Бесшовный деплой и оркестрация

Реализация Continuous Deployment. Алгоритм Rolling Updates для бесшовного обновления контейнеров. Использование оркестраторов для деплоя на кластер из нескольких машин.

  • 00:01:42 - Неудобство классического деплоя
  • 00:03:20 - Способ бесшовного обновления
  • 00:05:58 - Rolling Update
  • 00:08:54 - Настройки репликации
  • 00:10:20 - Проверка здоровья контейнера
  • 00:13:30 - Поддержка нескольких машин
  • 00:15:11 - Docker Swarm
  • 00:21:23 - Сравнение инструментов
Скрытый контент
Комментарии (17)
Arunas

Очень спасибо.

Ответить
Bondarenko Alexandr

Супер!

Ответить
Arunas

А как сделать бесшовный prod deploy на несколько сайтов: напр. сегодня на example1.com, завтра на example2.com? Можно ли как то проще собрать env по этому вопросу?

Ответить
Дмитрий Елисеев

Да, можно переделать gateway так, чтобы имя домена передавать через переменную окружения. Например, в нём подменить ENTRYPOINT на скрипт, который будет подставлять значения переменных окружения в шаблон conf-файла через команды sed или envsubst.

Ответить
Arunas

спасибо.

Ответить
Дмитрий

Когдаж код пойдет. Курс по девопсу какой-то )

Ответить
Дмитрий Елисеев

Это серия про все аспекты разработки проекта, а не только про код.

Ответить
fedot

Дмитрий, а а как быть если в момент пересборки контейнера на проде есть сессия пользователя? ведь в момент переключения контейнера он потеряет данные. Можно ли как то сохранять существующие подключения? или ждать их завершения не давая создавать новые или еще как то?

Ответить
Дмитрий Елисеев

Процессам nginx и php-fpm от Docker передаётся стандартный сигнал завершения программы и они останавливаются по своей логике. Если кто-то не остановился, то через некоторое время процесс уже принудительно убивается через kill.

Если же есть постоянное WebSocket-соединение, то оно отключится. Просто нужно написать JavaScript-код так, чтобы он переподключался при разрывах.

Ответить
fedot

Спасибо, за ответ, а есть ли возможность подать сигнал завершения таким образом, что что бы апач и нгинкс ждали конца текущей сессий не открывая новую пока не произойдет рестарт? Я не смог найти что-то, такое умное завершение было бы на порядок надежнее, загромождения логики лишними проверками, а при таком подходе как у нас, обрывы могут быть частыми, а в некоторых случаях потеря данных пользователя при неоконченном вводе недопустима, неужели никто ничего не придумал?
Так то понятно, что если обновлять склад при каждом изменении поля, то информация не должна пропасть, так как данные будут в браузере, но все равно как то стремно.

Ответить
Дмитрий Елисеев

не открывая новую пока не произойдет рестарт

Сам оркестратор перестаёт направлять запросы на останавливающийся контейнер. Так что новые запросы в него и так не попадут.

потеря данных пользователя при неоконченном вводе

Ввод обычно отправляется не постепенно, а целиковым Ajax-запросом, который либо совершится, либо вылетит с ошибкой валидации, сервера или соединения. Тогда можно на фронтенде вывести сообщение "Попробуйте снова" или через setTimeout попробовать отправить повторно самому.

Если имеется в виду многошаговый ввод, то промежуточные данные нужно сохранять в БД или Redis с привязкой к идентификатору посетителя, а не в файлах сессии в самом PHP-контейнере.

Если же где-то и ввод осуществляется через WebSocket, то нужно делать обработку обрывов в любом случае, а не только в нашем.

Ответить
fedot

Ясно, спасибо.

Ответить
Дмитрий

Подожду код )

Ответить
Arunas

хорошая инфраструктура сайта - как фундамент дома, где он живет....

Ответить
Александр

Спасибо, очень интересные уроки ! Хотелось бы еще kubernetes.

Ответить
Ivan

да, нужен еще в кубере деплой!

Ответить
fedot

спасибо

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий