squid и кеширование загрузок dnf / yum
. Извините, если это вопрос новичка. Сначала я пытаюсь описать ситуацию, затем придет квест-кальмар. Это также используется в случае медленной загрузки для переключения на следующий лучший сайт.
Я заметил, что из-за того, что docker собирает много загрузок, поэтому я рассматриваю прокси-сервер squid, который должны использовать все машины. Но эта «случайная» стратегия yum / dnf меня беспокоит. Я понимаю намерение Fedora / centos распределять нагрузку на эти бесплатные репозитории, поэтому на самом деле я не хочу подрывать эту стратегию
Может ли Squid каким-то образом разумно определить, что клиент просто использует "другой URL-адрес репозитория Fedora / centos "и разумно кэшировать это? Сам по себе список металинков кажется довольно стабильным (он просто меняет порядок, когда его спрашивают, но сам список кажется таким же).
Намерение: не хранить 1000 копий одного и того же файла только потому, что он с другого сервера.
Как мне сделать это с помощью squid?
РЕДАКТИРОВАТЬ: Есть ли у кого-нибудь опыт использования этого http://wiki.squid-cache.org/Features/StoreID для кеширования dnf / yum?
Ответы на мой собственный вопрос. Выяснилось, что у squid есть поддержка для работы с подобной проблемой в скрипте storeid_file_rewrite. Единственная хитрость в том, чтобы получить корректный список urls, которые представляют собой одни и те же репозитории. Похоже, пока все работает нормально.
Добавлено в squid.conf следующее
store_id_program /usr/lib64/squid/storeid_file_rewrite /etc/squid/fedora.db
store_id_access allow localnet
store_id_access deny all
Чтобы получить содержимое для файла fedora.db (на данный момент это кэширование fedora 25), вам нужно сконвертировать "url" в результат "tmp.db" в формат, объясненный здесь http://wiki.squid-cache.org/Features/StoreID/DB. Это может быть автоматизировано (Любые добровольцы?)
Тогда вы получите нечто подобное "fedora.db", которое используется в squid.conf выше.
^http:\/\/ftp\.halifax\.rwth-aachen\.de\/fedora\/linux\/releases\/25\/Everything\/(x86_64\/[a-zA-Z0-9\-\_\.\/]+rpm)$ http://repo.mirrors.squid.internal/fedora/25/$1
^http:\/\/mirror2\.hs-esslingen\.de\/fedora\/linux\/releases\/25\/Everything\/(x86_64\/[a-zA-Z0-9\-\_\.\/]+rpm)$ http://repo.mirrors.squid.internal/fedora/25/$1
^http:\/\/fedora\.tu-chemnitz\.de\/pub\/linux\/fedora\/linux\/releases\/25\/Everything\/(x86_64\/[a-zA-Z0-9\-\_\.\/]+rpm)$ http://repo.mirrors.squid.internal/fedora/25/$1
... much more
EDIT: Альтернативный, более опасный путь, но, возможно, и достаточный, более глобальный паттерн, похожий на этот:
\/fedora\/linux\/releases\/([0-9]+)\/Everything/x86_64\/(.*)$ http://repo.mirrors.squid.internal/fedora/releases/$1/$2
\/fedora\/linux\/updates\/([0-9]+)\/x86_64\/(.*)$ http://repo.mirrors.squid.internal/fedora/updates/$1/$2
Sources:
Вы могли бы подумать об использовании baseurl вместо него, как это здесь и предлагалось: http://serverascode.com/2014/03/29/squid-cache-yum.html
Так что используйте:
baseurl=http://mirror.fedoraproject.org/fedora/$releasever/os/$basearch/
вместо:
metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
Что позволяет избежать проблем с металлинком, делая вещи немного менее динамичными.
Если бы вы собирались использовать baseurl, я подозреваю, что другим способом достижения того, что вы пытаетесь сделать, было бы использование apache или nginx (я бы выбрал nginx) в качестве обратного прокси к зеркалу repo.
Если бы вы не собирались использовать кальмары для других целей, я думаю, что на самом деле я бы предпочел установить nginx в качестве локального зеркала, чем использовать зеркала интернета в качестве бэкэнда/обходного потока.