Reinstalarea unui container este o înlocuire

Reinstalarea unei mașini virtuale pe Proxmox este aproape plictisitoare. O opriți, o ștergeți, clonați șablonul peste același ID și lăsați cloud-init să facă restul. Șablonul poartă un disc, iar discul poartă un sistem de operare, așa că „reinstalare” înseamnă de fapt „fă o copie nouă a unui lucru despre care se știe că este bun”.

Un container Linux nu are niciuna dintre cele două. El este despachetat dintr-o arhivă tar, iar tot ce este după aceea, nucleele, memoria, swapul, dimensiunea sistemului de fișiere rădăcină, interfața de rețea, rezolvatorul, numele de gazdă, trăiește într-un fișier de configurare de pe hipervizor și nicăieri altundeva. Nu există nicio imagine peste care să clonați. Așadar, o reinstalare de container este o distrugere urmată de o creare, iar odată ce spuneți asta cu voce tare urmează un set de obligații pe care o reinstalare de mașină virtuală nu le are niciodată.

Iată cum am construit-o, iar partea care a durat cel mai mult nu a fost distrugerea.

Două faze, pentru că platforma nu știe ce este montat

Fluxul este împărțit. Prima fază doar citește și nu schimbă nimic: agentul preia configurația containerului și o predă înapoi. A doua fază oprește, distruge, creează și pornește, folosind drept precondiție ceea ce a citit prima fază.

Alternativa evidentă este o singură fază, cu o previzualizare construită din ce știe deja platforma. Aici nu este disponibilă. Inspecția hardware pentru containere nu este implementată, pentru că analizorul pe care l-ar folosi citește chei de configurare QEMU, așa că nu există nicăieri în baza noastră de date un instantaneu stocat al punctelor de montare ale unui container. O previzualizare care etichetează fiecare punct de montare drept „unknown” nu este o previzualizare, este o declinare a răspunderii.

Cinci cuvinte pentru ce se întâmplă cu datele

Fiecare punct de montare din configurație primește exact o etichetă, iar eticheta este despre date, nu despre montare.

Ultimul rând se află în listă și nu este produs niciodată. Păstrarea unui volum peste o distrugere înseamnă detașarea lui, ștergerea containerului fără colectarea discurilor nereferențiate și reatașarea lui după aceea: trei pași, dintre care cel din mijloc, la eșec, lasă în urmă un volum al cărui proprietar nu mai este nimeni. Aceasta este o lucrare separată, cu propria ei buclă de curățare. Valoarea există în vocabular pentru ca o versiune ulterioară să nu fie nevoită să o strecoare în tăcere sub alt nume, o funcție declară că încă nu este oferită, iar un test afirmă că clasificatorul nu o întoarce niciodată.

Distincția importantă este cea din prima propoziție. Un punct de montare poate să aibă date care supraviețuiesc și totuși să nu se mai întoarcă, pentru că apelul de creare pe care îl trimitem setează întotdeauna doar sistemul de fișiere rădăcină. Orice altă montare dispare din containerul nou, indiferent ce s-a întâmplat cu octeții ei. Dacă inversați asta, obțineți cea mai periculoasă propoziție din toată această funcționalitate: „preserved” lângă o montare care nu va exista după aceea.

Proprietatea se află în identificatorul de volum

Proxmox scrie un volum în una dintre două forme, iar amândouă spun ce oaspete îl deține. local-lvm:vm-5001-disk-0 și local:5001/vm-5001-disk-0.raw aparțin amândouă containerului 5001. Un bind mount nu este niciuna dintre ele: este o cale absolută, iar bara oblică de la început este exact ceea ce testează Proxmox însuși.

Această analiză decide excluded față de erased. Un punct de montare din configurația acestui container care arată către volumul altui oaspete este sărit de distrugere, pentru că Proxmox verifică proprietatea, așa că acele date nu sunt șterse. Fără comparație, previzualizarea ar spune „erased” despre date care rămân. Cineva ar restaura apoi o copie de siguranță de care nu avea nevoie, ceea ce este un dezastru mai mic decât inversul, dar tot unul provocat de noi.

Previzualizarea este o precondiție, nu o poză

Ce a văzut clientul călătorește înapoi odată cu comanda de aplicare, sub forma unei liste de confirmări, iar agentul citește configurația din nou, imediat înainte de a distruge. Dacă diferă, un punct de montare adăugat, un alt volum sub aceeași cheie, refuză.

Între previzualizare și clic se află o ființă umană, iar în acest timp un administrator poate atașa un disc în interfața Proxmox. „Bind mounturile și punctele de montare gestionate de gazdă nu fac automat parte dintr-o reinstalare” este adevărat numai dacă ceva impune asta.

Fiecare confirmare este o cheie și un volum și, în mod deliberat, nu eticheta. Eticheta este judecata platformei și nu are nimic de decis la celălalt capăt; dacă i-ar fi dată agentului ca parte din ceea ce compară, ar exista o ramură care ar alege pe baza ei, iar atunci regulile ar trăi în două locuri. Eticheta este totuși consemnată, alături de confirmări, în înregistrarea comenzii și în rândul de intenție, pentru că aceea este partea de audit, iar acolo trebuie să scrie exact ce i s-a arătat clientului.

Numai creștere, comparată în octeți, arătată în gibiocteți

O reinstalare nu are voie să micșoreze sistemul de fișiere rădăcină. Comparația rulează pe octeți, iar ecranul rotunjește în sus la gibiocteți întregi.

Rotunjirea în sus este direcția conservatoare, iar contraexemplul spune de ce. Rotunjiți în jos 8,5 GiB la „8 GiB” pe ecran, acceptați față de această valoare o cerere de 8 GiB și dispare o jumătate de gibioctet pe care nimeni nu a cerut să o piardă. Măsurat pe un Proxmox reconstruit, un container care raporta 16 GiB acolo unde planul cerea 8 a fost refuzat.

Există o capcană cu un nivel mai jos. Proxmox scrie dimensiunile ca 8G, 512M sau ca un număr simplu, iar un număr simplu înseamnă kibiocteți. Citit ca octeți, 8388608 înseamnă 8 MiB; citit corect, înseamnă 8 GiB. Un analizor care ghicește greșit aici nu aruncă nicio eroare, ci pur și simplu aprobă orice micșorare care i se arată vreodată.

Nouă motive pentru a refuza

Înainte să se întâmple ceva ireversibil există nouă piedici cu nume: containerul nu mai există, este pus protection=1, Proxmox ține o blocare pe oaspete, rulează una dintre propriile noastre sarcini de copiere de siguranță sau de restaurare, există un punct de restaurare protejat, sistemul de fișiere rădăcină s-ar micșora, dimensiunea lui curentă nu a putut fi citită, un punct de montare nu a putut fi clasificat sau o reinstalare este deja în curs.

Fiecare este o valoare tipizată cu propria ei propoziție tradusă în nouă limbi, așa că un motiv care nu se află pe listă nu poate primi una. Ele sunt verificate de două ori la noi, o dată când se desenează previzualizarea și încă o dată când se apasă butonul de confirmare, și a treia oară de agent, față de configurația pe care o citește el însuși. Trei închideri, pentru că acesta este pasul ireversibil al capitolului.

Parola de root este cerută în a doua fază, nu în prima, și călătorește ca date tranzitorii în loc să fie stocată. Un secret pe care îl tastați chiar înainte de pasul ireversibil nu petrece o jumătate de oră stând într-o filă de browser.

„Necesită reconciliere” este al treilea rezultat și ține blocarea închisă

Dacă ceva eșuează între distrugere și creare, rularea nu devine „eșuată”. Devine „necesită reconciliere”, purtând ID-ul containerului, pasul la care a murit și dacă containerul mai exista atunci când agentul a renunțat. Ultimul câmp poate fi null, iar null nu este false: „nu am putut determina” nu are voie să se citească drept „ID-ul este liber”.

Dacă un eșec este distructiv sau nu se deduce din poziția pasului în lista ordonată de etape, începând de la distrugere încolo. De aceea etapele sunt o listă și nu un set de șiruri libere: la întrebarea „se întâmplase deja ceva ireversibil” se răspunde într-un singur loc.

O rulare aflată în acea stare ține închisă blocarea de pe server. Pornirea unei a doua înlocuiri pe un ID despre care nimeni nu știe dacă are un container pe el este exact lucrul pe care acest design îl interzice, iar închiderea trebuie făcută de un om.

Perdantul unui compare and swap trebuie să recitească

Nu există niciun lucrător care să actualizeze aceste rânduri. Starea avansează atunci când cineva o citește: citirea se uită la comanda de care este atașată intenția și mută rândul înainte, cu un compare and swap pe un contor de generație, așa că doi cititori simultani execută împreună fiecare tranziție exact o dată.

Atât fusese proiectat. Ce nu fusese proiectat, și ce a prins testul de browser, este ce ar trebui să întoarcă perdantul acelui swap.

Panoul interoghează o dată pe secundă după ce se cere o previzualizare, iar acea interogare execută aceeași tranziție. Dacă clientul încarcă pagina în aceeași secundă, interogarea câștigă swapul, pagina dă înapoi propriul ei rând, acum învechit, iar ecranul continuă să spună „se așteaptă agentul”, deși previzualizarea se află deja în baza de date. O navigare, o cerere și un ecran care arată o stare ce nu mai exista. Numai o a doua reîncărcare o repara.

Remediul are lungimea unei propoziții și merită interiorizat: a pierde un compare and swap înseamnă, prin construcție, că altcineva tocmai a făcut exact tranziția pe care o doreați. Răspunsul corect este, prin urmare, rândul lui, iar asta costă un singur select. Să îl întoarceți pe al dumneavoastră este lucrul intuitiv și este întotdeauna greșit.

Ce am scrie noi

1. 01Dacă lucrul pe care îl înlocuiți nu are nicio imagine, numiți-l înlocuire. Cuvântul schimbă ce îi datorați clientului înainte să începeți.
2. 02Etichetați datele și montarea separat. Sunt două întrebări, iar combinația dintre un răspuns adevărat la una și un răspuns fals la cealaltă este cea mai proastă ieșire pe care o poate produce sistemul.
3. 03Faceți previzualizarea să călătorească înapoi ca o condiție, recitiți-o la celălalt capăt și refuzați la orice diferență. Între timp a dat clic un om.
4. 04Rotunjiți conservator atunci când o eroare de rotunjire nu poate decât să distrugă.
5. 05Dați unei operațiuni distructive lăsate la jumătate o stare a ei proprie, țineți blocarea închisă și nu o lăsați niciodată să cadă nici în reușită, nici în eșec.
6. 06Recitiți după un compare and swap pierdut, întotdeauna.

Suportul pentru containere pe Proxmox este lansat în etape, iar reinstalarea stă târziu în acea ordine, din motivele de mai sus. Dacă vă aflați mai devreme în acea succesiune, compromisurile dintre cele două tipuri de oaspete se află în VM sau container pe Proxmox, iar motivul pentru care un apel API reușit nu este o lucrare încheiată se află în de ce un 200 de la Proxmox nu este un rezultat.

Din munca la Proxmox de la Provibr.