diff --git a/docs/ja/applications/index.md b/docs/ja/applications/index.md index 3e0df94a27..d2ae155d44 100644 --- a/docs/ja/applications/index.md +++ b/docs/ja/applications/index.md @@ -2,21 +2,21 @@ 説明: Lagoonで実行できるアプリケーション --- -# Lagoonがサポートするアプリケーション、フレームワーク、言語の幅広い範囲 +# Lagoonは幅広いアプリケーション、フレームワーク、言語をサポートしています -Lagoonは、アプリケーションスタックの3つのレベルを大まかに分類しています: +Lagoonは、アプリケーションスタックを大きく3つのレベルに分類しています: ## 言語 -これらは通常Lagoon特有のイメージによって提供され、任意のLagoonプロジェクトの基本的な構成要素です。 +Lagoonプロジェクトの基本的な構成要素であり、通常はLagoon専用のイメージによって提供されます。 ## フレームワーク -これらは基本イメージを取り、ウェブサイトを提供するため、またはアプリケーションを運用するために必要なロジック、ツール、パッケージを追加します。 +これらの基本イメージを基に、ウェブサイトを提供したり、アプリケーションを駆動したりするために必要なロジック、ツール、パッケージを追加します。 ## アプリケーション -通常、フレームワークの上に構築され、これはコンテンツエディターや開発者が最終製品を形成するために対話するレイヤーです。 +通常、フレームワークの上に構築され、コンテンツ編集者や開発者が最終製品を形作るために操作するレイヤーです。 ----------------------- @@ -24,14 +24,14 @@ Lagoonで使用するためのリポジトリを参照するとき、通常は3 ## テンプレート -これらは完全に機能し、複製可能なスターターリポジトリであり、定期的に維持・更新され、少ないカスタマイズで拡張して使用することができます。 +これらは完全に機能する、クローン可能なスターターリポジトリです。定期的にメンテナンスと更新が行われ、わずかなカスタマイズで拡張して使用できる状態にあります。 ## 例 -これらは完全に機能するリポジトリであり、定期的に維持・更新されますが、個々のプロジェクトに対して動作させるためにはいくつかの努力が必要かもしれません。 +これらは完全に機能するリポジトリで、定期的にメンテナンスと更新が行われていますが、個別のプロジェクトで動作させるにはある程度の労力が必要な場合があります。 ## デモ -これらはデモンストレーションとして構築されたリポジトリであり、その中のいくつかの概念に対して使用可能です。 しかし、定期的にメンテナンスや更新は行われていません。 +これらは実証のために構築されたリポジトリで、概念検証としては使用可能ですが、定期的なメンテナンスや更新は行われていません。 より完全なリストについては、私たちのGitHubリポジトリ:[https://www.github.com/lagoon-examples](https://www.github.com/lagoon-examples) と私たちのウェブサイト [https://lagoon.sh/application/](https://lagoon.sh/applications/) をご覧ください。 diff --git a/docs/ja/applications/laravel.md b/docs/ja/applications/laravel.md new file mode 100644 index 0000000000..a0ad8c6afa --- /dev/null +++ b/docs/ja/applications/laravel.md @@ -0,0 +1,15 @@ +# LaravelをLagoonで実行 + +LaravelをLagoonで実行するには、複数の方法があります。 + +* 既存のアプリケーションを自分で「lagoonize」することができます（[Lagoonizing](../lagoonizing/index.md)のドキュメントを参照してください）。 +* 参考として、シンプルなlagoonizeされたLaravelインストールの例示リポジトリを用意しています。 +* （推奨） ["Sail:onLagoon"](../other-tools/sail.md)というツールを提供しています。これは標準的なLaravel Sailアプリケーションを取り、適切なLagoon設定ファイルを自動生成します。 + +## アプリケーション環境キー + +アプリケーションキーを設定するには、CLIまたはUIを通じて`APP_KEY`環境変数([environment variable](../concepts-advanced/environment-variables.md))を設定してください。 + +これにより、キーをコード内（例えば`.env`ファイル）に保存する必要がなくなります。 + +アプリケーションキーを生成するには、`php artisan key:generate --show`コマンドを実行してください。このコマンドはプロジェクトファイルを変更せずに、有効なキーを出力します。 diff --git a/docs/ja/applications/node.md b/docs/ja/applications/node.md index af04ef0065..4e1b288284 100644 --- a/docs/ja/applications/node.md +++ b/docs/ja/applications/node.md @@ -2,6 +2,6 @@ ## はじめに -Lagoonは、[公式のNode Alpineイメージ](https://hub.docker.com/_/node/)を基にした[Node.jsイメージ](https://github.com/uselagoon/lagoon-images/tree/main/images/node)を提供しています。 +Lagoonは、[公式のNode Alpineイメージ](https://hub.docker.com/_/node/)をベースにした[Node.jsイメージ](https://github.com/uselagoon/lagoon-images/tree/main/images/node)を提供しています。 -Lagoon上でプロジェクトを動かすための適応方法についての詳しい情報は、[Node.js Dockerイメージ](../docker-images/nodejs.md)セクションで見つけることができます。 \ No newline at end of file +Lagoon上でプロジェクトを動かすための適応方法についての詳しい情報は、[Node.js Dockerイメージ](../docker-images/nodejs.md)セクションで見つけることができます。 diff --git a/docs/ja/applications/options.md b/docs/ja/applications/options.md index 58d1f9de25..35d555f305 100644 --- a/docs/ja/applications/options.md +++ b/docs/ja/applications/options.md @@ -6,38 +6,38 @@ description: Lagoonを使用するためのアプリケーション設定 ## `lagoon.yml` -Lagoonのプロジェクトレベルおよび環境レベルの設定は、リポジトリの `.lagoon.yml` ファイルに提供されています。 +Lagoonのプロジェクトレベルおよび環境レベルの設定は、リポジトリの `.lagoon.yml` ファイルで提供されています。 [`lagoon-yml.md`](../concepts-basics/lagoon-yml.md)を参照してください。 ## `docker-compose.yml` -Lagoonのサービスレベルの設定は、リポジトリの`docker-compose.yml`ファイルに提供されています。特に、`lagoon.type`と関連するサービスラベルは個々のサービスで文書化されています。 +Lagoonのサービスレベルの設定は、リポジトリの`docker-compose.yml`ファイルで提供されています。特に、`lagoon.type`と関連するサービスラベルは、個々のサービスのドキュメントに記載されています。 [`docker-compose-yml.md`](../concepts-basics/docker-compose-yml.md)を参照してください。 ## ストレージ -Lagoonは、ほとんどのサービスにストレージを提供する能力があります - 組み込みのLagoonサービスタイプには、必要なPVC、ボリュームなどを追加するための`-persistent`バリアントがあります。この設定をローカルに反映するように例を更新しました。 +Lagoonはほとんどのサービスにストレージを提供する機能があります。Lagoon組み込みのサービスタイプには、必要なPVC、ボリュームなどを追加できる`-persistent`バリアントがあります。この設定をローカルで反映するように例を更新しました。 ## データベース -Lagoonは以下の設定を利用できます: +Lagoonは以下のデータベース設定に対応しています: -* Mariadb - すべてのサポートされているバージョン -* PostgreSQL - すべてのサポートされているバージョン +* Mariadb - サポートされている全バージョン +* PostgreSQL - サポートされている全バージョン ### データベース・アズ・ア・サービス -Lagoonはまた、[dbaas-operator](https://github.com/amazeeio/dbaas-operator)を利用して、これらのデータベースを自動的にプロビジョニングする能力もあります。 管理データベースサービス(例:RDS、Google Cloud Databases、Azure Database)があります。これらのサービスがクラスターにプロビジョニングされ、設定されると自動的にこれらが利用されます。これらが利用できない場合、フォールバックとしてポッドがプロビジョニングされます。 +Lagoonはまた、[dbaas-operator](https://github.com/amazeeio/dbaas-operator)を利用して、基盤となるマネージドデータベースサービス（例：RDS、Google Cloud Databases、Azure Database）を使用してこれらのデータベースを自動的にプロビジョニングする機能を持っています。これらのサービスがクラスタ用にプロビジョニングおよび設定されると、自動的に行われます。これらが利用できない場合は、フォールバックとしてポッドがプロビジョニングされます。 ## キャッシュ -Lagoonは、キャッシュバックエンドとしてRedisをサポートしています。本番環境では、一部のユーザーがスケールを助けるために、本番環境用の管理されたRedisサービスをプロビジョニングします。 +LagoonはキャッシュバックエンドとしてRedisをサポートしています。本番環境では、一部のユーザーがスケーリングを支援するために、マネージドRedisサービスをプロビジョニングしています。 ## 検索 -Lagoonは、Elasticsearch、Solr、OpenSearchを検索プロバイダとしてサポートしています。必要に応じて、外部検索プロバイダも設定できます。 +Lagoonは検索プロバイダーとしてElasticsearch、Solr、OpenSearchをサポートしています。必要に応じて外部の検索プロバイダーも設定できます。 ## イングレス/ルート @@ -45,6 +45,6 @@ Lagoonは、イングレス要件を持つサービスのルートを自動生 ## 環境変数 { #environment-variables } -Lagoonは、ビルド時とランタイム時に環境変数を多用します。これらがアプリケーションの重要な設定(例:データベース設定/資格情報)を提供するために使用される場合、ローカルバージョンとLagoonバージョンが同様に名付けられていることが重要です。 +Lagoonは、ビルド時とランタイム時に環境変数を多用します。これらがアプリケーションの重要な設定(例:データベース設定/認証情報)を提供するために使用される場合、ローカルとLagoonのバージョンで同様の名前を付けることが重要です。 詳細は [environment-variables.md](../concepts-advanced/environment-variables.md)を参照してください。 diff --git a/docs/ja/applications/other.md b/docs/ja/applications/other.md index d3abba5b1d..16a2fb6bd9 100644 --- a/docs/ja/applications/other.md +++ b/docs/ja/applications/other.md @@ -1,12 +1,12 @@ -# Lagoon上で他のアプリケーションを実行する +# Lagoonで他のアプリケーションを実行 -たとえLagoonがあなたの特定のアプリケーション、フレームワーク、言語のための基本イメージを持っていなくても、Lagoonはそれを構築することができます！ +Lagoonが特定のアプリケーション、フレームワーク、言語用のベースイメージを持っていなくても、Lagoonでビルドすることが可能です。 -[共通イメージ](../docker-images/commons.md)を拡張したり、継承したりすることで、Lagoonはほぼどんなワークロードでも実行することができます。 +[commonsイメージ](../docker-images/commons.md)を拡張または継承することで、Lagoonはほぼあらゆるワークロードを実行できます。 ## Hugo -この簡単な例では、Hugoのウェブサイトを構築し、それをNGINXイメージの静的ファイルとして提供する方法を示しています。共通イメージはHugoの追加、サイトのコピー、構築のために使用されます。その後、NGINXイメージを使用してサイトを提供し、カスタマイズしたNGINX設定を追加します。 +この簡単な例は、Hugoウェブサイトをビルドし、NGINXイメージで静的ファイルとして提供する方法を示しています。commonsイメージを使用してHugoを追加し、サイトをコピーしてビルドします。その後、カスタマイズされたNGINX設定を追加したNGINXイメージを使用してサイトを提供します。 ```bash title="nginx.dockerfile" FROM uselagoon/commons as builder @@ -32,4 +32,4 @@ services: dockerfile: lagoon/nginx.Dockerfile labels: lagoon.type: nginx -``` \ No newline at end of file +``` diff --git a/docs/ja/applications/php.md b/docs/ja/applications/php.md index 49ce8f689e..3f30a5f824 100644 --- a/docs/ja/applications/php.md +++ b/docs/ja/applications/php.md @@ -1,6 +1,6 @@ # PHP -## 紹介 +## はじめに Lagoonは、[Drupal](./drupal/index.md)、Laravel、[Wordpress](wordpress.md)、Magento、Symfonyなど、様々なPHPベースのアプリケーションをサポートしています。 diff --git a/docs/ja/applications/ruby.md b/docs/ja/applications/ruby.md index 15d18b3bf6..5fcf237f45 100644 --- a/docs/ja/applications/ruby.md +++ b/docs/ja/applications/ruby.md @@ -1,18 +1,17 @@ # RubyとRuby on Rails -## 序章 +## はじめに -私たちは、公式のRuby alpine Dockerイメージをベースに構築したRuby 3.0以上のイメージを提供しています。 +私たちは、公式の Ruby alpine Docker イメージをベースにした Ruby 3.0 以上のイメージを提供しています。 +以下では、Rails アプリを Lagoon にデプロイしようとしていることを前提としていますが、ここで説明する詳細の多くは実際にはフレームワークに依存しません。 -以下では、Lagoon上でRailsアプリをデプロイしようとしていると仮定していますが、記述されている詳細のほとんどはフレームワークに関係なく適用可能です。 - -## Lagoon上でRailsを動作させる +## Lagoon で Rails を実行する ### リクエストへの応答 -Lagoonの例のリポジトリにある[Ruby on Rails](https://github.com/lagoon-examples/ruby-on-rails)の例は、ここで参考になります。 +Lagoonの例のリポジトリにある[Ruby on Rails](https://github.com/lagoon-examples/ruby-on-rails)の例が参考になります。 -[`docker-compose.yml`](https://github.com/lagoon-examples/ruby-on-rails/blob/main/docker-compose.yml)では、`ruby`という名前のサービスを設定しています。これは、任意の動的リクエストを処理する主要なサービスです。 +[`docker-compose.yml`](https://github.com/lagoon-examples/ruby-on-rails/blob/main/docker-compose.yml)では、動的リクエストを処理する主要サービスとして`ruby`という名前のサービスを設定しています。 `ruby`サービス用に指定された[dockerfile](https://github.com/lagoon-examples/ruby-on-rails/blob/main/lagoon/ruby.dockerfile)を見てみると、ポート3000を公開していることがわかります。`nginx`サービスは、非静的アセットのリクエストをこのポートの`ruby`サービスにリダイレクトします(詳細は[nginx設定ファイル](https://github.com/lagoon-examples/ruby-on-rails/blob/main/lagoon/nginx/nginx.conf)を参照してください)。 @@ -20,7 +19,7 @@ Lagoonの例のリポジトリにある[Ruby on Rails](https://github.com/lagoon Lagoonのロギングインフラストラクチャについては、次の文書で説明されています。 [こちらのドキュメント](../logging/logging.md)をご覧ください。基本的に、このインフラを利用するためには、ログをUDPメッセージで`udp://application-logs.lagoon.svc:5140`に送信する必要があります。 -Railsの例では、`logstash-logger`というgemをインポートし、その後`config/application.rb`で以下のように初期化しています。 +Railsの例では、`logstash-logger`というgemをインポートし、その後`config/application.rb`で以下のように初期化しています： ```ruby title="config/application.rb" if ENV.has_key?('LAGOON_PROJECT') && ENV.has_key?('LAGOON_ENVIRONMENT') then @@ -39,7 +38,7 @@ Railsの例では、`logstash-logger`というgemをインポートし、その ## データベース設定 -この例では、私たちのPostgreSQLイメージを使用しています(`docker-compose.yml`ファイルを参照してください)。LagoonでのRailsを用いたデータベースアクセスの設定は非常に簡単です。Lagoonはデータベースのホスト、名前、資格情報を環境変数として注入するため、[`config/database.yml`](https://github.com/lagoon-examples/ruby-on-rails/blob/main/config/database これらのenv varsを認識し、存在する場合はそれらを利用するように.yml)を設定します。 +この例では、私たちのPostgreSQLイメージを使用しています(`docker-compose.yml`ファイルを参照してください)。LagoonでのRailsを用いたデータベースアクセスの設定は非常に簡単です。Lagoon はデータベース接続に必要な情報を環境変数として提供します。そのため、[`config/database.yml`](https://github.com/lagoon-examples/ruby-on-rails/blob/main/config/database) ファイルでこれらの環境変数を利用するように設定することで、簡単にデータベース接続を構成できます。 ```yaml title="config/database.yml" default: &default diff --git a/docs/ja/applications/wordpress.md b/docs/ja/applications/wordpress.md index 3c2775de64..b57db94676 100644 --- a/docs/ja/applications/wordpress.md +++ b/docs/ja/applications/wordpress.md @@ -1,12 +1,12 @@ -# Lagoon上のWordPress +# WordPressをLagoonで実行 -[WordPressテンプレート](https://www.github.com/lagoon-examples/wordpress-base)は、WordPress、その依存性、およびテーマをインストールするためにComposerを使用するように設定されています。 +[WordPressテンプレート](https://www.github.com/lagoon-examples/wordpress-base)は、Composerを使用してWordPress、その依存関係、およびテーマをインストールするように設定されています。 -WordPressテンプレートは、[https://github.com/roots/bedrock](https://github.com/roots/bedrock)ボイラープレートを基にしていますが、標準化されたLagoonのデプロイメントパターンに合わせて拡張されています。 +このWordPressテンプレートは、[https://github.com/roots/bedrock](https://github.com/roots/bedrock)のボイラープレートをベースにしていますが、標準化されたLagoonのデプロイメントパターンに合わせて拡張されています。 ## Composerインストール -テンプレートは、WordPressとそのテーマをインストールするためにComposerを使用します。 +このテンプレートは、WordPressとそのテーマをインストールするためにComposerを使用します。 ## データベース @@ -14,8 +14,8 @@ LagoonはMariaDBとPostgreSQLデータベースをサポートしていますが ## NGINXの設定 -LagoonにはWordPress用の組み込み設定がありません - 代わりに、テンプレートには[初期設定のnginx.conf](https://github.com/lagoon-examples/wordpress-base/tree/main/lagoon/nginx)が付属しています - あなたが見つけた改善点をぜひ投稿してください! +LagoonにはWordPress用の組み込み設定がありません - 代わりに、テンプレートには[初期設定のnginx.conf](https://github.com/lagoon-examples/wordpress-base/tree/main/lagoon/nginx)が付属しています。改善点があれば、ぜひ貢献してください！ ## WP-CLI -Lagoonテンプレートは、WordPressのインストールを管理するために`wp-cli`をcliイメージにインストールします。 \ No newline at end of file +Lagoonテンプレートは、WordPressのインストールを管理するために`wp-cli`をcliイメージにインストールします。 diff --git a/docs/ja/lagoonizing/index.md b/docs/ja/lagoonizing/index.md index 3c3a083d1a..437c9f17d0 100644 --- a/docs/ja/lagoonizing/index.md +++ b/docs/ja/lagoonizing/index.md @@ -1,6 +1,6 @@ -# 既存のサイトをLagoon化する +# 既存のサイトをLagoonizing -_Lagoon化_、つまり既存のサイトをLagoonプラットフォームに対応させることは、一般的には難しくありません(サイトやセットアップによりますが)、しかしいくつかの手順が必要です。このプロセスを簡単にするためのステップバイステップのガイドをまとめました。 +「Lagoonizing」とは、既存のサイトをLagoonプラットフォームに適応させることで、通常は難しくない作業です（ただし、サイトやセットアップにより異なります）。「Lagoonizing」にはいくつかの手順が必要となります。このプロセスを簡単にするためのステップバイステップのガイドをまとめています。 ## 要件 @@ -8,15 +8,15 @@ _Lagoon化_、つまり既存のサイトをLagoonプラットフォームに対 ## ローカル開発環境 -[ローカル開発環境を設定する](../using-lagoon-the-basics/local-development-environments.md)。PygmyとLandoのどちらかを選ぶことができます。 +ローカルでの開発環境の設定方法については[こちら](../using-lagoon-the-basics/local-development-environments.md)をご覧ください。PygmyまたはLandoのいずれかを使用することができます。 ## コマンドラインとGit -コマンドラインを通じてLagoonとやりとりする必要があり、またGitも必要ですので、準備が整っていることを確認してください。 +Lagoonとのやり取りにはコマンドラインが必要ですし、Gitも使用しますので、これらが準備できているか確認してください。 ### コマンドライン -いくつかのタスクにはコマンドラインターミナルを使用する必要があります。何を使用しても構いません、オペレーティングシステムのデフォルトツールも含めてです。以下にいくつかのオプションを示します: +タスクの実行にはコマンドラインを使用する必要があります。OSのデフォルトのツールを含め、何を使用していただいても構いません。以下にいくつかのオプションを示します: - [iTerm2](https://iterm2.com/) (Mac) - [PowerShell](https://docs.microsoft.com/en-us/powershell/) (Windows) @@ -25,7 +25,7 @@ _Lagoon化_、つまり既存のサイトをLagoonプラットフォームに対 ### Gitのインストール -まだ持っていない場合は、 何らかの形でGitクライアントが必要です。コマンドライン、GUI、何でも構いません(私たちの例では、コマンドラインを使用します)。以下にいくつかのオプションを示します: +まだGitをインストールしていない場合は、 何らかの形でGitクライアントが必要となります。コマンドライン、GUI、何でも構いません(私たちの例では、コマンドラインを使用します)。以下にいくつかのオプションを示します: - [Gitのインストール](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) (Mac、Windows、Linux) - [SourceTree](https://www.sourcetreeapp.com/) (Mac、Windows) @@ -34,23 +34,23 @@ _Lagoon化_、つまり既存のサイトをLagoonプラットフォームに対 ## Lagoon管理者が必要とするもの -Lagoonを設定しているLagoon管理者は、いくつかの情報を必要とします。[詳細はこちら](../using-lagoon-the-basics/setup-project.md)。 +Lagoonを設定するLagoon管理者は、各種情報が必要となります。[詳細はこちら](../using-lagoon-the-basics/setup-project.md)。 ## Webhooksの設定 -次に、Gitリポジトリのためのwebhooksを設定する必要があります。[その手順はこちらで見つけることができます](../using-lagoon-the-basics/configure-webhooks.md)。 +次に、Gitリポジトリのためのwebhooksを設定する必要があります。その手順は[こちら](../using-lagoon-the-basics/configure-webhooks.md)からご確認いただけます。 ## `docker-compose.yml` -`docker-compose.yml`ファイルは、Lagoonによって以下のように使用されます: +`docker-compose.yml`ファイルは、Lagoonにおいて以下の目的で使用されます: - どのサービス/コンテナをデプロイするべきかを学ぶ。 - コンテナのイメージがどのようにビルドされるかを定義する。 - 永続ボリュームなどの追加設定を定義する。 -さらに詳しくは[私たちの`docker-compose.yml`ドキュメンテーション](../concepts-basics/docker-compose-yml.md). +さらに詳しい情報は[`docker-compose.yml`ドキュメンテーション](../concepts-basics/docker-compose-yml.md)をご確認ください. -これは、あなたのサイトをLagoonに対応させるために作成・設定する2つのファイルのうちの1つです。 +`docker-compose.yml`ファイルは、あなたのサイトをLagoonに対応させるために作成・設定する2つのファイルのうちの1つです。 `Docker-compose`(ツール)は、YAMLファイルの内容を厳格に検証するので、サービス定義の**ラベル**内でのみ設定を行うことができます。 @@ -60,13 +60,13 @@ Lagoonを設定しているLagoon管理者は、いくつかの情報を必要 基本的なサービスの設定方法をいくつか見てみましょう。この例では、Drupal、Laravel、その他のコンテンツマネジメントシステムなど、多くのシステムに必要なNGINX、PHP、MariaDBを設定します。 -以下は、Drupal用の`docker-compose.yml`ファイルの直接的な例です: +以下は、Drupal用の`docker-compose.yml`ファイルの例です: ```yaml title="docker-compose.yml" version: '2.3' x-lagoon-project: - # Lagoonプロジェクト名( この)を編集するときに `&lagoon-project`を残してください + # Lagoonプロジェクト名（ここを編集する場合は、&lagoon-projectを保持してください） &lagoon-project drupal-example x-volumes: @@ -78,11 +78,11 @@ x-volumes: x-environment: &default-environment LAGOON_PROJECT: *lagoon-project - # ローカルで使用するルート。pygmyを使用している場合、このルートは *必ず* .docker.amazee.ioで終わらなければなりません + # ローカルで使用するルート。pygmyを使用している場合、このルートは *必ず* .docker.amazee.ioで終わるようにしてください LAGOON_ROUTE: http://drupal-example.docker.amazee.io - # システムを本番環境のように動作させたい場合はコメントアウトを解除してください + # システムを本番環境のように動作させたい場合は以下の行のコメントアウトを解除してください #LAGOON_ENVIRONMENT_TYPE: production - # xdebugを有効にし、`docker-compose up -d`で再起動したい場合はコメントアウトを解除してください + # xdebugを有効にし、`docker-compose up -d`で再起動したい場合は以下の行のコメントアウトを解除してください #XDEBUG_ENABLE: "true" x-user: @@ -127,58 +127,58 @@ services: `x-environment`: - ここでローカル開発URLを設定できます。Pygmyを使用している場合、`.docker.amazee.io.`で終わらなければなりません。 -- 本番環境を完全に模倣したい場合は、`LAGOON_ENVIRONMENT_TYPE: production`のコメントを解除します。 -- x-debugを有効にしたい場合は、`DEBUG_ENABLE: "true"`のコメントを解除します。 +- 本番環境と全く同じ環境を再現したい場合は、`LAGOON_ENVIRONMENT_TYPE: production`のコメントアウトを解除してください。 +- x-debugを有効にしたい場合は、`DEBUG_ENABLE: "true"`のコメントアウトを解除してください。 `x-user`: これを変更する必要はほとんどありませんが、Linuxを使用していて1000以外のユーザーとして実行したい場合は変更できます。 ### `services` { #services } -これはデプロイしたいすべてのサービスを定義します。残念ながら、`docker-compose`はそれらをサービスと呼びますが、実際にはコンテナを定義しています。今後、これらをサービスと呼び、このドキュメンテーション全体で呼びます。 +`services`はデプロイしたいすべてのサービスを定義します。`docker-compose`はそれらをサービスと呼びますが、実際にはコンテナを定義しています。今後ドキュメンテーション全体でこれらをサービスと呼びます。 サービスの **名前** (上記の例では `nginx`、`php`、`mariadb`) は、生成される Kubernetes ポッド (これも別の用語ですが、ここではサービスと呼びます) の名前として Lagoon によって使用され、さらに定義された `lagoon.type` に基づいて作成される追加の Kubernetes オブジェクトの名前としても使用されます。これには、サービス、ルート、永続ストレージなどが含まれます。 ### Docker イメージ { #docker-images } -Lagoon ですべてのデプロイメント中にサービスの Dockerfile をビルドする場合は、ここで定義できます: +デプロイ毎にサービス用のDockerfileをLagoonがビルドするよう設定したい場合、以下のように定義できます: `build` -- `context` : Docker の `build` コマンドに渡すビルド コンテキスト パス。 +- `context` : Docker の `build` コマンドに渡すべきビルドコンテキストのパス。 - `dockerfile`: ビルドする Dockerfile の場所と名前。 -!!! Warning - Lagoon は `build: ` の短縮バージョンをサポートしていないため、そのような定義が見つかった場合は失敗します。 +!!! 注意 + Lagoon は `build: ` の短縮形をサポートしておらず、この形式の定義が見つかるとビルドに失敗します。 `image` - Dockerfile をビルドする必要がなく、既存の Dockerfile を使用する場合は、`image` で定義します。 -この例では、現在のディレクトリのパスを指定しています。NGINX は `nginx.dockerfile` をビルドするように設定され、PHP は `php.dockerfile` をビルドするように設定されています。MariaDB は `amazeeio/mariadb-drupal` の既存のイメージを使用しています。[Docker イメージの詳細については、こちら](../docker-images/commons.md) をご覧ください。 +この例では、現在のディレクトリのパスを指定しています。NGINX は `nginx.dockerfile` をビルドするように設定され、PHP は `php.dockerfile` をビルドするように設定されています。MariaDB は `amazeeio/mariadb-drupal` の既存のイメージを使用しています。Docker イメージの詳細については[こちら](../docker-images/commons.md) をご覧ください。 ### タイプ { #types } Lagoonは、正しいKubernetesのオブジェクトを設定するために、デプロイするサービスのタイプを知る必要があります。 -これは `lagoon.type` ラベルを介して行われます。選択できるタイプは多岐にわたります。すべてのタイプと追加的な設定可能性を見るために、私たちの公開ドキュメンテーション [Service Types](../concepts-advanced/service-types.md) を読んでください。 +これは `lagoon.type` ラベルを介して行われます。選択できるタイプは多岐にわたります。すべてのタイプと追加的な設定可能性を見るために、公開ドキュメンテーション [Service Types](../concepts-advanced/service-types.md) をご確認ください。 -例で気づいたかもしれませんが、PHPとNGINXのサービスは両方ともタイプを `nginx-php-persistent` と定義しています。それは彼らがいわゆるマルチコンテナポッドだからです。 +例では、PHPとNGINXのサービスは `nginx-php-persistent` としてタイプの定義しています。これはマルチコンテナポッドと呼ばれるものです。 ### マルチコンテナポッド -Kubernetesはプレーンなコンテナをデプロイしません。代わりに、それは1つ以上のコンテナを持つポッドをデプロイします。通常、Lagoonは定義された `docker-compose` サービスごとにコンテナを内部に持つ単一のポッドを作成します。しかし、いくつかのケースでは、これらのコンテナが互いに非常に依存しているため、単一のポッド内に2つのコンテナを置く必要があります。そのような状況の例は、DrupalのようなウェブアプリケーションのPHPコードを含むPHPとNGINXのコンテナです。 +Kubernetesは単独のコンテナをデプロイしません。代わりに、一つまたは複数のコンテナを含むポッドをデプロイします。通常、Lagoonは定義された `docker-compose` サービスに対して、一つのコンテナを含む単一のポッドを作成します。しかし、一部のケースでは、互いに依存度が高いため、二つのコンテナを単一のポッド内に配置する必要があります。DrupalのようなウェブアプリケーションのPHPコードを含むPHPとNGINXコンテナがその例です。 -これらのケースでは、どのサービスが一緒に留まるべきかをLagoonに伝えることが可能です。 一緒に。これは以下の方法で行われます(私たちはコンテナをサービスと呼んでいることを覚えておいてください): +これらのケースでは、以下のようにしてLagoonにどのサービスが一緒に配置されるべきかを指示することが可能です: -1. 両方のサービスを `lagoon.type` で定義し、それが2つのサービスを期待している(この例では、NGINXとPHPのサービスで定義されている `nginx-php-persistent` )。 -2. 2番目のサービスを1番目のサービスにリンクし、2番目のサービスのラベル `lagoon.name` を1番目のものと一致させます(この例では `lagoon.name: nginx` の設定によりこれが行われます)。 +1. 二つのサービスが必要な`lagoon.type`を指定して、それぞれのサービスを定義します（この例では、NGINXとPHPのサービスに`nginx-php-persistent`が設定されています）。 +2. 二番目のサービスの`lagoon.name`ラベルを一番目のサービスに一致させてリンクします（例では`lagoon.name: nginx`により設定されています）。 これにより、Lagoonは `nginx` と `php` のサービスが `nginx` と呼ばれるポッドに結合されていることを認識します。 -Lagoonはまだ、2つのサービスのうちどちらが _実際の_ 個々のサービスタイプであるか(この場合は `nginx` と `php` )を理解する必要があります。これは、一致するサービスタイプのサービス名を検索することでこれを行います。 `nginx-php-persistent` は、 `docker-compose.yml` の中で `nginx` という名前のサービスと `php` という名前のサービスを期待しています。 +Lagoonは2つのサービスのうちどちらが個々のサービスタイプであるか(この場合は `nginx` と `php` )を理解する必要があります。これは、一致するサービスタイプのサービス名を検索することで行います。 `nginx-php-persistent` は、 `docker-compose.yml` の中で `nginx` という名前のサービスと `php` という名前のサービスを期待しています。 -何らかの理由でサービスの名前を変更したい場合や、 `nginx-php-persistent` のタイプを持つ複数のポッドが必要な場合は、実際のサービスタイプを定義するために使用できる追加のラベル `lagoon.deployment.servicetype` があります。 +サービス名を変更したい場合や、`nginx-php-persistent`タイプの複数のポッドが必要な場合、`lagoon.deployment.servicetype`という追加のラベルを使用して、実際のサービスタイプを定義できます。 -以下に、マルチコンテナポッドがどのようになるかを示す例を示します。 詳細に設定する: +以下に、マルチコンテナポッドをより詳細に設定する例を示します: ```yaml title="docker-compose.yml" nginx: @@ -205,16 +205,17 @@ docker-compose.ymlでできることはもっとありますが、サービス ## `.lagoon.yml` -[`.lagoon.yml`](../concepts-basics/lagoon-yml.md) ファイルは、プロジェクトを設定するための中心的なファイルです。以下を行うための設定が含まれています: +[`.lagoon.yml`](../concepts-basics/lagoon-yml.md) ファイルはプロジェクト設定の中心となるファイルで、以下の設定を含んでいます: - サイトへのアクセスルートを定義します。 -- プレロールアウトタスクを定義します。 - ポストロールアウトタスクを定義する。 +- プレロールアウトタスクを定義します。 +- ポストロールアウトタスクを定義する。 - SSL証明書を設定する。 - 環境のためのcronジョブを追加する。 `.lagoon.yml`ファイルを作成し、Gitリポジトリのルートに配置する必要があります。 -以下に、私たちが説明するDrupalサイトの様々な設定オプションを示す例の`.lagoon.yml`ファイルを示します: +以下は、Drupalサイト用の様々な設定オプションを示す`.lagoon.yml`ファイルの例です: ```yaml title=".lagoon.yml" @@ -252,40 +253,43 @@ environments: - nginx: - example.com - example.net - - "www.example.com": - tls-acme: 'true' - insecure: Redirect - hsts: max -``` -年齢=31536000 - - "example.ch": - アノテーション: - nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri - - www.example.ch - - タイプ: - マリアDB: mariadb-galera - テンプレート: - マリアDB: mariadb.main.deployment.yml - ロールアウト: - マリアDB: statefulset - クロンジョブ: - - 名前: drush cron - スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。 - コマンド: drush cron - サービス: cli - ステージング: - クロンジョブ: - - 名前: drush cron - スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。 - コマンド: drush cron - サービス: cli + - "www.example.com": + tls-acme: 'true' + insecure: Redirect + hsts: max-age=31536000 + - "example.ch": + Annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri + - www.example.ch + +types: + mariadb: mariadb-galera + +templates: + mariadb: mariadb.main.deployment.yml + +rollouts: + mariadb: statefulset + +cronjobs: + - name: drush cron + schedule: "H * * * *" # 1時間に1回cronを実行します + command: drush cron + service: cli + +staging: + cronjobs: + - name: drush cron + schedule: "H * * * *" # 1時間に1回cronを実行します + command: drush cron + service: cli ``` ### 一般設定 #### `docker-compose-yaml` -このファイルは、どのサービスとコンテナがデプロイされるべきかを知るために、どの`docker-compose`YAMLファイルをビルドスクリプトが使用すべきかを指示します。これはデフォルトで`docker-compose.yml`になりますが、特定のLagoon `docker-compose` YAMLファイルが必要な場合にはこれを使用することができます。 +このファイルは、ビルドスクリプトにどの`docker-compose` YAMLファイルを使用するべきかを指示します。これにより、どのサービスとコンテナをデプロイするべきかを判断します。デフォルトは`docker-compose.yml`ですが、特定のLagoon `docker-compose` YAMLファイルが必要な場合に使用できます。 #### `environment_variables.git_sha` @@ -293,19 +297,19 @@ environments: ### タスク { #tasks } -定義できるタスクにはさまざまな種類があり、ビルド フローで実行されるタイミングも異なります。 +ビルドフローの中で実行されるタイミングによって、異なるタイプのタスクを定義できます： -#### ロールアウト前のタスク - `pre_rollout.[i].run` { #pre-rollout-tasks-pre_rolloutirun } +#### プレロールアウトタスク - `pre_rollout.[i].run` { #pre-rollout-tasks-pre_rolloutirun } `pre_rollout` タスクとして定義されたタスクは、新しいイメージが正常にビルドされた _後_、プロジェクトが何らかの形で変更される _前_ にプロジェクトに対して実行されます。この機能により、たとえば、上記の例のように、ロールアウトの実行前にデータベース ダンプを作成できます。これにより、ロールアウトで問題が発生した場合にロールバックしやすくなります。 -#### ロールアウト後のタスク - `post_rollout.[i].run` { #post-rollout-tasks-post_rolloutirun } +#### ポストロールアウトタスク - `post_rollout.[i].run` { #post-rollout-tasks-post_rolloutirun } -ここでは、次の後にプロジェクトに対して実行する必要があるタスクを指定できます。 +ここでは、以下の条件が満たされた後にプロジェクトに対して実行する必要のあるタスクを指定できます： -- すべてのイメージが正常にビルドされました。 -- すべてのコンテナが新しいイメージで更新されました。 -- 実行中のすべてのコンテナが準備チェックに合格しました。 +- すべてのイメージが正常にビルドされた +- すべてのコンテナが新しいイメージで更新された +- 実行中のすべてのコンテナが準備状態チェックに合格した `post_rollout` タスクの一般的な用途には、`drush updb`、`drush cim` の実行、またはさまざまなキャッシュのクリアが含まれます。上記の例では、`drush cim` と `drush cr` を実行します。 @@ -323,39 +327,39 @@ environments: `shell` -タスクを実行するためにどのシェルを使用するべきか。デフォルトでは `sh` が使用されますが、コンテナに他のシェル(bashなど)がある場合、ここでそれを定義することができます。これは、post-rollouts内でいくつかの小さなif/else bashスクリプトを実行したい場合に便利です。(上記の例で複数行のスクリプトを書く方法を参照してください)。 +タスクの実行に使用するシェルを指定します。デフォルトでは `sh` が使用されますが、コンテナに他のシェル(bashなど)がある場合、ここでそれを定義することができます。これは、ポストロールアウト内でいくつかの小さなif/else bashスクリプトを実行したい場合に便利です。(上記の例で複数行のスクリプトを書く方法を参照してください)。 ### ルート { #routes } #### `routes.autogenerate.enabled` -これにより、自動的に作成されたルートをまったく無効にすることができます。これは環境ごとのカスタムルートを無効にするものではありません。それについては下記を参照してください。 +これにより、自動生成されるルートを完全に無効にすることができます。これは環境ごとのカスタムルートを無効にするものではありません。詳細は下記を参照してください。 #### `routes.autogenerate.insecure` -これにより、自動的に作成されたルートの挙動を定義することができます。これは環境ごとのカスタムルートを設定するものではありません。それについては下記を参照してください。これは、上記の例で使用しているオプションで、`insecure: リダイレクト。 +これにより、自動生成されるルートの動作を定義できます。これは環境ごとのカスタムルートを設定するものではありません（詳細は後述）。これは上記の例で使用しているオプションで、`insecure: Redirect`と設定しています。 以下のオプションが許可されています: -`許可` +`Allow` - HTTPとHTTPSの両方のルートを設定します(これがデフォルトです)。 -`リダイレクト` +`Redirect` - すべてのHTTPリクエストをHTTPSにリダイレクトします。 -`なし` +`None` - HTTPのルートは作成されず、リダイレクトもありません。 ### 環境 -環境名は、デプロイされたブランチまたはプルリクエストに一致します。これにより、各環境は異なる設定を持つことができます。この例では、メインとステージングの環境を持っています。 +環境名は、デプロイされたブランチまたはプルリクエストに一致します。これにより、各環境は異なる設定を持つことができます。この例では、mainとstagingの環境を持っています。 #### 特定のパスの監視 -UptimeRobotがクラスターに設定されている場合、Lagoonは各ルート/イングレスにアノテーションを注入し、`stakater/IngressControllerMonitor`が使用します。デフォルトのアクションはルートのホームページを監視することです。特定のルートを監視する必要がある場合、ルートの仕様に`monitoring-path`を追加することでこれを上書きできます。一般的な使用法は、キャッシュをバイパスする監視用のパスを設定することで、サイトのリアルタイム監視をより実現します。 +UptimeRobotがクラスタに設定されている場合、Lagoonは各ルート/イングレスに`stakater/IngressControllerMonitor`で使用するためのアノテーションを注入します。デフォルトの動作はルートのホームページをモニタリングすることです。特定のルートを監視する必要がある場合、ルートの仕様に`monitoring-path`を追加することでこれを上書きできます。一般的な使用法は、キャッシュをバイパスする監視用のパスを設定することで、サイトのリアルタイム監視を実現します。 ```yaml title=".lagoon.ymlの例" - "www.example.com": @@ -364,20 +368,20 @@ UptimeRobotがクラスターに設定されている場合、Lagoonは各ルー #### `environments.[name].routes` -ルートセクションでは、環境が対応するドメイン名を特定します。それは 通常、ルートが指定された環境は本番環境だけです。すべての環境は生成されたルートを受け取りますが、非本番環境が独自のドメイン名を持つ必要がある場合もあります。ここでそれを指定し、そのドメインを生成されたルート名のCNAMEとしてDNSプロバイダに追加できます(これらのルートはデプロイメッセージで公開されます)。 +ルートセクションでは、環境が応答するドメイン名を指定します。通常、本番環境用のルートのみを指定します。すべての環境は生成されたルートを受け取りますが、本番以外の環境が独自のドメイン名を必要とする場合があります。ここで指定し、DNSプロバイダーでそのドメインを生成されたルート名へのCNAMEとして追加できます（これらのルートはデプロイメッセージで公開されます）。 -環境の次の要素は、ターゲットサービスで、例ではNGINXです。これにより、どのサービスに入力リクエストを送るかを特定します。 +環境設定の後に記述される最初の要素は、ターゲットサービスを指定します。この例ではNGINXがターゲットサービスとなっています。これにより、受信したリクエストをどのサービスに転送するかを指定しています。 -最も単純なルートは、上記のサンプル`.lagoon.yml`の`example.com`の例で、追加の設定がないことがわかります。これは、ルートのLet's Encrypt証明書を希望し、HTTPSからHTTPへのリダイレクトがないと仮定します。 +最もシンプルなルートは、上記のサンプル`.lagoon.yml`にある`example.com`の例です。追加の設定がないことがわかります。これは、ルートにLet's Encrypt証明書が必要で、HTTPSからHTTPへのリダイレクトが不要であることを前提としています。 -#### 注釈 +#### アノテーション -!!! Info "情報" - ルート/Ingress注釈は、nginx-ingressコントローラを実行するクラスタにデプロイされるプロジェクトでのみサポートされています！これがサポートされているかどうかはLagoonの管理者に確認してください。 +!!! Info "Info" + ルート/イングレスアノテーションは、`nginx-ingress`コントローラーを実行しているクラスタにデプロイするプロジェクトでのみサポートされています。この機能がサポートされているかどうかは、Lagoon管理者に確認してください。 -注釈は、`nginx-ingress`コントローラがサポートする注釈のYAMLマップであることが特に便利で、簡単にリダイレクトできます: +アノテーションは、nginx-ingressコントローラーがサポートするYAMLマップ形式で記述できます。これは簡単なリダイレクトに便利です: -この例では、`example.ch`への任意のリクエストがリダイレクトされます。 `https://www.example.ch` への移動、フォルダやクエリパラメータを維持します: +例えば、`example.ch`へのリクエストを`https://www.example.ch`にリダイレクトし、フォルダやクエリパラメータを維持したい場合は以下のように設定します: `(example.com/folder?query -> https://www.example.ch/folder?query)` @@ -388,7 +392,7 @@ UptimeRobotがクラスターに設定されている場合、Lagoonは各ルー - www.example.ch ``` -もちろん、Lagoonでホストされていない他のURLにもリダイレクトできます。これは `example.de` のリクエストを `https://www.google.com` にリダイレクトします: +もちろん、Lagoonでホストされていない他のURLへのリダイレクトも可能です。例えば、`example.de`へのリクエストを`https://www.google.com`にリダイレクトする場合: ```yaml title=".lagoon.yml の例" - "example.de": @@ -400,14 +404,14 @@ UptimeRobotがクラスターに設定されている場合、Lagoonは各ルー `tls-acme : ‘true’` -- このルートに対してLagoonがLet's Encrypt証明書を発行することを示します。これがデフォルトです。 +- Lagoonにそのルートに対してLet's Encrypt証明書を発行するよう指示します。これがデフォルトです。 - Let's Encryptが不要な場合、これを `tls-acme: ‘false’` に設定します。 `insecure` -- `None`、`Allow`、または `Redirect` に設定できます。 -- Allowは単にHTTPとHTTPSの両方のルートを設定します(これがデフォルトです)。 -- `Redirect` は、HTTPのリクエストをHTTPSにリダイレクトします。 +- `Allow`：HTTPとHTTPS両方のルートを設定します（デフォルト）。 +- `Redirect`：HTTPリクエストをHTTPSにリダイレクトします。 +- `None`：HTTPルートは作成されず、リダイレクトも行われません。 `None` @@ -415,27 +419,27 @@ UptimeRobotがクラスターに設定されている場合、Lagoonは各ルー `Hsts` -- 設定することができます `max-age=31536000;includeSubDomains;preload`の値に。 +- `max-age=31536000;includeSubDomains;preload`のような値を設定できます。 - スペースや他のパラメータが含まれていないことを確認します。 -- 必要なのは`max-age`パラメータのみです。この必要な max-age パラメータは、HSTS ポリシーが有効な時間を秒単位で指定します。 +- `max-age`パラメータのみが必須です。これはHSTSポリシーの有効期間を秒単位で指定します。 -!!! Info "情報" +!!! Info "Info" 証明書認証局(CA)によって署名された SSL 証明書から Let's Encrypt 証明書に切り替える予定がある場合は、Lagoon の管理者に連絡して移行を監督してもらうのが最善です。 #### `environments.[name].types` -Lagoon のビルドプロセスは `docker-compose.yml` ファイルの `lagoon.type` ラベルをチェックして、どのタイプのサービスをデプロイすべきかを学びます([docker-compose.yml のドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳細を読むことができます)。 +Lagoon のビルドプロセスは `docker-compose.yml` ファイルの `lagoon.type` ラベルをチェックして、どのタイプのサービスをデプロイするべきかを判断します([docker-compose.yml のドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳細を読むことができます)。 -時々、全てではなく一つの環境だけでタイプを上書きしたいかもしれません。 +特定の環境でのみタイプをオーバーライドしたい場合があります。 ##### `service-name: service-type -- `service-name` は上書きしたい `docker-compose.yml` のサービスの名前です。 -- `service-type` はあなたが上書きで使用したいサービスのタイプです。 +- `service-name`は`docker-compose.yml`からオーバーライドしたいサービスの名前です。 +- `service-type` オーバーライドで使用したいサービスのタイプです。 -例えば、あなたがプロダクション用の MariaDB-Galera 高可用性データベースを求めている場合、 メインと呼ばれる環境 - これが私たちの例のファイルで行っていることです: +例えば、`main`という名前の本番環境用にMariaDB-Galeraの高可用性データベースを使用したい場合: -```yaml title=".lagoon.yml example" +```yaml title=".lagoon.yml 例" environments: main: types: @@ -444,16 +448,16 @@ environments: #### `environments.[name].templates` -Lagoonのビルドプロセスは、`docker-compose.yml`ファイルから`lagoon.template`ラベルを確認し、サービスがカスタムテンプレートファイルが必要かどうかを確認します([docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳しく読むことができます)。 +Lagoonビルドプロセスは、`docker-compose.yml`ファイルの`lagoon.template`ラベルをチェックして、サービスにカスタムテンプレートファイルが必要かどうかを確認します([docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳しく読むことができます)。 -場合によっては、すべての環境ではなく、単一の環境だけでテンプレートを上書きすることが必要かもしれません: +特定の環境でのみテンプレートをオーバーライドしたい場合: ##### `service-name: template-file` -- `service-name`は、`docker-compose.yml`から上書きしたいサービスの名前です。 +- `service-name`は、`docker-compose.yml`からオーバーライドしたいサービスの名前です。 - `template-file`は、この環境でこのサービスに使用するテンプレートのパスと名前です。 -```yaml title=".lagoon.yml example" +```yaml title=".lagoon.yml 例" environments: main: templates: @@ -462,16 +466,16 @@ environments: #### `environments.[name].rollouts` -Lagoonのビルドプロセスは、`docker-compose.yml`ファイルから`lagoon.rollout`ラベルを確認し、サービスが特別なロールアウトタイプが必要かどうかを確認します([dockerのドキュメンテーションで詳しく読むことができます。 -compose.yml](../concepts-basics/docker-compose-yml.md))。 +Lagoonビルドプロセスは、`docker-compose.yml`ファイルの`lagoon.rollout`ラベルをチェックして、サービスにカスタムテンプレートファイルが必要かどうかを確認します([docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳しく読むことができます)。 -時折、特に環境のテンプレートタイプを上書きした場合には、単一の環境だけでロールアウトタイプを上書きしたいことがあります。 +すべての環境に対してではなく、ひとつの環境に対してだけタイプをオーバーライドしたい場合もあります。 ##### `service-name: rollout-type` - `service-name`は上書きしたい`docker-compose.yml`のサービス名です。 - `rollout-type`はロールアウトのタイプです。可能な値については[docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)を参照してください。 -```yaml title=".lagoon.yml example" +```yaml title=".lagoon.yml 例" environments: main: rollouts: @@ -480,17 +484,17 @@ environments: #### Cronジョブ - `environments.[name].cronjobs` -ほとんどの場合、すべての環境で同じcronジョブを実行することは望ましくないため、各環境で実行したいジョブを明示的に定義する必要があります。私たちの例では、1時間ごとに実行されるdrushのcronジョブを作成しています。 +通常、全ての環境で同じCronジョブを実行することは望ましくありません。そのため、各環境で実行したいジョブを明示的に定義する必要があります。例として、1時間に1回実行するdrush cronジョブを作成します。 `name` -- cronジョブの動作を識別するための親切な名前。 +- Cronジョブの目的を識別するためのわかりやすい名前。 `schedule` -- cronジョブを実行するスケジュール。これはcronの標準的な規則に従います。構文に自信がない場合は、[Crontab Generator](https://crontab-generator.org/)が役立ちます。 -- `M`を指定することができます。 - 分毎に `M` を指定すると、あなたの cron ジョブは毎時間ランダムな分に一度実行されます(毎時間同じ分)。または、`M/15` を指定すると、毎時間15分ごとに実行されますが、時間からのランダムなオフセット(6、21、36、51など)で実行されます。 -- 時間に `H` を指定すると、あなたの cron ジョブは毎日ランダムな時間に一度実行されます(毎日同じ時間)。または、`H(2-4)` を指定すると、2時から4時の間に一度だけ実行されます。 +- Cronジョブの実行スケジュールです。標準的なcron記法に従います。構文が不明な場合は、[Crontab Generator](https://crontab-generator.org/)が役立ちます。 +- 分`M`を指定すると、毎時間ランダムな分（毎時同じ分）に実行されます。`M/15`とすると15分ごとに実行されますが、時間からのオフセットはランダムです（例：6, 21, 36, 51）。 +- 時`H`を指定すると、毎日ランダムな時間（毎日同じ時間）に実行されます。`H(2-4)`とすると、2時から4時の間に1回実行されます。 `command` @@ -508,9 +512,9 @@ DrupalサイトをLagoonに移行する場合、全てをセットアップす ### 設定ファイル -次のステップは、設定ファイルを更新することです。Lagoonは、環境変数を使用する環境特有の設定ファイルのセットを使用するため、これらのファイルには機密情報は保存されず、全てがコミット可能で安全です。我々はさまざまな [私たちの例のリポジトリ](https://github.com/uselagoon/lagoon-examples)にあるさまざまな例のプロジェクト - もし初めての場合は、それらの一つを使用することをお勧めします。そうでない場合は、似たようなものを選んで関連する設定ファイルをコピーしてください。[環境変数に関するドキュメンテーションを確認してください](../concepts-advanced/environment-variables.md)。それらをどのように使用するかの詳細情報を得るために。 +次のステップは設定ファイルの更新です。Lagoonは環境変数を使用する環境固有の設定ファイルを使用します。これにより、機密情報がこれらのファイルに保存されることはなく、すべて安全にコミットできます。[リポジトリ](https://github.com/uselagoon/lagoon-examples)に様々なプロジェクト例があります。新規に始める場合は、これらの使用をお勧めします。そうでない場合は、類似のものを選んで関連する設定ファイルをコピーしてください。環境変数の使用方法については、[環境変数のドキュメント](../concepts-advanced/environment-variables.md)をご覧ください。 -例のリポジトリから設定ファイルをコピーし、その後、あなたのサイトが使用していないサービスの設定を削除するためにそれを確認します(例えば、すべてのサイトがSolrやRedisを使用しているわけではありません)。特定の環境タイプの設定をオーバーライドする必要がある場合(開発環境でのキャッシュを無効にするなど)、追加の設定ファイルを設定することができます(例のリポジトリにすでにいくつかあります)、そして次の順序でロードされます: +リポジトリから設定ファイルをコピーし、サイトで使用していないサービスの設定を削除してください（例：すべてのサイトがSolrやRedisを使用しているわけではありません）。特定の環境タイプ（開発環境でのキャッシュ無効化など）の設定をオーバーライドする必要がある場合、追加の設定ファイルを設定できます（例示リポジトリにすでにいくつか用意されています）。ファイルは以下の順序で読み込まれます： ```php title="settings.php" @@ -526,25 +530,25 @@ DrupalサイトをLagoonに移行する場合、全てをセットアップす ### ``.gitignore``の設定を更新する -`.gitignore`が設定ファイルのコミットを許可するようにすることを確認してください。Drupalは `sites/*`で出荷されます `/settings*.php`および`sites/*/services*.yml`を`.gitignore`から削除します。Lagoonを使用する場合、Gitリポジトリに機密情報を保持することはありません。 +`.gitignore`が設定ファイルのコミットを許可するようにすることを確認してください。Drupalはデフォルトで`sites/*/settings*.php`と`sites/*/services*.yml`を`.gitignore`に含めています。Lagoonでは機密情報をGitリポジトリに保存しないので、これらを削除できます。 ### DrupalのWebrootについての注意点 -残念ながら、Drupalコミュニティでは標準化されたwebrootフォルダ名についてまだ決定していません。一部のプロジェクトではDrupalを`/web`内に、他のプロジェクトでは`/docroot`または他の場所に配置します。LagoonのDrupal設定ファイルは、Drupalが`/web`内にあると想定しています。Drupalのインストールがこれと異なる場合は、ファイルを適切に調整してください。 +残念ながら、Drupalコミュニティはウェブルートフォルダ名を標準化していません。プロジェクトによってはDrupalを`/web`内に、他は`/docroot`や他の場所に配置しています。Lagoon Drupal設定ファイルは、Drupalが`/web`内にあることを前提としています。もしあなたのDrupalインストールが異なる場合は、ファイルを適宜調整してください。 -### 画像をビルドする +### イメージのビルドする -まず、定義された画像をビルドする必要があります: +まず、定義されたイメージをビルドする必要があります: ```bash title="build your images" docker-compose build ``` -これには数分かかる場合があり、長いレスポンスが返ってきます。[これは次のようなものになるはずです](https://gist.github.com/AlannaBurke/1bdad6aab977b0994c245834e61b6b50)。 +これには数分かかる場合があり、長いレスポンスが返ってきます。[このようなものになるはずです](https://gist.github.com/AlannaBurke/1bdad6aab977b0994c245834e61b6b50)。 -これにより、`docker-compose.yml`で`build:`定義を持つすべてのコンテナのDockerイメージを`docker-compose`にビルドさせます。通常、Drupalでは`cli`、`nginx`、`php`が含まれます。これは、特定のビルドコマンド(`composer install`など)を実行したり、特定の環境変数(`WEBROOT`など)を画像に注入したりするためです。 +これにより、docker-composeは`docker-compose.yml`内で`build:`定義があるすべてのコンテナのDockerイメージをビルドします。通常、Drupalの場合、これには`cli`、`nginx`、`php`が含まれます。特定のビルドコマンド（`composer install`など）を実行したり、特定の環境変数（`WEBROOT`など）をイメージに注入したりするために行います。 -通常、 Drupalのコードを編集するたびにビルドする必要はありません(コードはホストからコンテナにマウントされます)、しかし再ビルドは問題ありません。さらに、Lagoonはデプロイメント時に全く同じDockerイメージをビルドするので、`docker-compose build` を再度実行するだけで、ビルドがデプロイメント時にも正常に動作するか確認できます。 +通常、 Drupalのコードを編集するたびにビルドする必要はありません(コードはホストからコンテナにマウントされます)、しかし再ビルドは問題ありません。さらに、Lagoonはデプロイ中に全く同じDockerイメージをビルドするので、`docker-compose build` を再度実行するだけで、ビルドがデプロイ中にも機能することを確認できます。 ### コンテナの起動 @@ -557,7 +561,7 @@ docker-compose up -d 次のような応答が表示されます: ```bash title="containers started" -➜ lagoon-test git:(main) docker-compose up -d +➜ lagoon-test git:(main) docker compose up -d Recreating lagoon-test_cli_1 ... done Starting lagoon-test_redis_1 ... done Starting lagoon-test_solr_1 ... done @@ -570,41 +574,42 @@ Recreating lagoon-test_varnish_1 ... done これによりすべてのコンテナが起動します。コマンドが完了した後、`docker-compose ps`で確認して、すべて完全に起動し、クラッシュしていないことを確認できます。その応答は次のようになるはずです: ```bash title="view running containers" -➜ lagoon-test git:(main) docker-compose ps -Name コマンド 状態 ポート +➜ lagoon-test git:(main) docker compose ps +Name Command State Ports ---------------------------------------------------------------------------------------- -lagoon-test_cli_1 /sbin/tini -- /lagoon/entr ... 上 9000/tcp -lagoon-test_mariadb_1 /sbin/tini -- /lagoon/entr ... 上 0.0.0.0:32768->3306/tcp -lagoon-test_nginx_1 /sbin/tini -- /lagoon/entr ... 上 8080/tcp -lagoon-test_php_1 /sbin/tini -- /lagoon/entr ... 上 9000/tcp -lagoon-test_redis_1 /sbin/tini -- /lagoon/entr ... 上 6379/tcp -lagoon-test_solr_1 /sbin/tini -- /lagoon/entr ... 上 0.0.0.0:32769->8983/tcp -lagoon-test_varnish_1 /sbin/tini -- /lagoon/entr ... 上 8080/tcp +lagoon-test_cli_1 /sbin/tini -- /lagoon/entr ... Up 9000/tcp +lagoon-test_mariadb_1 /sbin/tini -- /lagoon/entr ... Up 0.0.0.0:32768->3306/tcp +lagoon-test_nginx_1 /sbin/tini -- /lagoon/entr ... Up 8080/tcp +lagoon-test_php_1 /sbin/tini -- /lagoon/entr ... Up 9000/tcp +lagoon-test_redis_1 /sbin/tini -- /lagoon/entr ... Up 6379/tcp +lagoon-test_solr_1 /sbin/tini -- /lagoon/entr ... Up 0.0.0.0:32769->8983/tcp +lagoon-test_varnish_1 /sbin/tini -- /lagoon/entr ... Up 8080/tcp + ``` 問題がある場合は、 `docker-compose logs -f [servicename]`を使用してログを確認します。 -### 再度 `composer install`を実行する(Composerプロジェクトのみ) +### `composer install`の再実行（Composerプロジェクトのみ） -Drupal 8+プロジェクトを実行している場合は、Composerを使用しているはずであり、すべての依存関係をダウンロードしてインストールする必要があります。cliコンテナに接続し、composer installを実行します: +Drupal 8以降のプロジェクトを実行している場合、Composerを使用しているはずです。全ての依存関係をダウンロードしてインストールする必要があります。cliコンテナに接続し、`composer install`を実行します： ```bash title="re-run composer install" docker-compose exec cli bash [drupal-example]cli-drupal:/app$ composer install ``` -これは奇妙に聞こえるかもしれませんが、 ビルドステップ中にすでに`composer install`が実行されていたので、再度これを行う理由を説明します: +これは奇妙に聞こえるかもしれません。ビルド段階ですでに`composer install`が実行されているからです。再度実行する理由は以下の通りです： -- ホスト上のファイルを編集してコンテナ内で直ちに利用できるようにするため、デフォルトの`docker-composer.yml`は全フォルダをコンテナにマウントします(これは`volumes`セクションの`.:/app:delegated`で起こります)。これはまた、Dockerビルド中にインストールされた全ての依存関係がホスト上のファイルで上書きされることも意味します。 -- ローカルでは、`composer.json`で`require-dev`として定義された依存関係にアクセスしたいと思うでしょう、一方で本番環境ではそれらは不必要なスペースを占めるだけです。そのため、Dockerfileで`composer install --no-dev`を実行し、手動で`composer install`を行います。 +- ホスト上でファイルを編集し、すぐにコンテナで利用できるようにするため、デフォルトの`docker-composer.yml`はフォルダ全体をコンテナにマウントします（これは`volumes`セクションの.`:/app:delegated`で行われます）。これは、Dockerビルド中にインストールされた全ての依存関係がホスト上のファイルで上書きされることも意味します。 +- ローカルでは、おそらく`composer.json`の`require-dev`で定義された依存関係にアクセスしたいでしょうが、本番デプロイではそれらは不要なスペースを使用するだけです。そのため、Dockerfileでは`composer install --no-dev`を実行し、手動で`composer install`を実行します。 -すべてがうまくいった場合、`docker-compose.yml`で定義された`LAGOON_ROUTE`を開きます(例えば`http://drupal.docker.amazee.io`)と、素敵なDrupalエラーに迎えられるはずです。心配しないでください - 今のところそれは大丈夫です、最も重要なことはDrupalサイトをロードしようと試みることです。 +全てが上手くいった場合、`docker-compose.yml`で定義された`LAGOON_ROUTE`（例：`http://drupal.docker.amazee.io`）を開くと、Drupalのエラーが表示されるはずです。心配しないでください - 今のところこれで問題ありません。最も重要なのは、Drupalサイトを読み込もうとしていることです。 -500やそれに類似するエラーが出る場合は、Composerですべてが適切にロードされていることを確認してください。 +500または同様のエラーが発生した場合は、Composerで全てが正しく読み込まれていることを確認してください。 ### ステータスの確認とDrupalのインストール -最後にDrupalをインストールする時間ですが、その前に すべてが正常に動作することを確認したいです。そのためには、`drush status`を使ったDrushの使用をお勧めします: +最後にDrupalをインストールする時が来ましたが、その前に全てが正常に動作していることを確認しましょう。そのためにDrushを使用することをお勧めします。`drush status`を実行します： ```bash title="run drush status" docker-compose exec cli bash @@ -637,9 +642,9 @@ Site path : sites/default ``` !!! Info "情報" - 次のステップに進む前に、公開鍵についてpygmyに伝える必要があるかもしれません。`Permission denied (publickey)`というエラーが表示された場合は、確認してください。 こちらでドキュメンテーションを確認してください:[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/usage/#adding-ssh-keys)。 + 次のステップに進む前に、公開鍵についてpygmyに伝える必要があるかもしれません。`Permission denied (publickey)`というエラーが表示された場合は、こちらのドキュメンテーションを確認してください:[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/usage/#adding-ssh-keys)。 -次にDrupalをインストールします(代わりに既存のSQLファイルをインポートしたい場合は、次のステップに進んでください。しかし、初めにすべてが正常に動作していることを確認するために、クリーンなDrupalをインストールすることをお勧めします)。 +これでDrupalをインストールする時が来ました（代わりに既存のSQLファイルをインポートしたい場合は、次のステップに進んでください。ただし、最初はクリーンなDrupalをインストールして、全てが動作することを確認することをお勧めします）。 ```bash title="drush siの実行" [drupal-example]cli-drupal:/app$ drush site-install @@ -648,47 +653,46 @@ Site path : sites/default ```bash title="drush siの結果" [drupal-example]cli-drupal:/app$ drush site-install -あなたは 'drupal' データベースのすべてのテーブルをDROPしようとしています。続行しますか？ (y/n): y -Drupalのインストールを開始します。これには時間がかかります。--notifyグローバルオプションの使用を検討してください。 -インストール完了。ユーザー名: admin ユーザーパスワード: arbZJekcqh -おめでとうございます、Drupalをインストールしました！ +You are about to DROP all tables in your 'drupal' database. Do you want to continue? (y/n): y +Starting Drupal installation. This takes a while. Consider using the --notify global option. +Installation complete. User name: admin User password: arbZJekcqh +Congratulations, you installed Drupal! ``` -これで、`LAGOON_ROUTE`で定義されたURLにアクセスして、新鮮できれいにインストールされたDrupalを見ることができます - おめでとうございます！ +これで`LAGOON_ROUTE`で定義されたURLにアクセスすると、新しくクリーンにインストールされたDrupalが表示されるはずです - おめでとうございます！ ### 既存のデータベースダンプのインポート -既に存在するDrupalサイトがある場合、そのデータベースをローカルサイトにインポートしたくなるでしょう。データベースダンプを作成する方法は多数存在し、現在のホスティングプロバイダーによります。 Drushがインストールされている場合、以下のように使用できます。 +既存のDrupalサイトがある場合、そのデータベースをローカルサイトにインポートしたいでしょう。データベースダンプを作成する方法は多数ありますが、現在のホスティングプロバイダにDrushがインストールされている場合は、以下のように使用できます： ```bash title="drush sql-dump" [your-existing-site]$ drush sql-dump --result-file=dump.sql -データベースのダンプがdump.sqlに保存されました。[成功] +Database dump saved to dump.sql [success] ``` -これで、あなたの全データベースを含む`dump.sql`ファイルが作成されました。 -このファイルをローカルのGitリポジトリにコピーし、CLIに接続すると、その中にファイルが表示されます。 +これで、データベース全体を含むdump.sqlファイルができました。このファイルをローカルのGitリポジトリにコピーし、CLIに接続すると、そこにファイルが表示されるはずです： -```bash title="here's our dump file" +```bash title="dump file" [drupal-example] docker-compose exec cli bash [drupal-example]cli-drupal:/app$ ls -l dump.sql -rw-r--r-- 1 root root 5281 Dec 19 12:46 dump.sql ``` -現在のデータベースをドロップした後、ダンプをインポートできます(まだCLIに接続したままです): +これで、現在のデータベースを削除した後にダンプをインポートできます（まだcliに接続したままです）： ```bash title="dump existing db and import dump file" [drupal-example]cli-drupal:/app$ drush sql-drop -本当にデータベースdrupalのすべてのテーブルをドロップしますか？ (y/n): y +Do you really want to drop all tables in the database drupal? (y/n): y [drupal-example]cli-drupal:/app$ drush sql-cli < dump.sql ``` ### Drupalファイルディレクトリ -Drupalサイトには、ファイルディレクトリも含まれます。既存のサイトからファイルを移行するには、ファイルを適切なフォルダに追加するだけです(おそらく`web/sites/default/files`、`sites/default/files`など)。あなたが何を設定したかを覚えておいてください。 webroot - すべてのプロジェクトで同じではないかもしれません。 +Drupalサイトにはファイルディレクトリも含まれます。既存のサイトからファイルを移行するには、正しいフォルダ（おそらく`web/sites/default/files`、`sites/default/files`、または類似のもの）にファイルを追加するだけです。ウェブルートとして設定したものを覚えておいてください - プロジェクトによって異なる場合があります。 ## デプロイ -このガイドのすべてを行い、あなたのamazee.io管理者がすべてを設定した場合、あなたのサイトをデプロイする準備が整いました！ +このガイドの全ての手順を完了し、Lagoon管理者が全てを設定していれば、サイトをデプロイする準備が整いました！ -Drupalサイトをデプロイする場合は、[このデプロイガイドを参照してください](../applications/drupal/first-deployment-of-drupal.md)。 +Drupalサイトをデプロイする場合は、[このデプロイガイド](../applications/drupal/first-deployment-of-drupal.md)を参照してください。 -それ以外の全てのデプロイについては、[このデプロイガイドを参照してください](../using-lagoon-the-basics/first-deployment.md)。 +それ以外の全てのデプロイについては、[このデプロイガイド](../using-lagoon-the-basics/first-deployment.md)を参照してください。 diff --git a/mkdocs.yml b/mkdocs.yml index f951cdfde7..3dbd6aea35 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -280,8 +280,8 @@ plugins: Base Images: ベースイメージ Workflows: ワークフロー Feature Flags: フィーチャーフラグ - Lagoonizing: Lagoon化 - Lagoonizing Your Existing Site: 既存サイトのLagoon化 + Lagoonizing: Lagoonizing + Lagoonizing Your Existing Site: 既存サイトのLagoonizing Docker Images: Dockerイメージ Configuring Applications: アプリケーションの設定 Options: オプション