docker compose の記述ルールについての簡単な説明

この記事ではクラスタの展開に関連する内容は紹介しません

バージョン制約

• Docker エンジン >= 19.03
• Docker Compose >= 3.8

構造紹介

docker-compose.yamlファイル構造は主に以下のものから構成されています。

version # docker compose versionnetworks # docker の内部通信に使用されるネットワーク containerx-{name} # テンプレートの命名規則は再利用のために x- で始まりますvolumes # ボリュームをマウントservices # サービス モジュール。内部でコンテナー情報を定義します。その内部パラメーターは docker run のパラメーターと同じです。

モジュールの紹介

Docker Compose 公式ドキュメント

バージョン

docker-compose.yamlのバージョンをアップグレードする必要がある場合は、ドキュメントのバージョンアップグレードリファレンスドキュメントを参照してください。

ネットワークモード

--networkパラメータと同じ値を、特別な形式service:[service name]で使用します。

ネットワークモード: "ブリッジ"
ネットワークモード: "ホスト"
ネットワークモード: "なし"
network_mode: "service:[サービス名]"
network_mode: "container:[コンテナ名/ID]"

ネットワーク

現在のdocker-compose.yamlファイルによって作成されたコンテナのネットワークを設定します

必ずしもバージョンと同じレベルに存在するわけではなく、サービスなどの他のモジュールにも存在する場合があります。

内部ネットワーク

サービス:
 いくつかのサービス:
  ネットワーク:
   -あるネットワーク
   - その他のネットワーク

パブリックネットワーク

バージョン: "3"
ネットワーク:
 デフォルトネットワーク:

エイリアス（追加予定）

ネットワークエイリアス

バージョン: "3.8"

サービス:
 ウェブ：
  画像: "nginx:alpine"
  ネットワーク:
   - 新しい

 ワーカー：
  イメージ: "my-worker-image:latest"
  ネットワーク:
   - 遺産

 デシベル:
  画像: mysql
  ネットワーク:
   新しい：
    エイリアス:
     - データベース
   遺産：
    エイリアス:
     -MySQLについて

ネットワーク:
 新しい：
 遺産：

ipv4_address、ipv6_address（追加予定）

バージョン: "3.8"

サービス:
 アプリ：
  画像: nginx:alpine
  ネットワーク:
   アプリネット:
    ipv4_アドレス: 172.16.238.10
    ipv6_アドレス: 2001:3984:3989::10

ネットワーク:
 アプリネット:
  ipam:
   ドライバー: デフォルト
   設定:
    - サブネット: "172.16.238.0/24"
    - サブネット: "2001:3984:3989::/64"

サービス

最も重要な部分は各サービスを構成するために使用されます

建てる

イメージをビルドするために使用されます。build フィールドと image フィールドの両方が存在する場合、image で指定されたイメージ名とタグが、ビルドされたイメージの名前とタグとして使用されます。

version: "3.8" # docker compose バージョン サービス:
 webapp: # docker-compose で定義されるサービス (コンテナ) 名は主に docker-compose コマンドのパラメータ用であり、docker が認識するコンテナ名と一致しない場合があります ps build: # Dockerfile を使用してイメージをビルドします context: ./dir コンテキスト パス、相対パスは compose ファイル パスを基準とします dockerfile: Dockerfile-alternate # Dockerfile ファイル名を指定します args: # Dockerfile 環境変数のパラメータを指定します buildno: 1 # ディレクトリとリストの両方の書き込みが許容されます

コンテクスト

相対パスまたは Git リポジトリの URL を使用できます。

建てる：
 コンテキスト: ./dir

Dockerファイル

Dockerfileファイル名を指定し、コンテキストを指定する必要があります

建てる：
 コンテクスト： 。
 dockerfile: Dockerfile 代替

引数

DockerfileのARGフィールドは、docker build時に環境変数を指定するために使用されます。

ARGビルド番号
ARG gitcommithash

RUN echo "ビルド番号: $buildno" # bash のようなスタイル RUN echo "コミットに基づく: $gitcommithash"

リストまたはマップを使用して引数を設定できます

建てる：
 コンテクスト： 。
 引数: # マップ
  ビルド番号: 1
  gitcommithash:cdc3b19 さん

建てる：
 コンテクスト： 。
 引数: # リスト
  -ビルド番号=1
  -gitcommithash=cdc3b19 翻訳:

ヒント
ブール値を使用する必要がある場合は、パーサーがそれらを文字列として解析できるように、二重引用符 ("true"、"false"、"yes"、"no"、"on"、"off") を使用する必要があります。

キャッシュ元

ビルドプロセスのキャッシュを指定する

