AWS OpsWorks for Chef Automate Chef-Server fürs Konfigurationsmanagement aufsetzen

Der verwaltete Config-Management-Service von AWS hört auf den Namen OpsWorks. Dieser Workshop beschreibt, wie man mit OpsWorks einen Chef-Server aufsetzt und dann einen existenten Host zum Chef-verwalteten Knoten macht, um auf diesem per Rezept eine Webanwendung zu bootstrappen.

Grundlagen zum Konfigurations-Management im Allgemeinen sowie auf Basis von AWS mit AWS OpsWorks Stack haben wir bereits ausführlich dargelegt. Ferner haben wir AWS for Puppet Enterprise in einer mehrteiligen Artikelserie vorgestellt.

Nun wollen uns dem Thema noch einmal auf Basis von Chef Automate nähern, der dritten „Work“-Engine für den verwalteten OpsWorks-Dienst, der Kunden einen vollständig von AWS verwalteten Chef-Automate-Server zur Verfügung stellt. Die Config-Management-Grundlagen und die grundlegende Arbeitsweise von Chef und Puppet haben wir aber bereits in den verlinkten Beiträgen gezeigt.

In diesem Beitrag konzentrieren wir uns deshalb darauf, ein konkretes Szenario nachzustellen. Hierbei möchten wir einen virtuellen Server (EC2) von Chef verwalten lassen und per Live-Bootstrapping mit der neusten Version einer webbasieren Anwendung versorgen sowie deren künftige Aktualisierungen vom Chefkoch vornehmen lassen.

Kosten für Chef Automate

Vorab ein paar Hinweise zu entstehenden Kosten, falls das Szenario im eigenen AWS-Konto nachgestellt werden soll. Zahlreiche AWS-Dienste – darunter auch AWS OpsWorks Stacks oder AWS Cloud Formation – zeichnen sich dadurch aus, dass man nichts für die Benutzung des Dienstes an sich zahlt, sondern nur für die durch den Dienst generierten verwalteten und/oder Infrastruktur-Ressourcen. Für AWS OpsWorks Puppet Enterprise und AWS OpsWorks Chef Automate gilt das nicht.

Hinter dem Dienst verbirgt sich nämlich das jeweilige kommerzielle Angebot von Puppet Labs bzw. dem Unternehmen Chef. Letzteres „lebt“ sowohl vom Support für die Open-Source-Versionen der jeweiligen Einzel-Tools wie Chef Workstation, Habitat, Inspec & Co hinter dem kommerziellen Produkt Chef Automate, als auch von Trainings für Chef Automate. Dies schlägt sich naturgemäß auch in der Preisgestaltung für AWS OpsWorks Chef Automate nieder, die AWS in so genannte „Knotenstunden“ einkleidet.

Bei AWS OpsWorks for Chef Automate berechnet AWS die Kosten auf Grundlage der Anzahl an Knoten, die mit dem Chef-Server verbunden sind, und ihrer jeweiligen Laufzeit. Zusätzlich zahlt man natürlich für die dem Chef-Server zugrunde liegende EC2-Instanz. Dafür profitiert der Nutzer bei Chef Automate in der AWS Cloud aber im jeden Fall vom Pay-as-you-Go-Preismodell, d. h. es gibt keine Vorabkosten oder Mindestgebühren. Man kann den Chef-Server jederzeit wieder „abgeben“.

evor wir loslegen werfen wir noch einmal einen Blich auf die grundlegende Chef-Architektur. Die vom Chef-Server verwalteten virtuellen oder physischen Server heißen „Knoten“ und werden in dem Moment zu einem Solchen, wenn der Chef-Agent installiert, bzw. das Tool „chef-client“ ausgeführt werde, etwa zum Abfragen des Chef-Repos vom Chef-Server.

Der Chef-Server verwaltet die Knoten in einem Client-Server-Modell. Die Chef-Workstation ist ein gewöhnlicher Linux-Host und dient als Steuerzentrale. Hier führt man die Chef-CLI und diverse Tools wie Knife aus, etwa zum Erstellen und Übertragen von Cookbooks auf das Chef-Repository.

Voraussetzungen für Chef Automate Server

Bevor ein Chef Automate Server bereitgestellt werden kann, müssen einige Voraussetzungen erfüllt sein. Diese unterscheiden sich geringfügig, je nachdem, ob die Bereitstellung über die Management Console über die GUI erfolgen soll: So braucht man für die Bereitstellung mindestens eine Service-Rolle, da OpsWorks letztendlich auf einer EC2-Instanz bereitgestellt wird, sowie eine Sicherheitsgruppe.

Die Service-Rolle ist in einem so genannten Instance-Profil gekapselt. Nur wenn die Service-Rolle in der GUI erzeugt wird, sind die Namen von Instanz-Profil und Service-Rolle identisch. In der Konsole erstellt AWS OpsWorks Service-Rolle und Sicherheitsgruppe automatisch, sofern der Nutzer keine vorhandenen Ressourcen angibt.

In der AWS CLI kann AWS OpsWorks zwar direkt eine Security-Group erstellen, nicht aber die Service-Rolle. Daher muss diese zuvor erstellt und dann im „create-server“-Kommando angegeben werden. Dafür erstellt OpsWorks in der GUI zwar den Chef Automate Server, der Nutzer muss sich aber das Chef Automate Starter Kit und die Anmeldeinformationen für das Chef-Automate-Dashboard manuell herunterladen.

Die Architektur von Chef Automate

Credentials extrahieren oder neu erstellen

Bei der CLI-Bereitstellung würde man hingen irgendeine Art von Shell-Tool in die Verarbeitung integrieren, dass einen JSON-Output weiterverarbeiten kann, um die Anmeldeinformationen und das Starter Kit aus der Ausgabe des Befehls „create-server….“ zu extrahieren, nachdem der neue AWS OpsWorks for Chef Automate-Server online ist. Alternativ kann der Nutzer an dieser Stelle aber auch komplett neue Anmeldeinformationen und ein neues Starter Kit in der Konsole generieren.

Konkret wird im Rahmen der Server-Erstellung automatisch ein pivotaler Chef-Schlüssel generiert, wenn kein vorhandener Key im Befehl create-server angeben ist. Man generiert den Schlüssel also entweder vorher und speichert ihn auf den lokalen Computer oder man muss den automatisch generierten Key aus der Ausgabe des Befehls create-server extrahieren.

Das zeigt sich auch am optionalen Parameter „–engine-attributes“, den das Kommando „aws opsworks-cm create-server …“ neben Instance-Profil, Service-Rolle und Security Group noch kennt. Legt der Nutzer nicht einen der beiden Parameter CHEF_PIVOTAL_KEY und/oder CHEF_DELIVERY_ADMIN_PASSWORD explizit fest, werden die Werte bei der Servererstellung generiert. Optional ist auch ein SSH-Schlüsselpaar für die Chef-Automate-Server-EC2-Instanz.

Zwar kann es mitunter nützlich sein, sich mit dem Chef Automate-Server direkt zu verbinden, z. B. wenn man das Administrator-Passwort des Chef-Automate-Dashboards zurücksetzen müsste, für den normalen Betrieb ist ein Solches aber nicht erforderlich, weil die auf der Chef-Workstation verwendeten Tools wie z. B. Knife nicht über SSH mit dem Chef-Server kommunizieren. Ferner richtet AWS OpsWorks bei der GUI-Bereitstellung automatische Backups und ein zugehöriges Wartungsfenster ein.

Beides lässt sich auch bei der CLI-Bereitstellung beeinflussen, worauf wir im folgenden Beispiel verzichten und damit die Defaults akzeptieren. Wir entscheiden uns im folgenden CLI-Bereitstellungs-Vorschlag dazu, CHEF_PIVOTAL_KEY, CHEF_DELIVERY_ADMIN_PASSWORD, Starterkit und Chef-Automate-Server-Endpoint direkt aus der Befehlsausgabe zu extrahieren. Allerdings erzwingen wir durch den Parameter „–output text“ eine Ausgabe im Text-Format und isolieren die jeweiligen Variableninhalte dann mit dem Unix-Kommando „cut“.

Der cut-Befehl extrahiert spaltenweise Ausschnitte aus Textzeilen. Als Eingabe-Parameter übergeben wir „EC2InstanceProfileArn“, „OpsWorksCmServiceIAMRoleArn“, „ChefServerSG“, die zu verwendeten Region (sofern nicht bei Verwendung der CLI als Default konfiguriert), die „Subnet-ID“ für den Chefserver (ChefServerSubnetId) und den Keypair-Namen des zuvor optional erstellten SSH-Keypairs. Als „EC2-Instance-Typ“ verwenden wir die minimal mögliche Größe „m4.large“.

Außerdem muss man die netzwerktechnischen Voraussetzungen schaffen und an die persönlichen Bedürfnisse anpassen. Wir verwenden in diesem Beispiel für die Chef Workstation eine gewöhnliche EC2-Instanz auf Basis von Amazon Linux in einem öffentlichen Subnet innerhalb der Ziel VPC und verbinden uns per SSH und Keypair mit dieser Maschine. Der Chef Automate Server soll in einem rein privaten Subnet positioniert und verwendet für seine eigene Internet-Verbindung ein NAT-Gateway, wahlweise als verwalteten AWS-Dienst oder als Instanz.

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.