🤔 Так ли нужны нам сложные решения?
Всегда ли нужен Кубер в современных проектах? Обязательно ли разворачивать ELK-стек для сбора логов?
Обычно рабочие инструменты не внедряются просто так — они призваны решить какую-то проблему. Нормальный человек не будет настраивать Kubernetes, когда проект еще даже не завернут в контейнеры, аргументируя тем, что это модно. А может Kubernetes в проекте вообще не нужен и достаточно Compose или Swarm? ¯_(ツ)_/¯
👉 Нужно понимать какой инструмент подходит лучше для решения конкретной проблемы, в чем его плюсы и минусы, насколько «дорогим» выйдет его внедрение.
Причем под дороговизной я понимаю косвенно-финансовую составляющую чего-либо: сколько времени и сил команда потратит на внедрение, обучение, поддержку решения. Человеко-часы тоже платные.
🥲 Один из запомнившихся случаев
В свое время у меня был опыт установки Kubernetes. Ну, на самом деле, не так сложно поднять простой кластер на виртуальных машинах, базово настроить его и задеплоить что-нибудь. И вот на новом месте появилась задача 🟢 динамически запускать тесты на разных машинах.
Совместно с разработчиком собрали в контейнеры эти тесты, которые раньше запускались на специальных виртуалках. Затем я поднял небольшой кластер Kubernetes на виртуалках, просто потому, что я уже умел это делать и это выглядело хорошим решением для оркестрации (управления) контейнерами на разных машинах.
Потратил день, чтобы интегрировать Jenkins с Кубером, затем поразбирался как джобы создавать. Перевел тесты на новую схему, проверил. И знаешь, все отлично работает и по сей день. Тесты теперь гоняются одинаково по времени, нормально распределены по машинам — то что и хотели. 🦾
Только вот не через чур ли сложное решение — поднимать кубер для запуска тестов? Это же виртуалка под мастер-ноду, виртуалки под воркеров. Благо разработчиков не пришлось учить — мы же только тесты запускаем, а это я настраиваю. (привет, бас-фактор 🚌)
А в целом пользоваться им кто-то кроме меня умеет? Контейнерами еще худо бедно многие разработчики умеют пользоваться, а вот Kubernetes зачастую видят в первый раз. Какие там деплойменты, сервисы, ингрессы, вы чего…
И вот другая задача — примерно тоже самое, 🟢 динамически запускать контейнеры на нескольких машинах, иметь возможность горизонтально масштабироваться. Решил попробовать поставить Docker Swarm — ни разу раньше не пользовался 😬.
Оказалось, что кластер инициализируется за минуту одной командой, ноды в него влетают другой командой, а задеплоить сервис можно просто подкинув уже имеющийся docker-compose.yml. Так еще и нет пердолинга с сетью — сервис будет доступен по указанному порту на любой из нод кластера.
Добавил к нему Swarmpit, чтобы кластером можно было управлять из веб-интерфейса.
Крутим там сейчас сервисы, которые иногда требуют масштабирования — все отлично работает. Разработчикам проще — есть веб-интерфейс, это более понятные «просто контейнеры», еще и docker-compose синтаксис. Затрат на поддержку меньше.
Следующий этап 🟠 выпилить к чертям Kubernetes, о котором тут речь, и поднять на его месте свежий Swarm-кластер. Заодно попробую Portainer для удобного взаимодействия с кластером, вместо Swarmpit.
Подумай, а так ли тебе нужен сложный комплексный инструмент, когда можно обойтись более простым?