Я не очень горю желанием HC делать на внутренних адресах, ведь доступность может отвалиться и на другом уровне. По этому каждая ВМ имеет внешний статический адрес который используется для проверки. 6 копеек за гигабайт не высокая плата.
Виртуалки очень надежны, аптайм некоторых сервисов исчислялся сотнями дней, но случается так, что целая зона лежит 12 часов (https://status.yandex.cloud/ru/incidents/1129), собственно это и побудило на написание данной статьи.
Да и те же виртуалки надо иногда обслуживать, желательно без большого простоя)
Конечных пользователей (живых) нет, все удаленные клиенты это сервера на колесах (несколько сотен, и не все одновременно в сети), администрировать сетевое оборудование этого парка, выстраивать логику работы переключения на нём накладнее, чем поднять отказоустойчивый впн и поддерживать его иаком.
Для стейдж контура сойдёт, редис заскейлить несложно, обращение через 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:
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.
В kvas требуется отключать системный DNS-сервер, что для меня не подходит. Мне удобен системный DNS благодаря его GUI. К тому же, у меня настроены туннели до работы, и часть зон я маршрутизирую через них. Администрировать это через dnsmasq или bind мне не хочется.
Ну и в целом, мне было интереснее разобраться, как это работает, чем просто взять готовое решение.
ну способ рабочий, имеет право на жизнь)
Я не очень горю желанием HC делать на внутренних адресах, ведь доступность может отвалиться и на другом уровне. По этому каждая ВМ имеет внешний статический адрес который используется для проверки. 6 копеек за гигабайт не высокая плата.
Виртуалки очень надежны, аптайм некоторых сервисов исчислялся сотнями дней, но случается так, что целая зона лежит 12 часов (https://status.yandex.cloud/ru/incidents/1129), собственно это и побудило на написание данной статьи.
Да и те же виртуалки надо иногда обслуживать, желательно без большого простоя)
Конечных пользователей (живых) нет, все удаленные клиенты это сервера на колесах (несколько сотен, и не все одновременно в сети), администрировать сетевое оборудование этого парка, выстраивать логику работы переключения на нём накладнее, чем поднять отказоустойчивый впн и поддерживать его иаком.
рассматривали, нам не подходит)
Для стейдж контура сойдёт, редис заскейлить несложно, обращение через 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::ConcurrentMigrationErrorand other issues when running database migrations using PgBouncer in transaction pooling mode.On the Rails deploy node run the post-deployment migrations:
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.Способ рабочий, но в случае отказа флешки с Entware я тоже не хочу остаться без интернета :)
Отличный краткий пересказ, спасибо! :)
В kvas требуется отключать системный DNS-сервер, что для меня не подходит. Мне удобен системный DNS благодаря его GUI. К тому же, у меня настроены туннели до работы, и часть зон я маршрутизирую через них. Администрировать это через dnsmasq или bind мне не хочется.
Ну и в целом, мне было интереснее разобраться, как это работает, чем просто взять готовое решение.