Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.
Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.
Стали ресерчить и решили покрутить параметры Git (похожие проблемы были, например, здесь и здесь):
pack.windowMemory
pack.packSizeLimit
core.packedgitwindowsize
core.packedgitlimit
core.deltacachesize
pack.deltacachesize
pack.window
pack.threads
Потратили какое-то время на проверку различных сочетаний параметров, но, к сожалению, это не помогло. А со временем ситуация бы только ухудшилась.
Чтобы перенести бинарные ассеты в отдельное хранилище и закрыть вопрос, решили подключить Git Large File Storage (документацию по реализации можно найти здесь).
gitlab_rails['lfs_enabled'] = true
в файле
/etc/gitlab/gitlab.rb
и сделать
sudo gitlab-ctl reconfigure
Список типов файлов, которые мы храним в LFS:
*.fbx
*.aar
*.psd
*.zip
*.png
*.exr
*.mp3
*.obj
*.a
*.o
*.pdf
*.mov
*.dylib
*.so
*.jpg
*.wav
*.blend
*.jar
*.tif
*.dll
*.ogg
Некоторые нативные плагины содержат большие бинарный файлы без расширений (в основном — исполняемые). Сначала хотели заводить отдельные файлы .gitattributes в каталогах этих плагинов и указывать в них имена этих файлов. В дальнейшем отказались от этого, чтобы не усложнять работу с репозиторием и избежать проблем в случае изменения структуры каталогов проекта. Например, при обновлении плагинов. Такие файлы сейчас хранятся у нас в обычном Git, не в LFS.
Так как мы использовали Sourcetree в качестве гит-клиента, а его Windows-версия тогда не очень хорошо дружила с LFS, то столкнулись с множеством проблем. Приходилось выкручиваться и как-то решать их, пока в более поздних версиях SourceTree их не пофиксил сам разработчик Atlassian.
Зато мы лучше разобрались во внутреннем устройстве Git и LFS, и сейчас все работает стабильно.
Создание бэкапа
Бэкап делается раз в неделю вызовом скрипта gitlab_backup.sh при помощи cron.
Сам скрипт:
#!/bin/bash
backup_path="/var/opt/gitlab/manual_backups"
current_date="`date +%d:%m:%Y-%H:%M`"
new_date_backup_path="/var/opt/gitlab/backup_storage/$current_date"
fixed_backup_path="/var/opt/gitlab/backup_storage/last_backup"
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
sudo gitlab-rake gitlab:backup:create
sudo rm -fr ${fixed_backup_path}
sudo mkdir ${fixed_backup_path}
sudo mkdir ${new_date_backup_path}
sudo cp -R ${backup_path}/* ${new_date_backup_path}
sudo mv ${backup_path}/* ${fixed_backup_path}
sudo gitlab-ctl restart
В документации нет прямой рекомендации выполнять перед созданием бэкапа, но мы делаем это для большей безопасности:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
Бэкапы регулярно копируются с этой машины и хранятся в отдельном хранилище.
Восстановление из бэкапа
Чтобы восстановить GitLab из резервки, заходим по ssh на гит-машину. Там из папки бэкапа переносим архив, имя которого оканчивается на _gitlab_backup.tar (!), по пути /var/opt/gitlab/manual_backups.
Там должен находиться только выбранный для восстановления архив с правами на чтение и запись. Далее в запущенном Git останавливаем два процесса:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
Затем запускаем команду и следим за процессом восстановления в консоли, иногда утвердительно отвечая на вопросы:
sudo gitlab-rake gitlab:backup:restore
После окончания восстановления запускаем Git:
sudo gitlab-ctl start
Затем пушим ветки с тех клиентов, на которых они в наиболее актуальном состоянии — чтобы в GitLab попали коммиты и ветки, которые были созданы после последнего бэкапа.
Так все и работало, пока в один прекрасный день GitLab восстановился не полностью. При попытке переключиться на ветку он не хотел отдавать отдельные объекты LFS, а в сообщении об ошибке указывались конкретные объекты хранилища, которые были не найдены.
Фикс хранилища LFS
Пришлось на сервер закидывать эти объекты из тех локальных копий, где они были поштучно. Код такой:
scp ~/Projects/pg3d/.git/lfs/objects/32/29/3229f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a9073 git-server@192.168.160.160:/home/git-server/
После этого копируем объект по нужному пути:
mv /home/git-server/3229f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a9073 /var/opt/gitlab/gitlab-rails/shared/lfs-objects/32/29/f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a907
/var/opt/gitlab/gitlab-rails/shared/lfs-objects — путь «по умолчанию» к хранилищу объектов LFS.
Ручной поштучный перенос объектов LFS был долгим и трудоемким, поэтому мы написали скрипт. Теперь при восстановлении из бэкапа не приходится ничего переносить руками, скрипт все делает за нас. Размер бэкапа на момент написания статьи составлял чуть больше 50 ГБ — в таких условиях скрипту для восстановления нужно минимум 200 ГБ свободного места.
Скрипт по ssh соединяется с Git-машиной:
/usr/bin/expect -c "spawn ssh \"git-server@192.168.160.160\" \"'/home/git-server/restore_gitlab_gitlab_side.sh'\" ; expect password; send PASSWORD\n; interact "
И запускает restore_gitlab_gitlab_side.sh:
#!/bin/bash
SUDO_PASSW="PASSWORD"
# каталог куда сохраняются бэкапы при создании (бэкапы создаются каждую неделю заданием cron)
BACKUP_STORAGE="/var/opt/gitlab/backup_storage"
# каталог где должен лежать бэкап, из которого Гитлаб будет восстанавливаться
RESTORE_BACKUP_PATH="/var/opt/gitlab/manual_backups"
# файл бэкапа из которого будем восстанавливаться
BACKUP_TO_RESTORE="latest_gitlab_backup.tar"
Чистим бэкапы старше трех недель, чтобы освободить место:
echo "removing old backups"
cd "$BACKUP_STORAGE/" || { echo 'cd for removing older than 3-week backups failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S find "$BACKUP_STORAGE/" -type d -mtime +21 -exec rm -rf {} \;
echo "freeing additional space"
echo "$SUDO_PASSW" | sudo -S rm -fR $RESTORE_BACKUP_PATH/*
echo "$SUDO_PASSW" | sudo -S rm -fR "$BACKUP_STORAGE/last_backup/tmp"
echo "creating backup of current state"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop unicorn || { echo 'backup of current state stop unicorn failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop sidekiq || { echo 'backup of current state stop sidekiq failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-rake gitlab:backup:create || { echo 'gitlab:backup:create failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl restart || { echo 'backup of current state restart failed' ; exit 1; }
echo "moving backup of current state to backups store"
current_date=$(date +%d:%m:%Y-%H:%M)
new_date_backup_path="$BACKUP_STORAGE/$current_date"
echo "$SUDO_PASSW" | sudo -S mkdir "$new_date_backup_path" || { echo 'mkdir new_date_backup_path failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S mv $RESTORE_BACKUP_PATH/* "$new_date_backup_path" || { echo 'mv new backup failed' ; exit 1; }
echo "fixing permissions for backup of current state"
echo "$SUDO_PASSW" | sudo -S chown -R git:git "$new_date_backup_path" || { echo 'chown backup of current state failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod -R 0660 "$new_date_backup_path" || { echo 'chmod backup of current state failed' ; exit 1; }
Кладем предыдущий бэкап (который был сделан по расписанию). Из него будем восстанавливаться:
echo "preparing to restore from backup"
TAR_FILE=$(echo "$SUDO_PASSW" | sudo -S ls $BACKUP_STORAGE/last_backup/*_gitlab_backup.tar)
echo "$SUDO_PASSW" | sudo -S cp "$TAR_FILE" "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'cp backup to manual_backups failed' ; exit 1; }
echo "checking free space"
# https://unix.stackexchange.com/questions/16640/how-can-i-get-the-size-of-a-file-in-a-bash-script
BACKUP_SIZE=$(echo "$SUDO_PASSW" | sudo -S du -k "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" | cut -f1)
# use backup size*3 ? https://stackoverflow.com/questions/15213127/variables-multiplication
REQUIRED_SPACE=$((BACKUP_SIZE*4))
FREE_SPACE_AVAILABLE=$(df "$PWD" | awk '/[0-9]%/{print $(NF-2)}')
if [[ $FREE_SPACE_AVAILABLE -lt $REQUIRED_SPACE ]]; then
echo "You need $REQUIRED_SPACE or more for successful restore"
exit 1
fi
echo "fixing permissions for backup"
echo "$SUDO_PASSW" | sudo -S chown git:git "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'chown backup failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod 0660 "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'chmod backup failed' ; exit 1; }
echo "restoring"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop unicorn || { echo 'stop unicorn failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop sidekiq || { echo 'stop sidekiq failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S sh -c "yes yes | gitlab-rake gitlab:backup:restore"
echo "successfully restored"
Теперь достанем содержимое хранилища LFS из бэкапа сломанного состояния и смержим его с восстановленным хранилищем LFS. В результате в LFS будут все файлы, которые были в GitLab на момент поломки. А вероятность того, что какой-нибудь объект потеряется — будет меньше.
LFS_STORE_PATH="/var/opt/gitlab/gitlab-rails/shared/lfs-objects"
# для наглядности смотрим размер хранилища LFS до мержа и после
SIZE_OF_LFS_BEFORE_MERGING=$(echo "$SUDO_PASSW" | sudo -S du -sh "$LFS_STORE_PATH")
echo "size of lfs store before merge: $SIZE_OF_LFS_BEFORE_MERGING"
echo "merging lfs of current state with restored state"
CURRENT_STATE_TAR=$(echo "$SUDO_PASSW" | sudo -S ls "$new_date_backup_path")
# lfs.tar.gz — имя подархива LFS в основном tar-файле бэкапа. Мы будем извлекать только LFS из файла бэкапа
LFS_TAR_GZ="lfs.tar.gz"
echo "$SUDO_PASSW" | sudo -S tar -xf "$new_date_backup_path/$CURRENT_STATE_TAR" -C "$new_date_backup_path" "$LFS_TAR_GZ" >/dev/null || { echo 'tar -xf lfs failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S mkdir "$new_date_backup_path/lfs_new" || { echo 'mkdir lfs_new failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S tar -xzf "$new_date_backup_path/$LFS_TAR_GZ" -C "$new_date_backup_path/lfs_new" >/dev/null || { echo 'tar -xzf lfs.tar.gz failed' ; exit 1; }
# Мерж — dажно указывать слэши в конце путей
echo "$SUDO_PASSW" | sudo -S rsync -abuP "$new_date_backup_path/lfs_new/" "$LFS_STORE_PATH/"
echo "$SUDO_PASSW" | sudo -S chown git:git "$LFS_STORE_PATH" || { echo 'chown merged lfs failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod 0755 "$LFS_STORE_PATH" || { echo 'chmod merged lfs failed' ; exit 1; }
SIZE_OF_LFS_AFTER_MERGING=$(echo "$SUDO_PASSW" | sudo -S du -sh "$LFS_STORE_PATH")
echo "size of lfs store after merge: $SIZE_OF_LFS_AFTER_MERGING"
# cleaning up
echo "$SUDO_PASSW" | sudo -S rm -fR "$new_date_backup_path/$LFS_TAR_GZ"
echo "$SUDO_PASSW" | sudo -S rm -fR "$new_date_backup_path/lfs_new"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl start || { echo 'start failed' ; exit 1; }
echo "Finished"
После этого пушим ветки с тех клиентов, на которых они в наиболее актуальном состоянии. В общем-то, все.
Бэкап конфигов и секретов
GitLab не добавляет в бэкап файлы конфига и секреты, поэтому мы делаем их резервные копии вручную. Но пока что ни разу не приходилось их восстанавливать.
Документация GitLab рекомендует для Omnibus-версии делать бэкапы хотя бы файлов /etc/gitlab/gitlab-secrets.json и /etc/gitlab/gitlab.rb. Но мы создаем резервную копию всей папки /etc/gitlab и храним отдельно от основного бэкапа.
Кроме того, в версии 12.3 появился функционал для бэкапа таких файлов. Планируем его использовать, когда обновим GitLab.
Чтобы этого не происходило, мы добавили серверный хук с защитой от пустых коммитов:
#!/usr/bin/env bash
#
# Pre-receive hook that will block any empty commits
# Artists often create empty merge commits by deleting all incoming changes. This hook exists to prevent such situations.
zero_commit="0000000000000000000000000000000000000000"
# Do not traverse over commits that are already in the repository
# (e.g. in a different branch)
# This prevents funny errors if pre-receive hooks got enabled after some
# commits got already in and then somebody tries to create a new branch
# If this is unwanted behavior, just set the variable to empty
excludeExisting="--not --all"
while read oldrev newrev refname; do
echo "$refname" "$oldrev" "$newrev"
# branch or tag get deleted
if [ "$newrev" = "$zero_commit" ]; then
continue
fi
# Check for new branch or tag
if [ "$oldrev" = "$zero_commit" ]; then
span=$(git rev-list $newrev $excludeExisting)
else
span=$(git rev-list $oldrev..$newrev $excludeExisting)
fi
for COMMIT in $span;
do
# if COMMIT is root commit in repo , skip it, because $COMMIT^ will cause error
files_in_commit=$(git diff --name-status $COMMIT^ $COMMIT)
if [ $? -ne 0 ]
then
echo "$COMMIT is root commit? skipping it"
continue
fi
echo "$files_in_commit"
# sed - for skipping blank lines
cnt_files_in_commit=$(echo "$files_in_commit" | sed '/^\s*$/d' | wc -l)
echo "$cnt_files_in_commit"
if [ "$cnt_files_in_commit" -eq 0 ]
then
echo "$COMMIT is empty, cannot push empty commits"
exit 1
fi
done
done
exit 0
Положили его по этому пути:
/var/opt/gitlab/git-data/repositories/USER/PROJECT.git/hooks/pre-receive.d
Здесь важно не забыть дать скрипту права на выполнение. Подробнее про хуки в GitLab можно прочитать по ссылке.
habr.com
Ставили все по официальному гайду. При установке postfix возникли ошибки из-за цифры в имени хоста (решилось переименованием), в остальном сложностей не было. Зато они появились позже: гит-машине перестало хватать памяти на объекты, мы подключили LFS и решили проблему, но потом сломались бэкапы. В общем, было весело. О том, как все это чинили — рассказал под катом.
Подключение LFS
Однажды на одном из проектов гит-машине перестало хватать памяти при перепаковке объектов. Ошибка указывала на большие бинарные ассеты.Стали ресерчить и решили покрутить параметры Git (похожие проблемы были, например, здесь и здесь):
pack.windowMemory
pack.packSizeLimit
core.packedgitwindowsize
core.packedgitlimit
core.deltacachesize
pack.deltacachesize
pack.window
pack.threads
Потратили какое-то время на проверку различных сочетаний параметров, но, к сожалению, это не помогло. А со временем ситуация бы только ухудшилась.
Чтобы перенести бинарные ассеты в отдельное хранилище и закрыть вопрос, решили подключить Git Large File Storage (документацию по реализации можно найти здесь).
gitlab_rails['lfs_enabled'] = true
в файле
/etc/gitlab/gitlab.rb
и сделать
sudo gitlab-ctl reconfigure
Список типов файлов, которые мы храним в LFS:
*.fbx
*.aar
*.psd
*.zip
*.png
*.exr
*.mp3
*.obj
*.a
*.o
*.mov
*.dylib
*.so
*.jpg
*.wav
*.blend
*.jar
*.tif
*.dll
*.ogg
Некоторые нативные плагины содержат большие бинарный файлы без расширений (в основном — исполняемые). Сначала хотели заводить отдельные файлы .gitattributes в каталогах этих плагинов и указывать в них имена этих файлов. В дальнейшем отказались от этого, чтобы не усложнять работу с репозиторием и избежать проблем в случае изменения структуры каталогов проекта. Например, при обновлении плагинов. Такие файлы сейчас хранятся у нас в обычном Git, не в LFS.
Так как мы использовали Sourcetree в качестве гит-клиента, а его Windows-версия тогда не очень хорошо дружила с LFS, то столкнулись с множеством проблем. Приходилось выкручиваться и как-то решать их, пока в более поздних версиях SourceTree их не пофиксил сам разработчик Atlassian.
Зато мы лучше разобрались во внутреннем устройстве Git и LFS, и сейчас все работает стабильно.
Работа с бэкапами
Хранилище LFS также усложнило нам работу с бэкапами. Как-то раз GitLab восстановился не полностью. Причину мы тогда так и не выяснили, но фикс написали — теперь проблем с резервными копиями нет. Пойдем по порядку.Создание бэкапа
Бэкап делается раз в неделю вызовом скрипта gitlab_backup.sh при помощи cron.
Сам скрипт:
#!/bin/bash
backup_path="/var/opt/gitlab/manual_backups"
current_date="`date +%d:%m:%Y-%H:%M`"
new_date_backup_path="/var/opt/gitlab/backup_storage/$current_date"
fixed_backup_path="/var/opt/gitlab/backup_storage/last_backup"
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
sudo gitlab-rake gitlab:backup:create
sudo rm -fr ${fixed_backup_path}
sudo mkdir ${fixed_backup_path}
sudo mkdir ${new_date_backup_path}
sudo cp -R ${backup_path}/* ${new_date_backup_path}
sudo mv ${backup_path}/* ${fixed_backup_path}
sudo gitlab-ctl restart
В документации нет прямой рекомендации выполнять перед созданием бэкапа, но мы делаем это для большей безопасности:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
Бэкапы регулярно копируются с этой машины и хранятся в отдельном хранилище.
Восстановление из бэкапа
Чтобы восстановить GitLab из резервки, заходим по ssh на гит-машину. Там из папки бэкапа переносим архив, имя которого оканчивается на _gitlab_backup.tar (!), по пути /var/opt/gitlab/manual_backups.
Там должен находиться только выбранный для восстановления архив с правами на чтение и запись. Далее в запущенном Git останавливаем два процесса:
sudo gitlab-ctl stop unicorn
sudo gitlab-ctl stop sidekiq
Затем запускаем команду и следим за процессом восстановления в консоли, иногда утвердительно отвечая на вопросы:
sudo gitlab-rake gitlab:backup:restore
После окончания восстановления запускаем Git:
sudo gitlab-ctl start
Затем пушим ветки с тех клиентов, на которых они в наиболее актуальном состоянии — чтобы в GitLab попали коммиты и ветки, которые были созданы после последнего бэкапа.
Так все и работало, пока в один прекрасный день GitLab восстановился не полностью. При попытке переключиться на ветку он не хотел отдавать отдельные объекты LFS, а в сообщении об ошибке указывались конкретные объекты хранилища, которые были не найдены.
Фикс хранилища LFS
Пришлось на сервер закидывать эти объекты из тех локальных копий, где они были поштучно. Код такой:
scp ~/Projects/pg3d/.git/lfs/objects/32/29/3229f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a9073 git-server@192.168.160.160:/home/git-server/
После этого копируем объект по нужному пути:
mv /home/git-server/3229f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a9073 /var/opt/gitlab/gitlab-rails/shared/lfs-objects/32/29/f63c1eb75eaeae57ab3199e8b7555b44906961ef44e38be2500c470a907
/var/opt/gitlab/gitlab-rails/shared/lfs-objects — путь «по умолчанию» к хранилищу объектов LFS.
Ручной поштучный перенос объектов LFS был долгим и трудоемким, поэтому мы написали скрипт. Теперь при восстановлении из бэкапа не приходится ничего переносить руками, скрипт все делает за нас. Размер бэкапа на момент написания статьи составлял чуть больше 50 ГБ — в таких условиях скрипту для восстановления нужно минимум 200 ГБ свободного места.
Скрипт по ssh соединяется с Git-машиной:
/usr/bin/expect -c "spawn ssh \"git-server@192.168.160.160\" \"'/home/git-server/restore_gitlab_gitlab_side.sh'\" ; expect password; send PASSWORD\n; interact "
И запускает restore_gitlab_gitlab_side.sh:
#!/bin/bash
SUDO_PASSW="PASSWORD"
# каталог куда сохраняются бэкапы при создании (бэкапы создаются каждую неделю заданием cron)
BACKUP_STORAGE="/var/opt/gitlab/backup_storage"
# каталог где должен лежать бэкап, из которого Гитлаб будет восстанавливаться
RESTORE_BACKUP_PATH="/var/opt/gitlab/manual_backups"
# файл бэкапа из которого будем восстанавливаться
BACKUP_TO_RESTORE="latest_gitlab_backup.tar"
Чистим бэкапы старше трех недель, чтобы освободить место:
echo "removing old backups"
cd "$BACKUP_STORAGE/" || { echo 'cd for removing older than 3-week backups failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S find "$BACKUP_STORAGE/" -type d -mtime +21 -exec rm -rf {} \;
echo "freeing additional space"
echo "$SUDO_PASSW" | sudo -S rm -fR $RESTORE_BACKUP_PATH/*
echo "$SUDO_PASSW" | sudo -S rm -fR "$BACKUP_STORAGE/last_backup/tmp"
echo "creating backup of current state"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop unicorn || { echo 'backup of current state stop unicorn failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop sidekiq || { echo 'backup of current state stop sidekiq failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-rake gitlab:backup:create || { echo 'gitlab:backup:create failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl restart || { echo 'backup of current state restart failed' ; exit 1; }
echo "moving backup of current state to backups store"
current_date=$(date +%d:%m:%Y-%H:%M)
new_date_backup_path="$BACKUP_STORAGE/$current_date"
echo "$SUDO_PASSW" | sudo -S mkdir "$new_date_backup_path" || { echo 'mkdir new_date_backup_path failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S mv $RESTORE_BACKUP_PATH/* "$new_date_backup_path" || { echo 'mv new backup failed' ; exit 1; }
echo "fixing permissions for backup of current state"
echo "$SUDO_PASSW" | sudo -S chown -R git:git "$new_date_backup_path" || { echo 'chown backup of current state failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod -R 0660 "$new_date_backup_path" || { echo 'chmod backup of current state failed' ; exit 1; }
Кладем предыдущий бэкап (который был сделан по расписанию). Из него будем восстанавливаться:
echo "preparing to restore from backup"
TAR_FILE=$(echo "$SUDO_PASSW" | sudo -S ls $BACKUP_STORAGE/last_backup/*_gitlab_backup.tar)
echo "$SUDO_PASSW" | sudo -S cp "$TAR_FILE" "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'cp backup to manual_backups failed' ; exit 1; }
echo "checking free space"
# https://unix.stackexchange.com/questions/16640/how-can-i-get-the-size-of-a-file-in-a-bash-script
BACKUP_SIZE=$(echo "$SUDO_PASSW" | sudo -S du -k "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" | cut -f1)
# use backup size*3 ? https://stackoverflow.com/questions/15213127/variables-multiplication
REQUIRED_SPACE=$((BACKUP_SIZE*4))
FREE_SPACE_AVAILABLE=$(df "$PWD" | awk '/[0-9]%/{print $(NF-2)}')
if [[ $FREE_SPACE_AVAILABLE -lt $REQUIRED_SPACE ]]; then
echo "You need $REQUIRED_SPACE or more for successful restore"
exit 1
fi
echo "fixing permissions for backup"
echo "$SUDO_PASSW" | sudo -S chown git:git "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'chown backup failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod 0660 "$RESTORE_BACKUP_PATH/$BACKUP_TO_RESTORE" || { echo 'chmod backup failed' ; exit 1; }
echo "restoring"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop unicorn || { echo 'stop unicorn failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S gitlab-ctl stop sidekiq || { echo 'stop sidekiq failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S sh -c "yes yes | gitlab-rake gitlab:backup:restore"
echo "successfully restored"
Теперь достанем содержимое хранилища LFS из бэкапа сломанного состояния и смержим его с восстановленным хранилищем LFS. В результате в LFS будут все файлы, которые были в GitLab на момент поломки. А вероятность того, что какой-нибудь объект потеряется — будет меньше.
LFS_STORE_PATH="/var/opt/gitlab/gitlab-rails/shared/lfs-objects"
# для наглядности смотрим размер хранилища LFS до мержа и после
SIZE_OF_LFS_BEFORE_MERGING=$(echo "$SUDO_PASSW" | sudo -S du -sh "$LFS_STORE_PATH")
echo "size of lfs store before merge: $SIZE_OF_LFS_BEFORE_MERGING"
echo "merging lfs of current state with restored state"
CURRENT_STATE_TAR=$(echo "$SUDO_PASSW" | sudo -S ls "$new_date_backup_path")
# lfs.tar.gz — имя подархива LFS в основном tar-файле бэкапа. Мы будем извлекать только LFS из файла бэкапа
LFS_TAR_GZ="lfs.tar.gz"
echo "$SUDO_PASSW" | sudo -S tar -xf "$new_date_backup_path/$CURRENT_STATE_TAR" -C "$new_date_backup_path" "$LFS_TAR_GZ" >/dev/null || { echo 'tar -xf lfs failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S mkdir "$new_date_backup_path/lfs_new" || { echo 'mkdir lfs_new failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S tar -xzf "$new_date_backup_path/$LFS_TAR_GZ" -C "$new_date_backup_path/lfs_new" >/dev/null || { echo 'tar -xzf lfs.tar.gz failed' ; exit 1; }
# Мерж — dажно указывать слэши в конце путей
echo "$SUDO_PASSW" | sudo -S rsync -abuP "$new_date_backup_path/lfs_new/" "$LFS_STORE_PATH/"
echo "$SUDO_PASSW" | sudo -S chown git:git "$LFS_STORE_PATH" || { echo 'chown merged lfs failed' ; exit 1; }
echo "$SUDO_PASSW" | sudo -S chmod 0755 "$LFS_STORE_PATH" || { echo 'chmod merged lfs failed' ; exit 1; }
SIZE_OF_LFS_AFTER_MERGING=$(echo "$SUDO_PASSW" | sudo -S du -sh "$LFS_STORE_PATH")
echo "size of lfs store after merge: $SIZE_OF_LFS_AFTER_MERGING"
# cleaning up
echo "$SUDO_PASSW" | sudo -S rm -fR "$new_date_backup_path/$LFS_TAR_GZ"
echo "$SUDO_PASSW" | sudo -S rm -fR "$new_date_backup_path/lfs_new"
echo "$SUDO_PASSW" | sudo -S gitlab-ctl start || { echo 'start failed' ; exit 1; }
echo "Finished"
После этого пушим ветки с тех клиентов, на которых они в наиболее актуальном состоянии. В общем-то, все.
Бэкап конфигов и секретов
GitLab не добавляет в бэкап файлы конфига и секреты, поэтому мы делаем их резервные копии вручную. Но пока что ни разу не приходилось их восстанавливать.
Документация GitLab рекомендует для Omnibus-версии делать бэкапы хотя бы файлов /etc/gitlab/gitlab-secrets.json и /etc/gitlab/gitlab.rb. Но мы создаем резервную копию всей папки /etc/gitlab и храним отдельно от основного бэкапа.
Кроме того, в версии 12.3 появился функционал для бэкапа таких файлов. Планируем его использовать, когда обновим GitLab.
Серверный хук для предотвращения коммита сломанных мерджей
Еще небольшой кейс вспомнился. У нас были повторяющиеся случаи, когда разработчики сбрасывали все изменения во время мерджа и коммитили его пустым.Чтобы этого не происходило, мы добавили серверный хук с защитой от пустых коммитов:
#!/usr/bin/env bash
#
# Pre-receive hook that will block any empty commits
# Artists often create empty merge commits by deleting all incoming changes. This hook exists to prevent such situations.
zero_commit="0000000000000000000000000000000000000000"
# Do not traverse over commits that are already in the repository
# (e.g. in a different branch)
# This prevents funny errors if pre-receive hooks got enabled after some
# commits got already in and then somebody tries to create a new branch
# If this is unwanted behavior, just set the variable to empty
excludeExisting="--not --all"
while read oldrev newrev refname; do
echo "$refname" "$oldrev" "$newrev"
# branch or tag get deleted
if [ "$newrev" = "$zero_commit" ]; then
continue
fi
# Check for new branch or tag
if [ "$oldrev" = "$zero_commit" ]; then
span=$(git rev-list $newrev $excludeExisting)
else
span=$(git rev-list $oldrev..$newrev $excludeExisting)
fi
for COMMIT in $span;
do
# if COMMIT is root commit in repo , skip it, because $COMMIT^ will cause error
files_in_commit=$(git diff --name-status $COMMIT^ $COMMIT)
if [ $? -ne 0 ]
then
echo "$COMMIT is root commit? skipping it"
continue
fi
echo "$files_in_commit"
# sed - for skipping blank lines
cnt_files_in_commit=$(echo "$files_in_commit" | sed '/^\s*$/d' | wc -l)
echo "$cnt_files_in_commit"
if [ "$cnt_files_in_commit" -eq 0 ]
then
echo "$COMMIT is empty, cannot push empty commits"
exit 1
fi
done
done
exit 0
Положили его по этому пути:
/var/opt/gitlab/git-data/repositories/USER/PROJECT.git/hooks/pre-receive.d
Здесь важно не забыть дать скрипту права на выполнение. Подробнее про хуки в GitLab можно прочитать по ссылке.
Вместо заключения
В дальнейшем планируем обновить GitLab до актуальной версии. А еще собираемся дополнить наш скрипт восстановления из бэкапа парой новых:- скриптом проверки целостности хранилища LFS на основе этого;
- скриптом актуализации содержимого базы данных LFS и файлов LFS на диске на основе этого и этого.
Как мы переезжали на новую версию GitLab и внедряли LFS. А потом чинили бэкапы
Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и...
habr.com