コンテンツにスキップ

docker-compose.yml#

docker-compose.ymlファイルはLagoonが以下の目的のために利用します:

  • デプロイするべきサービス/コンテナを知る
  • コンテナのイメージがどのようにビルドされるかを定義する
  • 永続ボリュームのような追加の設定を定義する

Docker Compose(ツール)はYAMLファイルの内容の検証に非常に厳格であるため、サービス定義のlabels内でのみ設定を行うことが可能です。

警告

Lagoonはdocker-compose.ymlファイルからラベル、サービス名、イメージ名、ビルド定義のみを読み取ります。ポート、環境変数、ボリューム、ネットワーク、リンク、ユーザーなどの定義は無視されます。

これは意図的なもので、docker-composeファイルがあなたのローカル環境の設定を定義するためのものです。Lagoonはlagoon.typeからあなたがデプロイしているサービスのタイプを学び、そのサービスが必要とするポート、ネットワーク、その他の追加設定について知ることができます。

以下に、Drupal用のdocker-compose.ymlファイルの簡単な例を示します:

docker-compose.yml
version: '2.3'

x-lagoon-project:
  # Lagoonプロジェクト名(これを編集する際は`&lagoon-project`を残してください)
  &lagoon-project drupal-example

x-volumes:
  &default-volumes
 # Dockerコンテナにリアルタイムでマウントしたいすべてのボリュームを定義します
    volumes:
      - .:/app:delegated

x-environment:
  &default-environment
    LAGOON_PROJECT: *lagoon-project
    # ローカルで使用するルート。pygmyを使用している場合、このルートは *必ず* .docker.amazee.ioで終わるようにしてください
    LAGOON_ROUTE: http://drupal-example.docker.amazee.io
    # 本番環境と同様の動作をさせたい場合はコメントアウトを解除してください
    #LAGOON_ENVIRONMENT_TYPE: production
    # Xdebugを有効にし、`docker-compose up -d`で再起動したい場合はコメントアウトを解除してください
    #XDEBUG_ENABLE: "true"

x-user:
  &default-user
    # コンテナが実行されるべきデフォルトのユーザー。Linux上でID `1000`以外のユーザーで実行する場合はこれを変更します
    user: '1000'

services:

  nginx:
    build:
      context: .
      dockerfile: nginx.dockerfile
    labels:
      lagoon.type: nginx-php-persistent # (1)
      lagoon.persistent: /app/web/sites/default/files/

  php:
    build:
      context: .
      dockerfile: php.dockerfile
    labels:
      lagoon.type: nginx-php-persistent # (2)
      lagoon.name: nginx
      lagoon.persistent: /app/web/sites/default/files/

  mariadb:
    image: uselagoon/mariadb-10.11-drupal
    labels:
      lagoon.type: mariadb
  1. ここでマルチコンテナポッドに注目してください。
  2. ここでマルチコンテナポッドに注目してください。

基本設定#

x-lagoon-project:

これはプロジェクトのマシン名で、ここで定義します。"drupal-example"を使用しています。

x-volumes:

これはLagoonにコンテナにマウントするものを指示します。ウェブアプリケーションは/appに存在しますが、必要に応じてこれを追加または変更することができます。

x-environment:

  1. ここでローカル開発URLを設定できます。pygmyを使用している場合、.docker.amazee.ioで終わらなければなりません。
  2. 完全に本番環境に似せたい場合は、LAGOON_ENVIRONMENT_TYPE: production のコメントを外します。
  3. Xdebugを有効にしたい場合は、DEBUG_ENABLE: "true" のコメントを外します。

x-user:

Linuxを使用していて、1000以外のユーザーで実行したい場合を除き、これを変更する必要はほとんどありません。

services#

ここでデプロイしたいすべてのサービスを定義します。 残念ながら、 Docker Composeはそれらをサービスと呼びますが、実際にはコンテナです。これからはこのドキュメンテーション全体でサービスと呼ぶことにします。

