APT proxy on Debian/Ubuntu: apt-cacher-ng для ускорения apt update в локальной сети

Зачем нужен APT proxy и чем полезен apt-cacher-ng

Когда у вас десятки виртуальных машин, контейнерных нод или просто парк серверов на Debian/Ubuntu, обновления превращаются в постоянное скачивание одних и тех же .deb и метаданных репозиториев. Особенно заметно это на CI-агентах, в тестовых окружениях и при массовых security-апдейтах.

apt-cacher-ng — лёгкий кэширующий APT-прокси: ставите его на один хост, клиенты начинают скачивать пакеты через него, а сервер кэширует запрошенное. Следующий клиент, запросивший тот же файл, получает его уже из локального кэша. В итоге apt update и apt install выполняются быстрее, внешний трафик снижается, а нагрузка на зеркала и аплинк — тоже.

Важно: apt-cacher-ng — не «полное зеркало». Он не тянет репозиторий целиком заранее, а накапливает кэш по мере обращений клиентов.

Типичный сценарий: один небольшой сервер (или отдельная ВМ) с apt-cacher-ng в подсети и множество Debian/Ubuntu-хостов, которые ходят на него за пакетами.

Архитектура и ограничения (особенно про HTTPS)

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

• HTTP-репозитории кэшируются «из коробки» и дают максимальный эффект.
• HTTPS сложнее: трафик шифруется end-to-end, и кэширующий прокси не всегда видит содержимое так, чтобы эффективно переиспользовать кэш. В реальности apt-cacher-ng всё равно может быть полезен (частично), но ожидания стоит скорректировать.
• Безопасность: APT проверяет подписи Release/InRelease и хэши. Это важнее, чем транспорт, но политика организации может требовать HTTPS для отдельных источников.

Практический вывод: apt-cacher-ng чаще всего окупается даже при частичном кэшировании — особенно если у вас много одинаковых базовых пакетов на множестве хостов.

Установка apt-cacher-ng на Debian/Ubuntu

Выделите хост под «центральный» APT proxy. По CPU требования обычно минимальные; важнее диск под кэш и стабильная сеть. Для небольшой команды часто достаточно 20–50 ГБ, но для CI и частых пересборок лучше планировать больше.

Установка:

sudo apt update
sudo apt install apt-cacher-ng

Проверяем, что сервис запущен и слушает порт 3142:

sudo systemctl status apt-cacher-ng
sudo ss -lntp | grep 3142

Если включён firewall или security groups, открывайте 3142/tcp только для нужных подсетей (делать такой прокси публичным точно не нужно).

Базовая настройка сервера: порт, кэш, bind и контроль доступа

Основной конфиг обычно находится в /etc/apt-cacher-ng/acng.conf. Перед правками сохраните копию:

sudo cp -a /etc/apt-cacher-ng/acng.conf /etc/apt-cacher-ng/acng.conf.bak

Параметры, которые чаще всего трогают на практике:

• Port — порт сервиса.
• CacheDir — каталог кэша (по умолчанию обычно /var/cache/apt-cacher-ng).
• LogDir — каталог логов.
• BindAddress — на каком IP слушать (полезно, чтобы не слушать на всех интерфейсах).
• ACL/ограничение клиентов — названия опций отличаются по версиям, поэтому лучше ориентироваться на комментарии в вашем acng.conf.

Пример «приземлённой» настройки: слушаем только внутренний адрес и используем стандартные пути. Если вы добавляете ACL, сверьтесь с документацией/комментариями вашей версии пакета.

sudo nano /etc/apt-cacher-ng/acng.conf

# пример: адаптируйте под вашу сеть
Port:3142
BindAddress:10.10.0.10
CacheDir:/var/cache/apt-cacher-ng
LogDir:/var/log/apt-cacher-ng

Перезапуск и быстрая проверка:

sudo systemctl restart apt-cacher-ng
sudo journalctl -u apt-cacher-ng -n 200 --no-pager

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Подключаем клиентов Debian/Ubuntu: два рабочих способа

На клиентах обычно используют один из подходов: задать прокси в конфиге APT (самый удобный и легко откатываемый вариант) или переписать адреса репозиториев так, чтобы они ходили через apt-cacher-ng.

Способ 1: прокси для APT через apt.conf.d (рекомендуется)

Создайте файл на клиенте:

sudo nano /etc/apt/apt.conf.d/01proxy

Для HTTP-источников:

Acquire::http::Proxy "http://10.10.0.10:3142";

Если у вас есть HTTPS-источники и вы хотите направлять их через этот же прокси, добавьте:

Acquire::https::Proxy "http://10.10.0.10:3142";

Дальше:

sudo apt update

Плюс этого способа — быстрый откат: удаляете один файл, и APT возвращается к прямым обращениям.

Способ 2: переписывание URL репозиториев под «входную точку» прокси

Иногда инфраструктурно удобнее сделать apt-cacher-ng «единым адресом» и перенастроить sources.list / sources.list.d. Но это требует дисциплины: централизованного управления (Ansible/Salt/Puppet), тестов на всех поддерживаемых релизах и планов быстрого переключения на прямые зеркала.

