デプロイボード（非推奨）

GitLabデプロイボードは、Kubernetes上で実行されている各CI環境の現在の正常性とステータスをまとめて表示し、デプロイメント内のポッドのステータスを表示します。デベロッパーや他のチームメイトは、Kubernetesにアクセスしなくても、すでに使用しているワークフローで、ロールアウトの進捗とステータスをポッドごとに確認できます。

デプロイボードを使用すると、次のような利点により、デプロイに関するインサイトをより深く得ることができます:

• 最初からデプロイを追跡できる（完了時だけでなく）
• 複数のサーバーにわたるビルドのロールアウトを監視できる
• より詳細な状態（成功、実行中、失敗、保留中、不明）
• カナリアデプロイを参照してください。

これは本番環境のデプロイボードの例です。

正方形は、指定された環境に関連付けられているKubernetesクラスター内のポッドを表しています。各正方形の上にマウスを置くと、デプロイのロールアウトの状態を確認できます。パーセンテージは、最新のリリースに更新されたポッドの割合です。

デプロイボードはKubernetesと密接に結合しているため、以下について理解しておく必要があります:

• Kubernetesのポッド
• Kubernetesラベル
• Kubernetesのネームスペース
• Kubernetesカナリアデプロイメント

ユースケース

デプロイボードは、特定の環境のKubernetesポッドを視覚的に表現したものであるため、多くのユースケースがあります。いくつか例を挙げます:

• ステージングで実行されているものを本番にプロモートしたいとします。そこで、環境リストに移動し、ステージングで実行されているものが想定どおりであることを確認し、本番にデプロイするための手動ジョブを選択します。
• デプロイをトリガーし、アップグレードするコンテナが多数あるため、時間がかかることがわかっています（一度にX個のコンテナしかダウンさせないように、デプロイを調整しました）。しかし、デプロイされたときに誰かに伝える必要があるので、環境リストに移動し、本番環境を見て、各ポッドがロールアウトされるにつれて、進捗状況がリアルタイムでどうなっているかを確認します。
• 本番で何かおかしいというレポートを受け取ったので、本番環境を見て、何が実行されているか、そしてデプロイが進行中か、停止しているか、または失敗したかを確認します。
• 見栄えの良いマージリクエストがありますが、ステージングが本番に近い方法でセットアップされているため、ステージングで実行したいと考えています。そこで、環境リストに移動し、関心のあるレビューアプリを見つけて、それをステージングにデプロイするための手動アクションを選択します。

デプロイボードの有効化

特定のenvironmentのデプロイボードを表示するには、次のようにします:

1. デプロイステージで定義された環境が必要です。

2. Kubernetesクラスターが起動して実行されている必要があります。

   OpenShiftを使用している場合は、DeploymentではなくDeploymentConfigurationリソースを使用していることを確認してください。そうしないと、デプロイボードが正しくレンダリングされません。詳細については、OpenShiftドキュメントとGitLabイシュー＃4584を参照してください。

3. dockerまたはkubernetes executorでGitLab Runnerを構成します。

4. クラスターのプロジェクトでKubernetesインテグレーションを構成します。Kubernetesネームスペースは、KUBE_NAMESPACECI/CD変数によって公開されるデプロイスクリプトに必要となるため、特に注意が必要です。

5. app.gitlab.com/env: $CI_ENVIRONMENT_SLUGおよびapp.gitlab.com/app: $CI_PROJECT_PATH_SLUGのKubernetes注釈がデプロイメント、レプリカセット、およびポッドに適用されていることを確認してください。ここで、$CI_ENVIRONMENT_SLUGと$CI_PROJECT_PATH_SLUGはCI/CD変数の値です。これは、複数のクラスター / ネームスペースにある可能性のある適切な環境をルックアップできるようにするためです。これらのリソースは、Kubernetesサービスの設定で定義されたネームスペースに含まれている必要があります。定義済みのステージと使用するコマンドがあり、注釈を自動的に適用する自動デプロイ .gitlab-ci.ymlテンプレートを使用できます。各プロジェクトには、Kubernetesに一意のネームスペースも必要です。下の図は、これがKubernetes内でどのように表示されるかを示しています。

   GCPを使用してクラスターを管理している場合は、Workloads（ワークロード） > deployment name（デプロイ名） > 詳細に移動して、GCP自体でデプロイの詳細を確認できます:

   

これまでのすべての手順をセットアップし、パイプラインを少なくとも1回実行したら、操作 > 環境の下の環境ページに移動します。

デプロイボードはデフォルトで表示されます。それぞれの環境名の横にある三角形を明示的に選択して、非表示にすることができます。

マニフェストファイルの例

次の例は、2つの注釈app.gitlab.com/envとapp.gitlab.com/appを使用してdeploy boards（デプロイボード）を有効にするKubernetesマニフェストデプロイメントファイルからの抜粋です:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: "APPLICATION_NAME"
  annotations:
    app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
    app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: "APPLICATION_NAME"
  template:
    metadata:
      labels:
        app: "APPLICATION_NAME"
      annotations:
        app.gitlab.com/app: ${CI_PROJECT_PATH_SLUG}
        app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}

これらの注釈は、デプロイメント、レプリカセット、およびポッドに適用されます。kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}のように、レプリカの数を変更することで、ボードからインスタンスのポッドを追跡できます。

カナリアデプロイ

一般的なCI戦略。フリートのほんの一部が、アプリケーションの新しいバージョンに更新されます。

カナリアデプロイメントの詳細をご覧ください。

さらに詳しく

• GitLab自動デプロイ
• GitLab CI/CD変数
• 環境とデプロイ
• Kubernetesデプロイの例