「SEROKU フリーランス(以下、SEROKU)」の中の人をやっている kouki です。SEROKU では主にインフラ面の担当をしています。
今回は社内で展開しつつ、SEROKU の開発でも利用している社内 Kubernetes 環境についてご紹介します。具体的な構築ログはこちらに記載しています。
Qiita: 快適な kubernetes オンプレミス環境を構築する(1. 設計編)
[adinserter block="1"]
上記の記事は淡々と記載していますが、今回は社内 Kubernetes での利用例や実は苦労した点をつらつらと書かせていただきます。
はじめに、SEROKU の開発は Jenkins などを利用して CI/CD 環境を構築しています。マルチブランチパイプラインによる各トピックブランチのテスト実施など、昨今では「当たり前」になっている環境を提供しています。
[adinserter block="1"]
SEROKU での社内 Kubenetes 利用例
そういった開発を行っているうちに、「トピックブランチのデモを簡単に作れるといいなぁ」という要望が社内から上がりました。
本番環境は GKE(Google Kubernetes Engine) を利用していますが、社内サーバの活用と Kubenetes ノウハウ蓄積のために Kubernetes クラスタを社内に構築することに至りました。
具体的には以下のような流れでトピックブランチのデモ環境を活用しています。
- 開発者が開発用にトピックブランチ切る
- 開発者が手元で開発を行い、適宜完成したらレポジトリに commit
- 開発者が実装が終わったら、レビュー担当者にレビュー依頼
- 開発者が社内 Kubernetes 環境にトピックブランチをデプロイ & 別の開発者に動作確認を依頼
- 動作確認者が社内 Kubernetes 環境に構築されたデモ環境を使って動作確認
- レビュー担当者が動作確認まで完了をしていることを確認して、リリース用ブランチにマージ
Kubernetes にデモをデプロイする手順は、社内 wiki に記載して開発者に周知しています。各開発者の方たちはスムーズにデモ環境の構築ができているようです。
[adinserter block="1"]
構築するときに苦労した点
GKE と同様の環境を構築するにあたって苦労した点を紹介します。
Kubernetes クラスタ自体を構築するのは rancher を使ったため、とても容易に構築できました。しかし、実利用という観点から考えると様々な懸念点が浮上してきました。
- インターネット上にデモを公開するとして、グローバル IP アドレスはどの Node が受け持つのか？
- グローバル IP アドレスとプライベート IP アドレスを 2つ持つ Node に Ingress 相当を担当させることができるか？
- GKE 環境にデプロイするときには Google Container Registry を利用すればいいが、社内に閉じるためにはプライベートなレジストリが必要
- GKE は PersistentVolume を意識しなくてもよいが、社内 Kubernetes の PersistentVolume は何を使う？
構築した時期が 2017年の末あたりだったので、ネットに情報も少なく海外のサイトを渡り歩いたり、公式ドキュメントを読み込んだりしていました。調査をしているうちに、いくつかシンプルに実装できる方法が分かってきました。
- の問題に対する解決方法
- グローバル IP アドレスを持つ Node に対して、
nginx-ingress-controllerを DaemonSet として動作させることによって意図した動作ができるようになりました。
- グローバル IP アドレスを持つ Node に対して、
- の問題に対する解決方法
docker-registryとPortusをコンテナとしてクラスタにデプロイすることによって、プライベートなレジストリを利用することができました。また、Portus には LDAP 認証機能が付いているので、社内の LDAP と連携することができました。
- の問題に対する解決方法
- 社内に NFS サーバを構築して、 nfs-client-provisioner を利用することで解決しました。他にも
Rookなどの選択肢もありましたが、分散ストレージ運用よりもインフラ環境のシンプルさを選択しました。
- 社内に NFS サーバを構築して、 nfs-client-provisioner を利用することで解決しました。他にも
[adinserter block="1"]
まとめ
私は開発も担当していますが、調査などを含めて1ヵ月程度で構築することができました。トピックブランチのデモができるようになったことで、SEROKU の新機能実装や画面イメージなどが共有しやすくなりました。
また、社内 Kubernetes 環境が構築されたことで、社内のアプリをコンテナ化する気概が高まったという点が一番のメリットだと感じています。
SEROKU 以外にも、Prometheus や Jenkins X など様々なインフラツールを試す土壌ができているため、興味があるメンバーは社内 Kubernetes にお手軽に環境を構築していたりもします。最近はアプリ側も helm package にして、煩雑になりがちな Kubernetes の yaml を隠蔽していこうという流れになっていたりもします。
今回を機に今後も SEROKU と共にインフラ環境の整備を進化させ続けようと思います。
[adinserter block="1"]
＞SEROKUを支える技術 ～開発準備編～
＞SEROKUを支える技術～プロジェクト管理編～
＞SEROKUを支える技術～社内 Kubernetes 編～
＞SEROKUを支える技術～CI/CD編～
＞SEROKUを支える技術～社内 Kubernetes トラブルシュート前編～
＞SEROKUを支える技術 Angular Tips編 その1
＞SEROKUを支える技術 Angular Tips編 その2
＞SEROKUを支える技術 Angular Tips編 その3
profile:強面のインフラエンジニア。夜の街が似合うらしい。