建てる：
 コンテクスト： 。
 キャッシュ元:
  - アルパイン:最新
  -corp/web_app:3.14

ラベル

DockerfileのLABEL命令と同じで、イメージのメタデータを設定する

建てる：
 コンテクスト： 。
 ラベル: # マップ
  com.example.description: 「会計 Web アプリ」
  com.example.department: 「財務」
  com.example.ラベルに空の値: ""

建てる：
 コンテクスト： 。
 ラベル: # リスト
  - "com.example.description=会計ウェブアプリ"
  - "com.example.department=財務"
  - 「com.example.label-空の値」

ネットワーク

docker --networkコマンドと同様に、コンテナのネットワークを指定します。LANブリッジを設定すると、3つのモードで2つの物理LANを接続できると理解しています

建てる：
 コンテクスト： 。
 ネットワーク: ホスト # ホストモードでは、ネットワークの遅延が最も低く、パフォーマンスはホストマシンと一致します

建てる：
 コンテクスト： 。
 network: custom_network_1 # カスタムネットワーク

建てる：
 コンテクスト： 。
 ネットワーク: なし # ネットワークなし

shm_サイズ

コンテナ内の/dev/shmディレクトリのサイズを設定する

/dev/shmディレクトリは非常に重要です。このディレクトリはハードディスク上ではなく、メモリ上にあります。デフォルトのサイズはメモリの半分のサイズです。ここに保存されたファイルはクリアされません。コンテナ内でこのディレクトリを分割することで、コンテナのパフォーマンスをある程度指定できます。

建てる：
 コンテクスト： 。
 shm_size: '2gb' # 文字列を使用してサイズを設定します

建てる：
 コンテクスト： 。
 shm_size: 10000000 # バイトサイズを設定する

指示

DockerfileのCMDコマンドと同等

コマンド: bundle exec thin -p 3000 # シェルのような

コマンド: ["bundle", "exec", "thin", "-p", "3000"] # json形式

コンテナ名

docker run --nameと同等

コンテナ名: my-web-container

依存する

サービス間の依存関係を表現するために使用される

docker-compose up実行すると、起動順序はdepends_onに従って決定されます。

バージョン: "3.8"
サービス:
 ウェブ：
  建てる： 。
  depends_on: # 最初に db と redis を起動します
   -db
   - レディス
 レディス:
  画像: redis
 デシベル:
  画像: postgres

ヒント:
Docker-compose は、起動前に、depends_on 内のコンテナのステータスが「準備完了」になるまで待機しないため、起動が完了した後にコンテナのステータスを確認する必要があります。公式の解決策は、シェル スクリプトを使用して問題を解決することですが、ここでは詳しく説明しません。

depends_on は、Web を起動する前に db と redis が「準備完了」になるまで待機しません。起動されるまで待機するだけです。サービスが準備完了になるまで待機する必要がある場合は、この問題の詳細と解決方法については、「起動順序の制御」を参照してください。
---- https://docs.docker.com/comp... からアクセス

デバイス

マウントされた外部デバイス--devicesと同じ

デバイス:
 - "/dev/ttyUSB0:/dev/ttyUSB0"

ドメイン名

カスタムDNSアドレス

dns: 8.8.8.8 # 単一の文字列値

dns: # リスト 
 - 8.8.8.8
 - 9.9.9.9

dns_検索

DNS検索ドメイン名をカスタマイズする

dns_search: example.com # 単一の文字列値

dns_検索:
 - dc1.example.com
 dc2.example.com の URL は http://www.dc2.example.com/ です。

エントリポイント

デフォルトのエントリポイントを上書きする

エントリポイント: /code/entrypoint.sh

Dockerfileと同じ

エントリポイント: ["php", "-d", "memory_limit=-1", "vendor/bin/phpunit"]

ヒント:
docker-compose.yamlのentrypointは、Dockerfile 内のCMDコマンドをクリアし、Dockerfile 内のすべてのENTRYPOINT命令をオーバーライドします。

環境ファイル

環境変数ファイルをdocker-compose.yamlに追加します。 docker-compose -f FILEでコンポーズファイルを設定する場合、 env_fileのファイルパスはFILEに対する相対パスになります。

env_file: .env # 単一の値

env_file: # リスト
 - ./common.env
 - ./apps/web.env
 - /opt/runtime_opts.env

ヒント:
.env ファイル形式:

# Rails/Rack環境を設定する # '#'はコメントです。
# 空行は無視されます RACK_ENV=development # 形式は VAR=VAL です

.env ファイル内の環境変数は、ビルド プロセス中に明示的に読み取ることはできません。docker-compose.yaml ファイルによってのみ読み取られます。ビルド中に環境変数を使用する必要がある場合は、ビルド後に args サブパラメータを追加します。

