• 11
    いいね
  • 0
    コメント

Official

ECS アップデートについて AWSJ 岩永亮介さん (@riywo)

  • Slide
  • EC2ContainerRegistryリリース
  • ServiceUpdateリソース利用率が設定可能
    • miniumHealthyPercent
    • maxinumPercent
  • CloudWatchメトリクス追加、リージョン拡張
  • awslogs対応
  • ServiceのAutoScaling対応
    • EC2インスタンスは今まで通りのAutoScalingの設定で
  • Docker1.11に
    • 1.12使いたい時は、Instanceに自分でインストールすればOK
    • OSも自分で選択すればOK
  • ECR用のCredentialHelper公開
  • AWSQuickStartForDockerDatacenter
    • Cloudformationのテンプレート

『(仮) EB multi-container docker をproduction で1年間運用して起きたこと』 株式会社VASILY 神崎さん (@tknzk)

  • Slide
  • iQONのADネットワークで利用
  • 4つのContainerで稼働
  • 構成
    • ruby,supervisord,nginx,td-agent,macharel-agent
    • AlpineLinux
  • ミドルウェアの更新が楽
    • ruby2.0 -> 2.2.3 -> 2.3.1とか
  • イメージの入れ替えが楽
  • DockerImageが肥大化
    • docker image削減した
    • mysql(maria-db)が大きいので、buildが必要なパッケージを精査。
  • EnvironmentClone
    • production/stagingの環境をまるごとコピー出来る
  • AutoScaling
    • アクセス過多は通常はAutoScalingで対応
  • TimeSchedhuledBaseAutoScalingで対応。-> 今はしていない。
  • DockerfileはApp別で別レポジトリで管理。
  • 手元のdockermachineでBuild&pushで運用
  • CircleCIがbuild&pushもしている
  • 運用ミス(deploy時)障害
    • デプロイ用のロボットアカウントを作成(quay.ioの機能)
  • Macharel-agentの不具合
    • base platformを変更したらうまく動作するようになった
    • deloy時にmackarel-agentのstopで失敗することがある
  • ELBのHealthCheckを使用しており、コケたらELBからリクエストが来ないので、カジュアルにデプロイが可能

『ECS を利用したデプロイ環境』 クックパッド株式会社 @eagletmt さん

v1のデプロイ方法

  • ホスト側にデプロイスクリプトを用意
    • 無停止で
    • 全開発者が出来るように
  • Nginxで、Nginxの設定切り替え(Hostヘッダを変更)で対応
  • 残念な点
    • ホスト指定が人力
    • EC2タグを指定
    • 他のサービスの設定も必要だった

v2のデプロイ方法

  • ECSを利用
  • デプロイ先の制御を任せる事が出来る
  • task definitionを隠蔽する必要があり、関連するリソースを設定する必だったのでHakoを開発
  • 設定ファイルからTaskDefinitionとELBを更新する
  • サービス毎にELBが必要なので、共通のELBを使いつつ、RProxyの設定をいい感じに変更するような別のモードを実装(Productionでは使用していない)。consulを使用している。
  • 秘匿値の安家い
  • yamlファイルに環境変数のように記述
  • 変数は別のストレージから取得(Dotenvとか)
  • Capistranoを使用する必要がなくなった
  • Rantaskで単発のタスクを実行している
  • 社内ではkuroko2のタスクとして実行出来るように整備
  • Hakoではデプロイ時にフックを書くことが可能
    • Route53の自動設定
    • Nginxコンテナのアクセス制限の設定
    • デプロイリビジョンをJenkinsの結果から決定
    • etc
  • FluentdLogDriverを使用。ホスト側にFluentdを起動し、そこからCloudWatchLogsへ転送。

『RailsアプリをECSで本番運用するためのStep by Step』 @joker1007 さん

  • Slide
  • ECSの利点
    • ミドルウェアのバージョン管理の容易さ
    • 無停止のデプロイ
    • AutoScaleのAMI管理不要
    • pull型のデプロイアーキテクチャ
  • 全環境の設定を管理対象に含める。
  • 秘匿情報はKMSで暗号化して起動時に復号化して管理。
  • yaml_vault
  • ファイルとして持っておきたいものはS3に暗号化して配置
  • TaskDefinitionの定義時やENtryKitで調整
  • uncornはSIGTERMで即死するので要調整
  • assets:precompileは、全環境用を事前に管理
  • CIサービスのキャッシュ管理に制約が多い
  • Capistranoで任意のコミットからイメージを作成出来るようにする
  • デプロイスクリプト
    • ecs_deploy ・・・ capistranoのタスクを定義するgem
  • ロギング
    • fluentd log driverを使用
    • Papertrailに転送
    • 今はcloudwatch logが楽そう
  • メンバーの展開と開発環境
    • docker-composeで1発起動可能に準備
  • AutoScale
    • TokyoリージョンにServiceAutoscaleがない
    • CloudwatchアラームをpollingしてTaskCountを調節
    • autoscaler
  • AutoScalingの注意点
    • EC2のノードレベルでは何のコンテナかわからない
    • 停止時に抱えたコンテナが停止しているとは限らない
    • 複数のアプリを混ぜると巻き込まれる
  • 得られた成果
    • デプロイ速度の向上
    • ミドルウェアアップデートの仕組み
    • Chefレシピを大幅削減
    • ゼロダウンタイム
  • Tips
    • 1プロセス1コンテナ
    • ロギングや監視のやりやすさ
    • 出来るだけ直接コンテナを見なくて済むように
    • ネイティブライブラリのコンパイルオプションに注意
    • gemコンパイル時にmarchオプションが指定されているとポータビリティが・・・
    • 環境変数を増やし過ぎないように工夫する

LT @yuka_jyotei さん

  • JAWS-UGの紹介

LT @ijin さん