• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: pro mysql:5.7 to totiz funguje "dle ocekavani" ..
    URPUTNIK
    URPUTNIK --- ---
    ahoj, uz se zase placam cely den na stejnem miste , asi neco prehlizim :) mejme defaultni mysql:8 image z docker hubu .. kdyz ho pustim lokalne, s parametry:
    
    $ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=pw -e MYSQL_USER=user -e MYSQL_PASSWORD=pw -e MYSQL_DATABASE=weborder -d mysql:8
    

    tak se databaze i uzivatel spravne zalozi .. kdyz totez ale presypu do yaml souboru pro kubernetes deployment, tak ve spustenem image to neni, ani databaze, ani uzivatel .. tusite nekdo proc?

    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: weborder-mysql
      namespace: dev10
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: weborder-mysql
      strategy:
        type: RollingUpdate
        rollingUpdate:
          maxSurge: 1        # how many pods we can add at a time
          maxUnavailable: 1  # maxUnavailable define how many pods can be unavailable during the rolling update
      template:
        metadata:
          labels:
            app: weborder-mysql
        spec:
          containers:
          - image: mysql:8
            name: weborder-mysql
            env:
            - name: "MYSQL_ROOT_PASSWORD"
              value: "pw"
            - name: "MYSQL_DATABASE"
              value: "weborder"
            - name: "MYSQL_USER"
              value: "user"
            - name: "MYSQL_PASSWORD"
              value: "pw"
            ports:
            - containerPort: 3306
              name: mysql
         ..
    


    mozna souvisi s https://dev.to/yoshiyukikato/tips-to-use-mysql-80-on-kubernetes-m3l ?
    ADM
    ADM --- ---
    oprava: pokud mu ten php skript pobezi jako root, tak by to mel zalogovat (ale overovat to nebudu)
    ADM
    ADM --- ---
    DEFILA: tady se ale bavime o filesystemu v containeru, neni mi znamo a zatim jsem se nesetkal s image (z tech beznych oficialnich), ktera by mela nastaveny selinux labely (a pravdepodobne by byly neucinny). presah z containeru do filesystemu hosta, tak tam samozrejme plati politika hosta. ano, rhel ma selinux politiku pro docker, takze z kontejneru si i na explicitne bind mountovany adresare nesahnes, ale to s tim prilis nesouvisi

    DEFILA: tak to prave naopak, to je hlavni filozofie kontejnerizace aplikaci, ze ma v containeru pid 1 a nebezi pod nejakymi proces managery. dale vetsinou kazda aplikace umi logovat, rekneme aspon do souboru. jako priklad dejme tomu ten webserver chci access log, tak nastavim logovani do konkretniho log souboru, pro jednoduchost v imagi vytvorim ten symlink soubor.log -> /proc/self/fd/1 a hotovo. jak si to interne prebere aplikace forkujici child workery neni az tak podstatne, access.log logovat umi, vyrizeno. problem nastava, pokud chce logovat z toho php, tam to ze skriptu proste do stdout a stderr pid 1 proste nedostane, tam je jedina moznost pouzit tu zkratku php://. dockerd cte log pouze z pidu 1 beziciho containeru
    DEFILA
    DEFILA --- ---
    ADM:
    tohle neni uplne pravda, pokud nevypnes security politku, tak ma prednost predevsim; zkus si nekdy pustit i jednoduchy Apache httpd na RHELu, kde je SElinux zapnuty(nebo na DEbianu s apparmor); v nejakem, 'custom' adresari -> nic ti nepojede bez ohledu na to, zda jsi root; budes muset menit labely na filech, abys to mohl pustit
    DEFILA
    DEFILA --- ---
    ADM:
    pokud netlacis jinak, tak mas v contejneru tvoji aplikaci ako pid 1 ..., coz je proste spatne, musis si ten kontejner ohnout, aby se tohle nedelo
    ADM
    ADM --- ---
    problem je v tom, ze log dostane pouze z pidu 1, a z potomku pouze pokud si to ty potomci resi, ze to zaloguji prostrednictvim parenta. prava typu filesystem, apparmor, selinux v tom podle me nehraji roli, on to proste do ty pipe nedostane
    ADM
    ADM --- ---
    DEFILA: njn ted se divam, ze on v tom vypisu stale ukazuje shell spustenej v ty imagi jako pid 1, takze tam je to samozrejme /dev/pts/0, kdyby ukazoval stdout toho apache, tak tam je to odkaz /proc/1/fd/1 -> pipe:[20481576] odkud si to cte dockerd do logu, a tam to samozrejme nezmeni
    DEFILA
    DEFILA --- ---
    DEFILA:
    stare ale stale hezke Danovo povidani o libpod
    tedy pokud je tvuj problem zpusobeny security politikou Linuchu :)

    duvodu muze byt spousta, rozhodne nemem prava v /proc/ :D
    DEFILA
    DEFILA --- ---
    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
    ADM --- ---
    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
    URPUTNIK --- ---
    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
    ADM --- ---
    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
    URPUTNIK --- ---
    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
    ADM --- ---
    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
    URPUTNIK --- ---
    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
    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
    Kliknutím sem můžete změnit nastavení reklam