複数の.envファイルを指定するには、公式サイトには非常に複雑なこの文章があります

リスト内のファイルの順序は、複数回表示される変数に割り当てられる値を決定する上で重要であることに注意してください。
---https://docs.docker.com/comp... より

直訳すると

リスト内のファイルの順序は、複数回出現する変数に割り当てられる値を決定する上で重要であることに注意してください。

環境パラメータ ファイルは上から下に処理されるため、複数のパラメータ ファイルに同じ環境変数が含まれている場合は、最後のパラメータ ファイルが優先されます。

環境

環境変数を追加する

環境: # マップ
 RACK_ENV: 開発
 表示: 'true'
 セッションシークレット:

環境: # リスト
 - RACK_ENV=開発
 - 表示=true
 -セッションシークレット

ヒント:
.env ファイル内の環境変数は、ビルド プロセス中に明示的に読み取ることはできません。docker-compose.yaml ファイルによってのみ読み取られます。ビルド中に環境変数を使用する必要がある場合は、ビルド後に args サブパラメータを追加します。
この環境変数は、イメージをビルドするときに独自のコードによって読み取ることができます。次に例を示します。

getEnvInfo()関数文字列{
  rackEnv := os.Getenv("RACK_ENV")
  fmt.Println(ラック環境)
}

出力：
発達

さらす

ポートを公開しますが、サービス間の通信にのみ使用します。公開されるのは内部ポートであり、DockerfileのEXPOSE命令に似ています。

さらす：
 - 「3000」
 - 「8000」

外部リンク

接続サービス

外部リンク:
 - レディス1
 - プロジェクトdb_1:mysql
 - プロジェクトdb_1:postgresql

ヒント:
公式の推奨はnetworkを使用することです

追加ホスト

--add-hostと同様にカスタムドメイン名を追加します

追加ホスト:
 - "somehost:162.242.195.82"
 - 「その他のホスト:50.31.209.229」

コンテナ内の/etc/hostsファイルに書き込むこともできます

162.242.195.82 誰かホスト
50.31.209.229 その他のホスト

健康チェック

DockerfileのHEALTHCHECK命令と同じ

ヘルスチェック:
 テスト: ["CMD", "curl", "-f", "http://localhost"]
 間隔: 1分30秒
 タイムアウト: 10秒
 再試行: 3
 開始期間: 40秒

disabel: trueを使用します。これはtest: ["NONE"]と同等です。

ヘルスチェック:
 無効: true

画像

プルまたは使用するイメージを指定します。倉庫/標簽または部分的なイメージ ID を使用することもできます。

画像: redis #デフォルトラベル最新
イメージ: ubuntu:18.04
画像: tutum/influxdb
イメージ: example-registry.com:4000/postgresql
画像: a4bc65fd

初期化

コンテナ内で init プログラムを実行し、プロセスを開始するための信号を転送します。

バージョン: "3.8"
サービス:
 ウェブ：
  画像: アルパイン:最新
  初期化: 真

ヒント:
使用されるデフォルトの init バイナリは Tini であり、デーモン ホストの /usr/libexec/docker-init にインストールされます。 init-path 構成オプションを使用して、カスタム init バイナリを使用するようにデーモンを構成できます。

分離

コンテナ分離技術を指定します。Linuxはdefaultの のみをサポートし、Windowsはdefault `process をサポートします。 hypervの3つの値の詳細については、Docker Engine Docsを参照してください。

ラベル

DockerfileのLABEL命令と同じで、コンテナのメタデータを設定する

建てる：
 コンテクスト： 。
 ラベル: # マップ
  com.example.description: 「会計 Web アプリ」
  com.example.department: 「財務」
  com.example.ラベルに空の値: ""

建てる：
 コンテクスト： 。
 ラベル: # リスト
  - "com.example.description=会計ウェブアプリ"
  - "com.example.department=財務"
  - 「com.example.label-空の値」

リンク

古いバージョンの機能なので、推奨されません

ログ記録

現在のサービスの毎日のパラメータを設定する

ログ記録:
 ドライバー: syslog
 オプション:
  syslog アドレス: "tcp://192.168.0.42:123"

driverパラメータは--log-driverコマンドと同じです

ドライバー: "json-file"
ドライバー: "syslog"
ドライバー:「なし」

ヒント:
json-fileとjournaldが使用されている場合にのみ、 docker-compose upとdocker-compose logs がログを見ることができます。他のドライバーはログの印刷を見ることができません。

docker run --log-optと同じようにログ設定を指定します。形式は kv 構造です。

ドライバー: "syslog"
オプション:
 syslog アドレス: "tcp://192.168.0.42:123"

デフォルトのログドライバーはjson-fileで、ストレージ制限を設定できます。

オプション:
 max-size: "200k" # 単一ファイルの最大ストレージ max-file: "10" # ファイルの最大数

ヒント:
上記のoptionパラメータは、 json-fileログ ドライバーでのみサポートされます。ドライバーによってサポートされるパラメータは異なります。詳細については、次の表を参照してください。

サポートされているドライバーのリスト

ヒント:
詳細については、ログドライバの設定を参照してください。

ポート

外部に露出したポート

短い構文:
両方のポートHOST:CONTAINERを指定するか、コンテナ ポートのみを指定します (一時的なホスト ポートが選択されます)。

ポート:
 - 「3000」
 - 「3000-3005」
 - 「8000:8000」
 - 「9090-9091:8080-8081」
 - 「49100:22」
 - 「127.0.0.1:8001:8001」
 - 「127.0.0.1:5000-5010:5000-5010」
 - 「6060:6060/udp」
 - 「12400-12500:1240」

ヒント:
HOST:CONTAINER形式でポートをマッピングする場合、60 未満のコンテナー ポートを使用すると、YAML がxx:yy形式の数字を 60 進数 (時間として理解できる) として解釈するため、エラーが発生する可能性があります。したがって、ポート マッピングは常に文字列として明示的に指定することをお勧めします。

長い構文

長い構文では、短い構文では許可されないフィールドが許可されます

• target: コンテナ内のポート
• 公開済み: 公開ポート
• プロトコル: ポート プロトコル (tcp または udp)
• mode: host は各ノードのホスト ポートを公開し、ingress はクラスター モード ポートの負荷を分散します。

ポート:
 - 目標: 80
  公開: 8080
  プロトコル: tcp
  モード: ホスト

再起動

コンテナ再起動ポリシー

restart: "no" # 失敗時に再起動しない restart: always # 失敗後に常に再起動する restart: on-failure # エラーコードが on-failure の場合にのみ再起動する restart: until-stopped # 手動停止後に再起動しない

秘密（追加予定）

ボリューム

データボリュームをマウントするために使用

短い構文
短い構文は最も単純な形式[SOURCE:]TARGET[:MODE]を使用します

• SOURCEホスト アドレスまたはデータ ボリューム名にすることができます。
• TARGETはコンテナ内のパスです。
• MODEにはread-onlyのroとread-writeのrw （デフォルト）が含まれます。

ホストへの相対パスを使用する場合は、 docker-compose.yamlを展開します。

ボリューム:
 #コンテナ内のパスを指定すると、Docker は自動的にパスを作成します - /var/lib/mysql

 #マウント絶対パス - /opt/data:/var/lib/mysql

 # 相対パスをマウント - ./cache:/tmp/cache

 # ユーザーディレクトリの相対パス - ~/configs:/etc/configs/:ro

 # 名前付きマウント - datavolume:/var/lib/mysql

長い構文

長い構文を使用すると、短い構文では表現できないフィールドを使用できます。

• type : インストール タイプ、 bind 、 tmpfs 、またはnpipe source : マウント ソース。最上位のマウント設定で設定されたホスト パスまたはボリューム名になります。 tmpfs はマウントtargetに適していません: コンテナ内のマウントパスはread_only : マウントパスを読み取り専用に設定します
• bind : 追加のバインド設定を構成する
  • propagation : バインディングの伝播モードを設定するために使用されます
• volume : 追加のマウント構成を構成する
  • nocopy : ボリューム作成時にコンテナからのデータのコピーを無効にする
• tmpfs : 追加のtmpfs設定を構成する
  • size : マウントされたtmpfsのサイズを設定します（バイト）
• consistency : マウントの一貫性要件。一貫性 (ホストとコンテナのビューが同じ)、キャッシュ (読み取りキャッシュ、ホスト ビューが権限を持つ)、委任 (読み取り/書き込みキャッシュ、コンテナ ビューが権限を持つ) のいずれかになります。

バージョン: "3.8"
サービス:
 ウェブ：
  画像: nginx:alpine
  ポート:
   - 「80:80」
  ボリューム:
   - タイプ: ボリューム
    出典: マイデータ
    ターゲット: /data
    音量：
     コピーなし: true
   - タイプ: バインド
    ソース: ./static
    ターゲット: /opt/app/static

ネットワーク:
 ウェブネット:

ボリューム:
 マイデータ:

docker compose の記述ルールに関するこの記事はこれで終わりです。docker compose の記述ルールに関するより関連性の高いコンテンツについては、123WORDPRESS.COM の過去の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。