В нашем блоге мы много пишем о развитии облачного сервиса 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 кластеры)? Они не читают ENVvars, и ничего не знают об использующихся инструментах раскрытия внутреннего сервиса. Эти типы систем имеют собственные конфиги, они могут быть elasticsearch.yml или my.cnf. В этом и ему подобных случаях Dockerfile до ужаса бесполезен, говорит Барретт.
Инженер уверен, что самым распространенным решением является простая установка других утилит внутри образа, которые бы загружали конфигурацию перед запуском сервиса. И по его мнению, это надругательство над самой идеей существования контейнеров без неспециализированного софта. Инструменты, наподобие pyinfra и Ansible для такой работы куда более удобны (они не устанавливают ненужный хлам, чтобы сгенерировать конфиг).
Ведь можно использовать легкодоступные инстансы Elasticsearch/Galera/и т.д., что намного полезнее на стадии разработки продукта. Возможность мгновенно запустить единичный Elasticsearch-инстанс, привязанный к определенной ветке приложений, сэкономит массу времени. Это однозначно лучший способ развертывания stateless-приложений, из когда либо созданных. Поэтому Баррет советует «просто не заморачиваться» с созданием кластеров или комплексного постороннего софта с помощью контейнеров Docker.
Автор: 1cloud.ru
