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

Amazon Web Services（AWS）にGitLab POCをインストールする

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

このページでは、公式Linuxパッケージを使用してAWS上にGitLabを構築する一般的な設定の流れを説明します。ニーズに合わせてカスタマイズしてください。

ユーザー数が1,000人以下の組織の場合、推奨されるAWSインストール方法は、EC2単一インスタンス構成でLinuxパッケージインストールを起動し、データをバックアップするためのスナップショット戦略を実装することです。詳細については、20 RPSまたは1,000ユーザーのリファレンスアーキテクチャを参照してください。

本番環境グレードのGitLabの使用を開始する

このドキュメントは、概念実証インスタンスのインストールガイドです。これはリファレンスアーキテクチャではなく、高可用性設定にもなりません。代わりに、GitLab Environment Toolkit（GET）を使用することを強くおすすめします。

このガイドに正確に従うと、概念実証インスタンスを構築できます。これは、Non-HA（非HA）構成の40 RPSまたは2,000ユーザーのリファレンスアーキテクチャにおけるtwo availability zone implementation（2つのアベイラビリティーゾーン実装）をscaled down（縮小）した形に相当します。2,000ユーザーのリファレンスアーキテクチャは、コストと複雑さを抑えながらある程度のスケーリングを実現することを主な目的としているため、HAではありません。60 RPSまたは3,000ユーザーのリファレンスアーキテクチャが、GitLab HAとしての最小構成です。この構成では、HAを実現するための追加のサービスロールを含みます。特筆すべき点は、GitリポジトリストレージをGitalyクラスターでHA化し、三重冗長を規定していることです。

GitLabは、主に2種類のリファレンスアーキテクチャを維持およびテストしています。Linux package architectures（Linuxパッケージアーキテクチャ）はインスタンスのコンピューティングリソース上に実装され、Cloud Native Hybrid architectures（クラウドネイティブハイブリッドアーキテクチャ）はKubernetesクラスターを最大限に活用します。クラウドネイティブハイブリッドのリファレンスアーキテクチャ仕様は、リファレンスアーキテクチャのサイズ別ページの追補セクションとして掲載されています。これらのページは、Linuxパッケージアーキテクチャの説明から始まります。たとえば、60 RPSまたは3,000ユーザーのクラウドネイティブリファレンスアーキテクチャは、60 RPSまたは3,000ユーザーのリファレンスアーキテクチャページの、Helmチャートを使用したクラウドネイティブハイブリッドのリファレンスアーキテクチャ（代替）というサブセクションに掲載されています。

本番環境グレードのLinuxパッケージインストールの使用を開始する

Infrastructure as CodeツールであるGitLab Environment Tool（GET）は、AWS上でLinuxパッケージを使用して構築する際の出発点として最適です。とりわけ、HA構成を目標とする場合に有用です。GETはすべてを自動化するわけではありませんが、Gitalyクラスターのような複雑なセットアップを自動構成します。GETはオープンソースであるため、誰でも機能を追加したり、改善にコントリビュートしたりできます。

本番環境グレードのクラウドネイティブハイブリッドGitLabの使用を開始する

GitLab Environment Toolkit（GET）は、明確な設計思想に基づいたTerraformおよびAnsibleのスクリプト群です。これらのスクリプトは、選択したクラウドプロバイダー上でLinuxパッケージまたはクラウドネイティブハイブリッド環境をデプロイする際に役立ち、GitLabデベロッパーがGitLab Dedicated（例）で使用します。

GitLab Environment Toolkitを使用して、AWS上にクラウドネイティブハイブリッド環境をデプロイできます。ただし必須ではなく、すべての有効な組み合わせをサポートしているとは限りません。なお、スクリプトは現状のまま提供されており、必要に応じて調整できます。

はじめに

このセットアップでは主にLinuxパッケージを使用しますが、ネイティブAWSサービスも活用します。LinuxパッケージにバンドルされているPostgreSQLやRedisの代わりに、Amazon RDSとElastiCacheを使用します。

このガイドでは、マルチノードのセットアップについて説明します。まず、Virtual Private Cloudとサブネットを設定し、その後、データベースサーバー用のRDS、Redisクラスター構成のElastiCacheなどのサービスを統合し、最終的にカスタムスケーリングポリシーを適用したオートスケールグループでそれらを管理します。

要件

AWSおよびAmazon EC2の基本的な知識に加えて、次のものが必要です:

ACM経由でプロビジョニングした証明書の検証には、数時間かかる場合があります。後の作業を遅らせないために、できるだけ早く証明書をリクエストしてください。

アーキテクチャ

次の図は、推奨アーキテクチャの概要を示しています。

2つのアベイラビリティーゾーンを持つ、非HA構成の縮小版AWSアーキテクチャ。

AWSのコスト

GitLabは次のAWSサービスを使用しています。各サービスの価格情報はリンク先を参照してください:

  • EC2: GitLabは共有ハードウェアにデプロイされ、オンデマンド料金が適用されます。専有インスタンスまたはリザーブドインスタンスでGitLabを実行する場合、コストの詳細についてはEC2の料金ページを参照してください。
  • S3: GitLabはS3（料金ページ）を使用して、バックアップ、アーティファクト、LFSオブジェクトを保存します。
  • NLB: GitLabインスタンスにリクエストをルーティングするためのネットワークロードバランサー（料金ページ）。
  • RDS: PostgreSQLを使用するAmazon Relational Database Service（料金ページ）。
  • ElastiCache: Redis構成を提供するために使用するインメモリキャッシュ環境（料金ページ）。

IAM EC2インスタンスのロールとプロファイルを作成する

Amazon S3オブジェクトストレージを使用しているため、EC2インスタンスにはS3バケットに対する読み取り、書き込み、一覧表示の権限が必要です。GitLabの設定にAWSキーを埋め込むのを避けるため、IAMロールを使用して、GitLabインスタンスにこのアクセス権を付与します。IAMロールにアタッチするためのIAMポリシーを作成する必要があります:

IAMポリシーを作成する

  1. IAMダッシュボードに移動し、左側のメニューでポリシーを選択します。

  2. ポリシーの作成を選択し、JSONタブを選択して、ポリシーを追加します。セキュリティのベストプラクティスに従い、_最小権限_の原則を適用することで、必要なアクションを実行するために必要な権限のみをロールに付与します。

    1. 図に示すように、S3バケット名のプレフィックスがgl-であると仮定して、次のポリシーを追加します:
    {   "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::gl-*/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:AbortMultipartUpload",
                "s3:ListMultipartUploadParts",
                "s3:ListBucketMultipartUploads"
            ],
            "Resource": "arn:aws:s3:::gl-*"
        }
    ]
}

  3. 次へを選択して、ポリシーを確認します。ポリシーに名前を付け（この例ではgl-s3-policy）、ポリシーの作成を選択します。

