An upgrade installs the new package over the current version: the configuration in /etc/gitlab/gitlab.rb and the data are kept, and the configuration run and the database migrations start automatically. The version order and the requirement to wait for the background migrations are on the Overview page.
Steps
-
Create a backup as described on the Linux package page and check that fresh copies of the
/etc/gitlab/gitlab-secrets.jsonand/etc/gitlab/gitlab.rbfiles exist:sudo gitlab-backup create -
Install the new package; the configuration run and the migrations start automatically:
# RED OS. sudo rpm -Uvh ./deckhouse-code-<NEW_VERSION>.el8.x86_64.rpm # Ubuntu. sudo apt install -y ./deckhouse-code_<NEW_VERSION>_amd64.deb -
Check the state of the instance and the installed version:
# Every service is in the run state. sudo gitlab-ctl status # The installed version on RED OS. rpm -q deckhouse-code # The installed version on Ubuntu. dpkg -l deckhouse-code # health=200 is expected. curl --cacert /etc/gitlab/ssl/<HOSTNAME>.crt \ --resolve '<HOSTNAME>:443:127.0.0.1' -o /dev/null \ -w "health=%{http_code}\n" https://<HOSTNAME>/-/health
While the migrations run, the instance answers more slowly; on a typical instance the upgrade takes minutes.
Rollback
A rollback is only possible from a backup taken before the upgrade. Install the package version on which the backup was taken and restore the data as described in Restoring. Ask the vendor for the exact downgrade procedure for your configuration.
Moving between the package and the module
Moving an instance from the Linux package to the Deckhouse Kubernetes Platform module and back is described in the Migration section of the module documentation.