Docs: Lacking documentation on migrating FROM Helm chart TO Omnibus
Problem to solve
We have docs on the process of migrating from Omnibus to Kubernetes, but the inverse is not true. There are certain instances wherein migrating from a Helm installation to Omnibus is desired. The first example I can think of is for administrators who are in the process of migrating to Helm, but need a quick and well-documented path to revert back to Omnibus.
Both GitLab users and GitLab team members benefit from a documented process with examples if necessary. Migrations of any kind are generally daunting to some degree; we could help position GitLab administrators better by giving them a step-by-step workflow for this type of migration
Proposal
The process is fairly straightforward from a high level:
- Create a backup using
backup-utility
- Ensure secrets are backed up as well
- Start a fresh Omnibus installation with the exact same GitLab version
- Ensure a
gitlab-ctl reconfigure
is run successfully at least once on the fresh install - Use
gitlab-backup restore
to restore the tarball - Copy
gitlab.rb
andgitlab-secrets.json
from your backup into/etc/gitlab/
- Alternatively, if you need to, you can pull the secrets out of
secrets.yml
and manually paste them into a freshgitlab-secrets.json
- Run a
gitlab-ctl reconfigure
and then check that your system is in working state again
I think that our docs would benefit the most from explicitly laying out how to take configurations from Helm installs and convert them to their respective Omnibus formats, for example, gitlab.rb
and gitlab-secrets.json
.
Other attention would need to be given to ensuring artifacts/uploads/LFS are converted back to local storage if desired.