FALLENANGEL: U nas sme hledali nakoho seniornejsiho na ocp/k8s k nam do tymu s opravdu tucnym referal bonusem (nemuzu rict podrobnosti) a rok ta pozice zustala neobsazena. Nedavno k nam nastoupil sikovnej klucina ale stejne bude trvat nez to do sebe natlaci. Ono uz tohle zkratka neni o tom nainstalovat a zkonfigurovat par linuxovejch serveru. Mluvim o praci na rkzsahlym on-premu

FALLENANGEL: Tak je dost otázka co chtějí. Jestli je to manged EKS od cloudu nebo to K8s si postavili sami. Pak je otázka co tam máš dělat, jestli děláš SRE/DevOps nebo něco jinýho. Obecně Operations nejsou špatně placený, protože spoustu lidí to táhne spíš k dev a pak ti často práce končí mergem do develop a co je dál, už tě moc nezajímá, kromě konzumace stacktrace. V menších firmách si to ošaháš všechno, ve větších musíš být v operations či někde u backendu. A pak je otázka co je přitažený za vlasy:-) Jestli je to US firma nebo česká. Češi maj senior engineering u 120k. US/banky mají rate daleko vyšší. Plus ta hloubka znalostí kolem EKS se dost liší, né každý musí řešit networking mesh, EKS u AWS má svá specifika - tak se ta cenová hladina pohybuje podle potenciál versus aktuální znalosti. A asi bych taky čekal, že spousta firem je ještě ve fázi před K8s a potřebují někoho, kdo to rozjede.

Narazil jsem ted na jednu takovou zajimavou vec. Vyfiltroval jsem si v Jobsech inzeraty, ktery poptavaji znalost Kubernetu:

Nabídka práce Praha – Jobs.cz
https://www.jobs.cz/prace/praha/?q%5B%5D=kubernetes&locality%5Bradius%5D=0

A priznam se, ze ty rakety co tam nabizi mi prijdou dost pritazeny za vlasy. Skoro to vypada, ze Kubernetes je stale dost okrajova znalost, ale firmy to proste chteji. Mate nekdo nejakej blizsi prehled jak je to na ceskym trhu?

DWICH: aha, v tom muze bejt rozdil no... zajimava cloudova politika

SADY: Na to jsem narazil, kdyz jsem vcera hledal ty tokens a to podle vseho nabizi Bitbucket jen v server verzi, ne jeho cloud verze.

Kdyz jsem to chtel najit pro Bitbucket cloud, tak jsem se dostal sem, kde pisou, ze to v cloud verzi neni
Personal Access Token for Bitbucket Cloud?
https://community.atlassian.com/t5/Bitbucket-questions/Personal-Access-Token-for-Bitbucket-Cloud/qaq-p/677663

Mozna neco prehlizim.

BESH: Build args predavam, pro secrets me to nenapadlo, dalsi dobrej tip, dikes!

DWICH: proste personal token, kde ta persona je robot co ti buildi appku, tam si expiration nastavis sam

Personal access tokens | Bitbucket Data Center and Server 7.16 | Atlassian Documentation
https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html

Díky všem za rady! Ten ssh klíč je jednoúčelovej, čistě pro čtení z toho repo a na nic dalšího se nepoužívá. Namountovat ho mě nenapadlo, díky za tip.

S multistage počítám. Nicméně i když půjde o multistage, tak stejně neodpadne ta nutnost dostat ze secret managera ten klíč do image, ať už přes COPY nebo mount. Je to tak?

Ten balíček z Bitbucketu potřebuju přidat v poslední fázi instalace aplikace (tzn. v posledním kroku multistage). Z toho mi vychází, že bych za tímhle posledním krokem měl udělat ještě jeden opravdu-poslední krok, do kterého přenesu sakum-prdum instalovanou appku (tzn. nezkopíruje se klíč). Je to tak?

DWICH: obecne nevidim problem mit nekde ssh klic, problem vidim v tom co s tim ssh klicem muzes delat. Jinymi slovy spis zalezi na tom jak silna prava jsou prirazena entite, ktera se autentizuje pomoci toho klice. Totez plati i o tokenu. Navic je ímho v tomhle pripade bezpecnejsi ssh klic nez token, kterej muze obsahovat spoustu readable informaci, ale asi bude zaelzet i na tokenu.

Zaznel tu i termin “secret” v kubernetes. Secret neni zas tak secret :) protoze je to pouze zakodovana nejaka imformace (klic, cert, heslo atd) v base64 - nic vic nic min. Pokud chces nejakou vyssi formu bezpecnosti, pak je na zvazeni treba nejakej vault, otazka je jak potom dostat automaticky data z toho vaultu.

Osobne bych sel cestou multistage jak Ti radi King

DWICH: ja prave nevim jak v bitbucketu - to prostredi nepouzivam a nemam rad.

JON: Na to jsem nenarazil a klidně si nechám napovědět. Co jsem v rychlosti prošel, tak mi vyskočilo tohle
Use OAuth on Bitbucket Cloud | Bitbucket Cloud | Atlassian Support
https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/
kde access token má platnost dvě hodiny a novej získáš přes OAuth2

Uložit v secret manageru ssh klíč nebo credentials pro získání access tokenu a jeho následný použití mi přijde podobný, možná trochu složitější s tím tokenem. Nebo mi něco uniká?


RAGNAROK: Díky za tip, nemám vyzkoušeno, mrknu na to.

.netrc file

DANIELSOFT, KING: Obojí mám vyzkoušený, tak snad cílovej setup nebude složitější. Build bude probíhat v GCP v Cloud Buildu, tak to zkusím napojit na tamní secrets (ne na kube secrets).

Díky!

DWICH: v Kubernetes je něco, co se jmenuje "secrets" a je přesně k tomuto: detaily si nepamatuju, protože jsem na tom dělal v roce 2016. možná je něco podobného v Compose či menším orchestrátoru, pokud je Kubernetes overkill, ale můžeš se u nich podívat, jak to mají udělané

Zdravíčko vespolek. Mám Dockerfile, v něm pouštím pip install -r requirements.txt a v něm je jeden balíček, co je na na Bitbucketu. pip si zavolá git, ten udělá git clone a balíček nainstaluje. Potud OK. Ten git ale potřebuje ssh klíč, aby se mohl Bitbucketu ověřit.

Ten ssh klíč můžu do Dockerfile zapsat, nechat proběhnout instalaci a pak ho smazat. Abych ten klíč do dostal do Dockeru, mám COPY, jenže to COPY může číst jen v rámci adresářů, kam může Dockerfile. A tím se dostávám k problému - kde by ten ssh klíč měl být uložený? Resp. jaké máte best practices, jak instalovat balíčky z privátních repos do dockerů?

Diky za feedback, kritiku snesu :)