Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny. - Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker - Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos - Používám Arch, Podman v rootless režimu (z mnoha důvodů). - Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP. - Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění, výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Díky, Petr
Ahojte,
sorry nemám odpověď, ale chtěl jsem se zeptat proč je Docker tak oblíbený, když LXC/LXD je mnohem jednodušší na zprovoznění a chyby se tam ladí lépe a přijde mi to i rychlejší?
Má k tomu někdo fundovaný opravdu smysluplnou odpověď? Snažil jsem se Docker používat několikrát, ale přijde mi to hrozně překombinované a horší situaci jsem pak zažil na armu, kdy většina aplikací prostě nejela (různé chyby/problematické nastavení/overlayfs). Předpokládám, že na x86, je tohle asi v pohodě, ale když jsem si pak připravil přímé virtuály s alpine nebo ubuntu nad LXC a nad něma jen pouze aplikace, tak to šlo hodně rychle a byl jsem to schopnej i opravit přímo.
Takže moje otázka zní co je na tom Dockeru tak skvělého oproti LXC ? můj tip je, že se to lidem zdá jednoduché (jeden příkaz a je tam aplikace)
Zdenek
ne 12. 7. 2020 v 21:24 odesílatel Petr Kutalek petr@kutalek.cz napsal:
Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery
a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny.
- Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker
- Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos
- Používám Arch, Podman v rootless režimu (z mnoha důvodů).
- Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP.
- Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění,
výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Díky, Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Zdar,
predem rikam, ze docker pouzivam jenom na amd64, takze nevim, jestli je na jinych architekturach situace horsi.
On 2020-07-13 07:14:00 +0200, zd nex wrote:
když LXC/LXD je mnohem jednodušší na zprovoznění
Citation needed. Naposled jsem zabil asi hodinu tim, ze jsem se snazil rozchodit userns lxc nez jsem to vzdal s tim, ze fakt uz nevim.
V porovnani s tim pro kombinaci buildah/podman to byla otazka vytvoreni /etc/sub{u,g}id a hotovo, fungovalo to.
přijde mi to i rychlejší?
Vykon by mel byt srovnatelny (snad s vyjimkou site, protoze docker jede vsechno pres iptables afaik; lxc se vetsinou pouziva pres bridge ne?).
[..]
Takže moje otázka zní co je na tom Dockeru tak skvělého oproti LXC ? můj tip je, že se to lidem zdá jednoduché (jeden příkaz a je tam aplikace)
Jenom bych rad zminil, ze s dockerem mam vice zkusenosti, takze otazky na lxc jsou skutecne otazky, budu rad kdyz mne nekdo opravi :)
1. LXC je k nicemu v kubernetes (LXE projekt se netvari production ready). Takze v praci se dockeru nevyhnu.
2. Snadny presun containeru mezi pocitaci (docker push/pull). Ma lxc take neco takoveho? Buildah dokonce umi i export klasicky na disk, takze se to pak da zatarovat a presouvat jako jeden bezny soubor. S tim, ze korektne funguje uid/gid (userns) i napric pocitaci.
3. Dockerfile je pomerne rozumny zpusob vytvareni containeru, vsechno env promennych a entrypointu. Je neco podobneho pro lxc?
4. Docker containery jsou zamyslene jako snadno zahoditelne, takze udelaji svoji praci, jsou smazane a priste nabehnout v pristine stavu. Mam pocit, ze pres lxc snapshot by melo jit delat neco podobneho, ale afaik to tak neni out-of-the-box a navic jak jsem zminil, vzhledem k tomu, ze se mi to nepovedlo rozchodit, tak jsem to moc testovat nemohl.
5. Pro spoustu aplikaci, kde container je skutecne zamyslen jako jedna applikace, to proste pusobi jako lepsi fit. Napriklad pokud mi jde ciste o to rozbehat nejaky proprietary trash, ktery vyzaduje glibc, tak zabalit jenom tu jedno vec do dockeru s nejaky minimalnim systemem a nastavit ji jako entrypoint pusobi lepe pouzitelne nez to same v lxc (protoze se to z vnejsu vskutku chova jako ta aplikace). To same (ci podobne) by nejspise slo dosahnout i v lxc, ale what's the point?
Zaverem dodam, ze je klidne mozne, ze mi z lxc neco fundamentalniho unika a rad se necham poucit. Ale snad to nebylo uplne mimo. Bod 2 je pro mne asi nejvetsi blocker, takze zvlast tady kdyby mne nekdo poucil, bylo by to super.
W.
No co se týče neprivilegovaného kontejneru, tak tam je potřeba prostě postup. Mít lxc-usernsexec a uidmap a následně mapování. No a někdy bývá problém s přístupem na .local/share/lxc při kopírování
https://github.com/lxc/lxc/issues/2930 Na druhou stranu pak to opravdu funguje.
1) - asi LXD? No vím, že to už lidi používají a asi i ve velkém, ale asi to není stále na úrovni Kubernetess 2) pokud vím tak lxc image jsou normální adresáře např. v .local/share/lxc (tzn lze s tím dělat spoustu věcí) Jinak LXD má nějaké věci navíc není zde ale místo kam to jednoduše nahrávat, pokud si to asi lidi neudělají. 3) LXD má pak i něco takového https://linuxcontainers.org/lxd/docs/master/image-handling případně úprava image 4) lxc-snapshot jsou stavy (LXD má pak jinou funkcionalitu). Jinak je možné ho přímo smazat/clone 5) O to jsem se zatím nesnažil, takže nevím, ale viděl jsem jak lidi upravili alpine image přímo na aplikaci.
Na druhou stranu chápu ten důvod, že tady když to uživatel připraví na dockeru, tak to prostě bere tak, že je to hotové a připravené. To bohužel, asi na lxc/lxd ještě nějaký čas reálné nebude, pokud někdy bude.
po 13. 7. 2020 v 11:25 odesílatel Wolf wolf@wolfsden.cz napsal:
Zdar,
predem rikam, ze docker pouzivam jenom na amd64, takze nevim, jestli je na jinych architekturach situace horsi.
On 2020-07-13 07:14:00 +0200, zd nex wrote:
když LXC/LXD je mnohem jednodušší na zprovoznění
Citation needed. Naposled jsem zabil asi hodinu tim, ze jsem se snazil rozchodit userns lxc nez jsem to vzdal s tim, ze fakt uz nevim.
V porovnani s tim pro kombinaci buildah/podman to byla otazka vytvoreni /etc/sub{u,g}id a hotovo, fungovalo to.
přijde mi to i rychlejší?
Vykon by mel byt srovnatelny (snad s vyjimkou site, protoze docker jede vsechno pres iptables afaik; lxc se vetsinou pouziva pres bridge ne?).
[..]
Takže moje otázka zní co je na tom Dockeru tak skvělého oproti LXC ? můj tip je, že se to lidem zdá jednoduché (jeden příkaz a je tam aplikace)
Jenom bych rad zminil, ze s dockerem mam vice zkusenosti, takze otazky na lxc jsou skutecne otazky, budu rad kdyz mne nekdo opravi :)
- LXC je k nicemu v kubernetes (LXE projekt se netvari production
ready). Takze v praci se dockeru nevyhnu.
- Snadny presun containeru mezi pocitaci (docker push/pull). Ma lxc
take neco takoveho? Buildah dokonce umi i export klasicky na disk, takze se to pak da zatarovat a presouvat jako jeden bezny soubor. S tim, ze korektne funguje uid/gid (userns) i napric pocitaci.
- Dockerfile je pomerne rozumny zpusob vytvareni containeru, vsechno
env promennych a entrypointu. Je neco podobneho pro lxc?
- Docker containery jsou zamyslene jako snadno zahoditelne, takze
udelaji svoji praci, jsou smazane a priste nabehnout v pristine stavu. Mam pocit, ze pres lxc snapshot by melo jit delat neco podobneho, ale afaik to tak neni out-of-the-box a navic jak jsem zminil, vzhledem k tomu, ze se mi to nepovedlo rozchodit, tak jsem to moc testovat nemohl.
- Pro spoustu aplikaci, kde container je skutecne zamyslen jako jedna
applikace, to proste pusobi jako lepsi fit. Napriklad pokud mi jde ciste o to rozbehat nejaky proprietary trash, ktery vyzaduje glibc, tak zabalit jenom tu jedno vec do dockeru s nejaky minimalnim systemem a nastavit ji jako entrypoint pusobi lepe pouzitelne nez to same v lxc (protoze se to z vnejsu vskutku chova jako ta aplikace). To same (ci podobne) by nejspise slo dosahnout i v lxc, ale what's the point?
Zaverem dodam, ze je klidne mozne, ze mi z lxc neco fundamentalniho unika a rad se necham poucit. Ale snad to nebylo uplne mimo. Bod 2 je pro mne asi nejvetsi blocker, takze zvlast tady kdyby mne nekdo poucil, bylo by to super.
W.
-- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
No, jako nejsem odbornik ani na jedno, takze se rozhodne neodvazuju hodnotit, ale prijde mi, ze pokud se na "kontejnery" prestanes divat ocima "sysadmina" a preostris trochu na developer/devops pohled na vec, tak tam holt "jednoduchost a primocarost" Dockeru ma zasadni vyhody. Verim tomu, ze cokoli dela Docker zvladnes s nejakym toolingem udelat i kolem LXC, ale pro "beznyho Frantu developera, co 'to' musi nekde nasazovat" je holt vyrazne jednodussi pouzit Docker a mit to "zadarmo" nez resit LXC, ansible, kubernetes, reprodukovatelny buildy, snapshoty filesystemu, orchestraci, migrace, nastaveni siti, ... Pridej k tomu to ze pak mas celkem jistotu toho ze cos odladil lokalne _presne_ spustis "tam nekde na serveru", pridej automatizaci kolem vyvoje (automaticky buildy a deploy do devel prostredi pri pushi do gitu) a deploye (rollout na produkci pri updatu Docker image na Hubu) s moznosti bezproblemovyho fallbacku na "minulou" verzi protoze ty kontejnery mas verzovany...
Verim tomu ze "doopravdy kontejnery" (LXC/D) a custom orchestrace vseho maji svoje misto, ale stejne tak ho maji ty single-app kontejnery typu Docker.
J.
On Mon, Jul 13, 2020 at 7:14 AM zd nex zdnexnet@gmail.com wrote:
Ahojte,
sorry nemám odpověď, ale chtěl jsem se zeptat proč je Docker tak oblíbený, když LXC/LXD je mnohem jednodušší na zprovoznění a chyby se tam ladí lépe a přijde mi to i rychlejší?
Má k tomu někdo fundovaný opravdu smysluplnou odpověď? Snažil jsem se Docker používat několikrát, ale přijde mi to hrozně překombinované a horší situaci jsem pak zažil na armu, kdy většina aplikací prostě nejela (různé chyby/problematické nastavení/overlayfs). Předpokládám, že na x86, je tohle asi v pohodě, ale když jsem si pak připravil přímé virtuály s alpine nebo ubuntu nad LXC a nad něma jen pouze aplikace, tak to šlo hodně rychle a byl jsem to schopnej i opravit přímo.
Takže moje otázka zní co je na tom Dockeru tak skvělého oproti LXC ? můj tip je, že se to lidem zdá jednoduché (jeden příkaz a je tam aplikace)
Zdenek
ne 12. 7. 2020 v 21:24 odesílatel Petr Kutalek petr@kutalek.cz napsal:
Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery
a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny.
- Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker
- Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos
- Používám Arch, Podman v rootless režimu (z mnoha důvodů).
- Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP.
- Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění,
výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Díky, Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Pěkný den,
taky se občas pozastavím nad tím, co Docker vlastně přinesl tak zásadního, že se stal tak oblíbeným. Domnívám se, že technologicky nic (nového). Ale to "nic" udělali tak jednoduché pro tak širokou masu (méně znalých) lidí, že to prostě převálcovalo dokonalejší technologie.
Vývojáři jsou klíč k tomu úspěchu. Ti nechtějí mít technologický detail, ale snadnou integraci. Docker jim umožnil díky Docker Hubu zkoušet různé technologie v rámci hodin/minut. Nahodit si databázi na serveru a během 10 minut mít aktivní TCP port - a na ten se připojí aplikací a mají problém vyřešen.
Tady by se mohla rozvinout celá diskuse, kdo je vlastně "vývojář" :-). Řekl bych, že když zkouknete ke kontejnerům pár Youtube videí, tak tipuju, že průměrný vývojář není borec s 20ti letou praxí, protřelý technologiema, metodikama. Tím nemyslím nic špatného, prostě realita je taková (jak to vnímám já).
Tahle masa chce rychlé (apt install docker-ce), snadno integrovatelné (TCP port) a snadno nahoditelné (docker run ...) řešení, které může snadno škálovat (docker service ...) a dneska i velmi snadno migrovat do (veřejného) Kubernetes cloudu (protože do cloudu přece managersky musíme).
Ta velká spousta bezpečnostních a provozních problémů se obvykle buď neřeší, nebo vzniká dojem, že je vyřeší orchestrace (haha :-)). Problém jde řešit jenom tehdy, když se nějak projevuje, nebo o něm vím. A to slýchávám hodně často: "Jaký problém, dyť to jede, ne?!".
A upřímně, i Googlefight má jasno, co vede :-) : https://www.googlefight.com/docker-vs-lxc.php
Takže ti co příjdou "noví" a zadaji do Googlu "containers how to", tak dostanou první dva odkazy na docker.com a už to jede ... :-)
S pozdravem,
Petr Baláži
On 13. 7. 2020 7:14, zd nex wrote:
Ahojte,
sorry nemám odpověď, ale chtěl jsem se zeptat proč je Docker tak oblíbený, když LXC/LXD je mnohem jednodušší na zprovoznění a chyby se tam ladí lépe a přijde mi to i rychlejší?
Má k tomu někdo fundovaný opravdu smysluplnou odpověď? Snažil jsem se Docker používat několikrát, ale přijde mi to hrozně překombinované a horší situaci jsem pak zažil na armu, kdy většina aplikací prostě nejela (různé chyby/problematické nastavení/overlayfs). Předpokládám, že na x86, je tohle asi v pohodě, ale když jsem si pak připravil přímé virtuály s alpine nebo ubuntu nad LXC a nad něma jen pouze aplikace, tak to šlo hodně rychle a byl jsem to schopnej i opravit přímo.
Takže moje otázka zní co je na tom Dockeru tak skvělého oproti LXC ? můj tip je, že se to lidem zdá jednoduché (jeden příkaz a je tam aplikace)
Zdenek
ne 12. 7. 2020 v 21:24 odesílatel Petr Kutalek <petr@kutalek.cz mailto:petr@kutalek.cz> napsal:
Ahoj, tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :) - Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny. - Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker - Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos - Používám Arch, Podman v rootless režimu (z mnoha důvodů). - Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP. - Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění, výsledek je stejný. Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi: > Error: > container_linux.go:367: starting container process caused: > process_linux.go:459: container init caused: > process_linux.go:382: setting rlimits for ready process caused: > error setting rlimit type 7: invalid argument: OCI runtime error Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli? Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické? Díky, Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
On 7/12/20 9:20 PM, Petr Kutalek wrote:
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny. - Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker - Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos - Používám Arch, Podman v rootless režimu (z mnoha důvodů). - Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP. - Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění, výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Hm, chvíli jsem si s tím hrál a tuhle chybu jsem nepotkal... na jakém to máš nodu? Mně to na Archu na node2.stg funguje. Co jsem nerozchodil je podman pod neprivilegovaným uživatelem, hello-world funguje, ale když zkusím pustit bash z ubuntu:latest, stěžuje si to "there might not be enough IDs available in the namespace". Přes to jsem se nedostal, i když mám snad /etc/sub{u,g}id nastaveno...
Tohle mi teda projde jak pod rootem, tak neprivilegovaným uživatelem na nově vytvořené VPS:
docker run --rm -it --cgroup-manager cgroupfs hello-world
Bez --cgroup-manager si to stěžuje že to potřebuje cgroupv2... Máš toho podmana aktuálního? Vidím třeba
https://github.com/containers/podman/pull/2126
Proč je to u nás s kontejnerama někdy složitější? Protože už VPS od nás je kontejner v user namespace, tj. omezenější prostředí a s tím musí docker/podman/whatever počítat. Kontejnery v kontejnerech v kontejnerech... jupí.
Ono i kontejnery tak jak je linux umí mají k dokonalosti hodně daleko, máme spoustů vlastních patchů v kernelu, aby se to vůbec dalo používat... poslední chuťovka je, že když teda řešíme memory limity VPS přes memory cgroup, OOM killer při nedostatku paměti vybere libovolný proces -- klidně ti sejme /sbin/init a tím celou VPS.
Jakub
On 2020-07-13 18:01:37 +0200, Jakub Skokan wrote:
Co jsem nerozchodil je podman pod neprivilegovaným uživatelem, hello-world funguje, ale když zkusím pustit bash z ubuntu:latest, stěžuje si to "there might not be enough IDs available in the namespace".
Pamatujes si, co presne jsi zkousel? Mne
[root@playground ~]# su - test -c 'podman run --rm ubuntu bash -c "echo x"' x
Funguje takze premyslim co delam jinak..
W.
Tedy, díky moc, Wolfe! Přiznám se, že jsem to od 12. 7. někdy později v noci neřešil. Pak jsem tady na svůj mail četl reakce o kupce hnoje, sr***e… To na mne bylo příliš, uvědomil jsem si, že součástí takovéto komunity být nechci. Takže jsem si připravil jiný stroj.
Co jsem nerozchodil je podman pod neprivilegovaným uživatelem, hello-world funguje, ale když zkusím pustit bash z ubuntu:latest, stěžuje si to "there might not be enough IDs available in the namespace".
Pamatujes si, co presne jsi zkousel? Mne
[root@playground ~]# su - test -c 'podman run --rm ubuntu bash -c "echo x"' x
Funguje takze premyslim co delam jinak..
Nyní mi na node7.prg vše funguje bez problémů. Takže děkuji, žes mne k tomu vrátil! :)
Udělal jsi mi radost, pěkný víkend!
Petr
Ahoj,
no... podman je preci Lepsi Nahrada za Docker (tm), ne?
Proto dava smysl, ze:
1. defaultne nepouziva user namespace
- a hlavne, obzlast relevantne tu -
2. nastavuje setrlimit-em maximalni pocet procesu v kontejneru na "unlimited".
Njn, fakt lepsi varianta.
Problem je v tom, ze my tam mame nastaveny limit na neco pres milion per jeden kontejner, neco jako unlimited pro kontejner, v kterem muze bezet "untrusted" kod... process idcka jsou jen 32bitova, to se da predstavit s dost RAM vybombit.
Takze veskrze fakt vylepseni...
Uz oproti dost sracce. Ale Red Hatu se vzdycky povede sracka jeste vetsi - i kdyz tvrdi, ze je to vylepsena krupavejsi chutnejsi alternativa...
Ted je otazka, co s tim.
Jako nejlepsi reseni se mi jevi proste milemu zlatemu podmanu a containerd kecat, ze se mu to povedlo nastavit a pritom to tise nechat na puvodnim limitu.
Co si o tom myslite?
/snajpa
On 2020-07-12 21:20, Petr Kutalek wrote:
Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro
kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny.
- Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker
- Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos
- Používám Arch, Podman v rootless režimu (z mnoha důvodů).
- Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP.
- Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění,
výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Díky, Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Je to udělátor pro vývojáře, takže to musí fungovat - a to i v případě, že vývojářův výtvor je digitální kupka hnoje. Když to fungovat nebude, vývojář půjde ke konkurenci.
Vyčerpaná ID a jiné případy, kdy zprasená aplikace nakonec vyčerpá i ty nesmyslně vysoké limity, už jsou problém lidí, co se o to mají starat.
Akorát teda nechápu, proč to řešíte? Jestli dobře počítám, tak milion na kontejner ( == VPS? ) po 32b hodnotu dává 4000 kontejnerů (tj. víc, než lze fyzicky spustit na jednom hostiteli) a pokud si v tom někdo rozhodne pustit takovou věc, která to vyčerpá, tak se maximálně zahltí sám?
On 7/13/20 10:39 PM, Pavel Snajdr wrote:
Ahoj,
no... podman je preci Lepsi Nahrada za Docker (tm), ne?
Proto dava smysl, ze:
- defaultne nepouziva user namespace
- a hlavne, obzlast relevantne tu -
- nastavuje setrlimit-em maximalni pocet procesu v kontejneru na
"unlimited".
Njn, fakt lepsi varianta.
Problem je v tom, ze my tam mame nastaveny limit na neco pres milion per jeden kontejner, neco jako unlimited pro kontejner, v kterem muze bezet "untrusted" kod... process idcka jsou jen 32bitova, to se da predstavit s dost RAM vybombit.
Takze veskrze fakt vylepseni...
Uz oproti dost sracce. Ale Red Hatu se vzdycky povede sracka jeste vetsi
- i kdyz tvrdi, ze je to vylepsena krupavejsi chutnejsi alternativa...
Ted je otazka, co s tim.
Jako nejlepsi reseni se mi jevi proste milemu zlatemu podmanu a containerd kecat, ze se mu to povedlo nastavit a pritom to tise nechat na puvodnim limitu.
Co si o tom myslite?
/snajpa
On 2020-07-12 21:20, Petr Kutalek wrote:
Ahoj,
tuším, že Pavel Šnajdr na poslední schůzi v Praze říkal (volně převyprávěno), že je rád, když se lidi ozvou, protože to pak připomíná více komunitu, nikoli jen podporu á la firma. Tak já tedy jeden dotaz mám – týká se to Dockeru, resp. Podmana. :)
- Připravil jsem si lokálně na svém _lab_ desktopu image pro kontejnery a pody, které chci nasadit na VPSce. Vše OK, žádné extra vylomeniny. - Pročetl jsem https://kb.vpsfree.cz/navody/vps/vpsadminos/docker - Podíval jsem se na https://kb.vpsfree.cz/navody/vps/vpsadminos - Používám Arch, Podman v rootless režimu (z mnoha důvodů). - Povolil jsem ve features podporu FUSE (pro overlayfs) a TUN/TAP. - Nevím, co přesně dělá "Docker" feature, ale reálně nic nemění, výsledek je stejný.
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Resp. proč/v čem je nastavení Dockeru v našem virtualizačním řešení nějak specifické?
Díky, Petr _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
On 2020-07-14 10:39:44 +0200, Jirka Bourek wrote:
Akorát teda nechápu, proč to řešíte? Jestli dobře počítám, tak milion na kontejner ( == VPS? ) po 32b hodnotu dává 4000 kontejnerů (tj. víc, než lze fyzicky spustit na jednom hostiteli) a pokud si v tom někdo rozhodne pustit takovou věc, která to vyčerpá, tak se maximálně zahltí sám?
jestli jsem to spravne pochopil, tak se to resi proto, ze podman nenabehne pokud se mu nepovede nastavit na unlimited.
Takze i kdyz by mu milion stacil, tak on stejne trva na unlimited.
W.
No jestli je to takhle, tak v tichosti nastavit limit z nadřazeného kontejneru a tvářit se, že je to unlimited, je docela dobrý nápad (a pokud někoho nenapadne důvod, proč by to nemělo být výchozí chování, tak by to možná šlo procpat i do upstream kernelu.)
On 7/14/20 12:28 PM, Wolf wrote:
Ahoj,
On 2020-07-14 10:39:44 +0200, Jirka Bourek wrote:
Akorát teda nechápu, proč to řešíte? Jestli dobře počítám, tak milion na kontejner ( == VPS? ) po 32b hodnotu dává 4000 kontejnerů (tj. víc, než lze fyzicky spustit na jednom hostiteli) a pokud si v tom někdo rozhodne pustit takovou věc, která to vyčerpá, tak se maximálně zahltí sám?
jestli jsem to spravne pochopil, tak se to resi proto, ze podman nenabehne pokud se mu nepovede nastavit na unlimited.
Takze i kdyz by mu milion stacil, tak on stejne trva na unlimited.
W.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
LXC také dělá toto nastavení toho limitu stejným způsobem?
út 14. 7. 2020 v 12:44 odesílatel Jirka Bourek vpsfree-list@keroub.cz napsal:
No jestli je to takhle, tak v tichosti nastavit limit z nadřazeného kontejneru a tvářit se, že je to unlimited, je docela dobrý nápad (a pokud někoho nenapadne důvod, proč by to nemělo být výchozí chování, tak by to možná šlo procpat i do upstream kernelu.)
On 7/14/20 12:28 PM, Wolf wrote:
Ahoj,
On 2020-07-14 10:39:44 +0200, Jirka Bourek wrote:
Akorát teda nechápu, proč to řešíte? Jestli dobře počítám, tak milion na kontejner ( == VPS? ) po 32b hodnotu dává 4000 kontejnerů (tj. víc, než
lze
fyzicky spustit na jednom hostiteli) a pokud si v tom někdo rozhodne
pustit
takovou věc, která to vyčerpá, tak se maximálně zahltí sám?
jestli jsem to spravne pochopil, tak se to resi proto, ze podman nenabehne pokud se mu nepovede nastavit na unlimited.
Takze i kdyz by mu milion stacil, tak on stejne trva na unlimited.
W.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
"pokud někoho nenapadne důvod, proč by to nemělo být výchozí chování, tak by to možná šlo procpat i do upstream kernelu."
Ja nevim, treba protoze.....je to realne kec a chyba? Pokud aplikace trva na unlimited tak:
- k tomu ma opravneny duvod a muze se to pokonit, kdyz realita bude jina
- je zprasena
Ani jeden pripad neni nejmensi duvod, proc by kernel nebo kontejner mel kecat o zdrojich.
OF
Ja nevim, treba protoze.....je to realne kec a chyba? Pokud aplikace trva na unlimited tak:
Jsi schopny vymyslet duvod, pro ktery by kontejnerova technologie, urcena k pousteni 3rd party kodu, mela mit ospravedlneni pro nastaveni unlimited poctu procesu pro ten 3rd party kod, *obzvlast* pokud admin systemu nastavil nizsi, nez unlimited?
/snajpa
Tim spis by se do kontejneru nemelo propagovat unlimited, ale limit nastaveny adminem.
OF
Hlavně mi přijde, že to je buď nesmysl, nebo tvůrce nastavením "unlimited" myslel "hodně hodně moc". Ani Google a Amazon dohromady nemůžou poskytnout prostředky pro skutečně nelimitovaný počet procesů, pokud jejich hlavním akcionářem není Bůh. Minimálně je něčím omezený PID, ne? Takže stejně nakonec unlimited <= HROZNEVELKECISLO. Asi to tedy reálně je nějakých 2^63 nebo jak je velký PID, ale proč by to nemohlo být třeba zrovna milion?
Štěpán.
Dne 14. 07. 20 v 18:33 Pavel Snajdr napsal(a):
Ja nevim, treba protoze.....je to realne kec a chyba? Pokud aplikace trva na unlimited tak:
Jsi schopny vymyslet duvod, pro ktery by kontejnerova technologie, urcena k pousteni 3rd party kodu, mela mit ospravedlneni pro nastaveni unlimited poctu procesu pro ten 3rd party kod, *obzvlast* pokud admin systemu nastavil nizsi, nez unlimited?
/snajpa
Mea culpa, nic se nesnazi nic nastavit na unlimited.
Jen defaultni limit na vpsAdminOS bez vpsAdmin stacku je prilis nizky, takze mne se nedarilo pustit ten podman v kontejneru ani pod rootem...
*facepalm*
/snajpa
On 2020-07-14 18:33, Pavel Snajdr wrote:
Ja nevim, treba protoze.....je to realne kec a chyba? Pokud aplikace trva na unlimited tak:
Jsi schopny vymyslet duvod, pro ktery by kontejnerova technologie, urcena k pousteni 3rd party kodu, mela mit ospravedlneni pro nastaveni unlimited poctu procesu pro ten 3rd party kod, *obzvlast* pokud admin systemu nastavil nizsi, nez unlimited?
/snajpa _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On 2020-07-12 21:20:55 +0200, Petr Kutalek wrote:
Když se ale snažím spustit byť jen demo `podman run --rm hello-world`, nedaří se mi:
Error: container_linux.go:367: starting container process caused: process_linux.go:459: container init caused: process_linux.go:382: setting rlimits for ready process caused: error setting rlimit type 7: invalid argument: OCI runtime error
Narazil jste někdo při zprovoznění Dockeru na něco podobného? Můžete mne nasměrovat k cíli?
Je tohle porad problem? Delal jsi nejakou specialni konfiguraci? Ja jsem si ted na playground nainstaloval uplne cisty stroj, archlinux. Zapnul jsem FUSE a TUN/TAP ve features a pak jsem pustil:
+ $ ssh root@185.8.164.43 'set -x +> pacman -Syyu --noconfirm podman >/dev/null +> useradd -m test +> echo test:100000:65535 >/etc/subuid +> echo test:100000:65535 >/etc/subgid +> su - test -c "podman run --rm hello-world" +> ' The authenticity of host '185.8.164.43 (185.8.164.43)' can't be established. ECDSA key fingerprint is SHA256:nYRbmUGn4lh3ZV8VxH/a4QzYI2uQdWdLGX1cahu58Y0. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '185.8.164.43' (ECDSA) to the list of known hosts. + pacman -Syyu --noconfirm podman + useradd -m test + echo test:100000:65535 + echo test:100000:65535 + su - test -c 'podman run --rm hello-world' Trying to pull docker.io/library/hello-world... Getting image source signatures Copying blob sha256:0e03bdcc26d7a9a57ef3b6f1bf1a210cff6239bff7c8cac72435984032851689 Copying config sha256:bf756fb1ae65adf866bd8c456593cd24beb6a0a061dedf42b26a993176745f6b Writing manifest to image destination Storing signatures
Hello from Docker! This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps: 1. The Docker client contacted the Docker daemon. 2. The Docker daemon pulled the "hello-world" image from the Docker Hub. (amd64) 3. The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading. 4. The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
To try something more ambitious, you can run an Ubuntu container with: $ docker run -it ubuntu bash
Share images, automate workflows, and more with a free Docker ID: https://hub.docker.com/
For more examples and ideas, visit: https://docs.docker.com/get-started/
Takze to funguje. Prisel jsi na to, jak presne zreprodukovat ten tvuj problem?
W.
community-list@lists.vpsfree.cz
-
Jakub Skokan -
Jirka Bourek -
Josef Skladanka -
Ondrej.Flidr -
Pavel Snajdr -
Petr Balazi -
Petr Kutalek -
Stepan Liska -
Wolf -
zd nex