Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mkdocs update Lagoon v2.21 #3802

Merged
merged 5 commits into from
Sep 9, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/test-mkdocs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@ on:
push:
branches:
- 'docs/**'
- 'mkdocs'
pull_request:
branches:
- 'main'
Expand Down
53 changes: 53 additions & 0 deletions docs/docker-images/deprecated-images.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Deprecated Images

From time to time, the Lagoon team may need to mark images as deprecated.

This is conveyed in a "sh.lagoon.image.deprecated" . It can be viewed in Docker Desktop, via a `docker inspect` command, or in future releases of Lagoon, highlighted in a build.

If the image has a suggested replacement, it will be conveyed in a "sh.lagoon.image.deprecated.suggested" label attached the deprecated image.

## Changing the image

In all cases, changing to a suggested or updated image will require a change in your codebase. Any reference to the image in a Dockerfile, or in your docker-compose.yml will need to be updated.

## Reasons for deprecating

We have three main reasons for deprecating an image:

### Replaced
An image will be marked as "replaced" when the image reference needs to be changed. This could be because of a naming change, a repository change, or a versioning change. In these cases a new image will usually be recommended for use instead, and using it should be a fairly easy switch.

Some examples of this are:

* the migration from `amazeeio/{image}` to `uselagoon/{image}` - these images should be identical
* the versioning of an image from `uselagoon/mongo` to `uselagoon/mongo-4` - these images should be identical

### End of Life
An image will be marked as "endoflife" when the version published is no longer actively supported or maintained upstream. In these cases a new image will usually be recommended for use instead, but upgrading to it may require updating some of your application code, so should always be tested thoroughly. Also note that any suggested image may also be marked as endoflife (especially if the upstream moves quickly)

Some examples of this are:

* PHP 8.0 reached EOL in November 2023, and any `uselagoon/php-8.0-{variant}` image will suggest `uselagoon/php-8.3-{variant}` as it is the current latest release of PHP. Upgrades here _may_ be straightforward as it's within a major version.
* Python 2.7 reached EOL in January 2020, and the `uselagoon/php-2.7` images will suggest `uselagoon/python-3.12` as it is the current latest release of Python. Upgrades here will be complex, owing to it being a major version change.

### Discontinued
An image will be marked as "discontinued when the variant is no longer being published by the Lagoon team (although the upstream may still be supported). In these cases a replacement image _may_ be suggested, but any migration will be involved, and require updating of application code, client libraries, data directories etc, or removal of functionality completely.

* A CKAN variant of Python 2.7 image `uselagoon/python-2.7-ckan` stopped being published in August 2021 and no replacement is suggested.
* An AthenaPDF image `uselagoon/athenapdf-service` stopped being published in October 2022 and no replacement image is suggested.
* An Elasticsearch 7 image `uselagoon/elasticsearch-7` stopped being published in April 2023 due to licensing concerns, and although images may suggest `uselagoon/opensearch-2` - any upgrade here will be extremely involved.


## "amazeeio/" image variants

Historically, all Lagoon images were dual published to the [uselagoon](https://hub.docker.com/u/uselagoon) and [amazeeio](https://hub.docker.com/u/amazeeio) Docker Hub organizations.

In August 2024, we ceased this dual-publishing model, and have used the deprecated image tooling to suggest the correct replacements.

We encourage anyone still using the `amazeeio` variants to switch to the `uselagoon` variants as soon as possible.

As well as being easier for us to maintain, the uselagoon versions:

* Are routinely published and updated. No `amazeeio` image will be updated beyond July 2024.
* Are published as multi-architecture images by default, so will work natively on Linux, Windows or MacOS machines.
* Are free from any rate-limit restrictions, as the `uselagoon` organization is [Docker Sponsored Open Source](https://docs.docker.com/trusted-content/dsos-program/)
2 changes: 1 addition & 1 deletion docs/docker-images/nodejs.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ The builder variant of those images comes with additional tooling that is needed
* 12 \(available for compatibility only, no longer officially supported\) - `uselagoon/node-12`
* 14 \(available for compatibility only, no longer officially supported\) - `uselagoon/node-14`
* 16 \(available for compatibility only, no longer officially supported\) - `uselagoon/node-16`
* 18 \(available for compatibility only, no longer officially supported\) - `uselagoon/node-18`
* 18 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node/18.Dockerfile) (Security Support until April 2025) - `uselagoon/node-18`
* 20 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node/20.Dockerfile) (Security Support until April 2026) - `uselagoon/node-20`
* 22 [Dockerfile](https://github.com/uselagoon/lagoon-images/blob/main/images/node/22.Dockerfile) (Security Support until April 2027) - `uselagoon/node-22`

Expand Down
28 changes: 14 additions & 14 deletions docs/ja/concepts-basics/docker-compose-yml.md
Original file line number Diff line number Diff line change
Expand Up @@ -71,7 +71,7 @@ services:
1. ここで[マルチコンテナポッド](docker-compose-yml.md#multi-container-pods)に注目してください。
2. ここで[マルチコンテナポッド](docker-compose-yml.md#multi-container-pods)に注目してください。

## 基本設定
## 基本設定 { #basic-settings }

`x-lagoon-project`:

Expand Down Expand Up @@ -107,7 +107,7 @@ Linuxを使用していて、`1000`以外のユーザーで実行したい場合
!!! Warning "警告"
一度サービスの名前を設定したら、修正しないでください。修正すると、コンテナ内で様々な問題が発生し、不整合が発生する可能性があります。

### Dockerイメージ
### Dockerイメージ { #docker-images }

#### `build`

Expand All @@ -127,17 +127,17 @@ Linuxを使用していて、`1000`以外のユーザーで実行したい場合

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

### タイプ
### タイプ { #types }

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

これは`lagoon.type`ラベルを通じて行われます。選択できるタイプは多数あります。すべてのタイプと追加設定の可能性を見るには、[サービスタイプ](../concepts-advanced/service-types.md)を確認してください。

#### コンテナのスキップ/無視
#### コンテナのスキップ/無視 { #skipignore-containers }

たとえば、ローカル開発時にのみコンテナが必要な場合など、Lagoonにサービスを完全に無視させたい場合は、そのタイプに`none`を指定します。

### 永続的なストレージ
### 永続的なストレージ { #persistent-storage }

一部のコンテナには永続的なストレージが必要です。Lagoonでは、各コンテナが最大1つの永続的なストレージボリュームをコンテナに接続できるようにしています。コンテナに自身の永続的なストレージボリュームを要求させることができ(それを他のコンテナにマウントさせることも可能)、また、コンテナに他のコンテナが作成した永続的なストレージをマウントするよう指示することもできます。

Expand All @@ -148,13 +148,13 @@ Lagoonは、KubernetesやOpenShiftのオブジェクトを正しく設定する
* `lagoon.persistent.size` - 必要な永続的なストレージのサイズ(Lagoonは通常、最小5Gの永続的なストレージを提供します。もしもっと必要なら、ここで定義してください)。
* `lagoon.persistent.class` - デフォルトではLagoonは自動的に適切なストレージクラス(MySQLのSSD、Nginxの大量ストレージなど)をサービスに割り当てます。これを上書きする必要がある場合は、ここで行うことができます。これは、Lagoonが動作するKubernetes/OpenShiftのインフラ基盤に大きく依存します。これについてはLagoonの管理者に問い合わせてください。

### 自動生成されるルート
### 自動生成されるルート { #auto-generated-routes }

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)ときに、サービスに対して自動生成されるルートを有効にします。

## マルチコンテナーポッド
## マルチコンテナーポッド { #multi-container-pods }

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

Expand Down Expand Up @@ -197,11 +197,11 @@ php:

Lagoonはどのサービスが`nginx`、`php`であるかを認識するために、`lagoon.deployment.servicetype: nginx`および`lagoon.deployment.servicetype: php`と定義します。

## Helmテンプレート (Kubernetesのみ)
## Helmテンプレート (Kubernetesのみ) { #helm-templates-kubernetes-only }

LagoonはKubernetesでのテンプレート作成に[Helm](https://helm.sh/)を使用します。これを行うために、一連の[チャート](https://github.com/uselagoon/build-deploy-tool/tree/main/legacy/helmcharts)が`build-deploy-tool`イメージに含まれています。

## カスタムロールアウトモニタータイプ
## カスタムロールアウトモニタータイプ { #custom-rollout-monitor-types }

デフォルトでは、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`を通じて定義することができます:

Expand All @@ -211,7 +211,7 @@ LagoonはKubernetesでのテンプレート作成に[Helm](https://helm.sh/)を

また、特定の環境のみにロールアウトを上書きすることもできます。これは[`.lagoon.yml`](lagoon-yml.md#environments-name-rollouts)で行います。

## Docker Compose v2互換性
## Docker Compose v2互換性 { #docker-compose-v2-compatibility }

!!! Bug "バグ"
ローカルでDocker Compose V2の古いバージョンを使用していると、一部の既知の問題が発生することがあります - これらの問題は後のリリース(v2.17.3以降)で解決されています。
Expand Down Expand Up @@ -239,21 +239,21 @@ no such service: container:amazeeio-ssh-agent
* このメッセージは、ローカルで実行されているコンテナへのSSHアクセスを提供するサービスが、あなたのDocker Composeスタックの外部で実行され、アクセスできないことを意味します。
* あなたのローカル環境からSSHアクセスが必要ない場合、`docker-compose.yml`ファイルからこのセクションを削除することもできます。

## BuildKitとLagoon
## BuildKitとLagoon { #buildkit-and-lagoon }

BuildKitは、ソースコードを効率的で表現力豊かで繰り返し利用可能な方法でビルド成果物に変換するためのツールキットです。

Lagoon v2.11.0のリリースにより、Lagoonはより高度なBuildKitベースのdocker-composeビルドをサポートするようになりました。プロジェクトまたは環境でBuildKitを有効にするには、Lagoonプロジェクトまたは環境に`DOCKER_BUILDKIT=1`をビルド時の変数として追加してください。

## LagoonビルドでのDocker Composeエラー
## LagoonビルドでのDocker Composeエラー { #docker-compose-errors-in-lagoon-builds }

Docker Composeで一般的なビルドエラーの解決方法については、[Lagoonビルドエラーページ](../using-lagoon-the-basics/lagoon-build-errors-and-warnings.md#docker-compose-errors)を参照してください。

## よくあるDocker Composeの問題
## よくあるDocker Composeの問題 { #common-docker-compose-issues }

このセクションでは、一般的なDocker Composeのエラーとその対処方法について説明します。これらはローカル開発で発生するか、または[Lagoonビルドエラーと警告](../using-lagoon-the-basics/lagoon-build-errors-and-warnings.md#docker-compose-errors)として発生するかもしれません。

### 二重マッピングキー
### 二重マッピングキー { #dual-mapping-keys }

``` shell title="マッピングキーのエラーを示すDocker Composeの出力"
ERR: yaml: unmarshal errors: line 22: mapping key "<<" already defined at line 21
Expand Down
Loading