diff --git a/docs/_data/defaults.yml b/docs/_data/defaults.yml
index 1a175fbe19..066d03bb76 100644
--- a/docs/_data/defaults.yml
+++ b/docs/_data/defaults.yml
@@ -4,7 +4,7 @@ sshport: 22
sshhostname: ssh.example.com
apiaddress: api.example.com
helpstring: your Lagoon administrator
-helpstring_ja: Lagoon 管理者
+helpstring_ja: Lagoonの管理者
## Comment out any of the above, and uncomment the corresponding below to see the variables in action
# name: amazee.io
diff --git a/docs/ja/concepts-advanced/backups.md b/docs/ja/concepts-advanced/backups.md
index 86443d4ed2..de38e3d69d 100644
--- a/docs/ja/concepts-advanced/backups.md
+++ b/docs/ja/concepts-advanced/backups.md
@@ -2,28 +2,28 @@
Lagoonは、データベースのデータとコンテナの永続的なストレージボリュームの両方のバックアップ機能を提供するために、[k8up operator](https://github.com/vshn/k8up)を使用しています。このオペレータは、これらのバックアップをカタログ化するために[Restic](https://github.com/restic/restic)を利用し、通常はAWS S3バケットに接続して生成されたバックアップの安全なオフサイトストレージを提供します。
-## プロダクション環境
+## production環境
### バックアップスケジュール
-データベースとコンテナの永続的なストレージボリュームのバックアップは、デフォルトでプロダクション環境内で夜間に行われます。
+データベースとコンテナの永続的なストレージボリュームのバックアップは、デフォルトで`production`環境内で夜間に行われます。
-プロダクションバックアップの異なるバックアップスケジュールが必要な場合、これはプロジェクトレベルで指定できます。これは、プロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-schedule)ファイルの"Backup Schedule"変数を設定することで行います。
+バックアップに異なるスケジュールが必要な場合はプロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-schedule)ファイルの"Backup Schedule"変数を設定することでプロジェクトレベルで指定できます。
### バックアップ保持
-プロダクション環境のバックアップは、デフォルトで以下のスケジュールに従って保持されます:
+production環境のバックアップは、デフォルトで以下のスケジュールに従って保持されます:
* 日次:7
* 週次:6
* 月次:1
* 時間ごと:0
-プロダクションバックアップの異なる保持期間が必要な場合、これはプロジェクトレベルで指定できます。これは、プロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-retention)ファイルの"Backup Retention"変数を設定することで行います。 ファイル。
+バックアップに異なる保持期間が必要な場合はプロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-retention)ファイルにある"Backup Retention"変数を設定することでプロジェクトレベルで指定できます。
## 開発環境
-開発環境のバックアップは毎晩試みられ、厳格に最善の努力サービスです。
+開発環境のバックアップは毎晩試みられますが、あくまでベストエフォートサービスです。
## バックアップの取得
diff --git a/docs/ja/concepts-advanced/base-images.md b/docs/ja/concepts-advanced/base-images.md
index 45976b317a..af390c5073 100644
--- a/docs/ja/concepts-advanced/base-images.md
+++ b/docs/ja/concepts-advanced/base-images.md
@@ -2,30 +2,30 @@
## ベースイメージとは何ですか？ { #what-is-a-base-image }
-ベースイメージは、Lagoon上でデプロイされたプロジェクトが使用できる、または使用している[Docker](https://www.docker.com/)イメージです。ベースイメージは、監査されていないものが上流からコードベース/プロジェクトに持ち込まれないようにする方法を提供します。また、デプロイされた環境上で必要となる可能性のあるものがすべて利用可能であることを保証します - 低レベルのライブラリからアプリケーションレベルのテーマとモジュールまで。
+ベースイメージは、Lagoon上でデプロイされたプロジェクトが使用できる、または使用している[Docker](https://www.docker.com/)イメージです。ベースイメージは、監査されていないものが上流からコードベース/プロジェクトに持ち込まれないようにする方法を提供します。また、低レベルのライブラリからアプリケーションレベルのテーマとモジュールまで、デプロイされた環境上で必要となる可能性のあるものがすべて利用可能であることを保証します。
-ベースイメージは、どのシステムがデプロイされているかがわかっている場合、時間とリソースの節約に役立ちます - 共有パッケージがベースイメージに含まれている場合、それらを個々の数百のサイトにデプロイする必要はありません。
+ベースイメージは、どのシステムがデプロイされているかがわかっている場合、時間とリソースの節約に役立ちます。つまり、共有パッケージがベースイメージに含まれている場合、それらを個々の数百のサイトにデプロイする必要はありません。
## 派生イメージ { #derived-images }
-派生イメージとは、ベースイメージを拡張するイメージのことを指します。例えば、いくつかのブログサイトを作る必要があるかもしれません。私たちのDrupalイメージを取り、ブログサイトに必要なモジュールとテーマすべてを含めてカスタマイズし、そのブログイメージですべてをデプロイします。テンプレートはベースイメージから派生します。
+派生イメージとは、ベースイメージを拡張するイメージのことを指します。例えば、いくつかのブログサイトを作る必要があるかもしれません。私たちのDrupalイメージを取得し、ブログサイトに必要なモジュールとテーマすべてを含めてカスタマイズし、そのブログイメージですべてをデプロイします。テンプレートはベースイメージから派生します。
-すべての派生イメージは、`composer.json`ファイルを([Packagist](https://packagist.org/)、[Satis](https://github.com/composer/satis)、または[GitHub](https://github.com/)などのリポジトリ経由で)プルインする必要があります。これにより、それらは 基本パッケージの最新バージョン。
+すべての派生イメージは、`composer.json`ファイル([Packagist](https://packagist.org/)、[Satis](https://github.com/composer/satis)、または[GitHub](https://github.com/)などのリポジトリ経由で)を取り込む必要があります。これにより、基本パッケージの最新バージョンを使用するようになります。
-さらに、派生イメージには、`/build/pre_composer`スクリプトへの呼び出しが含まれています。これは、基本イメージが派生イメージでスクリプト、アップデートなどを実行するために使用できます。例えば、派生イメージでパッケージが更新またはインストールされると、デフォルトで実行され、`pre_composer`スクリプトはその後、基本イメージパッケージを更新します。
+さらに、派生イメージには、`/build/pre_composer`スクリプトへの呼び出しが含まれています。これは、ベースイメージが派生イメージでスクリプト、アップデートなどを実行するために使用できます。例えば、派生イメージでパッケージが更新またはインストールされると、デフォルトで実行され、`pre_composer`スクリプトはその後、ベースイメージパッケージを更新します。
-## 基本イメージの構造 { #anatomy-of-a-base-image}
+## べースイメージの構造 { #anatomy-of-a-base-image}
!!! Info "情報"
- このドキュメントでは、DrupalやLaravelの基本イメージを例に取り上げます。これは、元々Lagoonプロジェクトでこれらのテクノロジーを使用しているクライアント向けに書かれたものです。他の基本イメージの内容もカバーするように拡張されますが、基本イメージの内容に関係なく、プロセスは変わりません。
+ このドキュメントでは、DrupalやLaravelのベースイメージを例に取り上げます。これは、元々Lagoonプロジェクトでこれらのテクノロジーを使用しているクライアント向けに書かれたものです。他のベースイメージの内容もカバーするように拡張されますが、ベースイメージの内容に関係なく、プロセスは変わりません。
-基本イメージは、[Composer](https://getcomposer.org/)で管理され、[BitBucket](https://bitbucket.org/)、[GitHub](https://github.com/)、または[GitLab](https://gitlab.com/) \(チームが使用しているもの\)にホストされています。各基本イメージには独自のリポジトリがあります。
+ベースイメージは、[Composer](https://getcomposer.org/)で管理され、[BitBucket](https://bitbucket.org/)、[GitHub](https://github.com/)、または[GitLab](https://gitlab.com/) \(チームが使用しているもの\)にホストされています。各ベースイメージには独自のリポジトリがあります。
### メタパッケージ { #metapackages }
-メタパッケージは、複数の他のコンポーネントを包括するComposerパッケージです。これには、例えば、LaravelやDrupalのコアファイル、必要なモジュールなどが含まれます。 またはテーマ。これにより、プロジェクトの依存関係に Laravel や Drupal などを含める必要がありません。
+メタパッケージは、複数の他のコンポーネントを包括するComposerパッケージです。これには、例えば、LaravelやDrupalのコアファイル、必要なモジュールやテーマなどが含まれます。 これにより、プロジェクトの依存関係に Laravel や Drupal などを含める必要がありません。
-以下は、Laravel ベースのイメージの `composer.json` からの例です:
+以下は、Laravelのベースイメージを `composer.json` から使用した例です:
```text title="composer.json"
"require": {
@@ -33,23 +33,23 @@
},
```
-私たちはこのメタパッケージだけを必要とし、これは GitHub のリポジトリを指しています。
+私たちに必用なのはGitHubリポジトリを指すこのメタパッケージだけです。
### `docker-compose.yml` { #docker-composeyml }
-プロジェクトの他の部分は [`docker-compose.yml`](../concepts-basics/docker-compose-yml.md) で定義されています。例えば、Drupal プロジェクトを持っている場合、Drupal のイメージが必要ですが、MariaDB、Solr、Redis、Varnish も必要です。これらのサービスのバージョンは Drupal に最適化されており、すべて `docker-compose.yml` に含まれています。
+プロジェクトの他の部分は [`docker-compose.yml`](../concepts-basics/docker-compose-yml.md) で定義されています。例えば、Drupalプロジェクトを持っている場合、Drupal のイメージが必要ですが、MariaDB、Solr、Redis、Varnishも必要です。これらのサービスのバージョンはDrupalに最適化されており、すべて`docker-compose.yml`に含まれています。
### Drupal { #drupal }
-Drupal ベースのイメージには、Drupal コアに加えて以下の貢献ツールとモジュールが含まれています:
+Drupalベースのイメージには、Drupalコアに加えて以下のコントリビュートツールやモジュールが含まれています:
-* [Drupal コンソール](https://drupalconsole.com/)
+* [Drupal Console](https://drupalconsole.com/)
* [Drush](https://www.drush.org/)
-* [設定インストーラ](https://www.drupal.org/project/config_installer)
+* [Configuration installer](https://www.drupal.org/project/config_installer)
* [Redis](https://www.drupal.org/project/redis)
* [Poll](https://www.drupal.org/project/poll)
* [Search API](https://www.drupal.org/project/search_api)
-* [Search API Solr](https://www.drupal.org/project/search _api_solr)
+* [Search API Solr](https://www.drupal.org/project/search_api_solr)
* [Varnish Purge](https://www.drupal.org/project/varnish_purge)
* [Purge](https://www.drupal.org/project/purge)
* [Admin Toolbar](https://www.drupal.org/project/admin_toolbar)
@@ -62,7 +62,7 @@ Drupal ベースのイメージには、Drupal コアに加えて以下の貢献
#### 設定 { #configuration }
-基本イメージは、Laravelで使用される環境変数のデフォルト値を提供しています。
+ベースイメージは、Laravelで使用される環境変数のデフォルト値を提供しています。
これらは以下の値です:
@@ -80,7 +80,7 @@ Drupal ベースのイメージには、Drupal コアに加えて以下の貢献
#### キュー { #queues }
-プロジェクトが[キュー](https://laravel.com/docs/5.8/queues)を使用している場合、`artisan-worker`サービスを使用できます。これはワーカーコンテナで、[`artisan queue:work`](https://laravel.com/docs/5.8/queues#running-the-queue-worker)の実行に使用されます。これはデフォルトでは無効化されています - `docker-compose.yml`のコメントをご覧ください。
+プロジェクトが[キュー](https://laravel.com/docs/5.8/queues)を使用している場合、`artisan-worker`サービスを使用できます。これはワーカーコンテナで、[`artisan queue:work`](https://laravel.com/docs/5.8/queues#running-the-queue-worker)の実行に使用されます。これはデフォルトでは無効化されています。（`docker-compose.yml`のコメントをご覧ください）
## ビルドプロセスの理解 ベースイメージ { #understanding-the-process-of-building-a-base-image }
@@ -88,16 +88,16 @@ Drupal ベースのイメージには、Drupal コアに加えて以下の貢献
### Makefileとビルドの前提条件 { #makefile-and-build-assumptions }
-ローカルで実行する予定の場合、少なくとも必要な環境変数が存在する必要があります。
+ローカルで実行する場合、ビルドするために最低限必用な環境変数がいくつかあります。
### ベースイメージビルド変数 { #base-image-build-variables }
-ベースイメージビルドプロセスに注入される変数と、それを見つける場所。
+ベースイメージビルドプロセスに注入される変数と、それを見つける場所です。
* `BUILD_NUMBER` - これは自動的にJenkinsによって注入されます。
-* `GIT_BRANCH` - これはJenkinsのビルドプロセス自体によって提供されます。ビルド時にどのブランチが使用されるかによります(develop、mainなど)。
-* `DOCKER_REPO`/`DOCKER_HUB` - これはJenkinsfile自体内で定義されています。これはDockerプロジェクトとハブを指しています。 生成された画像はプッシュされます。
-* `DOCKER_USERNAME`/`DOCKER_PASSWORD` - これらは、ビルドの早い段階でDockerリポジトリに実際にログインするために使用されます。これらの変数はJenkinsの資格情報内に保存されます。これらはJenkinsfile自体で使用され、Makefileの一部ではありません。つまり、Jenkins以外の場所(つまり、ローカルでテストするなど)でベースイメージをビルドする場合、`docker login`を手動で実行する必要があります。
+* `GIT_BRANCH` - これはJenkinsのビルドプロセス自体によって提供されます。その時点でビルドされているブランチ(develop、mainなど)に依存します。
+* `DOCKER_REPO`/`DOCKER_HUB` - これはJenkinsfile自体内で定義されていて生成されたイメージがプッシュされるDockerプロジェクトとハブを指しています。
+* `DOCKER_USERNAME`/`DOCKER_PASSWORD` - これらは、ビルドの早い段階でDockerリポジトリに実際にログインするために使用されます。これらの変数はJenkinsの認証情報内に保存されます。これらはJenkinsfile自体で使用され、Makefileの一部ではありません。つまり、Jenkins以外の場所(ローカルでテストするなど)でベースイメージをビルドする場合、`docker login`を手動で実行する必要があります。
実際には、ローカルマシンで`make`ターゲットを実行している場合、これらが環境で利用可能であることを確認したいと思うでしょう - たとえば、コマンドラインからmakeを実行するときにこれらを設定するだけでも構いません:
@@ -115,29 +115,29 @@ GIT_BRANCH=example_branch_name DOCKER_HUB=the_docker_hub_the_images_are_pushed_t
* `images_test`:イメージに対して基本的なテストを実行します。
* `images_remove`:ビルド環境変数が与えられると、以前にビルドされたイメージを削除します。
-### ベースイメージの新リリースをビルドするための例のワークフロー { #example-workflow-for-building-a-new-release-of-a-base-image }
+### ベースイメージの新リリースをビルドするワークフロー例 { #example-workflow-for-building-a-new-release-of-a-base-image }
-ビルドプロセスにはいくつかのステップがあります。これらのほとんどは、さまざまなベースイメージ間で共有されています。これらは主に上記で説明したMakefileターゲットに対応しています。
+ビルドプロセスにはいくつかのステップがあります。これらのほとんどは、様々なベースイメージ間で共有されています。これらは主に上記で説明したMakefileターゲットに対応しています。
-1. **Dockerログイン** - Dockerのユーザー名、パスワード、HarborのURLがDockerクライアントに渡されます。
-2. **Dockerビルド** - `make images_build`ステップが現在実行されます。これにより以下のことが行われます:
- 1. すべての環境変数がビルドの準備ができていることを確認します。
+1. **Docker Login** - Dockerのユーザー名、パスワード、HarborのURLがDockerクライアントに渡されます。
+2. **Docker Build** - `make images_build`ステップが現在実行されます。これにより以下のことが行われます:
+ 1. すべての環境変数がビルドのために準備されていることを確認します。
2. `docker-compose build`を実行します。これにより、現在のGitブランチからいくつかの新しいDockerイメージが生成されます。
-3. **イメージテスト** - これにより`make images_test`ターゲットが実行されます。これはテストされるイメージにより異なります。ほとんどの場合、これはイメージを開始し、何らかの方法で対話できることを確認する非常に直感的なテストです(Drupalのインストール、ファイルのリスト表示など)。
+3. **Image Test** - これにより`make images_test`ターゲットが実行されます。これはテストされるイメージにより異なります。ほとんどの場合、これはイメージを開始し、何らかの方法で対話できることを確認する非常に直感的なテストです(Drupalのインストール、ファイルのリスト表示など)。
4. **Docker Push** - このステップでは、`images_publish`のmakeターゲットに含まれるロジックが実行され、その結果として生成されたイメージにタグが付けられます。 ステップ2の**Docker Build**でそれらをHarborにプッシュします。これについては、本ガイドの[他の場所](base-images.md#step-4-building-the-new-base-images)で詳しく説明されています。
5. **Docker Clean Images** - `images_remove`というmakeターゲットを実行し、これらがHarborにあるため、新しくビルドされたイメージをDockerホストから単純に削除します。
#### ベースイメージの新バージョンのリリース { #releasing-a-new-version-of-a-base-image }
-ベースイメージの新バージョンをリリースする理由は多々あります。DrupalやLaravel、Node.jsなどのイメージでは、機能やセキュリティのためにモジュール/パッケージをアップグレードまたはインストールするためかもしれません。また、コンテナにバンドルされている基本ソフトウェアのバージョンを更新することもあります。例えば、PHPやNode.jsのバージョンを更新するなどです。また、ベースイメージがビルドされている実際の基本的な_イメージ_を更新することもあります。
+ベースイメージの新バージョンをリリースする理由は多々あります。DrupalやLaravel、Node.jsなどのイメージでは、機能やセキュリティのためにモジュールやパッケージをアップグレードまたはインストールするかもしれません。また、コンテナにバンドルされている基本ソフトウェアのバージョンを更新することもあります。例えば、PHPやNode.jsのバージョンを更新するなどです。また、ベースイメージがビルドされている実際の基本的なイメージを更新することもあります。
-あなたのプロジェクトのベースイメージがビルドされているイメージは、Lagoonチームによって管理されているイメージです。これらの基本イメージは月に一回(またはそれ以上)の頻度で更新されます。これらが更新されたとき、あなたはアップストリームのイメージにバンドルされている変更とアップグレードを取り入れるために、自分自身のベースイメージの新バージョンをビルドする必要があります。
+あなたのプロジェクトのベースとなるイメージは、Lagoonチームによって管理されているイメージです。これらのベースイメージは月に一回(またはそれ以上)の頻度で更新されます。これらが更新されたとき、あなたはアップストリームのイメージにバンドルされている変更とアップグレードを取り入れるために、自分自身のベースイメージの新バージョンをビルドする必要があります。
-このセクションでは、そのプロセスを示します。 Drupal 8基本イメージの新リリースを更新およびタグ付けします。我々は新しいモジュール([ClamAV](https://www.drupal.org/project/clamav))を基に追加します。Drupalをデモンストレーションするのは、基本イメージの中で最も複雑なセットアップを持っているからです。すべての基本イメージに共通する手順は以下に記載されています。
+このセクションでは、そのプロセスを示します。 Drupal8のベースイメージの新リリースを更新およびタグ付けします。我々は新しいモジュール([ClamAV](https://www.drupal.org/project/clamav))を基に追加します。Drupalでデモを行うのは、ベースイメージの中で最も設定が複雑だからです。すべてのベースイメージに共通する手順を以下に記載します。
-#### ステップ1 - 基本イメージをローカルにダウンロードする { #step-1-pull-down-the-base-image-locally }
+#### ステップ1 - ベースイメージをローカルにダウンロードする { #step-1-pull-down-the-base-image-locally }
-これは単にGitリポジトリをローカルにダウンロードすることです。Drupal 8基本イメージの場合です。この例では、Bitbucketを使用しているので、次のコマンドを実行します:
+これは単にGitリポジトリをローカルにダウンロードすることです。Drupal8のベースイメージの場合では、Bitbucketを使用しているので次のコマンドを実行します:
```bash title="Clone Git repo."
git clone ssh://git@bitbucket.biscrum.com:7999/webpro/drupal8_base_image.git
@@ -148,11 +148,11 @@ git clone ssh://git@bitbucket.biscrum.com:7999/webpro/drupal8_base_image.git
#### ステップ2 - リポジトリに変更を加える { #step-2-make-the-changes-to-the-repository }
!!! Info "情報"
- ここで示されていることはDrupal 8基本イメージに特有のものです。しかし、変更(ファイルの追加、基本的なDockerイメージの変更など)はすべての基本イメージでこのステップで行われます。
+ ここで示されていることはDrupal 8のベースイメージに特有のものです。しかし、あらゆる変更(ファイルの追加、基本的なDockerイメージの変更など)はすべてのベースイメージに対してこのステップで行われます。
-我々の例では、ClamAVモジュールをDrupal 8基本イメージに追加しています。これにはいくつかのステップが関与します。最初はパッケージを必要とすることで、これにより我々の`composer.json`ファイルに追加されます。これは`composer require`を実行することで行われます。
+我々の例では、ClamAVモジュールをDrupal 8のベースイメージに追加しています。これにはいくつかのステップが関与します。最初はパッケージを必要とすることで、これにより我々の`composer.json`ファイルに追加されます。これは`composer require`を実行することで行われます。
-ここで我々は実行します:
+次のコマンドを実行します:
```bash title="Composer requireでパッケージをインストールする。"
composer require drupal/clamav
```
@@ -160,22 +160,24 @@ composer require drupal/clamav
Composer requireのプロセスが完了すると、パッケージは`composer.json`ファイルに表示されるべきです。
-ここでは、`composer.json`ファイルを開き、必要なパッケージのリストを見て、ClamAVパッケージがリストされていることを確認し、それがそこにあることを確認します:
+ここでは、`composer.json`ファイルを開き、必要なパッケージのリストを見て、ClamAVパッケージがリストされていることを確認します。
#### ステップ2.2 - テンプレートベースの派生イメージで必要なDrupalモジュールが有効になっていることを確認する { #step-22-ensure-that-the-required-drupal-module-is-enabled-in-template-based-derived-images }
ベースイメージに追加された任意のモジュールは、テンプレートベースの派生イメージで有効にする必要があります。これは、モジュールをLagoon Bundleモジュールに追加することで行われます。これは具体的には、`dependencies`セクションの`lagoon_bundle.info.yml`ファイルに依存性として追加することを要求します。Lagoon Bundleモジュールは、派生イメージ間の依存関係を強制するためだけに存在するユーティリティモジュールです。
-ここでは、`web/modules/contrib/lagoon/lagoon_bundle/lagoon_bundle.info.yml`を開き、`clamav:clamav`を追加します。 依存関係:
+ここでは、`web/modules/contrib/lagoon/lagoon_bundle/lagoon_bundle.info.yml`を開き、依存関係として`clamav:clamav`を追加します。
-これに依存関係を追加することで、派生したイメージ上でLagoon Bundleモジュールが有効になるたびに、その依存関係(この場合、新たに追加されたClamAVモジュール)も有効になることを保証します。これは、ロールアウト時に`lagoon_bundle`を派生イメージで有効にするポストロールアウトスクリプトで強制されます。
+これに依存関係を追加することで、派生したイメージ上でLagoon Bundleモジュールが有効になるたびに、その依存関係(この場合、新たに追加されたClamAVモジュール)も有効になります。これは、ロールアウト時に`lagoon_bundle`を派生イメージで有効にするポストロールアウトスクリプトで強制されます。
#### ステップ2.3 - テスト { #step-23-test }
-これはあなたが何をテストしているかによります。ClamAVモジュールを追加する場合、ベースイメージでモジュールがダウンロードされ、Lagoon Bundleモジュールが有効化されたときにClamAVも有効化されることを確認したいと考えています。
-ここでは、モジュールが`/app/web/modules/contrib`にダウンロードされたことを確認します:
+これはあなたが何をテストしているかによります。ClamAVモジュールを追加する場合、ベースイメージでモジュールがダウンロードされ、Lagoon Bundleモジュールが有効化されたときにClamAVも有効化されることを確認したいです。
+ここでは、モジュールが`/app/web/modules/contrib`にダウンロードされたことを確認します。
+
-そして、`lagoon_bundle`モジュールを有効化するときに、`clamav`も有効化されることを確認するために、以下のコマンドを実行します:
+
+そして、`lagoon_bundle`モジュールを有効化するときに、`clamav`も有効化されることを確認するために、以下のコマンドを実行します。
```bash title="Drushでモジュールを有効化する。"
drush pm-enable lagoon_bundle -y
```
@@ -183,15 +185,15 @@ drush pm-enable lagoon_bundle -y
!!! Warning "警告"
- 上記のコンテナでJWTエラーが発生していることが分かるでしょう。これは安全に無視することができます 上記のデモンストレーションでは、背景として、あなたが作業しているサイトのためのLagoon環境が存在しない場合にこのエラーが表示されます。
+ 上記のコンテナでJWTエラーが発生していることが分かるでしょう。上のデモではこのエラーは無視してかまいません。背景として、あなたが作業しているサイトにLagoon環境が存在しない場合、このエラーが表示されます。
テストが終了したので、イメージをタグ付けしてビルドすることができます。
#### ステップ3 - イメージのタグ付け { #step-3-tagging-images }
-イメージは、[Gitタグ](https://git-scm.com/docs/git-tag)に基づいてバージョン管理されます - これらは標準的な[セマンティックバージョニング](https://semver.org/)(semver)の実践に従うべきです。すべてのタグは **vX.Y.Z** の構造を持つべきであり、X、Y、Zは整数です(正確にはX.Y.Z自体がセマンティックバージョンであり、vX.Y.Zはタグです)。これはイメージタグを決定するために使用される仮定であるため、_必ず_ それに従う必要があります。
+イメージは、[Gitタグ](https://git-scm.com/docs/git-tag)に基づいてバージョン管理されます - これらは標準的な[セマンティックバージョニング](https://semver.org/)(semver)のプラクティスに従うべきです。すべてのタグは **vX.Y.Z** の構造を持つべきであり、X、Y、Zは整数です(正確にはX.Y.Z自体がセマンティックバージョンであり、vX.Y.Zはタグです)。これはイメージタグを決定するために使用されるので必ず従う必要があります。
-この例では、ClamAVを追加したことを示すDrupal 8ベースイメージの新しいバージョンをタグ付けします。
+この例では、ClamAVを追加したことを示すDrupal8のベースイメージの新しいバージョンをタグ付けします。
#### ここでは、イメージのタグ付け方法を示します { #here-we-demonstrate-how-to-tag-an-image }
@@ -200,12 +202,12 @@ drush pm-enable lagoon_bundle -y
1. まだ変更をコミットしていなければ、コミットします。
2. 次に、`git tag`を使用して、どのタグにいるのかを確認します。
3. 次に、`git tag -a v0.0.9 -m “Adds clamAV to base.”`を使用してタグ付けします。
- 1. _git -a, --annotate: 署名なし、注釈付きのタグを作成します。 オブジェクト_
-4. 次に、`git push --tags`で我々のタグをプッシュします。
-5. 最後に、`git push`で我々の全ての変更をプッシュします。
+ 1. _git -a, --annotateを使うと 無署名の注釈付きタグオブジェクトを作成します。
+4. 次に、`git push --tags`でタグをプッシュします。
+5. 最後に、`git push`で全ての変更をプッシュします。
!!! Danger "危険"
- タグはそれ自体のステップで明示的にプッシュされなければなりません！
+ タグはそれ自体のステップで明示的にプッシュしなければなりません！
@@ -214,21 +216,21 @@ drush pm-enable lagoon_bundle -y
!!! Danger "危険"
ビルドワークフローによりますが、ほぼ確実に**develop**ブランチ経由で変更をプッシュし、それを**main**ブランチにマージするでしょう。
-ここで覚えておくべき重要な点は、Jenkinsのベースイメージのビルドプロセスは、_最新のコミットタグ_に基づいて_イメージ_をタグ付けするということです。
+ここで覚えておくべき重要な点は、Jenkinsのベースイメージのビルドプロセスは、最新のコミットタグに基づいてイメージをタグ付けするということです。
イメージは以下のルールでタグ付けされ、これに該当するものごとにイメージがビルドされます:
1. **main**ブランチがビルドされると、`latest`としてタグ付けされます。
2. developブランチがビルドされると、`development`としてタグ付けされます。
-3. ビルドされるコミットが_タグ付け_されていれば、そのブランチはそのコミットのタグ付けでビルドされます。
- 1. これは我々が上で示した新しいバージョンをリリースする方法です。これはまた、かなり任意のタグでアドホックなビルドを行うためにも使用できます - タグ名は適切であるべきです、それは_セマンティックバージョニング_のタグでのみテストされています。
+3. ビルドされるコミットがタグ付けされていれば、そのブランチはそのコミットのタグ付けでビルドされます。
+ 1. 上で示したように、これが新しいバージョンをリリースする方法です。また、任意のタグでアドホックなビルドを行うためにも使用できます。タグ名には十分注意してください。これらはセマンティックバージョニングのタグでのみテストされています。
#### ステップ4 - 新しいベースイメージのビルド { #step-4-building-the-new-base-images }
!!! Info "情報"
- 一般的には、自動ビルドのためのトリガー戦略がここに設定されていますが、それはあなたのニーズや設定によって異なるため、ここでは手動でビルドする方法を説明します。
+ 一般的には、自動ビルドのためのトリガーストラテジーをここに設定することになりますが、それはあなたのニーズや設定によって異なるため、ここでは手動でビルドする方法を説明します。
-1. あなたのLagoon Jenkinsインスタンスを訪れます。
+1. あなたのLagoon Jenkinsインスタンスにアクセスします。
2. 作業中のプロジェクト(この場合、AIOBI Drupal 8 Base)を選択します。
3. ビルドしたいブランチをクリックします。
4. 「Build Now」をクリックします。
@@ -239,7 +241,7 @@ drush pm-enable lagoon_bundle -y
ビルドが成功しない場合は、ビルド自体をクリックしてログを読み、どこで失敗したかを理解することができます。
-下のHarborからのスクリーンショットで示されているように、私たちがJenkinsでビルドしたばかりのイメージはHarborにアップロードされ、タグ付けされています。ここでは、それがv0.0.9とタグ付けされているため、そのタグのついたイメージが存在します。また、私たちは**main**ブランチをビルドしたので、「latest」イメージもビルドされました。この段階では、v0.0.9と「latest」のイメージは同一です。
+下のHarborからのスクリーンショットで示されているように、私たちがJenkinsでビルドしたばかりのイメージはHarborにアップロードされ、タグ付けされています。ここでは、それがv0.0.9とタグ付けされているため、そのタグのついたイメージが存在します。また、私たちは**main**ブランチをビルドしたので、「latest」イメージもビルドされました。この段階では、v0.0.9と「latest」イメージは同一です。
diff --git a/docs/ja/concepts-advanced/environment-idling.md b/docs/ja/concepts-advanced/environment-idling.md
index ec6d7a2f48..6e647147cd 100644
--- a/docs/ja/concepts-advanced/environment-idling.md
+++ b/docs/ja/concepts-advanced/environment-idling.md
@@ -11,12 +11,12 @@ Lagoonは、[Aergiaコントローラー](https://github.com/amazeeio/aergia-con
* アイドリングは4時間ごとに試みられます。
* 本番環境は決してアイドル状態になりません。
* CLIポッドは、cronジョブが含まれておらず、リモートシェル接続がアクティブでない場合にアイドル状態になります。
-* 他のすべてのサービスとポッドは、環境上で過去4時間間にトラフィックがなかった場合にアイドル状態になります。
+* 他のすべてのサービスとポッドは、環境上で過去4時間の間にトラフィックがなかった場合にアイドル状態になります。
* アクティブなビルドが進行中であれば、アイドリングは行われません。
### 環境はどのようにしてアイドル状態から解除されますか？
-Aergiaは、環境が訪問されるとすぐに自動的にアイドル状態を解除します。 したがって、環境の任意のURLを訪れるだけで環境が起動します。同様に、環境へのSSHセッションを開始すると、サービスも再開します。
+Aergiaは、任意の環境がアクセスされると自動的にアイドル状態を解除します。 そのため、環境のURLにアクセスするだけで環境が起動します。同様に、環境へのSSHセッションを開始すると、サービスも再開します。
アンアイドリングは数秒かかります。なぜなら、Kubernetesクラスタはすべてのコンテナを再起動する必要があるからです。この間、訪問者には、現在自分の環境が起動中であることを示す待機画面が表示されます。
diff --git a/docs/ja/concepts-advanced/environment-types.md b/docs/ja/concepts-advanced/environment-types.md
index 13030b2af8..878dcd33e1 100644
--- a/docs/ja/concepts-advanced/environment-types.md
+++ b/docs/ja/concepts-advanced/environment-types.md
@@ -4,14 +4,14 @@ Lagoonは現在、`production(本番環境)`と`development(開発環境)`の2
Lagoon GraphQL APIを通じてプロジェクトを設定する際には、`productionEnvironment`を定義することができます。Lagoonが実行するすべてのデプロイメントで、現在の環境名が`productionEnvironment`で定義されているものと一致するかどうかをチェックします。もしそうであれば、Lagoonはこの環境を`production`環境としてマークします。これは2つの場所で行われます:
-1. GraphQL API自体内で。
-2. すべてのコンテナ内で`LAGOON_ENVIRONMENT_TYPE`という名前の環境変数として。
+1. GraphQL API自体内。
+2. すべてのコンテナ内の`LAGOON_ENVIRONMENT_TYPE`という名前の環境変数。
-しかしそれだけです。Lagoon自体は`development`と`production`の環境をまったく同じように扱います(最終的には環境の違いをできるだけ少なくすることが目指しています - それがLagoonの美しさです)。
+この2つだけです。Lagoon自体は`development`と`production`の環境をまったく同じように扱います(最終的には環境の違いをできるだけ少なくすることを目指しています - それがLagoonの美しさです)。
この情報を使用するものがいくつかあります:
-* デフォルトでは、`development`環境はヒットが4時間ない場合に休止状態になります(心配しないでください、自動的に起動します)。また、Lagoonの管理者に一つずつの環境で自動休止を無効にするよう依頼することも可能です！
-* デフォルトのDrupal `settings.php`ファイルは、`development.settings.php`と `production.settings.php`は、環境タイプごとに異なる設定や構成を定義できます。
-* もし、プロダクション環境として定義された環境(ウェブフックまたはREST経由で)を削除しようとすると、Lagoonはあなたが誤って削除するのを防ぐために、礼儀正しく削除を拒否します。プロダクション環境を削除するためには、APIで`productionEnvironment`を変更するか、REST APIのPOSTペイロードで秘密の`forceDeleteProductionEnvironment: true`を使用できます。
-* Lagoonの管理者は、プロダクション環境情報を追加の事項に使用することがあります。例えば、amazee.ioでは、ホスティングの価格を計算するために、プロダクション環境のヒット数だけを計算しています。
+* デフォルトでは、`development`環境はヒットが4時間ない場合に休止状態になります(心配しないでください、自動的に起動します)。また、Lagoonの管理者に1つずつの環境で自動休止を無効にするよう依頼することも可能です！
+* デフォルトのDrupal `settings.php`ファイルは、`development.settings.php`と `production.settings.php`という追加の設定ファイルを読み込みます。これにより、環境タイプごとに異なる設定や構成を定義できます。
+* もし、あなたが`production`環境として定義された環境(ウェブフックまたはREST経由で)を削除するなら、Lagoonは誤って削除するのを防ぐために拒否します。`production`環境を削除するには、APIで`productionEnvironment`を変更するか、REST APIのPOSTペイロードで`forceDeleteProductionEnvironment: true`を使用する必用があります。
+* Lagoonの管理者は、`production`環境情報を追加の目的で使用することがあります。例えば、amazee.ioでは、ホスティングの価格を計算するために、`production`環境のヒット数だけを計算しています。
diff --git a/docs/ja/concepts-advanced/environment-variables.md b/docs/ja/concepts-advanced/environment-variables.md
index dd840b687d..dfc8d61037 100644
--- a/docs/ja/concepts-advanced/environment-variables.md
+++ b/docs/ja/concepts-advanced/environment-variables.md
@@ -1,24 +1,24 @@
# 環境変数
-APIトークンやアプリケーションの資格情報を環境変数に保存することは一般的です。
+APIトークンやアプリケーションのクレデンシャルを環境変数に保存することは一般的です。
-ベストプラクティスに従って、これらの資格情報は環境ごとに異なります。私たちは、各環境が環境変数または環境ファイルで定義された別の環境変数セットを使用できるようにします。
+ベストプラクティスに従うと、これらのクレデンシャルは環境ごとに異なります。私たちは、各環境が環境変数または.`env`ファイルで定義された別の環境変数セットを使用できるようにします。
-Dockerfileまたはランタイム時(API環境変数経由)のいずれかで定義されている環境変数があるため、環境変数の階層があります。低い数字で定義された環境変数が強いです。
+環境変数にはDockerfileまたはランタイム時(API環境変数経由)のいずれかで定義される場合があるため優先順位があり、より低い数字で定義された環境変数が優先されます。
1. 環境変数(Lagoon API経由で定義) - 環境固有。
2. 環境変数(Lagoon API経由で定義) - プロジェクト全体。
3. Dockerfileで定義された環境変数(`ENV`コマンド)。
-4. `.lagoon.env.$LAGOON_GIT_BRANCH`または`.lagoon.env.$LAGOON_GIT_SAFE_BRANCH`で定義された環境変数(ファイルが存在し、`$LAGOON_GIT_BRANCH` `$LAGOON_GIT_SAFE_BRANCH`がこのDockerイメージがビルドされたブランチの名前と安全な名前である場合)、これを特定のブランチのみの変数の上書きに使用します。
-5. `.lagoon.env`で定義された環境変数(存在する場合)、これを全ての変数の上書きに使用します。 ブランチ。
+4. `.lagoon.env.`の`$LAGOON_GIT_BRANCH`または`.lagoon.env.`の`$LAGOON_GIT_SAFE_BRANCH`で定義された環境変数(ファイルが存在し、`$LAGOON_GIT_BRANCH`と`$LAGOON_GIT_SAFE_BRANCH`がこのDockerイメージがビルドされたブランチの名前と一致する名前である場合、これらの値をこの特定のブランチの変数に上書きします。）
+5. `.lagoon.env`で定義された環境変数(存在する場合)、これを全てのブランチの変数の上書きに使用します。
6. `.env`で定義された環境変数。
7. `.env.defaults`で定義された環境変数。
-`.lagoon.env.$LAGOON_GIT_BRANCH`、`.lagoon.env.$LAGOON_GIT_SAFE_BRANCH`、`.env`、そして `.env.defaults`は、全て、各コンテナ自体によってエントリーポイントスクリプトの一部として実行される際にソース化されます。それらはLagoonではなく、コンテナの `ENTRYPOINT` スクリプトによって読み込まれ、コンテナの作業ディレクトリでそれらを探します。環境変数が期待通りに表示されない場合は、コンテナに他の場所を指す `WORKDIR` 設定があるかどうかを確認してください。
+`.lagoon.env.`の`$LAGOON_GIT_BRANCH`、`.lagoon.env.`の`$LAGOON_GIT_SAFE_BRANCH`、`.env`、そして `.env.defaults`は、全て、各コンテナ自体によってエントリーポイントスクリプトの一部として実行される際にソース化されます。それらはLagoonではなく、コンテナの`ENTRYPOINT`スクリプトによって読み込まれ、コンテナの作業ディレクトリでそれらを探します。環境変数が期待通りに表示されない場合は、コンテナに他の場所を指す`WORKDIR`設定があるかどうかを確認してください。
## 環境変数 - Lagoon API { #environment-variables-lagoon-api }
-Gitリポジトリに保存したくない変数(シークレットやAPIキーなど)については、Lagoon APIの環境変数システムを使用することをお勧めします。これらの変数は、誰かがローカルの開発環境やインターネット上に持っていると、危険にさらされる可能性があります。
+Gitリポジトリに保存したくない変数(シークレットキーやAPIキーなど)については、Lagoon APIの環境変数システムを使用することをお勧めします。これらの変数は、誰かがローカルの開発環境やインターネット上に持っていると、危険にさらされる可能性があります。
Lagoon APIでは、プロジェクト全体または環境固有の変数を定義することができます。さらに、スコープ限定のビルド時またはランタイムに対して定義することもできます。これらはすべてLagoon GraphQL APIを通じて作成されます。GraphQL APIの使用方法については、[GraphQL API](../interacting/graphql.md)のドキュメンテーションで詳しく説明しています。
@@ -70,7 +70,7 @@ mutation addRuntimeEnv {
ARG MYVARIABLENAME
```
-通常、`ARG`はその後に行くでしょう。 FROM. [ARGとFROMについてのdockerドキュメントを読む](https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact)。
+通常、`ARG`は`FROM`の後に記述します。[ARGとFROMについてのdockerドキュメントを読む](https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact)。
これは、ID `463`のプロジェクト全体のビルド時変数(すべての環境で利用可能)を定義します。
@@ -141,7 +141,7 @@ mutation addContainerRegistryEnv {
## Gitリポジトリに直接存在する環境ファイル { #environment-files-existing-directly-in-the-git-repo }
-Gitリポジトリ内に安全に保存できる環境変数がある場合、追加することをお勧めします Gitリポジトリの環境ファイルに直接入力します。これらの変数はローカル開発環境でも利用可能であり、より移植性が高いです。
+Gitリポジトリ内に安全に保存できる環境変数がある場合、それらをファイルに直接追加することをお勧めします 。これらの変数はローカル開発環境でも利用可能であり、より移植性が高くなります。
環境ファイルの構文は次のとおりです:
@@ -157,15 +157,15 @@ DB_USER=$DB_USERNAME # DB_USERNAMEの値でDB_USERを再定義します。例え
### `.env` and `.env.defaults` { #env-and-envdefaults }
-`.env`と`.env.defaults`は、他に定義されていない場合の環境変数のデフォルト値として機能します。例えば、プルリクエスト環境用のデフォルト環境変数として([Workflows](workflows.md#pull-requests)参照)。
+`.env`と`.env.defaults`は、他に定義されていない場合の環境変数のデフォルト値として機能します。例えば、プルリクエスト環境用のデフォルト環境変数として利用します([Workflows](workflows.md#pull-requests)参照)。
## 特別な環境変数 { #special-environment-variables }
### `PHP_ERROR_REPORTING` { #php_error_reporting }
-この変数が設定されている場合、PHPが使用する[ログ](../logging/logging.md)レベルを定義します。指定されていない場合は、それが これはプロダクション環境か開発環境かによって動的に設定されます。
+この変数が設定されている場合、PHPが使用する[ログ](../logging/logging.md)レベルを定義します。指定されていない場合は、`production`環境か開発環境かによって動的に設定されます。
-プロダクション環境では、この値はデフォルトで`E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE`になります。
+`production`環境では、この値はデフォルトで`E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE`になります。
開発環境では、この値はデフォルトで`E_ALL & ~E_DEPRECATED & ~E_STRICT`になります。
@@ -177,31 +177,31 @@ Lagoonは、次の4つの変数すべてが`BUILD`タイプの変数として設
| 環境変数名 | 目的 |
|:---------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `LAGOON_BAAS_CUSTOM_BACKUP_ENDPOINT` | Lagoon によって開始されたバックアップを保存する S3 互換エンドポイントを指定します。S3 Sydney の例は次のようになります。 `https://s3.ap-southeast-2.amazonaws.com`. |
-| `LAGOON_BAAS_CUSTOM_BACKUP_BUCKET` | Lagoon によって開始されたバックアップを保存するバケット名を指定します。カスタム設定の例は次のようになります。 `example-restore-bucket`. |
-| `LAGOON_BAAS_CUSTOM_BACKUP_ACCESS_KEY` | カスタム バックアップ バケットにアクセスするために Lagoon が使用するアクセス キーを指定します。カスタム設定の例は次のようになります。 `AKIAIOSFODNN7EXAMPLE`. |
-| `LAGOON_BAAS_CUSTOM_BACKUP_SECRET_KEY` | カスタム バックアップ バケットにアクセスするために Lagoon が使用する秘密キーを指定します。カスタム設定の例は次のようになります。 `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`. |
+| `LAGOON_BAAS_CUSTOM_BACKUP_ENDPOINT` | Lagoonによって開始されたバックアップを保存するS3互換エンドポイントを指定しますS3 Sydneyの例は次のようになります。 `https://s3.ap-southeast-2.amazonaws.com` |
+| `LAGOON_BAAS_CUSTOM_BACKUP_BUCKET` | Lagoonによって開始されたバックアップを保存するバケット名を指定します。カスタム設定の例は次のようになります。 `example-restore-bucket` |
+| `LAGOON_BAAS_CUSTOM_BACKUP_ACCESS_KEY` | カスタム バックアップバケットにアクセスするためにLagoonが使用するアクセスキーを指定します。カスタム設定の例は次のようになります。 `AKIAIOSFODNN7EXAMPLE` |
+| `LAGOON_BAAS_CUSTOM_BACKUP_SECRET_KEY` | カスタムバックアップバケットにアクセスするためにLagoonが使用する秘密キーを指定します。カスタム設定の例は次のようになります。 `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` |
-S3 バケットではパブリック アクセスは不要で、完全にプライベートにすることができます。
+S3バケットではパブリックアクセスは不要で、完全にプライベートにすることができます。
-Lagoon はこれらの S3 バケット内のファイルを自動的に削除するため、バケット レベルでオブジェクト保持ポリシーは必要ありません。
+LagoonはこれらのS3バケット内のファイルを自動的に削除するため、バケットレベルでのオブジェクト保持ポリシーは必要ありません。
### カスタム復元場所 { #custom-restore-location }
-`BUILD`タイプの環境変数として以下の全4つの変数が設定されている場合、任意のプロジェクトに対してカスタムリストアロケーションと資格情報を設定できます。環境変数はプロジェクトレベルで設定する必要があり(環境ごとではなく)、それらを設定した後、Lagoonのデプロイが必要です(各環境について)。
+`BUILD`タイプの環境変数として以下の全4つの変数が設定されている場合、任意のプロジェクトに対してカスタムリストアロケーションとクレデンシャルを設定できます。環境変数はプロジェクトレベルで設定する必要があり(環境ごとではなく)、それらを設定した後、Lagoonのデプロイが必要です(各環境について)。
-これらの変数を使用すると、Lagoonによって復元されたすべての環境とデータベースのスナップショットがこれらの資格情報を使用して保存されることに注意してください。これは、これらの資格情報へのアクセスが中断されると、復元されたファイルの失敗またはアクセス不能につながる可能性があることを意味します。
+これらの変数を使用すると、Lagoonによって復元されたすべての環境とデータベースのスナップショットがこれらのクレデンシャルを使用して保存されることに注意してください。これらのクレデンシャルへのアクセスが中断されると、復元されたファイルの失敗またはアクセス不能につながる可能性があることを意味します。
| 環境変数名 | 目的 |
|:----------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `LAGOON_BAAS_CUSTOM_RESTORE_ENDPOINT` | Lagoon によって開始された復元を保存する S3 互換エンドポイントを指定します。S3 Sydney の例は次のようになります。 `https://s3.ap-southeast-2.amazonaws.com`. |
-| `LAGOON_BAAS_CUSTOM_RESTORE_BUCKET` | Lagoon によって開始された復元を保存するバケット名を指定します。カスタム設定の例は次のようになります。 `example-restore-bucket`. |
-| `LAGOON_BAAS_CUSTOM_RESTORE_ACCESS_KEY` | カスタム復元バケットにアクセスするために Lagoon が使用するアクセス キーを指定します。カスタム設定の例は次のようになります。 `AKIAIOSFODNN7EXAMPLE`. |
-| `LAGOON_BAAS_CUSTOM_RESTORE_SECRET_KEY` | カスタム復元バケットにアクセスするために Lagoon が使用する秘密キーを指定します。カスタム設定の例は次のようになります。 `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`. |
+| `LAGOON_BAAS_CUSTOM_RESTORE_ENDPOINT` | Lagoonによって開始された復元を保存する S3 互換エンドポイントを指定します。S3 Sydneyの例は次のようになります。 `https://s3.ap-southeast-2.amazonaws.com` |
+| `LAGOON_BAAS_CUSTOM_RESTORE_BUCKET` | Lagoonによって開始された復元を保存するバケット名を指定します。カスタム設定の例は次のようになります。 `example-restore-bucket` |
+| `LAGOON_BAAS_CUSTOM_RESTORE_ACCESS_KEY` | カスタム復元バケットにアクセスするためにLagoonが使用するアクセスキーを指定します。カスタム設定の例は次のようになります。 `AKIAIOSFODNN7EXAMPLE` |
+| `LAGOON_BAAS_CUSTOM_RESTORE_SECRET_KEY` | カスタム復元バケットにアクセスするためにLagoonが使用するシークレットキーを指定します。カスタム設定の例は次のようになります。 `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` |
-Lagoon は必要に応じてバケット内のオブジェクトの[署名済み URL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) を作成するため、S3 バケットではパブリック アクセスが有効になっている必要があります。
+Lagoonは必要に応じてバケット内のオブジェクトの[署名済みURL](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html) を作成するため、S3バケットではパブリックアクセスが有効になっている必要があります。
-S3 バケット `example-restore-bucket` のみへのアクセスを許可するように作成できる AWS IAM ポリシーの例は次のとおりです。
+S3バケット `example-restore-bucket` のみへのアクセスを許可するように作成できる AWS IAM ポリシーの例は次のとおりです。
```json title="aws_iam_restore_policy.json"
{
@@ -234,4 +234,4 @@ S3 バケット `example-restore-bucket` のみへのアクセスを許可する
}
```
-増強されたセキュリティと削減されたストレージコストのために、[設定されたライフタイム後に復元されたバックアップを削除する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)(例えば、7日間)を選択することができます。Lagoonはこのシナリオをうまく処理し、必要に応じて復元されたスナップショットを再作成します。
+セキュリティの強化とストレージコスト削減のために、[設定されたライフタイム後に復元されたバックアップを削除する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)(例えば、7日間)を選択することができます。Lagoonはこのシナリオをうまく処理し、必要に応じて復元されたスナップショットを再作成します。
diff --git a/docs/ja/concepts-advanced/feature-flags.md b/docs/ja/concepts-advanced/feature-flags.md
index b69ee77241..ae47ecd9af 100644
--- a/docs/ja/concepts-advanced/feature-flags.md
+++ b/docs/ja/concepts-advanced/feature-flags.md
@@ -1,4 +1,4 @@
-＃フィーチャーフラグ
+# フィーチャーフラグ
Lagoonの一部の機能は、フィーチャーフラグを設定することで制御できます。
これは、新しいプラットフォーム機能を制御された方法で展開するためのユーザーと管理者を支援するように設計されています。
@@ -8,14 +8,14 @@ Lagoonの一部の機能は、フィーチャーフラグを設定すること
以下の環境変数は、フィーチャーフラグを切り替えるために環境またはプロジェクトに設定することができます。
| 環境変数名 | アクティブスコープ | 導入されたバージョン | 削除されたバージョン | デフォルト値 | 説明 |
-| --- | --- | --- | --- | --- | --- | |
-| `LAGOON_FEATURE_FLAG_ROOTLESS_WORKLOAD` | `global` | 2.2.0 | - | `無効` | この環境またはプロジェクトのポッドに非rootポッドセキュリティコンテキストを設定するには、`有効`に設定します。
このフラグは最終的に廃止され、その時点で非rootワークロードが強制されます。 |
-| `LAGOON_FEATURE_FLAG_ISOLATION_NETWORK_POLICY` | `global` | 2.2.0 | - | `無効` | デプロイ時に各環境にデフォルトの名前空間分離ネットワークポリシーを追加するには、`有効`に設定します。
このフラグは最終的に廃止され、その時点で名前空間分離ネットワークポリシーが強制されます。
注: この機能を有効にしてから無効にすると、既存のネットワークは削除されません。 以前のデプロイからのポリシー。これらは手動で削除する必要があります。|
+| --- | --- | --- | --- | --- | --- |
+| `LAGOON_FEATURE_FLAG_ROOTLESS_WORKLOAD` | `global` | 2.2.0 | - | `無効` | この環境またはプロジェクトのポッドに非rootポッドセキュリティコンテキストを設定するには、`enabled`に設定します。
このフラグは最終的に廃止され、その時点で非rootワークロードが強制されます。 |
+| `LAGOON_FEATURE_FLAG_ISOLATION_NETWORK_POLICY` | `global` | 2.2.0 | - | `無効` | デプロイ時に各環境にデフォルトの名前空間分離ネットワークポリシーを追加するには、`enabled`に設定します。
このフラグは最終的に廃止され、その時点で名前空間分離ネットワークポリシーが強制されます。
注: この機能を有効にしてから無効にすると、既存のネットワークは削除されません。 以前のデプロイからのポリシー削除されません。これらは手動で削除する必要があります。|
## クラスターレベルのコントロール
機能フラグはクラスターレベルでも制御することができます。これに対応している[`lagoon-build-deploy`チャート](https://github.com/uselagoon/lagoon-charts/blob/main/charts/lagoon-build-deploy/values.yaml)があります。
-各機能フラグには、設定できる値が2種類あります:`default`と`force`。
+各機能フラグには、設定できる値が`default`と`force`の2種類あります。
-* `default`は、クラスターにデプロイされる環境のデフォルトポリシーを制御しますが、上記の環境変数によってプロジェクトレベルまたは環境レベルで上書きすることができます。
-* `force`もクラスターにデプロイされる環境のポリシーを制御しますが、上記の環境変数によって上書きすることは_できません_。
+* `default`はクラスターにデプロイされる環境のデフォルトポリシーを制御しますが、上記の環境変数によってプロジェクトレベルまたは環境レベルで上書きすることができます。
+* `force`もクラスターにデプロイされる環境のポリシーを制御しますが、上記の環境変数によって上書きすることはできません。
diff --git a/docs/ja/concepts-advanced/index.md b/docs/ja/concepts-advanced/index.md
index e1b9a0b990..e631d7dcd3 100644
--- a/docs/ja/concepts-advanced/index.md
+++ b/docs/ja/concepts-advanced/index.md
@@ -1,5 +1,5 @@
-# 高度なLagoonの概念
+# Lagoonの高度な概念
-このセクションでは、Lagoonのより高度な概念について説明します。Lagoonが初めての方は、まず[基本的なLagoonの概念](../concepts-basics/index.md)から始めてください。
+このセクションでは、Lagoonのより高度な概念について説明します。Lagoonを使うのが初めての方は、まず[Lagoonの基本概念](../concepts-basics/index.md)から始めてください。
-助けが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティやメンテナーに連絡してください。
+専門的なサポートが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティのメンバーやメンテナーに連絡してください。
diff --git a/docs/ja/concepts-advanced/service-types.md b/docs/ja/concepts-advanced/service-types.md
index 2041b42b5a..df843accbf 100644
--- a/docs/ja/concepts-advanced/service-types.md
+++ b/docs/ja/concepts-advanced/service-types.md
@@ -11,15 +11,15 @@
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `3000` 上の TCP 接続 | `3000` | はい | いいえ | `lagoon.service.port`, `lagoon.autogeneratedroute` |
+| `3000`でTCP接続 | `3000` | はい | いいえ | `lagoon.service.port`, `lagoon.autogeneratedroute` |
## `basic-persistent`
-`basic`と同じです。また、永続的なストレージを生成し、`lagoon.persistent` を通じてマウントの位置を定義します。
+`basic`と同じですが、**永続的なストレージを生成し**、`lagoon.persistent` をでマウントの位値を定義します。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | --- | :--- | :--- | :--- |
-| `3000`上のTCP接続 | `3000` | はい | はい | `lagoon.service.port`, `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
+| `3000`でTCP接続 | `3000` | はい | はい | `lagoon.service.port`, `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
## `cli`
@@ -31,7 +31,7 @@ PHP、Node.jsなど、任意のCLIコンテナに使用します。 `/var/run/se
## `cli-persistent`
-`cli`と同様に、`lagoon.persistent.name`が永続ストレージを持つサービスの名前を指定されることを期待しています。それは定義された`lagoon.persistent`ラベルの下にマウントされます。自身の永続ストレージを生成せず、別のサービスの永続ストレージをマウントするためだけに使用されます。
+`cli`と同じですが、`lagoon.persistent.name`は永続ストレージを持つサービスの名前を指定されることを期待しています。これは定義された`lagoon.persistent`ラベルの下にマウントされます。自身の永続ストレージを生成せず、別のサービスの永続ストレージをマウントするためだけに使用されます。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | その他のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -39,11 +39,11 @@ PHP、Node.jsなど、任意のCLIコンテナに使用します。 `/var/run/se
## `elasticsearch`
-Elasticsearchコンテナは、`/usr/share/el`の下に永続ストレージを自動生成します。 `elasticsearch/data`。
+Elasticsearchコンテナは、`/usr/share/el`の下に永続ストレージを自動生成します。 `elasticsearch/data`
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `localhost:9200/_cluster/health?local=true` 上のHTTP | 9200 | なし | はい | `lagoon.persistent.size` |
+| `localhost:9200/_cluster/health?local=true` でHTTP通信 | 9200 | なし | はい | `lagoon.persistent.size` |
## `kibana`
@@ -51,7 +51,7 @@ Kibanaコンテナ。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `5601` 上のTCP接続 | `5601` | はい | なし | - |
+| `5601`でTCP接続 | `5601` | はい | なし | - |
## `logstash`
@@ -59,11 +59,11 @@ Logstashコンテナ。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `9600` 上のTCP接続 | `9600` | なし | なし | - |
+| `9600`でTCP接続 | `9600` | なし | なし | - |
## `mariadb`
-Lagoonに自動的に`mariadb-single`と`mariadb-dbaas`の間を決めるように指示するメタサービス。
+Lagoonに`mariadb-single`と`mariadb-dbaas`のどちらかを自動的に決定させるメタサービス。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -74,9 +74,8 @@ Lagoonに自動的に`mariadb-single`と`mariadb-dbaas`の間を決めるよう
MariaDBコンテナ。`/lagoon/mysql-backup.sh 127.0.0.1`を実行するバックアップのcronジョブを24時間ごとに作成します。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
- | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `3306`でのTCP接続 | `3306` | なし | はい | `lagoon.persistent.size` |
+| `3306`でTCP接続 | `3306` | なし | はい | `lagoon.persistent.size` |
## `mariadb-dbaas`
@@ -88,7 +87,7 @@ DBaaSオペレーターを介した共有MariaDBサーバーを使用します
## `mongo`
-Lagoonに`mongo-single`と`mongo-dbaas`の間で自動的に決定させるメタサービス。
+Lagoonに`mongo-single`と`mongo-dbaas`のどちらかを自動的に決定させるメタサービス。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -96,11 +95,11 @@ Lagoonに`mongo-single`と`mongo-dbaas`の間で自動的に決定させるメ
## `mongo-single`
-MongoDBコンテナー、`/data/db`にマウントされた最小1GBの永続ストレージを生成します。
+MongoDBコンテナ、`/data/db`にマウントされた最小1GBの永続ストレージを生成します。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `27017`でのTCP接続 | `27017` | なし | はい | `lagoon.persistent.size` |
+| `27017`でTCP接続 | `27017` | なし | はい | `lagoon.persistent.size` |
## `mongo-dbaas`
@@ -128,11 +127,11 @@ NGINXコンテナ。永続的なストレージはありません。
## `nginx-php-persistent`
-`nginx-php`と同様。永続的なストレージを生成し、`lagoon.persistent` でマウント位置を定義します。
+`nginx-php`と同様。永続的なストレージを生成し、`lagoon.persistent` でマウントの位置を定義します。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| NGINX: `localhost:50000/nginx_status`, PHP: `/usr/sbin/check_fcgi` | http on `8080` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
+| NGINX: `localhost:50000/nginx_status`, PHP: `/usr/sbin/check_fcgi` | httpの`8080` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
## `node`
@@ -140,15 +139,15 @@ Node.js コンテナ。永続的なストレージはありません。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `3000`でのTCP接続 | `3000` | はい | なし | `lagoon.autogeneratedroute` |
+| `3000`でTCP接続 | `3000` | はい | なし | `lagoon.autogeneratedroute` |
## `node-persistent`
-`node`と同様。永続的なストレージを生成し、`lagoon.persistent`を介してマウント場所を定義します。
+`node`と同様。永続的なストレージを生成し、`lagoon.persistent`でマウントの位置を定義します。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `3000`でのTCP接続 | `3000` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
+| `3000`でTCP接続 | `3000` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` |
## `none`
@@ -168,7 +167,7 @@ OpenSearchコンテナ、`/usr/share/opensearch/data`以下に永続的なスト
## `postgres`
-Lagoonが自動的に`postgres-single`と`postgres-dbaas`の間を判断するように指示するメタサービス。
+Lagoonに`postgres-single`と`postgres-dbaas`のどちらかを自動的に決定に決定させるメタサービス。
| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -176,11 +175,11 @@ Lagoonが自動的に`postgres-single`と`postgres-dbaas`の間を判断する
## `postgres-single`
-Postgresコンテナ。バックアップ用のcronジョブを作成し、それは24時間ごとに`/lagoon/postgres-backup.sh localhost`を実行します。
+Postgresコンテナ。バックアップ用のcronジョブを作成し、24時間ごとに`/lagoon/postgres-backup.sh localhost`を実行します。
| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `5432`でのTCP接続 | `5432` | いいえ | はい | `lagoon.persistent.size` |
+| `5432`でTCP接続 | `5432` | いいえ | はい | `lagoon.persistent.size` |
## `postgres-dbaas`
@@ -196,7 +195,7 @@ Pythonコンテナ。永続ストレージはありません。
| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `880でのHTTP接続 0` | `8800` | はい | いいえ | `lagoon.autogeneratedroute` |
+| `8800`でHTTP接続 | `8800` | はい | いいえ | `lagoon.autogeneratedroute` |
## `python-persistent`
@@ -204,7 +203,7 @@ Pythonコンテナ。永続ストレージはありません。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `8800`上のHTTP接続 | `8800` | はい | はい | `lagoon.autogeneratedroute` |
+| `8800`でHTTP接続 | `8800` | はい | はい | `lagoon.autogeneratedroute` |
## `redis`
@@ -212,7 +211,7 @@ Redisコンテナ。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `6379`上のTCP接続 | `6379` | いいえ | いいえ | - |
+| `6379`でTCP接続 | `6379` | いいえ | いいえ | - |
## `redis-persistent`
@@ -220,7 +219,7 @@ Redisコンテナ。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `6379`上のTCP接続 | `6379` | いいえ | はい | `lagoon.persistent.size` |
+| `6379`でTCP接続 | `6379` | いいえ | はい | `lagoon.persistent.size` |
## `solr`
@@ -228,11 +227,11 @@ Redisコンテナ。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
-| `8983`上のTCP接続 | `8983` | いいえ | はい | `lagoon.persistent.size` |
+| `8983`でTCP接続 | `8983` | いいえ | はい | `lagoon.persistent.size` |
## `varnish`
-バーニッシュコンテナー。
+Varnishコンテナ。
| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -240,7 +239,7 @@ Redisコンテナ。
## `varnish-persistent`
-`/var/cache/varnish` 下にマウントされた自動生成される永続的なストレージを持つバーニッシュコンテナー。
+`/var/cache/varnish` 下にマウントされた自動生成される永続的なストレージを持つVarnishコンテナ。
| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -248,7 +247,7 @@ Redisコンテナ。
## `worker`
-任意の種類のワーカーコンテナー(キューワーカーなど)で、公開サービスポートがない場合に使用します。
+任意の種類のワーカーコンテナ(キューワーカーなど)で、公開サービスポートがない場合に使用します。
| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
@@ -256,7 +255,7 @@ Redisコンテナ。
## `worker-persistent`
-`worker`と同様に、`lagoon.persistent.name`が永続的なストレージを持つサービスの名前を与えられることを期待し、定義された`lagoon.persistent`ラベルの下にマウントされます。自身の永続的なストレージを生成することはありません、ただし使用されます。 他のサービスの永続的なストレージをマウントする。
+`worker`と同じですが、`lagoon.persistent.name`が永続的なストレージを持つサービスの名前を与えられることを期待し、定義された`lagoon.persistent`ラベルの下にマウントされます。このサービスは自身の永続的なストレージを生成することなく、他のサービスの永続的なストレージをマウントするためにのみ使用されます。
| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | その他のカスタマイズパラメータ |
| :--- | :--- | :--- | :--- | :--- |
diff --git a/docs/ja/concepts-advanced/workflows.md b/docs/ja/concepts-advanced/workflows.md
index 8bad142591..38979f8f06 100644
--- a/docs/ja/concepts-advanced/workflows.md
+++ b/docs/ja/concepts-advanced/workflows.md
@@ -8,7 +8,7 @@ Lagoonは、可能な限り多様な開発ワークフローをサポートし
Lagoonがデプロイすべきブランチ(例えば `develop`、`staging`、`main`など、これらは正規表現で `^(develop|staging|main)$`となります)を定義し、それを実行します。それで完了です！
-新しい機能をテストしたい場合は、ローカルで設定したブランチにそれらをマージしてプッシュし、Lagoonがその機能をデプロイします。すべてが良ければ、そのブランチをあなたの本番ブランチにマージしてプッシュします。
+新しい機能をテストしたい場合は、ローカルで設定したブランチにそれらをマージしてプッシュし、Lagoonがその機能をデプロイします。問題がなければ、そのブランチをあなたの本番ブランチにマージしてプッシュします。
## フィーチャーブランチ { #feature-branches }
@@ -18,19 +18,19 @@ Lagoonがデプロイすべきブランチ(例えば `develop`、`staging`、`ma
* Lagoonは、`feature/myfeature`ブランチを新しい環境としてデプロイし、他の機能とは独立して機能をテストできます。
* `feature/myfeature`を`main`ブランチにマージすると、それはあなたの本番環境にデプロイされます。
-もしご希望であれば、`feature/myfeature`や他の機能ブランチを最初に`staging`にマージして、複数の機能の機能性を一緒にテストすることもできます。ステージングで機能を一緒にテストした後、機能をmainにマージできます。
+もしご希望であれば、`feature/myfeature`や他のフィーチャーブランチを最初に`staging`にマージして、複数の機能を一緒にテストすることもできます。その後、mainにマージできます。
-このワークフローは、Gitリポジトリのブランチの剪定と清潔さを高度に必要とします。各機能ブランチは自身のLagoon環境を作成するため、非常にすぐに大量の環境を生成することができ、それら全てがリソースを使用します。未使用のブランチをマージするか削除することを確認してください。
+このワークフローは、Gitリポジトリのブランチの整理とクリーンさが非常に重要です。各フィーチャーブランチは自身のLagoon環境を作成するため、非常に速く大量の環境を生成することができ、それら全てがリソースを消費します。未使用のブランチは必ずマージするか削除してください。
このため、プルリクエストベースのワークフローを考えることが理にかなっているかもしれません。
## プルリクエスト { #pull-requests }
-さらに高度なワークフローはプルリクエストを介したものです。このようなワークフローは、プルリクエスト(またはマージリクエストとも呼ばれる)をサポートするGitホスティングのサポートが必要です。プルリクエストベースのワークフローのアイデアは、その背後にあります。 あなたが特定の機能をターゲットブランチと一緒にテストできるというアイデアは、実際にはまだマージする必要はないが、Lagoonがビルド中にマージしてくれるというものです。
+さらに高度なワークフローはプルリクエストによるものです。このようなワークフローは、プルリクエスト(またはマージリクエストとも呼ばれます)をサポートするGitホスティングのサポートが必要です。プルリクエストベースのワークフローのアイデアは、ビルド中にLagoonがマージを行ってくれるので、実際にマージする必要はなく、ターゲットブランチと一緒に機能をテストできるというアイデアの背景にあります。
-私たちの例では、Lagoonを設定して、ブランチ`^(staging|main)$`とプルリクエストを`.*` \(すべてのプルリクエストをデプロイする\)にデプロイさせます。 これで、私たちのワークフローは次のようになります:
+私たちの例では、Lagoonを設定して、ブランチ`^(staging|main)$`とプルリクエストを`.*` \(すべてのプルリクエストをデプロイする\)にデプロイさせます。 これでワークフローは次のようになります:
-1. `main`から新しいブランチ`feature/myfeature`を作成し、`feature/myfeature`をプッシュします\(私たちがデプロイするブランチとして特定のステージングとメインのみを持っているため、今はデプロイは行われません\)。
+1. `main`から新しいブランチ`feature/myfeature`を作成し、`feature/myfeature`をプッシュします\(デプロイされるブランチは`staging`と`main`のみのため、今はデプロイは行われません\)。
2. あなたのGitホスティングで`feature/myfeature`から`main`へのプルリクエストを作成します。
3. Lagoonは今、`feature/myfeature`ブランチを`main`ブランチの上にマージし、その結果のコードをデプロイします。
4. これで、`feature/myfeature`ブランチの機能をテストできます。まるで`main`にマージされたかのように、`feature/myfeature`ブランチを作成してから`main`で起こったすべての変更がそこにありますので、`main`ブランチの古いバージョンを持っているかもしれないと心配する必要はありません。
@@ -40,13 +40,13 @@ Lagoonがデプロイすべきブランチ(例えば `develop`、`staging`、`ma
一部のチームでは、共有の`staging`ブランチに対してプルリクエストを作成し、その後、別のプルリクエストを介して`staging`ブランチを`main`ブランチにマージすることを選択するかもしれません。これは、使用しているGitのワークフローの種類によります。
-また、Lagoonでは、タイトルに特定のテキストがあるプルリクエストのみをデプロイするように設定することができます。正規表現として定義された`[BUILD]`は、タイトルが`[BUILD] My Pull Request`のようなプルリクエストのみをデプロイし、タイトルが`My other Pull Request`のプルリクエストは自動的にデプロイされません。これにより、環境の数を少なく保つことができ、また、まだ環境が必要でないプルリクエストを許可することができます。
+また、Lagoonでは、タイトルに特定のテキストがあるプルリクエストのみをデプロイするように設定することができます。正規表現として定義された`[BUILD]`は、タイトルが`[BUILD] My Pull Request`のようなプルリクエストのみをデプロイし、タイトルが`My other Pull Request`のようなプルリクエストは自動的にデプロイされません。これにより、環境の数を少なく保つことができ、まだ環境が必要でないプルリクエストを保持すること可能にします。
### プルリクエストの自動データベース同期 { #automatic-database-sync-for-pull-requests }
自動的なプルリクエストの環境は素晴らしいことです。しかし、それらの環境が作成されたときに別の環境からデータベースが同期されると便利だろうとも思います。Lagoonはそれを扱うことができます！
-これは 次の例は、プルリクエスト環境の最初のロールアウトでステージングデータベースを同期します:
+次の例は、プルリクエスト環境の最初のロールアウトでステージングデータベースを同期します:
```yaml title=".lagoon.yml"
tasks:
@@ -65,11 +65,11 @@ tasks:
環境にコードをデプロイする別の方法は、**プロモーション**ワークフローです。
-プロモーションワークフローの背後にある考え方は次のようなものです(例として):
+プロモーションワークフローの考え方は、例としてここから来ています。
-`staging`ブランチを`main`ブランチにマージし、`main`に変更がなければ、つまり`main`と`staging`がGitでまったく同じコードを持っている場合でも、結果として得られるDockerイメージがわずかに異なる可能性があります。これは、最後の`staging`デプロイメントと現在の`main`デプロイメントの間に、いくつかの上流Dockerイメージが変更されたか、またはさまざまなパッケージマネージャーからロードされた依存関係が変更された可能性があるためです。これは非常に小さい確率ですが、存在します。
+`staging`ブランチを`main`ブランチにマージし、`main`に変更がなければ、つまり`main`と`staging`がGitでまったく同じコードを持っている場合でも、結果として得られるDockerイメージがわずかに異なる可能性があります。これは、最後の`staging`デプロイメントと現在の`main`デプロイメントの間に、いくつかの上流Dockerイメージが変更されたか、またはさまざまなパッケージマネージャーによってロードされた依存関係が変更された可能性があるためです。これは非常に小さい確率ですが存在します。
-そのため、 この状況では、Lagoonは一つの環境から別の環境へのLagoonイメージのプロモーションという概念を理解しています。これは基本的に、すでに構築されデプロイされたDockerイメージを一つの環境から取り出し、それらのまったく同じDockerイメージを別の環境で使用するということを意味します。
+そのため、 この状況ではLagoonは一つの環境から別の環境へのLagoonイメージのプロモーションという概念を理解しています。これは基本的に、すでに構築されデプロイされたDockerイメージを一つの環境から取り出し、それらのまったく同じDockerイメージを別の環境で使用するということを意味します。
私たちの例では、`main`環境から`production`環境へDockerイメージをプロモートしたいと思っています:
@@ -85,8 +85,8 @@ lagoon deploy promote --project="myproject" --source="main" --destination="produ
Lagoonは次のことを行います:
-* `.lagoon.yml`と`docker-compose.yml`ファイルをロードするために、Gitブランチ`main`をチェックアウトします(Lagoonはこれらがまだ必要です 完全に動作するために)。
-* `docker-compose.yml`で定義されたサービスのすべてのKubernetes/OpenShiftオブジェクトを作成しますが、環境変数として`LAGOON_GIT_BRANCH=production`を使用します。
+* `.lagoon.yml`と`docker-compose.yml`ファイルをロードするために、Gitブランチ`main`をチェックアウトします(Lagoonが 完全に動作するにはこれらがまだ必要です)。
+* `docker-compose.yml`で定義されたサービスに対して、すべてのKubernetes/OpenShiftオブジェクトを作成しますが、環境変数として`LAGOON_GIT_BRANCH=production`を使用します。
* `main`環境から最新のイメージをコピーし、それらを使用します(イメージをビルドしたり、上流からタグ付けしたりする代わりに)。
* 通常のデプロイメントのように、すべてのポストロールアウトタスクを実行します。
diff --git a/docs/ja/using-lagoon-advanced/active-standby.md b/docs/ja/using-lagoon-advanced/active-standby.md
index 1951229e70..f8a366b76f 100644
--- a/docs/ja/using-lagoon-advanced/active-standby.md
+++ b/docs/ja/using-lagoon-advanced/active-standby.md
@@ -1,10 +1,10 @@
-# アクティブ/スタンバイ
+# Active/Standby
## 設定
-既存のプロジェクトをアクティブ/スタンバイに対応させるためには、Lagoon APIを使用してプロジェクト設定をいくつか設定する必要があります。
+既存のプロジェクトをActive/Standbyに対応させるためには、Lagoon APIを使用してプロジェクト設定をいくつか設定する必要があります。
* `productionEnviromment`は、現在アクティブな環境のブランチ名に設定する必要があります。
* `standbyProductionEnvironment`は、現在スタンバイ中の環境のブランチ名に設定する必要があります。
@@ -27,17 +27,17 @@ mutation updateProject {
### `.lagoon.yml` - `production_routes`
-`.lagoon.yml`ファイルでプロジェクトをアクティブ/スタンバイに設定するためには、`active`環境にアタッチしたいルートと`standby`にアタッチしたいルートを`production_routes`セクションに設定する必要があります。 環境。アクティブ/スタンバイの切り替え時には、これらのルートは2つの環境間で移動します。
+`.lagoon.yml`ファイルでプロジェクトをActive/Standbyに設定するためには、`active`環境にアタッチしたいルートと`standby`環境にアタッチしたいルートを`production_routes`セクションに設定する必要があります。Active/Standbyの切り替え時には、これらのルートは2つの環境間で移行します。
-もし2つのプロダクション環境、`production-brancha`と`production-branchb`があり、現在アクティブなプロダクション環境が`production-brancha`であるなら:
+`production-brancha`と`production-branchb`の2つの`production`環境があり、現在アクティブな`production`環境が`production-brancha`である場合：
-* `production_routes.active`の下のルートはあなたを`production-brancha`に向かわせます。
-* `production_routes.standby`の下のルートはあなたを`production-branchb`に向かわせます。
+* `production_routes.active`配下のルートは`production-brancha`に向かわせます。
+* `production_routes.standby`配下のルート`production-branchb`に向かわせます。
-アクティブ/スタンバイの切り替え時には、ルートが交換されます:
+Active/Standbyの切り替え時には、ルートが入れ替わります:
-* `production_routes.active`の下のルートはあなたを`production-branchb`に向かわせます。
-* `production_routes.standby`の下のルートはあなたを`production-brancha`に向かわせます。
+* `production_routes.active`配下のルートは`production-branchb`に向かわせます。
+* `production_routes.standby`配下のルートは`production-brancha`に向かわせます。
```yaml title=".lagoon.yml"
production_routes:
@@ -56,19 +56,19 @@ production_routes:
```
!!! Info "情報"
- セクション`environments..routes`の下にあるルートは、アクティブ/スタンバイの一部として移動されません。これらのルートは常に定義された環境に付属しています。特定のルートを必要とする場合は、そのルートが アクティブ/スタンバイ切り替え中に移行した場合、それらを環境セクションから削除し、それがアクティブルートかスタンバイルートであるべきか特定の `production_routes` セクションに配置してください。[ `.lagoon.yml` のルートについて詳しくはこちらを参照してください。](../concepts-basics/lagoon-yml.md#routes)
+ `environments..routes`セクション配下にあるルートは、Active/Standbyの一部として移動されません。これらのルートは常に定義された環境にアタッチされます。Active/Standbyの切り替え中に特定のルートを移行する必用がある場合、それらを環境セクションから削除し、Activeまたは、Standbyルート固有の`production_routes` セクションに配置してください。 [ `.lagoon.yml` のルートについて詳しくはこちらを参照してください。](../concepts-basics/lagoon-yml.md#routes)
## 切り替えイベントのトリガー
### UI経由
-環境ルートの切り替えをトリガーするには、Lagoon UIでスタンバイ環境を訪れ、`Switch Active/Standby environments`というラベルのボタンをクリックします。アクションを確認するように求められます。
+環境ルートの切り替えをトリガーするには、Lagoon UIで`Standby`環境を訪れ、`Switch Active/Standby environments`というラベルのボタンをクリックします。アクションを確認するように求められます。
-確認されると、スイッチの進行状況を確認することができるタスクページに移動します。
+確認すると、タスクページに移動し、切り替えの進捗状況を確認することができます。
### API経由
-環境を切り替えるイベントをトリガーするには、次のGraphQL変異を実行します。これにより、Lagoonがプロセスを開始します。
+環境を切り替えるイベントをトリガーするには、次のGraphQL mutationを実行します。これにより、Lagoonがプロセスを開始します。
```graphql title="アクティブスタンバイスイッチ"
mutation ActiveStandby {
@@ -85,9 +85,9 @@ mutation ActiveStandby {
}
```
-切り替えイベントがトリガーされると、現在のアクティブ環境の `tasks` タブにタスクが作成されます。ここでスイッチの状態を確認することができます。
+切り替えイベントがトリガーされると、現在のアクティブ環境の `tasks` タブにタスクが作成されます。ここで切り替えの状態を確認することができます。
-`switchActiveStandby` 変異からの `remoteId` を使用して、 タスクのステータスも確認することができます。
+`remoteId` を使用して、`switchActiveStandby` mutationからタスクのステータスを確認することもできます。
```graphql title="タスクステータスの確認"
query getTask {
@@ -105,14 +105,14 @@ query getTask {
## `drush`エイリアス
-デフォルトでは、プロジェクトは以下のエイリアスが作成され、プロジェクトでアクティブ/スタンバイが有効になっている場合に利用できます。
+デフォルトでプロジェクトは以下のエイリアスが作成され、Active/Standbyが有効になっている場合に利用できます。
* `lagoon-production`
* `lagoon-standby`
`lagoon-production`エイリアスは`productionEnvironment`として定義されているサイトを指し、`lagoon-standby`は常に`standbyProductionEnvironment`として定義されているサイトを指します。
-これらのエイリアスは、プロジェクトの更新によって設定を変更することができます。ただし、それらを変更すると、それらに依存するスクリプトを更新する必要があるかもしれません。
+これらのエイリアスは、プロジェクトの更新によって設定を変更することができます。ただし、それらを変更すると、それらに依存するスクリプトを更新する必要があることに注意してください。
```graphql title="Drushエイリアスの更新"
mutation updateProject {
@@ -132,13 +132,13 @@ mutation updateProject {
## Active/Standbyの無効化
-これら2つのブランチのうち、どちらを主な環境として進めていくかを決定する必要があります。その後、 それがアクティブなブランチとして設定されていることを確認してください(例:`production-branchb`)。
+これら2つのブランチのうち、どちらを主な環境として進めていくかを決定する必要があります。その後、 それがアクティブなブランチとして設定されていることを確認してください。(例:`production-branchb`)
-1. この(現在アクティブな)ブランチの`.lagoon.yml`ファイルで、`production_routes.active.routes`セクションからルートを`environments.production-branchb`セクションに移動します。これは、そのルートが`production-branchb environment`にのみ関連付けられることを意味します。
+1. この現在アクティブなブランチの`.lagoon.yml`ファイルで、`production_routes.active.routes`セクションからルートを`environments.production-branchb`セクションに移動します。これは、そのルートが`production-branchb environment`にのみ関連付けられることを意味します。
2. これが完了したら、`.lagoon.yml`ファイルから完全にproduction_routesセクションを削除し、production-branchb環境を再デプロイできます。
-3. もう他のブランチ`production-brancha`が必要ない場合、それを削除できます。
-4. Gitでブランチを保持する場合、混乱を避けるためにそのブランチの`.lagoon.yml`からも`production_routes`を削除するべきです。ブランチは`production`タイプのままになりますが、それを削除して再デプロイしない限り(すべてのストレージとデータベースなどを消去)。
-5. プロジェクトが`production-branchb`プロダクション環境だけが存在し、他のすべての環境が`development`である状態になったら、プロジェクトから`standbyProductionEnvironment`を削除して、環境のアクティブ/スタンバイラベルを消去します。
+3. もう1つのブランチである`production-brancha`が必要ない場合は削除してもかまいません。
+4. Gitにブランチを保持する場合、混乱を避けるためにそのブランチの`.lagoon.yml`からも`production_routes`を削除しておきましょう。このブランチは削除して再デプロイ(すべてのストレージとデータベースなどを消去)するまで`production`タイプとして残ります。
+5. プロジェクトが`production-branchb`の`production`環境のみで、他のすべての環境が`development`環境である状態になったら、プロジェクトを更新して`standbyProductionEnvironment`を削除し、環境のActive/Standbyラベルを消去します。
```graphql title="アクティブ/スタンバイをオフにする"
mutation updateProject {
@@ -158,7 +158,7 @@ mutation updateProject {
## ノート
-アクティブ/スタンバイトリガーが実行されたとき、`productionEnvironment`と`standbyProductionEnvironments`はLagoon API内で切り替わります。両方の環境はまだ`production`環境タイプとして分類されています。`productionEnvironment`はどちらが`active`とラベル付けされているかを決定するために使用します。環境タイプの違いについての詳細は、[`environment types`のドキュメンテーション](../concepts-advanced/environment-types.md)をご覧ください。
+Active/Standbyトリガーが実行されたとき、`productionEnvironment`と`standbyProductionEnvironments`はLagoon API内で切り替わります。両方の環境はまだ`production`環境タイプとして分類されています。`productionEnvironment`はどちらが`active`とラベル付けされているかを決定するために使用します。環境タイプの違いについての詳細は、[`environment types`のドキュメント](../concepts-advanced/environment-types.md)をご覧ください。
```graphql title="GraphQLを使って環境を取得する"
query projectByName {
@@ -169,7 +169,7 @@ query projectByName {
}
```
-環境を切り替える前:
+環境を切り替える前
```graphql title="環境クエリの結果"
{
@@ -182,9 +182,9 @@ query projectByName {
}
```
-環境を切り替えた後:
+環境を切り替えた後
-```graphql title="結果 の環境クエリ"
+```graphql title="環境クエリの結果"
{
"data": {
"projectByName": {
diff --git a/docs/ja/using-lagoon-advanced/blackfire.md b/docs/ja/using-lagoon-advanced/blackfire.md
index 775f087378..9bce262061 100644
--- a/docs/ja/using-lagoon-advanced/blackfire.md
+++ b/docs/ja/using-lagoon-advanced/blackfire.md
@@ -2,9 +2,9 @@
## Blackfireの変数
-Lagoon Base Imagesには、PHP ImagesにBlackfireのサポートが組み込まれています([PHP images](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/entrypoints/80-php-blackfire.sh)を参照)。
+Lagoon Base Imagesには、PHP ImagesにBlackfireのサポートが組み込まれています。([PHP images](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/entrypoints/80-php-blackfire.sh)を参照)
-LagoonでBlackfireを使用するためには、以下の3つの環境変数を定義する必要があります:
+LagoonでBlackfireを使用するためには、以下の3つの環境変数を定義する必要があります。
| 環境変数 | デフォルト | 説明 |
| :--- | :--- | :--- |
@@ -14,7 +14,7 @@ LagoonでBlackfireを使用するためには、以下の3つの環境変数を
## Blackfireのローカル使用
-Lagoon ImagesでBlackfireをローカルで使用する場合、上記の環境変数をPHPコンテナに設定します。以下はDrupalアプリケーションの例です:
+Lagoon ImagesでBlackfireをローカルで使用する場合、上記の環境変数をPHPコンテナに設定します。以下はDrupalアプリケーションの例です。
```yaml title="docker-compose.yml"
@@ -26,7 +26,7 @@ services:
[[snip]]
environment:
- << : *default-environment # 上部で定義された環境変数を読み込む
+ << : *default-environment # 定義された環境変数を上から読み込む
BLACKFIRE_ENABLED: TRUE
``` BLACKFIRE_SERVER_ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
BLACKFIRE_SERVER_TOKEN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
@@ -36,10 +36,13 @@ services:
## Blackfireのリモート使用
-デプロイされたLagoon環境でBlackfireを使用するためには、同じ環境変数を設定する必要があります。この時、[Lagoonに環境変数を追加する](../concepts-advanced/environment-variables.md)方法の一つを通じて設定します。重要:ローカル開発用に`docker-compose.yml`に設定された環境変数はLagoonのリモート環境では使用されません！
+デプロイされたLagoon環境でBlackfireを使用するためには、同じ環境変数を設定する必要があります。この時、[Lagoonに環境変数を追加する](../concepts-advanced/environment-variables.md)方法で設定します。
+
+!!! warn "重要"
+ ローカル開発用に`docker-compose.yml`に設定された環境変数はLagoonのリモート環境では使用されません！
## デバッグ
-PHPコンテナで動作しているBlackfireエージェントは、通常のコンテナログとしてログを出力します。これは`docker-compose logs`またはリモート環境のLagoon Logging Infrastructureを通じて見ることができます。
+PHPコンテナで動作しているBlackfireエージェントは、通常のコンテナログとしてログを出力します。これは`docker-compose logs`またはリモート環境の`Lagoon Logging Infrastructure`を通じて見ることができます。
-デフォルトでは、ログはレベル`3`(情報)に設定されていますが、環境変数`BLACKFIRE_LOG_LEVEL`を使ってレベルを`4`(デバッグ)に上げることで、より多くの情報を生成することができます。 デバッグ出力。
+デフォルトでは、ログはレベル`3`(情報)に設定されていますが、環境変数`BLACKFIRE_LOG_LEVEL`を使ってレベルを`4`(デバッグ)に上げることで、より多くの情報を生成することができます。
diff --git a/docs/ja/using-lagoon-advanced/custom-tasks.md b/docs/ja/using-lagoon-advanced/custom-tasks.md
index ace07d0554..efe1d2cde4 100644
--- a/docs/ja/using-lagoon-advanced/custom-tasks.md
+++ b/docs/ja/using-lagoon-advanced/custom-tasks.md
@@ -8,27 +8,27 @@ Lagoonでは、環境、プロジェクト、グループレベルでカスタ
### どのタスクを実行しますか？
-ほとんどの場合、実行するカスタムタスクは、アプリケーションのコンテナの一つでシェルで実行されるものです。
+ほとんどの場合、実行するカスタムタスクは、アプリケーションのコンテナの一つでシェルから実行されるものです。
-例えば、Node.jsアプリケーションでは、`node`コンテナで`yarn audit`を実行することに興味があるかもしれません。この場合、コマンドは単純に`yarn audit`となります。
+例えば、Node.jsアプリケーションでは、`node`コンテナで`yarn audit`を実行することに興味があるかもしれません。この場合コマンドは単純に`yarn audit`となります。
### このタスクはどこで実行されますか？
-このタスクがどこで実行されるかを定義する必要があります -- これは二つのことを意味します。まず、どのプロジェクトまたは環境でタスクを実行するか、そして、どのサービスで行うかです。
+このタスクがどこで実行されるかを定義する必要があります。これは二つのことを意味します。まず、どのプロジェクトまたは環境でタスクを実行するか、そしてどのサービスで行うかです。
-たとえば、`yarn audit`タスクを特定のプロジェクト(この例ではプロジェクトのIDを42としましょう)の任意の環境で実行可能にしたいと考えているとしましょう。そのため、タスク定義を作成する際には、下記で説明するように、プロジェクトのIDを指定します。
+たとえば、`yarn audit`タスクを特定のプロジェクト(この例ではプロジェクトのIDを42としましょう)の任意の環境で実行可能にしたいと考えているとしましょう。タスク定義を作成する際には、下記で説明するように、プロジェクトのIDを指定します。
-2つ目の質問は、どの環境をタスクの対象とするかということです。あなたが設定するときに あなたのプロジェクトを設定する際に、[`docker-compose.yml`](../concepts-basics/docker-compose-yml.md)でいくつかのサービスを指定します。このサービス名を使用して、コマンドが実際にどこで実行されるかを決定します。
+2つ目の質問は、どの環境をタスクの対象とするかということです。プロジェクトを設定する際に[`docker-compose.yml`](../concepts-basics/docker-compose-yml.md)でいくつかのサービスを指定します。このサービス名を使用してコマンドが実際にどこで実行されるかを決定します。
### このタスクを実行できるのは誰ですか？
-タスクシステムへのアクセス権はプロジェクトロールに対応した3つのレベルがあります。ゲスト、デベロッパー、メンテナー -- 最も制限的なものから最も制限の少ないものまで、各ロールはそれより下のロールで定義されたタスクを呼び出すことができます(デベロッパーはゲストのタスクを見ることができ、メンテナーはすべてのタスクを見ることができます)。
+タスクシステムへのアクセス権はプロジェクトロールに対応した3つのレベルがあります。ゲスト、デベロッパー、メンテナーです。最も制限的なものから最も制限の少ないものまで、各ロールはそれより下のロールで定義されたタスクを呼び出すことができます(デベロッパーはゲストのタスクを見ることができ、メンテナーはすべてのタスクを見ることができます)。
## タスクの定義
-タスクは`addAdvancedTaskDefinition`ミューテーションを呼び出すことで定義されます。重要なことは、これは単にタスクを_定義するだけで、それを呼び出すわけではありません。それは単にそれを環境で実行可能にするだけです。
+タスクは`addAdvancedTaskDefinition`ミューテーションを呼び出すことで定義されます。重要なことは、これは単にタスクを定義するだけで呼び出すわけではありません。単にそれを環境で実行可能にするだけです。
-概念的には、呼び出しは次のようになります。
+概念的には呼び出しは次のようになります。
```graphql title="新しいタスクを定義する"
mutation addAdvancedTask {
@@ -81,17 +81,17 @@ mutation addAdvancedTask {
}
```
-フィールド`name`と`description`は直訳です。これらは主にUIで使用されるタスクの名前と説明です。
+フィールド`name`と`description`は簡単です。これらは主にUIで使用されるタスクの名前と説明です。
-`type`フィールドについては説明が必要です - 現時点では、プラットフォーム管理者のみが`IMAGE`タイプのコマンドを定義できます - これは、既存のサービスを対象にするのではなく、特定のタスクイメージをタスクとして実行することを可能にします。しかし、ほとんどのタスクは`COMMAND`タイプになります。
+`type`フィールドについては説明が必要です。現時点では、プラットフォームの管理者のみが`IMAGE`タイプのコマンドを定義できます。これは、既存のサービスを対象にするのではなく、特定のタスクイメージをタスクとして実行することを可能にします。しかし、ほとんどのタスクは`COMMAND`タイプです。
-`[project|environment]`フィールドのセットは、タスクを`project`または`environment`に関連付ける(使用するキーによります)ことで、その値が id. 私たちが`yarn audit`のために考えているケースでは、IDが`42`の`project`を対象としていることを明示します。
+`[project|environment]`フィールドのセットは、タスクを`project`または`environment`に関連付ける(使用するキーによります)ことで、その値がidになります。 私たちが`yarn audit`のために考えているケースでは、IDが`42`の`project`を対象としていることを明示します。
私たちがタスクでターゲットにしたいサービスを`service`フィールドに置き、`command`は私たちが実行したい実際のコマンドです。
### タスクに渡される引数
-Lagoon UI経由でタスクを呼び出すユーザーにより柔軟性を提供するために、タスク引数の定義をサポートしています。これらの引数はテキストボックスまたはドロップダウンとして表示され、タスクを呼び出すために必要です。
+Lagoon UI経由でタスクを呼び出すユーザーに柔軟性を与えるために、タスク引数の定義をサポートしています。これらの引数はテキストボックスまたはドロップダウンとして表示され、タスクを呼び出すために必要です。
以下は、2つの引数を設定する方法の例です。
@@ -99,13 +99,13 @@ Lagoon UI経由でタスクを呼び出すユーザーにより柔軟性を提
advancedTaskDefinitionArguments: [
{
name: "ENV_VAR_NAME_SOURCE",
- displayName: "環境源",
+ displayName: "Environment source",
type: ENVIRONMENT_SOURCE_NAME
},
{
name: "ENV_VAR_NAME_STRING",
- displayName: "エコー値",
+ displayName: "Echo value",
type: STRING
}
]
@@ -113,7 +113,7 @@ advancedTaskDefinitionArguments: [
```
このフラグメントは、システムが現在サポートしている両方のタイプの引数を示しています。
-最初の`ENV_VAR_NAME_SOURCE`は`ENVIRONMENT_SOURCE_NAME`タイプの例で、これはUIのユーザーにプロジェクト内の異なる環境のドロップダウンを提示します。もし私たちが許可したくない場合は、 呼び出し環境で実行するタスク(例えば、他の環境からデータベースをインポートしたい場合など)については、`ENVIRONMENT_SOURCE_NAME_EXCLUDE_SELF`を使用して環境リストを制限することができます。
+最初の`ENV_VAR_NAME_SOURCE`は`ENVIRONMENT_SOURCE_NAME`タイプの例で、UIのユーザーにプロジェクト内の異なる環境のドロップダウンを提示します。タスクが起動した環境で実行されるのを許可したくない場合(例えば、他の環境からデータベースをインポートしたい場合など)は`ENVIRONMENT_SOURCE_NAME_EXCLUDE_SELF`を使用して環境リストを制限することができます。
二つ目の`ENV_VAR_NAME_STRING`は`STRING`型で、ユーザーにテキストボックスを記入するように促します。
ユーザーが選択した値は、タスクが実行されたときに`COMMAND`型のタスクで環境変数として利用可能になります。
@@ -123,24 +123,24 @@ advancedTaskDefinitionArguments: [
### システム全体のタスク
-プラットフォームの管理者は、システム全体のタスクを登録することができます。これらのタスクはすべての環境で表示され、ユーザーがそれらを呼び出す権限によって制限されます。
+システム全体のタスクを登録できるのはLagoonの管理者のみです。これらのタスクはすべての環境で表示され、ユーザーが持つ権限によって制限されます。
システム全体のタスクを作成する方法は、他のタスクタイプとほぼ同じですが、2つの例外があります。
まず、`addAdvancedTaskDefinition`ミューテーションの中で`systemWide: true`フィールドを設定します。
-次に、`groupName`、`project`、または`environment`を指定してい*ない*ことを確認します - これらのフィールドは特定のコンテキストをターゲットにするために使用されるため、これらを指定すると目的を逸脱することになります。
+次に、`groupName`、`project`、`environment`を指定していないことを確認します。これらのフィールドは特定のコンテキストをターゲットにするために使用されるため、指定すると目的を逸脱することになります。
### 確認
-`confirmationText`フィールドにテキストがあると、ユーザーがタスクを実行できるようになる前に、UIに確認モーダルとともに表示されます。 
+`confirmationText`フィールドにテキストがあると、ユーザーがタスクを実行できるようになる前に、UIに確認モーダルが表示されます。 
## タスクの呼び出し
タスクが定義されていると、タスクはLagoon UIのタスクドロップダウンに表示されるはずです。
-また、`invokeTask` ミューテーションを使用してGraphQL apiからも呼び出すことができます。
+また、`invokeTask` ミューテーションを使用してGraphQL apiからも呼び出すこともできます。
```graphql title="タスクの呼び出し"
mutation invokeTask {
@@ -150,7 +150,7 @@ mutation invokeTask {
}
```
-`invokeTask`は常に_特定の環境_でタスクを呼び出すことに注意してください。
+`invokeTask`は常に特定の環境でタスクを呼び出すことに注意してください。
## 例
@@ -172,8 +172,8 @@ mutation runYarnAudit {
}
```
-これにより、私たちのプロジェクト(42)のタスクが定義されます。これを実行すると、タスク定義のIDが返されます(たとえば、`9`とします)
+これにより、私たちのプロジェクト(42)のタスクが定義されます。これを実行すると、タスク定義のIDが返されます(例えば、`9`とします)
-このタスクは、`DEVELOPER`または`MAINTAINER`の役割を持つ誰でもUIから実行できるようになります。
+このタスクは、`DEVELOPER`または`MAINTAINER`の役割を持つユーザーがUIから実行できるようになります。
diff --git a/docs/ja/using-lagoon-advanced/deploytarget-configs.md b/docs/ja/using-lagoon-advanced/deploytarget-configs.md
index 496be96e34..d63c2f9445 100644
--- a/docs/ja/using-lagoon-advanced/deploytarget-configs.md
+++ b/docs/ja/using-lagoon-advanced/deploytarget-configs.md
@@ -10,37 +10,38 @@ DeployTarget設定の基本的な考え方は、プロジェクトが複数の
DeployTarget設定を利用してプロジェクトを設定する方法について説明する前に、知っておくべきことがいくつかあります。
-1. 環境には、それらがどのDeployTarget(KubernetesまたはOpenShift)で作成されたかを識別するための新たな2つのフィールドが利用可能になりました。
+1. 環境にはどのDeployTarget(KubernetesまたはOpenShift)で作成されたかを識別するための新たな2つのフィールドが利用可能になりました。
1. `kubernetesNamespacePattern`
2. `kubernetes`
-2. 特定のDeployTargetに一度デプロイされた環境は、DeployTarget設定やプロジェクト設定が変更されても、常にこのターゲットにデプロイされます。 3. これは、DeployTargetの設定を変更して異なるクラスターで新しい環境を作成するのを防ぐことで、既存の環境に一定の安全性を提供します。
- 4. これはLagoonの一部であり、特にDeployTarget設定に限定された新機能です。
+2. 特定のDeployTargetに一度デプロイされた環境は、DeployTarget設定やプロジェクト設定が変更されても、常にこのターゲットにデプロイされます。
+ 1. これによりDeployTargetの設定を変更しても、異なるクラスタで新しい環境が作成されることがなくなり、既存の環境に対して一定の安全性を提供できます。
+ 2. これはLagoonの新機能であり、DeployTarget設定に特化されたものではありません。
-2. デフォルトでは、プロジェクトにDeployTargetの設定が関連付けられていない場合、そのプロジェクトは既存の方法を続けて使用してどの環境をデプロイするかを決定します。これには以下のフィールドが使用されます。
+3. デフォルトでは、プロジェクトにDeployTargetの設定が関連付けられていない場合、そのプロジェクトは既存の方法を使用してどの環境にデプロイするかを決定します。これには以下のフィールドを使用されます。
1. `branches`
2. `pullrequests`
3. `kubernetesNamespacePattern`
4. `kubernetes`
-3. プロジェクトにいかなるDeployTargetの設定が追加されると、そのプロジェクトのすべての将来のデプロイメントはこれらの設定を使用します。プロジェクトで定義されているものは無視され、DeployTargetの設定が使用されていることをユーザーに通知するために上書きされます。
-4. DeployTargetの設定は重み付けされており、これは大きい重みのDeployTarget設定が小さい重みのものより優先されることを意味します。
+4. DeployTargetの設定がプロジェクトに追加されると、今後すべてのデプロイはこれらの設定を使用します。プロジェクトで定義されているものは無視され、DeployTargetの設定が使用されていることをユーザーに通知するために上書きされます。
+5. DeployTargetの設定は重み付けされており、これは大きい重みのDeployTarget設定が小さい重みのものより優先されることを意味します。
- 1. クエリで返される順序が、環境がデプロイされるべき場所を決定するために使用される順序です。
+ 1. クエリで返される順序が、環境がデプロイされるべき場所を決定するために使用される順序です。
-5. アクティブ/スタンバイ環境は、同じ クラスターなので、DeployTarget設定はそれらの環境を同じターゲットにデプロイできるように設定する必要があります。
-6. Lagoonの`promote`機能を活用するプロジェクトは、DeployTarget設定が`destination`環境では無視されることを認識していなければなりません。
+6. Active/Standby環境は、同じクラスタなので、DeployTarget設定はそれらの環境を同じターゲットにデプロイできるように設定する必要があります。
+7. Lagoonの`promote`機能を活用するプロジェクトは、DeployTarget設定が`destination`環境では無視されることに注意する必要があります。
- 1. 宛先環境は常に`source`環境がある同じターゲットにデプロイされますので、DeployTarget設定はこの`source`環境に対して正しく設定する必要があります。
- 2. 安全のため、`source`と`destination`の環境を同じDeployTarget設定のブランチ正規表現で定義するのが最善です。
+ 1. ディスティネーション環境は常に`source`環境がある同じターゲットにデプロイされますので、DeployTarget設定はこの`source`環境に対して正しく設定する必要があります。
+ 2. 安全のため、`source`と`destination`の環境を同じDeployTarget設定のブランチ正規表現で定義するのがベストです。
## 設定
-プロジェクトをDeployTarget設定を使用するように設定するためには、まずプロジェクトに設定を追加することが第一歩です。
+プロジェクトでDeployTarget設定を使用するよう構成するには、最初のステップとしてプロジェクトに設定を追加します。
-以下のGraphQLの突然変異を使用できます。この特定の例では、プロジェクトID 1のプロジェクトにDeployTarget設定を追加します。
+以下のGraphQLのミューテーションを使用できます。この特定の例では、プロジェクトID 1のプロジェクトにDeployTarget設定を追加します。
これにより、名前が`main`と一致するブランチのみがデプロイされ、`pullrequests`は`false`に設定されます。
これは、他のブランチがこの特定のターゲットにデプロイすることができず、プルリクエストもこの特定のターゲットにデプロイされないことを意味します。
`deployTarget`はID 1で、これはKubernetesになる可能性があります。 特定の地域や特定の種類のワークロード(製品版または開発版)向けにクラスターを指定します。
@@ -75,11 +76,11 @@ mutation addDeployTargetConfig{
また、複数のDeployTarget設定を構成することも可能です。
-以下のGraphQL変異を使用できます。この特定の例では、上記と同じプロジェクトにDeployTarget設定を追加します。
+以下のGraphQLミューテーションを使用できます。この例では、上記と同じプロジェクトにDeployTarget設定を追加します。
-これにより、`^feature/|^(dev|test|develop)$` と正規表現マッチするブランチのみがデプロイされ、`pullrequests` は `true` に設定されているため、すべてのプルリクエストがこのターゲットに到達します。
+これにより、`^feature/|^(dev|test|develop)$` と正規表現がマッチするブランチのみがデプロイされます。そして、`pullrequests` は `true` に設定されているのですべてのプルリクエストがこのターゲットに到達します。
-この例では、ターゲットとなるクラスタはID 2で、これは`main`ブランチに上で定義されたものとは全く異なるKubernetesクラスタです。
+この例では、ターゲットとなるクラスタはID2で、`main`ブランチ上で定義されたものとは全く異なるKubernetesクラスタです。
```GraphQL title="DeployTargetの設定"
mutation addDeployTargetConfig{
diff --git a/docs/ja/using-lagoon-advanced/index.md b/docs/ja/using-lagoon-advanced/index.md
index f85fecee84..fe3c1c9bfd 100644
--- a/docs/ja/using-lagoon-advanced/index.md
+++ b/docs/ja/using-lagoon-advanced/index.md
@@ -1,5 +1,5 @@
-# Lagoonの高度な利用方法
+# Lagoonの高度な使い方
-このセクションでは、Lagoonのより高度な機能と機能について説明します。Lagoonが初めての方は、まず[Lagoonの基本的な使用方法](../using-lagoon-the-basics/index.md)から始めてください。
+このセクションでは、Lagoonのより高度な機能や特徴について説明します。Lagoonが初めての方は、まず[Lagoonの基本的な使い方](../using-lagoon-the-basics/index.md)から始めてください。
-助けが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティやメンテナーに問い合わせてください。
+サポートが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティのメンバーやメンテナーに問い合わせてください。
diff --git a/docs/ja/using-lagoon-advanced/nodejs.md b/docs/ja/using-lagoon-advanced/nodejs.md
index 13ff4cfb9f..812720ccd4 100644
--- a/docs/ja/using-lagoon-advanced/nodejs.md
+++ b/docs/ja/using-lagoon-advanced/nodejs.md
@@ -1,10 +1,10 @@
# Node.jsのグレースフルシャットダウン
-Node.jsには統合されたウェブサーバーの機能があります。さらに[Express](https://expressjs.com/)を使用すると、これらの機能をさらに拡張することができます。
+Node.jsには統合されたWebサーバーの機能があります。さらに[Express](https://expressjs.com/)を使用すると、これらの機能を拡張することができます。
-残念ながら、Node.jsはデフォルトで自身をシャットダウンする処理をあまりうまく処理しません。これはコンテナ化されたシステムで多くの問題を引き起こします。最大の問題は、Node.jsのコンテナがシャットダウンするように指示されると、すぐにすべてのアクティブな接続を強制終了し、それらを適切に停止させることができないことです。
+残念ながら、Node.jsは自身のシャットダウンをうまく処理できません。これはコンテナ化されたシステムで多くの問題を引き起こします。最大の問題は、Node.jsのコンテナがシャットダウンするように指示されると、すべてのアクティブな接続を即座にを強制終了し適切に停止させることができないことです。
-この部分では、アクティブなリクエストを処理し終えてから、適切にシャットダウンするようにNode.jsを教える方法を説明します。
+このパートでは、アクティブなリクエストを処理し終えてから、適切にシャットダウンするようにNode.jsを設定する方法を説明します。
例として、Expressを使用したシンプルなNode.jsサーバーを使用します:
@@ -24,7 +24,7 @@ const server = app.listen(3000, function () {
})
```
-これは、ウェブサーバーが `localhost:3000` にアクセスされたときに "Hello World" を表示します。処理に時間がかかるリクエストをシミュレートするため、応答に5秒の遅延があることに注意してください。 いくつかのコンピューティング時間。
+これは、Webサーバーが `localhost:3000` にアクセスされたときに "Hello World" を表示します。計算処理に時間がかかるリクエストをシミュレートするため、レスポンスに5秒の遅延があることに注意してください。
## パートA: リクエストの完了を許可する
@@ -53,13 +53,13 @@ process.on('SIGINT', startGracefulShutdown);
この小さな追加により、Node.jsはすべてのリクエストが完了するのを待つようになり、その後自身を停止します。
-もし私たちがNode.jsをコンテナ化された環境で実行していないならば、おそらく 数秒後に実際にNode.jsサーバーを終了する追加のコードを含めたいと考えています。なぜなら、一部のリクエストが非常に長くかかるか、あるいは全く停止しない可能性があるからです。これはコンテナ化されたシステム内で実行されているため、コンテナが停止しない場合、DockerとKubernetesは数秒後(通常は30秒後)に`SIGKILL`を実行します。これはプロセス自体では処理できないため、私たちにとっては関心事ではありません。
+もし私たちがNode.jsをコンテナ化された環境で実行していないならば、おそらく 数秒後に実際にNode.jsサーバーを終了する追加のコードを含めたいと考えています。なぜなら、一部のリクエストが非常に長くかかるか、あるいは全く停止しない可能性があるからです。これはコンテナ化されたシステム内で実行されているため、コンテナが停止しない場合、DockerとKubernetesは数秒後(通常は30秒後)に`SIGKILL`を実行します。これはプロセス自体では処理できないため、私たちは気にする必用がありません。
## パートB:YarnとNPMの子生成問題
もし私たちがパートAだけを実装した場合、良い経験を得られるでしょう。現実の世界では、多くのNode.jsシステムがYarnやNPMで構築されており、これらはNode.jsにパッケージ管理システムだけでなく、スクリプト管理も提供します。
-これらのスクリプト機能を使うと、アプリケーションの起動を簡単にすることができます。多くの`package.json`ファイルが以下のようになっていることが分かります:
+これらのスクリプト機能を使うと、アプリケーションの起動を簡単にすることができます。多くの`package.json`ファイルが以下のようになっていることが分かります。
```javascript title="package.json"
{
@@ -78,14 +78,17 @@ process.on('SIGINT', startGracefulShutdown);
そして、定義された`scripts`セクションを使って、以下のようにアプリケーションを起動するだけで済みます:
-```bash title="Start application"
-yarn start または
+```bash title="アプリケーションの起動"
+yarn start
+```
+
+または
```bash title="アプリケーションの起動"
npm start
```
-これは便利で、開発者の生活を楽にします。したがって、私たちはDockerfilesの中でも同じものを使用しています。
+これは便利で、開発者を楽にします。だから、私たちはDockerfilesの中でも同じものを使用しています。
```text title=".dockerfile"
CMD ["yarn", "start"]
@@ -93,7 +96,7 @@ CMD ["yarn", "start"]
しかし、これには大きな問題があります:
-`yarn` や `npm` が `SIGINT` や `SIGTERM` シグナルを受け取ると、それらは正確にシグナルを生成した子プロセスに転送します(この場合は `node index.js`)。しかし、子プロセスが停止するのを待つことはありません。代わりに、`yarn`/`npm` は即座に自分自身を停止します。これにより、Docker/Kubernetesに対してコンテナが完了したというシグナルが送られ、Docker/Kubernetesはすぐにすべての子プロセスを強制終了します。[Yarn](https://github.com/yarnpkg/yarn/issues/4667)と[NPM](https://github.com/npm/npm/issues/4603)にはオープンな問題がありますが、残念ながらまだ解決されていません。
+`yarn` や `npm` が `SIGINT` や `SIGTERM` シグナルを受け取ると、それらは正確にシグナルを生成した子プロセスに転送します。(この場合は `node index.js`)しかし、子プロセスが停止するのを待つことはありません。代わりに、`yarn`/`npm` は即座に自分自身を停止します。これにより、Docker/Kubernetesに対してコンテナが完了したというシグナルが送られ、Docker/Kubernetesはすぐにすべての子プロセスを強制終了します。[Yarn](https://github.com/yarnpkg/yarn/issues/4667)と[NPM](https://github.com/npm/npm/issues/4603)にはオープンな問題がありますが、残念ながらまだ解決されていません。
この問題の解決策は、YarnやNPMを使用してアプリケーションを開始するのではなく、直接 `node` を使用することです。
diff --git a/docs/ja/using-lagoon-advanced/private-repositories.md b/docs/ja/using-lagoon-advanced/private-repositories.md
index 48ada68786..8f1f927642 100644
--- a/docs/ja/using-lagoon-advanced/private-repositories.md
+++ b/docs/ja/using-lagoon-advanced/private-repositories.md
@@ -1,8 +1,8 @@
# プライベートリポジトリ
1. デプロイキーに、あなたのGitHub/GitLab/BitBucketのGitリポジトリへのアクセス権を与えます。
-2. `dockerfile`に`ARG LAGOON_SSH_PRIVATE_KEY`を追加します(SSHキーが必要なビルドプロセスのステップの前に)。
-3. `dockerfile`に`RUN /lagoon/entrypoints/05-ssh-key.sh`を追加します(SSHキーが必要なビルドプロセスのステップの前に)。
+2. `dockerfile`に`ARG LAGOON_SSH_PRIVATE_KEY`を追加します。(SSHキーが必要なビルドプロセスのステップの前に)
+3. `dockerfile`に`RUN /lagoon/entrypoints/05-ssh-key.sh`を追加します。(SSHキーが必要なビルドプロセスのステップの前に)
```bash title="プライベートリポジトリの設定"
RUN /lagoon/entrypoints/05-ssh-key.sh && composer install && rm /home/.ssh/key
diff --git a/docs/ja/using-lagoon-advanced/project-default-users-keys.md b/docs/ja/using-lagoon-advanced/project-default-users-keys.md
index 99f2da12c3..5e5f0821fd 100644
--- a/docs/ja/using-lagoon-advanced/project-default-users-keys.md
+++ b/docs/ja/using-lagoon-advanced/project-default-users-keys.md
@@ -1,11 +1,11 @@
# プロジェクトデフォルトユーザーとSSHキー
-Lagoonプロジェクトが作成されると、デフォルトで関連するSSH "プロジェクトキー"が生成され、その秘密キーがプロジェクトのCLIポッド内で利用可能になります。サービスアカウント`default-user@project`も作成され、プロジェクトへの`MAINTAINER`アクセスが付与されます。SSH "プロジェクトキー"は、その`default-user@project`に添付されます。
+Lagoonプロジェクトが作成されると、デフォルトで関連するSSH "プロジェクトキー"が生成され、そのシークレットキーがプロジェクトのCLIポッド内で利用可能になります。サービスアカウント`default-user@project`も作成され、プロジェクトへの`MAINTAINER`アクセスが付与されます。SSH "プロジェクトキー"は、その`default-user@project`に添付されます。
-これにより、任意の環境のCLIポッド内から同じプロジェクト内の他の任意の環境にSSHでアクセスすることが可能になります。このアクセスは、環境間でデータベースを同期化するなど、コマンドラインからタスクを実行するために使用されます(例:drush `sql-sync`)。
+これにより、任意の環境のCLIポッド内から同じプロジェクト内の他の任意の環境にSSHでアクセスすることが可能になります。このアクセスは、環境間でデータベースを同期化するなど、コマンドラインからタスクを実行するために使用されます。(例:drush `sql-sync`)
`MAINTAINER`ロールについての詳しい情報は、[RBAC](../interacting/rbac.md)のドキュメンテーションにあります。
## プロジェクトキーの指定
-プロジェクトを作成する際にSSH秘密キーを指定することは可能ですが、これにはセキュリティ上の問題があるため推奨されません。
+プロジェクトを作成する際にSSHシークレットキーを指定することは可能ですが、これにはセキュリティ上の問題があるため推奨されません。
diff --git a/docs/ja/using-lagoon-advanced/setting-up-xdebug-with-lagoon.md b/docs/ja/using-lagoon-advanced/setting-up-xdebug-with-lagoon.md
index 565d9490ec..7495de8eb1 100644
--- a/docs/ja/using-lagoon-advanced/setting-up-xdebug-with-lagoon.md
+++ b/docs/ja/using-lagoon-advanced/setting-up-xdebug-with-lagoon.md
@@ -2,47 +2,47 @@
## コンテナでXdebug拡張機能を有効にする
-Lagoonの基本イメージはXdebugが設定済みですが、パフォーマンス上の理由から、デフォルトでは拡張機能はロードされません。拡張機能を有効にするには、`XDEBUG_ENABLE`環境変数を`true`に設定する必要があります:
+Lagoonの基本イメージはXdebugが設定済みですが、パフォーマンス上の理由から、デフォルトでは拡張機能はロードされません。拡張機能を有効にするには、`XDEBUG_ENABLE`環境変数を`true`に設定する必要があります。
- **ローカル** (PygmyとLando)
- 1. プロジェクトがlagoon-examplesの `docker-compose.yml`ファイルをベースにしている場合、環境変数はすでに存在します。[これらの行をコメント解除してください](https://github.com/lagoon-examples/drupal10-base/blob/main/docker-compose.yml#L14-L15)。
- 2. 環境変数を変更した後は、コンテナを再構築して再起動することを確認してください。
+ 1. プロジェクトがlagoon-examplesの`docker-compose.yml`ファイルをベースにしている場合、環境変数はすでに存在します。[これらの行をコメント解除してください](https://github.com/lagoon-examples/drupal10-base/blob/main/docker-compose.yml#L14-L15)。
+ 2. 環境変数を変更した後は、コンテナを再構築して再起動できることを確認してください。
- **リモート** (dev/prod)
1. [Lagoon APIを使用して、実行中の環境に環境変数を追加することができます](../concepts-advanced/environment-variables.md#runtime-environment-variables-lagoon-api)。
2. 環境変数を変更した後は、環境を再デプロイすることを確認してください。
## Xdebug拡張機能の有効化
-デフォルトのXdebug設定では、セッションを開始するために拡張機能を有効化する"トリガー"が必要です。[完全なドキュメンテーションを表示することができます](https://xdebug.org/docs/step_debug#activate)。 _debugger)
-デバッガを有効化するためには、以下の簡単な手順を参照してください。
+デフォルトのXdebug設定では、セッションを開始するために拡張機能を有効化する"トリガー"が必要です。[（Xdebugのドキュメントを参考にしてください）](https://xdebug.org/docs/step_debug#activate)
+デバッガを有効化するためには、以下の簡単な手順を参考にししてください。
### CLI
-`php-cli` イメージは、Xdebugが有効になっているときには _常に_ Xdebugを有効化するように設定されています。
-したがって、他に行う必要があることは何もありません。任意のPHPスクリプトを実行すると、デバッグセッションが開始されます。
+`php-cli`イメージはXdebugが有効になっているときには常にXdebugを有効化するように設定されています。
+したがって、他に何もする必要はありません。任意のPHPスクリプトを実行するとデバッグセッションが開始されます。
### Web
-[ブラウザ拡張機能をインストールする](https://xdebug.org/docs/step_debug#browser-extensions)
-ことで、有効化クッキーを設定/解除します。
+[Xdebugのブラウザ拡張機能をインストールする](https://xdebug.org/docs/step_debug#browser-extensions)
+ことで、アクティベーションクッキーを設定/解除します。
-デバッグを開始したいウェブサイトに有効化クッキーが設定されていることを確認してください。
+デバッグを開始したいウェブサイトにアクティベーションクッキーが設定されていることを確認してください。
## PHPStormの設定
1. PHPStormはデフォルトで正しく設定されています。
2. ツールバーの“**Start Listening for PHP Debug Connections**”アイコンをクリックします。
3. ウェブページを読み込むか、Drushコマンドを実行します。
-4. 初回実行時には、PHPStormがウィンドウを表示し、次の操作を求めます:
+4. 初回実行時には、PHPStormがウィンドウを表示し、次の操作を求めます。
1. パスマッピングを確認します。
2. サーバー上でトリガーされた正しいローカルファイルを選択します。
## Visual Studio Codeの設定
-1. Felix Beckerによる[PHP Debug拡張機能をインストールします](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug)。
-2. 基本的な `launch.json` を作成するための[手順を参照します](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug#vs-code-configuration)。 PHP.
-3. 正しいパスマッピングを追加します。典型的なDrupalサイトの例は以下の通りです:
+1. Felix Beckerによる[PHP Debug拡張機能](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug)をインストールします。
+2. [説明](https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug#vs-code-configuration)に従ってPHP用の基本的な `launch.json`作成します。
+3. 正しいパスマッピングを追加します。典型的なDrupalサイトの例は以下の通りです。
```json title="launch.json"
"pathMappings": {
@@ -52,7 +52,7 @@ Lagoonの基本イメージはXdebugが設定済みですが、パフォーマ
4. Visual Studio Codeの**Run**タブで、
“**Listen for Xdebug**”の隣にある緑色の矢印をクリックします。
-5. ウェブページをロードするか、Drushコマンドを実行します。
+5. Webページをロードするか、Drushコマンドを実行します。
## トラブルシューティング
@@ -61,7 +61,7 @@ Lagoonの基本イメージはXdebugが設定済みですが、パフォーマ
-- 以下の設定を確認します:
+- 以下の設定を確認します。
| ディレクティブ | ローカル値 |
|:-------------------|:------------------------------------------|
@@ -69,12 +69,12 @@ Lagoonの基本イメージはXdebugが設定済みですが、パフォーマ
| xdebug.client_host | `host.docker.internal` または あなたのIPアドレス |
| xdebug.client_port | 9003 |
-- 実行中のコンテナ内でXdebugのロギングを有効にします。必要なのは、ロギングを有効にするために設定された`XDEBUG_LOG`という名前の環境変数だけです。
+- 実行中のコンテナ内でXdebugのログを有効にします。ログを有効にするには`XDEBUG_LOG`という名前の環境変数に何らかの値を設定するだけです。
ログは`/tmp/xdebug.log`に保存されます。もしlagoon-examplesを使用しているなら、あなたは [いくつかの既存の行](https://github.com/lagoon-examples/drupal10-base/blob/main/docker-compose.yml#L16-L18)のコメントを外します。
- アクティベーションクッキーが設定されていることを確認します。ChromeまたはFirefoxのブラウザツールを使用して、`XDEBUG_SESSION`クッキーが設定されていることを確認できます。
-- Xdebugがアクティブ化され、デバッグセッションがあなたのコンピューターで開始しようとしていることを確認します。`nc -l 9003` コマンドラインツールを使用してXdebugポートを開くことができます。すべてがPHPで正しく設定されていれば、ウェブページをロードするか、Drushコマンドを実行するとXdebug initのレスポンスが得られるはずです。
+- Xdebugがアクティブ化され、コンピューターとのデバッグセッションを開始しようとしていることを確認します。`nc -l 9003` コマンドラインツールを使用してXdebugポートを開くことができます。すべてがPHPで正しく設定されていれば、ウェブページをロードするか、Drushコマンドを実行すると`Xdebug init`のレスポンスが得られるはずです。
- `xdebug.client_host`が正しく設定されていることを確認します。Docker for Macでのローカルデバッグの場合、この値は`host.docker.internal`であるべきです。リモートデバッグの場合、この値はあなたのIPアドレスであるべきです。この値が正しく決定されなかった場合は、`DOCKERHOST`環境変数を設定することで上書きできます。
-- Landoをローカルで使用する場合、CLIから実行されるスクリプトをデバッグするためには、まず`lando ssh`を介してCLIコンテナにSSHでログインする必要があります。`lando drush`または`lando php`を実行してもデバッグできません。
+- Landoをローカルで使用する場合、CLIから実行されるスクリプトをデバッグするためには、まず`lando ssh`を介してCLIコンテナにSSHでログインする必要があります。`lando drush`または`lando php`を実行してもデバッグできないので注意が必要です。
### Mac固有のトラブルシューティング
@@ -86,11 +86,11 @@ Lagoonの基本イメージはXdebugが設定済みですが、パフォーマ
```
次のようなメッセージが表示されます。
- `host.docker.internal (192.168.65.2:9003) open`。
+ `host.docker.internal (192.168.65.2:9003) open`
## Linux 特有のトラブルシューティング
-- ホスト `host.docker.internal`に接続できることを確認します。`docker`が手動で(Docker Desktopを経由せずに)インストールされている場合、このホストは解決されません。これを強制的に解決するためには、`docker-compose.yml`ファイルに追加のスニペットを挿入することができます(インストラクションは[このブログ投稿](https://medium.com/the-sensiolabs-tech-blog/how-to-use-xdebug-in-docker-phpstorm-76d998ef2534)から引用)。
+- ホスト`host.docker.internal`に接続できることを確認してください。`docker`が(Docker Desktopを経由せずに)手動でインストールされている場合、このホストは解決されません。これを強制的に解決するためには、`docker-compose.yml`ファイルに追加のスニペットを挿入することで、このホストを強制的に解決することができます。(手順は[このブログ投稿](https://medium.com/the-sensiolabs-tech-blog/how-to-use-xdebug-in-docker-phpstorm-76d998ef2534)から引用しています)
```yaml title="Linux向けのdocker-compose.ymlの修正"
services:
@@ -104,7 +104,7 @@ Lagoonの基本イメージはXdebugが設定済みですが、パフォーマ
## Xdebug 2
-古いイメージを使用している場合は、まだXdebugバージョン2を使用しているかもしれません。このページのすべての情報は依然として適用されますが、一部の設定名と値は変更されています:
+古いイメージを使用している場合は、まだXdebugバージョン2を使用しているかもしれません。このページの情報はすべてそのまま適用されますが、設定名と値の一部は変更されています。
| v3 | v2 | |
|:-------------------|:----------------------|:----------------------------------------------|
diff --git a/docs/ja/using-lagoon-advanced/simplesaml.md b/docs/ja/using-lagoon-advanced/simplesaml.md
index f405c4b238..fa9ed0ecca 100644
--- a/docs/ja/using-lagoon-advanced/simplesaml.md
+++ b/docs/ja/using-lagoon-advanced/simplesaml.md
@@ -14,9 +14,9 @@ composer req simplesamlphp/simplesamlphp
### SimpleSAMLphpの設定を変更する
-`vendor/simplesamlphp/simplesamlphp/config-templates`から`authsources.php`と`config.php`をベンダーディレクトリ外の`conf/simplesamlphp`のような場所にコピーします。また、`vendor/simplesamlphp/simplesamlphp/metadata-templates`から`saml20-idp-remote.php`も必要です。
+`vendor/simplesamlphp/simplesamlphp/config-templates`から`authsources.php`と`config.php`を`vendor`ディレクトリ外の`conf/simplesamlphp`のような場所にコピーします。また、`vendor/simplesamlphp/simplesamlphp/metadata-templates`から`saml20-idp-remote.php`も必要です。
-`config.php`で次のLagoonの値を設定します:
+`config.php`でLagoonに以下の値を設定します:
SimpleSAMLphpにアクセスするための基本URLパス:
@@ -24,7 +24,7 @@ SimpleSAMLphpにアクセスするための基本URLパス:
'baseurlpath' => 'https://YOUR_DOMAIN.TLD/simplesaml/',
```
-セッションをデータベースに保存する:
+セッションをデータベースに保存します。
```php title="config.php"
'store.type' => 'sql',
@@ -36,14 +36,14 @@ SimpleSAMLphpにアクセスするための基本URLパス:
]),
```
-他の設定を好みに合わせて変更します:
+他の設定はお好みで設定してください。
-* ログと証明書のパスを確認します。
-* SimpleSAMLphpを保護します。 ダッシュボード。
-* ロギングのレベルを設定します。
-* `technicalcontact`と`timezone`を設定します。
+* ログと証明書のパスを確認します
+* SimpleSAMLphpダッシュボードを保護します
+* ロギングのレベルを設定します
+* `technicalcontact`と`timezone`を設定します
-`authsources.php`にauthsources(IdPs)を追加します。例を参照してください:
+例を参考に`authsources.php`にauthsources(IdPs)を追加します。
```php title="authsources.php"
'default-sp' => [
@@ -88,7 +88,7 @@ SimpleSAMLphpにアクセスするための基本URLパス:
],
```
-`saml20-idp-remote.php`にIdPメタデータを追加します。例を参照してください:
+例を参考に`saml20-idp-remote.php`にIdPメタデータを追加します。
```php title="saml20-idp-remote.php"
???+ Info "amazee.ioのお客様への情報"
- あなたがamazee.ioのお客様である場合、webhook-handlerへのルートは次のとおりです:[`https://hooks.lagoon.amazeeio.cloud`](https://hooks.lagoon.amazeeio.cloud)。
+ amazee.ioを利用しているで場合、webhook-handlerへのルートは次のとおりです。[`https://hooks.lagoon.amazeeio.cloud`](https://hooks.lagoon.amazeeio.cloud)
!!! Danger "危険"
- 以下の設定を管理するには、これらのリポジトリへの高いレベルのアクセスが必要となります。これはあなたの組織によって管理されます。これらの設定にアクセスできない場合は、システム管理者またはあなたの組織内の適切な人物に連絡してください。
+ 以下の設定を管理するには、これらのリポジトリへの高いレベルのアクセスが必要となります。これはあなたの組織によって管理されます。これらの設定にアクセスできない場合は、システム管理者またはあなたの組織内の適切な責任者に連絡してください。
## GitHub
@@ -16,8 +16,8 @@
2. `Payload URL`は、あなたのLagoon管理者から提供される、あなたのLagoonインスタンスの`webhook-handler`へのルートです。
3. `Content type`を`application/json`に設定します。
-4. "`私が個々のイベントを選択させてください`"を選択します。
-5. どのイベントがあなたのwebhookをトリガーするかを選択します。私たちは、`Push`と`Pull request`のイベントを送信することを提案し、その後、あなたのプロジェクトのLagoon設定でさらにフィルタリングします。
+4. "`Let me select individual events`"を選択します。
+5. どのイベントがwebhookをトリガーするかを選択します。`Push`と`Pull request`のイベントを送信し、プロジェクトのLagoon設定でさらにフィルタリングすることをお勧めします。
6. webhookが`Active`に設定されていることを確認します。
7. `Add webhook`をクリックして設定を保存します。
@@ -26,27 +26,27 @@
1. GitLabリポジトリで設定 -> インテグレーションに移動します。
-2. `URL`は、あなたのLagoon管理者から提供される、あなたのLagoonインスタンスの`webhook-handler`へのルートです。
-3. Lagoonに通知を送信する`Trigger`イベントを選択します。我々はあなたが`Push events`と`Merge request events`を送信し、その後Lagoonの設定でさらにフィルタリングすることを提案します。 あなたのプロジェクトの設定。
+2. `URL`は、Lagoonの管理者から提供される、Lagoonインスタンスの`webhook-handler`へのルートです。
+3. Lagoonに通知を送信する`Trigger`イベントを選択します。`Push events`と`Merge request events`を選択し、その後Lagoonの設定でさらにフィルタリングすることをお勧めします。
4. `Add webhook`をクリックして設定を保存します。
## Bitbucket
1. リポジトリで設定 -> ウェブフック -> 新しいウェブフックを追加に移動します。
-2. `Title`はあなたの参照のためのものです。
+2. `Title`は参照用です。
3. `URL`はあなたのLagoonインスタンスの`webhook-handler`へのルートで、Lagoonの管理者によって提供されます。
-4. `全てのトリガーから選択`をクリックし、以下を選択します:
-
- * リポジトリ
- * プッシュ
- * プルリクエスト
- * 作成
- * 更新
- * 承認
- * 承認の削除
- * マージ
- * 拒否
+4. `Choose from a full list of triggers`をクリックし、以下を選択します:
+
+ * Repository
+ * PUsh
+ * Pull Request
+ * Created
+ * Updated
+ * Approved
+ * Approval removed
+ * Merged
+ * Declined
5. `Save`をクリックしてBitbucketのウェブフック設定を保存します。
diff --git a/docs/ja/using-lagoon-the-basics/first-deployment.md b/docs/ja/using-lagoon-the-basics/first-deployment.md
index 8f7466b733..f79f8ee93d 100644
--- a/docs/ja/using-lagoon-the-basics/first-deployment.md
+++ b/docs/ja/using-lagoon-the-basics/first-deployment.md
@@ -8,26 +8,26 @@ description: >-
!!! Note "注意:"
- Drupalプロジェクトをデプロイする場合は、これをスキップして、[Drupal-specific first deployment documentation](../applications/drupal/first-deployment-of-drupal.md)をお読みください。
+ Drupalプロジェクトをデプロイする場合は、これをスキップして、[Drupalの初回デプロイ](../applications/drupal/first-deployment-of-drupal.md)をお読みください。
-## 1. 準備が整っていることを確認する
+## 1. 準備が整っていることを確認します
-最初のデプロイを成功させるためには、プロジェクトがLagoon化されており、Lagoonでプロジェクトが設定されていることを確認してください。もしそうでない場合、または確信が持てない場合、またはそれが馴染みがない場合は心配しないでください。[ステップバイステップのガイド](setup-project.md)を戻って読み、どのように作動するか見てから、再度デプロイに来てください！
+最初のデプロイを成功させるためには、プロジェクトがLagoon化されており、Lagoonでプロジェクトが設定されていることを確認してください。もしそうでない場合、または確信が持てない場合、または馴染みがない場合は心配しないでください。[ステップバイステップのガイド](setup-project.md)に戻ってどのように動作するか見てから、再度このページに来てください！
## 2. プッシュ
Lagoonでは、デプロイが設定されているブランチにプッシュすることで新しいデプロイを作成します。
-新しいコードをプッシュするものがない場合でも心配しないでください！以下のコマンドを実行してください:
+新しいコードをプッシュするものがない場合でも心配しないでください！以下のコマンドを実行してください。
```bash title="Git push"
-git commit --allow-empty -m "go, go! Power Rangers!"
+git commit --allow-empty -m "go, go! Lagoon!"
git push
```
-これによりプッシュがトリガーされ、Gitホスティングが設定されたWebhookを通じてLagoonにこのプッシュについて通知します。
+これによりプッシュがトリガーされ、Gitホスティングが設定されたWebhookを通じてLagoonにこのプッシュを通知します。
-すべて正しければ、あなたは見るはずです あなたが設定したチャットシステムでの通知(これはあなたの親切なLagoon管理者が設定したものです):
+すべて正しければ設定されたチャットシステムの通知を見ることができます。(これは親切なLagoonの管理者が設定したものです)
@@ -37,30 +37,30 @@ Lagoon UI をチェックして、展開の進行状況を確認することも
## 3. 完了しました
-Lagoonがビルドとデプロイを完了すると、チャットシステムに2つ目の通知を送ります。ここに例を示します:
+Lagoonがビルドとデプロイを完了すると、チャットシステムに2つ目の通知を送ります。ここに例を示します。
これには以下の情報が含まれています:
-* デプロイされたプロジェクト。
-* デプロイされたブランチとGit SHA。
-* ビルドとデプロイの完全なログへのリンク。
-* 環境にアクセスできるすべてのルート(URL)へのリンク。
+* デプロイされたプロジェクト
+* デプロイされたブランチとGit SHA
+* ビルドとデプロイのログへのリンク
+* 環境にアクセスできるすべてのルート(URL)へのリンク
-また、どのような通知なのかをすぐに判断することもできます。 それは絵文字によって始まります - ビルドが開始しただけの情報であるか、成功であるか、または失敗であるか。
+また、どのような通知なのかをすぐに判断することもできます。 それらは絵文字によって始まります。ビルドが開始しただけの情報であるか、成功であるか、または失敗であるか。
-それだけです！あまり難しくなかったことを願っています - devOpsを利用可能にすることが私たちの目指すところです！
+それだけです！あまり難しくなかったことを願っています。devOpsを利用可能にすることが私たちの目標です！
-## でも待って、他のブランチや本番環境についてはどうでしょうか？
+## 他のブランチや本番環境についてはどうでしょうか？
-それがLagoonの美しさです:それはまったく同じです！ブランチの名前をプッシュするだけで、そのブランチがデプロイされます。
+これがLagoonの良いところです。それらはまったく同じ方法です！ブランチの名前をプッシュするだけで、そのブランチがデプロイされます。
-## 失敗？心配しないで
+## 失敗？心配しないでください
-デプロイメントが失敗しましたか？ああ、いやだ！しかし、私たちはここに助けを求めています:
+デプロイが失敗しましたか？私たちがお手伝いします。
-1. Drupalサイトをデプロイした場合、[Drupal専用の最初のデプロイメントドキュメンテーション](../applications/drupal/first-deployment-of-drupal.md)を読むことを確認してください。これはなぜこれが起こるのかを説明します。
+1. Drupalサイトをデプロイした場合、[Drupalの初回デプロイ](../applications/drupal/first-deployment-of-drupal.md)を読むことを確認してください。これはなぜこれが起こるのかを説明します。
2. エラー通知の `Logs` リンクをクリックすると、デプロイメントプロセスのどこで失敗が発生したかが表示されます。
-3. もし理解できない場合は、Lagoonのサポートに尋ねてみてください。私たちはここに助けを求めています！
-4. サポートチャンネルまたは[コミュニティDiscord](https://discord.gg/te5hHe95JE)で私たちに連絡してください。
+3. もし理解できない場合は、Lagoonのサポートに尋ねてみてください。私たちがお手伝いします！
+4. サポートチャンネルまたは[Discordのコミュニティ](https://discord.gg/te5hHe95JE)で私たちに連絡してください。
diff --git a/docs/ja/using-lagoon-the-basics/going-live.md b/docs/ja/using-lagoon-the-basics/going-live.md
index e31984911c..b2a036d84d 100644
--- a/docs/ja/using-lagoon-the-basics/going-live.md
+++ b/docs/ja/using-lagoon-the-basics/going-live.md
@@ -6,9 +6,9 @@
### ルート / SSL
-あなたの`.lagoon.yml`にすべてのルートが設定されていることを確認してください。ドメインをLagoonに向けない場合、Let's Encrypt(LE)の証明書の作成を無効にすべきであることを認識しておいてください。これは問題を引き起こす可能性があります。Lagoonに向けていないドメインは、Let's Encryptの制限を超えないように、しばらくすると無効になります。
+あなたの`.lagoon.yml`にすべてのルートが設定されていることを確認してください。ドメインをLagoonに向けない場合、Let's Encrypt(LE)の証明書の作成を無効にすべきであることを認識しておいてください。このままでは問題を引き起こす可能性があります。Lagoonに向けていないドメインは、Let's Encryptの制限を超えないようにするためしばらくすると無効になります。
-証明機関(CA)による署名付き証明書を使用する場合、`tls-acme`を`false`に設定できますが、`insecure`フラグは`Allow`または`Redirect`に設定したままにしておいてください。CA証明書の場合、Lagoonの管理者にルートと、設定する必要があるSSL証明書を知らせてください。
+証明機関(CA)による署名付き証明書を使用する場合、`tls-acme`を`false`に設定できますが、`insecure`フラグは`Allow`または`Redirect`に設定したままにしておいてください。CA証明書の場合、Lagoonの管理者にルートと設定する必要があるSSL証明書を知らせてください。
```yaml title=".lagoon.yml"
environments:
@@ -38,55 +38,47 @@ environments:
insecure: Redirect
```
-!!! Note "注意:"
- ウェブサイトのすべてのページを確認するのは少し手間がかかるかもしれませんので、[mixed-content-scan](https://github.com/bramus/mixed-content-scan)を利用することができます。これにより、サイト全体をクロールし、非HTTPSサイトからのアセットを含むページを返します。
+!!! Note "注意"
+ ウェブサイトのすべてのページを確認するのは少し手間がかかるかもしれませんので、[mixed-content-scan](https://github.com/bramus/mixed-content-scan)を利用することもできます。これにより、サイト全体をクロールし、非HTTPSサイトからのアセットを含むページを返します。
-### リダイレクト
+### リダイレクトについて
-非wwwからwwwへのリダイレクトが必要な場合は、それらが `redirects-map.conf` に設定されていることを確認してください - [ドキュメンテーションを参照](../docker-images/nginx.md#redirects-mapconf)。
+非wwwからwwwへのリダイレクトが必要な場合は、それらが `redirects-map.conf` に設定されていることを確認してください。[ドキュメントを参照](../docker-images/nginx.md#redirects-mapconf)
-### クロンジョブ
+### Cron jobs
-プロダクション環境用のクロンジョブが設定されているか確認してください - [`.lagoon.yml`](../concepts-basics/lagoon-yml.md)を参照してください。
+production環境用のCron jobsが設定されているか確認してください。[`.lagoon.ymlのドキュメント`](../concepts-basics/lagoon-yml.md)を参照してください。
## DNS
-あなたのサイトが私たちのサーバーを指すようにするためにできるだけスムーズに進行するように、専用のロードバランサーDNSレコードを用意しています。これらの技術的なDNSリソースレコードは、あなたのサイトを取得するために使用されます。 amazee.ioインフラストラクチャにリンクされ、他の目的では使用されません。CNAMEレコードに疑問がある場合は、Lagoonの管理者に設定する必要がある正確なCNAMEを尋ねてください。
+あなたのサイトがamazee.ioのサーバーにできるだけスムーズに接続できるように、専用のロードバランサーDNSレコードを用意しています。これらの技術的なDNSリソースレコードは、あなたのサイトをamazee.ioのインフラストラクチャにリンクされるために使用され他の目的では使用されません。CNAMEレコードに疑問がある場合は、Lagoonの管理者に正確なCNAMEを設定してもらってください。
**amazee.ioの例:** `.amazee.io`
-ドメインをLagoonに切り替える前に、ライブになる前にTime-to-Live \(TTL\)を下げておくことを確認してください。これにより、古いサーバーから新しいサーバーへの切り替えが迅速に行われます。通常、DNSの切り替え前にはTTLを300-600秒に設定することをお勧めします。[TTLについての詳細情報](https://en.wikipedia.org/wiki/Time_to_live#DNS_records)。
+ドメインをLagoonに切り替える前に、（ライブになる前に）Time-to-Live \(TTL\)を下げておくことを確認してください。これにより、古いサーバーから新しいサーバーへの切り替えが迅速に行われます。通常、DNSの切り替え前にはTTLを300-600秒に設定することをお勧めします。[TTLについての詳細情報](https://en.wikipedia.org/wiki/Time_to_live#DNS_records)
-### Fastlyのための推奨設定(CNAMEレコード):
+!!! Info "情報:"
+ この情報はamazee.ioがホストしているプロジェクトにのみ関連しており、まもなくこのドキュメントから削除され、amazee.io固有のドキュメントに追加されます
-ドメインのDNSレコードをLagoonに指す推奨方法は、以下に示すようなCNAMEレコードを使用することです:
+### Fastlyの推奨設定
+
+**サブドメイン (CNAME)**
+
+サブドメイン(例: www.example.com.)のDNSレコードをLagoonに向けるには、以下のようにCNAMEレコードを使用することをお勧めします：
`CNAME`: `cdn.amazee.io`
-### Fastlyのための代替設定(Aレコード):
-
-DNSプロバイダがCNAMEレコードの使用をサポートしていない場合、代わりに以下のAレコードを使用できます。以下に示す各IPに対して個別のレコードを設定してください:
+**ルートドメイン(A/AAAA)**
+ルートドメイン(example.com.など)の設定は、DNS仕様ではルートドメインがCNAMEを指すことを許可していないため、厄介な場合があります。 そのため、以下のAレコードとAAAAレコードを使用する必要があります。 下記の各IPに個別のレコードを設定してください：
* `A`: `151.101.2.191`
* `A`: `151.101.66.191`
* `A`: `151.101.130.191`
* `A`: `151.101.194.191`
-
-!!! Note "注意:"
- 静的IPの設定は推奨しません DNSゾーン内のIPアドレス。Lagoonのロードバランサインフラが時間とともに変化する可能性があり、静的IPアドレスを設定するとサイトの利用可能性に影響を及ぼす可能性があります。
-
-### ルートドメイン
-
-ルートドメイン(例:example.com)の設定は、DNSの仕様がルートドメインをCNAMEエントリにポイントすることを許可していないため、少々トリッキーになることがあります。DNSプロバイダによっては、レコード名が異なります:
-
-* ALIAS at [DNSimple](https://dnsimple.com/)
-* ANAME at [DNS Made Easy](http://www.dnsmadeeasy.com/)
-* ANAME at [easyDNS](https://www.easydns.com/)
-* ALIAS at [PointDNS](https://pointhq.com/)
-* CNAME at [CloudFlare](https://www.cloudflare.com/)
-* CNAME at [NS1](http://ns1.com)
-
-DNSプロバイダがルートドメイン用のIPアドレスを必要とする場合は、Lagoonの管理者に連絡してロードバランサのIPアドレスを提供してもらいます。
+* `AAA`: `2a04:4e42::703`
+* `AAAA`: `2a04:4e42:200::703`
+* `AAAA`: `2a04:4e42:400::703`
+* `AAA`: `2a04:4e42:600::703`
## 本番環境
diff --git a/docs/ja/using-lagoon-the-basics/index.md b/docs/ja/using-lagoon-the-basics/index.md
index d9a5f2166e..8fddcadfaa 100644
--- a/docs/ja/using-lagoon-the-basics/index.md
+++ b/docs/ja/using-lagoon-the-basics/index.md
@@ -1,14 +1,14 @@
-# Lagoonの使用 - 概要
+# Lagoonの基本的な使い方 - 概要
-このセクションでは、Lagoonの基本的な特徴と機能について説明します。これらに慣れている方は、[Lagoonの使用 - 上級](../using-lagoon-advanced/index.md)に進んでください。
+このセクションでは、Lagoonの基本的な特徴と機能について説明します。これらに慣れている方は、[Lagoonの高度な使い方](../using-lagoon-advanced/index.md)に進んでください。
-ヘルプが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティとメンテナに問い合わせてください。
+ヘルプが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティのメンバーとメンテナに問い合わせてください。
## 必要条件
### Docker
-Lagoonプロジェクトを実行するには、システムがDockerを実行するための要件を満たしている必要があります。ワークステーションに最新バージョンのDockerをインストールすることをおすすめします。Dockerは[こちら](https://www.docker.com/get-docker)からダウンロードできます。また、Dockerには最低でも**4 CPUs**と**4 GB RAM**を割り当てることをおすすめします。
+Lagoonプロジェクトを実行するには、システムがDockerを実行するための要件を満たしている必要があります。ワークステーションに最新バージョンのDockerをインストールすることをおすすめします。Dockerは[こちら](https://www.docker.com/get-docker)からダウンロードできます。また、Dockerには最低でも**4CPUs**と**4GB RAM**を割り当てることをおすすめします。
### ローカル開発環境
@@ -32,14 +32,14 @@ Lagoonと[ローカル開発環境](local-development-environments.md)につい
### `docker-compose.yml`
-このファイルは`Docker Compose`によってローカル開発環境を開始するために使用されます。Lagoonもこれを使用して、どのサービスがデプロイされるべきか、どのタイプで、どのようにビルドするかを理解します。これは`labels`を通じて行われます。[`docker-compose.yml`のドキュメンテーション](../concepts-basics/docker-compose-yml.md)を参照してください。
+このファイルは`Docker Compose`によってローカル開発環境を開始するために使用されます。Lagoonもこれを使用して、どのサービスがデプロイされるべきか、どのタイプで、どのようにビルドするかを理解します。これは`labels`を通じて行われます。[docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)を参照してください。
### Dockerfiles
一部のDockerイメージとコンテナは、提供されたイメージから追加のカスタマイズが必要です。これには通常、2つの理由があります:
-1. **アプリケーションコード**: NGINX、PHP、Node.jsなどのコンテナは、そのイメージ内に実際のプログラミングコードが必要です。これはDockerビルドステップ中に行われ、Dockerfileで設定されます。LagoonはDockerを完全にサポートしており、そのためDockerfileのカスタマイズを通じて結果として得られるイメージに対する完全なコントロールを許可します。
-2. **イメージのカスタマイズ **: Lagoonでは、ベースイメージをあなたのニーズに合わせてカスタマイズすることも可能です。これには、追加の環境変数を挿入したり、サービスの設定を変更したり、さらに追加のツールをインストールすることも含まれます。Dockerイメージに追加のツールをインストールする際には注意が必要です。なぜなら、将来的に任意の適応を維持する必要があるからです！
+1. **アプリケーションコード**: NGINX、PHP、Node.jsなどのコンテナは、そのイメージ内に実際のプログラミングコードが必要です。これはDockerビルドステップ中に行われ、Dockerfileで設定されます。LagoonはDockerを完全にサポートしているためDockerfileのカスタマイズによって出来上がるイメージを完全に制御できます。
+2. **イメージのカスタマイズ**: Lagoonでは、ベースイメージをあなたのニーズに合わせてカスタマイズすることも可能です。これには、追加の環境変数を挿入したり、サービスの設定を変更したり、さらに追加のツールをインストールすることも含まれます。Dockerイメージに追加のツールをインストールする際には注意が必要です。なぜなら、将来的に任意の適応を維持する必要があるからです！
## Lagoonによるサポートサービスとベースイメージ
@@ -52,7 +52,7 @@ Lagoonと[ローカル開発環境](local-development-environments.md)につい
| [Node.js](../docker-images/nodejs.md) | 16, 18, 20 | [node/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node) |
| [PHP FPM](../docker-images/php-fpm.md) | 8.0, 8.1, 8.2 | [php/fpm/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm) |
| [PHP CLI](../docker-images/php-cli.md) | 8.0, 8.1, 8.2 | [php/cli/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli) |
-| [Python](../docker-images/nodejs.md) | 3.7, 3.8, 3.9, 3.10, 3.11 | [python/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python) |
+| [Python](../docker-images/python.md) | 3.7, 3.8, 3.9, 3.10, 3.11 | [python/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python) |
| [Redis](../docker-images/redis.md) | 5, 6, 7 | [redis/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/redis) |
| [Solr](../docker-images/solr.md) | 7, 8 | [solr/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/solr) |
| [Varnish](../docker-images/varnish.md) | 5, 6, 7 | [varnish/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish) |
@@ -62,4 +62,4 @@ Lagoonと[ローカル開発環境](local-development-environments.md)につい
すべてのイメージは[https://hub.docker.com/u/uselagoon](https://hub.docker.com/u/uselagoon)にプッシュされます。特性とセキュリティの観点から常に最新のタグ(例:`uselagoon/nginx:latest`)を使用することをおすすめします。
-特定のLagoonバージョンのイメージ、例えば`uselagoon/nginx:20.10.0`や`uselagoon/node-10:20.10.0`を使用する場合、新しいLagoonバージョンがリリースされたらすぐにイメージのバージョンをアップグレードするのはあなた自身の責任です！
+特定のLagoonバージョンのイメージ、例えば`uselagoon/nginx:20.10.0`や`uselagoon/node-10:20.10.0`を使用する場合、新しいLagoonバージョンがリリースされたらすぐにイメージのバージョンを各自の責任でアップグレードしてください！
diff --git a/docs/ja/using-lagoon-the-basics/lagoon-build-errors-and-warnings.md b/docs/ja/using-lagoon-the-basics/lagoon-build-errors-and-warnings.md
index 58ca2f8e87..9cdfff4ba6 100644
--- a/docs/ja/using-lagoon-the-basics/lagoon-build-errors-and-warnings.md
+++ b/docs/ja/using-lagoon-the-basics/lagoon-build-errors-and-warnings.md
@@ -1,14 +1,14 @@
# Lagoonビルドのエラーと警告
-新しいバージョンのLagoonでは、ビルドに潜在的な問題があるかどうかを識別し、失敗せずにそれらを警告としてハイライトする機能があります。これはまた、Lagoonチームがユーザーに対して予定されている非推奨や機能の変更を通知する方法でもあります。
+新しいバージョンのLagoonでは、ビルドに潜在的な問題があるかどうかを識別し、失敗せずにそれらを警告としてハイライトする機能があります。これはまたLagoonチームがユーザーに対して予定されている非推奨事項や機能の変更を通知する方法でもあります。
-例えば、Lagoonチームが `lagoon.yml` の設定を変更し、ユーザーが変更する必要がある何かがあった場合、警告にそれが記されます。そこでユーザーは、それが破壊的な変更になる前に変更することができます。可能な限り早期に解決するべきであり、将来のLagoonのリリースではエラーを処理できないかもしれませんが、ビルドを停止させるべきではありません。
+例えば、Lagoonチームが `.lagoon.yml` の設定を変更し、ユーザーが変更すべきことがある場合、警告が表示されます。ユーザーは、それを破壊的な変更になる前に修正できるようになります。これは可能な限り早期に解決するべきであり、将来のLagoonのリリースではエラーを処理できないかもしれませんが、ビルドを停止することはありません。
これらのエラーの解決方法がわからない場合は、Lagoonの管理者に連絡するか、[Lagoonコミュニティ](../community/discord.md)で質問してください。
## Docker Composeのエラー { #docker-compose-errors }
-[一般的なDocker Composeの問題](../concepts-basics/docker-compose-yml.md#common-docker-compose-issues)についてのセクションも参照してください。これらの問題の一部はそこでカバーされているかもしれません。
+[よくあるDocker Composeの問題](../concepts-basics/docker-compose-yml.md#common-docker-compose-issues)についてのセクションも参照してください。これらの問題の一部はそこでカバーされているかもしれません。
``` shell title="env_file エラーを示す Lagoon ビルド出力"
> an env_file is defined in your docker-compose file, but no matching file found
@@ -20,10 +20,10 @@ Docker Compose ビルド時に参照されるenvファイルが存在するこ
> an invalid string key was detected in your docker-compose file
```
-あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの誤用に関連している可能性があります。エラーメッセージはあなたがどこで理解するのを助けるべきです。
+あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの不備に関連している可能性があります。エラーメッセージを見ればその場所がわかるはずです。
``` shell title="yaml検証エラーを示すLagoonビルド出力"
> There are yaml validation errors in your docker-compose file that should be corrected
```
-あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの誤用に関連している可能性があります。エラーメッセージはあなたがどこで理解するのを助けるべきです。
+あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの不備に関連している可能性があります。エラーメッセージを見ればその場所がわかるはずです。
diff --git a/docs/ja/using-lagoon-the-basics/local-development-environments.md b/docs/ja/using-lagoon-the-basics/local-development-environments.md
index 646d1daa08..30b4b79094 100644
--- a/docs/ja/using-lagoon-the-basics/local-development-environments.md
+++ b/docs/ja/using-lagoon-the-basics/local-development-environments.md
@@ -1,16 +1,16 @@
# ローカル開発環境
-LagoonにはDockerと[Docker Compose](https://docs.docker.com/compose/)(ほとんどがDockerと一緒に出荷されています)に対する硬い依存性しかありませんが、Dockerに含まれていないローカル開発に役立つものがいくつかあります:
+LagoonにはDockerと[Docker Compose](https://docs.docker.com/compose/)(ほとんどがDockerと一緒に出荷されています)にしか依存しませんが、Dockerに含まれていないローカル開発に役立つものがいくつかあります:
* ナイスなURLとHTTPSオフローディングのためのHTTPリバースプロキシ。
* IPアドレスを覚えておく必要がないDNSシステム。
* コンテナ内でSSHキーを使用するためのSSHエージェント。
-* メールをローカルで受信し表示するシステム。
+* メールをローカルで受信して表示するシステム。
???+ warning
- ローカルでLagoonを_使用する_ためには、ローカルにLagoonを_インストール_する必要はありません！これは混乱するかもしれませんが、ドキュメンテーションを参照してください。Lagoonはあなたのローカル開発環境を本番環境に**デプロイ**するシステムであり、環境自体では**ありません**。
+ ローカルでLagoonを使用するためにインストールする必要はありません！これは混乱するかもしれませんが、ドキュメントを参照してください。Lagoonはあなたのローカル開発環境を本番環境に**デプロイ**するシステムであり、環境そのものでは**ありません**。
-## pygmy、DDEV、またはLando - 選択はあなた次第
+## pygmy、DDEV、またはLando - 選択はあなた次第です。
### pygmy
@@ -22,16 +22,16 @@ Lagoonは伝統的に`pygmy`と最も良好に動作してきました。これ
brew tap pygmystack/pygmy && brew install pygmy
```
-pygmyの詳細な使用方法やインストール情報については、その[ドキュメンテーション](https://pygmy.readthedocs.io/en/master/)を参照してください。
+pygmyの詳細な使用方法やインストール情報については、その[ドキュメント](https://pygmy.readthedocs.io/en/master/)を参照してください。
### Lando
-LagoonはLandoと非常によく組み合わされています！詳細な情報は、[https://docs.lando.dev/config/lagoon.html](https://docs.lando.dev/config/lagoon.html)のドキュメンテーションを参照して始めてください。
+LagoonはLandoと非常によく組み合わされています！詳細な情報は、[https://docs.lando.dev/config/lagoon.html](https://docs.lando.dev/config/lagoon.html)のドキュメントを参照して使用てください。
-LandoのLagoon向けのワークフローは、Landoのユーザーにとっては馴染み深いものであり、またLagoonの初心者が始めるのにも最も簡単な方法になります。一方、PygmyはDockerとより密接に統合されており、より複雑なシナリオやユースケースにはより適していますが、より深い理解が必要になります。
+LandoのLagoon向けのワークフローはLandoのユーザーにとっては馴染み深いものであり、またLagoonの初心者が始めるのにも最も簡単な方法になります。一方、PygmyはDockerとより密接に統合されており、より複雑なシナリオやユースケースに適していますがより深い理解が必要になります。
### DDEV
-LagoonはDDEVでもサポートされています！始めるためのドキュメンテーションをチェックしてみてください:[https://ddev.readthedocs.io/en/stable/users/providers/lagoon/](https://ddev.readthedocs.io/en/stable/users/providers/lagoon/)。
+LagoonはDDEVでもサポートされています！始めるためのドキュメントをチェックしてみてください。[https://ddev.readthedocs.io/en/stable/users/providers/lagoon/](https://ddev.readthedocs.io/en/stable/users/providers/lagoon/)。
-以前には、[Docksal](https://docksal.io/)や[Docker4Drupal](https://wodby.com/docs/stacks/drupal/local/)などの他のシステムへのサポートを追加することを評価していました。これらに将来的にサポートを追加する可能性はありますが、現在のところは、既存のツールへのサポートに焦点を当てています。
+以前には、[Docksal](https://docksal.io/)や[Docker4Drupal](https://wodby.com/docs/stacks/drupal/local/)などの他のシステムへのサポートを追加することを評価したことがありました。将来的にこれらのサポートを追加する可能性はありますが、現在のところは既存のツールへのサポートに焦点を当てています。
diff --git a/docs/ja/using-lagoon-the-basics/setup-project.md b/docs/ja/using-lagoon-the-basics/setup-project.md
index 2b6cb1c366..59bbc0579a 100644
--- a/docs/ja/using-lagoon-the-basics/setup-project.md
+++ b/docs/ja/using-lagoon-the-basics/setup-project.md
@@ -1,21 +1,21 @@
# 新しいプロジェクトの設定
!!! Note "注意:"
- 我々は全ての人がLagoonを使って自分自身でプロジェクトを設定し、構成することを可能にするためのCLIとGraphQL APIの設定に熱心に取り組んでいます。現在、これらの機能をリリースできる前に更なるテストが必要なので、お待ちください！
+ 我々は全ての人がLagoonを使って自分自身でプロジェクトを設定し、構成することを可能にするためのCLIとGraphQL APIの設定に熱心に取り組んでいます。現在これらの機能をリリースできる前に更なるテストが必要なのでお待ちください！
-それまでは、新しいプロジェクトの設定はLagoonの管理者と話し合うことを含んでいます。それは大丈夫です、彼らはAPIよりもずっとフレンドリーです。😊
+それまでは新しいプロジェクトの設定はLagoonの管理者と話しす必要があります。それについては問題ないです、彼らはAPIよりもずっとフレンドリーです。😊
あなたのLagoon管理者のために以下の情報を準備しておいてください:
* プロジェクトの名前
* この名前は小文字、数字、ダッシュのみを含めることができます
* プロジェクト名内にダブルダッシュ(`--`)は許可されていません
-* このプロジェクトに取り組むすべての人のSSH公開鍵、メールアドレス、名前。ここには、[GitHub](https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh)、[GitLab](https://docs.gitlab.com/ee/ssh/)、[Bitbucket](https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html) のSSHキーの生成とコピーについての指示があります。
-* あなたのコードがホストされているGitリポジトリのURL(`git@example.com:test/test.git`)。
-* あなたが使用するGitブランチの名前 あなたの本番環境で使用したい環境について ([環境タイプ](../concepts-advanced/environment-types.md) で環境の詳細を参照してください)。
-* 追加の環境にデプロイしたいブランチとプルリクエスト。Lagoonでは、正規表現でブランチとプルリクエストの名前をフィルタリングでき、あなたのLagoon管理者がこれを設定できます。
+* このプロジェクトに取り組むすべての人のSSH公開鍵、メールアドレス、名前。ここには、[GitHub](https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh)、[GitLab](https://docs.gitlab.com/ee/ssh/)、[Bitbucket](https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html) のSSHキーの生成とコピーについての指示があります
+* あなたのコードがホストされているGitリポジトリのURL(`git@example.com:test/test.git`)
+* あなたが使用するGitブランチの名前あなたの本番環境で使用したい環境について ([環境の種類](../concepts-advanced/environment-types.md) で環境の詳細を参照してください)
+* 追加の環境にデプロイしたいブランチとプルリクエスト。Lagoonでは、正規表現でブランチとプルリクエストの名前をフィルタリングでき、あなたのLagoon管理者が設定できます。
-特定の重要なブランチ(`develop`や`main`のような)やプルリクエストをデプロイすることをお勧めします。しかし、それはすべてあなた次第です！([ワークフロー](../concepts-advanced/workflows.md)で詳細情報を参照してください)
+特定の重要なブランチ(例えば`develop`や`main`)やプルリクエストをデプロイすることをお勧めします。しかし、最終的な判断はあなた次第です！([ワークフロー](../concepts-advanced/workflows.md)で詳細情報を参照してください)
## 1. プロジェクトがLagoon化されていることを確認する
@@ -25,16 +25,16 @@
## 2. あなたのコードへのアクセスを提供する
-あなたのコードをデプロイするために、Lagoonはそれへのアクセスが必要です。設計上、セキュリティのため、LagoonはあなたのGitリポジトリへの読み取りアクセスのみが必要です。
+あなたのコードをデプロイするために、Lagoonはコードへアクセスする必要があります。設計上、セキュリティのためにLagoonはあなたのGitリポジトリへの読み取りアクセスしか必要としません
-あなたのLagoon管理者は、読み取りアクセスを与えるべきSSH公開鍵やGitアカウントを教えてくれるでしょう。
+Lagoonの管理者から、読み取りアクセスを与えるべきSSH公開鍵やGitアカウントを教えてもらう必用があるかもしれません。
-## 3. ウェブフックの設定
+## 3. Webhooksの設定
-Lagoonは、Gitリポジトリに何が起こっているかについていくつかのイベントを知る必要があります。現在、これらはプッシュとプルリクエストですが、将来的にはもっと追加するかもしれません。
+Lagoonは、Gitリポジトリで起こっているいくつかのイベントを知る必要があります。現在はプッシュとプルリクエストですが、将来的にはもっと追加される予定です。
-Lagoonは多くの異なるGitホストをサポートしているため、これらの指示をこのドキュメンテーションに分割しました:[ウェブフックの設定](configure-webhooks.md)。
+Lagoonは多くの異なるGitホストをサポートしているため、これらの指示をこのドキュメントに分割しました:[Webhooksの設定](configure-webhooks.md)。
## 4. 次に:最初のデプロイメント
-おめでとうございます、あなたは今[初めてのデプロイメント](first-deployment.md)を実行する準備ができました。
+おめでとうございます、あなたは今[最初のデプロイ](first-deployment.md)を実行する準備ができました。
diff --git a/mkdocs.yml b/mkdocs.yml
index 3dbd6aea35..11bde1d8ba 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -271,7 +271,7 @@ plugins:
Deploy Targets: デプロイターゲット
Organizations: 組織
Roles: ロール
- Advanced Lagoon Concepts: 高度なLagoonの概念
+ Advanced Lagoon Concepts: Lagoonの高度な概念
Service Types: サービスタイプ
Environment Types: 環境タイプ
Environment Variables: 環境変数
@@ -305,7 +305,7 @@ plugins:
Lagoon Build Errors and Warnings: Lagoonビルドエラーと警告
Going Live: 本番環境への移行
Using Lagoon - Advanced: Lagoonの高度な使い方
- Active/Standby: アクティブ/スタンバイ
+ Active/Standby: Active/Standby
Triggering Deployments: デプロイのトリガー
Private Repositories: プライベートリポジトリ
Project Default Users and SSH Keys: プロジェクトのデフォルトユーザーとSSHキー