So machen Sie Ihre IT-Infrastruktur langweilig

Michael DeHaan ist der Mann, der Ansible erschaffen hat. Viele der Dinge, die Systemadministratoren, Release- und DevOps-Ingenieure regelmäßig tun, sind, gelinde gesagt, uninteressant. DeHaan möchte, dass diese Personen ihre Zeit für interessantere Dinge (bei der Arbeit oder vor der Bürotür) freigeben und einen Produktcode schreiben, der Administratorzeit spart.
Mehr Zeit, weniger Adrenalin während der Geschäftszeiten, weniger Skripte und weniger Fehler.
Übrigens können Sie diesen Absatz zu Ende lesen, indem Sie sich stattdessen am 6. Juni hier mit Livestream verbinden.



Wenn Sie noch weiter gelesen haben ...

Ansible: Kontinuierliche Integration und Lieferung

Ansible ist eine leistungsstarke Open Source-Automatisierungssprache. Ja, es eignet sich nicht nur hervorragend für das Management, sondern auch für die Bereitstellung und Orchestrierung von IT-Systemen. Ansible wurde ursprünglich entwickelt, um eine Vielzahl von Automatisierungsaufgaben effektiv zu lösen und als einfache universelle Grundlage für den Ersatz herkömmlicher Steuerungen. Letztendlich erwies es sich jedoch in vielen Bereichen als sehr nützlich. Zum Beispiel bei gleichzeitiger Sicherstellung von Ausfallzeiten während der kontinuierlichen Integration und Anwendungsbereitstellung (CI / CD). Normalerweise wird dieses Problem durch die umfassende Verfeinerung der Software, die Verwendung verschiedener Softwarepakete und viele Tricks gelöst, die für jede spezifische Konfiguration einzigartig sind. Ansible wurde ursprünglich speziell für solche Orchestrierungsszenarien entwickelt und bietet eine schlüsselfertige Lösung "alles in einem".

Kontinuierliche Integration und Anwendungsbereitstellung (CI / CD)

Einige gemeinsame Wahrheiten. Die Praxis der Entwicklung von Softwaresystemen in den letzten 10 Jahren zeigt, dass der lange Lebenszyklus von Softwareversionen (kaskadierendes Entwicklungsmodell) im Vergleich zu einem kurzen Zyklus (der sogenannten "iterativen" oder agilen Entwicklung) einen viel höheren Overhead aufweist. Es geht nur um Arrhythmie: Wenn Programmierer gerade erst anfangen, an einer neuen Version zu arbeiten, haben die IT-Mitarbeiter, die für das Testen und die Bereitstellung verantwortlich sind, einfach nichts zu tun. Aber je näher die Version an der Version liegt, desto mehr IT-Experten sind beschäftigt und desto häufiger müssen Programmierer den Kontext wechseln, abwechselnd an Fehlern arbeiten und die nächste Version planen.

Darüber hinaus verlängert ein langer Zyklus das Intervall zwischen der Identifizierung und Beseitigung von Softwarefehlern und -mängeln, was insbesondere für große Websysteme mit einem Benutzerpublikum von mehreren Millionen Dollar von entscheidender Bedeutung ist. Daher setzt die Softwareindustrie unter dem Motto „schneller und häufiger veröffentlichen“ schnell agile Methoden ein, damit die Teilnehmer am Entwicklungsprozess ihren Arbeitskontext seltener wechseln und Verbesserungen und Innovationen viel schneller erstellen, debuggen und implementieren können.

Die Automatisierung der Qualitätskontrolle, die TDD-Entwicklung durch Tests und andere verwandte Techniken erhöhen die Effektivität neuer Arbeitsmethoden weiter. Wo ist die Automatisierung? Wo sind die Technologien, die die Zahnräder schneller drehen lassen und die Beteiligung des Menschen auf das unbedingt notwendige Minimum reduzieren?

Und hier zum Beispiel Ansible und Ansible Tower von Red Hat zur Orchestrierung von IT-Systemen als Teil moderner Softwareentwicklungsprozesse.

Keine Ausfallzeiten

Ein bisschen offensichtlicher. Ausfallzeiten bedeuten entgangenen Gewinn und unzufriedene Kunden. Daher ist in Web-Warteschlangensystemen, deren Benutzer über alle Zeitzonen verteilt sind, das geplante Herunterfahren nur in wirklich schwerwiegenden Fällen zulässig, deren Liste das Aktualisieren von Anwendungsversionen nicht explizit enthält. Ähnlich verhält es sich in Unternehmensumgebungen, in denen die Unzugänglichkeit eines Intranets oder Buchhaltungssystems die Produktivität der Mitarbeiter erheblich verringert. Daher sollte jede Prozessautomatisierung Aktualisierungen bereitstellen, ohne den Betrieb zu unterbrechen - mit anderen Worten, ohne Ausfallzeiten.

Es ist durchaus möglich, keine Ausfallzeiten zu erzielen, aber dafür benötigen wir geeignete Tools, um beispielsweise eine erweiterte, mehrstufige und mehrstufige Orchestrierung bereitzustellen, wie beispielsweise das Ansible-System.

Anwendungserstellungssysteme

Continuous Delivery (CD) beginnt mit Continuous Integration (CI). Ein System, das Quellcode-Repositorys auf Änderungen überwacht, die entsprechenden Tests unabhängig ausführt und mit jeder Code-Aktualisierung automatisch eine neue Version der Anwendung erstellt (und im Idealfall testet), z. B. das Jenkins-Projekt (jenkins.io).

Um den Staffelstab nach erfolgreichem Zusammenstellen der neuen Version der Anwendung an das CD-System weiterzuleiten, kann das CI-System-Build-Subsystem Ansible aufrufen, um diese neue Version sofort denjenigen bereitzustellen, die Unit- oder Integrationstests durchführen. Insbesondere kann Jenkins Tower verwenden, um Baugruppen in verschiedenen Umgebungen bereitzustellen, und die Test- oder Zwischenumgebung kann auf der Grundlage der Produktionsumgebung modelliert werden, wodurch die Vorhersagbarkeit während des gesamten Software-Lebenszyklus erheblich verbessert wird. Die von Ansible aus den Ergebnissen der Ausführung von Automatisierungsskripten zurückgegebenen Daten können direkt in die Build Systems-Jobs des Tower-Systems einbezogen werden. Mit Tower können Sie sogar Bereitstellungsszenarien in einer Zwischenumgebung testen, bevor Sie sie auf "Kampf" -Servern ausführen.

Mehrstufiges Anwendungsupdate nacheinander

Das CD-System muss in der Lage sein, die fortlaufenden Aktualisierungsprozesse von mehrstufigen Anwendungen zu koordinieren. Dank der Push-Architektur und der Funktionen der mehrstufigen mehrstufigen Orchestrierung kann Ansible diese Aufgabe bewältigen, indem alle Anwendungsebenen nach Ebenen aktualisiert werden und Daten zwischen ihnen ausgetauscht werden.

Um einzelne Updates zu implementieren, verwendet Ansible Play-Skripte, mit denen Sie die Gruppe der Zielhosts genau angeben und Aufgaben (Rollen) zuweisen können, die für sie ausgeführt werden müssen. Aufgaben sind normalerweise Ankündigungen, dass sich eine bestimmte IT-Ressource in einem bestimmten Zustand befinden muss. Beispielsweise muss für eine Version einer Software ein bestimmtes Paket installiert werden, und für eine andere muss das Code-Repository überprüft werden. Webanwendungstopologien müssen in der Regel in strikter Reihenfolge aktualisiert werden, und Sie können Anwendungen und Systemkonfigurationen nicht auf allen Computern gleichzeitig aktualisieren.

Wenn der Dienst neu gestartet wird, bleibt er einige Zeit nicht verfügbar, und das Ersetzen der Anwendungsversion erfolgt ebenfalls nicht sofort. Daher ziehen wir das System vor der Aktualisierung aus dem Ausgleichspool. Daher müssen Sie in der Lage sein, das Verbinden und Trennen von Maschinen vom Pool zu automatisieren. Konsequent ist das Schlüsselwort. Ansible kann die Größe des Fensters eines aufeinanderfolgenden Updates sehr genau steuern. Nun, die Entwicklung solcher Updates wird sehr sorgfältig durchgeführt, und wenn irgendwann ein Fehler auftritt, wird das Update ausgesetzt, um den Rest der IT-Infrastruktur nicht zu deaktivieren.

Kontinuierliche Bereitstellung für Automatisierungsskripte

Zusätzlich zur CD-Funktionalität für Dienste, die im kommerziellen Betriebsmodus betrieben werden, können Sie auch die kontinuierliche Bereitstellung von Automatisierungsskripten selbst organisieren (Ansible Playbook-Befehlssätze. Hören Sie nicht auf zu lesen, im zweiten Teil finden Sie Beispiele für Playbooks). Auf diese Weise können Systemadministratoren und Entwickler Skripts mithilfe des Quellcode-Repositorys verwalten, diese Skripts in einer Zwischenumgebung testen und sie bei einem erfolgreichen Einbruch automatisch in die Produktionsumgebung übertragen. Mit anderen Worten, wenn Sie mit Skripten arbeiten, erhalten Sie alle methodischen und anderen Vorteile des zentralen Code-Repositorys, die Sie bei der Entwicklung von Software gewohnt sind.

Änderungen an Software- und Systemkonfigurationen sind einer der Hauptgründe für ungeplante Ausfälle. Daher gibt es zusätzlich zu automatisierten Tests eine menschliche Kontrolle. Es kann durch Integration in ein Code-Inspektionssystem wie Gerrit organisiert werden und die Änderungen erst anwenden, nachdem sie von den zuständigen Genossen genehmigt wurden.

Alternative Updates und Lastausgleichssysteme

Ansible arbeitet sehr unabhängig mit Lastausgleichssystemen, wenn aufeinanderfolgende Updates durchgeführt werden. Daher können Sie einfach in ein Playbook-Skript in einem beliebigen Zyklus für eine Gruppe von Hosts schreiben, z. B. "Führen Sie diese Aktion auf System X im Auftrag von Host Y aus", und Ansible kümmert sich um den Rest.

Ansible interagiert gut mit Load Balancern aller Art und kann ein Flag zum vorübergehenden Trennen eines Hosts setzen, um die Verfügbarkeitsüberwachung für diesen Host während des Aktualisierungszeitraums zu deaktivieren. Das einfache Schema "Überwachung ausschalten - Aus dem Pool entfernen - Gewünschte Softwareversion aktualisieren - Zurück zum Pool - Überwachung einschalten" implementiert problemlos eine sequentielle Aktualisierung ohne Ausfallzeiten und ohne Fehlalarme. Und das alles in einem vollautomatischen Modus ohne Bedienereingriff.

Integrierte Zwischenprüfung

Tower kann mit verschiedenen Ressourceninventardateien (Inventar) arbeiten, wodurch es einfach ist, aufeinanderfolgende Aktualisierungsszenarien in einer Zwischenumgebung zu testen, bevor sie auf "Kampf" -Servern ausgeführt werden. Dazu reicht es aus, die Produktionsumgebung in der Testumgebung zu simulieren, Ansible mit dem Parameter "-i" auszuführen und anzugeben, welche Inventardatei beim Ausführen des Skripts verwendet werden soll - für die Testumgebung oder für die Produktionsumgebung. Das Skript selbst muss nicht geändert werden.

Bereitstellung der Versionskontrolle

Einige Leute mögen es, Anwendungen zusammen mit Betriebssystempaketen (RPM, Debs usw.) heißer zu packen, aber oft, insbesondere für Webanwendungen, ist ein solches Packen nicht erforderlich. Daher enthält Ansible mehrere Module zum Bereitstellen von Anwendungen direkt aus Versionskontrollsystemen. Im Playbook-Skript können Sie eine Abstimmung mit dem Code-Repository für das angegebene Tag oder die angegebene Versionsnummer schreiben. Danach überprüft Ansible diese Bedingung auf allen Zielservern und aktiviert die nächsten Schritte nur, wenn die Version ersetzt werden muss, wodurch unnötige Neustarts des Dienstes vermieden werden.

Integration mit Überwachungstools

Als vollwertiges Orchestrierungssystem unterstützt Ansible die Integration in APM-basierte Anwendungsleistungsmanagementsysteme auf Überwachungsebene. Während der Bereitstellungs- oder Integrationstestphase müssen Sie beispielsweise den APM-Software-Agenten mit der Anwendung installieren oder aktualisieren. Ansible spielt hierfür eine besondere Rolle. Nach der Installation und Aktivierung des Agenten kann Ansible ihn im APM-Überwachungsstapel konfigurieren (sofern er noch nicht konfiguriert ist), sodass Anwendungsmanager sofort überprüfen können, ob die neue Version installiert wurde und problemlos funktioniert .

Wenn nach dem Aktualisieren der Anwendung in der Produktionsumgebung ein Fehler aufgetreten ist, rufen die Überwachungstools möglicherweise Ansible auf, um ein Rollback auf die vorherige Version durchzuführen. Natürlich nur, wenn ein solches Rollback erlaubt ist.

Ereignisbenachrichtigung

Im CI / CD-Paradigma möchte jeder so schnell wie möglich Ereignisbenachrichtigungen erhalten. Ansible bietet sowohl integrierte Funktionen, einschließlich eines E-Mail-Moduls, als auch die Integration in externe Benachrichtigungstools wie Instant Messenger, soziale Netzwerke oder Ereignisregistrierungssysteme.

Bereitstellung mithilfe eines Ressourcenstatusmodells

Eine der Hauptfunktionen von Ansible, die es zu einem sehr nützlichen Tool für die Bereitstellung von Anwendungen macht, ist die regelmäßige Verwendung des Ressourcenstatusmodells in Softwareupdateprozessen, die bei der Verwaltung von Systemkonfigurationen an Beliebtheit gewonnen hat. Im Gegensatz zu herkömmlichen Open Source-Steuerelementen muss Ansible nicht mit zusätzlicher Software oder speziellen Skripten ausgestattet sein, um die Anwendungsbereitstellung zu organisieren.

In Ansible können Sie die Reihenfolge von Ereignissen auf verschiedenen Architekturebenen sehr genau registrieren und steuern. Auf diese Weise können Sie Aktionen an andere Systeme delegieren sowie Anweisungen des Ressourcenmodells (z. B. "Paket X muss sich im Status Y befinden") und herkömmliche Skriptbefehle (z. B. "Skript ausführen") kombinieren .sh ") innerhalb eines Prozesses.

Ansible macht es auch einfach, Überprüfungen verschiedener Bedingungen durchzuführen und Entscheidungen basierend auf deren Ergebnissen zu treffen. Die Kombination der Prozesse der Systemkonfiguration und der Anwendungsbereitstellung in einer einzigen Toolkette ist wesentlich effizienter als ein Schema mit mehreren spezialisierten Tools und erhöht außerdem die Konsistenz der Betriebssystemrichtlinien und -anwendungen.

Bereitstellungstests

Je mehr Möglichkeiten, desto höher die Verantwortung. Die Automatisierung kontinuierlicher Bereitstellungsprozesse erhöht das Risiko der Bereitstellung einer fehlgeschlagenen Konfiguration auf allen Knoten des Systems erheblich. Um die Risiken zu verringern, schlägt Ansible vor, Kontrolltests in das Skript einzufügen, die die sequentielle Aktualisierung unterbrechen, wenn etwas schief geht. Um verschiedene Bedingungen zu testen, einschließlich des Status der Funktionsweise von Diensten, können Sie beliebige Tests mithilfe der Befehls- oder Skriptmodule bereitstellen und solche Tests sogar als separate Ansible-Module erstellen.

Das Fail-Modul kann die Ausführung des Skripts auf dem Host jederzeit unterbrechen, sodass Sie Fehler in einem frühen Stadium der sequentiellen Aktualisierung erkennen können. Aufgrund des Unterschieds zwischen der Zwischenumgebung und der Produktionsumgebung generiert letztere beispielsweise einen Konfigurationsfehler, der die "Kampf" -Server deaktiviert. In diesem Fall kann in der ersten Phase des sequentiellen Updates ein Notausgang im Playbooks-Skript registriert werden. Wenn Sie über 100 Server verfügen und das Fenster für aufeinanderfolgende Updates 10 ist, haben Sie bei einem solchen Notstopp Zeit, dies ruhig herauszufinden, das Skript zu reparieren und die Aktualisierung fortzusetzen.

Im Falle eines Fehlers funktioniert Ansible nicht weiter und belässt die Systeme in einem halbkonfigurierten Zustand. Es wird ein Fehler generiert, um die Aufmerksamkeit des Bedieners auf sich zu ziehen und ihm mitzuteilen, auf welchen Hosts der Aktualisierungszyklus fehlerhaft war und wie viele Änderungen auf jeder Plattform vorgenommen wurden. Ansible verfügt über einen Simulationslaufmodus, in dem das System einen Bericht darüber generiert, welche Änderungen vorgenommen worden wären, wenn das Skript ohne seine tatsächliche Ausführung ausgeführt worden wäre.

Konformitätsprüfung

Es gibt Umgebungen, in denen sich Konfigurationen nur ändern, wenn es ohne sie keinen Weg gibt. Änderungen in solchen Umgebungen werden vorab analysiert. Es werden kontinuierliche Liefersysteme „mit Vorbehalt“ verwendet.

Ansible verfügt über einen Simulationslaufmodus (aktiviert durch das Flag "--check"), in dem das System einen Bericht darüber generiert, welche Änderungen bei der Ausführung des Skripts vorgenommen werden. In diesem Fall findet die eigentliche Ausführung des Skripts nicht statt. Der Simulationslauf lässt keine Fehler zu, hilft jedoch, die Details und Ergebnisse der vorgeschlagenen Änderungen besser zu verstehen und zu analysieren.

Auf der anderen Seite können Sie mit Ansible trotz der kontinuierlichen Bereitstellung neuer Assemblys Konformitätsprüfungen viel häufiger ausführen, um den Moment zu erfassen, in dem sich einige Dinge in der Produktionsumgebung aufgrund menschlicher Eingriffe ändern, und müssen beispielsweise durch Ausführen des entsprechenden Ansible-Skripts behoben werden, um Änderungen vorzunehmen Softwareversion, Berechtigungen anpassen usw.

Autopilot-Bereitstellung

Wenn Sie in einer Welt der mehrstufigen mehrstufigen Orchestrierung sequentieller Software-Update-Prozesse ohne Ausfallzeiten leben, wird CI / CD höchstwahrscheinlich ausschließlich von Bedienern (sowohl manuell als auch mit teilweiser Automatisierung) ausgeführt und erfordert wie im Round Dance koordinierte Aktionen aller Prozessteilnehmer. Ansible kann zusammen mit seiner einzigartigen Architektur und dem Fehlen von Software-Agenten auf den Zielhosts (Erhöhung der Sicherheit und Eliminierung der Notwendigkeit, das Managementsystem selbst zu verwalten) komplexe Bereitstellungsprozesse einfach beschreiben und einfach automatisieren, dh Ansible implementiert hier den vollständigen Autopilot-Modus.

Beispiele für Ansible-Automatisierungsskripte finden Sie auf GitHub . Jetzt geben wir eine Grundlage und ein Beispiel für das Schreiben eines Playbook-Skripts, das in Ansible oder Ansible Tower ausgeführt werden kann. Zusammen mit einer Liste von Modulen und anderen Dokumenten hilft sie Ihnen dabei, zu lernen, wie Sie Ihre eigenen Playbooks-Skripte erstellen.

Was ist ein Spielbuch?

Ein Playbook-Skript besteht im Wesentlichen aus einer Reihe von Spielen, die zur Ausführung auf einem einzelnen Remote-Host oder einer Gruppe von Hosts gesendet werden. Es ist wie bei einer Montageanleitung für IKEA-Möbel: Befolgen Sie die Anweisungen genau und erhalten Sie genau das, was Sie im Geschäft gesehen haben. So funktionieren Skripte.

Module

Wir werden ein Playbook erstellen, das den Webserver auf dem RHEL / CentOS 7-Host installiert und eine index.html-Datei darauf basierend auf der im Skript angegebenen Vorlage erstellt. Das hier gezeigte Beispielskript ist voll funktionsfähig und einsatzbereit. Im Folgenden sehen wir uns ein Beispiel für ein Playbook-Skript an und zeigen, wie die Module verwendet werden.

Autoren (Autoren)

Ein Autor ist jemand, der Anweisungen erstellt, die von Modulen ausgeführt werden (häufig zusammen mit zusätzlichen Werten: Argumente, Speicherorte usw.). Die Module werden auf dem Zielhost in der Reihenfolge ausgeführt, in der sie im Playbook-Skript folgen (einschließlich include'y und anderer darin enthaltener zusätzlicher Dateien). Der Status des Hosts ändert sich (oder ändert sich nicht) in Abhängigkeit von den Ergebnissen der Modulausführung, die in Form von Ansible- und Tower-Ausgabe angezeigt werden.

Playbook-Skriptausführung

Zunächst müssen Sie einige Dinge über das Ausführen von Playbook-Skripten wissen. Playbook ist eine Art symbolisches System, das das Modul über die Notwendigkeit informiert, eine Aufgabe auszuführen. Um Ihr Playbook erfolgreich zu starten, ist es wichtig, die folgenden Punkte zu verstehen:

1. Zielsystem (Ziel)
Da Playbook-Skripte Anweisungen für Module enthalten und mit diesen interagieren, ist Ansible der Ansicht, dass Sie verstehen, was Sie tun möchten, und es einfach automatisieren. Deshalb sagen wir, dass Playbooks wie Anweisungen oder Anweisungen sind: Sie teilen den automatisierten Elementen mit, wie Sie die Aufgabe konfigurieren möchten. Gleichzeitig müssen Sie selbst sehr gut verstehen, wie der Zielhost funktioniert, auf dem das Playbook-Skript ausgeführt wird.

2. Aufgaben
Wenn Sie einen Webserver in einem Teil des Playbooks starten müssen, müssen Sie wissen, wie dies gemacht wird, um zu wissen, welches Servicemodul dafür verwendet werden soll, und um den Webserver mit Namen zu starten. Wenn das Playbook das Softwarepaket installiert, sollten Sie wissen, wie dies auf dem Zielhost ausgeführt wird. Sie sollten zumindest auf einer grundlegenden Ebene auch die Essenz der ausgeführten Aufgaben verstehen. Ist für die Software, die Sie installieren möchten, eine zusätzliche Hostkonfiguration erforderlich? Gibt es Verzweigungen, die von den Bedingungen und Werten der Argumente abhängen? Wenn dabei Variablen übergeben werden, müssen Sie genau verstehen, was und warum.

Playbook Script Beispiel
Das folgende Beispiel für ein Playbook-Skript hilft Ihnen zu verstehen, was Sie gerade gelesen haben. Der Zielhost darin ist der RHEL / CentOS 7-Server, auf dem unser Skript den NGINX-Webserver installiert und anschließend die Datei index.html im Standard-Webroot-Verzeichnis erstellt.Nach Abschluss der Installation und Erstellung des Index wird der Webserver gestartet.

* Hinweis: Um dieses Playbook-Beispielskript in Ansible Tower auszuführen, müssen Sie zuerst Inventar und Konten konfigurieren.

Playbooks beginnen mit drei YAML-Bindestrichen (---), gefolgt von:

Name : Einfach der Name des Skripts, um die Lesbarkeit des Playbooks zu gewährleisten.

Hosts : Eine Liste der Zielhosts, auf denen Ansible arbeiten soll.

Werden Sie : Hier haben wir eine echte Aussage geschrieben, um sicherzustellen, dass nginx ohne Probleme installiert wurde (dieses Feld ist nicht immer erforderlich).

1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 

Mit dem Einzug als den vorherigen drei Zeilen gibt es die Aufgaben : Direktive, nach der mit zusätzlichem Einzug (gemäß den YAML-Verschachtelungsregeln) Aufgaben aufgelistet werden (Spiele). In diesem Beispiel haben wir zwei Aufgaben und beide verwenden das Yum-Modul. Die erste Aufgabe fügt ein Epel-Release-Repository hinzu, damit Sie nginx installieren können. Nachdem epel auf dem System angezeigt wurde, installiert die zweite Task das nginx-Paket.

Die Anweisung state : bedeutet, dass Ansible den Status des Zielhosts überprüfen muss, bevor weitere Aktionen ausgeführt werden. Wenn in unserem Beispiel bereits ein Repository oder Nginx auf dem Host vorhanden ist, versteht Ansible, dass diese beiden Aufgaben nicht ausgeführt werden müssen, und fährt mit den folgenden Schritten fort.

 1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present 

Die Download-Seite, die standardmäßig in nginx verwendet wird, eignet sich hervorragend, um zu überprüfen, ob nginx korrekt installiert wurde. Möglicherweise möchten Sie dies jedoch mit Ihrer HTML-Startdatei tun. In diesem Beispiel befindet sich die Indexdateivorlage der Einfachheit halber in demselben Verzeichnis, in dem das Playbook gestartet wird. Das Ziel ist nur der Standardpfad in Nginix, für den keine Sites konfiguriert sind.

 1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html 

Die letzte Zeile in unserem Playbook dient nur dazu, zu überprüfen, ob der Nginx-Dienst erfolgreich gestartet wurde (oder um ihn zu starten, wenn nicht).

 1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started 

Das gesamte Playbook-Skript war ungefähr so ​​lang wie der erste Absatz in diesem Beitrag:

 1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started 

Zusammenfassung

Playbook-Skripte sind eine einfache und bequeme Möglichkeit, viele Dinge mit ein wenig Code zu erledigen. Im obigen Beispiel haben wir drei Module verwendet: yum, template und service, um das Repository und das Softwarepaket auf dem Server zu installieren, eine Datei aus der lokalen Vorlage zu erstellen und dann den gerade installierten Dienst zu starten. Gleichzeitig erschien unser Playbook-Skript etwas länger als dieses Angebot! Und obwohl wir es auf einem Host ausgeführt haben, kann es genauso gut auf Dutzenden und Hunderten von Servern ausgeführt werden, dafür müssen nur sehr kleine Änderungen vorgenommen werden. Darüber hinaus können Sie mit Tower ein Playbook-Skript in eine Jobvorlage einfügen, um es auf einer Gruppe von Servern in der AWS-Cloud oder in einem Unternehmensdatenzentrum auszuführen.

Ansible Architekturmerkmale und die Fähigkeit zur Integration in CI-Systeme wie Jenkins automatisieren nicht nur Konfigurationsmanagementprozesse, sondern auch ein viel breiteres Spektrum von IT-Aufgaben. Aus diesem Grund nennen wir Ansible liebevoll ein integriertes Orchestrierungssystem und nicht nur ein Tool für die Softwarebereitstellung und das Konfigurationsmanagement.