- 要件
- 概要
- Linuxパッケージ・データベース・ノードのセットアップ
- Kubernetesクラスターのセットアップ
- 情報の収集
- プライマリデータベースの設定
- ChartをGeoプライマリサイトとしてデプロイします。
- Geo プライマリサイトの設定
- セカンダリデータベースの設定
- プライマリサイトからセカンダリサイトへのシークレットのコピー
- Geo セカンダリサイトとしてデプロイします。
- プライマリ経由でセカンダリ Geo サイトを追加
- オペレーション状況の確認
- レジストリ
GitLab GeoでGitLabチャートを設定します。
GitLab Geoは地理的に分散されたアプリケーションのデプロイ機能を提供します。
外部のデータベースサービスを利用することもできますが、これらの文書では、最もプラットフォームに依存しないガイドを提供するために PostgreSQL のLinux パッケージの利用に焦点を当て、gitlab-ctl
に含まれる自動化を利用します。
このガイドでは、両方のクラスターが同じ外部URLを持っています。Geo サイトの統一 URL の設定」 を参照してください。
要件
GitLab GeoをGitLab Helmチャートで使用するには、以下の要件を満たす必要があります:
- 外部の PostgreSQLサービスを利用すること。チャートに含まれる PostgreSQL は外部のネットワークに公開されておらず、レプリケーションに必要な WAL サポートもありません。
- 提供されるデータベースは
- レプリケーションのサポート
- プライマリ データベースは、プライマリ サイトおよびすべてのセカンダリ データベース ノード(レプリケーション用)からアクセス可能である必要があります。
- セカンダリデータベースは、セカンダリサイトからのみアクセス可能である必要があります。
- プライマリデータベースとセカンダリデータベースのノード間でSSLをサポートします。
- プライマリサイトは、すべてのセカンダリサイトから HTTP(S) 経由でアクセス可能である必要があります。セカンダリサイトは、HTTP(S)経由でプライマリサイトにアクセス可能である必要があります。
概要
このガイドでは、Linuxパッケージを使用して作成した2つのデータベースノードを使用し、必要なPostgreSQLサービスのみを設定し、GitLab Helmチャートを2回デプロイします。必要_最小限の_設定を想定しています。このドキュメントには、アプリケーションからデータベースへのSSL、他のデータベースプロバイダのサポート、セカンダリサイトからプライマリサイトへの昇格は含まれていません。
以下のアウトラインに従ってください:
- Linuxパッケージデータベースノードのセットアップ
- Kubernetesクラスターのセットアップ
- 情報の収集
- プライマリデータベースの設定
- ChartをGeoプライマリサイトとしてデプロイ
- Geoプライマリサイトの設定
- セカンダリデータベースの設定
- プライマリ サイトからセカンダリ サイトへのシークレットのコピー
- Geo セカンダリ サイトとしてのチャートのデプロイ
- プライマリ経由でセカンダリ Geo サイトを追加
- オペレーション状況の確認
Linuxパッケージ・データベース・ノードのセットアップ
このプロセスでは、2つのノードが必要です。1つはプライマリデータベースノード、もう1つはセカンダリデータベースノードです。オンプレミスでもクラウドプロバイダーでも、どのプロバイダーのマシンインフラを使用してもかまいません。
通信が必要であることに留意してください:
- レプリケーションのために2つのデータベースノード間で
- 各データベースノードとそれぞれのKubernetesデプロイの間:
- プライマリはTCPポート
5432
を公開する必要があります。 - セカンダリはTCPポート
5432
&5431
を公開する必要があります。
- プライマリはTCPポート
Linuxパッケージがサポートするオペレーションシステムをインストールし、その上にLinuxパッケージをインストールしてください。パッケージを再設定する前に最小限の設定ファイルを提供するので、インストール時にEXTERNAL_URL
環境変数を提供しないでください。
オペレーションシステムとGitLabパッケージをインストールしたら、使用するサービスの設定を行います。その前に、情報を収集しなければなりません。
Kubernetesクラスターのセットアップ
このプロセスでは、2つのKubernetesクラスタを使用する必要があります。これらはオンプレミスでもクラウドプロバイダーでも、どのプロバイダーのものでもかまいません。
通信が必要であることに留意してください:
- 各データベースノードへの
- TCP
5432
へのプライマリ・アウトバウンド。 - TCP
5432
および5431
へのセカンダリ発信 .
- TCP
- 両方のKubernetes間でHTTPS経由でIngress。
プロビジョニングされる各クラスターには
- これらのChartのベースライン・インストールをサポートするのに十分なリソース。
- 永続的ストレージへのアクセス:
- 外部オブジェクトストレージを使用する場合、MinIOは不要。
- 外部Gitalyを使用する場合は不要です。
- 外部のRedisを使用する場合は、Redisは必要ありません。
情報の収集
設定を続けるためには、以下の情報を様々な情報源から収集する必要があります。これらを収集し、このドキュメントの残りの部分で使用するためのメモを作成します。
- プライマリ・データベース:
- 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つで以下のコマンドを実行してください。
gitlab-ctl pg-password-md5 gitlab
gitlab-ctl pg-password-md5 gitlab_geo
プライマリデータベースの設定
このセクションは、プライマリ Linux パッケージインストールデータベースノードで実行します。
プライマリデータベースノードのLinuxパッケージインストールを設定するには、この設定例を参考にしてください:
### 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
grafana['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']
は、サイトの固有名に置き換える必要があります。共通設定の名前フィールドを参照してください。 -
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']
のままでも_構いませんが_、ベストプラクティスではありません。
上記の設定が準備できたら、次のようにします:
- コンテンツを
/etc/gitlab/gitlab.rb
-
gitlab-ctl reconfigure
を実行してください。サービスがTCPをリッスンしていないというイシューが発生した場合は、gitlab-ctl restart postgresql
を使って直接再起動してみてください。 -
gitlab-ctl set-replication-password
を実行して、gitlab_replicator
ユーザーのパスワードを設定します。 -
プライマリデータベースノードの公開証明書を取得します。これはセカンダリデータベースがレプリケートできるようにするために必要です(この出力を保存します):
cat ~gitlab-psql/data/server.crt
ChartをGeoプライマリサイトとしてデプロイします。
このセクションは Primary サイトの Kubernetes クラスターで実行します。
このChartをGeo Primaryとしてデプロイするには、この設定例から始めます:
-
Chartが使用するデータベースのパスワードを含むシークレットを作成します。以下の
PASSWORD
をgitlab
データベースユーザーのパスワードに置き換えてください:kubectl --namespace gitlab create secret generic geo --from-literal=postgresql-password=PASSWORD
-
設定例に基づいて
primary.yaml
ファイルを作成し、正しい値が反映されるように設定を更新します:### Geo Primary global: # See docs.gitlab.com/charts/charts/globals # Configure host & domain hosts: domain: example.com # 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
- global.hosts.domain
- global.geo.nodeNameは管理エリアのGeoサイトのNameフィールドと一致する必要があります。
- nginx-ingress-geoはセカンダリから転送される Geo トラフィックの Ingress コントローラを有効にします。
- プライマリのGeoサイトのgitLab.webserviceのGeoトラフィック用Ingressの設定
- などの追加設定も行います:
-
この設定を使ってChartをデプロイします:
helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f primary.yaml
これは、gitlab
ネームスペースを使用していることを前提としています。別の名前空間を使用したい場合は、このドキュメントの残りの部分で--namespace gitlab
に置き換えてください。 -
デプロイが完了し、アプリケーションがオンラインになるのを待ちます。アプリケーションにアクセスできるようになったら、ログインします。
-
GitLab にサインインし、GitLab サブスクリプションを有効化します。
このステップは Geo が機能するために必要です。
Geo プライマリサイトの設定
チャートがデプロイされ、ライセンスがアップロードされたので、これをプライマリサイトとして設定します。これは Toolbox ポッドで行います。
-
ツールボックス・ポッドを探す
kubectl --namespace gitlab get pods -lapp=toolbox
-
kubectl exec
でgitlab-rake geo:set_primary_node
を実行します:kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake geo:set_primary_node
-
Rails runnerコマンドでプライマリサイトの内部URLを設定します。
https://primary.gitlab.example.com
を実際の内部URLに置き換えてください:kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rails runner "GeoNode.primary_node.update!(internal_url: 'https://primary.gitlab.example.com')"
-
Geo の設定状況を確認します:
kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- gitlab-rake gitlab:geo:check
以下のような出力が表示されるはずです:
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
-
Exception: getaddrinfo: Servname not supported for ai_socktype
、Kubernetesコンテナはホストクロックにアクセスできないので、心配しないでください。これで_OK_です。 -
OpenSSH configured to use AuthorizedKeysCommand ... no
が_期待_されます。このRakeタスクはローカルのSSHサーバーをチェックしていますが、実際にはgitlab-shell
チャートに存在し、別の場所にデプロイされ、すでに適切に設定されています。
-
セカンダリデータベースの設定
このセクションは、セカンダリLinuxパッケージインストールデータベースノードで実行されます。
セカンダリデータベースノードの Linux パッケージインストールを設定するには、この設定例を参考にしてください:
### 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
grafana['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']
は、サイト固有の名前に置き換える必要があります。共通設定の名前フィールドを参照してください。 -
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']
のままでも_構いませんが_、ベストプラクティスではありません。
上記の設定が完了しました:
-
プライマリサイトのPostgreSQLノードへのTCP接続を確認します:
openssl s_client -connect <primary_node_ip>:5432 </dev/null
出力は以下のようになります:
CONNECTED(00000003) write:errno=0
この手順が失敗した場合、間違ったIPアドレスを使用しているか、ファイアウォールがサーバへのアクセスを妨げている可能性があります。公開アドレスと非公開アドレスの違いに注意してIPアドレスを確認し、ファイアウォールが存在する場合、セカンダリPostgreSQLノードがTCPポート5432でプライマリPostgreSQLノードへの接続を許可されていることを確認してください。 - コンテンツを
/etc/gitlab/gitlab.rb
-
gitlab-ctl reconfigure
を実行してください。サービスがTCPをリッスンしていないというイシューが発生した場合は、gitlab-ctl restart postgresql
を使って直接再起動してみてください。 - 上記のプライマリPostgreSQLノードの証明書の内容を
primary.crt
-
セカンダリPostgreSQLノードでPostgreSQL TLS検証を設定します:
primary.crt
ファイルをインストールしてください:install \ -D \ -o gitlab-psql \ -g gitlab-psql \ -m 0400 \ -T primary.crt ~gitlab-psql/.postgresql/root.crt
PostgreSQLはTLS接続を検証する際に、その証明書のみを認識するようになります。この証明書は、プライマリPostgreSQLノードにしか存在しない秘密鍵にアクセスできる人だけが複製することができます。
-
gitlab-psql
ユーザがプライマリサイトのPostgreSQL(デフォルトのLinuxパッケージデータベース名はgitlabhq_production
)に接続できることをテストしてください:sudo \ -u gitlab-psql /opt/gitlab/embedded/bin/psql \ --list \ -U gitlab_replicator \ -d "dbname=gitlabhq_production sslmode=verify-ca" \ -W \ -h <primary_database_node_ip>
プロンプトが表示されたら、
gitlab_replicator
ユーザのパスワードを入力してください。すべてが正しく動作していれば、プライマリPostgreSQLノードのデータベースのリストが表示されるはずです。ここで接続に失敗した場合は、TLSの設定が正しくないことを示しています。プライマリPostgreSQLノードの
~gitlab-psql/data/server.crt
の内容がセカンダリPostgreSQLノードの~gitlab-psql/.postgresql/root.crt
の内容と一致していることを確認してください。 -
データベースを複製します。
PRIMARY_DATABASE_HOST
をプライマリ PostgreSQL ノードの IP またはホスト名に置き換えてください:gitlab-ctl replicate-geo-database --slot-name=geo_2 --host=PRIMARY_DATABASE_HOST --sslmode=verify-ca
-
レプリケーションが終了したら、最後にもう一度Linuxパッケージを再設定して、
pg_hba.conf
がセカンダリPostgreSQLノードで正しいことを確認しなければなりません:gitlab-ctl reconfigure
プライマリサイトからセカンダリサイトへのシークレットのコピー
次に、プライマリサイトのKubernetesデプロイからセカンダリサイトのKubernetesデプロイにいくつかのシークレットをコピーします:
gitlab-geo-gitlab-shell-host-keys
gitlab-geo-rails-secret
-
gitlab-geo-registry-secret
レジストリレプリケーションが有効になっている場合。
-
kubectl
のコンテキストをプライマリのコンテキストに変更します。 -
プライマリのデプロイからこれらのシークレットを収集します:
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
-
kubectl
コンテキストをセカンダリのコンテキストに変更します。 -
これらのシークレットを適用してください:
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
次にデータベースパスワードを含むシークレットを作成します。以下のパスワードを適切な値に置き換えてください:
kubectl --namespace gitlab create secret generic geo \
--from-literal=postgresql-password=gitlab_user_password \
--from-literal=geo-postgresql-password=gitlab_geo_user_password
Geo セカンダリサイトとしてデプロイします。
このセクションは、セカンダリサイトの Kubernetes クラスターで実行します。
このChartをGeo Secondaryサイトとしてデプロイするには、この設定例から始めます。
-
設定例に基づいて
secondary.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 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
global.psql.host
global.geo.psql.host
- global.geo.nodeNameは管理エリアのGeoサイトのNameフィールドと一致する必要があります。
- nginx-ingress-geoはトラフィック用に事前に設定されたイングレスコントローラを有効にします。
- などの追加設定も行います:
- 外部データベースの場合、
global.psql.host
はセカンダリの読み取り専用レプリカデータベースで、global.geo.psql.host
は Geo トラッキングデータベースです。
-
この設定を使ってChartをデプロイします:
helm upgrade --install gitlab-geo gitlab/gitlab --namespace gitlab -f secondary.yaml
-
デプロイが完了し、アプリケーションがオンラインになるのを待ちます。
プライマリ経由でセカンダリ Geo サイトを追加
両方のデータベースが設定され、アプリケーションがデプロイされたので、プライマリ・サイトにセカンダリ・サイトの存在を知らせる必要があります:
- プライマリサイトにアクセスします。
- 左のサイドバーで、Search を選択するか、次のページに進んでください。
- Admin Areaを選択します。
- Geo > Add siteを選択します。
- セカンダリー・サイトを追加します。URLにはGitLabの完全なURLを使います。
- セカンダリサイトの
global.geo.nodeName
、Nameを入力します。これらの値は常に文字と文字が正確に一致する必要があります。 -
https://shanghai.gitlab.example.com
のように、内部URLを入力します。 - オプションで、セカンダリサイトでレプリケートするグループまたはストレージシャードを選択します。すべてをレプリケートする場合は空白のままにします。
- Add nodeを選択します。
セカンダリサイトが管理パネルに追加されると、セカンダリサイトは自動的にプライマリサイトの不足データのレプリケーションを開始します。このプロセスは「バックフィル」と呼ばれます。一方、プライマリサイトは 各セカンダリサイトに変更の通知を開始し、セカンダリサイトはそれらの変更を迅速に複製できるようにします。
オペレーション状況の確認
最後のステップは、完全に設定されたセカンダリサイトの Geo 設定を、Toolbox ポッドで再確認することです。
-
Toolbox ポッドを見つけてください:
kubectl --namespace gitlab get pods -lapp=toolbox
-
kubectl exec
でポッドに取り付けます:kubectl --namespace gitlab exec -ti gitlab-geo-toolbox-XXX -- bash -l
-
Geo の設定状況を確認します:
gitlab-rake gitlab:geo:check
以下のような出力が表示されるはずです:
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
-
Exception: getaddrinfo: Servname not supported for ai_socktype
、Kubernetesコンテナはホストクロックにアクセスできないので、心配しないでください。これで_OK_です。 -
OpenSSH configured to use AuthorizedKeysCommand ... no
が_期待_されます。このRakeタスクはローカルのSSHサーバーをチェックしていますが、実際にはgitlab-shell
チャートに存在し、別の場所にデプロイされ、すでに適切に設定されています。
-
レジストリ
セカンダリレジストリとプライマリレジストリを同期するには、通知シークレットを使用してレジストリレプリケーションを設定します。