AWS OpsWorks for Puppet Enterprise, Teil 2

Erstellen eines Puppet-Masters

| Autor / Redakteur: Thomas Drilling / Stephan Augsten

In diesem Tutorial spielen wir das Erstellen eines Master-Servers unter AWS OpsWorks for Puppet Enterprise durch.
In diesem Tutorial spielen wir das Erstellen eines Master-Servers unter AWS OpsWorks for Puppet Enterprise durch. (Bild: Drilling / AWS Germany GmbH)

Ein neuer Puppet Master lässt sich unter AWS OpsWorks for Puppet Enterprise wie bei Amazon Web Services üblich über die Management-Konsole oder per AWS CLI erstellen. Das Command Line Interface spricht eher erfahrene Nutzer an, der Weg über die AWS Management Console dürfte für Einsteiger der Einfachere sein.

Zum Erstellen eines Master-Servers genügt an der AWS-OpsWorks-Konsole ein Klick auf „Go to OpsWorks for Puppet Enterprise“ und dann auf „Create Puppet Enterprise server“. Auf der Seite „Set name, region, and type“ wählt der Nutzer dann einen Namen für seinen Server. Der Master-Name darf maximal 40 Zeichen lang sein, muss mit einem Buchstaben beginnen und kann nur alphanumerische Zeichen sowie Bindestriche enthalten.

Danach wählt man eine der unterstützten Regionen und entscheidet sich dann für einen Instance-Typ. Dessen Größe sollte so gewählt sein, dass er die Anzahl zu unterstützender Knoten bewältigen kann. Der Instanz-Typ lässt sich aber auch nach Erstellen des Servers noch ändern. Allerdings ist der kleinste angebotene Instanz-Typ „c4x.large“ zum Verwalten von bis zu 500 Knoten, was einem Stunden-Knoten-Preis von 0,015 US-Dollar entspricht.

Wer OpsWorks für Puppet Enterprise zunächst nur testen möchte, profitiert allerdings davon, dass auch dieser Service vom AWS-Free-Tier abgedeckt ist. Dieses Einsteiger-Angebot umfasst für die ersten 12 Monate nach Kontoeröffnung monatlich 7500 Knotenstunden und maximal 10 verbundene Knoten.

Puppet Credentials

Auf der Seite „Configure credentials“ kann der Benutzer – sofern er eine Verbindung via SSH wünscht – in der Dropdown-Liste bei „SSH key“ mit „Use an existing EC2 key pair“ ggf. einen seiner vorhandenen Key-Pairs auswählen. Schließlich gibt man im unteren Teil des Fensters bei „Configure Puppet Code Manager“ im Feld „r10k remote“ eine gültige SSH-URL zu einem vorhandenen Git Remote-Repository an.

Bei den Puppet-Zugangsdaten ist es möglich, einen eigenen SSH-Key mitzugeben.
Bei den Puppet-Zugangsdaten ist es möglich, einen eigenen SSH-Key mitzugeben. (Bild: Drilling / AWS Germany GmbH)

Hier ist das Verwenden eines optionalen privaten SSH-Keys im *.pem-Format im Feld „r10k private“ möglich, damit AWS OpsWorks auf das Remote-Repository „r10k“ zugreifen kann. Der Schlüssel wird von ggf. Git bereitgestellt, sobald man ein privates Repository erstellt. Optional kann der Nutzer aber selbstverständlich auch ein auf AWS CodeCommit gehostet Repository verwenden.

Der Konfigurationsassistent bietet zahlreiche erweiterte Sicherheitseinstellungen.
Der Konfigurationsassistent bietet zahlreiche erweiterte Sicherheitseinstellungen. (Bild: Drilling / AWS Germany GmbH)

Auf der nächsten Seite des Konfigurations-Assistenten „Configure advanced settings“ ergänzt der AWS-Admin dann die erforderlichen Netzwerk- und Sicherheitsinformationen. Diese umfassen die gewünschte VPC, das Subnetz, die zu verwendende Sicherheitsgruppen sowie eine Service-Rolle und das Instance-Profil. Die letzteren drei Angaben lassen sich übrigens auch On-the-Fly im Assistenten erzeugen. Außerdem darf der AWS-Nutzer entscheiden, ob der Puppet-Enterprise-Server eine öffentliche IP-Adresse erhalten soll.

Wartungsfenster

Weiter unten im Bereich „System maintenance“ kann der Admin einen spezifischen Tag und eine Uhrzeit für die Systemwartung festlegen, während der der Server offline ist. Das Angeben des Wartungsfensters ist zwingend, allerdings lassen sich die hier gemachten Angaben später mit Hilfe der AWS Management Console, über AWS CLI oder die entsprechenden APIs ändern.

Automatische Backups sind standardmäßig aktiviert.
Automatische Backups sind standardmäßig aktiviert. (Bild: Drilling / AWS Germany GmbH)

Noch weiter unten im Bereich „Automated backup“ konfiguriert der OpsWorks-Admin dann seine Sicherungen. Diese automatischen Backups sind standardmäßig aktiviert („yes“). Bei „Frequency“ kann der Admin die gewünschte Häufigkeit und bei „Start time (URC)“ die gewünschte Startstunde für die automatische Sicherung festlegen. Über „Number of generations to keep“ definiert man die Anzahl der Sicherungspunkte, die in Amazon S3 abgelegt werden.

Anmeldeinformationen

Vor dem Erstellen des Puppet-Masters gibt es noch einmal die Möglichkeit, die Einstellungen zu prüfen.
Vor dem Erstellen des Puppet-Masters gibt es noch einmal die Möglichkeit, die Einstellungen zu prüfen. (Bild: Drilling / AWS Germany GmbH)

Nach einem weiteren Klick auf „Next“ hat der Admin dann noch einmal die Möglichkeit, seine Eingaben auf der „Review“-Seite zu überprüfen und zu ändern. Mit dem Klick auf „Launch“ erstellt AWS OpsWorks nun den Puppet-Master, was eine gewisse Zeit n Anspruch nehmen kann.

Diese Zeit kann der Admin bereits sinnvoll nutzen und in der „AWS OpsWorks for Puppet Enterprise“-Konsole die Seite „Eigenschaften“ für den neuen Server öffnen. Beim ersten Verbinden mit einem neuen Puppet-Master fordert diese Seite den User auf, die „sign-in-credentials für „your Puppet Enterprise dashboard“ sowie das „Starter Kit für you Puppet Enterprise server“ mit Hilfe der jeweiligen Schaltflächen herunterzuladen.

Ist der Master-Server einmal online, verschwindet die Schaltfläche zum Herunterladen der Anmeldeinformationen.
Ist der Master-Server einmal online, verschwindet die Schaltfläche zum Herunterladen der Anmeldeinformationen. (Bild: Drilling / AWS Germany GmbH)

Das Herunterladen der Anmeldeinformationen muss geschehen, bevor der Puppet-Server online geht. Ist der Server einmal online, ist die Schaltfläche zum Herunterladen nicht mehr verfügbar, denn AWS OpsWorks speichert diese Informationen nicht ab. Die Anmeldeinformationen für den Puppet-Master werden zum Anmelden an der Puppet Enterprise-Konsole benötigt, an der der Admin später die weitaus meisten Verwaltungsaufgaben für den Knoten ausführt.

Falls gewünscht, kann der Nutzer das Passwort ändern, nachdem er sich mit diesen Anmeldeinformationen angemeldet hat. Ist der Server später online, ist die Puppet Enterprise-Konsole auf der Server-Domäne mit einer URL im Format https://your_server_name-randomID.region.opsworks-cm.io verfügbar.

Starter Kit

AWS OpsWorks erstellt bei jedem Herunterladen des Starter Kit neue Credentials und macht die alten Anmeldeinformationen ungültig.
AWS OpsWorks erstellt bei jedem Herunterladen des Starter Kit neue Credentials und macht die alten Anmeldeinformationen ungültig. (Bild: Drilling / AWS Germany GmbH)

Das Starter Kit enthält eine Readme-Datei mit Informationen und ein Beispiel. In der Readme-Datei ist unter anderem beschrieben, wie das Einrichten der Administrator-Anmeldeinformationen für die Puppet-Enterprise-Konsole fertiggestellt wird. AWS OpsWorks erstellt bei jedem Herunterladen des Starter Kit neue Credentials und macht die alten Anmeldeinformationen ungültig.

Das Starter Kit enthält außerdem ein Konfigurationsbeispiel. Hat man das Kit heruntergeladen und entpackt, kann man das Beispiel im Beispielordner „control-repo-example“ verwenden, um exemplarisch einen Nginx-Webserver auf einem verwalteten Knoten zu konfigurieren. Neben dem Ordner „control-repo-example“ enthält das Starter-Kit einen weiteren Ordner „control-repo“. Dieser repräsentiert den production-Zweig im Puppet-GitHub-Repository. Der Ordner control-repo-example-Ordner ist hingegen der production-Zweig mit Beispiel-Code für einen Nginx-Server inklusive einer Test-Website.

Um mit diesem zu experimentieren, verschiebt man den control-repo-example-production-Zweig in das eigene lokale Git-Remote-Repository. Das ist die „r10k_remote“-URL des Puppet-Masters. Das wiederrum kann selbstredend auch ein AWS-CodeCommit-Repository sein. Dazu wechselt man ins Wurzel-Verzeichnis des Starter Kits, führt das Kommando …

git remote add origin <r10kRemoteUrl>

… aus und gibt dabei die eigene „r10kRemoteURL“ an. Jetzt kann der Nutzer ein …

git push origin production

absetzen. Der Puppet-Code-Manager verwendet Git-Zweige als „Umgebungen“, wobei sich per Default sämtliche Knoten in der production-Umgebung befinden. Demnach ist es wichtig, nicht den „master“-Zweig zu verwenden, denn dieser ist exklusiv für den Puppet-Master reserviert. Ist das erledigt, kann der Nutzer seinen Code im „control-repo-example“-Zweig seinem Puppet Master bereitstellen. Dieser kann dann den Puppet-Code des Nutzers von dessen Git-Repository (<r10k_remote>) herunterladen. Danach für man im Starter-Kit-Wurzel-Verzeichnis das Kommando

puppet-code deploy --all --wait --config-file .config/puppet-code.conf

aus. Details dazu und wie man Puppet-Code schreibt, zeigt der nächste Teil unseres Workshops.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45299849 / Configuration-Management)