Kontejnerizace a různé pohledy

Kontejnerizace a různé pohledy
« 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.
« Poslední změna: 04. 04. 2022, 16:56:26 od Petr Krčmář »


Re:Kontejnerizace a ruzne pohledy
« Odpověď #1 kdy: 04. 04. 2022, 16:36:45 »
... k8s nemusi byt mimo hru, pokud zvazite self-hosted reseni jako rancher, okd 4.

Jinak resit to muzete pres infrastrukturni pody + managment pres systemd, nejaky realny srovnani nemam...
https://mojefedora.cz/kontejnery-s-podmanem-sitovani/
https://docs.podman.io/en/latest/markdown/podman-generate-systemd.1.html

Pokud si to nejak pekne zorchestrujete proc ne.

Doufam, ze nekdo erudovany Vam poradi.

Re:Kontejnerizace a různé pohledy
« Odpověď #2 kdy: 06. 04. 2022, 11:53:16 »
Tak co si hraju s podman plus koukam, co umi portainer, tak jsem tak trochu z toho nestastny.

Oddeleni uzivatelu v podmanu by se mi strasne hodilo, vcetne toho, ze lze definovat systemd user sluzby. Ale ty site...nemoznost pouzit macvlan/ipvlan pro non-root uzivatele to zabiji, navic vyuziti centralni konfigurace neni mozne. A to jsem jeste nezkousel rootless kontejnery...

Portainer vypada na prehled prostredi rozumne, jen v podmanu nevidi uzivatelske kontejner, prime napojeni na uzivatelsky podman.sock prozatim nejde kvuli pravum. No, bude to na dlouho...

Re:Kontejnerizace a různé pohledy
« Odpověď #3 kdy: 06. 04. 2022, 14:38:34 »
to je dlouhé téma.

Vykašli se na podman, to není na běh služeb ideální, však už jsi na hlavní úskalí narazil. k8s pořád nemusí být mimo hru, stejně jako k3s, stejně tak dobře funguje openshift, rancher, nomad aj.

Deamonless režim ala podman má velká omezení, protože při inicializaci kontejneru nemůžeš skoro nikam šáhnout, i obyčejný docker s centrální službou toho udělá víc, umí ti to vysokými právy připravit síť a kontajner pak můžeš mít spuštění v uživatelem.

Provázání na systemd nefunguje dobře v dockeru a ani podmanu, konflikt různých cgroup namespaců je poměrně zásadní, ztratíš buď monitoring, zabezpečení nebo stabilitu.

S návrhem sítě ti moc neporadím, neposkytl jsi příliš moc informací. Varianta (2) mi ale nedává moc smysl, raději bych viděl oddělení tenanta do vlastního subnetu, z pohledu monitoringu a bezpečnosti se lépe řeší DMZ pro jednotlivé zákazníky než pak vertikálně řezat služby.

Nechce ti firma raději zaplatit školení? Za den/dva se toho dá projít strašně moc.

Re:Kontejnerizace a různé pohledy
« Odpověď #4 kdy: 07. 04. 2022, 10:26:02 »
Jasne, provozovat k8s on-premise v jednom cloveku, uz se do toho zenu :D
Zatim resime jen obejiti nevhodne volby aplikacni technologie (aneb, vice tenantu v jednom redisu, do toho se jim moc nechce).

Na tohle by mi podman s tou systemd podporou bohate stacil, bez root prav ale pouze v rezimu ruzne redisy na ruznych portech...ruznoportovy reseni pro stejnou sluzbu ja teda moc v oblibe nemam.
« Poslední změna: 07. 04. 2022, 10:28:23 od czechsys »


Re:Kontejnerizace a různé pohledy
« Odpověď #5 kdy: 07. 04. 2022, 10:55:20 »
třeba Nomad lze provozovat v jednom člověku, nebo i k3s (osobní zkušenost).

Když to vezmeš fakticky, můžeš v systemd si udělat službičku, která ti nahodí net interface pro redis a dát jí jako závislost redisu v podmanu, podobně to dělá docker. Tím nepotřebuješ zvýšená práva. Využij toho, že ti systemd běží pod vysokými právy a umí dělat ledacos.

Když chceš zachovat porty, tak si spouštějí jednotlivé instance redisu na extra IP, tím můžeš zachovat porty. Přestaň o portech přemýšlet jako o něčem statickém a něčem přímo dosažitelném. Port má být statický jen když to je nějaký veřejný kontrakt, api, pokud máš interní služby nebo redis jako sidecar, nic tě nenutí mít porty náhodné, pak je jen předáš do konfigurace. Stejně tak to používáme s uživateli, pevného uživatele mají jen jednotky služeb, všechny redisy např. běží pod dynamickým uživatelem bez práv a obehnané selinuxem.

Po velkém boom kontajnerů se dnes zase vracíme zpátky a čím dál častěji experimentujeme s infrastrukturou, kdy generujeme celá jednoúčelný VM s konkrétní aplikací. Vývojář/admin to připraví v dockeru, vezmeme definici a z ní uděláme celým VM vč. kernelu a ten se spouští. Výhoda je daleko menší režije (docker prostě dělá nějakých 10 - 20 %, což u velkých služeb je pořádný balík peněz), lepší monitoring provozu, daleko nižší nároky na znalosti, protože odpadá milion komplexní nástrojů jako k8s. To jen takový povzdech a nápad kam se dál ubírat.

Re:Kontejnerizace a různé pohledy
« Odpověď #6 kdy: 07. 04. 2022, 13:12:20 »
Když už na to příjde řeč, tak pro tvoje účely možná může být dostatečný systemd-nspawn, spustíš takhle container pod uživatelem a oprávnění a vše ostatní můžeš řešit jak jsi zvyklý.

Re:Kontejnerizace a různé pohledy
« Odpověď #7 kdy: 07. 04. 2022, 14:06:02 »
třeba Nomad lze provozovat v jednom člověku, nebo i k3s (osobní zkušenost).

Když to vezmeš fakticky, můžeš v systemd si udělat službičku, která ti nahodí net interface pro redis a dát jí jako závislost redisu v podmanu, podobně to dělá docker. Tím nepotřebuješ zvýšená práva. Využij toho, že ti systemd běží pod vysokými právy a umí dělat ledacos.

Když chceš zachovat porty, tak si spouštějí jednotlivé instance redisu na extra IP, tím můžeš zachovat porty. Přestaň o portech přemýšlet jako o něčem statickém a něčem přímo dosažitelném. Port má být statický jen když to je nějaký veřejný kontrakt, api, pokud máš interní služby nebo redis jako sidecar, nic tě nenutí mít porty náhodné, pak je jen předáš do konfigurace. Stejně tak to používáme s uživateli, pevného uživatele mají jen jednotky služeb, všechny redisy např. běží pod dynamickým uživatelem bez práv a obehnané selinuxem.

Po velkém boom kontajnerů se dnes zase vracíme zpátky a čím dál častěji experimentujeme s infrastrukturou, kdy generujeme celá jednoúčelný VM s konkrétní aplikací. Vývojář/admin to připraví v dockeru, vezmeme definici a z ní uděláme celým VM vč. kernelu a ten se spouští. Výhoda je daleko menší režije (docker prostě dělá nějakých 10 - 20 %, což u velkých služeb je pořádný balík peněz), lepší monitoring provozu, daleko nižší nároky na znalosti, protože odpadá milion komplexní nástrojů jako k8s. To jen takový povzdech a nápad kam se dál ubírat.

Kdybych umel automaticky generovat VM vcetne vsech dokumentaci a pridavnych sluzeb, tak do kontejneru ani nepachnu :)

