JAWS-UGおコンテナ支部 #5 に行ってきました
少し前になりますが6/27(月)に行われたJAWS-UGおコンテナ支部 #5に行ってきました。
コンテナ支部には初参加でした。ちょうど業務でECSを検討しているところで、今回は運用系の話が多そうだったので思わず参加。
みなさんもう普通にコンテナを使っていらっしゃる。具体的な運用例なども聞けたのでかなり参考になりました。
以下メモ付き感想。ちょっとうろ覚えのところもあるかもしれません。目次はイベントのページから引用させていただきました。
あいさつとか
- おとなのたしなみ おコンテナ
ECS アップデートについて AWSJ 岩永亮介さん (@riywo)
ここ半年での ESC のアップデートの紹介。
- Service Update のリソース利用率が設定可能になった
- メトリクス、リージョン拡大
- Cluster のメトリクス
- Service のメトリクス(Taskが確保したCPU、メモリをどのくらい利用しているか)
- Logの設定で awslogs が使えるようになった
- ログドライバに clodwatch logs 対応、kibana に連携
- Service のオートスケーリング対応
- 東京リージョンは未対応
- docker 1.11.1 対応
- 本家では 1.12 がリリースされたが追従したい場合は自分でインストールすればOK
- ECRのCredential Helper公開
- Registryの認証時に認証処理を代行してくれる
- docker login不要
- Quick Start for Dcoker Datacenter
- CloudFormation テンプレート
- 6ヶ月で10回近くのアップデートが行われていて、開発はとても活発
『(仮) EB multi-container docker をproduction で1年間運用して起きたこと』 株式会社VASILY 神崎さん (@tknzk)
こちらは ECS ではなく、 ElasticBeanstalk のマルチコンテナ Docker の運用ノウハウ。 監視に Mackerel を使っていたりミドルウェアが rails,redis,mysql だったり親近感のある構成とだったので参考になりました。 カジュアルに image を入れ替える事ができてミドルウェアのアップデートがとても楽になったそうで、これだけでも Docker 化する価値がありそう。 Docker Registry に quay.io を使っているそうですが、現状 quay.io が SPOF になってるとおっしゃっていて意外と盲点でした。
- iQONAD
- iQONおよび外部アプリに広告配信のADネットワーク
- ruby,rails,sinatra
- mysql,redis,memcached
- ec2,ElasticBeanstalk
- ミドルウェアの更新が楽になった
- ruby2.0->2.2系に移行 -> 2.3.1 -> 2.4.0もテスト中
- 他のミドルウェアもカジュアルにアップデート
- Docker image がでっかい問題
- alpine を採用したり、不要なバイナリを削除したりして削減してる
- environment クローン 環境をまるっとコピーできて便利
- 通常のアクセス増減はオートスケーリングで対応
- スパイクがあるとオートスケーリングじゃ対応しきれない
- タイムスケジュール機能でスパイクに対応してた
- Docker Registry は quay.io を使用
- 専用のブランチに push すると CircleCI がイメージを build&push
- EBやDocker起因の障害はなし
- alpineをproduction運用中
『ECS を利用したデプロイ環境』 クックパッド株式会社 @eagletmt さん
クックパッドでは新規のwebアプリケーションは基本 Docker を利用しているそう。 カジュアルな社内向けサービスのデプロイ先としてECSを使っていて、ECS化するにあたって秘匿値(設定ファイルに直書きできないパスワード等)の設定や Route53 の設定などを行ってくれる Hako というアプリケーションを作って運用している。 開発者が自由に使える Docker 環境というのはいいですね。
- 2014/09ごろからDockerを検討
- 自分の新規アプリをパイロットプロジェクトとして利用開始
- v1
- 同じ方法でどんなアプリケーションでもスケールできるようになった
- 残念点
- デプロイ先のホストは人力
- タグを指定していた
- v2 ECS
- デプロイ先の制御をECSにやってもらえる
- 秘匿値の扱い。別のストレージから値を入れる必要がある
- ECSだけじゃ完結しないのでHakoというツールを開発
- 秘匿値は変数で書けるようにしている、デプロイ時に別のストレージから値をとってくる
- etcenvなどを使う
- デプロイコマンドの実行はRundeckでやっている
- バッチ処理は Service を使わずに Runtask で単発実行
- デプロイ時の hook
- route53 自動設定、nginx コンテナのアクセス制御、デプロイするイメージのリビジョンを Jenkins の結果から決定
- fluentd log driverを使ってcloud watch logsに転送
- 社内アプリが気楽につくられるようになった
『RailsアプリをECSで本番運用するためのStep by Step』 @joker1007 さん
RailsアプリをECSで本番運用するためのStep by Step
主要なシステムはほぼECSに移行を終えていて、そのために具体的にどのような事が必要だったかという話。 Railsプロダクトだったので参考になりまくりです。 Service の Autoscale が東京リージョンで使えるようになっていないため、自分で実装したとのこと。(凄い) やはりここでも秘匿情報の取り扱いについて触れられていてこの辺の扱いは課題になりそうです。
- 主要システムはほぼECSに移行完了
- web,api,非同期処理ワーカー
- クラスタは15台くらい。スケーリングするとこの3倍くらいまで増える
- ECS化した理由
- 現実に必要な事
- 各環境の設定をどうするか
- 非同期処理のワーカーどうするか
- assets:precompile
- 秘匿情報
- KMSで暗号化
- ECSならIAMロールで復号化できる
- yaml_vault
- ファイルとしてもっておきたいのはS3に暗号化しておいとく
- 起動モードを切り替えられるようにしておく
- アプリケーションプロセス
- wokerプロセス
- rakeの実行
- entrykitで調整
- graceful restert。unicornはsigtermで即死するのでシグナル変更する必要がある
- assetsファイル自体は事前に作成してS3へ
- 複数の(Docker)イメージを作らないのはイメージ管理をしないでよくするため
- ビルドサーバの構築
- Docker 環境を各開発者が持たなくてよい
- CIサービスだとデータキャッシュに制約が多い
- デプロイスクリプト
- capと同じ使い勝手を実現したい
- ecs_deployを作った
- 東京リージョンにservice autoscaleがない
- 車輪の再発明だが実装した
- cloduwatch アラームの状態をポーリングしてある状態になったらTask countを調節する
- 得られた成果
- デプロイ速度向上
- ミドルウェアアップデートの仕組み
- chefレシピを大幅に削減
- ゼロダウンタイム
- コンテナ便利