ecs-deployからecspressoに乗り換えた

のがもはや半年前だけど記録として書いておく。結論を書くと、ecs-deployからecspressoに乗り換えるのはすぐできるし、タスク定義が管理しやすくなるのでおすすめです。

https://github.com/kayac/ecspresso

もともとNature社では僕が入社する前からecs-deployが使われていた。これは、コンテナイメージをすげ替えてdeployするだけであればシンプルでわかりやすい。ただ、以下のような課題があった。

• タスク定義自体を変更したい時にecs-deployだけでは対応できない
• ソースがbashスクリプトで年々複雑になっており(僕には)読みづらい
• 実際度々メンテナンスが滞ったりforkがいくつかあったりする
• jqやawsコマンドに依存している

それに対して、ecspressoは以下のような利点があった。

• タスク定義ごとリポジトリ管理できる
• Goなので(僕には)読みやすい
• メンテナンスも活発で、開発陣とコミュニケーションとりやすいので僕もメンテナンスに関わりやすい
• 外部コマンドに依存せずGoバイナリ一個で済む

タスク定義をリポジトリ管理できるようになったのが一番大きなメリットで、サイドカーの追加やパラメーターの変更などがpull request上でレビューできるようになった。

deployのフロー

社内のdeployはCircleCIから実行している。masterブランチが進むと勝手にdeployされるようになっている。これをecs-deployからecspressoを使うようにした。ecspressoのバイナリはかっこ悪いがリポジトリに突っ込んでいる。今だとOrbがあるのでそれを使うのが良さそう。

https://circleci.com/orbs/registry/orb/fujiwara/ecspresso

ちなみに、ecspressoのデフォルト挙動ではサービスが更新されてdeployの完了を待つ挙動になっているが、我々のユースケースだと、場合によってはいくつかのサービスを同時にdeployする関係上、そこでブロックして欲しくなかった。

なので、サービス更新がかかったらすぐに抜ける --no-wait オプションを追加するpull requestを送って取り込んでもらった。こっちのほうがecs-deployの挙動にも近いので乗り換える場合はおすすめです。ちなみに、--no-wait で一旦抜けた際にサービス更新完了を待ち受けたい場合は ecspresso wait コマンドを実行することでサービスの更新完了まで待機することができます。

以前git-pr-releaseのエントリに書いたように、Nature社では、featureブランチがdevelopブランチにマージされたら、developからmasterへのpull requestが自動で作られるようになっており、そのマージボタンを押したらさながらワンクリップデプロイの要領で本番に反映されるので体験が良い。

設定ファイル類の配置や課題など

設定類は今の所リポジトリの conf/ecspresso/ 配下に諸々配置している。例えば以下のような具合。

$ tree conf/ecspresso
conf/ecspresso
├── production-api.yaml
├── production-worker.yaml
├── production-consul.yaml
├── production-datadog-agent.yaml
├── production-nginx.yaml
├── taskdef-api.json
├── taskdef-worker.json
├── taskdef-consul.json
├── taskdef-datadog-agent.json
└── taskdef-nginx.json

YAMLが設定ファイルで{env}-{service}.yaml、JSONがタスク定義でtaskdef-{family}.jsonという命名規則にしている。サービス定義は配置していないが、管理したくなったら配置するかも知れない。

YAMLの設定ファイルがアプリケーション及びデプロイの単位となるが、一つのリポジトリの中に複数のアプリケーションがあるのはTwelve-Factor App的には良いことではないが、サブコンポーネント的なちょっとしたアプリケーションのためだけにリポジトリを分けるのも大げさなのでこのように管理している。

上記のAPIとWorkerについてはmasterブランチが進んだら愚直に両方deployされるようにしていて、その他のサブコンポーネントの類は一部手元からecspressoコマンドを実行する形でdeployしている。

手元のコマンド実行でdeployするのはあまり良いことではないので、masterブランチが進んだ時に更新が必要なdeployを洗い出して自動的に出ていくようにするのが良いと考えていて、そのあたりはBazel的なやつを入れるのが良いのかなーとか考えたりしている。ということでモノレポ指向になっていくかもしれない。