Не могу не согласиться что решение спорное, но у меня не сложилось впечатления, что Opa будет легче в поддержке, видя последним релиз 2 года назад и 61 звезду на гитхабе(в Кафка репозитории)
Понимаю почему вы уделили этому внимание. Логически, должно работать с рафтом, так как в контексте acl метаданные хранятся или в zookeeper или raft (или дублируются, если кластер в процессе миграции на raft). В случае с opa, метаданных нет, вся логика на стороне opa.
Спасибо за ответ и разъяснения! Если OPA уже используется или планируется применять где-то ещё, то все становится более прозрачно. А почему выбрали "сайдкар" c opa(если я правильно понял этот момент) ? Исключительно для экономии трафика или есть заметный профит по латенси? Или дело в том, что он не поддерживает кластеризацию и таким образом вы увеличиваете доступность приложения?
Также расскажите пожалуйста про Kraft, во первых что имеется в виду? Брокер с ролью контролёр(тогда почему именно он) или любой брокер просто речь про кафку на рафте, а не зукипере? (Тогда упоминание Kraft не кажется существенным, кажется что зк и рафт в данном сценарии не имеет различий)
Strimzi интересный проект, стоит внимания, но довольно монструозный и имеет определенный порог вхождения. Я имел в виду что можно пересобрать strimzi под себя и заставить обрабатывать acl с любым кластером, даже bare metal, однако, если в этом контуре нет k8s, то затея сомнительная.
Спасибо, было интересно. Не знал что есть такое opa и статья демонстрирует хорошую инженерную культуру. В результате получилось удобное решение для работы с Kafka acl
Теперь к недостаткам, почему всего 1 альтернативный вариант?
Решение получилось, на мой взгляд, спорное, opa тут выглядит как усложнение, почему не написать свой авторайзер? Как вариант, если уж задумались об acl,которые не поддерживают rbac или группировку, то почему не использовать код генерацию для acl? Исходят из тех же топиков, уже можно сгенерить большую часть acl. И синхронизировать их тем же стримзи оператором
Если же вы не знаете какие есть топики и принципалы, то почему задумались об acl в принципе? А если речь идёт об ограничении доступа к одному топику, то можно настроить acl только там и оставить остальные без ограничений
Забыли сказать, что первые два способа - файл и база, антипаттерн в 99% случаев и не применяется в современных архитектурах. Брокеры сообщений упомянуты, но не раскрыты.
Статья ориентирована на студентов, которым предстоит сдавать зачет. Львиная часть указанных технологий уже безнадежно устарела :)
Забыли уточнить, что вендор едва ли решит ваши проблемы с высоким приоритетом здесь и сейчас. Будет выспрашивать по проблеме, заполнять какой-то баг репорт, тратить время на анализ и воспроизведение (если повезёт), но не будет забывать просить платить по счетам, ее считаясь с вашими проблемами.
Зачастую open source комьюнити работает на порядок быстрее, и проблема с которой вы столкнетесь , весьма вероятно уже будет либо решена, либо иметь воркэраунд. В худшем сценарии можно сделать форк, запатчить и пересобрать его.
Имея вендорский продукт, остаётся только пинговать вендора и надеяться на его благодушие.
Replication.factor на брокере влияет на количество реплик автоматически создаваемых топиков, что может быть недоконфигурено на начальном этапе и привести к проблемам в будущем. Например недореплицированные consumer_offsets
Спасибо большое за проделанную работу! Был зрителем двух конференций, проблемки иногда встречались, о чем я про себя ругал разработчиков, но на фоне этой истории они кажутся смешными. Желаю удачи!
Если это не плохой перевод, то что это?
И что если у нас не "зоопарк", а "плот"?
В остальном спасибо за статью, было интересно
Не могу не согласиться что решение спорное, но у меня не сложилось впечатления, что Opa будет легче в поддержке, видя последним релиз 2 года назад и 61 звезду на гитхабе(в Кафка репозитории)
Понятно, спасибо ещё раз за пояснения!
Понимаю почему вы уделили этому внимание. Логически, должно работать с рафтом, так как в контексте acl метаданные хранятся или в zookeeper или raft (или дублируются, если кластер в процессе миграции на raft). В случае с opa, метаданных нет, вся логика на стороне opa.
Спасибо за ответ и разъяснения! Если OPA уже используется или планируется применять где-то ещё, то все становится более прозрачно. А почему выбрали "сайдкар" c opa(если я правильно понял этот момент) ? Исключительно для экономии трафика или есть заметный профит по латенси? Или дело в том, что он не поддерживает кластеризацию и таким образом вы увеличиваете доступность приложения?
Также расскажите пожалуйста про Kraft, во первых что имеется в виду? Брокер с ролью контролёр(тогда почему именно он) или любой брокер просто речь про кафку на рафте, а не зукипере? (Тогда упоминание Kraft не кажется существенным, кажется что зк и рафт в данном сценарии не имеет различий)
Strimzi интересный проект, стоит внимания, но довольно монструозный и имеет определенный порог вхождения. Я имел в виду что можно пересобрать strimzi под себя и заставить обрабатывать acl с любым кластером, даже bare metal, однако, если в этом контуре нет k8s, то затея сомнительная.
Спасибо, было интересно. Не знал что есть такое opa и статья демонстрирует хорошую инженерную культуру. В результате получилось удобное решение для работы с Kafka acl
Теперь к недостаткам, почему всего 1 альтернативный вариант?
Решение получилось, на мой взгляд, спорное, opa тут выглядит как усложнение, почему не написать свой авторайзер? Как вариант, если уж задумались об acl,которые не поддерживают rbac или группировку, то почему не использовать код генерацию для acl? Исходят из тех же топиков, уже можно сгенерить большую часть acl. И синхронизировать их тем же стримзи оператором
Если же вы не знаете какие есть топики и принципалы, то почему задумались об acl в принципе? А если речь идёт об ограничении доступа к одному топику, то можно настроить acl только там и оставить остальные без ограничений
Забыли сказать, что первые два способа - файл и база, антипаттерн в 99% случаев и не применяется в современных архитектурах. Брокеры сообщений упомянуты, но не раскрыты.
Статья ориентирована на студентов, которым предстоит сдавать зачет. Львиная часть указанных технологий уже безнадежно устарела :)
Забыли уточнить, что вендор едва ли решит ваши проблемы с высоким приоритетом здесь и сейчас. Будет выспрашивать по проблеме, заполнять какой-то баг репорт, тратить время на анализ и воспроизведение (если повезёт), но не будет забывать просить платить по счетам, ее считаясь с вашими проблемами.
Зачастую open source комьюнити работает на порядок быстрее, и проблема с которой вы столкнетесь , весьма вероятно уже будет либо решена, либо иметь воркэраунд. В худшем сценарии можно сделать форк, запатчить и пересобрать его.
Имея вендорский продукт, остаётся только пинговать вендора и надеяться на его благодушие.
Id не принципиально.
Replication.factor на брокере влияет на количество реплик автоматически создаваемых топиков, что может быть недоконфигурено на начальном этапе и привести к проблемам в будущем. Например недореплицированные consumer_offsets