Docker-Composeの上級バージョンについてお話しましょう

Docker-Composeの上級バージョンについてお話しましょう

1. 概要

docker-compose プロジェクトは、docker の公式オープン ソース プロジェクトであり、docker コンテナ クラスターの迅速なオーケストレーションを実現して、コンテナを簡単かつ効率的に管理し、複数のコンテナを定義および実行することを担当しています。

  • Docker-compose は、管理対象コンテナをプロジェクト、サービス、コンテナの 3 つのレイヤーに分割します。
  • docker-compose 実行ディレクトリ内のすべてのファイル (docker-compose.yml ファイル、extends ファイル、環境変数など) がプロジェクトを形成します。特別な指定がない場合は、プロジェクト名は現在のディレクトリ名になります。
  • プロジェクトには複数のサービスを含めることができ、各サービスはコンテナ操作のイメージ、パラメーター、依存関係を定義します。
  • サービスには複数のコンテナ インスタンスを含めることができますが、docker-compose では負荷分散の問題が解決されません。したがって、サービス検出と負荷分散を実現するには、consul などの他のツールが必要です。
  • docker-compose のデフォルトのプロジェクト構成ファイルは docker-compose.yml です。環境変数 COMPOSE_FILE -f パラメータを使用して構成ファイルをカスタマイズできます。これにより、複数の依存サービスと各サービスが実行されるコンテナがカスタマイズされます。

公式ドキュメント: https://docs.docker.com/compose/

GitHub: https://github.com/docker/compose/releases/

以前、Docker Compose の基礎について記事を書きました。興味があれば、ぜひチェックしてみてください: Docker の三銃士の作品

2. ComposeとDockerの互換性

Compose ファイル形式には、1、2、2.x、3.x という複数のバージョンがあります。次の表は、Compose ファイルでサポートされている特定の Docker ディストリビューションを示しています。

3. Dockerをインストールする

 # yum - config - manager設定ツールをインストールします
yum - y インストール yum - utils

 # Alibaba Cloud yum ソースを使用することをお勧めします: (推奨)
 #yum - config - manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
 yum - config - manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

 # docker - ce バージョンをインストール
yum インストール-y docker -ce
 # 起動して起動
systemctl enable --now docker
 docker --バージョン

4. docker-composeをインストールする

公式インストールチュートリアル: https://docs.docker.com/compose/install/other/ 

 curl - SL https://github.com/docker/compose/releases/download/v2.16.0/docker-compose-linux-x86_64-o/usr/local/bin/docker-compose

 chmod + x / usr / bin / docker -作成
docker - compose --version

5. 環境変数

Docker Compose を使用すると、さまざまな方法でサービスの環境変数を設定できます。これらの環境変数は、アプリケーションを構成したり、機密情報をコンテナーに渡したりするために使用できます。

Docker Compose 環境変数を設定する方法はいくつかあります。

1) docker-compose.ymlファイルで環境変数を設定する

docker-compose.yml ファイルでサービスごとに環境変数を設定できます。サービス構成では、environment キーワードを使用して、設定する必要がある環境変数とその値をリストします。 

サービス:
 ウェブ:
 画像: nginx
 環境：
 MY_VAR :私の値

2) .envファイルから環境変数を読み取る

環境変数を .env​ ファイルに保存し、Docker Compose に読み取らせることができます。 docker-compose.yml​ ファイルで、env_file​ キーワードを使用して、.env ファイルへのパスを指定します。 

サービス:
 ウェブ:
 画像: nginx
 環境ファイル:
 - .env

3) シェル環境変数の使用

docker-compose コマンドを起動するときに、シェル環境変数を使用して環境変数値を渡すこともできます。例えば： 

 $ エクスポート MY_VAR = my_value
 $ docker -作成する

シェル環境変数を参照するには、docker-compose.yml ファイルで ${MY_VAR} 構文を使用します。 

サービス:
 ウェブ:
 画像: nginx
 環境：
 MY_VAR : $ { MY_VAR }

環境変数を使用すると、アプリケーションの柔軟性が向上し、機密情報の管理が容易になります。

6. 配置のフィールドの詳細な説明

Docker Compose オーケストレーション ファイルには、理解しておくべき重要なフィールドがいくつかあります。

1) バージョン

version​ フィールドは、Docker Compose オーケストレーション ファイルのバージョンを指定します。現在の最新バージョンは3です。 

バージョン: '3'

2) サービス

services フィールドは、Docker Compose オーケストレーションで実行するサービスを指定します。各サービスには名前があり、使用するイメージとコンテナの構成オプションを指定します。以下は単純なサービス構成の例です。 

サービス:
 ウェブ:
 建てる： 。
 ポート:
 - 「5000:5000」
 レディス:
 画像: "redis:alpine"

3) ビルドとイメージ

1. 構築する

ビルド フィールドを使用すると、Docker Compose オーケストレーション内の Dockerfile の場所を指定して、Docker Compose を使用してイメージをビルドできます。たとえば、ローカル Dockerfile を使用する例を次に示します。 

サービス:
 ウェブ:
 建てる： 。

Dockerfile を含むディレクトリを指定することもできます。 

サービス:
 ウェブ:
 ビルド: ./my-web-app

2. 画像

イメージ フィールドは、使用する Docker イメージを指定します。例えば： 

サービス:
 ウェブ:
 画像: nginx

[ヒント] ビルドとイメージのどちらかを選択することも、両方を同時に書き込むこともできますが、通常はイメージのみを選択します。 

バージョン: '3.8'
サービス:
 ウェブ:
 ビルド: ./web
 画像: myapp /ウェブ:最新

上記の構成では、サービス名を web、Dockerfile パスを ./web、イメージ名を myapp/web​、タグを latest​ に指定しています。 docker-compose build コマンドを実行すると、myapp/web:latest という名前のイメージが自動的にビルドされます。

4) ネットワーク

ネットワーク フィールドは、使用するネットワークを指定します。デフォルトでは、Docker Compose は default というネットワークを作成します。以下はカスタム ネットワークを使用した例です。 

ネットワーク:
 私のネットワーク:
 ドライバー: ブリッジ

5) ボリューム

ボリューム フィールドは、使用するデータ ボリュームを指定します。以下はデータ ボリュームの使用例です (詳細は後述)。 

巻数:
 私の-ボリューム:
 ドライバー：地元

6) 環境と環境ファイル

1. 環境

環境フィールドは、設定する環境変数を指定します。環境変数を使用する例を次に示します。 

環境：
 MY_VAR :私の値

2. 環境ファイル

environment_file: ファイルから環境変数を読み取ることを指定します。 

環境ファイル: .env

7) ポートと公開

1. ポート

ports フィールドは、コンテナーにマップするホスト上のポートを指定します (ホスト ポート:コンテナー ポート)。以下はポート マッピングを使用する例です。 

ポート:
 - 「8080:80」

2. 公開する

expose フィールドは、Docker コンテナ内のポートを公開するためのオプションであり、他のコンテナがそれらのポートに接続できるようにしますが、それらを Docker ホストにマッピングすることはありません。

docker-compose.yml ファイルの expose オプションを使用して、コンテナ内で公開する必要があるポートを指定します。たとえば、次の例では、ポート 8000 と 8080 を公開する Web サービスを定義します。 

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 さらす：
 - 「8000」
 - 「8080」

公開オプションを使用すると、他のコンテナは Docker の内部ネットワークを使用して接続できます。たとえば、Web サービスのポート 8000 に接続する必要がある別のサービス ワーカーがある場合は、ワーカー サービスの docker-compose.yml ファイルで links オプションを使用できます。 

バージョン: '3'
サービス:
 労働者:
 画像: myworker :最新
 リンク:
 -ウェブ

8) 依存する

depends_on フィールドは、サービス間の依存関係を指定します。たとえば、Web サービスが db サービスに依存している場合は、次の例を使用できます。 

依存:
 -db

9) 再起動

Docker Compose は、コンテナが失敗した場合に自動的に再起動するためのいくつかの再起動戦略を提供します。次の再起動戦略が利用可能です。

  • no: コンテナを再起動しません。コンテナが停止した場合、Compose はコンテナを自動的に再起動しようとしません。 (デフォルトポリシー)
  • always: コンテナが停止した場合、Compose は自動的にコンテナを再起動します。 （一般）
  • on-failure: コンテナは、ゼロ以外の終了コードで停止した場合にのみ再起動されます。
  • until-stopped: 手動で停止しない限り、常にコンテナを再起動します。これは、docker run コマンドを使用するときに --restart=unless-stopped フラグを使用するのと同じです。

これらの戦略は、docker-compose.yml ファイルで restart キーを使用して指定できます。次に例を示します。 

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 再起動:常に

この例では always ポリシーを使用します。つまり、Web コンテナーが停止すると、Compose によって自動的に再起動されます。

10) コマンド

コマンド フィールドは、ニーズや好みに応じて、コンテナーの起動時に実行されるコマンドを指定するためにさまざまな方法で記述できます。一般的な例をいくつか挙げます。

1. 文字列形式

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 コマンド: python manage .py runserver 0.0 .0 .0 : 8000

この例では、コマンド フィールドの値は、実行されるコマンドとそのパラメータを表す文字列です。

2. リスト形式

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 指示：
 -パイソン
-管理.py
 -runserver
 - 0.0.0.0:8000

この例では、コマンド フィールドの値はリストであり、各要素は実行されるコマンドまたはパラメーターを表します。

3. シェルコマンド形式

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 # 2つの書き方
 # コマンド: sh - c "python manage.py runserver 0.0.0.0:8000"
 コマンド: [ "sh" 、 "-c" 、 "python manage.py runserver 0.0.0.0:8000" ]

4. 環境変数を使用する

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 環境：
 -環境=生産
 コマンド: python manage .py runserver 0.0 .0 .0 : $ { PORT }

この例では、コマンド フィールドの ${PORT}​ は、Web サービスの環境変数 PORT の値に置き換えられます。

11) 健康チェック

healthcheck: コンテナのヘルスチェック構成を指定します。 

ヘルスチェック:
 テスト: [ "CMD" 、 "curl" 、 "-f" 、 "http://localhost/health" ]
 間隔: 30秒
 タイムアウト: 10秒
 再試行回数: 3

上記の例では、コンテナのヘルスチェック コマンドは「curl -f http://localhost/health」として構成されており、30 秒ごとにチェックされ、タイムアウトは 10 秒、再試行は最大 3 回です。

12) 設定と秘密

1. 構成

configs: コンテナで使用される構成ファイルを指定します。 

設定:
 -ソース: my - config
 ターゲット: /etc/nginx/conf.d/default.conf

上記の例では、my-config という名前の設定ファイルがコンテナの /etc/nginx/conf.d/default.conf ディレクトリにコピーされます。

2. 秘密

secrets: コンテナで使用される秘密データを指定します。 

秘密:
 -db_パスワード

13) ホスト名とコンテナ名

hostname​ と container_name はどちらも Docker コンテナを定義するために使用される識別子ですが、意味が異なります。

1. ホスト名

hostname は、コンテナ内で使用できる名前であるコンテナのホスト名を設定するために使用されます。たとえば、コンテナ内で ping hostname コマンドを使用すると、コンテナの IP アドレスが解決されます。ホスト名は次の形式で設定できます。 

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 コンテナ名: myapp

この例では、Web サービスのコンテナ ホスト名は myapp-container に設定されています。

2. コンテナ名

container_name はコンテナに名前を付けるために使用され、これは Docker ホストで使用される名前です。コンテナ名は次の形式で設定できます。 

バージョン: '3'
サービス:
 ウェブ:
 画像: myapp :最新
 コンテナ名: myapp

この例では、Web サービスのコンテナー名は myapp に設定されています。

つまり、hostname と container_name はどちらもコンテナを定義するために使用される識別子ですが、hostname はコンテナ内の識別に使用され、container_name は Docker ホスト上の識別に使用されます。

14) ユーザー

Docker Compose では、ユーザー フィールドを使用して、コンテナー内で実行されているプロセスのユーザーとグループを指定できます。その構文は docker run​ コマンドの --user オプションに似ており、次の 3 つの形式があります。

1. ユーザー:グループ (推奨)

コンテナ内のプロセスを、ユーザー user およびグループ user group として実行します。例: 

バージョン: "3"
サービス:
 ウェブ:
 画像: nginx
 ユーザー: nginx : nginx

2. uid:gid

コンテナ内のプロセスを uid ユーザー ID および gid グループ ID として実行します。例: 

バージョン: "3"
サービス:
 ウェブ:
 画像: nginx
 ユーザー: 「1000:1000」

3. ユーザー

コンテナ内のプロセスをユーザー user として実行します。例: 

バージョン: "3"
サービス:
 ウェブ:
 画像: nginx
 ユーザー: nginx

Docker Compose でユーザー フィールドが使用されている場合、コンテナー内のすべてのプロセスはデフォルトのルート ユーザーではなく、指定されたユーザーとして実行されることに注意することが重要です。これにより、コンテナのセキュリティが向上し、コンテナ内でルート ユーザーを使用することによって発生する潜在的なセキュリティ リスクを回避できます。

15) 展開する

deploy: サービスのデプロイメント構成を指定します。 

展開する：
 レプリカ: 3
 リソース：
 制限:
 CPU : '0.5'
 メモリ: '256M'
 予約:
 CPU : '0.25'
 メモリ: '128M'

上記の例では、構成サービスのレプリカの数は 3 で、各レプリカが使用する CPU およびメモリ リソースは制限されており、一部のリソースは他のサービス用に予約されています。

7. ポートとエクスポーズの違い

ports​ と expose は、コンテナー内のポートを公開するために使用される 2 つの異なる Docker Compose フィールドです。

  • ポート フィールドは、コンテナ内のポートをホスト上のポートにマッピングするために使用されます。これにより、外部ネットワークはホスト上のポートを介してコンテナ内で実行されているアプリケーションと通信できるようになります。このフィールドの構文は次のとおりです。 
バージョン: "3"
サービス:
 ウェブ:
 画像: nginx
 ポート:
 - 「8080:80」

この例では、コンテナ内で実行されている nginx プロセスはコンテナ内のポート 80 をリッスンし、ports フィールドはホスト上のポート 8080 をコンテナ内のポート 80 にマッピングします。このようにして、外部ネットワークはホストのポート 8080 にアクセスすることで、コンテナ内で実行されている nginx アプリケーションにアクセスできるようになります。

  • expose​ ポートとは異なり、expose フィールドは、ホスト上のポートに直接マッピングするのではなく、コンテナー内のポートを他のコンテナーに公開して使用できるようにします。このフィールドの構文は次のとおりです。 
