環境

GitLab環境は、開発、ステージ、本番環境など、アプリケーションの特定のデプロイターゲットを表します。これは、ソフトウェアライフサイクルのさまざまな段階で複数の異なる設定を管理したり、コードをデプロイしたりするために使用します。

環境を使用すると、次のことが可能になります:

• デプロイプロセスの一貫性と再現可能性を維持する
• どのコードがどこにデプロイされているかを追跡する
• 問題が発生した場合に以前のバージョンにロールバックする
• 機密性の高い環境を不正な変更から保護する
• セキュリティ境界を維持するために、環境ごとにデプロイ変数を制御する
• 環境の健全性をモニタリングし、問題が発生した場合はアラートを受信する

環境とデプロイを表示する

前提要件:

• 非公開プロジェクトでは、レポーターロール以上が必要です。環境の権限を参照してください。

特定のプロジェクトの環境のリストを表示する方法はいくつかあります:

• 少なくとも1つの環境が利用可能な場合（つまり、環境が停止していない場合）は、プロジェクトの概要ページに表示されます。

  

• 左側のサイドバーで、操作 > 環境を選択します。環境が表示されます。

  

• 環境のデプロイリストを表示するには、stagingなどの環境名を選択します。デプロイがこのリストに表示されるのは、デプロイジョブによってそれらが作成された後です。

  

• デプロイパイプライン内のすべての手動ジョブのリストを表示するには、実行（ ）ドロップダウンリストを選択します。

  

環境URL

環境URLは、GitLabのいくつかの場所に表示されます:

• マージリクエスト内のリンクとして表示:

  

• 環境ビュー内のボタンとして:

  

• デプロイビュー内のボタンとして:

  

マージリクエストでこの情報が表示されるのは、次の条件を満たす場合です:

• マージリクエストが最終的にデフォルトブランチ（通常はmain）にマージされること。
• そのブランチも環境（stagingやproductionなど）にデプロイされること。

次に例を示します:

ソースファイルから公開ページに移動する

GitLabのルートマップを使用すると、ソースファイルから、レビューアプリ用に設定された環境の公開ページに直接移動できます。

環境の種類

環境は、静的または動的のいずれかです。

静的環境:

• 通常、継続的なデプロイによって再利用される。
• 静的な名前が付けられる。例: staging、production。
• 手動で、またはCI/CDパイプラインの一部として作成される。

動的環境:

• 通常、CI/CDパイプラインで作成され、単一のデプロイでのみ使用された後、停止または削除される。
• 動的な名前が付けられる（通常、CI/CD変数の値に基づく）。
• レビューアプリの機能の1つ。

環境は、その停止ジョブが実行されたかどうかに応じて、次の3つのステータスのいずれかになります:

• available: この環境が存在する。デプロイが存在する場合があります。
• stopping: _停止ジョブ_が開始された。停止ジョブが定義されていない場合、このステータスは適用されません。
• stopped: _停止ジョブ_が実行されたか、ユーザーが手動でジョブを停止した。

静的環境を作成する

UIまたは.gitlab-ci.ymlファイルで静的環境を作成できます。

UIの場合

前提要件:

• デベロッパーロール以上が必要です。

UIで静的環境を作成するには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 環境を作成を選択します。
4. フィールドに入力します。
5. 保存を選択します。

.gitlab-ci.ymlファイルの場合

前提要件:

• デベロッパーロール以上が必要です。

.gitlab-ci.ymlファイルで静的環境を作成するには、次のようにします:

1. deployステージでジョブを定義します。
2. ジョブで、環境のnameとurlを定義します。その名前の環境がパイプラインの実行時に存在しない場合は、作成されます。

たとえば、stagingという名前の環境を作成し、URLをhttps://staging.example.comに設定するには、次のようにします:

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging server"
  environment:
    name: staging
    url: https://staging.example.com

動的環境を作成する

動的環境を作成するには、各パイプラインに一意のCI/CD変数を使用します。

前提要件:

• デベロッパーロール以上が必要です。

.gitlab-ci.ymlファイルで動的環境を作成するには、次のようにします:

