A Story about Mirrors and Caches

LinuxContainer sind für mich Wegwerfartikel. Benutze sie als Sandboxes um neue Software auszuprobieren, bestimmte Software zu Betreiben und um der Dependency-Hölle zu entkommen. Auch dieser Blogpost wurde in so einer LXC-VM gebaut.

Mirroring

Natürlich fällt bei (im Schnitt) 20-25 VMs zusätzlicher Verwaltungsaufwand an, was ich bisher sehr gut mit Puppet erschlagen konnte. Ein anderes Problem sind aber die OS Updates der Maschinen. Dazu nutze ich alle Monat clusterssh. Klar, wenn alle Maschinen gleichzeitig Updates ziehen macht das weder meiner Internetanbindung noch dem Mirror-Betreiber Spaß.

Ich rechnete etwas hin und her, ob es sich wirklich lohnt einen eigenen lokalen Mirror zu betreiben. Für die richtige Architektur von main/non-free/contrib braucht wohl ~150GB. Letztendlich rentiert sich das von der Masse und Update-Synchronisierung erst hart spät. Ich tat es aber dann doch, was mit dem apt-mirror einfach und schnell ging.

Caching

Es gibt Caching Software für Debian Repos! Nach einem Schwatz mit einem Kollegen kam die Erkenntnis das alles zu syncen garnicht nötig war. Auf diese Idee war ich nicht gekommen. Nichtmal an die Möglichkeit gedacht. Konkret möchte man apt-cacher-ng nutzen.

apt-cacher-ng agiert jetzt quasi als Proxy zwischen den Containern und dem konfigurierten Debian Mirror.

sudo aptitude install apt-cacher-ng
sudo /etc/init.d/apt-cacher-ng start

Möchte ein Client Updates herunterladen, bemüht sich apt-cacher-ng nach Möglichkeit bereits heruntergeladene Pakete aus /var/cache/apt-cacher-ng/$mirror/debian auszuliefern. Das spart Bandbreite und Speicherplatz. Clientseitig lässt sich die Nutzung des Proxys auf zweierlei Varianten konfigurieren.

Entweder durch das apt HTTP Proxy Feature

Acquire::http { Proxy "http://10.10.0.10:3142"; };

oder durch sources.list URLs

deb http://10.10.0.10:3142/debian.cs.fau.de/debian stable main contrib non-free

Mir gefiel die erste Variante allerdings wesentlich besser. Ich kann es nicht begründen, fühlt sich aber besser an.

Puppet

Ausrollen konnte ich die Konfiguration gegen apt-cacher-ng einfach über das Puppetlabs apt Modul.

class { 'apt':
  always_apt_update    => false,
  proxy_host           => '10.10.0.10',
  proxy_port           => '3142',
}

apt::source { 'wheezy-mirror':
  location    => 'http://debian.cs.fau.de/debian/',
  release     => 'wheezy',
  include_src => false,
  repos       => 'main contrib non-free',
}

Außerdem war dies der erste Post den ich mit der Cherry G80-3000LSCDE-2 verfasste. Es ist schöner als vorher.

Comments (7)

killermoehre on 2013-08-31T18:33:40

Zur besseren Lastverteilung könntest du noch cdn.debian.net als Paketquelle eintragen, das Content Delivering Network von Debian.

Martin on 2013-08-31T19:14:36

pip install https://github.com/rodjek/puppet-pygments-lexer/archive/master.zip pbpaste | pygmentize -l puppet -f terminal -g /dev/stdin SCNR ;)

noqqe on 2013-09-01T11:24:05

Du bist so gut zu mir ;D

noqqe on 2013-09-01T11:24:54

Ich war der Meinung der routed einen nur Location-Based zum nächstmöglichen Mirror. Nicht Last-Bezogen.

Michael on 2013-09-03T07:18:42

apt-cacher-ng (siehe auch Wiki bei ubuntuusers.de) setze ich hier ebenfalls ein, damit sich meine 4-5 Ubuntu-Computer im Haushalt möglichst viele Updates teilen. Funktioniert alles gut, einzig für die mobilen Geräte müsste ich mal ein kleines Skript schreiben, damit sie sich direkt mit den Servern verbinden, wenn sie ausser Hause sind...

senden9 on 2013-09-07T17:41:52

"apt-cacher-ng" kannte ich schon. Das Thema Puppet/Massenkonfiguration welches du kurz angerissen hast finde ich allerdings interessant.

MKzero on 2014-01-09T23:31:53.206764

Man kann, wenn man eh schon einen Proxy braucht(weil man z.B. keine direktes Routing ins Internet hat) auch einfach einen Squid o.ä. betreiben. Der kann entsprechend Cachen und die Clients brauchen auch nur die Proxy-Config für Apt.