BASE開発チームブログスマートフォン用の表示で見るBASE開発チームブログ2019-01-16ECS(Fargate)でコンテナアプリケーションを動かすための設定情報の扱い方AWSあけましておめでとうございます。BANK株式会社でソフトウェアエンジニアをやっている東口(@hgsgtk)です。Fargateの次の新機能を実際のプロダクトに適用しました。シークレットのサポートを追加これを期に、コンテナアプリケーションにおける設定情報を扱う考え方・それを実現するためのAWSのサービス構成と得られた利点についてまとめてみようと思います。BANK(エールバンク)」というプロダクトを開発しています。buildしたイメージから作成したコンテナをECS(Fargate)上で動かすことで機能を提供しています。設定情報とは本記事内での「設定情報」は、データベース、Memcached、他バックエンドサービスなどのリソースハンドルのための認証情報を指します。これらは、本番・ステージング・開発・QAなど環境ごとにそれぞれ異なる値を持つ属性があります。コンテナアプリケーションの設計として、設定情報をどう取り扱っていくか次に考えていきます。コンテナベースの設計思想・原則コンテナベースで動かすアプリケーションでの設計思想について次の2点の資料がよく参照されます。(Redhat)この2つの資料からコンテナベースアプリケーションにおける設定情報の扱い方について見ていきます。App」をHerokuの中の人が書きました。Appは、2016年にPivotal社が、オリジナルのガイドラインのアップデート・ガイドラインの追加したものです。クラウド環境を活用したクラウドネイティブアプリケーションの新たなベストプラクティスをガイドラインとしてまとめてくださっています。次のURLから実際にPDFをダウンロードすることができます。content.pivotal.ioまた、次のスライドが大変わかりやすくガイドラインについてまとめてくださっているので、そちらもご参照いただくと良いかと思います。Codeという章で言及されています。ピックアップすると大きく次の内容です。prd...etc)ごとに設定をグルーピングすべきではない。設定をコードから分離する一番の方法は環境変数への格納である。設定情報とコードを分離することを求めており、分離できているかどうかの指標として、今すぐにでもコードをオープンソース化できるかを上げています。次にもう一つredhatが公開している設計原則について見てみましょう。(Redhat)redhatが公開しているホワイトペーパーで、コンテナベース・アプリケーションの設計原則についてまとめています。次のURLにて日本語版の資料をダウンロードすることができます。イメージ不変性の原則いくつかの原則を説明している中で設定情報についての扱いに関連のあるものとしてこちらの原則があります。コンテナ化アプリケーションは不変であるため、ビルドされた後、異なる環境間で変化することは想定されていません。環境ごとにコンテナの作成や修正を行うのではなく、ランタイムデータの保存に外部手段を利用し、外部化した設定を環境によって使い分けます。上記の記述により、yamlファイルなどでアプリケーション内で設定情報を分けてそれぞれビルドする方法ではなく、ビルドするアプリケーション内に環境によって異なる情報は入れず、外部に保存した設定情報を使用することが推奨されています。2つの思想・原則から方針を見出すこれまで見てきた2つの資料から、コードから設定情報を分離し、環境変数から外部設定した設定情報を注入する構成としていきます。シークレットのサポートを追加で発表された機能を利用するため、プラットフォームバージョンは1.3以上を前提とします。アプリケーション環境変数から設定情報を取得する実装とします。Go言語の場合はosパッケージを利用して次のようなコードを書くことになるでしょう。Hubといったコンテナレジストリサービスにpushします。Storeに保管していきます。SSMでは、パラメータを階層的に管理する事が可能です。いった形で階層を掘っていく形になります。Store)を用いて暗号化キーを作成し、そのキーを持って暗号化します。SSMに設定する情報を暗号化する際は登録時に暗号化オプションを付け、KMSキーを指定します。ap-northeast-1具体的には、typeをSecureStringとし、key-idに作成したKMSキーを設定するだけです。コンテナから設定情報を利用SSMに保存した設定情報を、コンテナに挿入するためにはタスク実行ロールに対してSSMのパラメータ取得・KMSキーでの復号を許可する必要があります。具体的には、タスク実行ロールに対して以下のようなポリシーを追加します。Storeなどから設定情報をコンテナに注入するには、自前でdocker-entrypoint.shなどからSSMに対してAPIアクセスして取得する必要がありました。今回のサポートによって、タスク定義内のコンテナ定義に設定することによって、コンテナ起動時に自動でコンテナに対して設定を注入することができるようになりました。具体的には、コンテナ定義の環境変数に、環境変数名・SSMのパラメータ名を指定するだけです。コンテナ定義/環境変数設定1.3より前は、次のようなentrypoint.shなどを書いて対応していました。"$@"1.3へのアップデートによって、自前での実装が不要になり、かなりシンプルになりました。その他その他、より詳細の説明は、AWS公式の次のドキュメントを参照してみてください。docs.aws.amazon.comこの構成にして得られた利点コードから設定情報を分離できたコードから設定情報を分離したことによって、全アプリケーションエンジニアがすべての設定情報を参照できる状況は避けることができました。Storeに設定されています。本番・ステージングなどでアカウント自体が分かれている場合は、そもそもアカウントを発行されている人のみに閲覧を絞ることができ、加えてIAMの設定等で誰のアクセスを許可するかを制御することが可能になりました。Storeでは、階層的にパラメータを登録することが可能なため、情報を階層的に扱いたいモチベーションもある程度満たしてくれました。シークレットのサポートを追加によって嬉しかった点も記載します。コンテナ起動時の複雑性が軽減された当初、デプロイ時の複雑性を増していたdocker-entrypointでの自前実装が不要になり、アプリケーションの複雑性が減りました。イメージサイズが小さくなった副次的な効果として、AWSのAPIに対するアクセスが不要になったため、実行イメージに含めていたpythonとaws-cliが不要になりました。その効果によって、約40MB程度だったイメージサイズが約10MBまで小さくなりました。Fargateを利用した場合についての説明をさせていただきました。当初扱いづらさがあった部分もアップデートによって日々使い勝手がよくなってきている印象を覚えています。現在、ECSなどでアプリケーションを構成しようとしている・または検討している方にとって、一つの参考になれば幸いです。)の開発チームによるブログです。Groupの大木です。Developerをしている東口です。Groupのマネージャーをしている山田です。12/1から始まっ...Archiveスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。