Hozzászólok Aktív témák

  • instantwater

    addikt

    válasz samujózsi #132 üzenetére

    Ok, a fenti módszerrel tényleg megmarad.

    Ez azért van, mert így könnyebb debuggolni, és tudod commitolni az állapotot egy imagebe, amit utána feltölthetsz a registrybe, de alapvetően nem ez a best practice mód image gyártásra, mert nem követhető, és nem reprodukálható Dockerfileból, ezáltal biztonsági szempontból aggályos, hiszen bármit telepíthetsz az imagedbe, sok munka ellenőrizni a tartalmát, mert nem tudni hogyan épül fel, és csak a layerek letöltésével lehet megszerezni az imaget, pár kilobájtos Dockerfileból nem lehet reprodukálni.

    Frissítése lehetetlen az image méret növekedése nélkül, mert a Docker minden commitot új image layerként kezel, hiába uninstallálsz bármit, az foglalja a helyet egy korábbi layerben.

    Csak export/import, squashing varázslással lehet a méretet csökkenteni és az új rétegek által "árnyékolt" halott adatot kidobni, ami dobja a historyt, ezzel együtt a layer cachelést, és újra és újra le kell töltened az egész imaget (operációs rendszerrel együtt ami ubuntunál többszáz mega) ahelyett, hogy csak a legutolsó (néhány) layert szednéd le frissítéskor, ez többszáz mega vagy akár több giga felesleges forgalmat eredményezhet, és pluszban foglalja a szervereden a helyet, míg a layer cache használatával csak a változott layer foglalja pluszban a helyet, a parent layerek csak egyszer tárolódnak.

    Tehát ha mondjuk van egy Node.js appod, akkor a fenti megoldással van kindulásként egy Node 10 alapú imaged, majd később az általad vázolt módszerrel frissítesz Node 12re, hiába törlöd a Node 10 runtimet, foglalni fogja a helyet egy szülő layerben, és ráadásként még a Node 12 is foglalni fogja, hiszen most telepítetted a konténeredbe. Ugyanez igaz PHP, vagy bármilyen más alkalmazásra is.
    És akkor még nem is beszéltünk az alkalmazásod, és függőségei által elfoglalt helyről.

    Minden alkalommal amikor frissíted az appodat.... ez nem lesz egyszerű, hiszen kelleni fog git kliens, SSH kulcsok (ezt nem akarod beletenni az imagebe), build függőségek (build packagek gigabájtokat emésztenek fel, és futásidőben nem használod őket, tehát kézi build után manuálisan kellene uninstallálnod őket ami nem mindig lehetséges 100%ban bizonyos függőségek miatt).....
    Máris van egy folyamatosan hízó több gigás imaged.

    Azt még nem is említettem, hogy az általad vázolt "perzisztencia" csak a --name flag használatával valósítható meg könnyen, viszont ez esetben nagyon hamar bele fogsz névütközésbe.

    Egy nevet csak egyszer használhatsz. Ha van 2 projekted, és mindkettő saját adatbáziskonténert használ (ami ajánlott), akkor nem hívhatod mindkettőt db nek.
    Elnevezed az egyiket app1-db nek a másikat app2-db nek? De akkor a szervereden amire telepíted őket, ott is ugyanígy kell elnevezned, és az elérési nevük is ez lesz az alkalmazásodból, és még ráadásul figyelned is kell hogy biztosan megadd a neveket, jól add meg őket, és ne legyen névütközés.

    Itt abba is hagyom, mert egész könyvet lehetne írni ennek a módszernek a hátrányairól.

    Javaslataim a következők:

    1)
    Használd az --rm flaget amikor egy konténert futtatsz.
    Ez törli a konténert amikor kilépsz belőle.
    Ha nem használod, és kézzel mókolsz a konténerben, akkor commitolnod kell, ha a szerveredre át akarod vinni a változásokat, de ez a fentebb említett méret növekedési és egyéb problémákkal jár.

    2)
    Fontos megérteni, hogy a konténer NEM VM!
    A cél a reprodukálhatóság, transzparencia, auditálhatóság, cachelhetőség, frissítéskor csak a változott layerek letöltése, ezáltal kisebb sávszélesség és tárhely igény.

    3)
    Nézz utána:
    hogyan működnek a Docker layerek,
    hogyan lesz a Dockerfile egyes soraiból új layer
    hogyan működik ezeknek a cachelése
    hogyan működik ezeknek a rétegeknek az újrafelhasználása különböző imagek között.

    4)
    Használj Docker Composet.
    Ez megoldja a konténerek életciklusának kezelését. (létrehozás, nevek, restart, takarítás, minden)
    Ráadásként minden stackben elnevezheted az adatbázis konténeredet db-nek, az appodat app-nak, nem lesz névütközés, és még a hosztnevet is feloldja.

    Ne mixeld a stackeket, csak, ha tudod mit miért és hogyan csinálsz.

    Konkrétan akkor lehet hasznos a több stack közötti kapcsolat felépítése, ha nginxxel virtual hostokat akarsz csinálni különböző konténereknek.
    Ilyenkor csinálsz egy külön nginxet ami kezeli a proxyzást hosztnév/útvonal alapján a megfelelő konténernek, elvégzi a TLS terminációt, és az összes virtual hostodat tudod használni a 443-as porton, nem kell titkosítatlanul random host portokon használni a konténereidet.

    [ Szerkesztve ]

Hozzászólok Aktív témák