Auto DevOpsをカスタマイズ

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

Auto DevOpsのコンポーネントは、ニーズに合わせてカスタマイズできます。たとえば、次のことができます:

カスタムbuildpacks 、Dockerfiles 、およびHelmチャートを追加します。
カスタムCI/CD設定でステージングおよびカナリアデプロイを有効にします。
Auto DevOpsをGitLab APIで拡張します。

カスタムbuildpacks

buildpacksは、以下のいずれかの場合にカスタマイズできます:

プロジェクトの自動buildpack検出が失敗する場合。
ビルドをより細かく制御する必要がある場合。

Cloud Native Buildpacksを使用したbuildpacksのカスタマイズ

以下いずれかを指定します:

CI/CD変数BUILDPACK_URLに、packのURI仕様形式のいずれかを指定します。
含めるbuildpacksを指定したproject.tomlプロジェクト記述子。

複数buildpacks

Auto Testは.buildpacksファイルを使用できないため、Auto DevOpsは複数buildpacksをサポートしていません。buildpack heroku-buildpack-multiは、バックエンドで.buildpacksファイルを解析するために使用されますが、必要なコマンドbin/test-compileおよびbin/testを提供していません。

単一のカスタムbuildpackのみを使用する場合は、代わりにプロジェクトCI/CD変数BUILDPACK_URLを指定する必要があります。

カスタムDockerfiles

プロジェクトリポジトリのルートにDockerfileがある場合、Auto DevOpsはDockerfileに基づいてDockerイメージをビルドします。これはbuildpackを使用するよりも高速です。特にDockerfileがAlpineに基づいている場合は、より小さなイメージになることもあります。

CI/CD変数DOCKERFILE_PATHを設定すると、Auto Buildは代わりにその場所でDockerfileを探します。

`docker build`への引数渡し

CI/CD変数AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGSを使用して、docker buildに引数を渡すことができます。

たとえば、デフォルトのruby:latestではなく、ruby:alpineに基づいたDockerイメージをビルドするには:

AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGSを--build-arg=RUBY_VERSION=alpineに設定します。

カスタムDockerfileに以下を追加します:

ARG RUBY_VERSION=latest
FROM ruby:$RUBY_VERSION

# Include your content here

スペースや改行などの複雑な値を渡すには、Base64エンコードを使用します。複雑な未エンコードの値は、文字エスケープの問題を引き起こす可能性があります。

シークレットをDockerビルド引数として渡さないでください。シークレットがイメージに残る可能性があります。詳細については、シークレットに関するベストプラクティスの議論を参照してください。

カスタムコンテナイメージ

デフォルトでは、自動デプロイは、Auto BuildによってビルドされGitLabレジストリにプッシュされたコンテナイメージをデプロイします。特定の変数を定義することで、この動作をオーバーライドできます:

エントリ	デフォルト	オーバーライド元
イメージパス	`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`はブランチパイプライン用。`$CI_REGISTRY_IMAGE`はタグパイプライン用。	`$CI_APPLICATION_REPOSITORY`
イメージタグ	`$CI_COMMIT_SHA`はブランチパイプライン用。`$CI_COMMIT_TAG`はタグパイプライン用。	`$CI_APPLICATION_TAG`

これらの変数は、Auto Buildおよび自動コンテナスキャンにも影響します。$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAGにイメージをビルドおよびプッシュしたくない場合は、Jobs/Deploy.gitlab-ci.ymlのみを含めるか、buildジョブをスキップしてください。

自動コンテナスキャンを使用し、$CI_APPLICATION_REPOSITORYの値を設定した場合は、$CS_DEFAULT_BRANCH_IMAGEも更新する必要があります。詳細については、デフォルトブランチイメージの設定を参照してください。

.gitlab-ci.ymlにおける設定例を次に示します:

variables:
  CI_APPLICATION_REPOSITORY: <your-image-repository>
  CI_APPLICATION_TAG: <the-tag>

Auto DevOpsをAPIで拡張する

GitLab APIを使用して、Auto DevOpsの設定を拡張および管理できます:

APIコールで設定にアクセスします。auto_devops_enabledを含め、デフォルトでプロジェクトのAuto DevOpsを有効にします。
新規プロジェクトを作成します。
グループを編集します。
プロジェクトを編集します。

CI/CD変数をビルド環境に転送

CI/CD変数をビルド環境に転送するには、転送したい変数の名前をAUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES CI/CD変数に追加します。複数の変数はカンマで区切ります。

たとえば、変数CI_COMMIT_SHAとCI_ENVIRONMENT_NAMEを転送するには:

