Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы. А то, что кто то сделал слияние сервисов через Ж, никак ни подход, ни технологии под капотом не дискредитируют.
И да, заголовок статьи вводит в заблуждение. Когда пишут «SSO» на тех. ресурсе, о сбере я подумаю в последнюю очередь.
Какое же это ретро? Я же практически вчера почти такой же дружил с принтером на дому авторитетному человеку после школы. А хотя, это же сколько уже лет то прошло…
Всегда пожалуйста :) А коллеги Ваши как нибудь прокомментировали? Просто очень нравиться идея CDC прям из wal для критичных event-source систем. Но пару таких подводных камней смущает.
мы с свое время из-за этого использовали его только с базами с блочной репликацией дисков между мастром и standby.
p.s. в patroni с 2.1 вроде как завезли механизм failover logical slots (прокси не дает подключиться клиентам к базе, пока не пересоздаст все слоты), но это решает только половину проблемы. А если debezium не успел дочитать транзакции до конца с мастера, а реплика успела, то опять эти транзакции не попадут в слот и, соответственно, Debezium их проскочит.
Если я правильно понял, то source для CDC у вас Postgres? Если так, то расскажите пожалуйста как справляетесь с переносом replication slot'а для debesium на новый мастер при падении базы?
Т.е. Вы наивно выключили проверку, не разобравшись зачем тут она была, не задали вопрос разработчикам в открытом проекте на Github, пошли с этим в HiLoad продакшн и надеетесь что все будет хорошо?
То ли я старею, то ли этот мир несется куда то не туда...
Спасибо за статью. Тоже приходилось решать похожую задачу. Единственное, специально отключил динамические пулы в fpm: не думаю что они полезны в подах. Если вы определяете limits/requets ресурсов по памяти, то помоем лучше сразу ставить столько, сколько влезает в под. Постольку fpm не шарит ресурсы с другими, как в случае настоящего сервера, то и смысла расти а потом сжиматься динамически особо нет. Плюс мониторинг проще.
p.s. Интересно было бы еще добавить подтему мониторинга: на какие метрики и для чего смотрите а первую очередь.
Managed k8s часто имеют неприятные Нюансы, которые хоть и упомянуты в доках (часто вскользь, зачем пугать людей?), но кто же внимательно их сразу читает. И тут начинается самое веселье. Напр из AWS EKS: нельзя свой CNI, иначе webhooks придется делать на hostport, раньше было ограничение pod-per-node из-за особенности работы их eni (сейчас можно выделять IP ноде сразу подсетями). И такие wtf встречаются не редко.
Так же managed не всегда упакован всем необходимым набором (cert-manager, coredns, mesh, monitoring, и тд), а из моего опыта поддержка всего этого набора и занимает основное время ухода за кубером. Так что в итоге все равно собираешь свой дистр. Радует правда, что в последние время с этим становиться лучше.
Из жирных плюсов managed - часто широкая и хорошо работающая интеграция с остальными сервисами внутри провайдера. Ну и саппорт, особенно при обновлениях (напр в интерфейсе у того же EKS сразу пишут какие манифесты сломаются после апдейта).
Перейдем на оптику
Что у Вас под капотом, knative или что-то другое?
Какой прокси гейтвей, можно ли его как то настроить (CORS, хедеры и т.д.)?
Можно ли со своим доменом?
Что с сетевыми метриками и логами запросов?
Есть ли автоскейлинг и по каким метрикам его можно настроить?
Есть ли постоянные тома хранилища, снепшоты, резервное копирование?
Есть ли версионирование деплоев? Можно ли откатиться по кнопке?
Будет ли техническая документация?
Тащите все в SSO. Аунтификацией должны заниматься специализированные под это сервисы. А то, что кто то сделал слияние сервисов через Ж, никак ни подход, ни технологии под капотом не дискредитируют.
И да, заголовок статьи вводит в заблуждение. Когда пишут «SSO» на тех. ресурсе, о сбере я подумаю в последнюю очередь.
А в продакшене используйте специализированные средства: consul-template, ansible и т.д.
Какое же это ретро? Я же практически вчера почти такой же дружил с принтером на дому авторитетному человеку после школы. А хотя, это же сколько уже лет то прошло…
здесь автор имеет ввиду serverless functions и проводит примеры на AWS Lambda
любой на несимметричных ключах, напр. RSA - https://ru.wikipedia.org/wiki/RSA
Продаст на Ebay как слегка подержанный
И как можно было забыть про Metabase?
Mimir неплох, но имеет пару жирных минусов:
нет управления rules и alerts из CRD (только свое api)
довольно прожорливый на ресурсы
нет downsampling для исторических данных, а если попытаться сделать его на rules, то можно разориться s3
Всегда пожалуйста :) А коллеги Ваши как нибудь прокомментировали? Просто очень нравиться идея CDC прям из wal для критичных event-source систем. Но пару таких подводных камней смущает.
deleted
Ну вообще-то нет. Точнее слот то создаться, но с новым счетчиком транзакций. И дальше все зависит от стратегии подключения Debezium (то что конфигурируется через
snapshot.mode) , или от того что произойдет раньше: новый коммит транзакции, которая не попадет уже в CDC или создание слота. Подробнее тут: https://debezium.io/documentation/reference/2.4/connectors/postgresql.html#postgresql-cluster-failuresмы с свое время из-за этого использовали его только с базами с блочной репликацией дисков между мастром и standby.
p.s. в patroni с 2.1 вроде как завезли механизм failover logical slots (прокси не дает подключиться клиентам к базе, пока не пересоздаст все слоты), но это решает только половину проблемы. А если debezium не успел дочитать транзакции до конца с мастера, а реплика успела, то опять эти транзакции не попадут в слот и, соответственно, Debezium их проскочит.
Если я правильно понял, то source для CDC у вас Postgres? Если так, то расскажите пожалуйста как справляетесь с переносом replication slot'а для debesium на новый мастер при падении базы?
Т.е. Вы наивно выключили проверку, не разобравшись зачем тут она была, не задали вопрос разработчикам в открытом проекте на Github, пошли с этим в HiLoad продакшн и надеетесь что все будет хорошо?
То ли я старею, то ли этот мир несется куда то не туда...
Спасибо за статью. Тоже приходилось решать похожую задачу. Единственное, специально отключил динамические пулы в fpm: не думаю что они полезны в подах. Если вы определяете limits/requets ресурсов по памяти, то помоем лучше сразу ставить столько, сколько влезает в под. Постольку fpm не шарит ресурсы с другими, как в случае настоящего сервера, то и смысла расти а потом сжиматься динамически особо нет. Плюс мониторинг проще.
p.s. Интересно было бы еще добавить подтему мониторинга: на какие метрики и для чего смотрите а первую очередь.
Поиграем в найди отличие?
Я честно пытался уследить за мыслю, но так и не понял
откуда взялся DAG?
в начале сказано, что скрипт запускается DAG'ом, но он упаковывается в контейнер под python:alpine?
если контейнер запускает PodOperator (судя по логу), то где лежат pod template и, если нужны, остальные артифакты пода?
что с авторизацией airflow -> k8s, gitSync -> repo?
и ключ улетел в клиента. конкуренты скажут спасибо за лиды
Managed k8s часто имеют неприятные Нюансы, которые хоть и упомянуты в доках (часто вскользь, зачем пугать людей?), но кто же внимательно их сразу читает. И тут начинается самое веселье. Напр из AWS EKS: нельзя свой CNI, иначе webhooks придется делать на hostport, раньше было ограничение pod-per-node из-за особенности работы их eni (сейчас можно выделять IP ноде сразу подсетями). И такие wtf встречаются не редко.
Так же managed не всегда упакован всем необходимым набором (cert-manager, coredns, mesh, monitoring, и тд), а из моего опыта поддержка всего этого набора и занимает основное время ухода за кубером. Так что в итоге все равно собираешь свой дистр. Радует правда, что в последние время с этим становиться лучше.
Из жирных плюсов managed - часто широкая и хорошо работающая интеграция с остальными сервисами внутри провайдера. Ну и саппорт, особенно при обновлениях (напр в интерфейсе у того же EKS сразу пишут какие манифесты сломаются после апдейта).