Automatisierte Proxmox-Abonnementverwaltung mit Ansible

Bei der Bereitstellung von Proxmox VE in Enterprise-Umgebungen, sei es für neue Standorte, die Erweiterung bestehender Cluster oder die Migration von Plattformen wie VMware, ist Automatisierung unerlässlich. Diese Szenarien umfassen typischerweise die Bereitstellung von Dutzenden oder sogar Hunderten von Knoten über mehrere Standorte hinweg. Das manuelle Aktivieren von Abonnements über die Proxmox-Weboberfläche ist in diesem Umfang nicht praktikabel.

Um Konsistenz und Effizienz zu gewährleisten, sollte jeder Teil des Bereitstellungsprozesses von Anfang an automatisiert werden. Dies umfasst nicht nur die Installation und Konfiguration von Knoten, die automatisierte Cluster-Erstellung, sondern auch die Aktivierung des Proxmox-Abonnements. In der Vergangenheit erforderte dieser Schritt oft eine manuelle Interaktion, was die Bereitstellung verlangsamte und unnötige Komplexität verursachte.

Jetzt gibt es eine saubere Lösung dafür. Mit der Einführung des neuen Ansible-Moduls proxmox_node ist die Abonnementverwaltung vollständig integriert. Dieses Modul ermöglicht es Ihnen, die Abonnementaktivierung als Teil Ihrer Ansible-Playbooks zu handhaben, wodurch es möglich wird, den gesamten Prozess zu automatisieren, ohne jemals die Weboberfläche öffnen zu müssen.

Diese Verbesserung ist besonders wertvoll für Massenbereitstellungen, bei denen Zuverlässigkeit und Wiederholbarkeit am wichtigsten sind. Jeder Knoten kann nun direkt nach dem Booten automatisch konfiguriert, lizenziert und produktionsbereit sein. Es ist ein großartiges Beispiel dafür, wie sich Proxmox VE kontinuierlich zu einer unternehmensfreundlicheren Plattform entwickelt und gleichzeitig die Flexibilität und Offenheit beibehält, die es auszeichnet.

Ansible-Modul: proxmox_node

Da die Automatisierung in modernen IT-Betrieben immer wichtiger wird, ist die Verwaltung der Proxmox VE-Infrastruktur über standardisierte Tools wie Ansible zu einer gängigen Praxis geworden. Bis jetzt, obwohl verschiedene Community-Module zur Interaktion mit Proxmox-Ressourcen verfügbar waren, erforderte die Knotenverwaltung oft benutzerdefinierte Workarounds oder direkten SSH-Zugriff. Diese Lücke wurde nun mit der Einführung des neuen proxmox_node Moduls geschlossen.

Dieses Modul wurde von unserem Team bei credativ GmbH entwickelt, insbesondere von unserem Kollegen, der in der Community unter dem Handle gyptazy bekannt ist. Es wurde Upstream beigetragen und ist bereits Teil der offiziellen Ansible Community Proxmox Collection, die jedem zur Verfügung steht, der die Collection über Ansible Galaxy oder Automation Controller Integrationen verwendet.

Das proxmox_node Modul konzentriert sich auf Aufgaben, die direkt mit dem Lebenszyklus und der Konfiguration eines Proxmox VE-Knotens zusammenhängen. Was dieses Modul besonders leistungsfähig macht, ist, dass es direkt mit der Proxmox API interagiert, ohne dass ein SSH-Zugriff auf den Knoten erforderlich ist. Dies ermöglicht einen saubereren, sichereren und API-gesteuerten Ansatz zur Automatisierung.

Das Modul unterstützt derzeit mehrere Schlüsselfunktionen, die im realen Betrieb unerlässlich sind:

• Verwaltung von Abonnementlizenzen
  Eine der herausragenden Funktionen ist die Möglichkeit, einen Proxmox VE-Abonnementschlüssel automatisch hochzuladen und zu aktivieren. Dies ist unglaublich hilfreich für Unternehmen, die Cluster in großem Umfang ausrollen, wo die Lizenzierung konsistent und automatisch als Teil des Bereitstellungs-Workflows gehandhabt werden sollte.
• Steuerung der Leistungszustände
  Die Energieverwaltung von Knoten kann nun über Ansible erfolgen, was es einfach macht, Knoten im Rahmen von Playbook-gesteuerten Wartungsaufgaben oder während automatisierter Clusteroperationen zu starten (über Wake-on-Lan) oder herunterzufahren.
  
• Verwaltung der DNS-Konfiguration
  DNS-Einstellungen wie Resolver und Suchdomänen können deklarativ geändert werden, wodurch sichergestellt wird, dass alle Knoten die gleichen Konfigurationsrichtlinien ohne manuelle Eingriffe befolgen.
  
• Verwaltung von X509-Zertifikaten
  Das Modul ermöglicht es Ihnen auch, die von dem Knoten verwendeten TLS-Zertifikate zu verwalten. Unabhängig davon, ob Sie intern PKI-signierte Zertifikate bereitstellen oder extern ausgestellte verwenden, können Sie mit dem proxmox_node Modul diese über die Automatisierung auf saubere und wiederholbare Weise hochladen und anwenden.

Indem all diese Funktionalität in einem einzigen, API-gesteuerten Ansible-Modul zusammengeführt wird, wird der Prozess der Verwaltung von Proxmox-Knoten wesentlich zuverlässiger und wartungsfreundlicher. Sie müssen nicht mehr mit Shell-Befehlen um pveproxy herumskripten oder SSH verwenden, nur um Knoteneinstellungen zu verwalten.

Beispiel für die Integration von Abonnements

Das Hinzufügen eines Abonnements zu einem Proxmox VE-Knoten ist so einfach wie die folgende Aufgabe. Dies zeigt zwar den einfachsten Weg für einen einzelnen Knoten, kann aber auch in einer Schleife über ein Dictionary verwendet werden, das die zugehörigen Abonnements für jeden Knoten enthält.

- name: Platzieren einer Abonnementlizenz auf einem Proxmox VE-Knoten
  community.proxmox.node:
  api_host: proxmoxhost
  api_user: gyptazy@pam
  api_password: password123
  validate_certs: false
  node_name: de-cgn01-virt01
  subscription:
  state: present
  key: ABCD-EFGH-IJKL-MNOP-QRST-UVWX-YZ0123456789

Fazit

Für uns bei credativ schließt dieses Modul eine echte Lücke in der Automatisierungslandschaft rund um Proxmox und demonstriert, wie fehlende Funktionen in Open-Source-Projekten durch Upstream-Beiträge effektiv angegangen werden können. Es verstärkt auch die breitere Bewegung der deklarativen Verwaltung von Infrastruktur, bei der die Konfiguration versioniert, dokumentiert und leicht reproduzierbar ist.

In Kombination mit anderen Modulen aus der Community Proxmox Collection wie unserem kürzlich erschienenen proxmox_cluster Modul, proxmox_node hilft, das Bild einer vollständig automatisierten Proxmox VE-Umgebung zu vervollständigen — von der Cluster-Erstellung und VM-Bereitstellung bis hin zur Knotenkonfiguration und Lizenzierung. Wenn Sie Hilfe oder Unterstützung bei der Erstellung von Proxmox VE-basierten Virtualisierungsinfrastrukturen, Automatisierung oder kundenspezifischer Entwicklung zur Anpassung an Ihre Bedürfnisse suchen, helfen wir Ihnen gerne weiter! Sie können uns jederzeit gerne kontaktieren.

Effiziente Proxmox-Cluster-Bereitstellung durch Automatisierung mit Ansible

Das manuelle Einrichten und Verwalten von Servern ist in der Regel zeitaufwendig, fehleranfällig und schwer zu skalieren. Dies wird besonders bei groß angelegten Rollouts, beim Aufbau komplexer Infrastrukturen oder bei der Migration aus anderen Virtualisierungsumgebungen deutlich. In solchen Fällen stoßen traditionelle manuelle Prozesse schnell an ihre Grenzen. Eine konsequente Automatisierung bietet eine effektive und nachhaltige Lösung für diese Herausforderungen.

Proxmox ist eine leistungsstarke Virtualisierungsplattform, die für ihre Flexibilität und ihren umfassenden Funktionsumfang bekannt ist. In Kombination mit Ansible, einem schlanken und agentenlosen Automatisierungstool, wird die Verwaltung ganzer Systemlandschaften deutlich effizienter. Ansible ermöglicht die Definition wiederverwendbarer Konfigurationen in Form von Playbooks, wodurch sichergestellt wird, dass Bereitstellungsprozesse konsistent, transparent und reproduzierbar sind.

