Но с кучей ограничений (типа квоты 100Мб). И не пожизненно, а пока хостер не решит, что содержать орду бесплатных клиентов - как-то дороговато
Без использования VPS
По итогу VPS и получили :)
Сама инструкция неплохая, всё наглядно, спасибо. Но с привязкой к этому хостеру и его бесплатному тарифу годится разве что для пет-проектов и тестовых стендов
100B - слишком тяжело даже для коммерческого использования (если не изменяет память, арендовать машинку с 200+ VRAM обойдется в 400-500К руб/мес). Вроде видел на Хабре статью, где её запускали на RAM, но это больше на костыль похоже, чем на решение
Хотя в ишью под самой YaLM ссылаются на Llama, но что-то слабо верится в то что получим квантованные модельки или хотя бы версии поменьше :(
У нас остался тот же отдельный сервис, с отдельным endpoint, к которому мы обращаемся на каждом проекте. Но теперь, кроме структуры меню, он еще возвращал статику на JS, в которой, хранится логика. И еще статику на CSS, для отрисовки счетчиков, лейблов и тому подобного.
Если верно понял, во всех проектах по-прежнему есть компонент меню, отвечающий за рендеринг основных пунктов, а их функционал "докручивается" shared-ресурсами?
Получается, это абсолютно разные скрипты, которые ничего не знают друг о друге? Сначала рендерится основное приложение (включая меню), а потом через vm исполняется shared-код, который меняет существующий DOM?
git-trigger запускает воркер, который с какой-то периодичностью пытается сделать git pull origin branchname
Может быть, разумнее держать один лёгкий http-сервер, на который вешать вебхуки Github/Gitlab (на Github этот функционал даже без GH Actions реализуется) и pull делать только тогда, когда изменения действительно произошли?
Сам впервые столкнулся с таким ограничением и сперва, когда проверил скорость через speedtest-cli, подумал, что оно вовсе не работает (тест показал 500/120 Мбит на загрузку и отправку соответственно). Только ТП и разъяснила механизм работы. Но по сути из этого родилась идея сделать то, что я сделал, так что только рад этому странному ограничению :)
До него просто-напросто не успел докопаться в поисках решения, разум затуманил OpenVPN Сейчас мельком посмотрел на wireguard, в некоторых моментах он мне тоже показался проще (например та же статистика, которую я собираю через management-interface достается просто просто командой wg), так что попробую и его пощупать на досуге
Об этом, честно говоря, у меня даже мыслей не было - видимо недостаточно "контейнерное" мышление :) В идеале, наверное, нужно абсолютно всё упаковать в контейнеры (в т.ч. БД) и поднимать одним docker-compose up
Спасибо за наводку, обязательно попробую!
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Но с кучей ограничений (типа квоты 100Мб). И не пожизненно, а пока хостер не решит, что содержать орду бесплатных клиентов - как-то дороговато
По итогу VPS и получили :)
Сама инструкция неплохая, всё наглядно, спасибо. Но с привязкой к этому хостеру и его бесплатному тарифу годится разве что для пет-проектов и тестовых стендов
100B - слишком тяжело даже для коммерческого использования (если не изменяет память, арендовать машинку с 200+ VRAM обойдется в 400-500К руб/мес). Вроде видел на Хабре статью, где её запускали на RAM, но это больше на костыль похоже, чем на решение
Хотя в ишью под самой YaLM ссылаются на Llama, но что-то слабо верится в то что получим квантованные модельки или хотя бы версии поменьше :(
Сами OpenAI уже придумали это в виде плагинов :)
https://habr.com/ru/news/t/724432/
Если верно понял, во всех проектах по-прежнему есть компонент меню, отвечающий за рендеринг основных пунктов, а их функционал "докручивается" shared-ресурсами?
Получается, это абсолютно разные скрипты, которые ничего не знают друг о друге? Сначала рендерится основное приложение (включая меню), а потом через vm исполняется shared-код, который меняет существующий DOM?
Может быть, разумнее держать один лёгкий http-сервер, на который вешать вебхуки Github/Gitlab (на Github этот функционал даже без GH Actions реализуется) и pull делать только тогда, когда изменения действительно произошли?
Сам впервые столкнулся с таким ограничением и сперва, когда проверил скорость через speedtest-cli, подумал, что оно вовсе не работает (тест показал 500/120 Мбит на загрузку и отправку соответственно). Только ТП и разъяснила механизм работы. Но по сути из этого родилась идея сделать то, что я сделал, так что только рад этому странному ограничению :)
До него просто-напросто не успел докопаться в поисках решения, разум затуманил OpenVPN
Сейчас мельком посмотрел на wireguard, в некоторых моментах он мне тоже показался проще (например та же статистика, которую я собираю через management-interface достается просто просто командой wg), так что попробую и его пощупать на досуге
Если правильно понял, получится получить только общий трафик интерфейса OpenVPN? То есть анализ по каждому клиенту отдельно не провести?
Об этом, честно говоря, у меня даже мыслей не было - видимо недостаточно "контейнерное" мышление :)
В идеале, наверное, нужно абсолютно всё упаковать в контейнеры (в т.ч. БД) и поднимать одним docker-compose up
Спасибо за наводку, обязательно попробую!