Leitfaden für die ersten Schritte zur Serververwaltung mit Puppet
Einleitung
Puppet ist ein Open-Source-Dienstprogramm zur Konfigurationsverwaltung, das es dem Benutzer ermöglicht, mehrere Systeme und deren Konfiguration automatisch und bei Bedarf auch aus der Ferne zu verwalten. Puppet ist deklarativ, was bedeutet, dass der Benutzer nur einen Zustand des Diensts oder der Ressource anfordern muss, ohne wirklich darüber nachzudenken, wie dieser Zustand erreicht wird.
Mit anderen Worten: Stellen Sie sich vor, Sie sind ein Systemadministrator, der Hunderte von Systemen verwaltet und sicherstellen muss, dass eine bestimmte Ressource wie das hello-Paket installiert ist. Um dies auf traditionelle Weise der Systemadministration zu erreichen, muss sich der Admin-Benutzer mehreren Überprüfungen unterziehen, wie z.B. dem aktuellen Status der Paketinstallation, dem Typ der Betriebssystemplattform und dem Installationsbefehl, der vor der eigentlichen Paketinstallation verwendet werden soll. Da es sich bei puppet um ein Deklarativ handelt, muss der Benutzer nur den Status des gewünschten Pakets definieren und puppet kümmert sich um den Rest. Für den Fall, dass unser Paket "hello" installiert ist, wird die Marionette keine Aktion ausführen, während es installiert wird, wenn das Paket nicht installiert ist.
Szenario
In unserem Szenario werden wir nicht Hunderte von Betriebssystemen ausführen und versuchen, sie zu verwalten. Unser Ziel wird viel einfacher sein als das. Tatsächlich werden wir nur zwei separate Systeme betreiben, auf denen Puppet Master und Puppet Agent laufen. Daher werden wir über den Master-Puppet-Server versuchen, einen Remote-Knoten zu konfigurieren und das "hello"-Paket mit dem Puppet-Agenten zu installieren. Dies geschieht mit einem Minimum an Konfiguration.
Terminologie
- Puppet Master – Zentraler Server, der alle Agent-Konfigurationsmanifeste hostet und kompiliert
- Puppet-Agent – ein Dienst, der auf dem Knoten ausgeführt wird und regelmäßig den Konfigurationsstatus mit dem Master-Puppet-Server überprüft und ein aktuelles, aktuelles Konfigurationsmanifest abruft
- manifest – Konfigurationsdatei, die zwischen Puppet Muster und Puppet Agent ausgetauscht wird
- node – ein Betriebssystem, auf dem der Puppet-Dienst ausgeführt wird
Szenario-Einstellungen
In diesem Tutorial werde ich beide Hosts einfach als master und node1 bezeichnen. Das Betriebssystem, das sowohl auf der Master- als auch auf der node1-Instanz verwendet wird, ist Debian 8 Jessie. Ubuntu Linux kann auch als Alternative verwendet werden, um diesem Tutorial zu folgen. Die zugrunde liegende Netzwerkkonfiguration ist irrelevant. Es wird jedoch erwartet, dass node1 den Masterhost anhand seines Namens auflösen kann, beide Hosts verbunden sind und die richtigen Firewalleinstellungen angewendet werden, damit der Puppet-Master und der node1-Agent kommunizieren können:
root@node1:/# ping -c 1 master
PING master (172.17.0.1): 56 data bytes
64 bytes from 172.17.0.1: icmp_seq=0 ttl=64 time=0.083 ms
--- master ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.083/0.083/0.083/0.000 ms
Anmerkung: Lesen Sie den Anhang, um zu erfahren, wie Sie das obige Szenario mühelos mit Docker einrichten können.
Installation und Konfiguration von Pupper Master
Beginnen wir mit der Installation von Puppet Master:
root@master:~# apt-get install puppetmaster-passenger
Der obige Befehl installiert Puppet zusammen mit Apache und Passenger. Anstatt einen typischen WEBrick-Server zu verwenden, werden wir Apache Passenger einbeziehen, um den Puppet-Master auf Port 8140 auszuführen. Die standardmäßige und automatisch generierte Apache Passenger Konfigurationsdatei befindet sich unter /etc/apache2/sites-available/puppetmaster.conf:
This Apache 2 virtual host config shows how to use Puppet as a Rack
application via Passenger. See
http://docs.puppetlabs.com/guides/passenger.html for more information.
You can also use the included config.ru file to run Puppet with other Rack
servers instead of Passenger.
you probably want to tune these settings
PassengerHighPerformance on
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
PassengerMaxRequests 1000
PassengerStatThrottleRate 120
Listen 8140
SSLEngine on
SSLProtocol ALL -SSLv2 -SSLv3
SSLCipherSuite EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!IDEA:!ECDSA:kEDH:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
SSLHonorCipherOrder on
SSLCertificateFile /var/lib/puppet/ssl/certs/master.pem
SSLCertificateKeyFile /var/lib/puppet/ssl/private_keys/master.pem
SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem
# If Apache complains about invalid signatures on the CRL, you can try disabling
# CRL checking by commenting the next line, but this is not recommended.
SSLCARevocationFile /var/lib/puppet/ssl/ca/ca_crl.pem
# Apache 2.4 introduces the SSLCARevocationCheck directive and sets it to none
# which effectively disables CRL checking; if you are using Apache 2.4+ you must
# specify 'SSLCARevocationCheck chain' to actually use the CRL.
# SSLCARevocationCheck chain
SSLVerifyClient optional
SSLVerifyDepth 1
# The `ExportCertData` option is needed for agent certificate expiration warnings
SSLOptions +StdEnvVars +ExportCertData
# This header needs to be set if using a loadbalancer or proxy
RequestHeader unset X-Forwarded-For
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
DocumentRoot /usr/share/puppet/rack/puppetmasterd/public/
RackBaseURI /
Wenn wir uns die obige Konfigurationsdatei ansehen, können wir eine Reihe von SSL-Zertifikaten feststellen, die automatisch basierend auf dem Hostnamen des Systems generiert werden. Vergewissern Sie sich, dass alle aufgelisteten Zertifikatspfade auf ein korrektes Puppet-SSL-Zertifikat verweisen. Andernfalls müssen neue SSL-Zertifikate generiert werden. Wenn Sie zuerst neue Zertifikate generieren müssen, entfernen Sie die aktuellen Zertifikate:
root@master:~# rm -rf /var/lib/puppet/ssl
Führen Sie als Nächstes puppet im Vordergrund aus, um Ihre neuen Zertifikate zu sehen, die generiert werden sollen. Wenn Sie fertig sind, stoppen Sie den Vorgang mit der Tastenkombination STRG+C:
root@master:~# puppet master --verbose --no-daemonize
Info: Creating a new SSL key for ca
Info: Creating a new SSL certificate request for ca
Info: Certificate Request fingerprint (SHA256): FA:D8:2A:0F:B4:0B:91:8C:01:AD:71:B4:49:66:1F:B1:38:BE:A4:4E:AF:76:16:D2:97:50:C8:A3:8F:35:CC:F2
Notice: Signed certificate request for ca
Info: Creating a new certificate revocation list
Info: Creating a new SSL key for master
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for master
Info: Certificate Request fingerprint (SHA256): 43:67:42:68:64:73:83:F7:36:2B:2E:6F:06:20:65:87:AB:61:96:2A:EB:B2:91:A9:58:8E:3F:F0:26:63:C3:00
Notice: master has a waiting certificate request
Notice: Signed certificate request for master
Notice: Removing file Puppet::SSL::CertificateRequest master at '/var/lib/puppet/ssl/ca/requests/master.pem'
Notice: Removing file Puppet::SSL::CertificateRequest master at '/var/lib/puppet/ssl/certificate_requests/master.pem'
Notice: Starting Puppet master version 3.7.2
^CNotice: Caught INT; calling stop
Bevor wir unseren Puppet-Master starten, müssen wir zunächst ein leeres Standardkonfigurationsmanifest erstellen:
root@master:~# > /etc/puppet/manifests/site.pp
Alles ist bereit, um den Start des Puppet-Masters nach dem Neustart zu aktivieren:
root@master:~# systemctl enable apache2
Synchronizing state for apache2.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d apache2 defaults
Executing /usr/sbin/update-rc.d apache2 enable
und starten Sie Puppet Master, indem Sie den Apache Webserver starten:
root@master:~# service apache2 start
[ ok ] Starting web server: apache2.
root@master:~#
Vergewissern Sie sich, dass die Marionette ausgeführt wird
ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 20228 2016 ? Ss 11:53 0:00 /bin/bash
root 1455 0.0 0.0 98272 4600 ? Ss 12:40 0:00 /usr/sbin/apache2 -k start
root 1458 0.0 0.0 223228 1920 ? Ssl 12:40 0:00 PassengerWatchdog
root 1461 0.0 0.0 506784 4156 ? Sl 12:40 0:00 PassengerHelperAgent
nobody 1466 0.0 0.0 226648 4892 ? Sl 12:40 0:00 PassengerLoggingAgent
www-data 1476 0.0 0.0 385300 5116 ? Sl 12:40 0:00 /usr/sbin/apache2 -k start
www-data 1477 0.0 0.0 450880 5608 ? Sl 12:40 0:00 /usr/sbin/apache2 -k start
root 1601 0.0 0.0 17484 1140 ? R+ 12:44 0:00 ps aux
und Lauschen auf Port 8140:
netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp6 0 0 :::8140 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::443 :::* LISTEN
Konfiguration des Marionettenknotens
Im Moment läuft unser Master-Server und erwartet Anfragen vom Puppet-Agenten und daher ist es an der Zeit, unseren Puppet-Agenten auf node1 zu installieren:
apt-get install puppet
Als nächstes müssen wir puppet so konfigurieren, dass es als Agent fungiert, indem wir alle Standardanweisungen des Master-Servers aus der Konfigurationsdatei /etc/puppet/puppet.conf:
FROM entfernen:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
prerun_command=/etc/puppet/etckeeper-commit-pre
postrun_command=/etc/puppet/etckeeper-commit-post
[master]
These are needed when the puppetmaster is run by passenger
and can safely be removed if webrick is used.
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
AN:
[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
prerun_command=/etc/puppet/etckeeper-commit-pre
postrun_command=/etc/puppet/etckeeper-commit-post
[agent]
server = master
Die obige Direktive server=master definiert einen Master-Server, mit dem der Puppet-Agent verbunden werden soll. Dabei ist das Wort Master in unserem Fall ein Hostname, der in die IP-Adresse des Master-Servers aufgelöst wird:
ping -c 1 master
PING master (172.17.0.43): 56 data bytes
64 bytes from 172.17.0.43: icmp_seq=0 ttl=64 time=0.226 ms
--- master ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.226/0.226/0.226/0.000 ms
Der Installationsteil ist abgeschlossen und es bleibt nur noch, die Puppet nach dem Neustart zu starten und die Puppet zu starten:
systemctl enable puppet
Synchronizing state for puppet.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d puppet defaults
Executing /usr/sbin/update-rc.d puppet enable
root@node1:/# service puppet start
[ ok ] Starting puppet agent.
Darüber hinaus ist der Agent nach der Installation auf neuen, nicht konfigurierten Hosts standardmäßig deaktiviert. Um den Puppet-Agenten zu aktivieren, müssen wir Folgendes ausführen:
root@node1:/# puppet agent --enable
Zertifikat des Signatur-Agents
Sowohl der Host master als auch node1 sind betriebsbereit. Die letzte Konfiguration, die erforderlich ist, um sowohl Master als auch Agent zum Sprechen zu bringen, besteht darin, die Zertifikatsanforderung von node1 zu signieren. Nachdem wir den Puppet-Agenten auf node1 gestartet haben, wurde eine Zertifikatssignierungsanforderung an den Master-Server gesendet:
root@master:/# puppet cert list
"node1" (SHA256) 2C:62:B3:A4:1A:66:0A:14:17:93:86:E4:F8:1C:E3:4E:25:F8:7A:7C:FB:FC:6B:83:97:F1:C8:21:DD:52:E4:91
Standardmäßig muss jede Zertifikatsignierungsanforderung manuell signiert werden:
root@master:/# puppet cert sign node1
Notice: Signed certificate request for node1
Notice: Removing file Puppet::SSL::CertificateRequest node1 at '/var/lib/puppet/ssl/ca/requests/node1.pem'
Zu diesem Zeitpunkt sollte unser Master zwei signierte Zertifikate hosten:
root@master:/# puppet cert list --all
+ "master" (SHA256) EE:E0:0A:5C:05:17:FA:11:05:E8:D0:8C:29:FC:D2:1F:E0:2F:27:A8:66:70:D7:4B:A1:62:7E:BA:F4:7C:3D:E8
+ "node1" (SHA256) 99:DC:41:BA:26:FE:89:98:DC:D6:F0:34:64:7A:DF:E2:2F:0E:84:48:76:6D:75:81:BD:EF:01:44:CB:08:D9:2A
Auslösen einer Puppet-Konfigurationsanforderung
Es ist an der Zeit, ein erstes Konfigurationsmanifest zu erstellen. Wie oben bereits erwähnt, werden wir nun sicherstellen, dass das Paket hello auf node1 verfügbar ist. Öffnen Sie die Standardmanifestdatei /etc/puppet/manifests/site.pp auf den Master-Hosts, und fügen Sie die folgende vereinfachte Knotenkonfiguration hinzu:
package { "hello":
ensure => "installed"
}
Unser Agent auf node1 ist standardmäßig so eingestellt, dass die Master-Konfiguration alle 30 Minuten abgerufen wird. Wenn wir nicht warten möchten, können wir die Konfigurationsanfrage manuell auslösen:
root@node1:/# hello
bash: hello: command not found
Package hello ist derzeit auf node1 nicht verfügbar. Lösen Sie eine neue Konfigurationsanforderung manuell aus:
root@node1:/# puppet agent --test
Info: Caching certificate_revocation_list for ca
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for node1
Info: Applying configuration version '1434159185'
Notice: /Stage[main]/Main/Package[hello]/ensure: ensure changed 'purged' to 'present'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 4.00 seconds
Aus der obigen Ausgabe können wir sehen, dass die neue Konfiguration angewendet wurde und das Paket "hello" jetzt verfügbar ist:
root@node1:/# hello
Hello, world!
Schlussfolgerung
Der obige Text zeigt eine vereinfachte Puppet-Konfigurationsprozedur. Es sollte jedoch als Ausgangspunkt für Bereitstellungen mit mehreren Knoten dienen. Wenn Sie weitere Knoten hinzufügen möchten, besuchen Sie einfach die obigen Abschnitte Puppet-Knotenkonfiguration und Signatur-Agent-Zertifikat in diesem Artikel.
Fehlerbehebung
apache2: Der vollqualifizierte Domänenname des Servers konnte mit 172.17.0.43 nicht zuverlässig ermittelt werden. Legen Sie die Direktive 'ServerName' global fest, um diese Nachricht zu unterdrücken
echo "ServerName `hostname`" >> /etc/apache2/apache2.conf
Hinweis: Die Ausführung des Puppet-Konfigurationsclients wird übersprungen. administrativ deaktiviert (Grund: 'Standardmäßig deaktiviert bei neuen oder nicht konfigurierten alten Installationen');
Verwenden Sie 'puppet agent –enable', um die Aktivierung wiederherzustellen.
root@node1:/# puppet agent --enable
Anhang
Schnelle Szenarioeinstellungen mit Docker
linuxconfig/sandbox ist ein Docker-Image, das eine Basis, Textbearbeitungs- und Netzwerktools enthält, die Ihnen bei der Konfiguration und Fehlerbehebung Ihres Puppet-Masters und Agenten helfen.
Starten Sie zuerst den Puppet-Master:
docker run -it -h master --name=master linuxconfig/sandbox /bin/bash
Sobald der Puppet-Master betriebsbereit ist, starten Sie node1:
docker run -it -h node1 --name=node1 --link master:master linuxconfig/sandbox /bin/bash