バージョン: "3"
サービス:
 デシベル:
 画像: mysql
 さらす：
 - 「3306」
 ウェブ:
 画像: nginx
 さらす：
 - 「80」

この例では、db コンテナーと web コンテナーはそれぞれ内部ポート 3306 と 80 を公開しており、他のコンテナーはこれらのポートを使用してそれらのコンテナーと通信できます。ただし、これらのポートはホスト マシンにマップされていないため、外部ネットワークから直接アクセスすることはできません。外部ネットワークからこれらのコンテナにアクセスする場合は、ポート フィールドを使用して、それらをホスト マシン上のポートにマップする必要があります。

8. 設定とシークレットの違い

Configs と Secrets は、コンテナ構成と機密データを管理するための Docker Compose と Docker Swarm の 2 つの異なる機能です。それらの違いは次のとおりです。

  • さまざまな用途: configs は、nginx 構成ファイル、MySQL 構成ファイルなどのコンテナ アプリケーションの構成ファイルを管理するために使用されます。一方、secrets は、データベース パスワード、API キーなどの機密データを管理するために使用されます。
  • 異なる保存場所: 構成は Docker ホストのファイル システム (ローカル ファイル システム、NFS ファイル システム、またはリモート S3 ストレージ) に保存されますが、シークレットは Docker Swarm の安全なストレージに保存されます。このストレージは暗号化されており、安全性が高く、承認された Docker サービスとノードのみがアクセスできます。
  • アクセス方法は異なります。configs にはファイルマウントまたは Docker Compose ファイルの configs フィールドを介してアクセスできますが、secrets にはファイルマウント、Docker Compose ファイルの secrets フィールド、Docker CLI の docker secret コマンド、またはコンテナー内のファイルシステムを介してアクセスできます。
  • 異なるライフサイクル: 構成のライフサイクルはサービスから独立しています。サービスが停止しても、構成ファイルはホスト上に残ることがあります。シークレットのライフサイクルはサービスにバインドされます。サービスが削除されると、機密データも削除されます。
  • 更新方法は異なります。構成はサービスを再デプロイすることによって更新されますが、シークレットは Docker CLI の docker secret コマンドまたはコンテナ内のファイル システムを通じて更新されます。

以下は、configs​ と secrets を使用する Docker Compose ファイルの例です。 

バージョン: '3.7'

サービス:
 ウェブ:
 画像: nginx :最新
 ポート:
 - 80 : 80
 設定:
 -ソース: nginx_conf
 ターゲット: /etc/nginx/nginx.conf
 秘密:
 -ソース: db_password
 ターゲット: / run / secrets / db_password

設定:
 nginx_conf :
 ファイル: ./nginx.conf

秘密:
 db_パスワード:
 ファイル: ./db_password.txt

上記の例では、nginx:latest イメージを使用し、コンテナ内のポート 80 を Docker ホストのポート 80 にマッピングする Web サービスを定義しました。さらに、configs と secrets という 2 つの構成も定義しました。

  • configs​ は nginx_conf と呼ばれる構成を定義します。これは、ローカルの nginx.conf ファイルから構成を読み取り、コンテナー内の /etc/nginx/nginx.conf パスにマウントします。このように、カスタマイズされた nginx.conf 構成ファイルを使用して nginx サービスを構成することができます。
  • secrets​ は db_password という名前の機密データを定義します。これはローカルの db_password.txt ファイルから読み取られ、コンテナー内の /run/secrets/db_password パスにマウントされます。こうすることで、パスワード漏洩のリスクを心配することなく、コンテナ内のデータベース パスワードに安全にアクセスできるようになります。

上記の例では、ファイルマウントを使用して構成とシークレットにアクセスしました。これは最も一般的なアクセス方法ですが、唯一の方法ではありません。シークレットには、Docker CLI の docker secret コマンド経由で、またはコンテナのファイルシステム内からアクセスすることもできます。

9. マウント

Docker Compose では、ホスト ディレクトリまたはファイルをマウントすることでコンテナー内のファイルまたはディレクトリにアクセスできるため、コンテナーの内外でデータまたは構成ファイルを共有できます。 Docker Compose は 2 つのマウント方法をサポートしています。

1) 名前付きボリュームのマウント

名前付きボリュームは、Docker によって作成および管理されるボリュームです。永続的なデータを保存するために使用でき、複数のコンテナ間で共有できます。 Docker Compose では、ボリューム フィールドを使用して、名前付きボリュームのマウント パスとホスト ディレクトリ間のマッピングを定義できます。 Docker ボリューム管理の詳細については、私の記事「Docker データ ボリューム - ボリューム」を参照してください。例: 

バージョン: "3.7"

サービス:
 アプリ：
 画像: myapp :最新
 巻数:
 - myapp_data : / app /データ

巻数:
 マイアプリデータ:

上記の例では、myapp:latest イメージを使用し、名前付きボリューム myapp_data をコンテナー内の /app/data ディレクトリにマウントする myapp サービスを定義します。

2) ホストディレクトリのマウント

