Обновление GitLab (БЕСПЛАТНО)

«=== Загрузка следующей версии для установки ===»

«=== Успешно завершено ===»

«=== Резервное копирование текущего экземпляра ===»

«=== Вытащить новый контейнер ===»

«=== Перезапустить с новым контейнером ===»

«=== Успешно завершено ===»

/// Извлеките текущую версию Gitlab из запущенного контейнера с помощью команды `docker inspect`.

// Запустить команду `docker inspect` и захватить вывод.

// `докер проверяет $CONTAINER_NAME`

// Анализ предыдущего вывода команды и чтение тега изображения Docker.

// Анализ номеров версий.

/// Извлекать доступные теги Gitlab-ce из API-концентратора докеров, пока не будет достигнута заданная версия.

// Запрос API концентратора докеров.

// Сохранить URL следующей страницы.

// Извлечь список тегов.

/// 1. Если существует новая версия патча (тот же основной, тот же дополнительный, более высокий патч), она выбирается.

/// 2. В противном случае, если доступна следующая младшая версия (тот же мажор, младшая + 1, любой патч), она выбирается.

/// 3. В противном случае, если ALLOWED BY CONF и доступна следующая основная версия (основная + 1, дополнительная = 0, любой патч), она выбирается.

/// 4. В противном случае возвращается null: доступных обновлений нет.

// Получить следующую версию исправления, если она доступна.

// Получить следующую дополнительную версию, если она доступна.

// Получить следующую основную версию, если она доступна.

/// Сделайте резервную копию, выполнив команду `gitlab-rake gitlab:backup:create` в работающем контейнере.

// `docker exec -t $CONTAINER_NAME gitlab-rake gitlab:backup:create`

/// Вытащите контейнер Gitlab с заданной версией.

// `docker pull gitlab/gitlab-ce:$VERSION`

/// Остановить работающий контейнер Gitlab.

// `docker stop $CONTAINER_NAME`

/// Удалить текущий контейнер Gitlab.

// `docker container rm $CONTAINER_NAME`

/// Запуск контейнера Gitlab данной версии.

/// Показать журналы.

// `docker logs -f $CONTAINER_NAME`

/// Дождаться запуска контейнера.

Содержание
  1. Обновите GitLab с помощью пакета GitLab (БЕСПЛАТНО)
  2. Предпосылки
  3. Время простоя
  4. Изменения, зависящие от версии
  5. Сделайте резервную копию перед обновлением
  6. Обновите с помощью официальных репозиториев
  7. Обновите до последней версии, используя официальные репозитории
  8. Обновите до определенной версии, используя официальные репозитории
  9. Обновление с помощью загруженного вручную пакета
  10. Обновите документацию по продукту
  11. Устранение неполадок
  12. Получить статус установки GitLab
  13. Ошибка RPM "пакет уже установлен"
  14. Пакет устарел из-за установленного пакета
  15. Ошибка 500 при доступе к Проекту > Настройки > Репозиторий
  16. Ошибка Failed to connect to the internal GitLab API на отдельном сервере GitLab Pages
  17. Ошибка An error occurred during the signature verification при беге apt-get update
  18. Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails] [..] Command timed out after 3600s
  19. Отсутствующие файлы активов
  20. Старые процессы
  21. Файлы дубликатов звездочек
  22. Неполная установка
  23. Поддержка NGINX Gzip

Обновите GitLab с помощью пакета GitLab (БЕСПЛАТНО)

Вы можете обновить GitLab до новой версии с помощью
Пакет GitLab.

Предпосылки

  • Решите, когда обновлять, просмотрев поддерживаемые пути обновления
    .
    Вы не можете напрямую пропустить основные версии (например, перейти с 10.3 на 12.7 за один шаг).
  • Если вы переходите с установки без пакета на установку пакета GitLab, см.
    Обновление с непакетной установки до установки пакета GitLab
    .
  • Убедитесь, что любой
    фоновые миграции

    полностью завершены. Обновление
    до завершения фоновой миграции может привести к повреждению данных.
    Мы рекомендуем выполнять обновления между основными и дополнительными выпусками не чаще одного раза за
    неделе, чтобы дать время для завершения фоновой миграции.

  • Серверы Gitaly необходимо обновить до более новой версии перед обновлением сервера приложений.
    Это не позволяет клиенту gRPC на сервере приложений отправлять RPC, которые были в старой версии Gitaly.
    не поддерживает.

