Настраиваем бэкап Gitlab в Amazon S3

С любым сервером, который что-нибудь хранит (картинки, сайты, файлы) рано или поздно происходит некоторое дерьмо, из-за которого хранимый контент исчезает. Чтобы предотвратить стремные последствия потери контента, мы обычно бэкапим все и бэкапы тоже бэкапим. И всё это на регулярной основе в автоматическом режиме.

В случае с Gitlab бэкапить нужно конфиги самого приложения и хранимые там данные.

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

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

Когда позвали провести аудит инфры

Чтобы такого не происходило, существуют всякие провайдеры типа AWS S3, Google Cloud Storage, RackSpace Cloud Files и другие. У каждого из них существуют свои, определенные протоколы хранения данных и их восстановления на случай, например, возгорания дата центра.

Перейдем непосредственно к самим бэкапам. Исходя из предположения, что нам нужно будет только загружать и хранить файлы в облаке, оптимальнее всего (дешевле) хранить все в S3. Мы будем загружать файлы в Standart Storage и по истечении какого-то времени перемещать их в Glacier Storage, а по истечении года удалять их и оттуда.

Начнем.

Зарегистрируйте аккаунт на AWS. Amazon дает 12 месяцев бесплатного пользования для новых пользователей. После регистрации откройте AWS Console, нажмите Sign In to the Console и завершите регистрацию.

Теперь вам необходимо создать bucket. Это что-то вроде ведра, в который Amazon сгружает ~~дерьмо~~ бэкапы. Отправляйтесь сюда и нажмите Create Bucket. Заполните форму: укажите название, регион (если вы в России – выбирайте поближе что-нибудь, если в Европе – выбирайте ту же локацию, в которой работаете, GDPR и так далее) и жмите Create. Ваше ведро готово принимать файлы.

Теперь нам нужно настроить жизненный цикл хранимых файлов. Нажмите на только что созданный бакит и перейдите в Properties. Перейдите в Lifecycle и создайте правило. В появившемся визарде настройте все по своим предпочтениям. Для примера можно указать, чтобы через 30 дней файлы перемещались в Glacier и через 365 дней удалялись безвозвратно.

Следующий шаг – создать и сконфигурировать пользователя, который будет загружать файлы. Мы настоятельно не рекомендуем использовать root для этого (аккаунт, под которым вы сейчас в консоли AWS), потому что акк могут угнать и сами понимаете последствия, да. Поэтому, создадим IAM пользователя. Нажмите на Users слева и затем на кнопку Create New User. Вы можете создавать до 5 пользователей за раз, но нам потребуется только один. Укажите имя и оставьте галочку на пункте Generate an access key for each user, это важно. Нажмите Create и скачайте себе секреты по кнопке Download Credentials.

Теперь создадим группу для управления правами доступа нашего пользователя. Нажмите Groups слева и создайте группу. Затем перейдите в группу, нажмите Permissions и раскройте пункт Inline Policies. Нажмите на ссылку Click Here и нажмите на кнопку Policy Generator. Выберите S3 в дропдауне AWS Service и отметьте следующие действия для указанных ресурсов:

# Resource - "arn:aws:s3:::<bucket-name>/*" 
"s3:AbortMultipartUpload",
"s3:GetBucketAcl",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:ListBucketMultipartUploads",
"s3:PutObject",
"s3:PutObjectAcl"

# Resource - "*"
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"

# Resource - "arn:aws:s3:::<bucket-name>"
"s3:ListBucket"

После добавления каждого пункта нажимайте Add Statement и в конце Next Step. Дайте название политике. Она будет расположена во вкладке Permissions вашей группы.

Перейдите во вкладку Users внутри вашей группы. Нажмите Add Users To Group и добавьте пользователя, которого создали ранее.

Готово, вы восхитительны! Мало кто доходит до этого шага самостоятельно. Осталось самое легкое – научить Gitlab бэкапить самого себя на регулярной основе.

Откройте файл /etc/gitlab/gitlab.rb и найдите фразу manage_backup_path (тут детали).

gitlab_rails['manage_backup_path'] = true
gitlab_rails['backup_path'] = "/path/to/backup/location/in/server"
# gitlab_rails['backup_archive_permissions'] = 0644 
# See: http://doc.gitlab.com/ce/raketasks/backup_restore.html#backup-archive-permissions
# gitlab_rails['backup_pg_schema'] = 'public'# gitlab_rails['backup_keep_time'] = 604800
gitlab_rails['backup_upload_connection'] = {   
'provider' => 'AWS',   
'region' => 'us-west-2',   
'aws_access_key_id' => '_secret_id_',   
'aws_secret_access_key' => '_secret_key_'
}
gitlab_rails['backup_upload_remote_directory'] = 'bucket-name'
gitlab_rails['backup_multipart_chunk_size'] = 104857600
gitlab_rails['backup_encryption'] = 'AES256' # Turns on AWS Server-Side Encryption with Amazon S3-Managed Keys for backups

В зависимости от выбранного региона, вам нужно вставить его алиас. AWS Secret Access Key и Access Key Id находятся в секретах, которые вы скачивали ранее при создании IAM юзера. Bucket-name замените на название вашего бакита.

Почти готово, теперь перезапустим Gitlab и создадим первый бэкап!

gitlab-ctl reconfigure
gitlab-rake gitlab:backup:create

Если вы все сделали правильно, то в вашем баките вы увидите первый .tar файл.

Всё? Нет! Мы же не будем ручками бэкапы запускать. Мы с вами нормальные ~~пацаны~~ девопсы, мы воспользуемся cron: sudo crontab -e -u root

Надеюсь, с синтаксисом крона вы знакомы. Если нет – вот хорошая статья.

Добавим в конец нашего крон файла строчку:

59 23 * * 7 /usr/bin/gitlab-rake gitlab:backup:create

Уважаемый редактор

Готово! Будем надеяться, что бэкапы вам никогда не пригодятся, конечно, но в следующих статьях мы расскажем как проводить учения по их извлечению.