Как мы внедряли отказоустойчивый 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]

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

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

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

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

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

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