Deckhouse Code работает на GitLab и принимает данные инстанса GitLab Community Edition (CE) той же версии GitLab: репозитории, пользователей, группы, задачи, запросы на слияние, настройки и историю CI/CD. Инстанс переносится целиком. Отдельные проекты между инстансами переносятся по инструкции «Импорт проекта».

Порядок миграции зависит от того, где работает Deckhouse Code:

  • на том же сервере или с теми же томами Docker, что и GitLab CE: пакет или образ Deckhouse Code заменяет GitLab CE, данные остаются на месте, как описано в разделе «Миграция на месте»;
  • на другом сервере, в установке из Helm-чарта или в модуле Deckhouse Kubernetes Platform: данные переносятся в архиве резервной копии, как описано в разделе «Миграция через архив резервной копии».

Перед началом

Проверьте условия на инстансе GitLab CE:

  • Версия GitLab на инстансе совпадает с версией GitLab устанавливаемого выпуска Deckhouse Code. Архив резервной копии восстанавливается только в ту версию, в которой он создан. Если на инстансе более старая версия, сначала обновите его по пути обновления GitLab.
  • Все фоновые миграции завершены: откройте «Admin» → «Мониторинг» → «Фоновые миграции» и проверьте, что вкладки «В очереди», «Завершаются» и «Неудачные» пусты.
  • На диске достаточно свободного места для архива резервной копии.

Проверьте версию GitLab на инстансе:

  • Пакет для ОС Linux
  • Omnibus Docker
sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

В командах на этой странице контейнер GitLab CE называется gitlab; замените имя на своё.

docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Миграция на месте

Пакет Deckhouse Code заменяет пакет gitlab-ce, а образ Deckhouse Code запускается на томах контейнера GitLab CE. Конфигурация в /etc/gitlab/gitlab.rb, секреты в /etc/gitlab/gitlab-secrets.json и данные в /var/opt/gitlab сохраняются. Запуск настройки применяет миграции базы данных, которые создают таблицы Deckhouse Code.

Во время установки сервисы перезапускаются, и инстанс недоступен до окончания настройки и миграций.

  • Пакет для ОС Linux
  • Omnibus Docker

  1. Создайте резервную копию и скопируйте её за пределы сервера вместе с файлами /etc/gitlab/gitlab.rb, /etc/gitlab/gitlab-secrets.json и директорией /etc/gitlab/ssl/:

    sudo gitlab-backup create

  2. Установите пакет Deckhouse Code. Менеджер пакетов удалит пакет gitlab-ce:

    # РЕД ОС.
sudo dnf install -y ./deckhouse-code-<VERSION>.el8.x86_64.rpm
# AlmaLinux.
sudo dnf install -y ./deckhouse-code-<VERSION>.el9.x86_64.rpm
# Ubuntu.
sudo apt install -y ./deckhouse-code_<VERSION>_amd64.deb

  3. Запустите настройку:

    sudo gitlab-ctl reconfigure

  4. Проверьте, что не осталось неприменённых миграций, что зашифрованные данные в базе читаются секретами инстанса и что инстанс проходит самопроверку:

    sudo gitlab-rake db:migrate:status | grep -w down
sudo gitlab-rake gitlab:fe:secret:verify
sudo gitlab-rake gitlab:check SANITIZE=true

    Первая команда ничего не выводит, когда все миграции применены. Если она выводит миграции, примените их и повторите проверки:

    sudo gitlab-rake db:migrate

В командах ниже <GITLAB_HOME> — директория на хосте с томами config, logs и data контейнера GitLab CE.

  1. Создайте резервную копию и скопируйте её за пределы хоста вместе с директорией <GITLAB_HOME>/config:

    docker exec -t gitlab gitlab-backup create

  2. Остановите и удалите контейнер GitLab CE. Тома — это директории на хосте, они остаются на месте:

    docker stop gitlab
docker rm gitlab

  3. Создайте контейнер Deckhouse Code на тех же томах, с портами и переменными окружения контейнера GitLab CE:

    docker run -d --name code \
  --shm-size 256m \
  -p 80:80 -p 443:443 -p 22:22 \
  -e GITLAB_OMNIBUS_CONFIG="external_url 'https://<HOSTNAME>'" \
  -v <GITLAB_HOME>/config:/etc/gitlab \
  -v <GITLAB_HOME>/logs:/var/log/gitlab \
  -v <GITLAB_HOME>/data:/var/opt/gitlab \
  <REGISTRY>/<FLAVOR>:<VERSION>

  4. Следите за запуском. Миграции базы данных выполняются во время настройки, и до её окончания инстанс отвечает кодом 502:

    docker logs -f code

  5. Проверьте, что не осталось неприменённых миграций, что зашифрованные данные в базе читаются секретами инстанса и что инстанс проходит самопроверку:

    docker exec code gitlab-rake db:migrate:status | grep -w down
