Ansible veiledning for nybegynnere: Playbook, kommandoer og eksempel

Hva er Ansible?

Ansible er et åpen kildekode-automatiserings- og orkestreringsverktøy for programvarelevering, konfigurasjonsadministrasjon og programvaredistribusjon. Ansible kan enkelt kjøre og konfigurere Unix-lignende systemer i tillegg Windows systemer for å tilby infrastruktur som kode. Den inneholder sitt eget deklarative programmeringsspråk for systemkonfigurasjon og -administrasjon.

Ansible er populært for sin enkelhet i installasjonen, brukervennligheten når det gjelder tilkobling til klienter, mangelen på agent for Ansible-klienter og mangfoldet av ferdigheter. Den fungerer ved å koble til via SSH til klientene, så den trenger ikke en spesiell agent på klientsiden, og ved å skyve moduler til klientene, blir modulene deretter utført lokalt på klientsiden og utdataene skyves tilbake til Ansible-serveren.

Siden den bruker SSH, kan den veldig enkelt koble til klienter ved hjelp av SSH-nøkler, noe som forenkler hele prosessen. Klientdetaljer, som vertsnavn eller IP-adresser og SSH-porter, lagres i filer som kalles inventarfiler. Når du har opprettet en inventarfil og fylt den ut, kan ansible bruke den.

Hvorfor bruke Ansible?

Her er noen viktige fordeler med å bruke Ansible

• En av de viktigste fordelene med Ansible er at den er gratis å bruke av alle.
• Den trenger ingen spesielle systemadministratorferdigheter for å installere og bruke Ansible, og den offisielle dokumentasjonen er svært omfattende.
• Modulariteten angående plugins, moduler, inventar og spillebøker gjør Ansible til den perfekte følgesvennen for å orkestrere store miljøer.
• Ansible er veldig lett og konsekvent, og ingen begrensninger angående operativsystemet eller underliggende maskinvare er tilstede.
• Den er også veldig sikker på grunn av dens agentløse evner og på grunn av bruken av OpenSSH sikkerhetsfunksjoner.
• En annen fordel som oppmuntrer til bruk av Ansible, er dens jevne læringskurve bestemt av den omfattende dokumentasjonen og strukturen og konfigurasjonen som er lett å lære.

Ansibles historie

Her er viktige landemerker fra ansibles historie:

• I februar 2012 startet Ansible-prosjektet. Den ble først utviklet av Michael DeHaan, skaperen av Cobbler and Func, Fedora Unified Network Controller.
• Opprinnelig kalt AnsibleWorks Inc, selskapet som finansierte ansible-verktøyet ble kjøpt opp i 2015 av RedHat og senere, sammen med RedHat, flyttet under paraplyen til IBM.
• I nåtiden kommer Ansible inkludert i distribusjoner som Fedora Linux, RHEL, Centos og Oracle Linux.

Viktige termer brukt i Ansible

• Ansible server

  Maskinen der Ansible er installert og som alle oppgaver og spillebøker skal kjøres fra

• Moduler

  I utgangspunktet er en modul en kommando eller et sett med lignende Ansible-kommandoer ment å bli utført på klientsiden

• Oppgave

  En oppgave er en del som består av én enkelt prosedyre som skal fullføres

• Rolle

  En måte å organisere oppgaver og relaterte filer for senere å bli kalt inn i en spillebok

• Faktum

  Informasjon hentet fra klientsystemet fra de globale variablene med samle-fakta-operasjonen

• Varelager

  Fil som inneholder data om mulige klientservere. Definert i senere eksempler som vertsfil

• Spille

  Utførelse av en lekebok

• Handler

  Oppgave som kalles kun hvis en varsler er tilstede

• Varsler

  Seksjon tilskrevet en oppgave som kaller en behandler hvis utdata endres

• tag

  Navn satt til en oppgave som kan brukes senere til å utstede nettopp den spesifikke oppgaven eller gruppen av oppgaver.

Ansible installasjon i Linux

Når du har sammenlignet og veid alternativene dine og bestemt deg for å gå for Ansible, er neste trinn å få det installert på systemet ditt. Vi vil gå gjennom trinnene for installasjon i forskjellige Linux distribusjoner, de mest populære, i den neste lille opplæringen.

Installer Ansible på Centos/RedHat-systemer

Trinn 1) Installer EPEL repo

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

Trinn 2) Installer mulig pakke

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

Installer mulig på Ubuntu/Debian-systemer

Trinn 1) Utfør en oppdatering av pakkene

$ sudo apt update

Trinn 2) Installer software-properties-common-pakken

$ sudo apt install software-properties-common

Trinn 3) Installer et mulig personlig pakkearkiv

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

Trinn 4) Installer mulig

$ sudo apt update
$ sudo apt install ansible

Mulige ad hoc-kommandoer

En av de enkleste måtene Ansible kan brukes på er å bruke ad-hoc-kommandoer. Disse kan brukes når du vil utstede noen kommandoer på en server eller en haug med servere. Ad-hoc-kommandoer lagres ikke for fremtidig bruk, men representerer en rask måte å samhandle med de ønskede serverne på.

For denne Ansible-opplæringen vil en enkel vertsfil med to servere konfigureres, som inneholder vert1 og vert2.

Du kan sørge for at vertene er tilgjengelige fra den aktuelle serveren ved å gi en ping-kommando på alle verter.

[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 tilfellet SUKSESS
2. Vert som kommandoen kjørte på
3. Kommandoen utstedt via parameteren -m, i dette tilfellet ping
4. Med parameteren -i kan du peke på vertsfilen.

Du kan gi den samme kommandoen bare på en spesifikk vert om nødvendig.

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

Forklaring:

1. Limit-parameter kan brukes til å gi kommandoer bare på spesifikke verter i vertens fil
2. Navnet på verten som definert i inventarfilen

Hvis du trenger å kopiere en fil til flere destinasjoner raskt, kan du bruke kopimodulen i ansible som bruker SCP. Så kommandoen og dens utgang ser ut 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 definert
2. Modulargumenter, i dette tilfellet, er absolutt kildebane og absolutt målbane.
3. Ansible kommandoutgang som gjenspeiler suksessen til kopieringskommandoen og andre detaljer som sha1- eller md5-sjekksummene for filintegritetssjekk og metadata som eier, størrelse eller tillatelser. Det er enkelt å ha en pakke installert på en haug med servere. Ansible har flere moduler som samhandler med brukte installatører, som yum, apt, dnf, etc.

I neste eksempel vil du finne ut hvordan du installerer en pakke via yum-modulen på to Centos-verter.

[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-modulen brukes i dette eksemplet
2. Den definerer modulargumentene, og i dette tilfellet vil du velge navnet på pakken og dens tilstand. Hvis staten er fraværende, for eksempel, vil pakken bli gjennomsøkt og fjernet hvis den blir funnet
3. Når den er farget i gult, vil du se utdataene til den aktuelle kommandoen med tilstanden endret, noe som i dette tilfellet betyr at pakken ble funnet og installert.
4. Status for yum install-kommandoen utstedt via ansible. I dette tilfellet ble pakken ncdu.x86_64 0:1.14-1.el7 installert.

Selvfølgelig kan alle yum-installasjonsalternativene brukes via ansible, inkludert oppdatering, installering, siste versjon eller fjern.

I eksemplet nedenfor ble den samme kommandoen gitt for å fjerne den tidligere installerte ncdu-pakken.

[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. Utdataene fra yum-kommandoen viser at pakken ble fjernet.

En annen nyttig og viktig funksjon som ansible bruker for å samhandle med klientens server, er å samle noen fakta om systemet. Så den henter maskinvare-, programvare- og versjonsinformasjon fra systemet og lagrer hver verdi i en variabel som kan brukes senere.

Hvis du trenger detaljert informasjon om systemene som skal modifiseres via ansible, kan neste kommando brukes. Oppsettmodulen samler fakta fra systemvariablene.

Ansible playbook-kommandoer bruker YAML-format, så det er ikke mye syntaks som trengs, men innrykk må respekteres. Som navnet sier, er en lekebok en samling skuespill. Gjennom en lekebok kan du utpeke spesifikke roller til noen verter og andre roller til andre verter. Ved å gjøre det kan du orkestrere flere servere i svært forskjellige scenarier, alt i én spillebok.

For å ha alle detaljene nøyaktige før vi fortsetter med eksempler på Ansible playbook, må vi først definere en oppgave. Dette er grensesnittet til mulige moduler for roller og spillebøker.

La oss nå lære Ansible playbook gjennom et eksempel med en playbook med en play, som inneholder flere oppgaver 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 eksemplet over Ansible playbook er gruppen1 av verter i vertsfilen målrettet for lldpad-pakkeinstallasjon ved hjelp av yum-modulen, og etterpå startes tjenesten lldpad opprettet etter installasjonen ved å bruke tjenestemodulen som hovedsakelig brukes til å samhandle med systemd-ensemble.

Forklaring:

1. Gruppe med verter som spilleboken skal kjøres på
2. Yum-modulen brukes i denne oppgaven for lldpad-installasjon
3. Servicemodulen brukes til å sjekke om tjenesten er oppe og kjører etter installasjon

Hver ansible spillebok fungerer med en inventarfil. Inventarfilen inneholder en liste over servere delt inn i grupper for bedre kontroll for detaljer som IP-adresse og SSH-port for hver vert.

Inventarfilen du kan bruke for dette Ansible playbook-eksemplet ser ut som nedenfor. Det er to grupper, kalt gruppe1 og gruppe2, som hver inneholder henholdsvis vert1 og vert2.

[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. Gruppenavn
2. Vertsnavn, med IP-adresse og ssh-port, i dette tilfellet standarden, 22.

Et annet nyttig Ansible playbook-eksempel som inneholder denne gangen to avspillinger for to verter, er det neste. For den første gruppen med verter, gruppe1, vil selinux være aktivert. Hvis det er aktivert, vil en melding vises på skjermen til verten.

For den andre gruppen av verter, vil httpd-pakken kun installeres hvis ansible_os_family er RedHat og ansible_system_vendor er HP.

Ansible_os_family og ansible_system_vendor er variabler samlet med alternativet gather_facts og kan brukes som i dette betingede eksemplet.

---

- 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å når-klausulen, I dette tilfellet, når OS-typen er Debian. Ansible_os_family-variabelen samles inn via gather_facts-funksjonaliteten.
2. Oppgaveutgangen er registrert for fremtidig bruk, med navnet enable_selinux
3. Et annet eksempel på når-klausulen. I dette tilfellet vil en melding vises for vertsbrukeren hvis SELinux faktisk var aktivert før.
4. Et annet eksempel på når-klausulen som består av to regler

I tillegg til oppgaver, er det også noen spesielle oppgaver som kalles behandlere. Håndtere må ha et unikt navn gjennom hele spilleboken. Disse fungerer på samme måte som en vanlig oppgave, men en behandler kan varsles via en varsler.

Hvis en behandler ikke blir varslet under kjøringen av spilleboken, vil den ikke kjøre. Men hvis mer enn én oppgave varsler en behandler, vil dette kun kjøres én gang etter at alle oppgavene er fullført.

I eksemplet nedenfor kan du se hvordan en spesifikk oppgave har en varslingsdel som kaller på en annen oppgave. Hvis utdata fra den første oppgaven endres, vil en behandleroppgave bli kalt. Det beste eksemplet er å få endret en konfigurasjonsfil og deretter starte den spesifikke tjenesten på nytt.

---

- 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 tilfellet, hvis den første oppgaven, "sshd config file modify port" endres, noe som betyr at hvis porten ikke er 28675 i utgangspunktet, vil den bli endret og oppgaven vil varsle behandleren med samme navn om å kjøre , og den vil starte sshd-tjenesten på nytt.

Forklaring:

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

Ansible roller

Når du har å gjøre med omfattende lekebøker, er det lettere å dele opp oppgavene i roller. Dette hjelper også med å gjenbruke rollene i fremtiden. Roller er en samling oppgaver som kan flyttes fra en spillebok til en annen, kan kjøres uavhengig, men bare gjennom en spillebokfil.

Roller lagres i separate kataloger og har en bestemt katalogstruktur.

[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 standardkatalogen inneholder en liste over standardvariabler som skal brukes sammen med spilleboken. Behandlerkatalogen brukes til å lagre behandlere. Metakatalogen skal ha informasjon om forfatteren og rolleavhengigheter. I oppgavekatalogen er det yaml-hovedfilen for rollen.

Testkatalogen inneholder et eksempel på en yaml playbook-fil og en eksempel på inventarfil og brukes for det meste til testformål før den faktiske rollen opprettes.

Vars-katalogen inneholder yaml-filen der alle variablene som brukes av rollen vil bli definert. Katalogmalene og katalogfilene skal inneholde filer og maler som skal brukes av oppgavene i rollen.

For å lage katalogtreet for en rolle, bør du bruke følgende kommando med den siste parameteren, rollenavnet:

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

Ansible fungerer også bra med maler. Som et språk for maling bruker den Jinja2.

I neste eksempel vil du finne ut hvordan en grunnleggende jinja2-mal ser ut og bruke den i en rolle.

På kjøretiden, avhengig av, la oss si i hvilket datasenter serveren din er plassert, kan du velge fra mer enn én navneserver, som hver tilsvarer et datasenter, ved å bruke variabelen «resolver_ip_addresses».

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

options timeout:1
options attempts:5
options rotate

I dette eksemplet, i playbook-katalogen, er det definert noen variabler, inkludert en variabel kalt resolver_ip_addresses med forskjellige verdier avhengig av datasenteret.

- 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å malen som skal brukes. Mal ligger i maler dir i rollebanen
2. Destinasjonsbanen til filnavnet som skal erstattes med malen, på klientsiden.
3. Tillatelser for målfilen

Rolleoppgavene kan også ha et tagfelt, som har et navn. Mer enn én oppgave kan dele samme tag. Når du kjører en ansible playbook, kan du spesifisere taggen også, slik at disse oppgavene blir utført.

Ansible kasusstudie

I denne delen vil vi analysere en case-studie av en essensiell ansible lekebok som har tre roller. Hensikten med dette er å gi et praktisk eksempel på hva vi snakket om før. Noen av eksemplene som er brukt før i denne Ansible playbook-opplæringen vil bli tilpasset og brukt i denne playbook.

Nedenfor er katalogstrukturen til spilleboken. Yaml-filen som skal brukes 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

Spilleboken har tre roller, en kalt resolver som setter en spesifikk navneserver på serverne ved å kopiere en fil fra serveren til /etc/resolv.conf-destinasjonen. En annen kalles httpd, og den installerer httpd-pakken med yum-modulen, og den tredje aktiverer SELinux og varsler den loggede brukeren om å starte systemet på nytt. Hver rolle ble opprettet ved hjelp av ansible-galaxy-kommandoen.

Løserrolle, main.yml-oppgave:

Httpd-rolle, main.yml-oppgave:

Selinux-rolle, main.yml-oppgave:

Nedenfor er p4.yml-spilleboken definert. Det vil kjøre på alle verter hvis ikke annet er spesifisert i kommandolinjen, det vil kjøre som root-bruker på port 22 (SSH), det vil samle fakta før det kjører rollene, og det vil kjøre alle de tre rollene nevnt før. Hver rolle kan kjøres uavhengig ved å spesifisere taggen i ansible-playbook-kommandolinjen med –t-parameteren.

---

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

Kjøre p4.yml-spilleboken på to verter og tolke utdataene. Den samme kommandoen kan kjøres med –check-parameteren for en tørrkjøring. I tilfelle du vil bruke passordautentisering, bruk -k parameter.

Forklaring:

1. Ansible-playbook-kommando som kjører p4.yml
2. Playbook hopper over SELinux-rollen fordi den allerede er aktivert.
3. Ansible fant ut at httpd-pakken allerede er installert, så den returnerer ok.
4. Resolver ble satt, og rolleløser fikk status endret.

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

Utfør en oppdatering av pakkene på Debian/Ubuntu systemer

$ sudo apt update

Installer software-properties-common-pakken på Debian/Ubuntu systemer

$ sudo apt install software-properties-common

Installer mulig personlig 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

Utsted en ping-kommando på alle servere som er definert i inventarfilen kalt hosts

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

Utsted en ping-kommando bare på host2

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

Kopier filen "testfile" på alle verter 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 verter

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

Fjern ncdu-pakken på alle verter

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

Bygg katalogstrukturen for rolle kalt rolle1.

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

Tørrkjørt p4.yml-lekebok

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

Kjør p4.yml playbook med passordautentisering for alle verter

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

Sammendrag

I en verden med teknologi som kontinuerlig endrer seg i raskt tempo og vokser utrolig raskt samtidig, må systemadministratorer og devops-ingeniører tenke på forskjellige tilnærminger for hvordan de kan automatisere rutineoppgaver og orkestrere store servergrupper.

Mens det er mange alternativ til Ansible (Chef, Puppet) der ute som gjør det samme med noen forskjeller, Ansible klarte å heve seg over dem alle med sin enkelhet, forbedrede sikkerhet og ikke minst sin jevne læringskurve. På grunn av disse egenskapene og den raske innføringen av Ansible, har vi laget en opplæring full av eksempler slik at du kan få en enda mer sømløs første erfaring med å jobbe med Ansible.

I denne grunnleggende opplæringen for Ansible beskrev vi ansible og snakket litt om historien. Vi nevnte de sterke sidene til Ansible og fordelene som ansible kan gi til automatisering og orkestrering av infrastrukturer av forskjellige størrelser. Vi definerte de essensielle ansible brukte begrepene og definerte strukturen til Ansible playbooks. Grundige eksempler fulgte med all informasjon med detaljerte forklaringer.