diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-06-24 13:31:56 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-06-24 13:31:56 +0300 |
commit | 159f25da0106c574f2c855b44d5ba4e46822d3a3 (patch) | |
tree | 0c0c451079f5a737e3a45461473f45fb5f845921 /doc/topics/autodevops | |
parent | f1926d2aa6447173a06fee5e0a3141bea27a0d8d (diff) |
Add latest changes from gitlab-org/gitlab@14-0-stable-ee
Diffstat (limited to 'doc/topics/autodevops')
-rw-r--r-- | doc/topics/autodevops/upgrading_auto_deploy_dependencies.md | 75 |
1 files changed, 33 insertions, 42 deletions
diff --git a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md index 62dc061aba6..48d37e5125c 100644 --- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md +++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md @@ -77,7 +77,7 @@ The v2 auto-deploy-image drops support for Kubernetes 1.15 and lower. If you nee Kubernetes cluster, follow your cloud provider's instructions. Here's [an example on GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster). -#### Helm 3 +#### Helm v3 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/228609) in GitLab 13.4. @@ -86,47 +86,38 @@ Previously, `auto-deploy-image` used Helm v2, which used Tiller in a cluster. In the v2 `auto-deploy-image`, it uses Helm v3 that doesn't require Tiller anymore. If your Auto DevOps project has an active environment that was deployed with the v1 -`auto-deploy-image`, use the following steps to upgrade to v2, which uses Helm 3: - -1. Modify your `.gitlab-ci.yml` with: - - ```yaml - include: - - template: Auto-DevOps.gitlab-ci.yml - - remote: https://gitlab.com/hfyngvason/ci-templates/-/raw/master/Helm-2to3.gitlab-ci.yml - - variables: - # If this variable is not present, the migration jobs will not show up - MIGRATE_HELM_2TO3: "true" - - .auto-deploy: - # Optional: If you are on GitLab 13.12 or older, pin the auto-deploy-image - # image: registry.gitlab.com/gitlab-org/cluster-integration/auto-deploy-image:v2.6.0 - variables: - AUTO_DEVOPS_FORCE_DEPLOY_V2: 1 - # If you have non-public pipelines, you can back up the entire namespace in a job artifact - # prior to the migration by setting the CI variable BACKUP_NAMESPACE to a non-empty value. - # WARNING: If you have public pipelines, this artifact will be public and can - # expose your secrets. - # BACKUP_HELM2_RELEASES: 1 - ``` - -1. Run the `<environment-name>:helm-2to3:migrate` job. -1. Deploy your environment as usual. This deployment uses Helm 3. -1. If the deployment succeeds, you can safely run `environment:helm-2to3:cleanup`. - This deletes all Helm 2 release data from the namespace. - - If you set `BACKUP_HELM2_RELEASES` to a non-empty value, the `<environment-name>:helm2to3:migrate` - job saves a backup for 1 week in a job artifact called `helm-2-release-backups`. - If you accidentally delete the Helm 2 releases before you are ready, then - this backup is in a Kubernetes manifest file that can be restored using - `kubectl apply -f $backup`. - - **WARNING:** - This artifact can contain secrets and is visible to any - user who can see your job. - -1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable. +`auto-deploy-image`, use the following steps to upgrade to v2, which uses Helm v3: + +1. Include the [Helm 2to3 migration CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Jobs/Helm-2to3.gitlab-ci.yml): + + - If you are on GitLab.com, or GitLab 14.0.1 or later, this template is already included in Auto DevOps. + - On other versions of GitLab, you can modify your `.gitlab-ci.yml` to include the templates: + + ```yaml + include: + - template: Auto-DevOps.gitlab-ci.yml + - remote: https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Jobs/Helm-2to3.gitlab-ci.yml + ``` + +1. Set the following CI/CD variables: + + - `MIGRATE_HELM_2TO3` to `true`. If this variable is not present, migration jobs do not run. + - `AUTO_DEVOPS_FORCE_DEPLOY_V2` to `1`. + - **Optional:** `BACKUP_HELM2_RELEASES` to `1`. If you set this variable, the migration + job saves a backup for 1 week in a job artifact called `helm-2-release-backups`. + If you accidentally delete the Helm v2 releases before you are ready, you can restore + this backup from a Kubernetes manifest file by using `kubectl apply -f $backup`. + + **WARNING:** + *Do not use this if you have public pipelines*. + This artifact can contain secrets and is visible to any + user who can see your job. + +1. Run a pipeline and trigger the `<environment-name>:helm-2to3:migrate` job. +1. Deploy your environment as usual. This deployment uses Helm v3. +1. If the deployment succeeds, you can safely run `<environment-name>:helm-2to3:cleanup`. + This deletes all Helm v2 release data from the namespace. +1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable or set it to `false`. You can do this one environment at a time using [environment scopes](../../ci/environments/index.md#scoping-environments-with-specs). #### In-Cluster PostgreSQL Channel 2 |