Думку інженера: Чому не потрібно завжди і скрізь використовувати Docker



У нашому блозі ми багато пишемо про розвиток хмарного сервісу 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.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.