"С блэкджеком и CI/CD": как собрать APT-репозиторий на GitHub и Cloudflare Workers
В Linux давно существует удобная модель управления программами: пакетный менеджер умеет находить, устанавливать, обновлять и удалять приложения, а также самостоятельно разрешать зависимости. В Debian и Ubuntu за это отвечает APT. Однако далеко не весь полезный софт доступен в официальных репозиториях.
Разработчики нередко публикуют программы только на собственных сайтах, в GitHub Releases, в виде статических бинарников или исходного кода. Последний вариант особенно неудобен: для сборки на новом компьютере приходится заново устанавливать множество пакетов `*-dev`, компиляторы и библиотеки. Статические бинарники тоже требуют ручной работы - нужно создать `.desktop`-файл, добавить приложение в `PATH`, продумать обновления и не забыть о зависимостях.
Автор много лет использовал Linux в качестве основной системы и постепенно столкнулся со всеми этими проблемами. Сначала программы устанавливались вручную, а система обрастала пакетами для сборки. Затем появилась виртуальная машина с аналогичным окружением, а позже - Dockerfile для воспроизводимой сборки. Docker упростил компиляцию, но не решил задачу доставки: собранные пакеты всё равно приходилось переносить между компьютерами вручную.
От VPS к бессерверной архитектуре
Следующим шагом стал собственный APT-репозиторий на VPS, созданный с помощью aptly. Скрипты загружали обновления, формировали индексы и публиковали пакеты. Первое время всё работало, но затем проявились типичные недостатки такой схемы: закончился диск из-за хранения истории релизов, а после закрытия VPS хостингом исчезла и вся инфраструктура.
После переустановки ноутбука возникла необходимость поставить привычные приложения заново, но уже без ручного поиска свежих `.deb`-файлов. Хотелось получить решение, которое будет дешёвым, надёжным и не потребует постоянного администрирования. Так появилась идея использовать GitHub Releases как хранилище пакетов, а облачные сервисы - для публикации метаданных и маршрутизации запросов.
В результате создание собственного APT-репозитория на GitHub стало основой всей системы. Файлы `.deb` размещаются в релизах GitHub, текстовые индексы APT публикуются через Cloudflare Pages, а перенаправлением запросов занимается Cloudflare Workers. Такой подход не требует отдельного сервера, резервного копирования диска и постоянного контроля за состоянием VPS.
Как устроена схема
Логика разделена между тремя ветками одного Git-репозитория:
- `apps` - описание приложений и параметры их сборки;
- `apt` - опубликованные метаданные Debian-репозитория;
- `worker` - исходный код маршрутизаторов Cloudflare Workers.
Пользователь добавляет репозиторий в систему обычным способом. APT запрашивает файлы `Release`, `Packages` и другие индексы с Cloudflare Pages. Когда требуется скачать сам пакет, Worker перенаправляет запрос на нужный файл в GitHub Releases.
Так достигается важное разделение: индексы остаются небольшими текстовыми файлами, а тяжёлые бинарные данные не занимают место в Git и не хранятся на сервере. Подробное описание подобной архитектуры и практические детали реализации можно найти в материале о [бессерверном APT-репозитории на GitHub и Cloudflare](https://habr.com/ru/articles/1062422/?utm_campaign=1062422&utm_source=habrahabr&utm_medium=rss).
Сборка и публикация пакетов
При появлении новой версии исходного проекта GitHub Actions запускает workflow. Он устанавливает необходимые зависимости, собирает `.deb`, проверяет результат и создаёт новый GitHub Release. В сам Git бинарные файлы не добавляются - это позволяет сохранять репозиторий компактным.
После сборки формируются APT-метаданные. В них указываются имя пакета, версия, архитектура, размер файла и URL, по которому клиент сможет его скачать. Сгенерированные индексы отправляются в ветку `apt`, а Cloudflare Pages автоматически публикует изменения.
Именно так реализуется CI/CD для сборки и публикации Debian-пакетов: разработчику достаточно изменить описание приложения или запустить workflow вручную, а дальнейшие операции выполняются автоматически. Для пользователя обновление выглядит привычно:
```bash
sudo apt update
sudo apt install имя-пакета
```
Для полноценной настройки APT-репозитория для Debian и Ubuntu также потребуется добавить ключ подписи, файл `.list` или `.sources`, а затем проверить корректность структуры каталогов `dists/` и `pool/`. Даже если пакет физически хранится в GitHub Releases, APT должен получить корректные и согласованные индексы.
Зачем здесь Cloudflare Workers
Cloudflare Workers выполняет роль лёгкого HTTP-роутера. Он анализирует входящий запрос, определяет нужный пакет и возвращает перенаправление на соответствующий URL GitHub Release. При этом не нужно поднимать nginx, настраивать TLS, следить за дисковым пространством или оплачивать постоянно работающую виртуальную машину.
Cloudflare Workers для APT-репозитория особенно удобны там, где пакеты имеют разные версии, архитектуры или каналы обновлений. Логику маршрутизации можно расширить: добавить проверку имени дистрибутива, разделить stable и testing, настроить кэширование или возвращать понятные ответы для отсутствующих файлов.
Важная деталь - подпись метаданных. APT не должен безоговорочно доверять любому набору индексов, поэтому репозиторий следует подписывать собственным GPG-ключом. Публичный ключ распространяется вместе с инструкцией по установке, а закрытый ключ хранится в секретах GitHub Actions. Это позволяет автоматически подписывать новые публикации, не размещая ключ на сервере.
Автоматизация и дальнейшее развитие
Автоматизация публикации deb-пакетов через GitHub Actions сокращает число ручных операций и делает выпуск воспроизводимым. В workflow можно добавить линтеры, проверку зависимостей, тестовую установку пакета в чистом контейнере и контроль соответствия архитектур. Полезно также автоматически удалять неудачные релизы и уведомлять о сбоях сборки.
Для небольшого личного набора приложений такая архитектура почти не требует обслуживания. GitHub хранит историю релизов и исходные описания, Cloudflare раздаёт метаданные и выполняет маршрутизацию, а клиентская система работает с репозиторием как с обычным источником пакетов.
При росте проекта стоит заранее продумать политику хранения версий. Старые релизы занимают место и могут быть нужны для отката, но бесконечно сохранять их не всегда разумно. Оптимальный вариант - оставлять несколько последних стабильных сборок, а критичные версии архивировать отдельно.
Таким образом, APT-репозиторий можно построить без собственной VPS и сложной серверной инфраструктуры. Связка GitHub Releases, GitHub Actions, Cloudflare Pages и Workers превращает выпуск пакетов в понятный конвейер: исходное описание запускает сборку, workflow создаёт релиз, индексы публикуются автоматически, а Debian и Ubuntu получают обновления через привычный `apt`.
