From 66cfcbe640d1a607283f68943008d0b6ed2ead5b Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Wed, 25 Jun 2025 14:55:36 -0700 Subject: [PATCH 01/15] AI Translations This translation push includes AI translations from the following merge requests gitlab-com/localization/tech-docs-forked-projects/prod/gitlab-chart!16 gitlab-com/localization/tech-docs-forked-projects/prod/gitlab-chart!17 --- doc-locale/ja-jp/advanced/_index.md | 20 + .../ja-jp/advanced/custom-images/_index.md | 44 + .../ja-jp/advanced/external-db/_index.md | 59 + .../external-db/external-omnibus-psql.md | 68 + .../ja-jp/advanced/external-gitaly/_index.md | 726 +++++++++ .../external-omnibus-gitaly.md | 102 ++ .../advanced/external-gitlab-pages/_index.md | 74 + .../advanced/external-mattermost/_index.md | 71 + .../ja-jp/advanced/external-nginx/_index.md | 77 + .../external-object-storage/_index.md | 348 +++++ .../external-object-storage/aws-iam-roles.md | 197 +++ .../azure-minio-gateway.md | 96 ++ .../azure-workload-identity.md | 130 ++ .../gke-workload-identity.md | 42 + .../advanced/external-object-storage/minio.md | 25 + .../ja-jp/advanced/external-redis/_index.md | 121 ++ .../external-redis/external-omnibus-redis.md | 56 + doc-locale/ja-jp/advanced/fips/_index.md | 16 + doc-locale/ja-jp/advanced/geo/_index.md | 682 ++++++++ .../ja-jp/advanced/internal-tls/_index.md | 230 +++ .../advanced/multiple-databases/_index.md | 14 + .../advanced/persistent-volumes/_index.md | 423 +++++ doc-locale/ja-jp/advanced/ubi/_index.md | 32 + doc-locale/ja-jp/backup-restore/_index.md | 232 +++ doc-locale/ja-jp/backup-restore/backup.md | 174 +++ doc-locale/ja-jp/backup-restore/restore.md | 205 +++ doc-locale/ja-jp/charts/_index.md | 19 + .../ja-jp/charts/certmanager-issuer/_index.md | 61 + doc-locale/ja-jp/charts/gitlab/_index.md | 90 ++ .../ja-jp/charts/gitlab/gitaly/_index.md | 480 ++++++ .../charts/gitlab/gitlab-exporter/_index.md | 189 +++ .../charts/gitlab/gitlab-pages/_index.md | 443 ++++++ .../charts/gitlab/gitlab-runner/_index.md | 87 ++ .../charts/gitlab/gitlab-shell/_index.md | 496 ++++++ .../charts/gitlab/gitlab-zoekt/_index.md | 121 ++ doc-locale/ja-jp/charts/gitlab/kas/_index.md | 236 +++ .../ja-jp/charts/gitlab/mailroom/_index.md | 246 +++ .../ja-jp/charts/gitlab/migrations/_index.md | 265 ++++ .../ja-jp/charts/gitlab/praefect/_index.md | 333 ++++ .../ja-jp/charts/gitlab/sidekiq/_index.md | 684 ++++++++ .../ja-jp/charts/gitlab/spamcheck/_index.md | 216 +++ .../ja-jp/charts/gitlab/toolbox/_index.md | 202 +++ .../ja-jp/charts/gitlab/webservice/_index.md | 845 ++++++++++ doc-locale/ja-jp/charts/haproxy/_index.md | 41 + doc-locale/ja-jp/charts/minio/_index.md | 270 ++++ doc-locale/ja-jp/charts/nginx/_index.md | 147 ++ doc-locale/ja-jp/charts/nginx/fork.md | 14 + doc-locale/ja-jp/charts/registry/_index.md | 1376 +++++++++++++++++ .../charts/registry/metadata_database.md | 532 +++++++ doc-locale/ja-jp/charts/shared-secrets.md | 90 ++ doc-locale/ja-jp/charts/traefik/_index.md | 41 + .../ja-jp/installation/chart-provenance.md | 118 ++ doc-locale/ja-jp/installation/cloud/_index.md | 61 + doc-locale/ja-jp/installation/cloud/aks.md | 93 ++ doc-locale/ja-jp/installation/cloud/eks.md | 127 ++ doc-locale/ja-jp/installation/cloud/gke.md | 105 ++ doc-locale/ja-jp/installation/cloud/oke.md | 63 + .../ja-jp/installation/cloud/openshift.md | 120 ++ .../installation/command-line-options.md | 482 ++++++ .../ja-jp/installation/database_upgrade.md | 155 ++ .../ja-jp/installation/migration/_index.md | 24 + .../ja-jp/installation/migration/helm.md | 99 ++ .../installation/migration/helm_to_package.md | 91 ++ .../ja-jp/installation/migration/minio.md | 58 + .../installation/migration/package_to_helm.md | 44 + doc-locale/ja-jp/installation/rbac.md | 55 + doc-locale/ja-jp/installation/secrets.md | 602 ++++++++ doc-locale/ja-jp/installation/storage.md | 156 ++ doc-locale/ja-jp/installation/tls.md | 177 +++ doc-locale/ja-jp/installation/tools.md | 238 +++ doc-locale/ja-jp/installation/uninstall.md | 34 + doc-locale/ja-jp/installation/upgrade.md | 154 ++ .../ja-jp/installation/verify_cng_images.md | 58 + .../ja-jp/installation/version_mappings.md | 368 +++++ doc-locale/ja-jp/quickstart/_index.md | 136 ++ doc-locale/ja-jp/releases/6_0.md | 77 + doc-locale/ja-jp/releases/7_0.md | 71 + doc-locale/ja-jp/releases/8_0.md | 106 ++ doc-locale/ja-jp/releases/9_0.md | 70 + doc-locale/ja-jp/troubleshooting/_index.md | 643 ++++++++ .../troubleshooting/kubernetes_cheat_sheet.md | 311 ++++ 81 files changed, 16684 insertions(+) create mode 100644 doc-locale/ja-jp/advanced/_index.md create mode 100644 doc-locale/ja-jp/advanced/custom-images/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-db/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md create mode 100644 doc-locale/ja-jp/advanced/external-gitaly/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md create mode 100644 doc-locale/ja-jp/advanced/external-gitlab-pages/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-mattermost/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-nginx/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/aws-iam-roles.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/azure-minio-gateway.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/azure-workload-identity.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/gke-workload-identity.md create mode 100644 doc-locale/ja-jp/advanced/external-object-storage/minio.md create mode 100644 doc-locale/ja-jp/advanced/external-redis/_index.md create mode 100644 doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md create mode 100644 doc-locale/ja-jp/advanced/fips/_index.md create mode 100644 doc-locale/ja-jp/advanced/geo/_index.md create mode 100644 doc-locale/ja-jp/advanced/internal-tls/_index.md create mode 100644 doc-locale/ja-jp/advanced/multiple-databases/_index.md create mode 100644 doc-locale/ja-jp/advanced/persistent-volumes/_index.md create mode 100644 doc-locale/ja-jp/advanced/ubi/_index.md create mode 100644 doc-locale/ja-jp/backup-restore/_index.md create mode 100644 doc-locale/ja-jp/backup-restore/backup.md create mode 100644 doc-locale/ja-jp/backup-restore/restore.md create mode 100644 doc-locale/ja-jp/charts/_index.md create mode 100644 doc-locale/ja-jp/charts/certmanager-issuer/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitaly/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitlab-exporter/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitlab-runner/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitlab-shell/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/gitlab-zoekt/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/kas/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/mailroom/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/migrations/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/praefect/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/sidekiq/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/spamcheck/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/toolbox/_index.md create mode 100644 doc-locale/ja-jp/charts/gitlab/webservice/_index.md create mode 100644 doc-locale/ja-jp/charts/haproxy/_index.md create mode 100644 doc-locale/ja-jp/charts/minio/_index.md create mode 100644 doc-locale/ja-jp/charts/nginx/_index.md create mode 100644 doc-locale/ja-jp/charts/nginx/fork.md create mode 100644 doc-locale/ja-jp/charts/registry/_index.md create mode 100644 doc-locale/ja-jp/charts/registry/metadata_database.md create mode 100644 doc-locale/ja-jp/charts/shared-secrets.md create mode 100644 doc-locale/ja-jp/charts/traefik/_index.md create mode 100644 doc-locale/ja-jp/installation/chart-provenance.md create mode 100644 doc-locale/ja-jp/installation/cloud/_index.md create mode 100644 doc-locale/ja-jp/installation/cloud/aks.md create mode 100644 doc-locale/ja-jp/installation/cloud/eks.md create mode 100644 doc-locale/ja-jp/installation/cloud/gke.md create mode 100644 doc-locale/ja-jp/installation/cloud/oke.md create mode 100644 doc-locale/ja-jp/installation/cloud/openshift.md create mode 100644 doc-locale/ja-jp/installation/command-line-options.md create mode 100644 doc-locale/ja-jp/installation/database_upgrade.md create mode 100644 doc-locale/ja-jp/installation/migration/_index.md create mode 100644 doc-locale/ja-jp/installation/migration/helm.md create mode 100644 doc-locale/ja-jp/installation/migration/helm_to_package.md create mode 100644 doc-locale/ja-jp/installation/migration/minio.md create mode 100644 doc-locale/ja-jp/installation/migration/package_to_helm.md create mode 100644 doc-locale/ja-jp/installation/rbac.md create mode 100644 doc-locale/ja-jp/installation/secrets.md create mode 100644 doc-locale/ja-jp/installation/storage.md create mode 100644 doc-locale/ja-jp/installation/tls.md create mode 100644 doc-locale/ja-jp/installation/tools.md create mode 100644 doc-locale/ja-jp/installation/uninstall.md create mode 100644 doc-locale/ja-jp/installation/upgrade.md create mode 100644 doc-locale/ja-jp/installation/verify_cng_images.md create mode 100644 doc-locale/ja-jp/installation/version_mappings.md create mode 100644 doc-locale/ja-jp/quickstart/_index.md create mode 100644 doc-locale/ja-jp/releases/6_0.md create mode 100644 doc-locale/ja-jp/releases/7_0.md create mode 100644 doc-locale/ja-jp/releases/8_0.md create mode 100644 doc-locale/ja-jp/releases/9_0.md create mode 100644 doc-locale/ja-jp/troubleshooting/_index.md create mode 100644 doc-locale/ja-jp/troubleshooting/kubernetes_cheat_sheet.md diff --git a/doc-locale/ja-jp/advanced/_index.md b/doc-locale/ja-jp/advanced/_index.md new file mode 100644 index 0000000000..78b42d224d --- /dev/null +++ b/doc-locale/ja-jp/advanced/_index.md @@ -0,0 +1,20 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 高度な設定 +--- + +- 独自のカスタム[Dockerイメージ](custom-images/_index.md)を使用する +- 外部[データベース](external-db/_index.md)の使用 +- 外部[Gitaly](external-gitaly/_index.md)の使用 +- 外部[GitLab Pagesインスタンス](external-gitlab-pages/_index.md)の使用 +- 外部[Mattermost](external-mattermost/_index.md)の使用 +- 独自の[NGINX Ingress Controller](external-nginx/_index.md)の使用 +- 外部[オブジェクトストレージ](external-object-storage/_index.md)の使用 +- 外部[Redis](external-redis/_index.md)の使用 +- [FIPS](fips/_index.md)準拠イメージの使用 +- [GitLab Geo機能](geo/_index.md)の活用 +- [サービス間の内部TLS](internal-tls/_index.md)の有効化 +- インストール後の[Persistent Volumesの管理](persistent-volumes/_index.md) +- [Red Hat UBI](ubi/_index.md)ベースのイメージの使用 diff --git a/doc-locale/ja-jp/advanced/custom-images/_index.md b/doc-locale/ja-jp/advanced/custom-images/_index.md new file mode 100644 index 0000000000..e30b31377c --- /dev/null +++ b/doc-locale/ja-jp/advanced/custom-images/_index.md @@ -0,0 +1,44 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートにカスタムのDockerイメージを使用する +--- + +特定のシナリオ（オフライン環境など）では、インターネットからDockerイメージをプルするのではなく、独自のDockerイメージを使用したい場合があります。これを行うには、GitLabのリリースを構成する各チャートに対して、独自のDockerイメージレジストリ/リポジトリを指定する必要があります。 + +## デフォルトイメージ形式 {#default-image-format} + +ほとんどの場合、イメージに対するデフォルトの形式には、tagを除外するイメージへのフルパスが含まれています。 + +```yaml +image: + repository: repo.example.com/image + tag: custom-tag +``` + +最終的な結果は`repo.example.com/image:custom-tag`になります。 + +## 現在のイメージとtag {#current-images-and-tags} + +アップグレードをPlanする場合、現在の`values.yaml`とGitLabチャートのターゲットバージョンを使用して、[Helmテンプレート](https://helm.sh/docs/helm/helm_template/)を生成できます。このテンプレートには、指定されたチャートのバージョンに必要なイメージとそれぞれのタグが含まれます。 + +```shell +# Gather the latest values +helm get values gitlab > gitlab.yaml + +# Use the gitlab.yaml to find the images and tags +helm template versionfinder gitlab/gitlab -f gitlab.yaml --version 7.3.0 | grep 'image:' | tr -d '[[:blank:]]' | sort --unique +``` + +このコマンドを使用して、カスタム設定をVerifyすることもできます。 + +## 値ファイルの例 {#example-values-file} + +カスタムの[Docker](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml) [レジストリ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)/[リポジトリ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)と[タグ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)を[Configure](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)する方法を示す[値](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)ファイルの例[example values file](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)があります。このファイルの関連セクションをコピーして、独自のリリースに使用できます。 + +{{< alert type="note" >}} + +一部のチャート（特にサードパーティのチャート）では、イメージのレジストリ/リポジトリとタグの指定方法が若干異なる場合があります。サードパーティ[チャート](https://artifacthub.io/)のドキュメントは、[Artifact Hub](https://artifacthub.io/)にあります。 + +{{< /alert >}} diff --git a/doc-locale/ja-jp/advanced/external-db/_index.md b/doc-locale/ja-jp/advanced/external-db/_index.md new file mode 100644 index 0000000000..53d1560272 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-db/_index.md @@ -0,0 +1,59 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部データベースでGitLabチャートを設定する +--- + +{{< alert type="warning" >}} + +バンドルされているbitnami PostgreSQLチャートは、本番環境に対応していません。本番環境に対応したGitLabチャートのデプロイには、外部データベースを使用してください。 + +{{< /alert >}} + +前提要件: + +- [必要なバージョンのPostgreSQL](https://docs.gitlab.com/install/requirements/#postgresql)のデプロイ。お持ちでない場合は、[AWS RDS PostgreSQL](https://aws.amazon.com/rds/postgresql/)や[GCP Cloud SQL](https://cloud.google.com/sql/)のようなクラウドで提供されるソリューションをご検討ください。代替ソリューションとしては、[Linux Package](external-omnibus-psql.md)をご検討ください。 +- デフォルトでは`gitlabhq_production`という名前の空のデータベース。 +- データベースへのフルアクセス権を持つユーザー。詳細については、[外部データベースのドキュメント](https://docs.gitlab.com/administration/postgresql/external/)を参照してください。 +- データベースユーザーのパスワードを持つ[Kubernetes Secret](https://kubernetes.io/docs/concepts/configuration/secret/)。 +- [`pg_trgm`および`btree_gist` extension](https://docs.gitlab.com/install/postgresql_extensions/)。GitLabにSuperuserフラグを持つアカウントを提供しない場合は、データベースのインストールに進む前に、これらのextensionが読み込むことを確認してください。 + +ネットワーキングの前提要件: + +- データベースがクラスターから到達可能であることを確認してください。ファイアウォールPoliciesがトラフィックを許可していることを確認してください。 +- PostgreSQLをロードバランシングクラスターとして使用し、Kubernetes DNSをサービスディスカバリに使用する場合は、`bitnami/postgresql`チャートのインストール時に`--set slave.service.clusterIP=None`を使用します。このSettingsは、PostgreSQLセカンダリinstanceごとにDNS `A`レコードを作成できるように、PostgreSQLセカンダリサービスをヘッドレスサービスとしてConfigureします。 + + [Kubernetes](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/database/values-loadbalancing-discover.yaml) DNSをサービスディスカバリに使用する方法の例については、[`examples/database/values-loadbalancing-discover.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/database/values-loadbalancing-discover.yaml)を参照してください。 + +外部データベースを使用するようにGitLabチャートをConfigureするには: + +1. 次のパラメータを設定します: + + - `postgresql.install`:`false`に設定して、埋め込みデータベースを無効にします。 + - `global.psql.host`:外部データベースのホスト名に設定します。ドメインまたはIPアドレスを指定できます。 + - `global.psql.password.secret`:`gitlab`ユーザーのデータベースパスワードを含む[シークレット](../../installation/secrets.md#postgresql-password)の名前。 + - `global.psql.password.key`:シークレット内で、パスワードを含むキー。 + +1. 任意。デフォルトを使用していない場合は、次の項目をさらにカスタマイズできます: + + - `global.psql.port`:データベースが利用可能なポート。デフォルトは`5432`です。 + - `global.psql.database`:データベースの名前。 + - `global.psql.username`:データベースへのアクセス権を持つユーザー。 + +1. 任意。相互TLSConnectionをデータベースに使用する場合は、以下を設定します: + + - `global.psql.ssl.secret`:クライアント証明書、キー、およびcertificate authorityを含むシークレット。 + - `global.psql.ssl.serverCA`:シークレット内で、certificate authority (CA) を参照するキー。 + - `global.psql.ssl.clientCertificate`:シークレット内で、クライアント証明書を参照するキー。 + - `global.psql.ssl.clientKey`:シークレットのクライアント。 + +1. GitLabチャートをデプロイするときは、`--set`フラグを使用して値を追加します。例: + + ```shell + helm install gitlab gitlab/gitlab + --set postgresql.install=false + --set global.psql.host=psql.example + --set global.psql.password.secret=gitlab-postgresql-password + --set global.psql.password.key=postgres-password + ``` diff --git a/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md b/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md new file mode 100644 index 0000000000..dd0ba90d34 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md @@ -0,0 +1,68 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: スタンドアロンのPostgreSQLデータベースをセットアップ +--- + +Ubuntu用の[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)を利用します。このパッケージは、のサービスと互換性があることが保証されているサービスのを提供します。 + +## LinuxパッケージでVMを作成 {#create-vm-with-the-linux-package} + +任意のプロバイダーで、またはローカルでを作成します。これは、VirtualBox、KVM、およびBhyveでテストされました。がから到達可能であることを確認します。 + +作成したにUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのが最新であることを確認します。とホスト名を設定します。ホスト名/ をメモし、それがKubernetesから解決可能で、到達可能であることを確認します。トラフィックを許可するために、ファイアウォールが適切に設定されていることを確認してください。 + +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、**_しないで_**ください`EXTERNAL_URL=`値を指定します。次の手順で非常に具体的なを提供するので、自動が発生しないようにします。 + +## Linuxパッケージのインストールを設定 {#configure-linux-package-installation} + +最小限の`gitlab.rb`ファイルを作成して、`/etc/gitlab/gitlab.rb`に配置します。こので何が有効になっているかを非常に明確にし、以下のコンテンツを使用してください。 + +*ノート*:この例は、[スケーリング用のPostgreSQL](https://docs.gitlab.com/administration/postgresql/)を提供するものではありません。 + +_**注**:以下の値は置き換える必要があります_ + +- `DB_USERNAME`デフォルトのユーザー名は`gitlab`です +- `DB_PASSSWORD`エンコードされていない +- `DB_ENCODED_PASSWORD``DB_PASSWORD`のエンコードされた。`DB_USERNAME`と`DB_PASSWORD`を次の実際のに置き換えることで生成できます: `echo -n 'DB_PASSSWORDDB_USERNAME' | md5sum - | cut -d' ' -f1` +- `AUTH_CIDR_ADDRESS` MD5用のCIDRを設定します。これは、またはそのゲートウェイの可能な限り小さいサブネットである必要があります。minikubeの場合、この値は`192.168.100.0/12`です + +```ruby +# Change the address below if you do not want PG to listen on all available addresses +postgresql['listen_address'] = '0.0.0.0' +# Set to approximately 1/4 of available RAM. +postgresql['shared_buffers'] = "512MB" +# This password is: `echo -n '${password}${username}' | md5sum - | cut -d' ' -f1` +# The default username is `gitlab` +postgresql['sql_user_password'] = "DB_ENCODED_PASSWORD" +# Configure the CIDRs for MD5 authentication +postgresql['md5_auth_cidr_addresses'] = ['AUTH_CIDR_ADDRESSES'] +# Configure the CIDRs for trusted authentication (passwordless) +postgresql['trust_auth_cidr_addresses'] = ['127.0.0.1/24'] + +## Configure gitlab_rails +gitlab_rails['auto_migrate'] = false +gitlab_rails['db_username'] = "gitlab" +gitlab_rails['db_password'] = "DB_PASSSWORD" + + +## Disable everything else +sidekiq['enable'] = false +puma['enable'] = false +registry['enable'] = false +gitaly['enable'] = false +gitlab_workhorse['enable'] = false +nginx['enable'] = false +prometheus_monitoring['enable'] = false +redis['enable'] = false +gitlab_kas['enable'] = false +``` + +`gitlab.rb`を作成したら、`gitlab-ctl reconfigure`でを再設定します。タスクが完了したら、`gitlab-ctl status`で実行中のプロセスを確認します。は次のようになります: + +```plaintext +# gitlab-ctl status +run: logrotate: (pid 4856) 1859s; run: log: (pid 31262) 77460s +run: postgresql: (pid 30562) 77637s; run: log: (pid 30561) 77637s +``` diff --git a/doc-locale/ja-jp/advanced/external-gitaly/_index.md b/doc-locale/ja-jp/advanced/external-gitaly/_index.md new file mode 100644 index 0000000000..93d921cf27 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-gitaly/_index.md @@ -0,0 +1,726 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部GitalyでGitLabチャートを設定する +--- + +このドキュメントは、このHelm Chartを外部Gitalyサービスで設定する方法について説明することを目的としています。 + +Gitalyが設定されていない場合は、オンプレミスまたはVMへのデプロイメントについて、[Linuxパッケージ](external-omnibus-gitaly.md)の使用を検討してください。 + +{{< alert type="note" >}} + +外部Gitaly _サービス_は、Gitalyノードまたは[Praefect](https://docs.gitlab.com/administration/gitaly/praefect/)クラスターによって提供できます。 + +{{< /alert >}} + +## チャートを設定する {#configure-the-chart} + +`gitaly`チャートと、提供されているGitalyサービスを無効にし、他のサービスを外部サービスに向けるようにします。 + +次のプロパティを設定する必要があります。 + +- `global.gitaly.enabled`:`false`に設定して、含まれているGitaly Chartを無効にします。 +- `global.gitaly.external`:これは、[外部Gitalyサービス](../../charts/globals.md#external)の配列です。 +- `global.gitaly.authToken.secret`:[認証用のトークンを含むシークレット](../../installation/secrets.md#gitaly-secret)の名前。 +- `global.gitaly.authToken.key`:トークンのコンテンツを含むシークレット内のキー。 + +外部Gitalyサービスは、GitLab Shellの独自のインスタンスを使用します。実装によっては、このChartのシークレットを使用してそれらを構成することも、定義済みのソースからのコンテンツを使用してこのChartのシークレットを構成することもできます。 + +次のプロパティの設定が必要になる**場合**があります。 + +- `global.shell.authToken.secret`:[GitLab Shellのシークレットを含むシークレット](../../installation/secrets.md#gitlab-shell-secret)の名前。 +- `global.shell.authToken.key`:シークレットのコンテンツを含むシークレット内のキー。 + +2つの外部サービスを含む完全な構成例（`external-gitaly.yml`）。 + +```yaml +global: + gitaly: + enabled: false + external: + - name: default # required + hostname: node1.git.example.com # required + port: 8075 # optional, default shown + - name: praefect # required + hostname: ha.git.example.com # required + port: 2305 # Praefect uses port 2305 + tlsEnabled: false # optional, overrides gitaly.tls.enabled + authToken: + secret: external-gitaly-token # required + key: token # optional, default shown + tls: + enabled: false # optional, default shown +``` + +`gitlab.yml`を介して他の構成と組み合わせて上記の構成ファイルを使用するインストール例: + +```shell +helm upgrade --install gitlab gitlab/gitlab \ + -f gitlab.yml \ + -f external-gitaly.yml +``` + +## 複数の外部Gitaly {#multiple-external-gitaly} + +実装で、これらのChartの外部にある複数のGitalyノードを使用する場合は、複数のホストを定義することもできます。構文は、必要な複雑さを許容するために、若干異なります。 + +適切な設定セットを示す[値のサンプルファイル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/gitaly/values-multiple-external.yaml)が用意されています。この値ファイルの内容は`--set`引数では正しく解釈されないため、`-f / --values`フラグを指定してHelmに渡す必要があります。 + +### TLS経由で外部Gitalyに接続する {#connecting-to-external-gitaly-over-tls} + +外部[GitalyサーバーがTLSポート経由でリッスン](https://docs.gitlab.com/administration/gitaly/#enable-tls-support)している場合は、GitLabインスタンスがTLS経由で通信するように設定できます。これを行うには、次の手順に従ってください。 + +1. Gitalyサーバーの証明書を含むKubernetesシークレットを作成します + + ```shell + kubectl create secret generic gitlab-gitaly-tls-certificate --from-file=gitaly-tls.crt= + ``` + +1. [カスタム認証局](../../charts/globals.md#custom-certificate-authorities)のリストに外部Gitalyサーバーの証明書を追加します。値ファイルで、以下を指定します + + ```yaml + global: + certificates: + customCAs: + - secret: gitlab-gitaly-tls-certificate + ``` + + または、`--set`を使用して、`helm upgrade`コマンドに渡します + + ```shell + --set global.certificates.customCAs[0].secret=gitlab-gitaly-tls-certificate + ``` + +1. すべてのGitalyインスタンスに対してTLSを有効にするには、`global.gitaly.tls.enabled: true`を設定します。 + + ```yaml + global: + gitaly: + tls: + enabled: true + ``` + + インスタンスごとに有効にするには、そのエントリに`tlsEnabled: true`を設定します。 + + ```yaml + global: + gitaly: + external: + - name: default + hostname: node1.git.example.com + tlsEnabled: true + ``` + +{{< alert type="note" >}} + +これには有効なシークレット名とキーを任意に選択できますが、シークレット内のすべてのキーがマウントされるため、`customCAs`で指定されたすべてのシークレット間でキーが一意であることを確認してください。これは_クライアント側_であるため、証明書のキーを指定する**必要はありません**。 + +{{< /alert >}} + +## GitLabがGitalyに接続できることをテストする {#test-that-gitlab-can-connect-to-gitaly} + +GitLabが外部Gitalyサーバーに接続できることを確認するには: + +```shell +kubectl exec -it -- gitlab-rake gitlab:gitaly:check +``` + +TLSでGitalyを使用している場合は、GitLab ChartがGitaly証明書を信頼しているかどうかを確認することもできます。 + +```shell +kubectl exec -it -- echo | /usr/bin/openssl s_client -connect : +``` + +## Gitaly Chartから外部Gitalyへの移行 {#migrate-from-gitaly-chart-to-external-gitaly} + +Gitaly Chartを使用してGitalyサービスを提供しており、すべてのリポジトリを外部Gitalyサービスに移行する必要がある場合は、次のいずれかの方法で実行できます。 + +- [リポジトリストレージ移動APIで移行する（推奨）](#migrate-with-the-repository-storage-moves-api)。 +- [バックアップ/復元方式で移行する](#migrate-with-the-backuprestore-method)。 + +### リポジトリストレージ移動APIを使用した移行 {#migrate-with-the-repository-storage-moves-api} + +この方法: + +- [リポジトリストレージ移動API](https://docs.gitlab.com/api/project_repository_storage_moves/)を使用して、リポジトリをGitaly Chartから外部Gitalyサービスに移行します。 +- ダウンタイムなしで実行できます。 +- 外部GitalyサービスがGitalyポッドと同じVPC/ゾーン内にある必要があります。 +- [Praefect Chart](../../charts/gitlab/praefect/_index.md)ではテストされておらず、サポートされていません。 + +#### ステップ1:外部GitalyサービスまたはGitalyクラスターをセットアップする {#step-1-set-up-external-gitaly-service-or-gitaly-cluster} + +[外部Gitaly](https://docs.gitlab.com/administration/gitaly/configure_gitaly/)または[外部Gitalyクラスター](https://docs.gitlab.com/administration/gitaly/praefect/)をセットアップします。これらのステップの一部として、ChartインストールからのGitalyトークンとGitLab Shellシークレットを提供する必要があります: + +```shell +# Get the GitLab Shell secret +kubectl get secret -gitlab-shell-secret -ojsonpath='{.data.secret}' | base64 -d + +# Get the Gitaly token +kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 -d +``` + +{{< tabs >}} + +{{< tab title="Gitaly" >}} + +- ここで抽出されたGitalyトークンは、`AUTH_TOKEN`の値に使用する必要があります。 +- ここで抽出されたGitLab Shellシークレットは、`shellsecret`の値に使用する必要があります。 + +{{< /tab >}} + +{{< tab title="Gitalyクラスター" >}} + +- ここで抽出されたGitalyトークンは、`PRAEFECT_EXTERNAL_TOKEN`に使用する必要があります。 +- ここで抽出されたGitLab Shellシークレットは、`GITLAB_SHELL_SECRET_TOKEN`に使用する必要があります。 + +{{< /tab >}} + +{{< /tabs >}} + +最後に、外部Gitalyサービスのファイアウォールが、構成されたGitalyポートでKubernetesポッドIP範囲のトラフィックを許可していることを確認します。 + +#### ステップ2:新しいGitalyサービスを使用するようにインスタンスを設定する {#step-2-configure-instance-to-use-new-gitaly-service} + +1. 外部Gitalyを使用するようにGitLabを設定します。メインの`gitlab.yml`設定ファイルにGitalyへの参照がある場合は、それらを削除し、次の内容で新しい`mixed-gitaly.yml`ファイルを作成します。 + + 以前に追加のGitalyストレージを定義した場合は、新しい設定で同じ名前の一致するGitalyストレージが指定されていることを確認する必要があります。そうしない場合、復元操作は失敗します。 + + TLSを構成する場合は、[TLS経由で外部Gitalyへの接続](#connecting-to-external-gitaly-over-tls)セクションを参照してください: + + {{< tabs >}} + + {{< tab title="Gitaly" >}} + + ```yaml + global: + gitaly: + internal: + names: + - default + external: + - name: ext-gitaly # required + hostname: node1.git.example.com # required + port: 8075 # optional, default shown + tlsEnabled: false # optional, overrides gitaly.tls.enabled + ``` + + {{< /tab >}} + + {{< tab title="Gitalyクラスター" >}} + + ```yaml + global: + gitaly: + internal: + names: + - default + external: + - name: ext-gitaly-cluster # required + hostname: ha.git.example.com # required + port: 2305 # Praefect uses port 2305 + tlsEnabled: false # optional, overrides gitaly.tls.enabled + ``` + + {{< /tab >}} + + {{< /tabs >}} + +1. `gitlab.yml`ファイルと`mixed-gitaly.yml`ファイルを使用して、新しい設定を適用します: + + ```shell + helm upgrade --install gitlab gitlab/gitlab \ + -f gitlab.yml \ + -f mixed-gitaly.yml + ``` + +1. Toolboxポッドで、GitLabが外部Gitalyに正常に接続できることを確認します: + + ```shell + kubectl exec -it -- gitlab-rake gitlab:gitaly:check + ``` + +1. 外部GitalyがChartインストールに接続できることを確認します: + + {{< tabs >}} + + {{< tab title="Gitaly" >}} + + GitalyサービスがGitLab APIへのコールバックを正常に実行できることを確認します: + + ```shell + sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml + ``` + + {{< /tab >}} + + {{< tab title="Gitalyクラスター" >}} + + すべてのPraefectノードで、PraefectサービスがGitalyノードに接続できることを確認します: + + ```shell + # Run on Praefect nodes + sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes + ``` + + すべてのGitalyノードで、GitalyサービスがGitLab APIへのコールバックを正常に実行できることを確認します: + + ```shell + # Run on Gitaly nodes + sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml + ``` + + {{< /tab >}} + + {{< /tabs >}} + +#### ステップ3:GitalyポッドのIPとホスト名を取得する {#step-3-get-the-gitaly-pod-ip-and-hostnames} + +リポジトリストレージ移動APIを成功させるには、外部Gitalyサービスがポッドサービスホスト名を使用してGitalyポッドに接続できる必要があります。ポッドサービスホスト名を解決できるようにするには、Gitalyプロセスを実行している各外部Gitalyサービスのhostsファイルにホスト名を追加する必要があります。 + +1. Gitalyポッドのリストと、それぞれの内部IPアドレス/ホスト名をフェッチします: + + ```shell + kubectl get pods -l app=gitaly -o jsonpath='{range .items[*]}{.status.podIP}{"\t"}{.spec.hostname}{"."}{.spec.subdomain}{"."}{.metadata.namespace}{".svc\n"}{end}' + ``` + +1. Gitalyプロセスを実行している各外部Gitalyサービスの`/etc/hosts`ファイルに、最後のステップからの出力を追加します。 +1. Gitalyポッドのホスト名が、Gitalyプロセスを実行している各外部Gitalyサービスからpingできることを確認します: + + ```shell + ping + ``` + +接続が確認されたら、リポジトリストレージの移動のスケジュールに進むことができます。 + +#### ステップ4:リポジトリストレージの移動をスケジュールする {#step-4-schedule-the-repository-storage-move} + +[リポジトリの移動](https://docs.gitlab.com/administration/operations/moving_repositories/#moving-repositories)で示されているステップに従って、移動をスケジュールします。 + +#### ステップ5:最終的な設定と検証 {#step-5-final-configuration-and-validation} + +1. 複数のGitalyストレージがある場合は、[新しいリポジトリの保存場所を設定](https://docs.gitlab.com/administration/repository_storage_paths/#configure-where-new-repositories-are-stored)します。 + +1. 外部Gitaly構成を含む、将来のために統合された`gitlab.yml`を生成することを検討してください: + + ```shell + helm get values -o yaml > gitlab.yml + ``` + +1. `gitlab.yml`ファイルで内部Gitalyサブチャートを無効にし、新しい`default`リポジトリストレージを外部Gitalyサービスに向けます。[GitLabにはデフォルトのリポジトリストレージが必要です](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#gitlab-requires-a-default-repository-storage): + + {{< tabs >}} + + {{< tab title="Gitaly" >}} + + ```yaml + global: + gitaly: + enabled: false # Disable the internal Gitaly subchart + external: + - name: ext-gitaly # required + hostname: node1.git.example.com # required + port: 8075 # optional, default shown + tlsEnabled: false # optional, overrides gitaly.tls.enabled + - name: default # Add the default repository storage, use the same settings as ext-gitaly + hostname: node1.git.example.com + port: 8075 + tlsEnabled: false + ``` + + {{< /tab >}} + + {{< tab title="Gitalyクラスター" >}} + + ```yaml + global: + gitaly: + enabled: false # Disable the internal Gitaly subchart + external: + - name: ext-gitaly-cluster # required + hostname: ha.git.example.com # required + port: 2305 # Praefect uses port 2305 + tlsEnabled: false # optional, overrides gitaly.tls.enabled + - name: default # Add the default repository storage, use the same settings as ext-gitaly-cluster + hostname: ha.git.example.com + port: 2305 + tlsEnabled: false + ``` + + {{< /tab >}} + + {{< /tabs >}} + +1. 新しい設定を適用します: + + ```shell + helm upgrade --install gitlab gitlab/gitlab \ + -f gitlab.yml + ``` + +1. オプション。[GitalyポッドのIPとホスト名を取得する](#step-3-get-the-gitaly-pod-ip-and-hostnames)ステップに従って、各外部Gitaly `/etc/hosts`ファイルに加えられた変更を削除します。 + +1. すべてが期待どおりに動作していることを確認したら、Gitaly PVCを削除できます: + + 警告:すべてが期待どおりに動作していることを再確認するまで、Gitaly PVCを削除しないでください。 + + ```shell + kubectl delete pvc repo-data--gitaly-0 + ``` + +### バックアップ/復元方式で移行する {#migrate-with-the-backuprestore-method} + +この方法: + +- リポジトリをGitaly Chart PersistentVolumeClaim (PVC) からバックアップし、それらを外部Gitalyサービスに復元します。 +- すべてのユーザーにダウンタイムが発生します。 +- [Praefect Chart](../../charts/gitlab/praefect/_index.md)ではテストされておらず、サポートされていません。 + +#### ステップ1:GitLab Chartの現在のリリースのリビジョンを取得する {#step-1-get-the-current-release-revision-of-the-gitlab-chart} + +移行中に問題が発生する可能性は低いですが、GitLab Chartの現在のリリースのリビジョンを取得してください。出力をコピーして、[ロールバック](#rollback)を実行する必要がある場合に備えて、脇に置いてください: + +```shell +helm history --max=1 +``` + +#### ステップ2:外部GitalyサービスまたはGitalyクラスターをセットアップする {#step-2-setup-external-gitaly-service-or-gitaly-cluster} + +[外部Gitaly](https://docs.gitlab.com/administration/gitaly/configure_gitaly/)または[外部Gitalyクラスター](https://docs.gitlab.com/administration/gitaly/praefect/)をセットアップします。これらのステップの一部として、ChartインストールからのGitalyトークンとGitLab Shellシークレットを提供する必要があります: + +```shell +# Get the GitLab Shell secret +kubectl get secret -gitlab-shell-secret -ojsonpath='{.data.secret}' | base64 -d + +# Get the Gitaly token +kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 -d +``` + +{{< tabs >}} + +{{< tab title="Gitaly" >}} + +- ここで抽出されたGitalyトークンは、`AUTH_TOKEN`の値に使用する必要があります。 +- ここで抽出されたGitLab Shellシークレットは、`shellsecret`の値に使用する必要があります。 + +{{< /tab >}} + +{{< tab title="Gitalyクラスター" >}} + +- ここで抽出されたGitalyトークンは、`PRAEFECT_EXTERNAL_TOKEN`に使用する必要があります。 +- ここで抽出されたGitLab Shellシークレットは、`GITLAB_SHELL_SECRET_TOKEN`に使用する必要があります。 + +{{< /tab >}} + +{{< /tabs >}} + +#### ステップ3:移行中にGitの変更が行われないことを確認する {#step-3-verify-no-git-changes-can-be-made-during-migration} + +移行のデータ整合性を確保するために、次の手順でGitリポジトリに加えられる変更を防ぎます: + +**1\.メンテナンスモードを有効にする** + +GitLab Enterprise Editionを使用している場合は、UI、API、またはRailsコンソールから[メンテナンスモード](https://docs.gitlab.com/administration/maintenance_mode/#enable-maintenance-mode)を有効にします: + +```shell +kubectl exec -it -- gitlab-rails runner 'Gitlab::CurrentSettings.update!(maintenance_mode: true)' +``` + +**2\.Runnerポッドをスケールダウンする** + +GitLab Community Editionを使用している場合は、クラスターで実行されているGitLab Runnerポッドをスケールダウンする必要があります。これにより、RunnerがGitLabに接続してCI/CDジョブを処理できなくなります。 + +GitLab Enterprise Editionを使用している場合、このステップはオプションです。[メンテナンスモード](https://docs.gitlab.com/administration/maintenance_mode/#enable-maintenance-mode)により、クラスター内のRunnerがGitLabに接続できなくなるためです。 + +```shell +# Make note of the current number of replicas for Runners so we can scale up to this number later +kubectl get deploy -lapp=gitlab-gitlab-runner,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' + +# Scale down the Runners pods to zero +kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas=0 +``` + +**3\.CIジョブが実行されていないことを確認する** + +管理者エリアで、**CI/CD > ジョブ**に移動します。このページにはすべてのジョブが表示されますが、**実行中**状態のジョブがないことを確認します。次のステップに進む前に、ジョブが完了するまで待つ必要があります。 + +**4\.Sidekiq cronジョブを無効にする** + +移行中にSidekiqジョブがスケジュールおよび実行されないようにするには、すべてのSidekiq cronジョブを無効にします: + +```shell +kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:disable!)' +``` + +**5\.バックグラウンドジョブが実行されていないことを確認する** + +次のステップに進む前に、エンキューされたジョブまたは進行中のジョブが完了するまで待つ必要があります。 + +1. 管理者エリアで、[**モニタリング**](https://docs.gitlab.com/administration/admin_area/#background-jobs)に移動し、**バックグラウンドジョブ**を選択します。 +1. Sidekiqダッシュボードで、**キュー**を選択し、次に**ライブポール**を選択します。 +1. **ビジー**と**エンキュー済み**が0になるまで待ちます。 + + ![Sidekiqのバックグラウンドジョブ](img/sidekiq_bg_jobs_v16_5.png) + +**6\.SidekiqポッドとWebserviceポッドをスケールダウンする** + +整合性のあるバックアップを確実に行うために、SidekiqポッドとWebserviceポッドをスケールダウンします。両方のサービスは後の段階でスケールアップされます: + +- Sidekiqポッドは復元ステップ中にスケールバックされます +- Webserviceポッドは、接続をテストするために外部Gitalyサービスに切り替えた後にスケールバックされます + +```shell +# Make note of the current number of replicas for Sidekiq and Webservice so we can scale up to this number later +kubectl get deploy -lapp=sidekiq,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' +kubectl get deploy -lapp=webservice,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' + +# Scale down the Sidekiq and Webservice pods to zero +kubectl scale deploy -lapp=sidekiq,release= --replicas=0 +kubectl scale deploy -lapp=webservice,release= --replicas=0 +``` + +**7\.クラスターへの外部接続を制限する** + +ユーザーと外部GitLab RunnerがGitLabに変更を加えないようにするには、GitLabへの不要な接続をすべて制限する必要があります。 + +これらのステップが完了すると、復元が完了するまで、ブラウザでGitLabを完全に使用できなくなります。 + +移行中にクラスターを新しい外部Gitalyサービスがアクセスできるようにするには、外部GitalyサービスのIPアドレスを唯一の外部例外として`nginx-ingress`構成に追加する必要があります。 + +1. 次の内容で`ingress-only-allow-ext-gitaly.yml`ファイルを作成します: + + ```yaml + nginx-ingress: + controller: + service: + loadBalancerSourceRanges: + - "x.x.x.x/32" + ``` + + `x.x.x.x`は、外部GitalyサービスのIPアドレスである必要があります。 + +1. `gitlab.yml`ファイルと`ingress-only-allow-ext-gitaly.yml`ファイルの両方を使用して、新しい設定を適用します: + + ```shell + helm upgrade gitlab/gitlab \ + -f gitlab.yml \ + -f ingress-only-allow-ext-gitaly.yml + ``` + +**8\.リポジトリチェックサムのリストを作成する** + +バックアップを実行する前に、[すべてのGitLabリポジトリを確認](https://docs.gitlab.com/administration/raketasks/check/#check-all-gitlab-repositories)し、リポジトリチェックサムのリストを作成します。移行後にチェックサムを`diff`できるように、出力をファイルにパイプします: + +```shell +kubectl exec -it -- gitlab-rake gitlab:git:checksum_projects > ~/checksums-before.txt +``` + +#### ステップ4:すべてのリポジトリをバックアップする {#step-4-backup-all-repositories} + +リポジトリの[バックアップを作成](../../backup-restore/backup.md#create-the-backup)します: + +```shell +kubectl exec -it -- backup-utility --skip artifacts,ci_secure_files,db,external_diffs,lfs,packages,pages,registry,terraform_state,uploads +``` + +#### ステップ5:新しいGitalyサービスを使用するようにインスタンスを設定する {#step-5-configure-instance-to-use-new-gitaly-service} + +1. Gitalyサブチャートを無効にし、外部Gitalyを使用するようにGitLabを設定します。メインの`gitlab.yml`設定ファイルにGitalyへの参照がある場合は、それらを削除し、次の内容で新しい`external-gitaly.yml`ファイルを作成します: + + 以前に追加のGitalyストレージを定義した場合は、新しい設定で同じ名前の一致するGitalyストレージが指定されていることを確認する必要があります。そうしない場合、復元操作は失敗します。 + + TLSを構成する場合は、[TLS経由で外部Gitalyへの接続](#connecting-to-external-gitaly-over-tls)セクションを参照してください: + + {{< tabs >}} + + {{< tab title="Gitaly" >}} + + ```yaml + global: + gitaly: + enabled: false + external: + - name: default # required + hostname: node1.git.example.com # required + port: 8075 # optional, default shown + tlsEnabled: false # optional, overrides gitaly.tls.enabled + ``` + + {{< /tab >}} + + {{< tab title="Gitalyクラスター" >}} + + ```yaml + global: + gitaly: + enabled: false + external: + - name: default # required + hostname: ha.git.example.com # required + port: 2305 # Praefect uses port 2305 + tlsEnabled: false # optional, overrides gitaly.tls.enabled + ``` + + {{< /tab >}} + + {{< /tabs >}} + +1. `gitlab.yml`ファイル、`ingress-only-allow-ext-gitaly.yml`ファイル、および`external-gitaly.yml`ファイルを使用して、新しい設定を適用します: + + ```shell + helm upgrade --install gitlab gitlab/gitlab \ + -f gitlab.yml \ + -f ingress-only-allow-ext-gitaly.yml \ + -f external-gitaly.yml + ``` + +1. Webserviceポッドが実行されていない場合は、元のレプリカ数にスケールアップします。これは、次のステップでGitLabから外部Gitalyへの接続をテストするために必要です。 + + ```shell + kubectl scale deploy -lapp=webservice,release= --replicas= + ``` + +1. Toolboxポッドで、GitLabが外部Gitalyに正常に接続できることを確認します: + + ```shell + kubectl exec -it -- gitlab-rake gitlab:gitaly:check + ``` + +1. 外部GitalyがChartインストールに接続できることを確認します: + + {{< tabs >}} + + {{< tab title="Gitaly" >}} + + GitalyサービスがGitLab APIへのコールバックを正常に実行できることを確認します: + + ```shell + sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml + ``` + + {{< /tab >}} + + {{< tab title="Gitalyクラスター" >}} + + すべてのPraefectノードで、PraefectサービスがGitalyノードに接続できることを確認します: + + ```shell + # Run on Praefect nodes + sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes + ``` + + すべてのGitalyノードで、GitalyサービスがGitLab APIへのコールバックを正常に実行できることを確認します: + + ```shell + # Run on Gitaly nodes + sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml + ``` + + {{< /tab >}} + + {{< /tabs >}} + +#### ステップ6:リポジトリのバックアップを復元して検証する {#step-6-restore-and-validate-repository-backup} + +1. 以前に作成した[バックアップファイルを復元](../../backup-restore/restore.md#restoring-the-backup-file)します。その結果、リポジトリは構成された外部GitalyまたはGitalyクラスターにコピーされます。 + +1. [すべてのGitLabリポジトリを確認](https://docs.gitlab.com/administration/raketasks/check/#check-all-gitlab-repositories)し、リポジトリチェックサムのリストを作成します。次のステップでチェックサムを`diff`できるように、出力をファイルにパイプします。 + + ```shell + kubectl exec -it -- gitlab-rake gitlab:git:checksum_projects > ~/checksums-after.txt + ``` + +1. リポジトリのの前後で、リポジトリのチェックサムを比較します。チェックサムが同一の場合、このコマンドは出力を返しません。 + + ```shell + diff ~/checksums-before.txt ~/checksums-after.txt + ``` + + 特定の行の`diff`出力で空白のチェックサムが`0000000000000000000000000000000000000000`に変化している場合、これは想定どおりであり、無視しても問題ありません。 + +#### ステップ7:最終設定と {#step-7-final-configuration-and-validation} + +1. 外部ユーザーとGitLabがGitLabに再度できるように、`gitlab.yml`ファイルと`external-gitaly.yml`ファイルを適用します。`ingress-only-allow-ext-gitaly.yml`を指定しないため、制限が削除されます。 + + ```shell + helm upgrade gitlab/gitlab \ + -f gitlab.yml \ + -f external-gitaly.yml + ``` + + 外部のを含む、将来のために`gitlab.yml`を生成することを検討してください。 + + ```shell + helm get values gitlab/gitlab -o yaml > gitlab.yml + ``` + +1. Edition（EE）/>を使用している場合は、[メンテナンスモード](https://docs.gitlab.com/administration/maintenance_mode/#enable-maintenance-mode)を、、またはのいずれかで無効にします。 + + ```shell + kubectl exec -it -- gitlab-rails runner 'Gitlab::CurrentSettings.update!(maintenance_mode: false)' + ``` + +1. 複数のストレージがある場合は、[新しいリポジトリの保存場所をしてください](https://docs.gitlab.com/administration/repository_storage_paths/#configure-where-new-repositories-are-stored)。 + +1. を有効にします: + + ```shell + kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)' + ``` + +1. が実行されていない場合は、 を元の数にします: + + ```shell + kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas= + ``` + +1. すべてが期待どおりに動作していることを確認したら、 を削除できます: + + 警告:すべてが期待どおりに動作していることを再確認するまで、[手順6](#step-6-restore-and-validate-repository-backup)に従ってチェックサムが一致することを確認するまで、 を削除しないでください。 + + ```shell + kubectl delete pvc repo-data--gitaly-0 + ``` + +#### {#rollback} + +問題が発生した場合は、サブが再度使用されるように、変更をできます。 + +を正常に行うには、元の が存在している必要があります。 + +1. [手順1で取得したリビジョン番号を使用して、 を以前のにします: の現在のリビジョンを取得します](#step-1-get-the-current-release-revision-of-the-gitlab-chart): + + ```shell + helm rollback + ``` + +1. が実行されていない場合は、 を元の数にします: + + ```shell + kubectl scale deploy -lapp=webservice,release= --replicas= + ``` + +1. が実行されていない場合は、 を元の数にします: + + ```shell + kubectl scale deploy -lapp=sidekiq,release= --replicas= + ``` + +1. 以前に無効にした場合は、 を有効にします: + + ```shell + kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)' + ``` + +1. が実行されていない場合は、 を元の数にします: + + ```shell + kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas= + ``` + +1. Edition（EE）/>を使用している場合は、有効になっている場合は、[メンテナンスモード](https://docs.gitlab.com/administration/maintenance_mode/#disable-maintenance-mode)を無効にします。 + +### 関連ドキュメント {#related-documentation} + +- [ にする](https://docs.gitlab.com/administration/gitaly/#migrate-to-gitaly-cluster) diff --git a/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md new file mode 100644 index 0000000000..f231ee2cba --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md @@ -0,0 +1,102 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: スタンドアロンGitalyの設定 +--- + +この手順では、Ubuntu用の[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)を使用します。このパッケージは、chartsのサービスとの互換性が保証されているサービスのバージョンを提供します。 + +## 仮想マシンをLinuxパッケージで作成 {#create-vm-with-the-linux-package} + +任意のプロバイダーで、またはローカルで仮想マシンを作成します。これは、VirtualBox、KVM、Bhyveでテストされました。インスタンスがクラスターから到達可能であることを確認してください。 + +作成した仮想マシンにUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのパッケージが最新の状態であることを確認してください。ネットワーク構築とホスト名を設定します。ホスト名/IPをメモし、それがKubernetesクラスターから解決可能で、到達可能であることを確認します。トラフィックを許可するために、ファイアウォールポリシーが適切に設定されていることを確認してください。 + +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。Linuxパッケージのインストールを実行するときは、**_行わないでください_**、`EXTERNAL_URL=`の値を指定します。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 + +## Linuxパッケージのインストールを設定 {#configure-linux-package-installation} + +最小限の`gitlab.rb`ファイルを`/etc/gitlab/gitlab.rb`に配置するように作成します。*非常に*、このノードで有効になっていることを明示的に指定します。[Gitalyを独自のサーバー上で実行](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#run-gitaly-on-its-own-server)するためのドキュメントに基づいた次のコンテンツを使用します。 + +_**注**:以下の値は置き換える必要があります_ + +- `AUTH_TOKEN`を[`gitaly-secret`シークレット](../../installation/secrets.md#gitaly-secret)の値に置き換える必要があります +- `GITLAB_URL`は、GitLabインスタンスのURLに置き換える必要があります +- `SHELL_TOKEN`を[`gitlab-shell-secret`シークレット](../../installation/secrets.md#gitlab-shell-secret)の値に置き換える必要があります + + + +```ruby +# Avoid running unnecessary services on the Gitaly server +postgresql['enable'] = false +redis['enable'] = false +nginx['enable'] = false +puma['enable'] = false +sidekiq['enable'] = false +gitlab_workhorse['enable'] = false +gitlab_exporter['enable'] = false +gitlab_kas['enable'] = false + +# If you run a seperate monitoring node you can disable these services +prometheus['enable'] = false +alertmanager['enable'] = false + +# If you don't run a separate monitoring node you can +# Enable Prometheus access & disable these extra services +# This makes Prometheus listen on all interfaces. You must use firewalls to restrict access to this address/port. +# prometheus['listen_address'] = '0.0.0.0:9090' +# prometheus['monitor_kubernetes'] = false + +# If you don't want to run monitoring services uncomment the following (not recommended) +# node_exporter['enable'] = false + +# Prevent database connections during 'gitlab-ctl reconfigure' +gitlab_rails['auto_migrate'] = false + +# Configure the gitlab-shell API callback URL. Without this, `git push` will +# fail. This can be your 'front door' GitLab URL or an internal load +# balancer. +gitlab_rails['internal_api_url'] = 'GITLAB_URL' +# Token used by Gitaly and GitLab shell to authenticate with GitLab +gitaly['gitlab_secret'] = 'SHELL_TOKEN' + +gitaly['configuration'] = { + # Make Gitaly accept connections on all network interfaces. You must use + # firewalls to restrict access to this address/port. + # Comment out following line if you only want to support TLS connections + listen_addr: '0.0.0.0:8075', + # Authentication token to ensure only authorized servers can communicate with + # Gitaly server + auth: { + token: 'AUTH_TOKEN', + }, +} + +git_data_dirs({ + 'default' => { + 'path' => '/var/opt/gitlab/git-data' + }, + 'storage1' => { + 'path' => '/mnt/gitlab/git-data' + }, +}) + +# To use TLS for Gitaly you need to add +gitaly['tls_listen_addr'] = "0.0.0.0:8076" +gitaly['certificate_path'] = "path/to/cert.pem" +gitaly['key_path'] = "path/to/key.pem" +``` + +`gitlab.rb`を作成したら、`gitlab-ctl reconfigure`を使用してパッケージを再設定します。タスクが完了したら、`gitlab-ctl status`を使用して実行中のプロセスを確認します。出力は次のようになります。 + +```plaintext +# gitlab-ctl status +run: gitaly: (pid 30562) 77637s; run: log: (pid 30561) 77637s +run: logrotate: (pid 4856) 1859s; run: log: (pid 31262) 77460s +``` diff --git a/doc-locale/ja-jp/advanced/external-gitlab-pages/_index.md b/doc-locale/ja-jp/advanced/external-gitlab-pages/_index.md new file mode 100644 index 0000000000..0e4ce17edc --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-gitlab-pages/_index.md @@ -0,0 +1,74 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部GitLab PagesでGitLabチャートを設定する +--- + +このドキュメントでは、Linuxパッケージを使用して、クラスターの外部で設定されたGitLab PagesインスタンスでこのHelmチャートを設定する方法について説明します。[イシュー418259](https://gitlab.com/gitlab-org/gitlab/-/issues/418259)は、Helm Chartを使用して外部GitLab Pagesを持つLinuxパッケージ インスタンスのドキュメントを追加することを提案しています。 + +## 要件 {#requirements} + +1. [外部オブジェクトストレージ](../external-object-storage/_index.md)は、本番環境インスタンスに推奨されるため、使用する必要があります。 +1. GitLab Pagesとやり取りするための、Pages用の32バイト長のAPIシークレットキーのBase64エンコード形式。 + +## 既知の制限事項 {#known-limitations} + +1. [GitLab Pagesアクセス制御](https://docs.gitlab.com/user/project/pages/pages_access_control/)は、デフォルトではサポートされていません。 + +## 外部GitLab Pagesインスタンスを設定する {#configure-external-gitlab-pages-instance} + +1. Linuxパッケージを使用して[GitLabをインストール](https://about.gitlab.com/install/)します。 + +1. `/etc/gitlab/gitlab.rb`ファイルを編集し、その内容を次のスニペットに置き換えます。構成に合わせて以下の値を更新します。 + + ```ruby + roles ['pages_role'] + + # Root domain where Pages will be served. + pages_external_url '' # Example: 'http://pages.example.io' + + # Information regarding GitLab instance + gitlab_pages['gitlab_server'] = '' # Example: 'https://gitlab.example.com' + gitlab_pages['api_secret_key'] = '' + ``` + +1. `sudo gitlab-ctl reconfigure`を実行して変更を適用します。 + +## チャートを設定する {#configure-the-chart} + +1. Pagesデプロイメントを格納するために、オブジェクトストレージに`gitlab-pages`という名前のバケットを作成します。 + +1. APIシークレットキーのBase64エンコード形式を値として持つシークレット`gitlab-pages-api-key`を作成します。 + + ```shell + kubectl create secret generic gitlab-pages-api-key --from-literal="shared_secret=" + ``` + +1. 次の構成スニペットを参照して、必要なエントリをvaluesファイルに追加します。 + + ```yaml + global: + pages: + path: '/srv/gitlab/shared/pages' + host: + port: '80' # Set to 443 if Pages is served over HTTPS + https: false # Set to true if Pages is served over HTTPS + artifactsServer: true + objectStore: + enabled: true + bucket: 'gitlab-pages' + apiSecret: + secret: gitlab-pages-api-key + key: shared_secret + extraEnv: + PAGES_UPDATE_LEGACY_STORAGE: true # Bypass automatic disabling of disk storage + ``` + + {{< alert type="note" >}} + +`PAGES_UPDATE_LEGACY_STORAGE`環境変数をtrueに設定すると、機能フラグ`pages_update_legacy_storage`が有効になり、Pagesがローカルディスクにデプロイされます。オブジェクトストレージに移行する際は、この変数を削除することを忘れないでください。 + + {{< /alert >}} + +1. この構成を使用して[チャートをデプロイ](../../installation/deployment.md#deploy-using-helm)します。 diff --git a/doc-locale/ja-jp/advanced/external-mattermost/_index.md b/doc-locale/ja-jp/advanced/external-mattermost/_index.md new file mode 100644 index 0000000000..cf3071e224 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-mattermost/_index.md @@ -0,0 +1,71 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Mattermost Team EditionでGitLabチャートを設定する +--- + +このドキュメントでは、既存のGitLab Helmチャートのデプロイ環境に近接してMattermost Team Edition Helm Chartをインストールする方法について説明します。 + +Mattermost Helm Chartは別のネームスペースにインストールされているため、クラスター全体のIngressと証明書リソースを管理するために、`cert-manager`および`nginx-ingress`を設定することをお勧めします。その他の設定情報については、[Mattermost Helm設定ガイド](https://github.com/mattermost/mattermost-helm/tree/master/charts/mattermost-team-edition#configuration)を参照してください。 + +## 前提要件 {#prerequisites} + +- Kubernetesクラスターが稼働していること。 +- [Helm](https://helm.sh/docs/intro/install/) v3 + +{{< alert type="note" >}} + +Teamエディションの場合、実行できるレプリカは1つだけです。 + +{{< /alert >}} + +## Mattermost Team Edition Helm Chartをデプロイする {#deploy-the-mattermost-team-edition-helm-chart} + +Mattermost Team Edition Helm Chartをインストールしたら、次のコマンドを使用してデプロイできます。 + +```shell +helm repo add mattermost https://helm.mattermost.com +helm repo update +helm upgrade --install mattermost -f values.yaml mattermost/mattermost-team-edition +``` + +ポッドが実行されるまで待ちます。次に、設定で指定したIngressホストを使用して、Mattermostサーバーにアクセスします。 + +その他の[設定](https://github.com/mattermost/mattermost-helm/tree/master/charts/mattermost-team-edition#configuration)情報については、[Mattermost Helm](https://github.com/mattermost/mattermost-helm/tree/master/charts/mattermost-team-edition#configuration)設定ガイドを参照してください。これについて何か問題が発生した場合は、[Mattermost Helm Chart](https://github.com/mattermost/mattermost-helm/issues) issue repositoryまたは[Mattermost Forum](https://forum.mattermost.com/search?q=helm)を参照してください。 + +## GitLab Helmチャートをデプロイする {#deploy-gitlab-helm-chart} + +[GitLab Helmチャート](../../_index.md)をデプロイするには、こちらに記載されている手順に従ってください。 + +インストールする簡単な方法は次のとおりです。 + +```shell +helm repo add gitlab https://charts.gitlab.io/ +helm repo update +helm upgrade --install gitlab gitlab/gitlab \ + --timeout 600s \ + --set global.hosts.domain= \ + --set global.hosts.externalIP= \ + --set certmanager-issuer.email= +``` + +- ``: 目的のドメイン（`gitlab.example.com`など）。 +- ``: Kubernetesクラスターを指す外部IP。 +- ``: TLS証明書を取得するために、Let's Encryptにregisterするメール。 + +[GitLab](../../installation/deployment.md#initial-login)インスタンスをデプロイしたら、最初のログインの手順に従ってください。 + +## GitLabでOAuthアプリケーションをCreateする {#create-an-oauth-application-with-gitlab} + +プロセスの次の部分は、GitLab SSOインテグレーションの設定です。そのためには、Mattermostが[GitLab](https://docs.mattermost.com/deployment/sso-gitlab.html)を認証プロバイダーとして使用できるように、OAuthアプリケーションをCreateする必要があります。 + +{{< alert type="note" >}} + +デフォルトのGitLab SSOのみが正式にサポートされています。「Double SSO」(GitLab SSOが他のSSOソリューションにチェーンされている場合) は、サポートされていません。GitLab SSOをAD、LDAP、SAML、またはMFAアドオンに接続できる場合がありますが、特別なロジックが必要なため、公式にはサポートされておらず、一部のエクスペリエンスでは機能しないことがわかっています。 + +{{< /alert >}} + +## トラブルシューティング {#troubleshooting} + +提供されたものとは異なる[プロセス](https://docs.mattermost.com/install/troubleshooting.html?&redirect_source=mm-org)に従っており、認証および/またはデプロイの問題が発生した場合は、Mattermost troubleshooting forumまでお知らせください。 diff --git a/doc-locale/ja-jp/advanced/external-nginx/_index.md b/doc-locale/ja-jp/advanced/external-nginx/_index.md new file mode 100644 index 0000000000..3d6103ffa9 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-nginx/_index.md @@ -0,0 +1,77 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部のNGINX IngressコントローラーでGitLabチャートを設定する +--- + +このチャートは、公式の[NGINX Ingress](https://github.com/kubernetes/ingress-nginx)実装で使用するために`Ingress`リソースを設定します。NGINX Ingressコントローラーは、このチャートの一部としてデプロイされます。クラスター内で既に使用可能な既存のNGINX Ingressコントローラーを再利用したい場合に、このガイドが役立ちます。 + +## 外部IngressコントローラーのTCPサービス {#tcp-services-in-the-external-ingress-controller} + +GitLab Shellコンポーネントでは、ポート22 (デフォルト) でTCPトラフィックが通過する必要があります (変更可能)。IngressはTCPサービスを直接サポートしていないため、追加の設定が必要です。NGINX Ingressコントローラーは、[直接デプロイ](https://github.com/kubernetes/ingress-nginx/blob/master/docs/deploy/index.md) (Kubernetes仕様ファイルを使用) されたか、[公式Helm Chart](https://github.com/kubernetes/ingress-nginx)を通じてデプロイされた可能性があります。TCPパススルーの設定は、デプロイ方法によって異なります。 + +### 直接デプロイ {#direct-deployment} + +直接デプロイでは、NGINX Ingressコントローラーは`ConfigMap`を使用してTCPサービスを設定します (ドキュメントは[こちら](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md)を参照)。GitLabチャートが`gitlab`ネームスペースにデプロイされ、Helmリリースに`mygitlab`という名前が付けられていると仮定すると、`ConfigMap`は次のようになります。 + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: tcp-configmap-example +data: + 22: "gitlab/mygitlab-gitlab-shell:22" +``` + +その`ConfigMap`を入手したら、`--tcp-services-configmap`オプションを使用して、NGINX Ingressコントローラーの[ドキュメント](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/exposing-tcp-udp-services.md)に記載されているように有効にできます。 + +```yaml +args: + - /nginx-ingress-controller + - --tcp-services-configmap=gitlab/tcp-configmap-example +``` + +最後に、NGINX Ingressコントローラーの`Service`が、80および443に加えて、ポート22を公開していることを確認します。 + +### Helmデプロイ {#helm-deployment} + +[Helm Chart](https://github.com/kubernetes/ingress-nginx)を使用してNGINX Ingressコントローラーをインストールした場合、またはインストールする予定の場合は、コマンドラインを使用して値をチャートに追加する必要があります。 + +```shell +--set tcp.22="gitlab/mygitlab-gitlab-shell:22" +``` + +または`values.yaml`ファイル: + +```yaml +tcp: + 22: "gitlab/mygitlab-gitlab-shell:22" +``` + +値の形式は、上記の「直接デプロイ」セクションで説明されているものと同じです。 + +## GitLab Ingressオプションのカスタマイズ {#customize-the-gitlab-ingress-options} + +NGINX Ingressコントローラーは、どのIngressコントローラーが特定の`Ingress`にサービスを提供するかを示すために、アノテーションを使用します (ドキュメント[を参照](https://github.com/kubernetes/ingress-nginx#annotation-ingressclass))。`global.ingress.class`設定を使用して、このチャートで使用するIngressクラスを設定できます。必ず、この設定をHelmオプションで設定してください。 + +```shell +--set global.ingress.class=myingressclass +``` + +必ずしも必須ではありませんが、外部Ingressコントローラーを使用している場合は、このチャートでデフォルトでデプロイされるIngressコントローラーを無効にすることをお勧めします。 + +```shell +--set nginx-ingress.enabled=false +``` + +## カスタム証明書管理 {#custom-certificate-management} + +TLSオプションのスコープ全体は、[別の場所](../../installation/tls.md)に記載されています。 + +外部Ingressコントローラーを使用している場合は、外部cert-managerインスタンスを使用するか、他のカスタム方法で証明書を管理している場合もあります。TLSオプションに関する完全なドキュメントは[こちら](../../installation/tls.md)にありますが、このディスカッションの目的のために、cert-managerチャートを無効にし、組み込みの証明書リソースを検索しないようにGitLabコンポーネントチャートに指示するために設定する必要がある2つの値を示します。 + +```shell +--set installCertmanager=false +--set global.ingress.configureCertmanager=false +``` diff --git a/doc-locale/ja-jp/advanced/external-object-storage/_index.md b/doc-locale/ja-jp/advanced/external-object-storage/_index.md new file mode 100644 index 0000000000..486aff102c --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/_index.md @@ -0,0 +1,348 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部オブジェクトストレージでGitLabチャートを設定する +--- + +GitLabは、Kubernetes内の可用性の高い永続的なデータのためにオブジェクトストレージに依存しています。GitLabは、主要なクラウドオブジェクトストレージプロバイダー向けに、クラウド固有のサービスを介した静的な認証情報と一時的な認証情報の2種類の認証方法をサポートしています。 + +### 静的な認証情報 {#static-credentials} + +これらの認証情報は、すべてのプロバイダーにとって有効期間の長いアクセスキーとシークレットです。 + +- AWS S3:アクセスキーID + シークレットアクセスキー +- Google Cloud Storage:サービスアカウントJSONキーファイル +- Azure Blob Storage:ストレージアカウント名 + アクセスキー、またはクライアントID + テナントID + クライアントシークレット + +### Cloud IAMを介した一時的な認証情報 {#temporary-credentials-through-cloud-iam} + +GitLabは、動的な短期間の認証情報のために、プロバイダー固有のワークロード アイデンティティメカニズムを取得できます。 + +- AWS S3:[サービスアカウント](aws-iam-roles.md)のIAMロール（IRSA） +- Google Cloud Storage:[ワークロードアイデンティティフェデレーション](gke-workload-identity.md) +- Azure Blob Storage:Azure [Kubernetes](azure-workload-identity.md) [Service](azure-workload-identity.md)の[ワークロード](azure-workload-identity.md) [アイデンティティ](azure-workload-identity.md) + +これらの一時的な認証情報メカニズムにより、次の方法でセキュリティが向上します。 + +- 有効期間の長い静的な認証情報を排除します。 +- 認証情報の自動ローテーションを提供します。 +- きめ細かいアクセストークン アクセス制御を有効にします。 +- 認証情報の使用状況のログの生成をサポートします。 +- クラウドプロバイダーIAMポリシーと統合します。 + +## MinIOを無効にする {#disable-minio} + +デフォルトでは、`minio`という名前のS3互換ストレージソリューションがチャートとともにデプロイされます。本番環境品質のデプロイメントでは、Google Cloud StorageやAWS S3のようなホスティングされたオブジェクトストレージソリューションを使用することをお勧めします。 + +MinIOを無効にするには、このオプションを設定し、以下の関連ドキュメントに従ってください。 + +```shell +--set global.minio.enabled=false +``` + +[完全な設定の例](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/values-external-objectstorage.yaml)が、[例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples)で提供されています。 + +## Azure Blob Storage {#azure-blob-storage} + +Azure Blob [ストレージ](https://docs.gitlab.com/administration/object_storage/#storage-specific-configuration)の直接[サポート](https://docs.gitlab.com/administration/object_storage/#storage-specific-configuration)は、[アップロードされた添付ファイル、CIジョブ アーティファクト、LFS、および統合された設定を介してサポートされるその他のオブジェクトタイプで利用できます](https://docs.gitlab.com/administration/object_storage/#storage-specific-configuration)。以前のGitLabバージョンでは、[Azure MinIOゲートウェイ](azure-minio-gateway.md)が必要でした。 + +{{< alert type="note" >}} + +GitLabは、Docker [レジストリ](https://github.com/minio/minio/issues/9978)の[ストレージ](https://github.com/minio/minio/issues/9978)としてAzure MinIO [ゲートウェイ](https://github.com/minio/minio/issues/9978)を[サポート](https://github.com/minio/minio/issues/9978) [しません](https://github.com/minio/minio/issues/9978)。[対応するAzureの例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.azure.yaml)を参照して、[Dockerレジストリ](#docker-registry-images)を設定してください。 + +{{< /alert >}} + +Azureはコンテナという単語をblobのコレクションを示すために使用しますが、GitLabはバケットという用語で標準化されています。 + +Azure Blob [ストレージ](../../charts/globals.md#consolidated-object-storage)では、[統合されたオブジェクトストレージ設定](../../charts/globals.md#consolidated-object-storage)を使用する必要があります。単一のAzureストレージアカウント名とキーを、複数のAzureblobコンテナで使用する必要があります。オブジェクトタイプごとの個別の`connection`設定（たとえば、`artifacts`、`uploads`など）のカスタマイズは許可されていません。 + +Azure Blob [ストレージ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azurerm.yaml)を有効にするには、Azure `connection`を定義する例として[`rails.azurerm.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azurerm.yaml)を参照してください。これは、次のコマンドでシークレットとして読み込むことができます。 + +```shell +kubectl create secret generic gitlab-rails-storage --from-file=connection=rails.azurerm.yml +``` + +次に、MinIOを無効にして、これらのグローバル設定を設定します。 + +```shell +--set global.minio.enabled=false +--set global.appConfig.object_store.enabled=true +--set global.appConfig.object_store.connection.secret=gitlab-rails-storage +``` + +[デフォルト](../../charts/globals.md#specify-buckets)名 + +{{< alert type="note" >}} + +`Requests to the local network are not allowed`で失敗するリクエストが発生した場合は、[トラブルシューティング](#troubleshooting)セクション + +{{< /alert >}} + +## Dockerレジストリイメージ {#docker-registry-images} + +`registry`チャートのオブジェクトストレージの設定は、`registry.storage`キーと`global.registry.bucket`キーを介して行われます。 + +```shell +--set registry.storage.secret=registry-storage +--set registry.storage.key=config +--set global.registry.bucket=bucket-name +``` + +{{< alert type="note" >}} + +バケット名は、シークレットと`global.registry.bucket`の両方で設定する必要があります。このシークレットはレジストリサーバーで使用され、グローバルはGitLabバックアップで使用されます。 + +{{< /alert >}} + +[ストレージに関するレジストリ チャートのドキュメント](../../charts/registry/_index.md#storage)に従って[シークレット](../../charts/registry/_index.md#storage)を作成し、この[シークレット](../../charts/registry/_index.md#storage)を使用するように[チャート](../../charts/registry/_index.md#storage)を[設定](../../charts/registry/_index.md#storage)します。 + +[S3](https://distribution.github.io/distribution/storage-drivers/s3/)（S3互換[ストレージ](https://distribution.github.io/distribution/storage-drivers/s3/)。[Azure Blob Storage](#azure-blob-storage)を参照）、[Azure](https://distribution.github.io/distribution/storage-drivers/azure/)、および[GCS](https://distribution.github.io/distribution/storage-drivers/gcs/)ドライバーの例は、[`examples/objectstorage`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage)にあります。 + +- [`registry.s3.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.s3.yaml) +- [`registry.gcs.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.gcs.yaml) +- [`registry.azure.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.azure.yaml) + +### レジストリ 設定 {#registry-configuration} + +1. 使用するストレージ サービスを決定します。 +1. 適切なファイルを`registry-storage.yaml`にコピーします。 +1. 環境に適した値で編集します。 +1. [シークレット](../../charts/registry/_index.md#storage)を作成するには、[ストレージに関するレジストリ チャートのドキュメント](../../charts/registry/_index.md#storage)に従ってください。 +1. ドキュメント化されているようにチャートを設定します。 + +## LFS、アーティファクト、アップロード、パッケージ、外部差分、Terraformステート、依存プロキシ、セキュアファイル {#lfs-artifacts-uploads-packages-external-diffs-terraform-state-dependency-proxy-secure-files} + +LFS、アーティファクト、アップロード、パッケージ、外部差分、Terraformステート、セキュアファイル、および仮名化子のオブジェクトストレージの設定は、次のキーを介して行われます。 + +- `global.appConfig.lfs` +- `global.appConfig.artifacts` +- `global.appConfig.uploads` +- `global.appConfig.packages` +- `global.appConfig.externalDiffs` +- `global.appConfig.dependencyProxy` +- `global.appConfig.terraformState` +- `global.appConfig.ciSecureFiles` + +次の点にも注意してください。 + +- [デフォルト](../../charts/globals.md#specify-buckets)名 +- それぞれに異なるバケットが必要です。そうでない場合、バックアップからの復元が正しく機能しません。 +- MR差分を外部ストレージに保存することはデフォルトで有効になっていないため、`externalDiffs`のオブジェクトストレージ 設定を有効にするには、`global.appConfig.externalDiffs.enabled`キーに`true`値が必要です。 +- 依存プロキシ 機能はデフォルトで有効になっていないため、`dependencyProxy`のオブジェクトストレージ 設定を有効にするには、`global.appConfig.dependencyProxy.enabled`キーに`true`値が必要です。 + +以下は、設定オプションの例です。 + +```shell +--set global.appConfig.lfs.bucket=gitlab-lfs-storage +--set global.appConfig.lfs.connection.secret=object-storage +--set global.appConfig.lfs.connection.key=connection + +--set global.appConfig.artifacts.bucket=gitlab-artifacts-storage +--set global.appConfig.artifacts.connection.secret=object-storage +--set global.appConfig.artifacts.connection.key=connection + +--set global.appConfig.uploads.bucket=gitlab-uploads-storage +--set global.appConfig.uploads.connection.secret=object-storage +--set global.appConfig.uploads.connection.key=connection + +--set global.appConfig.packages.bucket=gitlab-packages-storage +--set global.appConfig.packages.connection.secret=object-storage +--set global.appConfig.packages.connection.key=connection + +--set global.appConfig.externalDiffs.bucket=gitlab-externaldiffs-storage +--set global.appConfig.externalDiffs.connection.secret=object-storage +--set global.appConfig.externalDiffs.connection.key=connection + +--set global.appConfig.terraformState.bucket=gitlab-terraform-state +--set global.appConfig.terraformState.connection.secret=object-storage +--set global.appConfig.terraformState.connection.key=connection + +--set global.appConfig.dependencyProxy.bucket=gitlab-dependencyproxy-storage +--set global.appConfig.dependencyProxy.connection.secret=object-storage +--set global.appConfig.dependencyProxy.connection.key=connection + +--set global.appConfig.ciSecureFiles.bucket=gitlab-ci-secure-files +--set global.appConfig.ciSecureFiles.connection.secret=object-storage +--set global.appConfig.ciSecureFiles.connection.key=connection +``` + +詳細については、[appConfigに関するチャート/globalsのドキュメント](../../charts/globals.md#configure-appconfig-settings)を参照してください。 + +[接続](../../charts/globals.md#connection)の詳細[ドキュメント](../../charts/globals.md#connection)同じシークレットをすべてに使用できます。 + +[AWS](https://fog.github.io/storage/#using-amazon-s3-and-fog)（[MinIOを使用したAzure](azure-minio-gateway.md)のようなS3互換）および[Google](https://fog.github.io/storage/#google-cloud-storage)プロバイダーの例は、[`examples/objectstorage`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage)にあります。 + +- [`rails.s3.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.s3.yaml) +- [`rails.gcs.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.gcs.yaml) +- [`rails.azure.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azure.yaml) +- [`rails.azurerm.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.azurerm.yaml) + +### S3暗号化 {#s3-encryption} + +GitLabは、[S3](https://aws.amazon.com/kms/) [バケット](https://aws.amazon.com/kms/)に[保存](https://docs.gitlab.com/administration/object_storage/#encrypted-s3-buckets)されているデータを[暗号化](https://aws.amazon.com/kms/)するために[Amazon KMS](https://aws.amazon.com/kms/)をサポートしています。これを有効にするには、次の2つの方法があります。 + +- AWSで、[デフォルト](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)の[暗号化](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)を使用するようにS3[バケット](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)を[設定](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html)します。 +- GitLabで、[サーバー側の暗号化](../../charts/globals.md#storage_options) [ヘッダー](../../charts/globals.md#storage_options)を有効にします。 + +これら2つのオプションは、相互に排他的ではありません。デフォルトの暗号化 ポリシーを設定できますが、サーバー側の暗号化 ヘッダーを有効にして、それらのデフォルトを上書きすることもできます。 + +詳細については、[暗号化](https://docs.gitlab.com/administration/object_storage/#encrypted-s3-buckets)されたS3[バケット](https://docs.gitlab.com/administration/object_storage/#encrypted-s3-buckets)に関するGitLab[ドキュメント](https://docs.gitlab.com/administration/object_storage/#encrypted-s3-buckets) + +### appConfig設定 {#appconfig-configuration} + +1. 使用するストレージ サービスを決定します。 +1. 適切なファイルを`rails.yaml`にコピーします。 +1. 環境に適した値で編集します。 +1. [シークレット](../../charts/globals.md#connection)を作成するには、[接続](../../charts/globals.md#connection)の詳細[ドキュメント](../../charts/globals.md#connection) +1. ドキュメント化されているようにチャートを設定します。 + +## バックアップ {#backups} + +バックアップもオブジェクトストレージに保存され、含まれているMinIOサービスではなく、外部を指すように設定する必要があります。バックアップ/復元手順では、2つの個別のバケットを使用します。 + +- バックアップを保存するためのバケット（`global.appConfig.backups.bucket`） +- 復元プロセス中に既存のデータを保持するための一時バケット（`global.appConfig.backups.tmpBucket`） + +AWS S3互換のオブジェクトストレージシステム、Google Cloud Storage、およびAzure Blob Storageがサポートされているバックエンドです。`global.appConfig.backups.objectStorage.backend`をAWS S3の場合は`s3`、Google Cloud Storageの場合は`gcs`、Azure Blob Storageの場合は`azure`に設定して、バックエンドタイプを設定できます。`gitlab.toolbox.backups.objectStorage.config`キーを介して接続 設定も指定する必要があります。 + +シークレットでGoogle Cloud Storageを使用する場合、`global.appConfig.backups.objectStorage.config.gcpProject`値を使用してGCPプロジェクトを設定する必要があります。 + +S3互換ストレージの場合: + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config +--set gitlab.toolbox.backups.objectStorage.config.key=config +``` + +シークレットを使用したGoogle Cloud Storage（GCS）の場合: + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +--set gitlab.toolbox.backups.objectStorage.backend=gcs +--set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id +--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config +--set gitlab.toolbox.backups.objectStorage.config.key=config +``` + +[GKE](gke-workload-identity.md)の[ワークロードアイデンティティフェデレーション](gke-workload-identity.md)を使用したGoogle Cloud Storage（GCS）の場合、[バックエンド](gke-workload-identity.md)と[バケット](gke-workload-identity.md)のみを設定する必要があります。`gitlab.toolbox.backups.objectStorage.config.secret`と`gitlab.toolbox.backups.objectStorage.config.key`が設定されていないことを確認して、クラスターが[GoogleのApplication Default Credentials](https://cloud.google.com/docs/authentication/application-default-credentials)を使用するようにします。 + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +--set gitlab.toolbox.backups.objectStorage.backend=gcs +``` + +Azure Blob Storageの場合: + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +--set gitlab.toolbox.backups.objectStorage.backend=azure +--set gitlab.toolbox.backups.objectStorage.config.secret=storage-config +--set gitlab.toolbox.backups.objectStorage.config.key=config +``` + +詳細については、[バックアップ/復元オブジェクトストレージ](../../backup-restore/_index.md#object-storage)の[ドキュメント](../../backup-restore/_index.md#object-storage) + +{{< alert type="note" >}} + +他のオブジェクトストレージの場所からファイルをバックアップまたは復元するには、すべてのGitLabバケットへの読み取り/書き込みに十分な権限を持つユーザーとして認証するように設定ファイルを設定する必要があります。 + +{{< /alert >}} + +### バックアップ ストレージの例 {#backups-storage-example} + +1. `storage.config`ファイルを作成します。 + + - Amazon S3では、コンテンツは[s3cmd設定ファイル形式](https://s3tools.org/kb/item14.htm)である必要があります + + ```ini + [default] + access_key = AWS_ACCESS_KEY + secret_key = AWS_SECRET_KEY + bucket_location = us-east-1 + multipart_chunk_size_mb = 128 # default is 15 (MB) + ``` + + - Google Cloud Storageでは、`storage.admin`ロールを持つサービスアカウントを作成し、[サービスアカウントキーを作成する](https://cloud.google.com/iam/docs/keys-create-delete#creating_service_account_keys)ことでファイルを作成できます。以下は、`gcloud` CLIを使用してファイルを作成する例です。 + + ```shell + export PROJECT_ID=$(gcloud config get-value project) + gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage" + gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com + gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config + ``` + + - Azure Storageの場合 + + ```ini + [default] + # Setup endpoint: hostname of the Web App + host_base = https://your_minio_setup.azurewebsites.net + host_bucket = https://your_minio_setup.azurewebsites.net + # Leave as default + bucket_location = us-west-1 + use_https = True + multipart_chunk_size_mb = 128 # default is 15 (MB) + + # Setup access keys + # Access Key = Azure Storage Account name + access_key = AZURE_ACCOUNT_NAME + # Secret Key = Azure Storage Account Key + secret_key = AZURE_ACCOUNT_KEY + + # Use S3 v4 signature APIs + signature_v2 = False + ``` + +1. シークレットを作成します + + ```shell + kubectl create secret generic storage-config --from-file=config=storage.config + ``` + +## Google Cloud CDN {#google-cloud-cdn} + +{{< history >}} + +- GitLab 15.5で[導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/98010)されました。 + +{{< /history >}} + +[Google Cloud CDN](https://cloud.google.com/cdn)を使用して、[アーティファクト](https://cloud.google.com/cdn) [バケット](https://cloud.google.com/cdn)からデータを[キャッシュ](https://cloud.google.com/cdn)して[フェッチ](https://cloud.google.com/cdn)できます。これは、パフォーマンスを向上させ、ネットワーク構築 エグレスコストを削減するのに役立ちます。 + +Cloud CDNの設定は、次のキーを介して行われます。 + +- `global.appConfig.artifacts.cdn.secret` +- `global.appConfig.artifacts.cdn.key`（デフォルトは`cdn`） + +Cloud CDNを使用するには: + +1. [アーティファクト](https://cloud.google.com/cdn/docs/setting-up-cdn-with-bucket) [バケット](https://cloud.google.com/cdn/docs/setting-up-cdn-with-bucket)を[バックエンド](https://cloud.google.com/cdn/docs/setting-up-cdn-with-bucket)として使用するようにCloud [CDN](https://cloud.google.com/cdn/docs/setting-up-cdn-with-bucket)を設定 +1. [署名](https://cloud.google.com/cdn/docs/using-signed-urls)付きURLのキーを作成 +1. [バケット](https://cloud.google.com/cdn/docs/using-signed-urls#configuring_permissions)から読み取る[権限](https://cloud.google.com/cdn/docs/using-signed-urls#configuring_permissions)をCloud [CDN](https://cloud.google.com/cdn/docs/using-signed-urls#configuring_permissions) [サービスアカウント](https://cloud.google.com/cdn/docs/using-signed-urls#configuring_permissions)に付与 +1. [`rails.googlecdn.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/cdn/rails.googlecdn.yaml)の例を使用して、パラメータを含む[YAML](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/cdn/rails.googlecdn.yaml)ファイルを用意します。次の情報を入力する必要があります。 + - `url`:手順1からのCDNホストのベースURL + - `key_name`:手順2のキー名 + - `key`:手順2からの実際のシークレット +1. `cdn`キーの下に、このYAMLファイルをKubernetesのシークレットに読み込むします。たとえば、`gitlab-rails-cdn`というシークレットを作成するには: + + ```shell + kubectl create secret generic gitlab-rails-cdn --from-file=cdn=rails.googlecdn.yml + ``` + +1. `global.appConfig.artifacts.cdn.secret`を`gitlab-rails-cdn`に設定します。`helm`パラメータを介してこれを設定する場合は、次を使用します。 + + ```shell + --set global.appConfig.artifacts.cdn.secret=gitlab-rails-cdn + ``` + +## トラブルシューティング {#troubleshooting} + +### Azure Blob:URL \[FILTERED]がブロックされています:ローカルネットワークへのリクエストは許可されていません {#azure-blob-url-filtered-is-blocked-requests-to-the-local-network-are-not-allowed} + +これは、Azure Blobホスト名が[RFC1918（ローカル/プライベート）IPアドレス](https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints#dns-changes-for-private-endpoints)に[解決](https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints#dns-changes-for-private-endpoints)された場合に発生します。回避策として、Azure Blobホスト名（`yourinstance.blob.core.windows.net`）の[送信](https://docs.gitlab.com/security/webhooks/#allowlist-for-local-requests)リクエスト diff --git a/doc-locale/ja-jp/advanced/external-object-storage/aws-iam-roles.md b/doc-locale/ja-jp/advanced/external-object-storage/aws-iam-roles.md new file mode 100644 index 0000000000..4d552d48a1 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/aws-iam-roles.md @@ -0,0 +1,197 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートを使用する際のAWSのIAMロール +--- + +チャート内の外部オブジェクトストレージのデフォルト設定では、アクセスキーとシークレットキーを使用します。[`kube2iam`](https://github.com/jtblin/kube2iam)、[`kiam`](https://github.com/uswitch/kiam)、または[IRSA](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)と組み合わせてIAMロールを使用することも可能です。 + +## IAMロール {#iam-role} + +IAMロールは、S3バケットに対する読み取り、書き込み、およびリストの権限を必要とします。バケットごとにロールを設定するか、それらを結合するかを選択できます。 + +## チャートの設定 {#chart-configuration} + +IAMロールは、以下に示すように、アノテーションを追加し、シークレットを変更することで指定できます。 + +### レジストリ {#registry} + +IAMロールは、アノテーションキーを介して指定できます。 + +```plaintext +--set registry.annotations."iam\.amazonaws\.com/role"= +``` + +[`registry-storage.yaml`](../../charts/registry/_index.md#storage)シークレットを作成する際に、アクセスキーとシークレットキーを省略します。 + +```yaml +s3: + bucket: gitlab-registry + v4auth: true + region: us-east-1 +``` + +*ノート*:キーペアを指定すると、IAMロールは無視されます。詳細については、[AWSのドキュメント](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default)を参照してください。 + +### LFS、アーティファクト、アップロード、パッケージ {#lfs-artifacts-uploads-packages} + +LFS、アーティファクト、アップロード、パッケージの場合、`webservice`および`sidekiq`の設定のアノテーションキーを介してIAMロールを指定できます。 + +```shell +--set gitlab.sidekiq.annotations."iam\.amazonaws\.com/role"= +--set gitlab.webservice.annotations."iam\.amazonaws\.com/role"= +``` + +[`object-storage.yaml`](../../charts/globals.md#connection)シークレットの場合、アクセスキーとシークレットキーを省略します。GitLab RailsのコードベースはS3ストレージにFogを使用しているため、Fogがロールを使用するには、[`use_iam_profile`](https://docs.gitlab.com/administration/cicd/secure_files/#s3-compatible-connection-settings)キーを追加する必要があります。 + +```yaml +provider: AWS +use_iam_profile: true +region: us-east-1 +``` + +{{< alert type="note" >}} + +この設定に`endpoint`を含めないでください。IRSAは[STSトークンを使用します。これらは、専用のエンドポイントを使用します](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html)。`endpoint`が指定されている場合、AWSクライアントは[このエンドポイントに`AssumeRoleWithWebIdentity`メッセージを送信しようとし、失敗します](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3148#note_889357676)。 + +{{< /alert >}} + +### バックアップ {#backups} + +Toolboxの設定により、S3にバックアップをアップロードするためのアノテーションを設定できます。 + +```shell +--set gitlab.toolbox.annotations."iam\.amazonaws\.com/role"= +``` + +[`s3cmd.config`](_index.md#backups-storage-example)シークレットは、アクセスキーとシークレットキーなしで作成されます。 + +```ini +[default] +bucket_location = us-east-1 +``` + +### サービスアカウントaccount>でのIAMロールの使用 {#using-iam-roles-for-service-accounts} + +GitLabがAWS Amazon EKSクラスター (バージョン1.14以降) で実行されている場合、アクセストークンを生成または保存する必要なく、AWS IAMロールを使用してS3オブジェクトストレージに認証できます。Amazon EKSクラスターでIAMロールを使用する方法の詳細については、AWSの[サービスアカウント向けのきめ細かいIAMロールの概要](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/)に関するドキュメントを参照してください。 + +ロールに対する適切なIRSAアノテーションは、次の2つの方法のいずれかで、このHelm ChartChart>全体のサービスアカウントaccount>に適用できます。 + +1. 上記のAWSドキュメントで説明されているように、事前に作成されたサービスアカウントaccount>。これにより、サービスアカウントaccount>とリンクされたOIDCプロバイダーに対する適切なアノテーションが保証されます。 +1. アノテーションが定義された、チャートによって生成されたサービスアカウントaccount>。アノテーションの設定は、グローバルとチャートごとの両方でサービスアカウントaccount>で許可されています。 + +Amazon EKSクラスター内のGitLabのサービスアカウントaccount>にIAMロールを使用するには、特定のアノテーションを`eks.amazonaws.com/role-arn: arn:aws:iam:::role/`にする必要があります。 + +AWS Amazon EKSクラスターで実行されているGitLabのサービスアカウントaccount>にIAMロールを有効にするには、[サービスアカウントのIAMロール](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html)の手順に従ってください。 + +#### 事前に作成されたサービスアカウントaccount>の使用 {#using-pre-created-service-accounts} + +GitLabチャートをデプロイするときは、次のオプションを設定します。サービスアカウントaccount>が有効になっているが、作成されていないことに注意することが重要です。 + +```yaml +global: + serviceAccount: + enabled: true + create: false + name: +``` + +きめ細かいサービスアカウントaccount>制御も利用可能です。 + +```yaml +registry: + serviceAccount: + create: false + name: gitlab-registry +gitlab: + migrations: + serviceAccount: + create: false + name: gitlab-migrations + webservice: + serviceAccount: + create: false + name: gitlab-webservice + sidekiq: + serviceAccount: + create: false + name: gitlab-sidekiq + toolbox: + serviceAccount: + create: false + name: gitlab-toolbox +``` + +IAMロールの信頼ポリシーが、[これらのKubernetesサービスアカウントaccount>を信頼する](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)ように設定されていることを確認してください。 + +#### チャートが所有するサービスアカウントaccount>の使用 {#using-chart-owned-service-accounts} + +アノテーション`eks.amazonaws.com/role-arn`は、`global.serviceAccount.annotations`を設定することにより、GitLabが所有するチャートによって作成された_すべて_のサービスアカウントaccount>に適用できます。 + +```yaml +global: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/name +``` + +アノテーションはサービスアカウントaccount>ごとに追加することもできますが、各チャートに一致する定義を追加します。これらは同じロール、または個々のロールにすることができます。 + +```yaml +registry: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab-registry +gitlab: + migrations: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab + webservice: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab + sidekiq: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab + toolbox: + serviceAccount: + annotations: + eks.amazonaws.com/role-arn: arn:aws:iam::xxxxxxxxxxxx:role/gitlab-toolbox +``` + +## トラブルシューティング {#troubleshooting} + +IAMロールが正しくセットアップされ、GitLabがIAMロールを使用してS3にアクセスしているかどうかをテストするには、`toolbox`ポッドにログインし、`awscli`を使用します (インストールされているGitLabのネームスペースで``を置き換えます)。 + +```shell +kubectl exec -ti $(kubectl get pod -n -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n -- bash +``` + +`awscli`パッケージがインストールされている状態で、AWS APIと通信できることを検証します。 + +```shell +aws sts get-caller-identity +``` + +AWS APIへの接続が成功した場合、一時的なユーザーID、アカウント番号、およびIAM ARN (これはS3へのアクセスに使用されるロールのIAM ARNではありません) を示す正常な応答が返されます。接続が失敗した場合、`toolbox`ポッドがAWS APIと通信できない理由を特定するために、より多くのトラブルシューティングが必要になります。 + +AWS APIへの接続が成功した場合、次のコマンドは作成されたIAMロールを想定し、S3へのアクセス用にSTSトークンを取得できることを検証します。IAMロールのアノテーションがポッドに追加された場合、`AWS_ROLE_ARN`および`AWS_WEB_IDENTITY_TOKEN_FILE`の変数は環境で定義されており、定義する必要はありません。 + +```shell +aws sts assume-role-with-web-identity --role-arn $AWS_ROLE_ARN --role-session-name gitlab --web-identity-token file://$AWS_WEB_IDENTITY_TOKEN_FILE +``` + +IAMロールを想定できなかった場合は、次のようなエラーメッセージが表示されます。 + +```plaintext +An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation: Not authorized to perform sts:AssumeRoleWithWebIdentity +``` + +それ以外の場合は、STS認証情報とIAMロールの情報が表示されます。 + +## `WebIdentityErr: failed to retrieve credentials` {#webidentityerr-failed-to-retrieve-credentials} + +ログにこのエラーが表示された場合は、`endpoint`が[`object-storage.yaml`](../../charts/globals.md#connection)シークレットに設定されていることを示唆しています。この設定を削除し、`webservice`および`sidekiq`ポッドを再起動します。 diff --git a/doc-locale/ja-jp/advanced/external-object-storage/azure-minio-gateway.md b/doc-locale/ja-jp/advanced/external-object-storage/azure-minio-gateway.md new file mode 100644 index 0000000000..b741ad4266 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/azure-minio-gateway.md @@ -0,0 +1,96 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートを使用する際のAzure MinIOゲートウェイ +--- + +[MinIO](https://min.io/)は、S3互換のAPIを公開するオブジェクトストレージサーバーであり、Azure Blob Storageへのリクエストをプロキシできるゲートウェイ機能を備えています。ゲートウェイを設定するには、Linux上のAzure Webアプリを使用します。 + +開始するには、Azureコマンドラインインターフェース（CLI） がインストールされ、ログインしていることを確認してください(`az login`)。[リソースグループ](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/overview#resource-groups)を作成してください(まだない場合)。 + +```shell +az group create --name "gitlab-azure-minio" --location "WestUS" +``` + +## ストレージアカウント {#storage-account} + +リソースグループにストレージアカウントを作成します。ストレージアカウントの名前はグローバルに一意である必要があります。 + +```shell +az storage account create \ + --name "gitlab-azure-minio-storage" \ + --kind BlobStorage \ + --sku Standard_LRS \ + --access-tier Cool \ + --resource-group "gitlab-azure-minio" \ + --location "WestUS" +``` + +ストレージアカウントのアカウントキーを取得します。 + +```shell +az storage account show-connection-string \ + --name "gitlab-azure-minio-storage" \ + --resource-group "gitlab-azure-minio" +``` + +出力は次の形式である必要があります。 + +```json +{ + "connectionString": "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=gitlab-azure-minio-storage;AccountKey=h0tSyeTebs+..." +} +``` + +## Linux上のWebアプリへのMinIOのデプロイ {#deploy-minio-to-web-app-on-linux} + +まず、同じリソースグループにApp Serviceプランを作成する必要があります。 + +```shell +az appservice plan create \ + --name "gitlab-azure-minio-app-plan" \ + --is-linux \ + --sku B1 \ + --resource-group "gitlab-azure-minio" \ + --location "WestUS" +``` + +[`minio/minio`](https://hub.docker.com/r/minio/minio) Dockerコンテナで構成されたWebアプリを作成します。指定する名前はWebアプリのURLで使用されます。 + +```shell +az webapp create \ + --name "gitlab-minio-app" \ + --deployment-container-image-name "minio/minio" \ + --plan "gitlab-azure-minio-app-plan" \ + --resource-group "gitlab-azure-minio" +``` + +これで、Webアプリに`https://gitlab-minio-app.azurewebsites.net`でアクセスできるようになります。 + +最後に、スタートアップコマンドを設定し、Webアプリで使用するためにストレージアカウント名とキーを格納する環境変数`MINIO_ACCESS_KEY`と`MINIO_SECRET_KEY`を作成する必要があります。 + +```shell +az webapp config appsettings set \ + --settings "MINIO_ACCESS_KEY=gitlab-azure-minio-storage" "MINIO_SECRET_KEY=h0tSyeTebs+..." "PORT=9000" \ + --name "gitlab-minio-app" \ + --resource-group "gitlab-azure-minio" + +# Startup command +az webapp config set \ + --startup-file "gateway azure" \ + --name "gitlab-minio-app" \ + --resource-group "gitlab-azure-minio" +``` + +## 結論 {#conclusion} + +s3互換性のある任意のクライアントでこのゲートウェイを引き続き使用できます。WebアプリケーションURLは`s3 endpoint`、ストレージアカウント名は`accesskey`、ストレージアカウントキーは`secretkey`になります。 + +## 参照 {#reference} + + + +このガイドは、[同じトピックに関するAlessandro Segalaのブログ投稿](https://withblue.ink/2017/10/29/how-to-use-s3cmd-and-any-other-amazon-s3-compatible-app-with-azure-blob-storage.html)から後世のために翻案されました。 + + diff --git a/doc-locale/ja-jp/advanced/external-object-storage/azure-workload-identity.md b/doc-locale/ja-jp/advanced/external-object-storage/azure-workload-identity.md new file mode 100644 index 0000000000..63a19aceff --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/azure-workload-identity.md @@ -0,0 +1,130 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートを使用する際のAzureワークロードアイデンティティ +--- + +チャート内の外部オブジェクトストレージのデフォルト設定は、シークレットキーを使用します。[Azureワークロードアイデンティティ](https://azure.github.io/azure-workload-identity/docs/)を使用すると、有効期間の短いトークンを使用して、Kubernetesクラスターへのオブジェクトストレージへのアクセスを許可できます。[Azure Kubernetes Service (AKS) クラスターにワークロードアイデンティティをデプロイおよび設定する方法に関するMicrosoftのドキュメント](https://learn.microsoft.com/en-us/azure/aks/workload-identity-deploy-cluster)をお読みください。 + +## 要件 {#requirements} + +オブジェクトストレージでワークロードアイデンティティを使用するには、以下が必要です。 + +1. OpenID Connect (OIDC) Issuerが有効になっているAKSクラスター。 +1. `Storage Blob Data Contributor`ロールが割り当てられたAzureマネージドID。 +1. アノテーション`azure.workload.identity/client-id: `を使用して、マネージドIDに関連付けられたKubernetesサービスアカウント。 + +ワークロードアイデンティティをアクティブ化するには、各ポッドに`azure.workload.identity/use: "true"`ラベルが必要です。これはポッド**ラベル**であり、アノテーションではありません。 + +## チャートの設定 {#chart-configuration} + +### レジストリ {#registry} + +{{< history >}} + +- GitLab 17.9で[ベータ](https://gitlab.com/gitlab-org/container-registry/-/issues/1431)機能として[導入](https://gitlab.com/gitlab-org/container-registry/-/issues/1431)。 + +{{< /history >}} + +レジストリに対するワークロードアイデンティティのサポートはベータ版です。ワークロードアイデンティティは、ポッドラベルを設定することで有効にできます。 + +```plaintext +--set registry.podLabels."azure\.workload\.identity/use"=true +``` + +[`registry-storage.yaml`](../../charts/registry/_index.md#storage)シークレットを作成する際は、以下を行う必要があります。 + +1. `azure_v2`ストレージ設定を使用します。 +1. `credentialstype`を`default_credentials`に設定します。 + +次に例を示します。 + +```yaml +azure_v2: + accountname: accountname + container: containername + credentialstype: default_credentials + realm: core.windows.net +``` + +`azure_v2`ストレージドライバーはワークロードアイデンティティをサポートしますが、`azure`ドライバーはサポートしません。現在`azure`ドライバーを使用しており、ワークロードアイデンティティを使用する場合は、`azure_v2`ドライバーに移行してください。詳細については、[`azure_v2`ドキュメント](https://gitlab.com/gitlab-org/container-registry/-/blob/3ebb5bffd3f6cfbf4479b1b8a4079d842a1c8025/docs/storage-drivers/azure_v2.md)を参照してください。 + +### LFS、アーティファクト、アップロード、パッケージ {#lfs-artifacts-uploads-packages} + +LFS、アーティファクト、アップロード、およびパッケージの場合、IAMロールは、`webservice`、`sidekiq`、および`toolbox`設定のアノテーションキーを介して指定できます。 + +```shell +--set gitlab.sidekiq.podLabels."azure\.workload\.identity/use"="true" +--set gitlab.webservice.podLabels."azure\.workload\.identity/use"="true" +--set gitlab.toolbox.podLabels."azure\.workload\.identity/use"="true" +``` + +[`object-storage.yaml`](../../charts/globals.md#connection)シークレットの場合は、`azure_storage_access_key`を省略します。 + +```yaml +provider: AzureRM +azure_storage_account_name: YOUR_AZURE_STORAGE_ACCOUNT_NAME +azure_storage_domain: blob.core.windows.net +``` + +### バックアップ {#backups} + +Toolboxの設定では、ポッドラベルを設定できます。 + +```shell +--set gitlab.toolbox.podLabels."azure\.workload\.identity/use"="true" +``` + +`gitlab.toolbox.backups.objectStorage.config.secret`シークレットに保存されている[`azure-backup-conf.yaml`](../../backup-restore/_index.md)の場合は、`azure_storage_access_key`を省略します。 + +```yaml +# azure-backup-conf.yaml +azure_storage_account_name: +azure_storage_domain: blob.core.windows.net # optional +``` + +## トラブルシューティング {#troubleshooting} + +Azureワークロードアイデンティティが正しく設定され、GitLabがAzure Blobストレージにアクセスしているかどうかを`toolbox`ポッドにログインしてテストできます (GitLabが存在するネームスペースで``を置き換えます)。 + +```shell +kubectl exec -ti $(kubectl get pod -n -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n -- bash +``` + +まず、必要な環境変数が存在するかどうかを確認します。 + +- `AZURE_TENANT_ID` +- `AZURE_FEDERATED_TOKEN_FILE` +- `AZURE_CLIENT_ID` + +たとえば、次のように表示されます。 + +```shell +$ env | grep AZURE +AZURE_TENANT_ID=abcdefghi-c2c5-43d6-b426-1d8c9e8e7ad1 +AZURE_FEDERATED_TOKEN_FILE=/var/run/secrets/azure/tokens/azure-identity-token +AZURE_AUTHORITY_HOST=https://login.microsoftonline.com/ +AZURE_CLIENT_ID=123456789-abcd-12ab-89ca-cb379118f978 +``` + +次に、`azcopy`を使用してblobコンテナ内のファイルを一覧表示します。 + +```shell +export AZCOPY_AUTO_LOGIN_TYPE=workload +azcopy --log-level debug list https://.blob.core.windows.net/ +``` + +認証が成功すると、次のメッセージがblobコンテナの内容とともに表示されます。 + +```plaintext +INFO: Login with Workload Identity succeeded +INFO: Authenticating to source using Azure AD +``` + +401または403エラーが表示された場合は、マネージドIDの設定を確認してください。一般的なエラーを次に示します。 + +1. Azureストレージアカウントとblobコンテナ名のスペルを確認します。 +1. `kubectl describe pod `を使用して、ポッドに正しいKubernetesサービスアカウントと`azure.workload.identity/use: "true"`ポッドラベルがあることを確認します。 +1. マネージドIDの場合は、フェデレーション認証情報の設定に、正しい発行者URL、ネームスペース、および関連付けられたKubernetesサービスアカウントがあることを確認してください。これは、Azure portalで確認するか、[`az`コマンドラインインターフェイス](https://learn.microsoft.com/en-us/cli/azure/identity)を使用して確認できます。 +1. マネージドIDにblobストレージコンテナの`Storage Blob Data Contributor`があることを確認します。 diff --git a/doc-locale/ja-jp/advanced/external-object-storage/gke-workload-identity.md b/doc-locale/ja-jp/advanced/external-object-storage/gke-workload-identity.md new file mode 100644 index 0000000000..a536fa3fae --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/gke-workload-identity.md @@ -0,0 +1,42 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートを使用したGKEのワークロードアイデンティティフェデレーション +--- + +{{< history >}} + +- [導入](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3434)：GitLab 17.0。 + +{{< /history >}} + +チャート内の外部オブジェクトストレージのデフォルト設定では、シークレットキーが使用されます。[GKEのワークロードアイデンティティフェデレーション](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity)を使用すると、短寿命トークンを使用してKubernetesクラスターにオブジェクトストレージへのアクセスを許可できます。既存のGKEクラスターがある場合は、[ノードプールを更新してワークロードアイデンティティフェデレーションを使用する方法に関するGoogleドキュメント](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#option_2_node_pool_modification)をお読みください。 + +ワークロードアイデンティティを使用するには、`google_json_key_string`の[`object-storage.yaml`](../../charts/globals.md#connection)シークレットの`google_json_key_string`を省略します。 + +```yaml +provider: Google +google_project: your-project-id +google_client_email: null # Will use workload identity +google_json_key_string: null # Will use workload identity +``` + +## トラブルシューティング {#troubleshooting} + +[Kubernetesサービスアカウントが](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity#kubernetes-sa-to-iam)、`iam.gke.io/gcp-service-account`アノテーションを介してIAMサービスアカウントにリンクされていることを確認してください。 + +toolboxポッド内でメタデータエンドポイントにクエリを実行して、ワークロードアイデンティティが適切に設定されているかどうかを確認できます。クラスターに関連付けられたサービスアカウントが返されるはずです。 + +```shell +$ curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email +example@your-example-project.iam.gserviceaccount.com +``` + +このアカウントは、次のスコープにもアクセスできる必要があります。 + +```shell +$ curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scopes +https://www.googleapis.com/auth/cloud-platform +https://www.googleapis.com/auth/userinfo.email +``` diff --git a/doc-locale/ja-jp/advanced/external-object-storage/minio.md b/doc-locale/ja-jp/advanced/external-object-storage/minio.md new file mode 100644 index 0000000000..dcc096bfc0 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-object-storage/minio.md @@ -0,0 +1,25 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートでMinIOを設定 +--- + +[MinIO](https://min.io/)は、S3互換APIを公開するオブジェクトストレージサーバーです。 + +MinIOは、いくつかの異なるプラットフォームにデプロイできます。新しいMinIO[インスタンス](https://min.io/docs/minio/linux/index.html)を起動するには、[クイックスタートガイド](https://min.io/docs/minio/linux/index.html)に従ってください。[TLSでMinIOサーバーへのアクセスをSecure](https://min.io/docs/minio/linux/operations/network-encryption.html)にしてください。 + +GitLabを外部[MinIO](https://min.io/)インスタンスに[接続中](https://min.io/)するには、まずこの[設定ファイル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/values-external-objectstorage.yaml)の[バケット](https://min.io/)名を使用して、GitLabアプリケーション用のMinIO[バケット](https://min.io/)をCreateしてください。 + +[MinIOクライアント](https://min.io/docs/minio/kubernetes/upstream/)を使用して、使用前に必要な[バケット](https://min.io/docs/minio/kubernetes/upstream/)をCreateしてください。 + +```shell +mc mb gitlab-registry-storage +mc mb gitlab-lfs-storage +mc mb gitlab-artifacts-storage +mc mb gitlab-uploads-storage +mc mb gitlab-packages-storage +mc mb gitlab-backup-storage +``` + +バケットが作成されると、GitLabがMinIOインスタンスを使用するようにConfigureできます。[examples](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage)フォルダーの[`rails.minio.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.minio.yaml)と[`registry.minio.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.minio.yaml)の[設定](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/rails.minio.yaml)例を参照してください。 diff --git a/doc-locale/ja-jp/advanced/external-redis/_index.md b/doc-locale/ja-jp/advanced/external-redis/_index.md new file mode 100644 index 0000000000..19f6dbc436 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-redis/_index.md @@ -0,0 +1,121 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 外部RedisでGitLabチャートを設定する +--- + +このドキュメントでは、外部RedisサービスでこのHelm Chartを設定する方法について説明します。 + +Redisを設定していない場合は、[Linuxを使用して、オンプレミスまたはへのを検討してください。](external-omnibus-redis.md) + +現在サポートされているRedisの[インストール要件](https://docs.gitlab.com/install/requirements/#redis)の詳細については、こちらを参照してください。 + +## チャートを {#configure-the-chart}構成する + +`redis`と、それが提供するRedisサービスを無効にして、他のサービスを外部サービスにポイントします。 + +次のパラメータを設定する必要があります。 + +- `redis.install`:`false`に設定して、Redisを含めないようにします。 +- `global.redis.host`:外部Redisのホスト名に設定します。ドメインまたはアドレスを指定できます。 +- `global.redis.auth.enabled`:外部Redisがパスワードを必要としない場合は、`false`に設定します。 +- `global.redis.auth.secret`:[用のを含むの名前。](../../installation/secrets.md#redis-password) +- `global.redis.auth.key`:内の。これには、コンテンツが含まれています。 + +以下に示す項目は、を使用していない場合は、さらにカスタマイズできます。 + +- `global.redis.port`:データベースが利用可能なポートは、デフォルトで`6379`です。 +- `global.redis.database`:Redisサーバーで接続するデータベースは、デフォルトで`0`です。 + +たとえば、これらの値をデプロイ時にHelmの`--set`フラグを介して渡します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set redis.install=false \ + --set global.redis.host=redis.example \ + --set global.redis.auth.secret=gitlab-redis \ + --set global.redis.auth.key=redis-password \ +``` + +Sentinelサーバーが実行されているRedis HAクラスターに接続している場合、`global.redis.host`属性は、`sentinel.conf`で指定されているように、Redisインスタンスグループの名前（`mymaster`や`resque`など）に設定する必要があります。Redis masterのホスト名には設定しないでください。Sentinelサーバーは、`--set`フラグの`global.redis.sentinels[0].host`および`global.redis.sentinels[0].port`を使用して参照できます。インデックスはゼロから始まります。 + +## 複数のRedisインスタンスを {#use-multiple-redis-instances}使用する + +は、複数のRedisにわたって、リソースを大量に消費するいくつかのRedisの分割をしています。このは、これらの永続クラスを他のRedisにすることをしています。 + +複数のRedisインスタンスを使用するための[チャート](../../charts/globals.md#multiple-redis-support)の設定に関する詳細については、[グローバル](../../charts/globals.md#multiple-redis-support)ドキュメントを参照してください。 + +## セキュアなRedisスキーム（SSL）を {#specify-secure-redis-scheme-ssl}指定する + +SSLを使用してRedisに接続するには、`rediss`（二重の`s`に注意）スキームパラメータを使用します。 + +```shell +--set global.redis.scheme=rediss +``` + +## `redis.yml`をオーバーライド {#redisyml-override} + +GitLab 15.8で導入された[`redis.yml`設定ファイル](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106854)のコンテンツをオーバーライドする場合は、`global.redis.redisYmlOverride`の下で値を定義することで実行できます。そのキーの下にあるすべての値とサブ値は、`redis.yml`にそのままレンダリングされます。 + +`global.redis.redisYmlOverride`は、外部Redisサービスで使用することを目的としています。`redis.install`を`false`に設定する必要があります。詳細については、[Redisをを参照してください。](../../charts/globals.md#configure-redis-settings) + +例: + +```yaml +redis: + install: false +global: + redis: + redisYmlOverride: + raredis: + host: rare-redis.example.com:6379 + password: + enabled: true + secret: secretname + key: password + exotic_redis: + host: redis.example.com:6379 + password: <%= File.read('/path/to/secret').strip.to_json %> + mystery_setting: + deeply: + nested: value +``` + +`/path/to/secret`に`THE SECRET`が含まれており、`/path/to/secret/raredis-override-password`に`RARE SECRET`が含まれていると仮定すると、次が`redis.yml`にレンダリングされます。 + +```yaml +production: + raredis: + host: rare-redis.example.com:6379 + password: "RARE SECRET" + exotic_redis: + host: redis.example.com:6379 + password: "THE SECRET" + mystery_setting: + deeply: + nested: value +``` + +### 注意すべき点 {#things-to-look-out-for} + +`redisYmlOverride`の柔軟性の裏側は、ユーザーフレンドリーでないことです。例: + +1. `redis.yml`にパスワードを挿入するには、次のいずれかを実行します。 + - 既存の[パスワード定義](../../charts/globals.md#multiple-redis-support)を使用し、HelmにそれをERBステートメントに置き換えさせます。 + - コンテナでシークレットがマウントされているパスを使用して、正しいERB `<%= File.read('/path/to/secret').strip.to_json %>`ステートメントを自分で記述します。 +1. `redisYmlOverride`では、 Railsのに従う必要があります。たとえば、「SharedState」インスタンスは`sharedState`と呼ばれず、`shared_state`と呼ばれます。 +1. の継承はありません。たとえば、単一のSentinelセットを共有する3つのRedisがある場合は、Sentinelを3回繰り返す必要があります。 +1. CNGイメージは、[有効な`resque.yml`と`cable.yml`を想定している](https://gitlab.com/gitlab-org/build/CNG/-/blob/4d314e505edb25ccefd4297d212bfbbb5bc562f9/gitlab-rails/scripts/lib/checks/redis.rb#L54)ため、`resque.yml`ファイルを取得するには、少なくとも`global.redis.host`を設定する必要があります。 + +## トラブルシューティング {#troubleshooting} + + + +### `ERR Error running script (call to f_5962bd591b624c0e0afce6631ff54e7e4402ebd8): @user_script:7: ERR syntax error` {#err-error-running-script-call-to-f_5962bd591b624c0e0afce6631ff54e7e4402ebd8-user_script7-err-syntax-error} + +Helm Chart 7.2以降で外部Redis 5を使用している場合、`webservice`および`sidekiq`ポッドのログにこのエラーが表示されることがあります。Redis 5 [はされていません。](https://docs.gitlab.com/install/requirements/#redis) + +問題をするには、外部Redisを6.xにしてください。 + + diff --git a/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md b/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md new file mode 100644 index 0000000000..1a976c1395 --- /dev/null +++ b/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md @@ -0,0 +1,56 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: スタンドアロンRedisの設定 +--- + +ここで説明する手順では、Ubuntuの[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)を使用します。このパッケージは、チャートのサービスと互換性があることが保証されているサービスのバージョンを提供します。 + +## LinuxパッケージでVMを作成する {#create-vm-with-the-linux-package} + +お好みのプロバイダーまたはローカルで仮想マシン（VM）を作成します。これは、VirtualBox、KVM、およびBhyveでテストされました。インスタンスがクラスターから到達可能であることを確認してください。 + +作成した仮想マシン（VM）にUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのパッケージが最新であることを確認してください。ネットワーク構築とホスト名を設定します。ホスト名/アドレスをメモし、それがKubernetesクラスターから解決可能で、到達可能であることを確認します。トラフィックを許可するようにファイアウォールポリシーが設定されていることを確認してください。 + +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、**___** `EXTERNAL_URL=`値を指定しないでください。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 + +## Linuxパッケージインストールの設定 {#configure-linux-package-installation} + +`/etc/gitlab/gitlab.rb`に配置される最小限の`gitlab.rb`ファイルを作成します。このノードで有効になっているものを___明示的に指定し、以下の内容を使用します。 + +{{< alert type="note" >}} + +この例は、[スケーリング用のRedis](https://docs.gitlab.com/administration/redis/)を提供することを目的としていません。 + +{{< /alert >}} + +- `REDIS_PASSWORD`は、[`gitlab-redis`シークレット](../../installation/secrets.md#redis-password)の値に置き換える必要があります。 + +```Ruby +# Listen on all addresses +redis['bind'] = '0.0.0.0' +# Set the defaul port, must be set. +redis['port'] = 6379 +# Set password, as in the secret `gitlab-redis` populated in Kubernetes +redis['password'] = 'REDIS_PASSWORD' + +## Disable everything else +gitlab_rails['enable'] = false +sidekiq['enable'] = false +puma['enable']=false +registry['enable'] = false +gitaly['enable'] = false +gitlab_workhorse['enable'] = false +nginx['enable'] = false +prometheus_monitoring['enable'] = false +postgresql['enable'] = false +``` + +`gitlab.rb`を作成したら、`gitlab-ctl reconfigure`でパッケージを再設定します。タスクが完了したら、`gitlab-ctl status`で実行中のプロセスを確認します。出力は次のように表示されます。 + +```plaintext +# gitlab-ctl status +run: logrotate: (pid 4856) 1859s; run: log: (pid 31262) 77460s +run: redis: (pid 30562) 77637s; run: log: (pid 30561) 77637s +``` diff --git a/doc-locale/ja-jp/advanced/fips/_index.md b/doc-locale/ja-jp/advanced/fips/_index.md new file mode 100644 index 0000000000..90ebbd3e85 --- /dev/null +++ b/doc-locale/ja-jp/advanced/fips/_index.md @@ -0,0 +1,16 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: FIPS準拠のイメージでGitLabチャートを設定する +--- + +GitLabは、[FIPS準拠](https://docs.gitlab.com/development/fips_compliance/)のイメージを提供しており、FIPS対応クラスター上でGitLabを実行できます。 + +これらのイメージは、[Red Hat Universal Base Images](https://access.redhat.com/articles/4238681)に基づいています。完全に準拠したFIPSモードで機能させるには、すべてのホストがFIPSモード用にされている必要があります。 + +## サンプル値 {#sample-values} + +FIPS互換のGitLabのに役立つ[`examples/fips/values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/fips/values.yaml)のGitLabチャート値の例を示します。 + +FIPS互換のNGINXイメージを使用するための関連を提供する`nginx-ingress.controller`キーの下のコメントに注意してください。このイメージは、[NGINX ](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-ingress-nginx)でされます。 diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md new file mode 100644 index 0000000000..cae411b226 --- /dev/null +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -0,0 +1,682 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab GeoでGitLabチャートを設定する +--- + +GitLab Geoは、地理的に分散したアプリケーションのデプロイを可能にします。 + +外部データベースサービスも使用できますが、これらの[ドキュメント](https://docs.gitlab.com/omnibus/)では、PostgreSQL用の[Linux package](https://docs.gitlab.com/omnibus/)を使用して、最も[プラットフォーム](https://docs.gitlab.com/omnibus/)に[依存しない](https://docs.gitlab.com/omnibus/)ガイドを提供し、`gitlab-ctl`に含まれる自動化を利用することに重点を置いています。 + +このガイドでは、両方のクラスターが同じ外部URLを持ちます。この機能は、チャートのバージョン7.3以降でサポートされています。[Geoサイトの統合URLの設定](https://docs.gitlab.com/administration/geo/secondary_proxy/#set-up-a-unified-url-for-geo-sites)を参照してください。オプションで、[セカンダリサイトに個別のURLを設定](#configure-a-separate-url-for-the-secondary-site-optional)できます。 + +既知の[イシュー](https://docs.gitlab.com/administration/geo/#known-issues)については、[Geoドキュメント](https://docs.gitlab.com/administration/geo/#known-issues)を参照してください。 + +{{< alert type="note" >}} + +Geoのすべての側面（主に`site`と`node`の区別）を説明する[定義された用語](https://docs.gitlab.com/administration/geo/glossary/)を参照してください。 + +{{< /alert >}} + +## 要件 {#requirements} + +GitLab GeoをGitLab Helm Chartで使用するには、次の要件を満たす必要があります。 + +- [外部PostgreSQL](../external-db/_index.md)サービスの使用。チャートに含まれるPostgresSQLは外部ネットワークに公開されておらず、[レプリケーション](../external-db/_index.md)に必要なWAL[サポート](../external-db/_index.md)がないため。 +- 提供されるデータベースは以下をサポートする必要があります。 + - レプリケーションをサポートします。 + - プライマリデータベースは、プライマリサイトおよびすべてのセカンダリデータベースノード（レプリケーション用）から到達可能である必要があります。 + - セカンダリデータベースは、セカンダリサイトからのみ到達可能である必要があります。 + - プライマリデータベースノードとセカンダリデータベースノード間のSSLをサポートします。 +- プライマリサイトは、すべてのセカンダリサイトからHTTP(S)経由で到達可能である必要があります。セカンダリサイトは、プライマリサイトからHTTP(S)経由でアクセス可能である必要があります。 +- 完全な[要件](https://docs.gitlab.com/administration/geo/#requirements-for-running-geo)リストについては、[Geoの実行要件](https://docs.gitlab.com/administration/geo/#requirements-for-running-geo)を参照してください。 + +## 概要 {#overview} + +このガイドでは、Linuxパッケージを使用して作成された2つのデータベースノードを使用し、必要なPostgreSQLサービスのみを設定し、GitLab Helm Chartの2つのデプロイを使用します。これは、_最小_限必要な_設定_であるように意図されています。このドキュメントには、アプリケーションからデータベースへのSSL、他のデータベースプロバイダーのサポート、または[セカンダリサイトをプライマリにプロモートすること](https://docs.gitlab.com/administration/geo/disaster_recovery/)は含まれていません。 + +以下の概要は、次の順序で実行する必要があります。 + +1. [Linuxパッケージデータベースノードを設定](#set-up-linux-package-database-nodes) +1. [Kubernetesクラスターを設定](#set-up-kubernetes-clusters) +1. [情報を収集](#collect-information) +1. [プライマリデータベースを設定](#configure-primary-database) +1. [Geoプライマリサイトとしてチャートをデプロイ](#deploy-chart-as-geo-primary-site) +1. [Geoプライマリサイトを設定](#set-the-geo-primary-site) +1. [セカンダリデータベースを設定](#configure-secondary-database) +1. [プライマリサイトからセカンダリサイトにシークレットをコピー](#copy-secrets-from-the-primary-site-to-the-secondary-site) +1. [Geoセカンダリサイトとしてチャートをデプロイ](#deploy-chart-as-geo-secondary-site) +1. [プライマリ経由でGeoセカンダリサイトを追加](#add-secondary-geo-site-via-primary) +1. [運用状態を確認](#confirm-operational-status) +1. [セカンダリサイトに個別のURLを設定（オプション）](#configure-a-separate-url-for-the-secondary-site-optional) +1. [レジストリ](#registry) +1. [Cert-managerと統合URL](#cert-manager-and-unified-url) + +## Linuxパッケージデータベースノードを設定する {#set-up-linux-package-database-nodes} + +このプロセスでは、2つのノードが必要です。1つはプライマリデータベースノード、もう1つはセカンダリデータベースノードです。オンプレミスまたはクラウドプロバイダーから、マシンインフラストラクチャの任意のプロバイダーを使用できます。 + +通信が必要であることに注意してください。 + +- レプリケーションのための2つのデータベースノード間。 +- 各データベースノードとそれぞれのKubernetesデプロイメント間： + - プライマリは、TCPポート`5432`を公開する必要があります。 + - セカンダリは、TCPポート`5432`および`5431`を公開する必要があります。 + +[Linuxパッケージでサポートされているオペレーティングシステム](https://docs.gitlab.com/install/requirements/#operating-systems)をインストールし、次に[Linux [パッケージ](https://docs.gitlab.com/install/requirements/#operating-systems)をインストール](https://about.gitlab.com/install/)します。インストール時に`EXTERNAL_URL`環境変数を指定しないでください。これは、パッケージを再設定する前に最小限の設定ファイルを提供するからです。 + +オペレーティングシステムとGitLabパッケージをインストールしたら、使用するサービスに対して設定を作成できます。その前に、情報を収集する必要があります。 + +## Kubernetesクラスターを設定する {#set-up-kubernetes-clusters} + +このプロセスでは、2つのKubernetesクラスターを使用する必要があります。これらは、オンプレミスまたはクラウドプロバイダーから、任意のプロバイダーからのものでもかまいません。 + +通信が必要であることに注意してください。 + +- それぞれのデータベースノードへ： + - プライマリはTCP `5432`へ送信します。 + - セカンダリはTCP `5432`と`5431`へ送信します。 +- HTTPS経由の両方のKubernetes Ingress間。 + +プロビジョニングされる各クラスターには、次のものが必要です。 + +- これらのチャートのベースラインインストールをサポートするのに十分なリソース。 +- 永続ストレージへのアクセス： + - [外部オブジェクトストレージ](../external-object-storage/_index.md)を使用している場合、MinIOは不要です。 + - [外部Gitaly](../external-gitaly/_index.md)を使用している場合、Gitalyは不要です。 + - [外部Redis](../external-redis/_index.md)を使用している場合、Redisは不要です。 + +## 情報を収集する {#collect-information} + +設定を続行するには、さまざまなソースから次の情報を収集する必要があります。これらを収集し、このドキュメントの残りの部分で使用するためのノートを作成します。 + +- プライマリデータベース： + - IPアドレス + - ホスト名（オプション） +- セカンダリデータベース： + - IPアドレス + - ホスト名（オプション） +- プライマリ クラスター： + - 外部URL + - 内部URL + - ノードのIPアドレス +- セカンダリ クラスター： + - 内部URL + - ノードのIPアドレス +- データベースパスワード（_パスワードを事前に決定する必要があります_）： + - `gitlab` （`postgresql['sql_user_password']`、`global.psql.password`で使用） + - `gitlab_geo` （`geo_postgresql['sql_user_password']`、`global.geo.psql.password`で使用） + - `gitlab_replicator` （レプリケーションに必要） +- GitLabライセンスファイル + +各クラスターの内部URLは、クラスターに固有である必要があります。これにより、すべてのクラスターが他のすべてのクラスターにリクエストを送信できるようになります。次に例を示します。 + +- すべてのクラスターの外部URL：`https://gitlab.example.com` +- プライマリ クラスターの内部URL：`https://london.gitlab.example.com` +- セカンダリ クラスターの内部URL：`https://shanghai.gitlab.example.com` + +このガイドでは、DNSの設定については説明しません。 + +`gitlab`および`gitlab_geo`データベースユーザーパスワードは、ベアパスワードとPostgreSQLハッシュパスワードの2つの形式で存在する必要があります。ハッシュ形式を取得するには、Linuxパッケージインストールインスタンスの1つで次のコマンドを実行します。これにより、パスワードを入力して確認するように求められた後、適切なハッシュ値が出力され、ノートを作成できます。 + +1. `gitlab-ctl pg-password-md5 gitlab` +1. `gitlab-ctl pg-password-md5 gitlab_geo` + +## プライマリデータベースを設定 {#configure-primary-database} + +_このセクションは、プライマリLinuxパッケージインストールデータベースノードで実行されます。_ + +プライマリデータベースノードのLinuxパッケージインストールを設定するには、この設定例から作業します。 + +```ruby +### Geo Primary +external_url 'http://gitlab.example.com' +roles ['geo_primary_role'] +# The unique identifier for the Geo node. +gitlab_rails['geo_node_name'] = 'London Office' +gitlab_rails['auto_migrate'] = false +## turn off everything but the DB +sidekiq['enable']=false +puma['enable']=false +gitlab_workhorse['enable']=false +nginx['enable']=false +geo_logcursor['enable']=false +gitaly['enable']=false +redis['enable']=false +gitlab_kas['enable']=false +prometheus_monitoring['enable'] = false +## Configure the DB for network +postgresql['enable'] = true +postgresql['listen_address'] = '0.0.0.0' +postgresql['sql_user_password'] = 'gitlab_user_password_hash' +# !! CAUTION !! +# This list of CIDR addresses should be customized +# - primary application deployment +# - secondary database node(s) +postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0'] +``` + +いくつかのアイテムを置き換える必要があります。 + +- `external_url`は、プライマリサイトのホスト名を反映するように更新する必要があります。 +- `gitlab_rails['geo_node_name']`は、サイトの一意の名前に置き換える必要があります。[共通設定](https://docs.gitlab.com/administration/geo_sites/#common-settings)の名前フィールドを参照してください。 +- `gitlab_user_password_hash`は、`gitlab`パスワードのハッシュ形式に置き換える必要があります。 +- `postgresql['md5_auth_cidr_addresses']`は、明示的なIPアドレスのリスト、またはCIDR表記のアドレスブロックになるように更新できます。 + +`md5_auth_cidr_addresses`は`[ '127.0.0.1/24', '10.41.0.0/16']`の形式である必要があります。Linuxパッケージの自動化がこれを使用して接続するため、このリストに`127.0.0.1`を含めることが重要です。このリストのアドレスには、セカンダリデータベースのIPアドレス（ホスト名ではない）と、プライマリKubernetesクラスターのすべてのノードを含める必要があります。これは`['0.0.0.0/0']`のままにすることも_できます_が、_ベストプラクティスではありません_。 + +上記の設定が準備されたら： + +1. コンテンツを`/etc/gitlab/gitlab.rb`に配置します +1. `gitlab-ctl reconfigure`を実行します。TCPでサービスがリッスンしていないことに関してイシューが発生した場合は、`gitlab-ctl restart postgresql`を使用して直接再起動してみてください。 +1. `gitlab-ctl set-replication-password`を実行して、`gitlab_replicator`ユーザーのパスワードを設定します。 +1. プライマリデータベースノードの公開証明書を取得します。これは、セカンダリデータベースがレプリケートできるようにするために必要です（この出力を保存します）。 + + ```shell + cat ~gitlab-psql/data/server.crt + ``` + +## Geoプライマリサイトとしてチャートをデプロイする {#deploy-chart-as-geo-primary-site} + +_このセクションは、プライマリサイトのKubernetesクラスターで実行されます。_ + +この[チャート](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/primary.yaml)をGeo[プライマリ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/primary.yaml)として[デプロイ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/primary.yaml)するには、[この設定例から開始](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/primary.yaml)します。 + +1. チャートが使用するデータベースパスワードを含むシークレットを作成します。次の`PASSWORD`を`gitlab`データベースユーザーのパスワードに置き換えます。 + + ```shell + kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD + ``` + +1. [設定例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/primary.yaml)に基づいて`primary.yaml`ファイルを作成し、正しい値を反映するように設定を更新します。 + + ```yaml + ### Geo Primary + global: + # See docs.gitlab.com/charts/charts/globals + # Configure host & domain + hosts: + domain: example.com + # optionally configure a static IP for the default LoadBalancer + # externalIP: + # optionally configure a static IP for the Geo LoadBalancer + # externalGeoIP: + # configure DB connection + psql: + host: geo-1.db.example.com + port: 5432 + password: + secret: geo + key: postgresql-password + # configure geo (primary) + geo: + nodeName: London Office + enabled: true + role: primary + # configure Geo Nginx Controller for internal Geo site traffic + nginx-ingress-geo: + enabled: true + gitlab: + webservice: + # Use the Geo NGINX controller. + ingress: + useGeoClass: true + # Configure an Ingress for internal Geo traffic + extraIngress: + enabled: true + hostname: gitlab.london.example.com + useGeoClass: true + # External DB, disable + postgresql: + install: false + ``` + + + - [`global.hosts.domain`](../../charts/globals.md#configure-host-settings) + - [`global.psql.host`](../../charts/globals.md#configure-postgresql-settings) + - `global.geo.nodeName`は[管理者エリアのGeoサイトの名前フィールド](https://docs.gitlab.com/administration/geo_sites/#common-settings)と一致する必要があります + - セカンダリから転送されたGeoトラフィックの[Ingress](../../charts/nginx/_index.md#gitlab-geo) [コントローラー](../../charts/nginx/_index.md#gitlab-geo)を有効にするには、[`nginx-ingress-geo.enabled`](../../charts/nginx/_index.md#gitlab-geo)を設定します。 + - Geoトラフィック用に、[プライマリ](../../charts/gitlab/webservice/_index.md#ingress-settings)Geoサイトの[`gitlab.webservice`](../../charts/gitlab/webservice/_index.md#ingress-settings) [Ingress](../../charts/gitlab/webservice/_index.md#ingress-settings)を[設定](../../charts/gitlab/webservice/_index.md#ingress-settings)します。 + - また、次のような追加の設定も設定します。 + - [SSL/TLSの設定](../../installation/tools.md#tls-certificates) + - [外部Redisの使用](../external-redis/_index.md) + - [外部オブジェクトストレージの使用](../external-object-storage/_index.md) + + +1. この設定を使用してチャートをデプロイします。 + + ```shell + helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml + ``` + + {{< alert type="note" >}} + + これは、`gitlab`名前空間を使用していることを前提としています。別の名前空間を使用する場合は、このドキュメントの残りの部分全体で`--namespace gitlab`でも置き換える必要があります。 + + {{< /alert >}} + +1. デプロイが完了し、アプリケーションがオンラインになるまで待ちます。アプリケーションに到達できるようになったら、ログインします。 + +1. GitLabに[サイン](https://docs.gitlab.com/administration/license/)インし、[GitLabサブスクリプションをアクティブ化](https://docs.gitlab.com/administration/license/)します。 + + {{< alert type="note" >}} + + このステップは、Geoが機能するために必要です。 + + {{< /alert >}} + +## Geoプライマリサイトを設定する {#set-the-geo-primary-site} + +チャートがデプロイされ、ライセンスがアップロードされたので、これをプライマリサイトとして設定できます。これは、Toolbox Podを介して行います。 + +1. Toolbox Podを検索 + + ```shell + kubectl --namespace gitlab get pods -lapp=toolbox + ``` + +1. `kubectl exec`で`gitlab-rake geo:set_primary_node`を実行します： + + ```shell + kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_primary_node + ``` + +1. Rails runnerコマンドを使用して、プライマリサイトの内部URLを設定します。`https://primary.gitlab.example.com`を実際の内部URLに置き換えます： + + ```shell + kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.primary_node.update!(internal_url: 'https://primary.gitlab.example.com')" + ``` + +1. Geo設定の状態をチェックします。 + + ```shell + kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:check + ``` + + 以下のような出力が表示されるはずです。 + + ```plaintext + WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell. + Checking Geo ... + + GitLab Geo is available ... yes + GitLab Geo is enabled ... yes + GitLab Geo secondary database is correctly configured ... not a secondary node + Database replication enabled? ... not a secondary node + Database replication working? ... not a secondary node + GitLab Geo HTTP(S) connectivity ... not a secondary node + HTTP/HTTPS repository cloning is enabled ... yes + Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype + Git user has default SSH configuration? ... yes + OpenSSH configured to use AuthorizedKeysCommand ... no + Reason: + Cannot find OpenSSH configuration file at: /assets/sshd_config + Try fixing it: + If you are not using our official docker containers, + make sure you have OpenSSH server installed and configured correctly on this system + For more information see: + doc/administration/operations/fast_ssh_key_lookup.md + GitLab configured to disable writing to authorized_keys file ... yes + GitLab configured to store new projects in hashed storage? ... yes + All projects are in hashed storage? ... yes + + Checking Geo ... Finished + ``` + + - Kubernetesコンテナはホストクロックにアクセスできないため、`Exception: getaddrinfo: Servname not supported for ai_socktype`を心配しないでください。これは_OK_です。 + - `OpenSSH configured to use AuthorizedKeysCommand ... no`は_想定_されています。このRakeタスクはローカルSSHサーバーをチェックしていますが、実際には`gitlab-shell`チャートに存在し、別の場所にデプロイされ、すでに適切に設定されています。 + +## セカンダリデータベースを設定 {#configure-secondary-database} + +_このセクションは、セカンダリLinuxパッケージインストールデータベースノードで実行されます。_ + +セカンダリデータベースノードのLinuxパッケージインストールを設定するには、この設定例から作業します。 + +```ruby +### Geo Secondary +# external_url must match the Primary cluster's external_url +external_url 'http://gitlab.example.com' +roles ['geo_secondary_role'] +gitlab_rails['enable'] = true +# The unique identifier for the Geo node. +gitlab_rails['geo_node_name'] = 'Shanghai Office' +gitlab_rails['auto_migrate'] = false +geo_secondary['auto_migrate'] = false +## turn off everything but the DB +sidekiq['enable']=false +puma['enable']=false +gitlab_workhorse['enable']=false +nginx['enable']=false +geo_logcursor['enable']=false +gitaly['enable']=false +redis['enable']=false +prometheus_monitoring['enable'] = false +gitlab_kas['enable']=false +## Configure the DBs for network +postgresql['enable'] = true +postgresql['listen_address'] = '0.0.0.0' +postgresql['sql_user_password'] = 'gitlab_user_password_hash' +# !! CAUTION !! +# This list of CIDR addresses should be customized +# - secondary application deployment +# - secondary database node(s) +postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0'] +geo_postgresql['listen_address'] = '0.0.0.0' +geo_postgresql['sql_user_password'] = 'gitlab_geo_user_password_hash' +# !! CAUTION !! +# This list of CIDR addresses should be customized +# - secondary application deployment +# - secondary database node(s) +geo_postgresql['md5_auth_cidr_addresses'] = ['0.0.0.0/0'] +gitlab_rails['db_password']='gitlab_user_password' +``` + +いくつかのアイテムを置き換える必要があります。 + +- `gitlab_rails['geo_node_name']`は、サイトの一意の名前に置き換える必要があります。[共通設定](https://docs.gitlab.com/administration/geo_sites/#common-settings)の名前フィールドを参照してください。 +- `gitlab_user_password_hash`は、`gitlab`パスワードのハッシュ形式に置き換える必要があります。 +- `postgresql['md5_auth_cidr_addresses']`は、明示的なIPアドレスのリスト、またはCIDR表記のアドレスブロックになるように更新する必要があります。 +- `gitlab_geo_user_password_hash`は、`gitlab_geo`パスワードのハッシュ形式に置き換える必要があります。 +- `geo_postgresql['md5_auth_cidr_addresses']`は、明示的なIPアドレスのリスト、またはCIDR表記のアドレスブロックになるように更新する必要があります。 +- `gitlab_user_password`は更新する必要があり、LinuxがPostgreSQLのを自動化できるようにするためにここで使用されます。 + +`md5_auth_cidr_addresses`は、`[ '127.0.0.1/24', '10.41.0.0/16']`の形式にする必要があります。Linuxの自動化がこれを使用して接続するため、このリストに`127.0.0.1`を含めることが重要です。このリストのアドレスには、セカンダリKubernetesのすべてのノードのIPアドレスを含める必要があります。この_は_`['0.0.0.0/0']`のままにすることもできますが、_ベストプラクティスではありません_。 + +上記のを作成した後: + +1. **プライマリ**サイトのPostgreSQLノードへのTCPを確認します。 + + ```shell + openssl s_client -connect :5432 }} + + この手順が失敗した場合は、間違ったIPアドレスを使用しているか、ファイアウォールがサーバーへのアクセスをしている可能性があります。IPアドレスを確認し、パブリックアドレスとプライベートアドレスの違いに注意し、ファイアウォールが存在する場合は、**セカンダリ**PostgreSQLノードがTCP5432で**プライマリ**PostgreSQLノードにできることを確認してください。 + + {{< /alert >}} + +1. `/etc/gitlab/gitlab.rb`にコンテンツを配置します +1. `gitlab-ctl reconfigure`を実行します。サービスがTCPでリッスンしていないことに関して問題が発生した場合は、`gitlab-ctl restart postgresql`で直接再起動してみてください。 +1. 上記のプライマリPostgreSQLノードの証明書の内容を`primary.crt`に配置します +1. **セカンダリ** PostgreSQLノードでPostgreSQL TLS検証を設定します: + + `primary.crt`ファイルをインストールします: + + ```shell + install \ + -D \ + -o gitlab-psql \ + -g gitlab-psql \ + -m 0400 \ + -T primary.crt ~gitlab-psql/.postgresql/root.crt + ``` + + PostgreSQLは、TLSを検証する際に、その正確な証明書のみを認識するようになります。証明書は、プライベートキーへのアクセス権を持つユーザーのみができます。これは、**プライマリ** PostgreSQLノードに**のみ**存在します。 + +1. `gitlab-psql`ユーザーが**プライマリ**サイトのPostgreSQLにできることをテストします（デフォルトのLinuxデータベース名は`gitlabhq_production`です）。 + + ```shell + sudo \ + -u gitlab-psql /opt/gitlab/embedded/bin/psql \ + --list \ + -U gitlab_replicator \ + -d "dbname=gitlabhq_production sslmode=verify-ca" \ + -W \ + -h + ``` + + `gitlab_replicator`ユーザーに対して収集されたパスワードを入力するように求められたら、パスワードを入力します。すべてが正しく機能していれば、**プライマリ** PostgreSQLノードのデータベースのリストが表示されます。 + + ここへのの失敗は、TLSが正しくないことを示しています。**プライマリ** PostgreSQLノードの`~gitlab-psql/data/server.crt`の内容が、**セカンダリ** PostgreSQLノードの`~gitlab-psql/.postgresql/root.crt`の内容と一致していることを確認します。 + +1. データベースをします。`PRIMARY_DATABASE_HOST`をプライマリPostgreSQLノードのIPまたはホスト名に置き換えます: + + ```shell + gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca + ``` + +1. が完了したら、Linuxをもう一度再して、セカンダリPostgreSQLノードの`pg_hba.conf`が正しいことを確認する必要があります: + + ```shell + gitlab-ctl reconfigure + ``` + +## サイトからサイトにをコピーします {#copy-secrets-from-the-primary-site-to-the-secondary-site} + +サイトのKubernetesからサイトのKubernetesにいくつかのをコピーします。 + +- `gitlab-geo-gitlab-shell-host-keys` +- `gitlab-geo-rails-secret` +- `gitlab-geo-registry-secret`（のが有効な場合）。 + +1. `kubectl`コンテキストをプライマリのコンテキストに変更します。 +1. からこれらのを収集します。 + + ```shell + kubectl get --namespace gitlab -o yaml secret gitlab-geo-gitlab-shell-host-keys > ssh-host-keys.yaml + kubectl get --namespace gitlab -o yaml secret gitlab-geo-rails-secret > rails-secrets.yaml + kubectl get --namespace gitlab -o yaml secret gitlab-geo-registry-secret > registry-secrets.yaml + ``` + +1. `kubectl`コンテキストをセカンダリのコンテキストに変更します。 +1. これらのを適用します。 + + ```shell + kubectl --namespace gitlab apply -f ssh-host-keys.yaml + kubectl --namespace gitlab apply -f rails-secrets.yaml + kubectl --namespace gitlab apply -f registry-secrets.yaml + ``` + +次に、データベースパスワードを含むを作成します。以下のパスワードを適切なに置き換えます。 + +```shell +kubectl --namespace gitlab create secret generic geo \ + --from-literal=postgresql-password=gitlab_user_password \ + --from-literal=geo-postgresql-password=gitlab_geo_user_password +``` + +## セカンダリサイトとしてをします {#deploy-chart-as-geo-secondary-site} + +_このセクションは、セカンダリサイトのKubernetesで実行されます。_ + +このをセカンダリサイトとしてするには、[この例から開始します](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/secondary.yaml)。 + +1. [の例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/geo/secondary.yaml)に基づいて`secondary.yaml`ファイルを作成し、正しいを反映するようにを更新します: + + ```yaml + ## Geo Secondary + global: + # See docs.gitlab.com/charts/charts/globals + # Configure host & domain + hosts: + domain: shanghai.example.com + # use a unified URL (same external URL as the primary site) + gitlab: + name: gitlab.example.com + # configure DB connection + psql: + host: geo-2.db.example.com + port: 5432 + password: + secret: geo + key: postgresql-password + # configure geo (secondary) + geo: + enabled: true + role: secondary + nodeName: Shanghai Office + psql: + host: geo-2.db.example.com + port: 5431 + password: + secret: geo + key: geo-postgresql-password + # Optional for secondary sites: Configure Geo Nginx Controller for internal Geo site traffic. + # nginx-ingress-geo: + # enabled: true + gitlab: + webservice: + # Configure a Ingress for internal Geo traffic + extraIngress: + enabled: true + hostname: shanghai.gitlab.example.com + # External DB, disable + postgresql: + install: false + ``` + + + - [`global.hosts.domain`](../../charts/globals.md#configure-host-settings) + - [`global.psql.host`](../../charts/globals.md#configure-postgresql-settings) + - [`global.geo.psql.host`](../../charts/globals.md#configure-postgresql-settings) + - `global.geo.nodeName`は、[管理者エリアのサイトの[名前]フィールド](https://docs.gitlab.com/administration/geo_sites/#common-settings)と一致する必要があります + - `nginx-ingress-geo.enabled`を設定して、内部トラフィック用に事前にされた を有効にすることもできます。[これにより、サイトをプライマリにすることが容易になります](../../charts/nginx/_index.md#gitlab-geo)。 + - [gitlab.webservice](../../charts/gitlab/webservice/_index.md#ingress-settings)の追加の をして、セカンダリサイトの内部URLに送信されるトラフィックを処理します。 + - その他の追加もします。次に例を示します。 + - [SSL/TLSの](../../installation/tools.md#tls-certificates) + - [外部Redisの使用](../external-redis/_index.md) + - [外部オブジェクトストレージの使用](../external-object-storage/_index.md) + - 外部データベースの場合、`global.psql.host`はセカンダリの読み取り専用データベースであり、`global.geo.psql.host`は のトラッキングデータベースです + + +1. このを使用してをします: + + ```shell + helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml + ``` + +1. が完了し、アプリケーションがオンラインになるまで待ちます。 + +## 経由でセカンダリサイトを追加します {#add-secondary-geo-site-via-primary} + +両方のデータベースがされ、アプリケーションがされたので、サイトにサイトが存在することを伝える必要があります: + +1. **プライマリ**サイトにアクセスします。 +1. 左側のサイドバーの一番下にある**管理者エリア**を選択します。 +1. ** > サイトを追加**を選択します。 +1. **セカンダリ**サイトを追加します。URLには完全なGitLab URLを使用します。 +1. セカンダリサイトの`global.geo.nodeName`を持つ名前を入力します。これらのは常に文字どおり完全に一致する必要があります。 +1. 内部URL（例：`https://shanghai.gitlab.example.com`）を入力します。 +1. オプションで、**セカンダリ**サイトでするグループまたはストレージを選択します。すべてをするには、空白のままにします。 +1. **ノードを追加**を選択します。 + +**セカンダリ**サイトが管理パネルに追加されると、**プライマリ**サイトからの不足しているデータのが自動的に開始されます。このプロセスは「埋め戻し」と呼ばれます。その間、**プライマリ**サイトは各**セカンダリ**サイトに変更を通知し始め、**セカンダリ**サイトはそれらの変更を迅速にできます。 + +## 稼働を確認します {#confirm-operational-status} + +最後の手順は、完全にされたら、Toolboxを介してセカンダリサイトの を再確認することです。 + +1. Toolboxを検索します: + + ```shell + kubectl --namespace gitlab get pods -lapp=toolbox + ``` + +1. `kubectl exec`を使用してにアタッチします: + + ```shell + kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l + ``` + +1. のを確認します: + + ```shell + gitlab-rake gitlab:geo:check + ``` + + 出力は次のようになります。 + + ```plaintext + WARNING: This version of GitLab depends on gitlab-shell 10.2.0, but you're running Unknown. Please update gitlab-shell. + Checking Geo ... + + GitLab Geo is available ... yes + GitLab Geo is enabled ... yes + GitLab Geo secondary database is correctly configured ... yes + Database replication enabled? ... yes + Database replication working? ... yes + GitLab Geo HTTP(S) connectivity ... + * Can connect to the primary node ... yes + HTTP/HTTPS repository cloning is enabled ... yes + Machine clock is synchronized ... Exception: getaddrinfo: Servname not supported for ai_socktype + Git user has default SSH configuration? ... yes + OpenSSH configured to use AuthorizedKeysCommand ... no + Reason: + Cannot find OpenSSH configuration file at: /assets/sshd_config + Try fixing it: + If you are not using our official docker containers, + make sure you have OpenSSH server installed and configured correctly on this system + For more information see: + doc/administration/operations/fast_ssh_key_lookup.md + GitLab configured to disable writing to authorized_keys file ... yes + GitLab configured to store new projects in hashed storage? ... yes + All projects are in hashed storage? ... yes + + Checking Geo ... Finished + ``` + + - Kubernetesコンテナはホストクロックにアクセスできないため、`Exception: getaddrinfo: Servname not supported for ai_socktype`を心配しないでください。_これはOK_です。 + - `OpenSSH configured to use AuthorizedKeysCommand ... no`_が想定されます_。このはローカルサーバーをチェックしていますが、これは実際には`gitlab-shell`に存在し、別の場所にされ、すでに適切にされています。 + +## サイトの別のURLをします（オプション） {#configure-a-separate-url-for-the-secondary-site-optional} + +サイトとサイトの単一の統合URLは、通常、ユーザーにとってより便利です。たとえば、次のことができます。 + +- 両方のサイトをの背後に配置します。 +- クラウドプロバイダーのを使用して、ユーザーを最寄りのサイトにルーティングします。 + +場合によっては、ユーザーにアクセスするサイトを制御させたいことがあります。このために、 サイトをして、一意の外部URLを使用できます。次に例を示します。 + +- の外部URL：`https://gitlab.example.com` +- の外部URL：`https://shanghai.gitlab.example.com` + +1. `secondary.yaml`を編集し、`webservice`がこれらのを処理できるように、セカンダリの外部URLを更新します。 + + ```yaml + global: + # See docs.gitlab.com/charts/charts/globals + # Configure host & domain + hosts: + domain: example.com + # use a unique external URL for the secondary site + gitlab: + name: shanghai.gitlab.example.com + ``` + +1. GitLabでセカンダリサイトの外部URLを更新して、必要な場所でURLを使用できるようにします。 + - 管理者の使用: + 1. **プライマリ**サイトにアクセスします。 + 1. 左側のサイドバーの一番下にある**管理者エリア**を選択します。 + 1. ** > サイト**を選択します。 + 1. 鉛筆を選択して、**セカンダリサイトを編集**します。 + 1. 外部URL（例：`https://shanghai.gitlab.example.com`）を編集します。 + 1. **変更の保存**を選択します。 + +1. セカンダリサイトのを再します: + + ```shell + helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml + ``` + +1. が完了し、アプリケーションがオンラインになるまで待ちます。 + +## {#registry} + +セカンダリ[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)をプライマリ[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)と[同期](../../charts/registry/_index.md#notification-secret)するには、[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)の[レプリケーション](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)を[通知シークレット](../../charts/registry/_index.md#notification-secret)を使用して[設定](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)できます。 + +## Cert-managerと統合URL {#cert-manager-and-unified-url} + +の統合URLは、位置情報認識ルーティング（たとえば、Amazon Route 53またはGoogle Cloudの使用）でよく使用されます。これにより、ドメイン名が管理下にあることをするために[HTTP01 ](https://letsencrypt.org/docs/challenge-types/#http-01-challenge)が使用されている場合に問題が発生する可能性があります。 + +1つのサイトの証明書をすると、Let'sは名をしているサイトにする必要があります。が別のサイトにされる場合、統合URLの証明書は発行またはされません。 + +cert-managerで証明書を確実に作成および[更新](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)するには、統合ホスト名を[Geo](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)サイトのアドレスに[解決](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)することがわかっているサーバーに[Challenge](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks) [ネームサーバー](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)を[設定](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)するか、[DNS01](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge) [Issuer](https://cert-manager.io/docs/configuration/acme/dns01/)を[設定](https://cert-manager.io/docs/configuration/acme/http01/#setting-nameservers-for-http-01-solver-propagation-checks)します。 diff --git a/doc-locale/ja-jp/advanced/internal-tls/_index.md b/doc-locale/ja-jp/advanced/internal-tls/_index.md new file mode 100644 index 0000000000..44a3b52676 --- /dev/null +++ b/doc-locale/ja-jp/advanced/internal-tls/_index.md @@ -0,0 +1,230 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのコンポーネント間でTLSを使用する +--- + +GitLabチャートは、さまざまなコンポーネント間でトランスポート層セキュリティ（TLS）を使用できます。これには、有効にするサービス用の証明書を提供し、それらの証明書と、それらに署名した公開認証局（CA）を利用するようにそれらのサービスを設定する必要があります。 + +## 準備 {#preparation} + +各チャートには、そのサービスのTLSを有効にする方法、および適切な設定を保証するために必要なさまざまな設定に関するドキュメントがあります。 + +### 内部使用向けの証明書の生成 {#generating-certificates-for-internal-use} + +{{< alert type="note" >}} + +GitLabは、高度なPKIインフラストラクチャ、または認証局を提供することを目的としていません。 + +{{< /alert >}} + +このドキュメントでは、**概念実証**スクリプトを以下に提供します。これは、自己署名公開認証局（CA）を生成するために[CloudflareのCFSSL](https://github.com/cloudflare/cfssl/)を使用し、すべてのサービスに使用できるワイルドカード証明書を生成します。 + +このスクリプト: + +- CAキーペアを生成します。 +- すべてのGitLabコンポーネントサービスエンドポイントを提供する証明書に署名します。 +- 2つのKubernetesシークレット オブジェクトを作成します。 + - サーバー証明書とキーペアを持つ`kuberetes.io/tls`タイプのシークレット。 + - `Opaque`タイプの**シークレット**。これは、Ingress CAの公開証明書のみを`ca.crt`として含みます。 + +前提要件: + +- Bash、または互換性のあるShell。 +- `cfssl`がShellで使用可能であり、`PATH`内に存在すること。 +- `kubectl`が使用可能で、GitLabを後でインストールするKubernetesクラスターを指すように構成されていること。 + - スクリプトを実行する前に、これらの証明書をインストールするネームスペースを作成しておくようにしてください。 + +このスクリプトの内容をコンピューターにコピーして、結果のファイルを実行可能ファイルにすることができます。`poc-gitlab-internal-tls.sh`をお勧めします。 + +```shell +#!/bin/bash +set -e +############# +## make and change into a working directory +pushd $(mktemp -d) + +############# +## setup environment +NAMESPACE=${NAMESPACE:-default} +RELEASE=${RELEASE:-gitlab} +## stop if variable is unset beyond this point +set -u +## known expected patterns for SAN +CERT_SANS="*.${NAMESPACE}.svc,${RELEASE}-metrics.${NAMESPACE}.svc,*.${RELEASE}-gitaly.${NAMESPACE}.svc" + +############# +## generate default CA config +cfssl print-defaults config > ca-config.json +## generate a CA +echo '{"CN":"'${RELEASE}.${NAMESPACE}.internal.ca'","key":{"algo":"ecdsa","size":256}}' | \ + cfssl gencert -initca - | \ + cfssljson -bare ca - +## generate certificate +echo '{"CN":"'${RELEASE}.${NAMESPACE}.internal'","key":{"algo":"ecdsa","size":256}}' | \ + cfssl gencert -config=ca-config.json -ca=ca.pem -ca-key=ca-key.pem -profile www -hostname="${CERT_SANS}" - |\ + cfssljson -bare ${RELEASE}-services + +############# +## load certificates into K8s +kubectl -n ${NAMESPACE} create secret tls ${RELEASE}-internal-tls \ + --cert=${RELEASE}-services.pem \ + --key=${RELEASE}-services-key.pem +kubectl -n ${NAMESPACE} create secret generic ${RELEASE}-internal-tls-ca \ + --from-file=ca.crt=ca.pem +``` + +{{< alert type="note" >}} + +この_スクリプト_は、CAのプライベートキーを保持しません。これは概念実証ヘルパーであり、_本番環境_での使用を意図したものではありません。 + +{{< /alert >}} + +このスクリプトは、2つの環境変数が設定されていることを想定しています。 + +1. `NAMESPACE`:GitLabを後でインストールするKubernetesネームスペース。これは、`default`と同様に、`kubectl`にデフォルト設定されています。 +1. `RELEASE`:GitLabを後でインストールするために使用するHelmリリース名。これは`gitlab`にデフォルト設定されています。 + +このスクリプトを操作するには、2つの変数を`export`するか、スクリプト名の前にそれらの値を付加することができます。 + +```shell +export NAMESPACE=testing +export RELEASE=gitlab + +./poc-gitlab-internal-tls.sh +``` + +スクリプトの実行後、作成された2つのシークレットが見つかり、一時的な作業ディレクトリにはすべての証明書とそのキーが含まれます。 + +```plaintext +$ pwd +/tmp/tmp.swyMgf9mDs +$ kubectl -n ${NAMESPACE} get secret | grep internal-tls +testing-internal-tls kubernetes.io/tls 2 11s +testing-internal-tls-ca Opaque 1 10s +$ ls -1 +ca-config.json +ca.csr +ca-key.pem +ca.pem +testing-services.csr +testing-services-key.pem +testing-services.pem +``` + +#### 必要な証明書のCNとSAN {#required-certificate-cn-and-sans} + +さまざまなGitLabコンポーネントは、それぞれのサービスのDNS名を使用して相互に通信します。GitLabチャートによって生成されたIngressオブジェクトは、`tls.verify: true`（これはデフォルトです）の場合、検証する名前をNGINXに提供する必要があります。この結果、各GitLabコンポーネントは、サービスのDNSエントリに受け入れ可能なサービスの名前またはワイルドカードを含むSANを持つ証明書を受け取る必要があります。 + +- `service-name.namespace.svc` +- `*.namespace.svc` + +証明書_内_でこれらのSANを確保できないと、機能しないインスタンスになり、「接続の失敗」または「SSL検証の失敗」を指す、かなり意味不明なログが表示されます。 + +必要に応じて、`helm template`を使用して、すべてのサービスオブジェクト名の完全なリストを取得できます。GitLabがTLSなしでデプロイされている場合、それらの名前についてKubernetesにクエリできます: + +`kubectl -n ${NAMESPACE} get service -lrelease=${RELEASE}` + +## 設定 {#configuration} + +[設定](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/internal-tls/)の例は、[examples/internal-tls](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/internal-tls/)にあります。 + +このドキュメントでは、`shared-cert-values.yaml`を提供しました。これは、上記の内部使用向けの証明書の生成の[スクリプト](#generating-certificates-for-internal-use)で生成された証明書を使用するようにGitLabコンポーネントを構成します。 + +設定するキー項目: + +1. グローバル[カスタムCA証明書](../../charts/globals.md#custom-certificate-authorities)。 +1. サービスリスナーごとのTLS。（各[チャート](../../charts/_index.md)のドキュメントのcharts/を参照してください） + +このプロセスは、YAMLのネイティブアンカー機能を利用することで大幅に簡略化されます。`shared-cert-values.yaml`の切り詰められた スニペットはこれを示しています: + +```yaml +.internal-ca: &internal-ca gitlab-internal-tls-ca +.internal-tls: &internal-tls gitlab-internal-tls + +global: + certificates: + customCAs: + - secret: *internal-ca + workhorse: + tls: + enabled: true +gitlab: + webservice: + tls: + secretName: *internal-tls + workhorse: + tls: + verify: true # default + secretName: *internal-tls + caSecretName: *internal-ca +``` + +## 結果 {#result} + +すべてのコンポーネントがサービスリスナーでTLSを提供するように構成されている場合、すべてのGitLabコンポーネント間のすべての通信は、NGINX Ingressから各GitLabコンポーネントへの接続を含め、TLSセキュリティでネットワークを通過します。 + +_NGINX_ Ingressは受信TLSを終了し、トラフィックを渡す適切なサービスを決定し、次にGitLabコンポーネントへの新しいTLS接続を形成します。ここに示されているように構成されている場合、_CA_に対してGitLabコンポーネントによって提供される証明書も_検証_します。 + +これは、Toolboxポッドに接続し、さまざまなコンポーネントサービスにクエリすることで検証できます。そのような例の1つは、NGINX Ingressが使用するWebserviceポッドのプライマリサービスポートへの接続です。 + +```plaintext +$ kubectl -n ${NAMESPACE} get pod -lapp=toolbox,release=${RELEASE} +NAME READY STATUS RESTARTS AGE +gitlab-toolbox-5c447bfdb4-pfmpc 1/1 Running 0 65m +$ kubectl exec -ti gitlab-toolbox-5c447bfdb4-pfmpc -c toolbox -- \ + curl -Iv "https://gitlab-webservice-default.testing.svc:8181" +``` + +出力は、次の例と同様である必要があります: + +```plaintext +* Trying 10.60.0.237:8181... +* Connected to gitlab-webservice-default.testing.svc (10.60.0.237) port 8181 (#0) +* ALPN, offering h2 +* ALPN, offering http/1.1 +* successfully set certificate verify locations: +* CAfile: /etc/ssl/certs/ca-certificates.crt +* CApath: /etc/ssl/certs +* TLSv1.3 (OUT), TLS handshake, Client hello (1): +* TLSv1.3 (IN), TLS handshake, Server hello (2): +* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): +* TLSv1.3 (IN), TLS handshake, Certificate (11): +* TLSv1.3 (IN), TLS handshake, CERT verify (15): +* TLSv1.3 (IN), TLS handshake, Finished (20): +* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): +* TLSv1.3 (OUT), TLS handshake, Finished (20): +* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 +* ALPN, server did not agree to a protocol +* Server certificate: +* subject: CN=gitlab.testing.internal +* start date: Jul 18 19:15:00 2022 GMT +* expire date: Jul 18 19:15:00 2023 GMT +* subjectAltName: host "gitlab-webservice-default.testing.svc" matched cert's "*.testing.svc" +* issuer: CN=gitlab.testing.internal.ca +* SSL certificate verify ok. +> HEAD / HTTP/1.1 +> Host: gitlab-webservice-default.testing.svc:8181 +``` + +## トラブルシューティング {#troubleshooting} + +GitLabインスタンスがブラウザーからアクセスできないように見える場合、HTTP 503エラーをレンダリングすると、NGINX IngressはGitLabコンポーネントの証明書の検証で問題が発生している可能性があります。 + +これを回避するには、一時的に`gitlab.webservice.workhorse.tls.verify`を`false`に設定します。 + +NGINX Ingressコントローラーは接続でき、証明書の検証に関する問題について、`nginx.conf`にメッセージが表示されます。 + +シークレットにアクセスできない場合のコンテンツ例: + +```plaintext +# Location denied. Reason: "error obtaining certificate: local SSL certificate + testing/gitlab-internal-tls-ca was not found" +return 503; +``` + +これが原因で発生する一般的な問題: + +- CA証明書がシークレット内の`ca.crt`という名前のキーにありません。 +- シークレットが正しく提供されていないか、ネームスペース内に存在しない可能性があります。 diff --git a/doc-locale/ja-jp/advanced/multiple-databases/_index.md b/doc-locale/ja-jp/advanced/multiple-databases/_index.md new file mode 100644 index 0000000000..5a26d1716d --- /dev/null +++ b/doc-locale/ja-jp/advanced/multiple-databases/_index.md @@ -0,0 +1,14 @@ +--- +redirect_to: '../_index.md' +remove_date: '2025-06-09' +--- + + + + +この[ドキュメント](../_index.md)は、別の場所に移されました。 + + + + + diff --git a/doc-locale/ja-jp/advanced/persistent-volumes/_index.md b/doc-locale/ja-jp/advanced/persistent-volumes/_index.md new file mode 100644 index 0000000000..e88f97e5ea --- /dev/null +++ b/doc-locale/ja-jp/advanced/persistent-volumes/_index.md @@ -0,0 +1,423 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: 永続ボリュームでGitLabチャートを設定する +--- + +含まれているサービスの一部では、クラスターがアクセスできるディスクを指定する[永続ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を介して設定された永続ストレージが必要です。このチャートのインストールに必要なストレージ[設定](../../installation/storage.md)に関するドキュメントは、[ストレージガイド](../../installation/storage.md)にあります。 + +インストール後のストレージの変更は、クラスターの管理者によって手動で処理する必要があります。インストール後のこれらのボリュームの自動管理は、GitLabチャートでは処理されません。 + +最初のインストール後に自動的に管理されない変更の例を以下に示します。 + +- ポッドへの異なるボリュームのマウント +- 有効なaccessModesまたは[Storage Class](https://kubernetes.io/docs/concepts/storage/storage-classes/)の変更 +- ボリューム*1のストレージサイズの展開 + +1 Kubernetes 1.11では、`allowVolumeExpansion`が[Storage Class](https://kubernetes.io/docs/concepts/storage/storage-classes/)でtrueに設定されている場合、[ボリュームのストレージサイズの展開がサポートされます](https://kubernetes.io/blog/2018/07/12/resizing-persistent-volumes-using-kubernetes/)。 + +これらの変更の自動化は、次の理由により複雑になります。 + +1. Kubernetesでは、既存の[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)のほとんどのフィールドへの変更は許可されていません +1. [手動で設定](../../installation/storage.md)されていない限り、[PVC](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)は、動的にプロビジョニングされた[PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)への唯一の参照です +1. `Delete`は、動的にプロビジョニングされた[PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)のデフォルトの[reclaimPolicy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy)です + +つまり、変更を行うには、[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を削除し、変更を加えて新しいものを作成する必要があります。ただし、デフォルトの[reclaimPolicy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy)により、[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を削除すると、[PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)と基盤となるディスクが削除される可能性があります。また、適切なvolumeNamesやlabelSelectorsで設定されていない限り、チャートはアタッチするボリュームを認識しません。 + +このプロセスをより簡単にする方法を引き続き検討していきますが、今のところ、ストレージを変更するには手動プロセスに従う必要があります。 + +## GitLabボリュームの特定 {#locate-the-gitlab-volumes} + +使用されているボリューム/クレームを見つけます: + +```shell +kubectl --namespace get PersistentVolumeClaims -l release= -ojsonpath='{range .items[*]}{.spec.volumeName}{"\t"}{.metadata.labels.app}{"\n"}{end}' +``` + +- ``は、GitLabチャートをインストールしたネームスペースに置き換える必要があります。 +- ``は、GitLabチャートのインストールに使用した名前に置き換える必要があります。 + +このコマンドは、ボリューム名のリストと、それらが対象とするサービスの名前を出力します。 + +次に例を示します。 + +```shell +$ kubectl --namespace helm-charts-win get PersistentVolumeClaims -l release=review-update-app-h8qogp -ojsonpath='{range .items[*]}{.spec.volumeName}{"\t"}{.metadata.labels.app}{"\n"}{end}' +pvc-6247502b-8c2d-11e8-8267-42010a9a0113 gitaly +pvc-61bbc05e-8c2d-11e8-8267-42010a9a0113 minio +pvc-61bc6069-8c2d-11e8-8267-42010a9a0113 postgresql +pvc-61bcd6d2-8c2d-11e8-8267-42010a9a0113 prometheus +pvc-61bdf136-8c2d-11e8-8267-42010a9a0113 redis +``` + +## ストレージを変更する前に {#before-making-storage-changes} + +変更を行う担当者は、クラスターへの管理者アクセス権と、使用されているストレージソリューションへの適切なアクセス権を持っている必要があります。多くの場合、変更はまずストレージソリューションで適用する必要があり、次に結果をKubernetesで更新する必要があります。 + +変更を行う前に、[PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)が`Retain` [reclaimPolicy](https://kubernetes.io/docs/concepts/storage/storage-classes/#reclaim-policy)を使用していることを確認して、変更中に削除されないようにする必要があります。 + +まず、[使用されているボリューム/クレームを見つけます](#locate-the-gitlab-volumes)。 + +次に、各ボリュームを編集し、`spec`フィールドの`persistentVolumeReclaimPolicy`の値を、`Delete`ではなく`Retain`に変更します + +次に例を示します。 + +```shell +kubectl --namespace helm-charts-win edit PersistentVolume pvc-6247502b-8c2d-11e8-8267-42010a9a0113 +``` + +出力の編集: + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +kind: PersistentVolume +metadata: + annotations: + kubernetes.io/createdby: gce-pd-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: "yes" + pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd + creationTimestamp: 2018-07-20T14:58:43Z + labels: + failure-domain.beta.kubernetes.io/region: europe-west2 + failure-domain.beta.kubernetes.io/zone: europe-west2-b + name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + resourceVersion: "48362431" + selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + uid: 650bd649-8c2d-11e8-8267-42010a9a0113 +spec: + accessModes: + - ReadWriteOnce + capacity: + storage: 50Gi + claimRef: + apiVersion: v1 + kind: PersistentVolumeClaim + name: repo-data-review-update-app-h8qogp-gitaly-0 + namespace: helm-charts-win + resourceVersion: "48362307" + uid: 6247502b-8c2d-11e8-8267-42010a9a0113 + gcePersistentDisk: + fsType: ext4 + pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113 +# Changed the following line + persistentVolumeReclaimPolicy: Retain + storageClassName: standard +status: + phase: Bound +``` + +## ストレージの変更 {#making-storage-changes} + +まず、クラスターの外部でディスクに必要な変更を加えます。(GKEでディスクのサイズを変更するか、スナップショットまたはクローンなどから新しいディスクを作成します)。 + +これを行う方法、およびダウンタイムなしでライブで実行できるかどうかは、使用しているストレージソリューションによって異なり、このドキュメントでは説明できません。 + +次に、これらの変更をKubernetesオブジェクトに反映させる必要があるかどうかを評価します。たとえば、ディスクストレージサイズを展開する場合、[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)のストレージサイズ[設定](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)は、新しいボリュームリソースがリクエストされた場合にのみ使用されます。したがって、(追加のGitalyポッドで使用するために) より多くのディスクをスケールアップする場合は、[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の値を増やすだけで済みます。 + +Kubernetesに変更を反映させる必要がある場合は、[ストレージを変更する前に](#before-making-storage-changes)セクションで説明されているように、ボリュームのリクレイムポリシーを更新したことを確認してください。 + +ストレージの変更に関してドキュメント化されているパスは次のとおりです。 + +- [既存のボリュームへの変更](#changes-to-an-existing-volume) +- [別のボリュームへの切り替え](#switching-to-a-different-volume) + +### 既存のボリュームへの変更 {#changes-to-an-existing-volume} + +まず、変更する[ボリューム名](#locate-the-gitlab-volumes)を特定します。 + +`kubectl edit`を使用して、ボリュームに必要な設定の変更を加えます。(これらの変更は、アタッチされたディスクの実際の状態を反映するための更新のみである必要があります) + +次に例を示します。 + +```shell +kubectl --namespace helm-charts-win edit PersistentVolume pvc-6247502b-8c2d-11e8-8267-42010a9a0113 +``` + +出力の編集: + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +kind: PersistentVolume +metadata: + annotations: + kubernetes.io/createdby: gce-pd-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: "yes" + pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd + creationTimestamp: 2018-07-20T14:58:43Z + labels: + failure-domain.beta.kubernetes.io/region: europe-west2 + failure-domain.beta.kubernetes.io/zone: europe-west2-b + name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + resourceVersion: "48362431" + selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + uid: 650bd649-8c2d-11e8-8267-42010a9a0113 +spec: + accessModes: + - ReadWriteOnce + capacity: + # Updated the storage size + storage: 100Gi + claimRef: + apiVersion: v1 + kind: PersistentVolumeClaim + name: repo-data-review-update-app-h8qogp-gitaly-0 + namespace: helm-charts-win + resourceVersion: "48362307" + uid: 6247502b-8c2d-11e8-8267-42010a9a0113 + gcePersistentDisk: + fsType: ext4 + pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + persistentVolumeReclaimPolicy: Retain + storageClassName: standard +status: + phase: Bound +``` + +変更が[ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)に反映されたので、[クレーム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を更新する必要があります。 + +[PersistentVolumeClaimを変更する](#make-changes-to-the-persistentvolumeclaim)セクションの手順に従ってください。 + +#### クレームにバインドするようにボリュームを更新する {#update-the-volume-to-bind-to-the-claim} + +別のターミナルで、[クレーム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)のステータスがboundに変わるタイミングを監視し始め、次のステップに進んで、ボリュームを新しいクレームで使用できるようにします。 + +```shell +kubectl --namespace get --watch PersistentVolumeClaim +``` + +ボリュームを編集して、新しいクレームで使用できるようにします。`.spec.claimRef`セクションを削除します。 + +```shell +kubectl --namespace edit PersistentVolume +``` + +出力の編集: + +```yaml +# Please edit the object below. Lines beginning with a '#' will be ignored, +# and an empty file will abort the edit. If an error occurs while saving this file will be +# reopened with the relevant failures. +# +apiVersion: v1 +kind: PersistentVolume +metadata: + annotations: + kubernetes.io/createdby: gce-pd-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: "yes" + pv.kubernetes.io/provisioned-by: kubernetes.io/gce-pd + creationTimestamp: 2018-07-20T14:58:43Z + labels: + failure-domain.beta.kubernetes.io/region: europe-west2 + failure-domain.beta.kubernetes.io/zone: europe-west2-b + name: pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + resourceVersion: "48362431" + selfLink: /api/v1/persistentvolumes/pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + uid: 650bd649-8c2d-11e8-8267-42010a9a0113 +spec: + accessModes: + - ReadWriteOnce + capacity: + storage: 100Gi + gcePersistentDisk: + fsType: ext4 + pdName: gke-cloud-native-81a17-pvc-6247502b-8c2d-11e8-8267-42010a9a0113 + persistentVolumeReclaimPolicy: Retain + storageClassName: standard +status: + phase: Released +``` + +[ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)への変更後まもなく、クレーム[ステータス](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を監視しているターミナルに`Bound`と表示されるはずです。 + +最後に、[GitLabチャートに変更を適用します](#apply-the-changes-to-the-gitlab-chart) + +### 別のボリュームへの切り替え {#switching-to-a-different-volume} + +新しいボリュームの使用に切り替える場合は、古いボリュームからの適切なデータのコピーを持つディスクを使用して、最初にKubernetesで新しい[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を作成する必要があります。 + +ディスクの永続ボリュームを作成するには、ストレージタイプの[ドライバー固有のドキュメント](https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes)を見つける必要があります。開始点として、同じ[Storage Class](https://kubernetes.io/docs/concepts/storage/storage-classes/)の既存のPersistent Volumeを使用することもできます: + +```shell +kubectl --namespace get PersistentVolume -o yaml > .bak.yaml +``` + +ドライバーのドキュメントに従う場合は、いくつかの注意点があります。 + +- 多くのドキュメントに示されているように、ボリュームを持つPodオブジェクトではなく、ドライバーを使用して[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を作成する必要があります。 +- ボリュームの[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を**作成する**必要はありません。代わりに、既存のクレームを編集します。 + +ドライバーのドキュメントには、多くの場合、Podでドライバーを使用する例が含まれています。次に例を示します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: registry.k8s.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # This GCE PD must already exist. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +実際に必要なのは、次のように[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を作成することです。 + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +通常、[PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)情報を含むローカル`yaml`ファイルを作成し、createコマンドをKubernetesに発行して、ファイルを使用してオブジェクトを作成します。 + +```shell +kubectl --namespace create -f .yaml +``` + +ボリュームが作成されたら、[PersistentVolumeClaimの変更](#make-changes-to-the-persistentvolumeclaim)に進むことができます + +## PersistentVolumeClaimを変更する {#make-changes-to-the-persistentvolumeclaim} + +変更する[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を見つけます。 + +```shell +kubectl --namespace get PersistentVolumeClaims -l release= -ojsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.labels.app}{"\n"}{end}' +``` + +- ``は、GitLabチャートをインストールしたネームスペースに置き換える必要があります。 +- ``は、GitLabチャートのインストールに使用した名前に置き換える必要があります。 + +このコマンドは、PersistentVolumeClaim名のリストと、それらが対象とするサービスの名前を出力します。 + +次に、[クレーム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)のコピーをローカルファイルシステムに保存します: + +```shell +kubectl --namespace get PersistentVolumeClaim -o yaml > .bak.yaml +``` + +出力例: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + annotations: + pv.kubernetes.io/bind-completed: "yes" + pv.kubernetes.io/bound-by-controller: "yes" + volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/gce-pd + creationTimestamp: 2018-07-20T14:58:38Z + labels: + app: gitaly + release: review-update-app-h8qogp + name: repo-data-review-update-app-h8qogp-gitaly-0 + namespace: helm-charts-win + resourceVersion: "48362433" + selfLink: /api/v1/namespaces/helm-charts-win/persistentvolumeclaims/repo-data-review-update-app-h8qogp-gitaly-0 + uid: 6247502b-8c2d-11e8-8267-42010a9a0113 +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 50Gi + storageClassName: standard + volumeName: pvc-6247502b-8c2d-11e8-8267-42010a9a0113 +status: + accessModes: + - ReadWriteOnce + capacity: + storage: 50Gi + phase: Bound +``` + +新しいPVCオブジェクトの新しいYAMLファイルを作成します。同じ`metadata.name`、`metadata.labels`、`metadata.namespace`、および`spec`フィールド(更新を適用)を使用し、その他の設定を削除します: + +例: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + labels: + app: gitaly + release: review-update-app-h8qogp + name: repo-data-review-update-app-h8qogp-gitaly-0 + namespace: helm-charts-win +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + # This is our updated field + storage: 100Gi + storageClassName: standard + volumeName: pvc-6247502b-8c2d-11e8-8267-42010a9a0113 +``` + +次に、古い[クレーム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を削除します: + +```shell +kubectl --namespace delete PersistentVolumeClaim +``` + +削除を完了するには、`finalizers`をクリアする必要がある場合があります: + +```shell +kubectl --namespace patch PersistentVolumeClaim -p '{"metadata":{"finalizers":null}}' +``` + +新しいクレームを作成します: + +```shell +kubectl --namespace create -f +``` + +クレームに以前バインドされていた同じ[PersistentVolume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)にバインドする場合は、[クレームにバインドするようにボリュームを更新](#update-the-volume-to-bind-to-the-claim)に進みます + +それ以外の場合、クレームを新しいボリュームにバインドした場合は、[GitLabチャートに変更を適用](#apply-the-changes-to-the-gitlab-chart)に進みます + +## GitLabチャートに変更を適用する {#apply-the-changes-to-the-gitlab-chart} + +[PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)および[PersistentVolumeClaims](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)に変更を加えた後、変更がチャート[設定](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)にも適用された状態でHelmアップデートを発行することもできます。 + +オプションについては、[インストールストレージガイド](../../installation/storage.md#using-the-custom-storage-class)を参照してください。 + +> **メモ**:Gitaly [volume claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)に変更を加えた場合は、Helmアップデートを発行できるようになる前に、Gitaly [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)を削除する必要があります。これは、StatefulSetのVolume Templateがイミュータブルであり、変更できないためです。 +> +> Gitalyポッドを削除せずに、StatefulSetを削除できます:`kubectl --namespace delete --cascade=false StatefulSet -gitaly` Helm updateコマンドはStatefulSetを再作成し、Gitalyポッドを採用して更新します。 + +チャートを更新し、更新された設定を含めます: + +例: + +```shell +helm upgrade --install review-update-app-h8qogp gitlab/gitlab \ + --set gitlab.gitaly.persistence.size=100Gi \ + +``` diff --git a/doc-locale/ja-jp/advanced/ubi/_index.md b/doc-locale/ja-jp/advanced/ubi/_index.md new file mode 100644 index 0000000000..0f8c541ee7 --- /dev/null +++ b/doc-locale/ja-jp/advanced/ubi/_index.md @@ -0,0 +1,32 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: UBIベースのイメージでGitLabチャートをConfigureする +--- + +GitLabは、イメージの[Red Hat UBI](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image)バージョンを提供しており、標準イメージをUBIベースのイメージに置き換えることができます。これらのイメージは、`-ubi`拡張子を持つ標準イメージと同じtagを使用します。 + +{{< alert type="note" >}} + +GitLab 17.3より前のUBIベースのイメージは、`-ubi8`拡張子を使用します。 + +{{< /alert >}} + +GitLabチャートは、UBIに基づかないサードパーティ製のイメージを使用します。これらのイメージは主に、Redis、PostgreSQLなどの外部サービスをGitLabに提供します。UBIのみをベースとするGitLabインスタンスをdeployする場合は、内部サービスを無効にし、外部のdeploymentまたはサービスを使用する必要があります。 + +無効にして外部から提供する必要があるサービスは次のとおりです。 + +- PostgreSQL +- MinIO（オブジェクトストア） +- Redis + +無効にする必要があるサービスは次のとおりです。 + +- CertManager (Let's Encryptインテグレーション) +- Prometheus +- GitLab Runner + +## サンプル値 {#sample-values} + +純粋なUBI GitLabのdeploymentを構築するのに役立つ、[`examples/ubi/values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/ubi/values.yaml)のGitLabチャート値の例を提供します。 diff --git a/doc-locale/ja-jp/backup-restore/_index.md b/doc-locale/ja-jp/backup-restore/_index.md new file mode 100644 index 0000000000..86fc1f29fa --- /dev/null +++ b/doc-locale/ja-jp/backup-restore/_index.md @@ -0,0 +1,232 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabインスタンスのバックアップとリストア +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLab Helmチャートは、GitLabインスタンスのバックアップとリストアを目的としたインターフェースとして機能するToolboxサブチャートからユーティリティポッドを提供します。このタスクに必要な他のポッドとやり取りする`backup-utility`実行可能ファイルが搭載されています。ユーティリティの動作方法に関する技術的な詳細は、[アーキテクチャドキュメント](../architecture/backup-restore.md)に記載されています。 + +## 前提要件 {#prerequisites} + +- ここに記載されているバックアップとリストアの手順は、S3互換のAPIでのみテストされています。Google Cloud Storageなどの他のオブジェクトストレージサービスのサポートは、将来の改訂でテストされる予定です。 + +- リストア中、バックアップtarボールをディスクに抽出する必要があります。つまり、Toolboxポッドには[必要なサイズのディスク](../charts/gitlab/toolbox/_index.md#restore-considerations)が必要です。 + +- このチャートは、`artifacts`、`uploads`、`packages`、`registry`、`lfs`オブジェクトに[オブジェクトストレージ](#object-storage)を使用しており、リストア中にこれらを移行することはありません。別のインスタンスから取得したバックアップをリストアする場合は、バックアップを実行する前に、既存のインスタンスをオブジェクトストレージを使用するように移行する必要があります。[イシュー646](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/646)を参照してください。 + +## バックアップとリストアの手順 {#backup-and-restoring-procedures} + +- [GitLabインストールのバックアップ](backup.md) +- [GitLabインストールのリストア](restore.md) + +## オブジェクトストレージ {#object-storage} + +[外部オブジェクトストレージ](../advanced/external-object-storage/_index.md)が指定されていない限り、このチャートを使用すると、MinIOインスタンスがすぐに使用できるようになります。特定の設定が指定されていない限り、Toolboxはデフォルトで含まれているMinIOに接続します。Toolboxは、Amazon S3またはGoogle Cloud Storage（GCS）にバックアップするように構成することもできます。 + +### S3へのバックアップ {#backups-to-s3} + +[別のS3ツールを使用するように指定](../backup-restore/backup.md#specify-s3-tool-to-use)しない限り、Toolboxはデフォルトで`s3cmd`を使用してオブジェクトストレージに接続します。外部オブジェクトストレージへの接続を構成するには、`gitlab.toolbox.backups.objectStorage.config.secret`を指定する必要があります。これは、`.s3cfg`ファイルを含むKubernetesシークレットを指します。`config`のデフォルトと異なる場合は、`gitlab.toolbox.backups.objectStorage.config.key`を指定する必要があります。これは、`.s3cfg`ファイルの内容を含むキーを指します。 + +次のように表示されます。 + +```shell +helm install gitlab gitlab/gitlab \ + --set gitlab.toolbox.backups.objectStorage.config.secret=my-s3cfg \ + --set gitlab.toolbox.backups.objectStorage.config.key=config . +``` + +s3cmd `.s3cfg`ファイルのドキュメントは[こちら](https://s3tools.org/kb/item14.htm)にあります + +さらに、2つのバケットの場所を構成する必要があります。1つはバックアップを保存するため、もう1つはバックアップのリストア時に使用される一時バケットです。 + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +``` + +### Google Cloud Storage (GCS) へのバックアップ {#backups-to-google-cloud-storage-gcs} + +GCSにバックアップするには、まず`gitlab.toolbox.backups.objectStorage.backend`を`gcs`に設定する必要があります。これにより、Toolboxはオブジェクトの保存と取得時に`gsutil` CLIを使用するようになります。 + +さらに、2つのバケットの場所を構成する必要があります。1つはバックアップを保存するため、もう1つはバックアップのリストア時に使用される一時バケットです。 + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +``` + +バックアップユーティリティは、これらのバケットへのアクセスを必要とします。アクセスを許可する方法は2つあります。 + +- Kubernetesシークレットで認証情報を指定します。 +- [GKEのワークロードアイデンティティフェデレーション](https://cloud.google.com/kubernetes-engine/docs/concepts/workload-identity)の設定。 + +#### GCS認証情報 {#gcs-credentials} + +まず、`gitlab.toolbox.backups.objectStorage.config.gcpProject`を、ストレージバケットを含むGCPプロジェクトのプロジェクトIDに設定します。 + +サービスアカウントにバックアップに使用するバケットの`storage.admin`ロールがあるアクティブなサービスアカウントJSONキーの内容を含むKubernetesシークレットを作成する必要があります。以下は、`gcloud`と`kubectl`を使用してシークレットを作成する例です。 + +```shell +export PROJECT_ID=$(gcloud config get-value project) +gcloud iam service-accounts create gitlab-gcs --display-name "Gitlab Cloud Storage" +gcloud projects add-iam-policy-binding --role roles/storage.admin ${PROJECT_ID} --member=serviceAccount:gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com +gcloud iam service-accounts keys create --iam-account gitlab-gcs@${PROJECT_ID}.iam.gserviceaccount.com storage.config +kubectl create secret generic storage-config --from-file=config=storage.config +``` + +サービスアカウントキーを使用してバックアップのためにGCSに対して認証するには、次のようにHelmチャートを構成します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set gitlab.toolbox.backups.objectStorage.config.secret=storage-config \ + --set gitlab.toolbox.backups.objectStorage.config.key=config \ + --set gitlab.toolbox.backups.objectStorage.config.gcpProject=my-gcp-project-id \ + --set gitlab.toolbox.backups.objectStorage.backend=gcs +``` + +#### GKEのワークロードアイデンティティフェデレーションの設定 {#configuring-workload-identity-federation-for-gke} + +[GitLabチャートを使用したGKEのワークロードアイデンティティフェデレーションに関するドキュメント](../advanced/external-object-storage/gke-workload-identity.md)を参照してください。 + +Kubernetes ServiceAccountを参照するIAM許可ポリシーを作成する場合は、`roles/storage.objectAdmin`ロールを付与します。 + +バックアップの場合、`gitlab.toolbox.backups.objectStorage.config.secret`、`gitlab.toolbox.backups.objectStorage.config.key`、および`gitlab.toolbox.backups.objectStorage.config.gcpProject`が設定されていないことを確認して、Googleのアプリケーションのデフォルト認証情報が使用されるようにします。 + +### Azure blobストレージへのバックアップ {#backups-to-azure-blob-storage} + +`gitlab.toolbox.backups.objectStorage.backend`を`azure`に設定することで、Azure blobストレージをバックアップの保存に使用できます。これにより、Toolboxは含まれている`azcopy`のコピーを使用して、バックアップファイルをAzure blobストレージに送信および取得できます。 + +Azure blobストレージを使用するには、既存のリソースグループにストレージアカウントを作成する必要があります。ストレージアカウントの名前、アクセスキー、およびblobホストを使用して設定シークレットを作成します。 + +パラメータを含む設定ファイルを作成します。 + +```yaml +# azure-backup-conf.yaml +azure_storage_account_name: +azure_storage_access_key: +azure_storage_domain: blob.core.windows.net # optional +``` + +次の`kubectl`コマンドを使用して、Kubernetesシークレットを作成できます。 + +```shell +kubectl create secret generic backup-azure-creds \ + --from-file=config=azure-backup-conf.yaml +``` + +シークレットが作成されると、デプロイされた値にバックアップ設定を追加するか、Helmコマンドラインで設定を提供することにより、GitLab Helmチャートを構成できます。次に例を示します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set gitlab.toolbox.backups.objectStorage.config.secret=backup-azure-creds \ + --set gitlab.toolbox.backups.objectStorage.config.key=config \ + --set gitlab.toolbox.backups.objectStorage.backend=azure +``` + +シークレットからのアクセスキーは、ストレージアカウントにアクセスするためにより短寿命の共有アクセス署名（SAS）トークンを生成および更新するために使用されます。 + +さらに、2つのバケット/コンテナを事前に作成する必要があります。1つはバックアップを保存するため、もう1つはバックアップのリストア時に使用される一時バケットです。バケット名を値または設定に追加します。次に例を示します。 + +```shell +--set global.appConfig.backups.bucket=gitlab-backup-storage +--set global.appConfig.backups.tmpBucket=gitlab-tmp-storage +``` + +## トラブルシューティング {#troubleshooting} + +### ポッドの削除に関するイシュー {#pod-eviction-issues} + +バックアップはオブジェクトストレージターゲットの外部でローカルに組み立てられるため、一時的なディスク容量が必要です。必要な領域は、実際のバックアップアーカイブのサイズを超える可能性があります。デフォルト設定では、Toolboxポッドのファイルシステムを使用して一時データを保存します。リソース不足が原因でポッドが削除されている場合は、一時データを保持するために永続ボリュームをポッドに接続する必要があります。GKEで、次の設定をHelmコマンドに追加します。 + +```shell +--set gitlab.toolbox.persistence.enabled=true +``` + +バックアップが付属のバックアップcronジョブの一部として実行されている場合は、cronジョブの永続性を有効にすることをお勧めします。 + +```shell +--set gitlab.toolbox.backups.cron.persistence.enabled=true +``` + +他のプロバイダーの場合は、永続ボリュームを作成する必要があるかもしれません。これを行う方法の例については、[ストレージに関するドキュメント](../installation/storage.md)を参照してください。 + +### 「バケットが見つかりません」エラー {#bucket-not-found-errors} + +バックアップ中に`Bucket not found`エラーが表示される場合は、バケットに対して認証情報が構成されていることを確認してください。 + +コマンドはクラウドサービスプロバイダーによって異なります。 + +- AWS S3の場合、認証情報はツールボックスポッドの`~/.s3cfg`に保存されます。実行: + + ```shell + s3cmd ls + ``` + +- GCP GCSの場合は、次を実行します。 + + ```shell + gsutil ls + ``` + +利用可能なバケットのリストが表示されます。 + +### 「AccessDeniedException:GCPの403」エラー {#accessdeniedexception-403-errors-in-gcp} + +`[Error] AccessDeniedException: 403 does not have storage.objects.list access to the Google Cloud Storage bucket.`のようなエラーは、権限がないために、GitLabインスタンスのバックアップまたはリストア中に通常発生します。 + +バックアップおよびリストアオペレーションは環境内のすべてのバケットを使用するため、環境内のすべてのバケットが作成されていること、およびGCPアカウントがすべてのバケットにアクセス（リスト、読み取り、および書き込み）できることを確認してください。 + +1. ツールボックスポッドを見つけます。 + + ```shell + kubectl get pods -lrelease=RELEASE_NAME,app=toolbox + ``` + +1. ポッドの環境内のすべてのバケットを取得します。``を実際のツールボックスポッド名に置き換えますが、`"BUCKET_NAME"`はそのままにします。 + + ```shell + kubectl describe pod | grep "BUCKET_NAME" + ``` + +1. 環境内のすべてのバケットへのアクセス権があることを確認します。 + + ```shell + # List + gsutil ls gs:/// + + # Read + gsutil cp gs:/// + + # Write + gsutil cp -n gs:/// + ``` + +### 「エラー：`/home/git/.s3cfg`:`--backend s3`で`backup-utility`を実行した場合のNone」エラー {#error-homegits3cfg-none-error-when-running-backup-utility-with---backend-s3} + +このエラーは、`.s3cfg`ファイルを含むKubernetesシークレットが`gitlab.toolbox.backups.objectStorage.config.secret`値を介して指定されていない場合に発生します。 + +この問題を解決するには、[S3へのバックアップ](_index.md#backups-to-s3)の手順に従ってください。 + +### 「PermissionError:S3を使用したファイル書き込み不可」エラー {#permissionerror-file-not-writable-errors-using-s3} + +ツールボックスユーザーがバケットアイテムの保存されている権限と一致するファイルを書き込む権限を持っていない場合、`[Error] WARNING: not writable: Operation not permitted`のようなエラーが発生します。 + +これを防ぐには、`gitlab.toolbox.backups.objectStorage.config.secret`を介して参照される`.s3cfg`ファイルに次のフラグを追加して、ファイル所有者、モード、およびタイムスタンプを保持しないように`s3cmd`を構成します。 + +```toml +preserve_attrs = False +``` + +### リストア時にスキップされたリポジトリ {#repositories-skipped-on-restore} + +GitLab 16.6/Chart 7.6以降では、バックアップアーカイブの名前が変更された場合、リストア時にリポジトリがスキップされることがあります。これを回避するには、バックアップアーカイブの名前を変更せず、バックアップを元の名前（`{backup_id}_gitlab_backup.tar`）に変更します。 + +元のバックアップIDは、リポジトリバックアップディレクトリ構造から抽出できます：`repositories/@hashed/*/*/*/{backup_id}/LATEST` diff --git a/doc-locale/ja-jp/backup-restore/backup.md b/doc-locale/ja-jp/backup-restore/backup.md new file mode 100644 index 0000000000..be06932470 --- /dev/null +++ b/doc-locale/ja-jp/backup-restore/backup.md @@ -0,0 +1,174 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabインストールのバックアップ +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabのバックアップは、チャートで提供されているToolboxポッドで`backup-utility`コマンドを実行することで行われます。このチャートの[Cronベースのバックアップ](#cron-based-backup)機能を有効にすることで、バックアップを自動化することもできます。 + +初めてバックアップを実行する前に、[オブジェクトストレージ](_index.md#object-storage)にアクセスするために[Toolboxが適切に設定](../charts/gitlab/toolbox/_index.md#configuration)されていることを確認する必要があります。 + +GitLab Helmチャートベースのインストールをバックアップするには、次の手順に従います。 + +## バックアップを作成する {#create-the-backup} + +1. 次のコマンドを実行して、Toolboxポッドが実行されていることを確認します + + ```shell + kubectl get pods -lrelease=,app=toolbox + ``` + + ``をHelmリリース名（通常は`gitlab`）に置き換えます。 + +1. バックアップユーティリティを実行します + + ```shell + kubectl exec -it -- backup-utility + ``` + +1. オブジェクトストレージサービスの`gitlab-backups`バケットにアクセスし、tarボールが追加されていることを確認します。`_gitlab_backup.tar`の形式で名前が付けられます。[バックアップID](https://docs.gitlab.com/administration/backup_restore/backup_archive_process/#backup-id)の詳細をお読みください。 + +1. このtarボールは、リストアに必要です。 + +## Cronベースのバックアップ {#cron-based-backup} + +{{< alert type="note" >}} + +Helm Chartによって作成されたKubernetes CronJobは、jobTemplateに`cluster-autoscaler.kubernetes.io/safe-to-evict: "false"`アノテーションを設定します。GKE Autopilotなどの一部のKubernetes環境では、このアノテーションの設定が許可されておらず、バックアップ用のジョブポッドは作成されません。このアノテーションは、`gitlab.toolbox.backups.cron.safeToEvict`パラメータを`true`に設定することで変更できます。これにより、ジョブの作成は許可されますが、削除されてバックアップが破損するリスクがあります。 + +{{< /alert >}} + +このチャートでCronベースのバックアップを有効にして、[Kubernetesスケジュール](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule)で定義されているように定期的に実行できます。 + +次のパラメータを設定する必要があります。 + +- `gitlab.toolbox.backups.cron.enabled`:Cronベースのバックアップを有効にするには、trueに設定します +- `gitlab.toolbox.backups.cron.schedule`:Kubernetesスケジュールのドキュメントに従って設定します +- `gitlab.toolbox.backups.cron.extraArgs`:[backup-utility](https://gitlab.com/gitlab-org/build/CNG/blob/master/gitlab-toolbox/scripts/bin/backup-utility)の追加の引数をオプションで設定します（`--skip db`や`--s3tool awscli`など）。 + +## バックアップユーティリティの追加引数 {#backup-utility-extra-arguments} + +バックアップユーティリティは、いくつかの追加の引数を受け取ることができます。 + +### コンポーネントのスキップ {#skipping-components} + +`--skip`引数を使用して、コンポーネントをスキップします。有効なコンポーネント名は、[バックアップから特定のデータを除外する](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/#excluding-specific-data-from-the-backup)にあります。 + +各コンポーネントには、独自の`--skip`引数が必要です。次に例を示します。 + +```shell +kubectl exec -it -- backup-utility --skip db --skip lfs +``` + +### バックアップのみをクリーンアップする {#cleanup-backups-only} + +新しいバックアップを作成せずに、バックアップのクリーンアップを実行します。 + +```shell +kubectl exec -it -- backup-utility --cleanup +``` + +### 使用するS3ツールを指定する {#specify-s3-tool-to-use} + +`backup-utility`コマンドは、デフォルトで`s3cmd`を使用してオブジェクトストレージに接続します。`s3cmd`が他のS3ツールよりも信頼性が低い場合に、この追加の引数をオーバーライドすることがあります。 + +GitLabがS3バケットをCIジョブアーティファクトストレージとして使用し、デフォルトの`s3cmd` CLIツールが使用されている場合、バックアップジョブが`ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist.`でクラッシュする[既知の問題](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3338)があります。`s3cmd`から`awscli`に切り替えることで、バックアップジョブを正常に実行できます。詳細については、[issue 3338](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3338)を参照してください。 + +使用するS3 CLIツールは、`s3cmd`または`awscli`のいずれかです。 + + ```shell + kubectl exec -it -- backup-utility --s3tool awscli + ``` + +#### awscliでのMinIOの使用 {#using-minio-with-awscli} + +`awscli`を使用するときにMinIOをオブジェクトストレージとして使用するには、次のパラメータを設定します。 + +```yaml +gitlab: + toolbox: + extraEnvFrom: + AWS_ACCESS_KEY_ID: + secretKeyRef: + name: + key: accesskey + AWS_SECRET_ACCESS_KEY: + secretKeyRef: + name: + key: secretkey + extraEnv: + AWS_DEFAULT_REGION: us-east-1 # MinIO default + backups: + cron: + enabled: true + schedule: "@daily" + extraArgs: "--s3tool awscli --aws-s3-endpoint-url " +``` + +{{< alert type="note" >}} + +S3 CLIツール`s5cmd`のサポートは調査中です。進捗状況を追跡するには、[issue 523](https://gitlab.com/gitlab-org/build/CNG/-/issues/523)を参照してください。 + +{{< /alert >}} + +#### `awscli`によるデータ整合性保護 {#data-integrity-protection-with-awscli} + +Toolboxに含まれる最新バージョンの`awscli`ツールは、デフォルトでデータ整合性保護を適用します。オブジェクトストレージサービスがこの機能をサポートしていない場合、この要件は次のように無効にできます。 + +```yaml +extraEnv: + AWS_REQUEST_CHECKSUM_CALCULATION: WHEN_REQUIRED +``` + +設定は、Toolboxポッド`extraEnv`またはグローバル`extraEnv`のいずれかになります。 + +### サーバーサイドリポジトリのバックアップ {#server-side-repository-backups} + +{{< history >}} + +- GitLab 17.0で[導入](https://gitlab.com/gitlab-org/gitlab/-/issues/438393)。 + +{{< /history >}} + +バックアップアーカイブに大きなリポジトリバックアップを格納する代わりに、各リポジトリをホストするGitalyノードがバックアップの作成とそのオブジェクトストレージへのストリーミングを担当するように、リポジトリバックアップを設定できます。これにより、バックアップの作成とリストアに必要なネットワークリソースを削減できます。 + +[サーバーサイドリポジトリバックアップの作成](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/#create-server-side-repository-backups)を参照してください。 + +### その他の引数 {#other-arguments} + +利用可能な引数の完全なリストを表示するには、次のコマンドを実行します。 + +```shell +kubectl exec -it -- backup-utility --help +``` + +## シークレットのバックアップ {#back-up-the-secrets} + +セキュリティ上の予防措置として、レールシークレットのコピーを保存する必要もあります。これらはバックアップには含まれていません。データベースを含む完全なバックアップを、シークレットのコピーとは別に保管することをお勧めします。 + +1. レールシークレットのオブジェクト名を見つけます + + ```shell + kubectl get secrets | grep rails-secret + ``` + +1. レールシークレットのコピーを保存します + + ```shell + kubectl get secrets -o jsonpath="{.data['secrets\.yml']}" | base64 --decode > gitlab-secrets.yaml + ``` + +1. `gitlab-secrets.yaml`を安全な場所に保管してください。バックアップを復元するには、これが必要です。 + +## 追加情報 {#additional-information} + +- [GitLabチャートのバックアップ/リストアの概要](_index.md) +- [GitLabインストールの復元](restore.md) diff --git a/doc-locale/ja-jp/backup-restore/restore.md b/doc-locale/ja-jp/backup-restore/restore.md new file mode 100644 index 0000000000..3a5b47305a --- /dev/null +++ b/doc-locale/ja-jp/backup-restore/restore.md @@ -0,0 +1,205 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabインスタンスの復元 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +LinuxパッケージやGitLab Helmチャートなどの他のインストール方法を使用した既存のGitLabインスタンスのバックアップtarballを取得するには、[ドキュメントに記載されている](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/)手順に従ってください。 + +別のインスタンスから取得したバックアップを復元する場合は、バックアップを実行する前に、既存のインスタンスをオブジェクトストレージを使用するように移行する必要があります。[イシュー646](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/646)を参照してください。 + +バックアップは、作成されたGitLabの同じバージョンに復元することをお勧めします。 + +GitLabのバックアップの復元は、チャートで提供されているToolboxポッドで`backup-utility`コマンドを実行することで行われます。 + +初めて復元を実行する前に、[オブジェクトストレージ](_index.md)へのアクセスに対して[Toolboxが適切に設定されている](_index.md#object-storage)ことを確認する必要があります + +GitLab Helmチャートで提供されるバックアップユーティリティは、次のいずれかの場所からのtarballの復元をサポートしています + +1. インスタンスに関連付けられたオブジェクトストレージサービス内の`gitlab-backups`バケット。これはデフォルトのシナリオです。 +1. ポッドからアクセスできるパブリックURL。 +1. `kubectl cp`を使用してToolboxポッドにコピーできるローカルファイル + +## シークレットの復元 {#restoring-the-secrets} + +### railsシークレットの復元 {#restore-the-rails-secrets} + +{{}} + +[GitLab Environment Toolkit (GET)](https://docs.gitlab.com/install/install_methods/#gitlab-environment-toolkit-get)を使用してデプロイされたハイブリッド環境は、復元を実行する際に考慮する必要がある、OmnibusノードとKubernetes間の自動シークレット同期を実行します。詳細については、GETドキュメントの[こちらのセクション](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_post_considerations.md#restores)を参照してください。 + +{{}} + +GitLabチャートは、railsシークレットがYAMLコンテンツを含むKubernetes Secretとして提供されることを想定しています。Linuxパッケージインスタンスからrailsシークレットを復元する場合、シークレットは`/etc/gitlab/gitlab-secrets.json`ファイルにJSON形式で保存されます。ファイルを変換し、シークレットをYAML形式で作成するには: + +1. ファイル`/etc/gitlab/gitlab-secrets.json`を、`kubectl`コマンドを実行するワークステーションにコピーします。 + +1. ワークステーションに[yq](https://github.com/mikefarah/yq)ツール（バージョン4.21.1以降）をインストールします。 + +1. 次のコマンドを実行して、`gitlab-secrets.json`をYAML形式に変換します: + + ```shell + yq -P '{"production": .gitlab_rails}' gitlab-secrets.json -o yaml >> gitlab-secrets.yaml + ``` + +1. 新しい`gitlab-secrets.yaml`ファイルに次の内容が含まれていることを確認してください: + + ```YAML + production: + db_key_base: + secret_key_base: + otp_key_base: + openid_connect_signing_key: + active_record_encryption_primary_key: + - 'your active record encryption primary key' + active_record_encryption_deterministic_key: + - 'your active record encryption deterministic key' + active_record_encryption_key_derivation_salt: 'your active record key derivation salt' + ``` + +YAMLファイルからrailsシークレットを復元するには: + +1. railsシークレットのオブジェクト名を検索します: + + ```shell + kubectl get secrets | grep rails-secret + ``` + +1. 既存のシークレットを削除します: + + ```shell + kubectl delete secret + ``` + +1. 古いシークレットと同じ名前を使用して新しいシークレットを作成し、ローカルYAMLファイルを渡します + + ```shell + kubectl create secret generic --from-file=secrets.yml=gitlab-secrets.yaml + ``` + +### ポッドの再起動 {#restart-the-pods} + +新しいシークレットを使用するには、Webservice、Sidekiq、Toolboxの各ポッドを再起動する必要があります。これらのポッドを再起動する最も安全な方法は、次を実行することです: + +```shell +kubectl delete pods -lapp=sidekiq,release= +kubectl delete pods -lapp=webservice,release= +kubectl delete pods -lapp=toolbox,release= +``` + +## バックアップファイルの復元 {#restoring-the-backup-file} + +GitLabインスタンスを復元する手順は次のとおりです + +1. チャートをデプロイして、実行中のGitLabインスタンスがあることを確認します。次のコマンドを実行して、Toolboxポッドが有効になっていて実行されていることを確認します + + ```shell + kubectl get pods -lrelease=RELEASE_NAME,app=toolbox + ``` + +1. 上記のいずれかの場所でtarballを準備します。`_gitlab_backup.tar`形式で名前が付けられていることを確認してください。[バックアップID](https://docs.gitlab.com/administration/backup_restore/backup_archive_process/#backup-id)についてお読みください。 + +1. 後で再起動するために、データベースクライアントの現在のレプリカ数に注意してください: + + ```shell + kubectl get deploy -n -lapp=sidekiq,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' + kubectl get deploy -n -lapp=webservice,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' + kubectl get deploy -n -lapp=prometheus,release= -o jsonpath='{.items[].spec.replicas}{"\n"}' + ``` + +1. データベースのクライアントを停止して、ロックが復元プロセスを妨げないようにします: + + ```shell + kubectl scale deploy -lapp=sidekiq,release= -n --replicas=0 + kubectl scale deploy -lapp=webservice,release= -n --replicas=0 + kubectl scale deploy -lapp=prometheus,release= -n --replicas=0 + ``` + +1. バックアップユーティリティを実行してtarballを復元します + + ```shell + kubectl exec -it -- backup-utility --restore -t + ``` + + ここで、``は、`gitlab-backups`バケットに格納されているtarballの名前から取得されます。パブリックURLを提供する場合は、次のコマンドを使用します: + + ```shell + kubectl exec -it -- backup-utility --restore -f + ``` + + 形式が`file:///`である限り、ローカルパスをURLとして指定できます + +1. このプロセスには、tarballのサイズに応じて時間がかかります。 +1. 復元プロセスでは、データベースの既存のコンテンツが消去され、既存のリポジトリが一時的な場所に移動され、tarballのコンテンツが抽出されます。リポジトリはディスク上の対応する場所に移動され、アーティファクト、アップロード、LFSなどの他のデータは、オブジェクトストレージ内の対応するバケットにアップロードされます。 + +1. アプリケーションを再起動します: + + ```shell + kubectl scale deploy -lapp=sidekiq,release= -n --replicas= + kubectl scale deploy -lapp=webservice,release= -n --replicas= + kubectl scale deploy -lapp=prometheus,release= -n --replicas= + ``` + +{{< alert type="note" >}} + +復元中、バックアップtarballをディスクに展開する必要があります。これは、Toolboxポッドに必要なサイズのディスクを使用できる必要があることを意味します。詳細および設定については、[Toolboxドキュメント](../charts/gitlab/toolbox/_index.md#persistence-configuration)を参照してください。 + +{{< /alert >}} + +### runner登録トークンの復元 {#restore-the-runner-registration-token} + +復元後、正しい登録トークンがなくなったため、含まれているrunnerはインスタンスに登録できなくなります。更新するには、これらの[トラブルシューティングの手順](../troubleshooting/_index.md#included-gitlab-runner-failing-to-register)に従ってください。 + +## Kubernetes関連の設定の有効化 {#enable-kubernetes-related-settings} + +復元されたバックアップがチャートの既存のインストールからのものではない場合、復元後にいくつかのKubernetes固有の機能を有効にする必要もあります。[インクリメンタルCIジョブログの生成](https://docs.gitlab.com/administration/cicd/job_logs/#incremental-logging-architecture)など。 + +1. 次のコマンドを実行して、Toolboxポッドを見つけます + + ```shell + kubectl get pods -lrelease=RELEASE_NAME,app=toolbox + ``` + +1. インスタンス設定スクリプトを実行して、必要な機能を有効にします + + ```shell + kubectl exec -it -- gitlab-rails runner -e production /scripts/custom-instance-setup + ``` + +## ポッドの再起動 {#restart-the-pods-1} + +新しい変更を使用するには、WebserviceとSidekiqのポッドを再起動する必要があります。これらのポッドを再起動する最も安全な方法は、次を実行することです: + +```shell +kubectl delete pods -lapp=sidekiq,release= +kubectl delete pods -lapp=webservice,release= +``` + +## (オプション) rootユーザーのパスワードのリセット {#optional-reset-the-root-users-password} + +復元プロセスでは、バックアップの値で`gitlab-initial-root-password`シークレットは更新されません。`root`としてログインするには、バックアップに含まれている元のパスワードを使用します。パスワードにアクセスできなくなった場合は、次の手順に従ってリセットしてください。 + +1. コマンドを実行してWebserviceポッドにアタッチします + + ```shell + kubectl exec -it -- bash + ``` + +1. 次のコマンドを実行して、`root`ユーザーのパスワードをリセットします。`#{password}`を任意のパスワードに置き換えます + + ```shell + /srv/gitlab/bin/rails runner "user = User.first; user.password='#{password}'; user.password_confirmation='#{password}'; user.save!" + ``` + +## 追加情報 {#additional-information} + +- [GitLabチャートのバックアップ/復元入門](_index.md) +- [GitLabインストールのバックアップ](backup.md) diff --git a/doc-locale/ja-jp/charts/_index.md b/doc-locale/ja-jp/charts/_index.md new file mode 100644 index 0000000000..8e5992bd68 --- /dev/null +++ b/doc-locale/ja-jp/charts/_index.md @@ -0,0 +1,19 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャートを設定する +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 製品:GitLab Self-Managed + +{{< /details >}} + +GitLab Helmチャートは、複数の[サブチャート](gitlab/_index.md)で構成されています。 + +いずれかのチャートを設定するには、[グローバル](globals.md)を使用します。 + +[高度な設定](../advanced/_index.md)を実行することもできます。 diff --git a/doc-locale/ja-jp/charts/certmanager-issuer/_index.md b/doc-locale/ja-jp/charts/certmanager-issuer/_index.md new file mode 100644 index 0000000000..c22f254880 --- /dev/null +++ b/doc-locale/ja-jp/charts/certmanager-issuer/_index.md @@ -0,0 +1,61 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: CertManager Issuer作成のためのcertmanager-issuerの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +このチャートは、[JetstackのCertManager Helm Chart](https://cert-manager.io/docs/installation/helm/)のヘルパーです。GitLab IngressのTLS証明書をリクエストする際にCertManagerが使用するIssuerオブジェクトを自動的にプロビジョニングします。 + +## 設定 {#configuration} + +ここでは、設定の主要なセクションについて説明します。親チャートから設定する場合、これらの値は次のとおりです。 + +```yaml +certmanager-issuer: + # Configure an ACME Issuer in cert-manager. Only used if global.ingress.configureCertmanager is true. + server: https://acme-v02.api.letsencrypt.org/directory + + # Provide an email to associate with your TLS certificates + # email: + + rbac: + create: true + + resources: + requests: + cpu: 50m + + # Priority class assigned to pods + priorityClassName: "" + + common: + labels: {} +``` + +## インストールパラメータ {#installation-parameters} + +このには、`helm install`フラグを使用して`--set`コマンドに指定できるすべての可能な設定が含まれています。 + +| パラメータ | デフォルト | 説明 | +|-----------------------------------------------------|--------------------------------------------------|-------------| +| `server` | `https://acme-v02.api.letsencrypt.org/directory` | [ACME CertManager Issuer](https://cert-manager.io/docs/configuration/acme/)で使用するLet's Encryptサーバー。 | +| `email` | | TLS証明書に関連付けるを指定する必要があります。Let's Encryptはこのアドレスを使用して、期限切れの証明書、およびアカウントに関連するについて連絡します。 | +| `rbac.create` | `true` | `true`の場合、CertManager Issuerの操作を許可するために、関連のリソースを作成します。 | +| `resources.requests.cpu` | `50m` | Issuer作成のリクエストされたCPU。 | +| `common.labels` | | ServiceAccount、、ConfigMap、およびIssuerに適用する共通。 | +| `priorityClassName` | | [優先](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)クラスがにされます。 | +| `containerSecurityContext` | | Certmanagerの起動元の[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をする | +| `containerSecurityContext.runAsUser` | `65534` | の起動元のユーザーID | +| `containerSecurityContext.runAsGroup` | `65534` | の起動元のグループ | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | プロセスがプロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | を非ルートユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | の[Linux](https://man7.org/linux/man-pages/man7/capabilities.7.html)機能を削除します | +| `ttlSecondsAfterFinished` | `1800` | 完了したがカスケード削除の対象となるタイミングを制御します。 | diff --git a/doc-locale/ja-jp/charts/gitlab/_index.md b/doc-locale/ja-jp/charts/gitlab/_index.md new file mode 100644 index 0000000000..5a092d2bf3 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/_index.md @@ -0,0 +1,90 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmサブチャート +--- + +GitLab Helmチャートは複数のサブチャートで構成されており、コアのGitLabコンポーネントを提供します。 + +- [Gitaly](gitaly/_index.md) +- [GitLab Exporter](gitlab-exporter/_index.md) +- [GitLab Pages](gitlab-pages/_index.md) +- [GitLab Runner](gitlab-runner/_index.md) +- [GitLab Shell](gitlab-shell/_index.md) +- [GitLabエージェントサーバー (KAS)](kas/_index.md) +- [Mailroom](mailroom/_index.md) +- [移行](migrations/_index.md) +- [Praefect](praefect/_index.md) +- [Sidekiq](sidekiq/_index.md) +- [Spamcheck](spamcheck/_index.md) +- [Toolbox](toolbox/_index.md) +- [Webservice](webservice/_index.md) + +各サブチャートのパラメータは、`gitlab`キーの下にある必要があります。たとえば、GitLab Shellのパラメータは次のようになります。 + +```yaml +gitlab: + gitlab-shell: + ... +``` + +オプションのdependenciesには、これらのチャートを使用してください。 + +- [MinIO](../minio/_index.md) +- [NGINX](../nginx/_index.md) +- [HAProxy](../haproxy/_index.md) +- [PostgreSQL](https://artifacthub.io/packages/helm/bitnami/postgresql) +- [Redis](https://artifacthub.io/packages/helm/bitnami/redis) +- [レジストリ](../registry/_index.md) +- [Traefik](../traefik/_index.md) + +オプションの追加として、これらのチャートを使用します。 + +- [Prometheus](https://artifacthub.io/packages/helm/prometheus-community/prometheus) +- Kubernetes executorを使用する[_特権のない_](https://docs.gitlab.com/runner/install/kubernetes.html#running-docker-in-docker-containers-with-gitlab-runner) [GitLab Runner](https://docs.gitlab.com/runner/) +- [Let's Encrypt](https://letsencrypt.org/)から自動[プロビジョニング](https://cert-manager.io/docs/)された[SSL](https://venafi.com/jetstack-consult/)。[Jetstack](https://venafi.com/jetstack-consult/)の[cert-manager](https://cert-manager.io/docs/)と[certmanager-issuer](../certmanager-issuer/_index.md)を使用します + +## GitLab Helmサブチャートのオプションパラメータ {#gitlab-helm-subchart-optional-parameters} + +### affinity {#affinity} + +{{< history >}} + +- `webservice`および`sidekiq`を除くすべてのGitLab Helmサブチャートに対して、GitLab 17.3 (Charts 8.3) で[導入されました](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/3770)。 + +{{< /history >}} + +`affinity`は、すべてのGitLab Helmサブチャートのオプションパラメータです。設定すると、[グローバル`affinity`](../globals.md#affinity)値よりも優先されます。`affinity`の詳細については、[関連するKubernetesドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を参照してください。 + +{{< alert type="note" >}} + +`webservice`および`sidekiq` [Helm Chart](../globals.md#affinity)は、[グローバル`affinity`](../globals.md#affinity)値のみを使用できます。ローカル`affinity`が`webservice`および`sidekiq`に実装される時期については、[イシュー25403](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/25403)を参照してください。 + +{{< /alert >}} + +`affinity`を使用すると、次のいずれかまたは両方を設定できます。 + +- 次の`podAntiAffinity`ルール： + - `topology key`に対応する式に一致するポッドと同じドメインにポッドをスケジュールしません。 + - 2つのモードの`podAntiAffinity`ルールを設定します。必須 (`requiredDuringSchedulingIgnoredDuringExecution`) および優先 (`preferredDuringSchedulingIgnoredDuringExecution`)。`values.yaml`の`antiAffinity`変数を使用して、優先モードが適用されるように設定を`soft`に設定するか、必須モードが適用されるように`hard`に設定します。 +- 次の`nodeAffinity`ルール： + - 特定のゾーンに属するノードにポッドをスケジュールします。 + - 2つのモードの`nodeAffinity`ルールを設定します。必須 (`requiredDuringSchedulingIgnoredDuringExecution`) および優先 (`preferredDuringSchedulingIgnoredDuringExecution`)。`soft`に設定すると、優先モードが適用されます。`hard`に設定すると、必須モードが適用されます。このルールは、`registry` chart、`gitlab` chart、および`webservice`および`sidekiq`を除くすべてのサブchartに対してのみ実装されます。 + +`nodeAffinity`は、[`In`演算子](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators)のみを実装します。 + +次の例では、`affinity`を設定し、`nodeAffinity`と`antiAffinity`の両方を`hard`に設定します。 + +```yaml +nodeAffinity: "hard" +antiAffinity: "hard" +affinity: + nodeAffinity: + key: "test.com/zone" + values: + - us-east1-a + - us-east1-b + podAntiAffinity: + topologyKey: "test.com/hostname" +``` diff --git a/doc-locale/ja-jp/charts/gitlab/gitaly/_index.md b/doc-locale/ja-jp/charts/gitlab/gitaly/_index.md new file mode 100644 index 0000000000..3677a4d80a --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitaly/_index.md @@ -0,0 +1,480 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab-Gitalyチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`gitaly`サブチャートは、Gitalyサーバーの設定可能なデプロイメントを提供します。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスターから到達可能な外部サービスとして提供される、Workhorseサービスへのアクセスに依存します。 + +## 設計上の選択 {#design-choices} + +このチャートで使用されているGitalyコンテナには、まだGitalyに移植されていないGitリポジトリに対してアクションを実行するために、GitLab Shellのコードベースも含まれています。Gitalyコンテナには、GitLab Shellコンテナのコピーが含まれており、その結果、このチャート内でGitLab Shellも設定する必要があります。 + +## 構成 {#configuration} + +`gitaly`チャートは、[外部サービス](#external-services)と[チャート設定](#chart-settings)の2つの部分で構成されています。 + +Gitalyは、デフォルトでGitLabチャートをデプロイする際のコンポーネントとしてデプロイされます。Gitalyを個別にデプロイする場合は、`global.gitaly.enabled`を`false`に設定する必要があり、[外部Gitalyドキュメント](../../../advanced/external-gitaly/_index.md)に記載されているように追加の構成を実行する必要があります。 + +### インストールコマンドラインオプション {#installation-command-line-options} + +以下の表に、`--set`フラグを使用して`helm install`コマンドに指定できる、可能性のあるすべてのチャート構成を示します。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|---------------------------------------------------------|-------------| +| `annotations` | | Podアノテーション | +| `backup.goCloudUrl` | | [サーバー側のGitalyバックアップ](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)のオブジェクトストレージURL。 | +| `common.labels` | `{}` | このチャートによって作成されたすべてのオブジェクトに適用される補足ラベル。 | +| `podLabels` | | 補足的なPodラベル。セレクターには使用されません。 | +| `external[].hostname` | `- ""` | 外部ノードのホスト名 | +| `external[].name` | `- ""` | 外部ノードストレージの名前 | +| `external[].port` | `- ""` | 外部ノードのポート | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラルスタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `extraVolumeMounts` | | 実行する追加のボリュームマウントのリスト | +| `extraVolumes` | | 作成する追加のボリュームのリスト | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `gitaly.serviceName` | | 生成されたGitalyサービスの名前。`global.gitaly.serviceName`をオーバーライドし、デフォルトは`-gitaly` | +| `gpgSigning.enabled` | `false` | [Gitaly GPG署名](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)を使用するかどうか。 | +| `gpgSigning.secret` | | Gitaly GPG署名に使用されるシークレットの名前。 | +| `gpgSigning.key` | | GitalyのGPG署名キーを含むGPGシークレットのキー。 | +| `image.pullPolicy` | `Always` | Gitalyイメージのプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitaly` | Gitalyイメージリポジトリ | +| `image.tag` | `master` | Gitalyイメージタグ | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージタグ | +| `init.containerSecurityContext` | | initContainer固有の[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `internal.names[]` | `- default` | StatefulSetストレージの順序付けられた名前 | +| `serviceLabels` | `{}` | 補足サービスラベル | +| `service.externalPort` | `8075` | Gitalyサービスが公開するポート | +| `service.internalPort` | `8075` | Gitalyの内部ポート | +| `service.name` | `gitaly` | GitalyがServiceオブジェクトの背後にあるServiceポートの名前。 | +| `service.type` | `ClusterIP` | Gitalyサービスタイプ | +| `service.clusterIP` | `None` | Service作成リクエストの一部として、独自のクラスターIPアドレスを指定できます。これは、KubernetesのServiceオブジェクトのclusterIPと同じ規則に従います。`service.type`がLoadBalancerの場合、これは設定しないでください。 | +| `service.loadBalancerIP` | | 設定されていない場合は、一時的なIPアドレスが作成されます。これは、KubernetesのServiceオブジェクトのloadbalancerIP構成と同じ規則に従います。 | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをPodにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定しない場合、完全なチャート名が使用されます | +| `securityContext.fsGroup` | `1000` | Podを開始するグループID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要です） | +| `securityContext.runAsUser` | `1000` | Podを開始するユーザーID | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `shareProcessNamespace` | `false` | コンテナプロセスを同じPod内の他のすべてのコンテナに表示できるようにします | +| `containerSecurityContext` | | Gitalyコンテナが開始されるコンテナ[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | Gitalyコンテナが起動される特定のセキュリティコンテキストユーザーIDのオーバーライドを許可します | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | Gitalyコンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | Gitalyコンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `tolerations` | `[]` | Podの割り当ての容認ラベル | +| `affinity` | `{}` | Pod割り当ての[アフィニティルール](../_index.md#affinity) | +| `persistence.accessMode` | `ReadWriteOnce` | Gitaly永続性アクセスモード | +| `persistence.annotations` | | Gitaly永続性アノテーション | +| `persistence.enabled` | `true` | Gitaly永続性フラグを有効にする | +| `persistance.labels` | | Gitaly永続性ラベル | +| `persistence.matchExpressions` | | バインドするラベル式の一致 | +| `persistence.matchLabels` | | バインドするラベル値の一致 | +| `persistence.size` | `50Gi` | Gitaly永続ボリュームサイズ | +| `persistence.storageClass` | | プロビジョニングのstorageClassName | +| `persistence.subPath` | | Gitaly永続ボリュームのマウントパス | +| `priorityClassName` | | Gitaly StatefulSet priorityClassName | +| `logging.level` | | ログレベル | +| `logging.format` | `json` | ログ形式 | +| `logging.sentryDsn` | | Sentry DSN URL - Goサーバーからの例外 | +| `logging.sentryEnvironment` | | ログの生成に使用されるSentry環境 | +| `shell.concurrency[]` | | 各RPCエンドポイントの並行処理。構成キーについては、[RPC並行処理の制限](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/#limit-rpc-concurrency)と[RPC並行処理の適応性の有効化](https://docs.gitlab.com/administration/gitaly/concurrency_limiting/#enable-adaptiveness-for-rpc-concurrency)を参照してください。 | +| `packObjectsCache.enabled` | `false` | Gitaly pack-objectsキャッシュを有効にします | +| `packObjectsCache.dir` | `/home/git/repositories/+gitaly/PackObjectsCache` | キャッシュファイルが格納されるディレクトリ | +| `packObjectsCache.max_age` | `5m` | キャッシュエントリの有効期間 | +| `packObjectsCache.min_occurrences` | `1` | キャッシュエントリを作成するために必要な最小カウント | +| `git.catFileCacheSize` | | Git cat-fileプロセスで使用されるキャッシュサイズ | +| `git.config[]` | `[]` | GitalyがGitコマンドを起動するときに設定する必要があるGit設定 | +| `prometheus.grpcLatencyBuckets` | | Gitalyによって記録されるGRPCメソッド呼び出しのヒストグラムレイテンシーに対応するバケット。配列の文字列形式（たとえば、`"[1.0, 1.5, 2.0]"`）が入力として必要です | +| `statefulset.strategy` | `{}` | StatefulSetで使用される更新ストラテジーを構成できます | +| `statefulset.livenessProbe.initialDelaySeconds` | `0` | Livenessプローブが開始されるまでの遅延。startupProbeが有効になっている場合、これは0に設定されます。 | +| `statefulset.livenessProbe.periodSeconds` | `10` | Livenessプローブを実行する頻度 | +| `statefulset.livenessProbe.timeoutSeconds` | `3` | Livenessプローブがタイムアウトしたとき | +| `statefulset.livenessProbe.successThreshold` | `1` | 失敗後にlivenessプローブが成功したと見なされるための最小連続成功数 | +| `statefulset.livenessProbe.failureThreshold` | `3` | 成功後にlivenessプローブが失敗したと見なされるための最小連続失敗数 | +| `statefulset.readinessProbe.initialDelaySeconds` | `0` | Readinessプローブが開始されるまでの遅延。startupProbeが有効になっている場合、これは0に設定されます。 | +| `statefulset.readinessProbe.periodSeconds` | `5` | Readinessプローブを実行する頻度 | +| `statefulset.readinessProbe.timeoutSeconds` | `3` | Readinessプローブがタイムアウトしたとき | +| `statefulset.readinessProbe.successThreshold` | `1` | 失敗後にreadinessプローブが成功したと見なされるための最小連続成功数 | +| `statefulset.readinessProbe.failureThreshold` | `3` | 成功後にreadinessプローブが失敗したと見なされるための最小連続失敗数 | +| `statefulset.startupProbe.enabled` | `true` | スタートアッププローブを有効にするかどうか。 | +| `statefulset.startupProbe.initialDelaySeconds` | `1` | スタートアッププローブが開始されるまでの遅延 | +| `statefulset.startupProbe.periodSeconds` | `1` | スタートアッププローブを実行する頻度 | +| `statefulset.startupProbe.timeoutSeconds` | `1` | スタートアッププローブがタイムアウトしたとき | +| `statefulset.startupProbe.successThreshold` | `1` | 失敗後にスタートアッププローブが成功したと見なされるための最小連続成功数 | +| `statefulset.startupProbe.failureThreshold` | `60` | 成功後にスタートアッププローブが失敗したと見なされるための最小連続失敗数 | +| `metrics.enabled` | `false` | メトリクスのエンドポイントをスクレイピングに使用できるようにするかどうか | +| `metrics.port` | `9236` | メトリクスのエンドポイントポート | +| `metrics.path` | `/metrics` | メトリクスのエンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにするためにServiceMonitorを作成するかどうか。これを有効にすると、`prometheus.io`スクレイプアノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加のラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント構成 | +| `metrics.metricsPort` | | **非推奨** `metrics.port`を使用します | +| `gomemlimit.enabled` | `true` | この設定により、その制限も設定されている場合、Gitalyコンテナの`GOMEMLIMIT`環境変数が`resources.limits.memory`に自動的に設定されます。ユーザーは、この値をfalseに設定し、`extraEnv`で`GOMEMLIMIT`を設定することで、この値をオーバーライドできます。これは、[ドキュメント化された形式の基準](https://pkg.go.dev/runtime#hdr-Environment_Variables)を満たしている必要があります。 | +| `cgroups.enabled` | `false` | Gitalyには、組み込みのcgroups制御があります。構成すると、Gitalyはが動作しているリポジトリに基づいて、プロセスをcgroupに割り当てます。このパラメータは、リポジトリのcgroupを有効にします。有効にした場合、cgroups v2のみがサポートされることに注意してください。 | +| `cgroups.initContainer.image.repository` | `registry.com/gitlab-org/build/cng/gitaly-init-cgroups` | Gitalyイメージリポジトリ | +| `cgroups.initContainer.image.tag` | `master` | Gitalyイメージタグ | +| `cgroups.initContainer.image.pullPolicy` | `IfNotPresent` | Gitalyイメージのプルポリシー | +| `cgroups.mountpoint` | `/etc/gitlab-secrets/gitaly-pod-cgroup` | 親cgroupがマウントされている場所。 | +| `cgroups.hierarchyRoot` | `gitaly` | Gitalyがグループを作成する親cgroup。Gitalyが実行するユーザーとグループが所有することが想定されています。 | +| `cgroups.memoryBytes` | | Gitalyがするすべてのプロセスにまとめて課せられる合計メモリ制限。0は制限がないことを意味します。 | +| `cgroups.cpuShares` | | Gitalyがするすべてのプロセスにまとめて課せられるCPU制限。0は制限がないことを意味します。最大は1024シェアで、CPUの100％を表します。 | +| `cgroups.cpuQuotaUs` | | cgroupのプロセスがこのクォータ値を超えた場合に、cgroupのプロセスをスロットルするために使用されます。cpuQuotaUsを100msに設定して、1コアが100000になるようにします。0は制限がないことを意味します。 | +| `cgroups.repositories.count` | | cgroupsプール内のcgroupの数。新しいがされるたびに、Gitalyはが対象とするリポジトリに基づいて、これらのcgroupの1つに割り当てます。巡回ハッシュアルゴリズムは、これらのcgroupにを割り当てるため、リポジトリのは常に同じcgroupに割り当てられます。 | +| `cgroups.repositories.memoryBytes` | | リポジトリcgroupに含まれるすべてのプロセスに課せられる合計メモリ制限。0は制限がないことを意味します。この値は、最上位のmemoryBytesの値を超えることはできません。 | +| `cgroups.repositories.cpuShares` | | リポジトリcgroupに含まれるすべてのプロセスに課せられるCPU制限。0は制限がないことを意味します。最大は1024シェアで、CPUの100％を表します。この値は、最上位のcpuSharesの値を超えることはできません。 | +| `cgroups.repositories.cpuQuotaUs` | | リポジトリcgroupに含まれるすべてのプロセスに課せられるcpuQuotaUs。プロセスは、指定されたクォータを超えることはできません。cpuQuotaUsを100msに設定して、1コアが100000になるようにします。0は制限がないことを意味します。 | +| `cgroups.repositories.maxCgroupsPerRepo` | `1` | 特定のリポジトリを対象とするプロセスを分散できるリポジトリcgroupの数。これにより、バースト的なを許可しながら、リポジトリcgroupに対してより保守的なCPUおよびメモリ制限を構成できます。たとえば、`2`の`maxCgroupsPerRepo`と10GBの`memoryBytes`制限がある場合、特定のリポジトリに対する独立したオペレーションは最大20GBのメモリを消費する可能性があります。 | +| `gracefulRestartTimeout` | `25` | Gitalyシャットダウン猶予期間。インフライトが完了するまで待機する時間（秒）。Podの`terminationGracePeriodSeconds`は、この値+ 5秒に設定されます。 | +| `timeout.uploadPackNegotiation` | | [ネゴシエーションタイムアウトの構成](https://docs.gitlab.com/administration/settings/gitaly_timeouts/#configure-the-negotiation-timeouts)を参照してください。 | +| `timeout.uploadArchiveNegotiation` | | [ネゴシエーションタイムアウトの構成](https://docs.gitlab.com/administration/settings/gitaly_timeouts/#configure-the-negotiation-timeouts)を参照してください。 | +| `dailyMaintenance.disabled` | | 毎日のバックグラウンドメンテナンスを無効にすることができます。 | +| `dailyMaintenance.duration` | | 毎日のバックグラウンドメンテナンスの最大期間。たとえば、「1時間」または「45分」。 | +| `dailyMaintenance.startHour` | | 毎日のバックグラウンドメンテナンスの開始時間。 | +| `dailyMaintenance.startMinute` | | 毎日のバックグラウンドメンテナンスの開始時間。 | +| `dailyMaintenance.storages` | | 毎日のバックグラウンドメンテナンスを実行するストレージ名の配列。例：\[「default」]。 | +| `bundleUri.goCloudUrl` | | [バンドルURIドキュメント](https://docs.gitlab.com/administration/gitaly/bundle_uris/)を参照してください。 | + +## チャート構成の例 {#chart-configuration-examples} + +### extraEnv {#extraenv} + +`extraEnv`を使用すると、Pod内のすべてのコンテナで追加のを公開できます。 + +以下は、`extraEnv`の使用例です。 + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナが開始されると、が公開されていることを確認できます。 + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +### extraEnvFrom {#extraenvfrom} + +`extraEnvFrom`を使用すると、Pod内のすべてのコンテナで、他のデータソースからの追加のを公開できます。 + +以下は、`extraEnvFrom`の使用例です。 + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### image.pullSecrets {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートに対してして、Podのイメージをプルできます。 + +プライベートとその方法に関する追加の詳細は、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)にあります。 + +以下は、`pullSecrets`の使用例です + +```yaml +image: + repository: my.gitaly.repository + tag: latest + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをPodにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをPodにマウントするかどうかを制御します。特定のサイドカーが適切に機能するために（たとえば、Istio）、これを有効にする必要がない限り、有効にしないでください。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定しない場合、完全なチャート名が使用されます。 | + +### tolerations {#tolerations} + +`tolerations`を使用すると、taintされたノードでPodをスケジュールできます + +以下は、`tolerations`の使用例です。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### affinity {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +### annotations {#annotations} + +`annotations`を使用すると、Gitaly Podにアノテーションを追加できます。 + +以下は、`annotations`の使用例です。 + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +### priorityClassName {#priorityclassname} + +`priorityClassName`を使用すると、Gitaly Podに[PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)をできます。 + +以下は、`priorityClassName`の使用例です。 + +```yaml +priorityClassName: persistence-enabled +``` + +### `git.config` {#gitconfig} + +`git.config`を使用すると、Gitalyによってされたすべてのに構成を追加できます。`key` / `value`ペアで、`git-config(1)`に記載されている構成を受け入れます（以下を参照）。 + +```yaml +git: + config: + - key: "pack.threads" + value: 4 + - key: "fsck.missingSpaceBeforeDate" + value: ignore +``` + +### cgroups {#cgroups} + +リソースの枯渇を防ぐために、Gitalyは**cgroups**を使用して、動作中のに基づいてプロセスをcgroupにします。各cgroupには、メモリとCPUの制限があり、システムの安定性を確保し、リソースの飽和を防ぎます。 + +Gitalyの起動前に実行される`initContainer`は、**rootとして実行**する必要があることに注意してください。このコンテナは、Gitalyがcgroupを管理できるように、権限を設定します。したがって、`/sys/fs/cgroup`への書き込みアクセス権を持つために、ファイルシステムにボリュームをマウントします。 + +[過剰サブスクリプションの例](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configuring-oversubscription) + +```yaml +cgroups: + enabled: true + # Total limit across all repository cgroups + memoryBytes: 64424509440 # 60GiB + cpuShares: 1024 + cpuQuotaUs: 1200000 # 12 cores + # Per repository limits, 1000 repository cgroups + repositories: + count: 1000 + memoryBytes: 32212254720 # 30GiB + cpuShares: 512 + cpuQuotaUs: 400000 # 4 cores +``` + +## 外部サービス {#external-services} + +このチャートは、Workhorseサービスにアタッチする必要があります。 + +### Workhorse {#workhorse} + +```yaml +workhorse: + host: workhorse.example.com + serviceName: webservice + port: 8181 +``` + +| 名前 | 種類 | デフォルト | 説明 | +|:--------------|:-------:|:-------------|:------------| +| `host` | 文字列 | | Workhorseサーバーのホスト名。これは、`serviceName`の代わりに省略できます。 | +| `port` | 整数 | `8181` | Workhorseサーバーへの接続に使用するポート。 | +| `serviceName` | 文字列 | `webservice` | WorkhorseサーバーをOperateしている`service`の名前。これが存在し、`host`が存在しない場合、チャートは`host`値の代わりに、サービス（および現在の`.Release.Name`）のホスト名をテンプレート化します。これは、Workhorseを全体的なGitLabチャートの一部として使用する場合に便利です。 | + +## チャート設定 {#chart-settings} + +以下の値は、Gitalyポッドの設定に使用されます。 + +{{< alert type="note" >}} + +Gitalyは認証トークンを使用して、WorkhorseおよびSidekiqサービスで認証します。認証トークンのシークレットとキーは、`global.gitaly.authToken`値から取得されます。さらに、GitalyコンテナにはGitLab Shellのコピーがあり、設定できる設定がいくつかあります。Shellの認証トークンは、`global.shell.authToken`値から取得されます。 + +{{< /alert >}} + +### Gitリポジトリの永続化 {#git-repository-persistence} + +このチャートは、PersistentVolumeClaimをプロビジョニングし、Gitリポジトリ データに対応する永続ボリュームをマウントします。これが機能するには、Kubernetesクラスターで使用可能な物理ストレージが必要です。emptyDirを使用する場合は、`persistence.enabled: false`でPersistentVolumeClaimを無効にします。 + +{{< alert type="note" >}} + +Gitalyの永続性の設定は、すべてのGitalyポッドに対して有効であるvolumeClaimTemplateで使用されます。単一の特定のボリューム（`volumeName`など）を参照するための*設定*を含めないでください。特定のボリュームを参照する場合は、PersistentVolumeClaimを手動でCreateする必要があります。 + +{{< /alert >}} + +{{< alert type="note" >}} + +これらの設定は、デプロイ後に変更できません。[StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)では、`VolumeClaimTemplate`は不変です。{{< /alert >}} + +```yaml +persistence: + enabled: true + storageClass: standard + accessMode: ReadWriteOnce + size: 50Gi + matchLabels: {} + matchExpressions: [] + subPath: "data" + annotations: {} +``` + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------|:-------:|:----------------|:------------| +| `accessMode` | 文字列 | `ReadWriteOnce` | PersistentVolumeClaimでリクエストされたaccessModeを設定します。詳細については、[Kubernetes Access Modes Documentation](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes)を参照してください。 | +| `enabled` | ブール値 | `true` | リポジトリデータにPersistentVolumeClaimsを使用するかどうかを設定します。`false`の場合、emptyDirボリュームが使用されます。 | +| `matchExpressions` | 配列 | | バインドするボリュームを選択するときに照合するラベル条件オブジェクトの配列を受け入れます。これは、`PersistentVolumeClaim` `selector`セクションで使用されます。[ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector)のドキュメントを参照してください。 | +| `matchLabels` | マップ | | バインドするボリュームを選択するときに照合するラベル名とラベル値のマップを受け入れます。これは、`PersistentVolumeClaim` `selector`セクションで使用されます。[ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector)のドキュメントを参照してください。 | +| `size` | 文字列 | `50Gi` | データの永続化のためにリクエストする最小ボリュームサイズ。 | +| `storageClass` | 文字列 | | 動的プロビジョニングのために、ボリュームリクエストでstorageClassNameを設定します。設定解除されているかnullの場合、デフォルトのプロビジョニングツールが使用されます。ハイフンに設定すると、動的プロビジョニングが無効になります。 | +| `subPath` | 文字列 | | ボリュームルートではなく、マウントするボリューム内のパスを設定します。subPathが空の場合、ルートが使用されます。 | +| `annotations` | マップ | | 動的プロビジョニングのために、ボリュームリクエストでアノテーションを設定します。詳細については、[Kubernetes Annotations Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)を参照してください。 | + +### TLS {#running-gitaly-over-tls}経由でGitalyを実行する + +{{< alert type="note" >}} + +このセクションでは、Helm Chartを使用してクラスター内で実行されているGitalyについて説明します。外部Gitaly [インスタンス](../../../advanced/external-gitaly/_index.md#connecting-to-external-gitaly-over-tls)を使用しており、TLSを使用して通信する場合は、[外部Gitalyのドキュメント](../../../advanced/external-gitaly/_index.md#connecting-to-external-gitaly-over-tls)を参照してください + +{{< /alert >}} + +Gitalyは、TLS経由で他のコンポーネントと通信することをサポートしています。これは、`global.gitaly.tls.enabled`および`global.gitaly.tls.secretName`の設定によって制御されます。TLS経由でGitalyを実行するには、次の手順に従います。 + +1. Helm Chartは、TLS経由でGitalyと通信するために証明書が提供されることを想定しています。この証明書は、存在するすべてのGitalyノードに適用される必要があります。したがって、これらの各Gitalyノードのすべてのホスト名を、証明書にサブジェクト代替名（SAN）として追加する必要があります。 + + 使用するホスト名を知るには、Toolboxポッドの`/srv/gitlab/config/gitlab.yml`ファイルを確認し、その中の`repositories.storages`キーの下に指定されているさまざまな`gitaly_address`フィールドを確認します。 + + ```shell + kubectl exec -it -- grep gitaly_address /srv/gitlab/config/gitlab.yml + ``` + +{{< alert type="note" >}} + +内部Gitaly [ポッド](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh)用のカスタム署名付き[証明書](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh)を生成するための基本[スクリプト](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh)は、[このリポジトリにあります](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh)。ユーザーは、そのスクリプトを使用して、適切なSAN属性を持つ証明書を生成できます。 + +{{< /alert >}} + +1. 作成された証明書を使用して、K8s TLSシークレットをCreateします。 + + ```shell + kubectl create secret tls gitaly-server-tls --cert=gitaly.crt --key=gitaly.key + ``` + +1. `--set global.gitaly.tls.enabled=true`を渡すことにより、Helm Chartを再デプロイします。 + +### グローバルサーバーフック {#global-server-hooks} + +Gitaly StatefulSetは、[グローバルサーバーフック](https://docs.gitlab.com/administration/server_hooks/#create-a-global-server-hook-for-all-repositories)を[サポート](https://docs.gitlab.com/administration/server_hooks/#create-a-global-server-hook-for-all-repositories)しています。フックスクリプトはGitalyポッドで実行されるため、[Gitalyコンテナ](https://gitlab.com/gitlab-org/build/CNG/-/blob/master/gitaly/Dockerfile)で使用可能なツールに制限されます。 + +[フック](https://kubernetes.io/docs/concepts/configuration/configmap/)は、[ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/)を使用して[入力された](https://kubernetes.io/docs/concepts/configuration/configmap/)ものであり、必要に応じて次の値を設定することで使用できます。 + +1. `global.gitaly.hooks.preReceive.configmap` +1. `global.gitaly.hooks.postReceive.configmap` +1. `global.gitaly.hooks.update.configmap` + +ConfigMapに入力するには、`kubectl`にスクリプトディレクトリを指定します。 + +```shell +kubectl create configmap MAP_NAME --from-file /PATH/TO/SCRIPT/DIR +``` + +### GitLab {#gpg-signing-commits-created-by-gitlab}でCreateされたGPG署名コミット + +Gitalyは、GitLab [UI](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)（WebIDEなど）を[パス](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)して[Create](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)されたすべての[GPG](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)署名[コミット](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)、および[マージコミット](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)や[スカッシュ](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)など、GitLabで[Create](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)された[コミット](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)を[GPG](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits) [署名（する）](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-commit-signing-for-gitlab-ui-commits)できます。 + +1. GPGプライベートキーを使用して、k8sシークレットをCreateします。 + + ```shell + kubectl create secret generic gitaly-gpg-signing-key --from-file=signing_key=/path/to/gpg_signing_key.gpg + ``` + +1. `values.yaml`でGPG署名（する）を有効にします。 + + ```yaml + gitlab: + gitaly: + gpgSigning: + enabled: true + secret: gitaly-gpg-signing-key + key: signing_key + ``` + +### サーバーバックアップ {#server-side-backups} + +このチャートは、[Gitaly](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)サーバーサイド[バックアップ](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)を[サポート](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)しています。使用するには： + +1. バックアップを保存するバケットをCreateします。 +1. オブジェクトストアの認証情報とストレージURLをConfigureします。 + + ```yaml + gitlab: + gitaly: + extraEnvFrom: + # Mount the exisitign object store secret to the expected environment variables. + AWS_ACCESS_KEY_ID: + secretKeyRef: + name: + key: aws_access_key_id + AWS_SECRET_ACCESS_KEY: + secretKeyRef: + name: + key: aws_secret_access_key + backup: + # This is the connection string for Gitaly server side backups. + goCloudUrl: + ``` + + 予想される[環境変数](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)と[オブジェクト](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)ストレージ[バックエンド](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)のストレージURL形式については、[Gitaly](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#configure-server-side-backups)ドキュメントを参照してください。 + +1. [`backup-utility`でサーバーサイドバックアップを有効にする](../../../backup-restore/backup.md#server-side-repository-backups)。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-exporter/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-exporter/_index.md new file mode 100644 index 0000000000..862fb68e96 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-exporter/_index.md @@ -0,0 +1,189 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab-Exporterチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`gitlab-exporter`サブチャートは、GitLabアプリケーション固有のデータのPrometheusメトリクスを提供します。PostgreSQLと直接通信してクエリを実行し、CIビルド、プルミラーなどのデータを取得します。さらに、Sidekiqを使用してRedisと通信し、Sidekiqキューの状態に関するさまざまなメトリクス (ジョブ数など) を収集します。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして提供される、RedisおよびPostgreSQLサービスに依存しています。 + +## 設定 {#configuration} + +`gitlab-exporter`チャートは次のように設定されます。[グローバル設定](#global-settings)および[チャート設定](#chart-settings)。 + +## インストール コマンドライン オプション {#installation-command-line-options} + +以下の表に、`helm install`フラグを使用して`--set`コマンドに指定できる、すべての可能なチャート設定を示します。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|------------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | | ポッドアノテーション | +| `common.labels` | `{}` | このチャートによって作成されたすべてのオブジェクトに適用される追加のラベル。 | +| `podLabels` | | 補足的なポッドラベル。セレクターには使用されません。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される追加のラベル。 | +| `deployment.strategy` | `{}` | デプロイメントで使用される更新ストラテジを構成できます | +| `enabled` | `true` | GitLab Exporterが有効なフラグ | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラル スタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `extraVolumeMounts` | | 実行する追加のボリューム マウントのリスト | +| `extraVolumes` | | 作成する追加のボリュームのリスト | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `image.pullPolicy` | `IfNotPresent` | GitLabイメージプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-exporter` | GitLab Exporterイメージリポジトリ | +| `image.tag` | | イメージtag | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージtag | +| `init.containerSecurityContext` | | initContainer固有の[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナが非rootユーザーで実行されるかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `metrics.enabled` | `true` | メトリクス エンドポイントをスクレイピングに使用できるようにする必要がある場合 | +| `metrics.port` | `9168` | メトリクス エンドポイントポート | +| `metrics.path` | `/metrics` | メトリクス エンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにServiceMonitorを作成する必要がある場合、これを有効にすると`prometheus.io`スクレイピングアノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加のラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント設定 | +| `metrics.annotations` | | **非推奨**明示的なメトリクスアノテーションを設定します。テンプレートコンテンツに置き換えられました。 | +| `priorityClassName` | | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | +| `resources.requests.cpu` | `75m` | GitLab Exporterの最小CPU | +| `resources.requests.memory` | `100M` | GitLab Exporterの最小メモリ | +| `serviceLabels` | `{}` | 補足サービスラベル | +| `service.externalPort` | `9168` | GitLab Exporterの公開ポート | +| `service.internalPort` | `9168` | GitLab Exporterの内部ポート | +| `service.name` | `gitlab-exporter` | GitLab Exporterサービス名 | +| `service.type` | `ClusterIP` | GitLab Exporterサービスタイプ | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定しない場合、チャートのフルネームが使用されます | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23が必要) | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナを開始する[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナが開始される特定のセキュリティコンテキストユーザーの上書きを許可します | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `false` | コンテナが非rootユーザーで実行されるかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `tolerations` | `[]` | ポッド割り当ての容認ラベル | +| `psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`よりも優先されます | +| `tls.enabled` | `false` | GitLab Exporterが有効 | +| `tls.secretName` | `{Release.Name}-gitlab-exporter-tls` | GitLab Exporterシークレット。[Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を指す必要があります。 | + +## チャート設定の例 {#chart-configuration-examples} + +### extraEnv {#extraenv} + +`extraEnv`を使用すると、ポッド内のすべてのコンテナで追加の環境変数を公開できます。 + +`extraEnv`の使用例を以下に示します: + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナが起動すると、環境変数が公開されていることを確認できます: + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +### extraEnvFrom {#extraenvfrom} + +`extraEnvFrom`を使用すると、ポッド内のすべてのコンテナで他のデータソースからの追加の環境変数を公開できます。 + +`extraEnvFrom`の使用例を以下に示します: + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### image.pullSecrets {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに対して認証して、ポッドのイメージをプルできます。 + +プライベートレジストリとその認証方法の詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)を参照してください。 + +`pullSecrets`の使用例を以下に示します: + +```YAML +image: + repository: my.image.repository + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセス トークンをポッドにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これを有効にしないでください (たとえば、Istio)。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | ストリング | | ServiceAccountの名前。設定しない場合、チャートのフルネームが使用されます。 | + +### affinity {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +### annotations {#annotations} + +`annotations`を使用すると、GitLab Exporterポッドにアノテーションを追加できます。次に例を示します: + +```YAML +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +## グローバル設定 {#global-settings} + +チャート間でいくつかの共通グローバル設定を共有します。GitLabやレジストリのホスト名など、一般的な構成オプションについては、[グローバルドキュメント](../../globals.md)を参照してください。 + +## チャート設定 {#chart-settings} + +次の値は、GitLab Exporterポッドを構成するために使用されます。 + +### metrics.enabled {#metricsenabled} + +デフォルトでは、ポッドは`/metrics`でメトリクス エンドポイントを公開します。メトリクスが有効になっている場合、各ポッドにアノテーションが追加され、Prometheusサーバーが公開されたメトリクスを検出してスクレイピングできるようになります。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md new file mode 100644 index 0000000000..8c78a04d56 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md @@ -0,0 +1,443 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Pagesチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`gitlab-pages`サブチャートは、GitLabプロジェクトから静的ウェブサイトを提供するためのデーモンを提供します。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして提供される、Workhorseサービスへのアクセスに依存します。 + +## 設定 {#configuration} + +`gitlab-pages`チャートは次のように構成されています:[グローバル設定](#global-settings)および[チャート設定](#chart-settings)。 + +## グローバル設定 {#global-settings} + +いくつかの一般的なグローバル設定をチャート間で共有します。詳細については、[グローバルドキュメント](../../globals.md#configure-gitlab-pages)を参照してください。 + +## チャート設定 {#chart-settings} + +次の2つのセクションのテーブルには、`helm install`コマンドに`--set`フラグを使用して指定できる、可能なすべてのチャート設定が含まれています。 + +### 一般設定 {#general-settings} + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|---------------------------------------------------------|-------------| +| `affinity` | `{}` | Pod割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | | Podアノテーション | +| `common.labels` | `{}` | このチャートで作成されたすべてのオブジェクトに適用される追加のラベル。 | +| `deployment.strategy` | `{}` | デプロイで使用される更新戦略を構成できます。指定しない場合、クラスターのデフォルトが使用されます。 | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、アップスケーリングとダウンスケーリングの動作の`autoscaling/v2beta2`以上が必要です。 | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、必要なレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`で設定された平均CPU使用率のデフォルトの使用をオーバーライドします）。 | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | `100m` | オートスケールCPUターゲットを設定します | +| `hpa.cpu.targetAverageUtilization` | | オートスケールCPUターゲット使用率を設定します | +| `hpa.memory.targetType` | | オートスケールメモリーターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリーターゲットを設定します | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリーターゲット使用率を設定します | +| `hpa.minReplicas` | `1` | レプリカの最小数 | +| `hpa.maxReplicas` | `10` | レプリカの最大数 | +| `hpa.targetAverageValue` | | **非推奨**オートスケールCPUターゲットを設定します | +| `image.pullPolicy` | `IfNotPresent` | GitLabイメージプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-pages` | GitLab Pagesイメージリポジトリ | +| `image.tag` | | イメージtag | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージtag | +| `init.containerSecurityContext` | | initContainer固有の[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | リソースを0にスケールバックする前に、最後のトリガーがアクティブと報告されてから待機する期間 | +| `keda.minReplicaCount` | `hpa.minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `keda.maxReplicaCount` | `hpa.maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `keda.fallback` | | KEDAフォールバック構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | アップスケーリングとダウンスケーリングの動作の。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。デフォルトは`hpa.cpu`および`hpa.memory`から計算されたトリガーです | +| `metrics.enabled` | `true` | メトリクスエンドポイントをスクレイピングに使用できるようにするかどうか | +| `metrics.port` | `9235` | メトリクスエンドポイントポート | +| `metrics.path` | `/metrics` | メトリクスエンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにServiceMonitorを作成するかどうか。これを有効にすると、`prometheus.io`スクレイプアノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加のラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント構成 | +| `metrics.annotations` | | **非推奨**明示的なメトリクスアノテーションを設定します。テンプレートコンテンツに置き換えられました。 | +| `metrics.tls.enabled` | `false` | メトリクスエンドポイントに対してTLSが有効 | +| `metrics.tls.secretName` | `{Release.Name}-pages-metrics-tls` | メトリクスエンドポイントTLS証明書とキーのシークレット | +| `priorityClassName` | | Podに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | +| `podLabels` | | 補足Podラベル。セレクターには使用されません。 | +| `resources.requests.cpu` | `900m` | GitLab Pagesの最小CPU | +| `resources.requests.memory` | `2G` | GitLab Pagesの最小メモリ | +| `securityContext.fsGroup` | `1000` | Podを開始するグループID | +| `securityContext.runAsUser` | `1000` | Podを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要） | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナが開始される[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナが開始される特定のセキュリティコンテキストユーザーIDの上書きを許可 | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `service.externalPort` | `8090` | GitLab Pagesの公開ポート | +| `service.internalPort` | `8090` | GitLab Pagesの内部ポート | +| `service.name` | `gitlab-pages` | GitLab Pagesサービス名 | +| `service.annotations` | | すべてのPagesサービスのアノテーション。 | +| `service.primary.annotations` | | プライマリサービスのみのアノテーション。 | +| `service.metrics.annotations` | | メトリクスサービスのみのアノテーション。 | +| `service.customDomains.annotations` | | カスタムドメインサービスのみのアノテーション。 | +| `service.customDomains.type` | `LoadBalancer` | カスタムドメインを処理するために作成されたサービスの種類 | +| `service.customDomains.internalHttpsPort` | `8091` | PagesデーモンがHTTPSリクエストをリッスンするポート | +| `service.customDomains.internalHttpsPort` | `8091` | PagesデーモンがHTTPSリクエストをリッスンするポート | +| `service.customDomains.nodePort.http` | | HTTP接続用に開かれるノードポート。`service.customDomains.type`が`NodePort`の場合にのみ有効 | +| `service.customDomains.nodePort.https` | | HTTPS接続用に開かれるノードポート。`service.customDomains.type`が`NodePort`の場合にのみ有効 | +| `service.sessionAffinity` | `None` | セッションアフィニティの種類。`ClientIP`または`None`のいずれかである必要があります（これはクラスター内から発信されるトラフィックに対してのみ意味があります） | +| `service.sessionAffinityConfig` | | セッションアフィニティ構成。`service.sessionAffinity` == `ClientIP`の場合、デフォルトのセッションスティッキー時間は3時間（`10800`）です | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定されていない場合、チャートのフルネームが使用されます | +| `serviceLabels` | `{}` | 補足サービスラベル | +| `tolerations` | `[]` | Pod割り当てのTolerationラベル | + +### Pages固有の設定 {#pages-specific-settings} + +| パラメータ | デフォルト | 説明 | +|-----------------------------|---------|-------------| +| `artifactsServerTimeout` | `10` | アーティファクトサーバーへのプロキシリクエストのタイムアウト（秒単位） | +| `artifactsServerUrl` | | アーティファクトリクエストをプロキシするAPI URI | +| `extraVolumeMounts` | | 追加する追加ボリュームマウントのリスト | +| `extraVolumes` | | 作成する追加ボリュームのリスト | +| `gitlabCache.cleanup` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabCache.expiry` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabCache.refresh` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabClientHttpTimeout` | | GitLab API HTTPクライアント接続タイムアウト（秒単位） | +| `gitlabClientJwtExpiry` | | JWTトークンの有効期限（秒単位） | +| `gitlabRetrieval.interval` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabRetrieval.retries` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabRetrieval.timeout` | int | 参照:[Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `gitlabServer` | | GitLabサーバーのFQDN | +| `headers` | `[]` | 各レスポンスでクライアントに送信される追加のHTTPヘッダーを指定します。複数のヘッダーを配列として指定できます。ヘッダーと値を1つの文字列として指定します（例：`['my-header: myvalue', 'my-other-header: my-other-value']`）。 | +| `insecureCiphers` | `false` | デフォルトの暗号スイートリストを使用します。3DESやRC4などの脆弱なスイートが含まれている可能性があります | +| `internalGitlabServer` | | APIリクエストに使用される内部GitLabサーバー | +| `logFormat` | `json` | ログ出力形式 | +| `logVerbose` | `false` | 冗長なログの生成 | +| `maxConnections` | | HTTP、HTTPS、またはプロキシリスナーへの同時接続数の制限 | +| `maxURILength` | | URIの長さを制限します。無制限の場合は0。 | +| `propagateCorrelationId` | | 受信リクエストヘッダー`X-Request-ID`から既存の相関IDを再利用します（存在する場合） | +| `redirectHttp` | `false` | HTTPからHTTPSにページをリダイレクト | +| `sentry.enabled` | `false` | Sentryレポートを有効にする | +| `sentry.dsn` | | Sentryクラッシュレポートの送信先アドレス | +| `sentry.environment` | | Sentryクラッシュレポートの環境 | +| `serverShutdowntimeout` | `30s` | GitLab Pagesサーバーのシャットダウンタイムアウト（秒単位） | +| `statusUri` | | ページのURLパス | +| `tls.minVersion` | | 最小SSL/TLSを指定します | +| `tls.maxVersion` | | 最大SSL/TLSを指定します | +| `useHTTPProxy` | `false` | GitLab Pagesがリバースプロキシの背後にある場合は、このオプションを使用します。 | +| `useProxyV2` | `false` | HTTPSリクエストでPROXYv2プロトコルを強制的に利用します。 | +| `zipCache.cleanup` | int | 参照:[Zip提供とキャッシュの構成](https://docs.gitlab.com/administration/pages/#zip-serving-and-cache-configuration) | +| `zipCache.expiration` | int | 参照:[Zip提供とキャッシュの構成](https://docs.gitlab.com/administration/pages/#zip-serving-and-cache-configuration) | +| `zipCache.refresh` | int | 参照:[Zip提供とキャッシュの構成](https://docs.gitlab.com/administration/pages/#zip-serving-and-cache-configuration) | +| `zipOpenTimeout` | int | 参照:[Zip提供とキャッシュの構成](https://docs.gitlab.com/administration/pages/#zip-serving-and-cache-configuration) | +| `zipHTTPClientTimeout` | int | 参照:[Zip提供とキャッシュの構成](https://docs.gitlab.com/administration/pages/#zip-serving-and-cache-configuration) | +| `rateLimitSourceIP` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits)。 | +| `rateLimitSourceIPBurst` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits) | +| `rateLimitDomain` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits)。 | +| `rateLimitDomainBurst` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits) | +| `rateLimitTLSSourceIP` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits)。 | +| `rateLimitTLSSourceIPBurst` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits) | +| `rateLimitTLSDomain` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits)。 | +| `rateLimitTLSDomainBurst` | | 参照:[GitLab Pagesのレート制限](https://docs.gitlab.com/administration/pages/#rate-limits) | +| `rateLimitSubnetsAllowList` | | 参照:[GitLab Pagesのレート制限](#rate-limits) | +| `serverReadTimeout` | `5s` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `serverReadHeaderTimeout` | `1s` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `serverWriteTimeout` | `5m` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `serverKeepAlive` | `15s` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `authTimeout` | `5s` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | +| `authCookieSessionTimeout` | `10m` | 参照:[GitLab Pagesグローバル設定](https://docs.gitlab.com/administration/pages/#global-settings) | + +### `ingress`の構成 {#configuring-the-ingress} + +このセクションでは、GitLab Pages Ingressを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------------------|:-------:|:--------|:------------| +| `apiVersion` | String | | `apiVersion`フィールドで使用する。 | +| `annotations` | String | | このフィールドは、[Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)の標準`annotations`と完全に一致します。 | +| `configureCertmanager` | Boolean | `false` | Ingressアノテーション`cert-manager.io/issuer`と`acme.cert-manager.io/http01-edit-in-place`を切り替えます。cert-managerを使用したGitLab PagesのTLS証明書の取得は、ワイルドカード証明書の取得には[DNS01ソルバー](https://cert-manager.io/docs/configuration/acme/dns01/)を備えたcert-manager Issuerが必要であり、このチャートによってデプロイされたIssuerは[HTTP01ソルバー](https://cert-manager.io/docs/configuration/acme/http01/)のみを提供するため、無効になっています。詳細については、[GitLab PagesのTLS要件](../../../installation/tls.md)を参照してください。 | +| `enabled` | Boolean | | サポートするサービスに対してIngressオブジェクトを作成するかどうかを制御する設定。設定しない場合、`global.ingress.enabled`設定が使用されます。 | +| `tls.enabled` | Boolean | | `false`に設定すると、PagesサブチャートのTLSが無効になります。これは主に、Ingressコントローラーの前にTLS終端プロキシがある場合など、`ingress-level`でTLS終端を使用できない場合に役立ちます。 | +| `tls.secretName` | String | | ページURIの有効な証明書とキーを含むKubernetes TLSシークレットの名前。設定しない場合、代わりに`global.ingress.tls.secretName`が使用されます。デフォルトでは設定されていません。 | + +## チャート構成の例 {#chart-configuration-examples} + +### extraVolumes {#extravolumes} + +`extraVolumes`を使用すると、追加ボリュームチャート全体を構成できます。 + +`extraVolumes`の使用例を以下に示します: + +```yaml +extraVolumes: | + - name: example-volume + persistentVolumeClaim: + claimName: example-pvc +``` + +### extraVolumeMounts {#extravolumemounts} + +`extraVolumeMounts`を使用すると、すべてのコンテナチャート全体で追加のvolumeMountを構成できます。 + +`extraVolumeMounts`の使用例を以下に示します: + +```yaml +extraVolumeMounts: | + - name: example-volume + mountPath: /etc/example +``` + +### `networkpolicy`の構成 {#configuring-the-networkpolicy} + +このセクションでは、[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を制御します。この構成はオプションであり、PodのエグレスとIngressを特定のエンドポイントに制限するために使用されます。 + +| 名前 | 種類 | デフォルト | 説明 | +|:------------------|:-------:|:--------|:------------| +| `enabled` | Boolean | `false` | この設定により、`NetworkPolicy`が有効になります | +| `ingress.enabled` | Boolean | `false` | `true`に設定すると、`Ingress`ネットワークポリシーがアクティブになります。これにより、ルールが指定されていない限り、すべてのIngress接続がブロックされます。 | +| `ingress.rules` | Array | `[]` | Ingressポリシーのルールについて詳しくは、および下記の例を参照してください | +| `egress.enabled` | Boolean | `false` | `true`に設定すると、`Egress`ネットワークポリシーがアクティブになります。これにより、ルールが指定されていない限り、すべてのエグレス接続がブロックされます。 | +| `egress.rules` | Array | `[]` | エグレスポリシーのルールについて詳しくは、および下記の例を参照してください | + +### ネットワークポリシーの例 {#example-network-policy} + +`gitlab-pages`サービスには、ポート80および443へのIngress接続と、デフォルトのWorkhorseポート8181へのさまざまなエグレス接続が必要です。この例では、次のネットワークポリシーを追加します。 + +- Ingressリクエストを許可: + - `nginx-ingress`ポッドからポート`8090`へ + - `prometheus`ポッドからポート`9235`へ +- エグレスリクエストを許可: + - ポート`53`上の`kube-dns`へ + - ポート`8181`上の`webservice`ポッドへ + - ポート`443`上のS3用のAWS VPCエンドポイントなどのエンドポイント`172.16.1.0/24`へ + +_提供されている例は一例にすぎず、完全ではない可能性があることに注意してください_ + +この例は、`kube-dns`がネームスペース`kube-system`に、`prometheus`がネームスペース`monitoring`に、`nginx-ingress`がネームスペース`nginx-ingress`にデプロイされたという前提に基づいています。 + +```yaml +networkpolicy: + enabled: true + ingress: + enabled: true + rules: + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: monitoring + podSelector: + matchLabels: + app: prometheus + component: server + release: gitlab + ports: + - port: 9235 + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: nginx-ingress + podSelector: + matchLabels: + app: nginx-ingress + component: controller + ports: + - port: 8090 + egress: + enabled: true + rules: + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + podSelector: + matchLabels: + k8s-app: kube-dns + ports: + - port: 53 + protocol: UDP + - to: + - ipBlock: + cidr: 172.16.1.0/24 + ports: + - port: 443 + - to: + - podSelector: + matchLabels: + app: webservice + ports: + - port: 8181 +``` + +### GitLab PagesへのTLSアクセス {#tls-access-to-gitlab-pages} + +GitLab Pagesの機能にTLSアクセスするには、以下を実行する必要があります。 + +1. この形式でGitLab Pagesドメインの専任のワイルドカード証明書を作成します: `*.pages.`。 + +1. Kubernetesでシークレットを作成します: + + ```shell + kubectl create secret tls tls-star-pages- --cert= --key= + ``` + +1. このシークレットを使用するようにGitLab Pagesを設定します: + + ```yaml + gitlab: + gitlab-pages: + ingress: + tls: + secretName: tls-star-pages- + ``` + +1. ロードバランサーを指す名前`*.pages.`でDNSプロバイダーにDNSエントリを作成します。 + +### ワイルドカードDNSなしのPagesドメイン {#pages-domain-without-wildcard-dns} + +{{< history >}} + +- [導入](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5570) [ベータ](https://docs.gitlab.com/policy/development_stages_support/#beta)版としてGitLab 17.2で +- GitLab 17.4で[一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/483365)。 + +{{< /history >}} + +{{< alert type="warning" >}} + +GitLab Pagesは、一度に1つのURLスキームのみをサポートします。ワイルドカードDNSを使用するか、ワイルドカードDNSなしで使用します。`namespaceInPath`を有効にすると、既存のGitLab PagesのWebサイトには、ワイルドカードDNSなしのドメインでのみアクセスできます。 + +{{< /alert >}} + +1. グローバルPages設定で`namespaceInPath`を有効にします。 + + ```yaml + global: + pages: + namespaceInPath: true + ``` + +1. ロードバランサーを指す名前`pages.`でDNSプロバイダーにDNSエントリを作成します。 + +#### ワイルドカードDNSなしのGitLab PagesドメインへのTLSアクセス {#tls-access-to-gitlab-pages-domain-without-wildcard-dns} + +1. この形式でGitLab Pagesドメインの証明書を作成します: `pages.`。 +1. Kubernetesでシークレットを作成します: + + ```shell + kubectl create secret tls tls-star-pages- --cert= --key= + ``` + +1. このシークレットを使用するようにGitLab Pagesを設定します: + + ```yaml + gitlab: + gitlab-pages: + ingress: + tls: + secretName: tls-star-pages- + ``` + +#### アクセス制御の設定 {#configure-access-control} + +1. グローバルPages設定で`accessControl`を有効にします。 + + ```yaml + global: + pages: + accessControl: true + ``` + +1. 任意。[TLSアクセス](#tls-access-to-gitlab-pages-domain-without-wildcard-dns)が[設定](#tls-access-to-gitlab-pages-domain-without-wildcard-dns)されている場合は、HTTPSプロトコルを使用するように、GitLab Pages [システムOAuthアプリケーション](https://docs.gitlab.com/integration/oauth_provider/#create-an-instance-wide-application)のリダイレクト[URI](#tls-access-to-gitlab-pages-domain-without-wildcard-dns)を更新します。 + +{{< alert type="warning" >}} + +GitLab PagesはOAuthアプリケーションを更新せず、デフォルトの`authRedirectUri`が`https://pages./projects/auth`に更新されます。プライベートPagesサイトにアクセス中に、「指定されたリダイレクトURIが無効です」というエラーが発生した場合は、GitLab Pages [システムOAuthアプリケーション](https://docs.gitlab.com/integration/oauth_provider/#create-an-instance-wide-application)のリダイレクトURIを`https://pages./projects/auth`に更新します。 + +{{< /alert >}} + +### レート制限 {#rate-limits} + +サービス拒否（DoS）攻撃のリスクを最小限に抑えるために、レート制限を適用できます。詳細な[レート制限](https://docs.gitlab.com/administration/pages/#rate-limits)ドキュメントが利用可能です。 + +特定のIP範囲（サブネット）がすべてのレート制限を回避するのを許可するには: + +- `rateLimitSubnetsAllowList`:すべてのレート制限をバイパスする必要があるIP範囲（サブネット）で許可リストを設定します。 + +#### レート制限サブネット許可リストの設定 {#configure-rate-limits-subnets-allow-list} + +`charts/gitlab/charts/gitlab-pages/values.yaml`でIP範囲（サブネット）を使用して、許可リストを設定します: + +```yaml +gitlab: + gitlab-pages: + rateLimitSubnetsAllowList: + - "1.2.3.4/24" + - "2001:db8::1/32" +``` + +### KEDAの設定 {#configuring-keda} + +この`keda`セクションでは、通常の`HorizontalPodAutoscalers`の代わりに、[KEDA](https://keda.sh/) `ScaledObjects`のインストールを有効にします。この設定はオプションであり、カスタムまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。 + +ほとんどの設定は、該当する場合、`hpa`セクションで設定された値にデフォルト設定されます。 + +次の条件がtrueの場合、`hpa`セクションで設定されたCPUおよびメモリーのしきい値に基づいて、CPUおよびメモリートリガーが自動的に追加されます: + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`設定もゼロ以外の値に設定されます。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらの[設定](https://keda.sh/docs/2.10/concepts/scaling-deployments/)の詳細については、[KEDAのドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | 型 | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | Boolean | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用する | +| `pollingInterval` | Integer | `30` | 各トリガーをオンにする間隔 | +| `cooldownPeriod` | Integer | `300` | リソースを0にスケールして戻す前に、アクティブと報告された最後のトリガーの後に待機する期間 | +| `minReplicaCount` | Integer | `hpa.minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `maxReplicaCount` | Integer | `hpa.maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `fallback` | Map | | KEDA [フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback) [設定](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | String | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | Boolean | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールして戻す必要があるかどうかを指定します | +| `behavior` | Map | `hpa.behavior` | アップスケールとダウンスケールの動作の仕様。 | +| `triggers` | Array | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト、デフォルトは`hpa.cpu`および`hpa.memory`からコンピューティングされたトリガー | + +### サービスアカウント {#serviceaccount} + +このセクションでは、サービスアカウントを作成する必要があるかどうか、およびデフォルトのアクセストークンをポッドにマウントする必要があるかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | Map | `{}` | サービスアカウントアノテーション。 | +| `automountServiceAccountToken` | Boolean | `false` | デフォルトのサービスアカウント アクセストークンをポッドにマウントする必要があるかどうかを制御します。特定のサイドカーが正しく動作するために必要な場合（たとえば、Istio）を除き、これを有効にしないでください。 | +| `create` | Boolean | `false` | サービスアカウントを作成する必要があるかどうかを示します。 | +| `enabled` | Boolean | `false` | サービスアカウントを使用するかどうかを示します。 | +| `name` | String | | サービスアカウントの名前。設定されていない場合、チャートのフルネームが使用されます。 | + +### アフィニティ {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-runner/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-runner/_index.md new file mode 100644 index 0000000000..6e81a5f07d --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-runner/_index.md @@ -0,0 +1,87 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Runnerチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLab Runnerサブチャートは、CIジョブを実行するためのGitLab Runnerを提供します。これはデフォルトで有効になっており、S3互換のオブジェクトストレージを使用したキャッシュのサポートにより、すぐに使用できるはずです。 + +{{< alert type="warning" >}} + +含まれているGitLab Runnerチャートのデフォルト設定は、**本番環境を対象としていません**。これは、すべてのGitLabサービスがクラスターにデプロイされる概念実証 (PoC) 実装として提供されます。本番環境のデプロイメントでは、[セキュリティとパフォーマンス上の理由](https://docs.gitlab.com/install/requirements/#gitlab-runner)から、GitLab Runnerを別のマシンにインストールします。詳細については、[リファレンスアーキテクチャドキュメント](../../../installation/_index.md#use-the-reference-architectures)を参照してください。 + +{{< /alert >}} + +## 要件 {#requirements} + +GitLab 16.0では、Runner認証トークンを使用してRunnerをregisterする新しいRunner作成GitLabワークフローが導入されました。登録トークンを使用するレガシーGitLabワークフローは非推奨となり、GitLab 17.0ではデフォルトで無効になっています。GitLab 18.0で削除されます。 + +推奨されるGitLabワークフローを使用するには: + +- [Runner認証トークンを生成します。](https://docs.gitlab.com/ci/runners/new_creation_workflow/#prevent-your-runner-registration-workflow-from-breaking) +- `-gitlab-runner-secret` Runnerシークレットを手動で更新します。設定は[`shared-secrets`](../../shared-secrets.md)ジョブで処理されないためです。 +- `gitlab-runner.runners.locked`を`null`に設定します: + + ```yaml + gitlab-runner: + runners: + locked: null + ``` + +レガシーGitLabワークフローを使用する場合（非推奨）: + +- [レガシーGitLabワークフローを再度有効にする](https://docs.gitlab.com/administration/settings/continuous_integration/#enable-runner-registrations-tokens)必要があります。 +- 登録トークンは、[`shared-secrets`](../../shared-secrets.md)ジョブによって入力されます。 +- GitLab 18.0より前に新しいGitLabワークフローに移行する必要があります。これにより、レガシーGitLabワークフローのサポートが削除されます。 + +## 設定 {#configuration} + +詳細については、[使用方法と設定](https://docs.gitlab.com/runner/install/kubernetes/)に関するドキュメントを参照してください。 + +## スタンドアロンrunnerのデプロイ {#deploying-a-stand-alone-runner} + +デフォルトでは、`gitlabUrl`を推測し、登録トークンを自動的に生成し、`migrations`チャートを介して生成します。実行中のGitLabインスタンスとともにデプロイする場合、この動作は機能しません。 + +この場合、`gitlabUrl`値を実行中のGitLabインスタンスのURLに設定する必要があります。また、`gitlab-runner`シークレットを手動で作成し、実行中のGitLabによって提供される`registrationToken`を入力する必要があります。 + +## Docker-in-Dockerの使用 {#using-docker-in-docker} + +Docker-in-Dockerを実行するには、必要な機能にアクセスできるように、runnerコンテナに特権を与える必要があります。これを有効にするには、`privileged`の値を`true`に設定します。これがデフォルトで`true`にならない理由については、[アップストリームドキュメント](https://docs.gitlab.com/runner/install/kubernetes_helm_chart_configuration/#use-privileged-containers-for-the-runners)を参照してください。 + +### セキュリティに関する懸念 {#security-concerns} + +特権コンテナには拡張機能があり、たとえば、実行元のホストから任意のファイルをマウントできます。重要なものが隣で実行されないように、コンテナを分離された環境で実行してください。 + +## デフォルトのrunner設定 {#default-runner-configuration} + +GitLabチャートで使用されるデフォルトのrunner設定は、デフォルトで含まれているMinIOをキャッシュに使用するようにカスタマイズされています。runner `config`値を設定する場合は、独自のキャッシュ設定も設定する必要があります。 + +```yaml +gitlab-runner: + runners: + config: | + [[runners]] + [runners.kubernetes] + image = "ubuntu:22.04" + {{- if .Values.global.minio.enabled }} + [runners.cache] + Type = "s3" + Path = "gitlab-runner" + Shared = true + [runners.cache.s3] + ServerAddress = {{ include "gitlab-runner.cache-tpl.s3ServerAddress" . }} + BucketName = "runner-cache" + BucketLocation = "us-east-1" + Insecure = false + {{ end }} +``` + +カスタマイズされたすべてのGitLab Runnerチャートの設定は、`gitlab-runner`キーの下の[トップレベル`values.yaml`ファイル](https://gitlab.com/gitlab-org/charts/gitlab/raw/master/values.yaml)で利用できます。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-shell/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-shell/_index.md new file mode 100644 index 0000000000..21d627d0ea --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-shell/_index.md @@ -0,0 +1,496 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Shellチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`gitlab-shell`サブチャートは、Git SSHアクセスをGitLabに対して行うように設定されたSSHサーバーを提供します。 + +## 要件 {#requirements} + +このチャートは、Workhorseサービスへのアクセスに依存します。Workhorseサービスは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスターからアクセス可能な外部サービスとして提供されます。 + +## 設計上の選択 {#design-choices} + +SSHレプリカを容易にサポートし、SSH Authorized Keysに共有ストレージを使用することを避けるために、GitLab authorized keysエンドポイントに対して認証するために、SSH [AuthorizedKeysCommand](https://man.openbsd.org/sshd_config#AuthorizedKeysCommand)を使用しています。その結果、これらのポッド内のAuthorizedKeysファイルを永続化または更新することはありません。 + +## 設定 {#configuration} + +`gitlab-shell`チャートは、[外部サービス](#external-services)と[チャート設定](#chart-settings)の2つの部分で構成されています。Ingressを介して公開されるポートは`global.shell.port`で設定され、デフォルトは`22`です。Serviceの外部ポートも`global.shell.port`によって制御されます。 + +## インストール コマンドライン オプション {#installation-command-line-options} + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|---------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | | Podアノテーション | +| `podLabels` | | 補足的なPodラベル。セレクターには使用されません。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される補足的なラベル。 | +| `config.ciphers` | 説明をご覧ください。 | 許可されている暗号を指定します。デフォルトは`[aes128-gcm@openssh.com, chacha20-poly1305@openssh.com, aes256-gcm@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr]`です。 | +| `config.kexAlgorithms` | 説明をご覧ください。 | 利用可能なKEX（キー交換）アルゴリズムを指定します。デフォルトは`[curve25519-sha256, curve25519-sha256@libssh.org, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1]`です。 | +| `config.macs` | 説明をご覧ください。 | 利用可能なMAC（メッセージ認証コード）アルゴリズムを指定します。デフォルトは`[hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-sha2-256, hmac-sha2-512, hmac-sha1]`です。 | +| `config.clientAliveInterval` | `0` | それ以外の場合はアイドル状態の接続でのキープアライブpingの間隔。デフォルト値の0は、このpingを無効にします | +| `config.loginGraceTime` | `60` | ユーザーが正常にログインしなかった場合にサーバーが切断するまでの時間を指定します | +| `config.maxStartups.full` | `100` | SSHdの拒否確率は線形に増加し、認証されていない接続数が指定された数に達すると、認証されていないすべての接続試行が拒否されます | +| `config.maxStartups.rate` | `30` | 認証されていない接続が多すぎる場合、SSHdは指定された確率で接続を拒否します（オプション） | +| `config.maxStartups.start` | `10` | 現在、指定された数よりも多くの認証されていない接続がある場合、SSHdはある確率で接続試行を拒否します（オプション） | +| `config.proxyProtocol` | `false` | `gitlab-sshd`デーモンのPROXYプロトコルサポートを有効にします | +| `config.proxyPolicy` | `"use"` | PROXYプロトコルを処理するためのポリシーを指定します。値は、`use, require, ignore, reject`のいずれかである必要があります | +| `config.proxyHeaderTimeout` | `"500ms"` | `gitlab-sshd`がPROXYプロトコルヘッダーの読み取りをあきらめるまで待機する最大時間。`ms`、`s`、または`m`の単位を含める必要があります。 | +| `config.publicKeyAlgorithms` | `[]` | 公開キーアルゴリズムのカスタムリスト。空の場合、デフォルトのアルゴリズムが使用されます。 | +| `config.gssapi.enabled` | `false` | `gitlab-sshd`デーモンのGSS-APIサポートを有効にします | +| `config.gssapi.keytab.secret` | | gssapi-with-mic認証方式のkeytabを保持するKubernetesシークレットの名前 | +| `config.gssapi.keytab.key` | `keytab` | Kubernetesシークレットでkeytabを保持するキー | +| `config.gssapi.krb5Config` | | GitLab Shellコンテナ内の`/etc/krb5.conf`ファイルの内容 | +| `config.gssapi.servicePrincipalName` | | `gitlab-sshd`デーモンで使用されるKerberosサービス名 | +| `config.lfs.pureSSHProtocol` | `false` | LFS Pure SSHプロトコルサポートを有効にします | +| `config.pat.enabled` | `true` | SSHを使用したPATを有効にします | +| `config.pat.allowedScopes` | `[]` | SSHで生成されたPATに許可されるスコープの配列 | +| `opensshd.supplemental_config` | | 補足設定は、`sshd_config`に追加されます。[man page](https://manpages.debian.org/bookworm/openssh-server/sshd_config.5.en.html)に厳密に準拠 | +| `deployment.livenessProbe.initialDelaySeconds` | `10` | livenessプローブが開始されるまでの遅延 | +| `deployment.livenessProbe.periodSeconds` | `10` | livenessプローブを実行する頻度 | +| `deployment.livenessProbe.timeoutSeconds` | `3` | livenessプローブがタイムアウトすると | +| `deployment.livenessProbe.successThreshold` | `1` | 失敗した後、livenessプローブが成功したと見なされるための最小連続成功数 | +| `deployment.livenessProbe.failureThreshold` | `3` | 成功した後、livenessプローブが失敗したと見なされるための最小連続失敗数 | +| `deployment.readinessProbe.initialDelaySeconds` | `10` | readinessプローブが開始されるまでの遅延 | +| `deployment.readinessProbe.periodSeconds` | `5` | readinessプローブを実行する頻度 | +| `deployment.readinessProbe.timeoutSeconds` | `3` | readinessプローブがタイムアウトすると | +| `deployment.readinessProbe.successThreshold` | `1` | 失敗した後、readinessプローブが成功したと見なされるための最小連続成功数 | +| `deployment.readinessProbe.failureThreshold` | `2` | 成功した後、readinessプローブが失敗したと見なされるための最小連続失敗数 | +| `deployment.strategy` | `{}` | デプロイメントで使用される更新ストラテジを構成できます | +| `deployment.terminationGracePeriodSeconds` | `30` | Kubernetesがポッドの強制終了を待機する秒数 | +| `enabled` | `true` | Shell有効フラグ | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラルスタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `extraVolumeMounts` | | 実行する追加のボリュームマウントのリスト | +| `extraVolumes` | | 作成する追加のボリュームのリスト | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、スケールアップおよびスケールダウンの動作の仕様が含まれています（`autoscaling/v2beta2`以上が必要です） | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、目的のレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`で構成された平均CPU使用率のデフォルトの使用をオーバーライドします） | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールCPUターゲットタイプを設定します。これは、`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | `100m` | オートスケールCPUターゲット値を設定します | +| `hpa.cpu.targetAverageUtilization` | | オートスケールCPUターゲット使用率を設定します | +| `hpa.memory.targetType` | | オートスケールメモリーターゲットタイプを設定します。これは、`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリーターゲット値を設定します | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリーターゲット使用率を設定します | +| `hpa.targetAverageValue` | | **非推奨**オートスケールCPUターゲット値を設定します | +| `image.pullPolicy` | `IfNotPresent` | Shellイメージプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-shell` | Shellイメージリポジトリ | +| `image.tag` | `master` | Shellイメージtag | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージtag | +| `init.containerSecurityContext` | | initContainer固有の[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナが非rootユーザーで実行されるかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | リソースを0にスケールバックする前に、最後のトリガーがアクティブを報告した後で待機する期間 | +| `keda.minReplicaCount` | `minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `keda.maxReplicaCount` | `maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `keda.fallback` | | KEDAフォールバック設定については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | スケールアップおよびスケールダウンの動作の仕様。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブ化するトリガーのリスト。デフォルトでは、`hpa.cpu`および`hpa.memory`から計算されたトリガー | +| `logging.format` | `json` | 非構造化ログの場合は`text`に設定 | +| `logging.sshdLogLevel` | `ERROR` | 基盤となるSSHデーモンのログレベル | +| `priorityClassName` | | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | +| `replicaCount` | `1` | Shellレプリカ | +| `serviceLabels` | `{}` | 補足サービスラベル | +| `service.allocateLoadBalancerNodePorts` | Kubernetesのデフォルト値を使用するように設定されていません。 | ロードバランサーサービスでNodePort割り当てを無効にすることができます。[ドキュメント](https://kubernetes.io/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation)を参照してください | +| `service.externalTrafficPolicy` | `Cluster` | Shellサービス外部トラフィックポリシー（クラスターまたはローカル） | +| `service.internalPort` | `2222` | Shell内部ポート | +| `service.nodePort` | | 設定されている場合は、shell nodePortを設定します | +| `service.name` | `gitlab-shell` | Shellサービス名 | +| `service.type` | `ClusterIP` | Shellサービスタイプ | +| `service.loadBalancerIP` | | ロードバランサーに割り当てるIPアドレス（サポートされている場合） | +| `service.loadBalancerSourceRanges` | | ロードバランサーへのアクセスを許可されたIP CIDRのリスト（サポートされている場合） | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定されていない場合、完全なチャート名が使用されます | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要です） | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナが開始される[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナが開始される特定のsecurity contextを上書きできます | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナが非rootユーザーで実行されるかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `sshDaemon` | `openssh` | 実行するSSHデーモンを選択します。使用可能な値（`openssh`、`gitlab-sshd`） | +| `tolerations` | `[]` | ポッド割り当てのTolerationラベル | +| `traefik.entrypoint` | `gitlab-shell` | traefikを使用する場合、GitLab Shellに使用するtraefikエントリポイント。デフォルトは`gitlab-shell`です | +| `traefik.tcpMiddlewares` | `[]` | traefikを使用する場合、IngressRouteTCPリソースに追加するTCPミドルウェア。デフォルトではミドルウェアはありません | +| `workhorse.serviceName` | `webservice` | Workhorseサービス名（デフォルトでは、Workhorseはwebservice Pod / Serviceの一部です） | +| `metrics.enabled` | `false` | メトリクスのスクレイピングに使用できるメトリクスエンドポイントを作成する必要がある場合（`sshDaemon=gitlab-sshd`が必要です）。 | +| `metrics.port` | `9122` | メトリクスエンドポイントポート | +| `metrics.path` | `/metrics` | メトリクスエンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにServiceMonitorを作成する必要がある場合、これを有効にすると`prometheus.io`スクレイピングアノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加のラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント設定 | +| `metrics.annotations` | | **非推奨**明示的なメトリクスアノテーションを設定します。テンプレートコンテンツに置き換えられました。 | + +## チャート設定の例 {#chart-configuration-examples} + +### extraEnv {#extraenv} + +`extraEnv`を使用すると、ポッド内のすべてのコンテナで追加の環境変数を公開できます。 + +以下は、`extraEnv`の使用例です。 + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナが起動されると、環境変数が公開されていることを確認できます。 + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +### extraEnvFrom {#extraenvfrom} + +`extraEnvFrom`を使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開できます。 + +以下は、`extraEnvFrom`の使用例です。 + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### image.pullSecrets {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに対して認証して、ポッドのイメージをプルできます。 + +プライベートレジストリとその認証方法に関する追加の詳細は、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)にあります。 + +以下は、`pullSecrets`の使用例です。 + +```yaml +image: + repository: my.shell.repository + tag: latest + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これを有効にしないでください（たとえば、Istio）。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定されていない場合、完全なチャート名が使用されます。 | + +### livenessProbe/readinessProbe {#livenessprobereadinessprobe} + +`deployment.livenessProbe`および`deployment.readinessProbe`は、一部のシナリオでPodの終了を制御するのに役立つメカニズムを提供します。 + +大規模なリポジトリでは、livenessプローブとreadinessプローブの時間を調整して、一般的な長時間実行接続に一致させると効果的です。`clone`および`push`操作中の潜在的な中断を最小限に抑えるために、readinessプローブの期間をlivenessプローブの期間よりも短く設定します。`terminationGracePeriodSeconds`を増やし、スケジューラーがポッドを終了する前に、これらの操作により多くの時間を与えます。より大きなリポジトリワークロードで安定性と効率を高めるためにGitLab Shellポッドを調整するための開始点として、以下の例を検討してください。 + +```yaml +deployment: + livenessProbe: + initialDelaySeconds: 10 + periodSeconds: 20 + timeoutSeconds: 3 + successThreshold: 1 + failureThreshold: 10 + readinessProbe: + initialDelaySeconds: 10 + periodSeconds: 5 + timeoutSeconds: 2 + successThreshold: 1 + failureThreshold: 3 + terminationGracePeriodSeconds: 300 +``` + +この構成に関する追加の詳細については、公式の[Kubernetesドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)を参照してください。 + +### tolerations {#tolerations} + +`tolerations`を使用すると、taintされたワーカーノードでポッドをスケジュールできます + +以下は、`tolerations`の使用例です。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### affinity {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +### annotations {#annotations} + +`annotations`を使用すると、アノテーションをGitLab Shellポッドに追加できます。 + +以下は、`annotations`の使用例です + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +## 外部サービス {#external-services} + +このチャートは、Workhorseサービスにアタッチする必要があります。 + +### Workhorse {#workhorse} + +```yaml +workhorse: + host: workhorse.example.com + serviceName: webservice + port: 8181 +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------|:-------:|:-------------|:------------| +| `host` | 文字列 | | Workhorseサーバーのホスト名。これは、`serviceName`の代わりに省略できます。 | +| `port` | 整数 | `8181` | Workhorseサーバーに接続するポート。 | +| `serviceName` | 文字列 | `webservice` | Workhorseサーバーを操作している`service`の名前。デフォルトでは、Workhorseはwebservice Pod / Serviceの一部です。これが存在し、`host`が存在しない場合、チャートは`host`値の代わりに、サービス（および現在の`.Release.Name`）のホスト名をテンプレート化します。これは、Workhorseを全体のGitLabチャートの一部として使用する場合に便利です。 | + +## チャート設定 {#chart-settings} + +次の値は、GitLab Shell Podを構成するために使用されます。 + +### hostKeys.secret {#hostkeyssecret} + +SSHホストキーを取得するKubernetes `secret`の名前。シークレット内のキーは、GitLab Shellで使用されるために、キー名`ssh_host_`で始まる必要があります。 + +### authToken {#authtoken} + +GitLab Shellは、Workhorseとの通信で認証トークンを使用します。共有シークレットを使用して、GitLab ShellとWorkhorseでトークンを共有します。 + +```yaml +authToken: + secret: gitlab-shell-secret + key: secret +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------|:------:|:--------|:------------| +| `authToken.key` | 文字列 | | 上記のシークレットに含まれる認証トークンを含むキーの名前。 | +| `authToken.secret` | 文字列 | | 取得元のKubernetes `Secret`の名前。 | + +### LoadBalancer Service {#loadbalancer-service} + +`service.type`が`LoadBalancer`に設定されている場合、オプションで`service.loadBalancerIP`を指定して、ユーザー指定のIPで`LoadBalancer`を作成できます (クラウドプロバイダーがサポートしている場合)。 + +また、オプションで`service.loadBalancerSourceRanges`のリストを指定して、`LoadBalancer`にアクセスできるCIDR範囲を制限できます (クラウドプロバイダーがサポートしている場合)。 + +`LoadBalancer`サービスタイプの詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/services-networking/#loadbalancer)を参照してください。 + +```yaml +service: + type: LoadBalancer + loadBalancerIP: 1.2.3.4 + loadBalancerSourceRanges: + - 5.6.7.8/32 + - 10.0.0.0/8 +``` + +### OpenSSH補足設定 {#openssh-supplemental-configuration} + +OpenSSHの`sshd` ( `.sshDaemon: openssh`経由) を使用する場合、`.opensshd.supplemental_config`と、`/etc/ssh/sshd_config.d/*.conf`への設定スニペットのマウントという2つの方法で補足設定を提供できます。 + +指定された設定はすべて、`sshd_config`の機能_要件_を満たしている_必要_があります。[マニュアル](https://man.openbsd.org/sshd_config)ページを[必ず](https://man.openbsd.org/sshd_config)お読みください。 + +#### opensshd.supplemental_config {#opensshdsupplemental_config} + +`.opensshd.supplemental_config`の内容は、コンテナ内の`sshd_config`ファイルの末尾に直接配置されます。この値は、複数行の文字列である必要があります。 + +`ssh-rsa`キー交換アルゴリズムを使用する古いクライアントを有効にする例。`ssh-rsa`などの[非推奨](https://www.openssh.com/txt/release-8.8)のアルゴリズムを有効にすると、[重大なセキュリティの脆弱性](https://www.openssh.com/txt/release-8.8)が発生することに注意してください。これらの変更により、公開されているGitLab **インスタンス**で悪用される**可能性**が**大幅に高まり**ます。 + +```yaml +opensshd: + supplemental_config: |- + HostKeyAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com + PubkeyAcceptedAlgorithms +ssh-rsa,ssh-rsa-cert-v01@openssh.com + CASignatureAlgorithms +ssh-rsa +``` + +#### sshd_config.d {#sshd_configd} + +`/etc/ssh/sshd_config.d`にコンテンツをマウントして`sshd`に完全な設定スニペットを提供できます。ファイルは`*.conf`に一致します。これらは、コンテナ内および_チャート_内でアプリケーションが_機能_するために_必要_なデフォルト設定_後_に含まれていることに注意してください。これらの値は`sshd_config`の_内容_を_上書き_しませんが、拡張します。 + +`extraVolumes`および`extraVolumeMounts`を介して、ConfigMapの単一のアイテムをコンテナにマウントする例: + +```yaml +extraVolumes: | + - name: gitlab-sshdconfig-extra + configMap: + name: gitlab-sshdconfig-extra + +extraVolumeMounts: | + - name: gitlab-sshdconfig-extra + mountPath: /etc/ssh/sshd_config.d/extra.conf + subPath: extra.conf +``` + +### `networkpolicy`の設定 {#configuring-the-networkpolicy} + +このセクションでは、[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を[制御](https://kubernetes.io/docs/concepts/services-networking/network-policies/)します。この設定はオプションであり、特定のエンドポイントに対するポッドのエグレスとIngressを制限するために使用されます。 + +| 名前 | タイプ | デフォルト | 説明 | +|:------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | この設定は`NetworkPolicy`を有効にします | +| `ingress.enabled` | ブール値 | `false` | `true`に設定すると、`Ingress`ネットワークポリシーが有効になります。これにより、ルールが指定されていない限り、すべてのIngress接続がブロックされます。 | +| `ingress.rules` | 配列 | `[]` | Ingressポリシーのルール。詳細については、と以下の例を参照してください | +| `egress.enabled` | ブール値 | `false` | `true`に設定すると、`Egress`ネットワークポリシーが有効になります。これにより、ルールが指定されていない限り、すべてのエグレス接続がブロックされます。 | +| `egress.rules` | 配列 | `[]` | エグレスポリシーのルール。詳細については、と以下の例を参照してください | + +### ネットワークポリシーの例 {#example-network-policy} + +`gitlab-shell`サービスには、ポート22のIngress接続と、デフォルトのWorkhorseポート8181へのさまざまなエグレス接続が必要です。この例では、次のネットワークポリシーを追加します。 + +- Ingressリクエストを許可します: + - `nginx-ingress`ポッドからポート`2222`へ + - `prometheus`ポッドからポート`9122`へ + + {{< alert type="note" >}} + + `prometheus`からポート`9122`へのアクセスは、SSHデーモンが`gitlab-sshd`に設定されている場合にのみ必要です + + {{< /alert >}} + +- エグレスリクエストを許可します: + - `webservice`ポッドからポート`8181`へ + - `gitaly`ポッドからポート`8075`へ + +_提供されている例は単なる例であり、完全ではない可能性があることに注意してください_ + +この例は、`kube-dns`がネームスペース`kube-system`に、`prometheus`がネームスペース`monitoring`に、`nginx-ingress`がネームスペース`nginx-ingress`にデプロイされたという前提に基づいています。 + +```yaml +networkpolicy: + enabled: true + ingress: + enabled: true + rules: + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: nginx-ingress + podSelector: + matchLabels: + app: nginx-ingress + component: controller + ports: + - port: 2222 + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: monitoring + podSelector: + matchLabels: + app: prometheus + component: server + release: gitlab + ports: + - port: 9122 + egress: + enabled: true + rules: + - to: + - podSelector: + matchLabels: + app: gitaly + ports: + - port: 8075 + - to: + - podSelector: + matchLabels: + app: webservice + ports: + - port: 8181 + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + podSelector: + matchLabels: + k8s-app: kube-dns + ports: + - port: 53 + protocol: UDP +``` + +## KEDAの設定 {#configuring-keda} + +この`keda`セクションでは、[KEDA](https://keda.sh/) `ScaledObjects`を通常の`HorizontalPodAutoscalers`の代わりにインストールできます。この設定はオプションであり、カスタムまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。 + +ほとんどの設定は、`hpa`セクションで設定された値にデフォルトで設定されます(該当する場合)。 + +次の条件が満たされる場合、`hpa`セクションで設定されたCPUおよびメモリーのしきい値に基づいて、CPUおよびメモリーのトリガーが自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`設定もゼロ以外の値に設定されています。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらの設定の詳細については、[KEDAドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | ブール値 | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用する | +| `pollingInterval` | 整数 | `30` | 各トリガーのチェック間隔 | +| `cooldownPeriod` | 整数 | `300` | リソースを0にスケールバックする前に、最後のアクティブなトリガーがレポートされてから待機する期間 | +| `minReplicaCount` | 整数 | `minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `maxReplicaCount` | 整数 | `maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `fallback` | マップ | | KEDAフォールバック設定については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | 文字列 | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | ブール値 | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | `hpa.behavior` | スケールアップとスケールダウンの動作の仕様。 | +| `triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`と`hpa.memory`から計算されたトリガーにデフォルト設定されます | + +`keda`の使用例については、[`examples/keda/gitlab-shell.yml`](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/keda/gitlab-shell.yml)を[参照](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/keda/gitlab-shell.yml)してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-zoekt/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-zoekt/_index.md new file mode 100644 index 0000000000..58e76851fc --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-zoekt/_index.md @@ -0,0 +1,121 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Zoektチャート +--- + +{{< details >}} + +- プラン:Premium、Ultimate +- 提供形態:GitLab.com、GitLab Self-Managed +- 状態:ベータ + +{{< /details >}} + +{{< history >}} + +- [導入](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105049)：GitLab 15.9で[ベータ](https://docs.gitlab.com/policy/development_stages_support/#beta)版として[フラグ](https://docs.gitlab.com/administration/feature_flags/)付きで導入（`index_code_with_zoekt`と`search_code_with_zoekt`）。デフォルトでは無効。 +- GitLab 16.6で[GitLab.comで有効化](https://gitlab.com/gitlab-org/gitlab/-/issues/388519)。 +- 機能フラグ`index_code_with_zoekt`と`search_code_with_zoekt`は、GitLab 17.1で[削除](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148378)されました。 + +{{< /history >}} + +{{< alert type="warning" >}} + +この機能は[ベータ](https://docs.gitlab.com/policy/development_stages_support/#beta)版であり、予告なしに変更される場合があります。詳細については、[エピック9404](https://gitlab.com/groups/gitlab-org/-/epics/9404)を参照してください。 + +{{< /alert >}} + +Zoektチャートは、[完全一致コードの検索](https://docs.gitlab.com/user/search/exact_code_search/)をサポートします。`gitlab-zoekt.install`を`true`に設定すると、このチャートをインストールできます。詳細については、[`gitlab-zoekt`](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-zoekt)を参照してください。 + +## Zoektチャートを有効にする {#enable-the-zoekt-chart} + +Zoektチャートを有効にするには、次の値を設定します。 + +```shell +--set gitlab-zoekt.install=true \ +--set gitlab-zoekt.replicas=2 \ # Number of Zoekt pods. If you want to use only one pod, you can skip this setting. +--set gitlab-zoekt.indexStorage=128Gi # Disk size for the Zoekt node. Zoekt requires up to three times the repository's default branch's storage size, depending on the number of large and binary files. +``` + +## CPUとメモリの使用量を設定する {#set-cpu-and-memory-usage} + +次のGitLab.comのデフォルト設定を変更して、Zoektチャートのリクエストと制限を定義できます。 + +```yaml + webserver: + resources: + requests: + cpu: 4 + memory: 32Gi + limits: + cpu: 16 + memory: 128Gi + indexer: + resources: + requests: + cpu: 4 + memory: 6Gi + limits: + cpu: 16 + memory: 12Gi + gateway: + resources: + requests: + cpu: 2 + memory: 512Mi + limits: + cpu: 4 + memory: 1Gi +``` + +## GitLabでZoektを設定する {#configure-zoekt-in-gitlab} + +{{< history >}} + +- GitLab 16.6でシャードはノードに[名称変更](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134717)されました。 + +{{< /history >}} + +GitLabのトップレベルグループに対してZoektを設定するには、次の手順に従います。 + +1. toolboxポッドのRailsコンソールに接続します。 + + ```shell + kubectl exec -it -c toolbox -- gitlab-rails console -e production + ``` + +1. [完全一致コードの検索を有効](https://docs.gitlab.com/integration/exact_code_search/zoekt/#enable-exact-code-search)にします。 +1. インデックス作成を設定します。 + + {{< tabs >}} + + {{< tab title="GitLab 17.7以降" >}} + + ```shell + node = ::Search::Zoekt::Node.online.last + namespace = Namespace.find_by_full_path('') + enabled_namespace = Search::Zoekt::EnabledNamespace.find_or_create_by(namespace: namespace) + replica = enabled_namespace.replicas.find_or_create_by(namespace_id: enabled_namespace.root_namespace_id) + node.indices.create!(zoekt_enabled_namespace_id: enabled_namespace.id, namespace_id: namespace.id, zoekt_replica_id: replica.id) + ``` + + {{< /tab >}} + + {{< tab title="GitLab 17.6以前" >}} + + ```shell + node = ::Search::Zoekt::Node.online.last + namespace = Namespace.find_by_full_path('') + enabled_namespace = Search::Zoekt::EnabledNamespace.find_or_create_by(namespace: namespace) + replica = enabled_namespace.replicas.find_or_create_by(namespace_id: enabled_namespace.root_namespace_id) + replica.ready! + node.indices.create!(zoekt_enabled_namespace_id: enabled_namespace.id, namespace_id: namespace.id, zoekt_replica_id: replica.id, state: :ready) + ``` + + {{< /tab >}} + + {{< /tabs >}} + +Zoektは、プロジェクトが更新または作成された後、そのグループ内のプロジェクトのインデックスを作成できるようになりました。最初のインデックス作成では、Zoektがネームスペースのインデックス作成を開始するまで、少なくとも数分待ちます。 diff --git a/doc-locale/ja-jp/charts/gitlab/kas/_index.md b/doc-locale/ja-jp/charts/gitlab/kas/_index.md new file mode 100644 index 0000000000..dd25070f34 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/kas/_index.md @@ -0,0 +1,236 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab `kas` チャートの使用 +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`kas`サブチャートは、[GitLabエージェントサーバー (KAS)](https://docs.gitlab.com/administration/clusters/kas/)の設定可能なデプロイメントを提供します。エージェントサーバーは、GitLabと一緒にインストールするコンポーネントです。[Kubernetes向けGitLabエージェント](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent)を管理するために必要です。 + +このチャートは、GitLab APIとGitalyサーバーへのアクセスに依存します。このチャートを有効にすると、Ingressがデプロイされます。 + +リソースの消費を最小限に抑えるため、`kas`コンテナはDistrolessイメージを使用します。デプロイされたサービスはIngressによって公開され、通信には[WebSocketプロキシ](https://nginx.org/en/docs/http/websocket.html)を使用します。このプロキシにより、外部コンポーネントである[`agentk`](https://docs.gitlab.com/user/clusters/agent/install/)との長期的な接続が可能になります。`agentk`は、Kubernetesクラスター側のエージェントの対応物です。 + +サービスへのアクセスルートは、[Ingress設定](#specify-an-ingress)によって異なります。 + +詳細については、[Kubernetes向けGitLabエージェントのアーキテクチャ](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md)を参照してください。 + +## エージェントサーバーを無効にする {#disable-the-agent-server} + +GitLabエージェントサーバー（`kas`）はデフォルトで有効になっています。GitLabインスタンスで無効にするには、Helmプロパティ`global.kas.enabled`を`false`に設定します。 + +例: + +```shell +helm upgrade --install kas --set global.kas.enabled=false +``` + +### Ingressを指定する {#specify-an-ingress} + +チャートのIngressをデフォルト設定で使用すると、エージェントサーバーのサービスはサブドメインで到達可能になります。たとえば、`global.hosts.domain: example.com`の場合、エージェントサーバーは`kas.example.com`で到達可能です。 + +[KAS Ingress](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/charts/gitlab/charts/kas/templates/ingress.yaml)は、`global.hosts.domain`とは異なるドメインを使用できます。 + +`global.hosts.kas.name`を設定します。例: + +```shell +global.hosts.kas.name: kas.my-other-domain.com +``` + +この例では、`kas.my-other-domain.com`をKAS Ingressのみのホストとして使用します。その他のサービス（GitLab、Registry、MinIOなどを含む）は、`global.hosts.domain`で指定されたドメインを使用します。 + +### インストールコマンドラインオプション {#installation-command-line-options} + +これらのパラメータを`helm install`コマンドに渡すには、`--set`フラグを使用します。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|-------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッドの割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | `{}` | Podアノテーション。 | +| `common.labels` | `{}` | このチャートによって作成されたすべてのオブジェクトに適用される補助ラベル。 | +| `securityContext.runAsUser` | `65532` | ポッドを開始するユーザーID | +| `securityContext.runAsGroup` | `65534` | ポッドを開始するグループID | +| `securityContext.fsGroup` | `65532` | ポッドを開始するグループID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要です） | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext.runAsUser` | `65532` | コンテナを開始するコンテナの[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)ユーザーIDをオーバーライドします | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラルスタイル文字列。 | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `init.containerSecurityContext` | | initコンテナのsecurityContextのオーバーライド | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-kas` | イメージリポジトリ。 | +| `image.tag` | `v13.7.0` | イメージtag。 | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、アップスケールとダウンスケールのが含まれています（`autoscaling/v2beta2`以上が必要です）。 | +| `hpa.customMetrics` | `[]` | カスタムには、必要なレプリカ数を計算するために使用するが含まれています（`targetAverageUtilization`で構成された平均CPU使用率のデフォルトの使用をオーバーライドします）。 | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールのCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります。 | +| `hpa.cpu.targetAverageValue` | `100m` | オートスケールのCPUターゲットを設定します。 | +| `hpa.cpu.targetAverageUtilization` | | オートスケールのCPUターゲット使用率を設定します。 | +| `hpa.memory.targetType` | | オートスケールのメモリーターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります。 | +| `hpa.memory.targetAverageValue` | | オートスケールのメモリーターゲットを設定します。 | +| `hpa.memory.targetAverageUtilization` | | オートスケールのメモリーターゲット使用率を設定します。 | +| `hpa.targetAverageValue` | | **非推奨**オートスケールのCPUターゲットを設定します | +| `ingress.enabled` | `global.kas.enabled=true`の場合`true` | `kas.ingress.enabled`を使用して、明示的にオンまたはオフにすることができます。設定されていない場合は、オプションで`global.ingress.enabled`を同じ目的で使用できます。 | +| `ingress.apiVersion` | | `apiVersion`フィールドで使用する。 | +| `ingress.annotations` | `{}` | Ingressアノテーション。 | +| `ingress.tls` | `{}` | Ingress TLS。 | +| `ingress.agentPath` | `/` | エージェントAPIのIngressパス。 | +| `ingress.k8sApiPath` | `/k8s-proxy` | Kubernetes APIのIngressパス。 | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用する | +| `keda.pollingInterval` | `30` | 各をチェックする間隔 | +| `keda.cooldownPeriod` | `300` | 最後がアクティブと報告されてから、リソースを0にスケールバックするまで待機する期間 | +| `keda.minReplicaCount` | | KEDAがリソースをスケールダウンするレプリカの最小数。デフォルトは`minReplicas` | +| `keda.maxReplicaCount` | | KEDAがリソースをスケールアップするレプリカの最大数。デフォルトは`maxReplicas` | +| `keda.fallback` | | KEDA構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | | KEDAが作成するHPAリソースの名前。デフォルトは`keda-hpa-{scaled-object-name}` | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | | アップスケールとダウンスケールのの。デフォルトは`hpa.behavior` | +| `keda.triggers` | | ターゲットリソースのをアクティブにするのリスト。デフォルトは`hpa.cpu`と`hpa.memory`から計算された | +| `metrics.enabled` | `true` | のエンドポイントをスクレイピングに使用できるようにするかどうか。 | +| `metrics.path` | `/metrics` | エンドポイントパス。 | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがのスクレイピングを管理できるようにするために、ServiceMonitorを作成するかどうか。有効にすると、`prometheus.io`スクレイピングアノテーションが削除されます。これは、`metrics.podMonitor.enabled`と一緒に有効にすることはできません。 | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加の。 | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加の構成。 | +| `metrics.podMonitor.enabled` | `false` | Prometheus Operatorがのスクレイピングを管理できるようにするために、PodMonitorを作成するかどうか。有効にすると、`prometheus.io`スクレイピングアノテーションが削除されます。これは、`metrics.serviceMonitor.enabled`と一緒に有効にすることはできません。 | +| `metrics.podMonitor.additionalLabels` | `{}` | PodMonitorに追加する追加の。 | +| `metrics.podMonitor.endpointConfig` | `{}` | PodMonitorの追加の構成。 | +| `maxReplicas` | `10` | HPA `maxReplicas`。 | +| `maxUnavailable` | `1` | HPA `maxUnavailable`。 | +| `minReplicas` | `2` | HPA `maxReplicas`。 | +| `nodeSelector` | | 存在する場合は、この`Deployment`の`Pod`の[ノードセレクター](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)を定義します。 | +| `observability.port` | `8151` | 可観測性ポート。とプローブに使用されます。 | +| `observability.livenessProbe.path` | `/liveness` | livenessプローブのURI。このは、KASサービス構成の`observability.liveness_probe.url_path`と一致する必要があります。 | +| `observability.readinessProbe.path` | `/readiness` | readinessプローブのURI。このは、KASサービス構成の`observability.readiness_probe.url_path`と一致する必要があります。 | +| `serviceAccount.annotations` | `{}` | サービスアカウントのアノテーション。 | +| `podLabels` | `{}` | 補足Pod。セレクターには使用されません。 | +| `serviceLabels` | `{}` | 補足サービス。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される補助ラベル。 | +| `resources.requests.cpu` | `100m` | KASポッドごとの最小CPU | +| `resources.requests.memory` | `256Mi` | KASポッドメモリーごとの最小メモリー。 | +| `service.externalPort` | `8150` | 外部ポート（`agentk`接続用）。 | +| `service.internalPort` | `8150` | 内部ポート（`agentk`接続用）。 | +| `service.apiInternalPort` | `8153` | 内部API（GitLabバックエンド用）の内部ポート。 | +| `service.loadBalancerIP` | `nil` | `service.type`が`LoadBalancer`の場合のカスタムロードバランサーIP。 | +| `service.loadBalancerSourceRanges` | `nil` | `service.type`が`LoadBalancer`の場合のカスタムロードバランサーソース範囲のリスト。 | +| `service.kubernetesApiPort` | `8154` | プロキシされたKubernetes APIを公開する外部ポート。 | +| `service.privateApiPort` | `8155` | `kas`のプライベートAPIを公開する内部ポート（`kas` -> `kas`通信用）。 | +| `serviceAccount.annotations` | `{}` | ServiceAccountのアノテーション。 | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します。 | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します。 | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します。 | +| `serviceAccount.name` | | ServiceAccountの名前。設定されていない場合は、チャートのフルネームが使用されます。 | +| `websocketToken.secret` | 自動生成 | WebSocketの署名と検証に使用するシークレットの名前。 | +| `websocketToken.key` | 自動生成 | 使用する`websocketToken.secret`内のキーの名前。 | +| `privateApi.secret` | 自動生成 | データベースとの認証に使用するシークレットの名前。 | +| `privateApi.key` | 自動生成 | 使用する`privateApi.secret`内のキーの名前。 | +| `global.kas.service.apiExternalPort` | `8153` | 内部API（GitLabバックエンド用）の外部ポート。 | +| `service.type` | `ClusterIP` | サービスタイプ。 | +| `tolerations` | `[]` | ポッドの割り当てのToleration。 | +| `customConfig` | `{}` | 指定された場合、デフォルトの`kas`構成をこれらのとマージし、ここで定義されたを優先します。 | +| `deployment.minReadySeconds` | `0` | `kas`ポッドが準備完了と見なされるまでに経過する必要がある最小秒数。 | +| `deployment.strategy` | `{}` | デプロイメントで使用される更新戦略を構成できます。 | +| `deployment.terminationGracePeriodSeconds` | `300` | SIGTERMを受信した後、Podがシャットダウンに費やすことができる時間（秒単位）。 | +| `priorityClassName` | | ポッドに[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)が割り当てられています。 | + +## TLS通信を有効にする {#enable-tls-communication} + +`kas`ポッドと他のGitLabチャートコンポーネント間のTLS通信を、[グローバルKAS属性](../../globals.md#tls-settings-1)を介して有効にします。 + +## `kas`チャートをテストする {#test-the-kas-chart} + +チャートをインストールするには: + +1. 独自のKubernetesクラスターを作成します。 +1. マージリクエストの作業をチェックアウトします。 +1. ローカルチャートからデフォルトで`kas`が有効になっているGitLabをインストール（または）します: + + ```shell + helm upgrade --force --install gitlab . \ + --timeout 600s \ + --set global.hosts.domain=your.domain.com \ + --set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \ + --set certmanager-issuer.email=your@email.com + ``` + +1. GDKを使用して、[Kubernetes向けGitLabエージェント](https://docs.gitlab.com/user/clusters/agent/)を設定および使用するプロセスを実行します:（エージェントを手動で設定して使用する手順に従うこともできます。） + + 1. GDK GitLabリポジトリから、QAフォルダーに移動します:`cd qa`。 + 1. QAを実行するには、次のコマンドを実行します: + + ```shell + GITLAB_USERNAME=$ROOT_USER + GITLAB_PASSWORD=$ROOT_PASSWORD + GITLAB_ADMIN_USERNAME=$ROOT_USER + GITLAB_ADMIN_PASSWORD=$ROOT_PASSWORD + bundle exec bin/qa Test::Instance::All https://your.gitlab.domain/ -- --tag orchestrated --tag quarantine qa/specs/features/ee/api/7_configure/kubernetes/kubernetes_agent_spec.rb + ``` + + 環境変数`GITLAB_AGENTK_VERSION=v13.7.1`を使用してインストールする`agentk`をカスタマイズすることもできます + +## KEDAを設定する {#configuring-keda} + +この`keda`セクションでは、通常の`HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`のインストールを有効にします。このはオプションであり、カスタムまたは外部に基づいてオートスケールが必要な場合に使用できます。 + +ほとんどのは、該当する場合、`hpa`セクションで設定されたにデフォルト設定されます。 + +以下が真の場合、`hpa`セクションで設定されたCPUとメモリーのに基づいて、CPUとメモリーのが自動的に追加されます: + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`の設定もゼロ以外のに設定されています。 + +が設定されていない場合、`ScaledObject`は作成されません。 + +これらのの詳細については、[KEDAドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用する | +| `pollingInterval` | 整数 | `30` | 各をチェックする間隔 | +| `cooldownPeriod` | 整数 | `300` | 最後がアクティブと報告されてから、リソースを0にスケールバックするまで待機する期間 | +| `minReplicaCount` | 整数 | | KEDAがリソースをスケールダウンするレプリカの最小数。デフォルトは`minReplicas` | +| `maxReplicaCount` | 整数 | | KEDAがリソースをスケールアップするレプリカの最大数。デフォルトは`maxReplicas` | +| `fallback` | マップ | | KEDA構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | 文字列 | | KEDAが作成するHPAリソースの名前。デフォルトは`keda-hpa-{scaled-object-name}` | +| `restoreToOriginalReplicaCount` | ブール値 | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | | アップスケールとダウンスケールのの。デフォルトは`hpa.behavior` | +| `triggers` | 配列 | | ターゲットリソースのをアクティブにするのリスト。デフォルトは`hpa.cpu`と`hpa.memory`から計算された | + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountのアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが正常に動作するために必要な場合を除き、これを有効にしないでください（たとえば、Istio）。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定されていない場合は、チャートのフルネームが使用されます。 | + +### affinity {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +## デバッグログを有効にする {#enable-debug-logging} + +KASサブチャートのデバッグログを有効にするには、`values.yaml`ファイルの`kas`セクションに以下を追加します: + +```yaml +customConfig: + observability: + logging: + level: debug + grpc_level: debug +``` diff --git a/doc-locale/ja-jp/charts/gitlab/mailroom/_index.md b/doc-locale/ja-jp/charts/gitlab/mailroom/_index.md new file mode 100644 index 0000000000..b657681ce5 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/mailroom/_index.md @@ -0,0 +1,246 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Mailroomチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +Mailroomチャートは、[受信メール](https://docs.gitlab.com/administration/incoming_email/)を処理します。 + +## 設定 {#configuration} + +```yaml +image: + repository: registry.gitlab.com/gitlab-org/build/cng/gitlab-mailroom + # tag: v0.9.1 + pullSecrets: [] + # pullPolicy: IfNotPresent + +enabled: true + +init: + image: {} + # repository: + # tag: + resources: + requests: + cpu: 50m + +annotations: {} + +# Tolerations for pod scheduling +tolerations: [] +affinity: {} +podLabels: {} + +hpa: + minReplicas: 1 + maxReplicas: 2 + cpu: + targetAverageUtilization: 75 + + # Note that the HPA is limited to autoscaling/v2beta1, autoscaling/v2beta2 and autoscaling/v2 + customMetrics: [] + behavior: {} + +networkpolicy: + enabled: false + egress: + enabled: false + rules: [] + ingress: + enabled: false + rules: [] + annotations: {} + +resources: + # limits: + # cpu: 1 + # memory: 2G + requests: + cpu: 50m + memory: 150M + +## Allow to overwrite under which User and Group we're running. +securityContext: + runAsUser: 1000 + fsGroup: 1000 + +## Enable deployment to use a serviceAccount +serviceAccount: + enabled: false + create: false + annotations: {} + ## Name to be used for serviceAccount, otherwise defaults to chart fullname + # name: +``` + +| パラメータ | デフォルト | 説明 | +|-----------------------------------------------|------------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | `{}` | Podアノテーション。 | +| `deployment.strategy` | `{}` | デプロイで使用される更新戦略を構成できます | +| `enabled` | `true` | Mailroomの有効化フラグ | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | 動作には、アップスケールとダウンスケールの動作の仕様が含まれています（`autoscaling/v2beta2`以上が必要です） | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、目的のレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`で設定された平均CPU使用率のデフォルトの使用を上書きします） | +| `hpa.cpu.targetType` | `Utilization` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | | オートスケールCPUターゲット値を設定します | +| `hpa.cpu.targetAverageUtilization` | `75` | オートスケールCPUターゲット使用率を設定します | +| `hpa.memory.targetType` | | オートスケールメモリターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリターゲット値を設定します | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリターゲット使用率を設定します | +| `hpa.maxReplicas` | `2` | レプリカの最大数 | +| `hpa.minReplicas` | `1` | レプリカの最小数 | +| `image.pullPolicy` | `IfNotPresent` | Mailroomイメージプルポリシー | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `image.pullSecrets` | | Mailroomイメージプルシークレット | +| `image.registry` | | Mailroomイメージレジストリ | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-mailroom` | Mailroomイメージリポジトリ | +| `image.tag` | | Mailroomイメージtag | +| `init.image.repository` | | Mailroom initイメージリポジトリ | +| `init.image.tag` | | Mailroom initイメージtag | +| `init.resources` | `{ requests: { cpu: 50m }}` | Mailroom initコンテナリソース要件 | +| `init.containerSecurityContext` | | initContainerコンテナ固有の[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `keda.enabled` | `false` | `ScaledObjects`[KEDA](https://keda.sh/)を[使用](https://keda.sh/)して、`HorizontalPodAutoscalers`の代わりに使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | 最後のアクティブとレポートされたトリガーの後に、リソースを0にスケールバックするまで待機する期間 | +| `keda.minReplicaCount` | `hpa.minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `keda.maxReplicaCount` | `hpa.maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `keda.fallback` | | KEDA [フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`の削除後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | アップスケールとダウンスケールの動作の仕様。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`および`hpa.memory`から計算されたトリガーにデフォルト設定します | +| `podLabels` | `{}` | Mailroomポッドを実行するためのラベル | +| `common.labels` | `{}` | このチャートで作成されたすべてのオブジェクトに適用される補足ラベル。 | +| `resources` | `{ requests: { cpu: 50m, memory: 150M }}` | Mailroomリソース要件 | +| `networkpolicy.annotations` | `{}` | NetworkPolicyに追加するアノテーション | +| `networkpolicy.egress.enabled` | `false` | NetworkPolicyのエグレスルールを有効にするフラグ | +| `networkpolicy.egress.rules` | `[]` | NetworkPolicyのエグレスルールのリストを定義する | +| `networkpolicy.enabled` | `false` | NetworkPolicyを使用するためのフラグ | +| `networkpolicy.ingress.enabled` | `false` | NetworkPolicyの`ingress`ルールを有効にするフラグ | +| `networkpolicy.ingress.rules` | `[]` | NetworkPolicyの`ingress`ルールのリストを定義する | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要） | +| `containerSecurityContext` | | コンテナが起動されるコンテナの[オーバーライド](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `containerSecurityContext.runAsUser` | `1000` | コンテナが起動される特定のセキュリティコンテキストを上書きできるようにします | +| `serviceAccount.annotations` | `{}` | ServiceAccountのアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定されていない場合、チャートのフルネームが使用されます | +| `tolerations` | | Mailroomに追加するTolerations | +| `priorityClassName` | | [ポッド](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)に[割り当て](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)られた[優先](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)度クラス。 | + +## KEDAの設定 {#configuring-keda} + +この`keda`セクションでは、通常の`HorizontalPodAutoscalers`ではなく、[KEDA](https://keda.sh/) `ScaledObjects`のインストールを有効にします。この設定はオプションであり、カスタムまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。 + +ほとんどの設定は、該当する場合は`hpa`セクションで設定された値にデフォルト設定されます。 + +次がtrueの場合、CPUおよびメモリトリガーは、`hpa`セクションで設定されたCPUおよびメモリしきい値に基づいて自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`の設定も、ゼロ以外の値に設定されています。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらの[設定](https://keda.sh/docs/2.10/concepts/scaling-deployments/)の詳細については、[KEDAドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | 種類 | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | ブール値 | `false` | `ScaledObjects`[KEDA](https://keda.sh/)を[使用](https://keda.sh/)して、`HorizontalPodAutoscalers`の代わりに使用します | +| `pollingInterval` | 整数 | `30` | 各トリガーをチェックする間隔 | +| `cooldownPeriod` | 整数 | `300` | 最後のアクティブとレポートされたトリガーの後に、リソースを0にスケールバックするまで待機する期間 | +| `minReplicaCount` | 整数 | `hpa.minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `maxReplicaCount` | 整数 | `hpa.maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `fallback` | マップ | | KEDA [フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | 文字列 | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | ブール値 | | `ScaledObject`の削除後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | `hpa.behavior` | アップスケールとダウンスケールの動作の仕様。 | +| `triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`および`hpa.memory`から計算されたトリガーにデフォルト設定します | + +## 受信メール {#incoming-email} + +デフォルトでは、受信メールは無効になっています。受信メールを読む方法は2つあります: + +- [IMAP](#imap) +- [Microsoft Graph](#microsoft-graph) + +まず、[共通設定](../../../installation/command-line-options.md#common-settings)を設定して有効にします。次に、[IMAP設定](../../../installation/command-line-options.md#imap-settings)または[Microsoft Graph設定](../../../installation/command-line-options.md#microsoft-graph-settings)を構成します。 + +これらの方法は、`values.yaml`で構成できます。次の例を参照してください: + +- [IMAPでの受信メール](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/email/values-incoming-email.yaml) +- [Microsoft Graphでの受信メール](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/email/values-msgraph.yaml) + +### IMAP {#imap} + +IMAPの受信メールを有効にするには、`global.appConfig.incomingEmail`設定を使用して、IMAPサーバーと認証情報の詳細を提供します。 + +さらに、ターゲットのIMAPアカウントをGitLabがメール受信に[使用](https://docs.gitlab.com/administration/incoming_email/)できることを確認するには、[IMAPメールアカウントの要件](https://docs.gitlab.com/administration/incoming_email/)を[レビュー](https://docs.gitlab.com/administration/incoming_email/)する必要があります。いくつかの一般的なメールサービスも同じページに記載されており、受信メールの設定に役立ちます。 + +IMAPパスワードは、[シークレットガイド](../../../installation/secrets.md#imap-password-for-incoming-emails)に記載されているように、Kubernetes [シークレット](../../../installation/secrets.md#imap-password-for-incoming-emails)として作成する必要があります。 + +### Microsoft Graph {#microsoft-graph} + +[Azure Active Directoryアプリケーションの作成に関するGitLabドキュメント](https://docs.gitlab.com/administration/incoming_email/#microsoft-graph)を参照してください。 + +テナントID、クライアントID、クライアントシークレットを提供します。これらの[設定](../../../installation/command-line-options.md#incoming-email-configuration)の詳細については、[コマンドラインオプション](../../../installation/command-line-options.md#incoming-email-configuration)を参照してください。 + +[シークレットガイド](../../../installation/secrets.md#microsoft-graph-client-secret-for-incoming-emails)の説明に従って、クライアント[シークレット](../../../installation/secrets.md#microsoft-graph-client-secret-for-incoming-emails)を含むKubernetes [シークレット](../../../installation/secrets.md#microsoft-graph-client-secret-for-incoming-emails)を作成します。 + +### メールによる返信 {#reply-by-email} + +メールによる返信[機能](../../../installation/command-line-options.md#outgoing-email-configuration)を[使用](../../../installation/command-line-options.md#outgoing-email-configuration)するには、[ユーザー](../../../installation/command-line-options.md#outgoing-email-configuration)が通知メールに返信して[イシュー](../../../installation/command-line-options.md#outgoing-email-configuration)とMRにコメントできるようにするには、[送信メール](../../../installation/command-line-options.md#outgoing-email-configuration)と受信メールの[設定](../../../installation/command-line-options.md#outgoing-email-configuration)を構成する必要があります。 + +### サービスデスクのメール {#service-desk-email} + +デフォルトでは、サービスデスクのメールは無効になっています。 + +受信メールと同様に、[共通設定](../../../installation/command-line-options.md#common-settings-1)を設定して有効にします。次に、[IMAP設定](../../../installation/command-line-options.md#imap-settings-1)または[Microsoft Graph設定](../../../installation/command-line-options.md#microsoft-graph-settings-1)を構成します。 + +これらのオプションは、`values.yaml`でも構成できます。次の例を参照してください: + +- [IMAPを使用したサービスデスク](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/email/values-service-desk-email.yaml) +- [Microsoft Graphを使用したサービスデスク](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/email/values-msgraph.yaml) + +サービスデスクのメールは、[受信メール](#incoming-email)を構成することを_要求_します。 + +#### IMAP {#imap-1} + +`global.appConfig.serviceDeskEmail`設定を使用して、IMAPサーバーと認証情報の詳細を提供します。これらの設定の詳細については、[コマンドラインオプション](../../../installation/command-line-options.md#service-desk-email-configuration)を参照してください。 + +[シークレットガイド](../../../installation/secrets.md#imap-password-for-service-desk-emails)の説明に従って、IMAPパスワードを含むKubernetes [シークレット](../../../installation/secrets.md#imap-password-for-service-desk-emails)を作成します。 + +#### Microsoft Graph {#microsoft-graph-1} + +[Azure Active Directoryアプリケーションの作成に関するGitLabドキュメント](https://docs.gitlab.com/administration/incoming_email/#microsoft-graph)を参照してください。 + +`global.appConfig.serviceDeskEmail`設定を使用して、テナントID、クライアントID、クライアントシークレットを提供します。これらの設定の詳細については、[コマンドラインオプション](../../../installation/command-line-options.md#service-desk-email-configuration)を参照してください。 + +[シークレットガイド](../../../installation/secrets.md#imap-password-for-service-desk-emails)の説明に従って、クライアント[シークレット](../../../installation/secrets.md#imap-password-for-service-desk-emails)を含むKubernetes [シークレット](../../../installation/secrets.md#imap-password-for-service-desk-emails)も作成する必要があります。 + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合（たとえば、Istio）、これを有効にしないでください。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定されていない場合は、チャートのフルネームが使用されます。 | + +### アフィニティ {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/migrations/_index.md b/doc-locale/ja-jp/charts/gitlab/migrations/_index.md new file mode 100644 index 0000000000..dbec2fdcee --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/migrations/_index.md @@ -0,0 +1,265 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab-Migrationsチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`migrations`サブチャートは、GitLabデータベースのシーディング/移行を処理する単一の移行[ジョブ](https://kubernetes.io/docs/concepts/workloads/controllers/job/)を提供します。このチャートは、GitLab Railsのコードベースを使用して実行されます。 + +移行後、このジョブは、[許可されたキーファイルへの書き込み](https://docs.gitlab.com/administration/operations/fast_ssh_key_lookup/#setting-up-fast-lookup-via-gitlab-shell)をオフにするために、データベース内のアプリケーション設定も編集します。このチャートでは、許可されたキーファイルへの書き込みのサポートの代わりに、SSH `AuthorizedKeysCommand`でGitLab Authorized Keys APIの使用のみをサポートしています。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして、RedisおよびPostgreSQLに依存します。 + +## 設計上の選択 {#design-choices} + +`migrations`チャートは、チャートのインストール時、または新しい[チャートバージョン](https://helm.sh/docs/topics/charts/#charts-and-versioning)、[appVersion](https://helm.sh/docs/topics/charts/#the-appversion-field)、またはいずれかの値への変更でチャートがアップグレードされるたびに、新しい移行[ジョブ](https://kubernetes.io/docs/concepts/workloads/controllers/job/)を作成します。 + +このチャートのインストールとアップグレードに`helm install`と`helm upgrade`を使用すると、このチャートによって作成されたジョブは、次のチャートのアップグレードまでクラスター内のオブジェクトとして残ります。これは、移行ログを監視できるようにするためです。何らかの形式のログの生成が適切に行われると、これらのオブジェクトの永続性を再検討できます。 + +`helm template`と`kubectl apply`、または同様のツールで生成されたマニフェストを使用してデプロイメントが行われる場合、古い移行ジョブオブジェクトはクラスターから削除されません。 + +このチャートで使用されているコンテナには、現在ここで使用していない追加の最適化がいくつかあります。主に、Railsアプリケーションを起動して確認しなくても、すでに最新の状態になっている場合は、移行の実行をすばやくスキップできる機能です。この最適化では、移行状態を永続化する必要があります。これは、現時点ではこのチャートでは行っていません。将来的には、このチャートへの移行状態のストレージサポートを導入する予定です。 + +## 設定 {#configuration} + +`migrations`チャートは、外部サービスとチャート設定の2つの部分で構成されています。 + +## インストールコマンドラインline>オプション {#installation-command-line-options} + +下のテーブルに、`--set`フラグを使用して`helm install`コマンドに指定できる、すべての可能なチャート設定が含まれています + +| パラメータ | 説明 | デフォルト | +| --------------------------- | ---------------------------------------- | ---------------- | +| `common.labels` | このチャートによって作成されたすべてのオブジェクトに適用される補助ラベル。 | `{}` | +| `image.repository` | 移行イメージリポジトリ | `registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ee` | +| `image.tag` | 移行イメージtag | | +| `image.pullPolicy` | 移行プルポリシー | `Always` | +| `image.pullSecrets` | イメージリポジトリのシークレット | | +| `init.image.repository` | initContainerイメージリポジトリ | `registry.gitlab.com/gitlab-org/build/cng/gitlab-base` | +| `init.image.tag` | initContainerイメージtag | `master` | +| `init.image.containerSecurityContext` | initコンテナsecurityContext上書き | `{}` | +| `init.containerSecurityContext.allowPrivilegeEscalation` | initContainer固有:プロセスがその親プロセスよりも多くの特権を取得できるかどうかを制御します | `false` | +| `init.containerSecurityContext.runAsNonRoot` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | `true` | +| `init.containerSecurityContext.capabilities.drop` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | `[ "ALL" ]` | +| `enabled` | 移行を有効にするフラグ | `true` | +| `tolerations` | ポッドの割り当ての容認ラベル | `[]` | +| `affinity` | ポッドの割り当ての[アフィニティルール](../_index.md#affinity) | `{}` | +| `annotations` | ジョブ仕様のアノテーション | `{}` | +| `podAnnotations` | ポッド 仕様のアノテーション | `{}` | +| `podLabels` | 補助ポッド ラベル。セレクターには使用されません。 | | +| `redis.serviceName` | Redisサービス名 | `redis` | +| `psql.serviceName` | PostgreSQLを提供するサービスの名前 | `release-postgresql` | +| `psql.password.secret` | psqlシークレット | `gitlab-postgres` | +| `psql.password.key` | psqlシークレット内のpsqlパスワードへのキー | `psql-password` | +| `psql.port` | PostgreSQLサーバーのポートを設定します。`global.psql.port`より優先されます | | +| `resources.requests.cpu` | GitLabの移行の最小CPU | `250m` | +| `resources.requests.memory` | GitLabの移行の最小メモリ | `200Mi` | +| `securityContext.fsGroup` | ポッドを開始するグループID | `1000` | +| `securityContext.runAsUser` | ポッドを開始するユーザーID | `1000` | +| `securityContext.fsGroupChangePolicy` | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要） | | +| `securityContext.seccompProfile.type` | 使用するSeccompプロファイル | `RuntimeDefault` | +| `containerSecurityContext.runAsUser` | コンテナの開始元のコンテナ[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | `1000` | +| `containerSecurityContext.allowPrivilegeEscalation` | コンテナのプロセスがその親プロセスよりも多くの特権を取得できるかどうかを制御します | `false` | +| `containerSecurityContext.runAsNonRoot` | コンテナを非rootユーザーで実行するかどうかを制御します | `true` | +| `containerSecurityContext.capabilities.drop` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | `[ "ALL" ]` | +| `serviceAccount.annotations` | ServiceAccountアノテーション | `{}` | +| `serviceAccount.automountServiceAccountToken`| デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | `false` | +| `serviceAccount.create` | ServiceAccountを作成するかどうかを示します | `false` | +| `serviceAccount.enabled` | ServiceAccountを使用するかどうかを示します | `false` | +| `serviceAccount.name` | ServiceAccountの名前。設定されていない場合、チャートのフルネームが使用されます | | +| `extraInitContainers` | 含める追加のinitコンテナのリスト | | +| `extraContainers` | 含めるコンテナのリストを含む複数行のリテラル スタイル文字列 | | +| `extraVolumes` | 作成する追加ボリュームのリスト | | +| `extraVolumeMounts` | 実行する追加ボリュームマウントのリスト | | +| `extraEnv` | 公開する追加の環境変数variable>のリスト | | +| `extraEnvFrom` | 公開する他のデータソースからの追加の環境変数variable>のリスト| | +| `priorityClassName` | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | | + +## チャート設定例 {#chart-configuration-examples} + +### extraEnv {#extraenv} + +`extraEnv`を使用すると、ポッド内のすべてのコンテナで追加の環境変数variable>を公開できます。 + +`extraEnv`の使用例を以下に示します: + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナが起動すると、環境変数variable>が公開されていることを確認できます: + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +### extraEnvFrom {#extraenvfrom} + +`extraEnvFrom`を使用すると、ポッド内のすべてのコンテナで他のデータソースからの追加の環境変数variable>を公開できます。 + +`extraEnvFrom`の使用例を以下に示します: + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### image.pullSecrets {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに認証して、ポッドのイメージをプルできます。 + +プライベートレジストリとその認証方法に関する追加の詳細は、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)にあります。 + +`pullSecrets`の使用例を以下に示します: + +```YAML +image: + repository: my.migrations.repository + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが正常に動作するためにこれが必要な場合（たとえば、Istio）、これを有効にしないでください。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定されていない場合、チャートのフルネームが使用されます。 | + +### affinity {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +## このチャートのCommunityエディションの使用 {#using-the-community-edition-of-this-chart} + +デフォルトでは、HelmチャートはGitLabのGitLab Enterpriseエディション（EE）を使用します。必要に応じて、代わりにCommunityエディションを使用できます。[2つの違い](https://about.gitlab.com/install/ce-or-ee/)について詳しく見る。 + +Communityエディションを使用するには、`image.repository`を`registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ce`に設定します + +## 外部サービス {#external-services} + +### Redis {#redis} + +```YAML +redis: + host: redis.example.com + serviceName: redis + port: 6379 + sentinels: + - host: sentinel1.example.com + port: 26379 + password: + secret: gitlab-redis + key: redis-password +``` + +#### host {#host} + +使用するデータベースを持つRedisサーバーのホスト名。これは、`serviceName`の代わりとして省略できます。Redis Sentinelを使用している場合、`host`属性は、`sentinel.conf`で指定されているクラスター名に設定する必要があります。 + +#### serviceName {#servicename} + +Redisデータベースをオペレートしている`service`の名前。これが存在し、`host`が存在しない場合、チャートはサービスのホスト名（および現在の`.Release.Name`）を`host`値の代わりにテンプレート化します。これは、Redisを全体のGitLabチャートの一部として使用する場合に便利です。これはデフォルトで`redis`になります + +#### ポート {#port} + +Redisサーバーに接続するポート。デフォルトは`6379`です。 + +#### パスワード {#password} + +Redisの`password`属性には、2つのサブキーがあります: + +- `secret`は、プルするKubernetes `Secret`の名前を定義します +- `key`は、上記のシークレットに含まれるキーの名前を定義します。 + +#### センティネル {#sentinels} + +`sentinels`属性を使用すると、Redis HAクラスターに接続できます。サブキーは、各Sentinel接続を記述します。 + +- `host`は、Sentinelサービスのホスト名を定義します +- `port`は、Sentinelサービスに到達するポート番号を定義します（デフォルトは`26379`）。 + +_注:_現在のRedis Sentinelサポートは、GitLabチャートとは別にデプロイされたSentinelのみをサポートします。その結果、GitLabチャートを介したRedisデプロイメントは、`redis.install=false`で無効にする必要があります。Redisパスワードを含むシークレットは、GitLabチャートをデプロイする前に手動で作成する必要があります。 + +### PostgreSQL {#postgresql} + +```yaml +psql: + host: psql.example.com + serviceName: pgbouncer + port: 5432 + database: gitlabhq_production + username: gitlab + preparedStatements: false + password: + secret: gitlab-postgres + key: psql-password +``` + +#### ホスト {#host-1} + +使用するデータベースを持つPostgreSQLサーバーのホスト名。これは、`postgresql.install=true`の場合（デフォルトは非本番環境）は省略できます。 + +#### serviceName {#servicename-1} + +PostgreSQLデータベースをオペレートしているサービスの名前。これが存在し、`host`が存在しない場合、チャートは`host`値の代わりにサービスのホスト名をテンプレート化します。 + +#### ポート {#port-1} + +PostgreSQLサーバーに接続するポート。デフォルトは`5432`です。 + +#### データベース {#database} + +PostgreSQLサーバーで使用するデータベースの名前。これはデフォルトで`gitlabhq_production`になります。 + +#### preparedStatements {#preparedstatements} + +PostgreSQLサーバーと接続中にプリペアドステートメントを使用するかどうか。デフォルトは`false`です。 + +#### ユーザー名 {#username} + +データベースに認証するためのユーザー名。これはデフォルトで`gitlab`になります + +#### パスワード {#password-1} + +PostgreSQLの`password`属性には、サブキーが必要です: + +- `secret`は、プルするKubernetes `Secret`の名前を定義します +- `key`は、上記のシークレットに含まれるキーの名前を定義します。 diff --git a/doc-locale/ja-jp/charts/gitlab/praefect/_index.md b/doc-locale/ja-jp/charts/gitlab/praefect/_index.md new file mode 100644 index 0000000000..3c44ecaec1 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/praefect/_index.md @@ -0,0 +1,333 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Praefectチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed +- 状態:実験 + +{{< /details >}} + +{{< alert type="warning" >}} + +Praefectチャートはまだ開発中です。この実験的なバージョンは、まだ本番環境での使用には適していません。アップグレードには、大幅な手動による介入が必要になる場合があります。詳細については、[Praefect GAリリースエピック](https://gitlab.com/groups/gitlab-org/charts/-/epics/33)を参照してください。 + +{{< /alert >}} + +Praefectチャートは、Helm ChartでデプロイされたGitLabインストール内の[Gitalyクラスター](https://docs.gitlab.com/administration/gitaly/praefect/)を管理するために使用されます。 + +## 既知の制限事項と問題 {#known-limitations-and-issues} + +1. データベースは[手動で作成](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2310)する必要があります。 +1. クラスターサイズは固定されています:[Gitalyクラスターは現在、オートスケールをサポートしていません](https://gitlab.com/gitlab-org/gitaly/-/issues/2997)。 +1. クラスター内のPraefectインスタンスを使用して、クラスター外のGitalyインスタンスを管理することは[サポートされていません](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2662)。 + +## 要件 {#requirements} + +このチャートはGitalyチャートを使用します。`global.gitaly`の設定は、このチャートで作成されたインスタンスの設定に使用されます。これらの設定のドキュメントは、[Gitalyチャートのドキュメント](../gitaly/_index.md)にあります。 + +_重要_:`global.gitaly.tls`は`global.praefect.tls`とは独立しています。これらは個別に構成されます。 + +デフォルトでは、このチャートは3つのGitalyレプリカを作成します。 + +## 設定 {#configuration} + +このチャートはデフォルトで無効になっています。チャートのデプロイの一部として有効にするには、`global.praefect.enabled=true`を設定します。 + +### レプリカ {#replicas} + +デプロイするレプリカのデフォルト数は3です。これは、必要なレプリカ数を指定して`global.praefect.virtualStorages[].gitalyReplicas`を設定することで変更できます。例: + +```yaml +global: + praefect: + enabled: true + virtualStorages: + - name: default + gitalyReplicas: 4 + maxUnavailable: 1 +``` + +### 複数の仮想ストレージ {#multiple-virtual-storages} + +複数の仮想ストレージを設定できます([Gitalyクラスター](https://docs.gitlab.com/administration/gitaly/praefect/)のドキュメントを参照)。例: + +```yaml +global: + praefect: + enabled: true + virtualStorages: + - name: default + gitalyReplicas: 4 + maxUnavailable: 1 + - name: vs2 + gitalyReplicas: 5 + maxUnavailable: 2 +``` + +これにより、Gitalyのリソースが2セット作成されます。これには、2つのGitaly StatefulSet (仮想ストレージごとに1つ)が含まれます。 + +次に、[管理者は新しいリポジトリの保存場所を設定](https://docs.gitlab.com/administration/repository_storage_paths/#configure-where-new-repositories-are-stored)できます。 + +### 永続性 {#persistence} + +仮想ストレージごとに永続性の設定を指定できます。 + +```yaml +global: + praefect: + enabled: true + virtualStorages: + - name: default + gitalyReplicas: 4 + maxUnavailable: 1 + persistence: + enabled: true + size: 50Gi + accessMode: ReadWriteOnce + storageClass: storageclass1 + - name: vs2 + gitalyReplicas: 5 + maxUnavailable: 2 + persistence: + enabled: true + size: 100Gi + accessMode: ReadWriteOnce + storageClass: storageclass2 +``` + +## defaultReplicationFactor {#defaultreplicationfactor} + +`defaultReplicationFactor`は、各仮想ストレージで構成できます(「[レプリケーション係数の構成](https://docs.gitlab.com/administration/gitaly/praefect/#configure-replication-factor)」ドキュメントを参照)。 + +```yaml +global: + praefect: + enabled: true + virtualStorages: + - name: default + gitalyReplicas: 5 + maxUnavailable: 2 + defaultReplicationFactor: 3 + - name: secondary + gitalyReplicas: 4 + maxUnavailable: 1 + defaultReplicationFactor: 2 +``` + +### Praefectへの移行 {#migrating-to-praefect} + +{{< alert type="note" >}} + +グループWikiは、[APIを使用して移動することはできません](https://docs.gitlab.com/api/project_repository_storage_moves/)。 + +{{< /alert >}} + +スタンドアロンGitalyインスタンスからPraefectセットアップに移行する場合、`global.praefect.replaceInternalGitaly`を`false`に設定できます。これにより、新しいPraefect管理対象Gitalyインスタンスが作成されている間、既存のGitalyインスタンスが確実に保持されます。 + +```yaml +global: + praefect: + enabled: true + replaceInternalGitaly: false + virtualStorages: + - name: virtualStorage2 + gitalyReplicas: 5 + maxUnavailable: 2 +``` + +{{< alert type="note" >}} + +Praefectへの移行時に、Praefectのどの仮想ストレージも`default`という名前にすることはできません。これは、常に少なくとも1つのストレージに`default`という名前を付ける必要があるため、名前はPraefect以外の構成ですでに使用されているためです。 + +{{< /alert >}} + +次に、[Gitalyクラスターに移行](https://docs.gitlab.com/administration/gitaly/#migrating-to-gitaly-cluster)する手順に従って、`default`ストレージから`virtualStorage2`にデータを移動できます。追加のストレージが`global.gitaly.internal.names`で定義されている場合は、それらのストレージからリポジトリも移行してください。 + +リポジトリが`virtualStorage2`に移行された後、Praefect構成に`default`という名前のストレージが追加された場合、`replaceInternalGitaly`を`true`に戻すことができます。 + +```yaml +global: + praefect: + enabled: true + replaceInternalGitaly: true + virtualStorages: + - name: default + gitalyReplicas: 4 + maxUnavailable: 1 + - name: virtualStorage2 + gitalyReplicas: 5 + maxUnavailable: 2 +``` + +必要に応じて、[Gitalyクラスターに移行](https://docs.gitlab.com/administration/gitaly/#migrating-to-gitaly-cluster)する手順に再度従って、`virtualStorage2`から新しく追加された`default`ストレージにデータを移動できます。 + +最後に、[リポジトリストレージパスのドキュメント](https://docs.gitlab.com/administration/repository_storage_paths/#choose-where-new-repositories-are-stored)を参照して、新しいリポジトリの保存場所を設定します。 + +### データベースの作成 {#creating-the-database} + +Praefectは、独自のデータベースを使用して状態を追跡します。Praefectが機能するためには、これを手動で作成する必要があります。 + +{{< alert type="note" >}} + +これらの手順では、バンドルされたPostgreSQLサーバーを使用していることを前提としています。独自のサーバーを使用している場合は、接続方法に多少の違いがあります。 + +{{< /alert >}} + +1. データベースインスタンスにログインします: + + ```shell + kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash + ``` + + ```shell + PGPASSWORD=$(echo $POSTGRES_POSTGRES_PASSWORD) psql -U postgres -d template1 + ``` + +1. データベースユーザーを作成します: + + ```sql + CREATE ROLE praefect WITH LOGIN; + ``` + +1. データベースユーザーのパスワードを設定します。 + + デフォルトでは、`shared-secrets`ジョブはシークレットを生成します。 + + 1. パスワードをフェッチします: + + ```shell + kubectl get secret RELEASE_NAME-praefect-dbsecret -o jsonpath="{.data.secret}" | base64 --decode + ``` + + 1. `psql`プロンプトでパスワードを設定します: + + ```sql + \password praefect + ``` + +1. データベースを作成します: + + ```sql + CREATE DATABASE praefect WITH OWNER praefect; + ``` + +### TLS経由でのPraefectの実行 {#running-praefect-over-tls} + +Praefectは、クライアントおよびGitalyノードとのTLS経由での通信をサポートします。これは、`global.praefect.tls.enabled`および`global.praefect.tls.secretName`の設定によって制御されます。TLS経由でPraefectを実行するには、次の手順に従います: + +1. Helm Chartは、TLS経由でPraefectと通信するために証明書が提供されることを想定しています。この証明書は、存在するすべてのPraefectノードに適用される必要があります。したがって、これらの各ノードのすべてのホスト名を証明書のサブジェクト代替名 (SAN)として追加するか、またはワイルドカードを使用できます。 + + 使用するホスト名を知るには、Toolbox Podの`/srv/gitlab/config/gitlab.yml`ファイルを確認し、その中の`repositories.storages`キーの下に指定されているさまざまな`gitaly_address`フィールドを確認します。 + + ```shell + kubectl exec -it -- grep gitaly_address /srv/gitlab/config/gitlab.yml + ``` + +{{< alert type="note" >}} + +内部Praefectポッド用のカスタム署名付き証明書を生成するための基本スクリプトは、[このリポジトリにあります](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/generate_certificates.sh)。ユーザーはそのスクリプトを使用して、適切なSAN属性を持つ証明書を生成したり、参照したりできます。 + +{{< /alert >}} + +1. 作成した証明書を使用してTLSシークレットを作成します。 + + ```shell + kubectl create secret tls --cert=praefect.crt --key=praefect.key + ``` + +1. `--set global.praefect.tls.enabled=true`を渡してHelm Chartを再デプロイします。 + +TLS経由でGitalyを実行する場合は、仮想ストレージごとにシークレット名を指定する必要があります。 + +```yaml +global: + gitaly: + tls: + enabled: true + praefect: + enabled: true + tls: + enabled: true + secretName: praefect-tls + virtualStorages: + - name: default + gitalyReplicas: 4 + maxUnavailable: 1 + tlsSecretName: default-tls + - name: vs2 + gitalyReplicas: 5 + maxUnavailable: 2 + tlsSecretName: vs2-tls +``` + +### コマンドラインオプションのインストール {#installation-command-line-options} + +次のテーブルには、`--set`フラグを使用して`helm install`コマンドに指定できるすべての可能なチャート構成が含まれています。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|---------------------------------------------------|-------------| +| common.labels | `{}` | このチャートで作成されたすべてのオブジェクトに適用される追加ラベル。 | +| failover.enabled | true | Praefectがノード障害時にフェイルオーバーを実行するかどうか | +| failover.readonlyAfter | false | ノードがフェイルオーバー後に読み取り専用モードになるかどうか | +| autoMigrate | true | スタートアップ時に移行を自動的に実行する | +| image.repository | `registry.gitlab.com/gitlab-org/build/cng/gitaly` | 使用するデフォルトのイメージリポジトリ。PraefectはGitalyイメージの一部としてバンドルされています | +| podLabels | `{}` | 補足のポッドラベル。セレクターには使用されません。 | +| ntpHost | `pool.ntp.org` | Praefectが現在の時刻を要求するNTPサーバーを構成します。 | +| service.name | `praefect` | 作成するサービスの名前 | +| service.type | ClusterIP | 作成するサービスの種類 | +| service.internalPort | 8075 | Praefectポッドがリッスンする内部ポート番号 | +| service.externalPort | 8075 | Praefectサービスがクラスターで公開するポート番号 | +| init.resources | | | +| init.image | | | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスがその親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| extraEnvFrom | | 公開する他のデータソースからの追加の環境変数のリスト | +| logging.level | | ログレベル | +| logging.format | `json` | ログ形式 | +| logging.sentryDsn | | Sentry DSN URL - Goサーバーからの例外 | +| logging.sentryEnvironment | | ログの生成に使用するSentry環境 | +| `metrics.enabled` | `true` | メトリックエンドポイントをスクレイピングに使用できるようにするかどうか | +| `metrics.port` | `9236` | メトリックエンドポイントポート | +| `metrics.separate_database_metrics` | `true` | trueの場合、メトリクスのスクレイピングはデータベースクエリを実行しません。falseに設定すると、[パフォーマンスの問題が発生する可能性があります](https://gitlab.com/gitlab-org/gitaly/-/issues/3796) | +| `metrics.path` | `/metrics` | メトリックエンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | ServiceMonitorを作成してPrometheus Operatorがメトリクスのスクレイピングを管理できるようにするかどうか。これを有効にすると、`prometheus.io`スクレイピングアノテーションが削除されることに注意してください | +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加のラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント設定 | +| securityContext.runAsUser | 1000 | | +| securityContext.fsGroup | 1000 | | +| securityContext.fsGroupChangePolicy | | ボリュームの所有権と権限を変更するためのポリシー(Kubernetes 1.23が必要) | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが、その親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定しない場合、チャートのフルネームが使用されます | +| serviceLabels | `{}` | 補足のサービスラベル | +| statefulset.strategy | `{}` | statefulsetで使用される更新ストラテジを構成できます | + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これを有効にしないでください(たとえば、Istio)。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定しない場合、チャートのフルネームが使用されます。 | + +### アフィニティ {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/sidekiq/_index.md b/doc-locale/ja-jp/charts/gitlab/sidekiq/_index.md new file mode 100644 index 0000000000..a71da34c21 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/sidekiq/_index.md @@ -0,0 +1,684 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab-Sidekiqチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 製品:GitLab Self-Managed + +{{< /details >}} + +`sidekiq`サブチャートは、Sidekiqワーカーの構成可能なデプロイメントを提供します。これは、個々のスケーラビリティと構成を備えた複数の`Deployment`にわたるキューの分離を提供するように明示的に設計されています。 + +このチャートはデフォルトの`pods:`宣言を提供しますが、空の定義を提供すると、ワーカーは*ありません*。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされるKubernetesクラスターから到達可能な外部サービスとして、Redis、PostgreSQL、およびGitalyサービスへのアクセスに依存します。 + +## 設計上の選択 {#design-choices} + +このチャートは、複数の`Deployment`と関連する`ConfigMap`を作成します。コマンド長に関する懸念を回避するために、コンテナの`command`への`environment`属性または追加の引数を使用する代わりに、`ConfigMap`の動作を利用する方が明確であると判断されました。この選択により、多数の`ConfigMap`が作成されますが、各ポッドが何をする必要があるかについて非常に明確な定義が提供されます。 + +## 設定 {#configuration} + +`sidekiq`チャートは、チャート全体の[外部サービス](#external-services)、[チャート全体のデフォルト](#chart-wide-defaults)、および[ポッドごとの定義](#per-pod-settings)の3つの部分で構成されています。 + +## インストールコマンドラインオプション {#installation-command-line-options} + +以下の表に、`--set`フラグを使用して`helm install`コマンドに指定できるすべての可能なチャート設定を示します。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|--------------------------------------------------------------|-------------| +| `annotations` | | ポッドアノテーション | +| `podLabels` | | 補足的なポッドラベル。セレクターには使用されません。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される補足ラベル。 | +| `concurrency` | `20` | Sidekiqのデフォルトの並行処理 | +| `deployment.strategy` | `{}` | デプロイメントで使用される更新戦略を構成できます | +| `deployment.terminationGracePeriodSeconds` | `30` | ポッドが正常に終了するために必要なオプションの秒単位の時間。 | +| `enabled` | `true` | Sidekiqが有効なフラグ | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラルスタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `extraVolumeMounts` | | 構成する追加のボリュームマウントの文字列テンプレート | +| `extraVolumes` | | 構成する追加のボリュームの文字列テンプレート | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `gitaly.serviceName` | `gitaly` | Gitalyサービス名 | +| `health_checks.port` | `3808` | ヘルスチェックサーバーのポート | +| `hpa.behaviour` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、アップスケールとダウンスケールの動作の仕様が含まれています（`autoscaling/v2beta2`以上が必要です）。 | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、目的のレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`で構成された平均CPU使用率のデフォルトの使用を上書きします）。 | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | `350m` | オートスケールCPUターゲット値を設定します | +| `hpa.cpu.targetAverageUtilization` | | オートスケールCPUターゲット使用率を設定します | +| `hpa.memory.targetType` | | オートスケールメモリーターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリーターゲット値を設定します | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリーターゲット使用率を設定します | +| `hpa.targetAverageValue` | | **非推奨**オートスケールCPUターゲット値を設定します | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | 最後のアクティブと報告されたトリガーの後にリソースを0にスケールバックするまで待機する期間 | +| `keda.minReplicaCount` | | KEDAがリソースをスケールダウンする最小レプリカ数。デフォルトは`minReplicas`です | +| `keda.maxReplicaCount` | | KEDAがリソースをスケールアップする最大レプリカ数。デフォルトは`maxReplicas`です | +| `keda.fallback` | | KEDAフォールバック構成。ドキュメント[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | | KEDAが作成するHPAリソースの名前。デフォルトは`keda-hpa-{scaled-object-name}`です | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | | アップスケールとダウンスケールの動作の仕様。デフォルトは`hpa.behavior`です | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。デフォルトは、`hpa.cpu`および`hpa.memory`から計算されたトリガーです | +| `minReplicas` | `2` | レプリカの最小数 | +| `maxReplicas` | `10` | レプリカの最大数 | +| `maxUnavailable` | `1` | 使用できないポッドの最大数の制限 | +| `image.pullPolicy` | `Always` | Sidekiqイメージのプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ee` | Sidekiqイメージリポジトリ | +| `image.tag` | | Sidekiqイメージタグ | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージタグ | +| `init.containerSecurityContext` | | initContainer固有の[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.runAsUser` | `1000` | initContainer固有:コンテナを開始するユーザーID | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナをroot以外のユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `logging.format` | `json` | JSON以外のログの場合は`text`に設定します | +| `metrics.enabled` | `true` | スクレイピングに使用できるメトリクスエンドポイントを作成する必要がある場合 | +| `metrics.port` | `3807` | メトリクスエンドポイントポート | +| `metrics.path` | `/metrics` | メトリクスエンドポイントのパス | +| `metrics.log_enabled` | `false` | `sidekiq_exporter.log`に書き込まれたメトリクスサーバーログを有効または無効にします | +| `metrics.podMonitor.enabled` | `false` | Prometheus Operatorがメトリクスのスクレイピングを管理できるようにするために、PodMonitorを作成する必要がある場合 | +| `metrics.podMonitor.additionalLabels` | `{}` | PodMonitorに追加する追加のラベル | +| `metrics.podMonitor.endpointConfig` | `{}` | PodMonitorの追加のエンドポイント構成 | +| `metrics.annotations` | | **非推奨**明示的なメトリクスアノテーションを設定します。テンプレートコンテンツに置き換えられました。 | +| `metrics.tls.enabled` | `false` | `metrics/sidekiq_exporter`エンドポイントに対してTLSが有効になっています | +| `metrics.tls.secretName` | `{Release.Name}-sidekiq-metrics-tls` | `metrics/sidekiq_exporter`エンドポイントTLS証明書とキーのシークレット | +| `psql.password.key` | `psql-password` | psqlシークレットのpsqlパスワードへのキー | +| `psql.password.secret` | `gitlab-postgres` | psqlパスワードシークレット | +| `psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`よりも優先されます | +| `redis.serviceName` | `redis` | Redisサービス名 | +| `resources.requests.cpu` | `900m` | Sidekiqに必要な最小CPU | +| `resources.requests.memory` | `2G` | Sidekiqに必要な最小限のメモリ | +| `resources.limits.memory` | | Sidekiqが許可する最大メモリ | +| `timeout` | `25` | Sidekiqジョブのタイムアウト | +| `tolerations` | `[]` | ポッド割り当ての容認ラベル | +| `memoryKiller.daemonMode` | `true` | `false`の場合、レガシーメモリーキラーモードを使用します | +| `memoryKiller.maxRss` | `2000000` | 遅延シャットダウンがトリガーされる前の最大RSS（キロバイト単位） | +| `memoryKiller.graceTime` | `900` | トリガーされたシャットダウン前に待機する時間（秒単位） | +| `memoryKiller.shutdownWait` | `30` | 既存のジョブが終了するために、トリガーされたシャットダウン後に経過する時間（秒単位） | +| `memoryKiller.hardLimitRss` | | デーモンモードで即時シャットダウンがトリガーされる前の最大RSS（キロバイト単位） | +| `memoryKiller.checkInterval` | `3` | メモリーチェック間の時間 | +| `livenessProbe.initialDelaySeconds` | `20` | 活性プローブが開始されるまでの遅延 | +| `livenessProbe.periodSeconds` | `60` | 活性プローブを実行する頻度 | +| `livenessProbe.timeoutSeconds` | `30` | 活性プローブがタイムアウトするタイミング | +| `livenessProbe.successThreshold` | `1` | 失敗後に活性プローブが成功したと見なされるための最小連続成功数 | +| `livenessProbe.failureThreshold` | `3` | 成功後に活性プローブが失敗したと見なされるための最小連続失敗数 | +| `readinessProbe.initialDelaySeconds` | `0` | 準備プローブが開始されるまでの遅延 | +| `readinessProbe.periodSeconds` | `10` | 準備プローブを実行する頻度 | +| `readinessProbe.timeoutSeconds` | `2` | 準備プローブがタイムアウトするタイミング | +| `readinessProbe.successThreshold` | `1` | 失敗後に準備プローブが成功したと見なされるための最小連続成功数 | +| `readinessProbe.failureThreshold` | `3` | 成功後に準備プローブが失敗したと見なされるための最小連続失敗数 | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要です） | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナの開始に使用されるオーバーライドコンテナ[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `containerSecurityContext.runAsUser` | `1000` | コンテナの開始に使用される特定のセキュリティコンテキストを上書きできます | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナをroot以外のユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.annotations` | `{}` | ServiceAccountアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定されていない場合、完全なチャート名が使用されます | +| `priorityClassName` | `""` | ポッドの`priorityClassName`の設定を許可します。これは、削除の場合にポッドの優先度を制御するために使用されます | + +## チャート設定の例 {#chart-configuration-examples} + +### リソース {#resources} + +`resources`を使用すると、Sidekiqポッドが消費できるリソース（メモリーと仮想CPU）の最小量と最大量を構成できます。 + +Sidekiqポッドのワークロードは、デプロイメントによって大きく異なります。一般的に言って、各Sidekiqプロセスは約1つの仮想CPUと2 GiBのメモリーを消費すると理解されています。垂直方向のスケーリングは、通常、この`vCPU:Memory`の`1:2`比率に合わせる必要があります。 + +以下は、`resources`の使用例です: + +```yaml +resources: + limits: + memory: 5G + requests: + memory: 2G + cpu: 900m +``` + +### extraEnv {#extraenv} + +`extraEnv`を使用すると、依存関係コンテナに追加の環境変数を公開できます。 + +以下は、`extraEnv`の使用例です: + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナの起動時に、環境変数が公開されていることを確認できます: + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +特定のポッドに対して`extraEnv`を設定することもできます: + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +pods: + - name: mailers + queues: mailers + extraEnv: + SOME_POD_KEY: some_pod_value + - name: catchall +``` + +これにより、`mailers`ポッド内のアプリケーションコンテナに対してのみ`SOME_POD_KEY`が設定されます。ポッドレベルの`extraEnv`設定は、[initコンテナ](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)に追加されません。 + +### extraEnvFrom {#extraenvfrom} + +`extraEnvFrom`を使用すると、ポッド内のすべてのコンテナ内の他のデータソースから追加の環境変数を公開できます。後続の変数は、Sidekiqポッドごとに上書きできます。 + +以下は、`extraEnvFrom`の使用例です: + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean +pods: + - name: immediate + extraEnvFrom: + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### extraVolumes {#extravolumes} + +`extraVolumes`を使用すると、チャート全体の追加ボリュームを構成できます。 + +以下は、`extraVolumes`の使用例です: + +```yaml +extraVolumes: | + - name: example-volume + persistentVolumeClaim: + claimName: example-pvc +``` + +### extraVolumeMounts {#extravolumemounts} + +`extraVolumeMounts`を使用すると、チャート全体のすべてのコンテナで追加のvolumeMountsを構成できます。 + +以下は、`extraVolumeMounts`の使用例です: + +```yaml +extraVolumeMounts: | + - name: example-volume-mount + mountPath: /etc/example +``` + +### image.pullSecrets {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに対して認証して、ポッドのイメージをプルできます。 + +プライベートレジストリとその認証方法の詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)を参照してください。 + +以下は、`pullSecrets`の使用例です: + +```yaml +image: + repository: my.sidekiq.repository + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### serviceAccount {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これは有効にしないでください（たとえば、Istio）。 | +| `create` | ブール値 | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | 文字列 | | ServiceAccountの名前。設定されていない場合、完全なチャート名が使用されます。 | + +### 許容 {#tolerations} + +`tolerations`を使用すると、tainted workerノードでポッドをスケジュールできます + +以下は、`tolerations`の使用例です: + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### アノテーション {#annotations} + +`annotations`を使用すると、Sidekiqポッドにアノテーションを追加できます。 + +以下は、`annotations`の使用例です: + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +## このチャートのCommunity Editionの使用 {#using-the-community-edition-of-this-chart} + +デフォルトでは、HelmチャートはGitLab Enterprise Editionを使用します。必要に応じて、代わりにCommunity Editionを使用できます。[2つの違い](https://about.gitlab.com/install/ce-or-ee/)について詳しくはこちらをご覧ください。 + +Community Editionを使用するには、`image.repository`を`registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ce`に設定します。 + +## 外部サービス {#external-services} + +このチャートは、Webサービスチャートと同じRedis、PostgreSQL、およびGitalyインスタンスにアタッチする必要があります。外部サービスの値は、すべてのSidekiqポッド間で共有される`ConfigMap`に入力されます。 + +### Redis {#redis} + +```yaml +redis: + host: rank-racoon-redis + port: 6379 + sentinels: + - host: sentinel1.example.com + port: 26379 + password: + secret: gitlab-redis + key: redis-password +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------------|:-------:|:--------|:------------| +| `host` | 文字列 | | 使用するデータベースを持つRedisサーバーのホスト名。これは、`serviceName`の代わりに使用できます。Redis Sentinelを使用している場合、`host`属性は、`sentinel.conf`で指定されているクラスター名に設定する必要があります。 | +| `password.key` | 文字列 | | Redisの`password.key`属性は、パスワードを含むシークレット（下記）のキーの名前を定義します。 | +| `password.secret` | 文字列 | | Redisの`password.secret`属性は、プル元のKubernetes `Secret`の名前を定義します。 | +| `port` | 整数 | `6379` | Redisサーバーに接続するポート。 | +| `serviceName` | 文字列 | `redis` | Redisデータベースを操作している`service`の名前。これが存在し、`host`が存在しない場合、チャートは`host`値の代わりにサービス（および現在の`.Release.Name`）のホスト名をテンプレート化します。これは、RedisをGitLabチャート全体の一部として使用する場合に便利です。 | +| `sentinels.[].host` | 文字列 | | Redis HAセットアップ用のRedis Sentinelサーバーのホスト名。 | +| `sentinels.[].port` | 整数 | `26379` | Redis Sentinelサーバーに接続するポート。 | + +{{< alert type="note" >}} + +現在のRedis Sentinelサポートは、GitLabチャートとは別にデプロイされたSentinelのみをサポートします。その結果、GitLabチャートを介したRedisのデプロイメントは、`redis.install=false`で無効にする必要があります。Redisパスワードを含むシークレットは、GitLabチャートをデプロイする前に手動で作成する必要があります。 + +{{< /alert >}} + +### PostgreSQL {#postgresql} + +```yaml +psql: + host: rank-racoon-psql + serviceName: pgbouncer + port: 5432 + database: gitlabhq_production + username: gitlab + preparedStatements: false + password: + secret: gitlab-postgres + key: psql-password +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:---------------------|:-------:|:----------------------|:------------| +| `host` | 文字列 | | 使用するデータベースを持つPostgreSQLサーバーのホスト名。これは、`postgresql.install=true`（デフォルトの非本番環境）の場合に省略できます。 | +| `serviceName` | 文字列 | | PostgreSQLデータベースを操作している`service`の名前。これが存在し、`host`が存在しない場合、チャートは`host`値の代わりにサービスのホスト名をテンプレート化します。 | +| `database` | 文字列 | `gitlabhq_production` | PostgreSQLサーバーで使用するデータベースの名前。 | +| `password.key` | 文字列 | | PostgreSQLの`password.key`属性は、パスワードを含むシークレット内のキーの名前を定義します（下記参照）。 | +| `password.secret` | 文字列 | | PostgreSQLの`password.secret`属性は、プル元のKubernetes `Secret`の名前を定義します。 | +| `port` | 整数 | `5432` | PostgreSQLサーバーへの接続に使用するポート。 | +| `username` | 文字列 | `gitlab` | データベースへの認証に使用するユーザー名。 | +| `preparedStatements` | ブール値 | `false` | PostgreSQLサーバーとの通信時にプリペアドステートメントを使用するかどうか。 | + +### Gitaly {#gitaly} + +```YAML +gitaly: + internal: + names: + - default + - default2 + external: + - name: node1 + hostname: node1.example.com + port: 8079 + authToken: + secret: gitaly-secret + key: token +``` + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------|:-------:|:---------|:------------| +| `host` | 文字列 | | 使用するGitalyサーバー のホスト名。これは、`serviceName`の代わり省略できます。 | +| `serviceName` | 文字列 | `gitaly` | Gitalyサーバーを操作している`service`の名前。これが存在し、`host`が存在しない場合、このチャートは`host`値の代わりに、サービス（および現在の`.Release.Name`）のホスト名をテンプレート化します。これは、GitLabチャート全体の一部としてGitalyを使用する場合に便利です。 | +| `port` | 整数 | `8075` | Gitalyサーバーへの接続に使用するポート。 | +| `authToken.key` | 文字列 | | authTokenを含む以下のシークレット内のキーの名前。 | +| `authToken.secret` | 文字列 | | プル元のKubernetes `Secret`の名前。 | + +## メトリクス {#metrics} + +デフォルトでは、Prometheusメトリクスのexporterがポッドごとに有効になっています。[GitLab Prometheusメトリクス](https://docs.gitlab.com/administration/monitoring/prometheus/gitlab_metrics/)が管理者エリアで有効になっている場合にのみ、メトリクスを使用できます。exporterは、ポート`3807`の`/metrics`エンドポイントを公開します。メトリクスが有効になっている場合、Prometheusサーバーが公開されたメトリクスを検出してスクレイピングできるように、各ポッドにアノテーションが追加されます。 + +## チャート全体のデフォルト {#chart-wide-defaults} + +以下の値は、ポッドごとに値が表示されない場合に、チャート全体で使用されます。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------------------------|:-------:|:----------|:------------| +| `concurrency` | 整数 | `25` | 同時に処理するタスク数。 | +| `timeout` | 整数 | `4` | Sidekiqのシャットダウン・タイムアウト。SidekiqがTERMシグナルを受信してから、プロセスを強制的にシャットダウンするまでの秒数。 | +| `memoryKiller.checkInterval` | 整数 | `3` | メモリーチェックの間隔（秒単位） | +| `memoryKiller.maxRss` | 整数 | `2000000` | 遅延シャットダウンがトリガーされる前の最大RSS（キロバイト単位） | +| `memoryKiller.graceTime` | 整数 | `900` | トリガーされたシャットダウンの前に待機する時間（秒単位） | +| `memoryKiller.shutdownWait` | 整数 | `30` | トリガーされたシャットダウン後に既存のジョブが完了するまでの時間（秒単位） | +| `minReplicas` | 整数 | `2` | レプリカの最小数 | +| `maxReplicas` | 整数 | `10` | レプリカの最大数 | +| `maxUnavailable` | 整数 | `1` | 利用できなくなるポッドの最大数の制限 | + +{{< alert type="note" >}} + +[Sidekiqメモリーキラーの詳細なドキュメント](https://docs.gitlab.com/administration/sidekiq/sidekiq_memory_killer/)は、Linuxパッケージのドキュメントにあります。 + +{{< /alert >}} + +## ポッドごとの設定 {#per-pod-settings} + +`pods`宣言は、workerポッドのすべての属性の宣言を提供します。これらは`Deployment`にテンプレート化され、Sidekiqインスタンス用に個別の`ConfigMap`が設定されます。 + +{{< alert type="note" >}} + +設定はデフォルトで、すべてのキューを監視するように設定された単一のポッドが含まれます。podsセクションを変更すると、異なるポッド構成で*デフォルトのポッドが上書き*されます。デフォルトに加えて、新しいポッドが追加されることはありません。 + +{{< /alert >}} + +| 名前 | 種類 | デフォルト | 説明 | +|:--------------------------------------|:-------:|:---------------|:------------| +| `concurrency` | 整数 | | 同時に処理するタスク数。指定されていない場合、チャート全体のデフォルトからプルされます。 | +| `name` | 文字列 | | このポッドの`Deployment`と`ConfigMap`の命名に使用されます。短く保ち、2つのエントリ間で複製しないでください。 | +| `queues` | 文字列 | | [下記参照](#queues)。 | +| `timeout` | 整数 | | Sidekiqのシャットダウン・タイムアウト。SidekiqがTERMシグナルを受信してから、プロセスを強制的にシャットダウンするまでの秒数。指定されていない場合、チャート全体のデフォルトからプルされます。この値は、`terminationGracePeriodSeconds`より**小さく**する必要があります。 | +| `resources` | | | 各ポッドは独自の`resources`要件を示すことができ、存在する場合、これはそのために作成された`Deployment`に追加されます。これらは、Kubernetesドキュメントと一致します。 | +| `nodeSelector` | | | 各ポッドは`nodeSelector`属性で構成でき、存在する場合、そのために作成された`Deployment`に追加されます。これらの定義はKubernetesドキュメントと一致します。 | +| `memoryKiller.checkInterval` | 整数 | `3` | メモリーチェックの間隔 | +| `memoryKiller.maxRss` | 整数 | `2000000` | 特定のポッドの最大RSSをオーバーライドします。 | +| `memoryKiller.graceTime` | 整数 | `900` | 特定のポッドでトリガーされたシャットダウンの前に待機する時間をオーバーライドします | +| `memoryKiller.shutdownWait` | 整数 | `30` | 特定のポッドでトリガーされたシャットダウン後に既存のジョブを完了するまでの時間をオーバーライドします | +| `minReplicas` | 整数 | `2` | レプリカの最小数 | +| `maxReplicas` | 整数 | `10` | レプリカの最大数 | +| `maxUnavailable` | 整数 | `1` | 利用できなくなるポッドの最大数の制限 | +| `podLabels` | マップ | `{}` | 補足的なポッドのラベル。セレクターには使用されません。 | +| `strategy` | | `{}` | デプロイで使用される更新ストラテジを設定できます | +| `extraVolumes` | 文字列 | | 指定されたポッドの追加ボリュームを構成します。 | +| `extraVolumeMounts` | 文字列 | | 指定されたポッドの追加ボリュームマウントを構成します。 | +| `priorityClassName` | 文字列 | `""` | ポッドの`priorityClassName`の設定を許可します。これは、立ち退きが発生した場合にポッドの優先度を制御するために使用されます | +| `hpa.customMetrics` | 配列 | `[]` | カスタム メトリクスには、必要なレプリカ数を計算するために使用するが含まれます（`targetAverageUtilization`で構成された平均CPU使用率のデフォルトの使用を上書きします） | +| `hpa.cpu.targetType` | 文字列 | `AverageValue` | オートスケールCPUのターゲットをオーバーライドします。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | 文字列 | `350m` | オートスケールCPUのターゲット値を上書きします | +| `hpa.cpu.targetAverageUtilization` | 整数 | | オートスケールCPUのターゲット使用率をオーバーライドします | +| `hpa.memory.targetType` | 文字列 | | オートスケールメモリーのターゲットをオーバーライドします。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | 文字列 | | オートスケールメモリーのターゲット値を上書きします | +| `hpa.memory.targetAverageUtilization` | 整数 | | オートスケールメモリーのターゲット使用率を上書きします | +| `hpa.targetAverageValue` | 文字列 | | **非推奨**オートスケールCPUのターゲット値を上書きします | +| `keda.enabled` | ブール値 | `false` | KEDAの有効化をオーバーライドします | +| `keda.pollingInterval` | 整数 | `30` | KEDAポーリングの間隔をオーバーライドします | +| `keda.cooldownPeriod` | 整数 | `300` | KEDAのクールダウン期間をオーバーライドします | +| `keda.minReplicaCount` | 整数 | | KEDAがリソースをスケールダウンする最小レプリカ数をオーバーライドします。デフォルトはです | +| `keda.maxReplicaCount` | 整数 | | KEDAがリソースをスケールアップする最大レプリカ数をオーバーライドします。デフォルトはです | +| `keda.fallback` | マップ | | KEDAフォールバックをオーバーライドします。ドキュメントを参照してください | +| `keda.hpaName` | 文字列 | | KEDAが作成するHPAリソースの名前をオーバーライドします。デフォルトはです | +| `keda.restoreToOriginalReplicaCount` | ブール値 | | が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | マップ | | アップスケールとダウンスケールのの。デフォルトはです | +| `keda.triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。デフォルトはとから計算されたトリガーです | +| `extraEnv` | マップ | | 公開する追加の環境変数のリスト。チャート全体のがこれにマージされ、ポッドからのが優先されます | +| `extraEnvFrom` | マップ | | 公開する他のデータソースからの追加の環境変数のリスト | +| `terminationGracePeriodSeconds` | 整数 | `30` | ポッドが正常に終了するために必要なオプションの秒単位の期間。 | + +### キュー {#queues} + +`queues`値は、処理されるキューのコンマ区切りリストを含む文字列です。デフォルトでは設定されておらず、すべてのキューが処理されることを意味します。 + +文字列にスペースを含めないでください。`merge,post_receive,process_commit`は機能しますが、`merge, post_receive, process_commit`は機能しません。 + +ジョブが追加されたが、少なくとも1つのポッドアイテムの一部として表されていないキューは*処理されません*。すべてのキューの完全なリストについては、GitLabソースのこれらのファイルを参照してください。 + +1. [`app/workers/all_queues.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/workers/all_queues.yml) +1. [`ee/app/workers/all_queues.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/workers/all_queues.yml) + +`gitlab.sidekiq.pods[].queues`の設定に加えて、`global.appConfig.sidekiq.routingRules`も設定する必要があります。詳細については、[Sidekiqルーティング ルール設定](../../globals.md#sidekiq-routing-rules-settings)を参照してください。 + +### `pod`エントリの例 {#example-pod-entry} + +```YAML +pods: + - name: immediate + concurrency: 10 + minReplicas: 2 # defaults to inherited value + maxReplicas: 10 # defaults to inherited value + maxUnavailable: 5 # defaults to inherited value + queues: merge,post_receive,process_commit + extraVolumeMounts: | + - name: example-volume-mount + mountPath: /etc/example + extraVolumes: | + - name: example-volume + persistentVolumeClaim: + claimName: example-pvc + resources: + limits: + cpu: 800m + memory: 2Gi + hpa: + cpu: + targetType: Value + targetAverageValue: 350m +``` + +### Sidekiqの完全な例 {#full-example-of-sidekiq-configuration} + +以下は、インポート関連のジョブ用の個別のSidekiqポッド、個別のRedisインスタンスを使用するエクスポート関連のジョブ用のSidekiqポッド、およびその他すべてのジョブ用の別のポッドを使用した、Sidekiqの完全な例です。 + +```yaml +... +global: + appConfig: + sidekiq: + routingRules: + - ["feature_category=importers", "import"] + - ["feature_category=exporters", "export", "queues_shard_extra_shard"] + - ["*", "default"] + redis: + redisYmlOverride: + queues_shard_extra_shard: ... +... +gitlab: + sidekiq: + pods: + - name: import + queues: import + - name: export + queues: export + extraEnv: + SIDEKIQ_SHARD_NAME: queues_shard_extra_shard # to match key in global.redis.redisYmlOverride + - name: default +... +``` + +## `networkpolicy`の設定 {#configuring-the-networkpolicy} + +このセクションでは、[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を制御します。このはオプションであり、ポッドのエグレスとIngressを特定のエンドポイントに制限するために使用されます。 + +| 名前 | 種類 | デフォルト | 説明 | +|:------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | この設定により、ネットワークが有効になります | +| `ingress.enabled` | ブール値 | `false` | `true`に設定すると、`Ingress`ネットワークがアクティブになります。これにより、ルールが指定されていない限り、すべてのIngress接続がブロックされます。 | +| `ingress.rules` | 配列 | `[]` | Ingressのルール。詳細については、と以下の例を参照してください | +| `egress.enabled` | ブール値 | `false` | `true`に設定すると、`Egress`ネットワークがアクティブになります。これにより、ルールが指定されていない限り、すべてのエグレス接続がブロックされます。 | +| `egress.rules` | 配列 | `[]` | エグレスのルール。詳細については、と以下の例を参照してください | + +### ネットワークの例 {#example-network-policy} + +Sidekiqサービスは、有効になっている場合にPrometheus exporterのみにIngressを必要とし、通常はさまざまな場所へのエグレスを必要とします。この例では、次のネットワークを追加します。 + +- Ingressリクエストを許可します。 + - `Prometheus`ポッドからポート`3807`へ +- エグレスリクエストを許可します。 + - `kube-dns`からポート`53`へ + - `gitaly`ポッドからポート`8075`へ + - `registry`ポッドからポート`5000`へ + - `kas`ポッドからポート`8153`へ + - 外部データベース`172.16.0.10/32`からポート`5432`へ + - 外部Redis `172.16.0.11/32`からポート`6379`へ + - 外部Elasticsearch `172.16.0.12/32`からポート`443`へ + - メールゲートウェイ`172.16.0.13/32`からポート`587`へ + - S3またはSTSのAWS VPCのようなへ`172.16.1.0/24`ポート`443` + - 内部サブネット`172.16.2.0/24`からポート`443`にWebhookを送信する + +*提供されている例は単なる例であり、完全ではない可能性があることに注意してください* + +{{< alert type="note" >}} + +Sidekiqサービスには、ローカルが利用できない場合、[外部オブジェクトストレージ](../../../advanced/external-object-storage)上のイメージへのパブリックインターネットへのアウトバウンドが必要です。 + +{{< /alert >}} + +この例は、`kube-dns`が`kube-system`に、`prometheus`が`monitoring`に、`nginx-ingress`が`nginx-ingress`にデプロイされたという前提に基づいています。 + +```yaml +networkpolicy: + enabled: true + ingress: + enabled: true + rules: + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: monitoring + podSelector: + matchLabels: + app: prometheus + component: server + release: gitlab + ports: + - port: 3807 + egress: + enabled: true + rules: + - to: + - podSelector: + matchLabels: + app: gitaly + ports: + - port: 8075 + - to: + - podSelector: + matchLabels: + app: kas + ports: + - port: 8153 + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + podSelector: + matchLabels: + k8s-app: kube-dns + ports: + - port: 53 + protocol: UDP + - to: + - ipBlock: + cidr: 172.16.0.10/32 + ports: + - port: 5432 + - to: + - ipBlock: + cidr: 172.16.0.11/32 + ports: + - port: 6379 + - to: + - ipBlock: + cidr: 172.16.0.12/32 + ports: + - port: 25 + - to: + - ipBlock: + cidr: 172.16.0.13/32 + ports: + - port: 443 + - to: + - ipBlock: + cidr: 172.16.1.0/24 + ports: + - port: 443 + - to: + - ipBlock: + cidr: 172.16.2.0/24 + ports: + - port: 443 +``` + +## KEDAの設定 {#configuring-keda} + +この`keda`セクションでは、[KEDA](https://keda.sh/) `ScaledObjects`のインストールを、通常の`HorizontalPodAutoscalers`の代わりに行います。このはオプションであり、カスタムメトリクスまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。 + +ほとんどのは、該当する場合、`hpa`セクションで設定されたにデフォルト設定されます。 + +以下がtrueの場合、CPUおよびメモリーのトリガーは、`hpa`セクションで設定されたCPUおよびメモリーのに基づいて自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`設定もゼロ以外のに設定されています。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらのの詳細については、[KEDAドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | 種類 | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用する | +| `pollingInterval` | 整数 | `30` | 各トリガーをチェックする間隔 | +| `cooldownPeriod` | 整数 | `300` | 最後のアクティブなトリガーがされてから、リソースを0にスケールバックするまで待機する期間 | +| `minReplicaCount` | 整数 | | KEDAがリソースをスケールダウンする最小レプリカ数。デフォルトは`minReplicas`です | +| `maxReplicaCount` | 整数 | | KEDAがリソースをスケールアップする最大レプリカ数。デフォルトは`maxReplicas`です | +| `fallback` | マップ | | KEDAフォールバック、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | 文字列 | | KEDAが作成するHPAリソースの名前。デフォルトは`keda-hpa-{scaled-object-name}` | +| `restoreToOriginalReplicaCount` | ブール値 | | ターゲットが、`ScaledObject`削除後に元の数にスケールバックされるかどうかを指定します | +| `behavior` | | | アップスケーリングとダウンスケーリングの。デフォルトは`hpa.behavior`です。 | +| `triggers` | | | ターゲットのをアクティブにするのリスト。デフォルトは`hpa.cpu`と`hpa.memory`からされたです | diff --git a/doc-locale/ja-jp/charts/gitlab/spamcheck/_index.md b/doc-locale/ja-jp/charts/gitlab/spamcheck/_index.md new file mode 100644 index 0000000000..e1faf49f25 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/spamcheck/_index.md @@ -0,0 +1,216 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab-Spamcheckチャートの使用 +--- + +{{< details >}} + +- プラン:Premium, Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`spamcheck`サブチャートは、[Spamcheck](https://gitlab.com/gitlab-org/spamcheck)のデプロイを提供します。これは、GitLab.comでのスパムの増加に対抗するためにGitLabによって開発され、後にGitLab Self-Managedで使用するために公開されたアンチスパムエンジンです。 + +## 要件 {#requirements} + +このチャートは、GitLab APIへのアクセスに依存します。 + +## 設定 {#configuration} + +### Spamcheckの有効化 {#enable-spamcheck} + +`spamcheck`はデフォルトで無効になっています。GitLabインスタンスで有効にするには、Helmプロパティ`global.spamcheck.enabled`を`true`に設定します。例: + +```shell +helm upgrade --force --install gitlab . \ +--set global.hosts.domain='your.domain.com' \ +--set global.hosts.externalIP=XYZ.XYZ.XYZ.XYZ \ +--set certmanager-issuer.email='me@example.com' \ +--set global.spamcheck.enabled=true +``` + +### Spamcheckを使用するようにGitLabを設定する {#configure-gitlab-to-use-spamcheck} + +1. 左側のサイドバーの下部にある**管理者エリア**を選択します。 +1. **設定 > レポート**を選択します。 +1. **スパムとアンチボット対策**を展開します。 +1. スパムチェックの設定を更新します。 + 1. \[外部APIエンドポイント経由でスパムチェックを有効にする]チェックボックスをオンにします + 1. 外部スパムチェックエンドポイントのURLには`grpc://gitlab-spamcheck.default.svc:8001`を使用します。`default`は、GitLabがデプロイされているKubernetesネームスペースに置き換えられます。 + 1. 「スパムチェックAPIキー」は空白のままにします。 +1. **変更の保存**を選択します。 + +## インストール コマンドライン オプション {#installation-command-line-options} + +以下のテーブルには、`helm install`コマンドに`--set`フラグを使用して指定できる、すべての可能なチャート設定が含まれています。 + +| パラメータ | デフォルト | 説明 | +|-------------------------------------------------|------------------------------------------------------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | `{}` | ポッドアノテーション | +| `common.labels` | `{}` | このチャートによってCreateされたすべてのオブジェクトに適用される追加のラベル。 | +| `deployment.livenessProbe.initialDelaySeconds` | `20` | livenessProbeが開始されるまでの遅延 | +| `deployment.livenessProbe.periodSeconds` | `60` | livenessProbeを実行する頻度 | +| `deployment.livenessProbe.timeoutSeconds` | `30` | livenessProbeがタイムアウトしたとき | +| `deployment.livenessProbe.successThreshold` | `1` | livenessProbeが失敗した後、成功したとみなされるための最小連続成功数 | +| `deployment.livenessProbe.failureThreshold` | `3` | livenessProbeが成功した後、失敗したとみなされるための最小連続失敗数 | +| `deployment.readinessProbe.initialDelaySeconds` | `0` | readinessProbeが開始されるまでの遅延 | +| `deployment.readinessProbe.periodSeconds` | `10` | readinessProbeを実行する頻度 | +| `deployment.readinessProbe.timeoutSeconds` | `2` | readinessProbeがタイムアウトしたとき | +| `deployment.readinessProbe.successThreshold` | `1` | readinessProbeが失敗した後、成功したとみなされるための最小連続成功数 | +| `deployment.readinessProbe.failureThreshold` | `3` | readinessProbeが成功した後、失敗したとみなされるための最小連続失敗数 | +| `deployment.strategy` | `{}` | デプロイで使用される更新ストラテジーをConfigureできます。指定しない場合、クラスターのデフォルトが使用されます。 | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、アップスケールおよびダウンスケールBehaviorの仕様が含まれています（`autoscaling/v2beta2`以降が必要です）。 | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、目的のレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`でConfigureされた平均CPU使用率のデフォルト使用をオーバーライドします）。 | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | `100m` | オートスケールCPUターゲット値を設定します | +| `hpa.cpu.targetAverageUtilization` | | オートスケールCPUターゲット使用率を設定します | +| `hpa.memory.targetType` | | オートスケールメモリターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリターゲット値を設定します | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリターゲット使用率を設定します | +| `hpa.targetAverageValue` | | **非推奨**オートスケールCPUターゲット値を設定します | +| `image.registry` | | Spamcheckイメージレジストリ | +| `image.repository` | `registry.gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/spam/spamcheck` | Spamcheckイメージリポジトリ | +| `image.tag` | | Spamcheckイメージtag | +| `image.digest` | | Spamcheckイメージdigest | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | リソースを0にスケールバックする前に、最後のアクティブとレポートされたトリガーの後に待機する期間 | +| `keda.minReplicaCount` | `hpa.minReplicas` | KEDAがリソースをスケールダウンする最小レプリカ数。 | +| `keda.maxReplicaCount` | `hpa.maxReplicas` | KEDAがリソースをスケールアップする最大レプリカ数。 | +| `keda.fallback` | | KEDA [フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)設定については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAがCreateするHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | アップスケールおよびダウンスケールBehaviorの仕様。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`および`hpa.memory`からコンピュートされたトリガーにデフォルト設定されます | +| `logging.level` | `info` | ログレベル | +| `maxReplicas` | `10` | HPA `maxReplicas` | +| `maxUnavailable` | `1` | HPA `maxUnavailable` | +| `minReplicas` | `2` | HPA `maxReplicas` | +| `podLabels` | `{}` | 補足Podラベル。セレクターには使用されません。 | +| `resources.requests.cpu` | `100m` | Spamcheck最小CPU | +| `resources.requests.memory` | `100M` | Spamcheck最小メモリ | +| `securityContext.fsGroup` | `1000` | Podを開始するグループID | +| `securityContext.runAsUser` | `1000` | Podを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23が必要) | +| `serviceLabels` | `{}` | サービスの補足ラベル | +| `service.externalPort` | `8001` | Spamcheck外部ポート | +| `service.internalPort` | `8001` | Spamcheck内部ポート | +| `service.type` | `ClusterIP` | Spamcheckサービス タイプ | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをPodにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountをCreateするかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `tolerations` | `[]` | Pod割り当てのTolerationラベル | +| `extraEnvFrom` | `{}` | 公開する他のデータソースからの追加の環境変数のリスト | +| `priorityClassName` | | [ポッド](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)に割り当てられた[優先](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)クラス。 | + +## KEDAのConfigure {#configuring-keda} + +この`keda`セクションでは、通常の`HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`のインストールを有効にします。この設定はオプションであり、カスタムメトリクスまたは外部メトリクスに基づいてオートスケールが必要な場合に使用できます。 + +ほとんどの設定は、該当する場合、`hpa`セクションで設定された値にデフォルト設定されます。 + +以下が当てはまる場合、`hpa`セクションで設定されたCPUおよびメモリしきい値に基づいて、CPUおよびメモリトリガーが自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`設定も、ゼロ以外の値に設定されています。 + +トリガーが設定されていない場合、`ScaledObject`はCreateされません。 + +これらの[設定](https://keda.sh/docs/2.10/concepts/scaling-deployments/)の詳細については、KEDAドキュメントを参照してください。 + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | ブール値 | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `pollingInterval` | 整数 | `30` | 各トリガーをチェックする間隔 | +| `cooldownPeriod` | 整数 | `300` | リソースを0にスケールバックする前に、最後のアクティブとレポートされたトリガーの後に待機する期間 | +| `minReplicaCount` | 整数 | `hpa.minReplicas` | KEDAがリソースをスケールダウンする最小レプリカ数。 | +| `maxReplicaCount` | 整数 | `hpa.maxReplicas` | KEDAがリソースをスケールアップする最大レプリカ数。 | +| `fallback` | マップ | | KEDA [フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)設定については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `hpaName` | 文字列 | `keda-hpa-{scaled-object-name}` | KEDAがCreateするHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | ブール値 | | `ScaledObject`が削除された後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | `hpa.behavior` | アップスケールおよびダウンスケールBehaviorの仕様。 | +| `triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`および`hpa.memory`からコンピュートされたトリガーにデフォルト設定されます | + +## チャート設定の例 {#chart-configuration-examples} + +### `serviceAccount` {#serviceaccount} + +このセクションでは、ServiceAccountをCreateするかどうか、およびデフォルトのアクセストークンをPodにマウントするかどうかを制御します。 + +| 名前 | タイプ | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをPodにマウントするかどうかを制御します。特定のサイドカーが正常に動作するためにこれが必要な場合を除き（たとえば、Istio）、これを有効にしないでください。 | +| `create` | ブール値 | `false` | ServiceAccountをCreateするかどうかを示します。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | + +### Toleration {#tolerations} + +`tolerations`を使用すると、taintされたworkerノードでPodをスケジュールできます + +以下は、`tolerations`の使用例です: + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### アフィニティ {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 + +### アノテーション {#annotations} + +`annotations`を使用すると、Spamcheck Podにアノテーションを追加できます。次に例を示します。 + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +### リソース {#resources} + +`resources`を使用すると、Spamcheck Podが消費できるリソース（メモリとCPU）の最小量と最大量をConfigureできます。 + +次に例を示します。 + +```yaml +resources: + requests: + memory: 100m + cpu: 100M +``` + +### livenessProbe/readinessProbe {#livenessprobereadinessprobe} + +`deployment.livenessProbe`および`deployment.readinessProbe`は、コンテナが破損状態にある場合など、特定のシナリオでSpamcheck Podの終了を制御するのに役立つメカニズムを提供します。 + +次に例を示します。 + +```yaml +deployment: + livenessProbe: + initialDelaySeconds: 10 + periodSeconds: 20 + timeoutSeconds: 3 + successThreshold: 1 + failureThreshold: 10 + readinessProbe: + initialDelaySeconds: 10 + periodSeconds: 5 + timeoutSeconds: 2 + successThreshold: 1 + failureThreshold: 3 +``` + +この[設定](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)に関する追加の詳細については、公式のKubernetesドキュメントを参照してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/toolbox/_index.md b/doc-locale/ja-jp/charts/gitlab/toolbox/_index.md new file mode 100644 index 0000000000..4cf968683f --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/toolbox/_index.md @@ -0,0 +1,202 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Toolbox +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +Toolboxポッドは、GitLabアプリケーション内で定期的なハウスキーピングタスクを実行するために使用されます。これらのタスクには、バックアップ、Sidekiqのメンテナンス、Rakeタスクが含まれます。 + +## 設定 {#configuration} + +次の設定は、Toolboxチャートによって提供されるデフォルト設定です。 + +```yaml +gitlab: + ## doc/charts/gitlab/toolbox + toolbox: + enabled: true + replicas: 1 + backups: + cron: + enabled: false + concurrencyPolicy: Replace + failedJobsHistoryLimit: 1 + schedule: "0 1 * * *" + successfulJobsHistoryLimit: 3 + suspend: false + backoffLimit: 6 + safeToEvict: false + restartPolicy: "OnFailure" + resources: + requests: + cpu: 50m + memory: 350M + persistence: + enabled: false + accessMode: ReadWriteOnce + useGenericEphemeralVolume: false + size: 10Gi + objectStorage: + backend: s3 + config: {} + persistence: + enabled: false + accessMode: 'ReadWriteOnce' + size: '10Gi' + resources: + requests: + cpu: '50m' + memory: '350M' + securityContext: + fsGroup: '1000' + runAsUser: '1000' + runAsGroup: '1000' + containerSecurityContext: + runAsUser: '1000' + affinity: {} +``` + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|--------------------------------------------------------------|-------------| +| `affinity` | `{}` | ポッド割り当ての[アフィニティルール](../_index.md#affinity) | +| `annotations` | `{}` | Toolboxポッドおよびジョブに追加するアノテーション | +| `common.labels` | `{}` | このチャートで作成されたすべてのオブジェクトに適用される追加のラベル。 | +| `antiAffinityLabels.matchLabels` | | アンチアフィニティオプションを設定するためのラベル | +| `backups.cron.activeDeadlineSeconds` | `null` | バックアップCronジョブのアクティブなデッドライン秒数（nullの場合、アクティブなデッドラインは適用されません） | +| `backups.cron.ttlSecondsAfterFinished` | `null` | バックアップCronジョブが完了後に存続する時間（nullの場合、time to liveは適用されません） | +| `backups.cron.safeToEvict` | `false` | オートスケール対応のsafe-to-evictアノテーション | +| `backups.cron.backoffLimit` | `6` | バックアップCronジョブのバックオフ制限 | +| `backups.cron.concurrencyPolicy` | `Replace` | Kubernetesジョブの並行処理ポリシー | +| `backups.cron.enabled` | `false` | バックアップCronジョブの有効フラグ | +| `backups.cron.extraArgs` | | バックアップユーティリティに渡す引数の文字列 | +| `backups.cron.failedJobsHistoryLimit` | `1` | 履歴に表示する失敗したバックアップジョブの数 | +| `backups.cron.persistence.accessMode` | `ReadWriteOnce` | バックアップcronの永続性アクセスモード | +| `backups.cron.persistence.enabled` | `false` | バックアップcronの永続性を有効にするフラグ | +| `backups.cron.persistence.matchExpressions` | | バインドするラベル式のマッチ | +| `backups.cron.persistence.matchLabels` | | バインドするラベル値のマッチ | +| `backups.cron.persistence.useGenericEphemeralVolume` | `false` | [汎用的な一時ボリューム](https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes)を使用する | +| `backups.cron.persistence.size` | `10Gi` | バックアップcronの永続ボリュームサイズ | +| `backups.cron.persistence.storageClass` | | プロビジョニング用のStorageClass名 | +| `backups.cron.persistence.subPath` | | バックアップcronの永続ボリュームのマウントパス | +| `backups.cron.persistence.volumeName` | | 既存の永続ボリューム名 | +| `backups.cron.resources.requests.cpu` | `50m` | バックアップcronに必要な最小CPU | +| `backups.cron.resources.requests.memory` | `350M` | バックアップcronに必要な最小メモリ | +| `backups.cron.restartPolicy` | `OnFailure` | バックアップcronの再起動ポリシー（`Never`または`OnFailure`） | +| `backups.cron.schedule` | `0 1 * * *` | Cron形式のスケジュール文字列 | +| `backups.cron.startingDeadlineSeconds` | `null` | バックアップcronジョブの開始デッドライン（秒単位）（nullの場合、開始デッドラインは適用されません） | +| `backups.cron.successfulJobsHistoryLimit` | `3` | 履歴に表示する成功したバックアップジョブの数 | +| `backups.cron.suspend` | `false` | バックアップcronジョブは一時停止されます | +| `backups.cron.timeZone` | `""` | バックアップスケジュールのタイムゾーン。詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#time-zones)を参照してください。指定しない場合、クラスターのタイムゾーンを使用します。 | +| `backups.cron.tolerations` | `""` | バックアップcronジョブに追加するToleration | +| `backups.cron.nodeSelector` | `""` | バックアップcronジョブのノード選択 | +| `backups.objectStorage.backend` | `s3` | 使用するオブジェクトストレージプロバイダー（`s3`、`gcs`、または`azure`） | +| `backups.objectStorage.config.gcpProject` | `""` | バックエンドが`gcs`の場合に使用するGCPプロジェクト | +| `backups.objectStorage.config.key` | `""` | シークレットに認証情報を含むキー | +| `backups.objectStorage.config.secret` | `""` | オブジェクトストレージの認証情報のシークレット | +| `common.labels` | `{}` | このチャートで作成されたすべてのオブジェクトに適用される追加のラベル。 | +| `deployment.strategy` | ``{ `type`: `Recreate` }`` | デプロイメントで使用される更新ストラテジを構成できます | +| `enabled` | `true` | Toolboxの有効化フラグ | +| `extra` | `{}` | [追加の`gitlab.yml`設定](https://gitlab.com/gitlab-org/gitlab/-/blob/8d2b59dbf232f17159d63f0359fa4793921896d5/config/gitlab.yml.example#L1193-1199)のYAMLブロック | +| `image.pullPolicy` | `IfNotPresent` | Toolboxイメージのプルポリシー | +| `image.pullSecrets` | | Toolboxイメージプルシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ee` | Toolboxイメージリポジトリ | +| `image.tag` | `master` | Toolboxイメージタグ | +| `init.image.repository` | | Toolbox initイメージリポジトリ | +| `init.image.tag` | | Toolbox initイメージタグ | +| `init.resources` | ``{ `requests`: { `cpu`: `50m` }}`` | Toolbox initコンテナのリソース要件 | +| `init.containerSecurityContext` | | initContainer固有の[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsUser` | `1000` | initContainer固有:コンテナを開始するユーザーID | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `nodeSelector` | | Toolboxおよびバックアップジョブのノード選択 | +| `persistence.accessMode` | `ReadWriteOnce` | Toolboxの永続性アクセスモード | +| `persistence.enabled` | `false` | Toolboxの永続性を有効にするフラグ | +| `persistence.matchExpressions` | | バインドするラベル式のマッチ | +| `persistence.matchLabels` | | バインドするラベル値のマッチ | +| `persistence.size` | `10Gi` | Toolboxの永続ボリュームサイズ | +| `persistence.storageClass` | | プロビジョニング用のStorageClass名 | +| `persistence.subPath` | | Toolboxの永続ボリュームのマウントパス | +| `persistence.volumeName` | | 既存のPersistentVolume名 | +| `podLabels` | `{}` | Toolboxポッドを実行するためのラベル | +| `priorityClassName` | | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | +| `replicas` | `1` | 実行するToolboxポッドの数 | +| `resources.requests` | ``{ `cpu`: `50m`, `memory`: `350M` }`` | Toolboxに必要な最小リソース | +| `securityContext.fsGroup` | `1000` | ポッドを開始するファイルシステムグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.runAsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー（Kubernetes 1.23が必要です） | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナを開始するコンテナの[セキュリティコンテキスト](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)を上書きします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナを開始する特定のセキュリティコンテキストの上書きを許可します | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.annotations` | `{}` | ServiceAccountのアノテーション | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定しない場合、チャート名全体が使用されます | +| `tolerations` | | Toolboxに追加するToleration | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | + +## バックアップの設定 {#configuring-backups} + +[バックアップと復元に関するドキュメント](../../../backup-restore/_index.md)でのバックアップの設定に関する情報。バックアップの実行方法に関する技術的な実装に関する追加情報は、[バックアップと復元のアーキテクチャドキュメント](../../../architecture/backup-restore.md)にあります。] + +## 永続性の設定 {#persistence-configuration} + +バックアップと復元の永続ストアは、個別に構成されます。バックアップおよび復元操作のためにGitLabを構成する場合は、次の考慮事項を確認してください。 + +バックアップは`backups.cron.persistence.*`プロパティを使用し、復元は`persistence.*`プロパティを使用します。永続ストアの構成に関する詳細な説明では、最後のプロパティキー（例：`.enabled`または`.size`）のみを使用し、適切なプレフィックスを追加する必要があります。 + +永続ストアはデフォルトで無効になっているため、重要なサイズのバックアップまたは復元を行うには、`.enabled`を`true`に設定する必要があります。さらに、`.storageClass`をKubernetesによってPersistentVolumeを作成するために指定するか、PersistentVolumeを手動で作成する必要があります。`.storageClass`が「-」として指定されている場合、PersistentVolumeは、Kubernetesクラスターで指定されている[デフォルトのStorageClass](https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/)を使用して作成されます。 + +PersistentVolumeを手動で作成する場合、`.volumeName`プロパティを使用するか、セレクター`.matchLables`/`.matchExpressions`プロパティを使用してボリュームを指定できます。 + +ほとんどの場合、`.accessMode`のデフォルト値は、ToolboxのみがPersistentVolumeにアクセスするための適切な制御を提供します。設定が正しいことを確認するには、KubernetesクラスターにインストールされているCSIドライバーのドキュメントを参照してください。 + +### バックアップに関する考慮事項 {#backup-considerations} + +バックアップ操作では、バックアップオブジェクトストアに書き込まれる前に、バックアップされる個々のコンポーネントを保持するために、ある程度のディスク容量が必要です。ディスク容量の量は、次の要因によって異なります。 + +- プロジェクトの数と各プロジェクトに保存されているデータの量 +- PostgresSQLデータベースのサイズ（イシュー、MRなど） +- 各オブジェクトストアバックエンドのサイズ + +おおよそのサイズが決定されると、バックアップを開始できるように`backups.cron.persistence.size`プロパティを設定できます。 + +### 復元に関する考慮事項 {#restore-considerations} + +バックアップの復元中、実行中のインスタンスでファイルを置き換える前に、バックアップをディスクに抽出する必要があります。この復元ディスク領域のサイズは、`persistence.size`プロパティによって制御されます。GitLabインストールのサイズが大きくなるにつれて、復元ディスク領域のサイズもそれに応じて大きくする必要があることに注意してください。ほとんどの場合、復元ディスク領域のサイズは、バックアップディスク領域と同じサイズである必要があります。 + +## Toolboxに含まれるツール {#toolbox-included-tools} + +Toolboxコンテナには、Railsコンソール、Rakeタスクなど、便利なGitLabツールが含まれています。これらのコマンドを使用すると、データベース移行のステータスを確認したり、管理タスクのRakeタスクを実行したり、Railsコンソールを操作したりできます。 + +```shell +# locate the Toolbox pod +kubectl get pods -lapp=toolbox + +# Launch a shell inside the pod +kubectl exec -it -- bash + +# open Rails console +gitlab-rails console -e production + +# execute a Rake task +gitlab-rake gitlab:env:info +``` + +### アフィニティ {#affinity} + +詳細については、[`affinity`](../_index.md#affinity)を参照してください。 diff --git a/doc-locale/ja-jp/charts/gitlab/webservice/_index.md b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md new file mode 100644 index 0000000000..b18d9cacf3 --- /dev/null +++ b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md @@ -0,0 +1,845 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Webserviceチャートの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`webservice`サブチャートは、GitLab Railsウェブサーバーに、ポッドごとに2つのWebserviceワーカーを提供します。これは、単一のポッドがGitLabであらゆるWebリクエストを処理するために必要な最小限の数です。 + +このチャートのポッドは、`gitlab-workhorse`と`webservice`の2つのコンテナを使用します。[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab/-/tree/master/workhorse)はポート`8181`でリッスンし、ポッドへの受信トラフィックの宛先は_常に_これでなければなりません。`webservice`はGitLabの[Railsコードベース](https://gitlab.com/gitlab-org/gitlab)を格納し、`8080`でリッスンし、メトリクスの収集を目的としてアクセスできます。`webservice`は、通常のトラフィックを直接受信しないでください。 + +## 要件 {#requirements} + +このチャートは、完全なGitLabチャートの一部として、またはこのチャートがデプロイされているKubernetesクラスターから到達可能な外部サービスとして、Redis、PostgreSQL、Gitaly、およびRegistryサービスに依存します。 + +## 設定 {#configuration} + +`webservice`チャートは、次のように構成されています。[グローバル設定](#global-settings)、[デプロイメント設定](#deployments-settings)、[Ingress設定](#ingress-settings)、[外部サービス](#external-services)、[チャート設定](#chart-settings)。 + +## インストール コマンドライン オプション {#installation-command-line-options} + +以下のテーブルには、`helm install`コマンドに`--set`フラグを使用して指定できる、可能なすべてのチャート構成が記載されています。 + +| パラメータ | デフォルト | 説明 | +|---------------------------------------------------------------|-----------------------------------------------------------------|-------------| +| `annotations` | | Podアノテーション | +| `podLabels` | | 補足的なPodラベル。セレクターには使用されません。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される補足的なラベル。 | +| `deployment.terminationGracePeriodSeconds` | `30` | Kubernetesがポッドの終了を待機する秒数。これは`shutdown.blackoutSeconds`よりも長くする必要があります。 | +| `deployment.livenessProbe.initialDelaySeconds` | `20` | Livenessプローブが開始されるまでの遅延 | +| `deployment.livenessProbe.periodSeconds` | `60` | Livenessプローブの実行頻度 | +| `deployment.livenessProbe.timeoutSeconds` | `30` | Livenessプローブがタイムアウトするタイミング | +| `deployment.livenessProbe.successThreshold` | `1` | Livenessプローブが失敗後に成功したと見なされるための最小連続成功数 | +| `deployment.livenessProbe.failureThreshold` | `3` | Livenessプローブが成功後に失敗したと見なされるための最小連続失敗数 | +| `deployment.readinessProbe.initialDelaySeconds` | `0` | Readinessプローブが開始されるまでの遅延 | +| `deployment.readinessProbe.periodSeconds` | `10` | Readinessプローブの実行頻度 | +| `deployment.readinessProbe.timeoutSeconds` | `2` | Readinessプローブがタイムアウトするタイミング | +| `deployment.readinessProbe.successThreshold` | `1` | Readinessプローブが失敗後に成功したと見なされるための最小連続成功数 | +| `deployment.readinessProbe.failureThreshold` | `3` | Readinessプローブが成功後に失敗したと見なされるための最小連続失敗数 | +| `deployment.strategy` | `{}` | デプロイメントで使用されるアップデートストラテジーを構成できます。指定されていない場合、クラスターのデフォルトが使用されます。 | +| `enabled` | `true` | Webserviceが有効なフラグ | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラル スタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `extras.google_analytics_id` | `nil` | フロントエンド用のGoogle Analytics ID | +| `extraVolumeMounts` | | 実行する追加ボリューム マウントのリスト | +| `extraVolumes` | | 作成する追加ボリュームのリスト | +| `extraEnv` | | 公開する追加の環境変数のリスト | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `gitlab.webservice.workhorse.image` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee` | Workhorseイメージリポジトリ | +| `gitlab.webservice.workhorse.tag` | | Workhorseイメージtag | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | 動作には、スケールアップおよびスケールダウン動作の仕様が含まれています（`autoscaling/v2beta2`以上が必要です）。 | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、必要なレプリカ数を計算するために使用する仕様が含まれています（`targetAverageUtilization`で構成された平均CPU使用率のデフォルトの使用をオーバーライドします）。 | +| `hpa.cpu.targetType` | `AverageValue` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります。 | +| `hpa.cpu.targetAverageValue` | `1` | オートスケールCPUターゲット値を設定します。 | +| `hpa.cpu.targetAverageUtilization` | | オートスケールCPUターゲット使用率を設定します。 | +| `hpa.memory.targetType` | | オートスケールメモリターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります。 | +| `hpa.memory.targetAverageValue` | | オートスケールメモリターゲット値を設定します。 | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリターゲット使用率を設定します。 | +| `hpa.targetAverageValue` | | **非推奨**オートスケールCPUターゲット値を設定します。 | +| `sshHostKeys.mount` | `false` | 公開SSH鍵を含むGitLab Shellシークレットをマウントするかどうか。 | +| `sshHostKeys.mountName` | `ssh-host-keys` | マウントされたボリュームの名前。 | +| `sshHostKeys.types` | `[dsa,rsa,ecdsa,ed25519]` | マウントするSSHキータイプのリスト。 | +| `image.pullPolicy` | `Always` | Webserviceイメージのプルポリシー | +| `image.pullSecrets` | | イメージリポジトリのシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ee` | Webserviceイメージリポジトリ | +| `image.tag` | | Webserviceイメージtag | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージtag | +| `init.containerSecurityContext.runAsUser` | `1000` | initContainer固有:コンテナを開始するユーザーID | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | リソースを0にスケールバックする前に、最後のトリガーがアクティブであると報告されてから待機する期間 | +| `keda.minReplicaCount` | `minReplicas` | KEDAがリソースをスケールダウンする最小レプリカ数。 | +| `keda.maxReplicaCount` | `maxReplicas` | KEDAがリソースをスケールアップする最大レプリカ数。 | +| `keda.fallback` | | KEDAフォールバック構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`の削除後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | スケールアップおよびスケールダウン動作の仕様。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`と`hpa.memory`から計算されたトリガーがデフォルトです | +| `metrics.enabled` | `true` | メトリクス エンドポイントをスクレイピングに使用できるようにするかどうか | +| `metrics.port` | `8083` | メトリクス エンドポイント ポート | +| `metrics.path` | `/metrics` | メトリクス エンドポイント パス | +| `metrics.serviceMonitor.enabled` | `false` | Prometheus Operatorがメトリクス スクレイピングを管理できるようにするServiceMonitorを作成するかどうか。これを有効にすると、`prometheus.io`スクレイプ アノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加ラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント構成 | +| `metrics.annotations` | | **非推奨**明示的なメトリクス アノテーションを設定します。テンプレート コンテンツに置き換えられました。 | +| `metrics.tls.enabled` | | メトリクス/web_exporterエンドポイントに対してTLSが有効。デフォルトは`tls.enabled`です。 | +| `metrics.tls.secretName` | | メトリクス/web_exporterエンドポイントTLS証明書とキーのシークレット。デフォルトは`tls.secretName`です。 | +| `minio.bucket` | `git-lfs` | MinIOを使用する場合のストレージ バケットの名前 | +| `minio.port` | `9000` | MinIOサービスのポート | +| `minio.serviceName` | `minio-svc` | MinIOサービスの名前 | +| `monitoring.ipWhitelist` | `[0.0.0.0/0]` | モニタリング エンドポイントの許可リストに追加するIPのリスト | +| `monitoring.exporter.enabled` | `false` | Prometheusメトリクスを公開するためにウェブサーバーを有効にします。メトリクス ポートがモニタリングexporterポートに設定されている場合、これは`metrics.enabled`によって上書きされます | +| `monitoring.exporter.port` | `8083` | メトリクスexporterに使用するポート番号 | +| `psql.password.key` | `psql-password` | psqlシークレットのpsqlパスワードへのキー | +| `psql.password.secret` | `gitlab-postgres` | psqlシークレット名 | +| `psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`よりも優先されます | +| `puma.disableWorkerKiller` | `true` | Puma workerメモリキラーを無効にします。 | +| `puma.workerMaxMemory` | | Puma workerキラーの最大メモリ（メガバイト単位） | +| `puma.threads.min` | `4` | Pumaスレッドの最小量 | +| `puma.threads.max` | `4` | Pumaスレッドの最大量 | +| `rack_attack.git_basic_auth` | `{}` | 詳細については、[GitLabドキュメント](https://docs.gitlab.com/administration/settings/protected_paths/)を参照してください | +| `redis.serviceName` | `redis` | Redisサービス名 | +| `global.registry.api.port` | `5000` | レジストリポート | +| `global.registry.api.protocol` | `http` | レジストリプロトコル | +| `global.registry.api.serviceName` | `registry` | レジストリサービス名 | +| `global.registry.enabled` | `true` | すべてのプロジェクトメニューでレジストリリンクを追加/削除します | +| `global.registry.tokenIssuer` | `gitlab-issuer` | レジストリトークン発行者 | +| `replicaCount` | `1` | Webserviceレプリカの数 | +| `resources.requests.cpu` | `300m` | Webservice最小CPU | +| `resources.requests.memory` | `1.5G` | Webservice最小メモリ | +| `service.externalPort` | `8080` | Webservice公開ポート | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23が必要) | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナの開始に使用される[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナの開始に使用される特定のセキュリティコンテキストユーザーIDの上書きを許可します | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | Gitalyコンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | Gitalyコンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.create` | `false` | ServiceAccountを作成するかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceAccount.name` | | ServiceAccountの名前。設定しない場合、完全なチャート名が使用されます | +| `serviceLabels` | `{}` | 補足的なサービスラベル | +| `service.internalPort` | `8080` | Webservice内部ポート | +| `service.type` | `ClusterIP` | Webserviceサービスタイプ | +| `service.workhorseExternalPort` | `8181` | Workhorse公開ポート | +| `service.workhorseInternalPort` | `8181` | Workhorse内部ポート | +| `service.loadBalancerIP` | | LoadBalancerに割り当てるIPアドレス（クラウドプロバイダーでサポートされている場合） | +| `service.loadBalancerSourceRanges` | | LoadBalancerへのアクセスを許可されているIP CIDRのリスト（サポートされている場合）。service.type = LoadBalancerに必須 | +| `shell.authToken.key` | `secret` | ShellシークレットのShellトークンへのキー | +| `shell.authToken.secret` | `{Release.Name}-gitlab-shell-secret` | Shellトークンシークレット | +| `shell.port` | `nil` | UIによって生成されたSSH URLで使用するポート番号 | +| `shutdown.blackoutSeconds` | `10` | シャットダウンの受信後にWebserviceを実行し続ける秒数。これは`deployment.terminationGracePeriodSeconds`よりも短くする必要があります | +| `tls.enabled` | `false` | Webservice TLSが有効 | +| `tls.secretName` | `{Release.Name}-webservice-tls` | Webservice TLSシークレット。`secretName`は[Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を指している必要があります。 | +| `tolerations` | `[]` | ポッド割り当ての容認ラベル | +| `trusted_proxies` | `[]` | 詳細については、[GitLabドキュメント](https://docs.gitlab.com/install/installation/#adding-your-trusted-proxies)を参照してください | +| `workhorse.logFormat` | `json` | ログ形式。有効な形式：`json`、`structured`、`text` | +| `workerProcesses` | `2` | Webserviceワーカーの数 | +| `workhorse.keywatcher` | `true` | RedisにWorkhorseをサブスクライブします。これは`/api/*`へのリクエストを処理するあらゆるデプロイメントで**必須**ですが、他のデプロイメントでは安全に無効にできます | +| `workhorse.shutdownTimeout` | `global.webservice.workerTimeout + 1`（秒） | すべてのWebリクエストがWorkhorseからクリアされるまで待機する時間。例：`1min`、`65s`。 | +| `workhorse.trustedCIDRsForPropagation` | | 相関IDの伝播を信頼できるCIDRブロックのリスト。これが機能するには、`workhorse.extraArgs`でも`-propagateCorrelationID`オプションを使用する必要があります。詳細については、[Workhorseドキュメント](https://docs.gitlab.com/development/workhorse/configuration/#propagate-correlation-ids)を参照してください。 | +| `workhorse.trustedCIDRsForXForwardedFor` | | `X-Forwarded-For` HTTPヘッダーを介して実際のクライアントIPを解決するために使用できるCIDRブロックのリスト。これは`workhorse.trustedCIDRsForPropagation`で使用されます。詳細については、[Workhorseドキュメント](https://docs.gitlab.com/development/workhorse/configuration/#trusted-proxies)を参照してください。 | +| `workhorse.metadata.zipReaderLimitBytes` | | zipリーダーを制限するオプションのバイト数。GitLab 16.9で導入されました。詳細については、[Workhorseドキュメント](https://docs.gitlab.com/development/workhorse/configuration/#metadata-options)を参照してください。 | +| `workhorse.containerSecurityContext` | | コンテナの開始に使用される[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `workhorse.containerSecurityContext.runAsUser` | `1000` | コンテナを開始するユーザーID | +| `workhorse.containerSecurityContext.allowPrivilegeEscalation` | `false` | コンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `workhorse.containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `workhorse.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `workhorse.livenessProbe.initialDelaySeconds` | `20` | Livenessプローブが開始されるまでの遅延 | +| `workhorse.livenessProbe.periodSeconds` | `60` | Livenessプローブの実行頻度 | +| `workhorse.livenessProbe.timeoutSeconds` | `30` | Livenessプローブがタイムアウトするタイミング | +| `workhorse.livenessProbe.successThreshold` | `1` | Livenessプローブが失敗後に成功したと見なされるための最小連続成功数 | +| `workhorse.livenessProbe.failureThreshold` | `3` | Livenessプローブが成功後に失敗したと見なされるための最小連続失敗数 | +| `workhorse.monitoring.exporter.enabled` | `false` | Prometheusメトリクスを公開するためにworkhorseを有効にします。これは`workhorse.metrics.enabled`によってオーバーライドされます | +| `workhorse.monitoring.exporter.port` | `9229` | workhorse Prometheusメトリクスに使用するポート番号 | +| `workhorse.monitoring.exporter.tls.enabled` | `false` | `true`に設定すると、メトリクス エンドポイントでTLSが有効になります。[WorkhorseでTLSが有効になっている](#gitlab-workhorse)必要があります。 | +| `workhorse.metrics.enabled` | `true` | workhorseメトリクス エンドポイントをスクレイピングに使用できるようにするかどうか | +| `workhorse.metrics.port` | `8083` | Workhorseメトリクス エンドポイントポート | +| `workhorse.metrics.path` | `/metrics` | Workhorseメトリクス エンドポイントパス | +| `workhorse.metrics.serviceMonitor.enabled` | `false` | Prometheus OperatorがWorkhorseメトリクス スクレイピングを管理できるようにするServiceMonitorを作成するかどうか | +| `workhorse.metrics.serviceMonitor.additionalLabels` | `{}` | Workhorse ServiceMonitorに追加する追加ラベル | +| `workhorse.metrics.serviceMonitor.endpointConfig` | `{}` | Workhorse ServiceMonitorの追加のエンドポイント構成 | +| `workhorse.readinessProbe.initialDelaySeconds` | `0` | Readinessプローブが開始されるまでの遅延 | +| `workhorse.readinessProbe.periodSeconds` | `10` | Readinessプローブの実行頻度 | +| `workhorse.readinessProbe.timeoutSeconds` | `2` | Readinessプローブがタイムアウトするタイミング | +| `workhorse.readinessProbe.successThreshold` | `1` | Readinessプローブが失敗後に成功したと見なされるための最小連続成功数 | +| `workhorse.readinessProbe.failureThreshold` | `3` | Readinessプローブが成功後に失敗したと見なされるための最小連続失敗数 | +| `workhorse.imageScaler.maxProcs` | `2` | 同時に実行できるイメージスケーリングプロセスの最大数 | +| `workhorse.imageScaler.maxFileSizeBytes` | `250000` | スケーラーで処理されるイメージの最大ファイルサイズ（バイト単位） | +| `workhorse.tls.verify` | `true` | `true`に設定すると、NGINX IngressはWorkhorseのTLS証明書を強制的に検証します。カスタムCAの場合は、`workhorse.tls.caSecretName`も設定する必要があります。自己署名証明書の場合は、`false`に設定する必要があります。 | +| `workhorse.tls.secretName` | `{Release.Name}-workhorse-tls` | TLSキーと証明書のペアを含む[TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)の名前。これは、Workhorse TLSが有効な場合に必要です。 | +| `workhorse.tls.caSecretName` | | CA証明書を含むシークレットの名前。これは**TLSシークレット** [ではありません](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)。キー`ca.crt`のみが必要です。これは、NGINXがWorkhorseのTLS証明書を検証するために使用されます。 | +| `webServer` | `puma` | リクエストの処理に使用されるWebサーバー(Webservice/Puma)を選択します | +| `priorityClassName` | `""` | ポッド`priorityClassName`の設定を許可します。これは、削除の場合にポッドの優先度を制御するために使用されます | + +## チャート構成の例 {#chart-configuration-examples} + +### `extraEnv` {#extraenv} + +`extraEnv`を使用すると、ポッド内のすべてのコンテナに追加の環境変数を公開できます。 + +以下は、`extraEnv`の使用例です。 + +```yaml +extraEnv: + SOME_KEY: some_value + SOME_OTHER_KEY: some_other_value +``` + +コンテナが起動されると、環境変数が公開されていることを確認できます。 + +```shell +env | grep SOME +SOME_KEY=some_value +SOME_OTHER_KEY=some_other_value +``` + +### `extraEnvFrom` {#extraenvfrom} + +`extraEnvFrom`を使用すると、ポッド内のすべてのコンテナで、他のデータソースからの追加の環境変数を公開できます。後続の変数は、[デプロイメント](#deployments-settings)ごとにオーバーライドできます。 + +以下は、`extraEnvFrom`の使用例です。 + +```yaml +extraEnvFrom: + MY_NODE_NAME: + fieldRef: + fieldPath: spec.nodeName + MY_CPU_REQUEST: + resourceFieldRef: + containerName: test-container + resource: requests.cpu + SECRET_THING: + secretKeyRef: + name: special-secret + key: special_token + # optional: boolean +deployments: + default: + extraEnvFrom: + CONFIG_STRING: + configMapKeyRef: + name: useful-config + key: some-string + # optional: boolean +``` + +### `image.pullSecrets` {#imagepullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに対して認証を行い、ポッドのイメージをプルできます。 + +プライベートレジストリとその認証方法の詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)を参照してください。 + +以下は、`pullSecrets`の使用例です。 + +```yaml +image: + repository: my.webservice.repository + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### `serviceAccount` {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 型 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `annotations` | マップ | `{}` | ServiceAccountアノテーション。 | +| `automountServiceAccountToken` | ブール | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に機能するために必要でない限り（たとえば、Istio）、これを有効にしないでください。 | +| `create` | ブール | `false` | ServiceAccountを作成するかどうかを示します。 | +| `enabled` | Boolean | `false` | ServiceAccountを使用するかどうかを示します。 | +| `name` | String | | ServiceAccountの名前。設定されていない場合、完全なチャート名が使用されます。 | + +### `tolerations` {#tolerations} + +`tolerations`を使用すると、taintされたワーカーノードでポッドをスケジュールできます + +以下は、`tolerations`の使用例です。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### `annotations` {#annotations} + +`annotations`を使用すると、Webserviceポッドにアノテーションを追加できます。次に例を示します。 + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +### `strategy` {#strategy} + +`deployment.strategy`を使用すると、デプロイの更新ストラテジーを変更できます。これは、デプロイが更新されたときにポッドがどのように再作成されるかを定義します。指定されていない場合、クラスターのデフォルトが使用されます。たとえば、ローリングアップデートの開始時に追加のポッドを作成せず、利用不可ポッドの最大数を50% に変更する場合は、次のようにします。 + +```yaml +deployment: + strategy: + rollingUpdate: + maxSurge: 0 + maxUnavailable: 50% +``` + +更新ストラテジーのタイプを`Recreate`に変更することもできますが、新しいポッドのスケジュール前にすべてのポッドが強制終了されるため、注意が必要です。新しいポッドが開始されるまで、Web UIは使用できません。この場合、`rollingUpdate`を定義する必要はなく、`type`のみを定義します。 + +```yaml +deployment: + strategy: + type: Recreate +``` + +詳細については、[Kubernetes](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy)ドキュメントを参照してください。 + +### TLS {#tls} + +Webserviceポッドは2つのコンテナを実行します。 + +- `gitlab-workhorse` +- `webservice` + +#### `gitlab-workhorse` {#gitlab-workhorse} + +Workhorseは、Webとメトリクスエンドポイントの両方でTLSをサポートします。これにより、Workhorseと他のコンポーネント（特に`nginx-ingress`、`gitlab-shell`、および`gitaly`）間の通信が保護されます。TLS証明書には、共通名 (CN) またはサブジェクト代替名 (SAN) にWorkhorseサービス ホスト名 (例: `RELEASE-webservice-default.default.svc`) を含める必要があります。 + +[Webserviceの複数のデプロイ](#deployments-settings)が存在する可能性があるため、異なるサービス名に対してTLS証明書を準備する必要があります。これは、複数のSANまたはワイルドカード証明書のいずれかによって実現できます。 + +TLS証明書が生成されたら、その証明書の[Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を作成します。また、`ca.crt`キーを使用して、TLS証明書のCA証明書のみを含む別のシークレットを作成する必要があります。 + +`global.workhorse.tls.enabled`を`true`に設定すると、`gitlab-workhorse`コンテナに対してTLSを有効にできます。必要に応じて、カスタムシークレット名を`gitlab.webservice.workhorse.tls.secretName`および`global.certificates.customCAs`にパスできます。 + +`gitlab.webservice.workhorse.tls.verify`が`true` (これはデフォルトです) の場合、CA証明書のシークレット名を`gitlab.webservice.workhorse.tls.caSecretName`にもパスする必要があります。これは、自己署名証明書とカスタムCAに必要です。このシークレットは、NGINXがWorkhorseのTLS証明書を検証するために使用します。 + +```yaml +global: + workhorse: + tls: + enabled: true + certificates: + customCAs: + - secret: gitlab-workhorse-ca +gitlab: + webservice: + workhorse: + tls: + verify: true + # secretName: gitlab-workhorse-tls + caSecretName: gitlab-workhorse-ca + monitoring: + exporter: + enabled: true + tls: + enabled: true +``` + +`gitlab-workhorse`コンテナのメトリクスエンドポイントのTLSは、`global.workhorse.tls.enabled`から継承されます。メトリクスエンドポイントのTLSは、Workhorseに対してTLSが有効になっている場合にのみ使用できます。メトリクスリスナーは、`gitlab.webservice.workhorse.tls.secretName`で指定されたものと同じTLS証明書を使用します。 + +メトリクスエンドポイントに使用されるTLS証明書では、特に含まれているPrometheus Helm ChartChart>を使用している場合に、含まれているサブジェクトの代替名 (SAN) について追加の考慮事項が必要になる場合があります。詳細については、[TLSが有効なエンドポイントをスクレイピングするようにPrometheusを設定する](../../../installation/tools.md#configure-prometheus-to-scrape-tls-enabled-endpoints)を参照してください。 + +#### `webservice` {#webservice} + +TLSを有効にする主なユースケースcase>は、[Prometheusメトリクスをスクレイピング](https://docs.gitlab.com/administration/monitoring/prometheus/gitlab_metrics/)するためにHTTPS経由で暗号化を提供することです。 + +PrometheusがHTTPSを使用して`/metrics/`エンドポイントをスクレイピングするには、証明書の`CommonName`属性または`SubjectAlternativeName`エントリの追加設定が必要です。これらの要件については、[TLSが有効なエンドポイントをスクレイピングするようにPrometheusを設定する](../../../installation/tools.md#configure-prometheus-to-scrape-tls-enabled-endpoints)を参照してください。 + +`gitlab.webservice.tls.enabled`設定により、`webservice`コンテナでTLSを有効にできます。 + +```yaml +gitlab: + webservice: + tls: + enabled: true + # secretName: gitlab-webservice-tls +``` + +`secretName`は、[Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を指すto>必要があります。たとえば、ローカル証明書とキーを使用してTLSシークレットを作成するには、次のようにします。 + +```shell +kubectl create secret tls --cert=path/to/puma.crt --key=path/to/puma.key +``` + +## このチャートのCommunity Editionの使用 {#using-the-community-edition-of-this-chart} + +デフォルトでは、Helm ChartChart>はGitLab Enterprise EditionEdition> を使用します。必要に応じて、代わりにCommunity Editionを使用できます。[2つの違い](https://about.gitlab.com/install/ce-or-ee/)について詳しく見てください。 + +Community Editionを使用するには、`image.repository`を`registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ce`に、`workhorse.image`を`registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ce`に設定します。 + +## グローバル設定 {#global-settings} + +チャート間でいくつかの一般的なグローバル設定を共有します。GitLabやレジストリのホスト名など、一般的な設定オプションについては、[グローバルドキュメント](../../globals.md)を参照してください。 + +## デプロイ設定 {#deployments-settings} + +このチャートには、複数のデプロイオブジェクトとそれらに関連するリソースを作成する機能があります。この機能により、パスベースのルーティングを使用して、複数のポッドセット間でGitLabアプリケーションへのリクエストを分散型できます。 + +このマップのキー（この例では`default`）は、それぞれの「名前」です。`default`には、`RELEASE-webservice-default`で作成されたデプロイ、サービス、HorizontalPodAutoscaler、PodDisruptionBudget、およびオプションのIngressがあります。 + +指定されていないプロパティは、`gitlab-webservice`チャートのデフォルトから継承されます。 + +```yaml +deployments: + default: + ingress: + path: # Does not inherit or default. Leave blank to disable Ingress. + pathType: Prefix + provider: nginx + annotations: + # inherits `ingress.anntoations` + proxyConnectTimeout: # inherits `ingress.proxyConnectTimeout` + proxyReadTimeout: # inherits `ingress.proxyReadTimeout` + proxyBodySize: # inherits `ingress.proxyBodySize` + deployment: + annotations: # map + labels: # map + # inherits `deployment` + pod: + labels: # additional labels to .podLabels + annotations: # map + # inherit from .Values.annotations + service: + labels: # additional labels to .serviceLabels + annotations: # additional annotations to .service.annotations + # inherits `service.annotations` + hpa: + minReplicas: # defaults to .minReplicas + maxReplicas: # defaults to .maxReplicas + metrics: # optional replacement of HPA metrics definition + # inherits `hpa` + pdb: + maxUnavailable: # inherits `maxUnavailable` + resources: # `resources` for `webservice` container + # inherits `resources` + workhorse: # map + # inherits `workhorse` + extraEnv: # + # inherits `extraEnv` + extraEnvFrom: # + # inherits `extraEnvFrom` + puma: # map + # inherits `puma` + workerProcesses: # inherits `workerProcesses` + shutdown: + # inherits `shutdown` + nodeSelector: # map + # inherits `nodeSelector` + tolerations: # array + # inherits `tolerations` +``` + +### デプロイIngress {#deployments-ingress} + +各`deployments`エントリは、チャート全体の[Ingress設定](#ingress-settings)から継承されます。ここに表示される値は、そこに指定された値をオーバーライドします。`path`を除き、すべての設定はそれらと同じです。 + +```yaml +webservice: + deployments: + default: + ingress: + path: / + api: + ingress: + path: /api +``` + +`path`プロパティはIngressの`path`プロパティに直接入力されたもので、各サービスに向けられたURIパスを制御できます。上記の例では、`default`はキャッチオールパスとして機能し、`api`は`/api`の下のすべてのトラフィックを受信しました + +`path`を空に設定すると、特定のデプロイに関連付けられたIngressリソースが作成されなくなります。以下を参照してください。`internal-api`は外部トラフィックを受信しません。 + +```yaml +webservice: + deployments: + default: + ingress: + path: / + api: + ingress: + path: /api + internal-api: + ingress: + path: +``` + +## Ingress設定 {#ingress-settings} + +| 名前 | タイプ | デフォルト | 説明 | +|:----------------------------------|:-------:|:--------------------------|:------------| +| `ingress.apiVersion` | String | | `apiVersion`フィールドで使用する値。 | +| `ingress.annotations` | Map | [以下](#annotations)を参照してください。 | これらのアノテーションは、すべてのIngressに使用されます。次に例を示します。`ingress.annotations."nginx\.ingress\.kubernetes\.io/enable-access-log"=true`。 | +| `ingress.configureCertmanager` | Boolean | | Ingressアノテーション`cert-manager.io/issuer`および`acme.cert-manager.io/http01-edit-in-place`を切り替えます。詳細については、[GitLab PagesのTLS要件](../../../installation/tls.md)を参照してください。 | +| `ingress.enabled` | Boolean | `false` | それらをサポートするサービスのIngressオブジェクトを作成するかどうかを制御する設定。`false`の場合、`global.ingress.enabled`設定 値が使用されます。 | +| `ingress.proxyBodySize` | String | `512m` | [以下](#proxybodysize)を参照してください。 | +| `ingress.serviceUpstream` | Boolean | `true` | [以下](#serviceupstream)を参照してください。 | +| `ingress.tls.enabled` | Boolean | `true` | `false`に設定すると、GitLab WebserviceのTLSが無効になります。これは、Ingressコントローラーの前にTLS終端プロキシがある場合のように、IngressレベルでTLS終端を使用できない場合に特に役立ちます。 | +| `ingress.tls.secretName` | String | （空） | GitLab URLの有効な証明書とキーを含むKubernetes TLSシークレットの名前。設定されていない場合、代わりに`global.ingress.tls.secretName`値が使用されます。 | +| `ingress.tls.smardcardSecretName` | String | （空） | 有効になっている場合、GitLabスマートカードURLの有効な証明書とキーを含むKubernetes TLS SEcretの名前。設定されていない場合、代わりに`global.ingress.tls.secretName`値が使用されます。 | +| `ingress.tls.useGeoClass` | Boolean | `false` | IngressClassをGeo Ingressクラス (`global.geo.ingressClass`) でオーバーライドします。プライマリGeoサイトに必要です。 | + +### アノテーション {#annotations-1} + +`annotations`は、Webservice Ingressにアノテーションを設定するために使用されます。 + +### `serviceUpstream` {#serviceupstream} + +これにより、NGINXにアップストリームとしてサービス自体に直接接続するように指示することで、Webserviceポッドへのトラフィックをより均等に分散させることができます。詳細については、[NGINXドキュメント](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md#service-upstream)を参照してください。 + +これをオーバーライドするには、次のように設定します。 + +```yaml +gitlab: + webservice: + ingress: + serviceUpstream: "false" +``` + +### `proxyBodySize` {#proxybodysize} + +`proxyBodySize`は、NGINXプロキシの最大本文サイズを設定するために使用されます。これは通常、デフォルトよりも大きいDockerイメージを許可するために必要です。これは、[Linuxパッケージインストール](https://docs.gitlab.com/omnibus/settings/nginx/#use-an-existing-passenger-and-nginx-installation)の`nginx['client_max_body_size']`設定と同等です。代替オプションとして、次の2つのパラメータのいずれかを使用して本文サイズを設定することもできます。 + +- `gitlab.webservice.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"` +- `global.ingress.annotations."nginx\.ingress\.kubernetes\.io/proxy-body-size"` + +### 追加のIngress {#extra-ingress} + +`extraIngress.enabled=true`を設定すると、追加のIngressをデプロイできます。Ingressは、`-extra`サフィックスが付いたデフォルトのIngressとして名前が付けられ、デフォルトのIngressと同じ設定をサポートします。 + +## リソース {#resources} + +### メモリリクエスト/制限 {#memory-requestslimits} + +各ポッドは`workerProcesses`と同じ数の作業者を起動するため、各作業者がある程度のベースラインメモリを使用します。推奨事項： + +- 作業者あたり最小1.25 GB (`requests.memory`) +- 作業者あたり最大1.5 GB、さらにプライマリ用に1 GB (`limits.memory`) + +必要なリソースは、ユーザーによって生成されるワークロードに依存し、GitLabアプリケーションの変更またはアップグレードに基づいて将来変更される可能性があることに注意してください。 + +デフォルト： + +```yaml +workerProcesses: 2 +resources: + requests: + memory: 2.5G # = 2 * 1.25G +# limits: +# memory: 4G # = (2 * 1.5G) + 950M +``` + +4人の作業者が設定されている場合： + +```yaml +workerProcesses: 4 +resources: + requests: + memory: 5G # = 4 * 1.25G +# limits: +# memory: 7G # = (4 * 1.5G) + 950M +``` + +## 外部サービス {#external-services} + +### Redis {#redis} + +Redisドキュメントは、[グローバル](../../globals.md#configure-redis-settings)ページに統合されています。最新のRedis設定オプションについては、このページを参照してください。 + +### PostgreSQL {#postgresql} + +PostgreSQLドキュメントは、[グローバル](../../globals.md#configure-postgresql-settings)ページに統合されています。最新のPostgreSQL設定オプションについては、このページを参照してください。 + +### Gitaly {#gitaly} + +Gitalyは[グローバル設定](../../globals.md)によって設定されます。[Gitaly設定ドキュメント](../../globals.md#configure-gitaly-settings)を参照してください。 + +### MinIO {#minio} + +```yaml +minio: + serviceName: 'minio-svc' + port: 9000 +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:--------------|:-------:|:------------|:------------| +| `port` | Integer | `9000` | MinIO `Service`に到達するためのポート番号。 | +| `serviceName` | String | `minio-svc` | MinIOポッドによって公開される`Service`の名前。 | + +### レジストリ {#registry} + +```yaml +registry: + host: registry.example.com + port: 443 + api: + protocol: http + host: registry.example.com + serviceName: registry + port: 5000 + tokenIssuer: gitlab-issuer + certificate: + secret: gitlab-registry + key: registry-auth.key +``` + +| 名前 | タイプ | デフォルト | 説明 | +|:---------------------|:-------:|:----------------|:------------| +| `api.host` | String | | 使用するレジストリサーバーのホスト名。これは、`api.serviceName`の代わりに省略できます。 | +| `api.port` | Integer | `5000` | レジストリAPIへの接続に使用するポート。 | +| `api.protocol` | String | | Webserviceが レジストリAPIに到達するために使用する必要があるプロトコル。 | +| `api.serviceName` | String | `registry` | レジストリサーバーを操作している`service`の名前。これが存在し、`api.host`が存在しない場合、チャートはサービスのホスト名 (および現在の`.Release.Name`) を`api.host`値の代わりにテンプレート化します。これは、GitLabチャート全体の一部としてレジストリを使用する場合に便利です。 | +| `certificate.key` | String | | `auth.token.rootcertbundle`として[registry](https://hub.docker.com/_/registry/)コンテナに提供される証明書バンドルを格納する`Secret`の`key`の名前。 | +| `certificate.secret` | String | | GitLabインスタンスによって作成されたトークンを検証するために使用される証明書バンドルを格納する[Kubernetesシークレット](https://kubernetes.io/docs/concepts/configuration/secret/)の名前。 | +| `host` | String | | GitLab UIでDockerコマンドをユーザーに提供するために使用する外部ホスト名。`registry.hostname`テンプレートで設定された値にフォールバックします。これにより、`global.hosts`で設定された値に基づいてレジストリのホスト名が決定されます。詳細については、[グローバルドキュメント](../../globals.md)を参照してください。 | +| `port` | Integer | | ホスト名で使用される外部ポート。ポート`80`または`443`を使用すると、URLが`http`/`https`で形成されます。他のすべてのポートは`http`を使用し、ホスト名の最後にポートを付加します (例: `http://registry.example.com:8443`)。 | +| `tokenIssuer` | String | `gitlab-issuer` | 認証トークン発行者の名前。これは、送信時にトークンに組み込まれるため、レジストリの設定で使用されている名前と一致する必要があります。デフォルトの`gitlab-issuer`は、レジストリチャートで使用しているデフォルトと同じです。 | + +## チャート設定 {#chart-settings} + +次の値は、Webserviceポッドを設定するために使用されます。 + +| 名前 | タイプ | デフォルト | 説明 | +|:------------------|:-------:|:--------|:------------| +| `workerProcesses` | Integer | `2` | ポッドごとに実行するWebservice作業者の数。GitLabが適切に機能するためには、クラスターで使用可能な作業者が少なくとも`2`人必要です。`workerProcesses`を増やすと、作業者1人あたり約`400MB`ずつ必要なメモリが増加するため、それに応じてポッドの`resources`を更新する必要があります。 | +| `minReplicas` | Integer | `2` | レプリカの最小数 | +| `maxReplicas` | Integer | `10` | レプリカの最大数 | +| `maxUnavailable` | Integer | `1` | 利用できなくなるポッドの最大数の制限 | + +### メトリクス {#metrics} + +`metrics.enabled`の値を有効にすると、GitLabを使用して ポートを公開できます。ポッドにはPrometheusアノテーションが付与されるか、`metrics.serviceMonitor.enabled`が`true`の場合、Prometheus Operator ServiceMonitorが作成されます。メトリクスは`/-/metrics`エンドポイントから代替的にスクレイピングできますが、これには[GitLab Prometheusメトリクス](https://docs.gitlab.com/administration/monitoring/prometheus/gitlab_metrics/)が管理者エリアで有効になっている必要があります。GitLab Workhorseは`workhorse.metrics.enabled`経由で公開することもできますが、Prometheusアノテーションを使用して収集することはできないため、`workhorse.metrics.serviceMonitor.enabled`を`true`にするか、外部Prometheusが必要になります。 + +### GitLab Shell {#gitlab-shell} + +GitLab Shellは、Webserviceとの通信で認証を使用します。共有を使用して、をGitLab ShellおよびWebserviceと共有します。 + +```yaml +shell: + authToken: + secret: gitlab-shell-secret + key: secret + port: +``` + +| 名前 | 種類 | | 説明 | +|:-------------------|:-------:|:--------|:------------| +| `authToken.key` | 文字列 | | 認証を含む (下記) のキーの名前を定義します。 | +| `authToken.secret` | 文字列 | | プル元のKubernetes `Secret`の名前を定義します。 | +| `port` | 整数 | `22` | GitLab UI内でSSH URLの生成に使用する番号。`global.shell.port`によって制御されます。 | + +### WebServerオプション {#webserver-options} + +現在ののは、Puma Webサーバーをします。 + +Puma固有のオプション: + +| 名前 | 種類 | | 説明 | +|:-----------------------|:-------:|:--------|:------------| +| `puma.workerMaxMemory` | 整数 | | Puma killerの最大メモリ (メガバイト単位) | +| `puma.threads.min` | 整数 | `4` | Pumaの最小量 | +| `puma.threads.max` | 整数 | `4` | Pumaの最大量 | + +## `networkpolicy` {#configuring-the-networkpolicy}の + +このセクションでは、[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を制御します。このはオプションであり、特定のに対するポッドのとを制限するために使用されます。 + +| 名前 | 種類 | | 説明 | +|:------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | このは、`NetworkPolicy`を有効にします | +| `ingress.enabled` | ブール値 | `false` | `true`に設定すると、`Ingress`ポリシーがアクティブになります。これにより、ルールが指定されていない限り、すべての接続がされます。 | +| `ingress.rules` | 配列 | `[]` | ポリシーのルール。詳細については、と以下の例を参照してください | +| `egress.enabled` | ブール値 | `false` | `true`に設定すると、`Egress`ポリシーがアクティブになります。これにより、ルールが指定されていない限り、すべての接続がされます。 | +| `egress.rules` | 配列 | `[]` | ポリシーのルール。詳細については、と以下の例を参照してください | + +### ネットワークポリシーの例 {#example-network-policy} + +webserviceサービスでは、有効になっている場合、Prometheusの接続、NGINXおよびいくつかのGitLabからのトラフィックが必要です。通常、さまざまな場所への接続が必要です。この例では、次のネットワークポリシーを追加します。 + +- を許可: + - `gitaly`、`gitlab-pages`、`gitlab-shell`、`kas`、`mailroom`、および`nginx-ingress`のから`8181`へのを許可 + - `Prometheus`から`8080`、`8083`、および`9229`へのを許可 +- を許可: + - `gitaly`から`8075`への + - `kas`から`8153`への + - `kube-dns`から`53`への + - `registry`から`5000`への + - 外部データベース`172.16.0.10/32`から`5432`への + - 外部Redis `172.16.0.11/32`から`6379`への + - インターネット`0.0.0.0/0`から`443`へ + - S3または のAWSのようなから`443`への`172.16.1.0/24` + +_提供されている例は単なる例であり、完全ではない可能性があることに注意してください_ + +_Webserviceには、[外部オブジェクトストレージ](../../../advanced/external-object-storage)のイメージに対するパブリックインターネットへのアウトバウンド接続が必要であることに注意してください_ + +この例は、`kube-dns`が`kube-system`にデプロイされ、`prometheus`が`monitoring`にデプロイされ、`nginx-ingress`が`nginx-ingress`にデプロイされたという前提に基づいています。 + +```yaml +networkpolicy: + enabled: true + ingress: + enabled: true + rules: + - from: + - podSelector: + matchLabels: + app: gitaly + ports: + - port: 8181 + - from: + - podSelector: + matchLabels: + app: gitlab-pages + ports: + - port: 8181 + - from: + - podSelector: + matchLabels: + app: gitlab-shell + ports: + - port: 8181 + - from: + - podSelector: + matchLabels: + app: kas + ports: + - port: 8181 + - from: + - podSelector: + matchLabels: + app: mailroom + ports: + - port: 8181 + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: nginx-ingress + podSelector: + matchLabels: + app: nginx-ingress + component: controller + ports: + - port: 8181 + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: monitoring + podSelector: + matchLabels: + app: prometheus + component: server + release: gitlab + ports: + - port: 9229 + - port: 8080 + - port: 8083 + egress: + enabled: true + rules: + - to: + - podSelector: + matchLabels: + app: gitaly + ports: + - port: 8075 + - to: + - podSelector: + matchLabels: + app: kas + ports: + - port: 8153 + - to: + - ipBlock: + cidr: 0.0.0.0/0 + except: + - 10.0.0.0/8 + ports: + - port: 443 + - to: + - ipBlock: + cidr: 172.16.0.10/32 + ports: + - port: 5432 + - to: + - ipBlock: + cidr: 172.16.0.11/32 + ports: + - port: 6379 + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + podSelector: + matchLabels: + k8s-app: kube-dns + ports: + - port: 53 + protocol: UDP +``` + +### `LoadBalancer`サービス {#loadbalancer-service} + +`service.type`が`LoadBalancer`に設定されている場合、オプションで`service.loadBalancerIP`を指定して、ユーザー指定のIPで`LoadBalancer`を作成できます (クラウドプロバイダーがしている場合)。 + +`service.type`が`LoadBalancer`に設定されている場合、`LoadBalancer`にアクセスできる 範囲を制限するには、`service.loadBalancerSourceRanges`も設定する必要があります (クラウドプロバイダーがしている場合)。これは現在、[ が公開されている](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2500)問題が原因で必要です。 + +`LoadBalancer`サービスタイプの詳細については、[ Kubernetesドキュメント](https://kubernetes.io/docs/concepts/services-networking/#loadbalancer)を参照してください + +```yaml +service: + type: LoadBalancer + loadBalancerIP: 1.2.3.4 + loadBalancerSourceRanges: + - 10.0.0.0/8 +``` + +## KEDAの設定 {#configuring-keda} + +この`keda`セクションでは、標準の`HorizontalPodAutoscalers`の代わりに、[KEDA](https://keda.sh/) `ScaledObjects`のインストールを有効にします。このはオプションであり、カスタムまたは外部に基づいてオートスケールする必要がある場合に使用できます。 + +ほとんどのは、該当する場合、`hpa`セクションで設定された値に設定されます。 + +以下がtrueの場合、CPUとメモリのトリガーは、`hpa`セクションで設定されたCPUとメモリのしきい値に基づいて自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`もゼロ以外の値に設定されています。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらのの詳細については、[KEDAドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/)を参照してください。 + +| 名前 | 種類 | | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | ブール値 | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用します | +| `pollingInterval` | 整数 | `30` | 各トリガーで確認する間隔 | +| `cooldownPeriod` | 整数 | `300` | 最後トリガーがアクティブと報告されてから、リソースを0にスケールバックするまで待機する期間 | +| `minReplicaCount` | 整数 | `minReplicas` | KEDAがリソースをスケールダウンする最小レプリカ数。 | +| `maxReplicaCount` | 整数 | `maxReplicas` | KEDAがリソースをスケールアップする最大レプリカ数。 | +| `fallback` | マップ | | KEDAの[フォールバック](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)の設定については、ドキュメントを参照してください | +| `hpaName` | 文字列 | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | ブール値 | | ターゲットリソースを、`ScaledObject`が削除された後、元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | `hpa.behavior` | アップスケーリングとダウンスケーリングの仕様。 | +| `triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブにするトリガーのリスト。`hpa.cpu`および`hpa.memory`からコンピュートされたトリガーにデフォルト設定されています | diff --git a/doc-locale/ja-jp/charts/haproxy/_index.md b/doc-locale/ja-jp/charts/haproxy/_index.md new file mode 100644 index 0000000000..ceb3010f22 --- /dev/null +++ b/doc-locale/ja-jp/charts/haproxy/_index.md @@ -0,0 +1,41 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers +title: HAProxyの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +[HAProxy Helm Chart](https://github.com/haproxytech/helm-charts/tree/main/kubernetes-ingress)は、[バンドルされたNGINX Helm Chart](../nginx/_index.md)をIngressコントローラーとして置き換えることができ、Kubernetesの[追加のIngressコントローラーのリスト](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/#additional-controllers)に記載されています。 + +HAProxyは、SSH経由のGitもサポートします。 + +主にツールでの過去の経験から[NGINX](../nginx/_index.md)をデフォルトで使用していますが、HAProxyは有効な代替手段であり、特にHAProxyの経験が豊富なユーザーにとってはより好ましい場合があります。さらに、[FIPSコンプライアンス](#fips-compliant-haproxy)を提供しますが、[NGINX Ingressコントローラー](https://github.com/kubernetes/ingress-nginx)は現在提供していません。 + +## HAProxyの設定 {#configuring-haproxy} + +構成の詳細については、[HAProxy Helm Chartドキュメント](https://www.haproxy.com/documentation/kubernetes-ingress/enterprise/configuration-reference/)または[Helm values file](https://github.com/haproxytech/helm-charts/blob/main/kubernetes-ingress/values.yaml)を参照してください。 + +GitLab Helm Chartでテストされた値の詳細なYAMLについては、[HAProxy構成例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/values-haproxy-ingress.yaml)を参照してください。 + +### グローバル設定 {#global-settings} + +一部の一般的なグローバル設定は、チャート間で共有されています。GitLabやレジストリのホスト名など、一般的な構成オプションについては、[グローバルIngressドキュメント](../globals.md#configure-ingress-settings)を参照してください。 + +### FIPS準拠HAProxy {#fips-compliant-haproxy} + +[HAProxy Enterprise](https://www.haproxy.com/products/haproxy-enterprise-kubernetes-ingress-controller)は、FIPSコンプライアンスを提供します。HAProxy Enterpriseにはライセンスが必要です。 + +HAProxy Enterpriseの詳細については、以下のリンクを参照してください。 + +- [HAProxy Enterpriseランディングページ](https://www.haproxy.com/products/haproxy-enterprise) +- [HAProxy FIPSコンプライアンスのブログ記事](https://www.haproxy.com/blog/become-fips-compliant-with-haproxy-enterprise-on-red-hat-enterprise-linux-8) +- [認定OpenShift Operator](https://catalog.redhat.com/software/container-stacks/detail/5ec3f9fc110f56bd24f2dd57) +- [プライベートレジストリからイメージを使用する方法](https://github.com/haproxytech/helm-charts/blob/kubernetes-ingress-1.22.0/haproxy/README.md#installing-from-a-private-registry) +- [HAProxy Enterpriseイメージを見つける方法](https://www.haproxy.com/documentation/haproxy-enterprise/getting-started/installation/docker/) diff --git a/doc-locale/ja-jp/charts/minio/_index.md b/doc-locale/ja-jp/charts/minio/_index.md new file mode 100644 index 0000000000..3769117df3 --- /dev/null +++ b/doc-locale/ja-jp/charts/minio/_index.md @@ -0,0 +1,270 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: オブジェクトストレージにMinIOを使用する +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +このチャートは、[`stable/minio`](https://github.com/helm/charts/tree/master/stable/minio)バージョン[`0.4.3`](https://github.com/helm/charts/tree/aaaf98b5d25c26cc2d483925f7256f2ce06be080/stable/minio)に基づいており、ほとんどの設定をそこから継承します。 + +## 設計上の選択 {#design-choices} + +[アップストリームチャート](https://github.com/helm/charts/tree/master/stable/minio)に関する設計上の選択は、プロジェクトのReadmeにあります。 + +GitLabは、シークレットの設定を簡素化し、環境変数でのシークレットの使用をすべて削除するために、そのチャートを変更することを選択しました。GitLabは、シークレットを`config.json`に投入するのを制御するために`initContainer`を追加し、チャート全体の`enabled`フラグを追加しました。 + +このチャートは、1つのシークレットのみを使用します。 + +- `global.minio.credentials.secret`:`accesskey`および`secretkey`の値を格納するグローバルシークレットで、バケットへの認証に使用されます。 + +## 設定 {#configuration} + +以下に、設定の主要なセクションをすべて説明します。親チャートから設定する場合、これらの値は次のようになります。 + +```yaml +minio: + init: + ingress: + enabled: + apiVersion: + tls: + enabled: + secretName: + annotations: + configureCertmanager: + proxyReadTimeout: + proxyBodySize: + proxyBuffering: + tolerations: + persistence: # Upstream + volumeName: + matchLabels: + matchExpressions: + annotations: + serviceType: # Upstream + servicePort: # Upstream + defaultBuckets: + minioConfig: # Upstream +``` + +### コマンドラインオプションのインストール {#installation-command-line-options} + +次の表に、`--set`フラグを使用して`helm install`コマンドに指定できる、可能なすべてのチャート設定を示します。 + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|--------------------------------|-------------| +| `common.labels` | `{}` | このチャートによって作成されたすべてのオブジェクトに適用される補助ラベル。 | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `defaultBuckets` | `[{"name": "registry"}]` | MinIOデフォルトバケット | +| `deployment.strategy` | ``{ `type`: `Recreate` }`` | デプロイで使用される更新戦略を構成できます | +| `image` | `minio/minio` | MinIOイメージ | +| `imagePullPolicy` | `Always` | MinIOイメージプルポリシー | +| `imageTag` | `RELEASE.2017-12-28T01-21-00Z` | MinIOイメージtag | +| `minioConfig.browser` | `on` | MinIOブラウザフラグ | +| `minioConfig.domain` | | MinIOドメイン | +| `minioConfig.region` | `us-east-1` | MinIOリージョン | +| `minioMc.image` | `minio/mc` | MinIO mcイメージ | +| `minioMc.tag` | `latest` | MinIO mcイメージtag | +| `mountPath` | `/export` | MinIO設定ファイルのマウントパス | +| `persistence.accessMode` | `ReadWriteOnce` | MinIO永続性アクセスモード | +| `persistence.annotations` | | MinIO PersistentVolumeClaimアノテーション | +| `persistence.enabled` | `true` | MinIO永続性フラグを有効にする | +| `persistence.matchExpressions` | | バインドするMinIOラベル式の一致 | +| `persistence.matchLabels` | | バインドするMinIOラベル値の一致 | +| `persistence.size` | `10Gi` | MinIO永続ボリュームサイズ | +| `persistence.storageClass` | | プロビジョニング用のMinIO storageClassName | +| `persistence.subPath` | | MinIO永続ボリュームマウントパス | +| `persistence.volumeName` | | MinIO既存の永続ボリューム名 | +| `priorityClassName` | | ポッドに割り当てられた[優先](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)クラス。 | +| `pullSecrets` | | イメージのシークレット | +| `resources.requests.cpu` | `250m` | MinIOがする最小CPU | +| `resources.requests.memory` | `256Mi` | MinIOがする最小メモリ | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権とを変更するための (Kubernetes 1.23が必要) | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext.runAsUser` | `1000` | コンテナの起動元の特定のセキュリティコンテキストを上書きできます | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | Gitalyコンテナのプロセスが親プロセスよりも多くの特権を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `servicePort` | `9000` | MinIOサービス | +| `serviceType` | `ClusterIP` | MinIOサービスタイプ | +| `tolerations` | `[]` | ポッドの容認 | +| `jobAnnotations` | `{}` | ジョブのアノテーション | + +## チャート設定例 {#chart-configuration-examples} + +### `pullSecrets` {#pullsecrets} + +`pullSecrets`を使用すると、プライベートに対してして、ポッドのイメージをできます。 + +プライベートレジストリとその[認証](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)方法に関する追加の詳細は、[Kubernetes](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)ドキュメントにあります。 + +以下は`pullSecrets`の使用例です。 + +```yaml +image: my.minio.repository +imageTag: latest +imagePullPolicy: Always +pullSecrets: +- name: my-secret-name +- name: my-secondary-secret-name +``` + +### `serviceAccount` {#serviceaccount} + +このセクションでは、デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これを有効にしないでください (たとえば、Istio)。 | + +### `tolerations` {#tolerations} + +`tolerations`を使用すると、taintされたノードでポッドをスケジュールできます + +以下は`tolerations`の使用例です。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +## サブチャートを有効にする {#enable-the-sub-chart} + +コンパートメント化されたサブチャートを実装するために私たちが選択した方法は、特定ので不要なコンポーネントを無効にする機能を含みます。このため、最初に決定する必要がある設定は`enabled:`です。 + +デフォルトでは、MinIOはすぐに使用できるように有効になっていますが、本番環境での使用は推奨されません。無効にする準備ができたら、`--set global.minio.enabled: false`を実行します。 + +## `initContainer`を設定する {#configure-the-initcontainer} + +めったに変更されませんが、`initContainer`の動作は、次の項目を使用して変更できます。 + +```yaml +init: + image: + repository: + tag: + pullPolicy: IfNotPresent + script: +``` + +### initContainerイメージ {#initcontainer-image} + +initContainerイメージは、通常のイメージと同じです。デフォルトでは、チャートローカルの値は空のままになり、グローバル設定である`global.gitlabBase.image.repository`および現在の`global.gitlabVersion`に関連付けられたイメージtagは、initContainerイメージのpopulatedに使用されます。グローバル設定は、チャートローカルの値（例：`minio.init.image.tag`）で上書きできます。 + +### initContainerスクリプト {#initcontainer-script} + +initContainerには、次の項目が渡されます。 + +- `/config`にマウントされた認証項目を含むシークレット。通常は`accesskey`および`secretkey`です。 +- `config.json`テンプレートを含むConfigMapと、`sh`で実行されるスクリプトを含む`configure`が`/config`にマウントされます。 +- `/minio`にマウントされた`emptyDir`。デーモンのコンテナにされます。 + +initContainerは、`/config/configure`スクリプトを使用して、完成した設定で`/minio/config.json`をpopulateすることが期待されています。`minio-config` [コンテナ](https://min.io)がそのタスクを完了すると、`/minio` [ディレクトリ](https://min.io)が`minio` [コンテナ](https://min.io)に渡され、[MinIO](https://min.io)サーバーに`config.json`を提供するために使用されます。 + +## Ingressの設定 {#configuring-the-ingress} + +これらのは、MinIO Ingressを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------------------|:-------:|:--------|:------------| +| `apiVersion` | 文字列 | | `apiVersion`フィールドで使用する値。 | +| `annotations` | 文字列 | | このフィールドは、[Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)の標準`annotations`と完全に一致します。 | +| `enabled` | ブール値 | `false` | それをサポートするサービスに対してIngressオブジェクトを作成するかどうかを制御する。`false`の場合、`global.ingress.enabled`が使用されます。 | +| `configureCertmanager` | ブール値 | | Ingressアノテーション`cert-manager.io/issuer`と`acme.cert-manager.io/http01-edit-in-place`を切り替えます。詳細については、[GitLab PagesのTLS要件](../../installation/tls.md)を参照してください。 | +| `tls.enabled` | ブール値 | `true` | `false`に設定すると、MinIOのTLSを無効にします。これは、IngressレベルでTLSターミネーションを使用できない場合に特に役立ちます。たとえば、Ingressコントローラーの前にTLSターミネーションプロキシがある場合などです。 | +| `tls.secretName` | 文字列 | | MinIO URLの有効な証明書とを含むKubernetes TLSの名前。設定されていない場合、代わりに`global.ingress.tls.secretName`が使用されます。 | + +## イメージの設定 {#configuring-the-image} + +`image`、`imageTag`、`imagePullPolicy`のデフォルトは、[アップストリームでドキュメント化](https://github.com/helm/charts/tree/master/stable/minio#configuration)されています。 + +## 永続 {#persistence} + +このチャートは`PersistentVolumeClaim`をプロビジョニングし、対応する永続ボリュームをデフォルトの場所`/export`にマウントします。これが機能するには、Kubernetesクラスターで使用可能な物理ストレージが必要です。`emptyDir`を使用する場合は、`PersistentVolumeClaim`を`persistence.enabled: false`で無効にします。 + +[`persistence`](https://github.com/helm/charts/tree/master/stable/minio#persistence)の動作は、[アップストリームでドキュメント化](https://github.com/helm/charts/tree/master/stable/minio#configuration)されています。 + +GitLabにはいくつかの項目が追加されています。 + +```yaml +persistence: + volumeName: + matchLabels: + matchExpressions: +``` + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------|:------:|:--------|:------------| +| `volumeName` | 文字列 | `false` | `volumeName`が指定されている場合、`PersistentVolumeClaim`は、動的に`PersistentVolume`を作成する代わりに、指定された名前で`PersistentVolume`を使用します。これは、アップストリームの動作を上書きします。 | +| `matchLabels` | マップ | `true` | バインドするボリュームを選択するときに、照合する名と値のマップを受け入れます。これは、`PersistentVolumeClaim` `selector`セクションで使用されます。[ボリュームドキュメント](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector)を参照してください。 | +| `matchExpressions` | 配列 | | バインドするボリュームを選択するときに、照合する条件オブジェクトの配列を受け入れます。これは、`PersistentVolumeClaim` `selector`セクションで使用されます。[ボリュームドキュメント](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#selector)を参照してください。 | + +## `defaultBuckets` {#defaultbuckets} + +`defaultBuckets`は、*インストール*時にMinIOポッドにバケットを自動的に作成するメカニズムを提供します。このプロパティには、最大3つのプロパティ ( `name`、`policy`、および`purge`) を持つ項目の配列が含まれています。 + +```yaml +defaultBuckets: + - name: public + policy: public + purge: true + - name: private + - name: public-read + policy: download +``` + +| 名前 | 種類 | デフォルト | 説明 | +|:---------|:-------:|:--------|:------------| +| `name` | 文字列 | | 作成されるバケットの名前。指定された値は、[AWSバケット命名規則](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html)に準拠している必要があります。つまり、に準拠し、長さが3 ～ 63文字の文字列で文字a ～ z、0 ～ 9、および - (ハイフン) のみを含む必要があります。`name`プロパティは、すべての_エントリ_に_必須_です。 | +| `policy` | | `none` | `policy`の値は、MinIOのバケットのアクセスを制御します。`policy`プロパティは必須ではなく、デフォルト値は`none`です。**匿名**アクセスに関して、可能な値は次のとおりです: `none` (匿名アクセスなし)、`download` (匿名の読み取り専用アクセス)、`upload` (匿名の書き込み専用アクセス) または`public` (匿名の読み取り/書き込みアクセス)。 | +| `purge` | ブール値 | | `purge`プロパティは、インストール時に既存のバケットを強制的に削除するための手段として提供されます。これは、[永続](#persistence)性のvolumeNameプロパティに既存の`PersistentVolume`を使用する場合にのみ有効になります。動的に作成された`PersistentVolume`を使用する場合、これはチャートのインストール時にのみ発生し、作成されたばかりの`PersistentVolume`にデータが存在しないため、有効な効果はありません。このプロパティは必須ではありませんが、バケットを強制的にパージするには、`true`の値でこのプロパティを指定できます`mc rm -r --force`。 | + +## セキュリティコンテキスト {#security-context} + +これらのオプションを使用すると、ポッドの起動に使用される`user`および/または`group`を制御できます。 + +セキュリティコンテキストの詳細については、公式の[Kubernetesドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/)を参照してください。 + +## サービスタイプとポート {#service-type-and-port} + +これらは[アップストリームでドキュメント化](https://github.com/helm/charts/tree/master/stable/minio#configuration)されており、キーの概要は次のとおりです。 + +```yaml +## Expose the MinIO service to be accessed from outside the cluster (LoadBalancer service). +## or access it from within the cluster (ClusterIP service). Set the service type and the port to serve it. +## ref: http://kubernetes.io/docs/user-guide/services/ +## +serviceType: LoadBalancer +servicePort: 9000 +``` + +チャートは`type: NodePort`であるとは想定されていないため、そのように設定**しないでください**。 + +## アップストリーム項目 {#upstream-items} + +次の[アップストリームドキュメント](https://github.com/helm/charts/tree/master/stable/minio)も、このチャートに完全に適用されます。 + +- `resources` +- `nodeSelector` +- `minioConfig` + +`minioConfig`設定の詳細な説明については、[MinIO通知ドキュメント](https://min.io/docs/minio/kubernetes/upstream/index.html)を参照してください。これには、バケットオブジェクトがアクセスまたは変更されたときにを公開する方法の詳細が含まれています。 diff --git a/doc-locale/ja-jp/charts/nginx/_index.md b/doc-locale/ja-jp/charts/nginx/_index.md new file mode 100644 index 0000000000..41d4a925c5 --- /dev/null +++ b/doc-locale/ja-jp/charts/nginx/_index.md @@ -0,0 +1,147 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: NGINXの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +Ingressコントローラーとして使用される完全なNGINXデプロイを提供します。すべてのKubernetesプロバイダーがネイティブでNGINX [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#tls)をサポートしているわけではありません。互換性を確保するためです。 + +{{< alert type="note" >}} + +- GitLab NGINXチャートは、アップストリームNGINX Helmチャートのフォークです。私たちのフォークで何が変更されたかについて詳しくは、[NGINXフォークへの調整](#adjustments-to-the-nginx-fork)をご覧ください。 +- 1つの`global.hosts.domain`の値のみが可能です。複数のドメインのサポートは、[イシュー3147](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3147)で追跡されています。 + +{{< /alert >}} + +## NGINXの設定 {#configuring-nginx} + +設定の詳細については、[NGINXチャートのドキュメント](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/nginx-ingress/README.md#configuration)を参照してください。 + +### グローバル設定 {#global-settings} + +チャート間でいくつかの共通グローバル設定を共有します。GitLabやレジストリのホスト名など、共通の[設定](../globals.md)オプションについては、[グローバルドキュメント](../globals.md)を参照してください。 + +## グローバル設定を使用したホストの設定 {#configure-hosts-using-the-global-settings} + +GitLabサーバーとレジストリサーバーのホスト名は、[グローバル設定](../globals.md)チャートを使用して設定できます。 + +## GitLab Geo {#gitlab-geo} + +2番目のNGINXサブチャートがバンドルされており、GitLab Geoトラフィック用に事前設定されています。これは、デフォルトコントローラーと同じ設定をサポートします。コントローラーは`nginx-ingress-geo.enabled=true`で有効にできます。 + +このコントローラーは、受信`X-Forwarded-*`ヘッダーを変更しないように構成されています。Geoトラフィックに別のプロバイダーを使用する場合は、同じことを確認してください。 + +デフォルトコントローラーの値（`nginx-ingress-geo.controller.ingressClassResource.controllerValue`）は`k8s.io/nginx-ingress-geo`に設定され、IngressClass名は`{ReleaseName}-nginx-geo`に設定され、デフォルトコントローラーとの干渉を回避します。IngressClass名は、`global.geo.ingressClass`でオーバーライドできます。 + +カスタムヘッダー処理は、セカンダリサイトから転送されたトラフィックを処理するために、プライマリGeoサイトでのみ必要です。サイトがプライマリにプロモートされる予定の場合、セカンダリでのみ使用する必要があります。 + +フェイルオーバー中にIngressClassを変更すると、他のコントローラーが受信トラフィックを処理することに注意してください。他のコントローラーには異なるロードバランサーIPが割り当てられているため、DNS設定に追加の変更が必要になる場合があります。 + +これは、すべてのGeoサイトでGeo Ingressコントローラーを有効にし、関連付けられたIngressClass（`useGeoClass=true`）を使用するようにデフォルトおよび追加のウェブサービスIngressを設定することで回避できます。 + +## アノテーション値のワードブロックリスト {#annotation-value-word-blocklist} + +{{< history >}} + +- [GitLab Helmチャート6.6](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2713)で導入。 + +{{< /history >}} + +クラスターオペレーターが生成されたNGINX[設定](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)をより詳細に制御する必要がある状況では、NGINX Ingressは、標準のアノテーションとConfigMap[エントリ](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)で処理されないraw NGINX[設定](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)の「スニペット」を挿入する[設定スニペット](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)を許可します。 + +これらの設定スニペットの欠点は、クラスターオペレーターが、LUAスクリプトや、GitLabインストールとクラスター自体のセキュリティを侵害する可能性のある同様の設定（serviceaccountトークンやシークレットの公開など）を含むIngressオブジェクトをデプロイできることです。 + +詳細については、[CVE-2021-25742](https://nvd.nist.gov/vuln/detail/CVE-2021-25742)および[このアップストリーム`ingress-nginx`イシュー](https://github.com/kubernetes/ingress-nginx/issues/7837)を参照してください。 + +GitLabのHelmチャート[デプロイ](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v6.6.0/values.yaml#L836)でCVE-2021-25742を[緩和](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v6.6.0/values.yaml#L836)するために、`nginx-ingress`コミュニティからの推奨[設定](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist)を使用して、[アノテーション値ワードブロックリスト](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/v6.6.0/values.yaml#L836)を設定します + +GitLab Ingress設定で設定スニペットを使用している場合、または設定スニペットを使用するサードパーティのIngressオブジェクトでGitLab NGINX Ingressコントローラーを使用している場合は、GitLabサードパーティドメインにアクセスしようとすると`404`エラーが発生し、`nginx-controller`ログに「無効な単語」エラーが発生する可能性があります。その場合は、`nginx-ingress.controller.config.annotation-value-word-blocklist`設定を確認して調整してください。 + +チャートの[トラブルシューティングドキュメント](../../troubleshooting/_index.md#invalid-word-errors-in-the-nginx-controller-logs-and-404-errors)の`nginx-controller`ログおよび`404`エラーの「無効な単語」エラーも参照してください。 + +## NGINXフォークへの調整 {#adjustments-to-the-nginx-fork} + +{{< alert type="note" >}} + +NGINX[チャート](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/nginx-ingress)の[フォーク](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/nginx-ingress)は、[GitHub](https://github.com/kubernetes/ingress-nginx)から[プル](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/charts/nginx-ingress)されました。 + +{{< /alert >}} + +次の調整がNGINXフォークに加えられました。 + +- `tcp-configmap.yaml`：新しい`tcpExternalConfig`設定に応じてオプション +- 別のチャートからテンプレート化されたTCP ConfigMap名を使用する機能 + - `controller-configmap-tcp.yaml`：`.metadata.name`はテンプレート`ingress-nginx.tcp-configmap`です + - `controller-deployment.yaml`：`.spec.template.spec.containers[0].args`は、ConfigMap名に`ingress-nginx.tcp-configmap`テンプレートを使用します + - GitLabチャートは`ingress-nginx.tcp-configmap`をオーバーライドして、`gitlab/gitlab-org/charts/gitlab-shell`がTCPサービスを設定できるようにします +- リリース名に基づいて、テンプレート化されたIngress名を使用する機能 +- `controller.service.loadBalancerIP`を`externalIpTpl`に置き換えます（デフォルトは`global.hosts.externalIP`） +- `common.labels`設定オプションを介して共通ラベルを追加するサポートを追加 +- `controller-deployment.yaml`: + - `podlabels`と`global.pod.labels`を`.spec.template.metadata.labels`に追加 +- `default-backend-deployment.yaml`: + - `podlabels`と`global.pod.labels`を`.spec.template.metadata.labels`に追加 +- NGINXのデフォルトのnodeSelectorsを無効にします。 +- PDB `maxUnavailable`のサポートを追加しました。 +- `charts/nginx-ingress/templates/_helpers.tpl`のNGINXの`isControllerTagValid`ヘルパーを削除します + - 2020年に[実装](https://github.com/kubernetes/ingress-nginx/pull/5252)されてから、チェックは更新されていませんでした。 + - [\#3383](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3383)の一部として、`ubi`を含む[タグ](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3383)を参照する必要があります。これは、`semverCompare`がとにかく期待どおりに機能しないことを意味します。 +- HPAでautoscaling/v2beta2およびautoscaling/v2 APIのサポートを追加し、HPA設定を拡張して、メモリーとカスタムメトリクス、および動作設定をサポートしました。 +- PodDisruptionBudgetのAPIバージョンの条件付きサポートを追加しました。 +- 外部サービスと内部サービス（`controller.service.internal.enabled`で有効になっている場合）に対して、GitLab Shell（SSHアクセス）を個別に有効/無効にするには、次のブール値を追加します。 + - `controller.service.enableShell`。 + - `controller.service.internal.enableShell`。（`controller.service.enableHttp(s)`の既存のチャートパターンに従います） +- テンプレート呼び出し`{{ include "ingress-nginx.automountServiceAccountToken" . }}`を`controller-serviceaccount.yaml`に追加します +- テンプレートを`_helpers.tpl`に追加します： + + ```go + {{/* + Set if the default ServiceAccount token should be mounted by Kubernetes or not. + + Default is 'true' + */}} + {{- define "ingress-nginx.automountServiceAccountToken" -}} + automountServiceAccountToken: {{ pluck "automountServiceAccountToken" .Values.serviceAccount .Values.global.serviceAccount | first }} + {{- end -}} + ``` + +- テンプレート呼び出し`{{ include "ingress-nginx.defaultBackend.automountServiceAccountToken" . }}`を`default-backend-serviceaccount.yaml`に追加します +- テンプレートを`_helpers.tpl`に追加します： + + ```go + {{/* + Set if the default ServiceAccount token should be mounted by Kubernetes or not. + + Default is 'true' + */}} + {{- define "ingress-nginx.defaultBackend.automountServiceAccountToken" -}} + automountServiceAccountToken: {{ pluck "automountServiceAccountToken" .Values.defaultBackend.serviceAccount .Values.global.serviceAccount | first }} + {{- end -}} + ``` + +- Pod Security Standards Profile Restrictedに準拠するために、次の属性を追加します。 + - `controller-deployment.yaml` + - `spec.template.spec.containers[0].securityContext.runAsNonRoot` + - `spec.template.spec.containers[0].securityContext.seccompProfile` +- 次の新しいRBACルールを追加します。これは、チャートが4.0.6の場合に必要ですが、コントローラーイメージを1.11.2にバンプしました。チャートを4.11.2にすると、このパッチを削除できます。これは、コントローラーがエンドポイントの追跡にendpointslicesを使用するようになったために必要でした。これは、`charts/nginx-ingress/templates/clusterrole.yaml`と`charts/nginx-ingress/templates/controller-role.yaml`の両方に追加されました。 + + ```yaml + - apiGroups: + - discovery.k8s.io + resources: + - endpointslices + verbs: + - list + - watch + - get + ``` + + また、v1.3.1からv1.11.2以降への移行をサポートするために、独自のRBACルールを設定したユーザーは、RBACルールを適宜更新してください。v1.3.1イメージにフォールバックしなくなりました。 diff --git a/doc-locale/ja-jp/charts/nginx/fork.md b/doc-locale/ja-jp/charts/nginx/fork.md new file mode 100644 index 0000000000..340785cce4 --- /dev/null +++ b/doc-locale/ja-jp/charts/nginx/fork.md @@ -0,0 +1,14 @@ +--- +redirect_to: '_index.md#adjustments-to-the-nginx-fork' +remove_date: '2025-07-12' +title: NGINXフォーク +--- + + + +この[ドキュメント](_index.md#adjustments-to-the-nginx-fork)は、[別の場所](_index.md#adjustments-to-the-nginx-fork)に移動しました。 + + + + + diff --git a/doc-locale/ja-jp/charts/registry/_index.md b/doc-locale/ja-jp/charts/registry/_index.md new file mode 100644 index 0000000000..96aec07db5 --- /dev/null +++ b/doc-locale/ja-jp/charts/registry/_index.md @@ -0,0 +1,1376 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: コンテナレジストリの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`registry`サブチャートは、Kubernetes上の完全なクラウドネイティブGitLabデプロイメントにRegistryコンポーネントを提供します。このサブチャートは、[アップストリームチャート](https://github.com/docker/distribution-library-image)に基づいており、GitLab [コンテナレジストリ](https://gitlab.com/gitlab-org/container-registry)が含まれています。 + +このチャートは、主に次の3つの部分で構成されています。 + +- [サービス](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/templates/service.yaml)、 +- [デプロイ](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/templates/deployment.yaml)、 +- [ConfigMap](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/templates/configmap.yaml)。 + +すべての設定は、`/etc/docker/registry/config.yml`変数を使用して、[Registry設定ドキュメント](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads)に従って処理され、`ConfigMap`から`Deployment`に入力されます。`ConfigMap`はアップストリームのデフォルトをオーバーライドしますが、[それらに基づいています](https://github.com/docker/distribution-library-image/blob/master/config-example.yml)。詳細については、以下を参照してください。 + +- [`distribution/cmd/registry/config-example.yml`](https://github.com/docker/distribution/blob/master/cmd/registry/config-example.yml) +- [`distribution-library-image/config-example.yml`](https://github.com/docker/distribution-library-image/blob/master/config-example.yml) + +## 設計の選択 {#design-choices} + +Kubernetes `Deployment`は、インスタンスの簡単なスケーリングを可能にすると同時に、[ローリングアップデート](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/)を可能にするために、このチャートのデプロイ方法として選択されました。 + +このチャートでは、2つの必須シークレットと1つのオプションのシークレットを使用します。 + +### 必須 {#required} + +- `global.registry.certificate.secret`:関連付けられたGitLabインスタンスによって提供される認証トークンを検証するための公開証明書バンドルを含むグローバルシークレット。認証エンドポイントとしてGitLabを使用する方法については、[ドキュメント](https://docs.gitlab.com/administration/packages/container_registry/#use-an-external-container-registry-with-gitlab-as-an-auth-endpoint)を参照してください。 +- `global.registry.httpSecret.secret`:レジストリポッド間の[共有シークレット](https://distribution.github.io/distribution/about/configuration/#http)を含むグローバルシークレット。 + +### オプション {#optional} + +- `profiling.stackdriver.credentials.secret`:Stackdriver profilingが有効になっていて、明示的なサービスアカウント認証情報を提供する必要がある場合、このシークレットの値 (`credentials`キー (デフォルト)) はGCPサービスアカウントJSON認証情報です。GKEを使用していて、[ワークロードアイデンティティ](https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity) (またはノードサービスアカウント (推奨されません)) を使用してサービスアカウントをワークロードに提供している場合、このシークレットは不要であり、提供しないでください。どちらの場合も、サービスアカウントにはロール`roles/cloudprofiler.agent`または同等の[手動権限](https://cloud.google.com/profiler/docs/iam#roles)が必要です。 + +## 設定 {#configuration} + +以下に、設定の主要なセクションについて説明します。親チャートから設定する場合、これらの値は次のようになります。 + +```yaml +registry: + enabled: + maintenance: + readonly: + enabled: false + uploadpurging: + enabled: true + age: 168h + interval: 24h + dryrun: false + image: + tag: 'v4.15.2-gitlab' + pullPolicy: IfNotPresent + annotations: + service: + type: ClusterIP + name: registry + httpSecret: + secret: + key: + authEndpoint: + tokenIssuer: + certificate: + secret: gitlab-registry + key: registry-auth.crt + deployment: + terminationGracePeriodSeconds: 30 + draintimeout: '0' + hpa: + minReplicas: 2 + maxReplicas: 10 + cpu: + targetAverageUtilization: 75 + behavior: + scaleDown: + stabilizationWindowSeconds: 300 + storage: + secret: + key: storage + extraKey: + validation: + disabled: true + manifests: + referencelimit: 0 + payloadsizelimit: 0 + urls: + allow: [] + deny: [] + notifications: {} + tolerations: [] + affinity: {} + ingress: + enabled: false + tls: + enabled: true + secretName: redis + annotations: + configureCertmanager: + proxyReadTimeout: + proxyBodySize: + proxyBuffering: + networkpolicy: + enabled: false + egress: + enabled: false + rules: [] + ingress: + enabled: false + rules: [] + serviceAccount: + create: false + automountServiceAccountToken: false + tls: + enabled: false + secretName: + verify: true + caSecretName: + cipherSuites: +``` + +このチャートをスタンドアロンとしてデプロイする場合は、最上位レベルにある`registry`を削除します。 + +## インストールパラメータ {#installation-parameters} + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------|----------------------------------------------------------------------|-------------| +| `annotations` | | Podアノテーション | +| `podLabels` | | 補助的なPodラベル。セレクターには使用されません。 | +| `common.labels` | | このチャートによって作成されたすべてのオブジェクトに適用される補助ラベル。 | +| `authAutoRedirect` | `true` | 認証自動リダイレクト (Windowsクライアントが動作するにはtrueである必要があります) | +| `authEndpoint` | `global.hosts.gitlab.name` | 認証エンドポイント (ホストとポートのみ) | +| `certificate.secret` | `gitlab-registry` | JWT証明書 | +| `debug.addr.port` | `5001` | デバッグポート | +| `debug.tls.enabled` | `false` | レジストリのデバッグポートに対してTLSを有効にします。メトリクスのエンドポイント (有効な場合) だけでなく、稼働状態および準備状態のプローブにも影響します | +| `debug.tls.secretName` | | レジストリのデバッグエンドポイントの有効な証明書とキーを含むKubernetes TLSシークレットの名前。設定されておらず、`debug.tls.enabled=true`の場合、デバッグTLS設定はデフォルトでレジストリのTLS証明書になります。 | +| `debug.prometheus.enabled` | `false` | **非推奨** `metrics.enabled`を使用 | +| `debug.prometheus.path` | `""` | **非推奨** `metrics.path`を使用 | +| `metrics.enabled` | `false` | メトリクスのエンドポイントをスクレイピングに使用できるようにする必要がある場合 | +| `metrics.path` | `/metrics` | メトリクスのエンドポイントパス | +| `metrics.serviceMonitor.enabled` | `false` | ServiceMonitorを作成してPrometheus Operatorがメトリクスのスクレイピングを管理できるようにする場合、これを有効にすると、`prometheus.io`スクレイプアノテーションが削除されることに注意してください | +| `metrics.serviceMonitor.additionalLabels` | `{}` | ServiceMonitorに追加する追加ラベル | +| `metrics.serviceMonitor.endpointConfig` | `{}` | ServiceMonitorの追加のエンドポイント構成 | +| `deployment.terminationGracePeriodSeconds` | `30` | Podが正常に終了するために必要なオプションの秒単位の期間。 | +| `deployment.strategy` | `{}` | デプロイメントで使用される更新戦略を構成できます | +| `draintimeout` | `'0'` | SIGTERMシグナルを受信した後、HTTP接続のドレインを待機する時間 (例: `'10s'`) | +| `relativeurls` | `false` | ロケーションヘッダーでレジストリが相対URLを返すようにします。 | +| `enabled` | `true` | レジストリフラグを有効にする | +| `extraContainers` | | 含めるコンテナのリストを含む複数行のリテラルスタイル文字列 | +| `extraInitContainers` | | 含める追加のinitコンテナのリスト | +| `hpa.behavior` | `{scaleDown: {stabilizationWindowSeconds: 300 }}` | Behaviorには、アップスケールおよびダウンスケールBehaviorの仕様が含まれています (`autoscaling/v2beta2`以上が必要です) | +| `hpa.customMetrics` | `[]` | カスタムメトリクスには、目的のレプリカ数を計算するために使用する仕様が含まれています (デフォルトの`targetAverageUtilization`で構成された平均CPU使用率の使用をオーバーライドします) | +| `hpa.cpu.targetType` | `Utilization` | オートスケールCPUターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.cpu.targetAverageValue` | | オートスケールCPUターゲット値を設定する | +| `hpa.cpu.targetAverageUtilization` | `75` | オートスケールCPUターゲット使用率を設定する | +| `hpa.memory.targetType` | | オートスケールメモリーターゲットタイプを設定します。`Utilization`または`AverageValue`のいずれかである必要があります | +| `hpa.memory.targetAverageValue` | | オートスケールメモリーターゲット値を設定する | +| `hpa.memory.targetAverageUtilization` | | オートスケールメモリーターゲット使用率を設定する | +| `hpa.minReplicas` | `2` | レプリカの最小数 | +| `hpa.maxReplicas` | `10` | レプリカの最大数 | +| `httpSecret` | | HTTPSシークレット | +| `extraEnvFrom` | | 公開する他のデータソースからの追加の環境変数のリスト | +| `image.pullPolicy` | | レジストリイメージのプルポリシー | +| `image.pullSecrets` | | イメージリポジトリに使用するシークレット | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-container-registry` | レジストリイメージ | +| `image.tag` | `v4.15.2-gitlab` | 使用するイメージのバージョン | +| `init.image.repository` | | initContainerイメージ | +| `init.image.tag` | | initContainerイメージtag | +| `init.containerSecurityContext` | | initContainer固有の[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core) | +| `init.containerSecurityContext.runAsUser` | `1000` | initContainer固有:コンテナを開始するユーザーID | +| `init.containerSecurityContext.allowPrivilegeEscalation` | `false` | initContainer固有:プロセスが親プロセスよりも多くの権限を取得できるかどうかを制御します | +| `init.containerSecurityContext.runAsNonRoot` | `true` | initContainer固有:コンテナを非rootユーザーで実行するかどうかを制御します | +| `init.containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | initContainer固有:コンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `keda.enabled` | `false` | `HorizontalPodAutoscalers`の代わりに[KEDA](https://keda.sh/) `ScaledObjects`を使用 | +| `keda.pollingInterval` | `30` | 各トリガーをチェックする間隔 | +| `keda.cooldownPeriod` | `300` | リソースを0にスケールバックする前に、最後のトリガーがアクティブとレポートされてから待機する期間 | +| `keda.minReplicaCount` | `hpa.minReplicas` | KEDAがリソースをスケールダウンするレプリカの最小数。 | +| `keda.maxReplicaCount` | `hpa.maxReplicas` | KEDAがリソースをスケールアップするレプリカの最大数。 | +| `keda.fallback` | | KEDAフォールバック構成については、[ドキュメント](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)を参照してください | +| `keda.hpaName` | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `keda.restoreToOriginalReplicaCount` | | `ScaledObject`の削除後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `keda.behavior` | `hpa.behavior` | アップスケールおよびダウンスケールBehaviorの仕様。 | +| `keda.triggers` | | ターゲットリソースのスケーリングをアクティブ化するトリガーのリスト。デフォルトでは、`hpa.cpu`および`hpa.memory`から計算されたトリガーになります | +| `log` | `{level: info, fields: {service: registry}}` | ログ記録オプションを設定する | +| `minio.bucket` | `global.registry.bucket` | レガシーレジストリバケット名 | +| `maintenance.readonly.enabled` | `false` | レジストリの読み取り専用モードを有効にする | +| `maintenance.uploadpurging.enabled` | `true` | アップロードのパージを有効にする | +| `maintenance.uploadpurging.age` | `168h` | 指定された期間より古いアップロードをパージする | +| `maintenance.uploadpurging.interval` | `24h` | アップロードのパージが実行される頻度 | +| `maintenance.uploadpurging.dryrun` | `false` | 削除せずにパージされるアップロードのみを一覧表示する | +| `priorityClassName` | | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 | +| `reporting.sentry.enabled` | `false` | Sentryを使用したレポート作成を有効にする | +| `reporting.sentry.dsn` | | Sentry DSN (データソース名) | +| `reporting.sentry.environment` | | Sentry [環境](https://docs.sentry.io/concepts/key-terms/environments/) | +| `profiling.stackdriver.enabled` | `false` | Stackdriverを使用した継続的なプロファイリングを有効にする | +| `profiling.stackdriver.credentials.secret` | `gitlab-registry-profiling-creds` | 認証情報を含むシークレットの名前 | +| `profiling.stackdriver.credentials.key` | `credentials` | 認証情報が格納されているシークレットキー | +| `profiling.stackdriver.service` | `RELEASE-registry` (テンプレート化されたサービス名) | プロファイルを記録するStackdriverサービスの名前 | +| `profiling.stackdriver.projectid` | 実行中のGCPプロジェクト | プロファイルをレポートするGCPプロジェクト | +| `database.configure` | `false` | 有効にせずに、レジストリチャートにデータベース設定を入力します。[既存のレジストリを移行する](metadata_database.md#existing-registries)場合に必要です。 | +| `database.enabled` | `false` | メタデータデータベースを有効にします。これは試験的な機能であり、本番環境で使用しないでください。 | +| `database.host` | `global.psql.host` | データベースサーバーのホスト名。 | +| `database.port` | `global.psql.port` | データベースサーバーポート。 | +| `database.user` | | データベースユーザー名。 | +| `database.password.secret` | `RELEASE-registry-database-password` | データベースパスワードを含むシークレットの名前。 | +| `database.password.key` | `password` | データベースパスワードが格納されているシークレットキー。 | +| `database.name` | | データベース名。 | +| `database.sslmode` | | SSLモード。`disable`、`allow`、`prefer`、`require`、`verify-ca`、または`verify-full`のいずれか。 | +| `database.ssl.secret` | `global.psql.ssl.secret` | クライアント証明書、キー、認証局を含むシークレット。デフォルトはメインのPostgreSQL SSLシークレットです。 | +| `database.ssl.clientCertificate` | `global.psql.ssl.clientCertificate` | クライアント証明書を参照するシークレット内のキー。 | +| `database.ssl.clientKey` | `global.psql.ssl.clientKey` | クライアントキーを参照するシークレット内のキー。 | +| `database.ssl.serverCA` | `global.psql.ssl.serverCA` | 認証局 (CA) を参照するシークレット内のキー。 | +| `database.connecttimeout` | `0` | 接続を待機する最大時間。0または指定されていない場合は、無期限に待機することを意味します。 | +| `database.draintimeout` | `0` | シャットダウン時にすべての接続をドレインするまで待機する最大時間。0または指定されていない場合は、無期限に待機することを意味します。 | +| `database.preparedstatements` | `false` | 準備されたステートメントを有効にします。PgBouncerとの互換性のために、デフォルトで無効になっています。 | +| `database.primary` | `false` | ターゲットプライマリデータベースサーバー。これは、registry `database.migrations`の実行時にターゲットとする専用のFQDNを指定するために使用されます。指定されていない場合、`host`は`database.migrations`の実行に使用されます。 | +| `database.pool.maxidle` | `0` | アイドル接続プール内の接続の最大数。`maxopen`が`maxidle`より小さい場合、`maxidle`は`maxopen`の制限に合わせて縮小されます。0または指定されていない場合は、アイドル接続がないことを意味します。 | +| `database.pool.maxopen` | `0` | データベースへのオープン接続の最大数。`maxopen`が`maxidle`より小さい場合、`maxidle`は`maxopen`の制限に合わせて縮小されます。0または指定されていない場合は、無制限のオープン接続を意味します。 | +| `database.pool.maxlifetime` | `0` | 接続を再利用できる最大時間。期限切れの接続は、再利用前に遅延的に閉じられる場合があります。0または指定されていない場合は、無制限の再利用を意味します。 | +| `database.pool.maxidletime` | `0` | 接続がアイドル状態になる可能性がある最大時間。期限切れの接続は、再利用前に遅延的に閉じられる場合があります。0または指定されていない場合は、無制限の期間を意味します。 | +| `database.loadBalancing.enabled` | `false` | データベースのロードバランシングを有効にします。これは試験的な機能であり、本番環境で使用しないでください。 | +| `database.loadBalancing.nameserver.host` | `localhost` | DNSレコードのルックアップに使用するネームサーバーのホスト。 | +| `database.loadBalancing.nameserver.port` | `8600` | DNSレコードのルックアップに使用するネームサーバーのポート。 | +| `database.loadBalancing.record` | | ルックアップするSRVレコード。このオプションは、サービスディスカバリが機能するために必要です。 | +| `database.loadBalancing.replicaCheckInterval` | `1m` | レプリカの状態をチェックする最小時間。 | +| `database.migrations.enabled` | `true` | Chartの最初のデプロイメントおよびアップグレード時に、移行ジョブが自動的に移行を実行できるようにします。移行は、実行中のRegistryポッド内から手動で実行することもできます。 | +| `database.migrations.activeDeadlineSeconds` | `3600` | 移行ジョブで[activeDeadlineSeconds](https://kubernetes.io/docs/concepts/workloads/controllers/job/#job-termination-and-cleanup)を設定します。 | +| `database.migrations.annotations` | `{}` | 移行ジョブに追加する追加のアノテーション。 | +| `database.migrations.backoffLimit` | `6` | 移行ジョブで[backoffLimit](https://kubernetes.io/docs/concepts/workloads/controllers/job/#job-termination-and-cleanup)を設定します。 | +| `database.backgroundMigrations.enabled` | `false` | データベースのバックグラウンド移行を有効にします。これはRegistryメタデータデータベースの実験的な機能です。本番環境では使用しないでください。動作の詳細な説明については、[仕様](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/gitlab/database-background-migrations.md?ref_type=heads)を参照してください。 | +| `database.backgroundMigrations.jobInterval` | | 各バックグラウンド移行ジョブワーカーの実行間のスリープ間隔。指定されていない場合、[デフォルト値はレジストリによって設定されます](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#backgroundmigrations)。 | +| `database.backgroundMigrations.maxJobRetries` | | 失敗したバックグラウンド移行ジョブの最大再試行回数。指定されていない場合、[デフォルト値はレジストリによって設定されます](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#backgroundmigrations)。 | +| `gc.disabled` | `true` | `true`に設定すると、オンラインGCワーカーが無効になります。 | +| `gc.maxbackoff` | `24h` | エラーが発生した場合に、ワーカーの実行間でスリープするために使用される最大指数バックオフ期間。`gc.noidlebackoff`が`true`でない限り、処理するタスクがない場合にも適用されます。最大33% のランダム化されたジッター係数が常に加算されるため、これは絶対的な最大値ではないことに注意してください。 | +| `gc.noidlebackoff` | `false` | `true`に設定すると、処理するタスクがない場合に、ワーカーの実行間の指数バックオフが無効になります。 | +| `gc.transactiontimeout` | `10s` | 各ワーカーの実行のデータベーストランザクションのタイムアウト。各ワーカーは、開始時にデータベーストランザクションを開始します。このタイムアウトを超過すると、停止または長時間実行されるトランザクションを回避するために、ワーカーの実行はキャンセルされます。 | +| `gc.blobs.disabled` | `false` | `true`に設定すると、blobのGCワーカーが無効になります。 | +| `gc.blobs.interval` | `5s` | 各ワーカーの実行間の最初のスリープ間隔。 | +| `gc.blobs.storagetimeout` | `5s` | ストレージ操作のタイムアウト。ストレージバックエンドでぶら下がっているblobを削除するリクエストの期間を制限するために使用されます。 | +| `gc.manifests.disabled` | `false` | `true`に設定すると、マニフェストのGCワーカーが無効になります。 | +| `gc.manifests.interval` | `5s` | 各ワーカーの実行間の最初のスリープ間隔。 | +| `gc.reviewafter` | `24h` | ガベージコレクターがレビュー用にレコードをピックアップする必要がある最小時間。`-1`は待機しないことを意味します。 | +| `securityContext.fsGroup` | `1000` | ポッドを開始するグループID | +| `securityContext.runAsUser` | `1000` | ポッドを開始するユーザーID | +| `securityContext.fsGroupChangePolicy` | | ボリュームの所有権と権限を変更するためのポリシー (Kubernetes 1.23が必要) | +| `securityContext.seccompProfile.type` | `RuntimeDefault` | 使用するSeccompプロファイル | +| `containerSecurityContext` | | コンテナが開始される[securityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#securitycontext-v1-core)をオーバーライドします | +| `containerSecurityContext.runAsUser` | `1000` | コンテナが開始される特定のsecurityContextユーザーIDを上書きできるようにします | +| `containerSecurityContext.allowPrivilegeEscalation` | `false` | Gitalyコンテナのプロセスが親プロセスよりも多くの権限を取得できるかどうかを制御します | +| `containerSecurityContext.runAsNonRoot` | `true` | コンテナを非rootユーザーで実行するかどうかを制御します | +| `containerSecurityContext.capabilities.drop` | `[ "ALL" ]` | Gitalyコンテナの[Linux機能](https://man7.org/linux/man-pages/man7/capabilities.7.html)を削除します | +| `serviceAccount.automountServiceAccountToken` | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを示します | +| `serviceAccount.enabled` | `false` | ServiceAccountを使用するかどうかを示します | +| `serviceLabels` | `{}` | 補助的なサービスラベル | +| `tokenService` | `container_registry` | JWTトークンサービス | +| `tokenIssuer` | `gitlab-issuer` | JWTトークン発行者 | +| `tolerations` | `[]` | ポッド割り当ての容認ラベル | +| `affinity` | `{}` | ポッド割り当てのアフィニティルール | +| `middleware.storage` | | ミドルウェアストレージの構成レイヤー ([インスタンスのS3](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#example-middleware-configuration)) | +| `redis.cache.enabled` | `false` | `true`に設定すると、Redisキャッシュが有効になります。この機能は、[メタデータデータベース](#database)が有効になっているかどうかによって異なります。リポジトリメタデータは、構成されたRedisインスタンスにキャッシュされます。 | +| `redis.cache.host` | `` | Redisインスタンスのホスト名。空の場合、値は`global.redis.host:global.redis.port`として入力されます。 | +| `redis.cache.port` | `6379` | Redisインスタンスのポート。 | +| `redis.cache.sentinels` | `[]` | ホストとポートを持つセンチネルを一覧表示します。 | +| `redis.cache.mainname` | | メインサーバー名。Sentinelにのみ適用されます。 | +| `redis.cache.password.enabled` | `false` | Registryで使用されるRedisキャッシュがパスワードで保護されているかどうかを示します。 | +| `redis.cache.password.secret` | `gitlab-redis-secret` | Redisパスワードを含むシークレットの名前。`shared-secrets`機能が有効になっている場合、これが指定されていない場合は自動的に作成されます。 | +| `redis.cache.password.key` | `redis-password` | Redisパスワードが格納されているシークレットキー。 | +| `redis.cache.sentinelpassword.enabled` | `false` | Redis Sentinelがパスワードで保護されているかどうかを示します。`redis.cache.sentinelpassword`が空の場合、`global.redis.sentinelAuth`の値が使用されます。`redis.cache.sentinels`が定義されている場合にのみ使用されます。 | +| `redis.cache.sentinelpassword.secret` | `gitlab-redis-secret` | Redis Sentinelパスワードを格納しているシークレットの名前。 | +| `redis.cache.sentinelpassword.key` | `redis-sentinel-password` | Redis Sentinelパスワードが格納されているシークレットキー。 | +| `redis.cache.db` | `0` | 各接続に使用するデータベースの名前。 | +| `redis.cache.dialtimeout` | `0s` | Redisインスタンスへの接続のタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.cache.readtimeout` | `0s` | Redisインスタンスからの読み取りのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.cache.writetimeout` | `0s` | Redisインスタンスへの書き込みのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.cache.tls.enabled` | `false` | TLSを有効にするには、`true`に設定します。 | +| `redis.cache.tls.insecure` | `false` | TLS経由で接続する際にサーバー名の検証を無効にするには、`true`に設定します。 | +| `redis.cache.pool.size` | `10` | ソケット接続の最大数。デフォルトは10接続です。 | +| `redis.cache.pool.maxlifetime` | `1h` | クライアントが接続を再試行する接続時間。デフォルトでは、古くなった接続は閉じません。 | +| `redis.cache.pool.idletimeout` | `300s` | 非アクティブな接続を閉じるまでの待機時間。 | +| `redis.rateLimiting.enabled` | `false` | `true`に設定すると、Redisレートリミッターが有効になります。この機能は開発中です。 | +| `redis.rateLimiting.host` | `` | Redisインスタンスのホスト名。空の場合、値は`global.redis.host:global.redis.port`として入力されます。 | +| `redis.rateLimiting.port` | `6379` | Redisインスタンスのポート。 | +| `redis.rateLimiting.cluster` | `[]` | ホストとポートを持つアドレスのリスト。 | +| `redis.rateLimiting.sentinels` | `[]` | ホストとポートを持つSentinelのリスト。 | +| `redis.rateLimiting.mainname` | | mainサーバー名。Sentinelにのみ適用できます。 | +| `redis.rateLimiting.username` | | Redisインスタンスへの接続に使用されるユーザー名。 | +| `redis.rateLimiting.password.enabled` | `false` | Redisインスタンスがパスワードで保護されているかどうかを示します。 | +| `redis.rateLimiting.password.secret` | `gitlab-redis-secret` | Redisパスワードを格納しているシークレットの名前。`shared-secrets`機能が有効になっている場合、これが指定されていない場合は、自動的に作成されます。 | +| `redis.rateLimiting.password.key` | `redis-password` | Redisパスワードが格納されているシークレットキー。 | +| `redis.rateLimiting.db` | `0` | 各接続に使用するデータベースの名前。 | +| `redis.rateLimiting.dialtimeout` | `0s` | Redisインスタンスへの接続のタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.rateLimiting.readtimeout` | `0s` | Redisインスタンスからの読み取りのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.rateLimiting.writetimeout` | `0s` | Redisインスタンスへの書き込みのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.rateLimiting.tls.enabled` | `false` | TLSを有効にするには、`true`に設定します。 | +| `redis.rateLimiting.tls.insecure` | `false` | TLS経由で接続する際にサーバー名の検証を無効にするには、`true`に設定します。 | +| `redis.rateLimiting.pool.size` | `10` | ソケット接続の最大数。 | +| `redis.rateLimiting.pool.maxlifetime` | `1h` | クライアントが接続を再試行するまでの接続時間。デフォルトでは、古くなった接続は閉じません。 | +| `redis.rateLimiting.pool.idletimeout` | `300s` | 無効な接続を閉じるまでに待機する時間。 | +| `redis.loadBalancing.enabled` | `false` | `true`に設定すると、[ロードバランシング](#load-balancing)のRedis接続が有効になります。 | +| `redis.loadBalancing.host` | `` | Redisインスタンスのホスト名。空の場合、値は`global.redis.host:global.redis.port`として入力されます。 | +| `redis.loadBalancing.port` | `6379` | Redisインスタンスのポート。 | +| `redis.loadBalancing.cluster` | `[]` | ホストとポートを持つアドレスのリスト。 | +| `redis.loadBalancing.sentinels` | `[]` | ホストとポートを持つSentinelのリスト。 | +| `redis.loadBalancing.mainname` | | mainサーバー名。Sentinelにのみ適用できます。 | +| `redis.loadBalancing.username` | | Redisインスタンスへの接続に使用されるユーザー名。 | +| `redis.loadBalancing.password.enabled` | `false` | Redisインスタンスがパスワードで保護されているかどうかを示します。 | +| `redis.loadBalancing.password.secret` | `gitlab-redis-secret` | Redisパスワードを格納しているシークレットの名前。`shared-secrets`機能が有効になっている場合、これが指定されていない場合は、自動的に作成されます。 | +| `redis.loadBalancing.password.key` | `redis-password` | Redisパスワードが格納されているシークレットキー。 | +| `redis.loadBalancing.db` | `0` | 各接続に使用するデータベースの名前。 | +| `redis.loadBalancing.dialtimeout` | `0s` | Redisインスタンスへの接続のタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.loadBalancing.readtimeout` | `0s` | Redisインスタンスからの読み取りのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.loadBalancing.writetimeout` | `0s` | Redisインスタンスへの書き込みのタイムアウト。デフォルトでは、タイムアウトはありません。 | +| `redis.loadBalancing.tls.enabled` | `false` | TLSを有効にするには、`true`に設定します。 | +| `redis.loadBalancing.tls.insecure` | `false` | TLS経由で接続する際にサーバー名の検証を無効にするには、`true`に設定します。 | +| `redis.loadBalancing.pool.size` | `10` | ソケット接続の最大数。 | +| `redis.loadBalancing.pool.maxlifetime` | `1h` | クライアントが接続を再試行するまでの接続時間。デフォルトでは、古くなった接続は閉じません。 | +| `redis.loadBalancing.pool.idletimeout` | `300s` | 無効な接続を閉じるまでに待機する時間。 | + +## チャート設定の例 {#chart-configuration-examples} + +### `pullSecrets` {#pullsecrets} + +`pullSecrets`を使用すると、プライベートレジストリに認証して、ポッドのコンテナイメージをプルできます。 + +プライベートレジストリとその認証方式に関する追加の詳細は、[Kubernetesのドキュメント](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod)にあります。 + +以下は、`pullSecrets`の使用例です。 + +```yaml +image: + repository: my.registry.repository + tag: latest + pullPolicy: Always + pullSecrets: + - name: my-secret-name + - name: my-secondary-secret-name +``` + +### `serviceAccount` {#serviceaccount} + +このセクションでは、ServiceAccountを作成するかどうか、およびデフォルトのアクセストークンをポッドにマウントするかどうかを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-------------------------------|:-------:|:--------|:------------| +| `automountServiceAccountToken` | ブール値 | `false` | デフォルトのServiceAccountアクセストークンをポッドにマウントするかどうかを制御します。特定のサイドカーが適切に動作するために必要な場合を除き、これを有効にしないでください（Istioなど）。 | +| `enabled` | ブール値 | `false` | ServiceAccountを使用するかどうかを示します。 | + +### `tolerations` {#tolerations} + +`tolerations`を使用すると、taintedワーカーノードでポッドをスケジュールできます + +以下は、`tolerations`の使用例です。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +### `affinity` {#affinity} + +`affinity`はオプションのパラメータで、以下の一方または両方を設定できます。 + +- 次の`podAntiAffinity`ルール： + - `topology key`に対応する式に一致するポッドと同じドメインにポッドをスケジュールしません。 + - 必要な (`requiredDuringSchedulingIgnoredDuringExecution`) モードと優先 (`preferredDuringSchedulingIgnoredDuringExecution`) モードの2つのモードを`podAntiAffinity`ルールに設定します。`values.yaml`の`antiAffinity`変数を使用して、優先モードが適用されるように設定を`soft`に設定するか、必須モードが適用されるように`hard`に設定します。 +- 次の`nodeAffinity`ルール： + - 特定のゾーンに属するノードにポッドをスケジュールします。 + - 必要な (`requiredDuringSchedulingIgnoredDuringExecution`) モードと優先 (`preferredDuringSchedulingIgnoredDuringExecution`) モードの2つのモードを`nodeAffinity`ルールに設定します。`soft`に設定すると、優先モードが適用されます。`hard`に設定すると、必要なモードが適用されます。このルールは、`registry`チャートと、`webservice`と`sidekiq`を除くすべてのサブチャートとともに`gitlab`チャートにのみ実装されます。 + +`nodeAffinity`は、[`In`演算子](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators)のみを実装します。 + +詳細については、[関連するKubernetesドキュメント](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)を参照してください。 + +次の例では、`nodeAffinity`と`antiAffinity`の両方が`hard`に設定された状態で、`affinity`を設定します。 + +```yaml +nodeAffinity: "hard" +antiAffinity: "hard" +affinity: + nodeAffinity: + key: "test.com/zone" + values: + - us-east1-a + - us-east1-b + podAntiAffinity: + topologyKey: "test.com/hostname" +``` + +### `annotations` {#annotations} + +`annotations`を使用すると、レジストリ ポッドにアノテーションを追加できます。 + +以下は、`annotations`の使用例です + +```yaml +annotations: + kubernetes.io/example-annotation: annotation-value +``` + +## サブチャートを有効にする {#enable-the-sub-chart} + +コンパートメント化されたサブチャートを実装するために選択した方法には、特定のデプロイで不要なコンポーネントを無効にする機能が含まれています。このため、最初に決定する必要がある設定は`enabled`です。 + +デフォルト無効にする場合は、`enabled: false`を設定します。 + +## `image`の設定 {#configuring-the-image} + +このセクションでは、このサブチャートの[deployment](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/templates/deployment.yaml)で使用されるコンテナイメージの設定について詳しく説明します。レジストリと`pullPolicy`に含まれるバージョンを変更できます。 + +デフォルト 設定： + +- `tag: 'v4.15.2-gitlab'` +- `pullPolicy: 'IfNotPresent'` + +## `service`の設定 {#configuring-the-service} + +このセクションでは、[Service](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/templates/service.yaml)の名前と種類を制御します。これらの設定は、[`values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/charts/registry/values.yaml)によって入力された状態になります。 + +デフォルト + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------------|:------:|:------------|:------------| +| `name` | 文字列 | `registry` | サービスの名前を設定します | +| `type` | 文字列 | `ClusterIP` | サービスの種類を設定します | +| `externalPort` | 整数 | `5000` | Serviceによって公開されるポート | +| `internalPort` | 整数 | `5000` | サービスからのリクエストを受け入れるためにポッドによって利用されるポート | +| `clusterIP` | 文字列 | `null` | 必要に応じてカスタムクラスターIPを設定できるようにします | +| `loadBalancerIP` | 文字列 | `null` | 必要に応じてカスタムLoadBalancer IPアドレスを設定できるようにします | + +## `ingress`の設定 {#configuring-the-ingress} + +このセクションでは、レジストリIngressを制御します。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------------------|:-------:|:--------|:------------| +| `apiVersion` | 文字列 | | `apiVersion`フィールドで使用する値。 | +| `annotations` | 文字列 | | このフィールドは、[Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)の標準`annotations`と完全に一致します。 | +| `configureCertmanager` | ブール値 | | Ingressアノテーション`cert-manager.io/issuer`および`acme.cert-manager.io/http01-edit-in-place`を切り替えます。詳細については、[GitLab PagesのTLS要件](../../installation/tls.md)を参照してください。 | +| `enabled` | ブール値 | `false` | サービスをサポートするIngressオブジェクトを作成するかどうかを制御する設定。`false`の場合、`global.ingress.enabled`設定が使用されます。 | +| `tls.enabled` | ブール値 | `true` | `false`に設定すると、レジストリサブチャートのTLSが無効になります。これは主に、`ingress-level`でTLS終端を使用できない場合に役立ちます（Ingressコントローラーの前にTLS終端プロキシがある場合など）。 | +| `tls.secretName` | 文字列 | | レジストリURLの有効な証明書とキーを含むKubernetes TLSシークレットの名前。設定しない場合、代わりに`global.ingress.tls.secretName`が使用されます。デフォルト | +| `tls.cipherSuites` | 配列 | `[]` | TLSハンドシェイク中にコンテナ レジストリがクライアントに提示する必要がある暗号スイートのリスト。 | + +## TLSの設定 {#configuring-tls} + +コンテナ レジストリは、`nginx-ingress`を含む他のコンポーネントとの通信を保護するTLSをサポートします。 + +TLSを設定するための前提要件： + +- TLS証明書には、共通名（CN）またはサブジェクト代替名（SAN）のレジストリサービスホスト名（たとえば、`RELEASE-registry.default.svc`）を含める必要があります。 +- TLS証明書が生成された後： + - [Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)を作成します + - `ca.crt`キーを使用して、TLS証明書のCA証明書のみを含む別のシークレットを作成します。 + +TLSを有効にする手順： + +1. `registry.tls.enabled`を`true`に設定します。 +1. `global.hosts.registry.protocol`を`https`に設定します。 +1. `registry.tls.secretName`と`global.certificates.customCAs`にシークレット名を適宜渡します。 + +`registry.tls.verify`が`true`の場合、CA証明書シークレット名を`registry.tls.caSecretName`に渡す必要があります。これは、自己署名証明書とカスタム公開認証局（CA）に必要です。このシークレットは、レジストリのTLS証明書を検証するために、NGINXによって使用されます。 + +次に例を示します。 + +```yaml +global: + certificates: + customCAs: + - secret: registry-tls-ca + hosts: + registry: + protocol: https + +registry: + tls: + enabled: true + secretName: registry-tls + verify: true + caSecretName: registry-tls-ca +``` + +### コンテナ レジストリ暗号スイート {#container-registry-cipher-suites} + +通常、`tls.cipherSuites`オプションは、レジストリがスタンドアロンモードでデプロイされている、または最新の暗号スイートをサポートしていないデフォルト標準のGitLabデプロイでは、NGINX Ingressは、コンテナ レジストリ バックエンドでサポートされている最高のTLSバージョン（現在はTLS1.3）を選択します。TLS1.3では暗号を設定できず、デフォルトで安全です。何らかの理由でTLS1.3が利用できない場合、コンテナ レジストリが使用しているデフォルトのTLS1.2暗号リストも、NGINX Ingressのデフォルトの設定と互換性があり、安全です。 + +### デバッグポートのTLSの設定 {#configuring-tls-for-the-debug-port} + +レジストリデバッグポートもTLSをサポートします。デバッグポートは、Kubernetesの活性と準備状況のチェックに使用されるだけでなく、Prometheusの`/metrics`エンドポイントも公開します（有効な場合）。 + +TLSを有効にするには、`registry.debug.tls.enabled`を`true`に設定します。[Kubernetes TLSシークレット](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets)は、デバッグポートのTLS設定での使用専用として`registry.debug.tls.secretName`で指定できます。専用のシークレットが指定されていない場合、デバッグ設定は、レジストリの通常のTLS設定で`registry.tls.secretName`を共有するようにフォールバックします。 + +Prometheusが`https`を使用して`/metrics/`エンドポイントをスクレイピングするには、証明書のCommonName属性またはSubjectAlternativeNameエントリに追加の設定が必要です。これらの要件については、[TLS対応のエンドポイントをスクレイピングするようにPrometheusを設定する](../../installation/tools.md#configure-prometheus-to-scrape-tls-enabled-endpoints)を参照してください。 + +## `networkpolicy`の設定 {#configuring-the-networkpolicy} + +このセクションでは、レジストリ[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)を制御します。この設定はオプションであり、特定のエンドポイントへのレジストリのエグレスとIngressを制限するために使用されます。エンドポイントへのIngress。 + +| 名前 | 種類 | デフォルト | 説明 | +|:------------------|:-------:|:--------|:------------| +| `enabled` | ブール値 | `false` | この`NetworkPolicy`の設定を有効にします。 | +| `ingress.enabled` | ブール値 | `false` | `true`に設定すると、`Ingress`ネットワークポリシーが有効になります。これにより、ルールが指定されていない限り、すべてのIngress接続がブロックされます。 | +| `ingress.rules` | 配列 | `[]` | Ingressポリシーのルール。詳細については、と以下の例を参照してください | +| `egress.enabled` | ブール値 | `false` | `true`に設定すると、`Egress`ネットワークポリシーが有効になります。これにより、ルールが指定されていない限り、すべてのエグレス接続がブロックされます。 | +| `egress.rules` | 配列 | `[]` | エグレスポリシーのルール。詳細については、と以下の例を参照してください | + +### すべての内部エンドポイントへの接続を阻止するためのポリシー例 {#example-policy-for-preventing-connections-to-all-internal-endpoints} + +通常、レジストリサービスは、オブジェクトストレージへのエグレス接続、DockerクライアントからのIngress接続、およびDNSルックアップ用のkube-dnsを必要とします。これにより、レジストリサービスに次のネットワーク制限が追加されます。 + +- Ingressリクエストを許可します。 + - ポッド`sidekiq`、`webservice`、`nginx-ingress`からポート`5000`へ + - `Prometheus`ポッドからポート`9235`へ +- エグレスリクエストを許可します。 + - `kube-dns`からポート`53`へ + - S3またはSTS `172.16.1.0/24`のAWS VPCエンドポイントなどのエンドポイントからポート`443`へ + - インターネット`0.0.0.0/0`からポート`443`へ + +_注：[レジストリ](../../advanced/external-object-storage)サービスには、（エンドポイントが使用されていない場合）外部オブジェクトストレージ上のイメージへの送信接続が必要です_ + +この例は、`kube-dns`がネームスペース`kube-system`にデプロイされ、`prometheus`がネームスペース`monitoring`にデプロイされ、`nginx-ingress`がネームスペース`nginx-ingress`にデプロイされたという前提に基づいています。 + +```yaml +networkpolicy: + enabled: true + ingress: + enabled: true + rules: + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: nginx-ingress + podSelector: + matchLabels: + app: nginx-ingress + component: controller + ports: + - port: 5000 + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: monitoring + podSelector: + matchLabels: + app: prometheus + component: server + release: gitlab + ports: + - port: 9235 + - from: + - podSelector: + matchLabels: + app: sidekiq + ports: + - port: 5000 + - from: + - podSelector: + matchLabels: + app: webservice + ports: + - port: 5000 + egress: + enabled: true + rules: + - to: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: kube-system + podSelector: + matchLabels: + k8s-app: kube-dns + ports: + - port: 53 + protocol: UDP + - to: + - ipBlock: + cidr: 172.16.1.0/24 + ports: + - port: 443 + - to: + - ipBlock: + cidr: 0.0.0.0/0 + except: + - 10.0.0.0/8 +``` + +## KEDA {#configuring-keda}の設定 + +この`keda`セクションでは、[KEDA](https://keda.sh/)`ScaledObjects`のインストールを、`HorizontalPodAutoscalers`の代わりに有効にします。この設定はオプションであり、カスタムメトリクスまたは外部メトリクスに基づいたオートスケールが必要な場合に使用できます。 + +ほとんどの設定は、該当する場合、`hpa`セクションで設定された値にデフォルト設定されます。 + +次がtrueの場合、CPUとメモリのトリガーは、`hpa`セクションで設定されたCPUとメモリのしきい値に基づいて自動的に追加されます。 + +- `triggers`が設定されていません。 +- 対応する`request.cpu.request`または`request.memory.request`の設定も、ゼロ以外の値に設定されています。 + +トリガーが設定されていない場合、`ScaledObject`は作成されません。 + +これらの[設定](https://keda.sh/docs/2.10/concepts/scaling-deployments/)の詳細については、KEDAドキュメントを参照してください。 + +| 名前 | 種類 | デフォルト | 説明 | +|:--------------------------------|:-------:|:--------------------------------|:------------| +| `enabled` | ブール値 | `false` | [KEDA](https://keda.sh/) `ScaledObjects`を`HorizontalPodAutoscalers`の代わりに使用します | +| `pollingInterval` | 整数 | `30` | 各トリガーをチェックする間隔 | +| `cooldownPeriod` | 整数 | `300` | 最後トリガーがアクティブであるとレポートされてから、リソースを0にスケールバックするまでの待機時間 | +| `minReplicaCount` | 整数 | `hpa.minReplicas` | KEDAがリソースをスケールダウンする最小レプリカ数。 | +| `maxReplicaCount` | 整数 | `hpa.maxReplicas` | KEDAがリソースをスケールアップする最大レプリカ数。 | +| `fallback` | マップ | | [KEDA](https://keda.sh/docs/2.10/concepts/scaling-deployments/#fallback)フォールバック 設定、ドキュメントを参照してください | +| `hpaName` | 文字列 | `keda-hpa-{scaled-object-name}` | KEDAが作成するHPAリソースの名前。 | +| `restoreToOriginalReplicaCount` | ブール値 | | `ScaledObject`の削除後、ターゲットリソースを元のレプリカ数にスケールバックするかどうかを指定します | +| `behavior` | マップ | `hpa.behavior` | アップスケールとダウンスケールの動作の仕様。 | +| `triggers` | 配列 | | ターゲットリソースのスケーリングをアクティブ化するトリガーのリスト。`hpa.cpu`および`hpa.memory`から計算されるトリガーにデフォルト設定されます | + +### すべての内部エンドポイントへの接続を阻止するためのポリシー例 {#example-policy-for-preventing-connections-to-all-internal-endpoints-1} + +通常、レジストリサービスは、オブジェクトストレージへのエグレス接続、DockerクライアントからのIngress接続、およびDNSルックアップ用のkube-dnsを必要とします。これにより、レジストリサービスに次のネットワーク構築制限が追加されます。 + +- `10.0.0.0/8`ポート53上のローカルネットワークへのすべてのエグレス リクエストが許可されます（kubeDNSの場合） +- `10.0.0.0/8`上のローカルネットワークへの他のエグレス リクエストは制限されています +- `10.0.0.0/8`の外部 エグレス リクエストは許可されています + +_注：[レジストリ](../../advanced/external-object-storage)サービスには、外部オブジェクトストレージ上のイメージに対するパブリックインターネットへの送信接続が必要です_ + +```yaml +networkpolicy: + enabled: true + egress: + enabled: true + # The following rules enable traffic to all external + # endpoints, except the local + # network (except DNS requests) + rules: + - to: + - ipBlock: + cidr: 10.0.0.0/8 + ports: + - port: 53 + protocol: UDP + - to: + - ipBlock: + cidr: 0.0.0.0/0 + except: + - 10.0.0.0/8 +``` + +## レジストリ 設定の定義 {#defining-the-registry-configuration} + +この[チャート](https://hub.docker.com/_/registry/)の次のプロパティは、基盤となるレジストリ コンテナの設定に関係します。GitLabとのインテグレーションのために最も重要な値のみが公開されます。このインテグレーションでは、JWT [認証](https://github.com/docker/distribution) [トークン](https://distribution.github.io/distribution/spec/auth/token/)を介してレジストリへの認証を制御するDockerディストリビューションの`auth.token.x`設定を使用します。 + +### `httpSecret` {#httpsecret} + +フィールド`httpSecret`は、`secret`と`key`の2つのアイテムを含むマップです。 + +このキーが参照するコンテンツは、[レジストリ](https://hub.docker.com/_/registry/)の`http.secret`値に関連付けられています。この値には、暗号で生成されたランダムな文字列が入力されている必要があります。 + +`shared-secrets`ジョブは、指定されていない場合、このシークレットを自動的に作成します。これは、base64エンコードされた、安全に生成された128文字の英数字文字列で入力されます。 + +このシークレットを手動で作成するには： + +```shell +kubectl create secret generic gitlab-registry-httpsecret --from-literal=secret=strongrandomstring +``` + +### 通知 {#notification-secret}シークレット + +通知 シークレットは、さまざまな方法でGitLabアプリケーションにコールバックするために使用されます。たとえば、Geoがプライマリサイトとセカンダリサイト間でコンテナレジストリデータを同期するのを支援するなどです。 + +`notificationSecret`シークレット オブジェクトは、`shared-secrets`機能が有効になっている場合、指定されていない場合に自動的に作成されます。 + +このシークレットを手動で作成するには： + +```shell +kubectl create secret generic gitlab-registry-notification --from-literal=secret=[\"strongrandomstring\"] +``` + +次に、設定に進みます + +```yaml +global: + # To provide your own secret + registry: + notificationSecret: + secret: gitlab-registry-notification + key: secret + + # If utilising Geo, and wishing to sync the container registry. + # Define this in the primary site configs only. + geo: + registry: + replication: + enabled: true + primaryApiUrl: +``` + +`secret`値が上記で作成されたシークレットの名前に設定されていることを確認します + +### Redisキャッシュ シークレット {#redis-cache-secret} + +Redisキャッシュ シークレットは、`global.redis.auth.enabled`が`true`に設定されている場合に使用されます。 + +`shared-secrets`機能が有効になっている場合、`gitlab-redis-secret`シークレット オブジェクトは、指定されていない場合に自動的に作成されます。 + +この[シークレット](../../installation/secrets.md#redis-password)を手動で作成するには、Redisパスワードの手順を参照してください。 + +### `authEndpoint` {#authendpoint} + +`authEndpoint`フィールドは文字列で、[レジストリ](https://hub.docker.com/_/registry/)が認証するGitLabインスタンスへのURLを提供します。 + +この値には、プロトコルとホスト名のみを含める必要があります。チャートテンプレートは、必要なリクエスト パスを自動的に追加します。結果として得られる`auth.token.realm`の値は、コンテナ内で入力されます。次に例を示します。`authEndpoint: "https://gitlab.example.com"` + +デフォルトでは、このフィールドには、[グローバル設定](../globals.md)で設定されたGitLabホスト名の設定が入力されます。 + +### `certificate` {#certificate} + +`certificate`フィールドは、`secret`と`key`の2つの項目を含むマップです。 + +`secret`は、GitLabインスタンスによって作成されたトークンを検証するために使用される証明書[バンドル](https://kubernetes.io/docs/concepts/configuration/secret/)を格納する[Kubernetes Secret](https://kubernetes.io/docs/concepts/configuration/secret/)の名前を含む文字列です。 + +`key`は、[レジストリ](https://hub.docker.com/_/registry/)コンテナに`auth.token.rootcertbundle`として提供される証明書バンドルを格納する`Secret`内の`key`の名前です。 + +デフォルトの例: + +```yaml +certificate: + secret: gitlab-registry + key: registry-auth.crt +``` + +### readinessプローブとlivenessプローブ {#readiness-and-liveness-probe} + +デフォルトでは、デバッグポートである`5001`ポートで`/debug/health`をチェックするように設定されたreadinessプローブとlivenessプローブがあります。 + +### `validation` {#validation} + +`validation`フィールドは、レジストリ内のDockerイメージ検証プロセスを制御するマップです。イメージ検証が有効になっている場合、`manifests.urls.allow`フィールドがそれらのレイヤーのURLを許可するように明示的に設定されていない限り、レジストリは外部レイヤーを持つWindowsイメージを拒否します。 + +検証はmanifestのプッシュ中にのみ行われるため、レジストリに既に存在するイメージは、このセクションの値の変更の影響を受けません。 + +イメージ検証はデフォルトでオフになっています。 + +イメージ検証を有効にするには、`registry.validation.disabled: false`を明示的に設定する必要があります。 + +#### `manifests` {#manifests} + +`manifests`フィールドを使用すると、manifestに固有の検証ポリシーを設定できます。 + +`urls`セクションには、`allow`フィールドと`deny`フィールドの両方が含まれています。検証をpassするURLを含むmanifestのレイヤーの場合、そのレイヤーは`allow`フィールド内の正規表現のいずれかと一致する必要があり、`deny`フィールド内の正規表現と一致してはなりません。 + +| 名前 | 種類 | デフォルト | 説明 | +|:------------------:|:-----:|:--------|:-----------:| +| `referencelimit` | Int | `0` | 単一のmanifestが持つことができるレイヤー、イメージ設定、その他のmanifestなどのreferenceの最大数。`0`（デフォルト）に設定すると、この検証は無効になります。 | +| `payloadsizelimit` | Int | `0` | manifestのペイロードの最大データサイズ（バイト単位）。`0`（デフォルト）に設定すると、この検証は無効になります。 | +| `urls.allow` | 配列 | `[]` | manifestのレイヤー内のURLを有効にする正規表現のリスト。空のまま（デフォルト）にすると、URLを含むレイヤーは拒否されます。 | +| `urls.deny` | 配列 | `[]` | manifestのレイヤー内のURLを制限する正規表現のリスト。空のまま（デフォルト）にすると、`urls.allow`リストをpassしたURLを持つレイヤーは拒否されません | + +### `notifications` {#notifications} + +`notifications`フィールドは、[レジストリ](https://distribution.github.io/distribution/about/notifications/#configuration)の通知を設定するために使用されます。デフォルト値として空のハッシュがあります。 + +| 名前 | 種類 | デフォルト | 説明 | +|:-----------:|:-----:|:--------|:-----------:| +| `endpoints` | 配列 | `[]` | 各項目が[エンドポイント](https://distribution.github.io/distribution/about/configuration/#endpoints)に対応する項目のリスト | +| `events` | ハッシュ | `{}` | [イベント](https://distribution.github.io/distribution/about/configuration/#events)の通知で提供される情報 | + +設定例を次に示します。 + +```yaml +notifications: + endpoints: + - name: FooListener + url: https://foolistener.com/event + timeout: 500ms + # DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243. + # When using `maxretries`, `threshold` is ignored: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints + threshold: 10 + maxretries: 10 + backoff: 1s + - name: BarListener + url: https://barlistener.com/event + timeout: 100ms + # DEPRECATED: use `maxretries` instead https://gitlab.com/gitlab-org/container-registry/-/issues/1243. + # When using `maxretries`, `threshold` is ignored: https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads#endpoints + threshold: 3 + maxretries: 5 + backoff: 1s + events: + includereferences: true +``` + + + +### `hpa` {#hpa} + + + +`hpa`フィールドは、セットの一部として作成する[レジストリ](https://hub.docker.com/_/registry/)インスタンスの数を制御するオブジェクトです。これは、`minReplicas`の値`2`、`maxReplicas`の値10、および`cpu.targetAverageUtilization`を75％に設定します。 + +### `storage` {#storage} + +```yaml +storage: + secret: + key: config + extraKey: +``` + +`storage`フィールドは、Kubernetesシークレットと関連付けられたキーへの参照です。このシークレットの内容は、[レジストリ](https://distribution.github.io/distribution/about/configuration/#storage)の設定から直接取得されます: `storage`詳細については、そのドキュメントを参照してください。 + +[AWS S3](https://distribution.github.io/distribution/storage-drivers/s3/)および[Google GCS](https://distribution.github.io/distribution/storage-drivers/gcs/)ドライバーの例は、[`examples/objectstorage`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage)にあります: + +- [`registry.s3.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.s3.yaml) +- [`registry.gcs.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/objectstorage/registry.gcs.yaml) + +[S3](https://distribution.github.io/distribution/storage-drivers/s3/#s3-permission-scopes)の場合、レジストリストレージに適切な[権限](https://distribution.github.io/distribution/storage-drivers/s3/#s3-permission-scopes)があることを確認してください。ストレージの設定の詳細については、[コンテナレジストリストレージドライバー](https://docs.gitlab.com/administration/packages/container_registry/#container-registry-storage-driver)を管理ドキュメントで参照してください。 + +`storage`ブロックの_コンテンツ_を_シークレット_に配置し、次の項目を`storage`マップへの項目として提供します: + +- `secret`: YAMLブロックをホスティングするKubernetesシークレットの名前。 +- `key`: 使用するシークレット内のキーの名前。デフォルトは`config`です。 +- `extraKey`: _（オプション）_シークレット内の追加の_キー_の名前。これは、コンテナ内の`/etc/docker/registry/storage/${extraKey}`に_マウント_されます。これは、`gcs`ドライバーの`keyfile`を提供するために使用できます。 + +```shell +# Example using S3 +kubectl create secret generic registry-storage \ + --from-file=config=registry-storage.yaml + +# Example using GCS with JSON key +# - Note: `registry.storage.extraKey=gcs.json` +kubectl create secret generic registry-storage \ + --from-file=config=registry-storage.yaml \ + --from-file=gcs.json=example-project-382839-gcs-bucket.json +``` + +[ストレージドライバーのリダイレクトを無効にする](https://docs.gitlab.com/administration/packages/container_registry/#disable-redirect-for-storage-driver)ことで、すべてのトラフィックが別のバックエンドにリダイレクトされる代わりに、レジストリサービスを通過するようにすることができます: + +```yaml +storage: + secret: example-secret + key: config + redirect: + disable: true +``` + +`filesystem`ドライバーを使用することを選択した場合: + +- このデータの永続ボリュームを提供する必要があります。 +- [`hpa.minReplicas`](#hpa)を`1`に設定する必要があります +- [`hpa.maxReplicas`](#hpa)を`1`に設定する必要があります + +回復と簡素化のために、`s3`、`gcs`、`azure`などの外部サービス、またはその他の互換性のあるオブジェクトストレージを使用することをお勧めします。 + +{{< alert type="note" >}} + +ユーザーが指定しない場合、チャートはデフォルトでこの設定に`delete.enabled: true`を入力します。これにより、MinIOのデフォルトの使用だけでなく、Linuxパッケージとの整合性が維持されます。ユーザーが指定した値は、このデフォルトよりも優先されます。 + +{{< /alert >}} + +### `middleware.storage` {#middlewarestorage} + +`middleware.storage`の[設定](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware)は、アップストリームの規則に従います: + +設定は非常にgenericであり、同様のパターンに従います: + +```yaml +middleware: + # See https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#middleware + storage: + - name: cloudfront + options: + baseurl: https://abcdefghijklmn.cloudfront.net/ + # `privatekey` is auto-populated with the content from the privatekey Secret. + privatekeySecret: + secret: cloudfront-secret-name + # "key" value is going to be used to generate filename for PEM storage: + # /etc/docker/registry/middleware.storage// + key: private-key-ABC.pem + keypairid: ABCEDFGHIJKLMNOPQRST +``` + +上記のコード内`options.privatekeySecret`は、PEMファイルのコンテンツに対応する`generic` Kubernetesシークレットのコンテンツです。 + +```shell +kubectl create secret generic cloudfront-secret-name --type=kubernetes.io/ssh-auth --from-file=private-key-ABC.pem=pk-ABCEDFGHIJKLMNOPQRST.pem +``` + +アップストリームで使用される`privatekey`は、チャートによって`privatekey`シークレットから自動的に入力され、指定されている場合は**無視**されます。 + +#### `keypairid`バリアント {#keypairid-variants} + +さまざまなベンダーが、同じ構成に異なるフィールド名を使用します: + +| ベンダー | フィールド名 | +|:----------:|:----------:| +| Google CDN | `keyname` | +| CloudFront | `keypairid` | + +{{< alert type="note" >}} + +現時点では、`middleware.storage`セクションの設定のみがサポートされています。 + +{{< /alert >}} + +### `debug` {#debug} + +デバッグポートはデフォルトで有効になっており、liveness/readinessプローブに使用されます。さらに、Prometheusメトリクスは、`metrics`値を介して有効にできます。 + +```yaml +debug: + addr: + port: 5001 + +metrics: + enabled: true +``` + +### `health` {#health} + +`health`プロパティはオプションであり、ストレージドライバーのバックエンドストレージで定期的なヘルスチェックの環境設定を含みます。詳細については、Docker [設定](https://distribution.github.io/distribution/about/configuration/#health)ドキュメントを参照してください。 + +```yaml +health: + storagedriver: + enabled: false + interval: 10s + threshold: 3 +``` + +### `reporting` {#reporting} + +`reporting`プロパティはオプションで、[レポート作成](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#reporting)を有効にします + +```yaml +reporting: + sentry: + enabled: true + dsn: 'https://@sentry.io/' + environment: 'production' +``` + +### `profiling` {#profiling} + +`profiling`プロパティはオプションで、[継続的プロファイリング](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#profiling)を有効にします + +```yaml +profiling: + stackdriver: + enabled: true + credentials: + secret: gitlab-registry-profiling-creds + key: credentials + service: gitlab-registry +``` + +### `database` {#database} + +{{< history >}} + +- [GitLab](https://gitlab.com/groups/gitlab-org/-/epics/5521) 16.4で[ベータ](https://docs.gitlab.com/policy/development_stages_support/#beta)機能として[導入](https://gitlab.com/groups/gitlab-org/-/epics/5521)されました。 +- [一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/423459)はGitLab 17.3で行われました。 + +{{< /history >}} + +`database`プロパティはオプションで、[metadataデータベース](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#database)を有効にします。 + +この[機能](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/)を有効にする前に、管理ドキュメントを参照してください。 + +{{< alert type="note" >}} + +この機能を使用するには、PostgreSQL 13以降が必要です。 + +{{< /alert >}} + +```yaml +database: + enabled: true + host: registry.db.example.com + port: 5432 + user: registry + password: + secret: gitlab-postgresql-password + key: postgresql-registry-password + dbname: registry + sslmode: verify-full + ssl: + secret: gitlab-registry-postgresql-ssl + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + connecttimeout: 5s + draintimeout: 2m + preparedstatements: false + primary: 'primary.record.fqdn' + pool: + maxidle: 25 + maxopen: 25 + maxlifetime: 5m + maxidletime: 5m + migrations: + enabled: true + activeDeadlineSeconds: 3600 + backoffLimit: 6 + backgroundMigrations: + enabled: true + maxJobRetries: 3 + jobInterval: 10s +``` + +#### ロードバランシング {#load-balancing} + +{{< alert type="warning" >}} + +これは活発な開発中の実験的な機能であり、本番環境で使用してはなりません。 + +{{< /alert >}} + +`loadBalancing`セクションでは、[データベース](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#loadbalancing)のロードバランシングを設定できます。この機能を動作させるには、対応する[Redis](#redis-for-database-load-balancing)接続を有効にする必要があります。 + +#### データベースの管理 {#manage-the-database} + +[データベース](metadata_database.md)の作成と保持の詳細については、コンテナレジストリmetadataデータベースのページを参照してください。 + +### `gc`プロパティ {#gc-property} + +`gc`プロパティは、[オンラインガベージコレクション](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#gc)オプションを提供します。 + +[オンラインガベージコレクション](#database)には、metadataデータベースが有効になっている必要があります。データベースを使用する場合はオンラインガベージコレクションを使用する必要がありますが、メンテナンスとデバッグのために一時的にオンラインガベージコレクションを無効にすることができます。 + +```yaml +gc: + disabled: false + maxbackoff: 24h + noidlebackoff: false + transactiontimeout: 10s + reviewafter: 24h + manifests: + disabled: false + interval: 5s + blobs: + disabled: false + interval: 5s + storagetimeout: 5s +``` + +### Redisキャッシュ {#redis-cache} + +{{< alert type="note" >}} + +Redisキャッシュは、バージョン16.4以降のベータ版の機能です。この[機能](https://gitlab.com/gitlab-org/gitlab/-/issues/423459)を有効にする前に、フィードバックのイシューと関連ドキュメントを確認してください。 + +{{< /alert >}} + +`redis.cache`プロパティはオプションで、[Redisキャッシュ](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#cache-1)に関連するオプションを提供します。`redis.cache`をレジストリで使用するには、[metadataデータベース](#database)を有効にする必要があります。 + +次に例を示します。 + +```yaml +redis: + cache: + enabled: true + host: localhost + port: 16379 + password: + secret: gitlab-redis-secret + key: redis-password + db: 0 + dialtimeout: 10ms + readtimeout: 10ms + writetimeout: 10ms + tls: + enabled: true + insecure: true + pool: + size: 10 + maxlifetime: 1h + idletimeout: 300s +``` + +#### クラスタ {#cluster} + +`redis.rateLimiting.cluster`プロパティは、Redisクラスタへの接続に使用するホストとポートのリストです。次に例を示します。 + +```yaml +redis: + cache: + enabled: true + host: redis.example.com + cluster: + - host: host1.example.com + port: 6379 + - host: host2.example.com + port: 6379 +``` + +#### Sentinels {#sentinels} + +`redis.cache`は`global.redis.sentinels`構成を使用できます。ローカル値を提供でき、グローバル値よりも優先されます。次に例を示します。 + +```yaml +redis: + cache: + enabled: true + host: redis.example.com + sentinels: + - host: sentinel1.example.com + port: 16379 + - host: sentinel2.example.com + port: 16379 +``` + +#### Sentinelパスワードのサポート {#sentinel-password-support} + +{{< history >}} + +- GitLab 17.2で[導入](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/3805)されました。 + +{{< /history >}} + +`redis.cache`は、Redis Sentinelの認証パスワードを使用するために、[`global.redis.sentinelAuth`構成](../globals.md#redis-sentinel-password-support)も使用できます。ローカル値を提供でき、グローバル値よりも優先されます。次に例を示します。 + +```yaml +redis: + cache: + enabled: true + host: redis.example.com + sentinels: + - host: sentinel1.example.com + port: 16379 + - host: sentinel2.example.com + port: 16379 + sentinelpassword: + enabled: true + secret: registry-redis-sentinel + key: password +``` + +### Redisレート制限機構 {#redis-rate-limiter} + +{{< alert type="warning" >}} + +Redisレート制限機構は[開発中](https://gitlab.com/groups/gitlab-org/-/epics/13237)です。より詳細な機能については、使用可能になり次第、このセクションに追加します。 + +{{< /alert >}} + +`redis.rateLimiting`プロパティはオプションで、[Redisレート制限機構](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#ratelimiter)に関連するオプションを提供します。 + +次に例を示します。 + +```yaml +redis: + rateLimiting: + enabled: true + host: localhost + port: 16379 + username: registry + password: + secret: gitlab-redis-secret + key: redis-password + db: 0 + dialtimeout: 10ms + readtimeout: 10ms + writetimeout: 10ms + tls: + enabled: true + insecure: true + pool: + size: 10 + maxlifetime: 1h + idletimeout: 300s +``` + +### データベースロードバランシング用のRedis {#redis-for-database-load-balancing} + +{{< details >}} + +状態:実験 + +{{< /details >}} + +{{< history >}} + +- [チャート](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/4180) 8.11で[導入](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/4180)されました。 + +{{< /history >}} + +{{< alert type="warning" >}} + +[データベース](#load-balancing)の負荷分散は現在開発中の試験的な機能であり、本番環境で使用しないでください。進捗状況を追跡し、[フィードバック](https://gitlab.com/groups/gitlab-org/-/epics/8591)を共有するには、エピック8591を使用してください。 + +{{< /alert >}} + +`redis.loadBalancing`プロパティはオプションで、[データベース](https://gitlab.com/gitlab-org/container-registry/-/blob/b4d71f24a9ae31288401a3459228aa7f8d3dd8f0/docs/configuration.md#loadbalancing-1)の負荷分散のためのRedis接続に関連するオプションを提供します。 + +次に例を示します。 + +```yaml +redis: + loadBalancing: + enabled: true + host: localhost + port: 16379 + username: registry + password: + secret: gitlab-redis-secret + key: redis-password + db: 0 + dialtimeout: 10ms + readtimeout: 10ms + writetimeout: 10ms + tls: + enabled: true + insecure: true + pool: + size: 10 + maxlifetime: 1h + idletimeout: 300s +``` + +## ガベージコレクション {#garbage-collection} + +Dockerレジストリは、時間が経つにつれて不要なデータを蓄積します。これは[ガベージコレクション](https://distribution.github.io/distribution/about/garbage-collection/)を使用して解放できます。現在のところ、この[チャート](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1586)でガベージコレクションを実行するための完全に自動化された、またはスケジュールされた方法はありません。 + +{{< alert type="warning" >}} + +[metadataデータベース](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#gc)で[オンラインガベージコレクション](#database)を使用する必要があります。metadataデータベースで手動ガベージコレクションを使用すると、データが失われます。オンラインガベージコレクションは、手動でガベージコレクションを実行する必要性を完全に置き換えます。 + +{{< /alert >}} + +### 手動ガベージコレクション {#manual-garbage-collection} + +手動ガベージコレクションでは、最初にレジストリを読み取り専用モードにする必要があります。Helmを使用してGitLabチャートを既にインストールし、`mygitlab`という名前を付け、`gitlabns`ネームスペースにインストールしたと仮定しましょう。実際の設定に従って、以下のコマンドでこれらの値を置き換えてください。 + +```shell +# Because of https://github.com/helm/helm/issues/2948 we can't rely on --reuse-values, so let's get our current config. +helm get values mygitlab > mygitlab.yml +# Upgrade Helm installation and configure the registry to be read-only. +# The --wait parameter makes Helm wait until all ressources are in ready state, so we are safe to continue. +helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --set registry.maintenance.readonly.enabled=true --wait +# Our registry is in r/o mode now, so let's get the name of one of the registry Pods. +# Note down the Pod name and replace the '' placeholder below with that value. +# Replace the single quotes to double quotes (' => ") if you are using this with Windows' cmd.exe. +kubectl get pods -n gitlabns -l app=registry -o jsonpath='{.items[0].metadata.name}' +# Run the actual garbage collection. Check the registry's manual if you really want the '-m' parameter. +kubectl exec -n gitlabns -- /bin/registry garbage-collect -m /etc/docker/registry/config.yml +# Reset registry back to original state. +helm upgrade mygitlab gitlab/gitlab -f mygitlab.yml --wait +# All done :) +``` + +### コンテナレジストリに対する管理コマンドの実行 {#running-administrative-commands-against-the-container-registry} + +管理コマンドは、`registry`バイナリと必要な設定の両方が利用可能なレジストリポッドからのみ、コンテナレジストリに対して実行できます。ツールボックス[ポッド](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2629)からこの機能性を提供する方法について議論するために、[イシュー](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2629)\#2629が開かれています。 + +管理コマンドを実行するには: + +1. レジストリポッドに接続します: + + ```shell + kubectl exec -it -- bash + ``` + +1. レジストリポッド内に入ると、`registry`バイナリは`PATH`で使用できるようになり、直接使用できます。設定ファイルは`/etc/docker/registry/config.yml`で利用できます。次の例では、データベース移行の状態を確認します: + + ```shell + registry database migrate status /etc/docker/registry/config.yml + ``` + +詳細およびその他の使用可能なコマンドについては、関連ドキュメントを参照してください: + +- [一般的なレジストリドキュメント](https://docs.docker.com/registry/) +- [GitLab](https://gitlab.com/gitlab-org/container-registry/-/tree/master/docs-gitlab)固有のレジストリドキュメント + +## レジストリレート制限機構設定 {#registry-rate-limiter-configuration} + +レジストリは、コンテナレジストリインスタンスへのトラフィックを制御するためにレート制限機構で設定できます。これは、レジストリを不正使用、DoS攻撃、または過度の使用から保護するのに役立ちます。 + +### ノート {#notes} + +- レート制限は、`registry.redis.rateLimiting`の設定でRedisが適切に構成されている必要があります。 +- レート制限はデフォルトで無効になっています。有効にするには、`registry.rateLimiter.enabled: true`を設定します。 +- リミッターは優先順位に従って適用されます（値が低いものが最初）。 +- `log_only`オプションは、レート制限を適用する前にテストする場合に役立ちます。 + +### レート制限の設定 {#rate-limiter-configuration} + +コンテナレジストリのレート制限を有効化および構成するには、`registry.rateLimiter`設定を使用します。 + +```yaml +registry: + rateLimiter: + enabled: true + limiters: + - name: global_rate_limit + description: "Global IP rate limit" + log_only: false + match: + type: IP + precedence: 10 + limit: + rate: 5000 + period: "minute" + burst: 8000 + action: + warn_threshold: 0.7 + warn_action: "log" + hard_action: "block" +``` + +### リミッターの設定 {#limiters-configuration} + +レートリミッターは、リミッターのリストを使用してレート制限ルールを定義します。各リミッターには、次のプロパティがあります。 + +- `name`:リミッターの固有識別子 +- `description`:リミッターの目的を人間が読める形式で記述したもの +- `log_only`:`true`に設定すると、違反は適用されずにログに記録されるだけです +- `precedence`:リミッターが評価される順序を定義します（値が低いものが最初） +- `match`:リクエストを照合するための基準 +- `limit`:レート制限パラメータ +- `action`:制限に達したときに実行する行動 + +### 制限の設定 {#limit-configuration} + +`limit`セクションでは、実際値のレート制限パラメータを定義します。 + +```yaml +limit: + rate: 100 # Number of requests allowed + period: "minute" # Time period (second, minute, hour, day) + burst: 200 # Allowed burst capacity +``` + +### アクションの設定 {#action-configuration} + +`action`セクションでは、制限に近づいた場合または制限に達した場合に何が起こるかを定義します。 + +```yaml +action: + warn_threshold: 0.7 # Percentage of limit to trigger warning + warn_action: "log" # Action when warning threshold is reached + hard_action: "block" # Action when limit is reached +``` + +### 例 {#examples} + +#### グローバルIPレート制限 {#global-ip-rate-limit} + +この例では、単一のIPアドレスからのすべてのリクエストを制限します。 + +```yaml +- name: global_rate_limit + description: "Global IP rate limit" + log_only: false + match: + type: IP + precedence: 10 + limit: + rate: 5000 + period: "minute" + burst: 8000 + action: + warn_threshold: 0.7 + warn_action: "log" + hard_action: "block" +``` diff --git a/doc-locale/ja-jp/charts/registry/metadata_database.md b/doc-locale/ja-jp/charts/registry/metadata_database.md new file mode 100644 index 0000000000..c9d45e45af --- /dev/null +++ b/doc-locale/ja-jp/charts/registry/metadata_database.md @@ -0,0 +1,532 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: コンテナレジストリメタデータデータベースを管理します +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +{{< history >}} + +- [導入](https://gitlab.com/groups/gitlab-org/-/epics/5521)：GitLab 16.4で[ベータ](https://docs.gitlab.com/policy/development_stages_support/#beta)版[機能](https://gitlab.com/groups/gitlab-org/-/epics/5521)として +- GitLab 17.3で[一般提供](https://gitlab.com/gitlab-org/gitlab/-/issues/423459)。 + +{{< /history >}} + +メタデータデータベースにより、オンラインガベージコレクションなど、多くの新しいレジストリ機能が有効になり、多くのレジストリ操作の効率性が向上します。このページには、データベースの作成方法に関する情報が記載されています。 + +## メタデータデータベース機能のサポート {#metadata-database-feature-support} + +既存のレジストリをメタデータデータベースに移行し、オンラインガベージコレクションを使用できます。 + +データベースが有効になっている一部の機能は、GitLab.comでのみ有効になっており、レジストリデータベースの自動データベースプロビジョニングは利用できません。[コンテナレジストリ](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)データベースに関連する[機能](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)の[状態](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)については、[管理ドキュメント](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)の[機能](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)の[サポート](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)セクションを[レビュー](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#metadata-database-feature-support)してください。 + +## データベースの作成 {#create-the-database} + +以下の手順に従って、データベースとロールを手動で作成します。 + +{{< alert type="note" >}} + +これらの手順は、バンドルされたPostgreSQLサーバーを使用していることを前提としています。独自のサーバーを使用している場合、接続方法に多少の違いがあります。 + +{{< /alert >}} + +1. データベースのパスワードでシークレットを作成します。 + + ```shell + kubectl create secret generic RELEASE_NAME-registry-database-password --from-literal=password=randomstring + ``` + +1. データベースインスタンスにログインします: + + ```shell + kubectl exec -it $(kubectl get pods -l app.kubernetes.io/name=postgresql -o custom-columns=NAME:.metadata.name --no-headers) -- bash + ``` + + ```shell + PGPASSWORD=${POSTGRES_POSTGRES_PASSWORD} psql -U postgres -d template1 + ``` + +1. データベースユーザーを作成します: + + ```sql + CREATE ROLE registry WITH LOGIN; + ``` + +1. データベースユーザーパスワードを設定します。 + + 1. パスワードをフェッチします: + + ```shell + kubectl get secret RELEASE_NAME-registry-database-password -o jsonpath="{.data.password}" | base64 --decode + ``` + + 1. `psql`プロンプトでパスワードを設定します: + + ```sql + \password registry + ``` + +1. データベースを作成します: + + ```sql + CREATE DATABASE registry WITH OWNER registry; + ``` + +1. PostgreSQLコマンドラインから、次に`exit`を使用してコンテナから安全に終了します: + + ```shell + template1=# exit + ...@gitlab-postgresql-0/$ exit + ``` + +## Helmチャートインストールでメタデータデータベースを有効にする {#enable-the-metadata-database-for-helm-charts-installations} + +前提要件: + +- GitLab 17.3以降。 +- レジストリポッドからアクセス可能なPostgreSQLデータベースバージョン12以降。 +- KubernetesクラスターおよびHelmデプロイメントへのローカルアクセス。 +- レジストリポッドへのSSHアクセス。 + +状況に一致する手順に従ってください: + +- [新規インストール](#new-installations)または初めてコンテナ[レジストリ](#new-installations)を有効にします。 +- 既存のコンテナイメージをメタデータデータベースに移行します: + - [ワンステップ移行](#one-step-migration)。比較的小規模なレジストリ、またはダウンタイムを回避するための要件がない場合にのみお勧めします。 + - [3段階移行](#three-step-migration)。大規模なコンテナレジストリに推奨。 + +{{< alert type="note" >}} + +さまざまな[テスト](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#completed-tests-and-user-reports)およびユーザー[レジストリ](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#completed-tests-and-user-reports)の[インポート](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#completed-tests-and-user-reports)時間のリストについては、[イシュー423459のこのテーブル](https://gitlab.com/gitlab-org/gitlab/-/issues/423459#completed-tests-and-user-reports)を参照してください。レジストリデプロイメントは一意であり、インポート時間はイシューで報告されているものよりも長くなる可能性があります。 + +{{< /alert >}} + +### 始める前に {#before-you-start} + +[レジストリ](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#before-you-start)管理[ガイド](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#before-you-start)の[開始する前に](https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#before-you-start)セクションをお読みください。 + +### 新規インストール {#new-installations} + +データベースを有効にするには: + +1. [データベースとKubernetesシークレットを作成します](#create-the-database)。 +1. リリースの現在のHelm値を取得し、ファイルに保存します。たとえば、`gitlab`という名前のリリースと`values.yml`という名前のファイルの場合: + + ```shell + helm get values gitlab > values.yml + ``` + +1. 次の行を`values.yml`ファイルに追加します: + + ```yaml + registry: + enabled: true + database: + enabled: true + name: registry # must match the database name you created above + user: registry # must match the database username you created above + password: + secret: gitlab-registry-database-password # must match the secret name + key: password # must match the secret key to read the password from + sslmode: verify-full + # these settings are inherited from `global.psql.ssl` + ssl: + secret: gitlab-registry-postgresql-ssl # you will need to create this secret manually + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + migrations: + enabled: true # this option will execute the schema migration as part of the registry deployment + ``` + +1. 任意。スキーマ移行が正しく適用されていることを確認できます。次のいずれかを実行できます: + - たとえば、移行ジョブのログ出力をレビューします: + + ```shell + kubectl logs jobs/gitlab-registry-migrations-1 + ... + OK: applied 154 migrations in 13.752s + ``` + + - または、Postgresデータベースに接続して、`schema_migrations`テーブルをクエリします: + + ```sql + SELECT * FROM schema_migrations; + ``` + + すべての行に対して`applied_at`列のタイムスタンプが入力されていることを確認します。 + +レジストリは、メタデータデータベースを使用する準備ができました! + +### 既存のレジストリ {#existing-registries} + +既存のコンテナレジストリデータを、ワンステップまたは3つのステップで移行できます。いくつかの要因が移行の期間に影響します: + +- 既存のレジストリデータのサイズ。 +- PostgresSQLインスタンスの仕様。 +- クラスターで実行されているレジストリポッドの数。 +- レジストリ、PostgresSQL、および設定されたオブジェクトストレージ間のネットワークレイテンシー。 + +{{< alert type="note" >}} + +[移行](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5293)プロセスを自動化する作業は、[イシュー5293](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5293)で[追跡](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5293)されています。 + +{{< /alert >}} + +#### 要件 {#requirements} + +ワンステップまたは3段階移行を試みる前に、次の手順を完了する必要があります: + +1. [データベースとKubernetesシークレットを作成します](#create-the-database)。 +1. リリースの現在のHelm値を取得し、ファイルに保存します。たとえば、`gitlab`という名前のリリースと`values.yml`という名前のファイルの場合: + + ```shell + helm get values gitlab > values.yml + ``` + +#### ワンステップ移行 {#one-step-migration} + +ワンステップ移行を行うときは、次のことに注意してください: + +- 移行中、レジストリは`read-only`モードのままにする必要があります。 +- 移行が実行されているポッドが終了した場合は、プロセスを完全に再起動する必要があります。このプロセスを改善する作業は、[イシュー5293](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5293)で[追跡](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5293)されています。 + +既存のコンテナレジストリをワンステップでメタデータデータベースに移行するには: + +1. [要件](#requirements)セクションに記載されている手順に従ってください。 +1. `values.yml`ファイルの`registry:`セクションを見つけ、`database`セクションを追加します。設定: + - `database.configure`を`true`に設定します。 + - `database.enabled`を`false`に設定します。 + - `maintenance.readonly.enabled`を`true`に設定します。 + - `migrations.enabled`を`true`に設定します。 + + ```yaml + registry: + enabled: true + maintenance: + readonly: + enabled: true # must remain set to true while the migration is executed + database: + configure: true # must be true for the migration step + enabled: false # must be false! + name: registry # must match the database name you created above + user: registry # must match the database username you created above + password: + secret: gitlab-registry-database-password # must match the secret name + key: password # must match the secret key to read the password from + sslmode: verify-full # SSL connection mode. See https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-PROTECTION for more options. + ssl: + secret: gitlab-registry-postgresql-ssl # you will need to create this secret manually + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + migrations: + enabled: true # this option will execute the schema migration as part of the registry deployment + ``` + +1. Helmインストールをアップグレードして、デプロイメントの変更を適用します: + + ```shell + helm upgrade gitlab gitlab/gitlab -f values.yml + ``` + +1. SSH経由でレジストリポッドの1つに接続します。たとえば、`gitlab-registry-5ddcd9f486-bvb57`という名前のポッドの場合: + + ```shell + kubectl exec -ti gitlab-registry-5ddcd9f486-bvb57 bash + ``` + +1. ホームディレクトリに変更し、次のコマンドを実行します: + + ```shell + cd ~ + /usr/bin/registry database import /etc/docker/registry/config.yml + ``` + +1. コマンドが正常に完了した場合、すべてのイメージが完全にインポートされました。これで、データベースを有効にし、設定で読み取り専用モードをオフにすることができます: + + ```yaml + registry: + enabled: true + maintenance: + readonly: + enabled: false + database: + configure: true # once database.enabled is set to true, this option can be removed + enabled: true + name: registry + user: registry + password: + secret: gitlab-registry-database-password + key: password + migrations: + enabled: true + ``` + +1. Helmインストールをアップグレードして、デプロイメントの変更を適用します: + + ```shell + helm upgrade gitlab gitlab/gitlab -f values.yml + ``` + +メタデータデータベースをすべての操作に使用できるようになりました! + +#### 3段階移行 {#three-step-migration} + +既存のコンテナレジストリデータを、3つの個別のステップでメタデータデータベースに移行できます。これは、次の場合に推奨されます: + +- レジストリに大量のデータが含まれている。 +- 移行中のダウンタイムを最小限に抑える必要がある。 + +3つのステップで移行するには、次のことを行う必要があります: + +1. リポジトリの事前インポート +1. すべてのリポジトリデータをインポートします +1. 一般的なblobをインポートする + +{{< alert type="note" >}} + +ユーザーは、ステップ1の[インポート](https://gitlab.com/gitlab-org/gitlab/-/issues/423459)が[1時間あたり2～4 TBのレートで完了したと報告しています](https://gitlab.com/gitlab-org/gitlab/-/issues/423459)。スピードが遅い場合、100TBを超えるデータを持つレジストリでは、48時間以上かかることがあります。 + +{{< /alert >}} + +##### ステップ1リポジトリの事前インポート {#step-1-pre-import-repositories} + +インスタンスが大きい場合、レジストリのサイズによっては、このプロセスを完了するのに数時間または数日かかることがあります。このプロセス中もレジストリを使用できます。 + +{{< alert type="warning" >}} + +[移行](https://gitlab.com/gitlab-org/container-registry/-/issues/1162)を[再起動](https://gitlab.com/gitlab-org/container-registry/-/issues/1162)することは[まだ不可能](https://gitlab.com/gitlab-org/container-registry/-/issues/1162)であるため、[移行](https://gitlab.com/gitlab-org/container-registry/-/issues/1162)を完了まで実行することが重要です。操作を停止する必要がある場合は、このステップを再起動する必要があります。 + +{{< /alert >}} + +1. [要件](#requirements)セクションに記載されている手順に従ってください。 +1. `values.yml`ファイルの`registry:`セクションを見つけ、`database`セクションを追加します。設定: + - `database.configure`を`true`に設定します。 + - `database.enabled`を`false`に設定します。 + - `migrations.enabled`を`true`に設定します。 + + ```yaml + registry: + enabled: true + database: + configure: true + enabled: false # must be false! + name: registry # must match the database name you created above + user: registry # must match the database username you created above + password: + secret: gitlab-registry-database-password # must match the secret name + key: password # must match the secret key to read the password from + sslmode: verify-full # SSL connection mode. See https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-PROTECTION for more options. + ssl: + secret: gitlab-registry-postgresql-ssl # you will need to create this secret manually + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + migrations: + enabled: true # this option will execute the schema migration as part of the registry deployment + ``` + +1. ファイルを保存し、Helmインストールをアップグレードして、デプロイメントの変更を適用します: + + ```shell + helm upgrade gitlab gitlab/gitlab -f values.yml + ``` + +1. SSHでレジストリポッドの1つに接続します。たとえば、`gitlab-registry-5ddcd9f486-bvb57`という名前のポッドの場合: + + ```shell + kubectl exec -ti gitlab-registry-5ddcd9f486-bvb57 bash + ``` + +1. ホームディレクトリに変更し、次のコマンドを実行します: + + ```shell + cd ~ + /usr/bin/registry database import --step-one /etc/docker/registry/config.yml + ``` + +`registry import complete`が表示されると、最初のステップが完了します。 + +{{< alert type="note" >}} + +要件となるダウンタイムを削減するために、できるだけ早く次のステップをスケジュールするようにしてください。ステップ1が完了してから1週間以内が理想的です。次のステップの前にレジストリに書き込まれた新しいデータは、そのステップに時間がかかる原因となります。 + +{{< /alert >}} + +##### ステップ2すべてのリポジトリデータをインポートします {#step-2-import-all-repository-data} + +このステップでは、レジストリを`read-only`モードに設定する必要があります。このプロセス中にダウンタイムに十分な時間を確保してください。 + +1. `values.yml`ファイルでレジストリを`read-only`モードに設定します: + + ```yaml + registry: + enabled: true + maintenance: + readonly: + enabled: true # must be true! + database: + configure: true + enabled: false # must be false! + name: registry # must match the database name you created above + user: registry # must match the database username you created above + password: + secret: gitlab-registry-database-password # must match the secret name + key: password # must match the secret key to read the password from + sslmode: verify-full # SSL connection mode. See https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-PROTECTION for more options. + ssl: + secret: gitlab-registry-postgresql-ssl # you will need to create this secret manually + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + migrations: + enabled: true # this option will execute the schema migration as part of the registry deployment + ``` + +1. ファイルを保存し、Helmインストールをアップグレードして、デプロイメントの変更を適用します: + + ```shell + helm upgrade gitlab gitlab/gitlab -f values.yml + ``` + +1. SSHでレジストリポッドの1つに接続します。たとえば、`gitlab-registry-5ddcd9f486-bvb57`という名前のポッドの場合: + + ```shell + kubectl exec -ti gitlab-registry-5ddcd9f486-bvb57 bash + ``` + +1. ホームディレクトリに変更し、次のコマンドを実行します: + + ```shell + cd ~ + /usr/bin/registry database import --step-two /etc/docker/registry/config.yml + ``` + +1. コマンドが正常に完了した場合、すべてのイメージが完全にインポートされました。これで、データベースを有効にし、設定で読み取り専用モードをオフにすることができます: + + ```yaml + registry: + enabled: true + maintenance: # this section can be removed + readonly: + enabled: false + database: + configure: true # once database.enabled is set to true, this option can be removed + enabled: true # must be true! + name: registry # must match the database name you created above + user: registry # must match the database username you created above + password: + secret: gitlab-registry-database-password # must match the secret name + key: password # must match the secret key to read the password from + sslmode: verify-full # SSL connection mode. See https://www.postgresql.org/docs/current/libpq-ssl.html#LIBPQ-SSL-PROTECTION for more options. + ssl: + secret: gitlab-registry-postgresql-ssl # you will need to create this secret manually + clientKey: client-key.pem + clientCertificate: client-cert.pem + serverCA: server-ca.pem + migrations: + enabled: true # this option will execute the schema migration as part of the registry deployment + ``` + +1. ファイルを保存し、Helmインストールをアップグレードして、デプロイメントの変更を適用します: + + ```shell + helm upgrade gitlab gitlab/gitlab -f values.yml + ``` + +メタデータデータベースをすべての操作に使用できるようになりました! + +##### ステップ3一般的なblobをインポートする {#step-3-import-common-blobs} + +レジストリは、メタデータにデータベースを完全に使用するようになりましたが、潜在的に未使用のレイヤーblobにはまだアクセスできません。 + +プロセスを完了するには、移行の最後のステップを実行します: + +```shell +cd ~ +/usr/bin/registry database import --step-three /etc/docker/registry/config.yml +``` + +コマンドが正常に完了すると、レジストリがデータベースに完全に移行されます! + +## データベース移行 {#database-migrations} + +コンテナレジストリは、次の2種類の移行をサポートしています: + +- **標準スキーマ移行**:新しいアプリケーションコードをデプロイする前に実行する必要があるデータベース構造への変更。これらは、デプロイの遅延を回避するために高速である必要があります。 + +- **デプロイ**後の**移行**アプリケーションの実行中に実行できるデータベース構造への変更。大規模なテーブルにインデックスを作成するなど、より長い操作に使用され、スタートアップの遅延とアップグレードのダウンタイムの延長を回避します。 + +### データベース移行を適用する {#apply-database-migrations} + +デフォルトでは、`database.migrations.enabled`が`true`に設定されている場合、レジストリチャートは標準スキーマとデプロイ後の移行の両方を自動的に適用します。 + +アップグレード中のダウンタイムを削減するために、デプロイ後の移行をスキップし、アプリケーションの起動後に手動で適用できます: + +1. レジストリデプロイメントの場合、`ExtraEnv`を使用して`SKIP_POST_DEPLOYMENT_MIGRATIONS`環境変数を`true`に設定します: + + ```yaml + registry: + extraEnv: + SKIP_POST_DEPLOYMENT_MIGRATIONS: true + ``` + +1. [アップグレード](_index.md#running-administrative-commands-against-the-container-registry)後、[レジストリ](_index.md#running-administrative-commands-against-the-container-registry)[ポッド](_index.md#running-administrative-commands-against-the-container-registry)に接続します + +1. 保留中のデプロイ後の移行を適用します: + + ```shell + registry database migrate up /etc/docker/registry/config.yml + ``` + +{{< alert type="note" >}} + +`migrate up`コマンドは、移行の適用方法を制御するために使用できる追加のフラグをいくつか提供します。詳細については、`registry database migrate up --help`を実行してください。 + +{{< /alert >}} + +## トラブルシューティング {#troubleshooting} + +### エラー： `panic: interface conversion: interface {} is nil, not bool` {#error-panic-interface-conversion-interface--is-nil-not-bool} + +[既存のレジストリ](#existing-registries)をインポートする際に、このエラーが表示されることがあります。 + +```shell +panic: interface conversion: interface {} is nil, not bool +``` + +これは既知の[イシュー](https://gitlab.com/gitlab-org/container-registry/-/merge_requests/2041)で、レジストリバージョン`v4.15.2-gitlab`およびGitLab 17.9で修正されています。 + +このイシューを回避するには、レジストリのバージョンをアップグレードしてください。 + +1. `values.yml`ファイルで、レジストリイメージのtagを設定します。 + + ```yaml + registry: + image: + tag: v4.15.2-gitlab + ``` + +1. Helmインストールをアップグレードします。 + + ```shell + helm upgrade gitlab -f values.yml + ``` + +または、レジストリの設定を手動でアップデートすることもできます。 + +- `/etc/docker/registry/config.yml`で、ストレージプロバイダーの`parallelwalk`を`false`に設定します。たとえば、S3の場合: + + ```yaml + storage: + s3: + parallelwalk: false + ``` diff --git a/doc-locale/ja-jp/charts/shared-secrets.md b/doc-locale/ja-jp/charts/shared-secrets.md new file mode 100644 index 0000000000..1af911bcc5 --- /dev/null +++ b/doc-locale/ja-jp/charts/shared-secrets.md @@ -0,0 +1,90 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Shared-Secretsジョブの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +`shared-secrets`ジョブは、特に手動で指定しない限り、インストール全体で使用されるさまざまなシークレットのプロビジョニングを行います。内容は以下のとおりです。 + +1. 初期rootパスワード +1. すべてのパブリックサービスに対する自己署名TLS証明書:GitLab、MinIO、およびレジストリ +1. レジストリ認証 +1. MinIO、レジストリ、GitLab Shell、およびGitalyシークレット +1. RedisおよびPostgreSQLパスワード +1. SSHホストキー +1. [暗号化された認証情報](https://docs.gitlab.com/administration/encrypted_configuration/)のGitLab Railsシークレット + +## インストールコマンドラインオプション {#installation-command-line-options} + +以下のテーブルには、`--set`フラグを使用して`helm install`コマンドに指定できるすべての設定が含まれています。 + +| パラメータ | デフォルト | 説明 | +|------------------------------|------------------------------------------------------------|-------------| +| `enabled` | `true` | [下記参照](#disable-functionality) | +| `env` | `production` | Rails環境 | +| `podLabels` | | 補足のPodラベル。セレクターには使用されません。 | +| `annotations` | | 補足のPodアノテーション。 | +| `image.pullPolicy` | `Always` | **非推奨**:代わりに`global.kubectl.image.pullPolicy`を使用してください。 | +| `image.pullSecrets` | | **非推奨**:代わりに`global.kubectl.image.pullSecrets`を使用してください。 | +| `image.repository` | `registry.gitlab.com/gitlab-org/build/cng/kubectl` | **非推奨**:代わりに`global.kubectl.image.repository`を使用してください。 | +| `image.tag` | `1f8690f03f7aeef27e727396927ab3cc96ac89e7` | **非推奨**:代わりに`global.kubectl.image.tag`を使用してください。 | +| `priorityClassName` | | ポッドに割り当てられた[優先度クラス](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) | +| `rbac.create` | `true` | RBACロールとバインディングを作成 | +| `resources` | | リソースリクエスト、制限 | +| `securityContext.fsGroup` | `65534` | ファイルシステムのマウントに使用するユーザーID | +| `securityContext.runAsUser` | `65534` | コンテナの実行に使用するユーザーID | +| `selfsign.caSubject` | `GitLab Helm Chart` | selfsign CAサブジェクト | +| `selfsign.image.repository` | `registry.gitlab.com/gitlab-org/build/cnf/cfssl-self-sign` | selfsignイメージリポジトリ | +| `selfsign.image.pullSecrets` | | イメージリポジトリのシークレット | +| `selfsign.image.tag` | | selfsignイメージtag | +| `selfsign.keyAlgorithm` | `rsa` | selfsign証明書キーアルゴリズム | +| `selfsign.keySize` | `4096` | selfsign証明書キーサイズ | +| `serviceAccount.enabled` | `true` | ジョブのserviceAccountNameを定義します | +| `serviceAccount.create` | `true` | ServiceAccountの作成 | +| `serviceAccount.name` | `RELEASE_NAME-shared-secrets` | ジョブ（および`serviceAccount.create=true`の場合はserviceAccount自体）で指定するサービスアカウント名 | +| `tolerations` | `[]` | ポッド割り当てのTolerationラベル | + +## ジョブ設定の例 {#job-configuration-examples} + +### `tolerations` {#tolerations} + +`tolerations`を使用すると、taintされたworkerノードでポッドをスケジュールできます + +`tolerations`の使用例を以下に示します。 + +```yaml +tolerations: +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoSchedule" +- key: "node_label" + operator: "Equal" + value: "true" + effect: "NoExecute" +``` + +## 機能の無効化 {#disable-functionality} + +一部のユーザーは、このジョブによって提供される機能を明示的に無効にしたい場合があります。これを行うために、ブール値として`enabled`フラグを提供しました。`true`がデフォルトです。 + +ジョブを無効にするには、`--set shared-secrets.enabled=false`を渡すか、`-f`フラグを介してYAMLで以下を`helm`に渡します。 + +```yaml +shared-secrets: + enabled: false +``` + +{{< alert type="note" >}} + +このジョブを無効にする場合は、すべてのシークレットを手動で作成し、必要なシークレットコンテンツをすべて提供**する**必要があります。詳細については、[installation/secrets](../installation/secrets.md#manual-secret-creation-optional)を参照してください。 + +{{< /alert >}} diff --git a/doc-locale/ja-jp/charts/traefik/_index.md b/doc-locale/ja-jp/charts/traefik/_index.md new file mode 100644 index 0000000000..6d825e96ac --- /dev/null +++ b/doc-locale/ja-jp/charts/traefik/_index.md @@ -0,0 +1,41 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers +title: Traefikの使用 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +[Traefik Helm Chart](https://artifacthub.io/packages/helm/traefik/traefik)は、Ingressコントローラーとして[バンドルされたNGINX Helm Chart](../nginx/_index.md)を置き換えることができます。 + +Traefikは、ネイティブの[Kubernetes Ingress](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)オブジェクトを[IngressRoute](https://doc.traefik.io/traefik/routing/providers/kubernetes-crd/#kind-ingressroute)オブジェクトに変換します。 + +Traefikは[IngressRouteTCP](https://doc.traefik.io/traefik/routing/providers/kubernetes-crd/#kind-ingressroutetcp)オブジェクトを介してSSH経由のGitもサポートしています。[`global.ingress.provider`](../globals.md#configure-ingress-settings)が`traefik`として構成されている場合、これらはGitLab Shell Chartによってデプロイされます。 + +## Traefikの構成 {#configuring-traefik} + +構成の詳細については、[Traefik Helm Chartのドキュメント](https://github.com/traefik/traefik-helm-chart/tree/master/traefik)を参照してください。 + +[Traefikの構成例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/values-traefik-ingress.yaml)には、GitLab Helm Chartでテストされた値の詳細なYAMLが含まれています。 + +### グローバル設定 {#global-settings} + +このチャートでは、いくつかの共通のグローバル設定を共有しています。GitLabやレジストリのホスト名など、一般的な構成オプションについては、[グローバルIngressのドキュメント](../globals.md#configure-ingress-settings)を参照してください。 + +### FIPS準拠のTraefik {#fips-compliant-traefik} + +[Traefik Enterprise](https://doc.traefik.io/traefik-enterprise/)は、FIPSコンプライアンスを提供します。Traefik Enterpriseにはライセンスが必要ですが、このチャートには含まれていません。 + +Traefik Enterpriseの詳細については、以下のリンクを参照してください。 + +- [Traefik Enterpriseの機能](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) +- [Traefik Enterprise FIPSイメージ](https://doc.traefik.io/traefik-enterprise/operations/fips-image/) +- [Traefik Enterprise Helm Chart](https://doc.traefik.io/traefik-enterprise/installing/kubernetes/helm/) +- [ArtifactHub上のTraefik Enterprise Operator](https://artifacthub.io/packages/olm/community-operators/traefikee-operator) +- [RedHatカタログ上のTraefik Enterprise Certified OpenShift Operator](https://catalog.redhat.com/software/container-stacks/detail/5e98745a6c5dcb34dfbb1a0a) diff --git a/doc-locale/ja-jp/installation/chart-provenance.md b/doc-locale/ja-jp/installation/chart-provenance.md new file mode 100644 index 0000000000..c19c27e214 --- /dev/null +++ b/doc-locale/ja-jp/installation/chart-provenance.md @@ -0,0 +1,118 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャートのprovenance +--- + +[Helm provenance](https://helm.sh/docs/topics/provenance/)を使用すると、GitLab Helmチャートの整合性とoriginを検証できます。 + +GitLab Helmチャートは、GNUPGキーペアで署名されています。チャートを検証するには、キーペアの公開部分をダウンロードし、エクスポートが必要になる場合があります。[GNU Privacy Handbook](https://www.gnupg.org/gph/en/manual/x56.html)には、GPGキーの管理方法に関する詳細な手順が記載されています。 + +## GitLab Helmチャート署名キーのダウンロードとエクスポート {#download-and-export-the-gitlab-helm-chart-signing-key} + +GitLab Helmチャートのprovenanceを検証するには、公式のGitLab Helm Chart公開署名キーを使用する必要があります。キーは、最初にダウンロードしてから、ローカルのキーリングにエクスポートが必要になる場合があります。 + +### 公開署名キーのダウンロード {#download-the-public-signing-key} + +公式のGitLab Helmチャート署名キーをダウンロードするには、以下を実行します。 + +```shell +gpg --receive-keys --keyserver hkps://keys.openpgp.org '5E46F79EF5836E986A663B4AE30F9C687683D663' +``` + +例: + +```shell +$ gpg --receive-keys --keyserver hkps://keys.openpgp.org '5E46F79EF5836E986A663B4AE30F9C687683D663' +gpg: key E30F9C687683D663: public key "GitLab, Inc. Helm charts " imported +gpg: Total number processed: 1 +gpg: imported: 1 +``` + +このコマンドはキーをダウンロードし、defaultのキーリングに追加します。GitLab Helmチャート署名キーは、別のキーリングに配置する必要があります。`--no-default-keyring --keyring ` `gpg`オプションを使用すると、GitLab Chart署名キーのみを含む新しいキーリングを作成できます。 + +例: + +```shell +$ gpg --keyring $HOME/.gnupg/gitlab.pubring.kbx --keyserver hkps://keys.openpgp.org --no-default-keyring --receive-keys '5E46F79EF5836E986A663B4AE30F9C687683D663' +gpg: keybox '$HOME/.gnupg/gitlab.pubring.kbx' created +gpg: key E30F9C687683D663: public key "GitLab, Inc. Helm charts " imported +gpg: Total number processed: 1 +gpg: imported: 1 +``` + +### 署名キーのエクスポート {#export-the-signing-key} + +defaultでは、GnuPG v2は、Helmチャートのprovenance検証と互換性のない形式でキーリングを保存します。Helmチャートを検証するには、最初にキーリングをレガシー形式にエクスポートする必要があります。キーリングを適切な形式にエクスポートするには、次のいずれかの操作を行います。 + +- defaultキーリングからエクスポートします。 + + ```shell + gpg --export --output gitlab.pubring.gpg '5E46F79EF5836E986A663B4AE30F9C687683D663' + ``` + +- `--no-default-keyring --keyring `オプションを使用して、別のキーリングからキーをエクスポートします。 + + ```shell + gpg --export --output $HOME/.gnupg/gitlab.pubring.gpg --keyring $HOME/.gnupg/gitlab.pubring.kbx --no-default-keyring '5E46F79EF5836E986A663B4AE30F9C687683D663' + ``` + +## チャートの検証 {#verify-a-chart} + +GitLab Helmチャートは、次のいずれかの方法で検証できます。 + +- チャートをダウンロードして`helm verify`を実行する。 +- チャートのインストール中に`--verify`オプションを使用する。 + +### ダウンロードしたチャートの検証 {#verify-a-downloaded-chart} + +`helm verify`コマンドを使用して、ダウンロードしたチャートを検証できます。検証可能なチャートをダウンロードするには、`helm pull --prov`コマンドを使用します。例: + +```shell +helm pull --prov gitlab/gitlab +``` + +`--version`オプションを使用して、特定のチャートバージョンをダウンロードします。例: + +```shell +helm pull --prov gitlab/gitlab --version 7.9.0 +``` + +次に、`helm verify`コマンドを使用して、ダウンロードしたチャートを検証できます。 + +例: + +```shell +helm verify --keyring $HOME/.gnupg/gitlab.pubring.gpg gitlab-7.9.0.tgz +Signed by: GitLab, Inc. Helm charts +Using Key With Fingerprint: 5E46F79EF5836E986A663B4AE30F9C687683D663 +Chart Hash Verified: sha256:789ec56d929c7ec403fc05249639d0c48ff6ab831f90db7c6ac133534d0aba19 +``` + +`--verify`オプションと`helm pull command`を使用して、pullコマンドとverifyコマンドを組み合わせることができます。 + +例: + +```shell +helm pull --prov gitlab/gitlab --verify --keyring $HOME/.gnupg/gitlab.pubring.gpg +Signed by: GitLab, Inc. Helm charts +Using Key With Fingerprint: 5E46F79EF5836E986A663B4AE30F9C687683D663 +Chart Hash Verified: sha256:789ec56d929c7ec403fc05249639d0c48ff6ab831f90db7c6ac133534d0aba19 +``` + +### インストール中のチャートの検証 {#verify-a-chart-during-installation} + +`--verify`オプションを`helm install`または`helm upgrade`コマンドのいずれかで使用して、インストール中にチャートを検証できます。 + +- 例：`helm install`: + + ```shell + helm install --verify --keyring $HOME/.gnupg/gitlab.pubring.gpg gitlab gitlab/gitlab --set certmanager-issuer.email= --set global.hosts.domain= + ``` + +- 例：`helm upgrade`: + + ```shell + helm upgrade --install --verify --keyring $HOME/.gnupg/gitlab.pubring.gpg gitlab gitlab/gitlab --set certmanager-issuer.email= --set global.hosts.domain= + ``` diff --git a/doc-locale/ja-jp/installation/cloud/_index.md b/doc-locale/ja-jp/installation/cloud/_index.md new file mode 100644 index 0000000000..d730d56ba6 --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/_index.md @@ -0,0 +1,61 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのクラウドプロバイダーの設定 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabチャートをデプロイする前に、選択したクラウドプロバイダーのリソースを構成する必要があります。 + +GitLabチャートは、少なくとも8つのvCPUと30GiBのRAMを持つクラスターに適合するように設計されています。本番環境以外のインスタンスをデプロイする場合は、より小さなクラスターに合うようにデフォルト値を小さくすることができます。 + +## サポートされているKubernetesリリース {#supported-kubernetes-releases} + +GitLab Helmチャートは、以下のKubernetesリリースをサポートしています。 + +| Kubernetesリリース | 状態 | 最小GitLabバージョン | アーキテクチャ | サポート終了 | +|--------------------|-------------|------------------------|---------------|-------------| +| 1.33 | サポート対象 | 18.1 | x86-64 | 2026-06-28 | +| 1.32 | サポート対象 | 17.11 | x86-64 | 2026-02-28 | +| 1.31 | サポート対象 | 17.6 | x86-64 | 2025-10-28 | +| 1.30 | 非推奨 | 17.6 | x86-64 | 2025-06-28 | +| 1.29 | サポート対象外 | 17.0 | x86-64 | 2025-02-28 | +| 1.28 | サポート対象外 | 17.0 | x86-64 | 2024-10-28 | +| 1.27 | サポート対象外 | 16.6 | x86-64 | 2024-06-28 | +| 1.26 | サポート対象外 | 16.5 | x86-64 | 2024-02-28 | +| 1.25 | サポート対象外 | 16.5 | x86-64 | 2023-10-28 | +| 1.24 | サポート対象外 | 16.5 | x86-64 | 2023-07-28 | +| 1.23 | サポート対象外 | 16.5 | x86-64 | 2023-02-28 | +| 1.22 | サポート対象外 | 16.5 | x86-64 | 2022-10-28 | + +GitLab Helmチャートは、新しいマイナーKubernetesリリースを初期リリースから3か月後にサポートすることを目指しています。上記のリリースよりも新しいリリースの互換性の問題については、[イシュートラッカー](https://gitlab.com/gitlab-org/charts/gitlab/-/issues)へのご報告をお待ちしております。 + +一部のGitLabの機能は、非推奨のリリースや、上記のリリースよりも古いリリースでは動作しない可能性があります。 + +一部のコンポーネント（[Kubernetes用エージェント](https://docs.gitlab.com/user/clusters/agent/)、[GitLab Operator](https://docs.gitlab.com/operator/installation/)など）では、GitLabが異なるクラスターリリースをサポートしている場合があります。 + +{{< alert type="warning" >}} + +Kubernetesノードは、x86-64アーキテクチャを使用する必要があります。AArch64/ARM64を含む複数のアーキテクチャのサポートは、現在開発中です。詳細については、[イシュー2899](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2899)を参照してください。 + +{{< /alert >}} + +- 環境のクラスタートポロジに関する推奨事項については、[参照アーキテクチャ](https://docs.gitlab.com/administration/reference_architectures/#available-reference-architectures)を参照してください。 +- 3つのvCPU、12GiBのクラスターに適合するようにリソースを調整する例については、[最小GKEサンプルvaluesファイル](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/values-gke-minimum.yaml)を参照してください。 + +## 特定のクラウドプロバイダー向けの手順 {#instructions-for-specific-cloud-providers} + +環境内にKubernetesクラスターを作成して接続します。 + +- [Azure Kubernetes Service](aks.md) +- [Amazon EKS](eks.md) +- [Google Kubernetes Engine](gke.md) +- [OpenShift](openshift.md) +- [Oracle Container Engine for Kubernetes](oke.md) diff --git a/doc-locale/ja-jp/installation/cloud/aks.md b/doc-locale/ja-jp/installation/cloud/aks.md new file mode 100644 index 0000000000..088b136349 --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/aks.md @@ -0,0 +1,93 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャート用のAKSリソースの準備 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +完全に機能するGitLabインスタンスの場合、[Azure Kubernetes Service（AKS）](https://learn.microsoft.com/en-us/azure/aks/what-is-aks)にGitLabチャートをデプロイする前に、いくつかのリソースが必要です。 + +## AKSクラスターの作成 {#creating-the-aks-cluster} + +より簡単に開始できるように、クラスターの作成を自動化するスクリプトが用意されています。または、クラスターを手動で作成することもできます。 + +前提要件: + +- [前提要件](../tools.md)をインストールします。 +- [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli)をインストールし、それを使用して[Azureにサインイン](https://learn.microsoft.com/en-us/cli/azure/get-started-with-azure-cli#how-to-sign-into-the-azure-cli)します。 +- [`jq`をインストールします](https://stedolan.github.io/jq/download/)。 + +### スクリプト型クラスターの作成 {#scripted-cluster-creation} + +[ブートストラップスクリプト](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/aks_bootstrap_script.sh)が作成され、Azureでのユーザーのセットアッププロセスの多くを自動化します。 + +環境変数またはコマンドライン引数から追加のオプションパラメータを指定して、`up`、`down`、または`creds`の引数を読み取ります。 + +- クラスターを作成するには: + + ```shell + ./scripts/aks_bootstrap_script.sh up + ``` + + これは次のようになります: + + 1. 新しいリソース グループを作成します (オプション)。 + 1. 新しいAKSクラスターを作成します。 + 1. 新しいパブリックIPを作成します（オプション）。 + +- 作成されたAKSリソースをcleanするには: + + ```shell + ./scripts/aks_bootstrap_script.sh down + ``` + + これは次のようになります: + + 1. 指定されたリソース グループを削除します (オプション)。 + 1. AKSクラスターを削除します。 + 1. クラスターによって作成されたリソース グループを削除します。 + + `down`引数は、すべてのリソースを削除して即座に終了するコマンドを送信します。実際の削除が完了するまでに数分かかる場合があります。 + +- `kubectl`をクラスターに接続するには: + + ```shell + ./scripts/aks_bootstrap_script.sh creds + ``` + +次のテーブルでは、使用可能なすべての変数を説明します。 + +| 変数 | デフォルト値 | スコープ | 説明 | +|---------------------------|--------------------|---------|-------------| +| `-g --resource-group` | `gitlab-resources` | すべて | 使用するリソース グループの名前。 | +| `-n --cluster-name` | `gitlab-cluster` | すべて | 使用するクラスターの名前。 | +| `-r --region` | `eastus` | `up` | クラスターをインストールするリージョン。 | +| `-v --cluster-version` | 最新 | `up` | クラスターの作成に使用するKubernetesのバージョン。 | +| `-c --node-count` | `2` | `up` | 使用するノードの数。 | +| `-s --node-vm-size` | `Standard_D4s_v3` | `up` | 使用するノードのタイプ。 | +| `-p --public-ip-name` | `gitlab-ext-ip` | `up` | 作成するパブリックIPの名前。 | +| `--create-resource-group` | `false` | `up` | 作成されたすべてのリソースを保持する新しいリソース グループを作成します。 | +| `--create-public-ip` | `false` | `up` | 新しいクラスターで使用するパブリックIPを作成します。 | +| `--delete-resource-group` | `false` | `down` | downコマンドを使用するときにリソース グループを削除します。 | +| `-f --kubctl-config-file` | `~/.kube/config` | `creds` | 更新するKubernetes設定ファイル。代わりに、`-`を使用してYAMLを`stdout`に出力します。 | + +### 手動クラスターの作成 {#manual-cluster-creation} + +8vCPUと30GBのRAMを備えたクラスターをお勧めします。 + +最新の手順については、Microsoftの[AKSのチュートリアル](https://learn.microsoft.com/en-us/azure/aks/learn/quick-kubernetes-deploy-portal)に従ってください。 + +## GitLabへの外部アクセス {#external-access-to-gitlab} + +クラスターが到達可能になるように、外部IPが必要です。最新の手順については、Microsoftの[静的IPアドレスの作成](https://learn.microsoft.com/en-us/azure/aks/static-ip)ガイドに従ってください。 + +## 次の手順 {#next-steps} + +クラスターが稼働状態になり、静的IPとDNSエントリの準備ができたら、[チャートのインストール](../deployment.md)に進みます。 diff --git a/doc-locale/ja-jp/installation/cloud/eks.md b/doc-locale/ja-jp/installation/cloud/eks.md new file mode 100644 index 0000000000..06a71436aa --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/eks.md @@ -0,0 +1,127 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャート用のEKSリソースの準備 +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +完全に機能するGitLabインスタンスの場合、GitLabチャートをデプロイする前に、いくつかのリソースが必要です。 + +## EKSクラスターの作成 {#creating-the-eks-cluster} + +より簡単に開始できるように、クラスターの作成を自動化するスクリプトが用意されています。または、クラスターを手動で作成することもできます。 + +前提要件: + +- [前提要件](../tools.md)をインストールします。 +- [`eksctl`](https://github.com/weaveworks/eksctl#installation)をインストールします。 + +クラスターを手動で作成するには、[Amazon AWS Getting started with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html)を参照してください。EKSクラスターにはEC2マネージドノードを使用し、[Fargate](https://docs.aws.amazon.com/en_us/eks/latest/userguide/fargate.html)は使用しないでください。Fargateには多くの制限があり、GitLab Helmチャートでの使用はサポートされていません。 + +### スクリプト型クラスターの作成 {#scripted-cluster-creation} + +[ブートストラップスクリプト](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/eks_bootstrap_script)が作成され、EKSのユーザー向けに設定プロセスの大部分を自動化します。スクリプトを実行する前に、このリポジトリをクローンする必要があります。 + +スクリプトは以下を行います。 + +1. 新しいEKSクラスターを作成します。 +1. `kubectl`をセットアップし、クラスターに接続します。 + +認証するために、`eksctl`はAWSコマンドラインと同じオプションを使用します。[環境変数](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html)、または[設定ファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)の使用方法については、AWSドキュメントを参照してください。 + +スクリプトは、環境変数、またはコマンドライン引数、およびブートストラップの場合は`up`、clean upの場合は`down`の引数からさまざまなパラメータを読み込みます。 + +以下のテーブルは、すべての変数を記述しています。 + +| 変数 | デフォルト値 | 説明 | +|-------------------|------------------|-------------| +| `REGION` | `us-east-2` | クラスターが存在するリージョン | +| `CLUSTER_NAME` | `gitlab-cluster` | クラスターの名前 | +| `CLUSTER_VERSION` | `1.29` | EKSクラスターのバージョン | +| `NUM_NODES` | `2` | 必要なノード数 | +| `MACHINE_TYPE` | `m5.xlarge` | デプロイするノードのタイプ | + +目的のパラメータを渡して、スクリプトを実行します。デフォルトのパラメータで動作します。 + +```shell +./scripts/eks_bootstrap_script up +``` + +スクリプトは、作成されたEKSリソースのクリーンアップにも使用できます。 + +```shell +./scripts/eks_bootstrap_script down +``` + +### 手動クラスターの作成 {#manual-cluster-creation} + +- 8vCPUおよび30GiBのRAMを備えたクラスターをお勧めします。 + +最新の手順については、Amazonの[EKSの開始方法ガイド](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)に従ってください。 + +管理者は、このプロセスを簡素化するために[Kubernetes用の新しいAWS Service Operator](https://aws.amazon.com/blogs/opensource/aws-service-operator-kubernetes-available/)を検討することもできます。 + +{{< alert type="note" >}} + +AWS Service Operatorを有効にするには、クラスター内でロールを管理する方法が必要です。その管理タスクを処理する初期サービスは、サードパーティのデベロッパーによって提供されます。管理者は、デプロイを計画する際に、そのことを念頭に置いておく必要があります。 + +{{< /alert >}} + +## 永続ボリュームの管理 {#persistent-volume-management} + +Kubernetesでボリューム要求を管理するには、次の2つの方法があります。 + +- 永続ボリュームを手動で作成します。 +- 動的プロビジョニングによる自動永続ボリュームの作成。 + +現在、永続ボリュームの手動プロビジョニングを使用することをお勧めします。Amazon EKSクラスターはデフォルトで複数のゾーンにまたがっています。特定のゾーンにロックされたストレージクラスを使用するように構成されていない場合、動的プロビジョニングは、ポッドがストレージボリュームとは異なるゾーンに存在し、データにアクセスできなくなるシナリオにつながる可能性があります。詳細については、[永続ボリュームをプロビジョニング](../storage.md)する方法を参照してください。 + +Amazon EKS 1.23以降のクラスターでは、手動プロビジョニングと動的プロビジョニングのどちらの場合でも、クラスターに[Amazon EBS CSIアドオン](https://docs.aws.amazon.com/eks/latest/userguide/managing-ebs-csi.html#adding-ebs-csi-eks-add-on)をインストールする必要があります。 + +```shell +eksctl utils associate-iam-oidc-provider --cluster **CLUSTER_NAME** --approve + +eksctl create iamserviceaccount \ + --name ebs-csi-controller-sa \ + --namespace kube-system \ + --cluster **CLUSTER_NAME** \ + --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \ + --approve \ + --role-only \ + --role-name *ROLE_NAME* + +eksctl create addon --name aws-ebs-csi-driver --cluster **CLUSTER_NAME** --service-account-role-arn arn:aws:iam::*AWS_ACCOUNT_ID*:role/*ROLE_NAME* --force + +kubectl annotate serviceaccount ebs-csi-controller-sa -n kube-system eks.amazonaws.com/role-arn=arn:aws:iam::*AWS_ACCOUNT_ID*:role/*ROLE_NAME* +``` + +## GitLabへの外部アクセス {#external-access-to-gitlab} + +デフォルトでは、GitLabチャートをインストールすると、関連付けられたElastic Load Balancer（ELB）を作成するIngressがデプロイされます。ELBのDNS名は事前に不明であるため、[Let's Encrypt](https://letsencrypt.org/)を利用してHTTPS証明書を自動的にプロビジョニングすることは困難です。 + +[独自の証明書を使用](../tls.md#option-2-use-your-own-wildcard-certificate)し、CNAMEレコードを使用して、目的のDNS名を作成されたELBにマップすることをお勧めします。ホスト名を取得する前にELBを最初に作成する必要があるため、次の手順に従ってGitLabをインストールしてください。 + +{{< alert type="note" >}} + +AWS Load Balancerが必要な環境では、[AmazonのElastic Load Balancer](https://docs.aws.amazon.com/eks/latest/userguide/load-balancing.html)には特別な設定が必要です。[クラウドプロバイダーのロードバランサー](../../charts/globals.md#cloud-provider-loadbalancers)を参照してください + +{{< /alert >}} + +## 次のステップ {#next-steps} + +クラスターが起動して実行されたら、[チャートのインストール](../deployment.md)を続行します。`global.hosts.domain`オプションを使用してドメイン名を設定しますが、既存のElastic IPを使用する予定がない限り、`global.hosts.externalIP`オプションを使用して静的IP設定を省略します。 + +Helmのインストール後、次のコマンドを使用して、ELBのホスト名を取得し、CNAMEレコードに配置できます。 + +```shell +kubectl get ingress/RELEASE-webservice-default -ojsonpath='{.status.loadBalancer.ingress[0].hostname}' +``` + +`RELEASE`は、`helm install `で使用されているリリース名に置き換える必要があります。 diff --git a/doc-locale/ja-jp/installation/cloud/gke.md b/doc-locale/ja-jp/installation/cloud/gke.md new file mode 100644 index 0000000000..3a8317c155 --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/gke.md @@ -0,0 +1,105 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのGKEリソースの準備 +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimate +- 製品:GitLab Self-Managed + +{{< /details >}} + +完全に機能するGitLabインスタンスの場合、GitLabチャートをデプロイする前に、いくつかのリソースが必要です。以下に、これらのチャートがGitLab内でどのようにデプロイおよびテストされるかを示します。 + +## GKEクラスターの作成 {#creating-the-gke-cluster} + +開始しやすくするために、クラスターの作成を自動化するスクリプトが用意されています。または、クラスターを手動で作成することもできます。 + +前提要件: + +- [前提要件](../tools.md)をインストールします。 +- [Google SDK](https://cloud.google.com/sdk/docs/install)をインストールします。 + +### スクリプト型クラスターの作成 {#scripted-cluster-creation} + +[ブートストラップスクリプト](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/scripts/gke_bootstrap_script.sh)が作成され、GCP/GKEのユーザー向けにセットアッププロセスの多くを自動化します。 + +このスクリプトは以下を行います。 + +1. 新しいGKEクラスターを作成します。 +1. クラスターがDNSレコードを変更できるようにします。 +1. `kubectl`をセットアップし、クラスターに接続します。 + +このスクリプトは、環境変数とブートストラップの場合は引数`up`、clean upの場合は`down`からさまざまなパラメータを読み取ります。 + +下のテーブルにすべての変数の説明があります。 + +| 変数 | デフォルト値 | 説明 | +|-----------------------|-----------------------------------|-------------| +| `ADMIN_USER` | 現在のgcloudユーザー | セットアップ中にクラスター管理者アクセスを割り当てるユーザー。 | +| `AUTOSCALE_MAX_NODES` | `NUM_NODES` | オートスケーラーがスケールアップするノードの最大数。 | +| `AUTOSCALE_MIN_NODES` | `0` | オートスケーラーがスケールダウンするノードの最小数。 | +| `CLUSTER_NAME` | `gitlab-cluster` | クラスターの名前。 | +| `CLUSTER_VERSION` | GKEの[デフォルト](https://cloud.google.com/kubernetes-engine/docs/release-notes)、GKEリリースノートを確認してください | GKEクラスターのバージョン。 | +| `INT_NETWORK` | デフォルト | このクラスター内で使用するIPスペース。 | +| `MACHINE_TYPE` | `n2d-standard-4` | クラスターインスタンスのタイプ。 | +| `NUM_NODES` | `2` | 必要なノード数。 | +| `PREEMPTIBLE` | `false` | より安価なクラスターは*最大*24時間稼働します。ノード/ディスクにSLAはありません。 | +| `PROJECT` | デフォルトはありません。設定する必要があります。 | GCPプロジェクトのID。 | +| `RBAC_ENABLED` | `true` | クラスターでRBACが有効になっているかどうかを知っている場合は、この変数を設定します。 | +| `REGION` | `us-central1` | クラスターが存在するリージョン。 | +| `SUBNETWORK` | デフォルト | このクラスター内で使用するサブネットワーク。 | +| `USE_STATIC_IP` | `false` | 管理対象DNSを持つ一時的なIPの代わりに、GitLab用の静的IPを作成します。 | +| `ZONE_EXTENSION` | `b` | クラスターインスタンスが存在するゾーン名の拡張子（`a`、`b`、`c`）。 | + +スクリプトを実行するには、目的のパラメータを渡します。必須の`PROJECT`を除き、デフォルトのパラメータで動作します。 + +```shell +PROJECT= ./scripts/gke_bootstrap_script.sh up +``` + +スクリプトを使用して、作成したGKEリソースをクリーンアップすることもできます。 + +```shell +PROJECT= ./scripts/gke_bootstrap_script.sh down +``` + +クラスターを作成したら、[DNSエントリの作成](#dns-entry)に進みます。 + +### 手動クラスターの作成 {#manual-cluster-creation} + +2つのリソース（Kubernetesクラスターと外部IP）をGCPで作成する必要があります。 + +#### Kubernetesクラスターの作成 {#creating-the-kubernetes-cluster} + +Kubernetesクラスターを手動でプロビジョニングするには、[GKEの手順](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster)に従ってください。 + +- 少なくとも2つのノード（それぞれ4vCPUと15GiBのRAM）を持つクラスターをお勧めします。 +- クラスターのリージョンをメモしておいてください。次の手順で必要になります。 + +#### 外部IPの作成 {#creating-the-external-ip} + +クラスターが到達可能になるように、外部IPが必要です。外部IPは、リージョンIPであり、クラスター自体と同じリージョン内にある必要があります。グローバルIPまたはクラスターのリージョン外のIPは**機能しません**。 + +静的IPを実行するには、次のようにします。 + +`gcloud compute addresses create ${CLUSTER_NAME}-external-ip --region $REGION --project $PROJECT` + +新しく作成されたIPのアドレスを取得するには: + +`gcloud compute addresses describe ${CLUSTER_NAME}-external-ip --region $REGION --project $PROJECT --format='value(address)'` + +次のセクションでは、このIPを使用してDNS名にバインドします。 + +## DNSエントリ {#dns-entry} + +クラスターを手動で作成した場合、またはスクリプトによる作成で`USE_STATIC_IP`オプションを使用した場合は、作成したIPを指すAレコードのワイルドカードDNSエントリを持つパブリックドメインが必要です。 + +[Google DNSクイックスタートガイド](https://cloud.google.com/dns/docs/set-up-dns-records-domain-name)に従って、DNSエントリを作成します。 + +## 次のステップ {#next-steps} + +クラスターが起動して実行され、静的IPとDNSエントリの準備ができたら、[チャートのインストール](../deployment.md)に進みます。 diff --git a/doc-locale/ja-jp/installation/cloud/oke.md b/doc-locale/ja-jp/installation/cloud/oke.md new file mode 100644 index 0000000000..b4d89c8770 --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/oke.md @@ -0,0 +1,63 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャート用のOKEリソースの準備 +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +完全に機能するGitLabインスタンスの場合、[Oracle Container Engine for Kubernetes (OKE)](https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengoverview.htm)にGitLabチャートをデプロイする前に、いくつかのリソースが必要です。OKEクラスターを作成する前に、Oracle Cloud Infrastructureテナンシーを[準備](https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengprerequisites.htm)する方法を確認してください。 + +## OKEクラスターの作成 {#creating-the-oke-cluster} + +前提要件: + +- [前提要件](../tools.md)をインストールします。 + +Kubernetesクラスターを手動でプロビジョニングするには、[OKEの手順](https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke.htm)に従ってください。OKEでサポートされているワーカーノードで使用可能なコンピューティング[シェイプ](https://docs.oracle.com/en-us/iaas/Content/ContEng/Reference/contengimagesshapes.htm#shapes)のリストを確認してください。 + +4 OCPUと30GiBのRAMを持つクラスターを推奨します。 + +### GitLabへの外部アクセス {#external-access-to-gitlab} + +デフォルトでは、GitLabチャートは、100MbpsシェイプのOracle Cloud Infrastructureパブリックロードバランサーを作成するIngressコントローラーをデプロイします。ロードバランサーサービスは、ホストサブネットからのものではないフローティングパブリックIPアドレスを割り当てます。 + +チャートのインストール中にシェイプやその他の設定（ポート、SSL、セキュリティリストなど）を変更するには、次のコマンドライン`nginx-ingress.controller.service.annotations`引数を使用できます。たとえば、400Mbpsシェイプのロードバランサーを指定するには、次のようにします。 + +```shell +--set nginx-ingress.controller.service.annotations."service\.beta\.kubernetes\.io/oci-load-balancer-shape"="400Mbps" +``` + +デプロイしたら、Ingressコントローラーサービスに関連付けられている注釈を確認できます。 + +```plaintext +$ kubectl get service gitlab-nginx-ingress-controller -o yaml + +apiVersion: v1 +kind: Service +metadata: + annotations: + ... + service.beta.kubernetes.io/oci-load-balancer-shape: 400Mbps + ... +``` + +詳細については、[OKEロードバランサーのドキュメント](https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingloadbalancer.htm)を確認してください。 + +## 次のステップ {#next-steps} + +クラスターが起動して実行されたら、[チャートのインストール](../deployment.md)を続行します。`global.hosts.domain`オプションでDNSドメイン名を設定しますが、`global.hosts.externalIP`オプションで静的IP設定を省略します。 + +デプロイが完了したら、ロードバランサーのIPアドレスをクエリして、DNSレコードタイプに関連付けることができます。 + +```shell +kubectl get ingress/-webservice-default -ojsonpath='{.status.loadBalancer.ingress[0].ip}' +``` + +``は、`helm install `で使用されるリリース名に置き換える必要があります。 diff --git a/doc-locale/ja-jp/installation/cloud/openshift.md b/doc-locale/ja-jp/installation/cloud/openshift.md new file mode 100644 index 0000000000..7cac29d879 --- /dev/null +++ b/doc-locale/ja-jp/installation/cloud/openshift.md @@ -0,0 +1,120 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャート用のOpenShiftリソースの準備 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +このドキュメントでは、このプロジェクトの自動化スクリプトを使用して、Google CloudにOpenShiftクラスターを作成する方法について説明します。 + +## 準備 {#preparation} + +まず、GitLabメールに関連付けられたRed Hatアカウントが必要です。Red Hat Allianceの担当者にお問い合わせください。担当者からアカウント招待メールが送信されます。Red Hatアカウントを有効にすると、OpenShiftの実行に必要なライセンスとサブスクリプションにアクセスできるようになります。 + +Google Cloudでクラスターを起動するには、パブリックCloud DNSゾーンが登録済みドメインに接続され、Google Cloud DNSで構成されている必要があります。ドメインがまだ利用できない場合は、[このガイド](https://github.com/openshift/installer/blob/master/docs/user/gcp/dns.md)の手順に従って作成してください。 + +### CLIツールとプルシークレットを取得する {#get-the-cli-tools-and-pull-secret} + +OpenShiftクラスター (`openshift-install`) を作成し、クラスター (`oc`) を操作するには、2つのCLIツールが必要です。 + +Red HatのプライベートDockerレジストリからイメージをフェッチするには、プルシークレットが必要です。すべてのデベロッパーは、Red Hatアカウントに関連付けられた異なるプルシークレットを持っています。 + +CLIツールとプルシークレットを取得するには、[Red Hatのクラウド](https://cloud.redhat.com/openshift/install/gcp/installer-provisioned)にアクセスし、Red Hatアカウントでログインしてください。このページで、提供されているリンクを使用して、インストーラーとコマンドラインツールの最新バージョンをダウンロードします。これらのパッケージを解凍し、`openshift-install`と`oc`を`PATH`に配置します。 + +プルシークレットをクリップボードにコピーし、このリポジトリのルートにあるファイル`pull_secret`にコンテンツを書き込みます。このファイルはgitignoreされています。 + +### Google Cloud (GCP) サービスアカウントを作成する {#create-a-google-cloud-gcp-service-account} + +[これらの手順](https://docs.openshift.com/container-platform/4.9/installing/installing_gcp/installing-gcp-account.html#installation-gcp-service-account_installing-gcp-account)に従って、Google Cloud `cloud-native`プロジェクトにサービスアカウントを作成します。そのドキュメントで必須とマークされているすべてのロールをアタッチします。サービスアカウントが作成されたら、JSONキーを生成し、このリポジトリのルートに`gcloud.json`として保存します。このファイルはgitignoreされています。 + +## OpenShiftクラスターを作成する {#create-your-openshift-cluster} + +OpenShiftクラスターを作成するには: + +1. GitLab Operatorリポジトリをクローンします: + + ```shell + git clone https://gitlab.com/gitlab-org/cloud-native/gitlab-operator.git + ``` + +1. スクリプトを実行して、Google CloudでOpenShiftクラスターを作成します: + + ```shell + cd gitlab-operator + ./scripts/create_openshift_cluster.sh + ``` + +これは、3つのコントロールプレーン (master) ノードと3つのworkerノードを持つ6ノードのクラスターになります。このプロセスには約40分かかります。コンソール出力の最後にある手順に従って、クラスターに接続します。 + +作成されると、[Red Hatクラウド](https://cloud.redhat.com/openshift/)にクラスターが登録されていることを確認できるはずです。すべてのインストールログとメタデータは、このリポジトリの`install-$CLUSTER_NAME/`ディレクトリに保存されます。このディレクトリはgitignoreされています。 + +### 設定オプション {#configuration-options} + +設定は、環境変数を設定することにより、ランタイム時に適用できます。すべてのオプションにはデフォルト値があるため、オプションは必要ありません。 + +| 変数 | デフォルト | 説明 | +|----------------------------------|----------------------------------------------|-------------| +| `CLUSTER_NAME` | `ocp-$USER` | クラスターの名前 | +| `BASE_DOMAIN` | `k8s-ft.win` | クラスターのルートドメイン | +| `GCP_PROJECT_ID` | `cloud-native-182609` | Google CloudプロジェクトID | +| `GCP_REGION` | `us-central1` | クラスターのGoogle Cloudリージョン | +| `GOOGLE_APPLICATION_CREDENTIALS` | `gcloud.json` | Google CloudサービスアカウントJSONファイルへのパス | +| `GOOGLE_CREDENTIALS` | `$GOOGLE_APPLICATION_CREDENTIALS`のコンテンツ | Google CloudサービスアカウントJSONファイルのコンテンツ | +| `PULL_SECRET_FILE` | `pull_secret` | Red Hatプルシークレットファイルへのパス | +| `PULL_SECRET` | `$PULL_SECRET_FILE`のコンテンツ | Red Hatプルシークレットファイルのコンテンツ | +| `SSH_PUBLIC_KEY_FILE` | `$HOME/.ssh/id_rsa.pub` | SSH公開鍵ファイルへのパス | +| `SSH_PUBLIC_KEY` | `$SSH_PUBLIC_KEY_FILE`のコンテンツ | SSH公開鍵ファイルの内容 | +| `LOG_LEVEL` | `info` | `openshift-install`出力の詳細度 | +| `INSTALL_DIR` | `install-$CLUSTER_NAME` | 複数のクラスターの起動に役立つ、インストールアセットのディレクトリ | + +{{< alert type="note" >}} + +変数`CLUSTER_NAME`と`BASE_DOMAIN`は組み合わされて、クラスターのドメイン名を構築します。 + +{{< /alert >}} + +## OpenShiftクラスターを削除する {#destroy-your-openshift-cluster} + +OpenShiftクラスターを削除するには: + +1. GitLab Operatorリポジトリをクローンします: + + ```shell + git clone https://gitlab.com/gitlab-org/cloud-native/gitlab-operator.git + ``` + +1. スクリプトを実行して、Google CloudでOpenShiftクラスターを削除します。これには約4分かかります: + + ```shell + cd gitlab-operator + ./scripts/destroy_openshift_cluster.sh + ``` + +設定は、次の環境変数を設定することにより、ランタイム時に適用できます。すべてのオプションにはデフォルト値があるため、オプションは必要ありません。 + +| 変数 | デフォルト------------------------------------- | 説明 | +|----------------------------------|----------------------------------------------|-------------| +| `GOOGLE_APPLICATION_CREDENTIALS` | `gcloud.json` | Google CloudサービスアカウントJSONファイルへのパス | +| `GOOGLE_CREDENTIALS` | `$GOOGLE_APPLICATION_CREDENTIALS`のコンテンツ | Google CloudサービスアカウントJSONファイルのコンテンツ | +| `LOG_LEVEL` | `info` | `openshift-install`出力の詳細度 | +| `INSTALL_DIR` | `install-$CLUSTER_NAME` | 複数のクラスターの起動に役立つ、インストールアセットのディレクトリ | + +## 次のステップ {#next-steps} + +クラスターが起動して実行されたら、[GitLabのインストール](https://docs.gitlab.com/operator/)を続行できます。 + +## リソース {#resources} + +- [`openshift-installer`のソースコード](https://github.com/openshift/installer) +- [`oc`のソースコード](https://github.com/openshift/oc) +- [`openshift-installer`および`oc`パッケージ](https://mirror.openshift.com/pub/openshift-v4/clients/ocp/) +- [OpenShift Container Project (OCP) アーキテクチャドキュメント](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.9/html/architecture/architecture) +- [OpenShift GCPドキュメント](https://docs.openshift.com/container-platform/4.9/installing/installing_gcp/installing-gcp-account.html) +- [OpenShiftトラブルシューティングガイド](https://docs.openshift.com/container-platform/4.9/support/troubleshooting/troubleshooting-installations.html) diff --git a/doc-locale/ja-jp/installation/command-line-options.md b/doc-locale/ja-jp/installation/command-line-options.md new file mode 100644 index 0000000000..13a76ed284 --- /dev/null +++ b/doc-locale/ja-jp/installation/command-line-options.md @@ -0,0 +1,482 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャートのデプロイオプション +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +このページには、一般的に使用されるGitLabチャートの値がリストされています。利用可能なオプションの完全なリストについては、各サブチャートのドキュメントを参照してください。 + +YAMLファイルと`--values `フラグを使用するか、複数の`--set`フラグを使用して、`helm install`コマンドに値を渡すことができます。リリースに必要なオーバーライドのみを含む値ファイルを使用することをお勧めします。 + +デフォルトの`values.yaml`ファイルのソースは、[こちら](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/values.yaml)にあります。これらの内容はリリースによって異なりますが、Helm自体を使用して、バージョンごとにこれらを取得できます。 + +```shell +helm inspect values gitlab/gitlab +``` + +## 基本設定 {#basic-configuration} + +| パラメータ | デフォルト | 説明 | +|------------------------------------------------------|-----------------------------------------------|-------------| +| `gitlab.migrations.initialRootPassword.key` | `password` | 移行シークレット内のルートアカウントパスワードを指すキー | +| `gitlab.migrations.initialRootPassword.secret` | `{Release.Name}-gitlab-initial-root-password` | ルートアカウントパスワードを含むシークレットのグローバル名 | +| `global.gitlab.license.key` | `license` | ライセンスシークレット内のEnterpriseライセンスを指すキー | +| `global.gitlab.license.secret` | _なし_ | Enterpriseライセンスを含むシークレットのグローバル名 | +| `global.application.create` | `false` | GitLabの[アプリケーションリソース](https://github.com/kubernetes-sigs/application)を作成します | +| `global.edition` | `ee` | インストールするGitLabのエディション。Enterprise Edition（`ee`）またはCommunity Edition（`ce`） | +| `global.gitaly.enabled` | `true` | Gitaly有効フラグ | +| `global.hosts.domain` | 必須 | 公開されているすべてのサービスに使用されるドメイン名 | +| `global.hosts.externalIP` | 必須 | NGINX Ingressコントローラーに割り当てる静的IP | +| `global.hosts.ssh` | `gitlab.{global.hosts.domain}` | Git SSHアクセスに使用されるドメイン名 | +| `global.imagePullPolicy` | `IfNotPresent` | 非推奨:`global.image.pullPolicy`の代わりに使用してください | +| `global.image.pullPolicy` | _なし_ (デフォルトの動作は`IfNotPresent`です) | すべてのチャートのデフォルトのimagePullPolicyを設定します | +| `global.image.pullSecrets` | _なし_ | すべてのチャートのデフォルトのimagePullSecretsを設定します（`name`と値のペアのリストを使用） | +| `global.minio.enabled` | `true` | MinIO有効フラグ | +| `global.psql.host` | _インクラスターの非本番環境PostgreSQLを使用_ | 外部psqlのグローバルホスト名、サブチャートのpsql設定をオーバーライドします | +| `global.psql.password.key` | _インクラスターの非本番環境PostgreSQLを使用_ | psqlシークレット内のpsqlパスワードを指すキー | +| `global.psql.password.secret` | _インクラスターの非本番環境PostgreSQLを使用_ | psqlパスワードを含むシークレットのグローバル名 | +| `global.registry.bucket` | `registry` | レジストリバケット名 | +| `global.service.annotations` | `{}` | すべての`Service`に追加するアノテーション | +| `global.rails.sessionStore.sessionCookieTokenPrefix` | `""` | 生成されたセッションCookieのプレフィックス | +| `global.deployment.annotations` | `{}` | すべての`Deployment`に追加するアノテーション | +| `global.time_zone` | UTC | グローバルタイムゾーン | + +## TLS設定 {#tls-configuration} + +| パラメータ | デフォルト | 説明 | +|-----------------------------------------------------|---------|-------------| +| `certmanager-issuer.email` | `false` | Let's Encryptアカウントのメール | +| `gitlab.webservice.ingress.tls.secretName` | _なし_ | GitLabのTLS証明書とキーを含む既存の`Secret` | +| `gitlab.webservice.ingress.tls.smartcardSecretName` | _なし_ | GitLabスマートカード認証ドメインのTLS証明書とキーを含む既存の`Secret` | +| `global.hosts.https` | `true` | https経由で提供 | +| `global.ingress.configureCertmanager` | `true` | Let's Encryptから証明書を取得するようにcert-managerを設定します | +| `global.ingress.tls.secretName` | _なし_ | ワイルドカードTLS証明書とキーを含む既存の`Secret` | +| `minio.ingress.tls.secretName` | _なし_ | MinIOのTLS証明書とキーを含む既存の`Secret` | +| `registry.ingress.tls.secretName` | _なし_ | レジストリのTLS証明書とキーを含む既存の`Secret` | + +## 送信メールの設定 {#outgoing-email-configuration} + +| パラメータ | デフォルト | 説明 | +|-----------------------------------|-----------------------|-------------| +| `global.email.display_name` | `GitLab` | GitLabからのメールの送信者として表示される名前 | +| `global.email.from` | `gitlab@example.com` | GitLabからのメールの送信者として表示されるメールアドレス | +| `global.email.reply_to` | `noreply@example.com` | GitLabからのメールにリストされている返信先メール | +| `global.email.smime.certName` | `tls.crt` | S/MIME証明書ファイルの場所を特定するためのシークレットオブジェクトキー値 | +| `global.email.smime.enabled` | `false` | 送信メールにS/MIME署名を追加します | +| `global.email.smime.keyName` | `tls.key` | S/MIMEキーファイルの場所を特定するためのシークレットオブジェクトキー値 | +| `global.email.smime.secretName` | `""` | X.509証明書を検索するKubernetesシークレットオブジェクト（作成用の[S/MIME証明書](secrets.md#smime-certificate)） | +| `global.email.subject_suffix` | `""` | GitLabからのすべての送信メールの件名のサフィックス | +| `global.smtp.address` | `smtp.mailgun.org` | リモートメールサーバーのホスト名またはIP | +| `global.smtp.authentication` | `plain` | SMTP認証のタイプ（「plain」、「login」、「cram_md5」、または認証なしの場合は「」） | +| `global.smtp.domain` | `""` | SMTPのオプションのHELOドメイン | +| `global.smtp.enabled` | `false` | 送信メールを有効にする | +| `global.smtp.openssl_verify_mode` | `peer` | TLS検証モード（「none」、「peer」、「client_once」、または「fail_if_no_peer_cert」） | +| `global.smtp.password.key` | `password` | `global.smtp.password.secret`内のSMTPパスワードを含むキー | +| `global.smtp.password.secret` | `""` | SMTPパスワードを含む`Secret`の名前 | +| `global.smtp.port` | `2525` | SMTPのポート | +| `global.smtp.starttls_auto` | `false` | メールサーバーで有効になっている場合は、STARTTLSを使用します | +| `global.smtp.tls` | _なし_ | SMTP/TLSを有効にします（SMTPS:ダイレクトTLS接続経由のSMTP) | +| `global.smtp.user_name` | `""` | SMTP認証httpsのユーザー名 | +| `global.smtp.open_timeout` | `30` | 接続を試行中に待機する秒数。 | +| `global.smtp.read_timeout` | `60` | 1つのブロックの読み取り中に待機する秒数。 | +| `global.smtp.pool` | `false` | SMTP接続プーリングを有効にします | + +### Microsoft Graph Mailerの設定 {#microsoft-graph-mailer-settings} + +| パラメータ | デフォルト | 説明 | +|----------------------------------------------------------------|-------------------------------------|-------------| +| `global.appConfig.microsoft_graph_mailer.enabled` | `false` | Microsoft Graph API経由で送信メールを有効にする | +| `global.appConfig.microsoft_graph_mailer.user_id` | `""` | Microsoft Graph APIを使用するユーザーの一意の識別子 | +| `global.appConfig.microsoft_graph_mailer.tenant` | `""` | アプリケーションが動作を計画しているディレクトリテナント（GUIDまたはドメイン名形式） | +| `global.appConfig.microsoft_graph_mailer.client_id` | `""` | アプリに割り当てられているアプリケーションID。この情報は、アプリを登録したポータルにあります | +| `global.appConfig.microsoft_graph_mailer.client_secret.key` | `secret` | アプリ登録ポータルでアプリ用に生成したクライアントシークレットを含む`global.appConfig.microsoft_graph_mailer.client_secret.secret`内のキー | +| `global.appConfig.microsoft_graph_mailer.client_secret.secret` | `""` | アプリ登録ポータルでアプリ用に生成したクライアントシークレットを含む`Secret`の名前 | +| `global.appConfig.microsoft_graph_mailer.azure_ad_endpoint` | `https://login.microsoftonline.com` | Azure Active DirectoryエンドポイントのURL | +| `global.appConfig.microsoft_graph_mailer.graph_endpoint` | `https://graph.microsoft.com` | Microsoft GraphエンドポイントのURL | + +## 受信メールの設定 {#incoming-email-configuration} + +### 共通設定 {#common-settings} + +詳細については、[受信メール設定の例のドキュメント](https://docs.gitlab.com/administration/incoming_email/#configuration-examples)を参照してください。 + +| パラメータ | デフォルト | 説明 | +|------------------------------------------------------|--------------------------------------------|-------------| +| `global.appConfig.incomingEmail.address` | 空 | 返信されるアイテムを参照するメールアドレス（例：`gitlab-incoming+%{key}@gmail.com`）。`+%{key}`サフィックスは、メールアドレス全体に含める必要があり、別の値に置き換えないでください。 | +| `global.appConfig.incomingEmail.enabled` | `false` | 受信メールを有効にする | +| `global.appConfig.incomingEmail.deleteAfterDelivery` | `true` | メッセージを削除済みとしてマークするかどうか。IMAPの場合、削除済みとしてマークされたメッセージは、`expungedDeleted`が`true`に設定されている場合に消滅します。Microsoft Graphの場合、削除されたメッセージはしばらくすると自動的に消滅するため、インボックスにメッセージを保持するには、これをfalseに設定します。 | +| `global.appConfig.incomingEmail.expungeDeleted` | `false` | 配信後に削除済みとしてマークされたメッセージをメールボックスから消去（完全に削除）するかどうか。Microsoft Graphが削除されたメッセージを自動的に消去するため、IMAPにのみ関連します。 | +| `global.appConfig.incomingEmail.logger.logPath` | `/dev/stdout` | JSON構造化されたログを書き込むパス。このログの生成を無効にするには、「」に設定します | +| `global.appConfig.incomingEmail.inboxMethod` | `imap` | IMAP（`imap`）またはOAuth2を使用したMicrosoft Graph API（`microsoft_graph`）でメールを読み取ります | +| `global.appConfig.incomingEmail.deliveryMethod` | `webhook` | Mailroomがメールコンテンツを処理のためにRailsアプリに送信する方法。`sidekiq`または`webhook`のいずれか | +| `gitlab.appConfig.incomingEmail.authToken.key` | `authToken` | 受信メールシークレット内の受信メールトークンへのキー。配信方法がWebhookの場合に有効です。 | +| `gitlab.appConfig.incomingEmail.authToken.secret` | `{Release.Name}-incoming-email-auth-token` | 受信メール認証シークレット。配信方法がWebhookの場合に有効です。 | + +### IMAP設定 {#imap-settings} + +| パラメータ | デフォルト | 説明 | +|--------------------------------------------------|------------|-------------| +| `global.appConfig.incomingEmail.host` | 空 | IMAPのホスト | +| `global.appConfig.incomingEmail.idleTimeout` | `60` | IDLEコマンドのタイムアウト | +| `global.appConfig.incomingEmail.mailbox` | `inbox` | 受信メールの最終的な送信先となるメールボックス。 | +| `global.appConfig.incomingEmail.password.key` | `password` | `global.appConfig.incomingEmail.password.secret`内のIMAPパスワードを含むキー | +| `global.appConfig.incomingEmail.password.secret` | 空 | IMAPパスワードを含む`Secret`の名前 | +| `global.appConfig.incomingEmail.port` | `993` | IMAPのポート | +| `global.appConfig.incomingEmail.ssl` | `true` | IMAPサーバーがSSLを使用するかどうか | +| `global.appConfig.incomingEmail.startTls` | `false` | IMAPサーバーがStartTLSを使用するかどうか | +| `global.appConfig.incomingEmail.user` | 空 | IMAP認証のユーザー名 | + +### Microsoft Graphの設定 {#microsoft-graph-settings} + +| パラメータ | デフォルト | 説明 | +|------------------------------------------------------|---------|-------------| +| `global.appConfig.incomingEmail.tenantId` | 空 | Microsoft Azure Active DirectoryのテナントID | +| `global.appConfig.incomingEmail.clientId` | 空 | OAuth2アプリのクライアントID | +| `global.appConfig.incomingEmail.clientSecret.key` | 空 | OAuth2クライアントシークレットを含む`appConfig.incomingEmail.clientSecret.secret`内のキー | +| `global.appConfig.incomingEmail.clientSecret.secret` | シークレット | OAuth2クライアントシークレットを含む`Secret`の名前 | +| `global.appConfig.incomingEmail.pollInterval` | `60` | 新しいメールのポーリング頻度（秒単位） | +| `global.appConfig.incomingEmail.azureAdEndpoint` | 空 | Azure Active DirectoryエンドポイントのURL（例：`https://login.microsoftonline.com`） | +| `global.appConfig.incomingEmail.graphEndpoint` | 空 | Microsoft GraphエンドポイントのURL（例：`https://graph.microsoft.com`） | + +[シークレットの作成手順](secrets.md)を参照してください。 + +## サービスデスクのメール設定 {#service-desk-email-configuration} + +サービスデスクの要件として、受信メールを[設定](#incoming-email-configuration)する必要があります。受信メールとサービスデスクの両方のメールアドレスで、[メールサブアドレス](https://docs.gitlab.com/administration/incoming_email/#email-sub-addressing)を使用する必要があることに注意してください。各セクションでメールアドレスを設定する場合、ユーザー名に追加されるtagは`+%{key}`である必要があります。 + +### 共通設定 {#common-settings-1} + +| パラメータ | デフォルト | 説明 | +|---------------------------------------------------------|------------------------------------------------|-------------| +| `global.appConfig.serviceDeskEmail.address` | 空 | 返信されるアイテムを参照するメールアドレス（例：`project_contact+%{key}@gmail.com`） | +| `global.appConfig.serviceDeskEmail.enabled` | `false` | サービスデスクのメールを有効にする | +| `global.appConfig.serviceDeskEmail.deleteAfterDelivery` | `true` | メッセージを削除済みとしてマークするかどうか。IMAPの場合、削除済みとしてマークされたメッセージは、`expungedDeleted`が`true`に設定されている場合に消滅します。Microsoft Graphの場合、削除されたメッセージはしばらくすると自動的に消滅するため、インボックスにメッセージを保持するには、これをfalseに設定します。 | +| `global.appConfig.serviceDeskEmail.expungeDeleted` | `false` | 配信後に削除済みとしてマークされたメッセージをメールボックスから消去（完全に削除）するかどうか。Microsoft Graphが削除されたメッセージを自動的に消去するため、IMAPにのみ関連します。 | +| `global.appConfig.serviceDeskEmail.logger.logPath` | `/dev/stdout` | JSON構造化されたログを書き込むパス。このログの生成を無効にするには、「」に設定します | +| `global.appConfig.serviceDeskEmail.inboxMethod` | `imap` | IMAP（`imap`）またはOAuth2を使用したMicrosoft Graph API（`microsoft_graph`）でメールを読み取ります | +| `global.appConfig.serviceDeskEmail.deliveryMethod` | `webhook` | Mailroomがメールコンテンツを処理のためにRailsアプリに送信する方法。`sidekiq`または`webhook`のいずれか | +| `gitlab.appConfig.serviceDeskEmail.authToken.key` | `authToken` | サービスデスクのメールシークレット内のサービスデスクのメールトークンへのキー。配信方法がWebhookの場合に有効です。 | +| `gitlab.appConfig.serviceDeskEmail.authToken.secret` | `{Release.Name}-service-desk-email-auth-token` | サービスデスクメール認証シークレット。配信方法がWebhookの場合に有効です。 | + +### IMAP設定 {#imap-settings-1} + +| パラメータ | デフォルト | 説明 | +|-----------------------------------------------------|------------|-------------| +| `global.appConfig.serviceDeskEmail.host` | 空 | IMAPのホスト | +| `global.appConfig.serviceDeskEmail.idleTimeout` | `60` | IDLEコマンドのタイムアウト | +| `global.appConfig.serviceDeskEmail.mailbox` | `inbox` | サービスデスクメールの最終的な送信先となるメールボックス。 | +| `global.appConfig.serviceDeskEmail.password.key` | `password` | `global.appConfig.serviceDeskEmail.password.secret`内のIMAPパスワードを含むキー | +| `global.appConfig.serviceDeskEmail.password.secret` | 空 | IMAPパスワードを含む`Secret`の名前 | +| `global.appConfig.serviceDeskEmail.port` | `993` | IMAPのポート | +| `global.appConfig.serviceDeskEmail.ssl` | `true` | IMAPサーバーがSSLを使用するかどうか | +| `global.appConfig.serviceDeskEmail.startTls` | `false` | IMAPサーバーがStartTLSを使用するかどうか | +| `global.appConfig.serviceDeskEmail.user` | 空 | IMAP認証のユーザー名 | + +### Microsoft Graphの設定 {#microsoft-graph-settings-1} + +| パラメータ | デフォルト | 説明 | +|---------------------------------------------------------|---------|-------------| +| `global.appConfig.serviceDeskEmail.tenantId` | 空 | Microsoft Azure Active DirectoryのテナントID | +| `global.appConfig.serviceDeskEmail.clientId` | 空 | OAuth2アプリのクライアントID | +| `global.appConfig.serviceDeskEmail.clientSecret.key` | 空 | OAuth2クライアントシークレットを含む`appConfig.serviceDeskEmail.clientSecret.secret`内のキー | +| `global.appConfig.serviceDeskEmail.clientSecret.secret` | シークレット | OAuth2クライアントシークレットを含む`Secret`の名前 | +| `global.appConfig.serviceDeskEmail.pollInterval` | `60` | 新しいメールのポーリング頻度（秒単位） | +| `global.appConfig.serviceDeskEmail.azureAdEndpoint` | 空 | Azure Active DirectoryエンドポイントのURL（例：`https://login.microsoftonline.com`） | +| `global.appConfig.serviceDeskEmail.graphEndpoint` | 空 | Microsoft GraphエンドポイントのURL（例：`https://graph.microsoft.com`） | + +[シークレットの作成手順](secrets.md)を参照してください。 + +## デフォルトのプロジェクトの機能の設定 {#default-project-features-configuration} + +| パラメータ | デフォルト | 説明 | +|--------------------------------------------------------------|---------|-------------| +| `global.appConfig.defaultProjectsFeatures.builds` | `true` | プロジェクトのビルドを有効にする | +| `global.appConfig.defaultProjectsFeatures.containerRegistry` | `true` | コンテナレジストリプロジェクトの機能を有効にする | +| `global.appConfig.defaultProjectsFeatures.issues` | `true` | プロジェクトイシューを有効にする | +| `global.appConfig.defaultProjectsFeatures.mergeRequests` | `true` | プロジェクトマージリクエストを有効にする | +| `global.appConfig.defaultProjectsFeatures.snippets` | `true` | プロジェクトスニペットを有効にする | +| `global.appConfig.defaultProjectsFeatures.wiki` | `true` | プロジェクトWikiを有効にする | + +## GitLab Shell {#gitlab-shell} + +| パラメータ | デフォルト | 説明 | +|----------------------------------|---------|-------------| +| `global.shell.authToken` | | 共有シークレットを含むシークレット | +| `global.shell.hostKeys` | | SSHホストキーを含むシークレット | +| `global.shell.port` | | SSHのIngressで公開するポート番号 | +| `global.shell.tcp.proxyProtocol` | `false` | SSH IngressでProxyProtocolを有効にする | + +## RBAC設定 {#rbac-settings} + +| パラメータ | デフォルト | 説明 | +|----------------------------------------|---------|-------------| +| `certmanager.rbac.create` | `true` | RBACリソースを作成して使用する | +| `gitlab-runner.rbac.create` | `true` | RBACリソースを作成して使用する | +| `nginx-ingress.rbac.create` | `false` | デフォルトのRBACリソースを作成して使用する | +| `nginx-ingress.rbac.createClusterRole` | `false` | クラスターロールを作成して使用する | +| `nginx-ingress.rbac.createRole` | `true` | 名前空間ロールを作成して使用する | +| `prometheus.rbac.create` | `true` | RBACリソースを作成して使用する | + +`nginx-ingress.rbac.create`を`false`に設定してRBACルールを自分で構成する場合、[チャートバージョンに応じて](../releases/8_0.md#upgrade-to-86x-851-843-836)特定のRBACルールを追加する必要がある場合があります。 + +## 高度なNGINX Ingressの設定 {#advanced-nginx-ingress-configuration} + +NGINX Ingressの値を`nginx-ingress`でプレフィックスします。たとえば、`nginx-ingress.controller.image.tag`を使用してコントローラーイメージのtagを設定します。 + +[`nginx-ingress`チャート](../charts/nginx/_index.md)を参照してください。 + +## 高度なインクラスターRedisの設定 {#advanced-in-cluster-redis-configuration} + +| パラメータ | デフォルト | 説明 | +|---------------------------|-----------------------|-------------| +| `redis.install` | `true` | `bitnami/redis`チャートをインストールします | +| `redis.existingSecret` | `gitlab-redis-secret` | Redisサーバーで使用するシークレットを指定します | +| `redis.existingSecretKey` | `redis-password` | パスワードが保存されているシークレットキー | + +Redisサービスの追加設定では、[Redisチャート](https://github.com/bitnami/charts/tree/main/bitnami/redis)の設定を使用してください。 + +## 高度なレジストリ設定 {#advanced-registry-configuration} + +| パラメータ | デフォルト | 説明 | +|-----------------------------------------------------|---------------------------------------------|-------------| +| `registry.authEndpoint` | デフォルトでは未定義 | 認証エンドポイント | +| `registry.enabled` | `true` | Dockerレジストリを有効にする | +| `registry.httpSecret` | | Httpsシークレット | +| `registry.minio.bucket` | `registry` | MinIOレジストリバケット名 | +| `registry.service.annotations` | `{}` | `Service`に追加する注釈 | +| `registry.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `registry.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `registry.tokenIssuer` | `gitlab-issuer` | JWTトークン発行者 | +| `registry.tokenService` | `container_registry` | JWTトークンサービス | +| `registry.profiling.stackdriver.enabled` | `false` | Stackdriverを使用した継続的なプロファイリングを有効にする | +| `registry.profiling.stackdriver.credentials.secret` | `gitlab-registry-profiling-creds` | 認証情報を含むシークレットの名前 | +| `registry.profiling.stackdriver.credentials.key` | `credentials` | 認証情報の保存先のシークレットキー | +| `registry.profiling.stackdriver.service` | `RELEASE-registry`（テンプレート化されたサービス名） | プロファイルの記録先のStackdriverサービスの名前 | +| `registry.profiling.stackdriver.projectid` | 実行中のGCPプロジェクト | プロファイルのレポート先のGCPプロジェクト | + +## 高度なMinIO設定 {#advanced-minio-configuration} + +| パラメータ | デフォルト | 説明 | +|--------------------------------------|--------------------------------|-------------| +| `minio.defaultBuckets` | `[{"name": "registry"}]` | MinIOのデフォルトバケット | +| `minio.image` | `minio/minio` | MinIOイメージ | +| `minio.imagePullPolicy` | | MinIOイメージのプルポリシー | +| `minio.imageTag` | `RELEASE.2017-12-28T01-21-00Z` | MinIOイメージtag | +| `minio.minioConfig.browser` | `on` | MinIOブラウザーフラグ | +| `minio.minioConfig.domain` | | MinIOドメイン | +| `minio.minioConfig.region` | `us-east-1` | MinIOリージョン | +| `minio.mountPath` | `/export` | MinIO設定ファイルのmountパス | +| `minio.persistence.accessMode` | `ReadWriteOnce` | MinIOの永続アクセスモード | +| `minio.persistence.enabled` | `true` | MinIOの永続フラグを有効にする | +| `minio.persistence.matchExpressions` | | バインドするMinIOラベル式の一致 | +| `minio.persistence.matchLabels` | | バインドするMinIOラベル値の一致 | +| `minio.persistence.size` | `10Gi` | MinIOの永続ボリュームサイズ | +| `minio.persistence.storageClass` | | プロビジョニング用のMinIO storageClassName | +| `minio.persistence.subPath` | | MinIOの永続ボリュームのmountパス | +| `minio.persistence.volumeName` | | MinIOの既存の永続ボリューム名 | +| `minio.resources.requests.cpu` | `250m` | リクエストされたMinIOの最小CPU | +| `minio.resources.requests.memory` | `256Mi` | リクエストされたMinIOの最小メモリ | +| `minio.service.annotations` | `{}` | `Service`に追加する注釈 | +| `minio.servicePort` | `9000` | MinIOサービスポート | +| `minio.serviceType` | `ClusterIP` | MinIOサービスタイプ | + +## 高度なGitLab設定 {#advanced-gitlab-configuration} + +| パラメータ | デフォルト | 説明 | +|------------------------------------------------------------|-----------------------------------------------------------------|-------------| +| `gitlab-runner.checkInterval` | `30s` | ポーリングの間隔 | +| `gitlab-runner.concurrent` | `20` | 同時ジョブ数 | +| `gitlab-runner.imagePullPolicy` | `IfNotPresent` | イメージのプルポリシー | +| `gitlab-runner.image` | `gitlab/gitlab-runner:alpine-v10.5.0` | runnerイメージ | +| `gitlab-runner.gitlabUrl` | GitLabの外部URL | RunnerがGitLabサーバーに登録するために使用するURL | +| `gitlab-runner.install` | `true` | `gitlab-runner`チャートをインストールする | +| `gitlab-runner.rbac.clusterWideAccess` | `false` | ジョブのコンテナをクラスター全体にデプロイする | +| `gitlab-runner.rbac.create` | `true` | RBACサービスアカウントを作成するかどうか | +| `gitlab-runner.rbac.serviceAccountName` | `default` | 作成するRBACサービスアカウントの名前 | +| `gitlab-runner.resources.limits.cpu` | | runnerリソース | +| `gitlab-runner.resources.limits.memory` | | runnerリソース | +| `gitlab-runner.resources.requests.cpu` | | runnerリソース | +| `gitlab-runner.resources.requests.memory` | | runnerリソース | +| `gitlab-runner.runners.privileged` | `false` | 特権モードで実行する（`dind`に必要） | +| `gitlab-runner.runners.cache.secretName` | `gitlab-minio` | `accesskey`と`secretkey`を取得するためのシークレット | +| `gitlab-runner.runners.config` | [チャートのドキュメント](../charts/gitlab/gitlab-runner/_index.md#default-runner-configuration)を参照してください | 文字列としてのRunnerの設定 | +| `gitlab-runner.unregisterRunners` | `true` | チャートのインストール時に、ローカルの`config.toml`にあるすべてのrunnerを登録解除します。トークンのプレフィックスが`glrt-`の場合、runnerではなく、Runnerマネージャーが削除されます。Runnerマネージャーは、runnerと`config.toml`を含むマシンによって識別されます。Runnerが登録トークンで登録された場合、runnerは削除されます。 | +| `gitlab.geo-logcursor.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.geo-logcursor.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.gitaly.authToken.key` | `token` | シークレット内のGitalyトークンのキー | +| `gitlab.gitaly.authToken.secret` | `{.Release.Name}-gitaly-secret` | Gitalyシークレット名 | +| `gitlab.gitaly.image.pullPolicy` | | Gitalyイメージのプルポリシー | +| `gitlab.gitaly.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitaly` | Gitalyイメージリポジトリ | +| `gitlab.gitaly.image.tag` | `master` | Gitalyイメージtag | +| `gitlab.gitaly.persistence.accessMode` | `ReadWriteOnce` | Gitalyの永続アクセスモード | +| `gitlab.gitaly.persistence.enabled` | `true` | Gitalyの永続フラグを有効にする | +| `gitlab.gitaly.persistence.matchExpressions` | | バインドするラベル式の一致 | +| `gitlab.gitaly.persistence.matchLabels` | | バインドするラベル値の一致 | +| `gitlab.gitaly.persistence.size` | `50Gi` | Gitalyの永続ボリュームサイズ | +| `gitlab.gitaly.persistence.storageClass` | | プロビジョニング用のstorageClassName | +| `gitlab.gitaly.persistence.subPath` | | Gitalyの永続ボリュームのmountパス | +| `gitlab.gitaly.persistence.volumeName` | | 既存の永続ボリューム名 | +| `gitlab.gitaly.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.gitaly.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.gitaly.service.annotations` | `{}` | `Service`に追加する注釈 | +| `gitlab.gitaly.service.externalPort` | `8075` | Gitalyサービス公開ポート | +| `gitlab.gitaly.service.internalPort` | `8075` | Gitaly内部ポート | +| `gitlab.gitaly.service.name` | `gitaly` | Gitalyサービス名 | +| `gitlab.gitaly.service.type` | `ClusterIP` | Gitalyサービスタイプ | +| `gitlab.gitaly.serviceName` | `gitaly` | Gitalyサービス名 | +| `gitlab.gitaly.shell.authToken.key` | `secret` | Shellキー | +| `gitlab.gitaly.shell.authToken.secret` | `{Release.Name}-gitlab-shell-secret` | Shellシークレット | +| `gitlab.gitlab-exporter.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.gitlab-exporter.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.gitlab-shell.authToken.key` | `secret` | Shell認証シークレットキー | +| `gitlab.gitlab-shell.authToken.secret` | `{Release.Name}-gitlab-shell-secret` | Shell認証シークレット | +| `gitlab.gitlab-shell.enabled` | `true` | Shellの有効フラグ | +| `gitlab.gitlab-shell.image.pullPolicy` | | Shellイメージのプルポリシー | +| `gitlab.gitlab-shell.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-shell` | Shellイメージリポジトリ | +| `gitlab.gitlab-shell.image.tag` | `master` | Shellイメージtag | +| `gitlab.gitlab-shell.replicaCount` | `1` | Shellレプリカ | +| `gitlab.gitlab-shell.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.gitlab-shell.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.gitlab-shell.service.annotations` | `{}` | `Service`に追加する注釈 | +| `gitlab.gitlab-shell.service.internalPort` | `2222` | Shell内部ポート | +| `gitlab.gitlab-shell.service.name` | `gitlab-shell` | Shellサービス名 | +| `gitlab.gitlab-shell.service.type` | `ClusterIP` | Shellサービスタイプ | +| `gitlab.gitlab-shell.webservice.serviceName` | `global.webservice.serviceName`から継承 | Webserviceサービス名 | +| `gitlab.mailroom.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.mailroom.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.migrations.bootsnap.enabled` | `true` | 移行Bootsnapの有効フラグ | +| `gitlab.migrations.enabled` | `true` | 移行の有効フラグ | +| `gitlab.migrations.image.pullPolicy` | | 移行のプルポリシー | +| `gitlab.migrations.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ee` | 移行イメージリポジトリ | +| `gitlab.migrations.image.tag` | `master` | 移行イメージtag | +| `gitlab.migrations.psql.password.key` | `psql-password` | psqlシークレット内のpsqlパスワードへのキー | +| `gitlab.migrations.psql.password.secret` | `gitlab-postgres` | psqlシークレット | +| `gitlab.migrations.psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`より優先されます | +| `gitlab.migrations.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.migrations.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.sidekiq.concurrency` | `20` | Sidekiqのデフォルトの並行処理 | +| `gitlab.sidekiq.enabled` | `true` | Sidekiqの有効フラグ | +| `gitlab.sidekiq.gitaly.authToken.key` | `token` | Gitalyシークレット内のGitalyトークンへのキー | +| `gitlab.sidekiq.gitaly.authToken.secret` | `{.Release.Name}-gitaly-secret` | Gitalyシークレット | +| `gitlab.sidekiq.gitaly.serviceName` | `gitaly` | Gitalyサービス名 | +| `gitlab.sidekiq.image.pullPolicy` | | Sidekiqイメージのプルポリシー | +| `gitlab.sidekiq.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-sidekiq-ee` | Sidekiqイメージリポジトリ | +| `gitlab.sidekiq.image.tag` | `master` | Sidekiqイメージtag | +| `gitlab.sidekiq.psql.password.key` | `psql-password` | psqlシークレット内のpsqlパスワードへのキー | +| `gitlab.sidekiq.psql.password.secret` | `gitlab-postgres` | psqlパスワードシークレット | +| `gitlab.sidekiq.psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`より優先されます | +| `gitlab.sidekiq.replicas` | `1` | Sidekiqレプリカ | +| `gitlab.sidekiq.resources.requests.cpu` | `100m` | Sidekiqに必要な最小CPU | +| `gitlab.sidekiq.resources.requests.memory` | `600M` | Sidekiqに必要な最小メモリ | +| `gitlab.sidekiq.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.sidekiq.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.sidekiq.timeout` | `5` | Sidekiqジョブのタイムアウト | +| `gitlab.toolbox.annotations` | `{}` | ツールボックスに追加する注釈 | +| `gitlab.toolbox.backups.cron.enabled` | `false` | バックアップCronJobの有効フラグ | +| `gitlab.toolbox.backups.cron.extraArgs` | | バックアップユーティリティに渡す引数の文字列 | +| `gitlab.toolbox.backups.cron.persistence.accessMode` | `ReadWriteOnce` | バックアップcronの永続アクセスモード | +| `gitlab.toolbox.backups.cron.persistence.enabled` | `false` | バックアップcronの永続フラグを有効にする | +| `gitlab.toolbox.backups.cron.persistence.matchExpressions` | | バインドするラベル式の一致 | +| `gitlab.toolbox.backups.cron.persistence.matchLabels` | | バインドするラベル値の一致 | +| `gitlab.toolbox.backups.cron.persistence.size` | `10Gi` | バックアップcronの永続ボリュームサイズ | +| `gitlab.toolbox.backups.cron.persistence.storageClass` | | プロビジョニング用のstorageClassName | +| `gitlab.toolbox.backups.cron.persistence.subPath` | | バックアップcronの永続ボリュームのmountパス | +| `gitlab.toolbox.backups.cron.persistence.volumeName` | | 既存の永続ボリューム名 | +| `gitlab.toolbox.backups.cron.resources.requests.cpu` | `50m` | バックアップcronに必要な最小CPU | +| `gitlab.toolbox.backups.cron.resources.requests.memory` | `350M` | バックアップcronに必要な最小メモリ | +| `gitlab.toolbox.backups.cron.schedule` | `0 1 * * *` | Cronスタイルのスケジュール文字列 | +| `gitlab.toolbox.backups.objectStorage.backend` | `s3` | 使用するオブジェクトストレージプロバイダー（`s3`、`gcs`、または`azure`） | +| `gitlab.toolbox.backups.objectStorage.config.gcpProject` | `""` | バックエンドが`gcs`の場合に使用するGCPプロジェクト | +| `gitlab.toolbox.backups.objectStorage.config.key` | `""` | シークレット内の認証情報を含むキー | +| `gitlab.toolbox.backups.objectStorage.config.secret` | `""` | オブジェクトストレージの認証情報シークレット | +| `gitlab.toolbox.backups.objectStorage.config` | `{}` | オブジェクトストレージの認証情報 | +| `gitlab.toolbox.bootsnap.enabled` | `true` | ツールボックスでBootsnapキャッシュを有効にする | +| `gitlab.toolbox.enabled` | `true` | ツールボックスの有効フラグ | +| `gitlab.toolbox.image.pullPolicy` | `IfNotPresent` | ツールボックスイメージのプルポリシー | +| `gitlab.toolbox.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-toolbox-ee` | ツールボックスイメージリポジトリ | +| `gitlab.toolbox.image.tag` | `master` | ツールボックスイメージtag | +| `gitlab.toolbox.init.image.repository` | | ツールボックス初期化イメージリポジトリ | +| `gitlab.toolbox.init.image.tag` | | ツールボックス初期化イメージtag | +| `gitlab.toolbox.init.resources.requests.cpu` | `50m` | ツールボックスの初期化に必要な最小CPU | +| `gitlab.toolbox.persistence.accessMode` | `ReadWriteOnce` | ツールボックスの永続アクセスモード | +| `gitlab.toolbox.persistence.enabled` | `false` | ツールボックスの永続フラグを有効にする | +| `gitlab.toolbox.persistence.matchExpressions` | | バインドするラベル式の一致 | +| `gitlab.toolbox.persistence.matchLabels` | | バインドするラベル値の一致 | +| `gitlab.toolbox.persistence.size` | `10Gi` | ツールボックスの永続ボリュームサイズ | +| `gitlab.toolbox.persistence.storageClass` | | プロビジョニング用のstorageClassName | +| `gitlab.toolbox.persistence.subPath` | | ツールボックスの永続ボリュームのmountパス | +| `gitlab.toolbox.persistence.volumeName` | | 既存の永続ボリューム名 | +| `gitlab.toolbox.psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`より優先されます | +| `gitlab.toolbox.resources.requests.cpu` | `50m` | ツールボックスに必要な最小CPU | +| `gitlab.toolbox.resources.requests.memory` | `350M` | ツールボックスに必要な最小メモリ | +| `gitlab.toolbox.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.toolbox.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.webservice.enabled` | `true` | webserviceの有効フラグ | +| `gitlab.webservice.gitaly.authToken.key` | `token` | Gitalyシークレット内のGitalyトークンへのキー | +| `gitlab.webservice.gitaly.authToken.secret` | `{.Release.Name}-gitaly-secret` | Gitalyシークレット名 | +| `gitlab.webservice.gitaly.serviceName` | `gitaly` | Gitalyサービス名 | +| `gitlab.webservice.image.pullPolicy` | | webserviceイメージのプルポリシー | +| `gitlab.webservice.image.repository` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-webservice-ee` | webserviceイメージリポジトリ | +| `gitlab.webservice.image.tag` | `master` | webserviceイメージtag | +| `gitlab.webservice.psql.password.key` | `psql-password` | psqlシークレット内のpsqlパスワードへのキー | +| `gitlab.webservice.psql.password.secret` | `gitlab-postgres` | psqlシークレット名 | +| `gitlab.webservice.psql.port` | | PostgreSQLサーバーポートを設定します。`global.psql.port`より優先されます | +| `global.registry.enabled` | `true` | レジストリを有効にします。`registry.enabled`をミラーリングします | +| `global.registry.api.port` | `5000` | レジストリポート | +| `global.registry.api.protocol` | `http` | レジストリプロトコル | +| `global.registry.api.serviceName` | `registry` | レジストリサービス名 | +| `global.registry.tokenIssuer` | `gitlab-issuer` | レジストリトークン発行者 | +| `gitlab.webservice.replicaCount` | `1` | webserviceレプリカ数 | +| `gitlab.webservice.resources.requests.cpu` | `200m` | webserviceの最小CPU | +| `gitlab.webservice.resources.requests.memory` | `1.4G` | webserviceの最小メモリ | +| `gitlab.webservice.securityContext.fsGroup` | `1000` | ポッドの起動に使用するグループID | +| `gitlab.webservice.securityContext.runAsUser` | `1000` | ポッドの起動に使用するユーザーID | +| `gitlab.webservice.service.annotations` | `{}` | `Service`に追加する注釈 | +| `gitlab.webservice.http.enabled` | `true` | webservice HTTPを有効にする | +| `gitlab.webservice.service.externalPort` | `8080` | webservice公開ポート | +| `gitlab.webservice.service.internalPort` | `8080` | webservice内部ポート | +| `gitlab.webservice.tls.enabled` | `false` | webservice TLSを有効にする | +| `gitlab.webservice.tls.secretName` | `{Release.Name}-webservice-tls` | TLSキーのwebserviceシークレット名 | +| `gitlab.webservice.service.tls.externalPort` | `8081` | webservice TLS公開ポート | +| `gitlab.webservice.service.tls.internalPort` | `8081` | webservice TLS内部ポート | +| `gitlab.webservice.service.type` | `ClusterIP` | webserviceサービスタイプ | +| `gitlab.webservice.service.workhorseExternalPort` | `8181` | Workhorse公開ポート | +| `gitlab.webservice.service.workhorseInternalPort` | `8181` | Workhorse内部ポート | +| `gitlab.webservice.shell.authToken.key` | `secret` | Shellシークレット内のShellトークンへのキー | +| `gitlab.webservice.shell.authToken.secret` | `{Release.Name}-gitlab-shell-secret` | Shellトークンシークレット | +| `gitlab.webservice.workerProcesses` | `2` | webserviceのworker数 | +| `gitlab.webservice.workerTimeout` | `60` | webservice workerのタイムアウト | +| `gitlab.webservice.workhorse.extraArgs` | `""` | workhorseの追加パラメータの文字列 | +| `gitlab.webservice.workhorse.image` | `registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee` | Workhorseイメージリポジトリ | +| `gitlab.webservice.workhorse.sentryDSN` | `""` | エラーレポート用のSentryインスタンスのDSN | +| `gitlab.webservice.workhorse.tag` | | Workhorseイメージtag | + +## 外部チャート {#external-charts} + +GitLabは他のいくつかのチャートを利用します。これらは[親子関係](https://helm.sh/docs/topics/charts/#chart-dependencies)として扱われます。設定するプロパティは`chart-name.property`として指定してください。 + +### Prometheus {#prometheus} + +Prometheusの値のプレフィックスは`prometheus`です。たとえば、`prometheus.server.persistentVolume.size`を使用して永続ストレージ値を設定します。Prometheusを無効にするには、`prometheus.install=false`を設定します。 + +設定オプションの詳しいリストについては、[Prometheusチャートのドキュメント](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus)を参照してください。 + +### PostgreSQL {#postgresql} + +PostgreSQLの値のプレフィックスは`postgresql`です。たとえば、`postgresql.primary.persistence.storageClass`を使用して、プライマリのストレージクラスを設定します。 + +構成オプションの完全なリストについては、[Bitnami PostgreSQLチャートのドキュメント](https://artifacthub.io/packages/helm/bitnami/postgresql)を参照してください。 + +## 独自のイメージの持ち込み {#bringing-your-own-images} + +特定のシナリオ（オフライン環境など）では、インターネットからプルするのではなく、独自のイメージを持ち込む必要がある場合があります。これには、GitLabリリースを構成する各チャートに対して、独自のDockerイメージ レジストリ/リポジトリを指定する必要があります。 + +詳細については、[カスタムイメージに関するドキュメント](../advanced/custom-images/_index.md)を参照してください。 diff --git a/doc-locale/ja-jp/installation/database_upgrade.md b/doc-locale/ja-jp/installation/database_upgrade.md new file mode 100644 index 0000000000..53a44996ad --- /dev/null +++ b/doc-locale/ja-jp/installation/database_upgrade.md @@ -0,0 +1,155 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: バンドルされているPostgreSQLバージョンをアップグレードする +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +{{< alert type="note" >}} + +これらの手順は、バンドルされたPostgreSQLチャート(`postgresql.install`がfalseではない)を使用している場合の手順であり、外部PostgreSQLセットアップの場合の手順ではありません。 + +{{< /alert >}} + +{{< alert type="warning" >}} + +バンドルされたbitnami PostgreSQLチャートは、本番環境に対応していません。本番環境に対応したGitLabチャートのデプロイメントには、外部データベースを使用してください。 + +{{< /alert >}} + +バンドルされたPostgreSQLチャートを使用してPostgreSQLの新しいメジャーバージョンに変更するには、既存のデータベースのバックアップを作成し、新しいデータベースに復元します。 + +{{< alert type="note" >}} + +このチャートの`9.0.0`リリースの過程で、`14.8.0`から`16.6.0`にデフォルトのPostgreSQLバージョンをアップグレードしました。これは、[PostgreSQLチャート](https://github.com/bitnami/charts/tree/main/bitnami/postgresql)バージョンを`12.5.2`から`13.4.4`にアップグレードすることで行われます。 + +{{< /alert >}} + +これは、ドロップインリプレースメントではありません。データベースをアップグレードするには、手動による手順を実行する必要があります。手順は[アップグレード手順](#steps-for-upgrading-the-bundled-postgresql)に記載されています。 + +## バンドルされたPostgreSQLをアップグレードする手順 {#steps-for-upgrading-the-bundled-postgresql} + +これは、アップストリームのPostgreSQLチャートの[イシュー](https://github.com/bitnami/charts/issues/16707)が原因です。PostgreSQLのパスワードに環境変数を使用せず、ファイルの使用を希望する場合は、次の手順を実行する前に、手動で[既存のPostgreSQLパスワードシークレットを編集](#edit-the-existing-postgresql-passwords-secret)し、PostgreSQLチャートのパスワードファイルを有効にする必要があります。 + +### 既存のデータベースを準備する {#prepare-the-existing-database} + +以下の点に注意してください。 + +- バンドルされたPostgreSQLチャート(`postgresql.install`がfalse)を使用していない場合は、これらの手順に従う必要はありません。 +- 複数のチャートが同じネームスペースにインストールされている場合。Helmリリースの名前をデータベースアップグレードスクリプトに渡す必要がある場合があります。後で提供されるコマンド例で、`bash -s STAGE`を`bash -s -- -r RELEASE STAGE`に置き換えます。 +- チャートを`kubectl`コンテキストのデフォルト以外のネームスペースにインストールした場合は、ネームスペースをデータベースアップグレードスクリプトに渡す必要があります。後で提供されるコマンド例で、`bash -s STAGE`を`bash -s -- -n NAMESPACE STAGE`に置き換えます。このオプションは、`-r RELEASE`とともに使用できます。`kubectl config set-context --current --namespace=NAMESPACE`を実行するか、kubectxの[`kubens`](https://github.com/ahmetb/kubectx)を使用して、コンテキストのデフォルトのネームスペースを設定できます。 + +`pre`ステージでは、Toolboxのbackup-utilityスクリプトを使用してデータベースのバックアップが作成され、設定済みのS3バケット (デフォルトではMinIO) に保存されます。 + +```shell +# GITLAB_RELEASE should be the version of the chart you are installing, starting with 'v': v6.0.0 +curl -s "https://gitlab.com/gitlab-org/charts/gitlab/-/raw/${GITLAB_RELEASE}/scripts/database-upgrade" | bash -s pre +``` + +### 既存のPostgreSQLデータを削除する {#delete-existing-postgresql-data} + +{{< alert type="note" >}} + +PostgreSQLのデータ形式が変更されたため、アップグレードするには、リリースをアップグレードする前に、既存のPostgreSQL StatefulSetを削除する必要があります。StatefulSetは次の手順で再作成されます。 + +{{< /alert >}} + +{{< alert type="warning" >}} + +前の手順でデータベースのバックアップを作成したことを確認してください。バックアップがないと、GitLabデータが失われます。 + +{{< /alert >}} + +```shell +kubectl delete statefulset RELEASE-NAME-postgresql +kubectl delete pvc data-RELEASE_NAME-postgresql-0 +``` + +### GitLabをアップグレードする {#upgrade-gitlab} + +[標準的な手順](upgrade.md#steps)に従ってGitLabをアップグレードしてください。追加事項は以下のとおりです。 + +アップグレードコマンドで次のフラグを使用して、移行を無効にします。 + +1. `--set gitlab.migrations.enabled=false` + +バンドルされたPostgreSQLについては、後の手順でデータベースの移行を実行します。 + +### データベースを復元する {#restore-the-database} + +以下の点に注意してください。 + +- bash連想配列を使用する必要があるため、スクリプトを正常に実行するには、Bash 4.0以降を使用する必要があります。 + +1. Toolboxポッドのアップグレードが完了するまで待ちます。RELEASE_NAMEは、`helm list`のGitLabリリースの名前である必要があります + + ```shell + kubectl rollout status -w deployment/RELEASE_NAME-toolbox + ``` + +1. Toolboxポッドが正常にデプロイされたら、`post`ステップを実行します。 + + ```shell + # GITLAB_RELEASE should be the version of the chart you are installing, starting with 'v': v6.0.0 + curl -s "https://gitlab.com/gitlab-org/charts/gitlab/-/raw/${GITLAB_RELEASE}/scripts/database-upgrade" | bash -s post + ``` + + この手順では、次のことを行います。 + + 1. `webservice`、`sidekiq`、および`gitlab-exporter`デプロイメントのレプリカを0に設定します。これにより、バックアップの復元中に他のアプリケーションがデータベースを変更できなくなります。 + 1. プレステージで作成されたバックアップからデータベースを復元します。 + 1. 新しいバージョンのデータベース移行を実行します。 + 1. 最初の手順からデプロイメントを再開します。 + +### データベースのアップグレードプロセスのトラブルシューティング {#troubleshooting-database-upgrade-process} + +- アップグレード中にエラーが発生した場合は、詳細について`gitlab-upgrade-check`ポッドの説明を確認すると役立つ場合があります。 + + ```shell + kubectl get pods -lrelease=RELEASE,app=gitlab + kubectl describe pod + ``` + +## 既存のPostgreSQLパスワードシークレットを編集する {#edit-the-existing-postgresql-passwords-secret} + +{{< alert type="note" >}} + +これは、`7.0.0`のアップグレードのみを対象とし、PostgreSQLサービスコンテナ内でパスワードファイルの使用を強制する場合のみを対象としています。 + +{{< /alert >}} + +[PostgreSQLチャート](https://github.com/bitnami/charts/tree/main/bitnami/postgresql)の新しいバージョンでは、シークレット内のパスワードを参照するために異なるキーが使用されます。`postgresql-password`および`postgresql-postgres-password`の代わりに、`password`および`postgres-password`が使用されるようになりました。これらのキーは、値を変更せずに`RELEASE-postgresql-password`シークレットで変更_する_必要があります。 + +このシークレットは、最初にGitLabチャートによって生成され、アップグレード中またはアップグレード後には変更されません。したがって、シークレットを編集してキーを変更する必要があります。 + +シークレットを編集したら、Helmアップグレードの値で_必ず_**`postgresql.auth.usePasswordFiles`を`true`に設定**してください。デフォルトは`false`です。 + +次のスクリプトは、シークレットのパッチ適用に役立ちます。 + +1. 最初に、既存のシークレットのバックアップを作成します。次のコマンドは、`-backup`という名前のサフィックスが付いた新しいシークレットにコピーします。 + + ```shell + kubectl get secrets ${RELEASE}-postgresql-password -o yaml | sed 's/name: \(.*\)$/name: \1-backup/' | kubectl apply -f - + ``` + +1. パッチが正しく表示されることを確認します。 + + ```shell + kubectl get secret ${RELEASE}-postgresql-password \ + -o go-template='{"data":{"password":"{{index .data "postgresql-password"}}","postgres-password":"{{index .data "postgresql-postgres-password"}}","postgresql-password":null,"postgresql-postgres-password":null}}' + ``` + +1. 次に、適用します。 + + ```shell + kubectl patch secret ${RELEASE}-postgresql-password --patch "$( + kubectl get secret ${RELEASE}-postgresql-password \ + -o go-template='{"data":{"password":"{{index .data "postgresql-password"}}","postgres-password":"{{index .data "postgresql-postgres-password"}}","postgresql-password":null,"postgresql-postgres-password":null}}')" + ``` diff --git a/doc-locale/ja-jp/installation/migration/_index.md b/doc-locale/ja-jp/installation/migration/_index.md new file mode 100644 index 0000000000..f2c8e360f1 --- /dev/null +++ b/doc-locale/ja-jp/installation/migration/_index.md @@ -0,0 +1,24 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャートの移行ガイド +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +Helmチャートとの間の移行: + +- [LinuxパッケージからHelmチャートに移行する。](package_to_helm.md) +- [HelmチャートからLinuxパッケージに移行する。](helm_to_package.md) + +その他の移行: + +- [Helmバージョン間で移行する。](helm.md) +- [オブジェクトストレージ用に組み込みのMinIOサービスに移行する。](minio.md) +- [Gitalyチャートから外部Gitalyに移行する](../../advanced/external-gitaly/_index.md#migrate-from-gitaly-chart-to-external-gitaly) diff --git a/doc-locale/ja-jp/installation/migration/helm.md b/doc-locale/ja-jp/installation/migration/helm.md new file mode 100644 index 0000000000..79818e4e8d --- /dev/null +++ b/doc-locale/ja-jp/installation/migration/helm.md @@ -0,0 +1,99 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Helm v2からHelm v3への移行 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +[Helm v2は2020年11月に正式に非推奨](https://helm.sh/blog/helm-v2-deprecation-timeline/)となりました。GitLab Helmチャートバージョン5.0（GitLabアプリケーションバージョン14.0）以降、Helm v2.xを使用したインストールとアップグレードはサポートされなくなりました。今後のGitLabの更新を入手するには、Helm v3に移行する必要があります。 + +## Helm v2とHelm v3の変更点 {#changes-between-helm-v2-and-helm-v3} + +Helm v3では、Helm v2との下位互換性のない多くの変更が導入されています。主な変更点としては、Tiller要件の削除や、クラスターでのリリース情報の保存方法などがあります。詳しくは、[Helm v3の変更点の概要](https://helm.sh/docs/topics/v2_v3_migration/#overview-of-helm-3-changes)と[Helm v2 FAQからの変更点](https://helm.sh/docs/faq/changes_since_helm2/)をご覧ください。 + +アプリケーションのデプロイに使用するHelm Chartは、新旧バージョンのHelmと互換性がない場合があります。複数のアプリケーションをHelm v2でデプロイおよび管理している場合は、それらも変換する場合に備えて、Helm v3との互換性を確認する必要があります。GitLab Helmチャートは、GitLab Helmチャートのバージョンv3.0.0以降、Helm v3.0.2以上をサポートしています。Helm v2はサポートされなくなりました。 + +現在実行中のアプリケーションの観点からは、Helm v2からv3への移行を実行しても何も変更されません。通常、Helm v2からv3への移行を実行してもかなり安全ですが、念のため、Helm v2のバックアップを作成してください。 + +## Helm v2からHelm v3への移行方法 {#how-to-migrate-from-helm-v2-to-helm-v3} + +[Helm 2to3プラグイン](https://github.com/helm/helm-2to3)を使用して、GitLabのリリースをHelm v2からHelm v3に移行できます。この移行プラグインに関する詳細な説明といくつかの例については、Helmのブログ記事を参照してください:[Helm v2からHelm v3への移行方法](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/)。 + +GitLab Helmのインストールを複数のユーザーが管理している場合は、各ローカルマシンで`helm3 2to3 move config`を実行する必要がある場合があります。`helm3 2to3 convert`を実行する必要があるのは1回だけです。 + +## 既知のイシュー {#known-issues} + +### 「UPGRADE FAILED: cannot patch」エラーが移行後に表示される {#upgrade-failed-cannot-patch-error-is-shown-after-the-migration} + +移行後、**その後のアップグレードが失敗**し、次のようなエラーが表示される場合があります。 + +```shell +Error: UPGRADE FAILED: cannot patch "..." with kind Deployment: Deployment.apps "..." is invalid: spec.selector: +Invalid value: v1.LabelSelector{...}: field is immutable +``` + +または + +```shell +Error: UPGRADE FAILED: cannot patch "..." with kind StatefulSet: StatefulSet.apps "..." is invalid: +spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden +``` + +これは、[Cert Manager](https://github.com/jetstack/cert-manager/issues/2451)と[Redis](https://github.com/bitnami/charts/issues/3482)の依存関係におけるHelm 2から3への移行に関する既知のイシューが原因です。一言で言えば、一部のデプロイメントとステートフルセットの`heritage`ラベルは不変であり、`Tiller`（Helm 2で設定）から`Helm`（Helm 3で設定）に変更できません。そのため、_強制的に_置き換える必要があります。 + +これを回避するには、次の手順を使用します: + +{{< alert type="note" >}} + +これらの手順は、特にRedis StatefulSetで、_リソースを強制的に置き換えます_。このStatefulSetにアタッチされているデータボリュームが安全で、そのまま残っていることを確認する必要があります。 + +{{< /alert >}} + +1. （有効になっている場合は）cert-managerデプロイメントを置き換えます。 + +```shell +kubectl get deployments -l app=cert-manager -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true -f - +kubectl get deployments -l app=cainjector -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true -f - +``` + +1. （オプション）Redis StatefulSetによって要求されるPVの`persistentVolumeReclaimPolicy`を`Retain`に設定します。これは、PVが誤って削除されないようにするためです。 + +```shell +kubectl patch pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' +``` + +1. 既存のRedis PVCの`heritage`ラベルを`Helm`に設定します。 + +```shell +kubectl label pvc -l app=redis --overwrite heritage=Helm +``` + +1. **カスケードなしで**Redis StatefulSetを置き換えます。 + +```shell +kubectl get statefulsets.apps -l app=redis -o yaml | sed "s/Tiller/Helm/g" | kubectl replace --force=true --cascade=false -f - +``` + +### Helmのアップグレード実行時の移行後のRBACに関するイシュー {#rbac-issues-after-the-migration-when-running-helm-upgrade} + +変換が完了した後、Helmのアップグレードを実行すると、次のエラーが発生する場合があります。 + +```shell +Error: UPGRADE FAILED: pre-upgrade hooks failed: warning: Hook pre-upgrade gitlab/templates/shared-secrets/rbac-config.yaml failed: roles.rbac.authorization.k8s.io "gitlab-shared-secrets" is forbidden: user "your-user-name@domain.tld" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held: +{APIGroups:[""], Resources:["secrets"], Verbs:["get" "list" "create" "patch"]} +``` + +Helm2は、Tillerサービスアカウントを使用してこのようなオペレーションを実行していました。Helm3はTillerを使用しなくなり、クラスター管理者として`helm upgrade`を実行している場合でも、コマンドを実行するには、ユーザーアカウントに適切なRBAC権限が必要です。自分自身に完全なRBAC権限を付与するには、次を実行します: + +```shell +kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=your-user-name@domain.tld +``` + +その後、`helm upgrade`は正常に動作するはずです。 diff --git a/doc-locale/ja-jp/installation/migration/helm_to_package.md b/doc-locale/ja-jp/installation/migration/helm_to_package.md new file mode 100644 index 0000000000..54bd4e81ca --- /dev/null +++ b/doc-locale/ja-jp/installation/migration/helm_to_package.md @@ -0,0 +1,91 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Helm ChartからLinuxパッケージへの移行 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +HelmインストールからLinuxパッケージ（Omnibus）インストールに移行するには、次の手順に従います。 + +1. 左側のサイドバーの下部にある**管理者エリア**を選択します。 +1. **概要 > コンポーネント**を選択して、現在のGitLabのバージョンを確認します。 +1. cleanなマシンを準備し、GitLab Helmチャートのバージョンに一致する[Linuxパッケージをインストール](https://docs.gitlab.com/update/package/)します。 +1. 移行前に、GitLab Helm Chartインスタンスで[Gitリポジトリの整合性を確認](https://docs.gitlab.com/administration/raketasks/check/)します。 +1. [GitLab Helmチャートインスタンスのバックアップを作成](../../backup-restore/backup.md)し、必ず[シークレットもバックアップ](../../backup-restore/backup.md#back-up-the-secrets)してください。 +1. Linuxパッケージインスタンスで`/etc/gitlab/gitlab-secrets.json`をバックアップします。 +1. `kubectl`コマンドを実行するワークステーションに、[yq](https://github.com/mikefarah/yq)ツール（バージョン4.21.1以降）をインストールします。 +1. ワークステーションに`/etc/gitlab/gitlab-secrets.json`ファイルのコピーを作成します。 +1. GitLab Helm Chartインスタンスからシークレットを取得するには、次のコマンドを実行します。`GITLAB_NAMESPACE`と`RELEASE`を適切な値に置き換えます。 + + ```shell + kubectl get secret -n GITLAB_NAMESPACE RELEASE-rails-secret -ojsonpath='{.data.secrets\.yml}' | yq '@base64d | from_yaml | .production' -o json > rails-secrets.json + yq eval-all 'select(filename == "gitlab-secrets.json").gitlab_rails = select(filename == "rails-secrets.json") | select(filename == "gitlab-secrets.json")' -ojson gitlab-secrets.json rails-secrets.json > gitlab-secrets-updated.json + ``` + +1. 結果は`gitlab-secrets-updated.json`になります。これは、Linuxパッケージインスタンスの古いバージョンの`/etc/gitlab/gitlab-secrets.json`を置き換えるために使用できます。 +1. `/etc/gitlab/gitlab-secrets.json`を置き換えた後、Linuxパッケージインスタンスを再構成します。 + + ```shell + sudo gitlab-ctl reconfigure + ``` + +1. Linuxパッケージインスタンスで、[オブジェクトストレージ](https://docs.gitlab.com/administration/object_storage/)を設定し、LFS、アーティファクト、アップロードなどをテストして、動作することを確認します。 +1. コンテナレジストリを使用する場合は、[オブジェクトストレージを個別に構成](https://docs.gitlab.com/administration/packages/container_registry/#use-object-storage)します。統合されたオブジェクトストレージはサポートされていません。 +1. Helm chartインスタンスに接続されているオブジェクトストレージから、Linuxパッケージインスタンスに接続されている新しいストレージにデータを同期します。いくつかの注意点: + + - S3互換ストレージの場合は、`s3cmd`ユーティリティを使用してデータをコピーします。 + - LinuxパッケージインスタンスでMinIOのようなS3互換のオブジェクトストレージを使用する予定がある場合は、MinIOを`endpoint`で指定し、`path_style`を`true`に設定する必要があります(`/etc/gitlab/gitlab.rb`)。 + - 新しいLinuxパッケージインスタンスで古いオブジェクトストレージを再利用できます。この場合、2つのオブジェクトストレージ間でデータを同期する必要はありません。ただし、組み込みのMinIOインスタンスを使用している場合、GitLab Helmチャートをアンインストールすると、ストレージのプロビジョニングが解除される可能性があります。 + +1. GitLab HelmバックアップをLinuxパッケージのGitLabインスタンスの`/var/opt/gitlab/backups`にコピーし、[復元を実行](https://docs.gitlab.com/administration/backup_restore/restore_gitlab/#restore-for-linux-package-installations)します。 +1. （オプション）Git SSHクライアントでホストのミスマッチエラーを回避するために、SSHホストキーを復元します。 + + 1. 次のスクリプトを使用して、[`-gitlab-shell-host-keys`シークレット](../secrets.md#ssh-host-keys)をファイルに変換します（必要なツール：`jq`、`base64`、および`kubectl`）。 + + ```shell + mkdir ssh + HOSTKEYS_JSON="hostkeys.json" + GITLAB_NAMESPACE="my_namespace" + kubectl get secret -n ${GITLAB_NAMESPACE} gitlab-gitlab-shell-host-keys -o json > ${HOSTKEYS_JSON} + + for k in $(jq -r '.data | keys | .[]' ${HOSTKEYS_JSON}); \ + do \ + jq -r --arg host_key ${k} '.data[$host_key]' ${HOSTKEYS_JSON} | base64 --decode > ssh/$k ; \ + done + ``` + + 1. 変換されたファイルをGitLab Railsノードにアップロードします。 + 1. ターゲットのRailsノードで、以下を実行します。 + 1. たとえば、`/etc/ssh/`ディレクトリをバックアップします。 + + ```shell + sudo tar -czvf /root/ssh_dir.tar.gz -C /etc ssh + ``` + + 1. 既存のホストキーを削除します。 + + ```shell + sudo find /etc/ssh -type f -name "/etc/ssh/ssh_*_key*" -delete + ``` + + 1. 変換されたホストキーファイルを所定の場所（`/etc/ssh`）に移動します。 + + ```shell + for f in ssh/*; do sudo install -b -D -o root -g root -m 0600 $f /etc/${f} ; done + ``` + + 1. SSHデーモンを再起動します。 + + ```shell + sudo systemctl restart ssh.service + ``` + +1. 復元が完了したら、[doctor Rakeタスク](https://docs.gitlab.com/administration/raketasks/check/)を実行して、シークレットが有効であることを確認します。 +1. すべてが検証されたら、GitLab Helmチャートインスタンスを[アンインストール](../uninstall.md)できます。 diff --git a/doc-locale/ja-jp/installation/migration/minio.md b/doc-locale/ja-jp/installation/migration/minio.md new file mode 100644 index 0000000000..65e8acab6e --- /dev/null +++ b/doc-locale/ja-jp/installation/migration/minio.md @@ -0,0 +1,58 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: オブジェクトストレージに組み込みのMinIOサービスを使用します +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +この移行ガイドは、[パッケージベースのインストール](package_to_helm.md)からHelm Chartに移行し、オブジェクトストレージに組み込みのMinIOサービスを使用する場合を対象としています。これはテスト目的により適しています。本番環境で使用する場合は、[外部オブジェクトストレージ](../../advanced/external-object-storage/_index.md)をセットアップすることをお勧めします。 + +組み込みのMinIOクラスターへのアクセス詳細を把握する最も簡単な方法は、Sidekiq、Webservice、Toolboxポッドで生成される`gitlab.yml`ファイルを確認することです。 + +Sidekiqポッドから取得するには: + +1. Sidekiqポッドの名前を調べます: + + ```shell + kubectl get pods -lapp=sidekiq + ``` + +1. Sidekiqポッドから`gitlab.yml`ファイルを取得します: + + ```shell + kubectl exec -- cat /srv/gitlab/config/gitlab.yml + ``` + +1. `gitlab.yml`ファイルには、オブジェクトストレージ接続の詳細を含むアップロードのセクションがあります。以下のようなものです: + + ```yaml + uploads: + enabled: true + object_store: + enabled: true + remote_directory: gitlab-uploads + proxy_download: true + connection: + provider: AWS + region: + aws_access_key_id: "" + aws_secret_access_key: "" + host: + endpoint: + path_style: true + ``` + +1. この情報を使用して、パッケージベースのデプロイの`/etc/gitlab/gitlab.rb`ファイルで[オブジェクトストレージを設定](https://docs.gitlab.com/administration/uploads/#s3-compatible-connection-settings)します。 + + {{< alert type="note" >}} + +クラスターの外部からMinIOサービスに接続する場合、MinIOホストURLだけで十分です。Helm Chartベースのインストールは、そのURLへのリクエストを対応するエンドポイントに自動的にリダイレクトするように構成されています。そのため、`/etc/gitlab/gitlab.rb`の接続設定で`endpoint`値を設定する必要はありません。 + +{{< /alert >}} diff --git a/doc-locale/ja-jp/installation/migration/package_to_helm.md b/doc-locale/ja-jp/installation/migration/package_to_helm.md new file mode 100644 index 0000000000..391e42b3b1 --- /dev/null +++ b/doc-locale/ja-jp/installation/migration/package_to_helm.md @@ -0,0 +1,44 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: LinuxパッケージからHelm Chartへの移行 +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +このガイドでは、パッケージベースのGitLabインスタンスからHelm Chartへの移行について説明します。 + +## 前提要件 {#prerequisites} + +移行を行う前に、いくつかの前提要件を満たす必要があります。 + +- パッケージベースのGitLabインスタンスが起動して実行されている必要があります。`gitlab-ctl status`を実行して、サービスが`down`状態をレポートしていないことを確認します。 +- 移行の前に、Gitリポジトリの[整合性をVerify](https://docs.gitlab.com/administration/raketasks/check/)することをお勧めします。 +- パッケージベースのインストールと同じGitLabのバージョンを実行している、Helm Chartベースのデプロイが必要です。 +- Helm Chartベースのデプロイで使用するオブジェクトストレージを設定する必要があります。本番環境で使用する場合は、[外部オブジェクトストレージ](../../advanced/external-object-storage/_index.md)を使用し、それにアクセスするための認証情報を準備しておくことをお勧めします。組み込みのMinIOサービスを使用している場合は、そこからログイン認証情報を取得する方法について、[ドキュメントをお読みください](minio.md)。 + +## 移行手順 {#migration-steps} + +1. パッケージベースのインストールからオブジェクトストレージに既存のデータを移行します。 + + 1. [オブジェクトストレージに移行します](https://docs.gitlab.com/administration/object_storage/#migrate-to-object-storage)。 + + 1. パッケージベースのGitLabインスタンスにアクセスし、移行されたデータが利用可能であることを確認します。たとえば、ユーザー、グループ、プロジェクトのアバターが正常に表示されているか、イシューに追加された画像やその他のファイルが正しく読み込まれているかなどを確認します。 + +1. [バックアップtarballを作成](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/)し、[既に移行されたディレクトリをすべて除外します](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/#excluding-specific-directories-from-the-backup)。 + + ローカルバックアップ（デフォルト）の場合、バックアップファイルは`/var/opt/gitlab/backups`に保存されます。場所を[明示的に変更した場合](https://docs.gitlab.com/omnibus/settings/backups/#manually-manage-backup-directory)を除きます。[リモートストレージバックアップ](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/#upload-backups-to-a-remote-cloud-storage)の場合、バックアップファイルは設定されたバケットに保存されます。 +1. シークレットから開始して、[パッケージベースのインストールから復元](../../backup-restore/restore.md)してHelm Chartに移行します。`/etc/gitlab/gitlab-secrets.json`の値を、Helmで使用されるYAMLファイルに移行する必要があります。 +1. 変更が適用されるように、すべてのポッドを再起動します。 + + ```shell + kubectl delete pods -lrelease= + ``` + +1. Helmベースのデプロイにアクセスし、パッケージベースのインストールに存在していたプロジェクト、グループ、ユーザー、イシューなどが復元されていることを確認します。また、アップロードされたファイル（アバター、イシューにアップロードされたファイルなど）が正常に読み込まれているかどうかを確認します。 diff --git a/doc-locale/ja-jp/installation/rbac.md b/doc-locale/ja-jp/installation/rbac.md new file mode 100644 index 0000000000..38c357eabe --- /dev/null +++ b/doc-locale/ja-jp/installation/rbac.md @@ -0,0 +1,55 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのRBACの設定 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +Kubernetes 1.7までは、クラスター内に権限がありませんでした。1.7のリリースにより、クラスター内でサービスが実行できる[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)（ロールベースのアクセス制御）システムが導入されました。 + +RBACは、GitLabのいくつかの異なる側面に影響を与えます。 + +- Helmを使用したGitLabのインストール +- Prometheusモニタリング +- GitLab Runner +- クラスター内PostgreSQLデータベース (RBACが有効な場合) +- 証明書マネージャー + +## RBACが有効になっていることの確認 {#checking-that-rbac-is-enabled} + +現在のクラスターロールをリストしてみてください。失敗した場合は、`RBAC`が無効になっています + +このコマンドは、`RBAC`が無効の場合は`false`を、それ以外の場合は`true`を出力します + +`kubectl get clusterroles > /dev/null 2>&1 && echo true || echo false` + +## サービスアカウント {#service-accounts} + +GitLabチャートは、サービスアカウントを使用して特定のタスクを実行します。これらのアカウントとそれに関連付けられたロールは、チャートによって作成および管理されます。 + +サービスアカウントについては、次のテーブルで説明します。各サービスアカウントについて、テーブルには以下が示されています。 + +- 名前のサフィックス (プレフィックスはリリースの名前)。 +- 簡単な説明。たとえば、どこで使用されているか、何に使用されているか。 +- 関連付けられたロールと、どのリソースに対するアクセスレベル。アクセスレベルは、読み取り専用 (R)、書き込み専用 (W)、または読み取り/書き込み (RW) のいずれかです。リソースのグループ名が省略されていることに注意してください。 +- ロールのスコープ。クラスター (C) またはネームスペース (NS) のいずれかです。インスタンスによっては、ロールのスコープはいずれかの値で構成できます (NS/Cで示されます) + +| 名前のサフィックス | 説明 | ロール | スコープ +| --- | --- | --- | --- +| `gitlab-runner` | GitLab Runnerは、このアカウントで実行されます。 | 任意のリソース (RW) | NS/C +| `ingress-nginx` | NGINX Ingressによって使用され、サービスのエンドポイントへのアクセスを制御します。 | シークレット、Pod、エンドポイント、Ingress (R)、イベント (W)、ConfigMap、サービス (RW) | NS/C +| `shared-secrets` | 共有シークレットを作成するジョブは、このアカウントで実行されます。(インストール前/アップグレードのフック時) | シークレット(RW) | NS +| `cert-manager` | 証明書マネージャーを制御するジョブは、このアカウントで実行されます。 | Issuer、Certificate、CertificateRequest、Order (RW) | NS/C + +GitLabチャートは、RBACを使用し、独自のサービスアカウントとロールバインディングを作成する他のチャートに依存しています。概要を以下に示します。 + +- Prometheusモニタリングは、デフォルトで複数の独自のサービスアカウントを作成します。これらはすべて、クラスターレベルのロールに関連付けられています。詳細については、[Prometheusチャートのドキュメント](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#rbac-configuration)を参照してください。 +- 証明書マネージャーは、カスタムリソースとネイティブリソースをクラスターレベルで管理するために、デフォルトでサービスアカウントを作成します。詳細については、[cert-managerチャートRBACテンプレート](https://github.com/cert-manager/cert-manager/blob/master/deploy/charts/cert-manager/templates/rbac.yaml)を参照してください。 +- クラスター内PostgreSQLデータベースを使用する場合 (これはデフォルトです)、サービスアカウントは有効になりません。有効にすることはできますが、PostgreSQLサービスの実行にのみ使用され、特定のロールに関連付けられていません。詳細については、[PostgreSQLチャート](https://github.com/bitnami/charts/tree/main/bitnami/postgresql)を参照してください。 diff --git a/doc-locale/ja-jp/installation/secrets.md b/doc-locale/ja-jp/installation/secrets.md new file mode 100644 index 0000000000..393e104e5e --- /dev/null +++ b/doc-locale/ja-jp/installation/secrets.md @@ -0,0 +1,602 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのシークレットを設定する +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabを稼働させるには、さまざまなシークレットが必要です。 + +GitLabコンポーネント: + +- レジストリ認証証明書 +- GitLab ShellのSSHホストキーと証明書 +- 個々のGitLabサービス用パスワード +- GitLab PagesのTLS証明書 + +オプションの外部サービス: + +- SMTPサーバー +- LDAP +- OmniAuth +- 受信メール用IMAP (mail_roomサービス経由) +- Service Deskメール用IMAP (mail_roomサービス経由) +- 受信メール用OAuth2を使用したMicrosoft Graph (mail_roomサービス経由) +- Service Deskメール用OAuth2を使用したMicrosoft Graph (mail_roomサービス経由) +- 送信メール用OAuth2を使用したMicrosoft Graph +- S/MIME証明書 +- スマートカード認証 +- OAuthインテグレーション + +手動で提供されないシークレットは、ランダムな値で自動的に生成されます。HTTPS証明書の自動生成はLet's Encryptによって提供されます。 + +自動生成されたシークレットを利用するには、[次の手順](#next-steps)に進みます。 + +独自のシークレットを指定するには、[手動でのシークレットの作成](#manual-secret-creation-optional)に進みます。 + +## 手動でのシークレットの作成 (オプション) {#manual-secret-creation-optional} + +このドキュメントの前の手順に従った場合は、`gitlab`をリリース名として使用します。 + +- [TLS証明書](tls.md) +- [レジストリ認証証明書](#registry-authentication-certificates) +- [レジストリの機密通知ヘッダー](#registry-sensitive-notification-headers) +- [SSHホストキー](#ssh-host-keys) +- パスワード: + - [初期rootパスワード](#initial-root-password) + - [Redisパスワード](#redis-password) + - [GitLab Shellシークレット](#gitlab-shell-secret) + - [Gitalyシークレット](#gitaly-secret) + - [Praefectシークレット](#praefect-secret) + - [GitLab Railsシークレット](#gitlab-rails-secret) + - [GitLab Workhorseシークレット](#gitlab-workhorse-secret) + - [GitLab Runnerシークレット](#gitlab-runner-secret) + - [PostgreSQLパスワード](#postgresql-password) + - [Praefect DBパスワード](#praefect-db-password) + - [MinIOシークレット](#minio-secret) + - [レジストリHTTPシークレット](#registry-http-secret) + - [レジストリ通知シークレット](#registry-notification-secret) + - [GitLab Pagesシークレット](#gitlab-pages-secret) + - [GitLab受信メール認証トークン](#gitlab-incoming-email-auth-token) + - [GitLab Service Deskメール認証トークン](#gitlab-service-desk-email-auth-token) + - [Zoekt Basic認証パスワード](#zoekt-basic-auth-password) +- [外部サービス](#external-services) + - [OmniAuth](#omniauth) + - [LDAPパスワード](#ldap-password) + - [SMTPパスワード](#smtp-password) + - [受信メール用IMAPパスワード](#imap-password-for-incoming-emails) + - [Service Desk用IMAPパスワード](#imap-password-for-service-desk-emails) + - [受信メール用Microsoft Graphクライアントシークレット](#microsoft-graph-client-secret-for-incoming-emails) + - [Service Desk用Microsoft Graphクライアントシークレット](#microsoft-graph-client-secret-for-service-desk-emails) + - [送信メール用Microsoft Graphクライアントシークレット](#microsoft-graph-client-secret-for-outgoing-emails) + - [S/MIME証明書](#smime-certificate) + - [スマートカード認証](#smartcard-authentication) + +### レジストリ認証証明書 {#registry-authentication-certificates} + +GitLabとレジストリ間の通信はIngressの背後で行われるため、ほとんどの場合、この通信には自己署名証明書を使用すれば十分です。このトラフィックがネットワーク経由で公開されている場合は、公開的に有効な証明書を生成する必要があります。 + +以下の例では、自己署名証明書が必要であると想定しています。 + +証明書とキーのペアを生成します: + +```shell +mkdir -p certs +openssl req -new -newkey rsa:4096 -subj "/CN=gitlab-issuer" -nodes -x509 -keyout certs/registry-example-com.key -out certs/registry-example-com.crt +``` + +これらの証明書を含むシークレットを作成します。`registry-auth.key`および`registry-auth.crt`キーを`-registry-secret`シークレット内に作成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -registry-secret --from-file=registry-auth.key=certs/registry-example-com.key --from-file=registry-auth.crt=certs/registry-example-com.crt +``` + +このシークレットは、`global.registry.certificate.secret`設定によって参照されます。 + +### レジストリの機密通知ヘッダー {#registry-sensitive-notification-headers} + +詳細については、[レジストリ通知の設定に関するドキュメント](../charts/globals.md#configure-registry-settings)を確認してください。 + +シークレットの内容は、項目が1つしか含まれていない場合でも、項目のリストである必要があります。コンテンツが単なる文字列の場合、チャートは必要に応じてそれをリストに変換**しません**。 + +`RandomFooBar`の値を持つ`registry-authorization-header`シークレットが作成される例を考えてみましょう。 + +```shell +kubectl create secret generic registry-authorization-header --from-literal=value="[RandomFooBar]" +``` + +デフォルトでは、シークレット内で使用されるキーは「value」です。ただし、ユーザーは別のキーを使用できますが、ヘッダーマップ項目で`key`として指定されていることを確認する必要があります。 + +### SSHホストキー {#ssh-host-keys} + +OpenSSH証明書とキーのペアを生成します: + +```shell +mkdir -p hostKeys +ssh-keygen -t rsa -f hostKeys/ssh_host_rsa_key -N "" +ssh-keygen -t dsa -f hostKeys/ssh_host_dsa_key -N "" +ssh-keygen -t ecdsa -f hostKeys/ssh_host_ecdsa_key -N "" +ssh-keygen -t ed25519 -f hostKeys/ssh_host_ed25519_key -N "" +``` + +これらの証明書を含むシークレットを作成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-shell-host-keys --from-file hostKeys +``` + +このシークレットは、`global.shell.hostKeys.secret`設定によって参照されます。 + +このシークレットがローテーションされると、すべてのSSHクライアントに`hostname mismatch`エラーが表示されます。 + +### 初期Enterpriseライセンス {#initial-enterprise-license} + +{{< alert type="warning" >}} + +この方法は、インストール時にのみライセンスを追加します。Web UIの管理者エリアを使用して、ライセンスを更新またはアップグレードしてください。 + +{{< /alert >}} + +GitLabインスタンスのEnterpriseライセンスを格納するためのKubernetesシークレットを作成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-license --from-file=license=/tmp/license.gitlab +``` + +次に、`--set global.gitlab.license.secret=-gitlab-license`を使用して、ライセンスを構成に注入します。 + +`global.gitlab.license.key`オプションを使用して、ライセンスシークレットのライセンスを指すデフォルトの`license`キーを変更することもできます。 + +### 初期rootパスワード {#initial-root-password} + +初期rootパスワードを格納するためのKubernetesシークレットを作成します。パスワードは6文字以上にする必要があります。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-initial-root-password --from-literal=password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32) +``` + +### Redisパスワード {#redis-password} + +Redisのランダムな64文字の英数字パスワードを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -redis-secret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +既存のRedisクラスターを使用してデプロイする場合は、ランダムに生成されたパスワードの代わりに、base64エンコードされたRedisクラスターへのアクセスに使用するパスワードを使用してください。 + +このシークレットは、`global.redis.auth.secret`設定によって参照されます。 + +### GitLab Shellシークレット {#gitlab-shell-secret} + +GitLab Shell用のランダムな64文字の英数字シークレットを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-shell-secret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`global.shell.authToken.secret`設定によって参照されます。 + +### Gitalyシークレット {#gitaly-secret} + +Gitalyのランダムな64文字の英数字トークンを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitaly-secret --from-literal=token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`global.gitaly.authToken.secret`設定によって参照されます。 + +### Praefectシークレット {#praefect-secret} + +Praefectのランダムな64文字の英数字トークンを生成します。``をリリース名に置き換えます: + +```shell +kubectl create secret generic -praefect-secret --from-literal=token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`global.praefect.authToken.secret`設定によって参照されます。 + +### GitLab Railsシークレット {#gitlab-rails-secret} + +{{< history >}} + +- `active_record_encryption_*`キーは[GitLab 17.8](../releases/8_0.md#upgrade-to-880)で追加されました。 + +{{< /history >}} + +``をリリース名に置き換えます。 + +```shell +cat << EOF > secrets.yml +production: + secret_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128) + otp_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128) + db_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128) + encrypted_settings_key_base: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-f0-9' | head -c 128) + openid_connect_signing_key: | +$(openssl genrsa 2048 | awk '{print " " $0}') + active_record_encryption_primary_key: + - $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32) + active_record_encryption_deterministic_key: + - $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32) + active_record_encryption_key_derivation_salt: $(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32) +EOF + +kubectl create secret generic -rails-secret --from-file=secrets.yml +``` + +このシークレットは、`global.railsSecrets.secret`設定によって参照されます。 + +データベースの暗号化キーが含まれているため、このシークレットをローテーションする**ことは推奨されません**。シークレットがローテーションされると、[シークレットファイルが失われた場合](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/#when-the-secrets-file-is-lost)と同じ動作になります。 + +### GitLab Workhorseシークレット {#gitlab-workhorse-secret} + +Workhorseシークレットを生成します。これは、長さが32文字で、base64エンコードされている必要があります。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-workhorse-secret --from-literal=shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.workhorse.secret`設定によって参照されます。 + +### GitLab Runnerシークレット {#gitlab-runner-secret} + +``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-runner-secret --from-literal=runner-registration-token=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`gitlab-runner.runners.secret`設定によって参照されます。 + +### GitLab KASシークレット {#gitlab-kas-secret} + +KASサブチャートをインストールせずにこのチャートをデプロイする場合でも、GitLab RailsにはKASのシークレットが必要です。それでも、以下の手順に従ってこのシークレットを手動で作成するか、チャートにシークレットを自動生成させることができます。 + +``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-kas-secret --from-literal=kas_shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.appConfig.gitlab_kas.key`設定によって参照されます。 + +### GitLab KAS APIシークレット {#gitlab-kas-api-secret} + +チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます ( ``をリリース名に置き換えます): + +```shell +kubectl create secret generic -kas-private-api --from-literal=kas_private_api_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`gitlab.kas.privateApi.secret`設定によって参照されます。 + +### GitLab KAS WebSocketトークンシークレット {#gitlab-kas-websocket-token-secret} + +チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます ( ``をリリース名に置き換えます): + +```shell +kubectl create secret generic -kas-websocket-token --from-literal=kas_websocket_token_secret=$(head -c 72 /dev/urandom | base64 -w0) +``` + +このシークレットは、`gitlab.kas.websocketToken.secret`設定によって参照されます。 + +### GitLab Suggested Reviewersシークレット {#gitlab-suggested-reviewers-secret} + +{{< alert type="note" >}} + +レビュアーの推奨シークレットは自動的に作成され、GitLab.comでのみ使用されます。このシークレットはGitLab Self-Managedでは必要ありません。 + +{{< /alert >}} + +GitLab Railsには、レビュアーの推奨のシークレットが必要です。チャートにシークレットを自動生成させるか、このシークレットを手動で作成できます ( ``をリリース名に置き換えます): + +```shell +kubectl create secret generic -gitlab-suggested-reviewers --from-literal=suggested_reviewers_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.appConfig.suggested_reviewers.secret`設定によって参照されます。 + +### MinIOシークレット {#minio-secret} + +MinIO用のランダムな20文字と64文字の英数字キーのセットを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -minio-secret --from-literal=accesskey=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 20) --from-literal=secretkey=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`global.minio.credentials.secret`設定によって参照されます。 + +### PostgreSQLパスワード {#postgresql-password} + +ランダムな64文字の英数字パスワードを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -postgresql-password \ + --from-literal=postgresql-password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) \ + --from-literal=postgresql-postgres-password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) +``` + +このシークレットは、`global.psql.password.secret`設定によって参照されます。 + +#### バンドルされたPostgreSQLサブチャートのPostgreSQLパスワードの変更 {#changing-the-postgresql-password-for-the-bundled-postgresql-subchart} + +{{< alert type="warning" >}} + +デフォルトのHelm Chart構成は**本番環境を対象としていません**。これにはバンドルされたPostgreSQLサブチャートが含まれます。 + +{{< /alert >}} + +バンドルされたPostgreSQLサブチャートは、データベースが最初に作成されたときに、シークレットからのパスワードを使用してデータベースを構成するだけです。既存のデータベースでパスワードを変更するには、追加の手順を実行する必要があります。 + +この操作は、変更が行われている間、ユーザーに中断をもたらすことに注意してください。 + +PostgreSQLシークレットをローテーションするには: + +1. PostgreSQLシークレットの一般的な[シークレットのローテーション](#rotating-secrets)手順を完了します。 +1. PostgreSQLポッドにExecし、データベース内のパスワードを更新します: + + ```shell + # Exec into the PostgreSQL pod + kubectl exec -it -postgresql-0 -- sh + + # Inside the pod, update the passwords in the database + sed -i 's/^\(local .*\)md5$/\1trust/' /opt/bitnami/postgresql/conf/pg_hba.conf + pg_ctl reload ; sleep 1 + echo "ALTER USER postgres WITH PASSWORD '$(echo $POSTGRES_POSTGRES_PASSWORD)' ; ALTER USER gitlab WITH PASSWORD '$(echo POSTGRES_PASSWORD)'" | psql -U postgres -d gitlabhq_production -f - + sed -i 's/^\(local .*\)trust$/\1md5/' /opt/bitnami/postgresql/conf/pg_hba.conf + pg_ctl reload + ``` + +1. `gitlab-exporter`、`postgresql`、`toolbox`、`sidekiq`、および`webservice`ポッドを`kubectl delete pod`コマンドを使用して削除し、新しいポッドが新しいシークレットとともにロードされ、データベースに接続できるようにします。 + +### GitLab Pagesシークレット {#gitlab-pages-secret} + +GitLab Pagesのシークレットを生成します。これは、長さが32文字で、base64エンコードされている必要があります。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -gitlab-pages-secret --from-literal=shared_secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.pages.apiSecret.secret`設定によって参照されます。 + +### レジストリHTTPシークレット {#registry-http-secret} + +すべてのレジストリポッドで共有されるランダムな64文字の英数字キーを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -registry-httpsecret --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64 | base64) +``` + +このシークレットは、`global.registry.httpSecret.secret`設定によって参照されます。 + +### レジストリ通知シークレット {#registry-notification-secret} + +すべてのレジストリポッドとGitLab webserviceポッドで共有されるランダムな32文字の英数字キーを生成します。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -registry-notification --from-literal=secret=[\"$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32)\"] +``` + +このシークレットは、`global.registry.notificationSecret.secret`設定によって参照されます。 + +### Praefect DBパスワード {#praefect-db-password} + +ランダムな64文字の英数字パスワードを生成します。``をリリース名に置き換えます: + +```shell +kubectl create secret generic -praefect-dbsecret \ + --from-literal=secret=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 64) \ +``` + +このシークレットは、`global.praefect.dbSecret`設定によって参照されます。 + +## 外部サービス {#external-services} + +一部のチャートには、自動的に生成できない機能を有効にするための追加のシークレットがあります。 + +### OmniAuth {#omniauth} + +デプロイされたGitLabで[OmniAuthプロバイダー](https://docs.gitlab.com/integration/omniauth/)の使用を有効にするには、[Globalsチャートの手順](../charts/globals.md#omniauth)に従ってください + +### LDAPパスワード {#ldap-password} + +LDAPサーバーに接続するためにパスワード認証が必要な場合は、パスワードをKubernetesシークレットに格納する必要があります。 + +```shell +kubectl create secret generic ldap-main-password --from-literal=password=yourpasswordhere +``` + +次に、`--set global.appConfig.ldap.servers.main.password.secret=ldap-main-password`を使用して、パスワードを構成に挿入します。 + +{{< alert type="note" >}} + +Helmプロパティを構成するときは、_実際のパスワード_ではなく、`Secret`名を使用してください。 + +{{< /alert >}} + +### SMTPパスワード {#smtp-password} + +認証を必要とするSMTPサーバーを使用している場合は、パスワードをKubernetesシークレットに格納します。 + +```shell +kubectl create secret generic smtp-password --from-literal=password=yourpasswordhere +``` + +次に、Helmコマンドで`--set global.smtp.password.secret=smtp-password`を使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成するときは、_実際のパスワード_ではなく、`Secret`名を使用してください。 + +{{< /alert >}} + +### 受信メール用IMAPパスワード {#imap-password-for-incoming-emails} + +GitLabは、アプリのパスワード、トークン、IMAPパスワードなどの認証文字列を使用して受信メールにアクセスします。 + +[GitLab受信メールのドキュメントでメールプロバイダーを検索](https://docs.gitlab.com/administration/incoming_email/)し、必要な認証文字列をKubernetesシークレットとして設定します。 + +```shell +kubectl create secret generic incoming-email-password --from-literal="password=auth_string_for_your_provider_here" +``` + +次に、[ドキュメント内](command-line-options.md#incoming-email-configuration)で指定されている他の必要な設定とともに、Helmコマンドで`--set global.appConfig.incomingEmail.password.secret=incoming-email-password`を使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成するときは、_実際のパスワード_ではなく、`Secret`名を使用してください。 + +{{< /alert >}} + +### Service Deskメール用IMAPパスワード {#imap-password-for-service-desk-emails} + +GitLabは、アプリのパスワード、トークン、IMAPパスワードなどの認証文字列を使用して[Service Deskメール](https://docs.gitlab.com/user/project/service_desk/configure/#custom-email-address)にアクセスします。 + +[GitLab受信メールのドキュメントでメールプロバイダーを検索](https://docs.gitlab.com/administration/incoming_email/)し、必要な認証文字列をKubernetesシークレットとして設定します。 + +```shell +kubectl create secret generic service-desk-email-password --from-literal="password=auth_string_for_your_provider_here" +``` + +次に、[ドキュメント内](command-line-options.md#service-desk-email-configuration)で指定されている他の必要な設定とともに、Helmコマンドで`--set global.appConfig.serviceDeskEmail.password.secret=service-desk-email-password`を使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成するときは、_実際のパスワード_ではなく、`Secret`名を使用してください。 + +{{< /alert >}} + +### GitLab受信メール認証トークン {#gitlab-incoming-email-auth-token} + +受信メールがWebhook配信メソッドを使用するように構成されている場合、mail_roomサービスとwebserviceの間に共有シークレットが必要です。これは、長さが32文字で、base64エンコードされている必要があります。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -incoming-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.incomingEmail.authToken`設定によって参照されます。 + +### GitLab Service Deskメール認証トークン {#gitlab-service-desk-email-auth-token} + +Service DeskメールがWebhook配信メソッドを使用するように構成されている場合、mail_roomサービスとwebserviceの間に共有シークレットが必要です。これは、長さが32文字で、base64エンコードされている必要があります。``をリリース名に置き換えます。 + +```shell +kubectl create secret generic -service-desk-email-auth-token --from-literal=authToken=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +``` + +このシークレットは、`global.serviceDeskEmail.authToken`設定によって参照されます。 + +### Zoekt Basic認証パスワード {#zoekt-basic-auth-password} + +シークレットを自動生成するようにGitLabチャートに任せることも、このシークレットを手動で作成することもできます（``をリリースの名前に置き換えてください）。 + +```shell +password=$(head -c 512 /dev/urandom | LC_CTYPE=C tr -cd 'a-zA-Z0-9' | head -c 32 | base64) +kubectl create secret generic -zoekt-basicauth --from-literal=gitlab_username=gitlab --from-literal=gitlab_password="$password" +``` + +このシークレットは、`gitlab.zoekt.gateway.basicAuth.secretName`設定によって参照されます。 + +### 受信メール用のMicrosoft Graphクライアントシークレット {#microsoft-graph-client-secret-for-incoming-emails} + +[受信](https://docs.gitlab.com/administration/incoming_email/)メールへのアクセスをGitLabに許可するには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します。 + +```shell +kubectl create secret generic incoming-email-client-secret --from-literal=secret=your-secret-here +``` + +次に、`--set global.appConfig.incomingEmail.clientSecret.secret=incoming-email-client-secret`を[ドキュメント](command-line-options.md#incoming-email-configuration)に指定されている他の必要な設定とともに、Helmコマンドで使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成する際は、`Secret`名を使用し、_実際のパスワード_は使用しないでください。 + +{{< /alert >}} + +### サービスデスクメール用のMicrosoft Graphクライアントシークレット {#microsoft-graph-client-secret-for-service-desk-emails} + +[サービスデスク](https://docs.gitlab.com/user/project/service_desk/configure/#custom-email-address)メールへのアクセスをGitLabに許可するには、IMAPアカウントのパスワードをKubernetesのシークレットに保存します。 + +```shell +kubectl create secret generic service-desk-email-client-secret --from-literal=secret=your-secret-here +``` + +次に、`--set global.appConfig.serviceDeskEmail.clientSecret.secret=service-desk-email-client-secret`を[ドキュメント](command-line-options.md#service-desk-email-configuration)に指定されている他の必要な設定とともに、Helmコマンドで使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成する際は、`Secret`名を使用し、_実際のパスワード_は使用しないでください。 + +{{< /alert >}} + +### 送信メール用のMicrosoft Graphクライアントシークレット {#microsoft-graph-client-secret-for-outgoing-emails} + +Kubernetesのシークレットにパスワードを保存します。 + +```shell +kubectl create secret generic microsoft-graph-mailer-client-secret --from-literal=secret=your-secret-here +``` + +次に、`--set global.appConfig.microsoft_graph_mailer.client_secret.secret=microsoft-graph-mailer-client-secret`をHelmコマンドで使用します。 + +{{< alert type="note" >}} + +Helmプロパティを構成する際は、`Secret`名を使用し、_実際のパスワード_は使用しないでください。 + +{{< /alert >}} + +### S/MIME証明書 {#smime-certificate} + +[送信](https://en.wikipedia.org/wiki/S/MIME)メールメッセージは、S/MIME標準を使用してデジタル署名できます。S/MIME証明書は、TLSタイプのシークレットとしてKubernetesのシークレットに保存する必要があります。 + +```shell +kubectl create secret tls smime-certificate --key=file.key --cert file.crt +``` + +不透明型として既存のシークレットがある場合は、`global.email.smime.keyName`および`global.email.smime.certName`の値を、特定のシークレットに合わせて調整する必要があります。 + +S/MIME設定は、`values.yaml`ファイルまたはコマンドラインで設定できます。`--set global.email.smime.enabled=true`を使用してS/MIMEを有効にし、`--set global.email.smime.secretName=smime-certificate`を使用してS/MIME証明書を含むシークレットを指定します。 + +### スマートカード認証 {#smartcard-authentication} + +[スマートカード](https://docs.gitlab.com/administration/auth/smartcard/)認証では、カスタム公開認証局（CA）を使用してクライアント証明書に署名します。クライアント証明書が有効かどうかをVerifyするために、このカスタムCAの証明書をWebサービスのポッドにデプロイする必要があります。これはK8sのシークレットとして提供されます。 + +```shell +kubectl create secret generic --from-file=ca.crt= +``` + +証明書が保存されているシークレット内のキー名は、必ず`ca.crt`にしてください。 + +### OAuthインテグレーション {#oauth-integration} + +GitLab PagesなどのさまざまなサービスのOAuthインテグレーションを構成するには、OAuth認証情報を含むシークレットが必要です。このシークレットには、アプリID（`appid`キーにデフォルトで格納）と、アプリシークレット（`appsecret`キーにデフォルトで格納）が含まれている必要があり、どちらも英数字の文字列で、少なくとも64文字の長さであることが推奨されます。 + +```shell +kubectl create secret generic oauth-gitlab-pages-secret --from-literal=appid= --from-literal=appsecret= +``` + +このシークレットは、`global.oauth..secret`設定を使用して指定できます。`appid`および`appsecret`以外のキーを使用する場合は、`global.oauth..appIdKey`および`global.oauth..appSecretKey`設定を使用して指定できます。 + +## 次の手順 {#next-steps} + +すべての[シークレット](deployment.md)を生成および保存したら、GitLabのデプロイに進むことができます。 + +## シークレットのローテーション {#rotating-secrets} + +セキュリティ上の目的で必要な場合は、シークレットをローテーションできます。 + +1. [現在のシークレットをバックアップ](../backup-restore/backup.md#back-up-the-secrets)します。 +1. 便宜上、ローテーションする各シークレットについて、`-v2` (`gitlab-shell-host-keys-v2`など) というサフィックスが付いた新しい[シークレット](#manual-secret-creation-optional)を手動シークレットCreateの手順に従ってCreateします。 +1. 新しいシークレット名を指すように、`values.yaml`ファイル内のシークレット キーを更新します。ほとんどのシークレット名は、[手動](#manual-secret-creation-optional)シークレットCreateセクションのそれぞれのシークレットで説明されています。 +1. 更新された`values.yaml`ファイルを使用して、GitLabチャート リリースをアップグレードします。 +1. [PostgreSQL](#changing-the-postgresql-password-for-the-bundled-postgresql-subchart)のシークレットをローテーションする場合は、ローテーションを完了するための追加の手順があります。 +1. GitLabが期待どおりに動作していることを確認します。その場合は、古いシークレットを削除しても安全です。 diff --git a/doc-locale/ja-jp/installation/storage.md b/doc-locale/ja-jp/installation/storage.md new file mode 100644 index 0000000000..5dd99d20c8 --- /dev/null +++ b/doc-locale/ja-jp/installation/storage.md @@ -0,0 +1,156 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのストレージを設定 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabチャート内の以下のアプリケーションは、状態を保持するために永続ストレージを必要とします。 + +- [Gitaly](../charts/gitlab/gitaly/_index.md) (Gitリポジトリを永続化) +- [PostgreSQL](https://github.com/bitnami/charts/tree/main/bitnami/postgresql) (GitLabデータベースデータを永続化) +- [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) (GitLabジョブデータを永続化) +- [MinIO](../charts/minio/_index.md) (オブジェクトストレージデータを永続化) + +管理者は、[動的](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic)または[静的](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static)ボリューム[プロビジョニング](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static)を使用して、このストレージを[プロビジョニング](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static)できます。 + +> **重要**:事前計画により、インストール後の追加ストレージ移行タスクを最小限に抑える。最初のデプロイ後に加えられた変更では、`helm upgrade`を実行する前に、既存のKubernetesオブジェクトを手動で編集する必要があります。 + +## 一般的なインストール動作 {#typical-installation-behavior} + +インストーラーは、[デフォルト](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic)のストレージクラスと[動的ボリュームプロビジョニング](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic)を使用してストレージを作成します。アプリケーションは、[Persistent Volume Claim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)を通じてこのストレージに接続します。管理者は、利用可能な場合は[静的ボリュームプロビジョニング](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#dynamic)の代わりに[動的ボリュームプロビジョニング](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#static)を使用することをお勧めします。 + +> 管理者は、`kubectl get storageclass`を使用して本番環境のデフォルトのストレージクラスを特定し、`kubectl describe storageclass *STORAGE_CLASS_NAME*`を使用して調べます。Amazon EKSなど、一部のプロバイダーはデフォルトのストレージクラスを提供していません。 + +## クラスター・ストレージの設定 {#configuring-cluster-storage} + +### 推奨事項 {#recommendations} + +デフォルトのストレージクラスは以下である必要があります。 + +- 利用可能な場合は、高速SSDストレージを使用する +- `reclaimPolicy`を`Retain`に設定 + +> `reclaimPolicy`が`Retain`に設定されていない状態でGitLabをアンインストールすると、自動化されたジョブがボリューム、ディスク、データを完全に削除できます。一部のプラットフォームでは、`reclaimPolicy`のデフォルトを`Delete`に設定しています。`gitaly`永続ボリュームクレームは、[StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)に属しているため、このルールに従いません。 + +### 最小限のストレージクラスの構成 {#minimal-storage-class-configurations} + +次の`YAML`構成は、GitLabのカスタムストレージクラスを作成するために必要な最小限の要件を提供します。`CUSTOM_STORAGE_CLASS_NAME`を、ターゲットインストール環境に合った値に置き換えます。 + +- [Google Cloud](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gke_storage_class.yml)上のGKEの[サンプル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gke_storage_class.yml)ストレージクラス +- [Amazon Web Services](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/eks_storage_class.yml)上のEKSの[サンプル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/eks_storage_class.yml)ストレージクラス + +> Amazon EKSでは、ノードの作成が常にポッドと同じゾーン内にあるとは限らないという動作が確認されています。上記の***zone***パラメータを設定すると、リスクが*緩和*されます。 + +### カスタムストレージクラスの使用 {#using-the-custom-storage-class} + +カスタムストレージクラスをクラスターデフォルトに設定すると、すべての動的プロビジョニングに使用されます。 + +```shell +kubectl patch storageclass CUSTOM_STORAGE_CLASS_NAME -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' +``` + +または、インストールの際に、カスタムストレージクラスとその他のオプションをサービスごとにHelmに提供できます。提供されている[設定ファイル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/helm_options.yml)を表示し、ご使用の[環境](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/helm_options.yml)に合わせて変更してください。 + +```shell +helm install -upgrade gitlab gitlab/gitlab -f HELM_OPTIONS_YAML_FILE +``` + +詳細な情報と追加の永続オプションについては、以下のリンクを参照してください。 + +- [Gitaly](../charts/gitlab/gitaly/_index.md#git-repository-persistence) [永続](../charts/gitlab/gitaly/_index.md#git-repository-persistence)設定 +- [MinIO](../charts/minio/_index.md#persistence) [永続](../charts/minio/_index.md#persistence)設定 +- [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis#persistence) [永続](https://github.com/bitnami/charts/tree/main/bitnami/redis#persistence)設定 +- [アップストリーム](https://github.com/bitnami/charts/tree/main/bitnami/postgresql#configuration-and-installation-details)PostgreSQLチャート設定 + +> **メモ**:高度な永続オプションの一部は、PostgreSQLとその他とで異なるため、変更を行う前に、それぞれのドキュメントを確認することが重要です。 + +## 静的ボリュームプロビジョニングの使用 {#using-static-volume-provisioning} + +動的ボリュームプロビジョニングが推奨されますが、一部のクラスターまたは環境ではサポートされていない場合があります。管理者は、[Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes)を手動で作成する必要があります。 + +### Google GKEの使用 {#using-google-gke} + +1. クラスター内に[永続](https://kubernetes.io/docs/concepts/storage/volumes/#creating-a-pd)ディスクを作成します。 + +```shell +gcloud compute disks create --size=50GB --zone=*GKE_ZONE* *DISK_VOLUME_NAME* +``` + +1. [サンプル`YAML`設定](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gke_pv_example.yml)を変更したら、[Persistent Volume](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gke_pv_example.yml)を作成します。 + +```shell +kubectl create -f *PV_YAML_FILE* +``` + +### Amazon EKSの使用 {#using-amazon-eks} + +{{< alert type="note" >}} + +複数の[ゾーン](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)に[デプロイ](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)する[必要](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)がある[場合](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)は、ストレージソリューションを定義する[際](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)に、[Amazon](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)独自のストレージクラスに関する[ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)を[レビュー](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)する[必要](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)があります。 + +{{< /alert >}} + +1. クラスター内に[永続](https://kubernetes.io/docs/concepts/storage/volumes/#creating-an-ebs-volume)ディスクを作成します。 + +```shell +aws ec2 create-volume --availability-zone=*AWS_ZONE* --size=10 --volume-type=gp2 +``` + +1. [サンプル`YAML`設定](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/eks_pv_example.yml)を変更したら、[Persistent Volume](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/eks_pv_example.yml)を作成します。 + +```shell +kubectl create -f *PV_YAML_FILE* +``` + +### PersistentVolumeClaimの手動作成 {#manually-creating-persistentvolumeclaims} + +[Gitaly](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)サービスは、[StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)を使用して[デプロイ](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)します。[PersistentVolumeClaim](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)は、正しく認識されて使用されるように、次の命名規則を使用して作成します。 + +```plaintext +- +``` + +Gitalyの`mount-name`は`repo-data`です。StatefulSetポッド名は、以下を使用して作成されます。 + +```plaintext +- +``` + +GitLabチャートは、以下を使用して`statefulset-name`を決定します。 + +```plaintext +- +``` + +Gitaly PersistentVolumeClaimの正しい名前は、`repo-data-gitlab-gitaly-0`です。 + +> **メモ**:複数の仮想ストレージでPraefectを使用する場合、定義された仮想ストレージごとに、Gitalyレプリカごとに1つのPersistentVolumeClaimが必要になります。例えば、`default`および`vs2`仮想ストレージが定義されていて、それぞれに2つのレプリカがある場合、次のPersistentVolumeClaimが必要です。 +> +> - `repo-data-gitlab-gitaly-default-0` +> - `repo-data-gitlab-gitaly-default-1` +> - `repo-data-gitlab-gitaly-vs2-0` +> - `repo-data-gitlab-gitaly-vs2-1` + +ご使用の[環境](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gitaly_persistent_volume_claim.yml)に合わせて[サンプル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gitaly_persistent_volume_claim.yml) [YAML](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gitaly_persistent_volume_claim.yml)設定を修正し、`helm`を[実行する](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/gitaly_persistent_volume_claim.yml)際に参照してください。 + +> [StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)を使用しないその他のサービスでは、管理者は`volumeName`を[設定](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)に提供できます。このチャートは、[ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)クレームの作成を引き続き行い、手動で作成されたボリュームへのバインドを試みます。含まれる各アプリケーションについて、チャートのドキュメントを確認してください。 +> +> [ほとんど](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/use_manual_volumes.yml)の[場合](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/use_manual_volumes.yml)、手動で作成されたディスクボリュームを使用するサービスのみを保持して、[サンプル](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/storage/use_manual_volumes.yml)YAML設定 + +## インストール後にストレージを変更する {#making-changes-to-storage-after-installation} + +初期インストール後、新しいボリュームへの移行、ディスクサイズの変更などのストレージ変更では、Helmアップグレードコマンドの外部でKubernetesオブジェクトを編集する必要があります。 + +[永続ボリュームドキュメント](../advanced/persistent-volumes/_index.md)の管理 + +## オプションのボリューム {#optional-volumes} + +大規模なインストールでは、バックアップ/リストアを機能させるために、Toolboxに永続ストレージを追加する必要がある場合があります。これを行う[方法](../backup-restore/_index.md#pod-eviction-issues)については、[トラブルシューティングドキュメント](../backup-restore/_index.md#pod-eviction-issues)を参照してください。 diff --git a/doc-locale/ja-jp/installation/tls.md b/doc-locale/ja-jp/installation/tls.md new file mode 100644 index 0000000000..ad7e602295 --- /dev/null +++ b/doc-locale/ja-jp/installation/tls.md @@ -0,0 +1,177 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのTLSを設定 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +このチャートは、NGINX Ingressコントローラーを使用してTLS終端を実行できます。デプロイメント用のTLS証明書を取得する方法を選択できます。詳細については、[グローバルIngress設定](../charts/globals.md#configure-ingress-settings)を参照してください。 + +## オプション1：cert-managerとLet's Encrypt {#option-1-cert-manager-and-lets-encrypt} + +Let's Encryptは、無料で自動化されたオープンな公開認証局（CA）です。証明書は、さまざまなツールを使用して自動的にリクエストできます。このチャートは、一般的な選択肢である[cert-manager](https://github.com/cert-manager/cert-manager)と統合する準備ができています。 + +*すでにcert-managerを使用している場合*、`global.ingress.annotations`を使用して、cert-managerデプロイメントに[適切なアノテーション](https://cert-manager.io/docs/usage/ingress/#supported-annotations)を設定できます。 + +*クラスターにcert-managerがまだインストールされていない場合*、このチャートの依存関係としてインストールして設定できます。 + +### 内部cert-managerとIssuer {#internal-cert-manager-and-issuer} + +```shell +helm repo update +helm dep update +helm install gitlab gitlab/gitlab \ + --set certmanager-issuer.email=you@example.com +``` + +`cert-manager`のインストールは、`installCertmanager`設定によって制御され、チャートでの使用は、`global.ingress.configureCertmanager`設定によって制御されます。これらは両方ともデフォルトで`true`であるため、デフォルトでは発行者のメールのみを提供する必要があります。 + +### 外部cert-managerと内部Issuer {#external-cert-manager-and-internal-issuer} + +外部`cert-manager`を利用できますが、Issuerをこのチャートの一部として提供します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set installCertmanager=false \ + --set certmanager-issuer.email=you@example.com \ + --set global.ingress.annotations."kubernetes\.io/tls-acme"=true +``` + +### 外部cert-managerとIssuer（外部） {#external-cert-manager-and-issuer-external} + +外部`cert-manager`と`Issuer`リソースを利用するには、自己署名証明書がアクティブにならないように、いくつかの項目を提供する必要があります。 + +1. 外部`cert-manager`をアクティブにするためのアノテーション（詳細については[ドキュメント](https://cert-manager.io/docs/usage/ingress/#supported-annotations)を参照してください） +1. 各サービスのTLSシークレットの名前（これにより[自己署名動作](#option-4-use-auto-generated-self-signed-wildcard-certificate)が無効になります） + +```shell +helm install gitlab gitlab/gitlab \ + --set installCertmanager=false \ + --set global.ingress.configureCertmanager=false \ + --set global.ingress.annotations."kubernetes\.io/tls-acme"=true \ + --set gitlab.webservice.ingress.tls.secretName=RELEASE-gitlab-tls \ + --set registry.ingress.tls.secretName=RELEASE-registry-tls \ + --set minio.ingress.tls.secretName=RELEASE-minio-tls \ + --set gitlab.kas.ingress.tls.secretName=RELEASE-kas-tls +``` + +## オプション2:独自のワイルドカード証明書を使用する {#option-2-use-your-own-wildcard-certificate} + +完全なチェーン証明書とキーを`Secret`としてクラスターに追加します（例：）。 + +```shell +kubectl create secret tls --cert= --key= +``` + +次のオプションを含めます + +```shell +helm install gitlab gitlab/gitlab \ + --set installCertmanager=false \ + --set global.ingress.configureCertmanager=false \ + --set global.ingress.tls.secretName= +``` + +### AWS ACMを使用して証明書を管理する {#use-aws-acm-to-manage-certificates} + +AWS ACMを使用してワイルドカード証明書を作成している場合、ACM証明書はダウンロードできないため、シークレット経由で指定することはできません。代わりに、`nginx-ingress.controller.service.annotations`を使用して指定します。 + +```yaml +nginx-ingress: + controller: + service: + annotations: + ... + service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:{region}:{user id}:certificate/{id} +``` + +## オプション3:サービスごとに個別の証明書を使用する {#option-3-use-individual-certificate-per-service} + +完全なチェーン証明書をシークレットとしてクラスターに追加し、それらのシークレット名を各Ingressに渡します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set installCertmanager=false \ + --set global.ingress.configureCertmanager=false \ + --set global.ingress.tls.enabled=true \ + --set gitlab.webservice.ingress.tls.secretName=RELEASE-gitlab-tls \ + --set registry.ingress.tls.secretName=RELEASE-registry-tls \ + --set minio.ingress.tls.secretName=RELEASE-minio-tls \ + --set gitlab.kas.ingress.tls.secretName=RELEASE-kas-tls +``` + +{{< alert type="note" >}} + +GitLabインスタンスが他のサービスと通信するように設定している場合は、これらのサービスの[証明書チェーン](../charts/globals.md#custom-certificate-authorities)をHelm Chartを介してGitLabに提供する必要がある場合があります。 + +{{< /alert >}} + +## オプション4:自動生成された自己署名ワイルドカード証明書を使用する {#option-4-use-auto-generated-self-signed-wildcard-certificate} + +これらのチャートは、自動生成された自己署名ワイルドカード証明書を提供する機能も提供します。これは、Let's Encryptがオプションではない環境で役立ちますが、SSLによるセキュリティは依然として必要です。この機能は、[shared-secrets](../charts/shared-secrets.md)ジョブによって提供されます。 + +{{< alert type="note" >}} + +`gitlab-runner`チャートは、自己署名証明書では適切に機能しません。以下に示すように、無効にすることをお勧めします。 + +{{< /alert >}} + +{{< alert type="note" >}} + +`--set global.ingres.tls.enabled=false`のように、TLSをグローバルに無効にしている場合、自己署名証明書は生成されません。 + +{{< /alert >}} + +```shell +helm install gitlab gitlab/gitlab \ + --set installCertmanager=false \ + --set global.ingress.configureCertmanager=false \ + --set gitlab-runner.install=false +``` + +次に、`shared-secrets`ジョブは、CA証明書、ワイルドカード証明書、および外部からアクセス可能なすべてのサービスで使用する証明書チェーンを生成します。これらを含むシークレットは、`RELEASE-wildcard-tls`、`RELEASE-wildcard-tls-ca`、および`RELEASE-wildcard-tls-chain`になります。`RELEASE-wildcard-tls-ca`には、デプロイされたGitLabインスタンスにアクセスするユーザーとシステムに配布できるパブリックCA証明書が含まれています。`RELEASE-wildcard-tls-chain`には、CA証明書とワイルドカード証明書の両方が含まれており、`gitlab-runner.certsSecretName=RELEASE-wildcard-tls-chain`を介してGitLab Runnerに直接使用することもできます。 + +## GitLab PagesのTLS要件 {#tls-requirement-for-gitlab-pages} + +[TLSサポートを備えたGitLab Pages](https://docs.gitlab.com/administration/pages/#wildcard-domains-with-tls-support)の場合、`*.`（``のデフォルト値は`pages.`）に適用可能なワイルドカード証明書が必要です。 + +ワイルドカード証明書が必要なため、cert-managerとLet's Encryptによって自動的に作成することはできません。したがって、cert-managerは、デフォルトではGitLab Pagesに対して無効になっているため（`gitlab-pages.ingress.configureCertmanager`経由）、ワイルドカード証明書を含む独自のk8sシークレットを提供する必要があります。`global.ingress.annotations`を使用して構成された外部cert-managerがある場合は、`gitlab-pages.ingress.annotations`でそのようなアノテーションをオーバーライドすることもできます。 + +デフォルトでは、このシークレットの名前は`-pages-tls`です。`gitlab.gitlab-pages.ingress.tls.secretName`設定を使用して、別の名前を指定できます。 + +```shell +helm install gitlab gitlab/gitlab \ + --set global.pages.enabled=true \ + --set gitlab.gitlab-pages.ingress.tls.secretName= +``` + +## トラブルシューティング {#troubleshooting} + +このセクションでは、発生する可能性のある問題の考えられる解決策について説明します。 + +### SSL終端エラー {#ssl-termination-errors} + +Let's EncryptをTLSプロバイダーとして使用していて、証明書関連のエラーが発生している場合は、これをデバッグするいくつかのオプションがあります。 + +1. 考えられるエラーがないか、[letsdebug](https://letsdebug.net/)でドメインを確認してください。 +1. letsdebugがエラーを返さない場合は、cert-managerに関連する問題があるかどうかを確認してください。 + + ```shell + kubectl describe certificate,order,challenge --all-namespaces + ``` + + エラーが表示された場合は、証明書オブジェクトを削除して、新しい証明書のリクエストを強制してみてください。 + +1. 上記の方法で解決しない場合は、[既存のcert-managerリソース](https://cert-manager.io/docs/installation/kubectl/#uninstalling)を削除して、cert-managerを再インストールすることを検討してください。内部cert-managerを使用している場合は、名前に`certmanager`を含むデプロイメントを削除し、Helm Chartを再インストールします。たとえば、`gitlab`という名前のリリースを想定します。 + + ```shell + kubectl -n delete deployment gitlab-certmanager gitlab-certmanager-cainjector gitlab-certmanager-webhook + helm upgrade --install -n gitlab gitlab/gitlab + ``` diff --git a/doc-locale/ja-jp/installation/tools.md b/doc-locale/ja-jp/installation/tools.md new file mode 100644 index 0000000000..6d98a0dd37 --- /dev/null +++ b/doc-locale/ja-jp/installation/tools.md @@ -0,0 +1,238 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートの前提要件 +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +KubernetesクラスターにGitLabをデプロイする前に、以下の前提要件をインストールし、インストール時に使用するオプションを決定します。 + +## 前提要件 {#prerequisites} + +### kubectl {#kubectl} + +[Kubernetesのドキュメント](https://kubernetes.io/docs/tasks/tools/#kubectl)に従って、`kubectl`をインストールします。インストールするのバージョンは、クラスターで実行されているバージョンの[マイナーリリース1つ以内](https://kubernetes.io/releases/version-skew-policy/#kubectl)である必要があります。 + +### Helm {#helm} + +[Helmのドキュメント](https://helm.sh/docs/intro/install/)に従って、Helm v3.10.3以降をインストールします。 + +### PostgreSQL {#postgresql} + +デフォルトでは、GitLabチャートには、[`bitnami/PostgreSQL`](https://artifacthub.io/packages/helm/bitnami/postgresql)によって提供される、クラスター内PostgreSQLのデプロイメントが含まれています。このデプロイメントはトライアル目的のみであり、**本番環境での使用は推奨されません**。 + +[外部の本番環境対応PostgreSQLインスタンス](../advanced/external-db/_index.md)をセットアップする必要があります。推奨されるデフォルトのバージョン: + +- PostgreSQL 13（GitLabチャート6.0以降）。 +- PostgreSQL 14（GitLabチャート8.0以降）。 + +GitLabチャート4.0.0の時点では、レプリケーションは内部で利用可能ですが、デフォルトでは有効になっていません。このような機能は、GitLabによって負荷テストされていません。 + +### Redis {#redis} + +デフォルトでは、GitLabチャートには、[`bitnami/Redis`](https://artifacthub.io/packages/helm/bitnami/redis)によって提供される、クラスター内Redisのデプロイメントが含まれています。このデプロイメントはトライアル目的のみであり、**本番環境での使用は推奨されません**。 + +[外部の本番環境対応Redisインスタンス](../advanced/external-redis/_index.md)をセットアップする必要があります。利用可能なすべての設定については、[Redisグローバルドキュメント](../charts/globals.md#configure-redis-settings)を参照してください。 + +GitLabチャート4.0.0の時点では、レプリケーションは内部で利用可能ですが、デフォルトでは有効になっていません。このような機能は、GitLabによって負荷テストされていません。 + +### Gitaly {#gitaly} + +デフォルトでは、GitLabチャートには、クラスター内Gitalyのデプロイメントが含まれています。本番環境の場合、KubernetesでのGitalyの実行はサポートされていません。[Gitalyは、従来の仮想マシンでのみサポートされています](https://docs.gitlab.com/administration/reference_architectures/#stateful-components-in-kubernetes)。 + +[外部の本番環境対応Gitalyインスタンス](../advanced/external-gitaly/_index.md)をセットアップする必要があります。利用可能なすべての設定については、[Gitalyグローバルドキュメント](../charts/globals.md#configure-gitaly-settings)を参照してください。 + +## その他のオプションの決定 {#decide-on-other-options} + +GitLabをデプロイする際、`helm install`で次のオプションを使用します。 + +### シークレット {#secrets} + +SSH鍵などのシークレットを作成する必要があります。デフォルトでは、これらのシークレットはデプロイメント中に自動的に生成されますが、指定する場合は、[シークレットドキュメント](secrets.md)に従ってください。 + +### ネットワーキングとDNS {#networking-and-dns} + +デフォルトでは、サービスを公開するために、GitLabは`Ingress`オブジェクトで設定された名前ベースの仮想サーバーを使用します。これらのオブジェクトは、`type: LoadBalancer`のKubernetes `Service`オブジェクトです。 + +チャートの適切なIPアドレスに`gitlab`、`registry`、および`minio`（有効な場合）を解決するレコードを含むドメインを指定する必要があります。 + +次に例を示します。`helm install`で以下を使用します。 + +```shell +--set global.hosts.domain=example.com +``` + +カスタムドメインのサポートを有効にすると、デフォルトで``である`*.`サブドメインは`pages.`になります。ドメインは、`--set global.pages.externalHttp`または`--set global.pages.externalHttps`によってPagesに割り当てられた外部IPに解決されます。 + +カスタムドメインを使用するには、GitLab Pagesは、カスタムドメインを対応する`.`ドメインにポイントするCNAMEレコードを使用できます。 + +#### `external-dns`を使用した動的IPアドレス {#dynamic-ip-addresses-with-external-dns} + +[`external-dns`](https://github.com/kubernetes-sigs/external-dns)のような自動DNS登録サービスを使用する場合は、GitLabに追加のDNS設定は必要ありません。ただし、`external-dns`をクラスターにデプロイする必要があります。プロジェクトページ[には、](https://github.com/kubernetes-sigs/external-dns#deploying-to-a-cluster)サポートされているプロバイダーごとに包括的なガイドがあります。 + +{{< alert type="note" >}} + +GitLab Pagesのカスタムドメインのサポートを有効にした場合、`external-dns`はPagesドメイン（デフォルトでは`pages.`）では機能しなくなります。Pages専用の外部IPアドレスにドメインをポイントするように、DNSエントリを手動で設定する必要があります。 + +{{< /alert >}} + +提供されているスクリプトを使用して[GKEクラスター](cloud/gke.md)をプロビジョニングする場合、`external-dns`はクラスターに自動的にインストールされます。 + +#### 静的IPアドレス {#static-ip-addresses} + +DNSレコードを手動で設定する場合は、すべて静的IPアドレスを指す必要があります。たとえば、`example.com`を選択し、`10.10.10.10`の静的IPアドレスがある場合、`gitlab.example.com`、`registry.example.com`、および`minio.example.com`（MinIOを使用している場合）はすべて`10.10.10.10`に解決される必要があります。 + +GKEを使用している場合は、[外部IPとDNSエントリの作成](cloud/gke.md#creating-the-external-ip)の詳細をお読みください。このプロセスの詳細については、クラウドまたはDNSプロバイダーのドキュメントを参照してください。 + +次に例を示します。`helm install`で以下を使用します。 + +```shell +--set global.hosts.externalIP=10.10.10.10 +``` + +#### Istioプロトコル選択との互換性 {#compatibility-with-istio-protocol-selection} + +サービスポート名は、Istioの[明示的なポート選択](https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection)と互換性のある規則に従います。たとえば、`tls-gitaly`や`https-metrics`のように、`-`のように見えます。 + +GitalyとKASはgRPCを使用しますが、[Issue #3822](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3822)と[Issue #4908](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/4908)の発見により、代わりに`tcp`プレフィックスを使用することに注意してください。 + +### 永続性 {#persistence} + +デフォルトでは、GitLabチャートは、動的プロビジョナーが基盤となる永続ボリュームを作成することを期待して、ボリューム要求を作成します。`storageClass`をカスタマイズするか、手動でボリュームを作成して割り当てる場合は、[ストレージドキュメント](storage.md)を確認してください。 + +{{< alert type="note" >}} + +最初のデプロイ後、ストレージ設定を変更するには、Kubernetesオブジェクトを手動で編集する必要があります。したがって、ストレージの移行作業を余分に行わないように、本番環境インスタンスをデプロイする前に事前に計画しておくことをお勧めします。 + +{{< /alert >}} + +### TLS証明書 {#tls-certificates} + +TLS証明書を必要とするHTTPSでGitLabを実行する必要があります。デフォルトでは、GitLabチャートは無料のTLS証明書を取得するために[`cert-manager`](https://github.com/cert-manager/cert-manager)をインストールして設定します。 + +独自のワイルドカード証明書がある場合、または`cert-manager`が既にインストールされている場合、またはTLS証明書を取得する他の方法がある場合は、[TLSオプション](tls.md)の詳細をお読みください。 + +デフォルト設定では、TLS証明書を登録するためにメールアドレスを指定する必要があります。次に例を示します。`helm install`で以下を使用します。 + +```shell +--set certmanager-issuer.email=me@example.com +``` + +### Prometheus {#prometheus} + +KubernetesおよびGitLabチャートによって作成されたオブジェクトへのメトリクスの収集を制限するためにカスタマイズされた`prometheus.yml`ファイル以外に、[アップストリームPrometheusチャート](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#configuration)を使用し、独自のデフォルトからの値をオーバーライドしません。ただし、デフォルトでは、`alertmanager`、`node-exporter`、`pushgateway`、および`kube-stat-metrics`を無効にします。 + +`prometheus.yml`ファイルは、`gitlab.com/prometheus_scrape`アノテーションを持つリソースからメトリックを収集するようにPrometheusに指示します。さらに、`gitlab.com/prometheus_path`および`gitlab.com/prometheus_port`アノテーションを使用して、メトリクスの検出方法を設定できます。これらのアノテーションはそれぞれ、`prometheus.io/{scrape,path,port}`アノテーションに匹敵します。 + +PrometheusのインストールでGitLabアプリケーションを監視している場合、または監視する場合は、元のアノテーション`prometheus.io/*`が適切なポッドとサービスに引き続き追加されます。これにより、既存のユーザーのメトリクス収集の継続性が可能になり、デフォルトのPrometheus設定を使用して、GitLabアプリケーションメトリクスと、Kubernetesクラスターで実行されている他のアプリケーションの両方をキャプチャできます。 + +設定オプションの網羅的なリストについては、[アップストリームPrometheusチャートドキュメント](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#configuration)を参照し、要件チャートとしてこれを使用するため、それらが`prometheus`のサブキーであることを確認してください。 + +たとえば、永続ストレージのリクエストは、次のように制御できます。 + +```yaml +prometheus: + alertmanager: + enabled: false + persistentVolume: + enabled: false + size: 2Gi + prometheus-pushgateway: + enabled: false + persistentVolume: + enabled: false + size: 2Gi + server: + persistentVolume: + enabled: true + size: 8Gi +``` + +#### TLS対応エンドポイントをスクレイピングするようにPrometheusを設定する {#configure-prometheus-to-scrape-tls-enabled-endpoints} + +指定されたexporterがTLSを許可し、チャート設定がexporterのエンドポイントのTLS設定を公開する場合、PrometheusはTLS対応エンドポイントからメトリクスをスクレイピングするように設定できます。 + +Prometheus [スクレイプ設定](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)に[Kubernetesサービスディスカバリ](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config)とTLSを使用する場合、いくつかの注意事項があります。 + +- [ポッド](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#pod)および[サービスエンドポイント](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#endpoints)ディスカバリロールの場合、Prometheusはポッドの内部アドレスを使用して、スクレイプターゲットのアドレスを設定します。TLS証明書を検証するには、Prometheusは、メトリクスエンドポイント用に作成された証明書に設定された共通名（CN）を使用するか、サブジェクトの代替名（SAN）拡張機能に含まれる名前を使用して構成する必要があります。名前は解決する必要はなく、[有効なDNS名](https://datatracker.ietf.org/doc/html/rfc1034#section-3.1)である任意の文字列にすることができます。 +- exporterのエンドポイントに使用される証明書が自己署名されているか、Prometheusベースイメージに存在しない場合、Prometheusポッドはexporterのエンドポイントに使用される証明書に署名した認証局（CA）の証明書をマウントする必要があります。Prometheusは、[ベースイメージ](https://github.com/prometheus/busybox)内のDebianからの`ca-bundle`を使用します。 +- Prometheusは、スクレイプ設定のそれぞれに適用される[tls_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#tls_config)を使用して、これらの項目の両方を設定することをサポートしています。Prometheusには、ポッドアノテーションやその他の検出された属性に基づいてPrometheusターゲットラベルを設定するための堅牢な[relabel_config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config)メカニズムがありますが、`tls_config.server_name`および`tls_config.ca_file`を設定することは、`relabel_config`を使用して行うことはできません。詳細については、[このPrometheusプロジェクトイシュー](https://github.com/prometheus/prometheus/issues/4827)を参照してください。 + +これらの注意事項を考慮すると、最も単純な設定は、「名前」とをexporterエンドポイントに使用されるすべての証明書間で共有することです。 + +1. `tls_config.server_name`（たとえば、`metrics.gitlab`）に使用する単一の任意の名前を選択します。 +1. exporterエンドポイントをTLS暗号化するために使用される各証明書のSANリストにその名前を追加します。 +1. 同じからすべての証明書を発行します: + - 証明書をクラスターシークレットとして追加します。 + - [Prometheusチャート](https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml)の`extraSecretMounts:`設定を使用して、そのシークレットをPrometheusサーバーコンテナにマウントします。 + - Prometheus `scrape_config`の`tls_config.ca_file`としてそれを設定します。 + +[Prometheus TLS値の例](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/prometheus/values-tls.yaml)は、この共有設定の例を示しています: + +1. ポッド/エンドポイント`scrape_config`ロールの場合、`tls_config.server_name`を`metrics.gitlab`に設定します。 +1. `metrics.gitlab`がexporterエンドポイントに使用されるすべての証明書のSANリストに追加されていると仮定します。 +1. 証明書が、Prometheusチャートがデプロイされているのと同じネームスペースで作成された、シークレットキーも`metrics.gitlab.tls-ca`という名前の`metrics.gitlab.tls-ca`という名前のシークレットに追加されていると仮定します（たとえば、`kubectl create secret generic --namespace=gitlab metrics.gitlab.tls-ca --from-file=metrics.gitlab.tls-ca=./ca.pem`）。 +1. `extraSecretMounts:`エントリを使用して、その`metrics.gitlab.tls-ca`シークレットを`/etc/ssl/certs/metrics.gitlab.tls-ca`にマウントします。 +1. `tls_config.ca_file`を`/etc/ssl/certs/metrics.gitlab.tls-ca`に設定します。 + +#### Exporterエンドポイント {#exporter-endpoints} + +GitLabチャートに含まれるすべてのメトリクスエンドポイントがTLSをサポートしているわけではありません。エンドポイントがTLS対応可能で、TLS対応になっている場合は、`gitlab.com/prometheus_scheme: "https"`アノテーションと`prometheus.io/scheme: "https"`アノテーションも設定されます。これらのアノテーションは、`relabel_config`と組み合わせてPrometheus `__scheme__`ターゲットラベルを設定するために使用できます。[Prometheus TLSの値の例](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/examples/prometheus/values-tls.yaml)には、`gitlab.com/prometheus_scheme: "https"`アノテーションを使用して`__scheme__`をターゲットとする`relabel_config`が含まれています。 + +次のテーブルは、デプロイメント（またはGitalyとPraefectの両方を使用している場合:`gitlab.com/prometheus_scrape: true`アノテーションが適用されたStatefulSets）およびサービスエンドポイントを一覧表示します。 + +以下のドキュメントリンクで、コンポーネントがSANエントリの追加について言及している場合は、Prometheus `tls_config.server_name`に使用することにしたSANも必ず追加してください。 + +| サービス | メトリクスポート（デフォルト） | TLSをサポートしていますか？ | 注釈/ドキュメント/イシュー | +| --- | --- | --- | --- | +| [Gitaly](../charts/gitlab/gitaly/_index.md) | 9236 | はい | `global.gitaly.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-gitaly-tls`
[ドキュメント:TLS経由でのGitalyの実行](../charts/gitlab/gitaly/_index.md#running-gitaly-over-tls) | +| [GitLab Exporter](../charts/gitlab/gitlab-exporter/_index.md) | 9168 | はい | `gitlab.gitlab-exporter.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-gitlab-exporter-tls` | +| [GitLab Pages](../charts/gitlab/gitlab-pages/_index.md) | 9235 | はい | `gitlab.gitlab-pages.metrics.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-pages-metrics-tls`
[ドキュメント:一般設定](../charts/gitlab/gitlab-pages/_index.md#general-settings) | +| [GitLab Runner](../charts/gitlab/gitlab-runner/_index.md) | 9252 | いいえ | [イシュー - メトリクスエンドポイントへのTLSサポートの追加](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29176) | +| [GitLab Shell](../charts/gitlab/gitlab-shell/_index.md) | 9122 | いいえ | GitLab Shellメトリクスexporterは、[`gitlab-sshd`](https://docs.gitlab.com/administration/operations/gitlab_sshd/)を使用する場合にのみ有効になります。TLSを必要とする環境には、OpenSSHをお勧めします | +| [KAS](../charts/gitlab/kas/_index.md) | 8151 | はい | `global.kas.customConfig.observability.listen.certificate_file`および`global.kas.customConfig.observability.listen.key_file`オプションを使用して設定できます | +| [Praefect](../charts/gitlab/praefect/_index.md) | 9236 | はい | `global.praefect.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-praefect-tls`
[ドキュメント:TLS経由でのPraefectの実行](../charts/gitlab/praefect/_index.md#running-praefect-over-tls) | +| [レジストリ](../charts/registry/_index.md) | 5100 | はい | `registry.debug.tls.enabled=true`を使用して有効化
[ドキュメント:レジストリ - デバッグポートのTLSの設定](../charts/registry/_index.md#configuring-tls-for-the-debug-port) | +| [Sidekiq](../charts/gitlab/sidekiq/_index.md) | 3807 | はい | `gitlab.sidekiq.metrics.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-sidekiq-metrics-tls`
[ドキュメント:インストールコマンドラインオプション](../charts/gitlab/sidekiq/_index.md#installation-command-line-options) | +| [Webservice](../charts/gitlab/sidekiq/_index.md) | 8083 | はい | `gitlab.webservice.metrics.tls.enabled=true`を使用して有効化
デフォルトのシークレット:`RELEASE-webservice-metrics-tls`
[ドキュメント:インストールコマンドラインオプション](../charts/gitlab/webservice/_index.md#installation-command-line-options) | +| [Ingress-NGINX](../charts/nginx/_index.md) | 10254 | いいえ | メトリクス/ヘルスチェックポートでTLSをサポートしていません | + +webserviceポッドの場合、公開されるポートはwebserviceコンテナ内のスタンドアロンのWebrick exporterです。Workhorseコンテナポートはスクレイピングされません。詳細については、[Webserviceメトリクスのドキュメント](../charts/gitlab/webservice/_index.md#metrics)を参照してください。 + +### 送信メール {#outgoing-email} + +デフォルトでは、送信メールは無効になっています。有効にするには、`global.smtp`および`global.email`設定を使用して、SMTPサーバーの詳細を入力します。これらの設定の詳細については、[コマンドラインオプション](command-line-options.md#outgoing-email-configuration)を参照してください。 + +SMTPサーバーが認証を必要とする場合は、[シークレットドキュメント](secrets.md#smtp-password)でパスワードの提供に関するセクションを必ずお読みください。`--set global.smtp.authentication=""`を使用して認証設定を無効にすることができます。 + +KubernetesクラスターがGKEにある場合、SMTP [ポート25がブロックされている](https://cloud.google.com/compute/docs/tutorials/sending-mail/#using_standard_email_ports)ことに注意してください。 + +### 受信メール {#incoming-email} + +受信[メール](../charts/gitlab/mailroom/_index.md#incoming-email)の設定については、[mailroomチャート](../charts/gitlab/mailroom/_index.md#incoming-email)に記載されています。 + +### サービスデスク {#service-desk-email}のメール + +受信[メール](../charts/gitlab/mailroom/_index.md#service-desk-email)の設定については、[mailroomチャート](../charts/gitlab/mailroom/_index.md#service-desk-email)に記載されています。 + +### RBAC {#rbac} + +GitLabチャートは[RBAC](rbac.md)の作成と使用がデフォルトです。クラスターでRBACが有効になっていない場合は、次の設定を無効にする必要があります。 + +```shell +--set certmanager.rbac.create=false +--set nginx-ingress.rbac.createRole=false +--set prometheus.rbac.create=false +--set gitlab-runner.rbac.create=false +``` + +## 次の手順 {#next-steps} + +[クラウドプロバイダーをセットアップしてクラスターを作成する](cloud/_index.md)。 diff --git a/doc-locale/ja-jp/installation/uninstall.md b/doc-locale/ja-jp/installation/uninstall.md new file mode 100644 index 0000000000..ab4916f275 --- /dev/null +++ b/doc-locale/ja-jp/installation/uninstall.md @@ -0,0 +1,34 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャートをアンインストールする +--- + +GitLab Helmチャートをアンインストールするには、次のコマンドを実行します。 + +```shell +helm uninstall gitlab +``` + +継続性を保つために、これらのチャートには、`helm uninstall`を実行しても削除されないKubernetesオブジェクトがいくつかあります。これらは、再デプロイする場合に影響があるため、_意識して_削除する必要がある項目です。 + +- ステートフルデータ用のPVC。これらは_意識して_削除する必要があります。 + - Gitaly:これは、リポジトリデータです。 + - PostgreSQL（内部の場合）：これはメタデータです。 + - Redis（内部の場合）：これはキャッシュとジョブキューであり、安全に削除できます。 +- シークレット（共有シークレットジョブによって生成される場合）。これらのチャートは、KubernetesシークレットをHelm経由で直接生成しないように設計されています。そのため、Helmで削除できません。これには、パスワード、暗号化シークレットなどが含まれています。これらは軽率に削除しないでください。 +- ConfigMaps + - `ingress-controller-leader-RELEASE-nginx`:これは、NGINX Ingressコントローラー自体によって生成され、チャートの制御外にあります。安全に削除できます。 + +PVCとシークレットには、`release`ラベルが設定されているため、以下を使用してこれらを見つけることができます。 + +```shell +kubectl get pvc,secret -lrelease=gitlab +``` + +{{< alert type="warning" >}} + +シークレット`RELEASE-gitlab-initial-root-password`を手動で削除しない場合、次のリリースで再利用されます。記録されたデモなどで、このパスワードが何らかの形で公開されている場合は、手動で削除する必要があります。これにより、公開されたパスワードが将来のリリースでインスタンスへのサインインに使用できなくなります。 + +{{< /alert >}} diff --git a/doc-locale/ja-jp/installation/upgrade.md b/doc-locale/ja-jp/installation/upgrade.md new file mode 100644 index 0000000000..6f33cc4f71 --- /dev/null +++ b/doc-locale/ja-jp/installation/upgrade.md @@ -0,0 +1,154 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートをアップグレードする +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabインストールをアップグレードする前に、アップグレード先の特定[リリース](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/CHANGELOG.md)に対応する[変更履歴](version_mappings.md#release-notes-for-each-supported-version)を確認し、新しいGitLabチャートバージョンに関連する可能性のある[リリースノート](version_mappings.md#release-notes-for-each-supported-version)を探す必要があります。 + +アップグレードは、サポートされている[アップグレードパス](https://docs.gitlab.com/update/#upgrade-paths)に従う必要があります。GitLabチャートのバージョン番号はGitLabのバージョン番号と同じではないため、両者間の[バージョンマッピング](version_mappings.md)を参照してください。 + +{{< alert type="note" >}} + +**ゼロ・ダウンタイム・アップグレード**はGitLabチャートでは利用できませんが、[GitLab Operator](https://docs.gitlab.com/operator/gitlab_upgrades/)を使用することで実現できます。 + +{{< /alert >}} + +最初に[バックアップ](../backup-restore/_index.md)を取ることをお勧めします。また、現在の値の一部は非推奨になっている可能性があるため、`helm upgrade --set key=value`構文または`-f values.yaml`を使用してすべての値を指定する必要があります。`--reuse-values`を使用しないでください。 + +以前の`--set`引数は、`helm get values `で適切に取得できます。これをファイル(`helm get values > gitlab.yaml`)にリダイレクトすると、`-f`経由でこのファイルを安全に渡すことができます。したがって、`helm upgrade gitlab gitlab/gitlab -f gitlab.yaml`。これにより、`--reuse-values`の動作が安全に置き換えられます + +## 手順 {#steps} + +{{< alert type="note" >}} + +チャートの`7.0`バージョンにアップグレードする場合は、[7.0の手動アップグレード手順](#upgrade-to-version-70)に従ってください。チャートの`6.0`バージョンにアップグレードする場合は、[6.0の手動アップグレード手順](#upgrade-to-version-60)に従ってください。以前のバージョンのチャートにアップグレードする場合は、[以前のバージョンのアップグレード手順](#older-upgrade-instructions)に従ってください。 + +{{< /alert >}} + +アップグレードする前に、設定した値を振り返り、設定を「過剰に構成」していないか確認してください。変更された値の小さなリストを保持し、ほとんどのチャートのデフォルトを活用することを想定しています。以下に示す方法で、多数の設定を明示的に設定した場合: + +- 計算された設定をコピーする +- すべての設定をコピーし、実際にはデフォルト値と同じ値を明示的に定義する + +構成構造がバージョン間で変更されている可能性があり、設定の適用に問題が発生するため、アップグレード中に問題が発生する可能性が非常に高くなります。これを確認する方法については、次の手順で説明します。 + +GitLabを新しいバージョンにアップグレードする手順は、次のとおりです。 + +1. アップグレード先の特定のバージョンの[変更履歴](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/CHANGELOG.md)を確認します。 +1. [デプロイメントドキュメント](deployment.md)を手順ごとに確認してください。 +1. 以前に指定した値を取得します: + + ```shell + helm get values gitlab > gitlab.yaml + ``` + +1. アップグレード時に引き継ぐ必要のあるすべての値を決定します。GitLabには適切なデフォルト値があり、アップグレード中に上記のコマンドからすべての値を渡すことができますが、チャートのバージョン間で構成が変更され、適切にマップされないシナリオが発生する可能性があります。明示的に設定する値の最小限のセットを保持し、アップグレードプロセス中にそれらを渡すことをお勧めします。 +1. 前の手順で抽出した値を使用して、アップグレードを実行します: + + ```shell + helm upgrade gitlab gitlab/gitlab \ + --version \ + -f gitlab.yaml \ + --set gitlab.migrations.enabled=true \ + --set ... + ``` + +メジャーデータベースのアップグレード中に、`gitlab.migrations.enabled`を`false`に設定するように求められます。今後のアップデートのために、明示的に`true`に戻してください。 + +## バンドルされたPostgreSQLチャートをアップグレードする {#upgrade-the-bundled-postgresql-chart} + +{{< alert type="note" >}} + +バンドルされたPostgreSQLチャート(`postgresql.install`がfalse)を使用していない場合は、この手順を実行する必要はありません。 + +{{< /alert >}} + +### バンドルされたPostgreSQLをバージョン13にアップグレードする {#upgrade-the-bundled-postgresql-to-version-13} + +PostgreSQL 13は、GitLab 14.1以降でサポートされています。[PostgreSQL 13には、大幅なパフォーマンスの改善](https://www.postgresql.org/about/news/postgresql-13-released-2077/)がもたらされています。 + +バンドルされたPostgreSQLをバージョン13にアップグレードするには、次の手順が必要です。 + +1. [既存のデータベースを準備](database_upgrade.md#prepare-the-existing-database)します。 +1. [既存のPostgreSQLデータを削除](database_upgrade.md#delete-existing-postgresql-data)します。 +1. `postgresql.image.tag`の値を`13.6.0`に更新し、[チャートを再インストール](database_upgrade.md#upgrade-gitlab)して、新しいPostgreSQL 13データベースを作成します。 +1. [データベースを復元](database_upgrade.md#restore-the-database)します。 + +## バージョン7.0にアップグレードする {#upgrade-to-version-70} + +{{< alert type="warning" >}} + +チャートの`6.x`バージョンから最新の`7.0`リリースにアップグレードする場合は、まず、アップグレードが機能するように、最新の`6.11.x`パッチリリースに更新する必要があります。[7.0リリースノート](../releases/7_0.md)には、サポートされているアップグレードパスが記載されています。 + +{{< /alert >}} + +`7.0.x`リリースでは、アップグレードを実行するために手動による手順が必要になる場合があります。 + +- クラスター内Redisサービスを提供するために、バンドルされた[`bitnami/Redis`](https://artifacthub.io/packages/helm/bitnami/redis)サブチャートを使用している場合、GitLabチャートのバージョン7.0にアップグレードする前に、RedisのStatefulSetを手動で削除する必要があります。以下の[バンドルされたRedisサブチャートのアップグレード](#update-the-bundled-redis-sub-chart)の設定に従ってください。 + +### バンドルされたRedisサブチャートをアップデートする {#update-the-bundled-redis-sub-chart} + +GitLabチャートのリリース7.0では、バンドルされた[`bitnami/Redis`](https://artifacthub.io/packages/helm/bitnami/redis)サブチャートが、以前にインストールされた`11.3.4`から`16.13.2`バージョンに更新されます。サブチャートの`redis-master` StatefulSetに適用される`matchLabels`の変更により、StatefulSetを手動で削除せずにアップグレードすると、次のエラーが発生します: + +```shell +Error: UPGRADE FAILED: cannot patch "gitlab-redis-master" with kind StatefulSet: StatefulSet.apps "gitlab-redis-master" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden +``` + +`RELEASE-redis-master`のStatefulSetを削除するには: + +1. `webservice`、`sidekiq`、`kas`、および`gitlab-exporter`デプロイメントの場合、レプリカを`0`にスケールダウンします: + + ```shell + kubectl scale deployment --replicas 0 --selector 'app in (webservice, sidekiq, kas, gitlab-exporter)' --namespace + ``` + +1. `RELEASE-redis-master` StatefulSetを削除します: + + ```shell + kubectl delete statefulset RELEASE-redis-master --namespace + ``` + + - ``は、GitLabチャートをインストールしたネームスペースに置き換える必要があります。 + +次に、[標準のアップグレード手順](#steps)に従います。Helmが変更をマージする方法により、最初の手順でスケールダウンしたデプロイメントを手動でスケールアップする必要がある場合があります。 + +### `global.redis.password`の使用 {#use-of-globalredispassword} + +`global.redis.password`の使用による構成タイプの競合を緩和するために、`global.redis.password`の使用を非推奨とし、`global.redis.auth`を推奨することにしました。 + +非推奨通知の表示に加えて、`helm upgrade`から次の警告メッセージが表示された場合: + +```plaintext +coalesce.go:199: warning: destination for password is a table. Ignoring non-table value +``` + +これは、`global.redis.password`を値ファイルに設定していることを示しています。 + +### Ingressの`useNewIngressForCerts` {#usenewingressforcerts-on-ingresses} + +既存のチャートを`7.x`から 以降のバージョンにアップグレードし、`global.ingress.useNewIngressForCerts`を`true`に変更する場合は、既存のcert-manager `Certificate`オブジェクトを更新して、`acme.cert-manager.io/http01-override-ingress-name`アノテーションを削除する必要もあります。 + +この属性が`false` (デフォルト) に設定されている場合、この変更を行う必要があります。このアノテーションはデフォルトで証明書に追加され、cert-managerはそれを使用して、その証明書に使用するIngressメソッドを識別します。この属性を`false`に変更しただけでは、アノテーションは自動的に削除されません。手動によるアクションが必要です。そうしないと、cert-managerは、既存のIngressの古い動作を使用し続けます。 + +## バージョン6.0にアップグレードする {#upgrade-to-version-60} + +{{< alert type="warning" >}} + +チャートの`5.x`バージョンから最新の`6.0`リリースにアップグレードする場合は、まず、アップグレードが機能するように、最新の`5.10.x`パッチリリースに更新する必要があります。[6.0リリースノート](../releases/6_0.md)には、サポートされているアップグレードパスが記載されています。 + +{{< /alert >}} + +`6.0`リリースにアップグレードするには、最初に最新の`5.10.x`パッチリリースを適用する必要があります。`6.0`では追加の手動による変更は必要ないため、[通常のリリースアップグレード手順に従う](#steps)ことができます。 + +## 以前のアップグレード手順 {#older-upgrade-instructions} + +5.xよりも前のバージョンのGitLabチャートからアップグレードする場合は、[GitLabドキュメントアーカイブ](https://docs.gitlab.com/archives/)を参照して、以前のバージョンのドキュメントにアクセスしてください。 diff --git a/doc-locale/ja-jp/installation/verify_cng_images.md b/doc-locale/ja-jp/installation/verify_cng_images.md new file mode 100644 index 0000000000..7d722fe093 --- /dev/null +++ b/doc-locale/ja-jp/installation/verify_cng_images.md @@ -0,0 +1,58 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: CNGイメージの整合性の検証 +--- + +CNGイメージが[`cosign`](https://github.com/sigstore/cosign)を使用してdigestに署名し、レジストリにプッシュされた後で改ざんされないようにするために、`cosign`はECDSA-P256キーとSHA256ハッシュを使用します。キーはPEMエンコードされたPKCS8形式で格納されます。 + +これらのdigestは、以下に示すように`cosign verify`コマンドを使用してVerifyできます。 + +{{< alert type="note" >}} + +イメージは秘密キーを使用して署名されており、対応する公開キーを使用してローカルでVerifyすることのみが可能です。[イシュー638](https://gitlab.com/gitlab-org/build/CNG/-/issues/638)で、GitLab.com OIDCプロバイダーを使用したキーレス署名/Verifyへの移行について議論されています。 + +{{< /alert >}} + +1. [https://charts.gitlab.io/cosign.pub](https://charts.gitlab.io/cosign.pub)から署名に使用される公開キーをダウンロードします。 + + ```shell + wget https://charts.gitlab.io/cosign.pub + ``` + +1. CNGイメージをVerifyします。 + + ```shell + $ cosign verify --key cosign.pub registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee:v16.9.0 | jq -r + + Verification for registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee:v16.9.0 -- + The following checks were performed on each of these signatures: + - The cosign claims were validated + - Existence of the claims in the transparency log was verified offline + - The signatures were verified against the specified public key + [ + { + "critical": { + "identity": { + "docker-reference": "dev.gitlab.org:5005/gitlab/charts/components/images/gitlab-workhorse-ee" + }, + "image": { + "docker-manifest-digest": "sha256:218a67cc46b49ba0563dbdc83618bf11fa5453577a4aa75475823e315952ea79" + }, + "type": "cosign container image signature" + }, + "optional": { + "Bundle": { + "SignedEntryTimestamp": "MEUCIQCDj2Ffe8Qll9clqAKoBA8wTwg2NrzMLvpVMkw61qdhmAIgQgLYCT7IdGwVEp5UrQjN67Zt9CTATQpi08+CrGgqnxw=", + "Payload": { + "body": "eyJhcGlWZXJzaW9uIjoiMC4wLjEiLCJraW5kIjoiaGFzaGVkcmVrb3JkIiwic3BlYyI6eyJkYXRhIjp7Imhhc2giOnsiYWxnb3JpdGhtIjoic2hhMjU2IiwidmFsdWUiOiI4Mzg1Y2YyYzI0MjI5ZjFhYzk2MTU1ZGU3YzM3ZjcyZmQzOTczYTgwZGIyMjNmNDUwZjlhNGMxNjRmZDIyNmUzIn19LCJzaWduYXR1cmUiOnsiY29udGVudCI6Ik1FUUNJRVpjcENpRFJ5V1FuT25jRGtmUEtaTnRPc0s4dW9YeFJqMEcrTnZ1VzRwS0FpQThEK2YyWVRtQ2Z3MVFqK0doQmlVb0tFQVA4dE5MWDZOYk1kczFUQ1JJR0E9PSIsInB1YmxpY0tleSI6eyJjb250ZW50IjoiTFMwdExTMUNSVWRKVGlCUVZVSk1TVU1nUzBWWkxTMHRMUzBLVFVacmQwVjNXVWhMYjFwSmVtb3dRMEZSV1VsTGIxcEplbW93UkVGUlkwUlJaMEZGYnpGQk5tbEZjbXhrSzFoRU5WSTBiVXRNU1VGNU4wVXhOMlV3WXdwV1VWSldlVEpoTmpoSlRESklSaXRXV1VKeWFqRkpjbHAyT0ZsdU5UUTVaU3RUUVRVeVpVZHZLMEpIU1RWSWJVeGxVbXR2Wm5Ob1MxaG5QVDBLTFMwdExTMUZUa1FnVUZWQ1RFbERJRXRGV1MwdExTMHRDZz09In19fX0=", + "integratedTime": 1707955615, + "logIndex": 71468664, + "logID": "c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d" + } + } + } + } + ] + ``` diff --git a/doc-locale/ja-jp/installation/version_mappings.md b/doc-locale/ja-jp/installation/version_mappings.md new file mode 100644 index 0000000000..38b8375da0 --- /dev/null +++ b/doc-locale/ja-jp/installation/version_mappings.md @@ -0,0 +1,368 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのバージョン +--- + +{{< details >}} + +- プラン:Free、Premium、Ultimate +- 提供:GitLab Self-Managed + +{{< /details >}} + +GitLabチャートのバージョン番号は、GitLab自体のバージョン番号と同じではありません。これは、破壊的な変更がGitLabとは関係なくチャートに導入される可能性があることを意味します。 + +すばやく`gitlab`チャートのバージョンと、対応するGitLabのバージョンの一覧を表示するには、[Helm](tools.md)で次のコマンドを実行します。 + +```shell +helm repo add gitlab https://charts.gitlab.io/ +helm search repo -l gitlab/gitlab +``` + +## 各サポート対象バージョン {#release-notes-for-each-supported-version}のリリースノート + +- [9.0](../releases/9_0.md) +- [8.0](../releases/8_0.md) +- [7.0](../releases/7_0.md) +- [6.0](../releases/6_0.md) + +## 以前のチャートのバージョン {#previous-chart-versions} + +以下のテーブルは、以前にサポートされていた主要なチャートバージョンと、サポートされているGitLabのバージョンをマップしたものです。 + +| チャートのバージョン | GitLabのバージョン | +|---------------|----------------| +| 9.0.1 | 18.0.1 | +| 9.0.0 | 18.0.0 | +| 8.11.3 | 17.11.3 | +| 8.11.2 | 17.11.2 | +| 8.11.1 | 17.11.1 | +| 8.11.0 | 17.11.0 | +| 8.10.7 | 17.10.7 | +| 8.10.6 | 17.10.6 | +| 8.10.5 | 17.10.5 | +| 8.10.4 | 17.10.4 | +| 8.10.3 | 17.10.3 | +| 8.10.2 | 17.10.2 | +| 8.10.1 | 17.10.1 | +| 8.10.0 | 17.10.0 | +| 8.9.8 | 17.9.8 | +| 8.9.7 | 17.9.7 | +| 8.9.6 | 17.9.6 | +| 8.9.5 | 17.9.5 | +| 8.9.4 | 17.9.4 | +| 8.9.3 | 17.9.3 | +| 8.9.2 | 17.9.2 | +| 8.9.1 | 17.9.1 | +| 8.9.0 | 17.9.0 | +| 8.8.7 | 17.8.7 | +| 8.8.6 | 17.8.6 | +| 8.8.5 | 17.8.5 | +| 8.8.4 | 17.8.4 | +| 8.8.3 | 17.8.3 | +| 8.8.2 | 17.8.2 | +| 8.8.1 | 17.8.1 | +| 8.8.0 | 17.8.0 | +| 8.7.9 | 17.7.7 | +| 8.7.8 | 17.7.6 | +| 8.7.7 | 17.7.5 | +| 8.7.6 | 17.7.4 | +| 8.7.5 | 17.7.3 | +| 8.7.4 | 17.7.2 | +| 8.7.3 | 17.7.1 | +| 8.7.2 | 17.7.0 | +| 8.7.0 | 17.7.0 | +| 8.6.5 | 17.6.5 | +| 8.6.4 | 17.6.4 | +| 8.6.3 | 17.6.3 | +| 8.6.2 | 17.6.2 | +| 8.6.1 | 17.6.1 | +| 8.6.0 | 17.6.0 | +| 8.5.5 | 17.5.5 | +| 8.5.4 | 17.5.4 | +| 8.5.3 | 17.5.3 | +| 8.5.2 | 17.5.2 | +| 8.5.1 | 17.5.1 | +| 8.5.0 | 17.5.0 | +| 8.4.6 | 17.4.6 | +| 8.4.5 | 17.4.5 | +| 8.4.4 | 17.4.4 | +| 8.4.3 | 17.4.3 | +| 8.4.2 | 17.4.2 | +| 8.4.1 | 17.4.1 | +| 8.4.0 | 17.4.0 | +| 8.3.7 | 17.3.7 | +| 8.3.6 | 17.3.6 | +| 8.3.5 | 17.3.5 | +| 8.3.4 | 17.3.4 | +| 8.3.3 | 17.3.3 | +| 8.3.2 | 17.3.2 | +| 8.3.1 | 17.3.1 | +| 8.3.0 | 17.3.0 | +| 8.2.9 | 17.2.9 | +| 8.2.8 | 17.2.8 | +| 8.2.7 | 17.2.7 | +| 8.2.6 | 17.2.6 | +| 8.2.5 | 17.2.5 | +| 8.2.4 | 17.2.4 | +| 8.2.3 | 17.2.3 | +| 8.2.2 | 17.2.2 | +| 8.2.1 | 17.2.1 | +| 8.2.0 | 17.2.0 | +| 8.1.8 | 17.1.8 | +| 8.1.7 | 17.1.7 | +| 8.1.6 | 17.1.6 | +| 8.1.5 | 17.1.5 | +| 8.1.4 | 17.1.4 | +| 8.1.3 | 17.1.3 | +| 8.1.2 | 17.1.2 | +| 8.1.1 | 17.1.1 | +| 8.1.0 | 17.1.0 | +| 8.0.8 | 17.0.8 | +| 8.0.7 | 17.0.7 | +| 8.0.6 | 17.0.6 | +| 8.0.5 | 17.0.5 | +| 8.0.4 | 17.0.4 | +| 8.0.3 | 17.0.3 | +| 8.0.2 | 17.0.2 | +| 8.0.1 | 17.0.1 | +| 8.0.0 | 17.0.0 | +| 7.11.10 | 16.11.10 | +| 7.11.9 | 16.11.9 | +| 7.11.8 | 16.11.8 | +| 7.11.7 | 16.11.7 | +| 7.11.6 | 16.11.6 | +| 7.11.5 | 16.11.5 | +| 7.11.4 | 16.11.4 | +| 7.11.3 | 16.11.3 | +| 7.11.2 | 16.11.2 | +| 7.11.1 | 16.11.1 | +| 7.11.0 | 16.11.0 | +| 7.10.10 | 16.10.10 | +| 7.10.9 | 16.10.9 | +| 7.10.8 | 16.10.8 | +| 7.10.7 | 16.10.7 | +| 7.10.6 | 16.10.6 | +| 7.10.5 | 16.10.5 | +| 7.10.4 | 16.10.4 | +| 7.10.3 | 16.10.3 | +| 7.10.2 | 16.10.2 | +| 7.10.1 | 16.10.1 | +| 7.10.0 | 16.10.0 | +| 7.9.11 | 16.9.11 | +| 7.9.10 | 16.9.10 | +| 7.9.9 | 16.9.9 | +| 7.9.8 | 16.9.8 | +| 7.9.7 | 16.9.7 | +| 7.9.6 | 16.9.6 | +| 7.9.5 | 16.9.5 | +| 7.9.4 | 16.9.4 | +| 7.9.3 | 16.9.3 | +| 7.9.2 | 16.9.2 | +| 7.9.1 | 16.9.1 | +| 7.9.0 | 16.9.0 | +| 7.8.10 | 16.8.10 | +| 7.8.9 | 16.8.9 | +| 7.8.8 | 16.8.8 | +| 7.8.7 | 16.8.7 | +| 7.8.6 | 16.8.6 | +| 7.8.5 | 16.8.5 | +| 7.8.4 | 16.8.4 | +| 7.8.3 | 16.8.3 | +| 7.8.2 | 16.8.2 | +| 7.8.1 | 16.8.1 | +| 7.8.0 | 16.8.0 | +| 7.7.10 | 16.7.10 | +| 7.7.9 | 16.7.9 | +| 7.7.8 | 16.7.8 | +| 7.7.7 | 16.7.7 | +| 7.7.6 | 16.7.6 | +| 7.7.5 | 16.7.5 | +| 7.7.4 | 16.7.4 | +| 7.7.3 | 16.7.3 | +| 7.7.2 | 16.7.2 | +| 7.7.1 | 16.7.1 | +| 7.7.0 | 16.7.0 | +| 7.6.10 | 16.6.10 | +| 7.6.9 | 16.6.9 | +| 7.6.8 | 16.6.8 | +| 7.6.7 | 16.6.7 | +| 7.6.6 | 16.6.6 | +| 7.6.5 | 16.6.5 | +| 7.6.4 | 16.6.4 | +| 7.6.3 | 16.6.3 | +| 7.6.2 | 16.6.2 | +| 7.6.1 | 16.6.1 | +| 7.6.0 | 16.6.0 | +| 7.5.10 | 16.5.10 | +| 7.5.9 | 16.5.9 | +| 7.5.8 | 16.5.8 | +| 7.5.7 | 16.5.7 | +| 7.5.6 | 16.5.6 | +| 7.5.5 | 16.5.5 | +| 7.5.4 | 16.5.4 | +| 7.5.3 | 16.5.3 | +| 7.5.2 | 16.5.2 | +| 7.5.1 | 16.5.1 | +| 7.5.0 | 16.5.0 | +| 7.4.7 | 16.4.7 | +| 7.4.6 | 16.4.6 | +| 7.4.5 | 16.4.5 | +| 7.4.4 | 16.4.4 | +| 7.4.3 | 16.4.3 | +| 7.4.2 | 16.4.2 | +| 7.4.1 | 16.4.1 | +| 7.4.0 | 16.4.0 | +| 7.3.9 | 16.3.9 | +| 7.3.8 | 16.3.8 | +| 7.3.7 | 16.3.7 | +| 7.3.6 | 16.3.6 | +| 7.3.5 | 16.3.5 | +| 7.3.4 | 16.3.4 | +| 7.3.3 | 16.3.3 | +| 7.3.2 | 16.3.2 | +| 7.3.1 | 16.3.1 | +| 7.3.0 | 16.3.0 | +| 7.2.11 | 16.2.11 | +| 7.2.10 | 16.2.10 | +| 7.2.9 | 16.2.9 | +| 7.2.8 | 16.2.8 | +| 7.2.7 | 16.2.7 | +| 7.2.6 | 16.2.6 | +| 7.2.5 | 16.2.5 | +| 7.2.4 | 16.2.4 | +| 7.2.3 | 16.2.3 | +| 7.2.2 | 16.2.2 | +| 7.2.1 | 16.2.1 | +| 7.2.0 | 16.2.0 | +| 7.1.8 | 16.1.8 | +| 7.1.7 | 16.1.7 | +| 7.1.6 | 16.1.6 | +| 7.1.5 | 16.1.5 | +| 7.1.4 | 16.1.4 | +| 7.1.3 | 16.1.3 | +| 7.1.2 | 16.1.2 | +| 7.1.1 | 16.1.1 | +| 7.1.0 | 16.1.0 | +| 7.0.10 | 16.0.10 | +| 7.0.9 | 16.0.9 | +| 7.0.8 | 16.0.8 | +| 7.0.7 | 16.0.7 | +| 7.0.6 | 16.0.6 | +| 7.0.5 | 16.0.5 | +| 7.0.4 | 16.0.4 | +| 7.0.3 | 16.0.3 | +| 7.0.2 | 16.0.2 | +| 7.0.1 | 16.0.1 | +| 7.0.0 | 16.0.0 | +| 6.11.13 | 15.11.13 | +| 6.11.12 | 15.11.12 | +| 6.11.11 | 15.11.11 | +| 6.11.10 | 15.11.10 | +| 6.11.9 | 15.11.9 | +| 6.11.8 | 15.11.8 | +| 6.11.7 | 15.11.7 | +| 6.11.6 | 15.11.6 | +| 6.11.5 | 15.11.5 | +| 6.11.4 | 15.11.4 | +| 6.11.3 | 15.11.3 | +| 6.11.2 | 15.11.2 | +| 6.11.1 | 15.11.1 | +| 6.11.0 | 15.11.0 | +| 6.10.8 | 15.10.8 | +| 6.10.7 | 15.10.7 | +| 6.10.6 | 15.10.6 | +| 6.10.5 | 15.10.5 | +| 6.10.4 | 15.10.4 | +| 6.10.3 | 15.10.3 | +| 6.10.2 | 15.10.2 | +| 6.10.1 | 15.10.1 | +| 6.10.0 | 15.10.0 | +| 6.9.8 | 15.9.8 | +| 6.9.7 | 15.9.7 | +| 6.9.6 | 15.9.6 | +| 6.9.5 | 15.9.5 | +| 6.9.4 | 15.9.4 | +| 6.9.3 | 15.9.3 | +| 6.9.2 | 15.9.2 | +| 6.9.1 | 15.9.1 | +| 6.9.0 | 15.9.0 | +| 6.8.6 | 15.8.6 | +| 6.8.5 | 15.8.5 | +| 6.8.4 | 15.8.4 | +| 6.8.3 | 15.8.3 | +| 6.8.2 | 15.8.2 | +| 6.8.1 | 15.8.1 | +| 6.8.0 | 15.8.0 | +| 6.7.9 | 15.7.9 | +| 6.7.8 | 15.7.8 | +| 6.7.7 | 15.7.7 | +| 6.7.6 | 15.7.6 | +| 6.7.5 | 15.7.5 | +| 6.7.3 | 15.7.3 | +| 6.7.2 | 15.7.2 | +| 6.7.1 | 15.7.1 | +| 6.7.0 | 15.7.0 | +| 6.6.8 | 15.6.8 | +| 6.6.7 | 15.6.7 | +| 6.6.6 | 15.6.6 | +| 6.6.4 | 15.6.4 | +| 6.6.3 | 15.6.3 | +| 6.6.2 | 15.6.2 | +| 6.6.1 | 15.6.1 | +| 6.6.0 | 15.6.0 | +| 6.5.9 | 15.5.9 | +| 6.5.8 | 15.5.7 | +| 6.5.7 | 15.5.6 | +| 6.5.6 | 15.5.5 | +| 6.5.5 | 15.5.4 | +| 6.5.4 | 15.5.3 | +| 6.5.3 | 15.5.3 | +| 6.5.2 | 15.5.2 | +| 6.5.1 | 15.5.1 | +| 6.5.0 | 15.5.0 | +| 6.4.6 | 15.4.6 | +| 6.4.5 | 15.4.5 | +| 6.4.4 | 15.4.4 | +| 6.4.3 | 15.4.3 | +| 6.4.2 | 15.4.2 | +| 6.4.1 | 15.4.1 | +| 6.4.0 | 15.4.0 | +| 6.3.5 | 15.3.5 | +| 6.3.4 | 15.3.4 | +| 6.3.3 | 15.3.3 | +| 6.3.2 | 15.3.2 | +| 6.3.1 | 15.3.1 | +| 6.3.0 | 15.3.0 | +| 6.2.5 | 15.2.5 | +| 6.2.4 | 15.2.4 | +| 6.2.3 | 15.2.3 | +| 6.2.2 | 15.2.2 | +| 6.2.1 | 15.2.1 | +| 6.2.0 | 15.2.0 | +| 6.1.6 | 15.1.6 | +| 6.1.5 | 15.1.5 | +| 6.1.4 | 15.1.4 | +| 6.1.3 | 15.1.3 | +| 6.1.2 | 15.1.2 | +| 6.1.1 | 15.1.1 | +| 6.1.0 | 15.1.0 | +| 6.0.5 | 15.0.5 | +| 6.0.4 | 15.0.4 | +| 6.0.3 | 15.0.3 | +| 6.0.2 | 15.0.2 | +| 6.0.1 | 15.0.1 | +| 6.0.0 | 15.0.0 | + +全リストを表示するには、Helmで次のコマンドを実行します。 + +```shell +helm repo add gitlab https://charts.gitlab.io/ +helm search repo -l gitlab/gitlab +``` + +[チャートのバージョニング](../development/release.md#chart-versioning)の詳細については、関連ドキュメントを参照してください。 + +重要な[リリースのドキュメント](#release-notes-for-each-supported-version)を確認し、任意のリリースの完全な詳細については、[変更履歴](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/CHANGELOG.md)を参照してください。 diff --git a/doc-locale/ja-jp/quickstart/_index.md b/doc-locale/ja-jp/quickstart/_index.md new file mode 100644 index 0000000000..01404dd4b7 --- /dev/null +++ b/doc-locale/ja-jp/quickstart/_index.md @@ -0,0 +1,136 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GKEまたはEKSでのGitLabチャートのテスト +--- + +このガイドは、Google Kubernetes Engine（GKE）またはAmazon Elastic Kubernetes Service（Amazon EKS）にデフォルト値でGitLabチャートをインストールする方法に関する、簡潔かつ完全なドキュメントとして提供することを目的としています。 + +デフォルトでは、GitLabチャートには、クラスター内PostgreSQL、Redis、およびMinIOのデプロイメントが含まれています。これらは**トライアル**目的のみを対象としており、**本番環境**での使用は推奨されません。これらのチャートを継続的な負荷がかかる本番環境にデプロイする場合は、完全な[インストールガイド](../installation/_index.md)に従ってください。 + +## 前提要件 {#prerequisites} + +このガイドを完了するには、以下が必要です。 + +- DNSレコードを追加できる、お客様が所有するドメイン。 +- Kubernetesクラスター。 +- `kubectl`の動作するインストール。 +- 動作するHelm v3のインストール。 + +### 利用可能なドメイン {#available-domain} + +DNSレコードを追加できる、インターネットからアクセス可能なドメインにアクセスできる必要があります。これは`poc.domain.com`などのサブドメインにすることができますが、Let's Encryptサーバーは、証明書を発行するためにアドレスを解決できる必要があります。 + +### KubernetesクラスターのCreate {#create-a-kubernetes-cluster} + +合計で少なくとも8つの仮想CPUと30 GiBのRAMを備えたクラスターをお勧めします。 + +Kubernetes[クラスター](../installation/cloud/_index.md)の作成方法については、[クラウドプロバイダー](../installation/cloud/_index.md)の手順を参照するか、GitLab提供のスクリプトを使用して[クラスター](../installation/cloud/_index.md)の作成を自動化できます。 + +{{< alert type="warning" >}} + +Kubernetesノードは、x86-64アーキテクチャを使用する必要があります。AArch64/ARM64を含む複数のアーキテクチャのサポートは、積極的に開発中です。詳細については、[イシュー2899](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2899)を参照してください。 + +{{< /alert >}} + +### kubectlのインストール {#install-kubectl} + +[kubectl](https://kubernetes.io/docs/tasks/tools/)をインストールするには、[Kubernetes](https://kubernetes.io/docs/tasks/tools/)インストールに関するドキュメントを参照してください。このドキュメントでは、ほとんどのオペレーティングシステムとGoogle Cloud SDKについて説明しています。これらは、前の手順でインストールした可能性があります。 + +[クラスター](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#generate_kubeconfig_entry)を作成したら、`kubectl`を[設定](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#generate_kubeconfig_entry)して、[コマンドライン](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#generate_kubeconfig_entry)から[クラスター](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl#generate_kubeconfig_entry)とやり取りできるようにする必要があります。 + +### Helmのインストール {#install-helm} + +このガイドでは、Helm v3の最新リリース（v3.9.4以降）を使用します。Helmをインストールするには、[Helm](https://helm.sh/docs/intro/install/)インストールに関するドキュメントを参照してください。 + +## GitLab Helmリポジトリの追加 {#add-the-gitlab-helm-repository} + +GitLab Helmリポジトリを`helm`の設定に追加します。 + +```shell +helm repo add gitlab https://charts.gitlab.io/ +``` + +## GitLabのインストール {#install-gitlab} + +このチャートが提供できるものの素晴らしさをご紹介します。1つのコマンド。はい、どうぞ。すべてインストールされ、SSLで設定されたGitLab。 + +チャートを設定するには、以下が必要です。 + +- GitLabが動作するドメインまたはサブドメイン。 +- お客様のメールアドレス。これにより、Let's Encryptが証明書を発行できます。 + +チャートをインストールするには、2つの`--set`引数を使用してインストールコマンドを実行します。 + +```shell +helm install gitlab gitlab/gitlab \ + --set global.hosts.domain=DOMAIN \ + --set certmanager-issuer.email=me@example.com +``` + +この手順では、すべてのリソースの割り当て、サービスの起動、およびアクセスが利用可能になるまでに数分かかる場合があります。 + +完了したら、インストールされているNGINX Ingressに動的に割り当てられたIPアドレスのフェッチに進むことができます。 + +## IPアドレスのRetrieve {#retrieve-the-ip-address} + +`kubectl`を使用して、インストールおよび設定したNGINX IngressにGKEによって動的に割り当てられたアドレスを、GitLabチャートの一部としてフェッチできます。 + +```shell +kubectl get ingress -lrelease=gitlab +``` + +出力は次のようになります。 + +```plaintext +NAME HOSTS ADDRESS PORTS AGE +gitlab-minio minio.domain.tld 35.239.27.235 80, 443 118m +gitlab-registry registry.domain.tld 35.239.27.235 80, 443 118m +gitlab-webservice gitlab.domain.tld 35.239.27.235 80, 443 118m +``` + +3つのエントリがあり、すべて同じIPアドレスであることがわかります。このIPアドレスを取得し、使用することを選択したドメインのDNSに追加します。タイプ`A`のレコードを複数追加できますが、簡単にするために、単一の「ワイルドカード」レコードをお勧めします。 + +- Google Cloud DNSで、名前`*`の`A`レコードをCreateします。また、TTLを`1`分ではなく、`5`分に設定することをお勧めします。 +- AWS EKSでは、アドレスはIPアドレスではなくURLになります。[Route 53エイリアスレコードを作成](https://repost.aws/knowledge-center/route-53-create-alias-records) `*.domain.tld`このURLを指します。 + +## GitLabへのSign in {#sign-in-to-gitlab} + +`gitlab.domain.tld`でGitLabにアクセスできます。たとえば、`global.hosts.domain=my.domain.tld`を設定した場合は、`gitlab.my.domain.tld`にアクセスします。 + +サインインするには、`root`ユーザーのパスワードを収集する必要があります。これはインストール時に自動的に生成され、Kubernetesシークレットに保存されます。シークレットからそのパスワードをフェッチしてデコードしましょう。 + +```shell +kubectl get secret gitlab-gitlab-initial-root-password -ojsonpath='{.data.password}' | base64 --decode ; echo +``` + +これで、ユーザー名`root`と取得したパスワードを使用してGitLabにサインインできます。ログイン後、ユーザー設定からこのパスワードを変更できます。これは、お客様に代わって最初のログインをSecureにできるようにするためにのみ生成するものです。 + +## トラブルシューティング {#troubleshooting} + +このガイドで問題が発生した場合は、動作していることを確認する必要のある、可能性の高い項目を次に示します。 + +1. `gitlab.my.domain.tld`は、取得したIngressのIPアドレスに解決されます。 +1. 証明書の警告が表示された場合は、Let's Encryptに問題が発生しています。通常はDNS、または再試行の要件に関連しています。 + +その他の[トラブルシューティング](../troubleshooting/_index.md)のヒントについては、[トラブルシューティング](../troubleshooting/_index.md)ガイドを参照してください。 + +### Helmインストールが`roles.rbac.authorization.k8s.io "gitlab-shared-secrets" is forbidden` {#helm-install-returns-rolesrbacauthorizationk8sio-gitlab-shared-secrets-is-forbidden}を返します + +実行後: + +```shell +helm install gitlab gitlab/gitlab \ + --set global.hosts.domain=DOMAIN \ + --set certmanager-issuer.email=user@example.com +``` + +次のようなエラーが表示されることがあります。 + +```shell +Error: failed pre-install: warning: Hook pre-install templates/shared-secrets-rbac-config.yaml failed: roles.rbac.authorization.k8s.io "gitlab-shared-secrets" is forbidden: user "some-user@some-domain.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held: +{APIGroups:[""], Resources:["secrets"], Verbs:["get" "list" "create" "patch"]} +``` + +これは、クラスターへの接続に使用している`kubectl`コンテキストに、[RBAC](../installation/rbac.md)リソースを作成するために必要な権限がないことを意味します。 diff --git a/doc-locale/ja-jp/releases/6_0.md b/doc-locale/ja-jp/releases/6_0.md new file mode 100644 index 0000000000..8ccc3d2d83 --- /dev/null +++ b/doc-locale/ja-jp/releases/6_0.md @@ -0,0 +1,77 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLab Helmチャート6.0 +--- + +GitLabの`15.0`リリースに伴い、チャートバージョンを`6.0`に更新しました。 + +## 主な変更点の概要 {#summary-of-major-changes} + +- 推奨デフォルトのPostgreSQLデータベースは[13にアップグレードされました](#postgresql)。 +- NGINX Ingressで許可される暗号のデフォルトリストが[脆弱な暗号を削除](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2578)するように変更されました。これにより、一部のAWSデプロイが中断される可能性があります。詳細については、[イシュー #3317](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3317)を参照してください。 + +## 5.xからのアップグレード パス {#upgrade-path-from-5x} + +チャートの`6.0`バージョンにアップグレードするには、まず、チャートの最新`5.10.x`リリースにアップグレードする必要があります。最新パッチについては、[バージョン マッピングの詳細](../installation/version_mappings.md)を確認してください。 + +最新の`5.10.x`パッチに最初にアップグレードしないと、`helm upgrade`から次のエラーが表示されます。 + +```shell +Error: UPGRADE FAILED: Job failed: BackoffLimitExceeded +``` + +この状況にあるかどうかを確認するには、名前にテキスト`gitlab-upgrade-check`を含むエラーが発生したポッドを探します。 + +これらのポッドのログを確認すると、バージョンのアップグレードエラーメッセージが表示されます。 + +```plaintext +It seems you are upgrading the GitLab Helm chart from X (GitLab X) to 6.0.0 (GitLab 15.0.0). +It is required to upgrade to the latest 5.10.x version first before proceeding. +Please follow the upgrade documentation at https://docs.gitlab.com/charts/releases/6_0.html +and upgrade to GitLab Helm chart version 5.10.x before upgrading to 6.0.0. +``` + +## 5.10.xからのアップグレード {#upgrade-from-510x} + +[通常のアップグレード手順](../installation/upgrade.md)に従ってください。 + +## 主な変更点 {#major-changes} + +### PostgreSQL {#postgresql} + +PostgreSQL 13が推奨バージョンですが、PostgreSQL 12.xも引き続きサポートされています。 + +{{< alert type="note" >}} + +今回のメジャーリリースには必須ではありませんが、PostgreSQL 13へのアップグレードの計画を開始する必要があります。 + +{{< /alert >}} + +## リリース ケイデンス {#release-cadence} + +新しいGitLabパッチごとに、チャートの新しいバージョンをリリースします。 + +チャートのバージョニング方法の詳細については、[リリースドキュメント](../development/release.md)を参照してください。 + +このリポジトリのイシューおよびマージリクエストrequest>とともに、[変更履歴](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/CHANGELOG.md)を利用して、アップグレードをより簡単に追跡できます。 + +## Kubernetesデプロイのサポート {#kubernetes-deployment-support} + +GitLabは以下に対してテストされています。 + +- [Google Kubernetesエンジン](https://cloud.google.com/kubernetes-engine) +- [Amazon EKS](https://aws.amazon.com/eks/) + +他のKubernetesデプロイも同様に機能するはずです。GKE以外の特定のデプロイに関するイシューが発生した場合は、イシューを提起してください。 + +このリリースには、Kubernetesバージョン`1.21.10-gke.2000`および`v1.19.16-eks-25803e`の自動CIテストがあります。 + +## テクニカルサポート {#technical-support} + +イシューをオープンする前に、[既存のイシューを検索](https://gitlab.com/gitlab-org/charts/gitlab/-/issues)して、同様のイシューが既に存在するかどうかを確認してください。 + +コミュニティの広範なテストに感謝し、新しいイシューを作成して、それらに対処できるようにすることをお勧めします。 + +[マージリクエストrequest>](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests)の形式でコントリビュートされた改善を歓迎します。[コントリビュータードキュメント](https://gitlab.com/gitlab-org/charts/gitlab/-/blob/master/CONTRIBUTING.md)から始めてください。 diff --git a/doc-locale/ja-jp/releases/7_0.md b/doc-locale/ja-jp/releases/7_0.md new file mode 100644 index 0000000000..bea4781194 --- /dev/null +++ b/doc-locale/ja-jp/releases/7_0.md @@ -0,0 +1,71 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers +title: GitLabクラウドネイティブチャート7.0 +--- + +GitLabの`16.0`リリースに伴い、チャートのバージョンを`7.0`に上げました。 + +## 主な変更の概要 {#summary-of-major-changes} + +- 推奨されるPostgreSQLデータベースは、[14.8にアップグレード](#postgresql)されました。 +- バンドルされたcertmanagerチャートは、[1.5.4から1.11.1にアップグレード](#bundled-certmanager)されました。 + +## 6.xからのアップグレードパス {#upgrade-path-from-6x} + +チャートの`7.0`バージョンにアップグレードするには、まず、チャートの最新`6.11.x`リリースにアップグレードする必要があります。最新パッチについては、[バージョンのマッピングの詳細](../installation/version_mappings.md)を確認してください。 + +GitLabは、デフォルトで2つのデータベース接続を使用するようになりました。アップグレードする前に、PostgreSQLの`max_connections`が十分に高いことを確認してください（利用可能な最大接続数の50％以上を使用）。これを[Toolboxコンテナ](../charts/gitlab/toolbox/_index.md#toolbox-included-tools)を使用して、次のRakeタスクを実行して[検証](../charts/gitlab/toolbox/_index.md#toolbox-included-tools)できます。 + +```shell +gitlab-rake gitlab:db:decomposition:connection_status +``` + +タスクで`max_connections`が十分に高いことが示されている場合は、アップグレードに進むことができます。そうでない場合、または単一接続のままにしたい場合は、アップグレードの前に`ci.enabled`キーを`false`に設定できます。 + +## 6.11.xからのアップグレード {#upgrade-from-611x} + +[7.0リリースのアップグレード手順](../installation/upgrade.md#upgrade-to-version-70)に従ってください。 + +## 主な変更点 {#major-changes} + +### PostgreSQL {#postgresql} + +このチャートの`7.0.0`リリースの一環として、デフォルトのPostgreSQLバージョンを`12.7`から`14.8`にアップグレードしました。これは、[PostgreSQLチャート](https://github.com/bitnami/charts/tree/main/bitnami/postgresql)のバージョンを`8.9.4`から`12.5.2`にアップグレードすることで行われます。 + +これは、ドロップインリソースではありません。データベースをアップグレードするには、手動手順を実行する必要があります。手順は、[アップグレード](../installation/database_upgrade.md#steps-for-upgrading-the-bundled-postgresql)手順に記載されています。 + +{{< alert type="note" >}} + +PostgreSQL 13は、GitLab 16.0でサポートされる最小要件のPostgreSQLバージョンであることに注意してください。PostgreSQL 12は、GitLab 16.0以降ではサポートされなくなりました。 + +{{< /alert >}} + +### バンドルされたcertmanager {#bundled-certmanager} + +バンドルされたcertmanagerチャートは、1.5.4から1.11.1にアップグレードされます。クラスターとツールによっては、アップグレードする前に手動での操作が必要になる場合があります。 + +クラスターのバージョンがcertmanager 1.11でサポートされていることを確認してください。このリリースは、Kubernetes 1.21〜1.26およびOpenShift 4.8〜4.13をサポートしています。詳細については、[certmanagerでサポートされているリリース](https://cert-manager.io/docs/releases/)を参照してください。 + +デフォルトのcertmanager設定は、`acme.cert-manager.io/http01-edit-in-place`アノテーションを使用するようになりました。その結果、certmanagerは、新しいIngressを作成する代わりに、既存のIngressを使用してACME Challengeを完了します。この変更により、`ingressClassName`を設定する必要があるIngressコントローラーとの互換性が確保されます。 + +OpenShiftユーザーは、Security Context Constraintsを変更してcertmanager 1.10+をデプロイする必要がある場合があります。詳細については、[certmanager 1.10リリースノート](https://cert-manager.io/docs/releases/release-notes/release-notes-1.10/#on-openshift-the-cert-manager-pods-may-fail-until-you-modify-security-context-constraints)を参照してください。 + +GitLabチャートで[管理](https://cert-manager.io/docs/releases/)されていないcertmanagerカスタム[リソース](https://cert-manager.io/docs/releases/)を[デプロイ](https://cert-manager.io/docs/releases/)する場合、またはcert-[管理](https://cert-manager.io/docs/releases/)に関連する追加のスクリプトまたは[ツール](https://cert-manager.io/docs/releases/)を使用する場合は、[アップグレード](https://cert-manager.io/docs/releases/)する前に、[certmanager 1.6〜1.11](https://cert-manager.io/docs/releases/)の潜在的な破壊的な変更をお読みください。 + +#### インプレースIngressの変更を無効にする {#disable-in-place-ingress-modification} + +検証のために既存のIngressを再利用するロジックが適切でない場合があります。たとえば、IP許可リストがある場合、またはIngressに対するその他の制限により、パブリックインターネットにアクセスできなくなるIP許可リストがある場合です。 + +毎回動的に作成されたIngressでACME Challenge検証を実行するには、`7.7.0`から`global.issuer.useNewIngressForCerts`の値を`true`に設定できます（デフォルトは`false`）。 + +`useNewIngressForCerts`を`true`に設定するには、`ingressClassName`フィールドがIngressコントローラーでサポートされている必要があります。このフィールドはKubernetes 1.18以降で使用可能ですが、すべてのコントローラーでサポートされているわけではありません。たとえば、[GKE Ingress](https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#deprecated_annotation)を使用している場合は、まだ使用できません。 + +GitLabチャート`7.0-7.6`を実行している既存のクラスターでアップグレード中にこのフィールドを有効にする必要がある場合は、[アップグレード](../installation/upgrade.md#usenewingressforcerts-on-ingresses)手順に従ってください + +### Redis {#redis} + +含まれている[`bitnami/Redis`](https://artifacthub.io/packages/helm/bitnami/redis)サブチャートは、以前にインストールされた`11.3.4`から[バージョン](https://artifacthub.io/packages/helm/bitnami/redis)`16.13.2`に更新されました。これにより、Redisも`6.0.9`から`6.2.7`にアップグレードされます。 + +バンドルされたRedisを使用している場合は、アップグレードする前に手動手順が必要です。[バンドルされたRedisサブチャートのアップグレード](../installation/upgrade.md#update-the-bundled-redis-sub-chart)を参照してください diff --git a/doc-locale/ja-jp/releases/8_0.md b/doc-locale/ja-jp/releases/8_0.md new file mode 100644 index 0000000000..273e0cd35c --- /dev/null +++ b/doc-locale/ja-jp/releases/8_0.md @@ -0,0 +1,106 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers +title: GitLabクラウドネイティブチャート8.0 +--- + +GitLabの`17.0`リリースに伴い、チャートのバージョンを`8.0`に上げました。 + +## 主な変更点の概要 {#summary-of-major-changes} + +- レガシーrunner登録ワークフローは、デフォルトで無効になりました。[新しい登録ワークフローに移行するには、手動での行動が必要です](#runner-workflow-changes)。 +- PostgreSQL 13のサポートは削除されました。アップグレードする前に、PostgreSQL 14以降を実行していることを確認してください。 + +アップグレードに関連するすべての変更については、[GitLab 17の変更点](https://docs.gitlab.com/update/versions/gitlab_17_changes/#1700)を参照してください。 + +## 7.xからのアップグレードパス {#upgrade-path-from-7x} + +チャートの`8.0`バージョンにアップグレードするには、まず、チャートの最新の`7.11.x`リリースにアップグレードする必要があります。最新のパッチについては、[バージョンマッピングの詳細](../installation/version_mappings.md)を確認してください。 + +### 8.8.0へのアップグレード {#upgrade-to-880} + +[`shared-secrets`ジョブ](../charts/shared-secrets.md#disable-functionality)を無効にした場合は、3つの新しいシークレットを手動で作成する必要があります。有効になっている場合(デフォルトの行動)、新しいシークレットが自動的に生成されるため、何もする必要はありません。 + +- `active_record_encryption_primary_key` +- `active_record_encryption_deterministic_key` +- `active_record_encryption_key_derivation_salt` + +シークレットの形式は、[GitLab Railsのシークレットセクション](../installation/secrets.md#gitlab-rails-secret)にあります。 + +これら3つのシークレットを入力する手順は次のとおりです。 + +1. [シークレットをバックアップ](../backup-restore/backup.md#back-up-the-secrets)。 +1. `LC_ALL=C < /dev/urandom tr -dc 'a-zA-Z0-9' | head -c 32`を使用して、3つの異なる32文字のランダムな文字列(新しいシークレットごとに1つ)を生成します +1. `gitlab-secrets.yaml`の最後にシークレットを追加します。シークレットが`production`キーの下にインデントされた状態になっていることを確認します。 + + ```yaml + production: + active_record_encryption_primary_key: + - "" + active_record_encryption_deterministic_key: + - "" + active_record_encryption_key_derivation_salt: "" + ``` + +1. 新しい`secret`リソースを作成します(``をリリースの名前に置き換えます)。 + + ```shell + kubectl create secret generic -rails-secret-v2 --from-file=gitlab-secrets.yaml + ``` + +1. `values.yaml`ファイル内の`global.railsSecrets.secret`を更新して、新しい`-rails-secret-v2`シークレット リソースを指すto>ようにします。 +1. この新しい値でGitLabチャートリリースをアップグレードしますが、他の古い値が引き続き適用されるようにします([たとえば、`--reuse-values`フラグを使用しないでください](../installation/upgrade.md))。 +1. GitLabが期待どおりに動作していることを確認します。そうであれば、古い`-rails-secret`シークレット リソースを削除しても安全です。 + +### 8.6.0へのアップグレード {#upgrade-to-860} + +レジストリメタデータデータベースのデータベース移行を実行するジョブの`app`ラベルが、`registry`から`registry-migrations`に変更され、コンテナレジストリ`Deployment`と`PodDisruptionBudget`のセレクターに関する問題に対処するようになりました。 + +レジストリメタデータデータベースが有効になっていない場合、またはモニタリングやログの生成ソリューションなどの外部ツールで使用していない場合は、何もする必要はありません。このラベルを使用する場合は、それに応じて更新してください。 + +### 8.6.x、8.5.1、8.4.3、8.3.6へのアップグレード {#upgrade-to-86x-851-843-836} + +{{< alert type="note" >}} + +[GitLab NGINXチャート](../charts/nginx/_index.md)を使用しており、独自のNGINX RBACルールを設定している場合にのみ、この変更が適用されます。 + +独自の[外部NGINXチャート](../advanced/external-nginx/_index.md)を使用している場合、またはNGINX RBACルールを変更せずにGitLab NGINXチャートを使用している場合は、このセクションをスキップできます。 + +{{< /alert >}} + +Helm ChartChart> バージョン8.6.0、8.5.1、8.4.3、8.3.6では、Ingress NGINXコントローラーイメージがv1.11.2にバンプされましたが、Ingress NGINXコントローラーチャートのバージョンは依然として4.0.6です。古い`v1.3.1`コントローラーイメージは現在非推奨であり、GitLabチャート9.0での削除が予定されています。 + +前述のチャートバージョンにアップグレードすると、デフォルトで`v1.11.2`が設定されます。`nginx-ingress.rbac.create`を設定するか、`false`に設定すると、チャートは自動的に`v1.3.1`にフォールバックします(Geo `nginx-ingress-geo.rbac.create`にも同じことが当てはまります)。これは、`v1.11.2`が新しいRBACルールを必要とするためです。これは、[NGINXチャート](../charts/nginx/_index.md)に追加しました。 + +独自のNGINX RBACルールを管理しており、GitLab 18.0(Helmチャート9.0)で適用される前に新しい`v1.11.2`を使用する場合は、次の手順を実行します。 + +1. 新しいRBACルールをクラスターに適用します([例](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/3901/diffs?commit_id=93a3cbdb5ad83db95e12fa6c2145df0800493d8b))。 + + ```yaml + - apiGroups: + - discovery.k8s.io + resources: + - endpointslices + verbs: + - list + - watch + - get + ``` + +1. 次の手順でコントローラーイメージ`v1.11.2`を有効にします。 + + ```yaml + nginx-ingress: + rbac: + create: false + controller: + image: + disableFallback: true + ``` + +### Runnerワークフローの変更 {#runner-workflow-changes} + +レガシーrunner登録ワークフローは、デフォルトで無効になりました。[新しい登録ワークフローに移行](https://docs.gitlab.com/tutorials/automate_runner_creation/)するか、[レガシーワークフローを再度有効にする](https://docs.gitlab.com/administration/settings/continuous_integration/#enable-runner-registrations-tokens)必要があります。 + +移行手順については、[runnerサブチャートのドキュメント](../charts/gitlab/gitlab-runner/_index.md#requirements)を参照してください。 diff --git a/doc-locale/ja-jp/releases/9_0.md b/doc-locale/ja-jp/releases/9_0.md new file mode 100644 index 0000000000..152062350b --- /dev/null +++ b/doc-locale/ja-jp/releases/9_0.md @@ -0,0 +1,70 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers +title: GitLabクラウドネイティブチャート9.0 +--- + +GitLabの`18.0`のリリースに伴い、チャートのバージョンを`9.0`に上げました。 + +## 主な変更点の概要 {#summary-of-major-changes} + +- PostgreSQL 14および15のサポートは削除されました。アップグレードする前に、PostgreSQL 16が実行されていることを確認してください。 +- バンドルされているPrometheusチャートが15.3から27.11にアップデートされました。 +- Prometheusチャートのアップグレードに伴い、Prometheusのバージョンが2.38から3.0にアップデートされました。 + +## 8.xからのアップグレードパス {#upgrade-path-from-8x} + +### 9.3.0へのアップグレード {#upgrade-to-930} + +#### Cert-managerのアップグレード {#cert-manager-upgrade} + +Cert-managerサブチャートは、1.12.xから最新リリースにアップグレードされています。これらの新しいcert-manager[リリース](https://helm.sh/docs/topics/charts/#schema-files)では、[Helm](https://helm.sh/docs/topics/charts/#schema-files)スキーマ検証が実装され、チャートの値の構造が検証されます。 + +現在`certmanager.install`の値を設定している場合は、`installCertmanager`に移行してください。バージョン9.0以降、この新しいパラメータの使用を開始できますが、古いパラメータを引き続き使用すると、バージョン9.3へのアップグレード時にアップグレードチェックが失敗します。 + +バンドルされたcert-managerを使用する場合は、cert-managerのリリースノートで、その他の重要な変更を確認してください。 + +- [v1.12からのアップグレード](https://cert-manager.io/docs/releases/upgrading/upgrading-1.12/) +- [v1.16からのアップグレード](https://cert-manager.io/docs/releases/upgrading/upgrading-1.16-1.17/) + +### 9.0.0へのアップグレード {#upgrade-to-900} + +#### PostgreSQL {#postgresql} + +GitLab 18.0 [リリース](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/)の一部として、[PostgreSQL 14および15のサポートは非推奨になりました](https://handbook.gitlab.com/handbook/engineering/infrastructure-platforms/data-access/database-framework/postgresql-upgrade-cadence/)。バンドルされているPostgreSQLサブチャートは、デフォルトでPostgreSQL 16になるようにアップグレードされました。データベースをアップグレードしてください。 + +[バンドル](../installation/database_upgrade.md#steps-for-upgrading-the-bundled-postgresql)されているPostgreSQLデータベースをアップグレードする手順は、アップグレード手順に記載されています。 + +#### Prometheusのアップグレード {#prometheus-upgrade} + +GitLabチャートにバンドルされているPrometheusサブチャートを使用していない場合は、このセクションをスキップできます。 + +バンドルされているPrometheusサブチャートが15.3から27.11にアップデートされ、Prometheus 2.xではなくPrometheus 3がバンドルされるようになりました。使用している[機能](https://prometheus.io/docs/prometheus/3.0/migration/)が影響を受ける場合は、[Prometheus 3](https://prometheus.io/docs/prometheus/3.0/migration/)移行ガイドを確認してください。 + +ここでは最も重要な情報に焦点を当てていますが、変更の完全なリストについては、アップストリームの[Prometheus](https://github.com/prometheus-community/helm-charts/tree/3aa3bbb4815854836033f42ff7fc41ed27d2904d/charts/prometheus#upgrading-chart)チャートアップグレードのドキュメントを参照してください。 + +- Prometheusチャートは、HelmおよびKubernetesのラベル付けのベストプラクティスに合わせて、いくつかの（セレクター）ラベルをアップデートします。アップグレードする前に、古いワークロードを削除する必要があります。 + + ```shell + kubectl delete deployment -l app=prometheus,heritage=Helm,release= + kubectl delete statefulset -l app=prometheus,heritage=Helm,release= + kubectl delete daemonset -l app=prometheus,heritage=Helm,release= + ``` + + Prometheusリソースのラベルに依存する他のサービスがある場合は、これに応じてアップデートしてください。 + +- バンドルされているkube-state-metrics、alertmananger、node exporter、またはpushgatewayを有効にした場合は、アップストリームのアップグレードの変更履歴に従って値をアップデートする必要があります。 + + - [16.0での変更](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#to-160)、 + - [17.0での変更](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#to-170)、 + - [18.0での変更](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#to-180)、および + - [19.0での変更](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#to-190)。 + +- `configmapReload.prometheus.extraArgs`は、[20.0](https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus#to-200)へのアップグレードに従って、互換性がなくなりました。 + +#### NGINXコントローラーイメージのアップグレードには、新しいRBACルールが必要です {#nginx-controller-image-upgrade-requires-new-rbac-rules} + +[GitLab NGINX](../charts/nginx/_index.md)チャートを使用しており、独自のNGINX RBACルールを設定している場合は、新しいNGINXコントローラーイメージバージョンで必要な新しいルールを含めるようにアップデートする必要があります。 + +[8.6](8_0.md#upgrade-to-86x-851-843-836)のアップグレード ノートで詳細をお読みください。 diff --git a/doc-locale/ja-jp/troubleshooting/_index.md b/doc-locale/ja-jp/troubleshooting/_index.md new file mode 100644 index 0000000000..1290355f49 --- /dev/null +++ b/doc-locale/ja-jp/troubleshooting/_index.md @@ -0,0 +1,643 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: GitLabチャートのトラブルシューティング +--- + +## アップグレードに失敗しました:ジョブに失敗しました:BackoffLimitExceeded {#upgrade-failed-job-failed-backofflimitexceeded} + +[チャートの6.0バージョンへのアップグレード](../releases/6_0.md#upgrade-path-from-5x)時にこのエラーが発生した場合、適切なアップグレードパスに従っていない可能性があります。まず、最新の5.10.xバージョンにアップグレードする必要があります。 + +1. すべてのリリースをリストして、GitLab Helmリリース名を特定します（リリースが`default` K8sネームスペースにデプロイされていない場合は、`-n `を含める必要があります）。 + + ```shell + helm ls + ``` + +1. GitLab Helmリリースの名前が`gitlab`であると仮定すると、リリース履歴を確認し、最後に成功したリビジョンを特定する必要があります（`DESCRIPTION`でリビジョンの状態を確認できます）。 + + ```shell + helm history gitlab + ``` + +1. 最後に成功したリビジョンが`1`であると仮定すると、このコマンドを使用してロールバックします。 + + ```shell + helm rollback gitlab 1 + ``` + +1. ``を適切なチャートバージョンに置き換えて、アップグレードコマンドを再実行します。 + + ```shell + helm upgrade --version=5.10. + ``` + +1. この時点で、`--version`オプションを使用して特定の6.x.xチャートバージョンを渡すか、GitLabの最新バージョンにアップグレードするためのオプションを削除できます。 + + ```shell + helm upgrade --install gitlab gitlab/gitlab + ``` + +コマンドライン引数の詳細については、[Helmを使用したデプロイ](../installation/deployment.md#deploy-using-helm)セクションを参照してください。チャートバージョンとGitLabバージョンのマッピングについては、[GitLabバージョンマッピング](../installation/version_mappings.md)をお読みください。 + +## アップグレードに失敗しました: 「$name」にはデプロイされたリリースがありません {#upgrade-failed-name-has-no-deployed-releases} + +このエラーは、最初のインストールが失敗した場合、2回目のインストール/アップグレードで発生します。 + +最初のインストールが完全に失敗し、GitLabが動作しなかった場合は、再度インストールする前に、まず失敗したインストールをパージする必要があります。 + +```shell +helm uninstall +``` + +代わりに、最初のインストールコマンドがタイムアウトしたが、GitLabが正常に起動した場合は、`--force`フラグを`helm upgrade`コマンドに追加して、エラーを無視し、リリースの更新を試みることができます。 + +それ以外の場合、GitLabチャートのデプロイが以前に成功した後にこのエラーが発生した場合は、バグが発生しています。当社の[イシュートラッカー](https://gitlab.com/gitlab-org/charts/gitlab/-/issues)でイシューをオープンし、この問題からCIサーバーを復旧した[イシュー#630](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/630)もご確認ください。 + +## エラー: このコマンドには2つの引数が必要です: リリース名、チャートパス {#error-this-command-needs-2-arguments-release-name-chart-path} + +このようなエラーは、`helm upgrade`を実行したときに、パラメータにスペースが含まれている場合に発生する可能性があります。次の例では、`Test Username`が原因です。 + +```shell +helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name=Test Username ... +``` + +修正するには、パラメータをシングルクォートで囲んで渡します。 + +```shell +helm upgrade gitlab gitlab/gitlab --timeout 600s --set global.email.display_name='Test Username' ... +``` + +## アプリケーションコンテナの初期化が常に実行される {#application-containers-constantly-initializing} + +Sidekiq、Webservice、またはその他のRailsベースのコンテナが常に初期化状態になっている場合は、`dependencies`コンテナがパスするのを待っている可能性があります。 + +特定のPodのログを`dependencies`コンテナについて確認すると、次のメッセージが繰り返し表示されることがあります。 + +```plaintext +Checking database connection and schema version +WARNING: This version of GitLab depends on gitlab-shell 8.7.1, ... +Database Schema +Current version: 0 +Codebase version: 20190301182457 +``` + +これは、`migrations`ジョブがまだ完了していないことを示しています。このジョブの目的は、データベースのシードと、関連するすべての移行が適切に行われることを保証することです。アプリケーションコンテナは、データベースが予想されるデータベースバージョン以上になるまで待機しようとしています。これは、アプリケーションがコードベースの期待値とスキーマが一致しないために誤動作しないようにするためです。 + +1. `migrations`ジョブを見つけます。`kubectl get job -lapp=migrations` +1. ジョブによって実行されているPodを見つけます。`kubectl get pod -lbatch.kubernetes.io/job-name=` +1. `STATUS`列を確認して、出力を調べます。 + +`STATUS`が`Running`の場合は、続行します。`STATUS`が`Completed`の場合、アプリケーションコンテナは、次のチェックがパスした直後に開始されます。 + +このポッドからのログを調べます。`kubectl logs ` + +このジョブの実行中に発生したエラーはすべて対処する必要があります。これらは、解決されるまでアプリケーションの使用をブロックします。考えられる問題は次のとおりです。 + +- 設定されたPostgreSQLデータベースへの到達不能または認証の失敗 +- 設定されたRedisサービスへの到達不能または認証の失敗 +- Gitalyインスタンスに到達できない + +## 設定変更の適用 {#applying-configuration-changes} + +次のコマンドは、`gitlab.yaml`に加えられた更新を適用するために必要な操作を実行します。 + +```shell +helm upgrade -f gitlab.yaml +``` + +## 登録に失敗したインクルードされたGitLab Runner {#included-gitlab-runner-failing-to-register} + +これは、runner登録トークンがGitLabで変更された場合に発生する可能性があります。（これは、バックアップを復元した後に頻繁に発生します） + +1. GitLabインストールの`admin/runners` Webページにある新しい共有runnerトークンを見つけます。 +1. Kubernetesに保存されている既存のrunnerトークンシークレットの名前を見つけます + + ```shell + kubectl get secrets | grep gitlab-runner-secret + ``` + +1. 既存のシークレットを削除します + + ```shell + kubectl delete secret + ``` + +1. 2つのキー（共有トークンを持つ`runner-registration-token`と、空の`runner-token`）で新しいシークレットを作成します + + ```shell + kubectl create secret generic --from-literal=runner-registration-token= --from-literal=runner-token="" + ``` + +## リダイレクトが多すぎる {#too-many-redirects} + +これは、NGINX Ingressの前にTLS終端があり、tlsシークレットが設定で指定されている場合に発生する可能性があります。 + +1. `global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect": "false"`を設定するように値を更新します + + 値ファイル経由: + + ```yaml + # values.yaml + global: + ingress: + annotations: + "nginx.ingress.kubernetes.io/ssl-redirect": "false" + ``` + + Helm CLI経由: + + ```shell + helm ... --set-string global.ingress.annotations."nginx.ingress.kubernetes.io/ssl-redirect"=false + ``` + +1. 変更を適用します。 + +{{< alert type="note" >}} + +外部サービスをSSL終端に使用する場合、そのサービスはhttpsへのリダイレクトを担当します（必要に応じて）。 + +{{< /alert >}} + +## イミュータブルフィールドエラーでアップグレードが失敗する {#upgrades-fail-with-immutable-field-error} + +### spec.clusterIP {#specclusterip} + +これらのチャートの3.0.0リリースより前は、実際の値（`""`）がないにもかかわらず、`spec.clusterIP`プロパティが[いくつかのサービスに入力されていました](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1710)。これはバグであり、Helm 3のプロパティの3方向マージで問題が発生します。 + +チャートがHelm 3でデプロイされると、さまざまなサービスから`clusterIP`プロパティを収集して、それらをHelmに提供される値に入力するか、影響を受けるサービスをKubernetesから削除しない限り、_可能なアップグレードパス_はありません。 + +[このチャートの3.0.0リリースでこのエラーが修正されました](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1710)が、手動による修正が必要です。 + +これは、影響を受けるすべてのサービスを削除するだけで解決できます。 + +1. 影響を受けるすべてのサービスを削除します: + + ```shell + kubectl delete services -lrelease=RELEASE_NAME + ``` + +1. Helm経由でアップグレードを実行します。 +1. 今後のアップグレードでは、このエラーは発生しません。 + +{{< alert type="note" >}} + +これにより、使用中の場合、このチャートのNGINX Ingressの`LoadBalancer`の動的な値が変更されます。`externalIP`に関する詳細については、[グローバルIngress設定ドキュメント](../charts/globals.md#configure-ingress-settings)を参照してください。DNSレコードの更新が必要になる場合があります。 + +{{< /alert >}} + +### spec.selector {#specselector} + +Sidekiqポッドは、チャートリリース`3.0.0`より前に一意のセレクターを受信しませんでした。[この問題については、ドキュメントに記載されています](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/663)。 + +Helmを使用した`3.0.0`へのアップグレードでは、古いSidekiqデプロイメントが自動的に削除され、Sidekiqの`Deployments`、`HPAs`、および`Pods`の名前に`-v1`が付加された新しいものが作成されます。 + +`3.0.0`のインストール時にSidekiqデプロイメントでこのエラーが引き続き発生する場合は、次の手順で解決してください。 + +1. Sidekiqサービスを削除します + + ```shell + kubectl delete deployment --cascade -lrelease=RELEASE_NAME,app=sidekiq + ``` + +1. Helm経由でアップグレードを実行します。 + +### 種類Deploymentで「RELEASE-NAME-cert-manager」にできません {#cannot-patch-release-name-cert-manager-with-kind-deployment} + +**CertManager**バージョン`0.10`からのアップグレードでは、多くの破壊的な変更が導入されました。古いカスタムリソース定義をアンインストールし、Helmの追跡から削除して、再度インストールする必要があります。 + +Helmチャートはデフォルトでこれを行おうとしますが、このエラーが発生した場合は、手動でアクションを実行する必要がある場合があります。 + +このエラーメッセージが発生した場合、アップグレードでは、新しいカスタムリソース定義がデプロイメントに実際に適用されるようにするために、通常よりも1つ多くのステップが必要になります。 + +1. 古い**CertManager**デプロイメントを削除します。 + + ```shell + kubectl delete deployments -l app=cert-manager --cascade + ``` + +1. 再度アップグレードを実行します。今回は、新しいカスタムリソース定義をインストールします + + ```shell + helm upgrade --install --values - YOUR-RELEASE-NAME gitlab/gitlab < <(helm get values YOUR-RELEASE-NAME) + ``` + +### 種類Deploymentで`gitlab-kube-state-metrics`にできません {#cannot-patch-gitlab-kube-state-metrics-with-kind-deployment} + +**Prometheus**バージョン`11.16.9`から`15.0.4`へのアップグレードでは、[kube-state-metricsデプロイメント](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-state-metrics)で使用されるセレクターが変更されます。これはデフォルトで無効になっています（`prometheus.kubeStateMetrics.enabled=false`）。 + +このエラーメッセージが発生した場合、つまり`prometheus.kubeStateMetrics.enabled=true`を意味する場合は、アップグレードには[追加の手順](https://artifacthub.io/packages/helm/prometheus-community/prometheus#to-15-0)が必要です。 + +1. 古い**kube-state-metrics**デプロイメントを削除します。 + + ```shell + kubectl delete deployments.apps -l app.kubernetes.io/instance=RELEASE_NAME,app.kubernetes.io/name=kube-state-metrics --cascade=orphan + ``` + +1. Helm経由でアップグレードを実行します。 + +## `ImagePullBackOff`、`Failed to pull image`および`manifest unknown`エラー {#imagepullbackoff-failed-to-pull-image-and-manifest-unknown-errors} + +[`global.gitlabVersion`](../charts/globals.md#gitlab-version)を使用している場合は、まずそのプロパティを削除します。[チャートとGitLabの間のバージョンマッピング](../installation/version_mappings.md)を確認し、`helm`コマンドで`gitlab/gitlab`チャートの互換性のあるバージョンを指定します。 + +## アップグレードに失敗しました: `helm 2to3 convert`の後の「できません...」 {#upgrade-failed-cannot-patch--after-helm-2to3-convert} + +これは既知の問題です。Helm 2リリースをHelm 3に移行した後、後続のアップグレードが失敗する可能性があります。詳細な説明とについては、[Helm v2からHelm v3への移行](../installation/migration/helm.md#known-issues)を参照してください。 + +## アップグレードに失敗しました: mailroomのタイプが一致しません: `%!t()` {#upgrade-failed-type-mismatch-on-mailroom-tnil} + +このようなエラーは、マップを予期するキーに対して有効なマップを指定しない場合に発生する可能性があります。 + +たとえば、次の設定ではこのエラーが発生します。 + +```yaml +gitlab: + mailroom: +``` + +これを修正するには、次のいずれかの操作を行います。 + +1. `gitlab.mailroom`に有効なマップを提供します。 +1. `mailroom`キーを完全に削除します。 + +オプションのキーの場合、空のマップ（`{}`）は有効な値であることに注意してください。 + +## エラー: `cannot drop view pg_stat_statements because extension pg_stat_statements requires it` {#error-cannot-drop-view-pg_stat_statements-because-extension-pg_stat_statements-requires-it} + +Helmチャートインスタンスでを復元するときに、このエラーが発生する可能性があります。次の手順をとして使用します。 + +1. `toolbox`ポッド内で、DBコンソールを開きます: + + ```shell + /srv/gitlab/bin/rails dbconsole -p + ``` + +1. 拡張機能をドロップします: + + ```shell + DROP EXTENSION pg_stat_statements; + ``` + +1. プロセスを実行します。 +1. が完了したら、DBコンソールで拡張機能を再作成します: + + ```shell + CREATE EXTENSION pg_stat_statements; + ``` + +`pg_buffercache`拡張機能で同じ問題が発生した場合は、上記と同じ手順に従ってドロップして再作成します。 + +このエラーの詳細については、イシュー[\#2469](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2469)を参照してください。 + +## バンドルされたPostgreSQLポッドが起動に失敗しました: `database files are incompatible with server` {#bundled-postgresql-pod-fails-to-start-database-files-are-incompatible-with-server} + +GitLab Helmチャートの新しいバージョンにアップグレードした後、バンドルされたPostgreSQLポッドに次のエラーメッセージが表示されることがあります。 + +```plaintext +gitlab-postgresql FATAL: database files are incompatible with server +gitlab-postgresql DETAIL: The data directory was initialized by PostgreSQL version 11, which is not compatible with this version 12.7. +``` + +これに対処するには、[Helmロールバック](https://helm.sh/docs/helm/helm_rollback/)を実行してチャートの以前のバージョンに戻し、[アップグレードガイド](../installation/upgrade.md)の手順に従って、バンドルされたPostgreSQLバージョンをアップグレードします。PostgreSQLが正しくアップグレードされたら、GitLab Helmチャートのアップグレードを再度試してください。 + +## バンドルされたNGINX Ingressポッドが起動に失敗しました: `Failed to watch *v1beta1.Ingress` {#bundled-nginx-ingress-pod-fails-to-start-failed-to-watch-v1beta1ingress} + +Kubernetesバージョン1.22以降を実行している場合、バンドルされたNGINX Ingressポッドに次のエラー メッセージが表示されることがあります。 + +```plaintext +Failed to watch *v1beta1.Ingress: failed to list *v1beta1.Ingress: the server could not find the requested resource +``` + +これに対処するには、Kubernetesバージョンが1.21以前であることを確認してください。Kubernetes 1.22以降のNGINX Ingressのの詳細については、[\#2852](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2852)を参照してください。 + +## `/api/v4/jobs/request`エンドポイントでの負荷の増加 {#increased-load-on-apiv4jobsrequest-endpoint} + +オプション`workhorse.keywatcher`が`false`に設定されている場合、`/api/*`をするデプロイメントでこの問題が発生する可能性があります。確認するには、次の手順に従います。 + +1. `/api/*`をするポッド内のコンテナ`gitlab-workhorse`にアクセスします: + + ```shell + kubectl exec -it --container=gitlab-workhorse -- /bin/bash + ``` + +1. ファイル`/srv/gitlab/config/workhorse-config.toml`を調べます。`[redis]`設定が見つからない可能性があります: + + ```shell + grep '\[redis\]' /srv/gitlab/config/workhorse-config.toml + ``` + +`[redis]`設定が存在しない場合、デプロイメント中に`workhorse.keywatcher`フラグが`false`に設定されたため、`/api/v4/jobs/request`エンドポイントで追加の負荷が発生します。これを修正するには、`webservice`チャートで`keywatcher`を有効にします: + +```yaml +workhorse: + keywatcher: true +``` + +## Git over : `the remote end hung up unexpectedly` {#git-over-ssh-the-remote-end-hung-up-unexpectedly} + +経由のGitオペレーションは、次のエラーで断続的に失敗する可能性があります。 + +```plaintext +fatal: the remote end hung up unexpectedly +fatal: early EOF +fatal: index-pack failed +``` + +このエラーには、いくつかの考えられる原因があります。 + +- **ネットワークタイムアウト**: + + Gitクライアントは、オブジェクトを圧縮するときなど、接続を開いてアイドル状態のままにすることがあります。HAProxyの`timeout client`のようなは、これらのアイドル状態の接続が終了する原因となる可能性があります。 + + `sshd`でキープアライブを設定できます: + + ```yaml + gitlab: + gitlab-shell: + config: + clientAliveInterval: 15 + ``` + +- **`gitlab-shell`メモリ**: + + デフォルトでは、チャートはGitLab Shellメモリに制限を設定しません。`gitlab.gitlab-shell.resources.limits.memory`が低すぎる場合、経由のGitオペレーションはこれらのエラーで失敗する可能性があります。 + + ネットワーク経由のではなく、これがメモリ制限によって引き起こされていることを確認するには、`kubectl describe nodes`を実行します。 + + ```plaintext + System OOM encountered, victim process: gitlab-shell + Memory cgroup out of memory: Killed process 3141592 (gitlab-shell) + ``` + +## エラー: `kex_exchange_identification: Connection closed by remote host` {#error-kex_exchange_identification-connection-closed-by-remote-host} + +次のエラーがGitLab Shellログに表示されることがあります。 + +```plaintext +subcomponent":"ssh","time":"2025-02-21T19:07:52Z","message":"kex_exchange_identification: Connection closed by remote host\r"} +``` + +このエラーは、OpenSSH `sshd`が準備と活性プローブを処理できないことが原因です。このエラーを解決するには、設定で`sshDaemon: openssh`を`sshDaemon: gitlab-ssd`に変更して、代わりに[`gitlab-sshd`](../charts/gitlab/gitlab-shell/_index.md#configuration)を使用します: + +```yaml +gitlab: + gitlab-shell: + sshDaemon: gitlab-sshd +``` + +## 設定: `mapping values are not allowed in this context` {#yaml-configuration-mapping-values-are-not-allowed-in-this-context} + + 設定に先頭のスペースが含まれている場合、次のエラーメッセージが表示されることがあります。 + +```plaintext +template: /var/opt/gitlab/templates/workhorse-config.toml.tpl:16:98: + executing \"/var/opt/gitlab/templates/workhorse-config.toml.tpl\" at : + error calling YAML: + yaml: line 2: mapping values are not allowed in this context +``` + +これに対処するには、設定に先頭のスペースがないことを確認します。 + +たとえば、これを変更します: + +```yaml + key1: value1 + key2: value2 +``` + +... これに変更します: + +```yaml +key1: value1 +key2: value2 +``` + +## と証明書 {#tls-and-certificates} + +GitLabインスタンスがプライベート公開認証局（CA）を信頼する必要がある場合、GitLabはオブジェクトストレージ、Elasticsearch、Jira、Jenkinsなどの他のサービスとのハンドシェイクに失敗する可能性があります: + +```plaintext +error: certificate verify failed (unable to get local issuer certificate) +``` + +プライベート公開認証局（CA）によって署名された証明書の部分的信頼は、次の場合に発生する可能性があります: + +- 提供された証明書が個別のファイルにない。 +- 証明書initコンテナが必要なすべてのステップを実行しない。 + +また、GitLabは主にRuby on RailsとGoで記述されており、各のライブラリの動作は異なります。この違いにより、ジョブログがGitLabでレンダリングに失敗するが、rawジョブログが問題なくダウンロードされるなどの問題が発生する可能性があります。 + +さらに、`proxy_download`設定によっては、信頼ストアが正しく設定されている場合、ブラウザは問題なくオブジェクトストレージにリダイレクトされます。同時に、1つ以上のGitLabコンポーネントによるハンドシェイクが引き続き失敗する可能性があります。 + +### 証明書の信頼設定と {#certificate-trust-setup-and-troubleshooting} + +証明書の問題のの一環として、次のことを確認してください: + +- 信頼する必要がある各証明書のシークレットを作成します。 +- ファイルごとに1つの証明書のみを提供します。 + + ```plaintext + kubectl create secret generic custom-ca --from-file=unique_name=/path/to/cert + ``` + + この例では、証明書はキー名`unique_name`を使用して保存されます + +バンドルまたはチェーンを提供する場合、一部のGitLabコンポーネントは機能しません。 + +`kubectl get secrets`および`kubectl describe secrets/secretname`でシークレットをします。これにより、`Data`の下の証明書のキー名が表示されます。 + +`global.certificates.customCAs`を使用して信頼するための追加の証明書をします[チャートグローバル](../charts/globals.md#custom-certificate-authorities)。 + +ポッドがデプロイされると、initコンテナは証明書をマウントし、GitLabコンポーネントがそれらを使用できるように設定します。initコンテナは`registry.gitlab.com/gitlab-org/build/cng/alpine-certificates`です。 + +追加の証明書は`/usr/local/share/ca-certificates`でコンテナにマウントされ、シークレットキー名が証明書ファイル名として使用されます。 + +initコンテナは`/scripts/bundle-certificates` ([ソース](https://gitlab.com/gitlab-org/build/CNG-mirror/-/blob/master/certificates/scripts/bundle-certificates)) を実行します。そのスクリプトでは、`update-ca-certificates`: + +1. `/usr/local/share/ca-certificates`から`/etc/ssl/certs`にカスタム証明書をコピーします。 +1. バンドル`ca-certificates.crt`をコンパイルします。 +1. 各証明書のハッシュを生成し、Railsに必要なハッシュを使用してシンボリックリンクを作成します。証明書バンドルは、警告付きでスキップされます: + + ```plaintext + WARNING: unique_name does not contain exactly one certificate or CRL: skipping + ``` + +[initコンテナの状態とログのします](https://kubernetes.io/docs/tasks/debug/debug-application/debug-init-containers/)。たとえば、証明書initコンテナのログを表示し、警告を確認するには: + +```plaintext +kubectl logs gitlab-webservice-default-pod -c certificates +``` + +### Railsコンソールで確認する {#check-on-the-rails-console} + +ツールボックスポッドを使用して、Railsが提供した証明書を信頼するかどうかを確認します。 + +1. Railsコンソールを起動します（``をGitLabがインストールされているネームスペースに置き換えます）: + + ```shell + kubectl exec -ti $(kubectl get pod -n -lapp=toolbox -o jsonpath='{.items[0].metadata.name}') -n -- bash + /srv/gitlab/bin/rails console + ``` + +1. Railsが証明書公開認証局（CA）を確認する場所を確認します: + + ```ruby + OpenSSL::X509::DEFAULT_CERT_DIR + ``` + +1. RailsコンソールでHTTPSを実行します: + + ```ruby + ## Configure a web server to connect to: + uri = URI.parse("https://myservice.example.com") + + require 'openssl' + require 'net/http' + Rails.logger.level = 0 + OpenSSL.debug=1 + http = Net::HTTP.new(uri.host, uri.port) + http.set_debug_output($stdout) + http.use_ssl = true + + http.verify_mode = OpenSSL::SSL::VERIFY_PEER + # http.verify_mode = OpenSSL::SSL::VERIFY_NONE # TLS verification disabled + + response = http.request(Net::HTTP::Get.new(uri.request_uri)) + ``` + +### Initコンテナの {#troubleshoot-the-init-container} + +Dockerを使用して証明書コンテナを実行します。 + +1. ディレクトリ構造を設定し、証明書をします: + + ```shell + mkdir -p etc/ssl/certs usr/local/share/ca-certificates + + # The secret name is: my-root-ca + # The key name is: corporate_root + + kubectl get secret my-root-ca -ojsonpath='{.data.corporate_root}' | \ + base64 --decode > usr/local/share/ca-certificates/corporate_root + + # Check the certificate is correct: + + openssl x509 -in usr/local/share/ca-certificates/corporate_root -text -noout + ``` + +1. 正しいコンテナのバージョンを決定します。 + + ```shell + kubectl get deployment -lapp=webservice -ojsonpath='{.items[0].spec.template.spec.initContainers[0].image}' + ``` + +1. `etc/ssl/certs`コンテンツの準備を実行するコンテナを実行します。 + + ```shell + docker run -ti --rm \ + -v $(pwd)/etc/ssl/certs:/etc/ssl/certs \ + -v $(pwd)/usr/local/share/ca-certificates:/usr/local/share/ca-certificates \ + registry.gitlab.com/gitlab-org/build/cng/gitlab-base:v15.10.3 + ``` + +1. 証明書が正しくビルドされていることを確認してください。 + + - `etc/ssl/certs/corporate_root.pem`が作成されているはずです。 + - ハッシュされたファイル名があり、それが証明書自体へのシンボリックリンクである必要があります（`etc/ssl/certs/1234abcd.0`など）。 + - ファイルとシンボリックリンクは次のように表示されるはずです。 + + ```shell + ls -l etc/ssl/certs/ | grep corporate_root + ``` + + 次に例を示します。 + + ```plaintext + lrwxrwxrwx 1 root root 20 Oct 7 11:34 28746b42.0 -> corporate_root.pem + -rw-r--r-- 1 root root 1948 Oct 7 11:34 corporate_root.pem + ``` + +## リダイレクト {#308-permanent-redirect-causing-a-redirect-loop}を引き起こす`308: Permanent Redirect` + +`308: Permanent Redirect`は、ロードバランサーが暗号化されていないトラフィック（HTTP）をNGINXに送信するように設定されている場合に発生する可能性があります。NGINXはデフォルトで`HTTP`から`HTTPS`へのリダイレクトを行うため、「リダイレクト」が発生する可能性があります。 + +この問題を[修正するには、NGINXの`use-forwarded-headers`を有効にします](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#use-forwarded-headers)。 + +## `nginx-controller`ログおよび`404`エラーの「無効な単語」エラー {#invalid-word-errors-in-the-nginx-controller-logs-and-404-errors} + + 6.6以降にすると、にインストールされているアプリケーションのまたはサードパーティドメインにアクセスしたときに`404`のコードが表示されたり、`gitlab-nginx-ingress-controller`ログに「無効な単語」エラーが表示されたりする場合があります: + +```console +gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.162001 7 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-688hr controller W1116 19:03:13.465487 7 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.233577 6 store.go:846] skipping ingress gitlab/gitlab-kas: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.536534 6 store.go:846] skipping ingress gitlab/gitlab-webservice-default: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:12.848844 6 store.go:846] skipping ingress gitlab/gitlab-webservice-default-smartcard: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.161640 6 store.go:846] skipping ingress gitlab/gitlab-minio: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.465425 6 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass +``` + +その場合は、[ ](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)の使用について、 とサードパーティの をしてください。`nginx-ingress.controller.config.annotation-value-word-blocklist`を調整または変更する必要がある場合があります。 + +詳細については、[ ](../charts/nginx/_index.md#annotation-value-word-blocklist)をしてください。 + +### マウントに時間がかかる {#volume-mount-takes-a-long-time} + +`gitaly`や`toolbox`など、大きなをマウントするには時間がかかる場合があります。がの`securityContext`に合わせてのコンテンツのを再帰的に変更するためです。 + + 1.23以降では、この問題をするために`securityContext.fsGroupChangePolicy`を`OnRootMismatch`にできます。このフラグは、すべてのサブでされています。 + +サブの例を次に示します。 + +```yaml +gitlab: + gitaly: + securityContext: + fsGroupChangePolicy: "OnRootMismatch" +``` + +詳細については、[ドキュメント](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)をしてください。 + +`fsGroupChangePolicy`をしていない の場合、`securityContext`のを変更または完全に削除することで、問題をできます。 + +```yaml +gitlab: + gitaly: + securityContext: + fsGroup: "" + runAsUser: "" +``` + +{{< alert type="note" >}} + +構文例では、`securityContext`が完全に削除されます。`securityContext: {}`または`securityContext:`をしても、が とが指定したをする方法では機能しません。 + +{{< /alert >}} + +### 断続的な502エラー {#intermittent-502-errors} + +のによって処理されているがメモリ制限を超えると、のOOMKillerによって強制終了されます。ただし、を強制終了しても、必ずしも 自体が強制終了または再起動されるとは限りません。この状態になると、は`502`を返します。ログでは、これは、`502`エラーのログが記録された直後にされた として表示されます。 + +```shell +2024-01-19T14:12:08.949263522Z {"correlation_id":"XXXXXXXXXXXX","duration_ms":1261,"error":"badgateway: failed to receive response: context canceled".... +2024-01-19T14:12:24.214148186Z {"component": "gitlab","subcomponent":"puma.stdout","timestamp":"2024-01-19T14:12:24.213Z","pid":1,"message":"- Worker 2 (PID: 7414) booted in 0.84s, phase: 0"} +``` + +この問題を解決するには、[ のメモリ制限を引き上げます](../charts/gitlab/webservice/_index.md#memory-requestslimits)。 + +### アップグレードに失敗しました-`cannot patch "gitlab-prometheus-server" with kind Deployment` {#upgrade-failed---cannot-patch-gitlab-prometheus-server-with-kind-deployment} + + 9.0で、主要のサブをしました。のセレクターとが変更されたため、手動での操作が必要です。 + + をするには、[ガイド](../releases/9_0.md#prometheus-upgrade)にしてください。 + +## ののアップロードが失敗しました {#toolbox-backup-failing-on-upload} + +次のようなエラーで へのアップロードを試みると、が失敗する可能性があります: + +```plaintext +An error occurred (XAmzContentSHA256Mismatch) when calling the UploadPart operation: The Content-SHA256 you specified did not match what we received +``` + +これは、`awscli`ツールと サービスの間に互換性がないことが原因である可能性があります。このは、Dell ECSを使用している場合にされています。このを回避するには、[データ整合性保護を無効にする](../backup-restore/backup.md#data-integrity-protection-with-awscli)ことができます。 diff --git a/doc-locale/ja-jp/troubleshooting/kubernetes_cheat_sheet.md b/doc-locale/ja-jp/troubleshooting/kubernetes_cheat_sheet.md new file mode 100644 index 0000000000..23f722ea26 --- /dev/null +++ b/doc-locale/ja-jp/troubleshooting/kubernetes_cheat_sheet.md @@ -0,0 +1,311 @@ +--- +stage: GitLab Delivery +group: Self Managed +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +title: Kubernetesチートシート +--- + +{{< details >}} + +- プラン:Free, Premium, Ultimateプラン +- 提供:GitLab Self-Managed + +{{< /details >}} + +これは、GitLabサポートがトラブルシューティングの際に使用するKubernetesに関する有用な情報の一覧です。誰でもサポートチームが集めた知識を利用できるように、GitLabはこれを公開しています + +{{< alert type="warning" >}} + +これらのコマンドは、Kubernetesコンポーネントを**変更または破損させる可能性**があるため、ご自身の責任で使用してください。 + +{{< /alert >}} + +[有料プラン](https://about.gitlab.com/pricing/)をご利用で、これらのコマンドの使用方法が不明な場合は、[サポートにお問い合わせ](https://about.gitlab.com/support/)いただくことをお勧めします。サポートがお客様が抱えている問題について支援します。 + +## 一般的なKubernetesコマンド {#generic-kubernetes-commands} + +- GCPプロジェクトへの認証方法 (異なるGCPアカウントでプロジェクトを使用している場合に特に役立ちます)。 + + ```shell + gcloud auth login + ``` + +- Kubernetesダッシュボードへのアクセス方法: + + ```shell + # for minikube: + minikube dashboard —url + # for non-local installations if access via Kubectl is configured: + kubectl proxy + ``` + +- KubernetesノードにSSHで接続し、rootとしてコンテナに入る方法: + + - GCPの場合、ノード名を見つけて、`gcloud compute ssh node-name`を実行できます。 + - `docker ps`を使用してコンテナを一覧表示します。 + - `docker exec --user root -ti container-id bash`を使用してコンテナに入ります。 + +- ローカルマシンからポッドにファイルをコピーする方法: + + ```shell + kubectl cp file-name pod-name:./destination-path + ``` + +- `CrashLoopBackoff`ステータスのポッドの対処法: + + - Kubernetesダッシュボードからログを確認します。 + - Kubectl経由でログを確認します。 + + ```shell + kubectl logs -c dependencies + ``` + +- すべてのKubernetesクラスターイベントをリアルタイムで追跡する方法: + + ```shell + kubectl get events -w --all-namespaces + ``` + +- 以前に終了したポッドインスタンスのログを取得する方法: + + ```shell + kubectl logs --previous + ``` + + ログはコンテナ/ポッド自体には保持されません。すべて`stdout`に書き込まれます。これはKubernetesの原則です。詳細については、[Twelve-factor app](https://12factor.net/)を参照してください。 + +- クラスターで設定されたcronジョブを取得する方法 + + ```shell + kubectl get cronjobs + ``` + + [cronベースのバックアップ](../backup-restore/backup.md#cron-based-backup)を設定すると、ここに新しいスケジュールが表示されます。スケジュールの詳細については、[CronJobで自動タスクを実行する](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#creating-a-cron-job)を参照してください + +## GitLab固有のKubernetes情報 {#gitlab-specific-kubernetes-information} + +- 個別のポッドのログの追跡。`webservice`ポッドの例: + + ```shell + kubectl logs gitlab-webservice-54fbf6698b-hpckq -c webservice + ``` + +- ラベルを共有するすべてのポッドを追跡およびフォローします (この場合は`webservice`)。 + + ```shell + # all containers in the webservice pods + kubectl logs -f -l app=webservice --all-containers=true --max-log-requests=50 + + # only the webservice containers in all webservice pods + kubectl logs -f -l app=webservice -c webservice --max-log-requests=50 + ``` + +- Linuxパッケージインストールでコマンド`gitlab-ctl tail`と同様に、すべてのコンテナから一度にログをストリーミングできます。 + + ```shell + kubectl logs -f -l release=gitlab --all-containers=true --max-log-requests=100 + ``` + +- `gitlab`ネームスペース内のすべてのイベントを確認します (Helm Chartのデプロイ時に別のネームスペースを指定した場合は、ネームスペース名が異なる場合があります)。 + + ```shell + kubectl get events -w --namespace=gitlab + ``` + +- 便利なGitLabツール (コンソール、Rakeタスクなど) のほとんどは、toolboxポッドにあります。中に入ってコマンドを実行したり、外からコマンドを実行したりできます。 + + ```shell + # find the pod + kubectl --namespace gitlab get pods -lapp=toolbox + + # open the Rails console + kubectl --namespace gitlab exec -it -c toolbox -- gitlab-rails console + + # run GitLab check. The output can be confusing and invalid because of the specific structure of GitLab installed via helm chart + gitlab-rake gitlab:check + + # open console without entering pod + kubectl exec -it -- gitlab-rails console + + # check the status of DB migrations + kubectl exec -it -- gitlab-rake db:migrate:status + ``` + +- **インフラストラクチャ > Kubernetesクラスター**インテグレーションのトラブルシューティング: + + - `kubectl get events -w --all-namespaces`の出力を確認します。 + - `gitlab-managed-apps`ネームスペース内のポッドのログを確認します。 + +- [初期管理者パスワード](../installation/deployment.md#initial-login)の取得方法: + + ```shell + # find the name of the secret containing the password + kubectl get secrets | grep initial-root + # decode it + kubectl get secret -ojsonpath={.data.password} | base64 --decode ; echo + ``` + +- GitLab PostgreSQLデータベースに接続する方法。 + + ```shell + kubectl exec -it -- gitlab-rails dbconsole --include-password --database main + ``` + +- Helmインストール状態に関する情報を取得する方法: + + ```shell + helm status + ``` + +- Helm Chartを使用してインストールされたGitLabを更新する方法: + + ```shell + helm repo update + + # get current values and redirect them to yaml file (analogue of gitlab.rb values) + helm get values > gitlab.yaml + + # run upgrade itself + helm upgrade -f gitlab.yaml + ``` + + [Helm Chartを使用したGitLabの更新](../installation/upgrade.md)も参照してください。 + +- GitLab設定への変更を適用する方法: + + - `gitlab.yaml`ファイルを修正します。 + - 変更を適用するには、次のコマンドを実行します: + + ```shell + helm upgrade -f gitlab.yaml + ``` + +- リリースのmanifestを取得する方法。すべてのKubernetesリソースと依存関係のあるチャートに関する情報が含まれているため、役立ちます: + + ```shell + helm get manifest + ``` + +## KubeSOSレポートのFast-Stats {#fast-stats-for-kubesos-reports} + +[KubeSOS](https://gitlab.com/gitlab-com/support/toolbox/kubesos)は、GitLabクラスターの構成と、GitLab Cloud Nativeチャートのデプロイからのログを収集するツールです。最小限のメモリ使用量のツールである[fast-stats](https://gitlab.com/gitlab-com/support/toolbox/fast-stats)を使用して、GitLabログのパフォーマンス統計をすばやく作成して比較できます。 + +- `fast-stats`の実行: + + ```shell + cut -d ' ' -f2- | grep ^{ | fast-stats + ``` + +- エラーの一覧表示: + + ```shell + cut -d ' ' -f2- | grep ^{ | fast-stats errors + ``` + +- `fast-stats` topの実行: + + ```shell + cut -d ' ' -f2- | grep ^{ | fast-stats top + ``` + +- 印刷される行数を変更します。デフォルトでは、10行が出力されます。 + + ```shell + cut -d ' ' -f2- | grep ^{ | fast-stats -l + ``` + +## macOSでのminikube経由での最小GitLab構成のインストール {#installation-of-minimal-gitlab-configuration-via-minikube-on-macos} + +このセクションは、[minikubeでのKubernetesの開発](../development/minikube/_index.md)と[Helm](../installation/tools.md)に基づいています。詳細については、それらのドキュメントを参照してください。 + +- Homebrew経由でKubectlをインストールします: + + ```shell + brew install kubernetes-cli + ``` + +- Homebrew経由でminikubeをインストールします: + + ```shell + brew cask install minikube + ``` + +- minikubeを起動して構成します。minikubeを起動できない場合は、`minikube delete && minikube start`を実行して手順を繰り返してください: + + ```shell + minikube start --cpus 3 --memory 8192 # minimum amount for GitLab to work + minikube addons enable ingress + ``` + +- Homebrew経由でHelmをインストールして初期化します: + + ```shell + brew install helm + ``` + +- [minikubeの最小値YAMLファイル](https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml)をワークステーションにコピーします: + + ```shell + curl --output values.yaml "https://gitlab.com/gitlab-org/charts/gitlab/raw/master/examples/values-minikube-minimum.yaml" + ``` + +- `minikube ip`の出力でIPアドレスを見つけ、このIPアドレスでYAMLファイルを更新します。 + +- GitLab Helmチャートをインストールします: + + ```shell + helm repo add gitlab https://charts.gitlab.io + helm install gitlab -f gitlab/gitlab + ``` + + GitLab設定を一部変更する場合は、上記の構成をベースとして使用し、独自のYAMLファイルを作成できます。 + +- `helm status gitlab`と`minikube dashboard`を使用して、インストール処理を監視します。インストールには、ワークステーションのリソース量に応じて最大20 ～ 30分かかる場合があります。 + +- すべてのポッドが`Running`または`Completed`のステータスを表示したら、[最初のログイン](../installation/deployment.md#initial-login)の説明に従ってGitLabパスワードを取得し、UIを使用してGitLabにログインします。`https://gitlab.domain`経由でアクセスできるようになります。ここで、`domain`はYAMLファイルで指定された値です。 + + + +## `toolbox`ポッドでのRailsコードのパッチ適用 {#patching-the-rails-code-in-the-toolbox-pod} + +{{< alert type="warning" >}} + +このタスクは、定期的に実行する必要があるものではありません。ご自身の責任で使用してください。 + +{{< /alert >}} + +運用GitLabサービスポッドにパッチを適用するには、変更されたソースコードを含む新しいイメージをビルドする必要があります。これらは直接パッチを適用_できません_。[`toolbox`/`task-runner`ポッド](../charts/gitlab/toolbox/_index.md)には、他の通常のサービスオペレーションを妨げることなく、Railsベースのポッドとして動作するために必要なものがすべて含まれています。これを使用して、独立したタスクを実行したり、ソースコードを一時的に変更して、いくつかのタスクを実行したりできます。 + +{{< alert type="note" >}} + +`toolbox`ポッドを使用して変更を加えた場合、ポッドを再起動しても、それらの変更は保持されません。これらは、コンテナの操作の有効期間中のみ存在します。 + +{{< /alert >}} + +`toolbox`ポッドでソースコードにパッチを適用するには: + +1. 適用する目的の`.patch`ファイルをフェッチします: + + - マージリクエストの差分を[パッチファイル](https://docs.gitlab.com/user/project/merge_requests/reviews/#download-merge-request-changes-as-a-patch-file)として直接ダウンロードします。 + - または、`curl`を使用して差分を直接フェッチします。以下の``をマージリクエストのIIDに置き換えるか、生の スニペット を指すようにURLを変更します: + + ```shell + curl --output ~/.patch "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/.patch" + ``` + +1. `toolbox`ポッドでローカルファイルにパッチを適用します: + + ```shell + cd /srv/gitlab + busybox patch -p1 -f < ~/.patch + ``` -- GitLab From f264a858132c3e22511c0cb809a53dd4f6e79fbd Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 10:24:26 -0700 Subject: [PATCH 02/15] Add doc-locale markdownlint config and ci --- .gitlab/ci/checks.yml | 4 +- .../.markdownlint/.markdownlint-cli2.yaml | 38 +++++++++++++++++++ 2 files changed, 39 insertions(+), 3 deletions(-) create mode 100644 doc-locale/.markdownlint/.markdownlint-cli2.yaml diff --git a/.gitlab/ci/checks.yml b/.gitlab/ci/checks.yml index 33b5c0bae4..d20176de30 100644 --- a/.gitlab/ci/checks.yml +++ b/.gitlab/ci/checks.yml @@ -73,10 +73,8 @@ check_docs_i18n_markdown: dependencies: [] before_script: [] script: - # Do not lint link-fragments, which are currently invalid in translations - - 'echo " link-fragments: false" >> .markdownlint-cli2.yaml' # Lint Markdown - - markdownlint-cli2 'doc-locale/**/*.md' + - cd doc-locale && markdownlint-cli2 --config .markdownlint/.markdownlint-cli2.yaml '**/*.md' rules: - !reference [.rule:skip_if_dev] - if: '$PIPELINE_TYPE == "DOCS_PIPELINE_LOCALIZATION"' diff --git a/doc-locale/.markdownlint/.markdownlint-cli2.yaml b/doc-locale/.markdownlint/.markdownlint-cli2.yaml new file mode 100644 index 0000000000..078d8d200e --- /dev/null +++ b/doc-locale/.markdownlint/.markdownlint-cli2.yaml @@ -0,0 +1,38 @@ + +--- +# Extended Markdown configuration for translated documentation +# To use this configuration, in the doc-locale directory, run: +# +# markdownlint-cli2 --config .markdownlint/.markdownlint-cli2.yaml '**/*.md' +# See https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md for explanations of each rule +config: + # First, set the default + default: true + + # Per-rule settings in alphabetical order + code-block-style: # MD046 + style: "fenced" + emphasis-style: false # MD049 + header-style: # MD003 + style: "atx" + hr-style: # MD035 + style: "---" + line-length: # MD013 + code_blocks: false + tables: false + headings: true + heading_line_length: 100 + line_length: 800 + no-duplicate-heading: # MD024 + siblings_only: true + no-emphasis-as-heading: false # MD036 + no-inline-html: false # MD033 + no-trailing-punctuation: # MD026 + punctuation: ".,;:!。，；：！？" + no-trailing-spaces: false # MD009 + ol-prefix: # MD029 + style: "one" + reference-links-images: false # MD052 + ul-style: # MD004 + style: "dash" +fix: false -- GitLab From 53bb9ff2e88b3a0a5f228eab8a4740ddf772cc9f Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 10:48:06 -0700 Subject: [PATCH 03/15] Resolve conflict on checks.yml --- .gitlab/ci/checks.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.gitlab/ci/checks.yml b/.gitlab/ci/checks.yml index d20176de30..780b2ff1eb 100644 --- a/.gitlab/ci/checks.yml +++ b/.gitlab/ci/checks.yml @@ -73,7 +73,6 @@ check_docs_i18n_markdown: dependencies: [] before_script: [] script: - # Lint Markdown - cd doc-locale && markdownlint-cli2 --config .markdownlint/.markdownlint-cli2.yaml '**/*.md' rules: - !reference [.rule:skip_if_dev] -- GitLab From a54d7fa82fa0d41e81c1ea86abe322a3b6f2a8d1 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 10:54:46 -0700 Subject: [PATCH 04/15] Resolve markdownlint errors for external-gitaly --- .../ja-jp/advanced/external-gitaly/_index.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc-locale/ja-jp/advanced/external-gitaly/_index.md b/doc-locale/ja-jp/advanced/external-gitaly/_index.md index 93d921cf27..033359fa45 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/_index.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/_index.md @@ -663,13 +663,13 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure 1. 複数のストレージがある場合は、[新しいリポジトリの保存場所をしてください](https://docs.gitlab.com/administration/repository_storage_paths/#configure-where-new-repositories-are-stored)。 -1. を有効にします: +1. を有効にします: ```shell kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)' ``` -1. が実行されていない場合は、 を元の数にします: +1. が実行されていない場合は、 を元の数にします: ```shell kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas= @@ -683,7 +683,7 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure kubectl delete pvc repo-data--gitaly-0 ``` -#### {#rollback} +#### {#rollback} 問題が発生した場合は、サブが再度使用されるように、変更をできます。 @@ -695,13 +695,13 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure helm rollback ``` -1. が実行されていない場合は、 を元の数にします: +1. が実行されていない場合は、 を元の数にします: ```shell kubectl scale deploy -lapp=webservice,release= --replicas= ``` -1. が実行されていない場合は、 を元の数にします: +1. が実行されていない場合は、 を元の数にします: ```shell kubectl scale deploy -lapp=sidekiq,release= --replicas= @@ -713,7 +713,7 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:enable!)' ``` -1. が実行されていない場合は、 を元の数にします: +1. が実行されていない場合は、 を元の数にします: ```shell kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas= @@ -723,4 +723,4 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure ### 関連ドキュメント {#related-documentation} -- [ にする](https://docs.gitlab.com/administration/gitaly/#migrate-to-gitaly-cluster) +- [にする](https://docs.gitlab.com/administration/gitaly/#migrate-to-gitaly-cluster) -- GitLab From 238b786491a555b26ae79d782192f804be8bfb9b Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 11:17:51 -0700 Subject: [PATCH 05/15] Resolve all MD030 errors --- doc-locale/ja-jp/advanced/external-redis/_index.md | 2 +- doc-locale/ja-jp/advanced/fips/_index.md | 2 +- doc-locale/ja-jp/advanced/geo/_index.md | 10 +++++----- doc-locale/ja-jp/charts/gitlab/webservice/_index.md | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc-locale/ja-jp/advanced/external-redis/_index.md b/doc-locale/ja-jp/advanced/external-redis/_index.md index 19f6dbc436..3455502ba2 100644 --- a/doc-locale/ja-jp/advanced/external-redis/_index.md +++ b/doc-locale/ja-jp/advanced/external-redis/_index.md @@ -105,7 +105,7 @@ production: - 既存の[パスワード定義](../../charts/globals.md#multiple-redis-support)を使用し、HelmにそれをERBステートメントに置き換えさせます。 - コンテナでシークレットがマウントされているパスを使用して、正しいERB `<%= File.read('/path/to/secret').strip.to_json %>`ステートメントを自分で記述します。 1. `redisYmlOverride`では、 Railsのに従う必要があります。たとえば、「SharedState」インスタンスは`sharedState`と呼ばれず、`shared_state`と呼ばれます。 -1. の継承はありません。たとえば、単一のSentinelセットを共有する3つのRedisがある場合は、Sentinelを3回繰り返す必要があります。 +1. の継承はありません。たとえば、単一のSentinelセットを共有する3つのRedisがある場合は、Sentinelを3回繰り返す必要があります。 1. CNGイメージは、[有効な`resque.yml`と`cable.yml`を想定している](https://gitlab.com/gitlab-org/build/CNG/-/blob/4d314e505edb25ccefd4297d212bfbbb5bc562f9/gitlab-rails/scripts/lib/checks/redis.rb#L54)ため、`resque.yml`ファイルを取得するには、少なくとも`global.redis.host`を設定する必要があります。 ## トラブルシューティング {#troubleshooting} diff --git a/doc-locale/ja-jp/advanced/fips/_index.md b/doc-locale/ja-jp/advanced/fips/_index.md index 90ebbd3e85..afaba5ed57 100644 --- a/doc-locale/ja-jp/advanced/fips/_index.md +++ b/doc-locale/ja-jp/advanced/fips/_index.md @@ -13,4 +13,4 @@ GitLabは、[FIPS準拠](https://docs.gitlab.com/development/fips_compliance/) FIPS互換のGitLabのに役立つ[`examples/fips/values.yaml`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/fips/values.yaml)のGitLabチャート値の例を示します。 -FIPS互換のNGINXイメージを使用するための関連を提供する`nginx-ingress.controller`キーの下のコメントに注意してください。このイメージは、[NGINX ](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-ingress-nginx)でされます。 +FIPS互換のNGINXイメージを使用するための関連を提供する`nginx-ingress.controller`キーの下のコメントに注意してください。このイメージは、[NGINX](https://gitlab.com/gitlab-org/cloud-native/charts/gitlab-ingress-nginx)でされます。 diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md index cae411b226..abc06d3411 100644 --- a/doc-locale/ja-jp/advanced/geo/_index.md +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -459,7 +459,7 @@ gitlab_rails['db_password']='gitlab_user_password' - `gitlab-geo-registry-secret`（のが有効な場合）。 1. `kubectl`コンテキストをプライマリのコンテキストに変更します。 -1. からこれらのを収集します。 +1. からこれらのを収集します。 ```shell kubectl get --namespace gitlab -o yaml secret gitlab-geo-gitlab-shell-host-keys > ssh-host-keys.yaml @@ -587,7 +587,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l ``` -1. のを確認します: +1. のを確認します: ```shell gitlab-rake gitlab:geo:check @@ -636,8 +636,8 @@ _このセクションは、セカンダリサイトのKubernetesで実行され 場合によっては、ユーザーにアクセスするサイトを制御させたいことがあります。このために、 サイトをして、一意の外部URLを使用できます。次に例を示します。 -- の外部URL：`https://gitlab.example.com` -- の外部URL：`https://shanghai.gitlab.example.com` +- の外部URL：`https://gitlab.example.com` +- の外部URL：`https://shanghai.gitlab.example.com` 1. `secondary.yaml`を編集し、`webservice`がこれらのを処理できるように、セカンダリの外部URLを更新します。 @@ -669,7 +669,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され 1. が完了し、アプリケーションがオンラインになるまで待ちます。 -## {#registry} +## {#registry} セカンダリ[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)をプライマリ[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)と[同期](../../charts/registry/_index.md#notification-secret)するには、[レジストリ](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)の[レプリケーション](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)を[通知シークレット](../../charts/registry/_index.md#notification-secret)を使用して[設定](https://docs.gitlab.com/administration/geo/replication/container_registry/#configure-container-registry-replication)できます。 diff --git a/doc-locale/ja-jp/charts/gitlab/webservice/_index.md b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md index b18d9cacf3..e00697f708 100644 --- a/doc-locale/ja-jp/charts/gitlab/webservice/_index.md +++ b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md @@ -678,10 +678,10 @@ Puma固有のオプション: webserviceサービスでは、有効になっている場合、Prometheusの接続、NGINXおよびいくつかのGitLabからのトラフィックが必要です。通常、さまざまな場所への接続が必要です。この例では、次のネットワークポリシーを追加します。 -- を許可: +- を許可: - `gitaly`、`gitlab-pages`、`gitlab-shell`、`kas`、`mailroom`、および`nginx-ingress`のから`8181`へのを許可 - `Prometheus`から`8080`、`8083`、および`9229`へのを許可 -- を許可: +- を許可: - `gitaly`から`8075`への - `kas`から`8153`への - `kube-dns`から`53`への -- GitLab From 2f5ad1244a165d9994ee42135f30f46283f7fe61 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 11:23:30 -0700 Subject: [PATCH 06/15] Fix all MD039 errors --- doc-locale/ja-jp/advanced/geo/_index.md | 2 +- doc-locale/ja-jp/charts/gitlab/webservice/_index.md | 4 ++-- doc-locale/ja-jp/troubleshooting/_index.md | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md index abc06d3411..b90ac48da1 100644 --- a/doc-locale/ja-jp/advanced/geo/_index.md +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -675,7 +675,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され ## Cert-managerと統合URL {#cert-manager-and-unified-url} -の統合URLは、位置情報認識ルーティング（たとえば、Amazon Route 53またはGoogle Cloudの使用）でよく使用されます。これにより、ドメイン名が管理下にあることをするために[HTTP01 ](https://letsencrypt.org/docs/challenge-types/#http-01-challenge)が使用されている場合に問題が発生する可能性があります。 +の統合URLは、位置情報認識ルーティング（たとえば、Amazon Route 53またはGoogle Cloudの使用）でよく使用されます。これにより、ドメイン名が管理下にあることをするために[HTTP01](https://letsencrypt.org/docs/challenge-types/#http-01-challenge)が使用されている場合に問題が発生する可能性があります。 1つのサイトの証明書をすると、Let'sは名をしているサイトにする必要があります。が別のサイトにされる場合、統合URLの証明書は発行またはされません。 diff --git a/doc-locale/ja-jp/charts/gitlab/webservice/_index.md b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md index e00697f708..278b5357e8 100644 --- a/doc-locale/ja-jp/charts/gitlab/webservice/_index.md +++ b/doc-locale/ja-jp/charts/gitlab/webservice/_index.md @@ -804,9 +804,9 @@ networkpolicy: `service.type`が`LoadBalancer`に設定されている場合、オプションで`service.loadBalancerIP`を指定して、ユーザー指定のIPで`LoadBalancer`を作成できます (クラウドプロバイダーがしている場合)。 -`service.type`が`LoadBalancer`に設定されている場合、`LoadBalancer`にアクセスできる 範囲を制限するには、`service.loadBalancerSourceRanges`も設定する必要があります (クラウドプロバイダーがしている場合)。これは現在、[ が公開されている](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2500)問題が原因で必要です。 +`service.type`が`LoadBalancer`に設定されている場合、`LoadBalancer`にアクセスできる 範囲を制限するには、`service.loadBalancerSourceRanges`も設定する必要があります (クラウドプロバイダーがしている場合)。これは現在、[が公開されている](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2500)問題が原因で必要です。 -`LoadBalancer`サービスタイプの詳細については、[ Kubernetesドキュメント](https://kubernetes.io/docs/concepts/services-networking/#loadbalancer)を参照してください +`LoadBalancer`サービスタイプの詳細については、[Kubernetesドキュメント](https://kubernetes.io/docs/concepts/services-networking/#loadbalancer)を参照してください ```yaml service: diff --git a/doc-locale/ja-jp/troubleshooting/_index.md b/doc-locale/ja-jp/troubleshooting/_index.md index 1290355f49..3ba9638508 100644 --- a/doc-locale/ja-jp/troubleshooting/_index.md +++ b/doc-locale/ja-jp/troubleshooting/_index.md @@ -578,9 +578,9 @@ gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.161640 gitlab-nginx-ingress-controller-899b7d6bf-lqcks controller W1116 19:03:13.465425 6 store.go:846] skipping ingress gitlab/gitlab-registry: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word proxy_pass ``` -その場合は、[ ](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)の使用について、 とサードパーティの をしてください。`nginx-ingress.controller.config.annotation-value-word-blocklist`を調整または変更する必要がある場合があります。 +[その場合は、](https://kubernetes.github.io/ingress-nginx/examples/customization/configuration-snippets/)の使用について、 とサードパーティの をしてください。`nginx-ingress.controller.config.annotation-value-word-blocklist`を調整または変更する必要がある場合があります。 -詳細については、[ ](../charts/nginx/_index.md#annotation-value-word-blocklist)をしてください。 +[詳細については、](../charts/nginx/_index.md#annotation-value-word-blocklist)をしてください。 ### マウントに時間がかかる {#volume-mount-takes-a-long-time} @@ -624,7 +624,7 @@ gitlab: 2024-01-19T14:12:24.214148186Z {"component": "gitlab","subcomponent":"puma.stdout","timestamp":"2024-01-19T14:12:24.213Z","pid":1,"message":"- Worker 2 (PID: 7414) booted in 0.84s, phase: 0"} ``` -この問題を解決するには、[ のメモリ制限を引き上げます](../charts/gitlab/webservice/_index.md#memory-requestslimits)。 +この問題を解決するには、[のメモリ制限を引き上げます](../charts/gitlab/webservice/_index.md#memory-requestslimits)。 ### アップグレードに失敗しました-`cannot patch "gitlab-prometheus-server" with kind Deployment` {#upgrade-failed---cannot-patch-gitlab-prometheus-server-with-kind-deployment} -- GitLab From 88fc9f59706af09b5adab59fbd68f93723a8467c Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 11:35:22 -0700 Subject: [PATCH 07/15] Fix other additional errors --- doc-locale/ja-jp/advanced/geo/_index.md | 6 +++--- doc-locale/ja-jp/troubleshooting/_index.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md index b90ac48da1..48c00ade5e 100644 --- a/doc-locale/ja-jp/advanced/geo/_index.md +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -64,7 +64,7 @@ GitLab GeoをGitLab Helm Chartで使用するには、次の要件を満たす - プライマリは、TCPポート`5432`を公開する必要があります。 - セカンダリは、TCPポート`5432`および`5431`を公開する必要があります。 -[Linuxパッケージでサポートされているオペレーティングシステム](https://docs.gitlab.com/install/requirements/#operating-systems)をインストールし、次に[Linux [パッケージ](https://docs.gitlab.com/install/requirements/#operating-systems)をインストール](https://about.gitlab.com/install/)します。インストール時に`EXTERNAL_URL`環境変数を指定しないでください。これは、パッケージを再設定する前に最小限の設定ファイルを提供するからです。 +[Linuxパッケージでサポートされているオペレーティングシステム](https://docs.gitlab.com/install/requirements/#operating-systems)をインストールし、次に[Linuxパッケージをインストール](https://about.gitlab.com/install/)します。インストール時に`EXTERNAL_URL`環境変数を指定しないでください。これは、パッケージを再設定する前に最小限の設定ファイルを提供するからです。 オペレーティングシステムとGitLabパッケージをインストールしたら、使用するサービスに対して設定を作成できます。その前に、情報を収集する必要があります。 @@ -562,7 +562,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され 1. **プライマリ**サイトにアクセスします。 1. 左側のサイドバーの一番下にある**管理者エリア**を選択します。 -1. ** > サイトを追加**を選択します。 +1. **サイトを追加**を選択します。 1. **セカンダリ**サイトを追加します。URLには完全なGitLab URLを使用します。 1. セカンダリサイトの`global.geo.nodeName`を持つ名前を入力します。これらのは常に文字どおり完全に一致する必要があります。 1. 内部URL（例：`https://shanghai.gitlab.example.com`）を入力します。 @@ -656,7 +656,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され - 管理者の使用: 1. **プライマリ**サイトにアクセスします。 1. 左側のサイドバーの一番下にある**管理者エリア**を選択します。 - 1. ** > サイト**を選択します。 + 1. **サイト**を選択します。 1. 鉛筆を選択して、**セカンダリサイトを編集**します。 1. 外部URL（例：`https://shanghai.gitlab.example.com`）を編集します。 1. **変更の保存**を選択します。 diff --git a/doc-locale/ja-jp/troubleshooting/_index.md b/doc-locale/ja-jp/troubleshooting/_index.md index 3ba9638508..267da78f30 100644 --- a/doc-locale/ja-jp/troubleshooting/_index.md +++ b/doc-locale/ja-jp/troubleshooting/_index.md @@ -386,7 +386,7 @@ gitlab: sshDaemon: gitlab-sshd ``` -## 設定: `mapping values are not allowed in this context` {#yaml-configuration-mapping-values-are-not-allowed-in-this-context} +## 設定: `mapping values are not allowed in this context` {#yaml-configuration-mapping-values-are-not-allowed-in-this-context} 設定に先頭のスペースが含まれている場合、次のエラーメッセージが表示されることがあります。 -- GitLab From 9d0df351bf7c9776c761160180ec80aa6e6d4a01 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 11:36:41 -0700 Subject: [PATCH 08/15] Adjust line length markdownlint --- doc-locale/.markdownlint/.markdownlint-cli2.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc-locale/.markdownlint/.markdownlint-cli2.yaml b/doc-locale/.markdownlint/.markdownlint-cli2.yaml index 078d8d200e..ce15bdcf56 100644 --- a/doc-locale/.markdownlint/.markdownlint-cli2.yaml +++ b/doc-locale/.markdownlint/.markdownlint-cli2.yaml @@ -22,7 +22,7 @@ config: tables: false headings: true heading_line_length: 100 - line_length: 800 + line_length: 1500 no-duplicate-heading: # MD024 siblings_only: true no-emphasis-as-heading: false # MD036 -- GitLab From 9434d123b95445247d7c4b2347b9adc3368d492b Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Thu, 26 Jun 2025 12:28:33 -0700 Subject: [PATCH 09/15] Exclude link-fragments from markdownlint check --- doc-locale/.markdownlint/.markdownlint-cli2.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/doc-locale/.markdownlint/.markdownlint-cli2.yaml b/doc-locale/.markdownlint/.markdownlint-cli2.yaml index ce15bdcf56..d76fcc7939 100644 --- a/doc-locale/.markdownlint/.markdownlint-cli2.yaml +++ b/doc-locale/.markdownlint/.markdownlint-cli2.yaml @@ -35,4 +35,5 @@ config: reference-links-images: false # MD052 ul-style: # MD004 style: "dash" + link-fragments: false # MD051 fix: false -- GitLab From 008992e2f382c1e95a73db0d9b4770b5715c4503 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:15:38 -0700 Subject: [PATCH 10/15] Remove multiples of same link --- doc-locale/ja-jp/advanced/custom-images/_index.md | 2 +- doc-locale/ja-jp/releases/7_0.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc-locale/ja-jp/advanced/custom-images/_index.md b/doc-locale/ja-jp/advanced/custom-images/_index.md index e30b31377c..e65c3f5865 100644 --- a/doc-locale/ja-jp/advanced/custom-images/_index.md +++ b/doc-locale/ja-jp/advanced/custom-images/_index.md @@ -35,7 +35,7 @@ helm template versionfinder gitlab/gitlab -f gitlab.yaml --version 7.3.0 | grep ## 値ファイルの例 {#example-values-file} -カスタムの[Docker](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml) [レジストリ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)/[リポジトリ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)と[タグ](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)を[Configure](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)する方法を示す[値](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)ファイルの例[example values file](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)があります。このファイルの関連セクションをコピーして、独自のリリースに使用できます。 +カスタムのDockerレジストリ/リポジトリとタグをConfigureする方法を示す[値ファイルの例](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/examples/custom-images/values.yaml)があります。このファイルの関連セクションをコピーして、独自のリリースに使用できます。 {{< alert type="note" >}} diff --git a/doc-locale/ja-jp/releases/7_0.md b/doc-locale/ja-jp/releases/7_0.md index bea4781194..f44581bee7 100644 --- a/doc-locale/ja-jp/releases/7_0.md +++ b/doc-locale/ja-jp/releases/7_0.md @@ -52,7 +52,7 @@ PostgreSQL 13は、GitLab 16.0でサポートされる最小要件のPostgreSQL OpenShiftユーザーは、Security Context Constraintsを変更してcertmanager 1.10+をデプロイする必要がある場合があります。詳細については、[certmanager 1.10リリースノート](https://cert-manager.io/docs/releases/release-notes/release-notes-1.10/#on-openshift-the-cert-manager-pods-may-fail-until-you-modify-security-context-constraints)を参照してください。 -GitLabチャートで[管理](https://cert-manager.io/docs/releases/)されていないcertmanagerカスタム[リソース](https://cert-manager.io/docs/releases/)を[デプロイ](https://cert-manager.io/docs/releases/)する場合、またはcert-[管理](https://cert-manager.io/docs/releases/)に関連する追加のスクリプトまたは[ツール](https://cert-manager.io/docs/releases/)を使用する場合は、[アップグレード](https://cert-manager.io/docs/releases/)する前に、[certmanager 1.6〜1.11](https://cert-manager.io/docs/releases/)の潜在的な破壊的な変更をお読みください。 +GitLabチャートで管理されていないcert-managerカスタムリソースをデプロイする場合、またはcert-managerに関連する追加のスクリプトまたはツールを使用する場合は、アップグレードする前に、[cert-manager 1.6〜1.11の潜在的な破壊的な変更](https://cert-manager.io/docs/releases/)をお読みください。 #### インプレースIngressの変更を無効にする {#disable-in-place-ingress-modification} -- GitLab From 0ce1434d727d7311bd26de222ee31ce2fea62e9a Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:25:57 -0700 Subject: [PATCH 11/15] Remove bold italics --- .../advanced/external-db/external-omnibus-psql.md | 4 ++-- doc-locale/ja-jp/advanced/external-gitaly/_index.md | 12 ++++++------ .../external-gitaly/external-omnibus-gitaly.md | 4 ++-- .../external-redis/external-omnibus-redis.md | 2 +- doc-locale/ja-jp/installation/database_upgrade.md | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md b/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md index dd0ba90d34..3e37326643 100644 --- a/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md +++ b/doc-locale/ja-jp/advanced/external-db/external-omnibus-psql.md @@ -13,7 +13,7 @@ Ubuntu用の[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)を 作成したにUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのが最新であることを確認します。とホスト名を設定します。ホスト名/ をメモし、それがKubernetesから解決可能で、到達可能であることを確認します。トラフィックを許可するために、ファイアウォールが適切に設定されていることを確認してください。 -[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、**_しないで_**ください`EXTERNAL_URL=`値を指定します。次の手順で非常に具体的なを提供するので、自動が発生しないようにします。 +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、しないでください`EXTERNAL_URL=`値を指定します。次の手順で非常に具体的なを提供するので、自動が発生しないようにします。 ## Linuxパッケージのインストールを設定 {#configure-linux-package-installation} @@ -21,7 +21,7 @@ Ubuntu用の[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)を *ノート*:この例は、[スケーリング用のPostgreSQL](https://docs.gitlab.com/administration/postgresql/)を提供するものではありません。 -_**注**:以下の値は置き換える必要があります_ +注:以下の値は置き換える必要があります - `DB_USERNAME`デフォルトのユーザー名は`gitlab`です - `DB_PASSSWORD`エンコードされていない diff --git a/doc-locale/ja-jp/advanced/external-gitaly/_index.md b/doc-locale/ja-jp/advanced/external-gitaly/_index.md index 033359fa45..446e5e8e20 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/_index.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/_index.md @@ -21,17 +21,17 @@ Gitalyが設定されていない場合は、オンプレミスまたはVMへの 次のプロパティを設定する必要があります。 -- `global.gitaly.enabled`:`false`に設定して、含まれているGitaly Chartを無効にします。 -- `global.gitaly.external`:これは、[外部Gitalyサービス](../../charts/globals.md#external)の配列です。 -- `global.gitaly.authToken.secret`:[認証用のトークンを含むシークレット](../../installation/secrets.md#gitaly-secret)の名前。 -- `global.gitaly.authToken.key`:トークンのコンテンツを含むシークレット内のキー。 +- `global.gitaly.enabled`: `false`に設定して、含まれているGitaly Chartを無効にします。 +- `global.gitaly.external`: これは、[外部Gitalyサービス](../../charts/globals.md#external)の配列です。 +- `global.gitaly.authToken.secret`: [認証用のトークンを含むシークレット](../../installation/secrets.md#gitaly-secret)の名前。 +- `global.gitaly.authToken.key`: トークンのコンテンツを含むシークレット内のキー。 外部Gitalyサービスは、GitLab Shellの独自のインスタンスを使用します。実装によっては、このChartのシークレットを使用してそれらを構成することも、定義済みのソースからのコンテンツを使用してこのChartのシークレットを構成することもできます。 次のプロパティの設定が必要になる**場合**があります。 -- `global.shell.authToken.secret`:[GitLab Shellのシークレットを含むシークレット](../../installation/secrets.md#gitlab-shell-secret)の名前。 -- `global.shell.authToken.key`:シークレットのコンテンツを含むシークレット内のキー。 +- `global.shell.authToken.secret`: [GitLab Shellのシークレットを含むシークレット](../../installation/secrets.md#gitlab-shell-secret)の名前。 +- `global.shell.authToken.key`: シークレットのコンテンツを含むシークレット内のキー。 2つの外部サービスを含む完全な構成例（`external-gitaly.yml`）。 diff --git a/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md index f231ee2cba..f8621517ed 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md @@ -13,13 +13,13 @@ title: スタンドアロンGitalyの設定 作成した仮想マシンにUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのパッケージが最新の状態であることを確認してください。ネットワーク構築とホスト名を設定します。ホスト名/IPをメモし、それがKubernetesクラスターから解決可能で、到達可能であることを確認します。トラフィックを許可するために、ファイアウォールポリシーが適切に設定されていることを確認してください。 -[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。Linuxパッケージのインストールを実行するときは、**_行わないでください_**、`EXTERNAL_URL=`の値を指定します。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。Linuxパッケージのインストールを実行するときは、行わないでください、`EXTERNAL_URL=`の値を指定します。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 ## Linuxパッケージのインストールを設定 {#configure-linux-package-installation} 最小限の`gitlab.rb`ファイルを`/etc/gitlab/gitlab.rb`に配置するように作成します。*非常に*、このノードで有効になっていることを明示的に指定します。[Gitalyを独自のサーバー上で実行](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#run-gitaly-on-its-own-server)するためのドキュメントに基づいた次のコンテンツを使用します。 -_**注**:以下の値は置き換える必要があります_ +注:以下の値は置き換える必要があります_ - `AUTH_TOKEN`を[`gitaly-secret`シークレット](../../installation/secrets.md#gitaly-secret)の値に置き換える必要があります - `GITLAB_URL`は、GitLabインスタンスのURLに置き換える必要があります diff --git a/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md b/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md index 1a976c1395..c69a43d7db 100644 --- a/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md +++ b/doc-locale/ja-jp/advanced/external-redis/external-omnibus-redis.md @@ -13,7 +13,7 @@ title: スタンドアロンRedisの設定 作成した仮想マシン（VM）にUbuntu Serverをインストールします。`openssh-server`がインストールされていること、およびすべてのパッケージが最新であることを確認してください。ネットワーク構築とホスト名を設定します。ホスト名/アドレスをメモし、それがKubernetesクラスターから解決可能で、到達可能であることを確認します。トラフィックを許可するようにファイアウォールポリシーが設定されていることを確認してください。 -[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、**___** `EXTERNAL_URL=`値を指定しないでください。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 +[Linuxパッケージ](https://about.gitlab.com/install/#ubuntu)のインストール手順に従ってください。パッケージのインストールを実行するときは、`EXTERNAL_URL=`値を指定しないでください。次の手順で非常に具体的な設定を行うため、自動設定は不要です。 ## Linuxパッケージインストールの設定 {#configure-linux-package-installation} diff --git a/doc-locale/ja-jp/installation/database_upgrade.md b/doc-locale/ja-jp/installation/database_upgrade.md index 53a44996ad..da6957453d 100644 --- a/doc-locale/ja-jp/installation/database_upgrade.md +++ b/doc-locale/ja-jp/installation/database_upgrade.md @@ -129,7 +129,7 @@ kubectl delete pvc data-RELEASE_NAME-postgresql-0 このシークレットは、最初にGitLabチャートによって生成され、アップグレード中またはアップグレード後には変更されません。したがって、シークレットを編集してキーを変更する必要があります。 -シークレットを編集したら、Helmアップグレードの値で_必ず_**`postgresql.auth.usePasswordFiles`を`true`に設定**してください。デフォルトは`false`です。 +シークレットを編集したら、Helmアップグレードの値で_必ず`postgresql.auth.usePasswordFiles`を`true`に設定**してください。デフォルトは`false`です。 次のスクリプトは、シークレットのパッチ適用に役立ちます。 -- GitLab From 81d229395e11085dc4bcd475040d836183f45051 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:32:21 -0700 Subject: [PATCH 12/15] Space after colon --- .../ja-jp/advanced/external-gitaly/_index.md | 36 +++++++++---------- .../external-omnibus-gitaly.md | 2 +- .../external-object-storage/_index.md | 2 +- doc-locale/ja-jp/backup-restore/_index.md | 4 +-- .../charts/gitlab/gitlab-pages/_index.md | 6 ++-- 5 files changed, 25 insertions(+), 25 deletions(-) diff --git a/doc-locale/ja-jp/advanced/external-gitaly/_index.md b/doc-locale/ja-jp/advanced/external-gitaly/_index.md index 446e5e8e20..1004d43789 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/_index.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/_index.md @@ -181,7 +181,7 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - 最後に、外部Gitalyサービスのファイアウォールが、構成されたGitalyポートでKubernetesポッドIP範囲のトラフィックを許可していることを確認します。 -#### ステップ2:新しいGitalyサービスを使用するようにインスタンスを設定する {#step-2-configure-instance-to-use-new-gitaly-service} +#### ステップ2: 新しいGitalyサービスを使用するようにインスタンスを設定する {#step-2-configure-instance-to-use-new-gitaly-service} 1. 外部Gitalyを使用するようにGitLabを設定します。メインの`gitlab.yml`設定ファイルにGitalyへの参照がある場合は、それらを削除し、次の内容で新しい`mixed-gitaly.yml`ファイルを作成します。 @@ -275,7 +275,7 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - {{< /tabs >}} -#### ステップ3:GitalyポッドのIPとホスト名を取得する {#step-3-get-the-gitaly-pod-ip-and-hostnames} +#### ステップ3G: italyポッドのIPとホスト名を取得する {#step-3-get-the-gitaly-pod-ip-and-hostnames} リポジトリストレージ移動APIを成功させるには、外部Gitalyサービスがポッドサービスホスト名を使用してGitalyポッドに接続できる必要があります。ポッドサービスホスト名を解決できるようにするには、Gitalyプロセスを実行している各外部Gitalyサービスのhostsファイルにホスト名を追加する必要があります。 @@ -294,11 +294,11 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - 接続が確認されたら、リポジトリストレージの移動のスケジュールに進むことができます。 -#### ステップ4:リポジトリストレージの移動をスケジュールする {#step-4-schedule-the-repository-storage-move} +#### ステップ4: リポジトリストレージの移動をスケジュールする {#step-4-schedule-the-repository-storage-move} [リポジトリの移動](https://docs.gitlab.com/administration/operations/moving_repositories/#moving-repositories)で示されているステップに従って、移動をスケジュールします。 -#### ステップ5:最終的な設定と検証 {#step-5-final-configuration-and-validation} +#### ステップ5: 最終的な設定と検証 {#step-5-final-configuration-and-validation} 1. 複数のGitalyストレージがある場合は、[新しいリポジトリの保存場所を設定](https://docs.gitlab.com/administration/repository_storage_paths/#configure-where-new-repositories-are-stored)します。 @@ -377,7 +377,7 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - - すべてのユーザーにダウンタイムが発生します。 - [Praefect Chart](../../charts/gitlab/praefect/_index.md)ではテストされておらず、サポートされていません。 -#### ステップ1:GitLab Chartの現在のリリースのリビジョンを取得する {#step-1-get-the-current-release-revision-of-the-gitlab-chart} +#### ステップ1: GitLab Chartの現在のリリースのリビジョンを取得する {#step-1-get-the-current-release-revision-of-the-gitlab-chart} 移行中に問題が発生する可能性は低いですが、GitLab Chartの現在のリリースのリビジョンを取得してください。出力をコピーして、[ロールバック](#rollback)を実行する必要がある場合に備えて、脇に置いてください: @@ -385,7 +385,7 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - helm history --max=1 ``` -#### ステップ2:外部GitalyサービスまたはGitalyクラスターをセットアップする {#step-2-setup-external-gitaly-service-or-gitaly-cluster} +#### ステップ2: 外部GitalyサービスまたはGitalyクラスターをセットアップする {#step-2-setup-external-gitaly-service-or-gitaly-cluster} [外部Gitaly](https://docs.gitlab.com/administration/gitaly/configure_gitaly/)または[外部Gitalyクラスター](https://docs.gitlab.com/administration/gitaly/praefect/)をセットアップします。これらのステップの一部として、ChartインストールからのGitalyトークンとGitLab Shellシークレットを提供する必要があります: @@ -415,11 +415,11 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - {{< /tabs >}} -#### ステップ3:移行中にGitの変更が行われないことを確認する {#step-3-verify-no-git-changes-can-be-made-during-migration} +#### ステップ3: 移行中にGitの変更が行われないことを確認する {#step-3-verify-no-git-changes-can-be-made-during-migration} 移行のデータ整合性を確保するために、次の手順でGitリポジトリに加えられる変更を防ぎます: -**1\.メンテナンスモードを有効にする** +**1.メンテナンスモードを有効にする** GitLab Enterprise Editionを使用している場合は、UI、API、またはRailsコンソールから[メンテナンスモード](https://docs.gitlab.com/administration/maintenance_mode/#enable-maintenance-mode)を有効にします: @@ -427,7 +427,7 @@ GitLab Enterprise Editionを使用している場合は、UI、API、またはRa kubectl exec -it -- gitlab-rails runner 'Gitlab::CurrentSettings.update!(maintenance_mode: true)' ``` -**2\.Runnerポッドをスケールダウンする** +**2.Runnerポッドをスケールダウンする** GitLab Community Editionを使用している場合は、クラスターで実行されているGitLab Runnerポッドをスケールダウンする必要があります。これにより、RunnerがGitLabに接続してCI/CDジョブを処理できなくなります。 @@ -441,11 +441,11 @@ kubectl get deploy -lapp=gitlab-gitlab-runner,release= -o jsonpath='{.i kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas=0 ``` -**3\.CIジョブが実行されていないことを確認する** +**3.CIジョブが実行されていないことを確認する** 管理者エリアで、**CI/CD > ジョブ**に移動します。このページにはすべてのジョブが表示されますが、**実行中**状態のジョブがないことを確認します。次のステップに進む前に、ジョブが完了するまで待つ必要があります。 -**4\.Sidekiq cronジョブを無効にする** +**4.Sidekiq cronジョブを無効にする** 移行中にSidekiqジョブがスケジュールおよび実行されないようにするには、すべてのSidekiq cronジョブを無効にします: @@ -463,7 +463,7 @@ kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.a ![Sidekiqのバックグラウンドジョブ](img/sidekiq_bg_jobs_v16_5.png) -**6\.SidekiqポッドとWebserviceポッドをスケールダウンする** +**6.SidekiqポッドとWebserviceポッドをスケールダウンする** 整合性のあるバックアップを確実に行うために、SidekiqポッドとWebserviceポッドをスケールダウンします。両方のサービスは後の段階でスケールアップされます: @@ -480,7 +480,7 @@ kubectl scale deploy -lapp=sidekiq,release= --replicas=0 kubectl scale deploy -lapp=webservice,release= --replicas=0 ``` -**7\.クラスターへの外部接続を制限する** +**7.クラスターへの外部接続を制限する** ユーザーと外部GitLab RunnerがGitLabに変更を加えないようにするには、GitLabへの不要な接続をすべて制限する必要があります。 @@ -508,7 +508,7 @@ kubectl scale deploy -lapp=webservice,release= --replicas=0 -f ingress-only-allow-ext-gitaly.yml ``` -**8\.リポジトリチェックサムのリストを作成する** +**8.リポジトリチェックサムのリストを作成する** バックアップを実行する前に、[すべてのGitLabリポジトリを確認](https://docs.gitlab.com/administration/raketasks/check/#check-all-gitlab-repositories)し、リポジトリチェックサムのリストを作成します。移行後にチェックサムを`diff`できるように、出力をファイルにパイプします: @@ -516,7 +516,7 @@ kubectl scale deploy -lapp=webservice,release= --replicas=0 kubectl exec -it -- gitlab-rake gitlab:git:checksum_projects > ~/checksums-before.txt ``` -#### ステップ4:すべてのリポジトリをバックアップする {#step-4-backup-all-repositories} +#### ステップ4: すべてのリポジトリをバックアップする {#step-4-backup-all-repositories} リポジトリの[バックアップを作成](../../backup-restore/backup.md#create-the-backup)します: @@ -524,7 +524,7 @@ kubectl exec -it -- gitlab-rake gitlab:git:checksum_projects kubectl exec -it -- backup-utility --skip artifacts,ci_secure_files,db,external_diffs,lfs,packages,pages,registry,terraform_state,uploads ``` -#### ステップ5:新しいGitalyサービスを使用するようにインスタンスを設定する {#step-5-configure-instance-to-use-new-gitaly-service} +#### ステップ5: 新しいGitalyサービスを使用するようにインスタンスを設定する {#step-5-configure-instance-to-use-new-gitaly-service} 1. Gitalyサブチャートを無効にし、外部Gitalyを使用するようにGitLabを設定します。メインの`gitlab.yml`設定ファイルにGitalyへの参照がある場合は、それらを削除し、次の内容で新しい`external-gitaly.yml`ファイルを作成します: @@ -621,7 +621,7 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure {{< /tabs >}} -#### ステップ6:リポジトリのバックアップを復元して検証する {#step-6-restore-and-validate-repository-backup} +#### ステップ6: リポジトリのバックアップを復元して検証する {#step-6-restore-and-validate-repository-backup} 1. 以前に作成した[バックアップファイルを復元](../../backup-restore/restore.md#restoring-the-backup-file)します。その結果、リポジトリは構成された外部GitalyまたはGitalyクラスターにコピーされます。 @@ -639,7 +639,7 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure 特定の行の`diff`出力で空白のチェックサムが`0000000000000000000000000000000000000000`に変化している場合、これは想定どおりであり、無視しても問題ありません。 -#### ステップ7:最終設定と {#step-7-final-configuration-and-validation} +#### ステップ7: 最終設定と {#step-7-final-configuration-and-validation} 1. 外部ユーザーとGitLabがGitLabに再度できるように、`gitlab.yml`ファイルと`external-gitaly.yml`ファイルを適用します。`ingress-only-allow-ext-gitaly.yml`を指定しないため、制限が削除されます。 diff --git a/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md index f8621517ed..11108890ed 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/external-omnibus-gitaly.md @@ -19,7 +19,7 @@ title: スタンドアロンGitalyの設定 最小限の`gitlab.rb`ファイルを`/etc/gitlab/gitlab.rb`に配置するように作成します。*非常に*、このノードで有効になっていることを明示的に指定します。[Gitalyを独自のサーバー上で実行](https://docs.gitlab.com/administration/gitaly/configure_gitaly/#run-gitaly-on-its-own-server)するためのドキュメントに基づいた次のコンテンツを使用します。 -注:以下の値は置き換える必要があります_ +注: 以下の値は置き換える必要があります_ - `AUTH_TOKEN`を[`gitaly-secret`シークレット](../../installation/secrets.md#gitaly-secret)の値に置き換える必要があります - `GITLAB_URL`は、GitLabインスタンスのURLに置き換える必要があります diff --git a/doc-locale/ja-jp/advanced/external-object-storage/_index.md b/doc-locale/ja-jp/advanced/external-object-storage/_index.md index 486aff102c..89d861b635 100644 --- a/doc-locale/ja-jp/advanced/external-object-storage/_index.md +++ b/doc-locale/ja-jp/advanced/external-object-storage/_index.md @@ -343,6 +343,6 @@ Cloud CDNを使用するには: ## トラブルシューティング {#troubleshooting} -### Azure Blob:URL \[FILTERED]がブロックされています:ローカルネットワークへのリクエストは許可されていません {#azure-blob-url-filtered-is-blocked-requests-to-the-local-network-are-not-allowed} +### Azure Blob: URL \[FILTERED]がブロックされています: ローカルネットワークへのリクエストは許可されていません {#azure-blob-url-filtered-is-blocked-requests-to-the-local-network-are-not-allowed} これは、Azure Blobホスト名が[RFC1918（ローカル/プライベート）IPアドレス](https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints#dns-changes-for-private-endpoints)に[解決](https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints#dns-changes-for-private-endpoints)された場合に発生します。回避策として、Azure Blobホスト名（`yourinstance.blob.core.windows.net`）の[送信](https://docs.gitlab.com/security/webhooks/#allowlist-for-local-requests)リクエスト diff --git a/doc-locale/ja-jp/backup-restore/_index.md b/doc-locale/ja-jp/backup-restore/_index.md index 86fc1f29fa..13659f24c0 100644 --- a/doc-locale/ja-jp/backup-restore/_index.md +++ b/doc-locale/ja-jp/backup-restore/_index.md @@ -178,7 +178,7 @@ helm install gitlab gitlab/gitlab \ 利用可能なバケットのリストが表示されます。 -### 「AccessDeniedException:GCPの403」エラー {#accessdeniedexception-403-errors-in-gcp} +### 「AccessDeniedException: GCPの403」エラー {#accessdeniedexception-403-errors-in-gcp} `[Error] AccessDeniedException: 403 does not have storage.objects.list access to the Google Cloud Storage bucket.`のようなエラーは、権限がないために、GitLabインスタンスのバックアップまたはリストア中に通常発生します。 @@ -215,7 +215,7 @@ helm install gitlab gitlab/gitlab \ この問題を解決するには、[S3へのバックアップ](_index.md#backups-to-s3)の手順に従ってください。 -### 「PermissionError:S3を使用したファイル書き込み不可」エラー {#permissionerror-file-not-writable-errors-using-s3} +### 「PermissionError: S3を使用したファイル書き込み不可」エラー {#permissionerror-file-not-writable-errors-using-s3} ツールボックスユーザーがバケットアイテムの保存されている権限と一致するファイルを書き込む権限を持っていない場合、`[Error] WARNING: not writable: Operation not permitted`のようなエラーが発生します。 diff --git a/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md b/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md index 8c78a04d56..a64eef8422 100644 --- a/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md +++ b/doc-locale/ja-jp/charts/gitlab/gitlab-pages/_index.md @@ -7,8 +7,8 @@ title: GitLab Pagesチャートの使用 {{< details >}} -- プラン:Free、Premium、Ultimate -- 提供:GitLab Self-Managed +- プラン: Free、Premium、Ultimate +- 提供: GitLab Self-Managed {{< /details >}} @@ -20,7 +20,7 @@ title: GitLab Pagesチャートの使用 ## 設定 {#configuration} -`gitlab-pages`チャートは次のように構成されています:[グローバル設定](#global-settings)および[チャート設定](#chart-settings)。 +`gitlab-pages`チャートは次のように構成されています: [グローバル設定](#global-settings)および[チャート設定](#chart-settings)。 ## グローバル設定 {#global-settings} -- GitLab From 5114fff59741fed1ab7da43d7b67e4f278ae7e5a Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:33:49 -0700 Subject: [PATCH 13/15] Remove extra space --- doc-locale/ja-jp/advanced/geo/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md index 48c00ade5e..ea23012608 100644 --- a/doc-locale/ja-jp/advanced/geo/_index.md +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -538,7 +538,7 @@ _このセクションは、セカンダリサイトのKubernetesで実行され - [`global.hosts.domain`](../../charts/globals.md#configure-host-settings) - [`global.psql.host`](../../charts/globals.md#configure-postgresql-settings) - [`global.geo.psql.host`](../../charts/globals.md#configure-postgresql-settings) - - `global.geo.nodeName`は、[管理者エリアのサイトの[名前]フィールド](https://docs.gitlab.com/administration/geo_sites/#common-settings)と一致する必要があります + - `global.geo.nodeName`は[管理者エリアのサイトの[名前]フィールド](https://docs.gitlab.com/administration/geo_sites/#common-settings)と一致する必要があります - `nginx-ingress-geo.enabled`を設定して、内部トラフィック用に事前にされた を有効にすることもできます。[これにより、サイトをプライマリにすることが容易になります](../../charts/nginx/_index.md#gitlab-geo)。 - [gitlab.webservice](../../charts/gitlab/webservice/_index.md#ingress-settings)の追加の をして、セカンダリサイトの内部URLに送信されるトラフィックを処理します。 - その他の追加もします。次に例を示します。 -- GitLab From 28955769f65f682e5e36819aea40062e4335d3a0 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:42:43 -0700 Subject: [PATCH 14/15] Use english parenthesis for links --- doc-locale/ja-jp/advanced/custom-images/_index.md | 4 ++-- doc-locale/ja-jp/advanced/external-gitaly/_index.md | 8 ++++---- doc-locale/ja-jp/installation/command-line-options.md | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc-locale/ja-jp/advanced/custom-images/_index.md b/doc-locale/ja-jp/advanced/custom-images/_index.md index e65c3f5865..5287b7419c 100644 --- a/doc-locale/ja-jp/advanced/custom-images/_index.md +++ b/doc-locale/ja-jp/advanced/custom-images/_index.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w title: GitLabチャートにカスタムのDockerイメージを使用する --- -特定のシナリオ（オフライン環境など）では、インターネットからDockerイメージをプルするのではなく、独自のDockerイメージを使用したい場合があります。これを行うには、GitLabのリリースを構成する各チャートに対して、独自のDockerイメージレジストリ/リポジトリを指定する必要があります。 +特定のシナリオ(オフライン環境など)では、インターネットからDockerイメージをプルするのではなく、独自のDockerイメージを使用したい場合があります。これを行うには、GitLabのリリースを構成する各チャートに対して、独自のDockerイメージレジストリ/リポジトリを指定する必要があります。 ## デフォルトイメージ形式 {#default-image-format} @@ -39,6 +39,6 @@ helm template versionfinder gitlab/gitlab -f gitlab.yaml --version 7.3.0 | grep {{< alert type="note" >}} -一部のチャート（特にサードパーティのチャート）では、イメージのレジストリ/リポジトリとタグの指定方法が若干異なる場合があります。サードパーティ[チャート](https://artifacthub.io/)のドキュメントは、[Artifact Hub](https://artifacthub.io/)にあります。 +一部のチャート(特にサードパーティのチャート)では、イメージのレジストリ/リポジトリとタグの指定方法が若干異なる場合があります。サードパーティ[チャート](https://artifacthub.io/)のドキュメントは、[Artifact Hub](https://artifacthub.io/)にあります。 {{< /alert >}} diff --git a/doc-locale/ja-jp/advanced/external-gitaly/_index.md b/doc-locale/ja-jp/advanced/external-gitaly/_index.md index 1004d43789..5e905d5089 100644 --- a/doc-locale/ja-jp/advanced/external-gitaly/_index.md +++ b/doc-locale/ja-jp/advanced/external-gitaly/_index.md @@ -33,7 +33,7 @@ Gitalyが設定されていない場合は、オンプレミスまたはVMへの - `global.shell.authToken.secret`: [GitLab Shellのシークレットを含むシークレット](../../installation/secrets.md#gitlab-shell-secret)の名前。 - `global.shell.authToken.key`: シークレットのコンテンツを含むシークレット内のキー。 -2つの外部サービスを含む完全な構成例（`external-gitaly.yml`）。 +2つの外部サービスを含む完全な構成例(`external-gitaly.yml`)。 ```yaml global: @@ -363,7 +363,7 @@ kubectl get secret -gitaly-secret -ojsonpath='{.data.token}' | base64 - 1. すべてが期待どおりに動作していることを確認したら、Gitaly PVCを削除できます: - 警告:すべてが期待どおりに動作していることを再確認するまで、Gitaly PVCを削除しないでください。 + 警告: すべてが期待どおりに動作していることを再確認するまで、Gitaly PVCを削除しないでください。 ```shell kubectl delete pvc repo-data--gitaly-0 @@ -453,7 +453,7 @@ kubectl scale deploy -lapp=gitlab-gitlab-runner,release= --replicas=0 kubectl exec -it -- gitlab-rails runner 'Sidekiq::Cron::Job.all.map(&:disable!)' ``` -**5\.バックグラウンドジョブが実行されていないことを確認する** +**5.バックグラウンドジョブが実行されていないことを確認する** 次のステップに進む前に、エンキューされたジョブまたは進行中のジョブが完了するまで待つ必要があります。 @@ -677,7 +677,7 @@ kubectl exec -it -- backup-utility --skip artifacts,ci_secure 1. すべてが期待どおりに動作していることを確認したら、 を削除できます: - 警告:すべてが期待どおりに動作していることを再確認するまで、[手順6](#step-6-restore-and-validate-repository-backup)に従ってチェックサムが一致することを確認するまで、 を削除しないでください。 + 警告: すべてが期待どおりに動作していることを再確認するまで、[手順6](#step-6-restore-and-validate-repository-backup)に従ってチェックサムが一致することを確認するまで、 を削除しないでください。 ```shell kubectl delete pvc repo-data--gitaly-0 diff --git a/doc-locale/ja-jp/installation/command-line-options.md b/doc-locale/ja-jp/installation/command-line-options.md index 13a76ed284..e66d2f4b67 100644 --- a/doc-locale/ja-jp/installation/command-line-options.md +++ b/doc-locale/ja-jp/installation/command-line-options.md @@ -72,7 +72,7 @@ helm inspect values gitlab/gitlab | `global.email.smime.certName` | `tls.crt` | S/MIME証明書ファイルの場所を特定するためのシークレットオブジェクトキー値 | | `global.email.smime.enabled` | `false` | 送信メールにS/MIME署名を追加します | | `global.email.smime.keyName` | `tls.key` | S/MIMEキーファイルの場所を特定するためのシークレットオブジェクトキー値 | -| `global.email.smime.secretName` | `""` | X.509証明書を検索するKubernetesシークレットオブジェクト（作成用の[S/MIME証明書](secrets.md#smime-certificate)） | +| `global.email.smime.secretName` | `""` | X.509証明書を検索するKubernetesシークレットオブジェクト(作成用の[S/MIME証明書](secrets.md#smime-certificate)) | | `global.email.subject_suffix` | `""` | GitLabからのすべての送信メールの件名のサフィックス | | `global.smtp.address` | `smtp.mailgun.org` | リモートメールサーバーのホスト名またはIP | | `global.smtp.authentication` | `plain` | SMTP認証のタイプ（「plain」、「login」、「cram_md5」、または認証なしの場合は「」） | @@ -83,7 +83,7 @@ helm inspect values gitlab/gitlab | `global.smtp.password.secret` | `""` | SMTPパスワードを含む`Secret`の名前 | | `global.smtp.port` | `2525` | SMTPのポート | | `global.smtp.starttls_auto` | `false` | メールサーバーで有効になっている場合は、STARTTLSを使用します | -| `global.smtp.tls` | _なし_ | SMTP/TLSを有効にします（SMTPS:ダイレクトTLS接続経由のSMTP) | +| `global.smtp.tls` | _なし_ | SMTP/TLSを有効にします(SMTPS:ダイレクトTLS接続経由のSMTP) | | `global.smtp.user_name` | `""` | SMTP認証httpsのユーザー名 | | `global.smtp.open_timeout` | `30` | 接続を試行中に待機する秒数。 | | `global.smtp.read_timeout` | `60` | 1つのブロックの読み取り中に待機する秒数。 | -- GitLab From 9b957b2d93ff78e291127db090243283893af618 Mon Sep 17 00:00:00 2001 From: Lauren Barker Date: Mon, 30 Jun 2025 15:44:10 -0700 Subject: [PATCH 15/15] Remove extra space --- doc-locale/ja-jp/advanced/geo/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc-locale/ja-jp/advanced/geo/_index.md b/doc-locale/ja-jp/advanced/geo/_index.md index ea23012608..61d13aaea0 100644 --- a/doc-locale/ja-jp/advanced/geo/_index.md +++ b/doc-locale/ja-jp/advanced/geo/_index.md @@ -540,12 +540,12 @@ _このセクションは、セカンダリサイトのKubernetesで実行され - [`global.geo.psql.host`](../../charts/globals.md#configure-postgresql-settings) - `global.geo.nodeName`は[管理者エリアのサイトの[名前]フィールド](https://docs.gitlab.com/administration/geo_sites/#common-settings)と一致する必要があります - `nginx-ingress-geo.enabled`を設定して、内部トラフィック用に事前にされた を有効にすることもできます。[これにより、サイトをプライマリにすることが容易になります](../../charts/nginx/_index.md#gitlab-geo)。 - - [gitlab.webservice](../../charts/gitlab/webservice/_index.md#ingress-settings)の追加の をして、セカンダリサイトの内部URLに送信されるトラフィックを処理します。 + - [gitlab.webservice](../../charts/gitlab/webservice/_index.md#ingress-settings)の追加の をして、セカンダリサイトの内部URLに送信されるトラフィックを処理します。 - その他の追加もします。次に例を示します。 - [SSL/TLSの](../../installation/tools.md#tls-certificates) - [外部Redisの使用](../external-redis/_index.md) - [外部オブジェクトストレージの使用](../external-object-storage/_index.md) - - 外部データベースの場合、`global.psql.host`はセカンダリの読み取り専用データベースであり、`global.geo.psql.host`は のトラッキングデータベースです + - 外部データベースの場合、`global.psql.host`はセカンダリの読み取り専用データベースであり、`global.geo.psql.host`は のトラッキングデータベースです 1. このを使用してをします: -- GitLab