- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Steam Deck
- Vezeték nélküli fülhallgatók
- Milyen billentyűzetet vegyek?
- Milyen egeret válasszak?
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- Milyen videókártyát?
- Azonnali fotós kérdések órája
- Melyik hordozható audiolejátszót (DAP, MP3, stb.) vegyem?
- Intel Core i3 / i5 / i7 8xxx "Coffee Lake" és i5 / i7 / i9 9xxx “Coffee Lake Refresh” (LGA1151)
Hirdetés
-
Mégis megjelenik Switch-re a Deliver Us the Moon
gp Közel négy évvel a hibrid konzolora szánt változat elkaszálása után a készítők úgy döntöttek, hogy mégis megjelenik a Switch verzió.
-
A Coca-Cola következő nagy újítása az AI
it 1,1 milliárd dolláros üzletet kötött a Coca-Cola és a Microsoft, hogy előbbi használja majd a redmondi felhőt és AI-t.
-
Szűkös készlettel indít az iPad Pro OLED?
ma Állítólag meggyűlt a Samsung baja az iPad képernyőkkel, az LG viszont a kívánt mennyiségben szállítja a paneleket.
Új hozzászólás Aktív témák
-
-
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
-
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.
-
samujózsi
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ő.
-
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
-
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
--name
flag 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
db
nek.
Elnevezed az egyiketapp1-db
nek a másikatapp2-db
nek? 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 ]
-
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 ]
-
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 ]
-
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. -
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 ]
-
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? -
instantwater
addikt
-
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.
-
őstag
válasz samujózsi #170 üzenetére
Bár nem értem minden szavad, DE. Én pl linuxserver konténereket használok. Van pl nginx konténerük. Felparaméterezve elindítom.
docker run --rm \ --name=nginx \ -e PUID=1111 \ -e PGID=1111 \ -e TZ=Europe/Budapest \ -p 80:80 \ -p 443:443 \ -v /path/to/appdata/config:/config \ linuxserver/nginx
Így az 1111 user és 1111 csoport nevében fut a konténer és csak a .../config mappába tud dolgozni. Ebből ha kijut, akkor szvsz egy vm se akadály annak a power user-nek. A konténereknek szintén tudsz erőforrás limitet állítani. Ha jön ki újabb image (minden pénteken vagy szombaton van friss build náluk), akkor kap egy docker stop-ot, majd docker pull linuxserver/nginx és végezetül a fenti parancs újra. Ez compose-ban még könnyebb, de most az lényegtelen. A frissítést lehet automatizálni is, de szvsz nem szerencsés éles környezetben.
Én kényszerűségből álltam át Docker-re az N40L-en, de nem bántam meg. A dependency hell nem vicces. Azóta RPi4-esen is így vannak a dolgaim.Remélem tudtam segíteni!
-
haddent
addikt
válasz samujózsi #170 üzenetére
Sok mindent nem látsz még megfelelően át, ebbe most nem mennék mélyebben bele, mert óriási téma és nyilván bőven van amit én sem meg senki sem, amikor épp kell, akkor felkeresi az ember a szükséges infókat. De a teljesség igénye nélkül:
Ami belül root, az kívül semmi, nagyon nem root, soha, semmiképp. Kivéve a privileged containerek.
Egy konténer frissen tartása rendkívül egyszerű feladat: pullolod az újat, vagy buildeled, ha nem official hanem saját image. Azért látod rosszul, mert "benne használt összes szoftvert" -ként emlegeted. Ez már itt rossz. Egy konténerben szinte csak egy szoftvert használsz, épp ez a lényege, microservices. Pl. egy weblap nem egy konténer egyben nginx mysql stb., hanem mind külön. Innentől az update is megoldott említett módon
Logolásra alapvetően nem-démonizáltan szokás mindent konténeren bleül futtatni foregroundban, így a log a compose logs streamre kerül, amit docker logger driverrel aztán bárhova IS küldhetsz, syslogként meg csomó log aggregátorhoz van előreírt driver
Óriási előnye, hogy az overhead kb. nulla, nagyon natívan fut minden. Illetve mivel microservicek vannak nem szerverek lényegében, ezért nem pazarolsz még sokkal többet külön szerverekre, vm -ekre.Végül pedig a kérdésedre az igazi válasz: nem kell mindent átpakolni Dockerbe! Helyén kell kezelni a dolgokat, tudni eldönteni, hogy mihez kell baremetal, mihez jó vm és mihez Docker.
Részben objektív, részben ízlés kérdése szintű példa: nem lenne elméleti akadálya, hogy a tűzfalat is Dockerizáljam, de k*#ra nagyon rossz ötlet lenne és nem oda való, de ugyanígy egy web szerver sem való vm -nek, ahogy a torrent "szerver" sem, ahogy egy Jellyfin (Emby/Plex) sem és egy Nextcloud sem.Röviden: ami nem kifejezetten biztonsági eszköz és egy, jól behatárolható feladtot lát el, vagy felbontható x kissebb konkretizálható feladatra, azt érdemes szétdobni konténerekbe és stacket építeni belőle, szerintem. Ez az én álláspontom jelenleg, nem mindig volt így és valószínűleg nem is lesz, de a mai tudásom és a napi szintű tájékozódás alapján én így lövöm be, most
-
samujózsi
tag
válasz samujózsi #174 üzenetére
Pardon (közben visszaültem a géphez) /etc/docker/daemon.json a fájl és egy ilyen kell bele:
{
"userns-remap": "docker-user"
}
A docker-user egy létező user a hoston és nem árt, ha a /etc/subuid és /etc/subgid is tartalmaz róla szóló infót.
Primadonnát felveszünk! https://youtu.be/9lETrcMJZJM
-
haddent
addikt
válasz samujózsi #177 üzenetére
#173: -ra: hát ha bemountolod neki a filesystemet, akkor nyilván tudja írni lehet ro kapcsolóval is. User mapping, iptables nyulkapiszka alapból stb., lehet erről vitatkozni, de amíg van egyenes és nem gány workaround megoldás, addig nem gondolom, hogy baj. Konténeren belül nem root futtatja a dolgokat, az egy dolog, hogy te hosztról hozzáférsz a roothoz, de az alkalmazást feltörőnek ugyanúgy privescelnie kell, majd onnan még konténerből megszöknie, nem lesz könnyaű dolga.. De igen, nyilván vitatathatatlanu könnyebb, mint vm -ből szökni.
A frissítéseknél pedig pull lehúzza a latest tagű imidzset, re-upnál már azzal indul. Official imidzseknél ergo megbízol a csomagolóban, hogy frissíti, ha van 0day hotfix, ami rendszerint meg is történik. Erről lehet vitatkozni, csak felesleges. Igen, +1 absztrakció, valóban. De ennyi erővel mindenféle csomagkezelő meg csomag is az, hiszen van sok dependencia, mi van, ha a láncban valahol valami hotfix kijön és egyik ráépülő meg nem reagál stb..? Ugyanez. De igen, ez is +1 absztrakció. Ellenkező esetben a "tökéletes" megoldás, hogy kizárólag saját imidzseket használsz, automatizálsz mindent, folyamatosan figyel, amint kijön valami buildel, deployol. Nekem van Jenkins CI -om erre, baromira nem használom
Ha ez még mind mindig nem elég, akkor egyetlen megoldás it-sec szempontból a teljesen saját implementáció teljesen saját, zárt forráskóddal, ami aztán telis tele lehet hibával és exploittal, mert senkinek fingja nincs róla és vaktyúk is talál szemet módszerrel jóval nehezebb feltörni valamit, mintha a kódot elemezgetve unatkozva játszanak a gyerekek
Log: de épp ezt mondom, hogy nem syslognak, hanem foreground non-daemon, stdout/stderr. Azt kapja el a docker log, azt tudja és továbbítja konténer névre és id -re szűkítve a host syslognak, gelf -nek vagy aminek akarod. Az official imagek így működnek. Ha ezen felül valami nem sztenderd elk*#!t logolása is van az appnak, akkor azt sajnos neked kell megoldani valamilyen más módon
[ Szerkesztve ]
-
Rimuru
veterán
válasz samujózsi #180 üzenetére
Az hogy a fajlrendszeren milyen uuid melyik rendszeren milyen userhez tartozik a rendszer dolga. A fajlrendszernek fogalma sincs arrol rendszerben milyen szintu a user csak szamokat (uuid/guid) irkal. (Tehat ami nalad geza az lehet hogy nalan jancsi lenne)
Amugy ajanlom hogy nezz utana az alapoknak is, namespaces, cgroups, stb.
Amugy2, cafoljatok meg ha valtozott, de legjobb tudomasom szerint amelyik user futtatja a dockert az root szintu userre valik, ergo nem less biztonsagosabb, max hamis biztonsagerzetet ad.
Vigyázat, csalok!
-
őstag
-
őstag
-
őstag
válasz samujózsi #200 üzenetére
Nem egy ilyen projekten kellett már dolgoznom.
Ott volt, hogy inkább fél lábon álltak, csak ne nyúljak az éppen működő rendszerhez.
Nyílván nem szélsőségesen, de én pl többre tartom a működést, mint a legfrissebb verziót. Még így, konténerekben is el tud néha b@szódni ez-az. -
haddent
addikt
válasz samujózsi #200 üzenetére
De ez tényleg nem tetszés kérdése. Ahogy írta a kollega, ez így működik. Pull, rebuild, deploy. Ez mehet CI alól teljesen beavatkozásmentesen. Tényleg nem sértésből, de az iparban óriási területeket hódított már meg és exponenciálisan nő évről évre. Ez, így, a te felhasználásodnál komolyabb és kritikusabb területeken
De ha ennyire kritikus számodra, akkor a CI tényleg nem értem miért nem jó megoldás. Tetszőleges X percenként pull, ha van új image akkor indul a saját image build, a végén pedig deploy. Közben bármelyik pontnál lehetnek tesztek is, nyilvángolya87 hoho, amikor megkapod a 4-5 éve telepített, akkor is lts -ként felrakott, elavúlt hulladék szutykot és hát őőő.. nem megy, frissíteni kéne. Ja, hogy azt senki nem fogja megcsinálni, mert minden 52 féleképpen dependency break meg társai
[ Szerkesztve ]
-
-
haddent
addikt
válasz samujózsi #209 üzenetére
Elég nagy állami cégnél dolgozom, szarásig van virtualizálva, HA (high availability), cluster stb.. amit el tudsz képzelni, tényleg, Microsoft on-premise nem tudsz olyat kitalálni ami nincs. Ennek ellenére senkinek eszébe nem jutna random befrissíteni semmit. Erre vannak a tűzfalak, ips/ids, intrusion detection, endpoint detection stb. Majd munkaidőn kívül, előre tervezetten.
Az pedig nem, hogy túlzás, hanem egyenesen nem igaz, hogy nem áll módodban. Ha annyira kell, minden buildelsz akár forrásból Más kérdés, hogy emberi lény ilyet nem tesz, az is biztos. -
PumpkinSeed
addikt
válasz samujózsi #216 üzenetére
Ha ilyen alapon megyunk akkor azert ne fejlodjon a vilag infrastrukture szinten mert elobb-utobb mindent meg lehet boritani? Nalunk egy 1000+ konteneres k8s cluster fut penzugyi rendszerrel. Ezt azert nehez lenne replikalni egy nem kontenerizalt kornyezetbe. Nyilvan meg kell mindent tenni, hogy a kontenerek biztonsagosak legyenek. Ami nem azt jelenti, hogy beirom Google-be "how to secure docker image".
[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
huliganboy
addikt
válasz samujózsi #220 üzenetére
Szia!
Publiksnak publikus, csak nem értem... A docker elméletét megtanultam, már a használat is menne, csak ez amit futtatom kell benne nem megy, pedig elméletileg jól van konfigurálva.... Még a logolás sem működik benne...
Jelenleg haddent segít, leírom majd mi volt a gond, ha elmondja..
-
huliganboy
addikt
válasz samujózsi #222 üzenetére
Ne szállj ki! Szeretem megérteni a dolgokat...
a program elindul, sőt a
sudo docker ps -a
listázza us hogy up és mutatja mióta...A lényege ennek, hogy több fajta riasztót lehet vele okosítani, okos otthonba integrálni. Soros porton csatlakozik a szerver a riasztóhoz, és elvileg ez a program MQTT és IP modult emulál mellé. A Kommunikáció soros porton zajlik ezután...
[ Szerkesztve ]
-
haddent
addikt
válasz samujózsi #222 üzenetére
Nagyon sok alapvető faxság, amit a git készítője rontott el, nem a user tehet róla.. Kezdve onnan, hogy nem bind-mountolunk ilyen aliasokkal, hogy "~/", mert hiába van a compose-ban UID=1000, a compose -t magát a root futtatja és tök meglepő módon a /root -ra létrehozta a /home/blabla -n keresett dolgott
Nem mappelünk (meg mégis hogy?!) directoryt - fájlba és fordítva. Meg még pár "apróság"
Na mindegy, most épp megy, de a /dev/ttyusb0 chownolnom kellett a userének, mert le se szarta a group membershipeket. Ez a része ugyan nem szép, de egyelőre megy.IP bindolni nem tud, szerintem kétszer akarja megkötni a 10000 portot, mert amikor nem fut, akkor semmi nem fogja. Amint elindul foglalt de ő is ezt látja..Megy az is, konfig el volt írva, host ip -re akart bindolni, pedig ugye konténeren belül 0.0.0.0 -ra bindolunk
[ Szerkesztve ]
-
haddent
addikt
válasz samujózsi #227 üzenetére
Hát ez valami zug github repo cucc, örüljünk, ha egyáltalán menni fog.. Azóta látom be akart lépni (gondolom vmi kliensről) és a python kód elhányta magát valami exceptionnel
Mindegy, ahogy én látom most a Docker része rendben van, fogjuk rá.
De válts(atok) le a debugban, mennem kell most kicsit -
haddent
addikt
válasz samujózsi #238 üzenetére
Az nginx fog listenelni a 80, 443 porton (80 -> 443 átirányítás, ssl/https miatt ugye), és a http(s) requestből eldönti, hogy hova irányítson át. Tehát a gyakorlatban best practice szerint úgy néz ki, hogy:
kliensek --- (https app protocol, 443 port, fqdn) --- > nginx (ssl bontás, fqdn értelmezése, 80 -> 443 redirect, headerek csatolása stb..) ---- http (vagy https, de itt már nem indokolt az ssl) ---> valódi szerver
Vagyis a kliensek az nginx -szel beszélnek és az nginx beszél az aktuális szerverekkel. Kívülről biztonságos, belülről akár sima http is lehet, így különböző layer7 analizálók is benézhetnek a forgalomba, it security stb.
Nagyjábol ilyen elven lehet egyetlen ip címen hosztolni lényegében végtelen számú domaint, szervert.
Pl. egyszerűség kedvéért legyen a publikus cím 1.2.3.4 és van egy Teszt.hu meg egy Valami.hu cím, aldomainekkel. Ekkor
Teszt.hu meghívod a böngészőben, resolveolódik 1.2.3.4 -re, de a requestben benne lesz, hogy te "Teszt.hu" címen keresed, nginx fut 80,443 -on, elkapja, látja a Teszt.hu, ezért a 192.168.1.123:1234 szerverre továbbít, tetszőleges, bármilyen porton (így egy szerveren futhat akár 100 másik nginx, apache bármi is, más-más portokon)
Valami.hu -t meg mondjuk a 10.20.30.40:80 -ra, emby.valami.hu meg a 10.20.30.41:8096 -ra.
Ebből kívülről semmit nem fogsz látni, zökkenőmentes, https kapcsolatod lesz.
Kb így lehetne jellemezni konyhanyelven rövidenA felhasználóbarát kényelmen óriási előnye, hogy igazából csak 80,443 van nyitva az internet felé, nem kell 5-10-100 portot megnyitnod
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Ford topik
- Kínában túl sok az EV, fokozódik az árháború
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Kínai, és egyéb olcsó órák topikja
- Witcher topik
- Luck Dragon: Asszociációs játék. :)
- Samsung Galaxy S23 Ultra - non plus ultra
- Steam Deck
- Opel topik
- Call of Duty: Modern Warfare III (2023)
- További aktív témák...