コンテンツにスキップ

既存のサイトをLagoon化する#

Lagoon化、つまり既存のサイトをLagoonプラットフォームに対応させることは、一般的には難しくありません(サイトやセットアップによりますが)、しかしいくつかの手順が必要です。このプロセスを簡単にするためのステップバイステップのガイドをまとめました。

要件#

あなたのシステムがローカルでLagoonを使用するための要件を満たしていることを確認してください。

ローカル開発環境#

ローカル開発環境を設定する。PygmyとLandoのどちらかを選ぶことができます。

コマンドラインとGit#

コマンドラインを通じてLagoonとやりとりする必要があり、またGitも必要ですので、準備が整っていることを確認してください。

コマンドライン#

いくつかのタスクにはコマンドラインターミナルを使用する必要があります。何を使用しても構いません、オペレーティングシステムのデフォルトツールも含めてです。以下にいくつかのオプションを示します:

Gitのインストール#

まだ持っていない場合は、 何らかの形でGitクライアントが必要です。コマンドライン、GUI、何でも構いません(私たちの例では、コマンドラインを使用します)。以下にいくつかのオプションを示します:

Lagoon管理者が必要とするもの#

Lagoonを設定しているLagoon管理者は、いくつかの情報を必要とします。詳細はこちら。

Webhooksの設定#

次に、Gitリポジトリのためのwebhooksを設定する必要があります。その手順はこちらで見つけることができます。

docker-compose.yml#

docker-compose.ymlファイルは、Lagoonによって以下のように使用されます:

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

さらに詳しくは私たちのdocker-compose.ymlドキュメンテーション.

これは、あなたのサイトをLagoonに対応させるために作成・設定する2つのファイルのうちの1つです。

Docker-compose(ツール)は、YAMLファイルの内容を厳格に検証するので、サービス定義のラベル内でのみ設定を行うことができます。

警告

Lagoonはdocker-compose.ymlファイルからラベル、サービス名、イメージ名、ビルド定義のみを読み込みます。ポート、環境変数、ボリューム、ネットワーク、リンク、ユーザーなどの定義は無視されます。これは意図的なもので、docker-composeファイルはあなたのローカル環境設定を定義するためのものです。Lagoonはlagoon.typeからあなたがデプロイしているサービスのタイプを学び、その結果、このサービスが必要とする可能性のあるポート、ネットワーク、その他の追加設定について知ることができます。

基本的なサービスの設定方法をいくつか見てみましょう。この例では、Drupal、Laravel、その他のコンテンツマネジメントシステムなど、多くのシステムに必要なNGINX、PHP、MariaDBを設定します。

以下は、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
      lagoon.persistent: /app/web/sites/default/files/

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

  mariadb:
    image: amazeeio/mariadb-drupal
    labels:
      lagoon.type: mariadb

それぞれのオプションが何を意味するかを見てみましょう。

基本設定#

x-lagoon-project: これはプロジェクトのマシン名です、ここで定義します。"drupal-example"という例を使用します。

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

x-environment:

  • ここでローカル開発URLを設定できます。Pygmyを使用している場合、.docker.amazee.io.で終わらなければなりません。
  • 本番環境を完全に模倣したい場合は、LAGOON_ENVIRONMENT_TYPE: productionのコメントを解除します。
  • x-debugを有効にしたい場合は、DEBUG_ENABLE: "true"のコメントを解除します。

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

services#

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

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

Docker イメージ#

Lagoon ですべてのデプロイメント中にサービスの Dockerfile をビルドする場合は、ここで定義できます:

build - context : Docker の build コマンドに渡すビルド コンテキスト パス。 - dockerfile: ビルドする Dockerfile の場所と名前。

Warning

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

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

この例では、現在のディレクトリのパスを指定しています。NGINX は nginx.dockerfile をビルドするように設定され、PHP は php.dockerfile をビルドするように設定されています。MariaDB は amazeeio/mariadb-drupal の既存のイメージを使用しています。Docker イメージの詳細については、こちら をご覧ください。

タイプ#

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

これは lagoon.type ラベルを介して行われます。選択できるタイプは多岐にわたります。すべてのタイプと追加的な設定可能性を見るために、私たちの公開ドキュメンテーション Service Types を読んでください。

例で気づいたかもしれませんが、PHPとNGINXのサービスは両方ともタイプを nginx-php-persistent と定義しています。それは彼らがいわゆるマルチコンテナポッドだからです。

マルチコンテナポッド#

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

これらのケースでは、どのサービスが一緒に留まるべきかをLagoonに伝えることが可能です。 一緒に。これは以下の方法で行われます(私たちはコンテナをサービスと呼んでいることを覚えておいてください):

  1. 両方のサービスを lagoon.type で定義し、それが2つのサービスを期待している(この例では、NGINXとPHPのサービスで定義されている nginx-php-persistent )。
  2. 2番目のサービスを1番目のサービスにリンクし、2番目のサービスのラベル lagoon.name を1番目のものと一致させます(この例では lagoon.name: nginx の設定によりこれが行われます)。

これにより、Lagoonは nginx と php のサービスが nginx と呼ばれるポッドに結合されていることを認識します。

Lagoonはまだ、2つのサービスのうちどちらが 実際の 個々のサービスタイプであるか(この場合は nginx と php )を理解する必要があります。これは、一致するサービスタイプのサービス名を検索することでこれを行います。 nginx-php-persistent は、 docker-compose.yml の中で nginx という名前のサービスと php という名前のサービスを期待しています。

何らかの理由でサービスの名前を変更したい場合や、 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

docker-compose.ymlでできることはもっとありますが、サービスを設定することが最も重要な部分です。docker-compose.ymlに関する我々のドキュメンテーションをチェックして、他に何ができるかを学んでください。

.lagoon.yml#

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

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

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

以下に、私たちが説明するDrupalサイトの様々な設定オプションを示す例の.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:
  insecure: Redirect

environments:
  main:
    monitoring_urls:
      - "www.example.com"
      - "www.example.com/special_page"
    routes:
      - nginx:
        - example.com
        - example.net
        - "www.example.com":
            tls-acme: 'true'
            insecure: Redirect
            hsts: max
``` -年齢=31536000
        - "example.ch":
            アノテーション:
              nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri
        - www.example.ch

    タイプ:
      マリアDB: mariadb-galera
    テンプレート:
      マリアDB: mariadb.main.deployment.yml
    ロールアウト:
      マリアDB: statefulset
    クロンジョブ:
     - 名前: drush cron
       スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。
       コマンド: drush cron
       サービス: cli
  ステージング:
    クロンジョブ:
     - 名前: drush cron
       スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。
       コマンド: drush cron
       サービス: cli

一般設定#

docker-compose-yaml#

このファイルは、どのサービスとコンテナがデプロイされるべきかを知るために、どのdocker-composeYAMLファイルをビルドスクリプトが使用すべきかを指示します。これはデフォルトでdocker-compose.ymlになりますが、特定のLagoon docker-compose YAMLファイルが必要な場合にはこれを使用することができます。

environment_variables.git_sha#

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

タスク#

定義できるタスクにはさまざまな種類があり、ビルド フローで実行されるタイミングも異なります。

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

pre_rollout タスクとして定義されたタスクは、新しいイメージが正常にビルドされた 後、プロジェクトが何らかの形で変更される 前 にプロジェクトに対して実行されます。この機能により、たとえば、上記の例のように、ロールアウトの実行前にデータベース ダンプを作成できます。これにより、ロールアウトで問題が発生した場合にロールバックしやすくなります。

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

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

  • すべてのイメージが正常にビルドされました。
  • すべてのコンテナが新しいイメージで更新されました。
  • 実行中のすべてのコンテナが準備チェックに合格しました。

post_rollout タスクの一般的な用途には、drush updb、drush cim の実行、またはさまざまなキャッシュのクリアが含まれます。上記の例では、drush cim と drush cr を実行します。

name

  • name は、ログで各タスクを識別しやすくするための任意のラベルです。

command

  • ここでは、実行するコマンドを指定します。これらは、各コンテナの WORKDIR で実行されます。Lagoon イメージの場合、これは /app です。タスクを実行するために特定の場所に cd する必要がある場合は、この点に注意してください。

service

  • タスクを実行するサービス。私たちのdrupal-exampleに従っている場合、これはCLIコンテナになります。なぜなら、それはあなたのサイトのコード、ファイル、そしてデータベースへの接続を全て持っているからです。通常、これを変更する必要はありません。

shell

タスクを実行するためにどのシェルを使用するべきか。デフォルトでは sh が使用されますが、コンテナに他のシェル(bashなど)がある場合、ここでそれを定義することができます。これは、post-rollouts内でいくつかの小さなif/else bashスクリプトを実行したい場合に便利です。(上記の例で複数行のスクリプトを書く方法を参照してください)。

ルート#

routes.autogenerate.enabled#

これにより、自動的に作成されたルートをまったく無効にすることができます。これは環境ごとのカスタムルートを無効にするものではありません。それについては下記を参照してください。

routes.autogenerate.insecure#

これにより、自動的に作成されたルートの挙動を定義することができます。これは環境ごとのカスタムルートを設定するものではありません。それについては下記を参照してください。これは、上記の例で使用しているオプションで、`insecure: リダイレクト。

以下のオプションが許可されています:

許可

  • HTTPとHTTPSの両方のルートを設定します(これがデフォルトです)。

リダイレクト

  • すべてのHTTPリクエストをHTTPSにリダイレクトします。

なし

  • HTTPのルートは作成されず、リダイレクトもありません。

環境#

環境名は、デプロイされたブランチまたはプルリクエストに一致します。これにより、各環境は異なる設定を持つことができます。この例では、メインとステージングの環境を持っています。

特定のパスの監視#

UptimeRobotがクラスターに設定されている場合、Lagoonは各ルート/イングレスにアノテーションを注入し、stakater/IngressControllerMonitorが使用します。デフォルトのアクションはルートのホームページを監視することです。特定のルートを監視する必要がある場合、ルートの仕様にmonitoring-pathを追加することでこれを上書きできます。一般的な使用法は、キャッシュをバイパスする監視用のパスを設定することで、サイトのリアルタイム監視をより実現します。

.lagoon.ymlの例
     - "www.example.com":
            monitoring-path: "/bypass-cache"

environments.[name].routes#

ルートセクションでは、環境が対応するドメイン名を特定します。それは 通常、ルートが指定された環境は本番環境だけです。すべての環境は生成されたルートを受け取りますが、非本番環境が独自のドメイン名を持つ必要がある場合もあります。ここでそれを指定し、そのドメインを生成されたルート名のCNAMEとしてDNSプロバイダに追加できます(これらのルートはデプロイメッセージで公開されます)。

環境の次の要素は、ターゲットサービスで、例ではNGINXです。これにより、どのサービスに入力リクエストを送るかを特定します。

最も単純なルートは、上記のサンプル.lagoon.ymlのexample.comの例で、追加の設定がないことがわかります。これは、ルートのLet's Encrypt証明書を希望し、HTTPSからHTTPへのリダイレクトがないと仮定します。

注釈#

情報

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

注釈は、nginx-ingressコントローラがサポートする注釈のYAMLマップであることが特に便利で、簡単にリダイレクトできます:

この例では、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

SSL設定 - tls-acme#

tls-acme : ‘true’

  • このルートに対してLagoonがLet's Encrypt証明書を発行することを示します。これがデフォルトです。
  • Let's Encryptが不要な場合、これを tls-acme: ‘false’ に設定します。

insecure

  • None、Allow、または Redirect に設定できます。
  • Allowは単にHTTPとHTTPSの両方のルートを設定します(これがデフォルトです)。
  • Redirect は、HTTPのリクエストをHTTPSにリダイレクトします。

None

  • HTTPのルートは作成されず、リダイレクトも行われません。

Hsts

  • 設定することができます max-age=31536000;includeSubDomains;preloadの値に。
  • スペースや他のパラメータが含まれていないことを確認します。
  • 必要なのはmax-ageパラメータのみです。この必要な max-age パラメータは、HSTS ポリシーが有効な時間を秒単位で指定します。

情報

証明書認証局(CA)によって署名された SSL 証明書から Let's Encrypt 証明書に切り替える予定がある場合は、Lagoon の管理者に連絡して移行を監督してもらうのが最善です。

environments.[name].types#

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

時々、全てではなく一つの環境だけでタイプを上書きしたいかもしれません。

`service-name: service-type#
  • service-name は上書きしたい docker-compose.yml のサービスの名前です。
  • service-type はあなたが上書きで使用したいサービスのタイプです。

例えば、あなたがプロダクション用の MariaDB-Galera 高可用性データベースを求めている場合、 メインと呼ばれる環境 - これが私たちの例のファイルで行っていることです:

.lagoon.yml example
environments:
  main:
    types:
      mariadb: mariadb-galera

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 example
environments:
  main:
    templates:
      mariadb: mariadb.main.deployment.yml

environments.[name].rollouts#

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

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

service-name: rollout-type#
.lagoon.yml example
environments:
  main:
    rollouts:
      mariadb: statefulset

Cronジョブ - environments.[name].cronjobs#

ほとんどの場合、すべての環境で同じcronジョブを実行することは望ましくないため、各環境で実行したいジョブを明示的に定義する必要があります。私たちの例では、1時間ごとに実行されるdrushのcronジョブを作成しています。

name

  • cronジョブの動作を識別するための親切な名前。

schedule

  • cronジョブを実行するスケジュール。これはcronの標準的な規則に従います。構文に自信がない場合は、Crontab Generatorが役立ちます。
  • Mを指定することができます。 - 分毎に M を指定すると、あなたの cron ジョブは毎時間ランダムな分に一度実行されます(毎時間同じ分)。または、M/15 を指定すると、毎時間15分ごとに実行されますが、時間からのランダムなオフセット(6、21、36、51など)で実行されます。
  • 時間に H を指定すると、あなたの cron ジョブは毎日ランダムな時間に一度実行されます(毎日同じ時間)。または、H(2-4) を指定すると、2時から4時の間に一度だけ実行されます。

command

  • 実行するコマンド。タスクと同様に、このコマンドはサービスの WORKDIR で実行されます。Lagoonのイメージでは、これは /app です。

service

  • コマンドを実行するプロジェクトのサービス。ほとんどのプロジェクトでは、これはCLIサービスです。

.lagoon.yml でできることはまだたくさんあります。詳細は .lagoon.yml についてのドキュメンテーション をご覧ください。

Drupal特有のセットアップ#

DrupalサイトをLagoonに移行する場合、全てをセットアップするためにいくつかDrupal特有のタスクを完了する必要があります。

設定ファイル#

次のステップは、設定ファイルを更新することです。Lagoonは、環境変数を使用する環境特有の設定ファイルのセットを使用するため、これらのファイルには機密情報は保存されず、全てがコミット可能で安全です。我々はさまざまな 私たちの例のリポジトリにあるさまざまな例のプロジェクト - もし初めての場合は、それらの一つを使用することをお勧めします。そうでない場合は、似たようなものを選んで関連する設定ファイルをコピーしてください。環境変数に関するドキュメンテーションを確認してください。それらをどのように使用するかの詳細情報を得るために。

例のリポジトリから設定ファイルをコピーし、その後、あなたのサイトが使用していないサービスの設定を削除するためにそれを確認します(例えば、すべてのサイトがSolrやRedisを使用しているわけではありません)。特定の環境タイプの設定をオーバーライドする必要がある場合(開発環境でのキャッシュを無効にするなど)、追加の設定ファイルを設定することができます(例のリポジトリにすでにいくつかあります)、そして次の順序でロードされます:

settings.php
 all.settings.php
 all.services.yml
 production.settings.php
 production.services.yml
 development.settings.php
 development.services.yml
 settings.local.php
 services.local.yml

.gitignoreの設定を更新する#

.gitignoreが設定ファイルのコミットを許可するようにすることを確認してください。Drupalは sites/*で出荷されます /settings*.phpおよびsites/*/services*.ymlを.gitignoreから削除します。Lagoonを使用する場合、Gitリポジトリに機密情報を保持することはありません。

DrupalのWebrootについての注意点#

残念ながら、Drupalコミュニティでは標準化されたwebrootフォルダ名についてまだ決定していません。一部のプロジェクトではDrupalを/web内に、他のプロジェクトでは/docrootまたは他の場所に配置します。LagoonのDrupal設定ファイルは、Drupalが/web内にあると想定しています。Drupalのインストールがこれと異なる場合は、ファイルを適切に調整してください。

画像をビルドする#

まず、定義された画像をビルドする必要があります:

build your images
docker-compose build

これには数分かかる場合があり、長いレスポンスが返ってきます。これは次のようなものになるはずです。

これにより、docker-compose.ymlでbuild:定義を持つすべてのコンテナのDockerイメージをdocker-composeにビルドさせます。通常、Drupalではcli、nginx、phpが含まれます。これは、特定のビルドコマンド(composer installなど)を実行したり、特定の環境変数(WEBROOTなど)を画像に注入したりするためです。

通常、 Drupalのコードを編集するたびにビルドする必要はありません(コードはホストからコンテナにマウントされます)、しかし再ビルドは問題ありません。さらに、Lagoonはデプロイメント時に全く同じDockerイメージをビルドするので、docker-compose build を再度実行するだけで、ビルドがデプロイメント時にも正常に動作するか確認できます。

コンテナの起動#

イメージがビルドされたので、コンテナを起動できます:

start the containers
docker-compose up -d

次のような応答が表示されます:

containers started
➜  lagoon-test git:(main) docker-compose up -d
Recreating lagoon-test_cli_1   ... done
Starting lagoon-test_redis_1   ... done
Starting lagoon-test_solr_1    ... done
Starting lagoon-test_mariadb_1 ... done
Recreating lagoon-test_php_1   ... done
Recreating lagoon-test_nginx_1 ... done
Recreating lagoon-test_varnish_1 ... done

これによりすべてのコンテナが起動します。コマンドが完了した後、docker-compose psで確認して、すべて完全に起動し、クラッシュしていないことを確認できます。その応答は次のようになるはずです:

view running containers
➜  lagoon-test git:(main) docker-compose ps
Name                        コマンド               状態            ポート
----------------------------------------------------------------------------------------
lagoon-test_cli_1       /sbin/tini -- /lagoon/entr ...   上      9000/tcp
lagoon-test_mariadb_1   /sbin/tini -- /lagoon/entr ...   上      0.0.0.0:32768->3306/tcp
lagoon-test_nginx_1     /sbin/tini -- /lagoon/entr ...   上      8080/tcp
lagoon-test_php_1       /sbin/tini -- /lagoon/entr ...   上      9000/tcp
lagoon-test_redis_1     /sbin/tini -- /lagoon/entr ...   上      6379/tcp
lagoon-test_solr_1      /sbin/tini -- /lagoon/entr ...   上      0.0.0.0:32769->8983/tcp
lagoon-test_varnish_1   /sbin/tini -- /lagoon/entr ...   上      8080/tcp

問題がある場合は、 docker-compose logs -f [servicename]を使用してログを確認します。

再度 composer installを実行する(Composerプロジェクトのみ)#

Drupal 8+プロジェクトを実行している場合は、Composerを使用しているはずであり、すべての依存関係をダウンロードしてインストールする必要があります。cliコンテナに接続し、composer installを実行します:

re-run composer install
docker-compose exec cli bash
[drupal-example]cli-drupal:/app$ composer install

これは奇妙に聞こえるかもしれませんが、 ビルドステップ中にすでにcomposer installが実行されていたので、再度これを行う理由を説明します:

  • ホスト上のファイルを編集してコンテナ内で直ちに利用できるようにするため、デフォルトのdocker-composer.ymlは全フォルダをコンテナにマウントします(これはvolumesセクションの.:/app:delegatedで起こります)。これはまた、Dockerビルド中にインストールされた全ての依存関係がホスト上のファイルで上書きされることも意味します。
  • ローカルでは、composer.jsonでrequire-devとして定義された依存関係にアクセスしたいと思うでしょう、一方で本番環境ではそれらは不必要なスペースを占めるだけです。そのため、Dockerfileでcomposer install --no-devを実行し、手動でcomposer installを行います。

すべてがうまくいった場合、docker-compose.ymlで定義されたLAGOON_ROUTEを開きます(例えばhttp://drupal.docker.amazee.io)と、素敵なDrupalエラーに迎えられるはずです。心配しないでください - 今のところそれは大丈夫です、最も重要なことはDrupalサイトをロードしようと試みることです。

500やそれに類似するエラーが出る場合は、Composerですべてが適切にロードされていることを確認してください。

ステータスの確認とDrupalのインストール#

最後にDrupalをインストールする時間ですが、その前に すべてが正常に動作することを確認したいです。そのためには、drush statusを使ったDrushの使用をお勧めします:

run drush status
docker-compose exec cli bash
[drupal-example]cli-drupal:/app$ drush status

上記のコマンドは、以下のような結果を返すはずです:

drush status results
[drupal-example]cli-drupal:/app$ drush status
[notice] Missing database table: key_value
Drupal version       :  8.6.1
Site URI             :  http://drupal.docker.amazee.io
Database driver      :  mysql
Database hostname    :  mariadb
Database port        :  3306
Database username    :  drupal
Database name        :  drupal
PHP binary           :  /usr/local/bin/php
PHP config           :  /usr/local/etc/php/php.ini
PHP OS               :  Linux
Drush script         :  /app/vendor/drush/drush/drush
Drush version        :  9.4.0
Drush temp           :  /tmp
Drush configs        :  /home/.drush/drush.yml
                        /app/vendor/drush/drush/drush.yml
Drupal root          :  /app/web
Site path            :  sites/default

情報

次のステップに進む前に、公開鍵についてpygmyに伝える必要があるかもしれません。Permission denied (publickey)というエラーが表示された場合は、確認してください。 こちらでドキュメンテーションを確認してください:pygmy - sshキーの追加。

次にDrupalをインストールします(代わりに既存のSQLファイルをインポートしたい場合は、次のステップに進んでください。しかし、初めにすべてが正常に動作していることを確認するために、クリーンなDrupalをインストールすることをお勧めします)。

drush siの実行
[drupal-example]cli-drupal:/app$ drush site-install
これにより、次のような出力が表示されるはずです:

drush siの結果
[drupal-example]cli-drupal:/app$ drush site-install
あなたは 'drupal' データベースのすべてのテーブルをDROPしようとしています。続行しますか？ (y/n): y
Drupalのインストールを開始します。これには時間がかかります。--notifyグローバルオプションの使用を検討してください。
インストール完了。ユーザー名: admin ユーザーパスワード: arbZJekcqh
おめでとうございます、Drupalをインストールしました！

これで、LAGOON_ROUTEで定義されたURLにアクセスして、新鮮できれいにインストールされたDrupalを見ることができます - おめでとうございます！

既存のデータベースダンプのインポート#

既に存在するDrupalサイトがある場合、そのデータベースをローカルサイトにインポートしたくなるでしょう。データベースダンプを作成する方法は多数存在し、現在のホスティングプロバイダーによります。 Drushがインストールされている場合、以下のように使用できます。

drush sql-dump
[your-existing-site]$ drush sql-dump --result-file=dump.sql
データベースのダンプがdump.sqlに保存されました。[成功]

これで、あなたの全データベースを含むdump.sqlファイルが作成されました。 このファイルをローカルのGitリポジトリにコピーし、CLIに接続すると、その中にファイルが表示されます。

here's our dump file
[drupal-example] docker-compose exec cli bash
[drupal-example]cli-drupal:/app$ ls -l dump.sql
-rw-r--r--    1 root     root          5281 Dec 19 12:46 dump.sql
現在のデータベースをドロップした後、ダンプをインポートできます(まだCLIに接続したままです):

dump existing db and import dump file
[drupal-example]cli-drupal:/app$ drush sql-drop
本当にデータベースdrupalのすべてのテーブルをドロップしますか？ (y/n): y
[drupal-example]cli-drupal:/app$ drush sql-cli < dump.sql

Drupalファイルディレクトリ#

Drupalサイトには、ファイルディレクトリも含まれます。既存のサイトからファイルを移行するには、ファイルを適切なフォルダに追加するだけです(おそらくweb/sites/default/files、sites/default/filesなど)。あなたが何を設定したかを覚えておいてください。 webroot - すべてのプロジェクトで同じではないかもしれません。

デプロイ#

このガイドのすべてを行い、あなたのamazee.io管理者がすべてを設定した場合、あなたのサイトをデプロイする準備が整いました！

Drupalサイトをデプロイする場合は、このデプロイガイドを参照してください。

それ以外の全てのデプロイについては、このデプロイガイドを参照してください。