IAMロールを作成する

  1. 引き続きIAMダッシュボードで、左側のメニューのロールを選択し、ロールを作成するを選択します。
  2. Trusted entity typeで、AWS serviceを選択します。Use caseで、ドロップダウンリストとラジオボタンの両方でEC2を選択し、次へを選択します。
  3. ポリシーフィルターで、先ほど作成したgl-s3-policyを検索して選択し、次へを選択します。
  4. ロールに名前を付けます（この例ではGitLabS3Access）。必要に応じてタグを追加します。ロールを作成するを選択します。

このロールは、後で起動テンプレートを作成するときに使用します。

ネットワークを設定する

まず、GitLabクラウドインフラストラクチャ用のVPCを作成します。次に、少なくとも2つのアベイラビリティーゾーン（AZ）にパブリックインスタンスとプライベートインスタンスを配置するためのサブネットを作成します。パブリックサブネットには、ルートテーブルの設定と関連付けられたインターネットゲートウェイが必要です。

Virtual Private Cloud（VPC）を作成する

ここで、ユーザーが制御する仮想ネットワーキング環境であるVPCを作成します:

  1. Amazon Web Servicesにサインインします。

  2. 左側のメニューからYour VPCsを選択し、Create VPCを選択します。「Name tag」にgitlab-vpcと入力し、「IPv4 CIDR block」に10.0.0.0/16と入力します。専用ハードウェアが不要な場合、「Tenancy」はデフォルトのままでかまいません。準備ができたら、Create VPCを選択します。

    GitLabクラウドインフラストラクチャ用のVPCを作成します。

  3. VPCを選択し、アクション、Edit VPC Settingsの順に選択し、Enable DNS resolutionをオンにします。完了したら、保存を選択します。

サブネット

ここでは、さまざまなアベイラビリティーゾーンにサブネットをいくつか作成します。各サブネットが、先ほど作成したVPCに関連付けられ、CIDRブロックが重複していないことを確認してください。これにより、冗長性を確保するためのマルチAZを有効にすることもできます。

ロードバランサーとRDSインスタンスに対応するように、プライベートサブネットとパブリックサブネットも作成します:

  1. 左側のメニューからSubnetsを選択します。

  2. Create subnetを選択します。IPに基づいたわかりやすい名前タグ（例: gitlab-public-10.0.0.0）を付け、先ほど作成したVPCを選択します。アベイラビリティーゾーンを選択し（この例ではus-west-2a）、IPv4 CIDR blockには/24サブネットの10.0.0.0/24を指定します:

    サブネットを作成します。

  3. 同様の手順に従って、次のすべてのサブネットを作成します:

    名前タグタイプアベイラビリティーゾーンCIDRブロック
    gitlab-public-10.0.0.0publicus-west-2a10.0.0.0/24
    gitlab-private-10.0.1.0privateus-west-2a10.0.1.0/24
    gitlab-public-10.0.2.0publicus-west-2b10.0.2.0/24
    gitlab-private-10.0.3.0privateus-west-2b10.0.3.0/24

  4. すべてのサブネットを作成したら、2つのパブリックサブネットに対してAuto-assign IPv4を有効にします:

    1. 各パブリックサブネットを順番に選択し、アクション、Edit subnet settingsの順に選択します。Enable auto-assign public IPv4 addressオプションをオンにして、保存します。

インターネットゲートウェイ

次に、同じダッシュボードで、Internet Gatewaysに移動して、新しいゲートウェイを作成します:

  1. 左側のメニューからInternet Gatewaysを選択します。

  2. Create internet gatewayを選択し、gitlab-gatewayという名前を付けて、作成を選択します。

  3. 作成したインターネットゲートウェイをテーブルから選択し、アクションドロップダウンリストから「Attach to VPC」を選択します。

    インターネットゲートウェイを作成します。

  4. リストからgitlab-vpcを選択し、Attachをクリックします。

NATゲートウェイを作成する

プライベートサブネットにデプロイされたインスタンスは、アップデートのためにインターネットに接続する必要がありますが、パブリックインターネットからアクセスされないように設定します。そのために、各パブリックサブネットにデプロイされたNATゲートウェイを使用します:

  1. VPCダッシュボードに移動し、左側のメニューバーでNAT Gatewaysを選択します。
  2. Create NAT Gatewayを選択し、次の項目を設定します:
    1. Subnet: ドロップダウンリストからgitlab-public-10.0.0.0を選択します。
    2. Elastic IP Allocation ID: 既存のElastic IPを入力するか、Allocate Elastic IP addressを選択し、NATゲートウェイに新しいIPを割り当てます。
    3. 必要に応じてタグを追加します。
    4. Create NAT Gatewayを選択します。

2つ目のNATゲートウェイを作成します。今回は、2つ目のパブリックサブネットであるgitlab-public-10.0.2.0に配置します。

ルートテーブル

パブリックルートテーブル

前の手順で作成したインターネットゲートウェイ経由でパブリックサブネットがインターネットにアクセスできるように、ルートテーブルを作成する必要があります。

VPCダッシュボードで、次の手順に従います:

  1. 左側のメニューからRoute Tablesを選択します。
  2. Create Route Tableを選択します。
  3. 「Name tag」にgitlab-publicと入力し、「VPC」でgitlab-vpcを選択します。
  4. 作成を選択します。

次に、インターネットゲートウェイを新しいターゲットとして追加し、すべての宛先からトラフィックを受信するように設定する必要があります。

  1. 左側のメニューからRoute Tables）を選択し、gitlab-publicルートを選択して、下部のオプションを表示します。
  2. Routesタブを選択し、Edit routes > Add routeを選択して、宛先に0.0.0.0/0を設定します。ターゲット列で、Internet Gatewayを選択し、先ほど作成したgitlab-gatewayを選択します。完了したら変更を保存を選択します。

次に、public（パブリック）サブネットをルートテーブルに関連付ける必要があります:

  1. Subnet Associationsタブを選択し、Edit subnet associationsを選択します。
  2. パブリックサブネットのチェックボックスのみをオンにし、Save associationsを選択します。

プライベートルートテーブル

各プライベートサブネット内のインスタンスが、同じアベイラビリティーゾーン内の対応するパブリックサブネットにあるNATゲートウェイ経由でインターネットにアクセスできるように、2つのプライベートルートテーブルを作成する必要があります。

  1. 先ほどと同様の手順に従って、プライベートルートテーブルを2つ作成し、gitlab-private-aおよびgitlab-private-bという名前を付けます。
  2. 次に、各プライベートルートテーブルに新しいルートを追加します。宛先を0.0.0.0/0とし、ターゲットには先ほど作成したNATゲートウェイのいずれかを指定します。
    1. gitlab-private-aルートテーブルの新しいルートには、gitlab-public-10.0.0.0に作成したNATゲートウェイをターゲットとして追加します。
    2. 同様に、gitlab-private-bの新しいルートには、gitlab-public-10.0.2.0にあるNATゲートウェイをターゲットとして追加します。
  3. 最後に、各プライベートサブネットをプライベートルートテーブルに関連付けます。
    1. gitlab-private-10.0.1.0をgitlab-private-aに関連付けます。
    2. gitlab-private-10.0.3.0をgitlab-private-bに関連付けます。

ロードバランサー

ロードバランサーを作成し、GitLabアプリケーションサーバー間でポート80および443に対する受信トラフィックを均等に分散させます。後ほど作成するスケーリングポリシーに基づいて、必要に応じてインスタンスがロードバランサーに追加または削除されます。さらに、ロードバランサーはインスタンスに対してヘルスチェックを実行します。SSL/TLSを環境内で処理するにはさまざまな方法がありますが、このPOCではバックエンドでSSLを使用せず、ロードバランサーでSSLの終端を行います。

EC2ダッシュボードで、左側のナビゲーションバーのLoad Balancersを探します:

  1. Create Load Balancerを選択します。

  2. Network Load Balancerを選択し、作成を選択します。

  3. Load Balancer nameにgitlab-loadbalancerと指定します。次の追加オプションを設定します:

    • Scheme: Internet-facingを選択します。
    • IP address type: IPv4を選択します。
    • VPC: ドロップダウンリストからgitlab-vpcを選択します。
    • Mapping: リストから両方のパブリックサブネットを選択し、ロードバランサーが両方のアベイラビリティーゾーンにトラフィックをルーティングできるようにします。

  4. ロードバランサーがファイアウォールとして機能し、通過を許可するトラフィックを制御できるようにするため、セキュリティグループを追加します。Security Group（セキュリティグループ）セクションで、create a new security group（新しいセキュリティグループを作成）を選択し、名前（この例ではgitlab-loadbalancer-sec-group）と説明を入力します。すべての送信元からのHTTPおよびHTTPSトラフィックを許可します（0.0.0.0/0, ::/0）。また、SSHトラフィックを許可し、カスタムソースを選択して、単一の信頼できるIPアドレス、またはCIDR表記のIPアドレス範囲を追加します。これにより、ユーザーはSSH経由でGitアクションを実行できます。

  5. Listeners and routing（リスナーとルーティング）セクションで、次のターゲットグループを考慮して、ポート22、80、443のリスナーをセットアップします。

    プロトコルポートターゲットグループ
    TCP22gitlab-loadbalancer-ssh-target
    TCP80gitlab-loadbalancer-http-target
    TLS443gitlab-loadbalancer-http-target
    1. ポート443のTLSリスナーについて、Security Policy設定で次のように指定します:
      1. ポリシー名: ドロップダウンリストから定義済みのセキュリティポリシーを選択します。ネットワークロードバランサー用の定義済みSSLセキュリティポリシーの詳細については、AWSドキュメントを参照してください。サポートされているSSL暗号およびプロトコルの一覧は、GitLabコードベースで確認できます。
      2. Default SSL/TLS server certificate: ACMからSSL/TLS証明書を選択するか、証明書をIAMにアップロードします。

  6. 作成した各リスナーに対して、ターゲットグループを作成し、前述の表に基づいて割り当てる必要があります。まだEC2インスタンスを作成していないため、ターゲットを登録する必要はありません。EC2インスタンスは、後ほどオートスケールグループのセットアップの一部として作成され、割り当てられます。

    1. Create target groupを選択します。ターゲットタイプにはインスタンスを選択します。
    2. 各リスナーに対して適切なTarget group nameを選択します:
      • gitlab-loadbalancer-http-target - ポート80のTCPプロトコル
      • gitlab-loadbalancer-ssh-target - ポート22のTCPプロトコル
    3. IP address typeにはIPv4を選択します。
    4. VPCドロップダウンリストからgitlab-vpcを選択します。
    5. gitlab-loadbalancer-http-targetのヘルスチェックでは、準備状況チェックエンドポイントを使用する必要があります。ヘルスチェックエンドポイントのIP許可リストに、VPC IPアドレス範囲（CIDR）を追加する必要があります。
    6. gitlab-loadbalancer-ssh-targetのヘルスチェックでは、TCPを選択します。
      • ポート80と443の両方のリスナーにgitlab-loadbalancer-http-targetを割り当てます。
      • ポート22のリスナーにgitlab-loadbalancer-ssh-targetを割り当てます。
    7. 一部の属性は、ターゲットグループの作成後にのみ設定できます。要件に応じて設定できる機能の例を次に示します。

      • Client IP preservationは、ターゲットグループではデフォルトで有効になっています。これにより、ロードバランサーに接続しているクライアントのIPがGitLabアプリケーションで保持されます。要件に応じて、有効/無効を切り替えることができます。

      • Proxy Protocolは、ターゲットグループではデフォルトで無効になっています。これにより、ロードバランサーがプロキシプロトコルヘッダーを使用して追加情報を送信できるようになります。この機能を有効にする場合は、内部ロードバランサーやNGINXなど、他の環境コンポーネントも同様に設定されていることを確認してください。このPOCの場合、後でGitLabノードで有効にするだけで、プロキシプロトコルの設定が完了します。

  7. Create load balancerを選択します。

ロードバランサーが起動して稼働したら、Security Groupsに戻り、NLB経由のアクセスのみに制限するなど、必要に応じてアクセス設定を調整します。

ロードバランサーのDNSを設定する

Route 53ダッシュボードで、左側のナビゲーションバーのHosted zonesを選択します:

  1. 既存のホストゾーンを選択するか、ドメインのホストゾーンがまだない場合は、Create Hosted Zone（ホストゾーンを作成）を選択し、ドメイン名を入力して作成を選択します。
  2. Create recordを選択し、次の値を指定します:
    1. 名前: ドメイン名（デフォルト値）を使用するか、サブドメインを入力します。
    2. 種類: A - IPv4 addressを選択します。
    3. Alias: デフォルトでは無効になっています。このオプションを有効にします。
    4. Route traffic to: Alias to Network Load Balancerを選択します。
    5. リージョン: ネットワークロードバランサーが存在するリージョンを選択します。
    6. Choose network load balancer: 先ほど作成したネットワークロードバランサーを選択します。
    7. Routing Policy: ここではSimpleを使用しますが、ユースケースに応じて別のポリシーを選択することもできます。
    8. Evaluate Target Health: この値はいいえに設定しますが、ターゲットヘルスに基づいてロードバランサーがトラフィックをルーティングするよう設定することもできます。
    9. 作成を選択します。
  3. Route 53を通じてドメインを登録した場合、これで完了です。別のドメインレジストラを使用している場合は、そのドメインレジストラでDNSレコードを更新する必要があります。これを行うには、次の手順に従います:
    1. Hosted zonesを選択し、先ほど追加したドメインを選択します。
    2. NSレコードの一覧が表示されます。ドメインレジストラの管理者パネルから、これらの各NSレコードをドメインのDNSレコードに追加します。この手順は、ドメインレジストラによって異なる場合があります。行き詰まった場合は、“name of your registrar” add DNS records（「レジストラの名前」DNSレコードの追加）をGoogleで検索すると、ドメインレジストラに固有のヘルプ記事が見つかります。

具体的な手順は使用するレジストラによって異なり、このガイドの範囲外です。

PostgreSQLとRDS

データベースサーバーには、冗長性を確保するためにマルチAZを提供するAmazon RDS for PostgreSQLを使用します（Auroraはサポートしていません）。まず、セキュリティグループとサブネットグループを作成し、次に実際のRDSインスタンスを作成します。

RDSセキュリティグループ

データベース用のセキュリティグループを作成し、後でgitlab-loadbalancer-sec-groupにデプロイするインスタンスからの受信トラフィックを許可します:

  1. EC2ダッシュボードで、左側のメニューバーからSecurity Groupsを選択します。
  2. Create security groupを選択します。
  3. 名前（この例ではgitlab-rds-sec-group）と説明を入力し、VPCドロップダウンリストからgitlab-vpcを選択します。
  4. Inbound rulesセクションで、ルールを追加するを選択し、次の項目を設定します:
    1. 種類: PostgreSQLルールを検索して選択します。
    2. Source type: 「Custom」に設定します。
    3. ソース: 先ほど作成したgitlab-loadbalancer-sec-groupを選択します。
  5. 設定が完了したら、Create security groupを選択します。

RDSサブネットグループ

  1. RDSダッシュボードに移動し、左側のメニューからSubnet Groupsを選択します。
  2. Create DB Subnet Groupを選択します。
  3. Subnet group detailsで、名前（この例ではgitlab-rds-group）と説明を入力し、VPCドロップダウンリストからgitlab-vpcを選択します。
  4. Availability Zonesドロップダウンリストから、設定済みのサブネットを含むアベイラビリティーゾーンを選択します。この例では、eu-west-2aとeu-west-2bを追加します。
  5. Subnetsドロップダウンリストから、サブネットセクションで定義した2つのプライベートサブネット（10.0.1.0/24と10.0.3.0/24）を選択します。
  6. 準備ができたら作成を選択します。

データベースを作成する

データベースには、バースト可能インスタンス（tクラスインスタンス）を使用しないでください。高負荷状態が長時間続くとCPUクレジットが枯渇し、パフォーマンスの問題が発生する可能性があります。

それでは、データベースを作成しましょう:

  1. RDSダッシュボードに移動し、左側のメニューからデータベースを選択し、データベースを作成を選択します。

  2. データベースの作成方法ではStandard Createを選択します。

  3. データベースエンジンとしてPostgreSQLを選択し、GitLabバージョンのデータベース要件で定義されている最小PostgreSQLバージョンを選択します。

  4. これは本番環境サーバーであるため、テンプレートセクションでProductionを選択します。

  5. Availability & durabilityで、Multi-AZ DB instanceを選択し、別のアベイラビリティーゾーンにスタンバイRDSインスタンスをプロビジョニングします。

  6. 設定で、次の値を使用します:

    • DB instance identifier: gitlab-db-ha。
    • master username: gitlab。
    • master password: 非常に安全なパスワード。

    これらの情報は後で必要になるため、メモしておきます。

  7. DB instance sizeにはStandard classes（標準クラス）を選択し、要件を満たすインスタンスサイズをドロップダウンリストから選択します。ここではdb.m5.largeインスタンスを使用します。

  8. ストレージで、次の項目を設定します:

    1. ストレージタイプのドロップダウンリストから**Provisioned IOPS (SSD)**を選択します。Provisioned IOPS（SSD）ストレージは、この用途に最適です（ただし、コスト削減のためにGeneral Purpose（SSD）を選択することもできます）。詳細については、Amazon RDSのストレージを参照してください。
    2. ストレージを割り当て、プロビジョニングされたIOPSを設定します。ここでは、最小値である100と1000を使用します。
    3. ストレージのオートスケールを有効にし（オプション）、ストレージの最大しきい値を設定します。

  9. Connectivityで、次の項目を設定します:

    1. **Virtual Private Cloud (VPC)**ドロップダウンリストで、先ほど作成したVPC（gitlab-vpc）を選択します。
    2. DB subnet groupで、先ほど作成したサブネットグループ（gitlab-rds-group）を選択します。
    3. パブリックアクセスをいいえに設定します。
    4. VPC security groupで、Choose existingを選択し、ドロップダウンリストから先ほど作成したgitlab-rds-sec-groupを選択します。
    5. 追加の設定で、データベースポートをデフォルトの5432のままにします。

  10. Database authenticationで、Password authenticationを選択します。

  11. 追加の設定セクションを展開し、次の項目を設定します:

    1. 初期データベース名（この例ではgitlabhq_production）。
    2. 必要に応じてバックアップを設定します。
    3. 最後に、Maintenanceでマイナーバージョンの自動更新を無効にします。
    4. その他すべての設定はそのままにするか、必要に応じて微調整します。
    5. 問題がなければ、データベースを作成を選択します。

これで、データベースが作成されました。次に、ElastiCacheを使用してRedisをセットアップします。

ElastiCacheを使用したRedis

ElastiCacheは、ホストされるインメモリキャッシュ型のソリューションです。Redisは独自の永続性を保持し、GitLabアプリケーションのセッションデータ、一時的なキャッシュ情報、バックグラウンドジョブキューの保存に使用されます。

Redisセキュリティグループを作成する

  1. EC2ダッシュボードに移動します。
  2. 左側のメニューからSecurity Groupsを選択します。
  3. Create security groupを選択し、詳細を入力します。名前（この例ではgitlab-redis-sec-group）を付けて説明を追加し、先ほど作成したVPC（gitlab-vpc）を選択します。
  4. Inbound rulesセクションで、ルールを追加するを選択し、Custom TCPルールを追加します。ポート6379を設定し、「Custom」ソースに先ほど作成したgitlab-loadbalancer-sec-groupを指定します。
  5. 設定が完了したら、Create security groupを選択します。

Redisサブネットグループ

  1. AWSコンソールからElastiCacheダッシュボードに移動します。

  2. 左側のメニューのSubnet Groupsに移動し、新しいサブネットグループを作成します（この例ではgitlab-redis-groupという名前を付けます）。先ほど作成したVPC（gitlab-vpc）を選択し、Selected subnetsテーブルにプライベートサブネットのみが含まれていることを確認します。

  3. 準備ができたら作成を選択します。

    GitLab Redisグループのサブネットグループを作成します。

Redisクラスターを作成する

  1. ElastiCacheダッシュボードに戻ります。

  2. 左側のメニューでRedis cachesを選択し、Create Redis cacheを選択して、新しいRedisクラスターを作成します。

  3. Deployment optionで、Design your own cacheを選択します。

  4. Creation methodで、Cluster cacheを選択します。

  5. Cluster modeはサポートされていないため、無効を選択します。クラスターモードを無効にしても、複数のアベイラビリティーゾーンにRedisをデプロイすることは可能です。

  6. Cluster infoで、クラスター名（gitlab-redis）と説明を入力します。

  7. ロケーションで、AWS Cloudを選択し、Multi-AZオプションを有効にします。

  8. Cluster settingsセクション:

    1. Engine versionでは、Redis要件に記載されている、ご利用のGitLabバージョンに対応するRedisバージョンを選択します。
    2. ポートは6379のままにします。これは先ほどRedisセキュリティグループで使用した値です。
    3. ノードタイプ（少なくともcache.t3.medium、必要に応じて調整）とレプリカの数を選択します。

  9. Connectivity settingsセクション:

    1. Network type: IPv4
    2. Subnet groups: Choose existing subnet groupを選択し、先ほど作成したgitlab-redis-groupを選択します。

  10. Availability Zone placementsセクション:

    1. 優先するアベイラビリティーゾーンを手動で選択し、「Replica 2」で他の2つとは異なるゾーンを選択します。

      Redisグループに使用するアベイラビリティーゾーンを選択します。

  11. 次へを選択します。

  12. セキュリティ設定で、セキュリティグループを編集し、先ほど作成したgitlab-redis-sec-groupを選択します。次へを選択します。

  13. 残りの設定はデフォルト値のままにするか、必要に応じて編集します。

  14. 完了したら作成を選択します。

踏み台ホストを設定する

GitLabインスタンスはプライベートサブネット内にあるため、設定変更やアップグレードなどを行う際に、SSHを使用してこれらのインスタンスに接続する方法が必要です。その手段の1つが、踏み台ホストを使用することです。ジャンプボックスとも呼ばれます。

踏み台ホストを管理したくない場合は、インスタンスへのアクセスにAWS Systems ManagerのSession Managerを使用するよう設定できます。この設定は、このドキュメントの範囲外です。

踏み台ホストAを作成する

  1. EC2ダッシュボードに移動し、Launch instanceを選択します。
  2. Name and tagsセクションで、名前にBastion Host Aと指定します。
  3. 最新のUbuntu Server LTS (HVM) AMIを選択します。サポート対象の最新のOSバージョンについては、GitLabドキュメントを確認してください。
  4. インスタンスタイプを選択します。ここでは、踏み台ホストを使用して他のインスタンスにSSHで接続するだけなので、t2.microを使用します。
  5. Key pairセクションで、Create new key pairを選択します。
    1. キーペアに名前（この例ではbastion-host-a）を付け、後で使用するためにbastion-host-a.pemファイルを保存します。
  6. Network settingsセクションを編集します:
    1. VPCで、ドロップダウンリストからgitlab-vpcを選択します。
    2. Subnetで、先ほど作成したパブリックサブネット（gitlab-public-10.0.0.0）を選択します。
    3. Auto-assign Public IPで、無効が選択されていることを確認します。Elastic IPアドレスは、次のセクションでホストに割り当てます。
    4. Firewallで、Create security groupを選択し、Security group name（この例ではbastion-sec-group）を入力し、説明を追加します。
    5. すべての送信元からのSSHアクセスを有効にします（0.0.0.0/0）。より厳密なセキュリティを適用する必要がある場合は、単一のIPアドレスまたはCIDR表記のIPアドレス範囲を指定します。
  7. ストレージについては、すべてをデフォルトのままにし、8 GBのルートボリュームのみを追加します。このインスタンスには何も保存しません。
  8. すべての設定を確認し、問題がなければ、Launch Instance（インスタンスを起動）を選択します。

踏み台ホストAにElastic IPを割り当てる

  1. EC2ダッシュボードに移動し、Network & Securityを選択します。
  2. Elastic IPsを選択し、Network border groupをus-west-2に設定します。
  3. Allocateを選択します。
  4. 作成されたElastic IPアドレスを選択します。
  5. アクション、Associate Elastic IP addressの順に選択します。
  6. Resource Typeでインスタンスを選択し、インスタンスドロップダウンリストからBastion Host Aホストを選択します。
  7. Associateを選択します。

インスタンスにSSHで接続できることを確認する

  1. EC2ダッシュボードで、左側のメニューからインスタンスを選択します。
  2. インスタンスの一覧からBastion Host Aを選択します。
  3. 接続を選択し、表示される接続手順に従います。
  4. 正常に接続できたら、冗長性を確保するために2つ目の踏み台ホストの設定に進みます。

踏み台ホストBを作成する

  1. 先ほどと同じ手順に従ってEC2インスタンスを作成しますが、次の点を変更します:
    1. Subnetには、先ほど作成した2つ目のパブリックサブネット（gitlab-public-10.0.2.0）を選択します。
    2. Add Tagsセクションでは、2つのインスタンスを区別しやすくするため、Key: NameとValue: Bastion Host Bを設定します。
    3. セキュリティグループには、先ほど作成した既存のbastion-sec-groupを選択します。

SSHエージェント転送を使用する

Linuxを実行するEC2インスタンスでは、SSH認証に秘密キーファイルを使用します。SSHクライアントを使用し、クライアントに保存されている秘密キーファイルで踏み台ホストに接続します。踏み台ホストには秘密キーファイルが存在しないため、プライベートサブネット内のインスタンスには接続できません。

踏み台ホストに秘密キーファイルを保存するのは不適切です。この問題を回避するには、クライアントでSSHエージェント転送を使用します。

たとえば、コマンドラインのsshクライアントは、次のような-Aスイッチでエージェント転送を使用します:

ssh -A user@<bastion-public-IP-address>

他のクライアントでSSHエージェント転送を使用する手順については、Securely Connect to Linux Instances Running in a Private Amazon VPCを参照してください。

GitLabをインストールしてカスタムAMIを作成する

後で起動設定に使用するため、設定済みのカスタムGitLab AMIが必要です。まず公式のGitLab AMIを使用してGitLabインスタンスを作成します。次に、PostgreSQL、Redis、Gitaly向けのカスタム設定を追加します。必要に応じて、公式のGitLab AMIを使用せず、独自に選択したEC2インスタンスを起動し、GitLabを手動でインストールすることもできます。

GitLabをインストールする

EC2ダッシュボードで、次の手順に従います:

  1. 後述の「AWS上でGitLabが提供する公式AMI IDを見つける」セクションを参照して、正しいAMIを特定し、Launchを選択します。
  2. Name and tagsセクションで、名前にGitLabと指定します。
  3. Instance typeドロップダウンリストで、ワークロードに応じてインスタンスタイプを選択します。ハードウェア要件を参照し、ニーズに合ったタイプを選択します（少なくともc5.2xlarge。これは100人のユーザーに十分対応できます）。
  4. Key pairセクションで、Create new key pairを選択します。
    1. キーペアに名前（この例ではgitlab）を付け、後で使用するためにgitlab.pemファイルを保存します。
  5. Network settingsセクション:
    1. VPC: 先ほど作成したgitlab-vpcを選択します。
    2. Subnet: 先ほど作成したサブネットの一覧からgitlab-private-10.0.1.0を選択します。
    3. Auto-assign Public IP: Disableを選択します。
    4. Firewall: Select existing security groupを選択し、先ほど作成したgitlab-loadbalancer-sec-groupを選択します。
  6. ストレージについては、ルートボリュームはデフォルトで8 GiBに設定されています。ここにはデータを保存しないため、この容量で十分です。
  7. すべての設定を確認し、問題がなければ、Launch Instance（インスタンスを起動）を選択します。

カスタム設定を追加する

SSHエージェント転送を使用し、Bastion Host A（踏み台ホストA）経由でGitLabインスタンスに接続します。接続したら、次のカスタム設定を追加します:

Let’s Encryptを無効にする

ロードバランサーでSSL証明書を追加するため、GitLabに組み込まれているLet’s Encryptのサポートは必要ありません。httpsドメインを使用する場合、Let’s Encryptはデフォルトで有効になっているため、明示的に無効にする必要があります:

  1. /etc/gitlab/gitlab.rbを開き、無効にします:

    letsencrypt['enable'] = false

  2. ファイルを保存し、変更を有効にするために再設定します:

    sudo gitlab-ctl reconfigure

PostgreSQLに必要な拡張機能をインストールする

GitLabインスタンスからRDSインスタンスに接続し、アクセスを確認して、必要な拡張機能pg_trgmおよびbtree_gistをインストールします。

ホストまたはエンドポイントを見つけるには、Amazon RDS > データベースに移動し、先ほど作成したデータベースを選択します。Connectivity & securityタブでエンドポイントを探します。

コロンとポート番号は含めないでください:

sudo /opt/gitlab/embedded/bin/psql -U gitlab -h <rds-endpoint> -d gitlabhq_production

psqlプロンプトで拡張機能を作成します。完了したらセッションを終了します:

psql (10.9)
Type "help" for help.

gitlab=# CREATE EXTENSION pg_trgm;
gitlab=# CREATE EXTENSION btree_gist;
gitlab=# \q

PostgreSQLとRedisに接続するようにGitLabを設定する

  1. /etc/gitlab/gitlab.rbを編集し、external_url 'http://<domain>'オプションを見つけて、使用しているhttpsドメインに変更します。

  2. GitLabデータベース設定を探して、必要に応じてコメントアウトを解除します。今回のケースでは、データベースアダプター、エンコード、ホスト、データベース名、ユーザー名、パスワードを指定します:

    # Disable the built-in Postgres
 postgresql['enable'] = false

# Fill in the connection details
gitlab_rails['db_adapter'] = "postgresql"
gitlab_rails['db_encoding'] = "unicode"
gitlab_rails['db_database'] = "gitlabhq_production"
gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "mypassword"
gitlab_rails['db_host'] = "<rds-endpoint>"

  3. 次に、Redisセクションを設定し、ホストを追加してポートのコメントアウトを解除する必要があります:

    # Disable the built-in Redis
redis['enable'] = false

# Fill in the connection details
gitlab_rails['redis_host'] = "<redis-endpoint>"
gitlab_rails['redis_port'] = 6379

  4. 最後に、変更を有効にするためにGitLabを再設定します:

    sudo gitlab-ctl reconfigure

  5. チェックとサービスステータスを実行して、すべてが正しく設定されていることを確認することもできます:

    sudo gitlab-rake gitlab:check
sudo gitlab-ctl status

Gitalyを設定する

このアーキテクチャでは、Gitalyサーバーが1台しかない場合、単一障害点となります。この制限を解消するには、Gitaly Cluster (Praefect)を使用します。

Gitalyは、Gitリポジトリへの高レベルのRPCアクセスを提供するサービスです。以前に設定したプライベートサブネットのいずれかに配置した個別のEC2インスタンス上で、Gitalyを有効にして設定する必要があります。

GitalyをインストールするEC2インスタンスを作成します:

  1. EC2ダッシュボードでLaunch instanceを選択します。
  2. Name and tagsセクションで、名前にGitalyと指定します。
  3. AMIを選択します。この例では、最新のUbuntu Server LTS (HVM), SSD Volume Typeを選択します。サポート対象の最新のOSバージョンについては、GitLabドキュメントを確認してください。
  4. インスタンスタイプを選択します。m5.xlargeを選択します。
  5. Key pairセクションで、Create new key pairを選択します。
    1. キーペアに名前（この例ではgitaly）を付け、後で使用するためにgitaly.pemファイルを保存します。
  6. Network settingsセクション:
    1. VPCで、ドロップダウンリストからgitlab-vpcを選択します。
    2. Subnetで、先ほど作成したプライベートサブネット（gitlab-private-10.0.1.0）を選択します。
    3. Auto-assign Public IPで、無効が選択されていることを確認します。
    4. Firewallで、Create security groupを選択し、Security group name（この例ではgitlab-gitaly-sec-group）を入力し、説明を追加します。
      1. Custom TCPルールを作成し、ポート8075をPort Rangeに追加します。ソースにはgitlab-loadbalancer-sec-groupを選択します。
      2. さらに、踏み台ホストからSSHエージェント転送を使用して接続できるように、bastion-sec-groupからのSSH接続を許可するインバウンドルールを追加します。
  7. Root volume sizeを20 GiBに増やし、Volume TypeをProvisioned IOPS SSD (io1)に変更します。（ボリュームサイズには任意の値を設定できます。リポジトリストレージ要件を満たす十分な容量を確保してください。）
    1. IOPSには1000（20 GiB x 50 IOPS）を設定します。1 GiBあたり最大50 IOPSまでプロビジョニングできます。より大きなボリュームを選択する場合は、それに応じてIOPSを増やします。gitのように、多数の小さなファイルを直列的に書き込むワークロードでは、高性能ストレージが必要となるため、Provisioned IOPS SSD (io1)を選択します。
  8. すべての設定を確認し、問題がなければ、Launch Instance（インスタンスを起動）を選択します。

設定やリポジトリデータをルートボリュームに保存する代わりに、リポジトリストレージとして追加のEBSボリュームを割り当てることもできます。前述のガイダンスと同様の手順に従ってください。Amazon EBSの料金ページを参照してください。

EC2インスタンスの準備が整ったので、ドキュメントに従ってGitLabをインストールし、Gitalyを専用サーバー上にセットアップします。先ほど作成したGitLabインスタンスで、前述のドキュメントに記載されたクライアント側のセットアップ手順を実行します。

Elastic File System（EFS）

GitLabのパフォーマンスに悪影響を与える可能性があるため、EFSの使用は推奨されません。詳細については、クラウドベースのファイルシステムの回避に関するドキュメントを参照してください。

それでもEFSを使用する場合は、PosixUser属性を省略するか、Gitalyがインストールされているシステム上のgitユーザーの固有識別子（UID）とグループID（GID）を正しく指定してください。UIDとGIDは、次のコマンドで取得できます:

# UID
$ id -u git

# GID
$ id -g git

また、複数のアクセスポイントを設定しないでください。特に、異なる認証情報を指定している場合は避ける必要があります。Gitaly以外のアプリケーションが、Gitalyストレージディレクトリに対する権限を操作し、Gitalyが正常に動作しなくなるおそれがあります。この問題の具体例については、omnibus-gitlabイシュー8893を参照してください。

プロキシ経由のSSLのサポートを追加する

ロードバランサーでSSLを終端しているため、/etc/gitlab/gitlab.rbでこの設定を行うには、プロキシ経由のSSLをサポートする手順に従います。

gitlab.rbファイルへの変更を保存した後、必ずsudo gitlab-ctl reconfigureを実行してください。

承認されたSSHキーの高速検索

GitLabへのアクセスを許可されたユーザーの公開SSHキーは、/var/opt/gitlab/.ssh/authorized_keysに保存されています。通常は共有ストレージを使用し、ユーザーがSSH経由でGitアクションを実行する際に、すべてのインスタンスがこのファイルにアクセスできるようにします。しかし、今回のセットアップでは共有ストレージを使用していないため、GitLabデータベース内のインデックス検索を使用してSSHユーザーを認証するように設定を更新します。

SSHキーの高速検索の設定手順に従って、authorized_keysファイルの使用からデータベースに切り替えてください。

高速検索を設定しない場合、SSH経由でGitアクションを実行すると次のエラーが返されます:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

ホストキーを設定する

通常は、プライマリアプリケーションサーバー上の/etc/ssh/の内容（プライマリキーと公開キー）を、すべてのセカンダリサーバー上の/etc/sshに手動でコピーします。これにより、ロードバランサーの背後にあるクラスター内のサーバーにアクセスする際に、誤った中間者攻撃のアラートが発生するのを防ぐことができます。

カスタムAMIの一部として静的ホストキーを作成することで、この手順を自動化します。また、これらのホストキーはEC2インスタンスが起動するたびにローテーションされるため、カスタムAMIに「ハードコード」することで、この問題を回避できます。

GitLabインスタンスで、次のコマンドを実行します:

sudo mkdir /etc/ssh_static
sudo cp -R /etc/ssh/* /etc/ssh_static

/etc/ssh/sshd_configで、次の内容を更新します:

# HostKeys for protocol version 2
HostKey /etc/ssh_static/ssh_host_rsa_key
HostKey /etc/ssh_static/ssh_host_dsa_key
HostKey /etc/ssh_static/ssh_host_ecdsa_key
HostKey /etc/ssh_static/ssh_host_ed25519_key

Amazon S3オブジェクトストレージ

共有ストレージとしてNFSを使用していないため、バックアップ、アーティファクト、LFSオブジェクト、アップロード、マージリクエストの差分、コンテナレジストリのイメージなどを保存するためにAmazon S3バケットを使用します。GitLabのドキュメントには、これらの各データタイプに対してオブジェクトストレージを設定する方法や、GitLabでオブジェクトストレージを使用する際の詳細情報が記載されています。

先ほど作成したAWS IAMプロファイルを使用しているため、オブジェクトストレージを設定する際はAWSアクセスキーとシークレットアクセスキーのキー/値のペアを指定しないでください。代わりに、先ほどリンクを紹介したオブジェクトストレージに関するドキュメントに記載されているとおり、設定で'use_iam_profile' => trueを使用します。

gitlab.rbファイルへの変更を保存した後、必ずsudo gitlab-ctl reconfigureを実行してください。

これで、GitLabインスタンスの設定変更は完了です。次に、このインスタンスを基にカスタムAMIを作成し、起動設定とオートスケールグループに使用します。

IP許可リスト

先ほど作成したgitlab-vpcのVPC IPアドレス範囲（CIDR）を、ヘルスチェックエンドポイントのIP許可リストに追加する必要があります。

  1. /etc/gitlab/gitlab.rbを編集します:

    gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '10.0.0.0/16']

  2. GitLabを再設定します:

    sudo gitlab-ctl reconfigure

プロキシプロトコル

先ほど作成したロードバランサーでプロキシプロトコルが有効になっている場合は、gitlab.rbファイルでもこれを有効にする必要があります。

  1. /etc/gitlab/gitlab.rbを編集します:

    nginx['proxy_protocol'] = true
nginx['real_ip_trusted_addresses'] = [ "127.0.0.0/8", "IP_OF_THE_PROXY/32"]

  2. GitLabを再設定します:

    sudo gitlab-ctl reconfigure

初めてサインインする

ロードバランサーのDNSを設定したときに使用したドメイン名を使用すると、ブラウザでGitLabにアクセスできるようになります。

GitLabのインストール方法や、他の手段でパスワードを変更したかどうかに応じて、デフォルトのパスワードは次のいずれかになります:

  • 公式のGitLab AMIを使用した場合は、インスタンスID。
  • /etc/gitlab/initial_root_passwordに24時間保存されるランダム生成パスワード。

デフォルトのパスワードを変更するには、rootユーザーとしてデフォルトのパスワードでサインインし、ユーザープロファイルで変更します。

オートスケールグループが新しいインスタンスを起動すると、ユーザー名rootと新しく作成されたパスワードでサインインできます。

カスタムAMIを作成する

EC2ダッシュボードで、次の手順に従います:

  1. 先ほど作成したGitLabインスタンスを選択します。
  2. アクションを選択し、Image and templatesまでスクロールダウンしてCreate imageを選択します。
  3. イメージの名前と説明を入力します（この例ではどちらにもGitLab-Sourceを使用します）。
  4. それ以外の設定はすべてデフォルトのままにして、Create Imageを選択します。

これで、次のステップで起動設定を作成するために使用するカスタムAMIが作成されました。

オートスケールグループ内にGitLabをデプロイする

起動テンプレートを作成する

EC2ダッシュボードで、次の手順に従います:

  1. 左側のメニューからLaunch Templatesを選択し、create launch templateを選択します。
  2. 起動テンプレートの名前を入力します（この例ではgitlab-launch-template）。
  3. Launch template contentsを選択し、My AMIsタブを選択します。
  4. 自分が所有を選択し、先ほど作成したカスタムAMIであるGitLab-Sourceを選択します。
  5. ニーズに最適なインスタンスタイプを選択します（少なくともc5.2xlarge）。
  6. Key pairセクションで、Create new key pairを選択します。
    1. キーペアに名前（この例ではgitlab-launch-template）を付け、後で使用するためにgitlab-launch-template.pemファイルを保存します。
  7. ルートボリュームはデフォルトで8 GiBに設定されています。ここにはデータを保存しないため、この容量で十分です。Configure Security Groupを選択します。
  8. Select and existing security groupチェックボックスをオンにして、先ほど作成したgitlab-loadbalancer-sec-groupを選択します。
  9. Network settingsセクション:
    1. Firewall: Select existing security groupを選択し、先ほど作成したgitlab-loadbalancer-sec-groupを選択します。
  10. Advanced detailsセクション:
    1. IAM instance profile: 先ほど作成したGitLabS3Accessロールを選択します。
  11. すべての設定を確認し、問題がなければCreate launch templateを選択します。

オートスケールグループを作成する

EC2ダッシュボードで、次の手順に従います:

  1. 左側のメニューからAuto scaling groupsを選択し、Create Auto Scaling groupを選択します。

  2. グループ名を入力します（この例ではgitlab-auto-scaling-group）。

  3. Launch templateで、先ほど作成した起動テンプレートを選択します。次へを選択します。

  4. Network settingsセクション:

    1. VPCで、ドロップダウンリストからgitlab-vpcを選択します。
    2. Availability Zones and subnetsで、先ほど作成したプライベートサブネット（gitlab-private-10.0.1.0とgitlab-private-10.0.3.0）を選択します。
    3. 次へを選択します。

  5. Load Balancing settingsセクション:

    1. Attach to an existing load balancerを選択します。
    2. Existing load balancer target groupsドロップダウンリストで、先ほど作成したターゲットグループを選択します。
    3. Health Check Typeで、Turn on Elastic Load Balancing health checksオプションをオンにします。Health Check Grace Periodは、デフォルトの300秒のままにします。
    4. 次へを選択します。

  6. Group sizeで、Desired capacityを2に設定します。

  7. Scaling settingsセクションで、次の手順に従います:

    1. No scaling policiesを選択します。ポリシーは後で設定します。
    2. Min desired capacity: 2に設定します。
    3. Max desired capacity: 4に設定します。
    4. 次へを選択します。

  8. 最後に、必要に応じて通知とタグを設定し、変更内容を確認してから、オートスケールグループを作成します。

  9. オートスケールグループを作成したら、CloudWatchでスケールアップおよびスケールダウンポリシーを作成し、それらを割り当てる必要があります。

    1. 先ほど作成したBy Auto Scaling Group（オートスケールグループ）のEC2インスタンスから取得したメトリクスに対して、CPUUtilizationのアラームを作成します。
    2. 次の条件を使用してスケールアップポリシーを作成します:
      1. CPUUtilizationが60%以上の場合は、キャパシティユニットを1追加します。
      2. Scaling policy nameをScale Up Policyに設定します。

    スケールアップポリシーを設定します。

    1. 次の条件を使用してスケールダウンポリシーを作成します:
      1. CPUUtilizationが45%以下の場合は、キャパシティユニットを1削除します。
      2. Scaling policy nameをScale Down Policyに設定します。

    スケールダウンポリシーを設定します。

    1. 先ほど作成したオートスケールグループに、新しい動的スケーリングポリシーを割り当てます。

オートスケールグループが作成されると、EC2ダッシュボード上で新しいインスタンスが起動していることを確認できます。また、ロードバランサーに新しいインスタンスが追加されていることも確認できます。インスタンスがヘルスチェックに合格すると、ロードバランサーからトラフィックを受信する準備が整います。

インスタンスはオートスケールグループによって作成されるため、インスタンスに戻り、先ほど手動で作成したインスタンスを終了します。このインスタンスは、カスタムAMIを作成する目的にのみ使用しました。

Prometheusによるヘルスチェックとモニタリング

さまざまなサービスで有効化できるAmazon CloudWatchとは別に、GitLabはPrometheusに基づく独自の統合モニタリングソリューションを提供しています。設定方法の詳細については、GitLab Prometheusを参照してください。

GitLabにはさまざまなヘルスチェックエンドポイントが用意されており、pingしてレポートを取得できます。

GitLab Runner

GitLab CI/CDを活用するには、少なくとも1つのRunnerを設定する必要があります。

AWS上でオートスケール対応のGitLab Runnerを設定する方法については、リンク先を参照してください。

バックアップと復元

GitLabには、Gitデータ、データベース、添付ファイル、LFSオブジェクトなどをバックアップおよび復元するためのツールが用意されています。

知っておくべき重要な点:

GitLabをバックアップする

GitLabをバックアップするには、次の手順に従います:

  1. インスタンスにSSHで接続します。

  2. バックアップを作成します:

    sudo gitlab-backup create

バックアップからGitLabを復元する

GitLabを復元するには、まず復元に関するドキュメント、特に復元の前提要件を確認してください。次に、Linuxパッケージインストールセクションに記載された手順に従います。

GitLabを更新する

GitLabでは、毎月リリース日に新しいバージョンをリリースしています。新しいバージョンがリリースされたら、GitLabインスタンスを更新できます:

  1. インスタンスにSSHで接続します。

  2. バックアップを作成します:

    sudo gitlab-backup create

  3. リポジトリを更新し、GitLabをインストールします:

    sudo apt update
sudo apt install gitlab-ee

数分後には、新しいバージョンが起動して稼働を開始します。

AWS上でGitLabが提供する公式AMI IDを見つける

GitLabがリリースしているAMIの使用方法については、リンク先をご覧ください。

まとめ

このガイドでは、主にスケーリングといくつかの冗長化オプションについて説明しましたが、必要な作業内容は環境によって異なります。

すべてのソリューションは、コストと複雑さ、そしてアップタイムの間でバランスを取る必要があります。必要とするアップタイムが長くなるほど、ソリューションは複雑になります。そしてソリューションが複雑になるほど、セットアップやメンテナンスに必要な作業も増えます。

以下のその他のリソースもぜひご覧ください。追加の資料をご希望の場合は、イシューを開いてリクエストしてください:

  • GitLabのスケーリング: GitLabはさまざまなクラスタリングをサポートしています。
  • Geoレプリケーション: Geoは、広範な地域に分散した開発チーム向けのソリューションです。
  • Linuxパッケージ: GitLabインスタンスの管理について知っておくべきすべての情報が掲載されています。
  • ライセンスの追加: ライセンスを適用すると、GitLab Enterprise Editionのすべての機能を有効にできます。
  • 価格: 各プランの価格をご確認ください。

トラブルシューティング

インスタンスがヘルスチェックに失敗する

インスタンスがロードバランサーのヘルスチェックに失敗する場合は、以前に設定したヘルスチェックエンドポイントからステータス200が返されていることを確認してください。ステータス302などのリダイレクトを含む、その他のステータスが返されるとヘルスチェックは失敗します。

ヘルスチェックに合格するために、rootユーザーにパスワードを設定し、サインインエンドポイントでの自動リダイレクトを防ぐ必要がある場合があります。

メッセージ：The change you requested was rejected (422)

Webインターフェースでパスワードを設定しようとした際にこのページが表示される場合は、gitlab.rb内のexternal_urlがリクエスト元のドメインと一致していることを確認してください。ファイルに変更を加えた場合は、sudo gitlab-ctl reconfigureを実行します。

一部のジョブログがオブジェクトストレージにアップロードされない

GitLabデプロイを複数のノードにスケールアップすると、一部のジョブログがオブジェクトストレージに正常にアップロードされない場合があります。CIでオブジェクトストレージを使用するには、増分ログが必要です。

まだ有効にしていない場合は、増分ログを有効にします。