• ビルドとデプロイの変数
• データベース変数
• ジョブを無効にする変数
• アプリケーション秘密変数の設定
  • Kubernetesのシークレット
• アプリケーションのシークレットを更新
• レプリカ変数の設定
  • カスタムレプリカ変数
• ステージ環境と本番環境へのデプロイポリシー
• カナリア環境へのデプロイポリシー
• 本番環境への増分ロールアウト
  • 増分ロールアウトの設定例
• 本番環境への時間差ロールアウト

CI/CD 変数

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

ビルドとデプロイの変数

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

データベース変数

PostgreSQLデータベースとCI/CDをインテグレーションするには、これらの変数を使用してください。

ジョブを無効にする変数

CI/CDジョブを無効にするにはこれらの変数を使います。

アプリケーション秘密変数の設定

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

前提条件

• 変数値は1行であること。

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

1. 左のサイドバーで「検索」または「移動」を選択してあなたのプロジェクトを検索します。
2. Settings > CI/CDを選択します。
3. 変数]を展開します。
4. K8S_SECRET_という接頭辞を持つ CI/CD 変数を作成します。例えば、K8S_SECRET_RAILS_MASTER_KEY という変数を作成します。
5. 手動で新しいパイプラインを作成するか、GitLabにコード変更をプッシュすることで、Auto DevOpsパイプラインを実行します。

Kubernetesのシークレット

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ポッドでは環境変数は一般的に不変です。アプリケーションシークレットを更新してから手動で新しいパイプラインを作成すると、実行中のアプリケーションは更新されたシークレットを受信しません。

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

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

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

レプリカ変数の設定

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

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

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

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

カスタムレプリカ変数

カスタムレプリカ変数は<TRACK>_<ENV>_REPLICAS という形式で作成することができます：

• <TRACK> は、track Helm Chartアプリ定義で設定したKubernetesラベルの track全角値です。設定されていないtrack 場合は track、 <TRACK>カスタム変数から<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% rollout ジョブを実行した場合、アプリケーションは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分間の遅延があります。