自動DevOpsのステージ

以下のセクションでは、AutoDevOpsのステージについて説明します。それぞれがどのように機能するかを理解するために、注意深く読んでください。

自動ビルド

note
OpenShiftクラスタのように、DockerのDockerがGitLab Runnerで利用できない場合、Auto Buildはサポートされません。GitLabのOpenShiftサポートは専用のエピックで追跡されています。

Auto Buildは、既存のDockerfile または Heroku buildpacksを使用してアプリケーションのビルドを作成します。出来上がったDockerイメージはコンテナレジストリにプッシュされ、コミットSHAまたはタグでタグ付けされます。

Dockerfileを使った自動ビルド

プロジェクトのリポジトリにDockerfile がルートに含まれている場合、Auto Build はdocker build を使って Docker イメージを作成します。

Auto Review AppsとAuto Deployも使用していて、独自のDockerfile を提供する場合は、以下のいずれかを行う必要があります:

クラウドネイティブビルドパックを使用した自動ビルド

  • GitLab 12.10で導入されました
  • デフォルトでCloud Native Buildpacksを使用した自動ビルドがGitLab 14.0で導入れました。

Auto Buildはプロジェクトが存在するDockerfile 場合、 Dockerfileそのプロジェクトを使ってアプリケーションをビルドします。存在Dockerfile しない場合 Dockerfile、Auto BuildはCloudNative Buildpacksを使ってアプリケーションを検出し、Dockerイメージにビルドします。この機能はpack コマンドを使用します。デフォルトのビルダーは heroku/buildpacks:18 ですが、CI/CD 変数AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDERを使用して別のビルダーを選択できます。

各ビルドパックでは、Auto Buildがアプリケーションを正常にビルドするために、プロジェクトのリポジトリに特定のファイルが含まれている必要があります。その構造は、選択したビルダーとビルドパックに固有です。例えば、Herokuビルダー(デフォルト)を使用する場合、アプリケーションのルートディレクトリには、アプリケーションの言語に適したファイルが含まれている必要があります:

  • Python プロジェクトの場合は、Pipfile またはrequirements.txt ファイルです。
  • Rubyプロジェクトの場合は、Gemfile またはGemfile.lock ファイル。

その他の言語やフレームワークの要件については、Heroku buildpacks documentationを参照してください。

note
テストスイートの検出はまだCloud Native Buildpackの仕様の一部ではないため、Auto TestはまだHerokuishを使用しています。詳細はイシュー212689を参照してください。

ビルドコンテナへのボリュームのマウント

  • GitLab 14.2で導入されました
  • マルチボリュームのサポート(またはauto-build-image v1.6.0)がGitLab 14.6で導入れました。

変数BUILDPACK_VOLUMES を使って、ボリュームマウント定義をpack コマンドに渡すことができます。マウントは--volume 引数を使ってpack build に渡されます。各ボリューム定義には、ホストパス、ターゲットパス、書き込み可能かどうか、1つ以上のボリュームオプションなど、build pack が提供する機能を含めることができます。

複数のボリュームを渡すには、パイプ(| )を使用します。リストの各項目は、個別の--volume 引数を使用してbuild back に渡されます。

この例では、3 つのボリュームが/etc/foo/opt/foo/var/opt/foo としてコンテナにマウントされています:

buildjob:
  variables:
    BUILDPACK_VOLUMES: /mnt/1:/etc/foo:ro|/mnt/2:/opt/foo:ro|/mnt/3:/var/opt/foo:rw

ボリュームの定義の詳細については、pack build ドキュメントを参照してください。

Herokuishを使った自動ビルド(非推奨)

GitLab 14.0のCloud Native Buildpacksに置き換えられました

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

GitLab 14.0以前では、Herokuishは Dockerfile がないプロジェクトのデフォルトのビルド方法でした。 Herokuishは、CI/CD変数AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLEDfalse に設定することで、まだ使うことができます。

note
プロジェクトが buildpack の要件を満たしているにもかかわらず Auto Build が失敗した場合は、プロジェクトの CI/CD 変数TRACE=true を設定して、冗長ロギングを有効にしてください。

Heroku から Cloud Native ビルドパックへの移行

Cloud Native Buildpacksを使ったビルドは、以下の注意点を除き、Herokuishを使ったビルドと同じオプションをサポートしています:

  • ビルドパックはCloud Native Buildpackでなければなりません。Herokuのビルドパックは、Herokuのcnb-shimを使用してCloud Native Buildpackに変換できます。
  • BUILDPACK_URLpack](https://buildpacks.io/docs/app-developer-guide/specify-buildpacks/) でサポートされているフォーマット[でなければなりません。
  • ビルドされたイメージには/bin/herokuish コマンドが存在せず、コマンドの前に/bin/herokuish procfile exec を付ける必要がなくなりました(不可能でもありません)。その代わりに、カスタムコマンドは正しい実行環境を得るために、/cnb/lifecycle/launcher を先頭に付ける必要があります。

自動テスト (非推奨)

caution
HerokuishのサポートはGitLab 15.8で非推奨となり、17.0で削除される予定です。Auto TestはHerokuishを使用しているため、Auto Testも非推奨です。

Auto TestはHerokuishと Heroku buildpacksを使用して、プロジェクトを分析して言語とフレームワークを検出することで、アプリケーションに適切なテストを実行します。いくつかの言語とフレームワークは自動的に検出されますが、言語が検出されない場合は、カスタムビルドパックを作成することができます。現在サポートされている言語を確認してください。

Auto Test は、アプリケーションにすでにあるテストを使用します。テストがない場合、追加するかどうかはあなた次第です。

note
Auto Buildでサポートされているすべてのビルドパックが Auto Test でサポートされているわけではありません。Auto Test は Cloud Native Buildpacksではなく HerokuishBuildpacks を使用し、Testpack APIを実装したビルドパックのみをサポートします。

現在サポートされている言語

Auto Testは比較的新しい機能拡張なので、まだすべてのビルドパックが対応しているわけではありません。Herokuが公式にサポートしている言語はすべてAuto Testをサポートしています。HerokuのHerokuishビルドパックでサポートされている言語はすべてAuto Testをサポートしていますが、特にマルチビルドパックはサポートしていません。

サポートされているビルドパックは以下のとおりです:

- heroku-buildpack-multi
- heroku-buildpack-ruby
- heroku-buildpack-nodejs
- heroku-buildpack-clojure
- heroku-buildpack-python
- heroku-buildpack-java
- heroku-buildpack-gradle
- heroku-buildpack-scala
- heroku-buildpack-play
- heroku-buildpack-php
- heroku-buildpack-go
- buildpack-nginx

上記のリストにないビルドパックが必要な場合は、カスタムビルドパックを使用するとよいでしょう。

自動コード品質

13.2でGitLab StarterからGitLab Freeに移行しました。

Auto Code QualityはCode Qualityイメージを使って、現在のコードに対して静的解析やその他のコードチェックを実行します。レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトできます。マージリクエストウィジェットは、ソースブランチとターゲットブランチ間の差分も表示します。

自動 SAST

  • GitLab Ultimate10.3から導入されました。
  • 13.1から全階層で利用可能になった機能。

Static Application Security Testing(SAST) 現在のコードの静的解析を実行し、潜在的なセキュリティのイシューをチェックします。Auto SASTステージには、GitLab Runner11.5以上が必要です。

レポートを作成した後、後でダウンロードしてチェックアウトできるアーティファクトとしてアップロードされます。マージリクエストウィジェットは、Ultimateライセンスのセキュリティ警告も表示します。

詳細については、静的アプリケーションセキュリティテスト(SAST) を参照してください。

自動シークレット検出

Secret DetectionはSecret Detection Dockerイメージを使って現在のコードに対してSecret Detectionを実行し、漏れたシークレットをチェックします。Auto Secret DetectionにはGitLab Runner11.5以上が必要です。

レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードして評価することができます。マージリクエストウィジェットは、Ultimateライセンスのセキュリティ警告も表示します。

詳細については、シークレット検出を参照してください。

自動依存関係スキャン

Dependency Scanningはプロジェクトの依存関係を分析し、潜在的なセキュリティ問題をチェックします。Ultimate以外のライセンスでは自動依存関係スキャンのステージはスキップされ、GitLab Runner11.5以上が必要です。

レポートの作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトすることができます。マージリクエストウィジェットには、検出されたセキュリティ警告が表示されます、

詳細については、「依存関係のスキャン」を参照してください。

自動ライセンスコンプライアンス(非推奨)

この機能はGitLab 15.9で非推奨となり、GitLab 16.3ではライセンスコンプライアンスレポートのサポートを削除しました。自動ライセンスコンプライアンスはまだパイプラインに存在しますが、結果は出力されません。

代わりにAuto Dependency Scanningを使ってください。

コンテナの自動スキャン

コンテナ用の脆弱性静的解析は、Dockerイメージの潜在的なセキュリティ問題をチェックするためにTrivyを使用します。Ultimate以外のライセンスでは、Auto Container Scanningステージはスキップされます。

レポート作成後、アーティファクトとしてアップロードされ、後でダウンロードしてチェックアウトできます。マージリクエストは検出されたセキュリティ問題を表示します。

詳細については、コンテナスキャンを参照してください。

自動レビューアプリ

多くのプロジェクトではKubernetesクラスターが利用できないため、これはオプションのステップです。要件が満たされない場合、ジョブは静かにスキップされます。

レビューアプリはブランチのコードに基づいた一時的なアプリケーション環境であり、開発者、デザイナー、QA、プロダクトマネージャー、その他のレビュアーがレビュープロセスの一環としてコードの変更を実際に見て操作できるようにします。自動レビューアプリはブランチごとにレビューアプリを作成します。

Auto Review AppsはアプリケーションをKubernetesクラスターにのみデプロイします。クラスターがない場合はデプロイは行われません。

レビューアプリには、プロジェクトID、ブランチまたはタグ名、一意の番号、およびAuto DevOpsのベースドメイン(13083-review-project-branch-123456.example.com など)の組み合わせに基づく一意のURLがあります。マージリクエストウィジェットには、レビューアプリへのリンクが表示され、簡単に発見できます。マージリクエストをマージした後など、ブランチやタグが削除されると、レビューアプリも削除されます。

レビューアプリは、カスタマイズできる Helm のauto-deploy-appチャートを使ってデプロイされます。アプリケーションは環境のKubernetes名前空間にデプロイされます。

GitLab 11.4以降では、ローカルのTillerが使用されます。以前のバージョンのGitLabでは、プロジェクトのネームスペースにTillerがインストールされていました。

caution
アプリはHelmの外部で(Kubernetesを直接使って)操作しないでください。これは、Helmが変更を検出せず、その後のAuto DevOpsによるデプロイで変更が元に戻されるなどの混乱を引き起こす可能性があります。また、何かを変更して再度デプロイすることで元に戻したい場合、Helmは最初に何かが変更されたことを検出しないため、古い設定を再適用する必要があることに気づかない可能性があります。

自動DAST

Dynamic Application Security Testing(DAST) は、人気の高いオープンソースツールOWASP ZAProxyを使用して、現在のコードを分析し、潜在的なセキュリティ問題をチェックします。Ultimate以外のライセンスでは、Auto DASTステージはスキップされます。

  • デフォルトのブランチでは、ターゲットブランチを上書きしない限り、DAST はその目的専用にデプロイされたアプリケーションをスキャンします。アプリは、DAST の実行後に削除されます。
  • 機能ブランチでは、DAST はレビューアプリをスキャンします。

DAST スキャンが完了すると、セキュリティ警告がセキュリティダッシュボードとマージリクエストウィジェットに表示されます。

詳細については、動的アプリケーションセキュリティテスト(DAST) を参照してください。

DAST ターゲットのオーバーライド

自動デプロイされたレビューアプリの代わりにカスタムターゲットを使用するには、DAST_WEBSITE CI/CD変数をDASTがスキャンするURLに設定します。

caution
DAST Full Scanが有効になっている場合、GitLab は** をステージング環境や本番環境に設定しないことを強くお勧めします。DAST Full Scanはターゲットを積極的に攻撃するため、アプリケーションをダウンさせたり、データの損失や破損につながる可能性があります。

自動DASTの無効化

DASTを無効にすることができます:

  • DAST_DISABLED CI/CD 変数を"true"に設定することで、すべてのブランチで DAST: を無効にできます。
  • DAST_DISABLED_FOR_DEFAULT_BRANCH 変数を"true"に設定することで、デフォルトブランチでのみ使用できます。
  • REVIEW_DISABLED 変数を"true"に設定することで、フィーチャーブランチでのみ使用できます。 これはレビューアプリも無効にします。

自動ブラウザのパフォーマンステスト

GitLab 10.4から導入されました。

AutoBrowser Performance TestingはSitespeed.ioコンテナでウェブページのブラウザパフォーマンスを測定し、各ページの総合パフォーマンススコアを含むJSONレポートを作成し、レポートをアーティファクトとしてアップロードします。デフォルトでは、レビュー環境と本番環境のルートページをテストします。追加のURLをテストしたい場合は、ルートディレクトリの.gitlab-urls.txt という名前のファイルに、1行に1ファイルずつパスを追加します。たとえば

/
/features
/direction

ソースブランチとターゲットブランチ間のブラウザーパフォーマンスの違いは、マージリクエストウィジェットにも表示されます。

自動負荷パフォーマンステスト

GitLab 13.2で導入されました。

AutoLoad Performance Testingは、k6 コンテナでアプリケーションのサーバーパフォーマンスを測定し、いくつかの主要な結果メトリクスを含む JSON レポートを作成し、レポートをアーティファクトとしてアップロードします。

初期設定が必要です。特定のアプリケーションに合わせたk6テストを書く必要があります。テストはまた、CI/CD変数経由で環境の動的URLをピックアップできるように設定する必要があります。

ソースブランチとターゲットブランチ間の負荷性能テスト結果の違いは、マージリクエストウィジェットにも表示されます。

自動デプロイ

GitLab 13.6から導入された、Kubernetesクラスターに加えてAmazon Elastic Compute Cloud (Amazon EC2)へのデプロイも選択できるようになりました。

Auto DeployはAuto DevOpsのオプションステップです。要件を満たしていない場合、ジョブはスキップされます。

ブランチまたはマージリクエストがプロジェクトのデフォルトブランチにマージされた後、Auto DeployはKubernetesクラスタ内のproduction 環境にアプリケーションをデプロイします。名前空間はプロジェクト名と一意のプロジェクトIDに基づき、project-4321.

Auto Deployはデフォルトではステージング環境やカナリア環境へのデプロイを含みませんが、Auto DevOpsテンプレートにはこれらのタスクを有効にしたい場合のジョブ定義が含まれています。

CI/CD変数を使用して、ポッドレプリカを自動的にスケールしたり、Auto DevOpshelm upgrade コマンドにカスタム引数を適用したりすることができます。これはAuto Deploy Helmチャートをカスタマイズする簡単な方法です。

Helmはauto-deploy-appチャートを使用して、環境用のKubernetesネームスペースにアプリケーションをデプロイします。

GitLab 11.4以降では、ローカルのTillerが使用されます。GitLabの以前のバージョンでは、プロジェクトのネームスペースにTillerがインストールされていました。

caution
アプリはHelmの外部で(Kubernetesを直接使って)操作しないでください。これは、Helmが変更を検出せず、その後のAuto DevOpsによるデプロイで変更が元に戻されるなどの混乱を引き起こす可能性があります。また、何かを変更して再度デプロイすることで元に戻したい場合、Helmは最初に何かが変更されたことを検出しないため、古い設定を再適用する必要があることに気づかない可能性があります。
caution
GitLab 14.0はAuto Deployテンプレートを更新します。これは、v2auto-deploy-image の変更を壊すため、Auto DevOps プロジェクトで予期せぬ失敗を引き起こすかもしれません。GitLab 14.0にアップグレードする前に、アップグレードガイドに従って環境をアップグレードしてください。

GitLab デプロイトークン

GitLab 11.0で導入されました

GitLabデプロイトークンは、Auto DevOpsが有効化され、Auto DevOps設定が保存されると、内部および非公開プロジェクト用に作成されます。デプロイトークンはレジストリへの永続的なアクセスに使用できます。GitLab デプロイトークンを手動で取り消した後は、自動的に作成されません。

GitLab デプロイトークンが見つからない場合は、CI_REGISTRY_PASSWORD

note
CI_REGISTRY_PASSWORD はデプロイ中にのみ有効です。Kubernetesはデプロイ中にコンテナイメージを正常にプルできますが、ポッドの立ち退き後など、イメージを再度プルする必要がある場合、KubernetesはCI_REGISTRY_PASSWORD を使用してイメージをフェッチしようとするため、プルできません。

Kubernetes 1.16+の場合。

  • GitLab 12.8で導入されました
  • Kubernetes 1.16+ をサポートする PostgreSQL バージョンのデプロイが GitLab 12.9 で導入れました。
  • GitLab 13.0から新しいデプロイですぐにサポートされるようになりました。
caution
GitLab 13.0 でdeploymentApiVersion 設定のデフォルト値がextensions/v1beta からapps/v1 に変更されました。

Kubernetes 1.16 以降では、extensions/v1beta1 バージョンのDeployment のサポートを含む多くのAPI が削除されました。

Kubernetes 1.16+クラスターでAuto Deployを使用するには:

  1. GitLab 13.0以降で初めてアプリケーションをデプロイする場合は、設定は必要ありません。

  2. GitLab 12.10以前では、.gitlab/auto-deploy-values.yaml ファイルで以下を設定してください:

    deploymentApiVersion: apps/v1
    
  3. AUTO_DEVOPS_POSTGRES_CHANNEL1 に設定された PostgreSQL データベースがクラスター内部にインストールされている場合、PostgreSQL をアップグレードするためのガイドに従ってください。

  4. アプリケーションを初めてデプロイする場合で、GitLab 12.9 または 12.10 を使用している場合は、AUTO_DEVOPS_POSTGRES_CHANNEL2 に設定します。

caution
GitLab 12.9 と 12.10 では、AUTO_DEVOPS_POSTGRES_CHANNEL バージョン2 にオプトインすると、バージョン1 の PostgreSQL データベースが削除されます。バージョン2 にオプトインする前に、PostgreSQLのアップグレードガイドに従ってデータベースのバックアップと復元を行ってください(GitLab 13.0では、データベースの削除をトリガーするために追加のCI/CD変数が必要です)。

マイグレーション

GitLab 11.4 で導入されました

プロジェクトのCI/CD変数DB_INITIALIZEDB_MIGRATE を設定することで、PostgreSQLのデータベース初期化とマイグレーションをアプリケーションポッド内部で実行するように設定できます。

存在する場合、DB_INITIALIZE はHelmのポストインストールフックとしてアプリケーションポッド内でshellコマンドとして実行されます。データベースの初期化ステップが成功しないと実行できないアプリケーションもあるので、GitLabは最初のリリースをアプリケーションのデプロイなしで、データベースの初期化ステップだけをデプロイします。データベースの初期化が完了した後、GitLabはアプリケーションデプロイを標準とした2つ目のリリースをデプロイします。

ポストインストールフックは、デプロイが成功した場合、DB_INITIALIZE 以降は処理されないことを意味します。

存在する場合、DB_MIGRATE は Helm pre-upgrade フックとしてアプリケーションポッド内で shell コマンドとして実行されます。

たとえば、Cloud Native BuildpacksでビルドされたイメージのRailsアプリケーションでは、次のようになります:

  • DB_INITIALIZERAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:setup
  • DB_MIGRATE に設定できます。RAILS_ENV=production /cnb/lifecycle/launcher bin/rails db:migrate

リポジトリにDockerfile が含まれていない限り、イメージは Cloud Native Buildpacks でビルドされます。これらのイメージで実行するコマンドの前に/cnb/lifecycle/launcher を付けて(Herokuish を使用している場合は/bin/herokuish procfile exec を付けて)、アプリケーションの実行環境をレプリケートする必要があります。

auto-deploy-appチャートのアップグレード

アップグレードガイドに従って、auto-deploy-app Chart をアップグレードすることができます。

作業者

ウェブアプリケーションの中には、「ワーカープロセス」のために特別なデプロイを実行しなければならないものがあります。たとえば Rails アプリケーションでは、メール送信のようなバックグラウンドタスクを実行するために個別のワーカープロセスを使用するのが一般的です。

Auto Deploy で使用されるデフォルトの Helm チャ ートはワーカープロセスの実行をサポートしています。

ワーカーを実行するには、ワーカーが標準的なヘルスチェックに応答できることを確認する必要があります。標準的なヘルスチェックでは、ポート5000 で正常な HTTP 応答が期待されます。Sidekiq については、sidekiq_alive gemを使うことができます。

Sidekiqを使用するには、デプロイがRedisインスタンスにアクセスできることも確認する必要があります。Auto DevOpsはこのインスタンスをデプロイしてくれません:

  • 独自のRedisインスタンスをメンテナーしてください。
  • CI/CD 変数K8S_SECRET_REDIS_URL にこのインスタンスの URL を設定し、デプロイに渡せるようにします。

ヘルスチェックに応答するようにWorkerを設定したら、Railsアプリケーション用にSidekiq Workerを実行します。.gitlab/auto-deploy-values.yaml ファイル で以下を設定することで、ワーカーを有効にできます:

workers:
  sidekiq:
    replicaCount: 1
    command:
      - /cnb/lifecycle/launcher
      - sidekiq
    preStopCommand:
      - /cnb/lifecycle/launcher
      - sidekiqctl
      - quiet
    terminationGracePeriodSeconds: 60

コンテナでのコマンド実行

リポジトリにカスタムDockerfileが含まれていない限り、デフォルトではHerokuishを使用してAuto Buildでビルドされたアプリケーションは、以下のようにコマンドをラップする必要があるかもしれません:

/bin/herokuish procfile exec $COMMAND

コマンドをラップする必要があるいくつかの理由:

例えば、アプリケーションのルートディレクトリから Rails コンソールを起動するには、次のように実行します:

/bin/herokuish procfile exec bin/rails c

Cloud Native Buildpacksを使用する場合は、/bin/herokuish procfile exec の代わりに次のようにします。

/cnb/lifecycle/launcher $COMMAND

自動モニタリング (削除)

この機能はGitLab 14.7で非推奨となり、16.0で削除れました。

自動コードインテリジェンス

GitLab 13.5 で導入されました

GitLabコードインテリジェンスは、対話型開発環境(IDE)、型シグネチャ、シンボルドキュメント、ゴーゴー定義などのコードナビゲーション機能を追加します。LSIFによって提供され、Go言語を使用するAuto DevOpsプロジェクトでのみ利用可能です。GitLabは、より多くのLSIFインデクサが利用可能になるにつれて、より多くの言語のサポートを追加する予定です。アップデートはコードインテリジェンス・エピックで確認できます。

このステージはデフォルトで有効になっています。無効にするにはCODE_INTELLIGENCE_DISABLED CI/CD 変数を追加してください。Auto DevOpsジョブの無効化については、こちらをご覧ください。