Кэш для пакетных менеджеров: Squid для apt/yum/dnf на VDS

Кэш пакетов на уровне сети — одна из самых недооценённых оптимизаций в инфраструктуре. Там, где есть несколько серверов, CI-агенты или сборочные машины, одни и те же пакеты скачиваются снова и снова при каждом обновлении или билд-джобе. В результате теряем минуты и гигабайты без какой-либо пользы. Простой и проверенный путь сократить издержки — развернуть на VDS универсальный кэширующий прокси Squid и направить через него пакетные менеджеры apt, yum и dnf.

Кому и когда это нужно

Если у вас один сервер и редкие обновления, выгода будет скромной. Но уже с 3–5 узлами, регулярными apt upgrade, dnf update и активным CI/CD эффект заметен: быстрее накатываются обновления, уменьшается внешняя загрузка сети, а при проблемах с зеркалами часть артефактов берётся из локального кэша.

• Ферма сборочных агентов (GitLab Runner, Jenkins), где один и тот же пакет притягивается десятки раз в день.
• Тестовые среды с частыми переустановками или развёртываниями контейнерных образов, которым нужны системные зависимости.
• Изолированные площадки с лимитом трафика или нестабильной связностью до внешних зеркал.

Архитектура и ограничения

Используем классическую схему «forward proxy»: на VDS поднимается Squid, к нему по явному адресу и порту подключаются клиенты (ваши сервера), а он проксирует запросы к публичным репозиториям. Такой подход не требует прозрачного перехвата трафика и сложных сетевых настроек.

Важный момент: полноценное кэширование HTTPS содержимого пакетов без MITM невозможно. Большинство репозиториев доступно как по HTTPS, так и по HTTP. Мы делаем ставку на HTTP-зеркала для кэшируемого трафика и полагаемся на подписи пакетов и метаданных (GPG) для проверки целостности. Это нормальная и широко используемая практика для внутреннего кэша.

Итог: кэшируем HTTP-запросы к зеркалам, а HTTPS либо обходим напрямую, либо проксируем без кэширования через CONNECT. Подписи обеспечивают безопасность контента.

Требования к ресурсам

Squid любит быстрый диск и немного оперативной памяти:

• Диск: чем выше IOPS, тем лучше. Для кэша пакетов полезно 50–200 ГБ в зависимости от разнообразия дистрибутивов и частоты обновлений.
• Память: 512–2048 МБ под индекс кэша и активные объекты обычно достаточно для средних инсталляций.
• Сеть: исходящий канал важнее входящего для VDS, но в кэше трафик быстро локализуется.

Файловая система: ext4 или xfs подойдут. Опционально рассмотрите монтирование с noatime для снижения нагрузки на журналирование доступа.

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

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

Подробнее

Установка Squid

Debian/Ubuntu

sudo apt update
sudo apt install -y squid
sudo systemctl enable --now squid

RHEL/CentOS/AlmaLinux/Rocky

sudo dnf install -y squid
sudo systemctl enable --now squid

Стандартный порт — 3128. По умолчанию конфигурация открыта минимально; всё равно рекомендуем явно ограничить доступ.

Базовая конфигурация squid.conf

Ниже — минимальная, но практичная конфигурация для кэширования крупных объектов (.deb, .rpm) и метаданных. Параметры подобраны консервативно, чтобы избежать «штормов» и проблем с частичной загрузкой.

# /etc/squid/squid.conf
# Слушаем только на внешнем интерфейсе или на 0.0.0.0 при наличии файрвола
http_port 3128

# Память под частые и маленькие объекты
cache_mem 256 MB

# Дисковый кэш: под большие файлы пакетов
cache_dir ufs /var/spool/squid 50000 16 256
maximum_object_size 2000 MB

# Разрешить кэширование range-запросов (частичные докачки)
range_offset_limit -1

# Экономия трафика при прерывании клиентом — докачиваем до конца в кэш
quick_abort_min 0 KB
quick_abort_max 0 KB

# Снижаем шторм однотипных запросов
collapsed_forwarding on
pipeline_prefetch on

# Локали и кодировка логов
strip_query_terms off
uri_whitespace strip

# ACL: разрешаем только выбранным подсетям или хостам
acl localnet src 10.0.0.0/8
acl localnet src 192.168.0.0/16
acl localnet src 172.16.0.0/12
http_access allow localnet
http_access deny all

# Политики кэширования для метаданных и пакетов
refresh_pattern -i \.(deb|udeb|rpm|drpm)$ 129600 100% 129600
refresh_pattern -i (Packages|Sources|InRelease|Release|Release\.gpg)$ 60 20% 1440
refresh_pattern -i (repodata/.*\.(xml|xml\.gz|sqlite|sqlite\.bz2))$ 60 20% 1440
refresh_pattern . 0 20% 4320

# Логи
access_log daemon:/var/log/squid/access.log squid
cache_log /var/log/squid/cache.log

# DNS и время ожидания
dns_v4_first on
positive_dns_ttl 1 hours
negative_dns_ttl 5 minutes
connect_timeout 10 seconds
read_timeout 5 minutes
request_timeout 5 minutes

# Без аутентификации по умолчанию

Пояснения:

• cache_dir и maximum_object_size рассчитаны на крупные пакеты. Если храните много разных дистрибутивов, увеличьте размер cache_dir.
• collapsed_forwarding предотвращает дубликаты одновременных запросов к одному и тому же URL по разным клиентам.
• refresh_pattern задаёт TTL для типов файлов. Для пакетов — дни, для метаданных — минуты/часы.

Ограничение доступа и файрвол

Не оставляйте прокси открытым в Интернет. Минимум — ACL по исходящим IP ваших серверов, как показано выше. Дополнительно закройте порт 3128 файрволом. Для быстрых правил на Ubuntu:

sudo ufw allow from 192.168.10.0/24 to any port 3128 proto tcp
sudo ufw deny 3128/tcp

На системах с firewalld:

sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.10.0/24 port protocol=tcp port=3128 accept'
sudo firewall-cmd --permanent --add-port=3128/tcp --zone=drop
sudo firewall-cmd --reload

Опционально: базовая аутентификация

Если у вас разнородные сети, добавьте auth. Для простоты — basic auth. Не используйте его как единственную меру защиты в небезопасных сетях.

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/squid/passwd ci-agent
sudo chown proxy: /etc/squid/passwd

# Фрагмент /etc/squid/squid.conf
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic realm Squid proxy
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
http_access deny all

Перезапустите сервис:

sudo systemctl restart squid

Настройка клиентов: apt

Для Debian/Ubuntu можно задать глобальный прокси для HTTP и отключить проксирование HTTPS, чтобы не путать кэш с непрозрачным CONNECT-трафиком:

sudo tee /etc/apt/apt.conf.d/01proxy >/dev/null << 'EOF'
Acquire::http::Proxy "http://192.0.2.10:3128";
Acquire::https::Proxy "DIRECT";
Acquire::Retries "3";
EOF

Если ваши источники в /etc/apt/sources.list и /etc/apt/sources.list.d указывают на HTTPS-зеркала, и вы хотите кэш, переведите их на HTTP-варианты зеркал (там, где это доступно). Подписи InRelease/Release.gpg обеспечивают проверку целостности. Дальше всё прозрачно: apt update и apt install автоматически пойдут через прокси и начнут накапливать кэш.

Настройка клиентов: yum/dnf

Для RHEL-семейства добавьте строку proxy в конфиг:

sudo sh -c 'echo proxy=http://192.0.2.10:3128 >> /etc/dnf/dnf.conf'

Аналогично для /etc/yum.conf на старых системах. Если репозитории используют metalink и HTTPS, кэширование не сработает. В таких случаях указывайте baseurl с HTTP-зеркалом для тех репозиториев, где вы хотите экономию трафика, сохраняя GPG-подписи включёнными.

Проверка: HIT/MISS и прирост скорости

Первый запрос к пакету всегда MISS, последующие — HIT. Смотрите логи:

sudo tail -f /var/log/squid/access.log

Ищите коды вида TCP_HIT, TCP_MEM_HIT, TCP_MISS. Для агрегированной статистики:

