Na de odáig el kell jutni. Azt a configot össze kell rakni és vannak olyan feladatok, amit először tökölsz ki életedben, nem készen veszed le a polcról és rakod ki.
És ezt miért a célgépen akarod kézzel tökörészni?
Aztán teszt szerveren életszagúbb adatokkal átpörgeted. Ha ok, akkor meg ki éles szerverre. Na de a fejlesztést, a kitökölést egy komplex problémánál muszáj nagyobb környezetben kipróbálni, pl. a fenti mail szerver. Nem az a kérdés, hogy hogy rakod a végleges configot vagy annak egy sorának módosítását.
Pedig az is kérdés. És az is, hogy fejben még nem álltál át deklaratív leírásra, hanem procedurálisan próbálod megfogni.
A különböző flagekkel akarsz játszani, kell egy új feature. Hol hozod össze azt a végleges sort, amit majd kitelepítesz?
Alapvetően a Puppet modul rakja össze, nem én, én csak belenyúltam a template-be, hogy legyen változás, amit tudok demózni.
Gyanítom nem próbálkozásonként módosítod a mgmt toolt, hogy deploy config....á nem jó, módosít, újra deploy, még mindig nem jó. Mert ez így hatalmas overhead.
De. Mi az overhead? Push kimegy a megfelelő szerverre, azonnal. Ami hatalmas előny: nyoma van, hogy mit csináltál és mikor csináltad, vissza tudsz állni egy korábbi működő állapotra, létre tudsz hozni egy játszós-szervert, minimális melóval, mert csak megmondod a CMDB/CMT eszköznek, hogy legyen még egy szerver virtualizálva, ilyen-és-ilyen class, role, whatever és ott lesz, anélkül, hogy munkád lenne vele. Aztán azon megoldod, amit meg akarsz oldani, és ha megvan, akkor megy a szokásos merge-flow, akár squash commit mellett a végleges konfigurációba. Nem nagyon lehet másképp, ha nem akarsz a nyakadba venni egy valag üzemeltetési kockázatot.
Én nem tudok olyanról, aki vissza szeretne térni az old school kézi módosításokra, ha már egyszer átállt erre a működésmódra... sokan a fejüket verték a falba, hogy évekig szoptak feleslgesen, mert nem tudták, hogy ez milyen a gyakorlatban. Nyilván meg kell tanulni, ki kell alakulnia a készségeknek, de onnan triviális lesz.