FALLENANGEL: Nedobre se na to divas :). Je potreba si uvedomit, ze v enterpise prostedi Te k8s vlastne moc nezajima, to co je dulezity jsou integrace. Chces treba aby ten cluster mel nejak resenej access management, byl integrovanej s adckem apod. Coz znamena uz mit slusny povedomi o tom jak ad funguje, jak na nej naroubovat oidc identity providera apod. Chces mit proviznovany luny z nejakyho pole pres csi, tzn mel bys vedet neco o tom jako funguje nfs nebo proviznovani lunu v san. Prostedi to bezi na nejakyn vmwaru, mel bys mit povedomi o tom jak ta virtualizace funguje, proc cpu pinning a proc ne, mel bys cca mit povedomi o hw, o tom jak se linux chova, o sharovani zdroju, moznym tieringu, memory mgmt - protoze kazda aplikace chce neco jinyho atd apod. Resis nejak monitoring, centralni logovani, ci/cd, tracing. Resis jak udelat ingress, aby to davalo smysl. Atd. dale apod. Zadny veci nikde neklikas, na vsechno pises ansible/helm, vlastni tooly skripty. Jasne treba openshift nebo public cloud Ti se spoustiu veci pomze, ale i tak imho dalsich x sracek resis. Do toho delas operations vyvojovem tymum, tu nekomu blbne jeho api, tcpdumpujes, vysvetlujes, ses nasranej. A to nepocitam to ze sposta tech technologii je novejch a psal je nakej vysmahlej hipster na zachode cvut po celotydeni parbe.

Hele ja ted treba makam na projektu apigw, protoze chcem urcity veci po autentizaci, tak ji stavime na nginxu. Moje prace obnasi udelat si vlastni buile (dockerfile), ne uplne trivialni helm chart, vymyslet samotnou konfiguraci, programovani v javascriptu hooku na oidc auth codeflow, psani lua skriptu pro nginx (tam uz fajn mit vcelku slusnou znalost toho jak nginx funguje uvnitr), psani toolu v golangu, teorie kolem distribuovanejch cache apod... Do toho meetingy, skoleni kolegu, vysvetlovani.

Jako driv sem spravoval svou blade farmu, odmakal sem si par ticketu a pak celej den cucel na net nebo honil ltspice simulace (paac me to zajimalo). Ja si nestezuju, jen podotykam ze it jako obor se hrozne promenil a kdyz chce tomu clovek fakt rozumet (protoze ho to treba bavi) tak tim stravi nemalej cas.

RUDOLF, VELDRANE: To je docela zajimavy. Cekal bych, ze Kubernetes uz bude dost proflaknutej. Preci DevOps a kontejnery jsou tady uz cekem dlouho. Ale dobre pro nas. Porad je to zrejme skill, do kteryho se vyplati investovat :)

DWICH: Pokud potrebujes nejakou hodnotu jen pro nejakej build step, tak lze dodat `docker build --build-arg MY_SECRET=abcd`. Ta hodnota pak nebude ve vyslednem image persistovana. Takovyhle args se daji v CI obvykle narvat pres nejaky pipeline variables.

VELDRANE: Tak do multistage bych sel i z duvodu velikosti vysledneho image. I kdybych nepotreboval zadny klic apod., tak stejne by to byla spravna cesta.

DWICH: Ale jinak pokud ti jde i jen o klic, tak ho muzes pri buildu mountnout do ~/.ssh/.... (podle toho odkud se defaultne bere) a bude ti pak fungovat. Zadne copy. Ale rozhodne je lepsi pouzit multistage. V prvnim si delat co chces a finalni ma jen stazene soubory a pripadne uz i zkompilovane. Finalni image by pak uz nic takoveho nemel delat - v RUN z duvodu velikosti a poctu layers, v CMD kvuli rychlosti startu containeru.
I kdyby si ho tam dostal pres COPY a pak smaznul, tak pozor, porad tam zustane v jednom z layeru a lze ho z toho bez problemu dostat a zneuzit.

DWICH: nestaci na ten bitbucket nejaky token pro read-only access misto ssh klice?

DWICH: na tohle bych pouzil multi-stage build (https://docs.docker.com/develop/develop-images/multistage-build/) kde v prvnim kroku se vse sthne a nainstaluje a v druhem pak uz nebudou potreba ty secrets ani veci jako git

MORTAELTH: A je to taky o rychlosti uvolnovani novych verzi, kdy v ramci microservices jsi schopnej byt mnohem rychlejsi, nez u monolitnich aplikaci.