セカンダリサイトのコンテナレジストリ

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed

セカンダリ Geoサイトでコンテナレジストリをセットアップして、プライマリ Geoサイト上のコンテナレジストリをミラーリングできます。このコンテナレジストリのレプリケーションは、ディザスターリカバリーのみを目的として使用されます。

セカンダリ Geoサイトのコンテナレジストリにはプッシュしないでください。データがプライマリサイトにレプリケートされないためです。

セカンダリサイトからコンテナレジストリデータをプルすることはお勧めしません。データが古くなっている可能性があるためです。この問題は、イシュー365864で解決される可能性があります。関心を示すために、イシューに同意することをお勧めします。

サポートされているコンテナレジストリ

Geoは、次のタイプのコンテナレジストリをサポートしています:

サポートされているイメージ形式

Geoでは、次のコンテナイメージ形式がサポートされています:

Docker V2, スキーマ1
Docker V2, スキーマ2
OCI（OpenコンテナInitiative）

また、GeoはBuildKitキャッシュイメージもサポートしています。

サポートされているストレージ

Docker

サポートされているレジストリストレージドライバーの詳細については、Dockerレジストリストレージドライバーを参照してください

レジストリのデプロイ時にロードバランシングに関する考慮事項を読み取り、GitLabに統合されたcontainer registryのストレージドライバーを設定する方法を読み取ります。

OCIアーティファクトをサポートするレジストリ

次のレジストリは、OCIアーティファクトをサポートしています:

CNCF Distribution - ローカル/オフライン検証
Azureコンテナレジストリ（ACR）
Amazon Elasticコンテナリポジトリ（ECR）
Googleアーティファクトレジストリ（GAR）
GitHub Packagesコンテナレジストリ（GHCR）
Bundle Bar

詳細については、OCI Distribution仕様を参照してください。

コンテナレジストリのレプリケーションを設定する

ストレージ非依存のレプリケーションを有効にして、クラウドまたはローカルストレージに使用できるようにします。新しいイメージがプライマリサイトにプッシュされるたびに、各セカンダリサイトはそれを独自のコンテナリポジトリにプルします。

コンテナレジストリのレプリケーションを設定するには、次の手順を実行します:

プライマリサイトを設定します。
セカンダリサイトを設定します。
コンテナレジストリのレプリケーションを検証します。

プライマリサイトを設定する

次の手順を実行する前に、コンテナレジストリがプライマリサイトでセットアップされ、動作していることを確認してください。

新しいコンテナイメージをレプリケートできるようにするには、コンテナレジストリがすべてのプッシュに対してプライマリサイトに通知イベントを送信する必要があります。コンテナレジストリとプライマリ上のWebノードの間で共有されるトークンは、通信をより安全にするために使用されます。

GitLabのプライマリサーバーにSSHで接続し、rootとしてサインインします（GitLab HAの場合、レジストリノードのみが必要です）:
```
sudo -i
```
/etc/gitlab/gitlab.rbを編集します:
```
# Configure the registry to listen on the public/internal interface
# Replace with the appropriate interface (for example, '0.0.0.0' for all interfaces)
registry['registry_http_addr'] = '0.0.0.0:5000'
registry['notifications'] = [
  {
    'name' => 'geo_event',
    'url' => 'https://<example.com>/api/v4/container_registry_event/events',
    'timeout' => '500ms',
    'threshold' => 5,
    'backoff' => '1s',
    'headers' => {
      'Authorization' => ['<replace_with_a_secret_token>']
    }
  }
]
```
<example.com>をプライマリサイトの/etc/gitlab/gitlab.rbファイルで定義されているexternal_urlに置き換え、<replace_with_a_secret_token>を文字で始まる大文字と小文字を区別する英数字文字列に置き換えます。< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echoを使用して、この英数字文字列を生成できます
外部レジストリ（GitLabと統合されていないもの）を使用する場合は、/etc/gitlab/gitlab.rbファイルで通知シークレット（registry['notification_secret']）のみを指定する必要があります。
GitLab HAのみ。すべてのWebノードで/etc/gitlab/gitlab.rbを編集します:
```
registry['notification_secret'] = '<replace_with_a_secret_token_generated_above>'
```
更新した各ノードを再構成します:
```
gitlab-ctl reconfigure
```

セカンダリサイトを設定する

次の手順を実行する前に、コンテナレジストリがセカンダリサイトでセットアップされ、動作していることを確認してください。

次の手順は、コンテナイメージがレプリケートされることを期待する各セカンダリサイトで実行する必要があります。

セカンダリサイトがプライマリサイトのコンテナレジストリと安全に通信できるようにする必要があるため、すべてのサイトに単一のキーペアが必要です。セカンダリサイトは、このキーを使用して、プライマリサイトのコンテナレジストリにアクセスするためのプル専用の短寿命のJSON Webトークンを生成します。

セカンダリサイトの各アプリケーションおよびSidekiqノードの場合:

ノードにSSHで接続し、rootユーザーとしてサインインします:
```
sudo -i
```
プライマリからノードに/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.keyをコピーします。

/etc/gitlab/gitlab.rbを編集して、以下を追加します:

gitlab_rails['geo_registry_replication_enabled'] = true

# Primary registry's hostname and port, it will be used by
# the secondary node to directly communicate to primary registry
gitlab_rails['geo_registry_replication_primary_api_url'] = 'https://primary.example.com:5050/'

変更を有効にするには、ノードを再構成します:
```
gitlab-ctl reconfigure
```

レプリケーションを検証する

コンテナレジストリのレプリケーションが機能していることを確認するには、セカンダリサイトで次の手順を実行します:

左側のサイドバーの下部で、管理者を選択します。
左側のサイドバーの下部にあるGeo > ノードを選択します。初期レプリケーション、または「バックフィル」は、おそらくまだ進行中です。

ブラウザで、プライマリサイトのGeo Nodes（Geoノード）ダッシュボードから、各Geoサイトの同期プロセスをモニタリングできます。

トラブルシューティング

コンテナレジストリのレプリケーションが有効になっていることを確認する

これは、Railsコンソールを使用して確認できます:

Geo::ContainerRepositoryRegistry.replication_enabled?

コンテナレジストリの通知イベントが見つからない

イメージがプライマリサイトのコンテナレジストリにプッシュされると、コンテナリポジトリの通知がトリガーされます
プライマリサイトのコンテナレジストリは、https://<example.com>/api/v4/container_registry_event/eventsでプライマリサイトのAPIを呼び出します
プライマリサイトは、replicable_name: 'container_repository', model_record_id: <ID of the container repository>を使用して、geo_eventsテーブルにレコードを挿入します。
レコードは、PostgreSQLによってセカンダリサイトのデータベースにレプリケートされます。
Geoログカーソルサービスは、新しいイベントを処理し、SidekiqジョブGeo::EventWorkerをエンキューします

これが正しく機能していることを確認するには、イメージをプライマリサイトのレジストリにプッシュし、次のコマンドをRailsコンソールで実行して、通知が受信され、イベントに処理されたことを確認します:

Geo::Event.where(replicable_name: 'container_repository')

Geo::ContainerRepositorySyncServiceからのエントリについてgeo.logを確認することで、これをさらに検証できます。

レジストリイベントログの応答ステータス401未承認は許可されていません

401 Unauthorizedエラーは、プライマリサイトのコンテナレジストリの通知がRailsアプリケーションによって承認されず、何かがプッシュされたことをGitLabに通知できないことを示します。

これを修正するには、レジストリの通知とともに送信される認可ヘッダーが、手順プライマリサイトを設定するで実行する必要があるように、プライマリサイトで設定されているものと一致していることを確認します。

レジストリエラー：`token from untrusted issuer: "<token>"`

Geoでコンテナイメージをレプリケートすると、token from untrusted issuer: "<token>"というエラーが表示される場合があります。

この問題は、コンテナレジストリの設定が正しくない場合に発生し、SidekiqのJSON Webトークン認証が失敗します。

この問題を解決するには、以下を実行します:

セカンダリサイトの設定するで説明されているように、両方のサイトが単一の署名キーペアを共有していることを確認します。
両方のコンテナレジストリとプライマリサイトとセカンダリサイトの両方が、同じトークン発行者を使用するように設定されていることを確認します。詳細については、GitLabとレジストリを個別のノードに設定するを参照してください。
マルチノードデプロイでは、Sidekiqノードで設定された発行者が、レジストリで設定された値と一致することを確認します。

コンテナレジストリの同期イベントをトラブルシューティングする

トラブルシューティングを支援するために、コンテナレジストリのレプリケーションプロセスを手動でトリガーできます:

左側のサイドバーの下部で、管理者を選択します。
Geo > サイトを選択します。
Secondary Site（セカンダリサイト）のレプリケーションの詳細で、コンテナリポジトリを選択します。
1つの行に対して再同期を選択するか、すべて再同期を選択します。

次のコマンドをセカンダリのRailsコンソールで実行して、再同期を手動でトリガーすることもできます:

registry = Geo::ContainerRepositoryRegistry.first # Choose a Geo registry entry
registry.replicator.sync # Resync the container repository
pp registry.reload # Look at replication state fields

#<Geo::ContainerRepositoryRegistry:0x00007f54c2a36060
 id: 1,
 container_repository_id: 1,
 state: "2",
 retry_count: 0,
 last_sync_failure: nil,
 retry_at: nil,
 last_synced_at: Thu, 28 Sep 2023 19:38:05.823680000 UTC +00:00,
 created_at: Mon, 11 Sep 2023 15:38:06.262490000 UTC +00:00>

stateフィールドは、同期状態を表します:

"0"：同期保留中（通常、同期されていないことを意味します）
"1"：同期が開始されました（同期ジョブが現在実行中です）
"2"：正常に同期されました
"3"：同期に失敗しました