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

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

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.

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)

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: 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

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: 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

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

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

RAGNAROK: zajisti si, aby receiver poslouchal na wirldcard IP, pak se k nemu sender pripoji normalne na 'receiver:port'. links vyhod, ports vyhod taky, pokud teda nepotrebujes pristupovat na receiver odjinud nez ze sender.

RAGNAROK: na tohle je obecne nejlepsi mit nejakej MQ broker mimo, ale v tvym pripade bych rek ze potrebujes bridge a ne localhost, pac ty kontejnery localhost nesdili