Új hozzászólás Aktív témák
-
anulu
félisten
-
janos1988
addikt
Azért ez így elég gáz.
De mégis használják, mert beregisztrál 1 perc alatt és ott van a keze alatt minden 1-2 kattintásnyira.
Kicsit off: De mi a helyzet a sufniba berakott pc-vel? Van hasonló megoldás rá amit egyszerű beüzemelni és könnyű használni (levelező rendszer, ftb szerver, dokumentumok tárolása és szerkesztési lehetősége) és könnyű a karbantartása, üzemeltetése? Olyan megoldás amihez nem kell két informatikus, meg pár százezer ft, hogy működjön. És ha létezik akkor miért nem terjed?
https://www.youtube.com/watch?v=mkDSGbRyjz8&list=PLVJH24yGtE_w5Ke4aWmRV8erFQmqRD1dK Minden egyes új rész rátesz még egy lapáttal :-D
-
#95561216
törölt tag
Milyen előnyöket nem tud kiaknázni?
Az ár meg relatív, egy startup nem fog annyi pénzből saját infrát kiépíteni, amennyiért eldöcög egy évet a felhőben. A nagyok meg más tészta, ők nem listaáron kapják, különben egy Netflix már rég saját adatközpontokon csücsülne, ahelyett hogy a legnagyobb riválisát finanszírozza.
-
janos1988
addikt
-
#95561216
törölt tag
Dolgoztam európai felhővel is (három betűs német cég), akkor már inkább önként és dalolva adok mindent az NSA-nek
Cloud computing paltformoknak vannak más elméleti előnyei is az általad felsoroltakon kívül, aminek nagy része a gyakorlatban is megjelenik. Nem kell előre infrastruktúrát venni, ami új szolgáltatásnál legtöbbször hasraütésen alapul, vagy kidobtál egy csomó pénzt, vagy alultervezted, és akkor az marad meg a felhasználókban, hogy lassú vacak a termék. A csúcsidőt is remekül megoldja az automata skálázás. Persze ez nem úgy megy, hogy fogod a bare metal appserverre írt alkalmazást, kirakod a felhőbe, és ezek az előnyök megjelennek egy varázsütésre, és azt aláírom, hogy emiatt nem éri meg minden alkalmazást átírni.
De dolgoztam olyan greenfield projecten, ami cloud nélkül úgy indult volna, több száz, akár milliárd eurókért datacentereket építünk. Ehelyett évi pár millió euróért el lehetett kezdeni a fejlesztést, és megnézni, hogy van-e rá egyáltalán piaci igény. És itt elsősorban más cégek adatairól van szó, nem sajátokról, akiknek azt kell mérlegelniük, hogy mennyivel ad nagyobb kockázatot az, ha nem x cégnél vannak közvetlenül az adatok, hanem egy cloud szolgáltatónál, miközben az adatok minden esetben átutaznak az interneten, tehát még azt sem lehet mondani, hogy más módon nem férnek hozzá titkosszolgálatok, ha nagyon akarnak. A fejlesztői oldalról meg annyi a könnyebbség, hogy "csak" a saját alkalmazás biztonságával kell foglalkozni, az infra felelőssége másé. És itt talán még másodlagos is, hogy elhisszük-e, hogy ők jobban csinálják, a lényeg inkább az, hogy a jogi felelősség egy része másra kerül.
Btw a cloud computing nem egyenlő a public clouddal, vannak hybrid és private megoldások is, mindnek megvan a maga előnye és létjogosultsága.
-
#70234880
törölt tag
Teljesen jól látod.
Nem több ez, mint egy hatalmas lufi, ami bármikor ki durranhat.
Nagyobb cégek, ezt már az elején átlátták. És már az elején kedves mosollyal fogadták a zseniális, forradalmi korszakalkotó megoldást. De az hogy teljesen erre támaszkodjanak, egyértelműen felejtős.
Az okosabb IT felső vezetők nagyon meggondolják milyen információk tárolására használja. És milyen szolgáltatásokat üzemeltet.A Különböző VPS megoldások, szolgáltatások is lufi kategóriába tartoznak.
-
-
dabadab
titán
Senki nem mondta, hogy máshogy nem lehet megoldani: onnan kezdve, ha van egy editorod meg egy C fordítód, tulajdonképpen mindent meg lehet csinálni. A kérdés csak az, hogy lehet-e egyszerűbben, gyorsabban, hatékonyabban, jobban csinálni.
Persze, dokkerezés nélkül is felrakhatod a programodat a szerveredre, ahol gondoskodhatsz arról, hogy minden szerveren minden könyvtárból meg egyéb függőségből az legyen felrakva, mint az összes többin meg a fejlesztői gépeken, az összes file meg konfigurációs állomány oda legyen másolva, írhatsz valami scriptet, ami a config file-okban lecserélgeti a gépspecifikus részeket, ha egy gépen egynél több programot akarsz futtatni, akkor berakhatod őket chrootokba, hogy kellően el legyen választva egymástól, csinálhatsz nekik virtuális interface-eket, hogy mindegyik programnak legyen saját IP-je, így az azonos portok ne ütközzenek, ha több géped van, akkor rakhatsz föléjük valami load balancert - ezt tulajdonképpen mind meg tudod csinálni és ha meg is csináltad, akkor sikeresen újraimplementáltad a dockert. De mivel a legtöbb ember a mailservert meg a webservert se saját maga írja, akkor a docker esetében miért tenne ilyet?
Nincs az egész felhőzés meg egyebek között semmi nagy mágia, csak adott problémákra adott teljesen racionális megoldások.
[ Szerkesztve ]
DRM is theft
-
Nemtom, nekem elég egyszerűnek tűnt a Docker-es verzióváltás. Fut pár konténer, egyenként leállítgatod, elindítasz helyette egy újabb verzióst, amiben akár az egész frontend, vagy a webszerver, vagy akármi más verzió.
Ha valamelyik fajta forgalom megnő, elindítasz belőle még pár konténert, másik vason is akár, amin amúgy nem az szokott lenni. Ilyesmik.
A lényege nekem az, hogy sokkal kevesebb melóval lehet managelni, mintha OS szinten csinálsz mindent. (Nem mellesleg, pl. kevesebb plusz hardveres erőforrás, mintha virtuális gépeket kéne managelni egy fizikain.)Szinte mindennel van ez így, hogy arra kell használni, amire való, nem pedig minden másra is. Ha nem a Docker az optimális megoldás, akkor nem azt kell tolni.
[ Szerkesztve ]
Mutogatni való hater díszpinty
-
dabadab
titán
"ezen a területen az a kérdés, hogy docker image-t könnyebb generálni vagy .deb-et? elég egyértelmű, hogy .deb-et töredék meló karbantartani"
Ez miből ilyen egyértelmű? Mert nekem nagyon úgy tűnik, hogy a kettő kb. ugyanannyi meló.
És ugye a dockert nem csak in-house dolgokra használják, szóval a docker alternatívája sok esetben nem egy .deb, hanem egy Debian Stable .deb, egy Debian Testing .deb, friss Ubuntu .deb, Ubuntu LTS .deb meg RHEL .rpm. Az meg így már biztosan nem töredék meló.
"van. a felhő technológiát használó privát rendszerben meg főleg technológiai. ráadásul az egész egy teljesen irracionális, földtől elrugaszkodott fejlesztési elven alapul, nettó hülyeség az egész: ez a deploy-olj minél gyakrabban."
És ez azért irracionális, mert?...
Egyébként ez részedről elég nagy félreértés: a gyors deployolhatóság az csak következménye annak, hogy egyszerűen és jól használható a rendszer (nota bene, egy dpkg -i lefuttatása se tart sokáig).
"szóval amíg nem látok olyan problémát, ami valós és valóban nehezebb konténer nélkül megoldani"
Milyen gyakran szoktál olyan webes appokat csinálni, ahol előre nem túl megjósolható módon, elég tág határok között változhat a userek száma? Mert hát az egész felhősködés azért elég nagy részben arról szól, hogy rugalmasan, a terheléshez alkalmazkodó méretű infrastruktúrát lehessen használni.
"ja, nem tudom, olvasod-e néha a hupon nagyz blogját. nemrég írta, hogy jók ezek a konténer orchestration cuccok, mióta a zömét átírták maguknak, azóta használni is lehet. "
Nem olvasom, most belenéztem, de nem találtam ilyet - linket tudsz adni?
[ Szerkesztve ]
DRM is theft
-
cog777
senior tag
(A dockerhez lenne egy megjegyzesem. Mi c++ build rendszerehez hasznaljuk a docker-t, ami a
sajat infrastrukturan fut. )"egyrészt ki lehet szögelni egy oprendszer verziót, és akkor mindenhol minden ugyanaz."
Gondolom nem dolgoztal meg hosszu lejaratu nagy projekten, amit mar tobb mint 10 eve kezdtek.
Ez gyakorlatban ugy nez ki, hogy a project tobbfele oprendszer alatt forditodik es maga a project is rengeteg fuggoseget hasznal. A fuggosegek egy resze meg van osztva mas projectekkel, amelyeknek szinten megvan a maguk sajat kovetelmenye (oprendszer, fordito, cppcheck stb)
A termekhez gyakorlatilag osszeraktunk egy disztrot yocto-val ami nyilvan NEM ugyanazt nyujtja mint a fejlesztoi gepeken es a build szervereken van.
Sot, van olyan hogy a yocto egy verzioja (ami komplett operacios rendszer es annak szolgaltatasait jelenti) nem kompatibilis a fejlesztoi gepeken hasznalt ubuntuval. Ezt is dockerrel oldottuk meg, szimulaltuk a regebbi ubuntut es igy keszitjuk az imaget dockeren belul.
Mivel en most kezdtem el osszerakni egy build szervert, ami kismillio lepesbol all, a legnyilvanvalobb eszkoz hogy egy dockerfile-ba berakom az osszes lepessorozatot. Igy dokumentalva van az egesz, nincs az hogy valaki frissitett egy library-t ami problemat okozott csak az adott szerveren.
Tehat a docker file nem csak a buildhez szukseges lepeseket jelenti hanem az operacios rendszer kismillio beallitasait is. Kb min egy darab script amit MINDENT beallit. Nagyon kenyelmes igy menedzselni...Ha ki akarok probalni uj library-t, akkor konnyen megtehetem, atirom a dockerfile-ba es elinditom a build-et.
Ha operacios rendszer ujabb valtozatat szeretnem kiprobalni, akkor az egy verzio szam atirassal megtortenik es elinditom az build-et.Igy ha megvan a dockerfile egy build szerverre, akkor gyakorlatilag nagyon keves munkaval at tudom rakni a tobbire. Minden valtoztatas eseten keszitunk egy uj teszt docker fajlt, ha mukodik akkor csak deployoljuk a tobbi build szerverre.
Kesobb valoszinuleg behozzuk a Kubernetes is hogy segitse az image generalast.
HP ZBook Studio 15.6 G8 Mobile Workstation - Windows 11
Tehat a docker file nem csak a buildhez szukseges lepeseket jelenti hanem az operacios rendszer kismillio beallitasait is. Kb min egy darab script amit MINDENT beallit. Nagyon kenyelmes igy menedzselni...Új hozzászólás Aktív témák
it Az Oracle és a KPMG közös kutatása szerint a tisztázatlan felhőbiztonsági feladatkörök, az átláthatóság hiánya és a shadow IT hátráltatják a vállalatok kiberbiztonságát.
- PlayStation 5
- Parfüm topik
- WLAN, WiFi, vezeték nélküli hálózat
- Samsung Galaxy A54 - türelemjáték
- petipetya: Nagy chili topic. :)
- MILC felhasználók szakmai topikja
- Galax GeForce RTX kártyák jönnek a szűkösebb házakba
- Amlogic S905, S912 processzoros készülékek
- Formula-1
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen