CI/CD変数

CI/CD変数を使用して、Auto DevOpsドメインを設定したり、カスタムHelmチャートを提供したり、アプリケーションをスケールすることができます。

ビルドおよびデプロイメント変数

これらの変数を使用して、ビルドをカスタマイズしてデプロイします。

データベース変数

これらの変数を使用して、CI/CDをPostgreSQLデータベースと統合します。

ジョブスキップ変数

これらの変数を使用して、特定の種類のCI/CDジョブをスキップします。スキップされた場合、CI/CDジョブは作成または実行されません。

アプリケーションシークレット変数の設定

一部のデプロイされたアプリケーションでは、シークレット変数へのアクセスが必要です。Auto DevOpsはK8S_SECRET_で始まるCI/CD変数を検出し、デプロイされたアプリケーションに環境変数として利用可能にします。

前提条件:

• 変数の値は単一行である必要があります。

シークレット変数を設定するには:

1. 上部のバーで、検索または移動先を選択して、プロジェクトを見つけます。
2. 設定 > CI/CDを選択します。
3. 変数を展開します。
4. K8S_SECRET_のプレフィックスを持つCI/CD変数を作成します。たとえば、K8S_SECRET_RAILS_MASTER_KEYという変数を作成できます。
5. 新しいパイプラインを手動で作成するか、codeコードの変更をGitLabにプッシュすることによって、Auto DevOpsパイプラインを実行します。

Kubernetes Secrets

Auto DevOpsパイプラインは、アプリケーションのシークレット変数を使用してKubernetesシークレットを設定します。このシークレットは環境ごとに一意です。アプリケーションをデプロイする際、シークレットはアプリケーションを実行しているコンテナに環境変数として読み込まれます。たとえば、K8S_SECRET_RAILS_MASTER_KEYというシークレットを作成した場合、Kubernetesシークレットは次のようになります:

$ kubectl get secret production-secret -n minimal-ruby-app-54 -o yaml

apiVersion: v1
data:
  RAILS_MASTER_KEY: MTIzNC10ZXN0
kind: Secret
metadata:
  creationTimestamp: 2018-12-20T01:48:26Z
  name: production-secret
  namespace: minimal-ruby-app-54
  resourceVersion: "429422"
  selfLink: /api/v1/namespaces/minimal-ruby-app-54/secrets/production-secret
  uid: 57ac2bfd-03f9-11e9-b812-42010a9400e4
type: Opaque

アプリケーションシークレットを更新する

環境変数は通常、Kubernetesポッド内ではイミュータブルです。アプリケーションシークレットを更新し、新しいパイプラインを手動で作成した場合、実行中のアプリケーションは更新されたシークレットを受け取りません。

アプリケーションシークレットを更新するには、次のいずれかを実行します:

• codeコードの更新をGitLabにプッシュすることで、Kubernetesデプロイを強制的にポッドを再作成させます。
• 実行中のポッドを手動で削除して、Kubernetesに更新されたシークレットを持つ新しいポッドを作成させます。

複数行の値を持つ変数は、Auto DevOpsスクリプティング環境の制限によりサポートされていません。

レプリカ変数の設定

デプロイをスケールする場合は、レプリカ変数を追加します:

1. プロジェクトCI/CD変数としてレプリカ変数を追加します。

2. アプリケーションをスケールするには、再デプロイします。

   Kubernetesを直接使用してアプリケーションをスケールすることは避けてください。Helmが変更を検出しない可能性があり、その後のAuto DevOpsによるデプロイで変更が元に戻される可能性があります。

カスタムレプリカ変数

<TRACK>_<ENV>_REPLICASの形式でカスタムレプリカ変数を作成できます:

• <TRACK>は、Helm Chartアプリケーション定義で設定されたtrack Kubernetesラベルの大文字の値です。trackが設定されていない場合、カスタム変数から<TRACK>を省略します。
• <ENV>は、.gitlab-ci.ymlで設定されたデプロイジョブのすべて大文字の環境名です。

たとえば、環境がqaでトラックがfooの場合、FOO_QA_REPLICASという環境変数を作成します:

QA testing:
  stage: deploy
  environment:
    name: qa
  script:
    - deploy foo

トラックfooは、アプリケーションのHelmチャートで定義されている必要があります。例:

replicaCount: 1
image:
  repository: gitlab.example.com/group/project
  tag: stable
  pullPolicy: Always
  secrets:
    - name: gitlab-registry
application:
  track: foo
  tier: web
service:
  enabled: true
  name: web
  type: ClusterIP
  url: http://my.host.com/
  externalPort: 5000
  internalPort: 5000

ステージングおよび本番環境のデプロイポリシー

Auto DevOpsは通常、継続的デプロイを使用し、新しいパイプラインがデフォルトブランチで実行されるたびに自動的にproduction環境にプッシュする。手動で本番環境にデプロイするには、STAGING_ENABLED CI/CD変数を使用できます。

STAGING_ENABLEDを設定すると、GitLabは自動的にアプリケーションをstaging環境にデプロイします。本番環境にデプロイする準備ができたら、GitLabはproduction_manualジョブを作成します。

また、プロジェクト設定で手動デプロイを有効にすることもできます。

カナリア環境のデプロイポリシー

本番環境に変更をデプロイする前に、カナリア環境を使用できます。

CANARY_ENABLEDを設定すると、GitLabは2つの手動ジョブを作成します:

• canary - アプリケーションをカナリア環境にデプロイします。
• production_manual - アプリケーションを本番環境にデプロイします。

本番環境へのインクリメンタルロールアウト

インクリメンタルロールアウトを使用して、少数のポッドから開始してアプリケーションを継続的にデプロイします。手動でポッドの数を増やすことができます。

プロジェクト設定で手動デプロイを有効にするか、INCREMENTAL_ROLLOUT_MODEをmanualに設定することで有効にできます。

INCREMENTAL_ROLLOUT_MODEをmanualに設定すると、GitLabは4つの手動ジョブを作成します:

1. rollout 10%
2. rollout 25%
3. rollout 50%
4. rollout 100%

このパーセンテージはREPLICAS CI/CD変数に基づいており、デプロイに使用されるポッドの数を定義します。たとえば、値が10で、10%ロールアウトジョブを実行すると、アプリケーションは1つのポッドのみにデプロイされます。

ロールアウトジョブは任意の順序で実行できます。スケールダウンするには、より低いパーセンテージのジョブを再実行します。

rollout 100%ジョブを実行した後、スケールダウンすることはできず、デプロイをロールバックする必要があります。

インクリメンタルロールアウトの設定例

INCREMENTAL_ROLLOUT_MODEなし、およびSTAGING_ENABLEDなし:

INCREMENTAL_ROLLOUT_MODEなし、STAGING_ENABLEDあり:

INCREMENTAL_ROLLOUT_MODEをmanualに設定し、STAGING_ENABLEDなし:

INCREMENTAL_ROLLOUT_MODEをmanualに設定し、STAGING_ENABLEDあり:

本番環境への時間指定インクリメンタルロールアウト

時間指定インクリメンタルロールアウトを使用して、少数のポッドから開始してアプリケーションを継続的にデプロイします。

プロジェクト設定で時間指定インクリメンタルデプロイを有効にするか、INCREMENTAL_ROLLOUT_MODE CI/CD変数をtimedに設定することで有効にできます。

INCREMENTAL_ROLLOUT_MODEをtimedに設定すると、GitLabは4つのジョブを作成します:

1. timed rollout 10%
2. timed rollout 25%
3. timed rollout 50%
4. timed rollout 100%

ジョブ間に5分間の遅延があります。