AK
that's enough.
я про это " пяток человек в чате тоже нифига не поняли"
Size: a a a
2021 April 03
AK
слишком категорично
VR
я про это " пяток человек в чате тоже нифига не поняли"
Если ты хочешь разбора истории - го в личку.
на 6к участников разбирать уже решённую историю - странно.
в чём цель продолжения дискуссии-то ?
на 6к участников разбирать уже решённую историю - странно.
в чём цель продолжения дискуссии-то ?
AK
Если ты хочешь разбора истории - го в личку.
на 6к участников разбирать уже решённую историю - странно.
в чём цель продолжения дискуссии-то ?
на 6к участников разбирать уже решённую историю - странно.
в чём цель продолжения дискуссии-то ?
ну уж нет, пороть, так публично. Не хочешь продолжать - перестань мне отвечать :)
SM
господа, заюзал я значит rook nfs, и чет не пойму, я должен сам запустить provisioner ? дока вообще не прозрачная
DS
кстати я тут как то хуесосил flant за верфь но всетаки такие годные статьи пишут и вообще много чего делают для компьюнити что хочется даже извиниться)
Спасибо на добром слове, мы увидели 😉🤗
AL
ребята вот если у вас куберок распирает от недостатка ресурсов какие делаете приседания чтоб как-то снизить проблему? потому что начинают валиться лайвнесы у всех подов и начинается эта бичеловка с перезагрузками бесконечная что тоже дает нагрузки на куб
А можно конкретнее?
AL
У тебя етцд перестает вывозить? Или кубелеты на нодах подвисают?
Ц
Всем привет! Есть ли какие-нибудь практики для работы с ботами? Знаю, что можно создавать инстансы для балансировки нагрузки, но, в телеге к примеру, одновременно два бота запрашивать метод getUpdates не могут. Что в таком случае делается? Промежуточный сервис какой-то?
tE
Всем ку, может у кого-нибудь есть конфиг сервис монитора для кликхаус оператора под рукой, если есть возможность заделиться – буду очень признателен, спасибо)
tE
Всем привет! Есть ли какие-нибудь практики для работы с ботами? Знаю, что можно создавать инстансы для балансировки нагрузки, но, в телеге к примеру, одновременно два бота запрашивать метод getUpdates не могут. Что в таком случае делается? Промежуточный сервис какой-то?
Можно поставить вебхук, пусть телега сама к тебе ходит, а ты уже балансируй, но лучший способ - это развернуть у себя telegram-bot-api сервер, там max_connections можешь выкрутить до бесконечности, а не стандартный лимит в 100)
Ц
Можно поставить вебхук, пусть телега сама к тебе ходит, а ты уже балансируй, но лучший способ - это развернуть у себя telegram-bot-api сервер, там max_connections можешь выкрутить до бесконечности, а не стандартный лимит в 100)
Так даже если вебхук, я не могу же одновременно два указать
Ц
Куча незнакомых слов, но это, походу, то, что мне нужно - спасибо, буду разбираться
tE
Куча незнакомых слов, но это, походу, то, что мне нужно - спасибо, буду разбираться
Почитайте про разницу polling и вебхук, при поллинге приложение само ходит опрашивать телегу на наличие обновлений, а когда вебхук - телеграм сам присылает обновления на твой сервер
Ц
Почитайте про разницу polling и вебхук, при поллинге приложение само ходит опрашивать телегу на наличие обновлений, а когда вебхук - телеграм сам присылает обновления на твой сервер
Да, я про вебхук знаю, говорю о kubernetes. Большое спасибо за помощь!
DS
господа, заюзал я значит rook nfs, и чет не пойму, я должен сам запустить provisioner ? дока вообще не прозрачная
Так мы же тебе советовали проверенное и популярное решение. Теперь страдай 😂
N
Всем привет
Начинаем переезд в kubernetes
Имеется приложение, которое для запросов в разные АПИ использует клиентские сертификаты, ключи шифрования, которых может быть достаточно много, но обновляются не часто
Сертификаты могут быть примерно в таком виде:
Подскажите, пожалуйста, как правильнее хранить эти сертификаты?
Нашел варианты:
1) использовать werf или helm-secrets. Указать сертификаты как секреты в values зашифрованные и в CI указать ключ для расшифровки
2) использовать vault и запрашивать сертификат у волта на каждый запрос в АПИ, но тут 2 проблемы:
1) лишняя нагрузка на vault
2) Приложение работает в 2-ух окружениях. Во втором нет кубера и директория с сертификатами маунтится с хоста, из-за чего в приложении уже заложено ходить именно к файлам и с волтом тут получится костыль
3) использовать vault и получать сертификаты во время CI, но тут придется каждый секрет получить отдельно и потом еще все они пойдут через аргументы
4) упаковать директорию с сертификатами в архив, положить в виде base64 в vault, использовать initContainer, который заберет из волта архив, распакует и отдаст приложению сразу все сертификаты
Начинаем переезд в kubernetes
Имеется приложение, которое для запросов в разные АПИ использует клиентские сертификаты, ключи шифрования, которых может быть достаточно много, но обновляются не часто
Сертификаты могут быть примерно в таком виде:
/cli-crt
/cli-crt/api1/cert.pem
/cli-crt/api2/cert.pem
/cli-crt/api3/cert1/cert.pem
/cli-crt/api3/cert2/cert.pem
/cli-crt/api3/cert3/cert.pem
Подскажите, пожалуйста, как правильнее хранить эти сертификаты?
Нашел варианты:
1) использовать werf или helm-secrets. Указать сертификаты как секреты в values зашифрованные и в CI указать ключ для расшифровки
2) использовать vault и запрашивать сертификат у волта на каждый запрос в АПИ, но тут 2 проблемы:
1) лишняя нагрузка на vault
2) Приложение работает в 2-ух окружениях. Во втором нет кубера и директория с сертификатами маунтится с хоста, из-за чего в приложении уже заложено ходить именно к файлам и с волтом тут получится костыль
3) использовать vault и получать сертификаты во время CI, но тут придется каждый секрет получить отдельно и потом еще все они пойдут через аргументы
4) упаковать директорию с сертификатами в архив, положить в виде base64 в vault, использовать initContainer, который заберет из волта архив, распакует и отдаст приложению сразу все сертификаты
AS
Захардени кубер и не парься)
AS
В волт ходить на каждый запрос такая себе идея
AS
Я бы 4 пункт выбрал