По сути да, но показалось это не очень страшным, udp нередко бывает закрыт, тем более для офиса это делал. Решение не безупречное, но никто ничего не заметил) хотя созвоны постоянные.
Наверное идеальное решение можно будет сделать только через доп контейнер (пробовал на chr - работает нормально), когда или будут перехватываться DNS запросы, и заранее адреса оттуда подставляться в лист для обхода, либо в контейнере будет развернут какой-нить haproxy с более хитрой (полноценной) логикой анализа SNI, либо контейнер с развёрнутым zapret, чтобы вообще VPN не использовать, пока такие механизмы позволяют обходить DPI. В общем будущее за каким-нибудь хитрым контейнером)
Была ситуация с Ютубом, что браузер установил соединение по UDP по QUIC протоколу, и роутер не отловил это соединение и не завернул его в VPN, потому что в этом протоколе домен передаётся не в открытом виде и маршрутизатор его не видит. Поэтому запретил любой QUIC протокол кроме случаев подключения к адресам, которые у нас и так уже идут через VPN.
По правилу на домен в mangle, потому что L7 фильтр не всегда подхватывал домен, проверил через wireshark, оказалось иногда домен попадал не в первые 2кб соединения, и L7 по умолчанию обрабатывал только их. Через mangle заставляю проанализировать теперь первые 4кб соединения.
Получилось на микроте, но загоняя через VPN. Добавляете L7 Protocol, например, ^.+(2ip.ru|.googlevideo.com).*$ , далее в Mangle добавляете для prerouting правило, чтобы соединения с портами назначения 80 и 443, которые не находятся в неком адрес листе, добавлялись в этот адрес лист. Далее стандартно для этого адрес листа заворачиваете трафик в VPN. Единственное добавил в firewall правило, чтобы дропались с tcp reset подключения по адресам из этого адрес листа, если они попытались пойти через WAN, чтобы отклонить первое соединение, когда адреса еще не было в адрес листе.
Но в целом наверняка красивее и без VPN можно справиться и через контейнеризацию - запустить zapret и как-то закручивать трафик на него.
Подскажите, пожалуйста, если просто без кода запускать LLAMA-3-70B-Instruct-IQ2_XS в LM Studio (как понимаю это просто GUI над llama.cpp) на RTX 4090 24Gb с выгрузкой всей модель в GPU (помещается), то из коробки все известные на данный момент оптимизации применяются? Сейчас получаем около 25 токенов/сек
Спасибо за обзор! Кажется бОльшая часть человечества и даже разработчиков ещё даже не осознают масштабы происходящего и открывающихся возможностей ИИ, особенно в мультиагентном варианте, с возможностью развития каждого проекта, наличием у каждого своей специализации и базы знаний, а также подключения внешних интеграций. Думаю уже в ближайшие годы возникнут полностью цифровые компании с цифровыми сотрудниками
В официальных релизах сейчас 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 и очень довольны, удобно.
Письмо действительно приходило, и даже ответили на уточняющие вопросы о том какие именно "прочие данные" утекли. Возможно у ваших знакомых попало в спам, либо не обратили внимания на "очередное письмо от яндекса"?
Подскажите, пожалуйста, когда планируется предоставить возможность произвольным компаниям становиться теми самыми инициаторами подписания? Известна ли процедура? Есть ли публичная документация по интеграции?
А longhorn обладает какими-то недостатками по сравнению с предложенным решением?
В правиле рубится udp только на 80 и 443 портах
По сути да, но показалось это не очень страшным, udp нередко бывает закрыт, тем более для офиса это делал. Решение не безупречное, но никто ничего не заметил) хотя созвоны постоянные.
Наверное идеальное решение можно будет сделать только через доп контейнер (пробовал на chr - работает нормально), когда или будут перехватываться DNS запросы, и заранее адреса оттуда подставляться в лист для обхода, либо в контейнере будет развернут какой-нить haproxy с более хитрой (полноценной) логикой анализа SNI, либо контейнер с развёрнутым zapret, чтобы вообще VPN не использовать, пока такие механизмы позволяют обходить DPI. В общем будущее за каким-нибудь хитрым контейнером)
Была ситуация с Ютубом, что браузер установил соединение по UDP по QUIC протоколу, и роутер не отловил это соединение и не завернул его в VPN, потому что в этом протоколе домен передаётся не в открытом виде и маршрутизатор его не видит. Поэтому запретил любой QUIC протокол кроме случаев подключения к адресам, которые у нас и так уже идут через VPN.
см. https://habr.com/ru/articles/833564/comments/#comment_27134572
Я немного в целом весь подход переделал:
По правилу на домен в mangle, потому что L7 фильтр не всегда подхватывал домен, проверил через wireshark, оказалось иногда домен попадал не в первые 2кб соединения, и L7 по умолчанию обрабатывал только их. Через mangle заставляю проанализировать теперь первые 4кб соединения.
Получилось на микроте, но загоняя через VPN. Добавляете L7 Protocol, например,
^.+(2ip.ru|.googlevideo.com).*$, далее в Mangle добавляете для prerouting правило, чтобы соединения с портами назначения 80 и 443, которые не находятся в неком адрес листе, добавлялись в этот адрес лист. Далее стандартно для этого адрес листа заворачиваете трафик в VPN. Единственное добавил в firewall правило, чтобы дропались с tcp reset подключения по адресам из этого адрес листа, если они попытались пойти через WAN, чтобы отклонить первое соединение, когда адреса еще не было в адрес листе.Но в целом наверняка красивее и без VPN можно справиться и через контейнеризацию - запустить zapret и как-то закручивать трафик на него.
Подскажите, пожалуйста, если просто без кода запускать LLAMA-3-70B-Instruct-IQ2_XS в LM Studio (как понимаю это просто GUI над llama.cpp) на RTX 4090 24Gb с выгрузкой всей модель в GPU (помещается), то из коробки все известные на данный момент оптимизации применяются? Сейчас получаем около 25 токенов/сек
Спасибо за обзор! Кажется бОльшая часть человечества и даже разработчиков ещё даже не осознают масштабы происходящего и открывающихся возможностей ИИ, особенно в мультиагентном варианте, с возможностью развития каждого проекта, наличием у каждого своей специализации и базы знаний, а также подключения внешних интеграций. Думаю уже в ближайшие годы возникнут полностью цифровые компании с цифровыми сотрудниками
А получится при этом установить 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 и очень довольны, удобно.
Письмо действительно приходило, и даже ответили на уточняющие вопросы о том какие именно "прочие данные" утекли. Возможно у ваших знакомых попало в спам, либо не обратили внимания на "очередное письмо от яндекса"?
Здравствуйте!
Подскажите, пожалуйста, когда планируется предоставить возможность произвольным компаниям становиться теми самыми инициаторами подписания? Известна ли процедура? Есть ли публичная документация по интеграции?
Спасибо!