Vývoj vs. repozitáře aneb když nejsou aktuální verze

[MP]

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.

[Reklama]

[MP]

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.

[Kit]

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.

[lazywriter]

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?

[ldj]

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.

[Reklama]

[dustin]

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

[ldj]

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.

[martinnn]

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.

[martinnn]

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.

[Kit]

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.

[ldj]

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.

[Kit]

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.

[martinnn]

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.

[MP]

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.