Requirements for Auto DevOps (FREE)

Before enabling Auto DevOps, we recommend you to prepare it for deployment. If you don't, you can use it to build and test your apps, and then configure the deployment later.

To prepare the deployment:

Auto DevOps deployment strategy

Introduced in GitLab 11.0.

When using Auto DevOps to deploy your applications, choose the continuous deployment strategy that works best for your needs:

Deployment strategy	Setup	Methodology
Continuous deployment to production	Enables Auto Deploy with the default branch continuously deployed to production.	Continuous deployment to production.
Continuous deployment to production using timed incremental rollout	Sets the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.	Continuously deploy to production with a 5 minutes delay between rollouts.
Automatic deployment to staging, manual deployment to production	Sets `STAGING_ENABLED` to `1` and `INCREMENTAL_ROLLOUT_MODE` to `manual`.	The default branch is continuously deployed to staging and continuously delivered to production.

You can choose the deployment method when enabling Auto DevOps or later:

In GitLab, on the top bar, select Main menu > Projects and find your project.
On the left sidebar, select Settings > CI/CD.
Expand Auto DevOps.
Choose the deployment strategy.
Select Save changes.

NOTE: Use the blue-green deployment technique to minimize downtime and risk.

Auto DevOps base domain

The Auto DevOps base domain is required to use Auto Review Apps, Auto Deploy, and Auto Monitoring.

To define the base domain, either:

In the project, group, or instance level: go to your cluster settings and add it there.
In the project or group level: add it as an environment variable: KUBE_INGRESS_BASE_DOMAIN.
In the instance level: go to Main menu > Admin > Settings > CI/CD > Continuous Integration and Delivery and add it there.

The base domain variable KUBE_INGRESS_BASE_DOMAIN follows the same order of precedence as other environment variables.

If you don't specify the base domain in your projects and groups, Auto DevOps uses the instance-wide Auto DevOps domain.

Auto DevOps requires a wildcard DNS A record that matches the base domains. For a base domain of example.com, you'd need a DNS entry like:

*.example.com   3600     A     1.2.3.4

In this case, the deployed applications are served from example.com, and 1.2.3.4 is the IP address of your load balancer, generally NGINX (see requirements). Setting up the DNS record is beyond the scope of this document; check with your DNS provider for information.

Alternatively, you can use free public services like nip.io which provide automatic wildcard DNS without any configuration. For nip.io, set the Auto DevOps base domain to 1.2.3.4.nip.io.

After completing setup, all requests hit the load balancer, which routes requests to the Kubernetes pods running your application.

Auto DevOps requirements for Kubernetes

To make full use of Auto DevOps with Kubernetes, you need:

Kubernetes (for Auto Review Apps, Auto Deploy, and Auto Monitoring)

To enable deployments, you need:
1. A Kubernetes 1.12+ cluster for your project. For Kubernetes 1.16+ clusters, you must perform additional configuration for Auto Deploy for Kubernetes 1.16+.
2. 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-nginx Helm chart.
  
  NOTE: For metrics to appear when using the Prometheus cluster integration, you must enable Prometheus metrics.
  
  When deploying using custom charts, you must also annotate the Ingress manifest to be scraped by Prometheus using prometheus.io/scrape: "true" and prometheus.io/port: "10254".
  
  NOTE: If your cluster is installed on bare metal, see Auto DevOps Requirements for bare metal.
Base domain (for Auto Review Apps, Auto Deploy, and Auto Monitoring)

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.

Runners should be registered as shared runners for the entire GitLab instance, or project runners that are assigned to specific projects.
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.

The Prometheus integration integration must be activated for the project, or activated at the group or instance level. For more information, see Project integration management.

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.

If you don't have Kubernetes or Prometheus configured, then Auto Review Apps, Auto Deploy, and Auto Monitoring are skipped.

After all requirements are met, you can enable Auto DevOps.

Auto DevOps requirements for bare metal

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:

Through MetalLB.
Through PorterLB.