Ansible-opetusohjelma aloittelijoille: Pelikirja ja komennot

Ansible on yksi laajimmin käytetyistä avoimen lähdekoodin automaatiotyökaluista nykyaikaisessa... DevOps, jota arvostetaan agentittoman suunnittelunsa ja yksinkertaisten, luettavien määritystiedostojensa ansiosta. Tämä Ansible-opetusohjelma aloittelijoille selittää, mikä Ansible on, miten se asennetaan ja miten ad-hoc-komentoja, pelikirjoja, rooleja ja malleja käytetään käytännön esimerkkien avulla.

Mikä on Ansible?

Ansible on avoimen lähdekoodin automaatio- ja orkestrointityökalu ohjelmistojen tarjoamiseen, konfiguroinnin hallintaan ja käyttöönottoon. Se konfiguroi Unix-tyyppisiä järjestelmiä ja Windows järjestelmät, jotka tarjoavat infrastruktuurin koodina oman deklaratiivisen kielensä kautta. Ansiblea verrataan usein agenttipohjaisiin työkaluihin, kuten nukke.

Ansible on suosittu yksinkertaisen asennuksensa, helpon asiakasyhteyden ja agentittoman suunnittelunsa ansiosta. Se muodostaa yhteyden asiakkaisiin yli SSH, joten asiakaspuolella ei tarvita erityistä agenttia. Ansible lähettää moduulit jokaiselle asiakasohjelmalle, moduulit suoritetaan paikallisesti ja niiden tuloste palautetaan Ansible-palvelimelle.

Koska Ansible käyttää SSH:ta, se muodostaa helposti yhteyden asiakkaisiin SSH-avaimilla, mikä yksinkertaistaa koko prosessia. Asiakastiedot, kuten isäntänimet tai IP-osoitteet ja SSH-portit, tallennetaan tiedostoihin, joita kutsutaan inventaariotiedostoiksi. Kun olet luonut ja täyttänyt inventaariotiedoston, Ansible voi käyttää sitä.

Miksi käyttää Ansiblea?

Tässä on joitakin Ansiblen käytön tärkeitä etuja:

• Yksi Ansiblen merkittävimmistä eduista on, että se on ilmainen kaikille.
• Sen asentaminen ja käyttö ei vaadi erityisiä järjestelmänvalvojan taitoja, ja virallinen dokumentaatio on erittäin kattava.
• Sen modulaarisuus laajennusten, moduulien, inventaarioiden ja pelikäsikirjojen välillä tekee Ansiblesta erinomaisen kumppanin suurten ympäristöjen orkestrointiin.
• Ansible on kevyt ja johdonmukainen, eikä siinä ole rajoituksia käyttöjärjestelmälle tai taustalla olevalle laitteistolle.
• Se on erittäin turvallinen agentittoman suunnittelunsa ja OpenSSH-tietoturvaominaisuuksien käytön ansiosta.
• Ansiblen oppimiskäyrä on sujuva, ja sitä tukevat perusteellinen dokumentaatio sekä helposti opittava rakenne ja konfigurointi.

Nämä vahvuudet, erityisesti verrattuna muihin vaihtoehtoja Ansiblelle, auttavat selittämään sen nopeaa käyttöönottoa. Ennen sen asentamista on hyödyllistä ymmärtää, miten projekti kehittyi.

Ansiblen historia

Tässä ovat Ansiblen historian tärkeät maamerkit:

• Ansible-projekti alkoi helmikuussa 2012. Sen kehitti alun perin Michael DeHaan, Cobblerin ja Funcin (Fedora Unified Network Controller) luoja.
• Alun perin AnsibleWorks Inc:ksi kutsuttu Ansiblea rahoittanut yritys siirtyi RedHatin omistukseen vuonna 2015, ja myöhemmin se siirtyi RedHatin ohella... IBM sateenvarjo.
• Nykyään Ansible sisältyy jakeluihin, kuten Fedora Linux, RHEL, CentOS ja Oracle Linux.

Ansiblessa käytetyt tärkeät termit

Seuraavat termit esiintyvät tässä Ansible-opetusohjelmassa ja ne kannattaa tietää ennen aloittamista:

Mahdollinen palvelin

Kone, jolle Ansible on asennettu ja josta kaikki tehtävät ja pelikirjat suoritetaan.

Moduulit

Moduuli on komento tai joukko vastaavia Ansible-komentoja, jotka on tarkoitettu suoritettavaksi asiakaspuolella.

Tehtävä

Tehtävä on osa, joka koostuu yhdestä suoritettavasta proseduurista.

Rooli

Tapa järjestää tehtäviä ja niihin liittyviä tiedostoja, jotta niitä voidaan kutsua myöhemmin esiin pelisuunnitelmassa.

tosiasia

Asiakasjärjestelmän globaaleista muuttujista gather_facts-operaation kautta noudetut tiedot.

Inventaario

Tiedosto, joka sisältää tietoja Ansible-asiaspalvelimista. Se määritellään myöhemmissä esimerkeissä hosts-tiedostona.

Pelaa

Pelikirjan toteutus.

Käsittelijä

Tehtävä, jota kutsutaan vain, kun ilmoittaja on läsnä.

Ilmoittaja

Tehtävälle osoitettu osio, joka kutsuu käsittelijää, jos tuloste muuttuu.

tag

Tehtävälle asetettu nimi, jota voidaan myöhemmin käyttää vain kyseisen tehtävän tai tehtäväryhmän suorittamiseen.

Mahdollinen asennus Linuxissa

Kun olet punninnut vaihtoehtojasi ja päättänyt ottaa Ansiblen käyttöön, seuraava vaihe on asentaa se järjestelmääsi. Seuraava lyhyt ohje kattaa asennuksen suosituimpiin Linux jakaumat.

Asenna Ansible Centos/RedHat-järjestelmiin

Vaihe 1) Asenna EPEL-repo.

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

Vaihe 2) Asenna ansible-paketti.

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

Asenna mahdollinen päälle Ubuntu/Debian-järjestelmät

Vaihe 1) Suorita päivitys paketeille.

$ sudo apt update

Vaihe 2) Asenna software-properties-common-paketti.

$ sudo apt install software-properties-common

Vaihe 3) Asenna ansiblen henkilökohtainen pakettiarkisto.

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

Vaihe 4) Asenna ansible.

$ sudo apt update
$ sudo apt install ansible

Mahdolliset ad-hoc-komennot

Yksi yksinkertaisimmista tavoista käyttää Ansiblea on ad-hoc-komentojen avulla. Nämä ovat hyödyllisiä, kun haluat antaa komennon yksittäiselle palvelimelle tai palvelinryhmälle. Ad-hoc-komentoja ei tallenneta myöhempää käyttöä varten, mutta ne ovat nopea tapa olla vuorovaikutuksessa valitsemiesi palvelimien kanssa.

Tässä Ansible-opetusohjelmassa konfiguroidaan yksinkertainen kahden palvelimen isäntätiedosto, joka sisältää isäntätiedostot host1 ja host2.

Voit varmistaa, että isännät ovat tavoitettavissa Ansible-palvelimelta, antamalla komennon ping komento kaikissa isännissä.

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

Selitys:

1. Komennon tila, tässä tapauksessa SUCCESS
2. Isäntä, jolla komento suoritettiin
3. Komento, joka annetaan parametrilla -m, tässä tapauksessa ping
4. Parametrilla -i voit osoittaa hosts-tiedostoon.

Voit tarvittaessa antaa saman komennon myös yksittäiselle isännälle.

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

Selitys:

1. Limit-parametria voidaan käyttää komentojen antamiseen vain tietyissä isäntäkoneissa isäntätiedoston tiedostossa
2. Isännän nimi sellaisena kuin se on määritetty inventaariotiedostossa

Jos sinun täytyy kopioida tiedosto nopeasti useisiin kohteisiin, käytä kopiointimoduulia, joka on riippuvainen SCP:stä. Komento ja sen tuloste näyttävät seuraavilta:

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

Selitys:

1. Kopioi moduuli määritetty
2. Moduuliargumentit ovat tässä tapauksessa lähde absoluuttinen polku ja määränpää absoluuttinen polku.
3. Mahdollinen komentotulostus, joka heijastaa kopiokomennon onnistumista ja muita yksityiskohtia, kuten sha1- tai md5-tarkistussummat tiedoston eheyden tarkistukseen ja metatiedot, kuten omistaja, koko tai käyttöoikeudet. Paketin asentaminen useille palvelimille on vaivatonta. Ansiblessa on useita moduuleja, jotka ovat vuorovaikutuksessa käytettyjen asentajien kanssa, kuten yum, apt, dnf jne.

Seuraavassa esimerkissä asennat yum-moduulia sisältävän paketin kahteen CentOS-isäntään.

[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"
    ]
}

Selitys:

1. Tässä esimerkissä käytetään Yum-moduulia
2. Se määrittelee moduulin argumentit, ja tässä tapauksessa valitset paketin nimen ja sen tilan. Jos tila puuttuu esimerkiksi, paketti etsitään ja jos se löytyy, se poistetaan
3. Kun väri on keltainen, näet ansible-komennon tulosteen tila muuttuneena, mikä tarkoittaa tässä tapauksessa, että paketti on löydetty ja asennettu.
4. Ansiblen kautta annetun yum install -komennon tila. Tässä tapauksessa paketti ncdu.x86_64 0:1.14-1.el7 asennettiin.

Kaikkia yum-asennusohjelman vaihtoehtoja, kuten päivitystä, asennusta, uusinta versiota ja poistoa, voi tietenkin käyttää Ansiblen kautta.

Alla olevassa esimerkissä sama komento annetaan aiemmin asennetun ncdu-paketin poistamiseksi.

[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"
    ]
}

Selitys:

1. Yum-komennon tulos osoittaa, että paketti on poistettu.

Toinen Ansiblen olennainen ominaisuus on sen kyky kerätä tietoja järjestelmästä. Se kerää laitteisto-, ohjelmisto- ja versiotietoja ja tallentaa jokaisen arvon muuttujaan, jota voit käyttää uudelleen myöhemmin.

Kun tarvitset yksityiskohtaisia ​​tietoja järjestelmistä, joita Ansible muokkaa, asennusmoduuli kerää nämä tiedot järjestelmämuuttujista.

Ansible Playbooks

Ansible Playbooks ovat tapa lähettää komentoja etäjärjestelmiin skriptien avulla. Pelikirjat konfiguroivat monimutkaisia ​​järjestelmäympäristöjä ja lisäävät joustavuutta suorittamalla yhden skriptin yhtä tai useampaa järjestelmää vastaan. Ne toimivat enemmän konfigurointikielen kuin ohjelmointikielen tavoin.

Pelikirjan komennot käyttävät YAML-muotoa, joten syntaksia tarvitaan vain vähän, mutta sisennystä on noudatettava. Kuten nimestä voi päätellä, pelikirja on kokoelma pelikuvioita. Pelikirjan avulla voit määrittää tiettyjä rooleja joillekin isännille ja eri rooleja toisille, jolloin voit hallita useita palvelimia yhdessä tiedostossa.

Ennen kuin jatkamme käsikirjaesimerkkien parissa, on hyödyllistä määritellä tehtävä. Tehtävät ovat rajapinta Ansible-moduuleihin rooleille ja käsikirjoille.

Tarkastellaan nyt Ansible-pelikirjaa, jossa on yksi pelikuvio, joka sisältää useita tehtäviä, kuten alla on esitetty:

---

- hosts: group1
  tasks:
  - name: Install lldpad package
    yum:
      name: lldpad
      state: latest
  - name: check lldpad service status
    service:
      name: lldpad
      state: started

Yllä olevassa toimintaohjeessa hosts-tiedoston group1-isännät on tarkoitettu lldpad-paketin asennukseen yum-moduulin avulla. Asennuksen jälkeen luotu lldpad-palvelu käynnistetään sitten palvelumoduulin avulla, joka on enimmäkseen vuorovaikutuksessa systemd-ensemblen kanssa.

Selitys:

1. Ryhmä isäntiä, joilla pelikirja toimii
2. Yum-moduulia käytetään tässä tehtävässä lldpad-asennukseen
3. Huoltomoduulin avulla tarkistetaan, onko palvelu toiminnassa asennuksen jälkeen

Jokainen Ansible-peliopas toimii inventaariotiedoston kanssa. Inventaariotiedosto sisältää luettelon palvelimista, jotka on jaettu ryhmiin, mikä antaa paremman hallinnan yksityiskohtiin, kuten kunkin isännän IP-osoitteeseen ja SSH-porttiin.

Tämän esimerkkikäsikirjan inventaariotiedosto näyttää seuraavalta. Siinä on kaksi ryhmää, ryhmä1 ja ryhmä2, jotka molemmat sisältävät isäntä1:n ja isäntä2:n.

[group1]
host1 ansible_host=192.168.100.2 ansible_ssh_port=22
[group2]
host2 ansible_host=192.168.100.3 ansible_ssh_port=22

Selitys:

1. Ryhmän nimi
2. Isäntänimi, jossa on IP-osoite ja ssh-portti, tässä tapauksessa oletusarvo, 22.

Seuraava Ansible-pelin esimerkki sisältää kaksi pelikuviota kahdelle isäntäryhmälle. Ensimmäiselle ryhmälle, group1, SELinux on käytössä, ja kun se on käytössä, isäntänäyttöön tulee viesti.

Toisen ryhmän tapauksessa httpd-paketti asennetaan vain, jos ansible_os_family on RedHat ja ansible_system_vendor on HP.

ansible_os_family ja ansible_system_vendor ovat gather_facts-asetuksella kerättyjä muuttujia, ja niitä voidaan käyttää kuten tässä ehdollisessa esimerkissä.

---

- 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'

Selitys:

1. Esimerkki when-lauseesta, Tässä tapauksessa, kun käyttöjärjestelmän tyyppi on Debian. Ansible_os_family-muuttuja kerätään collection_facts-toiminnon kautta.
2. Tehtävän tulos on rekisteröity tulevaa käyttöä varten nimellä enable_selinux
3. Toinen esimerkki kun-lauseesta. Tässä tapauksessa isäntäkäyttäjälle näytetään viesti, jos SELinux oli todella käytössä aiemmin.
4. Toinen esimerkki kun-lauseesta, joka koostuu kahdesta säännöstä

Tehtävien lisäksi on olemassa myös erikoistehtäviä, joita kutsutaan käsittelijöiksi. Käsittelijällä on oltava yksilöllinen nimi koko pelikirjassa. Käsittelijät toimivat kuten tavalliset tehtävät, mutta käsittelijälle voidaan ilmoittaa muutoksista ilmoittajan kautta.

Jos käsittelijälle ei ilmoiteta pelikirjan suorituksen aikana, sitä ei suoriteta. Jos useampi kuin yksi tehtävä ilmoittaa käsittelijälle, se suoritetaan vain kerran kaikkien tehtävien valmistuttua.

Alla olevassa esimerkissä tietyllä tehtävällä on ilmoitusosio, joka kutsuu toista tehtävää. Jos ensimmäisen tehtävän tuloste muuttuu, kutsutaan käsittelijätehtävää. Yleinen esimerkki on määritystiedoston muuttaminen ja sitten kyseisen palvelun uudelleenkäynnistys.

---

- 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

Tässä tapauksessa, jos ensimmäinen tehtävä, ”sshd config file modify port”, muuttuu, eli portti ei ole jo 28675, porttia muutetaan ja tehtävä ilmoittaa muutoksesta samannimiselle käsittelijälle, joka käynnistää sshd-palvelun uudelleen.

Selitys:

1. Esimerkki ilmoittajasta
2. Esimerkki käsittelijästä

Ansible Rooleja

Suuria pelikirjoja (playbookeja) käytettäessä tehtävät on helpompi jakaa rooleihin. Roolit helpottavat myös työn uudelleenkäyttöä myöhemmin. Rooli on kokoelma tehtäviä, jotka voidaan siirtää pelikirjasta toiseen ja suorittaa itsenäisesti, tosin vain pelikirjatiedoston kautta.

Roolit tallennetaan erillisiin hakemistoihin ja ne noudattavat tiettyä hakemistorakennetta.

[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

Defaults-hakemistossa oleva YAML-tiedosto sisältää pelikirjan kanssa käytettävät oletusmuuttujat. Handlers-hakemisto tallentaa käsittelijät ja meta-hakemisto sisältää tietoja tekijästä ja rooliriippuvuuksista. Tasks-hakemisto sisältää roolin pääasiallisen YAML-tiedoston.

Testihakemisto sisältää esimerkki-YAML-käsikirjan ja esimerkki-inventaariotiedoston, ja sitä käytetään enimmäkseen testaukseen ennen varsinaisen roolin luomista.

vars-hakemisto sisältää YAML-tiedoston, jossa kaikki roolin käyttämät muuttujat on määritelty. Templates- ja files-hakemistot sisältävät roolin tehtävien käyttämät mallit ja tiedostot.

Voit luoda roolin hakemistopuun seuraavalla komennolla, jonka viimeinen parametri on roolin nimi:

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

Ansible toimii myös hyvin mallien kanssa ja käyttää Jinja2:ta mallinnuskielenään.

Seuraava esimerkki näyttää, miltä Jinja2-perusmalli näyttää ja miten sitä käytetään roolissa.

Suorituksen aikana, esimerkiksi riippuen siitä, missä konesalissa palvelimesi sijaitsee, voit valita useista nimipalvelimista, joista jokainen vastaa yhtä konesalia, käyttämällä muuttujaa resolver_ip_addresses.

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

options timeout:1
options attempts:5
options rotate

Tässä esimerkissä playbook-hakemisto määrittää useita muuttujia, mukaan lukien resolver_ip_addresses, joiden arvot vaihtelevat datakeskuksen mukaan.

- name: Set resolver for server
  template:
    src: dns.j2
    dest: /etc/resolv.conf
    group: root
    owner: root
    mode: "0644"
    tag: resolver

Selitys:

1. Käytettävän mallin nimi. Malli sijaitsee mallien hakemistossa roolipolussa
2. Mallilla korvattavan tiedostonimen kohdepolku asiakaspuolella.
3. Kohdetiedoston käyttöoikeudet

Roolitehtävillä voi olla myös tunnistekenttä, jolla on määritetty nimi. Useampi kuin yksi tehtävä voi käyttää samaa tunnistetta, ja kun suoritat pelisuunnitelman, voit määrittää tunnisteen, jotta vain tunnisteella merkityt tehtävät suoritetaan.

Ansible tapaustutkimus

Tässä osiossa analysoimme tapaustutkimusta keskeisestä Ansible-käsikirjasta, jolla on kolme roolia. Tavoitteena on antaa käytännön esimerkki tähän mennessä käsitellyistä käsitteistä. Joitakin tämän opetusohjelman aiempia esimerkkejä on mukautettu ja käytetty uudelleen tässä käsikirjassa.

Alla on käsikirjan hakemistorakenne. Käytetty YAML-tiedosto on 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

Pelikirjalla on kolme roolia. Resolver-rooli asettaa palvelimille tietyn nimipalvelimen kopioimalla tiedoston /etc/resolv.conf-kohteeseen. Httpd-rooli asentaa httpd-paketin yum-moduulilla ja kolmas rooli ottaa SELinuxin käyttöön ja ilmoittaa sisäänkirjautuneelle käyttäjälle järjestelmän uudelleenkäynnistyksestä. Jokainen rooli luotiin ansible-galaxy-komennolla.

Ratkaisijarooli, main.yml-tehtävä:

Httpd-rooli, main.yml-tehtävä:

Selinux-rooli, main.yml-tehtävä:

Alla on p4.yml-tiedoston käsikirja. Se toimii kaikilla isännillä, ellei komentorivillä toisin määritetä, toimii pääkäyttäjänä portissa 22 (SSH), kerää tietoja ennen roolien suorittamista ja suorittaa kaikki kolme roolia. Kukin rooli voidaan suorittaa itsenäisesti määrittämällä sen tunniste ansible-playbook-komentorivillä –t-parametrilla.

---

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

Voit sitten ajaa p4.yml-käskykirjan kahdella isännällä ja tulkita tulosteen. Sama komento voidaan ajaa –check-parametrilla testiajoa varten ja -k-parametrilla, kun haluat käyttää salasanatodennusta.

Selitys:

1. Ansible-playbook-komento, joka suorittaa p4.yml:n
2. Playbook ohittaa SELinux-roolin, koska se on jo käytössä.
3. Ansible havaitsi, että httpd-paketti on jo asennettu, joten se palauttaa ok.
4. Resolver asetettiin, ja roolinratkaisun tila muutettiin.

Ansible Commands -huijauslehti

Asenna EPEL repo Centos/RHEL-järjestelmiin

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

Asenna mahdollinen paketti Centos/RHEL-järjestelmiin

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

Päivitä paketit Debianissa/Ubuntu järjestelmät

$ sudo apt update

Asenna paketti software-properties-common Debianille/Ubuntu järjestelmät

$ sudo apt install software-properties-common

Asenna mahdollinen henkilökohtainen pakettiarkisto Debianille/Ubuntu järjestelmät

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

Asenna mahdollinen Debianille/Ubuntu järjestelmät

$ sudo apt update
$ sudo apt install ansible

Ongelma a ping komento kaikille palvelimille, jotka on määritelty hosts-nimisessä inventaariotiedostossa

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

Ongelma a ping komento vain host2:lla

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

Kopioi tiedosto "testfile" kaikille inventaariotiedoston koneille

[root@ansible-server test_ansible]# ansible -i hosts all -m copy -a "src=/root/test_ansible/testfile dest=/tmp/testfile"

Asenna ncdu-paketti kaikkiin koneisiin

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

Poista ncdu-paketti kaikista isännistä

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

Luo hakemistorakenne roolille nimeltä role1.

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

Kuivakäyttöinen p4.yml pelikirja

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

Suorita p4.yml playbook salasanatodennuksella kaikille isännille

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

UKK