.lagoon.yml#

.lagoon.yml ファイルは、プロジェクトを設定するための中心的なファイルです。以下の操作を行うための設定が含まれています:

サイトへのアクセスルートを定義する。
プレロールアウトタスクを定義する。
ポストロールアウトタスクを定義する。
SSL証明書を設定する。
環境のためのcronジョブを追加する。

.lagoon.yml ファイルは、Gitリポジトリのルートに配置する必要があります。

一般設定#

`docker-compose-yaml`#

この設定は、ビルドスクリプトにどのDocker Compose YAMLファイルを使用するべきかを指示します。これにより、どのサービスとコンテナがデプロイされるべきかを理解します。これはデフォルトで docker-compose.yml を指しますが、必要に応じて特定のLagoon Docker Compose YAMLファイルに使用することもできます。

`environment_variables.git_sha`#

この設定は、デプロイされたGit SHAを環境変数としてプロジェクトに注入することを有効にすることができます。デフォルトではこれは無効です。値を true に設定すると、SHAが環境変数 LAGOON_GIT_SHA として設定されます。

ルート#

ルートはトラフィックを指向するために使用されますサービスに。環境内の各サービスにはルートがあり、ドメイン名は手動または自動で定義されます。トップレベルの routes セクションは、すべての環境のすべてのルートに適用されます。

`routes.autogenerate`#

これにより、自動的に作成されるルートを設定できます。手動ルートは環境ごとに定義されます。

enabled: 自動生成されたルートを無効にするには、falseに設定します。デフォルトはtrueです。
allowPullrequests: プルリクエストのために enabled: falseを上書きするには、trueに設定します。
.lagoon.yml
```
routes:
  autogenerate:
    enabled: false
    allowPullrequests: true
```

insecure: HTTP接続を設定します。デフォルトはAllowです。
- Allow: ルートはHTTPとHTTPSの両方に応答します。
- Redirect: ルートは任意のHTTPリクエストをHTTPSにリダイレクトします。

prefixes: 各環境の自動生成されたルートのプレフィクスを設定します。これは、言語プレフィクスドメインやDrupalのdomainモジュールを使用したマルチドメインサイトなどに便利です。
.lagoon.yml
```
  routes:
    autogenerate:
      prefixes:
      - www
      - de
      - fr
      - it
```

タスク#

以下のようなものがありますビルドフローで正確にどのタイミングで実行されるかによって異なるタスクの種類を定義することができます:

プリロールアウトタスク - `pre_rollout.[i].run`#

ここでは、すべてのイメージが正常にビルドされた後、_しかし_以下の前に、プロジェクトに対して実行するタスクを指定することができます:

新規にビルドされたイメージで実行中のコンテナが更新される。
既存の環境に他の変更が加えられる。

この機能を利用すると、たとえば、アプリケーションを更新する前にデータベースダンプを作成するなどのことが可能になります。この機能は、デプロイに問題が発生した場合のロールバックを容易にします。

情報

プリロールアウトタスクは_更新前の既存のポッド内で実行されます_、つまり:

最後のデプロイ以降にDockerfileに加えられた変更は、プリロールアウトタスクが実行されるときには表示されません。
既存のコンテナがない場合(例えば、新しい環境の初期デプロイメント時など)、プリロールアウトタスクはスキップされます。

ポストロールアウトタスク - `post_rollout.[i].run`#

ここでは、以下の後に、プロジェクトに対して実行する必要があるタスクを指定することができます:

全てのイメージが正常にビルドされる。
全てのコンテナが新しいイメージで更新される。
全てのコンテナが稼働し、その準備が整った後。チェック。

ポストロールアウトタスクの一般的な使用例には、drush updb、drush cimの実行や、さまざまなキャッシュのクリアなどが含まれます。

name
- 名前は、ログ内の各タスクを識別するための任意のラベルです。
command
- ここでは、実行するべきコマンドを指定します。これらは、各コンテナのWORKDIRで実行されます。Lagoonのイメージの場合、これは/appです。タスクを実行するために特定の場所にcdする必要がある場合は、これを念頭に置いてください。
service
- タスクを実行するサービス。Drupalの例に従っている場合、これはCLIコンテナになります。なぜなら、あなたのサイトのコード、ファイル、データベースへの接続がすべて含まれているからです。通常、これを変更する必要はありません。
container
- サービスが複数のコンテナを持っている場合(例:nginx-php)、ポッド内で接続するコンテナを指定する必要があります(例:nginxポッド内のphpコンテナ)。
shell
- タスクが実行されるべきシェル。デフォルトではshが使用されますが、コンテナが他のシェル(bashなど)も持っている場合は、ここで定義できます。これは、ポストロールアウト内で小さなif/else bashスクリプトを実行したい場合に便利です。以下の例を参照してください、これにより、どのようにして書き込むかを学ぶことができます複数行のスクリプト。
when
- "when"節は、タスクの条件付き実行を可能にします。それは真/偽の値に評価される表現を期待しており、タスクを実行するかどうかを決定します。

注: デプロイメント中にpre/post-rolloutタスクを一時的に無効にしたい場合は、APIで以下の環境変数をプロジェクトレベルまたは環境レベルで設定することができます(環境変数の設定方法についてはここを参照してください)。

LAGOON_PREROLLOUT_DISABLED=true
LAGOON_POSTROLLOUT_DISABLED=true

post-rolloutタスクの例#

以下は、あなたのプロジェクトに使用したり適応したりしたい、いくつかの有用なpost-rolloutタスクの例です。

Drupalがインストールされていない場合にのみ実行:

.lagoon.yml

- run:
  name: IF no Drupal installed
  command: | # (1)
    if tables=$(drush sqlq "show tables like 'node';") && [ -z "$tables" ]; then
      #### whatever you like
    fi
  service: cli
  shell: bash

これは、複数行のコマンドを作成する方法を示しています。

ブランチ名に基づいた異なるタスク:

.lagoon.yml

- run:
    name: Different tasks based on branch name
    command: |
        ### Runs if current branch is not 'production'
    service: cli
    when: LAGOON_GIT_BRANCH != "production"

シェルスクリプトを実行:

.lagoon.yml

- run:
    name: Run Script
    command: './scripts/script.sh'
    service: cli

ポッド内の特定のコンテナを対象にする:

.lagoon.yml

- run:
    name: show php env variables
    command: env
    service: nginx
    container: php

Drupal & Drush 9: マスター環境からデータベースとファイルを同期:

.lagoon.yml

- run:
    name: Sync DB and Files from master if we are not on master
    command: |
      # Only if we don't have a database yet
      if tables=$(drush sqlq 'show tables;') && [ -z "$tables" ]; then
          drush sql-sync @lagoon.master @self # (1)
          drush rsync @lagoon.master:%files @self:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX
      fi
    service: cli
    when: LAGOON_ENVIRONMENT_TYPE != "production"

ここではプロジェクトに適したエイリアスを使用してください。

バックアップの保持期間#

`backup-retention.production.monthly`#

Lagoonがプロジェクトの本番環境の月次バックアップを何回保持するべきかを指定します。

グローバルこの値が指定されていない場合、デフォルトは 1 です。

`backup-retention.production.weekly`#

Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき週間バックアップの数を指定します。

この値が指定されていない場合、グローバルデフォルトは 6 です。

`backup-retention.production.daily`#

Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき日次バックアップの数を指定します。

この値が指定されていない場合、グローバルデフォルトは 7 です。

`backup-retention.production.hourly`#

Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき毎時バックアップの数を指定します。

この値が指定されていない場合、グローバルデフォルトは 0 です。

バックアップスケジュール#

`backup-schedule.production`#

このプロジェクトのバックアップスケジュールを指定します。ただし、Minute ブロックは M でなければならず、他の値は Lagoon ビルドを失敗させます。これにより、Lagoonはこれらのバックアップが行われる特定の分をランダムに選択することができ、ユーザーはスケジュールの残りを時間まで指定することができます。

この値が指定されていない場合、グローバルデフォルトは M H(22-2) * * * です。注意してくださいこれらのバックアップは、クラスタのローカルタイムゾーンを使用します。

環境#

環境名は、デプロイされたブランチやプルリクエストと一致します。これにより、各環境で異なる設定を持つことが可能になります。私たちの例では、mainとstaging環境に適用されます。

`environments.[name].routes`#

手動ルートは、サービスへのトラフィックを指示するために環境ごとに設定されたドメイン名です。すべての環境がデフォルトで自動生成されたルートを取得するため、手動ルートは通常、プロジェクトのウェブサイトのメインドメイン(www.example.comなど)を使用して本番環境でのみ設定されます。

ヒント

Lagoonは手動ルートを制御できないので、DNSプロバイダーでDNSレコードが適切に設定されていることを確認する必要があります。自動ルートを指すCNAMEレコードを設定できる可能性があります。

環境の次の最初の要素はターゲットサービスであり、私たちの場合はnginxです。例えば、これは私たちがどのサービスに入ってくるリクエストを送るかを識別する方法です。

最も単純なルートは example.comで、これは私たちの例の.lagoon.ymlで見ることができます - 追加の設定がないことがわかります。これは、あなたがルートに対してLet's Encrypt証明書を望んでいると仮定し、HTTPSからHTTPへのリダイレクトはありません。

以下の"www.example.com"の例では、さらに3つのオプションを見ることができます(また、ルートの終わりにある:と、ルートが"で囲まれていることに注意してください、これは重要です！):

.lagoon.yml

- "www.example.com":
    tls-acme: true
    insecure: Redirect
    hstsEnabled: true

SSL設定 `tls-acme`#

警告

tls-acme: trueからtls-acme: falseに切り替えると、このルートに対して以前に生成された証明書がすべて削除されます。これは、外部のCDNを使用していて証明書のピン留めを行っている場合、予期しない挙動を引き起こす可能性があります。

tls-acme:Let's Encryptを通じた自動TLS証明書生成を設定します。デフォルトはtrueで、自動証明書を無効にするにはfalseに設定します。
insecure:HTTP接続を設定します。デフォルトはAllowです。
- Allow:ルートはHTTPとHTTPSに応答します。
- リダイレクト:ルートはすべてのHTTPリクエストをHTTPSにリダイレクトします。
hstsEnabled: Strict-Transport-Securityヘッダーを追加します。デフォルトは falseです。
hstsMaxAge: max-ageディレクティブを設定します。デフォルトは 31536000 (1 年)です。
hstsPreload: preloadディレクティブを設定します。デフォルトは falseです。
hstsIncludeSubdomains: includeSubDomainsディレクティブを設定します。デフォルトは falseです。

情報

証明書認証機関(CA)によって署名されたSSL証明書からLet's Encrypt証明書に切り替える予定の場合、移行を監視するためにLagoon管理者に連絡することをお勧めします。

特定のパスの監視#

UptimeRobotがあなたのクラスター(KubernetesまたはOpenShift)に設定されている場合、Lagoonは各ルート/イングレスに注釈を注入してstakater/IngressControllerMonitorが使用します。デフォルトのアクションはルートのホームページを監視することです。特定のルートを監視したい場合、ルート仕様にmonitoring-pathを追加することでこれをオーバーライドできます。一般的な使用法は、キャッシングをバイパスする監視用のパスを設定し、サイトのリアルタイムの監視を可能にすることです。

.lagoon.yml

- "www.example.com":
      monitoring-path: "/bypass-cache"

Ingressの注釈#

警告

ルート/Ingressの注釈は、nginx-ingressコントローラーを実行するクラスターにデプロイされるプロジェクトのみがサポートしています！これがサポートされているかどうかは、あなたのLagoon管理者に確認してください。

annotationsは、nginx-ingressコントローラーがサポートする注釈のYAMLマップです。これは特に、簡単なリダイレクトや他の設定に便利です。

制限事項#

Lagoonでは、一部の注釈が禁止されているか、部分的に制限されています。以下の表は、これらのルールを説明しています。

あなたの.lagoon.ymlがこれらの注釈のいずれかを含んでいる場合、ビルドが失敗する原因となります。

注釈	ノート
`nginx.ingress.kubernetes.io/auth-snippet`	不許可
`nginx.ingress.kubernetes.io/configuration-snippet`	`rewrite`、`add_header`、`set_real_ip`、および `more_set_headers` ディレクティブに制限されています。
`nginx.ingress.kubernetes.io/modsecurity-snippet`	不許可
`nginx.ingress.kubernetes.io/server-snippet`	`rewrite`、`add_header`、`set_real_ip`、および `more_set_headers` ディレクティブに制限されています。
`nginx.ingress.kubernetes.io/stream-snippet`	不許可
`nginx.ingress.kubernetes.io/use-regex`	不許可

Ingressのアノテーションリダイレクト#

この例では、example.chへの任意のリクエストが、フォルダーやクエリパラメータを保持したまま https://www.example.chにリダイレクトされます(example.com/folder?query -> https://www.example.ch/folder?query)。

.lagoon.yml

- "example.ch":
    annotations:
      nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri
- www.example.ch

もちろん、他の任意の場所にリダイレクトすることも可能です。 LagoonにホストされていないURL、これはexample.deへのリクエストをhttps://www.google.comにリダイレクトします。

.lagoon.yml

- "example.de":
    annotations:
      nginx.ingress.kubernetes.io/permanent-redirect: https://www.google.com

信頼されるリバースプロキシ#

警告

Kubernetesは単一のnginx.ingress.kubernetes.io/server-snippetアノテーションのみを処理します。非本番環境のルートでこのアノテーションを使用する場合は、add_header X-Robots-Tag "noindex, nofollow";アノテーションもサーバースニペットの一部として含めてください。これは、開発環境でクローラーがクロールするのを防ぐために、デフォルトのサーバースニペットがingressテンプレートで設定されているものを上書きするために必要です。.lagoon.ymlで設定されたserver-snippets。

一部の設定では、リバースプロキシ(CDNなど)がKubernetesクラスタの前に配置されます。これらの設定では、リバースプロキシのIPがアプリケーションのREMOTE_ADDR HTTP_X_REAL_IP HTTP_X_FORWARDED_FORヘッダー領域として表示されます。リクエスターのオリジナルIPはHTTP_X_ORIGINAL_FORWARDED_FORヘッダーに見つけることができます。

あなたがあなたのアプリケーションでオリジナルのリクエストIPを必要とするなら、 REMOTE_ADDR HTTP_X_FORWARDED_FOR HTTP_X_REAL_IP ヘッダーに元のIPが表示されるようにするには、信頼したいリバースプロキシのIPをイングレスに伝える必要があります:

.lagoon.yml

- "example.ch":
    annotations:
      nginx.ingress.kubernetes.io/server-snippet: |
        set_real_ip_from 1.2.3.4/32;

この例では、CIDR 1.2.3.4/32(この場合はIP 1.2.3.4)を信頼します。したがって、IP 1.2.3.4 からKubernetesクラスターにリクエストが送信されると、X-Forwarded-For ヘッダーが分析され、その内容が REMOTE_ADDR HTTP_X_REAL_IP HTTP_X_FORWARDED_FOR ヘッダーに注入されます。

`Environments.[name].types`#

Lagoonのビルドプロセスは、docker-compose.ymlファイルからlagoon.typeラベルをチェックして、どの種類のサービスがデプロイされるべきかを学習します(docker-compose.ymlのドキュメンテーションで詳しく読むことができます)。

場合によっては、すべてではなく、単一の環境だけでtypeをオーバーライドしたいことがあります。例えば、非本番環境である` 開発:

service-name: service-type

service-nameは、docker-compose.ymlから上書きしたいサービスの名前です。
service-typeは、上書きで使用したいサービスの種類です。

MariaDB_Galeraの設定例:

.lagoon.yml

environments:
  develop:
    types:
      mariadb: mariadb-single

`environments.[name].templates`#

Lagoonのビルドプロセスは、docker-compose.ymlファイルからlagoon.templateラベルをチェックして、サービスがカスタムテンプレートファイルを必要とするかどうかを確認します(docker-compose.ymlのドキュメンテーションで詳しく読むことができます)。

場合によっては、テンプレートをすべての環境ではなく、特定の環境だけで上書きしたい場合があります:

service-name: template-file

service-nameは、docker-compose.ymlから上書きしたいサービスの名前です。
template-fileは、この環境でこのサービスに使用するテンプレートのパスと名前です。

テンプレート上書きの例#

.lagoon.yml

environments:
  main:
    templates:
      mariadb: mariadb.main.deployment.yml

`environments.[name].rollouts`#

Lagoonのビルドプロセス lagoon.rolloutラベルをdocker-compose.ymlファイルからチェックし、サービスが特別なロールアウトタイプを必要とするかどうかを確認します(docker-compose.ymlのドキュメンテーションで詳しく読むことができます)。

場合によっては、特に環境のテンプレートタイプを上書きした場合には、単一の環境だけでロールアウトタイプを上書きしたいことがあります。

service-name: rollout-type

service-nameは、上書きしたいdocker-compose.ymlのサービスの名前です。
rollout-typeは、ロールアウトのタイプです。可能な値については、docker-compose.ymlのドキュメンテーションを参照してください。

カスタムロールアウトタイプの例#

.lagoon.yml

environments:
  main:
    rollouts:
      mariadb: statefulset

`environments.[name].autogenerateRoutes`#

これにより、ルートの自動生成が無効になっている場合でも、任意の環境が自動生成されたルートを取得することができます。

.lagoon.yml

routes:
  autogenerate:
    enabled: false
environments:
  develop:
    autogenerateRoutes: true

`environments.[name].cronjobs`#

Cronジョブは、通常、すべての環境で同じものを実行することは望ましくないため、各環境で明示的に定義する必要があります。定義したスケジュールにより、CronジョブはKubernetesネイティブのCronJobとして、または定義したサービスのcrontabを介したin-pod cronジョブとして実行される場合があります。

Cronジョブの例#

.lagoon.yml

cronjobs:
  - name: Hourly Drupal Cron
    schedule: "M * * * *" # Once per hour, at a random minute.
    command: drush cron
    service: cli
  - name: Nightly Drupal Cron
    schedule: "M 0 * * *" # Once per day, at a random minute from 00:00 to 00:59.
    command: drush cron
    service: cli

name: 他のcronジョブと区別し、目的を特定するための任意の名前。
schedule: cronジョブの実行スケジュール。Lagoonは、crontab形式の拡張版を使用します。構文がわからない場合は、crontab generatorを使用してください。
- 分にMを指定すると、cronジョブはランダムな分(毎時間同じ分)に1時間ごとに実行するか、M/15を指定して15分ごとに実行するが、時間からのランダムなオフセット(6,21,36,51のような)で実行します。この機能を使用してcronジョブを分散させることは、すべてのジョブを分0で一斉に実行するよりも良い方法です。
- Hを時間に指定すると、cronジョブはランダムな時間(毎日同じ時間)に1日1回実行されます。また、H(2-4)を指定すると、2時から4時の間に1日1回実行されます。

タイムゾーン:

cronジョブのデフォルトのタイムゾーンはUTCです。
ネイティブのcronジョブはノードのタイムゾーンを使用し、それはUTCです。
In-podのcronジョブは定義されたサービスのタイムゾーンを使用し、UTC以外に設定することができます。

command:実行するコマンド。これはサービスのWORKDIRで実行されます。Lagoonイメージの場合、これは/appです。

警告

Cronジョブは、crontabを介してin-podで実行される可能性があり、それは複数行のコマンドをサポートしていません。複雑なまたは複数行のcronコマンドが必要な場合、コマンドとして使用できるスクリプトに入れる必要があります。プレロールアウトまたはポストロールアウトタスクは機能します。

危険

CronジョブはKubernetesのポッドで実行されますが、ポッドの再スケジューリングにより中断される可能性があります。そのため、cronジョブを作成する際には、次のcronインターバルでコマンドを安全に中断し、再実行できるようにする必要があります。

サービス:コマンドをどのプロジェクトのサービスで実行するか。ほとんどのプロジェクトでは、これはcliサービスであるべきです。

ポリサイト#

Lagoonでは、同じGitリポジトリが複数のプロジェクトに追加することができ、これをポリサイトと呼びます。これにより、同じコードベースを実行しながら、異なる独立したデータベースと永続的なファイルを許可することができます。 .lagoon.ymlでは、現在、ポリサイトプロジェクトのためのカスタムルートを指定することのみをサポートしています。標準プロジェクトとの主な違いは、environmentsが二次元要素となり、プロジェクト名が最上位要素となることです。

これを利用するには、以下の手順を踏む必要があります:

Lagoonに2つ(以上)のプロジェクトを作成し、それぞれに同じGit URLとプロダクションブランチを設定します。これはあなたの.lagoon.ymlに従って命名されます(例:poly-project1 と poly-project2)
各プロジェクトのデプロイキーをGitリポジトリに追加します。
リポジトリのウェブフックを設定します(もし必要) - その後、プッシュ/デプロイが可能になります。リポジトリへのプッシュは、そのGit URLに対するすべてのプロジェクト/ブランチを同時にデプロイします。

Polysiteの例#

.lagoon.yml

poly-project1:
  environments:
    main:
      routes:
        - nginx:
          - project1.com
poly-project2:
  environments:
    main:
      routes:
        - nginx:
          - project2.com

特別な項目#

`api`#

情報

amazee.ioのホストされたLagoonで直接動作する場合、このキーは設定する必要はありません。

キーapiを使用すると、Lagoon CLIとdrushがLagoon GraphQL APIに接続するために使用する別のURLを定義できます。これはスキーム付きの完全なURLである必要があります。例:http://localhost:3000 これは通常変更する必要はありませんが、Lagoonの管理者がそうするよう指示する場合があります。

`ssh`#

情報

amazee.ioのホストされたLagoonで直接動作する場合、このキーは設定する必要はありません。

キーsshを使用すると、Lagoon CLIとdrushがLagoonリモートシェルサービスに接続するために使用する別のSSHエンドポイントを定義できます。これはコロンで区切られたホスト名とポートである必要があります。例:localhost:2020 これは通常変更する必要はありませんが、Lagoonの管理者がそうするよう指示する場合があります。変更する必要はありませんが、Lagoonの管理者がそうするように指示する場合があります。

`container-registries`#

container-registries ブロックでは、カスタムまたはプライベートなイメージをプルするための独自のプライベートコンテナレジストリを定義することができます。プライベートコンテナレジストリを使用するには、username、password、およびオプションでレジストリの url が必要です。YAMLで url を指定しない場合、デフォルトでDocker Hubを使用します。

レジストリユーザーのためのパスワードを定義する方法は2つあります。

Lagoon APIで container_registry タイプの環境変数を作成します:

lagoon add variable -p <project_name> -N <registry_password_variable_name> -V <password_goes_here> -S container_registry
(詳しくは Environment Variables を参照してください)

作成した変数の名前は、パスワードとして設定することができます:

.lagoon.yml

container-registries:
  docker-hub:
    description: "username and password consumed from environment variables for the default docker.io registry"
  my-custom-registry:
    description: "username and password consumed from environment variables for my custom registry"
    url: my.own.registry.com
  another-custom-registry:
    description: "password consumed from environment variables for my other registry"
    username: myotheruser
    url: my.other.registry.com

また、.lagoon.yml ファイルに直接プレーンテキストでパスワードを定義することもできます:

.lagoon.yml

container-registries:
  docker-hub:
    description: "the default docker.io registry credentials"
    username: dockerhubuser
    password: MySecretPassword
  my-custom-registry:
    description: "the credentials for my own registry"
    url: my.own.registry.com
    username: mycustomuser
    password: MyCustomSecretPassword

カスタムまたはプライベートなコンテナレジストリイメージの使用#

カスタムまたはプライベートなコンテナレジストリイメージを使用するには、docker-compose.yml ファイル内のサービスを更新して、イメージを定義する代わりにビルドコンテキストを使用するようにする必要があります:

.docker-compose.yml

services:
  mariadb:
    build:
      context: .
      dockerfile: Dockerfile.mariadb

docker-compose.yml ファイルがビルドを使用するように更新されたら、 Dockerfile.<service> を作成し、プライベートイメージを FROM <repo>/<name>:<tag> として設定する必要があります。

.lagoon.yml

FROM dockerhubuser/my-private-database:tag

`.lagoon.yml` の例#

これは全ての可能な設定を示す .lagoon.yml の例です。プロジェクトに合わせて調整する必要があります。

.lagoon.yml
docker-compose-yaml: docker-compose.yml

environment_variables:
  git_sha: 'true'

tasks:
  pre-rollout:
    - run:
        name: drush sql-dump
        command: mkdir -p /app/web/sites/default/files/private/ && drush sql-dump --ordered-dump --gzip --result-file=/app/web/sites/default/files/private/pre-deploy-dump.sql.gz
        service: cli
  post-rollout:
    - run:
        name: drush cim
        command: drush -y cim
        service: cli
        shell: bash
    - run:
        name: drush cr
        command: drush -y cr
        service: cli

routes:
  autogenerate:
    insecure: Redirect

environments:
  main:
    routes:
      - nginx:
        - example.com
        - example.net
        - "www.example.com":
            tls-acme: true
            insecure: Redirect
            hstsEnabled: true
        - "example.ch":
            annotations:
              nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri
        - www.example.ch
    types:
      mariadb: mariadb
    templates:
      mariadb: mariadb.main.deployment.yml
    rollouts:
      mariadb: statefulset
    cronjobs:
      - name: drush cron
        schedule: "M * * * *" # This will run the cron once per hour.
        command: drush cron
        service: cli
  staging:
      cronjobs:
      - name: drush cron
        schedule: "M * * * *" # This will run the cron once per hour.
        command: drush cron
        service: cli
  feature/feature-branch:
      cronjobs:
      - name: drush cron
        schedule: "H * * * *" # This will run the cron once per hour.
        command: drush cron
        service: cli

非推奨#

これらの設定は非推奨となり、あなたの .lagoon.yml から削除するべきです。

routes.autogenerate.insecure
None オプションは Redirect と同等です。

environments.[name].monitoring_urls
environments.[name].routes.[service].[route].hsts
environments.[name].routes.[service].[route].insecure
None オプションは Redirect と同等です。

.lagoon.yml#

一般設定#

docker-compose-yaml#

environment_variables.git_sha#

ルート#

routes.autogenerate#

タスク#

プリロールアウトタスク - pre_rollout.[i].run#

ポストロールアウトタスク - post_rollout.[i].run#

post-rolloutタスクの例#

バックアップの保持期間#

backup-retention.production.monthly#

backup-retention.production.weekly#

backup-retention.production.daily#

backup-retention.production.hourly#

バックアップスケジュール#

backup-schedule.production#

環境#

environments.[name].routes#

SSL設定 tls-acme#

特定のパスの監視#

Ingressの注釈#

制限事項#

Ingressのアノテーションリダイレクト#

信頼されるリバースプロキシ#

Environments.[name].types#

environments.[name].templates#

テンプレート上書きの例#

environments.[name].rollouts#

カスタムロールアウトタイプの例#

environments.[name].autogenerateRoutes#

environments.[name].cronjobs#

Cronジョブの例#

ポリサイト#

Polysiteの例#

特別な項目#

api#

ssh#

container-registries#

カスタムまたはプライベートなコンテナレジストリイメージの使用#

.lagoon.yml の例#

非推奨#

`docker-compose-yaml`#

`environment_variables.git_sha`#

`routes.autogenerate`#

プリロールアウトタスク - `pre_rollout.[i].run`#

ポストロールアウトタスク - `post_rollout.[i].run`#

`backup-retention.production.monthly`#

`backup-retention.production.weekly`#

`backup-retention.production.daily`#

`backup-retention.production.hourly`#

`backup-schedule.production`#

`environments.[name].routes`#

SSL設定 `tls-acme`#

`Environments.[name].types`#

`environments.[name].templates`#

`environments.[name].rollouts`#

`environments.[name].autogenerateRoutes`#

`environments.[name].cronjobs`#

`api`#

`ssh`#

`container-registries`#

`.lagoon.yml` の例#