Как стать автором
Обновить

Комментарии 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

Неужели не работает?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории