• ú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í
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    URPUTNIK: základ image můžeš vyrobit pomocí debootstrap, a pak případně ručně doinstalovat v chrootu co potřebuješ a pomocí tar udělat image?
    není to moc hezké, ale automatizovatelné to je.

    Create a base image | Docker Documentation
    https://docs.docker.com/develop/develop-images/baseimages/
    URPUTNIK
    URPUTNIK --- ---
    MARTEN: jj, tomu rozumim .. jen mne zajimalo, jestli pri tomhle zpusobu to vyrobi vic vrstev nebo ne .. ze jde vyrobit ze scratch jsem uz studoval, mame totiz v praci jednu hodne archaickou aplikaci v Ccku, co uz nejde pod aktualnima OS zbuildit, ted to bezi na serverovym Ubuntu 8.04, ke kterymu uz jsem nenasel zadnej image, takze jsem to chtel prave vyrabet z kopie filesystemu ..
    ESTEN
    ESTEN --- ---
    MARTEN: vi, ne vim.
    MARTEN
    MARTEN --- ---
    URPUTNIK: Ano. Ale obecne neni dobre se pripojit a z toho udelat image. Pokud pak budes chtit pouzit novou verzi alpine/debian/.... tak je to vpodstate nereplikovatelna vec. Takze pekne vsechno do Dockerfile a ty muzes retezit. Jeden layer je jeden prikaz, proto casto uvidis
    RUN apt-get update && apt-get install vim && apt-get clean
    apod. Protoze tohle udela jediny layer a ne tri. Ale opatrne s tim kdyz tam budes mit balicek kde te zajima verze. Pokud priste buildnes s novou verzi, tak prijde o layery vseho co na tom bylo postaveno.
    Docela se divim, ze vim je hned v zakladu. Alpine se snazi byt co nejmensi, bezne v tech zakladnich neni ani less ani ping. Jinak si muzes udelat i vlastni uplne ten zakladni image, takze nemusis vychazet z existujiciho, ale je to trochu opruz :)
    URPUTNIK
    URPUTNIK --- ---
    MARTEN: btw, vi v alpine je :)
    URPUTNIK
    URPUTNIK --- ---
    MARTEN: aha, to s tim ulozenim po vrstvach je docela dulezita informace, diky. Vlastne to urcuje hierarchii, v jaky by mel clovek ten vysledny image skladat (cim nizsi vrstva, tim obecnejsi a vic reusovana vec)

    co vrstva to jeden prikaz v docker file? a kdyz by ten image vznikl tak, ze pustim nejaky base image, pripojim se na nej pres ssh a nakonfiguruju/nainstaluju, pak z toho udelam image, bude to jedna vrstva?
    MVEK
    MVEK --- ---
    ADM: Ano 192.168.99.1 má být jako adresa hosta, když na hostu běží mock. Volá se URL něco jako http://192.168.99.1:10600/v1/secure/nnnnnn. Ale já si na tu adresu hosta ani nepingnu, pokud fyzický počítač (host) není ve firemní síti, ale je offline nebo třeba doma.

    Ale díky kolegům jsem objevil workaround, i když příčinu problému stále neznáme.

    Stačí do konfigurace pro službu kterou mockuju dát jako endpoint namísto 192.168.99.1 IP adresu, kterou zjistím tak, že se v minikube VM dotážu na ping na název fyzického (hosta) počítače, když jsem v síti, a překladem zjistím IP. Tahle IP asi nebude stálá, ale to tolik práce zjistit jednou denně není.


    Takže pokud mi něco neuniká, přijde mi to na problém v nastavení sítí VBoxu nebo v doménové politice či jiných omezeních našich fyzických pracovních počítačů (protože nechápu, proč by adresa hosta jako 192.168.99.1 byla vidět jen ve firemní síti) a asi nesouvisí s Dockerem jako takovým.


    ADM
    ADM --- ---
    MVEK: jasne, takze ta 192.168.99.0/24 bude adresa virtualboxu host only networking, 192.168.99.100 je adresa toho virtualu s minikube, a ta 192.168.99.1 se tam asi pridava jako adresa hosta. takze kdyz si tu lokalni sluzbu nastartujes na 192.168.99.1, tak ji musi sluzby z toho virtualboxu videt. kdyz to teda funguje, jaky jsou tam zdrojovy adresy requestu na http://192.168.99.1:10600/ ?
    MVEK
    MVEK --- ---
    Samozřejmě nefunguje ani ping z toho virtuálu na tu adresu na hostu, když je host offline nebo třeba přes VPN.
    Koukal jsem, že ten adaptér má nastaveno an hostu:

    Ethernet adapter VirtualBox Host-Only Network #2:

    Connection-specific DNS Suffix . :
    IPv4 Address. . . . . . . . . . . : 192.168.99.1
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . :
    MVEK
    MVEK --- ---
    ADM: Ano, už sám vidím svou špatnou úvahu, že nemůžu si hrát s wget z hostu a myslet si, že stejně je na tom aplikace v kontejneru ve VM ve VBoxu. Ale ano nepopírám, že mé síťové znalosti jsou taky chabé, ve škole to mnou před lety bohužel z větší části jen proteklo.

    Podíval jsem se víc na situaci a:
    VM se vytváří inicializačními příkazy a nástroji, takže při vytváření jsem si svou nevědomostí bordel neudělal.
    1) VBox má dva adaptéry, jeden NAT a druhý VirtualBox Host-Only Ethernet Adapter #2 typu Paravirtualized Network (virtio-net).
    2) Služba běží v minikube ve VBoxu. Poslouchá sama na http://192.168.99.100:30050/, na kterém jí v mém testovacím scénáři posílám SOAP request z hostu. A pak sama (i podle logů) kontaktuje přes POST ten mock na http://192.168.99.1:10600/.
    3) Mock poslouchá na http://192.168.99.1:10600/ a běží na hostu (je napsaný v Javě, volá na poslouchání JdkHttpServerFactory.createHttpServer(new URI("http://192.168.99.1:10600/"), myApplication, true); )

    V bodě 2 služba vytimeoutuje, když je host offline (odpojený kabel, vypnutá wifi...), nebo na VPN nebo např. za mým domácím routerem. Ale funguje v pracovní síti.


    Jak bych mohl ověřit, jak doopravdy ta služba mock kontaktuje, nebo co bych mohl zkusit dál hledat?
    ADM
    ADM --- ---
    MVEK: tak kristalova koule nepomohla, ale je to samozrejme ciste sitovy problem, podle toho co pises to vypada ze docker kontejnery spoustite pod minikube ve virtualboxu. dulezity bude si zjistit jaky networking pouziva ten virtualbox, viz https://www.thomas-krenn.com/en/wiki/Network_Configuration_in_VirtualBox a s tim souvisi ta sit 192.168.99.1/24, ta je kde, na jakym rozhrani

    ted vidim ze pises o proxy, ta se v siti nachazi kde? nedava moc smysl aby se pouzivala externi proxy pro lokalne spustene docker kontejnery
    MVEK
    MVEK --- ---
    DANIELSOFT, MVEK: Dík, no ten parametr se zdá, že ani můj Docker (17.10 klient, 17.12 server) nezná (není v nápovědě), ale možná opravdu na Win chybí. Ale stejně zatím nevím, jak bych to aplikoval, protože já vůbec příkaz docker pro startování a vytváření díky tomu Helmu atd. nepoužívám (ale třeba bych našel někde, jak to protlačit).


    Já ale zhruba příčinu mezitím odhalil, když jsem si zkusil wgetem kontaktovat ten mock. On je problém v našich proxinách. Takže spíš půjdu o dům vedle do nějakého síťového fóra, protože jedna věc je, že defaultně máme nastavenou proxy pro HTTP a HTTPS komunikace, a tu to samozřejmě offline nenajde (a na VPN asi taky ne). Druhá věc je, že vyřazením tohoto nastavení, kdy mi už wget asi kontaktuje mock, mi to stejně stále nefunguje.
    MARTEN
    MARTEN --- ---
    URPUTNIK:
    e) poradne nikde, tooly ktere ti to vizualizuji z existujicich, pokud jde o hierarchyi. Z tech simple treba https://github.com/justone/dockviz . Volumes apod. v readme file s tim jak to nastavit. Ale opet to jde vizualizovat z existujicich co je treba v kterem za volumes. Pokud nepotrebujes popis co je to za volume, tak by mohlo stacit. Trochu mimo, na lokale pouzivam traefik a portainer jako pomocne tooly co bezi porad. Existuje jich vic, tohle mi staci. Neresi hierarchyi, ale portainer z toho neco malo ma.

    e2) merguji, aspon co vim.

    f) vi/vim nebude by default, ale instalovat muzes. Jinak to muze byt vic veci nez jen balicky. Bezne to muze byt treba pridani firemniho repository, nastaveni vpn, pridani monitoring toolu,... Pokud nic takoveho nemate, tak to budou jen ty balicky co pouziva kazdy.

    Velikost bude tak, ze kdyz budes pouzivat alpine a budes mit 50 images, tak alpine zabere velikost jen jednou. Pokud pak z toho 20 images bude pouzivat Java8, tak opet velikostne bude jen jednou. Takze misto bude brat jen vas kod ve vysledku. Koukni klidne na layers nektereho existujiciho image, uvidis jak je to buildene a ktery kolik zabere, vychazet pak muzes z kterehokoliv a jen pridavat nad nej. Fyzicky jsou ulozeny layers, ne finalni image.
    DANIELSOFT
    DANIELSOFT --- ---
    MVEK: hmmm... možná to bude něco jiného, ale já měl před časem problém, že mi Docker ignoroval /etc/hosts na hostitelském stroji

    v mém případě pomohl parametr "--network host" u "docker run", třeba ti to pomůže taky
    MVEK
    MVEK --- ---
    Omlouvám se za lame dotaz amatéra, jsem nucen s Dockerem pracovat jako tester vyvíjené aplikace, a přitom podporu máme strašnou, ale hlavně tento problém omezuje v tuto chvíli jen mě, a jen pokud potřebuji pracovat z terénu, nikoliv v kanclu, takže to přenechat jiným moc nemůžu.

    Řeším, proč mi komunikace z microservice v Dockeru kontaktuje správně mock na 192.168.99.1:10600 jen, když jsem ve firemní síti. Pokud jsem na VPN nebo offline nebo jinde, tak timeout. Přitom na tom 192.168.99.1:10600 poslouchá mock pouštěný z mého počítače (kousek kódu pouštěný přímo v IDE IntelliJ Idea).
    Ping na danou IP adresu můžu udělat kdekoliv a dopadne stejně úspěšně. Komunikace mezi dílčímí mikroservisami také funguje. A z počítače do mikroservis přes jinou soukromou adresu (192.168.99.100) se taky dostanu kdekoliv.

    Nenapadá někoho, kam dál se pošťouchnout, kde pátrat?
    Dodám jen, že tedy nejedeme na čistém Dockeru. Máme tu ještě gokube/minikube, Helm, Kubernetes a minikube VM se vytvoří a spustí ve VirtualBoxu. Instalaci mikroservis pak řešíme přes Helm. Celé prostředí startujeme přes minikube start/stop.
    Workaroundem by pro mě bylo připojit si ten mock jako docker kontejner, který jiný vývojář vytvořil, ale ten neumíme nahrát přes Helm, aby to spolupracovalo. A ano, podle mě je tu pěkný bordel, ale jelikož tomu jen tak rozumět nebudu, tak do toho vrtat nemůžu.

    Možná je to spíš síťová záležitost, ale třeba se tu aspoň dozvím, kde pátrat. V tuhle chvíli se půjdu prát s Wiresharkem, ale jsem v něm amatér, zkusil jsem si v něm něco před mnoha lety.
    URPUTNIK
    URPUTNIK --- ---
    MARTEN: te velikosti jsem se bal u image repository, nas nexus ma aktualne kolem 50gb zbuildenych zdrojaku (mival i 400, nez jsme ho spravne nastavili :) ), kdyz k tomu pridam tu omacku s OS, javou apod .. ale je pravda ze prostor je dneska uz levny a asi to zbytecne optimalizuju dopredu
    URPUTNIK
    URPUTNIK --- ---
    f) mate priklad toho, jaky tooly mate v tom dev image? protoze my si vystacime se sh a vi, ktery predpokladam oba v alpine budou .. ale mozna jsem jenom zvykli na praci v konzoli .. vlastne mozna mc, ten tam asi neni
    URPUTNIK
    URPUTNIK --- ---
    d) v terminologii image, ten z ktereho se vychazi, je 'vyssi', nebo 'nizsi'? abych kladl spravne formulovane otazky :)

    e) jestli a kde drzite dokumentaci, napriklad hierarchie docker image? ted mam treba predstavu ze bude nejaky javovy base image (alpine, java), nad/pod nim bude dev image (aka pridany volume pro lokalni vyvoj, stale jeste staticky image), nad/pod nim produkcni image (ten bude mit v sobe uz konkretni aplikaci a volume jen pro logy) .. jenom textove uvnitr dockerfile? nejaky vhodny UML diagram? treba package? prijde mi ze ted to treba nejak poskladame, ale za rok se nekdo zepta "a proc" a budem to muset znova vymyslet :)

    e) tohle si ted vyzkousim, tak to asi nemusite odpoviat :) zajima me, jestlli vyssi/nizsi dockerfily prepisujou definici volume/portu, nebo se s ni slucuji? aka jestli se da jenom 'pridavat', nebo ji zcela prepisuji? napriklad ten dev image, ktery ma proti produkcnimu volume pridane volume .. jestli muze byt predkem produkcniho, protoze v produkci nechci/nepotrebuju to volume na nahravani aplikaci ..
    MARTEN
    MARTEN --- ---
    URPUTNIK:
    a) Jde oboji. Spravnejsi je balit i s kodem aplikace, duvody presne ty ktere pises. Chces tedy mit verzi stejnou se vsim. Image pouze z balicky je dobry na vyvoj a mountovat git repository. Pro produkci ne, nemusis trefit kombinaci verzi. Velke to nebude, nebo bych se tim v dnesni tobe netrapil. Docker je chytry v tom, ze funguje jako git. Pokud RUN byl stejny v predchozim buildu, tak to pouzije z nej. Vpodstate pak zalezi na poradi v Dockerfile jak to ve vysledku bude velke. Co se nemeni dej na zacatek, co se meni tak jako posledni. Promazat vzdy cache package managementu atd.
    Ad prostredi. Vetsinou se to jede bud pres environment variable nebo mountujes config file. Aplikace bud pouziva ten config, nebo bere z environment, nebo je CMD nastaven na script, ktery z environment vezme promenne a da je do config souboru a pak spusti aplikaci.

    b) Vytvor vzdy image s cislem verze application:1.2.3 a pokud je to aktualni tak i jako latest. Pokud delam balicky pro test prostredi co nepujdou do produkce, datam jim jako verzi timestampu. Ty se pak treba po par dnech mazou.

    c) pokud je to vic technologii, tak bych spolecny base nedelal. Prijdes presne o vyhodu toho co je hotove. To uz bych do toho zapojil treba ansible. Takze budete mit base pro javu ktery vychazi z oficialni Java a prvni command je zavolani nejakeho vaseho base scriptu. Vlastni base je dobry kdyz mas cas to vyladit, vse postavis treba na alpine, vsude mas tooly co pouzivate a na tom delas uz ty drobnosti jako java, apache,... Ale zabere to hodne casu, ve vysledku budou mensi a budou vam vic sedet. Oficialni image maji kazdy jiny pristup jak se configuruji, coz pridava nutnost znat jak ktery funguje, vlastni si udelate at jsou vsechny stejne. Ale neresil bych, hlavne ne takhle na zacatku, pokud teprve s tim zacinate.
    URPUTNIK
    URPUTNIK --- ---
    ahoj, mel jsem zkusenost s dockerem z predlonska, ale tam bylo ciste uzivatelsky .. konecne jsem se dostali k virtualizaci v praci, takze procitam a studuju a rozvazuju, co pro nas plati a co ne ..

    zatim mam napriklad takovehle otazky, ale je mozny ze to spis patri do continuous-delivery klubu

    a) image, ktery bude obsahovat jen "engine", ale aplikaci nahravat az v ramci deploye (u nas napriklad image jenom s tomcatem, pres volume napojit adresar, do nej bude CI sypat aplikace a odkud si bude tomcat spoustet), nebo muzu rovnou balit aplikaci do image, cili pak staci jen nastartovat image a budu mit jistotu ze mi v produkci bezi identicke sestaveni jako treba v testingu..
    zatim se klonim k druhe variante (videl jsem ji z uzivatelskeho pohledu), ma to pro mne 2 hacky - konfigurace pro prostredi musi byt mimo aplikaci (jinak nemuzu pouzit stejny image pro ruzna prostredi), druhak to bude asi docela zrat misto, ne? pokud mi nekde sedi CI server, ktery bude po kazdem commitu buildit aplikaci a vyrabet novy image (ktery obsahuje danou aplikaci & tomcat & javu & alpine :) )? predpokladam ze obvykle je ty stare mazat?

    b) jak oznacujete ten validni image, co vypadnul z CI (tzn treba prosel aut. testy a testovacim deploymentem), pres tag latest? nebo ho radsi nepouzivate (viz duvody) a mate treba nejaky specialni vlastni?

    c) nasel jsem nekde doporuceni, aby vsechny nase image pouzivaly stejny base image .. nejak si nedovedu predstavit, co to znamena pro nas, protoze krom nekolik ruznych jav (takhle se to asi nesklonuje co :) ), tu mame nejaky php, nejaky python, .. pokud budu vychazet ze stejneho base-image, tak se nemuzu oprit o uz hotovy kontejnery, napriklad s java+tomcat, apache+php php a budu si je muset vsechny poskladat rucne.. mozna se to da obejit nejaky dockerfilem, ktery bude fungovat jako wrapper kolem libovolneho jineho (patrne urceneho pres promenne, jestli se teda daji pouzit ve FROM)? nebo mit rucne poskladany image neni takovej problem? mi to prijde jako ze vymyslim kolo ..
    ADM
    ADM --- ---
    SH_PANDA: pokud tam posilas co musis, tak neni zbyti, ja spis poukazuji na to, ze se posila cely adresar kde je umisteny dockerfile, coz muze byt mnohem vic nez je nutny. asi proste predpokladaji, ze dockerfile je umisteny vzdy v rootu projektu
    Kliknutím sem můžete změnit nastavení reklam