Как поддерживать много серверов (5000+) в актуальном состоянии с git (и его пределы скорости)?

Question

Мы создаем php сервис, который будет работать на многих серверах, думаю 5000+. Мы размещаем наш код на git (bitbucket). Мы задавались вопросом, каким будет лучший способ поддерживать серверы в актуальном состоянии.

Мы полагали, что или после-фиксации хуки (но что будет тогда, если несколько серверов не получат уведомление об обновлении?) Или git выборка каждую минуту с помощью cron. Мы хотим использовать 1019 * способ cron, так как невозможно, что он выйдет из строя, даже если сервер будет в автономном режиме (либо выключен, либо отключен от сети), он все равно в конечном итоге разрешится.

Мы делаем выборку каждую минуту, а затем сравниваем, чтобы увидеть, нужно ли ему извлекать, если это так, он извлекает и запускает код миграции.

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

Теперь мы задаемся вопросом, а как насчет ограничения скорости? Мы используем bitbucket, а ограничения скорости составляют 60 000 запросов в час (то есть 1000 в минуту), что ограничило бы нас максимум 1000 серверами, прежде чем у нас возникнут проблемы?

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

Это лучший способ справиться с этим? Это кажется очень нетрадиционным. Каков стандартный или рекомендуемый способ справиться с этим (если есть)?

Answer 1

Несмотря на то, что использовать его как единое целое нередко, git не является инструментом развертывания. В лучшем случае он незначительно отвечает потребностям простых рабочих процессов развертывания. Это определенно не инструмент массового развертывания / синхронизации, и хостинговые провайдеры, такие как bitbucket, не предназначены для обслуживания трафика c для такого рода использования.

Даже если вы можете найти В качестве способа заставить это работать, как пользователь bitbucket, я бы ожидал, что он root изо всех, кто пытается использовать эту величину ресурсов. (Что, кстати, может иметь какое-то отношение к ограничениям скорости.)

Вы должны получать каждое обновление один раз (или, самое большее, возможно, один раз на центр обработки данных, если ваши серверы организованы таким образом), выполнить задачи сборки на сервере, который получил обновление, а затем распространить полученные артефакты через собственную сеть. Это хорошо зарекомендовавший себя шаблон с любым количеством инструментов (jenkins, teamcity, ...)