Hirdetés
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- Házimozi belépő szinten
- Nem teljesít túl jól a kasszáknál az aktuális Xbox generáció
- Milyen Android TV boxot vegyek?
- TCL LCD és LED TV-k
- Melyik hordozható audiolejátszót (DAP, MP3, stb.) vegyem?
- Gyorsít az egyes Zen 5 dizájnokon a legfrissebb AMD AGESA
- Milyen billentyűzetet vegyek?
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
Hirdetés
-
Asus Rog Ally(RC71L)
lo Szép Napot Mindenkinek Szemezgettem ezzel a RoG Ally(ejtsd: Rodzs Eláj)-al, hogy kéne valami, ami hordozhatóbb mint egy...
-
Barcelonából indul nemzetközi útra a Huawei MatePad 12.2 (2024)
ma Illetve a MatePad Air 2024, amit errefelé MatePad 12 X-nek hívnak.
-
Konkrét terv van az Altera jövőjéről
ph Nincs szó egyelőre az Intelről leválasztott részleg teljes eladásáról, de a jelenlegi felállás sem marad.
Új hozzászólás Aktív témák
-
BullZeye
veterán
-
Sziasztok!
Végre megszültem ezt a compose fájlt, de az alábbi hibát kapom a docker-compose -f media-compose.yml up parancsra:
ERROR: In file './media-compose.yml', volume 'tmp' must be a mapping not a string.
Ha kitörlöm ezt a sort és bedrótozom a plex konténerbe, akkor a ser meghajtójával van baja.Mit rontok el?
[ Szerkesztve ]
-
haddent
addikt
Szia
ahogy írja is, a volume mappinget. [link] így érdemes szerintem (csak a tmp -t írtam át, annak mintájára a többit is kéne), tehát egyből a konténer volumes részénél:- /helye/a/hoszt/gépen:/helye/a/konténerben
Van több féle mapping és szintakszis is, ez az én preferáltam de compose doksiban nyugodtan válassz másikat, ha jobban bejön[ Szerkesztve ]
-
Tudom, hogy én vagyok a csekély értelmű medvebocs, de én ebben nem látom, hogy hogy tudnám megoldani, hogy a yml fájlban tüntetem fel szépen a végén az egyes meghajtók szerveren elfoglalt helyét. Csak a haddent által javasol opcióra látok megoldást, vagy hogy megadok egy meghajtó nevet, amit vagy én hozok létre korábban, vagy a Docker létrehozza nekem random(?) helyre.
Van ebben valakinek tapasztalata?
Mivel több helyen is használom ugyanazt a volume-ot, így nem szeretném mindenhova felvinni a szerveren lévő mappa struktúrát, megkönnyítve ezzel a szerkeszthetőséget. -
#106
huliganboy
őstag
huliganboy
őstag
Sziasztok!
Új vagyok ezen a területen. X86 gépen futtatott ubuntu server 16.04 LTS rendszeren futtatok dockert..... de még kicsit ködös a felépítés és működése.... Próbálok benne működésre bírni egy programot, de nem megy. Az alábbi hibánál állok.... miközben azt olvasom, hogy az x386 is támogatott:
docker: no matching manifest for linux/386 in the manifest list entries.
Tudtok egy kis iránymutatást adni?
Köszi
[ Szerkesztve ]
-
#107
golya87
őstag
huliganboy
#106
válasz
huliganboy
#106
üzenetére
Így első ránézésre azt mondanám, hogy nem 64bites Ubuntut használsz. x64-re van image, x86-ra nincs.
-
#109
golya87
őstag
huliganboy
#108
válasz
huliganboy
#108
üzenetére
Igen, Docker van x86-ra, viszont az általad használni kívánt image-ből nincs x86-os build, csak x64. Ha a HW nem indokolja, akkor érdemes áttérni x64-es Ubuntura.
-
haddent
addikt
Így van, illetve jó eséllyel azért a Dockerfile ("makefile") elérhető a konténerhez, akkor tudsz magad "fordítani" egy x86 -ot is sajátkezűleg
golya87 találtam megoldást a "globális bindmountra", de elég rusnya, a doksiban nincs benne, egy 2 éves github request eldugott kommentjei közül
működik, de jóétvágyat hozzá. Én általában fejből meg tudom írni a composeokat amik kellenek nekem, elég intuitív, hát ezt biztos nem jegyzem meg [link] -
Hát ez tényleg csúnyácska...
Találkoztam én is egy ilyesmivel, de este már nem sikerült felfognom. Túl bonyolultnak tűnt, de úgy látszik ez a megoldás.
Marad az általad javasolt megoldás. Tegnap egyből indult is, látják egymást a konténerek név alapján.
Köszönöm a segítséget!
-
haddent
addikt
Egy kis érdekesség, hátha jól jön valakinek. Tegnap dobtam össze egy "titkosított" saját proxyt. Egy openvpn -ből áll amin "wan interfésznek" használok a proxy számára:
https://cloud.rowra.org/s/proxeyeLeírás a compose-ban, de kell neki 1db config.ovpn a config mappába és be kell illeszteni 2 sort a confiba, ha nincs benne / ha ki van kommentezve + az auth.txt
Aztán egy docker-compose build és mehet is az up, 1234 -es porton proxy megy a megfelelő vpn -nelElég minimál, sok helyen lehetne szebb, de működik és 10 perc alatt kellett, lehetőleg tegnapra
[ Szerkesztve ]
-
samujózsi
senior tag
Nézegetem a docker hálózatkezeléssel kapcsolatos dolgait és egy dolog máris nem tiszta: ha kérem tőle, hogy publikálja a konténer által használt portokat, akkor ezeket ő berakja a netfilter (iptables) szabályok közé úgy, hogy minden, a hostnak a megadott portjára érkező csomag menjen tovább a konténerbe. Az csak nekem furcsa, hogy nem lehet paraméterezni, hogy milyen IP-kről fogadjon csomagokat ezeken a portokon?
A közös kernel miatt a konténerben nem tudok új szabályokat beállítani.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#114
instantwater
addikt
samujózsi
#113
-
#115
samujózsi
senior tag
instantwater
#114
samujózsi
senior tag
válasz
instantwater
#114
üzenetére
Előbbi. Utóbbi egyértelmű, nem nincs is köze a netfilterhez.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#117
samujózsi
senior tag
instantwater
#116
samujózsi
senior tag
válasz
instantwater
#116
üzenetére
Miután a docker belepiszkál a netfilter szabályokba, ha publikálom a portjait, szerintem valahol hozzá tartozik.
Az alapfelállás, hogy minden tiltva van.
Amikor indítoknegy konténert, ami tcp/udp szolgáltatást nyújt és a létrehozásakor a -p vagy a -P kapcsolót használom, akkor mindenkinek megnyitja azokat a portokat, amiket publikál, nem tudom szabályozni, hogy mely IP-kről legyen elérhető.
Ha nem használom ezeket a kapcsolókat, akkor viszont elég macerás összekötni a netfilter szabályokat a.konténer indításával/leállításával.Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#117
üzenetére
Ezt nagyon jól látod, ezért komolyabb felhasználás esetén mindenképp érdemes letiltani, hogy a Docker nyulkáljon az iptables -hez és manuálisan állítani, én is így csinálom. Nyilván kényelmetlenebb, de tudod mi történik. Alapból olyan chaineke meg szabályokat összerottyant neked, hogy csak nézel, hogy most ezt azért, mert megpublikáltál egy 80-as portot
-
samujózsi
senior tag
Ha jár még erre valami kóbor lélek: ugye az az általános mondás, hogy egy konténer-egy service.
De... mi van, ha egy olyan webes alkalmazást futtatnék, ami használ adatbázist is?
Egy nginx, egy mysql konténer és valahogy megoldom köztük a kommunikációt?
Vagy ilyenkor mind mehet egy konténerbe?
Ha külön, akkor hogy szokás megoldani a konténerek közti kapcsolatot? Úgy vettem észre, az ip cím random, így elég nehéz akár név, akár ip cím alapján összekapcsolni őket, nem?Más: a konténerekben futó szoftver update-elését hogy szokás megoldani? Egyesével belépek és futtatok egy a konténer op.rendszerének megfelelő update-et? Vagy hogy?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#121
instantwater
addikt
samujózsi
#120
instantwater
addikt
válasz
samujózsi
#120
üzenetére
Egy szervice egy konténer. Csak nagyon különleges esetekben ajánlott eltérni tőle.
Egyik konténer az adatbázis, másik az appod.
Konténernév alapján tudnak kommunikálni, a nevet pedig feloldja a Docker daemon DNS szervere konténer IPre, így létrejöhet a kapcsolat a konténereid között.Érdemes Docker Composet használni, az megoldja a könnyű service név alapú kommunikációt, egyszerre elindítja az összes szükséges komponenst, appot, adatbázist, bármi mást amire még szükséged van.
Az adatbázis adattároló mappáját erősen javasolt egy volumebe vagy mappelt/bindelt/mountolt mappába tenni, hogy újraindításkor ne vesszen el az adatbázis.
Fontos megérteni, hogy a konténer NEM virtuális gép.
Nem telepítünk bele SSH szervert (kivéve, ha SSH szerver konténert akarsz, de az ritka), nem updatelünk semmit command lineból, mert egy restartkor ugrik minden nem mountolt path tartalma.A frissítés a Dockerfileban meghatározott komponensek frissítésével, egy új verziószámú image buildelésével, majd ennek az új imagenek a használatával történik. Általában egy gépen buildelik, feltöltik a registrybe, ami lehet Docker Hub vagy más registry, majd letöltik a szerverre ami futtatja a konténert.
Tehát komplett konténer verzió cserével frissítünk, nem mókolunk bele kézzel a futó konténerbe frissítés céljából, max esetleg debuggolás céljából.
Ez a konténerizálás egyik nagy előnye, hogy nem kell kézzel frissítgetned az egyes komponenseket, hanem új képfájlt gyártasz minden alkalommal amikor frissíted az alkalmazásod függőségeit.
-
#122
samujózsi
senior tag
instantwater
#121
samujózsi
senior tag
válasz
instantwater
#121
üzenetére
No várj, sima restartnál nem vész el semmi, csak ha újragenerálom az image-et, nem?
(docker run ... ; docker exec xxx /bin/sh ; ... itt létrehozok, módosítok ezt-azt ; docker restart xxx - megmarad amit az első exec alatt módosítottam)Ezt az update-elést továbbra sem értem: ha a felhasznált image létrehozója/kezelője nem update-eli, akkor akár a végtelenségig futhat nekem egy már ismert explitokat tartalmazó rendszer? Mert ilyen alapon mondjuk elkészítek mindent magamnak, de egy alaprendszer, például egy alpine akkor is kell. Ha ebben lyukas a libc, akkor az összes konténerem lyukas lesz, míg a hivatalos image-ben be nem foltozzák. Nem gáz ez így?
Viszont az is gondot jelenthet, hogy ha mondjuk (csak példa, de az életből ellesve
) adatbázis szerverem fut konténerben és upgrade-elni kell az adatbázist. Ugyanis ez esetenként járhat az adatbázis struktúrájának változásával, amit egy közvetlenül az op.rendszerbe telepített RDBMS upgrade procedúrája általában vagy elintéz automatikusan vagy le van írva a doksiban, hogy mikor kell futtatni ezeket az upgrade script-eket az upgrade során. De egy docker konténernél, ahol nincs igazán upgrade eljárás... 
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#123
samujózsi
senior tag
instantwater
#121
samujózsi
senior tag
válasz
instantwater
#121
üzenetére
Közben lejárt a szerkesztési idő: ha sok adatbázisom van, azokat a fentiek értelmében önálló konténerben kellene futtatni ezek szerint? (ezt kicsit erőforrás pazarlásnak tartom, legalábbis néhány esetben)
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
válasz
samujózsi
#123
üzenetére
Illetve ehhez kapcsolódva: ha olyan szolgáltatást akarok üzemeltetni, ami az adott gépen futó konténereknek szolgáltat (mondjuk egy syslog-ng service), akkor annak a portjait odaadom a localhost-nak és a többi konténerekből a 127.0.0.1 megfelelő portjára hivatkozom?
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#124
üzenetére
Nem. A konténerek belülről 127.0.0.1 -nek a sajátjukat látják. Azt hiszek "HOST" vagy hasonló hostnamen eléred a hoszt gépet, nem biztos, hogy ez, de van rá. A networking feljebb írta a kollega, compose és vagy stackben szereplő név alapján, ip -ket el kell felejteni, random, nem is kell statikus.
Updatelés nagyon egyszerű: docker-compose pull, docker-compose build, docker-compose up -d --force-recreate. Ha úgy ítéled meg, hogy nem elég friss valamelyik komponens vagy azon alkotóleme, akkor buildelsz magadnak egyet, de erősen kétlem, hogy bármiben gyorsabb tudnál lenni Egyébként konténeren belül, belelépve nem változtatunk semmit, épp azért, mert nem permanens.Konvenció szerint, 1 service 1 konténer és 1 szolgáltatás (iiiigen, ez angolul a service, de akkor tegyük mögé, hogy "csomag", pl jelen esetben tökéletes példa nginx + mariadb + stb..) 1 stack.
De, sima restartnál is elveszik mindig, minden, addig a pontig amíg meg nem mondod neki explicit, hogy mi hova legyen bekötve. Ez lehet automatikus docker volume vagy bind mount meg van még 1-2 őrültség de ez a kettő a jellemző.
-
samujózsi
senior tag
Bocs, félálomban írtam: a host saját lo interface-ére gondoltam a 127.0.0.1 kapcsán. Mert ha csak azon hallgat az adott port, akkor kívülről nem lehet elérni.
Az továbbra sem tiszta, hogy ha egymástól független alkalmazáscsomagoknak adnék közös szolgáltatást, azoknak hogyan illene ezt összerakni.
Mondjuk syslog szerver vagy pl adatbázis szerver, amiben a különböző szolgáltatások eltérő sémába dolgoznak közös szerveren.Restart: konkrétan kipróbáltam a fentieket, mielőtt leírtam:
docker run alpine
Kaptam egy promptot.cd root
touch x.x
ctrl-ddocker restart xxxx (fenti konténer)
docker exec -it xxxx /bin/sh
ls -l root
És ott az x.xLehet, hogy hibás az ubuntu 18.04 docker csomagja, de nálam így működik.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#129
samujózsi
senior tag
instantwater
#128
samujózsi
senior tag
válasz
instantwater
#128
üzenetére
Köszi, csak... nem igazán ez volt a kérdésem lényege. Inkább arra vonatkozott, hogy hogyan illik megoldani, ha egymástól független alkalmazások/konténerek rendelkeznek közös ponttal, amilyen pl egy több sémát tartalmazó adatbázis vagy mondjuk egy syslog szerver. Ilyenkor a compose nem játszik, de valahogy mégis kapcsolódniuk kellene egymáshoz.
(Utcán vagyok, ha nem felejtem el, otthon próbálok valami ábrát készíteni, hátha érthetőbb lesz)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#129
üzenetére
Ja értem már a kérdésed, tehát különböző stackek közti kapcsolatot szeretnél. Erre viszont nem tudok ennyire best practicet. Én úgy oldanám/tottam meg, hogy localhoston (hoszt gépén) listenel és így eléri, tehát a 2 stack egymást úgy látja, mintha nem is lenne docker. Természetesen tűzfalan tiltani, ellenőrizni, hogy lo -n listenel csak stb.
Előzőre: biztosan nem marad meg semmi teljes restart közt. Ha megmarad az azt jelenti, hogy valami, a konténer, a stack bármi, de valami csinált perzisztencia bindet valahova
-
samujózsi
senior tag
A best practice számomra az, hogy a közös pontot a futtató hoston a 127.0.0.1 címen publikálom és csak a portot kell megjegyezni, a host asszem, elérhető valamilyen névvel. Szóval kb amit írsz. Csak azt hittem, van valami más, "szabványos" mód is.
Még nem jutottam el oda, hogy beizzítsam a notebookon a konténereket. Próbálok majd logot készíteni a konténer létrehozásáról és a restartokról. Semmi szándékos perzisztencia nincs benne.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
samujózsi
senior tag
Hát ennél restartabb restartot már nem tudok produkálni.
Ubuntu 18.04, frissen telepítve egy virtuális gépbe, de ennek nincs jelentősége, csak annyi a lényeg, hogy semmi más nem történt, csak egyapt install docker.iodocker run -it --name alp1 alpine
Itt kapok egy root promptot a konténerben, ahol létrehozok egy addig nem létező fájlt:/ # touch root/root.txt
Ctrl-D, ezzel leáll a konténer.docker start alp1docker exec -it alp1 /bin/bashIsmét a konténerben vagyok, a /root/root.txt még mindig létezik.
docker stop alp1docker start alp1docker exec -it alp1 /bin/bashA root/root.txt megvan.
Reboot a docker hostján.docker start alp1docker exec -it alp1 /bin/bashA fájl még mindig megvan.
Akkor most mi van?
Ennél alaposabb újraindítást már nem tudok összehozni.[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#133
instantwater
addikt
samujózsi
#132
instantwater
addikt
válasz
samujózsi
#132
üzenetére
Ok, a fenti módszerrel tényleg megmarad.
Ez azért van, mert így könnyebb debuggolni, és tudod commitolni az állapotot egy imagebe, amit utána feltölthetsz a registrybe, de alapvetően nem ez a best practice mód image gyártásra, mert nem követhető, és nem reprodukálható Dockerfileból, ezáltal biztonsági szempontból aggályos, hiszen bármit telepíthetsz az imagedbe, sok munka ellenőrizni a tartalmát, mert nem tudni hogyan épül fel, és csak a layerek letöltésével lehet megszerezni az imaget, pár kilobájtos Dockerfileból nem lehet reprodukálni.
Frissítése lehetetlen az image méret növekedése nélkül, mert a Docker minden commitot új image layerként kezel, hiába uninstallálsz bármit, az foglalja a helyet egy korábbi layerben.
Csak export/import, squashing varázslással lehet a méretet csökkenteni és az új rétegek által "árnyékolt" halott adatot kidobni, ami dobja a historyt, ezzel együtt a layer cachelést, és újra és újra le kell töltened az egész imaget (operációs rendszerrel együtt ami ubuntunál többszáz mega) ahelyett, hogy csak a legutolsó (néhány) layert szednéd le frissítéskor, ez többszáz mega vagy akár több giga felesleges forgalmat eredményezhet, és pluszban foglalja a szervereden a helyet, míg a layer cache használatával csak a változott layer foglalja pluszban a helyet, a parent layerek csak egyszer tárolódnak.
Tehát ha mondjuk van egy Node.js appod, akkor a fenti megoldással van kindulásként egy Node 10 alapú imaged, majd később az általad vázolt módszerrel frissítesz Node 12re, hiába törlöd a Node 10 runtimet, foglalni fogja a helyet egy szülő layerben, és ráadásként még a Node 12 is foglalni fogja, hiszen most telepítetted a konténeredbe. Ugyanez igaz PHP, vagy bármilyen más alkalmazásra is.
És akkor még nem is beszéltünk az alkalmazásod, és függőségei által elfoglalt helyről.Minden alkalommal amikor frissíted az appodat.... ez nem lesz egyszerű, hiszen kelleni fog git kliens, SSH kulcsok (ezt nem akarod beletenni az imagebe), build függőségek (build packagek gigabájtokat emésztenek fel, és futásidőben nem használod őket, tehát kézi build után manuálisan kellene uninstallálnod őket ami nem mindig lehetséges 100%ban bizonyos függőségek miatt).....
Máris van egy folyamatosan hízó több gigás imaged.Azt még nem is említettem, hogy az általad vázolt "perzisztencia" csak a
--nameflag használatával valósítható meg könnyen, viszont ez esetben nagyon hamar bele fogsz névütközésbe.Egy nevet csak egyszer használhatsz. Ha van 2 projekted, és mindkettő saját adatbáziskonténert használ (ami ajánlott), akkor nem hívhatod mindkettőt
dbnek.
Elnevezed az egyiketapp1-dbnek a másikatapp2-dbnek? De akkor a szervereden amire telepíted őket, ott is ugyanígy kell elnevezned, és az elérési nevük is ez lesz az alkalmazásodból, és még ráadásul figyelned is kell hogy biztosan megadd a neveket, jól add meg őket, és ne legyen névütközés.Itt abba is hagyom, mert egész könyvet lehetne írni ennek a módszernek a hátrányairól.
Javaslataim a következők:
1)
Használd az --rm flaget amikor egy konténert futtatsz.
Ez törli a konténert amikor kilépsz belőle.
Ha nem használod, és kézzel mókolsz a konténerben, akkor commitolnod kell, ha a szerveredre át akarod vinni a változásokat, de ez a fentebb említett méret növekedési és egyéb problémákkal jár.2)
Fontos megérteni, hogy a konténer NEM VM!
A cél a reprodukálhatóság, transzparencia, auditálhatóság, cachelhetőség, frissítéskor csak a változott layerek letöltése, ezáltal kisebb sávszélesség és tárhely igény.3)
Nézz utána:
hogyan működnek a Docker layerek,
hogyan lesz a Dockerfile egyes soraiból új layer
hogyan működik ezeknek a cachelése
hogyan működik ezeknek a rétegeknek az újrafelhasználása különböző imagek között.4)
Használj Docker Composet.
Ez megoldja a konténerek életciklusának kezelését. (létrehozás, nevek, restart, takarítás, minden)
Ráadásként minden stackben elnevezheted az adatbázis konténeredetdb-nek, az appodatapp-nak, nem lesz névütközés, és még a hosztnevet is feloldja.Ne mixeld a stackeket, csak, ha tudod mit miért és hogyan csinálsz.
Konkrétan akkor lehet hasznos a több stack közötti kapcsolat felépítése, ha nginxxel virtual hostokat akarsz csinálni különböző konténereknek.
Ilyenkor csinálsz egy külön nginxet ami kezeli a proxyzást hosztnév/útvonal alapján a megfelelő konténernek, elvégzi a TLS terminációt, és az összes virtual hostodat tudod használni a 443-as porton, nem kell titkosítatlanul random host portokon használni a konténereidet.[ Szerkesztve ]
-
#134
samujózsi
senior tag
instantwater
#133
samujózsi
senior tag
válasz
instantwater
#133
üzenetére
Most csak az első mondatra reagálva (ébredés után megpróbálom megérteni a többit is
)
Akkor ti itt milyen restartról beszéltetek?
Nem rebuildről?
Mert az tiszta, hogy ha saját app fejlesztéséhez használom, akkor minden módosítás után rebuild, és ekkor valóban eltűnik minden változtatás, de ez nem restart.
De én kész szoftvereket üzemeltetnék, amiket változtatni nem akarok élesítés után, így a rebuild ritka esemény lenne.És itt egy kicsit visszatérnék az eredeti kérdéshez is: készítek mondjuk egy nginx konténert. Kiderül valami zero day exploit.
A fejlesztők villámgyorsan befoltozzák.
De hogyan, mennyi idő alatt fog eljutni ez a javítás a konténerembe?
Mert ha nincs konténerben, akkor előbb az nginx forrás lesz kijavítva, ezt követően az alap OS csomagja, a disztribúció fejlesztői/maintainere által, de a docker image?
Ha nem dockerben fut, akkor (debian alapon) apt-get update && apt-get upgrade és kész. Ezt naponta megcsinálom az éles gépeken. De a dockerbe, ha ott nem illik ilyet csinálni, akkor hogy, pontosabban mennyi idő alatt jut el?Ui: gondolom, feltűnt, hogy csak ismerkedek a technológiával. Azt egyébként kár hangsúlyozni ennyiszer, hogy ez nem vm, eleve közös a kernel, nem is fut benne más, csak a legfontosabb alkatrészek, ettől kezdve kevés köze lehet virtuális gépekhez.
Ilyenkor kezdek rájönni, hogy az élőszóban folytatott kommunikáció akár gyorsabb is lehet, mint az írott
[ Szerkesztve ]
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#135
instantwater
addikt
samujózsi
#134
instantwater
addikt
válasz
samujózsi
#134
üzenetére
Olyan restartról, hogy mi --rm flaggel használjuk, mert az a javasolt, és nem akarunk névütközést, de leginkább nem akarunk gondolkodni neveken egy eldobós konténernél.
Nem eldobós konténereket Docker Composeból indítjuk, mert egyszerűbb mint az alkalmanként igen hosszú docker run parancs.
A Compose pedig eldobja a konténert és újat csinál restartkor.Az nginxxel ráhibáztál, mert az pont egy olyan image, amit a készítő ad ki automatikusan az új verzióval együtt.
Az, hogy hogyan jut el ez a szerveredre az már más kérdés. Van aki használ különböző figyelő daemonokat, van aki már a git repót analizáltatja valamilyen vulnerability scan szolgáltatással ami riaszt, ha van sérülékeny függőség.
Beszélhetünk élőszóban is, mondom az óradíjat és a számlaszámot
Azért hangsúlyozom, hogy nem VM, hogy ne kezdj el a konténer shelljében csomagokkal mókolni, mert arra a Dockerfile való.
[ Szerkesztve ]
-
#136
samujózsi
senior tag
instantwater
#135
samujózsi
senior tag
válasz
instantwater
#135
üzenetére
Az nginx példa volt, helyettesíthető bármivel. A lényeg, hogy egy alaprendszeren én tartom kézben az update-eket, míg egy konténer esetében van egy plusz függőség, az image készítője. És tökmindegy, hogy egy hivatalos nginx-ről beszélünk vagy egy magam buildelte alpine alapú tákolmányról, ami nginx-t futtat. Utóbbi esetben az alpine készítője a plusz "réteg".
Nálam ennek nincs jelentősége, de egy netre kirakott szolgáltatásnál... nem aludnék nyugodtan, ha értesülnék egy aktívan használt exploitról és várnom kellene még arra is, hogy az image-ek készítőin átjusson.A szóbeli kommunikációval csak azt akartam mondani, hogy itt litániákat írok olyasmiről, amit munkahelyen, kollégákkal húsz másodperc megtárgyalni annak, aki nem olyan femedékeny, mint én.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#137
samujózsi
senior tag
instantwater
#133
samujózsi
senior tag
válasz
instantwater
#133
üzenetére
Nem állítom, hogy most nem voltam felszínes, de átfutottam újra azon amit írtál.
Azt hiszem, ott van köztünk a nézetkülönbség, hogy te fejlesztő eszközként tekintesz a docker konténerre, én meg egy szimpla biztonsági rétegként, mint mondjuk a FreeBSD jail-ek.
Amikor elkezdtem nézegetni a dockert, az volt a cél, hogy egy szerveren futó akármilyen szolgáltatás (DNS, proxy, saját gyártású web app, RADIUS stb.) kellőképp el legyen szeparálva a szervertől, viszonylag könnyen tudjam menteni, mozgatni.
Erre elvileg megfelel egy, max. két kvm guest valami lájtosabb op.rendszerrel, plusz némi bűvészkedés a host-on a netfilterrel/routinggal.
Ezt viszonylag könnyen kézben tudom tartani, tudom menteni, adott esetben akár más gépre átvinni nagyobb macera nélkül.
Csak láttam pár éve, hogy kezdenek divatba jönni ezek a konténeres megoldások, mint lxc/lxd és a docker és egy ismerős anno azt javasolta, hogy hagyjam a fenébe az első kettőt, mert csak a szívás van velük, tanuljam meg a dockert.
O.K., megtanulom, de lásd fent: mi a biztosíték rá, hogy a dockerben ugyanúgy és ugyanolyan gyorsan megjelennek a security update-ek, mint egy komplett, virtuális gépként futtatott linux esetében?
(és akkor csak az official image-ek vannak használatban, a ki tudja, ki által összetákoltakat nagy ívben kerültem - ha azokat is belevesszük a buliba, akkor már a konténert sem tudom megbízhatóként kezelni)Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#138
instantwater
addikt
samujózsi
#137
instantwater
addikt
válasz
samujózsi
#137
üzenetére
Rendben, tehát neked az izoláció miatt érdekes a Docker, és nem akarsz KVMmel komplett gépet virtualizálni.
A KVMen futó oprendszeredet te menedzseled, te mondod meg mikor, mit frissítsen.
Mivel a Docker image is valamilyen linuxot használ, ezért semmi nem gátol meg abban, hogy időnként újrabuildeld az általad készített képfájlt.Ha csak official imageket használsz, azok pedig elég jól karbantartottak, és folyamatosan frissítettek.
Nézz rá a watchtowerre. Ha van friss verzió az általad használt imageből, akkor ez elvileg tudja frissíteni.
Persze meg van az a hátránya is, hogy ez vakon letölti a legfrissebbet, amit nem biztos, hogy akarsz, mert mondjuk az új verzió inkompatibilis a régi által létrehozott adattal. -
haddent
addikt
válasz
samujózsi
#137
üzenetére
Egy virt-gépet pont nem fogsz frissítgetni, mert fut és kész. Automatizálni nem fogod, mert hülyén nem lehet vakon bele mindent lefrissíteni, ha olyan szinten production, hogy virtualizálva elfelejtve futtatod. Tehát kézzel tartod rendben. A Docker ennél egyszerűbb, mert lehúzod a legfrissebb official konténereket, ahogy a kollega is mondta és jónapot. Ha neked annyira egyedi és bleeding edge és security igényeid vannak, akkor buildeled őket magadnak, de nincsenek, ezt garantálom. Nálunknál sokkal komolyabb helyeknek sincs, mint mi, kis magánemberek
Alapvetően amit leírtál arra tökéletes a Docker, minimális az overhead. KVM marha jó, de azért van bőven. Én épp most borítom fel a teljesen rendet itthon. Egy baremetalon lesz több kvm virtualiuzáció, köztük 1 szerver és 1 tűzfal opnsense, majd a szerveren belül Docker. Hát azért van baj, kínosan megrogyasztja a gépet, amit a natív + Docker meg sem karcolt. Ott kezdődik, hogy natív iptables átküldte a gigabitet, mint kecskesztart a palánkon. Ez nem ugrik 600M fölé
[ Szerkesztve ]
-
-
#142
samujózsi
senior tag
instantwater
#141
samujózsi
senior tag
válasz
instantwater
#141
üzenetére
És ez már sokszor igazolódott...
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
#143
instantwater
addikt
samujózsi
#142
instantwater
addikt
válasz
samujózsi
#142
üzenetére
Persze, jobb félni, mint megijedni, és fontos a frissítés, meg a backup de nem biztos, hogy rajtad fogják kipróbálni a legújabb 0-day sérülékenységet.
Nincs azzal gond amit szeretnél, de általában nem kell naponta frissíteni a konténereket.
Nézd meg a fentebb linkelt watchtowert, hátha segít közelebb jutni az elképzelésedhez, ugyanakkor fontos megjegyezni, hogy nem mindig érdemes a legfrissebb verzióra frissíteni mindent, inkább csak a stabil vagy LTS verziókra érdemes, mert a köztes verziók bugosak lehetnek. -
#144
instantwater
addikt
samujózsi
#142
instantwater
addikt
válasz
samujózsi
#142
üzenetére
Sok Docker képfájl úgy készül, hogy a benne futó alkalmazás egy normál user alatt fut, nem a default root alatt, ez ad egy kis extra biztonságot. Van amikor még a shellt is letiltják az adott usernek, tehát, ha valahogy meghackelik az appot, akkor sem tudnak parancsokat futtatni a konténerben.
Sőt, indíthatod a konténereidet read-only módban is, akkor biztosan nem lehet belenyúlni a fájlokba és exploitot telepíteni.
Itt van egy blogpost arról, hogy Go appoknál mennyire le lehet csupaszítani a végső konténert, ezáltal nem lesz sérülékeny rendszerkomponensed: [link]
[ Szerkesztve ]
-
#145
haddent
addikt
instantwater
#144
haddent
addikt
válasz
instantwater
#144
üzenetére
Azért ahhoz, hogy a baremetal szervered, onnan a gatewayed és a gépeid meghackeljék az borzasztóan irreális, szerintem. Ahogy írod, mezítlábas paraszt userrel fut egy friss build ami legtöbbször konkrétan frissebb a legtöbb ilyen őskövület debian reponál. Na ebben az appban kell egy exploit, onnan kell 1 privesc és/vagy utána egy docker container escape, még 1 privesc és/vagy lateral movement, itt megfelelően szarul konfigurált tűzfal(ak), szintén megint megfelelően sérülékeny szerverek stb.. Én nem félek bár nincs is mit a saját forráskódjaimon kívül amit tessék vigyetek
Ettől függetlenül az ünnepek közti pangás alatt össze is raktam én is, vason kvm -ek, opnsense, dockerben minden reverse proxy mögött, default block policy abszolut minimum átengedve ips -sel meg intrusion detectionnel aztán gyertek, adok ip -t hajrá
És ezzel túlteljesítettem a legtöbb céget, köztük azt ahol dolgozom secanalystként [ Szerkesztve ]
-
samujózsi
senior tag
Vajon az normális, ha egy kvm guestben (ami NAT-olt interface-t használ) indított docker konténer (most épp nginx, de próbáltam egy mezítlábas alpine konténert is) nem lát ki a netre?
Hogy a publikált portok nem érhetőek el a fizikai vasról?Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz
samujózsi
#146
üzenetére
Ha jól értem, akkor nem: tehát van egy vas, rajta egy kvm guest és abban docker. Gondolom a guesten belül os szinten van net? Tippre valami guesten belüli natolási probléma lesz. Első körben a guesten belüli routeokat nézném meg, szeret össze-vissza akadni mindennel, ha automatikusan hagyod, nem static. Következő tipp, hogy 0.0.0.0 -on listenel-e guesten belül a docker cucc, végül pedig a guest ip -re oda van -e engedve a porton. Más nagyon nem kéne legyen
Nálam végre pontosan ez a konfig állt össze, vason fizikai NIC-re bridgelt OPNsense, illetve egy full virtuális bridgen egy guest még, amiben Docker azt csinál amit akar. Külön subnet a kettő, szépen megy minden ki-be amit engedek
[ Szerkesztve ]
-
-
haddent
addikt
válasz
samujózsi
#148
üzenetére
Szerintem a guesten belülre felesleges kézzel tűzfalaznod és/vagy annyira egyszerű kevés dolog lenne (lényegében sima bejövő forgalom accept és kész), hogy érdemes lenne natív iptablesben. Nálam is Arch a host os is meg a guest is, szóval maga az Arch tuti képes rá
Azt hiszem 172.17.0.0/16 a docker0 bridge gyárilag, ezzel nem akadsz össze routingnál?
Köszi
működik, de jóétvágyat hozzá. Én általában fejből meg tudom írni a composeokat amik kellenek nekem, elég intuitív, hát ezt biztos nem jegyzem meg 
És ezzel túlteljesítettem a legtöbb céget, köztük azt ahol dolgozom secanalystként 
Új hozzászólás Aktív témák
Hirdetés
- Teljes verziós játékok letöltése ingyen
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Diablo 3
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- Milyen légkondit a lakásba?
- Autós topik
- Házimozi belépő szinten
- Ingatlanos topic!
- Viccrovat
- Milyen okostelefont vegyek?
- További aktív témák...
- AKCIÓ! - STEAM kulcsok / Aragami, Transformers, Oddworld, stb. - 2024.08.08.
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- AMD Game Bundle: Warhammer 40,000: Space Marine 2 és Unknown 9: Awakening - kaparintsd meg már most!
- EREDETI - CHOICE - BUNDLE - STEAM KULCSOK - UPDATE!
- Microsoft Windows és Office Licencek / AZONNAL!
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen