Хабрахабр

[Из песочницы] Не переусложняйте ваш CI/CD и пользуйтесь Docker’ом осмысленно

Я работал в разных компаниях, которые используют микросервисы. И они запускали их в docker контейнерах. Сейчас я работаю с проектом, который хоть и монолит, но его все равно удобнее запустить в контейнере.

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

  1. Делается git push с нашим коммитом
  2. Триггерится какая-то система, будь то Jenkins, TeamCity и т.п.
  3. Запускается пайплайн/job, в котором происходит скачивание сторонних библиотек, компиляция проекта, прогон тестов
  4. Создается docker образ с собранным проектом (ADD. .) и пушится в удаленный docker registry
  5. Каким-нибудь образом на удаленном сервере делается git pull (chef, puppet, вручную через docker-compose) и запускается контейнер.

Интуитивно я всегда чувствовал, что это все как-то чересчур сложно. Этот процесс гордо называют CI/CD и я уже устал от таких умников, которые ничуть не сомневаются в том, что это самый простой путь.

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

Что мне НЕ нравится в этом подходе.

  1. Единственный способ развернуть систему на удаленном сервере — это пройти через все 5 шагов.
  2. В шаге 3 могут понадобиться ключи доступа к приватным библиотекам. Процесс может быть долгим, если не настроено кеширование ранее скачанных библиотек.
  3. Нужно подготовить Dockerfile, определиться с образом (FROM …), определиться как мы будет тегировать образ и нужны доступы к репозиторию, в который мы будем пушить образ.
  4. Нужен свой репозиторий, настроить https. Ведь docker client работает только по https.

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

Но не много ли раз упоминается слово Docker уже на стадии релиза?

Потому что считается, что в контейнере удобно и “Ну нормально же все было, работает. Задумайтесь: зачем мы тащим весь этот Docker раньше времени? Проект написанный на python, php, js, swift, scala/java, т.д. Чего ты начинаешь то?”.
Так вот, для таких людей я могу сказать — докер контейнеры это не панацея и не единственная среда, в которой может исполняться ваше приложение. можно запускать еще на:

  • удаленной виртуальной машине
  • на локалхосте без всякой виртуализации и docker контейнеров.

Внезапно 🙂

Давайте представим, что мы делаем сервис, который будет работать на nodeJS.

Результатом этого проекта (или как я называю ‘артефактом’) будет набор js файлов (сам сервис) + node_modules (сторонние библиотеки, которые используются в сервисе).

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

Как вам такая идея:

  1. Делаем .tar.gz с нашим проектом и заливаем его в … удаленное хранилище артефактов! (Еще такие хранилища называют “бинарный репозиторий”).
  2. Говорим url по которому могут скачать наш сервис и начать тестировать.

Дальше тестировщики могут запустить сервис или локально у себя, если у них все есть, или сделать Dockerfile, в котором будет скачивание артефакта и просто запустить контейнер. Ну или еще как-нибудь.

Сразу скажу, если вы не хотите чтобы тестировщики запускали docker контейнеры и вообще “это не их работа” по запуску, то используйте инструмент, который будет собирать образы как только новые артефакты появятся в бинарном репозитории (используйте web hook, гоняйте периодически по крону).

Сейчас из бинарных репозиториев есть:

  • Sonatype Nexus
  • Artifactory

Нексус простой в использовании, в нем куча разных репозиториев, которые можно создать (npm, maven, raw, docker) так что я использую его.

В интернете не счесть статей “как по git push где-то разворачивается контейнер в каком-нибудь kubernetes”. Это же чертовски простая идея, почему я нигде про это не читал? От таких сложных алгоритмов волосы встают дыбом.

Цель данной статьи, сказать — не нужно в одном процессе делать сборку проекта и добавлением его в докер образ.

Разделяете и властвуйте!

(Docker registry это не единственное место где можно хранить ваш проект, выбирайте универсальные пути доставки артефактов на сервера). Делайте сборку проекта, публикуйте артефакты в доступном для скачивания месте.

Не нужно навязывать использование технологии несмотря на то, что она кажется вам очень удобной и модной. Отдельным инструментом доставляйте артефакты на сервер, где будет работать ваш проект.
Все очень просто, дайте выбор другим: использовать docker, запускать в kubernetes или использовать любой другой инструмент для запуска артефактов.

Удачи вам в запуске ваших проектов!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть