diff --git a/docs/README.ja.ja.md b/docs/README.ja.ja.md new file mode 100644 index 0000000000..ec036e506b --- /dev/null +++ b/docs/README.ja.ja.md @@ -0,0 +1,11 @@ +Translation request timed out. Translation request timed out. DrupalをDockerで動作させるシステムは存在しますが、ローカルとプロダクションで正確に同じイメージとサービスをテストを許可するものは何もありませんでした。 + +Lagoonは2017年に誕生し、それ以来、プロダクションでDockerを動作させるシステムに進化しました。Lagoonは、我々の第3世代のホスティングプラットフォームを、最先端の全Dockerベースのシステムに置き換えました。 + +### オープンソース + +amazee.ioでは、オープンソースを信じています。Drupalのようなオープンソースコードが専有的なホスティングプラットフォームでホストされていることは常に我々にとって問題でした。ホスティング会社の力と成功は、単にデプロイメントシステムやサービスの設定だけではありません。それはプラットフォームを動かす人々と知識です。 プロセス、スキル、予期しない状況に対応する能力、そして最後に忘れてはならないのは、彼らがクライアントに提供するサポートです。 + +### ライセンス + +Lagoonは、[`Apache 2.0 ライセンス`](https://github.com/uselagoon/lagoon/blob/main/LICENSE)の下で利用可能です。 \ No newline at end of file diff --git a/docs/README.ja.md b/docs/README.ja.md index 12a3753bef..dab7f1e82a 100644 --- a/docs/README.ja.md +++ b/docs/README.ja.md @@ -1,129 +1,51 @@ -# Lagoon - - +# ラグーン ![](./lagoon-logo.png) +## ラグーン - Kubernetes向けのオープンソースアプリケーションデリバリープラットフォーム +ラグーンは開発者が夢見るものを提供します。それは開発者がローカル環境と本番環境でまったく同じコードを実行することを可能にするシステムです。同じDockerイメージ、同じサービス設定、そして同じコード。 -## Lagoon - Kubernetes用オープンソースアプリケーションデリバリープラットフォーム - - - -Lagoonは開発者が夢見るものを提供します。それは、開発者が自分のローカル環境と本番環境で全く同じコードを実行できるシステムです。同じDockerイメージ、同じサービス設定、そして同じコード。 - - - -## どこから始めればよいですか？ - - - -Lagoonを使用してウェブサイトやアプリケーションをホストしたい場合は、[Using Lagoon - The Basics](using-lagoon-the-basics/index.md)にアクセスしてください。 - - - -Lagoonの機能をより深く理解したい場合は、[Using Lagoon - Advanced](using-lagoon-advanced/index.md)にアクセスしてください。 - - - -Lagoonの仕組みについて理解するには、[Lagoon Concepts - The Basics](concepts-basics/index.md)をチェックしてください。 - - - -さらに深い理解を求めるなら、[Lagoon Concepts - Advanced](concepts-advanced/index.md)をご覧ください。 - - - -Lagoonの開発に参加したい場合（機能追加やバグ修正など）、[Developing Lagoon](contributing-to-lagoon/developing-lagoon.md)を参照してください。 - - - -## TL;DR: Lagoonの動作方法 - - - -1. 開発者はYAMLファイル内で必要なサービスを定義・設定します。 - -2. 満足したら、そのコードをGitにプッシュします。 - -3. LagoonはYAMLファイルを解析し、追加で必要な設定を加えます。 - -4. Lagoonは必要なDockerイメージをビルドします。 - -5. LagoonはそれらをDockerレジストリにプッシュします。 - -6. LagoonはKubernetes内で必要なリソースを作成します。 - -7. Lagoonはコンテナのデプロイを監視します。 +## どこから始めればいいですか？ -8. すべてが完了したら、Lagoonは開発者にSlack、メール、ウェブサイトなど様々な方法で通知します。 +あなたがラグーンを使用してウェブサイトやアプリケーションをホストしたい場合は、[ラグーンの基本的な使い方](using-lagoon-the-basics/index.md)を参照してください。 +ラグーンの機能についてより深く理解するためには、[ラグーンの高度な使い方](using-lagoon-advanced/index.md)をご覧ください。 +ラグーンの仕組みを理解するためには、[ラグーンの概念 - 基本](concepts-basics/index.md)をチェックしてください。 -## ヘルプ? +そして、より深い理解のために、[ラグーンの概念 - 高度](concepts-advanced/index.md)をご覧ください。 +あなたがラグーンを開発したい（機能を追加、バグを修正）場合は、[ラグーンの開発](contributing-to-lagoon/developing-lagoon.md)をご覧ください。 +## TL;DR: ラグーンの仕組み -質問やアイデアがありますか？メンテーナーや貢献者と交流しましょう。 - - - -Lagoon Discordでチャットしてください: [https://discord.gg/te5hHe95JE](https://discord.gg/te5hHe95JE) - - - -## Lagoonについてのいくつかのこと - - - -1. **Lagoonはマイクロサービスベースです**。デプロイとビルドのワークフローは非常に複雑です。複数のバージョン管理ソース、複数のクラスター、複数の通知システムが存在します。各デプロイはユニークで、数秒から数時間かかることもあります。柔軟性と堅牢性を念頭に置いて構築されています。マイクロサービスはメッセージングシステムを通じて通信します。これにより、個々のサービスのスケールアップとスケールダウンが可能になります。また、個別のサービスのダウンタイムを乗り切ることができます。さらに、新しいLagoonの部分を本番環境で他の部分に影響を与えずに試すことができます。 - -2. **Lagoonは多くのプログラミング言語を使用しています**。各プログラミング言語には特定の強みがあります。どの言語が各サービスに最も適しているかを判断しようとしています。現在、Lagoonの多くはNode.jsで構築されています。これはNode.jsを最初に使用し始めたからだけでなく、Node.jsがWebhookやタスクの非同期処理を可能にするからです。サービスの一部のプログラミング言語を変更することも検討しています。これはマイクロサービスの素晴らしいところです！他のプラットフォーム部分に影響を与えることなく、単一のサービスを他の言語に置き換えることができます。 - -3. **LagoonはDrupal専用ではありません**。すべてのものは任意のDockerイメージを実行できるように構築されています。Drupal用の既存のDockerイメージやDrushのようなDrupal特有のツールのサポートもありますが、それだけです！ - -4. **LagoonはDevOpsです**。開発者が必要なサービスを定義し、必要に応じてカスタマイズできるようにします。これは正しい方法ではなく、開発者に過剰な権限を与えてしまうと考えるかもしれません。私たちはシステムエンジニアとして、開発者をエンパワーメントする必要があると考えています。もし開発者がローカルでサービスを定義し、テストできるようにすれば、彼ら自身でバグや誤りを見つけることができます。 - -5. **LagoonはDockerとKubernetes上で動作します**。（これは当然ですよね？） - -6. **Lagoonは完全にローカルで開発・テスト可能です**。 - -7. **Lagoonは完全に統合テストされています**。これは、Git webhookの受信からDockerコンテナへのデプロイまでの全プロセスをテストできることを意味します。同じGitハッシュがクラスター内にデプロイされます。 - -8. **最も重要なこと: 継続的な作業中であること**。まだ完了していません。amazee.ioでは、ホスティングコミュニティとして協力し、コードを共有することが必要だと考えています。 - - - -Lagoonのインフラストラクチャとサービスがどのように連携しているかを理解してほしいと思っています。以下はそのスキーマです（少し古いものですが、最近追加されたサービスやKubernetesについては含まれていませんので、更新に取り組んでいます！）：[Lucid Chart](https://lucid.app/documents/view/cb441054-e04a-4389-b98b-c75bcda8ea0d) ‌ - +1. 開発者は必要なサービスをYAMLファイル内で定義し、設定します。 +2. 満足したら、コードをGitにプッシュします。 +3. ラグーンはYAMLファイルを解析し、必要な追加設定を追加します。 +4. ラグーンは必要なDockerイメージをビルドします。 +5. Translation request timed out. Lagoonは主にNode.jsで構築されています。これは最初にNode.jsを使い始めたからだけでなく、Node.jsがwebhooks、タスクなどの非同期処理を可能にするからです。一部のサービスのプログラミング言語を変更することを考えています。これがマイクロサービスの素晴らしいところです！他のプラットフォームの部分を心配することなく、一つのサービスを別の言語で置き換えることができます。 +3. **LagoonはDrupal特有のものではありません**。すべてが任意のDockerイメージを実行できるように構築されています。Drupal用の既存のDockerイメージがあり、DrushのようなDrupal特有のツールもサポートしています。しかし、それだけです！ +4. **LagoonはDevOpsです**。開発者が必要なサービスを定義し、必要に応じてカスタマイズすることができます。これが正しい方法でないと思うかもしれませんし、開発者にあまりにも多くの権限を与えていると思うかもしれません。しかし、私たちはシステムエンジニアとして、開発者を強化する必要があると考えています。開発者がローカルでサービスを定義し、それらをローカルでテストすることを許せば、彼ら自身がバグやミスを見つけるでしょう。 +5. **LagoonはDockerとKubernetes上で動作します。** \(それは明らかですよね?\) +6. **Lagoonは完全にローカルで開発・テストが可能です。** +7. **Lagoonは完全に統合テストされています**。これは私たちが 全プロセスをテストできます。Gitウェブフックの受信からDockerコンテナへのデプロイまで、同じGitハッシュがクラスタにデプロイされます。 +8. **最も重要な点: これは進行中の作業です**。まだ完了していません。amazee.ioでは、ホスティングコミュニティとして、可能な限りコードを共有し、協力して作業を進める必要があると考えています。 +私たちはあなたがLagoonのインフラストラクチャとサービスがどのように連携して動作するかを理解することを望んでいます。ここにスキーマがあります（少し古く、最近追加したサービスやKubernetesをカバーしていないので、更新作業中です！）：[Lucid Chart](https://lucid.app/documents/view/cb441054-e04a-4389-b98b-c75bcda8ea0d) ‌ ## Lagoonの歴史 +説明したように、Lagoonは夢が実現したものです。amazee.ioでは、Drupalを8年以上ホストしてきました。これは私たちのホスティングプラットフォームの4回目の大きな改訂です。3回目の改訂はPuppetとAnsibleを中心に構築されました。プラットフォームの各部分は全て設定管理で行われました。これにより新しいサーバーの設定が非常に速くできましたが、同時に開発者のカスタマイズの余地が不足していました。私たちはいくつかのカスタマイズを実装しましたが、すでにDockerを本番環境で使用していました。しかし、私たちは決して それに完全に満足していました。我々は、既存のプラットフォームだけでは足りないと気づきました。分離型Drupalの台頭、サーバーサイドでのNode.jsの動作要求、Elasticsearchへの要望、異なるSolrバージョンなど、我々はもっと進める必要がありました。 +同時に、私たちは長年にわたり、ローカル開発のためにDockerを使用してきました。プロダクションで全てをDockerで行うというのは常に考えていました。唯一の問題は、ローカル開発とプロダクション環境間の接続でした。他にも、プロダクションでDrupalをDockerで動作させるシステムが存在します。しかし、ローカルとプロダクションで正確に同じイメージとサービスをテストすることを許可するものは何もありませんでした。 -前述のように、Lagoonは夢の実現です。amazee.ioでは8年以上Drupalをホスティングしてきました。これは私たちのホスティングプラットフォームの第4世代です。第3世代はPuppetとAnsibleを中心に構築されました。プラットフォームのすべての部分は構成管理によって行われました。これにより、新しいサーバーのセットアップが非常に迅速に行えましたが、同時に開発者にとってのカスタマイズ性が欠けていました。少しはDockerを使用して本番環境でのカスタマイズ性を実現しましたが、完全には満足できませんでした。我々の既存のプラットフォームでは不十分だと感じました。デカップルDrupalの台頭に伴い、サーバーサイドでのNode.jsの実行、Elasticsearchの要求、異なるSolrバージョンなど、より多くのことを行う必要がありました。 ‌ - - - -同時に、私たちはローカル開発にDockerを何年も使用してきました。Dockerを本番環境ですべてに使用するというアイデアは常にありました。唯一の問題は、ローカル開発環境と本番環境との間の接続でした。本番環境でDockerを使用してDrupalを実行できるシステムは他にもあります。しかし、同じイメージとサービスをローカルと本番環境でテストできるものはありませんでした。 - - - -Lagoonは2017年に誕生しました。それ以来、Dockerを本番環境で実行するシステムへと発展してきました。Lagoonは第3世代のホスティングプラットフォームに代わり、すべてDockerベースの最新システムになりました。 - - +Lagoonは2017年に誕生しました。それ以来、プロダクションでDockerを動作させるシステムに発展しました。Lagoonは、我々の第3世代のホスティングプラットフォームを、最先端の全Dockerベースのシステムに置き換えました。 ### オープンソース - - -amazee.ioでは、オープンソースが重要だと信じています。オープンソースコードであるDrupalがプロプライエタリなホスティングプラットフォームでホストされていることには常に悩まされていました。ホスティング会社の強みと成功は、単なるデプロイシステムやサービス設定だけではありません。プラットフォームを運営する人々とその知識によるものです。プロセス、スキル、予期しない状況に対処する能力、そして最後にですが重要なこととして、クライアントに提供するサポートです。 - - +amazee.ioでは、オープンソースを信じています。Drupalのようなオープンソースコードが独占的なホスティングプラットフォームでホストされていることは常に我々にとって問題でした。ホスティング会社の強さと成功は、単にデプロイメントシステムやサービスの設定だけではありません。それはプラットフォームを動かす人々と知識です。 プロセス、スキル、予期しない状況に対応する能力、そして最後に忘れてはならないのは、彼らがクライアントに提供するサポートです。 ### ライセンス - - -Lagoonは[`an Apache 2.0 License`](https://github.com/uselagoon/lagoon/blob/main/LICENSE)の下で提供されています。 \ No newline at end of file +Lagoonは、[`Apache 2.0 ライセンス`](https://github.com/uselagoon/lagoon/blob/main/LICENSE)の下で利用可能です。 \ No newline at end of file diff --git a/docs/applications/drupal/automatic-updates.ja.md b/docs/applications/drupal/automatic-updates.ja.md new file mode 100644 index 0000000000..238159a527 --- /dev/null +++ b/docs/applications/drupal/automatic-updates.ja.md @@ -0,0 +1,20 @@ +# 自動更新 + +Lagoonは、Drupalコアやcontribの一部の更新方法と互換性のない方法でアプリケーションをデプロイします。Lagoonは不変のイメージをビルドし、不変のコンテナを稼働させることを期待しています。ランタイムでアプリケーションのコードが変更されると、以下の問題が生じる可能性があります。 + +1. コンテナはKubernetesによって自動的に管理され、いつでも移動、再起動、スケーリングが可能です。これが起こると、元のビルド済みコンテナイメージが実行され、ランタイムで発生した変更はすべて失われます。 +2. タスクやcronjobは、元のビルド済みコンテナイメージで実行され、更新されたコードにアクセスできない可能性があります。 +3. 更新にはファイルシステムへの書き込み権限が必要ですが、読み取り専用のファイルシステムを強制する環境を設定することも可能です。 +4. ベストプラクティスは、それぞれが一つのことを行う小さなコンテナをデプロイすることです。これは、典型的なDrupalプロジェクトでは、`cli`、`php`、`nginx`というコンテナがそれぞれコードのコピーを含むことを意味します。これらのコンテナのうち一つだけを更新すると、コードの不一致による問題が発生します。 + +以下の更新方法はLagoonによって無効化されています。 + +## Drupal 自動更新 + +[自動更新] (https ://www.drupal.org/project/automatic_updates) +contribモジュールは無効化されており、Drupal coreに移行する際も無効化されます。 + +## Drush + +`drush pm-install`または`drush pm-update`は、デフォルトで無効化されています。これは[amazeeio/drupal-integrations](https://github.com/amazeeio/drupal-integrations) +パッケージの一部としてです。 \ No newline at end of file diff --git a/docs/applications/drupal/drush-9.ja.md b/docs/applications/drupal/drush-9.ja.md new file mode 100644 index 0000000000..5bba755a39 --- /dev/null +++ b/docs/applications/drupal/drush-9.ja.md @@ -0,0 +1,69 @@ +--- +description: >- + ラグーンはデフォルトでDrush 8を使用します。Composerを使ってDrush 9をDrupalサイトにインストールすると、Drush 9が使用されます。 +--- + +# Drush 9 + +## エイリアス + +残念ながら、Drush 9はDrush 8が持っていたような動的なサイトエイリアスを注入する能力を提供していません。私たちはDrushチームと協力して、これを再度実装する作業を行っています。その間、Drush 9をLagoonで使用するための回避策があります。 + +### 基本的なアイデア + +Drush 9は新しいコマンド、`drush site:alias-convert`を提供します。これはDrush 8スタイルのサイトエイリアスをDrush 9のYAMLサイトエイリアススタイルに変換できます。これにより、現在Lagoonに存在するサイトエイリアスの一時的なエクスポートが作成され、`/app/drush/sites`に保存されます。これらは、`drush sa`のようなコマンドを実行する際に使用されます。 + +### 準備 + +`drush site:alias-convert`を使用するために、以下のことを行う必要があります： + +* `drush`フォルダ内の`aliases.drushrc.php`を`lagoon.aliases.drushrc.php`にリネームします。 + +### サイトエイリアスの生成 + +あなたは今、あなたのプロジェクトで以下のコマンドを実行することにより、あなたのDrushエイリアスを変換することができます。これは`cli`コンテナを使って行います： + +```bash title="サイトエイリアスの生成" +docker-compose exec cli drush site:alias-convert /app/drush/sites --yes +``` + 結果として得られるYAMLファイルをGitリポジトリにコミットすることは良い習慣で、これにより他の開発者がそれらを利用できます。 + +### サイトエイリアスの使用 + +Drush 9では、すべてのサイトエイリアスにはグループがプレフィックスとして付けられています。私たちの場合、これは `lagoon` です。以下のようにして、そのプレフィックス付きのすべてのサイトエイリアスを表示できます： + +```bash title="すべてのサイトエイリアスを表示" +drush sa --format=list +``` + +そしてそれらを使用するには： + +```bash title="Drush サイトエイリアスの使用" +drush @lagoon.main ssh +``` + +### サイトエイリアスの更新 + +Lagoonで新しい環境が作成された場合、サイトエイリアスファイルを更新するために `drush site:alias-convert` を実行できます。このコマンドを実行しても `lagoon.site.yml` が更新されない場合は、まず `lagoon.site.yml` を削除してから `drush site:alias-convert` を再実行してみてください。 + +### ローカルからリモート環境へのDrush `rsync` + +ローカル環境からリモート環境にファイルを同期したい場合は、追加のパラメータを渡す必要があります： + +```bash title="Drush rsync" +drush rsync @self:%files @lagoon.main:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX +``` + +これは、LagoonのタスクUIを使ってファイルをコピーするのではなく、一つのリモート環境から別のリモート環境に同期する場合にも適用されます。 環境。 + +たとえば、`@lagoon.main`から`@lagoon.dev`へのファイルの同期を行いたい場合に、ローカルで`drush rsync @lagoon.main @lagoon.dev`を実行し、追加のパラメーターなしでこれを実行すると、「2つのリモートエイリアスを指定できません」というエラーが発生する可能性があります。 + +これを解決するには、まず目的の環境にSSHで接続し`drush @lagoon.dev ssh`を実行し、次に上記と同様のパラメーターで`rsync`コマンドを実行します。 + +```bash title="Drush rsync" +drush rsync @lagoon.main:%files @self:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX +``` + +リモートからローカル環境へ`rsync`する場合、これは必要ありません。 + +また、私たちは[Drushのメンテナと協力して](https://github.com/drush-ops/drush/issues/3491)、これを自動的に注入する方法を見つけ出そうとしています。 \ No newline at end of file diff --git a/docs/applications/drupal/first-deployment-of-drupal.ja.md b/docs/applications/drupal/first-deployment-of-drupal.ja.md new file mode 100644 index 0000000000..7144de3d86 --- /dev/null +++ b/docs/applications/drupal/first-deployment-of-drupal.ja.md @@ -0,0 +1,144 @@ +# Drupalの初回デプロイメント + +![excited](https://i.giphy.com/media/7kVRZwYRwF1ok/giphy-downsized.gif) + +## 1. すべてが準備できていることを確認してください + +初回のデプロイメントを成功させるためには、あなたの[DrupalプロジェクトがLagoon化されている](../../using-lagoon-the-basics/setup-project.md)ことと、Lagoonでプロジェクトが設定されていることを確認してください。そうでない場合でも心配はいりません！[ステップバイステップガイド](./step-by-step-getting-drupal-ready-to-run-on-lagoon.md)を参照して作業方法を確認してください。 + +## 2. プッシュ + +Lagoonでは、デプロイするために設定されたブランチにプッシュすることで新しいデプロイメントを作成します。 + +新たにプッシュするコードがない場合でも心配はいりません、次のコマンドを実行できます。 + +```bash title="Git push" +git commit --allow-empty -m "go, go! Power Rangers!" +git push +``` + +これによりプッシュがトリガーされ、設定されたWebhookを通じてGitホスティングがこのプッシュについてLagoonに通知します。 + +すべてが正しければ、設定されたチャットシステムに通知が表示されます（これは親切なLagoon管理者によって設定されます）： + +![デプロイメント開始のSlack通知](../../images/first_deployment_slack_start.jpg) + +これは、Lagoonがあなたのコードのデプロイを開始したことを示しています。コードのサイズによりますが、 ベースとコンテナの量により、これには数秒かかります。リラックスしてお待ちください。今何が起こっているか知りたい場合は、[Lagoonのビルドとデプロイプロセス](../../concepts-basics/build-and-deploy-process.md)をご覧ください。 + +また、Lagoon UIをチェックして、任意のデプロイメントの進行状況を確認することもできます（Lagoonの管理者が情報を持っています）。 + +## 3. 失敗 + +`.lagoon.yml`で定義されたポストロールアウトタスクにより、`drush updb`や`drush cr`のようなタスクを実行したかもしれません。これらのDrushタスクは、環境内に存在しているデータベースに依存していますが、明らかにまだ存在していません。それを修正しましょう！読み進めてください。 + +## 4. ローカルデータベースをリモートのLagoon環境に同期する + +LagoonではフルのDrushサイトエイリアスをサポートしているため、ローカルデータベースをリモートのLagoon環境と同期することができます。 + +!!! 警告 + 次のステップの前に、pygmyに公開キーについて教える必要があるかもしれません。 + +`Permission denied (publickey)`のようなエラーが表示された場合は、ここに記載のドキュメンテーションをチェックしてみてください：[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) + +まず、Drushサイトエイリアスが表示されることを確認しましょう： + +```bash title="サイトエイリアスの取得" +drush sa +``` + +これにより、あなたの デプロイされた環境（`develop`にプッシュしたとします）： + +```bash title="返されたサイトエイリアス" +[drupal-example]cli-drupal:/app$ drush sa +@develop +@self +default +``` + +これにより、ローカルデータベース（Drushではサイトエイリアス`@self`で表されます）とリモートデータベース（`@develop`）を同期することができます。 + +```bash title="Drush sql-sync" +drush sql-sync @self @develop +``` + +次のような結果が表示されるはずです： + +```bash title="Drush sql-syncの結果" +[drupal-example]cli-drupal:/app$ drush sql-sync @self @develop +ssh.lagoon.amazeeio.cloud/drupalのデータが破壊され、drupalからのデータで置き換えられます。 +本当に続行しますか？ (y/n): y +ソースのデータベースダンプを開始します。 [ok] +データベースダンプは/home/drush-backups/drupal/20180227075813/drupal_20180227_075815.sql.gzに保存されました。 [success] +デスティネーションで一時ファイルディレクトリを検出します。 [ok] +drupal-example-develop@ssh.lagoon.amazeeio.cloud:/tmp/drupal_20180227_075815.sql.gzのファイルを削除し、/home/drush-backups/drupal/201802270からのデータで置き換えます。 75813/drupal_20180227_075815.sql.gz +本当に続行しますか？ (y/n): y +ソースからデスティネーションへのダンプファイルのコピー。 [ok] +デスティネーションデータベースにダンプファイルのインポートを開始します。 + +``` + +さて、再度デプロイを試してみましょう。今度は空のプッシュです： + +```bash title="Git push" +git commit --allow-empty -m "行け、行け！ パワーレンジャー！" +git push +``` + +今回はすべてがグリーンになるはずです： + +![デプロイ成功！](../../images/first_deployment_slack_success.jpg) + +通知内のリンクをクリックすると、Drupalサイトが全ての美しさでロードされるのが見えるはずです！まだ画像がない可能性がありますが、それは[ステップ6](./first-deployment-of-drupal.md#6-synchronize-local-files-to-the-remote-lagoon-environment)で対処します。 + +それでも失敗する場合は、ログリンクを確認して詳細情報を得てください。 + +## 5. ローカルファイルをリモートのLagoon環境に同期する + +おそらく推測できたでしょう：Drushでそれを行うことができます： + +```bash title="Drush rsync" +drush rsync @self:%files @develop:%files +``` + +次のような表示が出るはずです： + +```bash title="Drush rsync results" +[drupal-example]cli-drupal:/app$ drush rsync @self:%files @develop:%files +ファイルを削除します drupal-example-develop@ssh.lagoon.amazeeio.cloud:/app/web/sites/default/files内のデータを/app/web/sites/default/files/からデータで置き換えます。 +本当に続行しますか？ (y/n): y + +しかし、場合によっては、ここでのように正しく見えないことがあります： + +```bash title="Drush rsync results" +[drupal-example]cli-drupal:/app$ drush rsync @self:%files @develop:%files +あなたはdrupal-example-develop@ssh.lagoon.amazeeio.cloud:'/app/web/%files'内のファイルを削除し、'/app/web/%files'からのデータで置き換えます。 +本当に続行しますか？ (y/n): +``` + +その理由は、Drupalがファイルディレクトリのパスを解決できないからです。これはおそらく、Drupalが完全に設定されていないか、データベースが欠けているためです。回避策としては`drush rsync @self:sites/default/files @develop:sites/default/files`を使用できますが、ローカルとリモートのDrupalを実際に確認することをお勧めします（`drush status`でファイルディレクトリが正しく設定されているかどうかをテストできます）。 + +## 6. 完了しました + +Lagoonがビルドとデプロイを完了すると、チャットシステムに2回目の通知を送信します。以下のような感じです： + +![完全なデプロイメントのSlack通知。](../../images/first_deployment_slack_2nd _success.jpg) + +これには以下の情報が表示されます： + +* デプロイされたプロジェクト +* デプロイされたブランチとGit SHA +* ビルドとデプロイメントの完全なログへのリンク +* 環境にアクセスできるすべてのルート（URL）へのリンク + +以上です！それが難しすぎなければよいのですが、私たちはDevOpsを使いやすくすることを目指しています。 + +## しかし、他のブランチや本番環境はどうですか？ + +それがLagoonの美点です：まったく同じです。本番ブランチとして定義したブランチ名をプッシュすると、そのブランチがデプロイされます。 + +## 失敗？心配しないで + +デプロイメントが失敗しましたか？ああ、それは大変です！でも、私たちは助けるためにここにいます： + +1. エラー通知の中の `logs` リンクをクリックします。それは失敗が発生したデプロイメントプロセスのどこであったかを教えてくれます。 +2. それがわからない場合は、Lagoonの管理者に尋ねてみてください。彼らは助けるためにここにいます！ \ No newline at end of file diff --git a/docs/applications/drupal/index.ja.md b/docs/applications/drupal/index.ja.md new file mode 100644 index 0000000000..168ae4d837 --- /dev/null +++ b/docs/applications/drupal/index.ja.md @@ -0,0 +1,13 @@ +# Lagoon上のDrupal + +LagoonはDrupalサイトをホストするために作られました（いや、本当に、少なくとも初めはそうでした！） + +このセクションでは、Drupalで使用するためにカスタマイズされたさまざまなサービスについての詳細情報を見つけることができます。 + +## `drupal_integrations` Drupalスキャフォールディングパッケージ + +[packagist](https://packagist.org/packages/amazeeio/drupal_integrations)で利用可能な`drupal_integrations`パッケージは、Lagoonで使用するためにDrupalのcore-composer-scaffoldを拡張します。また、LagoonプロジェクトのDrushエイリアスを取得するための追加のDrushコマンド`drush la`も提供します。 + +## `lagoon-logs` Drupalモジュール + +[drupal.org](https://www.drupal.org/project/lagoon_logs)で利用可能な`lagoon_logs`モジュールは、Lagoon上のDrupalのためのゼロ設定ロギングを提供します。 \ No newline at end of file diff --git a/docs/applications/drupal/integrate-drupal-and-fastly.ja.md b/docs/applications/drupal/integrate-drupal-and-fastly.ja.md new file mode 100644 index 0000000000..fa9f4cb6ec --- /dev/null +++ b/docs/applications/drupal/integrate-drupal-and-fastly.ja.md @@ -0,0 +1,198 @@ +# DrupalとFastlyの統合 + +## 前提条件 + +* Drupal 7+ +* FastlyサービスID +* パージ権限を持つFastly APIトークン + +## URLベースのパージングを持つDrupal 7 + +1. [Fastly Drupalモジュール](https://www.drupal.org/project/fastly)をダウンロードしてインストールします。 +2. FastlyサービスIDとAPIトークンを設定します。 +3. 必要に応じてWebhooksを設定します（例えば、キャッシュパージが送信されたときにSlackにピングを送るなど）。 +4. Drupal 7ではURLベースのパージングのみが可能です（シンプルパージング）。 +5. `settings.php`でDrupalのクライアントIPを変更します： + +```php title="Drupal 7のためのsettings.phpの変更" +$conf['reverse_proxy_header'] = 'HTTP_TRUE_CLIENT_IP'; +``` + +## キャッシュタグパージングを持つDrupal 10+ + +Composerを使用してモジュールの最新バージョンを取得します： + +```bash title="Fastly Drupalモジュールと依存関係のダウンロード" +composer require drupal/fastly drupal/http_cache_control drupal/purge +``` + +次のモジュールを有効化する必要があります： + +* `fastly` +* `fastlypurger` +* `http_cache_control` (2.x) +* `purge` +* `purge_ui` (技術的にはオプションですが、本番環境で有効にしておくと非常に便利です) +* `purge_processor_lateruntime` +* `purge_processor_cron` +* `purge_queuer_coretags` +* `purge_drush` (Drを通じてパージするために便利です) Drush、ここに[コマンドのリスト](https://git.drupalcode.org/project/purge/-/blob/8.x-3.x/README.md#drush-commands)があります。 + +### DrupalのFastlyモジュールを設定する + +FastlyのサービスIDとAPIトークンを設定します。サイトIDは自動的に生成されます。ランタイム環境変数を使用するか、`/admin/config/services/fastly`で見つけることができる設定フォームを編集することができます： + +* `FASTLY_API_TOKEN` +* `FASTLY_API_SERVICE` + +#### パージオプションを設定する + +* キャッシュタグのハッシュ長：4 +* パージ方法：ソフトパージを使用する + +ほとんどのサイトでは`4`文字のキャッシュタグが十分で、_数百万_のエンティティを持つサイトでは`5`文字のキャッシュタグが適している可能性があります（キャッシュタグの衝突を減らすため）。 + +!!! 注意 + ソフトパージングを使用するべきです。これは、Fastlyのオブジェクトが完全に追い出されるのではなく、古いものとしてマークされ、元の場所がダウンしている場合に使用できるようになることを意味します（[古くなったものを提供する](https://developer.fastly.com/solutions/tutorials/stale/)機能と共に）。 + +![パージング用のFastly管理UI。キャッシュタグの長さとソフトパージの使用に関する設定オプションを示しています](../images/fastly-cachetag.png) + +#### 古いコンテンツのオプションを設定する + +サイトに適したオプションを設定します。最小1時間（` 3600`）、最大1週間（`604800`）。一般的には以下のような設定が適しています： + +1. 再検証時にステール - オン、`14440`秒 +2. エラー時にステール - オン、`604800`秒 + +![Fastly管理者UIのステール設定](../images/fastly-swr.png) + +必要に応じてウェブフックを設定します（キャッシュパージが送信されたときに例えばSlackにピングを送ることができます）。 + +![Fastly管理者UIのウェブフック設定](../images/fastly-webhook.png) + +### Purgeモジュールの設定 + +パージページ`/admin/config/development/performance/purge`を訪れます。 + +以下のオプションを設定します： + +#### キャッシュ無効化 + +* Drupal Origin: タグ +* Fastly: E、タグ、URL + +![パージ管理者UIのパージャー設定](../images/fastly-invalidate.png) + +#### キュー + +* キューワー：コアタグキューワー、パージブロック（複数） +* キュー：データベース +* プロセッサ：コアプロセッサ、レイトランタイムプロセッサ、パージブロック（複数） + +![パージ管理者UIのキュー設定](../images/fastly-queue.png) + +これは、Drupalの組み込みコアタグキューワー（キューにタグを追加）を使用し、キューはデータベース（デフォルト）に保存され、キューは次のものによって処理されることを意味します。 + +* Cronプロセッサ +* レイトランタイムプロセッサ + +Cronプロセッサが動作するためには、Cronが動作することを確認する必要があります。 あなたのサイトで実行します。理想的には毎分です。`cli`ポッドで手動で実行して、`purge_processor_cron_cron()`がエラーなく実行されていることを確認できます。 + +```bash title="cronの開始" +[drupal8]production@cli-drupal:/app$ drush cron -v +... +[notice] purge_processor_cron_cron()の実行を開始、node_cron()の実行は21.16msかかりました。 +``` + +`遅延ランタイムプロセッサ`は各ページ読み込みの`hook_exit()`で実行され、これはキューに入ってくるほぼ同時にパージを処理するのに有用です。 + +両方を持つことで、パージができるだけ早く行われることを保証します。 + +### 最適なキャッシュヘッダー設定 + +初期設定では、DrupalはブラウザとFastlyで異なるキャッシュ寿命を設定する力を持っていません。したがって、Drupalで長いキャッシュ寿命を設定すると、ブラウザがページをキャッシュしている場合、エンドユーザーはそれらを見ることができません。[HTTP Cache Control](https://www.drupal.org/project/http_cache_control)モジュールの`2.x`バージョンをインストールすると、キャッシュの何がどれだけの期間有効であるかについて、より多くの柔軟性を得ることができます。 + +ほとんどのサイトでは、適切なデフォルト設定は次のとおりです。 + +* 共有キャッシュの最大寿命：1ヶ月 +* ブラウザキャッシュの最大寿命：10分 +* 404キャッシュの最大寿命：15分 分 +* 302キャッシュの最大寿命：1時間 +* 301キャッシュの最大寿命：1時間 +* 5xxキャッシュの最大寿命：キャッシュなし + +!!! 注意 + これは、あなたのサイトがページ上に存在するすべてのコンテンツを表現する正確なキャッシュタグを持っていることに依存しています。 + +### 真のクライアントIP + +私たちはFastlyを設定して、実際のクライアントIPをHTTPヘッダー`True-Client-IP`で返すようにしています。`settings.php`で以下の変更を行うことで、Drupalがこのヘッダーを尊重するように設定することができます： + +```php title="Drupal < 8.7.0用のsettings.phpの変更" +$settings['reverse_proxy'] = TRUE; +$settings['reverse_proxy_header'] = 'HTTP_TRUE_CLIENT_IP'; +``` + +しかし、Drupal 8.7.0では、[この機能を削除する変更がありました](https://www.drupal.org/node/3030558)。以下のスニペットを使用して同じ目標を達成することができます + +```php title="Drupal >= 8.7.0用のsettings.phpの変更" +/** + * DrupalにTrue-Client-IP HTTPヘッダーを使用するよう指示します。 + */ +if (isset($_SERVER['HTTP_TRUE_CLIENT_IP'])) { + $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_TRUE_CLIENT_IP']; +} +``` + +### Drush統合 + +```php title="settings.php" + fastly: + fastly:purge:all (fpall) サービス全体をパージ。 + fastly:purge:key (fpkey) キーでキャッシュをパージする。 + fastly:purge:url (fpurl) URLでキャッシュをパージする。 + +## cURLを使用してFastlyキャッシュヘッダーを表示する + +この関数を使用してください：（LinuxとMac OSXで動作します） + +```bash title="cURL function" +function curlf() { curl -sLIXGET -H 'Fastly-Debug:1' "$@" | grep -iE 'X-Cache|Cache-Control|Set-Cookie|X-Varnish|X-Hits|Vary|Fastly-Debug|X-Served|surrogate-control|surrogate-key' } +``` + +```bash title="Using cURL" +$ curlf https://www.example-site-fastly.com +cache-control: max-age=601, public, s-maxage=2764800 +surrogate-control: max-age=2764800, public, stale-while-revalidate=3600, stale-if-error=3600 +fastly-debug-path: (D cache-wlg10427-WLG 1612906144) (F cache-wlg10426-WLG 1612906141) (D cache-fra19179-FRA 1612906141) (F cache-fra19122-FRA 1612906141) +fastly-debug-ttl: (H cache-wlg10427-WLG - - 3) (M cache-fra19179-FRA - - 0) +fastly-debug-digest: 1118d9fefc8a514ca49d49cb6ece04649e1acf1663398212650bb462ba84c381 +x-served-by: cache-fra19179-FRA, cache-wlg10427-WLG +x-cache: MISS, HIT +x-cache-hits: 0, 1 +vary: Cookie, Accept-Encoding +``` + +上記のヘッダーから次のことが分かります： + +* HTML ページはキャッシュ可能です +* ブラウザはページを601秒間キャッシュします +* Fastlyはページを32日間（`2764800`秒）キャッシュします +* 階層型キャッシュが適用されています（エッジPoPはウェリントン、シールドPoPはフランスに位置しています） +* HTMLページはエッジPoPでキャッシュヒットしました + +### Fastlyに手動でパージリクエストを送信する + +特定のページを手動でキャッシュから削除したい場合、方法があります。 + +```bash title="単一のURLでFastlyをパージ" +curl -Ssi -XPURGE -H 'Fastly-Soft-Purge:1' -H "Fastly-Key:$FASTLY_API_TOKEN" https://www.example.com/subpage +``` + +キャッシュタグでパージすることもできます： + +```bash title="キャッシュタグでFastlyをパージ" +curl -XPOST -H 'Fastly-Soft-Purge:1' -H "Fastly-Key:$FASTLY_API_TOKEN" https://api.fastly.com/service/$FASTLY_API_SERVICE/purge/ +``` + +また、これを少し楽にするために[Fastly CLI](https://github.com/fastly/cli)を使用することもできます。 \ No newline at end of file diff --git a/docs/applications/drupal/phpunit-and-phpstorm.ja.md b/docs/applications/drupal/phpunit-and-phpstorm.ja.md new file mode 100644 index 0000000000..ca56737a4b --- /dev/null +++ b/docs/applications/drupal/phpunit-and-phpstorm.ja.md @@ -0,0 +1,91 @@ +# PHPUnit と PhpStorm + +!!! 注意 + このドキュメントでは、以下を前提としています： + + - Dockerを使用しています。 + + - [`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)ファイルを含む標準的なAmazee/Lagoonプロジェクトを使用しています。 + + - Macを使用しています - 他のオペレーティングシステムでも動作するはずですが、フォルダ構造や一部の設定が異なる場合があります。 + +## プロジェクトの設定 + +1. `/core/phpunit.xml.dist` ファイルを `/core/phpunit.xml` に複製します。 +2. `/core/phpunit.xml` を編集し、以下の変数を入力します： + + * **SIMPLETEST\_DB**: `mysql://drupal:drupal@mariadb:3306/drupal#db` + * **SIMPLETEST\_BASE\_URL**: `` + +## PhpStormの設定 + +### Dockerの設定 + +1. PhpStormで、**ファイル > 設定 > ビルド、実行、デプロイ > Docker**に移動します。 +2. `+`をクリックします。 +3. `Docker for Mac`を選択します。 + +![Dockerの設定](../../images/1-docker-setup.png) + +### CLIインタープリタの設定 + +**新しいCLIインタープリタを追加：** + +1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP**に移動します。 +2. `...`をクリックし、次に`+`をクリックします。 +3. 次に、Docker、vagrantなどから新しいCLIインタープリタを追加を選択します。 +4. 次の設定を使用します： + * サーバー: `` * 設定ファイル: `./docker-compose.yml` +* サービス: `cli` +* ライフサイクル: `既存のコンテナに接続 ('docker-compose exec')` +5. パスのマッピング: + * ローカルパス: `` + * リモートパス: `/app` + +![新しいCLIインタープリタの追加:](../../images/2-cli-interpreter.png) + +### **リモートインタープリタの設定** + +**リモートインタープリタの追加:** + +1. PhpStormで、**ファイル > 設定 > 言語 & フレームワーク > PHP > テストフレームワーク**に移動します。 +2. `+`をクリックして、`PHPUnit by Remote Interpreter`を選択します。 +3. 次の設定を使用します: + * CLIインタープリタ: `` + * パスマッピング: ` -> /app` + * PHPUnit: `Use Composer autoloader` + * スクリプトへのパス: `/app/vendor/autoload.php` + * デフォルトの設定ファイル: `/app/web/core/phpunit.xml` + +![リモートインタープリタの追加](../../images/3-remote-interpreter-setup.png) + +#### ランナーテンプレートの設定/構成 + +1. **ランナーの設定:** + 1. PhpStormで、**実行 > 設定の編集... > テンプレート > PHPUnit**に移動します。 + 2. 次の設定を使用します: + + 1. テストスコープ: `設定ファイルで定義されている` + + 2. 通訳者: `` + +![ランナーの設定](../../images/4-configure-runner.png) + +!!! 注意 + Macを使用していない場合、この内容は異なる場合があります。 + +## 最終チェック + +### テストを実行する前に行う最終チェック + +1. プロジェクトが起動し、稼働していること： `$ docker-compose up -d` +2. プロジェクトがエラーなく動作していること、サイトを訪れてすべてが期待通りに動作していることを確認する - これは100％必要ではありませんが、正常に動作していることを知っておくとよいでしょう。 +3. テストを実行する準備が整っているはずです！ + +## 実行の準備完了 + +上記の設定を行ったら、実行したいテストに移動し、緑色の矢印を押すだけで簡単に実行できるはずです！ + +このボタンを押すと、PhpStormはDockerを使用してCLIコンテナに入り、設定に基づいてPHPUnitの実行を開始します。 + +![これが実際の動作です、どうぞご覧ください!!](../../images/5-going-green-1-.gif) \ No newline at end of file diff --git a/docs/applications/drupal/services/README.ja.md b/docs/applications/drupal/services/README.ja.md new file mode 100644 index 0000000000..1a3e881d94 --- /dev/null +++ b/docs/applications/drupal/services/README.ja.md @@ -0,0 +1,25 @@ +# サービス + +## MariaDBは、オープンソースのMySQLの後継者です + +[DrupalとMariaDBについて学ぶ](mariadb.md) + +[プレーンなMariaDBイメージに関するドキュメンテーション](../../../docker-images/mariadb.md)（このMariaDB-Drupalイメージはこれをベースに作成されています）。 + +## Redisは高速なオープンソースのインメモリキーバリューデータストアで、データベース、キャッシュ、メッセージブローカー、キューとして利用できます + +[DrupalとRedisについて学ぶ。](../services/redis.md) + +[Redis-persistentイメージに関するドキュメンテーション。](../../../docker-images/redis.md) + +## Solrはオープンソースの検索プラットフォームです + +[DrupalとSolrについて学ぶ。](../services/solr.md) + +[プレーンなSolrイメージに関するドキュメンテーション](../../../docker-images/solr.md) \(このSolr-Drupalイメージはこれをベースに作成されています\)。 + +## Varnishは、ウェブサイトの速度を向上させるための強力なオープンソースのHTTPエンジンおよび逆HTTPプロキシです + +[DrupalとVarnishについて学ぶ](../services/varnish.md) + +[プレーンなVarnishイメージに関するドキュメンテーション](../../../docker-images/varnish.md) \(このVarnish-Drupalイメージはこれをベースに作成されています\)。 \ No newline at end of file diff --git a/docs/applications/drupal/services/mariadb.ja.md b/docs/applications/drupal/services/mariadb.ja.md new file mode 100644 index 0000000000..290963677e --- /dev/null +++ b/docs/applications/drupal/services/mariadb.ja.md @@ -0,0 +1,73 @@ +--- +description: MariaDBは、オープンソースのMySQLの後継者です。 +--- + +# MariaDB-Drupal + +Lagoonの `mariadb-drupal` Dockerイメージ [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb-drupal/10.5.Dockerfile) は、LagoonのDrupalプロジェクト内で使用するためにカスタマイズされた [`mariadb`](../../../docker-images/mariadb.md) イメージです。 `mariadb` イメージとの違いは、初期データベースのセットアップのみで、これはいくつかの環境変数によって行われます: + +| 環境変数 | デフォルト | 説明 | +| :--- | :--- | :--- | +| `MARIADB_DATABASE` | drupal | 起動時に作成されるDrupalデータベース。 | +| `MARIADB_USER` | drupal | 起動時に作成されるデフォルトのユーザー。 | +| `MARIADB_PASSWORD` | drupal | 起動時に作成されるデフォルトのユーザーのパスワード。 | + +`LAGOON_ENVIRONMENT_TYPE` 変数が `production` に設定されている場合、パフォーマンスは `MARIADB_INNODB_BUFFER_POOL_SIZE=1024` および `MARIADB_INNODB_LOG_FILE_SIZE=256` を使用してそれに応じて設定されます。 + +## その他のMariaDB [ログ](../../../logging/logging.md) + +開発の過程で、クエリログまたはスロークエリログを有効にする必要があるかもしれません。そうするためには、環境変数 `MARIADB_LOG_SLOW` または `MARIADB_LOG_QUERIES` を設定します。これは ` `docker-compose.yml`. + +## ホストからMySQLコンテナへの接続 + +Dockerコンテナ内のMySQLデータベースに[Sequel Pro](http://www.sequelpro.com/)、[MySQL Workbench](http://www.mysql.com/products/workbench/)、[HeidiSQL](http://www.heidisql.com/)、[DBeaver](http://dbeaver.jkiss.org/)、`mysql-cli`などの外部ツールから接続したい場合、IPアドレスとポート情報を取得する方法をここに示します。 + +### コンテナから公開MySQLポートを取得する + +デフォルトでは、Dockerは各コンテナ開始時にMySQLの公開ポートをランダムに割り当てます。これはポートの衝突を防ぐために行われます。 + +`docker`を使って公開ポートを取得するには： + +実行：`docker port [container_name]`。 + +```text title="ポートを取得する" +$ docker port drupal_example_mariadb_1 +3306/tcp -> 0.0.0.0:32797 +``` + +または、Drupalリポジトリ内で`docker-compose`を使って： + +実行：`docker-compose port [service_name] [internal_port]`。 + +```bash title="ポートを設定する" +docker-compose port mariadb 3306 +0.0.0.0:32797 +``` + +## 静的ポートの設定（非推奨） + +開発中に外部のデータベースツールを使用している場合、MySQL接続ポートを常に確認し設定するのは面倒になるかもしれません。 + +静的ポートを設定するには、編集してください あなたの `docker-compose.yml` でのサービス定義。 + +```yaml title="docker-compose.yml" + mariadb: + ... + ports: + - "33772:3306" # ポート3306をホストポートの33772で公開します。これを行うことで、ポートの衝突を管理する責任があなたにあります。 +``` + +!!! 警告 + 静的ポートを設定すると、ポートの衝突を管理する責任があなたにあります。 + +### MySQLへの接続 + +これらの詳細を使用して、お好みのデータベース管理ツールに接続できます。 + +| | Linux | OS X | +| :--- | :--- | :--- | +| IP/ホスト | コンテナからのIP | `docker.amazee.io` | +| ポート | コンテナから公開されたポート | コンテナから公開されたポート | +| ユーザー名 | `drupal` | `drupal` | +| パスワード | `drupal` | `drupal` | +| データベース | `drupal` | `drupal` | \ No newline at end of file diff --git a/docs/applications/drupal/services/nginx.ja.md b/docs/applications/drupal/services/nginx.ja.md new file mode 100644 index 0000000000..64e01bfeb2 --- /dev/null +++ b/docs/applications/drupal/services/nginx.ja.md @@ -0,0 +1,92 @@ +# NGINX-Drupal + +[Lagoonの`nginx-drupal` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/nginx-drupal/Dockerfile)。Drupalと連携するように最適化されています。[Lagoonの`nginx`イメージ](../../../docker-images/nginx.md)に基づいています。 + +## ラグーンの適応 + +このイメージは、Lagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に適応されるため、このイメージはランダムなユーザーで動作します。 +* `drupal.conf`の設定ファイルをできるだけクリーンでカスタマイズ可能に保つために、ファイルの主要なセクション（`server`、`location /`、`location @drupal`、`location @php`）に`include`指示を追加しました。 +* [`Drupal.conf`カスタマイズ](#drupalconf-customization)のセクションでさらなる情報を提供します。 + +## 含まれるDrupal設定（`drupal.conf`） + +このイメージには、Drupal 7, 8, 9の完全なNGINX作業設定が含まれています。いくつかの追加機能も含まれています： + +* [`humanstxt` Drupalモジュール](https://www.drupal.org/project/humanstxt)のサポート。 +* [`robotstxt` Drupalモジュール](https://www.drupal.org/project/ robotstxt)。 +* ローカル開発用の`vagrant`ディレクトリへのアクセスを禁止します。 + +## `Drupal.conf`のカスタマイズ + +`drupal.conf`ファイルは、Drupal用に最適化された`nginx`設定ファイルのカスタマイズ版です。顧客はそれをカスタマイズするための異なる方法を持っています： + +* _それを修正する_ \(エラーの場合、サポートが困難\)。 +* `*.conf`ファイルを通じた組み込みのカスタマイズを使用。 + +`drupal.conf`ファイルはいくつかのセクションに分割されています。私たちがカスタマイズに含めたセクションは次の通りです： + +* `server` +* `location /` +* `location @drupal` +* `location @php`. + +各セクションには**二つ**のインクルードがあります： + +* `*_prepend.conf` +* `*_append.conf` + +`location @drupal`セクションは以下のようになります： + +```bash title="drupal.conf" +location @drupal { + include /etc/nginx/conf.d/drupal/location_drupal_prepend*.conf; + + include /etc/nginx/fastcgi.conf; + fastcgi_param SCRIPT_NAME /index.php; + fastcgi_param SCRIPT_FILENAME $realpath_root/index.php; + fastcgi_pass ${NGINX_FASTCGI_PASS:-php}:9000; + + include /etc/nginx/conf.d/drupal/location_drupal_append*.conf; +} +``` + +この設定は、顧客が`location_drupal_prepend.conf`および` `location_drupal_append.conf`、ここに他のステートメントの前後に挿入したい設定をすべて置くことができます。 + +これらのファイルは作成されたら、`nginx`コンテナ内に**必ず**存在していなければならず、それらを`Dockerfile.nginx`に以下のように追加します： + +```bash title="dockerfile.nginx" +COPY location_drupal_prepend.conf /etc/nginx/conf.d/drupal/location_drupal_prepend.conf +RUN fix-permissions /etc/nginx/conf.d/drupal/location_drupal_prepend.conf +``` + +## Drupal Core Statisticsモジュールの設定 + +コアのStatisticsモジュールを使用している場合、短時間で設定の変更が必要な問題に遭遇するかもしれません。 + +デフォルトのNGINX設定では、トラッキングエンドポイント`/core/modules/statistics/statistics.php`へのリクエストが拒否され（404）ます。 + +これはデフォルトのNGINX設定に関連しています： + +```text title="drupal.conf" +location ~* ^.+\.php$ { + try_files /dev/null @drupal; +} +``` + +この問題を解決するために、特定のロケーションルールを定義し、これをロケーションの前置設定として注入します： + +```text title="drupal.conf" +## Allow access to to the statistics endpoint. +location ~* ^(/core/modules/statistics/statistics.php) { + try_files /dev/null @php; +} +``` + +そして、これをNGINの間にコピーします Xコンテナービルド： + +```text title="dockerfile.nginx" +# Drupal統計モジュールの特定のNGINX設定を追加します。 +COPY .lagoon/nginx/location_prepend_allow_statistics.conf /etc/nginx/conf.d/drupal/location_prepend_allow_statistics.conf +``` diff --git a/docs/applications/drupal/services/php-cli.ja.md b/docs/applications/drupal/services/php-cli.ja.md new file mode 100644 index 0000000000..693be20edb --- /dev/null +++ b/docs/applications/drupal/services/php-cli.ja.md @@ -0,0 +1,22 @@ +# PHP-CLI-Drupal + +[Lagoonの`php-cli-drupal` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal)はDrupalと連携するために最適化されています。これは[Lagoonの`php-cli`イメージ](../../../docker-images/php-cli.md)を基に作られており、Drupalウェブサイトの日々のメンテナンスに必要なコマンドラインツール全てが含まれています。 + +* `drush` +* `drupal console` +* `drush launcher` \(サイトにインストールされたDrushが見つからない場合はDrush 8にフォールバックします\) + +## サポートされているバージョン + +* 7.3 \(互換性のために利用可能ですが、公式にはサポートされていません\) +* 7.4 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/7.4.Dockerfile) - `uselagoon/php-7.4-cli-drupal` +* 8.0 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/8.0.Dockerfile) - `uselagoon/php-8.0-cli-drupal` +* 8.1 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli-drupal/8.1.Dockerfile) - `uselagoon/php-8.1-cli-drupal` + +全てのPHPバージョンはそれぞれのDockerfilesを使用します。 + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかの事項が完了しています: + +* フォルダのパーミッションは自動的に適応されます [`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)を使用して、この画像はランダムなユーザーと一緒に動作します。 \ No newline at end of file diff --git a/docs/applications/drupal/services/redis.ja.md b/docs/applications/drupal/services/redis.ja.md new file mode 100644 index 0000000000..35325eb290 --- /dev/null +++ b/docs/applications/drupal/services/redis.ja.md @@ -0,0 +1,140 @@ +# Redis + +内部キャッシングには、[Redis](https://redis.io/)の使用を推奨します。Redisサービスを `docker-compose.yaml`に追加します。 + +```yaml title="docker-compose.yml" + redis: + image: uselagoon/redis-5 + labels: + lagoon.type: redis + << : *default-user # トップから定義されたユーザーを使用します。 + environment: + << : *default-environment +``` + +また、Redisを設定するには、以下を`settings.php`に追加します。 + +## Drupal 7 + +```php title="settings.php" + if(getenv('LAGOON')){ + $conf['redis_client_interface'] = 'PhpRedis'; + $conf['redis_client_host'] = 'redis'; + $conf['lock_inc'] = 'sites/all/modules/contrib/redis/redis.lock.inc'; + $conf['path_inc'] = 'sites/all/modules/contrib/redis/redis.path.inc'; + $conf['cache_backends'][] = 'sites/all/modules/contrib/redis/redis.autoload.inc'; + $conf['cache_default_class'] = 'Redis_Cache'; + $conf['cache_class_cache_form'] = 'DrupalDatabaseCache'; + $conf['cache_class_cache_field'] = 'DrupalDatabaseCache'; + } +``` + +ファイルシステムの構造によっては、モジュールのパスを更新する必要があるかもしれません。 + +## Drupal 8 + +Drupal 8の設定は大部分が標準です。特筆すべきは、Drupalがインストールされている間はRedisが無効になっていることです。 + +```php title=" "settings.php" +if (getenv('LAGOON')){ + $settings['redis.connection']['interface'] = 'PhpRedis'; + $settings['redis.connection']['host'] = getenv('REDIS_HOST') ?: 'redis'; + $settings['redis.connection']['port'] = getenv('REDIS_SERVICE_PORT') ?: '6379'; + $settings['cache_prefix']['default'] = getenv('LAGOON_PROJECT') . '_' . getenv('LAGOON_GIT_SAFE_BRANCH'); + + // Drupalのインストール中にキャッシュを設定しない。 + if (!drupal_installation_attempted() && extension_loaded('redis')) { + $settings['cache']['default'] = 'cache.backend.redis'; + + // そして、Redisモジュールが有効になっていなくても使用できます。 + $class_loader->addPsr4('Drupal\\redis\\', 'modules/contrib/redis/src'); + + $settings['bootstrap_container_definition'] = [ + 'parameters' => [], + 'services' => [ + 'redis.factory' => [ + 'class' => 'Drupal\redis\ClientFactory', + ], + 'cache.backend.redis' => [ + 'class' => 'Drupal\redis\Cache\CacheBackendFactory', + 'arguments' => ['@redis.factory', '@cache_tags_provider.container', '@serialization.phpserialize'], + ], + 'cache.container' => [ + 'class' => '\Drupal\redis\Cache\PhpRedis', + 'factory' => ['@cache.backend.redis', 'get'], + 'arguments' => ['container'], + ], + 'cache_tags_provider.container' => [ + 'class' => 'Drupal\redis\Cache\RedisCacheTagsChecksum', + 'arguments' => ['@redis.factory'], + ], + 'serialization.phpserialize' => [ + 'class' => 'Drupal\Component\Serialization\PhpSerialize', + ], + ], + ]; + } +} + +### 持続性 + +Redisは、持続的なバックエンドとしても設定できます。 + +```yaml title="docker-compose.yml" +redis: + image: uselagoon/redis-5-persistent + labels: + lagoon.type: redis-persistent + environment: + << : *default-environment +``` + +## 環境変数 + +環境変数は、Redisに関する一般的な情報を保存するためのものです。 + +| 環境変数 | デフォルト | 説明 | +| :--- | :--- | :--- | +| `LOGLEVEL` | `notice` | Redisのログレベル | +| `DATABASES` | `1` | データベースの数 | +| `MAXMEMORY` | `100mb` | Redisの最大メモリ使用量 | + +## Redisのフェイルオーバー + +以下は、Redisコンテナが利用できない場合（例えば、メンテナンス中など）にRedisのフェイルオーバーを実装するためのスニペットです。 + +以下は、Drupalのアクティブな`settings.php`に挿入されます。 ファイル。 + +```php title="settings.php" +if (getenv('LAGOON')) { + $contrib_path = is_dir('sites/all/modules/contrib') ? 'sites/all/modules/contrib' : 'sites/all/modules'; + $redis = DRUPAL_ROOT . '/sites/all/modules/contrib/redis'; + + if (file_exists("$redis/redis.module")) { + require_once "$redis/redis.module"; + $conf['redis_client_host'] = getenv('REDIS_HOST') ?: 'redis'; + $conf['redis_client_port'] = getenv('REDIS_SERVICE_PORT') ?: 6379; + $conf['cache_prefix'] = getenv('REDIS_CACHE_PREFIX') ?: getenv('LAGOON_PROJECT') . '_' . getenv('LAGOON_GIT_SAFE_BRANCH'); + try { + // Redisに接続があることを確認します。 + $client = Redis_Client::getClient(); + $response = $client->ping(); + if (!$response) { + throw new \Exception('Redisに到達できましたが、正しく応答していません。'); + } + $conf['redis_client_interface'] = 'PhpRedis'; + $conf['lock_inc'] = $contrib_path . '/redis/redis.lock.inc'; + $conf['path_inc'] = $contrib_path . '/redis/redis.path.inc'; + $conf['cache_backends'][] = $contrib_path . '/redis/redis.autoload.inc'; + $conf['cache_default_class'] = 'Redis_Cache'; + } catch (\Exception $e) { + // Redis このリクエストには利用できないため、Redisバックエンドの設定を行わず、キャッシュが使用されないように確認する必要があります。これにより次のリクエストが再試行されます。 + // 'DrupalFakeCache'クラスが存在しない場合 + if (!class_exists('DrupalFakeCache')) { + $conf['cache_backends'][] = 'includes/cache-install.inc'; + } + $conf['cache_default_class'] = 'DrupalFakeCache'; + } + } +} +``` \ No newline at end of file diff --git a/docs/applications/drupal/services/solr.ja.md b/docs/applications/drupal/services/solr.ja.md new file mode 100644 index 0000000000..b2f470c800 --- /dev/null +++ b/docs/applications/drupal/services/solr.ja.md @@ -0,0 +1,46 @@ +# Solr-Drupal + +## 標準的な使用法 + +Solr 5.5、6.6、および 7.7のために、私たちは [search\_api\_solr](https://www.drupal.org/project/search_api_solr) Drupalモジュールによって提供されるデフォルトのスキーマファイルを提供しています。 `docker-compose.yml` ファイルに使用したいSolrバージョンを追加してください。[私たちの例](https://github.com/amazeeio/drupal-example-simple/blob/63b3fc613260d5192b7e2dd0167c6fc85d8d9162/docker-compose.yml#L110)に従ってください。 + +## カスタムスキーマ + +プロジェクトでSolrのスキーマカスタマイズを実装するには、Lagoonがどのように[標準のイメージを作成するか](https://github.com/uselagoon/lagoon-images/blob/main/images/solr-drupal/7.7.Dockerfile)を参照してください。 + +* `docker-compose.yml` ファイルの `solr` セクションで、 `image: amazeeio/solr:7.7` を以下のように置き換えます: + +```yaml title="docker-compose.yml" + build: + context: . + dockerfile: solr.dockerfile +``` + +* スキーマファイルをコードリポジトリに配置します。私たちは通常、 `.lagoon/solr` を使用します。 +* `solr.dockerfile` を作成します。 + +```bash title="solr.dockerfile" +FROM amazeeio/solr:7.7 + +COPY .lagoon/solr /solr-conf/conf + +RUN precreate-core drupal /solr-conf + +CMD ["solr-foreground"] +``` + +目標は、Solr設定ファイルが `/solr-conf/conf` に存在することです。 あなたが作成しているイメージ。 + +## 複数のコア + +複数のコアを実装するには、上記のように自分自身のSolrスキーマを出荷する必要があります。必要な変更はDockerfileの`CMD`に対してのみで、必要なコアごとに`precreate-core corename /solr-conf/ ;`のパターンを繰り返します。 + +```bash title="solr.dockerfile" +FROM amazeeio/solr:7.7-drupal + +RUN precreate-core drupal-index1 /solr-conf && \ + precreate-core drupal-index2 /solr-conf && \ + precreate-core drupal-index3 /solr-conf + +CMD ["solr-foreground"] +``` diff --git a/docs/applications/drupal/services/varnish.ja.md b/docs/applications/drupal/services/varnish.ja.md new file mode 100644 index 0000000000..fffeec7293 --- /dev/null +++ b/docs/applications/drupal/services/varnish.ja.md @@ -0,0 +1,132 @@ +# バニッシュ + +Drupalをバニッシュリバースプロキシと一緒に使用することをお勧めします。Lagoonは既にバニッシュが設定されている`varnish-drupal` Dockerイメージを提供しています。[Drupal Varnish config](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)付きです。 + +このバニッシュ設定は以下のことを行います： + +* Drupalのセッションクッキーを理解し、認証されたリクエストのバニッシュキャッシュを自動的に無効にします。 +* アセット（画像、CSS、JSなど）を1ヶ月間自動的にキャッシュし、このヘッダーもブラウザに送信します。これにより、ブラウザもアセットをキャッシュします。これは認証されたリクエストと認証されていないリクエストの両方で発生します。 +* Drupal 8のパージモジュールで使用される`BAN`および`URIBAN`をサポートしています。 +* URLパラメータから`utm_`と`gclid`を削除し、Google Analyticsのリンクが複数のキャッシュオブジェクトを生成するのを防ぎます。 +* その他の多くの良い点 - [drupal.vcl](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish-drupal/drupal.vcl)をチェックしてみてください。 + +## Drupal 8との使用 + +**要約**: [我々の例のレポジトリでdrupal8-advancedの例をチェックしてみてください](https://github.com/uselagoon/lagoon-examples)、それは必要なモジュールと必要なものを含んでいます。 Drupalの設定。 + +**注意**：これらの例の多くは、同じ`drupal-example-simple`リポジトリ内の異なるブランチ/ハッシュに存在します。例のリストから正確なブランチを取得してください！ + +### PurgeとVarnish Purgeモジュールのインストール + +Drupal 8のキャッシュタグとVarnishを完全に使用するためには、[Purge](https://www.drupal.org/project/purge)と[Varnish Purge](https://www.drupal.org/project/varnish_purge)モジュールをインストールする必要があります。これらは多くのサブモジュールと共に提供されています。最低限以下のものをインストールすることをお勧めします： + +* `purge` +* `purge_drush` +* `purge_tokens` +* `purge_ui` +* `purge_processor_cron` +* `purge_processor_lateruntime` +* `purge_queuer_coretags` +* `varnish_purger` +* `varnish_purge_tags` + +一度にすべてを取得します： + +```bash title="PurgeとVarnish Purgeのインストール" +composer require drupal/purge drupal/varnish_purge + +drush en purge purge_drush purge_tokens purge_ui purge_processor_cron purge_processor_lateruntime purge_queuer_coretags varnish_purger varnish_purge_tags +``` + +### Varnish Purgeの設定 + +1. `Configuration > Development > Performance > Purge`にアクセスします。 +2. `Add purger`でパージャーを追加します。 +3. `Varnish Bundled Purger`を選択します（`Varnish Purger`ではなく、\#Behind the Scenesを参照してください）。 セクション、詳細情報については。\). +4. 追加したばかりのパージャーの隣にあるドロップダウンをクリックし、`Configure`をクリックします。 +5. 良い名前をつけてください、`Lagoon Varnish` が良いでしょう。 +6. 以下のように設定します： + + ```text title="Varnish Purgeの設定" + TYPE: タグ + + REQUEST: + ホスト名: varnish + (またはdocker-compose.ymlでVarnishが呼ばれている名前) + ポート: 8080 + パス: / + リクエスト方法: BAN + スキーム: http + + HEADERS: + ヘッダー: Cache-Tags + 値: [invalidations:separated_pipe] + ``` + +7. `設定を保存`。 + +以上で終わりです！これをローカルでテストしたい場合は、次のセクションを読んでください。 + +### Varnish用のDrupalの設定 + +その他にもいくつかの設定が可能です： + +1. `drush pmu page_cache`を使用して`Internal Page Cache` Drupalモジュールをアンインストールします。これによりVarnishキャッシュのみがクリアされ、内部キャッシュはクリアされず、変更がユーザーに非常に遅く表示されるなど、奇妙な二重キャッシュ状況が発生することがあります。また、大きなサイトではキャッシュストレージを大量に使用します。 +2. `production.settings.php`内の`$config['system.performance']['cache']['page']['max_age']`を`2628000`に変更します。これにより、Varnishはサイトを最大1ヶ月間キャッシュするように指示されますが、これは多くのように聞こえますが、Drupal 8 キャッシュタグシステムは基本的に何かが変更されるたびにVarnishキャッシュがパージされるようにするので、とても素晴らしいです。 + +### Varnishをローカルでテストする + +LagoonのローカルでのDrupalセットアップでは、開発が困難になる可能性があるため、VarnishとDrupalのキャッシュは無効になっています。これは次のように行われます： + +* `docker-compose.yml`の環境変数`VARNISH_BYPASS=true`は、Varnishに基本的に自己無効化を指示します。 +* Drupalは、`development.settings.php`のDrupal設定`$config['system.performance']['cache']['page']['max_age'] = 0`を設定することで、キャッシュヘッダーを送信しないように設定されています。 + +ローカルでVarnishをテストするには、`docker-compose.yml`で以下の変更を行います： + +* Varnishサービスセクションで`VARNISH_BYPASS`を`false`に設定します。 +* `x-environment`セクションで`LAGOON_ENVIRONMENT_TYPE`を`production`に設定します。 +* `docker-compose up -d`を実行します。これにより、新しい環境変数ですべてのサービスが再起動します。 + +これで、Varnishをテストできるようになるはずです！ + +次に、IDが`1`でURLが`drupal-example.docker.amazee.io/node/1`となるノードがあると仮定した短い例を示します。 + +1. `curl -I drupal-example.docker.amazee.io/node/1`を実行し、見てみてください。 これらのヘッダーについて: + * `X-LAGOON` には `varnish` が含まれ、要求が実際にVarnishを経由したことを示します。 + * `Age:` は、Varnishがこのサイトを初めて見ることはおそらくないため、最初のリクエストがVarnishのキャッシュを温めるでしょう。 + * `X-Varnish-Cache` は `MISS` となり、Varnishがこのリクエストの以前にキャッシュされたバージョンを見つけられなかったことを示します。 +2. `curl -I drupal-example.docker.amazee.io/node/1` を再度実行し、ヘッダーは次のようになります: + * `Age:` は、リクエストがキャッシュされてから何秒経ったかを示します。例えば、コマンドを実行する速度によりますが、1-30の間でしょう。 + * `X-Varnish-Cache` は `HIT` となり、Varnishがリクエストのキャッシュされたバージョンを正常に見つけ、それを返したことを示します。 +3. Drupalの `node/1` の内容を変更します。 +4. `curl -I drupal-example.docker.amazee.io/node/1` を実行し、ヘッダーは最初のリクエストと同じになるべきです: + * `Age:0` + * `X-Varnish-Cache: MISS` + +### Varnish on Drupal の裏側 + +他のDrupalホストから来ているか、以前にDrupal 8 & Varnishのチュートリアルを経験している場合、あなたは気付いたかもしれません。 Lagoon Drupal Varnishチュートリアルにいくつかの変更があります。それらについて説明しましょう: + +#### `Varnish Purger`の代わりに`Varnish Bundled Purger`の使用 + +`Varnish Purger`は、無効化する必要がある各キャッシュタグに対して`BAN`リクエストを送信します。Drupalには多数のキャッシュタグが存在し、これによりVarnishに送信されるリクエスト数がかなり多くなる可能性があります。それに対して、`Varnish Bundled Purger`は、複数の無効化に対して一つの`BAN`リクエストを送信します。これはパイプ（`|`）できれいに分離されており、Varnishのバンの正規表現システムに完璧にマッチします。これにより、Varnishへのリクエスト数が減少し、Varnish内のバンリストテーブルも小さくなります。 + +#### `Purge Late runtime processor`の使用 + +Drupal 7のVarnishモジュールとは異なり、Drupal 8のPurgeモジュールはキャッシュのパージに若干異なるアプローチを持っています: パージするキャッシュをキューに追加し、それを異なるプロセッサで処理します。Purgeは`Cron processor`の使用を提案していますが、これはVarnishキャッシュがcron実行時にのみパージされることを意味します。これは、cronがおそらく毎分実行するように設定されていないため、Varnishが古いデータをキャッシュする可能性があり、編集者やクライアントが混乱する結果となる可能性があります。 + +その代わりに、`Purge `Late runtime processor`は、各Drupalリクエストの最後にキューを処理します。これにより、キャッシュタグがパージキューに追加されると（例えば、エディタがDrupalノードを編集した場合など）、そのノードのキャッシュタグが直接パージされるという利点があります。`Varnish Bundled Purger`と一緒に使用することで、Drupalリクエストの最後にVarnishへの追加のリクエストは1つだけで、リクエストの処理時間にはほとんど影響しません。 + +#### Varnish Ban Lurkerの完全なサポート + +私たちのVarnish設定は、`Ban Lurker`の完全なサポートを提供しています。Ban Lurkerは、キャッシュをきれいに保ち、Varnishをスムーズに動作させるのに役立ちます。基本的には、Varnishの禁止リストを走査し、それらをVarnishキャッシュ内のキャッシュされたリクエストと比較する小さなツールです。Varnishの禁止は、キャッシュ内のオブジェクトをパージするために使用されます。Ban Lurkerが"禁止"されるべきアイテムを見つけると、それらをキャッシュから削除し、禁止自体も削除します。これにより、通常は禁止されずにキャッシュスペースを占め続ける、アクセスが少なくTTLが非常に長いオブジェクトが削除され、更新できるようになります。これにより、禁止リストが小さくなり、それによって、Varnの処理時間も少なくなります。 それぞれのリクエストでのVarnishの動作については、[公式VarnishのBan Lurkerについての投稿](https://info.varnish-software.com/blog/ban-lurker)や、その他の[参考になる読み物](https://www.randonomicon.com/varnish/2018/09/19/banlurker.html)をご覧ください。 + +### トラブルシューティング + +Varnishがキャッシュしていない？ それとも何か他の問題がありますか？ 以下にデバッグの方法をいくつか紹介します： + +* `drush p-debug-en`を実行して、purgeモジュールのデバッグログを有効にします。これにより、Drupalのログの`admin/reports/dblog`でデバッグを表示できます。 +* Drupalが適切なキャッシュヘッダーを送信していることを確認してください。これを最もよくテストするためには、LagoonがVarnishキャッシュをバイパスするために生成したURLを使用します（私たちのDrupalの例では、これは[http://nginx-drupal-example.docker.amazee.io](http://nginx-drupal-example.docker.amazee.io)です）。`Cache-Control: max-age=900, public`ヘッダーをチェックし、`900`が`$config['system.performance']['cache']['page']['max_age']`で設定したものであることを確認します。 +* 環境変数`VARNISH_BYPASS`が`true`に設定されて**いない**ことを確認してください（`docker-compose.yml`を参照し、`docker-compose up -d varnish`を実行して環境変数が正しく設定されていることを確認します）。 +* もし全部 失敗すると、テーブルをひっくり返す前に \(╯°□°）╯︵ ┻━┻、ラグーンチームに話してみてください、私たちは喜んでお手伝いします。 + \ No newline at end of file diff --git a/docs/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.ja.md b/docs/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.ja.md new file mode 100644 index 0000000000..8613eb5be3 --- /dev/null +++ b/docs/applications/drupal/step-by-step-getting-drupal-ready-to-run-on-lagoon.ja.md @@ -0,0 +1,175 @@ +# ステップバイステップ：LagoonでDrupalを実行する準備 + +## 1. Lagoon Drupal 設定ファイル + +DrupalがLagoonと連携するためには、DrupalにLagoonのことを、LagoonにDrupalのことを教える必要があります。これは、特定のYAMLとPHPファイルをGitリポジトリにコピーすることで行われます。 + +Drupalプロジェクトを手がけている場合は、[私たちの例のリポジトリ](https://github.com/uselagoon/lagoon-examples)でさまざまなDrupalの例のプロジェクトをチェックできます。Drupal 8と9、さらに各々のバリアントがあります。最もニーズに合ったリポジトリをクローンして始めてください。 + +以下に、LagoonとDrupalに特化したファイルの概要を示します： + +* `.lagoon.yml` - Lagoonが何をデプロイすべきかなどを理解するために使用される主要なファイルです。このファイルには、一部の妥当なDrupalのデフォルト設定が含まれています。編集や変更を行いたい場合は、[`.lagoon.yml`のドキュメンテーション](../../concepts-basics/lagoon-yml.md)をご覧ください。 +* `docker-compose.yml`、`.dockerignore`、および `*.dockerfile` \(または `Dockerfile`\) - これらのファイルはローカルのDrupal開発環境を起動するために使用され、Dockerにどのサービスを開始し、それらをどのようにビルドするかを指示します。 次の内容を含む合理的なデフォルト設定と多くのコメント行があります。十分にコメントがつけられていて、その内容が自己説明的であることを願っています。詳しく知りたい場合は、[`docker-compose.yml`](../../concepts-basics/docker-compose-yml.md)のドキュメンテーションをご覧ください。 +* `sites/default/*` - これらの`.php`と`.yml`のファイルは、DrupalがLagoonのコンテナとローカルおよび本番環境で通信する方法を指示します。また、開発環境と本番環境で特定のオーバーライドを直接的に提供します。他のDrupalホスティングシステムとは異なり、Lagoonは決してDrupalの設定ファイルをあなたのDrupalに注入しません。したがって、あなたはそれらを好きなように編集できます。他のすべてのファイルと同様に、それらには合理的なデフォルト設定といくつかのコメント部分が含まれています。 +* `drush/aliases.drushrc.php` - これらのファイルはDrushに特化しており、DrushにLagoon GraphQL APIと通信し、存在するすべてのサイトエイリアスについて学ぶ方法を指示します。 +* `drush/drushrc.php` - Drushコマンドのためのいくつかの合理的なデフォルト設定。 + +### `.gitignore`設定の更新 + +設定ファイルをコミットできるように、`.gitignore`を確認するのを忘れないでください。 + +Drupalは`sites/*/settings*.php`と`sites/*/services*.yml`を`.gitignore`で提供しています。それらを削除してください。 ラグーンでは、Gitリポジトリに機密情報を一切持っていません。 + +### Drupal 8の`WEBROOT`についての注意 + +残念ながら、Drupalコミュニティは標準化された`WEBROOT`フォルダ名について一致していません。一部のプロジェクトではDrupalを`web`内に置き、他のプロジェクトでは`docroot`や他の場所に置いています。LagoonのDrupal設定ファイルは、Drupalが`web`内にあると仮定していますが、あなたのDrupalでこれが異なる場合は、ファイルを適切に調整してください。 + +### `composer.json`についての注意 + +もしDrupalをcomposerを使ってインストールした場合は、`composer.json`を確認し、`name`が`drupal/drupal`でないことを確認してください。これはDrushやDrupalのユニバースの他のツールを混乱させる可能性があるため、それを`myproject/drupal`のようなものにリネームしてください。 + +## 2. `docker-compose.yml`のカスタマイズ + +`lagoon-project`と`LAGOON_ROUTE`の値を忘れずにカスタマイズし、サイト固有の名前とアクセスしたいURLに書き換えてください。以下に例を示します： + +```yaml title="docker-compose.yml" +x-environment: + &default-environment + LAGOON_PROJECT: *lagoon-project + # Route that should be used locally. If you are using pygmy, this route *must* end with .docker.amazee.io. + LAGOON_ROUTE: http://drupal-example.docker.amazee.io ## 3. イメージのビルド + +まず、定義されたイメージをビルドする必要があります： + +```bash title="イメージをビルド" +docker-compose build +``` + +これにより、`docker-compose.yml`内で`build:`の定義を持つすべてのコンテナのDockerイメージを`docker-compose`にビルドするよう指示します。通常、Drupalでは`cli`、`nginx`、`php`のイメージが該当します。これは、特定の**ビルド**コマンド（`composer install`など）を実行したり、特定の環境変数（`WEBROOT`など）をイメージに注入したりするためです。 + +通常、Drupalのコードを編集するたびにビルドする必要はありません（コードはホストからコンテナにマウントされるため）が、再ビルドしても問題ありません。さらに、Lagoonはデプロイ時にまったく同じDockerイメージをビルドするので、`docker-compose build`を再度実行するだけで、ビルドがデプロイ時にも正常に動作することを確認できます。 + +## 4. コンテナの起動 + +イメージがビルドされたので、コンテナを起動できます： + +```bash title="コンテナを起動" +docker-compose up -d +``` + +これにより、すべてのコンテナが起動します。コマンドが完了した後、`docker-compose ps`で確認して、すべてが完全にアップしてクラッシュしていないことを確認できます。問題がある場合は、確認してください `docker-compose logs -f [servicename]`でログを確認します。 + +## 5. `composer install`を再実行します（Composerプロジェクトのみ） + +ローカルの開発環境では、すべての依存関係がダウンロードされインストールされることを期待するでしょう、それで`cli`コンテナへ接続し`composer install`を実行します： + +```bash title="CLIでcomposer installを実行" +docker-compose exec cli bash +composer install +``` + +これは奇妙に聞こえるかもしれません、なぜならビルドステップの間にすでに`composer install`が実行されていたからです、それで説明させてください： + +* ホスト上のファイルを編集し、それらをコンテナ内で即座に利用可能にするため、デフォルトの`docker-composer.yml`は全体のフォルダをコンテナ内にマウントします（これはボリュームセクションの`.:/app:delegated`で起こります）。これはまた、Dockerビルド中にインストールされたすべての依存関係がホスト上のファイルで上書きされることを意味します。 +* ローカルでは、`composer.json`で`require-dev`として定義された依存関係も存在することを期待するでしょう、一方で本番環境ではそれらは単に不必要なスペースを使用するだけです。そのため、Dockerfileで`composer install --no-dev`を実行し、`composer install`は手動で実行します。 + +全てがうまく行った場合、`docker-compose`で定義された`LAGOON_ROUTE`を開きます。 .yml` \(例えば `http://drupal.docker.amazee.io`\) を開いて、素敵なDrupalエラーが表示されるはずです。心配しないでください - 今のところそれは大丈夫です、最も重要なのはDrupalサイトをロードしようとしていることです。 + +500や類似のエラーが表示された場合は、Composerで正しくすべてがロードされていることを確認してください。 + +## 6. ステータスの確認とDrupalのインストール + +いよいよDrupalをインストールする時間がきましたが、その前にすべてが機能していることを確認したいと思います。それにはDrushを使用することをお勧めします: + +```bash title="Drush status" +docker-compose exec cli bash +drush status +``` + +これにより、以下のような結果が返されるはずです: + +```bash title="Drush status result" +[drupal-example]cli-drupal:/app$ drush status +[notice] Missing database table: key_value +Drupal version : 8.6.1 +Site URI : http://drupal.docker.amazee.io +Database driver : mysql +Database hostname : mariadb +Database port : 3306 +Database username : drupal +Database name : drupal +PHP binary : /usr/local/bin/php +PHP config : /usr/local/etc/php/php.ini +PHP OS : Linux +Drush script : /app/vendor/drush/drush/drush +Drush version : 9.4.0 +Drush temp : /tmp +Drush configs : /home/.dr ush/drush.yml + /app/vendor/drush/drush/drush.yml +Drupal root : /app/web +Site path : sites/default +``` + +!!! 警告 + 次のステップ前に、pygmyに公開鍵について伝える必要があるかもしれません。 + +`Permission denied (publickey)`のようなエラーが出た場合は、こちらのドキュメンテーションをご覧ください: [pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/ssh_agent) + +次にDrupalをインストールします（既存のSQLファイルをインポートしたい場合は、[ステップ7へスキップ](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#7-import-existing-database-dump)してください。しかし、始めは全てが機能することを確認するために、クリーンなDrupalのインストールから始めることをお勧めします）。 + +```bash title="Drupalのインストール" +drush site-install +``` + +以下のような出力が表示されるはずです: + +```bash title="drush site-install" +[drupal-example]cli-drupal:/app$ drush site-install +あなたは 'drupal' データベースの全てのテーブルをDROPしようとしています。続行しますか？ (y/n): y +Drupalのインストールを開始します。これにはしばらく時間がかかります。--notify グローバルオプションを使用することを検討してみてください。 +インストール完了。ユーザー名: admin ユーザーパスワード: a7kZJekcqh +おめでとうございます、Drupalをインストールしました！ +``` + +これで `LAGOON_ROUTE`で定義されたURLを訪れると、新鮮でクリーンにインストールされたDrupalサイトが表示されるはずです - おめでとうございます！ + +![おめでとう！](https://media.giphy.com/media/XreQmk7ETCak0/giphy.gif) + +## 7. 既存のデータベースダンプをインポートする + +既に既存のDrupalサイトを持っている場合、そのデータベースをローカルサイトにインポートしたいと思うでしょう。 + +データベースダンプを作成する方法は多数あります。現在のホスティングプロバイダーにDrushがインストールされている場合は、以下のように使用できます： + +```bash title="Drush sql-dump" +drush sql-dump --result-file=dump.sql + +データベースダンプはdump.sqlに保存されました +``` + +これで、データベース全体を含む`dump.sql`ファイルが作成されます。 + +このファイルをGitリポジトリにコピーし、`cli`に接続すると、その中にファイルが表示されるはずです： + +```bash title="dump.sqlの表示" +[drupal-example]cli-drupal:/app$ ls -l dump.sql +-rw-r--r-- 1 root root 5281 Dec 19 12:46 dump.sql +``` + +現在のデータベースを削除し、ダンプをインポートできます。 + +```bash title="dump.sqlのインポート" +drush sql-drop + +drush sql-cli < dump.sql +``` + +プロジェクトのURLを訪れてすべてが正常に動作することを確認します。Drupalサイトの機能的なコピーができているはずです！ + +## 8. Drupalファイル ディレクトリ + +Drupalサイトには、ファイルのディレクトリも必要です。全体のフォルダはDockerコンテナにマウントされるので、ファイルを正しいフォルダ（おそらく`web/sites/default/files`、`sites/default/files`またはそれに類似したもの）に追加してください。あなたが`WEBROOT`として設定したものを覚えておいてください - [すべてのプロジェクトで同じではないかもしれません](step-by-step-getting-drupal-ready-to-run-on-lagoon.md#note-about-webroot-in-drupal-8)。 + +## 9. 完了 + +あなたのローカルセットアップが完了しました。Lagoonチームは楽しいDrupal制作を願っています！ \ No newline at end of file diff --git a/docs/applications/drupal/subfolders.ja.md b/docs/applications/drupal/subfolders.ja.md new file mode 100644 index 0000000000..30e99d69af --- /dev/null +++ b/docs/applications/drupal/subfolders.ja.md @@ -0,0 +1,129 @@ +# サブフォルダ + +例えば、`www.example.com`が一つのDrupalサイトを指し、`www.example.com/blog`が別のDrupalで作られたブログをロードする場合があります。 + +両方のDrupalを1つのGitリポジトリで動かし、それを全体としてデプロイすることが可能ですが、このワークフローはすべてのチームに適合するわけではなく、別々のGitリポジトリを持つことが一部の状況にはより適しています。 + +## ルートアプリケーションの修正 + +ルートアプリケーション（この例では`www.example.com`のDrupalサイト）は、NGINXをサブフォルダアプリケーションへのリバースプロキシとして構成するいくつかのNGINX設定が必要です： + +### `location_prepend.conf` + +Drupalインストールのルートに`location_prepend.conf`というファイルを作成します： + +```text title="location_prepend.conf" +resolver 8.8.8.8 valid=30s; + +location ~ ^/subfolder { + # $http_x_forwarded_protoが空（上流のリバースプロキシから設定されていない場合）であれば、 + # 現在のスキームに設定します。 + set_if_empty $http_x_forwarded_proto $scheme; + + proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; + proxy_set_header X-Forwarded-Proto $scheme; + proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; + proxy_set_header X-Lagoon-Forwarded-Host $ ホスト; + # 元のホストを下流が知るために使用されます。 + proxy_set_header X-REVERSEPROXY $hostname; + proxy_set_header FORWARDED ""; + # drupal8が設定されているとエラーを出すため、FORWARDEDを未設定にします。 + proxy_set_header Proxy ""; + # drupal8が設定されているとエラーを出すため、Proxyを未設定にします。 + proxy_ssl_server_name on; + + # DNS解決が正しく機能するためには、NGINXに変数を設定する必要があります。 + set $subfolder_drupal_host "https://nginx-lagoonproject-${LAGOON_GIT_SAFE_BRANCH}.clustername.com:443"; + # LAGOON_GIT_SAFE_BRANCH変数はdockerエントリーポイント時に置換されます。 + proxy_pass $subfolder_drupal_host; + proxy_set_header Host $proxy_host; + # $proxy_hostはproxy_passに基づいてNGINXによって自動生成されます（スキームとポートは不要です）。 + + expires off; # プロキシからのキャッシュヘッダーを尊重し、上書きしないようにします +``` + +以下の文字列を置換してください： + +* `/subfolder` を使用したいサブフォルダの名前に置換します。例えば、`/blog`。 +* `nginx` をサブフォルダプロジェクト内で指すサービスに置換します。 +* `lagoonproject` をサブフォルダプロジェクトのLagoonプロジェクト名に置換します。 + +### N GINX Dockerfile + +以下をあなたのNGINX Dockerfile（`nginx.dockerfile`または`Dockerfile.nginx`）に追加してください： + +```text title="nginx.dockerfile" +COPY location_prepend.conf /etc/nginx/conf.d/drupal/location_prepend.conf +RUN fix-permissions /etc/nginx/conf.d/drupal/* +``` + +## サブフォルダアプリケーションの変更 + +ルートアプリケーションと同様に、サブフォルダアプリケーション（この例では、`www.example.com/blog`のDrupalインストール）にも、サブフォルダ下で動作していることを教える必要があります。これを行うために、以下の2つのファイルを作成します： + +### `location_drupal_append_subfolder.conf` + +サブフォルダのDrupalインストールのルートに`location_drupal_append_subfolder.conf`という名前のファイルを作成します： + +```text title="location_drupal_append_subfolder.conf" +# `subfolder`という接頭辞がついたスクリプト名を注入すると、Drupalは +# `subfolder`が接頭辞として付けられたすべてのURLを描画します +fastcgi_param SCRIPT_NAME /subfolder/index.php; + +# リバースプロキシ経由で実行している場合、元のHOST URLを +# PHPに注入します。これにより、Drupalは元のHOST URLで +# すべてのURLを描画し、現在使用しているHOSTではありません。 + +# 最初に、HOSTを通常のホスト変数に設定します。 +fastcgi_param HTTP_HOST $http +``` _host; +# それが存在する場合は、`X-Lagoon-Forwarded-Host`で上書きします。 +fastcgi_param HTTP_HOST $http_x_lagoon_forwarded_host if_not_empty; +``` + +`/subfolder`を使用したいサブフォルダの名前に置き換えてください。例えば、`/blog`。 + +### `server_prepend_subfolder.conf` + +サブフォルダのDrupalインストールのルートに`server_prepend_subfolder.conf`という名前のファイルを作成します： + +```text title="server_prepend_subfolder.conf" +# 内部のNGINXリライトを行う前に、リダイレクトを確認します。 +# これは、内部のNGINXリライトが `last`を使用するためで、 +# これはNGINXにリライトをこれ以上確認しないよう指示します（そして +# `if`はリダイレクトモジュールの一部です）。 +include /etc/nginx/helpers/010_redirects.conf; + +# これは内部のNGINXリライトで、リクエストから`/subfolder/`を +# 削除して、NGINXが最初から`/`だったかのようにリクエストを +# 処理します。 +# `last`フラグも重要です。これはNGINXにこれ以上のリライトを +# 実行しないよう指示します。なぜなら、以下のリライトで永遠に +# リダイレクトするからです。 +rewrite ^/subfolder/(.*) /$1 last; + +# リダイレクトが絶対ではないことを確認し、URLのホストをNGINXが +# 上書きしないようにします - これは # NGINXが現在提供しているもの以外の何かである可能性があります。 +absolute_redirect off; + +# リクエストが`/subfolder`だけの場合、301リダイレクトを`/subfolder/`にします +# (Drupalは末尾のスラッシュが大好き) +rewrite ^/subfolder /subfolder/ permanent; + +# 他の全てのリクエストに対しては、301リダイレクトを`/subfolder/`でプレフィックスします。 +rewrite ^\/(.*) /subfolder/$1 permanent; +``` + +`/subfolder`を使用したいサブフォルダの名前に置き換えてください。例えば、`/blog`。 + +### NGINX Dockerfile + +また、NGINX Dockerfileも修正する必要があります。 + +以下をNGINX Dockerfile (`nginx.dockerfile` または `Dockerfile.nginx`)に追加してください： + +```text title="nginx.dockerfile" +COPY location_drupal_append_subfolder.conf /etc/nginx/conf.d/drupal/location_drupal_append_subfolder.conf +COPY server_prepend_subfolder.conf /etc/nginx/conf.d/drupal/server_prepend_subfolder.conf +RUN fix-permissions /etc/nginx/conf.d/drupal/* +``` \ No newline at end of file diff --git a/docs/applications/index.ja.md b/docs/applications/index.ja.md new file mode 100644 index 0000000000..6515a132c5 --- /dev/null +++ b/docs/applications/index.ja.md @@ -0,0 +1,37 @@ +--- +説明： ラグーンで実行できるアプリケーション +--- + +# ラグーンがサポートするアプリケーション、フレームワーク、言語の幅広い範囲 + +ラグーンは、アプリケーションスタックの3つのレベルを大まかに分類しています： + +## 言語 + +これらは通常ラグーン特有のイメージによって提供され、任意のラグーンプロジェクトの基本的な構成要素です。 + +## フレームワーク + +これらは基本イメージを取り、ウェブサイトを提供するため、またはアプリケーションを運用するために必要なロジック、ツール、パッケージを追加します。 + +## アプリケーション + +通常、フレームワークの上に構築され、これはコンテンツエディターや開発者が最終製品を形成するために対話するレイヤーです。 + +----------------------- + +ラグーンで使用するためのリポジトリを参照するとき、通常は3つの方法でそれらを参照します： + +## テンプレート + +これらは完全に機能し、複製可能なスターターリポジトリであり、定期的に維持・更新され、少ないカスタマイズで拡張して使用することができます。 + +## 例 + +これらは完全に機能するリポジトリであり、定期的に維持・更新されますが、個々のプロジェクトに対して動作させるためにはいくつかの努力が必要かもしれません。 + +## デモ + +これらはデモンストレーションとして構築されたリポジトリであり、その中のいくつかの概念に対して使用可能です。 しかし、定期的にメンテナンスや更新は行われていません。 + +より完全なリストについては、私たちのGitHubリポジトリ：[https://www.github.com/lagoon-examples](https://www.github.com/lagoon-examples) と私たちのウェブサイト [https://lagoon.sh/application/](https://lagoon.sh/applications/) をご覧ください。 \ No newline at end of file diff --git a/docs/applications/node.ja.md b/docs/applications/node.ja.md new file mode 100644 index 0000000000..af04ef0065 --- /dev/null +++ b/docs/applications/node.ja.md @@ -0,0 +1,7 @@ +# Node.js + +## はじめに + +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 diff --git a/docs/applications/options.ja.md b/docs/applications/options.ja.md new file mode 100644 index 0000000000..d93f5ca2a0 --- /dev/null +++ b/docs/applications/options.ja.md @@ -0,0 +1,50 @@ +--- +description: Lagoonを使用するためのアプリケーション設定 +--- + +# Lagoonを使用するためのアプリケーション設定 + +## `lagoon.yml` + +Lagoonのプロジェクトレベルおよび環境レベルの設定は、リポジトリの `.lagoon.yml` ファイルに提供されています。 + +[`lagoon-yml.md`](../concepts-basics/lagoon-yml.md)を参照してください。 + +## `docker-compose.yml` + +Lagoonのサービスレベルの設定は、リポジトリの`docker-compose.yml`ファイルに提供されています。特に、`lagoon.type`と関連するサービスラベルは個々のサービスで文書化されています。 + +[`docker-compose-yml.md`](../concepts-basics/docker-compose-yml.md)を参照してください。 + +## ストレージ + +Lagoonは、ほとんどのサービスにストレージを提供する能力があります - 組み込みのLagoonサービスタイプには、必要なPVC、ボリュームなどを追加するための`-persistent`バリアントがあります。この設定をローカルに反映するように例を更新しました。 + +## データベース + +Lagoonは以下の設定を利用できます： + +* Mariadb - すべてのサポートされているバージョン +* PostgreSQL - すべてのサポートされているバージョン + +### データベース・アズ・ア・サービス + +Lagoonはまた、[dbaas-operator](https://github.com/amazeeio/dbaas-operator)を利用して、これらのデータベースを自動的にプロビジョニングする能力もあります。 管理データベースサービス（例：RDS、Google Cloud Databases、Azure Database）があります。これらのサービスがクラスターにプロビジョニングされ、設定されると自動的にこれらが利用されます。これらが利用できない場合、フォールバックとしてポッドがプロビジョニングされます。 + +## キャッシュ + +Lagoonは、キャッシュバックエンドとしてRedisをサポートしています。本番環境では、一部のユーザーがスケールを助けるために、本番環境用の管理されたRedisサービスをプロビジョニングします。 + +## 検索 + +Lagoonは、Elasticsearch、Solr、OpenSearchを検索プロバイダとしてサポートしています。必要に応じて、外部検索プロバイダも設定できます。 + +## イングレス/ルート + +Lagoonは、イングレス要件を持つサービスのルートを自動生成します。カスタムルートは、各サービスごとに `.lagoon.yml` に提供できます。 + +## 環境変数 + +Lagoonは、ビルド時とランタイム時に環境変数を多用します。これらがアプリケーションの重要な設定（例：データベース設定/資格情報）を提供するために使用される場合、ローカルバージョンとLagoonバージョンが同様に名付けられていることが重要です。 + +詳細は [environment-variables.md](../concepts-advanced/environment-variables.md)を参照してください。 \ No newline at end of file diff --git a/docs/applications/other.ja.md b/docs/applications/other.ja.md new file mode 100644 index 0000000000..d3abba5b1d --- /dev/null +++ b/docs/applications/other.ja.md @@ -0,0 +1,35 @@ +# Lagoon上で他のアプリケーションを実行する + +たとえLagoonがあなたの特定のアプリケーション、フレームワーク、言語のための基本イメージを持っていなくても、Lagoonはそれを構築することができます！ + +[共通イメージ](../docker-images/commons.md)を拡張したり、継承したりすることで、Lagoonはほぼどんなワークロードでも実行することができます。 + +## Hugo + +この簡単な例では、Hugoのウェブサイトを構築し、それをNGINXイメージの静的ファイルとして提供する方法を示しています。共通イメージはHugoの追加、サイトのコピー、構築のために使用されます。その後、NGINXイメージを使用してサイトを提供し、カスタマイズしたNGINX設定を追加します。 + +```bash title="nginx.dockerfile" +FROM uselagoon/commons as builder + +RUN apk add hugo git +WORKDIR /app +COPY . /app +RUN hugo + +FROM uselagoon/nginx + +COPY --from=builder /app/public/ /app +COPY lagoon/static-files.conf /etc/nginx/conf.d/app.conf + +RUN fix-permissions /usr/local/openresty/nginx +``` + +```yaml title="docker-compose.yml" +services: + nginx: + build: + context: . + dockerfile: lagoon/nginx.Dockerfile + labels: + lagoon.type: nginx +``` \ No newline at end of file diff --git a/docs/applications/php.ja.md b/docs/applications/php.ja.md new file mode 100644 index 0000000000..d280ad74f7 --- /dev/null +++ b/docs/applications/php.ja.md @@ -0,0 +1,7 @@ +# PHP + +## 紹介 + +ラグーンは、[Drupal](./drupal/index.md)、Laravel、[Wordpress](wordpress.md)、Magento、Symfonyなど、様々なPHPベースのアプリケーションをサポートしています。 + +LagoonでPHPプロジェクトを実行するための適応方法についての詳細は、[PHP-cli Dockerイメージ](../docker-images/php-cli.md)および[PHP-FPM Dockerイメージ](../docker-images/php-fpm.md)のセクションで見つけることができます。 \ No newline at end of file diff --git a/docs/applications/python.ja.md b/docs/applications/python.ja.md new file mode 100644 index 0000000000..a16415c512 --- /dev/null +++ b/docs/applications/python.ja.md @@ -0,0 +1,7 @@ +# Python + +## はじめに + +Lagoonは、Pythonベースのフレームワークやアプリケーションでウェブアプリを構築するために使用できる[Python 3.7以上](https://github.com/uselagoon/lagoon-images/tree/main/images/python)のイメージを提供します。 + +Lagoon上でPythonプロジェクトを動作させるための調整方法についての詳細は、[Python Dockerイメージ](../docker-images/python.md)セクションで見つけることができます。 \ No newline at end of file diff --git a/docs/applications/ruby.ja.md b/docs/applications/ruby.ja.md new file mode 100644 index 0000000000..e81373982a --- /dev/null +++ b/docs/applications/ruby.ja.md @@ -0,0 +1,53 @@ +# RubyとRuby on Rails + +## 序章 + +私たちは、公式のRuby alpine Dockerイメージをベースに構築したRuby 3.0以上のイメージを提供しています。 + +以下では、Lagoon上でRailsアプリをデプロイしようとしていると仮定していますが、記述されている詳細のほとんどはフレームワークに関係なく適用可能です。 + +## Lagoon上で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`という名前のサービスを設定しています。これは、任意の動的リクエストを処理する主要なサービスです。 + +`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)を参照してください）。 + +### ロギング + +Lagoonのロギングインフラストラクチャについては、次の文書で説明されています。 [こちらのドキュメント](../logging/logging.md)をご覧ください。基本的に、このインフラを利用するためには、ログをUDPメッセージで`udp://application-logs.lagoon.svc:5140`に送信する必要があります。 + +Railsの例では、`logstash-logger`というgemをインポートし、その後`config/application.rb`で以下のように初期化しています。 + +```ruby title="config/application.rb" + if ENV.has_key?('LAGOON_PROJECT') && ENV.has_key?('LAGOON_ENVIRONMENT') then + lagoon_namespace = ENV['LAGOON_PROJECT'] + "-" + ENV['LAGOON_ENVIRONMENT'] + LogStashLogger.configure do |config| + config.customize_event do |event| + event["type"] = lagoon_namespace + end + end + + config.logstash.host = 'application-logs.lagoon.svc' + config.logstash.type = :udp + config.logstash.port = 5140 + end +``` + +## データベース設定 + +この例では、私たちの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)を設定します。 + +```yaml title="config/database.yml" +default: &default + adapter: postgresql + encoding: unicode + pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> + username: <%= ENV.fetch("POSTGRES_USERNAME") { "drupal" } %> + password: <%= ENV.fetch("POSTGRES_PASSWORD") { "drupal" } %> + host: <%= ENV.fetch("POSTGRES_HOST") { "postgres" } %> + database: <%= ENV.fetch("'POSTGRES_DATABASE'") { "drupal" } %> +``` diff --git a/docs/applications/wordpress.ja.md b/docs/applications/wordpress.ja.md new file mode 100644 index 0000000000..3c2775de64 --- /dev/null +++ b/docs/applications/wordpress.ja.md @@ -0,0 +1,21 @@ +# Lagoon上のWordPress + +[WordPressテンプレート](https://www.github.com/lagoon-examples/wordpress-base)は、WordPress、その依存性、およびテーマをインストールするためにComposerを使用するように設定されています。 + +WordPressテンプレートは、[https://github.com/roots/bedrock](https://github.com/roots/bedrock)ボイラープレートを基にしていますが、標準化されたLagoonのデプロイメントパターンに合わせて拡張されています。 + +## Composerインストール + +テンプレートは、WordPressとそのテーマをインストールするためにComposerを使用します。 + +## データベース + +LagoonはMariaDBとPostgreSQLデータベースをサポートしていますが、WordPressでのPostgreSQLのサポートは限定的なので、使用は推奨されません。 + +## 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 diff --git a/docs/code-of-conduct.ja.md b/docs/code-of-conduct.ja.md new file mode 100644 index 0000000000..9054728d3a --- /dev/null +++ b/docs/code-of-conduct.ja.md @@ -0,0 +1,43 @@ +# 行動規範 + +## 私たちの誓い + +オープンで歓迎的な環境を育てるために、私たちは貢献者やメンテナとして、年齢、体型、障害、民族性、性自認と性表現、経験のレベル、国籍、個人の外見、人種、宗教、または性的アイデンティティと性的指向に関係なく、私たちのプロジェクトとコミュニティへの参加を誰もがハラスメントのない経験にすることを誓います。 + +## 私たちの基準 + +**積極的**な環境作りに貢献する行動の例： + +* ウェルカミングで包括的な言葉遣いをすること。 +* 異なる視点と経験を尊重すること。 +* 建設的な批評を穏やかに受け入れること。 +* コミュニティのために最善を尽くすこと。 +* 他のコミュニティメンバーに対する共感を示すこと。 + +参加者による**許されない**行動の例： + +* 性的な言葉やイメージの使用、および歓迎されない性的な関心やアドバンス。 +* トローリング、侮辱的/蔑視的なコメント、および個人または政治的な攻撃。 +* 公共の場またはプライベートでのハラスメント。 +* 明確な許可なしに他人のプライベート情報（物理的または電子的な住所など）を公開すること。 +* 合理的に不適切と考えられる他の行為。 専門的な環境では不適切と考えられる場合。 + +## 私たちの責任 + +プロジェクトの管理者は、受け入れられる行動の基準を明確にし、不受け入れ可能な行動の事例に対して適切で公正な是正措置をとることが期待されています。 + +プロジェクトの管理者は、この行動規範に合致していないコメント、コミット、コード、ウィキの編集、問題、およびその他の貢献を削除、編集、または拒否する権利と責任を持っています。また、不適切、脅威的、攻撃的、または有害と見なす他の行動を行った貢献者を一時的または永久に禁止することもあります。 + +## 適用範囲 + +この行動規範は、プロジェクトのスペース内だけでなく、個人がプロジェクトまたはそのコミュニティを代表して公共のスペースにいるときにも適用されます。プロジェクトまたはコミュニティを代表する例としては、公式のプロジェクトの電子メールアドレスを使用すること、公式のソーシャルメディアアカウントを通じて投稿すること、オンラインまたはオフラインのイベントで指名された代表者として行動することなどがあります。プロジェクトの代表は、プロジェクトの管理者によってさらに定義され、明確化されることがあります。 + +## 執行 + +虐待的、嫌がらせのある、またはそれ以外の不受け入れ可能な行動の事例は、連絡先に報告することができます。 プロジェクトチームは[uselagoon@amazee.io](mailto:uselagoon@amazee.io)にいます。また、[CoCトレーニング](https://www.drupal.org/community/cwg/code-of-conduct-contact-training)を完了したLagoonチームのメンバーである[Alanna](mailto:alanna.burke@amazee.io)または[Brandon](mailto:brandon.williams@amazee.io)に直接連絡することも可能です。プロジェクトチームはすべての苦情をレビューし、調査し、状況に適したと考える方法で対応します。プロジェクトチームは、事象の報告者に関する機密性を維持する義務があります。具体的な施行ポリシーの詳細は、別途投稿される可能性があります。 + +プロジェクトのメンテナーが誠実に行動規範に従わない場合、またはそれを強制しない場合、プロジェクトのリーダーシップの他のメンバーによって一時的または永久的な影響を受ける可能性があります。 + +## アトリビューション + +この行動規範は、[Contributor Covenant](http://contributor-covenant.org)、バージョン1.4からアダプトされています。こちらでご覧いただけます [http://contributor-covenant.org/version/1/4](https://www.contributor-covenant.org/version/1/4/)。 \ No newline at end of file diff --git a/docs/community/discord.ja.md b/docs/community/discord.ja.md new file mode 100644 index 0000000000..d6f00041bf --- /dev/null +++ b/docs/community/discord.ja.md @@ -0,0 +1,15 @@ +# Discord上のラグーンコミュニティ + +私たちの公式コミュニティ会議スペースは、ラグーンの[Discord](https://discord.gg/te5hHe95JE)です。 + +私たちは、このコミュニティを全てのラグーンユーザーが協力し、問題を解決し、アイデアを共有し、ラグーンプロジェクトに貢献する場として設立しました。現在、コミュニティはSlackやその他の場所に分散しているので、一元化するために努力しています。また、全てのユーザーや顧客が参加し、コミュニティから得られる利益を全ての人が享受できるようにしたいと考えています。 + +_この場所は、現在のサポートチャネルを置き換えるものではないことを忘れないでください - それらはそのまま維持されます。これは他のユーザーやラグーンのメンテナと繋がる場所です。_ + +私たちは全てのコミュニティメンバーに、私たちの[参加](participation.md)と[モデレーション](moderation.md)のガイドライン、および[行動規範](../code-of-conduct.md)を確認していただくことをお願いしています。 + +## コミュニティ時間 + +現在、コミュニティのニーズをよりよく理解するためにコミュニティを調査しているため、コミュニティ時間は一時停止しています。[こちらでアンケートにご記入ください](https://forms.gle/CFgQLCp3zu9fEFcM8)。 + +ラグーンに関して何か手助けが必要な場合は、[Discord](https://discord.gg/te5hHe95JE)でお問い合わせください。 または、[uselagoon@amazee.io](mailto:uselagoon@amazee.io)までメールをお送りください。 \ No newline at end of file diff --git a/docs/community/moderation.ja.md b/docs/community/moderation.ja.md new file mode 100644 index 0000000000..25bd6b1059 --- /dev/null +++ b/docs/community/moderation.ja.md @@ -0,0 +1,31 @@ +# ラグーンモデレーションガイドライン + +_これらのガイドラインは、[Drupal Diversity & Inclusionのモデレーションガイドライン](https://www.drupaldiversity.com/docs/moderation-guidelines)から改変されています。_ + +ラグーンの空間では、すべての人々に対する理解、共感、個人的な認識の向上を促進するよう努めてください。これには、あなたが個人的に意見が合わないかもしれないDrupalコミュニティや広範な技術コミュニティの人々も含まれます。 + +Discordからキックされた場合、キックされたユーザーは、再入場を希望する場合、キッカーまたは別のモデレーターにプライベートメッセージ（PM）を送ることができます。もし、敵意ある反応を引き起こすような意図的に煽動的、いじめ、または嫌がらせ行為に従事していると見える混乱を招く人がいた場合、他のチャネルメンバーにとってストレスとなる行為をほぐすよりも、キックする方が早くて簡単です。 + +キックは禁止ではありません。混乱を招く可能性のあるコメントや発言が真剣で、二者間のコミュニケーションを断絶することもあります。モデレーターと話すことにより、（潜在的に）混乱を招く人は、より配慮深く、包括的で、多様性を意識した言葉を使用するように指導されることができます。 そして、より建設的な方法で関与してください。 + +## 段階的な対応 + +1. 段階一の対応 + + ユーザーはチャンネルに歓迎され、スクロールバックの読み方を説明され、参加ガイドラインへのリンクが提供されます。 + +2. 段階二の対応 + + ユーザーには、投稿をトピックに沿ったものに保つように、または参加ガイドラインを守るように、チャンネル内で優しく思い出させます。 + +3. 段階三の対応 + + モデレーターからユーザーにPMが送られ、その投稿に問題があった理由と、何をどう違う方法で行うべきかについて説明されます。 + +4. 段階四の対応 + + 行動が続く場合、ユーザーはDiscordから少なくとも24時間は追放されます。 + +## 段階的でない対応：禁止 + +意図的に混乱を引き起こす個人は、段階的ではなく、追放されます。繰り返し違反すると禁止されます。 \ No newline at end of file diff --git a/docs/community/participation.ja.md b/docs/community/participation.ja.md new file mode 100644 index 0000000000..5b084ae88d --- /dev/null +++ b/docs/community/participation.ja.md @@ -0,0 +1,42 @@ +# ラグーン参加ガイドライン + +私たちのコミュニティのすべてのメンバーが、仮想的なスペースでも物理的なスペースでも、私たちの[行動規範](../code-of-conduct.md)を遵守することをお願いします。 + +_これらのガイドラインは、[Drupal Diversity & Inclusionの参加ガイドライン](https://www.drupaldiversity.com/docs/participant-guidelines)を参考に作成されました。_ + +1. 積極的に聞き、注意深く読み、理解すること。 + * 会話に参加する場合は、バックログを読んでください。他の参加者が効果的にコミュニケーションを取る機会を与えてください。 + * 他の参加者の発言の背後には良い意図があると仮定します。オープンソースソフトウェアのコミュニティは非常に多様で、全世界からの参加者がいます。文化的な特性や言語的な特性を理解することが重要です。 + * この分野に新しく参加する人も多くいます。彼らが良い意図を持っているが、まだ言語やアイデアをマスターしていないと仮定してください。私たちは彼らを助けたいと思っています！ +2. 一般化するのではなく、自分自身の経験から話すこと。他人の経験の価値を認識する。他人の代わりに話すことは避けてください。 + * 「彼ら」、「私たち」、「あなた」の代わりに「私」を使ってください。 + * すべての参加者は、他の参加者が自分自身のユニークな経験を持っていることを認識するべきです。 + * 別の参加者の経験を無効にしないでください。 Translation request timed out. 誰かをどのように呼ぶべきかわからない場合は、控えめかつ敬意を持って尋ねてください。例えば、どの代名詞を使用すべきかわからない場合は、プライベートメッセージを送って尋ねてください。正しい代名詞を使うことで他人を尊重することができます。 +8. 一部のオフトピックな会話は許容されます。 + * アナウンスのクロスポストの一部も許容されます。以下の行為は許されません： + * スレッドの乗っ取り + * スパム行為 + * 商業的な広告 + * 露骨な自己宣伝 + * 特に公式の会議時間や集中的な会話中にオフトピックに逸脱すること + * オフトピックな会話を深めるためのより適切な場所や時間を発表することを検討してみてください。 + * 適切な行動が何かわからない場合は、管理者に連絡してください。 +9. ラグーン内のコンテンツを共有する場合は、明確な同意のもとでのみ行ってください。また、共有は慎重に考えて行い、参加者を嫌がらせたり、傷つける意図をもって行わないでください。 + * このフォーラムは公開されていると考えてください。ここに投稿されたものは誰でも読むことができ、実際に読まれる可能性があると想定してください。 + * ラグーンのコンテンツを共有する際は、すべての参加者から事前に許可を得る必要があります。これは、コンテンツが引用されたり、要約されたり、スクリーンショットが撮られたりする場合でも同様です。これには、Twitterや他の公開されているメディアでの共有も含まれます。 ブログ投稿、記事、ポッドキャストなど、これらの場所は議論や作業進行中の場所です。会話の断片を削除すると、コンテキストが失われます。これは、特にラグーンプロジェクトを推進する目的がない場合、議論を歪めたり、阻止したりする可能性があります。 + * 上記で述べた通り、スクリーンショットを撮ってソーシャルメディアや他のフォーラムに投稿する場合、それを投稿した人から許可を取る必要があります。許可を取る際には、識別情報を削除するオプションを含めてください。識別情報を削除した場合でも、許可が必要です。これにはDiscord、Github、その他のラグーンの媒体からの内容も含まれます。 + * 何かを共有したい場合は、ただ聞いてみてください！「ねえ、これをTwitterにシェアしてもいいですか？あなたにクレジットを付けることを喜んでいます！」 + * 参加者がラグーンのモデレーターにハラスメント行為を報告するためにスクリーンショットを撮る必要がある場合、許可を得ることなく行うことができます。ただし、公にまたは私的に個人を恥ずかしくするためにスクリーンショットを撮ることは許されません。これはハラスメント行為の報告にのみ適用されます。 +10. 安全かつ適切な場合には、その場でお互いの苦情を解決してください。 安全である場合、対立が起こった場所で明確化し、関与しようと努めてみてください。例えば、Discordチャンネルで。 + * 対立がエスカレートしている場合は、管理者やコミュニティマネージャー（Alanna）に連絡する。 + * 助けを求める。 + * 対立の主題がLagoonとは関係ない場合は、その会話をより適切なチャンネルへ移動させる。 + +対面でのLagoonスペースにおける追加的な配慮事項 + +1. イベントの行動規範がある場合はそれに従ってください。ない場合は、私たちの行動規範が適用されます。 +2. 人々、彼らの移動装置、または他の補助機器に、その人の同意なく触れないでください。もし誰かがある特定の行動を止めるように頼んだら、すぐに止めてください。 +3. 何か問題があった場合は、イベントのスタッフに報告してください。 +Lagoonチームのメンバーに関する問題の場合は、[uselagoon@amazee.io](mailto:uselagoon@amazee.io)に報告してください。 + +Lagoonチームは、Lagoonのスペースへのアクセスを誰でも終了させる権利を保留しています。 \ No newline at end of file diff --git a/docs/concepts-advanced/backups.ja.md b/docs/concepts-advanced/backups.ja.md new file mode 100644 index 0000000000..dc03f1b62d --- /dev/null +++ b/docs/concepts-advanced/backups.ja.md @@ -0,0 +1,37 @@ +# バックアップ + +Lagoonは、データベースのデータとコンテナの永続的なストレージボリュームの両方のバックアップ機能を提供するために、[k8up operator](https://github.com/vshn/k8up)を使用しています。このオペレータは、これらのバックアップをカタログ化するために[Restic](https://github.com/restic/restic)を利用し、通常はAWS S3バケットに接続して生成されたバックアップの安全なオフサイトストレージを提供します。 + +## プロダクション環境 + +### バックアップスケジュール + +データベースとコンテナの永続的なストレージボリュームのバックアップは、デフォルトでプロダクション環境内で夜間に行われます。 + +プロダクションバックアップの異なるバックアップスケジュールが必要な場合、これはプロジェクトレベルで指定できます。これは、プロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-schedule)ファイルの"Backup Schedule"変数を設定することで行います。 + +### バックアップ保持 + +プロダクション環境のバックアップは、デフォルトで以下のスケジュールに従って保持されます： + +* 日次：7 +* 週次：6 +* 月次：1 +* 時間ごと：0 + +プロダクションバックアップの異なる保持期間が必要な場合、これはプロジェクトレベルで指定できます。これは、プロジェクトの[.lagoon.yml](../concepts-basics/lagoon-yml.md#backup-ret)ファイルの"Backup Retention"変数を設定することで行います。 ention) ファイル。 + +## 開発環境 + +開発環境のバックアップは毎晩試みられ、厳格に最善の努力サービスです。 + +## バックアップの取得 + +Resticに保存されたバックアップはLagoon内で追跡され、Lagoon UIの各環境の「バックアップ」タブから回復することができます。 + +## カスタムバックアップおよび/またはリストア位置 + +Lagoonは、各プロジェクトのLagoon APIに保存されている"[カスタムバックアップ設定](../concepts-advanced/environment-variables.md#custom-backup-settings)"および/または"[カスタムリストア設定](../concepts-advanced/environment-variables.md#custom-restore-location)"変数を使用して、カスタムバックアップとリストアの場所をサポートします。 + +!!! 危険 + 注意して進めてください：これらの変数を設定すると、クラスターレベルで設定されている可能性のあるバックアップ/リストアのストレージ場所が上書きされます。設定が間違っていると、バックアップ/リストアが失敗する原因となります。 \ No newline at end of file diff --git a/docs/concepts-advanced/base-images.ja.md b/docs/concepts-advanced/base-images.ja.md new file mode 100644 index 0000000000..e088fb1937 --- /dev/null +++ b/docs/concepts-advanced/base-images.ja.md @@ -0,0 +1,255 @@ +# ベースイメージ + +## ベースイメージとは何ですか？ + +ベースイメージは、Lagoon上でデプロイされたプロジェクトが使用できる、または使用している[Docker](https://www.docker.com/)イメージです。ベースイメージは、監査されていないものが上流からコードベース/プロジェクトに持ち込まれないようにする方法を提供します。また、デプロイされた環境上で必要となる可能性のあるものがすべて利用可能であることを保証します - 低レベルのライブラリからアプリケーションレベルのテーマとモジュールまで。 + +ベースイメージは、どのシステムがデプロイされているかがわかっている場合、時間とリソースの節約に役立ちます - 共有パッケージがベースイメージに含まれている場合、それらを個々の数百のサイトにデプロイする必要はありません。 + +## 派生イメージ + +派生イメージとは、ベースイメージを拡張するイメージのことを指します。例えば、いくつかのブログサイトを作る必要があるかもしれません。私たちのDrupalイメージを取り、ブログサイトに必要なモジュールとテーマすべてを含めてカスタマイズし、そのブログイメージですべてをデプロイします。テンプレートはベースイメージから派生します。 + +すべての派生イメージは、`composer.json`ファイルを（[Packagist](https://packagist.org/)、[Satis](https://github.com/composer/satis)、または[GitHub](https://github.com/)などのリポジトリ経由で）プルインする必要があります。これにより、それらは 基本パッケージの最新バージョン。 + +さらに、派生イメージには、`/build/pre_composer`スクリプトへの呼び出しが含まれています。これは、基本イメージが派生イメージでスクリプト、アップデートなどを実行するために使用できます。例えば、派生イメージでパッケージが更新またはインストールされると、デフォルトで実行され、`pre_composer`スクリプトはその後、基本イメージパッケージを更新します。 + +## 基本イメージの構造 + +!!! Info + このドキュメントでは、DrupalやLaravelの基本イメージを例に取り上げます。これは、元々Lagoonプロジェクトでこれらのテクノロジーを使用しているクライアント向けに書かれたものです。他の基本イメージの内容もカバーするように拡張されますが、基本イメージの内容に関係なく、プロセスは変わりません。 + +基本イメージは、[Composer](https://getcomposer.org/)で管理され、[BitBucket](https://bitbucket.org/)、[GitHub](https://github.com/)、または[GitLab](https://gitlab.com/) \(チームが使用しているもの\)にホストされています。各基本イメージには独自のリポジトリがあります。 + +### メタパッケージ + +メタパッケージは、複数の他のコンポーネントを包括するComposerパッケージです。これには、例えば、LaravelやDrupalのコアファイル、必要なモジュールなどが含まれます。 またはテーマ。これにより、プロジェクトの依存関係に Laravel や Drupal などを含める必要がありません。 + +以下は、Laravel ベースのイメージの `composer.json` からの例です： + +```text title="composer.json" +"require": { + "amazeelabs/algm_laravel_baseimage": "*" +}, +``` + +私たちはこのメタパッケージだけを必要とし、これは GitHub のリポジトリを指しています。 + +### `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 コンソール](https://drupalconsole.com/) +* [Drush](https://www.drush.org/) +* [設定インストーラ](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) +* [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) +* [CDN](https://www.drupal.org/project/cdn) +* [Password Policy](https://www.drupal.org/project/password_policy) +* [Pathauto](https://www.drupal.org/project/pathauto) +* [Ultimate Cron](https://www.drupal.org/project/ultimate_cron) + +### Laravel + +#### 設定 + +基本イメージは、Laravelで使用される環境変数のデフォルト値を提供しています。 + +これらは以下の値です： + +* `DB_CONNECTION` +* `DB_HOST` +* `DB_PORT` +* `DB_DATABASE` +* `DB_USERNAME` +* `DB_PASSWORD` +* `REDIS_HOST` +* `REDIS_PASSWORD` +* `REDIS_PORT` + +設定ファイル（通常は`/config`に位置しています）がこれらをデフォルトで使用するように確認してください。 + +#### キュー + +プロジェクトが[キュー](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`のコメントをご覧ください。 + +## ビルドプロセスの理解 ベースイメージ + +ベースイメージを構築するプロセスにはいくつかの部分があります。主要なステップはすべてMakefileに記載されています。Jenkinsfileにはよりシンプルなビューが含まれています。これらのファイルを見ることで、このプロセス中に何が起こるかをよく理解することができます。ほとんどのステップはローカルでテストできます（これは新しいバージョンのベースイメージを構築する際に重要です）。ローカルで全てを作成し、テストした後にプッシュすると、実際のベースイメージは[Jenkins](https://jenkins.io/)によって構築され、[Harbor](../using-lagoon-advanced/using-harbor/README.md)にプッシュされます。 + +### Makefileとビルドの前提条件 + +ローカルで実行する予定の場合、少なくとも必要な環境変数が存在する必要があります。 + +### ベースイメージビルド変数 + +ベースイメージビルドプロセスに注入される変数と、それを見つける場所。 + +* `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`を手動で実行する必要があります。 + +実際には、ローカルマシンで`make`ターゲットを実行している場合、これらが環境で利用可能であることを確認したいと思うでしょう - たとえば、コマンドラインからmakeを実行するときにこれらを設定するだけでも構いません： + +```bash title="ローカルでmakeターゲットを設定する" +GIT_BRANCH=example_branch_name DOCKER_HUB=the_docker_hub_the_images_are_pushed_to DOCKER_REPO=your_docker_repo_here BUILD_NUMBER= make images_remove +``` + +### Makefile targets + +最も重要なターゲットは以下の通りです： + +* `images_build` : 環境変数を指定すると、画像をビルドしてタグを付けて公開します。 +* `images_publish` : ビルドされた画像をDockerリポジトリにプッシュします。 +* `images_start` : テストなどのためにイメージを開始します。 +* `images_test`：イメージに対して基本的なテストを実行します。 +* `images_remove`：ビルド環境変数が与えられると、以前にビルドされたイメージを削除します。 + +### ベースイメージの新リリースをビルドするための例のワークフロー + +ビルドプロセスにはいくつかのステップがあります。これらのほとんどは、さまざまなベースイメージ間で共有されています。これらは主に上記で説明したMakefileターゲットに対応しています。 + +1. **Dockerログイン** - Dockerのユーザー名、パスワード、HarborのURLがDockerクライアントに渡されます。 +2. **Dockerビルド** - `make images_build`ステップが現在実行されます。これにより以下のことが行われます： + 1. すべての環境変数がビルドの準備ができていることを確認します。 + 2. `docker-compose build`を実行します。これにより、現在のGitブランチからいくつかの新しいDockerイメージが生成されます。 +3. **イメージテスト** - これにより`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ホストから単純に削除します。 + +#### ベースイメージの新バージョンのリリース + +ベースイメージの新バージョンをリリースする理由は多々あります。DrupalやLaravel、Node.jsなどのイメージでは、機能やセキュリティのためにモジュール/パッケージをアップグレードまたはインストールするためかもしれません。また、コンテナにバンドルされている基本ソフトウェアのバージョンを更新することもあります。例えば、PHPやNode.jsのバージョンを更新するなどです。また、ベースイメージがビルドされている実際の基本的な_イメージ_を更新することもあります。 + +あなたのプロジェクトのベースイメージがビルドされているイメージは、Lagoonチームによって管理されているイメージです。これらの基本イメージは月に一回（またはそれ以上）の頻度で更新されます。これらが更新されたとき、あなたはアップストリームのイメージにバンドルされている変更とアップグレードを取り入れるために、自分自身のベースイメージの新バージョンをビルドする必要があります。 + +このセクションでは、そのプロセスを示します。 Drupal 8基本イメージの新リリースを更新およびタグ付けします。我々は新しいモジュール（[ClamAV](https://www.drupal.org/project/clamav)）を基に追加します。Drupalをデモンストレーションするのは、基本イメージの中で最も複雑なセットアップを持っているからです。すべての基本イメージに共通する手順は以下に記載されています。 + +#### ステップ1 - 基本イメージをローカルにダウンロードする + +これは単にGitリポジトリをローカルにダウンロードすることです。Drupal 8基本イメージの場合です。この例では、Bitbucketを使用しているので、次のコマンドを実行します： + +```bash title="Clone Git repo." +git clone ssh://git@bitbucket.biscrum.com:7999/webpro/drupal8_base_image.git +``` + +![基本イメージリポジトリで\`git clone\`を実行します。](../images/0.gif) + +#### ステップ2 - リポジトリに変更を加える + +!!! Info + ここで示されていることはDrupal 8基本イメージに特有のものです。しかし、変更（ファイルの追加、基本的なDockerイメージの変更など）はすべての基本イメージでこのステップで行われます。 + +我々の例では、ClamAVモジュールをDrupal 8基本イメージに追加しています。これにはいくつかのステップが関与します。最初はパッケージを必要とすることで、これにより我々の`composer.json`ファイルに追加されます。これは`composer require`を実行することで行われます。 + +ここで我々は実行します： ```bash title="Composer requireでパッケージをインストールする。" +composer require drupal/clamav +``` + +![`composer require drupal/clamav`を実行](../images/step2_require.gif) + +Composer requireのプロセスが完了すると、パッケージは`composer.json`ファイルに表示されるべきです。 + +ここでは、`composer.json`ファイルを開き、必要なパッケージのリストを見て、ClamAVパッケージがリストされていることを確認し、それがそこにあることを確認します： + +![ClamAVが必要とされていることを確認するためにcomposer.jsonを開く](../images/2.gif) + +#### ステップ2.2 - テンプレートベースの派生イメージで必要なDrupalモジュールが有効になっていることを確認する + +ベースイメージに追加された任意のモジュールは、テンプレートベースの派生イメージで有効にする必要があります。これは、モジュールをLagoon Bundleモジュールに追加することで行われます。これは具体的には、`dependencies`セクションの`lagoon_bundle.info.yml`ファイルに依存性として追加することを要求します。Lagoon Bundleモジュールは、派生イメージ間の依存関係を強制するためだけに存在するユーティリティモジュールです。 + +ここでは、`web/modules/contrib/lagoon/lagoon_bundle/lagoon_bundle.info.yml`を開き、`clamav:clamav`を追加します。 依存関係: + +![Lagoon Bundleの依存関係としてClamAVを追加する。](../images/3.png) + +これに依存関係を追加することで、派生したイメージ上でLagoon Bundleモジュールが有効になるたびに、その依存関係（この場合、新たに追加されたClamAVモジュール）も有効になることを保証します。これは、ロールアウト時に`lagoon_bundle`を派生イメージで有効にするポストロールアウトスクリプトで強制されます。 + +#### ステップ2.3 - テスト + +これはあなたが何をテストしているかによります。ClamAVモジュールを追加する場合、ベースイメージでモジュールがダウンロードされ、Lagoon Bundleモジュールが有効化されたときにClamAVも有効化されることを確認したいと考えています。 + +ここでは、モジュールが`/app/web/modules/contrib`にダウンロードされたことを確認します： + +![/app/web/modules/contribをチェックして、ClamAVがダウンロードされていることを確認する。 ](../images/4.gif) + +そして、`lagoon_bundle`モジュールを有効化するときに、`clamav`も有効化されることを確認するために、以下のコマンドを実行します： + +```bash title="Drushでモジュールを有効化する。" +drush pm-enable lagoon_bundle -y +``` + +![`drush pm-enable lagoon_bundle -y`を実行し、それがClamAVも有効化することを確認する](../images/5.gif) + +!!! 警告 + 上記のコンテナでJWTエラーが発生していることが分かるでしょう。これは安全に無視することができます 上記のデモンストレーションでは、背景として、あなたが作業しているサイトのためのラグーン環境が存在しない場合にこのエラーが表示されます。 + +テストが終了したので、イメージをタグ付けしてビルドすることができます。 + +#### ステップ3 - イメージのタグ付け + +イメージは、[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ベースイメージの新しいバージョンをタグ付けします。 + +#### ここでは、イメージのタグ付け方法を示します + +私たちは、`git log`を使用して、通常のコミットやプッシュと同じように、変更をコミット（しかしプッシュはしない）したことを確認します。 + +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`で我々の全ての変更をプッシュします。 + +!!! 危険 + タグはそれ自体のステップで明示的にプッシュされなければなりません！ + +![ベースイメージをタグ付けしてプッシュする方法を示す](../images/6.gif) + +#### Gitのタグがイメージのタグにどのようにマッピングされるか + +!!! 危険 + ビルドワークフローによりますが、ほぼ確実に**develop**ブランチ経由で変更をプッシュし、それを**main**ブランチにマージするでしょう。 + +ここで覚えておくべき重要な点は、Jenkinsのベースイメージのビルドプロセスは、_最新のコミットタグ_に基づいて_イメージ_をタグ付けするということです。 + +イメージは以下のルールでタグ付けされ、これに該当するものごとにイメージがビルドされます： + +1. **main**ブランチがビルドされると、`latest`としてタグ付けされます。 +2. developブランチがビルドされると、`development`としてタグ付けされます。 +3. ビルドされるコミットが_タグ付け_されていれば、そのブランチはそのコミットのタグ付けでビルドされます。 + 1. これは我々が上で示した新しいバージョンをリリースする方法です。これはまた、かなり任意のタグでアドホックなビルドを行うためにも使用できます - タグ名は適切であるべきです、それは_セマンティックバージョニング_のタグでのみテストされています。 + +#### ステップ4 - 新しいベースイメージのビルド + +!!! 情報 一般的には、自動ビルドのためのトリガー戦略がここに設定されていますが、それはあなたのニーズや設定によって異なるため、ここでは手動でビルドする方法を説明します。 + +1. あなたのLagoon Jenkinsインスタンスを訪れます。 +2. 作業中のプロジェクト（この場合、AIOBI Drupal 8 Base）を選択します。 +3. ビルドしたいブランチをクリックします。 +4. 「Build Now」をクリックします。 + +![Jenkins UIでベースイメージをビルドする方法を示す](../images/7.gif) + +これにより、ビルドプロセスが開始され、成功すれば新しいイメージをHarborにプッシュします。 + +ビルドが成功しない場合は、ビルド自体をクリックしてログを読み、どこで失敗したかを理解することができます。 + +下のHarborからのスクリーンショットで示されているように、私たちがJenkinsでビルドしたばかりのイメージはHarborにアップロードされ、タグ付けされています。ここでは、それがv0.0.9とタグ付けされているため、そのタグのついたイメージが存在します。また、私たちは**main**ブランチをビルドしたので、「latest」イメージもビルドされました。この段階では、v0.0.9と「latest」のイメージは同一です。 + +![アップロードされ、タグ付けされたイメージを示すHarborからのスクリーンショット](../images/8.png) + +## 謝辞 + +ベースイメージの構造は、実際には、 [Denpal](https://github.com/dennisarslan/denpal)のフォークです。これは元の[Drupal Composer Template](https://github.com/drupal-composer/drupal-project)に基づいていますが、Lagoon（ローカル開発環境またはホストされたLagoon）で実行するために必要なすべてを含んでいます。 \ No newline at end of file diff --git a/docs/concepts-advanced/environment-idling.ja.md b/docs/concepts-advanced/environment-idling.ja.md new file mode 100644 index 0000000000..6f3cf428a3 --- /dev/null +++ b/docs/concepts-advanced/environment-idling.ja.md @@ -0,0 +1,28 @@ +# 環境アイドリング（オプション） + +## 環境アイドラーとは何ですか？ + +Lagoonは、[Aergiaコントローラー](https://github.com/amazeeio/aergia-controller)（`lagoon-remote`にインストールされています）を利用して、一定期間使用されていない環境を自動的にアイドル状態にします。これは、Kubernetesクラスタの負荷を軽減し、実際に使用中の本番環境と開発環境の全体的なパフォーマンスを向上させるために行われます。 + +### 環境はどのようにしてアイドル状態になりますか？ + +環境アイドラーには多くの異なる設定機能があります。ここでは、標準的なLagoonインストールのデフォルトを示します（これらはあなたのLagoonでは全く異なる可能性がありますので、Lagoon管理者に確認してください！） + +* アイドリングは4時間ごとに試みられます。 +* 本番環境は決してアイドル状態になりません。 +* CLIポッドは、cronジョブが含まれておらず、リモートシェル接続がアクティブでない場合にアイドル状態になります。 +* 他のすべてのサービスとポッドは、環境上で過去4時間間にトラフィックがなかった場合にアイドル状態になります。 +* アクティブなビルドが進行中であれば、アイドリングは行われません。 + +### 環境はどのようにしてアイドル状態から解除されますか？ + +Aergiaは、環境が訪問されるとすぐに自動的にアイドル状態を解除します。 したがって、環境の任意のURLを訪れるだけで環境が起動します。同様に、環境へのSSHセッションを開始すると、サービスも再開します。 + +アンアイドリングは数秒かかります。なぜなら、Kubernetesクラスタはすべてのコンテナを再起動する必要があるからです。この間、訪問者には、現在自分の環境が起動中であることを示す待機画面が表示されます。 + +### Idlerが私の環境をアイドリングしないように設定することはできますか？ + +はい、プロジェクト（すべての環境に影響）と環境（1つの環境のみを対象にする必要がある場合）に`autoIdle`フィールドがあり、アイドリングが行われるかどうかを指定できます。`1`の値は、プロジェクト/環境がアイドリングの対象であることを示します。プロジェクトが`0`に設定されている場合、環境が`0`に設定されていても、環境は決してアイドル状態になりません。 +デフォルトは常に`1`（アイドリングが有効）です。 + +これらのプロジェクト/環境フィールドの設定方法がわからない場合は、あなたのLagoon管理者に相談してください。 \ No newline at end of file diff --git a/docs/concepts-advanced/environment-types.ja.md b/docs/concepts-advanced/environment-types.ja.md new file mode 100644 index 0000000000..efdb3c711b --- /dev/null +++ b/docs/concepts-advanced/environment-types.ja.md @@ -0,0 +1,17 @@ +# 環境の種類 + +Lagoonは現在、`production（本番環境）`と`development（開発環境）`の2つの異なる環境タイプを区別しています。 + +Lagoon GraphQL APIを通じてプロジェクトを設定する際には、`productionEnvironment`を定義することができます。Lagoonが実行するすべてのデプロイメントで、現在の環境名が`productionEnvironment`で定義されているものと一致するかどうかをチェックします。もしそうであれば、Lagoonはこの環境を`production`環境としてマークします。これは2つの場所で行われます： + +1. GraphQL API自体内で。 +2. すべてのコンテナ内で`LAGOON_ENVIRONMENT_TYPE`という名前の環境変数として。 + +しかしそれだけです。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では、ホスティングの価格を計算するために、プロダクション環境のヒット数だけを計算しています。 \ No newline at end of file diff --git a/docs/concepts-advanced/environment-variables.ja.md b/docs/concepts-advanced/environment-variables.ja.md new file mode 100644 index 0000000000..cabf689f18 --- /dev/null +++ b/docs/concepts-advanced/environment-variables.ja.md @@ -0,0 +1,207 @@ +# 環境変数 + +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`で定義された環境変数（存在する場合）、これを全ての変数の上書きに使用します。 ブランチ。 +6. `.env`で定義された環境変数。 +7. `.env.defaults`で定義された環境変数。 + +`.lagoon.env.$LAGOON_GIT_BRANCH`、`.lagoon.env.$LAGOON_GIT_SAFE_BRANCH`、`.env`、そして `.env.defaults`は、全て、各コンテナ自体によってエントリーポイントスクリプトの一部として実行される際にソース化されます。それらはLagoonではなく、コンテナの `ENTRYPOINT` スクリプトによって読み込まれ、コンテナの作業ディレクトリでそれらを探します。環境変数が期待通りに表示されない場合は、コンテナに他の場所を指す `WORKDIR` 設定があるかどうかを確認してください。 + +## 環境変数（Lagoon API） + +Gitリポジトリに保存したくない変数（シークレットやAPIキーなど）については、Lagoon APIの環境変数システムを使用することをお勧めします。これらの変数は、誰かがローカルの開発環境やインターネット上に持っていると、危険にさらされる可能性があります。 + +Lagoon APIでは、プロジェクト全体または環境固有の変数を定義することができます。さらに、スコープ限定のビルド時またはランタイムに対して定義することもできます。これらはすべてLagoon GraphQL APIを通じて作成されます。GraphQL APIの使用方法については、[GraphQL API](../interacting/graphql.md)のドキュメンテーションで詳しく説明しています。 + +### ランタイム環境変数（ラグーンAPI） + +ランタイム環境変数は自動的にすべてのコンテナで利用可能になりますが、環境が再デプロイされた後にのみ追加または更新されます。 + +これは、ID `463`のプロジェクト用にプロジェクト全体のランタイム変数（すべての環境で利用可能）を定義します： + +```graphql title="ランタイム変数の追加" +mutation addRuntimeEnv { + addEnvVariable( + input:{ + type:PROJECT, + typeId:463, + scope:RUNTIME, + name:"MYVARIABLENAME", + value:"MyVariableValue" + } + ) { + id + } +} +``` + +これは、環境ID `546`特有のランタイム変数（特定の環境のみで利用可能）を定義します： + +```graphql title="環境IDの定義" +mutation addRuntimeEnv { + addEnvVariable( + input:{ + type:ENVIRONMENT, + typeId:546, + scope:RUNTIME, + name:"MYVARIABLENAME", + value:"MyVariableValue" + } + ) { + id + } +} +``` + +### ビルド時の環境変数（ラグーンAPI） + +ビルド時の環境変数はビルド中にのみ利用可能であり、Dockerfilesで以下のように使用する必要があります： + +```graphql title="ビルド時の環境変数の使用" +ARG MYVARIABLENAME +``` + +通常、`ARG`はその後に行くでしょう。 FROM. [ARGとFROMについてのdockerドキュメントを読む](https://docs.docker.com/engine/reference/builder/#understand-how-arg-and-from-interact)。 + +これは、ID `463`のプロジェクト全体のビルド時変数（すべての環境で利用可能）を定義します。 + +```graphql title="プロジェクト全体のビルド時変数を定義する" +mutation addBuildtimeEnv { + addEnvVariable( + input:{ + type:PROJECT, + typeId:463, + scope:BUILD, + name:"MYVARIABLENAME", + value:"MyVariableValue"} + ) { + id + } +} +``` + +これは、環境ID `546`特有のビルド時変数を定義します（その特定の環境内だけで利用可能）。 + +```graphql title="環境IDを定義する" +mutation addBuildtimeEnv { + addEnvVariable(input:{type:ENVIRONMENT, typeId:546, scope:BUILD, name:"MYVARIABLENAME", value:"MyVariableValue"}) { + id + } +} +``` + +コンテナレジストリの環境変数は、ビルド中にのみ利用可能で、プライベートレジストリにログインしようとするときに使用されます。これらは、[Specials » `container-registries`](../concepts-basics/lagoon-yml.md#specials)で定義されたユーザーのパスワードを保存するために使用されます。これらはプロジェクトレベルまたは環境レベルで適用することができます。 + +これは、プロジェクト全体を定義します プロジェクトID `463`のためのコンテナレジストリ変数（すべての環境で利用可能）： + +```graphql title="プロジェクト全体のコンテナレジストリ変数を定義する" +mutation addContainerRegistryEnv { + addEnvVariable( + input:{ + type:PROJECT, + typeId:463, + scope:CONTAINER_REGISTRY, + name:"MY_OWN_REGISTRY_PASSWORD", + value:"MySecretPassword"}) + ) { + id + } +} +``` + +これは、環境ID `546`特有のコンテナレジストリ変数を定義します（その特定の環境内でのみ利用可能）： + +```graphql title="環境IDを定義する" +mutation addContainerRegistryEnv { + addEnvVariable( + input:{ + type:ENVIRONMENT, + typeId:546, + scope:CONTAINER_REGISTRY, + name:"MY_OWN_REGISTRY_PASSWORD", + value:"MySecretPassword"} + ) { + id + } +} +``` + +### グローバル環境変数（Lagoon API） + +グローバル環境変数は、ビルドによって消費されるためのビルド時環境変数として、また実行中のコンテナ内で利用可能なランタイム変数として利用できます。 + +## 環境ファイル（Gitリポジトリ内に直接存在する） + +Gitリポジトリ内に安全に保存できる環境変数がある場合、追加することをお勧めします Gitリポジトリの環境ファイルに直接入力します。これらの変数はローカル開発環境でも利用可能であり、より移植性が高いです。 + +環境ファイルの構文は次のとおりです： + +```bash title="myenvironment.env" +MYVARIABLENAME="MyVariableValue" +MVARIABLENUMBER=4242 +DB_USER=$DB_USERNAME # DB_USERNAMEの値でDB_USERを再定義します。例えば、アプリケーションがLagoon提供の変数に対して別の変数名を期待している場合などです。 +``` + +### `.lagoon.env.$BRANCHNAME` + +環境ごとに異なる環境変数を定義したい場合は、`.lagoon.env.$BRANCHNAME`を作成できます。例えば、メインブランチの場合は`.lagoon.env.main`です。これにより、環境間での環境変数の区別が容易になります。 + +### `.env` and `.env.defaults` + +`.env`と`.env.defaults`は、他に定義されていない場合の環境変数のデフォルト値として機能します。例えば、プルリクエスト環境用のデフォルト環境変数として（[Workflows](workflows.md#pull-requests)参照）。 + +## 特別な環境変数 + +### `PHP_ERROR_REPORTING` + +この変数が設定されている場合、PHPが使用する[ログ](../logging/logging.md)レベルを定義します。指定されていない場合は、それが これはプロダクション環境か開発環境かによって動的に設定されます。 + +プロダクション環境では、この値はデフォルトで`E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE`になります。 + +開発環境では、この値はデフォルトで`E_ALL & ~E_DEPRECATED & ~E_STRICT`になります。 + +### カスタムバックアップ設定 + +Lagoonは、次の4つの変数すべてが`BUILD`タイプの変数として設定されている場合、任意のプロジェクトのカスタムバックアップ場所と認証情報をサポートします。環境変数はプロジェクトレベルで（環境ごとではなく）設定する必要があり、それらを設定した後にLagoonのデプロイメントが必要です（すべての環境について）。 + +これらの変数のいずれかを使用すると、Lagoonが作成および管理するすべての環境とデータベースのバックアップがこれらの認証情報を使用して格納されることを意味します。つまり、これらの認証情報の中断がバックアップの失敗またはアクセス不能を引き起こす可能性があります。 + +| 環境変数名 | 目的 | +|:---------------------------------------|:---------------------------------------------------------------- Translation request timed out. `BUILD`タイプの環境変数として以下の全4つの変数が設定されている場合、任意のプロジェクトに対してカスタムリストアロケーションと資格情報を設定できます。環境変数はプロジェクトレベルで設定する必要があり（環境ごとではなく）、それらを設定した後、Lagoonのデプロイが必要です（各環境について）。 + +これらの変数を使用すると、Lagoonによって復元されたすべての環境とデータベースのスナップショットがこれらの資格情報を使用して保存されることに注意してください。これは、これらの資格情報へのアクセスが中断されると、復元されたファイルの失敗またはアクセス不能につながる可能性があることを意味します。 + +| 環境変数名 | 目的 | +|:----------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| `LAGOON_BAAS_CUSTOM_RESTORE_ENDPOINT` | Lagoonが開始した復元を保存するべきS3互換エンドポイントを指定します。S3シドニーの例は次の通りです：`https://s3.ap-southeast-2 Translation request timed out. ``` +リソース": [ + "arn:aws:s3:::example-restore-bucket" + ] + }, + { + "Effect": "Allow", + "Action": [ + "s3:PutObject", + "s3:GetObject", + "s3:GetObjectVersion", + "s3:GetBucketLocation", + "s3:PutObjectAcl" + ], + "Resource": [ + "arn:aws:s3:::example-restore-bucket/*" + ] + } + ] +} + +増強されたセキュリティと削減されたストレージコストのために、[設定されたライフタイム後に復元されたバックアップを削除する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html)（例えば、7日間）を選択することができます。Lagoonはこのシナリオをうまく処理し、必要に応じて復元されたスナップショットを再作成します。 +``` \ No newline at end of file diff --git a/docs/concepts-advanced/feature-flags.ja.md b/docs/concepts-advanced/feature-flags.ja.md new file mode 100644 index 0000000000..dc2164b2d8 --- /dev/null +++ b/docs/concepts-advanced/feature-flags.ja.md @@ -0,0 +1,21 @@ +＃フィーチャーフラグ + +Lagoonの一部の機能は、フィーチャーフラグを設定することで制御できます。 +これは、新しいプラットフォーム機能を制御された方法で展開するためのユーザーと管理者を支援するように設計されています。 + +## 環境変数 + +以下の環境変数は、フィーチャーフラグを切り替えるために環境またはプロジェクトに設定することができます。 + +| 環境変数名 | アクティブスコープ | 導入されたバージョン | 削除されたバージョン | デフォルト値 | 説明 | +| --- | --- | --- | --- | --- | --- | | +| `LAGOON_FEATURE_FLAG_ROOTLESS_WORKLOAD` | `global` | 2.2.0 | - | `無効` | この環境またはプロジェクトのポッドに非rootポッドセキュリティコンテキストを設定するには、`有効`に設定します。

このフラグは最終的に廃止され、その時点で非rootワークロードが強制されます。 | +| `LAGOON_FEATURE_FLAG_ISOLATION_NETWORK_POLICY` | `global` | 2.2.0 | - | `無効` | デプロイ時に各環境にデフォルトの名前空間分離ネットワークポリシーを追加するには、`有効`に設定します。

このフラグは最終的に廃止され、その時点で名前空間分離ネットワークポリシーが強制されます。

注: この機能を有効にしてから無効にすると、既存のネットワークは削除されません。 以前のデプロイからのポリシー。これらは手動で削除する必要があります。| + +## クラスターレベルのコントロール + +機能フラグはクラスターレベルでも制御することができます。これに対応している[`lagoon-build-deploy`チャート](https://github.com/uselagoon/lagoon-charts/blob/main/charts/lagoon-build-deploy/values.yaml)があります。 +各機能フラグには、設定できる値が2種類あります：`default`と`force`。 + +* `default`は、クラスターにデプロイされる環境のデフォルトポリシーを制御しますが、上記の環境変数によってプロジェクトレベルまたは環境レベルで上書きすることができます。 +* `force`もクラスターにデプロイされる環境のポリシーを制御しますが、上記の環境変数によって上書きすることは_できません_。 \ No newline at end of file diff --git a/docs/concepts-advanced/index.ja.md b/docs/concepts-advanced/index.ja.md new file mode 100644 index 0000000000..8cbccc5e16 --- /dev/null +++ b/docs/concepts-advanced/index.ja.md @@ -0,0 +1,5 @@ +# 高度なラグーンの概念 + +このセクションでは、ラグーンのより高度な概念について説明します。ラグーンが初めての方は、まず[基本的なラグーンの概念](../concepts-basics/index.md)から始めてください。 + +助けが必要な場合は、ラグーンの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティやメンテナーに連絡してください。 \ No newline at end of file diff --git a/docs/concepts-advanced/service-types.ja.md b/docs/concepts-advanced/service-types.ja.md new file mode 100644 index 0000000000..69eb4dbd1a --- /dev/null +++ b/docs/concepts-advanced/service-types.ja.md @@ -0,0 +1,263 @@ +# サービスタイプ + +以下に示すのは、[`docker-compose.yml` ファイル](../concepts-basics/docker-compose-yml.md)内の `lagoon.type` を通じて定義できるすべてのサービスタイプです。 + +!!! 警告 + 一度 `lagoon.type` が定義され、環境がデプロイされると、異なるタイプに変更することはサポートされておらず、環境が壊れる可能性があります。 + +## `basic` + +基本的なコンテナで、既存のテンプレートがないアプリケーションのほとんどに適しています。永続的なストレージはありません。ポートはラベルを使用して変更できます。[自動生成されたルート](../concepts-basics/docker-compose-yml.md#auto-generated-routes)が必要でない場合（例：内部向けサービスの場合）、docker-compose.yml 内で `lagoon.autogeneratedroute: false` を設定します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `3000` 上の TCP 接続 | `3000` | はい | いいえ | `lagoon.service.port`, `lagoon.autogeneratedroute` | + +## `basic-persistent` + +`basic`と同じです。また、永続的なストレージを生成し、`lagoon.persistent` を通じてマウントの位置を定義します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | --- | :--- | :--- | :--- | +| `3000`上のTCP接続 | `3000` | はい | はい | `lagoon.service.port`, `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` | + +## `cli` + +PHP、Node.jsなど、任意のCLIコンテナに使用します。 `/var/run/secrets/lagoon/sshkey/ssh-privatekey`にマウントされている顧客のSSHプライベートキーが自動的に取得されます。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | その他のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | いいえ | いいえ | いいえ | - | + +## `cli-persistent` + +`cli`と同様に、`lagoon.persistent.name`が永続ストレージを持つサービスの名前を指定されることを期待しています。それは定義された`lagoon.persistent`ラベルの下にマウントされます。自身の永続ストレージを生成せず、別のサービスの永続ストレージをマウントするためだけに使用されます。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | その他のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | いいえ | いいえ | はい | `lagoon.persistent.name`, `lagoon.persistent` | + +## `elasticsearch` + +Elasticsearchコンテナは、`/usr/share/el`の下に永続ストレージを自動生成します。 `elasticsearch/data`。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `localhost:9200/_cluster/health?local=true` 上のHTTP | 9200 | なし | はい | `lagoon.persistent.size` | + +## `kibana` + +Kibanaコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `5601` 上のTCP接続 | `5601` | はい | なし | - | + +## `logstash` + +Logstashコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `9600` 上のTCP接続 | `9600` | なし | なし | - | + +## `mariadb` + +Lagoonに自動的に`mariadb-single`と`mariadb-dbaas`の間を決めるように指示するメタサービス。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | - | - | - | - | + +## `mariadb-single` + +MariaDBコンテナ。`/lagoon/mysql-backup.sh 127.0.0.1`を実行するバックアップのcronジョブを24時間ごとに作成します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | + | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `3306`でのTCP接続 | `3306` | なし | はい | `lagoon.persistent.size` | + +## `mariadb-dbaas` + +DBaaSオペレーターを介した共有MariaDBサーバーを使用します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| 不要 | `3306` | なし | - | - | + +## `mongo` + +Lagoonに`mongo-single`と`mongo-dbaas`の間で自動的に決定させるメタサービス。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | - | - | - | - | + +## `mongo-single` + +MongoDBコンテナー、`/data/db`にマウントされた最小1GBの永続ストレージを生成します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `27017`でのTCP接続 | `27017` | なし | はい | `lagoon.persistent.size` | + +## `mongo-dbaas` + +DBaaSオペレーターを介した共有MongoDBサーバーを使用します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| 不要 | `27017` | いいえ | - | - | + +## `nginx` + +NGINXコンテナ。永続的なストレージはありません。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `localhost:50000/nginx_status` | `8080` | はい | いいえ | `lagoon.autogeneratedroute` | + +## `nginx-php` + +`nginx`と同じですが、追加で`php`コンテナがあります。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| NGINX: `localhost:50000/nginx_status`, PHP: `/usr/sbin/check_fcgi` | `8080` | はい | いいえ | `lagoon.autogeneratedroute` | + +## `nginx-php-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` | + +## `node` + +Node.js コンテナ。永続的なストレージはありません。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `3000`でのTCP接続 | `3000` | はい | なし | `lagoon.autogeneratedroute` | + +## `node-persistent` + +`node`と同様。永続的なストレージを生成し、`lagoon.persistent`を介してマウント場所を定義します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `3000`でのTCP接続 | `3000` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent`, `lagoon.persistent.name`, `lagoon.persistent.size`, `lagoon.persistent.class` | + +## `none` + +Lagoonにこのサービスを完全に無視するよう指示します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | - | - | - | - | + +## `opensearch` + +OpenSearchコンテナ、`/usr/share/opensearch/data`以下に永続的なストレージを自動生成します。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `localhost:920`でのHTTP 0/_cluster/health?local=true` | 9200 | いいえ | はい | `lagoon.persistent.size` | + +## `postgres` + +Lagoonが自動的に`postgres-single`と`postgres-dbaas`の間を判断するように指示するメタサービス。 + +| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | - | - | - | - | + +## `postgres-single` + +Postgresコンテナ。バックアップ用のcronジョブを作成し、それは24時間ごとに`/lagoon/postgres-backup.sh localhost`を実行します。 + +| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `5432`でのTCP接続 | `5432` | いいえ | はい | `lagoon.persistent.size` | + +## `postgres-dbaas` + +DBaaS Operator経由で共有PostgreSQLサーバを利用します。 + +| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| 不要 | `5432` | いいえ | - | - | + +## `python` + +Pythonコンテナ。永続ストレージはありません。 + +| 健康チェック | 露出ポート | 自動生成ルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `880でのHTTP接続 0` | `8800` | はい | いいえ | `lagoon.autogeneratedroute` | + +## `python-persistent` + +永続ストレージを備えたPythonコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `8800`上のHTTP接続 | `8800` | はい | はい | `lagoon.autogeneratedroute` | + +## `redis` + +Redisコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `6379`上のTCP接続 | `6379` | いいえ | いいえ | - | + +## `redis-persistent` + +`/data`以下にマウントされた自動生成の永続ストレージを備えたRedisコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `6379`上のTCP接続 | `6379` | いいえ | はい | `lagoon.persistent.size` | + +## `solr` + +`/var/solr`以下にマウントされた自動生成の永続ストレージを備えたSolrコンテナ。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | 追加カスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| `8983`上のTCP接続 | `8983` | いいえ | はい | `lagoon.persistent.size` | + +## `varnish` + +バーニッシュコンテナー。 + +| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| HTTPリクエスト `localhost:8080/varnish_status` | `8080` | はい | いいえ | `lagoon.autogeneratedroute` | + +## `varnish-persistent` + +`/var/cache/varnish` 下にマウントされた自動生成される永続的なストレージを持つバーニッシュコンテナー。 + +| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| HTTPリクエスト `localhost:8080/varnish_status` | `8080` | はい | はい | `lagoon.autogeneratedroute`, `lagoon.persistent.size` | + +## `worker` + +任意の種類のワーカーコンテナー（キューワーカーなど）で、公開サービスポートがない場合に使用します。 + +| ヘルスチェック | 公開ポート | 自動生成されたルート | ストレージ | 追加のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | いいえ | いいえ | いいえ | - | + +## `worker-persistent` + +`worker`と同様に、`lagoon.persistent.name`が永続的なストレージを持つサービスの名前を与えられることを期待し、定義された`lagoon.persistent`ラベルの下にマウントされます。自身の永続的なストレージを生成することはありません、ただし使用されます。 他のサービスの永続的なストレージをマウントする。 + +| ヘルスチェック | 公開ポート | 自動生成ルート | ストレージ | その他のカスタマイズパラメータ | +| :--- | :--- | :--- | :--- | :--- | +| - | いいえ | いいえ | はい | `lagoon.persistent.name`, `lagoon.persistent` | \ No newline at end of file diff --git a/docs/concepts-advanced/workflows.ja.md b/docs/concepts-advanced/workflows.ja.md new file mode 100644 index 0000000000..f8ebe1b1c2 --- /dev/null +++ b/docs/concepts-advanced/workflows.ja.md @@ -0,0 +1,93 @@ +# ワークフロー + +Lagoonは、可能な限り多様な開発ワークフローをサポートしようとしています。特に、チームに対して特定のワークフローを強制することなく、各開発チームが自分たちのコードをどのように開発しデプロイするかを定義できます。 + +## 固定ブランチ + +最も直接的なワークフローは、いくつかの固定ブランチに基づいたデプロイメントです： + +Lagoonがデプロイすべきブランチ（例えば `develop`、`staging`、`main`など、これらは正規表現で `^(develop|staging|main)$`となります）を定義し、それを実行します。それで完了です！ + +新しい機能をテストしたい場合は、ローカルで設定したブランチにそれらをマージしてプッシュし、Lagoonがその機能をデプロイします。すべてが良ければ、そのブランチをあなたの本番ブランチにマージしてプッシュします。 + +## フィーチャーブランチ + +もう少し高度なものになると、フィーチャーブランチがあります。Lagoonは、デプロイしたいブランチを正規表現で定義する能力をサポートしているので、上記の正規表現をこのように拡張することもできます：`^feature\/|^(staging|main)$`。これにより、Lagoonは`feature/`で始まるすべてのブランチ、および`staging`と`main`という名前のブランチをデプロイするよう指示します。私たちの開発ワークフローは以下のようになるかもしれません： + +* 新しいブランチを作成する `main`から`feature/myfeature`を呼び出し、`feature/myfeature`をプッシュします。 +* ラグーンは、`feature/myfeature`ブランチを新しい環境としてデプロイし、他の機能とは独立して機能をテストできます。 +* `feature/myfeature`を`main`ブランチにマージすると、それはあなたの本番環境にデプロイされます。 + +もしご希望であれば、`feature/myfeature`や他の機能ブランチを最初に`staging`にマージして、複数の機能の機能性を一緒にテストすることもできます。ステージングで機能を一緒にテストした後、機能をmainにマージできます。 + +このワークフローは、Gitリポジトリのブランチの剪定と清潔さを高度に必要とします。各機能ブランチは自身のラグーン環境を作成するため、非常にすぐに大量の環境を生成することができ、それら全てがリソースを使用します。未使用のブランチをマージするか削除することを確認してください。 + +このため、プルリクエストベースのワークフローを考えることが理にかなっているかもしれません。 + +## プルリクエスト + +さらに高度なワークフローはプルリクエストを介したものです。このようなワークフローは、プルリクエスト（またはマージリクエストとも呼ばれる）をサポートするGitホスティングのサポートが必要です。プルリクエストベースのワークフローのアイデアは、その背後にあります。 あなたが特定の機能をターゲットブランチと一緒にテストできるというアイデアは、実際にはまだマージする必要はないが、Lagoonがビルド中にマージしてくれるというものです。 + +私たちの例では、Lagoonを設定して、ブランチ`^(staging|main)$`とプルリクエストを`.*` \(すべてのプルリクエストをデプロイする\)にデプロイさせます。 これで、私たちのワークフローは次のようになります： + +1. `main`から新しいブランチ`feature/myfeature`を作成し、`feature/myfeature`をプッシュします\(私たちがデプロイするブランチとして特定のステージングとメインのみを持っているため、今はデプロイは行われません\)。 +2. あなたのGitホスティングで`feature/myfeature`から`main`へのプルリクエストを作成します。 +3. Lagoonは今、`feature/myfeature`ブランチを`main`ブランチの上にマージし、その結果のコードをデプロイします。 +4. これで、`feature/myfeature`ブランチの機能をテストできます。まるで`main`にマージされたかのように、`feature/myfeature`ブランチを作成してから`main`で起こったすべての変更がそこにありますので、`main`ブランチの古いバージョンを持っているかもしれないと心配する必要はありません。 + 1. マージの競合がある場合、ビルドが失敗し、Lagoonは停止してあなたに通知します。 +5. あなたがプルリクエストのテストを終えた後 リクエストブランチでは、Gitホスティングに戻って実際にコードを`main`にマージすることができます。これにより、`main`のデプロイがトリガーされます。 +6. プルリクエストがマージされると、自動的にクローズされ、Lagoonはプルリクエストの環境を自動的に削除します。 + +一部のチームでは、共有の`staging`ブランチに対してプルリクエストを作成し、その後、別のプルリクエストを介して`staging`ブランチを`main`ブランチにマージすることを選択するかもしれません。これは、使用しているGitのワークフローの種類によります。 + +また、Lagoonでは、タイトルに特定のテキストがあるプルリクエストのみをデプロイするように設定することができます。正規表現として定義された`[BUILD]`は、タイトルが`[BUILD] My Pull Request`のようなプルリクエストのみをデプロイし、タイトルが`My other Pull Request`のプルリクエストは自動的にデプロイされません。これにより、環境の数を少なく保つことができ、また、まだ環境が必要でないプルリクエストを許可することができます。 + +### プルリクエストの自動データベース同期 + +自動的なプルリクエストの環境は素晴らしいことです。しかし、それらの環境が作成されたときに別の環境からデータベースが同期されると便利だろうとも思います。Lagoonはそれを扱うことができます！ + +これは 次の例は、プルリクエスト環境の最初のロールアウトでステージングデータベースを同期します： + +```yaml title=".lagoon.yml" +tasks: + post-rollout: + - run: + name: IF no Drupal installed & Pullrequest = Sync database from staging + command: | + if [[ -n ${LAGOON_PR_BASE_BRANCH} ]] && tables=$(drush sqlq 'show tables;') && [ -z "$tables" ]; then + drush -y sql-sync @staging default + fi + service: cli + shell: bash +``` + +## プロモーション + +環境にコードをデプロイする別の方法は、**プロモーション**ワークフローです。 + +プロモーションワークフローの背後にある考え方は次のようなものです（例として）： + +`staging`ブランチを`main`ブランチにマージし、`main`に変更がなければ、つまり`main`と`staging`がGitでまったく同じコードを持っている場合でも、結果として得られるDockerイメージがわずかに異なる可能性があります。これは、最後の`staging`デプロイメントと現在の`main`デプロイメントの間に、いくつかの上流Dockerイメージが変更されたか、またはさまざまなパッケージマネージャーからロードされた依存関係が変更された可能性があるためです。これは非常に小さい確率ですが、存在します。 + +そのため、 この状況では、Lagoonは一つの環境から別の環境へのLagoonイメージのプロモーションという概念を理解しています。これは基本的に、すでに構築されデプロイされたDockerイメージを一つの環境から取り出し、それらのまったく同じDockerイメージを別の環境で使用するということを意味します。 + +私たちの例では、`main`環境から`production`環境へDockerイメージをプロモートしたいと思っています： + +* 最初に、`main`という名前の通常のデプロイ環境が必要です。環境が正常にデプロイされていることを確認してください。 +* また、Gitリポジトリに`production`という名前のブランチがないことを確認してください。これがあると、人々がこのブランチにプッシュするなど、奇妙な混乱を引き起こす可能性があります。 +* 次に、[lagoon cli](https://github.com/uselagoon/lagoon-cli)を使用してプロモーションデプロイメントをトリガーします： + +```title="プロモーションデプロイメントをトリガーする" +lagoon deploy promote --project="myproject" --source="main" --destination="production" +``` + +これは、ソース`main`からデスティネーション`production`へのプロモーションを希望することをLagoonに伝えます。 + +Lagoonは次のことを行います： + +* `.lagoon.yml`と`docker-compose.yml`ファイルをロードするために、Gitブランチ`main`をチェックアウトします（Lagoonはこれらがまだ必要です 完全に動作するために）。 +* `docker-compose.yml`で定義されたサービスのすべてのKubernetes/OpenShiftオブジェクトを作成しますが、環境変数として`LAGOON_GIT_BRANCH=production`を使用します。 +* `main`環境から最新のイメージをコピーし、それらを使用します（イメージをビルドしたり、上流からタグ付けしたりする代わりに）。 +* 通常のデプロイメントのように、すべてのポストロールアウトタスクを実行します。 + +他のデプロイメントと同様に、成功または失敗の通知を受け取ります。 \ No newline at end of file diff --git a/docs/concepts-basics/build-and-deploy-process.ja.md b/docs/concepts-basics/build-and-deploy-process.ja.md new file mode 100644 index 0000000000..b9e68b6cfe --- /dev/null +++ b/docs/concepts-basics/build-and-deploy-process.ja.md @@ -0,0 +1,113 @@ +# ビルドとデプロイプロセス + +この文書では、Lagoonのビルドとデプロイメント中に実際に何が起こるかを説明します。実際のプロセスから大幅に単純化されていますが、Lagoonが新しいコードをデプロイするたびに何が行われているかを理解するのに役立ちます。 + +以下のビデオを見て、デプロイメントプロセスの詳細を確認してください。 + + + +## 1. 環境のためのOpenShiftプロジェクト/Kubernetesネームスペースの設定 + +まず、Lagoonは指定された環境のOpenShiftプロジェクト/Kubernetesネームスペースが存在して正しく設定されているかどうかを確認します。必要なサービスアカウントがあることを確認し、シークレットを作成し、環境変数を`lagoon-env`というConfigMapに設定します。これは、環境のタイプや名前、Lagoonプロジェクトの名前などの情報で満たされます。 + +## 2. Gitのチェックアウトとマージ + +次に、LagoonはGitからコードをチェックアウトします。これは、`.lagoon.yml`や`docker-compose.yml`を読み取るために必要です。 そして、`.env`ファイルだけでなく、Dockerイメージをビルドします。 + +ブランチ/PRがLagoonで設定されたブランチregexと一致する場合にのみ、Lagoonはこれらのアクションを処理します。デプロイがどのようにトリガーされたかにより、異なることが起こります： + +### **ブランチWebhook プッシュ** + +デプロイがGit webhook経由で自動的にトリガーされ、単一のブランチ向けである場合、Lagoonはwebhookペイロードに含まれるGit SHAをチェックアウトします。これにより、プッシュされた各Git SHAごとにデプロイがトリガーされます。 + +### **ブランチ REST トリガー** + +REST API経由（UIまたはGraphQL経由）で手動でブランチデプロイをトリガーし、POSTペイロードで`SHA`を定義しない場合、Lagoonはそのブランチの最新のコミットを単にチェックアウトし、それをデプロイします。 + +### **プルリクエスト** + +デプロイがプルリクエスト（PR）デプロイである場合、LagoonはプルリクエストのベースとHEADブランチおよびSHAをロードし、次のことを行います： + +* PRが指しているブランチ（ベースブランチ）をチェックアウトします。 +* PRが起源となるブランチ（`HEAD`ブランチ）をベースブランチの上にマージします。 +* **より具体的には：** + * Lagoonはwebhookで送信された特定のSHAをチェックアウトし、マージします。それらのSHAは、あるいは_ないかもしれません_ ブランチのヘッドを指してください。たとえば、GitHubのプルリクエストに新たにプッシュをすると、基本ブランチのSHAが現在の基本ブランチのHEADを指さないことがあります。 + +マージが失敗した場合、Lagoonも停止し、そのことをお知らせします。 + +## 3. イメージのビルド + +`docker-compose.yml`で定義された各サービスについて、Lagoonはイメージがビルドする必要があるかどうかを確認します。ビルドする必要がある場合、この時点でそれが行われます。ビルドの順序は、`docker-compose.yml`での設定順に基づいています。いくつかのビルド引数が注入されます： + +* `LAGOON_GIT_SHA` +* `LAGOON_GIT_BRANCH` +* `LAGOON_PROJECT` +* `LAGOON_BUILD_TYPE` \( `pullrequest`、`branch`、または `promote` のいずれか\) +* `LAGOON_SSH_PRIVATE_KEY` - ソースリポジトリをクローンするために使用されるSSHの秘密鍵です。ビルド引数を実際の鍵に変換するには、`RUN /lagoon/entrypoints/05-ssh-key.sh`を使用します。この鍵は`/home/.ssh/key`にあり、SSHとGitが自動的に使用します。安全のため、`RUN rm /home/.ssh/key`を使用して鍵を再度削除します。 +* `LAGOON_GIT_SOURCE_REPOSITORY` - ソースリポジトリの完全なGit URL。 + +また、これがプルリクエストのビルドである場合： + +* `LAGOON_PR_HEAD_BRANCH` +* `LAGOON_PR_HEAD_SHA` +* `LAGOON_PR_BASE_BRANCH` +* `LAGOON_PR_BASE_SHA` +* `LAGOON_PR_TITLE` + +また、すでに構築された各イメージの名前も注入されます。あなたの`docker-compose.yml`が最初に`cli`イメージを構築し、次に`nginx`イメージを構築するように設定されている場合、`nginx`イメージの名前は`NGINX_IMAGE`として注入されます。 + +## 4. KubernetesまたはOpenShiftのサービスとルートを設定する + +次に、Lagoonは、サービスタイプから定義されるすべてのサービスとルート、および`.lagoon.yml`で定義した可能な追加のカスタムルートをKubernetesまたはOpenShiftに設定します。 + +このステップでは、`LAGOON_ROUTES`で定義されたすべてのルートをカンマ区切りのURLとして公開します。また、以下の順序で1つのルートを"main"ルートとして定義します： + +1. カスタムルートが定義されている場合：`.lagoon.yml`で最初に定義されたカスタムルート。 +2. `docker-compose.yml`で定義されたサービスから自動生成された最初のルート。 +3. なし。 + +"main"ルートは`LAGOON_ROUTE`環境変数を介して注入されます。 + +## 5. イメージのプッシュとタグ付け + +これで、以前に構築したDockerイメージを内部のDockerイメージレジストリにプッシュする時が来ました。 + +`docker-compose.yml`でDockerfileを指定せず、イメージのみを指定したサービスの場合、それらもタグ付けされます。 そして、これにより内部のDockerイメージレジストリがイメージを認識し、コンテナで使用できるようになります。 + +## 6. 永続的なストレージ + +Lagoonは、永続的なストレージ（PVC）を必要とし、リクエストしたそれぞれのサービスに対して作成します。 + +## 7. Cronジョブ + +Cronジョブをリクエストするサービス（MariaDBなど）、および`.lagoon.yml`で定義されたカスタムCronジョブそれぞれについて、Lagoonは後で[デプロイメント](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)に注入されるCronジョブ環境変数を生成します。 + +## 8. 定義済みのプレロールアウトタスクの実行 + +これでLagoonは`.lagoon.yml`ファイルをチェックし、`pre-rollout`で定義されたタスクを探し、定義されたサービスで1つずつ実行します。これらのタスクは現在実行中のポッド上で実行されるため（最新のコミットに存在する機能やスクリプトを利用できません）、初回のデプロイメントでは実行されません。 + +これらのいずれかが失敗すると、Lagoonはすぐに停止し、あなたに通知し、ロールアウトは進行しなくなります。 + +## 9. DeploymentConfigs、Statefulsets、Daemonsets + +これがおそらく最も重要なステップです。定義されたサービスタイプに基づいて、Lagoonは[ [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)、[Statefulset](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) または [Daemonsets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) をサービス用に使用します。 \(DeploymentはOpenShiftの [DeploymentConfigs](https://docs.openshift.com/container-platform/latest/applications/deployments/what-deployments-are.html) と同等です\) + +これには、以前に収集した情報、cronジョブ、永続ストレージの位置、プッシュされたイメージなど全てが含まれます。 + +これらのオブジェクトの作成は、環境変数が変更されたり、イメージが変更されたりした場合など、必要に応じてKubernetesやOpenShiftがポッドの新しいデプロイメントを自動的にトリガーすることも引き起こします。しかし、変更がない場合はデプロイメントは行われません！これは、アプリケーションのPHPコードのみを更新した場合、Varnish、Solr、MariaDB、Redisなどの定義されているがあなたのコードを含まない他のサービスはデプロイされないということを意味します。これにより、全てが非常に高速になります。 + +## 10. すべてのロールアウトが完了するのを待つ + +今、Lagoonは待ちます！それは、ちょうどトリガーされたデプロイメントの全部が 新しいポッドが完了し、その健康チェックが成功すること。 + +デプロイメントや健康チェックのいずれかが失敗した場合、デプロイメントはここで停止し、デプロイメントが失敗したことを[定義済みの通知システム](../interacting/graphql-queries.md#adding-notifications-to-the-project)（例えばSlack）を通じて通知します。 + +## 11. 定義されたポストロールアウトタスクの実行 + +次に、Lagoonは`.lagoon.yml`ファイルをチェックして`post-rollout`で定義されたタスクを探し、定義されたサービスでそれらを一つずつ実行します。 + +これらのいずれかが失敗した場合、Lagoonは直ちに停止し、あなたに通知します。 + +## 12. 成功 + +全てが順調に進み、何もエラーが発生しなかった場合、Lagoonはこのビルドを成功とマークし、定義された通知を介してあなたに通知します。✅ \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/deploy-targets.ja.md b/docs/concepts-basics/building-blocks/deploy-targets.ja.md new file mode 100644 index 0000000000..a92d841079 --- /dev/null +++ b/docs/concepts-basics/building-blocks/deploy-targets.ja.md @@ -0,0 +1,5 @@ +# デプロイターゲット + +_デプロイターゲット_ は、Lagoonにプロジェクトをどのクラスターにデプロイするかを指示します。プロジェクトは一つまたはそれ以上のデプロイターゲットを持つことができ、例えば、一つは本番用、もう一つはテスト用といった具体的な使い分けが可能です。デプロイターゲットは、定義されたブランチの自動デプロイやプルリクエストへの対応など、さまざまなオプションを提供します。 + +[デプロイターゲットについて詳しく読む](../../using-lagoon-advanced/deploytarget-configs.md)。 \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/groups.ja.md b/docs/concepts-basics/building-blocks/groups.ja.md new file mode 100644 index 0000000000..4bd0aaa336 --- /dev/null +++ b/docs/concepts-basics/building-blocks/groups.ja.md @@ -0,0 +1,5 @@ +# グループ + +_グループ_は役割を持つユーザーで構成されています。組織は1つ以上のグループを持つことができます。各プロジェクトには1つ以上のグループが割り当てられます。グループは複数のプロジェクトに割り当てることができます。グループはプロジェクトとは独立して作成され、その後プロジェクトに割り当てられます。 + +組織には、割り当てられるグループの数を制限するクォータがあります。クォータを変更する必要がある場合は、あなたのラグーン管理者に連絡してください。 \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/notifications.ja.md b/docs/concepts-basics/building-blocks/notifications.ja.md new file mode 100644 index 0000000000..e687996e21 --- /dev/null +++ b/docs/concepts-basics/building-blocks/notifications.ja.md @@ -0,0 +1,15 @@ +# 通知 + +_通知_は、Lagoonがユーザーにプロジェクトの進行状況を伝える方法です。通知にはいくつかの種類があります： + + - Slack + - RocketChat + - メール + - Webhook + - Microsoft Teams + +プロジェクトは一つまたは複数の通知を持つことができます。組織は、すべてのプロジェクトに対する通知の割り当て枠を持っています。通知はプロジェクトとは独立して作成され、その後一つまたは複数のプロジェクトに割り当てることができます。 + +[Lagoon UIで通知をステップバイステップで追加する方法を学ぶ](../../interacting/organizations.md#add-an-email-notification-to-a-project). + +[APIを通じて通知を追加する方法を学ぶ](../../interacting/graphql-queries.md#adding-notifications-to-the-project). \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/organizations.ja.md b/docs/concepts-basics/building-blocks/organizations.ja.md new file mode 100644 index 0000000000..0abd225472 --- /dev/null +++ b/docs/concepts-basics/building-blocks/organizations.ja.md @@ -0,0 +1,9 @@ +# 組織 + +_組織_ は、一つ以上のプロジェクト、グループ、ユーザー、通知を含むことができるエンティティです。組織はプロジェクトへのアクセスを制御し、グループの作成、ユーザーの追加と削除、プロジェクトへのグループの割り当てを容易にします。 + +組織は構造のレイヤーを追加して生活を模倣するのに役立ちます - 例えば、特定のサイトで働くチームを反映する組織を作成するプロジェクトマネージャーであるかもしれません。その組織は、そのサイトを構成するプロジェクトやプロジェクト、サイトで働くためにアクセスが必要な人々を_開発者_というグループのユーザーとして、またサイトを見るだけで問題を見るためにLagoonへのアクセスが必要な別の人々のグループを_ビューアー_として含むでしょう。それぞれに適切な役割があります。 + +組織はプロジェクト、グループ、通知、環境の数を制限するためのクォータを持っています。このクォータを変更する必要がある場合は、あなたのLagoon管理者に連絡してください。 + +[組織とのやりとりについてもっと学ぶ](../../interacting/organizations.md). \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/projects.ja.md b/docs/concepts-basics/building-blocks/projects.ja.md new file mode 100644 index 0000000000..8d427ce4f4 --- /dev/null +++ b/docs/concepts-basics/building-blocks/projects.ja.md @@ -0,0 +1,3 @@ +# プロジェクト + +_プロジェクト_は、Lagoon上で動作するアプリケーションです。組織は1つ以上のプロジェクトを持つことができます。プロジェクトには、1人以上のユーザー、通知、そして少なくとも1つのデプロイターゲットが含まれます。組織は、作成できるプロジェクトの量を制限するためのクォータを持っています。 \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/roles.ja.md b/docs/concepts-basics/building-blocks/roles.ja.md new file mode 100644 index 0000000000..210c705a31 --- /dev/null +++ b/docs/concepts-basics/building-blocks/roles.ja.md @@ -0,0 +1,28 @@ +# 役割 + +_役割_はユーザーがプロジェクトにアクセスするためのものです。ユーザーはグループや組織で役割を与えられます。 + +グループのメンバーには以下の役割を与えることができます： + +- ゲスト +- レポーター +- 開発者 +- メンテナー +- オーナー + +これらの役割とその権限については、ここで詳しく説明されています：[役割ベースのアクセス制御](../../interacting/rbac.md)。 + +組織のメンバーには以下の役割を与えることができます： + +- 組織のオーナー +- 組織のビューア + +!!! info inline end "クォータの変更" + + クォータを変更する必要がある場合は、あなたのLagoon管理者に連絡してください。 + +_組織のオーナー_は、クォータの変更を除く、組織の管理に関連するすべての事を行うことができます。彼らはユーザー、グループ、プロジェクト、デプロイターゲット、通知の追加や削除ができます。 + +_組織のビューア_は、組織を閲覧するだけの読み取り専用の役割であり、変更や追加はできません。彼らは組織内のプロジェクト、グループ、ユーザー、通知を閲覧することができますが、変更することはできません。 + +オーナーまたはビューアとして指定されていないユーザーは、組織を見ることができません。 \ No newline at end of file diff --git a/docs/concepts-basics/building-blocks/users.ja.md b/docs/concepts-basics/building-blocks/users.ja.md new file mode 100644 index 0000000000..3cf108c54b --- /dev/null +++ b/docs/concepts-basics/building-blocks/users.ja.md @@ -0,0 +1,5 @@ +# ユーザー + +_ユーザー_は、ラグーンシステムとやり取りするためのラグーンのアカウントです。ユーザーは一つまたは複数の組織やグループに所属することができ、各グループはさまざまな許可を付与する異なる役割を持つことができます。組織、グループ、および役割は、ユーザーにプロジェクトへのアクセス権を付与します。 + +[ユーザーの役割について詳しく読む](roles.md)。 \ No newline at end of file diff --git a/docs/concepts-basics/docker-compose-yml.ja.md b/docs/concepts-basics/docker-compose-yml.ja.md new file mode 100644 index 0000000000..4197a70042 --- /dev/null +++ b/docs/concepts-basics/docker-compose-yml.ja.md @@ -0,0 +1,281 @@ +# docker-compose.yml + +`docker-compose.yml`ファイルは、Lagoonに以下のようなことを指示します： + +* デプロイするべきサービス/コンテナを知る。 +* コンテナのイメージがどのようにビルドされるかを定義する。 +* 永続ボリュームのような追加の設定を定義する。 + +Docker Compose（ツール）はYAMLファイルの内容の検証に非常に厳格であるため、サービス定義の`labels`内でのみ設定を行うことが可能です。 + +!!! 警告 + Lagoonは`docker-compose.yml`ファイルからラベル、サービス名、イメージ名、ビルド定義のみを読み取ります。ポート、環境変数、ボリューム、ネットワーク、リンク、ユーザーなどの定義は無視されます。 + +これは意図的なもので、`docker-compose`ファイルはあなたのローカル環境の設定を定義するためのものです。Lagoonは`lagoon.type`からあなたがデプロイしているサービスのタイプを学び、そのサービスが必要とするポート、ネットワーク、その他の追加設定について知ることができます。 + +以下に、Drupal用の`docker-compose.yml`ファイルの簡単な例を示します： + +```yaml title="docker-compose.yml" +version: '2.3' + +x-lagoon-project: + # Lagoonプロジェクト名（これを編集する際は`&lagoon-project`を残してください） + &lagoon-project drupal-example + +x-volumes: + &default-volumes + # Dockerコンテナにリアルタイムでマウントしたいすべてのボリュームを定義します + volumes: + - .:/app:delegated + +x-environment: + &default-environment + LAGOON_PROJECT: *lagoon-project + # ローカルで使用するルート。pygmyを使用している場合、このルートは *必ず* .docker.amazee.ioで終わるようにしてください + LAGOON_ROUTE: http://drupal-example.docker.amazee.io + # 本番環境と同様の動作をさせたい場合はコメントアウトを解除してください + #LAGOON_ENVIRONMENT_TYPE: production + # Xdebugを有効にし、`docker-compose up -d`で再起動したい場合はコメントアウトを解除してください + #XDEBUG_ENABLE: "true" + +x-user: + &default-user + # コンテナが実行されるべきデフォルトのユーザー。Linux上でID `1000`以外のユーザーで実行する場合はこれを変更します + user: '1000' + +services: + + nginx: + build: + context: . + dockerfile: nginx.dockerfile + labels: + lagoon.type: nginx-php-persistent # (1) + lagoon.persistent: /app/web/sites/default/files/ + + php: + build: + context: . + dockerfile: php.dockerfile + labels: + lagoon.type: nginx-php-persistent # (2) + lagoon.name: nginx + lagoon.persistent: /app/web/sites/default/files/ + + mariadb: + image: amazeeio/mariadb-drupal + ラベル: + lagoon.type: mariadb +``` + +1. ここで[マルチコンテナポッド](docker-compose-yml.md#multi-container-pods)に注目してください。 +2. ここで[マルチコンテナポッド](docker-compose-yml.md#multi-container-pods)に注目してください。 + +## 基本設定 + +`x-lagoon-project`: + +これはプロジェクトのマシン名で、ここで定義します。"drupal-example"を使用します。 + +`x-volumes`: + +これはLagoonにコンテナにマウントするものを指示します。ウェブアプリケーションは`/app`に存在しますが、必要に応じてこれを追加または変更することができます。 + +`x-environment`: + +1. ここでローカル開発URLを設定できます。pygmyを使用している場合、`.docker.amazee.io`で終わらなければなりません。 +2. 本番環境を完全に模倣したい場合は、`LAGOON_ENVIRONMENT_TYPE: production` のコメントを外します。 +3. Xdebugを有効にしたい場合は、`DEBUG_ENABLE: "true"` のコメントを外します。 + +`x-user`: + +Linuxを使用していて、`1000`以外のユーザーで実行したい場合を除き、これを変更する必要はほとんどありません。 + +## **`services`** + +これはデプロイしたいすべてのサービスを定義します。 _残念ながら、_ Docker Composeはそれらをサービスと呼びますが、実際にはコンテナです。これからはサービスと呼ぶことにします、そしてこのドキュメンテーション全体で。 + +その サービスの名前（上記の例では `nginx`、`php`、`mariadb`）は、Lagoonによって生成されるKubernetesのポッドの名前（また別の用語 - これからはサービスと呼びます）として使用され、さらに定義された `lagoon.type`に基づいて作成されるKubernetesのオブジェクトの名前としても使用されます。これには、サービス、ルート、永続的なストレージなどが含まれる可能性があります。 + +サービス名は[RFC 1035](https://tools.ietf.org/html/rfc1035)のDNSラベル標準に準拠していることに注意してください。サービス名は以下の要件を満たす必要があります： + +* 最大63文字を含む +* 小文字の英数字または'-'のみを含む +* 英字で始まる +* 英数字で終わる + +!!! 警告 + サービスの名前を設定したら、それを改名しないでください。これにより、コンテナ内で様々な問題が発生し、物事が壊れる可能性があります。 + +### Dockerイメージ + +#### `build` + +デプロイメントごとにLagoonがあなたのサービスのDockerfileをビルドしてほしい場合、ここで定義できます： + +`build` + +* `context` + * `docker build` コマンドに渡すべきビルドコンテキストパス。 +* `dockerfile:` + * ビルドするべきDockerfileの場所と名前。 + +!!! 警告 + Lagoonは短縮バージョンをサポートしていません `build: `の定義が見つかった場合、処理は失敗します。 + +#### `image` + +Dockerfileをビルドする必要がなく、既存のDockerfileを使用したい場合は、`image`で定義します。 + +### タイプ + +Lagoonは、KubernetesやOpenShiftのオブジェクトを正しく設定するために、デプロイするサービスのタイプを知る必要があります。 + +これは`lagoon.type`ラベルを通じて行われます。選択できるタイプは多数あります。すべてのタイプと追加設定の可能性を見るには、[Service Types](../concepts-advanced/service-types.md)を確認してください。 + +#### コンテナのスキップ/無視 + +たとえば、ローカル開発時にのみコンテナが必要な場合など、Lagoonにサービスを完全に無視させたい場合は、そのタイプに`none`を指定します。 + +### 永続的なストレージ + +一部のコンテナには永続的なストレージが必要です。Lagoonでは、各コンテナが最大1つの永続的なストレージボリュームをコンテナに接続できるようにしています。コンテナに自身の永続的なストレージボリュームを要求させることができます（それは他のコンテナにマウント可能）、または、コンテナに他のコンテナが作成した永続的なストレージをマウントするよう指示することもできます。 + +多くの場合、Lagoonはその永続的なストレージがどこに行くべきかを知っています。たとえば、 例えば、MariaDBコンテナの場合、Lagoonは永続的なストレージを`/var/lib/mysql`に配置すべきと知っており、それを定義するための追加の設定なしに自動的にそこに配置します。ただし、一部の状況では、Lagoonは永続的なストレージをどこに配置すべきかを知るためにあなたの助けが必要です。 + +* `lagoon.persistent` - 永続的なストレージをマウントすべき**絶対**パス（上記の例では`/app/web/sites/default/files/`を使用しており、これはDrupalが永続的なストレージを期待する場所です）。 +* `lagoon.persistent.name` - Lagoonにそのサービスの新しい永続的なストレージを作成しないように指示し、代わりに他の定義済みのサービスの永続的なストレージをこのサービスにマウントします。 +* `lagoon.persistent.size` - 必要な永続的なストレージのサイズ（Lagoonは通常、最小5Gの永続的なストレージを提供します。もしもっと必要なら、ここで定義してください）。 +* `lagoon.persistent.class` - デフォルトではLagoonは自動的に適切なストレージクラス（MySQLのSSD、Nginxの大量ストレージなど）をサービスに割り当てます。これを上書きする必要がある場合は、ここで行うことができます。これは、Lagoonが動作するKubernetes/OpenShiftの基礎となるものに大きく依存します。これについてはLagoonの管理者に問い合わせてください。 + +### 自動生成されるルート + +docker-compose.ymlファイルは、サービスごとに[自動生成されるルート](./lagoon-yml.md#routes)を有効または無効にすることもサポートしています。 + +* `lagoon.autogeneratedroute: false` ラベルを使用すると、そのサービスに対して自動的に生成されるルートが停止します。これは自動生成されるルートを持つすべてのサービスに適用できますが、データベースサービスなどの追加の内部向けサービスを作成する際に[`basic`](../concepts-advanced/service-types.md#basic)および[`basic-persistent`](../concepts-advanced/service-types.md#basic-persistent)サービスタイプで特に便利です。逆もまた真であり、.lagoon.ymlファイルがそれらを[無効にする](lagoon-yml.md#routesautogenerate)ときに、サービスに対して自動生成されるルートを有効にします。 + +## マルチコンテナーポッド + +KubernetesとOpenShiftは単純なコンテナーをデプロイしません。代わりに、それぞれが1つ以上のコンテナーを持つポッドをデプロイします。通常、Lagoonは定義された`docker-compose`サービスごとにコンテナーが内部にある単一のポッドを作成します。しかし、あるケースでは、これらのコンテナーが互いに非常に依存していて、常に一緒にいるべきであるため、単一のポッド内に2つのコンテナーを配置する必要があります。そのような状況の一例は、PHPです。 およびDrupalのようなWebアプリケーションのPHPコードを含むNGINXコンテナ。 + +これらのケースでは、どのサービスが一緒に残るべきかをLagoonに伝えることが可能で、次のように行います（私たちがコンテナを`docker-compose`のために`services`と呼んでいることを覚えておいてください）： + +1. 両方のサービスを、二つのサービスを期待する`lagoon.type`で定義します（この例では、`nginx`と`php`サービスで定義されている`nginx-php-persistent`です）。 +2. 第二のサービスを第一のサービスにリンクし、第二のサービスのラベル`lagoon.name`を第一のサービスで定義します（この例では、`lagoon.name: nginx`を定義することで行います）。 + +これにより、Lagoonは`nginx`と`php`コンテナが`nginx`と呼ばれるポッドに組み合わせられていることを認識します。 + +!!! 警告 + サービスの`lagooon.name`を設定したら、それをリネームしないでください。これはあなたのコンテナで混乱を引き起こし、物事を壊す原因となります。 + +Lagoonはまだ、二つのサービスのうちどちらが実際の個別のサービスタイプであるか（この場合は`nginx`と`php`）を理解する必要があります。これは、タイプが与える同じ名前のサービス名を検索することで行います、したがって`nginx-php-persistent`は`ng`という名前のサービスを一つ期待します。 `inx`と`php`を含む`docker-compose.yml`があります。何らかの理由でサービスの名前を変更したい場合や、`nginx-php-persistent`タイプのポッドを複数必要とする場合は、追加のラベル`lagoon.deployment.servicetype`を使用して実際のサービスタイプを定義することができます。 + +例： + +```yaml title="docker-compose.yml" +nginx: + build: + context: . + dockerfile: nginx.dockerfile + labels: + lagoon.type: nginx-php-persistent + lagoon.persistent: /app/web/sites/default/files/ + lagoon.name: nginx # これがないと、Lagoonはコンテナ名、つまりこの場合はnginxを使用します。 + lagoon.deployment.servicetype: nginx +php: + build: + context: . + dockerfile: php.dockerfile + labels: + lagoon.type: nginx-php-persistent + lagoon.persistent: /app/web/sites/default/files/ + lagoon.name: nginx # このサービスをLagoonのNGINXポッドの一部にしたい。 + lagoon.deployment.servicetype: php +``` + +上記の例では、サービス名は`nginx`と`php`です（しかし、好きな名前をつけることができます）。`lagoon.name`はLagoonにどのサービスが一緒に行くかを伝えます - 同じ名前のすべてのサービスは一緒に行きます。 一緒に。 + +Lagoonがどれが `nginx` で、どれが `php` サービスであるかを認識するために、これを `lagoon.deployment.servicetype: nginx` および `lagoon.deployment.servicetype: php` で定義します。 + +## ヘルムテンプレート (Kubernetesのみ) + +LagoonはKubernetesでのテンプレート作成に[Helm](https://helm.sh/)を使用します。これには、`build-deploy-tool` イメージに含まれる一連の[チャート](https://github.com/uselagoon/build-deploy-tool/tree/main/legacy/helmcharts)が必要です。 + +## カスタムロールアウトモニタータイプ + +デフォルトでは、LagoonはカスタムテンプレートからのサービスがKubernetesまたはOpenshift内の [`DeploymentConfig`](https://docs.openshift.com/container-platform/4.4/applications/deployments/what-deployments-are.html#deployments-and-deploymentconfigs_what-deployments-are) オブジェクトを介してロールアウトされることを期待しています。それに基づいてロールアウトを監視します。場合によっては、カスタムデプロイメントで定義されたサービスが異なる監視方法を必要とすることがあります。これは `lagoon.rollout` を通じて定義することができます： + +* `deploymentconfig` - これがデフォルトです。 [`DeploymentConfig`](https://docs.openshift.com/container-platform/4.4/applications/deployments/what-deployments-are.html#deployments-and-deployment を期待します。 サービスのテンプレート内の[`Statefulset`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)オブジェクトを期待します。 +* `daemonset` - サービスのテンプレート内の[`Daemonset`](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/)オブジェクトを期待します。 +* `false` - ロールアウトを監視せず、テンプレートが適用されエラーが発生しなければ満足します。 + +また、特定の環境のみにロールアウトを上書きすることもできます。これは[`.lagoon.yml`](lagoon-yml.md#environments-name-rollouts)で行います。 + +## Docker Compose v2互換性 + +!!! バグ + ローカルでDocker Compose V2の古いバージョンを使用していると、一部の既知の問題が発生することがあります - これらの問題は後のリリース(v2.17.3以降)で解決されています。 + +これらのエラーの解決策は通常、使用しているDocker Composeのバージョンを更新するか（または[新しいバージョンをインストールする](https://docs.docker.com/compose/install/)）、あるいは使用しているDocker Desktopのバージョンをアップグレードすることです。 Docker Desktopの[リリースノート](https://docs.docker.com/desktop/release-notes/)を参照してください。 詳しくは + +``` shell title="依存関係のエラーを示すDocker Compose出力" +Failed to solve with frontend dockerfile.v0: failed to create LLB definition: pull access denied, repository does not exist or may require authorization + +または + +Failed to solve: drupal9-base-cli: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed` +``` + +* これらはDocker Compose v2.13.0で解決されます。 +* このメッセージは、ビルドがまだビルドされていないDockerイメージにアクセスしようとしたことを意味します。BuildKitは並列にビルドするため、もしもう一つのDockerイメージを継承するものがある場合（DrupalのCLIのように）はこの事象が発生します。 +* マルチステージビルドとして再設定するために、ビルド内の[target](https://docs.docker.com/compose/compose-file/build/#target)フィールドを使用することもできます。 +* すでに新しいDocker Composeバージョンを実行している場合、このエラーは、docker-containerビルドコンテキストをbuildxでデフォルトにしている可能性があります。`docker buildx ls`がdocker-containerベースのものではなく、docker builderをデフォルトとして表示することを確認する必要があります。Docker buildxのドキュメントは[こちら](https://docs.docker.com/engine/referenceです。 /commandline/buildx_use/). + +``` shell title="volumes_from エラーを示す Docker Compose 出力" +no such service: container:amazeeio-ssh-agent +``` + +* この問題はDocker Compose v2.17.3で解決されています。 +* このメッセージは、ローカルで実行されているコンテナへのSSHアクセスを提供するサービスが、あなたのDocker Composeスタックの外部で実行され、アクセスできないことを意味します。 +* あなたのローカル環境からSSHアクセスが必要ない場合、`docker-compose.yml`ファイルからこのセクションを削除することもできます。 + +## BuildKitとLagoon + +BuildKitは、ソースコードを効率的で表現力豊かで繰り返し利用可能な方法でビルド成果物に変換するためのツールキットです。 + +Lagoon v2.11.0のリリースにより、Lagoonはより高度なBuildKitベースのdocker-composeビルドをサポートするようになりました。プロジェクトまたは環境でBuildKitを有効にするには、Lagoonプロジェクトまたは環境に`DOCKER_BUILDKIT=1`をビルド時の変数として追加してください。 + +## LagoonビルドでのDocker Composeエラー + +Docker Composeで一般的なビルドエラーの解決方法については、[Lagoonビルドエラーページ](../using-lagoon-the-basics/lagoon-build-errors-and-warnings.md#docker-compose-errors)を参照してください。 + +## よくあるDocker Composeの問題 + +このセクションでは、より一般的な Docker Composeのエラーとその対処法。これらはローカル開発で発生するか、または[Lagoonビルドエラーと警告](../using-lagoon-the-basics/lagoon-build-errors-and-warnings.md#docker-compose-errors)として発生するかもしれません。 + +### 二重マッピングキー + +``` shell title="マッピングキーのエラーを示すDocker Composeの出力" +ERR: yaml: unmarshal errors: line 22: mapping key "<<" already defined at line 21 +``` + +Lagoonの初期リリースでは、ボリュームとユーザーコードを提供するために、サービスにYAMLエイリアスのペアが添付されていました。Docker Composeの新しいリリースでは、これをエラーとして報告します。すべての例が現在更新されているものの、更新が必要な古いコードベースがあるかもしれません。 + +このエラーは、Docker Composeが配列に何を挿入しているのか分からないため、重複していると仮定して発生します。 + +あなたの`docker-compose.yml`がこの（または類似の）コードブロックを一つ以上含んでいる場合、あなたは影響を受けます。 + +``` yaml title="二重マッピングキーを含むDocker Composeのエラー" +... + << : [*default-volumes] + << : [*default-user] +... +``` + +修正版では、両方のエイリアスを1つのマッピングキーに統合します - すべての発生を対処する必要があります。 + +``` yaml title="Docker Compose correct 複数のエイリアスマッピングキーの挿入" +... + << : [*default-volumes, *default-user] +... +``` diff --git a/docs/concepts-basics/index.ja.md b/docs/concepts-basics/index.ja.md new file mode 100644 index 0000000000..6555ccebf6 --- /dev/null +++ b/docs/concepts-basics/index.ja.md @@ -0,0 +1,5 @@ +# 基本的なラグーンの概念 + +このセクションでは、Lagoonの基本的な概念について説明します。すでにこれらについて理解している場合は、[上級ラグーン概念](../concepts-advanced/index.md)に進んでください。 + +助けが必要な場合は、あなたのラグーン管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティやメンテナーに連絡してください。 \ No newline at end of file diff --git a/docs/concepts-basics/lagoon-yml.ja.md b/docs/concepts-basics/lagoon-yml.ja.md new file mode 100644 index 0000000000..e2ef1945b2 --- /dev/null +++ b/docs/concepts-basics/lagoon-yml.ja.md @@ -0,0 +1,606 @@ +# .lagoon.yml + +`.lagoon.yml` ファイルは、プロジェクトを設定するための中心的なファイルです。以下の操作を行うための設定が含まれています： + +* [サイトへのアクセスルートを定義する](lagoon-yml.md#routes)。 +* [プレロールアウトタスクを定義する](lagoon-yml.md#pre-rollout-tasks-pre_rolloutirun)。 +* [ポストロールアウトタスクを定義する](lagoon-yml.md#post-rollout-tasks-post_rolloutirun)。 +* [SSL証明書を設定する](lagoon-yml.md#ssl-configuration-tls-acme)。 +* [環境のためのcronジョブを追加する](lagoon-yml.md#environmentsnamecronjobs)。 + +`.lagoon.yml` ファイルは、Gitリポジトリのルートに配置する必要があります。 + +## 一般設定 + +### `docker-compose-yaml` + +この設定は、ビルドスクリプトにどのDocker Compose YAMLファイルを使用するべきかを指示します。これにより、どのサービスとコンテナがデプロイされるべきかを理解します。これはデフォルトで `docker-compose.yml` を指しますが、必要に応じて特定のLagoon Docker Compose YAMLファイルに使用することもできます。 + +### `environment_variables.git_sha` + +この設定は、デプロイされたGit SHAを環境変数としてプロジェクトに注入することを有効にすることができます。デフォルトではこれは無効です。値を `true` に設定すると、SHAが環境変数 `LAGOON_GIT_SHA` として設定されます。 + +## ルート + +ルートはトラフィックを指向するために使用されます サービスに。環境内の各サービスにはルートがあり、ドメイン名は手動または自動で定義されます。トップレベルの `routes` セクションは、すべての環境のすべてのルートに適用されます。 + +### `routes.autogenerate` + +これにより、自動的に作成されるルートを設定できます。[手動ルート](＃environmentsnameroutes)は環境ごとに定義されます。 + +* `enabled`: 自動生成されたルートを無効にするには、`false`に設定します。デフォルトは`true`です。 +* `allowPullrequests`: プルリクエストのために `enabled: false`を上書きするには、`true`に設定します。 + + ```yaml title=".lagoon.yml" + routes: + autogenerate: + enabled: false + allowPullrequests: true + ``` + +* `insecure`: HTTP接続を設定します。デフォルトは`Allow`です。 + * `Allow`: ルートはHTTPとHTTPSの両方に応答します。 + * `Redirect`: ルートは任意のHTTPリクエストをHTTPSにリダイレクトします。 + +* `prefixes`: 各環境の自動生成されたルートのプレフィクスを設定します。これは、言語プレフィクスドメインやDrupalの`domain`モジュールを使用したマルチドメインサイトなどに便利です。 + + ```yaml title=".lagoon.yml" + routes: + autogenerate: + prefixes: + - www + - de + - fr + - it + ``` + +## タスク + +以下のようなものがあります ビルドフローで正確にどのタイミングで実行されるかによって異なるタスクの種類を定義することができます： + +### プリロールアウトタスク - `pre_rollout.[i].run` + +ここでは、すべてのイメージが正常にビルドされた後、_しかし_以下の前に、プロジェクトに対して実行するタスクを指定することができます： + +* 新規にビルドされたイメージで実行中のコンテナが更新される。 +* 既存の環境に他の変更が加えられる。 + +この機能を利用すると、たとえば、アプリケーションを更新する前にデータベースダンプを作成するなどのことが可能になります。この機能は、デプロイに問題が発生した場合のロールバックを容易にします。 + +!!! 情報 + プリロールアウトタスクは_更新前の既存のポッド内で実行されます_、つまり： + + * 最後のデプロイ以降にDockerfileに加えられた変更は、プリロールアウトタスクが実行されるときには表示されません。 + * 既存のコンテナがない場合（例えば、新しい環境の初期デプロイメント時など）、プリロールアウトタスクはスキップされます。 + +### ポストロールアウトタスク - `post_rollout.[i].run` + +ここでは、以下の後に、プロジェクトに対して実行する必要があるタスクを指定することができます： + +* 全てのイメージが正常にビルドされる。 +* 全てのコンテナが新しいイメージで更新される。 +* 全てのコンテナが稼働し、その準備が整った後。 チェック。 + +ポストロールアウトタスクの一般的な使用例には、`drush updb`、`drush cim`の実行や、さまざまなキャッシュのクリアなどが含まれます。 + +* `name` + * 名前は、ログ内の各タスクを識別するための任意のラベルです。 +* `command` + * ここでは、実行するべきコマンドを指定します。これらは、各コンテナのWORKDIRで実行されます。Lagoonのイメージの場合、これは`/app`です。タスクを実行するために特定の場所に`cd`する必要がある場合は、これを念頭に置いてください。 +* `service` + * タスクを実行するサービス。Drupalの例に従っている場合、これはCLIコンテナになります。なぜなら、あなたのサイトのコード、ファイル、データベースへの接続がすべて含まれているからです。通常、これを変更する必要はありません。 +* `container` + * サービスが複数のコンテナを持っている場合（例：`nginx-php`）、ポッド内で接続するコンテナを指定する必要があります（例：`nginx`ポッド内の`php`コンテナ）。 +* `shell` + * タスクが実行されるべきシェル。デフォルトでは`sh`が使用されますが、コンテナが他のシェル（`bash`など）も持っている場合は、ここで定義できます。これは、ポストロールアウト内で小さなif/else bashスクリプトを実行したい場合に便利です。[以下の例を参照してください](#example-post-rollout-tasks)、これにより、どのようにして書き込むかを学ぶことができます 複数行のスクリプト。 +* `when` + * "when"節は、タスクの条件付き実行を可能にします。それは真/偽の値に評価される表現を期待しており、タスクを実行するかどうかを決定します。 + +注: デプロイメント中にpre/post-rolloutタスクを一時的に無効にしたい場合は、APIで以下の環境変数をプロジェクトレベルまたは環境レベルで設定することができます（[環境変数](../concepts-advanced/environment-variables.md)の設定方法についてはここを参照してください）。 + +* `LAGOON_PREROLLOUT_DISABLED=true` +* `LAGOON_POSTROLLOUT_DISABLED=true` + +#### post-rolloutタスクの例 + +以下は、あなたのプロジェクトに使用したり適応したりしたい、いくつかの有用なpost-rolloutタスクの例です。 + +Drupalがインストールされていない場合にのみ実行： + +```bash title=".lagoon.yml" +- run: + name: IF no Drupal installed + command: | # (1) + if tables=$(drush sqlq "show tables like 'node';") && [ -z "$tables" ]; then + #### whatever you like + fi + service: cli + shell: bash +``` + +1. これは、複数行のコマンドを作成する方法を示しています。 + +ブランチ名に基づいた異なるタスク： + +```yaml title=".lagoon.yml" +- run: + name: Different tasks based on branch name + command: | + ### Runs if 現在のブランチは 'production' ではありません + サービス: cli + 条件: LAGOON_GIT_BRANCH != "production" + +シェルスクリプトを実行: + +```yaml title=".lagoon.yml" +- run: + name: Run Script + command: './scripts/script.sh' + service: cli +``` + +ポッド内の特定のコンテナを対象にする： + +```yaml title=".lagoon.yml" +- run: + name: show php env variables + command: env + service: nginx + container: php +``` + +Drupal & Drush 9: マスター環境からデータベースとファイルを同期： + +```bash title=".lagoon.yml" +- run: + name: Sync DB and Files from master if we are not on master + command: | + # Only if we don't have a database yet + if tables=$(drush sqlq 'show tables;') && [ -z "$tables" ]; then + drush sql-sync @lagoon.master @self # (1) + drush rsync @lagoon.master:%files @self:%files -- --omit-dir-times --no-perms --no-group --no-owner --chmod=ugo=rwX + fi + service: cli + when: LAGOON_ENVIRONMENT_TYPE != "production" +``` + +1. ここではプロジェクトに適したエイリアスを使用してください。 + +## バックアップの保持期間 + +### `backup-retention.production.monthly` + +Lagoonがプロジェクトの本番環境の月次バックアップを何回保持するべきかを指定します。 + +グローバル この値が指定されていない場合、デフォルトは `1` です。 + +### `backup-retention.production.weekly` + +Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき週間バックアップの数を指定します。 + +この値が指定されていない場合、グローバルデフォルトは `6` です。 + +### `backup-retention.production.daily` + +Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき日次バックアップの数を指定します。 + +この値が指定されていない場合、グローバルデフォルトは `7` です。 + +### `backup-retention.production.hourly` + +Lagoonがあなたのプロジェクトのプロダクション環境で保持すべき毎時バックアップの数を指定します。 + +この値が指定されていない場合、グローバルデフォルトは `0` です。 + +## バックアップスケジュール + +### `backup-schedule.production` + +このプロジェクトのバックアップスケジュールを指定します。ただし、`Minute` ブロックは `M` でなければならず、他の値は Lagoon ビルドを失敗させます。これにより、Lagoonはこれらのバックアップが行われる特定の分をランダムに選択することができ、ユーザーはスケジュールの残りを時間まで指定することができます。 + +この値が指定されていない場合、グローバルデフォルトは `M H(22-2) * * *` です。注意してください これらのバックアップは、クラスタのローカルタイムゾーンを使用します。 + +## 環境 + +環境名は、デプロイされたブランチやプルリクエストと一致します。これにより、各環境で異なる設定を持つことが可能になります。私たちの例では、`main`と`staging`環境に適用されます。 + +### `environments.[name].routes` + + + +手動ルートは、サービスへのトラフィックを指示するために環境ごとに設定されたドメイン名です。すべての環境がデフォルトで[自動生成されたルート](#routesautogenerate)を取得するため、手動ルートは通常、プロジェクトのウェブサイトのメインドメイン（`www.example.com`など）を使用して本番環境でのみ設定されます。 + +!!! ヒント + Lagoonは手動ルートを制御できないので、DNSプロバイダーでDNSレコードが適切に設定されていることを確認する必要があります。自動ルートを指す`CNAME`レコードを設定できる可能性があります。 + +環境の次の最初の要素はターゲットサービスであり、私たちの場合は`nginx`です。 例えば、これは私たちがどのサービスに入ってくるリクエストを送るかを識別する方法です。 + +最も単純なルートは `example.com`で、これは私たちの[例の`.lagoon.yml`](#example-lagoonyml)で見ることができます - 追加の設定がないことがわかります。これは、あなたがルートに対してLet's Encrypt証明書を望んでいると仮定し、HTTPSからHTTPへのリダイレクトはありません。 + +以下の`"www.example.com"`の例では、さらに3つのオプションを見ることができます（また、ルートの終わりにある`:`と、ルートが`"`で囲まれていることに注意してください、これは重要です！）： + +```yaml title=".lagoon.yml" +- "www.example.com": + tls-acme: true + insecure: Redirect + hstsEnabled: true +``` + +### SSL設定 `tls-acme` + +!!! 警告 + `tls-acme: true`から`tls-acme: false`に切り替えると、このルートに対して以前に生成された証明書がすべて削除されます。これは、外部のCDNを使用していて証明書のピン留めを行っている場合、予期しない挙動を引き起こす可能性があります。 + +* `tls-acme`：Let's Encryptを通じた自動TLS証明書生成を設定します。デフォルトは`true`で、自動証明書を無効にするには`false`に設定します。 +* `insecure`：HTTP接続を設定します。デフォルトは`Allow`です。 + * `Allow`：ルートはHTTPとHTTPSに応答します。 + * ` リダイレクト`：ルートはすべてのHTTPリクエストをHTTPSにリダイレクトします。 +* `hstsEnabled`： `Strict-Transport-Security`ヘッダーを追加します。デフォルトは + `false`です。 +* `hstsMaxAge`： `max-age`ディレクティブを設定します。デフォルトは `31536000` （1 + 年）です。 +* `hstsPreload`： `preload`ディレクティブを設定します。デフォルトは `false`です。 +* `hstsIncludeSubdomains`： `includeSubDomains`ディレクティブを設定します。デフォルトは + `false`です。 + +!!! 情報 + 証明書認証機関（CA）によって署名されたSSL証明書からLet's Encrypt証明書に切り替える予定の場合、移行を監視するためにLagoon管理者に連絡することをお勧めします。 + +### 特定のパスの監視 + +[UptimeRobot](https://uptimerobot.com/)があなたのクラスター（KubernetesまたはOpenShift）に設定されている場合、Lagoonは各ルート/イングレスに注釈を注入して`stakater/IngressControllerMonitor`が使用します。デフォルトのアクションはルートのホームページを監視することです。特定のルートを監視したい場合、ルート仕様に`monitoring-path`を追加することでこれをオーバーライドできます。一般的な使用法は、キャッシングをバイパスする監視用のパスを設定し、サイトのリアルタイムの監視を可能にすることです。 + +```yaml title=".lagoon.yml" +- "www .example.com": + monitoring-path: "/bypass-cache" +``` + +### Ingressの注釈 + +!!! 警告 + ルート/Ingressの注釈は、nginx-ingressコントローラーを実行するクラスターにデプロイされるプロジェクトのみがサポートしています！これがサポートされているかどうかは、あなたのLagoon管理者に確認してください。 + +* `annotations`は、[nginx-ingressコントローラーがサポートする注釈](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/)のYAMLマップです。これは特に、簡単なリダイレクトや他の設定に便利です。 + +#### 制限事項 + +Lagoonでは、一部の注釈が禁止されているか、部分的に制限されています。 +以下の表は、これらのルールを説明しています。 + +あなたの`.lagoon.yml`がこれらの注釈のいずれかを含んでいる場合、ビルドが失敗する原因となります。 + +| 注釈 | ノート | +| --- | --- | +| `nginx.ingress.kubernetes.io/auth-snippet` | 禁止されています | +| `nginx `.ingress.kubernetes.io/configuration-snippet` | `rewrite`、`add_header`、`set_real_ip`、および `more_set_headers` ディレクティブに制限されています。 | +| `nginx.ingress.kubernetes.io/modsecurity-snippet` | 不許可 | +| `nginx.ingress.kubernetes.io/server-snippet` | `rewrite`、`add_header`、`set_real_ip`、および `more_set_headers` ディレクティブに制限されています。 | +| `nginx.ingress.kubernetes.io/stream-snippet` | 不許可 | +| `nginx.ingress.kubernetes.io/use-regex` | 不許可 | + +#### Ingressのアノテーションリダイレクト + +この例では、`example.ch`への任意のリクエストが、フォルダーやクエリパラメータを保持したまま `https://www.example.ch`にリダイレクトされます（`example.com/folder?query` -> `https://www.example.ch/folder?query`）。 + +```yaml title=".lagoon.yml" +- "example.ch": + annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri +- www.example.ch +``` + +もちろん、他の任意の場所にリダイレクトすることも可能です。 LagoonにホストされていないURL、これは`example.de`へのリクエストを`https://www.google.com`にリダイレクトします。 + +```yaml title=".lagoon.yml" +- "example.de": + annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.google.com +``` + +#### 信頼されるリバースプロキシ + +!!! 警告 + Kubernetesは単一の`nginx.ingress.kubernetes.io/server-snippet`アノテーションのみを処理します。非本番環境のルートでこのアノテーションを使用する場合は、`add_header X-Robots-Tag "noindex, nofollow";`アノテーションもサーバースニペットの一部として含めてください。これは、開発環境でクローラーがクロールするのを防ぐために、デフォルトのサーバースニペットがingressテンプレートで設定されているものを上書きするために必要です。`.lagoon.yml`で設定された`server-snippets`。 + +一部の設定では、リバースプロキシ（CDNなど）がKubernetesクラスタの前に配置されます。これらの設定では、リバースプロキシのIPがアプリケーションの`REMOTE_ADDR` `HTTP_X_REAL_IP` `HTTP_X_FORWARDED_FOR`ヘッダー領域として表示されます。リクエスターのオリジナルIPは`HTTP_X_ORIGINAL_FORWARDED_FOR`ヘッダーに見つけることができます。 + +あなたがあなたのアプリケーションでオリジナルのリクエストIPを必要とするなら、 `REMOTE_ADDR` `HTTP_X_FORWARDED_FOR` `HTTP_X_REAL_IP` ヘッダーに元のIPが表示されるようにするには、信頼したいリバースプロキシのIPをイングレスに伝える必要があります： + +```yaml title=".lagoon.yml" +- "example.ch": + annotations: + nginx.ingress.kubernetes.io/server-snippet: | + set_real_ip_from 1.2.3.4/32; +``` + +この例では、CIDR `1.2.3.4/32`（この場合はIP `1.2.3.4`）を信頼します。したがって、IP `1.2.3.4` からKubernetesクラスターにリクエストが送信されると、`X-Forwarded-For` ヘッダーが分析され、その内容が `REMOTE_ADDR` `HTTP_X_REAL_IP` `HTTP_X_FORWARDED_FOR` ヘッダーに注入されます。 + +### `Environments.[name].types` + +Lagoonのビルドプロセスは、`docker-compose.yml`ファイルから`lagoon.type`ラベルをチェックして、どの種類のサービスがデプロイされるべきかを学習します（[`docker-compose.yml`](docker-compose-yml.md#custom-templates)のドキュメンテーションで詳しく読むことができます）。 + +場合によっては、すべてではなく、単一の環境だけで**type**をオーバーライドしたいことがあります。例えば、非本番環境である` 開発： + +`service-name: service-type` + +* `service-name`は、`docker-compose.yml`から上書きしたいサービスの名前です。 +* `service-type`は、上書きで使用したいサービスの種類です。 + +MariaDB\_Galeraの設定例： + +```yaml title=".lagoon.yml" +environments: + develop: + types: + mariadb: mariadb-single +``` + +### `environments.[name].templates` + +Lagoonのビルドプロセスは、`docker-compose.yml`ファイルから`lagoon.template`ラベルをチェックして、サービスがカスタムテンプレートファイルを必要とするかどうかを確認します（`docker-compose.yml`のドキュメンテーションで詳しく読むことができます）。 + +場合によっては、**テンプレート**をすべての環境ではなく、特定の環境だけで上書きしたい場合があります： + +`service-name: template-file` + +* `service-name`は、`docker-compose.yml`から上書きしたいサービスの名前です。 +* `template-file`は、この環境でこのサービスに使用するテンプレートのパスと名前です。 + +#### テンプレート上書きの例 + +```yaml title=".lagoon.yml" +environments: + main: + templates: + mariadb: mariadb.main.deployment.yml +``` + +### `environments.[name].rollouts` + +Lagoonのビルドプロセス `lagoon.rollout`ラベルを`docker-compose.yml`ファイルからチェックし、サービスが特別なロールアウトタイプを必要とするかどうかを確認します（`docker-compose.yml`の[ドキュメンテーション](docker-compose-yml.md#custom-rollout-monitor-types)で詳しく読むことができます）。 + +場合によっては、特に環境のテンプレートタイプを上書きした場合には、単一の環境だけで**ロールアウトタイプ**を上書きしたいことがあります。 + +`service-name: rollout-type` + +* `service-name`は、上書きしたい`docker-compose.yml`のサービスの名前です。 +* `rollout-type`は、ロールアウトのタイプです。可能な値については、`docker-compose.yml`の[ドキュメンテーション](docker-compose-yml.md#custom-rollout-monitor-types)を参照してください。 + +#### カスタムロールアウトタイプの例 + +```yaml title=".lagoon.yml" +environments: + main: + rollouts: + mariadb: statefulset +``` + +### `environments.[name].autogenerateRoutes` + +これにより、ルートの自動生成が無効になっている場合でも、任意の環境が自動生成されたルートを取得することができます。 + +```yaml title=".lagoon.yml" +routes: + autogenerate: + enabled: false +environments: + develop: + autogenerateRoutes: true +``` + +### `environments.[name].cronjobs` + + + +Cronジョブは、通常、すべての環境で同じものを実行することは望ましくないため、各環境で明示的に定義する必要があります。定義したスケジュールにより、CronジョブはKubernetesネイティブの`CronJob`として、または定義したサービスのcrontabを介したin-pod cronジョブとして実行される場合があります。 + +#### Cronジョブの例 + +```yaml title=".lagoon.yml" +cronjobs: + - name: Hourly Drupal Cron + schedule: "M * * * *" # 時間ごとに、ランダムな分に一度 + command: drush cron + service: cli + - name: Nightly Drupal Cron + schedule: "M 0 * * *" # 日ごとに、00:00から00:59のランダムな分に一度 + command: drush cron + service: cli +``` + +* `name`: 他のcronジョブと区別し、目的を特定するための任意の名前。 +* `schedule`: cronジョブの実行スケジュール。Lagoonは、crontab形式の拡張版を使用します。構文がわからない場合は、[crontab generator](https://crontab.guru/)を使用してください。 + + * 分に`M`を指定すると、cronジョブは ランダムな分（毎時間同じ分）に1時間ごとに実行するか、`M/15`を指定して15分ごとに実行するが、時間からのランダムなオフセット（`6,21,36,51`のような）で実行します。この機能を使用してcronジョブを分散させることは、すべてのジョブを分`0`で一斉に実行するよりも良い方法です。 +* `H`を時間に指定すると、cronジョブはランダムな時間（毎日同じ時間）に1日1回実行されます。また、`H(2-4)`を指定すると、2時から4時の間に1日1回実行されます。 + +!!! Info "タイムゾーン：" + + * cronジョブのデフォルトのタイムゾーンはUTCです。 + * ネイティブのcronジョブはノードのタイムゾーンを使用し、それはUTCです。 + * In-podのcronジョブは定義されたサービスのタイムゾーンを使用し、UTC以外に設定することができます。 + +* `command`：実行するコマンド。これはサービスの`WORKDIR`で実行されます。Lagoonイメージの場合、これは`/app`です。 + +!!! warning + Cronジョブは、crontabを介してin-podで実行される可能性があり、それは[複数行のコマンドをサポートしていません](https://www.man7.org/linux/man-pages/man5/crontab.5.html)。複雑なまたは複数行のcronコマンドが必要な場合、コマンドとして使用できるスクリプトに入れる必要があります。[プレロールアウトまたはポストロールアウト タスク](#tasks) は機能します。 + +!!! 危険 + CronジョブはKubernetesのポッドで実行されますが、ポッドの再スケジューリングにより中断される可能性があります。 + そのため、cronジョブを作成する際には、次のcronインターバルでコマンドを安全に中断し、再実行できるようにする必要があります。 + +* `サービス`：コマンドをどのプロジェクトのサービスで実行するか。ほとんどのプロジェクトでは、これは`cli`サービスであるべきです。 + +## ポリサイト + +Lagoonでは、同じGitリポジトリが複数のプロジェクトに追加することができ、これをポリサイトと呼びます。これにより、同じコードベースを実行しながら、異なる独立したデータベースと永続的なファイルを許可することができます。 `.lagoon.yml`では、現在、ポリサイトプロジェクトのためのカスタムルートを指定することのみをサポートしています。標準プロジェクトとの主な違いは、`environments`が二次元要素となり、プロジェクト名が最上位要素となることです。 + +これを利用するには、以下の手順を踏む必要があります： + +1. Lagoonに2つ（以上）のプロジェクトを作成し、それぞれに同じGit URLとプロダクションブランチを設定します。これは**あなたの.lagoon.ymlに従って命名されます**（例：`poly-project1` と `poly-project2`） +2. 各プロジェクトのデプロイキーをGitリポジトリに追加します。 +3. リポジトリのウェブフックを設定します（もし 必要) - その後、プッシュ/デプロイが可能になります。リポジトリへのプッシュは、そのGit URLに対するすべてのプロジェクト/ブランチを同時にデプロイします。 + +### Polysiteの例 + +```yaml title=".lagoon.yml" +poly-project1: + environments: + main: + routes: + - nginx: + - project1.com +poly-project2: + environments: + main: + routes: + - nginx: + - project2.com +``` + +## 特別な項目 + +### `api` + +???+ 情報 + amazee.ioのホストされたLagoonで直接動作する場合、このキーは設定する必要はありません。 + +キー`api`を使用すると、Lagoon CLIと`drush`がLagoon GraphQL APIに接続するために使用する別のURLを定義できます。これはスキーム付きの完全なURLである必要があります。例：`http://localhost:3000` これは通常変更する必要はありませんが、Lagoonの管理者がそうするよう指示する場合があります。 + +### `ssh` + +???+ 情報 + amazee.ioのホストされたLagoonで直接動作する場合、このキーは設定する必要はありません。 + +キー`ssh`を使用すると、Lagoon CLIと`drush`がLagoonリモートシェルサービスに接続するために使用する別のSSHエンドポイントを定義できます。これはコロンで区切られたホスト名とポートである必要があります。例：`localhost:2020` これは通常変更する必要はありませんが、Lagoonの管理者がそうするよう指示する場合があります。 変更する必要はありませんが、Lagoonの管理者がそうするように指示する場合があります。 + +### `container-registries` + +`container-registries` ブロックでは、カスタムまたはプライベートなイメージをプルするための独自のプライベートコンテナレジストリを定義することができます。プライベートコンテナレジストリを使用するには、`username`、`password`、およびオプションでレジストリの `url` が必要です。YAMLで `url` を指定しない場合、デフォルトでDocker Hubを使用します。 + +レジストリユーザーのためのパスワードを定義する方法は2つあります。 + +Lagoon APIで `container_registry` タイプの環境変数を作成します： + +* `lagoon add variable -p -N -V -S container_registry` +* \(詳しくは [Environment Variables](../concepts-advanced/environment-variables.md) を参照してください\) + +作成した変数の名前は、パスワードとして設定することができます： + +```yaml title=".lagoon.yml" +container-registries: + my-custom-registry: + username: myownregistryuser + password: + url: my.own.registry.com +``` + +また、`.lagoon.yml` ファイルに直接プレーンテキストでパスワードを定義することもできます： + +```yaml title=".lagoon .yml" +container-registries: + docker-hub: + username: dockerhubuser + password: MySecretPassword +``` + +### カスタムまたはプライベートなコンテナレジストリイメージの使用 + +カスタムまたはプライベートなコンテナレジストリイメージを使用するには、`docker-compose.yml` ファイル内のサービスを更新して、イメージを定義する代わりにビルドコンテキストを使用するようにする必要があります： + +```yaml title=".docker-compose.yml" +services: + mariadb: + build: + context: . + dockerfile: Dockerfile.mariadb +``` + +`docker-compose.yml` ファイルがビルドを使用するように更新されたら、 `Dockerfile.` を作成し、プライベートイメージを `FROM /:` として設定する必要があります。 + +```yaml title=".lagoon.yml" +FROM dockerhubuser/my-private-database:tag +``` + +## `.lagoon.yml` の例 + +これは全ての可能な設定を示す `.lagoon.yml` の例です。プロジェクトに合わせて調整する必要があります。 + +```yaml linenums="1" title=".lagoon.yml" +docker-compose-yaml: docker-compose.yml + +environment_variables: + git_sha: 'true' + +tasks: + pre-rollout: + - run: + name: drush sql-dump + command: mkdir -p /app/web/sites/default/files/private/ && drush sql-dump --ordered-dump --gzip --result-file=/app/web/sites/default /files/private/pre-deploy-dump.sql.gz + サービス: cli + post-rollout: + - 実行: + 名前: drush cim + コマンド: drush -y cim + サービス: cli + シェル: bash + - 実行: + 名前: drush cr + コマンド: drush -y cr + サービス: cli + +routes: + autogenerate: + insecure: リダイレクト + +environments: + main: + routes: + - nginx: + - example.com + - example.net + - "www.example.com": + tls-acme: true + insecure: リダイレクト + hstsEnabled: true + - "example.ch": + annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri + - www.example.ch + types: + mariadb: mariadb + templates: + mariadb: mariadb.main.deployment.yml + rollouts: + mariadb: statefulset + cronjobs: + - 名前: drush cron + スケジュール: "M * * * *" # これは1時間ごとにcronを実行します。 + コマンド: drush cron + サービス: cli + staging: + cronjobs: + - 名前: drush cron + スケジュール: "M * * * *" # これは1時間ごとにcronを実行します。 + コマンド: drush cron + サービス: cli + feature/feature-branch: + cronjobs: - 名前: drush cron + スケジュール: "H * * * *" # これは毎時一度cronを実行します。 + コマンド: drush cron + サービス: cli +``` + +## 非推奨 + +これらの設定は非推奨となり、あなたの `.lagoon.yml` から削除するべきです。 + +* `routes.autogenerate.insecure` + + `None` オプションは `Redirect` と同等です。 + +* `environments.[name].monitoring_urls` +* `environments.[name].routes.[service].[route].hsts` +* `environments.[name].routes.[service].[route].insecure` + + `None` オプションは `Redirect` と同等です。 \ No newline at end of file diff --git a/docs/contributing-to-lagoon/api-debugging.ja.md b/docs/contributing-to-lagoon/api-debugging.ja.md new file mode 100644 index 0000000000..8b36f48c67 --- /dev/null +++ b/docs/contributing-to-lagoon/api-debugging.ja.md @@ -0,0 +1,57 @@ +# APIデバッグ + +1 . `services/api/package.json`にある`dev`スクリプトが以下を含むことを確認します： + +```javascript title="services/api/package.json" +node --inspect=0.0.0.0:9229 +``` + +2 . `docker-compose.yml`を更新して、`dist`フォルダをマップし、`9229`ポートを公開します： + +```yaml title="docker-compose.yml" + api: + image: ${IMAGE_REPO:-lagoon}/api + command: yarn run dev + volumes: + - ./services/api/src:/app/services/api/src + - ./services/api/dist:/app/services/api/dist + depends_on: + - api-db + - local-api-data-watcher-pusher + - keycloak + ports: + - '3000:3000' + - '9229:9229' +``` + +3 . 次の内容を`.vscode/launch.json`に追加します： + +```javascript title=".vscode/launch.json" +{ + // IntelliSenseを使用して可能な属性について学習します。 + // 既存の属性の説明を表示するには、ホバーします。 + // 詳細情報は、次のURLを参照してください：https://go.microsoft.com/fwlink/?linkid=830387. + "version": "0.2.0", + "configurations": [ + { + "name": "Docker: Attach to Node", + "type": "node", + "request": "attach", + "port": 9229, + "address": "localhost", + "outFiles": ["${workspaceRoot}/app/services/api/dist/**/*.js"], + "localRoot": "${ "workspaceFolder}/services/api", + "remoteRoot": "/app/services/api", + "sourceMaps": true, + "protocol": "inspector" + } + ] +} + +4 . コンテナの再構築/再起動： + +```bash title="コンテナの再起動" +rm build/api && make build/api && docker-compose restart api +``` + +5 . VScodeを再起動します。 \ No newline at end of file diff --git a/docs/contributing-to-lagoon/developing-lagoon.ja.md b/docs/contributing-to-lagoon/developing-lagoon.ja.md new file mode 100644 index 0000000000..edaf0e6c2b --- /dev/null +++ b/docs/contributing-to-lagoon/developing-lagoon.ja.md @@ -0,0 +1,232 @@ +# ラグーンの開発 + +ラグーンのローカル開発は、現在、ローカルのKubernetesクラスターまたはDocker Compose（フォールバックとして）を経由して行うことができます。 + +!!! 注意 + フルのラグーンスタックは、現在ARMベースのアーキテクチャ（M1/M2 Apple Siliconベースのマシンなど）と互換性のない上流プロジェクトに依存しています。このため、これらのアーキテクチャ上で`lagoon-core`または`lagoon-remote`をローカルで実行または開発することは現在サポートされていません。詳細はhttps://github.com/uselagoon/lagoon/issues/3189 をご覧ください。 + +## Docker + +Dockerは、ローカルでラグーンをビルドおよび実行するためにインストールする必要があります。 + +### DockerとDocker Composeのインストール + +Dockerのインストール方法については、[公式ドキュメント](https://docs.docker.com/engine/installation/)をご覧ください。 + +Docker Composeは、Docker for Macのインストールに含まれています。Linuxのインストールについては[こちらの手順](https://docs.docker.com/compose/install/)を参照してください。 + +### Dockerの設定 + +Dockerのセキュアでないレジストリを更新する必要があります。[その方法についてはこちらを読んで](https://docs.docker.com/registry/insecure/)ください。再設定を避けるため、全てのローカルIPv4プライベートアドレススペースを追加することをおすすめします。 KubernetesとDocker Compose。たとえば、`"insecure-registries" : ["172.16.0.0/12","192.168.0.0/16"],` + +### 十分なDockerリソースの割り当て + +ローカルマシン上でLagoon、Kubernetes、またはDockerクラスタを実行すると、多くのリソースを消費します。Dockerホストには最低でも8つのCPUコアと12GBのRAMを割り当てることをお勧めします。 + +## ローカルでLagoonをビルドする + +!!! 警告 + Lagoonをこの方法でビルドを考えるのは、それに機能や機能を開発したい、または内部プロセスをデバッグしたい場合だけです。また、ビルドせずにLagoonをインストールする方法（つまり、公開されたリリースを使用する方法）の指示も提供します。 + +私たちは、必要なDockerイメージをビルドし、Kubernetesを設定し、テストを実行するために`make`（[Makefile](https://github.com/uselagoon/lagoon/blob/main/Makefile)を参照）を使用しています。 + +私たちは、ほとんどのローカル開発シナリオをカバーするために、[Makefile](https://github.com/uselagoon/lagoon/blob/main/Makefile)にいくつかのルーチンを提供しました。ここでは、完全なプロセスを実行します。 + +### イメージのビルド + +1. ここでの`-j8`は、**make**にビルドを速めるために並列で8つのタスクを実行するように指示します。必要に応じて調整してください。 +2. デフォルトで`SCAN_IMAGES=false`を設定して、ビルドしたイメージをスキャンしないようにしています。 脆弱性。これをtrueに設定すると、スキャン結果を含む`scan.txt`ファイルがプロジェクトルートに作成されます。 + +```bash title="イメージのビルド" +make -j8 build +``` + +1. MakefileのデフォルトでLagoonのテストルーティンを開始します（すべてのテスト）。 + +```bash title="テスト開始" +make kind/test +``` + +!!! 警告 + デフォルトで実行するために設定されたテストが多数あります - 機能を確保するために必要最低限のローカルでのテストのみを考慮してください。これは、Makefileの`TESTS`変数からテストを指定したり削除したりすることで行うことができます。 + +このプロセスでは次のことが行われます： + +1. インストールされていない場合は、ローカル開発ツールの正しいバージョンをダウンロードします - `kind`、`kubectl`、`helm`、`jq`。 +2. Lagoonが機能するために必要なHelmリポジトリを更新します。 +3. 前のステップで正しいイメージがすべてビルドされていることを確認します。 +4. ローカルの[KinD](https://kind.sigs.k8s.io/)クラスターを作成します。これは、ローカルのDockerコンテナに完全に稼働するKubernetesクラスタを提供します。このクラスタは、ビルドしたLagoonイメージをプッシュするために提供されたイメージレジストリと通信するように設定されています。また、ローカル開発のためにホストファイルシステムへのアクセスも許可されています。 +5. Lagoonを[ https://github.com/uselagoon/lagoon-charts](https://github.com/uselagoon/lagoon-charts) \(必要に応じてMakefileの`CHARTS_TREEISH`変数を使用してブランチを制御してください\). +6. Harbor ImageレジストリをKinDクラスタにインストールし、そのイングレスとアクセスを適切に設定します。 +7. DockerはビルドしたLagoonのイメージをHarborイメージレジストリにプッシュします。 +8. 次に、[lagoon-chartsのMakefile](https://github.com/uselagoon/lagoon-charts/blob/main/Makefile)を使用して、残りの設定手順を進行します。 +9. 適切なイングレスコントローラーがインストールされます - [NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/)を使用します。 +10. 特定のボリューム要求を処理するローカルNFSサーバープロビジョナーがインストールされます - Read-Write-Many操作（RWX）を処理するものを使用します。 +11. その後、Lagoon Coreがインストールされ、クラスターローカルイメージレジストリにプッシュされたローカルでビルドされたイメージを使用し、デフォルトの設定を使用します。これにより、ローカルテストに必要とされない一部のサービスが除外される場合があります。インストールは、APIとKeycloakがオンラインになるのを待ちます。 +12. DBaaSプロバイダーがインストールされます - MariaDB、PostgreSQL、MongoDB。このステップでは、スタンドアロンのデータベースがプロビジョニングされ、 ローカルで実行中のプロジェクトと、クラウドプロバイダー（例えば、Cloud SQL、RDS、Azure Databaseなど）経由で利用可能なマネージドサービスをエミュレートします。 +13. 次にLagoon Remoteがインストールされ、Lagoon Core、データベース、ローカルストレージと通信するように設定されます。インストールはこれが完了するのを待ってから続行します。 +14. テストをプロビジョニングするために、Lagoon Testチャートがインストールされます。これにより、テストリポジトリをホストするローカルのGitサーバーがプロビジョニングされ、デフォルトのテストユーザー、アカウント、設定でLagoon APIデータベースが事前に設定されます。それから、テストを開始する前に準備チェックを行います。 +15. Lagoonは、MakefileのTESTS変数で指定されたすべてのテストを実行します。各テストは自身のプロジェクトと環境を作成し、テストを実行した後に環境とプロジェクトを削除します。テストの実行結果は`lagoon-test-suite-*`ポッドのコンソールログに出力され、コンテナごとに1つのテストを参照することができます。 + +理想的には、すべてのテストが通過し、すべて終了します！ + +### テストの進行状況とローカルクラスターの表示 + +テストルーチンはローカルのKubeconfigファイル（プロジェクトのルートに`kubeconfig.kind.lagoon`という名前で）を作成し、Kubernetesのダッシュボード、ビューワ、CLIとともに使用することができます。 ローカルクラスタにアクセスするためのツールです。私たちは、[Lens](https://k8slens.dev/)、[Octant](https://octant.dev/)、[kubectl](https://kubernetes.io/docs/reference/kubectl/cheatsheet/)、[Portainer](https://www.portainer.io/)といったツールをワークフローに使用しています。Lagoon Core、Remote、Testsはすべて`Lagoon`ネームスペースでビルドされ、各環境は自身のネームスペースを作成して実行するため、確認する際には正しいコンテキストを使用することを確認してください。 + +ローカルクラスタとkubectlを使用するには、正しいKubeconfigを使用する必要があります。これは、すべてのコマンドで行うことも、好みのツールに追加することもできます： + +```bash title="kubeconfig.kind.lagoon" +KUBECONFIG=./kubeconfig.kind.lagoon kubectl get pods -n lagoon +``` + +ローカルのLagoonをビルドするために使用されるHelmチャートは、ローカルのフォルダにクローンされ、`lagoon-charts.kind.lagoon`にシンボリックリンクされています。ここで設定を確認することができます。後でこのドキュメンテーションで簡単な変更の方法を説明します。 + +### ローカルLagoonクラスタと対話する + +Makefileには、インストールされたLagoonとの対話を簡単にするいくつかのルーチンが含まれています： + +```bash title="Create local ports" +make kind/port-forwards +``` + +これにより、UIを公開するためのローカルポートが作成されます。 6060\）、API \(7070\)、そして Keycloak \(8080\)です。これは `stdout`にログを出力するため、別のターミナル/ウィンドウで実行すべきでしょう。 + +```bash title="管理者の資格情報を取得する" +make kind/get-admin-creds +``` + +これにより、Lagoonとやり取りするための必要な資格情報が取得されます。 + +* JWTは、ローカルのGraphQLクライアントでbearerトークンとして使用するための管理者スコープのトークンです。[詳細はGraphQLのドキュメンテーションをご覧ください](../interacting/graphql.md)。 +* Keycloakの"admin"ユーザー用のトークンがあり、すべてのユーザー、グループ、ロールなどにアクセスできます。 +* Lagoonの"lagoonadmin"ユーザー用のトークンもあり、デフォルトのグループ、権限などを割り当てることができます。 + +```bash title="イメージの再プッシュ" +make kind/dev +``` + +これにより、`KIND_SERVICES`にリストされたイメージが正しいタグで再プッシュされ、lagoon-coreチャートが再デプロイされます。これはLagoonのサービスに対する小さな変更をテストするのに便利ですが、"ライブ"開発はサポートされていません。まずこれらのイメージをローカルで再構築する必要があります。例：`rm build/api && make build/api`. + +```bash title="typescriptのサービスをビルドする" +make kind/local-dev-patch +``` + +これにより、ローカルにインストールされたNode.jsを使用してtypescriptのサービスがビルドされます（これは >16.0\）。その後、次の操作を行います： + +* Lagoonサービスからの「dist」フォルダをKubernetesの正しいlagoon-coreポッドにマウントします +* コードの変更を監視する`nodemon`が動作しているサービスと共にlagoon-coreチャートを再デプロイします +* これによりLagoonでの「ライブ」開発が可能になります。 +* Kubernetesのポッドに変更が反映されるためには、時折再デプロイが必要なことに注意してください。異なるブランチを`git clean -dfx`で再ビルドする場合は、そのサービスからのビルド成果物をクリーンにしてください。なお、distフォルダはGitによって無視されます。 + +```bash title="ロギングを開始" +make kind/local-dev-logging +``` + +これにより、ローカルのDockerに独立したOpenDistro for Elasticsearchクラスタが作成され、Lagoonがすべてのログ（Lagoonおよびプロジェクト）をそれに送信するように設定します。設定は[lagoon-logging](https://github.com/uselagoon/lagoon-charts/tree/main/charts/lagoon-logging)に記載されています。 + +```bash title="テストを再実行" +make kind/retest +# OR +make kind/retest TESTS='[features-kubernetes]' +``` + +これにより、既存のクラスタに対する一連のテスト（`TESTS`変数で定義）が再実行されます。テスト用のイメージ（tests、local-git、data-watcher-pusher）が再プッシュされます。テストを指定することもできます。 TESTS変数をインラインで渡して実行します。 + +テスト設定を更新する場合、テストイメージを再ビルドしてプッシュする必要があります。例えば、`rm build/tests && make build/tests && make kind/push-images IMAGES='tests' && make kind/retest TESTS='[api]'` + +```bash title="Push all images" +make kind/push-images +# OR +make kind/push-images IMAGES='tests local-git' +``` + +これにより、すべてのイメージがイメージレジストリにプッシュされます。`IMAGES`を指定すると、特定のイメージにタグを付けてプッシュします。 + +```bash title="Remove cluster" +make kind/clean +``` + +これにより、ローカルのDockerからKinD Lagoonクラスタが削除されます。 + +### Ansible + +Lagoonテストでは、Ansibleを用いてテストスイートを実行します。特定の機能のテスト範囲は、それぞれのルーチンに分割されています。ローカルで開発作業を行っている場合は、実行するテストを選択し、Makefile内の`$TESTS`変数を更新して、同時に実行されるテストを減らします。 + +これらのテストの設定は3つのサービスで保持されています： + +* `tests`はAnsibleテストサービスそのものです。ローカルのテストルーチンでは、各個々のテストをテストスイートのポッド内の別々のコンテナとして実行します。これらは以下にリストされています。 +* `local-git`はクラスタ内でホストされるGitサーバで、それが保持しています テストのソースファイル。Ansibleはテストの間にこのリポジトリにプルとプッシュを行います。 +* `api-data-watcher-pusher`は、必要なKubernetes設定、テストユーザーアカウントとSSHキー、必要なグループと通知をローカルLagoonに事前に配置するためのGraphQL変異のセットです。 **これは実行ごとにローカルプロジェクトと環境を消去することに注意してください。** + +Kubernetesに関連する個々のルーチンは次のとおりです： + +* `active-standby-kubernetes`はKubernetesでのアクティブ/スタンバイを確認するテストを実行します。 +* `api`はAPI - ブランチ/PRデプロイメント、昇進のテストを実行します。 +* `bitbucket`、`gitlab`、`github`は特定のSCMプロバイダーのテストを実行します。 +* `drupal-php74`は単一ポッドのMariaDB、MariaDB DBaaS、およびDrupal 8/9プロジェクト用のDrush特化テストを実行します（`drupal-php73`はDrushテストを行いません）。 +* `drupal-postgres`は、Drupal 8プロジェクト用の単一ポッドのPostgreSQLとPostgreSQL DBaaSテストを実行します。 +* `elasticsearch`はElasticsearch単一ポッドへのシンプルなNGINXプロキシを実行します。 +* `features-variables`はLagoon内の変数を利用するテストを実行します。 +* `features-kubernetes`はKubernetesに特化した標準的なLagoonテストの範囲を実行します。 +* `features-kubernetes-2`はより高度なkubを実行します * エンダーン特有のテスト - 複数のプロジェクトとサブフォルダ設定をカバー。 +* `nginx`、`node`、`python`は、それぞれのプロジェクトタイプに対して基本テストを実行します。 +* `node-mongodb`は、単一ポッドのMongoDBテストとNode.jsアプリケーションに対するMongoDB DBaaSテストを実行します。 + +## ローカル開発 + +ほとんどのサービスは[Node.js](https://nodejs.org/en/docs/)で書かれています。これらのサービスの多くが同様のNode.jsコードとNode.jsパッケージを共有しているため、[Yarn](https://yarnpkg.com/en/docs)という機能を使用しています。これは[Yarn workspaces](https://yarnpkg.com/en/docs/workspaces)と呼ばれます。Yarn workspacesは、ワークスペースを定義するプロジェクトのルートディレクトリに`package.json`が必要です。 + +サービスの開発は、Docker内で直接行うことができます。それぞれのサービスのコンテナは、ソースコードが実行中のコンテナにマウントされるように設定されています（[`docker-compose.yml`を参照](../concepts-basics/docker-compose-yml.md)）。Node.js自体が`nodemon`を介してコードを監視し、変更があるとNode.jsプロセスを自動的に再起動します。 + +### lagoon-commons + +サービスは多くのNode.jsパッケージだけでなく、実際のカスタムコードも共有しています。このコードは`node-packages/lagoon-commons`内にあり、自動的にシンボリックリンクされます。 Yarnワークスペースによって管理されています。さらに、サービスの[`nodemon`](https://www.npmjs.com/package/nodemon)は、`node-packages`の変更をチェックし、ノードプロセスを自動的に再起動するように設定されています。 + +## トラブルシューティング + +### Node.jsベースのサービスのDockerイメージをビルドできない + +以下のようにイメージを再ビルドしてください： + +```bash title="イメージの再構築" + make clean + make build +``` + +### Node.jsベースのイメージをビルド/実行しようとすると、`node_modules`の内容が不足しているというエラーが出る + +一部のサービスが`yarn`ワークスペースによって管理されている共通の依存関係を持っているため、Lagoonのルートディレクトリで`yarn`を実行してください。 + +### `nip.io`ドメインの解決でエラーが出る + +```text title="エラー" +Error response from daemon: Get https://registry.172.18.0.2.nip.io:32080/v2/: dial tcp: lookup registry.172.18.0.2.nip.io: no such host +``` + +これは、ローカルのリゾルバが結果からプライベートIPをフィルタリングする場合に発生することがあります。これを回避するために、`/etc/resolv.conf`を編集して、結果をフィルタリングしない公開リゾルバを使用するように、上部に`nameserver 8.8.8.8`のような行を追加できます。 + +## 例示的なワークフロー + +ここでは、開発のシナリオと物事を進めるための有用なワークフローをいくつか紹介します。 + +### テストの追加 1. 上記の最初の手順を繰り返します。 +2. `tests/tests/features-variables.yaml`を編集し、テストケースを追加します。 +3. `tests`イメージを再構築します。 + +```bash title="テストの構築" +rm build/tests +make -j8 build/tests +``` + +1. 新しい`tests`イメージをクラスタレジストリにプッシュします。 + +```bash title="テストイメージをプッシュ" +make kind/push-images IMAGES=tests +``` + +1. テストを再実行します。 + +```bash title="テストを再実行" +make kind/retest TESTS='[features-variables]' +``` \ No newline at end of file diff --git a/docs/contributing-to-lagoon/documentation.ja.md b/docs/contributing-to-lagoon/documentation.ja.md new file mode 100644 index 0000000000..3e575330ce --- /dev/null +++ b/docs/contributing-to-lagoon/documentation.ja.md @@ -0,0 +1,37 @@ +# Lagoonドキュメンテーションへの貢献 + +皆さんからいただけるものは何でも大いに評価します！ + +ドキュメンテーションの作成と閲覧を非常に簡単にしており、チームは常にレビューやヒントを提供するために準備ができています。 + +私たちは優れた[Material](https://squidfunk.github.io/mkdocs-material/)テーマと共に[mkdocs](https://www.mkdocs.org/)を使用しています。 + +## ローカルでのドキュメンテーションの閲覧と更新 + +Lagoonリポジトリのルートから（Dockerが必要です）、以下を実行します： + +```bash title="Get local docs up and running." +docker run --rm -it -p 127.0.0.1:8000:8000 -v ${PWD}:/docs ghcr.io/amazeeio/mkdocs-material +``` + + +これにより、任意の更新でライブリロードが設定された開発サーバーが [http://127.0.0.1:8000](http://127.0.0.1:8000)で起動します。 + +カスタマイズされたDockerイメージには、必要なすべての拡張機能が含まれています。 + +あるいは、`mkdocs`パッケージをローカルで実行するには、mkdocsをインストールし、必要なすべてのプラグインをインストールする必要があります。 + +```bash title="Install mkdocs" +pip3 install -r docs/requirements.txt +mkdocs serve +``` + +## クラウドでの編集 + +各ドキュメンテーションページには、右上に"編集"の鉛筆アイコンがあり、それをクリックすると正しいページに移動します。 Gitリポジトリにて。 + +こちらでもお気軽に貢献していただけます。組み込みの[github.dev webベースのエディター](https://docs.github.com/en/codespaces/the-githubdev-web-based-editor)をいつでも使用できます。基本的なマークダウンのプレビューがありますが、mkdocsの素晴らしさはありません。 + +## ドキュメンテーションのデプロイ方法 + +私たちは[Deploy MkDocs](https://github.com/marketplace/actions/deploy-mkdocs) GitHubアクションを使用して、すべてのメインブランチのプッシュをビルドし、`gh-pages` ブランチのデプロイメントをトリガーします。 \ No newline at end of file diff --git a/docs/contributing-to-lagoon/releasing.ja.md b/docs/contributing-to-lagoon/releasing.ja.md new file mode 100644 index 0000000000..cd779c165f --- /dev/null +++ b/docs/contributing-to-lagoon/releasing.ja.md @@ -0,0 +1,59 @@ +# ラグーンのリリース + +ラグーンには多くの動的な部分があるため、リリースはかなり複雑です！ + +## Lagoon-core - タグとテスト + +1. 次の全ての特定されたプルリクエストがメインブランチにマージされていることを確認します： + - [uselagoon/lagoon](https://github.com/uselagoon/lagoon) + - [uselagoon/build-deploy-tool](https://github.com/uselagoon/build-deploy-tool) + - [uselagoon/lagoon-ui](https://github.com/uselagoon/lagoon-ui) +2. 確認が終わったら、次のタグ（マイナーまたはパッチ）をメインブランチにプッシュします。フォーマットはv2.MINOR.PATCHとし、[semver](https://semver.org/)に従います。これにより、Jenkinsビルドがトリガーされ、https://ci.lagoon.sh/blue/organizations/jenkins/lagoon/branches で見ることができます。 +3. これがビルド中の間、`lagoon-ui` と `build-deploy-tool` の適切なコミットに軽量タグをプッシュします。フォーマットは core-v2.MINOR.PATCH とします。build-deploy-toolには他のタグやリリースはありませんが、lagoon-uiには独自のsemverリリースがあり、これはその機能に基づいています。 +4. Jenkinsでのビルドが成功したら、https://github.com/uselagoon/lagoon-charts に移動して、チャートリリースの準備をします。 +5. `lagoon-core` と `lagoon-test` チャートのchart.yamlで、更新します。 以下のフィールド： + - **バージョン：** これはチャートの次の「マイナー」リリースで、通常は対応するlagoon-coreリリースのためのマイナーを使用します + - **appVersion：** これはリリースされたlagoon-coreの実際のタグです + - **artifacthub.io/changes：** 必要なのは以下のスニペットの2行で、リリースされる実際のappVersionに合わせて変更されます。 + + ```yaml title="sample chart.yml snippets" + # これはチャートのバージョンです。このバージョン番号は、アプリ + # バージョンを含む、チャートとそのテンプレートに変更を加えるたびに増やすべきです。 + # バージョンはセマンティックバージョニング（https://semver.org/）に従うことが期待されます。 + version: 1.28.0 + + # これはデプロイされるアプリケーションのバージョン番号です。このバージョン + # 番号は、アプリケーションに変更を加えるたびに増加させるべきです。 + # バージョンはセマンティックバージョニングに従うことが期待されません。それらは + # アプリケーションが使用しているバージョンを反映するべきです。 + appVersion: v2.14.2 + + # このセクションは、artifacthub.ioのチェンジログを収集するために使用されます + # それは各リリースごとに新たに開始されるべきです + # 有効なサポートされている種類は、追加、変更、非推奨、削除、修正、セキュリティがあります + annotations: + artifacthub.io/changes: | + - 種類: 変更 + 説明: Lagoon appVersionをv2.14.2に更新 + ``` + lagoon-coreリリースの結果、lagoon-coreとlagoon-testのチャートのみが更新されます。他に変更がある場合は、lagoon-remoteのプロセスに従ってください。 + +6. このチャートリリースのPRを作成し、Github Actionsスイートが一連のテストを実施します: + - **Lintとテストチャート - マトリクス:** 現在テストされているKubernetesバージョンに対してlintとチャートのインストールを行います + - **Lintとテストチャート - current:** 以前/将来のKubernetesバージョンに対してlintとチャートのインストールを行います + - **Lagoon tests:** リリースに対してansibleテストの全シリーズを実行します。 + + 通常、lintとテストチャートの失敗はよく説明されています（チャート設定の欠落/誤設定）。単一のLagoonテストが失敗する場合は、再実行するだけでかもしれません。複数の失敗が発生した場合は、調査が必要です。 + +これらのテストがすべて成功した後、リリースの作成を進めることができます: + +## Lagoon-core - リリースとリリースノート + +1. [uselagoon/lagoon](https://github.com/uselagoon/lagoon)で、先ほどプッシュしたタグからリリースを作成します。"リリースの生成 "notes"ボタンを使って変更履歴を作成します。リリースに含める内容については、以前のリリースを参照してください。 また、lagoon-imagesのリンクは常に最新のリリース版となります。チャート、lagoon-ui、build-deploy-toolへのリンクはすべて今すぐ埋めることができますが、リンクは今後のステップが完了するまで動作しません。これを最新のリリースとしてマークし、リリースを公開します。 +2. [uselagoon/build-deploy-tool] (https://github.com/uselagoon/build-deploy-tool)で、先ほどプッシュしたタグからリリースを作成します。"リリースノートを生成"ボタンを使用して変更履歴を作成します。最後のcore-v2.Xタグが使用され、他のタグは使用されないことを確認します。リリースに含める内容については、以前のリリースを参照してください。これを最新のリリースとしてマークし、リリースを公開します。 +3. [uselagoon/lagoon-ui] (https://github.com/uselagoon/lagoon-ui)で、先ほどプッシュしたタグからリリースを作成します。"リリースノートを生成"ボタンを使用して変更履歴を作成します。最後のcore-v2.Xタグが使用され、他のタグは使用されないことを確認します。リリースに含める内容については、以前のリリースを参照してください。これを最新のリリースとしてマークし、リリースを公開します。 +4. [uselagoon/lagoon-charts] (https://github.com/uselagoon/lagoon-charts)で 成功したPRをマージすると、lagoon-coreとlagoon-testのリリースが作成されます。結果として得られたlagoon-coreチャートリリースを編集し、タイトルとテキストボックスに対応するlagoonリリースを記載します。以前のリリースと同様にします。 + +## ラグーンリモート - リリースとリリースノート + +Lagoon remoteはLagoon Coreとは別のリリースサイクルを持ち、そのため、依存関係のあるサブチャートやサービスが更新されるたびにリリースすることができます。 \ No newline at end of file diff --git a/docs/contributing-to-lagoon/tests.ja.md b/docs/contributing-to-lagoon/tests.ja.md new file mode 100644 index 0000000000..beff97b565 --- /dev/null +++ b/docs/contributing-to-lagoon/tests.ja.md @@ -0,0 +1,48 @@ +# テスト + +私たちのすべてのテストは[Ansible](https://docs.ansible.com/ansible/latest/index.html)で書かれており、主に以下のアプローチに従っています： + +1. 新しいGitリポジトリを作成します。 +2. ファイルのリスト（`tests/files`内）から一部のファイルを追加し、このGitリポジトリにコミットします。 +3. このGitリポジトリをGitサーバー（ローカルまたはGitHub上）にプッシュします。 +4. トリガーサービス（例えば、実際に送信されるウェブフックと同じウェブフックハンドラーへのウェブフック）にトリガーを送信します。 +5. テストが何かが起こることを期待するURLを監視を開始します（例えば、GitブランチをHTMLテキストとして持つNode.jsアプリをデプロイするなど）。 +6. URLの結果と期待される結果を比較します。 + +Lagoonは主に3つの異なる方法でテストされています： + +## 1. ローカルで + +ローカル開発中にテストする最善の方法はローカルでのテストです。すべてのテストは`make`を介して開始されます。Makeは必要なすべての依存関係をダウンロードし、ビルドします。 + +```bash title="Make tests" +make tests +``` + +これにより、定義されたすべてのテストが実行されます。テストの一部だけを実行したい場合は、`make tests-list`を実行してすべての存在するテストを表示し、それぞれを個別に実行します。 + +たとえば、`make tests/node`はNode.js Dockerイメージのテストを実行します。 + +で マイクロサービスの内部で何が起こっているのかを実際に見るためには、`make logs`を使用できます： + +```bash title="Make logs" +make logs +``` + +または特定のサービスだけを表示するには： + +```bash title="Make logs" +make logs service=webhook-handler +``` + +## 2. 自動化された統合テスト + +Lagoonに対して作成されたプルリクエストをテストするために、専用のJenkinsインスタンスで完全に自動化された統合テストを実行しています：[https://ci.lagoon.sh](https://ci.lagoon.sh)。これは`.Jenkinsfile`内で定義されており、開かれたすべてのプルリクエストに対して自動で実行されます。 + +これにより、すべてのイメージがビルドされ、Kubernetesクラスタが起動し、一連のテストが実行されます。 + +テストはここで見つけることができます： + + +* [https://ci.lagoon.sh/blue/organizations/jenkins/lagoon/activity](https://ci.lagoon.sh/blue/organizations/jenkins/lagoon/activity) + \ No newline at end of file diff --git a/docs/contributing.ja.md b/docs/contributing.ja.md new file mode 100644 index 0000000000..58a2741397 --- /dev/null +++ b/docs/contributing.ja.md @@ -0,0 +1,54 @@ +# 貢献 + +我々はLagoonへのあらゆる種類の貢献を心から歓迎します！ + +## どのような貢献が必要ですか？ + +Lagoonはどんな種類の貢献でも恩恵を受けます - バグ修正、新機能、ドキュメンテーションの更新、あるいは単純なキューのメンテナンスなど - あなたが助けてくれることを我々は嬉しく思います。 + +### Lagoonの開発 + +Lagoonをあなたのローカルマシン上で動かす方法について、KinDを使用した[Developing Lagoon](contributing-to-lagoon/developing-lagoon.md)というセクション全体があります。このドキュメンテーションはまだ非常にWIPですが、あなたを助けるための多くのMakefileルーチンが存在します。 + +### Lagoonのインストール + +我々はLagoonをHelmチャートからインストールする方法を概説した別のセクションを持っています。その名も[Installing Lagoon Into Existing Kubernetes Cluster](installing-lagoon/requirements.md) - このプロセスを可能な限りスムーズにしたいと考えています！ + +### 我々の例題での助け + +現在、我々の最大のニーズの一つは、LagoonがDrupal以外の各種のコンテンツマネジメントシステムなどとどのように動作するかの例をまとめることです。 + +もし、あなたが現在我々がDocker Composeスタックとして持っていないオープンソースCMSまたはフレームワークを立ち上げることができれば、PRを送ってください。既存の例を[https://github.com/uselagoon/lagoon-ex](https://github.com/uselagoon/lagoon-ex)でご覧ください。 ヒント、アドバイス、スターターの問題については、[examples](https://github.com/uselagoon/lagoon-examples)をご覧ください。 + +ただし、可能な限り、基本のDocker Hubイメージ[https://hub.docker.com/u/uselagoon](https://hub.docker.com/u/uselagoon)を使用して作成していただきたいと考えています。適切なイメージがない場合や、当社のイメージを変更する必要がある場合は、PR（可能な場合）を投げていただくか、問題を作成してください（他の誰かが対応できるように）[https://github.com/uselagoon/lagoon-images](https://github.com/uselagoon/lagoon-images)にて。 + +既存の例を改善するために私たちを手伝ってください、もしご可能であれば - 私たちは最良の方法を追求しているのでしょうか、何か意味のないことをしているのでしょうか？ + +これらの例のいずれかのテストに貢献する人にはボーナスポイントがあります – [https://github.com/amazeeio/drupal-example-simple/blob/8.x/TESTING\_dockercompose.md](https://github.com/amazeeio/drupal-example-simple/blob/8.x/TESTING_dockercompose.md)のプロジェクトにいくつかの例テストがありますので、それらをガイダンスに使用してください。私たちが使用しているテストフレームワークは、[Lando](https://lando.dev/)の優れたチームからの[Leia](https://github.com/lando/leia)です。 + +他の例のドキュメンテーションを改善するために私たちを手伝ってください – 私たちは完全なものを期待していませんが、 原稿、整理、役立つリソースへのリンク、明確な声明は全て超素晴らしいです。 + +何か質問がある場合は、[Discord](https://discord.gg/te5hHe95JE)で私たちに連絡してください！ + +## セキュリティの問題を見つけました 🔓 + +私たちはセキュリティを非常に重視しています。 セキュリティの問題を発見したり、発見したと思ったら、是非メンテナに注意を促してください。 + +!!! 危険 + 結果を[security@amazee.io](mailto:security@amazee.io)に送ってください。 GitHubの問題としてそれらをファイルしては**絶対に**しないでください。 + +セキュリティレポートは非常に評価され、公共のカルマとスワッグがもらえます！ 私たちはまた、バグバウンティシステムの作業も進めています。 + +## 問題を見つけました + +私たちは常に問題を解決することに興味がありますので、問題報告は大歓迎です。 あなたの問題がすでに[問題キュー](https://github.com/uselagoon/lagoon/issues)に存在しないことを確認してください。 + +## 機能の要望やアイデアがあります + +素敵です！ [問題](https://github.com/uselagoon/lagoon/issues)を作成していただければ、私たちはそれを検討することを喜びます。 それが実装されることを保証することはできません。 しかし、私たちは常にLagoonに何をもたらすことができるかのアイデアを聞くことに興味があります。 + +別の良い方法は、あなたのアイデアについてDiscord経由で私たちと話すこともです。 . [今日参加してください](https://discord.gg/te5hHe95JE)！ + +## 私はいくつかのコードを書きました + +素晴らしい！それについてプルリクエストをお送りください、可能な限りレビューし、可能であればマージします。 \ No newline at end of file diff --git a/docs/docker-images/commons.ja.md b/docs/docker-images/commons.ja.md new file mode 100644 index 0000000000..778f8c7c08 --- /dev/null +++ b/docs/docker-images/commons.ja.md @@ -0,0 +1,17 @@ +# 共有リソース + +[Lagoon `共有リソース` Dockerイメージ](https://github.com/uselagoon/lagoon-images/tree/main/images/commons)。[公式のAlpineイメージ](https://hub.docker.com/_/alpine/)を基にしています。 + +このイメージ自体には機能はありませんが、代わりに基本イメージであり、他のイメージを構築するために拡張して利用されることを目的としています。Lagoonのすべてのalpineベースのイメージは、共有リソースからコンポーネントを継承しています。 + +## 含まれるツール + +- `docker-sleep` - 標準化された1時間のスリープ +- `fix-permissions` - 指定したディレクトリのパーミッションを自動的に全グループの読み書き可能に修正 +- `wait-for` - サービスが正しい順序で起動していることを保証する小さなスクリプト - https://github.com/eficode/wait-for を基にしています +- `entrypoint-readiness` - 長時間実行されるエントリーポイントが完了したことを確認 +- `entrypoints` - /lagoon/entrypoints/* の下にあるすべてのエントリーポイントをアルファベット/数値順にソースするスクリプト + +## 含まれるエントリーポイント + +このイメージのデフォルトのエントリーポイントのリストは[https://github.com/uselagoon/lagoon-images/tree/main/images/commons/lagoon/entrypoints](https://github.com/uselagoon/lagoon-images/tree/main/images/commons/lagoon/entrypoints)で見つけることができます。それに続くダウンストリームのイメージ 最終的なイメージで実行される`/lagoon`の下にエントリーポイントを提供します。 \ No newline at end of file diff --git a/docs/docker-images/mariadb.ja.md b/docs/docker-images/mariadb.ja.md new file mode 100644 index 0000000000..32efc058ae --- /dev/null +++ b/docs/docker-images/mariadb.ja.md @@ -0,0 +1,72 @@ +# MariaDB + +MariaDBは、オープンソースのMySQL後継者です。 + +[Lagoonの `MariaDB` イメージDockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/10.6.Dockerfile) は、上流のAlpineイメージが提供する公式パッケージ [`mariadb`](https://pkgs.alpinelinux.org/packages?name=mariadb&branch=edge) と [`mariadb-client`](https://pkgs.alpinelinux.org/packages?name=mariadb-client&branch=edge) をベースにしています。 + +このDockerfileは、スタンドアロンのMariaDBデータベースサーバを設定するために使用されることを意図しています。 + +* 10.4 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/10.4.Dockerfile) (Alpine 3.12 は2022年5月までサポート) - `uselagoon/mariadb-10.4` +* 10.5 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/10.5.Dockerfile) (Alpine 3.14 は2023年5月までサポート) - `uselagoon/mariadb-10.5` +* 10.6 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/10.6.Dockerfile) (Alpine 3.16 は2024年5月までサポート) - `uselagoon/mariadb-10.6` +* 10.11 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/10.11.Dockerfile) (Alpine 3.18 は2025年5月までサポート) - `uselagoon/mariadb-10.11` !!!情報 + これらのイメージは、上流のMariaDBイメージから構築されていないため、サポートは別のサイクルに従います - そして、基礎となるAlpineイメージがサポートを受けている限りのみアップデートを受けます - [https://alpinelinux.org/releases/](https://alpinelinux.org/releases/)を参照してください。実際には、ほとんどのMariaDBユーザーはこれらのコンテナをローカルで実行しています - 本番環境ではDBaaSオペレーターが提供するManaged Cloud Databasesを使用します。 + +## Lagoonの適応 + +MariaDBコンテナのデフォルトの公開ポートはポート`3306`です。 + +LagoonがMariaDBコンテナを最良の方法で実行することを可能にするために、`lagoon.type: mariadb`を使用します - これにより、DBaaSオペレーターがクラスターで利用可能な場合にクラウドデータベースをプロビジョニングできます。コンテナ内のMariaDBを特にリクエストするには、`lagoon.type: mariadb-single`を使用します。永続的なストレージは、常に`/var/lib/mysql`でMariaDBコンテナに対してプロビジョニングされます。 + +このイメージはLagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています： + +* フォルダのパーミッションは自動的に[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で調整されるため、このイメージは ランダムなユーザー。 +* MariaDBコンテナが準備完了したことを確認するための `readiness-probe.sh` スクリプト。 + +## `docker-compose.yml` スニペット + +```yaml title="docker-compose.yml" + mariadb: + image: uselagoon/mariadb-10.6-drupal:latest + labels: + # LagoonにこれがMariaDBデータベースであることを伝える + lagoon.type: mariadb + ports: + # ポート3306をランダムなローカルポートで公開し、`docker-compose port mariadb 3306`でそれを見つける + - "3306" + volumes: + # 名前付きボリュームをMariaDBのデフォルトパスにマウントする + - db:/var/lib/mysql +``` + +## 含まれるツール + +* [`mysqltuner.pl`](https://github.com/major/MySQLTuner-perl) - データベースパラメータのチューニングに役立つPerlスクリプト。 +* [`mysql-backup.sh`](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb/mysql-backup.sh) - 開発環境での日次MySQLバックアップを自動化するスクリプト。 +* [`pwgen`](https://linux.die.net/man/1/pwgen) - ランダムで複雑なパスワードを生成するユーティリティ。 + +## 含まれる `my.cnf` 設定ファイル + +このイメージには、_デフォルト_ のMariaDB設定ファイルが含まれており、Lagoonで動作するように最適化されています。一部のオプションは[環境変数](../concepts-advanced/environment-variables.md)を介して設定可能です。 + +## 環境変数 + +| 環境 | 変数名 | デフォルト | 説明 | +| :----------------------------------- | :-------------------- | :--------------------------------------------------------------------------- | +| MARIADB_DATABASE | lagoon | 起動時に作成されるデータベース名。 | +| MARIADB_USER | lagoon | 起動時に作成されるデフォルトユーザー。 | +| MARIADB_PASSWORD | lagoon | 起動時に作成されるデフォルトユーザーのパスワード。 | +| MARIADB_ROOT_PASSWORD | Lag00n | MariaDBのルートユーザーのパスワード。 | +| MARIADB_CHARSET | utf8mb4 | サーバーの文字セットを設定する。 | +| MARIADB_COLLATION | utf8mb4_bin | サーバーの照合順序を設定する。 | +| MARIADB_MAX_ALLOWED_PACKET | 64M | `max_allowed_packet`のサイズを設定する。 | +| MARIADB_INNODB_BUFFER_POOL_SIZE | 256M | MariaDB InnoDBバッファプールのサイズを設定します。 | +| MARIADB_INNODB_BUFFER_POOL_INSTANCES | 1 | InnoDBバッファプールインスタンスの数。 | +| MARIADB_INNODB_LOG_FILE_SIZE | 64M | InnoDBログファイルのサイズ。 | +| MARIADB_LOG_SLOW | (設定なし) | 遅いクエリの保存を制御する変数。 | +| MARIADB_LOG_QUERIES | (設定なし) | すべてのクエリの保存を制御する変数。 | +| BACKUPS_DIR | /var/lib/mysql/backup | データベースのバックアップのデフォルトパス。 | +| MARIADB_DATA_DIR | /var/lib/mysql | MariaDBのデータディレクトリのパス。注意してください、これを変更するとデータの損失が発生する可能性があります！ | +| MARIADB_COPY_DATA_DIR_SOURCE | (設定なし) | mariadbのエントリーポイントスクリプトが定義した`Mをコピーするために使用するパス。 `ARIADB_DATA_DIR`は、MariaDBにデータベースを事前に入れるために使用できます。このスクリプトは、sqlファイルではなく、実際のMariaDBデータファイルを期待しています！また、目的地にすでにmysqlのdatadirが存在しない場合にのみデータをコピーします。| + +`LAGOON_ENVIRONMENT_TYPE`変数が`production`に設定されている場合、パフォーマンスは`MARIADB_INNODB_BUFFER_POOL_SIZE=1024`および`MARIADB_INNODB_LOG_FILE_SIZE=256`を使用して適切に設定されます。 \ No newline at end of file diff --git a/docs/docker-images/mongodb.ja.md b/docs/docker-images/mongodb.ja.md new file mode 100644 index 0000000000..33b1b26d9b --- /dev/null +++ b/docs/docker-images/mongodb.ja.md @@ -0,0 +1,17 @@ +# MongoDB + +> _MongoDBは、モダンなアプリケーション開発者とクラウド時代のために構築された、汎用的な、ドキュメントベースの分散データベースです。MongoDBはドキュメントデータベースであり、JSON形式のドキュメントとしてデータを格納します。_ +> +> * [mongodb.com](https://www.mongodb.com/)から + +## 対応バージョン + +4.0 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mongo/4.Dockerfile) - `uselagoon/mongo-4` + +このDockerfileは、スタンドアロンのMongoDBデータベースサーバーをセットアップするためのものです。 + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています： + +* フォルダーの権限は自動的に[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で適応されるため、このイメージはランダムなユーザーで動作し、したがってKubernetesまたはOpenShiftでも動作します。 \ No newline at end of file diff --git a/docs/docker-images/nginx.ja.md b/docs/docker-images/nginx.ja.md new file mode 100644 index 0000000000..878af26178 --- /dev/null +++ b/docs/docker-images/nginx.ja.md @@ -0,0 +1,67 @@ +# NGINX + +[Lagoonの `nginx` イメージDockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/nginx/Dockerfile)です。公式の[`openresty/openresty` イメージ](https://hub.docker.com/r/openresty/openresty/)を基に作成されています。 + +このDockerfileは、Lagoon内の任意のウェブサーバーのベースとして使用することを目的としています。 + +## Lagoonの調整事項 + +NGINXコンテナのデフォルトの公開ポートは `8080` ポートです。 + +このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかの事項が処理されています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)により自動的に適応されるため、このイメージはランダムなユーザーでも動作します。 +* `/etc/nginx/*` 内のファイルは、コンテナエントリーポイントを使用して [`envplate`](https://github.com/kreuzwerker/envplate) を通じて解析されます。 + +## 含まれる `NGINX` 設定（`static-files.conf`） + +!!! 警告 + デフォルトでは `NGINX` は静的ファイルのみを提供します - これはデータベースやPHPコンポーネントが必要ない静的サイトに使用できます：例えば、静的サイトジェネレーターの [Hugo](https://gohugo.io/)、[Jekyll](https://jekyllrb.com/)、[Gatsby](https://www.gatsbyjs.org/) などです。 + +PHPが必要な場合は、以下を参照してください。 `php-fpm`イメージを見て、`nginx`と`php-fpm`を一緒に使用します。 + +ビルドプロセス中にコンテンツをビルドし、それを`nginx`コンテナに注入します。 + +## ヘルパー + +### `redirects-map.conf` + +リダイレクトを作成するために、私たちは`redirects-map.conf`を設置しています。これにより、マーケティングドメインをサブサイトにリダイレクトしたり、非wwwからwwwへのリダイレクトを行うことができます。**リダイレクトが多い場合は、`redirects-map.conf`をコードの隣に保存することでメンテナンスが容易になります。** + +!!! 注意 + リダイレクトが少ない場合は、`RUN`コマンドを使って`nginx.dockerfile`でリダイレクトを作成する便利な方法があります。 + +以下は、`www.example.com`を`example.com`にリダイレクトし、リクエストを保持する方法を示した例です： + +```bash title="Redirect" +RUN echo "~^www.example.com http://example.com\$request_uri;" >> /etc/nginx/redirects-map.conf +``` + +達成可能なさまざまなタイプのリダイレクトについて詳しく知りたい場合は、[`redirects-map.conf`](https://github.com/uselagoon/lagoon-images/blob/main/images/nginx/redirects-map.conf)のドキュメンテーションを直接参照してください。 + +`redirects-map.conf`を設置した後、それを`nginx.dockerfile`にも含める必要があります。 ビルドに設定ファイルを取り込む方法。 + +```bash title="nginx.dockerfile" +COPY redirects-map.conf /etc/nginx/redirects-map.conf +``` + +### 基本認証 + +`BASIC_AUTH_USERNAME` +および `BASIC_AUTH_PASSWORD` [環境 +変数](../concepts-advanced/environment-variables.md)が設定されている場合、基本認証は自動的に有効になります。 + +!!! 警告 + 自動基本認証設定は便宜上提供されています。ウェブサイトやプライベートデータを保護する安全な方法とは考えられません。 + +## 環境変数 + +いくつかのオプションは[環境 +変数](../concepts-advanced/environment-variables.md)を介して設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :------------------- | :--------- | :--- | +| BASIC_AUTH | restricted | 基本認証を無効にするには `off` に設定します。 | +| BASIC_AUTH_USERNAME | (設定なし) | 基本認証のユーザーネーム。 | +| BASIC_AUTH_PASSWORD | (設定なし) | 基本認証のパスワード。 基本認証（非暗号化）。 | +| FAST_HEALTH_CHECK | (未設定) | 特定のユーザーエージェント（StatusCake、Pingdom、Site25x7、Uptime、nagios）からのGETリクエストを軽量なLagoonサービスヘルスチェックにリダイレクトするには、`true`に設定します。 | diff --git a/docs/docker-images/nodejs.ja.md b/docs/docker-images/nodejs.ja.md new file mode 100644 index 0000000000..81823cfc39 --- /dev/null +++ b/docs/docker-images/nodejs.ja.md @@ -0,0 +1,54 @@ +# Node.js + +[Lagoonの `Node.js` Dockerイメージ](https://github.com/uselagoon/lagoon-images/tree/main/images/node)です。[公式のNode Alpineイメージ](https://hub.docker.com/_/node/)を基に作成しています。 + +## サポートされているバージョン + +Node.jsのイメージは2つのバージョンを提供しています：通常の `node:version` イメージと `node:version-builder`。 + +これらのイメージのビルダーバリアントには、Node.jsのアプリをビルドする際に必要な追加のツール（ビルドライブラリ、npm、Yarnなど）が含まれています。完全なリストについては、[Dockerfile](https://github.com/uselagoon/lagoon-images/tree/main/images/node-builder)をご覧ください。 + +* 12（互換性のためだけに利用可能、公式にはサポートされていません）- `uselagoon/node-12` +* 14（互換性のためだけに利用可能、公式にはサポートされていません）- `uselagoon/node-14` +* 16（互換性のためだけに利用可能、公式にはサポートされていません）- `uselagoon/node-16` +* 18 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node/18.Dockerfile) (2025年4月までのセキュリティサポート) - `uselagoon/node-18` +* 20 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node/20.Dockerfile) (2026年4月までのセキュリティサポート) - `uselagoon/node-20` + +!!! ヒント EOL Node.jsイメージの更新は通常、公式に発表されたEOL日付の後にリリースされるLagoonリリースと共に停止します：[https://nodejs.org/en/about/releases/](https://nodejs.org/en/about/releases/). + +## Lagoonの適応 + +Node.jsコンテナのデフォルトの公開ポートはポート`3000`です。 + +永続的なストレージは、`lagoon.type: node-persistent`を使用してLagoonで設定可能です。詳しくは[ドキュメンテーション](../concepts-basics/docker-compose-yml.md#persistent-storage)をご覧ください。 + +次のラベルを`docker-compose.yml`ファイルで設定します： + +* `lagoon.persistent` = これを使用して、コンテナ内で永続的なストレージとして使用するパスを定義します - 例えば、/app/files。 +* `lagoon.persistent.size` = これを使用して、Lagoonにこのパスに割り当てるストレージの量を通知します。 +* 同じストレージを共有する複数のサービスがある場合は、これを使用します +`lagoon.persistent.name` = （オプション）これを使用して、Lagoonに他の名前付きサービスで定義されたストレージを使用するように指示します。 + +## `docker-compose.yml`スニペット + +```yaml title="docker-compose.yml" + node: + build: + # これはルートフォルダーのDockerfileからビルドを設定します + context: . + dockerfile: Dockerfile + labels: + # このテキストはLagoonに対して、/app/filesに500MBの永続的なストレージを持つノードサービスとして設定されていることを伝えています。 + lagoon.type: node-persistent + lagoon.persistent: /app/files + lagoon.persistent.size: 500Mi + ポート: + # ローカル開発専用 + # ポート3000をランダムなローカルポートとして公開します + # `docker-compose port node 3000`で探すことができます + - "3000" + ボリューム: + # ローカル開発専用 + # 定義されたパスに名前付きボリューム（ファイル）をマウントして、このサービスの本番環境をレプリケートします + - files:/app/files +``` \ No newline at end of file diff --git a/docs/docker-images/opensearch.ja.md b/docs/docker-images/opensearch.ja.md new file mode 100644 index 0000000000..018f8dfd6d --- /dev/null +++ b/docs/docker-images/opensearch.ja.md @@ -0,0 +1,26 @@ +# OpenSearch + +> [_OpenSearch_](https://opensearch.org/)は、データを簡単に取り込み、検索、視覚化、分析することを可能にする、コミュニティ主導のApache 2.0ライセンスのオープンソース検索および分析スイートです。 +> +> * 出典: [https://opensearch.org/](https://opensearch.org/) + +## サポートバージョン + +* 2 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/opensearch/2.Dockerfile) - `uselagoon/opensearch-2` + +## 環境変数 + +いくつかのオプションは[環境変数](../concepts-advanced/environment-variables.md)経由で設定可能です。 + +| 環境変数 | デフォルト値 | 説明 | +| :------------------- | :---------------- | :------------------------------------------------------------------------------------------------------------------------- | +| OPENSEARCH_JAVA_OPTS | -Xms512m -Xmx512m | OpenSearchコンテナのメモリ使用量を設定します。両方の値は同じ値でなければ、OpenSearchは正常に起動しません。 | + +## 既知の問題 + +Linuxベースのシステムでは、`vm.max_map_count`設定が低いためにOpenSearchコンテナの起動が失敗する可能性があります。 ```bash title="エラー" +opensearch_1 | エラー: [1] ブートストラップチェックが失敗しました +opensearch_1 | [1]: 最大仮想メモリエリア vm.max_map_count [65530] が低すぎます、少なくとも [262144] に増やしてください +``` + +[この問題の解決策はここで見つけることができます](https://opensearch.org/docs/latest/opensearch/install/important-settings/). \ No newline at end of file diff --git a/docs/docker-images/php-cli.ja.md b/docs/docker-images/php-cli.ja.md new file mode 100644 index 0000000000..9067827907 --- /dev/null +++ b/docs/docker-images/php-cli.ja.md @@ -0,0 +1,58 @@ +# PHP-CLI + +[Lagoonの `php-cli` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli)です。[Lagoonの `php-fpm`イメージ](./php-fpm.md)を基に、日常的な操作に必要なコマンドラインツールが全て揃っています。 + +`cli`イメージから起動されたコンテナ（またはポッド）はComposerやNode.jsベースのプロジェクトのコードを構築する責任があります。 + +また、このイメージにはMariaDBとPostgreSQLの両方のデータベース`cli`が含まれています。 + +!!! インフォ + このDockerfileは、Lagoon内で`cli`が必要な場合に基本として使用することを意図しています。 + +## サポートされているバージョン + +* 7.3（互換性のために利用可能、公式サポートは終了） - `uselagoon/php-7.3-cli` +* 7.4（互換性のために利用可能、公式サポートは終了） - `uselagoon/php-7.4-cli` +* 8.0（互換性のために利用可能、公式サポートは終了） - `uselagoon/php-8.0-cli` +* 8.1 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli/8.1.Dockerfile)（2024年11月までセキュリティサポート） - `uselagoon/php-8.1-cli` +* 8.2 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli/8.2.Dockerfile)（2025年12月までセキュリティサポート） - `uselagoon/php-8.2-cli` +* 8.3 [ Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-cli/8.3.Dockerfile) (2026年12月までのセキュリティサポート) - `uselagoon/php-8.3-cli` + +すべてのPHPバージョンは、それぞれのDockerfilesを使用します。 + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかの事項が完了しています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に適応されるため、このイメージはランダムなユーザーで動作します。 +* `COMPOSER_ALLOW_SUPERUSER=1`は、rootとしてのComposerの使用に関する警告を削除します。 +* `80-shell-timeout.sh`スクリプトは、コンテナがKubernetes環境で実行されているかどうかを確認し、その後、アイドル`cli`ポッドに10分のタイムアウトを設定します。 +* `cli`コンテナは、Lagoonによって注入されたSSHキーまたは`SSH_PRIVATE_KEY`環境変数に定義されたSSHキーを使用します。 + +## 含まれるCLIツール + +含まれるCLIツールは次のとおりです： + +* [`composer`バージョン1.9.0](https://getcomposer.org/) \( `COMPOSER_VERSION`および`COMPOSER_HASH_SHA256`経由で変更可能\) +* [`node.js`バージョン17](https://nodejs.org/en/) \(2022年3月現在\) +* [`npm`](https://www.npmjs.com/) +* [`yarn`](https://yarnpkg.com/lang/en/) +* `mariadb-client` +* `postgres ql-client` + +### Node.jsバージョンの変更 + +デフォルトでは、このイメージには`nodejs-current`パッケージ（2022年3月時点でv17）が付属しています。別のバージョンが必要な場合は、現在のバージョンを削除して選択したバージョンをインストールできます。例えば、Node.js 16をインストールするには、dockerfileを以下のように修正します。 + +```bash title="Node.jsバージョンの更新" +RUN apk del nodejs-current \ + && apk add --no-cache nodejs=~16 +``` + +## 環境変数 + +いくつかのオプションは[環境変数](../concepts-advanced/environment-variables.md)を介して設定可能です。[php-fpm環境変数](php-fpm.md#environment-variables)も適用されます。 + +| 名前 | デフォルト | 説明 | +| :------------------------- | :------ | :---------------------------------------------------- | +| MARIADB_MAX_ALLOWED_PACKET | 64M | MySqlクライアントの最大許容パケットを制御します。 | \ No newline at end of file diff --git a/docs/docker-images/php-fpm.ja.md b/docs/docker-images/php-fpm.ja.md new file mode 100644 index 0000000000..d0a01ea2c7 --- /dev/null +++ b/docs/docker-images/php-fpm.ja.md @@ -0,0 +1,94 @@ +# PHP-FPM + +[Lagoonの `php-fpm` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm)です。[公式のPHP Alpineイメージ](https://hub.docker.com/_/php/)に基づいています。 + +>_PHP-FPM（FastCGIプロセスマネージャ）は、追加機能を備えた代替PHP FastCGIの実装で、任意のサイズのサイト、特に忙しいサイトに役立ちます。_ +> +> [https://php-fpm.org/](https://php-fpm.org/)より +> +> FastCGIは、サーバースクリプトがタイムコンシューミングなコードを一度だけ実行する方式で、スクリプトがロードされるたびに実行されるのを防ぎ、オーバーヘッドを軽減します。 + +!!! 情報 + このDockerfileは、Lagoon内での任意の`PHP`ニーズの基盤として使用することを目的としています。このイメージ自体はウェブサーバーを作成せず、`php-fpm` fastcgiリスナーを作成します。`php-fpm`プール設定を適応させる必要があるかもしれません。 + +## サポートされているバージョン + +* 7.3 (互換性を保つためのみに利用可能、公式サポートは終了) - `uselagoon/php-7.3-fpm` +* 7.4 (互換性を保つためのみに利用可能、公式サポートは終了) - `uselagoon/php-7.4-fpm` +* 8.0 (互換性を保つためのみに利用可能、公式サポートは終了) - `uselagoon/php-8.0-fpm` +* 8.1 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main /images/php-fpm/8.1.Dockerfile) (2024年11月までのセキュリティサポート) - `uselagoon/php-8.1-fpm` +* 8.2 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/8.2.Dockerfile) (2025年12月までのセキュリティサポート) - `uselagoon/php-8.2-fpm` +* 8.3 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/8.3.Dockerfile) (2026年12月までのセキュリティサポート) - `uselagoon/php-8.3-fpm` + +すべてのPHPバージョンはそれぞれのDockerfilesを使用します。 + +!!! ヒント + End of Life \(EOL\) PHP画像の更新は通常、公式に発表されたEOL日付の後のLagoonリリースで停止します：[https://www.php.net/supported-versions.php](https://www.php.net/supported-versions.php)。以前に公開されたバージョンは利用可能なままとなります。 + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかのことが行われています： + +* フォルダの権限は[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に適応されますので、この画像はランダムなユーザーで動作します。 +* `/usr/local/etc/php/php.ini` および `/usr/local/etc/php-fpm.conf`、および `/usr/local/etc/php-f pm.d/`は、コンテナエントリーポイントを経由して[`envplate`](https://github.com/kreuzwerker/envplate)で解析されます。 +* インストールされている `PHP` 拡張機能については、[Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/8.0.Dockerfile)を参照してください。 +* さらなる拡張機能をインストールするには、このイメージからDockerfileを拡張します。ドキュメントに従って拡張機能をインストールしてください。見出し[How to install more PHP extensions.](https://github.com/docker-library/docs/blob/master/php/README.md#how-to-install-more-php-extensions)を参照。 + +## 含まれるPHP設定 + +含まれる `PHP` 設定には、`PHP` プール設定の作成を容易にする合理的な値が含まれています。以下にいくつかを挙げます。すべてについては `/usr/local/etc/php.ini`、`/usr/local/etc/php-fpm.conf` を確認してください： + +| 値 | 詳細 | +| :--- | :--- | +| `max_execution_time = 900` | `PHP_MAX_EXECUTION_TIME` で変更可能。 | +| `realpath_cache_size = 256k` | 大規模なPHPプロジェクトのため。 | +| `memory_limit = 400M` | 大規模なPHPプロジェクトのため（`PHP_MEMORY_LIMIT` で変更可能）。 | +| `opcache.memory_consumption = 265` | 大規模なPHPプロジェクトのため。 | +| `opcache.enable_file_override = 1` と `opcache.huge_code_pages = 1` | 高速なPHPのため。 | +| `display Translation request timed out. 提供されたプールが開始されます！ + 2. [`PHP_INI_SYSTEM`変更可能モード](https://www.php.net/manual/ja/configuration.changes.modes.php)を持つPHPの値は、`fpm-pool`設定を介して変更できません。すでに提供されている環境変数または以下の方法で変更する必要があります： +3. 独自の`php.ini`または`php-fpm.conf`ファイルを提供します（これは最も好ましくない方法です）。 + +## デフォルトのfpm-pool + +このイメージは、`fpm-pool`設定（[`php-fpm.d/www.conf`](https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/php-fpm.d/www.conf)）が付属しており、`fpm-pool`を作成し、ポート9000でリッスンします。これは、PHPのほとんどのニーズをすでにカバーしているイメージを提供しようとしているためです。もし好きなら、自分自身で作成することも歓迎します！ + +このファイルが何をするかの短い説明： + +* IPv4とIPv6でポート9000でリッスンします。 +* pm `dynamic`を使用し、2-50の子を作成します。 +* メモリリークを防ぐために、500のリクエスト後に`php-fpm`プールの子を再生成します。 +* `/ping`へのfastcgiリクエストに`pong`で応答します（プールが起動したかどうかを自動テストで確認するのに便利）。 +* PHPのエラーを見るために`catch_workers_output = yes`。 +* `clear_env = `を使用して、通常のDocker環境変数経由でPHP環境変数を注入できます。 + +## 環境変数 + +一部のオプションは[環境変数](../concepts-advanced/environment-variables.md)経由で設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :----------------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | +| NEWRELIC_ENABLED | false | NewRelicのパフォーマンスモニタリングを有効にします。`NEWRELIC_LICENSE`の設定が必要です。 | +| NEWRELIC_LICENSE | (未設定) | 使用するNewRelicのライセンス。重要：NewRelicを有効にするには`NEWRELIC_ENABLED`を`true`に設定する必要があります。 | +| NEWRELIC_BROWSER_MONITORING_ENABLED | true | これにより、NewRelicのブラウザモニタリングのためのJavaScriptフラグメントの自動挿入が有効になります。 . 重要：`NEWRELIC_ENABLED`はNewRelicを有効にするために`true`に設定する必要があります。 | +| NEWRELIC_DISTRIBUTED_TRACING_ENABLED | false | これにより分散トレーシングが有効になります。重要：`NEWRELIC_ENABLED`はNewRelicを有効にするために`true`に設定する必要があります。 | +| PHP_APC_ENABLED | 1 | [APC](https://www.php.net/manual/en/apcu.configuration.php)を無効にするために`0`に設定することができます。 | +| PHP_APC_SHM_SIZE | 32m | 与えられた各共有メモリセグメントのサイズ。 | +| PHP_DISPLAY_ERRORS | Off | エラーが表示されるか非表示にされるかを設定します。[php.netを参照してください](https://www.php.net/display-errors)。 | +| PHP_DISPLAY_STARTUP_ERRORS | Off | スタートアップエラーが表示されるか非表示にされるかを設定します。[php.netを参照してください](https://www.php.net/display-startup-errors)。 | +| PHP_ERROR_REPORTING | Production `E_ALL & ~E _DEPRECATED & ~E_STRICT` 開発: `E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE` | PHPが使用するログレベルを設定します。[php.netを参照](https://www.php.net/manual/en/function.error-reporting.php) | +| PHP_FPM_PM_MAX_CHILDREN | 50 | 子プロセスの最大数。[php.netを参照](https://www.php.net/manual/en/install.fpm.configuration.php)。 | +| PHP_FPM_PM_MAX_REQUESTS | 500 | 各子プロセスが再生成される前に実行するべきリクエストの数。[php.netを参照](https://www.php.net/manual/en/install.fpm.configuration.php)。 | +| PHP_FPM_PM_MAX_SPARE_SERVERS | 2 | アイドル状態のサーバープロセスの最大数を設定します。[php.netを参照](https://www.php.net/manual/en/install.fpm.configuration.php)。 | +| PHP_FPM_PM_MIN_SPARE_SERVERS | 2 | アイドル状態のサーバープロセスの最小数を設定します。[php.netを参照](https://www.php.net/manual/en/install.fpm.configuration.php)。 | +| PHP_FPM_PM_PROCESS_IDLE_TIMEOUT | 60s | アイドルプロセスが強制終了されるまでの秒数。[php.netを参照](https://www.php.net /manual/ja/install.fpm.configuration.php)。 | +| PHP_FPM_PM_START_SERVERS | 2 | 起動時に作成される子プロセスの数。 [php.netを参照](https://www.php.net/manual/ja/install.fpm.configuration.php)。 | +| PHP_MAX_EXECUTION_TIME | 900 | 各スクリプトの最大実行時間（秒）。 [php.netを参照](https://www.php.net/max-execution-time)。 | +| PHP_MAX_FILE_UPLOADS | 20 | 同時にアップロードできるファイルの最大数。 [php.netを参照](https://www.php.net/manual/ja/ini.core.php#ini.max-file-uploads)。 | +| PHP_MAX_INPUT_VARS | 2000 | 受け入れ可能な入力変数の数。 [php.netを参照](https://www.php.net/manual/ja/info.configuration.php#ini.max-input-vars)。 | +| PHP_MEMORY_LIMIT | 400M | スクリプトが消費できるメモリの最大量。 [php.netを参照](https://www.php.net/memory-limit)。 | +| XDEBUG_ENABLE | (設定なし) | `xdebug` 拡張機能を有効にするには、`true`に設定します。 | +| BLACKFIRE_ENABLED | (設定されていません) | `blackfire` 拡張機能を有効にするには `true` に設定します。 | +| BLACKFIRE_SERVER_ID | (設定されていません) | Blackfire.io から提供されている Blackfire サーバー ID に設定します。`BLACKFIRE_ENABLED` を `true` に設定する必要があります。 | +| BLACKFIRE_SERVER_TOKEN | (設定されていません) | Blackfire.io から提供されている Blackfire サーバートークンに設定します。`BLACKFIRE_ENABLED` を `true` に設定する必要があります。 | +| BLACKFIRE_LOG_LEVEL | 3 | blackfire エージェントのログレベルを変更します。利用可能な値：`ログの冗長性レベル (4: デバッグ, 3: 情報, 2: 警告, 1: エラー)` [blackfire.ioを参照](https://blackfire.io/docs/up-and-running/configuration/agent)。 | \ No newline at end of file diff --git a/docs/docker-images/postgres.ja.md b/docs/docker-images/postgres.ja.md new file mode 100644 index 0000000000..986d7cacd5 --- /dev/null +++ b/docs/docker-images/postgres.ja.md @@ -0,0 +1,45 @@ +# PostgreSQL + +[Lagoon PostgreSQL Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres)。[公式PostgreSQL Alpineイメージ](https://hub.docker.com/_/postgres)を基にしています。 + +## サポートされているバージョン + +* 11 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/11.Dockerfile) (2023年11月までのセキュリティサポート) - `uselagoon/postgres-11` +* 12 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/12.Dockerfile) (2024年11月までのセキュリティサポート) - `uselagoon/postgres-12` +* 13 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/13.Dockerfile) (2025年11月までのセキュリティサポート) - `uselagoon/postgres-13` +* 14 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/14.Dockerfile) (2026年11月までのセキュリティサポート) - `uselagoon/postgres-14` +* 15 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/15.Dockerfile) (2027年11月までのセキュリティサポート) - `uselagoon/postgres-15` +* 16 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres/16.Dockerfile) (11月までのセキュリティサポート) 2028) - `uselagoon/postgres-16` + +!!! ヒント + Lagoonリリースが公式に通知されたEOL日付の後に、通常、EOL PostgreSQLイメージの更新を停止します：[https://www.postgresql.org/support/versioning](https://www.postgresql.org/support/versioning/) + +## Lagoonの適応 + +Postgresコンテナのデフォルトの公開ポートはポート`5432`です。 + +LagoonがPostgresコンテナを最適な方法で実行できるようにするためには、`lagoon.type: postgres`を使用してください。これにより、クラスタ内で利用可能な場合にDBaaSオペレータがクラウドデータベースをプロビジョニングできます。コンテナ内のPostgresを特にリクエストするには、`lagoon.type: postgres-single`を使用してください。永続的なストレージは常に、/var/lib/postgresql/dataでpostgresコンテナにプロビジョニングされます。 + +## `docker-compose.yml` スニペット + +```yaml title="docker-compose.yml" +postgres: + image: uselagoon/postgres-14-drupal:latest + labels: + # LagoonにこれがPostgresデータベースであることを伝える + lagoon.type: postgres + ports: + # ポート5432をランダムなローカルポートで公開する + # `docker-compose port postgres 5432`で見つけることができる + - "5432" + volumes: + # Postgresのデフォルトパスに名前付きボリュームをマウントする + - db:/var/lib/postgresql/data +``` + +## ヒント＆コツ + +SQLがある場合 コンテナの起動直後にデータベースを初期化するために実行する必要があるステートメントは、その `.sql` ファイルをコンテナの `docker-entrypoint-initdb.d` ディレクトリに配置できます。そのディレクトリに含まれる任意の `.sql` ファイルは、PostgreSQLコンテナを起動する一部として自動的に起動時に実行されます。 + +!!! 警告 + これらのスクリプトは、コンテナが空のデータベースで開始された場合にのみ実行されます。 \ No newline at end of file diff --git a/docs/docker-images/python.ja.md b/docs/docker-images/python.ja.md new file mode 100644 index 0000000000..970a187b62 --- /dev/null +++ b/docs/docker-images/python.ja.md @@ -0,0 +1,53 @@ +# Python + +[Lagoon `python` Docker image](https://github.com/uselagoon/lagoon-images/tree/main/images/python)。これは[公式のPython Alpineイメージ](https://hub.docker.com/_/python/)に基づいています。 + +## サポートされているバージョン + +* 2.7 \(互換性のためのみで、公式にはもうサポートされていません\) - `uselagoon/python-2.7` +* 3.7 \(互換性のためのみで、公式にはもうサポートされていません\) - `uselagoon/python-3.7` +* 3.8 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python/3.8.Dockerfile) (2024年10月までセキュリティサポート) - `uselagoon/python-3.8` +* 3.9 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python/3.9.Dockerfile) (2025年10月までセキュリティサポート) - `uselagoon/python-3.9` +* 3.10 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python/3.10.Dockerfile) (2026年10月までセキュリティサポート) - `uselagoon/python-3.10` +* 3.11 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python/3.11.Dockerfile) (2027年10月までセキュリティサポート) - `uselagoon/python-3.11` +* 3.12 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/python/3.12.Dockerfile) (セキュリティ 2028年10月までのサポート）- `uselagoon/python-3.12` + +!!! ヒント + 私たちは通常、公式に通知されたEOL日付の後に来るLagoonリリースとともにEOL Pythonイメージの更新と公開を停止します：[https://devguide.python.org/versions/#versions](https://devguide.python.org/versions/#versions)。以前に公開されたバージョンは引き続き利用可能です。 + +## Lagoonの適応 + +Pythonコンテナのデフォルトの公開ポートはポート`8800`です。 + +永続的なストレージは、`lagoon.type: python-persistent`を使用してLagoonで設定可能です。詳細については[ドキュメント](../concepts-basics/docker-compose-yml.md#persistent-storage)をご覧ください。 + +次のラベルを`docker-compose.yml`ファイルで使用して設定します： +`lagoon.persistent` = これを使用して、永続的なストレージとして使用するコンテナ内のパスを定義します - 例えば/app/files +`lagoon.persistent.size` = これを使用してLagoonにこのパスにどれだけのストレージを割り当てるかを伝えます。 + +同じストレージを共有する複数のサービスがある場合は、これを使用します +`lagoon.persistent.name` =（オプション）これを使用してLagoonに別の名前付きサービスで定義されたストレージを使用するように伝えます。 + +## `docker-compose.yml`のスニペット + +```yaml title="docker-compose.yml" +python: + build: + # これはビルドを設定します ルートフォルダにあるDockerfile + context: . + dockerfile: Dockerfile + labels: + # Lagoonにこれがpythonサービスであり、/app/filesに500MBの永続的なストレージが設定されていることを伝えます + lagoon.type: python-persistent + lagoon.persistent: /app/files + lagoon.persistent.size: 500Mi + ports: + # ローカル開発のみ + # 8800ポートをランダムなローカルポートで公開します + # `docker-compose port python 8800`で見つけることができます + - "8800" + volumes: + # ローカル開発のみ + # このサービスの定義されたパスで名前付きボリューム（ファイル）をマウントし、本番環境を再現します + - files:/app/files +``` diff --git a/docs/docker-images/rabbitmq.ja.md b/docs/docker-images/rabbitmq.ja.md new file mode 100644 index 0000000000..4b783a5534 --- /dev/null +++ b/docs/docker-images/rabbitmq.ja.md @@ -0,0 +1,46 @@ +# RabbitMQ + +管理プラグインがインストールされた[Lagoon RabbitMQ Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/rabbitmq/Dockerfile)。公式の `rabbitmq:3-management` イメージに基づいています。[docker-hub](https://hub.docker.com/_/rabbitmq)でご確認いただけます。 + +このDockerfileは、スタンドアロンのRabbitMQキューブローカーをセットアップするため、またデフォルトで高可用性キューサポート付きのクラスタをセットアップするためのベースイメージとして使用することを目的としています（[ミラーリングキュー](https://www.rabbitmq.com/ha.html)参照）。 + +デフォルトでは、RabbitMQブローカーは単一ノードとして起動します。クラスタを起動する場合は、`rabbitmq`イメージに加えて`rabbitmq_peer_discovery_k8s`プラグインを使用した[`rabbitmq-cluster`](https://github.com/uselagoon/lagoon-images/blob/main/images/rabbitmq-cluster/Dockerfile) Dockerイメージを使用する必要があります。 + +## サポートされるバージョン + +* 3.10 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/rabbitmq/Dockerfile) (2023年7月までセキュリティサポートあり) - `uselagoon/rabbitmq` + +## Lagoon適応 + +このイメージはLagoonで使用するために準備されています。したがって、すでにいくつかの事項が完了しています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/usel agoon/lagoon-images/blob/main/images/commons/fix-permissions)、ランダムなユーザーと一緒にこのイメージが動作します。 +* ファイル`/etc/rabbitmq/definitions.json`は、[`envplate`](https://github.com/kreuzwerker/envplate)を通じてパースされ、コンテナエントリーポイントになります。 + +## デフォルトのRabbitMQスキーマ（definitions.json）が含まれています + +* ミラーリングキューのサポートを有効にするには、少なくとも一つの[`policy`](https://www.rabbitmq.com/parameters.html#policies)が存在しなければなりません。 +* `definitions.json`スキーマファイルでは、コンテナの実行に必要な最小限のエンティティが定義されています： `virtualhost`（`vhost`）、`username`、管理UIへの`password`、`permissions`、`policies`。 + +デフォルトでは、起動時に`lagoon-ha`というポリシーが作成されますが、キューの名前パターンと一致しないためアクティブではありません（デフォルトの[環境変数](rabbitmq.md#environment-variables)を参照）。 + +```javascript title="definitions.json" +"policies":[ + {"vhost":"${RABBITMQ_DEFAULT_VHOST}","name":"lagoon-ha","pattern":"${RABBITMQ_DEFAULT_HA_PATTERN}", "definition":{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic","ha-sync-batch-size":5}} + ] +``` + +デフォルトでは、`ha-mode`は`exactly`に設定されており、これは キュー（ミラーズ）のミラーリングノードの正確な数。 ノードの数は `ha-params` で制御されます。 + +詳細な情報やカスタム設定については、[公式の RabbitMQ ドキュメンテーション](https://www.rabbitmq.com/ha.html)を参照してください。 + +## 環境変数 + +いくつかのオプションは[環境変数](../concepts-advanced/environment-variables.md)を通じて設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :------------------------- | :--------- | :---------------------------------------- | +| RABBITMQ_DEFAULT_USER | guest | 管理UIへのアクセス用のユーザ名。 | +| RABBITMQ_DEFAULT_PASS | guest | 管理UIへのアクセス用のパスワード。 | +| RABBITMQ_DEFAULT_VHOST | / | RabbitMQのメインの仮想ホスト。 | +| RABBITMQ_DEFAULT_HA_PATTERN| ^$ | ミラーリングキューにマッチする正規表現。 | diff --git a/docs/docker-images/redis.ja.md b/docs/docker-images/redis.ja.md new file mode 100644 index 0000000000..be9b0c2bd8 --- /dev/null +++ b/docs/docker-images/redis.ja.md @@ -0,0 +1,104 @@ +# Redis + +[Lagoon `Redis`イメージDockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/redis) は、[公式 `redis:alpine`イメージ](https://hub.docker.com/_/redis/)を元にしています。 + +このDockerfileは、デフォルトでスタンドアロンのRedis _エフェメラル_ サーバーをセットアップするために使用することを意図しています。 + +## サポートされているバージョン + +* 5（互換性のためのみ利用可能、公式にはもはやサポートされていません） - `uselagoon/redis-5`または`uselagoon/redis-5-persistent` +* 6 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/redis/6.Dockerfile) - `uselagoon/redis-6`または`uselagoon/redis-6-persistent` +* 7 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/redis/7.Dockerfile) - `uselagoon/redis-7`または`uselagoon/redis-7-persistent` + +## 使用方法 + +Redisイメージには2つの異なるバリエーションがあります：**エフェメラル** と **パーシステント**。 + +### エフェメラル + +エフェメラルイメージは、アプリケーションのインメモリキャッシュとして使用することを意図しており、コンテナの再起動を越えてデータを保持しません。 + +インメモリ（RAM）キャッシュとして使用する場合、大きなキャッシュを持っている場合に最初に調整したいかもしれないことは、`MAXMEMORY`変数を適応させることです。この変数は、どの程度の最大メモリ（RAM）を制御します。 Redisはキャッシュアイテムの保存に使用します。 + +### 永続的 + +永続的なRedisイメージは、コンテナの再起動を越えてデータを永続化し、永続性が必要なキューまたはアプリケーションデータに使用できます。 + +通常、メモリ内キャッシュのシナリオで永続的なRedisを使用することはお勧めしません。これは、Redisコンテナが再起動し、ディスクからデータをロードしているときに、アプリケーションに予期しない副作用をもたらす可能性があるからです。 + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)を使用して自動的に適応されるため、このイメージはランダムなユーザーで動作します。 +* `/etc/redis/*`内のファイルは、コンテナエントリーポイント経由で[`envplate`](https://github.com/kreuzwerker/envplate)を使用してテンプレート化されます。 + +## 含まれる `redis.conf` 設定ファイル + +このイメージには、Lagoonで動作するように最適化された _default_ Redis設定ファイルが含まれています。 + +### 環境変数 + +一部のオプションは[環境変数](../concepts-advanced/environment-variables.md)を介して設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :------------------- | :---------- | :----------------------------------------------------------------------------------------- | +| データベース | -1 | スタートアップ時に作成されるデータベースのデフォルト数。 | +| ログレベル | 通知 | ログのレベルを定義します。 | +| 最大メモリ使用量 | 100mb | メモリの最大使用量。 | +| 最大メモリポリシー | allkeys-lru | Redisが最大メモリ使用量に達したときにキーを追い出すためのポリシー。 | +| REDIS_PASSWORD | 無効 | [認証機能](https://redis.io/topics/security#authentication-feature)を有効にします。 | + +## カスタム設定 + +ベースイメージに基づいて、カスタム設定を含めることができます。 +Redis設定ファイルの完全なドキュメンテーションについては、[こちら](https://raw.githubusercontent.com/antirez/redis/4.0/redis.conf)をご覧ください。 + +## Redis-persistent + +以下に基づいています [Lagoonの `redis`イメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/redis/5.Dockerfile)、[Lagoonの `redis-persistent` Dockerイメージ](https://github.com/uselagoon/lagoon-images/blob/main/images/redis-persistent/5.Dockerfile)は、Redisサービスを`persistent`モード（つまり、キーがディスクに保存される永続化ボリュームで）で利用する場合に使われます。 + +これは`redis`との違いは、`FLAVOR`環境変数だけで、それは使用中のredisのバージョンにより、[それぞれのRedis設定](https://github.com/uselagoon/lagoon-images/tree/main/images/redis/conf)を使用します。 + +## トラブルシューティング + +LagoonのRedisイメージにはすべて`redis-cli`コマンドが事前にロードされており、これによりRedisサービスに情報を問い合わせたり、設定値を動的に設定したりできます。このユーティリティを使用するには、[ここ](../interacting/ssh.md)の指示に従って`pod`の値として`redis`を使用してRedisポッドにSSH接続し、接続したらターミナルから実行します。 + +### 最大メモリポリシー + +デフォルトでは、Lagoonの`redis`イメージは`allkeys-lru`ポリシーを使用するように設定されています。このポリシーでは、Redisに格納された**任意の**キーが、もし/ Redisサービスが、最近最も使用されていないキーに基づいて`maxmemory`制限に達した場合。 + +典型的なインストールでは、これが理想的な設定であり、DrupalがRedisでキャッシュされた各キーに`TTL`値を設定しない場合があります。 `maxmemory-policy`が`volatile-lru`のように設定されていて、Drupalがこれらの`TTL`タグを提供しない場合、これはRedisコンテナが埋まり、**いかなる**キーも追い出すことが完全にできなくなり、新しいキャッシュキーを全く受け付けなくなる結果となります。 + +Redisのmaxmemoryポリシーについての詳細情報は、Redisの[公式ドキュメンテーション](https://redis.io/docs/manual/eviction/#eviction-policies)で確認できます。 + +!!! danger "注意して進めてください" + この設定を変更すると、Redisが完全にいっぱいになり、結果として停電を引き起こす可能性があります。 + +### Redisの`maxmemory`値の調整 + +Redisに与えるメモリの最適量を見つけるのはかなり難しい作業です。Redisキャッシュのメモリサイズを調整しようとする前に、実際にはできるだけ長い時間、通常通りに稼働させることが賢明です。理想的な最小期間は、少なくとも1日間の典型的な使用です。 + +これらのメモリ値を調整する際に考慮すべきいくつかの高レベルの事項があります： + +* 最初に確認するべきことは 現在Redisが使用しているメモリの割合。 + * この割合が`50％`未満の場合は、`maxmemory`の値を25％下げることを検討してみてください。 + * この割合が`50％`と`75％`の間であれば、問題なく稼働しています。 + * この値が`75％`を超える場合、他の変数を見て`maxmemory`を増やす必要があるかどうか確認する価値があります。 +* Redisのメモリ使用率が高いと判断した場合、次に見るべきはキーの追い出し数です。 + * 大量のキー追い出しとメモリ使用率が`95％`を超えると、Redisが`maxmemory`設定を高くする必要があることをかなりよく示しています。 + * キーの追い出し数が多くなく、通常の応答時間が妥当であれば、これは単にRedisがその割り当てられたメモリを期待通りに管理していることを示しています。 + +### 例のコマンド + +以下のコマンドは、Redisサービスに関する情報を表示するために使用できます： + +* Redisサービスに関するすべての情報を表示：`redis-cli info` +* サービスのメモリ情報を表示：`redis-cli info memory` +* サービスのキースペース情報を表示：`redis-cli info keyspace` +* サービスの統計情報を表示：`redis-cli info stats` + +また、値を設定することも可能です Redisサービスを再起動せずに動的に設定することができます。動的に設定したこれらの値は、ポッドが再起動されると（デプロイメント、メンテナンス、あるいは単に一つのノードから別のノードへの移動の結果として起こり得る）永続化されません。 + +* `maxmemory`の設定値を動的に`500mb`に設定する: `config set maxmemory 500mb` +* `maxmemory-policy`の設定値を動的に`volatile-lru`に設定する: `config set maxmemory-policy volatile-lru` \ No newline at end of file diff --git a/docs/docker-images/ruby.ja.md b/docs/docker-images/ruby.ja.md new file mode 100644 index 0000000000..3fcef5ad0a --- /dev/null +++ b/docs/docker-images/ruby.ja.md @@ -0,0 +1,37 @@ +# Ruby + +[Lagoon `ruby` Dockerイメージ](https://github.com/uselagoon/lagoon-images/tree/main/images/ruby)。[公式のPython Alpineイメージ](https://hub.docker.com/_/ruby/)に基づいています。 + +## サポートされているバージョン + +* 3.0 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/ruby/3.0.Dockerfile) (2024年3月までのセキュリティサポート) - `uselagoon/ruby-3.0` +* 3.1 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/ruby/3.1.Dockerfile) (2025年3月までのセキュリティサポート) - `uselagoon/ruby-3.1` +* 3.2 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/ruby/3.2.Dockerfile) (2026年3月までのセキュリティサポート) - `uselagoon/ruby-3.2` + +!!! ヒント + Lagoonは、公式に通知されたEOL日付の後にリリースされるLagoonリリースとともに、通常EOL Rubyイメージの更新と公開を停止します：[https://www.ruby-lang.org/en/downloads/releases/](https://www.ruby-lang.org/en/downloads/releases/)。以前のバージョンは利用可能なままです。 + +## Lagoonの適応 + +rubyコンテナのデフォルトの公開ポートはポート`3000`です。 + +LagoonにはRubyサービスの「事前定義された」タイプはありません。それらは`lagoon.type: generic`とポートを`lagoonで設定する必要があります。 `.port: 3000` + +## `docker-compose.yml` スニペット + +```yaml title="docker-compose.yml" +ruby: + build: + # これは、ルートフォルダのDockerfileからのビルドを設定します + context: . + dockerfile: Dockerfile + labels: + # Lagoonにこれが一般的なサービスで、ポート3000を公開するように設定されていることを伝えます + lagoon.type: generic + lagoon.port: 3000 + ports: + # ローカル開発のみ + # これはポート3000をランダムなローカルポートで公開します + # `docker-compose port ruby 3000`で見つけることができます + - "3000" +``` diff --git a/docs/docker-images/solr.ja.md b/docs/docker-images/solr.ja.md new file mode 100644 index 0000000000..c907fbb760 --- /dev/null +++ b/docs/docker-images/solr.ja.md @@ -0,0 +1,31 @@ +# Solr + +[Lagoon `Solr`イメージのDockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/solr/7.Dockerfile)。公式の[`solr:-alpine`イメージ](https://hub.docker.com/_/solr)を基にしています。 + +このDockerfileは、初期コア`mycore`を持つスタンドアロンのSolrサーバーをセットアップするために使用することを意図しています。 + +## サポートされているバージョン + +* 5.5 \(互換性のために利用可能、公式サポートは終了\) +* 6.6 \(互換性のために利用可能、公式サポートは終了\) +* 7.7 \(互換性のために利用可能、公式サポートは終了\) +* 7 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/solr/7.Dockerfile) - `uselagoon/solr-7` +* 8 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/solr/8.Dockerfile) - `uselagoon/solr-8` + +## Lagoonの適応 + +このイメージはLagoonで使用するために準備されています。したがって、すでにいくつかのことが行われています： + +* フォルダの権限は自動的に[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で調整されるため、このイメージはランダムなユーザーで動作します。 +* `Solr`ポートを修正し確認する`10-solr-port.sh`スクリプト。 +* `20-solr-datadir.sh` `Solr`の設定がLagoonに適合しているかを確認するスクリプトです。これによりディレクトリのパスが設定され、正しいロックタイプが設定されます。 + +## 環境変数 + +一部のオプションは[環境変数](../concepts-advanced/environment-variables.md)を通じて設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :------------------------ | :-------- | :------------------------------------------------------------------------ | +| SOLR_JAVA_MEM | 512M | デフォルトのJava HEAPサイズ（例. `SOLR_JAVA_MEM="-Xms10g -Xmx10g"`）。 | +| SOLR_DATA_DIR | /var/solr | Solrのデータディレクトリのパス。注意してください、これを変更するとデータが失われる可能性があります！ | +| SOLR_COPY_DATA_DIR_SOURCE | (未設定) | Solrのエントリーポイントスクリプトが定義した`SOLR_DATA_DIR`にコピーするためのパス。これはSolrにコアを事前に準備するために使用できます。スクリプトは実際のSolrデータファイルを必要とします！また、目的地が既にSolrコアを持っていない場合にのみデータをコピーします。 | diff --git a/docs/docker-images/varnish.ja.md b/docs/docker-images/varnish.ja.md new file mode 100644 index 0000000000..3c8da96cae --- /dev/null +++ b/docs/docker-images/varnish.ja.md @@ -0,0 +1,42 @@ +# バニッシュ + +[Lagoonの `Varnish` Docker画像](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish)です。 [公式 `Varnish`パッケージ](https://hub.docker.com/_/varnish)に基づいています。 + +## 対応しているバージョン + +* 5（互換性のためだけに利用可能、公式にはもうサポートされていません）- `uselagoon/varnish-5` +* 6.0 LTS [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish/6.Dockerfile) - `uselagoon/varnish-6` +* 7 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/varnish/7.Dockerfile) - `uselagoon/varnish-7` + +## 含まれているバニッシュモジュール + +* [`vbox-dynamic`](https://github.com/nigoroll/libvmod-dynamic) - DNSルックアップとSRVレコードからのサービスディスカバリからのダイナミックバックエンド。 +* [`vbox-bodyaccess`](https://github.com/aondio/libvmod-bodyaccess) - リクエストボディにアクセスできるようにするVarnish `vmod`。 + +## Lagoon適応 + +このイメージはLagoonで使用するために準備されています。そのため、すでにいくつかの作業が行われています： + +* フォルダの権限は、[`fix-permissions`](https://github.com/uselagoon/lagoon-images/blob/main/images/commons/fix-permissions)で自動的に調整されるため、このイメージはランダムなユーザーで動作します。 + +## 含まれている `default.v `cl`設定ファイル + +このイメージには、Lagoonで動作するように最適化されたデフォルトの`vcl`設定ファイルが付属しています。いくつかのオプションは環境変数を介して設定可能です（[環境変数](#environment-variables)を参照）。 + +## 環境変数 + +いくつかのオプションは[環境変数](../concepts-advanced/environment-variables.md)を介して設定可能です。 + +| 環境変数 | デフォルト | 説明 | +| :------------------------- | :-------------------- | :-------------------------------------------------------------------------------------- | +| VARNISH_BACKEND_HOST | NGINX | デフォルトのバックエンドホスト。 | +| VARNISH_BACKEND_PORT | 8080 | デフォルトのVarnishリスニングポート。 | +| VARNISH_SECRET | lagoon_default_secret | 管理に接続するために使用されるVarnishのシークレット。 | +| LIBVMOD_DYNAMIC_VERSION | 5.2 | `vmod-dynamic`モジュールのデフォルトバージョン。 | LIBVMOD_BODYACCESS_VERSION | 5.0 | `vmod-bodyaccess`モジュールのデフォルトバージョン。 | +| HTTP_RESP_HDR_LEN | 8k | 任意のHTTPバックエンドレスポンスヘッダの最大長さ。 | +| HTTP_RESP_SIZE | 32k | 取り扱うHTTPバックエンドレスポンスのバイト数の最大値。 | +| NUKE_LIMIT | 150 | オブジェクトボディのスペースを作るために削除しようとするオブジェクトの最大数。 | +| CACHE_TYPE | malloc | varnishキャッシュのタイプ。 | +| CACHE_SIZE | 100M | キャッシュサイズ。 | +| LISTEN | 8080 | デフォルトのバックエンドサーバーポート。 | +| MANAGEMENT_LISTEN | 6082 | デフォルトの管理リスニングポート。 あなたが提供する内容は何ですか？ \ No newline at end of file diff --git a/docs/installing-lagoon/add-group.ja.md b/docs/installing-lagoon/add-group.ja.md new file mode 100644 index 0000000000..1f2d697117 --- /dev/null +++ b/docs/installing-lagoon/add-group.ja.md @@ -0,0 +1,5 @@ +# グループを追加 + +```bash title="グループを追加" + lagoon add group -N グループ名 +``` \ No newline at end of file diff --git a/docs/installing-lagoon/add-project.ja.md b/docs/installing-lagoon/add-project.ja.md new file mode 100644 index 0000000000..9380e9eb5b --- /dev/null +++ b/docs/installing-lagoon/add-project.ja.md @@ -0,0 +1,52 @@ +# プロジェクトの追加 + +## プロジェクトをLagoonに追加する + +1. 以下のコマンドを実行します： + + ```bash title="プロジェクトの追加" + lagoon add project \ + --gitUrl \ + --openshift 1 \ + --productionEnvironment \ + --branches \ + --project + ``` + + * `--openshift`の値は、あなたのKubernetesクラスタのIDです。 + * 本番環境は、本番環境として使用したいブランチの名前であるべきです。 + * デプロイしたいブランチは、次のようになる可能性があります：`“^(main|develop)$”` + * プロジェクトの名前は何でも良い - “会社のウェブサイト,” “例,” などです。 + +2. Lagoon UIに移動し、プロジェクトがリストに表示されているはずです！ + +## デプロイキーをGitリポジトリに追加する + +Lagoonは各プロジェクトにデプロイキーを作成します。これをGitリポジトリのデプロイキーとして追加することで、Lagoonがコードをダウンロードできるようにする必要があります。 + +1. デプロイキーを取得するために以下のコマンドを実行します： + + ```bash title="プロジェクトキーの取得" + lagoon get project-key --project + ``` + +2. キーをコピーし、Gitリポジトリのデプロイキーとして保存します。 + +[GitHub](https://docs.github.com/en/de 開発者/概要/デプロイキーの管理#deploy-keys) {.md-button} +[GitLab](https://docs.gitlab.com/ee/user/project/deploy\_keys/){ .md-button } +[Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/add-access-keys/){ .md-button } + +## Gitリポジトリにwebhooksエンドポイントを追加する + +Lagoonがコードの更新時にデプロイできるように、Gitリポジトリに接続する必要があります。 + +1. LagoonクラスタのwebhookエンドポイントをGitリポジトリに追加します。 + + * ペイロードURL: `` + * コンテンツタイプ: JSON + * アクティブ: アクティブ（必要に応じて有効/無効を切り替えることができます） + * イベント: 関連するイベントを選択するか、全てを選択します。通常はプッシュ、ブランチの作成/削除が必要です + +[GitHub](https://docs.github.com/en/developers/webhooks-and-events/webhooks/creating-webhooks){ .md-button } +[GitLab](https://docs.gitlab.com/ee/user/project/integrations/webhooks.html){ .md-button } +[Bitbucket](https://support.atlassian.com/bitbucket-cloud/docs/manage-webhooks/){ .md-button } \ No newline at end of file diff --git a/docs/installing-lagoon/create-user.ja.md b/docs/installing-lagoon/create-user.ja.md new file mode 100644 index 0000000000..139f5613f6 --- /dev/null +++ b/docs/installing-lagoon/create-user.ja.md @@ -0,0 +1,11 @@ +# ラグーンユーザーの作成 + +1. Lagoon CLIを使ってユーザーを追加します： + + ```bash title="ユーザーの追加" + lagoon add user --email user@example.com --firstName MyFirstName --lastName MyLastName + ``` + +2. あなたのメールに移動し、メール内のパスワードリセットリンクをクリックします。 +3. 指示に従って作成したパスワードでLagoon UIにログインします。 +4. ユーザーのSSH公開鍵を**設定**から追加します。 \ No newline at end of file diff --git a/docs/installing-lagoon/deploy-project.ja.md b/docs/installing-lagoon/deploy-project.ja.md new file mode 100644 index 0000000000..83fdcff170 --- /dev/null +++ b/docs/installing-lagoon/deploy-project.ja.md @@ -0,0 +1,14 @@ +# プロジェクトをデプロイする + +1. プロジェクトをデプロイするための以下のコマンドを実行します： + + ```bash title="デプロイ" + lagoon deploy branch -p <あなたのプロジェクト名> -b <あなたのブランチ名> + ``` + +2. LagoonのUIに移動し、プロジェクトを確認してみてください - このプロジェクトの環境が表示されているはずです！ +3. クラスタ内のPodsリストを確認し、Gitリポジトリをクローンしたり、サービスをセットアップしたりするビルドPodが見えるはずです。 + + ```bash title="全てのpodsを見る" + kubectl get pods --all-namespaces | grep lagoon-build + ``` \ No newline at end of file diff --git a/docs/installing-lagoon/efs-provisioner.ja.md b/docs/installing-lagoon/efs-provisioner.ja.md new file mode 100644 index 0000000000..3c149010b9 --- /dev/null +++ b/docs/installing-lagoon/efs-provisioner.ja.md @@ -0,0 +1,37 @@ +# EFSプロビジョナー + +!!!情報 + これはAWSインストールにのみ適用されます。 + +1. Helmリポジトリを追加します： + + ```bash title="Helmリポジトリを追加" + helm repo add stable https://charts.helm.sh/stable + ``` + +2. 設定ディレクトリに`efs-provisioner-values.yml`を作成し、値を更新します： + + ```yaml title="efs-provisioner-values.yml" + efsProvisioner: + efsFileSystemId: + awsRegion: + path: / + provisionerName: example.com/aws-efs + storageClass: + name: bulk + isDefault: false + reclaimPolicy: Delete + mountOptions: [] + global: + deployEnv: prod + + ``` + +3. EFSプロビジョナーをインストールします： + + ```bash title="EFSプロビジョナーをインストール" + helm upgrade --install --create-namespace \ + --namespace efs-provisioner --wait \ + -f efs-provisioner-values.yaml \ + efs-provisioner stable/efs-provisioner + ``` \ No newline at end of file diff --git a/docs/installing-lagoon/gitlab.ja.md b/docs/installing-lagoon/gitlab.ja.md new file mode 100644 index 0000000000..abce280553 --- /dev/null +++ b/docs/installing-lagoon/gitlab.ja.md @@ -0,0 +1,34 @@ +# GitLab + +\*ほとんどの\*インストールでは必要ありませんが、これはLagoonとGitLabをユーザーおよびグループ認証のために統合するように設定されています。 + +1. 管理者権限を持つユーザーのGitLabで[パーソナルアクセストークンを作成](https://docs.gitlab.com/ee/user/profile/personal\_access\_tokens.html)します。 +2. `your-gitlab.com/admin/hooks` の下にシステムフックを作成し、`webhookhandler.lagoon.example.com` にポイントし、ランダムな秘密のトークンを定義します。 + 1. 「リポジトリ更新イベント」を有効にします。 +3. `lagoon-core-values.yml`を更新します： + + ```yaml title="lagoon-core-values.yml" + api: + additionalEnvs: + GITLAB_API_HOST: <> + GITLAB_API_TOKEN: << APIへのアクセスを持つパーソナルアクセストークン >> + GITLAB_SYSTEM_HOOK_TOKEN: << システムフック秘密トークン >> + webhook-haondler: + additionalEnvs: + GITLAB_API_HOST: <> + GITLAB_API_TOKEN: << APIへのアクセスを持つパーソナルアクセストークン >> + GITLAB_SYSTEM_HOOK_TOKEN: << システムフック秘密トークン >> + webhooks2tasks: + additionalEnvs: + GITLAB_API_HOST: <> + GITLAB_API_TOKEN: << Personal APIへのアクセスを持つアクセストークン >> + GITLAB_SYSTEM_HOOK_TOKEN: << システムフックシークレットトークン >> + ``` + +4. `lagoon-core` helmchartをHelmで更新します。 +5. すでにKeycloakにユーザーを作成している場合は、それらを削除します。 +6. APIポッドで以下のコマンドを実行します： + + ```bash title="GitLabと同期" + yarn sync:gitlab:all + ``` diff --git a/docs/installing-lagoon/install-harbor.ja.md b/docs/installing-lagoon/install-harbor.ja.md new file mode 100644 index 0000000000..9e5e3a19b6 --- /dev/null +++ b/docs/installing-lagoon/install-harbor.ja.md @@ -0,0 +1,63 @@ +# Harborをインストール + +1. Helmリポジトリを追加します: + + ```bash title="Helmリポジトリを追加" + helm repo add harbor https://helm.goharbor.io + ``` + +2. あなたの特定の状況に最適なHarborの設定を考慮してください - 詳細な推奨事項については[彼らのドキュメント](https://goharbor.io/docs/latest/install-config/harbor-ha-helm/#configuration)を参照してください: + + 1. 画像のblob(`imageChartStorage`)にはS3互換のストレージの使用を推奨します。 + 2. Postgresサービス(`database.type`)にはマネージドデータベースサービスの使用を推奨します。 + 3. 高負荷シナリオでは、マネージドRedisサービス(`redis.type`)の使用を推奨します。 + +3. 設定ディレクトリ内に`harbor-values.yml`ファイルを作成します。プロキシバッファリングの注釈は大きな画像のプッシュに役立ちます: + + ```yaml title="harbor-values.yml" + expose: + ingress: + annotations: + kubernetes.io/tls-acme: "true" + nginx.ingress.kubernetes.io/proxy-buffering: "off" + nginx.ingress.kubernetes.io/proxy-request-buffering: "off" + hosts: + core: harbor.lagoon.example.com + tls: + enabled: true + certSource: secret + secret: + secretName: harbor-harbor-ingress + external URL：https://harbor.lagoon.example.com + harborAdminPassword：<あなたのHarbor管理者パスワード> + chartmuseum： + enabled：false + clair： + enabled：false + notary： + enabled：false + trivy： + enabled：false + jobservice： + jobLogger：stdout + ``` + +4. 現在サポートされているHarborバージョンの[要件](./requirements.md#harbor)を確認しながら、Harborをインストールします。 + + ```bash title="Harborのインストール" + helm upgrade --install --create-namespace \ + --namespace harbor --wait \ + -f harbor-values.yml \ + harbor harbor/harbor + ``` + +5. `harbor.yml`で設定したURLでHarborを訪れます。 + + 1. ユーザー名：admin + 2. パスワード： + + ```bash title="Harborのシークレットを取得" + kubectl -n harbor get secret harbor-core -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 --decode + ``` + +6. 次のステップのLagoon Remote `values.yml`と`harbor-values.yml`に上記のHarborの資格情報を追加する必要があります。 \ No newline at end of file diff --git a/docs/installing-lagoon/install-lagoon-remote.ja.md b/docs/installing-lagoon/install-lagoon-remote.ja.md new file mode 100644 index 0000000000..538996e7b1 --- /dev/null +++ b/docs/installing-lagoon/install-lagoon-remote.ja.md @@ -0,0 +1,82 @@ +# Lagoon Remoteをインストール + +次に、Lagoon RemoteをLagoon名前空間にインストールします。[RabbitMQ](../docker-images/rabbitmq.md)サービスがブローカーとなります。 + +1. 前の二つのファイルと同様に、設定ディレクトリに`lagoon-remote-values.yml`を作成し、値を更新します。 + + * **rabbitMQPassword** + + ``` bash title="RabbitMQ passwordを取得" + kubectl -n lagoon-core get secret lagoon-core-broker -o jsonpath="{.data.RABBITMQ_PASSWORD}" | base64 --decode + ``` + + * **rabbitMQHostname** + + ```bash title="lagoon-remote-values.yml" + lagoon-core-broker.lagoon-core.svc.local + ``` + + * **taskSSHHost** + + ```bash title="SSH Hostを更新" + kubectl get service lagoon-core-broker-amqp-ext \ + -o custom-columns="NAME:.metadata.name,IP ADDRESS:.status.loadBalancer.ingress[*].ip,HOSTNAME:.status.loadBalancer.ingress[*].hostname" + ``` + + * **harbor-password** + + ```bash title="Harbor secretを取得" + kubectl -n harbor get secret harbor-harbor-core -o jsonpath="{.data.HARBOR_ADMIN_PASSWORD}" | base64 --decode + ``` + +1. [Harborのインストール](./install-harbor.md)のステップからHarbor設定を追加します。 + + ```yaml title="lagoon-remote-values.yml" + lagoon-build-deploy: + enabled: true + extraArgs : + - "--enable-harbor=true" + - "--harbor-url=https://harbor.lagoon.example.com" + - "--harbor-api=https://harbor.lagoon.example.com/api/" + - "--harbor-username=admin" + - "--harbor-password=" + rabbitMQUsername: lagoon + rabbitMQPassword: + rabbitMQHostname: lagoon-core-broker.lagoon-core.svc.cluster.local + lagoonTargetName: + taskSSHHost: + taskSSHPort: "22" + taskAPIHost: "api.lagoon.example.com" + dbaas-operator: + enabled: true + + mariadbProviders: + production: + environment: production + hostname: 172.17.0.1.nip.io + readReplicaHostnames: + - 172.17.0.1.nip.io + password: password + port: '3306' + user: root + + development: + environment: development + hostname: 172.17.0.1.nip.io + readReplicaHostnames: + - 172.17.0.1.nip.io + password: password + port: '3306' + user: root + ``` + +1. [ssh-core service account](https://github.com/uselagoon/lagoon-charts/blob/main/charts/lagoon-remote/values.yaml#L116-L を有効にします。 125) + +1. Lagoon Remoteをインストールする： + + ```bash title="Lagoon remoteをインストール" + helm upgrade --install --create-namespace \ + --namespace lagoon \ + -f lagoon-remote-values.yml \ + lagoon-remote lagoon/lagoon-remote + ``` \ No newline at end of file diff --git a/docs/installing-lagoon/lagoon-backups.ja.md b/docs/installing-lagoon/lagoon-backups.ja.md new file mode 100644 index 0000000000..89e57c89ff --- /dev/null +++ b/docs/installing-lagoon/lagoon-backups.ja.md @@ -0,0 +1,101 @@ +# ラグーンバックアップ + +ラグーンは、K8upバックアップオペレーターを使用しています：[https://k8up.io](https://k8up.io)。ラグーンはK8upと密接に統合されているわけではありません。むしろ、ラグーンはそのリソースをK8upが自動的に発見してバックアップできるように作成できます。 + +ラグーンはK8up 1.xと広範にテストされていますが、まだ2.xとは互換性がありません。1.1.0チャートバージョン（アプリバージョンv1.2.0）の使用を推奨します。 + +1. ポリシーを持つ新しいAWSユーザーを作成します。 + + ```json title="example K8up IAM user" + { + "Version":"2012-10-17", + "Statement":[ + { + "Sid":"VisualEditor0", + "Effect":"Allow", + "Action":[ + "s3:ListAllMyBuckets", + "s3:CreateBucket", + "s3:GetBucketLocation" + ], + "Resource":"*" + }, + { + "Sid":"VisualEditor1", + "Effect":"Allow", + "Action":"s3:ListBucket", + "Resource":"arn:aws:s3:::baas-*" + }, + { + "Sid":"VisualEditor2", + "Effect":"Allow", + "Action":[ + "s3:PutObject", + "s3:GetObject", + "s3:AbortMultipartUpload", + "s3:DeleteObject", + "s3:ListMultipartUploadParts" + ``` + ], + "Resource":"arn:aws:s3:::baas-*/*" + } + ] + } + ``` + +2. あなたのプロバイダーに合わせて`k8up-values.yml`を作成します： + + ```yaml title="k8up-values.yml" + k8up: + envVars: + - name: BACKUP_GLOBALS3ENDPOINT + value: 'https://s3.eu-west-1.amazonaws.com' + - name: BACKUP_GLOBALS3BUCKET + value: '' + - name: BACKUP_GLOBALKEEPJOBS + value: '1' + - name: BACKUP_GLOBALSTATSURL + value: 'https://backup.lagoon.example.com' + - name: BACKUP_GLOBALACCESSKEYID + value: '' + - name: BACKUP_GLOBALSECRETACCESSKEY + value: '' + - name: BACKUP_BACKOFFLIMIT + value: '2' + - name: BACKUP_GLOBALRESTORES3BUCKET + value: '' + - name: BACKUP_GLOBALRESTORES3ENDPOINT + value: 'https://s3.eu-west-1.amazonaws.com' + - name: BACKUP_GLOBALRESTORES3ACCESSKEYID + value: '' + - name: BACKUP_GLOBALRESTORES3SECRETACCESSKEY + value: '' + timezone: Europe/Zurich + ``` + +3. K8upをインストール： + + ```bash title="K8upをインストールするステップ1" + helm repo add appuio https://charts.appuio.ch + ``` + + ```bash title="K8upをインストールするステップ 2" + kubectl apply -f https://github.com/vshn/k8up/releases/download/v1.2.0/k8up-crd.yaml + ``` + + ```bash title="K8upのインストールステップ3" + helm upgrade --install --create-namespace \ + --namespace k8up \ + -f k8up-values.yaml \ + --version 1.1.0 \ + k8up appuio/k8up + ``` + +4. `lagoon-core-values.yml`を更新します： + + ```yaml title="lagoon-core-values.yml" + s3BAASAccessKeyID: <<リストアバケット用のAccess Key ID>> + s3BAASSecretAccessKey: <<リストアバケット用のAccess Key Secret>> + ``` + +5. `lagoon-core`を再デプロイします。 \ No newline at end of file diff --git a/docs/installing-lagoon/lagoon-cli.ja.md b/docs/installing-lagoon/lagoon-cli.ja.md new file mode 100644 index 0000000000..91da8d4868 --- /dev/null +++ b/docs/installing-lagoon/lagoon-cli.ja.md @@ -0,0 +1,32 @@ +# Lagoon CLIのインストール + +1. あなたのオペレーティングシステムに対応するインストール方法については、[https://github.com/uselagoon/lagoon-cli#install](https://github.com/uselagoon/lagoon-cli#install)をご覧ください。macOSとLinuxでは、Homebrewを使用することができます。 + 1. `brew tap uselagoon/lagoon-cli` + 2. `brew install lagoon` +2. CLIはLagoonとどのように通信するかを知る必要があるため、以下のコマンドを実行します： + + ```bash title="Lagoon config" + lagoon config add \ + --graphql https://YOUR-API-URL/graphql \ + --ui https://YOUR-UI-URL \ + --hostname YOUR.SSH.IP \ + --lagoon YOUR-LAGOON-NAME \ + --port 22 + ``` + +3. SSHキーで認証してLagoonにアクセスします。 + + 1. Lagoon UI（URLは`values.yml`に記載されています）に移動し、**設定**に進みます。 + 2. 公開SSHキーを追加します。 + 3. amazee.ioのデフォルトを使用しようとするのを防ぐため、デフォルトのLagoonを_あなたの_ Lagoonに設定する必要があります： + + ```bash title="Lagoon config" + lagoon config default --lagoon + ``` + +4. `lagoon login`を実行します。LagoonはSSHに接続し、公開/秘密キーペアに対して認証を行い、ユーザー名のトークンを取得します。 + +5. `lagoon whoami`を通じて検証します。それが ログインしています。 + +!!! 情報 + 一般的にはラグーン管理者ロールの使用を推奨していませんが、最初に始めるためには管理者アカウントを作成する必要があります。理想的には、管理者では_ない_別のアカウントをすぐに作成して作業を行います。 \ No newline at end of file diff --git a/docs/installing-lagoon/lagoon-core.ja.md b/docs/installing-lagoon/lagoon-core.ja.md new file mode 100644 index 0000000000..e4bdecf82d --- /dev/null +++ b/docs/installing-lagoon/lagoon-core.ja.md @@ -0,0 +1,24 @@ +# Lagoon Coreのインストール + +## Helmチャートのインストール + +1. Lagoon ChartsリポジトリをHelmリポジトリに追加します: + + ```bash title="Lagoon Chartsリポジトリの追加" + helm repo add lagoon https://uselagoon.github.io/lagoon-charts/ + ``` + +2. 作成する設定ファイルのディレクトリを作成し、バージョン管理されていることを確認します。`values.yml`ファイルを参照するコマンドでこのパスを参照してください。 +3. 作成したディレクトリに`values.yml`を作成します。エンドポイントURLを更新します（それらを`api.lagoon.example.com`からあなたの値に変更します）。 + 例: [https://github.com/uselagoon/lagoon-charts/blob/main/charts/lagoon-core/ci/linter-values.yaml](https://github.com/uselagoon/lagoon-charts/blob/main/charts/lagoon-core/ci/linter-values.yaml) +4. 次に、`values.yml`を指定して`helm upgrade --install`コマンドを実行します。以下のようになります: + + ```bash title="values.ymlを使用してHelmをアップグレード" + helm upgrade --install --create-namespace --namespace lagoon-core -f values.yml lagoon-core lagoon/lagoon-core` + ``` + +5. Lagoon Coreがインストールされました！ + +!!! 警告 + 時々、Docker Hubのプル制限に遭遇します。これが続く場合は、私たちのイメージを他の場所に移動することを検討しています。 Translation request timed out. -core-keycloak -o jsonpath="{.data.KEYCLOAK_LAGOON_ADMIN_PASSWORD}" | base64 --decode + ``` diff --git a/docs/installing-lagoon/lagoon-files.ja.md b/docs/installing-lagoon/lagoon-files.ja.md new file mode 100644 index 0000000000..6871bd64ac --- /dev/null +++ b/docs/installing-lagoon/lagoon-files.ja.md @@ -0,0 +1,55 @@ +# ラグーンファイル + +ラグーンファイルは、バックアップなどのタスクのファイル出力を保存するために使用され、S3互換ストレージにホストできます。 + +1. ポリシーを持つ新しいAWSユーザーを作成します： + + ```json title="例：ファイルIAMユーザー" + { + "バージョン":"2012-10-17", + "ステートメント":[ + { + "効果":"許可", + "アクション":[ + "s3:ListBucket", + "s3:GetBucketLocation", + "s3:ListBucketMultipartUploads" + ], + "リソース":"arn:aws:s3:::S3_BUCKET_NAME" + }, + { + "効果":"許可", + "アクション":[ + "s3:PutObject", + "s3:GetObject", + "s3:DeleteObject", + "s3:ListMultipartUploadParts", + "s3:AbortMultipartUpload" + ], + "リソース":"arn:aws:s3:::S3_BUCKET_NAME/*" + } + ] + } + ``` + +2. `lagoon-core-values.yml`を更新します： + + ```yaml title="lagoon-core-values.yml" + s3FilesAccessKeyID: <<アクセスキーID>> + s3FilesBucket: <<ラグーンファイル用のバケット名>> + s3FilesHost: <> + s3FilesSecretAccessKey: <<アクセスキーシークレット>> + s3FilesRegion: <> + ``` + +3. もしもあなたが `lagoon-core`の前に`ingress-nginx`を使用することを提案します。これにより、より大きなファイルのアップロードが可能になります： + + ```yaml title="lagoon-core-values.yml" + controller: + config: + client-body-timeout: '600' # 最大600秒のファイルアップロード + proxy-send-timeout: '1800' # 最大30分の接続 - ウェブソケットに必要 + proxy-read-timeout: '1800' # 最大30分の接続 - ウェブソケットに必要 + proxy-body-size: 1024m # 1GBファイルサイズ + proxy-buffer-size: 64k # 大きなバッファ + ``` diff --git a/docs/installing-lagoon/lagoon-logging.ja.md b/docs/installing-lagoon/lagoon-logging.ja.md new file mode 100644 index 0000000000..33dba11e7c --- /dev/null +++ b/docs/installing-lagoon/lagoon-logging.ja.md @@ -0,0 +1,96 @@ +# ラグーンロギング + +ラグーンは、アプリケーション、コンテナ、ルーターのログを保存するためにOpenSearchと統合します。ラグーンロギングは、ラグーンプロジェクトからアプリケーション、ルーター、コンテナのログを収集し、それらをログ集約器に送信します。それは各`lagoon-remote` インスタンスにインストールする必要があります。 + +さらに、それは`lagoon-core`サービスからログを収集するために`lagoon-core`クラスターにインストールするべきです。これは`LagoonLogs`セクションで設定されています。 + +ロギング概要：[Lucid Chart](https://lucid.app/lucidchart/70f9610e-cfd7-42e8-8b5b-3d03293a439c/view?page=Uq-x~LhSIxrp&invitationId=inv_4e891071-f795-4ada-bbd3-2ff63b8eb1f7#) + +参照：[Logging](../logging/logging.md)。 + +ラグーンロギングについて詳しくはこちらをご覧ください：[https://github.com/uselagoon/lagoon-charts/tree/main/charts/lagoon-logging](https://github.com/uselagoon/lagoon-charts/tree/main/charts/lagoon-logging) + +1. `lagoon-logging-values.yaml`を作成します： + + ```yaml title="lagoon-logging-values.yaml" + tls: + caCert: | + << Logs-Concentratorからのca.pemの内容 >> + clientCert: | + << Logs-Concentratorからのclient.pemの内容 >> + clientKey: | + << Logs-Concentratorからのclient-key.pemの内容 >> + ``` + 転送: + username: <> + password: <> + host: <> + hostName: <> + hostPort: '24224' + selfHostname: <> + sharedKey: <> + tlsVerifyHostname: false + clusterName: <<短いクラスタ識別子>> + logsDispatcher: + serviceMonitor: + enabled: false + logging-operator: + monitoring: + serviceMonitor: + enabled: false + lagoonLogs: + enabled: true + rabbitMQHost: lagoon-core-broker.lagoon-core.svc.cluster.local + rabbitMQUser: lagoon + rabbitMQPassword: <> + excludeNamespaces: {} + ``` + +2. `lagoon-logging`をインストールします: + + ```bash title="Install lagoon-logging" + helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com + + helm upgrade --install --create-namespace \ + --namespace lagoon-logging \ + -f lagoon-logging-values.yaml \ + lagoon-logging lagoon/lagoon-logging + ``` + +## Logging NGINX In gressコントローラ + +`lagoon-logging`内の`ingress-nginx`からログが必要な場合： + +1. ingressコントローラは`ingress-nginx`という名前空間にインストールされていなければなりません +2. このファイルの内容を`ingress-nginx`に追加します： + + ```yaml title="ingress-nginx log-format-upstream" + controller: + config: + log-format-upstream: >- + { + "time": "$time_iso8601", + "remote_addr": "$remote_addr", + "x-forwarded-for": "$http_x_forwarded_for", + "true-client-ip": "$http_true_client_ip", + "req_id": "$req_id", + "remote_user": "$remote_user", + "bytes_sent": $bytes_sent, + "request_time": $request_time, + "status": "$status", + "host": "$host", + "request_proto": "$server_protocol", + "request_uri": "$uri", + "request_query": "$args", + "request_length": $request_length, + "request_time": $request_time, + "request_method": "$request_method", + "http_referer": "$http_referer", + "http_user_agent": "$http_user_agent", + "namespace": "$namespace", + "ingress_name": "$ingress_name", + "service_name": "$service_name", "service_port": "$service_port" + } + ``` + +3. あなたのログが流れ始めるはずです！ \ No newline at end of file diff --git a/docs/installing-lagoon/logs-concentrator.ja.md b/docs/installing-lagoon/logs-concentrator.ja.md new file mode 100644 index 0000000000..3ee9dc7fe5 --- /dev/null +++ b/docs/installing-lagoon/logs-concentrator.ja.md @@ -0,0 +1,36 @@ +# ログ集約器 + +ログ集約器は、Lagoonクラスタから送信されるログを収集し、それらに追加のメタデータを付加してからElasticsearchに挿入します。 + +1. ReadMeに従って証明書を作成します：[https://github.com/uselagoon/lagoon-charts/tree/main/charts/lagoon-logs-concentrator](https://github.com/uselagoon/lagoon-charts/tree/main/charts/lagoon-logs-concentrator) +2. `logs-concentrator-values.yml`を作成します： + + ```yaml title="logs-concentrator-values.yml" + tls: + caCert: | + <> + serverCert: | + <> + elasticsearchHost: elasticsearch-opendistro-es-client-service.elasticsearch.svc.cluster.local + elasticsearchAdminPassword: <> + forwardSharedKey: <<ランダムな32文字のパスワード>> + users: + - username: <> + password: <> + service: + type: LoadBalancer + serviceMonitor: + enabled: false + ``` + +3. ログ集約器をインストールします： + + ```bash title="Install logs-concentrator" + helm upgrade --install --create-namespace ``` + --namespace lagoon-logs-concentrator \ + -f logs-concentrator-values.yaml \ + lagoon-logs-concentrator lagoon/lagoon-logs-concentrator + ``` +このテキストはプログラミングコードであり、特定のプログラミング言語に依存しているため、翻訳は適用されません。 \ No newline at end of file diff --git a/docs/installing-lagoon/opendistro.ja.md b/docs/installing-lagoon/opendistro.ja.md new file mode 100644 index 0000000000..626b1ff6cc --- /dev/null +++ b/docs/installing-lagoon/opendistro.ja.md @@ -0,0 +1,184 @@ +# OpenDistro + +OpenDistroクラスタをインストールするには、Lagoonがそれと安全に通信できるようにTLSとシークレットを設定する必要があります。いくつかのJSONファイルを作成する必要があります - これらを、インストールプロセス全体を通じて作成してきた値のファイルと同じディレクトリに置いてください。 + +OpenDistro Helmをインストールします。詳細は[https://opendistro.github.io/for-elasticsearch-docs/docs/install/helm/](https://opendistro.github.io/for-elasticsearch-docs/docs/install/helm/)を参照してください。 + +## キーと証明書の作成 + +1. 証明書の生成 + + !!! 注意 "注意:" + _CFSSLはCloudFlareのPKI/TLSスイスアーミーナイフです。これはコマンドラインツールであり、TLS証明書の署名、検証、バンドル化を行うHTTP APIサーバです。ビルドにはGo 1.12+が必要です。_ + + 1. CFSSLをインストールします: [https://github.com/cloudflare/cfssl](https://github.com/cloudflare/cfssl) + 2. CAを生成します。次のファイルが必要です: + + ```json title="ca-csr.json" + { + "CN": "ca.elasticsearch.svc.cluster.local", + "hosts": [ + "ca.elasticsearch.svc.cluster.local" + ], + "key": { + "algo": "ecdsa", + "size": 256 + }, + "ca": { + "expiry": "87600h" + } + } + ``` + +1. 次の2つのコマンドを実行します : + + ```bash title="証明書の生成" + cfssl gencert -initca ca-csr.json | cfssljson -bare ca - + rm ca.csr + ``` + + `ca-key.pem`と`ca.pem`が生成されます。これがあなたのCAキーと自己署名証明書です。 + +3. 次に、ノードのピーリング証明書を生成します。次の2つのファイルが必要です： + + ```json title="ca-config.json" + { + "signing": { + "default": { + "expiry": "87600h" + }, + "profiles": { + "peer": { + "expiry": "87600h", + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ] + }, + "client": { + "expiry": "87600h", + "usages": [ + "signing", + "key encipherment", + "client auth" + ] + } + } + } + } + ``` + + ```json title="node.json" + { + "hosts": [ + "node.elasticsearch.svc.cluster.local" + ], + "CN": "node.elasticsearch.svc.cluster.local", + "key": { + "algo": "ecdsa", + "size": 256 + } + } + ``` + +4. 次の2つのコマンドを実行します： + + ```bash title="証明書キーの生成" + cfssl gencert -ca=ca.pem -ca -キー=ca-key.pem -config=ca-config.json -profile=peer node.json | cfssljson -bare node + rm node.csr + ``` + + `node.pem`と`node-key.pem`が得られます。これがESクラスターのノードで使用されるピア証明書になります。 + +5. 次に、以下のコマンドでキーをJavaがサポートする形式に変換します： + + ```bash title="キー形式の変換" + openssl pkey -in node-key.pem -out node-key.pkcs8 + ``` + +6. 次に、管理者証明書を生成します。次のファイルが必要です： + + ```json title="admin.json" + { + "CN": "admin.elasticsearch.svc.cluster.local", + "key": { + "algo": "ecdsa", + "size": 256 + } + } + ``` + +7. 次の2つのコマンドを実行します： + + ```bash title="管理者証明書キーの生成" + cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client admin.json | cfssljson -bare admin + rm admin.csr + ``` + + `admin.pem`と`admin-key.pem`が得られます。これがopendistro-securityプラグインで管理コマンドを実行するために使用される証明書になります。 + +8. 次に、以下のコマンドでキーをJavaがサポートする形式に変換します： + + ```bash title="キー形式の変換" + openssl pkey -in admin-key.pem -out admin -key.pkcs8 + ``` + +## OpenDistroのインストール + +キーと証明書を手に入れたので、インストールを続けることができます。 + +1. ハッシュ化されたパスワードを生成します。 + 1. `elasticsearch-secrets-values.yaml`には2つのハッシュ化されたパスワードが必要です。以下のコマンドでそれらを作成します（2回実行し、ランダムなパスワードを入力し、プレーンテキストとハッシュ化されたパスワードの両方を保存します）。 + + ```bash title="ハッシュ化されたパスワードを生成" + docker run --rm -it docker.io/amazon/opendistro-for-elasticsearch:1.12.0 sh -c "chmod +x /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh; /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh" + ``` + +1. secretsを作成します: + + 1. `elasticsearch-secrets-values.yaml`を作成する必要があります。このgistを参考にしてください：[https://gist.github.com/Schnitzel/43f483dfe0b23ca0dddd939b12bb4b0b](https://gist.github.com/Schnitzel/43f483dfe0b23ca0dddd939b12bb4b0b) + +2. 以下のコマンドでsecretsをインストールします: + + ```bash title="secretsのインストール" + helm repo add incubator https://charts.helm.sh/incubator` + helm upgrade --namespace elasticsearch --create-namespace --install elasticsearch-secrets incubator/raw --values elasticsearch-secrets-values.yaml ` + ``` + +3. あなたは必要とするでしょう `elasticsearch-values.yaml`を作成します。例としてこのgistを参照してください：（すべての<\>に値を埋めてください）[https://gist.github.com/Schnitzel/1e386654b6abf75bf4d66a544db4aa6a](https://gist.github.com/Schnitzel/1e386654b6abf75bf4d66a544db4aa6a) +4. Elasticsearchをインストール： + + ```bash title="Elasticsearchをインストール" + helm upgrade --namespace elasticsearch --create-namespace --install elasticsearch opendistro-es-X.Y.Z.tgz --values elasticsearch-values.yaml + ``` + +5. Elasticsearch内のセキュリティを次のように設定： + + ```bash title="セキュリティを設定" + kubectl exec -n elasticsearch -it elasticsearch-opendistro-es-master-0 -- bash + chmod +x /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh + /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -nhnv -cacert /usr/share/elasticsearch/config/admin-root-ca.pem -cert /usr/share/elasticsearch/config/admin-crt.pem -key /usr/share/elasticsearch/config/admin-key.pem -cd /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/ + ``` + +6. `lagoon-core-values.yaml`を次のように更新： + + ```yaml title="lagoon-core-values.yaml" + elasticsearchURL: http://elasticsearch-opendistro-es -client-service.elasticsearch.svc.cluster.local:9200 + kibanaURL: https://<> + logsDBAdminPassword: "<>" + ``` + +7. ロールアウトLagoon Core： + + ```bash title="Rollout Lagoon Core" + helm upgrade --install --create-namespace --namespace lagoon-core -f values.yaml lagoon-core lagoon/lagoon-core + ``` + +9. すべてのLagoonグループをOpendistro Elasticsearchと同期させる + + ```bash title="Sync groups" + kubectl -n lagoon-core exec -it deploy/lagoon-core-api -- sh + yarn run sync:opendistro-security + ``` \ No newline at end of file diff --git a/docs/installing-lagoon/querying-graphql.ja.md b/docs/installing-lagoon/querying-graphql.ja.md new file mode 100644 index 0000000000..cbf9fad4bb --- /dev/null +++ b/docs/installing-lagoon/querying-graphql.ja.md @@ -0,0 +1,59 @@ +# GraphQLでのクエリ + +1. GraphQLクエリの送受信にはアプリが必要です。GraphiQLを推奨します。 + + 1. Homebrewを使用している場合、`brew install --cask graphiql`でインストールできます。 + +2. Lagoon CoreにKubernetesクラスタについて通知する必要があります。GraphQLエンドポイントは次のとおりです：`https://<YOUR-API-URL>/graphql` +3. **HTTPヘッダーを編集**に移動し、**ヘッダーを追加**します。 + + 1. ヘッダー名：`Authorization` + 2. 値：`Bearer YOUR-TOKEN-HERE` + 3. ホームディレクトリにLagoon CLIが`.lagoon.yml`ファイルを作成しています。そのファイルからトークンをコピーして、ここでの値に使用します。 + 4. 保存。 + +4. これでクエリを実行する準備が整いました。次のテストクエリを実行して、すべてが正しく動作していることを確認します： + + ```graph title="Get all projects" + query allProjects {allProjects {name } } + ``` + +5. これにより、次のレスポンスが得られるはずです： + + ```graph title="API Response" + { + "data": { + "allProjects": [] + } + } + ``` + + [詳細については、ドキュメンテーションのGraphQLについてのページをご覧ください。](../interacting/graphql.md) + +6. 正しいレスポンスが得られたら、変異を追加する必要があります。 + + 1. 次のクエリを実行します： + + ```graphql title="Add mutation" + mutation addKubernetes { + ```bash + addKubernetes(input: + { + name: "<TARGET-NAME-FROM-REMOTE-VALUES.yml>", + consoleUrl: "<URL-OF-K8S-CLUSTER>", + token: "xxxxxx” + routerPattern: "${environment}.${project}.lagoon.example.com" + }){id} + } + ``` + + 1. `name`: `lagoon-remote-values.yml`から取得 + 2. `consoleUrl`: KubernetesクラスタのAPIエンドポイント。`values.yml`から取得 + 3. `token`: `ssh-core`サービスアカウント用のトークンを取得 + + ```bash title="トークンを取得" + kubectl -n lagoon get secret/lagoon-remote-ssh-core-token -o json | jq -r '.data.token | @base64d' + ``` + +!!! 情報 + GraphQLの認証トークンの有効期限は非常に短いため、新しいトークンを生成する必要があるかもしれません。`lagoon login`を実行し、新しいトークンを取得するために`.lagoon.yml`ファイルをcatコマンドで表示し、HTTPヘッダーの古いトークンを新しいものに置き換えてください。 \ No newline at end of file diff --git a/docs/installing-lagoon/requirements.ja.md b/docs/installing-lagoon/requirements.ja.md new file mode 100644 index 0000000000..962e203604 --- /dev/null +++ b/docs/installing-lagoon/requirements.ja.md @@ -0,0 +1,47 @@ +# 既存のKubernetesクラスターへのLagoonのインストール + +## 必要条件 + +* Kubernetes 1.23+（Kubernetes 1.21もサポートされていますが、1.23を推奨します） +* [Helm](https://helm.sh)、[Helm Charts](https://helm.sh/docs/topics/charts/#helm)、[kubectl](https://kubernetes.io/docs/tasks/tools/)に精通していること。 +* Ingressコントローラー、我々は[ingress-nginx](https://github.com/kubernetes/ingress-nginx)を推奨し、ingress-nginx名前空間にインストールされていること +* Cert manager（TLS用） - letsencryptの使用を強く推奨します +* StorageClasses（デフォルトとしてRWO、永続タイプ用にRWM） + +!!! 注意 + これは多くのステップが必要であることを認識しており、今後すぐに行う予定のロードマップには、このプロセスのステップ数を減らすことが含まれています。 + +## 特定の要件（2023年1月現在） + +### Kubernetes + +LagoonはKubernetesバージョン1.21以降をサポートしています。私たちは積極的にKubernetes 1.24に対してテストと開発を行っており、定期的に1.21、1.22、1.25に対してもテストを行っています。 + +次の大規模な破壊的変更は[Kubernetes 1.25](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-25)にあり、我々はこれらを事前に把握する努力をしますが、これは最低サポートバージョンの上昇を必要とするでしょう。 Lagoonのバージョン。 + +### ingress-nginx + +Lagoonは現在、単一の `ingress-nginx` コントローラーのみに対応して設定されているため、過去には `IngressClass` の定義は必要ありませんでした。 + +最近の `ingress-nginx` コントローラー（バージョン4以降、Kubernetes 1.22が必要）を使用するには、以下の設定を使用する必要があります。[`ingress-nginx` のドキュメント](https://kubernetes.github.io/ingress-nginx/#what-is-an-ingressclass-and-why-is-it-important-for-users-of-ingress-nginx-controller-now)に従ってください。 + +* `nginx-ingress` はデフォルトのコントローラーとして設定する必要があります - Helmの値で `.controller.ingressClassResource.default: true` を設定します +* `nginx-ingress` は `IngressClass` が設定されていないIngressを監視するように設定する必要があります - Helmの値で `.controller.watchIngressWithoutClass: true` を設定します + +これにより、コントローラーは新しいIngressを `IngressClass` として自身で作成し、`IngressClass` が設定されていない既存のIngressを処理するように設定されます。 + +他の設定も可能かもしれませんが、テストは行われていません。 + +### Harbor + +現在、Harborのバージョン2.1と2.2以降がサポートされています。2.2でロボットアカウントの取得方法が変更され、Lagoonのリモートコントローラーは Translation request timed out. Kubernetesプラットフォームで十分です。これは、可能な限り動的なプロビジョニングと拡張性があるように設定する必要があります。 + +また、Lagoonでは、永続的なポッドレプリカ（ノード間）をサポートするために、'bulk'と呼ばれる`StorageClass`が利用可能であることが必要です。この`StorageClass`は`ReadWriteMany`（RWX）アクセスモードをサポートしており、可能な限り動的なプロビジョニングと拡張性があるように設定する必要があります。詳細はhttps://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes を参照し、互換性のあるドライバの完全なリストについては[production drivers list](https://kubernetes-csi.github.io/docs/drivers.html)を参照してください。 + +現在、私たちは（現在は廃止されている）[EFS Provisioner](./efs-provisioner.md)の指示だけを含めています。本番の[EFS CSI driver](https://github.com/kubernetes-sigs/aws-efs-csi-driver)は、120以上のPVCをプロビジョニングする際に問題があります。私たちはアップストリームでの可能な修正を[ここ](https://github.com/kubernetes-sigs/aws-efs-csi-driver/pull/761)と[ここ](https://github.com/kubernetes-sigs/aws-efs-csi-driver/pull/732)で待っています - しかし、他のほとんどのプロバイダのCSIドライバも動作するはずで、NFS互換のサーバとプロビジョナーを備えた設定も同様です。 + +## どれくらい Kubernetesの経験/知識は必要ですか？ + +Lagoonは、非常に高度なKubernetesとクラウドネイティブの概念を使用しており、Lagoonのインストールや設定に完全な熟知が必要なわけではありませんが、問題の診断や貢献は、十分な知識がなければ難しくなるかもしれません。 + +指標として、[Certified Kubernetes Administrator](https://www.cncf.io/certification/cka/)のカリキュラムに対する快適さを最低限として提案することができます。 \ No newline at end of file diff --git a/docs/installing-lagoon/update-lagoon.ja.md b/docs/installing-lagoon/update-lagoon.ja.md new file mode 100644 index 0000000000..0797314adf --- /dev/null +++ b/docs/installing-lagoon/update-lagoon.ja.md @@ -0,0 +1,66 @@ +# 更新 + +1. Helmを使用して最新のチャートをダウンロードします。 + + ```bash title="最新のチャートをダウンロード" + helm repo update + ``` + +2. `helm diff`を使って変更点を確認します（[https://github.com/databus23/helm-diff](https://github.com/databus23/helm-diff)）。 + + ```bash title="変更点を確認" + helm diff upgrade --install --create-namespace --namespace lagoon-core \ + -f values.yml lagoon-core lagoon/lagoon-core + ``` + +3. 任意のHelm操作前に、Lagoonデータベースの[バックアップ](#database-backups)を取ります。 + また、データベース移行スクリプトがinitContainersで実行されるのを支援するために、APIを単一のポッドにスケーリングすることもお勧めします。 + +4. Helmを使用してアップグレードを実行します。 + + ```bash title="アップグレードを実行" + helm upgrade --install --create-namespace --namespace lagoon-core \ + -f values.yaml lagoon-core lagoon/lagoon-core + ``` + +5. （Lagoon v2.11.0以降、このステップは不要になりました） + Lagoon Coreをアップグレードする場合、アップグレード後の移行を行うために`rerun_initdb.sh`スクリプトを実行することを確認してください。 + + ```bash title="スクリプトを実行" + kubectl --namespace lagoon-core exec -it lagoon-core-api-db-0 -- \ + sh -c /rerun_initdb.sh + ``` + +6. APIポッドを元の数に戻してスケールアップします。 レベル。 + +7. Lagoon Coreをアップグレードし、OpenSearchのグループ/ユーザー同期を有効にしている場合、OpenSearchのグループを更新するために`sync:opendistro-security`スクリプトを実行する必要がある場合があります。このコマンドは、全体のグループ構造の同期に時間がかかる場合、一度に1つのグループを同期するために`GROUP_REGEX=<group-to-sync`でプレフィックスを付けることもできます。 + + ```bash title="スクリプトの実行" + kubectl --namespace lagoon-core exec -it deploy/lagoon-core-api -- \ + sh -c yarn sync:opendistro-security + ``` + +追加のアップグレードについては、[https://github.com/uselagoon/lagoon/releases](https://github.com/uselagoon/lagoon/releases)をご覧ください。 + +## データベースのバックアップ + +Lagoon Coreをアップグレードする前にデータベースをバックアップしたい場合があります。以下の手順でバックアップを作成し、必要に応じてそれらを使用して復元することができます。後でそれらを削除することもできます。 + +### API DB + +```bash title="API DBのバックアップ" +kubectl --namespace lagoon-core exec -it lagoon-core-api-db-0 -- \ + sh -c 'mysqldump --max-allowed-packet=500M --events \ + --routines --quick --add-locks --no-autocommit \ + --single-transaction infrastructure | gzip -9 > \ + /var/lib/mysql/backup/$(date +%Y-%m-%d_%H%M%S).infrastructure.sql.gz' +``` + ### Keycloak DB + +```bash title="Keycloak DBのバックアップ" +kubectl --namespace lagoon-core exec -it lagoon-core-keycloak-db-0 -- \ + sh -c 'mysqldump --max-allowed-packet=500M --events \ + --routines --quick --add-locks --no-autocommit \ + --single-transaction keycloak | gzip -9 > \ + /var/lib/mysql/backup/$(date +%Y-%m-%d_%H%M%S).keycloak.sql.gz' +``` diff --git a/docs/interacting/graphql-queries.ja.md b/docs/interacting/graphql-queries.ja.md new file mode 100644 index 0000000000..c626c26d57 --- /dev/null +++ b/docs/interacting/graphql-queries.ja.md @@ -0,0 +1,553 @@ +# GraphQL API + +## GraphQLクエリの実行 + +Lagoonでの直接的なAPIの相互作用は、[GraphQL](graphql-queries.md)を経由して行われます。 + +APIとの認証を行うためには、私たちが管理者としてGraphQL APIを使用できるようにするJWT（JSON Web Token）が必要です。このトークンを生成するには、Kubernetes UI経由、またはkubectlを使用して`storage-calculator`ポッドのターミナルを開き、次のコマンドを実行します： + +```bash title="JWTトークンの生成" +./create_jwt.py +``` + +これによりJWTトークンである長い文字列が返されます。これはクエリを送信するために必要となるので、メモしておいてください。 + +また、APIエンドポイントのURLも必要です。これはKubernetes UIの"Ingresses"の下、またはコマンドラインのkubectlを経由して見つけることができます。このエンドポイントURLも必要になるので、メモしておいてください。 + +GraphQLクエリを作成し送信するには、自動補完機能などを備えたデスクトップGraphQLクライアントである[GraphiQL.app](https://github.com/skevy/graphiql-app)をお勧めします。次の手順に進むには、このアプリをインストールし起動します。 + +"GraphQL Endpoint"の下に`/graphql`を末尾に付けたAPIエンドポイントURLを入力します。次に"Edit HTTP Headers"をクリックし、新しいヘッダーを追加します： + +* "ヘッダー名"：`Authorization` +* "ヘッダー値"：`Bearer [JWTトークン]` (確認してください JWTトークンにスペースがないこと(スペースが含まれていると動作しません) + +ESCキーを押してHTTPヘッダーオーバーレイを閉じ、最初のGraphQLリクエストを送信する準備ができました！ + +![GraphiQLでHTTPヘッダーを編集する](../images/graphiql-2020-01-29-18-05-54.png) + +これを左パネルに入力します + +```graphql title="クエリの実行" +query allProjects{ + allProjects { + name + } +} +``` + +![GraphiQLでクエリを実行する](../images/graphiql-2020-01-29-20-10-32.png) + +そして、▶️ボタンを押すか(またはCTRL+ENTERを押す)。 + +すべてがうまくいけば、最初のGraphQLレスポンスがすぐに右のペインに表示されるはずです。 + +## 最初のプロジェクトの作成 + +Lagoonにデプロイするための最初のプロジェクトを作成しましょう！これには、[`create-project.gql`](../interacting/create-project.gql)のGraphQLクエリテンプレートからクエリを使用します。 + +各クエリ(`mutation {`で始まるブロック)について、TODOコメントでマークされた空のフィールドをすべて埋めて、GraphiQL.appでクエリを実行します。これにより、以下の2つのオブジェクトがそれぞれ1つずつ作成されます： + +1. `kubernetes` : LagoonがデプロイするべきKubernetes(またはOpenshift)クラスタ。Lagoonは自身のKubernetesクラスタにだけでなく、任意のKubernetesにもデプロイすることが可能です。 世界中のどこでもクラスタリングします。 +2. `project` : デプロイされるLagoonプロジェクトで、ルートにコミットされた `.lagoon.yml` 設定ファイルを持つGitリポジトリです。 + +## プロジェクトへのアクセス許可 + +Lagoonでは、各開発者は自分のSSHキーで認証します。これにより、以下へのアクセスが決まります： + +1. 自分がアクセス権を持つプロジェクトを見て編集できるLagoon API。 +2. 自分がアクセス権を持つプロジェクトで実行中のコンテナへのリモートシェルアクセス。 +3. リクエストログ、コンテナログ、Lagoonログなどを見つけることができるLagoonのログシステム。 + +プロジェクトへのアクセスを許可するためには、まずAPIに新しいグループを追加する必要があります： + +```graphql title="APIにグループを追加" +mutation { + addGroup ( + input: { + # TODO: 新しいグループの名前を入力してください。 + name: "" + } + ) { + id + name + } +} +``` + +次に、APIに新しいユーザーを追加する必要があります： + +```graphql title="APIに新規ユーザーを追加" +mutation { + addUser( + input: { + email: "michael.schmid@example.com" + firstName: "Michael" + lastName: "Schmid" + comment: "CTO" + } + ) { + # TODO: 返されたユーザーIDをメモしておいてください。 + id + } +} +``` + +それから、その APIにユーザーを追加: + +```graphql title="APIにSSH公開鍵を追加する" +mutation { + addSshKey( + input: { + # TODO: nameフィールドを記入して下さい。 + # これはSSHキーの非一意な識別子です。 + name: "" + # TODO: keyValueフィールドを記入して下さい。 + # これは実際のSSH公開鍵です（最初のタイプと最後のコメントを除いて、例 `AAAAB3NzaC1yc2EAAAADAQ...3QjzIOtdQERGZuMsi0p`）。 + keyValue: "" + # TODO: keyTypeフィールドを記入して下さい。 + # 有効な値は、SSH_RSA、SSH_ED25519、ECDSA_SHA2_NISTP256/384/521のいずれかです。 + keyType: SSH_RSA + user: { + # TODO: userIdフィールドを記入して下さい。 + # これはaddUserクエリから取得したユーザーIDです。 + id:"0", + email:"michael.schmid@example.com" + } + } + ) { + id + } +} +``` + +キーを追加した後、ユーザーをグループに追加する必要があります: + +```graphql title="ユーザーをグループに追加する" +mutation { + addUserToGroup ( + input: { + user: { + #TODO: ユーザーのメールアドレスを入力してください。 + email: "" + } + group: { + #TODO: ユーザーを追加したいグループの名前を入力してください。 + name: "" + } + #TODO: ユーザーの役割を入力してください。 . + 役割：オーナー + + } + ) { + id + name + } +} +``` + +これらのクエリの一部または全部を実行した後、ユーザーはSSH経由でトークンを作成したり、コンテナにアクセスしたりする権限が付与されます。 + +## プロジェクトに通知を追加する + +デプロイメント中に何が起こっているのかを知りたい場合、プロジェクトに通知を設定することをお勧めします。以下の情報を提供します： + +* プッシュ通知 +* ビルド開始情報 +* ビルド成功または失敗メッセージ +* その他多数！ + +通知は、必要な情報の点でかなり異なる可能性があるため、各通知タイプには独自の変異があります。 + +ユーザーと同様に、まず通知を追加します： + +```graphql title="通知を追加する" +mutation { + addNotificationSlack( + input: { + # TODO: 名前フィールドを記入してください。 + # これは通知のための自身の識別子です。 + name: "" + # TODO: チャンネルフィールドを記入してください。 + # これはメッセージが送信されるチャンネルです。 + channel: "" + # TODO: ウェブフックフィールドを記入してください。 + # これはメッセージが送信されるべきウェブフックのURLで、通常はチャットシステムから提供されます。 + webhook: "" + } + ) { + id + } +} +``` + +通知が作成された後、 これで、私たちのプロジェクトに割り当てることができます： + +```graphql title="プロジェクトに通知を割り当てる" +mutation { + addNotificationToProject( + input: { + notificationType: SLACK + # TODO: プロジェクトフィールドを記入してください。 + # これはプロジェクトの名前です。 + project: "" + # TODO: 通知フィールドを記入してください。 + # これは通知の名前です。 + notificationName: "" + # TODO: オプション + # 興味のある通知クラスの種類は、デフォルトでDEPLOYMENTになります + contentType: DEPLOYMENT/PROBLEM + # TODO: オプション + # contentType PROBLEMに関連して、我々が通知を受けたい問題の種類の閾値を設定することができます + notificationSeverityThreshold: "NONE/UNKNOWN/NEGLIGIBLE/LOW/MEDIUM/HIGH/CRITICAL + } + ) { + id + } +} +``` + +これで、デプロイメントごとに、定義したチャンネルでメッセージを受け取ることができます。 + +## GraphQLクエリの例 + +### 新しいKubernetesターゲットの追加 + +!!! 注意 + Lagoonでは、`addKubernetes`と`addOpenshift`のどちらもKubernetesとOpenShiftのターゲットの両方に使用することができ、どちらも互換性があります。 + +Lagoonがデプロイするべきクラスタ。 + +```graphql title="Kubernetesターゲットの追加" +mutation { + addKubernetes( + 入力： +{ + # TODO: 名前フィールドを記入してください。 + # これはクラスタの一意の識別子です。 + 名前： "" + # TODO: consoleUrlフィールドを記入してください。 + # これはKubernetesクラスタのURLです + consoleUrl: "" + # TODO: トークンフィールドを記入してください。 + # これは、このクラスタで作成された`lagoon`サービスアカウントのトークンです（これは、Lagoonのインストール時にも使用したのと同じトークンです）。 + トークン： "" +} +){ + 名前 + id +} +``` + +### プロジェクトにグループを追加する + +このクエリはプロジェクトにグループを追加します。そのグループのユーザーはプロジェクトにアクセスできます。彼らはそのグループでの役割に基づいて変更を加えることができます。 + +```graphql タイトル="プロジェクトにグループを追加する" +mutation { + addGroupsToProject ( + 入力： { + プロジェクト： { + #TODO: プロジェクトの名前を入力してください。 + 名前： "" + } + グループ： { + #TODO: プロジェクトに追加されるグループの名前を入力してください。 + 名前： "" + } + } + ) { + id + } +} +``` + +### 新しいプロジェクトを追加する + +このクエリは、新しいLagoonプロジェクトをデプロイするために追加します。これは、ルートにコミットされた`.lagoon.yml`設定ファイルを持つGitリポジトリです。 + +もし` `privateKey` フィールドがある場合、プロジェクトの新しいSSHキーが自動的に生成されます。 + +別のプロジェクトからキーを再利用したい場合は、`addProject` ミューテーションでキーを提供する必要があります。 + +```graphql title="新しいプロジェクトを追加" +mutation { + addProject( + input: { + # TODO: 名前フィールドを入力してください。 + # これはプロジェクト名です。 + name: "" + # TODO: プライベートキーフィールドを入力してください（改行は '\n' で置き換えてください）。 + # これはプロジェクトのプライベートキーで、Gitのコードにアクセスするために使用されます。 + privateKey: "" + # TODO: Kubernetesフィールドを入力してください。 + # これはプロジェクトに割り当てるKubernetesまたはOpenShiftのIDです。 + kubernetes: 0 + # TODO: 名前フィールドを入力してください。 + # これはプロジェクト名です。 + gitUrl: "" + # TODO: デプロイするブランチを入力してください。 + branches: "" + # TODO: 本番環境を定義してください。 + productionEnvironment: "" + } + ) { + name + kubernetes { + name + id + } + gitUrl + branches + pullrequests + } +} +``` + +### プロジェクトとグループのリスト + +これは、私たちのLagoon内に存在するすべてのプロジェクト、クラスター、グループの概要を見るための良いクエリです。 + +```graphql title=" すべてのプロジェクト、クラスター、およびグループの概要を取得" +query { + allProjects { + name + gitUrl + } + allKubernetes { + name + id + } + allGroups{ + id + name + members { + # これはこのグループのユーザーを表示します。 + user { + id + firstName + lastName + } + role + } + groups { + id + name + } + } +} + +### 単一のプロジェクト + +単一のプロジェクトを詳しく見る場合、このクエリが非常に有用であることが証明されています。 + +```graphql title="プロジェクトを詳しく見る" +query { + projectByName( + # TODO: プロジェクト名を入力してください。 + name: "" + ) { + id + branches + gitUrl + pullrequests + productionEnvironment + notifications(type: SLACK) { + ... on NotificationSlack { + name + channel + webhook + id + } + } + environments { + name + deployType + environmentType + } + kubernetes { + id + } + } +} + +### Git URLによるプロジェクトのクエリ + +プロジェクトの名前を覚えていないが、Git URLは知っている場合？もう探す必要はありません、そのためのGraphQLクエリがあります： + +```graphql title="Git URLによるプロジェクトのクエリ" +query { + projectByGitUrl(gitUrl: "git@server.com:org/repo ``` +.git") { + name + } +} +``` + +### オブジェクトの更新 + +Lagoon GraphQL APIは、オブジェクトを表示し、オブジェクトを作成するだけでなく、[パッチオブジェクト](https://blog.apollographql.com/designing-graphql-mutations-e09de826ed97)を使用して既存のオブジェクトを更新する能力もあります。 + +プロジェクト内でデプロイするブランチを更新します。 + +```graphql title="デプロイブランチの更新。" +mutation { + updateProject( + input: { id: 109, patch: { branches: "^(prod|stage|dev|update)$" } } + ) { + id + } +} +``` + +プロジェクト内の本番環境を更新します。 + +!!! 警告 + この変更をコンテナに反映させるには、再デプロイが必要です。 + +```graphql title="本番環境の更新" + mutation { + updateProject( + input: { id: 109, patch: { productionEnvironment: "main" } } + ) { + id + } +} +``` + +また、一度に複数の変更を組み合わせることもできます。 + +```graphql title="本番環境の更新とデプロイブランチの設定。" +mutation { + updateProject( + input: { + id: 109 + patch: { + productionEnvironment: "main" + branches: "^(prod|stage|dev|update)$" + } + } + ) { + id + } +} +``` + +### 環境の削除 + +Lagoon GraphQL APIを使用して、環境を削除することもできます。 環境。コマンドを実行するためには、プロジェクト名と環境名を知っている必要があります。 + +```graphql title="環境を削除する" +mutation { + deleteEnvironment( + input: { + # TODO: nameフィールドを記入してください。 + # これは環境名です。 + name:"" + # TODO: projectフィールドを記入してください。 + # これはプロジェクト名です。 + project:"" + execute:true + } + ) +} +``` + +### プロジェクトに割り当てられたグループとユーザーを確認する + +プロジェクトにどのグループとユーザーがアクセスできるか見たいですか？彼らの役割は何か知りたいですか？そのためのクエリがあります！下記のクエリを使用して、プロジェクトを検索し、そのプロジェクトに割り当てられたグループ、ユーザー、役割を表示できます。 + +```graphql title="プロジェクトに割り当てられたグループ、ユーザー、役割をクエリする" +query search{ + projectByName( + #TODO: プロジェクトの名前を入力してください。 + name: "" + ) { + id, + branches, + productionEnvironment, + pullrequests, + gitUrl, + kubernetes { + id + }, + groups{ + id + name + groups { + id + name + } + members { + role + user { + id + email + } + } + } + } +} +``` + +## 維持 プロジェクトメタデータ + +プロジェクトメタデータは、任意のキー/値の組み合わせで割り当てることができます。プロジェクトは関連付けられたメタデータによって問い合わせることができます。例えば、ソフトウェアの種類、バージョン番号、または後で問い合わせるための任意のカテゴリーによってプロジェクトを分類することができます。 + +### プロジェクトのメタデータを追加/更新する + +メタデータの更新はキー/値の組み合わせを期待しています。これは`UPSERT`として動作します。つまり、既にキーが存在する場合は値が更新され、存在しない場合は挿入されます。 + +プロジェクトに対して任意の数のk/vペアを保存することができます。 + +```graphql title="メタデータにキー/値のペアを追加する" +mutation { + updateProjectMetadata( + input: { id: 1, patch: { key: "type", value: "saas" } } + ) { + id + metadata + } +} +``` + +### メタデータによるプロジェクトのクエリ + +クエリは`key`のみ（例：特定のキーが存在するすべてのプロジェクトを返す）または`key`と`value`の両方（キーと値の両方が一致する必要があります）によって行うことができます。 + +`version`タグを持つすべてのプロジェクト： + +```graphql title="メタデータによるクエリ" +query projectsByMetadata { + projectsByMetadata(metadata: [{key: "version"] ) { + id + name + } +} +``` + +特にバージョン`8`の`version`タグを持つすべてのプロジェクト： + +```graphql title="メタデータによるクエリ" + metadataでプロジェクトを検索する +{ + metadataを使用してプロジェクトを検索する（metadata: [{key: "version", value: "8"]} ) { + id + name + } +} +``` + +### プロジェクトのメタデータを削除する + +メタデータはキーごとに削除できます。他のメタデータキー/値のペアは残ります。 + +```graphql title="メタデータを削除する" +mutation { + removeProjectMetadataByKey ( + input: { id: 1, key: "version" } + ) { + id + metadata + } +} +``` \ No newline at end of file diff --git a/docs/interacting/graphql.ja.md b/docs/interacting/graphql.ja.md new file mode 100644 index 0000000000..62ec9486ce --- /dev/null +++ b/docs/interacting/graphql.ja.md @@ -0,0 +1,100 @@ +# GraphQL + +## GraphQL APIへの接続 + +LagoonでのAPIとのやりとりはGraphQLを通じて行います。APIに認証するためには、JWT（JSON Web Token）が必要で、これによりSSH公開鍵を通じてAPIに対する認証が行われます。 + +このトークンを生成するには、`token`コマンドを使ってリモートシェルを使用します： + +```bash title="トークンの取得" +ssh -p [PORT] -t lagoon@[HOST] token +``` + +amazee.ioの例： + +```bash title="amazee.ioトークンの取得" +ssh -p 32222 -t lagoon@ssh.lagoon.amazeeio.cloud token +``` + +これにより長い文字列が返されます。これがJWTトークンです。 + +また、APIエンドポイントのURLも必要です。これについてはLagoonの管理者に尋ねてください。 +<!-- markdown-link-check-disable-next-line --> +amazee.ioではこれは[`https://api.lagoon.amazeeio.cloud/graphql`](https://api.lagoon.amazeeio.cloud/graphql)です。 + +さて、GraphQLクライアントが必要です！技術的にはこれは単なるHTTPですが、我々はGraphiQLを推奨します。これは素敵なUIを備えており、オートコンプリートでGraphQLのリクエストを書くことができます。ダウンロードしてインストールし、起動します。 \[[GraphiQL App](https://github.com/skevy/graphiql-app)\] + +APIエンドポイントURLを入力します。次に"Edit HTTP Headers"をクリックし、新しいヘッダーを追加します： + +* "Header name": `Authorization` +* "Header value": `Bearer [jwt token]` \( JWTトークンにスペースがないことを確認してください、それは動作しません\) + +![GraphiQL UIでHTTPヘッダーを編集する。](../images/graphiql-2020-01-29-18-05-54.png) + +HTTPヘッダーオーバーレイを閉じます（ESCキーを押します）。これであなたは初めてのGraphQLリクエストを行う準備が整いました！ + +左側のウィンドウに次の内容を入力します： + +```graphql title="すべてのプロジェクトを取得する" +query whatIsThere { + allProjects { + id + gitUrl + name + branches + pullrequests + productionEnvironment + environments { + name + environmentType + } + } +} +``` + +そして、▶️ボタンを押すか（またはCTRL+ENTERを押す）。 + +![GraphiQL UIでクエリを入力する。](../images/graphiql-2020-01-29-18-07-28.png) + +すべてうまくいけば、初めてのGraphQLレスポンスを見ることができるはずです。 + +## ミューテーション + +LagoonのGraphQL APIは、オブジェクトを表示し、オブジェクトを作成するだけでなく、既存のオブジェクトを更新する機能も持っています。LagoonのすべてのGraphQLはベストプラクティスを使用しています。 + +!!! 情報 + + GraphQLのミューテーションクエリは、データストアのデータを変更し、値を返します。これらは、データの挿入、更新、削除に使用できます。ミューテーションはスキーマの一部として定義されています。 + +プロジェクト内でデプロイするブランチを更新します： + +```graphql title="デプロイブランチを更新" +mutation editProjectBranches { + updateProject(input:{id:109, patch:{branches:"^(prod|stage|dev|update)$"}}) { + id + } +} +``` + +プロジェクト内の製品環境を更新します： + +!!! 警告 + すべての変更がコンテナに反映されるように、再デプロイが必要です。 + +```graphql title="製品環境の更新" +mutation editProjectProductionEnvironment { + updateProject(input:{id:109, patch:{productionEnvironment:"prod"}}) { + id + } +} +``` + +また、複数の変更を一つのクエリにまとめることもできます： + +```graphql title="複数の変更" +mutation editProjectProductionEnvironmentAndBranches { + updateProject(input:{id:109, patch:{productionEnvironment:"prod", branches:"^(prod|stage|dev|update)$"}}) { + id + } +} +``` diff --git a/docs/interacting/lagoon-ui.ja.md b/docs/interacting/lagoon-ui.ja.md new file mode 100644 index 0000000000..c4f2c2023f --- /dev/null +++ b/docs/interacting/lagoon-ui.ja.md @@ -0,0 +1,5 @@ +# ラグーンUI + +ラグーンUIはhttps://ui-lagoon-master.ch.amazee.ioでアクセスできます。アクセスに問題がある場合は、ラグーンの管理者に連絡してください。 + +UIを使用すると、プロジェクトや組織で様々なタスクを完了することができます。[ここで組織について詳しく学ぶ](../concepts-basics/building-blocks/organizations.md)や、[UIで組織で何ができるかについてはこちら](../interacting/organizations.md)をご覧ください。 \ No newline at end of file diff --git a/docs/interacting/organizations.ja.md b/docs/interacting/organizations.ja.md new file mode 100644 index 0000000000..18a6f599bb --- /dev/null +++ b/docs/interacting/organizations.ja.md @@ -0,0 +1,39 @@ +# UIで組織と共同作業する + +以下は、Lagoon UIでの組織関連のタスクを組織、プロジェクト、ユーザー、ロールと共に行うためのステップバイステップのガイドです。 + +## ログインして組織を探す + +<iframe src="https://scribehow.com/embed/Log_in_and_find_organizations__KkZhAk3gRkq2kfeaYHaI9g?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## プロジェクトへのアクセス権を持つ人を確認する + +<iframe src="https://scribehow.com/embed/View_who_has_access_to_a_project__hiB4C4bYRcuAdGsZ5b4LNw?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## ユーザーをロール付きのグループに追加する + +<iframe src="https://scribehow.com/embed/Add_User_to_Group_with_Role__xGA4Xl6sSYa7bz0SZb2hbQ?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## ユーザーをグループから削除する + +<iframe src="https://scribehow.com/embed/Remove_a_User_from_a_Group__mSXpvF91R-irT19f3gCI2A?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## ユーザーの役割を変更する + +<iframe src="https://scribehow.com/embed/Change_a_User_Role__zj1UqJ3iTDCTvRKg3zLIFg?removeLogo=true" width="100%" height ="640" allowfullscreen frameborder="0"></iframe> + +## プロジェクトにメール通知を追加する + +<iframe src="https://scribehow.com/embed/How_to_Add_an_Email_Notification_to_a_Project__H9SHY7QvTzG4ZOK9-Bsw1g?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## プロジェクトにグループを追加する + +<iframe src="https://scribehow.com/embed/Add_a_Group_to_a_Project__Mvk-LUmaSsyaW2t3ioLuWw?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## 組織のオーナー権限を持つユーザーを追加する + +<iframe src="https://scribehow.com/embed/Add_a_User_with_Organization_Owner_Privileges__i3EgoX4hSy-Da9OTL83XXQ?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> + +## 新しいプロジェクトを作成し、グループを追加し、プロダクション環境を作成する + +<iframe src="https://scribehow.com/embed/Create_a_new_Project_add_a_Group_and_create_a_Production_Environment__pn1gouJXTm-lPy-SaLuTcg?removeLogo=true" width="100%" height="640" allowfullscreen frameborder="0"></iframe> \ No newline at end of file diff --git a/docs/interacting/rbac.ja.md b/docs/interacting/rbac.ja.md new file mode 100644 index 0000000000..e599bcba7f --- /dev/null +++ b/docs/interacting/rbac.ja.md @@ -0,0 +1,638 @@ +Translation request timed out. 組織のオーナーの役割では、自組織内でのプロジェクト、グループ、通知の作成と削除が可能です。 + +彼らはユーザーをグループに追加し、そのグループ内のユーザーの役割を変更し、プロジェクトをグループに関連付けることができます。これにより、組織のオーナーは誰がアクセス権を持っているかを明確に把握し、ユーザーを迅速に追加・削除することができます。 + +組織のオーナーは現在、直接Slackやその他の通知を作成し、それらの通知をLagoon管理者の助けを借りずにプロジェクトに関連付ける能力も持っています。 + +!!! 警告 "注意" + デフォルトでは、この役割は組織のオーナーがプロジェクト内で環境を作成したり、デプロイをトリガーしたりすることを許可していません。彼らは自分自身を、その権限を付与する役割を持つグループに追加することができます。プロジェクトを作成するとき、組織のオーナーはプロジェクトのデフォルトグループのオーナーとして追加されることを選択できます。 + +#### 組織のビューア + +組織のビューワーは、自組織内のプロジェクト、グループとユーザーのアクセス、通知を表示するアクセス権を持っています。 + +### グループの役割 + +#### オーナー + +オーナーの役割は、グループとその関連プロジェクト内で全てを行うことができます。彼らはグループのユーザーを追加し、管理することができます。 この役割には注意が必要です、なぜならプロジェクトや本番環境を削除することができるからです！ + +#### メンテナ + +メンテナの役割は、プロジェクト自体や本番環境を削除することを除いて、グループとその関連プロジェクト内で何でもできます。彼らはグループのユーザーを追加し、管理することができます。 + +#### 開発者 + +開発者の役割は、開発環境へのSSHアクセスのみを持っています。この役割では、本番環境にアクセスしたり、更新したり、削除したりすることはできません。彼らは本番環境をソースとして同期タスクを実行することができますが、宛先としてはできません。グループのユーザーを管理することはできません。 + +!!! 警告 "重要" + この役割は、デプロイがGitのプッシュ経由でトリガーされるため、本番環境のデプロイを防ぎません！あなたはGitサーバーがこれらのユーザーが本番環境として定義されたブランチにプッシュするのを防ぐことを確認する必要があります。 + +#### レポーター + +レポーターの役割は、閲覧アクセスのみを持っています。彼らはSSH経由で環境にアクセスしたり、それらを変更したりすることはできません。彼らはキャッシュクリアタスクを実行することができます。この役割は主に、ステークホルダーがLagoon UIとログにアクセスできるようにするために使用されます。 + +#### ゲスト + +ゲストの役割は、上記のレポーターの役割と同等の権限を持っています。 + +以下はその表です。 彼らが持つ役割とアクセスをリストします： + +### ラグーン 1.0.0 RBAC 権限マトリックス + +=== "自分自身" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | addSshKey | ssh\_key | 追加 | userID | + | updateSshKey | ssh\_key | 更新 | userID | + | deleteSshKey | ssh\_key | 削除 | userID | + | getUserSshKeys | ssh\_key | ユーザー表示 | userID | + | updateUser | user | 更新 | userID | + | deleteUser | user | 削除 | userID | + +=== "ゲスト" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | getBackupsByEnvironmentId | deployment | 表示 | projectID | + | getEnvironmentsByProjectId | environment | 表示 | projectID | + | getEnvironmentServicesByEnvironmentId | environment | 表示 | projectID | + | getEnvVarsByEnvironmentId | env\_var | environment:development表示 | projectID | + | getEnvVarsByEnvironmentId | env\_var | environment:production表示 | projectID | + | getEnvVarsByProjectId | env\_var | project:表示 | projectID | + | addGroup | group | 追加 | | + | getOpenshiftByProjectId | openshift | 表示 | projectID | + | addProject | project | 追加 | | + | getProjectBy EnvironmentId | プロジェクト | ビュー | プロジェクトID | + | getProjectByGitUrl | プロジェクト | ビュー | プロジェクトID | + | getProjectByName | プロジェクト | ビュー | プロジェクトID | + | addRestore | リストア | 追加 | プロジェクトID | + | updateRestore | リストア | 更新 | プロジェクトID | + | taskDrushCacheClear | タスク | drushCacheClear:開発 | プロジェクトID | + | taskDrushCacheClear | タスク | drushCacheClear:プロダクション | プロジェクトID | + | taskDrushCron | タスク | drushCron:開発 | プロジェクトID | + | taskDrushCron | タスク | drushCron:プロダクション | プロジェクトID | + | getFilesByTaskId | タスク | ビュー | プロジェクトID | + | getTasksByEnvironmentId | タスク | ビュー | プロジェクトID | + | getTaskByRemoteId | タスク | ビュー | プロジェクトID | + | getTaskById | タスク | ビュー | プロジェクトID | + | addUser | ユーザー | 追加 | | + +=== "開発者" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | addBackup | バックアップ | 追加 | プロジェクトID | + | getBackupsByEnvironmentId | バックアップ | ビュー | プロジェクトID | + | addEnvVariable \(環境へ\) | env\_var | 環境:追加:開発 | プロジェクトID | + | deleteEnvVariable \(環境から\) | env\_var | 環境:削除:開発 | プロジェクトID | + | | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:development | projectID | + | addOrUpdateEnvironment | 環境 | addOrUpdate:development | projectID | + | updateEnvironment | 環境 | update:development | projectID | + | deleteEnvironment | 環境 | delete:development | projectID | + | addDeployment | 環境 | deploy:development | projectID | + | setEnvironmentServices | 環境 | update:development | projectID | + | deployEnvironmentLatest | 環境 | deploy:development | projectID | + | deployEnvironmentBranch | 環境 | deploy:development | projectID | + | deployEnvironmentPullrequest | 環境 | deploy:development | projectID | + | deployEnvironmentPromote | 環境 | deploy:development | projectID | + | userCanSshToEnvironment | 環境 | ssh:development | projectID | + | getNotificationsByProjectId | 通知 | view | projectID | + | addTask | タスク | add:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:production | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:development | | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:production | プロジェクトID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:development | 環境ID | + | taskDrushSqlSync | タスク | drushSqlSync:source:development | プロジェクトID | + | taskDrushSqlSync | タスク | drushSqlSync:source:production | プロジェクトID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:development | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:source:development | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:source:production | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:development | プロジェクトID | + | deleteTask | タスク | 削除 | プロジェクトID | + | updateTask | タスク | 更新 | プロジェクトID | + | uploadFilesForTask | タスク | 更新 | プロジェクトID | + | deleteFilesForTask | タスク | 削除 | プロジェクトID | + | getBackupsByEnvironmentId | デプロイメント | 表示 | プロジェクトID | + | getEnvironmentsByProjectId | 環境 | 表示 | プロジェクトID | + | getEnvironmentServicesBy<br />EnvironmentId | 環境 | 表示 | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | environment:view:development | プロジェクトID | + | getEnvVarsByEnvironmentId | env_var | 環境:view:production | projectID | + | getEnvVarsByProjectId | env_var | project:view | projectID | + | addGroup | group | add | | + | getOpenshiftByProjectId | openshift | view | projectID | + | addProject | project | add | | + | getProjectByEnvironmentId | project | view | projectID | + | getProjectByGitUrl | project | view | projectID | + | getProjectByName | project | view | projectID | + | addRestore | restore | add | projectID | + | updateRestore | restore | update | projectID | + | taskDrushCacheClear | task | drushCacheClear:development | projectID | + | taskDrushCacheClear | task | drushCacheClear:production | projectID | + | taskDrushCron | task | drushCron:development | projectID | + | taskDrushCron | task | drushCron:production | projectID | + | getFilesByTaskId | task | view | projectID | + | getTasksByEnvironmentId | task | view | projectID | + | getTaskByRemoteId | task | view | projectID | + | getTaskById | task | view | projectID | + | addUser | user | add | | + +=== "メンテナー" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | deleteBackup | バックアップ | 削除 | projectID | + | addEnvVariable \(プロジェクトに\) | env\_var | project:add | projectID | + | addEnvVariable \(環境に\) | env\_var | environment:add:production | projectID | + | deleteEnvVariable | env\_var | 削除 | projectID || + | deleteEnvVariable \(プロジェクトから\) | env\_var | project:削除 | projectID | + | deleteEnvVariable \(環境から\) | env\_var | environment:削除:production | projectID | + | getEnvVarsByProjectId | env\_var | project:viewValue | projectID | + | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:production | projectID | + | addOrUpdateEnvironment | environment | addOrUpdate:production | projectID | + | updateEnvironment | environment | 更新:production | projectID | + | addDeployment | environment | deploy:production | projectID | + | deleteDeployment | deployment | 削除 | projectID | + | updateDeployment | deployment | 更新 | projectID | + | setEnvironmentServices | environment | 更新:production | projectID | + | deployEnvironmentLatest | environment | deploy:production | projectID | + | deployEnvironmentBranch | environment | deploy:production | projectID | + | deployEnvironmentPull 要求 | 環境 | 展開:製品 | プロジェクトID | + | deployEnvironmentPromote | 環境 | 展開:製品 | プロジェクトID | + | userCanSshToEnvironment | 環境 | ssh:製品 | プロジェクトID | + | updateGroup | グループ | アップデート | グループID | + | deleteGroup | グループ | 削除 | グループID | + | addUserToGroup | グループ | ユーザー追加 | グループID | + | removeUserFromGroup | グループ | ユーザー削除 | グループID | + | addNotificationToProject | プロジェクト | 通知追加 | プロジェクトID | + | removeNotificationFromProject | プロジェクト | 通知削除 | プロジェクトID | + | updateProject | プロジェクト | アップデート | プロジェクトID | + | addGroupsToProject | プロジェクト | グループ追加 | プロジェクトID | + | removeGroupsFromProject | プロジェクト | グループ削除 | プロジェクトID | + | addTask | タスク | 追加:製品 | プロジェクトID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:製品 | 環境ID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:製品 | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:製品 | プロジェクトID | + | addBackup | バックアップ | 追加 | プロジェクトID | + | getBackupsByEnvironmentId | バックアップ | 表示 | プロジェクトID | + | addEnvVariable \(to Environment | env_var | environment:add:development | projectID | + | deleteEnvVariable（環境から） | env_var | environment:delete:development | projectID | + | getEnvVarsByEnvironmentId | env_var | environment:viewValue:development | projectID | + | addOrUpdateEnvironment | 環境 | addOrUpdate:development | projectID | + | updateEnvironment | 環境 | update:development | projectID | + | deleteEnvironment | 環境 | delete:development | projectID | + | addDeployment | 環境 | deploy:development | projectID | + | setEnvironmentServices | 環境 | update:development | projectID | + | deployEnvironmentLatest | 環境 | deploy:development | projectID | + | deployEnvironmentBranch | 環境 | deploy:development | projectID | + | deployEnvironmentPullrequest | 環境 | deploy:development | projectID | + | deployEnvironmentPromote | 環境 | deploy:development | projectID | + | getNotificationsByProjectId | 通知 | view | projectID | + | addTask | タスク | add:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:development | projectID | + | taskDrushArchiveDump | タスク | drush ArchiveDump:production | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:development | プロジェクトID | + | taskDrushSqlDump | タスク | drushSqlDump:production | プロジェクトID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:development | 環境ID | + | taskDrushSqlSync | タスク | drushSqlSync:source:development | プロジェクトID | + | taskDrushSqlSync | タスク | drushSqlSync:source:production | プロジェクトID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:development | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:source:development | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:source:production | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:development | プロジェクトID | + | deleteTask | タスク | 削除 | プロジェクトID | + | updateTask | タスク | 更新 | プロジェクトID | + | uploadFilesForTask | タスク | 更新 | プロジェクトID | + | deleteFilesForTask | タスク | 削除 | プロジェクトID | + | getBackupsByEnvironmentId | デプロイメント | 表示 | プロジェクトID | + | getEnvironmentsByProjectId | 環境 | 表示 | プロジェクトID | + | getEnvironmentServicesBy<br />EnvironmentId | 環境 | 表示 | プロジェクトID | + | getEnvVarsByEnvironment Id | env\_var | 環境：ビュー：開発 | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | 環境：ビュー：製品 | プロジェクトID | + | getEnvVarsByProjectId | env\_var | プロジェクト：ビュー | プロジェクトID | + | addGroup | グループ | 追加 | | + | getOpenshiftByProjectId | openshift | ビュー | プロジェクトID | + | addProject | プロジェクト | 追加 | | + | getProjectByEnvironmentId | プロジェクト | ビュー | プロジェクトID | + | getProjectByGitUrl | プロジェクト | ビュー | プロジェクトID | + | getProjectByName | プロジェクト | ビュー | プロジェクトID | + | addRestore | リストア | 追加 | プロジェクトID | + | updateRestore | リストア | 更新 | プロジェクトID | + | taskDrushCacheClear | タスク | drushCacheClear:開発 | プロジェクトID | + | taskDrushCacheClear | タスク | drushCacheClear:製品 | プロジェクトID | + | taskDrushCron | タスク | drushCron:開発 | プロジェクトID | + | taskDrushCron | タスク | drushCron:製品 | プロジェクトID | + | getFilesByTaskId | タスク | ビュー | プロジェクトID | + | getTasksByEnvironmentId | タスク | ビュー | プロジェクトID | + | getTaskByRemoteId | タスク | ビュー | プロジェクトID | + | getTaskById | タスク | ビュー | プロジェクトID | + | addUser | ユーザー | 追加 | | + +=== "オーナー" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | deleteEnvironment | 環境 | delete:production | projectID | + | deleteProject | プロジェクト | 削除 | projectID | + | getProjectByEnvironmentId | プロジェクト | viewPrivateKey | projectID | + | getProjectByGitUrl | プロジェクト | viewPrivateKey | projectID | + | getProjectByName | プロジェクト | viewPrivateKey | projectID | + | deleteBackup | バックアップ | 削除 | projectID | + | addEnvVariable \(to Project\) | env\_var | project:追加 | projectID | + | addEnvVariable \(to Environment\) | env\_var | environment:追加:production | projectID | + | deleteEnvVariable | env\_var | 削除 | projectID || + | deleteEnvVariable \(from Project\) | env\_var | project:削除 | projectID | + | deleteEnvVariable \(from Environment\) | env\_var | environment:削除:production | projectID | + | getEnvVarsByProjectId | env\_var | project:viewValue | projectID | + | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:production | projectID | + | addOrUpdateEnvironment | 環境 | addOrUpdate:production | projectID | + | updateEnvironment | 環境 | update:production | projectID | + | addDeployment | 環境 | deploy:production | projectID | + | deleteDeployment | 配置 | 削除 | projectID | + | updateDeployment | 配置 | 更新 | projectID | + | setEnvironmentServices | 環境 | update:production | projectID | + | deployEnvironmentLatest | 環境 | deploy:production | projectID | + | deployEnvironmentBranch | 環境 | deploy:production | projectID | + | deployEnvironmentPullrequest | 環境 | deploy:production | projectID | + | deployEnvironmentPromote | 環境 | deploy:production | projectID | + | updateGroup | グループ | 更新 | groupID | + | deleteGroup | グループ | 削除 | groupID | + | addUserToGroup | グループ | addUser | groupID | + | removeUserFromGroup | グループ | removeUser | groupID | + | addNotificationToProject | プロジェクト | addNotification | projectID | + | removeNotificationFromProject | プロジェクト | removeNotification | projectID | + | updateProject | プロジェクト | 更新 | projectID | + | addGroupsToProject | プロジェクト | addGroup | projectID | + | removeGroupsFromProject | プロジェクト | removeGroup | projectID | + | addTask | タスク | add:production | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination: 生産 | 環境ID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:production | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:production | プロジェクトID | + | addBackup | バックアップ | 追加 | プロジェクトID | + | getBackupsByEnvironmentId | バックアップ | 表示 | プロジェクトID | + | addEnvVariable \(to Environment\) | env\_var | environment:add:development | プロジェクトID | + | deleteEnvVariable \(from Environment\) | env\_var | environment:delete:development | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:development | プロジェクトID | + | addOrUpdateEnvironment | 環境 | addOrUpdate:development | プロジェクトID | + | updateEnvironment | 環境 | update:development | プロジェクトID | + | deleteEnvironment | 環境 | delete:development | プロジェクトID | + | addDeployment | 環境 | deploy:development | プロジェクトID | + | setEnvironmentServices | 環境 | update:development | プロジェクトID | + | deployEnvironmentLatest | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentBranch | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentPullrequest | 環境 | deploy:development | プロジェクトID | projectID | + | deployEnvironmentPromote | 環境 | deploy:development | projectID | + | getNotificationsByProjectId | 通知 | view | projectID | + | addTask | タスク | add:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:production | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:development | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:production | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:development | environmentID | + | taskDrushSqlSync | タスク | drushSqlSync:source:development | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:source:production | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:production | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:development | projectID | + | deleteTask | タスク | delete | projectID | + | updateTask | タスク | update | projectID | + | uploadFilesFor タスク | task | 更新 | projectID | + | deleteFilesForTask | task | 削除 | projectID | + | getBackupsByEnvironmentId | deployment | ビュー | projectID | + | getEnvironmentsByProjectId | 環境 | ビュー | projectID | + | getEnvironmentServices<br />ByEnvironmentId | 環境 | ビュー | projectID | + | getEnvVarsByEnvironmentId | env\_var | 環境:ビュー:開発 | projectID | + | getEnvVarsByEnvironmentId | env\_var | 環境:ビュー:プロダクション | projectID | + | getEnvVarsByProjectId | env\_var | プロジェクト:ビュー | projectID | + | addGroup | グループ | 追加 | | + | getOpenshiftByProjectId | openshift | ビュー | projectID | + | addProject | プロジェクト | 追加 | | + | getProjectByEnvironmentId | プロジェクト | ビュー | projectID | + | getProjectByGitUrl | プロジェクト | ビュー | projectID | + | getProjectByName | プロジェクト | ビュー | projectID | + | addRestore | リストア | 追加 | projectID | + | updateRestore | リストア | 更新 | projectID | + | taskDrushCacheClear | タスク | drushCacheClear:開発 | projectID | + | taskDrushCacheClear | タスク | drushCacheClear:プロダクション | projectID | + | taskDrushCron | タスク | drushCron:開発 | projectID | + | taskDrushCron | タスク | drushCron:production | projectID | + | getFilesByTaskId | タスク | ビュー | projectID | + | getTasksByEnvironmentId | タスク | ビュー | projectID | + | getTaskByRemoteId | タスク | ビュー | projectID | + | getTaskById | タスク | ビュー | projectID | + | addUser | ユーザー | 追加 | | + +=== "組織ビューア" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | getOrganizationById | 組織 | ビュー | organizationId | + | getProjectByEnvironmentId | 組織 | viewProject | organizationId | + | getGroupsByOrganizationId | 組織 | viewGroup | organizationId | + | getUsersByOrganizationId | 組織 | viewUsers | organizationId | + | getUserByEmailAndOrganizationId | 組織 | viewUser | organizationId | + | getNotificationsByOrganizationId | 組織 | viewNotification | organizationId | + +=== "組織オーナー" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | getOrganizationById | 組織 | ビュー | organizationId | + | getProjectByEnvironmentId | 組織 | viewProject | organizationId | + | getGroupsByOrganizationId | 組織 | | viewGroup | 組織Id | + | getUsersByOrganizationId | 組織 | viewUsers | 組織Id | + | getUserByEmailAndOrganizationId | 組織 | viewUser | 組織Id | + | getNotificationsByOrganizationId | 組織 | viewNotification | 組織Id | + | addProject | 組織 | addProject | 組織Id | + | updateProject | 組織 | updateProject | 組織Id | + | deleteProject | 組織 | deleteProject | 組織Id | + | addGroup | 組織 | addGroup | 組織Id | + | deleteGroup | 組織 | removeGroup | 組織Id | + | addNotificationSlack | 組織 | addNotification | 組織Id | + | updateNotificationSlack | 組織 | updateNotification | 組織Id | + | deleteNotificationSlack | 組織 | removeNotification | 組織Id | + | addUserToOrganization | 組織 | addOwner | 組織Id | + | addUserToOrganization | 組織 | addViewer | 組織Id | + | updateOrganization | 組織 | updateOrganization | 組織Id | + +=== "プラットフォーム全体の所有者" + + | **名前** | **リソース** | **範囲** | **属性** | + | :--- | :--- | :--- --- | :--- | + | addOrUpdateEnvironment<br />Storage | 環境 | ストレージ | 追加または更新 | + | addNotificationSlack | 通知 | スラック | 追加 | + | updateNotificationSlack | 通知 | スラック | 更新 | + | deleteNotificationSlack | 通知 | スラック | 削除 | + | addKubernetes | kubernetes | 追加 | | + | updateKubernetes | kubernetes | 更新 | | + | deleteKubernetes | kubernetes | 削除 | | + | deleteAllKubernetes| kubernetes | 全削除 | | + | getAllOpenshifts | openshift | 全表示 | | + | getAllProjects | プロジェクト | 全表示 | | + | addSshKey | ssh\_key | 追加 | ユーザーID | + | updateSshKey | ssh\_key | 更新 | ユーザーID | + | deleteSshKey | ssh\_key | 削除 | ユーザーID | + | getUserSshKeys | ssh\_key | ユーザー表示 | ユーザーID | + | updateUser | ユーザー | 更新 | ユーザーID | + | deleteUser | ユーザー | 削除 | ユーザーID | + | deleteEnvironment | 環境 | 本番環境削除 | プロジェクトID | + | deleteProject | プロジェクト | 削除 | プロジェクトID | + | getProjectByEnvironmentId | プロジェクト | 秘密鍵表示 | プロジェクトID | + | getProjectByGitUrl | プロジェクト | 秘密鍵表示 | プロジェクトID | + | getProjectByName | プロジェクト | 秘密鍵表示 | プロジェクトID | + | deleteBackup | バックアップ | 削除 | | | 削除 | projectID | + | addEnvVariable \(プロジェクトへ\) | env\_var | project:add | projectID | + | addEnvVariable \(環境へ\) | env\_var | environment:add:production | projectID | + | deleteEnvVariable | env\_var | delete | projectID || + | deleteEnvVariable \(プロジェクトから\) | env\_var | project:delete | projectID | + | deleteEnvVariable \(環境から\) | env\_var | environment:delete:production | projectID | + | getEnvVarsByProjectId | env\_var | project:viewValue | projectID | + | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:production | projectID | + | addOrUpdateEnvironment | environment | addOrUpdate:production | projectID | + | updateEnvironment | environment | update:production | projectID | + | allEnvironments | environment | viewAll | | + | getEnvironmentStorageMonthBy<br />EnvironmentId | environment | storage | | + | getEnvironmentHoursMonthBy<br />EnvironmentId | environment | storage | | + | getEnvironmentHitsMonthBy<br />EnvironmentId | environment | storage | | + | addOrUpdateEnvironment<br />Storage | environment | storage | | + | addDeployment | environment | deploy:production | projectID | + | 削除 デプロイメント | deployment | 削除 | projectID | + | updateDeployment | deployment | 更新 | projectID | + | setEnvironmentServices | 環境 | 更新:本番 | projectID | + | deployEnvironmentLatest | 環境 | デプロイ:本番 | projectID | + | deployEnvironmentBranch | 環境 | デプロイ:本番 | projectID | + | deployEnvironmentPullrequest | 環境 | デプロイ:本番 | projectID | + | deployEnvironmentPromote | 環境 | デプロイ:本番 | projectID | + | updateGroup | グループ | 更新 | groupID | + | deleteGroup | グループ | 削除 | groupID | + | addUserToGroup | グループ | addUser | groupID | + | removeUserFromGroup | グループ | removeUser | groupID | + | addNotificationToProject | プロジェクト | addNotification | projectID | + | removeNotificationFromProject | プロジェクト | removeNotification | projectID | + | updateProject | プロジェクト | 更新 | projectID | + | addGroupsToProject | プロジェクト | addGroup | projectID | + | removeGroupsFromProject | プロジェクト | removeGroup | projectID | + | addTask | タスク | 追加:本番 | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:本番 | environmentID | + | taskDrushSql Sync | タスク | drushSqlSync:destination:production | プロジェクトID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:production | プロジェクトID | + | addBackup | バックアップ | 追加 | プロジェクトID | + | getBackupsByEnvironmentId | バックアップ | 表示 | プロジェクトID | + | addEnvVariable \(to Environment\) | env\_var | environment:add:development | プロジェクトID | + | deleteEnvVariable \(from Environment\) | env\_var | environment:delete:development | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | environment:viewValue:development | プロジェクトID | + | addOrUpdateEnvironment | 環境 | addOrUpdate:development | プロジェクトID | + | updateEnvironment | 環境 | update:development | プロジェクトID | + | deleteEnvironment | 環境 | delete:development | プロジェクトID | + | addDeployment | 環境 | deploy:development | プロジェクトID | + | setEnvironmentServices | 環境 | update:development | プロジェクトID | + | deployEnvironmentLatest | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentBranch | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentPullrequest | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentPromote | 環境 | deploy:development | プロジェクトID | 環境 | deploy:development | projectID | + | getNotificationsByProjectId | 通知 | 表示 | projectID | + | addTask | タスク | add:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:production | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:development | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:production | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:development | environmentID | + | taskDrushSqlSync | タスク | drushSqlSync:source:development | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:source:production | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:production | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:development | projectID | + | deleteTask | タスク | 削除 | projectID | + | updateTask | タスク | 更新 | projectID | + | uploadFilesForTask | タスク | 更新 | projectID | + | 削除 FilesForTask | タスク | 削除 | projectID | + | getBackupsByEnvironmentId | デプロイメント | 表示 | projectID | + | getEnvironmentsByProjectId | 環境 | 表示 | projectID | + | getEnvironmentServices<br />ByEnvironmentId | 環境 | 表示 | projectID | + | getEnvVarsByEnvironmentId | env\_var | 環境:表示:開発 | projectID | + | getEnvVarsByEnvironmentId | env\_var | 環境:表示:製品 | projectID | + | getEnvVarsByProjectId | env\_var | プロジェクト:表示 | projectID | + | addGroup | グループ | 追加 | | + | getOpenshiftByProjectId | openshift | 表示 | projectID | + | addProject | プロジェクト | 追加 | | + | getProjectByEnvironmentId | プロジェクト | 表示 | projectID | + | getProjectByGitUrl | プロジェクト | 表示 | projectID | + | getProjectByName | プロジェクト | 表示 | projectID | + | addRestore | リストア | 追加 | projectID | + | updateRestore | リストア | 更新 | projectID | + | taskDrushCacheClear | タスク | drushCacheClear:開発 | projectID | + | taskDrushCacheClear | タスク | drushCacheClear:製品 | projectID | + | taskDrushCron | タスク | drushCron:開発 | projectID | + | taskDrushCron | タスク | drushCron:製品 | projectID | + | getFilesByTaskId | タスク | ビュー | プロジェクトID | + | getTasksByEnvironmentId | タスク | ビュー | プロジェクトID | + | getTaskByRemoteId | タスク | ビュー | プロジェクトID | + | getTaskById | タスク | ビュー | プロジェクトID | + | addUser | ユーザー | 追加 | | + | getAllOrganizations | 組織 | 全て表示 | | + | addOrganization | 追加 | 全て表示 | | + | updateOrganization | 更新 | 全て表示 | | + | deleteOrganization | 削除 | 全て表示 | | + | getOrganizationById | 組織 | ビュー | 組織ID | + | getProjectByEnvironmentId | 組織 | プロジェクト表示 | 組織ID | + | getGroupsByOrganizationId | 組織 | グループ表示 | 組織ID | + | getUsersByOrganizationId | 組織 | ユーザー表示 | 組織ID | + | getUserByEmailAndOrganizationId | 組織 | ユーザー表示 | 組織ID | + | getNotificationsByOrganizationId | 組織 | 通知表示 | 組織ID | + | addProject | 組織 | プロジェクト追加 | 組織ID | + | updateProject | 組織 | プロジェクト更新 | 組織ID | + | deleteProject | 組織 | プロジェクト削除 | 組織ID | + | addGroup | 組織 | グループ追加 | 組織ID | + | deleteGroup | 組織 | グループを削除 | 組織ID | + | Slack通知を追加 | 組織 | 通知を追加 | 組織ID | + | Slack通知を更新 | 組織 | 通知を更新 | 組織ID | + | Slack通知を削除 | 組織 | 通知を削除 | 組織ID | + | ユーザーを組織に追加 | 組織 | オーナーを追加 | 組織ID | + | ユーザーを組織に追加 | 組織 | ビューワーを追加 | 組織ID | + | 組織を更新 | 組織 | 組織を更新 | 組織ID | + +=== "プラットフォーム全体の管理者" + + | **名前** | **リソース** | **スコープ** | **属性** | + | :--- | :--- | :--- | :--- | + | すべてのバックアップを削除 | バックアップ | すべて削除 | | + | すべての環境を削除 | 環境 | すべて削除 | | + | 環境IDによる月別環境ストレージを取得 | 環境 | ストレージ | | + | 環境IDによる月別環境時間を取得 | 環境 | ストレージ | | + | 環境IDによる月別環境ヒットを取得 | 環境 | ストレージ | | + | すべてのグループを削除 | グループ | すべて削除 | | + | すべてのSlack通知を削除 | 通知 | すべて削除 | | + | すべてのプロジェクトからすべての通知を削除 | 通知 | すべて削除 | | 全てのOpenshiftsを取得 | openshift | 全部見る | | + | 全プロジェクトを削除 | project | 全部削除 | | + | 全Sshキーを削除 | ssh\_key | 全部削除 | | + | 全ユーザーから全Sshキーを削除 | ssh\_key | 全部削除 | | + | 全ユーザーを削除 | user | 全部削除 | | + | 環境ストレージを追加または更新<br /> | environment | storage | | + | Slack通知を追加 | notification | 追加 | | + | Slack通知を更新 | notification | 更新 | | + | Slack通知を削除 | notification | 削除 | | + | Kubernetesを追加 | kubernetes | 追加 | | + | Kubernetesを更新 | kubernetes | 更新 | | + | Kubernetesを削除 | kubernetes | 削除 | | + | 全Kubernetesを削除| kubernetes | 全部削除 | | + | 全プロジェクトを取得 | project | 全部見る | | + | Sshキーを追加 | ssh\_key | 追加 | userID | + | Sshキーを更新 | ssh\_key | 更新 | userID | + | Sshキーを削除 | ssh\_key | 削除 | userID | + | ユーザーのSshキーを取得 | ssh\_key | ユーザー表示 | userID | + | ユーザーを更新 | user | 更新 | userID | + | ユーザーを削除 | user | 削除 | userID | + | 環境を削除 | environment | production削除 | projectID | + | プロジェクトを削除 | project | 削除 | projectID | + | 環境IDによるプロジェクト取得 | project | 私の鍵を見る | プロジェクトID | + | getProjectByGitUrl | プロジェクト | 私の鍵を見る | プロジェクトID | + | getProjectByName | プロジェクト | 私の鍵を見る | プロジェクトID | + | deleteBackup | バックアップ | 削除 | プロジェクトID | + | addEnvVariable（プロジェクトに） | env_var | プロジェクト：追加 | プロジェクトID | + | addEnvVariable（<br />環境に） | env_var | 環境：追加：プロダクション | プロジェクトID | + | deleteEnvVariable | env_var | 削除 | プロジェクトID || + | deleteEnvVariable（プロジェクトから） | env_var | プロジェクト：削除 | プロジェクトID | + | deleteEnvVariable（環境から） | env_var | 環境：削除：プロダクション | プロジェクトID | + | getEnvVarsByProjectId | env_var | プロジェクト：値を見る | プロジェクトID | + | getEnvVarsByEnvironmentId | env_var | 環境：値を見る：プロダクション | プロジェクトID | + | addOrUpdateEnvironment | 環境 | 追加または更新：プロダクション | プロジェクトID | + | updateEnvironment | 環境 | 更新：プロダクション | プロジェクトID | + | addDeployment | 環境 | デプロイ：プロダクション | プロジェクトID | + | deleteDeployment | デプロイメント | 削除 | プロジェクトID | + | updateDeployment | デプロイメント | 更新 | プロジェクトID | + | setEnvironmentServices | 環境 | 更新：プロダクション | projectID | + | deployEnvironmentLatest | 環境 | deploy:production | projectID | + | deployEnvironmentBranch | 環境 | deploy:production | projectID | + | deployEnvironmentPullrequest | 環境 | deploy:production | projectID | + | deployEnvironmentPromote | 環境 | deploy:production | projectID | + | updateGroup | グループ | 更新 | groupID | + | deleteGroup | グループ | 削除 | groupID | + | addUserToGroup | グループ | addUser | groupID | + | removeUserFromGroup | グループ | removeUser | groupID | + | addNotificationToProject | プロジェクト | addNotification | projectID | + | removeNotificationFromProject | プロジェクト | removeNotification | projectID | + | updateProject | プロジェクト | 更新 | projectID | + | addGroupsToProject | プロジェクト | addGroup | projectID | + | removeGroupsFromProject | プロジェクト | removeGroup | projectID | + | addTask | タスク | add:production | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:production | environmentID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:production | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:production | projectID | + | addBackup | バックアップ | 追加 | プロジェクトID | + | getBackupsByEnvironmentIdによるバックアップ | バックアップ | 見る | プロジェクトID | + | addEnvVariable \(環境に\) | env\_var | environment:add:development | プロジェクトID | + | deleteEnvVariable \(環境から\) | env\_var | environment:delete:development | プロジェクトID | + | getEnvVarsByEnvironmentIdによるenv_var | env\_var | environment:viewValue:development | プロジェクトID | + | 環境の追加または更新 | 環境 | addOrUpdate:development | プロジェクトID | + | 環境の更新 | 環境 | update:development | プロジェクトID | + | 環境の削除 | 環境 | delete:development | プロジェクトID | + | デプロイメントの追加 | 環境 | deploy:development | プロジェクトID | + | setEnvironmentServicesによる環境 | 環境 | update:development | プロジェクトID | + | deployEnvironmentLatestによる環境 | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentBranchによる環境 | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentPullrequestによる環境 | 環境 | deploy:development | プロジェクトID | + | deployEnvironmentPromoteによる環境 | 環境 | deploy:development | プロジェクトID | + | getNotificationsByProjectIdによる通知 | 通知 | 見る | プロジェクトID | + | タスクの追加 | タスク | add:development | プロジェクトID | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:development | projectID | + | taskDrushArchiveDump | タスク | drushArchiveDump:production | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:development | projectID | + | taskDrushSqlDump | タスク | drushSqlDump:production | projectID | + | taskDrushUserLogin | タスク | drushUserLogin:destination:development | environmentID | + | taskDrushSqlSync | タスク | drushSqlSync:source:development | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:source:production | projectID | + | taskDrushSqlSync | タスク | drushSqlSync:destination:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:development | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:source:production | projectID | + | taskDrushRsyncFiles | タスク | drushRsync:destination:development | projectID | + | deleteTask | タスク | 削除 | projectID | + | updateTask | タスク | 更新 | projectID | + | uploadFilesForTask | タスク | 更新 | projectID | + | deleteFilesForTask | タスク | 削除 | projectID | + | getBackupsByEnvironmentId | デプロイメント | ビュー | projectID | + | getEnvironmentsByProjectId | 環境 | | 表示 | プロジェクトID | + | getEnvironmentServices<br />ByEnvironmentId | 環境 | 表示 | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | environment:view:development | プロジェクトID | + | getEnvVarsByEnvironmentId | env\_var | environment:view:production | プロジェクトID | + | getEnvVarsByProjectId | env\_var | project:view | プロジェクトID | + | addGroup | group | 追加 | | + | getOpenshiftByProjectId | openshift | 表示 | プロジェクトID | + | addProject | project | 追加 | | + | getProjectByEnvironmentId | project | 表示 | プロジェクトID | + | getProjectByGitUrl | project | 表示 | プロジェクトID | + | getProjectByName | project | 表示 | プロジェクトID | + | addRestore | restore | 追加 | プロジェクトID | + | updateRestore | restore | 更新 | プロジェクトID | + | taskDrushCacheClear | task | drushCacheClear:development | プロジェクトID | + | taskDrushCacheClear | task | drushCacheClear:production | プロジェクトID | + | taskDrushCron | task | drushCron:development | プロジェクトID | + | taskDrushCron | task | drushCron:production | プロジェクトID | + | getFilesByTaskId | task | 表示 | プロジェクトID | + | getTasksByEnvironmentId | task | 表示 | プロジェクトID | + | getTaskByRemoteId | task | 表示 | プロジェクトID | | getTaskById | タスク | ビュー | プロジェクトID | + | addUser | ユーザー | 追加 | | + | getAllOrganizations | 組織 | すべて表示 | | + | addOrganization | 追加 | すべて表示 | | + | updateOrganization | 更新 | すべて表示 | | + | deleteOrganization | 削除 | すべて表示 | | + | getOrganizationById | 組織 | ビュー | 組織ID | + | getProjectByEnvironmentId | 組織 | プロジェクト表示 | 組織ID | + | getGroupsByOrganizationId | 組織 | グループ表示 | 組織ID | + | getUsersByOrganizationId | 組織 | ユーザー表示 | 組織ID | + | getUserByEmailAndOrganizationId | 組織 | ユーザー表示 | 組織ID | + | getNotificationsByOrganizationId | 組織 | 通知表示 | 組織ID | + | addProject | 組織 | プロジェクト追加 | 組織ID | + | updateProject | 組織 | プロジェクト更新 | 組織ID | + | deleteProject | 組織 | プロジェクト削除 | 組織ID | + | addGroup | 組織 | グループ追加 | 組織ID | + | deleteGroup | 組織 | グループ削除 | 組織ID | + | addNotificationSlack | 組織 | 通知追加 | 組織ID | + | updateNotificationSlack | 組織 | updateNotification | 組織Id | + | deleteNotificationSlack | 組織 | removeNotification | 組織Id | + | addUserToOrganization | 組織 | addOwner | 組織Id | + | addUserToOrganization | 組織 | addViewer | 組織Id | + | updateOrganization | 組織 | updateOrganization | 組織Id | \ No newline at end of file diff --git a/docs/interacting/ssh.ja.md b/docs/interacting/ssh.ja.md new file mode 100644 index 0000000000..31d584055f --- /dev/null +++ b/docs/interacting/ssh.ja.md @@ -0,0 +1,143 @@ +# SSH + +Lagoonでは、SSHを通じて実行中のコンテナに接続することができます。コンテナ自体にはSSHサーバーはインストールされていませんが、代わりにSSHを使ってLagoonに接続し、そこからKubernetes APIを通じてリモートシェル接続を作成します。 + +## SSHアクセスの設定を確認する + +### SSHキーの生成 + +同じキーを複数のコンピューター間で共有するのではなく、各デバイスごとに別々のSSHキーを生成することをお勧めします。各システムでのSSHキーの生成方法については以下を参照してください。 + +#### OSX（Mac） + +[Mac](https://www.makeuseof.com/ssh-keygen-mac){ .md-button } + +#### Linux（Ubuntu） + +[Linux](https://help.ubuntu.com/community/SSH/OpenSSH/Keys){ .md-button } + +#### Windows + +[Windows](https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement){ .md-button } + +### SSHエージェント + +#### OSX（Mac） + +OSXは、起動時に設定されたSSHキーをロードするようにSSHエージェントが設定されていません。これにより問題が発生することがあります。この機能の設定方法については、こちらのガイドを参照してください：[https://www.backarapper.com/add-ssh-keys-to-ssh-agent-on-startup-in-macos/](https://www.backarapper.com/add-ssh-keys-to-ssh-agent-on -startup-in-macos/) + +#### Linux + +Linuxディストリビューションは、`ssh-agent`の使用方法によります。一般的なガイドはここにあります：[https://www.ssh.com/academy/ssh/agent](https://www.ssh.com/academy/ssh/agent) + +#### Windows + +最近ではWindowsでのSSHキーのサポートが大幅に向上し、現在ではネイティブにサポートされています。Windows 10のSSHエージェントの設定についての便利なガイドはここにあります：[https://richardballard.co.uk/ssh-keys-on-windows-10/](https://richardballard.co.uk/ssh-keys-on-windows-10/) + +### SSHキーのアップロード + +### UIを通じて + +SSHキーをUIを通じてアップロードできます。通常通りにログインしてください。 + +右上の角にある設定をクリックします： + +![右上の角にある「設定」をクリックします](../images/ui-settings.png) + +次に、SSHキーをアップロードできるページが表示され、アップロードされたキーが表示されます。キーをテキストボックスに貼り付け、名前を付けて「追加」をクリックします。それだけです！必要に応じて追加のキーを追加します。 + +![キーをテキストボックスに貼り付けます。](../images/ui-ssh.png) + +### コマンドライン経由 + +Lagoon APIをGraphQL経由で使用してユーザーにSSHキーを追加する一般的な例は[ここ](../interacting/graphql-queries.md#allowing-access-to-the)にあります。 -プロジェクト） + +## ポッドへのSSH接続 + +### 接続 + +接続は直接的で、次のパターンに従います： + +```bash title="SSH" +ssh -p [PORT] -t [PROJECT-ENVIRONMENT-NAME]@[HOST] +``` + +* `PORT` - リモートシェルのSSHエンドポイントポート（amazee.ioの場合：`32222`）。 +* `HOST` - リモートシェルのSSHエンドポイントホスト（amazee.ioの場合`ssh.lagoon.amazeeio.cloud`）。 +* `PROJECT-ENVIRONMENT-NAME` - 接続したい環境。これは通常`PROJECTNAME-ENVIRONMENT`のパターンで使用されます。 + +例えば： + +```bash title="SSH example" +ssh -p 32222 -t drupal-example-main@ssh.lagoon.amazeeio.cloud +``` + +これにより、`main`環境のプロジェクト`drupal-example`に接続します。 + +### ポッド/サービス、コンテナ定義 + +デフォルトでは、リモートシェルはタイプ`cli`で定義されたコンテナに接続しようとします。他のポッド/サービスに接続したい場合は、以下のように定義できます： + +```bash title="SSH to another service" +ssh -p [PORT] -t [PROJECT-ENVIRONMENT-NAME]@[HOST] service=[SERVICE-NAME] +``` + +あなたのポッド/サービスに複数のコンテナが含まれている場合、Lagoonはあなたを最初に定義されたコンテナに接続します。また、接続したい特定のコンテナを定義することもできます： + +```bash title=" "コンテナ"を定義します。 +ssh -p [ポート] -t [プロジェクト-環境名]@[ホスト] service=[サービス名] container=[コンテナ名] + +例えば、`nginx`ポッド内の`php`コンテナに接続するには： + +```bash title="SSH to php container" +ssh -p 32222 -t drupal-example-main@ssh.lagoon.amazeeio.cloud service=nginx container=php +``` + +## ファイルのコピー + +一般的なケースで、ファイルを`cli`ポッドにコピーすることは、通常のSSH互換ツールを使って達成できます。 + +### scp + +```bash title="Copy file with scp" +scp -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P 32222 [ローカルパス] [プロジェクト名]-[環境名]@ssh.lagoon.amazeeio.cloud:[リモートパス] +``` + +### rsync + +```bash title="Copy files with rsync" +rsync --rsh='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 32222' [ローカルパス] [プロジェクト名]-[環境名]@ssh.lagoon.amazeeio.cloud:[リモートパス] +``` + +### tar + +```bash +ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P 32222 [プロジェクト名]-[環境名]@ssh.lagoon.amazee.io tar -zcf - [リモートパス] | tar -zxf - -C /tmp/ +``` + +### 非CLIポッド/サービスの指定 + +まれなケースで、非CLIサービスを指定する必要がある場合は、指定することができます。 `service=...`および/または`container=...`引数はコピーコマンドにあります。 + +`tar`を`ssh`接続を通してパイプすることは最も単純な方法で、通常の`tar`フラグを用いてファイルやディレクトリーをコピーするために使用できます： + +```bash +ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -P 32222 [project_name]-[environment_name]@ssh.lagoon.amazee.io service=solr tar -zcf - [remote_path] | tar -zxf - -C /tmp/ +``` + +また、LagoonのSSHサービスに必要な形で`ssh`の引数を並べ替えるラッパースクリプトを用いて`rsync`を使用することもできます： + +```bash +#!/usr/bin/env sh +svc=$1 user=$3 host=$4 +shift 4 +exec ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 32222 -l "$user" "$host" "$svc" "$@" +``` + +それを実行可能なシェルスクリプト`rsh.sh`に入れて、`rsync`コマンドで`service=...`を指定します： + +```bash title="rsync to non-CLI pod" +rsync --rsh="/path/to/rsh.sh service=cli" /tmp/foo [project_name]-[environment_name]@ssh.lagoon.amazeeio.cloud:/tmp/foo +``` + +このスクリプトは、`container=...`引数も処理するように調整することもできます。 \ No newline at end of file diff --git a/docs/lagoonizing/index.ja.md b/docs/lagoonizing/index.ja.md new file mode 100644 index 0000000000..b8aaf59750 --- /dev/null +++ b/docs/lagoonizing/index.ja.md @@ -0,0 +1,652 @@ +# 既存のサイトをラグーン化する + +_ラグーン化_、つまり既存のサイトをラグーンプラットフォームに対応させることは、一般的には難しくありません（サイトやセットアップによりますが）、しかしいくつかの手順が必要です。このプロセスを簡単にするためのステップバイステップのガイドをまとめました。 + +## 要件 + +あなたのシステムがローカルでラグーンを使用するための[要件を満たしている](../using-lagoon-the-basics/index.md)ことを確認してください。 + +## ローカル開発環境 + +[ローカル開発環境を設定する](../using-lagoon-the-basics/local-development-environments.md)。PygmyとLandoのどちらかを選ぶことができます。 + +## コマンドラインとGit + +コマンドラインを通じてラグーンとやりとりする必要があり、またGitも必要ですので、準備が整っていることを確認してください。 + +### コマンドライン + +いくつかのタスクにはコマンドラインターミナルを使用する必要があります。何を使用しても構いません、オペレーティングシステムのデフォルトツールも含めてです。以下にいくつかのオプションを示します： + +- [iTerm2](https://iterm2.com/) (Mac) +- [PowerShell](https://docs.microsoft.com/en-us/powershell/) (Windows) +- [Fish](https://fishshell.com/) (Mac, Windows, Linux) +- [Tabby](https://tabby.sh/) (Mac, Windows, Linux) + +### 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) +- [GitHub Desktop](https://desktop.github.com/) (Mac、Windows) +- [GitKraken](https://www.gitkraken.com/git-client) (Mac、Windows、Linux - 公開リポジトリは無料) + +## ラグーン管理者が必要とするもの + +ラグーンを設定しているラグーン管理者は、いくつかの情報を必要とします。[詳細はこちら](../using-lagoon-the-basics/setup-project.md)。 + +## Webhooksの設定 + +次に、Gitリポジトリのためのwebhooksを設定する必要があります。[その手順はこちらで見つけることができます](../using-lagoon-the-basics/configure-webhooks.md)。 + +## `docker-compose.yml` + +`docker-compose.yml`ファイルは、Lagoonによって以下のように使用されます： + +- どのサービス/コンテナをデプロイするべきかを学ぶ。 +- コンテナのイメージがどのようにビルドされるかを定義する。 +- 永続ボリュームなどの追加設定を定義する。 + +さらに詳しくは[私たちの`docker-compose.yml`ドキュメンテーション](../を読むことができます。 concepts-basics/docker-compose-yml.md). + +これは、あなたのサイトをLagoonに対応させるために作成・設定する2つのファイルのうちの1つです。 + +`Docker-compose`（ツール）は、YAMLファイルの内容を厳格に検証するので、サービス定義の**ラベル**内でのみ設定を行うことができます。 + +!!! warning "警告" + + Lagoonは`docker-compose.yml`ファイルからラベル、サービス名、イメージ名、ビルド定義のみを読み込みます。ポート、環境変数、ボリューム、ネットワーク、リンク、ユーザーなどの定義は無視されます。これは意図的なもので、`docker-compose`ファイルはあなたのローカル環境設定を定義するためのものです。Lagoonは`lagoon.type`からあなたがデプロイしているサービスのタイプを学び、その結果、このサービスが必要とする可能性のあるポート、ネットワーク、その他の追加設定について知ることができます。 + +基本的なサービスの設定方法をいくつか見てみましょう。この例では、Drupal、Laravel、その他のコンテンツマネジメントシステムなど、多くのシステムに必要なNGINX、PHP、MariaDBを設定します。 + +以下は、Drupal用の`docker-compose.yml`ファイルの直接的な例です： + +```yaml title="docker-compose.yml" +version: '2.3' + +x-lagoon-project: + # Lagoonプロジェクト名（ この)を編集するときに `&lagoon-project`を残してください + &lagoon-project drupal-example + +x-volumes: + &default-volumes + # Dockerコンテナにリアルタイムでマウントしたいすべてのボリュームを定義します + volumes: + - .:/app:delegated + +x-environment: + &default-environment + LAGOON_PROJECT: *lagoon-project + # ローカルで使用するルート。pygmyを使用している場合、このルートは *必ず* .docker.amazee.ioで終わらなければなりません + LAGOON_ROUTE: http://drupal-example.docker.amazee.io + # システムを本番環境のように動作させたい場合はコメントアウトを解除してください + #LAGOON_ENVIRONMENT_TYPE: production + # xdebugを有効にし、`docker-compose up -d`で再起動したい場合はコメントアウトを解除してください + #XDEBUG_ENABLE: "true" + +x-user: + &default-user + # コンテナが実行するデフォルトのユーザー。Linux上でid `1000`以外のユーザーとして実行する場合にはこれを変更します。 + user: '1000' + +services: + nginx: + build: + context: . + dockerfile: nginx.dockerfile + labels: + lagoon.type: nginx-php-persistent + lagoon.persistent: /app/web/sites/default/files/ + + php: + build: + context: . + dockerfile: php.dockerfile + labels: + lagoon.type: nginx-php-persistent lagoon.name：nginx + lagoon.persistent：/app/web/sites/default/files/ + + mariadb: + image: amazeeio/mariadb-drupal + labels: + lagoon.type: mariadb +``` + + +それぞれのオプションが何を意味するかを見てみましょう。 + +### 基本設定 + +`x-lagoon-project`： +これはプロジェクトのマシン名です、ここで定義します。"drupal-example"という例を使用します。 + +`x-volumes`： +これはLagoonにコンテナにマウントするものを指示します。ウェブアプリケーションは`/app`に存在しますが、必要に応じてこれを追加または変更できます。 + +`x-environment`： + +- ここでローカル開発URLを設定できます。Pygmyを使用している場合、`.docker.amazee.io.`で終わらなければなりません。 +- 本番環境を完全に模倣したい場合は、`LAGOON_ENVIRONMENT_TYPE: production`のコメントを解除します。 +- x-debugを有効にしたい場合は、`DEBUG_ENABLE: "true"`のコメントを解除します。 + +`x-user`： +これを変更する必要はほとんどありませんが、Linuxを使用していて1000以外のユーザーとして実行したい場合は変更できます。 + +### `services` + +これはデプロイしたいすべてのサービスを定義します。残念ながら、`docker-compose`はそれらをサービスと呼びますが、実際にはコンテナを定義しています。今後、これらをサービスと呼び、このドキュメンテーション全体で呼びます。 + +サービスの**名前**は Translation request timed out. -images/commons.md). + +### タイプ + +Lagoonは、正しいKubernetesのオブジェクトを設定するために、デプロイするサービスのタイプを知る必要があります。 + +これは `lagoon.type` ラベルを介して行われます。選択できるタイプは多岐にわたります。すべてのタイプと追加的な設定可能性を見るために、私たちの公開ドキュメンテーション [Service Types](../concepts-advanced/service-types.md) を読んでください。 + +例で気づいたかもしれませんが、PHPとNGINXのサービスは両方ともタイプを `nginx-php-persistent` と定義しています。それは彼らがいわゆるマルチコンテナポッドだからです。 + +### マルチコンテナポッド + +Kubernetesはプレーンなコンテナをデプロイしません。代わりに、それは1つ以上のコンテナを持つポッドをデプロイします。通常、Lagoonは定義された `docker-compose` サービスごとにコンテナを内部に持つ単一のポッドを作成します。しかし、いくつかのケースでは、これらのコンテナが互いに非常に依存しているため、単一のポッド内に2つのコンテナを置く必要があります。そのような状況の例は、DrupalのようなウェブアプリケーションのPHPコードを含むPHPとNGINXのコンテナです。 + +これらのケースでは、どのサービスが一緒に留まるべきかをLagoonに伝えることが可能です。 一緒に。これは以下の方法で行われます（私たちはコンテナをサービスと呼んでいることを覚えておいてください）： + +1. 両方のサービスを `lagoon.type` で定義し、それが2つのサービスを期待している（この例では、NGINXとPHPのサービスで定義されている `nginx-php-persistent` ）。 +2. 2番目のサービスを1番目のサービスにリンクし、2番目のサービスのラベル `lagoon.name` を1番目のものと一致させます（この例では `lagoon.name: nginx` の設定によりこれが行われます）。 + +これにより、Lagoonは `nginx` と `php` のサービスが `nginx` と呼ばれるポッドに結合されていることを認識します。 + +Lagoonはまだ、2つのサービスのうちどちらが _実際の_ 個々のサービスタイプであるか（この場合は `nginx` と `php` ）を理解する必要があります。これは、一致するサービスタイプのサービス名を検索することでこれを行います。 `nginx-php-persistent` は、 `docker-compose.yml` の中で `nginx` という名前のサービスと `php` という名前のサービスを期待しています。 + +何らかの理由でサービスの名前を変更したい場合や、 `nginx-php-persistent` のタイプを持つ複数のポッドが必要な場合は、実際のサービスタイプを定義するために使用できる追加のラベル `lagoon.deployment.servicetype` があります。 + +以下に、マルチコンテナポッドがどのようになるかを示す例を示します。 詳細に設定する： + +```yaml title="docker-compose.yml" +nginx: + build: + context: . + dockerfile: nginx.dockerfile + labels: + lagoon.type: nginx-php-persistent + lagoon.persistent: /app/web/sites/default/files/ + lagoon.name: nginx # これが存在しない場合、Lagoonはコンテナの名前、この場合はnginxを使用します。 + lagoon.deployment.servicetype: nginx +php: + build: + context: . + dockerfile: php.dockerfile + labels: + lagoon.type: nginx-php-persistent + lagoon.persistent: /app/web/sites/default/files/ + lagoon.name: nginx # このサービスをLagoonのnginxポッドの一部にしたいです。 + lagoon.deployment.servicetype: php +``` + +docker-compose.ymlでできることはもっとありますが、サービスを設定することが最も重要な部分です。[`docker-compose.yml`に関する我々のドキュメンテーション](../concepts-basics/docker-compose-yml.md)をチェックして、他に何ができるかを学んでください。 + +## `.lagoon.yml` + +[`.lagoon.yml`](../concepts-basics/lagoon-yml.md) ファイルは、プロジェクトを設定するための中心的なファイルです。以下を行うための設定が含まれています： + +- サイトへのアクセスルートを定義します。 +- プレロールアウトタスクを定義します。 - ポストロールアウトタスクを定義する。 +- SSL証明書を設定する。 +- 環境のためのcronジョブを追加する。 + +`.lagoon.yml`ファイルを作成し、Gitリポジトリのルートに配置する必要があります。 + +以下に、私たちが説明するDrupalサイトの様々な設定オプションを示す例の`.lagoon.yml`ファイルを示します： + +```yaml title=".lagoon.yml" + +docker-compose-yaml: docker-compose.yml + +environment_variables: + git_sha: 'true' + +tasks: + pre-rollout: + - run: + name: drush sql-dump + command: mkdir -p /app/web/sites/default/files/private/ && drush sql-dump --ordered-dump --gzip --result-file=/app/web/sites/default/files/private/pre-deploy-dump.sql.gz + service: cli + post-rollout: + - run: + name: drush cim + command: drush -y cim + service: cli + shell: bash + - run: + name: drush cr + command: drush -y cr + service: cli + +routes: + insecure: Redirect + +environments: + main: + monitoring_urls: + - "www.example.com" + - "www.example.com/special_page" + routes: + - nginx: + - example.com + - example.net + - "www.example.com": + tls-acme: 'true' + insecure: Redirect + hsts: max +``` -年齢=31536000 + - "example.ch": + アノテーション: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri + - www.example.ch + + タイプ: + マリアDB: mariadb-galera + テンプレート: + マリアDB: mariadb.main.deployment.yml + ロールアウト: + マリアDB: statefulset + クロンジョブ: + - 名前: drush cron + スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。 + コマンド: drush cron + サービス: cli + ステージング: + クロンジョブ: + - 名前: drush cron + スケジュール: "H * * * *" # これはクロンを1時間ごとに実行します。 + コマンド: drush cron + サービス: cli +``` + +### 一般設定 + +#### `docker-compose-yaml` + +このファイルは、どのサービスとコンテナがデプロイされるべきかを知るために、どの`docker-compose`YAMLファイルをビルドスクリプトが使用すべきかを指示します。これはデフォルトで`docker-compose.yml`になりますが、特定のLagoon `docker-compose` YAMLファイルが必要な場合にはこれを使用することができます。 + +#### `environment_variables.git_sha` + +この設定は、デプロイされたGit SHAを環境変数としてプロジェクトに注入することを可能にします。デフォルトではこれは無効化されています。値を`true`に設定すると Translation request timed out. これらは各コンテナの `WORKDIR`で実行されます。Lagoon画像の場合、これは `/app` なので、タスクを実行するために特定の場所に`cd`する必要がある場合はこれを念頭に置いてください。 + +`service` + +- タスクを実行するサービス。私たちのdrupal-exampleに従っている場合、これはCLIコンテナになります。なぜなら、それはあなたのサイトのコード、ファイル、そしてデータベースへの接続を全て持っているからです。通常、これを変更する必要はありません。 + +`shell` + +タスクを実行するためにどのシェルを使用するべきか。デフォルトでは `sh` が使用されますが、コンテナに他のシェル（bashなど）がある場合、ここでそれを定義することができます。これは、post-rollouts内でいくつかの小さなif/else bashスクリプトを実行したい場合に便利です。(上記の例で複数行のスクリプトを書く方法を参照してください)。 + +### ルート + +#### `routes.autogenerate.enabled` + +これにより、自動的に作成されたルートをまったく無効にすることができます。これは環境ごとのカスタムルートを無効にするものではありません。それについては下記を参照してください。 + +#### `routes.autogenerate.insecure` + +これにより、自動的に作成されたルートの挙動を定義することができます。これは環境ごとのカスタムルートを設定するものではありません。それについては下記を参照してください。これは、上記の例で使用しているオプションで、`insecure: リダイレクト。 + +以下のオプションが許可されています： + +`許可` + +- HTTPとHTTPSの両方のルートを設定します（これがデフォルトです）。 + +`リダイレクト` + +- すべてのHTTPリクエストをHTTPSにリダイレクトします。 + +`なし` + +- HTTPのルートは作成されず、リダイレクトもありません。 + +### 環境 + +環境名は、デプロイされたブランチまたはプルリクエストに一致します。これにより、各環境は異なる設定を持つことができます。この例では、メインとステージングの環境を持っています。 + +#### 特定のパスの監視 + +UptimeRobotがクラスターに設定されている場合、Lagoonは各ルート/イングレスにアノテーションを注入し、`stakater/IngressControllerMonitor`が使用します。デフォルトのアクションはルートのホームページを監視することです。特定のルートを監視する必要がある場合、ルートの仕様に`monitoring-path`を追加することでこれを上書きできます。一般的な使用法は、キャッシュをバイパスする監視用のパスを設定することで、サイトのリアルタイム監視をより実現します。 + +```yaml title=".lagoon.ymlの例" + - "www.example.com": + monitoring-path: "/bypass-cache" +``` + +#### `environments.[name].routes` + +ルートセクションでは、環境が対応するドメイン名を特定します。それは 通常、ルートが指定された環境は本番環境だけです。すべての環境は生成されたルートを受け取りますが、非本番環境が独自のドメイン名を持つ必要がある場合もあります。ここでそれを指定し、そのドメインを生成されたルート名のCNAMEとしてDNSプロバイダに追加できます（これらのルートはデプロイメッセージで公開されます）。 + +環境の次の要素は、ターゲットサービスで、例ではNGINXです。これにより、どのサービスに入力リクエストを送るかを特定します。 + +最も単純なルートは、上記のサンプル`.lagoon.yml`の`example.com`の例で、追加の設定がないことがわかります。これは、ルートのLet's Encrypt証明書を希望し、HTTPSからHTTPへのリダイレクトがないと仮定します。 + +#### 注釈 + +!!! info + ルート/Ingress注釈は、nginx-ingressコントローラを実行するクラスタにデプロイされるプロジェクトでのみサポートされています！これがサポートされているかどうかはLagoonの管理者に確認してください。 + +注釈は、`nginx-ingress`コントローラがサポートする注釈のYAMLマップであることが特に便利で、簡単にリダイレクトできます： + +この例では、`example.ch`への任意のリクエストがリダイレクトされます。 `https://www.example.ch` への移動、フォルダやクエリパラメータを維持します: + +`(example.com/folder?query -> https://www.example.ch/folder?query)` + +```yaml title=".lagoon.yml の例" + - "example.ch": + annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.example.ch$request_uri + - www.example.ch +``` + +もちろん、Lagoonでホストされていない他のURLにもリダイレクトできます。これは `example.de` のリクエストを `https://www.google.com` にリダイレクトします: + +```yaml title=".lagoon.yml の例" + - "example.de": + annotations: + nginx.ingress.kubernetes.io/permanent-redirect: https://www.google.com +``` + +#### SSL設定 - `tls-acme` + +`tls-acme : ‘true’` + +- このルートに対してLagoonがLet's Encrypt証明書を発行することを示します。これがデフォルトです。 +- Let's Encryptが不要な場合、これを `tls-acme: ‘false’` に設定します。 + +`insecure` + +- `None`、`Allow`、または `Redirect` に設定できます。 +- Allowは単にHTTPとHTTPSの両方のルートを設定します（これがデフォルトです）。 +- `Redirect` は、HTTPのリクエストをHTTPSにリダイレクトします。 + +`None` + +- HTTPのルートは作成されず、リダイレクトも行われません。 + +`Hsts` + +- 設定することができます `max-age=31536000;includeSubDomains;preload`の値に。 +- スペースや他のパラメータが含まれていないことを確認します。 +- 必要なのは`max-age`パラメータのみです。この必要な max-age パラメータは、HSTS ポリシーが有効な時間を秒単位で指定します。 + +!!! 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)で詳細を読むことができます）。 + +時々、全てではなく一つの環境だけでタイプを上書きしたいかもしれません。 + +##### `service-name: service-type + +- `service-name` は上書きしたい `docker-compose.yml` のサービスの名前です。 +- `service-type` はあなたが上書きで使用したいサービスのタイプです。 + +例えば、あなたがプロダクション用の MariaDB-Galera 高可用性データベースを求めている場合、 メインと呼ばれる環境 - これが私たちの例のファイルで行っていることです: + +```yaml title=".lagoon.yml example" +environments: + main: + types: + mariadb: mariadb-galera +``` + +#### `environments.[name].templates` + +Lagoonのビルドプロセスは、`docker-compose.yml`ファイルから`lagoon.template`ラベルを確認し、サービスがカスタムテンプレートファイルが必要かどうかを確認します([docker-compose.ymlのドキュメンテーション](../concepts-basics/docker-compose-yml.md)で詳しく読むことができます)。 + +場合によっては、すべての環境ではなく、単一の環境だけでテンプレートを上書きすることが必要かもしれません: + +##### `service-name: template-file` + +- `service-name`は、`docker-compose.yml`から上書きしたいサービスの名前です。 +- `template-file`は、この環境でこのサービスに使用するテンプレートのパスと名前です。 + +```yaml title=".lagoon.yml example" +environments: + main: + templates: + mariadb: mariadb.main.deployment.yml +``` + +#### `environments.[name].rollouts` + +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" +environments: + main: + rollouts: + mariadb: statefulset +``` + +#### Cronジョブ - `environments.[name].cronjobs` + +ほとんどの場合、すべての環境で同じcronジョブを実行することは望ましくないため、各環境で実行したいジョブを明示的に定義する必要があります。私たちの例では、1時間ごとに実行されるdrushのcronジョブを作成しています。 + +`name` + +- 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時の間に一度だけ実行されます。 + +`command` + +- 実行するコマンド。タスクと同様に、このコマンドはサービスの `WORKDIR` で実行されます。Lagoonのイメージでは、これは `/app` です。 + +`service` + +- コマンドを実行するプロジェクトのサービス。ほとんどのプロジェクトでは、これはCLIサービスです。 + +`.lagoon.yml` でできることはまだたくさんあります。詳細は [`.lagoon.yml` についてのドキュメンテーション](../concepts-basics/lagoon-yml.md) をご覧ください。 + +## Drupal特有のセットアップ + +DrupalサイトをLagoonに移行する場合、全てをセットアップするためにいくつかDrupal特有のタスクを完了する必要があります。 + +### 設定ファイル + +次のステップは、設定ファイルを更新することです。Lagoonは、環境変数を使用する環境特有の設定ファイルのセットを使用するため、これらのファイルには機密情報は保存されず、全てがコミット可能で安全です。我々はさまざまな [私たちの例のリポジトリ](https://github.com/uselagoon/lagoon-examples)にあるさまざまな例のプロジェクト - もし初めての場合は、それらの一つを使用することをお勧めします。そうでない場合は、似たようなものを選んで関連する設定ファイルをコピーしてください。[環境変数に関するドキュメンテーションを確認してください](../concepts-advanced/environment-variables.md)。それらをどのように使用するかの詳細情報を得るために。 + +例のリポジトリから設定ファイルをコピーし、その後、あなたのサイトが使用していないサービスの設定を削除するためにそれを確認します（例えば、すべてのサイトがSolrやRedisを使用しているわけではありません）。特定の環境タイプの設定をオーバーライドする必要がある場合（開発環境でのキャッシュを無効にするなど）、追加の設定ファイルを設定することができます（例のリポジトリにすでにいくつかあります）、そして次の順序でロードされます： + +```php title="settings.php" + + all.settings.php + all.services.yml + production.settings.php + production.services.yml + development.settings.php + development.services.yml + settings.local.php + services.local.yml +``` + +### ``.gitignore``の設定を更新する + +`.gitignore`が設定ファイルのコミットを許可するようにすることを確認してください。Drupalは `sites/*`で出荷されます `/settings*.php`および`sites/*/services*.yml`を`.gitignore`から削除します。Lagoonを使用する場合、Gitリポジトリに機密情報を保持することはありません。 + +### DrupalのWebrootについての注意点 + +残念ながら、Drupalコミュニティでは標準化されたwebrootフォルダ名についてまだ決定していません。一部のプロジェクトではDrupalを`/web`内に、他のプロジェクトでは`/docroot`または他の場所に配置します。LagoonのDrupal設定ファイルは、Drupalが`/web`内にあると想定しています。Drupalのインストールがこれと異なる場合は、ファイルを適切に調整してください。 + +### 画像をビルドする + +まず、定義された画像をビルドする必要があります： + +```bash title="build your images" +docker-compose build +``` + +これには数分かかる場合があり、長いレスポンスが返ってきます。[これは次のようなものになるはずです](https://gist.github.com/AlannaBurke/1bdad6aab977b0994c245834e61b6b50)。 + +これにより、`docker-compose.yml`で`build:`定義を持つすべてのコンテナのDockerイメージを`docker-compose`にビルドさせます。通常、Drupalでは`cli`、`nginx`、`php`が含まれます。これは、特定のビルドコマンド（`composer install`など）を実行したり、特定の環境変数（`WEBROOT`など）を画像に注入したりするためです。 + +通常、 Drupalのコードを編集するたびにビルドする必要はありません（コードはホストからコンテナにマウントされます）、しかし再ビルドは問題ありません。さらに、Lagoonはデプロイメント時に全く同じDockerイメージをビルドするので、`docker-compose build` を再度実行するだけで、ビルドがデプロイメント時にも正常に動作するか確認できます。 + +### コンテナの起動 + +イメージがビルドされたので、コンテナを起動できます： + +```bash title="start the containers" +docker-compose up -d +``` + +次のような応答が表示されます： + +```bash title="containers started" +➜ lagoon-test git:(main) docker-compose up -d +Recreating lagoon-test_cli_1 ... done +Starting lagoon-test_redis_1 ... done +Starting lagoon-test_solr_1 ... done +Starting lagoon-test_mariadb_1 ... done +Recreating lagoon-test_php_1 ... done +Recreating lagoon-test_nginx_1 ... done +Recreating lagoon-test_varnish_1 ... done +``` + +これによりすべてのコンテナが起動します。コマンドが完了した後、`docker-compose ps`で確認して、すべて完全に起動し、クラッシュしていないことを確認できます。その応答は次のようになるはずです： + +```bash title="view running containers" +➜ lagoon-test git:(main) docker-compose ps +Name コマンド 状態 ポート +---------------------------------------------------------------------------------------- +lagoon-test_cli_1 /sbin/tini -- /lagoon/entr ... 上 9000/tcp +lagoon-test_mariadb_1 /sbin/tini -- /lagoon/entr ... 上 0.0.0.0:32768->3306/tcp +lagoon-test_nginx_1 /sbin/tini -- /lagoon/entr ... 上 8080/tcp +lagoon-test_php_1 /sbin/tini -- /lagoon/entr ... 上 9000/tcp +lagoon-test_redis_1 /sbin/tini -- /lagoon/entr ... 上 6379/tcp +lagoon-test_solr_1 /sbin/tini -- /lagoon/entr ... 上 0.0.0.0:32769->8983/tcp +lagoon-test_varnish_1 /sbin/tini -- /lagoon/entr ... 上 8080/tcp +``` + +問題がある場合は、 `docker-compose logs -f [servicename]`を使用してログを確認します。 + +### 再度 `composer install`を実行する（Composerプロジェクトのみ） + +Drupal 8+プロジェクトを実行している場合は、Composerを使用しているはずであり、すべての依存関係をダウンロードしてインストールする必要があります。cliコンテナに接続し、composer installを実行します： + +```bash title="re-run composer install" +docker-compose exec cli bash +[drupal-example]cli-drupal:/app$ composer install +``` + +これは奇妙に聞こえるかもしれませんが、 ビルドステップ中にすでに`composer install`が実行されていたので、再度これを行う理由を説明します： + +- ホスト上のファイルを編集してコンテナ内で直ちに利用できるようにするため、デフォルトの`docker-composer.yml`は全フォルダをコンテナにマウントします（これは`volumes`セクションの`.:/app:delegated`で起こります）。これはまた、Dockerビルド中にインストールされた全ての依存関係がホスト上のファイルで上書きされることも意味します。 +- ローカルでは、`composer.json`で`require-dev`として定義された依存関係にアクセスしたいと思うでしょう、一方で本番環境ではそれらは不必要なスペースを占めるだけです。そのため、Dockerfileで`composer install --no-dev`を実行し、手動で`composer install`を行います。 + +すべてがうまくいった場合、`docker-compose.yml`で定義された`LAGOON_ROUTE`を開きます（例えば`http://drupal.docker.amazee.io`）と、素敵なDrupalエラーに迎えられるはずです。心配しないでください - 今のところそれは大丈夫です、最も重要なことはDrupalサイトをロードしようと試みることです。 + +500やそれに類似するエラーが出る場合は、Composerですべてが適切にロードされていることを確認してください。 + +### ステータスの確認とDrupalのインストール + +最後にDrupalをインストールする時間ですが、その前に すべてが正常に動作することを確認したいです。そのためには、`drush status`を使ったDrushの使用をお勧めします： + +```bash title="run drush status" +docker-compose exec cli bash +[drupal-example]cli-drupal:/app$ drush status +``` + +上記のコマンドは、以下のような結果を返すはずです： + +```bash title="drush status results" +[drupal-example]cli-drupal:/app$ drush status +[notice] Missing database table: key_value +Drupal version : 8.6.1 +Site URI : http://drupal.docker.amazee.io +Database driver : mysql +Database hostname : mariadb +Database port : 3306 +Database username : drupal +Database name : drupal +PHP binary : /usr/local/bin/php +PHP config : /usr/local/etc/php/php.ini +PHP OS : Linux +Drush script : /app/vendor/drush/drush/drush +Drush version : 9.4.0 +Drush temp : /tmp +Drush configs : /home/.drush/drush.yml + /app/vendor/drush/drush/drush.yml +Drupal root : /app/web +Site path : sites/default + +``` + +!!! info "" + 次のステップに進む前に、公開鍵についてpygmyに伝える必要があるかもしれません。`Permission denied (publickey)`というエラーが表示された場合は、確認してください。 こちらでドキュメンテーションを確認してください：[pygmy - sshキーの追加](https://pygmy.readthedocs.io/en/master/usage/#adding-ssh-keys)。 + +次にDrupalをインストールします（代わりに既存のSQLファイルをインポートしたい場合は、次のステップに進んでください。しかし、初めにすべてが正常に動作していることを確認するために、クリーンなDrupalをインストールすることをお勧めします）。 + +```bash title="drush siの実行" +[drupal-example]cli-drupal:/app$ drush site-install +``` +これにより、次のような出力が表示されるはずです： + +```bash title="drush siの結果" +[drupal-example]cli-drupal:/app$ drush site-install +あなたは 'drupal' データベースのすべてのテーブルをDROPしようとしています。続行しますか？ (y/n): y +Drupalのインストールを開始します。これには時間がかかります。--notifyグローバルオプションの使用を検討してください。 +インストール完了。ユーザー名: admin ユーザーパスワード: arbZJekcqh +おめでとうございます、Drupalをインストールしました！ +``` + +これで、`LAGOON_ROUTE`で定義されたURLにアクセスして、新鮮できれいにインストールされたDrupalを見ることができます - おめでとうございます！ + +### 既存のデータベースダンプのインポート + +既に存在するDrupalサイトがある場合、そのデータベースをローカルサイトにインポートしたくなるでしょう。データベースダンプを作成する方法は多数存在し、現在のホスティングプロバイダーによります。 Drushがインストールされている場合、以下のように使用できます。 + +```bash title="drush sql-dump" +[your-existing-site]$ drush sql-dump --result-file=dump.sql +データベースのダンプがdump.sqlに保存されました。[成功] +``` + +これで、あなたの全データベースを含む`dump.sql`ファイルが作成されました。 +このファイルをローカルのGitリポジトリにコピーし、CLIに接続すると、その中にファイルが表示されます。 + +```bash title="here's our dump file" +[drupal-example] docker-compose exec cli bash +[drupal-example]cli-drupal:/app$ ls -l dump.sql +-rw-r--r-- 1 root root 5281 Dec 19 12:46 dump.sql +``` +現在のデータベースをドロップした後、ダンプをインポートできます（まだCLIに接続したままです）： + +```bash title="dump existing db and import dump file" +[drupal-example]cli-drupal:/app$ drush sql-drop +本当にデータベースdrupalのすべてのテーブルをドロップしますか？ (y/n): y +[drupal-example]cli-drupal:/app$ drush sql-cli < dump.sql +``` + +### Drupalファイルディレクトリ + +Drupalサイトには、ファイルディレクトリも含まれます。既存のサイトからファイルを移行するには、ファイルを適切なフォルダに追加するだけです（おそらく`web/sites/default/files`、`sites/default/files`など）。あなたが何を設定したかを覚えておいてください。 webroot - すべてのプロジェクトで同じではないかもしれません。 + +## デプロイ + +このガイドのすべてを行い、あなたのamazee.io管理者がすべてを設定した場合、あなたのサイトをデプロイする準備が整いました！ + +Drupalサイトをデプロイする場合は、[このデプロイガイドを参照してください](../applications/drupal/first-deployment-of-drupal.md)。 + +それ以外の全てのデプロイについては、[このデプロイガイドを参照してください](../using-lagoon-the-basics/first-deployment.md)。 \ No newline at end of file diff --git a/docs/logging/kibana-examples.ja.md b/docs/logging/kibana-examples.ja.md new file mode 100644 index 0000000000..826f23ddcb --- /dev/null +++ b/docs/logging/kibana-examples.ja.md @@ -0,0 +1,99 @@ +# Kibanaの例 + +[キバナの始め方のビデオ](https://www.elastic.co/webinars/getting-started-kibana)を見て、ログの操作に取り組む準備ができましたか？ 私たちはここで助けを提供します！ このページでは、使用できるKibanaのクエリの例を提供します。これはKibana 101のクラスではありませんが、Kibanaで何ができるのかを理解するのに役立ちます。 + +始める準備はできましたか？ よし！ + +!!! 注意 + 開始する前にテナントを選択していることを確認してください！ 左側のメニューにある `Tenant` アイコンをクリックしてそれを行うことができます。 テナントを選択したら、再度 `Discover` アイコンをクリックして始めてください。 + +## ルーターログ + +以下に、2つの一般的なログリクエストの例を示します： + +* あなたのサイトへのヒット/リクエストの総数を表示します。 +* 特定のIPアドレスからのヒット/リクエストの数を表示します。 + +### サイトへのヒット/リクエストの総数 + +* Kibanaを起動し、`Discovery` を選択しましょう（以下のスクリーンショットの＃1） +* 次にあなたのプロジェクトのルーターログ（＃2）。 +* そこから、この情報を少し絞り込みます。私たちの主な製品環境に焦点を当てましょう。 +* 検索バー（＃3）に入力します： + + `openshift_project: "製品プロジェクトの名前"` + +* これにより、すべての 指定された時間枠内での生産環境へのヒット数。 +* 右上の角(#4)で時間枠を変更できます。 +* エントリの隣の矢印(#5)をクリックすると、それが展開されて、すべてのキャプチャされた情報が表示されます。 +* フィールドの上にマウスを置いて左側の追加をクリックすることで、そのフィールドをウィンドウに追加できます(#6)。 +* また、検索バーを使用して結果をさらにフィルタリングすることもできます。 + +![Kibanaでサイトへの総ヒット数/リクエスト数を取得する方法](../images/kibana_example1.png) + +### 特定のIPアドレスからのヒット数/リクエスト数 + +上記のクエリを実行すると、サイトへの全トラフィックを一般的に見ることができますが、特定のIPアドレスに絞り込む場合はどうでしょうか？ たとえば、IPがサイトを何回ヒットしたか、そして彼らが具体的にどのページを見ていたかを見たいかもしれません。次のクエリはその手助けになるはずです。 + +まず、上記と同じクエリから始めますが、いくつかの項目を追加します。 + +* 最初に、次のフィールドを追加します：`client_ip` と `http_request`。 +* これにより、すべてのIPアドレスとそのリクエストしたページのリストが表示されます。次は、Amazee.ioページの場合の表示内容です： + +![すべてのIPアドレスとそのリクエストしたページ：]( 要求された。](../images/kibana_example2.png) + +これは良さそうですが、特定のIPアドレスからのリクエストだけを表示したい場合はどうするのでしょうか？検索条件にアドレスを追加することでフィルタリングできます。 + +* 追加する内容：`AND client_ip: "IPアドレス"`. +* これにより、その特定のIPアドレスからのヒットと、そのアドレスから要求されたページだけが結果に表示されます。ここに私たちのAmazee.ioウェブサイトの例を示します： + +![特定のIPアドレスからのヒット。](../images/kibana_example3.png) + +## コンテナログ + +コンテナログは、特定のコンテナとプロジェクトのすべての`stout`と`sterr`メッセージを表示します。特定のコンテナからログを取得し、そのコンテナ内で特定のエラー番号を見つける例を示します。 + +### コンテナからのログ + +特定のコンテナ（php、nginxなど）のログを見たいですか？このセクションが役立ちます！NGINXのログを見ることに焦点を当ててみましょう。 + +* Kibanaを開き、Discoverを選択します（下のスクリーンショットの＃1）。 +* そこから、プロジェクトのコンテナログを選択します（＃2）。 +* 検索バー（＃3）に移動し、`kubernetes.container_name: "nginx"`を入力します。 +* これにより、プロジェクトのすべてのNGINXログが表示されます。 エントリー（＃4）の隣の矢印をクリックすると、そのエントリーが展開され、収集したすべての情報が表示されます。 +* ビューにメッセージフィールドとレベルフィールドを追加しましょう。左側の「追加」をクリックすることでそれができます（＃5）。 +* 画面の右上隅（＃6）で時間枠を変更することができます。以下の例では、過去4時間のログを見ています。 + +![](../images/kibana_example4.png) + +### ログの特定のエラー + +あなたのNGINXコンテナでいくつの500 Internal Serverエラーが発生したかを知りたいですか？検索クエリを変更することでそれが可能です。もし検索するなら： + +`kubernetes.container_name: "nginx" AND message: "500"` + +それはNGINXコンテナの500エラーメッセージのみを表示します。あなたが望む任意のコンテナで任意のエラーメッセージを検索することができます！ + +## 可視化 + +Kibanaは、可視化やグラフを作成するオプションも提供します。私たちは、上記で使用した同じクエリを使用して、1ヶ月間のヒット数/リクエスト数を示すチャートを作成します。 + +1. Kibanaの左側にあるVisualizeをクリックします。 +2. 青いプラス記号をクリックします。 +3. この例では、垂直バーチャートを選択します。 +4. プロジェクトのルーターログを選択します . +5. バケツの下のX軸をクリックし、間隔を日次に設定した日付ヒストグラムを選択します +6. 成功!! これで、毎日のトラフィックを示す素晴らしい棒グラフが表示されるはずです。 + +!!! 注意 + 右上隅のデータの適切な時間枠を選択することを確認してください。 + +以下は、日次ヒットの視覚化チャートの例です: + +![日次ヒット視覚化チャート.](../images/kibana_example5.png) + +また、視覚化（および検索）を保存できることにも注意してください！ それにより、将来的にそれらにより迅速にアクセスできます。 そして、各アカウントが自分のKibanaテナントを持っているため、検索や視覚化は他のアカウントと共有されません。 + +## トラブルシューティング + +<iframe width="560" height="315" src="https://www.youtube.com/embed/BuQo5J0Qc2c" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> \ No newline at end of file diff --git a/docs/logging/logging.ja.md b/docs/logging/logging.ja.md new file mode 100644 index 0000000000..3b4be2131a --- /dev/null +++ b/docs/logging/logging.ja.md @@ -0,0 +1,40 @@ +# ロギング + +LagoonはKibanaを介して以下のログにアクセスを提供します: + +* Kubernetes Routersからのログ。これには次の全てのHTTPおよびHTTPSリクエストが含まれます: + * ソースIP + * URL + * パス + * HTTP動詞 + * Cookies + * ヘッダー + * ユーザーエージェント + * プロジェクト + * コンテナ名 + * 応答サイズ + * 応答時間 +* コンテナからのログ: + * `stdout`と`stderr`メッセージ + * コンテナ名 + * プロジェクト +* Lagoonのログ: + * Webhooksの解析 + * ビルドログ + * ビルドエラー + * その他のLagoon関連ログ +* アプリケーションログ: + * Drupalの場合: Drupal Watchdogからのログを受け取るために、[Lagoon Logs](https://www.drupal.org/project/lagoon_logs)モジュールをインストールします。 + * Laravelの場合: [Laravel用Lagoon Logs](https://github.com/amazeeio/laravel_lagoon_logs)パッケージをインストールします。 + * その他のワークロード: + * ログを`udp://application-logs.lagoon.svc:5140`に送信します。 + * ログがJSONエンコードされたオブジェクトとして構造化されていることを確認します。 + * `type`フィールドにはKubernetesの名前空間の名前(`$LAGOON_PROJECT-$LAGOON_ENVIRONMENT`)が含まれていることを確認します。 + +ログにアクセスするには、KibanaルートのURLを取得するためにLagoonの管理者に確認してください（amazee.ioの場合、これは[https://logs.amazeeio.cloud/](https://logs.amazeeio.cloud/)です）。 logs.amazeeio.cloud/)。 + +各Lagoonユーザーアカウントは独自のログインを持ち、アクセス権があるプロジェクトのログのみを見ることができます。 + +各Lagoonユーザーアカウントはまた、独自の**Kibana Tenant**を持っており、これは保存された検索やビジュアライゼーションが他のアカウントと共有されないことを意味します。 + +Kibanaの使用方法について詳しく知りたい場合は、こちらをご覧ください：[https://www.elastic.co/webinars/getting-started-kibana](https://www.elastic.co/webinars/getting-started-kibana)。 \ No newline at end of file diff --git a/docs/other-tools/client-libraries.ja.md b/docs/other-tools/client-libraries.ja.md new file mode 100644 index 0000000000..09b10c3b17 --- /dev/null +++ b/docs/other-tools/client-libraries.ja.md @@ -0,0 +1,26 @@ +# ラグーンクライアントライブラリ + +ラグーンエコシステムのツール開発に興味がある場合、いくつかのライブラリが役立つかもしれません。 + +## Golang +### Machinery + +Machineryライブラリは、ラグーンのツールライブラリの中で最も積極的にサポートされ、開発されています。 +これは、主に（しかし排他的ではなく）APIとのやり取りのための、私たちのすべてのgolang基盤のツールタイプにわたるすべての基本操作の中央ストアです。 + +[https://github.com/uselagoon/machinery/](https://github.com/uselagoon/machinery/) + + +## PHP + +PHPの統合を探しているなら、php-sdkがあなたの仕事の出発点として良いかもしれません。 + +[https://github.com/uselagoon/lagoon-php-sdk](https://github.com/uselagoon/lagoon-php-sdk) + +# サードパーティライブラリ + +## Ansible + +ラグーンとのやり取りのための頻繁に更新され、拡張されているAnsibleライブラリ。 + +[https://github.com/salsadigitalauorg/lagoon_ansible_collection](https://github.com/salsadigitalauorg/lagoon_ansible_collection) \ No newline at end of file diff --git a/docs/resources/faq.ja.md b/docs/resources/faq.ja.md new file mode 100644 index 0000000000..2650b149a8 --- /dev/null +++ b/docs/resources/faq.ja.md @@ -0,0 +1,174 @@ +# よくある質問 + +## ラグーンの管理者にどのように連絡すればよいですか？ + +専用のSlackチャネルが設定されているはずなので、それを利用してコミュニケーションを取ることができます - もしない場合や、どのように連絡すればよいか忘れてしまった場合は、[support@amazee.io](mailto:support@amazee.io)に連絡して下さい。 + +## バグを見つけました！🐞 + +バグやセキュリティ問題を見つけた場合は、その内容を[support@amazee.io](mailto:support@amazee.io)に送ってください。GitHubの問題として報告しないでください。 + +## amazee.ioのラグーンを利用したホスティングサービスに興味があります + +それは素晴らしいニュースです！[sales@amazee.io](mailto:sales@amazee.io)までメールでお問い合わせいただけます。 + +## バックアップをどのように復元することができますか？ + +ファイルやデータベースのバックアップを提供しており、通常は最大で24時間ごとに取得しています。これらのバックアップはオフサイトで保存されています。 + +日次バックアップは最大7つ、週次バックアップは最大4つ保持しています。 + +バックアップの復元や回復が必要な場合は、お気軽にチケットを提出するか、チャットでメッセージを送ってください。喜んでお手伝いします！ + +## データベースダンプをどのようにダウンロードすることができますか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/bluTyxKqLbw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in -ピクチャー" allowfullscreen></iframe> + +## 私は無効なSSL証明書エラーが出ています + +まず最初に試すべきことは、[私たちのドキュメンテーションに記載されているSSLに関する情報](../concepts-basics/lagoon-yml.md#ssl-configuration-tls-acme)を参照してみてください。 + +その手順に従ってもまだエラーが出る場合は、チケットを送信するか、チャットでメッセージを送ってください。私たちはあなたの問題を解決するのをお手伝いします。 + +## Drushコマンドを実行するときに "Array" エラーが出ています + +これはDrushバージョン8.1.16と8.1.17で多く見られたバグで、エラーは次のようなものでした： + +```bash +コマンドを正常に実行できませんでした（返却：Array [error] +( +[default] => Array +( +[default] => Array +( +[driver] => mysql +[prefix] => Array +( +[default] => +) +, code: 0) +エラー：ソース@mainのデータベースレコードが見つかりませんでした [error] +``` + +Drushをアップグレードすると、この問題は解消されるはずです。我々は強く、バージョン8.3またはそれ以降を使用することをお勧めします。Drushをアップグレードすれば、コマンドは動作するはずです！ + +## Kibanaログにアクセスしようとすると、Internal Server Errorが表示されています + +<iframe width="560" height="315" src="https://www.youtube.com/embed/BuQo5J0Qc2c" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; パニックになる必要はありません！これは通常、テナントが選択されていないときに発生します。これを修正するには、次の手順を実行してください： + +1. Kibanaの左側のメニューで「テナント」に移動します。 +2. 自分のテナント名をクリックします。 +3. 「テナントの変更」とあなたのテナントの名前というポップアップウィンドウが表示されます。 +4. 「ディスカバー」タブに戻り、クエリを再度試みます。 + +これでログを見ることができるはずです。 + +## 任意の環境にSSHで接続できない + +任意の環境にSSHで接続できません。次のメッセージが表示されます： `Permission denied (publickey)`。`drush sa`を実行すると、エイリアスが返されません。 + +これは通常、Pygmyの問題を示しています。Pygmyのトラブルシューティングドキュメントはこちらで見つけることができます：[https://pygmy.readthedocs.io/en/master/troubleshooting/](https://pygmy.readthedocs.io/en/master/troubleshooting/) + +## ビルドのステータスを確認するにはどうすればいいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/PyrlZqTjf68" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## どのようにして追加しますか クロンジョブとは？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/Yd_JfDyfbR0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## 新しいルートを追加するには？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/vQxh87F3fW4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ルートを削除するには？ + +Lagoonは、`.lagoon.yml`からルートが削除されたことをデプロイ時に検出します。デプロイログを確認して、ルートが自動的に削除されたか、それらを削除する方法について確認してください。 + +## `pygmy status`を実行すると、キーがロードされません + +SSHキーをpygmyにロードする必要があります。方法はこちら：[https://pygmy.readthedocs.io/en/master/ssh_agent](https://pygmy.readthedocs.io/en/master/ssh_agent) + +## `drush sa`を実行すると、エイリアスが返されません + +これは通常、Pygmyに問題があることを示しています。Pygmyのトラブルシューティングドキュメントはこちらで見つけることができます：[https://pygmy.readthedocs.io/en/master/troubleshooting]( https://pygmy.readthedocs.io/en/master/troubleshooting) + +## 「drushはより機能的な環境が必要です」というメッセージが表示され、デプロイが失敗する + +これは通常、プロジェクトにアップロードされたデータベースがないことを意味します。[プロジェクトにデータベースを追加するためのステップバイステップガイド](../applications/drupal/first-deployment-of-drupal.md#5-synchronize-local-database-to-the-remote-lagoon-environment)を参照してください。 + +## Pygmyを起動すると「アドレスはすでに使用中」エラーが表示されますか？ + +`ユーザーランドプロキシの起動エラー: listen tcp 0.0.0.0:80: bind: address already in use Error: failed to start containers: amazeeio-haproxy` + +これは既知のエラーです！ほとんどの場合、ポート80ですでに何かが実行されていることを意味します。次のクエリを実行することで犯人を見つけることができます: + +```bash title="" +netstat -ltnp | grep -w ':80' +``` + +これにより、ポート80で実行中のすべてをリストアップします。ポート80で動作しているプロセスを終了させます。ポート80が解放されると、Pygmyはこれ以上のエラーなく起動するはずです。 + +## プロジェクトのブランチ/PR環境/本番環境をどのように変更できますか？ + +その変更はLagoon APIを使用して行うことができます！この変更に関するドキュメンテーションは[GraphQLのドキュメンテーションで見つけることができます](../interacting/graphql-queries)。 .md#updating-objects). + +## リダイレクトを追加するにはどうすればいいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/rWb-PkRDhY4" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## プロジェクト/グループに新しいユーザー（およびSSHキー）を追加するにはどうすればいいですか？ + +これはLagoon APIを介して行うことができます。この変更のステップドキュメンテーションは[私たちのGraphQLドキュメンテーション](../interacting/graphql-queries.md#allowing-access-to-the-project)で見つけることができます。 + +## 環境は完全に削除して、プロジェクトに大きなコード変更を展開できますか？ + +環境は各デプロイで完全にゼロから構築され、古いデータベースとファイルを削除してコードをプッシュすると、新鮮なクリーンなビルドが得られます。再同期を忘れないでください！ + +GraphQLを介して環境を削除することも可能です。指示は[私たちのGraphQLドキュメンテーション](../interacting/graphql-queries.md#deleting-environments)で見つけることができます。 + +## 新しい環境変数を表示させるにはどうすればいいですか？ + +GraphQLを介してプロダクション環境にランタイム環境変数を追加したら、デプロイを行うだけで新しい環境変数を表示させることができます。 あなたの環境に変更が反映されるようになります。 + +## Lagoon環境にSFTPでファイルを送信/取得するにはどうすればいいですか？ + +クラウドホスティングのお客様は、以下の情報を使用してLagoon環境にSFTPで接続することができます： + +* サーバーホスト名: `ssh.lagoon.amazeeio.cloud` +* ポート: 32222 +* ユーザー名: &lt;プロジェクト-環境-名&gt; + +ユーザー名は、接続する環境の名前になります。最も一般的なパターンは_`PROJECTNAME-ENVIRONMENT`_です。 + +また、新しいLagoon Syncツールについてもチェックしてみてください。ここで詳細を読むことができます: [https://github.com/uselagoon/lagoon-sync](https://github.com/uselagoon/lagoon-sync) + +認証は、SSH公開鍵と秘密鍵の認証を通じて自動的に行われます。 + +## Let's Encryptを使用したくない。私がインストールしたいSSL証明書があります + +それについては確かにお手伝いできます。自分のSSL証明書を手に入れたら、遠慮なくチケットを提出するか、チャットでメッセージを送ってください。喜んでお手伝いします！以下のファイルを送信する必要があります： + +* 証明書キー (.key) +* 証明書ファイル (.crt) +* 中間証明書 (.crt) + +また、[`.lagoon.yml`で`tls-acme`オプションをfalseに設定する](必要があります。 ../concepts-basics/lagoon-yml.md#ssl-configuration-tls-acme)。 + +## Lagoonに外部ボリューム（EFS/Fuse/SMB/etc）をマウントすることは可能ですか？ + +外部ボリュームのマウントは、コンテナ内部で完全に処理する必要があり、Lagoonはこの種の接続をプラットフォームの一部として提供していません。 + +開発者は、必要なパッケージをコンテナにインストール（[Dockerfile](https://docs.docker.com/engine/reference/builder/)経由）し、ボリュームマウントが[事前または事後のロールアウトタスク](../concepts-basics/lagoon-yml.md#tasks)経由で接続されていることを確認することでこれを処理できます。 + +## Lagoonのビルドを停止する方法はありますか？ + +長時間実行されているビルドを停止したい場合は、サポートに連絡する必要があります。現在、ビルドはクラスタへの管理者アクセス権を持つユーザーのみが停止できます。 + +## Elasticsearch\Solrサービスをウェブサイトにインストールしました。ブラウザからUI（ポート9200/8983）へのアクセスをどのように取得できますか？ +<!-- markdown-link-check-disable-next-line --> +デプロイされた環境でウェブサービス（NGINX/Varnish/Node.js）のみを公開することをお勧めします。ローカルでは、これらのサービスのポートマッピングを`docker-compose ps`で確認して取得できます。 `, そして [`http://localhost`](http://localhost/)`:<port>` をブラウザで読み込みます。 + +## ここでは答えられない質問があります + +[Discord](https://discord.gg/te5hHe95JE) または [uselagoon@amazee.io](mailto:uselagoon@amazee.io) のメールアドレスでチームに連絡することができます。 \ No newline at end of file diff --git a/docs/resources/glossary.ja.md b/docs/resources/glossary.ja.md new file mode 100644 index 0000000000..3f9179bbbf --- /dev/null +++ b/docs/resources/glossary.ja.md @@ -0,0 +1,115 @@ +--- +description: >- + これらの用語やサービスの多くは人々にとって新しいものであることを知っています - そのために私たちは、より多くの人々がアクセスできるように、ここで全ての用語を定義しました。 +--- + +# 用語集 + +| 用語 | 定義 | +| :--- | :--- | +| Access Mode | 永続ボリュームにどのようにアクセスするかを制御します。| +| Active/Standby | Active/Standby deploymentsは、一般にblue/green deploymentsとも呼ばれ、本番環境のコンテンツをシームレスに切り替える方法です。 | +| Ansible| インフラストラクチャをコード化可能にするオープンソースのソフトウェアツールスイート。| +| AWS | Amazon Web Services | +| Amazon S3 Glacier | 長期保存のための安全かつ低コストなS3ストレージ。 | +| BitBucket | Atlassianが所有するGitホスティングで、そのツールと統合します。| +| Brew | HomebrewはOSXのパッケージマネージャーです。 | +| CA | 信頼できるエンティティである証明書認証局（Certificate Authority）は、Secure Sockets Layer (SSL)証明書を発行します。| +| CDN | コンテンツ配信ネットワーク - キャッシングによるコンテンツ配信 | +| CI | 継続的インテグレーション | +| CIDR | クラスレス・インタードメイン・ルーティング - IPアドレスの割り当て方法 | +| CLI | コマンドラインインターフェース | +| Cluster | サーバーやVMの統一されたグループで、一緒に分散管理され、高い可用性を確保するために一つのエンティティをサービスします。 | 可用性、負荷分散、およびスケーラビリティ。| +| CMS | コンテンツ管理システム | +| Cron job | cronコマンドラインユーティリティは、Unix系オペレーティングシステムのジョブスケジューラです。ソフトウェア環境の設定と維持を行うユーザーは、cronを使用してジョブ（cronジョブとも呼ばれる）をスケジュールし、固定の時間、日付、または間隔で定期的に実行します。| +| Composer | パッケージマネージャー | +| DDEV | Drupalコミュニティで人気のあるDockerベースのPHP開発環境。 | +| DDoS | 分散型サービス拒否 | +| DNS | ドメインネームシステム | +| Docker | Linuxの機能を使用し、アプリケーションのデプロイメントを自動化するコンテナエンジン。 | +| Docker Compose | YAMLファイルを介してDockerアプリケーションを定義し、実行するツール。 | +| Drupal | オープンソースのコンテンツ管理システム | +| Drush | Drupalのコマンドラインシェル。 | +| EC2 | Amazon Elastic Compute Cloud | +| Elasticsearch | オープンソースの検索エンジン。分散型、マルチテナント対応の全文検索エンジンを提供し、スキーマフリーのJSONドキュメントとウェブインターフェースを提供します。 | +| Galera | トランザクショナルデータベースのための汎用的な同期マルチマスター複製ライブラリ。 | +| Git | 無料のオープンソースの分散型バージョン管理システム。 | +| Git Hash /SHA | 各コミットを識別する生成された文字列。SHA-1アルゴリズムを使用します | +| GitHub | Gitを使用した独自のバージョン管理ホスティング会社。マイクロソフトの子会社で、Gitの分散バージョン管理とソースコード管理機能を全て提供し、さらに追加機能も提供します。 | +| GitLab | CI機能を備えたWebベースのGitリポジトリマネージャー。 | +| Grafana | オープンソースの分析および監視ソリューション。 | +| GraphQL | APIのためのオープンソースのデータクエリと操作言語、および既存のデータでクエリを満たすためのランタイム。 | +| Harbor | ロールベースのアクセス制御でイメージを保護し、イメージの脆弱性をスキャンし、信頼できるイメージとして署名するオープンソースのコンテナイメージレジストリ。 | +| Helm | Kubernetesのパッケージマネージャーで、Kubernetesアプリケーションを管理するのを助けます。 | +| Helm Charts | Helm Chartsは、最も複雑なKubernetesアプリケーションを定義、インストール、アップグレードするのを助けます。 | +| HTTP | ハイパーテキスト転送プロトコル。HTTPはWorld Wide Webによって使用される基礎的なプロトコルで、メッセージがどのようにフォーマットされ、伝送され、Webサーバーとブラウザがさまざまなコマンドに対してどのようなアクションを取るべきかを定義します。 | +| IAM | AWS Identity and Access Management（IAM）は、AWSリソースへのアクセスを安全に制御するのに役立つウェブサービスです。| +| IDE | 統合開発環境は、ソフトウェア開発のための包括的な施設をコンピュータプログラマーに提供するソフトウェアアプリケーションです。IDEには通常、少なくともソースコードエディタ、ビルド自動化ツール、デバッガが含まれています。| +| Ingress controller | Ingress controllerは、Kubernetes（および他のコンテナ化された）環境用の特化したロードバランサーです。 | +| IPTables | Linuxカーネルファイアウォールを設定するためのコマンドラインユーティリティ。 | +| Jenkins | オープンソースの自動化サーバー。 | +| JWT | JSON Web Token。 | +| k3s | 高可用性、認定済みのKubernetesディストリビューション。 | +| k3d | k3dは、Docker内でk3sを実行するための軽量ラッパーです。 | +| k8s | Kubernetesの数字記号（K + 8文字 + s） | +| k8up | K8upは、k8s/OpenShiftクラスター上のストレージとアプリのバックアップを処理するバックアップオペレーターです。 | +| Keycloak | オープンソースのアイデンティティおよびアクセス管理システム。 | +| Kibana | Elasticsearch用のオープンソースのデータ可視化プラグイン。Elasticsearchクラスターにインデックスされたコンテンツの上で視覚化機能を提供します。 | +| KinD | Docker内のKubernetes - Dockerコンテナー「ノード」を使用してローカルのKubernetesクラスターを実行するツール。Kindは主にKubernetes自体のテスト用に設計されましたが、ローケル開発やCIにも使用できます。| +| kubectl | Kubernetesクラスターに対してコマンドを実行するためのKubernetesのコマンドラインツール。| +| Kubernetes | コンテナ化されたアプリケーションのデプロイメント、スケーリング、および管理を自動化するためのオープンソースシステム。 | +| Lagoon | Kubernetesのためのオープンソースのアプリケーションデリバリープラットフォーム。 | +| Lagoonize | あなたのアプリをLagoonで実行するための設定変更。 | +| Lando | Dockerを基盤にした無料のオープンソース、クロスプラットフォーム、ローカル開発環境およびDevOpsツール。 | +| Laravel | モデル-ビュー-コントローラー（MVC）のアーキテクチャパターンに従い、Symfonyを基にした無料のオープンソースPHPウェブフレームワーク。 | +| Let's Encrypt | 無料の自動化されたオープンな認証局（CA）。 | +| MariaDB | MySQLの関係データベース管理システムのコミュニティ開発版で、商業的にサポートされており、GNU General Public Licenseの下で無料でオープンソースソフトウェアであることを維持することを目指しています。 | +| Master node | 集合体の中の単一のノード。 | クラスタ状態を管理するプロセスが稼働しています。 | +| マイクロサービス | アプリケーションをより専門的な部分に分割する実践。各部分はAPIやHTTPのようなRESTインターフェースを介して互いに通信します。 | +| MongoDB | MongoDBはクロスプラットフォームのドキュメント指向データベースプログラムです。NoSQLデータベースプログラムとして分類され、MongoDBはスキーマ付きのJSON風ドキュメントを使用します。 | +| マルチテナント | ソフトウェアの単一インスタンスがサーバー上で動作し、複数のテナント（共通のアクセス権限を共有するユーザーグループ）にサービスを提供します。ソフトウェアは各テナントにリソースの一部を提供するように設計されています。 | +| MVC | モデル-ビュー-コントローラ - アプリケーションを3つの主要な論理コンポーネント：モデル、ビュー、コントローラに分けるアーキテクチャパターン。これらの各コンポーネントは、アプリケーションの特定の開発側面を処理するように構築されています。 | +| MySQL | MySQLはオープンソースのリレーショナルデータベース管理システムです。 | +| NGINX | NGINXは、リバースプロキシ、ロードバランサ、メールプロキシ、HTTPキャッシュとしても使用できるウェブサーバーです。 | +| ノード | 単一のEC2インスタンス（ | AWS virtual machine | AWSバーチャルマシン | +| Node.js | ブラウザーの外部でJavaScriptコードを実行するオープンソースのクロスプラットフォームのJavaScriptランタイム環境。 | +| Open source | ソースコードがライセンスの下にリリースされ、著作権者がユーザーにソフトウェアを研究、変更、および任意の目的で誰にでも配布する権利を付与するコンピュータソフトウェアの一種。オープンソースソフトウェアは、共同の公開方式で開発される可能性があります。 | +| OpenSearch | コミュニティ主導の、Apache 2.0ライセンスのオープンソースの検索および分析スイートで、データの取り込み、検索、視覚化、分析を容易にします。| +| OpenShift | DockerとKubernetesをエンタープライズにもたらすコンテナアプリケーションプラットフォーム。 | +| PHP | PHP（Personal Home Page）は、Web開発のために元々設計された汎用プログラミング言語です。 | +| PhpStorm | PHPとWebプロジェクトのための開発ツール（IDE）。| +| Pod | 同じホスト上に一緒にデプロイされるコンテナのグループ。 Kubernetesが扱う基本単位。 | +| PostgreSQL | 拡張性と技術標準の準拠を強調した無料のオープンソースのリレーショナルデータベース管理システム。 | +| Public/Private Key | 公開鍵/秘密鍵 | の暗号化は、誰もが知る公開鍵とメッセージの受信者だけが知る秘密鍵または秘密鍵を使用する暗号システムです。| +| Puppet | オープンソースのソフトウェア設定管理およびデプロイメントツール。 | +| PV | PersistentVolume - 管理者がプロビジョニングした、またはStorage Classesを使用して動的にプロビジョニングされたクラスタ内のストレージの一部。| +| PVC | Persistent Volume Claim - ユーザーによるストレージ要求。 | +| Pygmy | amazee.ioが提供するローカル開発システム。 | +| Python | Pythonはオープンソースで、解釈され、高レベルで、一般的なプログラミング言語です。 | +| RabbitMQ | オープンソースのメッセージブローカーソフトウェア。 | +| RBAC | ロールベースのアクセス制御 | +| RDS | 関係データベースサービス | +| Redis | データベース、キャッシュ、ストリーミングエンジン、メッセージブローカーとして使用されるオープンソースのインメモリデータストア。 | +| Restic |オープンソースのバックアッププログラム。 | +| ROX | KubernetesのアクセスモードReadOnlyMany - ボリュームは多くのノードで読み取り専用としてマウントできます。 | +| Ruby | 複数のプログラミングパラダイムをサポートする解釈型の高レベル汎用プログラミング言語。プログラミングの強調点として設計されました。 生産性とシンプルさ。Rubyでは、すべてがオブジェクトであり、プリミティブなデータ型も例外ではありません。| +| RWO | KubernetesのアクセスモードReadWriteOnce - ボリュームは単一のノードによって読み書き可能としてマウントできます。ReadWriteOnceアクセスモードでは、同じノード上で実行されている複数のポッドがボリュームにアクセスできます。| +| RWOP | KubernetesのアクセスモードReadWriteOncePod - ボリュームは単一のPodによって読み書き可能としてマウントできます。クラスタ全体でただ一つのポッドのみがそのPVCを読み書きできるようにしたい場合は、ReadWriteOncePodアクセスモードを使用します。これはCSIボリュームとKubernetesバージョン1.22+でのみサポートされています。| +| RWX | KubernetesのアクセスモードReadWriteMany - ボリュームは多数のノードによって読み書き可能としてマウントできます。 | +| S3 | Amazon Simple Storage Service。 | +| SBOM | ソフトウェアの部品表。 | +| SHA-1 | Secure Hash Algorithm 1、入力を取り、160ビットのハッシュ値（通常は40桁の16進数で表示）を生成するハッシュ関数。これはアメリカ国家安全保障局によって設計され、米国連邦情報処理標準となっています。 | +| Solr | Javaで書かれたオープンソースのエンタープライズ検索プラットフォーム。 | +| SSH | セキュア | ソケットシェル | ネットワークプロトコルで、管理者がリモートコンピュータに安全にアクセスできるようにするもの。 | +| SSL | セキュアソケットレイヤー | +| ストレージクラス | ストレージクラスは、Kubernetesの管理者が提供する「ストレージのクラス」を記述する方法を提供します。異なるクラスは、サービス品質レベル、バックアップポリシー、またはクラスター管理者によって決定される任意のポリシーにマップされるかもしれません | +| Symfony | SymfonyはPHPのWebアプリケーションフレームワークであり、再利用可能なPHPコンポーネント/ライブラリのセットで、Drupal 8以降はSymfonyに基づいています。 | +| TCP | トランスミッションコントロールプロトコル、アプリケーションプログラムがデータを交換できるネットワーク会話を確立し維持する方法を定義する標準。 | +| TLS | トランスポート層セキュリティ | +| Trivy | CIに適したシンプルで包括的なコンテナの脆弱性スキャナ。 | +| TTL | Time to liveまたはhop limitは、コンピュータまたはネットワーク内のデータの寿命または生存期間を制限するメカニズムです。 | +| Uptime Robot | アップタイム監視サービス。 | +| Varnish | 強力なオープンソースのHTTPエンジン/リバースHTTPプロキシで、ユーザが初めてWebページのコピーをキャッシュ（または保存）することでWebサイトの速度を上げることができます。 | visits. | 訪問数. | +| VM | バーチャルマシン | +| Webhook | Webhookは、GitHub、GitLab、Bitbucketなどのアプリが他のアプリケーションに即時データを提供し、何か（プルリクエストなど）に対して行動を起こす方法です。 | +| YAML | YAML Ain't Markup Language - YAMLは人間が読みやすいデータシリアライゼーション言語です。設定ファイルや、データが保存または送信されるアプリケーションで一般的に使用されます。| \ No newline at end of file diff --git a/docs/resources/tutorials-and-webinars.ja.md b/docs/resources/tutorials-and-webinars.ja.md new file mode 100644 index 0000000000..dc43eaa7cc --- /dev/null +++ b/docs/resources/tutorials-and-webinars.ja.md @@ -0,0 +1,79 @@ +# チュートリアル、ウェビナー、ビデオ + +## ラグーンウェビナー入門 + +\[[スライド](https://docs.google.com/presentation/d/1o90YQtXUofe2g9yU6R3awSK3F0iMpKLQm1ZZcrDUni0/edit#slide=id.g41f995a6b3_0_32)\] + +<iframe width="560" height="315" src="https://www.youtube.com/embed/GS4b5mbjbzM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ラグーンと共に進化するLando + +<iframe width="560" height="315" src="https://www.youtube.com/embed/au4F2KKwyOM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ウェビナー - ラグーンインサイト + +<iframe width="560" height="315" src="https://www.youtube.com/embed/eiIaKPWxbpM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ラグーンデプロイメントデモ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/XiaH7gqUXWc" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; クリップボード-ライト; 暗号化メディア; ジャイロスコープ; ピクチャーインピクチャー" allowfullscreen></iframe> + +## Lagoonを使って複数のDrupalサイトを管理する方法 + +\[[スライド](https://docs.google.com/presentation/d/12mSmZDcvanHkidfEaanpH8UpbiR-u_c8F26FEsDyWBA/edit#slide=id.g41f995a6b3_0_32)\] + +<iframe width="560" height="315" src="https://www.youtube.com/embed/R2tIivVvExQ" title="YouTubeビデオプレイヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## Kubernetesウェビナー101 + +\[[スライド](https://docs.google.com/presentation/d/1LiPqKjlYMAIt-WI_FCQqi8io8rcmpbNbduKBHdpww8A/edit#slide=id.g41f995a6b3_0_32)\] + +<iframe width="560" height="315" src="https://www.youtube.com/embed/-jHcurNDJ4Y" title="YouTubeビデオプレイヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## Kubernetesウェビナー102 + +\[[スライド](https://docs.google.com/presentation/d/1hY2Y65EZZVWwbdwBAOR2AkW3i7u11C6ar3lI-kSVQBs/edit)\] + +<iframe width="560" height="315" src="https://www.youtube.com/embed/SxJmMkNR9xs" title="YouTubeビデオプレイヤー" frameborder="0" allow=" 加速度計; 自動再生; クリップボード-ライト; 暗号化メディア; ジャイロスコープ; ピクチャ・イン・ピクチャ" allowfullscreen></iframe> + +## サーバーサイドレンダリングのベストプラクティス：私たちが月に1億1000万回ヒットする分離型ウェブサイトを運営する方法 + +<iframe width="560" height="315" src="https://www.youtube.com/embed/eZJz4VbM1E4" title="YouTubeビデオプレーヤー" frameborder="0" allow="加速度計; 自動再生; クリップボード-ライト; 暗号化メディア; ジャイロスコープ; ピクチャ・イン・ピクチャ" allowfullscreen></iframe> + +## ラグーン：フルDrupalサポート付きのオープンソースDockerビルド＆デプロイメントシステム + +<iframe width="560" height="315" src="https://www.youtube.com/embed/3RnZPrjvoqo" title="YouTubeビデオプレーヤー" frameborder="0" allow="加速度計; 自動再生; クリップボード-ライト; 暗号化メディア; ジャイロスコープ; ピクチャ・イン・ピクチャ" allowfullscreen></iframe> + +## Kibanaで内部サーバーエラーを修正するにはどうすればいいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/BuQo5J0Qc2c" title="YouTubeビデオプレーヤー" frameborder="0" allow="加速度計; 自動再生; クリップボード-ライト; 暗号化メディア; ジャイロスコープ; ピクチャ・イン・ピクチャ" allowfullscreen></iframe> + +## 新しいルートを追加するにはどうすればいいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com /embed/vQxh87F3fW4" title="YouTubeビデオプレーヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ビルドのステータスはどのように確認しますか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/PyrlZqTjf68" title="YouTubeビデオプレーヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## Lagoonにリダイレクトを追加するにはどうすればよいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/rWb-PkRDhY4" title="YouTubeビデオプレーヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## データベースダンプをダウンロードするにはどうすればよいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/bluTyxKqLbw" title="YouTubeビデオプレーヤー" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## クロンジョブを追加するにはどうすればよいですか？ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/Yd_JfDyfbR0" title="YouTubeビデオプレーヤー" <iframe width="560" height="315" src="https://www.youtube.com/embed/wbWz_WeaKcI" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## KubernetesにWebアプリケーションをデプロイする - Toby Bellwood | Techweek21トーク + +<iframe width="560" height="315" src="https://www.youtube.com/embed/OQJagjT2hRE" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## Covid-19中に前例のない規模で対処する - Sean Hamlin| Techweek21トーク + +<iframe width="560" height="315" src="https://www.youtube.com/embed/-18ZRHEARmY" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## ローカルからライブへのSilverstripe on Lagoon -Thom Toogood | Techweek21トーク \ No newline at end of file diff --git a/docs/using-lagoon-advanced/active-standby.ja.md b/docs/using-lagoon-advanced/active-standby.ja.md new file mode 100644 index 0000000000..cd4d99a725 --- /dev/null +++ b/docs/using-lagoon-advanced/active-standby.ja.md @@ -0,0 +1,196 @@ +# アクティブ/スタンバイ + +<iframe width="560" height="315" src="https://www.youtube.com/embed/urq15chLvzQ" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> + +## 設定 + +既存のプロジェクトをアクティブ/スタンバイに対応させるためには、Lagoon APIを使用してプロジェクト設定をいくつか設定する必要があります。 + +* `productionEnviromment`は、現在アクティブな環境のブランチ名に設定する必要があります。 +* `standbyProductionEnvironment`は、現在スタンバイ中の環境のブランチ名に設定する必要があります。 + +```graphql title="プロジェクト設定の更新" +mutation updateProject { + updateProject(input:{ + id:1234 + patch:{ + productionEnvironment:"production-brancha" + standbyProductionEnvironment:"production-branchb" + } + }){ + standbyProductionEnvironment + name + productionEnvironment + } +} +``` + +### `.lagoon.yml` - `production_routes` + +`.lagoon.yml`ファイルでプロジェクトをアクティブ/スタンバイに設定するためには、`active`環境にアタッチしたいルートと`standby`にアタッチしたいルートを`production_routes`セクションに設定する必要があります。 環境。アクティブ/スタンバイの切り替え時には、これらのルートは2つの環境間で移動します。 + +もし2つのプロダクション環境、`production-brancha`と`production-branchb`があり、現在アクティブなプロダクション環境が`production-brancha`であるなら： + +* `production_routes.active`の下のルートはあなたを`production-brancha`に向かわせます。 +* `production_routes.standby`の下のルートはあなたを`production-branchb`に向かわせます。 + +アクティブ/スタンバイの切り替え時には、ルートが交換されます： + +* `production_routes.active`の下のルートはあなたを`production-branchb`に向かわせます。 +* `production_routes.standby`の下のルートはあなたを`production-brancha`に向かわせます。 + +```yaml title=".lagoon.yml" +production_routes: + active: + routes: + - nginx: + - example.com: + tls-acme: 'false' + - active.example.com: + tls-acme: 'false' + standby: + routes: + - nginx: + - standby.example.com: + tls-acme: 'false' +``` + +!!! 情報 + セクション`environments..routes`の下にあるルートは、アクティブ/スタンバイの一部として移動されません。これらのルートは常に定義された環境に付属しています。特定のルートを必要とする場合は、そのルートが アクティブ/スタンバイ切り替え中に移行した場合、それらを環境セクションから削除し、それがアクティブルートかスタンバイルートであるべきか特定の `production_routes` セクションに配置してください。[ `.lagoon.yml` のルートについて詳しくはこちらを参照してください。](../concepts-basics/lagoon-yml.md#routes) + +## 切り替えイベントのトリガー + +### UI経由 + +環境ルートの切り替えをトリガーするには、Lagoon UIでスタンバイ環境を訪れ、`Switch Active/Standby environments`というラベルのボタンをクリックします。アクションを確認するように求められます。 + +確認されると、スイッチの進行状況を確認することができるタスクページに移動します。 + +### API経由 + +環境を切り替えるイベントをトリガーするには、次のGraphQL変異を実行します。これにより、Lagoonがプロセスを開始します。 + +```graphql title="Active Standby Switch" +mutation ActiveStandby { + switchActiveStandby( + input:{ + project:{ + name:"drupal-example" + } + } + ){ + id + remoteId + } +} +``` + +切り替えイベントがトリガーされると、現在のアクティブ環境の `tasks` タブにタスクが作成されます。ここでスイッチの状態を確認することができます。 + +`switchActiveStandby` 変異からの `remoteId` を使用して、 タスクのステータスも確認することができます。 + +```graphql title="タスクステータスの確認" +query getTask { + taskByRemoteId(id: "<remoteId>") { + id + name + created + started + completed + status + logs + } +} +``` + +## `drush`エイリアス + +デフォルトでは、プロジェクトは以下のエイリアスが作成され、プロジェクトでアクティブ/スタンバイが有効になっている場合に利用できます。 + +* `lagoon-production` +* `lagoon-standby` + +`lagoon-production`エイリアスは`productionEnvironment`として定義されているサイトを指し、`lagoon-standby`は常に`standbyProductionEnvironment`として定義されているサイトを指します。 + +これらのエイリアスは、プロジェクトの更新によって設定を変更することができます。ただし、それらを変更すると、それらに依存するスクリプトを更新する必要があるかもしれません。 + +```graphql title="Drushエイリアスの更新" +mutation updateProject { + updateProject(input:{ + id:1234 + patch:{ + productionAlias:"custom-lagoon-production-alias" + standbyAlias:"custom-lagoon-standby-alias" + } + }){ + productionAlias + name + standbyAlias + } +} +``` + +## Active/Standbyの無効化 + +これら2つのブランチのうち、どちらを主な環境として進めていくかを決定する必要があります。その後、 それがアクティブなブランチとして設定されていることを確認してください（例：`production-branchb`）。 + +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`を削除して、環境のアクティブ/スタンバイラベルを消去します。 + +```graphql title="アクティブ/スタンバイをオフにする" +mutation updateProject { + updateProject(input:{ + id:1234 + patch:{ + productionEnvironment:"production-branchb" + standbyProductionEnvironment:"" + } + }){ + standbyProductionEnvironment + name + productionEnvironment + } +} +``` + +## ノート + +アクティブ/スタンバイトリガーが実行されたとき、`productionEnvironment`と`standbyProductionEnvironments`はLagoon API内で切り替わります。両方の環境はまだ`production`環境タイプとして分類されています。`productionEnvironment`はどちらが`active`とラベル付けされているかを決定するために使用します。環境タイプの違いについての詳細は、[`environment types`のドキュメンテーション](../concepts-advanced/environment-types.md)をご覧ください。 + +```graphql title="GraphQLを使って環境を取得する" +query projectByName { + projectByName(name:"drupal-example"){ + productionEnvironment + standbyProductionEnvironment + } +} +``` + +環境を切り替える前： + +```graphql title="環境クエリの結果" +{ + "data": { + "projectByName": { + "productionEnvironment": "production-brancha", + "standbyProductionEnvironment": "production-branchb" + } + } +} +``` + +環境を切り替えた後： + +```graphql title="結果 の環境クエリ" +{ + "data": { + "projectByName": { + "productionEnvironment": "production-branchb", + "standbyProductionEnvironment": "production-brancha" + } + } +} +``` diff --git a/docs/using-lagoon-advanced/blackfire.ja.md b/docs/using-lagoon-advanced/blackfire.ja.md new file mode 100644 index 0000000000..466cb3389d --- /dev/null +++ b/docs/using-lagoon-advanced/blackfire.ja.md @@ -0,0 +1,45 @@ +# ブラックファイア + +## 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でBlackfireを使用するためには、以下の3つの環境変数を定義する必要があります： + +| 環境変数 | デフォルト | 説明 | +| :--- | :--- | :--- | +| `BLACKFIRE_ENABLED` | \(設定なし\) | `TRUE`または`true`に設定することで`blackfire`拡張を有効にする。 | +| `BLACKFIRE_SERVER_ID` | \(設定なし\) | Blackfire.ioから提供されるBlackfire Server IDに設定する。`BLACKFIRE_ENABLED`を`true`に設定する必要がある。 | +| `BLACKFIRE_SERVER_TOKEN` | \(設定なし\) | Blackfire.ioから提供されるBlackfire Server Tokenに設定する。`BLACKFIRE_ENABLED`を`true`に設定する必要がある。 | + +## Blackfireのローカル使用 + +Lagoon ImagesでBlackfireをローカルで使用する場合、上記の環境変数をPHPコンテナに設定します。以下はDrupalアプリケーションの例です： + +```yaml title="docker-compose.yml" + +services: + +[[snip]] + + php: + [[snip]] + + environment: + << : *default-environment # 上部で定義された環境変数を読み込む + BLACKFIRE_ENABLED: TRUE +``` BLACKFIRE_SERVER_ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + BLACKFIRE_SERVER_TOKEN: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +``` + +コンテナを再起動した後、[Blackfireブラウザプラグイン](https://blackfire.io/docs/profiling-cookbooks/profiling-http-via-browser)または[Blackfire CLI](https://blackfire.io/docs/profiling-cookbooks/profiling-http-via-cli)を通じてプロファイルを作成することができるはずです。 + +## Blackfireのリモート使用 + +デプロイされたLagoon環境でBlackfireを使用するためには、同じ環境変数を設定する必要があります。この時、[Lagoonに環境変数を追加する](../concepts-advanced/environment-variables.md)方法の一つを通じて設定します。重要：ローカル開発用に`docker-compose.yml`に設定された環境変数はLagoonのリモート環境では使用されません！ + +## デバッグ + +PHPコンテナで動作しているBlackfireエージェントは、通常のコンテナログとしてログを出力します。これは`docker-compose logs`またはリモート環境のLagoon Logging Infrastructureを通じて見ることができます。 + +デフォルトでは、ログはレベル`3`（情報）に設定されていますが、環境変数`BLACKFIRE_LOG_LEVEL`を使ってレベルを`4`（デバッグ）に上げることで、より多くの情報を生成することができます。 デバッグ出力。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/custom-tasks.ja.md b/docs/using-lagoon-advanced/custom-tasks.ja.md new file mode 100644 index 0000000000..e703235863 --- /dev/null +++ b/docs/using-lagoon-advanced/custom-tasks.ja.md @@ -0,0 +1,179 @@ +# カスタムタスク + +Lagoonでは、環境、プロジェクト、グループレベルでカスタムタスクを定義することができます。現在、これはGraphQL APIを通じて行われ、UIで公開されています。 + +## カスタムタスクの定義 + +タスクを定義する際には、いくつかのことを決定する必要があります。 + +### どのタスクを実行しますか？ + +ほとんどの場合、実行するカスタムタスクは、アプリケーションのコンテナの一つでシェルで実行されるものです。 + +例えば、Node.jsアプリケーションでは、`node`コンテナで`yarn audit`を実行することに興味があるかもしれません。この場合、コマンドは単純に`yarn audit`となります。 + +### このタスクはどこで実行されますか？ + +このタスクがどこで実行されるかを定義する必要があります -- これは二つのことを意味します。まず、どのプロジェクトまたは環境でタスクを実行するか、そして、どのサービスで行うかです。 + +たとえば、`yarn audit`タスクを特定のプロジェクト（この例ではプロジェクトのIDを42としましょう）の任意の環境で実行可能にしたいと考えているとしましょう。そのため、タスク定義を作成する際には、下記で説明するように、プロジェクトのIDを指定します。 + +2つ目の質問は、どの環境をタスクの対象とするかということです。あなたが設定するときに あなたのプロジェクトを設定する際に、[`docker-compose.yml`](../concepts-basics/docker-compose-yml.md)でいくつかのサービスを指定します。このサービス名を使用して、コマンドが実際にどこで実行されるかを決定します。 + +### このタスクを実行できるのは誰ですか？ + +タスクシステムへのアクセス権はプロジェクトロールに対応した3つのレベルがあります。ゲスト、デベロッパー、メンテナー -- 最も制限的なものから最も制限の少ないものまで、各ロールはそれより下のロールで定義されたタスクを呼び出すことができます（デベロッパーはゲストのタスクを見ることができ、メンテナーはすべてのタスクを見ることができます）。 + +## タスクの定義 + +タスクは`addAdvancedTaskDefinition`ミューテーションを呼び出すことで定義されます。重要なことは、これは単にタスクを_定義するだけで、それを呼び出すわけではありません。それは単にそれを環境で実行可能にするだけです。 + +概念的には、呼び出しは次のようになります。 + +```graphql title="新しいタスクを定義する" +mutation addAdvancedTask { + addAdvancedTaskDefinition(input:{ + name: string, + confirmationText: string, + type: [COMMAND|IMAGE], + [project|environment]: int, + description: string, + service: string, + command: string, + advancedTaskDefinitionArguments: [ + { + name: "ENVIROMENT_VARIABLE_NAME", + displayName: "Friendly Name For "Variable", + type: [文字列 | 環境ソース名 | 自己を除く環境ソース名] + } + ] + }) { + ... on AdvancedTaskDefinitionImage { + id + name + description + service + image + confirmationText + advancedTaskDefinitionArguments { + type + range + name + displayName + } + ... + } + ... on AdvancedTaskDefinitionCommand { + id + name + description + service + command + advancedTaskDefinitionArguments { + type + range + name + displayName + } + ... + } + } +} +``` + +フィールド`name`と`description`は直訳です。これらは主にUIで使用されるタスクの名前と説明です。 + +`type`フィールドについては説明が必要です - 現時点では、プラットフォーム管理者のみが`IMAGE`タイプのコマンドを定義できます - これは、既存のサービスを対象にするのではなく、特定のタスクイメージをタスクとして実行することを可能にします。しかし、ほとんどのタスクは`COMMAND`タイプになります。 + +`[project|environment]`フィールドのセットは、タスクを`project`または`environment`に関連付ける（使用するキーによります）ことで、その値が id. 私たちが`yarn audit`のために考えているケースでは、IDが`42`の`project`を対象としていることを明示します。 + +私たちがタスクでターゲットにしたいサービスを`service`フィールドに置き、`command`は私たちが実行したい実際のコマンドです。 + +### タスクに渡される引数 + +Lagoon UI経由でタスクを呼び出すユーザーにより柔軟性を提供するために、タスク引数の定義をサポートしています。これらの引数はテキストボックスまたはドロップダウンとして表示され、タスクを呼び出すために必要です。 + +以下は、2つの引数を設定する方法の例です。 + +```graphql title="タスク引数の定義" +advancedTaskDefinitionArguments: [ + { + name: "ENV_VAR_NAME_SOURCE", + displayName: "環境源", + type: ENVIRONMENT_SOURCE_NAME + + }, + { + name: "ENV_VAR_NAME_STRING", + displayName: "エコー値", + type: STRING + } + ] + }) +``` + +このフラグメントは、システムが現在サポートしている両方のタイプの引数を示しています。 +最初の`ENV_VAR_NAME_SOURCE`は`ENVIRONMENT_SOURCE_NAME`タイプの例で、これはUIのユーザーにプロジェクト内の異なる環境のドロップダウンを提示します。もし私たちが許可したくない場合は、 呼び出し環境で実行するタスク（例えば、他の環境からデータベースをインポートしたい場合など）については、`ENVIRONMENT_SOURCE_NAME_EXCLUDE_SELF`を使用して環境リストを制限することができます。 +二つ目の`ENV_VAR_NAME_STRING`は`STRING`型で、ユーザーにテキストボックスを記入するように促します。 + +ユーザーが選択した値は、タスクが実行されたときに`COMMAND`型のタスクで環境変数として利用可能になります。 + +![タスク引数](../images/custom-task-arguments.png) + + +### システム全体のタスク + +プラットフォームの管理者は、システム全体のタスクを登録することができます。これらのタスクはすべての環境で表示され、ユーザーがそれらを呼び出す権限によって制限されます。 + +システム全体のタスクを作成する方法は、他のタスクタイプとほぼ同じですが、2つの例外があります。 + +まず、`addAdvancedTaskDefinition`ミューテーションの中で`systemWide: true`フィールドを設定します。 + +次に、`groupName`、`project`、または`environment`を指定してい*ない*ことを確認します - これらのフィールドは特定のコンテキストをターゲットにするために使用されるため、これらを指定すると目的を逸脱することになります。 + + +### 確認 + +`confirmationText`フィールドにテキストがあると、ユーザーがタスクを実行できるようになる前に、UIに確認モーダルとともに表示されます。 ![タスク確認](../images/custom-task-confirm.png) + +## タスクの呼び出し + +タスクが定義されていると、タスクはLagoon UIのタスクドロップダウンに表示されるはずです。 + +また、`invokeTask` ミューテーションを使用してGraphQL apiからも呼び出すことができます。 + +```graphql title="タスクの呼び出し" +mutation invokeTask { + invokeRegisteredTask(advancedTaskDefinition: int, environment: int) { + status + } +} +``` + +`invokeTask`は常に_特定の環境_でタスクを呼び出すことに注意してください。 + +## 例 + +では、`yarn audit`の例を設定してみましょう。 + +```graphql title="タスク定義ミューテーション" +mutation runYarnAudit { + addAdvancedTaskDefinition(input:{ + name:"Run yarn audit", + project: 42, + type:COMMAND, + permission:DEVELOPER, + description: "Runs a 'yarn audit'", + service:"node", + command: "yarn audit"}) + { + id + } +} +``` + +これにより、私たちのプロジェクト（42）のタスクが定義されます。これを実行すると、タスク定義のIDが返されます（たとえば、`9`とします） + +このタスクは、`DEVELOPER`または`MAINTAINER`の役割を持つ誰でもUIから実行できるようになります。 + +![タスクリスト](../images/task-yarn-audit.png) \ No newline at end of file diff --git a/docs/using-lagoon-advanced/deploytarget-configs.ja.md b/docs/using-lagoon-advanced/deploytarget-configs.ja.md new file mode 100644 index 0000000000..2187d5dbfb --- /dev/null +++ b/docs/using-lagoon-advanced/deploytarget-configs.ja.md @@ -0,0 +1,163 @@ +# DeployTarget設定 + +DeployTarget設定は、プロジェクトが複数のクラスタにデプロイする方法を定義する方法です。この機能は、本番ワークロードを実行するために専用のクラスタと、開発ワークロードを実行するための別のクラスタがある場合に便利です。 + +これらの設定は、単に本番/開発の分割に限定されるわけではないため、プロジェクトは特定のクラスタを複数ターゲットにできる可能性があります。 + +DeployTarget設定の基本的な考え方は、プロジェクトが複数のクラスタ間でどのようにデプロイできるかを簡単に定義する方法であり、環境が有効かどうかを確認する既存の方法を利用します。 + +## 重要な情報 + +DeployTarget設定を利用してプロジェクトを設定する方法について説明する前に、知っておくべきことがいくつかあります。 + +1. 環境には、それらがどのDeployTarget（KubernetesまたはOpenShift）で作成されたかを識別するための新たな2つのフィールドが利用可能になりました。 + + 1. `kubernetesNamespacePattern` + 2. `kubernetes` + +2. 特定のDeployTargetに一度デプロイされた環境は、DeployTarget設定やプロジェクト設定が変更されても、常にこのターゲットにデプロイされます。 3. これは、DeployTargetの設定を変更して異なるクラスターで新しい環境を作成するのを防ぐことで、既存の環境に一定の安全性を提供します。 + 4. これはLagoonの一部であり、特にDeployTarget設定に限定された新機能です。 + +2. デフォルトでは、プロジェクトにDeployTargetの設定が関連付けられていない場合、そのプロジェクトは既存の方法を続けて使用してどの環境をデプロイするかを決定します。これには以下のフィールドが使用されます。 + + 1. `branches` + 2. `pullrequests` + 3. `kubernetesNamespacePattern` + 4. `kubernetes` + +3. プロジェクトにいかなるDeployTargetの設定が追加されると、そのプロジェクトのすべての将来のデプロイメントはこれらの設定を使用します。プロジェクトで定義されているものは無視され、DeployTargetの設定が使用されていることをユーザーに通知するために上書きされます。 +4. DeployTargetの設定は重み付けされており、これは大きい重みのDeployTarget設定が小さい重みのものより優先されることを意味します。 + + 1. クエリで返される順序が、環境がデプロイされるべき場所を決定するために使用される順序です。 + +5. アクティブ/スタンバイ環境は、同じ クラスターなので、DeployTarget設定はそれらの環境を同じターゲットにデプロイできるように設定する必要があります。 +6. Lagoonの`promote`機能を活用するプロジェクトは、DeployTarget設定が`destination`環境では無視されることを認識していなければなりません。 + + 1. 宛先環境は常に`source`環境がある同じターゲットにデプロイされますので、DeployTarget設定はこの`source`環境に対して正しく設定する必要があります。 + 2. 安全のため、`source`と`destination`の環境を同じDeployTarget設定のブランチ正規表現で定義するのが最善です。 + +## 設定 + +プロジェクトをDeployTarget設定を使用するように設定するためには、まずプロジェクトに設定を追加することが第一歩です。 + +以下のGraphQLの突然変異を使用できます。この特定の例では、プロジェクトID 1のプロジェクトにDeployTarget設定を追加します。 +これにより、名前が`main`と一致するブランチのみがデプロイされ、`pullrequests`は`false`に設定されます。 +これは、他のブランチがこの特定のターゲットにデプロイすることができず、プルリクエストもこの特定のターゲットにデプロイされないことを意味します。 +`deployTarget`はID 1で、これはKubernetesになる可能性があります。 特定の地域や特定の種類のワークロード（製品版または開発版）向けにクラスターを指定します。 + +```GraphQL title="DeployTargetの設定" +mutation addDeployTargetConfig{ + addDeployTargetConfig(input:{ + project: 1 + branches: "main" + pullrequests: "false" + deployTarget: 1 + weight: 1 + }){ + id + weight + branches + pullrequests + deployTargetProjectPattern + deployTarget{ + name + id + } + project{ + name + } + } +} +``` + +!!! 情報 + `deployTarget`はLagoon API内のKubernetesまたはOpenShift IDのエイリアスです + +また、複数のDeployTarget設定を構成することも可能です。 + +以下のGraphQL変異を使用できます。この特定の例では、上記と同じプロジェクトにDeployTarget設定を追加します。 + +これにより、`^feature/|^(dev|test|develop)$` と正規表現マッチするブランチのみがデプロイされ、`pullrequests` は `true` に設定されているため、すべてのプルリクエストがこのターゲットに到達します。 + +この例では、ターゲットとなるクラスタはID 2で、これは`main`ブランチに上で定義されたものとは全く異なるKubernetesクラスタです。 + +```GraphQL title="DeployTargetの設定" +mutation addDeployTargetConfig{ + add DeployTargetConfig(input:{ + project: 1 + branches: "^feature/|^(dev|test|develop)$" + pullrequests: "true" + deployTarget: 2 + weight: 1 + }){ + id + weight + branches + pullrequests + deployTargetProjectPattern + deployTarget{ + name + id + } + project{ + name + } + } +} +``` + +これらがプロジェクトに追加されると、以下のクエリを使用してプロジェクトのすべてのDeployTarget設定を返すことができます。 + +```GraphQL title="Get DeployTargets" +query deployTargetConfigsByProjectId{ + deployTargetConfigsByProjectId(project:1){ + id + weight + branches + pullrequests + deployTargetProjectPattern + deployTarget{ + name + id + } + project{ + name + } + } +} +# result: +{ + "data": { + "deployTargetConfigsByProjectId": [ + { + "id": 1, + "weight": 1, + "branches": "main", + "pullrequests": "false", + "deployTargetProjectPattern": null, + "deployTarget": { + "name": "production-cluster", + "id": 1 + }, + "project": { + "name": "my-project" + } + }, + { + "id": 2, + "weight": 1, + "branches": "^feature/|^(dev|test|develop)$", + "pullrequests": "true", + "deployTargetProjectPattern": null, + "deployTarget": { + "name": "development-cluster", + "id": 2 + }, + "project": { + "name": "my-project" + } + } + ] + } +} +``` \ No newline at end of file diff --git a/docs/using-lagoon-advanced/index.ja.md b/docs/using-lagoon-advanced/index.ja.md new file mode 100644 index 0000000000..602f810da5 --- /dev/null +++ b/docs/using-lagoon-advanced/index.ja.md @@ -0,0 +1,5 @@ +# ラグーンの高度な利用方法 + +このセクションでは、ラグーンのより高度な機能と機能について説明します。ラグーンが初めての方は、まず[ラグーンの基本的な使用方法](../using-lagoon-the-basics/index.md)から始めてください。 + +助けが必要な場合は、ラグーンの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティやメンテナーに問い合わせてください。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/nodejs.ja.md b/docs/using-lagoon-advanced/nodejs.ja.md new file mode 100644 index 0000000000..d4a84b567c --- /dev/null +++ b/docs/using-lagoon-advanced/nodejs.ja.md @@ -0,0 +1,104 @@ +# Node.jsのグレースフルシャットダウン + +Node.jsには統合されたウェブサーバーの機能があります。さらに[Express](https://expressjs.com/)を使用すると、これらの機能をさらに拡張することができます。 + +残念ながら、Node.jsはデフォルトで自身をシャットダウンする処理をあまりうまく処理しません。これはコンテナ化されたシステムで多くの問題を引き起こします。最大の問題は、Node.jsのコンテナがシャットダウンするように指示されると、すぐにすべてのアクティブな接続を強制終了し、それらを適切に停止させることができないことです。 + +この部分では、アクティブなリクエストを処理し終えてから、適切にシャットダウンするようにNode.jsを教える方法を説明します。 + +例として、Expressを使用したシンプルなNode.jsサーバーを使用します： + +```javascript title="app.js" +const express = require('express'); +const app = express(); + +// 全てのリクエストに5秒のディレイを追加。 +app.use((req, res, next) => setTimeout(next, 5000)); + +app.get('/', function (req, res) { + res.send("Hello World"); +}) + +const server = app.listen(3000, function () { + console.log('Example app listening on port 3000!'); +}) +``` + +これは、ウェブサーバーが `localhost:3000` にアクセスされたときに "Hello World" を表示します。処理に時間がかかるリクエストをシミュレートするため、応答に5秒の遅延があることに注意してください。 いくつかのコンピューティング時間。 + +## パートA: リクエストの完了を許可する + +上記の例を実行し、リクエストが処理されている間（5秒以内）にNode.jsプロセスを停止すると、Node.jsサーバーはすぐに接続を切断し、ブラウザはエラーを表示することになります。 + +Node.jsサーバーに、実際に自身を停止する前にすべてのリクエストが完了するのを待つべきだと伝えるために、以下のコードを追加します： + +```javascript title="Graceful Shutdown" +const startGracefulShutdown = () => { + console.log('Expressのシャットダウンを開始...'); + server.close(function () { + console.log('Expressがシャットダウンしました。'); + }); +} + +process.on('SIGTERM', startGracefulShutdown); +process.on('SIGINT', startGracefulShutdown); +``` + +これは基本的に `server.close()` を呼び出し、これによりNode.js HTTPサーバーに対して以下の指示が出されます： + +1. これ以上のリクエストを受け付けない。 +2. すべての実行中のリクエストを完了する。 + +これは `SIGINT` （ `CTRL + C` を押したとき）または `SIGTERM` （プロセスを終了するための標準信号）で行います。 + +この小さな追加により、Node.jsはすべてのリクエストが完了するのを待つようになり、その後自身を停止します。 + +もし私たちがNode.jsをコンテナ化された環境で実行していないならば、おそらく 数秒後に実際にNode.jsサーバーを終了する追加のコードを含めたいと考えています。なぜなら、一部のリクエストが非常に長くかかるか、あるいは全く停止しない可能性があるからです。これはコンテナ化されたシステム内で実行されているため、コンテナが停止しない場合、DockerとKubernetesは数秒後（通常は30秒後）に`SIGKILL`を実行します。これはプロセス自体では処理できないため、私たちにとっては関心事ではありません。 + +## パートB：YarnとNPMの子生成問題 + +もし私たちがパートAだけを実装した場合、良い経験を得られるでしょう。現実の世界では、多くのNode.jsシステムがYarnやNPMで構築されており、これらはNode.jsにパッケージ管理システムだけでなく、スクリプト管理も提供します。 + +これらのスクリプト機能を使うと、アプリケーションの起動を簡単にすることができます。多くの`package.json`ファイルが以下のようになっていることが分かります： + +```javascript title="package.json" +{ + "name": "node", + "version": "1.0.0", + "main": "index.js", + "license": "MIT", + "dependencies": { + "express": "^4.15.3" + }, + "scripts": { + "start": "node index.js" + } +} +``` + +そして、定義された`scripts`セクションを使って、以下のようにアプリケーションを起動するだけで済みます： + +```bash title="Start application" +yarn start または + +```bash title="アプリケーションの起動" +npm start +``` + +これは便利で、開発者の生活を楽にします。したがって、私たちはDockerfilesの中でも同じものを使用しています。 + +```text title=".dockerfile" +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を使用してアプリケーションを開始するのではなく、直接 `node` を使用することです。 + +```text title=".dockerfile" +CMD ["node", "index.js"] +``` + +これにより、Node.jsは適切に終了し、Docker/KubernetesはNode.jsが終了するのを待つことができます。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/private-repositories.ja.md b/docs/using-lagoon-advanced/private-repositories.ja.md new file mode 100644 index 0000000000..74759b4531 --- /dev/null +++ b/docs/using-lagoon-advanced/private-repositories.ja.md @@ -0,0 +1,9 @@ +# プライベートリポジトリ + +1. デプロイキーに、あなたのGitHub/GitLab/BitBucketのGitリポジトリへのアクセス権を与えます。 +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 +``` \ No newline at end of file diff --git a/docs/using-lagoon-advanced/project-default-users-keys.ja.md b/docs/using-lagoon-advanced/project-default-users-keys.ja.md new file mode 100644 index 0000000000..265bdf180d --- /dev/null +++ b/docs/using-lagoon-advanced/project-default-users-keys.ja.md @@ -0,0 +1,11 @@ +# プロジェクトデフォルトユーザーとSSHキー + +Lagoonプロジェクトが作成されると、デフォルトで関連するSSH "プロジェクトキー"が生成され、その秘密キーがプロジェクトのCLIポッド内で利用可能になります。サービスアカウント`default-user@project`も作成され、プロジェクトへの`MAINTAINER`アクセスが付与されます。SSH "プロジェクトキー"は、その`default-user@project`に添付されます。 + +これにより、任意の環境のCLIポッド内から同じプロジェクト内の他の任意の環境にSSHでアクセスすることが可能になります。このアクセスは、環境間でデータベースを同期化するなど、コマンドラインからタスクを実行するために使用されます（例：drush `sql-sync`）。 + +`MAINTAINER`ロールについての詳しい情報は、[RBAC](../interacting/rbac.md)のドキュメンテーションにあります。 + +## プロジェクトキーの指定 + +プロジェクトを作成する際にSSH秘密キーを指定することは可能ですが、これにはセキュリティ上の問題があるため推奨されません。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/setting-up-xdebug-with-lagoon.ja.md b/docs/using-lagoon-advanced/setting-up-xdebug-with-lagoon.ja.md new file mode 100644 index 0000000000..6d9ca6dc47 --- /dev/null +++ b/docs/using-lagoon-advanced/setting-up-xdebug-with-lagoon.ja.md @@ -0,0 +1,113 @@ +# LagoonでのXdebugの設定 + +## コンテナでXdebug拡張機能を有効にする + +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. 環境変数を変更した後は、コンテナを再構築して再起動することを確認してください。 +- **リモート** (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) +デバッガを有効化するためには、以下の簡単な手順を参照してください。 + +### CLI + +`php-cli` イメージは、Xdebugが有効になっているときには _常に_ Xdebugを有効化するように設定されています。 +したがって、他に行う必要があることは何もありません。任意のPHPスクリプトを実行すると、デバッグセッションが開始されます。 + +### Web + +[ブラウザ拡張機能をインストールする](https://xdebug.org/docs/step_debug#browser-extensions) +ことで、有効化クッキーを設定/解除します。 + +デバッグを開始したいウェブサイトに有効化クッキーが設定されていることを確認してください。 + +## PHPStormの設定 + +1. PHPStormはデフォルトで正しく設定されています。 +2. ツールバーの“**Start Listening for PHP Debug Connections**”アイコンをクリックします。 +3. ウェブページを読み込むか、Drushコマンドを実行します。 +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サイトの例は以下の通りです： + + ```json title="launch.json" + "pathMappings": { + "/app": "${workspaceFolder}", + }, + ``` + +4. Visual Studio Codeの**Run**タブで、 + “**Listen for Xdebug**”の隣にある緑色の矢印をクリックします。 +5. ウェブページをロードするか、Drushコマンドを実行します。 + +## トラブルシューティング + +- Xdebug拡張がロードされていることを確認します。Drupal + サイトでこれを行う最善の方法は、PHPのステータスページを確認することです。Xdebugとそのすべての設定についてのセクションが見つかるはずです。 + +![phpinfo results](../images/phpinfo.png) + +- 以下の設定を確認します: + +| ディレクティブ | ローカル値 | +|:-------------------|:------------------------------------------| +| xdebug.mode | debug | +| xdebug.client_host | `host.docker.internal` または あなたのIPアドレス | +| xdebug.client_port | 9003 | + +- 実行中のコンテナ内で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.client_host`が正しく設定されていることを確認します。Docker for Macでのローカルデバッグの場合、この値は`host.docker.internal`であるべきです。リモートデバッグの場合、この値はあなたのIPアドレスであるべきです。この値が正しく決定されなかった場合は、`DOCKERHOST`環境変数を設定することで上書きできます。 +- Landoをローカルで使用する場合、CLIから実行されるスクリプトをデバッグするためには、まず`lando ssh`を介してCLIコンテナにSSHでログインする必要があります。`lando drush`または`lando php`を実行してもデバッグできません。 + +### Mac固有のトラブルシューティング + +- Docker for Macのネットワーキングが壊れていないことを確認します。 ホストマシンで + `nc -l 9003`を実行し、その後新しいターミナルウィンドウで次のように実行します。 + + ```bash title="MacのDockerネットワーキングを確認" + docker-compose run cli nc -zv host.docker.internal 9003 + ``` + + 次のようなメッセージが表示されます。 + `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)から引用）。 + + ```yaml title="Linux向けのdocker-compose.ymlの修正" + services: + cli: + extra_hosts: + host.docker.internal: host-gateway + php: + extra_hosts: + host.docker.internal: host-gateway + ``` + +## Xdebug 2 + +古いイメージを使用している場合は、まだXdebugバージョン2を使用しているかもしれません。このページのすべての情報は依然として適用されますが、一部の設定名と値は変更されています： + +| v3 | v2 | | +|:-------------------|:----------------------|:----------------------------------------------| +| xdebug.mode | xdebug.remote_enabled | オン | +| xdebug.client_host | xdebug.remote_host | `host.docker.internal` またはあなたのIPアドレス | +| xdebug.client_port | xdebug.remote_port | 9000 | \ No newline at end of file diff --git a/docs/using-lagoon-advanced/simplesaml.ja.md b/docs/using-lagoon-advanced/simplesaml.ja.md new file mode 100644 index 0000000000..af986d98af --- /dev/null +++ b/docs/using-lagoon-advanced/simplesaml.ja.md @@ -0,0 +1,162 @@ +# SimpleSAML + +## SimpleSAMLphp + +これは、SimpleSAMLphpをプロジェクトに追加し、それをNGINX経由で提供するための設定を変更する方法の例です。 + +### 必要条件 + +SimpleSAMLphpをプロジェクトに追加します： + +```bash title="Composerを使用してプロジェクトにSimpleSAMLphpを追加する" +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`も必要です。 + +`config.php`で次のLagoonの値を設定します： + +SimpleSAMLphpにアクセスするための基本URLパス： + +```php title="config.php" + 'baseurlpath' => 'https://YOUR_DOMAIN.TLD/simplesaml/', +``` + +セッションをデータベースに保存する： + +```php title="config.php" + 'store.type' => 'sql', + + 'store.sql.dsn' => vsprintf('mysql:host=%s;port=%s;dbname=%s', [ + getenv('MARIADB_HOST'), + getenv('MARIADB_PORT'), + getenv('MARIADB_DATABASE'), + ]), +``` + +他の設定を好みに合わせて変更します： + +* ログと証明書のパスを確認します。 +* SimpleSAMLphpを保護します。 ダッシュボード。 +* ロギングのレベルを設定します。 +* `technicalcontact`と`timezone`を設定します。 + +`authsources.php`にauthsources（IdPs）を追加します。例を参照してください： + +```php title="authsources.php" + 'default-sp' => [ + 'saml:SP', + + // このSPのエンティティID。 + 'entityID' => 'https://YOUR_DOMAIN.TLD', + + // このSPが連絡すべきIdPのエンティティID。 + // NULL/未設定にすることも可能で、その場合、ユーザーには利用可能なIdPのリストが表示されます。 + 'idp' => 'https://YOUR_IDP_DOMAIN.TLD', + + // ディスカバリーサービスへのURL。 + // NULL/未設定にすることも可能で、その場合、組み込みのディスカバリーサービスが使用されます。 + 'discoURL' => null, + + 'NameIDFormat' => 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient', + + 'certificate' => '/app/conf/simplesamlphp/certs/saml.crt', + 'privatekey' => '/app/conf/simplesamlphp/certs/saml.pem', + 'redirect.sign' => TRUE, + 'redirect.validate' => TRUE, + + 'authproc' => [ + 50 => [ + 'class' => 'core:AttributeCopy', + 'urn:oid:1.3.6.1.4.1.5923.1.1.1.6' => 'eduPersonPrincipalName', + ], + 51 => [ + 'class' => 'core:AttributeCopy', + 'urn:oid:2.5.4.42' => 'givenName', + ], + 52 => [ + 'class' => 'core ':AttributeCopy'、 + 'urn:oid:2.5.4.4' => 'sn'、 + ]、 + 53 => [ + 'class' => 'core:AttributeCopy'、 + 'urn:oid:0.9.2342.19200300.100.1.3' => 'mail'、 + ]、 + ]、 + ]、 + +``` + +`saml20-idp-remote.php`にIdPメタデータを追加します。例を参照してください： + +```php title="saml20-idp-remote.php" +<?php +/** + * SimpleSAMLphpのためのSAML 2.0 リモートIdPメタデータ。 + * + * このファイルから使用しないIdPsを削除することを忘れないでください。 + * + * 参照：https://simplesamlphp.org/docs/stable/simplesamlphp-reference-idp-remote + */ + +/** + * いくつかのIdP。 + */ +$metadata['https://YOUR_IDP_DOMAIN.TLD'] = [ + 'entityid' => 'https://YOUR_IDP_DOMAIN.TLD'、 + 'name' => [ + 'en' => 'Some IdP'、 + ]、 + 'description' => 'Some IdP'、 + + ... + +]; +``` + +ビルドプロセスで、設定ファイルをSimpleSAMLphpにコピーします： + +* `vendor/simplesamlphp/simplesamlphp/config/authsources.php` +* `vendor/simplesamlphp/simplesamlphp/config/config.php` +* `vendor/simplesamlphp/simplesamlphp/metadata/saml20-idp-remote.php` + +### SimpleSAMLphpのためのNGINX confを作成します + +`lagoon/nginx/location_prepend_simplesamlphp.conf`というファイルを作成します： + +```bash title="location_prepend_simplesamlphp.conf" +location ^~ /simplesaml { + alias /app/vendor/simplesamlphp/simplesaml php/www; + + location ~ ^(?<prefix>/simplesaml)(?<phpfile>.+?\.php)(?<pathinfo>/.*)?$ { + include fastcgi_params; + fastcgi_pass ${NGINX_FASTCGI_PASS:-php}:9000; + fastcgi_param SCRIPT_FILENAME $document_root$phpfile; + # 基本URLパスを前に付ける必要があります + fastcgi_param SCRIPT_NAME /simplesaml$phpfile; + fastcgi_param PATH_INFO $pathinfo if_not_empty; + } +} + +これにより、`/simplesaml` URLがベンダーのSimpleSAMLphpにルーティングされます。 + +### NGINXイメージに追加のNGINX設定を追加する + +`nginx.dockerfile`を修正し、`location_prepend_simplesamlphp.conf`をイメージに追加します： + +```bash title="nginx.dockerfile" +ARG CLI_IMAGE +FROM ${CLI_IMAGE} as cli + +FROM amazeeio/nginx-drupal + +COPY --from=cli /app /app + +COPY lagoon/nginx/location_prepend_simplesamlphp.conf /etc/nginx/conf.d/drupal/location_prepend_simplesamlphp.conf +RUN fix-permissions /etc/nginx/conf.d/drupal/location_prepend_simplesamlphp.conf + +# Drupal Rootの位置を定義する +ENV WEBROOT=public +``` diff --git a/docs/using-lagoon-advanced/triggering-deployments.ja.md b/docs/using-lagoon-advanced/triggering-deployments.ja.md new file mode 100644 index 0000000000..af0b00b47f --- /dev/null +++ b/docs/using-lagoon-advanced/triggering-deployments.ja.md @@ -0,0 +1,40 @@ +# デプロイメントのトリガー + +## Azure Pipelinesを使用して新しいデプロイメントをトリガーする + +[Azure Pipelines](https://azure.microsoft.com/ja-jp/services/devops/pipelines/)を使用して新しいデプロイメントを自動的にトリガーするには、以下の手順に従ってください： + +1. デプロイメントのSSHプライベートキーを`id_rsa_lagoon`としてAzureのセキュアファイルに追加します。セキュアファイルについての詳細は[Azureのドキュメンテーションサイト](https://docs.microsoft.com/ja-jp/azure/devops/pipelines/library/secure-files?view=azure-devops)をご覧ください。 +2. 以下の設定を`azure-pipelines.yml`に追加します。 + +```yaml title="azure-pipelines.yml" +pool: + vmImage: 'ubuntu-latest' + +stages: + # .. 他のステージ + - stage: Deploy + condition: and(succeeded(), in(variables['Build.SourceBranch'], 'refs/heads/staging', 'refs/heads/develop')) + jobs: + - job: DeployLagoon + steps: + - task: DownloadSecureFile@1 + name: lagoonSshKey + displayName: 'Download Lagoon SSH key' + inputs: + secureFile: id_rsa_lagoon + - script: | + curl -L "https://github.com/amazeeio/lagoon-cli/releases/download/0.9.2/lagoon-cli-0.9.2-linux-amd64" -o ./lagoon + chmod +x ./lag oon + displayName: 'lagoon-cliをダウンロード' + - script: ./lagoon login -i $(lagoonSshKey.secureFilePath) + displayName: 'Lagoonにログイン' + - script: ./lagoon deploy branch -e $(Build.SourceBranchName) -p my-awesome-project -b $(Build.SourceBranchName) --force + displayName: 'lagoon-cliを使用してデプロイメントをトリガー' +``` + +これにより、`develop`ブランチまたは`staging`ブランチで変更が行われるたびに新しいデプロイメントがトリガーされます。これらの値を適切に調整して、デプロイメント戦略と設定に適合させてください。 + +## デプロイせずにプッシュ + +デプロイせずにプッシュしたい場合があるかもしれません。コミットメッセージに "`[skip deploy]`" または "`[deploy skip]`" が含まれていることを確認してください。そうすると、Lagoonはそのコミットからデプロイメントをトリガーしません。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/README.ja.md b/docs/using-lagoon-advanced/using-harbor/README.ja.md new file mode 100644 index 0000000000..17c14615b8 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/README.ja.md @@ -0,0 +1,23 @@ +# ハーバー + +[Harbor](https://goharbor.io/)は、Kubernetesインフラにデプロイする際のLagoonのデフォルトのパッケージリポジトリとして使用されます。HarborはDockerレジストリと、[Trivy](https://github.com/aquasecurity/trivy)によって提供されるコンテナセキュリティスキャニングソリューションを提供します。 + +!!! 注意 + Lagoonをローカルで実行している場合、Harborの設定はすべて自動的に処理されます。 +<!-- markdown-link-check-disable-next-line --> +もしLagoonをローカルで実行している場合は、そのUIに[localhost:8084](https://localhost:8084/)からアクセスできます。ユーザ名は `admin`、パスワードは `admin`です。 + +!!! 注意 + サイトをプロバイダー（amazee.ioなど）でホストしている場合、それらのプロバイダーは顧客がHarbor UIにアクセスすることを許可しない場合があります。 + +ログインすると、最初の画面にはユーザーがアクセスできるすべてのリポジトリのリストが表示されます。Harbor内の各「リポジトリ」はLagoonのプロジェクトに対応しています。 + +![Harborプロジェクトの概要](../../images/projects_overview.png) + +各Harborリポジトリ内には、単一のLagoonプロジェクトからのすべての環境のコンテナイメージのリストが表示されます。 + +![Harborリポジトリの概要](../../images/repositories_overview.png) + +ここから、個々のコンテナに深く掘り下げることができます。そのためには、 その詳細を見る、セキュリティスキャン結果の概要を含む。 + +![Harbor Container Overview](../../images/container_overview.png) \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/README.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/README.ja.md new file mode 100644 index 0000000000..29bc85651a --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/README.ja.md @@ -0,0 +1,47 @@ +# ローカルでのHarborの実行 + +Lagoonは、Harborをローカルで実行することをサポートしています。ここでは、AWS S3と互換性のあるローカルストレージソリューションであるMinIOをストレージバックエンドとして利用します。 + +## 設定 + +Harborは複数のコンテナで構成されており、それぞれが成功裏に実行するためには異なる設定が必要です。 + +## 環境変数 + +Harborが正しく開始するためには、以下の環境変数が設定されている必要があります： + +* `HARBOR_REGISTRY_STORAGE_AMAZON_BUCKET` + * これは、Harborがイメージを保存するAWSバケットの名前に設定する必要があります。 + * Lagoonがローカルで実行される場合やCIテスト中は、デフォルトで`harbor-images`に設定されます。 +* `HARBOR_REGISTRY_STORAGE_AMAZON_REGION` + * これは、Harborのバケットが存在するAWS地域に設定する必要があります。 + * Lagoonがローカルで実行される場合やCIテスト中は、デフォルトで`us-east-1`に設定されます。 +* `REGISTRY_STORAGE_S3_ACCESSKEY` + * これは、HarborがAWSバケットに読み書きするために使用するAWSアクセスキーに設定する必要があります。 + * Lagoonがローカルで実行される場合やCIテスト中は、MinIOは認証を必要としないため、デフォルトで空文字列に設定されます。 +* `REGISTRY_STORAGE_S3_SECRETKEY` + * これは、HarborがAWSバケットにアクセスするために使用するAWSシークレットキーに設定する必要があります。 AWSバケットへの読み書き。 + * Lagoonがローカルで実行されるかCIテスト中の場合、MinIOは認証を必要としないためデフォルトで空文字列になります。 + +必要に応じて次の環境変数を設定できます： + +* `HARBOR_REGISTRY_STORAGE_AMAZON_ENDPOINT` + * この変数が設定されている場合、Harborレジストリはその値をs3エントリポイントのアドレスとして使用します。 + * この変数が設定されていない場合のデフォルトは `https://s3.amazonaws.com` です。 + +## コンテナ固有の設定 + +次のコンテナは設定ファイルを使用します： + +* [HarborRegistry](harborregistry.md) +* [HarborRegistryCtl](harborregistryctl.md) +* [Harbor-Core](harbor-core.md) +* [Harbor-Database](harbor-database.md) +* [Harbor-Jobservice](harbor-jobservice.md) +* [Harbor-Trivy](harbor-trivy.md) + +次のコンテナは設定ファイルを必要とせずに実行できます： + +* Harbor-Nginx +* Harbor-Portal +* Harbor-Redis \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-core.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-core.ja.md new file mode 100644 index 0000000000..cefac26152 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-core.ja.md @@ -0,0 +1,163 @@ +# ハーバーコア + +Harbor-Coreは、コンテナ内の`/etc/core/app.conf`に位置する設定ファイルが必要で、起動します。この設定ファイルに行われる任意の変更は一時的なもので、ポッドが再起動されると持続しません。 + +この設定ファイルが生成されるConfigmapは、`services/harbor-core/harbor-core.yml`ファイルの中のLagoon内に保存されます。このconfigmapに行われる任意の変更は、コンテナの再起動をまたいで持続します。 + +## 設定ファイルの内容 + +* `_REDIS_URL` + * Redisサーバーへの接続情報をharbor-coreとChartmuseumサービスに伝えます。 + * デフォルト値は`harbor-redis:6379,100,`です。 +* `_REDIS_URL_REG` + * harborregistryがRedisサーバーに接続するために使用するべきURL。 + * デフォルト値は`redis://harbor-redis:6379/2`です。 +* `ADMIRAL_URL` + * admiralサービスの場所をharbor-coreに伝えます。 + * このサービスはLagoonのHarbor実装では**使用されません**。 + * デフォルト値は`NA`です。 +* `CFG_EXPIRATION` + * この値は使用されません。 + * デフォルト値は`5`です。 +* `CHART_CACHE_DRIVER` + * harbor-coreにアップロードされたチャートをどこに保存するかを伝えます。 + * デフォルト値は`redis`です。 +* `CLAIR_ADAPTER_URL` + * harbor-coreが使用すべきURL。 * Harbor-trivyサービスに接続するために使用します。 + * デフォルトの値は `http://harbor-trivy:8080` です。 +* `CLAIR_DB` + * harborclairが使用すべきデータベースのタイプ。 + * この値は使用されず、古いサポートのためだけに含まれています。 + * デフォルトの値は `postgres` です。 +* `CLAIR_DB_HOST` + * この値は使用されず、古いサポートのためだけに含まれています。 + * harbor-coreにharborclairサービスの場所を伝えます。 + * デフォルトの値は `harbor-database` です。 +* `CLAIR_DB_PASSWORD` + * harborclairのpostgresデータベースにアクセスするために使用するパスワード。 + * ローカルで実行するかCIテスト中の場合、デフォルトの値は `test123` です。 + * この値は使用されず、古いサポートのためだけに含まれています。 + * この値は、Harborが初めて稼働するLagoon上で設定された時に作成された秘密から取得されます。 +* `CLAIR_DB_PORT` + * harborclairがharborclairサーバーに接続するために使用すべきポート。 + * この値は使用されず、古いサポートのためだけに含まれています。 + * デフォルトの値は `5432` です。 +* `CLAIR_DB_SSLMODE` + * harborclairがpostgresqlサーバーに接続するためにSSLを使用すべきかどうか。 + * この値は使用されず、古いサポートのためだけに含まれています。 + * デフォルトの値は `disable` です。 +* `CLAIR_DB * `USERNAME` + * ユーザー名harborclairは、postgresqlサーバーに接続するために使用するべきです。 + * この値は使用されず、レガシーサポートのためだけに含まれています。 + * デフォルト値は`postgres`です。 +* `CLAIR_HEALTH_CHECK_SERVER_URL` + * この値は、harbor-coreがharbor-trivyサービスに対して健康チェックを発行する場所を指示します。 + * デフォルト値は`http://harbor-trivy:8080`です。 +* `CLAIR_URL` + * harbor-coreがharbor-trivyサービスに接続するために使用すべきURLです。 + * デフォルト値は`http://harbor-trivy:6060`です。 +* `CONFIG_PATH` + * harbor-coreが設定ファイルを探すべき場所です。 + * デフォルト値は`/etc/core/app.conf`です。 +* `CORE_SECRET` + * この値は、harbor-coreに接続する各種サービス間で一致する必要がある事前共有キーです。 + * デフォルト値は、HarborがローカルやCIテスト中に実行されるときに`secret123`に設定されます。 + * この値は、Harborが初めてLagoonで設定されたときに作成された秘密から取得されます。 +* `CORE_URL` + * harbor-coreが他のHarborサービスに公開し、それらがharbor-coreサービスに接続するためのURLです。 + * デフォルト値は`http://harbor-core:8080`です。 +* `DATABASE_TYPE` + * Harborのデータベースタイプ 使用するべきです。 + * デフォルト値は `postgresql`です。 +* `HARBOR_ADMIN_PASSWORD` + * `admin` ユーザーを使用してharborにアクセスするために使用するべきパスワードです。 + * デフォルト値はローカルで実行する場合やCIテスト中は `admin`です。 + * この値は、Harborが最初にセットアップされた際に作成された秘密から取得されます。 +* `HARBOR_NGINX_ENDPOINT` + * この環境変数は、harborregistryに、そのNGINXイングレスコントローラー、harbor-nginxがどこで稼働しているかを通知し、UI内の適切なプッシュとプルの指示を構築するためなどに使用されます。 + * デフォルト値は、ローカルで実行する場合やCIテスト中は `http://harbor-nginx:8080`に設定されています。 + * Lagoonは、本番環境で実行されるときにこの変数を自動的に取得し設定しようと試みます。そのプロセスが失敗すると、このサービスは実行できません。 +* `HTTP_PROXY` + * デフォルト値は空の文字列です。 +* `HTTPS_PROXY` + * デフォルト値は空の文字列です。 +* `JOBSERVICE_SECRET` + * この値は、harbor-jobserviceに接続する各種サービス間で一致しなければならない事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されるかCIテスト中の場合、`secret123`に設定されています。 + * この値は、Harborが最初に設定された際に作成された秘密から取得されます。 は、Lagoonが動作している状態で初めて設定されます。 +* `JOBSERVICE_URL` + * harbor-coreがharbor-jobserviceサービスに接続するために使用すべきURL。 + * デフォルトの値は`http://harbor-jobservice:8080`です。 +* `LOG_LEVEL` + * harbor-coreサービスのデフォルトのログレベル。 + * デフォルトの値は`error`です。 +* `NO_PROXY` + * リクエストがプロキシされるべきではないホストのリスト。 + * デフォルトは`harbor-core,harbor-jobservice,harbor-database,harbor-trivy,harborregistry,harbor-portal,127.0.0.1,localhost,.local,.internal`です。 +* `PORTAL_URL` + * この値は、サービスがharbor-portalサービスに接続する場所を指示します。 + * デフォルトの値は`http://harbor-portal:8080`です。 +* `POSTGRESQL_DATABASE` + * harbor-coreがpostgresqlサーバーに接続する際に使用すべきpostgresデータベース。 + * デフォルトの値は`registry`です。 +* `POSTGRESQL_HOST` + * harbor-coreがpostgresqlサーバーに接続すべき場所。 + * デフォルトの値は`harbor-database`です。 +* `POSTGRESQL_MAX_IDLE_CONNS` + * harbor-coreがpostgresqlサーバーに対して開放しておくべき最大のアイドル接続数。 + * デフォルトの値は`50`です。 +* `POSTGRESQL_MAX_OPEN_CONNS` + * harbor-coreが開くべき最大の接続数。 -コアはpostgresqlサーバーに接続する必要があります。 + * デフォルト値は`100`です。 +* `POSTGRESQL_PASSWORD` + * Harborがpostgresqlサーバーに接続するために使用すべきパスワード。 + * デフォルト値はランダムに生成された値です。 +* `POSTGRESQL_PORT` + * harbor-coreがpostgresqlサーバーに接続するために使用すべきポート。 + * デフォルト値は`5432`です。 +* `POSTGRESQL_USERNAME` + * harbor-coreがpostgresqlサーバーに接続するために使用すべきユーザー名。 + * デフォルト値は`postgres`です。 +* `POSTGRESQL_SSLMODE` + * harbor-coreがSSLを使用してpostgresqlサーバーに接続すべきかどうか。 + * デフォルト値は`disable`です。 +* `REGISTRY_HTTP_SECRET` + * この値は、harborregistryに接続する各サービス間で一致する必要がある事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されるかCIテスト中に`secret123`に設定されます。 + * この値は、Harborが初めて稼働しているLagoonに設定されたときに生成される秘密から取得されます。 +* `REGISTRY_STORAGE_PROVIDER_NAME` + * harborregistryが使用すべきストレージバックエンド。 + * デフォルト値は`s3`です。 +* `REGISTRY_URL` + * harbor-coreがharborregistryサービスに接続するために使用すべきURL。 + * デフォルト値は * 値は`http://harborregistry:5000`です。 +* `REGISTRYCTL_URL` + * この値は、サービスがharborregistryctlサービスに接続する場所を指定します。 + * デフォルト値は`http://harborregistryctl:8080`に設定されています。 +* `ROBOT_TOKEN_DURATION` + * この値は、各問題のロボットトークンが有効であるべき日数を設定します。 + * デフォルト値は`999`に設定されています。 +* `SYNC_REGISTRY` + * この値は使用されません。 + * デフォルト値は`false`です。 +* `TOKEN_SERVICE_URL` + * harbor-coreサービスが他のサービスに公開するURLで、これによりJWTトークンを取得します。 + * デフォルト値は`http://harbor-core:8080/service/token`です。 +* `TRIVY_ADAPTER_URL` + * harbor-coreサービスがharbor-trivyサービスに接続するために使用するURLです。 + * デフォルト値は`http://harbor-trivy:8080`です。 +* `WITH_CHARTMUSEUM` + * Chartmuseumサービスが使用されているかどうかをharbor-coreに伝えます。 + * このサービスはLagoonのHarbor実装では**使用されません**。 + * デフォルト値は`false`です。 +* `WITH_CLAIR` + * harborclairサービスが使用されているかどうかをharbor-coreに伝えます。 + * LagoonはHarborの実装でこのサービスを**使用します**。 + * デフォルト値は`true`です。 +* `WITH_NOTARY` + * harbor-coreに - ノータリーサービスが使用されている場合のcore。 + * このサービスは、Lagoonが実装したHarborでは**使用されません**。 + * デフォルト値は`false`です。 +* `WITH_TRIVY` + * Trivyサービスが使用されているかどうかをharbor-coreに伝えます。 + * デフォルト値は`true`です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-database.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-database.ja.md new file mode 100644 index 0000000000..f5e799f808 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-database.ja.md @@ -0,0 +1,16 @@ +# Harbor-データベース + +Harbor-データベースは起動するために特定の環境変数を設定する必要があり、それらは`services/harbor-database/harbor-core.yml`ファイルで説明されているようにシークレット内に保存されます。 + +## 設定ファイルの内容 + +* **`POSTGRES_DB`** + * Postgresサービスを初期化する際に設定されるデフォルトのデータベース。 + * デフォルト値は`postgres`です。 +* **`POSTGRES_PASSWORD`** + * Postgresデータベースのルートパスワード。 + * デフォルト値は`test123`です。 + * この値は、Harborが動作しているLagoon上で初めて設定されたときに作成されたシークレットから取得されます。 +* **`POSTGRES_USER`** + * Postgresサービスを初期化する際に設定されるデフォルトのユーザー。 + * デフォルト値は`postgres`です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-jobservice.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-jobservice.ja.md new file mode 100644 index 0000000000..992520f3c1 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-jobservice.ja.md @@ -0,0 +1,40 @@ +# Harbor-Jobservice + +Harbor-Jobserviceは、起動に設定ファイルを必要とします。これはコンテナ内の`/etc/jobservice/config.yml`に位置しています。この設定ファイルへの変更は一時的なもので、ポッドが再起動されると持続しません。 + +この設定ファイルが生成される元となるconfigmapは、Lagoon内の`services/harbor-jobservice/harbor-jobservice.yml`ファイルに保存されています。このconfigmapへの変更は、コンテナの再起動を越えて持続します。 + +## 設定ファイルの内容 + +* **`CORE_URL`** + * この値は`harbor-jobservice`に`harbor-core`がどこにあるかを伝えます。 + * デフォルト値は`http://harbor-core:8080`です。 +* **`CORE_SECRET`** + * この値は、`harbor-core`に接続する各種サービス間で一致しなければならない事前共有キーです。 + * デフォルト値は、HarborがローカルまたはCIテスト中に実行されるときに`secret123`に設定されます。 + * この値は、Harborが実行中のLagoon上で初めて設定されたときに作成された秘密から取得されます。 +* **`HTTP_PROXY`** + * デフォルト値は空の文字列です。 +* **`HTTPS_PROXY`** + * デフォルト値は空の文字列です。 +* **`JOBSERVICE_SECRET`** + * この値は、各種サービス間で一致しなければならない事前共有キーです。 `harbor-jobservice`に接続します。 + * デフォルト値は、Harborがローカルで実行されているか、CIテスト中の場合は`secret123`に設定されています。 + * この値は、Harborが実行中のLagoonに初めて設定されたときに作成された秘密から取得されます。 +* **`LOG_LEVEL`** + * このサービスが使用するログレベルです。 + * デフォルト値は`error`です。 + * 非常に詳細なログを有効にするには、`debug`に設定することもできます。 +* **`NO_PROXY`** + * そのリクエストがプロキシ化されるべきではないホストのリスト。 + * デフォルトは `harbor-core,harbor-jobservice,harbor-database,harbor-trivy,harborregistry,harbor-portal,127.0.0.1,localhost,.local,.internal`です。 +* **`REGISTRY_CONTROLLER_URL`** + * この値は、サービスが`harborregistryctl`サービスに接続する場所を指示します。 + * デフォルト値は `http://harborregistryctl:8080`に設定されています。 +* **`SCANNER_LOG_LEVEL`** + * スキャニングサービスが使用するログレベルです。 + * デフォルト値は`error`です。 + * 非常に詳細なログを有効にするには、`debug`に設定することもできます。 +* **`SCANNER_STORE_REDIS_URL`** + * この値は、`harbor-trivy`がRedisストアに接続する方法を指示します。 + * デフォルト値は `redis://harbor-redis:6379/4`です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-trivy.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-trivy.ja.md new file mode 100644 index 0000000000..9e9bcc2e03 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harbor-trivy.ja.md @@ -0,0 +1,19 @@ +# Harbor-Trivy + +Harbor-Trivyは特定の環境変数を介して設定され、設定ファイルは使用しません。 + +## 環境変数 + +* `SCANNER_LOG_LEVEL` + * このサービスが使用するログレベル。 + * デフォルト値は`error`です。 + * 非常に詳細なログを有効にするには、これを`debug`に設定できます。 +* `SCANNER_STORE_REDIS_URL` + * この値はharbor-trivyに、自身のRedisストアへの接続方法を指示します。 + * デフォルト値は`redis://harbor-redis:6379/4`です。 +* `SCANNER_JOB_QUEUE_REDIS_URL` + * この値はharbor-trivyに、自身のRedisストアへの接続方法を指示します。 + * デフォルト値は`redis://harbor-redis:6379/4`です。 +* `SCANNER_TRIVY_VULN_TYPE` + * この値はharbor-trivyに、何タイプの脆弱性を検索すべきかを指示します。 + * デフォルト値は`os,library`です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistry.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistry.ja.md new file mode 100644 index 0000000000..f200477569 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistry.ja.md @@ -0,0 +1,29 @@ +# HarborRegistry + +HarborRegistryは、起動に設定ファイルを必要とし、その設定ファイルはコンテナ内の `/etc/registry/config.yml` に位置しています。この設定ファイルへの変更は一時的なものであり、ポッドが再起動されると持続しません。 + +この設定ファイルは `services/harborregistry/harborregistry.yml` ファイル内に保存され、 `/etc/registry/pre-config.yml` としてコンテナ内にロードされます。 + +カスタムコンテナエントリーポイント `services/harborregistry/entrypoint.sh` は、提供された環境変数をこの設定ファイルに転送し、結果を `/etc/registry/config.yml` として保存します。 + +## 設定ファイルの内容 + +* **`CORE_SECRET`** + * この値は、`harbor-core` に接続する様々なサービス間で一致しなければならない事前共有キーです。 + * デフォルトの値は、Harborがローカルで実行されたりCIテスト中に設定される `secret123` です。 + * この値は、Harborが実行中のLagoonに初めてセットアップされたときに作成されるシークレットから取得されます。 +* **`HARBOR_NGINX_ENDPOINT`** + * この環境変数は、`harborregistry`に、そのNGINXイングレスコントローラー `harbor-nginx`がどこで実行されているかを通知し、UI内で適切なプッシュとプルの指示を構築するため、その他の事項を通知します。 + * デフォルトの値が設定されています ローカルで実行したりCIテスト中には、`http://harbor-nginx:8080`になります。 + * プロダクション環境でLagoonが自動的にこの変数を取得しセットしようとします。そのプロセスに失敗すると、このサービスは実行に失敗します。 +* **`JOBSERVICE_SECRET`** + * この値は、`harbor-jobservice`に接続する各種サービス間で一致しなければならない事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されるかCIテスト中に`secret123`に設定されます。 + * この値は、Harborが最初に稼働中のLagoon上に設定されたときに作成された秘密から取得されます。 +* **`REGISTRY_HTTP_SECRET`** + * この値は、`harborregistry`に接続する各種サービス間で一致しなければならない事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されるかCIテスト中に`secret123`に設定されます。 + * この値は、Harborが最初に稼働中のLagoon上に設定されたときに作成された秘密から取得されます。 +* **`REGISTRY_REDIS_PASSWORD`** + * この環境変数は、`harborregistryctl`がRedisに接続するために使用すべきパスワードを指示します。 + * デフォルト値は空の文字列です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistryctl.ja.md b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistryctl.ja.md new file mode 100644 index 0000000000..40d647e2a5 --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/harbor-settings/harborregistryctl.ja.md @@ -0,0 +1,23 @@ +# HarborRegistryCtl + +HarborRegistryCtlは起動するために設定ファイルを必要とし、その設定ファイルはコンテナ内の`/etc/registryctl/config.yml`に位置しています。この設定ファイルへの変更は一時的なものであり、ポッドが再起動されると持続しません。 + +この設定ファイルが生成される元となるconfigmapは、Lagoon内の`services/harborregistryctl/harborregistry.yml`ファイルに保存されています。このconfigmapへの変更は、コンテナが再起動されても保持されます。 + +## 設定ファイルの内容 + +* **`CORE_SECRET`** + * この値は、`harbor-core`に接続する各種サービス間で一致する必要がある事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されたりCIテスト中に設定される`secret123`です。 + * この値は、Harborが稼働中のLagoonに初めて設定された際に作成されるシークレットから取得されます。 +* **`JOBSERVICE_SECRET`** + * この値は、`harbor-jobservice`に接続する各種サービス間で一致する必要がある事前共有キーです。 + * デフォルト値は、Harborがローカルで実行されたりCIテスト中に設定される`secret123`です。 + * この値は、Harborが稼働中のLagoonに初めて設定された際に作成されるシークレットから取得されます。 +* **`REGISTRY_HTTP_SECRET`** + * この値は、 `harborregistry`に接続する各種サービス間で一致しなければならない事前共有キー。 + * デフォルト値は、HarborがローカルまたはCIテスト中に実行されるときに`secret123`に設定されます。 + * この値は、Harborが動作中のLagoonに初めて設定されたときに作成された秘密から取得されます。 +* **`REGISTRY_REDIS_PASSWORD`** + * この環境変数は、`harborregistryctl`にRedisに接続するために使用すべきパスワードを伝えます。 + * デフォルト値は空文字列です。 \ No newline at end of file diff --git a/docs/using-lagoon-advanced/using-harbor/security-scanning.ja.md b/docs/using-lagoon-advanced/using-harbor/security-scanning.ja.md new file mode 100644 index 0000000000..ab9d2bb10d --- /dev/null +++ b/docs/using-lagoon-advanced/using-harbor/security-scanning.ja.md @@ -0,0 +1,7 @@ +# セキュリティスキャン + +Harborには、Trivyサービスによって提供される組み込みのセキュリティスキャンソリューションが搭載されています。このサービスは、指定されたコンテナイメージを解析し、インストールされたパッケージのバージョン番号を収集します。その後、Trivyサービスは[国立脆弱性データベース](https://nvd.nist.gov/)を検索し、それらのパッケージバージョンに影響を与えるCVE（一般的な脆弱性と露出）を探します。Trivyはライブラリにも対応しているため、Composerファイルやその他のパッケージライブラリ定義ファイルをスキャンし、それらのパッケージバージョン内に見つかった脆弱性を報告します。これらの脆弱性は、個々のコンテナごとにHarbor内で報告されます。 + +Harborでのセキュリティスキャンの例、スキャンされたコンテナに適用可能な脆弱性を示しています： + +![Harbor セキュリティスキャン例画像](../../images/scanning_image_1.png) \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/configure-webhooks.ja.md b/docs/using-lagoon-the-basics/configure-webhooks.ja.md new file mode 100644 index 0000000000..16a4c999bf --- /dev/null +++ b/docs/using-lagoon-the-basics/configure-webhooks.ja.md @@ -0,0 +1,52 @@ +# Webhooksの設定 + +あなたのLagoon管理者は、`webhook-handler`へのルートもあなたに教えてくれるでしょう。このルートをリポジトリのアウトゴーイングwebhookに追加し、Lagoonに送信するイベントを選択します。通常、全てのプッシュとプルリクエストイベントを送信します。Lagoonでは、どのブランチやプルリクエストが実際にデプロイに結果するかを決定するための正規表現を追加することができ、あなたのLagoon管理者がそれを設定することができます。例えば、`feature-`で始まる全てのブランチがLagoonにデプロイされることができます。 + +<!-- markdown-link-check-disable --> +???+ Info "amazee.ioのお客様への情報" + あなたがamazee.ioのお客様である場合、webhook-handlerへのルートは次のとおりです：[`https://hooks.lagoon.amazeeio.cloud`](https://hooks.lagoon.amazeeio.cloud)。 + <!-- markdown-link-check-enable --> + +!!! danger + 以下の設定を管理するには、これらのリポジトリへの高いレベルのアクセスが必要となります。これはあなたの組織によって管理されます。これらの設定にアクセスできない場合は、システム管理者またはあなたの組織内の適切な人物に連絡してください。 + +## GitHub + +1. GitHubリポジトリで設定 -> Webhooks -> `Add webhook`に進みます。 ![GitHubでwebhookを追加します。](../images/webhooks-2020-01-23-12-40-16.png) +2. `Payload URL`は、あなたのLagoon管理者から提供される、あなたのLagoonインスタンスの`webhook-handler`へのルートです。 +3. `Content type`を`application/json`に設定します。 + ![Payload URLを追加し、Content typeを設定します。](../images/gh_webhook_1.png) +4. "`私が個々のイベントを選択させてください`"を選択します。 +5. どのイベントがあなたのwebhookをトリガーするかを選択します。私たちは、`Push`と`Pull request`のイベントを送信することを提案し、その後、あなたのプロジェクトのLagoon設定でさらにフィルタリングします。 + ![GitHubでwebhookイベントトリガーを選択します。](../images/gh_webhook_2.png) +6. webhookが`Active`に設定されていることを確認します。 +7. `Add webhook`をクリックして設定を保存します。 + +## GitLab + +1. GitLabリポジトリで設定 -> インテグレーションに移動します。 + ![GitLabリポジトリで設定 &amp;gt; インテグレーションに移動します。](../images/gitlab-settings.png) +2. `URL`は、あなたのLagoon管理者から提供される、あなたのLagoonインスタンスの`webhook-handler`へのルートです。 +3. Lagoonに通知を送信する`Trigger`イベントを選択します。我々はあなたが`Push events`と`Merge request events`を送信し、その後Lagoonの設定でさらにフィルタリングすることを提案します。 あなたのプロジェクトの設定。 + ![GitLabでトリガーイベントを選択する。](../images/gitlab_webhook.png) +4. `Add webhook`をクリックして設定を保存します。 + +## Bitbucket + +1. リポジトリで設定 -> ウェブフック -> 新しいウェブフックを追加に移動します。 +2. `Title`はあなたの参照のためのものです。 +3. `URL`はあなたのLagoonインスタンスの`webhook-handler`へのルートで、Lagoonの管理者によって提供されます。 +4. `全てのトリガーから選択`をクリックし、以下を選択します： + + * リポジトリ + * プッシュ + * プルリクエスト + * 作成 + * 更新 + * 承認 + * 承認の削除 + * マージ + * 拒否 + + ![Bitbucketのウェブフックのためのトリガーを選択します。](../images/bb_webhook_1.png) +5. `Save`をクリックしてBitbucketのウェブフック設定を保存します。 \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/first-deployment.ja.md b/docs/using-lagoon-the-basics/first-deployment.ja.md new file mode 100644 index 0000000000..66419caae0 --- /dev/null +++ b/docs/using-lagoon-the-basics/first-deployment.ja.md @@ -0,0 +1,66 @@ +--- +description: >- + 時間です！ラグーンに初めてデプロイする時間が来ました！私たちと同じくらいワクワクしていることを願っています！ +--- + +# 最初のデプロイ + +![excited](https://i.giphy.com/media/7kVRZwYRwF1ok/giphy-downsized.gif) + +!!! 注意 + Drupalプロジェクトをデプロイする場合は、これをスキップして、[Drupal-specific first deployment documentation](../applications/drupal/first-deployment-of-drupal.md)をお読みください。 + +## 1. 準備が整っていることを確認する + +最初のデプロイを成功させるためには、プロジェクトがラグーン化されており、ラグーンでプロジェクトが設定されていることを確認してください。もしそうでない場合、または確信が持てない場合、またはそれが馴染みがない場合は心配しないでください。[ステップバイステップのガイド](setup-project.md)を戻って読み、どのように作動するか見てから、再度デプロイに来てください！ + +## 2. プッシュ + +ラグーンでは、デプロイが設定されているブランチにプッシュすることで新しいデプロイを作成します。 + +新しいコードをプッシュするものがない場合でも心配しないでください！以下のコマンドを実行してください： + +```bash title="Git push" +git commit --allow-empty -m "go, go! Power Rangers!" +git push +``` + +これによりプッシュがトリガーされ、Gitホスティングが設定されたWebhookを通じてラグーンにこのプッシュについて通知します。 + +すべて正しければ、あなたは見るはずです あなたが設定したチャットシステムでの通知（これはあなたの親切なLagoon管理者が設定したものです）： + +![Lagoonizedリポジトリにプッシュが行われたというSlackの通知](../images/first_deployment_slack_start.jpg) + +これは、Lagoonがあなたのコードのデプロイを開始したことを通知します。コードの大きさやコンテナの量によりますが、これには数秒かかります。リラックスしてください。今何が起こっているのか知りたい場合は、[Lagoonのビルドとデプロイプロセス](../concepts-basics/build-and-deploy-process.md)をチェックしてください。 + +また、Lagoon UIを確認して、任意のデプロイメントの進行状況を確認することもできます（Lagoon管理者が情報を持っています）。 + +## 3. 完了しました + +Lagoonがビルドとデプロイを完了すると、チャットシステムに2つ目の通知を送ります。ここに例を示します： + +![成功したLagoonビルドとデプロイのSlack通知](../images/first_deployment_slack_2nd_success.jpg) + +これには以下の情報が含まれています： + +* デプロイされたプロジェクト。 +* デプロイされたブランチとGit SHA。 +* ビルドとデプロイの完全なログへのリンク。 +* 環境にアクセスできるすべてのルート（URL）へのリンク。 + +また、どのような通知なのかをすぐに判断することもできます。 それは絵文字によって始まります - ビルドが開始しただけの情報であるか、成功であるか、または失敗であるか。 + +それだけです！あまり難しくなかったことを願っています - devOpsを利用可能にすることが私たちの目指すところです！ + +## でも待って、他のブランチや本番環境についてはどうでしょうか？ + +それがLagoonの美しさです：それはまったく同じです！ブランチの名前をプッシュするだけで、そのブランチがデプロイされます。 + +## 失敗？心配しないで + +デプロイメントが失敗しましたか？ああ、いやだ！しかし、私たちはここに助けを求めています： + +1. Drupalサイトをデプロイした場合、[Drupal専用の最初のデプロイメントドキュメンテーション](../applications/drupal/first-deployment-of-drupal.md)を読むことを確認してください。これはなぜこれが起こるのかを説明します。 +2. エラー通知の `Logs` リンクをクリックすると、デプロイメントプロセスのどこで失敗が発生したかが表示されます。 +3. もし理解できない場合は、Lagoonのサポートに尋ねてみてください。私たちはここに助けを求めています！ +4. サポートチャンネルまたは[コミュニティDiscord](https://discord.gg/te5hHe95JE)で私たちに連絡してください。 \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/going-live.ja.md b/docs/using-lagoon-the-basics/going-live.ja.md new file mode 100644 index 0000000000..7893d1c69f --- /dev/null +++ b/docs/using-lagoon-the-basics/going-live.ja.md @@ -0,0 +1,99 @@ +# ライブ配信開始 + +おめでとうございます、あなたのウェブサイトがLagoon上でライブ配信する一歩手前に来ました！これをできるだけスムーズに進めるために、最後のチェックリストをご用意しました。これは、サイトをライブ配信する前に最後に確認すべきことをガイドします。 + +## `.lagoon.yml`を確認する + +### ルート / SSL + +あなたの`.lagoon.yml`にすべてのルートが設定されていることを確認してください。ドメインをLagoonに向けない場合、Let's Encrypt（LE）の証明書の作成を無効にすべきであることを認識しておいてください。これは問題を引き起こす可能性があります。Lagoonに向けていないドメインは、Let's Encryptの制限を超えないように、しばらくすると無効になります。 + +証明機関（CA）による署名付き証明書を使用する場合、`tls-acme`を`false`に設定できますが、`insecure`フラグは`Allow`または`Redirect`に設定したままにしておいてください。CA証明書の場合、Lagoonの管理者にルートと、設定する必要があるSSL証明書を知らせてください。 + +```yaml title=".lagoon.yml" +environments: + main: + routes: + - nginx: + - example.com: + tls-acme: 'false' + insecure: Allow + - www.example.com: + tls-acme: 'false' + insecure: Allow +``` + +次に DNSエントリがあなたのLagoonインストールを指すようになると、フラグを切り替えることができます：`tls-acme` を `true` に、`insecure` を `Redirect` にします。 + +```yaml title=".lagoon.yml" +environments: + main: + routes: + - nginx: + - example.com: + tls-acme: 'true' + insecure: Redirect + - www.example.com: + tls-acme: 'true' + insecure: Redirect +``` + +!!! 注意 + ウェブサイトのすべてのページを確認するのは少し手間がかかるかもしれませんので、[mixed-content-scan](https://github.com/bramus/mixed-content-scan)を利用することができます。これにより、サイト全体をクロールし、非HTTPSサイトからのアセットを含むページを返します。 + +### リダイレクト + +非wwwからwwwへのリダイレクトが必要な場合は、それらが `redirects-map.conf` に設定されていることを確認してください - [ドキュメンテーションを参照](../docker-images/nginx.md#redirects-mapconf)。 + +### クロンジョブ + +プロダクション環境用のクロンジョブが設定されているか確認してください - [`.lagoon.yml`](../concepts-basics/lagoon-yml.md)を参照してください。 + +## DNS + +あなたのサイトが私たちのサーバーを指すようにするためにできるだけスムーズに進行するように、専用のロードバランサーDNSレコードを用意しています。これらの技術的なDNSリソースレコードは、あなたのサイトを取得するために使用されます。 amazee.ioインフラストラクチャにリンクされ、他の目的では使用されません。CNAMEレコードに疑問がある場合は、Lagoonの管理者に設定する必要がある正確なCNAMEを尋ねてください。 + +**amazee.ioの例：** `<region-identifier>.amazee.io` + +ドメインをLagoonに切り替える前に、ライブになる前にTime-to-Live \(TTL\)を下げておくことを確認してください。これにより、古いサーバーから新しいサーバーへの切り替えが迅速に行われます。通常、DNSの切り替え前にはTTLを300-600秒に設定することをお勧めします。[TTLについての詳細情報](https://en.wikipedia.org/wiki/Time_to_live#DNS_records)。 + +### Fastlyのための推奨設定（CNAMEレコード）: + +ドメインのDNSレコードをLagoonに指す推奨方法は、以下に示すようなCNAMEレコードを使用することです： +<!-- markdown-link-check-disable-next-line --> +`CNAME`: `cdn.amazee.io` + +### Fastlyのための代替設定（Aレコード）: + +DNSプロバイダがCNAMEレコードの使用をサポートしていない場合、代わりに以下のAレコードを使用できます。以下に示す各IPに対して個別のレコードを設定してください： + +* `A`: `151.101.2.191` +* `A`: `151.101.66.191` +* `A`: `151.101.130.191` +* `A`: `151.101.194.191` + +!!! 注意 + 静的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アドレスを提供してもらいます。 + +## 本番環境 + +Lagoonは開発環境と本番環境の概念を理解しています。開発環境は自動的に`noindex`と`nofollow`のヘッダーを送信し、検索エンジンによるインデックス化を禁止します。 + +`X-Robots-Tag: noindex, nofollow` + +プロジェクトの設定中に、本番環境はすでに定義されているはずです。もしまだ定義されていない場合は、 省略された場合、あなたの環境は開発モードで動作します。ラグーンのユーザーインターフェースで環境が本番環境として設定されているかどうかを確認できます。本番環境が設定されていない場合は、ラグーンの管理者に知らせて、システムを適切に設定してもらってください。 + +![本番環境は左側の緑色で表示されています。](../images/lagoon-ui-production.png) diff --git a/docs/using-lagoon-the-basics/index.ja.md b/docs/using-lagoon-the-basics/index.ja.md new file mode 100644 index 0000000000..d22882e7d5 --- /dev/null +++ b/docs/using-lagoon-the-basics/index.ja.md @@ -0,0 +1,65 @@ +# Lagoonの使用 - 概要 + +このセクションでは、Lagoonの基本的な特徴と機能について説明します。これらに慣れている方は、[Lagoonの使用 - 上級](../using-lagoon-advanced/index.md)に進んでください。 + +ヘルプが必要な場合は、Lagoonの管理者に連絡するか、私たちの[Discord](../community/discord.md)でコミュニティとメンテナに問い合わせてください。 + +## 必要条件 + +### Docker + +Lagoonプロジェクトを実行するには、システムがDockerを実行するための要件を満たしている必要があります。ワークステーションに最新バージョンのDockerをインストールすることをおすすめします。Dockerは[こちら](https://www.docker.com/get-docker)からダウンロードできます。また、Dockerには最低でも**4 CPUs**と**4 GB RAM**を割り当てることをおすすめします。 + +### ローカル開発環境 + +pygmy、Lando、DDEVから選ぶことができます - 選択はあなた次第です！ + +Lagoonと[ローカル開発環境](local-development-environments.md)についてもっと学びましょう。 + +## ステップバイステップのガイド + +* 一般: [Lagoonで新しいプロジェクトを設定する](setup-project.md) +* 一般: [初めてのデプロイ](first-deployment.md) +* Drupal: [Drupalでの初めてのデプロイ](../applications/drupal/first-deployment-of-drupal.md) +* Drupal: [DrupalサイトをLagoon対応にする](../applications/drupal/step-by-step-getting-drupal-ready-to-run-on-l agoon.md) +* すべて: [Lagoonのビルドとデプロイメントプロセス](../concepts-basics/build-and-deploy-process.md) + +## Lagoon設定ファイルの概要 + +### `.lagoon.yml` + +これはLagoonが何をデプロイするべきか、また多くの他の事柄を理解するために使用する主要なファイルです。[`.lagoon.yml`のドキュメンテーション](../concepts-basics/lagoon-yml.md)を参照してください。 + +### `docker-compose.yml` + +このファイルは`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. **イメージのカスタマイズ **: ラグーンでは、ベースイメージをあなたのニーズに合わせてカスタマイズすることも可能です。これには、追加の環境変数を挿入したり、サービスの設定を変更したり、さらに追加のツールをインストールすることも含まれます。Dockerイメージに追加のツールをインストールする際には注意が必要です。なぜなら、将来的に任意の適応を維持する必要があるからです！ + +## ラグーンによるサポートサービスとベースイメージ + +| タイプ | バージョン | Dockerfile | +| :--- | :--- | :--- | +| [MariaDB](../docker-images/mariadb.md) | 10.4, 10.5, 10.6, 10.11 | [mariadb/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mariadb) | +| [PostgreSQL](../docker-images/postgres.md) | 11, 12, 13, 14, 15 | [postgres/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/postgres) | +| [MongoDB](../docker-images/mongodb.md) | 4 | [mongo/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/mongo) | +| [NGINX](../docker-images/nginx.md) | openresty/1.21 | [nginx/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/nginx) | +| [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) | +| [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) | +| [Opensearch](../docker-images/opensearch.md) | 2 | [opensearch/Dockerfiles](https://github.com/uselagoon/lagoon-images/blob/main/images/opensearch) | +| [RabbitMQ](../docker-images/rabbitmq.md) | 3.10 | [rabbitmq/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/rabbitmq) | +| [Ruby](../docker-images/ruby.md) | 3.0, 3. 1、3.2 | [ruby/Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/ruby) | + +すべてのイメージは[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バージョンがリリースされたらすぐにイメージのバージョンをアップグレードするのはあなた自身の責任です！ \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/lagoon-build-errors-and-warnings.ja.md b/docs/using-lagoon-the-basics/lagoon-build-errors-and-warnings.ja.md new file mode 100644 index 0000000000..fab2779747 --- /dev/null +++ b/docs/using-lagoon-the-basics/lagoon-build-errors-and-warnings.ja.md @@ -0,0 +1,29 @@ +# ラグーンビルドのエラーと警告 + +新しいバージョンのラグーンでは、ビルドに潜在的な問題があるかどうかを識別し、失敗せずにそれらを警告としてハイライトする機能があります。これはまた、ラグーンチームがユーザーに対して予定されている非推奨や機能の変更を通知する方法でもあります。 + +例えば、ラグーンチームが `lagoon.yml` の設定を変更し、ユーザーが変更する必要がある何かがあった場合、警告にそれが記されます。そこでユーザーは、それが破壊的な変更になる前に変更することができます。可能な限り早期に解決するべきであり、将来のラグーンのリリースではエラーを処理できないかもしれませんが、ビルドを停止させるべきではありません。 + +これらのエラーの解決方法がわからない場合は、ラグーンの管理者に連絡するか、[ラグーンコミュニティ](../community/discord.md)で質問してください。 + +## Docker Composeのエラー + +[一般的なDocker Composeの問題](../concepts-basics/docker-compose-yml.md#common-docker-compose-issues)についてのセクションも参照してください。これらの問題の一部はそこでカバーされているかもしれません。 + +``` shell title="Lagoon Build output indicating env_file error" +> an env_file is defined in your docker-compose file, but no matching file found +``` + +Docker Compose ビルド時に参照されるenvファイルが存在することを期待していますが、そのenvファイルはローカル開発環境でのみ存在するか、Dockerfileから除外されています。Lagoonチームは、Docker Composeがこのエラーを無視することを可能にするための作業を行っていますので、解決策が見つかるまでこの警告は続きます。 + +``` shell title="文字列キーエラーを示すLagoonビルド出力" +> あなたのdocker-composeファイルで無効な文字列キーが検出されました +``` + +あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの誤用に関連している可能性があります。エラーメッセージはあなたがどこで理解するのを助けるべきです。 + +``` shell title="yaml検証エラーを示すLagoonビルド出力" +> あなたのdocker-composeファイルには修正すべきyaml検証エラーがあります +``` + +あなたのDocker Composeファイルにエラーがあります、おそらく形式が不正またはエイリアスやアンカーの誤用に関連している可能性があります。エラーメッセージはあなたがどこで理解するのを助けるべきです。 \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/local-development-environments.ja.md b/docs/using-lagoon-the-basics/local-development-environments.ja.md new file mode 100644 index 0000000000..43d579e9e0 --- /dev/null +++ b/docs/using-lagoon-the-basics/local-development-environments.ja.md @@ -0,0 +1,37 @@ +# ローカル開発環境 + +LagoonにはDockerと[Docker Compose](https://docs.docker.com/compose/)（ほとんどがDockerと一緒に出荷されています）に対する硬い依存性しかありませんが、Dockerに含まれていないローカル開発に役立つものがいくつかあります： + +* ナイスなURLとHTTPSオフローディングのためのHTTPリバースプロキシ。 +* IPアドレスを覚えておく必要がないDNSシステム。 +* コンテナ内でSSHキーを使用するためのSSHエージェント。 +* メールをローカルで受信し表示するシステム。 + +???+ warning + ローカルでLagoonを_使用する_ためには、ローカルにLagoonを_インストール_する必要はありません！これは混乱するかもしれませんが、ドキュメンテーションを参照してください。Lagoonはあなたのローカル開発環境を本番環境に**デプロイ**するシステムであり、環境自体では**ありません**。 + +## pygmy、DDEV、またはLando - 選択はあなた次第 + +### pygmy + +Lagoonは伝統的に`pygmy`と最も良好に動作してきました。これは上記のツールのamazee.ioフレーバーシステムであり、Lagoonとそのまま動作します。これは[https://github.com/pygmystack/pygmy](https://github.com/pygmystack/pygmy)にあります。 + +`pygmy`はGolangで書かれているので、インストールするには次のコマンドを実行します： + +```bash title="HomeBrewでのインストール" +brew tap pygmystack/pygmy && brew pygmyのインストール +``` + +pygmyの詳細な使用方法やインストール情報については、その[ドキュメンテーション](https://pygmy.readthedocs.io/en/master/)を参照してください。 + +### Lando + +LagoonはLandoと非常によく組み合わされています！詳細な情報は、[https://docs.lando.dev/config/lagoon.html](https://docs.lando.dev/config/lagoon.html)のドキュメンテーションを参照して始めてください。 + +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/)。 + +以前には、[Docksal](https://docksal.io/)や[Docker4Drupal](https://wodby.com/docs/stacks/drupal/local/)などの他のシステムへのサポートを追加することを評価していました。これらに将来的にサポートを追加する可能性はありますが、現在のところは、既存のツールへのサポートに焦点を当てています。 \ No newline at end of file diff --git a/docs/using-lagoon-the-basics/setup-project.ja.md b/docs/using-lagoon-the-basics/setup-project.ja.md new file mode 100644 index 0000000000..31a1ffd0b7 --- /dev/null +++ b/docs/using-lagoon-the-basics/setup-project.ja.md @@ -0,0 +1,40 @@ +# 新しいプロジェクトの設定 + +!!! 注意 + 我々は全ての人がLagoonを使って自分自身でプロジェクトを設定し、構成することを可能にするためのCLIとGraphQL 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管理者がこれを設定できます。 + +特定の重要なブランチ（`develop`や`main`のような）やプルリクエストをデプロイすることをお勧めします。しかし、それはすべてあなた次第です！（[ワークフロー](../concepts-advanced/workflows.md)で詳細情報を参照してください） + +## 1. プロジェクトがLagoon化されていることを確認する + +これは、`.lagoon.yml`ファイルと`docker-compose.yml`ファイルがあなたのGitリポジトリに存在し、適切に設定されていることを意味します。 + +もしこれが実現していない場合は、先に進む前に[ステップバイステップガイド](index.md#step-by-step-guides)のリストをチェックしてください。 + +## 2. あなたのコードへのアクセスを提供する + +あなたのコードをデプロイするために、Lagoonはそれへのアクセスが必要です。設計上、セキュリティのため、LagoonはあなたのGitリポジトリへの読み取りアクセスのみが必要です。 + +あなたのLagoon管理者は、読み取りアクセスを与えるべきSSH公開鍵やGitアカウントを教えてくれるでしょう。 + +## 3. ウェブフックの設定 + +Lagoonは、Gitリポジトリに何が起こっているかについていくつかのイベントを知る必要があります。現在、これらはプッシュとプルリクエストですが、将来的にはもっと追加するかもしれません。 + +Lagoonは多くの異なるGitホストをサポートしているため、これらの指示をこのドキュメンテーションに分割しました：[ウェブフックの設定](configure-webhooks.md)。 + +## 4. 次に：最初のデプロイメント + +おめでとうございます、あなたは今[初めてのデプロイメント](first-deployment.md)を実行する準備ができました。 \ No newline at end of file diff --git a/mkdocs.yml b/mkdocs.yml index 526026755f..a63b9b92de 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -250,6 +250,159 @@ plugins: build: true nav_translations: Home: ホーム + Basic Lagoon Concepts: Lagoonの基本概念 + Overview: 概要 + Build and Deploy Process: ビルドとデプロイプロセス + Building Blocks of Lagoon: Lagoonの構成要素 + Users: ユーザー + Groups: グループ + Projects: プロジェクト + Notifications: 通知 + Deploy Targets: デプロイターゲット + Organizations: 組織 + Roles: ロール + Advanced Lagoon Concepts: 高度なLagoonの概念 + Overview: 概要 + Service Types: サービスタイプ + Environment Types: 環境タイプ + Environment Variables: 環境変数 + Environment Idling: 環境のアイドリング + Backups: バックアップ + Base Images: ベースイメージ + Workflows: ワークフロー + Feature Flags: フィーチャーフラグ + Lagoonizing: Lagoon化 + Lagoonizing Your Existing Site: 既存サイトのLagoon化 + Docker Images: Dockerイメージ + Commons: コモンズ + MariaDB: MariaDB + MongoDB: MongoDB + Node.js: Node.js + NGINX: NGINX + OpenSearch: OpenSearch + PHP-CLI: PHP-CLI + PHP-FPM: PHP-FPM + Python: Python + PostgreSQL: PostgreSQL + RabbitMQ: RabbitMQ + Ruby: Ruby + Solr: Solr + Redis: Redis + Varnish: Varnish + Configuring Applications: アプリケーションの設定 + Overview: 概要 + Options: オプション + Drupal: Drupal + Overview: 概要 + Services: サービス + Overview: 概要 + MariaDB: MariaDB + NGINX: NGINX + PHP-cli: PHP-cli + Redis: Redis + Solr: Solr + Varnish: Varnish + Step by Step - Getting Drupal ready to run on Lagoon: ステップバイステップ - DrupalをLagoonで実行する準備 + First Deployment of Drupal: Drupalの初回デプロイ + Drush 9: Drush 9 + Subfolders: サブフォルダ + Integrate Drupal & Fastly: DrupalとFastlyの統合 + PHPUnit and PhpStorm: PHPUnitとPhpStorm + Automatic Updates: 自動更新 + WordPress: WordPress + Overview: 概要 + Node.js-based: Node.jsベース + Overview: 概要 + PHP-based: PHPベース + Overview: 概要 + Python-based: Pythonベース + Overview: 概要 + Ruby-based: Rubyベース + Overview: 概要 + Other: その他 + Overview: 概要 + Using Lagoon - The Basics: Lagoonの基本的な使い方 + Overview: 概要 + Local Development Environments: ローカル開発環境 + Set Up a New Project: 新しいプロジェクトのセットアップ + Configure Webhooks: Webhooksの設定 + First Deployment: 初回デプロイ + Lagoon Build Errors and Warnings: Lagoonビルドエラーと警告 + Going Live: 本番環境への移行 + Using Lagoon - Advanced: Lagoonの高度な使い方 + Overview: 概要 + Active/Standby: アクティブ/スタンバイ + Triggering Deployments: デプロイのトリガー + Private Repositories: プライベートリポジトリ + SimpleSAML: SimpleSAML + Project Default Users and SSH Keys: プロジェクトのデフォルトユーザーとSSHキー + Node.js Graceful Shutdown: Node.jsのグレースフルシャットダウン + Setting up Xdebug with Lagoon: LagoonでのXdebugの設定 + Custom Tasks: カスタムタスク + DeployTarget Configs: DeployTargetの設定 + Blackfire: Blackfire + Harbor: Harbor + Using Harbor: Harborの使用 + Security Scanning: セキュリティスキャン + Harbor Settings: Harborの設定 + Harbor-Core: Harbor-Core + Harbor-Database: Harbor-Database + Harbor-Jobservice: Harbor-Jobservice + Harbor-Trivy: Harbor-Trivy + HarborRegistry: HarborRegistry + HarborRegistryCtl: HarborRegistryCtl + Interacting with Lagoon: Lagoonとの連携 + Using the UI: UIの使用 + Working with Orgs: 組織との連携 + GraphQL: GraphQL + SSH: SSH + GraphQL API: GraphQL API + Role-Based Access Control (RBAC): ロールベースのアクセス制御 (RBAC) + Understanding Logs: ログの理解 + Logging: ロギング + Kibana Examples: Kibanaの例 + Installing Lagoon: Lagoonのインストール + Requirements: 要件 + EFS Provisioner: EFSプロビジョナー + Install Harbor: Harborのインストール + Install Lagoon Core: Lagoon Coreのインストール + Install Lagoon Remote: Lagoon Remoteのインストール + Install the Lagoon CLI: Lagoon CLIのインストール + Querying with GraphQL: GraphQLによるクエリ + Create Lagoon User: Lagoonユーザーの作成 + Add a Project: プロジェクトの追加 + Deploy Your Project: プロジェクトのデプロイ + Add Group: グループの追加 + Lagoon Logging: Lagoonのロギング + OpenDistro: OpenDistro + Logs Concentrator: ログコンセントレーター + Lagoon Backups: Lagoonのバックアップ + Lagoon Files: Lagoonのファイル + GitLab: GitLab + Updating: 更新 + Contributing to Lagoon: Lagoonへの貢献 + Documentation: ドキュメント + Code of Conduct: 行動規範 + Contributing: 貢献 + Developing Lagoon: Lagoonの開発 + Tests: テスト + API Debugging: APIデバッグ + Releasing: リリース + Community: コミュニティ + Code of Conduct: 行動規範 + Discord: Discord + Participation Guidelines: 参加ガイドライン + Moderation Guidelines: モデレーションガイドライン + Resources: リソース + FAQ: FAQ + Glossary: 用語集 + Tutorials, Webinars, and Videos: チュートリアル、ウェビナー、ビデオ + Lagoon Examples: Lagoonの例 + Other Tools: その他のツール + Lagoon CLI: Lagoon CLI + Lagoon Sync: Lagoon Sync + Client Libraries: クライアントライブラリ + - redirects: redirect_maps: # Shortcut URLs for build and compose errors