AWS OpsWorks for Puppet Enterprise, Teil 3 Konfigurationsmanagement mit Puppet in der AWS-Cloud

Wurde der Puppet Enterprise-Server wie in Teil 1 unsers AWS OpsWorks-Workshops erfolgreich bereitgestellt, kann man erste verwaltete Knoten hinzufügen. Über die Puppet-Enterprise-Konsole lassen sich dann beispielsweise Knoten-Gruppen einrichten.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Confluent Germany GmbH

Server und Hosts, die von einem Puppet-Enterprise-Server verwaltet werden sollen, benötigen einen passenden Agenten. Erst dadurch werden sie zu einem Puppet-Enterprise-Server-Knoten. Das Elegante bei Puppet: jeder Puppet Enterprise-Master-Server stellt ein Repository bereit, mit dessen Hilfe die Puppet Agent-Software komfortabel auf allen Knoten installiert werden kann, die von Puppet verwaltet werden sollen. Dabei ist es unerheblich, ob der Knoten auf einer VM oder einem auf lokalen Computer im eigenen Rechenzentrum läuft.

Das in Teil 1 gezeigte Basis-Setup befüllt dieses Repository mit der Puppet-Agent-Software bereits mit Versionen für Ubuntu 14.04/16.04, RHEL 6 und alle von Puppet generell unterstützen 64-Bit-Windows-Versionen. Später kann man bei Bedarf weitere Puppet-Agenten gemäß der Liste der Puppet unterstützten Betriebssysteme hinzufügen.

Aktuelle Agent-Plattformen sind AIX 6.1/7.1/7.2, Amazon Linux 2, Debian 7/8/9, RHEL/CentOS/Oracle Linux 5/6/7, Fedora 26, SUSE Linux Enterprise Server 11/12, Ubuntu 14.04/16.04, MacOS 10.10/11/12/13, Solaris 10/11 und alle gängigen Windows-Versionen. Man muss dabei allerdings in Hinterkopf behalten, dass die Systemwartung Agenten löscht, die dem Server erst nach dem Start hinzugefügt wurden.

Aus diesem und anderen Gründen empfiehlt AWS, den „puppet-agent“ auf Knoten mit jenen Betriebssystemen, deren Agenten nicht auf AWS OpsWorks Puppet Enterprise-Server vorinstalliert sind, manuell auf den Knoten zu installieren. Detaillierte Informationen, wie man puppet-agent auf Server für Knoten mit anderen Betriebssystemen installiert, liefert die AWS-Dokumentation zu „OpsWorks Puppet Enterprise“.

Signaturanforderung

Wurden Knoten durch Installieren der Agenten-Software erfolgreich zum Puppet Master hinzugefügt beginnen diese automatisch, Zertifikat-Signieranforderungen (Certificate Signing Requests,CSRs) an den AWS OpsWorks for Puppet Enterprise-Server zu senden. Diese lassen sich auch in der Puppet-Konsole anzeigen. Details zum Prozess liefert die CSR-Dokumentation.

Durch Ausführen des OpsWorks-for-Puppet-Enterprise-API-Calls „associateNode()“ kann man dann Knoten-CSRs verbreiten und den Knoten seinem Server zuordnen. Mit folgendem Beispiel ordnen wir mit Hilfe eines solchen API-Calls einem einzelnen Knoten seinen Server zu. Die angegebene CSR, die der Knoten sendet muss im PEM-Format vorliegen.

Knoten zuordnen

Hat man „puppet-agent“ auf lokalen Computern oder virtuellen Maschinen installiert, gibt es in AWS OpsWorks for Puppet Enterprise-Master zwei Möglichkeiten, lokale Knoten zuzuordnen.

Manuell

Sind auf den betreffenden Knoten die AWS-SDKs, AWS CLI und/oder AWS-Tools für PowerShell installiert, ist die von AWS empfohlene Methode für das Zuordnen von Knoten das Verwenden eines associateNode()-API-Calls.

Das im ersten Teil beschriebene Starter Kit demonstriert unter anderem, wie man Rollen mittels Tags den Knoten zuweisen kann. Durch Festlegen von vertrauenswürdigen „Fakten“ in der Zertifikatssignierungsanforderung lassen sich Tags gleichzeitig mit dem Zuordnen von Knoten zum Puppet-Master anwenden. Das Demo-Control-Repository aus dem Starter-Kit ist zum Beispiel bereits für das Verwenden des Tags „pp_role“ zwecks Zuweisen von Rollen an Amazon EC2-Instances konfiguriert.

Autosign

Sind auf dem betreffenden Knoten die AWS-SDKs, AWS CLI und/oder AWS-Tools für PowerShell nicht installiert, lassen sie sich trotzdem auf die gleiche Weise bei einem AWS OpsWorks for Puppet Enterprise-Master registrieren, wie Knoten bei einem „echten“ Puppet Enterprise-Master, da ja wie oben gezeigt alle Knoten durch das das Installieren von puppet-agent eine Zertifikatsignierungsanforderung an den AWS OpsWorks for Puppet Enterprise-Master senden.

Jeder autorisierte Puppet-Nutzer kann dann die Zertifikatsignierungsanforderung wahlweise manuell signieren oder die automatische Signierung konfigurieren. Dazu muss er die auf dem Puppet-Master gespeicherte Datei „autosign.conf“ bearbeiten. Auch hierzu gibt es detaillierte Informationen in der https://puppet.com/docs/puppet/5.3/ssl_autosign.html Puppet-Dokumentation.

An der Puppet-Enterprise-Konsole anmelden

Hat sich der Benutzer wie in Teil 1 dieses Workshops gezeigt die Anmeldedaten von der Eigenschaftenseite des Puppet-Masters heruntergeladen, kann er sich – sobald der Server online ist – bei der Puppet Enterprise-Konsole anmelden. Der erste Schritt in der Konsole besteht dann darin, das Steuerungs-Repository anzugeben, das die Module enthält, und mindestens einen zu verwaltenden Knoten hinzuzufügen.

Erst dann werden Informationen über Agenten und Knoten in der Konsole angezeigt. Die Puppet-Enterprise-Konsole verwendet ein Zertifikat, das von der „integrierten“ Zertifizierungsstelle (Certificate Authority, CA) für Puppet Enterprise Server signiert ist. Da der eigene Browser dieses in der Regel als nicht vertrauenswürdig einstuft, muss der Nutzer in seinem Browser eine Sicherheitsausnahme hinzufügen.

Für das Anmelden an der Puppet Enterprise-Konsole entpackt man zunächst die im Teil 1 der Workshops heruntergeladenen Enterprise-Anmeldeinformationen. Dann klickt man in der AWS Management Console auf die Properties des Puppet-Servers und dann oben rechts auf „Open Puppet Enterprise console“.

Nun werden dem Nutzer detaillierte Informationen zu den verwalteten Knoten, Modul-Ausführungsfortschritten und Ereignissen, Compliance-Ebenen der Knoten und vieles mehr angezeigt. Weitere Informationen zu den Funktionen der Puppet Enterprise-Konsole und ihrer Verwendung findet man in der allgemeinen Puppet-Enterprise-Dokumentation. Diese sind dann Bestandteil der folgenden Teile unserer Puppet-Enterprise-Reihe.

(ID:45364969)