Auto DevOpsのカスタマイズ

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

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

カスタムbuildpack 、Dockerfile 、およびHelm Chartを追加します。
カスタムCI/CD構成で、ステージング環境とカナリアデプロイを有効にします。
GitLab APIを使用してAuto DevOpsを拡張します。

Auto DevOpsが有効になっていない場合、メンテナーロール以上のユーザーにはバナーが表示されます:

バナーは以下の場合に無効にできます:

ユーザーが自分で無視した場合。
プロジェクトで、明示的にAuto DevOpsを無効にする場合。
GitLabインスタンス全体:
- Railsコンソールで以下を実行することで、管理者が無効にする場合:
```
Feature.enable(:auto_devops_banner_disabled)
```
- 管理者アクセストークンを使用してREST APIから実行する場合:
```
curl --data "value=true" --header "PRIVATE-TOKEN: <personal_access_token>" "https://gitlab.example.com/api/v4/features/auto_devops_banner_disabled"
```

カスタムbuildpacks

buildpacksは、次の場合にカスタマイズできます:

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

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

以下を指定します:

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

複数のbuildpacks

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

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

カスタムDockerfiles

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

DOCKERFILE_PATHCI/CD変数を設定すると、Autoビルドは代わりにそこにDockerfileを探します。

`docker build`に引数を渡す

AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGSプロジェクトCI/CD変数を使用して、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ビルドの引数として渡さないでください。シークレットがイメージに残る可能性があります。詳細については、シークレットに関するベストプラクティスのこのディスカッションを参照してください。

コンテナイメージのカスタマイズ

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

エントリ	デフォルト	オーバーライドできる対象
イメージパス	ブランチパイプラインの場合は`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`。タグ付けパイプラインの場合は`$CI_REGISTRY_IMAGE`。	`$CI_APPLICATION_REPOSITORY`
イメージタグ	ブランチパイプラインの場合は`$CI_COMMIT_SHA`。タグ付けパイプラインの場合は`$CI_COMMIT_TAG`。	`$CI_APPLICATION_TAG`

これらの変数は、自動ビルドと自動コンテナスキャンにも影響します。イメージを$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>

APIによるAuto DevOpsの拡張

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 Chart

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

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

Helm Chartの値のカスタマイズ

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

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

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

`helm upgrade`のカスタマイズ

自動デプロイイメージは、helm upgradeコマンドを使用します。このコマンドをカスタマイズするには、HELM_UPGRADE_EXTRA_ARGS CI/CD変数を使用してオプションを渡します。

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

variables:
  HELM_UPGRADE_EXTRA_ARGS: --no-hooks

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

1つの環境にHelm Chartを制限する

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

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

Auto DevOpsは高度にカスタマイズ可能です。Auto DevOpsテンプレートは、.gitlab-ci.ymlファイルの実装であるためです。このテンプレートは、.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内の各ジョブに必要なステージも必ず定義してください。

たとえば、自動ビルドを使用するには、次の内容を.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からはデフォルトではなくなります。PostgreSQLデータベースのプロビジョニングを有効にするには、関連付けられているCI/CD変数を設定します。

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

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

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

PostgreSQLのアップグレード

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

以前のチャートバージョンを使用している場合は、PostgreSQLデータベースを移行する必要があります新しい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変数を、アプリケーションで利用可能な環境スコープの変数として定義します。これは、次の形式のURIである必要があります:
```
postgres://user:password@postgres-host:postgres-port/postgres-database
```
Kubernetesクラスタリングが、PostgreSQLがホストされている場所にネットワークアクセスできることを確認します。