подскажите как лучше оформить зависимости между helm-чартами. Есть 10 чартов, из них 4 это базы, они долго поднимаются, надо чтобы чарты с приложениями начинали подниматься только после того, как поды с базами станут ready.

ты можешь в чартах описать зависимость и тогда один чарт потянет все что ему нужно. но ты не можешь сказать "запусти под после запуска базы". зато можешь entrypoint или init container намутить, который будет тыкать в service дб. как только оно начнет что то возвращать - завершать инит с успехом и запускать твой апп

подскажите как лучше оформить зависимости между helm-чартами. Есть 10 чартов, из них 4 это базы, они долго поднимаются, надо чтобы чарты с приложениями начинали подниматься только после того, как поды с базами станут ready.

initContainers с wait’ом на базу?

про init знаю, думал может появились какие-то менее костыльные варианты )

Нет. Никакого "умного" деплоя Helm не умеет.

ок, спасибо!

в каком то смысле ваш апп будет дожидаться появления зависимостей, если например падает при недоступности бд. он же будет перезапускаться =)

Всем првиет! Подскажите в k8s service можно задать диапозон портов?

Что поделать, readme часть кода же

смотреть, что по факту image не поменялся. Там же есть sha256. Может он, ещё не читал. 100% можно детектить, что у контейнера отличаются только меткой.

там же собирается по слоям, у слоя md5 свой или ещё какой хэш. Хэши последних слоёв равны - не поменялся.

docker pull же не перекачивает слои, если они одинаковые у разных тегов одного image

даже если они у разных тегов разных образов

"слои" и "образы" это "многие ко многим"

да не, docker pull же ничего не качает, если контент не менялся

docker pull ничего не качает, deployment не должен обновлятся.

если тег поменялся, то обновится, даже если не качал ничего

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

и не пушит так же

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

порвёшь

выкачиваться может и не будет, но тегаться будет

docker pull some:label1 docker tag -t some:label2 some:label1 docker push some:label2

docker pull some:label2 ничего не качнет

docker build ничего не пересобёрет

потому что нельзя "скачать тег"

можно "узнать sha слоёв по тегу и скачать их"

Я могу путать понятия, с другой стороны. Если работает some:label1 а дальше docker pull some:label2 ничего нового не выкачивает то deployment не нужно запускать, ничего не поменялось.

docker pull*

потому что нельзя "скачать тег"

кроме слоев есть еще манифест, в нем хранятся теги. Меняются теги - меняется хэш манифеста

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

Ставлю миникуб)

Винда просто умерла )

кроме слоев есть еще манифест, в нем хранятся теги. Меняются теги - меняется хэш манифеста

ты про манифесты кубера?

ты про манифесты кубера?

https://docs.docker.com/registry/spec/manifest-v2-2/

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

У меня есть 2 тега 027cb8a34f212354af11dfc548d339e3a7ddf063 dcddfdc066d02ac80341de3e044918d49df5622c Они собраны на 100% одинаково. docker build просто берёт все их кеша слоёв. Есть же способ это задетектить, чтобы не перезапускать deployment просто так. Я про это начал говорить, в теме не разбирался пока, руки не доходят.

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

это не теги, это хеши

docker build -t service:dcddfdc066d02ac80341de3e044918d49df5622c .

это теги

$CI_COMMIT_SHA

И тут косяк только один, левые комиты заставляют deployment обновиться, хотя не нужно.

а это проблема?

Ну, нам уже пол года пофиг. А вообще безполезное действие

Я написал, что это если с этим нет проблем, то наоборот круто. Это тест, что приложение не валится от рандомных перезапусков =)

думаю этим должен CI заниматься, а не докер и не кубер

И тут косяк только один, левые комиты заставляют deployment обновиться, хотя не нужно.

образы тегируются git коммитами (хешами) в том месте, где идет deploy сервиса в k8s по триггеру, можно выдирать метку образа, через git смотреть что поменялось, и принимать решение. деплоить или нет

думаю этим должен CI заниматься, а не докер и не кубер

+1

общепринята практика делать [ci skip] в хедлайне коммита, например

образы тегируются git коммитами (хешами) в том месте, где идет deploy сервиса в k8s по триггеру, можно выдирать метку образа, через git смотреть что поменялось, и принимать решение. деплоить или нет

Я думаю, что можно опираться докеровское сравнение слоёв, потому что он уже это умеет. Пока не дошел ещё.

точнее CD

Зачем мне думать, что поменялось, если это знает докер.

Я думаю, что можно опираться докеровское сравнение слоёв, потому что он уже это умеет. Пока не дошел ещё.

это сложнее, проще посмотреть что поменялось в деревере git'a, какие файлы, и напримерт создать в репозитории .deployignore куда вписать какой-нибудь /README.md /doc и прочее

репа поменялась, а docker build ничего не сделал, deployment не нужно перерезапускать

readme.md поменялось, оно в dockerignore

сервис не поменялся, но тег меняется, потому что новый комит, а deployment смотрит на image, сменился, перезапускаю.

Это МИНИ проблема, просто разговор зашел про это.

да это проблема того же типа что и "запускать тесты только если код поменялся, а не readme"

она не про докер и не про кубер

Ну docker может на 100% сказать, что что-то поменялось, мне для этого не нужно ничего делать. Это отличие от тестов.

Для тестов ещё нужно пойти напрячься, чтобы граф зависимостей собрать.

не может

докер оперирует уже артефактами сборки, а не исходными данными

если поменять файл, который в dockerignore, то он будет поновой все собирать? Не будет.

если поменять файлы, которые не попадают в image вообще, он будет пересобирать? Не будет, все из кэша

если у меня src docs и docs не попадает в image, просто не хотелось бы перезапускать deployment из-за комита в docs, который поменял тег.

это скорее всего 1 if, не более.

ну не собирай образ просто

то есть в твоём случае не тегай

если у меня src docs и docs не попадает в image, просто не хотелось бы перезапускать deployment из-за комита в docs, который поменял тег.

используй версию софта для тегирования, а не хэш коммита

docker build -t service:$SHA_COMMIT_SHA . выполняется всегда, после этого можно сказать, что image поменялся или нет.

Да не хочу я делать работу, которуюделает docker build. Уже все готово же.

ну сделай чтобы не выполнялось

ну так после docker build нужно смотреть,что текущий image не отличается от работающего и скипать, я про это говорю 20 минут уже)

при чём тут образ вообще?

Да не хочу я делать работу, которуюделает docker build. Уже все готово же.

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

docker build не собирает ничего, если не было правок. Следовательно не нужно перезапускать deployment. Я только про это.

docker build бесплатный если не было правок, даже если другой тег.

kubectl apply напряжный, если поменялся тег и 50 реплик

ну раздели build и tag