Erlang/Elixir на Docker и Hot Code Swap

Одна из особенностей Erlang (и, по определению, Elixir) заключается в том, что вы можете делать своп-код. Однако это кажется странным с Docker, где вам нужно будет остановить свои экземпляры и перезапустить новые с новыми изображениями, содержащими новый код. По сути, это похоже на то, что делают все.

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

Мой вопрос будет следующий: кто-нибудь попытался и достиг с разумным успехом создать инфраструктуру Docker для Erlang/Elixir, которая позволила бы сменять Hot-code? Если да, то что делать, не нужно и оговорки?

Ответ 1

История

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

Теперь есть еще одна система, которая вычисляет, сколько нужно заряжать пользователя для вызова или переданных данных (назовите его PDF - Функция принятия решений по политикам). Обе системы подключены таким образом, что сервер шлюза создает несколько TCP-соединений в PDF, и он отключает сеансы пользователей, если эти соединения TCP снижаются. Шлюз может обрабатывать несколько сотен тысяч клиентов одновременно. Всякий раз, когда происходит событие, за которое пользователю необходимо платить (следующая передача данных, другая минута вызова), шлюз уведомляет PDF об этом факте, и PDF вычитает определенную сумму денег из учетной записи пользователя. Когда учетная запись пользователя пуста, PDF уведомляет шлюз о отключении вызова (у вас закончились деньги, вам нужно пополнить).

Ваш вопрос

Наконец, поговорим о вашем вопросе в этом контексте. Мы хотим обновить PDF node, а node работает на Docker. Мы создаем новый экземпляр Docker с новой версией программного обеспечения, но мы не можем закрыть старую версию (в середине их звонка есть сотни тысяч клиентов, мы не можем их отключить). Но нам нужно как-то переместить клиентов из старого PDF в новую версию. Поэтому мы сообщаем шлюзу node для создания любых новых соединений с обновленным node вместо старого PDF. Клиенты могут быть частыми, а некоторые из них могут иметь длительные соединения с данными (загрузка Windows 10 iso), поэтому для завершения всей операции требуется 2-3 дня. Это может потребоваться для обновления одной версии программного обеспечения до другой в случае критической ошибки. И могут быть десятки таких серверов, каждый из которых обрабатывает сотни тысяч клиентов.

Но что, если вместо этого мы использовали обработчик релиза Erlang? Мы создаем файл relup с новой версией программного обеспечения. Мы тестируем его правильно и развертываем в PDF-узлах. Каждый node обновляется на месте - внутреннее состояние приложения преобразуется, node запускает новую версию программного обеспечения. Но самое главное, TCP-соединение с сервером шлюза не было удалено. Таким образом, клиенты счастливо продолжают свои звонки или загружают последнюю версию Windows, пока мы обновляем систему. Все делается за 10 секунд, а не через 2-3 дня.

Ответ

Это пример конкретной системы с особыми требованиями. Docker и Erlang Release Handling являются ортогональными технологиями. Вы можете использовать один или оба, все это сводится к следующему:

Требования
Стоимость

Будет ли у вас достаточно ресурсов для тестирования обоих подходов предсказуемо и достаточно терпения, чтобы научить вашу команду Ops, чтобы они могли развернуть систему с помощью любого из этих методов? Что, если испытательный центр стоит миллионы фунтов (из-за необходимого оборудования) и может использовать только один из этих двух методов за один раз (потому что цикл тестирования занимает несколько дней)?

Прагматичный подход может состоять в том, чтобы сначала внедрить узлы с помощью Docker, а затем обновить их с помощью обработчика выпуска Erlang (если вам нужно использовать Docker в первую очередь). Или, если ваша система не должна быть доступна во время обновления (как это делает система в формате PDF), вы можете просто выбрать всегда развертывание новых версий с помощью Docker и забыть об обработке выпуска. Или вы также можете использовать обработчик релиза и забыть о Docker, если вам нужны быстрые и надежные обновления на лету, а Docker будет использоваться только для первоначального развертывания. Надеюсь, что это поможет.