Ansible Tutorial for begyndere: Playbook, Commands & Eksempel
Hvad er Ansible?
Ansible er et open source-automatiserings- og orkestreringsværktøj til levering af software, konfigurationsstyring og softwareimplementering. Ansible kan nemt køre og konfigurere Unix-lignende systemer samt Windows systemer til at levere infrastruktur som kode. Den indeholder sit eget deklarative programmeringssprog til systemkonfiguration og -styring.
Ansible er populær på grund af sin enkelhed i installationen, brugervenlighed, hvad angår forbindelsen til klienter, dens mangel på agent for Ansible-klienter og de mange færdigheder. Den fungerer ved at forbinde via SSH til klienterne, så det behøver ikke en speciel agent på klientsiden, og ved at skubbe moduler til klienterne, bliver modulerne så eksekveret lokalt på klientsiden og outputtet skubbes tilbage til Ansible serveren.
Da det bruger SSH, kan det meget nemt oprette forbindelse til klienter ved hjælp af SSH-nøgler, hvilket forenkler hele processen. Klientoplysninger, såsom værtsnavne eller IP-adresser og SSH-porte, gemmes i filer kaldet inventarfiler. Når du har oprettet en inventarfil og udfyldt den, kan ansible bruge den.
Hvorfor bruge Ansible?
Her er nogle vigtige fordele ved at bruge Ansible
- En af de væsentligste fordele ved Ansible er, at det er gratis at bruge af alle.
- Det kræver ingen særlige systemadministratorfærdigheder at installere og bruge Ansible, og den officielle dokumentation er meget omfattende.
- Dens modularitet med hensyn til plugins, moduler, opgørelser og playbooks gør Ansible til den perfekte ledsager til at orkestrere store miljøer.
- Ansible er meget let og konsistent, og der er ingen begrænsninger vedrørende operativsystemet eller underliggende hardware.
- Det er også meget sikkert på grund af dets agentløse muligheder og på grund af brugen af OpenSSH sikkerhedsfunktioner.
- En anden fordel, der tilskynder til brugen af Ansible, er dens glatte indlæringskurve bestemt af den omfattende dokumentation og let at lære struktur og konfiguration.
Ansibles historie
Her er vigtige landemærker fra ansibles historie:
- I februar 2012 begyndte Ansible-projektet. Det blev først udviklet af Michael DeHaan, skaberen af Cobbler and Func, Fedora Unified Network Controller.
- Oprindeligt kaldet AnsibleWorks Inc, virksomheden, der finansierede ansible-værktøjet, blev erhvervet i 2015 af RedHat og senere, sammen med RedHat, flyttet ind under paraplyen af IBM.
- I nutiden er Ansible inkluderet i distributioner som Fedora Linux, RHEL, Centos og Oracle Linux.
Vigtige termer brugt i Ansible
-
Ansible server
Maskinen, hvor Ansible er installeret, og hvorfra alle opgaver og spillebøger vil blive kørt
-
Moduler
Grundlæggende er et modul en kommando eller et sæt af lignende Ansible-kommandoer beregnet til at blive udført på klientsiden
-
Opgaver
En opgave er et afsnit, der består af en enkelt procedure, der skal udføres
-
roller
En måde at organisere opgaver og relaterede filer på, som senere skal kaldes i en spillebog
-
Faktum
Information hentet fra klientsystemet fra de globale variabler med indsamlingsfakta-operationen
-
Inventory
Fil, der indeholder data om de mulige klientservere. Defineret i senere eksempler som værtsfil
-
Leg
Udførelse af en spillebog
-
handler
Opgave som kun kaldes hvis der er en anmelder til stede
-
Underretning
Sektion tilskrevet en opgave, der kalder en behandler, hvis output ændres
-
tag
Navn sat til en opgave, som kan bruges senere til at udstede netop den specifikke opgave eller gruppe af opgaver.
Ansible installation i Linux
Når du har sammenlignet og vejet dine muligheder og besluttet at gå efter Ansible, er næste skridt at få det installeret på dit system. Vi vil gennemgå installationstrinene i forskellige Linux distributioner, de mest populære, i den næste lille tutorial.
Installer Ansible på Centos/RedHat-systemer
Trin 1) Installer EPEL repo
[root@ansible-server ~]# sudo yum install epel-release
Trin 2) Installer en passende pakke
[root@ansible-server ~]# sudo yum install -y ansible
Installer ansible på Ubuntu/Debian-systemer
Trin 1) Udfør en opdatering af pakkerne
$ sudo apt update
Trin 2) Installer pakken software-egenskaber-fælles
$ sudo apt install software-properties-common
Trin 3) Installer et muligt personligt pakkearkiv
$ sudo apt-add-repository ppa:ansible/ansible
Trin 4) Installer ansible
$ sudo apt update $ sudo apt install ansible
Ansible ad-hoc kommandoer
En af de enkleste måder, Ansible kan bruges på, er ved at bruge ad-hoc-kommandoer. Disse kan bruges, når du vil udstede nogle kommandoer på en server eller en flok servere. Ad-hoc kommandoer gemmes ikke til fremtidig brug, men repræsenterer en hurtig måde at interagere med de ønskede servere på.
Til denne Ansible-tutorial vil der blive konfigureret en simpel to-servere værtsfil, der indeholder host1 og host2.
Du kan sikre dig, at værterne er tilgængelige fra den relevante server ved at udstede en ping-kommando på alle værter.
[root@ansible-server test_ansible]# ansible -i hosts all -m ping host1 | SUCCESS => { "changed": false, "ping": "pong" } host2 | SUCCESS => { "changed": false, "ping": "pong" }
Forklaring:
- Status for kommandoen, i dette tilfælde SUCCES
- Vært, som kommandoen kørte på
- Kommandoen udstedt via parameteren -m, i dette tilfælde ping
- Med parameteren -i kan du pege på hosts-filen.
Du kan kun udstede den samme kommando på en bestemt vært, hvis det er nødvendigt.
[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2 host2 | SUCCESS => { "changed": false, "ping": "pong" }
Forklaring:
- Limit parameter kan kun bruges til at udstede kommandoer på specifikke værter i værtens fil
- Navnet på værten som defineret i inventarfilen
Hvis du har brug for at kopiere en fil til flere destinationer hurtigt, kan du bruge kopimodulet i ansible, som bruger SCP. Så kommandoen og dens output ser ud som nedenfor:
[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 }
Forklaring:
- Kopimodul defineret
- Modulargumenter er i dette tilfælde kildens absolutte sti og destinationens absolutte sti.
- Ansible kommandooutput, der afspejler succesen med kopikommandoen og andre detaljer som sha1 eller md5 kontrolsummer for filintegritetskontrol og metadata som ejer, størrelse eller tilladelser. Det er nemt at have en pakke installeret på en masse servere. Ansible har flere moduler, der interagerer med brugte installatører, såsom yum, apt, dnf osv.
I det næste eksempel vil du finde ud af, hvordan du installerer en pakke via yum-modulet på to Centos-værter.
[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" ] }
Forklaring:
- Yum-modulet bruges i dette eksempel
- Det definerer modulargumenterne, og i dette tilfælde vil du vælge navnet på pakken og dens tilstand. Hvis staten for eksempel er fraværende, vil pakken blive gennemsøgt, og hvis den findes, fjernes den
- Når den er farvet i gul, vil du se output fra den mulige kommando med ændret tilstand, hvilket betyder i dette tilfælde, at pakken blev fundet og installeret.
- Status for yum install-kommandoen udstedt via ansible. I dette tilfælde blev pakken ncdu.x86_64 0:1.14-1.el7 installeret.
Selvfølgelig kan alle yum-installationsmulighederne bruges via ansible, inklusive opdatering, installer, seneste version eller fjern.
I eksemplet nedenfor blev den samme kommando udstedt for at fjerne den tidligere installerede ncdu-pakke.
[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" ] }
Forklaring:
- Outputtet af yum-kommandoen viser, at pakken blev fjernet.
En anden nyttig og væsentlig funktion, som ansible bruger til at interagere med klientens server, er at indsamle nogle fakta om systemet. Så det henter hardware-, software- og versionsinformation fra systemet og gemmer hver værdi i en variabel, som senere kan bruges.
Hvis du har brug for detaljerede oplysninger om de systemer, der skal ændres via ansible, kan den næste kommando bruges. Opsætningsmodulet samler fakta fra systemvariablerne.
Ansible Playbooks
Ansible Playbooks er måden at sende kommandoer til fjernsystemer gennem scripts. Ansible playbooks bruges til at konfigurere komplekse systemmiljøer for at øge fleksibiliteten ved at udføre et script til et eller flere systemer. Ansible playbooks har en tendens til at være mere et konfigurationssprog end et programmeringssprog.
Ansible playbook-kommandoer bruger YAML-format, så der er ikke meget behov for syntaks, men indrykning skal respekteres. Som navnet siger, er en legebog en samling skuespil. Gennem en playbook kan du udpege bestemte roller til nogle værter og andre roller til andre værter. Ved at gøre det kan du orkestrere flere servere i meget forskellige scenarier, alt sammen i én spillebog.
For at have alle detaljerne præcise, før vi fortsætter med eksempler på Ansible playbook, skal vi først definere en opgave. Disse er grænsefladen til mulige moduler til roller og spillebøger.
Lad os nu lære Ansible playbook gennem et eksempel med en playbook med en play, der indeholder flere opgaver som nedenfor:
--- - hosts: group1 tasks: - name: Install lldpad package yum: name: lldpad state: latest - name: check lldpad service status service: name: lldpad state: started
I ovenstående Ansible playbook-eksempel er gruppe1 af værter i værtens fil målrettet mod lldpad-pakkeinstallation ved hjælp af yum-modulet, og bagefter startes den service lldpad, der er oprettet efter installationen, ved at bruge det servicemodul, der mest bruges til at interagere med systemd-ensemble.
Forklaring:
- Gruppe af værter, som spillebogen vil køre på
- Yum-modulet bruges i denne opgave til lldpad-installation
- Servicemodulet bruges til at kontrollere, om tjenesten er oppe og køre efter installationen
Hver mulig spillebog fungerer med en inventarfil. Inventarfilen indeholder en liste over servere opdelt i grupper for bedre kontrol med detaljer som f.eks IP-adresse og SSH-port for hver vært.
Inventarfilen, du kan bruge til dette Ansible playbook-eksempel, ser ud som nedenfor. Der er to grupper, navngivet gruppe1 og gruppe2, der hver indeholder henholdsvis vært1 og vært2.
[group1] host1 ansible_host=192.168.100.2 ansible_ssh_port=22 [group2] host2 ansible_host=192.168.100.3 ansible_ssh_port=22
Forklaring:
- Gruppe navn
- Værtsnavn med IP-adresse og ssh-port, i dette tilfælde standard, 22.
Et andet nyttigt Ansible playbook-eksempel, der denne gang indeholder to afspilninger for to værter, er det næste. For den første gruppe af værter, gruppe1, vil selinux være aktiveret. Hvis det er aktiveret, vises en meddelelse på værtens skærm.
For den anden gruppe af værter vil httpd-pakken kun blive installeret, hvis ansible_os_familien er RedHat og ansible_system_vendor er HP.
Ansible_os_family og ansible_system_vendor er variabler samlet med indsamle_fakta mulighed og kan bruges som i dette betingede eksempel.
--- - 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'
Forklaring:
- Eksempel på when-sætningen, I dette tilfælde, når OS-typen er Debian. Variablen ansible_os_family indsamles via funktionen gather_facts.
- Opgaveoutputtet er registreret til fremtidig brug med dets navn enable_selinux
- Endnu et eksempel på når-klausulen. I dette tilfælde vil en meddelelse blive vist til værtsbrugeren, hvis SELinux faktisk var aktiveret før.
- Endnu et eksempel på når-klausulen, der består af to regler
Udover opgaver er der også nogle særlige opgaver kaldet handlere. Håndtere skal have et unikt navn i hele spillebogen. Disse fungerer på samme måde som en almindelig opgave, men en behandler kan underrettes via en anmelder.
Hvis en handler ikke får besked under kørslen af afspilningsbogen, kører den ikke. Men hvis mere end én opgave giver en handler besked, vil dette kun køre én gang, efter at alle opgaverne er afsluttet.
I eksemplet vist nedenfor kan du se, hvordan en specifik opgave har en meddelelsessektion, som kalder på en anden opgave. Hvis outputtet af den første opgave ændres, kaldes en handleropgave. Det bedste eksempel er at få ændret en konfigurationsfil og bagefter genstarte den specifikke tjeneste.
--- - 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
I dette tilfælde, hvis den første opgave, "sshd config file modify port" ændres, hvilket betyder, at hvis porten ikke er 28675 i første omgang, så vil den blive ændret, og opgaven vil underrette handleren med samme navn om at køre , og det vil genstarte sshd-tjenesten.
Forklaring:
- Eksempel på en anmelder
- Eksempel på en handler
Ansible roller
Når man har med omfattende spillebøger at gøre, er det nemmere at opdele opgaverne i roller. Dette hjælper også med at genbruge rollerne i fremtiden. Roller er en samling af opgaver, som kan flyttes fra en playbook til en anden, kan køres uafhængigt, men kun gennem en playbook-fil.
Roller er gemt i separate mapper og har en bestemt mappestruktur.
[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
Yaml-filen i standardbiblioteket indeholder en liste over standardvariabler, der skal bruges sammen med spillebogen. Handlerbiblioteket bruges til at gemme handlere. Meta-mappen formodes at have information om forfatteren og rolleafhængigheder. I opgavebiblioteket er der den primære yaml-fil for rollen.
Testbiblioteket indeholder en prøve yaml playbook-fil og en prøveopgørelsesfil og bruges mest til testformål, før den faktiske rolle oprettes.
Vars-mappen indeholder yaml-filen, hvori alle de variabler, der bruges af rollen, vil blive defineret. Biblioteksskabelonerne og katalogfilerne skal indeholde filer og skabeloner, som vil blive brugt af opgaverne i rollen.
For at oprette bibliotekstræet til en rolle, skal du bruge følgende kommando med den sidste parameter, rollenavnet:
[root@ansible-server test2]# ansible-galaxy init role1
Ansible fungerer også godt med skabeloner. Som et sprog til skabeloner bruger det Jinja2.
I det næste eksempel vil du finde ud af, hvordan en grundlæggende jinja2-skabelon ser ud og bruge den i en rolle.
Ved kørselstiden, afhængigt af, lad os sige, i hvilket datacenter din server er placeret, kan du vælge mellem mere end én navneserver, der hver svarer til et datacenter, ved hjælp af variablen "resolver_ip_addresses."
{% for resolver in resolver_ip_addresses %} nameserver {{ resolver }} {% endfor %} options timeout:1 options attempts:5 options rotate
I dette eksempel er der defineret nogle variabler i playbook-mappen, inklusive en variabel ved navn resolver_ip_addresses med forskellige værdier afhængigt af datacenteret.
- name: Set resolver for server template: src: dns.j2 dest: /etc/resolv.conf group: root owner: root mode: "0644" tag: resolver
Forklaring:
- Navn på skabelonen, der skal bruges. Skabelon er placeret i skabeloner dir i rollestien
- Destinationsstien til filnavnet, der skal erstattes med skabelonen, på klientsiden.
- Tilladelser for destinationsfilen
Rolleopgaverne kan også have et tagfelt, som har et navn. Mere end én opgave kan dele det samme tag. Når du kører en ansible playbook, kan du også angive tagget, så disse opgaver vil blive udført.
Ansible Case Study
I dette afsnit vil vi analysere et casestudie af en essentiel ansible legebog, der har tre roller. Formålet med dette er at give et praktisk eksempel på, hvad vi talte om før. Nogle af de eksempler, der er brugt før i denne Ansible playbook-vejledning, vil blive tilpasset og brugt i denne playbook.
Nedenfor er biblioteksstrukturen for spillebogen. Yaml-filen, der vil blive brugt, vil være 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
Spillebogen har tre roller, en kaldet resolver, der sætter en specifik navneserver på serverne ved at kopiere en fil fra serveren til /etc/resolv.conf destinationen. En anden kaldes httpd, og den installerer httpd-pakken med yum-modulet, og den tredje aktiverer SELinux og giver den loggede bruger besked om at genstarte systemet. Hver rolle blev oprettet ved hjælp af ansible-galaxy kommando.
Resolver rolle, main.yml opgave:
Httpd rolle, main.yml opgave:
Selinux-rolle, main.yml-opgave:
Nedenfor er p4.yml playbook defineret. Det vil køre på alle værter, hvis ikke andet er angivet i kommandolinjen, det vil køre som root-bruger på port 22 (SSH), det vil indsamle fakta, før det kører rollerne, og det vil køre alle tre roller nævnt før. Hver rolle kan køres uafhængigt ved at angive tagget i ansible-playbook-kommandolinjen med parameteren –t.
--- - hosts: all user: root port: 22 gather_facts: True roles: - { role: selinux, tags: selinux } - { role: httpd, tags: httpd } - { role: resolver, tags: resolver }
Kørsel af p4.yml playbook på to værter og fortolkning af outputtet. Den samme kommando kan køres med parameteren –check for en tørkørsel. Hvis du vil bruge adgangskodegodkendelse, skal du bruge -k parameter.
Forklaring:
- Ansible-playbook-kommando, der kører p4.yml
- Playbook springer SELinux-rollen over, fordi den allerede er aktiveret.
- Ansible fandt ud af, at httpd-pakken allerede er installeret, så den returnerer ok.
- Resolver blev indstillet, og rolleresolver fik status ændret.
Ansible Commands Cheat Sheet
Installer EPEL repo på Centos/RHEL-systemer
[root@ansible-server ~]# sudo yum install epel-release
Installer en passende pakke på Centos/RHEL-systemer
[root@ansible-server ~]# sudo yum install -y ansible
Udfør en opdatering af pakkerne på Debian/Ubuntu systemer
$ sudo apt update
Installer software-properties-common-pakken på Debian/Ubuntu systemer
$ sudo apt install software-properties-common
Installer et passende personligt pakkearkiv på Debian/Ubuntu systemer
$ sudo apt-add-repository ppa:ansible/ansible
Installer ansible på Debian/Ubuntu systemer
$ sudo apt update $ sudo apt install ansible
Udsted en ping-kommando på alle servere, der er defineret i inventarfilen med navnet hosts
[root@ansible-server test_ansible]# ansible -i hosts all -m ping
Udsted kun en ping-kommando på host2
[root@ansible-server test_ansible]# ansible -i hosts all -m ping --limit host2
Kopier filen "testfile" på alle værter i inventarfilen
[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"
Installer ncdu-pakken på alle værter
[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=present'
Fjern ncdu-pakken på alle værter
[root@ansible-server test_ansible]# ansible -i hosts all -m yum -a 'name=ncdu state=absent'
Byg katalogstrukturen for rollen med navnet rolle1.
[root@ansible-server test2]# ansible-galaxy init role1
Tørløb p4.yml spillebog
[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml --check
Kør p4.yml playbook med adgangskodegodkendelse for alle værter
[root@ansible-server test_ansible]# ansible-playbook -i hosts p4.yml -k
Resumé
I en verden med teknologi, der konstant ændrer sig i et hurtigt tempo og vokser utrolig hurtigt på samme tid, skal systemadministratorer og devops-ingeniører tænke på forskellige tilgange til, hvordan man automatiserer rutineopgaver og orkestrerer store puljer af servere.
Mens der er mange alternativ til Ansible (Kok, Puppet) derude, der gør det samme med nogle forskelle, formåede Ansible at hæve sig over dem alle med sin enkelhed, forbedrede sikkerhed og vigtigst af alt sin glatte indlæringskurve. På grund af disse kvaliteter og hurtige indførelse af Ansible, har vi lavet en tutorial fuld af eksempler, så du kan få en endnu mere problemfri første oplevelse med at arbejde med Ansible.
I denne Ansible grundlæggende tutorial beskrev vi ansible og talte lidt om dens historie. Vi nævnte Ansibles stærke sider og de fordele, som ansible kan give til automatisering og orkestrering af infrastrukturer af forskellig størrelse. Vi definerede de væsentlige ansible brugte termer og definerede strukturen af Ansible playbooks. Grundige eksempler ledsagede al information med detaljerede forklaringer.