репа поменялась, а 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

и делай tag по условию

да нет, мне просто нужно делать if что текущий рабочий image отличается от собранного только тегом. Внутри все одинаковое.

Ладно, сделаю - расскажу.

Работа прилетела

ну есть некий docker diff

да, и какой-то sha256 у image... что-то в этой стороне. Курить доки нужно. Должно быть просто.

не, дифф это не то

@docker_ru какой-то

https://github.com/GoogleContainerTools/container-diff вот это наверное

можно и просто сравнив json'ы манифестов для этих тегов

тоже верно

да нет, мне просто нужно делать if что текущий рабочий image отличается от собранного только тегом. Внутри все одинаковое.

пробуй в манифесте указывать sha256 напрямую, без тега

https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier

+ в догонку https://docs.docker.com/config/labels-custom-metadata/

Ребят, кто настраивал bgp между calico и другими маршрутизаторами? Есть какой-то туториал? Заведётся оно с quagga?

заведётся

ну если в квагге бгп включить конечно

а почему квагга? или это не твой выбор?

в калико внутри обычный bird и обычный bgp

а почему квагга? или это не твой выбор?

Ну я тока с ней просто сталкивался. Так то не сетевик ни разу)

Главное - лишнего не заанонсить кластеру.

Главное - лишнего не заанонсить кластеру.

Мне наоборот, надо с кластера вытянуть)

Чтоб поды были доступны в локалке. Чтобы их мониторить прометеем без федерации

Мне вот bird понравился, квагга как-то неочевидно. А бёрд прям хорош и прост, и фильтры всякие развесистые умеет.

плюсую bird

У меня даже пример конфига найдётся, если нужно. Ну и в контейнере с calico можно посмотреть.

Кстати, калико сеть сервисов не умеет анонсить, это пока только kube-router может.

Для этого ipvs есть

Не то же самое конечно, но вполне рабочий варант

Для этого ipvs есть

Он балансит же.

А я про анонс на роутер самого факта наличия сети сервисов.

Ну или отдельных clusterip.

Я про то что kube-proxy вполне успешно без kube-router распространяет информацию про сервис адреса

Да, между нодами кластера, а во внешние сети?

Зачем анонсить сервисные адреса наружу?

а тут по-моему про адреса подов

Ну мне надо именно адреса подов. У меня поды умеют в /metrics для прометея. Было несколько вариантов, типо федерации, проксятника и BGP. Вроде коллективным разумом чатов телеграма пришел к выводу что BGP самый оптимальный вариант

А кто тебе мешает прометея просто сунуть внутрь кластера?

А кто тебе мешает прометея просто сунуть внутрь кластера?

Ну тут архитектурно так сложилось что он стоит сбоку, не в кубере. И засовывать его туда не хоцца

@azalio это не у тебя так?

ну у меня так да

прометей стоит сбоку

адреса подов доступны по всей сети

а начем сеть?

Ну тут архитектурно так сложилось что он стоит сбоку, не в кубере. И засовывать его туда не хоцца

А почему не хочется-то?

Проще всего на каждый кубокластер держать по своему прометею имхо

а начем сеть?

на calico

А почему не хочется-то?

ну для него сторедж надо делать и всякую такую обвязку. А сейчас все просто и примитивно. В кубере только stateless. Случилось се с серваком, выкинул, поставил новый, работаем дальше)

Проще всего на каждый кубокластер держать по своему прометею имхо

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

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

У тебя федерация или просто 2 разных прометея?

У тебя федерация или просто 2 разных прометея?

я еще не поднял, думаю будет 2 разных.

Зачем анонсить сервисные адреса наружу?

Ну вот есть большая сеть предприятия. И есть в ней кластер кубернетеса с двумя сетями маленькими - сетью подов и сетью сервисов. Первую мы анонсим роутерам в нашей большой сети, и вся сеть может ходить на айпишники подов. То же самое и с сетью сервисов, анонсим сеть сервисов, и вся сеть может ходить на айпишники сервисов.

что от этого анонса будет - я понимаю

вопрос был "зачем"

Чтобы из сети предприятия были маршруты до сети сервисов. А почему это вопросы вызывает?

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

логичнее того же ингресса?

Ну а почему нет?

Да и задачи разные бывают.

смотря как это делать

ну понятно что в каких-то кейсах это норм будет

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

например того же ингресса

А как получить программным путем подсеть выделеную для ноды? (без kubectl)

взять netmask c интерфейса?

у меня нет

у меня нет

Сеть калико?

Сеть калико?

ага

Ну, можно в calicoctl node чётотам посмотреть.

run Run the Calico node container image. status View the current status of a Calico node. diags Gather a diagnostics bundle for a Calico node. checksystem Verify the compute host is able to run a Calico node instance.

# calicoctl node status Calico process is running. IPv4 BGP status +--------------+-----------+-------+----------+----------------------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +--------------+-----------+-------+----------+----------------------------+ | 10.8.43.2 | global | down | 14:21:06 | Error: No listening socket | | 10.8.43.3 | global | down | 14:21:06 | Error: No listening socket | | 10.8.43.4 | global | down | 14:21:06 | Error: No listening socket | | 10.8.43.5 | global | down | 14:21:06 | Error: No listening socket | +--------------+-----------+-------+----------+----------------------------+