Există o astfel de tendință acum - de a lucra cu infrastructura IT ca un cod. Ei bine, scopul acestei metode este descris de acest citat:
"Activați reconstrucția afacerii de la nimic altceva decât un depozit de cod sursă, o copie de rezervă a datelor de aplicație și resurse metalice goale"
Susțin această idee și este în această interpretare.
Dacă vorbim despre paradigma pe care ne-o oferă această metodă, aici este:
Păstrați o infrastructură modulară, ușor automatizată și descrieți această infrastructură utilizând un limbaj de nivel înalt.
Aceasta înseamnă pentru noi, ca sysadmins, că ar trebui să utilizăm toate dezvoltările dezvoltatorilor de software, cum ar fi:
- Elaborarea descrierii infrastructurii;
- testarea completă a descrierii utilizând mai multe etape (dev, QA, staging, prod);
- standarde interne de "codificare";
- integrare continuă.
Problema, în opinia mea, este faptul că mulți oameni să înțeleagă „infrastructură Code“ într-un sens diferit - „Să scrie o descriere a infrastructurii noastre cu ajutorul Chef / păpuși, în cazul în care acesta este un cod regulat.“ În plus, în Chef, acest lucru este mult mai pronunțat, deoarece DSL-ul pur este folosit ca un DSL.
Desigur, programatori, devin responsabile pentru administrarea serverelor care utilizează Chef în nici un fel, fericit să înceapă să folosească instrumente familiare (Ruby) același mod obișnuit și a obține exact ceea ce au folosit pentru a face. În schimb, descrierea declarativă a infrastructurii pe care să incite orice instrument pentru managementul configurației și a obține o infrastructură personalizate, de ieșire este un program cu o grămadă de hacks, cu ramificare multiplă, cu performanța de cod Shell, care poate fi absolut necesară pentru a aduce sistemul la o stare dorită.
Un exemplu poate fi aproape orice bucatar chef. Luați cărțile de bucate Nginx. El poate pune Nginx în mai multe moduri, incluzând construirea din surse și conține o multitudine de variabile menite să înlocuiască scrierea șablonului de configurare Nginx cu specificarea valorilor acestui grup de variabile.
Aceasta este în sine o abordare proastă - încercând să strângem toate capabilitățile lui Nginx (și chiar și cu modulele terțelor părți) într-un mega-șablon și trebuie gestionate doar variabilele.
Construirea din codul sursă din kukbook provoacă, de asemenea, o mulțime de întrebări. De ce e pe serverul de luptă? Strângeți pachetul de pe serverul de configurare, îl testați și îl distribuiți de la toate serverele din depozit - aceasta este abordarea normală.
Și toate acestea creează atâtea dificultăți, este nevoie de atât de multă muncă pentru a scrie, a testa și a păstra acest kukbuk actualizat, în loc să împartă întregul proces în câțiva pași simpli:
- Colectați pachetul Nginx cu modulele necesare pe server-ul de configurare, testați-l și puneți-l în repozitoriu;
- Scrieți fișierul configurat Nginx pentru sarcinile dvs., luând în considerare diferențele dintre mediile existente (staging / prod);
- Scrieți o carte de bucate / manifeste / rol care va pune un pachet din repozitoriu, va popula șablonul cu variabile care diferă în mediile dvs. și va pune acest șablon pe server.
Asta e, nu aveți nevoie de tone de cod Ruby cu inserții de coajă, nu aveți nevoie de sute de variabile. Avem o descriere a procesului de construire a pachetelor (spec-file sau Makefile) și o descriere declarativă a stării necesare a sistemului.
Și se potrivește perfect cu unul dintre principiile Programării Extreme. care are următorul cuprins:
Faceți lucrul cel mai simplu care ar putea funcționa
Asta este, trebuie să ne asigurăm că kukbuk / manifestul / rolul nostru a fost suficient de simplu pentru a satisface cerințele noastre de astăzi. Bineînțeles, faptul că ne confruntăm și facem ceva "pe frunte" fără să ne gândim va fi greșit, dar cu siguranță nu merită să creăm monștri pseudo-universali. În toate măsura este necesar.
Care e cel mai rău - oamenii care scriu însuși Chef, și au scris acest kukbuk pentru Nginx. Ei au scris bine, dar au scris ca programatori, nu ca administratori de sistem. Și când sysadmins scriu kukbuki în acest stil, creațiile lor nu se uită deloc fără lacrimi.
De aceea, am ales pentru a gestiona serverele ansiblu create de Michael DeHaan, un om care a lucrat la Puppet Labs, el a creat FUNC și Cizmarul, și apoi, cu o mare experiență și de a vedea greșelile predecesorilor, a scris ansiblu. Ansiblu mult mai ușor de bucătar sau de păpuși, și declarative YAML-dosar care descrie starea dorită a sistemului limitează capacitatea de a te împușca în picior și umfli lapsheobraznogo cod imperativ.
Dacă această notă este citită de către administratorii care administrează serverele - oprirea interpretării "Infrastructură ca cod" este incorectă! Folosim cele mai bune practici din lumea programării, dar aceasta nu este o programare tradițională. Nu reinventați scripturile Bash pe Ruby.