1. deployステージでジョブを定義します。
2. ジョブで、次の環境属性を定義します:
   • name: $CI_COMMIT_REF_SLUGのような関連するCI/CD変数を使用します。必要に応じて、環境名に静的なプレフィックスを追加します。これにより、同じプレフィックスを持つすべての環境がUIでグループ化されます。
   • url: （オプション）ホスト名のプレフィックスとして、$CI_ENVIRONMENT_SLUGのような関連するCI/CD変数を指定します。

次の例では、deploy_review_appジョブが実行されるたびに、環境の名前とURLが一意の値を使用して定義されます。

deploy_review_app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: never
    - if: $CI_COMMIT_BRANCH

動的な環境URLを設定する

一部の外部ホスティングプラットフォームでは、デプロイごとにランダムなURLを生成します（例: https://94dd65b.amazonaws.com/qa-lambda-1234567）。そのため、.gitlab-ci.ymlファイルでURLを参照することが困難になります。

この問題に対処するため、変数のセットを返すようにデプロイジョブを設定できます。このような変数には、外部サービスが動的に生成するURLが含まれます。GitLabは、dotenv（.env）ファイル形式をサポートしており、.envファイルで定義された変数を使用してenvironment:urlの値を展開します。

この機能を使用するには、.gitlab-ci.ymlでartifacts:reports:dotenvキーワードを指定します。

また、environment:urlにhttps://$DYNAMIC_ENVIRONMENT_URLのようなURLの静的な部分を指定することもできます。DYNAMIC_ENVIRONMENT_URLの値がexample.comの場合、最終結果はhttps://example.comとなります。

review/your-branch-name環境に割り当てられたURLは、UIで確認できます。

概要については、Set dynamic environment URLs after a job finished（ジョブ完了後に動的URLを設定する）を参照してください。

次の例では、レビューアプリがマージリクエストごとに新しい環境を作成します:

• reviewジョブはプッシュごとにトリガーされ、review/your-branch-nameという名前の環境を作成または更新します。環境URLは$DYNAMIC_ENVIRONMENT_URLに設定されます。
• reviewジョブが完了すると、GitLabはreview/your-branch-name環境のURLを更新します。deploy.envレポートアーティファクトを解析し、変数のリストをランタイム作成済みとして登録し、environment:url: $DYNAMIC_ENVIRONMENT_URLを展開してそれを環境URLに設定します。

review:
  script:
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)                                 # In script, get the environment URL.
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env    # Add the value to a dotenv file.
  artifacts:
    reports:
      dotenv: deploy.env                                                       # Report back dotenv file to rails.
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL                                              # and set the variable produced in script to `environment:url`
    on_stop: stop_review

stop_review:
  script:
    - ./teardown-environment
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

次の点に注意してください:

• stop_reviewはdotenvレポートアーティファクトを生成しないため、DYNAMIC_ENVIRONMENT_URL環境変数を認識しません。このため、stop_reviewジョブではenvironment:urlを設定しないでください。
• 環境URLが無効な場合（たとえば、URLが不正な形式の場合）、システムは環境URLを更新しません。
• stop_reviewで実行されるスクリプトがリポジトリにのみ存在し、GIT_STRATEGY: noneまたはGIT_STRATEGY: emptyを使用できない場合、これらのジョブに対してマージリクエストパイプラインを設定します。これにより、フィーチャーブランチが削除された後でも、Runnerがリポジトリをフェッチできるようになります。詳細については、Runnerのrefspecを参照してください。

Add-Content -Path deploy.env -Value "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL"

環境のデプロイ階層

productionのような業界標準の環境名を使用する代わりに、customer-portalのようなコード名を使用したい場合があります。customer-portalのような名前を使用しても技術的には問題ありませんが、このような名前では、その環境が本番環境であることを示せません。また、デプロイ頻度などのメトリクスの計算方法に影響を及ぼす可能性があります。

特定の環境が特定の用途であることを示すために、次のような階層を使用できます:

デフォルトでは、GitLabは環境名に基づいて階層を想定します。UIを使用して環境階層を設定することはできません。代わりに、deployment_tierキーワードを使用して階層を指定できます。

環境名を変更する

環境名は変更できません。

環境名の変更と同じ結果を得るには、次のようにします:

1. 既存の環境を停止します。
2. 既存の環境を削除します。
3. 希望する名前で新しい環境を作成します。

CI/CD変数

環境とデプロイをカスタマイズするには、任意の定義済みCI/CD変数を使用して、カスタムCI/CD変数を定義します。

CI/CD変数の環境スコープを制限する

デフォルトでは、すべてのCI/CD変数をパイプライン内のすべてのジョブで利用できます。ジョブ内のテストツールが侵害された場合、そのツールはジョブで利用できるすべてのCI/CD変数の取得を試みる可能性があります。このようなサプライチェーン攻撃を軽減するため、機密性の高い変数の環境スコープは、必要とするジョブのみに制限する必要があります。

CI/CD変数を利用できる環境を定義して、CI/CD変数の環境スコープを制限します。デフォルトの環境スコープは、ワイルドカードの*であり、すべてのジョブが変数にアクセスできます。

特定の環境を選択するには、特定のマッチングを使用します。たとえば、変数の環境スコープをproductionに設定すると、その変数にアクセスできるのは、環境がproductionのジョブのみです。

ワイルドカードマッチング（*）を使用して、特定の環境グループを選択することもできます。たとえば、review/*と指定すると、すべてのレビューアプリが対象になります。

たとえば、次の4つの環境があるとします:

• production
• staging
• review/feature-1
• review/feature-2

これらに対する環境スコープのマッチングは次のとおりです:

環境ごとにスコープ設定された変数は、rulesやincludeと組み合わせて使用しないでください。パイプラインの作成時にGitLabがパイプライン設定を検証する際、変数が定義されていない可能性があります。

環境を検索する

名前で環境を検索するには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 検索ボックスに検索語句を入力します。
   • search term should be 3 or more characters（検索語句は3文字以上）でなければなりません。
   • マッチングは環境名の先頭から適用されます。
     • たとえば、develは環境名developmentと一致しますが、elopは一致しません。
   • フォルダー名形式の環境では、マッチングはベースフォルダー名の後から適用されます。
     • たとえば、名前がreview/test-appの場合、検索語句testはreview/test-appと一致します。
     • review/testのようにフォルダー名にプレフィックスを付けて検索すると、review/test-appと一致します。

類似の環境をグループ化する

UIで、環境を折りたたみ可能なセクションにグループ化できます。

たとえば、すべての環境名がreviewで始まる場合、UIではそれらの環境がその語句の見出しの下にグループ化されます:

次の例は、環境名をreviewで始める方法を示しています。$CI_COMMIT_REF_SLUG変数には、実行時にブランチ名が設定されます:

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG

環境を停止する

環境の停止とは、ターゲットサーバー上でそのデプロイにアクセスできなくなることを意味します。環境を削除するには、その前に環境を停止する必要があります。

環境を停止するためにon_stopアクションを使用すると、そのジョブがアーカイブされていなければ実行されます。

UIを使用して環境を停止する

GitLab UIで環境を停止するには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 停止する環境の横にある停止を選択します。
4. 確認ダイアログで、環境を停止を選択します。

デフォルトの停止動作

GitLabは、関連付けられたブランチが削除またはマージされると、環境を自動的に停止します。この動作は、明示的なon_stop CI/CDジョブが定義されていない場合でも適用されます。

ただし、イシュー428625では、本番環境とステージング環境については、明示的なon_stop CI/CDジョブが定義されている場合にのみ停止するように、この動作を変更することが提案されています。

環境の停止動作は、環境APIのauto_stop_settingパラメータで設定できます。

ブランチ削除時に環境を停止する

ブランチが削除されたときに環境を停止するように設定できます。

次の例では、deploy_reviewジョブがstop_reviewジョブを呼び出し、環境をクリーンアップして停止します。

• 両方のジョブには、同じrules設定またはonly/except設定が必要です。設定が同じでないと、deploy_reviewジョブを含むすべてのパイプラインにstop_reviewジョブが含まれない可能性があり、action: stopをトリガーして環境を自動的に停止できなくなる可能性があります。
• 環境を開始したジョブより後のステージにある場合、action: stopを含むジョブは実行されない可能性があります。
• マージリクエストパイプラインを使用できない場合は、stop_reviewジョブでGIT_STRATEGYをnoneまたはemptyに設定します。その後、ブランチが削除された後にRunnerがコードをチェックアウトしようとすることはありません。

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

マージリクエストのマージまたは完了時に環境を停止する

マージリクエストパイプライン設定を使用すると、stopトリガーが自動的に有効になります。

次の例では、deploy_reviewジョブがstop_reviewジョブを呼び出し、環境をクリーンアップして停止します。

• パイプラインが完了している設定が有効になっている場合、stop_reviewジョブに対してallow_failure: trueキーワードを設定することで、パイプラインとマージリクエストがブロックされるのを防ぐことができます。

deploy_review:
  stage: deploy
  script:
    - echo "Deploy a review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review:
  stage: deploy
  script:
    - echo "Remove review app"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

一定期間後に環境を停止する

一定期間後に自動的に停止するように環境を設定できます。

.gitlab-ci.ymlファイルで、environment:auto_stop_inキーワードを指定します。1 hour and 30 minutesや1 dayなど、自然言語で期間を指定します。指定した期間が経過すると、GitLabは環境を停止するジョブを自動的にトリガーします。

次の例では、以下が実行されます:

• マージリクエストの各コミットは、review_appジョブをトリガーします。このジョブは、最新の変更を環境にデプロイして有効期限をリセットします。
• 環境が1週間以上無効である場合、GitLabはstop_review_appジョブを自動的にトリガーして環境を停止します。

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1 week
  rules:
    - if: $CI_MERGE_REQUEST_ID

stop_review_app:
  script: stop-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

environment:actionキーワードを使用して、環境の停止がスケジュールされている期間をリセットできます。詳細については、準備または検証目的で環境にアクセスするを参照してください。

環境のスケジュールされた停止日時を表示する

環境が指定された期間後に停止するようにスケジュールされている場合は、その有効期限の日時を表示できます。

環境の有効期限の日時を表示するには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 環境名を選択します。

有効期限の日時は、左上隅にある環境名の横に表示されます。

環境のスケジュールされた停止日時をオーバーライドする

環境が指定された期間後に停止するようにスケジュールされている場合は、その有効期限をオーバーライドできます。

UIで環境の有効期限をオーバーライドするには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 環境名を選択します。
4. 右上隅の画鋲（ ）を選択します。

.gitlab-ci.ymlで環境の有効期限をオーバーライドするには、次のようにします:

1. プロジェクトの.gitlab-ci.ymlを開きます。
2. 対応するデプロイジョブのauto_stop_in設定をauto_stop_in: neverに更新します。

auto_stop_in設定がオーバーライドされ、環境は手動で停止されるまでアクティブな状態を維持します。

古い環境をクリーンアップする

プロジェクト内の古い環境を停止する場合は、古い環境をクリーンアップします。

前提要件:

• メンテナーロール以上が必要です。

古い環境をクリーンアップするには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 環境のクリーンアップを選択します。
4. 環境を古いと判定する基準となる日付を選択します。
5. クリーンアップを選択します。

指定した日付以降に更新されていないアクティブな環境は停止されます。保護環境は無視され、停止されません。

環境の停止時にパイプラインジョブを実行する

環境のデプロイジョブでon_stopアクションを使用して、環境の停止ジョブを定義できます。

環境を停止すると、最新の完了したパイプラインに含まれる完了したデプロイに対応する停止ジョブが実行されます。デプロイまたはパイプラインは、ステータスが成功、キャンセル、または失敗になったときに完了となります。

前提要件:

• デプロイジョブと停止ジョブの両方に、同じルールまたは「次のみ」/「次を除く」の設定が必要です。
• 停止ジョブでは、次のキーワードを定義する必要があります:
  • when。次のいずれかで定義されます:
    • ジョブレベル。
    • ルールセクション内。rulesとwhen: manualを使用する場合は、ジョブが実行されなくてもパイプラインを完了できるように、allow_failure: trueも設定する必要があります。
  • environment:name
  • environment:action

次の例では、以下が実行されます:

• review_appジョブは、最初のジョブが完了した後に、stop_review_appジョブを呼び出します。
• stop_review_appは、whenで定義された内容に基づいてトリガーされます。この場合は、manualに設定されているため、実行するにはGitLab UIからの手動操作が必要です。
• GIT_STRATEGYはnoneに設定されています。stop_review_appジョブが自動的にトリガーされた場合、ブランチが削除された後にRunnerがコードをチェックアウトしようとすることはありません。

review_app:
  stage: deploy
  script: make deploy-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com
    on_stop: stop_review_app

stop_review_app:
  stage: deploy
  variables:
    GIT_STRATEGY: none
  script: make delete-app
  when: manual
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop

環境に対する複数の停止アクション

環境に対して複数のparallel（並列）停止アクションを設定するには、.gitlab-ci.ymlファイルで定義されているとおり、同じenvironmentに対する複数のデプロイジョブにわたってon_stopキーワードを指定します。

環境が停止されると、成功したデプロイジョブに対応するon_stopアクションのみが、特定の順序なく並列に実行されます。

次の例では、test環境に対して次の2つのデプロイジョブがあります:

• deploy-to-cloud-a
• deploy-to-cloud-b

環境が停止されると、システムはteardown-cloud-aとteardown-cloud-bのon_stopアクションを並列に実行します。

deploy-to-cloud-a:
  script: echo "Deploy to cloud a"
  environment:
    name: test
    on_stop: teardown-cloud-a

deploy-to-cloud-b:
  script: echo "Deploy to cloud b"
  environment:
    name: test
    on_stop: teardown-cloud-b

teardown-cloud-a:
  script: echo "Delete the resources in cloud a"
  environment:
    name: test
    action: stop
  when: manual

teardown-cloud-b:
  script: echo "Delete the resources in cloud b"
  environment:
    name: test
    action: stop
  when: manual

on_stopアクションを実行せずに環境を停止する

定義済みのon_stopアクションを実行せずに環境を停止する必要がある場合があります。たとえば、コンピューティングクォータを消費せずに多数の環境を削除したい場合などです。

定義済みのon_stopアクションを実行せずに環境を停止するには、パラメータforce=trueを指定して環境の停止APIを実行します。

環境を削除する

環境とそのすべてのデプロイを削除する場合は、環境を削除します。

前提要件:

• デベロッパーロール以上が必要です。
• 削除する前に、環境を停止する必要があります。

環境を削除するには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 操作 > 環境を選択します。
3. 停止中タブを選択します。
4. 削除する環境の横にある環境を削除を選択します。
5. 確認ダイアログで、環境を削除を選択します。

準備または検証目的で環境にアクセスする

検証や準備など、さまざまな目的で環境にアクセスするジョブを定義できます。これにより、デプロイの作成を事実上回避できるため、CDワークフローをより正確に調整できます。

そのためには、ジョブのenvironmentセクションにaction: prepare、action: verify、またはaction: accessを追加します:

build:
  stage: build
  script:
    - echo "Building the app"
  environment:
    name: staging
    action: prepare
    url: https://staging.example.com

これにより、環境ごとにスコープ設定された変数にアクセスできるようになり、不正なアクセスからビルドを保護するために使用できます。また、古いデプロイジョブを防止機能を回避するためにも有効です。

環境が一定期間後に停止するように設定されている場合、accessアクションまたはprepareアクションを含むジョブは、スケジュール済みの停止時刻をリセットします。スケジュール済みの停止時刻をリセットする際は、環境に対する直近の成功したデプロイジョブで設定されたenvironment:auto_stop_inが使用されます。たとえば、直近のデプロイでauto_stop_in: 1 weekが使用され、その後action: accessを含むジョブによってアクセスされた場合、その環境は、アクセスジョブの完了時点から1週間後に停止するように再スケジュールされます。

スケジュール済みの停止時刻を変更せずに環境にアクセスするには、verifyアクションを使用します。

環境インシデント管理

本番環境は、制御不能な理由を含め、予期せず停止する可能性があります。たとえば、外部依存関係、インフラストラクチャ、または人為的エラーなどの問題が、環境に重大な悪影響を及ぼす可能性があります。次に例を示します:

• 依存しているクラウドサービスが停止する。
• サードパーティのライブラリが更新され、アプリケーションとの互換性がなくなる。
• サーバーの脆弱なエンドポイントに対してDDoS攻撃を受ける。
• オペレーターがインフラストラクチャを誤って設定する。
• 本番環境のアプリケーションコードにバグが入り込む。

インシデント管理を使用すると、即時対応が必要な重大な問題が発生した際にアラートを受け取ることができます。

環境の最新アラートを表示する

アラートインテグレーションを設定すると、環境に関するアラートが環境ページに表示されます。最も重大度の高いアラートが表示されるため、即時対応が必要な環境を特定できます。

アラートをトリガーした問題が解決されると、そのアラートは削除され、環境ページに表示されなくなります。

ロールバックが必要となるアラートの場合、環境ページのデプロイタブを選択して、ロールバックするデプロイを選択します。

自動ロールバック

通常の継続的デプロイワークフローでは、本番環境へのデプロイ前にCIパイプラインですべてのコミットをテストします。しかしそれでも、問題のあるコードが本番環境に導入される可能性はゼロではありません。たとえば、論理的には正しくても非効率なコードは、深刻なパフォーマンス低下を引き起こすにもかかわらず、テストには合格する可能性があります。オペレーターやサイトリライアビリティエンジニアリング（SRE）は、これらの問題をできるだけ早く検出するためにシステムをモニタリングしています。問題のあるデプロイを発見した場合、以前の安定したバージョンにロールバックできます。

GitLab自動ロールバックは、重大なアラートが検出された際にロールバックを自動的にトリガーし、このワークフローを簡素化します。GitLabがロールバックする際に適切な環境を選択できるようにするには、アラートにgitlab_environment_nameキーと環境名を含める必要があります。GitLabは、直近の成功したデプロイを選択して再度デプロイします。

GitLab自動ロールバックの制限事項:

• アラートが検出された際にデプロイが実行中の場合、ロールバックはスキップされます。
• ロールバックを実行できるのは3分に1回のみです。複数のアラートが同時に検出された場合、実行されるロールバックは1回のみです。

GitLab自動ロールバックは、デフォルトで無効になっています。有効にするには、次のようにします:

1. 左側のサイドバーで、検索または移動先を選択して、プロジェクトを見つけます。新しいナビゲーションをオンにした場合、このフィールドは上部のバーにあります。
2. 設定 > CI/CDを選択します。
3. 自動デプロイロールバックを展開します。
4. 自動ロールバックを有効化チェックボックスをオンにします。
5. 変更を保存を選択します。

環境の権限

自分のロールに応じて、公開プロジェクトと非公開プロジェクトで環境を操作できます。

環境を表示する

• 公開プロジェクトでは、メンバー以外を含め、すべてのユーザーが環境のリストを表示できます。
• 非公開プロジェクトでは、環境のリストを表示するにはレポーターロール以上が必要です。

環境を作成および更新する

• 新しい環境を作成したり、既存の保護されていない環境を更新したりするには、デベロッパーロール以上が必要です。
• 既存の環境が保護されていてアクセス権限がない場合、その環境を更新することはできません。

環境を停止および削除する

• 保護されていない環境を停止または削除するには、デベロッパーロール以上が必要です。
• 環境が保護されていてアクセス権限がない場合、その環境を停止または削除することはできません。

保護環境でデプロイジョブを実行する

保護されたブランチにプッシュまたはマージできる場合:

• レポーターロール以上が必要です。

保護ブランチにプッシュできない場合:

• レポーターロールを持つグループのメンバーでなければなりません。

保護環境へのデプロイ専用アクセスを参照してください。

Webターミナル（非推奨）

デプロイサービス（たとえばKubernetesインテグレーション）を使用して環境にデプロイする場合、GitLabはその環境へのターミナルセッションを開くことができます。これにより、Webブラウザから移動することなく問題をデバッグできます。

Webターミナルはコンテナベースのデプロイであり、基本ツール（エディタなど）はなく、いつでも停止または再起動される可能性があります。停止または再起動されると、変更内容がすべて失われます。Webターミナルは包括的なオンラインIDEではなく、デバッグツールとして扱う必要があります。

Webターミナルに関する注意事項:

• プロジェクトのメンテナーとオーナーのみが利用できる。
• 有効にする必要がある。

UIでWebターミナルを表示するには、次のいずれかを実行します:

• アクションメニューから、ターミナルを選択します:

  

• 特定の環境のページで、右側のターミナル（ ）を選択します。

ボタンを選択すると、ターミナルセッションが確立されます。このターミナルは、他のターミナルと同じように機能します。デプロイで作成されたコンテナ内で作業するため、以下を実行できます:

• Shellコマンドを実行し、リアルタイムで応答を受け取る。
• ログを確認する。
• 設定またはコードの微調整を試す。

同じ環境に対して複数のターミナルを開くことができます。ターミナルごとに独自のShellセッションがあり、screenやtmuxなどのマルチプレクサを使用することも可能です。

関連トピック

• Kubernetes向けダッシュボード
• デプロイ
• 保護環境
• 環境ダッシュボード
• デプロイの安全性

トラブルシューティング

action: stopを含むジョブが実行されない

on_stopジョブが設定されているにもかかわらず、環境が停止しない場合があります。これは、action: stopを含むジョブが、そのstages:またはneeds:の設定が原因で実行可能な状態になっていない場合に発生します。

次に例を示します:

• 環境が、失敗したジョブを含むステージで開始されることがあります。その場合、その後のステージのジョブは開始されません。環境に対するaction: stopを含むジョブが後続のステージに配置されている場合、そのジョブは開始されず、環境は削除されません。
• action: stopを含むジョブが、未完了のジョブに依存していることがあります。

action: stopが必要なときに常に実行されるようにするには、次のようにします:

• 両方のジョブを同じステージに配置します:

  stages:
    - build
    - test
    - deploy
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual

• ステージ順に従わなくてもジョブが開始されるように、needsエントリをaction: stopジョブに追加します:

  stages:
    - build
    - test
    - deploy
    - cleanup
  
  ...
  
  deploy_review:
    stage: deploy
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      url: https://$CI_ENVIRONMENT_SLUG.example.com
      on_stop: stop_review
  
  stop_review:
    stage: cleanup
    needs:
      - deploy_review
    environment:
      name: review/$CI_COMMIT_REF_SLUG
      action: stop
    when: manual

エラー: ジョブwould create an environment with an invalid parameter

プロジェクトが動的環境を作成するように設定されている場合、デプロイジョブで以下のエラーが発生する可能性があります。これは、動的に生成されたパラメータは環境の作成に使用できないためです:

This job could not be executed because it would create an environment with an invalid parameter.

たとえば、プロジェクトで.gitlab-ci.ymlが次のように設定されている場合:

deploy:
  script: echo
  environment: production/$ENVIRONMENT

パイプラインに$ENVIRONMENT変数が存在しないため、GitLabはproduction/という名前の環境を作成しようとします。しかしこれは、環境名の制約により無効です。

この問題を修正するには、次のいずれかの解決策を実行します:

• environmentキーワードをデプロイジョブから削除する。GitLabはすでに無効なキーワードを無視しているため、キーワードを削除してもデプロイパイプラインはそのまま維持されます。
• 変数がパイプラインに存在することを確認する。サポートされている変数の制限を確認してください。
• environment:deployment_tierが.gitlab-ci.ymlにある場合は、値がサポートされている階層のいずれかであることを確認してください。production、staging、testing、development、またはother。

レビューアプリでこのエラーが発生した場合

たとえば、.gitlab-ci.ymlが次のように設定されているとします:

review:
  script: deploy review app
  environment: review/$CI_COMMIT_REF_NAME

ブランチ名がbug-fix!の新しいマージリクエストを作成すると、reviewジョブはreview/bug-fix!という環境を作成しようとします。しかし、!は環境名として無効な文字であるため、デプロイジョブは環境なしで実行しようとして失敗します。

この問題を修正するには、次のいずれかの解決策を実行します:

• 無効な文字を含まないbug-fixなどの名前でフィーチャーブランチを作り直す。

• CI_COMMIT_REF_NAME定義済み変数を、無効な文字を除去するCI_COMMIT_REF_SLUGに置き換える:

  review:
    script: deploy review app
    environment: review/$CI_COMMIT_REF_SLUG