Ansible-tutorial voor beginners: draaiboek, opdrachten en voorbeeld

Wat is Ansible?

Ansible is een open source automatiserings- en orkestratietool voor softwarevoorziening, configuratiebeheer en software-implementatie. Ansible kan eenvoudig Unix-achtige systemen uitvoeren en configureren Windows systemen om infrastructuur als code te leveren. Het bevat zijn eigen declaratieve programmeertaal voor systeemconfiguratie en -beheer.

Ansible is populair vanwege de eenvoud van installatie, gebruiksgemak wat betreft de connectiviteit met clients, het ontbreken van een agent voor Ansible-clients en de veelheid aan vaardigheden. Het werkt door verbinding te maken via SSH naar de clients, zodat er geen speciale agent aan de clientzijde nodig is, en door modules naar de clients te pushen, worden de modules vervolgens lokaal aan de clientzijde uitgevoerd en wordt de uitvoer teruggestuurd naar de Ansible-server.

Omdat het SSH gebruikt, kan het heel eenvoudig verbinding maken met clients met behulp van SSH-Keys, wat het hele proces vereenvoudigt. Clientgegevens, zoals hostnamen of IP-adressen en SSH-poorten, worden opgeslagen in bestanden die inventarisbestanden worden genoemd. Zodra u een inventarisbestand hebt gemaakt en gevuld, kan Ansible het gebruiken.

Waarom Ansible gebruiken?

Hier zijn enkele belangrijke voor- en voordelen van het gebruik van Ansible

  • Een van de belangrijkste voordelen van Ansible is dat het door iedereen gratis te gebruiken is.
  • Er zijn geen speciale systeembeheerdervaardigheden nodig om Ansible te installeren en te gebruiken, en de officiële documentatie is zeer uitgebreid.
  • De modulariteit met betrekking tot plug-ins, modules, inventarissen en playbooks maakt Ansible de perfecte metgezel voor het orkestreren van grote omgevingen.
  • Ansible is zeer licht en consistent, en kent geen beperkingen met betrekking tot het besturingssysteem of de onderliggende hardware.
  • Het is ook zeer veilig vanwege de agentless-mogelijkheden en vanwege het gebruik van OpenSSH-beveiligingsfuncties.
  • Een ander voordeel dat de adoptie van Ansible aanmoedigt, is de soepele leercurve die wordt bepaald door de uitgebreide documentatie en de eenvoudig te leren structuur en configuratie.

Geschiedenis van Ansible

Hier zijn belangrijke herkenningspunten uit de geschiedenis van de weerwort:

  • In februari 2012 ging het Ansible-project van start. Het werd voor het eerst ontwikkeld door Michael DeHaan, de maker van Cobbler en Func, Fedora Unified Network Controller.
  • Het bedrijf dat de Ansible-tool financierde, heette aanvankelijk AnsibleWorks Inc. en werd in 2015 overgenomen door RedHat. Later werd het, samen met RedHat, ondergebracht onder de paraplu van IBM.
  • Tegenwoordig wordt Ansible opgenomen in distributies zoals Fedora Linux, RHEL, Centos en Oracle Linux.

Belangrijke termen die worden gebruikt in Ansible

  • Ansible-server

    De machine waarop Ansible is geïnstalleerd en waarop alle taken en draaiboeken worden uitgevoerd

  • Module

    Kortom, een module is een opdracht of een reeks vergelijkbare Ansible-opdrachten die bedoeld zijn om aan de clientzijde te worden uitgevoerd

  • Taak

    Een taak is een sectie die bestaat uit één enkele procedure die moet worden voltooid

  • Rol

    Een manier om taken en gerelateerde bestanden te organiseren, zodat ze later in een playbook kunnen worden aangeroepen

  • Feit

    Informatie opgehaald uit het clientsysteem van de globale variabelen met de verzamel-feitenbewerking

  • Inventaris

    Bestand met gegevens over de ansible-clientservers. In latere voorbeelden gedefinieerd als hosts-bestand

  • Spelen

    Uitvoering van een draaiboek

  • Handler

    Taak die alleen wordt aangeroepen als er een melder aanwezig is

  • Notifier

    Sectie toegeschreven aan een taak die een handler aanroept als de uitvoer wordt gewijzigd

  • Tag

    Naam die aan een taak is toegewezen en die later kan worden gebruikt om alleen die specifieke taak of groep taken uit te voeren.

