Как мы внедряли отказоустойчивый GitLab Cluster с использованием Ansible и бесшовными обновлениями

[alexq2]

Топовая отказоустойчивость! Один редис, одна база, один балансер!

[BaCuJIuu]

Для стейдж контура сойдёт, редис заскейлить несложно, обращение через sentinel, использовать pgbouncer и несколько инстансом postgresql тоже не запрещено, главное помнить что при обновлении гитлаба, необходимо переключиться напрямую к мастер постгре.

Из статьи Zero-downtime upgrades:

In addition to the above, Rails is where the main database migrations need to be executed. Like Praefect, the best approach is by using the deploy node. If PgBouncer is currently being used, it also needs to be bypassed as Rails uses an advisory lock when attempting to run a migration to prevent concurrent migrations from running on the same database. These locks are not shared across transactions, resulting in ActiveRecord::ConcurrentMigrationError and other issues when running database migrations using PgBouncer in transaction pooling mode.

On the Rails deploy node run the post-deployment migrations:

1. Ensure the deploy node is still pointing at the database leader directly. If the node is currently going through PgBouncer to reach the database then you must bypass it and connect directly to the database leader before running migrations.

   • To find the database leader you can run the following command on any database node - sudo gitlab-ctl patroni members.

[Ivan_Zalutskii]

Теперь у вас есть +13 серверов под GitLab. Не расматривали использование Kubernetes, на меньшем количестве серверов, внутрикоторого поднято все то, что описано в статье?

[BaCuJIuu]

рассматривали, нам не подходит)

[pit_art]

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

[alexey_melezhik]

В статье рассказывается о бесшовном обновлении сложной распределенной системы, где в качестве инструмента выбран ансибл , но ничего не сказано про важные детали без которых статья - всего лишь скучное перечисление кода ансибл инвентари файлов и прочего , интересны ответы на такие вопросы:

• можно ли контролировать порядок обхода узлов системы при обновлении ?

• что делать если в ходе обновления часть компонентов не обновилась или произошло сбой , поидее система в общем случае может прийти в неконсистентное состояние ( часть версий новые, часть старые и так далее ) - как быть с этим?

• можно ли в случае необходимости обновлять только часть компонентов ( для экономии времени или при ручном конфигурировании , когда нужно фиксить проблемы по местам )

Все эти важные и интересные детали не раскрыты увы в статье .

то есть конечно можно предположить что посыл автора такой что ансибл делает свою магию и все всегда хорошо, но я в этом сильно сомневаюсь )

[pit_art]

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

• можно ли контролировать порядок обхода узлов системы при обновлении ?

В нашем случае энсибла бегает по хостам с serial=1 в том порядке, который описан в оффдоке гитлаба по бесшовному обновлению. сначала первая нода рельсов + миграции в базу, далее оставшиеся рельсы, сайдкики, префект и гитали. Перед каждым апдейтом нода рельсов/префекта из ротации в хапроксе, и перед включением обратно проверяются хэлсчеки и запускаются другие тесты. Контролировать порядок обхода вручную в нашем случае смысла нет.

• что делать если в ходе обновления часть компонентов не обновилась или произошло сбой , поидее система в общем случае может прийти в неконсистентное состояние ( часть версий новые, часть старые и так далее ) - как быть с этим?

Гитлаб спокойно переживает такие ситуации, если обновление было в рамках одной минорной версии. Косяки могут вылезать раз в год при обновлении мажорной версии, но тут уже ничего не поделаешь особо. Если упало обновление - его надо перезапустить, возможно исправив ошибку, которая его вызвала и все придет в порядок. В некоторых случаях внутренний конфигуратор гитлаба ломается и не лечится командой reconfigure. В таком случае пакет надо удалить и вычистить все файлы гитлаба на хосте, у нас для этого есть отдельная переменная для энсибла, ничего страшного в её использовании нет - только скорость работы энсибла с ней резко падает - на полную переустановку нужно больше времени, чем на обновление/изменение конфигурации.

• можно ли в случае необходимости обновлять только часть компонентов ( для экономии времени или при ручном конфигурировании , когда нужно фиксить проблемы по местам )

энсибловый --limit c этим прекрасно справляется. Если нам надо изменить конфиг тех же гиталей, и мы понимаем что в остальных компонентах ничего не менялось - почему бы и нет. Надо правда понимать при этом что делаешь, чтобы не получить, например гитали верси 17.0 при версии остального кластер 16.11.

Василий как будто не приложил к статье нашу гелекси-роль, исправлюсь за него. Да, она делает всю магию. Нет, в этом нет ничего необычного. К сожалению ридми роли оставляет желать лучшего https://gitlab.com/pit.artamonov/gitlab-omnibus