Blog ·
Un script care știe că vorbește cu un container
Șapte câmpuri opționale în care absența înseamnă neconstatat, un tabel de comenzi al cărui test își derivă cazurile, și un sistem de operare în lista greșită.
De Provibr
O gazdă Proxmox poate rula două lucruri foarte diferite: o mașină virtuală completă cu nucleu și firmware proprii, și un container care împarte nucleul gazdei. De departe amândouă sunt „un server”, iar panoul le pune într-o singură listă. De aproape se deosebesc în feluri care contează pentru cine scrie automatizare, iar până în această rundă un script nu le putea deosebi.
Este o poziție proastă. Un script care îi cere unui container să mărească un disc virtual, să atașeze o imagine ISO sau să pornească din rețea nu cere ceva greu; cere ceva ce nu există. Eșecul ajunge patru straturi mai târziu, ca o comandă acceptată, pusă la coadă, trimisă și apoi refuzată de un agent.
Șapte câmpuri, iar absent înseamnă neconstatat
Scripturile și cârligele web primesc acum un grup de fapte despre ce se află sub un server: felul lui, șablonul din care vine, dacă este neprivilegiat, spațiul de stocare pe care stă rădăcina lui, punctele lui de montare, ce poate cu adevărat și ce nu poate.
Oricare dintre acele câmpuri poate lipsi, iar lipsa înseamnă neconstatat. Este aceeași regulă pe care o urmează coloana de dedesubt, unde felul nu a fost niciodată completat în tăcere, și există pentru că alternativa este mai rea decât inutilă. Un instantaneu care scrie „mașină virtuală” când nimeni nu a măsurat vreodată este o presupunere predată unui script care va lua o decizie pe baza ei.
Un fel necunoscut nu devine deci o valoare implicită. Câmpul dispare cu totul din contextul de redare, iar citirea lui este atunci o eroare dură chiar în momentul în care fluxul este salvat, în loc de un șir gol care face o condiție falsă în tăcere. Este același raționament ca eliminarea unui grup de variabile pe care un declanșator nu îl poate furniza: zgomotos la salvare bate tăcut la rulare.
Este totodată primul grup imbricat din catalogul de variabile. Un nume de câmp cu un punct în el este de obicei o capcană în această bază de cod, pentru că acest catalog de traducere tratează punctul ca pe un nivel; aici cheia catalogului îl aplatizează intenționat, în timp ce calea contextului coboară un nivel, iar un test fixează presupunerea că există exact un punct.
Căile gazdei nu călătoresc
O montare legată în configurarea unui container arată ca o cheie, o cale a gazdei și un punct de montare. Calea aceea este un dosar al hipervizorului și nu are voie să iasă niciodată de acolo.
Regula din propria noastră documentație este directă: clienții nu primesc niciodată prin Provibr un interpretor de comenzi al gazdei, o cale din sistemul ei de fișiere ori o acreditare de administrare a hipervizorului. Un instantaneu de variabile este exact o astfel de cale. Ajunge într-un script, în corpul unui cârlig web la un terț și într-un rând de audit.
Instantaneul nu poartă deci niciodată sursa. Rămâne ce are voie un client să știe despre propriul container: ce cheie este, unde este montată în container și din ce fel de sursă vine. O formă de text fixă, pentru că un script citește asta tăind după un separator și nu analizând proză: mp1:bind:/srv spune că există o montare legată la /srv și nu spune absolut nimic despre locul din care vine pe gazdă.
Asta este valabil și pentru o montare de volum. Un nume de stocare nu este o cale a gazdei, dar este nomenclatura proprie a hipervizorului, iar nicio întrebare de script nu are nevoie de el. Numele stocării apare o dată, separat, ca un singur cuvânt pe care clientul îl văzuse oricum la comandă.
Prețul acestui desen este declarat în loc să fie ascuns: faptele de montare vin din configurarea pe care agentul o citește în timpul unei copii de siguranță, deci un container care nu a avut niciodată o copie nu produce niciun punct de montare. Câmpul lipsește atunci, iar asta este corect, pentru că o listă goală ar susține că acel container nu are puncte de montare.
Un tabel al cărui test își derivă propriile cazuri
Exista deja un tabel scris care spune, pentru fiecare comandă de mașină virtuală, dacă un container o poate și de ce nu. Lipsea un tabel care să acopere fiecare comandă pe care o poate purta o integrare Proxmox, inclusiv copiile de siguranță și cele patru citiri care descriu integrarea și nu un oaspete anume.
Fără acea deosebire, o sită nu poate despărți „nicio judecată notată” de „asta nu este deloc despre un oaspete”, iar singurul comportament sigur pentru al doilea este să lase să treacă. Aceasta este exact ramura tăcută de care proiectul acesta se arde mereu.
Tabelul nou este de aceea derivat din cel scris în loc să fie scris alături, iar testul nu enumeră cazuri. Calculează mulțimea accesibilă din registre, luând fiecare fel de comandă pe care furnizorul Proxmox nu o refuză și care servește și o resursă oaspete, plus citirile numite pe descriptorul furnizorului însuși, și cerând apoi o declarație pentru fiecare fel. Douăzeci și șapte de comenzi de oaspete și patru citiri de integrare, iar testul a fost dovedit întâi roșu și abia apoi verde.
Un test pe caz nu poate găsi un caz lipsă. Baza aceasta de cod a învățat lecția de trei ori până acum, iar aceasta este a treia formă a aceleiași păzi.
O comandă lipsește intenționat, iar comentariul spune unde să o căutați. Executarea unei comenzi în container ar însemna astăzi rularea ei ca administrator pe hipervizor, în afara containerului, cu drepturile gazdei. Aceasta nu este o funcție de scripturi cu amprentă mică; este un interpretor de comenzi al gazdei cu un nume prietenos. Cine o va construi va avea o rundă proprie, cu un executant în oaspete, un drept propriu și o urmă de audit proprie.
Un refuz înainte de trimitere nu lasă niciun rând
Poarta refuza deja comenzile imposibile. Refuzul acela i se întâmplă unei comenzi care există deja: rândul stă în baza de date, operațiunea a fost creată, iar clientul privește cum eșuează o sarcină.
Ceea ce se cerea era validarea înainte de trimitere, iar aceasta este exact deosebirea. Cererea către un container să își spună echipamentul virtual trebuie să dea o propoziție și nu un rând de audit.
Cele două site nu se pot desincroniza, pentru că citesc același tabel. Nu este un al doilea adevăr; este același adevăr, cu un strat mai devreme. Poarta rămâne necesară pentru cererea repetată sau falsificată care nu trece niciodată prin funcția panoului.
Motivul refuzului este redat ca un singur mesaj cu o ramură pentru fiecare motiv, iar paza din jur cere două lucruri: o ramură pentru fiecare motiv și ca propozițiile să se deosebească între ele. O ramură lipsă într-o alegere de limbă cade pe valoarea implicită și spune ceva adevărat care nu înseamnă nimic, iar acest fel de a se strica îi este deja cunoscut proiectului.
Sistemul de operare din lista greșită
Descoperirea pe care doar o bază de date reală a scos-o la iveală nu avea nicio legătură cu cele de mai sus.
Intrările de sistem de operare își țineau odinioară sursa de instalare într-o coloană, iar acum în două, cea veche fiind citită ca rezervă pentru rândurile pe care niciun scriitor nou nu le-a atins vreodată. Șabloanele de container au venit mai târziu și merg într-o coloană proprie, iar pe un rând nou sunt proiectate și în cea veche.
Rezerva nu știa asta. Citea o referință de container din coloana veche drept șablon de mașină virtuală, așa că un sistem de operare cu doar un șablon de container apărea în lista de mașini virtuale a fluxului de comandă, fără fel de calcul, iar o comandă dată pe el ar fi eșuat mai târziu pe o sursă de clonare fără identificator de clonat.
Reparația este o ramură: o referință de container din coloana veche nu este o sursă de mașină virtuală. Nu se pierde nimic, pentru că partea de container își citește propria coloană și niciuna alta, iar rândurile destul de vechi ca să aibă nevoie de rezervă nu pot purta prin construcție o referință de container: coloana aceea nu exista încă.
O a doua descoperire a venit dintr-o captură de ecran și nu dintr-o verificare. În lista lucrurilor pe care un container nu le poate face stătea o comandă de plată care aparține altui furnizor și care pe Proxmox nu există pentru niciunul dintre cele două feluri. Adevărată, și cu totul nelalocul ei pe pagina de detaliu a unui container. A fost scoasă din acea listă.
Ce am nota
- Absent este un răspuns. Dacă nu cunoașteți felul, nu puneți o valoare implicită. O presupunere predată automatizării este mai rea decât o gaură pe care scriptul o poate vedea.
- Siguranța drepturilor este o proprietate a formei, nu a apelantului. Desenați instantaneul astfel încât calea gazdei să nu fie în el, iar niciun cititor viitor nu o va putea scăpa.
- O formă de text fixă bate proza. Cineva va tăia asta după un separator.
- Derivați cazurile din registru. Un test pe caz este structural incapabil să găsească acel caz pe care nu l-a scris nimeni.
- Refuzați înainte să consemnați. Un refuz care produce un rând de audit i-a spus deja clientului povestea greșită.
- Priviți capturile de ecran. Intrarea nelalocul ei era adevărată, a trecut prin fiecare verificare și era imediat greșită pentru un ochi omenesc.
Pentru claritate despre ce este acest lucru: containerele se pot comanda pe Proxmox, iar faptele de calcul sunt în producție. Mai multe lucruri nu sunt dovedite. Nimic din acestea nu a fost pus la treabă în această rundă față de un hipervizor real, faptele de montare depind de existența a cel puțin unei copii de siguranță, o propoziție din fluxul de comandă spune încă „VM-ul” la un container, iar contorul de licențe numără încă un container ca mașină virtuală.
Din munca de platformă a Provibr. De ce un container neprivilegiat este o măsurătoare și nu o setare se află în neprivilegiat este o măsurătoare, nu o setare, iar ce puncte de montare conține sau nu o copie de siguranță a unui container se află în ce nu conține o copie de siguranță.