@@ -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:
`auto-deploy-image`, use the following steps to upgrade to v2, which uses Helm v3:
1. Modify your `.gitlab-ci.yml` with:
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:
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.
1. Set the following CI/CD variables:
If you set `BACKUP_HELM2_RELEASES` to a non-empty value, the `<environment-name>:helm2to3:migrate`
-`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 2 releases before you are ready, then
this backup is in a Kubernetes manifest file that can be restored using
`kubectl apply -f $backup`.
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. Remove the `MIGRATE_HELM_2TO3` CI/CD variable.
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).