Tillvägagångssätt IaC (Infrastructure as Code) består inte bara av koden som lagras i ett rep, utan också av människorna och processerna som omger den koden. Kan vi återanvända metoder från mjukvaruutveckling i hantering och beskrivning av infrastruktur? Det är bra att hålla denna idé i åtanke när du läser artikeln.

Detta är en avkodning av min presentation till DevopsConf 2019-05-28.

Presentationer och videor

Engelsk version
Rysk version
Torrkörning 2019-04-24 SpbLUG
Video(RU) från DevopsConf 2019-05-28
Video(RU) från DINS DevOps EVENING 2019-06-20
Presentationer

Infrastruktur som bash-historik

Anta att du kommer till ett nytt projekt, och de säger till dig: «vi har Infrastructure as Code«. I verkligheten visar det sig att Infrastruktur som bash-historik eller till exempel Dokumentation som bash-historik. Detta är en helt realistisk situation, till exempel, en liknande historia beskrev Denis Lysenko i sin presentation Hur man ersätter hela infrastrukturen och börjar sova lugnt, han berättade hur de fick en strukturerad infrastruktur från bash-historik på projektet.

Med lite vilja kan man säga att Infrastruktur som bash-historik det är som kod:

återproducibility: du kan ta bash-historiken, utföra kommandona därifrån, och kanske får du en fungerande konfiguration som resultat.
versionshantering: du vet vem som loggade in och vad de gjorde, men det är återigen inte säkert att detta leder till en fungerande konfiguration som resultat.
with the VPN provider UFO, which had a publicly accessible Elasticsearch database of 894GB. The provider positioned itself as caring about user privacy and not keeping logs. Contrary to the claim, the exposed database contained logs, including information about IP addresses, session bindings to time, user location tags, information about the operating system and user device, and lists of domains for ad placement in unprotected HTTP traffic. Moreover, the database contained access passwords in plain text and session keys that allowed the decryption of intercepted sessions.: historik över vem som gjorde vad. men du kan inte använda den om du förlorar servern.

Vad ska vi göra?

Infrastructure as Code

Även ett så konstigt fall som Infrastruktur som bash-historik kan dras med våld till Infrastructure as Code, men när vi vill göra något mer komplicerat än en gammal god LAMP-server, kommer vi till den punkten att denna kod måste modifieras på något sätt, förändras, förbättras. Vidare kommer vi att betrakta paralleller mellan Infrastructure as Code och mjukvaruutveckling.

D.R.Y.

På ett projekt för utveckling av lagringssystem, fanns det en deluppgift att periodiskt konfigurera SDS: vi släpper en ny release — den måste rullas ut för vidare testning. Uppgiften är överraskande enkel:

gå in här via ssh och kör kommandot.
kopiera filen dit.
justera konfigurationen här.
starta tjänsten där
…
VINST!

För den beskrivna logiken är bash mer än tillräckligt, särskilt i de tidiga stadierna av projektet, när det precis har startat. Det är inte dåligt att du använder bash, men med tiden uppstår önskemål om att utveckla något liknande men med små avvikelser. Det första som kommer att tänka på: copy-paste. Och nu har vi redan två mycket lika skript som gör nästan samma sak. Med tiden har antalet skript ökat, och vi har stött på att det finns en viss affärslogik för att distribuera installationen som måste synkroniseras mellan olika skript, vilket är ganska komplicerat.

Det visar sig att det finns en sådan praxis som D.R.Y. (Do not Repeat Yourself). Idén är att återanvända befintlig kod. Det låter enkelt, men vi kom inte fram till det omedelbart. I vårt fall var det en banal idé: att separera konfigurationerna från skripten. Det vill säga affärslogiken för hur installationen distribueras är separat, konfigurationerna är separata.

S.O.L.I.D. för CFM

Med tiden växte projektet och ett naturligt nästa steg var framväxten av Ansible. Huvudskälet till dess tillkomst var expertisen i teamet och att bash inte är avsett för komplex logik. Ansible började också innehålla komplex logik. För att förhindra att den komplexa logiken förvandlas till kaos, finns det principer för kodorganisation inom mjukvaruutveckling. S.O.L.I.D. Dessutom nämnde Grigory Petrov i sin presentation "Varför IT-specialister behöver ett personligt varumärke" att människan är utformad så att det är lättare för henne att hantera sociala enheter, och inom mjukvaruutveckling handlar det om objekt. Om man kombinerar dessa två idéer och fortsätter att utveckla dem, kan man lägga märke till att beskrivningen av infrastrukturen också kan använda S.O.L.I.D. så att det i framtiden blir enklare att stödja och modifiera denna logik.

