自動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 Deploy を有効にします。本番環境への継続的なデプロイ.  時間差ロールアウトを使用した本番環境への継続的なデプロイ. INCREMENTAL_ROLLOUT_MODE 変数をtimedに設定します。本番環境への継続的なデプロイ。 自動デプロイをステージングに、手動デプロイをプロダクションに|STAGING_ENABLED1 に、INCREMENTAL_ROLLOUT_MODEmanualに設定します。デフォルトのブランチは、ステージングに継続的にデプロイされ、本番環境に継続的に配信されます。

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

  1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
  2. Settings > CI/CDを選択します。
  3. Auto DevOpsを展開します。
  4. デプロイ戦略を選択します。
  5. 変更を保存を選択します。
note
ダウンタイムとリスクを最小限に抑えるために、ブルーグリーンのデプロイ技術を使用してください。

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 マニフェストに注釈を付ける必要があります。

      note
      クラスターがベアメタルにインストールされている場合は、ベアメタルの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コントローラへの単一接点を提供するのに十分であり、間接的に、クラスター内部で実行されているすべてのアプリケーションに提供することができます。ベアメタル環境にはこのコモディティがないため、外部コンシューマに同じ種類のアクセスを提供するには少し異なるセットアップが必要です。

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