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

GitLab Dedicatedインスタンスを作成する

  • プラン: Ultimate
  • 提供形態: GitLab Dedicated

GitLab Dedicated管理ポータルであるスイッチボードを使用して、あなたのGitLab Dedicatedインスタンスを作成します。

このプロセスには、次のステップが含まれます:

  • スイッチボードへのアクセスを取得します。
  • あなたのインスタンスを作成します。
  • 新しいインスタンスにアクセスします。

スイッチボードへのアクセスを取得します

スイッチボードにアクセスするには:

  1. アカウントチームに以下を提供してください:

    • 予想されるユーザー数
    • 購入したストレージ容量の合計
    • GiBでのリポジトリの初期ストレージサイズ
    • GitLab Dedicatedインスタンスを作成するためにスイッチボードアクセスが必要なユーザーのメールアドレス
    • Geo移行を使用するかどうか
    • GitLabが暗号化を管理する代わりに、独自の暗号化キーを使用してデータを保護するかどうか

    独自の暗号化キーを使用する場合、GitLabはキーの設定のためにAWSアカウントIDを提供します。

  2. 一時的なスイッチボード認証情報が記載された招待状をメールで確認してください。

    スイッチボード認証情報は、既存のGitLab.comまたはGitLab Self-Managed認証情報とは別個のものです。

  3. 一時的な認証情報を使用してスイッチボードにサインインしてください。

  4. パスワードを更新し、多要素認証（MFA）を設定します。

あなたのインスタンスを作成します

あなたのGitLab Dedicatedインスタンスを作成するには:

  1. スイッチボードにサインインします。

  2. Account detailsページで、あなたのサブスクリプション設定を確認してください:

    • Reference architecture: 予想される負荷と使用パターンに基づいた、インスタンスのインフラストラクチャサイズ階層。推奨される最大ユーザー数によって命名されます（例: 「最大3,000ユーザー」）。契約要件に基づき、アカウントチームによって決定されます。詳細については、予想される負荷を参照してください。
    • 購入したストレージ容量の合計: 契約で購入したストレージ容量の合計（リポジトリとオブジェクトストレージ）。アカウントチームによって事前に決定されます。
    • リポジトリのストレージ: すべてのリポジトリに利用可能なストレージ容量の合計（例: 16 GiB）。Evaluateツールを使用した初期容量計画の議論に基づきます。プロビジョニング後に増やすことはできますが、減らすことはできません。

    これらの設定は、契約とアカウントチームとの議論によって事前に決定されます。

  3. 設定ページで、以下のフィールドを完了します:

    • Tenant name: あなたのインスタンスURL（<tenant_name>.gitlab-dedicated.com）の名前を入力します。プロビジョニング後に変更することはできません。ただし、カスタムドメインを設定した場合は除きます。
    • Primary region: 運用とデータストレージに使用するAWSリージョンを選択します。すべてのインフラストラクチャ（コンピューティング、ストレージ、データベース）がこのリージョンでプロビジョニングされるため、プロビジョニング後に変更することはできません。
    • Primary region Availability Zone IDs（AZ IDs）: GitLabがアベイラビリティーゾーンを選択する方法を選択します:
      • Default AZ IDs: GitLabがあなたのインスタンスのアベイラビリティーゾーンを選択します。
      • Custom AZ IDs: 既存のAWSインフラストラクチャに一致する2つのAZ IDsを選択します。PrivateLink接続を含む、特定の可用性ゾーン内で独自のAWSインフラストラクチャをGitLab Dedicatedインスタンスに接続するために必要です。プロビジョニング後に変更することはできません。
    • Secondary region: オプション。GeoベースのディザスターリカバリーのためにAWSリージョンを選択します。プロビジョニング後に変更することはできません。Geo移行方法を使用している場合は不要です。
    • Secondary region Availability Zone IDs（AZ IDs）: セカンダリーリージョンを設定した場合にのみ利用可能です。GitLabがアベイラビリティーゾーンを選択する方法を選択します:
      • Default AZ IDs: GitLabがあなたのインスタンスのアベイラビリティーゾーンを選択します。
      • Custom AZ IDs: 既存のAWSインフラストラクチャに一致する2つのAZ IDsを選択します。プロビジョニング後に変更することはできません。
    • Backup region: バックアップレプリケーションのためにAWSリージョンを選択します。プライマリーとセカンダリーと同じでも、冗長性を高めるために異なっても構いません。バックアップボールトとレプリケーションはプロビジョニング中に設定されるため、プロビジョニング後に変更することはできません。
    • Maintenance window: 更新とメンテナンスのために、週ごとの希望する4時間枠を選択します。オプションはタイムゾーン（APAC、EU、米国）と一致します。詳細については、GitLab Dedicated情報ポータルを参照してください。

  4. セキュリティページで、インスタンスの暗号化を設定します。

    GitLabが暗号化キーを自動的に管理します（推奨）。または、コンプライアンス要件のために独自のキーを管理することもできます。

    顧客管理の暗号化キーは、独自のAWSアカウントでの追加のセットアップと継続的な管理が必要です。あなたのインスタンスをプロビジョニングする前に、AWS KMSキーを作成し、設定する必要があります。一度設定されると、これらの設定はプロビジョニング後に変更できません。

    GitLab管理の暗号化（推奨）の場合:

    • すべてのAWS Key Management Service（KMS）フィールドを空のままにします。GitLabは、すべてのサービス（バックアップ、EBSディスク、RDSデータベース、S3オブジェクトストレージ、および高度な検索）にわたって暗号化を自動的に設定します。

    顧客管理の暗号化の場合:

    1. 暗号化キーを作成します。

    2. オプション。レプリカキーは、Geoベースのディザスターリカバリーのためにセカンダリーリージョンを選択した場合にのみ作成します。

    3. 各キーまたはレプリカキーのAmazon Resource Name（ARN）を収集します。ARN形式は次のとおりです: arn:aws:kms:<REGION>:<ACCOUNT-ID>:key/<KEY-ID>。

      例: arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012

    4. 選択した各AWSリージョン（プライマリー、セカンダリー、バックアップ）について、このマッピングを使用してキーフィールドを完了します:

      • Primary region Default: プライマリーリージョンのキーARNを使用します。
      • Secondary region Default: レプリカキーARNを使用します（Geoのためにセカンダリーリージョンを設定した場合のみ）。
      • Backup region Default: バックアップリージョンのキーARNを使用します。あなたのバックアップリージョンがプライマリーリージョンと同じである場合、同じキーARNを使用します。

    5. 各サービス（バックアップ、EBS（ディスク）、RDS（データベース）、S3（オブジェクトストレージ）、高度な検索）について: そのリージョンのデフォルトキーを使用するために空のままにするか、そのサービスに特定のKMSキーARNを入力します。サービス固有のキーは、対応するデフォルトキーと同じAWSリージョンのものである必要があります。

    6. 使用しないリージョンのフィールドは空白のままにします。例えば、プライマリーリージョンのみを使用している場合、セカンダリーおよびバックアップリージョンのフィールドは空のままにします。

    7. 続行する前にすべてのARNが正しいことを確認してください。

  5. オプション。Geo migration secretsページで、あなたのGitLab Self-Managedインスタンスから暗号化されたシークレットを収集し、アップロードします:

    このステップは、アカウント設定中にGeo移行を選択した場合にのみ必要です。

    1. インストールタイプに対応するスクリプトをダウンロードし、あなたのGitLab Self-Managedインスタンスで実行してください。
    2. あなたのmigration_secrets.json.ageファイルをアップロードします。
    3. オプション。オプション。あなたのssh_host_keys.json.ageファイルをアップロードします（カスタムドメインの使用を予定している場合は推奨）。

    詳細な手順とトラブルシューティングについては、GeoでGitLab Dedicatedに移行するを参照してください。

  6. Tenant summaryページで、すべての設定の詳細を確認してください。

    プロビジョニング後、これらの設定は変更できません:

    • AWS KMSキー（BYOK）の設定
    • AWSリージョン（プライマリー、セカンダリー、およびバックアップリージョン）
    • AWSアベイラビリティーゾーンIDs（プライマリーおよびセカンダリーリージョン）
    • リポジトリ容量（増加のみ可能）
    • テナント名とURL

  7. Create tenantを選択します。

あなたのインスタンスのプロビジョニングには最大3時間かかります。セットアップが完了すると、確認メールが届きます。

あなたのインスタンスにアクセスします

あなたのGitLab Dedicatedインスタンスにアクセスするには:

  1. スイッチボードにサインインします。

  2. Access your GitLab Dedicated instanceバナーで、認証情報の表示を選択します。

  3. テナントURLと一時的なroot認証情報をコピーします。

    一時的なroot認証情報は一度しか取得することはできません。スイッチボードを離れる前に、それらを安全に保管してください。

  4. あなたのテナントURLにアクセスし、一時的なroot認証情報でサインインします。

  5. 一時的なrootパスワードを変更します。

  6. 管理者エリアで、ライセンスキーを追加します。

  7. スイッチボードに戻り、必要に応じてユーザーを追加します。

次の手順

アップグレードとメンテナンスのために、リリースロールアウトスケジュールを確認してください。

以下の機能が必要な場合は、事前に計画を立ててください:

すべての設定オプションについては、あなたのGitLab Dedicatedインスタンスを設定を参照してください。

GitLab 18.0以降、GitLab Duo Core機能は新しいインスタンスでデフォルトで有効になります。データレジデンシー要件またはAI使用ポリシーに準拠するため、GitLab Duo Coreを無効にすることができます。