• ú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í
    RUDOLF
    RUDOLF --- ---
    RUDOLF: tak moje idiocie - ofiko přístup:

    $ ssh -i <path-to-ssh-key> -NL localhost:2374:/var/run/docker.sock docker@<ssh-host> &
    $ docker -H localhost:2374 info
    ADMIX
    ADMIX --- ---
    2 odpovědi
    RUDOLF: S dockerem jsem se tak daleko nedostal, ale nema to nahodou nejaky API do kteryho bys ten deployment poslal?
    RUDOLF
    RUDOLF --- ---
    2 odpovědi
    jedete někdo v docker for aws?

    Potřeboval bych z jenkinsu co běží mimo cílový swarm, poslat deploy do swarmu.

    Napadá mě:
    a.) připojit docker co běží na tom jenkins serveru přes join-token do swarmu jako manager, tj. jenkins by mohlo posílat joby přímo do swarmu

    b.) připojit docker --tlsverify --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem -H=$HOST:2376 version (ta version se mi nezdá), nebo to vložit do env. prostě dělat docker service update --image -- ale nějak jsem zmatený, jaký klíče ten docker manager vlastně použil.. takže je neumím vytvořit: https://docs.docker.com/engine/security/https/

    c.) nejšíleněnšjí mi přide ssh na daný management stroj a tam prostě docker service update --image pustit lokálně..

    díky
    MARASAN
    MARASAN --- ---
    MARASAN: vyreseno: [ MARASAN @ Network and host security - firewally, exploity, bugy, vulnerability, incidenty a vse o pocitacove bezpecnosti ]
    MARASAN
    MARASAN --- ---
    1 odpověď
    mam problem s LXC na Debian Stretch, pri lxc-create mi na serveru vzdycky skonci kvuli GPG overeni image:
    $ lxc-create -n testerka -t download
Setting up the GPG keyring
ERROR: Unable to fetch GPG key from keyserver.
lxc-create: lxccontainer.c: create_run_template: 1297 container creation template for testerka failed
lxc-create: tools/lxc_create.c: main: 318 Error creating container testerka

    Pridam-li parametr --no-validate, vsechno probehne ok. Nez jsem zacal konfigurovat server, rozjel jsem si LXC doma ve virtualu taky na Debian Stretch ve VirtualBoxu, kde mi lxc-create chodi bez problemu. Cili pokud pristupuje na stejny key-server (predpokladam, ze ano), tak nekde bude problem, ale absoilutne nemam tucha kde a v cem. Virtual doma je za NATem od UPC a dalsim NATem myho routeru a dalsim NATem pro VirtualBox, server je primo v siti s pevnou IP.

    Firewall je off, resp. je tam nejaky nastaveni pro lxc-net (asi dnsmasq):
    # iptables -L -v -n
Chain INPUT (policy ACCEPT 15505 packets, 34M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
    0     0 ACCEPT     udp  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      lxcbr0  0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  lxcbr0 *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 10847 packets, 6737K bytes)
 pkts bytes target     prot opt in     out     source               destination



    Popravde jsem fakt zmatenej, nic jinyho nez uvedeny --no-validate se mi vygooglit nepodarilo. Nenapada vas neco?
    ADMIX
    ADMIX --- ---
    ADM: To je jednoduchej bind mount, abys moh pustit vedle svy aplikace nakej filebeat nebo podobne - Nomad jako takovej nejaky sofistikovany logovani neresi (umyslne).
    Ale tusim ze to ted v poslednich verzich umi ty logy premigrovat, pokud treba drainujes ten node - nejsem si jistej :)
    ADM
    ADM --- ---
    1 odpověď
    ADMIX: nj, ale jak pak nomad resi kdyz to bezi na ruznych nodech (za loadbalancerem)?
    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.
    Kliknutím sem můžete změnit nastavení reklam