ホスト ディレクトリ マウントを使用すると、Docker ホスト上のディレクトリまたはフォルダーをコンテナーにマウントして、コンテナー間でデータを共有できるようになります。 Docker Compose では、ボリューム フィールドを使用して、ホスト ディレクトリのマウント パスとホスト ディレクトリ間のマッピングを定義できます。例えば： 

バージョン: "3.7"

サービス:
 アプリ：
 画像: myapp :最新
 巻数:
 - /ホスト/データ: /アプリ/データ

上記の例では、myapp:latest イメージを使用し、ホスト上の /host/data ディレクトリをコンテナ内の /app/data ディレクトリにマウントする myapp サービスを定義します。

[注意] Docker Compose では、ホスト ディレクトリを使用してマウントする場合、ホスト ディレクトリが存在し、適切な権限を持っている必要があります。そうしないと、コンテナはディレクトリにアクセスできなくなります。また、ホストディレクトリマウントを使用する場合は、データ漏洩のリスクを回避するために、マウントされたディレクトリに機密データが含まれているかどうかに注意してください。

10. ネットワーク

Docker Compose のネットワークを使用して、複数のコンテナ間の通信を確立できます。ネットワークを定義することで、コンテナはホスト ネットワークから分離しながら相互に通信できるようになり、コンテナ アプリケーションのセキュリティが向上します。実際、私の以前の記事も参照してください: 4 つの Docker ネットワーク モード (ブリッジ、ホスト、コンテナー、なし)

Docker Compose には、ブリッジ、ホスト、なしの 3 つのネットワーク タイプが用意されており、それぞれ異なるシナリオに適しています。

1) ブリッジネットワークタイプ

ブリッジ ネットワーク タイプはデフォルトのネットワーク タイプであり、ブリッジ ネットワークを作成してコンテナーが相互に通信できるようにします。各コンテナには独自の IP アドレスがあり、コンテナ名で相互にアクセスできます。ネットワーク タイプが指定されていない場合、Docker Compose はブリッジ ネットワーク タイプを使用します。

ブリッジ ネットワーク タイプでは、Docker Compose は各サービスに対してコンテナーを作成し、各コンテナーに IP アドレスを割り当てます。同じネットワーク内のコンテナは相互にアクセスできます。

注: Docker Compose のネットワーク機能を使用する場合 (ネットワークはデフォルトで作成されます)、同じネットワーク内の任意のコンテナからコンテナ名を使用してサービスにアクセスできます。 Docker Compose ネットワークを使用していない場合は、ネットワークを手動で作成し、すべてのコンテナを同じネットワークに追加する必要があります。

[例] web と db という 2 つのサービスがあるとします。デフォルトでは、Docker Compose はブリッジ ネットワーク タイプを使用するため、特定のネットワーク タイプを指定する必要はありません。以下は docker-compose.yml ファイルのサンプルです。 

バージョン: '3'
サービス:
 ウェブ:
 建てる： 。
 ポート:
 - 「80:80」
 デシベル:
 画像: mysql : 5.7
 環境：
 MYSQL_ROOT_PASSWORD :例

上記の例では、Web サービスはローカル Dockerfile を使用して構築され、コンテナ ポート 80 がホスト ポート 80 にマップされます。db サービスは MySQL 5.7 イメージを使用し、MySQL ルート ユーザー パスワードを example に設定します。

この例は、docker-compose up コマンドで開始します。 Docker Compose は各サービスにコンテナを作成し、サービスが相互に通信できるようにデフォルトのブリッジ ネットワークを自動的に作成します。

2) ホストネットワークタイプ

ホスト ネットワーク タイプでは、コンテナーがホストのネットワーク スタックを共有できるため、コンテナーの IP アドレスとネットワーク インターフェイスはホストと同じになります。これにより、コンテナのネットワーク パフォーマンスとアクセシビリティが向上しますが、コンテナは同じネットワーク スタックを共有するため、相互にアクセスすることはできません。

ホスト ネットワーク タイプでは、Docker Compose は各サービスをホスト ネットワークに直接配置します。コンテナは IP アドレスとネットワーク インターフェイスをホストと共有するため、コンテナ内で実行されているサービスにはホスト IP アドレスを介してアクセスできます。

[例] ホスト ネットワーク インターフェイスを使用する必要があるサービスがあるとします。以下は docker-compose.yml ファイルのサンプルです。 

バージョン: '3'
サービス:
 ウェブ:
 建てる： 。
 ネットワークモード:ホスト

上記の例では、build キーワードを使用してビルド コンテキストを指定し、network_mode キーワードを使用してサービス web のネットワーク モードをホストに設定しています。このようにして、Web サービスは IP アドレスとネットワーク インターフェイスをホストと共有し、ホスト IP アドレスを通じてサービスにアクセスできるようになります。

3) ネットワークタイプなし

none ネットワーク タイプは、コンテナーにネットワーク リソースが割り当てられておらず、コンテナーにネットワーク インターフェイスがないことを意味します。これは通常、ホストと対話するだけでネットワーク接続を必要としないコンテナなど、特別なコンテナ シナリオで使用されます。

none ネットワーク タイプでは、Docker Compose は各サービスを個別のネットワーク名前空間に配置し、コンテナーにはネットワーク リソースがないため、ネットワーク経由で通信することはできません。

[例] ネットワーク接続を必要としないサービスがあるとします。以下は docker-compose.yml ファイルのサンプルです。 

バージョン: '3'
サービス:
 労働者:
 建てる： 。
 ネットワークモード:なし

上記の例では、build キーワードを使用してビルド コンテキストを指定し、network_mode キーワードを使用してサービス ワーカーのネットワーク モードを none に設定しています。この方法では、ワーカー サービスにはネットワーク リソースがなくなり、ネットワーク経由で通信できなくなります。

4) カスタムネットワーク

デフォルトでは、Docker Compose は Compose プロジェクトごとに 1 つのネットワークを作成します。このネットワークの名前の先頭には、Compose プロジェクト ディレクトリの名前が付けられます。たとえば、Compose プロジェクト ディレクトリの名前が myproject の場合、デフォルトで作成されるネットワークの名前は myproject_default になります。

  • このデフォルトで作成されたネットワークでは、すべてのサービスとコンテナはサービス名またはコンテナ名を介して通信できます。これらの名前はデフォルトで一意であるため、名前の競合や混乱を回避できます。
  • 別のネットワークまたはカスタム ネットワークにアクセスする必要がある場合は、Docker Compose の networks プロパティを使用してカスタム ネットワークを作成できます。たとえば、my_network というカスタム ネットワークを定義する Docker Compose ファイルは次のとおりです。 
バージョン: '3'
サービス:
 ウェブ:
 画像: nginx
 ネットワーク:
 -私のネットワーク

ネットワーク:
 私のネットワーク:
 ドライバー：ブリッジ

この例では、Web サービスは、作成されたデフォルトのネットワークではなく、my_network ネットワークに接続されます。このネットワークのネットワーク ドライバーは bridge です。これは、Docker Compose で使用されるデフォルトのネットワーク ドライバーです。

Compose プロジェクト ディレクトリ名の説明: Compose プロジェクト ディレクトリ名は、Docker Compose ファイルが含まれるディレクトリの名前を指します。 Docker Compose ファイル (通常は docker-compose.yml という名前) は、Docker Compose が Docker コンテナー アプリケーションをビルドおよび実行する方法を説明します。このファイルは通常、Compose プロジェクト ディレクトリのルートに保存されます。

たとえば、myapp というアプリケーションを開発していて、Docker Compose を使用してそのコンテナー化されたデプロイメントを管理する場合、Docker Compose ファイルを次のディレクトリ構造に保存します。 

マイアプリ/
 ├── docker - .ymlを作成する
├── アプリ/
 │ ├── Dockerファイル
│ └── app.py
 └──データ/

この例では、myapp は Compose プロジェクト ディレクトリの名前であり、docker-compose.yml は Compose ファイルの名前であり、myapp ディレクトリのルートに保存されます。 myapp ディレクトリには、アプリケーションのコード ディレクトリとデータ ディレクトリも含まれています。

11. ドメイン名解決 DNS

Docker Compose 内のコンテナは、IP アドレスの代わりにコンテナ名またはサービス名を使用して相互にアクセスできます。これは、Docker Compose が各サービスの DNS レコードを作成し、それがデフォルトの DNS リゾルバーによって処理されるためです。

デフォルトでは、Docker Compose は「projectname_default」というネットワークを作成し、すべてのサービスをこのネットワークに接続します。このネットワークは、Docker の組み込み DNS リゾルバを使用して、各サービスとコンテナに DNS 名を割り当てます。たとえば、Compose プロジェクトの名前が「myproject」の場合、次のコマンドですべてのサービスの DNS 名を表示できます。 

 docker - compose run <サービス> nslookup <サービス>

たとえば、サービス名が「web」の場合、次のコマンドを使用して Web サービスの DNS 名を表示できます。 

 docker - compose 実行 web nslookup web

これにより、IP アドレスと DNS 名を含む Web サービスの DNS レコードが出力されます。例えば： 

サーバー: 127.0.0.11
アドレス1 : 127.0.0.11

名前:ウェブ
住所1 : 172.18.0.2​

この例では、Web サービスの DNS 名は「web」、IP アドレスは 172.18.0.2 です。 IP アドレスを使用する代わりに、この名前 (「web」) を使用してサービスにアクセスできます。

12. 健康チェック

Docker Compose は、サービスが正常に実行されているかどうかを確認するためのサービスのヘルス チェックの定義をサポートしています。ヘルス チェックは、コマンド、HTTP リクエスト、または TCP ポートになります。ヘルスチェックが失敗した場合、Docker Compose は再試行の最大回数に達するか、サービスが正常に実行されるまで、サービスの再起動を試みます。

1) ヘルスチェック構文

Docker Compose では、healthcheck キーワードを使用してヘルスチェックを定義できます。具体的な構文は次のとおりです。 

ヘルスチェック:
 テスト: [ "CMD-SHELL" , "コマンド" ]
 間隔:間隔
 タイムアウト:タイムアウト
 再試行:再試行

パラメータの説明:

  • test はヘルスチェックのコマンドまたはリクエストです。
  • interval​ はヘルスステータスをチェックする時間間隔（秒単位）で、デフォルトは 30 秒です。
  • timeout​ はヘルスステータスをチェックするためのタイムアウト（秒単位）で、デフォルトは 30 秒です。
  • retries​ は、ヘルスチェックが失敗した場合に試行する再試行回数です。デフォルト値は 3 です。

2) 健康診断書の書き方

書き方はいくつかあります:

1. 文字列形式のコマンド

ヘルスチェック:
 テスト: curl --fail http://localhost:80 ||出口1
 間隔: 30秒
 タイムアウト: 10秒
 再試行回数: 5

上記の例では、healthcheck フィールドの test 属性は、実行されるヘルス チェック コマンドを表す文字列です。この例では、curl コマンドを使用して、localhost:80 にアクセスできるかどうかをテストします。ヘルス チェック コマンドがステータス コード 0 を返す場合、サービスは正常であることを意味し、それ以外の場合はサービスが異常であることを意味します。この例では、ヘルス チェックが失敗した場合、Docker Compose は 30 秒ごとにヘルス チェックの再実行を試行し、最大 5 回まで再試行します。

2. 配列形式のコマンド

ヘルスチェック:
 テスト：
 -CMD
 -カール
- - 失敗
- http : //ローカルホスト: 80
 間隔: 30秒
 タイムアウト: 10秒
 再試行回数: 5

3. カスタムコマンド

ヘルスチェック:
 テスト: [ "CMD-SHELL" , "curl --fail http://localhost:80 || exit 1" ]
 間隔: 30秒
 タイムアウト: 10秒
 再試行回数: 5

上記の例では、healthcheck フィールドの test 属性は配列であり、最初の要素は CMD-SHELL であり、コマンドがシェルを使用して実行されることを示しています。 2 番目の要素は、前の例と同じカスタム コマンドです。

3) CMD-SHELLとCMD

CMD-SHELL​ と CMD​ はどちらも、Dockerfile​ の RUN​ 命令と Docker Compose​ の healthcheck 命令でよく使用されるコマンド形式です。両者の違いは次のとおりです。

  • CMD-SHELL (ここで推奨): シェルを使用してコマンドを実行することを意味します。 Docker Compose では、ヘルスチェックのテスト プロパティで CMD-SHELL を使用して、カスタム シェル コマンドを実行できます。
  • CMD: 指定されたコマンドまたはコマンド パラメータを実行することを示します。 Dockerfile では、CMD はコンテナの起動時に実行されるコマンドを指定するためによく使用されますが、Docker Compose では、CMD はサービスの起動時に実行されるコマンドまたはコマンド パラメータを指定するためによく使用されます。

これら 2 つは使用方法が異なりますが、どちらもコマンドまたはコマンド パラメータを実行するために使用できます。 Dockerfile では、CMD-SHELL​ は有効な命令ではありません。 Docker Compose では、CMD を使用してサービスの起動コマンドを定義し、healthcheck​ の test 属性では CMD-SHELL を使用してカスタム シェル コマンドを実行できます。実際、CMD は docker compose healthcheck​ でも使用できます。 CMD-SHELL を使用することをお勧めします。

4) 例の説明

以下はヘルスチェックを定義するシンプルな Docker Compose ファイルです。 

バージョン: "3"
サービス:
 ウェブ:
 画像: nginx
 ポート:
 - 「80:80」
 ヘルスチェック:
 #テスト: [ "CMD" 、 "curl" 、 "-f" 、 "http://localhost" ]
 テスト: [ "CMD-SHELL" , "curl -f http://localhost" ]
 間隔： 1m
 タイムアウト: 10秒
 再試行回数: 3

この例では、Web サービスは nginx イメージを使用し、ポート 80 をホストのポート 80 にマッピングします。さらに、定期的に curl コマンドを実行して、サービスが HTTP リクエストに応答するかどうかをテストするヘルス チェックを定義します。具体的には、チェックは 1 分ごとに実行され、タイムアウトは 10 秒で、3 回再試行されます。

次のコマンドでサービスを開始できます。 

 # -fで docker - compose ファイルも指定します
docker -作成する

サービスが開始されると、Compose は定期的にヘルスチェックを実行し、チェック結果に基づいてサービスを再起動します。次のコマンドを使用して、サービスのヘルス ステータスを表示できます。 

 docker - ps を作成する

このコマンドは、サービスのヘルス ステータスを表示します。例: 

名前 コマンド 状態 ポート
------------------------------------------------------------------------------
 webapp_web_1 nginx -gデーモンをオフ;アップ（正常） 0.0 .0 .0 : 80 -> 80 / tcp

