Стоят ли контейнеры головной боли?

Контейнеры — это концепция Unix, которая позволяет упаковывать приложения со всеми необходимыми зависимостями в один простой в использовании образ. Это имеет весомые преимущества для рабочего процесса DevOps, но стоит ли оно дополнительных хлопот?

Контейнеры синхронизируют среды разработки и производства

С контейнерами вся идея заключается в том, что они упаковывают все, что вам нужно для запуска вашего кода, в легко распространяемый образ. Это означает, что все, что требуется для запуска образа, — это загрузить его и запустить docker run.

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

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

Контейнеры обеспечивают эффективное масштабирование

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

У AWS есть свой Elastic Container Service, который управляет запуском ваших контейнеров в группе инстансов EC2 или в собственном сервисе Fargate. Kubernetes имеет открытый исходный код, и многие облачные провайдеры предоставляют с его помощью интеграцию.

Каждая служба оркестровки сможет отслеживать работоспособность ваших экземпляров и запускать новые при высоком трафике. Это обеспечивает эффективное масштабирование, которое может значительно сэкономить на расходах на хостинг (до 90 % на AWS с автоматическим масштабированием и спотовыми инстансами), а также означает, что вам не нужно слишком беспокоиться о том, что ваша инфраструктура перерастет.

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

И все это возможно благодаря природе контейнеров, без дополнительной работы. Вы можете делать то же самое на AWS, используя пользовательские образы AMI, но ими гораздо сложнее управлять, чем контейнерами, и вы все равно будете выполнять большую часть той же работы.

Управление версиями контейнеров Ваш системный администратор

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

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

Кроме того, Docker хорошо работает с системами непрерывной интеграции. Сборки Docker легко автоматизировать, особенно если вы используете Azure Pipelines. Загрузить образ Docker на ваш парк серверов так же просто, как обновить образ в репозитории. Вы даже можете развернуть новый контейнер на подмножестве серверов, чтобы отслеживать его работоспособность, прежде чем развертывать его на всем парке, что было бы нетривиально реализовать без контейнеров.

Недостаток: головная боль реальна

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

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

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

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