Új hozzászólás Aktív témák
-
#15
instantwater
addikt
instantwater
addikt
Örülök, hogy lett ilyen topik is, mert kicsit nyugatabbra évek óta használják production környezetben is a Dockert és a Kubernetes is egyre népszerűbb. Én magam is napi szinten püfölöm őket.
Remélem a jövőben lesznek fejlesztői témájú kérdések is, melyekben szívesen segítek, ha tudok.
Aki fejlesztőként dolgozik, nagyon megéri megtanulni a Docker használatát és képfájlok készítésének módját. Egyre inkább alapelvárás lesz ez a tudás, hogy Docker konténer formájában tudd szállítani a kész programot, akár te telepíted kézzel, akár CI/CD rendszerből automatikusan kerül telepítésre valamilyen platformon, ami valószínűleg valamilyen Kubernetes alapú/kompatibilis megoldás lesz.
És persze, ahogy az első hozzászólásban is írta a kolléga, rengeteg fejfájást spórol meg a konténerizáció. Még felsorolni is hosszú lenne. Ezért amikor új munkahelyet keresek, már a fejvadásztól megkérdezem, hogy Dockert használ-e a cég. Ha nem, megy a levesbe. Ennyire ég és föld a vele vagy nélküle telepítés.
Felhasználóként hobbi célra én Syncthinget és OpenVPN-t futtatok egy kis VPSen Dockerben, így olcsón megoldottam a fájlszinkronizációt és a VPNt.
Syncthinggel a Keepass adatbázisomat szinkronizálom a telefon és laptop között. VPS közbeiktatásával gyorsabb, stabilabb, mintha egymást kellene keresniük relay szervereken keresztül.
Az egyszerűség jegyében a host OS Alpine Linux. Ez lehetne bármi más is, de kizárólag konténerek futtatására használom, így a minimalizmusa törekedtem.
[ Szerkesztve ]
-
#19
instantwater
addikt
haddent
#17
instantwater
addikt
Bitwarden felhős fiókot kér.
Köszönöm, így tudom, hogy hogyan és hol van az adatbázisom, nem pedig egy nagy közös adatbázisban kitudja milyen titkosítással.Ez a baj, hogy hallani sem hallottak róla
Nyugatabbra azért jobb a helyzet.Mikor fogja az ELTE ismerni legalább azt a szót, hogy konténerizáció, és hálózatok?
Amikor én jártam az IK-ra néhány éve, még mindig a "szekvenciális inputfájlból" című feladatok voltak különféle módon.
Köszönöm, a főnököm többet fizet, ha gyors a szerver, mintha jól tudok text fájlból maximumot keresni.
-
#23
instantwater
addikt
Rimuru
#22
instantwater
addikt
Eldöntöttem. Mindkettőt hostolni kell, úgyhogy marad a Keepass Syncthinggel.
Először majdnem megijedtem, hogy titkosítatlanul tárolod gitben őket.
Hallottam már erről az appról, de ennek nincs Android kliensse. Vagy igen?Ki mit futtat dockerben? Bármit ami linuxon elfut.
[ Szerkesztve ]
-
#35
instantwater
addikt
haddent
#34
instantwater
addikt
A Docker nem segít inkompatibilis alkalmazások esetén.
Javasolnám, hogy csak LTS verziókat használj azokból a szoftverekből amiket konténerizálsz, így viszonylag ritkán, pár havonta vagy évente kell csak frissítened, függően a szoftvered kiadási ciklusaitól.
Én a hetekben szaladtam bele egy elég komoly hibába ezzel kapcsolatban.
Node.js app, rejtélyes memóriaszivárgással.Kiderült, hogy a kolléga amikor megírta a Dockerfilet úgy döntött, hogy ő Node 9-et fog használni, mert akkor még az volt a legfrissebb.
Viszont a hibát ott követte el, hogy a 9-es verzió nem LTS, tehát nem a stabilitásra van kihegyezve, hanem az új featurek tesztelésére, Node 8 lett volna a helyes döntés ami ugyan régebbi de LTS.Frissítettem Node 10-re a Dockerfilet, újrabuildeltem az imaget, és láss csodát elmúlt a memóriaszivárgás.
A Node 10 az egy LTS verzió.
Productionben ez a minimum, hogy amit lehet, azt stabilt használni, de home serveren miért szívatnád magad instabil verziók tesztelésével?
Neked a saját kis szervered a production, annak kell kiszolgálnia az igényeidet.
Kivéve ha az igényed az, hogy minél jobb hibakereső legyél. -
#68
instantwater
addikt
haddent
#66
instantwater
addikt
Eléggé más dologra vannak kitalálva.
A compose az "egygépes" környezetre van kitalálva, hogy szépen besshzol majd upolsz amit akarsz.
Ennek egy doppingolása volt a swarm ami végül nem lett népszerű.A Kubernetes pedig egy 3..n (n=10,20,100) szerveres környezetre van kitalálva, ahol
a rendszer dönti el, hogy melyik konténer melyik fizikai gépre kerüljön,
költözteti őket, ha lehal egy gép,
automatikusan bekonfigurálja a gépek között a routolást, hogy mindegy legyen melyik gépen fut a konténered,
hálózati meghajtókat csatol,
loadbalancereket kér az infrastruktúra szolgáltatótól,
logot gyűjt központosítva,
névtereket kezel,
dinamikusan bekonfigurálja a konténereid környezeti változóit, nem kell kézzel fájlokat barkácsolnod majd feltöltened minden szerverre,
monitorozza az erőforrásokat és képes autoscalingre,
feltételek alapján priorizálja az erőforrások kiosztását, és a legalacsonyabb prioritású konténereket lövi ki először, hogy a magasab prioritásúak tovább futhassanak.Az egyik legnagyobb előnye, hogyha olyan konténereid vannak amik kimaxolják a gép erőforrásait, akkor a stackedet kiteszi több gépre, és menetközben skálázni is tud.
Ezt a composevel nem lehet megcsinálni.
Ezért találták ki a Swarmot, de az már történelem.Körtét az almával.
-
#79
instantwater
addikt
szuszinho
#78
instantwater
addikt
válasz
szuszinho
#78
üzenetére
Ezek egy egy konténerben futnak composeben?
Ha igen, akkor ne IP hanem service név alapján hivatkozzanak egymásra.A 192.168.x.x úgy néz ki, mint a host LAN IPje. Ez is működhet, de az a konténer amit el akarsz érni annak a 0.0.0.0:9117-on kell figyelnie.
Esetleg, ha adnál egy kis compose YMLt vagy docker parancsot többet tudnánk segíteni.
[ Szerkesztve ]
-
#86
instantwater
addikt
szuszinho
#84
instantwater
addikt
válasz
szuszinho
#84
üzenetére
Én most már nyitnék indítanék egy shellt a konténerben és curl/wgettel vagy csak pinggel megpróbálnám elérni a másik konténert.
Itt a portok bindelésével lesz baj.
Ha konténer névvel próbálod elérni az sem megy?
Hostról eléred?Úgy emlékszem a portainer tud importálni vagy exportálni compose ymlt.
Ha megy composeben akkor portainerben is mennie kell.
Megy composeben?Most látom van egy ' a http előtt. Az tényleg ott van vagy csak a fórumra került be így?
[ Szerkesztve ]
-
#87
instantwater
addikt
golya87
#85
-
#114
instantwater
addikt
samujózsi
#113
-
#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.
-
#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 ]
-
#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 ]
-
#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. -
#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 ]
-
#163
instantwater
addikt
samujózsi
#161
instantwater
addikt
-
#164
instantwater
addikt
pelyib
#162
instantwater
addikt
Akár csak egyetlen servicere is azért jó a compose, mert ha bonyolult az indítási parancs mondjuk több konfig flag, portok, környezeti változók, volumek, miegymás akkor sokkal egyszerűbb ezt az egészet egy yml fájlba elmenteni mint egy nagyon hosszú parancsot elindítani.
-
#166
instantwater
addikt
samujózsi
#165
instantwater
addikt
válasz
samujózsi
#165
üzenetére
Pedig ez így működik: [link]
Valóban nem minden szoftver kezeli tisztességesen de azok Docker nélkül sem kezelik tisztességesen, így Docker nélkül is ugyanúgy megsérülhet az adatbázisod.
A hivatalos imagekben ez általában benne van.
Amiben nincs benne, ott használhatsz valami init rendszert ami lekezeli a signalt és leállítja megfelelően a benne futó alkalmazást. De írhatsz egy saját kis entrypoint scriptet is ami ezt kezeli.
-
#168
instantwater
addikt
huliganboy
#167
instantwater
addikt
válasz
huliganboy
#167
üzenetére
Ez composevel még egyszerűbb, mert nem kell container IDt keresned.
[ Szerkesztve ]
-
#245
instantwater
addikt
szuszinho
#233
instantwater
addikt
válasz
szuszinho
#233
üzenetére
Amit keresel az a következő: jwilder/nginx-proxy
Automatizált nginx.
Automatikusan létrehozza a megfelelő virtualhostokat, és egy darab 80/443 porttal használhatsz akármennyi konténert.Ez pedig egy Let's Encrypt kiegészítő a fenti proxyhoz.
Innentől már csak egy darab domain név, néhány subdomainnel bekonfigurálva a szervered IPjére, és mehet a móka.
-
#248
instantwater
addikt
haddent
#246
instantwater
addikt
Azért kell neki olvasási jog a Docker sockethez, mert figyeli a futó konténereket, és amelyiken megfelelő változók vannak konfigurálva, azokhoz beállítja a proxyzást.
Úgy gondolom, hogy egy olyan image amit már több mint 100 milliószor letöltöttek nem adhat okot aggodalomra.
Illetve teljesen opensource a megoldás, tehát, ha akarod leszedheted GitHubról és buildelheted magadnak. Ott is van közel 13 ezer csillagja.
Használtam már számtalanszor, és nagyon jól jön, ha csak egy sima Docker hostod van, és kényelmesen akarsz több dolgot futtatni rajta.
Mondjuk oda kell figyelni, mert ha a standard 80/443 porton figyel a proxy, akkor céltáblája lehet különböző botoknak de valamit valamiért, és az eredeti példában szereplő random portok nem éppen megfelelő védelem a botok ellen.
Inkább valami fail2ban vagy tűzfal a megoldás.[ Szerkesztve ]
-
#466
instantwater
addikt
linuxalpine
#465
instantwater
addikt
válasz
linuxalpine
#465
üzenetére
Azt hiszem van valami csavar, hogy a Docker daemon oldja fel neked a DNS-t, es nem a konténerbeli resolv.confot használja a rendszer.
Nézd meg a doksit, hogy mi a menete a custom DNS beállításának a Docker daemon config fileban.
-
#485
instantwater
addikt
code1005
#484
instantwater
addikt
válasz
code1005
#484
üzenetére
Attól függ miről beszélünk.
Ha egy stateless app ami csak a konfigfájlokból él mint például egy nginx, ott elég azokat menteni, hiszen az imaget le tudod húzni a hubról.
Egy stateful app mint például egy adatbázis, ott célszerű időnként exportálni vagy az adatmappát volumeként mountolni és azt menteni időnként.
[ Szerkesztve ]
-
#512
instantwater
addikt
donat_sz
#511
instantwater
addikt
válasz
donat_sz
#511
üzenetére
Ha van 2 USB rackked (vagy asztali PC ben 2 szabad port) akkor linuxon dd paranccsal át tudsz klónozni mindent, de biztos windowsra is vannak klónozó programok.
A NASsal szerintem nem lesz egyszerű, mivel arról fut a rendszer amit klónoznál, így sérült lehet az adat a célmeghajtón. -
#518
instantwater
addikt
aicon
#517
instantwater
addikt
Elbeszélünk egymás mellett.
A kérdezőnek nincs lehetősége mindkét lemezt olyan rendszerre kötni amire fel tudná telepíteni a clonezillát vagy tudná használni a dd parancsot vagy tudná bootolni pendriveról.
Csak egy NAS van neki 2 lemezzel és egy laptop.
Ebbőn én nem tudok főzni.
) voltam, és 2014 ben léptem le.
Új hozzászólás Aktív témák
- Milyen monitort vegyek?
- Épített vízhűtés (nem kompakt) topic
- Autós topik
- Okos Otthon / Smart Home
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Havi limitet kap a GeForce Now
- DUNE médialejátszók topicja
- Elemlámpa, zseblámpa
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Villanyszerelés
- További aktív témák...
- Game Pass Ultimate előfizetések 1 - 19 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Eladó Steam kulcsok kedvező áron!
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, kedvező ár!
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest