本番環境での Compose の利用
Compose を用いたアプリの定義を開発環境で行っていたら、その定義を別の環境に、たとえば継続インテグレーション（CI）、ステージング環境、本番環境に適用することができます。
アプリケーションをデプロイする一番簡単な方法は、一つのサーバー上で動作させることです。 ちょうど開発環境で動作させている方法に近いものです。 アプリケーションをスケールアップしたいなら、Compose アプリをスウォームクラスター上で実行する方法もあります。
本番環境向け Compose ファイルの修正
アプリケーションの設定を本番環境向けにするには、変更を要するかもしれません。 その変更とは以下のようなものです。
- アプリケーションコードからボリュームバインディングは削除します。 コードは内部のみで実現するようにし、外部から変更されないようにします。
- ホスト上のポートは別のものを割り当てます。
- 環境変数は区別して割り当てます。 たとえば冗長なログ出力が不要な場合にログレベルを下げるとか、メールサーバーのような外部サーバーの設定を行うなど。
- 再起動ポリシーを設定します。
たとえば
restart: alwaysとすることで、システムダウンの時間を減らします。 - ログ収集といったような追加サービスを設定します。
このようなことがあるので、追加の Compose ファイルとしてたとえばproduction.ymlといったものを用意して、そこに本番環境固有の設定を行うことを考えておきましょう。
この設定ファイルには、元の Compose ファイルに対して変更したい内容のみを含めておけばよいことになります。
つまりこの追加ファイルは、元々のdocker-compose.ymlにさらに設定を追加して、新たな設定を作り出すものとなるわけです。
このような 2 つめの設定ファイルを用意したら Compose に対してこれを利用するために-fオプションを用います。
$ docker-compose -f docker-compose.yml -f production.yml up -d
より詳細な例は、複数 compose ファイルの利用を参照してください。
アプリ変更後のデプロイ
アプリコードに変更を加えたら、イメージを再ビルドし、アプリのコンテナーを再生成することを忘れないでください。
webというサービスを再デプロイするには以下のようにします。
$ docker-compose build web
$ docker-compose up --no-deps -d web
はじめにwebのイメージを再ビルドし、次にwebサービスのみを停止、破棄、再生成します。
--no-depsフラグはwebサービスが依存している他のサービスを再生成しないことを指示しています。
単一サーバー上での Compose の実行
Compose を使って、リモートの Docker ホストへアプリをデプロイすることができます。
これを行うにはDOCKER_HOST、DOCKER_TLS_VERIFY、DOCKER_CERT_PATHという各環境変数を適切に設定します。
環境変数を設定していれば、他になにかを設定する必要はなく、通常のdocker-composeコマンドを使っていくことができます。