diff --git a/docs/ja/applications/drupal/automatic-updates.md b/docs/ja/applications/drupal/automatic-updates.md index 238159a527..cc5c8bfeb2 100644 --- a/docs/ja/applications/drupal/automatic-updates.md +++ b/docs/ja/applications/drupal/automatic-updates.md @@ -1,20 +1,18 @@ # 自動更新 -Lagoonは、Drupalコアやcontribの一部の更新方法と互換性のない方法でアプリケーションをデプロイします。Lagoonは不変のイメージをビルドし、不変のコンテナを稼働させることを期待しています。ランタイムでアプリケーションのコードが変更されると、以下の問題が生じる可能性があります。 +Lagoonは、Drupalのコア部分やcontribモジュールの更新方法の一部と互換性がありません。Lagoonは変更できないイメージを構築し、変更できないコンテナを実行することを想定しています。アプリケーションのコードが実行時に変更されると、以下の問題が発生する可能性があります。 -1. コンテナはKubernetesによって自動的に管理され、いつでも移動、再起動、スケーリングが可能です。これが起こると、元のビルド済みコンテナイメージが実行され、ランタイムで発生した変更はすべて失われます。 -2. タスクやcronjobは、元のビルド済みコンテナイメージで実行され、更新されたコードにアクセスできない可能性があります。 -3. 更新にはファイルシステムへの書き込み権限が必要ですが、読み取り専用のファイルシステムを強制する環境を設定することも可能です。 -4. ベストプラクティスは、それぞれが一つのことを行う小さなコンテナをデプロイすることです。これは、典型的なDrupalプロジェクトでは、`cli`、`php`、`nginx`というコンテナがそれぞれコードのコピーを含むことを意味します。これらのコンテナのうち一つだけを更新すると、コードの不一致による問題が発生します。 +1. コンテナの再起動による変更の消失: コンテナはKubernetesによって自動的に管理されており、いつでも移動、再起動、スケーリングされる可能性があります。これが発生すると、最初に構築されたコンテナイメージが実行され、実行時に加えられた変更はすべて失われます。 +2. タスクとCronジョブの問題: タスクやCronジョブは最初に構築されたコンテナイメージで実行されるため、更新されたコードにアクセスできません。 +3. 読み取り専用ファイルシステムによる更新の制限: 更新にはファイルシステムへの書き込み権限が必要ですが、読み取り専用ファイルシステムを強制する環境を構成することが可能です。 +4. 複数コンテナ更新時の不一致: ベストプラクティスでは、それぞれ単一の機能を持つ小さなコンテナをデプロイすることを推奨します。一般的なDrupalプロジェクトでは、コードのコピーを含む`cli`、`php`、`nginx`のコンテナが3つ存在します。これらのコンテナのうち1つだけを更新すると、コードの不一致による問題が発生します。 -以下の更新方法はLagoonによって無効化されています。 +Lagoonでは以下の更新方法が無効化されています。 ## Drupal 自動更新 -[自動更新] (https ://www.drupal.org/project/automatic_updates) -contribモジュールは無効化されており、Drupal coreに移行する際も無効化されます。 +Drupal 自動更新モジュール:contribモジュールの[自動更新] (https ://www.drupal.org/project/automatic_updates)は無効化されており、Drupalコアに移行しても無効化されます。 ## Drush -`drush pm-install`または`drush pm-update`は、デフォルトで無効化されています。これは[amazeeio/drupal-integrations](https://github.com/amazeeio/drupal-integrations) -パッケージの一部としてです。 \ No newline at end of file +`drush pm-install`または`drush pm-update`コマンドは、[amazeeio/drupal-integrations](https://github.com/amazeeio/drupal-integrations)パッケージの一部としてデフォルトで無効化されています。 diff --git a/docs/ja/applications/drupal/drush-9.md b/docs/ja/applications/drupal/drush-9.md index d467c11202..00c0db0810 100644 --- a/docs/ja/applications/drupal/drush-9.md +++ b/docs/ja/applications/drupal/drush-9.md @@ -7,36 +7,38 @@ description: >- ## エイリアス -残念ながら、Drush 9はDrush 8が持っていたような動的なサイトエイリアスを注入する能力を提供していません。私たちはDrushチームと協力して、これを再度実装する作業を行っています。その間、Drush 9をLagoonで使用するための回避策があります。 +残念ながら、Drush 9では Drush 8のような動的サイトエイリアスの注入機能が提供されていません。Drushチームと協力して、この機能を再び実装できるように取り組んでいます。当面の間、Drush 9をLagoonと一緒に使用する際の回避策をご紹介します。 + +### 基本的な考え方 + +Drush 9は新しいコマンド`drush site:alias-convert`を提供しており、Drush 8 形式のサイトエイリアスを Drush 9のYAML形式のサイトエイリアスに変換することができます。このコマンドは、Lagoonに現在存在するサイトエイリアスを一度だけエクスポートし、それらを`/app/drush/sites`ディレクトリに保存します。その後、これらのエイリアスは `drush sa`のようなコマンドを実行する際に使用されます。 -### 基本的なアイデア -Drush 9は新しいコマンド、`drush site:alias-convert`を提供します。これはDrush 8スタイルのサイトエイリアスをDrush 9のYAMLサイトエイリアススタイルに変換できます。これにより、現在Lagoonに存在するサイトエイリアスの一時的なエクスポートが作成され、`/app/drush/sites`に保存されます。これらは、`drush sa`のようなコマンドを実行する際に使用されます。 ### 準備 -`drush site:alias-convert`を使用するために、以下のことを行う必要があります: +`drush site:alias-convert`を使用する前に、以下の手順を行う必要があります: * `drush`フォルダ内の`aliases.drushrc.php`を`lagoon.aliases.drushrc.php`にリネームします。 ### サイトエイリアスの生成 -あなたは今、あなたのプロジェクトで以下のコマンドを実行することにより、あなたのDrushエイリアスを変換することができます。これは`cli`コンテナを使って行います: +`cli`コンテナを使用してプロジェクト内で以下のコマンドを実行すると、Drushエイリアスを変換できます: ```bash title="サイトエイリアスの生成" docker-compose exec cli drush site:alias-convert /app/drush/sites --yes ``` - 結果として得られるYAMLファイルをGitリポジトリにコミットすることは良い習慣で、これにより他の開発者がそれらを利用できます。 +生成されたYAMLファイルはGitリポジトリにコミットするのが良い習慣です。そうすることで、他の開発者も利用できるようになります。 ### サイトエイリアスの使用 -Drush 9では、すべてのサイトエイリアスにはグループがプレフィックスとして付けられています。私たちの場合、これは `lagoon` です。以下のようにして、そのプレフィックス付きのすべてのサイトエイリアスを表示できます: +Drush 9では、すべてのサイトエイリアスはグループ名でプレフィックスが付けられています。今回であれば、そのグループ名はlagoonです。以下のコマンドで、プレフィックス付きのすべてのサイトエイリアスを確認できます。 ```bash title="すべてのサイトエイリアスを表示" drush sa --format=list ``` -そしてそれらを使用するには: +エイリアスを利用するには、次のようにします: ```bash title="Drush サイトエイリアスの使用" drush @lagoon.main ssh @@ -44,7 +46,7 @@ drush @lagoon.main ssh ### サイトエイリアスの更新 -Lagoonで新しい環境が作成された場合、サイトエイリアスファイルを更新するために `drush site:alias-convert` を実行できます。このコマンドを実行しても `lagoon.site.yml` が更新されない場合は、まず `lagoon.site.yml` を削除してから `drush site:alias-convert` を再実行してみてください。 +Lagoonで新しい環境が作成された場合、`drush site:alias-convert`コマンドを実行して、サイトエイリアスファイル (.yml) を更新できます。このコマンドで`lagoon.site.yml`が更新されない場合は、最初に`lagoon.site.yml`を削除してから、もう一度`drush site:alias-convert`を実行してみてください。 ### ローカルからリモート環境へのDrush `rsync` @@ -54,16 +56,16 @@ Lagoonで新しい環境が作成された場合、サイトエイリアスフ drush rsync @self:%files @lagoon.main:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX ``` -これは、LagoonのタスクUIを使ってファイルをコピーするのではなく、一つのリモート環境から別のリモート環境に同期する場合にも適用されます。 環境。 +これは、LagoonのタスクUIを使用せずに、リモート環境間でファイルを同期する場合にも当てはまります。 -たとえば、`@lagoon.main`から`@lagoon.dev`へのファイルの同期を行いたい場合に、ローカルで`drush rsync @lagoon.main @lagoon.dev`を実行し、追加のパラメーターなしでこれを実行すると、「2つのリモートエイリアスを指定できません」というエラーが発生する可能性があります。 +たとえば、`@lagoon.main`から`@lagoon.dev`へファイルを同期したい場合、上記の追加パラメータなしでローカルで`drush rsync @lagoon.main @lagoon.dev`を実行すると、"Cannot specify two remote aliases" (2 つのリモートエイリアスは指定できません) というエラーが発生する可能性があります。 -これを解決するには、まず目的の環境にSSHで接続し`drush @lagoon.dev ssh`を実行し、次に上記と同様のパラメーターで`rsync`コマンドを実行します。 +これを解決するには、まず宛先の環境にSSHで接続 `drush @lagoon.dev ssh`し、上記と同様のパラメータを使用して `rsync`コマンドを実行する必要があります。 ```bash title="Drush rsync" drush rsync @lagoon.main:%files @self:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX ``` -リモートからローカル環境へ`rsync`する場合、これは必要ありません。 +上記の内容は、リモート環境からローカル環境へ `rsync`を使って同期する場合には必要ありません。 -また、私たちは[Drushのメンテナと協力して](https://github.com/drush-ops/drush/issues/3491)、これを自動的に注入する方法を見つけ出そうとしています。 +また、私たちは[Drushのメンテナと協力して](https://github.com/drush-ops/drush/issues/3491)、これを自動的に注入する方法を模索しています。 diff --git a/docs/ja/applications/drupal/first-deployment-of-drupal.md b/docs/ja/applications/drupal/first-deployment-of-drupal.md index f276f184b7..82f526af5f 100644 --- a/docs/ja/applications/drupal/first-deployment-of-drupal.md +++ b/docs/ja/applications/drupal/first-deployment-of-drupal.md @@ -2,51 +2,51 @@ ![excited](https://i.giphy.com/media/7kVRZwYRwF1ok/giphy-downsized.gif) -## 1. すべてが準備できていることを確認してください { #1-make-sure-you-are-all-set } +## 1. 準備を整えましょう { #1-make-sure-you-are-all-set } -初回のデプロイメントを成功させるためには、あなたの[DrupalプロジェクトがLagoon化されている](../../using-lagoon-the-basics/setup-project.md)ことと、Lagoonでプロジェクトが設定されていることを確認してください。そうでない場合でも心配はいりません！[ステップバイステップガイド](./step-by-step-getting-drupal-ready-to-run-on-lagoon.md)を参照して作業方法を確認してください。 +初回のデプロイメントを成功させるためには、[DrupalプロジェクトがLagoon化されている](../../using-lagoon-the-basics/setup-project.md)ことと、Lagoonでプロジェクトをセットアップしていることを確認してください。そうでない場合でも心配はいりません！[ステップバイステップガイド](./step-by-step-getting-drupal-ready-to-run-on-lagoon.md)を参照してください。 ## 2. プッシュ { #2-push } -Lagoonでは、デプロイするために設定されたブランチにプッシュすることで新しいデプロイメントを作成します。 +Lagoon を利用している場合、デプロイ用に設定されたブランチに push することで新しいデプロイを作成できます。 -新たにプッシュするコードがない場合でも心配はいりません、次のコマンドを実行できます。 +新しいコードをpushする必要がない場合でも心配はいりません、以下のコマンドを実行できます。 -```bash title="Git push" +```bash title="Gitにpush" git commit --allow-empty -m "go, go! Power Rangers!" git push ``` -これによりプッシュがトリガーされ、設定されたWebhookを通じてGitホスティングがこのプッシュについてLagoonに通知します。 +プッシュが実行されると、Gitホスティングが設定済みのWebhookを介してLagoonに通知します。 -すべてが正しければ、設定されたチャットシステムに通知が表示されます(これは親切なLagoon管理者によって設定されます): +すべて正常であれば、設定済みのチャットシステムに通知が表示されます。(設定についてはLagoon管理者に問い合わせてください): ![デプロイメント開始のSlack通知](../../images/first_deployment_slack_start.jpg) -これは、Lagoonがあなたのコードのデプロイを開始したことを示しています。コードのサイズによりますが、 ベースとコンテナの量により、これには数秒かかります。リラックスしてお待ちください。今何が起こっているか知りたい場合は、[Lagoonのビルドとデプロイプロセス](../../concepts-basics/build-and-deploy-process.md)をご覧ください。 +この通知は、Lagoonがコードのデプロイを開始したことを示しています。デプロイ時間は、コードベースのサイズとコンテナの数によって数秒かかります。しばらくお待ちください。現在の状況を確認したい場合は、[Lagoonのビルドとデプロイプロセス](../../concepts-basics/build-and-deploy-process.md)を参照してください。 -また、Lagoon UIをチェックして、任意のデプロイメントの進行状況を確認することもできます(Lagoonの管理者が情報を持っています)。 +デプロイの進行状況は、LagoonUIでも確認できます。(URLがわからない場合は、Lagoon管理者に問い合わせてください) ## 3. 失敗 { #3-a-fail } -`.lagoon.yml`で定義されたポストロールアウトタスクにより、`drush updb`や`drush cr`のようなタスクを実行したかもしれません。これらのDrushタスクは、環境内に存在しているデータベースに依存していますが、明らかにまだ存在していません。それを修正しましょう！読み進めてください。 +`.lagoon.yml`ファイルで定義されているデプロイ後処理タスクによっては、`drush updb`や`drush cr`などのタスクを実行している可能性があります。これらのDrushタスクは、環境内にデータベースが存在することを前提としていますが、デプロイ直後では当然ながらデータベースは存在しません。この問題を解決する方法を次に説明します。 -## 4. ローカルデータベースをリモートのLagoon環境に同期する { #4-synchronize-local-database-to-the-remote-lagoon-environment } +## 4. ローカルデータベースをリモートのLagoon環境に同期 { #4-synchronize-local-database-to-the-remote-lagoon-environment } -LagoonではフルのDrushサイトエイリアスをサポートしているため、ローカルデータベースをリモートのLagoon環境と同期することができます。 +Lagoonは完全なDrushサイトエイリアスをサポートしており、ローカルデータベースとリモートのLagoon環境を同期させることができます。 !!! Warning "警告" - 次のステップの前に、pygmyに公開キーについて教える必要があるかもしれません。 + 次のステップの前に、pygmyに公開キーを登録する必要があるかもしれません。 -`Permission denied (publickey)`のようなエラーが表示された場合は、ここに記載のドキュメンテーションをチェックしてみてください:[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) +`Permission denied (publickey)`などのエラーが発生した場合、こちらのドキュメントを参照してください:[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) -まず、Drushサイトエイリアスが表示されることを確認しましょう: +まずは、Drush サイトエイリアスを確認してみましょう: ```bash title="サイトエイリアスの取得" drush sa ``` -これにより、あなたの デプロイされた環境(`develop`にプッシュしたとします): +このコマンドを実行すると、現在デプロイ済みの環境が取得されます（最新の状態は、`develop`ブランチにプッシュした時点のものと仮定します）: ```bash title="返されたサイトエイリアス" [drupal-example]cli-drupal:/app$ drush sa @@ -83,17 +83,17 @@ git commit --allow-empty -m "行け、行け！ パワーレンジャー！" git push ``` -今回はすべてがグリーンになるはずです: +今度はすべて正常に動作するはずです: ![デプロイ成功！](../../images/first_deployment_slack_success.jpg) -通知内のリンクをクリックすると、Drupalサイトが全ての美しさでロードされるのが見えるはずです！まだ画像がない可能性がありますが、それは[ステップ5](#5-synchronize-local-files-to-the-remote-lagoon-environment)で対処します。 +通知内のリンクをクリックすると、Drupalサイトがすべての機能を備えてロードされた状態を確認できます。おそらくまだ画像は表示されていませんが、それは[ステップ5](#5-synchronize-local-files-to-the-remote-lagoon-environment)で処理します。 -それでも失敗する場合は、ログリンクを確認して詳細情報を得てください。 +デプロイが依然として失敗する場合は、詳細情報を確認するためにログリンクをクリックしてください。 -## 5. ローカルファイルをリモートのLagoon環境に同期する { #5-synchronize-local-files-to-the-remote-lagoon-environment } +## 5. ローカルファイルをリモートのLagoon環境に同期 { #5-synchronize-local-files-to-the-remote-lagoon-environment } -おそらく推測できたでしょう:Drushでそれを行うことができます: +おそらく予想通りですが、Drushを使って同期できます: ```bash title="Drush rsync" drush rsync @self:%files @develop:%files @@ -107,30 +107,38 @@ You will delete files in drupal-example-develop@ssh.example.com:/app/web/sites/d Do you really want to continue? (y/n): y ``` -その理由は、Drupalがファイルディレクトリのパスを解決できないからです。これはおそらく、Drupalが完全に設定されていないか、データベースが欠けているためです。回避策としては`drush rsync @self:sites/default/files @develop:sites/default/files`を使用できますが、ローカルとリモートのDrupalを実際に確認することをお勧めします(`drush status`でファイルディレクトリが正しく設定されているかどうかをテストできます)。 +しかし、場合によっては、このように正しく表示されないこともある： + +```bash title="Drush rsync results" +[drupal-example]cli-drupal:/app$ drush rsync @self:%files @develop:%files +You will delete files in drupal-example-develop@ssh.example.com:'/app/web/%files' and replace with data from '/app/web/%files'/ +Do you really want to continue? (y/n): +``` + +この理由は、Drupalがファイルディレクトリのパスを解決できないためです。これはおそらく、Drupalが完全設定されていないか、データベースが存在しないことが原因です。回避策としては`drush rsync @self:sites/default/files @develop:sites/default/files`を使用できます。しかし、実際にはローカルとリモートの Drupal を確認することをお勧めします (`drush status`コマンドを使用して、ファイルディレクトリが正しく設定されているかどうかを確認できます) -## 6. 完了しました { #6-its-done } +## 6. 完了 { #6-its-done } -Lagoonがビルドとデプロイを完了すると、チャットシステムに2回目の通知を送信します。以下のような感じです: +Lagoonがビルドとデプロイを完了すると、チャットシステムに次のような2回目の通知が送信されます。: ![完全なデプロイメントのSlack通知。](../../images/first_deployment_slack_2nd_success.jpg) -これには以下の情報が表示されます: +通知は次のような内容を示しています: * デプロイされたプロジェクト * デプロイされたブランチとGit SHA -* ビルドとデプロイメントの完全なログへのリンク +* ビルドとデプロイのログへのリンク * 環境にアクセスできるすべてのルート(URL)へのリンク -以上です！それが難しすぎなければよいのですが、私たちはDevOpsを使いやすくすることを目指しています。 +これで作業は完了です! DevOpsを簡単にできるようにすることが私たちの目標です。 -## しかし、他のブランチや本番環境はどうですか？ { #but-wait-how-about-other-branches-or-the-production-environment } +## しかし、他のブランチや本番環境はどうなるのでしょうか？ { #but-wait-how-about-other-branches-or-the-production-environment } -それがLagoonの美点です:まったく同じです。本番ブランチとして定義したブランチ名をプッシュすると、そのブランチがデプロイされます。 +Lagoonの優れた点は、まったく同じ方法で処理できることです。本番環境ブランチとして定義したブランチ名をプッシュすると、そのブランチがデプロイされます。 -## 失敗？心配しないで { #failure-dont-worry } +## デプロイの失敗 { #failure-dont-worry } -デプロイメントが失敗しましたか？ああ、それは大変です！でも、私たちは助けるためにここにいます: +デプロイが失敗しましたか？ 心配しないでください。ヘルプを用意しています: -1. エラー通知の中の `logs` リンクをクリックします。それは失敗が発生したデプロイメントプロセスのどこであったかを教えてくれます。 -2. それがわからない場合は、Lagoonの管理者に尋ねてみてください。彼らは助けるためにここにいます！ +1. エラー通知内の `logs` リンクをクリックします。デプロイプロセスでどこで失敗したかがわかります。 +2. 問題が解決できない場合は、Lagoon管理者に連絡してください。サポートいたします! diff --git a/docs/ja/applications/drupal/index.md b/docs/ja/applications/drupal/index.md index a301f44830..03b7f5995b 100644 --- a/docs/ja/applications/drupal/index.md +++ b/docs/ja/applications/drupal/index.md @@ -1,8 +1,8 @@ -# Lagoon上のDrupal +# 概要 -LagoonはDrupalサイトをホストするために作られました(いや、本当に、少なくとも初めはそうでした！) +LagoonはDrupalサイトをホストするために作られました(いや、本当に、少なくとも最初はそうでした！) -このセクションでは、Drupalで使用するためにカスタマイズされたさまざまなサービスについての詳細情報を見つけることができます。 +このセクションでは、Drupalで使用するためにカスタマイズされた様々なサービスに関する詳細情報を見つけることができます。 ## `drupal_integrations` Drupalスキャフォールディングパッケージ @@ -10,4 +10,4 @@ LagoonはDrupalサイトをホストするために作られました(いや、 ## `lagoon-logs` Drupalモジュール -[drupal.org](https://www.drupal.org/project/lagoon_logs)で利用可能な`lagoon_logs`モジュールは、Lagoon上のDrupalのためのゼロ設定ロギングを提供します。 +[drupal.org](https://www.drupal.org/project/lagoon_logs)で利用可能な`lagoon_logs`モジュールは、Lagoon上のDrupalに対して設定不要のロギングを提供します。 diff --git a/docs/ja/applications/drupal/integrate-drupal-and-fastly.md b/docs/ja/applications/drupal/integrate-drupal-and-fastly.md index d2a775d98e..1cc68109eb 100644 --- a/docs/ja/applications/drupal/integrate-drupal-and-fastly.md +++ b/docs/ja/applications/drupal/integrate-drupal-and-fastly.md @@ -2,25 +2,25 @@ ## 前提条件 -* Drupal 7+ +* Drupal 7以降 * FastlyサービスID * パージ権限を持つFastly APIトークン -## URLベースのパージングを持つDrupal 7 +## Drupal 7でのURLベースのパージ 1. [Fastly Drupalモジュール](https://www.drupal.org/project/fastly)をダウンロードしてインストールします。 2. FastlyサービスIDとAPIトークンを設定します。 -3. 必要に応じてWebhooksを設定します(例えば、キャッシュパージが送信されたときにSlackにピングを送るなど)。 -4. Drupal 7ではURLベースのパージングのみが可能です(シンプルパージング)。 +3. 必要に応じてWebhooksを設定します(例えば、キャッシュパージが送信されたときにSlackに通知するなど)。 +4. Drupal 7ではURLベースのパージ(簡易パージ)のみが可能です。 5. `settings.php`でDrupalのクライアントIPを変更します: ```php title="Drupal 7のためのsettings.phpの変更" $conf['reverse_proxy_header'] = 'HTTP_TRUE_CLIENT_IP'; ``` -## キャッシュタグパージングを持つDrupal 10+ +## Drupal 10以降でのキャッシュタグパージ -Composerを使用してモジュールの最新バージョンを取得します: +Composerを使って最新バージョンのモジュールを取得します: ```bash title="Fastly Drupalモジュールと依存関係のダウンロード" composer require drupal/fastly drupal/http_cache_control drupal/purge @@ -32,47 +32,47 @@ composer require drupal/fastly drupal/http_cache_control drupal/purge * `fastlypurger` * `http_cache_control` (2.x) * `purge` -* `purge_ui` (技術的にはオプションですが、本番環境で有効にしておくと非常に便利です) +* `purge_ui` (技術的には必須ではありませんが、本番環境で有効にすると非常に便利です) * `purge_processor_lateruntime` * `purge_processor_cron` * `purge_queuer_coretags` -* `purge_drush` (Drを通じてパージするために便利です) Drush、ここに[コマンドのリスト](https://git.drupalcode.org/project/purge/-/blob/8.x-3.x/README.md#drush-commands)があります。 +* `purge_drush` (Drushを使ったパージに便利です。こちらに[コマンドのリスト](https://git.drupalcode.org/project/purge/-/blob/8.x-3.x/README.md#drush-commands)があります) -### DrupalのFastlyモジュールを設定する +### DrupalでFastlyモジュールを設定します -FastlyのサービスIDとAPIトークンを設定します。サイトIDは自動的に生成されます。ランタイム環境変数を使用するか、`/admin/config/services/fastly`で見つけることができる設定フォームを編集することができます: +FastlyサービスIDとAPIトークンを設定します。サイトIDは自動的に生成されます。実行時環境変数を利用するか、`/admin/config/services/fastly`にある設定フォームを編集できます: * `FASTLY_API_TOKEN` * `FASTLY_API_SERVICE` -#### パージオプションを設定する +#### パージオプションの設定 -* キャッシュタグのハッシュ長:4 -* パージ方法:ソフトパージを使用する +* キャッシュタグハッシュ長: 4文字 +* パージ方式: ソフトパージを使用 -ほとんどのサイトでは`4`文字のキャッシュタグが十分で、_数百万_のエンティティを持つサイトでは`5`文字のキャッシュタグが適している可能性があります(キャッシュタグの衝突を減らすため)。 +ほとんどのサイトでは`4`文字のキャッシュタグで十分ですが、数百万のエンティティを持つサイトでは、キャッシュタグの衝突を減らすために`5`文字の方が良いでしょう。 !!! Note "注意:" - ソフトパージングを使用するべきです。これは、Fastlyのオブジェクトが完全に追い出されるのではなく、古いものとしてマークされ、元の場所がダウンしている場合に使用できるようになることを意味します([古くなったものを提供する](https://developer.fastly.com/solutions/tutorials/stale/)機能と共に)。 + ソフトパージを使用してください。Fastly内のオブジェクトは古くなったとマークされ、完全に削除されるわけではないので、オリジンがダウンしている場合にも使用することができます([古くなったものを提供する](https://developer.fastly.com/solutions/tutorials/stale/)機能を使用した場合) ![パージング用のFastly管理UI。キャッシュタグの長さとソフトパージの使用に関する設定オプションを示しています](../images/fastly-cachetag.png) -#### 古いコンテンツのオプションを設定する +#### 古いコンテンツのオプションの設定 -サイトに適したオプションを設定します。最小1時間(` 3600`)、最大1週間(`604800`)。一般的には以下のような設定が適しています: +サイトに適したオプションを設定してください。最小1時間(` 3600`)、最大1週間(`604800`)です。以下のような設定が一般的です: 1. 再検証時にステール - オン、`14440`秒 2. エラー時にステール - オン、`604800`秒 ![Fastly管理者UIのステール設定](../images/fastly-swr.png) -必要に応じてウェブフックを設定します(キャッシュパージが送信されたときに例えばSlackにピングを送ることができます)。 +必要に応じてWebhookを設定することもできます(たとえば、キャッシュパージが送信されたときにSlackに通知を送るなど) ![Fastly管理者UIのウェブフック設定](../images/fastly-webhook.png) ### Purgeモジュールの設定 -パージページ`/admin/config/development/performance/purge`を訪れます。 +パージページ`/admin/config/development/performance/purge`にアクセスします。 以下のオプションを設定します: @@ -85,18 +85,18 @@ FastlyのサービスIDとAPIトークンを設定します。サイトIDは自 #### キュー -* キューワー:コアタグキューワー、パージブロック(複数) +* キューワー:コアタグキューワー、パージブロック(複数可) * キュー:データベース -* プロセッサ:コアプロセッサ、レイトランタイムプロセッサ、パージブロック(複数) +* プロセッサ:コアプロセッサ、レイトランタイムプロセッサ、パージブロック(複数可) ![パージ管理者UIのキュー設定](../images/fastly-queue.png) -これは、Drupalの組み込みコアタグキューワー(キューにタグを追加)を使用し、キューはデータベース(デフォルト)に保存され、キューは次のものによって処理されることを意味します。 +これは、Drupalの組み込みのコアタグキューワーを使用してキューにタグを追加し、キューはデータベースに保存され (デフォルト)、以下のプロセッサによって処理されることを意味します。 * Cronプロセッサ * レイトランタイムプロセッサ -Cronプロセッサが動作するためには、Cronが動作することを確認する必要があります。 あなたのサイトで実行します。理想的には毎分です。`cli`ポッドで手動で実行して、`purge_processor_cron_cron()`がエラーなく実行されていることを確認できます。 +cronプロセッサを実行するには、サイトでcronが実行されていることを確認する必要があります (理想的には1分ごと)。`cli`ポッドでcronを手動実行して、`purge_processor_cron_cron()`がエラーなく実行されていることを確認してください。 ```bash title="cronの開始" [drupal8]production@cli-drupal:/app$ drush cron -v @@ -104,36 +104,36 @@ Cronプロセッサが動作するためには、Cronが動作することを確 [notice] purge_processor_cron_cron()の実行を開始、node_cron()の実行は21.16msかかりました。 ``` -`遅延ランタイムプロセッサ`は各ページ読み込みの`hook_exit()`で実行され、これはキューに入ってくるほぼ同時にパージを処理するのに有用です。 +レイアウトパージは、ページロードごとにhook_exit()で実行される`Late runtime processor`によって処理されます。これにより、パージ要求がキューに追加されるとほぼ同時に処理することができ、非常に便利です。 -両方を持つことで、パージができるだけ早く行われることを保証します。 +両方の方式を併用することで、パージが可能な限り迅速に実行されることが保証されます。 ### 最適なキャッシュヘッダー設定 -初期設定では、DrupalはブラウザとFastlyで異なるキャッシュ寿命を設定する力を持っていません。したがって、Drupalで長いキャッシュ寿命を設定すると、ブラウザがページをキャッシュしている場合、エンドユーザーはそれらを見ることができません。[HTTP Cache Control](https://www.drupal.org/project/http_cache_control)モジュールの`2.x`バージョンをインストールすると、キャッシュの何がどれだけの期間有効であるかについて、より多くの柔軟性を得ることができます。 +Drupalは標準設定では、ブラウザとFastlyで異なるキャッシュ有効期限を設定する機能がありません。そのため、Drupalで長いキャッシュ有効期限を設定しても、ブラウザが既にページをキャッシュしている場合、ユーザーは変更を確認できません。[HTTP Cache Control](https://www.drupal.org/project/http_cache_control)モジュールの`2.x`バージョンをインストールすると、さまざまなキャッシュに対して、より詳細な有効期限設定が可能になります。 -ほとんどのサイトでは、適切なデフォルト設定は次のとおりです。 +ほとんどのサイトでは、以下のような設定が妥当なデフォルト値になるでしょう。 -* 共有キャッシュの最大寿命:1ヶ月 -* ブラウザキャッシュの最大寿命:10分 -* 404キャッシュの最大寿命:15分 分 -* 302キャッシュの最大寿命:1時間 -* 301キャッシュの最大寿命:1時間 -* 5xxキャッシュの最大寿命:キャッシュなし +* 共有キャッシュ最大有効期限: 1ヶ月 +* ブラウザキャッシュ最大有効期限: 10分 +* 404 エラーキャッシュ最大有効期限: 15分 +* 302 リダイレクトキャッシュ最大有効期限: 1時間 +* 301 リダイレクトキャッシュ最大有効期限: 1時間 +* 5xx エラーキャッシュ最大有効期限: キャッシュしない !!! Note "注意:" - これは、あなたのサイトがページ上に存在するすべてのコンテンツを表現する正確なキャッシュタグを持っていることに依存しています。 + この設定は、サイト上のすべてのコンテンツに対して適切なキャッシュタグが設定されていることを前提としています。 -### 真のクライアントIP +### 実際のクライアントIP -私たちはFastlyを設定して、実際のクライアントIPをHTTPヘッダー`True-Client-IP`で返すようにしています。`settings.php`で以下の変更を行うことで、Drupalがこのヘッダーを尊重するように設定することができます: +Fastlyは、実際クライアントのIPアドレスを`True-Client-IP`HTTPヘッダーで返送するように設定されています。`settings.php`で以下の変更を行うことで、Drupalがこのヘッダーを尊重するように設定することができます: ```php title="Drupal < 8.7.0用のsettings.phpの変更" $settings['reverse_proxy'] = TRUE; $settings['reverse_proxy_header'] = 'HTTP_TRUE_CLIENT_IP'; ``` -しかし、Drupal 8.7.0では、[この機能を削除する変更がありました](https://www.drupal.org/node/3030558)。以下のスニペットを使用して同じ目標を達成することができます +しかし、Drupal 8.7.0では、[この機能が削除されました](https://www.drupal.org/node/3030558)。以下のコードスニペットで同様の動作を実現できます。 ```php title="Drupal >= 8.7.0用のsettings.phpの変更" /** @@ -148,13 +148,13 @@ if (isset($_SERVER['HTTP_TRUE_CLIENT_IP'])) { ```php title="settings.php" fastly: - fastly:purge:all (fpall) サービス全体をパージ。 - fastly:purge:key (fpkey) キーでキャッシュをパージする。 - fastly:purge:url (fpurl) URLでキャッシュをパージする。 + fastly:purge:all (fpall) サービス全体をパージ + fastly:purge:key (fpkey) キーでキャッシュをパージ + fastly:purge:url (fpurl) URLでキャッシュをパージ ## cURLを使用してFastlyキャッシュヘッダーを表示する -この関数を使用してください:(LinuxとMac OSXで動作します) +以下の関数を使用してください:(LinuxとMac OSXで動作します) ```bash title="cURL function" function curlf() { curl -sLIXGET -H 'Fastly-Debug:1' "$@" | grep -iE 'X-Cache|Cache-Control|Set-Cookie|X-Varnish|X-Hits|Vary|Fastly-Debug|X-Served|surrogate-control|surrogate-key' } @@ -173,26 +173,26 @@ x-cache-hits: 0, 1 vary: Cookie, Accept-Encoding ``` -上記のヘッダーから次のことが分かります: +上記のヘッダーから、以下の情報が確認できます: -* HTML ページはキャッシュ可能です +* HTMLページはキャッシュ可能 * ブラウザはページを601秒間キャッシュします * Fastlyはページを32日間(`2764800`秒)キャッシュします -* 階層型キャッシュが適用されています(エッジPoPはウェリントン、シールドPoPはフランスに位置しています) +* 階層型キャッシュが有効(WellingtonのエッジPoP、フランスのシールドPoP) * HTMLページはエッジPoPでキャッシュヒットしました ### Fastlyに手動でパージリクエストを送信する -特定のページを手動でキャッシュから削除したい場合、方法があります。 +特定のページを手動でキャッシュから削除したい場合、いくつかの方法があります。 ```bash title="単一のURLでFastlyをパージ" curl -Ssi -XPURGE -H 'Fastly-Soft-Purge:1' -H "Fastly-Key:$FASTLY_API_TOKEN" https://www.example.com/subpage ``` -キャッシュタグでパージすることもできます: +キャッシュタグを指定してパージすることもできます: ```bash title="キャッシュタグでFastlyをパージ" curl -XPOST -H 'Fastly-Soft-Purge:1' -H "Fastly-Key:$FASTLY_API_TOKEN" https://api.fastly.com/service/$FASTLY_API_SERVICE/purge/ ``` -また、これを少し楽にするために[Fastly CLI](https://github.com/fastly/cli)を使用することもできます。 +[Fastly CLI](https://github.com/fastly/cli)を使用すると、より簡単にパージを行うことができます。 diff --git a/docs/ja/applications/drupal/phpunit-and-phpstorm.md b/docs/ja/applications/drupal/phpunit-and-phpstorm.md index 75ae1c470e..738bf38c08 100644 --- a/docs/ja/applications/drupal/phpunit-and-phpstorm.md +++ b/docs/ja/applications/drupal/phpunit-and-phpstorm.md @@ -1,18 +1,18 @@ -# PHPUnit と PhpStorm +# PHPUnitとPhpStorm !!! Note "注意:" このドキュメントでは、以下を前提としています: - - Dockerを使用しています。 + - Dockerを使用している - - [`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)ファイルを含む標準的なAmazee/Lagoonプロジェクトを使用しています。 + - [`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)ファイルを持つ標準的なAmazee/Lagoonプロジェクトを使用している - - Macを使用しています - 他のオペレーティングシステムでも動作するはずですが、フォルダ構造や一部の設定が異なる場合があります。 + - Macを使用している(他のOSでも動作するはずですが、フォルダ構造や設定が異なる場合があります) ## プロジェクトの設定 -1. `/core/phpunit.xml.dist` ファイルを `/core/phpunit.xml` に複製します。 -2. `/core/phpunit.xml` を編集し、以下の変数を入力します: +1. `/core/phpunit.xml.dist`ファイルを複製し、`/core/phpunit.xml`という名前で保存します。 +2. `/core/phpunit.xml`を編集し、以下の変数を設定します: * **SIMPLETEST\_DB**: `mysql://drupal:drupal@mariadb:3306/drupal#db` * **SIMPLETEST\_BASE\_URL**: `` @@ -21,8 +21,8 @@ ### Dockerの設定 -1. PhpStormで、**ファイル > 設定 > ビルド、実行、デプロイ > Docker**に移動します。 -2. `+`をクリックします。 +1. PhpStormで、**ファイル > 設定 > ビルド、実行、デプロイ > Docker**へ移動します。 +2. `+`ボタンをクリックします。 3. `Docker for Mac`を選択します。 ![Dockerの設定](../../images/1-docker-setup.png) @@ -31,11 +31,12 @@ **新しいCLIインタープリタを追加:** -1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP**に移動します。 -2. `...`をクリックし、次に`+`をクリックします。 +1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP**へ移動します。 +2. `...`ボタンをクリックし、 `+`ボタンをクリックします。 3. 次に、Docker、vagrantなどから新しいCLIインタープリタを追加を選択します。 -4. 次の設定を使用します: - * サーバー: `` * 設定ファイル: `./docker-compose.yml` +4. 以下の設定を使用します: +* サーバー: `` +* 設定ファイル: `./docker-compose.yml` * サービス: `cli` * ライフサイクル: `既存のコンテナに接続 ('docker-compose exec')` 5. パスのマッピング: @@ -48,9 +49,9 @@ **リモートインタープリタの追加:** -1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP > テストフレームワーク**に移動します。 -2. `+`をクリックして、`PHPUnit by Remote Interpreter`を選択します。 -3. 次の設定を使用します: +1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP > テストフレームワーク**へ移動します。 +2. `+`ボタンをクリックして、`PHPUnit by Remote Interpreter`を選択します。 +3. 以下の設定を使用します: * CLIインタープリタ: `` * パスマッピング: ` -> /app` * PHPUnit: `Use Composer autoloader` @@ -62,30 +63,30 @@ #### ランナーテンプレートの設定/構成 1. **ランナーの設定:** - 1. PhpStormで、**実行 > 設定の編集... > テンプレート > PHPUnit**に移動します。 - 2. 次の設定を使用します: + 1. PhpStormで、**実行 > 設定の編集... > テンプレート > PHPUnit**へ移動します。 + 2. 以下の設定を使用します: - 1. テストスコープ: `設定ファイルで定義されている` + 1. テストスコープ: `Defined in the configuration file` - 2. 通訳者: `` + 2. インタープリター: `` ![ランナーの設定](../../images/4-configure-runner.png) !!! Note "注意:" - Macを使用していない場合、この内容は異なる場合があります。 + Mac以外のOSでは手順が異なる場合があります。 ## 最終チェック -### テストを実行する前に行う最終チェック +### テストを実行する前に、いくつかの確認が必要です。 -1. プロジェクトが起動し、稼働していること: `$ docker-compose up -d` -2. プロジェクトがエラーなく動作していること、サイトを訪れてすべてが期待通りに動作していることを確認する - これは100％必要ではありませんが、正常に動作していることを知っておくとよいでしょう。 -3. テストを実行する準備が整っているはずです！ +1. プロジェクトが起動していることを確認します:`$ docker-compose up -d` +2. プロジェクトがエラーなく動作していることを確認します (サイトにアクセスして、すべて想定通りに動作していることを確認してください)。必ずしも必要ではありませんが、正常に動作していることを確認しておくと安心です。 +3. これでテストを実行する準備が整いました！ -## 実行の準備完了 +## 実行準備完了 -上記の設定を行ったら、実行したいテストに移動し、緑色の矢印を押すだけで簡単に実行できるはずです！ +上記の設定が完了していれば、実行したいテストに移動し、緑色の矢印をクリックするだけで簡単に実行できます！ -このボタンを押すと、PhpStormはDockerを使用してCLIコンテナに入り、設定に基づいてPHPUnitの実行を開始します。 +PhpStormは、Dockerを使用してCLIコンテナに入り、設定に基づいてPHPUnitを実行します。 ![これが実際の動作です、どうぞご覧ください!!](../../images/5-going-green-1-.gif) diff --git a/docs/ja/applications/drupal/services/README.md b/docs/ja/applications/drupal/services/README.md index 3d1bb5e734..9df7cd49eb 100644 --- a/docs/ja/applications/drupal/services/README.md +++ b/docs/ja/applications/drupal/services/README.md @@ -1,25 +1,25 @@ -# サービス +# 概要 ## MariaDBは、オープンソースのMySQLの後継者です [DrupalとMariaDBについて学ぶ](mariadb.md) -[プレーンなMariaDBイメージに関するドキュメンテーション](../../../docker-images/mariadb.md)(このMariaDB-Drupalイメージはこれをベースに作成されています)。 +[標準的なMariaDBイメージに関するドキュメンテーション](../../../docker-images/mariadb.md)(このMariaDB-Drupalイメージはこれをベースに作成されています) -## Redisは高速なオープンソースのインメモリキーバリューデータストアで、データベース、キャッシュ、メッセージブローカー、キューとして利用できます +## Redisは、データベース、キャッシュ、メッセージブローカー、キューとして使用するための、高速でオープンソースのインメモリ・キーバリュー・データストアです -[DrupalとRedisについて学ぶ。](../services/redis.md) +[DrupalとRedisについて学ぶ](../services/redis.md) -[Redis-persistentイメージに関するドキュメンテーション。](../../../docker-images/redis.md) +[Redis-persistentイメージに関するドキュメンテーション](../../../docker-images/redis.md) ## Solrはオープンソースの検索プラットフォームです -[DrupalとSolrについて学ぶ。](../services/solr.md) +[DrupalとSolrについて学ぶ](../services/solr.md) -[プレーンなSolrイメージに関するドキュメンテーション](../../../docker-images/solr.md) \(このSolr-Drupalイメージはこれをベースに作成されています\)。 +[標準的なSolrイメージに関するドキュメンテーション](../../../docker-images/solr.md) \(このSolr-Drupalイメージはこれをベースに作成されています\) -## Varnishは、ウェブサイトの速度を向上させるための強力なオープンソースのHTTPエンジンおよび逆HTTPプロキシです +## Varnishは、ウェブサイトの速度を向上させるための強力なオープンソースのHTTPエンジンおよびリバースHTTPプロキシです [DrupalとVarnishについて学ぶ](../services/varnish.md) -[プレーンなVarnishイメージに関するドキュメンテーション](../../../docker-images/varnish.md) \(このVarnish-Drupalイメージはこれをベースに作成されています\)。 +[標準的なVarnishイメージに関するドキュメンテーション](../../../docker-images/varnish.md) \(このVarnish-Drupalイメージはこれをベースに作成されています\) diff --git a/docs/ja/applications/drupal/services/mariadb.md b/docs/ja/applications/drupal/services/mariadb.md index a96eadf1c4..0bb3b1dad2 100644 --- a/docs/ja/applications/drupal/services/mariadb.md +++ b/docs/ja/applications/drupal/services/mariadb.md @@ -2,42 +2,42 @@ description: MariaDBは、オープンソースのMySQLの後継者です。 --- -# MariaDB-Drupal +# MariaDB -Lagoonの `mariadb-drupal` Dockerイメージ [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb-drupal/10.5.Dockerfile) は、LagoonのDrupalプロジェクト内で使用するためにカスタマイズされた [`mariadb`](../../../docker-images/mariadb.md) イメージです。 `mariadb` イメージとの違いは、初期データベースのセットアップのみで、これはいくつかの環境変数によって行われます: +Lagoonの `mariadb-drupal` Dockerイメージ [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb-drupal/10.5.Dockerfile) は、LagoonのDrupalプロジェクト内で使用するためにカスタマイズされた [`mariadb`](../../../docker-images/mariadb.md) イメージです。 `mariadb` イメージと異なるのは、いくつかの環境変数によって行われるデータベースの初期設定だけです: | 環境変数 | デフォルト | 説明 | | :--- | :--- | :--- | -| `MARIADB_DATABASE` | drupal | 起動時に作成されるDrupalデータベース。 | -| `MARIADB_USER` | drupal | 起動時に作成されるデフォルトのユーザー。 | -| `MARIADB_PASSWORD` | drupal | 起動時に作成されるデフォルトのユーザーのパスワード。 | +| `MARIADB_DATABASE` | drupal | 起動時に作成されるDrupalデータベース | +| `MARIADB_USER` | drupal | 起動時に作成されるデフォルトユーザー | +| `MARIADB_PASSWORD` | drupal | 起動時に作成されるデフォルトユーザーのパスワード | -`LAGOON_ENVIRONMENT_TYPE` 変数が `production` に設定されている場合、パフォーマンスは `MARIADB_INNODB_BUFFER_POOL_SIZE=1024` および `MARIADB_INNODB_LOG_FILE_SIZE=256` を使用してそれに応じて設定されます。 +`LAGOON_ENVIRONMENT_TYPE` 変数が `production` に設定されている場合、パフォーマンスは `MARIADB_INNODB_BUFFER_POOL_SIZE=1024` および `MARIADB_INNODB_LOG_FILE_SIZE=256` に設定することで最適化されます。 -## その他のMariaDB [ログ](../../../logging/logging.md) +## MariaDB [ログ](../../../logging/logging.md)の追加設定 -開発の過程で、クエリログまたはスロークエリログを有効にする必要があるかもしれません。そうするためには、環境変数 `MARIADB_LOG_SLOW` または `MARIADB_LOG_QUERIES` を設定します。これは ` `docker-compose.yml`. +開発の過程で、クエリログまたはスロークエリログを有効にする必要があるかもしれません。そうするためには、環境変数 `MARIADB_LOG_SLOW` または `MARIADB_LOG_QUERIES` を設定します。これは`docker-compose.yml`で行うことができます. ## ホストからMySQLコンテナへの接続 -Dockerコンテナ内のMySQLデータベースに[Sequel Pro](http://www.sequelpro.com/)、[MySQL Workbench](http://www.mysql.com/products/workbench/)、[HeidiSQL](http://www.heidisql.com/)、[DBeaver](http://dbeaver.jkiss.org/)、`mysql-cli`などの外部ツールから接続したい場合、IPアドレスとポート情報を取得する方法をここに示します。 +[Sequel Pro](http://www.sequelpro.com/)、[MySQL Workbench](http://www.mysql.com/products/workbench/)、[HeidiSQL](http://www.heidisql.com/)、[DBeaver](http://dbeaver.jkiss.org/)、標準的な`mysql-cli`などの外部ツールを使って、Dockerコンテナ内のMySQLデータベースに接続したい場合、IPアドレスとポート情報を取得する方法を以下に示します。 -### コンテナから公開MySQLポートを取得する +### コンテナから公開された MySQL ポートを取得する -デフォルトでは、Dockerは各コンテナ開始時にMySQLの公開ポートをランダムに割り当てます。これはポートの衝突を防ぐために行われます。 +デフォルトでは、Dockerは各コンテナ起動時にMySQLの公開ポートをランダムに割り当てます。これはポートの衝突を防ぐために行われます。 `docker`を使って公開ポートを取得するには: -実行:`docker port [container_name]`。 +`docker port [container_name]`を実行 ```text title="ポートを取得する" $ docker port drupal_example_mariadb_1 3306/tcp -> 0.0.0.0:32797 ``` -または、Drupalリポジトリ内で`docker-compose`を使って: +または、Drupalリポジトリ内の`docker-compose`を使用して: -実行:`docker-compose port [service_name] [internal_port]`。 +`docker-compose port [service_name] [internal_port]`を実行 ```bash title="ポートを設定する" docker-compose port mariadb 3306 @@ -48,17 +48,17 @@ docker-compose port mariadb 3306 開発中に外部のデータベースツールを使用している場合、MySQL接続ポートを常に確認し設定するのは面倒になるかもしれません。 -静的ポートを設定するには、編集してください あなたの `docker-compose.yml` でのサービス定義。 +静的ポートを設定するには、`docker-compose.yml`のサービス定義を編集します。 ```yaml title="docker-compose.yml" mariadb: ... ports: - - "33772:3306" # ポート3306をホストポートの33772で公開します。これを行うことで、ポートの衝突を管理する責任があなたにあります。 + - "33772:3306" # ポート3306をホストポートの33772を指定して公開します。これを行うことで、ポートの衝突を管理する責任があることに注意すること。 ``` !!! Warning "警告" - 静的ポートを設定すると、ポートの衝突を管理する責任があなたにあります。 + 静的ポートを設定することで、ポートの衝突を管理する責任が生じます。 ### MySQLへの接続 diff --git a/docs/ja/applications/drupal/services/nginx.md b/docs/ja/applications/drupal/services/nginx.md index 531928e69e..62ab6bf3f2 100644 --- a/docs/ja/applications/drupal/services/nginx.md +++ b/docs/ja/applications/drupal/services/nginx.md @@ -1,38 +1,38 @@ -# NGINX-Drupal +# NGINX [Lagoonの`nginx-drupal` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/nginx-drupal/Dockerfile)。Drupalと連携するように最適化されています。[Lagoonの`nginx`イメージ](../../../docker-images/nginx.md)に基づいています。 ## Lagoonの適応 { #lagoon-adaptions } -このイメージは、Lagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています: +このイメージは、Lagoonで使用するために準備されています。そのため、すでにいくつかのことが行われています: * フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に適応されるため、このイメージはランダムなユーザーで動作します。 -* `drupal.conf`の設定ファイルをできるだけクリーンでカスタマイズ可能に保つために、ファイルの主要なセクション(`server`、`location /`、`location @drupal`、`location @php`)に`include`指示を追加しました。 +* `drupal.conf`の設定ファイルをできるだけシンプルで、カスタマイズしやすいようにするために、ファイルのメインセクション(`server`、`location /`、`location @drupal`、`location @php`)に`include`指示を追加しました。 * [`Drupal.conf`カスタマイズ](#drupalconf-customization)のセクションでさらなる情報を提供します。 ## 含まれるDrupal設定 - `drupal.conf`{ #included-drupal-configuration-drupalconf } -このイメージには、Drupal 7, 8, 9の完全なNGINX作業設定が含まれています。いくつかの追加機能も含まれています: +このイメージには、Drupal 7, 8, 9の完全なNGINX動作設定が含まれています。以下のような追加機能も含まれています: -* [`humanstxt` Drupalモジュール](https://www.drupal.org/project/humanstxt)のサポート。 -* [`robotstxt` Drupalモジュール](https://www.drupal.org/project/ robotstxt)。 +* [`humanstxt` Drupalモジュール](https://www.drupal.org/project/humanstxt)のサポート +* [`robotstxt` Drupalモジュール](https://www.drupal.org/project/ robotstxt) * ローカル開発用の`vagrant`ディレクトリへのアクセスを禁止します。 ## `Drupal.conf`のカスタマイズ { #drupalconf-customization } -`drupal.conf`ファイルは、Drupal用に最適化された`nginx`設定ファイルのカスタマイズ版です。顧客はそれをカスタマイズするための異なる方法を持っています: +`drupal.conf`ファイルは、`nginx`設定ファイルをDrupal用にカスタマイズしたものです。顧客によってカスタマイズ方法は様々です: -* _それを修正する_ \(エラーの場合、サポートが困難\)。 -* `*.conf`ファイルを通じた組み込みのカスタマイズを使用。 +* 修正が困難 \(エラーが発生した場合のサポートが難しい \) +* `*.conf`ファイルを使用した組み込みのカスタマイズ -`drupal.conf`ファイルはいくつかのセクションに分割されています。私たちがカスタマイズに含めたセクションは次の通りです: +`drupal.conf`ファイルはいくつかのセクションに分かれています。私たちがカスタマイズに含めたセクションは以下の通りです: * `server` * `location /` * `location @drupal` * `location @php`. -各セクションには**二つ**のインクルードがあります: +このセクションには、それぞれ2つのインクルードがあります: * `*_prepend.conf` * `*_append.conf` @@ -52,9 +52,9 @@ location @drupal { } ``` -この設定は、顧客が`location_drupal_prepend.conf`および` `location_drupal_append.conf`、ここに他のステートメントの前後に挿入したい設定をすべて置くことができます。 +この設定は、お客さまが`location_drupal_prepend.conf`および`location_drupal_append.conf`という名前のファイルを作成することを許可します。これらのファイルには、他のステートメントの前に挿入したい設定と、後に挿入したい設定をすべて記述することができます。 -これらのファイルは作成されたら、`nginx`コンテナ内に**必ず**存在していなければならず、それらを`Dockerfile.nginx`に以下のように追加します: +これらのファイルは一度作成されると、`nginx`コンテナ内に**必ず**存在しなければならないので、`Dockerfile.nginx`に以下のように追加します: ```bash title="dockerfile.nginx" COPY location_drupal_prepend.conf /etc/nginx/conf.d/drupal/location_drupal_prepend.conf @@ -63,9 +63,9 @@ RUN fix-permissions /etc/nginx/conf.d/drupal/location_drupal_prepend.conf ## Drupal Core Statisticsモジュールの設定 { #drupal-core-statistics-module-configuration } -コアのStatisticsモジュールを使用している場合、短時間で設定の変更が必要な問題に遭遇するかもしれません。 +コアのStatisticsモジュールを使用している場合、簡単な設定変更が必要になるかもしれません。 -デフォルトのNGINX設定では、トラッキングエンドポイント`/core/modules/statistics/statistics.php`へのリクエストが拒否され(404)ます。 +デフォルトのNGINX設定では、トラッキングエンドポイント`/core/modules/statistics/statistics.php`へのリクエストが拒否されます(404) これはデフォルトのNGINX設定に関連しています: @@ -75,7 +75,7 @@ location ~* ^.+\.php$ { } ``` -この問題を解決するために、特定のロケーションルールを定義し、これをロケーションの前置設定として注入します: +この問題を解決するために、特定のロケーションルールを定義し、これをロケーションのプリペンド設定として注入します: ```text title="drupal.conf" ## Allow access to to the statistics endpoint. @@ -84,9 +84,9 @@ location ~* ^(/core/modules/statistics/statistics.php) { } ``` -そして、これをNGINの間にコピーします Xコンテナービルド: +NGINXコンテナのビルド時にこのファイルをコピーします。 ```text title="dockerfile.nginx" -# Drupal統計モジュールの特定のNGINX設定を追加します。 +# Drupal StatisticsモジュールのNGINX設定を追加する COPY .lagoon/nginx/location_prepend_allow_statistics.conf /etc/nginx/conf.d/drupal/location_prepend_allow_statistics.conf ``` diff --git a/docs/ja/applications/drupal/services/php-cli.md b/docs/ja/applications/drupal/services/php-cli.md index 4279e1f61a..d3d4f0208c 100644 --- a/docs/ja/applications/drupal/services/php-cli.md +++ b/docs/ja/applications/drupal/services/php-cli.md @@ -1,14 +1,14 @@ -# PHP-CLI-Drupal +# PHP-cli [Lagoonの`php-cli-drupal` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal)はDrupalと連携するために最適化されています。これは[Lagoonの`php-cli`イメージ](../../../docker-images/php-cli.md)を基に作られており、Drupalウェブサイトの日々のメンテナンスに必要なコマンドラインツール全てが含まれています。 * `drush` * `drupal console` -* `drush launcher` \(サイトにインストールされたDrushが見つからない場合はDrush 8にフォールバックします\) +* `drush launcher` \(Drushがインストールされたサイトが見つからない場合、Drush 8にフォールバックします\) ## サポートされているバージョン { #supported-versions } -* 7.3 \(互換性のために利用可能ですが、公式にはサポートされていません\) +* 7.3 \(互換性のために利用可能ですが、公式サポートは終了\) * 7.4 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/7.4.Dockerfile) - `uselagoon/php-7.4-cli-drupal` * 8.0 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/8.0.Dockerfile) - `uselagoon/php-8.0-cli-drupal` * 8.1 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/8.1.Dockerfile) - `uselagoon/php-8.1-cli-drupal` @@ -17,6 +17,6 @@ ## Lagoonの適応 { #lagoon-adaptions } -このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかの事項が完了しています: +このイメージはLagoonで使用されることを想定して準備されています。そのため、すでにいくつかのことが行われています: -* フォルダのパーミッションは自動的に適応されます [`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)を使用して、この画像はランダムなユーザーと一緒に動作します。 +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に適応されるため、このイメージはランダムなユーザーで動作します。 diff --git a/docs/ja/applications/drupal/services/redis.md b/docs/ja/applications/drupal/services/redis.md index b1d3465abf..42dc7fedeb 100644 --- a/docs/ja/applications/drupal/services/redis.md +++ b/docs/ja/applications/drupal/services/redis.md @@ -7,7 +7,7 @@ image: uselagoon/redis-5 labels: lagoon.type: redis - << : *default-user # トップから定義されたユーザーを使用します。 + << : *default-user # 定義済みのユーザーを使用します。 environment: << : *default-environment ``` @@ -33,9 +33,9 @@ ## Drupal 8 -Drupal 8の設定は大部分が標準です。特筆すべきは、Drupalがインストールされている間はRedisが無効になっていることです。 +Drupal 8 の設定はほとんどデフォルト設定のままですが、インストール時に Redis は無効化されます。 -```php title=" "settings.php" +```php title="settings.php" if (getenv('LAGOON')){ $settings['redis.connection']['interface'] = 'PhpRedis'; $settings['redis.connection']['host'] = getenv('REDIS_HOST') ?: 'redis'; @@ -75,10 +75,11 @@ if (getenv('LAGOON')){ ]; } } +``` -### 持続性 +### 永続性 -Redisは、持続的なバックエンドとしても設定できます。 +Redisは、永続的なバックエンドとして設定することもできます。 ```yaml title="docker-compose.yml" redis: @@ -101,9 +102,9 @@ redis: ## Redisのフェイルオーバー -以下は、Redisコンテナが利用できない場合(例えば、メンテナンス中など)にRedisのフェイルオーバーを実装するためのスニペットです。 +Redisコンテナが利用できない場合(例えば、メンテナンス中など)にRedisのフェイルオーバーを実装するためのスニペットを以下に示します。 -以下は、Drupalのアクティブな`settings.php`に挿入されます。 ファイル。 +以下をDrupalのアクティブな`settings.php`ファイルに追加します。 ```php title="settings.php" if (getenv('LAGOON')) { @@ -120,7 +121,7 @@ if (getenv('LAGOON')) { $client = Redis_Client::getClient(); $response = $client->ping(); if (!$response) { - throw new \Exception('Redisに到達できましたが、正しく応答していません。'); + throw new \Exception('Redisにアクセスできましたが、正しく応答していません。'); } $conf['redis_client_interface'] = 'PhpRedis'; $conf['lock_inc'] = $contrib_path . '/redis/redis.lock.inc'; @@ -128,7 +129,7 @@ if (getenv('LAGOON')) { $conf['cache_backends'][] = $contrib_path . '/redis/redis.autoload.inc'; $conf['cache_default_class'] = 'Redis_Cache'; } catch (\Exception $e) { - // Redis このリクエストには利用できないため、Redisバックエンドの設定を行わず、キャッシュが使用されないように確認する必要があります。これにより次のリクエストが再試行されます。 + // Redis このリクエストには利用できないため、Redisバックエンドの設定を行わず、キャッシュが使用されないようにします。これにより次のリクエストが再試行されます。 // 'DrupalFakeCache'クラスが存在しない場合 if (!class_exists('DrupalFakeCache')) { $conf['cache_backends'][] = 'includes/cache-install.inc'; diff --git a/docs/ja/applications/drupal/services/solr.md b/docs/ja/applications/drupal/services/solr.md index b2f470c800..646b3ea6bf 100644 --- a/docs/ja/applications/drupal/services/solr.md +++ b/docs/ja/applications/drupal/services/solr.md @@ -1,12 +1,12 @@ -# Solr-Drupal +# Solr -## 標準的な使用法 +## 標準的な使い方 -Solr 5.5、6.6、および 7.7のために、私たちは [search\_api\_solr](https://www.drupal.org/project/search_api_solr) Drupalモジュールによって提供されるデフォルトのスキーマファイルを提供しています。 `docker-compose.yml` ファイルに使用したいSolrバージョンを追加してください。[私たちの例](https://github.com/amazeeio/drupal-example-simple/blob/63b3fc613260d5192b7e2dd0167c6fc85d8d9162/docker-compose.yml#L110)に従ってください。 +Solr 5.5、6.6、および 7.7では、[search\_api\_solr](https://www.drupal.org/project/search_api_solr) Drupalモジュールによって提供されるデフォルトのスキーマファイルを提供しています。使用するSolrバージョンを[例](https://github.com/amazeeio/drupal-example-simple/blob/63b3fc613260d5192b7e2dd0167c6fc85d8d9162/docker-compose.yml#L110)のように`docker-compose.yml`ファイルに追加してください。 ## カスタムスキーマ -プロジェクトでSolrのスキーマカスタマイズを実装するには、Lagoonがどのように[標準のイメージを作成するか](https://github.com/uselagoon/lagoon-images/blob/main/images/solr-drupal/7.7.Dockerfile)を参照してください。 +プロジェクトでSolrのスキーマカスタマイズを実装するには、Lagoonがどのように[標準のイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/solr-drupal/7.7.Dockerfile)を作成するかを参照してください。 * `docker-compose.yml` ファイルの `solr` セクションで、 `image: amazeeio/solr:7.7` を以下のように置き換えます: @@ -16,7 +16,7 @@ Solr 5.5、6.6、および 7.7のために、私たちは [search\_api\_solr](ht dockerfile: solr.dockerfile ``` -* スキーマファイルをコードリポジトリに配置します。私たちは通常、 `.lagoon/solr` を使用します。 +* スキーマファイルをコードリポジトリに配置します。通常、`.lagoon/solr`を使用します。 * `solr.dockerfile` を作成します。 ```bash title="solr.dockerfile" @@ -29,11 +29,11 @@ RUN precreate-core drupal /solr-conf CMD ["solr-foreground"] ``` -目標は、Solr設定ファイルが `/solr-conf/conf` に存在することです。 あなたが作成しているイメージ。 +目標は、ビルドするイメージの`/solr-conf/conf`Solr設定ファイルが存在することです。 -## 複数のコア +## マルチコア -複数のコアを実装するには、上記のように自分自身のSolrスキーマを出荷する必要があります。必要な変更はDockerfileの`CMD`に対してのみで、必要なコアごとに`precreate-core corename /solr-conf/ ;`のパターンを繰り返します。 +複数のコアを実装するには、上記のように独自のSolrスキーマを用意する必要があります。必要な変更はDockerfileの`CMD`だけで、必要なコアごとに`precreate-core corename /solr-conf/ ;`のパターンを繰り返します。 ```bash title="solr.dockerfile" FROM amazeeio/solr:7.7-drupal diff --git a/docs/ja/applications/drupal/services/varnish.md b/docs/ja/applications/drupal/services/varnish.md index 9d25bfa3b2..6b7a27aed1 100644 --- a/docs/ja/applications/drupal/services/varnish.md +++ b/docs/ja/applications/drupal/services/varnish.md @@ -1,24 +1,24 @@ # Varnish -Drupalをバニッシュリバースプロキシと一緒に使用することをお勧めします。Lagoonは既にバニッシュが設定されている`varnish-drupal` Dockerイメージを提供しています。[Drupal Varnish config](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)付きです。 +DrupalをVarnishリバースプロキシと一緒に使用することをお勧めします。LagoonはVarnishがすでに設定済みの[Drupal Varnish config](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)で`varnish-drupal`Dockerイメージを提供しています。 -このバニッシュ設定は以下のことを行います: +このVarnish configは以下のことを行います: -* Drupalのセッションクッキーを理解し、認証されたリクエストのバニッシュキャッシュを自動的に無効にします。 -* アセット(画像、CSS、JSなど)を1ヶ月間自動的にキャッシュし、このヘッダーもブラウザに送信します。これにより、ブラウザもアセットをキャッシュします。これは認証されたリクエストと認証されていないリクエストの両方で発生します。 +* Drupalのセッションクッキーを理解し、認証されたリクエストに対してVarnishのキャッシュを自動的に無効にします。 +* この機能は、アセット(画像、CSS、JSなど)を自動的に 1 か月間キャッシュし、ブラウザにもキャッシュさせるためのヘッダーを送信します。これは認証されたリクエストでも認証されていないリクエストでも行われます。 * Drupal 8のパージモジュールで使用される`BAN`および`URIBAN`をサポートしています。 -* URLパラメータから`utm_`と`gclid`を削除し、Google Analyticsのリンクが複数のキャッシュオブジェクトを生成するのを防ぎます。 -* その他の多くの良い点 - [drupal.vcl](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)をチェックしてみてください。 +* Google Analyticsのリンクが複数のキャッシュオブジェクトを作成するのを防ぐために、URLパラメータから`utm_`と`gclid`を削除します。 +* 他にも良いことがたくさんあります - [drupal.vcl](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)をチェックしてみてください。 ## Drupal 8との使用 -**要約**: [我々の例のレポジトリでdrupal8-advancedの例をチェックしてみてください](https://github.com/uselagoon/lagoon-examples)、それは必要なモジュールと必要なものを含んでいます。 Drupalの設定。 +**要約**: [examples repoのdrupal8-advanced example](https://github.com/uselagoon/lagoon-examples)をチェックしてください。必要なモジュールとDrupalの設定が用意されています。 -**注意**:これらの例の多くは、同じ`drupal-example-simple`リポジトリ内の異なるブランチ/ハッシュに存在します。例のリストから正確なブランチを取得してください！ +**注意**:これらの例の多くは、同じ`drupal-example-simple`リポジトリ内の異なるブランチ/ハッシュに存在します。必ず、サンプルリストから正確なブランチを確認してください! ### PurgeとVarnish Purgeモジュールのインストール -Drupal 8のキャッシュタグとVarnishを完全に使用するためには、[Purge](https://www.drupal.org/project/purge)と[Varnish Purge](https://www.drupal.org/project/varnish_purge)モジュールをインストールする必要があります。これらは多くのサブモジュールと共に提供されています。最低限以下のものをインストールすることをお勧めします: +Drupal 8のキャッシュタグでVarnishを完全に使用するには、[Purge](https://www.drupal.org/project/purge)と[Varnish Purge](https://www.drupal.org/project/varnish_purge)モジュールをインストールする必要があります。これらのモジュールには多くのサブモジュールが含まれています。少なくとも以下をインストールすることをお勧めします： * `purge` * `purge_drush` @@ -41,10 +41,10 @@ drush en purge purge_drush purge_tokens purge_ui purge_processor_cron purge_proc ### Varnish Purgeの設定 1. `Configuration > Development > Performance > Purge`にアクセスします。 -2. `Add purger`でパージャーを追加します。 -3. `Varnish Bundled Purger`を選択します(`Varnish Purger`ではなく、\#Behind the Scenesを参照してください)。 セクション、詳細情報については。\). -4. 追加したばかりのパージャーの隣にあるドロップダウンをクリックし、`Configure`をクリックします。 -5. 良い名前をつけてください、`Lagoon Varnish` が良いでしょう。 +2. `Add purger`からパージを追加します。 +3. `Varnish Bundled Purger`を選択します\(`Varnish Purger`ではありません。\#Behind the Scenesを参照してください\) +4. 追加したばかりのパージの横にあるドロップダウンをクリックし、`Configure`をクリックします。 +5. わかりやすい名前をつけて下さい。`Lagoon Varnish` が良いでしょう。 6. 以下のように設定します: ```text title="Varnish Purgeの設定" @@ -63,70 +63,70 @@ drush en purge purge_drush purge_tokens purge_ui purge_processor_cron purge_proc 値: [invalidations:separated_pipe] ``` -7. `設定を保存`。 +7. `Save configuration`設定を保存します。 -以上で終わりです！これをローカルでテストしたい場合は、次のセクションを読んでください。 +以上で設定は完了です！ローカルでテストしたい場合は、次のセクションを読んでください。 ### Varnish用のDrupalの設定 -その他にもいくつかの設定が可能です: +他にもいくつかの設定が可能です: -1. `drush pmu page_cache`を使用して`Internal Page Cache` Drupalモジュールをアンインストールします。これによりVarnishキャッシュのみがクリアされ、内部キャッシュはクリアされず、変更がユーザーに非常に遅く表示されるなど、奇妙な二重キャッシュ状況が発生することがあります。また、大きなサイトではキャッシュストレージを大量に使用します。 -2. `production.settings.php`内の`$config['system.performance']['cache']['page']['max_age']`を`2628000`に変更します。これにより、Varnishはサイトを最大1ヶ月間キャッシュするように指示されますが、これは多くのように聞こえますが、Drupal 8 キャッシュタグシステムは基本的に何かが変更されるたびにVarnishキャッシュがパージされるようにするので、とても素晴らしいです。 +1. `drush pmu page_cache`を使用して`Internal Page Cache` Drupalモジュールをアンインストールします。このモジュールは、奇妙な二重キャッシュが発生する可能性があり、Varnish キャッシュのみがクリアされ、内部キャッシュがクリアされないため、変更がユーザーに非常に遅く反映されることがあります。また、大きなサイトではキャッシュストレージを大量に使用します。 +2. `production.settings.php`内の`$config['system.performance']['cache']['page']['max_age']`を`2628000`に変更します。これにより、Varnish キャッシュはサイトを最大 1 ヶ月間キャッシュするように設定されます。一見長いように思われるかもしれませんが、Drupal 8 のキャッシュタグシステムは非常に優秀で、何らかの変更が行われると、Varnish キャッシュが自動的に更新されるようになっています。 -### Varnishをローカルでテストする +### ローカルでの Varnish テスト -LagoonのローカルでのDrupalセットアップでは、開発が困難になる可能性があるため、VarnishとDrupalのキャッシュは無効になっています。これは次のように行われます: +LagoonのローカルでのDrupalセットアップでは、開発作業の妨げになる可能性があるため、VarnishとDrupalのキャッシュはが無効化されています。無効化方法は以下の通りです: -* `docker-compose.yml`の環境変数`VARNISH_BYPASS=true`は、Varnishに基本的に自己無効化を指示します。 -* Drupalは、`development.settings.php`のDrupal設定`$config['system.performance']['cache']['page']['max_age'] = 0`を設定することで、キャッシュヘッダーを送信しないように設定されています。 +* `docker-compose.yml`ファイル内の環境変数`VARNISH_BYPASS=true`により、Varnishに事実上無効化を指示しています。 +* Drupal がキャッシュヘッダーを送信しないように設定されています\(開発環境ようの`development.settings.php`ファイル内のDrupal設定`$config['system.performance']['cache']['page']['max_age'] = 0`が設定されています\) -ローカルでVarnishをテストするには、`docker-compose.yml`で以下の変更を行います: +Varnishをローカルでテストするには、`docker-compose.yml`で以下の変更を行います: * Varnishサービスセクションで`VARNISH_BYPASS`を`false`に設定します。 * `x-environment`セクションで`LAGOON_ENVIRONMENT_TYPE`を`production`に設定します。 -* `docker-compose up -d`を実行します。これにより、新しい環境変数ですべてのサービスが再起動します。 +* `docker-compose up -d`を実行します。これにより、新しい環境変数とともにすべてのサービスが再起動します。 これで、Varnishをテストできるようになるはずです！ -次に、IDが`1`でURLが`drupal-example.docker.amazee.io/node/1`となるノードがあると仮定した短い例を示します。 - -1. `curl -I drupal-example.docker.amazee.io/node/1`を実行し、見てみてください。 これらのヘッダーについて: - * `X-LAGOON` には `varnish` が含まれ、要求が実際にVarnishを経由したことを示します。 - * `Age:` は、Varnishがこのサイトを初めて見ることはおそらくないため、最初のリクエストがVarnishのキャッシュを温めるでしょう。 - * `X-Varnish-Cache` は `MISS` となり、Varnishがこのリクエストの以前にキャッシュされたバージョンを見つけられなかったことを示します。 -2. `curl -I drupal-example.docker.amazee.io/node/1` を再度実行し、ヘッダーは次のようになります: - * `Age:` は、リクエストがキャッシュされてから何秒経ったかを示します。例えば、コマンドを実行する速度によりますが、1-30の間でしょう。 - * `X-Varnish-Cache` は `HIT` となり、Varnishがリクエストのキャッシュされたバージョンを正常に見つけ、それを返したことを示します。 -3. Drupalの `node/1` の内容を変更します。 -4. `curl -I drupal-example.docker.amazee.io/node/1` を実行し、ヘッダーは最初のリクエストと同じになるべきです: +次に、IDが`1`でURLが`drupal-example.docker.amazee.io/node/1`となるノードを想定した短い例です。 + +1. `curl -I drupal-example.docker.amazee.io/node/1`を実行し、ヘッダーを確認してください: + * `X-LAGOON` には `varnish` が含まれ、リクエストが実際にVarnishを通して処理されたことを示します。 + * Varnishはおそらくこのサイトを見たことがなく、最初のリクエストはVarnishのキャッシュをウォームアップするため、`Age:`は0のままです。 + * `X-Varnish-Cache` は `MISS` になっていれば、Varnishがこのリクエストのキャッシュ済みバージョンを見つけられなかったことを示します。 +2. `curl -I drupal-example.docker.amazee.io/node/1` を再度実行すると、ヘッダーは以下のようになります: + * `Age:` は、リクエストがキャッシュされてから何秒経ったかを示します。例えば、コマンドを実行する速度によりますが、おそらく1-30の間の値になるでしょう。 + * `X-Varnish-Cache` は `HIT` となり、Varnishがリクエストのキャッシュされたバージョンを正常に取得して、それを返したことを示しています。 +3. Drupalの `node/1` のコンテンツ内容を変更します。 +4. `curl -I drupal-example.docker.amazee.io/node/1` を実行すると、ヘッダーは最初のリクエストと同じになるはずです: * `Age:0` * `X-Varnish-Cache: MISS` -### Varnish on Drupal の裏側 +### DrupalとVarnishの舞台裏 -他のDrupalホストから来ているか、以前にDrupal 8 & Varnishのチュートリアルを経験している場合、あなたは気付いたかもしれません。 Lagoon Drupal Varnishチュートリアルにいくつかの変更があります。それらについて説明しましょう: +Drupal ホスティングを利用していた経験がある方や、Drupal 8 と Varnish のチュートリアルを以前に行ったことがある方は、Lagoon の Drupal Varnish チュートリアルにはいくつかの変更点があることに気づいたかもしれません。以下でそれらについて説明します: -#### `Varnish Purger`の代わりに`Varnish Bundled Purger`の使用 +#### `Varnish Purger`の代わりに`Varnish Bundled Purger`を使用する -`Varnish Purger`は、無効化する必要がある各キャッシュタグに対して`BAN`リクエストを送信します。Drupalには多数のキャッシュタグが存在し、これによりVarnishに送信されるリクエスト数がかなり多くなる可能性があります。それに対して、`Varnish Bundled Purger`は、複数の無効化に対して一つの`BAN`リクエストを送信します。これはパイプ(`|`)できれいに分離されており、Varnishのバンの正規表現システムに完璧にマッチします。これにより、Varnishへのリクエスト数が減少し、Varnish内のバンリストテーブルも小さくなります。 +`Varnish Purger`は、無効化する必要のあるキャッシュタグごとに`BAN`リクエストを送信します。Drupalには多くのキャッシュタグが存在するため、Varnishに大量のリクエストが送信される可能性があります。それに対して、`Varnish Bundled Purger`は、複数の無効化をパイプ(`|`)で区切って、1つの`BAN`リクエストのみ送信します。これは、Varnishのバン正規表現システムと適合しており、結果として少ないリクエストと、Varnish内のバンリストテーブルも小さくなります。 -#### `Purge Late runtime processor`の使用 +#### `Purge Late runtime processor`の使い方 -Drupal 7のVarnishモジュールとは異なり、Drupal 8のPurgeモジュールはキャッシュのパージに若干異なるアプローチを持っています: パージするキャッシュをキューに追加し、それを異なるプロセッサで処理します。Purgeは`Cron processor`の使用を提案していますが、これはVarnishキャッシュがcron実行時にのみパージされることを意味します。これは、cronがおそらく毎分実行するように設定されていないため、Varnishが古いデータをキャッシュする可能性があり、編集者やクライアントが混乱する結果となる可能性があります。 +Drupal 7のVarnishモジュールとは異なり、Drupal 8のPurgeモジュールはキャッシュの削除方法が少し異なります。Purgeモジュールは削除対象のキャッシュをキューに追加し、その後さまざまな処理者がキューを処理します。Purgeモジュールは`Cron processor`を使うことを推奨していますが、これは Varnish キャッシュがcronジョブの実行時のみ削除されることを意味します。通常のcronはおそらく1分ごとなど非常に頻繁には実行されないため、古いデータがVarnishキャッシュに残ってしまう可能性があり、編集者やクライアントが混乱する事態を引き起こすおそれがあります。 -その代わりに、`Purge `Late runtime processor`は、各Drupalリクエストの最後にキューを処理します。これにより、キャッシュタグがパージキューに追加されると(例えば、エディタがDrupalノードを編集した場合など)、そのノードのキャッシュタグが直接パージされるという利点があります。`Varnish Bundled Purger`と一緒に使用することで、Drupalリクエストの最後にVarnishへの追加のリクエストは1つだけで、リクエストの処理時間にはほとんど影響しません。 +代わりに、私たちは`Purge Late runtime processor`の使用を推奨します。これは、各Drupalリクエストの終了時にキューを処理します。この利点は、キャッシュタグがパージキューに追加された場合 (編集者が Drupal ノードを編集した場合など)、そのノードのキャッシュタグが直接パージされることです。これと`Varnish Bundled Purger`を組み合わせることで、Drupalリクエストの最後だけにVarnishに対する単一の追加リクエストが行われるため、リクエスト処理時間に目立った影響はありません。 #### Varnish Ban Lurkerの完全なサポート -私たちのVarnish設定は、`Ban Lurker`の完全なサポートを提供しています。Ban Lurkerは、キャッシュをきれいに保ち、Varnishをスムーズに動作させるのに役立ちます。基本的には、Varnishの禁止リストを走査し、それらをVarnishキャッシュ内のキャッシュされたリクエストと比較する小さなツールです。Varnishの禁止は、キャッシュ内のオブジェクトをパージするために使用されます。Ban Lurkerが"禁止"されるべきアイテムを見つけると、それらをキャッシュから削除し、禁止自体も削除します。これにより、通常は禁止されずにキャッシュスペースを占め続ける、アクセスが少なくTTLが非常に長いオブジェクトが削除され、更新できるようになります。これにより、禁止リストが小さくなり、それによって、Varnの処理時間も少なくなります。 それぞれのリクエストでのVarnishの動作については、[公式VarnishのBan Lurkerについての投稿](https://info.varnish-software.com/blog/ban-lurker)や、その他の[参考になる読み物](https://www.randonomicon.com/varnish/2018/09/19/banlurker.html)をご覧ください。 +Varnishの設定では、`Ban Lurker`が完全にサポートされています。Ban Lurker は、キャッシュのクリーンアップと Varnish のスムーズな動作を維持するのに役立つツールです。Ban Lurkerは、Varnishの禁止リストにある項目をキャッシュ内のリクエストと比較する小さなツールです。Varnishの禁止機能は、キャッシュ内のオブジェクトを削除対象としてマークするために使用されます。Ban Lurkerは削除すべき項目を見つけると、キャッシュから削除し、禁止自体も解除します。これにより、通常は禁止されずにずっとキャッシュ容量を占有し続ける、アクセス頻度が低く有効期限が非常に長いオブジェクトが削除され、更新されるようになります。これにより、禁止リストが小さくなり、Varnishの各リクエストに対する処理時間も短縮されます。詳細については、[Ban LurkerのVarnishの公式記事](https://info.varnish-software.com/blog/ban-lurker)や、その他の[参考になる記事](https://www.randonomicon.com/varnish/2018/09/19/banlurker.html)を参照ください。 ### トラブルシューティング -Varnishがキャッシュしていない？ それとも何か他の問題がありますか？ 以下にデバッグの方法をいくつか紹介します: +Varnishがキャッシュしていない？ それとも何か他の問題が？ 以下にデバッグの方法をいくつか紹介します: -* `drush p-debug-en`を実行して、purgeモジュールのデバッグログを有効にします。これにより、Drupalのログの`admin/reports/dblog`でデバッグを表示できます。 -* Drupalが適切なキャッシュヘッダーを送信していることを確認してください。これを最もよくテストするためには、LagoonがVarnishキャッシュをバイパスするために生成したURLを使用します(私たちのDrupalの例では、これは[http://nginx-drupal-example.docker.amazee.io](http://nginx-drupal-example.docker.amazee.io)です)。`Cache-Control: max-age=900, public`ヘッダーをチェックし、`900`が`$config['system.performance']['cache']['page']['max_age']`で設定したものであることを確認します。 -* 環境変数`VARNISH_BYPASS`が`true`に設定されて**いない**ことを確認してください(`docker-compose.yml`を参照し、`docker-compose up -d varnish`を実行して環境変数が正しく設定されていることを確認します)。 -* もし全部 失敗すると、テーブルをひっくり返す前に \(╯°□°)╯︵ ┻━┻、Lagoonチームに話してみてください、私たちは喜んでお手伝いします。 +* purgeモジュールのデバッグログを有効にするには、`drush p-debug-en`コマンドを実行します。デバッグ情報は、Drupalログ`admin/reports/dblog`で確認できます。 +* Drupalが適切なキャッシュヘッダーを送信していることを確認してください。最適なテスト方法としては、Lagoonが生成するVarnishキャッシュをバイパスするためのURLを使用します(ローカルのDrupalの例では、[http://nginx-drupal-example.docker.amazee.io](http://nginx-drupal-example.docker.amazee.io)になります)。`Cache-Control: max-age=900, public`ヘッダーをチェックし、`900`が`$config['system.performance']['cache']['page']['max_age']`で設定したものであることを確認します。 +* 環境変数`VARNISH_BYPASS`が`true`に設定されて**いない**ことを確認してください(`docker-compose.yml`を確認し、`docker-compose up -d varnish`を実行して環境変数が正しく設定されていることを確認してください)。 +* すべてが上手くいかない場合、テーブルをひっくり返す前に \(╯°□°)╯︵ ┻━┻、Lagoonチームに問い合わせください。喜んでお手伝いします。 diff --git a/docs/ja/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md b/docs/ja/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md index 711746a95b..c45ccb9bcd 100644 --- a/docs/ja/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md +++ b/docs/ja/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.md @@ -1,36 +1,36 @@ -# ステップバイステップ:LagoonでDrupalを実行する準備 +# ステップバイステップ:DrupalをLagoonで実行する準備 ## 1. Lagoon Drupal 設定ファイル { #1-lagoon-drupal-setting-files } -DrupalがLagoonと連携するためには、DrupalにLagoonのことを、LagoonにDrupalのことを教える必要があります。これは、特定のYAMLとPHPファイルをGitリポジトリにコピーすることで行われます。 +DrupalがLagoonと連携するためには、DrupalにLagoonのことを、LagoonにDrupalのことを教える必要があります。これは、特定のYAMLとPHPファイルをGitリポジトリにコピーします。 -Drupalプロジェクトを手がけている場合は、[私たちの例のリポジトリ](https://github.com/uselagoon/lagoon-examples)でさまざまなDrupalの例のプロジェクトをチェックできます。Drupal 8と9、さらに各々のバリアントがあります。最もニーズに合ったリポジトリをクローンして始めてください。 +Drupalプロジェクトに取り組んでいる場合は、[私たちの例のリポジトリ](https://github.com/uselagoon/lagoon-examples)にある様々なDrupalサンプルプロジェクトを利用できます。ニーズに合わせて Drupal 8、Drupal 9 だけでなく、データベースの種類などバリエーションも用意されています。開始するには、自分のニーズに合ったリポジトリをクローンしてください！ -以下に、LagoonとDrupalに特化したファイルの概要を示します: +以下は、LagoonとDrupalに特化したファイルの概要です： -* `.lagoon.yml` - Lagoonが何をデプロイすべきかなどを理解するために使用される主要なファイルです。このファイルには、一部の妥当なDrupalのデフォルト設定が含まれています。編集や変更を行いたい場合は、[`.lagoon.yml`のドキュメンテーション](../../concepts-basics/lagoon-yml.md)をご覧ください。 -* `docker-compose.yml`、`.dockerignore`、および `*.dockerfile` \(または `Dockerfile`\) - これらのファイルはローカルのDrupal開発環境を起動するために使用され、Dockerにどのサービスを開始し、それらをどのようにビルドするかを指示します。 次の内容を含む合理的なデフォルト設定と多くのコメント行があります。十分にコメントがつけられていて、その内容が自己説明的であることを願っています。詳しく知りたい場合は、[`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)のドキュメンテーションをご覧ください。 -* `sites/default/*` - これらの`.php`と`.yml`のファイルは、DrupalがLagoonのコンテナとローカルおよび本番環境で通信する方法を指示します。また、開発環境と本番環境で特定のオーバーライドを直接的に提供します。他のDrupalホスティングシステムとは異なり、Lagoonは決してDrupalの設定ファイルをあなたのDrupalに注入しません。したがって、あなたはそれらを好きなように編集できます。他のすべてのファイルと同様に、それらには合理的なデフォルト設定といくつかのコメント部分が含まれています。 -* `drush/aliases.drushrc.php` - これらのファイルはDrushに特化しており、DrushにLagoon GraphQL APIと通信し、存在するすべてのサイトエイリアスについて学ぶ方法を指示します。 -* `drush/drushrc.php` - Drushコマンドのためのいくつかの合理的なデフォルト設定。 +* `.lagoon.yml` - Lagoonがデプロイメントする内容などを理解するためのメインファイルです。Drupal向けの適切なデフォルト設定が用意されています。編集や変更を行う場合は、[`.lagoon.yml`のドキュメント](../../concepts-basics/lagoon-yml.md)を参照してください。 +* `docker-compose.yml`、`.dockerignore`、および `*.dockerfile` \(または `Dockerfile`\) - これらのファイルはローカルのDrupal開発環境の実行に使用されます。これらのファイルは、Dockerに対して起動するサービスの種類やビルド方法を指示します。適切なデフォルト設定と、多くのコメント行が含まれています。これらのファイルは、内容が読み取れるよう十分なコメントが付けられていることを目指しています。詳細は、[`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)のドキュメントを参照ください。 +* `sites/default/*` - `.php`と`.yml`のファイルは、Drupalがローカル環境と本番環境の両方でLagoonコンテナと通信する方法をDrupalに指示します。また、開発環境と本番環境で特定の設定をオーバーライド (上書き) するためのシンプルな仕組みも提供します。他のDrupalホスティングシステムとは異なり、LagoonはDrupalの設定ファイルに一切干渉しません。そのため、これらのファイルを自由に編集できます。他のファイルと同様に、適切なデフォルト設定と、一部コメント付きの部分が含まれています。 +* `drush/aliases.drushrc.php` - Drush独自のファイルで、DrushがLagoonのGraphQL APIを使ってサイトエイリアス (サイトの別名) を取得する方法をDrushに指示します。 +* `drush/drushrc.php` - Drushコマンド用の適切なデフォルト設定が用意されています。 ### `.gitignore`設定の更新 { #update-your-gitignore-settings } -設定ファイルをコミットできるように、`.gitignore`を確認するのを忘れないでください。 +設定ファイルをコミットできるように、`.gitignore`ファイルを確認してください。 -Drupalは`sites/*/settings*.php`と`sites/*/services*.yml`を`.gitignore`で提供しています。それらを削除してください。 Lagoonでは、Gitリポジトリに機密情報を一切持っていません。 +Drupalは`sites/*/settings*.php`と`sites/*/services*.yml`を`.gitignore`でコミットから除外するように初期設定されています。Lagoon 環境では機密情報は Git リポジトリに保存しないので、この除外設定を削除してください。 -### Drupal 8の`WEBROOT`についての注意 { #note-about-webroot-in-drupal-8 } +### Drupal 8の`WEBROOT`に関する注意事項 { #note-about-webroot-in-drupal-8 } -残念ながら、Drupalコミュニティは標準化された`WEBROOT`フォルダ名について一致していません。一部のプロジェクトではDrupalを`web`内に置き、他のプロジェクトでは`docroot`や他の場所に置いています。LagoonのDrupal設定ファイルは、Drupalが`web`内にあると仮定していますが、あなたのDrupalでこれが異なる場合は、ファイルを適切に調整してください。 +残念ながら、Drupalコミュニティでは`WEBROOT`フォルダ名の標準化がまだ決まっていません。Drupalを`web`ディレクトリ内に配置するプロジェクトもあれば、`docroot`や別の場所に入れるプロジェクトもあります。LagoonのDrupal設定ファイルは、Drupalが`web`ディレクトリ内に配置されていることを前提としています。もしあなたのDrupalの構成が異なる場合は、設定ファイルをそれに合わせて修正してください。 -### `composer.json`についての注意 { #note-about-composerjson } +### `composer.json`に関する注意事項 { #note-about-composerjson } -もしDrupalをcomposerを使ってインストールした場合は、`composer.json`を確認し、`name`が`drupal/drupal`でないことを確認してください。これはDrushやDrupalのユニバースの他のツールを混乱させる可能性があるため、それを`myproject/drupal`のようなものにリネームしてください。 +Composer を使って Drupal をインストールした場合、`composer.json`を確認し、`name`が`drupal/drupal`でないことを確認してください。この名前は Drush やその他の Drupal 関連ツールと競合してしまう可能性がありますので、`myproject/drupal`など、別の名前にしてください。 ## 2. `docker-compose.yml`のカスタマイズ { #2-customize-docker-composeyml } -`lagoon-project`と`LAGOON_ROUTE`の値を忘れずにカスタマイズし、サイト固有の名前とアクセスしたいURLに書き換えてください。以下に例を示します: +`lagoon-project`と`LAGOON_ROUTE`の値を忘れずにカスタマイズし、サイト名とアクセスしたいURLに書き換えてください。以下に例を示します: ```yaml title="docker-compose.yml" x-environment: @@ -48,9 +48,9 @@ x-environment: docker-compose build ``` -これにより、`docker-compose.yml`内で`build:`の定義を持つすべてのコンテナのDockerイメージを`docker-compose`にビルドするよう指示します。通常、Drupalでは`cli`、`nginx`、`php`のイメージが該当します。これは、特定の**ビルド**コマンド(`composer install`など)を実行したり、特定の環境変数(`WEBROOT`など)をイメージに注入したりするためです。 +このコマンドを実行すると、`docker-compose.yml`内で`build:`の定義があるすべてのコンテナのDockerイメージをビルドするように`docker-compose`に指示します。通常、Drupalでは`cli`、`nginx`、`php`のイメージが該当します。これは、特定の**ビルド**コマンド(`composer install`など)を実行したり、特定の環境変数(`WEBROOT`など)をイメージに注入するためです。 -通常、Drupalのコードを編集するたびにビルドする必要はありません(コードはホストからコンテナにマウントされるため)が、再ビルドしても問題ありません。さらに、Lagoonはデプロイ時にまったく同じDockerイメージをビルドするので、`docker-compose build`を再度実行するだけで、ビルドがデプロイ時にも正常に動作することを確認できます。 +通常、Drupal コードを編集するたびにビルドを行う必要はありません (コードはホストからコンテナにマウントされるため)。とはいえ、ビルドをしても何らかの問題が生じるわけではありません。さらに、Lagoon はデプロイ中にまったく同じ Docker イメージをビルドするので、`docker-compose build`コマンドをもう一度実行することで、デプロイ時にもビルドが正常に動作することを確認できます。 ## 4. コンテナの起動 { #4-start-containers } @@ -60,29 +60,29 @@ docker-compose build docker-compose up -d ``` -これにより、すべてのコンテナが起動します。コマンドが完了した後、`docker-compose ps`で確認して、すべてが完全にアップしてクラッシュしていないことを確認できます。問題がある場合は、確認してください `docker-compose logs -f [servicename]`でログを確認します。 +これにより、すべてのコンテナが起動します。コマンドが完了した後、`docker-compose ps`ですべてのコンテナが完全に立ち上がっているか、クラッシュしていないかを確認できます。問題がある場合は、`docker-compose logs -f [servicename]`でログを確認してください。 -## 5. `composer install`を再実行します { #5-rerun-composer-install } +## 5. `composer install`を再実行します（composerプロジェクトのみ） { #5-rerun-composer-install } -ローカルの開発環境では、すべての依存関係がダウンロードされインストールされることを期待するでしょう、それで`cli`コンテナへ接続し`composer install`を実行します: +ローカルの開発環境では、すべての依存関係をダウンロードしてインストールしたいと思うでしょう。そのため、`cli`コンテナに接続して`composer install`を実行します: ```bash title="CLIでcomposer installを実行" docker-compose exec cli bash composer install ``` -これは奇妙に聞こえるかもしれません、なぜならビルドステップの間にすでに`composer install`が実行されていたからです、それで説明させてください: +少し奇妙に感じるかもしれませんが、ビルド手順ですでに`composer install`が実行されているため、説明を加えさせていただきます: -* ホスト上のファイルを編集し、それらをコンテナ内で即座に利用可能にするため、デフォルトの`docker-composer.yml`は全体のフォルダをコンテナ内にマウントします(これはボリュームセクションの`.:/app:delegated`で起こります)。これはまた、Dockerビルド中にインストールされたすべての依存関係がホスト上のファイルで上書きされることを意味します。 -* ローカルでは、`composer.json`で`require-dev`として定義された依存関係も存在することを期待するでしょう、一方で本番環境ではそれらは単に不必要なスペースを使用するだけです。そのため、Dockerfileで`composer install --no-dev`を実行し、`composer install`は手動で実行します。 +* ホスト上のファイルを編集して、すぐにコンテナで利用できるようにするため、デフォルトの`docker-composer.yml`ファイルは、すべてのフォルダーをコンテナ内にマウントしています (ボリュームセクションの`.:/app:delegated`がこれに該当します)。つまり、Dockerビルド時にインストールされたすべての依存関係は、ホスト上のファイルで上書きされます。 +* ローカル開発環境においては、`composer.json`で`require-dev`として定義された依存関係も存在させる必要があるでしょう。一方、本番環境では、そうした依存関係はただ無駄な容量を消費するだけです。そのため、Dockerfile内では `composer install --no-dev`を実行し、手動で`composer install`を実行します。 -全てがうまく行った場合、`docker-compose`で定義された`LAGOON_ROUTE`を開きます。 .yml` \(例えば `http://drupal.docker.amazee.io`\) を開いて、素敵なDrupalエラーが表示されるはずです。心配しないでください - 今のところそれは大丈夫です、最も重要なのはDrupalサイトをロードしようとしていることです。 +すべて問題なく動作している場合、`docker-compose.yml` \(例えば `http://drupal.docker.amazee.io`\)で定義された`LAGOON_ROUTE`を開くと、Drupalエラーが表示されるはずです。心配しないでください。今の段階では問題ありません。重要なのは、Drupalサイトが読み込まれようとしていることです。 -500や類似のエラーが表示された場合は、Composerで正しくすべてがロードされていることを確認してください。 +500エラーや同様のエラーが発生した場合は、Composerによってすべてが正しく読み込まれたことを確認してください。 ## 6. ステータスの確認とDrupalのインストール { #6-check-status-and-install-drupal } -いよいよDrupalをインストールする時間がきましたが、その前にすべてが機能していることを確認したいと思います。それにはDrushを使用することをお勧めします: +いよいよDrupalをインストールしますが、その前にすべてが機能していることを確認したいと思います。そのためにDrushを使用することをお勧めします: ```bash title="Drush status" docker-compose exec cli bash @@ -116,9 +116,9 @@ Site path : sites/default !!! Warning "警告" 次のステップ前に、pygmyに公開鍵について伝える必要があるかもしれません。 -`Permission denied (publickey)`のようなエラーが出た場合は、こちらのドキュメンテーションをご覧ください: [pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) +`Permission denied (publickey)`のようなエラーが出た場合は、こちらからSSHキーの追加方法に関するドキュメントを参照ください: [pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) -次にDrupalをインストールします(既存のSQLファイルをインポートしたい場合は、[ステップ7へスキップ](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#7-import-existing-database-dump)してください。しかし、始めは全てが機能することを確認するために、クリーンなDrupalのインストールから始めることをお勧めします)。 +次にDrupalをインストールします(既存のSQLファイルをインポートしたい場合は、[ステップ7へスキップ](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#7-import-existing-database-dump)してください。ただし、すべてが機能することを確認するために、最初からクリーンなDrupalインストールをお勧めします。))。 ```bash title="Drupalのインストール" drush site-install @@ -128,13 +128,13 @@ drush site-install ```bash title="drush site-install" [drupal-example]cli-drupal:/app$ drush site-install -あなたは 'drupal' データベースの全てのテーブルをDROPしようとしています。続行しますか？ (y/n): y -Drupalのインストールを開始します。これにはしばらく時間がかかります。--notify グローバルオプションを使用することを検討してみてください。 -インストール完了。ユーザー名: admin ユーザーパスワード: a7kZJekcqh -おめでとうございます、Drupalをインストールしました！ +You are about to DROP all tables in your 'drupal' database. Do you want to continue? (y/n): y +Starting Drupal installation. This takes a while. Consider using the --notify global option. +Installation complete. User name: admin User password: a7kZJekcqh +Congratulations, you installed Drupal! ``` -これで `LAGOON_ROUTE`で定義されたURLを訪れると、新鮮でクリーンにインストールされたDrupalサイトが表示されるはずです - おめでとうございます！ +`LAGOON_ROUTE`で定義されているURLにアクセスすると、新しくインストールされたDrupalサイトが表示されます。おめでとうございます！ ![おめでとう！](https://media.giphy.com/media/XreQmk7ETCak0/giphy.gif) @@ -167,12 +167,12 @@ drush sql-drop drush sql-cli < dump.sql ``` -プロジェクトのURLを訪れてすべてが正常に動作することを確認します。Drupalサイトの機能的なコピーができているはずです！ +プロジェクトのURLにアクセスして、すべてが正常に動作することを確認してください。これで、Drupalサイトが正常に機能しているはずです！ ## 8. Drupalファイル ディレクトリ { #8-drupal-files-directory } -Drupalサイトには、ファイルのディレクトリも必要です。全体のフォルダはDockerコンテナにマウントされるので、ファイルを正しいフォルダ(おそらく`web/sites/default/files`、`sites/default/files`またはそれに類似したもの)に追加してください。あなたが`WEBROOT`として設定したものを覚えておいてください - [すべてのプロジェクトで同じではないかもしれません](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#note-about-webroot-in-drupal-8)。 +Drupalサイトには、ファイルのディレクトリも必要です。このフォルダ全体はDockerコンテナ内にマウントされるため、ファイルを正しいフォルダに追加してください (おそらく`web/sites/default/files`、`sites/default/files`または同様のフォルダです)。設定した`WEBROOT`を覚えておいてください - [プロジェクトごとに異なる場合があるかもしれません](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#note-about-webroot-in-drupal-8) ## 9. 完了 { #done } -あなたのローカルセットアップが完了しました。Lagoonチームは楽しいDrupal制作を願っています！ +ローカル設定が完了しました。Lagoon チームは、皆様の楽しい Drupaling を応援しています！ diff --git a/docs/ja/applications/drupal/subfolders.md b/docs/ja/applications/drupal/subfolders.md index 43c0bef151..00b084ea15 100644 --- a/docs/ja/applications/drupal/subfolders.md +++ b/docs/ja/applications/drupal/subfolders.md @@ -1,12 +1,14 @@ # サブフォルダ -例えば、`www.example.com`が一つのDrupalサイトを指し、`www.example.com/blog`が別のDrupalで作られたブログをロードする場合があります。 +例えば、`www.example.com`はあるDrupalサイトへのアクセスを提供し、`www.example.com/blog`は別のDrupalで構築されたブログを読み込みます。 -両方のDrupalを1つのGitリポジトリで動かし、それを全体としてデプロイすることが可能ですが、このワークフローはすべてのチームに適合するわけではなく、別々のGitリポジトリを持つことが一部の状況にはより適しています。 +この場合、両方のDrupalを単一のGitリポジトリで管理し、まとめてデプロイすることも可能です。しかし、このワークフローは全てのチームに適しているわけではなく、状況によっては別々のGitリポジトリを使用した方が良い場合もあります。 -## ルートアプリケーションの修正 -ルートアプリケーション(この例では`www.example.com`のDrupalサイト)は、NGINXをサブフォルダアプリケーションへのリバースプロキシとして構成するいくつかのNGINX設定が必要です: + +## ルートアプリケーションの変更 + +ルートアプリケーション(この例では`www.example.com`のDrupalサイト)は、NGINXをサブフォルダアプリケーションへのリバースプロキシとして設定するためのNGINX設定ファイルがいくつか必要になります: ### `location_prepend.conf` @@ -16,7 +18,7 @@ Drupalインストールのルートに`location_prepend.conf`というファイ resolver 8.8.8.8 valid=30s; location ~ ^/subfolder { - # $http_x_forwarded_protoが空(上流のリバースプロキシから設定されていない場合)であれば、 + # $http_x_forwarded_protoが空の場合 (上流のリバースプロキシから設定されていない場合) # 現在のスキームに設定します。 set_if_empty $http_x_forwarded_proto $scheme; @@ -27,30 +29,30 @@ location ~ ^/subfolder { # 元のホストを下流が知るために使用されます。 proxy_set_header X-REVERSEPROXY $hostname; proxy_set_header FORWARDED ""; - # drupal8が設定されているとエラーを出すため、FORWARDEDを未設定にします。 + # Drupal 8でエラーが発生するため、FORWARDEDヘッダーを削除します。 proxy_set_header Proxy ""; - # drupal8が設定されているとエラーを出すため、Proxyを未設定にします。 + # Drupal 8でエラーが発生するため、Proxyヘッダーを削除します。 proxy_ssl_server_name on; - # DNS解決が正しく機能するためには、NGINXに変数を設定する必要があります。 + # NGINXでDNS解決を正しく動作させるには、変数を設定する必要があります。 set $subfolder_drupal_host "https://nginx-lagoonproject-${LAGOON_GIT_SAFE_BRANCH}.clustername.com:443"; # LAGOON_GIT_SAFE_BRANCH変数はdockerエントリーポイント時に置換されます。 proxy_pass $subfolder_drupal_host; proxy_set_header Host $proxy_host; - # $proxy_hostはproxy_passに基づいてNGINXによって自動生成されます(スキームとポートは不要です)。 + # $proxy_hostは、NGINXがproxy_passディレクティブ(スキームとポートを除くホスト名)を元に自動生成されます。 expires off; # プロキシからのキャッシュヘッダーを尊重し、上書きしないようにします ``` 以下の文字列を置換してください: -* `/subfolder` を使用したいサブフォルダの名前に置換します。例えば、`/blog`。 -* `nginx` をサブフォルダプロジェクト内で指すサービスに置換します。 -* `lagoonproject` をサブフォルダプロジェクトのLagoonプロジェクト名に置換します。 +* `/subfolder`：サブフォルダとして使用する名前を入力してください例えば、`/blog`。 +* `nginx`：サブフォルダプロジェクトが参照するサービス名を入力してください。 +* `lagoonproject`：サブフォルダプロジェクトのLagoonプロジェクト名を入力してください。 ### N GINX Dockerfile -以下をあなたのNGINX Dockerfile(`nginx.dockerfile`または`Dockerfile.nginx`)に追加してください: +以下の内容をNGINX Dockerfile(`nginx.dockerfile`または`Dockerfile.nginx`)に追加してください: ```text title="nginx.dockerfile" COPY location_prepend.conf /etc/nginx/conf.d/drupal/location_prepend.conf @@ -59,20 +61,20 @@ RUN fix-permissions /etc/nginx/conf.d/drupal/* ## サブフォルダアプリケーションの変更 -ルートアプリケーションと同様に、サブフォルダアプリケーション(この例では、`www.example.com/blog`のDrupalインストール)にも、サブフォルダ下で動作していることを教える必要があります。これを行うために、以下の2つのファイルを作成します: +ルートアプリケーションと同様に、サブフォルダアプリケーション(この例では、`www.example.com/blog`のDrupalインストール)に対しても、サブフォルダで動作していることを認識させる必要があります。そのためには、以下の2つのファイルを作成します: ### `location_drupal_append_subfolder.conf` -サブフォルダのDrupalインストールのルートに`location_drupal_append_subfolder.conf`という名前のファイルを作成します: +サブフォルダアプリケーションのDrupalインストールのルートディレクトリに、`location_drupal_append_subfolder.conf`という名前のファイルを作成します: ```text title="location_drupal_append_subfolder.conf" -# `subfolder`という接頭辞がついたスクリプト名を注入すると、Drupalは -# `subfolder`が接頭辞として付けられたすべてのURLを描画します +# Drupalは、`subfolder`で始まるプレフィックスが付いたスクリプト名を注入すると、 +# すべてのURLに`subfolder`をプレフィックスとして付加してレンダリングします。 fastcgi_param SCRIPT_NAME /subfolder/index.php; -# リバースプロキシ経由で実行している場合、元のHOST URLを -# PHPに注入します。これにより、Drupalは元のHOST URLで -# すべてのURLを描画し、現在使用しているHOSTではありません。 +# リバースプロキシ経由で実行している場合、オリジナルのHOST URLを +# PHPに注入します。これにより、Drupalは現在のHOSTではなく、 +# オリジナルのHOST URLを用いてすべての URL をレンダリングします。 # 最初に、HOSTを通常のホスト変数に設定します。 fastcgi_param HTTP_HOST $http @@ -81,46 +83,45 @@ fastcgi_param HTTP_HOST $http fastcgi_param HTTP_HOST $http_x_lagoon_forwarded_host if_not_empty; ``` -`/subfolder`を使用したいサブフォルダの名前に置き換えてください。例えば、`/blog`。 +サブフォルダー名で `/subfolder`を置き換えてください。例えば、`/blog`のように置き換えます。 ### `server_prepend_subfolder.conf` -サブフォルダのDrupalインストールのルートに`server_prepend_subfolder.conf`という名前のファイルを作成します: +サブフォルダーでのDrupalインストールのルートディレクトリに、`server_prepend_subfolder.conf`という名前のファイルを作成してください: ```text title="server_prepend_subfolder.conf" -# 内部のNGINXリライトを行う前に、リダイレクトを確認します。 -# これは、内部のNGINXリライトが `last`を使用するためで、 -# これはNGINXにリライトをこれ以上確認しないよう指示します(そして -# `if`はリダイレクトモジュールの一部です)。 +# 内部NGINXリライトは`last`フラグを使うため、 +# リライトの前にリダイレクトの有無を確認します。 +# `last`フフラグはNGINXに対して、これ以降のリライト処理を行わないよう指示します。 +# (また、`if`はリダイレクトモジュールの一部です。) include /etc/nginx/helpers/010_redirects.conf; -# これは内部のNGINXリライトで、リクエストから`/subfolder/`を -# 削除して、NGINXが最初から`/`だったかのようにリクエストを -# 処理します。 -# `last`フラグも重要です。これはNGINXにこれ以上のリライトを -# 実行しないよう指示します。なぜなら、以下のリライトで永遠に -# リダイレクトするからです。 +# このリライトはリクエストURLから`/subfolder/`を削除し、 +# あたかも最初から`/`であったかのようにNGINXが +# 処理できるようにします。 +# `last`フラグも重要です。 +# これにより、以下のリライトが永続的に繰り返されるのを防ぎます。 rewrite ^/subfolder/(.*) /$1 last; -# リダイレクトが絶対ではないことを確認し、URLのホストをNGINXが -# 上書きしないようにします - これは # NGINXが現在提供しているもの以外の何かである可能性があります。 +# NGINXによって現在処理されているホスト情報が上書きされないよう、 +# リダイレクトの絶対パスを使用しないようにします。 absolute_redirect off; -# リクエストが`/subfolder`だけの場合、301リダイレクトを`/subfolder/`にします -# (Drupalは末尾のスラッシュが大好き) +# `/subfolder`だけがリクエストされた場合、301リダイレクトで +# `/subfolder`(Drupalは末尾のスラッシュを好みます)に転送します。 rewrite ^/subfolder /subfolder/ permanent; -# 他の全てのリクエストに対しては、301リダイレクトを`/subfolder/`でプレフィックスします。 +# その他のリクエストに対しては、301リダイレクトのパスに`/subfolder/`を先頭に追加します。 rewrite ^\/(.*) /subfolder/$1 permanent; ``` -`/subfolder`を使用したいサブフォルダの名前に置き換えてください。例えば、`/blog`。 +`/subfolder`は、使用するサブフォルダーの名前と置き換えてください。例えば、ブログ用のサブフォルダーであれば `/blog`となります。 ### NGINX Dockerfile -また、NGINX Dockerfileも修正する必要があります。 +NGINX Dockerfileも編集が必要です。 -以下をNGINX Dockerfile (`nginx.dockerfile` または `Dockerfile.nginx`)に追加してください: +NGINX Dockerfile(通常は`nginx.dockerfile` または `Dockerfile.nginx`)に以下の内容を追加してください: ```text title="nginx.dockerfile" COPY location_drupal_append_subfolder.conf /etc/nginx/conf.d/drupal/location_drupal_append_subfolder.conf