Здравствуйте. Подскажите пожалуйста. Мы идем к continous integration и сейчас я занимаюсь реализацией автоматического развертывания тестового окружения под каждую фичу. Я сделал чтобы под каждый pr развертывался свой deployment в рамках одного service. Но щас понял, что это может быть неверно. Какой подход будет более правильный? Развёртывание по сервису на каждую фичу?

Правильный подход namespace на фичу+проект, а туда уже продукт деплоить с короткими лаконичными именами типа service

ну то есть я такой пишу kubectl apply -f kubernetes-cluster.yaml а оно мне куб поднимает

Для AWS мелкало парочку https://github.com/giantswarm/aws-operator

Коллеги, а почему делать миграции через initContainer это плохо?

Коллеги, а почему делать миграции через initContainer это плохо?

Можно несколько параллельно запуститься

Иногда это не очень хорошо

Как вы катите миграции? И выполняете ли автоматический откат оных при фейле деплоя с новой версией приложения?

Через инит контейнер где-то, где-то через хельм хук, где-то через entrypoint

Больше интересует автоматический откат миграций - я склоняюсь к "руками" , типо это не штатный кейс

Больше интересует автоматический откат миграций - я склоняюсь к "руками" , типо это не штатный кейс

Хуками хельма можно, но вариант с руками мне больше нравится )

Больше интересует автоматический откат миграций - я склоняюсь к "руками" , типо это не штатный кейс

Так пишите скрипты которые откатываются при фейле и в хельм запихивайте

Как вы катите миграции? И выполняете ли автоматический откат оных при фейле деплоя с новой версией приложения?

liquibase

Обычно миграции обратно совместимые и проще руками как правило (вообще за последний год ни разу не приходилось откатывать)

В худшем случае EFM

Обычно миграции обратно совместимые и проще руками как правило (вообще за последний год ни разу не приходилось откатывать)

Ну и это тоже

Обычно миграции обратно совместимые и проще руками как правило (вообще за последний год ни разу не приходилось откатывать)

Я собственно за это и топил сегодня ..

Потмоу и "руками" =)

Я собственно за это и топил сегодня ..

Если по поводу миграций говорят разрабы

Посылай их нахуй

Тебе виднее как правильно накатывать

Если ты дба конечно)

Если по поводу миграций говорят разрабы

Разрабы ниче не придумали, руководитель пришел ко мне =\

Спасибо, друзья, вы дали мне ответы на мои вопросы)

Спасибо. Разобрались)

ждём отзывов

ждём отзывов

Отпишемся по результатам тестирования

Народ как думаете пригодилась бы актуальная статья по установке GlusterFS в кластер кубернетеса?

(из моего недельного гуглежа, ничего толкового не нашел ни в ru ни в us )

хм, вроде было не супер сложно

хм, вроде было не супер сложно

Вот и я о том же

А вылезла куча косяков

на определенных этапах

Пригодится конечно. Главное её достоинство будет в свежести информации

Тогда на днях набросаю статейку, лишним думаю не будет

Пусть она не будет большой, но комментарии типа "вот в этой статье все хорошо, но в 2014 было так-то, а в 2019 изменилось и стало этак-то" дорого стоят

Ребят, есть задачка проходиться по подам в пяти k8s кластерах и собирать через stdin статистику (количество игроков на сервере и их пинги, эту инфу можно достать, введя команду "status" в консоле игрового сервера), а дальше лить ее в какой-нибудь prometheus. Как лучше всего это сделать? в каждом таком поде размещать сайдкаром контейнер с общим неймспейсом, который собирает метрики? Или же daemonset'ом на все кластера раскатать скрипт, который будет запущен в глобальном неймспейсе и все процессы будет опрашивать через stdin?

Научить свой сервис отдавать метрики по прометеус протоколу и не сакме себе и людям мозг

Научить свой сервис отдавать метрики по прометеус протоколу и не сакме себе и людям мозг

Если бы это было возможно, я бы так и сделал и не обмазывался говном

спасибо кэп)

В подах запускаются бинарники, от которых нет исходников

В подах запускаются бинарники, от которых нет исходников

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

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

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

автор — Valve )

я думаю вы знаете кто это такие)

Пили экспортер со стороны и пускай сайдекаром в поде и страдай

сайдкар идеальный вариант

Парсить stdin - ещё что-то на Панина гонят

Парсить stdin - ещё что-то на Панина гонят

а что еще делать?)

автор — Valve )

вы что ли сервера контры запихнули в кубер?

вы что ли сервера контры запихнули в кубер?

конечно)

и живем вполне себе с этим)

кек

суперудобно)

fastcup.net

че уже "Exposes statistics read from local disk. The --collector.textfile.directory flag must be set." readnes вызывает этот скритп по nc передает в сайдкар

конечно)

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

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

— повторяемость (докер) — удобно развернуть на нашу пачку кластеров по всей европе обновление игрового сервера разом (скачивается только дифф) — удобство обслуживания — шедулинг

диски не используем кластерную сеть не используем

куб по сути как шедулер используется)

ну и апишка куба удобная

прогать вокруг чистого docker api было впадлу

свой шедулинг нет смысла писать, когда есть куб)

круто

в нас много кто кидался яйцами по поводу этого

но как оказалось вполне себе приятно

— повторяемость (докер) — удобно развернуть на нашу пачку кластеров по всей европе обновление игрового сервера разом (скачивается только дифф) — удобство обслуживания — шедулинг

А занимаетесь выкатыванием на несколько регионов?

А занимаетесь выкатыванием на несколько регионов?

пока в пределах одного материка

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

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

учитывая что игровые серваки — stateful, то такое себе)

у нас все деплойменты с replicas: 1

юзаем calico, выдаем подам внешние айпишники, каждому поду свой а также metallb, который по l2 анонсит

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

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

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

и они будут ждать пока сработает failover пода, переезд на другую ноду

и после поднятия у них раунд заново начнется

ну так если через ansible катать каокй-нибудь, то это будет менее удобно

ну это да)

с сетью классно нам ребята сделали из Exon Labs

у нас вообще udp-трафик игровой сразу же на ту же ноду попадает и сразу же в под

без оверлейных сетей

почему сами куб собирали? потому что нужен антиддос на уровне UDP L7 и серваки с 4.5-5ггц i7/i9 процами

в облаке такого нет) да и ценники за исходящий трафик ад, а у нас его дофига