docker exec code gitlab-rake gitlab:fe:secret:verify
docker exec code gitlab-rake gitlab:check SANITIZE=true

    Первая команда ничего не выводит, когда все миграции применены. Если она выводит миграции, примените их и повторите проверки:

    docker exec code gitlab-rake db:migrate

Миграция через архив резервной копии

Данные переносятся в архиве резервной копии, а файлы, которых нет в архиве, копируются отдельно. Deckhouse Code устанавливается заранее, с версией GitLab исходного инстанса и тем же внешним адресом.

Сбор данных GitLab CE

Соберите файлы с инстанса GitLab CE и храните их с той же степенью защиты, что и пароли:

  • архив резервной копии;
  • gitlab-secrets.json — ключи шифрования базы данных; без них теряются настройки двухфакторной аутентификации, токены и зашифрованные переменные CI/CD;
  • gitlab.rb — конфигурация инстанса;
  • сертификаты и ключи из директории /etc/gitlab/ssl/;
  • SSH-ключи хоста: с ними Git-клиенты подключаются к Deckhouse Code по SSH без предупреждения о смене ключа хоста.
  • Пакет для ОС Linux
  • Omnibus Docker

  1. Создайте резервную копию:

    sudo gitlab-backup create

    Архив <BACKUP_NAME>_gitlab_backup.tar записывается в /var/opt/gitlab/backups/.

  2. Скопируйте за пределы сервера архив, файлы /etc/gitlab/gitlab.rb и /etc/gitlab/gitlab-secrets.json, директорию /etc/gitlab/ssl/ и файлы /etc/ssh/ssh_host_*.

  1. Создайте резервную копию:

    docker exec -t gitlab gitlab-backup create

    Архив <BACKUP_NAME>_gitlab_backup.tar записывается в <GITLAB_HOME>/data/backups/ на хосте.

  2. Скопируйте за пределы хоста архив, файлы gitlab.rb и gitlab-secrets.json, директорию ssl/ и файлы ssh_host_* из <GITLAB_HOME>/config.

Если GitLab CE хранит загруженные файлы, артефакты CI/CD, объекты LFS или пакеты в объектном хранилище, архив их не содержит. Подключите Deckhouse Code к тем же бакетам или скопируйте бакеты в хранилище Deckhouse Code, например командой rclone sync.

<BACKUP_NAME> — имя файла архива без суффикса _gitlab_backup.tar: для архива 1784800000_2026_07_23_19.4.1_gitlab_backup.tar это 1784800000_2026_07_23_19.4.1.

Восстановление в Deckhouse Code

После восстановления в базе данных схема GitLab CE. Команда gitlab-rake db:migrate добавляет в неё таблицы Deckhouse Code.

  • Пакет для ОС Linux
  • Omnibus Docker
  • Helm-чарт
  • Модуль Deckhouse Kubernetes Platform

Установите Deckhouse Code, как описано в разделе «Быстрый старт».

  1. Замените /etc/gitlab/gitlab.rb и /etc/gitlab/gitlab-secrets.json файлами GitLab CE, скопируйте сертификаты и ключи в /etc/gitlab/ssl/ и запустите настройку:

    sudo gitlab-ctl reconfigure

  2. Скопируйте SSH-ключи хоста в /etc/ssh/ и перезапустите SSH-сервер:

    sudo cp ssh_host_* /etc/ssh/
# РЕД ОС, AlmaLinux.
sudo systemctl restart sshd
# Ubuntu.
sudo systemctl restart ssh

  3. Скопируйте архив в директорию резервных копий и передайте файл пользователю git:

    sudo cp <BACKUP_NAME>_gitlab_backup.tar /var/opt/gitlab/backups/
sudo chown git:git /var/opt/gitlab/backups/<BACKUP_NAME>_gitlab_backup.tar

  4. Остановите сервисы, которые пишут в базу данных:

    sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq

  5. Восстановите данные. Команда дважды запрашивает подтверждение: перед пересозданием файла authorized_keys и перед удалением текущих таблиц базы данных; оба раза ответьте yes:

    sudo gitlab-backup restore BACKUP=<BACKUP_NAME>

  6. Примените миграции базы данных Deckhouse Code:

    sudo gitlab-rake db:migrate

  7. Перезапустите инстанс и проверьте его:

    sudo gitlab-ctl restart
sudo gitlab-rake gitlab:fe:secret:verify
sudo gitlab-rake gitlab:check SANITIZE=true

Контейнер читает конфигурацию, секреты и SSH-ключи хоста с тома конфигурации и создаёт ключи хоста, только когда их на томе нет, поэтому файлы помещаются на том до первого запуска.

  1. Поместите файлы GitLab CE в директорию конфигурации на хосте: gitlab.rb, gitlab-secrets.json и файлы ssh_host_* — в /srv/code/config/, сертификаты и ключи — в /srv/code/config/ssl/.

  2. Создайте контейнер, как описано в разделе «Быстрый старт», и дождитесь окончания первого запуска:

    docker logs -f code

  3. Скопируйте архив в директорию резервных копий на томе данных и назначьте ему владельца, от имени которого работает инстанс:

    sudo cp <BACKUP_NAME>_gitlab_backup.tar /srv/code/data/backups/
docker exec code chown git:git /var/opt/gitlab/backups/<BACKUP_NAME>_gitlab_backup.tar

  4. Остановите сервисы, которые пишут в базу данных:

    docker exec code gitlab-ctl stop puma
docker exec code gitlab-ctl stop sidekiq

  5. Восстановите данные. Команда дважды запрашивает подтверждение: перед пересозданием файла authorized_keys и перед удалением текущих таблиц базы данных; оба раза ответьте yes:

    docker exec -it code gitlab-backup restore BACKUP=<BACKUP_NAME>

  6. Примените миграции базы данных Deckhouse Code:

    docker exec code gitlab-rake db:migrate

  7. Перезапустите контейнер и проверьте инстанс:

    docker restart code
docker exec code gitlab-rake gitlab:fe:secret:verify
docker exec code gitlab-rake gitlab:check SANITIZE=true

Установите Deckhouse Code, как описано в разделе «Быстрый старт»: релиз code в неймспейсе code с настроенным объектным хранилищем для резервных копий.

  1. Преобразуйте раздел gitlab_rails файла gitlab-secrets.json в файл секретов Rails и замените им объект Secret релиза:

    yq -p json -o yaml '{"production": .gitlab_rails}' gitlab-secrets.json > secrets.yml
d8 k -n code create secret generic code-rails-secret --from-file=secrets.yml \
  --dry-run=client -o yaml | d8 k apply -f -

  2. Замените объект Secret с SSH-ключами хоста:

    d8 k -n code create secret generic code-gitlab-shell-host-keys --from-file=. \
  --dry-run=client -o yaml | d8 k apply -f -

    Выполните команду в директории, где лежат только файлы ssh_host_*.

  3. Перезапустите поды, чтобы они прочитали новые объекты Secret:

    d8 k -n code delete pods -l app=webservice
d8 k -n code delete pods -l app=sidekiq
d8 k -n code delete pods -l app=gitlab-shell

  4. Загрузите архив в бакет резервных копий — значение global.appConfig.backups.bucket.

  5. Восстановите данные в поде toolbox:

    d8 k -n code exec -it deploy/code-toolbox -- backup-utility --restore -t <BACKUP_NAME>

  6. Примените миграции базы данных Deckhouse Code:

    d8 k -n code exec -it deploy/code-toolbox -- gitlab-rake db:migrate

  7. Перезапустите поды и проверьте инстанс:

    d8 k -n code delete pods -l app=webservice
d8 k -n code delete pods -l app=sidekiq
d8 k -n code exec -it deploy/code-toolbox -- gitlab-rake gitlab:fe:secret:verify
d8 k -n code exec -it deploy/code-toolbox -- gitlab-rake gitlab:check SANITIZE=true
Модуль берёт архив резервной копии из бакета резервных копий ресурса CodeInstance, а секреты и SSH-ключи хоста — из объектов Secret в неймспейсе d8-code. Порядок действий описан в разделе «Миграция» документации модуля; установка GitLab из пакета для ОС Linux, о которой там идёт речь, — это инстанс GitLab CE.

После миграции

Если Deckhouse Code работает на другом сервере, направьте DNS-имя инстанса на него, затем проверьте инстанс и завершите перенос:

  1. Войдите в веб-интерфейс под учётной записью GitLab CE и клонируйте репозиторий по HTTPS и по SSH.
  2. Установите лицензионный ключ, как описано в разделе «Лицензия». Без ключа инстанс работает в пробном режиме.
  3. Если внешний адрес изменился, обновите параметр url каждого GitLab Runner в /etc/gitlab-runner/config.toml и перезапустите раннер командой gitlab-runner restart.

Конвейер сохраняет CI_SERVER_URL, CI_PROJECT_URL и другие переменные CI_* на момент своего создания. Если адрес изменился, повторно запущенное задание конвейера, созданного до миграции, использует старый адрес; запустите новый конвейер.

Дополнительные ресурсы

←
Администрирование / Обзор
Миграция / Между типами установки
→