Comments 10
Если так правильно, то как деплоить неправильно? Например я разгуливаю через --kube-context, т.к. тестовый и продовый k8s, это разные кластера с разными сертификатами и токенами.
0
-
0
у helm есть опция -i — это позволяет установить релиз, если его нет.
Предпочитаю иметь свои vars.yml под разные среды, а не плодить кучу if.
Так же использую у себя конструкцию вида:
Немного упрощенно, там есть еще несколько шагов, но смысл в ролл бэке. Можно у хэлма использовать опцию wait, но она мне не нравится, так как не наглядна и иногда нужно делать цепочку из rollout status.
Предпочитаю иметь свои vars.yml под разные среды, а не плодить кучу if.
Так же использую у себя конструкцию вида:
- helm upgrade -i -f chart/vars.yml chart_name
- kubectl rollout status deploy || helm rollback chart_name 0 && exit 1
Немного упрощенно, там есть еще несколько шагов, но смысл в ролл бэке. Можно у хэлма использовать опцию wait, но она мне не нравится, так как не наглядна и иногда нужно делать цепочку из rollout status.
+1
А Вы можете рассказать, как вы делаете деплой на test, если нужна миграция базы? На каком этапе это осуществляется?
0
UFO just landed and posted this here
См. «helm.sh/hook-weight»: docs.helm.sh/developing_charts#writing-a-hook
0
Мы столкнулись с проблемой хостов Ingress'a.
У него есть большой минус, он не поддерживает wildcards. Мы хотели сделать динамические entrypoint's, а ля username.domain.com, но из-за упрямства разработчиков Ingress так не сделать.
Т.е. если вы хотите сделать приложение которое реализует схему *.domain.com – так сделать не получится.
У него есть большой минус, он не поддерживает wildcards. Мы хотели сделать динамические entrypoint's, а ля username.domain.com, но из-за упрямства разработчиков Ingress так не сделать.
Т.е. если вы хотите сделать приложение которое реализует схему *.domain.com – так сделать не получится.
0
Sign up to leave a comment.
Kubernetes (k8s) + Helm + GitLab CI/CD. Деплоим правильно