У меня на канале выходит много заметок с использованием Docker. Хочу высказать своё мнение по поводу его использования. Где-то считаю его уместным, а где-то не очень. Расскажу, как к этому отношусь.

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

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

Возьмём к примеру сервер мониторинга Zabbix. Он что через Docker контейнер ставится в пару действий, что через пакетный менеджер. То есть использование контейнера не упрощает установку, поэтому я не вижу смысла его ставить в прод через Docker. Он ставится и обновляется в одно действие:

# apt install zabbix-server-mysql
# apt update zabbix-server-mysql

И через Docker:

# docker run --name zabbix-server-mysql -e DB_SERVER_HOST="some-mysql-server" -e MYSQL_USER="some-user" -e MYSQL_PASSWORD="some-password" --init -d zabbix/zabbix-server-mysql:tag

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

То же самое относится к Nginx, Angie, Mysql, Php-fpm, Prometheus и т.д. То, что по сути состоит из пакета или бинарника и файла конфигурации к нему не вижу смысла запускать в постоянную эксплуатацию в контейнере. Если у разработчиков есть собранные пакеты, то буду использовать их.

Другое дело более сложный в плане установки софт, для которого пакетов нет. Тогда вручную его собирать, устанавливать, обновлять и поддерживать может быть очень хлопотно. Наглядные примеры, с которыми сталкивался сам - Onlyoffice, Webpagetest. У первого хоть и есть пакеты, но с ними много проблем с зависимостями. Часто нельзя обновиться без ошибок. У второго вообще пакетов нет, его ставить вручную – пуд соли съесть. Причём я ставил, вопрос решаемый, но очень трудоёмкий. Не хочется этим заниматься.

❗️Отдельно выделю софт, который может быть полностью сконфигурирован через переменные окружения при запуске контейнера и не требует подключения файлов конфигурации. Тут без вопросов, запустить в одну команду с ключами проще, чем ставить и отдельно готовить файл конфигурации. Пример - Traefik. У него доступно динамическое управление конфигурацией через переменные. Это удобно.

☝️ Подвожу итог. Всё, что не касается микросервисов, я запускаю в Docker только если установка из пакетов невозможна, либо слишком трудоёмка. Продукты, для которых у разработчиков есть репозитории под Debian, будут установлены из репозиториев. Речь идёт именно о промышленной эксплуатации, а не тестовых запусках.

Если речь идёт о связке нескольких продуктов в единое целое, то тоже буду смотреть на сложность установки и обновления. Если связку можно поставить по отдельности и потом через apt upgrade обновлять, то скорее всего соберу из пакетов. Если нужны будут дополнительные действия после обновления пакетов, то скорее всего буду использовать предоставленный docker compose.

А вы что думаете по этому поводу? Знаю популярное мнение, что абсолютно всё запускается в Docker из-за стандартизации и единообразия. Как по мне, это сомнительный аргумент, так как единая система и общий репозиторий к ней это такая же стандартизация.

#docker #мнение