正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

外部オブジェクトストレージでGitLabチャートを設定する

GitLabは、Kubernetesで可用性の高い永続データをオブジェクトストレージに依存しています。GitLabは、主要なクラウドプロバイダーのオブジェクトストレージに対して、静的な認証情報と、クラウド固有のサービスを介した一時的な認証情報という2種類の認証方法をサポートしています。

静的な認証情報

これらの認証情報は、すべてのプロバイダーに対して有効期間の長いアクセスキーとシークレットです:

  • AWS S3: アクセスキーID + クライアントのシークレットキー
  • Google Cloud Storage: サービスアカウントJSONキーファイル
  • Azure Blob Storage: ストレージアカウント名 + アクセスキー、またはクライアントID + テナントID + クライアントシークレット

Cloud IAMを介した一時的な認証情報

GitLabは、動的な有効期間の短い認証情報のために、プロバイダー固有のワークロードIDメカニズムを取得できます:

これらの一時的な認証情報メカニズムは、以下によりセキュリティを向上させます:

  • 有効期間の長い静的な認証情報を排除します。
  • 自動化された認証情報のローテーションを提供します。
  • きめ細かいアクセス制御
  • 認証情報の使用状況の監査ログをサポートします。
  • クラウドプロバイダーのIAMポリシーと統合します。

MinIOの無効化

デフォルトでは、minioという名前のS3互換ストレージソリューションがチャートとともにデプロイされます。本番環境品質のデプロイの場合、Google Cloud StorageやAWS S3などのホストされているオブジェクトストレージソリューションを使用することをお勧めします。

MinIOを無効にするには、このオプションを設定し、以下の関連ドキュメントに従ってください:

--set global.minio.enabled=false

完全な設定の例に記載されています。

Azure Blob Storage

Azure BLOBストレージのダイレクトサポートは、アップロードされた添付ファイル、CIジョブアーティファクト、LFS、および統合された設定を介してサポートされるその他のオブジェクトタイプで利用できます。以前のGitLabのバージョンでは、Azure MinIOゲートウェイが必要でした。

GitLabは、DockerレジストリのストレージとしてAzure MinIOゲートウェイをサポートしていません対応するAzureの例を、Dockerレジストリの設定時に参照してください。

Azureではコンテナのコレクションを表す用語としてを使用していますが、GitLabではこの用語をバケットに標準化しています。

Azure BLOBストレージでは、統合されたオブジェクトストレージの設定を使用する必要があります。1つのAzureストレージアカウント名とキーを、複数のAzure BLOBコンテナで使用する必要があります。オブジェクトタイプ(artifactsアーティファクト、uploadsアップロードなど)による個々のconnection設定のカスタマイズは許可されていません。

Azure BLOBストレージを有効にするには、Azure connectionを定義する例としてrails.azurerm.yamlを参照してください。これは、以下のようにシークレットとして読み込むことができます:

kubectl create secret generic gitlab-rails-storage --from-file=connection=rails.azurerm.yml

次に、MinIOを無効にして、これらのグローバル設定を設定します:

--set global.minio.enabled=false
--set global.appConfig.object_store.enabled=true
--set global.appConfig.object_store.connection.secret=gitlab-rails-storage

デフォルト名またはバケット設定でコンテナ名を設定するために、Azureコンテナを作成してください。

Requests to the local network are not allowedでリクエストが失敗する場合は、トラブルシューティングのセクションを参照してください。

Dockerレジストリイメージ

registryチャートのオブジェクトストレージの設定は、registry.storageキーと、global.registry.bucketキーを介して行われます。

--set registry.storage.secret=registry-storage
--set registry.storage.key=config
--set global.registry.bucket=bucket-name

バケット名は、シークレットとglobal.registry.bucketの両方で設定する必要があります。そのシークレットはレジストリサーバーで使用され、グローバル変数はGitLabのバックアップで使用されます。

ストレージに関するレジストリチャートのドキュメントごとにシークレットを作成し、このシークレットを使用するようにチャートを設定します。

S3 (S3互換のストレージですが、Azure MinIOゲートウェイはサポートされていません。Azure BLOBストレージを参照)、AzureGCSドライバーの例は、examples/objectstorageにあります。

レジストリの設定

  1. 使用するストレージサービスを決定します。
  2. 適切なファイルをregistry-storage.yamlにコピーします。
  3. 環境に適した値で編集します。
  4. シークレットを作成するには、ストレージに関するレジストリチャートのドキュメントに従ってください。
  5. ドキュメントの説明に従ってチャートを設定します。

LFS、アーティファクト、アップロード、パッケージ、外部差分、Terraformステート、依存プロキシ、セキュアファイル

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

次の点にも注意してください:

  • バケット設定でデフォルト名またはカスタム名のバケットを作成する必要があります。
  • それぞれに異なるバケットが必要です。そうしないと、バックアップからの復元が正常に機能しません。
  • 外部ストレージへのMR差分の保存はデフォルトでは有効になっていないため、externalDiffsのオブジェクトストレージ設定を有効にするには、global.appConfig.externalDiffs.enabledキーにtrueの値が必要です。
  • 依存プロキシ機能はデフォルトで有効になっていないため、dependencyProxyのオブジェクトストレージ設定を有効にするには、global.appConfig.dependencyProxy.enabledキーにtrueの値が必要です。

以下は、設定オプションの例です:

--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

詳細については、アプリ設定に関するチャートのグローバルドキュメントを参照してください。

接続の詳細ドキュメントごとにシークレットを作成し、提供されたシークレットを使用するようにチャートを設定します。同じシークレットをすべてに使用できます。

AWSMinIOを使用したAzureのようなS3互換)およびGoogleプロバイダーの例は、examples/objectstorageにあります。

S3暗号化

GitLabは、S3バケットに保存されているデータを暗号化するためにAmazon KMSをサポートしています。これは、次の2つの方法で有効にできます:

これら2つのオプションは相互に排他的ではありません。デフォルトの暗号化ポリシーを設定できますが、オーバーライドするためにサーバーサイド暗号化ヘッダーを有効にすることもできます。

詳細については、暗号化されたS3バケットに関するGitLabドキュメントを参照してください。

アプリ設定の設定

  1. 使用するストレージサービスを決定します。
  2. 適切なファイルをrails.yamlにコピーします。
  3. 環境に適した値で編集します。
  4. シークレットを作成するには、接続の詳細ドキュメントに従ってください。
  5. ドキュメントの説明に従ってチャートを設定します。

バックアップ

バックアップはオブジェクトストレージにも保存されており、含まれているMinIOサービスではなく、外部を指すように設定する必要があります。バックアップ/復元手順では、2つの異なるバケットを使用します:

  • バックアップを保存するためのバケット(global.appConfig.backups.bucket
  • 復元プロセス中に既存のデータを保持するための一時バケット(global.appConfig.backups.tmpBucket

AWS S3互換のオブジェクトストレージシステム、Google Cloud Storage、およびAzure BLOBストレージがサポートされているバックエンドです。global.appConfig.backups.objectStorage.backendをAWS S3の場合はs3、Google Cloud Storageの場合はgcs、Azure BLOBストレージの場合はazureに設定して、バックエンドタイプを設定できます。gitlab.toolbox.backups.objectStorage.configキーを使用して、接続設定も指定する必要があります。

シークレットでGoogle Cloud Storageを使用する場合、GCPプロジェクトはglobal.appConfig.backups.objectStorage.config.gcpProject値で設定する必要があります。

S3互換ストレージの場合:

--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)の場合:

--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のワークロードアイデンティティフェデレーションを使用したGoogle Cloud Storage(GCS)の場合、バックエンドとバケットのみを設定する必要があります。gitlab.toolbox.backups.objectStorage.config.secretgitlab.toolbox.backups.objectStorage.config.keyが設定されていないことを確認して、クラスターがGoogleのアプリケーションのデフォルト認証情報を使用するようにします:

--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:

--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

詳細については、バックアップ/復元オブジェクトストレージのドキュメントを参照してください。

他のオブジェクトストレージロケーションからファイルをバックアップまたは復元するには、すべてのGitLabのバケットに対する読み取り/書き込みを行うのに十分なアクセス権を持つユーザーとして認証するように、設定ファイルを設定する必要があります。

バックアップストレージの例

  1. storage.configファイルを作成する:

    • Amazon S3では、コンテンツはs3cmd設定ファイル形式にする必要があります

      [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ロールを持つサービスアカウントを作成し、サービスアカウントキーを作成することでファイルを作成できます。以下は、gcloud CLIを使用してファイルを作成する例です。

      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ストレージ上

      [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
  2. シークレットを作成する

    kubectl create secret generic storage-config --from-file=config=storage.config

Google Cloud CDN

Google CDNを使用して、アーティファクトバケットからデータをキャッシュし、フェッチできます。これは、パフォーマンスを向上させ、ネットワークエグレスコストを削減するのに役立ちます。

CDNの設定は、次のキーを介して行われます:

  • global.appConfig.artifacts.cdn.secret
  • global.appConfig.artifacts.cdn.key(デフォルトはcdnです)

CDNを使用するには:

  1. アーティファクトバケットをバックエンドとして使用するように、CDNを設定します。

  2. 署名付きURLのキーを作成します。

  3. バケットから読み取りを行う権限をCDNサービスアカウントに付与します。

  4. rails.googlecdn.yamlの例を使用して、パラメータを含むYAMLファイルを用意します。次の情報を入力する必要があります:

    • url: 手順1からのCDNホストのベースURL
    • key_name: 手順2からのキー名
    • key: 手順2からの実際のシークレット
  5. このYAMLファイルを、cdnキーの下のKubernetesシークレットに読み込むします。たとえば、gitlab-rails-cdnシークレットを作成するには:

    kubectl create secret generic gitlab-rails-cdn --from-file=cdn=rails.googlecdn.yml
  6. global.appConfig.artifacts.cdn.secretgitlab-rails-cdnに設定します。helmパラメータを使用してこれを設定する場合は、次を使用します:

    --set global.appConfig.artifacts.cdn.secret=gitlab-rails-cdn

トラブルシューティング

Azure BLOB: URL [FILTERED] is blocked: Requests to the local network are not allowed

これは、Azure BLOBホスト名がRFC1918(ローカル/プライベート)IPアドレスに解決される場合に発生します。回避策として、Azure BLOBホスト名(yourinstance.blob.core.windows.net)の送信リクエストを許可します。