Путешествие по истории от древних времен до современности

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

Ну и что? «Если он не сломался, не делай ничего», верно? GitLab добавил некоторые полезные функции со времен 6.9.2, в частности, довольно отличный API, который я хотел использовать для отслеживания некоторых проектов и отчетности. Я начал свои поиски, чтобы довести его до скорости.

Примечание. Мы используем PostgreSQL. Некоторые дополнительные шаги могут потребоваться, если вы начинаете работу с MySQL.

Еще одно примечание: если вы хотите пропустить повествование, перейдите к здесь.

Изобретение колеса

Сначала я начал с (случайного) перечисления способов не выполнять обновление. Команда GitLab любезно предоставляет инструкции по обновлению каждой версии до следующей с 2.6 до 10.4. Это здорово, и это было хорошее место для начала, но, используя этот список, мне пришлось бы выполнить где-то около 40 отдельных обновлений, каждое со своим набором шагов (резервное копирование, обновление, исправление, надежда на лучшее, паника, и т.д.). Я быстро решил искать другой путь.

Погуглил как построить колесо

В этот момент я наткнулся на удобную страницу под названием Обновление GitLab через omnibus-gitlab. Сначала я прочитал это, не совсем понимая, что такое омнибус; однако через несколько мгновений я узнал, что омнибус — это либо 1. том, содержащий несколько романов или других произведений, ранее опубликованных отдельно, либо 2. автобус. Я сделал обоснованное предположение и решил, что первое определение, вероятно, более применимо, а затем прочитал еще немного.

Подпишитесь, чтобы получать наши последние блоги

Пятьдесят обсуждений на форуме энтузиастов колес о создании оптимального колеса

GitLab допускает два типа установки: исходную установку и комплексную установку. На высоком уровне установка исходного кода начинается с клонирования репозитория GitLab CE, сборки и запуска оттуда. Омнибус обычно может быть установлен с помощью менеджера пакетов и находится в обычных местах в зависимости от дистрибутива Linux. Я начал с исходной установки, но решил, что хочу перейти на комплексную установку — в основном для упрощения обновлений в будущем.

Построение наименее оптимального колеса

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

Отказаться от колес и сосредоточиться на GitLab

В любом случае это была не очень удачная аналогия

После многих ошибочных попыток, исходящих из сообщения на форуме кто-знает-кто-кто-знает-кто из кто-знает-когда, я, наконец, наткнулся на правильный (или, по крайней мере, рабочий) способ сделать это. Оказывается, в GitLab есть некоторые функции резервного копирования. Процесс перехода от источника к омнибусу прост: создайте резервную копию в исходной установке и восстановите ее в омнибусной установке.

Единственная хитрость здесь в том, что резервное копирование и восстановление должны выполняться одной и той же версией GitLab. Резервная копия исходной версии установки 6.9.2 должна быть восстановлена ​​в комплексной установке версии 6.9.2. К счастью, GitLab предоставляет исторические релизы для омнибусной версии. Мне удалось найти deb-пакет 6.9.2 easy peasy.

Продвигается

Теперь, когда я понял, как получить гладкую комплексную установку, следующим шагом будет выяснить, как я могу избежать обновления одной версии за раз (40 шагов, упомянутых ранее).

Это возвращает меня к странице Обновление GitLab через omnibus-gitlab, которую я обнаружил ранее. На этой странице команда GitLab описывает несколько различных сценариев для пользователей, выполняющих обновление с разных версий на другие, разные версии. Конечно, первый логичный шаг — это просто перебором обновить все дерьмо из установки. Неудивительно, что попытка прямого обновления с 6.9.2 до 10.1 (самая последняя на тот момент) не сработала, и вместо этого все взорвалось. Есть инструкции по такому обновлению, но у меня они почему-то не сработали, и я решил отказаться от этой стратегии и поискать другое решение.

Прыжок, прыжок и прыжок позже, и я вернулся туда, где был до того, как все сломалось (спасибо снимкам). На этот раз я решил использовать некоторые умственные способности и, возможно, прочитать предоставленную документацию. Документ обновления содержал несколько разделов, которые выглядели как дополнительные шаги обновления (хотя и с некоторыми пробелами), которые казались хорошим местом для начала:

