Перевод статьи «7 Cases When You Should Not Use Docker».
Docker это потрясающая вещь, но это решение не на все случаи жизни.
У Docker много достоинств. Этот легковесный, портируемый и самодостаточный инструмент контейнеризации. Он отлично подходит для бизнеса любого размера.
Когда вы работаете над кодом в маленькой команде, благодаря Docker вы избавлены от проблемы «а на моей машине это работает». Но корпорации тоже могут использовать Docker для создания конвейеров производства программ по методике Agile, чтобы выпускать новый функционал быстрее и безопаснее.
Благодаря своей встроенной системе контейнеризации Docker является отличным инструментом для облачных вычислений. Docker Swarm, в свою очередь, развивает кластеризацию и децентрализованный дизайн.
Звучит слишком хорошо, чтобы быть правдой, верно? Ну, все-таки есть несколько случаев, когда использовать Docker не стоит. Мы рассмотрим семь из них.
1. Не используйте Docker, если вам нужно увеличить скорость работы вашего приложения
Контейнеры Docker занимают меньше места и требуют меньше ресурсов, чем виртуальная машина с сервером и базой данных. В то же время Docker будет использовать столько системных ресурсов, сколько ему позволит планировщик ядра хоста. В любом случае, не стоит рассчитывать на то, что Docker ускорит работу вашего приложения.
Больше того, Docker даже может ее замедлить. Работая с ним, следует устанавливать для контейнеров лимиты использования памяти, CPU или блока ввода-вывода. В противном случае, если ядро обнаружит, что память машины-хоста слишком загружена для выполнения важных системных функций, оно может начать убивать важные процессы. А если будут убиты не те процессы (включая сам Docker), система станет нестабильной.
К сожалению, улучшения Docker, касающиеся памяти — приоритет out-of-memory демона Docker — не решают эту проблему. Напротив, добавление еще одного уровня между приложением и операционной системой также может привести к снижению скорости. Впрочем, это снижение будет незначительным. Контейнеры Docker не полностью изолированы и не содержат полной операционной системы, как и любая виртуальная машина.
2. Не используйте Docker, если ваш приоритет — безопасность
Самое большое преимущество Docker по части безопасности состоит в том, что он разбивает приложение на меньшие части. Если безопасность одной части будет скомпрометирована, на остальные это не повлияет.
Но несмотря на то, что изолированность процессов в контейнерах повышает безопасность, все эти контейнеры имеют доступ к одной операционной системе хоста. Есть риск запустить контейнеры Docker с неполной изолированностью. Какой-нибудь вредоносный код может получить доступ к памяти вашего компьютера.
Запуск множества контейнеров в одной среде это довольно популярная практика. И таким образом, если вы не ограничиваете ресурсы, доступные контейнеру, вы делаете ваше приложение уязвимым для атак типа Resource Abuse («злоупотребление ресурсами»). Для максимальной эффективности и изолированности каждый контейнер должен быть предназначен для решения какой-то одной конкретной задачи.
Еще одна проблема дефолтной конфигурации Docker — пользователи не имеют пространства имен. Пространство имен позволяет программным ресурсам использовать другие ресурсы, только если они принадлежат к определенному пространству имен.
Запуск приложений с помощью Docker подразумевает запуск демона Docker с привилегиями root. Любые процессы, исходящие из контейнера Docker, будут иметь те же привилегии на хосте, что и в контейнере. Запуск ваших процессов внутри контейнеров от имени непривилегированного пользователя не может гарантировать безопасность. Имеют значение возможности, которые вы добавляете или удаляете. Чтобы снизить риск пробоя контейнера Docker, не следует загружать готовые к использованию контейнеры из ненадежных источников.
3. Не используйте Docker, если вы создаете десктопное приложение с графическим пользовательским интерфейсом
Docker не подходит для приложений, предполагающих наличие полнофункционального UI. Он главным образом нацелен на изолированные контейнеры с консольными приложениями. Программы с графическим интерфейсом не в приоритете, их поддержка может варьироваться в зависимости от каждого конкретного случая и приложения. В Windows в качестве операционной системы контейнеров используются Nano Server или Core Server — это не позволяет пользователям запускать GUI-интерфейс или Docker RDP сервер в контейнере Docker.
Тем не менее, вы можете запускать графические приложения, разработанные на Python и при помощи QT-фреймворка в контейнере Linux. Также можно использовать перенаправление X11, но это не совсем изящное решение.
4. Не используйте Docker, если вам нужно упростить разработку и отладку
Docker был создан разработчиками и для разработчиков. Он обеспечивает стабильность среды: контейнер будет работать в стейджинге, продакшене или в любой другой среде точно так же, как на компьютере разработчика. Это устраняет проблему различных версий программ в разных средах.
С Docker вы можете легко добавить новую зависимость в ваше приложение. Причем никому из вашей команды не придется повторять эти манипуляции на своем компьютере. В контейнере все будет в рабочем состоянии и в таком виде будет распределено по всей команде.
В то же время, чтобы вести разработку приложения в Docker, следует дополнительно продумать и настроить рабочие процессы. Кроме того, для дебаггинга в Docker нужно настроить вывод логов и порты для отладки. Может также понадобиться назначить порты для ваших приложений и сервисов в контейнерах.
В общем, если у вас сложная и трудоемкая процедура деплоймента, Docker вам существенно поможет. А если у вас простое приложение, он только все усложнит.
5. Не используйте Docker, если вам нужно использовать другую операционную систему или другое ядро
В случае с виртуальными машинами гипервизор может абстрагировать устройство целиком. При помощи Microsoft Azure можно запустить Windows Server и Linux Server одновременно. А вот для образа Docker необходима та же операционная система, для которой он был создан.
Существует обширная база образов контейнеров Docker — Docker Hub. Но если какой-то отдельно взятый образ был создан на Linux Ubuntu, его можно будет запустить только на точно такой же Ubuntu.
Если приложение разрабатывается на Windows, но продакшен запускается на Linux, использование Docker в этом случае будет неэффективным. Порой, если у вас несколько статичных приложений, проще поднять сервер.
6. Не используйте Docker, если вам нужно хранить много ценных данных
Все файлы Docker создаются внутри контейнера и хранятся на слое, доступном для записи. Если каким-то процессам нужны будут данные из контейнера, могут возникнуть трудности с их получением. Кроме того, слой контейнера, доступный для записи, связан с хостом, где запущен контейнер. Если у вас возникнет необходимость перенести данные куда-то еще, это нелегко будет сделать. Более того: при прекращении работы контейнера будут навсегда потеряны все данные, хранящиеся внутри него.
Нужно наперед продумывать способы сохранения данных где-то еще. Для обеспечения безопасности данных в Docker используется дополнительный инструмент — Docker Data Volumes. Но это решение тоже довольно топорное и нуждается в улучшении.
7. Не используйте Docker, если ищете технологию, управлять которой будет проще всего
Docker был представлен широкой публике в 2012 году, но все еще является новой технологией. Вам как разработчику может потребоваться регулярно обновлять версии Docker. К сожалению, обратная совместимость при этом не гарантирована, да и развитие документации отстает от развития самой технологии. Разработчику придется во многом разбираться самостоятельно.
Опции мониторинга, предлагаемые Docker, довольно скудны. Вы можете получить какие-то сведения типа самой простой статистики, но если вам нужен более продвинутый функционал мониторинга, Docker-у нечего вам предложить.
В случае с крупными и сложными приложениями имплементация Docker обходится дорого. Создание и поддержка коммуникации между многочисленными контейнерами на многочисленных серверах потребует много времени и сил. Есть, конечно, инструмент, облегчающий работу с многоконтейнерными приложениями Docker, — Docker Compose. Он определяет сервисы, сети и разделы в одном YAML-файле.
Экосистема Docker не отличается цельностью: не все продукты для поддержки контейнеров хорошо работают друг с другом. За всеми продуктами стоят разные компании и сообщества. Конкуренция между ними приводит к несовместимости продуктов.
Заключение
Несмотря на некоторые оговорки, Docker это отличный инструмент для запуска приложений в изолированных контейнерах и управления ими.
Установка приложения проста и осуществляется при помощи всего одной команды — <docker run>. Также Docker предоставляет чистую и оригинальную среду изоляции для каждого теста, что делает его важным и полезным инструментом для автоматического тестирования.
Благодаря функционалу Docker вы получаете существенные преимущества по части безопасности и управления зависимостями. А дополнение этого функционала такими полезными инструментами как Docker Hub, Docker Swarm и Docker Compose делает Docker популярным и дружественным к пользователю решением.
Но несмотря на все преимущества, которые дает Docker, не стоит использовать его для контейнеризации буквально всех приложений, которые вы разрабатываете. Это не волшебная палочка.
Также не стоит забывать, что Docker — не единственный подобный инструмент на рынке. Есть и альтернативы: rkt (произносится как «рокет»), Linux Containers, OpenVZ. Все они имеют свои достоинства и недостатки и все они похожи на Docker. Особая популярность последнего связана только с решением бизнеса использовать именно его.
Прежде чем решиться использовать или не использовать Docker, изучите требования проекта и обсудите этот вопрос с коллегами.
У этой технологии определенно есть будущее, независимо от того, нравится она вам или нет. Есть разработчики и компании, просто ненавидящие Docker и пытающиеся удалить его из всех своих проектов. В то же время, есть специалисты, считающие Docker панацеей от всех бед и заключающие в контейнеры все, что только можно. Вероятно, не стоит присоединяться к какому-то из этих двух лагерей. Оставайтесь объективными и принимайте решение в зависимости от каждой отдельной ситуации.
Специально посмотрел на год статьи и не поверил, что она от 2019 года. Ощущение, будто 2013 год.
2. Докер безопасен. Он основан на cgroups, цель которых является полностью изолировать, а следовательно, обезопасить процессы от основного хоста. То, что docker запущен от root ничего не значит. Cgroups не дадут совершить то, чего админ не предусмотрел. Чтобы выйти за пределы докера, нужно его настроить сверхкриво. А учитывая, что настройка докера — это процесс нескольких секунд, даже не минут, то чтобы докер представлял собой опасность нужно иметь и кривые руки, и целеустремлённость.
4. Да именно только докер и используют чтобы развернуть себе окружение разработчика. Особенно, если проект на микросервисах, у каждого из которых разное окружение. Без докера пришлось бы каждому разрабу покупать по отдельному компу в самых запущенных случаях.
5. Про то, что докер давно интегрирован в Windows и на MacOs, автор походу не знал. Ну бывает. Ну а уж не знать, что можно запустить образ CentOs на Ubuntu, это не знать docker совсем.
6. Ценные данные можно хранить на подключаемых томах. Естетсвенно, что внутри контейнера хранить ничего нельзя.
7. Докер — это уже не новая технология. Это уже старая технология. И довольно хорошо проверенная. А помимо docker-compose есть ещё docker swarm. И настройка этих оркестраторов — очень простая задача даже для новичка.
1) Докер-небезопасен. то что пишут наверху про cgroups-чушь от человека, явно далекого от безопасности. А принцип безопасности таков-чем больше кода, прослоек и сущностей, тем меньше безопасности. Это аксиома. Сами cgroups хоть и предлагают с одной стороны относительно удобные и отчасти безопасности, но с другой стороны, даже уменьшают ее степень. cgroups и docker сами по себе не застрахованы от уязвимостей.
2) Докер-не подходит для больших приложений со сложной архитектурой и структурой.
3) Докер-это лишняя зависимость от чужого решения и кода
4) Докер-это навязанное через некую «моду» иностранными спецслужбами решение, именно по вышеперечисленным причинам
5) Перечислять еще можно много.
КГ \ АМ