делай деплоймент с hpa

Если речь про консьюмеры - логично их в отдельные докерв

Ибо от очереди они независимы

Например по контейнеру на очередь и консьюмер?

Если вопрос в том как упаковать САМ кролик - у меня вообще мысль что его плохая идея совать в докер. Он слишком капризный

Или сделать один контейнер изапилить в него конфиг со всеми очередями чтобы там крутилось много процессов очередей консюмеров? НО вроде ка кне докер-вей

Если речь про консьюмеры - логично их в отдельные докерв

Как же тогда например будет выглядеть docker compose у разработчика? Сервисов там будет херова гора

Или сделать один контейнер изапилить в него конфиг со всеми очередями чтобы там крутилось много процессов очередей консюмеров? НО вроде ка кне докер-вей

Смотри. Если для тебя докер - средство упаковки зависимостей приложения, то это одна история.

Если дальше в планах куб, то тут и начинается веселуха. Ибо очередь, как и бд - это про состояние. А его нужно где-то хранить

Как же тогда например будет выглядеть docker compose у разработчика? Сервисов там будет херова гора

А разработчики прям нарисовали для каждой задачи свой отдельный код? Или это как водится в фреймворках - лежит в одной репе и обернуто в какую-то командную строку?

Как же тогда например будет выглядеть docker compose у разработчика? Сервисов там будет херова гора

Как говно, очевидно. Но он и так как говно выглядит

Если дальше в планах куб, то тут и начинается веселуха. Ибо очередь, как и бд - это про состояние. А его нужно где-то хранить

Дальше будет куб да, но база будет в RDS, а кролика уложу на стейтфул сет

В общем кратко Для тестов достаточно кроля + продюсера + консюмера

Для прода - боооольшой ? . Консумеры и продусеры вокруг него в докерах

Дальше будет куб да, но база будет в RDS, а кролика уложу на стейтфул сет

Рисковый ты человек

А разработчики прям нарисовали для каждой задачи свой отдельный код? Или это как водится в фреймворках - лежит в одной репе и обернуто в какую-то командную строку?

Да в одной репе все, одна точка входа только через параметр имя очереди

Рисковый ты человек

В чем проблема?

Или сделать один контейнер изапилить в него конфиг со всеми очередями чтобы там крутилось много процессов очередей консюмеров? НО вроде ка кне докер-вей

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

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

Тут надо докерезировать старое приложение, логично начинать не с кубернетиса а с докера

Раз рдс, то может амазоновскую нативную очередь заюзать ? Да и мокать ее несложно вроде

Тут надо докерезировать старое приложение, логично начинать не с кубернетиса а с докера

А может эта... Его проще переписать и не тратить время на фигню ?

Раз рдс, то может амазоновскую нативную очередь заюзать ? Да и мокать ее несложно вроде

Да у нас HA особо не нужен на кролике но просто есть много логики на роутинге в нем поэтому используем его

Всем привет! Приглашаем на DINS Java EVENING! Санкт-Петербург 26 июня в 19:30, Старо-Петергофский проспект, 19 На встрече мы познакомимся с опытом стартапа TextBack и узнаем, как проходит их миграция с Vert.x на Spring, поговорим чем еще можно заняться в асинхронном мире. Коллега из Genestack поделится своим опытом построения билд-системы на Gradle в большом проекте с нуля. После докладов мы продолжим общение со спикерами и подкрепимся пиццей. Подробности и регистрация на https://dins.timepad.ru/event/998859/

Да в одной репе все, одна точка входа только через параметр имя очереди

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

А может эта... Его проще переписать и не тратить время на фигню ?

Я не понимаю о какой фигне речь, я зашел с вопросом как лучше разместить консумеры в докере/композе и всего кончили за переписать приложение. Нормально?)

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

Понятно, спасибо. Хотел убедиться что это ок

Понятно, спасибо. Хотел убедиться что это ок

С точки зрения моды и великой архитектурной истины это не ок. Но это стабильно работает :)

С точки зрения моды и великой архитектурной истины это не ок. Но это стабильно работает :)

А как великоархитектурно?

А как великоархитектурно?

Вон там выше рассказывают

Что то выше я там не смог проследить мысль

hpa? Ну так он же вширь одну очередь растянет

А у меня вопрос про много разных

Что то выше я там не смог проследить мысль

Переписать все под докер, переделать под него всю архитектуру, сразу выкинуть докер-компоуз и локальный докер, писать строго так, как будто у всех локальный кубернетес

А в кубернетис уже завезли хотреалод при разработке?

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

можно через ямл якоря уменьшить количество

а еще можно докер-компоуз шаблонизировать

А в кубернетис уже завезли хотреалод при разработке?

да, если в контейнере это есть

Переписать все под докер, переделать под него всю архитектуру, сразу выкинуть докер-компоуз и локальный докер, писать строго так, как будто у всех локальный кубернетес

да, компоуз лишний, согласен )

Я не понимаю о какой фигне речь, я зашел с вопросом как лучше разместить консумеры в докере/композе и всего кончили за переписать приложение. Нормально?)

ну, жизнь это боль. страдай.

пацаны, как в компоузе, запустить контейнер, подождать пока он закроется, и потом уже запустить другой?

Вообщем я предлагаю костыль, мода предлагает страдать ради великой цели)

Единственное что меня останавливает от локального кубернетиса это не понятно как девелоперам девелопить чтоб сразу результат видеть

Так чтобы без мудатни с пересборкой контейнера на каждый чих

пацаны, как в компоузе, запустить контейнер, подождать пока он закроется, и потом уже запустить другой?

я рассказывал

https://habr.com/ru/post/454552/ - читай комменты

Так чтобы без мудатни с пересборкой контейнера на каждый чих

на чем они пишут?

на чем они пишут?

js

ого, спасибо

js

https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f такое?

https://medium.com/devschacht/praveen-durairaj-an-exhaustive-guide-to-writing-dockerfiles-for-node-js-web-apps-7b033bcc0b4f такое?

Есть еще большие куски на php, так что там не совсем js к сожалению

Единственное что меня останавливает от локального кубернетиса это не понятно как девелоперам девелопить чтоб сразу результат видеть

есть несколько вариантов, например scaffold от google

пхп тоже умеет в хот релоад

берешь базовый контейнер и мочишь. Он там на базе чего-то типа айнотифай (механизм отслеживания изменений в файлах в никсах)

нужно только образ выбрать верный...

есть для golang, есть для js, есть для питона

А кто нибудь тут реально локально на кубернетисе девелопит ваще?

но учти - в релиз это пойти не должно, т.к. оно забивает какие-то серьезнеы системные ресурсы

А кто нибудь тут реально локально на кубернетисе девелопит ваще?

никто, ибо не нужно

есть тестовый кластер - удаленный деплой

а для локальной... есть миникьюб... есть https://github.com/pyToshka/openshift-vagrant

Тогда нахера все советют?)

Ну миникуб да я имею ввиду

Тогда нахера все советют?)

что советуют?

С кубернетисом локально вместо докр-композа

Ну миникуб да я имею ввиду

telepresence ещё есть

С кубернетисом локально вместо докр-композа

кубернетес сам по себе слишком тяжелый, чтобы локально его гонять

telepresence ещё есть

Спасибо. А они уже реально работают или еще не оч зрелые?

в принципе, тебе для локальной разработки, ты прав, достаточно компоуза + замокать все зависимости

кубернетес сам по себе слишком тяжелый, чтобы локально его гонять

сейчас у разрабов такие машины, что обычно вполне себе

ну-ну

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

Та оно так то понятно

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

миникьюб - конечно, естественное... ололол

половина функций куба не работает

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

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

что не всегда возможно

то, что работает в локально или в композе, не обязано работать в к8с

я согласен, но то что работает в миникьюб необязательно заведется в к8с

а то что заведется в к8с не факт, что заведется на соседнем

Кажется достаточно иметь стейджинг на реальном кубе и вопросов не будет

У меня еще например RDS в проде, не понятно как мне делать миникуб

У меня еще например RDS в проде, не понятно как мне делать миникуб

мокать

либо в другую базу ходить

(типа постгреса)

С композом я доставляю локальный постгрес

угу

главное, чтобы желания компоуз на прод втащить не возникло. Остальное.... не важно

Не, мне он там ну нужон

Есть же даже конвернет композа в кубернетис

на продакшн не надо

пожалуйста

Дальше можно руками поправить

Ладно, а по кронджобам, у кого какой самый любимый солюшен?

Ладно, а по кронджобам, у кого какой самый любимый солюшен?

https://github.com/mcuadros/ofelia

https://github.com/mcuadros/ofelia

?

airflow ха-ха-ха-ха

но если серьезно - systemd-timer, если осилишь

Ну у нас лежит пачка кастомных systemd юнитов