settings
OTEX_BIGISTQB®
Süddeutsche Zeitung Institut Auszeichnung
Image
Alle Red Hat Schulungen

Schulung Red Hat Ansible Automation Platform 2.x: Administration und Betrieb

Automation Controller, Automation Hub, Execution Environments und Event-Driven Ansible

3 Tage / S6902
Neues Seminar
Per E-Mail senden

Schulungsformen

Inhouse-/Firmenschulung

  • 3 Tage - anpassbar
  • Termin nach Wunsch
  • In Ihrem Hause oder bei der GFU
  • Preis nach Angebot
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen

Beschreibung

Ansible auf der Kommandozeile funktioniert - für ein Team von drei Personen. Aber wenn 20 Administratoren, 5 Entwickler und 3 Teams in verschiedenen Zeitzonen dieselbe Automatisierung nutzen, wird Ansible auf der Kommandozeile zum Problem: Wer hat welches Playbook wann gegen welches Inventory ausgeführt? Wer darf auf die Produktionsserver zugreifen? Wo liegt die aktuelle Version des Playbooks - auf dem Laptop von Maria oder dem Git-Branch von Thomas? Warum funktioniert das Playbook auf Marias Rechner, aber nicht auf dem von Thomas (unterschiedliche Python-Versionen, unterschiedliche Collections)?
Die Ansible Automation Platform (AAP) löst all das. Der Automation Controller (ehemals Ansible Tower) bietet eine Weboberfläche, rollenbasierte Zugriffskontrolle, Credential-Management, Job-Scheduling, Audit-Logging und API-Zugriff. Der Private Automation Hub verwaltet Ansible-Content zentral (Collections und Execution Environments mit Approval-Workflows). Execution Environments lösen das „Works on my machine"-Problem: Container-Images mit definierter Python-Version, definierten Collections und definierten Abhängigkeiten - identisch auf jedem System. Und der EDA Controller macht Ansible reaktiv: Events aus Monitoring-Systemen, Cloud-Providern oder Ticketsystemen triggern automatisch Playbooks - ohne menschlichen Eingriff.
AAP 2.x ist eine fundamental neue Architektur gegenüber dem alten Ansible Tower - wer Tower kennt, muss umlernen. Wer AAP nicht kennt, startet mit der aktuellen Architektur.

Entdecken Sie auch unsere anderen Red Hat Schulungen.

Schulungsziel

Jede teilnehmende Person verlässt das Seminar mit einer vollständig konfigurierten AAP-Instanz (Controller, Hub, Execution Environments, EDA), dem Verständnis der AAP-2.x-Architektur (und der Unterschiede zu Tower 3.x), der Fähigkeit, RBAC, Workflows und Credentials produktionsreif zu konfigurieren, einem eigenen Execution Environment (gebaut, gepusht, genutzt), praktischer EDA-Erfahrung (Rulebook, Webhook-Source, automatische Playbook-Ausführung) und einem Betriebskonzept (Backup, Upgrade, Mesh, Monitoring).

Details

Inhalt

Tag 1: Architektur, Installation und Automation Controller
1. AAP 2.x Architektur und Komponenten
  • Ziele und Erwartungen der Teilnehmenden
    • Klärung individueller Lernziele und Erwartungen für ein praxisnahes und relevantes Seminar
  • Ansible auf der Kommandozeile vs. AAP: Was ändert sich? Zentrale Verwaltung, RBAC, Audit, Scheduling, API - warum Enterprise-Automatisierung eine Plattform braucht.
  • Die vier Säulen: Automation Controller (Weboberfläche, Job-Ausführung, RBAC - ehemals Tower), Private Automation Hub (Content-Management: Collections, Execution Environments, Approval Workflows), Execution Environments (Container-basierte Ansible-Laufzeit - ersetzt Python-Virtualenvs), EDA Controller (Event-Driven Ansible - reaktive Automatisierung).
  • Architektur: Automation Controller Cluster (mehrere Nodes für HA), Execution Nodes (dedizierte Nodes für Job-Ausführung - Separation of Concerns), Hop Nodes (Relay-Nodes für segmentierte Netzwerke - DMZ, Air-Gapped), Automation Hub (On-Premises oder cloud.redhat.com).
  • Lizenzierung: AAP-Subscription (Managed Nodes), Red Hat Manifest für Activation.
  • AAP 2.x vs. Tower 3.x: Was hat sich geändert? Execution Environments statt Python-Virtualenvs, Automation Mesh statt isolierte Nodes, Operator-basierte Installation auf OpenShift, neues UI.
  • Praxis-Übung: AAP-Architektur-Diagramm verstehen: Controller, Hub, Execution Nodes, Hop Nodes. Installations-Voraussetzungen prüfen (RHEL, Subscription, Netzwerk).
2. Installation und Grundkonfiguration
  • Installations-Methoden: RPM-basiert auf RHEL (Standalone oder Cluster), Operator-basiert auf OpenShift, Containerized Installation (Tech Preview). Installer-Inventory: Welche Nodes übernehmen welche Rolle?
  • Ersteinrichtung: Weboberfläche aufrufen, Subscription aktivieren (Manifest), Administrator-Account, grundlegende Einstellungen (Logging, LDAP/SAML-Anbindung vorbereiten, Proxy, Zertifikate).
  • Organisationen: Mandantenfähigkeit - jede Organisation hat eigene Projekte, Inventories, Credentials, Teams und Benutzer. Für Unternehmen mit mehreren Abteilungen oder Kunden.
  • Praxis-Übung: AAP auf einer vorbereiteten RHEL-Umgebung installieren (Standalone). Subscription aktivieren, erste Organisation erstellen, Administrator-Account konfigurieren.
3. Automation Controller: Projekte, Inventories und Credentials
  • Projekte: Git-Repositories als Quelle für Playbooks und Rollen. SCM-Anbindung (Git, SVN, Mercurial), automatische Synchronisation (bei jedem Job oder per Schedule), Branch-/Tag-/Commit-Auswahl.
  • Inventories: Statische Inventories (manuelle Host-Eingabe), dynamische Inventories (aus Cloud-Providern: AWS, Azure, GCP, VMware, Satellite, OpenShift - Hosts werden automatisch erkannt), Smart Inventories (Filter auf bestehende Inventories).
  • Credentials: Sichere Speicherung von Zugangsdaten - SSH-Keys, Passwörter, Cloud-Provider-Tokens, Vault-Passwörter, Container-Registry-Logins. Credentials werden verschlüsselt gespeichert und nie im Klartext angezeigt. Credential Types für Custom-Integrationen.
  • Praxis-Übung: Git-Projekt einbinden (Repository mit Playbooks und Rollen), Inventory mit 4 Managed Nodes erstellen, 3 Credentials anlegen (SSH-Key, Vault-Passwort, Cloud-Provider-Token).