Ansible-installatie onder Linux

Nadat u uw opties heeft vergeleken en afgewogen en hebt besloten voor Ansible te gaan, is de volgende stap het op uw systeem installeren. We zullen de installatiestappen in verschillende stappen doorlopen Linux distributies, de meest populaire, in de volgende kleine tutorial.

Installeer Ansible op Centos/RedHat-systemen

Stap 1) Installeer EPEL-repository

[root@ansible-server ~]# sudo yum install epel-release

Stap 2) Installeer het Anible-pakket

[root@ansible-server ~]# sudo  yum install -y ansible

Installeer Ansible op Centos/RedHat-systemen

Anible op installeren Ubuntu/Debian-systemen

Stap 1) Voer een update uit voor de pakketten

$ sudo apt update

Stap 2) Installeer het software-properties-common-pakket

$ sudo apt install software-properties-common

Stap 3) Installeer het anible persoonlijke pakketarchief

$ sudo apt-add-repository ppa:ansible/ansible

Stap 4) Anible installeren

$ sudo apt update
$ sudo apt install ansible

Ansible ad-hoc-opdrachten

Een van de eenvoudigste manieren waarop Ansible kan worden gebruikt, is door ad-hocopdrachten te gebruiken. Deze kunnen worden gebruikt als u opdrachten wilt geven op een server of een aantal servers. Ad-hocopdrachten worden niet opgeslagen voor toekomstig gebruik, maar vormen een snelle manier om met de gewenste servers te communiceren.

Voor deze Ansible-tutorial wordt een eenvoudig hosts-bestand voor twee servers geconfigureerd, met daarin host1 en host2.

U kunt ervoor zorgen dat de hosts toegankelijk zijn vanaf de ansible-server door een ping-opdracht op alle hosts te geven.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping
host1 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Ansible ad-hoc-opdrachten

Uitleg:

  1. Status van de opdracht, in dit geval SUCCES
  2. Host waarop de opdracht werd uitgevoerd
  3. Het commando dat wordt uitgegeven via de parameter -m, in dit geval ping
  4. Met de parameter -i kunt u naar het hosts-bestand verwijzen.


U kunt dezelfde opdracht indien nodig alleen op een specifieke host geven.

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2
host2 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

Ansible ad-hoc-opdrachten

Uitleg:

  1. De parameter Limit kan worden gebruikt om alleen opdrachten uit te voeren op specifieke hosts in het hostbestand
  2. Naam van de host zoals gedefinieerd in het inventarisbestand

Als u een bestand snel naar meerdere bestemmingen moet kopiëren, kunt u de kopieermodule in ansible gebruiken die SCP gebruikt. Het commando en de uitvoer zien er dus als volgt uit:

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"
host1 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.43-256741011164877/source",
    "state": "file",
    "uid": 0
}
host2 | SUCCESS => {
    "changed": true,
    "checksum": "da39a3ee5e6b4b0d3255bfef95601890afd80709",
    "dest": "/tmp/testfile",
    "gid": 0,
    "group": "root",
    "md5sum": "d41d8cd98f00b204e9800998ecf8427e",
    "mode": "0644",
    "owner": "root",
    "size": 0,
    "src": "/root/.ansible/tmp/ansible-tmp-1562216392.6-280302911361278/source",
    "state": "file",
    "uid": 0
}

Ansible ad-hoc-opdrachten

