Слушать кастомный CRD наверное самый надёжный вариант

Смертельно убитый труп мертвеца. Извините.

"кастомный CRD" отлично звучит :)

Смешно тебе

зависит от того, что вы из куба делаете. Если шаред хостинг для приложений, то гаверное нет)

У тебя просто нет фантазии)

Смешно тебе

Ну я и тех и тех устриц ел

У тебя просто нет фантазии)

есть, просто идеи аля серверлесс ферма он деманд я решил не озвучивать

есть, просто идеи аля серверлесс ферма он деманд я решил не озвучивать

А мсье таки обладает фантазией)

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

может поставить сайдкар контейнером перед ним oauth proxy? https://github.com/bitly/oauth2_proxy

может поставить сайдкар контейнером перед ним oauth proxy? https://github.com/bitly/oauth2_proxy

oauth не хотеть, да и в любом случае - клиент нужно модифицировать, Сейчас он просто ходит по тунелю - протокол нестандартный

этот прокси умеет по basic auth пускать

но по туннелю тоже норм, почему нет

этот прокси умеет по basic auth пускать

Протокол не HTTP, свой собственный костыль

почему helm upgrade foo . не апгредит values, которые мапятся на evn в контейнерах? приходится удалять все и заново инсталлить

в смысле не апгрейдит, можно поподробнее? вы передаете при апгрейде новый values.yaml но он его не использует?

—reuse-values

в смысле не апгрейдит, можно поподробнее? вы передаете при апгрейде новый values.yaml но он его не использует?

ага

хорошо, а что значит не апдейтит - не рестартует под?

там еще была команда у хелма получить теущие values (не помню как называется) - она возвращает старые значения?

после helm upgrade контейнер не получает env из values

приходится делать helm delete foo, helm install ...

после helm upgrade контейнер не получает env из values

Values я так понимаю попадают в конфигмап?

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

:D

Жаль не гиф

Вечер добрый. Есть кто ставил Ambassador как API gateway в продакшн? У него нет проблем с роутингом в нужные поды когда происходит обновление деплоймента? Имею ввиду, не станет ли он раньше времени трафик в новую поду гонять?

Кто пересобирает контейнеры, не меняя тэга, как вы кубу объясняете, что надо его перекачать и обновить? Я щас удаляю под и у деплоймента стоит imagepullpolicy always, но мне это не очень нравится

можно просто добавить env переменную, и менять ее

у меня она называется redeploy_counter

Кто пересобирает контейнеры, не меняя тэга, как вы кубу объясняете, что надо его перекачать и обновить? Я щас удаляю под и у деплоймента стоит imagepullpolicy always, но мне это не очень нравится

лучше не делать так

Я понимаю, но это удобно для ситуации: "сделал namespace под конкретный тикет в JIRA, в этом ns развернул весь сервис, а дальше разработчик делает новые коммиты". Я, соответственно, тэгирую контейнеры номером тикета, вот и получается, что он не меняется

Не помню, где спёр: kubectl patch deployment website-next -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

После этого при imagepullpolicy always происходит обновление сервиса

Тьфу, деплоя

Мне кажется я не одинок в этом, кто-то такую задачу решает иначе? Расскажите. Я только строю все, так что могу переделывать как захочу, еще пока непоздно :)

Вообще, кто-то стек Atlassian использует как CI/CD для k8s? :)

Я тоже строю, но у меня версии типа :latest и :stage заданы и в ближайшие полгода вряд ли поменяются...

Кто пересобирает контейнеры, не меняя тэга, как вы кубу объясняете, что надо его перекачать и обновить? Я щас удаляю под и у деплоймента стоит imagepullpolicy always, но мне это не очень нравится

Менять тег самый лучший подход. Если bamboo то там кроме номера тикета можно номер билда именно этой ветки выцарапывать из env

Ну если вы конечно фича бранчи используете

Вообще, кто-то стек Atlassian использует как CI/CD для k8s? :)

Озадачен трем же вопросом, вчера нашел статью как из bamboo деплоить в куб, но пока не читал

Вообще, кто-то стек Atlassian использует как CI/CD для k8s? :)

Тоже интересно. У нас битбакет используется

Ну и тегировать условно: ${JIRA_ISSUE}-${BUILD_NUMBER}

И да, старайтесь избегать :latest :stage :dev, etc.

Тоже интересно. У нас битбакет используется

Bitbacket pipeline то бишь?

Создает больше проблем чем решает

Ну и тегировать условно: ${JIRA_ISSUE}-${BUILD_NUMBER}

Тэгировать так ок, представляю как, но это ж получается deployment менять каждый раз. Щас у меня deployment.yml лежит в репозитории и туда sed все подставляет, а вот с билдом sed не прокатит блин :(

Bitbacket pipeline то бишь?

Да если бы. Сейчас просто битбакет, в нем хуки/плагины к которым Дженкинс прикручен. Но это какая-то жесть...

Да если бы. Сейчас просто битбакет, в нем хуки/плагины к которым Дженкинс прикручен. Но это какая-то жесть...

Ага, вот я к тому и спросил, что битбакет ж не ci/cd, получается дженкинс в этой роли все-таки

Да если бы. Сейчас просто битбакет, в нем хуки/плагины к которым Дженкинс прикручен. Но это какая-то жесть...

А в чем проблема то?

А в чем проблема то?

В самом битбакете хук который можно позвать из Дженкинса с результатом мало что умеет. Хочется чтобы именно пайплайн какой-то был. Скажем идёт коммит в релизную ветку, запустить там ci, потом поавтомержить дальше, скажем в мастер, там запустить ci, и если всё ок, то чтобы помержило и ещё возможно версии имиджей подняло в чарте, версию сайта и запаблишило его...

Может много хочу конечно :-)

Так а в чем проблема на дженкинсе это сделать?

Ну я не знаю как например. Думаю что придется с этим разобраться и сделать. Но подозреваю что поддерживать потом это будет проблема.

Делаем multibranch pipeline, в бранче по определенному паттерну прогоняем тесты и в случае успеха мержим в другую бранчу, там внезапно отрабатывает триггер на изменения и определив, что это другая бранча прогоняет тесты и вместо мержа куда-то выкатывает на прод/стейдж

Ну я не знаю как например. Думаю что придется с этим разобраться и сделать. Но подозреваю что поддерживать потом это будет проблема.

Jenkins Pipeline

Спасибо, почитаю

Код пайплана будет лежать в репе проекта, и там и правите

Хм, походу в Bamboo так круто не сделать

Хм, походу в Bamboo так круто не сделать

Сделать, но придется много шелла писать

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

А вот пайплайнов нет нормальных к сожалению, в плане Pipeline-as-a-code

Сделать, но придется много шелла писать

Ну как много, немного больше чем для дженкинса

И да, bamboo умеет автоматом вмерживать бранчу в апстрим если билд зеленый

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

Ну вот пока я docker без куба юзал - былр удобно. А с кубом толку от этих deploy немного. Он в итоге bash скрипт просто запускает у меня

Ну вот пока я docker без куба юзал - былр удобно. А с кубом толку от этих deploy немного. Он в итоге bash скрипт просто запускает у меня

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

А вот на плагины бамбу бедный, да

А вот пайплайнов нет нормальных к сожалению, в плане Pipeline-as-a-code

может немного не в тему: юзаем у себя Concourse CI, паплайны держим рядом с кодом, клёвый инструмент

Ну я понимаю. Моя ситуация - это в основном выкатывать новые версии контейнеров в окружения для тестирования. И сюда deploy не особо годится, т.к. надо привязываться к созданию бранчей в репо и к пулреквестам. Поэтому в итоге всё делает обычный plan. А deploy plan только когда уже в продакшен катим пригождается.

Ну я понимаю. Моя ситуация - это в основном выкатывать новые версии контейнеров в окружения для тестирования. И сюда deploy не особо годится, т.к. надо привязываться к созданию бранчей в репо и к пулреквестам. Поэтому в итоге всё делает обычный plan. А deploy plan только когда уже в продакшен катим пригождается.

Ну да, все верно, а как иначе? Может вы и в мастер коммитите?

Я к тому, что Bitbucket+Bamboo не особо дружелюбны к k8s. Только костылять

Я к тому, что Bitbucket+Bamboo не особо дружелюбны к k8s. Только костылять

Ну дергать shell вместо плагинов, shell хранить в том же репо где и код, что-бы в бранчах можно было правки делать и тестить сразу

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

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

много кто так делает. Я так делаю. И прод по хешу выкатываю

Есть кто рулит кубером через ансибл? Есть вопрос

Есть кто рулит кубером через ансибл? Есть вопрос

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

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

Депрекейиед старая версия модуля. Модуль k8s актуален

много кто так делает. Я так делаю. И прод по хешу выкатываю

А деплоите как? Хельмом?

Депрекейиед старая версия модуля. Модуль k8s актуален

Можно ссылочку на новую версию модуля? Что то не видел

А деплоите как? Хельмом?

нет, есть шаблон и через envsubst

cat template.yml | envsubst | kubectl apply -f -

Можно ссылочку на новую версию модуля? Что то не видел

https://docs.ansible.com/ansible/latest/modules/k8s_module.html

https://docs.ansible.com/ansible/latest/modules/k8s_module.html

спс. А что делаете через этот модуль? какие проблемы?

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

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

Только бранч деплой

спс. А что делаете через этот модуль? какие проблемы?

Создаю вид инфраструктуры, роли, секреты и тд. Логика работы такая что на хосте где запускаетсч ансибл плейбук локально, он берет кубконфиг и управлчет кластером на другом хосте. Но тут почемуто он начал выдавать ошибку что нужен модкль openshift, что логично. Но на ансибл хосте модуль установлен, и с докальным кластером это работало. А с удаленным почему то нет. Зачем удаленному кластер этот модуль если по сути управление происходит через ансибл хост

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

у всех свои конфиги. У нас stage скорее preproduction. frontend статика html/css/js каждая ветка выливается на поддомен. А для api чистый stage сильно не нужен (нам).

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

почему препрод а не rc

preprod - проверить, что прод не развалится при деплое.

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