Portál AbcLinuxu, 26. dubna 2024 01:19
18.9.2019 10:40
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Compose se rovnou vyhnuZ jakeho duvodu?
jo podman by me taky zajimal : )
. Kdyz posles ten one-liner, muzu ho v pristim dile pouzit jako example :-p.
Chci to resit tak, ze vezmu virtulni stroj (hyperV) na kterem budou 2 hostovane systemy - aplikace pod centos6 a database pod centos5. Asi pres unix-sockety (to musim napsat) se budu z aplikace dotazovat te databaze.IMHO idealni pro kontejnery (ja to tak pouzivam) * DB s cent5 zavri do samotneho kontejneru (idealne bez sitovky a nasdilej ven jen adresar s DB ux socketem) * APP do samotneho kontejneru s nasdilenym adresarem s DB ux socketem (nepises, jestli APP bezi pouze na cent6, v dalsim/jinem kontejneru muzes zkusit zmigrovat na cent7 ;) pokud nejaky program nepodporuje ux sockety, muzes pouzit nastroj socat, e.g.:
socat UNIX-LISTEN:/cesta/k/db-socketu.sock,reuseaddr,fork TCP:127.0.0.1:$DB_PORT socat TCP-LISTEN:$DB_PORT,reuseaddr,fork UNIX-CLIENT:/cesta/k/db-socketu.sock
19.9.2019 09:56
Jendа | skóre: 78
| blog: Jenda
| JO70FB
otazka na jak dlouho to je, nevim jestli jeste vubec existuje image centos 5, nebo bude muset si cely image postavit celý znova a to je uz podstatne vice praceMohlo by stačit zkopírovat rootfs stávajícího serveru a databázi spustit.
A stejne za par let muze prijit na to, ze image uz nepujde v dockeru natahnout, vypadne podpora napr. filesystemu a pápá.FS je záležitostí jádra (pokud tedy zrovna DB nemá nějaká FS-specific quirky) a to se používá hostitelské. Jediné co mě napadá (šlo to kolem když se upgradovalo jádro v Debianu) je že bude potřeba zapnout vsyscall.
Mohlo by stačit zkopírovat rootfs stávajícího serveru a databázi spustit.Jedna z výhod Dockeru je, že ke každému obrazu máš popis, jak ten obraz vytvořit. Tedy skript, který tam vše nainstaluje. Pokud zkopíruješ existující server, tak zkopíruješ i hromadu bordelu, který může později překážet a dělat potíže. Na druhou stranu, pokud je cílem jen udržovat zastaralou službu tak, jak teď je, a pokud ten server není moc zabordelený, tak je to docela rozumná a relativně bezpracná volba. Nicméně postavit si image pro kontejner je o jednom příkazu a nainstalování pár věcí. Tedy pokud použiješ něco integrovaného se systémem (systemd-nspawn nebo lxc). Docker je trochu těžší na přemluvení, aby v něm fungoval systemd a nějak slušně to interagovalo s okolím.
19.9.2019 11:45
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Jedna z výhod DockeruNo to by mě právě nejvíc zajímalo, v čem je docker tak super výhodný. Protože technologicky tam není nic, co by neuměly jaily, lxc, nspawn (openvz neznám, ale asi taky). Pokud přeskočím hype (který mě docela štve), tak docker nabízí hotové image "na všechno", takže "admin" nemusí umět nic nainstalovat a na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů. A setkal jsem se s argumentací, že mít i nativní programy, které jsou jinak běžně dostupné v repositáři distribuce, v dockeru, je výhodnější, protože si v dockerfile lze zvolit, kam se má který datový adresář namountouvat. Když jsem opáčil, že to je v linuxu už asi 28 let, tak jsem se dozvěděl, že to není ono. Tak nevím. Připadá mi to celé takové zvláštní. Máme tady technologie, které umožňují dělat totéž a lidi si raději instalují docker místo toho, aby v konfigu služby změnili umístění datového adresáře nebo si jej namountovali tam kam potřebují. Navíc vidím zásadní problém z hlediska bezpečnosti. Lidé si zvykli stahovat image a neznají jejich původ. Navíc to často ani neupdatují. Čest výjimkám, jsou lidé, kteří si image dělají sami včetně automatických update.
takže "admin" nemusí umět nicCela pointa DevOps je ze neni zadny admin.
na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů.To nekdo v produkcnim bezpecnem prostredi dela tak maximalne na vyzkouseni nejake nove aplikace, v produkci mas samozrejme image primo od vyrobce te dane aplikace, nebo si tvoris image vlastni.
Lidé si zvykli stahovat image a neznají jejich původ.Lidi si na sve pracovni stanice a sebou managovane servery instaluji bezpecnosti hrozby uz davno, byt treba jinak; organizace na to maji bezpecnostni politiky, IT governance procesy a interni a externi auditory.
19.9.2019 12:18
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
19.9.2019 20:23
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
OpenShift jako orchestrace k němu má tendence vyrábět spoustu problémů, které bez něj vůbec neexistovalyAle podle toho co jsem slysel, pokud se vam to podari uspesne nasadit budete prvni uspesna implementace OpenShiftu v CR :).
19.9.2019 20:46
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
jen se adminování přehazuje na programátoryCož považuju za problém, protože admini a programátoři jsou zcela odlišný druh zvířete (neříkám lepší / horší). Nejlepší je, pokud tyto dva spolu spolupracují a kromě potřeb vývoje se taky hledí na potřeby to potom udržovat v chodu. (I když chápu, že v době, kdy je technologie, která před půl rokem ještě ani neexistovala, považována za zastaralou, je toto hledisko pro některé lidi asi méně důležité.)
19.9.2019 16:02
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Docker postail svůj ekosystém na tom, že je předpis, který říká jak ten kontejner vyrobit, a kdykoliv můžu vše zahodit a vrátit se na začátek. Pokaždé na ten stejný začátek. Vlastně ani tak nejde o ten kontejner, jako spíš o to, že se spustí ten předpis a dřívější kontejner je jen někde nakešovaný. To je podle mne ten hlavní důvod, proč je Docker tak úspěšný. Ostatní kontejnerovací technologie toto postrádají a většinou to vůbec neřeší.To můžu mít pomocí jiných technologií taky. Ansible playbook + výchozí template kontejner s minimální instalací OS. Z template udělám "image" (zfs filesystem / btrfs subvolume), pustím na to ansible a jsem na konci.
To můžu mít pomocí jiných technologií taky.Ano, i auto si muzes postavit sam, otazka je jestli to bude snazsi a levnejsi nez si koupit auto uz od existujiciho vyrobce ze seriove vyroby; siti servisnich stanic vsude po svete,...
19.9.2019 18:36
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
To je trochu rozdíl, ansible můžu použít i na HW, dokonce stejný playbook, jako používám v npawnu nebo v kvm.V prostredi s nejakou formou governance tezko, virtualni stroje budes monitorovat jinak nez fyzicke servery, konteinery,...
Btw. asi se k tomu dostaneš v dalších dílech, ale jaká je best practices pro vytváření image? Bylo mi tvrzeno, že se to běžně dělá tak, že pokud někdo distribuuje nějaký software, který vyžaduje konfiguraci (změny v /etc/), tak prostě přímo hrábne do těch souborů v /etc/ a udělá z toho image.Takovy je best-practice... Ty nahrazovane konfiguraky mas soucasti toho git repozitare ze ktereho buildis ten image a delas replacement; pokud potrebujes aby se konfigurak menil na zaklade nejakych ENV promennych pri spusteni konteineru, tak do udelas v Docker entrypoint skriptu.
19.9.2019 19:11
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
No tak pokud je to v gitu a ten repos je dodávaný s tím image, tak možná.Muze byt, nemusi, kdyz mas OSS appku tak v tom neni problem, ale kdyz takhle distribuujes treba SAP tak ten Git bude uvnitr SAPu (jako organizace) a SAP bude distribuovat jenom binarni image s nejakymi nadefinovanymi parametry, ale to se nijak nelisi od dostribuce binarniho instalatoru SAPu, Oracle DB,...
Ale co jsem pochopil, tak voni prostě změní konf přímo v image a nazdar.Tak to delaji blbe, co ti k tomu mam rict? Je to nastroj a lidi ho muzou pouzivat spatne stejne jako jine nastroje...
To už mi fakt přijde lepší (ve smyslu je k tomu víc dokumentace), někomu říct: hele, minimální debian, nainstaluj ansible s pušť tam tohle (playbook). Minimální debian zná a co mu s tím provede ten playbook si v něm může po nocích přečíst.Ten playbook se ale da spustit i v tom Docker konteineru, ze... Deploynout novy konteiner a pripojit ho k load-balanceru je rychlejsi nez bootstrapnout novou VM, a spustit v nem ten playbook, takze dokazes rychleji horizontalne skalovat aplikaci v ramci spicek dane aplikace.
19.9.2019 19:28
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Tak to delaji blbe, co ti k tomu mam rict?Nic, právě proto jsem se na to ptal. To že to dělají blbě mě napadlo taky a to byl důvod mé otázky.
Ten playbook se ale da spustit i v tom Docker konteineru, ze...Ano.
Deploynout novy konteiner a pripojit ho k load-balanceru je rychlejsi nez bootstrapnout novou VMSe nemusí bootstapovat od nuly. Udělat btrfs / zfs clone stávajícího hotového template a spustit (nwpawn / jail) je otázkou sekund. (Do dvou sekund mám nový testovací jail pro testování webových appek a takových připravených templatů tu mám víc pro různé účely.) (Stejně ten docker používá btrfs resp nějaký systém layerů, takže toto je stejné.) (Ano já vím, nemám k tomu hotovou tu infra okolo a nemám si sám navrhovat auto, vím, nepiš to
).
19.9.2019 20:38
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Zběžně jsem prolítl vlákno a jedné věci nerozumim: Ptáš se k čemu je Docker a pak popisuješ, jak děláš +- to samé co Docker pomocí jiného softwaru. Neodpověděl sis tím pádem sám?No ptám, protože před dockerem jsme tady měli jaily, lxc, nspawn, openvz a další, tak mě zajímá, proč někdo místo tohoto používá právě docker (včetně "vtipné" historie OverlayFS). A když jsem se o tom bavil s několika lidmi, tak mi říkali různé featury dockeru a já jsem jenom reagoval "no jasně, to můžeš udělat i mimo docker a je to tam už 20 let". Takže oni byli nadšení, vyhypovaní a ani nevěděli, že to tady bylo už dávno. Další věc, která mi nebyla jasná, byla právě konfigurace image. Fakt se mi nechtělo věřit, že by někdo ručně natvrdo měnil soubory a čekal jsem nějakou sofistikovanou věc (lepší než ansible) zabudovanou přímo do dockeru, která to ulehčí. Ale odpověď: "prostě se to změní ručně" mě teda uzemnila. Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko. Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs. A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.
Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.Velke bezpecnostni riziko treba v automatizovanem vulnarability scanningu a alertingu pro kazdou image, ktera vypadne z CI/CD pipeline? Aha...
Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs.Lisi se to v tom, ze kolem toho existuje cely ekosistem podpurnych nastroju, ktere mezi sebou spolupracuji a jsou integrovany, treba NetApp Kubernetes Service.
A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.V serialu je jasne napsano, ze Docker skrze runc a containerd stavi abstrakcni vrstvu nad jiz existujicimi vlastnosmi jadra, stejne jako uvadi kdy ty featury byly do toho jadra zavedene, pokud si chces stavet vlastni letadlo, ja ti v tom branit nebudu, ale pokud bych ja zakladal aerolinku tak si je koupim od Boeingu, nebo Airbusu.
Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.Možná přívětivější tooling? Ačkoliv, co jsem posledně používal docker, tak to zas tak přívětivé nebylo a třeba error reporting byl dost špatnej.
Ano, lze to dělat i dobře, lze si stavět vlastní image a updatovat je, to nepopírám. Ale to se nijak neliší od provozování nspawnů / jailů nad btrfs / zfs.Hm, já třeba zrovna s btrfs moc kámoš nejsem (nepovažuju ho za dostatečně stabilní pro produkční nasazení) a zfs je na linuxu pořád trochu cizí (ale nevim, jakej je nejnovější stav). Jde to i bez nich?
19.9.2019 21:16
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Hm, já třeba zrovna s btrfs moc kámoš nejsem (nepovažuju ho za dostatečně stabilní pro produkční nasazení) a zfs je na linuxu pořád trochu cizí (ale nevim, jakej je nejnovější stav). Jde to i bez nich?ZFS používám jen na FreeBSD (z licenčních důvodů). Ano, jde to i bez nich, kontejnery nevyžadují mít COW FS ani nic podobného. Jen místo clone budeš muset dělat skutečnou kopii celého root adresáře, nebudeš moci dělat snapshoty (nebo opět jen kompletní kopií nebo využít zálohovací technologie, které vykopírují jen změněné soubory) a tak podobně. Ale na funkci to nemá vliv.
Další věc, která mi nebyla jasná, byla právě konfigurace image. Fakt se mi nechtělo věřit, že by někdo ručně natvrdo měnil soubory a čekal jsem nějakou sofistikovanou věc (lepší než ansible) zabudovanou přímo do dockeru, která to ulehčí. Ale odpověď: "prostě se to změní ručně" mě teda uzemnila.Pointa je v tom, že ty nedistribuuješ image, ale popis (skript) k jeho výrobě – Dockerfile. V tom souboru je popsáno, které soubory a jak se mají upravit či přepsat. Vlastní existence nějakého obrazu čehosi je už nepodstatný implementační detail, aby se na každé spuštění kontejneru nečekalo týden. Tedy žádné ruční úpravy image, který by se pak někam nahrával, se nedělají. Upravíš skript, který ty úpravy provede a ten šíříš. Pokud chceš někomu ušetřit čas na sestavení image, tak můžeš uploadnout do Docker repozitáře i ten nakešovaný image.
Tedy žádné ruční úpravy image, který by se pak někam nahrával, se nedělajíTo je takova polovicni pravda, na Docker Hub jde uploadovat i uz hotove sestavene Docker images bez Dockerfile receptu... a taky to tak nekteri delaji, ale takove image nenasazuju ani na otestovani appky pokud nepochazi od duveryhondeho vendora.
20.9.2019 10:21
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Takže moje zjištění "proč docker" jsou: hype a hotové image pro neadminy. V čemž vidím velké bezpečností riziko.Imho spíš funkční orchestrace. Docker registry a Dockerfile jsou dvě věci, které imho nic jiného nenabízelo. Jeden čas jsem taky používal lxc, ale to fungovalo stylem "urob si sám". Osobně třeba ansible nepovažuji za nějak štastnější řešení. Čímž nechci obhajovat Docker, tam mi spousta věcí taky přijde dost ujetá.
18.9.2019 15:16
19.9.2019 10:42
20.9.2019 10:55
apt install docker-ce, docker build.. a docker run..). Lxc a podobne musis este riesit ten extra tooling okolo. (napriklad spominany Ansible) Ak by si povedal, ze to zas tak vela prace navyse nie je, tak asi suhlasim, ale rozdiel tam je.
b) Microservices. Docker bol proste v spravny cas na spravnom mieste. Prave ked zacal nastupovat tento trend, Docker bol relativne popularny a hodil sa na microservices. V podstate sa zviezol na celom trende. Keby vtedy Canonical zapracoval a potlacil LXD, alebo niekto iny nejaku inu kontajnerovu technologiu, verim tomu ze by dnes situacia vyzerala inak.
Samozrejme ked sa rozhodujes dnes, tak hype a podobne nie je na mieste. (a nebol ani vtedy, ale tak sa nastavuju trendy - niekedy bohuzial) Dnes je to o tom, ze je okolo Dockeru kopec nastrojov ktore si pri inych kontajneroch musis casto implementovat sam. Konkretne ked sa bavime o infrastrukture, tak napriklad Kubernetes. Dnes uz proste nie je otazka, ci budes pouzivat Docker, pretoze musis lebo pouzivas Kubernetes ako sluzbu a alternativa by bola implementovat si nieco vlastne a platit ludi ktori by to prevadzkovali co dlho trva a stoji peniaze.
Aby sme sa rozumeli, nemyslim, ze Docker je nejaka uzasna technologia. Aj co sa tyka implementacie lightweight kontajnerov, tak tu su lepsie alternativy (rkt, podman, nspawn,..) oproti ktorym ma Docker casto zasadne nevyhody. Ale ked mas obmedzeny cas, pocet ludi a financie, tak proste pouzijes to co ma okolo seba vyvinuty ekosystem nastrojov a co vies aspon ciastocne pouzit ako outsourced sluzbu. A to je myslim, momentalne ta najzasadnejsia vyhoda Dockeru.
A od seriálu očekávám (přál bych si), že se dostane k technologiím, které si doma na koleně neudělám a bude tam jasná přidaná hodnota dockeru.Je mozne, ze pre teba konkretne nema Docker nejaky zasadny prinos. Myslim, ze ze keby tam bola nejaka pridana hodnota, tak uz by si ho pouzival, vyzeras ako clovek co siahne po najlepsom nastroji na danu pracu. Nie vsetci ale maju luxus nieco riesit "doma na kolene" ci uz z nedostatku casu, alebo aj vedomosti, lebo to nie je ich core business.
Pokud přeskočím hype (který mě docela štve), tak docker nabízí hotové image "na všechno", takže "admin" nemusí umět nic nainstalovat a na pár řádků v dockerfile mu to odněkud (takže bezpečnostní riziko) postahuje někým vytvořené image programů.Tady nutno podotknout, že Docker Hub v tomhle ohledu nemá právě dobrou pověst...
systemctl --machine) a kontejner máš jen jako další službu. Do kontejneru stačí hodit dostatečně nový systemd (touto dobou už až tak nový není) a dbus, aby to mělo jak komunikovat, jinak netřeba nic navíc.
20.9.2019 00:27
Jendа | skóre: 78
| blog: Jenda
| JO70FB
jinak oneliner v Perlu nepiseme ale kopirujeme z toho, co nam nalezl google. Mam to vyzkousene, je to prumerne asi o 30 vterin rychlejsi.
Tak to počkej počkej, pomalu ty vědátore, co je to google? To má být jako nějaká novější verze altavisty nebo co? Tady jsem vlastní rukou napsal generátor hlášek při odchodu z rachoty:
perl -e "my @x = ('jdu domu', 'koncim', 'balim to', 'nakaslat', 'bych se na to', 'co ja tu vlastne jeste delam'); print @x[rand @x], \"\n\""
Taky jsem zjistil, že z internetů zmizel yarpenův generátor nadávek, který by drobným rozšířením výše uvedeného mohl začít zase existovat, ale obsahuje moc sprostých slov pro školní příklad dockeru.
Abych nebyl za úplnou konzervu, tak docker chápu a dokonce i používám, ale začíná mi být smutno po době, kdy si člověk prostě otevřel textový editor a v něm napsal pár řádků a zkompiloval to nebo to spustil. (A když se mu to líbilo, mohl si to uložit na kazetu...)
Po pravdě nemáme zatím žádného zákazníka, který by produkční systémy měl v Dockeru. Prakticky všechny servery jsou virtuály, ale jsou to stále "kompletní" systémy.
Pro mě je Docker především pískoviště, které mohu používat když nejsou cílové systémy k dispozici. Mám jeden obecný "základ" ve kterém je toho na poměry Dockeru až nezdravě mnoho a z něj různé forky podle zákazníků nebo (verzí) aplikací.
Původně jsem to měl jen pro sebe, ale postupně a velmi zvolna se to šíří i mezi kolegy. V našem případě totiž mít zdrojové je kódy kolikrát k ničemu, když nemáte i devel prostředí proti kterému vyvíjet. A je mnohem lepší mít ho v dockeru, než na korporátním virtuálu, na který se nedostanete, když nemáte spojení na Internet.
Nepotřebuji Kubernetes ani Swarm. Bylo by pěkné mít CI, ale na to bohužel není čas a síla. Mám to *pro sebe*, abych si ušetřil práci. Málokdy na něčem dělám s někým jiným paralelně, ale je to dobré když někomu předáváte práci. Brzy dostanu nový notebook. Snad to stěhování bude i díky Dockeru o něco menší opruz.
---
Dřív jsem používal VMware a fungovalo to stejně. Jen image byly *podstatně* větší a měly tendenci se "zanášet bordelem". Docker je prostě jen o něco "elegantnější".
---
A jako vývojář pro adminy:
* Netoužím po tom, aby se moje "prasácké" image dostaly kamkoliv blízko produkce či testovky
* Chraň Bůh, abych se musel starat o nějaký server
https://www.root.cz/zpravicky/naucte-se-pracovat-s-dockerem-a-kontejnery-skoleni/12000 vs zdarma, stale je motivace? Psat zadara pro bussiness usery to chce odvahu
Psat zadara pro bussiness usery to chce odvahuNebo to proste cloveka bavi :).
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
10.1.2021 20:55