«С блэкджеком и CI/CD»: APT-репозиторий на базе GitHub и Cloudflare Workers

Повод прозаичный: софт живёт в GitHub Releases, статических бинарниках и исходниках, а на чистой Linux-машине его установка быстро превращается в коллекцию ручных ритуалов. curl | sh, симлинки, .desktop, пачка *-dev ради одной сборки. Потом это почему-то называют «гибкостью».

Репозиторий вместо папки с артефактами

APT давно решает скучную, но важную часть жизни Linux: поиск, установку, обновление, удаление пакетов и зависимости. Проблема начинается там, где нужная программа не попала в дистрибутивный репозиторий и распространяется через сайт автора, GitHub или просто исходники.

Автор схемы описывает знакомую эволюцию костылей. Сначала пакеты и сборки живут прямо на рабочей системе. Затем сборка переезжает в виртуалку с похожим окружением. Потом появляются Dockerfile. Но финальный этап всё равно ручной: собрать .deb, перенести его на другую машину, не забыть, откуда он взялся, и когда-нибудь повторить всё заново.

Собственный APT-репозиторий выглядит естественным выходом. Один раз описал пакет — дальше клиентский apt видит его как нормальный источник. Не как архив в каталоге «разное», не как закладку на страницу релизов, которую через полгода уже лень открывать.

VPS — не архитектура, а счётчик будущих проблем

Ранее для этой задачи использовались VPS, aptly и скрипты обновления. Схема работала, пока не закончился диск из-за истории релизов. Затем хостер ликвидировал VPS — вместе с репозиторием. Классика: «маленький сервис» внезапно оказывается сервисом, которому нужны диск, мониторинг, бэкапы и план на случай исчезновения железки.

После переустановки системы задача вернулась в исходную точку: старые .deb есть, но нужны свежие версии. Поднимать VPS снова означает снова заводить крон, следить за хранилищем и готовиться к очередной аварии. То есть обслуживать инфраструктуру ради нескольких пакетов. Отличный способ превратить домашний репозиторий в побочный прод.

GitHub Pages здесь тоже не стал готовым ответом: для размещения пришлось бы физически загружать .deb, а у сервиса есть ограничение в 10 МБ на файл. Если артефакты уже лежат в GitHub Releases и доступны по прямым ссылкам, дублировать их в ещё одном хранилище — сомнительная оптимизация.

Workers как тонкий слой между APT и релизами

В описанной схеме Cloudflare Workers становятся прослойкой публикации APT-репозитория, а сами пакеты остаются в релизах GitHub. Ключевой результат — нет своего веб-сервера. Значит, нет отдельной VPS, которую надо патчить, оплачивать, мониторить и потом героически восстанавливать из бэкапа, о существовании которого все вспомнили после инцидента.

Для веб-разработчиков тут ценен не только рецепт для Linux-десктопа. Это нормальный паттерн: не тащить состояние туда, где оно не нужно. GitHub хранит релизные файлы, Worker отдаёт нужную репозиторную обвязку, а apt получает привычную точку установки. Компоненты разделены по обязанностям, а не свалены на один дешёвый сервер «пока хватает».

Перед повторением такой схемы стоит проверить три вещи: где лежат исходные пакеты, можно ли обращаться к ним по прямой ссылке и какие данные репозитория должен публиковать слой на Workers. И да, бэкапы всё равно нужны. Особенно если кажется, что теперь-то серверов нет и ломаться нечему.