正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

デプロイの安全性

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

デプロイジョブは、特定の種類のCI/CDジョブです。これらはパイプライン内の他のジョブよりも機密性が高い場合があり、特別な注意を払って取り扱う必要があるかもしれません。GitLabには、デプロイのセキュリティと安定性を維持するのに役立つ機能がいくつかあります。

次のことが可能です。

継続的デプロイワークフローを使用しており、同じ環境への同時実行デプロイが発生しないようにする場合は、次のオプションを有効にする必要があります。

概要については、CDパイプライン/ワークフローを保護する方法を参照してください。

重要な環境への書き込みアクセスを制限する

デフォルトでは、環境は、少なくともデベロッパーロールを持つすべてのチームメンバーが変更できます。重要な環境（たとえば、production環境）への書き込みアクセスを制限する場合は、保護された環境を設定できます。

一度に1つのデプロイジョブのみが実行されるようにする

GitLab CI/CDのパイプラインジョブは並行して実行されるため、2つの異なるパイプライン内の2つのデプロイジョブが、同じ環境に同時にデプロイしようとする可能性があります。デプロイは順番に行われる必要があるため、これは望ましくない動作です。

.gitlab-ci.ymlのresource_groupキーワードを使用して、一度に1つのデプロイジョブのみが実行されるようにすることができます。

次に例を示します。

deploy:
 script: deploy-to-prod
 resource_group: prod

リソースグループを使用する前の問題のあるパイプラインフローの例:

  1. パイプラインAのdeployジョブが実行を開始します。
  2. パイプラインBのdeployジョブが実行を開始します。これは同時デプロイであり、予期しない結果を引き起こす可能性があります。
  3. パイプラインAのdeployジョブが完了しました。
  4. パイプラインBのdeployジョブが完了しました。

リソースグループを使用する後の、改善されたパイプラインフロー：

  1. パイプラインAのdeployジョブが実行を開始します。
  2. パイプラインBのdeployジョブが開始を試みますが、最初のdeployジョブが完了するのを待ちます。
  3. パイプラインAのdeployジョブが完了しました。
  4. パイプラインBのdeployジョブが実行を開始します。

詳細については、リソースグループのドキュメントを参照してください。

古いデプロイジョブを防止する

パイプラインジョブの有効な実行順序は実行ごとに異なる可能性があり、望ましくない動作を引き起こす可能性があります。たとえば、新しいパイプライン内のデプロイジョブが、古いパイプライン内のデプロイジョブよりも先に完了する可能性があります。これにより、古いデプロイが後で完了し、「新しい」デプロイを上書きする競合状態が発生します。

新しいデプロイジョブが開始されたときに、古いデプロイジョブが実行されないようにするには、古くなったデプロイジョブを防止機能を有効にします。

古いデプロイジョブが開始されると、失敗して、次のラベルが付けられます。

  • パイプラインビューのfailed outdated deployment job。
  • 完了したジョブを表示するときのThe deployment job is older than the latest deployment, and therefore failed.。

古いデプロイジョブが手動の場合、実行（ play ）ボタンはメッセージThis deployment job does not run automatically and must be started manually, but it's older than the latest deployment, and therefore can't run.で無効になります。

ジョブの経過時間は、コミット時間ではなく、ジョブの開始時間によって決まるため、状況によっては新しいコミットが阻止される可能性があります。

ロールバックデプロイのジョブの再試行

安定した古いデプロイにすばやくロールバックする必要があるかもしれません。デフォルトでは、デプロイのロールバックのパイプラインジョブの再試行が有効になっています。

パイプラインの再試行を無効にするには、ロールバックデプロイのジョブの再試行を許可するチェックボックスをオフにします。機密性の高いプロジェクトでは、パイプラインの再試行を無効にする必要があります。

ロールバックが必要な場合は、以前のコミットで新しいパイプラインを実行する必要があります。

例

古くなったデプロイジョブを防止を有効にする以前の、問題のあるパイプラインフローの例：

  1. パイプラインAは、デフォルトブランチ上に作成されます。
  2. 以後、パイプラインBがデフォルトブランチ上に作成されます（新しいコミットSHAを使用）。
  3. パイプラインBのdeployジョブが最初に完了し、新しいコードをデプロイします。
  4. パイプラインAのdeployジョブが後で完了し、古いコードをデプロイし、新しい（最新の）デプロイを上書きします。

古くなったデプロイジョブを防止を有効にする後の、改善されたパイプラインフロー：

  1. パイプラインAは、デフォルトブランチ上に作成されます。
  2. 以後、パイプラインBがデフォルトブランチ上に作成されます（新しいSHAを使用）。
  3. パイプラインBのdeployジョブが最初に完了し、新しいコードをデプロイします。
  4. パイプラインAのdeployジョブが失敗するため、新しいパイプラインからのデプロイは上書きされません。

デプロイフリーズ期間中のデプロイを防止する

特定の期間、たとえば、ほとんどの従業員が不在の計画された休暇期間中にデプロイを防止する場合は、デプロイフリーズを設定できます。デプロイフリーズ期間中は、デプロイを実行できません。これは、デプロイが予期せず発生しないようにするのに役立ちます。

次に設定されたデプロイフリーズが、環境デプロイリストページの上部に表示されます。

本番環境のシークレットを保護する

正常にデプロイするには、本番環境のシークレットが必要です。たとえば、クラウドにデプロイする場合、クラウドプロバイダーは、これらのシークレットをサービスに接続するために必要とします。プロジェクト設定で、これらのシークレットのCI/CD変数を定義して保護できます。保護された変数は、保護ブランチまたは保護されたタグで実行されているパイプラインにのみ渡されます。他のパイプラインは、保護された変数を取得しません。変数のスコープを特定の環境に設定することもできます。シークレットが意図せずに公開されないようにするために、保護された環境で保護された変数を使用することをお勧めします。Runner側で本番環境のシークレットを定義することもできます。これにより、メンテナーロールを持つ他のユーザーがシークレットを読み取ることを防ぎ、Runnerが保護されたブランチでのみ実行されるようにします。

詳細については、パイプラインセキュリティを参照してください。

デプロイ用にプロジェクトを分離する

プロジェクトのメンテナーロールを持つすべてのユーザーが、本番環境のシークレットにアクセスできます。本番環境にデプロイできるユーザーの数を制限する必要がある場合は、別のプロジェクトを作成し、元のプロジェクトからCD権限を分離し、プロジェクトのメンテナーロールを持つ元のユーザーが本番環境のシークレットとCD設定にアクセスできないようにする、新しい権限モデルを構成できます。複数プロジェクトパイプラインを使用して、CDプロジェクトを開発プロジェクトに接続できます。

変更から.gitlab-ci.ymlを保護する

.gitlab-ci.ymlには、アプリケーションを本番環境サーバーにデプロイするためのルールが含まれている場合があります。通常、このデプロイは、マージリクエストをプッシュした後に自動的に実行されます。デベロッパーが.gitlab-ci.ymlを変更するのを防ぐために、別のリポジトリで定義できます。この設定は、まったく異なる権限のセットを持つ別のプロジェクト内のファイルを参照できます（デプロイ用にプロジェクトを分離すると同様）。このシナリオでは、.gitlab-ci.ymlは公開されていますが、他のプロジェクトで適切な権限を持つユーザーのみが編集できます。

詳細については、カスタムCI/CD設定パスを参照してください。

デプロイする前に承認を要求する

デプロイを本番環境環境にプロモートする前に、専任のテストグループでクロス検証することは、安全性を確保するための効果的な方法です。詳細については、デプロイの承認を参照してください。