Inteligentní automatizace
Chcete nasadit na vaši infrastrukturu automatizaci? Přemýšlíte po jaké technologii sáhnout?
V následujícím článku vám popíšeme náš pohled na automatizaci IT infrastruktury.
Když přemýšlíte nad automatizací IT infrastruktury, vždy by měl být kladen velký důraz na:
- možnosti škálovat řešení
- možnosti komplexní automatizace (od fyzických serverů, síťových prvků, kontejnerů, či VPS a jejich operačního systému)
- možnost monitorování
Pokud nějaký fakt opomenete a smíříte se jen s částečnou automatizací, může se vám stát, že sice budete mít perfektně zautomatizovaný třeba deploy aplikací na servery, ale když dojde k poškození nějakého hardware, popřípadě k softwarové chybě, už nebudete schopni na to efektivně reagovat, protože v té dané části vám bude chybět automatizace. Reinstalace takové části může zabrat několik hodin, během kterých ztrácíte čas, a tedy i peníze.
Je dobré říci, že při dobré automatizaci jsou pro vás jediným problémem uživatelská data (databáze, soubory atp.), která se musejí přenášet. Zbytek infrastruktury jste schopni rychle sestavit pomocí automatizačního nástroje, nebo nástrojů. Dnes totiž není problém vytvořit aplikační servery během několika jednotek až desítek minut, ale když nemáte co na nich provozovat, není vám to k ničemu. Nicméně tento článek neslouží k popisu, jak řešit uložení dat, jen zde poukazujeme na nutnost nad tím přemýšlet už při automatizaci infrastruktury.
Jak by měl fungovat moderní automatizační nástroj fungovat?
Moderní automatizační nástroj by měl používat Event-Driven architekturu, to znamená komunikační linku, přes kterou si předává data o stavu a událostech v síti. Výhodou této architektury je, že každý prvek v síti (server, kontejner, síťový prvek), je přihlášen na komunikační linku, a tak je schopen přijímat nebo vysílat požadavky a informace o tom, co potřebuje provést, nebo co je potřeba s ním provést.
Zprávy zpracovává vždy jen ten, kdo jim rozumí, což může být jediná noda v celé síti nebo také všechny nody. Takový nástroj představuje například Salt od společnosti SaltStack. Salt používá master – minion přístup. Master je mozek, který řídí veškeré události. Minion aplikuje změny na hostitelském systému. Všechno navzájem propojuje Event-Driven, konkrétně se využívá ZeroMQ, a také je zde zajištěno šifrování a autorizace minionů vůči masteru. Velké množství automatizačních nástrojů používá pro spojení s hosty SSH. Salt tuto možnost také nabízí, a převážně se využívá tam, kde je nedostatečný výkon pro běh minionu (různé síťové prvky, nenáročné kontejnery, atd). Nevýhoda tohoto řešení je v tom, že funguje jen jako push akce, to znamená, že se posílají akce jedním směrem. A je potřeba otevřít příchozí síťové spojení. Salt používá spojení zevnitř na master, to znamená, že nepotřebuje mít na hostitelském systému, kde běží minion, otevřený příchozí port.
Pozorný čtenář už si určitě všiml, co lze s pomocí Event-Driven dělat za skvělé věci. Je to třeba monitoring, kdy se do event bus pošle message a monitorovací tool, který jí rozumí, si ji vezme a zpracuje, ať už se jedná o zanesení do grafu, nebo aktivaci notifikace. Nebo potřebujete udělat nějaký check na úrovni vaší aplikace? Něco se o ní dozvědět? I to lze pomocí event bus vyřešit.
Máte totiž k dispozici systém toku zpráv, na vás už je jen vyřešit, jak zprávy vytvořit a po obdržení zpracovat. Samozřejmě i tento systém má svoje nevýhody, konkrétně u Saltu je nevýhoda ta, že když přijdete o master, tak ztratíte spojení s miniony a i s event bus. Proto se to u Saltu řeší multi-master systémem, kde masterů je více a navzájem se vykrývají. Druhá nevýhoda je ta, že minion je daemon, který běží na hostiteli, na druhou stranu i SSH server je daemon, takže to nemusí být považováno za nevýhodu.
Další užitečnou možností je napojit automatizaci na CI/CD, díky čemuž získáte zajímavou variabilitu. Můžete vytvářet a rušit výpočetní výkon podle vaší potřeby, a to jen pomocí kliknutí ve webové aplikaci. V případě nutnosti testování procesu lze jednoduše spustit virtuální stroj kam se automaticky nainstaluje software, třeba z produkčního poolu serverů. Potom lze provádět testy, zda je nová aplikace plně kompatibilní, a snížit tak pravděpodobnost problémů při nasazení do produkce. Možnost vytvoření nového aplikačního serveru využijete po nasazení do výroby, kdy po otestování a schválení nahradí server starý. V případě problémů lze zpětně obnovit starý produkční server s využitím zaznamenané kompletní historie infrastruktury. Tato možnost může sloužit i jako dokumentace, využitelná pro současné administrátory, či zaškolení nových pracovníků.
—
Kam dále?
Zvládáte takovéto věci sami? Gratulujeme. Potřebujete s něčím pomoci, nechat si poradit, něco těžkého zprovoznit?