17
« kdy: 04. 04. 2022, 16:30:04 »
Ahoj,
budu ted testovat ruzne koncepty kontejnerizaci pro pripadne budouci firemni nasazeni. Nebude to v cloudu, takze k8s apod tu nehrozi.
Kazdopadne, mam tu vzorovy priklad jedne aplikace, kterou muzeme testovat bez toho, ze bychom ohrozili provoz/data. Zajimaly by mne zkusenosti z libovolnych smeru, zejmena principy nebo cesticky, co se ukazaly spatne.
Momentalne zkousim podman, standalone server. Clusterovy provoz zatim primo neresim, resim koncept administrace (CI/CD, pristup vyvojaru) a site. Zajimaly by mne zkusenosti z libovolnych smeru, zejmena principy nebo cesticky, co se ukazaly spatne.
Takze priklad je: kombinace pro jednu aplikaci je nginx + redis. Tech aplikaci je vice (ruzni zakaznici). Nginx je nyni VM, redis chceme kvuli automatizaci zkusit v kontejneru, nebot je to jednodussi nez automatizovat VM (zejmena zalozeni a vse kolem).. Z teto kombinace vychazi dva mozne smery:
1] nginx + redis v jednom subnetu - "zakaznik" v jednom
2] nginx v jednom subnetu, redis v druhem subnetu - subnet per typ sluzba (web, db, apod) pres vsechny zakazniky
Otazky mam zejmena tyto:
- pouziva nekdo uspesne nejaky typ administrace z hlediska principu podmanu? tzn. sluzby per uzivatel, oproti vsechny sluzby v monolitu dockeru
- ktera varianta je obecne lepsi, 1] ci 2]? Beru to i ve vztahu komunikacnich pruchodu (firewall apod) a oddeleni zakazniku.
Treba u siti mi bridge moc nevoni z hledisku pristupu na kontejnery z mimo kontejneroveho prostredi. Ale je pouziti macvlan pak ta spravna cesta? Aspon predpokladam, ze vetsina lidi provozuje kontejnery se stejnym typem sluzby na stejnem portu (tzn dedicated ip:port stejny) oproti (sdileny ip:ruzny port).
At uplne nemusim vymyslet cele kolo...
Diky.