Fórum Root.cz
Hlavní témata => Server => Téma založeno: Papi 25. 08. 2018, 17:12:35
-
Rozjíždíme nový projekt a máme aktuálně jeden server (což se má brzy změnit). Vzhledem k tomu, že chceme, aby se v serverové infrastruktuře vyznal ještě někdo za 2 roky, tak by bylo dobré nějak dokumentovat zásadní věci (co na něm běží, závislosti různých aplikací na ostatních, komunikaci serverů mezi sebou). Chtěl bych se proto zeptat jak dokumentujete servery vy. Napadla mě MediaWiki, ale nevím jestli je pro tento účel vhodná.
S touto problematikou nemám žádné zkušenosti, proto vás prosím, abyste se zdrželi hloupých odpovědí.
Děkuji.
-
Konfiguracni soubory v gitu a vlastni instalacni balicky s configy, daty, certifikaty.
staci pak na jakykoliv jiny stroj dat balicek, doinstaluje zbytek a staci spustit start skript.
Nebo docker soubory.
-
SaltStack (configuration management obecne), ktery je z meho pohledu citelny na prvni pohled.Pokud jde o hardwarovou cast, tak Netbox, kde lze zaznamenat umisteni serveru v racku, porty ve switchech atd. atd. Lze tak pomerne hodne slusne dokumentovat hardwarovou a sitovou cast.
-
Jestli tomu rozumím dobře, tak je potřeba kvalitně využívat configuration management tool a spoléhat na to, že se v něm ostatní dokáží zorientovat?
Dokumentuje se vůbec někde "do textu"? Upřímně si moc nedokážu představit, že bych každou změnu šel ihned zapsat do MediaWiki, Google Docs, nebo kamkoliv jinam. Ale zase nevím jestli je použití conf. management toolu dostatečná dokumentace. Nebo ano?
V minulé firmě jsem na velmi uživatelské úrovni používal Ansible (udělování přístupů, centrální správa uživatelů, atd...). Nicméně nejsem si jistý jestli bych si s ním dokázal představit distribuci a správu konfigurace na jednotlivých serverech.
-
Jestli tomu rozumím dobře, tak je potřeba kvalitně využívat configuration management tool a spoléhat na to, že se v něm ostatní dokáží zorientovat?
Dala by se automaticky generovat dokumentace z toho configu třeba právě do MediaWiki.
-
Jestli tomu rozumím dobře, tak je potřeba kvalitně využívat configuration management tool a spoléhat na to, že se v něm ostatní dokáží zorientovat?
Dala by se automaticky generovat dokumentace z toho configu třeba právě do MediaWiki.
To by mohlo být i jako služba na každém z těch serverů. REST API, data v XML nebo JSON.
-
Běžně wiki nebo readme v repositáři s ansiblem, chefem.
Ale o tom to je, že každou změnu zapíšeš někam do wiki, nebo ještě lépe, tu změnu tam zapíšeš dopředu, ověříš na neprodukčním prostředí a změny na produkci striktně plánuješ a eviduješ, základem dlouhodobé stability a čistoty je změny dopředu rozmýšlet a na produkci nasazovat až, když víš co a proč děláš.
Je také velice vhodné mít seznam SW, který tam není z balíčků a pravidelně kontrolovat security updaty a nasazovat je zavčasu.
-
U nas (vyse 150 vms, 32 host bladov, niekolko switchov a niekolko pizza boxov) je:
a) Konfiguracia v gite (z tohto dovodu je to inak u nas najcitlivejsi system z pohladu bezpecnosti)
b) Confluence s textami a vysvetlivkami
Ale viac menej sme len 2 co musia do hlbky chapat wo-co-go a par dalsich len povrchne. Aktualne sme v stave ze base image uz generujeme pomocou ansible (a ansible src su zase v gite) a v idealnom pripade chceme viac a viac casu invsetovat do ansible... Avsak z dovodu urychlenia procesov a setrenia naseho casu, prehlad mame aj bez toho.
-
Ono je taky otázka co na těch serverech běží a co vlastně dokumentuješ. jeden server může být složitější než 100. A na druhou stranu při špatně zvoleném systému může zabrat dpkumentace hodně času a stejně se v tom naknec nadělá binčus.
-
Záleží co přesně potřebuješ. U mě se zatím nejvíc osvědčil Ansible + git. Jen to ty playbooky a role chce pořádně komentovat + dělat readme. Oproti třeba dokuwiki to na začátku zabere více času, ale jak budou přibývat věci, tak budeš mít všechny úpravy na jednom místě. Též se to dá ještě propojit s Jenkins.
-
Já dokumentuji na dokuwiki. Základní logiku serveru, komunikační schéma, nutné procesy a speciální úpravy konfigurace. Je tam i dvouvětový manažerský úvod, víc nepobírají. Zbytek nechávám na zálohování. Dokumentace by se měla upravovat maximálně při reinstalaci serveru nebo přidání nové služby. Většinou platí, že dokumentace, která se upravuje častěji než 1x ročně, není správně udělaná.
-
Honzo, u nas se dokumentace upravuje pred kazdym change request, tj klidne i nekolikrat denne. Ze mame spatnou dokumentaci? Tezko, obsahuje vzdy up2date stav toho co mame.
-
Já dokumentuji na dokuwiki. Základní logiku serveru, komunikační schéma, nutné procesy a speciální úpravy konfigurace. Je tam i dvouvětový manažerský úvod, víc nepobírají. Zbytek nechávám na zálohování. Dokumentace by se měla upravovat maximálně při reinstalaci serveru nebo přidání nové služby. Většinou platí, že dokumentace, která se upravuje častěji než 1x ročně, není správně udělaná.
Ono asi jde o to co provozuješ, pokud ale máš desítky, stovky serverů a k tomu desítky neustále pracujících vývojářů, máš tým sysadminů, kteří pernamentně implementují nové věci, pak prostě dokumentaci upravuješ i několikrát denně.
Už jen taková maličkost jako pravidla pro FW, potřebuješ k nim evidovat spoustu věcí a to je přesně to, co se také do dokumentace píše. Brát jako dokumentaci aktuální (či minulý) stav serveru je tenký led, občas potřebuješ vědět důvod, občas potřebuješ udělat audit, že vše je správně a zamýšleně nastavené, občas potřebuješ vědět které nastavení je pro kterou aplikaci, jak to chceš udělat, když máš jen ten stav?
Chápu, že provozovat apache server a na něm dva weby znamená v podstatě nulovou potřebu něco poměnit.
-
Záleží co přesně potřebuješ. U mě se zatím nejvíc osvědčil Ansible + git. Jen to ty playbooky a role chce pořádně komentovat + dělat readme. Oproti třeba dokuwiki to na začátku zabere více času, ale jak budou přibývat věci, tak budeš mít všechny úpravy na jednom místě. Též se to dá ještě propojit s Jenkins.
Ansible/puppet/chef v kombinaci s GIT je podle mne určitě nejlepší. Je to spustitelná dokumentace, čitelné a kdokoli k tomu přijde, může provést úpravu, pustit redeploy nebo nainstalovat z čista. Není pak nutné popisovat extra v dokumentaci nainstalujte balíčky, nastavte, atd..
-
Jednoznacne salt/ansible/cheff/pupet atd.. je to defakto definice stavu ve kterem ma virtual/master byt. Umre to stroj/virtual, vezmes nove zelezo a jen to tim na jeden prikaz
natahnes na stejny stav jako predchozi uz neexistujici stroj. My tak managujeme 10k virtualu a 3k zelez. Dnes ale je cesta smerem k orchestraci, cize kubernetes/openshift + docker. Zde jsou vsechny konfigy dockeru a kubernetich yamlu v gitu dane aplikace a ty jsou ta pravda. Jak si na to zvyknete tak vite kde co je a jak to presne funguje. Jak u saltu atd tak u dockeru/kubernetu je presne ta pravda co umi kazdy cist jak to funguje. Dokumentace je v techto pripadech zcela zbytecna. Staty saltu/playbooky ansiblu/Dockerfily dockeru jsou ta jedina pravda co tam na te virtualizaci bezi a v jakym poradi.
-
Spustitelná dokumentace v Ansible/Salt/Chef/whatever je základ, v jednodušších případech může stačit. Spustitelná dokumentace má tu výhodu, že je mnohem jednodušší zajistit, aby seděla s realitou. Někdy se hodí přidat i nějaké readme nebo wikistránku s textovým popisem. Ten by neměl být extrémně podrobný (pokud každá změna v konfiguraci vyvolá změnu v readme, je něco špatně), spíš poskytnout takový big picture. Může odpovídat na otázky jako „proč je DB server separátní“, „na kterém serveru hledat komponentu XX a proč”, „proč používáme komponentu YY a ne ZZ” a spoustu jiných věcí. Kdy je tam toho dost – těžko obecně říct, je to ale možné vyzkoušet: dejte kolegovi (ideálně nově příchozímu) dokumentaci a ověřte si, že se v ní vyzná.
Proč ne podrobné readme? Jednak je zbytečně náročné to udržovat, ale to ve výsledku není to nejhorší. Horší je, že pak dříve nebo později readme přestane odpovídat realitě pak už jsme jen krůček od toho, aby dělalo více škody než užitku. Neaktuální dokumentace je někdy horší než žádná, protože mate lidi.
-
Děkuji za odpovědi.
Chtěl bych se ještě zeptat co doporučujete na deploy docker kontejnerů (docker-compose). Kubernetes bych se zatím chtěl vyhnout, protože je to moc těžkopádné řešení, které zatím neovládám. Všiml jsem si, že to umí i ansible, ale nevím jestli je na to vhodný.
S kubernetes do budoucna počítám, chtěl bych proto do začátku nějaké řešení, které nezpůsobí problémy s následným přechodem.
-
za mne co ti prijde za vhodne, ansible ma modul ve kterem docker-compose konfiguruaci nakodis, ale dal bych prednost mit krasny docker-compose yaml a ten spustet pres ten modul ze das cestu k tomu yamlu, hlavne kvuli debugu, nepotrebujes k tomu ansible potom. Ted jsem to tak delal a jsem stim spokojeny. Ale to same udelas vsude jinde. Kubernet je super ale overkill, mraky znalosti musis mit/nabydes a hodi se k tvorbe clusteru s mraky serveru, je to proste orchestrator. Na jeden stroj urcite jen docker-compose.