ещё вопрос: может кто знает способ прикрепления руками сгенерерированных wildcard-сертификатов (certbot) к кубику? пример: 1) есть домен example.com 2) есть wildcard-сертификат для него 3) есть куча сервисов с поддоменами типа app1.example.com, app2.example.com

ок, принято

ещё вопрос: может кто знает способ прикрепления руками сгенерерированных wildcard-сертификатов (certbot) к кубику? пример: 1) есть домен example.com 2) есть wildcard-сертификат для него 3) есть куча сервисов с поддоменами типа app1.example.com, app2.example.com

я подозреваю что вам нужен ingress+cert-manager

ещё вопрос: может кто знает способ прикрепления руками сгенерерированных wildcard-сертификатов (certbot) к кубику? пример: 1) есть домен example.com 2) есть wildcard-сертификат для него 3) есть куча сервисов с поддоменами типа app1.example.com, app2.example.com

Я вот так ставил серт для дашборда например с ингрессом и сертманагером, может чем-то поможет https://paste.ubuntu.com/p/Q7yGPjBcDC/. Правда тут не вайлдкарт, но все же.

немного оффтоп https://coreos.com/blog/fedora-coreos-red-hat-coreos-and-future-container-linux

Да была новость еще пару недель назад по этому поводу.

Не знаю какие ещё слова подобрать, утилизировал он свой максимум. Он такое может

Влезу с традиционным редис не персистенс. Откуда растет требование и действительно ли так нужно взять именно самый быстрый движок?

важно. важен быстрый ответ, поэтому на вопрос предыдущего автора даже глупо отвечать - redis - это про in-memory, а постгрес про транзакции, контроль целостности и это все.

Понял) то есть посгрес пока тянет, потом думать)

Ничего, что редис работает в 1-процессорном режиме ? Там есть пара случаев, когда он второй проц использует. вопрос кубер или нет зависит строго от: 1. Насколько критична потеря данных редиса - то есть насколько нужна персистентность 2. Сколько у вас там IO 3. Что мешает пойти путём, рекомендуемым вендором и поднять кластер ?

Но пробовать похоже буду https://github.com/voldemort/voldemort/blob/master/README.md

привет. Ребят, кто-то пользовался kubespray для разворачивания кластера локально (Vagrant)? Вопрос такой, есть ли возможность его потушить (vagrant halt) а потом о5 возобновить?

чем миникуб не вариант?

а чем это лучше монги? Вы бы написали конкретные требования на чтение/запись чтобы можно было говорить предметно. Да и редис с персистентом или в кластер режиме возможно тоже имеет право на жизнь для вашей задачи - но нужно понять саму задачу

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

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

да если бы

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

Кстати, по монге ДБА случаем не завалялся?

всем известно что монга - это просто "засунул данные и всё работает"

@SvPupok сюда пиши

реплика-сет же! какие еще шарды

какой ещё ключ шардирования

можно читать с реплик же!

можно читать с реплик же!

Товарищ,больше 150 гб данных и твоему RS-у на виртуалках хана. На железе проживёт чутка дольше

я бы на 1 тб ставил по опыту даже на виртуалках. Хотя смотря чё по схд снизу вопрос. Ну и смотря какой наркоман проектировал схему хранения.

Программист.

а вдруг он читал как работает монга и её двигло?

Товарищи, а что редактировать в RBAC дабы избежать : Error: error installing: deployments.extensions is forbidden: User "system:serviceaccount:gitlab-managed-apps:default" cannot create deployments.extensions in the namespace "gitlab-managed-apps"

у роли должно быть право на create extensions

у роли должно быть право на create extensions

Толи я дурак, толи в RBAC я её не вижу

Товарищ,больше 150 гб данных и твоему RS-у на виртуалках хана. На железе проживёт чутка дольше

Хмм 2.2тб данных в репликасете-стейтфулесете в кубе, уже года этак полтора, брат жив