Uitleg:

  1. Kopieermodule gedefinieerd
  2. Moduleargumenten zijn in dit geval het absolute bronpad en het absolute bestemmingspad.
  3. Ansible-opdrachtuitvoer die het succes van de kopieeropdracht en andere details zoals de sha1- of md5-checksums voor bestandsintegriteitscontrole en metagegevens zoals eigenaar, grootte of machtigingen weergeeft. Het is moeiteloos om een ​​pakket op een aantal servers te installeren. Ansible heeft verschillende modules die communiceren met gebruikte installatieprogramma's, zoals yum, apt, dnf, etc.

In het volgende voorbeeld ontdek je hoe je een pakket via de yum-module op twee Centos-hosts installeert.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [


"Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.xservers.ro\n * epel: fedora.mirrors.telekom.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: remi.schlundtech.de\n * remi-safe: remi.schlundtech.de\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nLoading mirror speeds from cached hostfile\n * base: mirror.netsite.dk\n * elrepo: mirrors.leadhosts.com\n * epel: mirrors.nav.ro\n * extras: centos.mirrors.telekom.ro\n * remi-php70: mirrors.uni-ruse.bg\n * remi-safe: mirrors.uni-ruse.bg\n * updates: centos.mirror.iphh.net\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version                Repository       Size\n================================================================================\nInstalling:\n ncdu            x86_64            1.14-1.el7             epel             51 k\n\nTransaction Summary\n================================================================================\nInstall  1 Package\n\nTotal download size: 51 k\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Installing : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nInstalled:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Ansible ad-hoc-opdrachten

Uitleg:

  1. In dit voorbeeld wordt de Yum-module gebruikt
  2. Het definieert de moduleargumenten, en in dit geval kiest u de naam van het pakket en de status ervan. Als de status bijvoorbeeld ontbreekt, wordt het pakket doorzocht en indien gevonden, verwijderd
  3. Indien geel gekleurd, ziet u de uitvoer van het ansible-commando met een gewijzigde status, wat in dit geval betekent dat het pakket is gevonden en geïnstalleerd.
  4. Status van de yum install-opdracht uitgegeven via ansible. In dit geval werd het pakket ncdu.x86_64 0:1.14-1.el7 geïnstalleerd.

Natuurlijk kunnen alle yum-installatieprogramma-opties worden gebruikt via ansible, inclusief updaten, installeren, nieuwste versie of verwijderen.

In het onderstaande voorbeeld werd dezelfde opdracht gegeven om het eerder geïnstalleerde ncdu-pakket te verwijderen.

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'
host1 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}
host2 | SUCCESS => {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: fastestmirror\nResolving Dependencies\n--> Running transaction check\n---> Package ncdu.x86_64 0:1.14-1.el7 will be erased\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\n================================================================================\n Package         Arch              Version               Repository        Size\n================================================================================\nRemoving:\n ncdu            x86_64            1.14-1.el7            @epel             87 k\n\nTransaction Summary\n================================================================================\nRemove  1 Package\n\nInstalled size: 87 k\nDownloading packages:\nRunning transaction check\nRunning transaction test\nTransaction test succeeded\nRunning transaction\n  Erasing    : ncdu-1.14-1.el7.x86_64                                       1/1 \n  Verifying  : ncdu-1.14-1.el7.x86_64                                       1/1 \n\nRemoved:\n  ncdu.x86_64 0:1.14-1.el7                                                      \n\nComplete!\n"
    ]
}

Ansible ad-hoc-opdrachten

Uitleg:

  1. De uitvoer van het yum-commando laat zien dat het pakket is verwijderd.

Een andere nuttige en essentiële functie die ansible gebruikt om te communiceren met de server van de client is om wat feiten over het systeem te verzamelen. Het haalt dus hardware-, software- en versie-informatie op van het systeem en slaat elke waarde op in een variabele die later kan worden gebruikt.

Als u gedetailleerde informatie nodig heeft over de systemen die via ansible moeten worden aangepast, kunt u het volgende commando gebruiken. De setup-module verzamelt feiten uit de systeemvariabelen.

Ansible ad-hoc-opdrachten

Ansible-speelboeken

