8.0 KiB
stage | group | info | type |
---|---|---|---|
Release | Release | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments | howto, reference |
Deploy Boards (CORE)
- Introduced in GitLab Premium 9.0.
- Moved to GitLab Core in 13.7.
GitLab's Deploy Boards offer a consolidated view of the current health and status of each CI environment running on Kubernetes, displaying the status of the pods in the deployment. Developers and other teammates can view the progress and status of a rollout, pod by pod, in the workflow they already use without any need to access Kubernetes.
Overview
With Deploy Boards you can gain more insight into deploys with benefits such as:
- Following a deploy from the start, not just when it's done
- Watching the rollout of a build across multiple servers
- Finer state detail (Succeeded, Running, Failed, Pending, Unknown)
- See Canary Deployments
Here's an example of a Deploy Board of the production environment.
The squares represent pods in your Kubernetes cluster that are associated with the given environment. Hovering above each square you can see the state of a deploy rolling out. The percentage is the percent of the pods that are updated to the latest release.
Since Deploy Boards are tightly coupled with Kubernetes, there is some required knowledge. In particular, you should be familiar with:
In GitLab 13.5 and earlier, apps that consist of multiple deployments are shown as duplicates on the deploy board. This is fixed in GitLab 13.6.
Use cases
Since the Deploy Board is a visual representation of the Kubernetes pods for a specific environment, there are a lot of use cases. To name a few:
- You want to promote what's running in staging, to production. You go to the environments list, verify that what's running in staging is what you think is running, then click on the manual action to deploy to production.
- You trigger a deploy, and you've got lots of containers to upgrade so you know it'll take a while (you've also throttled your deploy to only take down X containers at a time). But you need to tell someone when it's deployed, so you go to the environments list, look at the production environment to see what the progress is in real-time as each pod is rolled.
- You get a report that something is weird in production, so you look at the production environment to see what is running, and if a deploy is ongoing or stuck or failed.
- You've got an MR that looks good, but you want to run it on staging because staging is set up in some way closer to production. You go to the environment list, find the Review App you're interested in, and click the manual action to deploy it to staging.
Enabling Deploy Boards
To display the Deploy Boards for a specific environment you should:
-
Have defined an environment with a deploy stage.
-
Have a Kubernetes cluster up and running.
NOTE: If you are using OpenShift, ensure that you're using the
Deployment
resource instead ofDeploymentConfiguration
. Otherwise, the Deploy Boards won't render correctly. For more information, read the OpenShift docs and GitLab issue #4584. -
Configure GitLab Runner with the
docker
orkubernetes
executor. -
Configure the Kubernetes integration in your project for the cluster. The Kubernetes namespace is of particular note as you will need it for your deployment scripts (exposed by the
KUBE_NAMESPACE
environment variable). -
Ensure Kubernetes annotations of
app.gitlab.com/env: $CI_ENVIRONMENT_SLUG
andapp.gitlab.com/app: $CI_PROJECT_PATH_SLUG
are applied to the deployments, replica sets, and pods, where$CI_ENVIRONMENT_SLUG
and$CI_PROJECT_PATH_SLUG
are the values of the CI variables. This is so we can lookup the proper environment in a cluster/namespace which may have more than one. These resources should be contained in the namespace defined in the Kubernetes service setting. You can use an Autodeploy.gitlab-ci.yml
template which has predefined stages and commands to use, and automatically applies the annotations. Each project will need to have a unique namespace in Kubernetes as well. The image below demonstrates how this is shown inside Kubernetes.NOTE: Matching based on the Kubernetes
app
label was removed in GitLab 12.1. To migrate, please apply the required annotations (see above) and re-deploy your application. If you are using Auto DevOps, this will be done automatically and no action is necessary.If you are using GCP to manage clusters, you can see the deployment details in GCP itself by going to Workloads > deployment name > Details:
Once all of the above are set up and the pipeline has run at least once, navigate to the environments page under Operations > Environments.
Deploy Boards are visible by default. You can explicitly click the triangle next to their respective environment name in order to hide them.
Example manifest file
The following example is an extract of a Kubernetes manifest deployment file, using the two annotations app.gitlab.com/env
and app.gitlab.com/app
to enable the Deploy Boards:
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}
The annotations will be applied to the deployments, replica sets, and pods. By changing the number of replicas, like kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}
, you can follow the instances' pods from the board.
NOTE:
The YAML file is static. If you apply it using kubectl apply
, you must
manually provide the project and environment slugs, or create a script to
replace the variables in the YAML before applying.
Canary Deployments
A popular CI strategy, where a small portion of the fleet is updated to the new version of your application.
Read more about Canary Deployments.