Hvordan bruke svarbare variabler og hvelv

[ware_item id=33][/ware_item]

Hvordan ExpressVPN bruker Ansible


Hvordan vi bruker Ansible mye på ExpressVPN

Utviklingsteamene våre jobber uavhengig, det vil si at et team eier sitt produkt i hele sin livssyklus. Dette oppsettet betyr at vår forståelige forståelse kommer fra en samling av kunnskap fra mange forskjellige team i selskapet snarere enn en sentralisert gruppe som administrerer Ansible.

En desentralisert arbeidsstokk gir teamene våre mye fleksibilitet og mobilitet, men legger også press på enkeltpersoner til å vite mye om mange verktøy.

For å gjøre det enklere å dele kunnskap og bruke verktøy riktig, har vi bestemt oss for å standardisere hvordan vi bruker Ansible til konfigurasjonsadministrasjon og serveroperasjoner.

Denne bloggen dekker leksjonene vi har lært i vår skala, refleksjoner rundt måten vi jobber på og hvordan vi administrerer Ansible i en slik sammenheng.

Ansvarlig dokumentasjon

La oss komme inn på det! Dokumentasjonen for Ansible overlater noen ting å være ønsket, spesielt når det kommer til ende-til-ende-dokumentasjon (som hvordan kommer du deg fra punkt A til punkt Z?).

Noen spørsmål vi regelmessig møter er: "Hvordan fungerer variabel forrang?" Og "Hvordan passer Ansible Vault inn?"

Begge problemene er dokumentert veldig uavhengig (her og her), og siden Svarbare variabler har et veldig fint avsnitt om presedens eksplisitt, men krysset mellom de to får bare en kort omtale. Problemet er at det ikke er noen koblinger mellom dokumentasjonen om variabler og hvelv, noe som gir inntrykk av at brukeren er på brukeren for å finne ut hvordan de to skjærer hverandre inn..

Så i dag skal vi prøve å dekke krysset mellom variabler og hvelv og beste praksis.

Hva du kan bruke Ansible Vault-filer til

Oppsummert: I Vault-dokumentasjonen fremgår det Du kan i hovedsak kryptere hva som helst i Ansible-mappen til en Vault-fil, og Ansible vil prøve å "snedig" dekryptere det hver gang et spill inneholder disse filene. Hu h. Kul!

Dokumentasjonen om variabler nevner ikke noe om Vault-filer i det hele tatt, noe som er underlig da Vault ble designet for Variable-filer. Så hvordan passer de sammen? Det er viktig å merke seg det Selve filfiler har ingen spesiell betydning for variabel prosessering eller forrang, så det er mye fleksibilitet. Men potensielt gir dette deg ikke nok informasjon om hvordan du bruker den riktig.

Hvordan ikke bruke AnsibleDu gjør det feil.

Ta dette eksempelet på en enkel Ansible-mappe:

.
├── gruppe_vars
├── ├── alle
Produksjon
│ └── iscenesettelse
├── ansible.cfg
├── inventar
└── playbook.yml

Ved første øyekast ser dette oppsettet bra ut; dette ville være en relativt vanlig struktur å produsere hvis du skulle lese dokumentasjonen. En observatør kan potensielt anta at iscenesettelses- og produksjonsfilene i group_vars er hylster, men det er ikke nødvendigvis sant, noe som i seg selv er et problem.

Nå kan ikke filen "alle" være en Vault-fil siden du (forhåpentligvis) krypterte iscenesettelses- og produksjonshvelvfiler med forskjellige passord. Men det betyr også at gruppen_vars-filen for miljøer trenger å inneholde en blanding av hemmeligheter og ikke-hemmeligheter siden du er begrenset til en fil per miljø.

På grunn av dette - og hvis du ekstrapolerte litt etter å ha lest introduksjonen til Vaults i Ansible-dokumentasjonen - opprettet du sannsynligvis produksjons- / iscenesettingshvelvene ved å kopiere innholdet i "alle" til å begynne med og deretter endre dem.

Det betyr at "alt" -filen din kan se slik ut:

database:
brukernavn: default_user
passord: falsk

super_important_var_that_should_be_one: 1

Og produksjonshvelvfilen din kan se slik ut:

database:
brukernavn: produsent
passord: supersecretpasswordnoonecansee

super_important_var_that_should_be_one: 1

(Ikke bekymre deg, dette er ikke vårt egentlige produksjonspassord! Vi har dobbeltsjekket.)

Ovennevnte er farlig av grunner som kanskje ikke er åpenbare. For eksempel kan du savne å endre en standard for produksjon, og / eller "alle" -filen kan til og med bli kalt feil og ikke inkludert i det hele tatt! (Dette er den viktigste årsaken til strømbruddet vi hadde forrige uke.)

Beste praksis: Hvordan bruke Ansible Vault-filer trygt

Som det fremgår av siden med beste fremgangsmåter, skjuver det å lage en fil til en Vault-fil innholdet i filen, så de har en stor ulempe: Du kan ikke søke etter hvilke variabler som er i Vault-filen uten å dekryptere dem eksplisitt. Dette systemet betyr at den som ser på din Ansible-konfigurasjon ikke har noen anelse om hva som er inni disse filene uten også å vite Vault-passordet (forferdelig for kodevisninger!). Derfor anbefaler vi å legge så få variabler som mulig i Vault-filer. (Med andre ord, bare legg hemmeligheter i Vault-filene!)

Så la oss se på en struktur som vil gjøre det lettere å ikke skyte deg selv i foten:

.
├── gruppe_vars
├── ├── alle
│ │ └── vars.yml
Produksjon
│ │ ├── vars.yml
└── │ └── hvelv.yml
│ └── iscenesettelse
└── └── hvelv.yml
├── ansible.cfg
├── inventar
└── playbook.yml

Dokumentasjonen for beste fremgangsmåter anbefaler også å bruke et "lag med indireksjon", noe som betyr at du bør templere alle variablene i hvelvfilen til variablene det er referert til i spillbøkene dine. Det anbefaler også at du prefikserer hvelvvariablene med "hvelv" som betyr at all / vars.yml kan se ut som:

database:
brukernavn: default_user
passord: “{{vault_database_password}}”

super_important_var_that_should_be_one: 1

Produksjonen din / vars.yml ser slik ut:

database:
brukernavn: produsent

Og din produksjons- / vault.yml-fil skal bare inneholde denne:

vault_database_password: supersecretpasswordnoonecansee

Denne reviderte strukturen har et par fordeler. For det første, hvis du gjør kodevurderinger (vær så snill!), Betyr det at anmelderne dine kan se hva du har endret, sammen med det du har lagt til og fjernet i (nesten hele) konfigurasjonen din. Med denne strukturen vil leserne ikke bare se en full filendring på et hvelv som må dekrypteres manuelt, lagres på disk og skilles med den tidligere versjonen.

Og enda viktigere, Ansible vil mislykkes, selv med å gjengi varselen hvis den mangler vault_database_password Variabel i Vault, som vil redde deg fra minst en rekke problemer du kan støte på hvis du ikke holder nøye oversikt over Vault-filene dine.

Hvis du holder deg til dette mønsteret, uansett om det er en vertsgruppe i et miljø, et fullstendig miljø som du setter variabler for, eller til og med “alt” -mappen, vil jevnaldrende aldri bli forvirret om hva som er og ikke er i hvelvet.

Det er alt for nå, vi håper det har vært til nytte for deg!

Hvordan bruke svarbare variabler og hvelv
admin Author
Sorry! The Author has not filled his profile.