Fórum Root.cz
Hlavní témata => Distribuce => Téma založeno: MP 18. 09. 2017, 16:31:07
-
Hoj,
vyvojari u nas ve firme posilhavaji cimdal vice po novych technologiich. Technologie ruznych typu, primarne pro webove aplikace. Vzhledem k tomu, ze nase servery jsou postavene na Debianech, tak se to stretava z hlediska "zastaralosti" verzi. Zatim se mi podarilo udrzet to ve stavu, kdy na produkcni servery jdou pouze veci z repozitaru Debianu, pripadne primo tvurcu SW, ale narustaji tlaky na pouzivani aktualnich verzi. A neco ma "jen" instalator...
Docela by me zajimalo, kdo si prosel takovymhle obdobim, nez se stabilizovaly procesy z hlediska nasazovani verzi, jak to zhruba probihalo, resp., k cemu se nakonec dospelo.
tldr: vyvojar chce verzi X. V distribuci je verze Y<X, aktualni verze neni ani v unstable/testing, nebo existuje jen instalator. Jake jsou rozumne moznosti reseni?
Jako priklad uvadim composer. V debianu je az v Deb9 se zavislostmi na PHP7, ale verze je starsi nez aktualni. Vyvojar ho chce na Deb8 s PHP5. Pokud budou servery mix Deb8/9, kterou verzi byste tam nainstalovali a proc?
-
Toto jsem ve firmě řešil víckrát, nakonec jsem vedl úvahu o rozdělení projektů:
1. Projekty, které jdou neustále dopředu, a které mají speciální požadavky.
U takových mám v rozpočtu zahrnuto, že jedou na vlastní VPS (případně aspoň FreeBSD jailu). Těm udržuji prostředí, jaké si řekne programátor a počítám s tím, že to něco stojí. Nepodařilo se mi nikdy nakombinovat na stejný server projekt se speciálními požadavky a "běžné" projekty.
2. Projekty "vyrob a zapomeň".
To jsou projekty, kde zákazníkovi předáte verzi, a nepočítá se s dalším (průběžným) vývojem. Někdy je to dáno typem projektu (jednorázovka, k určité příležitosti), jindy je to dáno budgetem nebo přístupem (očekáváním) zákazníka. V tom případě mají programátoři k dispozici server, kde je aktuální Debian / FreeBSD, který udržím až do konce životnosti ve své verzi.
Tím mi historicky vznikly servery s Debian 7, 8, 9, které udržuji.
3. Udržované projekty
Ty vznikají ze skupin 2 tím, že se na nich aspoň čas od času pracuje, a je tedy časová dotace na to, tyto projekty aspoň pomalu migrovat na vyšší verze prostředí.
4. Databázové servery
PostgreSQL a MySQL, resp. MariaDB mám vždy na oddělených strojích, výjimkou jsou projekty ve skupině 1. Tím si mohu dovolit, že se nemusí dělat změny v práci s databází, i když povýším zbytek prostředí.
5. Využívání FreeBSD a jailů
Dobře se mi osvědčilo pracovat v jailech na FreeBSD. Tím můžu mít s poměrně malou režií k dispozici víc kombinací prostředí.
Summa summarum: nejprve je potřeba rozdělit projekty podle toho, na co je budget. Pak je jistě potřeba trochu držet zpátky programátory, ne vždy a všude je možné jim dělat custom prostředí. Instalovat z neoficiálních repozitářů lze, ale o to více je problematická otázka udržitelnosti prostředí. Často tyto repozitáře uhynou, nebo podporují jen nejnovější debian, a pak jste nahraný. Naopak, tam kde je budget, lze jít stále dopředu. Pak je docela zajímavé zvážit FreeBSD, jeho systém instalace z portů má nesporné výhody v těchto situacích. Lze tam nakombinovat verze daleko volněji, než u Debiana.
-
Docker... rikam to nerad, sere me ve spouste veci, ale tohle nam vyresil.
-
Docker... rikam to nerad, sere me ve spouste veci, ale tohle nam vyresil.
Jak docker vyresi roubovani novych veci na "starou" infra, kdyz se s necim takovym tehdy nepocitalo?
-
Dokazes jednoduse modernizovat infra toho konkretniho projektu bez zasahu do cehokoliv dalsiho.
-
Dokazes jednoduse modernizovat infra toho konkretniho projektu bez zasahu do cehokoliv dalsiho.
Musí se to udělat správně
-
Docker... rikam to nerad, sere me ve spouste veci, ale tohle nam vyresil.
Jak docker vyresi roubovani novych veci na "starou" infra, kdyz se s necim takovym tehdy nepocitalo?
Podobně jako virtualizace. Můžeš mít x různých verzí PHP s různými verzemi Composeru, klidně i na starší verzi systému.
-
Podobně jako virtualizace. Můžeš mít x různých verzí PHP s různými verzemi Composeru, klidně i na starší verzi systému.
Kontejnery tu nejsou od toho abysis udelal v infrastrukture bordel - jak resis napriklad security updaty? Ani pro docker neni moc nastroju co ti reknou, jaka knihovna ma jake CVE, pokud neni instalovana z balicku a nepuzijes CVE databaze od distribuci. A kdyz upstream tu verzi nepodporuje, tak si fixy backportujes sam?
-
Podobně jako virtualizace. Můžeš mít x různých verzí PHP s různými verzemi Composeru, klidně i na starší verzi systému.
Kontejnery tu nejsou od toho abysis udelal v infrastrukture bordel - jak resis napriklad security updaty? Ani pro docker neni moc nastroju co ti reknou, jaka knihovna ma jake CVE, pokud neni instalovana z balicku a nepuzijes CVE databaze od distribuci. A kdyz upstream tu verzi nepodporuje, tak si fixy backportujes sam?
Na všechny tyto problémy se mi jeví jako dobré a udržitelné řešení FreeBSD a jaily. Tam všechno toto jde víceméně dobře splnit.
-
Docker... rikam to nerad, sere me ve spouste veci, ale tohle nam vyresil.
Jak docker vyresi roubovani novych veci na "starou" infra, kdyz se s necim takovym tehdy nepocitalo?
Podobně jako virtualizace. Můžeš mít x různých verzí PHP s různými verzemi Composeru, klidně i na starší verzi systému.
A jak do toho naroubujes tento priklad VM:
1]Deb7 s apache + mod_php, sql, vice web projektu
2]chces do toho nacpat composer + git
A] composer az z Deb9? se zavislostmi na php7/phar
B] git? verze/zavislosti ted netusim, ale vyreseni pull/push modelu a prava na webslozkach
C] ruzne verze php? hm, to asi apache neda, takze tam budeme mit "nat" na kontejnerovych apache s php?
D] security s tim souvisejici? pristup k slozkam, aktualizace atd...
Nerikam ze to nejde. Jen mam pocit, ze s tim vznika (D]) vice problemu nez to cele zacit stavet znova...Jen jde o to, ze vyvojari chteji neco, na co ta stara infra pripravena proste nebyla a obecne, spousta projektu neni v repozitarich non-edge distribuci, ale casto jen na githubu...
-
A jak do toho naroubujes tento priklad VM:
1]Deb7 s apache + mod_php, sql, vice web projektu
Tohle reseni nema. Ale docker ti muze vyrazne pomoci ty projekty oddelit.
-
A] Toto nie je chybou dockera, to nevyriesi ani on ani VM
B] Preco git vo VM? Nechapem uplne otazku
C] "Politika" dockera je 1 kontajner 1 appka, nie je dovod tam mat viacero php, nesnazit sa z neho spravit VM
D] image sa daju skenovat na CVE, aktualizacie na distro vychadzaju tak rychlo ako na bezne distro
Celkovo pre vyuzitie dockera treba zmenit pristup vyvoja, nie je to klasicky vyvoj na VM
-
Obavam se, ze muzes vest nekonecnou debatu na tema, docker/jail/cloud... Ale to hlavni stejne nevyresis: Kdo ze tebe bude urzovat aktualni verze baliku, vcetne zaplat? Nakonec se stejne budes muset v tema vyvojarema dohodout a vysvetlit jim, ze musi zuzit porfolio toho na cem ty aplikace bezi.
-
S tymto sa neda nez suhlasit, nech je riesenie akekolvek, cim sirsie spektrum im das, tym viac roboty aj pre teba.
-
Chápu že to byl jen příklad, ale zrovna composer na produkčním serveru většinou nepotřebuješ. Ten by se měl instalovat jen v buildovacím kontejneru (který může být klidně "naprasený") a na produkci se nasadí aplikace už s nainstalovanými závislostmi. Stejně jako na produkci nemáš git, npm, apod.
-
Chápu že to byl jen příklad, ale zrovna composer na produkčním serveru většinou nepotřebuješ. Ten by se měl instalovat jen v buildovacím kontejneru (který může být klidně "naprasený") a na produkci se nasadí aplikace už s nainstalovanými závislostmi. Stejně jako na produkci nemáš git, npm, apod.
To je presne jedna z veci, ktere se tu nejakym zpusobem resi - vyvojari chteji "nove metody" na "starych". Cili, samotne nasazovani/aktualizace - (git,npm,composer) jak? sprava aplikacu - (npm) jak? Napr. bezi nam ty composer aplikace rucne pridane do projektu, ted by se o to mel o spravu techto aplikaci starat composer, takze ten composer na ty "stary" ted potrebuji. To samy, git. Npm je takovy vice extra, nebot nodejs aplikace se musi "spustit znova" po aktualizaci, oproti klasickemu pushnuti aplikacnich skriptu do webserveru, cela logika spravy je uplne jina. A s tim se samozrejme stretava prave ta oblast aktualni/starsi obsah (ne)repozitaru. Zatim to vypada, ze nez se vyjasni vyvojarsky workflow pro "novou", tak s tim bude dost boj.
-
Jen aby bylo jasno, neni to ted o kontejnerizaci, ta se u nas ted testuje hlavne pro zlepseni vyvoje, ne pro produkci, produkce bude dale na VM a tam urcite nehrozi, ze by kazdy projekt mel vlastni VM. A i kdyby mel, tak sondujeme, jak to v ruznych firmach chodi z hlediska (ne)existence (ne)aktualnost ruznych projektu z hlediska repozitaru.
-
Jen aby bylo jasno, neni to ted o kontejnerizaci, ta se u nas ted testuje hlavne pro zlepseni vyvoje, ne pro produkci, produkce bude dale na VM a tam urcite nehrozi, ze by kazdy projekt mel vlastni VM. A i kdyby mel, tak sondujeme, jak to v ruznych firmach chodi z hlediska (ne)existence (ne)aktualnost ruznych projektu z hlediska repozitaru.
Docker by vás mohl zbavit těch VM. Docker sám by jel přímo na železe a každý projekt by měl vlastní kontejner. Jádro systému je tedy sdíleno všemi kontejnery, v každém z nich může být jiná verze distribuce, knihoven, Apache, PHP i databáze.
Výhodou také je, že s těmi kontejnery můžeš migrovat mezi fyzickými servery dle potřeby. Když budeš např. potřebovat server vypnout, tak kontejnery přestěhuješ jinam a můžeš montovat.
-
Výhodou také je, že s těmi kontejnery můžeš migrovat mezi fyzickými servery dle potřeby. Když budeš např. potřebovat server vypnout, tak kontejnery přestěhuješ jinam a můžeš montovat.
Nemusí v tom případě být na sdileném siťovém filesystému?
-
Docker by vás mohl zbavit těch VM. Docker sám by jel přímo na železe a každý projekt by měl vlastní kontejner. Jádro systému je tedy sdíleno všemi kontejnery, v každém z nich může být jiná verze distribuce, knihoven, Apache, PHP i databáze.
Kernel sice ma pravidlo "dont break userspace", ale tohle tvrzeni plati jen pokud pouzivas starsi distribuci na novejsim kernelu, opacne nejde zarucit - obecne muzou nastat problemy mezi libc a kernelem, pokud mas starsi jadro a moc novou distribuci v dockeru. V podstate jsi v situaci ze si do nove distribuce rucne vrazis nejaky nepodporovany kernel - napadlo by nekoho instalovat Alpine kernel balicek na Debian? To je presne, co se s kontejnery deje. To znamena, ze bezite svou produkci v nejake totalne neotestovatelne kombinaci SW a modlite se aby to nejak fungovalo. Ne vse, co si muze vyvojar dovolit na dekstopu je dobry napad v produkci.
-
V čem je přínosnější docker na železe oproti např. lxc na železe se zfs? Nevím, jen se ptám, s dockerem jsem si svého času hrál, lxc používám a přijde mi vynikající.
-
V čem je přínosnější docker na železe oproti např. lxc na železe se zfs? Nevím, jen se ptám, s dockerem jsem si svého času hrál, lxc používám a přijde mi vynikající.
V nicem a ve vsem. Z heldiska technologie jako kontejnery (ruzne namespaces, cgroups, seccomp, selinux). Rozdil je az v celem ekosystemu, kdy nastupuji veci jako kubernetes. Bachorkam o aplikacnim a systemovem kontejneru taky never, protoze z heldiska kernelu se to chova stejne.
-
V čem je přínosnější docker na železe oproti např. lxc na železe se zfs? Nevím, jen se ptám, s dockerem jsem si svého času hrál, lxc používám a přijde mi vynikající.
Docker aj LXC su postavene nad cgroups, cize vo vykonnosti nie ziadny podstatny rozdiel. Docker ma vsak vela pozornosti na rozdiel od LXC + velky ekosystem: hotove image z bezplatneho Docker Hubu, vela nastrojov, ... Ten ekosystem ho robi cislom 1 v sucasnej kontajnerizacii.
-
Kernel sice ma pravidlo "dont break userspace", ale tohle tvrzeni plati jen pokud pouzivas starsi distribuci na novejsim kernelu, opacne nejde zarucit - obecne muzou nastat problemy mezi libc a kernelem, pokud mas starsi jadro a moc novou distribuci v dockeru. V podstate jsi v situaci ze si do nove distribuce rucne vrazis nejaky nepodporovany kernel - napadlo by nekoho instalovat Alpine kernel balicek na Debian? To je presne, co se s kontejnery deje. To znamena, ze bezite svou produkci v nejake totalne neotestovatelne kombinaci SW a modlite se aby to nejak fungovalo. Ne vse, co si muze vyvojar dovolit na dekstopu je dobry napad v produkci.
[/quote]
Mate nejaky realny priklad, ktorym sa da vase tvrdenie overit?
Kompilujem totiz binarne moduly pre rozne distribucie prave cez Docker kontajnery a ani raz som sa nestretol s popisovanym problem.
-
Docker by vás mohl zbavit těch VM. Docker sám by jel přímo na železe a každý projekt by měl vlastní kontejner. Jádro systému je tedy sdíleno všemi kontejnery, v každém z nich může být jiná verze distribuce, knihoven, Apache, PHP i databáze.
Kernel sice ma pravidlo "dont break userspace", ale tohle tvrzeni plati jen pokud pouzivas starsi distribuci na novejsim kernelu, opacne nejde zarucit - obecne muzou nastat problemy mezi libc a kernelem, pokud mas starsi jadro a moc novou distribuci v dockeru. V podstate jsi v situaci ze si do nove distribuce rucne vrazis nejaky nepodporovany kernel - napadlo by nekoho instalovat Alpine kernel balicek na Debian? To je presne, co se s kontejnery deje.
Kernel obvykle bývá nejnovější, na něm běží server Dockeru. Kontejnerům by tohle nemělo vůbec vadit, i když jsou ve starší verzi než kernel.
-
Mate nejaky realny priklad, ktorym sa da vase tvrdenie overit?
Kompilujem totiz binarne moduly pre rozne distribucie prave cez Docker kontajnery a ani raz som sa nestretol s popisovanym problem.
Nic, co bych mohl primo linkovat (Docker je relativne mladej, takze je to spis vzacnost). Ale staci se podivat na veci kolem kompilace glibc a --enable-kernel option, zaroven si muzete zkusit do glibc pridat nove volani a linkovat ho, pridat syscall a pouzit ho v aplikaci a tu pak spustit na starsi distribuci, zpusobu jak to nasimulovat je dost. To jsou veci, ktere se proste v realnem vyvoji postupne stavaji.
-
Mate nejaky realny priklad, ktorym sa da vase tvrdenie overit?
Kompilujem totiz binarne moduly pre rozne distribucie prave cez Docker kontajnery a ani raz som sa nestretol s popisovanym problem.
Nic, co bych mohl primo linkovat (Docker je relativne mladej, takze je to spis vzacnost). Ale staci se podivat na veci kolem kompilace glibc a --enable-kernel option, zaroven si muzete zkusit do glibc pridat nove volani a linkovat ho, pridat syscall a pouzit ho v aplikaci a tu pak spustit na starsi distribuci, zpusobu jak to nasimulovat je dost. To jsou veci, ktere se proste v realnem vyvoji postupne stavaji.
Tohle mi připadá jako hodně okrajová záležitost. Není mi jasné, proč by někdo provozoval Docker na zastaralém jádře.
-
Nic, co bych mohl primo linkovat (Docker je relativne mladej, takze je to spis vzacnost). Ale staci se podivat na veci kolem kompilace glibc a --enable-kernel option, zaroven si muzete zkusit do glibc pridat nove volani a linkovat ho, pridat syscall a pouzit ho v aplikaci a tu pak spustit na starsi distribuci, zpusobu jak to nasimulovat je dost. To jsou veci, ktere se proste v realnem vyvoji postupne stavaji.
Som asi este mlade ucho lebo som si este nikdy do glibc nepridal nove volanie :-). Podla mna je to to tiez iba okrajovy pripad low level programovania. U beznych jazykov (C, Golang, nodejs, java, ...) v kontajneri sa spominanej kernel nekompatibility neobavam.
-
Nic, co bych mohl primo linkovat (Docker je relativne mladej, takze je to spis vzacnost). Ale staci se podivat na veci kolem kompilace glibc a --enable-kernel option, zaroven si muzete zkusit do glibc pridat nove volani a linkovat ho, pridat syscall a pouzit ho v aplikaci a tu pak spustit na starsi distribuci, zpusobu jak to nasimulovat je dost. To jsou veci, ktere se proste v realnem vyvoji postupne stavaji.
Som asi este mlade ucho lebo som si este nikdy do glibc nepridal nove volanie :-). Podla mna je to to tiez iba okrajovy pripad low level programovania. U beznych jazykov (C, Golang, nodejs, java, ...) v kontajneri sa spominanej kernel nekompatibility neobavam.
Je bezne, ze na hypervizoru bezi i novejsi verze OS ve VM/kontejneru, nez je samotna verze OS hypervizoru.
-
I když to pro vás asi není řešení, tohle velice elagantně řeší Go. Jeden staticky linkovaný spustitelný soubor, který může obsahovat i všechny js knihovny, templaty apod. Může vám jich běžet na serveru několik, různé verze. Nijak se neovlivňují. Navíc díky "compatibility promise" je velice jednoduché (s porovnáním s jinými jazyky) přecházet na vyšší verze.
-
I když to pro vás asi není řešení, tohle velice elagantně řeší Go. Jeden staticky linkovaný spustitelný soubor, který může obsahovat i všechny js knihovny, templaty apod. Může vám jich běžet na serveru několik, různé verze. Nijak se neovlivňují. Navíc díky "compatibility promise" je velice jednoduché (s porovnáním s jinými jazyky) přecházet na vyšší verze.
Jako bych si nemohl nalinkovat staticky libovolnou binárku, v libovolném programovacím jazyce...
-
Jako bych si nemohl nalinkovat staticky libovolnou binárku, v libovolném programovacím jazyce...
Tak to zkus. Na Solarisu to nejde, a na Linuxu to za chvili taky nepujde.
Zkus staticky slinkoval libstdc++ pomoci cmake anebo pomoci neceho jineho. Zkus staticky slinkovat glibc.
RedHat a lidi okolo glibc jsou proti.
-
Jako bych si nemohl nalinkovat staticky libovolnou binárku, v libovolném programovacím jazyce...
Tak to zkus. Na Solarisu to nejde, a na Linuxu to za chvili taky nepujde.
Zkus staticky slinkoval libstdc++ pomoci cmake anebo pomoci neceho jineho. Zkus staticky slinkovat glibc.
RedHat a lidi okolo glibc jsou proti.
Uznávám, staticky linkovat glibc s cmake je vopruz. Také proto jsem opustil glibc, a ne statické linkování. Ale spíš kvůli současné cross-kompilaci, protože pak už s glibc opravdu ne...
Glibc povinné není, existují minimálně dvě možné alternativy, a jedna z nich náhodou od RedHatu. libstdc++ jsem takto zatím linkovat nepotřeboval, takže nevím jaký je tam problém.
A na Solarisu jsem aplikace linkoval už velice dávno.