デプロイボード
GitLabのデプロイボードは、Kubernetes上で稼働する各CI環境の現在の健全性とステータスを統合的に表示し、デプロイ中のポッドのステータスを表示します。 開発者や他のチームメイトは、Kubernetesにアクセスする必要なく、既に使用しているワークフローでポッドごとにロールアウトの進捗とステータスを確認できます。
概要
デプロイボードを使用することで、デプロイをより深くインサイトすることができます：
- デプロイ完了後だけでなく、最初からデプロイをフォロー
- 複数のサーバーにまたがるビルドのロールアウトの監視
- 状態の詳細（成功、実行中、失敗、保留、不明）
- カナリアのデプロイを見る
本番環境のデプロイボードの例です。
四角は、Kubernetesクラスター内の、指定された環境に関連付けられているポッドを表しています。 各四角の上にカーソルを置くと、デプロイがロールアウトされている状態を確認できます。 パーセンテージは、最新リリースに更新されているポッドの割合です。
デプロイボードはKubernetesと緊密に連携しているため、必要な知識がいくつかあります。 特に、以下の知識に精通している必要があります：
ユースケース
デプロイボードは、特定の環境のKubernetesポッドを視覚的に表現するものなので、多くの使用例があります。 いくつか挙げると、以下の通りです：
- ステージングで実行されているものを本番環境に昇格させたい場合、環境リストに行き、ステージングで実行されているものがあなたが考えているものであることを確認し、本番環境にデプロイする手動アクションをクリックします。
- デプロイをトリガーし、アップグレードするコンテナがたくさんあるので、時間がかかることは分かっています（一度にX個のコンテナしかダウンしないようにデプロイのスロットルも設定されています）。 しかし、デプロイが完了したら誰かに伝える必要があるので、環境リストに移動し、本番環境を見て、各ポッドがロールされる進捗状況をリアルタイムで確認します。
- 本番環境で何かがおかしいというレポーターがいたら、本番環境を見て、何が動いているのか、デプロイが進行中なのか、止まっているのか、失敗しているのかを確認します。
- あなたは良さそうなMRを手に入れましたが、ステージングが本番に近い形でセットアップされているため、ステージングで実行したいと思います。 環境リストで興味のあるレビューアプリを見つけ、手動アクションをクリックしてステージングにデプロイします。
デプロイボードの有効化
特定の環境のデプロイボードを表示するには、次のようにします：
-
デプロイステージのある環境を定義しました。
-
Kubernetesクラスターを稼働させてください。
OpenShift での実行:OpenShift を使用している場合は、DeploymentConfigurationの代わりにDeploymentリソースを使用していることを確認してください。 そうしないと、デプロイボードが正しくレンダリングされません。 詳細については、OpenShift のドキュメントとGitLab issue #4584をお読みください。 - GitLab Runnerを DockerまたはKubernetesexecutorで設定します。
- プロジェクトでクラスター用のKubernetesインテグレーションを設定します。 Kubernetes名前空間は、デプロイスクリプトに必要なので特に注意してください（
KUBE_NAMESPACEenv変数で公開されます）。 -
app.gitlab.com/env: $CI_ENVIRONMENT_SLUG、app.gitlab.com/app: $CI_PROJECT_PATH_SLUGのKubernetesアノテーションがデプロイメント、レプリカセット、ポッドに適用されていることを確認します。$CI_ENVIRONMENT_SLUG、$CI_PROJECT_PATH_SLUGはCI変数の値です。 これは、複数存在する可能性のあるクラスター/ネームスペースで適切な環境を検索できるようにするためです。 これらのリソースは、Kubernetesサービス設定で定義されたネームスペースに含まれている必要があります。使用するステージとコマンドが事前に定義されており、アノテーションを自動的に適用するAutodeploy.gitlab-ci.ymlテンプレートを使用できます。 各プロジェクトは、Kubernetesでも固有のネームスペースを持つ必要があります。以下の画像は、Kubernetes内部でこれがどのように表示されるかを示しています。注:Kubernetesappラベルに基づくマッチングはGitLab 12.1で削除されました。移行するには、必要なアノテーション（上記を参照）を適用し、アプリケーションを再デプロイしてください。 Auto DevOps を使用している場合、これは自動的に行われ、アクションは必要ありません。
上記のすべての設定が完了し、パイプラインが少なくとも1回実行されたら、Operations > Environmentsから環境ページに移動します。
デプロイボードはデフォルトで表示されています。 非表示にするには、それぞれの環境名の横にある三角形をクリックしてください。
マニフェストファイルの例
次の例は Kubernetes マニフェスト デプロイ ファイルの抜粋で、app.gitlab.com/env とapp.gitlab.com/app の 2 つのアノテーションを使用してデプロイ ボードを有効にしています：
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}のようにレプリカの数を変更することで、ボードからインスタンスのポッドを追うことができます。
kubectl applyを使って適用する場合、手動でプロジェクトと環境のスラッグを指定するか、適用する前に YAML の変数を置き換えるスクリプトを作成しなければなりません。カナリアのデプロイ
よく使われる CI 戦略で、フリート内のごく一部がアプリケーションの新しいバージョンに更新されます。
