• ú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í
    ADM
    ADM --- ---
    URPUTNIK: v php-fpm docker image (v image pro apache mod_php to bude zrejme obdobne) ten symlink odkazuje na stdout stderr pidu 1 a ten by mel bezet pod rootem (ted si to neoverim), az child workers bezi pod www-data, takze tezko do toho logu budes zapisovat z tech apache workeru. to by mohl byt tenhle problem
    DEFILA
    DEFILA --- ---
    URPUTNIK: SElinux?:)
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: tak aktualni zaver je, ze aplikaci nechame jak je .. akorat pro pouziti ve dockeru, kdyz se vytvari image, misto souboru se podstrci symlinky na /dev/stdout (uplne stejne se to resi v oficialnim php docker image) .. takhle:
    
    RUN set -eux ; \
        cd /app/log/ ; \
        touch app.log ;\
        ln -sfT /dev/stdout app.log ; \
       chown -R --no-dereference www-data:www-data . ;
    

    uvnitr pustenyho image ty symlinky vypadaj stejne, jako ty pro apache access/error:
    root@63f6b1c48b39:/app# ls -la /var/log/apache2/
    total 8
    drwxrwxrwx 2 www-data www-data 4096 May  8 02:37 .
    drwxr-xr-x 1 root     root     4096 May  8 02:37 ..
    lrwxrwxrwx 1 www-data www-data   11 May  8 02:37 access.log -> /dev/stdout
    lrwxrwxrwx 1 www-data www-data   11 May  8 02:37 error.log -> /dev/stderr
    lrwxrwxrwx 1 www-data www-data   11 May  8 02:37 other_vhosts_access.log -> /dev/stdout
    root@63f6b1c48b39:/app# ls -la log/
    total 8
    drwxr-xr-x 1 www-data www-data 4096 May 28 13:55 .
    drwxr-xr-x 1 root     root     4096 May 28 13:55 ..
    lrwxrwxrwx 1 www-data www-data   11 May 28 13:55 app.log -> /dev/stdout
    

    nicmene ve chvili, kdy do nich zkusi php zapsat
    
     if ($f = fopen($logfile, 'a')) {
        fwrite($f, strftime("%Y/%m/%d - %H:%M:%S: ") . $data);
        fclose($f);
        return true;
    } else {
       return false;
    }
    

    tak to spadne
    Warning:  fopen(/app/log/app.log): failed to open stream: Permission denied in ..


    takze, co mi uteklo? :/
    ADM
    ADM --- ---
    URPUTNIK: pokud mas docker logging driver journald, tak teoreticky muzes z jednoho containeru vytahnout 2 ruzny logy s tim ze je rozlisis dle stdout a stderr, logshipping z journald do ES to vetsinou zachova, takze si to muzes podle toho vyselektovat (v kibane treba). cili bys treba php log posilal na stderr a aplikacni na stdout (ale zrovna v oficialni php-fpm image tohle nejde, je tam k tomu v dockerfile nejaky comment), jinak pokud bys oba ty logy michal do jednoho vystupu tak je jedina moznost ten aplikacni log prefixovat. nejjednodussi reseni je proste opravdu mit jeden log z jednoho containeru (stdout), protoze je pak mnohem jednodussi implementace jakehokoli log collection reseni. pokud bude kazdy service logovat ruznym zpusobem tak se to bude obtizne spravovat, zalezi samozrejme o jakem mnozstvi sluzeb se bavime
    DANIELSOFT
    DANIELSOFT --- ---
    co prikaz "docker log" ? ten si pamatuje a vypisuje stdout, pokud vim
    URPUTNIK
    URPUTNIK --- ---
    BLACKOUT: takze ty message na stdout necim prefixujete? nebo v kontextu aplikace to neresite, ale ten, kdo to posila do ES, to prefixuje?

    QUIP: zatim jsou to kusy kontejneru~servis, ale budou hur/lip :) a je to ted do souboru, protoze jde o dockerizaci stare php aplikace, kde nechci delat 2 zmeny naraz - poustet to v dockeru a jeste k tomu menit funkcnost (protoze vedle toho bezi nevirtualizovane produkcni prostredi)
    INDIAN
    INDIAN --- ---
    +1 za ES - pokud to neni naka jednorazova vec a pro ES na danou platformu existuje handler
    QUIP
    QUIP --- ---
    URPUTNIK: Nevim, v jakem prostredi to resis. Jestli mas jeden kontajner, nebo vic... ale co treba logovat po siti do syslogu / rsyslogu atp.? Pak nemusis mit v tom kontajneru zadne logovani do souboru a pritom muzes posilat data z kolika chces sluzeb najednou.
    BLACKOUT
    BLACKOUT --- ---
    URPUTNIK: Osobne idem stylom stdout, a separe debug do kibany.
    Tak nam to funguje cca na 350+ microservice-och (je to pain potom v kibane ale developer lúza sa nestazuje :D)
    ADMIX
    ADMIX --- ---
    URPUTNIK: sypat veci do souboru neni nutne na prekazku, ale nevim jak to funguje s logovacima knihovnama; kubernetes nevim, ale i ten blbej nomad na to mel mechanismus ze ti do kontejneru namapoval treba 100MB tmpfs na logy, ze kterejch jsi jednak moh primo cist, a jednak je shippovat nekam do elastiku nebo podobne, pocitam ze kubernetes na tohle bude mit deployment v podobnym stylu
    URPUTNIK
    URPUTNIK --- ---
    tak novy dotaz :) jedna z best-practice pri psani docker image, je posilat vsechny data/logy misto do souboru na stdout .. coz je samozrejme hezky a neplni se to do image, takze o to clovek neprijde, kdyz je potreba image vypnout .. u nas je napr php aplikace, ktera generuje 3 logy - access log apache, php_error_log a business logy, co si zapisuje sama aplikace ..
    ten oficialni docker php image pise na stdout, access log i php_error_log (ten asi sype na stderr, uplne to nepoznam), ale ty business logy jsou (ted) do souboru ..

    takze kdyz to budem poustet v kubernetim clusteru, muzem budto vsechno posilat do souboru (patrne teda do 1 adresare, at se jednoduse sdili slozka s logstash sluzbou .. v nem pak budou definice pro jednotlivy souboru ..) nebo obracene, vsechno co ted zapisuje do souboru budu sypat na stdout/err .. predpokladam, ze ale v tom stdout se to bude michat, tzn prefixujou se napr ty message?

    nejakou variantu jsem minul? nejaky uz vynalezeny kolo? :) zatim se klonime k tomu sypat to vsechno do souboru (tak je to konckoncu ted pusteny v realnym nevirtualizovanym prostredi)
    URPUTNIK
    URPUTNIK --- ---
    QUIP: jj, rozumim, uz jsem se ptal i v php klubu .. a dospel jsem ke stejnym zaverum, takze diky za potvrzeni!
    QUIP
    QUIP --- ---
    URPUTNIK: S PHP 5.2 mas asi nejvetsi problem v tom, ze se malo kdo zabyval prechodem z 5.2 na 7.x Vetsina tech nekompatibilit zminuje rozdily mezi nejakou posledni vetvi 5.x, takze vetsinou 5.6 => 7.0
    Pokud se budete v te aplikaci stourat, aby fungovala na PHP 7.x, tak ji rovnou testujte na 7.3 (nebo aspon 7.2) 7.0 uz je EOL.
    Tudiz budes muset nejspis hledat nekompatibility mezi 5.2 - 5.6, 5.6 - 7.0 a pak 7.0 - 7.3
    https://www.php.net/manual/en/migration73.php
    https://www.php.net/manual/en/migration53.incompatible.php
    https://www.php.net/manual/en/migration54.incompatible.php
    https://www.php.net/manual/en/migration55.incompatible.php
    https://www.php.net/manual/en/migration56.incompatible.php
    https://www.php.net/manual/en/migration70.incompatible.php
    https://www.php.net/manual/en/migration71.incompatible.php
    https://www.php.net/manual/en/migration72.incompatible.php
    https://www.php.net/manual/en/migration73.incompatible.php

    ...ale tohle neni o Dockeru, to je proste o PHP

    https://github.com/sstalle/php7cc
    https://github.com/gisostallenberg/php-to-7-aid
    BLACKOUT
    BLACKOUT --- ---
    URPUTNIK: U nas to mame robene nasledovne :
    - echo $MTR_PASS | docker login -u="$MTR_USER" --password-stdin $MTR_URL
    - if ! docker pull $IMAGE_FQDN; then docker pull $MTR_URL/$MTR_NEA_GROUP/$CI_PROJECT_NAME:master || true; fi
    - docker build -t $IMAGE_FQDN-${CI_ENVIRONMENT_NAME} .
    - docker build -t $IMAGE_FQDN-${CI_PIPELINE_IID}-${CI_ENVIRONMENT_NAME} .
    - docker push $IMAGE_FQDN-${CI_ENVIRONMENT_NAME}
    - docker push $IMAGE_FQDN-${CI_PIPELINE_IID}-${CI_ENVIRONMENT_NAME}

    Treba to este poladit ale aktualne to postacuje, samotny image sa nahrava na private Quay, kde mame robene checky ci je image "OK". dalej nekonecny release management, helm, openshift.

    Dovod preco to cele take je, je poziadavka vediet hocikedy, hocijake, prostredie dostat do urciteho releasu (ci uz globalne na urovni "PI" alebo minor)

    Co sa tyka release managementu "muze se jich nekolik buildit paralelne atp, takze se neda spolehnout na latest"
    Mame nekonecne python / bash scripty ktore citaju z config suborov ktore vyplna samootna pipeline. (ofc je do toho zapojeny nexus,ansible pre nejake pripady, terraform ked sa jedna o nejake VPS/EPS) atd atd

    Jedina manualna vec ktoru clovek musi urobit, je v gitlabe v danom env. repo urcit aka verzia sa ma deployovat (napr ... pi4.1.1548)

    ale to uz asi zachadam :D
    URPUTNIK
    URPUTNIK --- ---
    tak dalsi, predpokladam ze velmi obvykly dotaz .. mame nejakou aplikaci, ktera pouziva php, ale samozrejme 5.2 .. tak ted zjistuju, co by nas stal predchod na php7, ktery umi oficialni docker image ..
    nasel jsem tohle a tohle .. nejaky dalsi zdroje, co jste potkali?

    buildit si vlastni image od operacniho systemu nechci (kdo ho pak bude udrzovat) a pouzivat cizi privatni co nevypada aktualizovane taky ne ..
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: a jeste jsem nasel parametr --iidfile do buildu, to by mi taky stacilo ..

    diky za reakce!
    INDIAN
    INDIAN --- ---
    URPUTNIK: ja pouzivam job id z Gitlab CI, kde se mi image generujou. Jedinou vadu na krase to ma to, ze to id je unikatni napric vsema projektama, tudiz na sebe primo nenavazujou, ale ke spokojenosti nam staci to, ze je lze diky jednoduchy inkrementaci porovnavat
    ADM
    ADM --- ---
    URPUTNIK: pokud vis, jak ten image otagujes nasledne, udelej to rovnou v build stage, jinak budes mit po naslednym pretagovani v local images 2 image, coz uz budes muset zbytecne nejak resit treba pri mazani.
    pokud ti jde o to, jak unikatne tagovat image a je tam moznost ze se buildi zaroven stejny image na nejakym CI systemu, tak pouzij treba git commit hash, nebo vetsinou mas z CI nejaky unikatni build id, apod.
    tam kde se builduji image je vetsinou neschranujes, takze veskery mezikroky mezi build, push, a pak nejakyho naslednyho mazani local images (treba na zaklade stari) jsou vetsinou zbytecny
    URPUTNIK
    URPUTNIK --- ---
    ahoj, mam dotaz, jak tagujete image? nemyslim tim vycet tagu, ale jak to provadite? jako parametry do docker build? nebo delate cely scenar, tzn 'docker build, docker images | grep, docker tag'?

    ten scenar mi prijde prehlednejsi (misto nekonecnyho docker build radku), ale resim, jak spravne identifikovat ten cerstve vyrobeny image .. ono to totiz muze byt soucast nejaky CI pipeline, takze tam tech imagu bude videt vic, muze se jich nekolik buildit paralelne atp, takze se neda spolehnout na latest .. a tak mne napadlo, ze si pred spustenim docker build vygeneruju unikatni hash, jim to otaguju zaroven s buildem, a pak tenhle hash pouziju pro filtrovani v 'docker images' .. je to nesmysl? da se to udelat jednoduseji? pac takhle mi to bude do privatni repo sypat i ten unikatni tag, ne?
    RAGNAROK
    RAGNAROK --- ---
    RAGNAROK:
    uz asi vim musim pouzit funkci:
    ips, err := net.LookupIP("receiver")
    RAGNAROK
    RAGNAROK --- ---
    ADM
    delam to v go:
    potrebuju nejak dostat adresu do funkce net.WriteToUDP(b []byte,addr *UDPAddr).
    Zkousel vsechno mozny porad mi to psalo write udp [::]:3000->%UDP:2000: sendto: cannot assign requested address"
    ADM
    ADM --- ---
    RAGNAROK: ano, stalo by za to hodit si tam explicitne networks (kdyz nepouzijes, melo by byt implicitni, ze se vytvori bridge network, kde jsou vsechny sluzby z konkretniho docker compose). na ty ip adresy z toho prikladu zapomen, staci ti pouzivat pro komunikaci mezi kontejnery dns servicename
    Kliknutím sem můžete změnit nastavení reklam