Docker a kontejnery

DEFILA --- --- 20:33:46 28.5.2019

ADM:
hu!
ne - tam maji pristup kerlen 'procesy' to, ze je vlastni root, je naprosto vporadku; takhle pak vznikaji exploity, kdy se ti z kontejneru nekdo pres shell dostane na hostovaci VM ...

URPUTNIK:

aha :)
SElinux je standartni security polic na RHEL(Fedora) based systemech, kazdy file(tedy prakticky vse, vcetne socketu a portu....) ma svuj stitek (label) vylistovatelny pres ls -lZ(Z pro Selinuch); pokud se tva aplikace snazi zapsat nekam, kde neni prirazeny spravny stitek, tak ji to kopne pryc bez ohledu zda je root nebo ne

dle tvych prispevku jsi na Debianu - ten tlacii apparmor, pokud si dobre pamatuju(nejsem uzivatelem Debianu)

ADM --- --- 20:09:50 28.5.2019

1 odpověď +1

URPUTNIK: no a ten /proc/1/fd/1 a i /dev/pts/0 vlastni root, takze tam nezapises. muzes si tam zkusit zmenit prava z toho kontejneru v shellu, a pak otestovat zda zalogujes s aplikace (tak jak to mas puvodne), melo by to jit, ale tvuj problem to nevyresi, musel bys ty prava upravit po spusteni kontejneru

URPUTNIK --- --- 17:23:30 28.5.2019

1 odpověď

ADM: ah, pardon, jsem natvrdlej .. ale je to stejne akorat symlink do /dev/pts, ktery ma root

root@0826b2dc6932:/usr/local/php# ls -la /proc/1/fd/1
lrwx------ 1 root root 64 May 28 15:06 /proc/1/fd/1 -> /dev/pts/0

problem s primym pouzitim php://stdout mam v tom, ze to znamena upravit zdrojak aplikace (coz nechci, aby se nam nerozjizdela codebase) .. asi to holt budu v ramci buildu prepisovat na stdout, tech mist jsou nastesti jednotky :)

diky moc za popostrceni!

ADM --- --- 17:08:00 28.5.2019

1 odpověď +1

URPUTNIK: davas tam furt *self*, coz je proces toho shellu, ne apache

ale fopen('php://stdout', 'w') - tohle je spravne reseni, timhle to php samo protlaci do parent procesu (toho pid apache)

URPUTNIK --- --- 17:05:03 28.5.2019

1 odpověď

URPUTNIK:


root@aa553164e3bf:/var/www/xmlrpc# ls -la /proc/self/fd/1 
lrwx------ 1 root root 64 May 28 15:02 /proc/self/fd/1 -> /dev/pts/1
root@aa553164e3bf:/var/www/xmlrpc# ls -la /dev/pts/1 
crw--w---- 1 root tty 136, 1 May 28 15:02 /dev/pts/1

kazdopadne mi ted nedava smysl, proc tohle funguje:

fopen('php://stdout', 'w')

protoze php://stdout interpretuje/obaluje apache?

ADM --- --- 17:01:38 28.5.2019

URPUTNIK: nene ten vypis nic neznamena, podivej se na /proc/1/fd/*.
v ty oficialni image je to nastaveno jako log pro apache a pro nej to funguje, z php kodu tam imho nezalogujes, pokud to nejde nastavit v konfiguraci mod_php

URPUTNIK --- --- 16:57:01 28.5.2019

3 odpovědi

DEFILA: nejsem admin, takze to budes muset asi rozvest :) mne ty symlinky prijdou stejne nastaveny, jako pro ten apache, kde ale fungujou :[ kazdopadne phpinfo() zacina s

Linux 63f6b1c48b39 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64

open_basedir je prazdny a safe_mode tam neni, protoze php7+ ..

ADM: aha! to zni logicky


root@aa553164e3bf:/var/www/xmlrpc# ls -la /dev/st*
lrwxrwxrwx 1 root root 15 May 28 14:52 /dev/stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 May 28 14:52 /dev/stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 May 28 14:52 /dev/stdout -> /proc/self/fd/1

predpokladam, ze poustet php pod rootem bude security dira jako krava, co? :) zeptam se nasich adminu .. diky!

ADM --- --- 16:53:21 28.5.2019

1 odpověď +1

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 --- --- 16:30:04 28.5.2019

1 odpověď +1

URPUTNIK: SElinux?:)

URPUTNIK --- --- 16:18:12 28.5.2019

2 odpovědi

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 --- --- 12:40:19 7.5.2019

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 --- --- 12:34:47 7.5.2019

co prikaz "docker log" ? ten si pamatuje a vypisuje stdout, pokud vim

URPUTNIK --- --- 12:22:36 7.5.2019

1 odpověď

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 --- --- 11:25:14 7.5.2019

+1 za ES - pokud to neni naka jednorazova vec a pro ES na danou platformu existuje handler

QUIP --- --- 11:11:45 7.5.2019

1 odpověď +1

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 --- --- 23:36:50 6.5.2019

1 odpověď +1

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 --- --- 17:15:33 6.5.2019

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 --- --- 15:16:16 6.5.2019

4 odpovědi

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 --- --- 10:04:07 29.4.2019

QUIP: jj, rozumim, uz jsem se ptal i v php klubu .. a dospel jsem ke stejnym zaverum, takze diky za potvrzeni!

QUIP --- --- 15:10:23 27.4.2019

1 odpověď +1

BLACKOUT --- --- 21:05:02 26.4.2019

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

Kliknutím sem můžete změnit nastavení reklam

přezdívka
heslo

pamatuj si mě
registrace
ztracené heslo?