Hirdetés

  • bambano

    Jómunkásember

    "A kérdés csak az, hogy lehet-e egyszerűbben, gyorsabban, hatékonyabban, jobban csinálni.": ezt elfogadhatjuk kiindulási alapnak. a kérdés az, hogy ilyen szemlélet mellett miért docker, ami lassabb, nem hatékony, nem biztonságos, semmit nem ad hozzá a rendszerhez, csak annyit, hogy idióta managgák verhetik a mellüket, hogy nekik is van konténer, meg satöbbi. nekünk is van konténer, abba hullik az, amit a szemétledobón leküldök az emeletről.

    "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": egyrészt ki lehet szögelni egy oprendszer verziót, és akkor mindenhol minden ugyanaz. ha pedig nem c jellegű dologról van szó, hanem mondjuk jáváról, akkor a többség úgyis mavennel vagy ant-tel telepít, annak a szkriptjében pedig lehet függőséget beállítani, amit automatikusan lehúz maga mellé.

    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. csinálja meg a fejlesztő rendesen a programot, legyenek olyanok a függőségek, amiket rendesen karban lehet tartani. persze lehet olyan, hogy tróger a fejlesztő, és erre nem hajlandó... akkor vagy lapát, vagy azt az egy-két libet berakod a program mellé és normálisan beállítod a linkert. debianon is simán lehet többféle verzió egy rendszerből, nem kell hozzá se docker, se chroot, se semmi, csak érteni kell a debianhoz meg a linkerhez. (jelen esetben nem is a debianhoz, hanem a gnu cuccokhoz)

    a portok kérdése se bonyolult, a szolgáltatások zöme alap porton látszik kifelé a világba, tehát szinte biztosan elé kell varrni egy load balancert, ha sokmindent akarsz egy gépen futtatni.

    "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?": aki nem akar felügyeleti rendszert csinálni, és mégis úgy akar szolgáltatni, az meg megveszi a cpanelt.

    "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.": itt azért van egy túlzó egyszerűsítés, amit annak ellenére magamtól is ismerek, hogy ebben a topicban nemrég szóvá tették: szét kellene választani a felhő szolgáltatást (ami alatt, egyéb jelzők híján, mindig publikus felhőt szokás érteni), a felhő technológiákat használó privát rendszertől.

    a publikus felhővel többek között gazdasági és biztonsági probléma is 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. azért dicsőítik a dockert meg a társait, merthogy gyorsan lehet vele deployolni. a probléma, hogyha gyorsan akarsz deployolni, elcseszted a fejlesztési módszertanodat.

    szóval amíg nem látok olyan problémát, ami valós és valóban nehezebb konténer nélkül megoldani, addig pesszimista maradok a technológiával kapcsolatban és az marad a fő iránymutató, hogy minél több kód, annál több bug.

    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. szóval az, hogy valaki nem ír magának mailszervert, nem érv a docker mellett, mert elvileg dockert se ír, gyakorlatilag meg mégis rákényszerül.

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • gabor7th

    PH! addikt

    Az összes link amit adtam egy se hozzám vezetett, éppenséggel Itcafe cikk is volt benne. Ez nem reklámozásról szól.

    A számítástechnika új negatív trendjei: ujtechkor.blog.hu

  • janos1988

    PH! addikt

    Nekem úgy jön le ez az egész kissé nyersen megfogalmazva, hogy van egy baszott nagy rés a piacon és senki sem próbálja meg betömni. Szóval gyakorlatilag nincs ellenfele a G Suite szolgáltatás csomagnak, nem hiába ezt választják sokan bagóért. Hajrá éhező informatikusok! :P De ez már nagyon off.

    [ Szerkesztve ]

    https://www.youtube.com/watch?v=mkDSGbRyjz8&list=PLVJH24yGtE_w5Ke4aWmRV8erFQmqRD1dK Minden egyes új rész rátesz még egy lapáttal :-D

  • gabor7th

    PH! addikt

    Nyilván ha egy kis helyi céged van, nulla nemzetközi édekeltséggel akkor nem akkora gond. De például a kínaiak ipari szinten másolják a nyugati cégek termékeit amiben hackerek is kiveszik a részüket aztán megspórolva a termék kifejlesztésének költségét is, nyomott áron kiadják a sajátjukat és éppenséggel az így kialakult versenyben sokszor ők győznek. Tehát nagy ára lehet annak, ha valaki lazán veszi a dolgot. Ha pedig sok vállalat egy helyben tartja a fontos adatait, akkor csak azt az egy diót kell feltörni, ahelyett, hogy mondjuk 40.000 helyet kéne egyenként, amire mondjuk nem is lenne kapacitásuk és így célpont se lennél.

    A számítástechnika új negatív trendjei: ujtechkor.blog.hu

  • bambano

    Jómunkásember

    elzarándokolsz a 19-es hozzászólásodhoz, elolvasod az első mondatot, majd revideálod az álláspontodat.
    az én magánvéleményem az, hogyha én lennék a ph! illetékese, ezért a mondatért biztos kivágtalak volna, ha meg figyelembe vesszük az összes többit is, akkor meg pláne. ugyanis lopod a reklámköltséget.

    lezso6 szerint a user: rossz számtech karmája van | @netik: There is no Internet of Things. There are only many unpatched, vulnerable small computers on the Internet.

  • hcl

    PH! félisten

    LOGOUT blog

    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 ]

    Veszek _hibás_ LCD monitort,fényképezőgépet, objektívet, routert ---- Mutogatni való hater díszpinty

  • dabadab

    Jómunkásember

    "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

  • Snoop-y

    PH! kedvence

    Viszont a kiadas jobban tervezheto. Ez eleg nagy elony.

    New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

  • 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.

    Lenovo T440s Thinkpad - Linux Mint 18.3 Cinnamon

  • anulu

    PH! félisten

    ühümm, feltéve ha mindenki pontosan tisztában van vele mi mennyibe kerül, és alkalmasint divíziónként back-charge-olva van. egyébként csak megy a pislogás meg a hüppögés, amikor megjön a számla, meg az értetlenkedés, hogy "dehát arról volt szó, hogy olcsóbb lesz". ha az adott cég és (részleg)vezetői képtelenek arra, hogy megértsék, hogy _minden_ pénzbe kerül, és ami eddig "best practice" alapon csak úgy "volt", az most rájuk lesz terhelve, akkor jönnek az értetlenkedő kérdések...

    [ Szerkesztve ]

    "Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone8 64GB | iPad Retina 32GB /w 3G | XBOX ONE X

  • Snoop-y

    PH! kedvence

    Nem azt mondtam hogy olcsobb lesz csak jobban tervezheto. Elozo munkahelyen is sajat adatparkban olcsobb volt uzemeltetni par dolgot viszont nem volt olyan rugalmas mint az AWS. Ezert par dolog ment a felhobe a mission critical dolgok maradtak (pl hitelkartya adatok)

    New level... Advertising has us chasing cars and clothes, working jobs we hate so we can buy shit we don’t need

  • Gargouille

    fanatikus tag

    Félig-meddig tényleg lufi, de azt ne vitassuk el, hogy van létjogosultsága. Kicsit olyasmi mint anno a Windows 95 megjelenése volt. Végre az is tudta használni a számítógépet aki amúgy full sötét volt hozzá, így korábban esélye sem volt.

    Valahogy a cloud szolgáltatások megjelenésével sokak számára elérhetőek lettek magasabb színvonalú dolgok, igénybe tudtak venni olyan eszközöket amiknek a házon belüli saját kiépítése és üzemeltetése meghaladta a képességeiket, így el voltak zárva előlük.

    Persze sok vetülete van ennek az egésznek, nem fekete-fehér.