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

Реализация 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 - Сравнение инструментов
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (23)
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

спасибо

Ответить
Михаил

Дмитрий, а как же быть с базой данных? Вы сказали, что она не часто меняется, но что делать, если происходят какие-либо миграции, в которых текущая структура БД изменяется? Получается, что репликация БД не поможет, так как за время развертки в текущую базу уже могли записаться новые данные и они, соответственно, не попадут в новую сборку. Как обычно решают такую проблему?

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

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

Ответить
Михаил

А если изменения затрагивают текущую структуру? Например, происходит какой-то рефакторинг, данные сначала лежали в одной таблице, а мы переносим их в связующую таблицу. В этом случае навряд ли подучится сделать обратную совместимость.. Или, банально, хотим переименовать колонку. В процессе сборки образа могут быть записаны новые данные в эту колонку.

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

Или, банально, хотим переименовать колонку.

Все такие операции делают многошаговыми. Совместимость реализуют триггерами:

  1. Первой миграцией добавляем новую колонку и триггер, дублирующий туда значения из старой.
  2. Деплоим код. Старые инстансы пишут в старую колонку, новые инстансы в новую.
  3. Второй миграцией удаляем триггер и старую колонку.
Ответить
Тимофей

Дмитрий, спасибо за материал. Возник такой вопрос: Допустим в стеке для фронта используется js с серверным рендерингом и кешированием (например next js) он под капотом кэширует запросы или, например, автоматически оптимизирует картинки и складывает их в свою внутреннюю папку. Как в случае оркестрации ведет себя js при запросе картинки (на каждом из хостов делается своя копия в зависимости от того кто сейчас обрабатывает запрос?)

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

Или войти через:

Google
GitHub
Yandex
MailRu