konfiguráció management

Hali,

Kíváncsi vagyok, ki hogyan csinálja (csinálná) több 10K linux szerver központi OS konfig managelését.

Azt gondolom, hogy egy szerver OS konfigját meghatározzák bizonyos paraméterei, pl.
* DC
* pillar (dev > prod)
* service (oradb, mysql, mq, tomcat, stb. stb.)
* rajta futó üzleti alkalmazás
* mittudomén

Ezekből összejön mondjuk 10-20-30 szerver csoport, amikbe a szerverek tartoznak.

Egy-egy csoport jól meghatározott OS konfigot jelent (timezone, loggolás, adminok akik beléphetnek, nyitott portok, bármi). A konfig mondjuk verziózva is lehet, de ez most nem fontos.

Ezt a konfigot hogyan a legjobb folyamatosan kiforce-olni a gépekre (óránként, naponta, tökmindegy) úgy, hogy akár még azt is be lehessen állítani, hogy bizonyos paraméter ha eltér a standardtól akkor csendben javításra kerüljön, vagy javításra kerül és bekerül vmi napi riportba vagy javításra kerül és azonnal incidens nyílik róla?

Teljesen teoretikus a kérdés, csak a tapasztalatokra vagyok kíváncsi.

Köszi.

Hozzászólások

Szerintem nem jo automatikusan folyamatosan forecolni a konfigot tul rendszeresen prodba. Ha van 10-30 szerver csoportod, akkor mindig lesz 1-2 specialis eset amit az automatikus konfig nem fog tokeletesen kezelni. Ha ezt erobol lenyomod mindig akkor garantalt, hogy valami bajt okozol.
Plusz lesz egy csomo olyan parameter, amit nem tudsz az app/barmi ujrainditasa nelkul megvaltoztatni akkor vagy a konfig managernek ujra kell inditania az appot, vagy kezi beavatkozas szukseges.

Szerintem a legjobb megoldas a kozeput:
Dev/stagingre akar mehet automatikusan, de prodra en mindenkeppen felugyelet mellett csinalnam csak (kiveve, ha valami jol tesztelt, trivialis valtozas)

+ a jo dontest csak az adott rendszer ismereteben lehet meghozni szerintem

--
http://blog.htmm.hu/

Abból indulnék ki, hogy nincs kivétel vagy nagyon minimális százalékban (legyenek mondjuk egy n+1., nem managelt csoport szerverei).

> Plusz lesz egy csomo olyan parameter, amit nem tudsz az app/barmi ujrainditasa nelkul
> megvaltoztatni akkor vagy a konfig managernek ujra kell inditania az appot, vagy kezi beavatkozas szukseges.

Például erről is szól a kérdés.
Konfig módosítás (vagy fixálás) és utána service reboot.
Ekkora környezetben nem lehetnek single point of failure service-ek, amiket nem lehet akármikor restartolni/reload-olni.
De ez jó ötlet, a tool azt is tudhatná, hogy beszól a change management rendszernek, hogy s1,s2,..,sn szerveren megmódosította az x,y,z konfigot.

> prodra en mindenkeppen felugyelet mellett csinalnam csak (kiveve, ha valami jol tesztelt, trivialis valtozas)

Itt két dolgot tudok elképzelni:
(1) már a dev szerver csoportok is "élesek" olyan szempontból, hogy nem mehet rá teszteletlen konfig, tehát kell egy konfig dev>teszt környezet (költségben eltörpül az igazi infra mellett)
(2) csak a prod szerver csoportok élesek és csak olyan konfig mehet ki rájuk, aminek az életciklusa bejárta az alatta lévő csoportokat

Én az (1)-et preferálnám.

> Ekkora környezetben nem lehetnek single point of failure service-ek, amiket nem lehet akármikor restartolni/reload-olni.

Ez jogos meglatas, de a valosag sajnos sokszor kozbeszol (ha nincs is klasszikus SPOF, de mondjuk egy clusternel, vagy egyeb aktiv-passziv rendszernel ennek lehetnek rovid ideig prodra is kihato hatasai amirol az SLA fuggvenyeben ertesiteni kell az ugyfelet vagy legalabb is jol meghatarozott idoben csinalni)

> De ez jó ötlet, a tool azt is tudhatná, hogy beszól a change management rendszernek, hogy s1,s2,..,sn szerveren megmódosította az x,y,z konfigot.

Ez mar keso, nem? Szerintem akkor elso sorban a change managementnek a konfig modositast kellene kovetnie es nem a deployt. (Nalunk vannak olyan rendszerek, ahol minden commithoz kotelezo megadni a ticket szamot es a VCS belekommentalja a ticketbe a commit logot)

> (1) már a dev szerver csoportok is "élesek" olyan szempontból, hogy nem mehet rá teszteletlen konfig, tehát kell egy konfig dev>teszt környezet (költségben eltörpül az igazi infra mellett)

Akkor hol teszteled eloszor?
Sajnos a tapasztalat azt mutatja, hogy sokszor nem torpul el annyira a teszt rendszer koltsege a Prod mellett (ha vannak olyan race conditionjaid peldaul amik nem jonnek elo ha a storage nem tud mondjuk 50kIOPS -t vagy nincs 10Gbe halozat, stb...)

--
http://blog.htmm.hu/

Ekkora környezetben nem lehetnek single point of failure service-ek, amiket nem lehet akármikor restartolni/reload-olni.

Nade ezen a ponton akkor tudnod kell, hogy a maradék redundancia megvan-e még rendszerben, tehát a többi része a rendszerednek éppen képes-e még érdemi munkát végezni. Amihez pedig funkcionális teszteket végző monitoringra lesz szükséged, per komponens. Plusz a függőségek gépi nyilvántartására (pl. ennek a webes alkalmazásnak erre az adatbázisra van szüksége).

Ezzel egyetertek, viszont altalaban amig nem derul ki addig nem tud rola senki (nahat). Pont arra gondoltam, hogy legyen az uzemeltetes arra is felkeszulve legalabb process szinten, hogy mi van, ha a valaki nem jol csinalta meg a hazifeladatat rendesen.
Hogy azt ugy oldod meg, hogy sysadmin inditja jokor, vagy biztos vagy benne, hogy van eleg hibakezeles a konfig managementedben az reszletkerdes, de kell, hogy legyen valami.

--
http://blog.htmm.hu/

Szerintem push a járható út, már tízezernél lényegesen kevesebb node esetén is... ha változik a konfig, akkor az érintett node-ok megkapják a különbséget, újrahúzásnál pedig a node kéri el a teljes konfigot.

--
https://iotguru.live

Ez az, amit neked kell eldöntened/letesztelned, mert van rá kismillió tool.
itt egy kisebb lista:
https://www.thorntech.com/2018/04/15-infrastructure-as-code-tools/

Én speciel ansible-t használok, az push (létezik már ansible-pull is, de még nem néztem), de nagy mennyiségű szerverre lehet lassú.

> Én speciel ansible-t használok, az push (létezik már ansible-pull is, de még nem néztem), de nagy mennyiségű szerverre lehet lassú.

Szinten Ansible user. Ha automatikus push van es az lehet aszinkron akkor a futasido annyira nem fontos altalaban amig belefer a rendelkezesre allo idoablakba (ha mondjuk hetente akarod kitolni a teljes konfigot akkor van ra egy heted)

--
http://blog.htmm.hu/

Jani miért gányolna bele helyi szintű konfigokba? Pont arról szól a sztori, hogy konfig menedzsment van egy konfig menedzsment eszköben.

Konfigok ansibleben, terraformban, octopusban, whateverben. Nem helyi fájlokban.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A dolog neheze, hogy amint te módosítasz egy konfigot központilag, onnan az az összes gépen eltér a strandardtól ami ezáltal tízezrével kerül be a reportokba . Onnan pedig droid legyen a talpán aki minden nap átolvassa és kiszúrja azt az 1-2 sort ami a bakiból adódó felülírásról szól. Valamiféle commithoz kötött push technikával ezt el lehetne kerülni, de ez a működés nem jellemző a mai SCM-ekre és elméletben is rengeteg kérdést vet fel.

A többi egyébként tök alap, amit kb bármelyk mai SCM-mel megoldható. Puppet-tel biztosan.

Ekkora környezetben sosem kellett konfig menedzsmentet használnom, de kisebb léptékben évek óta az Ansible-t használom a kényelme és az egyszerűsége miatt (nincs master/slave, agent, stb, csak sh kell neki), iszonyú sok modulja van, ami miatt nagyon rugalmasan használható.

hasonlot csinaltam de nem ekkora meretben, push helyett pull-t hasznaltam ansible-vel.
van neki egy local futtatas modja, az meg hogy mit kell futtatni (playbook + modulok + config) git segitsegevel lett kirakva a gepre.
maga a playbook cronbol futott, ott ha becsomagolod egy scriptbe a futtatast akkor tudod vizsgalni a vegeredmenyt (failed, vagy ha sikerult de volt change) es tetszoleges helyre tudsz reportolni.

Tedd ki a konfigot gitre, minden gepen ansible, cron lehuzza a playbookokat git-bol es ansible-playbook -i localhost.
A git repok legyenek ertelmesen csoportositva - a PROD repoba csak esszel comittolsz... Ehhez csak egy kelloen nagy git server szukseges - ha esetleg a cron egyszere uszitja ra a hostocat :) De ezt lehet tervezni jol.
Manageltem igy tobbszaz gepet, de lehetett volna akar tobb ezer is - a halozat es a git server szab(hat) hatart a skalazhatosagnak... Egyebkent ansible-pull amit keresel.

Hát ezt sok komponensből össze lehet legózni. Pl. van egy cloud-os infra cloudban. *Mindent* Terraform meg Ansible épít fel, ergo ha legyakod az egészet, akkor is újra tudsz húzni mindent mulláról pár kattintással.

Beállítások Octopusban, onnan indulnak a virtuális gépek felhúzása, azon belül, hogy hova milyen docker konténer kerüljön, milyen egyéb cloudos szolgáltatásokat veszünk igénybe, amiket nem akarunk mi üzemeltetni, stb. stb. stb. Octopusba meg a build szerver kimenetéből jönnek a packagek, amikből lesznek a releasek.

Olyan meg nincs, hogy valamelyik szerveren, docker imageben, stb. eltér valami, mert senki nem szerkeszt konfig fájlt. Központi menedzsment egy másik koncepció, mint a "bemegyek X szerverre és megeditálom a random fájlt". Vagy compose/env fájl az infra GIT repójában vagy octopus változó az, ami szerkesztve lesz, vagy valami konfig állomány, ami szintén a fenti pipelinen megy ki.

Méretileg nem 10K linuxos szerver ellenben van benne skálázódó dolog is (vannak időnként kifejezetten burst jellegű terheléseink is, amire pont jó a cloud). Meg igazából az egész a saját termékeink köré épül.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Szerintem a problema megkozeliteset kellene atgondolni, mert itt massziv CI/CD a jarhato es itt a hangsuly az egyes szolgaltatasokon van, nem pedig az egyes szervereken, ezert ez megvaltoztatja a valtozaskezelest (legyen az barmi - security fix, infrastrukturalis valtozas vagy egy uj kod release az egyik szolgaltatasban).

Inkabb a microservices architektura megoldasok kialakitasa immutable rendszerekkel iranyaba menj el, service discovery, service mesh es tarsai.
Ekkora kornyezetben, mar end-to-end automatizacio kell, ahol az nem igeny, hogy mondjuk egy klaszternek csak az egyik tagjan valtoztatsz egy beallitast.
Ha infrastruktura szolgaltatas valtozik (peldaul DNS), akkor azt gossip protokollon keresztul kapod meg, nem kell hozza Ansible vagy Puppet.

+100 Koszonom, hogy emlitetted! :-)

Vagrant + Packer + Consul + Vault + Terraform + Nomad

Nagyon szeretem a HashiCorp termekeit es foleg azt a filozofiat amit ok kepviselnek, mert a termekek gyonyoruen kiegeszitik egymast es jol mutatjak, hogy lehet lepesrol-lepesre magasabb es komplexebb szintre jutni.

A Nomad lehet a kapocs ha on-premises kornyezetbol szeretne valaki atterni K8s-re.
Uzemeltetoi szemmel ugy gondolom, hogy nagyon nagy ugras VMs kornyezetben szerzett tapasztalotokrol egybol K8s-re ugrani foleg ugy, hogy ha meg a VMs kornyezetben sem sikerult megvalositani a Continuous Deploymentet es ezt meg lehet tetezni a clouddal.

Visszaterve az eredeti problemahoz, ez egy nagyon jo felvetes es kihivassal teli feladat.
Amit elsore nehez megemeszteni, hogy itt bizony egy jelentos szemlelet valtasra lesz szukseg, ami ujabb technologiak/megoldasok bevezeteset fogja jelenteni illetve azt hogy bizonyos feladatokat mas szinten kell megoldani.

Ami ujabb nehezseg, hogy ki kell lepni a komfort zonabol es a regi "statikus" infrastrukturat "dinamikussa" kell tenni, ami azt jelenti, hogy az egyes epito elemek (virtualis gep, kontener) eletciklusa jelentosen lecsokken (hetekre/napokra/orakra) es csak "epizod szereplok" lesznek, mert folyamatosan kell majd deployolni a biztonsagi frissitesek es a kodvaltozasok miatt.

A mi rendszerunk a kovetkezo keppen epul fel. Az egesz infra AWS-t hasznal jelenleg egy DC de jovore tervben van meg egy.

A legtobb instanceunk immutable. Barmikor eldobhatjuk vagy ujra deployolhatjuk az instanceket. Ez alol pl. elasticsearch hot/warm nodejai a kivetelek.

Az AWS servicek managmentje az terraforombol tortenik a fobb modulokhoz vannak rendes tesztek. Mint egy normalis alkalmazashoz.

A terraform change az a kovetkezokeppen nezki:
feature branch -> pull request -> review -> master -> deploy

Az instancek indulas utan ansiblelel huzzak magukra a sajat configjukat. Ami beallit egy cron-t es 5 perckent lehuzza a legfrissebb configot s3-rol.

Az ansible change az a kovetkezokeppen nezki:
feature branch -> pull request -> review -> master -> s3

A terraform es az ansible mint az osszes tobbi alkalmazas review folyamaton megy keresztul es automatikusan deployolodik productionbe.

Az elasticsearch data nodek amik kivetelek a rendszerben ott nincs auto apply az elasticsearch configokra.

Az instancek 97% spotinstet hasznal ugy ,hogy vizsonylag gyorsan jonnek be es mennek ki az instancek. Ami egy fajta chaos monkey megvalositas is.

Nagyabbol olyan 150+ instanceunk van ebbol az alkalmazas kiszolgalas kb 100-110 csucsidoben. Autoscaling van szoval nem kell mindig ennyit tartani a rendszerbe :D.

Minden alkalmazas dockerben fut es kubernetest hasznal igy azert kicsit konnyebb dolgunk van. :)
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Szeptember ota az EKS-t hasznaljuk addig nem igazan volt production ready :D. A jelenlegi rendszerben nincs SQL. De ha lesz biztosan Aurorat fogunk hasznalni. Az elasticsearch sajat uzemeltetesu ott az i3 meg d2 instanceket hasznalunk es a belso diszkekre epitunk.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Koszonom, hogy megosztottad a ti megoldasotokat.

Az erdekes resz a tortenetnek a review es a deployment, illetve a Kubernetes klaszter menedzsment.

feature branch -> pull request -> review -> master -> deploy

Mennyi K8s klasztert hasznaltok, illetve hogyan valositjatok meg a reviewt es a deploymentet?
A fenti workflowban melyik folyamat(ok)ban van CI vagy QA resz?

Ha mar deployment; milyen tipusu deploymentet (blue/green, canary, stb) hasznaltok?

Koszonom a valaszod.

Kubernetes clusterbol 1 van.
A feature branch review, pull request, master -> ez githubon tortenik, approve nelkul nem lehet behuzni semmit a master agba.

Az alkalmazas deploy egy kicsit elter ettol.

Ez a jelenlegi.

feature branch -> pull request -> review -> staging -> deploy
staging -> pull request -> master -> deploy

Viszont elkezdtuk kivezetni magat a staging rendszert. Eleg sok service van es felesleges komplexitas.

A jelenlegi deploy sima rolling-update vagy kezi canary. De eleg sok feature flaget hasznalunk igy igazabol mehet minden prodba es csak 1-1 usernek van bekapcsolva elsore egy feature.

Az igazani canary deployment jovo ev elejere varhato nalunk,hogy elkezdjuk bevezetni.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Koszonom, hogy megosztottad.

Az atomi jellegu valtozasok kezeleset automatikus canary vagy blue/green deployment (bar ez utobbi picit koltsegesebb) hasznalataval valoban ki lehet valtani a staginget, mert ahogy mondani szoktak nincs jobb teszteles, mint elesben, a realisztikus forgalom atterelesevel.

A toggle features hasznalata, pedig visszaadja a lehetoseget, hogy minel hamarab bevezessenek egy új featuret, illetve, ha problemas kikapcsoljak ujabb deployment vagy roll back nelkul.

Igen de alkalmazunk dark launchot is.

De canary-re mar nagy szuksegunk van viszont a bevezetese eleg nehez es korulmenyes ( eleg sok edukacioval jar ) plusz eleg keves tool van a piacon ami ezt jol tudja plusz ki elegiti az igenyinket.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

Dolgoztam nagyon hasonló projekten, itt a teljes konfiguráció management kódra épült (Puppet, illetve szükség esetén PowerShell).
Kritérium volt, hogy a teljes infrastruktúra (az applikációs réteget is ideértve, tehát a külső komponensekről és a belső fejlesztésekről is csomagok készültek) bármikor a 0-ról újraépíthető legyen.
A kód természetesen verziókezelés alatt állt, CI / CD-vel jutott el a repository-kba, illetve a kezelt gépekre.

Mikrószegmentáció volt: rengeteg szeparált környezetet építettek, ahol az infrastrukturális elemek és az applikációk is szegmentálva voltak, minden ilyen szeparált környezetnek volt dev, stag és prod ága, valamint redundáns volt a DCk között.

A dolognak kétségkívül volt előnye, viszont rengeteg buktatója is, amit már a tervezésnél érdemes elkerülni.