docker-composeを環境別に使い分けたい

経緯

もともと、docker-compose.ymlで開発環境を用意していた。 プレビュー環境構築にあたり、諸々の事情により、プレビュー環境では別途新規に書き起こされたdocker-compose.yml、Dockerfileを使うことになった。 既存の設定は開発環境で使いつつ、プレビュー環境では新規の設定を使いたい。

やりたいこと

以下のような配慮をしつつ、Docker環境を使い分けたい。

  • 開発用PCでは、開発用docker-composeとプレビュー用docker-composeを適宜使い分けられるようにしたい。
  • プレビュー用ホストではプレビュー用docker-composeのみを使いたい。
  • プレビュー用ホストでうっかり開発用docker-composeで立ち上げることは絶対にしたくない。フールプルーフにしたい。
  • 開発PCでうっかりプレビュー用docker-composeを立ち上げてしまうのも避けたい。逆よりはマシだが。

実現案

  1. docker-composeのファイル名を分ける(例: docker-compose.development.yml)
    1. メリット
      1. フールプルーフ
      2. ファイル名を見れば用途がわかりやすい
    2. デメリット
      1. docker-compose -fオプションでいちいち指定するのが面倒
        1. だからといってよくつかう環境用の設定ファイルの名前をdocker-compose.ymlにすると、他の環境で使用してしまうというオペミスが発生する
        2. 環境変数COMPOSE_FILEで使用するdocker-compose.ymlを指定すれば対処できる 参考: suin.io
          1. メリット
            1. 一度設定すれば-fオプションが不要
          2. デメリット
            1. 環境構築時、知らない/忘れたひとは-fオプション無しで起動してハマる
              1. README.mdに書いておけばいいのでは
            2. 特定ディレクトリ下で環境変数を設定するいいかんじの方法が、自分はまだわからない => dotenvがよさそう。他の開発者と共有しやすそうなので。
              1. dotenv
              2. bashrcに記述 https://stackoverflow.com/a/14463040
              3. tmuxinator
  2. ブランチを分ける。追加開発分は適宜プレビュー用ブランチにマージする
    1. メリット
      1. -fオプションが不要
      2. 知らないひとがとりあえずdocker-compose upしてイライラすることもない
    2. デメリット
      1. フールプルーフでもフェイルセーフでもない。知らないで適当にdevelopブランチをプルしてきてdocker-compose upするとまずい
        1. previewで動かすとき、developブランチで合ってるのかな？というのは普通に気にするよね?
      2. docker-compose.ymlを変更したとき、おそらく変更がマージされてしまう
  3. 差分の設定を上書く
    1. メリット
      1. 公式の安心感 Use Compose in production
      2. ブランチを分ける必要がない
    2. デメリット
      1. フールプルーフでもフェイルセーフでもない。うっかりするとdevelopmentモードで起動してしまう
      2. docker-compose設定の全体像を把握しづらそう
      3. docker-compose設定を変更しづらそう
      4. 今回のケースだと、docker-compose設定が違いすぎるので、向かなさそう
  4. 環境ごとにわけない
    1. メリット
      1. 環境が分かれていることによるミスが発生しない
      2. じつは公式にも似たようなことが書いてある (The easiest way to deploy an application is to run it on a single server, similar to how you would run your development environment. If you want to scale up your application, you can run Compose apps on a Swarm cluster.)
    2. デメリット
      1. 当然、環境別の変更設定ができない

とりあえずの結論

1つ目の案でやってみる。フールプルーフで、かつ環境ごとに変更できるため。環境変数はdotenvを使って設定する。