По крайней мере, теперь у нас есть несколько логических шагов, чтобы попробовать. Вероятно, в версиях 7.10, 8.11 и 10.0 произошли большие изменения. Достаточно большой, чтобы хотя бы испортить процесс обновления. Авторы включили краткий обзор внесенных изменений в начало каждого раздела.

Прочитав информацию в начале этих разделов, я узнал, что версия 8.15 также является важной ступенькой перед выпуском версии 10.0, поскольку для продвижения вперед требовалась более новая версия PostgreSQL.

Добиться большего прогресса

К настоящему моменту я знал, что мне нужна куча пакетов, и мне нужно будет установить их по порядку и попутно следовать некоторым инструкциям из Обновление GitLab через omnibus-gitlab.

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

Требуется сборка

Этот раздел больше похож на пошаговое руководство, чем на письменный проект средней школы.

Предположения

Мы переходим от исходного кода GitLab 6.9.2 к омнибусу 10.1 Community Edition (CE). Я выполнил этот процесс на установке Ubuntu Trusty, поэтому могут существовать некоторые различия в зависимости от выбранного вами дистрибутива.

Мы предполагаем, что каталог установки исходного кода — /home/git/gitlab, принадлежащий пользователю git.

Мои файлы обновлений (пакеты .deb и т. д.) хранятся в файле в моем домашнем каталоге /home/wmclaughlin/GITLAB-UPGRADE/. Если вы видите этот каталог, вам следует вместо этого использовать путь к файлам на вашем локальном компьютере.

Собираем наши припасы

Сначала нам нужно получить кое-что. Помните, что мы переходим от исходного кода 6.9.2 к омнибусу 10.1 Community Edition (CE). Сначала мы загрузим несколько пакетов. Я прошел через это при установке Ubuntu Trusty, поэтому могут существовать некоторые различия в том, какие пакеты вам нужны.

Краткое примечание, прежде чем мы начнем

На нашей машине было установлено несколько версий PostgreSQL, поэтому, чтобы сделать GitLab счастливым, мне пришлось сделать некоторые символические ссылки, чтобы /usr/bin/pg_dump и /usr/bin/psql указывали на соответствующую версию. Обратите внимание, что могут быть другие способы решения этой проблемы. Я создал короткий bash-скрипт под названием fix_psql_links.sh, содержащий следующие строки:

#!/bin/bash
mv /opt/gitlab/embedded/bin/psql /opt/gitlab/embedded/bin/psql.bak
mv /opt/gitlab/embedded/bin/pg_dump /opt/gitlab/embedded/bin/pg_dump.bak
ln -s /usr/bin/psql /opt/gitlab/embedded/bin/psql
ln -s /usr/bin/pg_dump /opt/gitlab/embedded/bin/pg_dump

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

Примечание в примечании. Для большинства команд в этом сообщении требуется доступ root или sudo.

Создание резервной копии исходной установки версии 6.9.2.

Это оказалось приятно просто. Сначала мы переходим в исходный каталог установки (/home/git/gitlab) и запускаем задачу backup:create.

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

Это должно создать файл резервной копии в каталоге /home/git/gitlab/tmp/backups/. Имя файла будет содержать несколько чисел, представляющих временную метку.

Создание файла gitlab.rb

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

external_url 'http://not.the.actual.url'
postgresql['enable'] = false
gitlab_rails['db_host'] = '/var/run/postgresql'
gitlab_rails['db_port'] = '8999'
gitlab_rails['db_username'] = 'git'