variables:
  AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES: CI_COMMIT_SHA,CI_ENVIRONMENT_NAME

buildpacksを使用する場合、転送された変数は環境変数として自動的に利用可能です。

Dockerfileを使用する場合:

実験的なDockerfile構文を有効にするには、Dockerfileに以下を追加します:
```
# syntax = docker/dockerfile:experimental
```
Dockerfile内のRUN $COMMANDでシークレットを利用可能にするには、シークレットファイルをマウントし、$COMMANDを実行する前にそれをソースとして読み込みます:
```
RUN --mount=type=secret,id=auto-devops-build-secrets . /run/secrets/auto-devops-build-secrets && $COMMAND
```

AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLESが設定されている場合、Auto DevOpsは実験的なDocker BuildKit機能で--secretフラグを使用できるようにします。

カスタムHelmチャート

Auto DevOpsは、Helmを使用してアプリケーションをKubernetesにデプロイします。プロジェクトリポジトリにチャートをバンドルするか、プロジェクトCI/CD変数を指定することで、使用されるHelmチャートをオーバーライドできます:

Bundled chart - プロジェクトに./chartディレクトリがあり、その中にChart.yamlファイルがある場合、Auto DevOpsはチャートを検出して、デフォルトチャートの代わりに使用します。
Project variable - カスタムチャートのURLを指定して、プロジェクトCI/CD変数 AUTO_DEVOPS_CHARTを作成します。また、5つのプロジェクト変数を作成できます:
- AUTO_DEVOPS_CHART_REPOSITORY - カスタムチャートリポジトリのURL。
- AUTO_DEVOPS_CHART - チャートへのパス。
- AUTO_DEVOPS_CHART_REPOSITORY_INSECURE - 空でない値を設定すると、Helmコマンドに--insecure-skip-tls-verify引数が追加されます。
- AUTO_DEVOPS_CHART_CUSTOM_ONLY - 空でない値を設定すると、カスタムチャートのみが使用されます。デフォルトでは、最新のチャートはGitLabからダウンロードされます。
- AUTO_DEVOPS_CHART_VERSION - デプロイチャートのバージョン。

Helmチャートの値のカスタマイズ

デフォルトHelmチャートのvalues.yamlファイルにあるデフォルト値をオーバーライドするには、以下のいずれかを実行します:

.gitlab/auto-deploy-values.yamlという名前のファイルをリポジトリに追加します。このファイルはデフォルトでHelmアップグレードに使用されます。
別の名前またはパスのファイルをリポジトリに追加します。ファイルのパスと名前を指定して、HELM_UPGRADE_VALUES_FILE CI/CD変数を設定します。

一部の値は上記のオプションではオーバーライドできませんが、このイシューでこの動作を変更する提案がされています。replicaCountのような設定をオーバーライドするには、REPLICAS ビルドおよびデプロイ CI/CD変数を使用します。

`helm upgrade`をカスタマイズ

auto-deploy-imageはhelm upgradeコマンドを使用します。このコマンドをカスタマイズするには、HELM_UPGRADE_EXTRA_ARGS CI/CD変数でオプションを渡します。

たとえば、helm upgradeの実行時にアップグレード前後のフックを無効にするには:

variables:
  HELM_UPGRADE_EXTRA_ARGS: --no-hooks

オプションの完全なリストについては、公式helm upgradeドキュメントを参照してください。

Helmチャートを1つの環境に制限する

カスタムチャートを1つの環境に制限するには、環境スコープをCI/CD変数に追加します。詳細については、CI/CD変数の環境スコープを制限を参照してください。

`.gitlab-ci.yml`をカスタマイズ

Auto DevOpsテンプレートは.gitlab-ci.ymlファイルの実装であるため、Auto DevOpsは高度にカスタマイズ可能です。このテンプレートは、.gitlab-ci.ymlの任意の実装で利用可能な機能のみを使用します。

Auto DevOpsが使用するCI/CDパイプラインにカスタム動作を追加するには:

リポジトリのルートに、次の内容を含む.gitlab-ci.ymlファイルを追加します:
```
include:
  - template: Auto-DevOps.gitlab-ci.yml
```
.gitlab-ci.ymlファイルに変更を追加します。変更はAuto DevOpsテンプレートにマージされます。詳細については、includeが変更をマージする方法に関するincludeドキュメントを参照してください。

Auto DevOpsパイプラインから動作を削除するには:

Auto DevOpsテンプレートをプロジェクトにコピーします。
必要に応じて、テンプレートのコピーを編集します。

Auto DevOpsの個々のコンポーネントを使用する

Auto DevOpsが提供する機能の一部のみが必要な場合は、個々のAuto DevOpsジョブを独自の.gitlab-ci.ymlに含めることができます。各ジョブに必要なパイプラインステージも.gitlab-ci.ymlファイルで定義してください。

たとえば、Auto Buildを使用するには、.gitlab-ci.ymlに以下を追加します:

stages:
  - build

include:
  - template: Jobs/Build.gitlab-ci.yml

利用可能なジョブのリストについては、Auto DevOpsテンプレートを参照してください。

複数のKubernetesクラスターを使用する

Auto DevOps用の複数のKubernetesクラスターを参照してください。

Kubernetesネームスペースのカスタマイズ

GitLab 14.5および以前では、environment:kubernetes:namespaceを使用して環境のネームスペースを指定できました。しかし、この機能は証明書ベースのインテグレーションとともに非推奨となりました。

現在は、KUBE_NAMESPACE環境変数を使用し、その環境スコープを制限する必要があります。

ローカルDockerレジストリでホストされているイメージを使用する

多くのAuto DevOpsジョブをオフライン環境で実行するように設定できます:

必要なAuto DevOps DockerイメージをDocker Hubおよびregistry.gitlab.comからローカルのGitLabコンテナレジストリにコピーします。

イメージがローカルレジストリでホストされ利用可能になったら、.gitlab-ci.ymlを編集してローカルでホストされているイメージを指すようにします。例:

include:
  - template: Auto-DevOps.gitlab-ci.yml

variables:
  REGISTRY_URL: "registry.gitlab.example"

build:
  image: "$REGISTRY_URL/docker/auto-build-image:v0.6.0"
  services:
    - name: "$REGISTRY_URL/greg/docker/docker:20.10.16-dind"
      command: ['--tls=false', '--host=tcp://0.0.0.0:2375']

PostgreSQLデータベースのサポート

デフォルトでのPostgreSQLデータベースのプロビジョニングは、GitLab 15.8で非推奨となり、16.0以降ではデフォルトではなくなります。データベースのプロビジョニングを有効にするには、関連するCI/CD変数を設定します。

データベースを必要とするアプリケーションをサポートするため、PostgreSQLはデフォルトでプロビジョニングされます。データベースにアクセスするための認証情報は事前設定されています。

認証情報をカスタマイズするには、関連するCI/CD変数を設定します。カスタムDATABASE_URLを定義することもできます:

postgres://user:password@postgres-host:postgres-port/postgres-database

PostgreSQLのアップグレード

GitLabは、チャートバージョン8.2.1を使用して、デフォルトでPostgreSQLをプロビジョニングします。バージョンは0.7.1から8.2.1まで設定できます。

以前のチャートバージョンを使用している場合は、データベースを新しいPostgreSQLに移行する必要があります。

デフォルトでプロビジョニングされたPostgreSQLを制御するCI/CD変数AUTO_DEVOPS_POSTGRES_CHANNELは、GitLab 13.0で2に変更されました。以前のPostgreSQLを使用するには、AUTO_DEVOPS_POSTGRES_CHANNEL変数を1に設定します。

PostgreSQL Helm Chartの値のカスタマイズ

カスタム値を設定するには、以下のいずれかを実行します:

.gitlab/auto-deploy-postgres-values.yamlという名前のファイルをリポジトリに追加します。見つかった場合、このファイルは自動的に使用されます。このファイルはデフォルトでPostgreSQL Helmアップグレードに使用されます。
異なる名前またはパスのファイルをリポジトリに追加し、ファイルのパスと名前を指定してPOSTGRES_HELM_UPGRADE_VALUES_FILE 環境変数を設定します。
POSTGRES_HELM_UPGRADE_EXTRA_ARGS 環境変数を設定します。

外部PostgreSQLデータベースプロバイダーを使用する

Auto DevOpsは、本番環境向けのPostgreSQLコンテナの標準サポートを提供します。ただし、AWS Relational Database Serviceのような外部マネージドプロバイダーを使用したい場合もあります。

外部マネージドプロバイダーを使用するには:

必須の環境に対して、環境スコープのCI/CD変数を使用して、組み込みのPostgreSQLインストールを無効にします。レビューアプリとステージングの組み込みPostgreSQLセットアップで十分であるため、productionのインストールのみを無効にする必要がある場合があります。
DATABASE_URL変数を、アプリケーションで利用可能な環境スコープ変数として定義します。これは、次の形式のURLである必要があります:
```
postgres://user:password@postgres-host:postgres-port/postgres-database
```
KubernetesクラスターがPostgreSQLがホストされている場所にネットワークアクセスできることを確認してください。