docker compose大全集

はじめに

Dockerfileの書き方については、こちらの記事で紹介しているのでイメージの作り方が知りたい方は参照してください。

また、この記事では主に使用するであろう情報は記載しているつもりですが、紹介しきれていないオプションや設定等もあります。

Docker Composeとは

• Docker Composeは、複数のDockerコンテナをまとめて定義・管理できるツールである。

• docker-compose.yaml という設定ファイルを用意することで、複数のコンテナを一括で作成・起動・停止・削除できる。

• 例えば、Webアプリの開発環境では、Webサーバ、DB、キャッシュサーバなど複数のコンテナが必要になることがある。

• Docker Composeを使えば、これらを1つの設定ファイルで定義し、docker compose up コマンドを実行するだけで環境を再現できる。

• また、一度作成したコンテナは停止しても設定が保持されるため、作業途中の環境を簡単に再開できる。

• docker runコマンドでも設定できるが、非常に長いオプションを毎回つける必要があるため、大変。

Docker Composeでできることの例

• 複数コンテナの一括起動・停止・削除が可能である
• ホストOSとのポートマッピング（例：ホストの 8080 → コンテナの 80）ができる
• ボリュームの作成・マウントによるデータ永続化が可能である
• カスタムネットワーク（bridgeネットワーク）の作成とコンテナのアタッチができる
• コンテナに任意の名前を付けて管理でき、停止・再開しても維持可能である
• 環境変数や依存関係をYAMLファイルで簡潔に定義できる

docker-compose.yamlの書き方

いきなり複雑な設定をするのはとっつきにくいので、簡単に最小構成を示す。

version: "3"
services:
  app:
    image: nginx:latest
    ports:
      - "8080:80"

version：docker-compose.yamlのフォーマットのバージョン

• 特に今は記述する必要はないが、昔の慣習から記述することが多い
• 現在のDocker Compose（v2以降）では、特に記述しなくても動作する。
  しかし、昔の慣習やドキュメントでは、互換性のために記述されることが多い。

services：コンテナをまとめる単位

• services は、複数のコンテナをひとまとめにして管理するための単位である。
• 各サービスには 任意の名前（service名） を付けることができる。
• サービスごとにコンテナを定義し、設定を個別に管理できる。
• 下記の図では、赤枠で囲っている web と db がそれぞれサービスである

• それぞれのサービスに対して、イメージや環境変数、ポート、ボリュームなどを個別に設定できる
• docker compose up で 全サービスをまとめて起動 できる
• docker compose up web のように 特定のサービスだけ起動 することもできる
• 停止や削除もサービス単位で行える

サービス（コンテナ）の設定

ここからはコンテナに設定できる、よくつかう項目の紹介をする。
※2,3の必須と記述した項目以外は記述しなくてもよい、記述しない場合はデフォルトの設定で動作する。

services:
  app:
    container_name: my-app      # 1.コンテナ名の指定
    image: ubuntu:latest        # 2.ベースイメージの指定 (2 or3 必須)
    build: ./test_project       # 3.Dockerfileからビルドする場合 (2 or3 必須)
    volumes:                    # 4.ボリューム・マウント設定
      - db_data:/var/lib/mysql  #   -名前付きボリューム
      - ./data:/home            #   -バインドマウント
    ports:                      # 5.ポートマッピング
      - "443:3000"              #   -ホスト:コンテナ
    environment:                # 6.環境変数の指定
      - APP_ENV=production
    networks:                   # 7.ネットワークの指定
      - test-net
    entrypoint: /start.sh       # 8.起動時に実行するスクリプト
    restart: always             # 9.自動再起動
    privileged: true            # 10.特権モード（非推奨）

#1 container_name：コンテナ名を固定できる

• コンテナに任意の名前を付けて固定できる。
• 名前を指定しない場合は、自動的に <サービス名>_<番号> という形式になる。

#2 image：既存イメージを使用

• ビルド済みのイメージがローカルに存在するか、DockerHub等のレジストリに存在する場合は、イメージ名とタグを指定する。

#3 build：Dockerfileからイメージを作成

• オリジナルのDockerfileからイメージを作成して使用したい場合に使用する。
• 値にディレクトリを指定すると、その中の Dockerfile が使用される。

#4 volumes：データ永続化・バインドマウント

• 名前付きボリューム
  • コンテナ専用ストレージのようなものを作成し、データをコンテナ削除後も保持する（DBデータなど）。
  • ネットワークと同様、既に存在する場合は名前を指定、存在しない場合は作成をする必要がある。

  services:
      ・
      ・
      ・
  volumes: # ←servicesと同じインデント 
      db-data: #作成したいvolume名
          external: true #既に作成済みのvolumeを利用する場合に指定
  