Ansible-speelboeken zijn de manier om commando's naar externe systemen te sturen via scripts. Ansible-playbooks worden gebruikt om complexe systeemomgevingen te configureren om de flexibiliteit te vergroten door een script uit te voeren op een of meer systemen. Ansible-playbooks zijn over het algemeen meer een configuratietaal dan een programmeertaal.

Ansible playbook-opdrachten gebruiken het YAML-formaat, dus er is niet veel syntaxis nodig, maar de inspringing moet worden gerespecteerd. Zoals de naam al zegt, is een draaiboek een verzameling toneelstukken. Via een draaiboek kunt u specifieke rollen toewijzen aan sommige hosts en andere rollen aan andere hosts. Door dit te doen, kunt u meerdere servers in zeer uiteenlopende scenario's orkestreren, allemaal in één draaiboek.

Om alle details nauwkeurig te hebben voordat we verdergaan met Ansible playbook-voorbeelden, moeten we eerst een taak definiëren. Dit zijn de interfaces naar Ansible-modules voor rollen en playbooks.

Laten we nu het Ansible-speelboek leren aan de hand van een voorbeeld met één speelboek met één spel, dat meerdere taken bevat, zoals hieronder:

---

- hosts: group1
  tasks:
  - name: Install lldpad package
    yum:
      name: lldpad
      state: latest
  - name: check lldpad service status
    service:
      name: lldpad
      state: started

Ansible-speelboeken

In het bovenstaande Ansible playbook-voorbeeld is de groep1 hosts in het hostbestand bedoeld voor de installatie van het lldpad-pakket met behulp van de yum-module en daarna wordt de service lldpad die na de installatie is gemaakt, gestart met behulp van de servicemodule die meestal wordt gebruikt om te communiceren met systemd ensemble.

Uitleg:

  1. Groep hosts waarop het draaiboek zal draaien
  2. De Yum-module wordt bij deze taak gebruikt voor de installatie van lldpad
  3. De servicemodule wordt gebruikt om te controleren of de service na installatie actief is

Elk ansible playbook werkt met een inventarisbestand. Het inventarisbestand bevat een lijst met servers die in groepen zijn verdeeld voor betere controle over details zoals IP-adres en SSH-poort voor elke host.

Het inventarisbestand dat u voor dit Ansible-playbook-voorbeeld kunt gebruiken, ziet er als volgt uit. Er zijn twee groepen, genaamd group1 en group2, die elk respectievelijk host1 en host2 bevatten.

[group1]
host1 ansible_host=192.168.100.2 ansible_ssh_port=22
[group2]
host2 ansible_host=192.168.100.3 ansible_ssh_port=22

Ansible-speelboeken

Uitleg:

  1. Groepsnaam
  2. Hostnaam, met IP-adres en ssh-poort, in dit geval de standaardnaam, 22.

Een ander handig voorbeeld van het Ansible-playbook dat deze keer twee plays voor twee hosts bevat, is de volgende. Voor de eerste groep hosts, groep1, zal selinux ingeschakeld zijn. Als dit is ingeschakeld, verschijnt er een bericht op het scherm van de host.

Voor de tweede groep hosts wordt het httpd-pakket alleen geïnstalleerd als de ansible_os_family RedHat is en ansible_system_vendor HP is.

Ansible_os_family en ansible_system_vendor zijn variabelen verzameld met de optie collect_facts en kunnen worden gebruikt zoals in dit voorwaardelijke voorbeeld.

---

- hosts: group1
  tasks:
  - name: Enable SELinux
    selinux:
      state: enabled
    when: ansible_os_family == 'Debian'
    register: enable_selinux

  - debug:
      Imsg: "Selinux Enabled. Please restart the server to apply changes."
    when: enable_selinux.changed == true

- hosts: group2
  tasks:
  - name: Install apache
    yum:
      name: httpd
      state: present
    when: ansible_system_vendor == 'HP' and ansible_os_family == 'RedHat'

Ansible-speelboeken