Поля в основном означают то, что они выглядят так, как они означают. external_url определяет, где найти сервер GitLab. Если вы используете порт, отличный от 80, добавьте его в конец external_url (например, http://not.the.actual.url:8888). db_host — это путь к исполняемому файлу PostgreSQL, db_port — порт, через который GitLab должен пытаться подключиться к базе данных, а db_username — это имя пользователя, которое GitLab должен использовать при подключении.

Параметр postgresql[‘enable’] был установлен на false в нашей конфигурации, потому что мы использовали системную установку PostgreSQL, а не ту, которая включена в комплексную установку. Вероятно, это верно для большинства людей при переходе от исходной установки к комплексной установке.

Установка омнибусного пакета 6.9.2 вместе с исходным пакетом

Это снова оказалось относительно просто. Сначала мы устанавливаем комплексный пакет 6.9.2, создаем требуемый каталог /etc/gitlab/, копируем наш новый сверкающий файл gitlab.rb в соответствующее место, останавливаем службу нашей исходной установки, переконфигурируем нашу комплексную установку, чтобы применить наши параметры gitlab.rb с помощью только что установленной команды gitlab-ctl, затем перезапустите нашу комплексную установку на всякий случай.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab_6.9.2-omnibus.2-1_amd64.deb
mkdir -p /etc/gitlab
cp /home/wmclaughlin/GITLAB-UPGRADE/gitlab.rb /etc/gitlab/gitlab.rb
service gitlab stop
gitlab-ctl reconfigure
gitlab-ctl restart

Восстановление нашей резервной копии исходной установки 6.9.2 в нашей комплексной установке 6.9.2

Теперь пришло время переместить нашу резервную копию в нашу новую установку. Сначала мы останавливаем некоторые службы GitLab, которые могут мешать работе, затем используем gitlab-ctl status, чтобы убедиться, что они не работают, и копируем исходный файл резервной копии установки в соответствующее место. запустите восстановление и, наконец, перезапустите службу GitLab.

gitlab-ctl stop unicorn
gitlab-ctl stop sidekiq
gitlab-ctl status
cp /home/git/gitlab/tmp/backups/{{LATEST}} /var/opt/gitlab/backups/

Замените {{LATEST}} файлом, созданным ранее в процессе резервного копирования.

Далее мы собственно запускаем восстановление. На этом шаге вас спросят, хотите ли вы восстановить файл authorized_keys. При установке исходного кода GitLab использовал файл authorized_keys, хранящийся в домашнем каталоге пользователя git. В омнибусе файл перемещается вместе с остальными файлами установки.

Замените {{LATEST,timestamp_only}} только числовой меткой времени из имени файла резервной копии. gitlab-rake на этот раз не ожидает полного имени файла.

gitlab-rake gitlab:backup:restore BACKUP={{LATEST,timestamp_only}}

Наконец, мы перезапускаем сервис GitLab.

gitlab-ctl restart

Проверка нашей реставрации на наличие проблем

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

gitlab-rake gitlab:check SANITIZE=true

Прокрутите вывод и найдите все, что похоже на ошибку. В моем случае мне пришлось выполнить несколько команд, чтобы исправить некоторые проблемы с разрешениями в /var/opt/gitlab/, где установлен комплексный пакет.

sudo chmod -R ug+rwX,o-rwx /var/opt/gitlab/git-data/repositories
sudo chmod -R ug-s /var/opt/gitlab/git-data/repositories
find /var/opt/gitlab/git-data/repositories -type d -print0 | sudo xargs -0 chmod g+s

Затем я снова запустил проверку, чтобы убедиться, что проблем больше нет.

gitlab-rake gitlab:check SANITIZE=true

Оказалось, нужно было еще что-то исправить. Мне пришлось создать спутники репозитория, которые использовались для большинства операций git до версии 8.1.2.

gitlab-rake gitlab:satellites:create RAILS_ENV=production

Кажется, в последних версиях сателлиты больше не используются, и теперь эти операции выполняются на голом репо.

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

Обновление до 7.10.4

Теперь дела начинают идти несколько гладко. Обновление до 7.10.4 так же просто, как установка пакета 7.10.4, который мы скачали ранее.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab-ce_7.10.4~omnibus-1_amd64.deb

Как только этот процесс завершится, поскольку я все еще использовал системный PostgreSQL (как и вы, предположив, что вы использовали тот же файл gitlab.rb), нам нужно будет включить расширение pg_trgm PostgreSQL. Это требуется для версий GitLab 8.10.0 и новее.

Согласно документам PostgreSQL,

Модуль pg_trgm предоставляет функции и операторы для определения подобия буквенно-цифрового текста ASCII на основе сопоставления триграмм, а также классы операторов индексов, которые поддерживают быстрый поиск похожих строк.

Установка pg_trgm

В Ubuntu Trusty pg_trgm включен в пакет postgresql-contrib. В моем случае моя машина использовала PostgreSQL 9.3, поэтому мне нужен был пакет postgresql-contrib-9.3. Это зависит от вашей системы.

apt-get install -y postgresql-contrib-9.3

После установки этого пакета перезапускаем сервис GitLab.

gitlab-ctl restart

Теперь нам нужно включить расширение pg_trgm в нашей базе данных GitLab. Нам нужно переключиться на системного пользователя postgres, подключиться к базе данных PostgreSQL и выполнить команду CREATE EXTENSION. Сначала переключаемся на пользователя postgres.

su - postgres

Вы должны быть переброшены в подсказку как пользователь postgres. Под этим пользователем мы будем подключаться к базе данных GitLab. Замените соответствующий порт для вашей системы.

psql -p 5434 -s gitlabhq_production

Теперь вы должны оказаться в командной строке PostgreSQL. Теперь мы включаем pg_trgm и выходим из командной строки PostgreSQL, используя \q.

CREATE EXTENSION pg_trgm;
\q

Теперь вы вернетесь к подсказке для пользователя postgres. Чтобы выйти из этого приглашения, используйте встроенную оболочку exit.

exit

Теперь вы вернетесь к исходной подсказке. Теперь мы можем продолжить процесс обновления.

Восстановление символических ссылок PostgreSQL

Ранее мы создали bash-скрипт для модификации симлинков на /usr/bin/psql и /usr/bin/pg_dump. Из того, что я собрал, обновления стирают эти символические ссылки, поэтому нам приходится периодически сбрасывать их. Мы сделаем это сейчас, запустив наш скрипт. Опять же, подставьте свое собственное местоположение файла.

/home/wmclaughlin/GITLAB-UPGRADE/fix_psql_links.sh

Обновление до 8.10

Далее мы собираемся установить пакет для 8.10.0.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab-ce_8.10.0-ce.1_amd64.deb

На этом этапе процесса обновления я решил перейти от использования моей собственной установки PostgreSQL к использованию той, которая включена в комплексную установку.

Переход на комплексную установку PostgreSQL, включающую установку

Сначала мы изменим наш файл /etc/gitlab/gitlab.rb, изменив значение postgresql[‘enable’] с false на true. Это можно сделать с помощью вашего любимого текстового редактора.

Далее мы хотим перенастроить GitLab, используя наш новый файл gitlab.rb.

gitlab-ctl reconfigure

Как только это будет завершено, мы снова восстановим наши символические ссылки PostgreSQL.

/home/wmclaughlin/GITLAB-UPGRADE/fix_psql_links.sh

Обновление до 8.11

Далее мы установим пакет 8.11. Этот шаг может быть необязательным, но я решил перейти на 8.11 до 8.15, потому что некоторые были внесены изменения в некоторые секреты.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab-ce_8.11.0-ce.0_amd64.deb

Как и раньше, мы проверим установку на наличие проблем.

gitlab-rake gitlab:check SANITIZE=true

В моем случае мне пришлось снова исправить некоторые разрешения.

sudo chown -R git /var/opt/gitlab/gitlab-rails/uploads
sudo find /var/opt/gitlab/gitlab-rails/uploads -type f -exec chmod 0644 {} \;
sudo find /var/opt/gitlab/gitlab-rails/uploads -type d -not -path /var/opt/gitlab/gitlab-rails/uploads -exec chmod 0700 {} \;

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

Наконец, мы исправим наши символические ссылки перед дальнейшим обновлением.

/home/wmclaughlin/GITLAB-UPGRADE/fix_psql_links.sh

Обновление до 8.15

Далее мы обновимся до 8.15.0.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab-ce_8.15.0-ce.0_amd64.deb

После завершения этого процесса нам нужно обновить включенную установку PostgreSQL.

gitlab-ctl pg-upgrade

Надеюсь, это должно завершиться без проблем, и мы можем продолжить обновление.

Обновление до 10.1.0

Почти готово. Сначала мы хотим установить пакет для 10.1.0.

dpkg -i /home/wmclaughlin/GITLAB-UPGRADE/packages/gitlab-ce_10.1.0-ce.0_amd64.deb

После завершения этого процесса перезапустите службу GitLab.

gitlab-ctl restart

Подведение итогов

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

Возможные проблемы

Следует отметить одну проблему: количество фиксаций на главной странице репозитория может отображаться как 0. Это известная проблема, которая устраняется после первой успешной фиксации.

Автор: Уильям Маклафлин, аналитик по безопасности, Независимые оценщики безопасности

Твиттер: @ISESecurity

Подпишитесь, чтобы получать наши последние блоги