昨日「JAWS-UG コンテナ支部 #9」でデプロイについて話してきました．
中身は前に会社のブログで書いた話
なんだけど，これについて詳しい話をしてきた．
資料はこちら．
ecs-goployというデプロイツールを作った．
気になった発表
GitHub + ECSで快適Review環境
資料はまだみつけられてないんだけど，これっぽい．
pausっていうのは今回始めて聞いた．あとでなんか作ってみよ．
実はこういうのは前に作ったことがあって，
完全に目的は同じ．
俺の場合は，ECSを使うんじゃなくて，docker swarmを使っている．
この発表では，URLから接続先のコンテナの割り出しをするために，mysqlに接続情報を格納して，nginx + luaでmysqlにアクセスして接続先情報を取得するという話だった． この，接続先情報というのが，おそらくこういうものを作るときの一番のネックで，コンテナは好きに立ち上げられるけど，アクセスの振り分けが難しい． ましてや，ひとつのドメインのサブドメインとしてすべて機能してほしい．
そういうのをやる方法はいくつかあるんだけど（前はhipacheとか使ってたけど），docker swarmはそこを一番スマートに解決したと思う．
なにしろオーバーレイネットワークのお陰で，接続先情報はこちら側で一切管理する必要がない． サブドメインのドメイン名とコンテナ名が一致するという制約を受け入れてnginxの設定さえ書いておけば，基本的にdocker swarmを起動するだけでアクセスの振り分けをしてくれる．
作った当初はdocker swarmのネットワークが不安定で，たまにswarmクラスタから外れるやつが居たりしたんだけど，今年に入ってからのアップデートでだいぶマシになって，最近はとくにトラブルもなく運用できている．
その他
全体を通してやっぱりCloudFormationを使っている人は多いのかなーという印象を受けた．
俺は何を作るにしてもCloudFormationが余り好きではないので，基本的に使っていない． ECSのクラスタ作るのも全部terraformでやっている．
CloudFormationで楽に作れるかもしれないけど，複数人開発であのyamlを管理できる気もあまりしないんだよなー．
こういう場にくると，「ほんとにみんなECS作るのにCloudFormation使ってるの？」というような疑問が多少解消されて，「マジか，ほんとにこれで使ってるんだ」という気分になるので良い． いや，それでも使う気にはならないのだが． さすがにCloudFormationでECSのデプロイ出来ます！って言われても，全然それでデプロイしていこうっていう気分にはならない．
