Share
Dette er en del av en todelt opplæring på Ansible. I denne delen lærer du hva Ansible er, hvordan du installerer og konfigurerer det, og hvordan du installerer en lokal Vagrant-klynge for å teste den. Deretter vil du oppdage inventar, moduler, ad hoc kommandoer, spillebøker, løp strategier, blokker og hvelvet.
Ansible er et konfigurasjonshåndterings- og orkestreringsverktøy. Den opererer i samme domene som dukke, kokk og saltstack. Dette betyr at med Ansible kan du eksternt tilby en hel flåte av eksterne servere, installere og distribuere programvare på dem, og spore dem eksternt.
Ansible er et åpen kildekode-prosjekt implementert i Python og har en pluggbar arkitektur med moduler som kan administrere stort sett alle operativsystem, skymiljø og systemadministrasjonsverktøy eller rammeverk. Du kan også ganske enkelt utvide det med dine egne plugins hvis du vil gjøre noe spesielt.
En av de unike egenskapene til Ansible er at den ikke installerer programvare på administrerte maskiner. Den styrer maskinene eksternt over SSH. For å administrere en ekstern maskin må du bare sørge for at din offentlige SSH-nøkkel er i den autoriserte_keys-filen til maskinen.
Ansible kjører på en kontroll maskin og kan administrere servere som kjører et hvilket som helst operativsystem, men kontrollmaskinen kan ikke være en Windows-maskin for øyeblikket. Jeg bruker Mac OS X i denne opplæringen som kontrollmaskin.
Ansible krever Python 2.6 eller 2.7. For å installere det, skriv inn:
pip installasjonsansvarlig
På Mac OS X anbefales det å øke antall filhåndtak:
sudo launchctl limit maxfiles 1024 ubegrenset
Hvis du ser en feil som "For mange åpne filer", må du sannsynligvis gjøre det.
For å bekrefte at Ansible ble installert riktig, skriv inn ansible - versjon. Du bør se:
ansible 2.0.0.2 config file = konfigurert modul søkevei = Standard uten overstyringer
Versjonsnummeret kan være annerledes, selvfølgelig.
Ansible har en konfigurasjonsfil som lar deg kontrollere mange alternativer. Søkeordren er:
Du kan også overstyre bestemte innstillinger ved hjelp av individuelle miljøvariabler, som har forrang over konfigurasjonsfilen.
Sjekk ut dokumentasjonen Ansible for å lære om alle alternativene.
For å virkelig forstå kraften til Ansible trenger du en mengde servere å administrere. I denne veiledningen vil jeg bruke en Vagrant-klynge på 3 VM, men så langt som Ansible angår, er det bare noen verter som den trenger å administrere. For å lære mer om Vagrant, sjekk ut Introduksjon til Vagrant.
Først installerer du VirtualBox og Vagrant. Legg deretter følgende i en fil som heter 'Vagrantfile' i en arbeidsbok
Accentsconagua
# - * - modus: ruby - * - # vi: set ft = ruby: verter = "larry" => "192.168.88.10", "krøllet" => "192.168.88.11", "moe" => "192.168 .88.12 " Vagrant.configure (" 2 ") do | config | config.vm.box = "precise64" config.vm.box_url = "http://files.vagrantup.com/precise64.box" hosts.each gjør | navn, ip | config.vm.define navn gjør | maskin | machine.vm.network: private_network, ip: ip machine.vm.provider "virtualbox" do | v | v.name = navn sluttendens ende ende Skriv deretter inn vagrant opp. Vagrant vil skape tre virtuelle maskiner for deg, tilgjengelig som larry, krøllete og moe. For å bekrefte, skriv inn vagrant status. Du bør se:
Nåværende maskinstatus: larry running (virtualbox) curly running (virtuell boks) moe running (virtualbox) Dette miljøet representerer flere VMs. VMene er alle oppført ovenfor med deres nåværende tilstand. For mer informasjon om en bestemt VM, kjør "vagrant status NAME".
For å forsikre deg om at du kan SSH i cluster-vertene, skriv: vagrant ssh-config >> ~ / .ssh / config.
Nå kan du SSH til noen av dine virtuelle servere ved hjelp av vertsnavnet. For eksempel: ssh krøllete. Dette vil tillate Ansible å koble til klyngeserver over SSH uten problemer med brukernavn, passord eller nøkler.
Nå som vi har en klynge, må vi fortelle Ansible om det. Dette gjøres ved å bruke en lagerfil. Oppføringsfilen er en liste over vertsnavn organisert i grupper ved hjelp av et INI-filformat. Sett følgende i en fil som heter 'verter' i arbeidskatalogen din.
[morsom] larry [funnier] curly moe
Jeg legger larry i en gruppe som heter "morsom" og de andre vertene i en gruppe som heter "funnier". Den organisasjonen vil tillate oss å utføre handlinger på disse gruppene. Du kan også utføre handlinger på enkelte verter og på alle vertene.
Ansible har en veldig modulær og utvidbar arkitektur. Alle sine evner er organisert i moduler. Det er kjernemoduler og ekstra moduler. Hver modul representerer en kommando, og de fleste tar argumenter. Du kan bruke moduler direkte i ad hoc-kommandoer eller i spillbøker. Du kan lese om alle modulene i dokumentasjonen.
Det er på tide å få hands-on. Den enkleste måten å bruke Ansible er å kjøre ad hoc-kommandoer. Ad-hoc kommandoer bruker moduler. Formatet for en ad hoc-kommando er:
ansible
For å se om alle vertene i lageret ditt er oppe, kan du bruke pingmodulen (uten argumenter):
ansible all -i verter -m ping curly | SUCCESS => "changed": false, "ping": "pong" larry | SUCCESS => "changed": false, "ping": "pong" moe | SUCCESS => "changed": false, "ping": "pong"
Ansible har mange moduler for alle vanlige systemadministrasjonsoppgaver som filbehandling, brukeradministrasjon og pakkehåndtering, samt mange uvanlige oppgaver. Men hvis du ikke finner det du trenger eller bare føler deg mer komfortabel med vanlige skallkommandoer, kan du bruke skallmodulen direkte, inkludert rør. Følgende kommando trekker ut de interne og eksterne IP-adressene til alle verter:
ansible all -i verter -m shell -a '/ sbin / ifconfig | grep inet. * Bcast '"larry | Suksess | rc = 0 >> inet addr: 10.0.2.15 Bcast: 10.0.2.255 Maske: 255.255.255.0 inet addr: 192.168.88.10 Bcast: 192.168.88.255 Mask: 255.255.255.0 curly | Suksess | rc = 0 >> inet addr: 10.0.2.15 Bcast: 10.0.2.255 Maske: 255.255.255.0 inet addr: 192.168.88.11 Bcast: 192.168.88.255 Maske: 255.255.255.0 moe | Suksess | rc = 0 >> inet addr : 10.0.2.15 Bcast: 10.0.2.255 Maske: 255.255.255.0 inet addr: 192.168.88.12 Bcast: 192.168.88.255 Mask: 255.255.255.0
Ad-hoc kommandoer er fine når du vil raskt gjøre noe på en mengde verter, men den virkelige kraften til Ansible er i sine spillebøker. Lekebøker er YAML-filer der du definerer samlinger av oppgaver for å oppnå mål som forsyning, konfigurering, distribusjon og orkestrering av infrastrukturen din.
La oss ta en titt på hva en typisk spillebok ser ut før vi kommer ned til detaljene.
--- - Verktøy: funnier oppgaver: - navn: Installer Nginx apt: pkg = nginx state = installert update_cache = true notify: Start Nginx - navn: Installer Python 3 apt: pkg = python3-minimal state = installerte håndterer: - navn: Start Nginx service: navn = nginx state = startet
Spillelisten har en vertsavdeling der du spesifiserer verter fra beholdningsfilen. I dette tilfellet er gruppenavnet "morsomt". Deretter er det en oppgaveravdeling med to oppgaver som installerer Nginx og Python 3. Til slutt er det en håndteringsseksjon hvor Nginx startes etter installasjonen.
Du kjører spillbøker med ansible-playbook kommando. Du trenger fortsatt å oppgi en lagerfil og spillerboken du vil kjøre. Lagre spillelisten i en fil som heter "playbook.yml" i arbeidskatalogen. La oss gi det en sjanse:
ansible-playbook -i vertene playbook.yml PLAY *************************************** ********************************** TASK [setup] *********** ************************************************** ****** ok: [moe] ok: [curly] TASK [Installer Nginx] ************************************** ****************************** fatal: [moe]: FAILED! = "" endret ": false," failed ": true," msg ":" Kunne ikke låse apt for eksklusiv operasjon " dødelig: [curly]: FAILED! = "" endret ": false," failed ": true," msg ":" Kunne ikke låse apt for eksklusiv operasjon " PLAY RECAP ******************* ************************************************** krøllete: ok = 1 endret = 0 unreachable = 0 mislyktes = 1 moe: ok = 1 endret = 0 unreachable = 0 failed = 1
Å nei. Hva skjedde? Ansible gir en anstendig feilmelding her: "Kunne ikke låse apt for eksklusiv operasjon". Mange spillebøker vil kreve sudo privilegier. Denne spillboken er ikke et unntak. For å kjøre spillboken med sudo-privilegier, legger du bare til --sudo flagg:
ansible-playbook -i vertene playbook.yml --sudo PLAY ********************************************** ************************************* TASK [setup] ******** ************************************************** ********* ok: [curly] ok: [moe] TASK [Installer Nginx] ************************** ************************ endret: [moe] endret: [curly] TASK [Installer Python 3] * ************************************************** ***** endret: [moe] endret: [curly] RUNNING HANDLER [Start Nginx] ************************************** ********************* endret: [moe] endret: [curly] PLAY RECAP ***************** ************************************************** ** krøllete: ok = 4 endret = 3 unreachable = 0 mislyktes = 0 moe: ok = 4 endret = 3 unreachable = 0 mislyktes = 0
Ansible er idempotent, noe som betyr at hvis noe er allerede i ønsket tilstand, vil Ansible la det være alene. I utgangen av ansible-playbook, Du kan se hvilke oppgaver som lyktes eller feilet, og hvilke verter var endret.
La oss kjøre samme playbook igjen. Ingenting skal endres:
ansible-playbook -i vertene playbook.yml --sudo PLAY ********************************************** ************************************* TASK [setup] ******** ************************************************** ********* ok: [moe] ok: [curly] TASK [Installer Nginx] ************************** ********************************* ok: [curly] ok: [moe] TASK [Installer Python 3] * ************************************************** ***** ok: [curly] ok: [moe] PLAY RECAP ****************************************** *************************** krøllete: ok = 3 endret = 0 unreachable = 0 mislyktes = 0 moe: ok = 3 endret = 0 unreachable = 0 mislyktes = 0
Før Ansible 2.0, spiller utført på lineær måte, oppgave etter oppgave. Alle målverten utførte den første oppgaven. Først da alle vertene var ferdige med den første oppgaven, kunne de starte på den andre oppgaven.
Ansible 2.0 la til konseptet med løpestrategier. Det er for øyeblikket to strategier: den "lineære" strategien jeg har beskrevet ovenfor, som er standardstrategien, og den "gratis" strategien hvor verter er frie til å utføre oppgavene i spillboken, fortsatt i orden, men ikke i låstest med andre verter.
Dette kan være nyttig hvis hundrevis av verter trenger å laste ned flere filer fra noen FTP-servere. Den første verten kan fullføre nedlasting av den første filen og gå videre til neste, mens andre verter fortsatt er opptatt av å laste ned den første filen. Når andre verter kommer til å laste ned den neste filen, er den første verten allerede ferdig, og det er mindre påstand.
Den frie strategien virker overlegen i de fleste situasjoner. Du legger bare til en strategi: gratis nøkkelverdi-par i spillelisten.
- verter: all strategi: gratis oppgaver: ...
En annen ny Ansible 2.0-funksjon er blokker. Blokker lar deg gruppere oppgaver sammen. Dette er veldig nyttig hvis du har oppgaver som bare må utføres under en viss tilstand. Tidligere måtte du gjøre det for hver oppgave separat.
--- - verter: alle oppgaver: - feilsøking: msg = "Oppgave 1 her" når: ansible_distribution == 'Ubuntu' - feilsøking: msg = "Oppgave 2 her" når: ansible_distribution == 'Ubuntu' - feilsøking: msg = "Oppgave 3 her "når: ansible_distribution == 'Ubuntu'
Med blokker kan du gruppere alle disse feilsøkingsoppgaver sammen og sette "når" tilstanden på blokknivå.
- verter: alle oppgaver: - blokk: - feilsøking: msg = "Oppgave 1 her" - feilsøking: msg = "Oppgave 2 her" - feilsøking: msg = "Oppgave 3 her" når: ansible_distribution == 'Ubuntu'
Ansible kommuniserer med eksterne maskiner over SSH, men lekebøkene kan inneholde hemmeligheter som brukernavn, passord og API-nøkler. Siden du vanligvis lagrer spillebøker i kildekontrollsystemer som git, vil denne informasjonen være synlig for alle som har leseadgang.
Ansible hjelper med ansial-vault programmet som lar deg lage, redigere og rekey krypterte filer. Disse filene kan dekrypteres i fly når du kjører spillboken ved å gi et passord. Hvis du legger til --hvelv-be-pass flagg til ansible-playbook da det vil spørre deg om hvelv-passordet.
Alternativt kan du legge til --hvelv-passord-fil og ansible vil lese passordet fra filen din. Hvis du bruker passordfilen, må du ikke lagre den i kildekontrollen!
Nå kan du trygt lagre de krypterte filene i kildekontrollen og ikke bekymre deg for noen som finner hemmelighetene dine. Du må administrere ditt hvelvpassord nøye. Hvis du mister det, vil du ikke kunne dekryptere filene i hvelvet.
Ansible er et flott verktøy. Det er lett. Den kan brukes interaktivt med ad hoc-kommandoer, og det skaleres meget godt til massive systemer. Det har også mye fart og et stort samfunn. Hvis du klarer eller bare jobber med eksterne servere, vil du ha Ansible.
Hold deg innstilt for del to.
