外部オブジェクトストレージでGitLabチャートを設定する
GitLabは、Kubernetesで可用性の高い永続データをオブジェクトストレージに依存しています。GitLabは、主要なクラウドプロバイダーのオブジェクトストレージに対して、静的な認証情報と、クラウド固有のサービスを介した一時的な認証情報という2種類の認証方法をサポートしています。
静的な認証情報
これらの認証情報は、すべてのプロバイダーに対して有効期間の長いアクセスキーとシークレットです:
- AWS S3: アクセスキーID + クライアントのシークレットキー
- Google Cloud Storage: サービスアカウントJSONキーファイル
- Azure Blob Storage: ストレージアカウント名 + アクセスキー、またはクライアントID + テナントID + クライアントシークレット
Cloud IAMを介した一時的な認証情報
GitLabは、動的な有効期間の短い認証情報のために、プロバイダー固有のワークロードIDメカニズムを取得できます:
- AWS S3: サービスアカウント用IAMロール(IRSA)
- Google Cloud Storage: ワークロードアイデンティティフェデレーション。
- Azure Blob Storage: Azure Kubernetes ServiceのワークロードID
これらの一時的な認証情報メカニズムは、以下によりセキュリティを向上させます:
- 有効期間の長い静的な認証情報を排除します。
- 自動化された認証情報のローテーションを提供します。
- きめ細かいアクセス制御
- 認証情報の使用状況の監査ログをサポートします。
- クラウドプロバイダーのIAMポリシーと統合します。
MinIOの無効化
デフォルトでは、minioという名前のS3互換ストレージソリューションがチャートとともにデプロイされます。本番環境品質のデプロイの場合、Google Cloud StorageやAWS S3などのホストされているオブジェクトストレージソリューションを使用することをお勧めします。
MinIOを無効にするには、このオプションを設定し、以下の関連ドキュメントに従ってください:
--set global.minio.enabled=falseAzure 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ストレージを参照)、Azure 、GCSドライバーの例は、examples/objectstorageにあります。
レジストリの設定
- 使用するストレージサービスを決定します。
- 適切なファイルを
registry-storage.yamlにコピーします。 - 環境に適した値で編集します。
- シークレットを作成するには、ストレージに関するレジストリチャートのドキュメントに従ってください。
- ドキュメントの説明に従ってチャートを設定します。
LFS、アーティファクト、アップロード、パッケージ、外部差分、Terraformステート、依存プロキシ、セキュアファイル
LFS、アーティファクト、アップロード、パッケージ、外部差分、Terraformステート、セキュアファイル、および仮名化子のオブジェクトストレージの設定は、次のキーを介して行われます:
global.appConfig.lfsglobal.appConfig.artifactsglobal.appConfig.uploadsglobal.appConfig.packagesglobal.appConfig.externalDiffsglobal.appConfig.dependencyProxyglobal.appConfig.terraformStateglobal.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詳細については、アプリ設定に関するチャートのグローバルドキュメントを参照してください。
接続の詳細ドキュメントごとにシークレットを作成し、提供されたシークレットを使用するようにチャートを設定します。同じシークレットをすべてに使用できます。
AWS (MinIOを使用したAzureのようなS3互換)およびGoogleプロバイダーの例は、examples/objectstorageにあります。
S3暗号化
GitLabは、S3バケットに保存されているデータを暗号化するためにAmazon KMSをサポートしています。これは、次の2つの方法で有効にできます:
- AWSで、デフォルトの暗号化を使用するようにS3バケットを設定します。
- GitLabで、サーバーサイド暗号化ヘッダーを有効にします。
これら2つのオプションは相互に排他的ではありません。デフォルトの暗号化ポリシーを設定できますが、オーバーライドするためにサーバーサイド暗号化ヘッダーを有効にすることもできます。
詳細については、暗号化されたS3バケットに関するGitLabドキュメントを参照してください。
アプリ設定の設定
- 使用するストレージサービスを決定します。
- 適切なファイルを
rails.yamlにコピーします。 - 環境に適した値で編集します。
- シークレットを作成するには、接続の詳細ドキュメントに従ってください。
- ドキュメントの説明に従ってチャートを設定します。
バックアップ
バックアップはオブジェクトストレージにも保存されており、含まれている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=configGKEのワークロードアイデンティティフェデレーションを使用したGoogle Cloud Storage(GCS)の場合、バックエンドとバケットのみを設定する必要があります。gitlab.toolbox.backups.objectStorage.config.secretとgitlab.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のバケットに対する読み取り/書き込みを行うのに十分なアクセス権を持つユーザーとして認証するように、設定ファイルを設定する必要があります。
バックアップストレージの例
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ロールを持つサービスアカウントを作成し、サービスアカウントキーを作成することでファイルを作成できます。以下は、gcloudCLIを使用してファイルを作成する例です。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.configAzureストレージ上
[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
シークレットを作成する
kubectl create secret generic storage-config --from-file=config=storage.config
Google Cloud CDN
Google CDNを使用して、アーティファクトバケットからデータをキャッシュし、フェッチできます。これは、パフォーマンスを向上させ、ネットワークエグレスコストを削減するのに役立ちます。
CDNの設定は、次のキーを介して行われます:
global.appConfig.artifacts.cdn.secretglobal.appConfig.artifacts.cdn.key(デフォルトはcdnです)
CDNを使用するには:
署名付きURLのキーを作成します。
rails.googlecdn.yamlの例を使用して、パラメータを含むYAMLファイルを用意します。次の情報を入力する必要があります:url: 手順1からのCDNホストのベースURLkey_name: 手順2からのキー名key: 手順2からの実際のシークレット
このYAMLファイルを、
cdnキーの下のKubernetesシークレットに読み込むします。たとえば、gitlab-rails-cdnシークレットを作成するには:kubectl create secret generic gitlab-rails-cdn --from-file=cdn=rails.googlecdn.ymlglobal.appConfig.artifacts.cdn.secretをgitlab-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)の送信リクエストを許可します。