squidclient -h 127.0.0.1 -p 3128 mgr:info | sed -n '1,120p'

Быстрый практический тест — дважды скачать один и тот же пакет на двух разных серверах и сравнить время и исходящий трафик из VDS наружу. На втором скачивании исходящий трафик с VDS во внешнюю сеть минимален, а отдача идёт локально из кэша.

Тонкая настройка кэша

Политики refresh_pattern

Метаданные меняются чаще всего. Слишком высокий TTL на InRelease, repomd.xml даст устаревший список пакетов. Практика:

• Пакеты (.deb, .rpm): от суток до нескольких дней.
• Индексы (Packages, repodata/*.xml): минуты-час.

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

Range-запросы и большие файлы

Пакетные менеджеры часто докачивают части файлов. Ключ range_offset_limit -1 позволяет складывать в кэш даже частичные диапазоны, что повышает шанс HIT при повторных загрузках. Подробно о диапазонах читайте в статье HTTP Range и кэш в Nginx и Apache.

Снятие нагрузки «штормов»

collapsed_forwarding on — must-have в CI-сценариях: десяток агентов, начавших update одновременно, сформируют единый запрос к зеркалу, а остальные получат данные из очереди или кэша.

Размеры кэша и память

Увеличивая cache_mem, вы помогаете выдавать горячие небольшие объекты из RAM. Но пакеты крупные, выигрывают от дискового кэша. Следите за свободным местом и периодически проверяйте долю HIT по байтам — именно она важна для экономии трафика.

Обслуживание и обновления

Ротация логов настроена пакетами дистрибутива. Проверяйте состояние:

systemctl status squid
sudo squid -k parse
sudo squidclient -h 127.0.0.1 -p 3128 mgr:counters | sed -n '1,120p'

Иногда полезно «подогреть» кэш после чистой инсталляции: выполнить apt update и dnf makecache на нескольких клиентах. При крупных обновлениях дистрибутива кэш может накапливать много старых пакетов — Squid сам их вычищает по LRU, но если нужно «сбросить» кэш целиком, делайте это планово в тихое время.

Безопасность и комплаенс

• Ограничивайте доступ ACL и файрволом. Открытый прокси — риск злоупотреблений.
• Не пытайтесь расшифровывать клиентский HTTPS-трафик ради кэширования — это усложняет инфраструктуру и не требуется для нашей цели.
• Оставляйте проверку GPG-подписей включённой на клиентах, чтобы гарантировать целостность контента.

Типичные проблемы и решения

• 403/Access Denied: проверьте ACL в squid.conf и файрвол. Часто забывают добавить подсеть или конкретный хост.
• Нет HIT по HTTPS: это ожидаемо. Для кэширования используйте HTTP-зеркала там, где это возможно.
• Медленно при одновременных update: включите collapsed_forwarding, проверьте диск и IOPS.
• SELinux блокирует порт 3128 на RHEL-системах: проверьте контекст и разрешения через semanage port -a -t squid_port_t -p tcp 3128 при необходимости.
• Прерывания загрузок клиентом: убедитесь в настройках quick_abort_min/max, чтобы докачка завершалась в кэш.

Альтернативы и когда они уместны

Если у вас исключительно Debian/Ubuntu, имеет смысл рассмотреть специализированные кэши для apt. Но преимущество Squid — универсальность: один прокси обслуживает и apt, и yum/dnf, и любые другие HTTP-загрузки, сохраняя единый контроль доступа и логи.

Итоги

Squid на VDS как кэширующий прокси для пакетных менеджеров — простой способ ускорить обновления, уменьшить внешнее потребление трафика и повысить устойчивость к сбоям зеркал. Достаточно один раз настроить аккуратные ACL, разумные refresh_pattern и параметры для крупных объектов, затем прописать прокси в apt и dnf — и уже со второго скачивания пакетов вы увидите стабильные HIT в логах и более быстрые деплои.

Точка входа минимальна: поставить Squid, ограничить доступ, включить кэш для .deb и .rpm, направить клиентов. Дальше остаётся лишь наблюдать за метриками, подстраивать TTL для метаданных и, по мере роста инфраструктуры, масштабировать кэш по диску и памяти.