Спасибо за обзор! Кажется бОльшая часть человечества и даже разработчиков ещё даже не осознают масштабы происходящего и открывающихся возможностей ИИ, особенно в мультиагентном варианте, с возможностью развития каждого проекта, наличием у каждого своей специализации и базы знаний, а также подключения внешних интеграций. Думаю уже в ближайшие годы возникнут полностью цифровые компании с цифровыми сотрудниками
В официальных релизах сейчас 1.26.1 (выпустили 26.01.2023), то есть реально последняя версия ванильного кубера (released: 2023-01-18), т.е. выпустили буквально через неделю.
Хороший вопрос на счет автомасштабирования реплик. Предполагаете, что каждый под внутри k3d кластера будет являться отдельным контейнером (набором контейнеров) на уровне докера? Сейчас k3d не установлен, чтобы проверить, но почти уверен, что нет. Скорее всего все поды виртуальной "ноды" будут запускаться внутри единого docker-контейнера, а если это действительно так, то, получается, помирать докеру не от чего, он не будет видеть разрастания количества подов.
Если верно понимаю потребность (как часть CI/CD шустро развертывать свой маленький, но настоящий k8s кластер и прогонять на нем какие-нибудь тесты), то не подходит ли тут идеально k3d от Rancher? Развертывает одной командой k3s кластер заданной конфигурации в докере.
Может попробуем сделать dockerfile для сборки образа с сервером? Ну и в идеале helm chart (ну или просто набор yaml файликов) для развёртывания в кубере деплоймпнтов с самим сервером 1С (включая PVC для хранения файловой составляющей сервера), веб сервером и его публикацией через ingress?
Не увидел комментария, отвечу спустя несколько месяцев... Да, я полагаю, что больше нет никакого практического смысла использовать вебхуки, в т.ч. в коммерческих продуктах.
Используем в нескольких проектах на проде, в т.ч. в CI/CD, управлять очень просто, отлично работает автопубликация через traefik.
Есть известные неисправляющиеся баги на смешанных кластерах на Windows нодах с ingress и публикацией порта, открывал issue безрезультатно больше года назад - раз и два.
Хотя в итоге это не стало большой проблемой, если публиковать ресурсы с Windows нод через traefik, крутящийся на линуксовой ноде, ну и планомерно отказываться вообще от контейнеров на Windows.
Кажется в начале статьи есть достаточно важная неточность, Вы указываете, что "обновления будем получать периодически опрашивая Telegram сервер на наличие новых обновлений", но ведь указанный Telegram.Bot.Extentions.Polling использует long polling, поддерживаемый API Telegram согласно документации:
getUpdates
Use this method to receive incoming updates using long polling
Таким образом, никакого периодического опроса сервера нет, мы подключаемся к нему и висим до тех пор, пока серверу не будет что отдать, сразу после получения новых данных библиотека делает повторное подключение к API Telegram и опять висит. За счёт этого нет каких - либо задержек при получении обновлений и боты работают моментально.
По моему скромному мнению, с момента поддержки long polling не стало самого главного преимущества вебхуков (моментальности), а инфраструктурных недостатков и неудобств сильно больше. В наших проектах перешли на long polling и очень довольны, удобно.
Письмо действительно приходило, и даже ответили на уточняющие вопросы о том какие именно "прочие данные" утекли. Возможно у ваших знакомых попало в спам, либо не обратили внимания на "очередное письмо от яндекса"?
Подскажите, пожалуйста, когда планируется предоставить возможность произвольным компаниям становиться теми самыми инициаторами подписания? Известна ли процедура? Есть ли публичная документация по интеграции?
Спасибо за обзор! Кажется бОльшая часть человечества и даже разработчиков ещё даже не осознают масштабы происходящего и открывающихся возможностей ИИ, особенно в мультиагентном варианте, с возможностью развития каждого проекта, наличием у каждого своей специализации и базы знаний, а также подключения внешних интеграций. Думаю уже в ближайшие годы возникнут полностью цифровые компании с цифровыми сотрудниками
А получится при этом установить docker и запускать контейнеры? Или даже какой-нибудь k3s развернуть
Здравствуйте! Хотел уточнить судьбу второй части. Эти планы ещё в силе?
Скажите, пожалуйста, ожидается ли еще часть 2 с конкретикой?
В официальных релизах сейчас 1.26.1 (выпустили 26.01.2023), то есть реально последняя версия ванильного кубера (released: 2023-01-18), т.е. выпустили буквально через неделю.
Хороший вопрос на счет автомасштабирования реплик. Предполагаете, что каждый под внутри k3d кластера будет являться отдельным контейнером (набором контейнеров) на уровне докера? Сейчас k3d не установлен, чтобы проверить, но почти уверен, что нет. Скорее всего все поды виртуальной "ноды" будут запускаться внутри единого docker-контейнера, а если это действительно так, то, получается, помирать докеру не от чего, он не будет видеть разрастания количества подов.
Если верно понимаю потребность (как часть CI/CD шустро развертывать свой маленький, но настоящий k8s кластер и прогонять на нем какие-нибудь тесты), то не подходит ли тут идеально k3d от Rancher? Развертывает одной командой k3s кластер заданной конфигурации в докере.
Может попробуем сделать dockerfile для сборки образа с сервером? Ну и в идеале helm chart (ну или просто набор yaml файликов) для развёртывания в кубере деплоймпнтов с самим сервером 1С (включая PVC для хранения файловой составляющей сервера), веб сервером и его публикацией через ingress?
Не увидел комментария, отвечу спустя несколько месяцев... Да, я полагаю, что больше нет никакого практического смысла использовать вебхуки, в т.ч. в коммерческих продуктах.
Отличная обзорная статья, спасибо автору.
Используем в нескольких проектах на проде, в т.ч. в CI/CD, управлять очень просто, отлично работает автопубликация через traefik.
Есть известные неисправляющиеся баги на смешанных кластерах на Windows нодах с ingress и публикацией порта, открывал issue безрезультатно больше года назад - раз и два.
Хотя в итоге это не стало большой проблемой, если публиковать ресурсы с Windows нод через traefik, крутящийся на линуксовой ноде, ну и планомерно отказываться вообще от контейнеров на Windows.
Кажется в начале статьи есть достаточно важная неточность, Вы указываете, что "обновления будем получать периодически опрашивая Telegram сервер на наличие новых обновлений", но ведь указанный Telegram.Bot.Extentions.Polling использует long polling, поддерживаемый API Telegram согласно документации:
Таким образом, никакого периодического опроса сервера нет, мы подключаемся к нему и висим до тех пор, пока серверу не будет что отдать, сразу после получения новых данных библиотека делает повторное подключение к API Telegram и опять висит. За счёт этого нет каких - либо задержек при получении обновлений и боты работают моментально.
По моему скромному мнению, с момента поддержки long polling не стало самого главного преимущества вебхуков (моментальности), а инфраструктурных недостатков и неудобств сильно больше. В наших проектах перешли на long polling и очень довольны, удобно.
Письмо действительно приходило, и даже ответили на уточняющие вопросы о том какие именно "прочие данные" утекли. Возможно у ваших знакомых попало в спам, либо не обратили внимания на "очередное письмо от яндекса"?
Здравствуйте!
Подскажите, пожалуйста, когда планируется предоставить возможность произвольным компаниям становиться теми самыми инициаторами подписания? Известна ли процедура? Есть ли публичная документация по интеграции?
Спасибо!