この例では、サービスのヘルス ステータスは「Up (healthy)」です。これは、サービスが実行中で、ヘルス チェックに合格していることを意味します。

13. 一般的なコマンド

以下は、Docker Compose でよく使用されるコマンドです。

  • docker-compose up: Compose ファイルで定義されたサービスを起動し、すべてのコンテナを作成して起動します。
  • docker-compose down: Compose ファイルで定義されたサービスを停止し、すべてのコンテナとネットワークを削除します。
  • docker-compose ps: Compose ファイルで定義されているすべてのコンテナのステータスを表示します。
  • docker-compose ログ: Compose ファイルで定義されているすべてのコンテナのログを表示します。
  • docker-compose build: Compose ファイルで定義された Dockerfile に従って、すべてのサービスのイメージをビルドします。
  • docker-compose pull: Compose ファイルで定義されているすべてのサービスのイメージをプルします。
  • docker-compose restart: Compose ファイルで定義されているすべてのサービスを再起動します。
  • docker-compose stop: Compose ファイルで定義されているすべてのサービスを停止します。
  • Docker-Compose Start：Composeファイルで定義されたすべてのサービスを開始します。
  • Docker-Compose Exec：Composeファイルで定義されたコンテナ内のコマンドを実行します。
  • Docker-Compose Run：Composeファイルで定義されたコンテナでコマンドを実行します。
  • Docker-Compose Config：Composeファイルの構文をチェックし、Composeファイルで定義されているすべてのサービスの構成を表示します。

これらは、Docker Composeで一般的に使用されるコマンドであり、必要に応じてComposeプロジェクトを管理および操作できるようになります。

<<:  [クラウドネイティブ] Prometheus カスタムアラートルール

>>:  エッジコンピューティングは長い間私たちの身近に存在してきました

推薦する

impactvps-7 USD/オープン 4 VPS/5IP/4GB メモリ/4 コア/45GB SSD/2TB トラフィック

2003年に、impactvps（バックエンドドメイン名はsubnetlabs.com）を当サイトの...

#11.11# locvps: すべての VPS が 55% オフ、CN2\CUII\ およびその他の優れた回線: 香港、韓国、米国、日本、シンガポール、ドイツ、オランダ、ロシア

2018年のダブルイレブン期間中、locvpsはすべてのVPS（香港CN2、韓国CN2、米国CN2、...

図解解説: Discuz フォーラム最適化基本設定 前半

ウェブマスターの友人は Discuz をよくご存知だと思います。私たちが訪問するフォーラムのほとんど...

中国企業のクールカスタマーマーケティング：企業がコストゼロで数千万の露出を獲得できるよう支援

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っています導入：これ...

ハイブリッド クラウドは、将来のキャンパス インテリジェンスの基盤となります。ファーウェイクラウドが大学の知能化を支援

2017年ハルビンで高等教育情報化発展セミナー開催【中国ハルビン、2017年11月24日】11月、「...

中国での優れたSEOは井の中の蛙ではない

みなさんこんにちは。私の名前はLiang Lei、オンライン名はStoneです。初心者にとって、SE...

digitalvirt はどうですか?米国ロサンゼルスの高級 cmin2 ネットワーク VPS の簡単なレビュー。Netflix/TikTok のブロックを解除します。

digitalvirt cmin2 vps はどうですか? digitalvirtは、米国ロサンゼル...

SEO ガイド: シンプルな SEO プランをすばやく作成する方法!

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っていますスタートア...

Kafka の適用可能なシナリオをネットワーク全体で最も包括的に図解で解説します。

メッセージングシステムメッセージング システムは、データ プロデューサーの分離や未処理メッセージのキ...

ウェブサイト最適化の初心者がローカルSEOブログをホームページに素早く掲載するための重要なポイント

以前、A5 では SEO に関する知識を皆さんとたくさん共有しました。今日、SEO Qibing は...

Huawei EMUI10の詳細な分析：分散技術の機能、オープン性、ツールチェーン

8月10日、EMUI分散キーテクノロジー機能のオープン性とツールチェーンサブフォーラムが、約2,00...

クラウド コンピューティングとエッジ コンピューティングのどちらを選択しますか?企業はエッジコンピューティングの適用可能なシナリオと利点を理解する必要がある

[[440556]]エッジ コンピューティングは、クラウドベースのネットワークの制限を打ち破ろうとし...

対外貿易促進サービスプラットフォームは、どうすれば企業ユーザーを迅速に獲得できるのでしょうか?

2018年最もホットなプロジェクト：テレマーケティングロボットがあなたの参加を待っています過去2年間...

作成するのが最も簡単で最も難しい外部リンク

ウェブマスターは基本的に毎日外部リンクを処理する必要があります。どのような外部リンクを作るか、どのよ...

ssdnodes-$9.99/KVM/8G メモリ/80g SSD/4 コア/8T トラフィック/10Gbps 帯域幅

Docker をサポートし、安定性と信頼性に優れた KVM VPS をお探しの場合は、SSDNODE...