В нашем блоге мы много пишем о развитии облачного сервиса 1cloud и перспективных технологиях, вроде Docker. Контейнеры за последний год стали настоящим хитом, однако такая популярность имеет и обратную сторону. Инженер Ник Барретт (Nick Barret) в своем задался вопросом, почему сейчас контейнеры Docker начинают использовать даже для решения не подходщяих для этого инструмента задач?

Баррет говорит, что обожает Docker. По собственному признанию инженера, он потратил много времени, чтобы освоить Docker и Kubernetes. В сочетании со stateless-контейнерами они обеспечивают фантастическую масштабируемость, сервисное раскрытие и почти мгновенное развертывание приложений (кроме создания первичного образа).

Но сегодня контейнеры Docker используют для всего подряд, и, по словам Барретта, это приводит его в замешательство.

Для иллюстрации этого инженер предлагает рассмотреть ситуацию с запуском хранилища образов (Docker Registry) на Docker (v2). Здесь он собирается:

• запустить единичный инстанс с Go binary;
• при этом сохранив место на диске пропускную способность;
• и относительно низкие затраты CPU/памятью.

Такая конфигурация не нужна в кластере Kubernetes, кроме того тут не требуются возможности по масштабированию, которые дает Docker. Значит все это можно запустить сразу на «железе».

Беда в том, что в параметрах установки не найти информации о том, как это можно сделать. По сути, «официальный» путь – использовать образ Docker. По счастью, есть простой скрипт Dockerfile, так что решить проблему можно, воспользовавшись им (путь docker/distribution -> Registry Image -> Dockerfile).

Существуют и другие варианты работы вне Docker. Речь о datastores (временных хранилищах). Допустим, необходимо запустить кластер Elasticsearch или Galera. Docker-контейнеры предложат быструю установку, что выглядит довольно заманчиво.

Но не нужно торопиться. Как можно конфигурировать эти сервисы для работы с различными средами (test/prod кластеры)? Они не могут использовать переменные ENV и ничего не знают об использующихся инструментах раскрытия внутреннего сервиса. Эти типы систем имеют собственные конфигурационные файлы — elasticsearch.yml или my.cnf. В этом и ему подобных случаях формат Dockerfile до ужаса бесполезен, говорит Барретт.

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

Ведь можно использовать легкодоступные инстансы Elasticsearch/Galera/и т.д., что намного полезнее на стадии разработки продукта. Возможность мгновенно запустить единичный Elasticsearch-инстанс, привязанный к определенной ветке приложений, сэкономит массу времени. Это однозначно лучший способ развертывания stateless-приложений, из когда либо созданных. Поэтому Баррет советует «просто не заморачиваться» с созданием кластеров или комплексного постороннего софта с помощью контейнеров Docker.

Автор:

Источник