• Auto DevOpsデプロイ戦略
• Auto DevOpsの基本ドメイン
• Kubernetesの自動DevOps要件
• ベアメタルの Auto DevOps 要件

自動DevOpsの要件

AutoDevOpsを有効にする前に、デプロイの準備をしておくことをお勧めします。そうしない場合は、アプリのビルドとテストに使用し、後でデプロイを設定することができます。

デプロイを準備するには

1. デプロイ戦略を定義します。
2. ベースドメインの準備

3. デプロイ先を定義します：

   1. Kubernetes.
   2. Amazon Elastic Container Service(ECS).
   3. Amazon Elastic Kubernetes Service(EKS).
   4. Amazon EC2。
   5. Google Kubernetes Engine。
   6. ベアメタル。
4. Auto DevOpsを有効にします。

Auto DevOpsデプロイ戦略

GitLab 11.0で導入されました。

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

デプロイ方法は、Auto DevOps を有効にしたとき以降に選択できます：

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. Settings > CI/CDを選択します。
3. Auto DevOpsを展開します。
4. デプロイ戦略を選択します。
5. 変更を保存を選択します。

Auto DevOpsの基本ドメイン

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

ベースドメインを定義するには

• プロジェクト、グループ、またはインスタンスレベルで：クラスター設定に移動し、そこに追加します。
• プロジェクトまたはグループレベルで: 環境変数として追加します:KUBE_INGRESS_BASE_DOMAIN.
• インスタンスレベルの場合: Admin AreaのSettings > CI/CD > Continuous Integration and Deliveryに移動し、そこに追加します。

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

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

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

*.example.com   3600     A     10.0.2.2

この場合、デプロイされたアプリケーションはexample.com から提供され、10.0.2.2 はロードバランサー（通常は NGINX）の IP アドレスです（要件を参照）。DNS レコードの設定については、このドキュメントの範囲を超えています。

また、nip.io のような無料の公開サービスを利用することもできます。nip.io は設定なしで自動的にワイルドカード DNS を提供します。nip.ioでは、Auto DevOpsのベースドメインを10.0.2.2.nip.io。

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

Kubernetesの自動DevOps要件

KubernetesでAuto DevOpsをフル活用するには、以下のものが必要です：

• Kubernetes（オートレビューアプリと オートデプロイ用）

  デプロイを有効にするには、以下のものが必要です：

  1. プロジェクト用のKubernetes 1.12+クラスター。Kubernetes 1.16+クラスターの場合は、Auto Deploy for Kubernetes 1.16+の追加設定を行う必要があります。

  2. 外部HTTPトラフィックには、Ingressコントローラーが必要です。通常のデプロイでは、どのIngressコントローラーでも動作しますが、GitLab 14.0では、カナリアデプロイにはNGINX Ingressが必要です。NGINX IngressコントローラをKubernetesクラスターにデプロイするには、GitLabCluster管理プロジェクトテンプレートを使うか、ingress-nginx Helmチャートを使って手動で行います。

     カスタムチャートを使用してデプロイする場合、prometheus.io/scrape: "true" とprometheus.io/port: "10254"を使用して、Prometheus によってスクレイピングされる Ingress マニフェストに注釈を付ける必要があります。

     クラスターがベアメタルにインストールされている場合は、ベアメタルのAuto DevOps Requirementsを参照してください。

• ベースドメイン(Auto Review AppsおよびAuto Deploy用)

  すべてのAuto DevOpsアプリケーションが使用するAuto DevOpsベースドメインを指定する必要があります。このドメインはワイルドカードDNSで設定する必要があります。

• GitLab Runner(すべてのステージ用)

  RunnerはDockerを実行するように設定する必要があり、通常はDockerか KubernetesのいずれかのExecutorを特権モードを有効にして使用します。ランナーはKubernetesクラスタにインストールする必要はありませんが、Kubernetes Executorは使いやすく、自動的にオートスケールします。DockerMachineを使用して、DockerベースのRunnerをオートスケールするように設定することもできます。

  ランナーは、GitLabインスタンス全体の共有ランナー、または特定のプロジェクトに割り当てられたプロジェクトランナーとして登録する必要があります。

• cert-manager(オプション、TLS/HTTPS用)

  アプリケーションのHTTPSエンドポイントを有効にするには、証明書の発行を支援するネイティブのKubernetes証明書管理コントローラであるcert-managerをインストールします。クラスターにcert-managerをインストールすると、Let’s Encrypt証明書がイシューされ、証明書が有効で最新であることが保証されます。

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

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

ベアメタルの Auto DevOps 要件

Kubernetes Ingress-NGINXのドキュメントによると：

ネットワークロードバランサがオンデマンドで利用可能な従来のクラウド環境では、単一のKubernetesマニフェストで、外部クライアントへのNGINX Ingressコントローラへの単一接点を提供するのに十分であり、間接的に、クラスター内部で実行されているすべてのアプリケーションに提供することができます。ベアメタル環境にはこのコモディティがないため、外部コンシューマに同じ種類のアクセスを提供するには少し異なるセットアップが必要です。

上記のリンク先のドキュメントでは、イシューについて説明し、可能な解決策を提示しています：

• MetalLB.
• ポーターLBを通して