Ansible handledning för nybörjare: Playbook, kommandon och exempel

Vad är Ansible?

Ansible är ett automations- och orkestreringsverktyg med öppen källkod för programvaruförsörjning, konfigurationshantering och programvarudistribution. Ansible kan enkelt köra och konfigurera Unix-liknande system samt Windows system för att tillhandahålla infrastruktur som kod. Den innehåller ett eget deklarativt programmeringsspråk för systemkonfiguration och hantering.

Ansible är populärt för sin enkelhet i installationen, användarvänligheten vad gäller anslutning till klienter, bristen på agent för Ansible-kunder och mångfalden av färdigheter. Den fungerar genom att ansluta via SSH till klienterna, så den behöver ingen speciell agent på klientsidan, och genom att skjuta moduler till klienterna exekveras modulerna sedan lokalt på klientsidan och utdata skjuts tillbaka till Ansible-servern.

Eftersom den använder SSH kan den mycket enkelt ansluta till klienter med SSH-nycklar, vilket förenklar hela processen. Klientdetaljer, som värdnamn eller IP-adresser och SSH-portar, lagras i filer som kallas inventeringsfiler. När du har skapat en inventeringsfil och fyllt i den kan ansible använda den.

Varför använda Ansible?

Här är några viktiga fördelar med att använda Ansible

• En av de viktigaste fördelarna med Ansible är att det är gratis att använda av alla.
• Det krävs inga speciella systemadministratörskunskaper för att installera och använda Ansible, och den officiella dokumentationen är mycket omfattande.
• Dess modularitet när det gäller plugins, moduler, inventeringar och spelböcker gör Ansible till den perfekta följeslagaren för att orkestrera stora miljöer.
• Ansible är mycket lätt och konsekvent, och inga begränsningar gällande operativsystemet eller underliggande hårdvara finns.
• Det är också mycket säkert på grund av dess agentlösa kapacitet och på grund av användningen av OpenSSH säkerhetsfunktioner.
• En annan fördel som uppmuntrar antagandet av Ansible är dess smidiga inlärningskurva som bestäms av den omfattande dokumentationen och lättläst struktur och konfiguration.

Ansibles historia

Här är viktiga landmärken från ansibles historia:

• I februari 2012 startade Ansible-projektet. Det utvecklades först av Michael DeHaan, skaparen av Cobbler and Func, Fedora Unified Network Controller.
• Från början kallades AnsibleWorks Inc, företaget som finansierade ansible-verktyget förvärvades 2015 av RedHat och flyttades senare, tillsammans med RedHat, under paraplyet av IBM.
• I nuet ingår Ansible i distributioner som Fedora Linux, RHEL, Centos och Oracle Linux.

Viktiga termer som används i Ansible

• Ansible server

  Maskinen där Ansible är installerad och från vilken alla uppgifter och spelböcker kommer att köras

• Modulerna

  I grund och botten är en modul ett kommando eller en uppsättning liknande Ansible-kommandon som är avsedda att köras på klientsidan

• uppgift

  En uppgift är ett avsnitt som består av en enda procedur som ska slutföras

• Roll

  Ett sätt att organisera uppgifter och relaterade filer för att senare kallas i en spelbok

• Faktum

  Information hämtad från klientsystemet från de globala variablerna med insamlingsfakta-operationen

• Lager

  Fil som innehåller data om de möjliga klientservrarna. Definierat i senare exempel som hosts-fil

• Spela

  Utförande av en lekbok

• Handler

  Uppgift som anropas endast om en anmälare är närvarande

• anmäla

  Sektion som tillskrivs en uppgift som anropar en hanterare om utdata ändras

• tagg

  Namn inställt på en uppgift som kan användas senare för att utfärda just den specifika uppgiften eller gruppen av uppgifter.

Ansible installation i Linux

När du har jämfört och vägt dina alternativ och bestämt dig för att välja Ansible, är nästa steg att ha det installerat på ditt system. Vi kommer att gå igenom installationsstegen i olika Linux distributioner, de mest populära, i nästa lilla handledning.

Installera Ansible på Centos/RedHat-system

Steg 1) Installera EPEL repo

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

Steg 2) Installera ett lämpligt paket

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

Installera ansible på Ubuntu/Debian-system

Steg 1) Utför en uppdatering av paketen

$ sudo apt update

Steg 2) Installera paketet software-properties-common

$ sudo apt install software-properties-common

Steg 3) Installera ett lämpligt personligt paketarkiv

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

Steg 4) Installera ansible

$ sudo apt update
$ sudo apt install ansible

Ansible ad-hoc kommandon

Ett av de enklaste sätten som Ansible kan användas på är att använda ad-hoc-kommandon. Dessa kan användas när du vill utfärda några kommandon på en server eller ett gäng servrar. Ad-hoc-kommandon lagras inte för framtida användningar men representerar ett snabbt sätt att interagera med önskade servrar.

För denna Ansible-handledning kommer en enkel värdfil för två servrar att konfigureras, som innehåller värd1 och värd2.

Du kan se till att värdarna är åtkomliga från den aktuella servern genom att utfärda ett ping-kommando på alla värdar.

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

Förklaring:

1. Status för kommandot, i det här fallet SUCCESS
2. Värd på vilken kommandot kördes
3. Kommandot som ges via parametern -m, i det här fallet ping
4. Med parametern -i kan du peka på hosts-filen.

Du kan bara utfärda samma kommando på en specifik värd om det behövs.

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

Förklaring:

1. Limit parameter kan användas för att utfärda kommandon endast på specifika värdar i värdens fil
2. Värdens namn enligt definitionen i inventeringsfilen

Om du behöver kopiera en fil till flera destinationer snabbt kan du använda kopieringsmodulen i ansible som använder SCP. Så kommandot och dess utdata ser ut som nedan:

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

Förklaring:

1. Kopieringsmodul definierad
2. Modulargument, i det här fallet, är källans absoluta sökväg och destinationens absoluta sökväg.
3. Ansible kommandoutdata som återspeglar framgången för kopieringskommandot och andra detaljer som sha1 eller md5 kontrollsummor för filintegritetskontroll och metadata som ägare, storlek eller behörigheter. Det är enkelt att ha ett paket installerat på ett gäng servrar. Ansible har flera moduler som interagerar med begagnade installatörer, som yum, apt, dnf, etc.

I nästa exempel får du reda på hur du installerar ett paket via yum-modulen på två Centos-värdar.

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

Förklaring:

1. Yum-modulen används i detta exempel
2. Den definierar modulargumenten, och i det här fallet kommer du att välja namnet på paketet och dess tillstånd. Om staten är frånvarande, till exempel, kommer paketet att genomsökas och om det hittas tas det bort
3. När den är färgad i gult, kommer du att se resultatet av det ansible kommandot med tillståndet ändrat, vilket i detta fall betyder att paketet hittades och installerades.
4. Status för kommandot yum install utfärdat via ansible. I det här fallet installerades paketet ncdu.x86_64 0:1.14-1.el7.

Naturligtvis kan alla yum-installationsalternativ användas via ansible, inklusive uppdatering, installation, senaste version eller ta bort.

I exemplet nedan utfärdades samma kommando för att ta bort det tidigare installerade ncdu-paketet.

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

Förklaring:

1. Utdata från kommandot yum visar att paketet togs bort.

En annan användbar och väsentlig funktion som ansible använder för att interagera med klientens server är att samla in lite fakta om systemet. Så den hämtar hårdvara, mjukvara och versionsinformation från systemet och lagrar varje värde i en variabel som kan användas senare.

Om du behöver detaljerad information om de system som ska modifieras via ansible kan nästa kommando användas. Installationsmodulen samlar fakta från systemvariablerna.

Ansible playbook-kommandon använder YAML-format, så det behövs inte mycket syntax, men indrag måste respekteras. Som namnet säger är en lekbok en samling pjäser. Genom en spelbok kan du utse specifika roller till vissa värdar och andra roller till andra värdar. Genom att göra det kan du orkestrera flera servrar i mycket olika scenarier, allt i en spelbok.

För att ha alla detaljer exakta innan vi fortsätter med Ansible playbook-exempel måste vi först definiera en uppgift. Dessa är gränssnittet till eventuella moduler för roller och spelböcker.

Låt oss nu lära oss Ansible playbook genom ett exempel med en playbook med en play, som innehåller flera uppgifter enligt nedan:

---

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

I ovanstående Ansible playbook-exempel är grupp1 av värdar i värdens fil inriktad på lldpad-paketinstallation med yum-modulen och efteråt startas tjänsten lldpad som skapats efter installationen med hjälp av servicemodulen som mest används för att interagera med systemd-ensemble.

Förklaring:

1. Grupp av värdar som spelboken kommer att köras på
2. Yum-modulen används i den här uppgiften för lldpad-installation
3. Servicemodulen används för att kontrollera om tjänsten är igång efter installationen

Varje möjlig spelbok fungerar med en inventeringsfil. Inventeringsfilen innehåller en lista över servrar indelade i grupper för bättre kontroll för detaljer som IP-adress och SSH-port för varje värd.

Inventeringsfilen du kan använda för detta Ansible-spelbokexempel ser ut som nedan. Det finns två grupper, namngivna grupp1 och grupp2 som var och en innehåller värd1 respektive värd2.

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

Förklaring:

1. Grupp namn
2. Värdnamn, med IP-adress och ssh-port, i detta fall standard, 22.

Ett annat användbart exempel på Ansible-spelboken som den här gången innehåller två spelningar för två värdar är nästa. För den första gruppen värdar, group1, kommer selinux att vara aktiverat. Om det är aktiverat visas ett meddelande på värdens skärm.

För den andra gruppen värdar installeras httpd-paketet endast om ansible_os_family är RedHat och ansible_system_vendor är HP.

Ansible_os_family och ansible_system_vendor är variabler som samlats in med alternativet gather_facts och kan användas som i detta villkorliga exempel.

---

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

Förklaring:

1. Exempel på när-satsen, I det här fallet när OS-typen är Debian. Variabeln ansible_os_family samlas in via funktionen gather_facts.
2. Uppgiftsutgången registreras för framtida användning, med dess namn enable_selinux
3. Ett annat exempel på när-klausulen. I det här fallet kommer ett meddelande att visas för värdanvändaren om SELinux verkligen var aktiverat tidigare.
4. Ett annat exempel på när-satsen som består av två regler

Förutom uppgifter finns det även vissa särskilda uppgifter som kallas hanterare. Hanterare måste ha ett unikt namn genom hela spelboken. Dessa fungerar på samma sätt som en vanlig uppgift men en hanterare kan meddelas via en anmälare.

Om en hanterare inte meddelas under körningen av spelboken kommer den inte att köras. Men om mer än en uppgift meddelar en hanterare kommer detta endast att köras en gång efter att alla uppgifter är klara.

I exemplet nedan kan du se hur en specifik uppgift har en aviseringssektion som anropar en annan uppgift. Om utdata från den första uppgiften ändras, kommer en hanteraruppgift att anropas. Det bästa exemplet är att ändra en konfigurationsfil och sedan starta om den specifika tjänsten.

---

- 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 det här fallet, om den första uppgiften, "sshd config file modify port" ändras, vilket betyder att om porten inte är 28675 i första hand kommer den att ändras och uppgiften kommer att meddela hanteraren med samma namn att köras , och det kommer att starta om sshd-tjänsten.

Förklaring:

1. Exempel på en anmälare
2. Exempel på en hanterare

Ansible roller

När man har att göra med omfattande spelböcker är det lättare att dela upp uppgifterna i roller. Detta hjälper också till att återanvända rollerna i framtiden. Roller är en samling uppgifter som kan flyttas från en playbook till en annan, kan köras oberoende men bara genom en playbook-fil.

Roller lagras i separata kataloger och har en speciell 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 innehåller en lista med standardvariabler som ska användas tillsammans med spelboken. Katalogen hanterare används för att lagra hanterare. Metakatalogen är tänkt att ha information om författaren och rollberoenden. I tasks-katalogen finns yaml-huvudfilen för rollen.

Testkatalogen innehåller ett exempel på en yaml playbook-fil och en exempel på inventeringsfil och används mest för teständamål innan den faktiska rollen skapas.

Vars-katalogen innehåller yaml-filen där alla variabler som används av rollen kommer att definieras. Katalogmallarna och katalogfilerna bör innehålla filer och mallar som kommer att användas av uppgifterna i rollen.

För att skapa katalogträdet för en roll bör du använda följande kommando med den sista parametern, rollnamnet:

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

Ansible fungerar också bra med mallar. Som ett språk för mallar använder det Jinja2.

I nästa exempel kommer du att ta reda på hur en grundläggande jinja2-mall ser ut och använda den i en roll.

Under körtiden, beroende på, låt oss säga i vilket datacenter din server är placerad, kan du välja från mer än en namnservrar, som var och en motsvarar ett datacenter, med hjälp av variabeln "resolver_ip_addresses."

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

options timeout:1
options attempts:5
options rotate

I det här exemplet, i playbook-katalogen, finns vissa variabler definierade, inklusive en variabel som heter resolver_ip_addresses med olika värden beroende på datacenter.

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

Förklaring:

1. Namn på mallen som ska användas. Mallen finns i mallar dir i rollsökvägen
2. Destinationssökväg för filnamnet som ska ersättas med mallen, på klientsidan.
3. Behörigheter för målfilen

Rolluppgifterna kan också ha ett taggfält, som har ett namn. Mer än en uppgift kan dela samma tagg. När du kör en lämplig spelbok kan du också ange taggen, så att dessa uppgifter kommer att utföras.

Ansible fallstudie

I det här avsnittet kommer vi att analysera en fallstudie av en viktig lekbok som har tre roller. Syftet med detta är att ge ett praktiskt exempel på vad vi pratade om tidigare. Några av exemplen som använts tidigare i denna Ansible-spelbok-handledning kommer att anpassas och användas i den här lekboken.

Nedan är katalogstrukturen för spelboken. Yaml-filen som kommer att användas kommer att vara 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

Spelboken har tre roller, en som kallas resolver som ställer in en specifik namnserver på servrarna genom att kopiera en fil från servern till destinationen /etc/resolv.conf. En annan kallas httpd, och den installerar httpd-paketet med yum-modulen, och den tredje aktiverar SELinux och meddelar den inloggade användaren att starta om systemet. Varje roll skapades med ansible-galaxy-kommandot.

Upplösarroll, main.yml-uppgift:

Httpd roll, main.yml uppgift:

Selinux roll, main.yml uppgift:

Nedan är spelboken p4.yml definierad. Det kommer att köras på alla värdar om inte annat anges i kommandoraden, det kommer att köras som root-användare på port 22 (SSH), det kommer att samla in fakta innan rollerna körs, och det kommer att köra alla tre roller som nämnts tidigare. Varje roll kan köras oberoende genom att ange taggen på kommandoraden ansible-playbook med parametern –t.

---

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

Kör spelboken p4.yml på två värdar och tolka resultatet. Samma kommando kan köras med parametern –check för en torrkörning. Om du vill använda lösenordsautentisering, använd parametern -k.

Förklaring:

1. Ansible-playbook-kommando som kör p4.yml
2. Playbook skipsSELinux-rollen eftersom den redan är aktiverad.
3. Ansible fann att httpd-paketet redan är installerat, så det returnerar ok.
4. Resolver ställdes in och roll resolver fick status ändrad.

Ansible Commands Cheat Sheet

Installera EPEL repo på Centos/RHEL-system

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

Installera ett lämpligt paket på Centos/RHEL-system

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

Utför en uppdatering av paketen på Debian/Ubuntu system

$ sudo apt update

Installera paketet software-properties-common på Debian/Ubuntu system

$ sudo apt install software-properties-common

Installera ett lämpligt personligt paketarkiv på Debian/Ubuntu system

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

Installera ansible på Debian/Ubuntu system

$ sudo apt update
$ sudo apt install ansible

Ge ett ping-kommando på alla servrar som definieras i inventeringsfilen med namnet värdar

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

Ge ett ping-kommando endast på host2

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

Kopiera filen "testfil" på alla värdar i inventeringsfilen

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

Installera ncdu-paketet på alla värdar

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

Ta bort ncdu-paketet på alla värdar

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

Bygg katalogstrukturen för rollen som heter roll1.

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

Torrkörning p4.yml spelbok

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

Kör p4.yml playbook med lösenordsautentisering för alla värdar

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

Sammanfattning

I en värld med teknik som ständigt förändras i snabb takt och samtidigt växer otroligt snabbt, måste systemadministratörer och devops-ingenjörer tänka på olika tillvägagångssätt för hur man automatiserar rutinuppgifter och orkestrerar stora pooler av servrar.

Medan det finns många alternativ till Ansible (Kock, Puppet) där ute som gör samma sak med vissa skillnader, Ansible lyckades höja sig över dem alla med sin enkelhet, förbättrade säkerhet och viktigast av sin smidiga inlärningskurva. På grund av dessa egenskaper och snabb användning av Ansible skapade vi en handledning full av exempel så att du kan få en ännu mer sömlös första erfarenhet av att arbeta med Ansible.

I denna Ansibles grundhandledning beskrev vi ansible och pratade lite om dess historia. Vi nämnde Ansibles starka sidor och de fördelar som ansible kan ge för automatisering och orkestrering av infrastrukturer av olika storlekar. Vi definierade de väsentliga ansible använda termerna och definierade strukturen för Ansible playbooks. Grundliga exempel åtföljde all information med detaljerade förklaringar.