ingress можно ли при деплое в helm поставить каокйто блок чтобы он не перетирал внесенные вручную изменения ?
по сути я меняю только [{"backend":{"serviceName": "1234"....
можно ли при деплое в helm поставить каокйто блок чтобы он не перетирал внесенные вручную изменения ? НЕТ
Поменяйте в values.yaml или это проблема?
я пробую идею с переключением сайта в ментененс, тоесть если идут каието тяжелые миграции и бесшовно переключать не получается, деалем чтото вроде kubectl patch ingress 123 -p '{"spec":{"rules":[{"host":"domain.com","http":{"paths":[{"backend":{"serviceName":"321","servicePort":80},"path": "/","pathType": "ImplementationSpecific"}]}}]}}' и все работает как нужно, пока helm не накатит новый ingress и изменения внесенные вручную перетираются на дефолтные, что ломает всю идею ручного управления.
тоесть вроеде бы, мы имеем такую замечательную штуку как serviceAccount API кубера через который приложение может чтото делать с своими ресурсами, но приходит helm и ломает все.
не используй хельм
а в какой момент ты определяешь, что миграция тяжелая?
это уже зависит от фичи и бекендразработчики сами прикидывают
helmfile умеет патчи накладывать - https://github.com/roboll/helmfile/blob/master/docs/advanced-features.md#adhoc-kustomization-of-helm-charts
у вас где-то проблема в логике. почему деплой вообще происходит, в тот момент, когда идет изменение структуры БД, которая нарисована таким образом, что миграции кардинально корежат базу ? с вашим подходом к разработке в этот момент не то что деплоится, а всем причастным надо дыхание затаить и сидеть так два часа.
ну и раз вы лезете руками, то просто выкиньте манифест ингресса из своего чарта. и катите его отдельным CI
ну с моей стороны, логика как по мне павильная, сначала через job helm-hook накатываются миграции а затем происходит деплой бекенда,фронтенда. И вот тут бекендеры забеспокоились, что они могут чтото не учесть и пока работает старый бекенд а в это время накатывается или уже накатились новые миграции может чтото пойти не так и не туда записаться.
ну да. знакомая проблема в отсутствии нормального архитектора БД.
Так ты разработчикам намекни, чтобы они своими миграциями не ломали совместимость в приложении
Из серии: вечной борьбы devops и не желающийх, что-то адаптировать под инфраструктуру разработчиков 🤼♂️ Фичи ж важнее...
Причем здесь инфраструктура? Это правила хорошего тона
это здравый смысл
Обсуждают сегодня