• ú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í
    MARTEN
    MARTEN --- ---
    REFLEX: Nabidnu jeste za mne lepsi reseni. Co takhle to schedulovani resit uz na hostu? Pokud pouzivas kubernetes (da se pouzit i s docker-compose), tak je tam primo command schelule (cron line). Pak pouzijes php image a jen zmenis command. Pokud mas jen docker compose a uvnitr cisty docker, tak koukni na https://strm.sh/post/cron-tasks-inside-docker/ . Predpokladam ze container je udelan jako dind. Pokud by si bindoval nektere zarizeni ze serveru, mohlo by to byt tezsi, ale to nejspis nedelas. Nevim o tom, ze by primo vanila docker mel moznost schedulovani.
    ADM
    ADM --- ---
    REFLEX: stejny kontejner jsme delali tak jak jsem psal, vyhnul bych se udrzovani 2 imagi se stejnym php kodem
    REFLEX
    REFLEX --- ---
    MARTEN: cron vola klasicky symfony command "php bin/console app:..."
    MARTEN
    MARTEN --- ---
    ADM: Neni nejlepsi. Je spatna z pohledu dockeru, kde by mela bezet maximalne jedna sluzba v containeru. Ale pokud nepotrebuje vystup logu a healthcheck na cron, da se to pouzit. Oddeleni ma jak jsem psal minimalne vyhovu v tom ze se to da skalovat.
    Jina vec je, ze docker image byl mel byt asi dost jiny. Nepotrebuju v nem php-fpm. Nemusim potrebovat nektere knihovny a teoreticky i php kod muze pro cron byt uplne jiny nez pro web aplikaci (assets, presentery,...). Plus cron muze spoustet i jine procesy nez php (java, python,...). Ale to bez znalosti projektu nelze odhadnout.
    Ale pokud, tak bych to komplet oddelil, klidne mel base image ktery ma pouze php a knihovny co budu potrebovat a pak jeden s php-cli a druhy s php-fpm a daval do nich ty soubory, ktere potrebuju.

    REFLEX: Radsi dva containery. skalovani, omezeni resources (cron nebude potrebovat tolik co navstevovany web), nejspise jiny network,....
    Zalezi co ten cron ma taky volat. Nejaky php script z aplikacniho kodu? Pro jednoduchost muzes udelat ty dva entrypointy jak pise ADM. Pokud cron bude delat vic veci a potrebovat i jine balicky, vlastni image.
    ADM
    ADM --- ---
    MARTEN: to je spatna moznost. rozdilny entrypoint znamena jeden radek navic v tom docker-compose u container s cronem, to php pouzije defaultni z image
    MARTEN
    MARTEN --- ---
    ADM: Jeste je moznost mit jeden container a tam mit spustene jak php tak crond. Neni potreba mit rozdilne endpointy.
    Ale nevyhoda tohoto pristupu je skalovani. PHP aplikaci chci skalovat, ale cron nejspis ne.
    ADM
    ADM --- ---
    REFLEX: pridas cron do cointaneru s php, a spustis ho jako samostatny container s jinym entrypointem crond (tzn. mas porad jednu docker image ve ktery je php i crond, a spustis je s ruznymi entrypointy)
    REFLEX
    REFLEX --- ---
    je nejaka easy way jak rozbehat cron v dockeru?

    produkce jede pres docker-compose

    takze muzu:

    1) pridat cron primo do containeru kde mi jede PHP
    2) mit container vedle ktery bude volat ten jiny container, ale to vlastne nevim jak funguje :D
    INDIAN
    INDIAN --- ---
    FYI na CI/CD tu je specializovanej klubiki [ Continuous integration, App Deployment ]
    MARTEN
    MARTEN --- ---
    MLEKAR_STEIN: Predavani mezi jobama je tam taky, je na to trigger plugin. Ale je to teda ze musis triggerovat z jednoho jobu. Ne ze jeden bezi kazdy den a o vikendu chci spustit jiny job, ktery vezme parametry z jineho posledniho buildu. Ale zase jenkins ma hezke a jednoduche api, takze by se slo zeptat na latest build a vytahnout si parametry.
    Nebo... spustit trigger a mit at se spustenim ceka na vikend.
    Pokud jsem dobre pochopil problem.
    Mame treba projekt kde je asi 20 microservice. Kazda ma svuj CI. Jednou denne se spousti e2e testy. Vezmou se posledni buildute verze, kde vse proslo spravne. To se nasadi pres openshift na testovaci prostredi, spusti se testy. Kdyz je vse ok tak se otaguje ze tahle kombinace se muze nasadit.
    Klidne napis do posty, kdyby si chtel. Treba by me napadlo reseni, pokud si na jenkins nezanevrel :) A pokud to neumi, tak groovy script by tohle zvladnul, kdyz ne, tak vlastni plugin :)
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    MARTEN: ja myslel sdileni nejakych dat mezi ruznymi buildy, jako ze potrebuju vedet jakou verzi mi posledni build vyrobil. treba ze to je 1.2.3. anzto jinej task na zaklade toho udela neco jinyho. a je potreba to mit jako samostatne tasky, protoze task 1 vyrobi treba nejakou image, ktera se moc sasto nemeni a task 2 na zaklade tehle image neco vyrobi dalsiho a jak potrebuju vedet jaka byla poledni verze. a neprisel jsem na to, jak to predat nejak hezky. a tagovat to latest neni moc reseni, protoze task 1 ve skutecnosti dela veci vic verzi a ja potrebuju vedet, ktery posledni verze to jsou a spravne je pouzit.
    to s tim spoustenim od pulky jsem nejak minul. diky.
    RATTKIN
    RATTKIN --- ---
    tak za 3h instalace nového VM, v něm gitlab a Runner s dockerem.
    zbytek dne jsem zabil pokusem udělat build přes ci (gut) a push do repo (nicht gut)
    dík
    MARTEN
    MARTEN --- ---
    MLEKAR_STEIN: Ad jenkins: posouvani artifactu je bez problemu. Pokud je to v jednom containeru, tak samo od sebe. Pokud na kazdy step je jiny container, tak staci jen oznacit ktere soubory jsou artefactem. Nemusis resit nic sdileneho.
    Jenkins pro stepy podporuje i spusteni treba od pulky. Takze pokud na zacatku mas build, pak testy atd. Tak muzes priste buildnout treba jen posledni step a vzit jaky byl stav z posledniho buildovani.
    Jenkins je urcite slozitejsi, ale taky toho umi mnohem vic a da se mnohem lip rozsirovat, pokud je potreba.
    Vlastne ani nevim, jestli gitlab umi treba matrix buildovani, coz ne kazdy oceni, ale muze se hodit treba na e2e testy.
    Za mne velka vyhoda jenkinsu je taky v tom, ze je mu jedno kde je repository. Pokud se naucim gitlabci a pristi projekt bude na necem jinem, tak s tim nic neudelam.
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    RATTKIN: jak pise indian, GitlabCI
    me osobne na tom prijde dobry to, ze je to predne v jednom s repository
    a za druhe, build beha v tzv,. runneru, coz je kontejner, kterej si rozbehnes tak nejak kdekoli a pripojis ho do gitlabu, runneru muze byt vice, muzou byt vyhrazene pro nejake joby, v tomhle rozhodne snaze nastavitelnejsi nez Jenkins. navic muzes v gitlabci importovat casti ci scriptu z jinych repo, takze muzaes mit buildici repo zvlast pripadne to mit hezky rozdeleny. umi to pracovat s tagovanim, takze to udela treba image s docker-tagem kterej ma git hash a zaroven ji vyrobi s docker-tagem kterej ma v sobe git tag. (ntvl. prilis mnoho tagu)
    Jenkins nejak spravuju a vlastne se mi moc nelibi, blbe se to ladi, anzto to vlastne musis dycky pustit celej jenkinsfile a pokud mas v pipeline vetsi mnostvi stage, ktere trvaji par minut a jsou na sobe zavisle, tak je to blby, da se to samozrejme nejak resit a obejit, ale neni to pohodlny a co ma jenkins blbe vyresene je sdileni dat mezi buildy. bud musis push nekam do repo, nebo udelat nejakej persistentni adresar kde si odlozis nejaky file. to uz rovnou clovek muze pouzit ten gitlab. jako je par veci ktery necham radeji v Jenkinsu, ale neni jich moc.
    A slozitejsi veci stejne je potreba udelat nejakym scriptem, nechces to psat v groovy v jenkinsfile, kde se to stejne bude blbe ladit. nebluve o tom, ze pak ti jenkins nadava, ze delas nebezpecny veci a musis vyslovne povolovat ve scriptapproval. o problemech s deklarativni vs. scriptovana pipeline to radeji nechame stranou vubec.
    MARTEN
    MARTEN --- ---
    RATTKIN: Tech moznosti je strasne moc. Za mne zalezi jestli je to self hosted, nebo nejaky cloud. Taky jak je to velka aplikace, jestli se pocita s balancingem/failoverem,...
    Traefik je super na male veci. Pokud resit nejake skalovani, tak haproxy. Pripadne openshift, rancher, nebo jine self hosted. Casto si to pak resi sami.
    QUOING
    QUOING --- ---
    RATTKIN: traefik

    Let's Encrypt - Traefik
    https://doc.traefik.io/traefik/https/acme/
    RATTKIN
    RATTKIN --- ---
    jak děláte to, aby každý (některý) docker container měl hostname a letsencrypt certifikát?

    teď máme portainer na správu stacků, jeden nginx na letsencrypt který to háže na porty stacků a v každém stacku znova nginx, nechápu to jak je to udělané a nezdá se mi to..
    MARTEN
    MARTEN --- ---
    RATTKIN: Jak pise INDIAN, gitlab se da hostovat, community edition je docela dostacujici. Github se da taky hostovat lokalne. CI pouzit bud z toho, nebo miliardu dalsich alternativ. Osobne preferuji jenkins. Gitlab CI/Bitbucket pipeline/... nejak nedela vse co bych chtel. V jenkinsu mame i joby nejen na CI, coz by nam gitlab ci nedostacovalo. Plus nam generuje reporty a je tam obecne vetsi prehled a flexibilita.
    Ale treba nejlehci varianta muze byt klidne i jen git/svn hook.
    INDIAN
    INDIAN --- ---
    RATTKIN: gitlab lze v klidu pouzivat i interne a obsahuje nativne i vlastni docker registry.
    + samozrejme vlastni CI implementace (obdoba jenkins)
    mno a samozrejme hromady jinejch ficur...

    my uz ho pouzivame 3. rokem a spokojenost ... plne zaintegrovanej mezi interni aplikace diky API, prihlasovani uzivatelu pres externi SSO, hodne vyuzivame prave i interni registry (kazdej projekt ma svuj napespace) a diky tomu prechod na kontejnery byl i jednodusi pro plno vyvojaru, admini se zas docela naucili ovladat git (mame par internich nastroju na principu gitops).
    QUOING
    QUOING --- ---
    RATTKIN: za me zvitezila kombinace gitea+drone (CI) presne pro tenhle ucel - commit->container build+testy->push do registry..

    Self Hosted CICD with Gitea and Drone CI - DEV
    https://dev.to/ruanbekker/self-hosted-cicd-with-gitea-and-drone-ci-200l
    Docker | Drone
    http://plugins.drone.io/drone-plugins/drone-docker/

    dalsi co muzes zkusit je self-hosted Gitlab, a pak treba Jenkins jako CI.. urcite je toho vic, bude zalezet asi na konkretnich pozadavcich
    RATTKIN
    RATTKIN --- ---
    co se dnes používá na automatický stavění docker container po commitu nového kódu?
    v práci máme ruční skripty nad svn a chceme přejít na Git+nějaký auto build.
    nevím ani jak to hledat, všichni jsou zřejmě na github nebo gitlab, ale náš kód je tak dobrý, že musí být tajný a nesmí odpustit prostředí firmy.
    K4N3C
    K4N3C --- ---
    Ahoj, mám dotaz: jsme bezpečnostní firma, zaměřujeme se primárně na ochranu enterprise sítí (velký společnosti, telco, armáda, kritická infrastruktura) a jsme v tom myslím docela dobrý. Technologický partner, se kterým děláme a jehož řešení používáme, před rokem koupil společnost Twistlock, kterou přibral do portfolia a rozšiřuje tak služby i na oblast DevSecOps, ochranu kontejnerů a serverless. Hledáme někoho, koho zajímá oblast bepzečnosti v prostředí kontejnerů a kdo by byl ochotný poslechnout si jak tato oblast produktů funguje, případně dostal demo na vyzkoušení a probral s námi, zda je taková ochrana skutečně přidanou hodnotou a zda by něco takového používal.
    Odměnou může být nějaká dlouhodobější spolupráce na projektech, možnost pořízení nástroje do firmy se zajímavou slevou, posun do oblasti DevSecOps atd. Případně se dá domluvit i na placeném otestování jako službě.

    Elevator pitch:
    Nástroj umožňuje zabezpečení celého životního DevOps cyklu, a to pro všechny běžně využívané platformy, aplikace i cloud prostředí (např. Docker, Kubernetes, GCP, Azure, AWS i Openshift). Mezi zásadní dostupné funkce patří mimo jiné:
    1. Vulnerability Management – automatický nástroj pro zjišťování známých zranitelností napříč všemi hosty, kontejnery i funkcemi serverless computingu.
    2. Cloud Native Firewall – integrovaný L4 a L7 firewall v prostředí Kubernetes, zajišťující vhled do síťové komunikace mezi kontejnery a mikroslužbami na úrovni aplikací, funkci IPS a mikrosegmentaci.
    3. Runtime Defense – behaviorální analýza a automatizovaná detekce i prevence incidentů v prostředí kontejnerů.
    4. Access Control – centrální monitoring Kubernetes, auditování hostů, inspekce logů a monitoring příkazů docker, sshd a sudo events.
    5. CI/CD integrace – skenování vulnerabilit při zavádění nového kódu v CI/CD pipeline, např. prostřednictvím modulu do nástroje Jenkins.

    Nesnažím se tu teď nic prodávat, jde mi vážně o možnost spolupráce a dostat od někoho z oboru reálný feedback. Kdyžtak pošta prosím.

    Disclaimer: nikdo z nás není developer :-)
    Kliknutím sem můžete změnit nastavení reklam