Meer koffie dankzij Puppet
- Door: Miek Gieben
- 03 mei 2012 - 15:45 uur
Of; hoe SIDN Puppet inzet voor beheer.
Puppet is een ‘configuratie management systeem’. Met zo'n systeem automatiseer je de inrichting van je Unix-(Linux/FreeBSD/Solaris/...) omgeving. Een ander, soortgelijke toepassing is bijvoorbeeld CFengine.[meer...]
Met een configuratie management systeem kun je tal van repeterende routinewerkzaamheden automatiseren. Bijvoorbeeld: ‘Plaats dit configuratie-bestand in die directory en herstart daarna BIND’.
Bij SIDN hadden we hier behoefte aan. We wilden:
- Een consistente/automatische installatie van alle machines;
- Historie van veranderingen beter bijhouden;
- Alle software als packages (deb, rpm, etc.) installeren;
- De grootte van de back-up minimaliseren.
Met de introductie van Puppet is de situatie nu zo dat we een ‘kale’ machine in DNS/DHCP opvoeren en dan aanzetten. De rest gaat daarna ‘vanzelf’. Tijd voor een kop koffie dus. Tegen de tijd dat die op is, staat er een volledig geïnstalleerd en geconfigureerd systeem tot je beschikking.
Er zijn vier pijlers waarop dit rust:
- Een ‘build’-infrastructuur om packages mee te maken;
- Een ‘repository server’ waar de eigen (supplementaire) packages op worden neergezet, zodat ze eenvoudig uitgerold kunnen worden;
- PXE-boot omgeving, die werkt voor alle ondersteunde OS-en, op dit moment is dat bij ons: RedHat/CentOS en Ubuntu;
- Puppet-configuratie.
Build-infrastructuur
Om zelf packages te kunnen maken, hebben we een (virtuele) server ingericht (builder1). Deze beschikt over alle ‘sources’ van de packages die we nodig hebben. Denk bijvoorbeeld aan de source-code tar-files van BIND. Verder bevat hij de specifieke configuratie om .deb of .rpm packages te maken, zoals ‘rules’ en ‘spec’-files. Deze configuratie wordt (uiteraard) ook weer via Puppet beheerd.
Verder zijn er nog enkele ‘satellietmachines’ die de specifieke OS-en draaien waar we de packages voor willen bouwen. De hiervoor benodigde bestanden komen, via NFS-mounts, van de builder1.
Om op zo'n satellietmachine een package te bouwen is het geven van één commando voldoende:
makebind # bouwt de nieuwste BIND9
makensd # bouwt de nieuwste NSD
Hierna wordt het gemaakte package naar onze ‘repository server’ gekopieerd.
Repository server
Onze software-repositories worden om de zoveel tijd gesynchroniseerd met de officiële repositories van Redhat en Ubuntu. Op deze manier is SIDN in control over wat er precies op het netwerk draait. De packages die we zelf gemaakt voegen we vervolgens toe aan onze eigen repository server.
De rest van de systemen kan daarna op de gangbare manier geüpdatet worden: apt-get upgrade, yum update, etc.
PXE-boot omgeving
De derde pijler is onze PXE-boot omgeving. Deze omgeving heeft slechts één taak: zorg dat er op een willekeurige machine een OS komt te staan en een paar basis packages. Dat kan zowel een fysieke server zijn, als een virtueel systeem.
(Virtuele) harde schijven worden tijdens dit proces volautomatisch gepartitioneerd (met behulp van 'LVM'). Daarbij kan er voor worden gekozen om het filesysteem volledig te versleutelen, wat we in een aantal gevallen ook daadwerkelijk doen.
Het laatste pakket dat geïnstalleerd wordt is Puppet. Die neemt daarna de installatie over en zorgt ervoor dat de machine helemaal af-geconfigureerd wordt.
Puppet
Als vierde en laatste pijler is er een Puppet ‘master–machine’, die de configuraties bewaart in Subversion. We hebben bewust hiervoor gekozen en niet voor bijvoorbeeld Git, omdat Subversion zaken als $Id$ en $URL$ ondersteund. Zo kan je als beheerder op een machine altijd zien dat een bestand uit Subversion (en dus Puppet) komt en dat je die dus op de Puppet master machine moet veranderen en niet lokaal.
De Puppet configuratie is simpel gehouden, veel van de resource types die we gebruiken zijn:
De gedachte hierachter is, dat we niet de ambitie hebben om Puppet experts te willen worden, maar gewoon ‘gebruikers’ zijn. En met deze relatief simpele Puppet configuratie kun je al heel veel.
In Puppet definieer je ‘manifests’, die aangeven hoe een stukje software met eventuele configuratiebestanden op een machine moet worden neergezet. Een voorbeeld van een (onvolledig) Puppet manifest is deze:
# Class: generic::ntp
# Control the ntp configuration (/etc/ntp.conf).
# Package 'ntp' is also installed.
class generic::ntp {
file { "/etc/ntp.conf":
source => [ "puppet://puppet/modules/generic/etc/ntp.conf=$hostname",
"puppet://puppet/modules/generic/etc/ntp.conf" ],
require => Package["ntp"],
}
}
Dit kleine stukje Puppet laat zien hoe we een ntp.conf neerzetten. Veel moeilijker dan dit zijn onze Puppet manifests niet.
Wat staat hier precies?
Allereerst wordt er een klasse ‘generic::ntp’ gedefinieerd. Als deze klasse wordt aangeroepen, dan zal die ervoor zorgen dat het ntp-package wordt geïnstalleerd (vanwege de ‘require’ regel). En is er voor de betreffende machine een specifieke ntp.conf (ntp.conf=$hostname), gebruik die dan. Anders vallen we terug op de generieke versie.
Voordelen
De voordelen voor SIDN zijn legio:
- Het installeren van een machine kost eigenlijk nauwelijks tijd meer. Je kunt tijdens de installatie koffie gaan halen, opdrinken, terug lopen en dan inloggen op je nieuwe server;
- Alle systeem-specifieke data is opgeslagen in Subversion;
- Software-uitrol verloopt netjes via packages;
- Het documenteren kost minder tijd, want Puppet is bijna zelf-documenterend. Alleen one-off zaken moeten nu nog apart gedocumenteerd worden.
Inmiddels is het woord ‘Puppetized’ een veel gebruikte term geworden binnen SIDN.
Bijgaand een afbeelding van een /etc/motd van een machine die door middel van Puppet is uitgerold. Rechtsboven is te zien dat deze ‘puppetized’ is.
