Идея проекта веб-сервера

Завтра пятница

А пальцем до носа дотронься

Сайт должен деплоиться через github. Т.е. твой сервер должен мониторить репозиторий на github и доставать оттуда файлы.

Подходит как один из вариантов деплоя. Но фронтэнды часто имеют стадию сборки, коммитить сгенерированные файлы ну такое, логичнее CI/CD с загрузкой zip/tar архива с собранным фронтом в API.

ничего не понял но очень интересно. раньше была такая тема - апликатион сервер. там можно делать все что угодно.

все делается скриптами.

вопрос в том как вы будете зарабатывать на этом, а не тратить.

Что за глупость? Почему работоспособность моего сайта должна зависеть ещё и от доступности гитхаба?

Это ты панель для вебхостинга только без гуя придумал что ль?

Всё правильно юзернейм говорит. Периодически дёргать с гитхаба конфу, сидеть за клаудфлэром и с лэтсэнкриптовым сертификатом. А бэкапиться в ажур, или авс. Желательно уложиться в бесплатных тарифных планах. Иначе он слишком твой, сайт твой.

проекты паковать в Docker с nginx с дефолтной конфигурацией.
Что думает LOR? Не нужно?

Ненужно, конечно.

Ты только что описал managed-кубер

Периодически дёргать с гитхаба конфу

А что мешает её просто дёргать с гита? Или если не нравится дрочить терминал - gitea, тот-же гитлаб или что там ещё нафоркали.

Мало зависимостей от сторонних сервисов, которые по ToS тебе ничего не гарантируют.

Кубер и статический бинарник это несколько разные весовые категории и области применения.

Плюс статику сам по себе Кубер не деплоит, предлагается собирать свой образ на базе nginx и деплоить уже его, либо настраивать проксирование S3.

Я так и прочитал его идею как «возможность стягивать конфиг/файлы с гита». Гитхаб тут как Ксерокс - имя нарицательное. Хотя, конечно, я не могу гарантировать, что именно он имел ввиду :-)

Почему без гуя. Фронт тоже будет на базе API, чтобы можно было проверять конфигурацию и что-то менять руками.

В целом близко, да.

Но панель хостинга позволяла просто закинуть файлы, а тут ещё будут настраиваться апстримы. Плюс фича кеширования. Плюс этот самый API, которого у панели могло не быть.

Если тебе прям вот всё это в статический бинарник, то тебе в гошники.

UPD: Хотя чего это я… k3s же, вот тебе всё что ты описал в одном бинарнике. https://k3s.io/

Куберу нужен докер или другой рантайм контейнеров. Кубер нужно достаточно нетривиально настраивать.

У меня же идея - кнопка «сделать зашибись» для распространённого юзкейса «деплоим набор статических файлов + опциональный апстрим».

Go

Если буду писать, то на Rust. В принципе, проект мог бы быть и на Go, но я его не знаю и он мне не нравится.

Вообще, ещё в мою бытность вебмакакой хотинг панели были вымирающим явлением. Если только ты сумеешь устроить второе пришествие.

Кубер нужно достаточно нетривиально настраивать.

Подумай почему.

У меня же идея - кнопка «сделать зашибись» для распространённого юзкейса «деплоим набор статических файлов + опциональный апстрим».

Попробуй подумать почему такого нет

Если буду писать, то на Rust

Ты опухнешь.

но я его не знаю и он мне не нравится.

Подумай почему кубер написали именно на нём.

Подумай почему.

Потому что Кубер - универсальный инструмент, позволяющий настроить самые извращённые конфигурации.

Попробуй подумать почему такого нет

Такое есть. Например, тот самый Cloudflare Pages. Просто оно SaaS, а не self-hosted.

Ты опухнешь.

Пример как я не опухаю: https://github.com/quoi-dev/keystack-pages

На Rust уже давно можно писать REST сервисы примерно как на Java - всё что плохо лежит клонируется или оборачивается в Arc (да, это добавляет небольшой оверхед, но он точно также есть в любом managed языке, а тут нативный код, отсутствие GC и возможность более гибко выбирать передачу по ссылке или по значению). Ну и стиль с делением на MVC слои. Благо есть Axum (который несмотря на вездесущее клонирование находится в топе по бенчмаркам) и набор библиотек на каждый чих. И я не один такой, некоторые стартапы юзают Rust «вместо Java» (с соответствующим стилем кода).

Подумай почему кубер написали именно на нём.

Потому что нужно было что-то попроизводительнее Python, менее прожорливое к памяти, чем Java и не отстреливающее ноги как C++, потому что Rust тогда пешком под стол ходил (в том числе не было адекватных фреймворков для REST), потому что Go разработчиков проще нанимать, потому что Go создал Google, который и создал Kubernetes.

Вот и я с лицом легушки читаю как люди с удивлением для себя открывают волшебный дивный мир гита без гитхаба: https://medium.com/@the_atomic_architect/you-dont-need-github-your-ssh-server-is-already-a-git-host-8dd9a8c1f283

И что тебе мешает прямо сейчас это написать?

По моему опыту простенький веб-сервер на нормальном ЯП пишется за сутки-двое. А остальное - тупо навешивание фич.

можно грузить файлы одной командой по API и атомарно заменять

А чем это лучше, чем общепринятый способ:

• Деплой фронтэндов (вместо того чтобы … деплоить контейнер с NGINX )

?

Ну и Traefik на входе ещё.

По моему опыту простенький веб-сервер на нормальном ЯП пишется за сутки-двое.

Hello world, похожий на netcat ? :)

А остальное - тупо навешивание фич.

Ещё цать+ лет ? Чтобы неизвестно, понравился кому-то в проде или нет ?

Попробуй подумать почему такого нет

Такое сделать IMHO раз в 100 проще, да и managed Кубер иногда похож на что-то подобное?

А ещё есть десятки различных проприетарных велосипедов аля Heroku, но кому они нужны при наличии стандартизированного и намного более гибкого Кубера, где нет вендорлочной привязки к кассе производителя?

Кубер бывает в docker контейнере (k0s, k3s, etc.)

• Веб-сервер с поддержкой Let’s encrypt и нескольких доменов
• Можно настраивать через API и через веб-интерфейс
• Опционально можно задать апстрим (всего домена или отдельного роута или каталога). Если нет статического файла по пути, то запрос уходит в апстрим при наличии

Очень похоже на переизобретение панели управления хостингом. Это уже есть и бесплатно.

• Можно деплоить (добавлять/удалять) статические файлы через API

Изобретение S3 хранилища и CDN?

• Транзакционный деплой - добавление и удаление файлов не видимо снаружи, пока не дёрнешь API коммита, после него видимы сразу все изменения

Что-то очень сложное. Похоже на изобретение CI/CD со сбросом кеша CDN

• Статическим файлам можно задавать теги и есть API удаления сразу всех файлов по тегу (разумеется, атомарно)

Какая-то специфичная задача, вряд ли это нужно многим

• Деплой фронтэндов (вместо того чтобы руками таскать файлы на сервер или деплоить контейнер с NGINX можно грузить файлы одной командой по API и атомарно заменять)

Мне кажется, UI создаст больше проблем, чем пользы. Думаю, стоит посмотреть в сторону ansible

• Кеш перед CMS (проставляем страницам теги таким образом, чтобы можно было за один вызов API удалять страницы, которые затронуло изменение и они были перезапрошены)

Это задача самой CMS, не везде вообще нужно применять кеширование.

Как я понимаю, такое существует только в виде SaaS (Cloudflare Pages и т. д.), а OpenSource self-hosted нет.

Для мелких проектов это избыточно, а для крупных дорого.

Мне просто надоело свои фронтэнд проекты паковать в Docker с nginx с дефолтной конфигурацией.

Думаю, стоит посмотреть в сторону terraform и ansible. Если проекты типовые, то это решает вопрос с настройкой серверов.

Что думает LOR? Не нужно?

Не могу сказать за всех, но я бы не стал этим пользоваться.

Делай, разрешаю.

Hello world, похожий на netcat ?

Чо, нцать лет назад я был свидетелем, как один чувак написал на Джаве веб-сервер часа за четыре. С блэкджеком и шл*хами.

суть такова

Что думает LOR? Не нужно?

Корованы будут?

Hello world, похожий на netcat ? :)

Веб-сервер - это вообще одна из самых простых программ которые только могут быть.

Оно слушает TCP порт и парсит прилетающие в него строки с несколькими командами (а основных так и вовсе две) и параметрами с разделителем.

После чего в зависимости от параметра, или читает\выводит запрашиваемый файл, или обрабатывает запрос дальше.

Биндинг на TCP порт есть в любом ЯП со времен создания TCP, даже на пацкале.

Ещё цать+ лет ? Чтобы неизвестно, понравился кому-то в проде или нет ?

Сколько потребуется. Мир меняется, технологии тоже.

Понравиться - труднее, потому что во-первых веб-серверы уже есть и изобрести новое здесь трудно; во-вторых современные реализации ПО предлагают свой встроенный веб-сервер, который быстрее этих ваших nginx'ов; а в-третьих в современном мире как правило у тех кому нужен веб-сервер, он уже есть, и новому поделию ничего не светит из-за золотого правила админа.

IMHO простой вебсервер только до тех пор, пока хостит homepage для hello world, а когда нужен софт для критически важной и сильно нагруженной инфры, то многое становится не таким уж и простым?

Тем что не нужно писать dockerfile, не нужно держать по контейнеру на каждый статический сайт (им не нужна изоляция, так как там физически никакой код на сервере не выполняется), не нужно настраивать их запуск через свои велосипеды/docker compose/kubernetes.

Какая-то специфичная задача, вряд ли это нужно многим

Эта задача встаёт у многих владельцев CMS и они прикручивают всякие Varnish, Fastly и, собственно, Cloudflare.

Перед всякими PHP поставить кеширующий сервер святое дело, а там встаёт вопрос инвалидации.

Изобретение S3 хранилища и CDN?

Вообще, моя идея по сути гибрид S3 и кеширующего прокси. Но у S3 нет автонаполнения и удобной инвалидации, а у кеширующих серверов нет возможности вручную пихать в них данные. А моя идея совместить.

Что-то очень сложное. Похоже на изобретение CI/CD со сбросом кеша CDN

Это сложно реализуется сейчас. А технически это просто дополнительный признак версии к файлам в хранилище, сервить файлы не новее заданной версии, коммит инкрнментирует версию.

IMHO простой вебсервер только до тех пор, пока хостит homepage для hello world, а когда нужен софт для критически важной и сильно нагруженной инфры, то многое становится не таким уж и простым?

В этом и дело, что софту для критически важной и сильно нагруженной инфы, веб-сервер вообще не нужен - этот софт сам себе веб-сервер.

Часть фич думаю можно подпердолить на nginx + webdav. Еще у nginx довольно просто делать кэш перед CMS и в платной подписке через директиву proxy_cache_purge можно сделать урл при дерганьи которого конкретный кэш будет принудительно сноситься. Давно не лазил, может есть и опенсорс плагин для инвалидации кэша, на крайняк можно самому написать.
Транзакционный деплой можно посмотреть на gitlab ci + capistrano.