Um eine vollständig automatisierte Bereitstellung von Proxmox-Clustern zu ermöglichen, hat unser Teammitglied, das in der Open-Source-Community unter dem Alias gyptazy bekannt ist, ein dediziertes Ansible-Modul namens proxmox_cluster. Dieses Modul übernimmt alle notwendigen Schritte, um einen Proxmox-Cluster zu initialisieren und zusätzliche Knoten hinzuzufügen. Es wurde offiziell in die Upstream Ansible Community Proxmox Collection aufgenommen und ist ab Version 1.1.0 über Ansible Galaxy installierbar. Dadurch wird der manuelle Aufwand für die Cluster-Bereitstellung deutlich reduziert. Weitere Einblicke finden Sie in seinem Blogbeitrag mit dem Titel „How My BoxyBSD Project Boosted the Proxmox Ecosystem„.

Durch die Einführung dieser Lösung kann nicht nur wertvolle Zeit gespart werden, sondern es wird auch eine solide Grundlage für eine skalierbare und wartungsarme Infrastruktur geschaffen. Im Gegensatz zu fragilen, aufgabenbasierten Ansätzen, die oft auf Ansibles shell oder command Modulen basieren, nutzt diese Lösung das volle Potenzial der Proxmox-API durch ein dediziertes Modul. Dadurch kann sie in verschiedenen Bereichen ausgeführt werden und benötigt keinen SSH-Zugriff auf die Zielsysteme.

Dieser automatisierte Ansatz ermöglicht es, komplexe Setups effizient bereitzustellen und gleichzeitig die Grundlage für stabile und zukunftssichere IT-Umgebungen zu schaffen. Solche Umgebungen können zu einem späteren Zeitpunkt erweitert werden und sind nach einer konsistenten und wiederholbaren Struktur aufgebaut.

Vorteile

Die Verwendung des proxmox_cluster Moduls für die Proxmox-Cluster-Bereitstellung bringt mehrere entscheidende Vorteile für moderne IT-Umgebungen. Der Fokus liegt auf einer sicheren, flexiblen und skalierbaren Interaktion mit der Proxmox-API, einer verbesserten Fehlerbehandlung und einer vereinfachten Integration in verschiedenen Anwendungsfällen:

• Nutzung der nativen Proxmox-API
• Volle Unterstützung für das Proxmox-Authentifizierungssystem
  • Unterstützung der API-Token-Authentifizierung
• Kein SSH-Zugriff erforderlich
• Einsetzbar in mehreren Bereichen:
  • Von einem dedizierten Bereitstellungs-Host
  • Von einem lokalen System
  • Innerhalb des Kontexts des Zielsystems selbst
• Verbesserte Fehlerbehandlung durch API-Abstraktion

Ansible Proxmox Modul: proxmox_cluster

Das neu hinzugefügte proxmox_cluster Modul in Ansible vereinfacht die automatisierte Bereitstellung von Proxmox VE-Clustern erheblich. Mit nur einer einzigen Aufgabe ermöglicht es die nahtlose Erstellung eines kompletten Clusters, wodurch Komplexität und manueller Aufwand auf ein Minimum reduziert werden.

Erstellung eines Clusters

Die Erstellung eines Clusters erfordert jetzt nur noch eine einzige Aufgabe in Ansible unter Verwendung des Proxmox_Cluster-Moduls:

- name: Create a Proxmox VE Cluster
  community.proxmox.proxmox_cluster:
  state: present
  api_host: proxmoxhost
  api_user: root@pam
  api_password: password123
  api_ssl_verify: false
  link0: 10.10.1.1
  link1: 10.10.2.1
  cluster_name: "devcluster"

Anschließend wird der Cluster erstellt und zusätzliche Proxmox VE-Knoten können dem Cluster beitreten.

Beitritt zu einem Cluster

Zusätzliche Knoten können dem Cluster nun ebenfalls mit einer einzigen Aufgabe beitreten. In Kombination mit der Verwendung eines dynamischen Inventars wird es einfach, eine Liste von Knoten aus einer definierten Gruppe zu durchlaufen und diese innerhalb einer Schleife dem Cluster hinzuzufügen. Dieser Ansatz ermöglicht die schnelle Bereitstellung größerer Proxmox-Cluster auf effiziente und skalierbare Weise.

- name: Join a Proxmox VE Cluster
  community.proxmox.proxmox_cluster:
  state: present
  api_host: proxmoxhost
  api_user: root@pam
  api_password: password123
  master_ip: "{{ primary_node }}"
  fingerprint: "{{ cluster_fingerprint }}"
  cluster_name: “devcluster"

Cluster-Beitrittsinformationen

Damit ein Knoten einem Proxmox-Cluster beitreten kann, sind in der Regel die Beitrittsinformationen des Clusters erforderlich. Um diese Informationen nicht für jeden einzelnen Cluster manuell definieren zu müssen, kann auch dieser Schritt automatisiert werden. Im Rahmen dieser Funktion wurde ein neues Modul namens cluster_join_info eingeführt. Es ermöglicht, die notwendigen Daten automatisch über die Proxmox-API abzurufen und für die weitere Verwendung im Automatisierungsprozess bereitzustellen.

- name: List existing Proxmox VE cluster join information
  community.proxmox.proxmox_cluster_join_info:
  api_host: proxmox1
  api_user: root@pam
  api_password: "{{ password | default(omit) }}"
  api_token_id: "{{ token_id | default(omit) }}"
  api_token_secret: "{{ token_secret | default(omit) }}"
  register: proxmox_cluster_join

Fazit

Während die Automatisierung im Kontext von Virtualisierungstechnologien oft auf die Bereitstellung von Gastsystemen oder virtuellen Maschinen (VMs) ausgerichtet ist, zeigt dieser Ansatz, dass Automatisierung auf einer viel tieferen Ebene innerhalb der zugrunde liegenden Infrastruktur angewendet werden kann. Es ist auch möglich, Szenarien vollständig zu automatisieren, in denen Knoten zunächst mit einem kundenspezifischen Image mit vorinstalliertem Proxmox VE bereitgestellt werden und anschließend automatisch der Cluster erstellt wird.

Als offizieller Proxmox-Partner unterstützen wir Sie gerne bei der Implementierung einer umfassenden Automatisierungsstrategie, die auf Ihre Umgebung zugeschnitten ist und auf Proxmox-Produkten basiert. Sie können uns jederzeit kontaktieren!

pg_createconfig_patroni 11 test

systemctl start patroni@11-test

for i in pg1 pg2 pg3; do ssh $i 'apt -y install postgresql-common'; done
for i in pg1 pg2 pg3; do ssh $i 'sed -i "s/^#create_main_cluster = true/create_main_cluster = false/" /etc/postgresql-common/createcluster.conf'; done
for i in pg1 pg2 pg3; do ssh $i 'apt -y install patroni postgresql'; done
for i in pg1 pg2 pg3; do scp ./dcs.yml $i:/etc/patroni; done
for i in pg1 pg2 pg3; do ssh @$i 'pg_createconfig_patroni 11 test' && systemctl start patroni@11-test'; done

ssh pg1 'patronictl -c /etc/patroni/11-patroni.yml list'
+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 | Leader | running |  1 |           |
| 11-test |  pg2   | 10.0.3.41  |        | stopped |    |   unknown |
| 11-test |  pg3   | 10.0.3.46  |        | stopped |    |   unknown |
+---------+--------+------------+--------+---------+----+-----------+

+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 | Leader | running |  1 |         0 |
| 11-test |  pg2   | 10.0.3.41  |        | running |  1 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  1 |         0 |
+---------+--------+------------+--------+---------+----+-----------+

ssh pg1 'pg_lsclusters'
Ver Cluster Port Status Owner    Data directory                 Log file
11  test    5432 online postgres /var/lib/postgresql/11/test    /var/log/postgresql/postgresql-11-test.log

+---------+--------+-----------+------+---------+----+-----------+
| Cluster | Member |    Host   | Role |  State  | TL | Lag in MB |
+---------+--------+-----------+------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 |      | running |  1 |         0 |
| 11-test |  pg3   | 10.0.3.46 |      | running |  1 |         0 |
+---------+--------+-----------+------+---------+----+-----------+
[...]
+---------+--------+-----------+--------+---------+----+-----------+
| Cluster | Member |    Host   |  Role  |  State  | TL | Lag in MB |
+---------+--------+-----------+--------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46 |        | running |  1 |         0 |
+---------+--------+-----------+--------+---------+----+-----------+
[...]
+---------+--------+-----------+--------+---------+----+-----------+
| Cluster | Member |    Host   |  Role  |  State  | TL | Lag in MB |
+---------+--------+-----------+--------+---------+----+-----------+
| 11-test |  pg2   | 10.0.3.41 | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46 |        | running |  2 |         0 |
+---------+--------+-----------+--------+---------+----+-----------+

+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 |        | running |    |   unknown |
| 11-test |  pg2   | 10.0.3.41  | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  2 |         0 |
+---------+--------+------------+--------+---------+----+-----------+
[...]
+---------+--------+------------+--------+---------+----+-----------+
| Cluster | Member |    Host    |  Role  |  State  | TL | Lag in MB |
+---------+--------+------------+--------+---------+----+-----------+
| 11-test |  pg1   | 10.0.3.111 |        | running |  2 |         0 |
| 11-test |  pg2   | 10.0.3.41  | Leader | running |  2 |         0 |
| 11-test |  pg3   | 10.0.3.46  |        | running |  2 |         0 |
+---------+--------+------------+--------+---------+----+-----------+

for i in pg1 pg2 pg3; do ssh $i 'pg_createconfig_patroni 11 test2 && systemctl start patroni@11-test2'; done
ssh pg1 'patronictl -c /etc/patroni/11-test2.yml list'
+----------+--------+-----------------+--------+---------+----+-----------+
| Cluster  | Member |       Host      |  Role  |  State  | TL | Lag in MB |
+----------+--------+-----------------+--------+---------+----+-----------+
| 11-test2 |  pg1   | 10.0.3.111:5433 | Leader | running |  1 |         0 |
| 11-test2 |  pg2   |  10.0.3.41:5433 |        | running |  1 |         0 |
| 11-test2 |  pg3   |  10.0.3.46:5433 |        | running |  1 |         0 |
+----------+--------+-----------------+--------+---------+----+-----------+

Am 22.06.2017 fand in der Finanzmetropole London das alljährliche AnsibleFest statt. Unweit des beeindruckenden Millennium Dome, auch unter dem Namen „The O2“ bekannt, konnten Besucher aus aller Welt im InterContinental Hotel am Fuße der Themse am diesjährigen AnsibleFest London teilnehmen.

London wechselt sich dabei halbjährlich mit der kalifornischen Stadt San Francisco ab, die ihr AnsibleFest in diesem Jahr am 07. September veranstalten wird.

Das Fest dient in erster Linie dazu Ansible-Benutzer, Entwickler und auch Größen aus der Industrie näher zusammenzubringen. In mehreren Vorträgen haben die Besucher die Chance, sich in bestimmten Bereichen von Ansible weiterzubilden oder auch in Frage- und Antwortrunden direkten Kontakt mit einigen Hauptverantwortlichen von Ansible aufzunehmen.

Für die Sponsoren war Gelegenheit gegeben, ihre Produkte zu präsentieren. Red Hat hatte dabei den größten Anteil und bot mit Demosystemen einiger Lösungen einen guten Einblick in die Produktpalette.

Die credativ GmbH war an diesem AnsibleFest durch die Kollegen André Nähring und mich, Michael Sprengel vertreten. Wir beide haben im großen Umfang täglich mit Ansible zu tun und hatten durch das AnsibleFest die Chance, unsere Erfahrungen mit anderen Ansible-Benutzern und Entwicklern zu teilen.

Das diesjährige AnsibleFest war das bisher größte seiner Art. Weit über 800 Besucher fanden sich im großen Ballsaal des InterContinental wieder.

Um das Eis zwischen den Besuchern zu brechen, wurden die ersten Minuten des ersten Vortrags dazu genutzt, sich dem jeweiligen Sitznachbarn vorzustellen, um seine bisherige Erfahrung mit Ansible mit dieser Person auszutauschen. Dabei konnte man beobachten, dass viele Besucher die Veranstaltung für ein erstes Kennenlernen mit Ansible nutzen wollten.

Nach diesen doch recht spannenden zwei Minuten gingen die nachfolgenden Vorträge primär auf die bisherigen Partnerschaften mit weiteren Industriegrößen, wie zum Beispiel Microsoft, Google, Amazon, und VMWare ein. Auch wurde bereits eine Roadmap für die zukünftigen Versionen von Ansible und Ansible Tower skizziert. Dabei soll zum Beispiel der Fokus der zukünftigen Ansible-Versionen vor allem auf Python3, der Integration von Windows, dem Bereich Networking und Container liegen. Der Releasetermin ist gegenwärtig für den 24. September 2017 geplant. Ansible Tower in der Version 3.2 soll ebenfalls im Herbst 2017 erscheinen. Es wurde von den Rednern, wie zum Beispiel Jason McKerr (Director of Engineering), noch einmal bekräftigt, dass die Pläne Ansible Tower in Zukunft unter einer Open-Source-Lizenz frei anzubieten, weiterhin verfolgt werden. Ein genaues Datum wurde hingegen leider nicht genannt.

Das Vormittagsprogramm wurde durch Richard Henshall (Chief Architect for Cloud bei HSBC), Lieutenant Colonel Dorian Seabrook als auch Aidan Beeson (British Army) und Mohamed Ghaleb (Program Manger bei Siemens) abgerundet, die ihre und die Erfahrungen ihres Teams den Besuchern in Form eines Interviews mit Justin Nemmers (General Manager von Ansible) vorstellten und offen legten, wie Ansible ihnen bei der Automatisierung vieler verschiedener Aufgaben geholfen hat.

Anschließend konnten die Besucher sich am Buffet, mit direktem Ausblick auf das Bankenviertel von London, stärken. Fortan hatten die Gäste die Möglichkeit sich zwischen vier Tracks mit je vier Präsentationen zu entscheiden. Dies stellte eine Neuerung zu den bisher in London stattgefundenen AnsibleFesten dar.

So konnte zwischen den Tracks Essentials, Solution, Networking und Tech Deep Dive gewählt werden. Wir beide haben an einer Vielzahl von Präsentationen aus den Tracks Solution und Tech Deep Dive teilgenommen. Die Tracks konnten in den Pausen störungsfrei gewechselt werden. Jede Präsentation war hierbei auf 45 Minuten begrenzt. Dies empfanden wir in der ein oder anderen Situation als kleinen Wermutstropfen, da ein paar der Präsentationen genau dann aufhörten, als diese gerade richtig Fahrt aufgenommen hatten.

Nichtsdestotrotz fanden wir die Vielzahl der Präsentationen und die Wahl der verschiedenen Tracks als gelungene Mischung.

So konnten wir zum Beispiel einige Tipps und Tricks aus Vorträgen, wie „Running Ansible at Scale“, „Automated Management of Shared Secrets with Ansible“, „Ansible is in Our DNA: Automation at Illumina“ und noch viele mehr, mitnehmen. Ein kleines Highlight war zudem die Präsentation „Automating Your Business Application’s REST API with Ansible“, die von unserem früheren Kollegen Roland Wolters, mittlerweile Solutions Architect bei Red Hat, gehalten wurde.

Um 17:00 Uhr endeten alle Vorträge und die Besucher wurden zu einer Cocktailveranstaltung an der Bar eingeladen, um das AnsibleFest vollends abzuschließen. Hier bot sich nochmal die Gelegenheit, sich mit anderen Besuchern, aber auch mit den Entwicklern von Ansible selbst, zusammensetzen, auszutauschen und in Ruhe den Tag ausklingen zu lassen.

Damit endete ein aufregender und ereignisreicher Tag voller Vorträge im Herzen der englischen Finanzmetropole London.

---
- hosts: webservers
  vars:
    http_port: 80
    max_clients: 200
  remote_user: root
 
  tasks:
    - name: ensure apache is at the latest version
      apt: pkg=apache2-mpm-worker state=latest
 
    - name: write the apache config file
      template: 
        src=httpd.j2 
        dest=/etc/apache2/apache.conf
      notify:
      - restart apache
 
    - name: ensure apache is running
      service: name=apache2 state=started
 
  handlers:
    - name: restart apache
      service: name=apache2 state=restarted

$ ansible -m service -a "name=apache2 state=restarted" webservers
$ ansible -m apt -a "pkg=htop state=present" all