Я ищу правильное решение своей проблемы.
Проблема заключается в следующем: выполнение скользящего обновления на всех веб-серверах в группе экземпляров без одновременного обслуживания различного контента и достижение нулевого времени простоя.
У меня есть машина для развертывания, которая служит испытательной площадкой, прежде чем запланировано развертывание обновления, весь новый контент будет развернут на этой машине и протестирован (эта машина должна быть самым современным веб-сервером), когда содержимое проверено и с обновлением нет проблем, предпринимаются следующие шаги.
Я не могу добиться нулевого времени простоя, хотя я установил для параметра «Максимум недоступности» значение ноль, и я не обслуживаю только контент с недавно обновленной машины в момент, когда первый вычислительный экземпляр подключается к сети, что приводит к обслуживанию 2 разных версий в то же время.
Серверы не отвечают 1-10 секунд, и я получаю классический <h2>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds.</h2> ошибка.
Есть ли более простой способ сделать это, не возвращаясь к настройке моего собственного вычислительного экземпляра Haproxy и выполняя следующие шаги.
Это должно было быть сделано безупречно с «обычными» экземплярами (ex LAP), а не только с образами докеров, хотя я не могу найти никаких ресурсов по этой теме.
РЕДАКТИРОВАТЬ: выполнение скользящего обновления путем редактирования группы экземпляров, изменения шаблона экземпляра и выполнения операции скользящей замены приводит к нулевому времени простоя, мне кажется странным, что функция скользящего обновления не может достичь этого также.
Был бы очень признателен за ваш вклад.
Последовательное обновление - это постепенный процесс обновления ваших экземпляров. Стремление к нулевому времени простоя должно быть достижимо, однако обслуживание различного контента будет видно из-за того, как работают скользящие обновления. Чтобы сделать ваши серверы более отзывчивыми и менее разрушительными, обратите внимание на следующие две стратегии:
Максимальный всплеск. Это создаст экземпляры выше целевого размера, чтобы ускорить процесс обновления.
Оппортунистическое обновление. «Гибкое обновление применяется только тогда, когда новые экземпляры создаются группой управляемых экземпляров»