を参照してください。

Amazon Web Services(AWS) に GitLab POC をインストールします。

このページでは、公式Linuxパッケージを使ったAWS上のGitLabの一般的な設定のウォークスルーを提供します。あなたのニーズに合わせてカスタマイズしてください。

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

プロダクショングレードのGitLabを始めるには

note
このドキュメントは、概念実証インスタンスのインストールガイドです。リファレンスアーキテクチャではありませんし、可用性の高い設定にはなりません。

このガイドに忠実に従うと、Non-HA 2000ユーザーリファレンスアーキテクチャの2つのアベイラビリティゾーンの実装の 縮小版にほぼ等しい概念実証インスタンスが得られます。2Kリファレンスアーキテクチャは、コストと複雑さを抑えながらある程度のスケーリングを提供することを主な目的としているため、HAではありません。3000ユーザーリファレンスアーキテクチャは、GitLab HAである最小のサイズです。HAを実現するためにサービスのロールが追加されており、特にGitリポジトリストレージのHAを実現するためにGitalyクラスターを使用し、三重冗長性を指定しています。

GitLabは主に2種類のリファレンスアーキテクチャをメンテナーし、テストしています。Linuxパッケージアーキテクチャはインスタンスコンピュートで実装され、Cloud Native HybridアーキテクチャはKubernetesクラスターを最大限に利用します。Cloud Native Hybridリファレンスアーキテクチャ仕様は、Linuxパッケージアーキテクチャの説明から始まるリファレンスアーキテクチャサイズページの補遺セクションです。たとえば、3000ユーザーCloud Nativeリファレンス・アーキテクチャは、3000ユーザー・リファレンス・アーキテクチャ・ページのCloud Native Hybridリファレンス・アーキテクチャ with Helm Chart（代替）と題されたサブセクションにあります。

本番グレードの Linux パッケージ・インストールを始めるには

Infrastructure as CodeツールのGitLab環境ツール(GET)は、AWS上のLinuxパッケージを使った構築、特にHAセットアップをターゲットにしている場合に始めるのに最適な場所です。すべてを自動化してくれるわけではありませんが、Gitaly Cluster のような複雑なセットアップを完了させてくれます。GETはオープンソースなので、誰でもその上に構築し、改良に貢献することができます。

本番レベルのクラウド・ネイティブ・ハイブリッドGitLabを始めるには

クラウド・ネイティブ・ハイブリッドのアーキテクチャには2つのInfrastructure as Codeオプションがあり、GitLab Cloud Native Hybrid on AWS EKSの実装パターンではAvailable Infrastructure as Code for GitLab Cloud Native Hybridのセクションで比較しています。GitLabとAWSが共同開発したGitLab Environment ToolkitとAWS Quick Start for GitLab Cloud Native Hybrid on EKSを比較しています。GETとAWS Quick Startはどちらもオープンソースなので、誰でもその上に構築し、改良に貢献することができます。

導入

ほとんどの場合、Linuxパッケージを利用してセットアップしていますが、AWSのネイティブサービスも利用しています。LinuxパッケージにバンドルされているPostgreSQLとRedisを使う代わりに、Amazon RDSとElastiCacheを使っています。

このガイドでは、仮想プライベートクラウドとサブネットの設定から始め、データベースサーバとしてRDS、RedisクラスタとしてElastiCacheなどのサービスをインテグレーションし、最終的にカスタムのスケーリングポリシーで自動スケーリンググループで管理するマルチノードのセットアップを説明します。

要件

AWSと Amazon EC2の基本的な知識に加えて、以下のことが必要です：

note
ACMを通してプロビジョニングされた証明書の検証には数時間かかることがあります。後の遅延を避けるために、できるだけ早く証明書をリクエストしてください。

アーキテクチャ

以下は推奨アーキテクチャの図です。

AWS architecture diagram

AWSコスト

