RAM darbojošā VPN izpildes vide neko nepasaka par žurnāliem

VPN serveris, kas tiek palaists no tikai lasāma attēla un tur savu izpildes stāvokli tmpfs, ir reāls un noderīgs risinājums. To ir arī viegli aprakstīt kā tādu bez žurnāliem, ko risinājums nepierāda. Uzglabāšanas vieta nosaka, kur dzīvo kopija; vākšana un saglabāšana nosaka, vai ieraksts vispār pastāv, un restartēšana ietekmē tikai pirmo. Šo divu nošķiršana ir visa pārbaude.

Sāciet ar visu procesu uzskaitīšanu, kas var rakstīt stāvokli: dēmons, autentifikācijas pakalpojums, žurnāls, jebkurš uzraudzības aģents un pārvaldības rīki.

Uzglabāšana un vākšana ir dažādi jautājumi

Katram rakstītājam ir savs galamērķis un sava politika. VPN dēmons raksta stāvokļa failus, autentifikācijas aizmugure raksta konta notikumus, žurnāls vāc pakalpojumu izvadi, un uzraudzības aģents sūta metrikas pavisam citur. Risinājums, kas liek vienam no tiem pazust restartēšanas laikā, nav neko teicis par pārējiem trim. Sekojiet katram rakstītājam līdz tā galamērķim un atzīmējiet, vai šis galamērķis vispār ir mašīnā.

Lietotnei raksturīgi faili, augšupielādēta diagnostika un ārējie pakalpojumi prasa tādu pašu attieksmi. Pazīstama vietējā žurnāla neesamība nepierāda, ka savienojumu vai konta ieraksti nekur neeksistē; tā pierāda, ka vēl neesat atraduši, kur tie aiziet.

tmpfs nav garantija

Linux tmpfs nav fizisks RAM disks. Kodola dokumentācija skaidri norāda, ka lapas var rakstīt swap, ja montēšana to atļauj, tāpēc tmpfs fails var sasniegt disku, pat ja lietotne to tur nekad nav kopējusi. mount parāda, vai darbojas uz swap balstīts tmpfs, un citas atmiņas failu sistēmas uzvedas vēl citādi. Lasiet faktiskos montēšanas parametrus, nevis pieņemiet, ka ceļš zem /run nozīmē gaistamību.

Pēc tam uzskaitiet lietas, kas pārdzīvo restartēšanu veidos, ko cilvēki aizmirst: pastāvīgs augšējais slānis, pievienota glabātuve, hibernācijas attēli, avāriju izgāztuves un visas VM infrastruktūras momentuzņēmumi. Katrs no tiem ir iespējams galamērķis stāvoklim, ko uzskatījāt par īslaicīgu. Šis saraksts ir kaut kas pārbaudāms, nevis apgalvojums, ka katram resursdatoram ir visi.

Journald ir divi galamērķi un pārsūtītājs

Journald labi ilustrē sadalījumu. Gaistošā glabātuve tur ierakstus zem /run/log/journal, pastāvīgā zem /var/log/journal, un automātiskais režīms izvēlas starp tiem; spēkā esošais režīms nāk no darbojošās sistēmas, nevis no attēla apraksta. Pāreja uz gaistošo neizdzēš to, kas jau rakstīts pastāvīgi. Pārsūtīšana arī ir atsevišķs kanāls: pat glabātuves iestatījums, kas lokāli neko netur, var nodot ziņojumus citam mērķim.

Lasiet spēkā esošo režīmu no paša žurnāla vai tā konfigurācijas faila, pēc tam atsevišķi pārbaudiet pārsūtīšanas mērķus, jo viens iestatījums nevada otru.

Kam jāpārdzīvo restartēšana

Vide bez stāvokļa atbalsta atkārtojamu nomaiņu, un tai vajadzīgi apzināti avoti konfigurācijai, autorizācijai un atjaunošanas materiālam, ko pakalpojums nevar izdomāt. Zaudēt vienīgo strādājošo reģistrācijas vai atsaukšanas stāvokli, lai vietējie ieraksti pazustu, ir slikts darījums, un bieži sastopams. Izlemiet, kam apzināti jāpārdzīvo, pēc tam pārbaudiet, ka tas notiek.

Tā pati loģika attiecas uz darbības ierakstiem. Izlemiet, kuri notikumi drošībai un pakalpojumu pārvaldībai patiešām ir vajadzīgi, ar pamatotu tvērumu un saglabāšanu, un pārējo samaziniet līdz minimumam. Samazināšana nav tas pats, kas visas diagnostikas izslēgšana.

Salīdziniet spēkā esošo uzglabāšanas un pārsūtīšanas konfigurāciju ar dažiem nekaitīgiem notikumiem, pēc tam restartējiet vai nomainiet mašīnu un vēlreiz pārbaudiet, kas palika un no kurienes pakalpojums atjaunoja savu stāvokli.