読者です 読者をやめる 読者になる 読者になる

docker基盤としてECSを採用しました②

docker ECS AWS SpotFleet

こんにちはmatsです。

今回はdocker環境への全面移行について、運用環境や全体構成について書こうかと思います。

全体構成

f:id:intimatemerger:20170223123255p:plain

デプロイフロー

GitHubとCircleCIの連動を軸に自動化しています。流れ的には

  1. [GitHub] PRをmasterブランチにマージ
  2. [CircleCI] 自動テスト
  3. [CircleCI] docker build でイメージ作成
  4. [CircleCI] ECRに対してdocker push
  5. [CircleCI] API経由でECS Task Definitionを更新
  6. [CircleCI] API経由でECS Serviceを更新
  7. [ECS] Sevice設定を元にコンテナが展開される

masterブランチが勝手にデプロイされるので、デプロイという作業は行っていないような感じです。

また、ECSのコンテナの入れ替えはELBのヘルスチェックが通るまで古いコンテナを破棄しないため、Blue-Greenデプロイの様な感じになります。

Spot Fleet

dokcer基盤のインスタンスは全てSpot Fleetにて起動しています。 Spot Fleetの利用にあたってはcloud-initを駆使しているので、そのうちcloud-initに絞った記事を公開しようかと思います。

用途に応じてSpot FleetとECS Clusterを分けていますが、分け方としては

  • ジョブワーカー用の基盤はCPUのコア数指定でSpot Fleetを入札
  • Webサーバ用の基盤はインスタンスの台数指定でSpot Fleetを入札

のような感じです。

また、用途によらず基盤のオートスケールは行っていません。 理由としては

  • ECSのリソース予約がまだチューニング段階
  • オートスケール速度が緩慢
  • そもそもスポットインスタンスを使っているので、それほどコストメリットが効かない

などがあげられます。

ログハンドリング

詳細はまた別途書こうかと思いますが、基本的に

  • アプリケーションのログ → fluentdでBigQueryやMySQL、S3に収集
  • コンテナの標準出力 → logging-driverのsyslogでpapertrailへ

のような感じで行っています。papertrailでなくてもいいかともいますが、remote syslogに対応したサービスだとdocker engineから直接送ることが出来るので非常に楽に運用することが出来ます。

次回以降はもう少し個々の要素について細かく書いていこうかと思います。