Melyiket egyszerűbb egy 60+ éves informatikához nem értő rokonnak elmagyarázni?
1. Nyisd meg a böngészőt, írd be azt, hogy cam1.domain.hu, és tádá!
2. Csaltakozz a VPN-hez, telepítsd fel egy appot, vagy szintén böngészőben gépeljen be egy web címet + portot.
Őszintén úgy gondoltam, hogy legalább ebbe nem fog belekötni senki, hogy az 1. a jóval egyszerűbb megoldás felhasználói szempontból.
flatpack
A docker semmilyen módon nem köt meg. A restreamer image pont az aptt használja.
az általánosba az a történet tartozik, hogy jó-e, hogy minden vackot dockerrel meg saját csomagmenedzsmenttel (flatpack meg hasonlók, a nevüket se tudom, mert érdemtelenek arra is, hogy megjegyezzem) meg hasonló módon akarnak megoldani a linuxokon. válasz: NEM JÓ.
De igen, jó. A docker egyik célja az volt, hogy a virtuális gépeket végre le lehessen váltani. Bár kompromisszumokkal, de ez sikerült a dockerrel. Végre eltűnt egy jó vastag réteg, ami komoly erőforrásokat zabált. A docker ezzel szemben semennyire nem lassítja a program futását. Szinte semennyivel több memóriát használ (néhány 10 MB, nagyon max néhány 100 MB).
ugyanezért totálisan téves felfogás kubernetessel oldani meg olyan dolgokat, amiket egyébként a linuxok szoktak tudni maguktól.
A docker mögött az a filozófia, hogy a futtató környezetet én állíthatom be, ami aztán mindegy milyen hoston fut, mert futni fog, mert mindent biztosít magának.
A kubernetes mögött az a filozófia, hogy van egy microservice halmazom, ami valamilyen topológia/láthatóság/stb alapján rendezett + egyéb kiegészítő szolgáltatások is elérhetők, mint a domain, stb és ezeket egy clusteren futtatja, amiben aztán szinte bármilyen Linuxok lehetnek.
A végén úgyis működni fog, mert a docker + kubernetes mindent leír.
amit én egy pc-vel elfuttatok hibátlanul, ahhoz neki fél racknyi pc-ből összehordott cluster kell, terabájtnyi memóriával, 16-128 magos processzorokkal, nvme ssd-vel, minimum 25 gigás hálózattal, stb. stb.
A docker + kubernetesnek ehhez semmi köze. Az hogy az a program ami ebben fut az ekkora erőforrást igényel az nem a docker + kubernetes hibája. Ezek szinte nulla overheaddel operálnak.
alapszabály: minél több szoftver fut, annál több a hiba. pont. és amit megnyerhetnél elvben azzal, hogy docker konténerfájlt telepítesz, bőven elbukod azzal, amikor valamelyik szoftverrétegben hiba lesz (mert lesz, ebben ne legyenek kétségeid) és meg akarod találni, pláne javítani.
Ezt mond azoknak a tudósoknak és researchereknek is, akik az 5G-t (és gyakorlatilag minden új dolgot) clould-only-ban fejlesztenek.
2 specifikus: én letöltöttem és megnéztem a forrását ennek a csomagnak. szerintem tedd meg te is, mert azt gyanítom, eddig nem történt meg. a forrásában van egy rakás js fájl, amiből te azt használod, hogy bekérsz egy usernevet meg egy jelszót, amit egyébként a jelszóvédett html-eknél az apacs meg a böngésződ simán megold. letölt egy csomó deb-et(!!!), majd patkol és fordít magának egy saját ffmpeg csomagot (ez önmagában normálatlan eljárás a szabad szoftver világban, az általa használt bitrate patchet illett volna upstream belejuttatni az ffmpeg stock gyári forrásába), majd letölt és telepít egy nginx-et.
Ennek semmi köze sincs a dockerhez.
Tehát azt, amit normálisan a kamera webszervere simán ki tudna szolgálni, de ha nagyon biztonság-mániás vagy, akkor egy reverse proxyval (ezt még el tudnám fogadni), azt ez a docker cucc HÁROM webszerverrel, egy rakás pluszban feltelepített cuccal és egy méretesebb javascript weboldallal oldja meg.
A kamera legutolsó frissítését 2012-ben kapta. A HTTPS-t bár ismeri, de a self-signed certen kívül mást nem. Ez minden tekintetben egy nem biztonságos mód. Az már csak a hab a tortán, hogy a böngésző nem ismeri fel, hogy a bejelentkező ablakon user/password van így mindig be kellene írni a user/password-t. Ez nem user-friendly, de ezt már legalább háromszor leírtam. Többet nem fogom.
Azt látom, hogy teljesen alaptalan dolgokkal dobálózol mindenféle komoly háttértudás nélkül és végül jössz a végítéleteddel.