Tag 2: Templates, Workflows und RBAC
4. Job Templates und Workflow Templates
  • Job Templates: Verknüpfung von Projekt + Inventory + Credential + Playbook zu einer ausführbaren Einheit. Extra-Variablen, Verbosity, Forks, Job-Tags, Limit. Survey: Formulare für Endanwender (Eingabefelder vor der Ausführung - z.B. „Auf welchem Server soll deployed werden?").
  • Workflow Templates: Mehrere Job Templates in einem visuellen Workflow verketten. Verzweigungen (bei Erfolg -> nächster Job, bei Fehler -> Rollback-Job, immer -> Notification). Approval Nodes: Menschliche Genehmigung als Schritt im Workflow (z.B. Produktion-Deployment erst nach Manager-Freigabe).
  • Scheduling: Jobs und Workflows zeitgesteuert ausführen (einmalig, wiederkehrend). Für: Patch-Zyklen, Compliance-Checks, Nacht-Deployments.
  • Notifications: E-Mail, Slack, Webhook, PagerDuty bei Job-Start, -Erfolg oder -Fehler.
  • Praxis-Übung: 3 Job Templates erstellen (Basis-Härtung, Webserver-Deployment, Compliance-Check). Workflow: Härtung -> Deployment -> Compliance-Check mit Fehler-Branch (bei Compliance-Fehler -> Rollback). Survey für Server-Auswahl. Scheduling für nächtlichen Compliance-Check.
5. Rollenbasierte Zugriffskontrolle (RBAC)
  • Benutzer und Teams: Lokale Benutzer oder externe Authentifizierung (LDAP, Active Directory, SAML, OIDC). Teams als Gruppierung von Benutzern.
  • Rollen und Berechtigungen: Feingranulare Berechtigungen auf jeder Ebene - Organisation, Projekt, Inventory, Credential, Template. Vordefinierte Rollen: Admin, Execute, Read, Use, Update. Custom-Rollen für spezifische Anforderungen.
  • Typische RBAC-Szenarien: Entwickler dürfen Templates auf Dev-Inventory ausführen, aber nicht auf Produktion. Operations darf alles ausführen, aber keine Templates ändern. Security-Team sieht nur Compliance-Projekte. Manager genehmigt Produktions-Deployments (Approval Node).
  • Audit und Logging: Jede Aktion wird protokolliert - wer hat wann welches Template gegen welches Inventory ausgeführt, mit welchem Ergebnis. Job-Output persistent gespeichert. Für Compliance-Nachweise und Troubleshooting.
  • Praxis-Übung: 3 Teams erstellen (Entwicklung, Operations, Security), Benutzer zuweisen, RBAC konfigurieren: Entwicklung darf Dev-Templates ausführen, Operations darf Produktion, Security sieht nur Compliance-Jobs. Audit-Log inspizieren.
6. Execution Environments: Container-basierte Ansible-Laufzeit
  • Das Problem, das EE löst: Auf der Kommandozeile: jeder Admin hat andere Python-Versionen, andere Collections, andere Dependencies -> „Works on my machine". Mit Execution Environments: definierte Container-Images mit exakten Versionen -> identisch auf jedem System.
  • Aufbau: Base Image (RHEL UBI + Python + Ansible Core), Collections (automatisch installiert), Python-Dependencies (pip-Packages), System-Dependencies (RPM-Packages). Alles in einem Container-Image gebündelt.
  • Execution Environments bauen: Definition über eine YAML-Datei (Base Image, Collections, Dependencies). Build-Tool erstellt das Container-Image. Image in Registry pushen (Private Automation Hub oder externe Registry).
  • Execution Environments im Controller: Image-Referenz im Job Template auswählen. Verschiedene EEs für verschiedene Aufgaben (ein EE für Cloud-Automatisierung mit AWS/Azure-Collections, ein anderes für Netzwerk-Automatisierung mit Cisco/Aruba-Collections).
  • Praxis-Übung: Eigenes Execution Environment bauen: Base Image + 3 Collections + 2 Python-Dependencies. Image bauen, in den Private Automation Hub pushen, im Controller als EE registrieren, Job Template mit eigenem EE ausführen.
Tag 3: Private Automation Hub, EDA und Produktionsbetrieb
7. Private Automation Hub: Content-Management
  • Automation Hub als internes Galaxy: Collections zentral verwalten, versionieren und an Teams verteilen. Kein unkontrollierter Download von galaxy.ansible.com - nur freigegebene Collections.
  • Content Curation: Collections von Ansible Galaxy oder Automation Hub (cloud.redhat.com) spiegeln, prüfen, freigeben. Approval Workflows: Collection wird hochgeladen -> Reviewer prüft -> Freigabe -> verfügbar für alle Teams.
  • Execution Environment Registry: Container-Images für Execution Environments zentral speichern und verteilen. Controller zieht EE-Images vom Hub.
  • Namespaces und Zugriffskontrolle: Wer darf Collections hochladen? Wer darf sie nutzen? Namespace-basierte Trennung für verschiedene Teams.
  • Praxis-Übung: Private Automation Hub konfigurieren: Remote-Repository für Red-Hat-Certified-Collections einrichten, 3 Collections synchronisieren, Approval Workflow für eine Custom-Collection durchspielen, Execution Environment-Image im Hub speichern.
8. Event-Driven Ansible (EDA): Reaktive Automatisierung
  • Paradigmenwechsel: Klassisches Ansible = imperativ (Admin führt Playbook aus). EDA = reaktiv (Event tritt ein -> Rulebook entscheidet -> Playbook wird automatisch ausgeführt). Reduzierung der Mean Time to Repair (MTTR) durch automatisierte Incident Response.
  • EDA-Architektur: Event Sources (Monitoring: Prometheus/Alertmanager, Ticketing: ServiceNow, Cloud: AWS CloudWatch/Azure Monitor, Webhooks, Kafka), Rulebooks (Wenn Event X -> dann Playbook Y), Decision Environment (Container-Image für EDA - analog zu Execution Environments), EDA Controller (Weboberfläche, Rulebook-Verwaltung, Aktivierungen).
  • Rulebook-Aufbau: Sources (woher kommen Events?), Rules (Bedingungen: Event-Typ, Schweregrad, betroffener Host), Actions (Playbook ausführen, Debug-Output, Event an anderen Service weiterleiten).
  • Typische Use Cases: Monitoring-Alert „Disk Full" -> Playbook räumt temporäre Dateien auf. ServiceNow-Ticket „Neuer Server" -> Playbook provisioniert und konfiguriert automatisch. Webhook von CI/CD -> Playbook deployt Applikation.
  • Praxis-Übung: EDA Controller einrichten, Webhook-Source konfigurieren, Rulebook schreiben (Webhook-Event mit bestimmtem Payload -> Playbook auf Zielhost ausführen), Webhook senden -> automatische Playbook-Ausführung beobachten.
9. Produktionsbetrieb und Praxis-Workshop
Produktionsbetrieb (30 Min):
  • Automation Mesh: Execution Nodes und Hop Nodes für verteilte Umgebungen (DMZ, Multi-Standort, Air-Gapped). Mesh-Topologie planen: Controller -> Hop Node (DMZ) -> Execution Node (Produktionsnetz).
  • Backup und Restore: AAP-Backup (Datenbank, Konfiguration, Credentials) und Restore-Prozedur. Disaster-Recovery-Plan.
  • Upgrade-Strategie: AAP-Versioning (2.4 -> 2.5), Upgrade-Pfad, Rolling Upgrade für HA-Cluster, Execution Environment-Kompatibilität prüfen.
  • Monitoring: AAP-eigene Metriken (Job-Durchsatz, Queue-Länge, Node-Status), Integration mit externem Monitoring (Prometheus-Exporter), Log-Weiterleitung an SIEM.
  • Praxis-Übung: Backup der AAP-Instanz erstellen, Controller-Metriken inspizieren, Automation Mesh-Topologie skizzieren (für ein Szenario mit Hauptstandort + DMZ + Remote-Standort).
Praxis-Workshop (60 Min):
  • Phase 1 - Enterprise-Szenario implementieren (35 Min): Vollständiges Szenario aufbauen: 2 Organisationen (Entwicklung, Produktion), je 2 Teams, RBAC konfiguriert, 3 Projekte aus Git, dynamisches Inventory (oder statisch mit Gruppen), Vault-verschlüsselte Credentials, 4 Job Templates, 1 Workflow mit Approval Node und Fehler-Branch, 1 Execution Environment, 1 EDA-Rulebook. End-to-End: Workflow ausführen -> Approval erteilen -> Jobs laufen -> Notifications empfangen -> Audit-Log prüfen.
  • Phase 2 - Peer-Review (15 Min): AAP-Konfiguration vorstellen. Stresstest: „Ein Entwickler braucht Zugriff auf das Produktions-Inventory - wie verhinderst du das?" „Das Execution Environment ist 2 GB groß - wie optimierst du es?" „Der EDA Controller reagiert auf einen False-Positive-Alert - wie verhinderst du ungewollte Automatisierung?"

  • Ansible-Anwender und -Teams: Die von der Kommandozeile auf eine zentrale Plattform umsteigen - mit Weboberfläche, Zugriffskontrolle, Audit-Trail und Scheduling.
  • Platform Engineers und IT-Operations: Die AAP als zentrale Automatisierungsplattform für das gesamte Unternehmen aufbauen und betreiben.
  • RHCE-zertifizierte Administratoren: Die nach EX294 den nächsten Schritt gehen und Enterprise-Ansible beherrschen.
  • IT-Entscheider und Teamleiter: Die AAP als strategische Automatisierungsplattform evaluieren und einführen.
Voraussetzungen: Solide Ansible-Kenntnisse (Inventory, Playbooks, Rollen, Vault). Idealerweise Besuch von „Ansible - Automatisierung" (S2545, 3T) oder „RHCE-Vorbereitung EX294" (geplant, 5T). Linux-Administrationskenntnisse (RHEL). Keine AAP-Vorkenntnisse nötig.
Abgrenzung: Dieses Seminar behandelt die Ansible Automation Platform als Enterprise-Produkt - nicht Ansible-Grundlagen (dafür: S2545, 3T), nicht Ansible für Entwickler (dafür: S2550, 3T), nicht Event-Driven Ansible im Detail (dafür: S6503, 2T - EDA wird hier als AAP-Komponente eingeführt),


In Präsenz
Online
Lernmethode

Ausgewogene Mischung aus Theorie und Praxis

Wie auch bei unseren Präsenz-Seminaren: Ausgewogene Mischung aus Theorie und praktischen Übungen. Trainer durchgehend präsent.

Unterlagen

Seminarunterlagen oder Fachbuch inklusive. Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Seminarunterlagen oder Fachbuch inklusive (via DHL). Das Fachbuch wählt der Trainer passend zum Seminar aus - Ihren individuellen Buch-Wunsch berücksichtigen wir auf Nachfrage gerne.

Arbeitsplatz
  • PC/VMs für alle Teilnehmenden
  • Hochwertige und performante Hardware
  • Große, höhenverstellbare Bildschirme
  • Zugang zu Ihrem Firmennetz erlaubt
  • 86-90 Zoll Bildschirm für perfekte Präsentationen in jedem Schulungsraum
  • Online Meeting + Remote Zugriff auf persönlichen GFU-Schulungs-PC
  • Keine Installation auf dem eigenem PC notwendig
Lernumgebung

Neu aufgesetzte Remote-Systeme für jeden Kurs in Abstimmung mit dem Seminarleiter, sodass Sie über ein perfektes Setup für die Durchführung aller praktischen Übungen verfügen.

Arbeitsmaterialien

Din A4 Block, Notizblock, Kugelschreiber, USB-Stick, Textmarker, Post-its

Teilnahmezertifikat

Nach Abschluss des Seminars erhalten Sie das Teilnahmezertifikat inkl. Inhaltsverzeichnis per E-Mail als PDF.


In Präsenz
Online
Teilnehmendenzahl

min. 1, max. 8 Personen

Garantierte Durchführung *

Ab 1 Teilnehmenden

Schulungszeiten
3 Tage, 09:00 - 16:00 Uhr
Ort der Schulung
GFU Schulungszentrum oder Virtual Classroom
GFU Schulungszentrum
Am Grauen Stein 27
51105 Köln-Deutz

oder online im Virtual Classroom oder europaweit bei Ihnen als Inhouse-Schulung

Um ein optimales Raumklima zu gewährleisten, haben wir das Schulungszentrum mit 17 hochmodernen Trotec TAC V+ Luftreinigern ausgestattet. Diese innovative Filtertechnologie (H14 zertifiziert nach DIN EN1822) sorgt dafür, dass die Raumluft mehrfach pro Stunde umgewälzt wird und Schadstoffe zu 99.995% im HEPA-Filter abgeschieden und infektiöse Aerosole abgetötet werden.

Zusätzlich sind alle Räume mit CO2-Ampeln ausgestattet, um jederzeit eine hervorragende Luftqualität sicherzustellen.

Räumlichkeiten

Helle und modern ausgestattete Räume mit perfekter Infrastruktur

Bequem aus dem Homeoffice von überall

All-Inclusive

Frühstück, Snacks und Getränke ganztägig, Mittagessen im eigenen Restaurant, täglich 6 Menüs, auch vegetarisch

Eine Auswahl unserer Frühstücks-Snacks und Nervennahrungs-Highlights senden wir Ihnen mit den Seminarunterlagen via DHL zu.
Barrierefreiheit

Das GFU-Schulungszentrum (Am Grauen Stein 27) ist barrierefrei

-

In Präsenz
Online
  • Eigener Shuttle-Service
  • Reservierte Parkplätze
  • Hotelreservierung
  • Technik-Sofort-Support

Buchungsmöglichkeiten

Online oder in Präsenz teilnehmen

Sie können sowohl Online als auch in Präsenz am Seminar teilnehmen. Klicken Sie bei Ihrer Buchung oder Anfrage einfach die entsprechende Option an.

Mehr Infos
Inhouse-/Firmenschulung
  • Lernumgebung in der Cloud
  • Inhalte werden auf Wunsch an die Anforderungen Ihres Teams angepasst.
Präsenz Online Hybrid
Unverbindlich anfragen

So haben GFU-Kunden gestimmt

Zu diesem Seminar wurden noch keine Bewertungen abgegeben.

FAQ für Inhouse Schulungen

Bei einer offenen Schulung stehen Ort und Termin vorab fest. Jeder Interessent kann eine offene Schulung buchen, daher treffen Teilnehmer aus verschiedenen Unternehmen aufeinander.

Inhouse Schulungen können auf Ihren individuellen Schulungsbedarf zugeschnitten werden. Sie bestimmen den Teilnehmerkreis, Termin und Schulungsort.

Bei einer Inhouse Schulung gehen wir auf die individuellen Bedürfnisse Ihres Unternehmens ein und decken den Schulungsbedarf direkt bei Ihnen im Unternehmen ab.

Das spart Zeit und Geld und sorgt für einen schnellen Wissenstransfer Ihrer Mitarbeiter.

Eine komplette Lernumgebung in der Cloud mit Remote Zugriff ist für uns selbstverständlich. Sie müssen sich um nichts kümmern. Lediglich ein funktionierender PC oder Notebook mit Internetanschluss sollte für jeden Teilnehmer am Schulungstag bereit stehen.

  • Kompetente Seminarberatung
  • Dozenten aus der Praxis
  • Auf Ihre Bedürfnisse zugeschnittener individueller Lernstoff
  • Sie können den Termin flexibel gestalten, so wie es für Sie am besten passt
  • Unsere Inhouse Schulungen können Europaweit durchgeführt werden
  • Der Fokus liegt auf Ihrem Schulungsbedarf, somit schonen Sie Ihr Budget
  • Wissenslücken Ihrer Mitarbeitet werden schnell geschlossen

Verwandte Seminare

aegallianzaxaElement 1deutsche-bankdeutsche-postlufthansamercedessonyzdf
160.051
Teilnehmende
4.709
Seminarthemen
39.033
Durchgeführte Seminare