• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    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 :-)
    ONLINEQUE
    ONLINEQUE --- ---
    URPUTNIK: mozna jsem jenom narazil na samy juniory, nevim ;-) Mozna jsem i ja po letech stale jenom junior. Ano, cim vic veci poznavam, tim vic zjistuju, co jeste neumim.. Kazdopadne tahle filosoficka debata uz je trosku offtopic ;-) Ale chapu to, co pises a to sestavovani imagu timhle tebou popisovanym zpusobem urcite smysl ma, zni to dost logicky.
    ADMIX
    ADMIX --- ---
    ADM: ja se priznam ze jsem zcela nedustojne predpokladal tu runtime zmenu, pac veci ktery jsem videl lidi delat ...
    muj oblibenej favorit byl devops ninja co resit jak v aplikacnim kontejneru pustit init, aby mu to vevnitr nastartovalo cron, pac lift-and-shift zahrnoval tri crontaby :D
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: a tech pripravenych image bude samozrejme vic, protoze db bude potrebovat neco jineho, webovy kontejner taky atp ..
    URPUTNIK
    URPUTNIK --- ---
    ONLINEQUE: disclaimer, jsem dlouho vyvojar a castecne uz fusuju i k adminum (protoze nasi admini se virtualizace boji) .. troufam si tvrdit, ze "developeri jsou lenivi" je hodne zjednodusene videni sveta, ktere Ti asi moc nepomaha, ne? dovedu si predstavit a zcela chapu, ze to bude platit v "nizsich urovnich" hierarchie, protoze jsou to juniori a maji uplne jine problemy a jinou perspektivu .. ale technicky dluh je problem stejne tak administratoru, jako vyvojaru, takze u nas treba tohle pada na hlavu seniornich programatoru ..

    vize, kterou mame o tom, jak to adminum predame, je, ze si programatori reknou 'parametry', ktere ten image musi splnovat (aka musi tam byt napr JAVA_HOME, musi tam byt nahrane JDK 8+ na ktere JAVA_HOME ukazuje, a instalovane ssh + curl a verejne certifikacni autority, a uzivatel musi mit nahrany konkretni ssh klic) .. senior vyvojari pak vyjdou z takoveho image, nahraji si tam treba AS (tomcat, wildfly, nastavi ho aby se spoustel, atp) .. a tim vznikne "dev base image" ktery pouzivaji juniori, protoze tam maji to co potrebuji, jen si tam mountnou treba adresar se zdrojakama, rozsiri si ho o debug nastroje atp .. do produkce ale pujde ten baseimage od seniora s otestovanou a otagovanou verzi ..
    ADM
    ADM --- ---
    HOUMLES: ono to ani nedava smysl treba v kubernetes, tam se vsechny kontejnery restartem mazou, a upravu kodu v bezicim kontejneru bez restartu stejne neudelas (jen kdyz tam mas nejakej pid 1 proces manager). use case stateful kontejneru neznam (datova persistence je neco jinyho)
    ONLINEQUE
    ONLINEQUE --- ---
    Diky vsem za prinosnou debatu ;-), tim jsem asi tema vycerpal ;-}
    HOUMLES
    HOUMLES --- ---
    ADM: aha, tak ok, ja to tak z toho tvyho textu pochopil :)
    ADMIX
    ADMIX --- ---
    ONLINEQUE: hele je to tak, zvlast pokud potrebujete veci ktery se blbe automatizujou. V my aktualni praci mame problem "podobnej" a realita je takova ze jsem na to tymu napsal sadu fire-and-forget utilitek, ale tu posledni mili s commitem do interniho repa proste musi udelat nakej clovek. Dulezity je mit na to dobrej proces a zbavit se veci co trvaji a jsou otravny, a pak to proste brat jako development effort.
    ONLINEQUE
    ONLINEQUE --- ---
    ADMIX: ale jo, to asi zni rozumne. Demokracie je v takovym pripade nepouzitelna ;-)
    ADMIX
    ADMIX --- ---
    ONLINEQUE: Budto na to mate automation (jakoze nightly upstream sync) a nebo na to mate cronjob co kazdou druhou nedeli udela ticket nahodny obeti a nezavre ho dokud obet nereleasne novej image :)
    ONLINEQUE
    ONLINEQUE --- ---
    ADMIX: ted se asi chytam v pohode;
    jasne, tak to i pouzivam, mam jakysi base image, ktery pak pouzivam dal.
    Situace je pomerne velmi jednoducha, existuje jeden base image z ktereho je postaveno par kontejneru.

    Jen porad mi neni jasne, jak to bude resit muj problem s tim, aby to vevnitr bylo aktualni. Spolehat se na to, ze lenivi developeri neco nekdy udelaji - tak to moc nelze; developerum je u prdele, ze to, co tam jede, je zastaraly, jde jim primarne o vlastni pohodli, co si budeme nalhavat. Resi si jen svuj pisecek (coz castecne i chapu)

    Takze je jednak potreba, at uz behem buildu nebo tak, ze se zkontroluje bezici prostredi - zjistit, ze neco neni aktualni a vyreportovat to v dostatecne nahlas tak, aby se to nasledne vyresilo.
    Kliknutím sem můžete změnit nastavení reklam