Helmを使ったGitLabのインストール

クラウドネイティブのGitLab Helm chartを使ってKubernetesにGitLabをインストールします。

すでに前提条件がインストールされ設定されていると仮定すると、helm コマンドでGitLab をデプロイできます。

caution
デフォルトのHelmチャート設定は本番環境向けではありません。デフォルトのチャートでは、すべてのGitLabサービスがクラスターにデプロイされる概念実証(PoC)実装が作成されます。本番デプロイでは、Cloud Native Hybridリファレンスアーキテクチャに従う必要があります。

本番デプロイを行うには、Kubernetesに関する十分な知識が必要です。このデプロイ方法には、従来のデプロイとは異なる管理、観測可能性、概念があります。

本番デプロイでは

  • PostgreSQLやGitaly(Gitリポジトリストレージのデータプレーン)のようなステートフルなコンポーネントは、クラスター外のPaaSやコンピュートインスタンスで実行する必要があります。この設定は、本番GitLab環境で見られる様々なワークロードをスケールし、確実にサービスするために必要です。
  • PostgreSQL、Redis、そしてGitリポジトリ以外のストレージにはオブジェクトストレージにCloud PaaSを使うべきです。

KubernetesがGitLabインスタンスに必要でない場合は、よりシンプルな代替のリファレンスアーキテクチャを参照してください。

外部ステートフルデータを使用するためのHelmチャートの設定

GitLabのHelmチャートは、Gitリポジトリストレージ(Gitaly)だけでなく、PostgreSQL、Redis、すべての非Gitリポジトリストレージのような外部ステートフルストレージを指すように設定することができます。

以下のInfrastructure as Code (IaC)オプションはこのアプローチを使用しています。

プロダクション・グレードの実装では、適切なChartパラメータを使用して、選択したリファレンス・アーキテクチャに適合する、事前に構築された外部化されたステート・ストアを指定する必要があります。

リファレンス・アーキテクチャの使用

GitLabインスタンスをKubernetesにデプロイするためのリファレンスアーキテクチャは、特にCloud Native Hybridと呼ばれています。すべてのステートフルなGitLabコンポーネントはKubernetesクラスタの外にデプロイする必要があります。

利用可能なCloud Native Hybridリファレンスアーキテクチャのサイズは、リファレンスアーキテクチャのページに記載されています。例えば、ユーザー数3,000の場合のCloud Native Hybridリファレンスアーキテクチャです。

Infrastructure as Code(IaC)とビルダーリソースを使用します。

GitLabは、Helmチャートと補足的なクラウドインフラストラクチャの組み合わせを設定できるInfrastructure as Codeを開発しています: