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

WEB+DB PRESS

WEB+DB PRESS vol.86

WEB+DB PRESS Vol.86

WEB+DB PRESS Vol.86

第4章 本番環境の構築と Docker コンテナのデプロイ

% git clone https://github.com/spesnova/docker-example-capistrano.git
% cd docker-example-capistrano/coreos/
% cp .env.sample .env
% vagrant up
% vagrant ssh core-01
core@core-01 ~ $ cap -version
...
Capistrano Version: 3.3.5 (Rake Version: 10.4.2)
core@core-01 ~ $ cap postgres deploy
  • nginx コンテナのデプロイ
core@core-01 ~ $ cap nginx deploy
  • プロセスの管理は systemd で

  • Rails コンテナのデプロイ

core@core-01 ~ $ cap rails-blue deploy
core@core-01 ~ $ cap ps
MACHINE        ID        NAME                          STATUS                   PORTS                    COMMAND
172.17.8.101   5d5fb52   capistrano.1430525675         Up 2 seconds                                      cap ps
172.17.8.103   a42e044   docker-example-nginx          Up 16 minutes                                     /opt/nginx/sbin/nginx
172.17.8.102   5ad6a2c   docker-example-nginx          Up 16 minutes                                     /opt/nginx/sbin/nginx
172.17.8.102   6644478   docker-example-rails-blue     Up 45 seconds            0.0.0.0:8091->3000/tcp   bundle exec puma -C config/puma.rb
172.17.8.103   a96e2d7   docker-example-rails-blue     Up 45 seconds            0.0.0.0:8091->3000/tcp   bundle exec puma -C config/puma.rb
172.17.8.101   b89ffba   postgres                      Up 30 minutes            0.0.0.0:5432->5432/tcp   /docker-entrypoint.sh postgres
core@core-01 ~ $ cap rails-blue run
  • nginx との連携
core@core-01 ~ $ cap nginx deploy:switch[blue]
  • Rails コンテナのブルーグリーンデプロイ
core@core-01 ~ $ cap rails-green deploy deploy:switch[green]

f:id:yossk:20150502105653j:plain f:id:yossk:20150502105709j:plain

  • オーケストレーション自動化のポイント
    • 失敗が起こりえる前提で進める
    • 各操作を独立して自動化する
  • one-off コンテナによる管理タスクの実行
    • 短命なコンテナ
    • ephemeral コンテナとも
  • Swarm を使ったオーケストレーション
    • Docker 公式ツール
    • 複数 Docker ホスト環境下でも1つの Docker ホスト環境下と変わらない体験を提供
  • Swarm によるフィルタリング
    • どういうホストできどうすべきかという条件を与えることができる
  • Swarm によるリソースマネージメント  vaがどれくらい CPU とメモリを使うかを指定しておく

第5章 Docker 運用ノウハウ

  • 変更のしやすさが重要
  • Docker イメージの分割
    • Base イメージ
      • 何のイメージも継承しておらず起点となるイメージ
    • Build Dependencies イメージ
      • さまざまなライブラリやミドルウェアのビルドに共通して必要なパッケージがまとめて入ってるイメージ
    • Runtime イメージ
      • Ruby や Node.js などの実行環境がいインストールされたイメージ
    • Service イメージ
      • Rails アプリケーションや Elasticsearch など最終的に本番環境にデプロイするイメージ
  • Docker イメージのテスト
    • infrataster
    • テストする側もコンテナに
    • できる限りすべてをコンテナで行う
  • Wercker を利用したイメージの CI
  • モニタリング
  • ログ管理
    • 本番環境にデプロイされたコンテナのログは勝手に収集されるという状態が望ましい
    • Logspout
      • Docker コンテナ用のログルータ
    • Fluentd
    • Logentries : SaaS 型のログ集約サービス
    • ncat コマンドを使って Token ベースの TCP コネクション経由で journalctl から得られる systemd の全てのログを Logentries に送る
  • ホストマシンの運用
    • できるだけホストマシンにパッケージをインストールしないこと
    • コンテナを止められる、捨てられるようにしておくこと
    • Machine による upgrade で Docker のバージンアップ
    • CoreOS による Docker のバージョンアップ
  • パフォーマンスチューニング
    • VOLUME 機能
      • UnionFS をバイパス
    • ホストネットワーキング
  • セキュリティ
    • Docker を操作できるユーザを制限する
    • TLS認証を有効にして Docker Remote API を使う
    • コンテナ内のプロセスをルート権限で動かさない
    • Read-Only コンテナを動かす
    • 信頼できるイメージだけを使う