Если у вас много систем и вы активно работаете с кэшем, полезно также почитать про общие приёмы кэширования на веб-уровне (подходы к экономии трафика и ускорению выдачи): HTTP Range и кэш в Nginx/Apache.

Как проверить, что кэш реально работает

Вот несколько быстрых проверок, которые помогают «поймать» эффект:

• Посмотреть логи apt-cacher-ng во время apt update / apt install на клиентах.
• Поставить один и тот же пакет на двух машинах подряд: второй прогон обычно заметно быстрее.
• Проверить рост каталога кэша.

Команды на сервере:

sudo tail -n 200 /var/log/apt-cacher-ng/acng.log
sudo du -sh /var/cache/apt-cacher-ng
sudo find /var/cache/apt-cacher-ng -type f | wc -l

На клиенте для отладки полезен подробный вывод:

sudo apt -o Debug::Acquire::http=true update

Тюнинг под прод: диск, рост кэша и обслуживание

Главный ресурс apt-cacher-ng — дисковое пространство. Кэш растёт тем быстрее, чем больше у вас сочетаний: разные дистрибутивы/релизы (Debian 11/12, Ubuntu 22.04/24.04), архитектуры, отдельные сторонние репозитории.

• Небольшой парк (10–20 хостов): часто хватает 20–50 ГБ.
• CI и частые пересборки: обычно разумно 100+ ГБ.
• Сборка базовых контейнерных образов: кэш «отбивается» быстро, но и растёт заметнее.

В проде важны две вещи: не допускать переполнения раздела и не чистить кэш слишком агрессивно, чтобы не терять ускорение. Механизмы очистки и «сроки жизни» объектов зависят от версии apt-cacher-ng, поэтому ориентируйтесь на комментарии в acng.conf и доступные утилиты обслуживания в вашей сборке.

Минимальный мониторинг:

df -h /var/cache/apt-cacher-ng
sudo du -sh /var/cache/apt-cacher-ng

Если у вас прокси стоит на маленькой ВМ, часто проще и дешевле добавить диск или вынести кэш на отдельный том, чем регулярно «выжирать» кэш и терять смысл решения. Для таких задач удобно брать отдельный небольшой VDS рядом с вашим контуром.

Типовые проблемы и быстрый разбор

Клиенты не могут подключиться к APT proxy

• Проверьте, что сервис слушает порт: ss -lntp на сервере.
• Проверьте доступность порта из подсети (firewall/security group/ACL).
• Если задан BindAddress, убедитесь, что указан правильный IP.

sudo ss -lntp | grep 3142
sudo journalctl -u apt-cacher-ng -n 200 --no-pager

apt update работает, но ускорения почти нет

• Первый прогон всегда медленнее: кэш ещё пустой.
• Если большинство источников — HTTPS, эффект может быть слабее ожидаемого.
• Убедитесь, что клиент действительно использует прокси (включите debug-лог).
• Проверьте диск на сервере (IOPS/задержки) и сетевую латентность до него.

Ошибки 403/407 и «цепочка прокси» в корпоративной сети

Если в периметре уже есть корпоративный прокси, иногда получается цепочка: клиент → apt-cacher-ng → корпоративный прокси → интернет. Это нормальная схема, но важно понимать, где происходит авторизация и кто за что отвечает (доступ наружу, кэширование, аудит).

На практике часто удобнее сделать apt-cacher-ng единой точкой для серверов, а уже ему разрешить исходящий доступ по правилам вашей сети.

Практика: массовое подключение через конфиг-менеджмент

Чтобы не править руками десятки машин, обычно раскатывают файл /etc/apt/apt.conf.d/01proxy централизованно (Ansible/Salt/Puppet). Ниже — простой пример команд, который легко завернуть в задачу оркестратора:

echo 'Acquire::http::Proxy "http://10.10.0.10:3142";' | sudo tee /etc/apt/apt.conf.d/01proxy
sudo apt update

Откат:

sudo rm -f /etc/apt/apt.conf.d/01proxy
sudo apt update

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Рекомендации по эксплуатации: что реально важно

• Ограничьте доступ к порту прокси нужными подсетями. Не поднимайте apt-cacher-ng как публичный сервис.
• Следите за диском: переполненный раздел превращает обновления в аварийный инцидент.
• Держите план B: возможность быстро убрать прокси с клиентов (удалить один файл) — лучший сценарий отката.
• Не усложняйте sources без нужды: начните с прокси через apt.conf.d.
• Разделяйте контуры: если есть prod/stage/CI, иногда выгоднее два небольших прокси, чем один общий.

Короткий чек-лист запуска

1. Установили apt-cacher-ng на сервер, проверили порт 3142.
2. Ограничили доступ по сети (firewall/ACL/security groups).
3. На клиентах создали /etc/apt/apt.conf.d/01proxy с Acquire::http::Proxy.
4. Запустили apt update на 2–3 хостах, проверили логи и рост кэша.
5. Включили мониторинг диска и подготовили быстрый откат.

Дальше можно добавлять тюнинг под вашу реальность: отдельные прокси на контуры, цепочку с корпоративным прокси и политику обслуживания кэша.