• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    Docker aneb přístupný provoz kontejnerizovaných aplikací
    Docker(Hub), Compose, Swarm, boot2docker, DevOps, LXC, ECS, TumTum a jiné buzzwordy
    Bezpečnost v prostředí kontejnerů
    Related: automatizace [ Centralizovaná správa stanic a ostatních prvků v síti konfigurace/inventarizace/instalace/aktualizace/zalohovani ]
    rozbalit záhlaví
    ADMIX
    ADMIX --- ---
    1 odpověď
    ADM: Uf, nemam ted kam se podivat, ale pokud se nepletu, tak nomad si pro kazdej taskgroup vytvori adresar na hostovi pod --data-dir, a ten pak bindem mountuje dovnitr tech rkt kontejneru jako rw volumes.
    ADM
    ADM --- ---
    1 odpověď
    ADMIX: kdyz uz zminujes ten nomad, tak ty sdileny adresare jsou nejaky glusterfs, nebo jak tam maji tohle vyreseny? me cekaji ty logy vyresit na openshiftu (kubernetes), ale jeste jsem se tak daleko nedostal, zatim me nenapada jak to pak centralne sjenotit pokud repliky stejneho service loguji do stejnyho filename

    opet me prekvapil docker, ze neni mozne z parent image zbavit se EXPOSE, ENTRYPOINT apod., ale porad nechapu odkud to z te vysledne image vycte, vzdyt to musi byt ulozeny nekde uvnitr prece
    BEZDA
    BEZDA --- ---
    Zkousel nekdo neprivilegovany LXC kontejner a host networking? Nejsem si jistej jestli to vubec jde, pada mi to a dokumentace je skoupa, tak jen jestli nahodou nekdo netestoval
    ADMIX
    ADMIX --- ---
    1 odpověď+2
    DWICH: Nevim jak to ma kubernetes (nebo jakou orchestraci pouzivas), ale Nomad ma koncept taskgroups, kde vsechny tasky v jedny grupe maji namapovanej sdilenej adresar, kterej se da pouzit prave na ten socket.
    Typickej usecase pro to je logshipper - nechas hlavni task logovat do toho sdilenyho adresare, a logshipper task z nej sosa, posila upstream a rotuje.

    Jinak vic procesu v kontejneru tragedie neni, IMHO je to hlavne o tom udrzet si nejakej rozumnej deployment (aby clovek nedelal application container, ve kterym mu pojede celej jeho predchozi monolith :D )
    DWICH
    DWICH --- ---
    1 odpověď
    Mam kontejner, kam jsem si dal nginx, uwsgi a python, plus supervisor, kterej mi spusti uwsgi a nginx. Ze tam mam dva procesy mi srdce netrha, nicmene spravne by teda mel byt uwsgi, python a aplikace v jednom kontejneru a do druheho dat jen a pouze samotny nginx a konfiguraci k nemu? Vyznam toho vysunuti nginxu ven vidim jen v pripade, ze by serviroval vic ruznejch aplikaci, ktery pobezi v ruznych kontejnerech.

    Navic ted se muze uwsgi a nginx napojit pres socket, takhle by to muselo byt pres http.
    ADMIX
    ADMIX --- ---
    KOJA: Jo, deployment dobre separovanejch kontejneru je zuzo labuzo, mam ted jedno PoC ktery jede komplet na coreos a orchestruju rkt Nomadem z jednoho cloudfrontu :)
    KOJA
    KOJA --- ---
    1 odpověď
    ADMIX: Jsem pouze zvedavy amater, izolaci tech procesu povazuju za vyhodu ale dal uz nevidim. Je tam snazsi sprava zavislosti (treba security update knihovny) kdyz ma clovek vice mensich imagu nebo je to zajimavy z jineho duvodu?
    ADMIX
    ADMIX --- ---
    +1
    ADM: Je to proste jinej svet :)
    ADM
    ADM --- ---
    1 odpověď-3
    no teorie je to sice pekna, ale pokud je v ty php aplikaci nejaky staticky content, ktery ma byt podavany pres nginx, tak mi prijde trochu kontraproduktivni to oddelovat protoze pokud mi neco neunika tak bych tu aplikaci musel strkat do obou kontejneru, a dale resit smerovani z nginx na php (ale ok, o dynamickou dns vazbu se postara vyssi vrstva), dale musim v nginx mit servername abych vedel na ktery php-fpm konterjner to poslat, kdezto kdyz to mam spolecne tak to vim a mam tu nginx cast uplne stejnou konfiguraci v kazdem kontejneru

    stale mi prijde vyhodnejsi reseni mit to spolecne
    ADMIX
    ADMIX --- ---
    1 odpověď
    DWICH: Ja to treba delam kvuli tomu, ze backend je perl, je tam extra kontejner na perl a par dalsich dependencies, zatimco nginxu staci base OS kvuli par knihovnam.
    NIXIMOR
    NIXIMOR --- ---
    +2
    DWICH: vyhodu to ma tu, ze nemusis prave resit process management typu supervisor, protoze to za tebe dela docker sam.
    JON
    JON --- ---
    DWICH:u malych aplikaci to neni tak zjevny, ale v tom nginxu si to muzes treba rozhazovat mezi nekolik upstreamu (vic kontejneru) kvuli loadbalancingu, nebo AB testovani, nebo cast appky ti bezi v php a cast treba v ruby, nebo abys nasral uzivatele nebo admina apod. Duvod se dycky najde.
    DWICH
    DWICH --- ---
    3 odpovědi+1
    NIXIMOR: Ja teda pochopil pravidlo "one process per container" tak, jak ho pisou v best practices: "Each container should have only one concern"

    Best practices for writing Dockerfiles | Docker Documentation
    https://docs.docker.com/...ge/dockerfile_best-practices/#each-container-should-have-only-one-concern

    Oddelit od sebe webserver (nginx) a interpretr jazyka (php, py...) mi uz prijde trochu moc.

    Co by melo za vyhodu oddelit webserver a interpretr?
    NIXIMOR
    NIXIMOR --- ---
    1 odpověď+2
    ADM: spravne reseni by melo byt nginx v jednom kontejneru, php-fpm v druhym a ty mezi sebou prolinkovat. Idealne totiz plati ze jeden kontejner = jeden proces.
    ADMIX
    ADMIX --- ---
    ADM: V tomhle se mi kubernetes libi vic, pac v kombinaci s flanneld neresi porty, ale proste namapuje rovnou IP adresu pro tu danou instanci.
    ADM
    ADM --- ---
    1 odpověď
    no a pak by to podle zadani melo behat pod openshift(kubernetes), na to jsem taky zvedavej, takze predpokladam ze tahle vrstva se kompletne postara o dns-services-routing-portmapping a ten container bude hovorit pouze http na jakoukoli host hlavicku zvenku, jinak si nedovedu predstavit jak by se to uridilo, takze jina moznost nez nginx+php-fpm v kazdym containeru asi neni mozna
    ADM
    ADM --- ---
    1 odpověď
    resim ted microservices jako nginx+php container a musim si povzdechnout ze ofiko reseni jako CMD nebo ENTRYPOINT ve forme script wrapperu na startovani obou sluzeb me teda elegantni vubec neprijde (a uz vubec ne ta dalsi moznost hazet do containeru python kvuli supervisord, jak se pise v dokumentaci https://docs.docker.com/engine/admin/multi-service_container/). tohle mi prijde jako dost velke omezeni jinak velice vychytaneho dockeru
    ADMIX
    ADMIX --- ---
    +2
    ADMIX: Napadlo me dat followup na moji puvodni otazku, postavil jsem par malejch rychlejch PoC na Consul+Nomad kombu (SDS/CDS) co jedu v AWS EC2, a musim rict ze ten suite je fakt dobrej. Pro velky komplexni operations bude mozna kubernetes lepsi, ale Nomad jako orchestrator je rozhodne konkurenceschopnej, a hlavne consul+nomad ve srovnani s etcd+kubernetes je vyrazne jednodussi na initial setup.
    Zacinam si ted hrat s tou druhou dvojici, abych to dostal do ruky, tak uvidime jaky budou dojmy z toho :))
    KOJA
    KOJA --- ---
    ADMIX: Diky!
    ADMIX
    ADMIX --- ---
    1 odpověď+1
    O tohle se stara orchestrace.

    https://docs.docker.com/engine/swarm/admin_guide/#force-the-swarm-to-rebalance ?
    HVJ3R
    HVJ3R --- ---
    KOJA: Ja ti vubec nerozumim a stejne ti nedokazu poradit. Tohle neni use case, ktery bych resil. My v podstate mame desitky dockeru postaveny tak, aby nam kopirovaly produkcni prostredi (akorat misto jednoho kazdyho fyzickyho serveru v produkci, na kterym bezi pet sluzeb, mame pet dockeru).
    Kliknutím sem můžete změnit nastavení reklam