GitLabは以下のAWSサービスを利用しています：

  • EC2：GitLabは共有ハードウェア上にデプロイされ、オンデマンド価格が適用されます。専用インスタンスや予約インスタンスでGitLabを実行したい場合は、EC2の価格ページを参照してください。
  • S3:GitLabはバックアップ、アーティファクト、LFSオブジェクトを保存するためにS3（価格ページ）を使用します。
  • ELB: Classic Load Balancer(料金ページ)。リクエストを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. ポリシーの作成]を選択し、[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. Review policyを選択し、ポリシーに名前を付け（ここではgl-s3-policy ）、Create policyを選択します。

IAMロールの作成

  1. IAMダッシュボードで、左メニューの「ロール」を選択し、「ロールの作成」を選択します。
  2. AWS service > EC2を選択して新しいロールを作成し、Nextを選択します：権限を選択します。
  3. ポリシーフィルターで、上記で作成したgl-s3-policy を検索して選択し、Tagsを選択します。
  4. 必要に応じてタグを追加し、レビューを選択します。
  5. ロールに名前を付け（ここではGitLabS3Access を使用）、「ロールを作成」を選択します。

このロールは後で起動設定を作成するときに使用します。

ネットワークの設定

まずGitLabクラウドインフラストラクチャ用のVPCを作成し、サブネットを作成して少なくとも2つのAvailability Zone (AZ)に公開インスタンスと非公開インスタンスを配置します。公開サブネットにはRoute Table Keepと関連するInternet Gatewayが必要です。

仮想非公開クラウドの作成(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を選択し、「アクション」を選択し、「DNS解決の編集」を選択し、DNS解決を有効にします。完了したら「Save」を選択します。

サブネット

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

ロードバランサーやRDSインスタンスに合わせて非公開サブネットと公開サブネットも作成します：

  1. 左のメニューからサブネットを選択します。

  2. サブネットの作成]を選択します。IPに基づく説明的な名前タグを付けます。例えば、gitlab-public-10.0.0.0 。前回作成したVPCを選択し、アベイラビリティゾーンを選択します（ここではus-west-2a ）。IPv4 CIDRブロックで24サブネット10.0.0.0/24：

    Create subnet

  3. 同じ手順ですべてのサブネットを作成します：

    ネームタグ種類利用可能ゾーンCIDRブロック
    gitlab-public-10.0.0.0公開us-west-2a10.0.0.0/24
    gitlab-private-10.0.1.0非公開us-west-2a10.0.1.0/24
    gitlab-public-10.0.2.0公開us-west-2b10.0.2.0/24
    gitlab-private-10.0.3.0非公開us-west-2b10.0.3.0/24
  4. すべてのサブネットが作成されたら、2つの公開サブネットのIPv4の自動割り当てを有効にします：
    1. 各公開サブネットを順番に選択して、［アクション］を選択し、［自動割り当てIP設定の変更］を選択します。オプションを有効にして保存します。

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

同じダッシュボードの「Internet Gateways」で新しいゲートウェイを作成します：

  1. 左のメニューからインターネットゲートウェイを選択します。
  2. インターネットゲートウェイの作成」を選択し、「gitlab-gateway 」という名前を付けて「作成」を選択します。

  3. 表からゲートウェイを選択し、アクションのドロップダウンリストから「VPCにアタッチ」を選択します。

    Create gateway

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

NATゲートウェイの作成

非公開サブネットにデプロイされたインスタンスは、更新のためにインターネットに接続する必要がありますが、公開インターネットからはアクセスできないようにする必要があります。これを実現するために、各公開サブネットにデプロイされたNATゲートウェイを利用します：

  1. VPCダッシュボードに移動し、左のメニューバーでNAT Gatewaysを選択します。
  2. Create NAT Gatewayを選択し、以下を完了します：
    1. サブネット：ドロップダウンリストからgitlab-public-10.0.0.0 。
    2. Elastic IP割り当てID：NAT ゲートウェイに新しい IP を割り当てるには、既存の Elastic IP を入力するか、[Allocate Elastic IP address] を選択します。
    3. 必要に応じてタグを追加します。
    4. NATゲートウェイの作成］を選択します。

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 。target 列で、前に作成したgitlab-gateway を選択します。完了したら、Save routesを選択します。

次に、公開サブネットをルートテーブルに関連付けなければなりません：

  1. サブネットの関連付け]タブを選択し、[サブネットの関連付けの編集]を選択します。
  2. 公開サブネットのみにチェックを入れ、［保存］を選択します。

非公開ルートテーブル

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

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

ロードバランサ

ポート80 と443 のインバウンドトラフィックを GitLab アプリケーションサーバ間で均等にディストリビューションするためにロードバランサを作成します。後で作成するスケーリングポリシーに基づいて、必要に応じてインスタンスをロードバランサに追加したりロードバランサから削除したりします。さらに、ロードバランサはインスタンスのヘルスチェックを行います。

EC2のダッシュボードで、左のナビゲーションバーにあるロードバランサーを探します：

  1. Create Load Balancerを選択します。
    1. Classic Load Balancer を選択します。
    2. 名前をつけて（ここではgitlab-loadbalancer とします）、Create LB Insideオプションでドロップダウンリストからgitlab-vpc を選びます。
    3. Listenersセクションで、以下のリスナーを設定します：
      • ロードバランサとインスタンスの両方のプロトコルとポートに HTTP ポート 80 を設定します。
      • ロードバランサーとインスタンスの両方のプロトコルとポートに対するTCPポート22
      • ロードバランサーのプロトコルとポートにHTTPSポート443、インスタンスのHTTPポート80に転送（ガイドの後半でポート80をリッスンするようにGitLabを設定します）
    4. Select Subnetsセクションで、ロードバランサーが両方のアベイラビリティゾーンにトラフィックをルーティングできるように、リストから両方の公開サブネットを選択します。
  2. ロードバランサにセキュリティグループを追加して、ファイアウォールとして機能させ、どのトラフィックを通過させるかを制御します。Assign Security Groupsを選択し、Create a new security group を選択し、名前(ここではgitlab-loadbalancer-sec-groupを使います)と説明をつけ、どこからでも HTTP と HTTPS の両方のトラフィックを許可します(0.0.0.0/0, ::/0)。SSHトラフィックも許可し、カスタム・ソースを選択し、単一の信頼できるIPアドレスかCIDR表記のIPアドレス範囲を追加します。これにより、ユーザーはSSH経由でGitアクションを実行できるようになります。
  3. Configure Security Settingsを選択し、以下を設定します：
    1. ACMからSSL/TLS証明書を選択するか、IAMに証明書をアップロードします。
    2. Select a Cipherで、ドロップダウンリストから定義済みのセキュリティポリシーを選択します。クラシックロードバランサーの定義済み SSL セキュリティポリシーの内訳は、AWS のドキュメントで確認できます。サポートされているSSL暗号とプロトコルのリストについては、GitLabコードベースを確認してください。
  4. Configure Health Checkを選択し、EC2インスタンスのヘルスチェックを設定します。
    1. Ping ProtocolはHTTPを選択します。
    2. Ping Port］には、［80］を入力します。
    3. Ping Path] には、[Readiness check] エンドポイントを使用することをお勧めします。ヘルスチェックエンドポイントのIP allowlistにVPC IP Address Range(CIDR)を追加する必要があります。
    4. デフォルトのAdvanced Detailsを維持するか、必要に応じて調整します。
  5. Add EC2 Instancesを選択 - 後でAuto Scaling Groupを作成してインスタンスを管理するので、何も追加しないでください。
  6. Add Tagsを選択し、必要なタグを追加します。
  7. レビューと作成]を選択し、すべての設定をレビューし、問題がなければ[作成]を選択します。

ロードバランサが稼動したら、セキュリティグループをもう一度見直して、ELB経由だけのアクセスや、その他の必要条件を絞り込むことができます。

ロードバランサーのDNSの設定

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

  1. 既存のホストされたゾーンを選択するか、ドメインにまだゾーンがない場合は、ホストされたゾーンの作成を選択し、ドメイン名を入力し、作成を選択します。
  2. レコードセットの作成］を選択し、次の値を入力します：
    1. 名前：ドメイン名（デフォルト値）を使用するか、サブドメインを入力します。
    2. タイプ： A - IPv4アドレスを選択します。
    3. エイリアス：デフォルトは「いいえ 」です。
    4. Alias Target： ELB Classic Load Balancersセクションを探し、先ほど作成したクラシックロードバランサーを選択します。
    5. ルーティングポリシー：ここではSimpleを使いますが、ユースケースに応じて別のポリシーを選ぶこともできます。
    6. ターゲットの健全性を評価：私たちはこれを「いいえ」に設定していますが、ロードバランサがターゲットの健康状態に基づいてトラフィックをルーティングするように選択できます。
    7. 作成を選択します。
  3. Route 53経由でドメインを登録した場合は、これで完了です。別のドメインレジストラを使用した場合は、ドメインレジストラでDNSレコードを更新する必要があります。必要があります：
    1. Hosted zonesを選択し、上記で追加したドメインを選択します。
    2. NS レコードの NSリストが表示されます。NS ドメインレジストラの管理者パネルから、これらの NSレコードをそれぞれドメインのDNSレコードにNS 追加 NSします。これらの手順はドメインレジストラによって異なる場合があります。行き詰まった場合は、「レジストラ名」DNSレコードの追加でGoogle検索すると、ドメインレジストラ固有のヘルプ記事が見つかるはずです。

この手順は、使用するレジストラによって異なり、このガイドの範囲を超えています。

RDSを使用したPostgreSQL

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

RDSセキュリティグループ

後でgitlab-loadbalancer-sec-group にデプロイするインスタンスからのインバウンドトラフィックを許可する、データベースのセキュリティグループが必要です：

  1. EC2のダッシュボードから、左のメニューバーからセキュリティグループを選択します。
  2. Create security groupを選択します。
  3. 名前（ここではgitlab-rds-sec-group を使用）、説明を付け、VPCドロップダウンリストからgitlab-vpc を選択します。
  4. Inbound rulesセクションで、Add ruleを選択し、以下を設定します：
    1. タイプ： PostgreSQLルールを検索して選択します。
    2. ソース・タイプ：「カスタム」に設定します。
    3. ソース：先ほど作成したgitlab-loadbalancer-sec-group を選択します。
  5. 完了したら、セキュリティグループの作成を選択します。

RDSサブネットグループ

  1. RDSダッシュボードに移動し、左メニューからサブネットグループを選択します。
  2. Create DB Subnet Groupを選択します。
  3. サブネットグループの詳細で、名前（ここではgitlab-rds-group ）と説明を入力し、VPCドロップダウンリストからgitlab-vpc を選択します。
  4. Availability Zones］ドロップダウンリストで、設定したサブネットを含むAvailability Zonesを選択します。この例では、eu-west-2a とeu-west-2b を追加します。
  5. サブネット］ドロップダウン・リストから、サブネット・セクションで定義した2つの非公開サブネット（10.0.1.0/24 および10.0.3.0/24 ）を選択します。
  6. 準備ができたら、［作成］を選択します。

データベースの作成

caution
バースト可能なインスタンス (t クラス・インスタンス) をデータベースに使用すると、高負荷が継続した場合に CPU クレジットが不足してパフォーマンスにイシューが発生する可能性があるため、使用は避けてください。

さて、いよいよデータベースを作成します：

  1. RDSダッシュボードに移動し、左メニューからデータベースを選択し、データベースの作成を選択します。
  2. データベースの作成方法に「Standard Create」を選択します。
  3. データベースエンジンとしてPostgreSQLを選択し、データベース要件でGitLabのバージョンに定義されているPostgreSQLの最小バージョンを選択します。
  4. これは本番サーバーなので、TemplatesセクションからProductionを選びましょう。
  5. 設定]で
    • gitlab-db-ha をDBインスタンス識別子に使用します。
    • gitlab をマスタユーザ名に使用します。
    • マスターパスワードには非常にセキュリティの高いパスワードを使用します。

    後で必要になるので、メモしておいてください。

  6. DB インスタンス・サイズでは、[Standard class] を選択し、ドロップダウンリストから要件を満たすインスタンス・サイズを選択します。ここではdb.m4.large インスタンスを使用します。
  7. ストレージ]で、以下を設定します：
    1. ストレージタイプ]ドロップダウンリストから[Provisioned IOPS(SSD)]を選択します。Provisioned IOPS(SSD) ストレージはこの用途に最適です（ただし、General Purpose(SSD) を選択してコストを削減することもできます）。詳しくはStorage for Amazon RDSを参照してください。
    2. ストレージを割り当て、プロビジョニングIOPSを設定します。それぞれ最小値の100 と1000 を使用します。
    3. ストレージの自動スケーリングを有効にし（オプション）、ストレージの最大閾値を設定します。
  8. Availability & durability］で［Create a standby instance］を選択して、スタンバイRDSインスタンスを別のAvailability Zoneでプロビジョニングします。
  9. 接続性］で、以下を設定します：
    1. Virtual Private Cloud(VPC)ドロップダウンリストから、先ほど作成した VPC (gitlab-vpc) を選択します。
    2. Additional connectivity configuration] セクションを展開し、先ほど作成したサブネットグループ (gitlab-rds-group) を選択します。
    3. 公開アクセシビリティを「No」に設定します。
    4. VPCセキュリティグループで「Choose existing」を選択し、ドロップダウンリストから上記で作成したgitlab-rds-sec-group 。
    5. データベースポートはデフォルトの5432 のままにしておきます。
  10. データベース認証では、パスワード認証を選択します。
  11. 追加設定セクションを展開し、以下を完了します：
    1. 初期データベース名。gitlabhq_production を使用します。
    2. お好みのバックアップ設定を行います。
    3. ここでの唯一の変更は、メンテナンスで自動マイナーバージョンアップデートを無効にすることです。
    4. その他の設定はそのままにしておくか、必要に応じて微調整してください。
    5. 問題がなければ、Create databaseを選択します。

これでデータベースが作成されたので、次はElastiCacheを使ったRedisの設定に移りましょう。

RedisとElastiCacheのセットアップ

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

Redis セキュリティグループの作成

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

Redis サブネットグループ

  1. AWSコンソールからElastiCacheのダッシュボードに移動します。
  2. 左メニューのSubnet Groupsに移動し、新しいサブネットグループを作成します（私たちはgitlab-redis-group と名付けました）。VPCとその非公開サブネットを選択してください。

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

    ElastiCache subnet

Redisクラスターを作成します。

  1. ElastiCacheダッシュボードに戻ります。
  2. 左メニューのRedisを選択し、Createを選択して新しいRedisクラスターを作成します。クラスターモードは サポートされていないので有効にしないでください。クラスターモードがオンでなくても、Redisを複数のアベイラビリティゾーンにデプロイするチャンスはあります。
  3. 設定セクションで
    1. クラスターに名前 (gitlab-redis) と説明を付けます。
    2. バージョンは最新のものを選択します。
    3. ポートは6379 のままにしておきます。これは上記の Redis セキュリティグループで使用したものだからです。
    4. ノードの種類（少なくともcache.t3.medium 、必要に応じて調整してください）とレプリカの数を選択します。
  4. 詳細設定セクションで
    1. マルチAZオートフェイルオーバーオプションを選択します。
    2. 前回作成したサブネットグループを選択します。

    3. 手動で優先する可用性ゾーンを選択し、「Replica 2」で他の2つとは異なるゾーンを選択します。

      Redis availability zones

  5. セキュリティ設定で、セキュリティグループを編集し、以前作成したgitlab-redis-sec-group 。
  6. 残りの設定はデフォルト値のままにしておくか、お好みで編集してください。
  7. 完了したら、「作成」を選択します。

Bastionホストの設定

GitLab のインスタンスは非公開のサブネットにあるので、設定の変更やアップグレードなどのアクションを行うために SSH でインスタンスに接続する方法が必要です。そのためのひとつの方法が、ジャンプボックスとも呼ばれるbastion ホストを使うことです。

note
バスティオンホストをメンテナーしたくない場合は、インスタンスにアクセスするためにAWS Systems Manager Session Managerをセットアップすることができます。これはこのドキュメントの範囲外です。

バスティオンホスト A の作成

  1. EC2 Dashboardに移動し、Launch instanceを選択します。
  2. Ubuntu Server 18.04 LTS(HVM)AMIを選択します。
  3. インスタンスタイプを選択します。他のインスタンスにSSH接続するためにbastionホストを使用するだけなので、t2.micro 。
  4. Configure Instance Detailsを選択します。
    1. Network で、ドロップダウンリストからgitlab-vpc を選択します。
    2. サブネット］で、先ほど作成した公開サブネット（gitlab-public-10.0.0.0 ）を選択します。
    3. 公開IPの自動割り当て]で、[サブネットを使用する](Enable)が選択されていることを再度確認します。
    4. その他はデフォルトのままにして、Add Storageを選択します。
  5. ストレージについては、すべてをデフォルトのままにして、8GBのルートボリュームのみを追加します。このインスタンスには何も保存しません。
  6. Add Tagsを選択し、次の画面でAdd Tagを選択します。
    1. ここではKey: Name とValue: Bastion Host A のみを設定します。
  7. セキュリティグループの設定]を選択します。
    1. Create a new security groupを選択し、セキュリティグループ名（ここではbastion-sec-group）を入力し、説明を追加します。
    2. どこからでも SSH アクセスできるようにします (0.0.0.0/0)。より厳重なセキュリティが必要な場合は、単一のIPアドレスまたはCIDR表記のIPアドレス範囲を指定します。
    3. レビュアーと起動を選択します。
  8. すべての設定をレビューし、問題がなければ「起動」を選択します。
  9. 既存のキーペアにアクセスできることを確認するか、新しいキーペアを作成します。Launch Instanceを選択します。

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

  1. EC2ダッシュボードで、左メニューのインスタンスを選択します。
  2. インスタンスリストからBastion Host Aを選択します。
  3. Connectを選択し、接続の指示に従います。
  4. 接続に成功したら、冗長化のために2つ目のBastionホストの設定に移りましょう。

バスティオンホストBの作成

  1. 上記と同じ手順でEC2インスタンスを作成します：
    1. サブネットには、先ほど作成した2番目の公開サブネット（gitlab-public-10.0.2.0 ）を選択します。
    2. Add Tagsセクションで、Key: Name とValue: Bastion Host B を設定し、2つのインスタンスを簡単に識別できるようにします。
    3. セキュリティグループには、上記で作成した既存のbastion-sec-group を選択します。

SSH エージェント転送を使用します。

Linuxを実行しているEC2インスタンスは、SSH認証に秘密鍵ファイルを使用します。SSHクライアントとクライアントに保存されている秘密鍵ファイルを使用して、Bastionホストに接続します。秘密鍵ファイルがbastionホストに存在しないため、非公開サブネットのインスタンスに接続できません。

秘密鍵ファイルをbastionホストに保存するのは悪い考えです。これを回避するには、クライアントでSSHエージェント転送を使用します。SSH エージェント転送を使用する方法のステップバイステップガイドについては、プライベート Amazon VPC で実行されている Linux インスタンスにセキュアに接続するを参照してください。

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を見つけましょう。
  2. Launchon the desired AMIを選択したら、ワークロードに応じてインスタンスタイプを選択します。ハードウェア要件を参照して、ニーズに合ったものを選択してください（少なくとも、c5.xlarge 、100ユーザーを収容するのに十分です）。
  3. Configure Instance Details］を選択します：
    1. Network]ドロップダウンリストで、先ほど作成した VPC であるgitlab-vpc を選択します。
    2. サブネット] ドロップダウンリストで、先ほど作成したサブネットのリストからgitlab-private-10.0.1.0 を選択します。
    3. 公開IPの自動割り当てが Use subnet setting (Disable) に設定されていることを再度確認します。
    4. Add Storageを選択します。
    5. ルートボリュームはデフォルトで8GBで、データを保存しないことを考えると十分でしょう。
  4. Add Tagsを選択し、必要なタグを追加します。ここでは、Key: Name とValue: GitLab のみを設定します。
  5. セキュリティグループの設定」を選択します。Select an existing security groupをチェックし、先ほど作成したgitlab-loadbalancer-sec-group 。
  6. レビュアーと起動を選択し、設定に問題がなければ起動を選択します。
  7. 最後に、選択した秘密鍵ファイルにアクセスできることを確認するか、新しい秘密鍵ファイルを作成します。Launch Instancesを選択します。

カスタム設定の追加

SSH エージェント転送を使って Bastion Host Aから GitLab インスタンスに接続します。接続したら、以下のカスタム設定を追加します：

Let’s Encryptを無効にします。

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

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

    letsencrypt['enable'] = false

  2. ファイルを保存し、変更を有効にするために再設定してください：

    sudo gitlab-ctl reconfigure

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

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

ホストやエンドポイントを見つけるには、Amazon RDS > Databasesに行き、先ほど作成したデータベースを選択します。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のセットアップ

