環境とデプロイメント
GitLab 8.9 で導入されました。
GitLabでは、ソフトウェアの継続的デプロイメントを環境によって制御することができます。
導入
ソフトウェア開発プロセスでは、ソフトウェアが市場に提供されるまでに多くのステップが必要です。
使用例:
- 開発する
- テストする
- プロダクトを公開する前に、テスト環境やステージング環境にデプロイしましょう。
これは、ソフトウェアのバグを見つけるのに役立ちます。また、デプロイメントプロセスにおいても同様です。
GitLab CI/CDは、プロジェクトのテストやビルドだけでなく、インフラストラクチャへのデプロイも可能です。これは、デプロイを追跡する方法を提供するという付加的なメリットになります。言い換えれば、現在何がデプロイされているのか、あるいはサーバーにデプロイされているのかを常に知ることができます。
重要なこと:
- 環境はCIジョブのタグのようなもので、コードがデプロイされる場所を記述します。
- ジョブが環境にコードのバージョンをデプロイするときにデプロイメントが作成されるので、すべての環境に1つ以上のデプロイメントを持つことができます。
GitLab:
- 各環境のデプロイの完全な履歴を提供します。
- デプロイメントを追跡することで、現在何がサーバーにデプロイされているかを常に知ることができます。
Kubernetesなどのプロジェクトに関連するデプロイサービスがあれば、それを使ってデプロイを支援したり、GitLab内から自分の環境のWebターミナルにアクセスすることができます。
環境設定
環境の設定には、以下を含みます:
- パイプラインの仕組みを理解する
- プロジェクトの
.gitlab-ci.yml
ファイルで環境を定義します。 - アプリケーションをデプロイするように設定されたジョブを作成します。たとえば、
environment
で設定されたデプロイジョブは、アプリケーションを Kubernetesクラスターにデプロイします。
このセクションの残りの部分では、シナリオの例を挙げて環境とデプロイメントを設定する方法を説明します。すでに以下のことを行っていることを想定しています:
シナリオは次のような内容です:
- アプリケーションを開発しています
- すべてのブランチでアプリのテスト実行とビルドをしたいと考えています
- デフォルトのブランチは
master
です。 -
master
ブランチのパイプラインが実行されたときにのみ、アプリをデプロイします。
環境の定義
次の.gitlab-ci.yml
の例を見てみましょう:
stages:
- test
- build
- deploy
test:
stage: test
script: echo "Running tests"
build:
stage: build
script: echo "Building the app"
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
only:
- master
3つのステージを定義しています:
test
build
deploy
これらのステージに割り当てられたジョブは、この順番で実行されます。いずれかのジョブが失敗した場合、パイプラインは失敗し、次のステージに割り当てられたジョブは実行されません。
この場合は:
-
test
のジョブが最初に実行されます。 - それから
build
。 - 最後に
deploy_staging
のジョブ。
この設定では:
- テストが通過することを確認します
- アプリが正常にビルドできることを確認します
- 最後に、ステージング サーバーにデプロイします
environment
キーワードはアプリがデプロイされる場所を定義します。環境name
とurl
は GitLab 内のさまざまな場所で公開されています。環境が指定されたジョブが成功するたびに、デプロイが Git SHA と環境名とともに記録されます。-
,_
,/
,{
,}
,.
のみを使用してください。また、/
で始まったり、 で終わったりしてはいけません。まとめると、上記.gitlab-ci.yml
、私たちは以下のことを達成しました:
- すべてのブランチで
test
とbuild
のジョブが実行されます。 -
deploy_staging
ジョブはmaster
ブランチでのみ実行されます。つまり、ブランチから作成されたマージリクエストはすべてステージングサーバーにはデプロイされません。 - マージリクエストがマージされると、すべてのジョブが実行され、
deploy_staging
ジョブはステージングサーバーにコードをデプロイし、デプロイはstaging
という名前の環境に記録されます。
環境変数, Runner
GitLab 8.15以降、環境名は2つの方式でRunnerに公開されます:
-
$CI_ENVIRONMENT_NAME
.gitlab-ci.yml
で指定された名前(変数があれば展開)。 -
$CI_ENVIRONMENT_SLUG
URLやDNSなどで使用するのに適した、「クリーンアップ」された名前のバージョン。
既存の環境の名前を変更した場合:
-
$CI_ENVIRONMENT_NAME
変数が新しい環境名で更新されます。 -
$CI_ENVIRONMENT_SLUG
変数が変更されないのは、意図しない副作用を防ぐためです。
GitLab 9.3から、環境URLは$CI_ENVIRONMENT_URL
経由でRunnerに公開されるようになりました。 URLはどちらかから展開されます:
-
.gitlab-ci.yml
. -
.gitlab-ci.yml
で定義されていない場合は、環境からの内部 URL。
ジョブ終了後に動的環境の URL を設定する
GitLab 12.9で導入されました。
ジョブスクリプトでは、静的な環境URLを指定することができます。 しかし、動的なURLが必要な場合もあります。例えば、デプロイごとにランダムなURLを生成する外部ホスティングサービスにレビューアプリをデプロイする場合、https://94dd65b.amazonaws.com/qa-lambda-1234567
、デプロイスクリプトが終了する前にURLを知ることはできません。 GitLabで環境URLを使用する場合は、手動で更新する必要があります。
この問題に対処するために、デプロイジョブを設定して、外部サービスによって動的に生成された URL を含む変数のセットをレポートバックすることができます。 GitLab はdotenv (.env
) ファイル形式をサポートしており、environment:url
の値を.env
ファイルで定義された変数で展開します。
この機能を使用するには、.gitlab-ci.yml
でartifacts:reports:dotenv
キーワードを指定します。
概要については、ジョブ終了後に動的URLを設定するを参照してください。
動的環境URLの設定例
次の例では、マージリクエストごとに新しい環境を作成するレビューアプリを示しています。review
ジョブはプッシュされるたびにトリガーされ、review/your-branch-name
という名前の環境を作成または更新します。 環境の URL は$DYNAMIC_ENVIRONMENT_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
review
のジョブが終了するとすぐに、GitLab はreview/your-branch-name
環境の URL を更新します。deploy.env
レポートアーティファクトを解析し、実行時に作成された変数リストを登録し、environment:url: $DYNAMIC_ENVIRONMENT_URL
の展開に使用し、環境の URL に設定します。https://$DYNAMIC_ENVIRONMENT_URL
のように、environment:url:
で URL の静的な部分を指定することもできます。DYNAMIC_ENVIRONMENT_URL
の値がexample.com
の場合、最終的な結果はhttps://example.com
になります。
review/your-branch-name
環境に割り当てられた URL がUI に表示されます。
注:
stop_review
はdotenvレポートのアーティファクトを生成しないので、DYNAMIC_ENVIRONMENT_URL
変数を認識しません。したがって、stop_review
ジョブでenvironment:url:
を設定すべきではありません。- 環境URLが有効でない場合(URLが不正な場合など)、システムは環境URLを更新しません。
手動デプロイメント設定
自動実行されるジョブの設定にwhen: manual
を追加すると、手動操作が必要なジョブに変換されます。
先ほどの例を発展させるために、production
環境によって追跡される、アプリを本番サーバーにデプロイする別のジョブを以下に示します。
そのための.gitlab-ci.yml
ファイルは以下の通りです:
stages:
- test
- build
- deploy
test:
stage: test
script: echo "Running tests"
build:
stage: build
script: echo "Building the app"
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
only:
- master
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
environment:
name: production
url: https://example.com
when: manual
only:
- master
when: manual
アクション:
- GitLab の UI 上に、そのジョブの “play” ボタンが表示されます。
- つまり、
deploy_prod
のジョブは、”play” ボタンがクリックされたときのみ起動されます。
“play” ボタンは、パイプライン、環境、デプロイメント、ジョブの各ビューに存在します。
表示 | スクリーンショット |
---|---|
パイプライン | ![]() |
単一パイプライン | ![]() |
環境 | ![]() |
デプロイメント | ![]() |
ジョブ | ![]() |
どのビューでも再生ボタンをクリックすると、deploy_prod
ジョブがトリガーされ、production
という新しい環境としてデプロイが記録されます。
production
(すべて小文字)の場合、production
Value Stream Analyticsにproduction
記録されます。動的環境の設定
ステージングや本番環境のような「安定した」環境にデプロイする場合は、通常の環境が良いでしょう。
しかし、master
以外のブランチの環境については、動的環境を使うことができます。動的環境では、.gitlab-ci.yml
で動的に名前を宣言することで、その場で環境を作成することができます。
動的環境は Review Apps の基本的な部分です。
使用可能な変数
動的環境用のname
とurl
パラメーターは、CI/CD で利用可能なほとんどの変数を使用できます:
ただし、定義済み変数は使えません:
- アンダー
script
. - Runnerで定義されている変数
また、environment:name
のコンテキストではサポートされていない変数もあります。詳しくは、変数が使用できる場所を参照してください。
設定例
GitLab Runner は、ジョブの実行時にさまざまな 環境変数 を公開します。
以下の例では、ジョブはmaster
を除くすべてのブランチにデプロイされます:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
only:
- branches
except:
- master
この例では:
- ジョブ名は
deploy_review
、deploy
ステージで実行されます。 -
environment
environment:name
review/$CI_COMMIT_REF_NAME
環境名にはスラッシュ(/
)を含めることができるので、このパターンを使って動的環境と通常の環境を区別することができます。 - ジョブにブランチで
only
、except
master
。
このような値の場合:
-
environment:name
最初の部分はreview
、続いて/
、そして$CI_COMMIT_REF_NAME
、ブランチ名の値を受け取ります。 -
environment:url
$CI_COMMIT_REF_NAME
、ドメイン名やURLでは無効となる やその他の文字が含まれている可能性があるため、 、有効なURLの取得を保証します。/
$CI_ENVIRONMENT_SLUG
例えば、
100-Do-The-Thing
という$CI_COMMIT_REF_NAME
を指定すると、URLはhttps://100-do-the-4f99a2.example.com
のようになります。繰り返しますが、ウェブサーバーがこれらのリクエストに対応するように設定する方法は、あなたの設定に基づいています。ここでは
$CI_ENVIRONMENT_SLUG
を使いましたが、これは一意であることが保証されているからです。GitLab Flow のようなワークフローを使っている場合、衝突する可能性は低く、ブランチ名に近い環境名を好むかもしれません。 その場合、$CI_COMMIT_REF_NAME
をenvironment:url
で使うことができます。上の例ではhttps://$CI_COMMIT_REF_NAME.example.com
となり、URL はhttps://100-do-the-thing.example.com
となります。
Kubernetesデプロイメントの設定
GitLab 12.6 で導入されました。
プロジェクトに関連付けられたKubernetesクラスターにデプロイする場合は、gitlab-ci.yml
ファイルからこれらのデプロイを設定できます。
以下の設定オプションがサポートされています:
以下の例では、ジョブはアプリケーションをproduction
Kubernetes ネームスペースにデプロイします。
deploy:
stage: deploy
script:
- echo "Deploy to production server"
environment:
name: production
url: https://example.com
kubernetes:
namespace: production
only:
- master
GitLab の Kubernetes 連携を利用して Kubernetes クラスタにデプロイする場合、クラスタとネームスペースに関する情報がデプロイジョブのページのジョブのトレース情報に表示されます:
インクリメンタルロールアウト設定
インクリメンタルロールアウトを使用して、Kubernetesポッドの一部のみに本番の変更をリリースする方法を学びます。
デプロイメントの安全性
デプロイメントのジョブは、パイプラインの中の他のジョブよりも外部の影響を受けやすいので、丁寧なケアが必要になるかもしれません。GitLab には、デプロイメントのセキュリティと安定性を維持するための複数の機能があります。
完成例
このセクションの設定では、アプリが以下のような完全な開発ワークフローを提供します:
- テスト
- ビルド
- Review Appとしてデプロイ
- マージリクエストがマージされたら、ステージング サーバーにデプロイ
- 最後に、本番サーバーに手動でデプロイ
以下は、これまでの設定例を組み合わせたものです:
stages:
- test
- build
- deploy
test:
stage: test
script: echo "Running tests"
build:
stage: build
script: echo "Building the app"
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
only:
- branches
except:
- master
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
environment:
name: staging
url: https://staging.example.com
only:
- master
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
environment:
name: production
url: https://example.com
when: manual
only:
- master
より現実的な例としては、ウェブサーバ(例えばNGINX)がアクセスしてサービスを提供できる場所にファイルをコピーすることも含みます。
以下の例では、public
ディレクトリを/srv/nginx/$CI_COMMIT_REF_SLUG/public
にコピーします:
review_app:
stage: deploy
script:
- rsync -av --delete public /srv/nginx/$CI_COMMIT_REF_SLUG
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_COMMIT_REF_SLUG.example.com
この例では、このジョブが実行されるサーバーに NGINX と GitLab Runner がセットアップされている必要があります。
完成例では、開発者に以下のようなワークフローを提供しています:ローカルにブランチを作成する
- ローカルにブランチを作成する
- 変更を加えてコミットする
- GitLabにブランチの変更をプッシュする
- マージリクエストを作成する
GitLab Runnerはこれらの裏で次のようなことをしています:
- 変更をピックアップし、ジョブの実行を開始します
-
stages
で定義されているように、ジョブを順次実行します:- まず、テストを実行します
- テストが成功した場合、アプリをビルドします
- ビルドに成功した場合、アプリはブランチに固有の名前を持つ環境にデプロイされます
そして、全てのブランチに以下を行います:
- 独自の環境を提供する
- 独自の場所にデプロイする。それによって、以下の利点があります:
- デプロイの履歴を持つことができる
- 必要に応じて、変更をロールバックできる
詳細については、環境の URL を使うを参照してください。
保護された環境
アクセスを制限することにより、環境を”保護”できます。
詳細は、保護された環境を参照してください。
環境の操作
環境が構成されると、GitLabは環境を操作するための多くの機能を提供します。
環境とデプロイメントの表示
環境とデプロイメントの状態の一覧は、各プロジェクトの[オペレーション] > [環境]ページで確認できます。
使用例:
この例では、以下のように表示されます:
- 環境の名前とそのデプロイメントへのリンク
- 最後のデプロイメントIDとそれを実行した人
- 最後のデプロイメントのジョブIDとそれぞれのジョブ名
- 最後のデプロイメントのコミット情報 (誰がコミットしたのか、どのブランチにコミットしたのか、コミットのGit SHAなど)
- 最後のデプロイメントが実行された正確な時刻
-
.gitlab-ci.yml
のenvironment
キーワードで定義した URL に移動するボタンです。 - 最新のデプロイを再デプロイするボタン。つまり、特定のコミットの環境名で定義されたジョブを実行する
環境ページに表示される情報は最新のデプロイメントに限定されますが、一つの環境に複数のデプロイメントを含めることができます。
注:
- ウェブインターフェイスで手動で環境を作成することもできますが、最初に
.gitlab-ci.yml
で環境を定義することをお勧めします。最初のデプロイ後に自動的に環境が作成されます。- 環境ページは、Reporter パーミッションを持つユーザーのみが閲覧できます。 パーミッションの詳細については、パーミッションのドキュメントを参照してください。
.gitlab-ci.yml
が適切に設定された後に行われたデプロイのみが、[環境]リストと [最後のデプロイ] リストに表示されます。
デプロイに関する履歴の表示
GitLabではデプロイの記録を保持します:
- 現在サーバーに何がデプロイされているかを常に知ることができます
- 全ての環境に関するデプロイの完全な履歴を持つことができます
環境をクリックすると、その環境のデプロイの履歴が表示されます。以下は、複数のデプロイメントを持つEnvironmentsページの例です:
このビューは 環境 ページに似ていますが、全てのデプロイメントが表示されます。また、このビューには ロールバック ボタンがあります。詳細については、再試行とロールバックを参照してください。
再試行とロールバック
デプロイで問題が発生した場合に、再試行またはロールバックできます。
デプロイを再試行またはロールバックするには:
- Operations > Environmentsを開きます
- 環境をクリックします
- 環境のデプロイ履歴リストで下記を実行します:
- 前回の配置の横にある再試行ボタンをクリックして、その配置を再試行します
- 前に配置が成功したときの横にあるロールバックボタンをクリックすると、その配置にロールバックします
ロールバック実施時に期待すること
特定のコミットのロールバックボタンを押すと、独自のジョブIDを持つ 新しい デプロイが起動します。
これは、ロールバック先のコミットを指す新しいデプロイが表示されることを意味します。
script
で定義されたデプロイプロセスによって、ロールバックが成功するかどうかが決まります。環境URLを利用する
環境URLはGitLab内で公開されています:
この情報は、以下の場合にマージリクエスト上で直接確認することができます:
- マージリクエストは最終的にデフォルトブランチ (通常は
master
) にマージされます。 - そのブランチも環境(たとえば、
staging
やproduction
)にデプロイされます。
使用例:
ソースファイルから公開ページへ
GitLab の ルートマップ を使うと、ソースファイルからReview Appsに設定されている環境にある公開ページへのアクセスを停止します。
環境の停止
環境を停止する:
- Environmentsページにある利用可能な環境リストから停止中の環境リストに移動します
-
on_stop
アクションを実行します。
これは、複数人の開発者が同時に同じプロジェクトでの作業をして、それぞれのブランチにプッシュしている場合によく使われ、多くの動的な環境が作られる原因となります。
環境を自動的に停止する
環境は特別な設定を使って自動的に停止させることができます。
deploy_review
のジョブがstop_review
を呼び出して環境をクリーンアップし、停止する例を考えてみましょう:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_ENVIRONMENT_SLUG.example.com
on_stop: stop_review
only:
- branches
except:
- master
stop_review:
stage: deploy
variables:
GIT_STRATEGY: none
script:
- echo "Remove review app"
when: manual
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
ブランチが削除された後に GitLab Runnerがコードをチェックアウトしようとしないように、stop_review
のジョブでGIT_STRATEGY
をnone
に設定する必要があります。
停止アクションが定義されている環境がある場合(通常、その環境がレビューアプリを記述している場合)、関連するブランチが削除されると、GitLab は自動的に停止アクションをトリガーします。環境が自動的に停止するためには、stop_review
ジョブがdeploy_review
ジョブと同じstage
にある必要があります。
さらに、両方のジョブはrules
もしくはonly/except
の設定が一致している必要があります。上の例で、設定が一致していない場合、stop_review
ジョブはdeploy_review
ジョブを含むすべてのパイプラインに含まれず、action: stop
をトリガーして自動的に環境を停止することができないかもしれません。
詳しくは.gitlab-ci.yml
referenceをご覧ください。
環境オートストップ
GitLab 12.8で導入されました。
環境に有効期限を設定し、一定期間経過後に自動的に停止させることができます。
たとえば、レビューアプリ環境でのこの機能の使用について考えてみましょう。 レビューアプリをセットアップしたとき、いくつかのマージリクエストが未解決のままになっているために、長い間実行され続けることがあります。 このような状況の例として、マージリクエストの作成者が優先順位の変更や別のアプローチが決定されたために積極的に取り組んでおらず、単にマージリクエストが忘れられている場合があります。 アイドル環境はリソースを浪費するので、できるだけ早く終了させるべきです。
この問題に対処するために、レビューアプリ環境にオプションで有効期限を指定することができます。 有効期限に達すると、GitLabは自動的に環境を停止するジョブをトリガーし、手動で停止する必要がなくなります。 環境が更新された場合、有効期限はアクティブなマージリクエストのみがレビューアプリを実行し続けることを保証するために更新されます。
この機能を有効にするには、.gitlab-ci.yml
でenvironment:auto_stop_in
キーワードを指定する必要があります。値として、1 hour and 30 minutes
や1 day
のように、人にわかりやすい日付を指定することができます。auto_stop_in
は、artifacts:expire_in
docsと同じ書式を使用します。
オートストップの例
次の例では、マージリクエストごとに新しい環境を作成する基本的なレビューアプリがセットアップされています。review_app
ジョブはプッシュされるたびに起動し、review/your-branch-name
という名前の環境を作成または更新します。stop_review_app
が実行されるまで、この環境は実行され続けます:
review_app:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_NAME
on_stop: stop_review_app
auto_stop_in: 1 week
stop_review_app:
script: stop-review-app
environment:
name: review/$CI_COMMIT_REF_NAME
action: stop
when: manual
マージリクエストがアクティブで新しいコミットを取得し続けている限り、レビューアプリは停止しません。
一方、stop_review_app
はauto_stop_in: 1 week
に設定されているので、マージリクエストが一週間以上非アクティブになると、GitLab は自動的にstop_review_app
ジョブをトリガーして環境を停止します。
環境の有効期限はGitLabのUIからも確認することができます。 そのためには、オペレーション> 環境 > 環境と進みます。 左上のセクションに自動停止期間が表示され、右上のセクションにピンマークのボタンがあります。 このピンマークのボタンを使って環境の自動停止を防ぐことができます。このボタンをクリックすると、auto_stop_in
の設定が上書きされ、手動で停止させるまで環境がアクティブになります。
停止した環境の削除
GitLab 12.10 で導入されました。
停止した環境を削除するには、GitLab UIかAPIの2つの方法があります。
UIによる環境削除
停止した環境のリストを表示するには、オペレーション> 環境に移動し、[停止した環境]タブをクリックします。
そこから直接削除ボタンをクリックするか、環境名をクリックして詳細を表示し、そこから削除することができます。
停止している環境の詳細を見ることで環境を削除することもできます:
- Operations > Environmentsを開きます
- 停止中の環境リスト内の環境名をクリックします。
- 停止しているすべての環境の上部に表示される削除ボタンをクリックしてください。
- 最後に、表示されたモーダルで選択した環境を確認して削除します。
APIによる環境削除
環境は、Environments APIを使用して削除することもできます。
類似環境のグループ化
GitLab 8.14 で導入されました。
動的環境の構成で説明されているように、環境名の前に単語を付け、その後に/
を付け、最後にブランチ名を付けることができます。ブランチ名はCI_COMMIT_REF_NAME
変数によって自動的に定義されます。
つまり、type/foo
のような名前の環境は、すべてtype
という同じグループで表示されます。
最小限の例では、review/$CI_COMMIT_REF_NAME
という環境名をつけました。$CI_COMMIT_REF_NAME
はブランチ名です。以下はそのスニペットです:
deploy_review:
stage: deploy
script:
- echo "Deploy a review app"
environment:
name: review/$CI_COMMIT_REF_NAME
この場合、環境ページにアクセスし、ブランチが存在すれば、次のように表示されるはずです:
監視環境
Prometheusでシステムメトリクスとレスポンスメトリクスの監視を有効にしている場合、各環境で実行されているアプリの動作を監視できます。 監視ダッシュボードを表示するには、Prometheusで少なくとも1つのサポートされているメトリクスを収集するように設定する必要があります。
設定が完了すると、GitLab はデプロイに成功した環境に対してサポートされているパフォーマンスメトリクスの取得を試みます。 モニタリングデータの取得に成功した場合、各環境に対してMonitoringボタンが表示されます。
モニタリング]ボタンをクリックすると、過去8時間分のパフォーマンスデータを表示する新しいページが表示されます。 初期デプロイ後、データが表示されるまで1~2分かかる場合があります。
環境へのすべてのデプロイはモニタリングダッシュボードに直接表示され、GitLabを離れることなく、パフォーマンスの変化とアプリの新バージョンを簡単に相関させることができます。
GitLab Flavored Markdownにメトリクスを埋め込む
メトリクスチャートはGitLab Flavored Markdownに埋め込むことができます。 詳しくはGitLab Flavored Markdownにメトリクスを埋め込むをご覧ください。
ウェブ端末
WebターミナルはGitLab 8.15で追加され、プロジェクトのメンテナーとオーナーだけが利用できます。
デプロイサービス(例えばKubernetesインテグレーション)の助けを借りて環境にデプロイする場合、GitLabはあなたの環境へのターミナルセッションを開くことができます。
この機能を有効にするには、サービス・インテグレーション・ドキュメントの指示に従ってください。
有効にすると、あなたの環境には「ターミナル」ボタンが追加されます:
特定の環境のページからターミナルボタンにアクセスすることもできます:
ボタンをクリックすると、ターミナルセッションを確立するための別のページに移動します:
これは他のターミナルと同じように動作します。 デプロイによって作成されたコンテナ内にいるので、以下のことができます:
- シェルコマンドを実行し、リアルタイムで応答を取得します。
- ログを確認してください。
- 設定やコードの微調整などをお試しください。
同じ環境に複数のターミナルを開くことができ、それぞれ独自のシェルセッションと、screen
やtmux
のようなマルチプレクサを利用できます。
ローカルでのデプロイチェック
GitLab 8.13以降、Gitリポジトリの参照はデプロイごとに保存されるので、現在の環境の状態を知るにはgit fetch
。
gitの設定で、[remote "<your-remote>"]
ブロックに追加のフェッチ行を追加します:
fetch = +refs/environments/*:refs/remotes/origin/environments/*
スペックによる環境構築
- GitLab Premium9.4から導入されました。
- 環境変数のスコープはGitLab 12.2 でCore に移動しました。
変数の環境スコープを制限するには、その変数が利用可能な環境を定義します。
ワイルドカードを使うことができ、デフォルトの環境スコープは*
です。これは、環境が定義されているかどうかに関係なく、すべてのジョブがこの変数を持つことを意味します。
例えば、環境スコープがproduction
, production
であるproduction
場合、その環境が production
定義されたproduction
ジョブのみが production
この特定の変数を持つことになります。環境名と共にワイルドカード (*
) を使用することができます。したがって、環境スコープがreview/*
である場合、review/
で始まる環境名を持つすべてのジョブがこの特定の変数を持つことになります。
GitLabの機能の中には、環境ごとに動作が異なるものがあります。 例えば、本番環境のみに注入する秘密変数を作成することができます。
ほとんどの場合、これらの機能は_環境仕様の_メカニズムを使用しており、各環境グループ内でスコープを実装する効率的な方法を提供しています。
4つの環境があるとしましょう:
production
staging
review/feature-1
review/feature-2
各環境は、以下の環境仕様に合わせることができます:
環境仕様 | production
| staging
| review/feature-1
| review/feature-2
|
---|---|---|---|---|
* | 一致 | 一致 | 一致 | 一致 |
生産 | 一致 | |||
ステージング | 一致 | |||
review/* | 一致 | 一致 | ||
レビュー/特集-1 | 一致 |
ご覧のように、特定のマッチングを使用して特定の環境を選択したり、ワイルドカードマッチング(*
)を使用してレビューアプリ(review/*
)などの特定の環境グループを選択することができます。
review/feature-1
の仕様が、review/*
と*
の仕様よりも優先されます。環境ダッシュボード
各環境のオペレーション状況の概要については、環境ダッシュボードをご覧ください。
制限事項
environment: name
では、あらかじめ定義された環境変数のみに制限されています。script
内部で環境名の一部として定義された変数を再利用することはできません。
さらに読む
以下のリンクは興味深いものです: