- Auto DevOps requirements for Kubernetes
- Auto DevOps requirements for Amazon ECS
- Auto DevOps requirements for Amazon EC2
- Auto DevOps requirements for bare metal
You can set up Auto DevOps for Kubernetes, Amazon Elastic Container Service (ECS), or Amazon Cloud Compute. For more information about Auto DevOps, see the main Auto DevOps page or the quick start guide.
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+.
For external HTTP traffic, an Ingress controller is required. For regular deployments, any Ingress controller should work, but as of GitLab 14.0, canary deployments require NGINX Ingress. You can deploy the NGINX Ingress controller to your Kubernetes cluster either through the GitLab Cluster management project template or manually by using the
ingress-nginxHelm chart.If your cluster is installed on bare metal, see Auto DevOps Requirements for bare metal.
You must specify the Auto DevOps base domain, which all of your Auto DevOps applications use. This domain must be configured with wildcard DNS.
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.
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 the GitLab integration with Kubernetes, you can instruct GitLab to query an in-cluster Prometheus by enabling the Prometheus cluster integration.
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 can 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.
After all requirements are met, you can enable Auto DevOps.
Introduced in GitLab 13.0.
You can choose to target AWS ECS as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD 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
AUTO_DEVOPS_PLATFORM_TARGETvariable with one of the following values:
FARGATEif the service you’re targeting must be of launch type FARGATE.
ECSif you’re not enforcing any launch type check when deploying to ECS.
When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly entered AWS credentials as variables, your application is deployed to AWS ECS.
If you have both a valid
AUTO_DEVOPS_PLATFORM_TARGET variable and a Kubernetes cluster tied to your project,
only the deployment to Kubernetes runs.
ECStriggers 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. Do not override these jobs’ names in your own pipeline, as the override stops working when the name changes.
Introduced in GitLab 13.6.
You can target AWS EC2 as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a specific CI/CD variable.
For more details, see Custom build job for Auto DevOps for deployments to AWS EC2.
According to the Kubernetes Ingress-NGINX docs:
In traditional cloud environments, where network load balancers are available on-demand, a single Kubernetes manifest suffices to provide a single point of contact to the NGINX Ingress controller to external clients and, indirectly, to any application running inside the cluster. Bare-metal environments lack this commodity, requiring a slightly different setup to offer the same kind of access to external consumers.
The docs linked above explain the issue and present possible solutions, for example: