- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
- A Gigabyte is visszaveszi alaplapjainak alapértelmezett tuningját
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen belső merevlemezt vegyek?
- OLED TV topic
- HiFi műszaki szemmel - sztereó hangrendszerek
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Hobby elektronika
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Milyen egeret válasszak?
- Házimozi belépő szinten
Hirdetés
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
Új hozzászólás Aktív témák
-
haddent
addikt
Nem találtam Dockerrel foglalkozó topicot, szóval gondoltam nyitok egyet, hátha másnak is hasznos lesz
Mi is az a Docker?
Egy konténerizációs forma. Konyhanyelven a fizikai vas (bare-metal) és a teljes virtualizáció (kvm, hyper-v stb.) közt helyezhetnénk el valahol.
Főbb előnyei a szeparáció (egy-egy konténer izoláltan fut a hosthoz és egymáshoz képest) és a gyors, könnyű, kompatibilis disztribúció (konkrétan bármilyen alkalmazást becsomgolsz egy Docker konténerbe, akkor az pontosan ugyanúgy fog futni bármilyen hoszton, bármilyen OS alatt bármilyen verzióval, amennyiben egyetlen előfeltétele, a Dockerd engine teljesül).
Ezen felül természetesen el lehet durvulni vele és stackeket, swarmokat létrehozni, amiket aztán a felhőben (pl. Kubernetes) is futtathatunk, így osztva a terhelést, biztosítva a zero downtime -ot stb., de talán ennyire ne menjünk előre.Akkor most ez virtualizáció?
Nem. Pl. éppen ezért Linux hoszton nem tudsz Windows konténereket futtatni (nem mintha nagyon lennének vagy szükségesek lennének), illetve éppen ezért nincs grafikus megjelenítés, nem tudsz belépni "remote desktop" -pal a környezetbe (ez nem teljesen igaz, létezik pl. X11 forwarding, de ez eléggé abuse / erőszakolásnak számít és erősen megkérdőjelezi, hogy valóban Docker kell-e a feladat megoldásához)Teljesítmény
Szóval tisztáztuk, hogy nem virtualizációról beszélünk, tehát akkor nincs overhead. De, van, de linux hosztokon elenyésző. (Szubjektív, nem túl reprezentatív, de érdekes példa: ivy bridge alapú intel pentium G2130 procival és 4GB rammal kb. 20 servicet futtatok a szerveremen, köztük webszerver, torrent, Jellyfin (Emby) média stream, vpn stb., illetve ezek mellett tűzfalként is szolgál a gép, mégis röhögve bírja)
Nehéz százalékosan általánosságban adni egy számot, mivel nyilván alkalmazás- / felhasználásfüggő, de amennyiben bármilyen, nem grafikus alkalmazásunk (bármilyen szerver, kiszolgáló, háttérfolyamat stb..) van, mindenképp érdemes lehet kipróbálni.Miért?[/B
Nincs is konkrét virtualizáció, még overhead is van, akkor mégis minek? Azért, mert teljes mértékben elszeparálhatjuk alkalmazásainkat. Pl. miért akarnánk, hogy a webszerverünk és a torrent szerverünk egy környezetben fusson? Minek "lássanak át egymásra"? Sőt, minek férjenek hozzá a fizikai vashoz az abszolut szükségesnél jobban?
Ezen felül nem kell bajlódni semmilyen 26 ezer lépéses telepítéssel, nem létezik az inkompatibilitás és a dependencia fogalma, nincs cross-dependency, nem kell milliónyi, a hoszt számára felesleges csomagot karbantartanunk. Egy-egy alkalmazás esetén elég mindig csak az ő saját image -ét frissíteni és máris a legfrissebb, legbiztonságosabb, javított alkalmazás fog futni, ráadásul szeparálva, ami ugyan nem feltétlen teljes mértékben megegyező biztonsági izoláció a teljes virtualizációhoz képest, de közel állhat hozzá.
Személyes véleményem szerint a rendezettség és letisztultság is fontos egy ilyen környezet esetén, hiszen minden logot, mentést/adatot és konfigurációt a mi saját elveink szerint rendezhetünk, 1-1 mappába gyűjtve, nem szétszórva a root / -on. Így nyilván a biztonsági mentés / backup is jóval egyszerűbb.Témaindítónak talán elég ennyi
-
haddent
addikt
Nekem is tervben van / félig-meddig kész egy nagy összefogó cikk úgy mindenről is
Hol akadtál el az HTTPS/TLS -sel kapcsolatban? Biztos meg lehet oldani "gyári" Nextcloud stílusban is, de a legegyszerűbb szerintem / nekem az volt, hogy az amúgy is már meglévő nginx reverse proxy mögé bevágtam és kész is
Portainer-t is használok, viszont én kizárólag felügyeletre / log nézegetésre. Sajnos a deploy egyelőre docker-compose 2.0 -t tud max. kezelni én meg 3.2 verziót használok, sokkal rövidebb, implicitebb, meg talán voltak is dolgok amik csak vele jöttek be
-
haddent
addikt
Ahogy írta colomb2 is és én is, reverse proxy mögé érdemes rakni mindent. Egyrészt security másrészt https endpoint. Na meg ugye mi van olyankor, ha egyszerre 4-5 http(s) cuccot akarok hosztolni? Elég gány portokat írkálni böngészőbe, sokkal elegánsabb egy (sub)domain. Na meg nem szokás csak úgy kiengedni a dolgokat egyenest.
Backup szerintem rém egyszerű portainer nélkül is. Eleve minden volume -ot bindinggal használok, van egy sajátos szisztémám. A backup így a config+data könyvtárak és a docker-compose.yml, semmi más nem kell. Lényegében GIT -be mentek mindent. A data kicsit eröltetett GIT -be, de egyébként eléggé best practice szerintem.
Személy szerint nem ajánlom, hogy a Portainerre bízd magad. Jó dolog, én is használom, de nem helyettesíti a tudást, szerintem. Mert aztán ha gubanc van úgyis be kell mászni manuálisan
OMV alatt mit értesz?
[ Szerkesztve ]
-
haddent
addikt
-
haddent
addikt
Attól függ mit akarsz. Nekem több subdomainem is fut, ezért az nginx tök külön unit a cloudtól és kézzel hoztam létre a certeket majd automatán frissíti őket ha kell.
Ezekben tudok segíteni szívesen, de az Owncloudot egyáltalán nem ismerem, plána az ő ssl kezelési hülyeségeit. (Egyébként nem jobb a Nextcloud?)
Nagyjából így néz ki egy nginx példa (ez így nem fog működni, az enyémet raktam fel, csak kivágtam az irreleváns részeket):
-
haddent
addikt
- Pihole biztosan lesz, az csak egy fancy név egy hosts fájlra
- owncloud passz, de mivel lényegében egy php alkalmazásról beszélünk egy mariadb -vel, ezért szerintem biztosan megoldható, max saját build
- nextcloud ha van akkor viszont nem értem minek az owncloud? next jobb, szerintemPortainerben a containers lapon tudsz lehúzni és deployolni, de neked is azt javaslom, mint előzőleg, hogy ne portainerrel kezdj, ha az alapok nem feltétlen vannak meg
-
haddent
addikt
válasz instantwater #15 üzenetére
A jelszó kezelés elég bonyolult nálad, Bitwardent nézted már? Főleg a Bitwarden-rs implementációt rust nyelven, nálam hibátlan. Be tudod importálni a keepassod.
Nálunk hallani se nagyon hallottak a Dockerről, de egyből megtetszett nekik, hogy pár óra alatt migrálok bármit bárhonnan bárhova bármilyen verzióban. Nem gond, hogy 4 éve elavult és érintetlen szarokat kell újrahúzni új szerverre, majd upgradelni. Nem kérdés, hogy ez a jövő és már rég itt van (kéne lennie), csak hát rengetegen le vannak ragadva.
Én is az ELTE -n tanultam, papíron, formális matematikai nyelven papíron ciklust meg programkódot írni és C/C++ -ban mindent, de nem vagyok a magam ellensége -
haddent
addikt
válasz instantwater #19 üzenetére
Nem tudom hány néhány én 2013 -ban kezdtem, ne aggódj akkor is az ment bőven.. B szakirány, prog.mód meg analízis Nem baj ez, az alapok kellenek, adott egy látásmódot meg olyan alaptudást amivel ezek meg minden újdonság könnyen tanulható, csak mondjuk legalább a C szakirányon (vagy csinálnának egy "D" -t) ami tényleg az, hogy 3 év után használható, modern szakember legyen, ne egy elmaradt valami..
Van self-hosted bitwarden, közösbe nyilván nem tolnék én se semmit
[ Szerkesztve ]
-
haddent
addikt
válasz instantwater #25 üzenetére
Is! Na meg high availability -hez IS (swarm)
-
haddent
addikt
Dehogy! Biztos vannak olyan mazohista állatok, akik 1-1 konténert cli -ből futtatnak minden paramétert kézzel mindig beírva, de erre találták ki többek közt a Docker-Compose -t. Szépen egy yaml fájlban felparaméterezed aztán csak docker-compose up, down, pull stb..
Lehet portainerezni meg van updater ami a jelenleg futó konténerből kiszedi a paramétereket, updatel és újraindít ugyanazokkal meg ilyen egyéb baromságok, de egyértelműen az a biztos és jó, amikor explicit módon ott van egy yaml konfig fájlban minden és kész. Arról nem beszélve, hogy jól csoportosítható több konténer egy stackké, közös network stb..
-
haddent
addikt
Otthonra ez elmegy, de productionben csúnya lenne
Érdekességképp, hogy pl. miért / azért Dockerrel IS be lehet szívni az inkompatibilitást. Kb. hetente szoktam frissíteni az összes stacket, konténert. Van néhány saját "kéziratú" konténerem is benne saját appal. Az egyik ilyen egy homeserver (automatizált login nélkül torrent keresés, letöltés gombra nyomva beküldi a deluge -be majd letöltés után rendszerezi stb..). Kijött a Deluge frissítés tök jó, csak a Python-Deluge RPC nem volt vele kompatibilis, néztem miért, mégis hogy hasalhat el.. A saját konténerem meg ugye hiába próbálnám pullolni.. Jó, akkor fresh build. Semmi.. Oh, ja tényleg, diszkrét explicit módon beégetett verziók vannak benne, pontosan azért mert egy pip upgrade kb. naponta cseszte szét Docker nélkül... Csodás.. Akkor most mindenből fel a legfrissebb és szoros erős imák sorozata, hogy minden összeillik, majd megint diszkrét verziók beégetése.Ez nem volt sok idő, 1 óra kb. De productionben elég vicces lett volna
-
haddent
addikt
válasz szuszinho #36 üzenetére
Szia
Elég intuitív a dolog, ha az alap dockerezés megvan, illetve az official dokksiban mindenre rá tudsz keresni, össze lehet legozni szépen. Személyes véleményem alapján a legojbban akkor jársz, ha meglévő kissebb-nagyobb composeokat átnézel, mi merre hány méter. Ha lesz időm délután feltöltök párat
-
haddent
addikt
Nem, semmi. Annyi, hogy minden service-hez fel kell sorolni amit futtatni szeretnél. Van egyébként unless stopped is, nem tudom pontosan hogy van keress rá. Akkor még jobban .service -re hasonlít, mert ha leállítod kézzel ("disable") akkor nem indul újra amíg el nem indítod kézzel.
Meg ugye el lehetne ezt az egészet vinni kubernetes irányába is, de szerintem otthonra (jobban mondva amíg nem load-balance / high availability a cél) addig felesleges és szvsz. a kubernetes konfigja egy hányadék a compose-hoz képest
Kapcsolók közül még a --force-recreate talán érdemes megjegyezni
[ Szerkesztve ]
-
haddent
addikt
válasz szuszinho #58 üzenetére
Akkor meg is van mi a gond. Első körben, hogy a 172.19.0.2 az a konténer ip címe és lokál (ezért is látod a virtualizált eth0 interfészt), ahogyan a 192 -es is. Public ip -d kéne felvenni a dinamikus dns -hez.
Ezen felül a docker0, lan és wan interfészeid össze kellen forwardolni, ip forwardingot engedélyezni kernelbenMondjuk ennek nagy részét a Docker alapból megcsinálja, ha nem vagy mazohista és nem kapcsoltad ki az iptables nyulkapiszkát és csinálod manuálisan
De servernek tuti a wan címed kell nem a konténer-lanNálam pl. azt adom meg, hogy rowra.org, a lan 10.0.0.0/24, a docker meg 10.10.0.0/16
Ezen felül érdemes NET_ADMIN jogot adni a stacknek.Teszt erejére kipróbálhatod, hogy
privileged:
true
network_mode: host
Módban futtatod, csak majd (szerintem) ne hagyd úgy, mert így nem nagyon érvényesül a virtualizációban rejlő "védelem", ráül a hosztra teljesenItt az én konfigom, hátha segít ez is [link]
[ Szerkesztve ]
-
haddent
addikt
válasz instantwater #65 üzenetére
Maga a működése és az elve az nagyon is jó, csak nekem a konfigja baromira nem tetszik a composehoz képest De hát ez csak az én kis beidegződésem, ettől még marha jó cucc
-
haddent
addikt
válasz instantwater #68 üzenetére
Pontosan ezt mondtam, hogy a swarm nekem szimpatikusabb, hiszen compose syntaxot használ. Az már más dolog, hogy a Kubernetes meggyakta és nyilván azóta messze le is hagyta
-
haddent
addikt
válasz szuszinho #80 üzenetére
Ahogy mondta a kolléga, egy stacken belül hostnévvel közlekedünk, sőt a portokat sem szükséges megpublikálni. Én nem használom ezt a 2 cuccot, de ha jól értem, akkor pl a jackett neked nem is kell, mármint kézzel te azt nem piszkálod. Tehát pl felesleges megpublikálni. Sonarrnak pedig "jackett:9117" -en kellene elérnie az apit
-
haddent
addikt
válasz szuszinho #88 üzenetére
Container != stack. A stack az egy, vagy több konténer összessége. Az az előnye, hogy pont a hasonló helyzetekre saját networkingjük van amiben közösen vannak, többek közt
Nem kell sem túlgondolnod sem túlbonyolítanod, egyelőre szerintem bőven elég annyit tudni a stackről, hogy simán a composeban a services -nél nem egy, hanem szépen több konténert felsorolsz, a többi automatikus
-
-
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 ]
-
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]
-
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 ]
-
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
-
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
-
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 ]
-
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 ]
-
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? -
haddent
addikt
válasz instantwater #150 üzenetére
Szeparáció. Biztonságos a Docker, de épp tegnap beszéltünk paranoiáról, nem? Ezen felül részemről a Docker hoszt-guest kívülröl most egy sandbox, azt művel belül amit akar, kívülről úgyis csak 80,443/tcp van odaengedve. Illetve, részemről, ha külön vasam lenne szervernek, akkor azon natívan futna a Docker, de mivel 1 gép nálam a tűzfal, docker-szerverek + htpc, ezért tényleg indokolt, szerintem
-
haddent
addikt
válasz instantwater #168 üzenetére
Pont ezekért érdemes mindenre compose -t, akár 1 service-re is. Sokkal letisztultabb a config, és simán docker-compose logs -f, meg docker-compose exec <név> bash stb. Még sokkal szebb, ha container_name is def a composeban
-
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
-
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 ]
-
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. -
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 huliganboy #225 üzenetére
Szerkesztettem, nézd meg, szerintem már az is megy
pai | 2020-01-04 13:11:31,318 - INFO - PAI.paradox.connections.serial_connection - Connecting to serial port /dev
/ttyUSB0
pai | 2020-01-04 13:11:31,324 - INFO - PAI.paradox.connections.serial_connection - Serial port open
pai | 2020-01-04 13:11:31,325 - INFO - PAI.paradox.paradox - Connecting to panel
pai | 2020-01-04 13:11:31,325 - INFO - PAI.paradox.paradox - Initiating communication
pai | 2020-01-04 13:11:31,330 - INFO - PAI.paradox.interfaces.ip_interface - IP Interface: serving on ('0.0.0.0',
10000)
pai | 2020-01-04 13:11:31,331 - INFO - PAI.paradox.interfaces.ip_interface - IP Interface startedArra figyelj máskor, hogy konfigokban nem elég, hogy törlöd a # előle, a space is kell törölni. Illetve konténeren belül "mindenhova" (0.0.0.0) bindolunk, nem a külső hoszt lan ip -re, mert akkor szépen összeakad (a Docker engine bindolja a külső portot és NAT-olja be a konténerbe. A konténernek tök más IP címe van, nem is tudnál a külsőre bindolni. Ha ezt ki akarod hagyni, akkor futtathatod network_mode host -ban és akkor natívan megy NAT nélkül)
[ 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 huliganboy #229 üzenetére
Csak re-up és kész, de az kell
Új hozzászólás Aktív témák
- Vírusirtó, Antivirus VPN kulcsok
- AKCIÓ! - STEAM kulcsok /Anuchard, Aragami, Children of Morta, stb. - 2024.04.17.
- Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! LEGOLCSÓBB! Automatikus 0-24
- PC JÁTÉKOK (OLCSÓ STEAM, EA , UPLAY KULCSOK ÉS SOKMINDEN MÁS IS 100% GARANCIA )