Apt-Cacher NG
Last updated
Was this helpful?
Last updated
Was this helpful?
Любая современная система требует регулярного обновления и Linux не исключение, но как бы ни был организован этот процесс мы столкнемся с постоянной нагрузкой на канал и повышенным расходом трафика, так как каждый компьютер будет скачивать обновления самостоятельно из сети интернет. При этом, даже если вас не волнует трафик, данный процесс занимает время и не всегда зеркала репозиториев отдают данные на хорошей скорости, поэтому становится актуальным создание локального кеша пакетов, в чем нам поможет Apt-Cacher NG. Его просто установить и еще проще использовать.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Как указано в заголовке, Apt-Cacher NG - кеширующий прокси-сервер, который становится посредником между клиентом и зеркалом репозитория и сохраняет в собственное хранилище все загруженные из сети пакеты. При повторном запросе он проверит кеш и при наличии в нем требуемого пакета отдаст его локально. Это позволяет существенно экономить как трафик, так и время и последний фактор сегодня играет все более значимую роль.
Каких-то существенных требований к железу Apt-Cacher NG не предъявляет и прекрасно работает в виртуальной машине или контейнере. Все что вам нужно - это выделить достаточное место для хранилища кеша пакетов. Теоретически его размер может быть равен объему всех используемых репозиториев, но на практике запросы гораздо скромнее и зависят только от разнообразия систем и количества установленных в них пакетов.
Эффективность самого кеша зависит от однородности систем и их количества, чем более однородна инфраструктура и чем больше в ней однотипных ПК, тем больше будет попадания в кеш. Но в любом случае эффект будет достигнут даже если у вас всего несколько машин, при крупных обновлениях все необходимые пакеты скачает первый компьютер, а остальные обновятся локально.
Первоначально Apt-Cacher NG поддерживал только DEB-пакеты, сегодня это универсальный прокси, который можно использовать с любыми пакетными системами, но это выходит за рамки данной статьи и ниже мы будем рассматривать его применение исключительно в среде Debian или Ubuntu.
Установить пакет просто, он есть в стандартных репозиториях:
В процессе установки вам будет задан вопрос: разрешаете ли вы использование HTTP-туннелей. С одной стороны это облегчает работу с программой, в частности при доступе к HTTPS-репозиториям, с другой создает угрозу безопасности, так как пользователи смогут использовать такой туннель не только для скачивания обновлений, но и для выхода в интернет. Если для вас это не критично, то рекомендуем использование туннелей разрешить, что упростит дальнейшую эксплуатацию.
В остальном служба не требует каких-либо настроек и начинает работать сразу после установки, для приема соединений используется порт 3142 TCP. Тем не менее заглянем в конфигурационный файл /etc/apt-cacher-ng/acng.conf.
Прежде всего нам может быть интересна опция, определяющая расположение хранилище кеша пакетов, по умолчанию она имеет значение:
Вы можете задать собственный путь к хранилищу, однако после этого вам потребуется откорректировать его также в файле юнита /lib/systemd/system/apt-cacher-ng.service, для этого используйте команду:
Затем раскомментируйте и замените значение в строке:
Сохраните файл, перечитайте список юнитов systemd и перезапустите службу:
Вторая опция, которая может быть нам интересна - это привязка службы к адресам или интерфейсам, по умолчанию Apt-Cacher NG прослушивает все сетевые интерфейсы. Чтобы изменить это поведение раскомментируйте и измените опцию:
Остальные опции не представляют особого практического интереса.
Если вы при установке не разрешили создание HTTP-туннелей, то доступ к репозиториям использующим HTTPS будет невозможен, поэтому если вы используете такие репозитории, то нужно отдельно прописать разрешения на доступ к ним. Для этого следует использовать отдельный конфигурационный файл, выполним:
Если файл не существует, то он будет создан и открыт на редактирование, иначе просто открыт. Если же вам больше нравится редактор mc, то замените в команде nano на mcedit.
Для примера возьмем репозиторий браузера Opera:
Из него нам нужно узнать адрес, т.е. deb.opera.com, затем добавьте в файл zzz_override.conf запись:
Ничего сложного здесь нет, обычное регулярное выражение, так как символ точки является подстановочным, то экранируем его слешем. Аналогичные записи добавляем для всех интересующих нас репозиториев. После чего перезапускаем службу:
На этом настройка кеширующего прокси-сервера закончена.
Чтобы клиент начал использовать для доступа к репозиториям наш кеширующий сервер его нужно указать в настройках пакетного менеджера APT, для этого создадим отдельный конфигурационный файл:
И внесем в него следующие строки:
Где 192.168.111.72:3142 - адрес и порт нашего кеширующего сервера.
Из всех способов этот самый трудоемкий, но может понадобиться в настольных дистрибутивах, которые могут не использовать APT для управления пакетами и установки обновлений (например, KDE Neon). В этом случае изменения следует внести прямо в адреса репозиториев. Еще один плюс этого метода, что кешировать репозитории можно выборочно. Скажем, если у вас на некоторых узлах есть собственные репозитории, которые больше нигде не используются, то можно не тратить ресурсы кеширующего прокси-сервера на сохранение их пакетов и качать их напрямую.
Для того, чтобы применить данный способ замените адрес репозитория с:
На:
Для HTTPS репозиториев используйте следующую конструкцию:
Добавлять разрешающее правило в zzz_override.conf при этом не нужно.
У двух описанных выше способов есть существенный недостаток: если кеширующий прокси-сервер окажется недоступным, то обновиться не удастся. Плюс требуется вносить изменения в конфигурационные файлы, в этом плане намного привлекательнее выглядит возможность автоматического обнаружения прокси-сервера. Если он обнаружен - то трафик пойдет через него, нет - напрямую.
В этом нам поможет технология Zeroconf, при этом следует отметить, что при ее использовании вы не должны использовать в локальной сети домен верхнего уровня .local.
За поддержку Zeroconf в Linux отвечает служба Avahi, установим ее на сервере:
Apt-Cacher NG уже содержит готовую конфигурацию для Avahi, поэтому отдельно настраивать ничего не нужно. Для нормальной работы службы следует разрешить пакеты на порт 5353 UDP.
На клиенте следует установить пакет squid-deb-proxy-client:
Никаких настроек также не требуется, все начинает работать сразу после переустановки.
Для контроля и управления кеширующим сервером откройте в браузере адрес: http://192.168.111.72:3142/acng-report.html. Здесь вы можете увидеть статистику, включающую общий объем скачанных пакетов и объем данных отданных локально, а также процент попадания в кеш. Данные выводятся в двух разрезах: со времени последнего запуска службы и за все время.
Также здесь можно выполнять операции обслуживания сервера, например, очистить кеш от устаревших пакетов.
Если же перестало работать обновление с сервера, а напрямую обновляется без проблем, то перейдите в раздел Direct actions и последовательно выполните действия Delete unreferenced и Delete damaged.
Как видим, настроить кеширующий прокси для обновлений Debian и Ubuntu совсем несложно, а эксплуатировать его легко. В тоже время вы получите существенную экономию времени и ресурсов на обслуживание парка Linux-систем.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
