Vlákno názorů k článku Konfigurační a orchestrační nástroj Ansible: úvod od M. Prýmek - Davide, taky se přidávám, dík moc za článek....
-
Davide, taky se přidávám, dík moc za článek. Orchestrace a cfg management je určitě aktuální a docela málo známé téma. Super, těším se na další díly.
Pokus o konstruktivní kritiku/reflexi:
- Chápu snahu o vtažení čtenářů do tématu rychlými srozumitelnými příklady, ale trochu mi v prvním díle seriálu chybělo aspoň krátké systematické uvedení do toho, o co se vlastně jedná, na čem je to postavené, v čem napsané, jakým způsobem to běží, jaké to má závislosti, jak se to dá integrovat s jinými nástroji apod. Vydedukoval jsem teda, že jsou to vlastně jenom nějaké skripty, které se pouští vzdáleně přes ssh a předávají se jim nějaké parametry. Docela by mě zajímalo třeba
- kolik těch skriptů je (->kolik funkcionality pokrývají),
- v čem jsou napsané
- jestli je nutné je kvůli každé položce konfigurace spouštět zvlášť skript (trochu brzda výkonu...)
- jestli jsou dobře definované vstupy a výstupy (->integrovatelnost s dalšími nástroji)
- jestli můžou mít skripty nějaké závislosti (tohle spusť jenom když tamto selhalo)
Pak by mě taky zajímalo, jestli skupiny jsou jedinou možností "adresace" serverů, nebo má Ansible i něco na způsob facteru z Puppetu, popř. grainů/pil-laru* ze Saltu. Pokud by neměl, tak by to imho byla obrovská limitace a brzda.
A ještě si nemůžu odpustit boj proti oblíbenému mýtu, který se i ve Tvém článku dvakrát objevil: použít sudo proto, abych nepoužil roota <i>je</i> špatný nápad. Nepřináší to nic kromě zbytečných komplikací: musí se složitěji escapovat parametry skriptů, složitěji se vytváří shellové roury a celkově je to jenom opruz. Pokud má někdo paranoiu z toho, že mu roota hackne bot, není nic jednoduššího, než si vytvořit uživatele venca s uid=0,gid=0 a má stejný efekt zadarmo a bez opruzů. Jediná situace, kde má sudo opravdu smysl, je omezení práv na jenom nějaké příkazy. I kdyby se Canonical na hlavu postavil ;)
* pi-ll bez pomlčky je zakázané slovo :)
-
ebik (neregistrovaný)
- Vyhoda sudo neni v bezpecnosti ale pokud server spravuje vic administratoru
- maji oddelenou historii shelu
- jsou zalogovany jejich prihlaseni, takze se da dohledat kdo za zmenu muze a zeptat se ho proc ji udelal
Bezpecnostni riziko sudo je pokud je bez hesla (kvuli skriptum) a pritom ten clovek pouziva ten ucet i k jinym ucelum nez ke sprave toho serveru, protoze pak je mozne, ze pres diru v aplikaci kterou tam pouziva se mu tam nekdo dostane a pres sudo si pak udela roota.
-
Miroslave díky,
konstruktivní kritiku beru, bez zpětné vazby nemám jak zjistit co se dá vylepšit.
Přiznám se ale , že na tvou kritiku mám problém odpovědět i teď. Ansible je totiž opravdu velmi minimalistické, že by se až dalo říct, že to je několik skriptů a sada modulů, které můžeš snadno vyvolat a nic více. Jenže v tom to vězí. Moduly ti umožňují nastavit na vzdálených serverech v podstatě cokoliv (i když v některých případech jen voláním shellu, což není ideální).
Samotné Ansible je psané v pythonu a potřebuje ... python. To je většina závislostí. V něm jsou i psány moduly (skripty), ale můžou být psát v čemkoliv, pro Ansible je důležité aby měly jako výstup JSON, nic víc. Přehled modulů jsme neuváděl i proto, že by článek byl ... dlouhý. Ale mohl jsem uvést aspoň odkaz na jejich dokumentaci: http://www.ansibleworks.com/docs/modules.html
Adresace je primárně pomocí skupin. Ale když si člověk například vytvoří novou instanci na AWS, tak je možné tuhle instanci rovnou zařadit do skupiny (i když jen dynamicky) a pokud se později ve zpracování s tou skupinou něco děje, tak je to včetně těch nových strojů. Nemýlím-li se, tak je možnost i zjistit si jaké servery má člověk na AWS, rackspace, ... a ty rozřadit do skupin, které se následně použijí. Ale ještě jsem to v praxi nezkoušel tak možná trochu kecám (odpovídá to tomu jak to v Ansible obvykle funguje, ale nemám to ověřené).
Do diskuze jestli sudo vylepšuje bezpečnost, nebo ne se nebudu pouštět, 10 linux adminů na to má pravděpodobně 14 názorů :). Za sebe jen řeknu, že někde to používám, někde ne a většinou to určuje bezpečnostní politika firmy pro kterou spravuju servery. Jak opodstatnější beru abych měl u těch uživatelů přihlášení jen přes klíč, bez hesla. Ke komplikacím se sudo - u Ansible jen označíš že pro task má použít sudo, to jediné, s ním to funguje stejně jako když použiješ rovnou root přístup.
Argument s uživatelem venca beru :).
-
Díky za obsáhlou a přínosnou reakci.
> Ale mohl jsem uvést aspoň odkaz na jejich dokumentaci: http://www.ansibleworks.com/docs/modules.html
Jo! To je přesně to, co mě zajímalo. A vypadá to dobře, funkcí hodně.
> Adresace je primárně pomocí skupin. [...]
Hm, tak to je docela škoda. V Saltu (a myslím, že i Puppetu) jde adresovat stroje i podle jejich vlastností z nějakého grainu/pi-llaru. Takže např. když najednou chci něco udělat se všemi stroji s nějakým určitým množstvím RAM, můžu. U Ansible bych si teda prvně musel vytvořit skupinu. To je docela nepříjemné, protože vytvořit si dopředu skupiny podle všeho, co bych potenciáně někdy mohl potřebovat, je nereálný...
