Бесшовный деплой и оркестрация
Реализация 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
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Очень спасибо.
Супер!
А как сделать бесшовный prod deploy на несколько сайтов: напр. сегодня на example1.com, завтра на example2.com? Можно ли как то проще собрать env по этому вопросу?
Да, можно переделать gateway так, чтобы имя домена передавать через переменную окружения. Например, в нём подменить ENTRYPOINT на скрипт, который будет подставлять значения переменных окружения в шаблон conf-файла через команды
sedилиenvsubst.спасибо.
https://github.com/jwilder/dockerize
Когдаж код пойдет. Курс по девопсу какой-то )
Это серия про все аспекты разработки проекта, а не только про код.
Дмитрий, а а как быть если в момент пересборки контейнера на проде есть сессия пользователя? ведь в момент переключения контейнера он потеряет данные. Можно ли как то сохранять существующие подключения? или ждать их завершения не давая создавать новые или еще как то?
Процессам nginx и php-fpm от Docker передаётся стандартный сигнал завершения программы и они останавливаются по своей логике. Если кто-то не остановился, то через некоторое время процесс уже принудительно убивается через kill.
Если же есть постоянное WebSocket-соединение, то оно отключится. Просто нужно написать JavaScript-код так, чтобы он переподключался при разрывах.
Спасибо, за ответ, а есть ли возможность подать сигнал завершения таким образом, что что бы апач и нгинкс ждали конца текущей сессий не открывая новую пока не произойдет рестарт? Я не смог найти что-то, такое умное завершение было бы на порядок надежнее, загромождения логики лишними проверками, а при таком подходе как у нас, обрывы могут быть частыми, а в некоторых случаях потеря данных пользователя при неоконченном вводе недопустима, неужели никто ничего не придумал?
Так то понятно, что если обновлять склад при каждом изменении поля, то информация не должна пропасть, так как данные будут в браузере, но все равно как то стремно.
Сам оркестратор перестаёт направлять запросы на останавливающийся контейнер. Так что новые запросы в него и так не попадут.
Ввод обычно отправляется не постепенно, а целиковым Ajax-запросом, который либо совершится, либо вылетит с ошибкой валидации, сервера или соединения. Тогда можно на фронтенде вывести сообщение "Попробуйте снова" или через setTimeout попробовать отправить повторно самому.
Если имеется в виду многошаговый ввод, то промежуточные данные нужно сохранять в БД или Redis с привязкой к идентификатору посетителя, а не в файлах сессии в самом PHP-контейнере.
Если же где-то и ввод осуществляется через WebSocket, то нужно делать обработку обрывов в любом случае, а не только в нашем.
Ясно, спасибо.
Подожду код )
хорошая инфраструктура сайта - как фундамент дома, где он живет....
Спасибо, очень интересные уроки ! Хотелось бы еще kubernetes.
да, нужен еще в кубере деплой!
спасибо
Дмитрий, а как же быть с базой данных? Вы сказали, что она не часто меняется, но что делать, если происходят какие-либо миграции, в которых текущая структура БД изменяется? Получается, что репликация БД не поможет, так как за время развертки в текущую базу уже могли записаться новые данные и они, соответственно, не попадут в новую сборку. Как обычно решают такую проблему?
Обычно чтобы не было проблем расхождений кода и схемы делают обратно-совместимые миграции. То есть сначала пишут и деплоят миграцию, добавляющую колонку, а потом уже через некоторое время деплоят новый код, пишущий в эту колонку.
А если изменения затрагивают текущую структуру? Например, происходит какой-то рефакторинг, данные сначала лежали в одной таблице, а мы переносим их в связующую таблицу. В этом случае навряд ли подучится сделать обратную совместимость.. Или, банально, хотим переименовать колонку. В процессе сборки образа могут быть записаны новые данные в эту колонку.
Все такие операции делают многошаговыми. Совместимость реализуют триггерами:
Дмитрий, спасибо за материал. Возник такой вопрос: Допустим в стеке для фронта используется js с серверным рендерингом и кешированием (например next js) он под капотом кэширует запросы или, например, автоматически оптимизирует картинки и складывает их в свою внутреннюю папку. Как в случае оркестрации ведет себя js при запросе картинки (на каждом из хостов делается своя копия в зависимости от того кто сейчас обрабатывает запрос?)
Если ничего не предпринимать, то у каждого инстанса будет свой кэш и своя внутренняя папка для файлов. Если для файлов использовать volume в Docker Swarm, то на каждой виртуальной машине будет свой том.
Чтобы всё было общим нужно кэш складывать в общий отдельный сервис вроде Memcache или Redis. А картинки либо также сохранять в отдельный файловый сервис вроде S3-хранилища, либо делать общий volume с помощью сетевой синхронизуемой файловой системы, как это порой делают в Kubernetes.
Или войти через: