VPN okruženje u RAM-u ne govori ništa o dnevnicima

VPN poslužitelj koji se podiže s imagea samo za čitanje i drži radno stanje u tmpfsu stvaran je i koristan dizajn. Lako ga je i opisati kao bez dnevnika, što dizajn ne dokazuje. Mjesto pohrane određuje gdje kopija živi; prikupljanje i zadržavanje određuju postoji li zapis uopće, a ponovno pokretanje utječe samo na prvo. Razdvajanje to dvoje cijeli je pregled.

Počnite popisom svakog procesa koji može pisati stanje: daemon, servis za autentifikaciju, dnevnik, bilo koji agent za nadzor i alati za upravljanje.

Pohrana i prikupljanje različita su pitanja

Svaki zapisivač ima svoje odredište i svoju politiku. VPN daemon piše datoteke stanja, pozadina za autentifikaciju piše događaje računa, dnevnik prikuplja izlaz servisa, a agent za nadzor šalje metrike posve drugdje. Dizajn koji učini da jedno od toga nestane pri ponovnom pokretanju nije rekao ništa o ostala tri. Pratite svakog zapisivača do njegovog odredišta i zabilježite je li to odredište uopće na stroju.

Datoteke specifične za aplikaciju, učitana dijagnostika i vanjski servisi trebaju isti tretman. Nedostatak poznatog lokalnog dnevnika ne dokazuje da zapisi o vezama ili računima ne postoje nigdje; dokazuje da još niste pronašli kamo idu.

tmpfs nije garancija

Linux tmpfs nije fizički RAM disk. Dokumentacija kernela izričito navodi da se stranice mogu zapisati u swap kada to montiranje dopušta, pa tmpfs datoteka može doći na disk bez da je aplikacija ikada tamo kopirala. mount pokazuje je li tmpfs podržan swapom u igri, a drugi memorijski datotečni sustavi ponašaju se opet drugačije. Čitajte stvarne opcije montiranja umjesto da pretpostavite da putanja pod /run znači hlapljivost.

Zatim popišite stvari koje nadžive ponovno pokretanje na načine koje ljudi zaboravljaju: trajni overlay, priključena pohrana, slike hibernacije, dumpovi padova i infrastrukturne snimke cijelog VM-a. Svaka je moguće odredište za stanje koje ste smatrali efemernim. Taj popis je nešto što treba provjeriti, a ne tvrdnja da svaki host ima sve od toga.

Journald ima dva odredišta i prosljeđivač

Journald lijepo ilustrira podjelu. Hlapljiva pohrana drži unose pod /run/log/journal, trajna pod /var/log/journal, a automatski način rada bira između njih; način koji je na snazi dolazi iz pokrenutog sustava, a ne iz opisa imagea. Prebacivanje na hlapljivo ne briše ono što je već trajno zapisano. Prosljeđivanje je također zaseban kanal: čak i postavka pohrane koja lokalno ne drži ništa može poruke predati drugom cilju.

Pročitajte efektivni način rada iz samog dnevnika ili njegove konfiguracijske datoteke, zatim odvojeno provjerite ciljeve prosljeđivanja, jer jedna postavka ne kontrolira drugu.

Što mora preživjeti ponovno pokretanje

Okruženje bez stanja podržava ponovljivu zamjenu i treba namjerne izvore za konfiguraciju, autorizaciju i materijal za oporavak koji servis ne može izmisliti. Izgubiti jedino radno stanje upisa ili opoziva kako bi lokalni zapisi nestali loša je trgovina, i česta. Odlučite što mora namjerno preživjeti, zatim provjerite da preživi.

Isto razmišljanje vrijedi za operativne zapise. Odlučite koje događaje sigurnost i upravljanje servisima stvarno zahtijevaju, s opravdanim opsegom i zadržavanjem, a ostalo svedite na minimum. Minimiziranje nije isto što i isključivanje svake dijagnostike.

Usporedite efektivnu konfiguraciju pohrane i prosljeđivanja s nekoliko bezopasnih događaja, zatim ponovno pokrenite ili zamijenite stroj i ponovno provjerite što je ostalo i odakle je servis obnovio svoje stanje.