Skip to content

G
gitlab-ce
Commit d1657cb9 authored by Dennis Tang's avatar Dennis Tang
Browse files
Options

revert changes to autodevops/index.md

parent 2c6fc4c6
Show whitespace changes
Inline Side-by-side
Showing with 166 additions and 166 deletions
doc/topics/autodevops/index.md
View file @ d1657cb9
......@@ -52,11 +52,11 @@ project in an easy and automatic way:
As Auto DevOps relies on many different components, it's good to have a basic
knowledge of the following:
* [Kubernetes](https://kubernetes.io/docs/home/)
* [Helm](https://docs.helm.sh/)
* [Docker](https://docs.docker.com)
* [GitLab Runner](https://docs.gitlab.com/runner/)
* [Prometheus](https://prometheus.io/docs/introduction/overview/)
- [Kubernetes](https://kubernetes.io/docs/home/)
- [Helm](https://docs.helm.sh/)
- [Docker](https://docs.docker.com)
- [GitLab Runner](https://docs.gitlab.com/runner/)
- [Prometheus](https://prometheus.io/docs/introduction/overview/)
Auto DevOps provides great defaults for all the stages; you can, however,
[customize](#customizing) almost everything to your needs.
......@@ -119,9 +119,9 @@ The Auto DevOps base domain is required if you want to make use of [Auto
Review Apps](#auto-review-apps) and [Auto Deploy](#auto-deploy). It can be defined
in three places:
* either under the project's CI/CD settings while [enabling Auto DevOps](#enabling-auto-devops)
* or in instance-wide settings in the **admin area > Settings** under the "Continuous Integration and Delivery" section
* or at the project or group level as a variable: `AUTO_DEVOPS_DOMAIN` (required if you want to use [multiple clusters](#using-multiple-kubernetes-clusters-premium))
- either under the project's CI/CD settings while [enabling Auto DevOps](#enabling-auto-devops)
- or in instance-wide settings in the **admin area > Settings** under the "Continuous Integration and Delivery" section
- or at the project or group level as a variable: `AUTO_DEVOPS_DOMAIN` (required if you want to use [multiple clusters](#using-multiple-kubernetes-clusters))
A wildcard DNS A record matching the base domain(s) is required, for example,
given a base domain of `example.com`, you'd need a DNS entry like:
......@@ -157,9 +157,9 @@ different Kubernetes clusters. This is possible due to the 1:1 connection that
In the [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml)
(used behind the scenes by Auto DevOps), there are currently 3 defined environment names that you need to know:
* `review/` (every environment starting with `review/`)
* `staging`
* `production`
- `review/` (every environment starting with `review/`)
- `staging`
- `production`
Those environments are tied to jobs that use [Auto Deploy](#auto-deploy), so
except for the environment scope, they would also need to have a different
......@@ -171,7 +171,7 @@ The following table is an example of how the three different clusters would
be configured.
| Cluster name | Cluster environment scope | `AUTO_DEVOPS_DOMAIN` variable value | Variable environment scope | Notes |
| ------------ | ------------------------- | ----------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ------------ | -------------- | ----------------------------- | ------------- | ------ |
| review | `review/*` | `review.example.com` | `review/*` | The review cluster which will run all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, which means it will be used by every environment name starting with `review/`. |
| staging | `staging` | `staging.example.com` | `staging` | (Optional) The staging cluster which will run the deployments of the staging environments. You need to [enable it first](#deploy-policy-for-staging-and-production-environments). |
| production | `production` | `example.com` | `production` | The production cluster which will run the deployments of the production environment. You can use [incremental rollouts](#incremental-rollout-to-production). |
......@@ -243,11 +243,11 @@ project's **Settings > CI/CD > Auto DevOps**.
The available options are:
* **Continuous deployment to production** - enables [Auto Deploy](#auto-deploy)
- **Continuous deployment to production** - enables [Auto Deploy](#auto-deploy)
by setting the [`STAGING_ENABLED`](#deploy-policy-for-staging-and-production-environments) and
[`INCREMENTAL_ROLLOUT_ENABLED`](#incremental-rollout-to-production) variables
to false.
* **Automatic deployment to staging, manual deployment to production** - sets the
- **Automatic deployment to staging, manual deployment to production** - sets the
[`STAGING_ENABLED`](#deploy-policy-for-staging-and-production-environments) and
[`INCREMENTAL_ROLLOUT_ENABLED`](#incremental-rollout-to-production) variables
to true, and the user is responsible for manually deploying to staging and production.
......@@ -261,8 +261,8 @@ to understand how each one works.
Auto Build creates a build of the application in one of two ways:
* If there is a `Dockerfile`, it will use `docker build` to create a Docker image.
* Otherwise, it will use [Herokuish](https://github.com/gliderlabs/herokuish)
- If there is a `Dockerfile`, it will use `docker build` to create a Docker image.
- Otherwise, it will use [Herokuish](https://github.com/gliderlabs/herokuish)
and [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks)
to automatically detect and build the application into a Docker image.
......@@ -360,7 +360,7 @@ available. If the [requirements](#requirements) are not met, the job will
silently be skipped.
CAUTION: **Caution:**
Your apps should _not_ be manipulated outside of Helm (using Kubernetes directly.)
Your apps should *not* be manipulated outside of Helm (using Kubernetes directly.)
This can cause confusion with Helm not detecting the change, and subsequent
deploys with Auto DevOps can undo your changes. Also, if you change something
and want to undo it by deploying again, Helm may not detect that anything changed
......@@ -414,7 +414,7 @@ available. If the [requirements](#requirements) are not met, the job will
silently be skipped.
CAUTION: **Caution:**
Your apps should _not_ be manipulated outside of Helm (using Kubernetes directly.)
Your apps should *not* be manipulated outside of Helm (using Kubernetes directly.)
This can cause confusion with Helm not detecting the change, and subsequent
deploys with Auto DevOps can undo your changes. Also, if you change something
and want to undo it by deploying again, Helm may not detect that anything changed
......@@ -469,8 +469,8 @@ and response metrics such as HTTP error rates, latency, and throughput from the
The metrics include:
* **Response Metrics:** latency, throughput, error rate
* **System Metrics:** CPU utilization, memory utilization
- **Response Metrics:** latency, throughput, error rate
- **System Metrics:** CPU utilization, memory utilization
If GitLab has been deployed using the [GitLab Omnibus Helm Chart], no
configuration is required.
......@@ -504,9 +504,9 @@ If the automatic buildpack detection fails for your project, or if you want to
use a custom buildpack, you can override the buildpack(s) using a project variable
or a `.buildpacks` file in your project:
* **Project variable** - Create a project variable `BUILDPACK_URL` with the URL
- **Project variable** - Create a project variable `BUILDPACK_URL` with the URL
of the buildpack to use.
* **`.buildpacks` file** - Add a file in your project's repo called `.buildpacks`
- **`.buildpacks` file** - Add a file in your project's repo called `.buildpacks`
and add the URL of the buildpack to use on a line in the file. If you want to
use multiple buildpacks, you can enter them in, one on each line.
......@@ -526,11 +526,11 @@ Auto DevOps uses [Helm](https://helm.sh/) to deploy your application to Kubernet
You can override the Helm chart used by bundling up a chart into your project
repo or by specifying a project variable:
* **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
- **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
file in it, Auto DevOps will detect the chart and use it instead of the [default
one](https://gitlab.com/charts/charts.gitlab.io/tree/master/charts/auto-deploy-app).
This can be a great way to control exactly how your application is deployed.
* **Project variable** - Create a [project variable](../../ci/variables/README.md#secret-variables)
- **Project variable** - Create a [project variable](../../ci/variables/README.md#secret-variables)
`AUTO_DEVOPS_CHART` with the URL of a custom chart to use.
### Customizing `.gitlab-ci.yml`
......@@ -574,7 +574,7 @@ providing a custom Helm chart, or scaling your application. PostgreSQL can be
also be customized, and you can easily use a [custom buildpack](#custom-buildpacks).
| **Variable** | **Description** |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| ------------ | --------------- |
| `AUTO_DEVOPS_DOMAIN` | The [Auto DevOps domain](#auto-devops-domain); by default set automatically by the [Auto DevOps setting](#enabling-auto-devops). |
| `AUTO_DEVOPS_CHART` | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/charts.gitlab.io/tree/master/charts/auto-deploy-app). |
| `REPLICAS` | The number of replicas to deploy; defaults to 1. |
......@@ -586,11 +586,11 @@ also be customized, and you can easily use a [custom buildpack](#custom-buildpac
| `POSTGRES_PASSWORD` | The PostgreSQL password; defaults to `testing-password`. Set it to use a custom password. |
| `POSTGRES_DB` | The PostgreSQL database name; defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-variables-environment-variables). Set it to use a custom database name. |
| `BUILDPACK_URL` | The buildpack's full URL. It can point to either Git repositories or a tarball URL. For Git repositories, it is possible to point to a specific `ref`, for example `https://github.com/heroku/heroku-buildpack-ruby.git#v142` |
| `SAST_CONFIDENCE_LEVEL` | The minimum confidence level of security issues you want to be reported; `1` for Low, `2` for Medium, `3` for High; defaults to `3`. |
| `DEP_SCAN_DISABLE_REMOTE_CHECKS` | Whether remote Dependency Scanning checks are disabled; defaults to `"false"`. Set to `"true"` to disable checks that send data to GitLab central servers. [Read more about remote checks](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks). |
| `SAST_CONFIDENCE_LEVEL` | The minimum confidence level of security issues you want to be reported; `1` for Low, `2` for Medium, `3` for High; defaults to `3`.|
| `DEP_SCAN_DISABLE_REMOTE_CHECKS` | Whether remote Dependency Scanning checks are disabled; defaults to `"false"`. Set to `"true"` to disable checks that send data to GitLab central servers. [Read more about remote checks](https://gitlab.com/gitlab-org/security-products/dependency-scanning#remote-checks).|
| `STAGING_ENABLED` | From GitLab 10.8, this variable can be used to define a [deploy policy for staging and production environments](#deploy-policy-for-staging-and-production-environments). |
| `CANARY_ENABLED` | From GitLab 11.0, this variable can be used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). |
| `INCREMENTAL_ROLLOUT_ENABLED` | From GitLab 10.8, this variable can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. |
| `INCREMENTAL_ROLLOUT_ENABLED`| From GitLab 10.8, this variable can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. |
| `TEST_DISABLED` | From GitLab 11.0, this variable can be used to disable the `test` job. If the variable is present, the job will not be created. |
| `CODEQUALITY_DISABLED` | From GitLab 11.0, this variable can be used to disable the `codequality` job. If the variable is present, the job will not be created. |
| `SAST_DISABLED` | From GitLab 11.0, this variable can be used to disable the `sast` job. If the variable is present, the job will not be created. |
......@@ -606,7 +606,7 @@ Set up the replica variables using a
and scale your application by just redeploying it!
CAUTION: **Caution:**
You should _not_ scale your application using Kubernetes directly. This can
You should *not* scale your application using Kubernetes directly. This can
cause confusion with Helm not detecting the change, and subsequent deploys with
Auto DevOps can undo your changes.
......@@ -619,11 +619,11 @@ There's a very specific mapping between Kubernetes' label named `track`,
GitLab CI/CD environment names, and the replicas environment variable.
The general rule is: `TRACK_ENV_REPLICAS`. Where:
* `TRACK`: The capitalized value of the `track`
- `TRACK`: The capitalized value of the `track`
[Kubernetes label](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)
in the Helm Chart app definition. If not set, it will not be taken into account
to the variable name.
* `ENV`: The capitalized environment name of the deploy job that is set in
- `ENV`: The capitalized environment name of the deploy job that is set in
`.gitlab-ci.yml`.
That way, you can define your own `TRACK_ENV_REPLICAS` variables with which
......@@ -668,7 +668,7 @@ service:
#### Deploy policy for staging and production environments
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/160)
> in GitLab 10.8.
in GitLab 10.8.
TIP: **Tip:**
You can also set this inside your [project's settings](#deployment-strategy).
......@@ -687,7 +687,7 @@ you when you're ready to manually deploy to production.
#### Deploy policy for canary environments **[PREMIUM]**
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/171)
> in GitLab 11.0.
in GitLab 11.0.
A [canary environment](https://docs.gitlab.com/ee/user/project/canary_deployments.html) can be used
before any changes are deployed to production.
......@@ -695,8 +695,8 @@ before any changes are deployed to production.
If `CANARY_ENABLED` is defined in your project (e.g., set `CANARY_ENABLED` to
`1` as a secret variable) then two manual jobs will be created:
* `canary` which will deploy the application to the canary environment
* `production_manual` which is to be used by you when you're ready to manually
- `canary` which will deploy the application to the canary environment
- `production_manual` which is to be used by you when you're ready to manually
deploy to production.
#### Incremental rollout to production **[PREMIUM]**
......@@ -737,19 +737,19 @@ environment page.
Below, you can see how the pipeline will look if the rollout or staging
variables are defined.
* **Without `INCREMENTAL_ROLLOUT_ENABLED` and without `STAGING_ENABLED`**
- **Without `INCREMENTAL_ROLLOUT_ENABLED` and without `STAGING_ENABLED`**
![Staging and rollout disabled](img/rollout_staging_disabled.png)
* **Without `INCREMENTAL_ROLLOUT_ENABLED` and with `STAGING_ENABLED`**
- **Without `INCREMENTAL_ROLLOUT_ENABLED` and with `STAGING_ENABLED`**
![Staging enabled](img/staging_enabled.png)
* **With `INCREMENTAL_ROLLOUT_ENABLED` and without `STAGING_ENABLED`**
- **With `INCREMENTAL_ROLLOUT_ENABLED` and without `STAGING_ENABLED`**
![Rollout enabled](img/rollout_enabled.png)
* **With `INCREMENTAL_ROLLOUT_ENABLED` and with `STAGING_ENABLED`**
- **With `INCREMENTAL_ROLLOUT_ENABLED` and with `STAGING_ENABLED`**
![Rollout and staging enabled](img/rollout_staging_enabled.png)
......@@ -803,13 +803,13 @@ planned for a subsequent release.
## Troubleshooting
* Auto Build and Auto Test may fail in detecting your language/framework. There
- Auto Build and Auto Test may fail in detecting your language/framework. There
may be no buildpack for your application, or your application may be missing the
key files the buildpack is looking for. For example, for ruby apps, you must
have a `Gemfile` to be properly detected, even though it is possible to write a
Ruby app without a `Gemfile`. Try specifying a [custom
buildpack](#custom-buildpacks).
* Auto Test may fail because of a mismatch between testing frameworks. In this
- Auto Test may fail because of a mismatch between testing frameworks. In this
case, you may need to customize your `.gitlab-ci.yml` with your test commands.
### Disable the banner instance wide
......@@ -839,7 +839,7 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/
[review-app]: ../../ci/review_apps/index.md
[container-registry]: ../../user/project/container_registry.md
[postgresql]: https://www.postgresql.org/
[auto devops template]: https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml
[gitlab omnibus helm chart]: ../../install/kubernetes/gitlab_omnibus.md
[Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml
[GitLab Omnibus Helm Chart]: ../../install/kubernetes/gitlab_omnibus.md
[ee]: https://about.gitlab.com/products/
[ce-19507]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/19507
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