Комментарии 16
Блин до чего же потный все такие 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.
Спасибо, обязательно пригодится ваш опыт перезда!
Сбой одного компонента, например утечка памяти или высокая загрузка CPU, влияет на другие. Падение одного воркера можно пережить, но целиком лежащий или лагающий фронтенд и бэкенд - проблема более неприятная.
А как же resources
configures physical resource constraints for container to run on platform?
services:
frontend:
image: example/webapp
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
pids: 1
reservations:
cpus: '0.25'
memory: 20M
Неужели не работает?
Миграция приложения из Docker Compose в Kubernetes. Как, зачем и с какими проблемами я столкнулся