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:

1. Status for kommandoen, i dette tilfælde SUCCES
2. Vært, som kommandoen kørte på
3. Kommandoen udstedt via parameteren -m, i dette tilfælde ping
4. 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:

1. Limit parameter kan kun bruges til at udstede kommandoer på specifikke værter i værtens fil
2. 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:

1. Kopimodul defineret
2. Modulargumenter er i dette tilfælde kildens absolutte sti og destinationens absolutte sti.
3. 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:

1. Yum-modulet bruges i dette eksempel
2. 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
3. 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.
4. 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:

1. 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 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:

1. Gruppe af værter, som spillebogen vil køre på
2. Yum-modulet bruges i denne opgave til lldpad-installation
3. 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:

1. Gruppe navn
2. 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:

1. Eksempel på when-sætningen, I dette tilfælde, når OS-typen er Debian. Variablen ansible_os_family indsamles via funktionen gather_facts.
2. Opgaveoutputtet er registreret til fremtidig brug med dets navn enable_selinux
3. 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.
4. 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:

1. Eksempel på en anmelder
2. 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:

1. Navn på skabelonen, der skal bruges. Skabelon er placeret i skabeloner dir i rollestien
2. Destinationsstien til filnavnet, der skal erstattes med skabelonen, på klientsiden.
3. 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:

1. Ansible-playbook-kommando, der kører p4.yml
2. Playbook springer SELinux-rollen over, fordi den allerede er aktiveret.
3. Ansible fandt ud af, at httpd-pakken allerede er installeret, så den returnerer ok.
4. 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.