そのサービスの名前(上記の例では nginx、php、mariadb)は、Lagoonによって生成されるKubernetesのポッドの名前(また別の用語としてサービスと呼びます)として使用され、さらに定義されたlagoon.typeに基づいて作成されるKubernetesのオブジェクトの名前としても使用されます。これには、サービス、ルート、永続的なストレージなどが含まれる可能性があります。

サービス名はRFC 1035のDNSラベル標準に準拠していることに注意してください。サービス名は以下の要件を満たす必要があります:

  • 最大63文字を含む
  • 小文字の英数字または'-'のみを含む
  • 英字で始まる
  • 英数字で終わる

警告

一度サービスの名前を設定したら、修正しないでください。修正すると、コンテナ内で様々な問題が発生し、不整合が発生する可能性があります。

Dockerイメージ#

build#

デプロイメントごとにLagoonがあなたのサービスのDockerfileをビルドしてほしい場合、ここで定義できます:

build

  • context
    • docker build コマンドに渡すべきビルドコンテキストパス
  • dockerfile:
    • ビルドするべきDockerfileの場所と名前

警告

Lagoonは短縮バージョンをサポートしていません。build: <Dockerfile>の定義が見つかった場合、処理は失敗します。

image#

Dockerfileをビルドする必要がなく、既存のDockerfileを使用したい場合は、imageで定義します。

タイプ#

Lagoonは、KubernetesやOpenShiftのオブジェクトを正しく設定するために、デプロイするサービスのタイプを知る必要があります。

これはlagoon.typeラベルを通じて行われます。選択できるタイプは多数あります。すべてのタイプと追加設定の可能性を見るには、サービスタイプを確認してください。

コンテナのスキップ/無視#

たとえば、ローカル開発時にのみコンテナが必要な場合など、Lagoonにサービスを完全に無視させたい場合は、そのタイプにnoneを指定します。

永続的なストレージ#

一部のコンテナには永続的なストレージが必要です。Lagoonでは、各コンテナが最大1つの永続的なストレージボリュームをコンテナに接続できるようにしています。コンテナに自身の永続的なストレージボリュームを要求させることができ(それを他のコンテナにマウントさせることも可能)、また、コンテナに他のコンテナが作成した永続的なストレージをマウントするよう指示することもできます。

多くの場合、Lagoonはその永続的なストレージがどこに配置すべきかを知っています。たとえば、 例えば、MariaDBコンテナの場合、Lagoonは永続的なストレージを/var/lib/mysqlに配置すべきと知っており、それを定義するための追加の設定なしに自動的にそこに配置します。ただし、一部の状況では、Lagoonは永続的なストレージをどこに配置すべきかを知るためにあなたの助けが必要です。

  • lagoon.persistent - 永続的なストレージをマウントすべき絶対パス(上記の例では/app/web/sites/default/files/を使用しており、これはDrupalが永続的なストレージを期待するパスです)。
  • lagoon.persistent.name - Lagoonにそのサービスの新しい永続的なストレージを作成しないように指示し、代わりに他のサービスで定義済みの永続的なストレージをこのサービスにマウントします。
  • lagoon.persistent.size - 必要な永続的なストレージのサイズ(Lagoonは通常、最小5Gの永続的なストレージを提供します。もしもっと必要なら、ここで定義してください)。
  • lagoon.persistent.class - デフォルトではLagoonは自動的に適切なストレージクラス(MySQLのSSD、Nginxの大量ストレージなど)をサービスに割り当てます。これを上書きする必要がある場合は、ここで行うことができます。これは、Lagoonが動作するKubernetes/OpenShiftのインフラ基盤に大きく依存します。これについてはLagoonの管理者に問い合わせてください。

自動生成されるルート#

docker-compose.ymlファイルは、サービスごとに自動生成されるルートを有効または無効にすることもサポートしています。

  • lagoon.autogeneratedroute: false ラベルを使用すると、そのサービスに対して自動的に生成されるルートが停止します。これは自動生成されるルートを持つすべてのサービスに適用できますが、データベースサービスなどの追加の内部向けサービスを作成する際にbasicおよびbasic-persistentサービスタイプで特に便利です。逆もまた同様に、.lagoon.ymlファイルがそれらを無効にするときに、サービスに対して自動生成されるルートを有効にします。

マルチコンテナーポッド#

KubernetesとOpenShiftは単純なコンテナーをデプロイしません。代わりに、それぞれが1つ以上のコンテナーを持つポッドをデプロイします。通常、Lagoonは定義されたdocker-composeサービスごとにコンテナーが内部にある単一のポッドを作成します。しかし、あるケースでは、これらのコンテナーが互いに非常に依存していて、常に一緒にいるべきであるため、単一のポッド内に2つのコンテナーを配置する必要があります。そのような状況の一例は、PHPコンテナとNGINXコンテナがDrupalのようなウェブアプリケーションのPHPコードを含む場合です。

これらのケースでは、どのサービスを一緒にすべきかをLagoonに伝えることが可能で、次のように行います(私たちがコンテナをdocker-composeのためにservicesと呼んでいることを覚えておいてください):

  1. 両方のサービスを、二つのサービスを期待するlagoon.typeで定義します(この例では、nginxとphpサービスで定義されているnginx-php-persistentです)。
  2. 第2番目のサービスを第1番目のサービスにリンクし、第2番目のサービスのラベルlagoon.nameにて第1番目のサービスを指定します(この例では、lagoon.name: nginxと指定します)。

これにより、Lagoonはnginxとphpコンテナをnginxと呼ばれる1つのポッドに組み合わせることを認識します。

警告

一度サービスのlagooon.nameを設定したら、修正しないでください。これはあなたのコンテナで混乱を引き起こし、不整合を引き起こす原因となります。

Lagoonは、2つのサービスのうちどれが実際の個々のサービスタイプ（この場合、nginxおよびphp）であるかを理解する必要があります。これを行うために、タイプによって与えられた名前と同じ名前のサービスを検索します。したがって、nginx-php-persistentはdocker-compose.yml内にnginxという名前のサービスとphpという名前のサービスが1つずつ存在することを期待します。何らかの理由でサービスに異なる名前を使用したい場合、またはnginx-php-persistentタイプのポッドを複数必要とする場合には、実際のサービスタイプを定義するためにlagoon.deployment.servicetypeという追加のラベルを使用することができます。

例:

docker-compose.yml
nginx:
    build:
      context: .
      dockerfile: nginx.dockerfile
    labels:
      lagoon.type: nginx-php-persistent
      lagoon.persistent: /app/web/sites/default/files/
      lagoon.name: nginx # これがない場合、Lagoonはコンテナ名、つまりこの場合はnginxを使用します。
      lagoon.deployment.servicetype: nginx
php:
    build:
      context: .
      dockerfile: php.dockerfile
    labels:
      lagoon.type: nginx-php-persistent
      lagoon.persistent: /app/web/sites/default/files/
      lagoon.name: nginx # このサービスをLagoonのNGINXポッドの一部にします。
      lagoon.deployment.servicetype: php

上記の例では、サービス名はnginxとphpです(好きな名前をつけることができます)。lagoon.nameはLagoonにどのサービスを一緒のポッドにすべきを伝えます - 同じ名前のサービスはすべて一緒のポッドで動作します。

Lagoonはどのサービスがnginx、phpであるかを認識するために、lagoon.deployment.servicetype: nginxおよびlagoon.deployment.servicetype: phpと定義します。

Helmテンプレート (Kubernetesのみ)#

LagoonはKubernetesでのテンプレート作成にHelmを使用します。これを行うために、一連のチャートがbuild-deploy-toolイメージに含まれています。

カスタムロールアウトモニタータイプ#

デフォルトでは、LagoonはカスタムテンプレートからのサービスがKubernetesまたはOpenshift内のDeploymentConfigオブジェクトを介してロールアウトされることを期待しています。それに基づいてロールアウトを監視します。場合によっては、カスタムデプロイメントで定義されたサービスが異なる監視方法を必要とすることがあります。これはlagoon.rolloutを通じて定義することができます:

  • deploymentconfig - これがデフォルトです。サービスのテンプレートの中のDeploymentConfigオブジェクトを期待します。
  • daemonset - サービスのテンプレート内のDaemonsetオブジェクトを期待します。
  • false - どのロールアウトも監視せず、テンプレートが適用され、エラーを投げない場合にのみ満足します。

