У вас некоторые модели идут с постфиксом :free и за их использование не снимаются CAPS. Почему так? Можете пожалуйста показать условия использования таких моделей.
Благодарю за статью. Правильно ли я понял, сервер MCP не должен иметь LLM на борту. Просто у него есть роут, который показывает все возможные команды на естественном языке и роуты для каждой команды, если на исполнение передана одна из прописанных в нем комманд, то он возвращает соответствующие этому данные. То есть, простыми словами, это обычный API только вместо параметров запроса передается текст. Или нет?
С Dockerfile для нашего хостинга не подходящее решение. Мы не даём пользователям возможности собирать свои контейнеры на базе Dockerfile, а только предоставляем возможность запустить поддерживаемые образы.
Махинации над контейнером только через entrypoint, поэтому и встал этот вопрос с перезапуском. Ведь изначально, когда работало на docker compose этой проблемы не было. Enntrypoint срабатывал только после создания контейнера, а при обновлении файлов только рестарт и command.
Спасибо за ответ. Моё мышление в этом вопросе на базе Docker формировалось.
Вот например есть сервис, которому нужно несколько дополнительных системных зависимостей. Через скрипт в docker-compose.yml service.entrypoint их устанавлиешь и обходишься без Dockerfile.
Когда понадобилось перезапустить сервис, после изменения файлов в volumes, чтобы изменения вступили в силу. Просто делаешь docker restart name.
А в swarm, так не получается. Только пересоздание. Но пересоздание не годится, так как каждый раз будет срабатывать долгий entrypoint.
В Kubernetes сейчас смотрю с entrypoint похоже тоже не получится.
Получается от entrypoint на уровне конфигов в кубере придется забыть?
Спасибо, за замечание. Если Вы имеете в виду "нет возможности перезапуска", то считаю, что оно справедливое.
Просто в трёх разных контекстах с этим столкнулся:
Не поднять упавший контейнер
Не перезапустить без пересоздания
Не управляется через docker cli
И на примере реальных кейсов хотел показать, с чем сам столнулся. А литературного таланта не хватило, чтобы это правильно обыграть. Может если нумерацию заголовков убрать, то не будет вызывать ожидание, что в списке должны быть разные недостатки🤔
На короткой дистанции да. Но если потом, например, вы захотите шифровать траффик между сервисами на уровне сети или маршрутизировать траффик на уровне сети по заголовкам или адресам, или анализировать траффик. То проще будет всё таки грокнуть кубер и внедрить в него Istio с Envoy для всех этих задач чем изобретать свои велосипеды.
Работает, но нужно управление политиками. Для хостинга важно ограничивать, например, возможность исходящих запросов на какие-то порты, например почтовые, или запретить звонить из контейнеров в хост систему по IP. С помощью calico это можно сделать на уровне сети, при помощи конфига сервисов, а без этого придется добавлять ограничения в iptables на каждой отдельной ноде.
Верно. Просто в Kubernetes, например, он не даёт поды напрямую изменять, говорит "это создавалось через деплоймент и должно управляться через него". А в swarm бардак, в этом отношении.
Это, да. Если убить, то сварм новый запустит. Речь о том если остановить или перезапустить, то он станет самостоятельным, сварм про него забудет, а вместо него другой запустит.
Понимаю вашу боль. Прохожу через всё это. Точно могу сказать, что год назад мне ума не хватило бы разобраться с кубером, сейчас с помощью GPT, более менее продвигаюсь в освоении. На самом деле вещь крутая, не удивляюсь теперь что это новый стандарт. Там можно даже сделать CRD (Custom Resource Definition) и создавать свои ресурсы, которыми также управлять через kubectl, и навешивать контроллеры которые обслуживают логику.
Теперь вижу, что если грамотно использовать кубер, то от старого кода можно половину выкинуть.
В k8s есть перезапуск деплоймента `kubectl rollout restart deployment -n namespace name` и перезапуск можно настроить, там минимальное количество не перезагружающихся реплик и количество дополнительно создаваемых реплик. Вот только кажется там нет времени задержки между началом перезапуска следующей реплики.
Вот в тему статьи, когда блокировали докер хаб, я написал проект по созданию контейнеров из scratch (без загрузки готовых образов). Там две OS на самом гитхабе собирается, с разными версиями под разные архитектуры, держите для справки https://github.com/kolserdav/docker-container
Оно не медленнее работает, просто на работу самого докера нужны ресурсы, и если у системы с ресурсами проблема то это будет отражаться и на приложении.
Варианта нет для нашей ноды, которая соединяет клиентов и их сервисы.
Для запуска Swarm ноды, чтобы обеспечить бесперебойность при перезапуске вариант конечно же есть. Но сейчас цена и объем сервера расчитаны на развитие, и разбивка уменьшит общий объем сервера, при том что многие наверняка не будут использовать 2 реплики, потому что каждая стоит отдельно, и часть ресурсов сервера будет простаивать. Не думаю что отсутствие возможности купить 2 и более реплики, на данном этапе, будет распостраненной причиной отказа в покупке, тем более учитывая что такой функционал запланирован на ближайшее будущее.
Swarm пока не используется, но активно под него всё рассчитывается на будущее. Поэтому по проблемам горизонтального масштабирования пока ничего не скажу.
Из того что мне довелось увидеть, проблема swarm в перезапуске docker, если есть много контейнеров с `restart:always | on-failure`, потому что swarm как и compose использует для запуска контейнеров флаг `--restart`.
Сколько много это напрямую зависит от железа. На нашем сервере 128ГБ RAM и 2 проц по 28 ядер 2.4ГГЦ если например создать 200 контейнеров с `restart: always` то перезапуск docker минут 20, а если 300 то больше часа, 400 - боюсь представить сколько.
Я бы может подробил бы для начала один жирный железный сервер на несколько поменьше
Каждый сервер должен слушать 80 и 443 порт, на одном IP они не уживуться. А на данном этапе покупать отдельный канал интернета, находясь вдали от цивилизации, слишком расточительно.
Подумал бы про балансировку трафика, ну и да, тут без окрестратора ни куда
Это в процессе.
А еще, как идея на подумать, затащил бы отдельный сервис хранения секретов, чтоб пользователь не в тупую в конфигах их хранил открыто
Это есть называется переменные среды (${NAME}) в браузере можно создать защищенную, хранится в зашифрованном виде.
У вас некоторые модели идут с постфиксом :free и за их использование не снимаются CAPS. Почему так? Можете пожалуйста показать условия использования таких моделей.
Благодарю за статью. Правильно ли я понял, сервер MCP не должен иметь LLM на борту. Просто у него есть роут, который показывает все возможные команды на естественном языке и роуты для каждой команды, если на исполнение передана одна из прописанных в нем комманд, то он возвращает соответствующие этому данные. То есть, простыми словами, это обычный API только вместо параметров запроса передается текст. Или нет?
Это не вариант, потому что если у вас 2 реплики, чтобы во время рестарта хотя-бы одна отвечала, то это не сработает с таким перезапуском.
Я неправильно понимал механизм entrypoint, дописал внизу статьи.
Я заблуждался, благодарю Вас ещё раз за обратную связь. Дописал вконце статьи об этом.
С Dockerfile для нашего хостинга не подходящее решение. Мы не даём пользователям возможности собирать свои контейнеры на базе Dockerfile, а только предоставляем возможность запустить поддерживаемые образы.
Махинации над контейнером только через entrypoint, поэтому и встал этот вопрос с перезапуском. Ведь изначально, когда работало на docker compose этой проблемы не было. Enntrypoint срабатывал только после создания контейнера, а при обновлении файлов только рестарт и command.
Вы, кажется, не ту ссылку привели.
Спасибо за ответ. Моё мышление в этом вопросе на базе Docker формировалось.
Вот например есть сервис, которому нужно несколько дополнительных системных зависимостей. Через скрипт в docker-compose.yml service.entrypoint их устанавлиешь и обходишься без Dockerfile.
Когда понадобилось перезапустить сервис, после изменения файлов в volumes, чтобы изменения вступили в силу. Просто делаешь docker restart name.
А в swarm, так не получается. Только пересоздание. Но пересоздание не годится, так как каждый раз будет срабатывать долгий entrypoint.
В Kubernetes сейчас смотрю с entrypoint похоже тоже не получится.
Получается от entrypoint на уровне конфигов в кубере придется забыть?
Спасибо, за замечание. Если Вы имеете в виду "нет возможности перезапуска", то считаю, что оно справедливое.
Просто в трёх разных контекстах с этим столкнулся:
Не поднять упавший контейнер
Не перезапустить без пересоздания
Не управляется через docker cli
И на примере реальных кейсов хотел показать, с чем сам столнулся. А литературного таланта не хватило, чтобы это правильно обыграть. Может если нумерацию заголовков убрать, то не будет вызывать ожидание, что в списке должны быть разные недостатки🤔
На короткой дистанции да. Но если потом, например, вы захотите шифровать траффик между сервисами на уровне сети или маршрутизировать траффик на уровне сети по заголовкам или адресам, или анализировать траффик. То проще будет всё таки грокнуть кубер и внедрить в него Istio с Envoy для всех этих задач чем изобретать свои велосипеды.
Спасибо за комментарий. Хм, интересно. В k8s получается тоже нету перезапуска подов?
Работает, но нужно управление политиками. Для хостинга важно ограничивать, например, возможность исходящих запросов на какие-то порты, например почтовые, или запретить звонить из контейнеров в хост систему по IP. С помощью calico это можно сделать на уровне сети, при помощи конфига сервисов, а без этого придется добавлять ограничения в iptables на каждой отдельной ноде.
Верно. Просто в Kubernetes, например, он не даёт поды напрямую изменять, говорит "это создавалось через деплоймент и должно управляться через него". А в swarm бардак, в этом отношении.
Это, да. Если убить, то сварм новый запустит. Речь о том если остановить или перезапустить, то он станет самостоятельным, сварм про него забудет, а вместо него другой запустит.
Понимаю вашу боль. Прохожу через всё это. Точно могу сказать, что год назад мне ума не хватило бы разобраться с кубером, сейчас с помощью GPT, более менее продвигаюсь в освоении. На самом деле вещь крутая, не удивляюсь теперь что это новый стандарт. Там можно даже сделать CRD (Custom Resource Definition) и создавать свои ресурсы, которыми также управлять через kubectl, и навешивать контроллеры которые обслуживают логику.
Теперь вижу, что если грамотно использовать кубер, то от старого кода можно половину выкинуть.
В k8s есть перезапуск деплоймента `kubectl rollout restart deployment -n namespace name` и перезапуск можно настроить, там минимальное количество не перезагружающихся реплик и количество дополнительно создаваемых реплик. Вот только кажется там нет времени задержки между началом перезапуска следующей реплики.
Вот в тему статьи, когда блокировали докер хаб, я написал проект по созданию контейнеров из scratch (без загрузки готовых образов). Там две OS на самом гитхабе собирается, с разными версиями под разные архитектуры, держите для справки https://github.com/kolserdav/docker-container
Оно не медленнее работает, просто на работу самого докера нужны ресурсы, и если у системы с ресурсами проблема то это будет отражаться и на приложении.
Варианта нет для нашей ноды, которая соединяет клиентов и их сервисы.
Для запуска Swarm ноды, чтобы обеспечить бесперебойность при перезапуске вариант конечно же есть. Но сейчас цена и объем сервера расчитаны на развитие, и разбивка уменьшит общий объем сервера, при том что многие наверняка не будут использовать 2 реплики, потому что каждая стоит отдельно, и часть ресурсов сервера будет простаивать.
Не думаю что отсутствие возможности купить 2 и более реплики, на данном этапе, будет распостраненной причиной отказа в покупке, тем более учитывая что такой функционал запланирован на ближайшее будущее.
Swarm пока не используется, но активно под него всё рассчитывается на будущее. Поэтому по проблемам горизонтального масштабирования пока ничего не скажу.
Из того что мне довелось увидеть, проблема swarm в перезапуске docker, если есть много контейнеров с `restart:always | on-failure`, потому что swarm как и compose использует для запуска контейнеров флаг `--restart`.
Сколько много это напрямую зависит от железа. На нашем сервере 128ГБ RAM и 2 проц по 28 ядер 2.4ГГЦ если например создать 200 контейнеров с `restart: always` то перезапуск docker минут 20, а если 300 то больше часа, 400 - боюсь представить сколько.
Каждый сервер должен слушать 80 и 443 порт, на одном IP они не уживуться. А на данном этапе покупать отдельный канал интернета, находясь вдали от цивилизации, слишком расточительно.
Это в процессе.
Это есть называется переменные среды (${NAME}) в браузере можно создать защищенную, хранится в зашифрованном виде.