Go to Qiita Advent Calendar Top
LoginSignup
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

環境、AWSへのデプロイ、K8sへのデプロイ、K8sダッシュボード、環境ダッシュボード、運用ダッシュボード、レビューApp

Posted at

環境、AWSへのデプロイ、K8sへのデプロイ、K8sダッシュボード、環境ダッシュボード、運用ダッシュボード、レビューApp

(トップページはこちら) - (アプリケーションのデプロイとリリースを始める)

GitLabのCI/CD機能を活用すると、開発からプロダクションまでの一連のデプロイメントフローを効率的に管理できます。本記事では、Review Apps、Environments、Kubernetes統合、各種ダッシュボードといった機能を組み合わせて、実践的なデプロイメント環境を構築する方法を解説します。

1. Review Apps: マージ前に変更を確認する

Review Appsは、ブランチやマージリクエストごとに自動的に作成される一時的なテスト環境です。ローカル環境のセットアップなしに、変更内容をプレビューして検証できます。

主な利点

  • ローカルセットアップが不要でチーム全員が同じ環境でテスト可能
  • ステークホルダーがURLで変更内容をプレビュー可能
  • プロダクション到達前のフィードバックサイクルを高速化

1.1 Review Appsのワークフロー

1.2 基本的な設定

.gitlab-ci.ymlにReview App用のジョブを追加します。$CI_COMMIT_REF_SLUG変数を使用することで、ブランチ名から安全なURL形式の文字列が生成されます。

review_app:
  stage: deploy
  script:
    - echo "Review App環境へデプロイ"
    # デプロイコマンドをここに追加
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.example.com
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH

1.3 自動停止の設定

リソースを節約するため、Review Appを自動的に停止する設定が重要です。

マージリクエストのマージ時に自動停止

deploy_review:
  stage: deploy
  script:
    - echo "Review Appをデプロイ"
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    url: https://${CI_ENVIRONMENT_SLUG}.example.com
    on_stop: stop_review_app
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stop_review_app:
  stage: deploy
  script:
    - echo "Review Appを停止"
    # クリーンアップコマンドをここに追加
  environment:
    name: review/${CI_COMMIT_REF_NAME}
    action: stop
  when: manual
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

時間ベースの自動停止

一定期間アクティビティがない場合に自動停止します。

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 week  # 1週間後に自動停止
  rules:
    - if: $CI_MERGE_REQUEST_ID

1.4 Route Maps: ソースファイルから公開ページへ直接移動

Route Mapsを設定すると、ソースファイルから対応する公開ページへ直接ジャンプできます。.gitlab/route-map.ymlファイルを作成します。

# チームデータ
- source: 'data/team.yml'
  public: 'team/'

# ブログ記事（正規表現でパターンマッチ）
- source: /source\/posts\/([0-9]{4})-([0-9]{2})-([0-9]{2})-(.+?)\..*/
  public: '\1/\2/\3/\4/'

# HTMLファイル
- source: /source\/(.+?\.html).*/
  public: '\1'

# その他のファイル
- source: /source\/(.*)/
  public: '\1'

マージリクエストウィジェットやファイルビューから、Review App上の対応ページへ直接アクセスできるようになります。

2. Environments: デプロイメント先を管理する

Environmentsは、アプリケーションの特定のデプロイメント先を表現し、以下を実現します:

  • デプロイメントプロセスの一貫性と再現性の維持
  • どのコードがどこにデプロイされているかの追跡
  • 問題発生時の以前のバージョンへのロールバック
  • 機密環境への不正な変更の防止
  • 環境ごとのデプロイメント変数制御によるセキュリティ境界の維持

2.1 静的環境の作成

静的環境は、通常、連続するデプロイメントで再利用されます。

deploy_staging:
  stage: deploy
  script:
    - echo "ステージングサーバーへデプロイ"
  environment:
    name: staging
    url: https://staging.example.com

2.2 動的環境の作成

動的環境は、通常、CI/CDパイプラインで作成され、単一のデプロイメントでのみ使用されます。Review Appsの機能として活用されます。

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

2.3 動的なURL設定

外部ホスティングプラットフォームがランダムなURLを生成する場合、dotenvファイルを使用して動的にURLを設定できます。

review:
  script:
    # デプロイスクリプトから環境URLを取得
    - DYNAMIC_ENVIRONMENT_URL=$(deploy-script)
    # dotenvファイルに値を追加
    - echo "DYNAMIC_ENVIRONMENT_URL=$DYNAMIC_ENVIRONMENT_URL" >> deploy.env
  artifacts:
    reports:
      dotenv: deploy.env  # dotenvファイルをGitLabに報告
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: $DYNAMIC_ENVIRONMENT_URL  # スクリプトで生成された変数を使用
    on_stop: stop_review

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

2.4 デプロイメント階層

環境には階層を設定できます。これにより、デプロイメント頻度などのDORAメトリクスが正確に計算されます。

deploy_production:
  stage: deploy
  script: deploy-to-production
  environment:
    name: customer-portal
    deployment_tier: production  # 階層を明示的に指定
    url: https://portal.example.com

環境階層の種類

環境階層 環境名の例 用途
production Production、Live 本番環境
staging Staging、Model、Demo ステージング環境
testing Test、QC テスト環境
development Dev、Review apps、Trunk 開発環境
other - その他

2.5 環境のグループ化

環境名に共通のプレフィックスを使用すると、UIで折りたたみ可能なセクションにグループ化されます。これにより、多数のReview App環境を整理できます。

deploy_review:
  stage: deploy
  script:
    - echo "Review Appをデプロイ"
  environment:
    name: review/$CI_COMMIT_REF_SLUG  # review/プレフィックスでグループ化

2.6 環境スコープ付きCI/CD変数

セキュリティを強化するため、CI/CD変数の環境スコープを制限できます。これにより、サプライチェーン攻撃のリスクを軽減します。

環境スコープのマッチング例

以下の4つの環境がある場合:

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

環境スコープは次のようにマッチします:

スコープ / 環境 → production staging review/feature-1 review/feature-2
* マッチ マッチ マッチ マッチ
production マッチ - - -
staging - マッチ - -
review/* - - マッチ マッチ
review/feature-1 - - マッチ -

重要な注意点: 環境スコープ付き変数はrulesやincludeと一緒に使用しないでください。パイプライン作成時に変数が定義されていない可能性があります。

2.7 環境の停止

環境を停止する方法はいくつかあります。

ブランチ削除時の自動停止

deploy_review:
  stage: deploy
  script:
    - echo "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 "Review Appを削除"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

マージリクエストのマージまたはクローズ時の自動停止

マージリクエストパイプラインを使用する場合、停止トリガーが自動的に有効になります。

deploy_review:
  stage: deploy
  script:
    - echo "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 "Review Appを削除"
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_MERGE_REQUEST_ID
      when: manual

時間ベースの自動停止

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop_review_app
    auto_stop_in: 1 week  # 1週間の非アクティブ後に停止
  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

2.8 インシデント管理との連携

プロダクション環境では、以下のような予期しない問題が発生する可能性があります:

  • 依存するクラウドサービスのダウン
  • サードパーティライブラリの非互換性
  • DDoS攻撃
  • インフラストラクチャの設定ミス
  • プロダクションコードのバグ

GitLabのインシデント管理機能と連携することで、重大な問題が発生した際にアラートを受け取れます。アラート統合を設定すると、環境ページに最も深刻度の高いアラートが表示されます。

2.9 自動ロールバック

重大なアラートが検出されると、自動的にロールバックをトリガーできます。GitLabは最新の成功したデプロイメントを選択して再デプロイします。

制限事項

  • デプロイメント実行中にアラートが検出された場合、ロールバックはスキップされます
  • ロールバックは3分間に1回のみ実行されます

有効化手順

  1. 設定 > CI/CDを選択
  2. 自動デプロイメントロールバックを展開
  3. 自動ロールバックを有効にするにチェック
  4. 変更を保存を選択

アラートにはgitlab_environment_nameキーを含める必要があります。

3. クラウドデプロイメント: AWSへのデプロイ

GitLabは、AWSへのデプロイメントを支援するDockerイメージとテンプレートを提供しています。

3.1 GitLabとAWSの認証

セキュリティに関する注意: より安全な方法として、IDトークンとOpenID Connectの使用を検討してください。ただし、この方法は本セクションのガイダンスとは互換性がありません。

認証手順

  1. AWSアカウントにサインイン
  2. IAMユーザーを作成
  3. セキュリティ認証情報からアクセスキーを作成
  4. アクセスキーIDとシークレットアクセスキーを記録
  5. GitLabプロジェクトの設定 > CI/CDで以下のCI/CD変数を設定:
環境変数名 値 備考
AWS_ACCESS_KEY_ID アクセスキーID 保護変数として設定
AWS_SECRET_ACCESS_KEY シークレットアクセスキー 保護変数として設定
AWS_DEFAULT_REGION リージョンコード 使用するAWSサービスが選択したリージョンで利用可能か確認

重要: 保護されていないブランチやタグでGitLab CI/CDを使用する場合は、変数を保護のチェックを外してください。

3.2 AWSコマンドを実行するイメージの使用

AWS CLIを含むイメージを.gitlab-ci.ymlで参照できます。

deploy:
  stage: deploy
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - aws s3 sync ./build s3://my-bucket
    - aws ecs update-service --cluster my-cluster --service my-service --force-new-deployment
  environment: production

GitLabが提供するDockerイメージ:

  • 最新イメージ: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  • GitLabコンテナレジストリでホスト

3.3 ECSへのデプロイ

Amazon ECSクラスターへのデプロイを自動化できます。

前提条件

  • GitLabとAWSの認証が完了していること
  • ECSクラスターが作成されていること
  • ECSサービスやAmazon RDSデータベースなどの関連コンポーネントが作成されていること
  • ECSタスク定義が作成されていること（ECS内またはGitLabプロジェクト内のJSONファイル）

CI/CD変数の設定

環境変数名 値 備考
CI_AWS_ECS_CLUSTER ターゲットとするAWS ECSクラスターの名前 -
CI_AWS_ECS_SERVICE クラスターに紐づくサービスの名前 適切な環境にスコープを設定
CI_AWS_ECS_TASK_DEFINITION タスク定義の名前 ECS内に存在する場合
CI_AWS_ECS_TASK_DEFINITION_FILE タスク定義のJSONファイルパス GitLab内に存在する場合（例: ci/aws/my_task_definition.json）

重要: CI_AWS_ECS_TASK_DEFINITION_FILEとCI_AWS_ECS_TASK_DEFINITIONの両方を定義した場合、CI_AWS_ECS_TASK_DEFINITION_FILEが優先されます。

.gitlab-ci.ymlの設定

include:
  - template: AWS/Deploy-ECS.gitlab-ci.yml

デプロイメントフロー

  1. アプリケーションのDockerイメージがビルドされ、GitLabコンテナレジストリにプッシュされます
  2. ターゲットのタスク定義が新しいDockerイメージの場所で更新され、ECSで新しいリビジョンが作成されます
  3. AWS ECSサービスがタスク定義の新しいリビジョンで更新され、クラスターが最新バージョンのアプリケーションをプルします

注意: ECSデプロイジョブは、ロールアウトが完了するまで待機してから終了します。この動作を無効にするには、CI_AWS_ECS_WAIT_FOR_ROLLOUT_COMPLETE_DISABLEDを空でない値に設定してください。

3.4 EC2へのデプロイ

AWS CloudFormationとS3を使用してEC2にデプロイできます。

デプロイメントフロー

必要なJSONファイル

  1. スタック作成用のCloudFormation JSON
  2. S3へのプッシュ用JSON（以下の詳細を含む）:
{
  "applicationName": "string",
  "source": "string",
  "s3Location": "s3://your/bucket/project_built_file..."
}
  1. EC2デプロイメント用JSON

CI/CD変数の設定

リポジトリにJSONファイルを保存する場合:

variables:
  CI_AWS_CF_CREATE_STACK_FILE: 'aws/cf_create_stack.json'
  CI_AWS_S3_PUSH_FILE: 'aws/s3_push.json'
  CI_AWS_EC2_DEPLOYMENT_FILE: 'aws/create_deployment.json'
  CI_AWS_CF_STACK_NAME: 'YourStackName'

include:
  - template: AWS/CF-Provision-and-Deploy-EC2.gitlab-ci.yml

リポジトリにJSONファイルを保存したくない場合は、各オブジェクトをファイルタイプのCI/CD変数としてプロジェクト設定に追加します。

パイプライン実行時の動作

  1. CI_AWS_CF_CREATE_STACK_FILE変数の内容に基づいてAWS CloudFormationスタックが作成されます（スタックが既に存在する場合、このステップはスキップされますが、プロビジョニングジョブは実行されます）
  2. ビルドされたアプリケーションがS3バケットにプッシュされます
  3. 関連するJSONオブジェクトの内容に基づいてEC2インスタンスにデプロイされます

4. Kubernetes統合: クラスターとの接続

GitLabをKubernetesクラスターと接続することで、クラウドネイティブソリューションのデプロイ、管理、監視が可能になります。

4.1 GitLab Agent for Kubernetesの概要

Kubernetesクラスターに接続するには、まずクラスターにエージェントをインストールする必要があります。エージェントはクラスター内で実行され、以下を可能にします:

  • ファイアウォールやNATの背後にあるクラスターとの通信
  • クラスター内のAPIエンドポイントへのリアルタイムアクセス
  • クラスター内で発生するイベントに関する情報のプッシュ
  • 非常に低いレイテンシで最新の状態に保たれるKubernetesオブジェクトのキャッシュの有効化

重要な設計原則

  • 接続したい各クラスターに個別のエージェントをデプロイする必要があります
  • エージェントは強力なマルチテナンシーサポートを備えて設計されています
  • メンテナンスと運用を簡素化するため、クラスターごとに1つのエージェントのみを実行することを推奨します
  • エージェントは常にGitLabプロジェクトに登録されます
  • 登録およびインストール後、エージェント接続を他のプロジェクト、グループ、ユーザーと共有できます

4.2 アーキテクチャ

4.3 サポートされるKubernetesバージョン

GitLabは以下のKubernetesバージョンをサポートしています:

バージョン サポート終了時期
1.33 GitLab 19.2リリース時または1.36サポート時
1.32 GitLab 18.10リリース時または1.35サポート時
1.31 GitLab 18.7リリース時または1.34サポート時

サポートポリシー

  • GitLabは、新しいマイナーKubernetesバージョンの初回リリースから3ヶ月後にサポートを開始することを目指しています
  • 常に少なくとも3つのプロダクション対応Kubernetesマイナーバージョンをサポートします
  • エージェントをインストールする際は、Kubernetesバージョンと互換性のあるHelmバージョンを使用してください

4.4 デプロイメントワークフロー

2つの主要なワークフローから選択できます。

4.4.1 GitOpsワークフロー（推奨）

Fluxを使用したGitOpsワークフローが推奨されます。

特徴

  • プル型デプロイメント: FluxがGitリポジトリの変更をチェックし、自動的にクラスターに適用
  • より強力なセキュリティモデル
  • プロダクション環境に推奨

4.4.2 GitLab CI/CDワークフロー

CI/CDワークフローでは、GitLab CI/CDがKubernetes APIを使用してクラスターをクエリおよび更新します。

特徴

  • プッシュ型デプロイメント: GitLabがクラスターにリクエストをプッシュ
  • パイプライン駆動のプロセスに適している
  • GitOpsワークフローがユースケースをサポートしていない場合のマイグレーション用
  • より弱いセキュリティモデルのため、プロダクションデプロイメントには推奨されません

4.5 エージェント接続の技術詳細

エージェントは、KAS(GitLab Agent Server for Kubernetes)との通信のために双方向チャネルを開きます:

接続の仕様

  • 各エージェントは最大500の論理gRPCストリーム(アクティブおよびアイドル)を維持可能
  • gRPCストリームが使用するTCP接続数はgRPC自体が決定
  • 各接続の最大ライフタイムは2時間(猶予期間1時間)
  • KASの前にあるプロキシが接続の最大ライフタイムに影響を与える可能性があります（GitLab.comでは2時間）

4.6 用語集

用語 定義 スコープ
GitLab agent for Kubernetes 関連機能と基盤コンポーネント(agentkとkas)を含む全体的な提供物 GitLab、Kubernetes、Flux
agentk Kubernetesの管理とデプロイメント自動化のためにGitLabへの安全な接続を維持するクラスター側コンポーネント GitLab
GitLab agent server for Kubernetes (kas) Kubernetesエージェント統合の操作とロジックを処理するGitLab側コンポーネント。GitLabとKubernetesクラスター間の接続と通信を管理 GitLab
プル型デプロイメント FluxがGitリポジトリの変更をチェックし、自動的にクラスターに適用するデプロイメント方法 GitLab、Kubernetes
プッシュ型デプロイメント GitLab CI/CDパイプラインからKubernetesクラスターに更新が送信されるデプロイメント方法 GitLab
Flux エージェントとプル型デプロイメントのために統合されるオープンソースのGitOpsツール GitOps、Kubernetes
GitOps クラウドおよびKubernetesリソースの管理と自動化にGitをバージョン管理とコラボレーションに使用する実践のセット DevOps、Kubernetes
Kubernetes namespace Kubernetesクラスター内の論理的なパーティション。複数のユーザーや環境間でクラスターリソースを分割 Kubernetes

5. Kubernetes Dashboard: クラスターの状態を可視化

Kubernetes Dashboardは、接続されたクラスターの状態を直感的なビジュアルインターフェースで理解できます。CI/CDまたはGitOpsでデプロイしたすべての接続されたKubernetesクラスターで動作します。

5.1 ダッシュボードの設定

前提条件

  • GitLab agent for Kubernetesがインストールされていること
  • 環境のプロジェクトまたは親グループに対してuser_accessが設定されていること

既存の環境に設定する場合

  1. オペレーション > 環境を選択
  2. エージェントに関連付ける環境を選択
  3. 編集を選択
  4. GitLab agent for Kubernetesを選択
  5. オプション: Kubernetes namespaceドロップダウンリストからネームスペースを選択
  6. オプション: Flux resourceドロップダウンリストからFluxリソースを選択
  7. 保存を選択

新しい環境を作成する場合

  1. オペレーション > 環境を選択
  2. 新しい環境を選択
  3. 名前フィールドに入力
  4. GitLab agent for Kubernetesを選択
  5. オプション: Kubernetes namespaceドロップダウンリストからネームスペースを選択
  6. オプション: Flux resourceドロップダウンリストからFluxリソースを選択
  7. 保存を選択

5.2 動的環境のダッシュボード設定

.gitlab-ci.ymlファイルでエージェントを指定します。エージェント設定プロジェクトへのフルパスの後にコロンとエージェント名を指定する必要があります。

deploy_review_app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    kubernetes:
      agent: path/to/agent/project:agent-name

5.3 ダッシュボードの表示

設定されたダッシュボードを表示するには:

  1. オペレーション > 環境を選択
  2. GitLab agent for Kubernetesに関連付けられた環境を選択
  3. Kubernetes overviewタブを選択

Podのリストが表示されます。Podを選択すると詳細が表示されます。

リアルタイム更新: KubernetesリソースとFlux調整のステータスがリアルタイムで更新されます。

5.4 Flux同期ステータス

ダッシュボードには、Fluxデプロイメントの同期ステータスが表示されます。デプロイメントステータスを表示するには、環境にネームスペースが設定されている必要があります。

GitLabは、環境設定のFlux resourceドロップダウンリストで指定されたKustomizationおよびHelmReleaseリソースを検索します。

ステータスバッジの種類

ステータス 説明
Reconciled デプロイメントが環境と正常に調整された
Reconciling 調整が進行中
Stalled 人間の介入なしには解決できないエラーのため調整が停止
Failed 回復不可能なエラーのためデプロイメントが調整できなかった
Unknown デプロイメントの同期ステータスを取得できなかった
Unavailable KustomizationまたはHelmReleaseリソースを取得できなかった

5.5 Flux調整のトリガー

手動でデプロイメントをFluxリソースと調整できます:

  1. ダッシュボードでFluxデプロイメントの同期ステータスバッジを選択
  2. アクション > 調整をトリガーを選択

5.6 Flux調整の一時停止と再開

UIからFlux調整を手動で一時停止または再開できます:

  1. ダッシュボードでFluxデプロイメントの同期ステータスバッジを選択
  2. アクションを選択し、以下のいずれかを選択:
    • 調整を一時停止: Flux調整を一時停止
    • 調整を再開: Flux調整を再開

5.7 Podログの表示

設定されたダッシュボードから環境全体の問題を迅速に理解し、トラブルシューティングできます。各Pod内の各コンテナのログを表示できます。

  • ログを表示を選択し、ログを表示したいコンテナを選択

Pod詳細からもPodログを表示できます。

5.8 Podの削除

失敗したPodを再起動するには、Kubernetesダッシュボードから削除します:

  1. Kubernetes overviewタブで削除したいPodを見つける
  2. アクション > Podを削除を選択

Pod詳細からもPodを削除できます。

5.9 詳細ダッシュボード（ベータ）

詳細ダッシュボードは、以下のKubernetesリソースに関する情報を提供します:

  • Pods
  • Services
  • Deployments
  • ReplicaSets
  • StatefulSets
  • DaemonSets
  • Jobs
  • CronJobs

各ダッシュボードには、ステータス、ネームスペース、経過時間を含むリソースのリストが表示されます。リソースを選択すると、ラベル、YAML形式のステータス、アノテーション、仕様を含む詳細情報を含むドロワーが開きます。

注意: この機能はテスト用に利用可能ですが、プロダクション使用には対応していません。

詳細ダッシュボードの表示

詳細ダッシュボードはサイドバーナビゲーションからリンクされていません。

  1. GitLab agent for KubernetesのIDを確認:
    • オペレーション > Kubernetesクラスターを選択
    • アクセスしたいエージェントの数値IDをコピー
  2. 以下のURLのいずれかに移動（<agent_id>をエージェントIDに置き換え）:
リソースタイプ URL
Pods https://myinstance.gitlab.com/-/kubernetes/<agent_id>/pods
Services https://myinstance.gitlab.com/-/kubernetes/<agent_id>/services
Deployments https://myinstance.gitlab.com/-/kubernetes/<agent_id>/deployments
ReplicaSets https://myinstance.gitlab.com/-/kubernetes/<agent_id>/replicaSets
StatefulSets https://myinstance.gitlab.com/-/kubernetes/<agent_id>/statefulSets
DaemonSets https://myinstance.gitlab.com/-/kubernetes/<agent_id>/daemonSets
Jobs https://myinstance.gitlab.com/-/kubernetes/<agent_id>/jobs
CronJobs https://myinstance.gitlab.com/-/kubernetes/<agent_id>/cronJobs

6. Environments Dashboard: プロジェクト横断の環境ビュー

Environments Dashboardは、プロジェクト横断の環境ベースのビューを提供し、各環境で何が起こっているかの全体像を把握できます。単一の場所から、開発からステージング、そしてプロダクションへと変更が流れる進捗を追跡できます。

主な利点

  • 複数プロジェクトの一目でわかるビューで、どのパイプラインが成功し、どれが失敗しているかを即座に確認
  • 特定のポイントでブロックがあるか、調査が必要なより体系的な問題があるかを診断
  • 最大3つの環境を各プロジェクトに表示

6.1 ダッシュボードへのアクセス

  1. 検索または移動を選択
  2. あなたの作業を選択
  3. 環境を選択

6.2 プロジェクトの追加

  1. ダッシュボードのホーム画面でプロジェクトを追加を選択
  2. プロジェクトを検索フィールドを使用して1つ以上のプロジェクトを検索して追加
  3. プロジェクトを追加を選択

追加すると、各プロジェクトの環境運用状態の概要が表示されます:

  • 最新のコミット
  • パイプラインステータス
  • デプロイメント時刻

重要な注意点

  • Review Appsやその他のグループ化された環境は表示されません
  • EnvironmentsダッシュボードとOperationsダッシュボードは同じプロジェクトリストを共有します
  • 一方からプロジェクトを追加または削除すると、もう一方にも反映されます
  • 最大150のプロジェクトを追加できます

6.3 GitLab.comでの利用

  • パブリックプロジェクトは無料でEnvironments Dashboardに追加できます
  • プライベートプロジェクトの場合、所属するグループにGitLab Premiumプランが必要です

7. Operations Dashboard: 運用状態の概要

Operations Dashboardは、各プロジェクトの運用状態の概要を提供します:

  • パイプラインステータス
  • アラートステータス
  • 最後のコミット
  • 最後のデプロイメント時刻

7.1 ダッシュボードへのアクセス

  1. 検索または移動を選択
  2. あなたの作業を選択
  3. オペレーションを選択

7.2 プロジェクトの追加

前提条件

Prometheusで設定したアラートにgitlab_environment_nameラベルが含まれていることを確認してください。この値はGitLabの環境名と一致する必要があります。現在、production環境のアラートのみ表示できます。

追加手順

  1. ダッシュボードのホーム画面でプロジェクトを追加を選択
  2. プロジェクトを検索フィールドを使用して1つ以上のプロジェクトを検索して追加
  3. プロジェクトを追加を選択

追加すると、ダッシュボードには以下が表示されます:

  • プロジェクトのアクティブなアラート数
  • 最新のコミット
  • パイプラインステータス
  • 最後のデプロイメント時刻

7.3 ダッシュボード上のプロジェクトの並び替え

プロジェクトカードをドラッグして順序を変更できます。

注意: カードの順序は現在ブラウザにのみ保存されるため、他のユーザーのダッシュボードには影響しません。

7.4 デフォルトダッシュボードとして設定

Operations Dashboardをサインイン時に表示されるデフォルトのGitLabダッシュボードにすることもできます。設定するには、プロフィール設定を参照してください。

8. まとめ

GitLabのデプロイメント環境管理機能を活用することで、以下のような実践的なワークフローを構築できます:

1. 開発フェーズ

  • Review Appsでマージ前に変更を確認し、フィードバックサイクルを高速化
  • Route Mapsでソースファイルから公開ページへ直接ナビゲーション

2. デプロイメント管理

  • Environmentsで開発からプロダクションまでの各段階を明確に管理
  • 環境スコープ付きCI/CD変数でセキュリティを強化
  • デプロイメント階層でDORAメトリクスを正確に計算

3. クラウド統合

  • AWS統合でECSやEC2へのデプロイメントを自動化
  • GitLab提供のDockerイメージとテンプレートで迅速なセットアップ

4. Kubernetes統合

  • GitOpsワークフロー（Flux）でセキュアなプル型デプロイメント
  • GitLab CI/CDワークフローでパイプライン駆動のデプロイメント
  • Kubernetes Dashboardでクラスターの状態をリアルタイムで可視化

5. 運用監視

  • Environments Dashboardで複数プロジェクトの環境状態を一元管理
  • Operations Dashboardでパイプラインとアラートステータスを監視
  • インシデント管理と自動ロールバックで障害対応を自動化

推奨される導入アプローチ

  1. 小規模なプロジェクトでReview Appsから開始
  2. 静的環境（staging、production）を設定
  3. 環境スコープ付きCI/CD変数でセキュリティを強化
  4. Kubernetes統合を導入（GitOpsワークフロー推奨）
  5. ダッシュボードで複数プロジェクトの可視化を実現

これらの機能を段階的に導入することで、チーム全体の開発効率を向上させ、デプロイメントプロセスの透明性と信頼性を高めることができます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?