OCIでCI/CDパイプラインを有効にするためのGitLabのデプロイ

GitLabは、Gitベースのリポジトリ管理サービス、問題追跡および継続的インテグレーションおよびデプロイメント(CI/CD)パイプライン機能を提供するWebベースのDevOpsプラットフォームです。GitLabを自分で管理し、クラウド・デプロイメントを自動化するためにOracle Cloud Infrastructure (OCI)にデプロイできます。

アーキテクチャ

この参照アーキテクチャには、スタンドアロン・デプロイメントと分散デプロイメントの2つのデプロイメント・オプションがあります。

• スタンドアロン(< 1,000ユーザー)

  スタンドアロン・アーキテクチャは、GitLabの最も簡単なオプションです。すべてのGitLabコンポーネントをOCIテナンシ内の単一のコンピュート・インスタンスにデプロイします。最大1,000人のユーザーにサービスを提供する必要があり、厳密な可用性要件がない場合は、頻繁にバックアップするスタンドアロン・ソリューションが多くの組織に適しています。単一のテナンシで複数のGitLabサーバーをホストできます。次の図は、この参照アーキテクチャを示しています。

  
  図deploy_gitlab_sa.pngの説明

• 分散(1000 -2000ユーザー)

  分散ソリューションは、専用GitLabサーバーの様々なコンポーネントを個別のインスタンスに分割する複数層アーキテクチャで、それぞれが特定のタスクを実行するように割り当てられています。具体的には、分散アーキテクチャには、完全に機能するGitLabデプロイメントに必要な専用のPostgreSQLサーバー、Redisサーバー、GitalyサーバーおよびPrometheusモニタリング・インスタンスがあります。GitLabの推奨事項に従って、この分散デプロイメントでは約2,000ユーザーがサポートされます。一部の組込み冗長性により、スタンドアロン・デプロイメントよりもパフォーマンスが高く、フォルト・トレランスが高くなります。ただし、分散デプロイメントの可用性は高くありません。

  
  図deploy_gitlab_dist.pngの説明

これらのアーキテクチャには、次のコンポーネントがあります。

• リージョン

  Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。地域は他の地域から独立しており、広大な距離で(国または大陸間で)分離できます。

• 可用性ドメイン

  可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却などのインフラストラクチャや内部可用性ドメイン・ネットワークを共有しません。したがって、ある可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインに影響する可能性はほとんどありません。これらのGitLab参照アーキテクチャの一部としてデプロイされたインスタンスは、すべて単一の可用性ドメインに配置されます。

• 仮想クラウド・ネットワーク(VCN)およびサブネット

  VCNは、OCIリージョンで設定するソフトウェア定義ネットワークです。VCNは、リージョンまたは可用性ドメインに固有のサブネットにセグメント化できます。リージョン固有のサブネットと可用性ドメイン固有のサブネットの両方を同じVCNに共存させることができます。サブネットはパブリックまたはプライベートにできます。このGitLabアーキテクチャは、パブリックおよびプライベート・サブネットを含む既存のVCNにデプロイすることも、必要なサブネットを持つVCNを作成するように構成することもできます。

  • 要塞ホスト・サブネット

    要塞ホスト・サブネットは、要塞ホスト・インスタンスを含む専用のパブリック・サブネットです。要塞ホストはこのアーキテクチャのオプション・コンポーネントであり、GitLabがインターネットまたはパブリック・サブネットに直接接続されている場合は不要です。

  • ロード・バランサ・サブネット

    ロード・バランサ・サブネットは、ロード・バランサを含む専用のパブリック・サブネットです。

  • GitLabプライベート・サブネット

    GitLabプライベート・サブネットには、Gitalyサーバー、Redisサーバー、Postgresサーバー、Prometheus -Grafana (モニタリング)サーバーおよびオプションのGitLabランナーが含まれています。

• ロード・バランサ

  ロード・バランサには、GitLabインスタンスへの接続に使用されるパブリック対応IPが含まれます。GitLabインスタンスのカスタム・ドメイン名が必要な場合は、ロード・バランサのIPアドレスをDNSプロバイダに登録します。ロード・バランサは、GitLabサーバーの監視にラウンドロビン状態チェック・ポリシーを使用します。

• Compute
  GitLabの場合、単一のGitLabサーバー・コンピュート・インスタンスのみが作成されます。分散アーキテクチャでは、合計8つのコンピュート・インスタンスが作成されます。これらの各インスタンスは、次のサービスを提供します。

  • GitLabサーバー

    プライマリGitLab Webベース・アプリケーションは、2つのGitLabサーバーにインストールされます。GitLabの管理はこれらのインスタンスで実行され、ロード・バランサはフロントエンドとして機能します。

  • PostgreSQLサーバー

    GitLabアプリケーションの永続データベース情報を格納します。たとえば、ユーザー、権限、問題またはその他のメタデータは、PostgreSQLデータベースに格納されます。

  • Redisサーバー

    GitLabアプリケーションは、ジョブ情報、メタデータおよび受信ジョブの非永続データベース・バックエンドとしてRedisを使用します。

  • Gitaly Servers

    GitalyサービスはGitリポジトリのファイル・ストレージを提供します。GitLabのリポジトリの一部であるすべてのファイルは、Gitalyサーバーに格納されます。追加容量のレベルを証明するために、2つのGitalyインスタンスが作成されます。特定のプロジェクトのデータを格納するサーバーをリポジトリごとにカスタマイズできます。

  • PostgreSQLサーバー

    GitLabは、永続データベース情報をPostgreSQLサーバーに格納します。永続データの例としては、ユーザー、権限、問題、その他のプロジェクト・メタデータなどがあります。

  • Redisサーバー

    GitLabアプリケーションは、ジョブ情報、特定のタイプのメタデータおよび受信ジョブの非永続データベース・バックエンドとしてRedisを使用します。

  • Prometheus + Grafana (モニタリング)サーバー

    Prometheus + Grafanaサーバーは、システムおよびサービス・モニタリング・サーバーです。指定された間隔で構成済ターゲットからメトリックを収集し、ルール式を評価し、結果を表示し、指定された条件が満たされた場合にアラートをトリガーできます。

  • ランナー

    GitLabランナーは、GitLab CI/CDと連携してパイプラインでジョブを実行する専用のマシンです。これらは通常、GitLabインスタンスが稼働してテストされた後に、GitLab環境にデプロイされます。これらはデプロイメントの一部として作成されません。

• オブジェクト・ストレージ

  分散デプロイメントでは、OCIテナンシ内に一連のオブジェクト・ストレージ・バケットが作成され、バックアップなど、GitLabプロジェクトに関連付けられた様々なタイプのデータを格納するように設計されています。

推奨事項

GitLabをデプロイする際の開始点として次の推奨事項を使用して、Oracle Cloud InfrastructureでCI/CDパイプラインを有効にします。 実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。

• コンピュート・シェイプ

  このアーキテクチャでは、Oracle Linux OSイメージを使用し、コンピュート・シェイプのすべてのファミリ(標準または柔軟)をサポートします。GitLabでは、スタンドアロンおよび分散デプロイメントに次の構成パラメータをお薦めします。

  スタンドアロン

  サービス	構成
  GitLabサーバー	4 OCPU、8 GB RAM
  GitLabランナー(Nオプション)	1 OCPU、4 GB RAM

  配分済

  サービス	構成
  Bastion server (オプション)	1 OCPU、2 GB RAM
  GitLabサーバー(2)	4 OCPU、8 GB RAM
  PostgreSQL	1 OCPU、8 GB RAM
  Redis	1 OCPU、4 GB RAM
  ギタリー(1つは必須、2つはオプション)	2 OCPU、16 GB RAM
  モニタリング・ノード	1 OCPU、2 GB RAM
  GitLabランナー(Nオプション)	1 OCPU、4 GB RAM

  GitLabではこれらの構成をお薦めしますが、デプロイ時にカスタマイズできます。
• VCN

  VCNおよびサブネットを作成する場合、プライベート接続を設定する他のネットワーク(OCI、オンプレミス・データ・センターまたは別のクラウド・プロバイダ)と重複しないCIDRブロックを使用します。VCN CIDRブロックは、作成後に編集可能です。

  サブネットを設計する際には、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを、セキュリティ境界として機能できる同じサブネットにアタッチします。

• セキュリティ

  Oracle Cloud Guardを使用して、OCIのリソースのセキュリティをプロアクティブに監視および維持します。Cloud Guardでは、定義可能なディテクタ・レシピを使用して、リソースにセキュリティ上の弱点がないかどうかを調べ、オペレータおよびユーザーのリスク・アクティビティを監視します。構成の誤りやセキュアでないアクティビティが検出された場合、Cloud Guardは修正処理を推奨し、定義可能なレスポンダ・レシピに基づいてそれらの処理を支援します。

  最大限のセキュリティを必要とするリソースの場合、Oracleではセキュリティ・ゾーンを使用することをお薦めします。セキュリティ・ゾーンは、ベスト・プラクティスに基づくセキュリティ・ポリシーのOracle定義レシピに関連付けられたコンパートメントです。たとえば、セキュリティ・ゾーン内のリソースは、パブリック・インターネットからアクセスできず、顧客管理キーを使用して暗号化する必要があります。セキュリティ・ゾーンでリソースを作成および更新する場合、OCIはセキュリティ・ゾーン・レシピのポリシーに対して操作を検証し、ポリシーに違反する操作を拒否します。

• ランナー

  GitLabランナーは、既存のGitLabインスタンスと同じプライベート・サブネット、または専用のVCNまたはサブネットにデプロイできます。

注意事項

この参照アーキテクチャをデプロイする場合は、次の点を考慮してください。

• パフォーマンス

  このアーキテクチャの一部として起動されるすべてのデフォルトのコンピュート・シェイプは、GitLabドキュメントに記載されている推奨事項に従います。ただし、パーティクルノードにさらに多くのリソースが必要な場合は、コンピュートシェイプをスケーリングできます。分散アーキテクチャは、スタンドアロン・デプロイメントよりも高いパフォーマンスを発揮します。アーキテクチャには、次の予期されるパフォーマンス・メトリックのオプションがあります。

• SECURITY

  ロード・バランサおよび要塞ホストを除き、存在する場合、GitLabアーキテクチャのすべてのコンポーネントはプライベート・サブネットにあります。分散アーキテクチャのコンピュート・インスタンスはすべてファイアウォールが有効になっており、iptablesがオンになっており、ノード間の通信を可能にするために必要なポートのみが開かれています。

• 可用性

  GitLabサーバーはペアとしてデプロイされ、ロード・バランサによってバランシングされます。すべてのインスタンスは、単一の可用性ドメインにデプロイされます。この参照アーキテクチャでは、様々なタイプのデータを格納するための複数のオブジェクト・ストレージ・バケットも作成されます。オブジェクト・ストレージはリージョナル・サービスであり、特定のコンピュート・インスタンスまたは可用性ドメインには関連付けられません。インターネットに接続していて、いずれかのオブジェクト・ストレージ・エンドポイントにアクセスできる場合は、OCIのコンテキスト内外の任意の場所からデータにアクセスできます。このデプロイメントでは、サービス・ゲートウェイを使用してオブジェクト・ストレージ・バケットに接続します。サービス・ゲートウェイを使用すると、プライベート・サブネットのプライベートIPアドレスからオブジェクト・ストレージのパブリック・エンドポイントに接続できます

• バックアップと復元
  分散デプロイメントでは、バックアップを格納するためのオブジェクト・ストレージ・バケットが作成され、そのバケットへのデータのアップロードに必要なすべての構成設定が設定されます。また、プライマリGitLabサーバー・インスタンスにcronジョブを作成します。これにより、GitLabデータの日次バックアップが作成され、バケットにアップロードされて、マシンにコピーが格納されます。gitlab-secrets.jsonファイルには機密データが含まれており、このバックアップには含まれません。/etc/gitlabディレクトリまたは/etc/gitlab/gitlab-secrets.jsonファイルのコピーは、管理者がこの配備の外部に存在する安全な場所に保管することをお勧めします。より頻繁なバックアップが必要かどうかを検討し、オブジェクト・ストレージ・バケットに適切な保存ポリシーを設定します。

  ## Run a backup everyday at 1am.
  0 1 * * * sudo gitlab-backup create
   
  ## Run a separate backup for configuration settings (creates a tar archive in /etc/gitlab/config_backup)
  0 2 * * * sudo gitlab-ctl backup-etc

  GitLabデータだけでなく、GitLabサーバー全体もバックアップできます。OCIブロック・ボリューム・サービスでは、スケジュールに従ってブロック・ボリューム・バックアップを自動的に実行し、選択したバックアップ・ポリシーに基づいて保持できます。詳細は、ポリシー・ベースのバックアップのドキュメントを参照してください。

• 原価

  このアーキテクチャのコストは、コンピュート・インスタンス、ネットワーク・ロード・バランサ、データ・ストレージなどのOCIデプロイ済インフラストラクチャ、およびGitLabから購入したライセンスに関連しています。OCIサービスのコストの詳細は、「Oracle Cloud Proce List」ページを参照してください。

• パブリックURL

  DNSプロバイダを使用して、GitLabインスタンスのパブリックIPアドレスをカスタム・ドメイン名に関連付けることを検討します。分散アーキテクチャでは、カスタムURLをロード・バランサのパブリックIPアドレスに関連付ける必要があります。デプロイ時に外部URLドメイン名を設定し、その後、そのURLをGitLabデプロイメントのIPアドレスに関連付けることができます。カスタムURLは、ファクトの後にいつでも変更できます。

デプロイ

このリファレンス・アーキテクチャのTerraformコードは、Oracle Cloud Infrastructure Resource Managerのサンプル・スタックとして使用できます。GitLabからコードをダウンロードし、特定の要件にあわせてカスタマイズすることもできます。

• Oracle Cloud Infrastructure Resource Managerのサンプル・スタックを使用してデプロイします。
  1. をクリックします。

     まだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。

  2. スタックをデプロイするリージョンを選択します。
  3. 画面に表示されるプロンプトと指示に従って、スタックを作成します。
  4. スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
  5. ジョブが完了するまで待機し、計画を確認します。

     変更を加えるには、「Stack Details」ページに戻り、「Edit Stack」をクリックして、必要な変更を行います。その後、プラン処理を再度実行します。

  6. これ以上変更が必要ない場合は、「Stack Details」ページに戻り、「Terraform Actions」をクリックして「Apply」を選択します。
• GitLabでTerraformコードを使用してデプロイします。
  1. GitLabに移動します。
  2. リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
  3. READMEドキュメントの手順に従います。

まとめの問題

Oracle Cloud InfrastructureでCI/CDパイプラインを有効にするためのGitLabのデプロイの詳細を参照してください。

次の追加リソースを確認してください。

• GitLab参照アーキテクチャ
• GitLabのバックアップおよびリストア
• GitLabランナー