Joyentは、ContainerPilotのバージョン3.0をリリースした。コンテナ内で複数プロセスを実行するためのinitシステムとして機能し、サービス登録プロセス、サービスディスカバリ、ヘルスチェック、プロセスのライフサイクル管理を自動化する。HTTPベースのAPI、シンプルな構成言語が新たに用意される一方で、サポート対象がConsulのみに限定された。
コンテナのinitシステムは、子プロセスの動作を追跡することによって、PID-1の問題に対処するものだ。ContainerPilotはもともと、単一の“メイン”アプリケーションというコンセプトで開発されていたが、バージョン3はコンテナ内の複数プロセスに対するコントローラとして機能するようになった。この変更は主として、複数の構成オプションに対する混乱からプロセス間の依存関係まで、ユーザからのフィードバックによるものだ。新バージョンでは、各プロセスが自身のヘルスチェック、依存関係、実行頻度、起動および停止のライフサイクルフックを保有するようになった。
コンテナ内に複数のプロセスが存在する状況は、一般的には、メインアプリと並行して動作する、サービスディスカバリエージェントのようなサポートプロセスが存在する場合に発生する。こういったサービスプロセスは、メインアプリケーションとは構成が異なっていたり、同一コンテナ内あるいは外部コンテナで動作する他サービスに依存したりする場合がある。このようなファクタが、オーケストレーション作業を複雑にしているのだ。
Joyentの推奨する“オートパイロット(Autopilot)”と呼ばれるパターンは、オーケストレーションの責任をすべてアプリケーション自体に移行することを目的としている。これによって外部のオーケストレータは不要になる。ここで言うオーケストレーションには、一般的に、他サービスからの発見を可能にするためのサービスエンドポイントのレジストリへの登録、ヘルスチェックの定義、依存関係の定義、ライフサイクル管理などのアクションが含まれる。ContainerPilotのケースでは、最新リリースでは、サービスディスカバリ機構としてHashicorpのConsulのみを対象としている。これまで対象であったetcdのサポートは廃止された。
画像提供: https://www.joyent.com/blog/containerpilot-hello-world
ContainerPilotの新たなHTTPベースのAPIでは、シグナルを送信して、アプリケーションとその環境をコントロールすることが可能になる。コンテナ内のソケットにHTTPリクエストを送信することで、環境変数の更新、メンテナンスモードの切り替え、Prometeusエンドポイント用のメトリック記録、ContainerPilot設定の再ロードを行なうことができる。状態の切り替えのみで結果のフィードバックを受け取ることのできなかった、従来のシグナルベースの機構を置き換えるものだ。
サービスのライフサイクルイベント間の依存関係を定義する手段として、v3では構成言語が統合された。例えば常駐するConsulエージェントが起動した時のみに、nginxがスタートするように定義することが可能だ。このような依存関係を、他サービスの起動または停止、あるいは他の任意の中間状態によって定義することができる。今回のリリースでは、これまで定義された“ビヘイビア”フックをすべて、ジョブ(Job)という抽象概念に統合している。さまざまなジョブを連携させれば、依存アプリケーションの連鎖を定義することができる。
ContainerPilotは、以前のJoyentのプロダクトであるContainerBuddyを拡張したもので、オープンソースプロジェクトとしても公開されている。
この記事を評価
- 編集者評
- 編集長アクション