Single Responsibility Principle

Varje klass utför endast en uppgift.

Man ska inte blanda kod och skapa monolitiska, gudomliga makaronmonster. Infrastrukturen ska bestå av enkla byggstenar. Det visar sig att om man bryter ner Ansible playbook i små bitar, läs Ansible roller, så är de lättare att underhålla.

Open Closed Principle

Öppen/Stängd princip.

Öppna för utvidgning: innebär att en väsendes beteende kan utvidgas genom att skapa nya typer av väsen.
Stängda för förändringar: som ett resultat av utvidgningen av ett väsendes beteende får inga ändringar göras i koden som använder dessa väsen.

Till en början rullade vi ut testinfrastruktur på virtuella maskiner, men eftersom affärslogiken för utrullningen var separat från implementationen, kunde vi enkelt lägga till distributionen på baremetal.

Liskov Substitution Principle

Liskovsubstitutionsprincipen. Objekt i programmet ska kunna ersättas med instanser av deras underklasser utan att ändra programmets korrekthet.

Om man ser bredare är det inte en specifik egenskap hos något särskilt projekt, utan något som kan tillämpas. S.O.L.I.D., det handlar generellt om CFM, till exempel i ett annat projekt behövs det att rulla ut ett boxat Java-program ovanpå olika Java-servrar, applikationsservrar, databaser, operativsystem, etc. På detta exempel kommer jag att betrakta vidare principer. S.O.L.I.D.

I vårt fall finns det en överenskommelse inom infrastrukturen att om vi installerar rollen imbjava eller oraclejava, så har vi en binär körbar fil för java. Detta är nödvändigt eftersom de överordnade rollerna är beroende av detta beteende, de förväntar sig att java finns. Samtidigt gör det att vi kan byta ut en implementation/version av java mot en annan utan att ändra logiken för applikationens distribution.

Problemet här ligger i att det i Ansible inte går att implementera sådant, vilket leder till att det uppstår vissa överenskommelser inom teamet.

Interface Segregation Principle

Principen för gränssnittssegregering "flera gränssnitt som är speciellt designade för kunder är bättre än ett allmänt gränssnitt."

Till en början försökte vi samla all variabilitet för applikationsdistribution i en enda Ansible-playbook, men det var svårt att underhålla, och med tillvägagångssättet där vi har specificerat gränssnittet utåt (klienten förväntar sig port 443) kan infrastrukturen för en specifik implementation byggas upp av separata byggstenar.

Dependency Inversion Principle

Principen för beroendeinversion. Moduler av högre nivåer ska inte bero på moduler av lägre nivåer. Båda typerna av moduler ska bero på abstraktioner. Abstraktioner ska inte bero på detaljer. Detaljer ska bero på abstraktioner.

Här kommer exemplet att baseras på ett antipattern.

En av våra kunder hade en privat moln.
Inuti molnet beställde vi virtuella maskiner.
Men på grund av särdragen hos molnet var distributionen av applikationen knuten till vilken hypervisor den virtuella maskinen hamnade på.

D.v.s. den högnivålogik som används för att distribuera applikationen och dess beroenden flöt ner till de underliggande nivåerna av hypervisorn, vilket skapade problem med att återanvända denna logik. Det behövs inte.

Interaktion

Infrastruktur som kod handlar inte bara om kod, utan även om relationen mellan kod och människa, samt interaktionen mellan infrastrukturutvecklare.

Busfaktor

Anta att du har en person i ditt projekt som heter Vanya. Vanya vet allt om din infrastruktur, vad händer om Vanya plötsligt försvinner? Det är en verklig situation, eftersom han kan bli överkörd av en buss. Sådana saker händer ibland. Om dessa kunskaper om koden, dess struktur, hur den fungerar, användarnamn och lösenord inte är fördelade inom teamet, kan det leda till en rad obehagliga situationer. För att minimera dessa risker och fördela kunskapen inom teamet kan olika metoder användas.

Par DevOps

Det är inte som i skämtet, där administratörer dricker öl, byter lösenord, och det är en analog av parprogrammering. D.v.s. två ingenjörer sätter sig vid en dator, en tangentbord och börjar tillsammans konfigurera din infrastruktur: ställa in servrar, skriva Ansible-roll, etc. Det låter bra, men det fungerade inte för oss. Men privata fall av denna praktik har fungerat. En ny anställd kom, hans mentor tar tillsammans med honom en verklig uppgift, arbetar — överför kunskapen.

Ett annat privatfall är incidentanropet. Under ett problem samlas en grupp jourpersonal och berörda parter, en ledare utses som delar sin skärm och redogör för sitt tänkande. Andra deltagare följer ledarens tankegångar, ser tricks från konsolen, kontrollerar om en rad i loggen har missats, lär sig nya saker om systemet. Denna metod fungerade oftare än den inte gjorde.

Kodgranskning

Subjektivt sett var spridningen av kunskaper om infrastrukturen och hur den var uppbyggd mer effektiv genom kodgranskning:

Infrastrukturen beskrivs i kod i ett repository.
Ändringar görs i en separat gren.
Vid en merge-förfrågan kan man se skillnaden i infrastrukturen.

Det som var unikt här var att granskare valdes på tur, enligt schema, vilket innebär att med viss sannolikhet skulle du få reda på en ny del av infrastrukturen.

Kodstil

Med tiden började det uppstå konflikter under granskningar, eftersom granskare hade sina egna stilar och deras rotationer ledde dem till olika stilar: 2 mellanslag eller 4, camelCase eller snake_case. Att införa detta gick inte direkt.

Den första idén var att rekommendera användning av en linter, eftersom ingenjörerna ändå är smarta. Men olika redigerare och operativsystem gjorde det besvärligt.
Detta utvecklades till en bot som vid varje problematiskt commit skrev i Slack och bifogade linterutgången. Men i de flesta fall fanns det viktigare uppgifter och koden förblev oåtgärdad.

Green Build Master

Tiden gick, och vi kom fram till att vi inte kunde låta commits gå in i master som inte passerade vissa tester. Voilà! vi inventerade Green Build Master som redan länge har praktiserats inom programvaruutveckling:

Utvecklingen sker i en separat gren.
Tester körs på denna gren.
Om testerna misslyckas, kommer koden inte att hamna i master.

Att fatta detta beslut var ganska smärtsamt, eftersom det orsakade många diskussioner, men det var värt det, eftersom förfrågningar om sammanslagning började komma utan stilkonflikter, och med tiden minskade antalet problematiska områden.

IaC Testing

Förutom stilkontroll kan man använda andra metoder, till exempel verifiera att er infrastruktur verkligen kan distribueras. Eller kontrollera att förändringar i infrastrukturen inte leder till förluster. Varför kan detta vara nödvändigt? Frågan är komplex och filosofisk; det är bättre att svara med en historia om att det fanns en auto-scaler på Powershell som inte kontrollerade gränsvillkoren => det skapades fler VM än nödvändigt => kunden spenderade mer pengar än planerat. Inte så trevligt, men det skulle verkligen ha varit möjligt att fånga detta misstag i ett tidigare skede.

Man kan fråga sig varför man ska göra en komplex infrastruktur ännu mer komplex? Tester för infrastruktur, precis som för kod, handlar inte om förenkling, utan om att veta hur er infrastruktur ska fungera.

IaC Testing Pyramid

IaC Testing: Static Analysis

Om man direkt distribuerar hela infrastrukturen och kontrollerar att den fungerar kan det visa sig ta mycket tid och kräva en massa resurser. Därför bör det finnas något som fungerar snabbt, som är omfattande och täcker många primitiva områden.

Bash är knepigt

Låt oss titta på ett enkelt exempel. Välj alla filer i den aktuella katalogen och kopiera dem till en annan plats. Det första som kommer att tänka på:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Men vad händer om det finns ett mellanslag i filnamnet? Okej, vi är ju smarta, vi kan använda citattecken:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Bra jobbat? Nej! Vad händer om det inte finns något i katalogen, dvs. globbing fungerar inte.

find . -type f -exec mv -v {} dst/{}.bak ;

Är vi bra nu? Nej... Vi glömde att filnamnet kan innehålla n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Statisk analysverktyg

Problemet från föregående steg kunde ha fångats när vi glömde citattecken, för detta finns det många verktyg. Shellcheck, det finns många av dem, och ni kan säkert hitta en linter för er IDE och er stack.

Språk
Verktyg

bash
Shellcheck

Ruby
RuboCop

python
Pylint

ansible
Ansible Lint

IaC-testning: Enhetstester

Som vi såg i det föregående exemplet är inte linters allvetande och kan inte peka på alla problem. Vidare kan vi tänka på enhetstester, som vi ser i mjukvaruutveckling. shunit, junit, rspec, pytest. Men vad ska vi göra med ansible, chef, saltstack och liknande?

I början pratade vi om S.O.L.I.D. och att vår infrastruktur bör bestå av små block. Nu är det deras tid.

Infrastrukturen bryts ner i små block, till exempel Ansible-roller.
Ett visst miljö sätts upp, oavsett om det är docker eller VM.
Vi tillämpar vår Ansible-roll på denna testmiljö.
Vi kontrollerar att allt har fungerat som förväntat (kör tester).
Vi bestämmer om det är okej eller inte.

IaC-testning: Verktyg för enhetstestning

Frågan är, vad är tester för CFM? Du kan enkelt köra ett skript, men det finns också färdiga lösningar för det:

CFM
Verktyg

Ansible
Testinfra

Chef
Inspec

Chef
Serverspec

saltstack
Goss

Exempel för testinfra, vi kontrollerar att användarna test1, test2 finns och tillhör gruppen sshusers:

def test_default_users(host):
    users = ['test1', 'test2']
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Vad ska man välja? En svår och otydlig fråga, här är ett exempel på förändringar i projekt på github under 2018-2019:

IaC-testningsramverk

Frågan är hur man samlar allt detta och kör det? Man kan ta och göra allt själv med tillräckligt många ingenjörer. Men man kan också använda färdiga lösningar, som inte är så många:

CFM
Verktyg

Ansible
Molecule

Chef
Test Kitchen

Terraform
Terratest

Exempel på förändringar i projekt på github under 2018-2019:

Molecule vs. Testkitchen

Vi försökte först använda testkitchen Skapa VM parallellt.:

Создать ВМ в параллель.
Tillämpa Ansible-roller.
Kör inspec.

För 25-35 roller tog det 40-70 minuter, vilket var länge.

Nästa steg blev att gå över till Jenkins / Docker / Ansible / Molecule. Ideologiskt är allt detsamma.

Linta playbooks.
Linta roller.
Starta behållare.
Tillämpa Ansible-roller.
Kör testinfra.
Kontrollera idempotens.

Lintning för 40 roller och tester för ett dussin tog omkring 15 minuter.

Vad man väljer beror på många faktorer, som den använda teknologin, expertisen i teamet osv. Här bestämmer var och en själv hur man löser frågan om enhetstestning.

IaC-testning: Integrationstester.

På nästa steg i pyramidens testning av infrastrukturen dyker integrations tester upp. De liknar enhetstester:

Infrastrukturen delas upp i små bitar, till exempel Ansible-roller.
Ett visst miljö sätts upp, oavsett om det är docker eller VM.
Detta testmiljö tillämpas. många Ansible-roller.
Vi kontrollerar att allt har fungerat som vi förväntar oss (kör tester).
Vi bestämmer om det är okej eller inte.

Grovt sett, vi kontrollerar inte funktionaliteten hos enskilda systemelement som i enhetstester, vi kontrollerar hur servern är konfigurerad i sin helhet.

IaC-testning: End to End-tester.

På toppen av pyramiden möter vi End to End-tester. Det vill säga, vi kontrollerar inte funktionaliteten för enskilda servrar, enskilda skript, eller enskilda delar av vår infrastruktur. Vi kontrollerar att en mängd servrar, sammanslagna till en helhet, fungerar som vi förväntar oss. Tyvärr har jag inte sett några färdiga lösningar, antagligen eftersom infrastruktur ofta är unik och det är svårt att standardisera och skapa ett ramverk för testning av den. Som ett resultat skapar alla sina egna lösningar. Det finns en efterfrågan, men inget svar. Så jag kommer att berätta vad som finns, för att inspirera andra till kloka tankar eller påminna mig om att allt redan är uppfunnet.

Projekt med en rik historia. Används i stora organisationer och förmodligen har var och en av er indirekt varit i kontakt med det. Applikationen stöder många databaser, integrationer osv. Kunskapen om hur infrastrukturen kan se ut är många docker-compose-filer, och kunskapen om vilka tester som ska köras i vilken miljö är Jenkins.

Denna schemat fungerade länge, tills vi försökte flytta det till Openshift. Behållarna förblev desamma, men körningsmiljön ändrades (hej D.R.Y. igen). forskning мы не попробовали это перенести в Openshift. Контейнеры остались теже, а вот среда запуска сменилась (привет D.R.Y. опять).

Forskningsidén gick längre, och i OpenShift hittades något som kallas APB (Ansible Playbook Bundle), vilket möjliggör att packa in kunskapen om hur man distribuerar infrastrukturen i en container. Det vill säga, det finns en reproducerbar, testbar kunskapspunkt om hur man distribuerar infrastrukturen.

Allt detta lät bra, tills vi stötte på en heterogen infrastruktur: vi behövde Windows för tester. Slutligen sitter kunskapen om vad, var, hur man distribuerar och testar i Jenkins.