TGViewer
Записки IT специалиста Записки IT специалиста @interface31 · 9.03K subscribers
Post #4339 2.86K
​​Кеширующий прокси или зеркало репозитория?

Уже не первый раз сталкиваемся с тем, что начинающие администраторы путают эти два понятия. Поэтому попробуем внести ясность.

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

Дополнительными негативными факторами могут быть скорость канала или скорость доступа к репозиториям. Все это заставляет задуматься о том, как решить проблему.

Первое что приходит на ум – это локальное зеркало репозитория. Создать его несложно, для этого есть штатная утилита apt-mirror. С ее помощью можно поддерживать на собственных ресурсах полную копию репозиториев системы.

Но тут возникают иные сложности, так, например, размер репозиториев текущей версии Debian для архитектуры amd64 составляет 778 ГБ, сюда как минимум следует добавить all и еще 258 ГБ. Получаем примерно 1 ТБ требуемого дискового пространства.

Если у нас в эксплуатации несколько систем, то зеркала репозиториев нужно будет организовать для каждой из них. При переходе на новую версию – добавить новые репозитории.

В итоге получаем весьма значительное расходование места, причем достаточно бесполезное, поскольку по факту вы будете использовать лишь малую его часть.

Уменьшить размер локальных репозиториев в целом можно, например, скачав только самые нужные или оставив только последние версии пакетов, но все это не устраняет общей проблемы – значительный перерасход места.

Альтернатива локальному репозиторию – кеширующий прокси-сервер. Он работает по схожему, но несколько иному принципу.

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

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

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

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

При этом размер кеша будет равен размеру реально используемых пакетов и их версий. И разница с локальным репозиторием получается где-то на порядок.

Поэтому для большинства сценариев оптимальным будет использование именно кеширующего прокси.

Локальные репозитории в свою очередь следует использовать для закрытого контура или крупных систем с узким внешним каналом.

Настроить кеширующий прокси Apt-Cacher NG можно по нашей статье: Установка и настройка Apt-Cacher NG - кеширующего прокси-сервера обновлений для Debian и Ubuntu
  • 👍 33
  • ⚡ 2
  • ❤ 1
More from @interface31
  1. Oct 16, 2026Авторское право – не пустой звук Сегодня с одним нашим коллегой и молодым автором произоше…
  2. Oct 16, 2026Post #6891
  3. Oct 16, 2026Selectel обновил пользовательское соглашение. А что там? Правильно: 6.4. Исполнитель не не…
  4. Oct 16, 2026Post #6889
  5. Oct 15, 2026И еще немного про алиасы в PowerShell PowerShell предлагает большой набор встроенных алиас…
  6. Oct 15, 2026Post #6883
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →