コンテンツにスキップ

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: amazeeio/mariadb-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ラベルを通じて行われます。選択できるタイプは多数あります。すべてのタイプと追加設定の可能性を見るには、Service Typesを確認してください。

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

たとえば、ローカル開発時にのみコンテナが必要な場合など、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です。 およびDrupalのようなWebアプリケーションのPHPコードを含むNGINXコンテナ。

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

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

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

警告

サービスのlagooon.nameを設定したら、それをリネームしないでください。これはあなたのコンテナで混乱を引き起こし、物事を壊す原因となります。

Lagoonはまだ、二つのサービスのうちどちらが実際の個別のサービスタイプであるか(この場合はnginxとphp)を理解する必要があります。これは、タイプが与える同じ名前のサービス名を検索することで行います、したがってnginx-php-persistentはngという名前のサービスを一つ期待します。 inxとphpを含むdocker-compose.ymlがあります。何らかの理由でサービスの名前を変更したい場合や、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 で定義します。

ヘルムテンプレート (Kubernetesのみ)#

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

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

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

  • deploymentconfig - これがデフォルトです。 [DeploymentConfig](https://docs.openshift.com/container-platform/4.4/applications/deployments/what-deployments-are.html#deployments-and-deployment を期待します。 サービスのテンプレート内のStatefulsetオブジェクトを期待します。
  • daemonset - サービスのテンプレート内のDaemonsetオブジェクトを期待します。
  • false - ロールアウトを監視せず、テンプレートが適用されエラーが発生しなければ満足します。

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

Docker Compose v2互換性#

バグ

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

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

依存関係のエラーを示す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 correct 複数のエイリアスマッピングキーの挿入
...
    << : [*default-volumes, *default-user]
...