はじめに
この連載ではコンテナとコンテナオーケストレーションを使用した分散システムの設計パターンについてまとめていきます。
今回はサイドカーについて学びます。 (分散じゃないです)
連載記事一覧
サイドカーを使ったシンプルなPaasの構築
サイドカーパタンは機能追加や監視以外にも、シンプルにモジュール化した方法でアプリケーションの完全なロジックを実装する方法でもあります。
例 : Gitリポジトリへのソースアップロードが起動中のサーバーに自動デプロイ
サーバー上で動作するコンテナは以下の２つ
- メインアプリケーション : Node.jsサーバー。新しいファイルがアップロードされると自動でリロードされる。
- 詳しくはnodemonを参照
- サイドカーコンテナ : メインアプリケーションコンテナとファイルシステムを共有し、ファイルシステムをGitリポジトリと同期する。
#!/bin/bash while true; do git pull sleep 10 done
Node.jsアプリケーションとGIt同期サードカーは同じマシンに配置され、一度デプロイされたら、新しいコードがGitプッシュされるたびにコードはサイドカーによって自動的に更新されます。
モジュール化と再利用性を考えたサイドカーの設計
サイドカーはモジュール化されて再利用可であることが重要です。
特に以下の３つに焦点を当てましょう
- コンテナのパラメータ化
- コンテナのAPI使用の設計
- コンテナのオペレーションのドキュメント化
パラメータ化されたコンテナ
コンテナを再利用可能にするために最も重要なのがパラメータ化です。 各パラメータは汎用的なコンテナを特定の状況向けにカスタマイズするための入力です。
例 : リバースプロキシでSSL機能を追加するサイドカーコンテナ
前回 例にあげたレガシーアプリのSSLコンテナを使えるようにするには少なくとも以下の2つのパラメータが必要です。
- SSLを提供するための証明書のパス
- ローカルホストで動いているレガシーアプリのポート番号
証明書のパスとポートを環境変数として渡した場合のコマンド例は以下のようになります。
docker run -e=CERTIFICATE_PATH=/path/to/cert.crt -e=PROXY_PORT=8080
コンテナ内ではこれらの変数を使って、nogix.conf内で正しい証明書とプロキシ先を設定できます。
各コンテナのAPI仕様の設計
パラメータ化した事で、コンテナは実行される度に呼び出される「関数」になります。
コンテナが周りとやりとりする方法の全てが、そのコンテナが定義するAPIの要素になります。
APIがあることにより、サイドカーを利用しているものがサイドカーのバージョン更新に際しても正常に動き続けることができます。
また、サイドカーのAPIがしっかり設計されていると、サイドカーの開発者は素早く変更を加えることができます。
また、サイドカーのAPIに対する変更は、そのサイドカーの利用者にも影響を与える破壊的変更になり得るので十分な注意が必要です。
→ APIを不変に保つ
コンテナのドキュメント化
コンテナをすぐに使えるようにする。
以下、DockerFileがドキュメントとしても機能するようにするための指針。
- EXPOSE ディレクティブを含める
- どのポートでリッスンするかコメントつけておく。
- コンテナのパラメータ化に環境変数を使う場合はパラメータのデフォルト値を決めるためのENVディレクトリを仕様し、使用方法もコメントしておく。
- イメージにメタデータを追加するためのLABELディレクティブは必ずつける。
- よく使われるラベルなどはこちらを参考に
まとめ
第二回ではサイドカーパターンを学びました。
サイドカーはアプリケーションに変更を加えるにはコストがかかりすぎる時に、レガシーアプリケーションを更新するために利用できます。
また、共通機能の実装を標準化する、モジュール化されたユーティリティコンテナを作成するのにも利用できます。