TECHSTEP

ITインフラ関連の記事を公開してます。

GitLab Environmentの概要を紹介する

今回はGitLab Environmentの概要を紹介します。

docs.gitlab.com

背景

GitLabのEnvironmentは、GitLab内でコードがどの場所にデプロイされたかの「場所」を表すリソースです。この場所というのは、例えばクラウド上に実際に環境を作るわけではなく、GitLab上にのみ存在する仮想的な空間です。

GitLab Environmentは、以下のような情報を保有します。

  • Name: Environmentごとに production staging などの名前を設定します。
  • Status: Environmentは available stopping stopped という状態を持ちます。例えばEnvironmentを削除するには、利用可能な状態 (available) から停止を開始し (stopping) 、停止状態 (stopped) にする必要があります。
  • URL: Environmentには固定の、あるいは動的なURLを付与できます。新しいコミットからデプロイまで完了したあと、GitLab画面からWebの画面に移動できます。
  • Deployment: GitLab CI/CDで、あるバージョンのコードがEnvironmentにデプロイされると、そのたびにDeploymentというリソースが作成されます。各EnvironmentはDeploymentの全履歴を提供し、いつ何がEnvironmentにデプロイされたかを追跡できます。

※Environmentの概要図を作ってみました。

Environmentには以下のような特徴があります。

  • デプロイの履歴のみを追跡できる: EnvironmentのDeploymentはCI/CDでEnvironmentを指定したdeploy Jobが実行されると作成されます。そのため、GitLabのコミット履歴からデプロイに関する履歴のみを取り出したものが見られるので、いつ何をデプロイしたか追跡しやすくなります。なおGitLab以外でデプロイを実行した場合もDeploymentに履歴を残すことができます。
  • Roll back機能がある: EnvironmentはDeploymentごとに再デプロイかRoll backを実行できます。再デプロイ・Roll backのいずれも、特定のコミットを指定してDeployment jobのみを再実行するよう動作します。これにより過去のコミットへのRoll backを実現します。
  • Environmentごとに環境変数を制限できる: GitLab CI/CD変数はEnvironment単位にスコープを制限できます。例えばテスト環境と本番環境で異なるSecret情報を使ってデプロイする場合、テスト環境向けのJobから本番環境の情報にアクセスできてしまうと、セキュリティ攻撃を受けた際に本番環境へのアクセスを許してしまう可能性があります。これを防ぐため、変数ごとにEnvironment Scopeを定めることが推奨されます。
  • GitLabの他機能と連動する: EnvironmentはGitLab上の他の機能とも連動します。例えばDORA metricsを利用するにはEnvironmentが必須であり、Deployment frequencyの計算などに利用します。

なお、Environmentの利用有無に限らないですが、CI/CDの中でもデプロイは特に注意して扱うべきJobです。GitLabではDeployment Jobに関する推奨事項をドキュメントとして提供しています。

docs.gitlab.com

検証

今回はGitLab FreeプランでEnvironmentを簡単に利用してみます。 事前に以下のような .gitlab-ci.yml を用意し、Merge requestやコミットをいくつか実行しておきます。

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  rules:
    - when: always
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

test-job:
  stage: test
  rules:
    - when: always
  script:
    - echo "Running unit tests..."
    - echo "Complete test."

deploy-job-at-test:
  stage: deploy
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  environment: 
    name: testing
    url: https://testing.example.com
  script:
    - echo "Deploying application to test environment..."
    - echo "Application successfully deployed."

deploy-job-at-staging:
  stage: deploy
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      changes:
        - doc/**.md
      when: always
    - if: $CI_COMMIT_BRANCH == "main"
      changes:
        - .gitlab-ci.yml
      when: never
  environment: 
    name: staging
    url: https://staging.example.com
  script:
    - echo "Deploying application to staging environment..."
    - echo "Application successfully deployed."

deploy-job-at-production:
  stage: deploy
  rules:
    - when: manual
  environment: 
    name: production
    url: https://production.example.com
  script:
    - echo "Deploying application to production environment..."
    - echo "Application successfully deployed."

CI/CDからEnvironmentを作成する

EnvironmentはGitLabの画面上から、または.gitlab-ci.ymlから作成できます。.gitlab-ci.ymlから作成する場合は、以下のように environment というパラメータを指定します。

create-environment-example-job:
  script:
    - echo “Create Environment.”
  environment:
    name: production

なお .gitlab-ci.yml で利用できるEnvironment関連のパラメータは以下に記載されています。

docs.gitlab.com

CI/CD完了後、GitLab画面から 操作環境 (日本語の場合)に移動します。ここでは3つのEnvironmentを確認できます。

画面上では、最新のDeploymentの確認やEnvironmentの停止などを操作できます。

各Environmentを選択するとDeploymentの履歴が表示されます。関連するコミットやJob、何がトリガーになったか(ここではMerge requestの作成やマージなどを操作した私がトリガーです)などを確認できます。

なおEnvironmentへはMerge request画面やProjectのトップ画面からも移動できます。

URLの設定

EnvironmentごとにURLを設定している場合、Environment画面では以下のように表示されます。赤枠部分をクリックすれば指定したURLに移動します。

なおURLは、Merge request画面やDeployment画面からも選択できます。

Roll backの実行

Roll backを実行するには、各Environment画面に移動し、アクションから実行します。

以下の画像の様に 環境のロールバックというボタンを選択します。

確認画面が表示されるので 環境のロールバック を選択します。

すると、新しいDeploymentが起動することを確認できます。前述の通り、ここではCI/CDのうちDeploy Jobのみを再実行しています。

しばらくすればDeploymentも完了することを確認できます。

その他

Environmentに関連したいくつかの機能はPremium / Ultimateプランでのみ利用可能です。

  • Incident managementとの連携: GitLabのIncident management機能と連動し、最新のアラート情報を確認したり (Ultimateプラン) 、Critical alert発生時に自動的にRoll backする (Ultimateプラン) 機能を提供します。
  • Protected environment: 適切なユーザーのみがDeployment Jobを実行できるよう、Environmentを保護します。
  • Deployment approval: Protected environmentに対し、指定の承認がなければJobを実行しないよう制御します。
  • Environment dashboard: ProjectをまたいだEnvironment専用のダッシュボードを提供します。

参考リンク