Sådan bliver du DevOps-ingeniør på seks måneder eller mindre, del 2: Konfigurer

Foto af Reto Simonet på Unsplash

BEMÆRK: dette er del 2 af en flerdelsserie. For del 1 skal du klikke her.

Hurtig opsamling

I del 1 argumenterede jeg for, at DevOps Engineering har til opgave at bygge fuldt automatiserede, digitale rørledninger, der flytter kode fra en udviklers maskine til produktion.

For at udføre dette job kræver nu en solid forståelse af de grundlæggende elementer, der er afbildet her:

DevOps Fundamentals

samt en god forståelse af værktøjer og færdigheder (se næste grafik nedenfor), der bygger på disse grundlæggende elementer.

En hurtig påmindelse: Dit mål er at lære ting i blåt først, venstre til højre, efterfulgt af tingene i lilla, venstre til højre. Der er i alt 6 læringssøjler, en pr. Måned.

OK, tilbage til vores emne. I denne artikel dækker vi den første fase af vores digitale pipeline: Konfigurer.

Fokus på Konfigurer scenen

Oversigt

Hvad sker der i konfigurationsfasen?

Da den kode, vi opretter behovsmaskiner til at køre på, bygger Configure-scenen faktisk den infrastruktur, der kører vores kode.

Tidligere var levering af infrastruktur en lang, arbejdskrævende, fejlagtig prøvelse.

Nu, fordi vi har vores fantastiske sky, kan all provisionering udføres med et klik på en knap. Eller i det mindste mange klik.

Det viser sig, at klikknapper for at udføre disse opgaver er en dårlig idé.

Hvorfor?

Fordi knapklikning er

  1. fejl udsat (mennesker laver fejl),
  2. ikke versioneret (klik kan ikke gemmes i git),
  3. ikke gentagne (flere maskiner = mere klik),
  4. og ikke testbar (ingen idé om, hvis mine klik rent faktisk vil fungere eller ødelægge ting).

Tænk for eksempel på alt det arbejde, der kræves for at skaffe dit dev-miljø ... så det int-miljø ... så QA ... derefter iscenesættelse ... derefter prod i USA ... derefter prod i EU ... Det bliver meget trættende, meget irriterende, meget hurtigt.

Derfor er der brug for en ny måde. Denne nye måde er infrastruktur-som-kode, og det er det, dette konfigurationsfase handler om.

Som bedste praksis kræver infrastruktur-som-kode, at uanset arbejde, der er nødvendigt for at tilvejebringe databehandlingsressourcer, skal det kun udføres via kode.

BEMÆRK: med "databehandlingsressourcer" mener jeg alt, hvad der er nødvendigt for korrekt at køre en applikation i prod: computere, opbevaring, netværk, databaser osv. Derfor navnet "infrastruktur-som-kode."

Yderligere betyder det, at i stedet for at klikke på vores vej gennem vores infrastrukturudvikling, vil vi i stedet

  1. skriv den ønskede infrastrukturtilstand i Terraform,
  2. gem det i vores kildekodekontrol,
  3. gå gennem en formel Pull Request-proces for at anmode om feedback,
  4. test det,
  5. udføre for at give alle de nødvendige ressourcer.

Hvorfor dette og ikke det?

Nu er det åbenlyse spørgsmål: ”Hvorfor Terraform? Hvorfor ikke kok eller marionet eller Ansible eller CFEngine eller Salt eller CloudFormation eller $ {whatever}? ”

Godt spørgsmål! Tønder med virtuel blæk er spildt, som diskuterer netop dette spørgsmål.

Kort sagt, jeg synes du skal lære Terraform fordi

  1. Det er meget trendy, derfor er jobmulighederne rigelige
  2. Det er noget lettere at lære end andre
  3. Det er tværplatform

Nu kan du vælge en af ​​de andre og stadig have succes? Absolut!

SIDEBEMÆRKNING: dette rum udvikler sig hurtigt og er ret forvirrende. Jeg vil tage et par minutter på at tale om noget nyere historie, og hvor jeg ser ting udvikle sig.

Traditionelt er ting som Terraform og CloudFormation blevet brugt til at levere infrastruktur, mens ting som Ansible bruges til at konfigurere det.

Du kan tænke på Terraform som et værktøj til at skabe et fundament, Ansible til at lægge huset på toppen, og så bliver applikationen implementeret, uanset hvor du ønsker det (kan f.eks. Også være Ansible).

Sådan tænker du på disse værktøjer

Med andre ord opretter du dine VM'er med Terraform og bruger derefter Ansible til at konfigurere serverne såvel som potentielt implementere dine applikationer.

Traditionelt (!) Spillede disse ting sammen.

Ansible kan dog gøre meget (hvis ikke alt), som Terraform kan gøre. Det modsatte er også mest sandt.

Lad det ikke forstyrre dig. Bare ved, at Terraform er en af ​​de mest dominerende spillere i infrastrukturen-som-kode-rummet, så jeg anbefaler på det kraftigste, at du starter der.

Faktisk er Terraform + AWS ekspertise et af de hotteste færdigheder, der erhverves lige nu!

Hvis du dog vil udskyde Ansible til fordel for Terraform, skal du stadig vide, hvordan du konfigurerer et stort antal servere programmatisk, ikke?

Ikke nødvendigvis!

Uændelige implementeringer

Faktisk forudsiger jeg, at konfigurationsstyringsværktøjer som Ansible vil falde i betydning, mens infrastrukturleveringsværktøjer som Terraform eller CloudFormation vil stige i betydning.

Hvorfor?

På grund af noget, der kaldes "uforanderlige implementeringer."

Kort sagt, uforanderlige implementeringer refererer til praksis med aldrig at ændre din implementerede infrastruktur. Med andre ord er din installationsenhed en VM- eller en Docker-container, ikke et stykke kode.

Så du distribuerer ikke kode til et sæt statiske virtuelle maskiner, du distribuerer hele VM'er med koden, der allerede er bagt i.

Du ændrer ikke, hvordan VM'erne er konfigureret, du distribuerer nye VM'er med den ønskede konfiguration på plads.

Du laver ikke patch-maskiner, du implementerer nye maskiner, der allerede er lappet.

Du kører ikke et sæt VM'er i dev og et andet sæt VM'er i prod, de er alle de samme.

Faktisk kan du med sikkerhed deaktivere al SSH-adgang til alle prod-maskiner, fordi der ikke er noget at gøre der - ingen indstillinger, der skal ændres, ingen logfiler at se på (mere om logfiler senere).

Du får mit punkt.

Når det bruges korrekt, er dette et meget kraftfuldt mønster, og det vil jeg varmt anbefale!

BEMÆRK: Uændelige implementeringer kræver, at konfigurationen er adskilt fra din kode. Læs manifestet 12 Factor App, der detaljerede dette (og andre fantastiske ideer!). Dette er en must-read for DevOps-udøvere.

Afkoblingen af ​​kode fra config er super vigtig - du ønsker ikke at distribuere hele applikationsstakken hver gang du roterer dine databaseadgangskoder. Sørg i stedet for, at apps trækker det fra en ekstern konfigurationslager (SSM / Consul / osv.)

Endvidere kan du nemt se, hvorledes, med hensyn til fremkomsten af ​​uforanderlige implementeringer, begynder værktøjer som Ansible at spille mindre af en fremtrædende rolle.

Årsagen er, at du kun behøver at konfigurere en server og distribuere den en hel masse gange som en del af din autoskaleringsgruppe.

Eller, hvis du laver containere, ønsker du bestemt uforanderlige implementeringer næsten pr. Definition. Du ønsker ikke, at din dev-container skal være forskellig fra din QA-container, og at den er forskellig fra prod.

Du vil have den nøjagtige samme beholder på tværs af alle dine miljøer. Dette undgår konfigurationsdrift og forenkler roll-backs i tilfælde af problemer.

Containere til side, for de mennesker, der lige er begyndt, er levering af AWS-infrastruktur ved hjælp af Terraform en lærebog DevOps-mønster og noget, du virkelig har brug for at beherske.

Men vent ... hvad hvis jeg skal se på logfiler for at fejlfinde et problem? Nå, du logger ikke ind i maskinerne for at se på logfiler mere, du vil i stedet se på den centraliserede loggeinfrastruktur for alle dine logfiler.

Faktisk skrev en smuk fyr allerede et detaljeret indlæg om, hvordan man implementerer en ELK-stak i AWS - give den en læsning, hvis du vil se, hvordan det foregår i praksis.

Igen kan du deaktivere fjernadgang helt og have det godt med at være mere sikker end de fleste derude!

Hvordan du er garanteret at føle dig med uforanderlige implementeringer

For at opsummere begynder vores fuldautomatiske “DevOps” -rejse med at stille de computervarer til rådighed, der er nødvendige for at køre vores kode - Configure stage. Og den bedste måde at opnå dette er via uforanderlige implementeringer.

Endelig, hvis du er nysgerrig efter, hvor nøjagtigt du skal starte, er Terraform + AWS combo et solidt sted at begynde din rejse!

Det hele kommer til scenen "Konfigurer".

Del 3, "Version" er her!