Uitleg:

  1. Voorbeeld van de wanneer-clausule. In dit geval is het besturingssysteemtype Debian. De anible_os_family variabele wordt verzameld via de functionaliteit collect_facts.
  2. De taakuitvoer wordt geregistreerd voor toekomstig gebruik, met de naam enable_selinux
  3. Nog een voorbeeld van de when-clausule. In dit geval wordt een bericht weergegeven voor de hostgebruiker als SELinux inderdaad eerder is ingeschakeld.
  4. Nog een voorbeeld van de wanneer-clausule die uit twee regels bestaat

Naast taken zijn er ook enkele specifieke taken die handlers worden genoemd. Handlers moeten in het hele draaiboek een unieke naam hebben. Deze werken op dezelfde manier als een reguliere taak, maar een behandelaar kan via een notifier op de hoogte worden gesteld.

Als een handler tijdens de uitvoering van het draaiboek geen melding ontvangt, wordt deze niet uitgevoerd. Als echter meer dan één taak een handler op de hoogte stelt, wordt deze slechts één keer uitgevoerd nadat alle taken zijn voltooid.

In het onderstaande voorbeeld kunt u zien hoe een specifieke taak een meldingssectie heeft die een andere taak oproept. Als de uitvoer van de eerste taak wordt gewijzigd, wordt een handler-taak aangeroepen. Het beste voorbeeld is om een ​​configuratiebestand te laten wijzigen en daarna die specifieke service opnieuw te starten.

---

- hosts: group2
  tasks:
  - name: sshd config file modify port
    lineinfile:
     path: /etc/ssh/sshd_config
     regexp: 'Port 28675'
     line: '#Port 22'
    notify:
       - restart sshd
handlers
    - name: restart sshd
      service: sshd
        name: sshd
        state: restarted

In dit geval, als de eerste taak, “sshd configuratiebestand wijzigen poort” wordt gewijzigd, wat betekent dat als de poort in de eerste plaats niet 28675 is, deze zal worden gewijzigd en de taak de handler met dezelfde naam zal waarschuwen om uit te voeren , en het zal de sshd-service opnieuw starten.

Ansible-speelboeken

Uitleg:

  1. Voorbeeld van een melder
  2. Voorbeeld van een behandelaar

Ansible-rollen

Als je met uitgebreide draaiboeken te maken hebt, is het gemakkelijker om de taken in rollen op te splitsen. Dit helpt ook bij het hergebruik van de rollen in de toekomst. Rollen zijn een verzameling taken die van het ene draaiboek naar het andere kunnen worden verplaatst en onafhankelijk kunnen worden uitgevoerd, maar alleen via een draaiboekbestand.

Rollen worden in afzonderlijke mappen opgeslagen en hebben een bepaalde mapstructuur.

[root@ansible-server test2]# tree
.
`-- role1
    |-- defaults
    |   `-- main.yml
    |-- handlers
    |   `-- main.yml
    |-- meta
    |   `-- main.yml
    |-- README.md
    |-- tasks
    |   `-- main.yml
    |-- tests
    |   |-- inventory
    |   `-- test.yml
    `-- vars
        `-- main.yml

7 directories, 8 files

Het yaml-bestand in de map defaults bevat een lijst met standaardvariabelen die samen met het playbook moeten worden gebruikt. De handlersdirectory wordt gebruikt om handlers op te slaan. De metadirectory zou informatie moeten bevatten over de auteur en rolafhankelijkheden. In de takenmap bevindt zich het hoofd-yaml-bestand voor de rol.

De map tests bevat een voorbeeld van een yaml-playbookbestand en een voorbeeldinventarisbestand en wordt meestal gebruikt voor testdoeleinden voordat de daadwerkelijke rol wordt gemaakt.

De vars-directory bevat het yaml-bestand waarin alle variabelen die door de rol worden gebruikt, worden gedefinieerd. De directorysjablonen en de directorybestanden moeten bestanden en sjablonen bevatten die door de taken in de rol worden gebruikt.

