Új hozzászólás Aktív témák

  • bambano

    titán

    LOGOUT blog

    válasz dabadab #50 üzenetére

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

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Új hozzászólás Aktív témák