🥇Docker Compose: 開発から運用まで

コースの開始に備えて準備されたポッドキャストの文字起こしの翻訳「Linux管理者」

Docker Compose は、実用的なツールを作成するための素晴らしいツールです。
アプリケーションで使用されるスタックの環境。定義できるようになります
アプリケーションの各コンポーネントは、次の明確で単純な構文に従います。 YAML-
ファイル.

の出現でドッカー構成v3 これらの YAML ファイルは、運用環境で作業するときに直接使用できます。
集まる DockerSwarm.

しかし、これは、同じ docker-compose ファイルを使用できることを意味しますか?
開発プロセスと実稼働環境では? または、同じファイルを使用して、
演出？まあ、一般的にはそうですが、この機能には次のものが必要です。

変数の補間: 一部の環境変数を使用する
それぞれの環境で変化する価値観。
構成オーバーライド: XNUMX 番目の (または任意の) 構成を定義する機能
後続の別の) docker-compose ファイルに関して何かが変更されます
まず、docker compose が両方のファイルのマージを処理します。

開発ファイルと本番ファイルの違い

開発中は、コードの変更を確認する必要があるでしょう。
リアルタイム。これを行うには、通常、ソースコードを含むボリュームがマウントされます。
アプリケーションのランタイムを含むコンテナー。ただし実稼働環境の場合
この方法は適切ではありません。

運用環境では、多数のノードを含むクラスターがあり、ボリュームはローカルです。
コンテナー (またはサービス) が実行されているノードに対して相対的なので、
次のような複雑な操作を行わずにソースコードをマウントできます。
コード同期、信号など。

代わりに、通常はコードの特定のバージョンを使用してイメージを作成したいと考えます。
適切なタグでマークするのが通例です (セマンティックタグを使用できます)
バージョニングまたは別のシステムをあなたの裁量で管理します）。

構成の上書き

違いがあり、依存関係がシナリオによって異なる可能性があることを考慮すると、
開発と運用では、異なる構成ファイルが必要になることは明らかです。

Docker compose は、さまざまな compose ファイルのマージをサポートしています。
最終的な構成を取得します。これがどのように機能するかは、次の例で確認できます。

$ cat docker-compose.yml
version: "3.2"

services:
  whale:
    image: docker/whalesay
    command: ["cowsay", "hello!"]
$ docker-compose up
Creating network "composeconfigs_default" with the default driver
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ________
whale_1  | < hello! >
whale_1  |  --------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

前述したように、docker compose は複数の compose の結合をサポートしています。
これにより、XNUMX 番目のファイルのさまざまなパラメータをオーバーライドできます。例えば：

$ cat docker-compose.second.yml
version: "3.2"
services:
  whale:
    command: ["cowsay", "bye!"]

$ docker-compose -f docker-compose.yml -f docker-compose.second.yml up
Creating composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

この構文は、コマンドを実行する場合、開発中はあまり便利ではありません。
何度も行う必要があります。

幸いなことに、docker compose は、次の名前の特別なファイルを自動的に検索します。
docker-compose.override.yml 値を上書きするには docker-compose.yml。もし
XNUMX 番目のファイルの名前を変更すると、元のコマンドを使用するだけで同じ結果が得られます。

$ mv docker-compose.second.yml docker-compose.override.yml
$ docker-compose up
Starting composeconfigs_whale_1
Attaching to composeconfigs_whale_1
whale_1  |  ______
whale_1  | < bye! >
whale_1  |  ------
whale_1  |     
whale_1  |      
whale_1  |       
whale_1  |                     ##        .
whale_1  |               ## ## ##       ==
whale_1  |            ## ## ## ##      ===
whale_1  |        /""""""""""""""""___/ ===
whale_1  |   ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
whale_1  |        ______ o          __/
whale_1  |                     __/
whale_1  |           __________/
composeconfigs_whale_1 exited with code 0

そうですね、そのほうが覚えやすいですね。

変数の補間

設定ファイルのサポート補間
変数およびデフォルト値。つまり、次のことができます。

services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
...

そして、そうするなら docker-compose ビルド (またはプッシュ) 環境変数なし
$MY_SERVICE_VERSION、値が使用されます 最新のしかし、設定した場合
ビルド前の環境変数の値。ビルドまたはプッシュ時に使用されます。
レジスターに プライベート.レジストリ.マイン.

私の原則

私にとって効果的なアプローチは、あなたにも効果があるかもしれません。私はこれらに従います
簡単なルール:

本番環境、開発環境 (またはその他の環境) のすべてのスタックは、次のように定義されています。
docker-compose ファイル
可能な限りすべての環境をカバーするために必要な構成ファイル
重複を避けてください。
各環境で動作するには、XNUMX つの簡単なコマンドが必要です。
主な構成はファイルで定義されます docker-compose.yml.
環境変数は、イメージタグなどを定義するために使用されます。
環境ごとに異なる可能性のある変数 (ステージング、統合、
生産）。
生産変数の値は、
デフォルトでは、これにより、スタックが本番環境で起動された場合のリスクが最小限に抑えられます。
環境変数を設定します。
実稼働環境でサービスを開始するには、次のコマンドを使用します。 docker stackdeploy - compose-file docker-compose.yml -with-registry-auth my-stack-name.
作業環境は次のコマンドを使用して開始されます ドッカーはupdを作成する.

簡単な例を見てみましょう。

# docker-compose.yml
...
services:
  my-service:
    build:
      context: .
    image: private.registry.mine/my-stack/my-service:${MY_SERVICE_VERSION:-latest}
    environment:
      API_ENDPOINT: ${API_ENDPOINT:-https://production.my-api.com}
...

# docker-compose.override.yml
...
services:
  my-service:
    ports: # This is needed for development!
      - 80:80
    environment:
      API_ENDPOINT: https://devel.my-api.com
    volumes:
      - ./:/project/src
...

使うことができます docker-compose (docker-compose アップ)スタックを実行するには
ソースコードがマウントされた開発モード /プロジェクト/ソース.

これらと同じファイルを本番環境でも使用できます。そして、私は間違いなく使用することができました
同じファイル docker-compose.yml 演出用に。これを拡張するには
本番環境では、事前定義されたタグを使用してイメージをビルドして送信するだけです
CI 段階では:

export MY_SERVICE_VERSION=1.2.3
docker-compose -f docker-compose.yml build
docker-compose -f docker-compose.yml push

運用環境では、次のコマンドを使用してこれを実行できます。

export MY_SERVICE_VERSION=1.2.3
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

ステージ上でも同じことをしたい場合は、次のように定義するだけです。
ステージング環境で作業するために必要な環境変数:

export MY_SERVICE_VERSION=1.2.3
export API_ENDPOINT=http://staging.my-api.com
docker stack deploy my-stack --compose-file docker-compose.yml --with-registry-auth

その結果、XNUMX つの異なる docker-compose ファイルを使用しました。
重複した構成は、お持ちのどの環境でも使用できます。

コースについて詳しく見る「Linux管理者」

出所： habr.com

Docker Compose: 開発から本番まで

開発ファイルと本番ファイルの違い

構成の上書き

変数の補間

私の原則

コメントを追加します返信をキャンセル

Docker Compose: 開発から本番まで

開発ファイルと本番ファイルの違い

構成の上書き

変数の補間

私の原則

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル