Názory k článku Konfigurační a orchestrační nástroj Ansible: úvod

Děkuji autorovi za článek, nedávno jsem začal koketovat s Puppetem, ale toto řešení je pro můj use-case mnohem přívětivější (nebo tak alespoň vypadá). S napětím očekávám další článek na toto téma.

Na strojích používáme Gentoo, kde je ansible přímo v hlavním repozitáři ve verzi 1.2.1, což je další příjemné plus.

P.S. první :-)

V interaktivním módu asi o moc více ani o moc více neuděláte.

Ale pomocí scénářů (playbooks) by se daly docela lehce na serverech spravovat USE flagy a konfigurace v /etc/portage například. O tom píšu v dalším díle.

Nevím, jestli to jde konkrétně s Ansible, ale u Puppetu nebo Chefu je třeba hodně zajímavá možnost mít nástroj, který mi umožní bleskově sestavit server, o kterém vím, že má přesnou parametrizovanou konfiguraci.

Například že je to "můj typický server pro malou firmu" - má nainstalované všechny odzkoušené softy v odzkoušené konfiguraci, akorát na správných místech má správný název domény, IP DNS poskytovatele, heslo LDAP serveru, atd. atd.

Jasně, mohl bys stejného efektu dosáhnout i haldou ad-hoc skriptů. Ale časem by tě z toho kleplo.

Je to možné, vše se dá popsat poměrně snadno v yaml a pak pouštět dávkově, včetně konfigurace z šablon s doplněnými fakty. Tomu je věnován druhý díl.

Pokud ti tohle přijde daleko přívětivější než Puppet (což chápu), koukni se ještě na Salt. Rozhodně stojí minimálně za vyzkoušení.

Když já opravdu rád myšlenku, že na zákazníkův stroj přitáhnu co nejméně věcí navíc, takže mít možnost aby konfigurační soft neměl agenta je pro mě velký bonus.

Ale uložím si to, třeba budou dlouhé zimní večery, díky.

Dobrý den,

souhlasím, že jsem to nenapsal úplně jasně. Deploy aplikace pomocí puppetu i chefu určitě lze provést. To co umí ansible navíc, nebo přinejmenším pohodlněji je deploy aplikací na více serverů, kdy pro každý server postupně odebere aplikaci z loadbalanceru, deaktivuje notifikace v monitoringu, provede deploy a obojí opět aktivuje. A tohle provede jeden server po druhém tak, že nezaznamenáte výpadek. Podrobněji v dalších dílech. Rád se přiučím, jestli to podobně děláte, pošlete link :).

Ohledně mládí se nedá polemizovat, projekt skutečně mladý je.

Root přístup není potřeba, ansible umí bez problémů využít sudo.

Pukud jsou některá slova zažítá, tak je hloupé používat anglikanismy. Zrovna ta orchestrace - se překládá jako "organizace, příprava, instrumentace".

Ano, je potřebí vystříhati se cizáckých slov a používati toliko slov ryze českých. Jako kupříkladu organizace a instrumentace!

:))))

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 :)

A kdyz budou dva uzivatele venca a franta, oba s uid=0, tak jako nebudou mit oddelenou historii shellu a nebudou zalogovana jejich prihlaseni?

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ý...

Koukal's i na Salt?