自動DevOpsのカスタマイズ

ニーズに合わせてAuto DevOpsのコンポーネントをカスタマイズできます。例えば、以下のことが可能です：

Auto DevOpsのバナー

Auto DevOpsが有効でない場合、少なくともメンテナーのロールを持つユーザーにはバナーが表示されます：

Auto DevOps banner

このバナーは、以下の場合に無効にすることができます：

  • ユーザー自身がバナーを解除した場合。
  • プロジェクトは、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"

カスタムビルドパック

ビルドパックをカスタマイズすることができます：

  • ビルドパックの自動検出がプロジェクトで失敗した場合。
  • ビルドをもっとコントロールする必要があります。

Cloud Native Buildpacksでビルドパックをカスタマイズ

GitLab 12.10で導入されました。

どちらかを指定してください：

Herokuish によるビルドパックのカスタマイズ (非推奨)

caution
HerokuishのサポートはGitLab 15.8で非推奨となり、17.0で削除される予定です。代わりにCloud Native Buildpacksを使用してください。

どちらかを指定してください：

  • CI/CD 変数BUILDPACK_URL 。
  • プロジェクトのルートにある.buildpacks ファイルで、1 行に 1 つの buildpack URL を含みます。

buildpack URL は Git リポジトリの URL か tarball の URL を指します。

Git リポジトリの場合は、Git リポジトリの URL に#<ref> を追加することで、特定の Git リファレンスを指定できます。例えば

  • タグv142:https://github.com/heroku/heroku-buildpack-ruby.git#v142.
  • ブランチmybranch:https://github.com/heroku/heroku-buildpack-ruby.git#mybranch.
  • コミット SHAf97d8a8ab49:https://github.com/heroku/heroku-buildpack-ruby.git#f97d8a8ab49.

複数のビルドパック

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

単一のカスタムbuildpackのみを使用するには、代わりにプロジェクトCI/CD変数BUILDPACK_URL 。

カスタムDockerfile

DOCKERFILE_PATH GitLab 13.2で導入されました。

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

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

引数をdocker build

AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS project CI/CD 変数でdocker build に引数を渡すことができます。

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

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

  2. カスタムDockerfileに以下を追加します：

    ARG RUBY_VERSION=latest
FROM ruby:$RUBY_VERSION
   
# ... put your stuff here

スペースや改行のような複雑な値を渡すには、Base64エンコーディングを使用してください。エンコードされていない複雑な値は、文字エスケープでイシューを引き起こす可能性があります。

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

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

デフォルトでは、Auto Deployは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 と Auto Container Scanning にも影響します。イメージをビルドして$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の設定を拡張・管理することができます：

CI/CD 変数をビルド環境に転送します。

GitLab 12.3 で導入されました。

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を使用する場合：

  1. 実験的なDockerfile構文を有効にするには、Dockerfileに以下を追加してください：

    # syntax = docker/dockerfile:experimental

  2. 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は--secret フラグを使用する実験的なDocker BuildKit機能を有効にします。

カスタムHelmチャート

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

  • バンドルされたチャート- プロジェクト内にChart.yaml ファイルを含む./chart ディレクトリがある場合、Auto DevOps はそのチャートを検出し、デフォルトのチャートの代わりに使用します。

  • プロジェクト変数- カスタムチャートの URL でプロジェクト CI/CD 変数 AUTO_DEVOPS_CHART を作成します。2つのプロジェクト変数を作成することもできます：

    • AUTO_DEVOPS_CHART_REPOSITORY - カスタムチャートリポジトリのURL。
    • AUTO_DEVOPS_CHART - Chartへのパス。

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

GitLab 12.6 で導入された .gitlab/auto-deploy-values.yaml は、Helm のアップグレードにデフォルトで使用されます。

デフォルトの Helm Chart でvalues.yaml ファイルのデフォルト値を上書きするには、次のどちらかを実行します：

  • .gitlab/auto-deploy-values.yaml という名前のファイルをリポジトリに追加します。このファイルは自動的に使用されます。
  • リポジトリに別の名前やパスのファイルを追加します。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パイプラインにカスタムビヘイビアを追加するには：

  1. リポジトリのルートに、以下の内部を持つ.gitlab-ci.yml ファイルを追加します：

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

  2. .gitlab-ci.yml ファイルに変更を追加します。あなたの変更が Auto DevOps テンプレートにマージされます。include が変更をマージする方法の詳細については、 include ドキュメント を参照してください。

Auto DevOpsパイプラインからビヘイビアを削除するには：

  1. AutoDevOpsテンプレートをプロジェクトにコピーします。
  2. 必要に応じてテンプレートのコピーを編集します。

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テンプレートを参照してください。

caution
GitLab 13.0以降、only またはexcept 構文を使用するAuto DevOpsテンプレートは、rules 構文に切り替わりました。.gitlab-ci.yml がこれらの Auto DevOps テンプレートを拡張し、only またはexceptをオーバーライドする場合は、rules 構文にテンプレートをマイグレーションしてください。マイグレーションできない場合は、テンプレートを](../../ci/yaml/index.md#only–except)GitLab 12.10ベースのテンプレートに](../../ci/yaml/index.md#only–except)固定することができます。

複数のKubernetesクラスターの使用

自動DevOpsのための複数のKubernetesクラスタを参照してください。

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

GitLab 14.5以前では、environment:kubernetes:namespace を使って環境の名前空間を指定することができました。しかし、この機能は証明書ベースのインテグレーションとともに非推奨となりました。

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

ローカルのDockerレジストリにホストされたイメージを使用します。

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

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

  2. イメージがホストされ、ローカルのレジストリで利用できるようになったら、.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 データベースのサポート

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

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

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

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

PostgreSQLのアップグレード

GitLabはデフォルトでChartバージョン8.2.1を使ってPostgreSQLをプロビジョニングします。バージョンを0.7.1から8.2.1に設定することができます。

古いバージョンのChartを使用している場合は、データベースを新しいPostgreSQLにマイグレーションする必要があります。

デフォルトでプロビジョニングされた PostgreSQL をコントロールする CI/CD 変数AUTO_DEVOPS_POSTGRES_CHANNEL は、GitLab 13.0で2 に変更されました。古い PostgreSQL を使うには、AUTO_DEVOPS_POSTGRES_CHANNEL 変数を1に設定してください。

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

GitLab 13.8 の auto-deploy-image v2 で導入されました。

カスタム値を設定するには、次のいずれかを行います：

  • .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のような外部のマネージドプロバイダを使用したい場合もあるでしょう。

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

  1. 必要な環境の組み込みPostgreSQLインストールを、環境スコープのCI/CD変数で無効にします。レビューアプリとステージング用のビルトインPostgreSQLセットアップで十分なので、production のインストールを無効にするだけでよいかもしれません。

    Auto Metrics

  2. DATABASE_URL 変数をアプリケーションで利用可能な環境変数として定義してください。これは以下の形式の URL でなければなりません：

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

  3. Kubernetesクラスタが、PostgreSQLがホストされている場所にネットワークアクセスできることを確認してください。