Imagini Linux imuabile - cât de departe pot și ar trebui să merg?

Imuabilitatea este grozavă pentru a realiza consecvența, predictibilitatea și fiabilitatea și nu văd niciun motiv pentru care nu ar trebui să mă străduiesc pentru imuabilitatea la nivel de sistem de operare atunci când implementez aplicația mea pe VPS-uri Linux de la diferiți furnizori de cloud din întreaga lume. lume. Cu instrumente precum Packer pentru a ajuta la crearea imaginilor sistemului de operare, aceasta pare să fie și calea de urmat.

Pentru unii furnizori de cloud (de exemplu, Digital Ocean), pot crea imaginea local în qcow2 sau format brut și apoi pot încărca imaginea finalizată la furnizorul de cloud pentru implementare atunci când instanțiez noi VPS.Aceasta pare a fi cea mai bună opțiune.

Dar alți furnizori de servicii cloud (de exemplu, Hetzner din Germania) nu acceptă importarea propriilor imagini ale sistemului de operare - în schimb, trebuie să construiți imaginea pe infrastructura lor pe baza uneia dintre imaginile lor sursă și apoi puteți instantanee instalarea finală într-un sistem reutilizabil. imagine, când totul este configurat corect. De fapt, acest lucru este, de asemenea, ceea ce face „Hetzner Cloud Builder” de la Packer.

Dar cum pot garanta atunci că imaginea finală Hetzner are corect aceeași instalare CentOS 8 (până la același set precis de pachete RPM instalate cu exact aceleași numere de versiune) ca și care rulează pe toți ceilalți furnizori de cloud?

Îmi imaginez că soluția ar putea fi un fel de instrument declarativ, care preia o listă de pachete RPM și numerele de versiune asociate și aduce sistemul țintă în concordanță cu această listă - asigurându-se că orice pachete RPM lipsă sunt instalate în versiunea corectă, eliminând superflue. Pachetele RPM, actualizarea pachetelor RPM mai vechi și downgrade-ul pachetelor RPM mai noi pentru a vă asigura că versiunea necesară este instalată.

Există un astfel de instrument sau ar trebui să mă gândesc complet diferit despre asta?

Unii ar putea argumenta că pachetele CentOS RPM ar trebui să fie întotdeauna actualizate la cea mai nouă versiune disponibilă, dar nu pot garanta că toți furnizorii de cloud rulează aceeași instalare a sistemului de operare - ceea ce poate afecta predictibilitatea și fiabilitatea serviciului meu.

În schimb, vreau să pot testa în detaliu o configurare completă (OS + aplicație) înainte de a o implementa la orice furnizor de cloud, iar apoi implementarea va fi aceeași pentru toți furnizorii de cloud. Așa facem lucrurile la nivel de aplicație folosind imagini Docker și nu văd de ce ar trebui să acceptăm mai puțin la nivelul sistemului de operare.

Vreo contribuție de la colegii dvs. DevSecOps cum să atingeți aceste obiective?

Nici actualizările bazate pe imagini, nici gazdele imuabile nu sunt necesare pentru a seta unele controale asupra software-ului instalat. Există opțiuni între extremele
pachete de actualizare automată din oglinzi publice și imagini imuabile.

Cu o distribuție care folosește pachete individuale, să zicem CentOS folosind rpm, ar putea să vă păstrați propriul depozit de actualizări. Limitați-vă doar la pachetele pe care le utilizați. Preluați în mod regulat actualizări într-un depozit de testare, să zicem la fiecare 4 săptămâni. Testați acest set de pachete înghețate pentru o perioadă, apoi treceți în depozitul dvs. stabil. Configurați toate gazdele să se actualizeze automat din oglindă, poate într-un program. Când automatizarea instalează un pachet ca parte a implementării unui lucru, versiunea acestuia este cunoscută deoarece vine din oglindă. Cu toate acestea, gazdele individuale pot avea probleme la aplicarea tranzacției pachetului și pot fi depășite.Luați în considerare interogarea fiecărei gazde din flotă pentru versiuni ale pachetelor deosebit de importante, poate anumite actualizări de securitate.

Destul de ușor pentru a clona o instalare a sistemului de operare ca altă instanță. Cu toate acestea, imaginile distribuțiilor bazate pe pachete nu sunt cu adevărat imuabile, managerul de pachete este încă disponibil în instanță, iar utilizatorii privilegiați pot încă schimba lucrurile în arborele /usr.

Luați în considerare o distribuție construită în jurul actualizării bazate pe imagini, cum ar fi CoreOS. Actualizările trebuie să fie stratificate în imagine și repornite pentru a avea efect. Personalizarea este limitată la o cantitate mică de metadate. CoreOS în special este doar pentru găzduirea containerelor, dar acesta poate fi cazul dvs. de utilizare. Are avantajul de a fi reproductibil, Fedora CoreOS 34.20210904.3.0 este un set de software bine definit.

Gazdele de calcul care nu oferă o modalitate de a încărca imagini pot fi rezolvate. Porniți un mediu de salvare cu acces la rețea și descărcați imaginea direct pe disc. Faceți un instantaneu pentru a face un șablon.

Acum ar putea fi un moment bun pentru a evalua alegerea dvs. de distribuție din alte motive. CentOS Linux 8 se încheie în decembrie 2021. CentOS Stream este înlocuitorul, dar este mai degrabă în amonte decât în ​​aval de RHEL.

De fapt, odată ce ați creat VM în Hetzner, îl puteți porni pe un LiveCD la alegere, care are lucruri precum CloneZilla sau SystemRescue pe care le puteți utiliza pentru a vă descărca/restaura imaginea.

De fapt, constat că imaginile CloneZilla sunt mai portabile între diverși furnizori de cloud VPS.

Dar cum pot garanta apoi că imaginea finală Hetzner are exact aceeași instalare CentOS 8 (până la același set de pachete RPM instalate cu exact aceleași numere de versiune) ca și care rulează pe toți ceilalți furnizori de cloud?

Dacă înțeleg corect ce vrei, aș merge la orice instrument de „infra-test” cum ar fi Inspect care vă permite să descrie ceea ce doriți să aveți în imaginea/VM-ul țintă.

Îl folosim pentru a ne valida stiva de sare/proiect de sare cod folosind-o împreună cu Bucătărie în acest fel (o rulăm într-o lucrare pe instrumentul nostru CI)

• crea N mașini virtuale cu Bucătărie (poate fi folosit cu Docker, Vagrant dar și cu furnizorii de cloud)
• dispoziţie fiecare mașină cu profilul ei, cu Salt, Ansible, Chef, Puppet sau orice altceva
• verifica starea mașinii rezultată cu Inspec

Inspec vă permite să creați un fel de „testare unitară”, dar pentru infrastructură/sistem: puteți verifica cu ușurință utilizatorii și grupurile prezente sau absente, pachetele instalate și versiunea acestora, serviciile care rulează, porturile TCP/UDP, regulile firewall...

(Folosesc și Packer pentru a crea imagini, dar momentan nu folosesc Inspec în acest context: considerăm că codul folosit pentru a crea această imagine a fost deja testat de jobul CI anterior)

Deci, mergând la problema dvs.: aș adăuga la configurația dvs. Packer un pas de verificare Inspec. Mai mult, se pare că este deja integrat în Packer ca provider https://www.packer.io/docs/provisioners/inspec (pe care tocmai l-am descoperit)