また、特定の環境のみにロールアウトを上書きすることもできます。これは.lagoon.ymlで行います。

Docker Compose v2互換性#

バグ

ローカルでDocker Compose V2の古いバージョンを使用していると、一部の既知の問題が発生することがあります - これらの問題は後のリリース(v2.17.3以降)で解決されています。

これらのエラーの解決策は通常、使用しているDocker Composeのバージョンを更新するか(または新しいバージョンをインストールする)、あるいは使用しているDocker Desktopのバージョンをアップグレードすることです。 Docker Desktopのリリースノートを参照してください。 詳しくは

depends_onのエラーを示すDocker Compose出力
Failed to solve with frontend dockerfile.v0: failed to create LLB definition: pull access denied, repository does not exist or may require authorization

または

Failed to solve: drupal9-base-cli: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed`
  • これらはDocker Compose v2.13.0で解決されます。
  • このメッセージは、ビルドが、まだビルドされていないDockerイメージにアクセスしようとしたことを意味します。BuildKitは並列にビルドするため、もしもう一つのDockerイメージを継承するものがある場合(DrupalのCLIのように)はこの事象が発生します。
  • マルチステージビルドとして再設定するために、ビルド内のtargetフィールドを使用することもできます。
  • すでに新しいDocker Composeバージョンを実行している場合、このエラーは、docker-containerビルドコンテキストをbuildxでデフォルトにしている可能性があります。docker buildx lsがdocker-containerベースのものではなく、docker builderをデフォルトとして表示することを確認する必要があります。Docker buildxのドキュメントはこちらです.
volumes_fromエラーを示すDocker Compose出力
no such service: container:amazeeio-ssh-agent
  • この問題はDocker Compose v2.17.3で解決されています。
  • このメッセージは、ローカルで実行されているコンテナへのSSHアクセスを提供するサービスが、あなたのDocker Composeスタックの外部で実行され、アクセスできないことを意味します。
  • あなたのローカル環境からSSHアクセスが必要ない場合、docker-compose.ymlファイルからこのセクションを削除することもできます。

BuildKitとLagoon#

BuildKitは、ソースコードを効率的で表現力豊かで繰り返し利用可能な方法でビルド成果物に変換するためのツールキットです。

Lagoon v2.11.0のリリースにより、Lagoonはより高度なBuildKitベースのdocker-composeビルドをサポートするようになりました。プロジェクトまたは環境でBuildKitを有効にするには、Lagoonプロジェクトまたは環境にDOCKER_BUILDKIT=1をビルド時の変数として追加してください。

LagoonビルドでのDocker Composeエラー#

Docker Composeで一般的なビルドエラーの解決方法については、Lagoonビルドエラーページを参照してください。

よくあるDocker Composeの問題#

このセクションでは、一般的なDocker Composeのエラーとその対処方法について説明します。これらはローカル開発で発生するか、またはLagoonビルドエラーと警告として発生するかもしれません。

二重マッピングキー#

マッピングキーのエラーを示すDocker Composeの出力
ERR: yaml: unmarshal errors: line 22: mapping key "<<" already defined at line 21

Lagoonの初期リリースでは、ボリュームとユーザーコードを提供するために、サービスにYAMLエイリアスのペアが添付されていました。Docker Composeの新しいリリースでは、これをエラーとして報告します。すべての例が現在更新されているものの、更新が必要な古いコードベースがあるかもしれません。

このエラーは、Docker Composeが配列に何を挿入しているのか分からないため、重複していると仮定して発生します。

あなたのdocker-compose.ymlがこの(または類似の)コードブロックを一つ以上含んでいる場合、あなたは影響を受けます。

二重マッピングキーを含むDocker Composeのエラー
...
    << : [*default-volumes]
    << : [*default-user]
...

修正版では、両方のエイリアスを1つのマッピングキーに統合します。すべての箇所を対処する必要があります。

Docker Composeにおける複数のエイリアスマッピングキーの正しい挿入方法
...
    << : [*default-volumes, *default-user]
...