Назад | Перейти на главную страницу

squid и кеширование загрузок dnf / yum

Извините, если это вопрос новичка. Сначала я пытаюсь описать ситуацию, потом придет квест-кальмар.

Текущие установки Fedora / Centos имеют в своих обычных файлах конфигурации в /etc/yum.repos.conf металик, который выглядит следующим образом.

metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch

Этот металинк фактически заставляет yum / dnf выбрать «случайный» серверный сайт (выбранный сервером случайным образом географически по региону мира в соответствии с местоположением клиента металинк).
Это также используется в случае медленной загрузки для перехода на следующий лучший сайт.

Я заметил, что из-за того, что docker создает много загрузок, поэтому я рассматриваю прокси-сервер Squid, который должны использовать все машины. Но эта "случайная" стратегия yum / dnf меня беспокоит. Я понимаю намерение Fedora / centos распределять нагрузку на эти бесплатные репозитории, поэтому на самом деле я не хочу подрывать эту стратегию

Может ли Squid каким-то образом разумно определить, что клиент просто использует «другой URL-адрес репозитория Fedora / centos» и разумно кэшировать его? Список металинков сам по себе кажется довольно стабильным (он просто меняет порядок, когда его спрашивают, но сам список кажется таким же).

Намерение: не храните 1000 копий одного и того же файла только потому, что он с другого сервера.

Как мне сделать это с кальмаром?

EDIT: есть ли у кого-нибудь опыт использования этого http://wiki.squid-cache.org/Features/StoreID для кеширования dnf / yum?

Отвечая на свой вопрос. Выяснилось, что у squid есть поддержка для решения такого рода проблем с помощью скрипта storeid_file_rewrite. Единственная сложность - получить действительный список URL-адресов, которые представляют одни и те же репозитории. Кажется, пока все работает нормально.

В 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-адресов из зеркального списка.

basearch="x86_64"
releasever=25
mirrorlist="https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearc
curl -s "$mirrorlist" >tmp.db

Вам необходимо преобразовать "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

РЕДАКТИРОВАТЬ: Альтернатива, более опасный путь, но, возможно, также достаточный, более глобальное сопоставление с образцом, например:

\/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

Источники:

Вместо этого вы можете использовать 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) в качестве обратного прокси для зеркала репо.

Если вы не собирались использовать squid для других целей, я бы предпочел установить nginx в качестве локального зеркала, чем использовать интернет-зеркала в качестве бэкэнда / восходящего потока.