• バインドマウント
  • ホストOS上のディレクトリをコンテナにマウントして共有する。

#5 ports：ホストとコンテナのポートを接続

• ホストのポート番号:コンテナのポート番号の順で記述。
• 記述しなくても同じブリッジネットワーク内のコンテナ同士なら全てのポートにアクセス可能。

#6 environment：環境変数を設定

• コンテナ内に環境変数を注入できる。
• デプロイ環境ごとに設定を変えたい場合に便利。
• .envというファイルを作成し、環境変数を設定してdocker-compose.yamlと同じディレクトリに配置しておくと、下記のように変数で参照可能。

  environment:          
      - APP_ENV=${APP_ENV}
  

#7 networks：コンテナが所属するネットワークを指定

• 既存のネットワーク名を指定するか、Compose ファイル内で新規作成できる。

• 同じネットワークに所属するサービス同士は、サービス名で名前解決できる（例：db:3306 で DB にアクセス可能）。

• 指定しなければ default というネットワークが自動作成され、デフォルトは bridge ドライバになる。

• ネットワークの作成は下記のようにする

  services:
      ・
      ・
      ・
  networks: # ←servicesと同じインデント      
    app-net: #作成したいネットワーク名
      driver: bridge #作成するネットワークのモード（ドライバ）
  

  • ネットワークドライバの種類↓

    driver: bridge #（デフォルト）
    

    • 単一ホスト上で動く基本モード
    • NAT による外部アクセス、-p でポート公開

    driver: none
    

    • 完全に隔離、ネットワークなし

    driver: host
    

    • NAT を使わずホストのネットワークスタックをそのまま利用（Linux のみ）

    driver: macvlan
    

    • 物理 NIC 上に仮想 MAC を割り当て、LAN 上で別マシンとして認識される

    driver: overlay
    

    • 複数ホスト間で VXLAN を使ってコンテナ間通信
    • Docker Swarm や Kubernetes で利用される

#8 entrypoint：コンテナ起動時に実行するスクリプト

• コンテナ起動時に必ず実行されるスクリプトを指定できる。
• 例えば、コンテナ起動時にプロセスを立ち上げる場合によく使用する。

#9 restart：コンテナの再起動設定

• docker daemon起動時のコンテナの起動状態の設定には以下の４つのモードがある

  restart: no #（デフォルト）
  

  • 明示的にdocker startかdocker-compose upをしないと起動しない

  restart: always #（常に再起動）
  

  • docker daemonが起動したら、必ずコンテナも起動する。
  • docker stop等で停止すれば、daemonの再起動かコンテナをdocker startやcompose upで起動しない限り停止できる。

  restart: on-failure #（エラー時のみ再起動）
  

  • 基本的な動作は no と同じ（＝自動では起動しない）
  • コンテナが異常終了（exit code ≠ 0）した場合だけ再起動する
  • daemon を再起動したときには自動で復活しない
  • 再起動回数を制限するオプションも指定可能（例: on-failure:5 → 最大5回までリトライ）

  restart: unless-stopped #（明示的に停止しない限り、再起動）
  

  • 基本的な動作はalwaysと同じ（＝基本は自動起動）
  • docker stopなどで明示的に停止した場合は、docker daemonが起動しても停止したままにできる。

#10 privileged：特権モードでの起動（通常は非推奨）

• コンテナにホストOSのカーネルへ広いアクセス権限を与える。
• デバイス制御など特殊用途で必要になる場合を除き、基本的には使わない。

docker composeのコマンド

• 下記のコマンドはdocker-compose.yamlの存在するディレクトリ上で実行するか、-fオプションでyamlを指定しないとエラーになる

例)docker compose -f ./test/docker-compose.yaml 〇〇〇〇

• 下記はdocker composeの前提で記載しているが、バージョンなどによってはdocker-composeコマンドの場合もあるので注意

• また、下記コマンドの後ろにサービス名（例：webやapp）等を指定すればそのコンテナに対してのみ操作をすることも可能

例）docker compose 〇〇〇〇　web

起動・停止・削除

コンテナを作成して起動

• -dオプションでバックグラウンド起動

docker compose up (-d)

コンテナ・ネットワークを削除

• -v で関連するボリュームも削除

docker compose down (-v)

コンテナを停止（削除はしない）

docker compose stop

確認・ログ

コンテナの一覧と状態を確認

• docker psのyamlファイルに書いてあるコンテナのみの表示してくれるイメージ

docker compose ps

ログを追跡して確認

docker compose logs -f <サービス名>

最後に

docker composeについておおよそ説明しましたが、具体的な使用例や、どのような時に嬉しいのかの具体例があまり思いつかない方もいると思うので、近日中に筆者が実際にdockerを使って開発したシステムについて紹介したいと思います。