Время простоя

  • Для установок с одним узлом GitLab недоступен для пользователей, пока
    идет обновление. Веб-браузер пользователя показывает Deploy in progress
    сообщение или 502
    ошибка.
  • Для многоузловых установок см., как выполнить
    обновления без простоев
    .
  • Также можно выполнить обновление до многоузловых установок.
    с простоями
    .

Изменения, зависящие от версии

Сделайте резервную копию перед обновлением

Перед установкой новой версии GitLab создается резервная копия базы данных GitLab. Ты
может пропустить это автоматическое резервное копирование базы данных, создав пустой файл
в /etc/gitlab/skip-auto-backup
:

  /etc/gitlab/skip-auto-backup
  

Тем не менее, настоятельно рекомендуется поддерживать полную актуальность
резерв
самостоятельно.

Обновите с помощью официальных репозиториев

Все пакеты GitLab публикуются на сервере пакетов GitLab
.
Поддерживается пять репозиториев:

  • gitlab/gitlab-ee

    : Полный
    Пакет GitLab, содержащий все функции Community Edition, а также
    Корпоративная версия
    те.
  • gitlab/gitlab-ce

    : Раздетый
    down пакет, содержащий только функции Community Edition.
  • gitlab/unstable

    : Релиз-кандидаты и другие нестабильные версии.
  • gitlab/nightly-builds

    : Ночные сборки.
  • gitlab/raspberry-pi2

    : Официальные выпуски Community Edition, созданные для Raspberry Pi
    пакеты.

Если вы установили GitLab Community Edition

или Enterprise Edition
, то
официальный репозиторий GitLab уже должен быть настроен для вас.

Обновите до последней версии, используя официальные репозитории

Если вы регулярно обновляете GitLab, например, раз в месяц, вы можете перейти на
последнюю версию с помощью менеджера пакетов.

Чтобы перейти на последнюю версию GitLab:

 
apt update  apt gitlab-ee

# RHEL/CentOS 6 and 7
yum gitlab-ee

# RHEL/CentOS 8
dnf gitlab-ee


zypper gitlab-ee
  

ПРИМЕЧАНИЕ:
Для GitLab Community Edition замените gitlab-ee
с
gitlab-ce
.

Обновите до определенной версии, используя официальные репозитории

Менеджеры пакетов Linux по умолчанию устанавливают последнюю доступную версию
пакет для установки и обновления. Обновление непосредственно до последней основной
версия может быть проблематичной для более старых версий GitLab, которые требуют многоэтапного
путь улучшения
. Путь обновления может охватывать несколько
версии, поэтому вы должны указывать конкретный пакет GitLab при каждом обновлении.

Чтобы указать предполагаемый номер версии GitLab в установке вашего менеджера пакетов
или команда обновления:

  1. Определите номер версии установленного пакета:

    
       apt-cache madison gitlab-ee 
    
       
    
        # RHEL/CentOS 6 и 7 
      
    
       yum list gitlab-ee 
    
       
    
        # RHEL/CentOS 8 
      
    
       dnf list gitlab-ee 
    
       
    
    
       zypper search gitlab-ee 
    
       
    
    
  • 
       apt gitlab-ee 
    
       
    
        # RHEL/CentOS 6 и 7 
      
    
       yum gitlab-ee- 
    
       
    
        # RHEL/CentOS 8 
      
    
       dnf gitlab-ee- 
    
       
    
    
       zypper gitlab-ee 
    
       
    
    
  • ПРИМЕЧАНИЕ: Для GitLab Community Edition замените gitlab-ee с gitlab-ce .

    Обновление с помощью загруженного вручную пакета

    ПРИМЕЧАНИЕ: Репозиторий пакетов рекомендуется более ручная установка.

    Если по какой-то причине вы не пользуетесь официальными репозиториями, вы можете скачайте пакет и установите его вручную. Этот метод можно использовать либо для установите GitLab в первый раз или обновите его.

    Чтобы загрузить и установить GitLab:

    1. Посетите официальный репозиторий вашего пакета.

    2. Отфильтруйте список, выполнив поиск версии, которую хотите установить (например, 14.1.8). Для одной версии может существовать несколько пакетов, по одному для каждого поддерживаемого дистрибутива. и архитектура. Рядом с именем файла находится метка, указывающая на дистрибутив, так как имена файлов могут быть одинаковыми.

    3. Найдите версию пакета, которую хотите установить, и выберите имя файла из списка.

    4. В правом верхнем углу выберите Скачать .

    5. 
         dpkg  
      
         
      
          # RHEL/CentOS 6 и 7 
        
      
         об/мин  
      
         
      
          # RHEL/CentOS 8 
        
      
         dnf  
      
         
      
      
         zypper  
      
         
      
      

    ПРИМЕЧАНИЕ: Для GitLab Community Edition замените gitlab-ee с gitlab-ce .

    Обновите документацию по продукту

    Это необязательный шаг. Если вы установили документацию по продукту , узнайте, как перейти на более позднюю версию .

    Устранение неполадок

    Получить статус установки GitLab

     gitlab-ctl status
    gitlab-rake gitlab:check 
      

    • Информация по использованию gitlab-ctl
      выполнять ремонтные работы
      .
    • Информация по использованию gitlab-rake
      для проверить конфигурацию
      .

    Ошибка RPM "пакет уже установлен"

    Если вы используете RPM и выполняете обновление с GitLab Community Edition до GitLab Enterprise Edition, вы можете получить такую ​​ошибку:

     package gitlab-7.5.2_omnibus.5.2.1.ci-1.el7.x86_64 which is newer than gitlab-7.5.2_ee.omnibus.5.2.1.ci-1.el7.x86_64 is already installed
      

    Вы можете переопределить эту проверку версии с помощью --oldpackage
    вариант:

     rpm   gitlab-7.5.2_ee.omnibus.5.2.1.ci-1.el7.x86_64.rpm
      

    Пакет устарел из-за установленного пакета

    Пакеты CE и EE помечены как устаревшие и заменяющие друг друга, так что оба не устанавливаются и не работают одновременно.

    Если вы используете локальные файлы RPM для переключения с CE на EE или наоборот, используйте rpm
    для установки пакета, а не yum
    . Если вы попытаетесь использовать yum, то можете получить такую ​​ошибку:

     Cannot install package gitlab-ee-11.8.3-ee.0.el6.x86_64. It is obsoleted by installed package gitlab-ce-11.8.3-ce.0.el6.x86_64
      

    Чтобы избежать этой проблемы, либо:

    • Используйте те же инструкции, что и в
      Обновление с помощью загруженного вручную пакета
      раздел.
    • Временно отключите эту проверку в yum, добавив --setopt=obsoletes=0
      к параметрам, данным команде.

    Ошибка 500 при доступе к Проекту > Настройки > Репозиторий

    Эта ошибка возникает, когда GitLab преобразуется из CE > EE > CE, а затем обратно в EE.
    При просмотре настроек репозитория проекта в логах можно увидеть эту ошибку:

     Processing by Projects::Settings::RepositoryController#show as HTML
    
    
    
    NoMethodError undefined method commit_message_negative_regex' for #<PushRule:0x00007fbddf4229b8>
    Did you mean?  commit_message_regex_change):
      

    Эта ошибка вызвана добавлением функции EE в экземпляр CE при первоначальном переходе на EE.
    После того, как экземпляр будет перемещен обратно в CE, а затем снова обновлен до EE,
    push_rules
    таблица уже существует в базе данных. Таким образом, миграция является
    не могу добавить commit_message_regex_change
    столбец.

    Это приводит к обратной миграции таблиц EE
    не работает правильно.
    Миграция обратного порта предполагает, что определенные таблицы в базе данных не существуют при запуске CE.

    Чтобы решить эту проблему:

    1. Запустите консоль базы данных:

      В GitLab 14.2 и более поздних версиях:

       gitlab-rails dbconsole  main
        

      В GitLab 14.1 и более ранних версиях:

       gitlab-rails dbconsole
        

    2. Вручную добавить недостающие commit_message_negative_regex
      столбец:

             
      
        
      
        

    Ошибка Failed to connect to the internal GitLab API
    на отдельном сервере GitLab Pages

    Ошибка An error occurred during the signature verification
    при беге apt-get update

    Чтобы обновить ключ GPG сервера пакетов GitLab, выполните:

     
    
      

    Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails] [..] Command timed out after 3600s

    Если схема базы данных и изменения данных (миграция базы данных) должны выполняться более одного часа,
    апгрейды терпят неудачу с timed out
    ошибка:

     
    
    (/opt/gitlab/embedded/cookbooks/cache/cookbooks/gitlab/resources/rails_migration.rb line 16)
    had an error: Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:
      

    Чтобы исправить эту ошибку:

    1. Запустите остальные миграции базы данных:

       gitlab-rake db:migrate
        

      Выполнение этой команды может занять очень много времени. Использование screen
      или какой-либо другой механизм, обеспечивающий
      программа не прерывается, если ваш сеанс SSH обрывается.

    2. Завершите обновление:

       gitlab-ctl reconfigure
        

    3. Горячая перезагрузка puma
      и sidekiq
      услуги:

       gitlab-ctl hup puma
      gitlab-ctl restart sidekiq
        

    Отсутствующие файлы активов

    В масштабируемой среде GitLab, если один веб-сервер за балансировщиком нагрузки демонстрирует
    эта проблема, проблема возникает периодически.

    Задача Rake для перекомпиляции
    в
    активы не применяются к установке Omnibus, которая обслуживает
    предварительно скомпилированные активы из /opt/gitlab/embedded/service/gitlab-rails/public/assets
    .

    Возможные причины и исправления:

    Старые процессы

    Наиболее вероятная причина в том, что запущен старый процесс Puma, инструктирующий клиентов
    для запроса файлов ресурсов из предыдущей версии GitLab. Поскольку файлы больше не существуют,
    Возвращаются ошибки HTTP 404.

    Перезагрузка — лучший способ убедиться, что эти старые процессы Puma больше не работают.

    1. Проверить оставшиеся процессы Puma и убить их:

       
      
        

    2. Подтвердить с помощью ps
      что процессы Puma перестали работать.

    Файлы дубликатов звездочек

    Скомпилированные файлы активов имеют уникальные имена файлов в каждом выпуске. Файлы sprockets
    обеспечить сопоставление имен файлов в коде приложения с уникальными именами файлов.

     
      

    Убедитесь, что файл sprockets только один. Rails использует первый
    .

    Во время обновлений Omnibus GitLab запускается проверка на дубликаты файлов sprockets:

     GitLab discovered stale file(s) from the previous install that need to be cleaned up.
    
    
    
      

    Варианты решения этой проблемы включают:

    • Если у вас есть результат обновления пакета, удалите указанные файлы. Затем перезапустите Puma:

    Неполная установка

    Причиной этой проблемы может быть неполная установка.

    Проверьте пакет, чтобы определить, не в нем ли проблема:

    • Для дистрибутивов Debian:

       apt-get debsums
      debsums  gitlab-ee
        

    • Для дистрибутивов Red Hat/SUSE (RPM):

    Чтобы переустановить пакет для исправления незавершенной установки:

    1. Проверить установленную версию

      • Для дистрибутивов Debian:

         apt  list gitlab-ee
          

      • Для дистрибутивов Red Hat/SUSE (RPM):

    2. Переустановите пакет, указав установленную версию. Например, 14.4.0 Enterprise Edition:

      • Для дистрибутивов Debian:

         apt-get   gitlab-ee14.4.0-ee.0
          

      • Для дистрибутивов Red Hat/SUSE (RPM):

         yum reinstall gitlab-ee-14.4.0
          

    Поддержка NGINX Gzip

      /etc/gitlab/gitlab.rb
      

    Читайте также:  VPS за 40 рублей в месяц
    Оцените статью
    Хостинги