"Pokud se pomocí SSH přihlašujete na servery a něco tam děláte, děláte to špatně. Toto zaznělo letos na LinuxDays hned v několika přednáškách. Jak to dělat lépe?"
Systémů pro vzdálenou správu je samozřejmě více, ale všechny mají jeden nepříjemný efekt, a to ten, že člověk, který je používá, postupně zapomene, jak se ty věci nastavují ručně.
Což v případě, že nějaký automatický systém vypadne (a on vždy vypadne v tu nejhorší možnou chvíli) znamená, že kromě výpadku systému se ti lidé za běhu učí (často dost tristní pohled) co vlastně kde a jak nastavit. Takže ten člověk postupně ztrácí schopnost nastavovat ten server a stane se z něj jen operátor těch udělátek.
Nehledě na to, že samotný linux poskytuje řadu nástrojů, jak si život ulehčit, takže něco nastavit na deseti serverech neznamená se na každý ručně přihlásit a něco tam udělat. Buď se to udělá přes x paralelních ssh spojení (cssh, parallel ssh, Konsole, PAC Man apod), nebo i pomocí jednoduchého cyklu v bashi apod.
Velmi často je to mnohem rychlejší, než "efektivní" manažer.
Ty mají smysl u velkého počtu serverů, kde "velký počet" bych z vlastní zkušenosti viděl v řádu stovek.
Příspěvky Ansible – hromadná správa serverů
Já těch serverů nemám až tolik (méně než dvě desítky) a stejně silně uvažuji o nasazení centralizované správy (něco už centrálně řešené mám, ale není to udělané úplně optimálně). Často potřebuji něco nakonfigurovat na více serverech stejně - dělat to ručně je ubíjející a náchylné na chyby (snadno se na nějaký server zapomene). Nemyslím si, že bych používáním nástroje ztrácel nějaké schopnosti, protože stejně musím nejdřív vědět, co jak chci nastavit (a mnohdy musím i tak do manuálu, protože konfigurovat například Postfix často není zrovna triviální) a teprve potom bych to vnutil tomu udělátku.
"protože stejně musím nejdřív vědět, co jak chci nastavit"
Pokud si ten modul budeš vytvářet sám, tak v pořádku. Ale zejména u Puppetu se setkávám s tím, že někdo vezme hotový pp (příklad: lamp), spustí puppet apply lamp.pp, a hurá, má server, kde do /var/www/html nahraje svůj web (někdy ani to ne, protože má nějaký deployer) a vůbec neví, že tam má Apache, MySQl, vedle toho třeba ještě do světa otevřený phpmyadmin apod.
Já aplikuju spíš "test driven administraci", tedy že si nejdříve v Icinga (Nagios) nadefinuju co chci nastavit (nový check na skupině serverů) a potom, kdybych třeba zapomněl na nějaký server, to v tom monitorovadle furt bude strašit (a mimo jiné po downtime taky chodit notifikace).
Pokud si ten modul budeš vytvářet sám, tak v pořádku. Ale zejména u Puppetu se setkávám s tím, že někdo vezme hotový pp (příklad: lamp), spustí puppet apply lamp.pp, a hurá, má server, kde do /var/www/html nahraje svůj web (někdy ani to ne, protože má nějaký deployer) a vůbec neví, že tam má Apache, MySQl, vedle toho třeba ještě do světa otevřený phpmyadmin apod.
Já aplikuju spíš "test driven administraci", tedy že si nejdříve v Icinga (Nagios) nadefinuju co chci nastavit (nový check na skupině serverů) a potom, kdybych třeba zapomněl na nějaký server, to v tom monitorovadle furt bude strašit (a mimo jiné po downtime taky chodit notifikace).
Ansible (a obecně cfg mgmty) jsou jen nástroje, jak si to budeš dělat je na Tobě. Můžeš to dělat dobře, nebo špatně. Je jedno s čím toho dosáhneš, jestli použiješ ssh, Ansible nebo Puppet. Ad "stará dobrá ssh práce": spoustu uživatelů/junior_adminů si najde tutoriál a pak copy-pastují do mrtva, druhý den zapomenou jak to nastavili.
U cfg mgmtu ten správný postup je obvykle psát si vše sám od píky a testovat, testovat a testovat. Obecně je použití cfg mgmtu obvykle lepší z důvodu, že alespoň při nějaké tragedii jsou k dispozici ty recepty a teoreticky je rychlejší vše dát zase do pořádku.
Jinak Ansible je orientován imperativně kdežto Puppet/Chef/Salt jsou deklarativní systémy. Je to jiný přístup, oba se mohou doplňovat (např. spouštět Puppet pomocí Ansiblu nebo různé kombinace).
Jestli chce někdo doporučení s čím začít, tak bych doporučil právě Ansible, v případě nutnosti použití deklarativního nástroje pak asi Salt. A pochopitelně Foreman jako hlavní inventář :-)
U cfg mgmtu ten správný postup je obvykle psát si vše sám od píky a testovat, testovat a testovat. Obecně je použití cfg mgmtu obvykle lepší z důvodu, že alespoň při nějaké tragedii jsou k dispozici ty recepty a teoreticky je rychlejší vše dát zase do pořádku.
Jinak Ansible je orientován imperativně kdežto Puppet/Chef/Salt jsou deklarativní systémy. Je to jiný přístup, oba se mohou doplňovat (např. spouštět Puppet pomocí Ansiblu nebo různé kombinace).
Jestli chce někdo doporučení s čím začít, tak bych doporučil právě Ansible, v případě nutnosti použití deklarativního nástroje pak asi Salt. A pochopitelně Foreman jako hlavní inventář :-)
Re: Re: Re: Re: Ansible – hromadná správa serverů
Tomáš Crhonek 24. 10. 2015, 20:15:47
Odpovědět Odkaz
To je možné, ale také jsou mnohem blíže tomu, co nastavují, vnímají různé výstupy, výpisy, takže pokud mají v sobě špetku zvědavosti, mohou velice snadno začít zkoumat. U mgmt konzole nikoliv, tam je to více či méně dokonale odstíněné (znám člověka, co před 9 lety používal webmin s tím, že až bude čas, tak si to, co ten webmin vlastně dělá, nastuduje. Po 9 letech a x bezpečnostních problémech v jeho síti stále používá webmin a furt neví, co to vlastně dělá -- pochopitelně to není nijak reprezentativní vzorek).
"U cfg mgmtu ten správný postup je obvykle psát si vše sám od píky a testovat, testovat a testovat."
Ale nějak se v těch všech přednáškách zapomíná jak dlouho to trvá. Vyzkoušel jsem všechna propagovaná (chef, puppet, ansible) nastavovátka a sorry, to, co udělám na 10 serverech dohromady za 5 minut, to bych v puppetu skriptoval den, v ansible hodinu. Kde je přínos? To by těch serverů skutečně muselo být tisíce. Nehledě na to, že s počtem serverů zase stoupá nutnost a náročnost testování, protože když poseru něco na ssh na jednom serveru, tak to není taková trága jako když poseru mgmt a rozhodím ho na tisíce serverů. Je tedy otázkou, zda rychleji roste složitost ovládat ssh a nastavovat ty věcí přímo nebo ovládat ty mgmt věcičky.
Čímž se také dostávám k tématu, k čemu tyto prostředky ostatní používají. Na všech přednáškách je +- probrané totéž co v tutoriálu. Jasně, ansible -i hosts all -m ping má možná ten správný wow efect, ale ten velmi rychle opadne, když potom člověk zjistí, že na nastavení sshd není v ansible ofic. modul (Nebo jsem ho jen nenašel v dokumentaci a ani ostatní uživatelé ansible jej neznají). Přičemž je třeba připomenout, že ansible na ssh celkem závisí.
Když jsem hledal, jak to řeší ostatní, tak jsem nalezl hromadu různých způsobů (nemá náhodou mgmt spíše sjednocovat?) od relativně ok, po naprosto odstrašující příklady.
Závěr tedy je, že ansible nechává nastavení sshd, přes který sám komunikuje, na libovůli admina a to, co jsem viděl za příklady, ve mě rozhodně nevyvolává dojem, že by zrovna použití ansible v těch lidech nějak vyvolávalo touhu po tom to nastavit správně.
A přesně stejnou zkušenost mám i u puppetu. Tutoriál jako dobrý, ale když jsem chtěl vytvořit pp pro běžné činnosti po instalaci minimal debian, tak jsem velice rychle narazil na to, že na úkony, které já považuji za základní, žádný modul neexistuje. Což ve mě opět vzbuzuje otázky, jak a zda vůbec, to řeší ostatní uživatelé puppetu (odpověď samozřejmě znám, ale sám před sebou ji skrývám, abych si uchoval víru v dobro lidstva).
Jen poznamka. Na sshd v ansible modul ani nebude, to co hledas je Role. A ta existuje.
Jinak souhladim, u 10 serveru to smysl nemá, ale smysl to ma pokud tech 10 serveru pravidelně preinstalovavas. Pets vs cattles.
Jinak souhladim, u 10 serveru to smysl nemá, ale smysl to ma pokud tech 10 serveru pravidelně preinstalovavas. Pets vs cattles.
Kdyby někoho zajímalo, jakou cenu obdržel autor článku, může se podívat sem:
http://exospace.cz/wp-content/gallery/linuxdays-2015/PA112037.jpg
Další fotky z konference:
http://exospace.cz/galerie/nggallery/z-cinnosti-exospace/linuxdays-2015
Jako vždy opakuji, že naše redakce podporuje LinuxEXPRES, jak jen může.
http://exospace.cz/wp-content/gallery/linuxdays-2015/PA112037.jpg
Další fotky z konference:
http://exospace.cz/galerie/nggallery/z-cinnosti-exospace/linuxdays-2015
Jako vždy opakuji, že naše redakce podporuje LinuxEXPRES, jak jen může.
