Document that local tiller is used for Auto DevOps

Also note that apps will be released into the Kubernetes namespace for
the environment, and that GitLab < 11.4 used a dedicated Tiller
This commit is contained in:
Thong Kuah 2019-04-02 06:16:18 +00:00 committed by Evan Read
parent 264a629958
commit 93dd6ecca9

View file

@ -444,13 +444,6 @@ This is an optional step, since many projects do not have a Kubernetes cluster
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.)
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
in the first place, and thus not realize that it needs to re-apply the old config.
[Review Apps][review-app] are temporary application environments based on the
branch's code so developers, designers, QA, product managers, and other
reviewers can actually see and interact with code changes as part of the review
@ -466,6 +459,24 @@ up in the merge request widget for easy discovery. When the branch or tag is del
for example after the merge request is merged, the Review App will automatically
be deleted.
Review apps are deployed using the
[auto-deploy-app](https://gitlab.com/charts/auto-deploy-app) chart with
Helm. The app will be deployed into the [Kubernetes
namespace](../../user/project/clusters/index.md#deployment-variables)
for the environment.
Since GitLab 11.4, a [local
Tiller](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22036) is
used. Previous versions of GitLab had a Tiller installed in the project
namespace.
CAUTION: **Caution:**
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
in the first place, and thus not realize that it needs to re-apply the old config.
### Auto DAST **[ULTIMATE]**
> Introduced in [GitLab Ultimate][ee] 10.4.
@ -504,13 +515,6 @@ This is an optional step, since many projects do not have a Kubernetes cluster
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.)
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
in the first place, and thus not realize that it needs to re-apply the old config.
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
the Kubernetes cluster, with a namespace based on the project name and unique
@ -523,6 +527,24 @@ enable them.
You can make use of [environment variables](#environment-variables) to automatically
scale your pod replicas.
Apps are deployed using the
[auto-deploy-app](https://gitlab.com/charts/auto-deploy-app) chart with
Helm. The app will be deployed into the [Kubernetes
namespace](../../user/project/clusters/index.md#deployment-variables)
for the environment.
Since GitLab 11.4, a [local
Tiller](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22036) is
used. Previous versions of GitLab had a Tiller installed in the project
namespace.
CAUTION: **Caution:**
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
in the first place, and thus not realize that it needs to re-apply the old config.
> [Introduced][ce-19507] in GitLab 11.0.
For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md#gitlab-deploy-token)