135 lines
7.2 KiB
Markdown
135 lines
7.2 KiB
Markdown
|
# Requirements for Auto DevOps
|
|||
|
|
|||
|
You can set up Auto DevOps for [Kubernetes](#auto-devops-requirements-for-kubernetes)
|
|||
|
or [Amazon Elastic Container Service (ECS)](#auto-devops-requirements-for-amazon-ecs).
|
|||
|
For more information about Auto DevOps, see [the main Auto DevOps page](index.md)
|
|||
|
or the [quick start guide](quick_start_guide.md).
|
|||
|
|
|||
|
## 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:
|
|||
|
|
|||
|
1. A [Kubernetes 1.12+ cluster](../../user/project/clusters/index.md) for your
|
|||
|
project. The easiest way is to create a
|
|||
|
[new cluster using the GitLab UI](../../user/project/clusters/add_remove_clusters.md#create-new-cluster).
|
|||
|
For Kubernetes 1.16+ clusters, you must perform additional configuration for
|
|||
|
[Auto Deploy for Kubernetes 1.16+](stages.md#kubernetes-116).
|
|||
|
1. NGINX Ingress. You can deploy it to your Kubernetes cluster by installing
|
|||
|
the [GitLab-managed app for Ingress](../../user/clusters/applications.md#ingress),
|
|||
|
after configuring GitLab's Kubernetes integration in the previous step.
|
|||
|
|
|||
|
Alternatively, you can use the
|
|||
|
[`nginx-ingress`](https://github.com/helm/charts/tree/master/stable/nginx-ingress)
|
|||
|
Helm chart to install Ingress manually.
|
|||
|
|
|||
|
NOTE: **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](https://github.com/helm/charts/tree/master/stable/nginx-ingress#prometheus-metrics)
|
|||
|
for the response metrics to appear. You must also
|
|||
|
[annotate](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/)
|
|||
|
the NGINX Ingress deployment to be scraped by Prometheus using
|
|||
|
`prometheus.io/scrape: "true"` and `prometheus.io/port: "10254"`.
|
|||
|
|
|||
|
- **Base domain** (for [Auto Review Apps](stages.md#auto-review-apps),
|
|||
|
[Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring))
|
|||
|
|
|||
|
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](../../user/clusters/applications.md#ingress),
|
|||
|
the URL endpoint is automatically configured for you.
|
|||
|
|
|||
|
You must also [specify the Auto DevOps base domain](index.md#auto-devops-base-domain).
|
|||
|
|
|||
|
- **GitLab Runner** (for all stages)
|
|||
|
|
|||
|
Your Runner must be configured to run Docker, usually with either the
|
|||
|
[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).
|
|||
|
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](https://docs.gitlab.com/runner/install/autoscaling.html).
|
|||
|
|
|||
|
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](../../user/clusters/applications.md#gitlab-runner).
|
|||
|
|
|||
|
Runners should be registered as [shared Runners](../../ci/runners/README.md#shared-runners)
|
|||
|
for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#specific-runners)
|
|||
|
that are assigned to specific projects (the default if you've installed the
|
|||
|
GitLab Runner managed application).
|
|||
|
|
|||
|
- **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.
|
|||
|
If you've configured GitLab's Kubernetes integration, you can deploy it to
|
|||
|
your cluster by installing the
|
|||
|
[GitLab-managed app for Prometheus](../../user/clusters/applications.md#prometheus).
|
|||
|
|
|||
|
The [Prometheus service](../../user/project/integrations/prometheus.md)
|
|||
|
integration must be enabled for the project, or enabled as a
|
|||
|
[default service template](../../user/project/integrations/services_templates.md)
|
|||
|
for the entire GitLab installation.
|
|||
|
|
|||
|
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)
|
|||
|
|
|||
|
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](https://letsencrypt.org/) 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](../../user/clusters/applications.md#cert-manager).
|
|||
|
|
|||
|
If you don't have Kubernetes or Prometheus installed, then
|
|||
|
[Auto Review Apps](stages.md#auto-review-apps),
|
|||
|
[Auto Deploy](stages.md#auto-deploy), and [Auto Monitoring](stages.md#auto-monitoring)
|
|||
|
are skipped.
|
|||
|
|
|||
|
After all requirements are met, you can [enable Auto DevOps](index.md#enablingdisabling-auto-devops).
|
|||
|
|
|||
|
## Auto DevOps requirements for Amazon ECS
|
|||
|
|
|||
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0.
|
|||
|
|
|||
|
You can choose to target [Amazon Elastic Container Service (ECS)](../../ci/cloud_deployment/index.md) 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:
|
|||
|
|
|||
|
1. In your project, go to **Settings > CI / CD** and expand the **Variables**
|
|||
|
section.
|
|||
|
|
|||
|
1. Specify which AWS platform to target during the Auto DevOps deployment
|
|||
|
by adding the `AUTO_DEVOPS_PLATFORM_TARGET` variable.
|
|||
|
|
|||
|
1. Give this variable the value `ECS` before saving it.
|
|||
|
|
|||
|
When you trigger a pipeline, if Auto DevOps is enabled and if you've correctly
|
|||
|
[entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
|
|||
|
your application will be deployed to Amazon ECS.
|
|||
|
|
|||
|
NOTE: **Note:**
|
|||
|
If you have both a valid `AUTO_DEVOPS_PLATFORM_TARGET` variable and a Kubernetes cluster tied to your project,
|
|||
|
only the deployment to Kubernetes will run.
|
|||
|
|
|||
|
CAUTION: **Warning:**
|
|||
|
Setting the `AUTO_DEVOPS_PLATFORM_TARGET` variable to `ECS` will trigger jobs
|
|||
|
defined in the [`Jobs/Deploy/ECS.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Deploy/ECS.gitlab-ci.yml).
|
|||
|
However, it's not recommended to [include](../../ci/yaml/README.md#includetemplate)
|
|||
|
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.
|