отож. Но вдруг будет рациональное зерно

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

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

платить я не буду, я и так сотрудник

платить я не буду, я и так сотрудник

А наши платят))

А наши платят))

интересно. А вас случайно не будет в Спб 17го марта? Я бы пособирал фидбек

Нет я московский житель) А приглашение мне не присылали ни какое) Да и поверь мы платим не только за ОС) у нас весь прод на RHEL

ну кто-то из наших поедет на голангкон, может ему будет интересно

спасибо, но по мне — много букв

ещё без tini на чистом баше можно вот так сделать trap 'kill ${!}' SIGHUP SIGINT SIGQUIT SIGABRT SIGKILL SIGALRM SIGTERM # run application node program & pid="$!" # wait forever while true do tail -f /dev/null & wait ${!} done

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

а нельзя было wait forever как-нибудь по-другому сделать?

без tail -f /dev/null хотя бы

А наши платят))

а у нас мало того что не платят так еще запускают опенщит на убунте, вместо энсибл запилили свои папет модули еще и вместо devicemapper дефолтный перешли на overlayfs2

последнего не могу не одобрять

и потом удивляются почему никто не хочет на это переходить...

без tail -f /dev/null хотя бы

так я же кидал свой пример выше while :; do <run command> log "Sleep 5 seconds" sleep 5; done

а чо просто cat на запустить без аргументов?

без циклов и без слипов

вместо kill ${!} само собой exit 0

так вроде задача была что-то запускать все время в цикле?

в цикле разве?

с виду надо просто чтобы контейнер жил и в нём вызовом exec снаружи делаются какие-то действия

нет, можно без цикла

в смысле цикл вообще только нужен потому что не во всех sleep есть infinity

ну и слип не ловит TERM (или ловит, но не получает)

ловит он term

ну тогда tail -f несуществующего файла например, или любой другой процесс который не выйдет сам

проблема в том, что если он в цикле и без set +e, то он просто перезапустится

если в цикле висит

проблема в том, что если он в цикле и без set +e, то он просто перезапустится

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

точно?

кроме самого кубернетеса, который отправит ему TERM, но тогда он и не перезапустится

с виду надо просто чтобы контейнер жил и в нём вызовом exec снаружи делаются какие-то действия

а можешь поподробнее объяснить юзкейс?

Так вон же описали

а то какое-то костылестроение

Не мой кейс, а коллеги из этого чата

Привет всем. А как вы решаете такую проблему с helm: нужно, чтобы приложение (чарт), устанавливался обязательно в определенный неймспейс. Указывать его через параметр —namespace не особо хочется, ибо всегда есть человеческий фактор, возможность очепятаться и тд. Создавать неймспейсы через шаблоны, как я понял, считается плохой практикой. А хочется, чтобы по умолчанию был указан неймспейс отличный от default. Продукт коробочный, чарты потом отдаются клиенту, хочется предоставить максмум конфигурации из коробки. Что посоветуете?

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

Пользователь запускает свой под со своими контейнерами. Помимо пользовательских контейнеров в каждом таком поде должен быть служебный контейнер. Он собран таким образом, что содержит определенные инструменты, которые периодически вызываются через exec. То есть там нет процесса, который должен быть запущен, а без такого процесса контейнер, как известно, жить не может. Вот я и пытаюсь создать такой процесс. Да, это напоминает существующий pause контейнер.

"Он собран таким образом, что содержит определенные инструменты, которые периодически вызываются через exec" вот тут непонятно, почему через exec? все контейнеры внутри одного пода шарят network namespace и т.д. - пусть контейнер запускае все внутри себя же

кронтабом или в цикле

а что юзер делает в своем контейнере и что у него там в качестве инит процесса - это уже его отвественость?

> почему через exec? пусть контейнер запускае все внутри себя же потому что контейнер не знает по какой логике ему надо это запускать, этим занимается внешний контроллер > а что юзер делает в своем контейнере и что у него там в качестве инит процесса - это уже его отвественость? да

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

Нет, это не для большой, в опенсорс выкладываться не будет. Кейс. наш продукт я логически разделил на два слоя: зависимости (базы данных, очереди, кафки вот это все) и собственно сами приложения. Приложения - это кучка микросервисов, которые устанавливаются в дефолтный неймспейс, где ими удобней оперировать целиком в случае чего. И вот, в приложения передается адрес бд, например, по которому оно и стучится в оную. Зависимости же у меня ставятся в отдельные неймспейсы. И вот как обеспечить вот эту конфигурацию по умолчанию, чтобы можно было сделать helm install -f ./db и оно было в ожидаемом неймспейсе (недефолтном)?

> почему через exec? пусть контейнер запускае все внутри себя же потому что контейнер не знает по какой логике ему надо это запускать, этим занимается внешний контроллер > а что юзер делает в своем контейнере и что у него там в качестве инит процесса - это уже его отвественость? да

тогда имхо идеалогически правильнее взять гугловский pause как базовый контейнер и внутрь его поставить нужные тулзы

он будет норм хендлить сигналы и т.д.

Нет, это не для большой, в опенсорс выкладываться не будет. Кейс. наш продукт я логически разделил на два слоя: зависимости (базы данных, очереди, кафки вот это все) и собственно сами приложения. Приложения - это кучка микросервисов, которые устанавливаются в дефолтный неймспейс, где ими удобней оперировать целиком в случае чего. И вот, в приложения передается адрес бд, например, по которому оно и стучится в оную. Зависимости же у меня ставятся в отдельные неймспейсы. И вот как обеспечить вот эту конфигурацию по умолчанию, чтобы можно было сделать helm install -f ./db и оно было в ожидаемом неймспейсе (недефолтном)?

зависимости в отдельные неймспейсы - это же вроде идеологически неверно

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

а зачем вы разносите в отдельные неймспейсы зависимости, что это дает?

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

тогда имхо идеалогически правильнее взять гугловский pause как базовый контейнер и внутрь его поставить нужные тулзы

я вобщем-то тоже так подумал, но потом посмотрел в этот си код, и мне показалось, что он делает больше, чем просто заканчивает работу по SIGTERM. Что именно я особо не понял и это меня остановило.

а зачем вы разносите в отдельные неймспейсы зависимости, что это дает?

ну как минимум нет свалки. У нас в дефолте только 15 основных микросервисов. Ими удобно было оперировать в рамках одного неймспейса, например, задать resourse requests, скейлить их (сейчас понимаю, что скейлить можно и по лейблам) и просто мониторить.

ну или рабочее-крестьянский вариант на баше: trap 'exit 0' SIGHUP SIGINT SIGQUIT SIGABRT SIGKILL SIGALRM SIGTERM while :; do sleep 60; done

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

ну как минимум нет свалки. У нас в дефолте только 15 основных микросервисов. Ими удобно было оперировать в рамках одного неймспейса, например, задать resourse requests, скейлить их (сейчас понимаю, что скейлить можно и по лейблам) и просто мониторить.

так вы не ставьте в дефолтный

ставьте в отдельные неймспейсы по проектам

кстати, а сколько у вас таких кластеров что нужно защищаться от человеческой ошибки?

у нас в чем-то похожая ситуация, в кластере одно и то же приложение установлено несколько раз в разных неймспейсах: sitecode1 sitecode2 ...

ну как минимум нет свалки. У нас в дефолте только 15 основных микросервисов. Ими удобно было оперировать в рамках одного неймспейса, например, задать resourse requests, скейлить их (сейчас понимаю, что скейлить можно и по лейблам) и просто мониторить.

не знаю как "два неймспеса" удобнее чем "один лейбл", с учетом того что все тулзы заточены под "одно приложение - один неймспейс" - например helm

с помощью direnv сделано что когда заходишь в терминале в папке с проектом в подпапку sitecode1 то устанавливается через переменную окружения нужный неймспейс, имя кластера, авс регион и т.п.

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

кластер может быть и один. Просто может возникнуть ситуация, что бд, к примеру, поставят не в тот неймспейс, и тогда основные приложения не заведуться, упадут с ошибкой подключения. Ну, например, в приложение предается адрес базы db-0.db-svc.db-ns. Админ на стороне заказчика или я ставлю по ошибке бд в bb-ns. Конечно, ситуация может быть утрированная и я слишком с этим заморачиваюсь. Пока новичок в этом деле.

не знаю как "два неймспеса" удобнее чем "один лейбл", с учетом того что все тулзы заточены под "одно приложение - один неймспейс" - например helm

а что вы понимаете под «приложением»? ВП + мускул, например, или один модуль системы?

а что вы понимаете под «приложением»? ВП + мускул, например, или один модуль системы?

весь набор модулей

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

с помощью direnv сделано что когда заходишь в терминале в папке с проектом в подпапку sitecode1 то устанавливается через переменную окружения нужный неймспейс, имя кластера, авс регион и т.п.

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

и не боитесь задеплоить в прод вместо дева?

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

не совсем так, есть один дев кластер и 4 прод кластера. в каждом прод кластере установленно несколько копий приложения для разных стран, в дев кластере тоже несколько дев копий для разных стран

крутится все в aws в 3 разных регионах, кластеры сами по себе небольшие (до 8 воркер нод)

деплоится оно везде само через CI/CD, вручную хелмом можно продеплоить конкретную версию для конкретной инсталляции если надо

как-то так

кластер может быть и один. Просто может возникнуть ситуация, что бд, к примеру, поставят не в тот неймспейс, и тогда основные приложения не заведуться, упадут с ошибкой подключения. Ну, например, в приложение предается адрес базы db-0.db-svc.db-ns. Админ на стороне заказчика или я ставлю по ошибке бд в bb-ns. Конечно, ситуация может быть утрированная и я слишком с этим заморачиваюсь. Пока новичок в этом деле.

тут явный бок как по мне что приложение ходит в другой неймспейс в базу

логичнее сделать чтобы в неймспейсе приложение и все его зависимости: namespace=app_name - app_name - deployment(s) - mysql - statefulset - redis - statefulset ...

Спасибо большое, стало понятней. Неправильно понял саму идеалогию нейспесов. Значит 1 неймспейс - 1 приложение (гео-зона и тд),а выборку делать по лейблам.

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

контрольный вопрос - что у меня входит в проект? вот это и пихаю в один неймспейс

конечно если приложение всего одно (и одна инсталляция) то и неймспейс выйдет один

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

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

под выборкой понимаю, например, выборку микросервисов, написанных нами (то есть, без бд и прочих зависимостей). Сейчас они лежат в дефолте. Монга в своем неймспейсе, мускул в своем. Когда я выполняю команду kubectl get pods -n ns, я виду состояние подов из одной роли, так скажем. Это все, исходя из вашего объяснения, стоит заменить просто на выборку по лейблу, то есть kubectl get pods -l role=mongo, например.

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

И это офигенно удобно

контрольный вопрос - что у меня входит в проект? вот это и пихаю в один неймспейс

этот вопрос ставит все на свои места, записал 🙂

и не боитесь задеплоить в прод вместо дева?

тут куча вариантов: 1) разные SA для разных стендов. Забыл перелогиниться - не пушнет на прод 2) отдельные кластеры для стейджинга (на них тестовые версии в разных неймспейсах). На проде в другом неймспейсе висит прошлый конфиг с 0 подов, такой себе poor man's blue-green

Пользуясь случаем задам еще вопрос: у нас есть некоторая проблема с недостатном ресурсов для модуля. Модули написаны на джаве, еще не сильно оптимизированы. Местами жрут много процессора. Бывает, их скапливается на одной ноде по несколько штук. И когда происходит чуть более менее активная работа, они начинают жрать процессор, как я понял, нода переходит в статус NotReady (причем по ssh к ней тоже ноде подключится),переподнимаются на другой ноде, часто вешают и эту ноду и вот так по цепочке падает весь кластер. Я так понимаю, нужно прописывать всем подам ресурс реквесты, чтобы этого не происходило и распределять по нодам с помощью нодселекторов. Я пока вижу только такой выход из ситуации. Может есть что то более правильное?

тут куча вариантов: 1) разные SA для разных стендов. Забыл перелогиниться - не пушнет на прод 2) отдельные кластеры для стейджинга (на них тестовые версии в разных неймспейсах). На проде в другом неймспейсе висит прошлый конфиг с 0 подов, такой себе poor man's blue-green

по поводу второго пункта не очень понятно