Skip to content

G
gitlab-ce
Commit ff2b7cf4 authored by Amy Qualls's avatar Amy Qualls
Browse files
Options

Merge branch '220100-docs-aqualls-autodevops-split' into 'master' 

Docs: Split off Auto DevOps requirements

Closes #220100

See merge request gitlab-org/gitlab!33988
parents 3b4e82b0 aa8b2415
Show whitespace changes
Inline Side-by-side
Showing with 140 additions and 134 deletions
doc/topics/autodevops/index.md
View file @ ff2b7cf4
......@@ -25,6 +25,8 @@ and GitLab does the rest, improving your productivity and efficiency.
For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
For requirements, see [Requirements for Auto DevOps](requirements.md) for more information.
## Enabled by default
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3.
......@@ -54,7 +56,7 @@ configuring a cluster on GKE. After configuring the provider, you can follow
the steps in the [quick start guide](quick_start_guide.md) to get started.
In [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) and later, it is
possible to leverage Auto DevOps to deploy to [AWS ECS](#aws-ecs).
possible to leverage Auto DevOps to deploy to [AWS ECS](requirements.md#auto-devops-requirements-for-amazon-ecs).
## Comparison to application platforms and PaaS
......@@ -111,136 +113,6 @@ NOTE: **Note**
Kubernetes clusters can [be used without](../../user/project/clusters/index.md)
Auto DevOps.
## Requirements
### 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](#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#registering-a-shared-runner)
for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#registering-a-specific-runner)
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](#enablingdisabling-auto-devops).
### AWS ECS
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208132) in GitLab 13.0.
You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.
To get started on Auto DevOps to 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 you have AutoDev Ops enabled and if you have 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 AWS 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 is 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. Do not override these jobs names in your
own pipeline, as the override will stop working when the name changes.
## Auto DevOps base domain
The Auto DevOps base domain is required to use
......
doc/topics/autodevops/requirements.md 0 → 100644
View file @ ff2b7cf4
# 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#registering-a-shared-runner)
for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#registering-a-specific-runner)
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.
doc/topics/autodevops/stages.md
View file @ ff2b7cf4
......@@ -196,7 +196,7 @@ see the documentation.
## Auto Review Apps
This is an optional step, since many projects don't have a Kubernetes cluster
available. If the [requirements](index.md#requirements) are not met, the job is
available. If the [requirements](requirements.md) are not met, the job is
silently skipped.
[Review Apps](../../ci/review_apps/index.md) are temporary application environments based on the
......@@ -297,7 +297,7 @@ Any performance differences between the source and target branches are also
## Auto Deploy
This is an optional step, since many projects don't have a Kubernetes cluster
available. If the [requirements](index.md#requirements) are not met, the job is skipped.
available. If the [requirements](requirements.md) are not met, the job is skipped.
After a branch or merge request is merged into the project's default branch (usually
`master`), Auto Deploy deploys the application to a `production` environment in
......@@ -598,7 +598,7 @@ GitLab provides some initial alerts for you after you install Prometheus:
To use Auto Monitoring:
1. [Install and configure the requirements](index.md#requirements).
1. [Install and configure the Auto DevOps requirements](requirements.md).
1. [Enable Auto DevOps](index.md#enablingdisabling-auto-devops), if you haven't done already.
1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** and click **Run Pipeline**.
1. After the pipeline finishes successfully, open the
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7