Příspěvky

121

Server / Re:Kontejnerizace a různé pohledy

« 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.

122

Server / Re:Kontejnerizace a různé pohledy

« 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.

123

Distribuce / Debian 11 - chybí /var/run/reboot-required

« kdy: 08. 04. 2022, 09:49:21 »

Ahoj,

zjistil jsem, ze mi chybi /var/run/reboot-required, ktery by mel byt vytvaren automaticky.  Je jedno, zda updatuju pres ansible, ci pres aptitude, proste chybi.

Nevi nekdo, co zkontrolovat? "needrestart -k" detekuje rozdil kernelu, ale pripadne resit, jak to dostat do ansible skriptu, je vetsi opruz...

124

Server / Re:Kontejnerizace a různé pohledy

« 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.

125

Server / Re:Kontejnerizace a různé pohledy

« 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.

126

Server / Re:Kontejnerizace a různé pohledy

« kdy: 07. 04. 2022, 10:26:02 »

Jasne, provozovat k8s on-premise v jednom cloveku, uz se do toho zenu
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.

127

Server / Re:Kontejnerizace a různé pohledy

« 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...

128

Hardware / Re:NVME adaptér do staršího serveru

« kdy: 05. 04. 2022, 10:35:33 »

Kdo normální by provozoval ostrý server na vysloužilém hardware bez jakékoliv podpory?

By ses divil, tech "normalnich" najdes odhaduju nejmene u 20% firem.

129

Server / 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.

130

Studium a uplatnění / Re:Práce IT Admina

« kdy: 31. 03. 2022, 13:21:53 »

lidi, kteří mám na on-call pohotovosti mimo pracovní dobu dostávají 70 % platu formou příplatku, je to jejich rozhodnutí, jestli si směnu vezmou, domlouvá se to cca dva až čtyři týdny dopředu. Pokud je práce mimo pracovní dobu v kanceláři/datacentru, mají 130 % denní sazby. Dodávám průběžně do většiny českých bank a všude ty podmínky máme obdobné. V oboru dělám 15 let a nevšiml jsem si, že by někdo někoho vykořisťoval, nutil dělat podporu zadarmo.

Pokud je někdo zaměstnanec, máme tady poměrně přísný pracovní zákoník a velké firmy to dodržují až absurdně. Pokud někdo dělá jako OSVČ a přitom je to falešný zaměstnanec, tak je možné, že ty podmínky budou jiné, ale to je jeho věc, jak si ten smluvní vztah dohodne, tam jsou si obě strany rovni.

Ja jsem zamestnanec, ve smlouve ani slovo o pohotovosti, ani pracovni doba neni zcela pevna. Defacto jsem v pozici one-man IT (+urcita zastupitelnost ze strany sefa). Ale druhy sef ocekava minimalne 99,99% dostupnost sluzeb pro zakazniky :-) (Pry to ma ve SLA, dokonce mluvi o PETI devitkach).
A podobne je to v mnoha mensich firmach s one-man IT.

131

Studium a uplatnění / Re:Práce IT Admina

« kdy: 31. 03. 2022, 08:50:09 »

Primárně operations je o tom být dostupný (pohotovosti apod.), často někdo na úrovni hasiče co řeší problémy co přijdou. Co se týká nudy, to bych řekl, že je stav mysli víc než by to souviselo s profesí.

A s timto zcela souhlasim. Kdybych mohl v minulosti znovu volit, delat v operations bych jiz nesel. Sel bych do vyvoje nebo jine oblasti, kde si jentak nekdo nedovoli zavolat v 1 rano, ocekavat, ze clovek bude po pracovni dobe k dosazeni  pro pripad haseni problemu apod.

A kazdemu kdo se zepta, doporucim to same: nechod delat administratora. Skoro vsichni cekaji, ze budes v pohotovosti 24/7 a zadarmo. Bez delat treba vyvojare, kdyz te budou stvat, tak se snaze zvednes a vezmou te jinde.

132

Server / Re:Přístup k logům mailserveru

« kdy: 30. 03. 2022, 16:25:12 »

Tak jsem jeste narazil na systemd-journal-remote resp. systemd-journal-upload a systemd-journal-gatewayd. Ani jsem netusil, ze to existuje...

Pridam si sem popis, jak to muze fungovat:
https://www.digitalocean.com/community/tutorials/how-to-centralize-logs-with-journald-on-debian-10
https://sematext.com/blog/journald-logging-tutorial/

133

Server / Re:Přístup k logům mailserveru

« kdy: 30. 03. 2022, 16:05:09 »

Tak jsem jeste narazil na systemd-journal-remote resp. systemd-journal-upload a systemd-journal-gatewayd. Ani jsem netusil, ze to existuje...

134

Studium a uplatnění / Re:Práce IT Admina

« kdy: 30. 03. 2022, 08:55:47 »

Ja ti napisu, co bezny admin dela.

Odrazi pozadavky na to, aby byl dostupny 24/7, aby delal vetsinu praci po pracovni dobe vsech ostatnich (cti v noci), pokud mozno kazdy den.

135

Server / Re:Přístup k logům mailserveru

« kdy: 24. 03. 2022, 12:10:27 »

No tak my tu nemame ani kafku, s elastikem experimentujeme teprve takze...nam zbyva jen prenos textovych logu nebo to sypat rovnou do db.

20t/hod je vykonovy limit soucasneho serveru, kdyz dojde k jeho zahlceni (cca 7k per postfix instance, je jich tam vic), realne posilame objemy i nad sto tisic. To vlastne si jeste musime rict, zda to budeme prenaset davkove ci realtime...

Nemluve o pripadne zatezi "ciloveho" log serveru.