Найти в Дзене
proghub.ru

Микросервисное заблуждение. Опыт работы с Doker'ом команды proghub

В начале многих проектов, часто появляется выбор между новыми и крутыми фреймворками/языками/подходами. Конечно все зависит от специфики проекта, бюджетов, команды. Так вот про архитектуры: интересно то что в последнее время все бегут за микросервисной архитектурой, насмотревшись на страшные и ужасные монолиты с многолетней кодовой базой. Вооружившись успешными кейсами от больших компаний начинают ваять новый продукт с разделенной логикой ну и докером с k8s конечно. И вот в какой-то момент оказывается что проще сходить сервисами в одну бд, чем связывать их по интерфейсу, транзакция оплаты иногда теряется где-то в цепочке сервисов, а микросервисный рай становится адом. Вывод отсюда достаточно простой: если вам нужно запустить проект, просто применяйте то что знаете хорошо, добавьте немного консерватизма в свой выбор. Со временем, когда ваше решение достигнет пика возможностей тогда рассмотрите варианты плавного перехода. Если это ваш домашний проект - ни в чем себе не отказывайте :)
Оглавление

В начале многих проектов, часто появляется выбор между новыми и крутыми фреймворками/языками/подходами. Конечно все зависит от специфики проекта, бюджетов, команды.

Так вот про архитектуры: интересно то что в последнее время все бегут за микросервисной архитектурой, насмотревшись на страшные и ужасные монолиты с многолетней кодовой базой. Вооружившись успешными кейсами от больших компаний начинают ваять новый продукт с разделенной логикой ну и докером с k8s конечно. И вот в какой-то момент оказывается что проще сходить сервисами в одну бд, чем связывать их по интерфейсу, транзакция оплаты иногда теряется где-то в цепочке сервисов, а микросервисный рай становится адом.

Вывод отсюда достаточно простой: если вам нужно запустить проект, просто применяйте то что знаете хорошо, добавьте немного консерватизма в свой выбор. Со временем, когда ваше решение достигнет пика возможностей тогда рассмотрите варианты плавного перехода. Если это ваш домашний проект - ни в чем себе не отказывайте :)

Этот пост был навеян ситуаций годичной давности, когда наш старый proghub.ru работал на docker, а выбран он был только из интереса. Так вот это оказалось очень плохой идеей)

Docker

-2

Выше, с мыслями разработчика мы заговорили про docker. Что это такое можно прочитать тут и тут. А я ниже расскажу про наш опыт.

Почему мы выбрали Docker?

До запуска proghub.ru я пользовался им для локальной разработки около 2х лет и это было прекрасно: не засоряешь свою машину, легко разворачиваешь одинаковое окружение на разных компах, все поднимается с одной команды.

Приведу пример: я пользуюсь ubuntu 18.04 и хочу протестировать работу списков в redis чтобы понять подойдет ли он для моего решения или нет. Как я сделаю это без докера: загуглю как установить редис на мою ОС и выполню кучу команд (apt install redis...), как я сделаю это с докером: docker run -ti --rm redis redis-cli . Всего одна команда и вжух! Единственный минус локальной разработки с докером это пожалуй его скорость на windows и macos.

Когда в твоем проекте больше одно сервиса, возьмем к примеру стандартный LEMP-стек (linux+nginx+mysql+php). Чтобы собрать все сервисы вместе и заставить их взаимодействовать нам понадобиться docker-compose, это достаточно простая утилита.

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

Docker и proghub.ru

У докера в проде есть ряд проблем, которые мы обнаружили по ходу его использования:

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

- Порядок запусков сервисов (healthcheck и depends_on в docker-compose не решают проблемы). Пример БД еще не успела бустрапнуться, а проект уже к ней пытается подключиться и все падает. И да мы знали про костыль wait-for.sh.

- сеть/файрволл - это боль. Дело в том, что докер прописывает свои правила в iptables, так что свои задавать автоматически станет проблематично. Это фикситься опять костылем в виде изменения настроек докер-демона.

Это наш личный список вопросов к докеру которые оставили след в нашем опыте. Повторюсь что для разработки докер суперкрут. И да можно было притащить решение вроде kubernetes но это уже слишком :)

Если вам интересен такой формат, когда мы делимся своими ошибками и опытом, поддержите нас подпиской и лайком, что бы больше программистов увидели наш контент и мы в свою очередь приложили больше усилий над качеством и частотой материала:)