前回は、リリースエンジニアリングでGoogleの自動化ツールであるRapidとその関連ツールについてみていきました。
今回は、リリースエンジニアリングの最後の章として、設定管理について、見ていきます。
世間では、アドベントカレンダーの企画は終了したようですが、この連載には関係ありません。最後まで行きます。
設定管理
設定管理は、リリースエンジニアとSREが密に協力すべき領域の一つです。
設定の変更によって、サービスが不安定になってしまうことが十分考えられるからです。
Googleにおいて、システム及びサービスの設定のリリースと管理のアプローチは、時間の経過とともに変化しています。ですが、いつにおいても、設定をメインのソースコードリポジトリへ保存することと厳格なコードレビューが強制されます。
-
設定でのメインラインの使用
Borg上のサービスそしてBorg以前のシステムにおいて、使われた方法です。
この方法では、開発者とSREはメインブランチのヘッドにある設定ファイルを変更します。この変更はレビューされた後に、動作中のシステムに適用されます。これによりバイナリのリリースと設定の変更は分離されます。
この方法は単純でわかりやすいですが、プロダクション環境の設定との間に差ができてしまうのが欠点です。 -
MPMパッケージへの設定ファイルとバイナリの同梱
複数の設定ファイルを持つプロジェクトやリリースサイクルごとの設定ファイルが変更されるプロジェクトの場合、バイナリと設定ファイルを含めたMPMパッケージを作成することができます。
この方法は、バイナリと設定ファイルが密に組み合わされているので、柔軟性が制限されますが、一つのパッケージをインストールすればいいので、デプロイメントは単純になります。 -
MPMの「設定パッケージ」への設定ファイルのパッケージ化
バイナリと設定は密結合になる傾向があるので、バイナリと設定ファイルのスナップショットをリリースします。ビルドIDを用いれば、過去の特定の時点での設定を再構築できます。
複数のパッケージをまとめてインストールする場合には、ラベル機能を使うことができます。新しいバージョンがリリースされた場合、新バージョンのパッケージにラベルが付けられます。 -
外部ソースからの設定ファイル読み込み
設定ファイルを頻繁に変更したり、動的に変更が必要なプロジェクトは、ソースコードレポジトリへアクセスできるファイルシステムに保存することができます。
まとめ
- 設定管理は、ケースバイケースに応じて、適切に適用する。
- リリースエンジニアリングは、後付けで行われることが多いが、できるだけ早くリリースに関するリソースを確保する必要がある
参考文献
- Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 97-100