Hvor Docker hører hjemme på Proxmox: placeringsvalget og compose-fælden

Proxmox er installeret, og du vil køre beholdere. Spørgsmålet er ikke "hvordan installerer jeg det", men hvor placerer jeg det. Og det er ingen smagssag, det er et spørgsmål om, hvor mange ting der går i stykker, når én ting går i stykker.

Tre placeringer

Direkte på værten. Det nemmeste, og netop det, man ikke skal gøre. Værten er det lag, alt andet hviler på. Alt, hvad du installerer der, ligger nu inden for skaderadius af hver eneste virtuelle maskine: en afhængighedskollision, en fuld disk eller en dårlig opdatering tager ikke kun dine beholdere, men det hele på én gang.

Inde i en systembeholder. Let og hurtigt sat op. Til gengæld kører du beholdere inde i en beholder, og den opsætning har sine egne skarpe kanter: rettighedsmodellen, filsystemlagene, den delte kerne. Valgt bevidst er det fornuftigt; valgt fordi "det var nemmere" giver det overraskelser.

Inde i en virtuel maskine. På papiret det tungeste og i praksis det reneste. Når beholderopsætningen falder sammen, er det én virtuel maskine, der falder sammen, ikke din server. Og vil du bygge den op igen, bygger du én maskine op.

Det ene spørgsmål, der afgør

"Hvis det her går i stykker, hvad sker der med alt det andet?" På værten er svaret "det hele", inde i en virtuel maskine er svaret "én af dem". Ressourceforbrug, hvor let det er at installere, alt det bliver sekundært ved siden af det svar.

Den anden halvdel: compose er et program

En compose-fil ligner opsætning. Det er den ikke. At køre den er at køre kode, og den kører med dine rettigheder. To linjer i den kan give beholderen hele maskinen.

Når folk kopierer en compose-fil fra nettet, føler de ikke det ubehag, de føler ved at kopiere en kommando. Forskellen ligger ikke i faren, men i udseendet: en kommando ligner en kommando, mens compose ligner en indstillingsfil. At ligne sådan gør den ikke sikker.

Fire linjer at se på før kørsel

Monterer den værtens filsystem indenfor. Beder den om privilegeret tilstand. Sender den beholderstyringens egen sokkel indenfor. Bruger den værtens net direkte.

De fire er de linjer, der gennemborer beholdergrænsen: findes en af dem, er den beholder ikke længere en beholder, den er værten selv. At læse dem tager ti sekunder, og de ti sekunder er mere værd end alt andet i denne artikel.

Hvad Atlas gør

Atlas gennemgår compose-filer og installationsscripts før installationen, og den gennemgang sidder på serveren og ikke i brugerfladen. Uanset hvad brugerfladen sender, kan kontrollen altså ikke springes over.

Fundene kommer i to niveauer. Rødt betyder noget, der løfter beholderen ud af beholdergrænsen, altså rettigheder svarende til værtens; i det tilfælde kræves udtrykkelig godkendelse. Gult betyder noget, der kan gøres bevidst, men som du skal have at vide. På applikationskatalogets side accepteres rødt slet ikke.

Der er én detalje mere, og den tæller: gennemgangen mener ingenting, den melder kendsgerningen. Den siger ikke "det her er farligt", den siger "denne linje gør det der". Den, der læser, beslutter, for den samme linje kan være acceptabel i én opsætning og uacceptabel i en anden.