Dotaz: automatizacia LAMP s Gitlab a AWX (ansible)

[samo-sato-awx-ko]

Ahojte,

snazim sa co najlepsie uchopit automatizaciu a spravu standardneho LAMP clusteru, rad by som sa opytal na skusenosti alebo ako co najlepsie automatizaciu nadizajnovat. V podstate sa jedna o (teraz neriesim architekturu):

2ks Varnish HA

2ks NGNIX (VRRP active, passive)

4ks Apache (PHP aplikacia)

4ks MySQL (databaza)

 

Je jasne ze niektore konfiguracne subory budu na vsetkych serveroch rovnake, napr. /etc/hosts alebo /etc/resolv.conf alebo SSH verejne kluce. Naopak, na roznych serveroch Apache vs MySQL budu konfiguracne subory odlisne. A do tretice este deploy PHP aplikacie.

 

Moja predstava je, ze niekto pushne/mergne zmenu konfigu alebo aplikacie v master branch do git repo a AVX (ansible) urobi vsetku nudnu robotu samo.

 

Je lespie volit zvlast git repo pre kazdy server alebo vsetko drzat v jenom git repe porozhadzovane v spleti adresarov?

 

Da sa docielit aby sa na cielovy server preniesol len modifikovany subor alebo je lespie uploadnut/prepisat na cielovy server vsetky subory z git repozitara bez ohladu na to v ktorom prebehla zmena?

 

Rad by som sa opytal na vase skusenosti popripade doporucenia. Dakujem.

Odpovědi

[Max]

Tak zrovna "/etc/hosts" bude mít asi každý server jiný, ne?
Jinak používáme Ansible (AWX ne, protože OSS varianta prostě pro produkci není). Gitlab jedeme také, ale jen pro vývoj, né pro CI/CD u serverů.
Zatím jsme ve fázi, kdy instalace serverů popisujeme v playbookách. Přes playbooky pushujeme nastavení jako ssh klíče, sssd auth, nastavení ssh, proměnných apod., instalace základních programových sad apod. Nebo u stejných VM (např. nody Kubernetu) hromadné rozšiřování místa apod.
Teď plánuji plně zautomatizovat upgrady clusterů typu: vyjmy z HA, udělej upgrade OS, reboot, otestuj, že vše na tom běží, zapoj do HA, pokud vše ok, vyjmy další server z HA, upgrade atd.

Nejsem si jist, zda u tak malého počtu serverů, které jsi naznačil, má smysl řešit CI/CD. Na hraní super, ale je třeba si uvědomit, že to vytváří velký overhead, který se začne vyplácet až u většího počtu serverů.
Zdar Max
PS: od VRRP chci utéct podobně jako od Nginx

[MP]

Proc chces odejit od vrrp a co je mozna nahrada?

Proc chces odejit od nginx a co je mozna nahrada?

[Max]

VRRP (nejčastěji pomocí keepalived) má spoustu problémů a neošetřených věcí. Místo toho tedy klasiku, co se normálně používá, tj. pacemaker, corosync apod., kde lze lépe ošetřit další stavy. Dřív byl třeba neřešitelný problém mít Keepalived nasazený na virtualizované infrastruktuře, protože třeba vmware občas freeznul VM při záloze, nebo nějaké operaci na krátkou dobu. Druhý node nabyl dojmu, že první node umřel a stal se masterem. První VM se odfreezla a byla také master. Najednou měly dvě VM stejné IP, oba keepalived daemoni si mysleli, že jsou master (a nikdo jim to už nevyvrátil, jedině jeden z nich otočit). Pak přibyly nějaké patche, aby tento stav pokryly (aktivní kontroly směrem na slave, zda jsem skutečně master), ale i tak za nějakých konstelací toto nastalo. A to je jen příklad.

Nginx zase není v OSS verzi pro větší nasazení, protože neumí spoustu věcí nutných pro HA (aktivní health checky, sticky sessions apod.). Kdežto Apache je free v plné kráse a má více fcí, než OSS varianta Nginx. Je možné si Nginx zkompilovat sám s moduly třetích stran, který to pokryjí, ale to jsou většinou moduly typu neudržovaného onemanshow. Jen mi chybí čas všechno přepsat a otestovat pro Apache, jinak už bych to dávno měl. Bavil jsem se o tom i s jinýma firmama, co se zabývají architekturou a implementací a jeli také Apache z těchto důvodů.
Zdar Max

[MP]

Takze misto keepalived bys nasadil vice sluzeb, ktere by resily stejnou funkcionalitu? A nebude to trpet stejnymi problemy (zpusob nasledneho reseni tech problemu ted zanedbam) viz popsany freeze stav?

Ten nginx tedy chapu tak, ze ho pouzivas jako LB? Tak pak chapu, ze nemusi vyhovovat, protoze vetsinou se na to pouzivaji dedikovane LB reseni (haproxy a jine).

[Max]

To je omyl, oni neřeší stejnou funkcionalitu. Jak jsem psal, řeší mnohem více problémových stavů a běžně se u takových nasazení nasazují. S Keepalived budeš mít problém třeba v místech, kde to nebude na jedené L2 (kromě bezpečnosti budeš řešit další věci). Dále Keepalived neumí v mnoha případech řešit fencing a další věci okolo.

Ano, Nginx používám jako centrální reverzní proxy server, kde jsou terminováni klienti (používám jako aplikační fw + loadbalancer). Mohu použít Nginx, HAProxy, Apache a další. Na začátku jsem se rozhodl pro Nginx a chci to předělat na Apache.
Původně jsem se rozhodoval mezi Nginx a HAProxy, problém byl v tom, že HAProxy byla vývojem pozadu za Nginxem i Apache docela dost (chyběla mi třeba podpora http2 a další věci, což přišlo do HAProxy asi dva roky po nasazení Nginx). Teoreticky bych mohl HAProxy znovu zvážit.
Zdar Max

[MP]

Ano, haproxy z hlediska podpory novych protokolu je zatim vzdy trochu pozadu za web servery.

Kazdopadne, pokud zvazujes nove LB reseni, tak bych krome battle-tested haproxy zvazil i moderni LB typu traefik.

[samo-sato-awx-ko]

Vlastne v tomto momente mne neide ani tak o pocet serverov ale ide skor o to ako uchopit verzovanie playbookov a konfiguracnych suborov. Ci zvolit separatny git repozitar pre kazdy server alebo mat vsetko v jednom repozitary ulozene v adresarovej strukture.

[GeorgeWH]

No ved gro ansiblu je znovupouzitelnost - jeden template a naplnat ho konfiguraciou pre ten ktory server. Vytvorit konfiguraciu spolocnu pre vsetky servery, konfiguraciu per hosts groups a nakoniec per host. A potom jednu rolu na kofiguraciu db serverov, dalsiu pre web servery, atd. Typ padom celu infrastrukturu riadis z jedneho miesta, zaroven tam mas historiu konfiguracie, atd.