Комментарии 15
Блин до чего же потный все такие Dev-Ops.
У меня тоже есть небольшой проект который я надеюсь скоро перерастет Docker-Compose.
Было интересно вас почитать, теперь я представляю какой примерно объем работы предстоит заложить на изменение архитектуры.
Первый раз слышу об использовании Docker Compose в продакшне
да всё ок для маленького проекта
Примерно все. Это инструмент для локальной отладки проекта, но не для использования в проде. Для прода нужны инструменты уровня Kubernetes.
Так он долго он и не жил. Оркестраторы появились чтобы решать проблемы, которые появились из-за масштабирования продуктов. И они начали появляться у всех свои, пока гугл не начал делать опенсорс на основе своих наработок (так и появился кубер).
Так он долго он и не жил.Не совсем понял, что вы хотели сказать, если вы имели ввиду, что до появления кубера прод «долго не жил», то абсолютно не согласен. Прод отлично себя чувствовал и до появления кубернетеса. Он и сейчас себя без него отлично чувствует. Кубер просто привнес некую стандартизацию решения ряда проблем, что позволило с меньшими трудозатратами их решать.
И при этом далеко не любой прод сталкивается с такими проблемами и в таком их количестве и качестве, что применение кубернетеса оправдано. Когда кубер тащат в прод просто потому что «так принято», то не редко получается, что никаких актуальных проблем он не решает, а только добавляет.
Для локальной отладки minikube же.
для меня пока непонятно зачем ямлы полностью шаблонизировать. столкнулся только с одной проблемой - конфигмапов действительно много, но они выносятся в отдельные файлы и уже там шаблонизируются(хоть sed хоть jinja). мб кто-то поопытнее просветит?
Если конфигурируется большое количество объектов, а еще и подразумевается их запуск в нескольких окружениях, то описанный в статье подход с использованием универсальных шаблонов просто удобнее. Нужно смотреть по потребностям, где-то хватит и связки стандартных манифестов + sed, как вы описали.
вам бы в политики пойти... а можете привести пример? у меня несколько проектов есть, по 30-100 подов без нагрузки, в сумме около 50 ямлов на одни только поды но ситуации когда динамически что-то менять нужно было - не встречал.
Рассказываю как устроено у нас. Для примера возьму объекты Deployment.
Имеется 25 деплойментов в dev среде, столько же нужно запустить в проде. В процессе переноса из композа в кубер мы быстро убедились, что описания объектов довольно однотипные. Шаблонизация позволила соблюсти принцип DRY — не повторять похожие друг на друга куски конфигурации. Вместо 50 yaml манифестов у нас всего 1 файл-шаблон и 3 values файла. Если мне нужно будет поправить базовую конфигурацию манифеста, то я делаю это в файле-шаблоне. Если мне нужно поправить параметры специфичные для конкретного деплоймента, то я делаю это в values-файле – редактирую для него команду запуска, задаю requests/limits, количество реплик. Плюс у некоторых деплойментов могут быть опциональные параметры, которые не нужны для всех (напр. topologyspreadconstraints). В таком случае вместо того, чтобы плодить еще один шаблон я добавляю if-else условие в существующий и включаю опцию для конкретных объектов с помощью переменной.
Если понадобятся примеры конфигов, то они есть в статье, глава про Helm.
Спасибо, обязательно пригодится ваш опыт перезда!
Миграция приложения из Docker Compose в Kubernetes. Как, зачем и с какими проблемами я столкнулся