• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    ADMIX
    ADMIX --- ---
    1 odpověď
    ONLINEQUE: tak nejjednodussi priklad je, ze mas proste userland se vsim vsudy, kterej si buildis jednou za tejden z upstream repa, co si natahne par RPM, nejaky pip moduly a nasere nejaky veci do /etc: base-os:latest, base-os:20200610
    a pak mas tu samotnou aplikaci, ktera ty veci pouziva, ktera se buildi v CI, treba app:latest, app:commitId

    ted nevim jak je to v dockeru, FROM?
    v aplikaci mas v repu docker file kterej zacina FROM base-os:20200610 a ten ti buildi po kazdym commitu app:latest kontejner, kterej pokazdy pouziva ten samej base-os (takze ten nacachujes jednou a pak uz jen updatujes ten app)

    a jednou za tejden, za mesic, nebo kdyz se to developerovi chce delat, tak udela commit co updatne tu app FROM dependency na FROM base-os:20200714, a tenhle novej chain pak prozenete testama apod.

    To je takovej nejjednodussi priklad multistage buildu kde si drzis platform image nezavisle od aplikace, a aplikace si definuje ten FROM base image, na kterym pak certifikujete/testujete/rolujete.
    V zavislosti na tom jak vase appka vypada se to da rozbit do mnohem vic komponent, muj priklad z $job-1 byl
    - base-os
    - custom interpreter
    - proprietary set of libraries
    - app-common
    - per-daemon code

    ten per-daemon code mel jako dependency konkretni verze app-common, libs a interpreteru a interpreter/libs mely base-os. Tohle vyzaduje dobrej release management, jinak se z toho diagramu poserete :D
    ONLINEQUE
    ONLINEQUE --- ---
    1 odpověď
    ADMIX: muzes dat nejakej konkretni priklad toho, jak tohle myslis, a jaky dusledek by to pak melo pro to upgradovani ? U tyhle myslenky se mozna uplne nechytam, dik.
    ADMIX
    ADMIX --- ---
    1 odpověď+1
    ONLINEQUE: zkusil sis rozepsat strom zavislosti a podle toho se podivat jestli muzes verzovat zavislosti a ty finalni kontejnery upgradovat podle toho?
    ONLINEQUE
    ONLINEQUE --- ---
    1 odpověď
    HOUMLES: tak to bylo mysleno, vybuilduju si image tak ze do nej behem buildu vrznu co potrebuju (at uz nejake "OS" balicky navic, plus PIPem to, co je treba pro python kod. Jakmile vybuilduju, tak uz nesaham na to, co je vevnitr. Berme jako fakt, ze kontejner, ktery se jednou pusti z image, uz se dal nebude modifikovat. Tenhle problem tu neresim ;-). Resim to, jak zajistit, aby bezici kontejner byl up-to-date, resp. abych zjistil dostatecne vcas, ze tomu tak neni a mohl ho pripadne znovu rebuildovat.
    ADMIX
    ADMIX --- ---
    1 odpověď+6
    ADM: Problem kontejneru ktery si muzes menit je, ze ti vytvari heterogenni prostredi a hrozne blbe se pak hledaj rozdily a problemy.
    Pro development, whatever. Ale pokud jdes do nightly runu (a dal) s tim, ze si postavis container stack a pred startem aplikace tam musis na cokoliv sahnout (as opposed to just injecting configuration from the driver), tak ten image neni udelanej spravne - IMHO. Jasne, da se to udelat spoustou veci, muj osobni nazor je ze pokud aplikacni kontejnery musis modifikovat za behu, zadelavas si na problemy v produkci :)
    HOUMLES
    HOUMLES --- ---
    2 odpovědi+1
    ADM: "aplikacni kontejnery existuji prave od toho, aby se tam ten pip install, mohl delat"
    je to trosku slovickareni, ale pip install mam v dockerfilu a ten mi vybuildi image, potud ok ... kdyz ten image pak pustim tak mam kotejner a v nem uz se pip install fakt nepousti
    ADM
    ADM --- ---
    2 odpovědi+1
    ADMIX: s tim nemuzu souhlasit, s tou tyci to plati pokud by delal nekdo pip install v OS, ale aplikacni kontejnery existuji prave od toho, aby se tam ten pip install, mohl delat (jinak bys musel cekat, az nekdo backportuje php/python/atd do balicku, pritom v pip apod. jsou stable verze ihned].
    takze zrovna v python projektu mas requirements soubor se zavislostma vcetne verzi, a v dockerfile jeden pip install, ktery jej pri buildovani image nainstaluje, vyvojar si to pak otestuje, a vysledkem je funkcni docker image, co vic si prat?

    ONLINEQUE: problem jsi popsal presne, neni mi znamo, ze by existovalo nejake reseni. jo mozna v komercnim docker supportu jsem videl neco jako ze v jejich verzi docker repository je nejaka security featura, kterou jsem si z marketingu prelozil jako ze to asi scanuje image na vulnerability, ci co. pak taky officialni vendori upstream images muzou garantovat aktualizace (image od redhatu napr.)
    ONLINEQUE
    ONLINEQUE --- ---
    ADMIX: ok, pokud budou potrebovat dostat do kontejneru nejakej kus pythonovskyho kodu se spoustou modulu, resis to jak ? Zbuildujes si po vlastni ose vedle toho OS balicky, pokud ty moduly v takovy podobe vubec neexistujou ?
    MUXX
    MUXX --- ---
    +1
    ONLINEQUE: Mam v planu zkusit toto: https://anchore.com/opensource/

    Ale nejsem si jistej jestli to je presne co hledas.
    ADMIX
    ADMIX --- ---
    2 odpovědi+5
    ONLINEQUE: krok cislo 1, kontejnery jsou zasadne immutable a pokud ti v nich nekdo dela pip install, tak si najdi takovou tyc co budes nosit porad u sebe, a jak nekdo udela pip install, tak ho zabij :D
    Jedna cesta je mit base OS image (v zavislosti na tom co potrebujes to vetsinou bejva bare OS userland bez kernelu apod.) a tvuj release cycle pravidelne upgraduje zavislosti tech kontejneru (pocinaje nightly runs, pres QA/UAT, az po gradual prod rollout)
    ONLINEQUE
    ONLINEQUE --- ---
    3 odpovědi
    Ahoj, jak zabezpecite, ze to, co bezi vevnitr v kontejneru bude z pohledu patch managementu up-to-date ?
    Me napadaji postupy typu:
    - definovat striktne z ktereho image lze stavet kontejnery a podle toho se chovat k "OS" balickum, tj. lze je upgradovat napr. pomoci APT, YUM...
    - pokud se treba vevnitr v kontejneru pouzije python a jeho PIP, tak nastava trosku schizofrenie.. dokazu to zkontrolovat treba pomoci pip-check; ale kdo vi, co kdo kde schova do nejakych pythonovskych virtualnich prostredi; ty pravda dokazu najit pomoci nejake radoby heuristiky (to ze nekde je "/bin/activate" mi zpravidla nabonzuje, ze je tam i virtualni prostredi, ale neni to uplne zaruceny postup
    - aktualizace image samotneho - watchtower ?

    Napada nekoho z vas nejaky co nejvic obecny postup ? Dik za pripadnou debatu / namety.
    REFLEX
    REFLEX --- ---
    Ahoj, je tu nekdo kdo se Dockerem zivi, mel bych nejspis kseft

    U klienta na serveru potrebujeme rozbehnout docker na produkci a nastavit server
    MISO
    MISO --- ---
    MUXX: skus do nazvu WARu pridat commit id z gitu
    MUXX
    MUXX --- ---
    1 odpověď
    Potreboval bych poradit s jednou silenosti co jsem zdedil. Mam vetsi Java projekt, ktery pres maven (multimodule project) vyplivne 30 docker images (protoze microservices, 30x WAR pro tomcat). Potrebuju to nejak verzovat a nasazovat na kubernetes/openshift. Z tech triceti dockeru je cca dve tretiny beze zmeny kodu a tedy diky docker cache se zbuildi vdycky stejny image. Hledam nejaky tip jak tyhle dve tretiny odfiltrovat, otagovat jenom zmeny a do helm chartu pak davat jenom zmeny. Aktualne releasuju vsechno jako novou verzi a na k8s pak helm vsechno re-deployne i kdyz neni zmena v kodu (ale zmeni se tag). Je na toto nejaky tool nebo obecny pristup? Developeri jsou hloupy lopaty a nemuzu se spolehnout na to, ze mi daji spolehlivou odpoved na to, ktere image je potreba releasnout. Beru jakekoli napady co to alespon trochu zjednodusi.
    ADMIX
    ADMIX --- ---
    +4
    KING: IMHO downtime je naprosto normalni soucast SLA tehle reseni - ja mam taky bias, ale na druhou stranu :D pokud chces opravdovej zero downtime, tak s tim prichazi omezeni (nektery veci, nektery software proste nejde vzdycky udelat zero downtime) a cena (HA)
    Jestli ma nekdo jednu VPSku, tak mi tam obcasny maintenance window pres noc (kde teda musis zapocitat i "novej balik omylem smaznul vsechny data let's restore") prijde normalni
    KING
    KING --- ---
    JON: to je downtown do jedne vteriny pokud jde vsechno bez problemu. To neni risk ktery bych pro cokoliv mimo osobniho blogu. Ale jak rikam, jsem asi poznamenany od zakazniku - selection bias. Jelikoz se ale bavime jen o jednom stroji, tedy zadne HA nebo cokoliv podobneho tak je to v tomhle pripade asi fakt jedno
    JON
    JON --- ---
    1 odpověď+3
    KING: Tak s downtime do jedné vteřiny, než se ten nginx otočí, funguje drtivá většina všeho co na internetu je - na eshopu to, troufám si říct, nejen nikdo nezaznamená, ale ani nenaměří - to už je větší riziko, že ta VPS vypadne celá.
    My to třeba v HA případech řešíme na loadbalanceru, který je před těmi dockery,
    KING
    KING --- ---
    2 odpovědi+2
    JON: Pokud nepotrebuju 0 downtime je hodne velky pokud, mozna ziju nekde jinde ale nedokazu si predstavit ze bych to navrhl nejakemu zakaznikovi
    REFLEX
    REFLEX --- ---
    REFLEX: Ted jsem u jednoho eshopu kde maji 329600 hitu za mesic a prumerna odezva je 400ms spocital ze by provoz stal 6000 mesicne, oproti 600 za VPS

    Mozna to furt cele nechapu :]
    REFLEX
    REFLEX --- ---
    1 odpověď
    RUDOLF: ja si myslim, ze to realne nejde spocitat

    Vim kolik bude mesicni navstevnost, ale uz nedokazu rict za jak dlouho to zpracuje pozadavek a kolik GB ram a kolik vCPU na to bude potreba

    Udelal jsem na to tabulku ted v rychlosti https://docs.google.com/...eadsheets/d/1Krrd5Jm3KH7bz_lvkzuBJkPyMVUf-zGqbn7ecVofHTY/edit?usp=sharing
    Kliknutím sem můžete změnit nastavení reklam