Om de directorystructuur voor een rol te maken, moet u de volgende opdracht gebruiken met de laatste parameter, de rolnaam:

[root@ansible-server test2]# ansible-galaxy init role1

Ansible werkt ook goed met sjablonen. Als taal voor sjablonen gebruikt het Jinja2.

In het volgende voorbeeld ontdekt u hoe een basisjinja2-sjabloon eruit ziet en gebruikt u deze in een rol.

Tijdens de runtime kunt u, afhankelijk van bijvoorbeeld in welk datacenter uw server zich bevindt, kiezen uit meer dan één naamserver, die elk overeenkomt met een datacenter, met behulp van de variabele 'resolver_ip_addresses'.

{% for resolver in resolver_ip_addresses %}
nameserver {{ resolver }}
{% endfor %}

options timeout:1
options attempts:5
options rotate

In dit voorbeeld zijn in de playbook-directory enkele variabelen gedefinieerd, waaronder een variabele met de naam solver_ip_addresses met verschillende waarden, afhankelijk van het datacenter.

- name: Set resolver for server
  template:
    src: dns.j2
    dest: /etc/resolv.conf
    group: root
    owner: root
    mode: "0644"
    tag: resolver	

Ansible-rollen

Uitleg:

  1. Naam van de te gebruiken sjabloon. Sjabloon bevindt zich in de sjabloonmap in het rolpad
  2. Bestemmingspad van de bestandsnaam die moet worden vervangen door de sjabloon, aan de clientzijde.
  3. Machtigingen van het doelbestand

De rollentaken kunnen ook een tagveld hebben waaraan een naam is toegekend. Meer dan één taak kan dezelfde tag delen. Wanneer u een ansible-playbook uitvoert, kunt u ook de tag opgeven, zodat deze taken worden uitgevoerd.

Ansible-casestudy

In deze sectie analyseren we een casestudy van een essentieel weerwible-speelboek dat drie rollen heeft. Het doel hiervan is om een ​​praktisch voorbeeld te geven van waar we het eerder over hadden. Sommige van de voorbeelden die eerder in deze Ansible-playbook-tutorial zijn gebruikt, zullen in dit playbook worden aangepast en gebruikt.

Hieronder vindt u de directorystructuur van het playbook. Het Yaml-bestand dat zal worden gebruikt, is p4.yml.

[root@ansible-server test_ansible]# ls -lrth
total 16K
-rw-r--r--. 1 root root   0 Jul  3 10:13 testfile
-rw-r--r--. 1 root root 203 Jul  3 13:30 p1.yml
-rw-r--r--. 1 root root 125 Jul  3 15:00 hosts
-rw-r--r--. 1 root root 488 Jul  3 16:40 p2.yml
-rw-r--r--. 1 root root 188 Jul  4 17:33 p4.yml
drwxr-xr-x. 5 root root  47 Jul  4 17:35 roles
[root@ansible-server test_ansible]# cd roles
[root@ansible-server roles]# ls -lrth
total 12K
drwxr-xr-x. 9 root root 4.0K Jul  4 12:52 httpd
drwxr-xr-x. 9 root root 4.0K Jul  4 13:55 selinux
drwxr-xr-x. 9 root root 4.0K Jul  4 16:54 resolver

Het playbook heeft drie rollen, één heet 'resolver', die een specifieke naamserver op de servers instelt door een bestand van de server naar de bestemming /etc/resolv.conf te kopiëren. Een andere heet httpd en installeert het httpd-pakket met de yum-module, en de derde schakelt SELinux in en waarschuwt de ingelogde gebruiker om het systeem opnieuw op te starten. Elke rol is gemaakt met de opdracht ansible-galaxy.

Resolverrol, main.yml-taak:

Ansible-casestudy

Httpd-rol, main.yml-taak:

Ansible-casestudy

Selinux-rol, main.yml-taak:

Ansible-casestudy

Hieronder staat het p4.yml playbook gedefinieerd. Het zal op alle hosts draaien, tenzij anders gespecificeerd in de opdrachtregel, het zal draaien als rootgebruiker op poort 22 (SSH), het zal feiten verzamelen voordat de rollen worden uitgevoerd, en het zal alle drie de eerder genoemde rollen uitvoeren. Elke rol kan onafhankelijk worden uitgevoerd door de tag op te geven in de opdrachtregel ansible-playbook met de parameter –t.

---

- hosts: all
  user: root
  port: 22
  gather_facts: True
  roles:
    - { role: selinux, tags: selinux }
    - { role: httpd, tags: httpd }
    - { role: resolver, tags: resolver }

Het p4.yml-playbook uitvoeren op twee hosts en de uitvoer interpreteren. Hetzelfde commando kan worden uitgevoerd met de parameter –check voor een droogloop. Als u wachtwoordverificatie wilt gebruiken, gebruikt u de parameter -k.

Ansible-casestudy

Uitleg:

  1. Ansible-playbook-opdracht die p4.yml uitvoert
  2. Playbook slaat de SELinux-rol over omdat deze al is ingeschakeld.
  3. Ansible ontdekte dat het httpd-pakket al is geïnstalleerd, dus het retourneert ok.
  4. De Resolver is ingesteld en de status van de roloplosser is gewijzigd.

Ansible-opdrachten spiekbriefje

Installeer EPEL-repository op Centos/RHEL-systemen

[root@ansible-server ~]# sudo yum install epel-release

Installeer het ansible-pakket op Centos/RHEL-systemen

[root@ansible-server ~]# sudo  yum install -y ansible

Voer een update uit van de pakketten op Debian/Ubuntu oplossingen

$ sudo apt update

Installeer het pakket software-properties-common op Debian/Ubuntu oplossingen

$ sudo apt install software-properties-common

Installeer ansible persoonlijk pakketarchief op Debian/Ubuntu oplossingen

$ sudo apt-add-repository ppa:ansible/ansible

Ansible installeren op Debian/Ubuntu oplossingen

$ sudo apt update
$ sudo apt install ansible

Geef een ping-opdracht op alle servers die zijn gedefinieerd in het inventarisbestand met de naam hosts

 
[root@ansible-server test_ansible]# ansible -i hosts all -m ping

Geef alleen een ping-opdracht op host2

[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2

Kopieer het bestand “testfile” op alle hosts in het inventarisbestand

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"

Installeer het ncdu-pakket op alle hosts

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'

Verwijder het ncdu-pakket op alle hosts

[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'

Bouw de mapstructuur voor de rol met de naam rol1.

[root@ansible-server test2]# ansible-galaxy init role1

Droog uitgevoerd p4.yml-speelboek

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --check

Voer p4.yml playbook uit met wachtwoordverificatie voor alle hosts

[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -k

Samenvatting

In een wereld waarin technologie voortdurend in rap tempo verandert en tegelijkertijd razendsnel groeit, moeten systeembeheerders en DevOps-engineers nadenken over verschillende benaderingen om routinematige taken te automatiseren en grote groepen servers te beheren.

Hoewel er veel zijn alternatief voor Ansible (Chef, Puppet) die hetzelfde doen met enkele verschillen, slaagde Ansible erin om boven alles uit te stijgen met zijn eenvoud, verbeterde beveiliging en vooral zijn soepele leercurve. Vanwege deze kwaliteiten en de snelle acceptatie van Ansible hebben we een tutorial vol voorbeelden gemaakt, zodat u een nog naadlozere eerste ervaring kunt hebben met het werken met Ansible.

In deze Ansible basics tutorial hebben we Ansible beschreven en een beetje over de geschiedenis ervan gesproken. We noemden de sterke punten van Ansible en de voordelen die Ansible kan bieden voor automatisering en orkestratie van infrastructuren van verschillende groottes. We definieerden de essentiële termen die Ansible gebruikte en definieerden de structuur van Ansible playbooks. Uitgebreide voorbeelden vergezelden alle informatie met gedetailleerde uitleg.

Vat dit bericht samen met: