インフラ

Docker Composeを使うにあたってのTIPS集

はじめに

ume(梅)です。
Docker Compose使ってますか?
最終的に各種CSP提供のオーケストレーションツールで稼働させるにしても、ローカル開発環境や小規模な環境であればdocker composeコマンドでオーケストレーションさせていることも多いと思います。
今回は実務上で利用したいくつかのTIPSをみなさんに紹介します。

結論

当然ながら公式ドキュメント#環境変数, 公式ドキュメント#composeファイル内の例を読むのが第一ソースとなります。
記述した設定はdocker compose configで確認することになります。

とはいえ、結論のみで終わってもつまらないので筆者の整理の為にも暫しお付き合いください。

前提条件

以下の技術スタックでの実施しています

  • Docker
  • Docker Compose

ファイル分割

docker compose用にcompose.yaml (場合によっては{,docker-}compose.y{a,}mlのどれかかも)を記述されてると思いますが、複数のYAMLファイルを最終的な実行設定とすることが可能です。

デフォルトではdocker composeの実行ディレクトリにある、compose.yamlと(存在する場合は)compose.override.yamlを読み込みそれぞれのファイルのキーをマージすることができます。

マージ

以下、マージされるcompose.yamlとcompose.override.yamlのサンプルです

compose.yaml

services:
  hoge:
    build:
      context: src
      dockerfile: hoge/Dockerfile
    volumes:
      - ./src/hoge:/usr/local/src/hoge:ro
      - ./src/hog-lib:/usr/local/src/hoge-lib:ro
networks:
  external:
    name: ext
    external: true

compose.override.yaml

services:
  hoge:
    build:
      dockerfile: hoge/Dockerfile.debug
      target: debug
    volumes: !reset []
networks:
  external: !override
    name: ext-over

以下マージの説明になります。

  • 存在しているservices.hoge.build.dockerfileキーがcompose.override.yaml上の値でマージされる
  • 存在していないservices.hoge.build.targetキーがマージされる
  • !resetタグによりservices.hoge.volumesキーの値が空の配列にリセットされる
  • !overrideタグによりnetworks.externalキーの値がcompose.yamlが適用されずcompose.override.yamlのみに設定される

配列の順序や一意化、command等キーによっては固有の動作があるためより詳しくは公式#マージを参照ください。

ファイル指定方法

以下の手順でデフォルト以外のファイルを読み込むことが可能です。

  • docker composeコマンドの-f|--fileオプションでファイルを指定
  • COMPOSE_FILE環境変数にパス区切り文字でファイルを列挙

想定ユースケース

  • 環境毎の差異で環境変数で吸収出来ないものを別ファイルに分離する
    • マージのサンプルに記述した通り、コンテナイメージのビルドターゲットをデバッグ用にする
  • ローカル実行時の上書き
    • 対象のYAMLファイル指定が可能なので既存のcompose.yamlを編集せずに設定変更が可能になる

設定外部化

direnvを使用して開発ディレクトリ毎の環境変数を分離するのが王道になると思われますが、docker composeコマンドの実行ディレクトリの.envファイルをデフォルトで読み込み設定展開が可能です。

以下はファイルの例です。
.env

COMPOSE_PROJECT_NAME=hoge-project
COMPOSE_FILE=compose.yaml:compose.debug.yaml
COMPOSE_PROFILES=dummy

ALL_PROXY=http://198.51.100.200:3128

DB_HOST=192.0.2.100
DB_PORT=1024

それぞれ、docker composeコマンド用の環境変数(これ自体が.env読み込み可能なのは留意しておくと良いかも)、--build-argsオプションに使用するプロキシ設定、コンテナの環境変数用のDB設定になります。

想定ユースケース

  • 環境によって容易に変わりえる値の外部化
  • センシティブな値の外部化

使い回し

docker compsoeコマンドというよりはYAMLの仕様ですが、アンカー機能による記述済みの事項の再利用が可能です。

以下はファイルの例です。
compose.yaml

x-service-common: &service-common
  build: &service-common-build
    args:
      - ALL_PROXY
    target: debug
  ports:
    - &service-common-port ":${SERVICE_PORT}"
  environment: &service-common-environment
    SERVICE_PORT: ${SERVICE_PORT}
x-service-admin:
  ports:
    - &service-admin-port ":${ADMIN_PORT}"
  environment: &service-admin-environment
    ADMIN_PORT: ${ADMIN_PORT}
services:
  hoge: *service-common
  fuga:
    <<: *service-common
    ports:
      -  *service-common-port
      -  *service-admin-port
    environment:
      <<: [*service-common-environment, *service-admin-environment]

service.hogeについてはx-service-commonの値をそのまま利用し、service.fugaについてはx-service-commonを仕様した上で、x-service-admin配下の値を適宜マージさせています。

より詳しくは公式#フラグメンツ,公式#拡張を参照ください。

想定ユースケース

  • ports, build, environment等の大枠で再利用する箇所の記述統一

おわりに

いかがだったでしょうか?
なんの気無しに使ってるかもしれないDocker Composeの知らない機能を知っていただけたなら幸いです。

P.S.

他にもextends, includeといった機能があります。
どこまで使いこなすかはプロジェクト次第ですがご利用も一考かと。

AUTHOR
ume
ume
記事URLをコピーしました