Ansible - Kurzanleitung

Ansible ist eine einfache Open-Source-IT-Engine, die die Anwendungsbereitstellung, die Intra-Service-Orchestrierung, die Cloud-Bereitstellung und viele andere IT-Tools automatisiert.

Ansible ist einfach bereitzustellen, da keine Agenten oder benutzerdefinierte Sicherheitsinfrastruktur verwendet werden.

Ansible verwendet Playbook, um Automatisierungsjobs zu beschreiben, und Playbook verwendet eine sehr einfache Sprache, d. H. YAML(Es ist eine für Menschen lesbare Datenserialisierungssprache und wird häufig für Konfigurationsdateien verwendet, kann jedoch in vielen Anwendungen verwendet werden, in denen Daten gespeichert werden.) Dies ist für Menschen sehr einfach zu verstehen, zu lesen und zu schreiben. Daher besteht der Vorteil darin, dass selbst die Mitarbeiter der IT-Infrastruktur das Playbook lesen und verstehen und bei Bedarf debuggen können (YAML - Es ist in lesbarer Form).

Ansible ist für die Bereitstellung auf mehreren Ebenen konzipiert. Ansible verwaltet nicht jeweils ein System, sondern modelliert die IT-Infrastruktur, indem es beschreibt, dass alle Ihre Systeme miteinander verbunden sind. Ansible ist völlig agentenlos, was bedeutet, dass Ansible Ihre Knoten über ssh verbindet (standardmäßig). Wenn Sie jedoch eine andere Verbindungsmethode wie Kerberos wünschen, bietet Ihnen Ansible diese Option.

Nach dem Herstellen einer Verbindung zu Ihren Knoten überträgt Ansible kleine Programme, die als "Ansible-Module" bezeichnet werden. Ansible führt diese Module auf Ihren Knoten aus und entfernt sie, wenn Sie fertig sind. Ansible verwaltet Ihr Inventar in einfachen Textdateien (dies sind die Hosts-Dateien). Ansible verwendet die Hosts-Datei, in der die Hosts gruppiert und die Aktionen für eine bestimmte Gruppe in den Playbooks gesteuert werden können.

Beispiel-Hosts-Datei

Dies ist der Inhalt der Hosts-Datei -

#File name: hosts
#Description: Inventory file for your application. Defines machine type abc
node to deploy specific artifacts
# Defines machine type def node to upload
metadata.

[abc-node]
#server1 ansible_host = <target machine for DU deployment> ansible_user = <Ansible
user> ansible_connection = ssh
server1 ansible_host = <your host name> ansible_user = <your unix user>
ansible_connection = ssh

[def-node]
#server2 ansible_host = <target machine for artifact upload>
ansible_user = <Ansible user> ansible_connection = ssh
server2 ansible_host = <host> ansible_user = <user> ansible_connection = ssh

Was ist Konfigurationsmanagement

Konfigurationsmanagement in Bezug auf Ansible bedeutet, dass die Konfiguration der Produktleistung beibehalten wird, indem Aufzeichnungen geführt und detaillierte Informationen aktualisiert werden, die die Hardware und Software eines Unternehmens beschreiben.

Zu diesen Informationen gehören normalerweise die genauen Versionen und Aktualisierungen, die auf installierte Softwarepakete angewendet wurden, sowie die Speicherorte und Netzwerkadressen von Hardwaregeräten. Zum Beispiel, wenn Sie die neue Version von installieren möchtenWebLogic/WebSphere Server auf allen in Ihrem Unternehmen vorhandenen Computern. Es ist nicht möglich, dass Sie jeden einzelnen Computer manuell aktualisieren.

Sie können WebLogic / WebSphere auf einmal auf allen Ihren Computern installieren, wobei Ansible-Playbooks und Inventar auf einfachste Weise erstellt wurden. Sie müssen lediglich die IP-Adressen Ihrer Knoten im Inventar auflisten und ein Playbook schreiben, um WebLogic / WebSphere zu installieren. Führen Sie das Playbook von Ihrem Steuergerät aus und es wird auf allen Ihren Knoten installiert.

Wie funktioniert Ansible?

Das Bild unten zeigt die Arbeitsweise von Ansible.

Ansible works indem Sie eine Verbindung zu Ihren Knoten herstellen und kleine Programme mit dem Namen "Ansible Module "zu ihnen. Ansibleführt diese Module dann aus (standardmäßig über SSH) und entfernt sie, wenn sie fertig sind. Ihre Modulbibliothek kann sich auf jedem Computer befinden, und es sind keine Server, Daemons oder Datenbanken erforderlich.

Der Verwaltungsknoten im obigen Bild ist der Steuerknoten (Verwaltungsknoten), der die gesamte Ausführung des Playbooks steuert. Dies ist der Knoten, von dem aus Sie die Installation ausführen. Die Inventardatei enthält die Liste der Hosts, auf denen die Ansible-Module ausgeführt werden müssen, und der Verwaltungsknoten stellt eine SSH-Verbindung her, führt die kleinen Module auf dem Host-Computer aus und installiert das Produkt / die Software.

Beauty von Ansible ist, dass es die Module entfernt, sobald diese so effektiv installiert sind, dass es eine Verbindung zum Host-Computer herstellt, die Anweisungen ausführt und bei erfolgreicher Installation den Code entfernt, der auf den ausgeführten Host-Computer kopiert wurde.

In diesem Kapitel erfahren Sie mehr über die Einrichtung der Umgebung von Ansible.

Installationsprozess

Hauptsächlich gibt es zwei Arten von Maschinen, wenn wir über die Bereitstellung sprechen:

Control machine - Maschine, von der aus wir andere Maschinen verwalten können.
Remote machine - Maschinen, die von der Steuermaschine gehandhabt / gesteuert werden.

Es können mehrere Remote-Maschinen vorhanden sein, die von einer Steuerungsmaschine verwaltet werden. Für die Verwaltung von Remotecomputern müssen wir Ansible auf dem Steuercomputer installieren.

Anforderungen an die Steuermaschine

Ansible kann von jedem Computer ausgeführt werden, auf dem Python 2 (Versionen 2.6 oder 2.7) oder Python 3 (Versionen 3.5 und höher) installiert ist.

Note - Windows unterstützt keine Steuerungsmaschine.

Standardmäßig verwendet Ansible ssh Remote-Computer zu verwalten.

Ansible fügt keine Datenbank hinzu. Es sind keine Dämonen erforderlich, um es zu starten oder am Laufen zu halten. Während der Verwaltung von Remotecomputern wird Ansibledoes notLassen Sie alle Software installiert oder ausgeführt. Daher steht außer Frage, wie ein Upgrade beim Wechsel auf eine neue Version durchgeführt werden soll.

Ansible kann auf verschiedene Weise auf Steuergeräten installiert werden, für die die oben genannten Anforderungen gelten. Sie können die neueste Version über Apt, yum, pkg, pip, OpenCSW, pacman usw. installieren.

Installation über Apt auf Ubuntu Machine

Für die Installation von Ansible müssen Sie PPA auf Ihrem Computer konfigurieren. Dazu müssen Sie die folgende Codezeile ausführen:

$ sudo apt-get update $ sudo apt-get install software-properties-common 
$ sudo apt-add-repository ppa:ansible/ansible $ sudo apt-get update 
$ sudo apt-get install ansible

Nachdem Sie die obige Codezeile ausgeführt haben, können Sie Remotecomputer über Ansible verwalten. Führen Sie einfach Ansible - version aus, um die Version zu überprüfen und um zu überprüfen, ob Ansible ordnungsgemäß installiert wurde oder nicht.

Ansible verwendet die YAML-Syntax zum Ausdrücken von Ansible-Playbooks. Dieses Kapitel bietet einen Überblick über YAML. Ansible verwendet YAML, weil es für Menschen im Vergleich zu anderen Datenformaten wie XML und JSON sehr einfach ist, zu verstehen, zu lesen und zu schreiben.

Jeder YAML Die Datei beginnt optional mit "---" und endet mit "...".

YAML verstehen

In diesem Abschnitt lernen wir die verschiedenen Arten der Darstellung der YAML-Daten kennen.

Schlüssel-Wert-Paar

YAML verwendet ein einfaches Schlüssel-Wert-Paar, um die Daten darzustellen. Das Wörterbuch wird im Schlüssel: Wert-Paar dargestellt.

Note - Zwischen: und Wert sollte ein Leerzeichen stehen.

Beispiel: Ein Schülerdatensatz

--- #Optional YAML start syntax 
james: 
   name: james john 
   rollNo: 34 
   div: B 
   sex: male 
… #Optional YAML end syntax

Abkürzung

Sie können auch Abkürzungen verwenden, um Wörterbücher darzustellen.

Beispiel

James: {name: james john, rollNo: 34, div: B, sex: male}

Repräsentierende Liste

Wir können List auch in YAML darstellen. Jedes Element (Mitglied) der Liste sollte in eine neue Zeile mit demselben Einzug geschrieben werden, beginnend mit „-“ (- und Leerzeichen).

Beispiel

---
countries:  
   - America 
   - China 
   - Canada 
   - Iceland 
…

Abkürzung

Sie können auch Abkürzungen verwenden, um Listen darzustellen.

Beispiel

Countries: [‘America’, ‘China’, ‘Canada’, ‘Iceland’]

Liste in Wörterbüchern

Wir können die Liste in Wörterbüchern verwenden, dh der Wert des Schlüssels ist die Liste.

Beispiel

---  
james: 
   name: james john 
   rollNo: 34 
   div: B 
   sex: male 
   likes: 
      - maths 
      - physics 
      - english 
…

Liste der Wörterbücher

Wir können auch eine Liste von Wörterbüchern erstellen.

Beispiel

---  
- james: 
   name: james john 
   rollNo: 34 
      div: B 
   sex: male 
   likes: 
      - maths 
      - physics 
      - english 

- robert: 
      name: robert richardson 
      rollNo: 53 
      div: B 
      sex: male 
   likes: 
      - biology 
      - chemistry 
…

YAML verwendet "|" Um Zeilenumbrüche einzuschließen, während mehrere Zeilen angezeigt werden, und ">", um Zeilenumbrüche zu unterdrücken, während mehrere Zeilen angezeigt werden. Dadurch können wir große Zeilen lesen und bearbeiten. In beiden Fällen wird die Absicht ignoriert.

Wir können auch vertreten Boolean(Richtig / Falsch) Werte in YAML. woboolean Bei Werten kann die Groß- und Kleinschreibung nicht berücksichtigt werden.

Beispiel

---  
- james: 
   name: james john 
   rollNo: 34 
   div: B 
   sex: male 
   likes: 
      - maths 
      - physics 
      - english 
   
   result: 
      maths: 87 
      chemistry: 45 
      biology: 56 
      physics: 70 
      english: 80 
   
   passed: TRUE 
   
   messageIncludeNewLines: | 
      Congratulation!! 
      You passed with 79% 
   
   messageExcludeNewLines: > 
      Congratulation!! 
      You passed with 79%

Einige gebräuchliche Wörter im Zusammenhang mit Ansible.

Service/Server - Ein Prozess auf dem Computer, der den Dienst bereitstellt.

Machine - Ein physischer Server, eine VM (virtuelle Maschine) oder ein Container.

Target machine - Eine Maschine, die wir mit Ansible konfigurieren werden.

Task - Eine von Ansible verwaltete Aktion (dies ausführen, löschen) usw.

Playbook - Die yml-Datei, in die Ansible-Befehle geschrieben und yml auf einem Computer ausgeführt wird.

Ad-hoc-Befehle sind Befehle, die einzeln ausgeführt werden können, um schnelle Funktionen auszuführen. Diese Befehle müssen nicht später ausgeführt werden.

Beispielsweise müssen Sie alle Server Ihres Unternehmens neu starten. Dazu führen Sie die Adhoc-Befehle von '/usr/bin/ansible'.

Diese Ad-hoc-Befehle werden nicht für die Konfigurationsverwaltung und -bereitstellung verwendet, da diese Befehle nur einmal verwendet werden.

ansible-playbook wird für das Konfigurationsmanagement und die Bereitstellung verwendet.

Parallelität und Shell-Befehle

Starten Sie Ihren Unternehmensserver in 12 parallelen Gabeln gleichzeitig neu. Dazu müssen wir SSHagent für die Verbindung einrichten.

$ ssh-agent bash 
$ ssh-add ~/.ssh/id_rsa

So führen Sie einen Neustart für alle Unternehmensserver in einer Gruppe "abc" in 12 parallelen Gabeln durch:

$ Ansible abc -a "/sbin/reboot" -f 12

Standardmäßig führt Ansible die oben genannten Ad-hoc-Befehle aus dem aktuellen Benutzerkonto aus. Wenn Sie dieses Verhalten ändern möchten, müssen Sie den Benutzernamen in Ad-hoc-Befehlen wie folgt übergeben:

$ Ansible abc -a "/sbin/reboot" -f 12 -u username

Datei Übertragung

Sie können dazu die Ad-hoc-Befehle verwenden SCP (Secure Copy Protocol) Viele Dateien parallel auf mehreren Computern.

Übertragen von Dateien auf viele Server / Computer

$ Ansible abc -m copy -a "src = /etc/yum.conf dest = /tmp/yum.conf"

Neues Verzeichnis erstellen

$ Ansible abc -m file -a "dest = /path/user1/new mode = 777 owner = user1 group = user1 state = directory"

Löschen des gesamten Verzeichnisses und der Dateien

$ Ansible abc -m file -a "dest = /path/user1/new state = absent"

Pakete verwalten

Die Ad-hoc-Befehle sind für yum und apt verfügbar. Im Folgenden finden Sie einige Ad-hoc-Befehle, die yum verwenden.

Der folgende Befehl prüft, ob yum package installiert ist oder nicht, aktualisiert es jedoch nicht.

$ Ansible abc -m yum -a "name = demo-tomcat-1 state = present"

Der folgende Befehl überprüft, ob das Paket nicht installiert ist.

$ Ansible abc -m yum -a "name = demo-tomcat-1 state = absent"

Der folgende Befehl überprüft, ob die neueste Version des Pakets installiert ist.

$ Ansible abc -m yum -a "name = demo-tomcat-1 state = latest"

Fakten sammeln

Fakten können zum Implementieren von bedingten Anweisungen in Playbooks verwendet werden. Sie können Ad-hoc-Informationen zu all Ihren Fakten über den folgenden Ad-hoc-Befehl finden:

$ Ansible all -m setup

In diesem Kapitel erfahren Sie mehr über Playbooks in Ansible.

Playbooks sind die Dateien, in die Ansible-Code geschrieben wird. Playbooks sind im YAML-Format geschrieben. YAML steht für Yet Another Markup Language.Playbookssind eine der Hauptfunktionen von Ansible und teilen Ansible mit, was ausgeführt werden soll. Sie sind wie eine Aufgabenliste für Ansible, die eine Liste von Aufgaben enthält.

Playbooks enthalten die Schritte, die der Benutzer auf einem bestimmten Computer ausführen möchte. Playbooks werden nacheinander ausgeführt. Playbooks sind die Bausteine für alle Anwendungsfälle von Ansible.

Playbook-Struktur

Jedes Spielbuch ist eine Zusammenfassung von einem oder mehreren Spielen. Playbooks sind mit Plays strukturiert. Es kann mehr als ein Spiel in einem Spielbuch geben.

Die Funktion eines Spiels besteht darin, eine Reihe von Anweisungen zuzuordnen, die für einen bestimmten Host definiert sind.

YAML ist eine streng typisierte Sprache. Daher muss beim Schreiben der YAML-Dateien besondere Sorgfalt angewendet werden. Es gibt verschiedene YAML-Editoren, aber wir bevorzugen einen einfachen Editor wie Notepad ++. Öffnen Sie einfach Notepad ++ und kopieren Sie das folgende Yaml und fügen Sie es ein. Ändern Sie die Sprache in YAML (Sprache → YAML).

Eine YAML beginnt mit --- (3 Bindestriche)

Erstellen Sie ein Playbook

Beginnen wir mit dem Schreiben einer Beispiel-YAML-Datei. Wir werden jeden Abschnitt durchgehen, der in einer Yaml-Datei geschrieben ist.

--- 
   name: install and configure DB
   hosts: testServer
   become: yes

   vars: 
      oracle_db_port_value : 1521
   
   tasks:
   -name: Install the Oracle DB
      yum: <code to install the DB>
    
   -name: Ensure the installed service is enabled and running
   service:
      name: <your service name>

Das obige Beispiel ist ein Playbook, in dem wir versuchen, die grundlegende Syntax eines Playbooks zu behandeln. Speichern Sie den obigen Inhalt in einer Datei alstest.yml. Eine YAML-Syntax muss dem richtigen Einzug folgen und beim Schreiben der Syntax muss man ein wenig vorsichtig sein.

Die verschiedenen YAML-Tags

Lassen Sie uns nun die verschiedenen YAML-Tags durchgehen. Die verschiedenen Tags werden unten beschrieben -

Name

Dieses Tag gibt den Namen des Ansible-Playbooks an. Wie in diesem Spielbuch. Dem Spielbuch kann ein beliebiger logischer Name gegeben werden.

Gastgeber

Dieses Tag gibt die Listen der Hosts oder Hostgruppen an, für die die Aufgabe ausgeführt werden soll. Das Feld / Tag des Hosts ist obligatorisch. Es teilt Ansible mit, auf welchen Hosts die aufgelisteten Aufgaben ausgeführt werden sollen. Die Aufgaben können auf demselben Computer oder auf einem Remotecomputer ausgeführt werden. Man kann die Aufgaben auf mehreren Computern ausführen und daher kann das Host-Tag auch eine Gruppe von Host-Einträgen haben.

vars

Mit dem Vars-Tag können Sie die Variablen definieren, die Sie in Ihrem Playbook verwenden können. Die Verwendung ähnelt Variablen in jeder Programmiersprache.

Aufgaben

Alle Playbooks sollten Aufgaben oder eine Liste der auszuführenden Aufgaben enthalten. Aufgaben sind eine Liste von Aktionen, die ausgeführt werden müssen. Ein Aufgabenfeld enthält den Namen der Aufgabe. Dies dient als Hilfetext für den Benutzer. Es ist nicht obligatorisch, erweist sich jedoch als nützlich beim Debuggen des Playbooks. Jede Aufgabe ist intern mit einem Code verknüpft, der als Modul bezeichnet wird. Ein Modul, das ausgeführt werden soll, und Argumente, die für das Modul erforderlich sind, das Sie ausführen möchten.

Rollen bieten ein Framework für vollständig unabhängige oder voneinander abhängige Sammlungen von Variablen, Aufgaben, Dateien, Vorlagen und Modulen.

In Ansible ist die Rolle der Hauptmechanismus zum Aufteilen eines Playbooks in mehrere Dateien. Dies vereinfacht das Schreibencomplex playbooksund es macht sie einfacher wiederzuverwenden. Durch das Aufbrechen des Playbooks können Sie das Playbook logisch in wiederverwendbare Komponenten aufteilen.

Jede Rolle ist grundsätzlich auf eine bestimmte Funktionalität oder gewünschte Ausgabe beschränkt, wobei alle erforderlichen Schritte erforderlich sind, um dieses Ergebnis entweder innerhalb dieser Rolle selbst oder in anderen als Abhängigkeiten aufgeführten Rollen bereitzustellen.

Rollen sind keine Spielbücher. Rollen sind kleine Funktionen, die unabhängig voneinander verwendet werden können, aber in Playbooks verwendet werden müssen. Es gibt keine Möglichkeit, eine Rolle direkt auszuführen. Rollen haben keine explizite Einstellung für welchen Host die Rolle gelten soll.

Playbooks der obersten Ebene sind die Brücke zwischen den Hosts aus Ihrer Inventardatei und den Rollen, die auf diese Hosts angewendet werden sollen.

Eine neue Rolle erstellen

Die Verzeichnisstruktur für Rollen ist wichtig, um eine neue Rolle zu erstellen.

Rollenstruktur

Rollen haben ein strukturiertes Layout im Dateisystem. Die Standardstruktur kann geändert werden, aber lassen Sie uns zunächst die Standardeinstellungen beibehalten.

Jede Rolle ist ein Verzeichnisbaum für sich. Der Rollenname ist der Verzeichnisname im Verzeichnis / role.

$ ansible-galaxy -h

Verwendung

ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup] [--help] [options] ...

Optionen

-h, --help - Diese Hilfemeldung anzeigen und beenden.
-v, --verbose - Ausführlicher Modus (-vvv für mehr, -vvvv für das Debuggen von Verbindungen)
--version - Versionsnummer des Programms anzeigen und beenden.

Erstellen eines Rollenverzeichnisses

Der obige Befehl hat die Rollenverzeichnisse erstellt.

$ ansible-galaxy init vivekrole 
ERROR! The API server (https://galaxy.ansible.com/api/) is not responding, please try again later. 

$ ansible-galaxy init --force --offline vivekrole - vivekrole was created successfully $ tree vivekrole/ 
vivekrole/ 
├── defaults 
│   └── main.yml 
├── files ├── handlers 
│   └── main.yml 
├── meta 
│   └── main.yml 
├── README.md ├── tasks 
│   └── main.yml 
├── templates ├── tests │   ├── inventory 
│   └── test.yml 
└── vars 
    └── main.yml 
 
8 directories, 8 files

Im Beispiel werden nicht alle Verzeichnisse verwendet, und wir werden im Beispiel die Verwendung einiger Verzeichnisse zeigen.

Verwenden von Rollen im Playbook

Dies ist der Code des Playbooks, das wir für Demozwecke geschrieben haben. Dieser Code stammt aus dem Playbook vivek_orchestrate.yml. Wir haben die Hosts definiert:tomcat-node und nannte die beiden Rollen - install-tomcat und start-tomcat.

Die Problemstellung ist, dass wir einen Krieg haben, den wir über Ansible auf einem Computer bereitstellen müssen.

--- 
- hosts: tomcat-node 
roles: 
   - {role: install-tomcat} 
   - {role: start-tomcat}

Inhalt unserer Verzeichnisstruktur, von der aus wir das Playbook ausführen.

$ ls 
ansible.cfg  hosts  roles  vivek_orchestrate.retry vivek_orchestrate.yml

Unter jedem Verzeichnis befindet sich ein Aufgabenverzeichnis, das eine main.yml enthält. Die main.yml-Inhalte von install-tomcat sind -

--- 
#Install vivek artifacts 
-  
   block: 
      - name: Install Tomcat artifacts
         action: > 
            yum name = "demo-tomcat-1" state = present 
         register: Output 
          
   always: 
      - debug: 
         msg: 
            - "Install Tomcat artifacts task ended with message: {{Output}}" 
            - "Installed Tomcat artifacts - {{Output.changed}}"

Der Inhalt von main.yml des Start-Kater ist -

#Start Tomcat          
-  
   block: 
      - name: Start Tomcat 
      command: <path of tomcat>/bin/startup.sh" 
      register: output 
      become: true 
   
   always: 
      - debug: 
         msg: 
            - "Start Tomcat task ended with message: {{output}}" 
            - "Tomcat started - {{output.changed}}"

Der Vorteil der Aufteilung des Playbooks in Rollen besteht darin, dass jeder, der die Funktion "Tomcat installieren" verwenden möchte, die Rolle "Tomcat installieren" aufrufen kann.

Ein Spielbuch in eine Rolle zerlegen

Wenn nicht für die Rollen, kann der Inhalt der main.yml der jeweiligen Rolle in das Playbook kopiert werden ymlDatei. Um Modularität zu erreichen, wurden Rollen erstellt.

Jede logische Entität, die als wiederverwendbare Funktion wiederverwendet werden kann, kann in eine Rolle verschoben werden. Das Beispiel hierfür ist oben dargestellt

Führen Sie den Befehl aus, um das Playbook auszuführen.

-vvv option for verbose output – verbose output 
$ cd vivek-playbook/

Dies ist der Befehl zum Ausführen des Playbooks

$ sudo ansible-playbook -i hosts vivek_orchestrate.yml –vvv 
-----------------------------------------------------------------
-----------------------------------------------------------------------

Ausgabe

Die generierte Ausgabe wird wie auf dem Bildschirm angezeigt -

Verwenden von /users/demo/vivek-playbook/ansible.cfg als Konfigurationsdatei.

PLAYBOOK: vivek_orchestrate.yml *********************************************************
*********************************************************** 
1 plays in vivek_orchestrate.yml 

PLAY [tomcat-node] **********************************************************************
******** ************************************************* 
 
TASK [Gathering Facts] *************************************************
****************************** ********************************************* 
Tuesday 21 November 2017  13:02:05 +0530 (0:00:00.056) 0:00:00.056 ****** 
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/system/setup.py 
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root 
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0' 
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
   /root/.ansible/tmp/ansible-tmp-1511249525.88-259535494116870 `" && 
   echo ansible-tmp-1511249525.88-259535494116870="` 
   echo /root/.ansible/tmp/ansibletmp-1511249525.88-259535494116870 `" ) && sleep 0' 
<localhost> PUT /tmp/tmpPEPrkd TO 
   /root/.ansible/tmp/ansible-tmp-1511249525.88259535494116870/setup.py 
<localhost> EXEC /bin/sh -c 'chmod u+x 
   /root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/ 
   /root/.ansible/tmp/ansible-tmp-1511249525.88259535494116870/setup.py && sleep 0' 
<localhost> EXEC /bin/sh -c '/usr/bin/python 
   /root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/setup.py; rm -rf 
   "/root/.ansible/tmp/ansible-tmp1511249525.88-259535494116870/" > /dev/null 2>&1 && sleep 0' 
ok: [server1] 
META: ran handlers 
 
TASK [install-tomcat : Install Tomcat artifacts] ***********************************
*************************************************************** 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:5 
Tuesday 21 November 2017  13:02:07 +0530 (0:00:01.515)       0:00:01.572 ****** 
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/packaging/os/yum.py 
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root 
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0' 
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
   /root/.ansible/tmp/ansible-tmp-1511249527.34-40247177825302 `" && echo 
   ansibletmp-1511249527.34-40247177825302="` echo 
   /root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302 `" ) && sleep 0' 
<localhost> PUT /tmp/tmpu83chg TO 
   /root/.ansible/tmp/ansible-tmp-1511249527.3440247177825302/yum.py 
<localhost> EXEC /bin/sh -c 'chmod u+x 
   /root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/ 
   /root/.ansible/tmp/ansible-tmp-1511249527.3440247177825302/yum.py && sleep 0' 
<localhost> EXEC /bin/sh -c '/usr/bin/python 
   /root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/yum.py; rm -rf 
   "/root/.ansible/tmp/ansible-tmp1511249527.34-40247177825302/" > /dev/null 2>
   &1 && sleep 0' 
changed: [server1] => { 
   "changed": true, 
   "invocation": { 
      "module_args": { 
         "conf_file": null, 
         "disable_gpg_check": false, 
         "disablerepo": null, 
         "enablerepo": null, 
         "exclude": null, 
         "install_repoquery": true, 
         "installroot": "/", 
         "list": null, 
         "name": ["demo-tomcat-1"], 
         "skip_broken": false, 
         "state": "present", 
         "update_cache": false, 
         "validate_certs": true 
      } 
   }, 
   "msg": "", 
   "rc": 0, 
   "results": [ 
      "Loaded plugins: product-id, 
      search-disabled-repos, 
      subscriptionmanager\nThis system is not registered to Red Hat Subscription Management. 
      You can use subscription-manager to register.\nResolving Dependencies\n--> 
      Running transaction check\n---> 
      Package demo-tomcat-1.noarch 0:SNAPSHOT-1 will be installed\n--> Finished Dependency 
      Resolution\n\nDependencies Resolved\n
      \n================================================================================\n 
      Package Arch Version Repository         
      Size\n==================================================================\nInstalling:\n 
      demo-tomcat-1 noarch SNAPSHOT-1 demo-repo1 7.1 M\n\nTransaction 
      Summary\n==================================================================\nInstall  1 
      Package\n\nTotal download size: 7.1 M\nInstalled size: 7.9 M\nDownloading 
         packages:\nRunning transaction 
      check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : 
      demotomcat-1-SNAPSHOT-1.noarch 1/1 \n  Verifying  : 
      demo-tomcat-1-SNAPSHOT-1.noarch 1/1 \n\nInstalled:\n  
      demo-tomcat-1.noarch 0:SNAPSHOT-1 \n\nComplete!\n" 
   ] 
} 
 
TASK [install-tomcat : debug] **********************************************************
*************************************************************************** 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:11 
Tuesday 21 November 2017  13:02:13 +0530 (0:00:06.757) 0:00:08.329 ****** 
ok: [server1] => { 
   "changed": false, 
   "msg": [ 
      "Install Tomcat artifacts task ended with message: {
         u'msg': u'', u'changed': True, u'results': 
         [u'Loaded plugins: product-id, 
         search-disabledrepos, 
         subscription-manager\\nThis system is not registered to Red Hat Subscription Management. 
         You can use subscription-manager to register.\\nResolving Dependencies\\n--> 
         Running transaction check\\n---> 
         Package demo-tomcat-1.noarch 0:SNAPSHOT-1 will be installed\\n--> 
         Finished Dependency Resolution\\n
         \\nDependencies 
         Resolved\\n\\n==================================================================\\n 
         Package Arch Version Repository         
         Size\\n======================================================================== 
         =====\\nInstalling:\\n demo-tomcat-1 noarch SNAPSHOT-1 demo-repo1 7.1 M\\n\\nTransaction 
         Summary\\n=========================================================\\nInstall  1 
         Package\\n\\nTotal download size: 7.1 M\\nInstalled size: 7.9 M\\nDownloading 
            packages:\\nRunning 
         transaction check\\nRunning transaction test\\nTransaction test succeeded\\nRunning 
            transaction\\n  
         Installing : demo-tomcat-1-SNAPSHOT-1.noarch 1/1 \\n  Verifying  : 
         demo-tomcat-1-SNAPSHOT-1.noarch
         1/1 \\n\\nInstalled:\\n  demo-tomcat-1.noarch 0:SNAPSHOT-1  \\n\\nComplete!\\n'], u'rc': 0
      }", 
      "Installed Tomcat artifacts - True" 
   ] 
} 
 
TASK [install-tomcat : Clean DEMO environment] ****************************************
************************************************************ 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:19 
Tuesday 21 November 2017  13:02:13 +0530 (0:00:00.057) 0:00:08.387 ****** 
[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or 
   {% %}. Found: {{installationOutput.changed}} 
 
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/files/file.py 
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root 
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0' 
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
   /root/.ansible/tmp/ansible-tmp-1511249534.13-128345805983963 `" && echo 
   ansible-tmp-1511249534.13-128345805983963="` echo 
   /root/.ansible/tmp/ansibletmp-1511249534.13-128345805983963 `" ) && sleep 0' 
<localhost> PUT /tmp/tmp0aXel7 TO 
   /root/.ansible/tmp/ansible-tmp-1511249534.13128345805983963/file.py 
<localhost> EXEC /bin/sh -c 'chmod u+x 
   /root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/ 
   /root/.ansible/tmp/ansible-tmp-1511249534.13128345805983963/file.py && sleep 0' 
<localhost> EXEC /bin/sh -c '/usr/bin/python 
   /root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/file.py; rm -rf 
   "/root/.ansible/tmp/ansible-tmp1511249534.13-128345805983963/" > /dev/null 2>&1 
   && sleep 0' 
changed: [server1] => { 
   "changed": true, 
      "diff": { 
         "after": { 
            "path": "/users/demo/DEMO", 
            "state": "absent" 
      }, 
      "before": { 
         "path": "/users/demo/DEMO", 
         "state": "directory" 
      } 
   },

   "invocation": { 
      "module_args": { 
         "attributes": null, 
         "backup": null, 
         "content": null, 
         "delimiter": null, 
         "diff_peek": null, 
         "directory_mode": null, 
         "follow": false, 
         "force": false, 
         "group": null, 
         "mode": null, 
         "original_basename": null, 
         "owner": null, 
         "path": "/users/demo/DEMO", 
         "recurse": false, 
         "regexp": null, 
         "remote_src": null, 
         "selevel": null, 
         "serole": null, 
         "setype": null, 
         "seuser": null, 
         "src": null, 
         "state": "absent", 
         "unsafe_writes": null, 
         "validate": null 
      } 
   }, 
   "path": "/users/demo/DEMO", 
   "state": "absent" 
} 
 
TASK [install-tomcat : debug] ********************************************************
************************************************************* 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:29 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.257)       0:00:08.645 ****** 
ok: [server1] => {
   "changed": false, 
   "msg": [ 
      "Clean DEMO environment task ended with message:{u'diff': {u'after': {u'path': 
         u'/users/demo/DEMO', u'state': u'absent'}, 
      u'before': {u'path': u'/users/demo/DEMO', u'state': u'directory'}}, u'state': u'absent', 
         u'changed': True, u'path': u'/users/demo/DEMO'}", 
      "check value  :True" 
   ] 
} 
 
TASK [install-tomcat : Copy Tomcat to user home] *************************************
******************************************************** 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:37 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.055)       0:00:08.701 ****** 
[WARNING]: when statements should not include jinja2 templating delimiters such as {{ }} or 
   {% %}. Found: {{installationOutput.changed}} 
 
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/commands/command.py 
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root 
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0' 
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
   /root/.ansible/tmp/ansible-tmp-1511249534.43-41077200718443 `" && echo 
   ansibletmp-1511249534.43-41077200718443="` echo 
   /root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443 `" ) && sleep 0' 
<localhost> PUT /tmp/tmp25deWs TO 
   /root/.ansible/tmp/ansible-tmp-1511249534.4341077200718443/command.py 
<localhost> EXEC /bin/sh -c 'chmod u+x 
   /root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443/ 
   /root/.ansible/tmp/ansible-tmp-1511249534.4341077200718443/command.py && sleep 0' 
<localhost> EXEC /bin/sh -c '/usr/bin/python 
   /root/.ansible/tmp/ansible-tmp1511249534.43-41077200718443/command.py; rm -rf 
   "/root/.ansible/tmp/ansibletmp-1511249534.43-41077200718443/" > /dev/null 2>&1 
   && sleep 0' 
changed: [server1] => { 
   "changed": true, 
   "cmd": [ 
      "cp", 
      "-r", 
      "/opt/ansible/tomcat/demo", 
      "/users/demo/DEMO/" 
   ],
   "delta": "0:00:00.017923", 
   "end": "2017-11-21 13:02:14.547633", 
   "invocation": { 
      "module_args": { 
         "_raw_params": "cp -r /opt/ansible/tomcat/demo /users/demo/DEMO/", 
         "_uses_shell": false, 
         "chdir": null, 
         "creates": null, 
         "executable": null, 
         "removes": null, 
         "warn": true 
      } 
   }, 
   "rc": 0, 
   "start": "2017-11-21 13:02:14.529710", 
   "stderr": "", 
   "stderr_lines": [], 
   "stdout": "", 
   "stdout_lines": [] 
} 
 
TASK [install-tomcat : debug] ********************************************************
********************************************************** 
task path: /users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:47 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.260)       0:00:08.961 ****** 
ok: [server1] => { 
   "changed": false, 
   "msg": "Copy Tomcat to user home task ended with message {
      'stderr_lines': [], u'changed': True, u'end': u'2017-11-21 13:02:14.547633', u'stdout': 
      u'', u'cmd': [u'cp', u'-r', u'/opt/ansible/tomcat/demo', u'/users/demo/DEMO/'], u'rc': 0, 
      u'start': u'2017-11-21 13:02:14.529710', u'stderr': u'', u'delta': u'0:00:00.017923', 
      'stdout_lines': []}" 
} 
 
TASK [start-tomcat : Start Tomcat] **************************************************
********************************************************** 
task path: /users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:5 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.044)       0:00:09.006 ****** 
Using module file /usr/lib/python2.7/sitepackages/ansible/modules/commands/command.py 
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root 
<localhost> EXEC /bin/sh -c 'echo ~ && sleep 0' 
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
   /root/.ansible/tmp/ansible-tmp-1511249534.63-46501211251197 `" && echo 
   ansibletmp-1511249534.63-46501211251197="` echo 
   /root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197 `" ) && sleep 0' 
<localhost> PUT /tmp/tmp9f06MQ TO 
   /root/.ansible/tmp/ansible-tmp-1511249534.6346501211251197/command.py 
<localhost> EXEC /bin/sh -c 'chmod u+x 
   /root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197/ 
   /root/.ansible/tmp/ansible-tmp-1511249534.6346501211251197/command.py && sleep 0' 
<localhost> EXEC /bin/sh -c '/usr/bin/python 
   /root/.ansible/tmp/ansible-tmp1511249534.63-46501211251197/command.py; rm -rf 
   "/root/.ansible/tmp/ansibletmp-1511249534.63-46501211251197/" > /dev/null 2>&1 
   && sleep 0' 
changed: [server1] => { 
   "changed": true, 
   "cmd": [ "/users/demo/DEMO/bin/startup.sh" ], 
   "delta": "0:00:00.020024", 
   "end": "2017-11-21 13:02:14.741649", 
   "invocation": { 
      "module_args": { 
         "_raw_params": "/users/demo/DEMO/bin/startup.sh", 
         "_uses_shell": false, 
         "chdir": null, 
         "creates": null, 
         "executable": null, 
         "removes": null, 
         "warn": true 
      } 
   }, 
   "rc": 0, 
   "start": "2017-11-21 13:02:14.721625", 
   "stderr": "", 
   "stderr_lines": [], 
   "stdout": "Tomcat started.", 
   "stdout_lines": [ "Tomcat started." ] 
} 
 
TASK [start-tomcat : debug] *************************************************
********************************************************************** 
task path: /users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:10 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.150)       0:00:09.156 ****** 
ok: [server1] => { 
   "changed": false, 
   "msg": [ 
      "Start Tomcat task ended with message: {'
         stderr_lines': [], u'changed': True, u'end': u'2017-11-21 13:02:14.741649', u'stdout': 
         u'Tomcat started.', u'cmd': [u'/users/demo/DEMO/bin/startup.sh'], u'rc': 0, u'start': 
         u'2017-11-21 13:02:14.721625', u'stderr': u'', u'delta': u'0:00:00.020024', 
         'stdout_lines': [u'Tomcat started.']}", 
      "Tomcat started - True" 
   ] 
} 
META: ran handlers 
META: ran handlers 
 
PLAY RECAP ******************************************************************************* 
********************************************************* 
server1  : ok = 9    changed = 4    unreachable = 0    failed = 0 
 
Tuesday 21 November 2017  13:02:14 +0530 (0:00:00.042)       0:00:09.198 ****** 
=============================================================================== 
install-tomcat : Install Tomcat artifacts ------------------------------- 6.76s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:5 -------------- 
Gathering Facts --------------------------------------------------------- 1.52s 
 ------------------------------------------------------------------------------ 
install-tomcat : Copy Tomcat to user home ------------------------------- 0.26s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:37 ------------- 

install-tomcat : Clean DEMO environment --------------------------------- 0.26s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:19 ------------- 

start-tomcat : Start Tomcat --------------------------------------------- 0.15s 
/users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:5 ----------------

install-tomcat : debug -------------------------------------------------- 0.06s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:11 ------------- 

install-tomcat : debug -------------------------------------------------- 0.06s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:29 ------------- 

install-tomcat : debug -------------------------------------------------- 0.04s 
/users/demo/vivek-playbook/roles/install-tomcat/tasks/main.yml:47 ------------- 

start-tomcat : debug ---------------------------------------------------- 0.04s 
/users/demo/vivek-playbook/roles/start-tomcat/tasks/main.yml:10 ---------------

Klicken Sie auf die folgende URL und Sie werden zu einer Seite weitergeleitet, wie unten gezeigt - http://10.76.0.134:11677/HelloWorld/HelloWorld

Der eingesetzte Krieg hat nur ein Servlet, das "Hallo Welt" anzeigt. Die detaillierte Ausgabe zeigt die Zeit, die jede Aufgabe aufgrund des in der Datei ansible.cfg hinzugefügten Eintrags benötigt.

[defaults] 
callback_whitelist = profile_tasks

Variabel in Spielbüchern sind very similarzur Verwendung von Variablen in einer beliebigen Programmiersprache. Es hilft Ihnen, einen Wert zu verwenden und einer Variablen zuzuweisen und diesen an einer beliebigen Stelle im Playbook zu verwenden. Man kann Bedingungen um den Wert der Variablen setzen und sie dementsprechend im Playbook verwenden.

Beispiel

- hosts : <your hosts> 
vars:
tomcat_port : 8080

Im obigen Beispiel haben wir einen Variablennamen definiert tomcat_port und hat dieser Variablen den Wert 8080 zugewiesen und kann diesen in Ihrem Playbook verwenden, wo immer dies erforderlich ist.

Nehmen Sie nun eine Referenz aus dem geteilten Beispiel. Der folgende Code stammt aus einer der Rollen (install-tomcat) -

block: 
   - name: Install Tomcat artifacts 
      action: > 
      yum name = "demo-tomcat-1" state = present 
      register: Output 
          
   always: 
      - debug: 
         msg: 
            - "Install Tomcat artifacts task ended with message: {{Output}}" 
            - "Installed Tomcat artifacts - {{Output.changed}}"

Hier ist die Ausgabe die verwendete Variable.

Lassen Sie uns alle im obigen Code verwendeten Schlüsselwörter durchgehen -

block - Ansible Syntax zum Ausführen eines bestimmten Blocks.
name - Relevanter Name des Blocks - Dies wird bei der Protokollierung verwendet und hilft beim Debuggen dessen, was alle Blöcke erfolgreich ausgeführt wurden.
action- Der Code neben dem Aktionstag ist die auszuführende Aufgabe. Die Aktion ist wieder ein Ansible-Schlüsselwort, das in yaml verwendet wird.
register - Die Ausgabe der Aktion wird mit dem Schlüsselwort register registriert und Output ist der Variablenname, der die Aktionsausgabe enthält.
always - Wieder ein Ansible-Schlüsselwort, das besagt, dass unten immer ausgeführt wird.
msg - Zeigt die Nachricht an.

Verwendung der Variablen - {{Output}} ->

Dies liest den Wert der Variablen Output. Auch wenn es auf der Registerkarte msg verwendet wird, wird der Wert der Ausgabevariablen gedruckt.

Darüber hinaus können Sie auch die Untereigenschaften der Variablen verwenden. Wie im Fall, {{Output.changed}} zu überprüfen, ob die Ausgabe geändert wurde, und sie entsprechend zu verwenden.

Ausnahmebehandlung in Playbooks

Die Ausnahmebehandlung in Ansible ähnelt der Ausnahmebehandlung in jeder Programmiersprache. Ein Beispiel für die Ausnahmebehandlung im Playbook ist unten dargestellt.

tasks: 
   - name: Name of the task to be executed 
      block: 
         - debug: msg = 'Just a debug message , relevant for logging' 
         - command: <the command to execute> 
      
      rescue: 
         - debug: msg = 'There was an exception.. ' 
         - command: <Rescue mechanism for the above exception occurred) 
      
      always: 
         - debug: msg = "this will execute in all scenarios. Always will get logged"

Es folgt die Syntax für die Ausnahmebehandlung.

rescue und always sind die Schlüsselwörter für die Ausnahmebehandlung.
In Block wird der Code geschrieben (alles, was auf dem Unix-Computer ausgeführt werden soll).
Wenn der in die Blockfunktion geschriebene Befehl fehlschlägt, erreicht die Ausführung den Rettungsblock und wird ausgeführt. Falls der Befehl unter Blockfunktion keinen Fehler enthält, wird die Rettung nicht ausgeführt.
Always wird in allen Fällen ausgeführt.
Wenn wir also dasselbe mit Java vergleichen, ist es ähnlich, zu versuchen, zu fangen und schließlich zu blockieren.
Hier, Block ist ähnlich wie try block wo Sie den auszuführenden Code schreiben und rescue ist ähnlich wie catch block und always ist ähnlich wie finally.

Schleifen

Das folgende Beispiel zeigt die Verwendung von Loops in Ansible.

Die Aufgabe besteht darin, den Satz aller Kriegsdateien aus einem Verzeichnis in den Ordner "tomcat webapps" zu kopieren.

Die meisten der im folgenden Beispiel verwendeten Befehle wurden bereits zuvor behandelt. Hier konzentrieren wir uns auf die Verwendung von Schleifen.

Anfangs haben wir im Befehl 'shell' ls * .war ausgeführt. Es werden also alle Kriegsdateien im Verzeichnis aufgelistet.

Die Ausgabe dieses Befehls erfolgt in einer Variablen namens output.

Zum Schleifen wird die Syntax 'with_items' verwendet.

with_items: "{{output.stdout_lines}}" -> output.stdout_lines gibt uns die zeilenweise Ausgabe und dann durchlaufen wir die Ausgabe mit dem Befehl with_items von Ansible.

Fügen Sie die Beispielausgabe hinzu, um zu verstehen, wie wir die stdout_lines im Befehl with_items verwendet haben.

--- 
#Tsting 
- hosts: tomcat-node 
   tasks: 
      - name: Install Apache 
      shell: "ls *.war" 
      register: output 
      args: 
         chdir: /opt/ansible/tomcat/demo/webapps 
      
      - file: 
         src: '/opt/ansible/tomcat/demo/webapps/{{ item }}' 
         dest: '/users/demo/vivek/{{ item }}' 
         state: link 
      with_items: "{{output.stdout_lines}}"

Blöcke

Das gesamte Spielbuch ist in Blöcke unterteilt. Die kleinsten auszuführenden Schritte werden in Block geschrieben. Das Schreiben der spezifischen Anweisung in Blöcke hilft dabei, die Funktionalität zu trennen und sie bei Bedarf mit Ausnahmebehandlung zu behandeln.

Ein Beispiel für Blöcke wird in der Variablenverwendung, der Ausnahmebehandlung und den obigen Schleifen behandelt.

Bedingungen

Bedingungen werden verwendet, wenn ein bestimmter Schritt basierend auf einer Bedingung ausgeführt werden muss.

--- 
#Tsting 
- hosts: all 
   vars: 
      test1: "Hello Vivek" 
   tasks: 
      - name: Testing Ansible variable 
      debug: 
         msg: "Equals" 
         when: test1 == "Hello Vivek"

In diesem Fall wird Equals gedruckt, da die Variable test1 gleich ist, wie in der when-Bedingung angegeben. when kann wie in allen Programmiersprachen mit einem logischen ODER und einer logischen UND-Bedingung verwendet werden.

Ändern Sie einfach den Wert der Variablen test1 von Hello Vivek in Hello World und sehen Sie die Ausgabe.

In diesem Kapitel erfahren Sie, was die erweiterte Ausführung mit Ansible ist.

So beschränken Sie die Ausführung nach Aufgaben

Dies ist eine sehr wichtige Ausführungsstrategie, bei der nur eine Ausführung und nicht das gesamte Spielbuch ausgeführt werden muss. For exampleAngenommen, Sie möchten nur einen Server stoppen (falls ein Produktionsproblem auftritt) und anschließend einen Patch anwenden, mit dem Sie nur den Server starten möchten.

Hier im ursprünglichen Playbook waren Stop und Start Teil verschiedener Rollen im selben Playbook, dies kann jedoch mit der Verwendung von Tags behandelt werden. Wir können verschiedene Tags für verschiedene Rollen bereitstellen (die wiederum Aufgaben haben) und daher basierend auf den vom Executor bereitgestellten Tags nur die angegebene Rolle / Aufgabe ausgeführt werden. Für das obige Beispiel können wir also Tags wie das folgende hinzufügen:

- {role: start-tomcat, tags: ['install']}}

Der folgende Befehl hilft bei der Verwendung von Tags -

ansible-playbook -i hosts <your yaml> --tags "install" -vvv

Mit dem obigen Befehl wird nur die Start-Tomcat-Rolle aufgerufen. Das bereitgestellte Tag unterscheidet zwischen Groß- und Kleinschreibung. Stellen Sie sicher, dass die genaue Übereinstimmung an den Befehl übergeben wird.

So beschränken Sie die Ausführung durch Hosts

Es gibt zwei Möglichkeiten, um bestimmte Schritte auf bestimmten Hosts auszuführen. Für eine bestimmte Rolle definiert man die Hosts - für welche spezifischen Hosts diese bestimmte Rolle ausgeführt werden soll.

Beispiel

- hosts: <A> 
   environment: "{{your env}}" 
   pre_tasks: 
      - debug: msg = "Started deployment. 
      Current time is {{ansible_date_time.date}} {{ansible_date_time.time}} " 
     
   roles: 
      - {role: <your role>, tags: ['<respective tag>']} 
   post_tasks: 
      - debug: msg = "Completed deployment. 
      Current time is {{ansible_date_time.date}} {{ansible_date_time.time}}" 
 
- hosts: <B> 
   pre_tasks: 
      - debug: msg = "started.... 
      Current time is {{ansible_date_time.date}} {{ansible_date_time.time}} " 
        
   roles: 
      - {role: <your role>, tags: ['<respective tag>']} 
   post_tasks: 
      - debug: msg = "Completed the task.. 
      Current time is {{ansible_date_time.date}} {{ansible_date_time.time}}"

Gemäß dem obigen Beispiel werden abhängig von den bereitgestellten Hosts nur die jeweiligen Rollen aufgerufen. Jetzt sind meine Hosts A und B in den Hosts (Inventardatei) definiert.

Alternative Lösung

Eine andere Lösung könnte darin bestehen, die Hosts des Playbooks mithilfe einer Variablen zu definieren und dann eine bestimmte Hostadresse über zu übergeben --extra-vars - -

# file: user.yml  (playbook) 
--- 
- hosts: '{{ target }}' 
   user: ... 
playbook contd….

Ausführen des Playbooks

ansible-playbook user.yml --extra-vars "target = "<your host variable>"

Wenn {{target}} nicht definiert ist, führt das Playbook nichts aus. Bei Bedarf kann auch eine Gruppe aus der Hosts-Datei übergeben werden. Dies schadet nicht, wenn die zusätzlichen Vars nicht bereitgestellt werden.

Playbook für einen einzelnen Host

$ ansible-playbook user.yml --extra-vars "target = <your hosts variable>" --listhosts

Die gängigsten Strategien zum Debuggen von Ansible-Playbooks sind die folgenden Module:

Debuggen und Registrieren

Diese beiden Module sind in Ansible verfügbar. Zum Debuggen müssen wir die beiden Module mit Bedacht einsetzen. Beispiele sind unten gezeigt.

Verwenden Sie Ausführlichkeit

Mit dem Befehl Ansible kann die Ausführlichkeitsstufe angegeben werden. Sie können die Befehle mit der Ausführlichkeitsstufe eins (-v) oder zwei (-vv) ausführen.

Wichtige Punkte

In diesem Abschnitt werden wir einige Beispiele durchgehen, um einige Konzepte zu verstehen.

Wenn Sie kein Argument zitieren, das mit einer Variablen beginnt. Zum Beispiel,

vars: 
   age_path: {{vivek.name}}/demo/ 
   
{{vivek.name}}

Dies wird einen Fehler auslösen.

Lösung

vars: 
   age_path: "{{vivek.name}}/demo/" – marked in yellow is the fix. 
 
How to use register -> Copy this code into a yml file say test.yml and run it  
--- 
#Tsting 
- hosts: tomcat-node 
   tasks: 
 
   - shell: /usr/bin/uptime 
      register: myvar 
      - name: Just debugging usage 
         debug: var = myvar

Wenn ich diesen Code über den Befehl Ansible-playbook -i hosts test.yml ausführe, erhalte ich die Ausgabe wie unten gezeigt.

Wenn Sie das yaml sehen, haben wir die Ausgabe eines Befehls in einer Variablen registriert - myvar und druckte nur die Ausgabe.

Der gelb markierte Text gibt Auskunft über die Eigenschaft der Variablen myvar, die zur weiteren Flusskontrolle verwendet werden kann. Auf diese Weise können wir herausfinden, welche Eigenschaften einer bestimmten Variablen zur Verfügung stehen. Der folgende Debug-Befehl hilft dabei.

$ ansible-playbook -i hosts test.yml 

PLAY [tomcat-node] ***************************************************************
**************** ****************************************************************
*************** ****************************** 
 
TASK [Gathering Facts] *****************************************************************
************** *****************************************************************
************** ************************** 
Monday 05 February 2018  17:33:14 +0530 (0:00:00.051) 0:00:00.051 ******* 
ok: [server1] 
 
TASK [command] ******************************************************************
************* ******************************************************************
************* ********************************** 
Monday 05 February 2018  17:33:16 +0530 (0:00:01.697) 0:00:01.748 ******* 
changed: [server1] 
 
TASK [Just debugging usage] ******************************************************************
************* ******************************************************************
************* ********************* 
Monday 05 February 2018  17:33:16 +0530 (0:00:00.226) 0:00:01.974 ******* 
ok: [server1] => { 
   "myvar": { 
      "changed": true, 
      "cmd": "/usr/bin/uptime", 
      "delta": "0:00:00.011306", 
      "end": "2018-02-05 17:33:16.424647", 
      "rc": 0, 
      "start": "2018-02-05 17:33:16.413341", 
      "stderr": "", 
      "stderr_lines": [], 
      "stdout": " 17:33:16 up 7 days, 35 min,  1 user,  load average: 0.18, 0.15, 0.14", 
      "stdout_lines": [ 
         " 17:33:16 up 7 days, 35 min,  1 user,  load average: 0.18, 0.15, 0.14" 
      ] 
   } 
} 
 
PLAY RECAP ****************************************************************************
**********************************************************************************
 ************************************** 
server1 : ok = 3    changed = 1    unreachable = 0    failed = 0

Häufige Probleme mit dem Playbook

In diesem Abschnitt lernen wir einige häufig auftretende Probleme mit dem Spielbuch kennen. Die Probleme sind -

Quoting
Indentation

Das Playbook ist im Yaml-Format geschrieben und die beiden oben genannten sind die häufigsten Probleme im Yaml / Playbook.

Yaml unterstützt keine tabulatorbasierten Einrückungen und raumbasierte Einrückungen, daher muss man vorsichtig sein.

Note - Wenn Sie mit dem Schreiben des Yaml fertig sind, öffnen Sie diese Seite (https://editor.swagger.io/) und kopieren Sie Ihr Yaml auf der linken Seite, um sicherzustellen, dass das Yaml ordnungsgemäß kompiliert wird. Dies ist nur ein Tipp.

Swagger qualifiziert sowohl Fehler in der Warnung als auch Fehler.