надо сайт запилить, и за 1$ генерировать и подписывать "святые" файлы с агендой, что если этот "святой" файл положить в репозиторий, качество кода увелчивается на %5, вероятность деплоя на 7,5%

в чужой монастырь со своим уставом не лезут, конечно, но мне просто не нравится идеология хелма, который берёт на себя больше задач, чем положено пакетному манагеру и шаблонизатору. Хранение конфигураций в values (типа кредов к базе и тд) - как по мне - плохой подход.

package manager он никудышный , да и шаблонизатор тоже :)

а что не так с helm? видимо пропустил это. очень удобно для cd как мне кажется

у нас нет винды)

Приветствую может кто-нибудь подсказать (или ссылочкой в доку поделиться), как реализовать такую логику 1) сначала стартует deployment с базой 2) затем стартует job-а с миграциями 3) затем стартуют остальные деплойменты и сервисы запуск производится через helm

Пусть те кому миграция нужна сами и мигрируют. Если база знает про транзакции то только она миграция полностью завершится и все будет как вы хотите

Добрый день, посоветуйте как поступить. Есть вервис слушает 8080 порт (там курититься томкат) на томкате по пути http://service-ip:8080/some-path/ крутиться сама вебморда приложеньки Activiti. на тек момент у меня ингрес настрокен на томкат аля '"annotations": { "kubernetes.io/ingress.class": "nginx", "kubernetes.io/tls-acme": "true", "nginx.ingress.kubernetes.io/proxy-body-size": "0", "nginx.ingress.kubernetes.io/rewrite-target": "/" } .... rules: - host: activiti-dev.exempl.com http: paths: - backend: serviceName: activiti-web-service servicePort: 8080 path: / ' как указать чтоб из / направлял сразу на :8080/some-path/

Есть аннотация app-root или как то так, смотрите доку nginx-ingress

что значит сами мигрируют

если бы не было хелма, то только вопросы по нжинксовому ингрессу и остались

Ну как вариант то что вы хотели в Job запускать, запускайте в InitContainer самих приложений, которым эти миграции нужны

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

PowerShell на линуксе есть

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

PowerShell это сила, надо только сесть и изучить. Всяко лучше строк гонять по пайпам

PowerShell это сила, надо только сесть и изучить. Всяко лучше строк гонять по пайпам

А так - не вижу смысла на линуксах при наличии баша с питоном.

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

да, потом кластер от кронджоб разносит)

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

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

а если ты ошибся в докере?)

какую проблему вы решаете?

есть таска, которая должна запускаться каждую минуту (работать она может от оной минуты до 5 часов), конкуретнтность выполнения запрещена, запрет основывается на файловых локах. В идеологии докера - эти локи не работают. (Когда выкатывается новая версия приложения, задача стартует в 2 подах), хотя должна бы в новом не стартовать, пока в старом не умрет. Старый под при деплое новой версии приложения перестает запускать новые кронтаски, а только доделывает что были и умирает. Дешевле выглядит переделать эу таску на кронджобу.

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

Зачем такой под, если можно сделать крон в поде?

Станислав, там требуется одну таску по KD запускать, какой еще crontab?

есть таска, которая должна запускаться каждую минуту (работать она может от оной минуты до 5 часов), конкуретнтность выполнения запрещена, запрет основывается на файловых локах. В идеологии докера - эти локи не работают. (Когда выкатывается новая версия приложения, задача стартует в 2 подах), хотя должна бы в новом не стартовать, пока в старом не умрет. Старый под при деплое новой версии приложения перестает запускать новые кронтаски, а только доделывает что были и умирает. Дешевле выглядит переделать эу таску на кронджобу.

все это скурпулезно записывает etcd, отчего может стать плохо

починили же через historyLimit, или не?

ну да, тогда всё забъется резалтами от бесполезных кронджобов

я видел где-то что можно указать в пути монтирования hostname пода. Может помнит кто где это можно найти?

хотя до него был и вижл бейсик фор скрипт (сам на нем автоматизировал)

ещё jScript был, я на нём даже написал 1 скрипт в жизни

есть таска, которая должна запускаться каждую минуту (работать она может от оной минуты до 5 часов), конкуретнтность выполнения запрещена, запрет основывается на файловых локах. В идеологии докера - эти локи не работают. (Когда выкатывается новая версия приложения, задача стартует в 2 подах), хотя должна бы в новом не стартовать, пока в старом не умрет. Старый под при деплое новой версии приложения перестает запускать новые кронтаски, а только доделывает что были и умирает. Дешевле выглядит переделать эу таску на кронджобу.

env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName

https://github.com/kubernetes-incubator/kubespray через нее можно быстро развернуть кластер?

да, оно для того и предназначено

прикольно, надо попробовать, вчера вроде про это говорил @rheinx

Ты главное- бери только релизные(теговые) версии, внимательно почитай настройки перед деплоем. Плюс версию кубера сразу последную там поправь, иначе есть разочарования)

Всем привет? КТо то юзает это для сбора логов? https://github.com/helm/charts/tree/master/stable/fluent-bit