Jeste zvazim ty dynamicke porty, relativne mi v tomto pripade (v ramci intranetu) muzou byt fuk...spis je pro me dulezitejsi, aby se na ty sluzby dalo dostat z mimo hosta a nezneuzilo to pripadne nejakeho pruchodu fw pravidel.

Re:Kontejnerizace a různé pohledy
« Odpověď #8 kdy: 07. 04. 2022, 14:06:38 »
Když už na to příjde řeč, tak pro tvoje účely možná může být dostatečný systemd-nspawn, spustíš takhle container pod uživatelem a oprávnění a vše ostatní můžeš řešit jak jsi zvyklý.

Taky jsem o tom uz stihl premyslet, ale netusil jsem, ze to umi i docker kontejnery...tak to muzu zvazit.

Re:Kontejnerizace a různé pohledy
« Odpověď #9 kdy: 07. 04. 2022, 14:18:19 »
Když už na to příjde řeč, tak pro tvoje účely možná může být dostatečný systemd-nspawn, spustíš takhle container pod uživatelem a oprávnění a vše ostatní můžeš řešit jak jsi zvyklý.

Taky jsem o tom uz stihl premyslet, ale netusil jsem, ze to umi i docker kontejnery...tak to muzu zvazit.

on je neumí přímo, musíš container/image rozbalit. Používám pretask na rozbalení, mountnutí a případně mountnutí writable volume a z něho spustím nspawn, ten se na danou složku chrootne. Při ukončení se to zase odmountuje.

Re:Kontejnerizace a různé pohledy
« Odpověď #10 kdy: 09. 04. 2022, 14:09:33 »
Pokud mate vic zakazniku a planujete dlouhodobejsi spolupraci pak bych sel cestou k8s/okd v on-premu. Ano neni to ze zacatku jednoduchy na nasazeni, ale po prvotnich porodnich bolestech vam spravne navrzene reseni usetri spoustu casu. U k8s je jen dobre si dat pozor na network cni, aby reflektovalo to co od nej chcete (treba egress/ingress na namespaces, network policy etc) a dat tomu nakou stabni kulturu pouzivanejch technologii aby se Vam to nezvrhlo v technologicke zoo.

Pokud to chcete bastlit pres podmana nebo jine docker like systemy, dovedu si predstavit reseni mit ruzne kontejnery jednoho zakaznika ve vlastnim bridgi, ktery pak pres veth proroutujete/pronatujete ven. Pokud pouzijete misto linux bridge napr. openswitch daj se s tim delat kouzla jako tuneling l2 pres vxlany (pokud se treba rozhodne mit ten redis na jinym zeleze nez ty nginxy z nakejch duvodu) apod. Fantasii se meze nekladou a zalezi jen na Vasem na designu.

Imho zalezi hodne na tom kolik a jake zakazniky na tom chcete provozovat, kolik a jake aplikace chcete mit atd apod.

Jinak nechapu jaky je rozdil automatizovat vmka a automatizovat kontejnery…. Smirte se s tim ze holt musite vyvinout nejake usili aby Vam to prineslo kyzeny efekt. Obecne moderni it je hlavne o automatizaci, takze otazka imo neni proc ano, ale spis proc proboha ne ?

Re:Kontejnerizace a různé pohledy
« Odpověď #11 kdy: 09. 04. 2022, 19:14:34 »

Kdybych umel automaticky generovat VM vcetne vsech dokumentaci a pridavnych sluzeb, tak do kontejneru ani nepachnu :)
[/quote]

LXC kontejnery (takový malý virtuál, který nemusíš instalovat) + Ansible. Pro tvoje potřeby, domnívám se, ideální adept.

Jose D

  • *****
  • 862
    • Zobrazit profil
Re:Kontejnerizace a různé pohledy
« Odpověď #12 kdy: 10. 04. 2022, 11:52:42 »
Kdybych umel automaticky generovat VM vcetne vsech dokumentaci a pridavnych sluzeb, tak do kontejneru ani nepachnu :)

Tyhle věci už dneska jdou.
Já jsem byl teď neobyčejně spokojen s automatizací generování VM ve vsphere pomocí Ansible.
Vsphera poskytne API, nu a Ansiblem za něj taháš. (https://docs.ansible.com/ansible/latest/collections/community/vmware/index.html)

Deploy je otázkou asi čtyř statementů v ansible.

Teď se chystám ve svém stacku obdobně obsloužit libvirt/qemu, ale tam to bude na delší běh, protože tam ti Ansible umožňuje nahrát xml s definicí VMky, a to je takové api neapi. :/ :)

Re:Kontejnerizace a různé pohledy
« Odpověď #13 kdy: 11. 04. 2022, 10:50:16 »
Pokud mate vic zakazniku a planujete dlouhodobejsi spolupraci pak bych sel cestou k8s/okd v on-premu. Ano neni to ze zacatku jednoduchy na nasazeni, ale po prvotnich porodnich bolestech vam spravne navrzene reseni usetri spoustu casu. U k8s je jen dobre si dat pozor na network cni, aby reflektovalo to co od nej chcete (treba egress/ingress na namespaces, network policy etc) a dat tomu nakou stabni kulturu pouzivanejch technologii aby se Vam to nezvrhlo v technologicke zoo.

Pokud to chcete bastlit pres podmana nebo jine docker like systemy, dovedu si predstavit reseni mit ruzne kontejnery jednoho zakaznika ve vlastnim bridgi, ktery pak pres veth proroutujete/pronatujete ven. Pokud pouzijete misto linux bridge napr. openswitch daj se s tim delat kouzla jako tuneling l2 pres vxlany (pokud se treba rozhodne mit ten redis na jinym zeleze nez ty nginxy z nakejch duvodu) apod. Fantasii se meze nekladou a zalezi jen na Vasem na designu.

Imho zalezi hodne na tom kolik a jake zakazniky na tom chcete provozovat, kolik a jake aplikace chcete mit atd apod.

Jinak nechapu jaky je rozdil automatizovat vmka a automatizovat kontejnery…. Smirte se s tim ze holt musite vyvinout nejake usili aby Vam to prineslo kyzeny efekt. Obecne moderni it je hlavne o automatizaci, takze otazka imo neni proc ano, ale spis proc proboha ne ?

Rozdil je jednoduchy. Automatizovat VM znamena jit na uroven hypervizoru. Automatizovat kontejner, na to staci teoreticky docker compose nebo nejaky subsystem nad tim a muze se to cele schovat do VM.
A nemyslim si, ze ve firme, kde jedina znalost s kontejnery je docker compose, existuje clovek, co umi spravne navrhnout k8s. Ta komplexita to zabiji.

Re:Kontejnerizace a různé pohledy
« Odpověď #14 kdy: 11. 04. 2022, 10:51:44 »
Kdybych umel automaticky generovat VM vcetne vsech dokumentaci a pridavnych sluzeb, tak do kontejneru ani nepachnu :)

Tyhle věci už dneska jdou.
Já jsem byl teď neobyčejně spokojen s automatizací generování VM ve vsphere pomocí Ansible.
Vsphera poskytne API, nu a Ansiblem za něj taháš. (https://docs.ansible.com/ansible/latest/collections/community/vmware/index.html)

Deploy je otázkou asi čtyř statementů v ansible.

Teď se chystám ve svém stacku obdobně obsloužit libvirt/qemu, ale tam to bude na delší běh, protože tam ti Ansible umožňuje nahrát xml s definicí VMky, a to je takové api neapi. :/ :)

Ja nemam ani to vmware :-) Pouze proxmox. Ale hlavne, tu automatizaci kontejneru pak musi ovladat primarne aplikace (cti, vyvojari), nejde ani tak o automatizaci pro systemaky. O to je to slozitejsi treba z hlediska ansible.