ボードのデプロイ（非推奨）
フラグ: セルフマネジメントのGitLabでは、デフォルトではこの機能は利用できません。利用可能にするには、管理者がcertificate_based_clustersという機能フラグを有効にします。
GitLab デプロイボードは、Kubernetes 上で稼働している各 CI環境の現在の健全性とステータスを統合的に表示し、デプロイ内のポッドのステータスを表示します。開発者や他のチームメイトは、Kubernetesにアクセスすることなく、既に使用しているワークフローでポッドごとにロールアウトの進捗とステータスを確認できます。
概要
デプロイボードを使用することで、デプロイをより深く理解することができます：
- デプロイが完了したときだけでなく、最初からデプロイをフォローすることができます。
- 複数のサーバーにまたがるビルドのロールアウトの監視
- 状態の詳細（成功、実行中、失敗、保留、不明）
- Canaryデプロイを参照してください。
本番環境のデプロイボードの例です。
四角は、Kubernetesクラスタ内の、指定した環境に関連するポッドを表しています。各四角の上にカーソルを置くと、デプロイがロールアウトされている状態を見ることができます。パーセンテージは、最新リリースにアップデートされたポッドの割合です。
デプロイボードはKubernetesと緊密に連携しているため、必要な知識がいくつかあります。特に
ユースケース
デプロイボードは特定の環境のKubernetesポッドを視覚的に表現したものなので、多くの使用例があります。いくつか挙げると
- ステージングで実行しているものを本番環境に昇格させたい場合。環境リストに行き、ステージングで実行されているものがあなたが考えているものであることを確認し、本番環境にデプロイする手動ジョブを選択します。
- デプロイを開始し、アップグレードするコンテナがたくさんあるので、時間がかかることは分かっています（一度にX個のコンテナしかダウンしないようにデプロイのスロットルも設定されています）。しかし、デプロイが完了したら誰かに伝える必要があるので、環境リストを表示して本番環境を見て、各ポッドがロールされる進捗状況をリアルタイムで確認します。
- 本番環境で何かがおかしいというレポーターが来たので、本番環境を見て、何が実行されているのか、デプロイが進行中なのか、止まっているのか、失敗したのかを確認します。
- 良さそうなMRがあるのですが、ステージング環境の方が本番環境に近い設定になっているため、ステージング環境で実行したいとします。環境リストに行き、興味のあるレビューアプリを見つけ、手動アクションを選択してステージングにデプロイします。
デプロイボードの有効化
特定の環境のデプロイボードを表示するには、次のようにします：
-
デプロイステージのある環境を定義していること。
-
Kubernetesクラスターが稼働していること。
OpenShift を使用している場合は、DeploymentConfigurationの代わりにDeploymentリソースを使用していることを確認してください。そうしないと、デプロイボードが正しくレンダリングされません。詳しくはOpenShiftのドキュメントと GitLab issue #4584を読んでください。 -
GitLab Runnerを
dockerまたはkubernetesExecutor で設定します。 - プロジェクトでKubernetesインテグレーションをクラスター用に設定します。Kubernetes名前空間はデプロイスクリプトに必要なので、特に注意してください（
KUBE_NAMESPACEデプロイ変数によって公開されます）。 -
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サービス設定で定義された名前空間にコンテナされている必要があります。あらかじめ定義されたステージと使用するコマンドを持ち、アノテーションを自動的に適用するAuto deploy.gitlab-ci.ymlテンプレートを使用できます。各プロジェクトは、Kubernetesでも一意の名前空間を持っている必要があります。以下の画像は、Kubernetes内でどのように表示されるかを示しています。Kubernetesappラベルに基づくマッチングはGitLab 12.1で削除されました。マイグレーションするには、必要なアノテーション（上記を参照）を適用し、アプリケーションをデプロイし直してください。Auto DevOpsを使用している場合、これは自動的に行われ、アクションは必要ありません。クラスターを管理するために GCP を使用している場合、GCP 自体でWorkloads > deployment name > Detailsに移動してデプロイの詳細を見ることができます：
上記のすべての設定が完了し、パイプラインが少なくとも1回実行されたら、[Operate] > [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の変数を置き換えるスクリプトを作成する必要があります。Canaryのデプロイ
よく使われるCI戦略で、フリート内のごく一部が新しいバージョンのアプリケーションにアップデートされます。