Auto DevOpsのステージ

以下のセクションでは、Auto DevOpsのステージについて説明します。各ステージの動作を理解するために、注意深くお読みください。

Auto Build

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

Dockerfileを使用したAuto Build

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

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

• アプリケーションをポート5000に公開する。デフォルトのHelmチャートはこのポートが利用可能であることを前提としているためです。
• Auto Deploy Helmチャートをカスタマイズして、デフォルト値をオーバーライドする。

Cloud Native Buildpacksを使用したAuto Build

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

各Buildpackでは、Auto Buildがアプリケーションを正常にビルドできるように、プロジェクトのリポジトリに特定のファイルが含まれている必要があります。必要なファイルの構成は、選択したビルダーおよびBuildpackごとに異なります。たとえば、Herokuビルダー（デフォルト）を使用する場合、アプリケーションのルートディレクトリには、次のようにアプリケーションの言語に対応する適切なファイルを含める必要があります。

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

他の言語およびフレームワークの要件については、Heroku Buildpackドキュメントをお読みください。

ビルドコンテナにボリュームをマウントする

変数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からCloud Native Buildpacksに移行する

Cloud Native Buildpacksを使用したビルドは、Herokuishを使用したビルドと同じオプションをサポートしていますが、次の注意事項があります。:

• BuildpackはCloud Native Buildpackである必要があります。Heroku Buildpackは、Herokuのcnb-shimを使用してCloud Native Buildpackに変換できます。
• BUILDPACK_URLは、packでサポートされている形式である必要があります。
• /bin/herokuishコマンドはビルドされたイメージには存在せず、/bin/herokuish procfile execでコマンドにプレフィックスを付ける必要はなくなりました（また、付けることも不可能となりました）。代わりに、カスタムコマンドには、正しい実行環境を受け取るために/cnb/lifecycle/launcherというプレフィックスを付ける必要があります。

Auto Test

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

Auto Testは、アプリケーションにすでに用意されているテストを使用します。テストがない場合は、自分で追加する必要があります。

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

Auto Testは比較的新しい機能強化であるため、まだすべてのBuildpackがサポートしているわけではありません。ただし、Herokuが公式にサポートしている言語はすべて、Auto Testをサポートしています。HerokuのHerokuish Buildpackがサポートする言語はすべてAuto Testをサポートしていますが、特にマルチBuildpackはサポートしていません。

サポートされているBuildpackは次のとおりです。:

- 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

アプリケーションに必要なBuildpackが上記のリストにない場合は、カスタムBuildpackの使用を検討してください。

Auto Code Quality

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

Auto SAST

静的アプリケーションセキュリティテスト（SAST）は、現在のコードに対して静的な解析を実行し、潜在的なセキュリティ問題をチェックします。Auto SASTステージには、GitLab Runner 11.5以降が必要です。

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

詳細については、SASTを参照してください。

Auto Secret Detection

シークレット検出は、シークレット検出Dockerイメージを使用して現在のコードに対してシークレット検出を実行し、流出したシークレットをチェックします。

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

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

Auto Dependency Scanning

依存関係スキャンは、プロジェクトの依存関係に対して解析を実行し、潜在的なセキュリティ問題をチェックします。Auto Dependency Scanningステージは、Ultimate以外のライセンスではスキップされます。

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

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

Auto Container Scanning

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

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

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

Auto Review Apps

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

レビューアプリは、ブランチのコードに基づく一時的なアプリケーション環境であることから、デベロッパー、デザイナー、QA、プロダクトマネージャー、その他のレビュアーは、レビュープロセスの一環としてコードの変更を実際に確認して操作できます。Auto Review Appsは、各ブランチのレビューアプリを作成します。

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

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

レビューアプリは、Helmのauto-deploy-appチャートを使用してデプロイされます。これは、カスタマイズ可能です。アプリケーションは、環境のKubernetesネームスペースにデプロイされます。

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

Auto DAST

動的アプリケーションセキュリティテスト（DAST）では、一般的なオープンソースツールであるOWASP ZAProxyを使用して現在のコードを解析し、潜在的なセキュリティ問題をチェックします。Auto DASTステージは、Ultimate以外のライセンスではスキップされます。

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

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

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

DASTターゲットをオーバーライドする

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

Auto DASTをスキップする

DASTジョブをスキップできます。:

• DAST_DISABLED CI/CD変数を"true"に設定して、すべてのブランチでスキップします。
• DAST_DISABLED_FOR_DEFAULT_BRANCH変数を"true"に設定して、デフォルトブランチでのみスキップします。
• REVIEW_DISABLED変数を"true"に設定して、フィーチャーブランチでのみスキップします。これにより、レビューアプリもスキップされます。

Auto Browser Performance Testing

Auto Browser Performance Testingは、Sitespeed.ioコンテナを使用してWebページのブラウザパフォーマンスを測定し、各ページの全体的なパフォーマンススコアを含むJSONレポートを作成し、レポートをアーティファクトとしてアップロードします。デフォルトでは、レビュー環境と本番環境のルートページをテストします。追加のURLをテストする場合は、ルートディレクトリに.gitlab-urls.txtという名前のファイルを作成し、1行に1つずつパスを追加します。次に例を示します。:

/
/features
/direction

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

Auto Load Performance Testing

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

初期設定が必要です。k6テストは、特定のアプリケーションに合わせて作成する必要があります。そのテストは、CI/CD変数を使用して環境の動的URLを取得できるように設定しておく必要もあります。

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

Auto Deploy

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 DevOps helm upgradeコマンドにカスタム引数を適用したりできます。Auto Deploy Helmチャートをカスタマイズするには、この方法が簡単です。

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

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

GitLabデプロイトークン

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

GitLabデプロイトークンが見つからない場合、CI_REGISTRY_PASSWORDが使用されます。

Kubernetes 1.16以降

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

Kubernetes 1.16以降のクラスターでAuto Deployを使用するには、次の手順に従います。:

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

2. AUTO_DEVOPS_POSTGRES_CHANNELが1に設定された状態でクラスター内にPostgreSQLデータベースをインストールしている場合は、PostgreSQLのアップグレードガイドに従ってください。

移行

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

DB_INITIALIZEが存在する場合、これはHelmのインストール後フックとして、アプリケーションポッド内でShellコマンドとして実行されます。一部のアプリケーションは、データベースの初期化ステップが正常に完了しないと実行できないため、GitLabは最初のリリースでアプリケーションのデプロイを行わず、データベースの初期化ステップのみを実行します。データベースの初期化が完了すると、GitLabはアプリケーションのデプロイを含む2回目のリリースを通常どおりデプロイします。

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

DB_MIGRATEが存在する場合、これはHelmのアップグレード前フックとして、アプリケーションポッド内でShellコマンドとして実行されます。

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

• DB_INITIALIZEは次のように設定できます。RAILS_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を付ける必要があります。

auto-deploy-appチャートをアップグレードする

アップグレードガイドに従って、auto-deploy-appチャートをアップグレードできます。

ワーカー

一部のWebアプリケーションでは、「ワーカープロセス」のために追加のデプロイを実行する必要があります。たとえば、Railsアプリケーションでは、メールの送信などのバックグラウンドタスクを実行するために、通常、個別のワーカープロセスを使用します。

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

ワーカーを実行するには、ワーカーが標準ヘルスチェックに応答できるようにする必要があります。このヘルスチェックは、ポート5000でのHTTP応答が成功することを想定しています。Sidekiqの場合、sidekiq_alive gemを使用できます。

Sidekiqを操作するには、デプロイでRedisインスタンスにアクセスできることも確認する必要があります。Auto DevOpsはこのインスタンスをデプロイしないため、次の対応が必要になります。:

• 独自のRedisインスタンスを管理する。
• CI/CD変数K8S_SECRET_REDIS_URLにこのインスタンスのURLを設定し、デプロイに確実に渡されるようにする。

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

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

コンテナ内でコマンドを実行する

リポジトリにカスタムDockerfileが含まれていない限り、Auto Buildされたアプリケーションでは、コマンドを次のようにラップする必要がある場合があります。:

/cnb/lifecycle/launcher $COMMAND

コマンドをラップする必要がある理由の一部を次に示します。:

• kubectl execを使用してアタッチするため。
• GitLab Webターミナルを使用するため。

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

/cnb/lifecycle/launcher procfile exec bin/rails c

Auto Code Intelligence

GitLabコードインテリジェンスは、型シグネチャ、シンボルドキュメント、定義への移動など、インタラクティブな開発環境（IDE）で一般的なコードナビゲーション機能を追加します。これは、LSIFによって実現されており、Go言語を使用するAuto DevOpsプロジェクトでのみ使用できます。GitLabは、利用可能なLSIF Indexerが増えるにつれて、対応言語をさらに拡大していく予定です。最新情報はコードインテリジェンスエピックでフォローできます。

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