Ansible-vejledning for begyndere: Håndbog og kommandoer

Ansible er et af de mest udbredte open source-automatiseringsværktøjer i moderne DevOps, værdsat for sit agentløse design og sine enkle, læsbare konfigurationsfiler. Denne Ansible-tutorial for begyndere forklarer, hvad Ansible er, hvordan man installerer det, og hvordan man bruger ad-hoc-kommandoer, playbooks, roller og skabeloner gennem praktiske eksempler.

Hvad er Ansible?

Ansible er et open source-automatiserings- og orkestreringsværktøj til softwareprovisionering, konfigurationsstyring og softwareimplementering. Det konfigurerer Unix-lignende systemer og Windows systemer, der leverer infrastruktur som kode gennem sit eget deklarative sprog. Ansible sammenlignes ofte med agentbaserede værktøjer som f.eks. Marionet.

Ansible er populært for sin enkle installation, nemme klientforbindelse og sit agentløse design. Det opretter forbindelse til klienter over SSH, så der kræves ingen særlig agent på klientsiden. Ansible sender moduler til hver klient, modulerne kører lokalt, og deres output returneres til Ansible-serveren.

Fordi Ansible bruger SSH, opretter det nemt 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 inventory-filer. Når du har oprettet og udfyldt en inventory-fil, kan Ansible bruge den.

Hvorfor bruge Ansible?

Her er nogle vigtige fordele ved at bruge Ansible:

• En af de største fordele ved Ansible er, at det er gratis for alle at bruge.
• Det kræver ikke særlige systemadministratorfærdigheder at installere og bruge, og den officielle dokumentation er meget omfattende.
• Dens modularitet på tværs af plugins, moduler, inventarer og playbooks gør Ansible til en fremragende ledsager til orkestrering af store miljøer.
• Ansible er let og konsistent, uden begrænsninger på operativsystemet eller den underliggende hardware.
• Det er meget sikkert takket være dets agentløse design og dets brug af OpenSSH-sikkerhedsfunktioner.
• Ansible har en jævn indlæringskurve, understøttet af grundig dokumentation og en letlært struktur og konfiguration.

Disse styrker, især når de vejes op mod andre alternativer til Ansible, hjælper med at forklare dens hurtige implementering. Før installationen er det nyttigt at forstå, hvordan projektet udviklede sig.

Ansibles historie

Her er de vigtige milepæle i Ansibles historie:

• Ansible-projektet begyndte i februar 2012. Det blev først udviklet af Michael DeHaan, skaberen af ​​Cobbler og Func (Fedora Unified Network Controller).
• Virksomheden, der oprindeligt hed AnsibleWorks Inc., blev opkøbt af RedHat i 2015 og senere, sammen med RedHat, flyttet under IBM paraply.
• I dag er Ansible inkluderet i distributioner som Fedora Linux, RHEL, CentOS og ... Oracle Linux.

Vigtige termer brugt i Ansible

Følgende termer optræder i hele denne Ansible-vejledning og er værd at kende, før du starter:

Ansible server

Den maskine, hvor Ansible er installeret, og hvorfra alle opgaver og playbooks køres.

Moduler

Et modul er en kommando eller et sæt lignende Ansible-kommandoer, der er beregnet til at blive udført på klientsiden.

Opgaver

En opgave er en sektion, der består af en enkelt procedure, der skal udføres.

roller

En måde at organisere opgaver og relaterede filer på, så de kan kaldes senere i en playbook.

Faktum

Oplysninger hentet fra klientsystemets globale variabler via gather_facts-operationen.

Inventory

En fil, der indeholder data om Ansible-klientserverne. I senere eksempler defineres den som hosts-filen.

Leg

Udførelsen af ​​en playbook.

handler

En opgave, der kun kaldes, når en notifier er til stede.

Underretning

En sektion, der er tilskrevet en opgave, og som kalder en handler, hvis outputtet ændres.

tag

Et navn, der er angivet på en opgave, og som senere kan bruges til at køre netop den specifikke opgave eller gruppe af opgaver.

Ansible installation i Linux

Når du har overvejet dine muligheder og besluttet dig for at bruge Ansible, er næste skridt at installere det på dit system. Følgende korte gennemgang dækker installation på de mest populære Linux distributioner.

Installer Ansible på Centos/RedHat-systemer

Trin 1) Installer EPEL-repoet.

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

Trin 2) Installer ansible-pakken.

[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 software-properties-common-pakken.

$ sudo apt install software-properties-common

Trin 3) Installer det personlige pakkearkiv for ansible.

$ 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 at bruge Ansible på er via ad-hoc-kommandoer. Disse er nyttige, når du vil udføre en kommando på en enkelt server eller på en gruppe af servere. Ad-hoc-kommandoer gemmes ikke til senere brug, men de er en hurtig måde at interagere med de servere, du vælger.

Til denne Ansible-tutorial konfigureres en simpel hosts-fil med to servere, der indeholder host1 og host2.

Du kan bekræfte, at værterne kan nås fra Ansible-serveren 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 også udføre den samme kommando på en enkelt vært, når 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 hurtigt skal kopiere en fil til flere destinationer, skal du bruge kopimodulet, som er afhængig af SCP. Kommandoen og dens output ser således ud:

[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 installerer du en pakke med 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-installationsindstillingerne bruges via Ansible, inklusive opdatering, installation, seneste version og fjern.

I eksemplet nedenfor udføres den samme kommando 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 vigtig funktion i Ansible er dens evne til at indsamle fakta om et system. Den indsamler hardware-, software- og versionsoplysninger og gemmer hver værdi i en variabel, som du kan genbruge senere.

Når du har brug for detaljerede oplysninger om de systemer, som Ansible vil ændre, indsamler opsætningsmodulet disse fakta fra systemvariablerne.

Ansible Playbooks

Ansible Playbooks er måden at sende kommandoer til eksterne systemer via scripts. Playbooks konfigurerer komplekse systemmiljøer og øger fleksibiliteten ved at køre et enkelt script mod et eller flere systemer. De opfører sig mere som et konfigurationssprog end et programmeringssprog.

Playbook-kommandoer bruger YAML-formatet, så der kræves kun lidt syntaks, men indrykning skal respekteres. Som navnet antyder, er en playbook en samling af plays. Gennem en playbook kan du tildele specifikke roller til nogle værter og forskellige roller til andre, og dermed orkestrere mange servere i én fil.

Før vi fortsætter med eksemplerne i playbooks, er det en god idé at definere en opgave. Opgaver er grænsefladen til Ansible-moduler for roller og playbooks.

Overvej nu en Ansible-playbook med ét play, der indeholder flere opgaver, som vist 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 playbook er group1-værterne i hosts-filen målrettet mod installation af lldpad-pakker ved hjælp af yum-modulet. Den lldpad-tjeneste, der oprettes efter installationen, startes derefter ved hjælp af servicemodulet, som primært interagerer med systemd-ensemblet.

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 Ansible playbook arbejder med en inventory-fil. Inventory-filen indeholder en liste over servere opdelt i grupper, hvilket giver bedre kontrol over detaljer såsom IP-adresse og SSH-port for hver vært.

Inventarfilen for dette playbook-eksempel ser sådan ud. Der er to grupper, gruppe1 og gruppe2, som hver indeholder henholdsvis host1 og host2.

[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.

Det næste eksempel på en Ansible-playbook indeholder to plays for to værtsgrupper. For den første gruppe, gruppe1, er SELinux aktiveret, og når det er aktiveret, vises en meddelelse på værtsskærmen.

For den anden gruppe installeres httpd-pakken kun, hvis ansible_os_family er RedHat, og ansible_system_vendor er HP.

ansible_os_family og ansible_system_vendor er variabler indsamlet med gather_facts-indstillingen, og de 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å særlige opgaver kaldet handlere. En handler skal have et unikt navn i hele playbooken. Handlere fungerer som en almindelig opgave, men en handler kan underrettes via en notifier.

Hvis en handler ikke får besked under en playbook-kørsel, kører den ikke. Men hvis mere end én opgave giver besked til en handler, kører den kun én gang, når alle opgaverne er færdige.

I eksemplet nedenfor har en specifik opgave en notifikationssektion, der kalder en anden opgave. Hvis outputtet fra den første opgave ændres, kaldes en håndteringsopgave. Et almindeligt eksempel er at ændre en konfigurationsfil og derefter genstarte den berørte 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 porten ikke allerede er 28675, ændres porten, og opgaven underretter handleren med samme navn, som genstarter sshd-tjenesten.

Forklaring:

1. Eksempel på en anmelder
2. Eksempel på en handler

Ansible roller

Når man arbejder med store playbooks, er det nemmere at opdele opgaverne i roller. Roller gør det også nemmere at genbruge arbejde senere. En rolle er en samling af opgaver, der kan flyttes fra en playbook til en anden og køre uafhængigt, dog kun via en playbook-fil.

Roller gemmes i separate mapper og følger en specifik 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 defaults-mappen indeholder de standardvariabler, der bruges med playbooken. Handlers-mappen indeholder handlere, og meta-mappen indeholder oplysninger om forfatteren og rolleafhængigheder. Tasks-mappen indeholder den primære YAML-fil for rollen.

Testmappen indeholder en eksempel-YAML-playbook og en eksempel-inventory-fil, og den bruges primært til test, før den egentlige rolle oprettes.

Mappen vars indeholder YAML-filen, hvor alle variabler, der bruges af rollen, er defineret. Mappene skabeloner og filer indeholder de skabeloner og filer, der bruges af opgaverne i rollen.

For at oprette mappetræet for en rolle skal du bruge følgende kommando med rollenavnet som den sidste parameter:

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

Ansible fungerer også godt med skabeloner, og det bruger Jinja2 som skabelonsprog.

Det næste eksempel viser, hvordan en grundlæggende Jinja2-skabelon ser ud, og hvordan man bruger den i en rolle.

Under kørsel, afhængigt af f.eks. hvilket datacenter din server er placeret i, kan du vælge mellem flere navneservere, 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 definerer playbook-mappen flere variabler, herunder 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

Rolleopgaver kan også have et tagfelt med et tildelt navn. Mere end én opgave kan dele det samme tag, og når du kører en playbook, kan du angive et tag, så kun de taggede opgaver udføres.

Ansible Case Study

I dette afsnit analyserer vi en casestudie af en essentiel Ansible-håndbog, der har tre roller. Målet er at give et praktisk eksempel på de koncepter, der er dækket indtil videre. Nogle tidligere eksempler fra denne vejledning er tilpasset og genbrugt i denne håndbog.

Nedenfor er mappestrukturen for playbooken. Den anvendte YAML-fil er 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

Playbooken har tre roller. Resolver-rollen sætter en specifik navneserver på serverne ved at kopiere en fil til destinationen /etc/resolv.conf. httpd-rollen installerer httpd-pakken med yum-modulet, og den tredje rolle aktiverer SELinux og giver den indloggede bruger besked om at genstarte systemet. Hver rolle blev oprettet med kommandoen ansible-galaxy.

Resolver rolle, main.yml opgave:

Httpd rolle, main.yml opgave:

Selinux-rolle, main.yml-opgave:

Nedenfor er p4.yml-playbooken. Den kører på alle værter, medmindre andet er angivet på kommandolinjen, kører som root-bruger på port 22 (SSH), indsamler data før rollerne køres, og kører alle tre roller. Hver rolle kan køres uafhængigt ved at angive dens tag på kommandolinjen ansible-playbook 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 }

Du kan derefter køre p4.yml playbooken på de to værter og fortolke outputtet. Den samme kommando kan køres med -check parameteren til en testkørsel, og med -k parameteren, når du vil bruge adgangskodegodkendelse.

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

Udgave a ping kommandoen på alle servere defineret i inventory-filen med navnet hosts

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

Udgave a ping kommando kun 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

Ofte Stillede Spørgsmål