• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    Docker aneb přístupný provoz kontejnerizovaných aplikací
    Docker(Hub), Compose, Swarm, boot2docker, DevOps, LXC, ECS, TumTum a jiné buzzwordy
    Bezpečnost v prostředí kontejnerů
    Related: automatizace [ Centralizovaná správa stanic a ostatních prvků v síti konfigurace/inventarizace/instalace/aktualizace/zalohovani ]
    rozbalit záhlaví
    JON
    JON --- ---
    MARTEN: k tomu muzu doporucit tohle skoleni: https://ondrej-sika.cz/skoleni/rancher/

    primo na skoleni jsem nebyl, ale spolupracujeme s Ondrou Sikou a je dobrej. Imo velmi dobre investovanych 6800.
    MARTEN
    MARTEN --- ---
    Mate nekdo vlastni servery a sluzby? Nebo co nekomu hostujete mimo placene cloudy?
    Hledam pro sebe resit pro tooly, CI, pripadne non-prod prostredi. Takze nechci platit za relativne drahy cloud. Ale uz me to nebavi resit pres docker-compose.
    Uz jednu dobu koukam po Rancher, oproti openshift umi pripadne i AWS, GCP apod. Mate s tim nekdo zkusenost? Provozovani 2-3 serveru, rozchozeni cloudu a deploy pres rancher? Pripadne jina alternativa? Nechci kubernetes z cli, jedine s UI, ale Rancher to jeste hezky obaluje, tak se priklanim k nemu.
    GIOMIKY
    GIOMIKY --- ---
    Mozna sem?
    Waydroid
    https://waydro.id/
    FALLENANGEL
    FALLENANGEL --- ---
    VELDRANE: Co je to za svet, ve kterym zijeme ;) Truhlarina, to je prace.
    VELDRANE
    VELDRANE --- ---
    FALLENANGEL: proste se musime smirit s tim ze doba, kdy clovek vysmrknul instalaci oracle db na posledni true64 a byl za velkyho a dobre placenyho borce, je uz bohuzel pryc :)
    FALLENANGEL
    FALLENANGEL --- ---
    VELDRANE: 'takze i tak Te stoji provozovani takovhle platformu nemaly usili.' < to je bohuzel pravda. navic ti ne uplne vzdycky to co jde s openshiftem sedi, takze casto musis tu vec zahodit a postavit si ji sam.
    VELDRANE
    VELDRANE --- ---
    FALLENANGEL: :) Naopak ja mam tyhle technologie rad, protoze i Tebe technicky hodne posunou a neni to vubec nudna prace. Spis sem reagoval na to, ze seniorni clovek v tehle oblasti by imho mel mit nemalej presah a hodne ruznorodejch skillu. Nemusi v nich bejt expert, ale mel by vedet kam se podivat kdyz necemu uplne docdetailu nerozumi a zrovna to potrebuje. A to neni jen o vlastni operations, musis bejt relevatni parner pro vyvojare, management, kolegy... Takze chapu ze najit takovy lidi neni uplne snadny a asi ne levny.

    Jasne muzes si smudlat svoji poddomenu treba monitoring a vic Te nemusi zajimat a asi to taky tak pujde.

    Jinak openshift je fajn a je fakt ze spoustu veci k nemu dostanes, ale stejne je tak imho tretina veci co opravdu potrebujes, takze i tak Te stoji provozovani takovhle platformu nemaly usili.
    FALLENANGEL
    FALLENANGEL --- ---
    VELDRANE: Takze radis se do toho vubec nepoustet, chapu to spravne? :)

    Ale rozumim kam tim miris. Vetsina ops tymu, se kteryma komunikuju, z toho maji hlavu jako patraci balon. Nevim, jestli je to tema vysokejma platama, ale vetsinou jsou personalne poddimenzovany a nemaji uplne cas na vysivani, nebo na ty veci o kterych mluvis ty. Trochu ted vidim vyhody OpenShiftu, kde dostanes spoustu veci zaintegrovanou a chces z toho logicky co nejvic pouzit.
    VELDRANE
    VELDRANE --- ---
    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.
    DANIELSOFT
    DANIELSOFT --- ---
    Já se s Kubernetem poprvé setkal v roce 2016, co se koukám na Wiki, tak je tu od roku 2014, takže nebyl ještě tolik "vyzrálý". Teď jsem teda na jiném místě a dělám něco jiného, ale možná se k němu někdy vrátím, kdo ví.
    FALLENANGEL
    FALLENANGEL --- ---
    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 :)
    VELDRANE
    VELDRANE --- ---
    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
    RUDOLF
    RUDOLF --- ---
    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.
    FALLENANGEL
    FALLENANGEL --- ---
    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?
    SADY
    SADY --- ---
    DWICH: aha, v tom muze bejt rozdil no... zajimava cloudova politika
    DWICH
    DWICH --- ---
    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!
    SADY
    SADY --- ---
    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
    BESH
    BESH --- ---
    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.
    DWICH
    DWICH --- ---
    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?
    MARTEN
    MARTEN --- ---
    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.
    VELDRANE
    VELDRANE --- ---
    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
    Kliknutím sem můžete změnit nastavení reklam