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

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

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

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

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

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

Infrastructure as CodeツールであるGitLab Environment Tool（GET）は、AWS上でLinuxパッケージを使用して構築する際の出発点として最適です。とりわけ、HA構成を目標とする場合に有用です。GETはすべてを自動化するわけではありませんが、Gitaly Cluster (Praefect)のような複雑なセットアップを自動構成します。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の基本的な知識に加えて、次のものが必要です。

• AWSアカウント
• SSHキーを作成またはアップロードして、SSH経由でインスタンスに接続していること。
• GitLabインスタンスのドメイン名。
• ドメインを保護するSSL/TLS証明書。まだお持ちでない場合は、AWS Certificate Manager（ACM）を使用して無料のパブリックSSL/TLS証明書をプロビジョニングし、このガイドで作成するElastic Load Balancerで使用できます。

アーキテクチャ

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

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ダッシュボードに移動し、左側のメニューでPoliciesを選択します。

2. Create policyを選択し、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. Nextを選択して、ポリシーを確認します。ポリシーに名前を付け（この例ではgl-s3-policy）、Create policyを選択します。

IAMロールを作成する

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

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

ネットワークを設定する

まず、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を選択します。

   

3. VPCを選択し、Actions、Edit VPC Settingsの順に選択し、Enable DNS resolutionをオンにします。完了したら、Saveを選択します。

サブネット

ここでは、さまざまなアベイラビリティーゾーンにサブネットをいくつか作成します。各サブネットが、先ほど作成した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.0	public	us-west-2a	10.0.0.0/24
   gitlab-private-10.0.1.0	private	us-west-2a	10.0.1.0/24
   gitlab-public-10.0.2.0	public	us-west-2b	10.0.2.0/24
   gitlab-private-10.0.3.0	private	us-west-2b	10.0.3.0/24

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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アプリケーションサーバー全体に受信トラフィックを均等に分散します。後ほど作成するスケーリングポリシーに基づいて、必要に応じてインスタンスがロードバランサーに追加または削除されます。さらに、ロードバランサーはインスタンスに対してヘルスチェックを実行します。

AWSはこのアーキテクチャに2つのアプローチを提供します:

• Network Load Balancer (NLB) only: 小規模なデプロイに適した、よりシンプルなセットアップです。NLBは、すべてのトラフィック (SSH (ポート22)、HTTP (ポート80)、HTTPS (ポート443))をRailsノードに直接処理し、NLBでSSL/TLS終端を行います。
• Hybrid NLB->ALB approach: 懸念事項を分離する、よりスケーラブルなセットアップです。NLBはTCPトラフィック (SSH (ポート22))を処理し、Application Load Balancer (ALB)はSSL/TLS終端を伴うHTTP/HTTPSトラフィックを処理します。このアプローチにより、AWS WAFインテグレーションと、より優れたトラフィック管理が可能になります。

あなたのデプロイに最適なアプローチを選択してください:

• NLBのみ:

  graph TB
      subgraph Diagram1["NLB Only"]
        U1["Users"]
        NLB1["Network Load Balancer<br/>(Port 22, 80, 443)"]
        R1A["Rails Node 1<br/>(Port 22, 80)"]
        R1B["Rails Node 2<br/>(Port 22, 80)"]
  
        U1 -->|SSH| NLB1
        U1 -->|HTTP| NLB1
        U1 -->|HTTPS| NLB1
        NLB1 -->|Port 22| R1A
        NLB1 -->|Port 22| R1B
        NLB1 -->|"Port 80, 443"| R1A
        NLB1 -->|"Port 80, 443"| R1B
    end
  

• ハイブリッドNLB/ALB:

  graph TB
      subgraph Diagram2["Hybrid NLB/ALB"]
          U2["Users"]
          NLB2["Network Load Balancer<br/>(Port 22, 443)"]
          ALB["Application Load Balancer<br/>(Port 443)"]
          R2A["Rails Node 1<br/>(Port 22, 80)"]
          R2B["Rails Node 2<br/>(Port 22, 80)"]
  
          U2 -->|SSH| NLB2
          U2 -->|HTTPS| NLB2
          NLB2 -->|Port 22| R2A
          NLB2 -->|Port 22| R2B
          NLB2 -->|Port 443| ALB
          ALB -->|Port 80| R2A
          ALB -->|Port 80| R2B
      end
  

NLBロードバランサーが稼働したら、Security Groupsを再確認して、NLBを介したアクセスのみに制限し、その他の要件を設定できます。

一部の属性は、ロードバランサーが作成された後にのみ設定できます。以下は、要件に基づいて設定できるいくつかの機能です:

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

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

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

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

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

PostgreSQLとRDS

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

RDSセキュリティグループ

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

1. EC2ダッシュボードで、左側のメニューバーからSecurity Groupsを選択します。
2. Create security groupを選択します。
3. 名前（この例ではgitlab-rds-sec-group）と説明を入力し、VPCドロップダウンリストからgitlab-vpcを選択します。
4. Inbound rulesセクションで、Add ruleを選択し、次の項目を設定します。
   1. Type: PostgreSQLルールを検索して選択します。
   2. Source type: 「Custom」に設定します。
   3. ソース: ロードバランサーのアプローチに基づいて適切なセキュリティグループを選択します:
      • NLB only: gitlab-nlb-sec-group
      • Hybrid NLB->ALB: gitlab-rails-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ドロップダウンリストから、設定済みのサブネットを含むアベイラビリティーゾーンを選択します。この例では、us-west-2aとus-west-2bを追加します。
5. Subnetsドロップダウンリストから、サブネットセクションで定義した2つのプライベートサブネット（10.0.1.0/24と10.0.3.0/24）を選択します。
6. 準備ができたらCreateを選択します。

データベースを作成する

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

1. RDSダッシュボードに移動し、左側のメニューからDatabasesを選択し、Create databaseを選択します。

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

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

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

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

6. Settings（設定）で、次の値を使用します。

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

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

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

8. Storageで、次の項目を設定します。

   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. パブリックアクセスをNoに設定します。
   4. VPC security groupで、Choose existingを選択し、ドロップダウンリストから先ほど作成したgitlab-rds-sec-groupを選択します。
   5. Additional configurationで、データベースポートをデフォルトの5432のままにします。

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

11. Additional configurationセクションを展開し、次の項目を設定します。

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

これで、データベースが作成されました。次に、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" ソースを設定します:
   • NLB only: gitlab-nlb-sec-group
   • Hybrid NLB->ALB: gitlab-rails-sec-group
5. 設定が完了したら、Create security groupを選択します。

Redisサブネットグループ

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

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

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

   

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

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

7. Locationで、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つとは異なるゾーンを選択します。

       

11. Nextを選択します。

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

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

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

踏み台ホストを設定する

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

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

1. EC2ダッシュボードに移動し、Launch instanceを選択します。
2. Name and tagsセクションで、Nameに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で、Disabledが選択されていることを確認します。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. Actions、Associate Elastic IP addressの順に選択します。
6. Resource TypeでInstanceを選択し、InstanceドロップダウンリストからBastion Host Aホストを選択します。
7. Associateを選択します。

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

1. EC2ダッシュボードで、左側のメニューからInstancesを選択します。
2. インスタンスの一覧からBastion Host Aを選択します。
3. Connectを選択し、表示される接続手順に従います。
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. Find official GitLab-created AMI IDs on AWSというタイトルの以下のセクションを使用して、正しいAMIを見つけてLaunchを選択します。
2. Name and tagsセクションで、Nameに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を選択し、ロードバランサーのアプローチに基づいて適切なセキュリティグループを選択します:

      • NLB only: gitlab-nlb-sec-groupとbastion-sec-group
      • Hybrid NLB->ALB: gitlab-rails-sec-groupとbastion-sec-group

      bastion-sec-groupは、SSH Agent Forwardingを使用して、管理および設定タスクのためにバスティオンホストからのSSHアクセスを許可します。

6. ストレージについては、ルートボリュームはデフォルトで8 GiBに設定されています。ここにはデータを保存しないため、この容量で十分です。
7. すべての設定を確認し、問題がなければ、Launch Instanceを選択します。

カスタム設定を追加する

SSHエージェント転送を使用し、踏み台ホスト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インスタンスに接続してアクセスを検証し、required PostgreSQL extensionsをインストールします。

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

-hには、RDSエンドポイントのホスト名のみを使用し、末尾のコロンとポート番号は省略します:

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

次に、CREATE EXTENSIONを使用して各required extensionをインストールします:

CREATE EXTENSION IF NOT EXISTS btree_gist;
CREATE EXTENSION IF NOT EXISTS ...;

\dxでインストールされた拡張機能を検証します。

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
   
   # Adjust based on your Redis setting
   gitlab_rails['redis_ssl'] = true

4. 最後に、変更を反映するためにGitLabを再設定します。

   sudo gitlab-ctl reconfigure

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

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

Gitalyを設定する

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

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

1. EC2ダッシュボードでLaunch instanceを選択します。
2. Name and tagsセクションで、Nameに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で、Disableが選択されていることを確認します。
   4. Firewallで、Create security groupを選択し、Security group name（この例ではgitlab-gitaly-sec-group）を入力し、説明を追加します。
      1. Custom TCPルールを作成し、ポート8075をPort Rangeに追加します。ソースには、ロードバランサーのアプローチに基づいて適切なセキュリティグループを選択します:
         • NLB only: gitlab-nlb-sec-group
         • Hybrid NLB->ALB: gitlab-rails-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を選択します。

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

Elastic File System（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でオブジェクトストレージを使用する際の詳細情報が記載されています。

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. Actionsを選択し、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. Owned by meを選択し、先ほど作成したカスタム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 existing security groupをチェックし、ロードバランサーのアプローチに基づいて適切なセキュリティグループを選択します:

   • NLB only: gitlab-nlb-sec-groupとbastion-sec-group
   • Hybrid NLB->ALB: gitlab-rails-sec-groupとbastion-sec-group

   bastion-sec-groupは、SSH Agent Forwardingを使用して、管理および設定タスクのためにバスティオンホストからのSSHアクセスを許可します。

9. Advanced detailsセクション:

   1. IAM instance profile: 先ほど作成したGitLabS3Accessロールを選択します。

10. すべての設定を確認し、問題がなければCreate launch templateを選択します。

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

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

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

2. Group nameを入力します（この例ではgitlab-auto-scaling-group）。

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

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. Nextを選択します。

5. Load Balancing settingsセクション:

   1. Attach to an existing load balancerを選択します。
   2. Existing load balancer target groupsドロップダウンリストで、ロードバランサーのアプローチに基づいて適切なターゲットグループを選択します:
      • NLB only: gitlab-nlb-ssh-targetとgitlab-nlb-http-targetを選択します
      • Hybrid NLB->ALB: gitlab-nlb-ssh-targetとgitlab-alb-http-targetを選択します。オートスケールグループは、起動されたすべてのインスタンスをこれらのターゲットグループに自動的に登録します。
   3. Health Check Typeで、Turn on Elastic Load Balancing health checksオプションをオンにします。Health Check Grace Periodは、デフォルトの300秒のままにします。
   4. Nextを選択します。

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

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

   1. No scaling policiesを選択します。ポリシーは以降に設定されます。
   2. Min desired capacity: 2に設定します。
   3. Max desired capacity: 4に設定します。
   4. Nextを選択します。

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

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

   1. 先ほど作成したオートスケールグループの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オブジェクトなどをバックアップおよび復元するためのツールが用意されています。

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

• バックアップ/復元ツールは、シークレットなどの一部の設定ファイルを保存しません。これらは手動で設定する必要があります。
• デフォルトでは、バックアップファイルはローカルに保存されますが、S3を使用してGitLabをバックアップすることもできます。
• バックアップから特定のディレクトリを除外できます。

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でオブジェクトストレージを使用するには、増分ログが必要です。

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