Auto DevOpsの要件

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

Auto DevOpsを有効にする前に、デプロイの準備を整えておくことをおすすめします。準備をしなくても、まずAuto DevOpsを使用してアプリのビルドとテストを行い、後でデプロイを設定することは可能です。

デプロイを準備するには、次の手順に従います。

Auto DevOpsのデプロイ戦略

Auto DevOpsを使用してアプリケーションをデプロイする場合は、ニーズに最適な継続的デプロイ戦略を選択してください。

デプロイ戦略	セットアップ	開発手法
本番環境への継続的デプロイ	デフォルトブランチを本番環境に継続的にデプロイするためのAuto Deployを有効にします。	本番環境への継続的デプロイ。
スケジュールされた増分ロールアウトを用いた本番環境への継続的デプロイ	`INCREMENTAL_ROLLOUT_MODE`変数を`timed`に設定します。	ロールアウト間に5分の遅延を設けて、本番環境に継続的にデプロイします。
ステージングへの自動デプロイ、本番環境への手動デプロイ	`STAGING_ENABLED`を`1`に、`INCREMENTAL_ROLLOUT_MODE`を`manual`に設定します。	デフォルトブランチを継続的にステージングにデプロイし、本番環境には継続的デリバリーを行います。

デプロイ方法は、Auto DevOpsを有効にする際、または後から選択できます。

左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。
設定 > CI/CDを選択します。
Auto DevOpsを展開します。
デプロイ戦略を選択します。
変更を保存を選択します。

ダウンタイムとリスクを最小限に抑えるため、ブルー/グリーンデプロイ手法を使用してください。

Auto DevOpsのベースドメイン

Auto Review AppsとAuto Deployを使用するには、Auto DevOpsのベースドメインが必要です。

ベースドメインを定義するには、次のいずれかを実行します。

プロジェクト、グループ、またはインスタンスレベル: クラスター設定に移動し、そこで追加します。
プロジェクトまたはグループレベル: 環境変数として追加します: KUBE_INGRESS_BASE_DOMAIN。
インスタンスレベル: 管理者エリアに移動し、設定 > CI/CD > 継続的インテグレーションとデリバリーに移動して、そこで追加します。

ベースドメイン変数KUBE_INGRESS_BASE_DOMAINは、他の環境変数と同じ優先順位に従います。

プロジェクトとグループでベースドメインを指定しない場合、Auto DevOpsはインスタンス全体のAuto DevOpsドメインを使用します。

Auto DevOpsには、ベースドメインに一致するワイルドカードDNS Aレコードが必要です。ベースドメインがexample.comの場合、次のようなDNSエントリが必要です。

*.example.com   3600     A     10.0.2.2

この場合、デプロイされたアプリケーションはexample.comから提供され、10.0.2.2はロードバランサー（一般的にはNGINX）のIPアドレスです（要件を参照）。DNSレコードのセットアップは、このドキュメントの範囲外です。詳細については、DNSプロバイダーにお問い合わせください。

または、設定なしで自動ワイルドカードDNSを提供する無料のパブリックサービス（nip.ioなど）を使用することもできます。nip.ioの場合、Auto DevOpsのベースドメインを10.0.2.2.nip.ioに設定します。

セットアップが完了すると、すべてのリクエストはロードバランサーに到達し、ロードバランサーはアプリケーションを実行しているKubernetesポッドにリクエストをルーティングします。

KubernetesのAuto DevOps要件

KubernetesでAuto DevOpsを最大限に活用するには、以下が必要です。

Kubernetes（Auto Review AppsおよびAuto Deploy用）
デプロイを有効にするには、以下が必要です。
1. プロジェクト用のKubernetes 1.12以降のクラスター。Kubernetes 1.16以降のクラスターの場合、Kubernetes 1.16以降用のAuto Deployを使用するために追加の設定が必要です。
2. 外部HTTPトラフィック用のIngressコントローラー。通常のデプロイではどのIngressコントローラーでも動作するはずですが、GitLab 14.0以降、カナリアデプロイにはNGINX Ingressが必要です。GitLabクラスター管理プロジェクトテンプレートを使用するか、ingress-nginx Helmチャートを使用して、手動でNGINX IngressコントローラーをKubernetesクラスターにデプロイできます。
  カスタムチャートを使用してデプロイする場合は、prometheus.io/scrape: "true"およびprometheus.io/port: "10254"をアノテーションとしてIngressマニフェストに追加し、Prometheusによるスクレイプを有効にする必要があります。
  クラスターがベアメタルにインストールされている場合は、ベアメタルのAuto DevOps要件を参照してください。
ベースドメイン（Auto Review AppsおよびAuto Deploy用）
すべてのAuto DevOpsアプリケーションで使用されるAuto DevOpsのベースドメインを指定する必要があります。このドメインにはワイルドカードDNSを設定する必要があります。
GitLab Runner（すべてのステージ用）
RunnerはDockerを実行するように設定する必要があります。通常、Docker executorまたはKubernetes executorのいずれかを使用し、特権モードを有効にします。RunnerをKubernetesクラスターにインストールする必要はありませんが、Kubernetes executorは使いやすく、自動的にオートスケールします。Docker Machineを使用して、DockerベースのRunnerがオートスケールするように設定することもできます。
Runnerは、GitLabインスタンス全体で使用できるインスタンスRunnerとして登録するか、特定のプロジェクトに割り当てるプロジェクトRunnerとして登録する必要があります。
cert-manager（オプション、TLS/HTTPS用）
アプリケーションのHTTPSエンドポイントを有効にするには、cert-managerをインストールします。これは証明書の発行に役立つ、ネイティブのKubernetes証明書管理コントローラーです。クラスターにcert-managerをインストールすると、Let’s Encrypt証明書が発行され、証明書が有効で最新の状態であることが保証されます。

KubernetesまたはPrometheusが設定されていない場合、Auto Review AppsとAuto Deployはスキップされます。

すべての要件を満たしたら、Auto DevOpsを有効にできます。

ベアメタルのAuto DevOps要件

Kubernetes Ingress-NGINXドキュメントから引用:

ネットワークロードバランサーがオンデマンドで利用できる従来のクラウド環境では、1つのKubernetesマニフェストで、NGINX Ingressコントローラーへの単一の接続ポイントを外部クライアントに提供し、それを通じてクラスター内で実行されているすべてのアプリケーションに間接的にアクセスできます。ベアメタル環境にはこのような仕組みが備わっていないため、外部コンシューマーに同様のアクセスを提供するには、少し異なるセットアップが必要です。

上記のリンク先ドキュメントでは、この問題について説明し、利用可能な解決策を提示しています。次に例を示します。

MetalLBを使用する。
PorterLBを使用する。