Я работал в разных компаниях, которые используют микросервисы. И они запускали их в docker контейнерах. Сейчас я работаю с проектом, который хоть и монолит, но его все равно удобнее запустить в контейнере.
С одной стороны, Docker очень универсальный инструмент, его можно легко и эффективно использовать для решения огромного количества задач. Он понятен и кажется, что все элементарно. Но с другой стороны, если не потратить свое время и ресурсы, чтобы “прокачаться” в грамотном его использовании, вы, скорее всего, переусложните простые вещи. И конечно же будете считать что вы правы, а Docker это бездарная громоздкая фигня, не подходящая для решения вашей уникальной задачи.
Обычно, в стандартной компании, процесс работы над любой задачей выглядит так:
- Делается git push с нашим коммитом
- Триггерится какая-то система, будь то Jenkins, TeamCity и т.п.
- Запускается пайплайн/job, в котором происходит скачивание сторонних библиотек, компиляция проекта, прогон тестов
- Создается docker образ с собранным проектом (ADD. .) и пушится в удаленный docker registry
- Каким-нибудь образом на удаленном сервере делается git pull (chef, puppet, вручную через docker-compose) и запускается контейнер.
Интуитивно я всегда чувствовал, что это все как-то чересчур сложно. Этот процесс гордо называют CI/CD и я уже устал от таких умников, которые ничуть не сомневаются в том, что это самый простой путь.
Для конечного пользователя это выглядит так: по пушу в git репозиторий, где-то разворачивается то, что было в коммите.
Что мне НЕ нравится в этом подходе.
- Единственный способ развернуть систему на удаленном сервере — это пройти через все 5 шагов.
- В шаге 3 могут понадобиться ключи доступа к приватным библиотекам. Процесс может быть долгим, если не настроено кеширование ранее скачанных библиотек.
- Нужно подготовить Dockerfile, определиться с образом (FROM …), определиться как мы будет тегировать образ и нужны доступы к репозиторию, в который мы будем пушить образ.
- Нужен свой репозиторий, настроить https. Ведь docker client работает только по https.
Четвертый пункт, конечно, делается один раз и возможно его не следует добавлять.
Но не много ли раз упоминается слово Docker уже на стадии релиза?
Задумайтесь: зачем мы тащим весь этот Docker раньше времени? Потому что считается, что в контейнере удобно и “Ну нормально же все было, работает. Чего ты начинаешь то?”.
Так вот, для таких людей я могу сказать — докер контейнеры это не панацея и не единственная среда, в которой может исполняться ваше приложение. Проект написанный на python, php, js, swift, scala/java, т.д. можно запускать еще на:
- удаленной виртуальной машине
- на локалхосте без всякой виртуализации и docker контейнеров.
Внезапно :)
Давайте представим, что мы делаем сервис, который будет работать на nodeJS.
Результатом этого проекта (или как я называю ‘артефактом’) будет набор js файлов (сам сервис) + node_modules (сторонние библиотеки, которые используются в сервисе).
Допустим, мы убедились что сервис работает и хотим его запустить удаленно, чтобы наши тестировщики могли проверить его на функциональность.
Как вам такая идея:
- Делаем .tar.gz с нашим проектом и заливаем его в … удаленное хранилище артефактов! (Еще такие хранилища называют “бинарный репозиторий”).
- Говорим url по которому могут скачать наш сервис и начать тестировать.
Дальше тестировщики могут запустить сервис или локально у себя, если у них все есть, или сделать Dockerfile, в котором будет скачивание артефакта и просто запустить контейнер. Ну или еще как-нибудь.
Сразу скажу, если вы не хотите чтобы тестировщики запускали docker контейнеры и вообще “это не их работа” по запуску, то используйте инструмент, который будет собирать образы как только новые артефакты появятся в бинарном репозитории (используйте web hook, гоняйте периодически по крону).
Сейчас из бинарных репозиториев есть:
- Sonatype Nexus
- Artifactory
Нексус простой в использовании, в нем куча разных репозиториев, которые можно создать (npm, maven, raw, docker) так что я использую его.
Это же чертовски простая идея, почему я нигде про это не читал? В интернете не счесть статей “как по git push где-то разворачивается контейнер в каком-нибудь kubernetes”. От таких сложных алгоритмов волосы встают дыбом.
Цель данной статьи, сказать — не нужно в одном процессе делать сборку проекта и добавлением его в докер образ.
Разделяете и властвуйте!
Делайте сборку проекта, публикуйте артефакты в доступном для скачивания месте. (Docker registry это не единственное место где можно хранить ваш проект, выбирайте универсальные пути доставки артефактов на сервера).
Отдельным инструментом доставляйте артефакты на сервер, где будет работать ваш проект.
Все очень просто, дайте выбор другим: использовать docker, запускать в kubernetes или использовать любой другой инструмент для запуска артефактов. Не нужно навязывать использование технологии несмотря на то, что она кажется вам очень удобной и модной.
Удачи вам в запуске ваших проектов!
Автор: kondaurovDev
