To make full use of Auto DevOps with Kubernetes, you need:
To enable deployments, you need:
- A Kubernetes 1.12+ cluster for your project. The easiest way is to create a new cluster using the GitLab UI. For Kubernetes 1.16+ clusters, you must perform additional configuration for Auto Deploy for Kubernetes 1.16+.
NGINX Ingress. You can deploy it to your Kubernetes cluster by installing the GitLab-managed app for Ingress, after configuring GitLab’s Kubernetes integration in the previous step.
Alternatively, you can use the
nginx-ingressHelm chart to install Ingress manually.Note: If you use your own Ingress instead of the one provided by GitLab’s managed apps, ensure you’re running at least version 0.9.0 of NGINX Ingress and enable Prometheus metrics for the response metrics to appear. You must also annotate the NGINX Ingress deployment to be scraped by Prometheus using
You need a domain configured with wildcard DNS, which all of your Auto DevOps applications will use. If you’re using the GitLab-managed app for Ingress, the URL endpoint is automatically configured for you.
You must also specify the Auto DevOps base domain.
GitLab Runner (for all stages)
Your Runner must be configured to run Docker, usually with either the Docker or Kubernetes executors, with privileged mode enabled. The Runners don’t need to be installed in the Kubernetes cluster, but the Kubernetes executor is easy to use and automatically autoscales. You can configure Docker-based Runners to autoscale as well, using Docker Machine.
If you’ve configured GitLab’s Kubernetes integration in the first step, you can deploy it to your cluster by installing the GitLab-managed app for GitLab Runner.
Runners should be registered as shared Runners for the entire GitLab instance, or specific Runners that are assigned to specific projects (the default if you’ve installed the GitLab Runner managed application).
Prometheus (for Auto Monitoring)
To enable Auto Monitoring, you need Prometheus installed either inside or outside your cluster, and configured to scrape your Kubernetes cluster. If you’ve configured GitLab’s Kubernetes integration, you can deploy it to your cluster by installing the GitLab-managed app for Prometheus.
To get response metrics (in addition to system metrics), you must configure Prometheus to monitor NGINX.
cert-manager (optional, for TLS/HTTPS)
To enable HTTPS endpoints for your application, you must install cert-manager, a native Kubernetes certificate management controller that helps with issuing certificates. Installing cert-manager on your cluster issues a Let’s Encrypt certificate and ensures the certificates are valid and up-to-date. If you’ve configured GitLab’s Kubernetes integration, you can deploy it to your cluster by installing the GitLab-managed app for cert-manager.
After all requirements are met, you can enable Auto DevOps.
Introduced in GitLab 13.0.
You can choose to target Amazon Elastic Container Service (ECS) as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to Amazon ECS, you’ll have to add a specific Environment Variable. To do so, follow these steps:
In your project, go to Settings > CI / CD and expand the Variables section.
Specify which AWS platform to target during the Auto DevOps deployment by adding the
Give this variable the value
ECSbefore saving it.
When you trigger a pipeline, if Auto DevOps is enabled and if you’ve correctly entered AWS credentials as environment variables, your application will be deployed to Amazon ECS.
AUTO_DEVOPS_PLATFORM_TARGETvariable and a Kubernetes cluster tied to your project, only the deployment to Kubernetes will run.
ECSwill trigger jobs defined in the
Jobs/Deploy/ECS.gitlab-ci.ymltemplate. However, it’s not recommended to include it on its own. This template is designed to be used with Auto DevOps only. It may change unexpectedly causing your pipeline to fail if included on its own. Also, the job names within this template may also change. Don’t override these jobs’ names in your own pipeline, as the override will stop working when the name changes.