Kubefork
最終更新
最終更新
この章では、Wantedly で使われている Kubefork の概要について説明します。
Kubefork (社内では単に fork と呼ばれることが多いです) とは、 任意の identifier に基づく Virtual Cluster を作成すること、と定義されています。
Virtual Cluster について説明するために、まずマイクロサービス開発においてのあるあるを説明します。
あるコンポーネントを手元で開発するためには、コンポーネントが通信する別のコンポーネントのことも考える必要があります。一般には通信部分をモックしたり、 docker-compose などを使って手元に関連するプロセスを建てるなどの戦略が考えられます。このとき、コンポーネントのことをよく知らない人は何に依存しているかはよく知らないため、開発がうまく行かないときに何が悪いのかの切り分けが難しくなってしまう、といった問題があります。
開発用クラスタにはコンポーネントが一式揃っているため、開発したコンポーネントをクラスタにデプロイする、といった方法も考えられます。しかし、この方法は他の開発者にも迷惑がかかってしまうためうまくいきません。開発用クラスタを個々人に一つづつ割り当てるという方法もありえますが、コスト的な問題で難しいでしょう。
そこで、Wantedly では Virtual Cluster という概念を用いてマイクロサービス開発を行えるようにしています。 実際に存在する開発用クラスタに対して、仮想的なクラスタという意味で Virtual Cluster と名付けられています。 技術的には、特定のヘッダが付いている通信を特定の service にルーティングする仕組みで実現されています。
上記を説明した図が次の図です。
開発者は 図の2つめのマイクロサービスを開発するために A という Virtual Cluster を作成しました。変更を加えた マイクロサービスを A にデプロイすることで、他の開発者に迷惑をかけずに 変更したマイクロサービスが動くかどうか、開発環境へのリクエストを使って試すことができます。
このようにして、社内の Web アプリケーションの開発では開発者それぞれ Virtual Cluster を使って開発を行っています。
fork を用いた開発手法について次に示したあと、それぞれ説明します。
local fork
remote fork
PR Preview
次のようなコマンドを実行することで local fork を行うことができます。
local fork を実行すると、 Virtual Cluster が作成されたあと、Telepresence が起動し、 Virtual Cluster 宛のリクエストが手元に来るようになります。
リクエストが手元に来るだけでなく、クラスタ上の service へのリクエストも手元から行えるようになるので、クラスタ上で開発をしているような体験が得られます。
次のようなコマンドを使うと、現状開発しているブランチの Docker Image を Virtal Cluster 上にデプロイすることができます。
手元に開発環境がなくても、ファイルの編集と git push ができれば動作確認は remote fork で行う ということが可能です。
GitHub 上で Pull Request が作成されると、その Pull Request に対応した Virtual Cluster が作成されます。また、アプリケーションに到達するためのURLがコメントされるので機能の確認などに使うことができます。
Slack: #dx
Slack: #kube-fork-testers
