Auto DevOpsをカスタマイズ
- プラン: Free、Premium、Ultimate
- 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated
Auto DevOpsのコンポーネントは、必要に応じてカスタマイズできます。たとえば、次のことができます:
- カスタムビルドパック、Dockerfiles、およびHelmチャートを追加します。
- カスタムCI/CD設定を使用して、ステージングおよびカナリアデプロイを有効にします。
- Auto DevOpsをGitLab APIで拡張します。
カスタムビルドパック
次のいずれかの場合に、ビルドパックをカスタマイズできます:
- 自動ビルドパック検出がプロジェクトで失敗する場合。
- ビルドに対するより多くの制御が必要な場合。
Cloud Native Buildpacksを使用してビルドパックをカスタマイズ
次のいずれかを指定します:
- CI/CD変数
BUILDPACK_URLに、packのURI仕様形式のいずれかを指定します。 - 含めるビルドパックを持つ
project.tomlプロジェクト記述子。
複数のビルドパック
Auto Testが.buildpacksファイルを使用できないため、Auto DevOpsは複数のビルドパックをサポートしていません。バックエンドで.buildpacksファイルを解析するために使用されるビルドパックheroku-buildpack-multiは、必要なコマンドbin/test-compileとbin/testを提供しません。
単一のカスタムビルドパックのみを使用するには、代わりにプロジェクトCI/CD変数BUILDPACK_URLを指定する必要があります。
カスタムDockerfiles
プロジェクトのリポジトリのルートにDockerfileがある場合、Auto DevOpsはDockerfileに基づいてDockerイメージをビルドします。これは、ビルドパックを使用するよりも高速です。特にDockerfileがalpineに基づいている場合、より小さなイメージになる可能性もあります。
DOCKERFILE_PATH CI/CD変数を設定すると、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ビルドの引数としてシークレットを渡さないでください。シークレットはイメージ内に永続化する可能性があります。詳細については、シークレットに関するベストプラクティスのこのディスカッションを参照してください。
カスタムコンテナイメージ
デフォルトでは、自動デプロイは、自動ビルドによってビルドされ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>Auto DevOpsをAPIで拡張
Auto DevOpsの設定をGitLab APIで拡張および管理できます:
- 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ビルドパックを使用する場合、転送された変数は環境変数として自動的に利用可能です。
Dockerfileを使用する場合:
実験的なDockerfile構文を有効にするには、次の内容をDockerfileに追加します:
# syntax = docker/dockerfile:experimentalDockerfile内のいずれかの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チャートを上書きできます:
バンドルされたチャート - プロジェクトに
./chartディレクトリがあり、その中にChart.yamlファイルがある場合、Auto DevOpsはチャートを検出し、デフォルトチャートの代わりに使用します。プロジェクト変数 - カスタムチャートのURLでプロジェクトCI/CD変数
AUTO_DEVOPS_CHARTを作成します。さらに5つのプロジェクト変数を作成できます:AUTO_DEVOPS_CHART_REPOSITORY- カスタムチャートリポジトリのURL。AUTO_DEVOPS_CHART- チャートへのパス。AUTO_DEVOPS_CHART_REPOSITORY_INSECURE- 空ではない値に設定すると、--insecure-skip-tls-verify引数がHelmコマンドに追加されます。AUTO_DEVOPS_CHART_CUSTOM_ONLY- カスタムチャートのみを使用するように空ではない値に設定します。デフォルトでは、最新のチャートがGitLabからダウンロードされます。AUTO_DEVOPS_CHART_VERSION- デプロイチャートのバージョン。
PostgreSQL Helmチャートの値のカスタマイズ
デフォルトHelmチャートのvalues.yamlファイル内のデフォルト値を上書きするには、次のいずれかの方法を使用します:
- ファイル
.gitlab/auto-deploy-values.yamlをリポジトリに追加します。このファイルは、Helmアップグレードでデフォルトで使用されます。 - 異なる名前またはパスのファイルをリポジトリに追加します。ファイルのパスと名前を持つ
HELM_UPGRADE_VALUES_FILECI/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つの環境に制限するには、環境スコープを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ファイルで定義してください。
例えば、自動ビルドを使用するには、次の内容を.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はデフォルトでプロビジョニングされます。データベースにアクセスするための認証情報は事前に設定されています。
認証情報をカスタマイズするには、関連するCI/CD変数を設定します。カスタムDATABASE_URLも定義できます:
postgres://user:password@postgres-host:postgres-port/postgres-databasePostgreSQLのアップグレード
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チャートの値のカスタマイズ
カスタム値を設定するには、次のいずれかを実行します:
- ファイル
.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がホストされている場所にネットワークアクセスできることを確認してください。