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
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"
}
Uitleg:
- Status van de opdracht, in dit geval SUCCES
- Host waarop de opdracht werd uitgevoerd
- Het commando dat wordt uitgegeven via de parameter -m, in dit geval ping
- 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"
}
Uitleg:
- De parameter Limit kan worden gebruikt om alleen opdrachten uit te voeren op specifieke hosts in het hostbestand
- 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
}
Uitleg:
- Kopieermodule gedefinieerd
- Moduleargumenten zijn in dit geval het absolute bronpad en het absolute bestemmingspad.
- 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"
]
}
Uitleg:
- In dit voorbeeld wordt de Yum-module gebruikt
- 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
- 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.
- 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"
]
}
Uitleg:
- 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-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
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:
- Groep hosts waarop het draaiboek zal draaien
- De Yum-module wordt bij deze taak gebruikt voor de installatie van lldpad
- 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
Uitleg:
- Groepsnaam
- 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'
Uitleg:
- Voorbeeld van de wanneer-clausule. In dit geval is het besturingssysteemtype Debian. De anible_os_family variabele wordt verzameld via de functionaliteit collect_facts.
- De taakuitvoer wordt geregistreerd voor toekomstig gebruik, met de naam enable_selinux
- Nog een voorbeeld van de when-clausule. In dit geval wordt een bericht weergegeven voor de hostgebruiker als SELinux inderdaad eerder is ingeschakeld.
- 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.
Uitleg:
- Voorbeeld van een melder
- 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
Uitleg:
- Naam van de te gebruiken sjabloon. Sjabloon bevindt zich in de sjabloonmap in het rolpad
- Bestemmingspad van de bestandsnaam die moet worden vervangen door de sjabloon, aan de clientzijde.
- 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:
Httpd-rol, main.yml-taak:
Selinux-rol, main.yml-taak:
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.
Uitleg:
- Ansible-playbook-opdracht die p4.yml uitvoert
- Playbook slaat de SELinux-rol over omdat deze al is ingeschakeld.
- Ansible ontdekte dat het httpd-pakket al is geïnstalleerd, dus het retourneert ok.
- 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.















