Share
Dette er del to av en todelt veiledning på Ansible. Del ett er her. I denne delen lærer du om roller (ansibels byggeblokker), variabler, sløyfer, hvordan du bruker roller i spillbøker og hvordan du organiserer roller i en katalogstruktur.
Når du administrerer titalls, hundrevis eller flere servere, må du trolig at mange av dem må konfigureres på samme måte. Ulike grupper av servere som webservere eller databaseservere vil kreve sin egen spesielle konfigurasjon, men kan også dele annen felles funksjonalitet. Det er selvfølgelig mulig å bare kopiere oppgaver rundt, men det blir gammelt veldig fort når det gjelder en komplisert infrastruktur.
Ansible roller er billetten. Lekebøker kan inkludere roller. Roller kan avhenge av andre roller, og Ansible best practices anbefaler gruppering verter i lagerfilen din basert på deres roller. Roller er ryggraden av seriøs ansettelsesstyrt infrastruktur. Som vanlig begynner jeg med et eksempel og introduserer mange av rollens evner gjennom eksemplet.
Jeg liker aliaser og skall fungerer mye fordi jeg ikke kan huske alle de banebrytere og alternativer for hver kommando, og også fordi det sparer mye skriving. Jeg liker også å ha noen verktøy som htop og tmux på hver server jeg logger på.
Her er en fil som inneholder noen av mine favorittaliaser og funksjoner. Jeg kaller det '.gigirc'. Forresten, hvis du noen gang lurte på hva 'rc'-suffikset står for i alle de rc-filene, står det for' Run Commands '.
alias sv = "sudo vim" alias py = "python" alias pi = "pip installasjon" # Katalogoppføring i et fint format alias lla = "ls -lAGh" # Finn nullstørrelse filer alias lsz = "finn. størrelse 0 -exec ls \; " # Fjern alle * .pyc-filer rekursivt alias rmpyc = "find. -Name" * .pyc "-print0 | xargs -0 rm" # Diskbruk som også sorterer resultatene etter størrelse og lagrer til en fil alias dus = "du - Pscmx * | sort -nr | tee disk_usage.txt "alias g =" git "alias gci =" git commit -a "alias gcia =" git commit -a -amend "alias gb =" git filial "alias gbd =" git grenen -D "alias gco =" git checkout "alias gpu =" git pull -rebase "alias gg =" git grep -i "alias gs =" git status "alias gd =" git diff "alias gl =" git logg --online "# Vis alle usporte filer og kataloger i gjeldende dir alias ng =" git clean -n -d. " # Hente og spore fjerngrensefunksjon gfr git checkout - spor -b $ 1 opprinnelse / $ 1 # Opprett ekstern git-grenen (og lokal også) fra hovedfunksjonen gbr gco master gb $ 1 g push -u opprinnelse $ 1
La oss definere en rolle som heter 'felles' som lager en bruker som heter 'gigi', legger til en offentlig ssh-nøkkel, kopierer '.gigirc'-filen og legger til en linje på slutten av' ~ / .bashrc 'som kjører denne filen og til slutt installerer de vanlige pakkene vim, htop og tmux (definert i 'vars / main.yml-filen').
Jeg vil introdusere en mye av nye ting her: fire forskjellige moduler, variabler og looper. Også roller er vanligvis spredt over flere filer i en standard katalogstruktur. Jeg skal vise deg et par filer og deretter forklare om katalogstrukturen. Her er filen 'oppgaver / main.yml':
Accentsconagua
--- - navn: Opprett en bruker som heter gigi bruker: navn = gigi - navn: Legg til offentlig nøkkel authorized_key: user = gigi key = "oppslag ('fil', '~ / .ssh / id_rsa.pub') : Kopier .gigirc-filen til hjemmekatalogen til den nye brukeren gigi kopi: src = ~ / .gigirc dest = / home / gigi / .gigirc eier = gigi group = gigi modus = 0644 - navn: Kjør .gigirc fra .bashrc lineinfile: dest = / home / gigi / .bashrc line = "kilde / home / gigi /.gigirc" - navn: Installer vanlige pakker apt: name = item state = installert update_cache = true force = yes with_items: COMMON_PACKAGES Og her er filen vars / main.yml som inneholder definisjonen av "COMMON_PACKAGES" -variabelen som brukes til å angi hvilke vanlige pakker som skal installeres.
--- COMMON_PACKAGES: - vim - htop - tmux
Brukermodulen kan administrere brukerkontoer. Her bruker jeg den til å lage brukerens "gigi".
Den authorized_key-modulen er for å legge til / fjerne SSH-autoriserte nøkler. Her bruker jeg den til å legge til min offentlig nøkkel for brukeren 'gigi'.
Lineinfile-modulen kan brukes til å erstatte eller legge til enkeltlinjer i en fil. I dette tilfellet bruker jeg den til å kilde '.gigirc-filen' fra '.bashrc', så alle de kule aliasene og funksjonene i '.gigirc' er alltid tilgjengelige i en hvilken som helst interaktiv sesjon.
Til slutt har apt-modulen tonnevis med muligheter for å administrere apt-pakker. Her installerer jeg bare noen vanlige pakker.
De COMMON_PACKAGES du ser i den siste oppgaven for å installere vanlige pakker er en variabel. Ansible lar deg bruke variabler som er definert nesten hvor som helst: spillebøker, inventar, roller, dedikerte filer og til og med miljøvariabler. Det er mye mer informasjon om variabler i dokumentasjonen.
Ansible er erklærende, så det støtter ikke eksplisitte looper. Men det er en overflod av with_xxx som lar deg utføre gjentatte operasjoner på en hvilken som helst struktur som en liste over brukere, pakker. eller linjer i en fil. Du kan også gjenta operasjoner til noen tilstand er sann eller få indeksen for gjeldende element. Ytterligere informasjon finnes i dokumentasjonen.
Her er hva en typisk rolle katalogstruktur kan se ut som:
felles
─ - håndtere
│ └── main.yml
├── meta
│ └── main.yml
├── oppgaver
│ └── main.yml
├── maler
└── vars
├── Debian.yml
├── Ubuntu.yml
└── main.yml
Filen 'oppgaver / main.yml' er hvor alle oppgavene er definert. Hver oppgave tilsvarer en Ansible-kommando som vanligvis bruker en modul.
Meta / main.yml-filen inneholder en liste over andre roller som den nåværende rollen avhenger av. Disse rollens oppgaver vil bli utført før den nåværende rollen, så det kan være sikkert at alle forutsetninger er oppfylt.
Filen 'handlers / main.yml' er hvor du beholder dine håndtere, som håndterer du så tidligere som starter Nginx etter installasjon.
Maler katalogen er hvor du holder Jinja2 maler av konfigurasjon og andre filer som du vil fylle ut og kopiere til målsystemet.
Vars katalogen inneholder ulike variabler og kan betinget inneholde forskjellige verdier for forskjellige operativsystemer (svært vanlig bruk tilfelle).
Det er viktig å merke seg at Ansible er veldig fleksibel og du kan sette noe nesten hvor som helst. Dette er bare en mulig struktur som gir mening for meg. Hvis du ser på andre folks katalogstrukturer, kan du se noe helt annet. Det er helt greit. Ikke vær redd. Ansible er ikke reseptivt, selv om det gir veiledning for beste praksis.
Roller gjør tung løft, men lekebøker er hvordan du egentlig gjør arbeid. Lekebøkene gifte seg med beholdningen og rollene og angir hvilke roller som skal spilles på hvilken vert. Her ser det ut som en lekebok med roller ser ut som:
--- - verter: alle roller: - roller / common
Kjører spillboken gir følgende utgang:
ansible-playbook -i verter playbook_with_roles.yml --sudo PLAY ********************************************* ************************************* TASK [setup] ******** ************************************************** ********* ok: [larry] ok: [moe] ok: [curly] TASK [roller / common: Opprett en bruker som heter gigi] ************** ******************* endret: [curly] endret: [moe] endret: [larry] TASK [roller / common: Legg til offentlig nøkkel] ****** ************************************* endret: [larry] endret: [curly] endret: [ moe] TASK [roller / common: Kopier .gigirc-filen til hjemmekatalogen til den nye brukeren gigi] *** endret: [moe] endret: [larry] endret: [curly] TASK [roller / common: Installer vanlige pakker ] ********************************* endret: [curly] => (item = [u'vim ' , u'htop ', u'tmux']) endret: [moe] => (item = [u'vim ', u'htop', u'tmux ']) endret: [larry] => du har det, du har det, du har det)] PLAY RECAP **************************************** ************************************ krøllete: ok = 5 endret = 4 un nås = 0 mislyktes = 0 larry: ok = 5 endret = 4 unreachable = 0 mislyktes = 0 moe: ok = 5 endret = 4 unreachable = 0 mislyktes = 0
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.
