2021-01-29 00:20:46 +05:30
---
stage: Configure
group: Configure
2022-11-25 23:54:43 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2021-03-11 19:13:27 +05:30
# Requirements for Auto DevOps **(FREE)**
2020-06-23 00:09:42 +05:30
2021-10-27 15:23:28 +05:30
Before enabling [Auto DevOps ](index.md ), 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:
1. Define the [deployment strategy ](#auto-devops-deployment-strategy ).
1. Prepare the [base domain ](#auto-devops-base-domain ).
2022-07-23 23:45:48 +05:30
1. Define where you want to deploy it:
2021-10-27 15:23:28 +05:30
1. [Kubernetes ](#auto-devops-requirements-for-kubernetes ).
2022-07-23 23:45:48 +05:30
1. [Amazon Elastic Container Service (ECS) ](cloud_deployments/auto_devops_with_ecs.md ).
1. [Amazon Elastic Kubernetes Service (EKS) ](https://about.gitlab.com/blog/2020/05/05/deploying-application-eks/ ).
1. [Amazon EC2 ](cloud_deployments/auto_devops_with_ec2.md ).
1. [Google Kubernetes Engine ](cloud_deployments/auto_devops_with_gke.md ).
2021-10-27 15:23:28 +05:30
1. [Bare metal ](#auto-devops-requirements-for-bare-metal ).
1. [Enable Auto DevOps ](index.md#enable-or-disable-auto-devops ).
## Auto DevOps deployment strategy
2022-08-13 15:12:31 +05:30
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38542) in GitLab 11.0.
2021-10-27 15:23:28 +05:30
When using Auto DevOps to deploy your applications, choose the
[continuous deployment strategy ](../../ci/introduction/index.md )
that works best for your needs:
| Deployment strategy | Setup | Methodology |
|--|--|--|
| **Continuous deployment to production** | Enables [Auto Deploy ](stages.md#auto-deploy ) with the default branch continuously deployed to production. | Continuous deployment to production.|
2023-03-04 22:38:38 +05:30
| **Continuous deployment to production using timed incremental rollout** | Sets the [`INCREMENTAL_ROLLOUT_MODE` ](cicd_variables.md#timed-incremental-rollout-to-production ) 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` ](cicd_variables.md#deploy-policy-for-staging-and-production-environments ) to `1` and [`INCREMENTAL_ROLLOUT_MODE` ](cicd_variables.md#incremental-rollout-to-production ) to `manual` . | The default branch is continuously deployed to staging and continuously delivered to production. |
2021-10-27 15:23:28 +05:30
You can choose the deployment method when enabling Auto DevOps or later:
2022-10-11 01:57:18 +05:30
1. In GitLab, on the top bar, select **Main menu > Projects** and find your project.
2021-11-11 11:23:49 +05:30
1. On the left sidebar, select **Settings > CI/CD** .
1. Expand **Auto DevOps** .
2021-10-27 15:23:28 +05:30
1. Choose the deployment strategy.
1. Select **Save changes** .
NOTE:
Use the [blue-green deployment ](../../ci/environments/incremental_rollouts.md#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 ](stages.md#auto-review-apps ), [Auto Deploy ](stages.md#auto-deploy ), and
[Auto Monitoring ](stages.md#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` .
2022-10-11 01:57:18 +05:30
- In the instance level: go to **Main menu > Admin > Settings > CI/CD > Continuous Integration and Delivery** and add it there.
2021-10-27 15:23:28 +05:30
The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
as other environment [variables ](../../ci/variables/index.md#cicd-variable-precedence ).
If you don't specify the base domain in your projects and groups, Auto DevOps uses the instance-wide **Auto DevOps domain** .
2022-07-16 23:28:13 +05:30
Auto DevOps requires a wildcard DNS `A` record that matches the base domains. For
2021-10-27 15:23:28 +05:30
a base domain of `example.com` , you'd need a DNS entry like:
```plaintext
*.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](requirements.md)).
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 ](https://nip.io )
which provide automatic wildcard DNS without any configuration. For [nip.io ](https://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.
2020-06-23 00:09:42 +05:30
## Auto DevOps requirements for Kubernetes
To make full use of Auto DevOps with Kubernetes, you need:
- **Kubernetes** (for [Auto Review Apps ](stages.md#auto-review-apps ),
[Auto Deploy ](stages.md#auto-deploy ), and [Auto Monitoring ](stages.md#auto-monitoring ))
To enable deployments, you need:
2021-11-18 22:05:49 +05:30
1. A [Kubernetes 1.12+ cluster ](../../user/infrastructure/clusters/index.md ) for your
project.
2020-06-23 00:09:42 +05:30
For Kubernetes 1.16+ clusters, you must perform additional configuration for
[Auto Deploy for Kubernetes 1.16+ ](stages.md#kubernetes-116 ).
2021-09-04 01:27:46 +05:30
1. 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 ](../../user/project/canary_deployments.md ) require
NGINX Ingress. You can deploy the NGINX Ingress controller to your
Kubernetes cluster either through the GitLab [Cluster management project template ](../../user/clusters/management_project_template.md )
or manually by using the [`ingress-nginx` ](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx )
Helm chart.
2020-06-23 00:09:42 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2021-09-04 01:27:46 +05:30
For metrics to appear when using the [Prometheus cluster integration ](../../user/clusters/integrations.md#prometheus-cluster-integration ), you must [enable Prometheus metrics ](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx#prometheus-metrics ).
When deploying [using custom charts ](customize.md#custom-helm-chart ), you must also
2020-06-23 00:09:42 +05:30
[annotate ](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ )
2021-09-04 01:27:46 +05:30
the Ingress manifest to be scraped by Prometheus using
2020-06-23 00:09:42 +05:30
`prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"` .
2021-09-04 01:27:46 +05:30
NOTE:
If your cluster is installed on bare metal, see
[Auto DevOps Requirements for bare metal ](#auto-devops-requirements-for-bare-metal ).
2020-06-23 00:09:42 +05:30
- **Base domain** (for [Auto Review Apps ](stages.md#auto-review-apps ),
[Auto Deploy ](stages.md#auto-deploy ), and [Auto Monitoring ](stages.md#auto-monitoring ))
2021-10-27 15:23:28 +05:30
You must [specify the Auto DevOps base domain ](#auto-devops-base-domain ),
2021-03-11 19:13:27 +05:30
which all of your Auto DevOps applications use. This domain must be configured
with wildcard DNS.
2020-06-23 00:09:42 +05:30
- **GitLab Runner** (for all stages)
2020-11-24 15:15:51 +05:30
Your runner must be configured to run Docker, usually with either the
2020-06-23 00:09:42 +05:30
[Docker ](https://docs.gitlab.com/runner/executors/docker.html )
or [Kubernetes ](https://docs.gitlab.com/runner/executors/kubernetes.html ) executors, with
[privileged mode enabled ](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode ).
2020-11-24 15:15:51 +05:30
The runners don't need to be installed in the Kubernetes cluster, but the
2020-06-23 00:09:42 +05:30
Kubernetes executor is easy to use and automatically autoscales.
2020-11-24 15:15:51 +05:30
You can configure Docker-based runners to autoscale as well, using
2021-09-30 23:02:18 +05:30
[Docker Machine ](https://docs.gitlab.com/runner/executors/docker_machine.html ).
2020-06-23 00:09:42 +05:30
2021-09-04 01:27:46 +05:30
Runners should be registered as [shared runners ](../../ci/runners/runners_scope.md#shared-runners )
2023-04-23 21:23:45 +05:30
for the entire GitLab instance, or [project runners ](../../ci/runners/runners_scope.md#project-runners )
2021-09-04 01:27:46 +05:30
that are assigned to specific projects.
2020-06-23 00:09:42 +05:30
- **Prometheus** (for [Auto Monitoring ](stages.md#auto-monitoring ))
To enable Auto Monitoring, you need Prometheus installed either inside or
outside your cluster, and configured to scrape your Kubernetes cluster.
2021-09-04 01:27:46 +05:30
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 ](../../user/clusters/integrations.md#prometheus-cluster-integration ).
2020-06-23 00:09:42 +05:30
2021-09-04 01:27:46 +05:30
The [Prometheus integration ](../../user/project/integrations/prometheus.md )
integration must be activated for the project, or activated at the group or instance level.
2023-04-23 21:23:45 +05:30
For more information, see [Project integration management ](../../user/admin_area/settings/project_integration_management.md ).
2020-06-23 00:09:42 +05:30
To get response metrics (in addition to system metrics), you must
[configure Prometheus to monitor NGINX ](../../user/project/integrations/prometheus_library/nginx_ingress.md#configuring-nginx-ingress-monitoring ).
- **cert-manager** (optional, for TLS/HTTPS)
2021-11-18 22:05:49 +05:30
To enable HTTPS endpoints for your application, you can [install cert-manager ](https://cert-manager.io/docs/installation/supported-releases/ ),
2020-06-23 00:09:42 +05:30
a native Kubernetes certificate management controller that helps with issuing
certificates. Installing cert-manager on your cluster issues a
2021-04-29 21:17:54 +05:30
[Let's Encrypt ](https://letsencrypt.org/ ) certificate and ensures the
2021-09-04 01:27:46 +05:30
certificates are valid and up-to-date.
2020-06-23 00:09:42 +05:30
2021-09-04 01:27:46 +05:30
If you don't have Kubernetes or Prometheus configured, then
2020-06-23 00:09:42 +05:30
[Auto Review Apps ](stages.md#auto-review-apps ),
[Auto Deploy ](stages.md#auto-deploy ), and [Auto Monitoring ](stages.md#auto-monitoring )
are skipped.
2021-04-17 20:07:23 +05:30
After all requirements are met, you can [enable Auto DevOps ](index.md#enable-or-disable-auto-devops ).
2020-06-23 00:09:42 +05:30
2021-09-04 01:27:46 +05:30
## Auto DevOps requirements for bare metal
According to the [Kubernetes Ingress-NGINX docs ](https://kubernetes.github.io/ingress-nginx/deploy/baremetal/ ):
> 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 ](https://github.com/metallb/metallb ).
- Through [PorterLB ](https://github.com/kubesphere/porterlb ).
