Unufoja bootado el bildo ne igas Pi rekonstruebla aparato. Mankas malgranda aro da enigaĵoj, kiujn vi povas reapliki: prizorgata bazo, deklarita agordo, la daŭraj datumoj de la aplikaĵo kaj identeco de aparato, kiu apartenas nur al tiu tabulo. Se vi preterlasos la lastan, ĉiu anstataŭigo fariĝos klono de akreditaĵo.

La subaj paŝoj estas laborordo, ne rekomendo de ilo. Taŭgas ajna agordsistemo, kiu povas esprimi ilin.

Unue listigu la kvar specojn de enigaĵoj

La baza bildo kaj ĝiaj pakaĵoj difinas la operaciumon, la arkitekturon kaj de kie venas ĝisdatigoj, kaj bildkonstruilo helpas nur se la ilo, kiun ĝi nomas, ankoraŭ estas prizorgata por via eldono. La deklarita agordo estas la parto, kiun homo revizias: retaj roloj, servaj agordoj kaj la vivociklaj agoj, kiujn ĉiu servo bezonas. Daŭraj aplikaĵaj datumoj estas ĉio, kion la servo ne povas relegeneri, kaj ilia loko kaj sekurkopia metodo apartenas al tiu aplikaĵo, ne al la bildo. Aparataj identecoj kaj sekretoj estas la kvara enigaĵo, kaj ilin homoj forgesas, kiam ili klonas funkciantan karton.

Skribu la kvar listojn antaŭ ol rekonstrui ion ajn. Listo kun malplena vico estas decido, kiun vi ankoraŭ ne faris.

Tenu sekretojn ekster la deponejo kaj diru, kie ili loĝas

Deponejo estas bona hejmo por reviziitaj ŝablonoj kaj ne-sekreta agordo, kaj malbona hejmo por privataj ŝlosiloj de VPN, reuzeblaj administraj akreditaĵoj kaj diagnozaj arkivoj. Se sekreto devas ekzisti sur la aparato, notu, de kie ĝi venas, kiu povas legi ĝin kaj kiel ĝi rotacias. Ŝlosilo, kiu loĝas nur sur unu SD-karto, estas ununura punkto de fiasko, dum ŝlosilo kopiita al ĉiu tabulo estas akreditaĵo de la tuta floto sen posedanto. Nek unu nek la alia estas reakira plano.

La testo estas simpla: se la deponejo likus morgaŭ, kion gajnus atakanto? Ŝablonoj kaj topologiaj notoj postvivos. Funkcianta identeco ne.

Lasu aŭtomatigon posedi tion, kion ĝi povas relanĉi

La modelo de Ansible tenas inventaron de administrataj nodoj aparte de teatraĵoj, taskoj, roloj kaj traktiloj, kiuj aktiviĝas kiam tasko raportas ŝanĝon. Uzu tiun strukturon por doni al ĉiu servo unu agordan posedanton anstataŭ reludi ŝelan historion. Preferu operaciojn sekurajn por duobla rulado, kaj konscie decidu, kiel ŝanĝita dosiero atingas la kurantan procezon. Tasko, kiu certigas, ke servo startis, ne nepre igas ĝin reŝargi agordon, kiun vi ĵus reverkis.

Apartigu ankaŭ la etapojn de administrado. Starta konektebleco, rutina agordado kaj VPN-dependa administrado estas tri malsamaj fenestroj, kaj la tria povas forigi vian propran aliron, se la rekonstruo restarigas la reton sub ĝi. Konservu sendependan enirvojon.

Restaŭru datumojn kaj identecon intence

Konteneraj volumoj daŭras sendepende de la vivociklo de la kontenero, dum la skribebla tavolo ene de kontenero ne, tial rekreado de kontenero el ĝia bildo ne rekreas la staton, kiun la aplikaĵo uzis, kiel priskribas la dokumentaro pri volumoj. Notu la volumenojn, bind-muntaĵojn kaj eksterajn servojn, de kiuj la aparato dependas, kaj uzu la propran sekurkopiadan kaj restaŭran procezon de la aplikaĵo. Kontenero, kiu startas sen eraro, ne estas pruvo, ke ĝia datumbazo kaj ĝiaj dosieroj kongruas.

Pri identeco decidu, ĉu vi restaŭras la saman aparaton aŭ registras anstataŭaĵon, ĉar tiuj estas malsamaj operacioj kun malsama purigado.

Akordigu la aliron de la malnova samtavolano antaŭ ol aktivigi identecon aliloke, kaj nur poste testu la rekonstruitan aparaton en izolita aŭ restaŭra medio. Kontrolu la necesajn datumojn, la ĝustan identecon, ĝisdatigan vojon kun posedanto kaj la celatan retpolitikon.

Butebla bildo estas unu enigaĵo el kvar, kaj ĝi estas la plej facile reproduktebla.

Rilataj artikoloj