VPN-runtime i RAM siger intet om logs

En VPN-server, der starter fra et skrivebeskyttet image med sin runtime-tilstand på tmpfs, er et reelt og nyttigt design. Det er også let at beskrive som uden logs, hvilket designet ikke godtgør. Lagerplaceringen bestemmer, hvor en kopi bor; indsamling og opbevaring bestemmer, om en post overhovedet findes, og en genstart påvirker kun det første. At holde de to ting adskilt er hele gennemgangen.

Begynd med at liste hver proces, der kan skrive tilstand: daemonen, godkendelsestjenesten, journalen, enhver overvågningsagent og administrationsværktøjerne.

Lagring og indsamling er forskellige spørgsmål

Hver skriver har sin egen destination og sin egen politik. VPN-daemonen skriver statusfiler, godkendelsesbackenden skriver kontohændelser, journalen indsamler tjenesteoutput, og en overvågningsagent sender målinger helt andre steder hen. Et design, der får en af disse til at forsvinde ved genstart, har intet sagt om de øvrige tre. Følg hver skriver til dens destination, og noter, om destinationen overhovedet er på maskinen.

Applikationsspecifikke filer, uploadede diagnoser og eksterne tjenester skal behandles på samme måde. Fraværet af en velkendt lokal log beviser ikke, at forbindelses- eller kontoposter ikke findes nogen steder; det beviser, at du endnu ikke har fundet, hvor de går hen.

tmpfs er ikke en garanti

Linux tmpfs er ikke en fysisk RAM-disk. Kernelens dokumentation siger udtrykkeligt, at sider kan skrives til swap, når monteringen tillader det, så en tmpfs-fil kan nå en disk, uden at applikationen nogensinde kopierer den dertil. mount viser, om en swap-støttet tmpfs er i spil, og andre hukommelsesfilsystemer opfører sig igen anderledes. Læs de faktiske monteringsindstillinger i stedet for at antage, at en sti under /run betyder flygtighed.

Tag derefter inventar over de ting, der overlever en genstart på måder, folk glemmer: et vedvarende overlay, tilsluttet lager, hiberneringsbilleder, nedbrudsdumps og infrastruktursnapshots af hele VM'en. Hver af dem er en mulig destination for tilstand, du troede var efemer. Listen er noget, der skal kontrolleres, ikke en påstand om, at hver vært har dem alle.

Journald har to destinationer og en videresender

Journald illustrerer opdelingen fint. Flygtigt lager holder poster under /run/log/journal, vedvarende lager under /var/log/journal, og automatisk tilstand vælger mellem dem; den gældende tilstand kommer fra det kørende system og ikke fra imagets beskrivelse. Skift til flygtigt sletter ikke det, der allerede er skrevet vedvarende. Videresendelse er også en separat kanal: selv en lagerindstilling, der intet holder lokalt, kan overlevere meddelelser til et andet mål.

Læs den effektive tilstand fra journalen selv eller dens konfigurationsfil, og kontroller derefter videresendelsesmålene separat, fordi én indstilling ikke styrer den anden.

Hvad skal overleve en genstart

En stateless runtime understøtter gentagen udskiftning, og den kræver bevidste kilder til den konfiguration, godkendelse og det gendannelsesmateriale, som tjenesten ikke selv kan opfinde. At miste den eneste fungerende tilmeldings- eller tilbagekaldelsestilstand for at få lokale skriv til at forsvinde er en dårlig handel, og en almindelig. Beslut, hvad der bevidst skal overleve, og verificér derefter, at det gør det.

Samme ræsonnement gælder for driftsregistreringer. Beslut, hvilke hændelser sikkerhed og tjenestestyring reelt kræver, med et begrundet omfang og en begrundet opbevaring, og minimér resten. Minimering er ikke det samme som at slå al diagnostik fra.

Sammenlign den effektive lager- og videresendelseskonfiguration med nogle få harmløse hændelser, genstart eller udskift derefter maskinen, og kontroller igen, hvad der blev tilbage, og hvor tjenesten gendannede sin tilstand.