ArgoCD имплементирует свою собственную модель, а группы и права доступа настраиваются в CSV-подобном формате, что неудобно использовать как-либо кроме как через веб-интерфейс.
можно это расшифровать, просто не совсем понятно, какие варианты использования имеются ввиду. Можно через kubectl увидеть те же данные, что и в гуй. можно через argocd cli провалидировать права на ресурс, все так же, как нативный рбак
Не используйте ключи с неограниченным TTL, желательно ограничить размер TTL минимально необходимым сроком жизни ключа; Используйте политику вытеснения чтобы не засорять Redis и подбирайте параметр maxmemory-policy в зависимости от структуры базы и частоты обращения к ключам;
Зависит от специфики работы, иногда стоит запретить удалять что-то из бд силами редиса, во избежание получаения неприятных последствий.
Старайтесь снимать RDB дампы с боевой базы как можно реже, если объем базы более нескольких гигабайт. Для создания RDB используется операция fork в основном потоке, что может вызвать заметную задержку в работе инстанса Redis. Лучшее решение — поднятие мастер - слейв репликации и снятие бэкапа со слейва.
но если очень хочется и нет слейва, то только через команду `BGSAVE` , чтобы не блокировать работу редиса в момент снятия дампа. Так же сам редис просит включить механизм copy-on-write, для снижения потребления памяти.
RedisInsight - не умирает на больших размерах БД(от 50Гб) и ключах( от 100 млн)?
А так, интересная статья, добавлю в закладки, чтобы кидать тем, кто хочет познать дивный мир редиски
там выше было предложено отключить BGREWRITEAOF и BGSAVE ,SAVE поэтому про персистентность можно забыть) В статье так же не сказано, что при перезапуске мы теряем все данные, что будет неприятным сюрпризом для новичков, что по этой статье запустят редиску в прод ( и такое бывает)
сам недавно развлекался с мультимастером, итог примерно тот же, если инстансов 2, то мультимастер худо бедно работает, при увеличении инстансов начинаются чудеса. в итоге так и остался на схеме keydb + sentinel
Кстати, не увидел описание фичи мультимастера: если одна из реплик отвалилась и подключилась, то она запрашивает у остальных набор ключей, что вроде бы логично, но самое интересное, что потом старые реплики запрашивают у "поднявшейся" реплики ее набор ключей и синхронизируют со своими, и в этот момент становятся недоступны для клиентов.( с ошибкой Database loading)
опечатка.
при использовании kube-virt как-то проводили тестирование на сети, не упираетесь в пропускную способность свича гипервизора ?
да, а rbac легко можно описывать в репе. в helm chart есть для этого параметр
соотвественно сразу видно история изменений рбака.
так это подразумевается по-умолчанию, раз речь о гит-опсе, то логично, что аргосд следит за самим собой и обновляется при изменении репы
можно это расшифровать, просто не совсем понятно, какие варианты использования имеются ввиду. Можно через kubectl увидеть те же данные, что и в гуй. можно через argocd cli провалидировать права на ресурс, все так же, как нативный рбак
кто-то решил хабр использовать как свой сервер заметок )
Так это, а где соурс код для СДЕКа?)))
а почему нет сравнения с rust, но при этом есть сравнение с c++?
Загуглил, открыл...Я не дизайнер, но у меня от такого чет кровь полилась из глаз)
добавьте ваш манифест с прометеем в статью тогда уж )
это хорошо, только прометея нет в чарте с графаной, потому с 0 этот мега чарт не сможет развернуться
Зависит от специфики работы, иногда стоит запретить удалять что-то из бд силами редиса, во избежание получаения неприятных последствий.
но если очень хочется и нет слейва, то только через команду `BGSAVE` , чтобы не блокировать работу редиса в момент снятия дампа. Так же сам редис просит включить механизм copy-on-write, для снижения потребления памяти.
RedisInsight - не умирает на больших размерах БД(от 50Гб) и ключах( от 100 млн)?
А так, интересная статья, добавлю в закладки, чтобы кидать тем, кто хочет познать дивный мир редиски
любой курс линукс администратор. В каждом есть описание работы с файловой системой
https://habr.com/ru/articles/471038/
на мой взгляд лучшее описание, что я встречал
там выше было предложено отключить
BGREWRITEAOF
иBGSAVE
,SAVE
поэтому про персистентность можно забыть)В статье так же не сказано, что при перезапуске мы теряем все данные, что будет неприятным сюрпризом для новичков, что по этой статье запустят редиску в прод ( и такое бывает)
Если указать версию чарта через вайлдкарт типа 1.0.*
То арго сд проверит чарт на наличие новой минорной версии и сделает приложение OutOfSync если такая имеется
А чем вы в кубере раскатываете кейдб? где-то можно посмотреть манифест из Истории2?
мы используем в проде уже год, с версии 0,5.*, ни одного ложного срабатывания.
про шелл-оператора не понял.
и ниже
то есть секрет все равно надо создавать, но с определенной аннотацией. Тогда в чем смысл?
Далее
почему б не заменить на
kubectl apply ... ?
сам недавно развлекался с мультимастером, итог примерно тот же, если инстансов 2, то мультимастер худо бедно работает, при увеличении инстансов начинаются чудеса. в итоге так и остался на схеме keydb + sentinel
Кстати, не увидел описание фичи мультимастера:
если одна из реплик отвалилась и подключилась, то она запрашивает у остальных набор ключей, что вроде бы логично, но самое интересное, что потом старые реплики запрашивают у "поднявшейся" реплики ее набор ключей и синхронизируют со своими, и в этот момент становятся недоступны для клиентов.( с ошибкой Database loading)
это как? мастер и 2 слейва? а если мастер упадет?
hugepages включены?
tcp стек тюнили?