Случаи, когда контейнеры не помогают — CloudSavvy IT

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

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

Когда производительность имеет решающее значение

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

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

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

Много постоянных данных

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

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

Данные, хранящиеся в томах, могут быть сложными в управлении и обслуживании. Вам нужно использовать команды Docker для взаимодействия с вашими томами. Проверку данных лучше всего выполнять, подключая оболочку к контейнеру и перечисляя содержимое тома изнутри.

Docker требует от вас подумать о хранилище и выбрать собственную стратегию сохранения. Это отход от установки виртуальных машин и пакетов ОС, где вы можете безопасно хранить данные в любом каталоге, не беспокоясь о том, как вы будете управлять ими позже.

Docker наиболее удобен, когда вы создаете долгоживущие сервисы с зависимостями, которые вы не хотите устанавливать в каждой среде. Типичным примером может быть веб-приложение PHP, работающее за веб-сервером NGINX: есть несколько компонентов, включая фоновый сервер, который вы хотите запустить с помощью одной команды.

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

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

Однако это, как правило, усложняет дисциплины, которыми управляют IDE, такие как Android Studio, Visual Studio и Xcode. Разработчики привыкли устанавливать IDE и позволять ей настраивать свою среду. Следовательно, Docker имеет тенденцию добавлять меньше ценности к рабочим процессам на скомпилированном языке, чем для интерпретируемых языков, где правильная версия интерпретатора может быть встроена в образ.

Безопасность превыше всего

Докер может повысьте безопасность вашего стека, но для правильной защиты вашей установки требуется работа. Ошибка, которую допускают слишком часто, состоит в том, что предполагается, что Docker защищен из коробки. Скажем прямо: это не так.

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

Слишком легко услышать заявление об «изолированных приложениях» и предположить, что это распространяется на безопасность на уровне «песочницы». На самом деле стандартная установка Docker запускает процессы контейнера от имени пользователя root, и взлом контейнера может поставить под угрозу ваш хост.

Безопасность Docker — это многогранная тема, требующая рассмотрения среды хоста, демона Docker и того, как вы создаете и поддерживаете свои образы. Разработчики тоже должны сыграть свою роль, сводя к минимуму рискованные операции в коде, который выполняется внутри контейнеров.

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

Ваша кодовая база — это монолит

Вы, наверное, читали, что контейнеры идут рука об руку с микросервисами. Этот менталитет описывает процесс разделения вашей системы на независимые компоненты, которые можно легко поместить в контейнер. После того, как вы разделили свои службы, их можно масштабировать по отдельности, и вы можете заменять части, не затрагивая другие.

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

Однако, как обычно, у этой медали есть две стороны: контейнеризация монолита часто является первым шагом к модернизации вашего стека и разбиению его на более мелкие сервисы. Это точка, в которой вы отделяете кодовую базу от среды, к которой она привязана.

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

Вы пытаетесь сократить сложность

Пытаетесь сократить сложность? Думаете, что контейнеризация упростит разработку и развертывание? Опять же, это момент «это зависит», но мы бы предостерегли от того, чтобы прыгать на подножку Docker с простотой в качестве вашей основной мотивации.

Docker требует изменения мышления и ознакомления с новыми инструментами и концепциями. Будет ли это удобно вашим разработчикам и как это повлияет на ваши процессы найма? Это вопросы, которые можно легко упустить из виду, но их следует рассмотреть на раннем этапе.

Хотя Docker устраняет многие формы сложности, он имеет тенденцию появляться в разных формах. Вам нужно будет писать, документировать, поддерживать и создавать образы Docker либо локально на компьютерах разработчиков, либо как часть конвейера непрерывной интеграции. Разработчикам необходимо будет изучить интерфейс командной строки Docker, основы того, что такое контейнеры, и потенциальные проблемы, о которых следует помнить при подготовке приложений к контейнеризации.

Если вы планируете запускать контейнеры в производственной среде, у вас также будут дополнительные соображения. Как сетевой трафик будет направляться в контейнеры? Как система отреагирует, если контейнер неожиданно остановится?

Сторонники менталитета «Докер — это просто», как правило, сосредоточены на простоте, с которой вы можете наивно запускать экземпляры образов, которые у вас уже есть. Это правда, что если вы хотите новую базу данных MySQL на своем ноутбуке, это просто docker run -d mysql:8. Тем не менее, вам предстоит узнать гораздо больше, если вы хотите успешно использовать Docker для создания и запуска собственного программного обеспечения, соблюдая при этом передовой опыт и избегая распространенных ошибок.

Вы не уверены, зачем вам контейнеризация

Контейнеры повсюду; вы не можете прочитать больше, чем несколько статей о разработке программного обеспечения, не наткнувшись на них, и сторонники активны и полны энтузиазма. Этот популярный призыв может создать давление, чтобы принять в качестве Docker «современный» инструмент, который другие сочли полезным.

Это не веская причина для контейнеризации. Вам нужна более конкретная цель, например, «разработчики должны иметь возможность точно воспроизводить продукцию локально» или «мы должны иметь возможность горизонтально масштабировать реплики наших сервисов». Если вы не чувствуете точного варианта использования Docker и довольны своим текущим рабочим процессом, лучшим вариантом может быть придерживаться того, что работает. Это может показаться скучным выбором, но Docker не является безупречной трансформирующей силой, и успешное внедрение не гарантируется.

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

Вывод

Docker — заслуженно популярная технология: для многих команд и разработчиков она предлагает идеальный баланс простоты использования, гибкости и производительности, что позволяет упростить реальные процессы разработки. Однако Docker не волшебство: есть случаи, когда он не может работать, и многие другие, когда он не будет работать, в зависимости от ваших существующих технологий, процессов и мышления.

Даже если Docker сегодня не очень подходит для ваших проектов, вы все равно сможете получить некоторые преимущества, внедряя его постепенно. Определите, какие проблемы возникают в ваших процессах, а затем оцените, может ли Docker помочь в этих конкретных областях. Например, если разработчики тратят слишком много времени на развертывание промежуточных экземпляров вашего API, Dockering этой части вашего стека может устранить узкое место, даже если вы не можете запускать контейнеры в рабочей среде.

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