caution
このアーキテクチャでは、単一のGitalyサーバを持つことは、単一の障害点を作成します。この制限を取り除くためにGitalyクラスタを使用してください。

Gitalyは、GitリポジトリへのハイレベルなRPCアクセスを提供するサービスです。先に設定した非公開サブネット内の別のEC2インスタンスで有効にし、設定する必要があります。

GitalyをインストールするEC2インスタンスを作りましょう：

  1. EC2のダッシュボードからインスタンスの起動を選択します。
  2. AMIを選択します。この例では、Ubuntu Server 18.04 LTS(HVM) 、SSD Volume Typeを選択します。
  3. インスタンスタイプを選択します。c5.xlarge を選択します。
  4. Configure Instance Detailsを選択します。
    1. Network]ドロップダウンリストで、先ほど作成した VPC であるgitlab-vpc を選択します。
    2. サブネット] ドロップダウンリストで、先ほど作成したサブネットのリストからgitlab-private-10.0.1.0 を選択します。
    3. 公開IPの自動割り当てが Use subnet setting (Disable) に設定されていることを再度確認します。
    4. Add Storageを選択します。
  5. ルートボリュームのサイズを20 GiB に大きくし、ボリュームタイプをProvisioned IOPS SSD (io1)に変更します。リポジトリのストレージ要件に十分な大きさのボリュームを作成します)。
    1. IOPSは1000 (20 GiB x 50 IOPS) に設定します。GiB あたり最大 50 IOPS までプロビジョニングできます。より大きなボリュームを選択する場合は、それに応じて IOPS を増やします。gitのように、多くの小さなファイルがシリアライズされた方法で書き込まれるワークロードでは、パフォーマン スに優れたストレージが必要となるため、Provisioned IOPS SSD (io1)を選択します。
  6. Add Tagsを選択し、タグを追加します。内部では、Key: Name とValue: Gitalyのみを設定します。
  7. Configure Security Group（セキュリティグループの設定）を選択し、新しいセキュリティグループを作成します。
    1. セキュリティグループに名前と説明を付けます。どちらもgitlab-gitaly-sec-group を使用します。
    2. カスタムTCPルールを作成し、ポート「Port Range」にポート「8075 」を追加します。ソース」には、gitlab-loadbalancer-sec-groupを選択します。
    3. また、Bastion ホストからSSH エージェント転送を使用して接続できるように、bastion-sec-group から SSH の内部受信ルールを追加します。
  8. レビュアーと起動を選択し、設定に問題がなければ起動を選択します。
  9. 最後に、選択した秘密鍵ファイルにアクセスできることを確認するか、新しい秘密鍵ファイルを作成します。Launch Instancesを選択します。
note
ルートボリュームに_設定と_リポジトリデータを格納する代わりに、リポジトリストレージ用に追加のEBSボリュームを追加することもできます。上記と同じガイダンスに従ってください。Amazon EBSの価格を参照してください。GitLabのパフォーマンスに悪影響を与える可能性があるため、EFSの使用はお勧めしません。詳しくは関連ドキュメントをレビューしてください。

EC2インスタンスの準備ができたので、ドキュメントに従ってGitLabをインストールし、Gitalyを独自のサーバーにセットアップします。作成したGitLabインスタンスで、ドキュメントにあるクライアントのセットアップ手順を実行します。

プロキシSSLのサポートを追加

ロードバランサーでSSLを終了させるので、Supporting proxied SSLの手順に従って、/etc/gitlab/gitlab.rbで設定してください。

gitlab.rb ファイルに変更を保存した後、sudo gitlab-ctl reconfigure を実行することを忘れないでください。

作成者SSHキーの高速ルックアップ

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

Set up fast SSHキー lookupの説明に従って、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でオブジェクトストレージを使うためのその他の情報が記載されています。

note
先ほど作成したAWS IAM プロファイルを使うので、オブジェクトストレージを設定する際には AWS アクセスキーとシークレットアクセスキー/値のペアを省略するようにしましょう。その代わりに、上のリンク先のオブジェクトストレージのドキュメントにあるように'use_iam_profile' => true を設定に使いましょう。

gitlab.rb ファイルに変更を保存した後、sudo gitlab-ctl reconfigure を実行することを忘れないでください。

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

初回ログイン

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

GitLabのインストール方法にもよりますが、また他の方法でパスワードを変更していない場合、デフォルトのパスワードはどちらかになっています：

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

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

自動スケーリンググループが新しいインスタンスをスピンアップすると、ユーザ名root 、新しく作成したパスワードでサインインできるようになります。

カスタムAMIの作成

EC2のダッシュボードで

  1. 先ほど作成したGitLab インスタンスを選択します。
  2. アクション]を選択し、[イメージ]までスクロールダウンし、[イメージの作成]を選択します。
  3. 画像に名前と説明を付けます（どちらもGitLab-Source ）。
  4. その他はデフォルトのままにして、「画像を作成」を選択します。

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

GitLab をオートスケーリンググループ内にデプロイします。

起動設定の作成

EC2のダッシュボードから

  1. 左のメニューからLaunch Configurationsを選択し、Create launch configurationを選択します。
  2. 左メニューからMy AMIを選択し、上記で作成したGitLab custom AMIを選択します。
  3. ニーズに最適なインスタンスタイプ（少なくともc5.xlarge ）を選択し、Configure details を選択します。
  4. 起動設定の名前を入力します (gitlab-ha-launch-config を使用します)。
  5. Request Spot Instanceにはチェックを入れないでください。
  6. IAM Roleドロップダウンリストから、先ほど作成したGitLabAdmin インスタンスロールを選択します。
  7. 残りはデフォルトのままにして、Add Storageを選択します。
  8. ルートボリュームはデフォルトで8GBで、データを保存しないことを考えると十分でしょう。Configure Security Group（セキュリティグループの設定）を選択します。
  9. Select and existing security groupにチェックを入れ、先ほど作成したgitlab-loadbalancer-sec-group 。
  10. レビュー（Review）を選択し、変更内容をレビューして、起動設定の作成（Create launch configuration）を選択します。
  11. 秘密鍵にアクセスできることを確認するか、新しい秘密鍵を作成します。起動設定の作成]を選択します。

オートスケーリンググループの作成

  1. 起動設定が作成されたら、この起動設定を使用してオートスケーリンググループを作成するを選択して、オートスケーリンググループの作成を開始します。
  2. グループ名（ここではgitlab-auto-scaling-group ）を入力します。
  3. グループサイズには、開始するインスタンス数を入力します（ここでは2 と入力します）。
  4. Network]ドロップダウンリストから[gitlab-vpc ]を選択します。
  5. 先ほど作成した非公開サブネットの両方を追加します。
  6. Advanced Details]セクションを展開し、[Receive traffic from one or more load balancers] オプションをチェックします。
  7. Classic Load Balancersドロップダウンリストから、先ほど作成したロードバランサを選択します。
  8. Health Check Type でELBを選択します。
  9. Health Check Grace Period］はデフォルトの［300 seconds］のままにします。Configure scaling policies］を選択します。
  10. このグループの容量を調整するためにスケーリングポリシーを使用する］をチェックします。
  11. このグループでは、CPU使用率が60%以上になるとインスタンスが1つ追加され、45%未満になるとインスタンスが1つ削除されます。

Auto scaling group policies

  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
note
GitLab 12.1以前では、gitlab-rake gitlab:backup:create.

バックアップからのGitLabの復元

GitLabをリストアするには、まずリストアのドキュメントをレビューし、リストアの前提条件を確認します。それから、Linuxパッケージのインストールセクションの手順に従ってください。

GitLabのアップデート

GitLabは毎月22日に新しいバージョンをリリースします。新しいバージョンがリリースされるたびに、GitLabインスタンスをアップデートすることができます：

  1. インスタンスにSSH接続してください。

  2. バックアップを取ります：

    sudo gitlab-backup create

gitlab-rake gitlab:backup:create GitLab 12.1以前では、gitlab-rake gitlab:backup:create.

  1. リポジトリを更新し、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 ユーザにパスワードを設定する必要があるかもしれません。

“要求された変更は拒否されました (422)”

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

一部のジョブログがオブジェクトストレージにアップロードされません。

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

まだ有効になっていない場合は、インクリメンタルロギングを有効にしてください。