YAMLアンカーと拡張機能を使用してDocker作成ファイルを簡素化する方法

Docker Composeを使用すると、複数のDockerコンテナーと、ボリュームやネットワークなどの関連リソースを管理できます。 Composeがコンテナスタックの作成に使用する宣言型YAMLファイルを記述します。

docker-compose.yml 複雑なスタックで作業している場合、ファイルが繰り返される可能性があります。サービスが構成オプションを共有し、ファイルのセクションを複製する可能性があります。セクションのすべてのインスタンスを更新するのを忘れた場合、後で更新すると間違いにつながる可能性があります。

作成ファイルはプレーンなYAMLファイルであるため、組み込みのYAML機能を利用してスタック定義をモジュール化できます。アンカー、エイリアス、拡張機能を使用すると、YAMLセクションを再利用可能なブロックに抽象化できます。必要な場所ごとにセクションへの参照を追加できます。

アンカーとは何ですか？

YAMLアンカーは、アイテムを識別し、ファイル内の他の場所で参照できるようにする機能です。アンカーは&を使用して作成されますサイン。記号の後にエイリアス名が続きます。後でこのエイリアスを使用して、アンカーに続く値を参照できます。

アンカーを使用してコンテナの再起動ポリシーの繰り返しを回避する方法は次のとおりです。

services:
  httpd:
    image: httpd:latest
    restart: &restartpolicy unless-stopped
  mysql:
    image: mysql:latest
    restart: *restartpolicy

アンカーは*を使用して参照されます文字とそのエイリアス。 &の間にスペースがないことを確認する必要があります / * 文字と次のエイリアス名。

この例は、単一行の値をアンカーで再利用する方法を示しています。スタックの再起動ポリシーの変更は、サービスを個別に編集することなく、1か所で実行できるようになりました。

マルチラインアンカー

アンカーは複数行の値を持つことができます。単一行アンカーと同じ構文を使用してそれらを作成します。これは、一連の構成の詳細を複数のサービスに提供する必要がある場合に役立ちます。

services:
  first:
    image: my-image:latest
    environment: &env
      - CONFIG_KEY
      - EXAMPLE_KEY
      - DEMO_VAR
  second:
    image: another-image:latest
    environment: *env

second サービスは、firstと同じ環境変数を取り込むようになります。環境変数のリストを繰り返す必要がないため、将来的にははるかに保守しやすくなります。

アンカー値の拡張

上記の環境の例では、アンカーの値をそのまま使用しています。多くの場合、アンカーを拡張して値を追加する必要があります。別の構文でこれを行うことができます。

secondを変更します次のようなサービス：

services:
  second:
    image: another-image:latest
    environment:
      <<: *env
      - AN_EXTRA_KEY
      - SECOND_SPECIFIC_KEY

これで、サービスはenvから基本環境構成を取得します。アンカー。次に、追加のキーが環境リストに追加されます。アンカーによって定義された既存のキーを上書きすることもできます。

拡張フィールドの使用

モジュール化への別のアプローチは、拡張フィールドです。これらは、Dockerによって無視される特別なトップレベルのYAMLフラグメントです。

Dockerは通常、作成ファイルのルートにあるノードを解釈しようとします。パーサーは、接頭辞がx-の拡張フィールドを無視します。これらのフィールドを使用して、後で参照できるように共有構成をカプセル化できます。拡張フィールドをアンカーと組み合わせて、サービス定義からセクションを抽象化します。

x-env: &env
  environment:
    - CONFIG_KEY
    - EXAMPLE_KEY
 
services:
  first:
    <<: *env
    image: my-image:latest
  second:
    <<: *env
    image: another-image:latest

この作成ファイルは、上記の例をさらに改良したものです。環境変数はどちらのサービスにも属していません。それらは完全にx-envに持ち上げられました拡張フィールド。

これは、environmentを含む新しいノードを定義します分野。 YAMLアンカーが使用されます（&env ）両方のサービスが拡張フィールドの値を参照できるようにします。

構成可能性

これらの機能を利用すると、作成ファイルを自己完結型のチャンクに分割できます。これは、過度に繰り返されるサービス定義を回避するのに役立ちます。複数のサービスに共通するものはすべて、拡張フィールドに持ち上げる必要があります。

このプラクティスは、保守性を支援するだけでなく、他の共同作業者にあなたの意図を伝えます。トップレベルの拡張フィールドに汎用フィールドが含まれていることは明らかです。特定のサービスに縛られることはなく、自由に再利用できます。

アンカーと拡張フィールドを使用すると、作成できます YAMLの再利用可能なブロックからのサービス定義。各フィールドを小さく保つことで、サービスは利用可能なアンカーの構成セクションを組み合わせることができます。作成ファイルを維持することは、面倒な作業ではなくなるはずです。

モジュール性への他のアプローチ

アンカーと拡張機能に加えて、作成定義を複数の作成ファイルにいつでも分割できることを忘れないでください。これは、個別のサービスが少数以上ある場合に必要になることがあります。

複数の作成ファイルを使用すると、各サービスに独自のファイルを割り当てることができます。ノードの値が置き換えられたり拡張されたりするオーバーライドファイルを作成することもできます。 Composeは、すべてのファイルをマージして、最終的なランタイム構成を作成します。

service.yml

services:
  service:
    image: my-image:latest

service-dev.yml

services:
  service:
    environment:
      - DEV_MODE=true

この例では、両方のComposeファイルを適用すると、1つのサービスmy-image:latestになります。、DEV_MODEを使用環境変数セット。作成CLIで複数のファイルを使用するには、-fを渡しますフラグ：

docker-compose -f service.yml -f service-dev.yml up -d

ファイルは指定された順序でマージされます。

概要

Docker Composeファイルは、扱いにくく、繰り返しになる可能性があります。値のコピーに時間を費やしている場合は、サービスのセクションを専用のYAMLブロックに抽象化することを検討してください。

アンカーや拡張機能などの機能は、保守性を高め、オーサリングエクスペリエンスを容易にします。すべての作成ファイルにメリットがあるわけではありません。一部のサービスにはほとんど共通点がない場合があるため、開始する前に特定のスタックを評価してください。