Когда у вас не один сервер, а десяток (или сотня), внезапно выясняется: больше всего времени на плановые обновления съедают не CPU и даже не диски, а сеть и повторяющиеся скачивания одних и тех же пакетов. На практике это выглядит так: каждый хост делает apt update или dnf makecache, затем тянет одинаковые .deb/.rpm из интернета, перегревая канал, увеличивая окна обслуживания и создавая лишние точки отказа.
Ниже — админская схема, которая почти всегда даёт быстрый и измеримый эффект: кэширование пакетов и локальная раздача репозиториев для Debian/Ubuntu (APT) и RHEL-подобных (DNF/YUM). Разберём три сценария:
- apt caching proxy через apt-cacher-ng (внедряется быстро, обслуживания минимум);
- локальный deb repo (полный контроль над набором пакетов и версиями);
- зеркало (repo mirror) и/или локальный rpm repo для DNF/YUM (быстрая раздача пакетов и метаданных).
Что выбрать: кэш, локальный репозиторий или зеркало
Термины часто путают, хотя подходы разные — и это важно для правильного ожидания результата.
Кэширующий прокси (например, apt-cacher-ng) не «владеет» репозиторием: он просто переиспользует уже скачанное. Первый клиент тянет пакет из интернета, последующие — получают его локально. Это самый быстрый путь разгрузить внешний канал без перестройки инфраструктуры.
Локальный репозиторий (deb/rpm) — вы храните пакеты и публикуете индекс/метаданные. Это уже «источник истины»: можно закреплять версии, выкладывать свои пакеты, делать внутренний stable и ограничивать обновления только доверенным набором.
Зеркало репозитория (repo mirror) — частный случай локального репозитория, который наполняется синхронизацией с upstream. Хороший выбор, когда нужно быстро и воспроизводимо обновлять много одинаковых систем и не зависеть от внешней доступности.
Если цель — перестать скачивать одно и то же много раз, начинайте с кэша. Если важен контроль версий и управляемые окна обновлений — строите локальный репозиторий или зеркало.
APT: поднимаем apt-cacher-ng как caching proxy
apt-cacher-ng прозрачно кэширует пакеты и индексы APT. В итоге первый сервер скачивает пакет из интернета, остальные получают его уже по LAN. Для типового офиса/парка VM это один из лучших «быстрых выигрышей».
Установка apt-cacher-ng
Размещайте кэш на отдельной машине в том же сегменте, где находятся клиенты (или рядом по L2/L3). На Debian/Ubuntu:
sudo apt update
sudo apt install -y apt-cacher-ng
sudo systemctl enable --now apt-cacher-ng
По умолчанию сервис слушает порт 3142. Проверим:
sudo ss -lntp | grep 3142
sudo systemctl status apt-cacher-ng
Настройка клиентов APT
На клиентах укажите прокси для APT через отдельный конфиг-файл (удобно для Ansible/Salt/Puppet):
sudo tee /etc/apt/apt.conf.d/02proxy >/dev/null <<'EOF'
Acquire::http::Proxy "http://APT-CACHE-HOST:3142";
EOF
Где APT-CACHE-HOST — DNS-имя или IP сервера с apt-cacher-ng.
Проверка: на клиенте делаем apt update, на кэше смотрим лог запросов:
sudo apt update
sudo tail -n 50 /var/log/apt-cacher-ng/apt-cacher.log
Практичные настройки и эксплуатация
Основной конфиг — /etc/apt-cacher-ng/acng.conf. Чаще всего в проде решают три вещи: сетевой доступ, диск и обслуживание кэша.
- Сетевой доступ: лучше ограничить вход с внутренней сети через firewall (или убедиться, что сервис слушает нужный интерфейс).
- Ёмкость диска: даже небольшой парк быстро раздувает кэш. Практический минимум — десятки гигабайт; для активного парка/CI — 100–300 ГБ и больше.
- Экспирация/уборка: периодически проверяйте, что кэш не забивает диск «в ноль».
Быстрый чек по диску и размеру кэша:
sudo du -sh /var/cache/apt-cacher-ng
sudo df -h
Типовые проблемы APT-кэша
Клиент игнорирует прокси. Проверьте, что файл подхватился:
apt-config dump | grep -i proxy
HTTPS-репозитории. APT всё чаще ходит по HTTPS. В некоторых сценариях кэширование HTTPS работает не так прозрачно, как для HTTP. Внутри периметра часто проще либо жить с HTTPS без кэша, либо организовать внутреннее зеркало (и уже его раздавать по HTTP внутри сети, если политика безопасности это допускает). Проверки подписей при этом остаются обязательными.
«Кэш не ускоряет apt update». apt update — это в основном метаданные. Если у вас много разных релизов/архитектур/наборов репозиториев, «попаданий» будет меньше. Максимальный эффект даёт унификация sources.list и расписания обновлений.
APT: локальный deb repo для контроля версий и своих пакетов
Кэш — это ускоритель. Но если вы хотите закреплять версии, переживать недоступность upstream и обновлять сервера только из доверенного источника, нужен локальный deb repo.
Вариантов реализации много (aptly/reprepro и т.д.), но принцип один: вы храните .deb, публикуете индексы (Packages, Release) и подписываете репозиторий ключом. Клиенты подключают репо через sources.list и доверенный ключ.
Минимальный репозиторий «для своих .deb»
Если задача — раздавать только собственные пакеты (например, внутренние утилиты), можно начать с простого индекса. Важно: структура каталогов должна существовать заранее.
sudo apt update
sudo apt install -y dpkg-dev
sudo mkdir -p /srv/debrepo/pool
sudo mkdir -p /srv/debrepo/dists/stable/main/binary-amd64
cd /srv/debrepo
dpkg-scanpackages -m pool /dev/null | gzip -9c > dists/stable/main/binary-amd64/Packages.gz
Такой «скелет» удобен для тестов, но для продакшена почти всегда нужно довести до нормального состояния: выпускать Release, подписывать и правильно раздавать ключи. Иначе вы либо получите ошибки доверия, либо начнёте «временно» отключать проверки — что плохо для цепочки поставки.
Когда локальный repo лучше кэша
- Нужна воспроизводимость: «все сервера ставят ровно эти версии».
- Нужно переживать сбои upstream/CDN без срыва окна обновлений.
- Есть требования комплаенса: обновления только из внутреннего источника.
Рекомендация по публикации: раздавайте репо обычным веб-сервером
Проще всего отдавать /srv/debrepo через Nginx/Apache или встроенную статику, а доступ ограничивать по сети/VPN. Если у вас уже есть инфраструктура, часто удобно держать зеркало/репо на отдельном узле (например, на VDS) в том же сегменте, где живут серверы и CI: так вы снимете зависимость от внешнего канала и получите предсказуемое время обновлений.
DNF/YUM: почему зеркало даёт больше эффекта, чем локальный dnf cache
В RHEL-подобных системах «узкое место» при массовых обновлениях — не только сами пакеты, но и метаданные репозиториев (repodata). Поэтому чаще всего эффективнее строить локальное зеркало (repo mirror) или полноценный локальный yum repository, чем надеяться на «кэш на каждом клиенте».
Локальный кэш DNF помогает повторным операциям на том же хосте. Но если серверов много, внешние скачивания всё равно происходят N раз. Зеркало превращает это в «1 скачивание на зеркало + быстрая раздача по LAN».
Если хотите углубиться в универсальные прокси-кэши и сравнить подходы для APT/YUM, полезно держать под рукой заметку: кэш пакетов через Squid для APT/YUM/DNF.
RPM mirror: reposync + публикация метаданных
На сервере-зеркале синхронизируйте нужные репозитории утилитой reposync. Обычно достаточно сохранять upstream-метаданные, но иногда вы будете пересобирать метаданные сами (если формируете репо из выбранного набора пакетов).
Установка инструментов
sudo dnf install -y dnf-plugins-core createrepo_c
sudo mkdir -p /srv/rpmrepo
Синхронизация репозитория
Посмотрите имена репо в системе:
dnf repolist
Пример синхронизации репозитория в каталог с метаданными:
sudo reposync -p /srv/rpmrepo --repoid=baseos --download-metadata
Если вы собираете репозиторий «вручную» из произвольных RPM, пересоздайте метаданные:
sudo createrepo_c /srv/rpmrepo
Подключение клиентов к локальному yum repository
На клиентах создайте файл в /etc/yum.repos.d/ и укажите внутренний baseurl (подставьте ваш хост и путь). Если зеркало раздаётся по HTTP внутри сети, не забудьте ограничить доступ по периметру.
sudo tee /etc/yum.repos.d/local-mirror.repo >/dev/null <<'EOF'
[local-mirror]
name=Local RPM mirror
baseurl=http://REPO-HOST/rpmrepo/
enabled=1
gpgcheck=1
EOF
Далее очистите кэш и проверьте метаданные:
sudo dnf clean all
sudo dnf makecache
sudo dnf repolist
Архитектура и расписание: чтобы метаданные не «ломались» во время синка
Сама установка инструментов — половина дела. Вторая половина — организовать публикацию так, чтобы клиенты не попадали в момент, когда метаданные уже обновились, а пакеты ещё не докачались (или наоборот).
- Один кэш/зеркало на сегмент: филиалы, отдельные DC, VLAN — лучше обслуживать локально.
- Единые источники: одинаковые репозитории и релизы ОС дают максимум повторного использования (и меньше сюрпризов при обновлениях).
- Разведите по времени: зеркало обновляется ночью, клиенты — утром. Так меньше шансов поймать несогласованные метаданные.
- Контроль диска и inode: зеркала растут рывками, особенно при переходах между минорными релизами.
Диагностика: как понять, что ускорение реально работает
APT
- На клиенте:
apt-config dump | grep -i proxy— прокси применился? - На сервере apt-cacher-ng: растёт ли кэш и видны ли запросы в
/var/log/apt-cacher-ng/apt-cacher.log. - Сравните время установки одного «тяжёлого» пакета на первом и втором сервере: второй должен быть заметно быстрее (LAN вместо интернета).
DNF/YUM
dnf repolist— клиент видит локальный репозиторий?dnf makecacheпослеdnf clean all— метаданные скачиваются быстро и стабильно?- Проверьте, что репозиторий реально отдаёт
repodataи что клиент не ходит в интернет по старым репо.
Ошибки, которые встречаются чаще всего
Пытаются решить всё одним инструментом. Для APT почти всегда проще начать с apt-cacher-ng. Для DNF/YUM чаще всего выигрывает зеркало (repo mirror). Универсальные прокси-кэши возможны, но сложнее в сопровождении и диагностике.
Нет контроля подписей. Локальный repo — часть цепочки поставки. Не отключайте проверки подписи «ради удобства». Лучше один раз правильно настроить ключи и подпись репозитория.
Синхронизация зеркала в рабочее время. Во время обновления зеркала метаданные могут стать несогласованными с набором пакетов. Решение: синк по расписанию и/или атомарная публикация (синхронизировать в отдельный каталог и переключать ссылку/путь после окончания).
Нет места на диске. Кэш и зеркала растут незаметно и рывками. Заранее закладывайте запас, мониторинг и политику очистки.
Практический итог
Чтобы ускорить apt update и установки на Debian/Ubuntu, начните с apt-cacher-ng: внедрение занимает минуты, эффект заметен сразу. Если нужен контроль версий и независимость от внешних репозиториев — стройте локальный deb repo или зеркало.
Для RHEL-подобных систем лучший «первый шаг» — локальный repo mirror и раздача по LAN: это резко сокращает внешний трафик, ускоряет обслуживание и делает обновления предсказуемее.
