Где лежат пределы уместности Docker. Продолжение
В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.
Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.
Это избавляет нас от проблем взаимозависимостей элементов стека и обеспечивает стабильную повторяемость результата при разных внешних условиях.
Если мы хотим обновить или заменить какой-то элемент стека – мы заменяем только один контейнер и не трогаем остальные, риски того, что обновление поломает весь стек – минимальны.
При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.
Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.
Это свойство одно из ключевых для технологии непрерывного развертывания. Когда ПО в продуктивной среде автоматически обновляется без крупных перерывов в обслуживании.
Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.
Но у всего должны быть разумные пределы и у Docker тоже, потому что в последнее время прослеживаются тенденции упаковывать в контейнеры все что нужно и все что не нужно, включая одиночные бинарники.
Следует понимать, что при всех своих плюсах Docker – это сложное ПО, еще один слой абстракции и еще одна точка отказа или человеческой ошибки.
Кроме того, Docker, как и любая технология, требует набора базовых знаний, иначе compose-файл будет для вас китайской грамоты, а первый же сбой заставит бегать по потолку.
Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.
Также достаточно сомнительна необходимость Docker для ПО, которое собирается и сопровождается под конкретную версию дистрибутива на всем протяжении его жизненного цикла.
В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.
Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.
Другое дело внешние приложения, тот же Wordpress, который мы получаем непосредственно от разработчика, и разработчик выставляет системные требования. Решил поднять версию PHP – садитесь и думайте, как жить дальше, скорее всего придется пересобирать весь стек.
Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.
Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.
А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.
И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.
