• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    RAGNAROK
    RAGNAROK --- ---
    Vyrabim dockerized emacs.
    Zkousim v Dockerfile:
    RUN useradd UID USER

    Potreboval bych tomu useradd nacpat jako parametry $(id -u) a $(id -g). Napadlo me jen v bashi skript kterej ty parametry do toho Dockerfile naprasi.

    Zkousel jsem ten useradd v entrypointu ale to pak nemuzu pustit docker run s parameterem -u $UID protoze nemam pak neni pristup k passwd.
    MARTEN
    MARTEN --- ---
    REFLEX: Jestli bylo chciple vsechno, hledal bych na serveru. Co uptime? Kouknul bych na posledni instalovane balicky, jestli tam nebyl docker/kernel/.... pripadne bych kouknul i do logu syslog/messages/apod.
    Necekam ze kazdy container se exitnul ve stejnou chvili a bylo by to "chybou" toho co v tom bezi.
    RAGNAROK
    RAGNAROK --- ---
    REFLEX:
    pokud ti containery nelogujou do stderr/stdout tak v logs nic neuvidis.
    REFLEX
    REFLEX --- ---
    Ahoj, tak mam dalsi dotaz :D. Na serveru mi bezi docker-compose a dnes rano to bylo chciple = containery co bezeli byly ve stavu exited, nemel jsem zaple restart: always, ale to neresi to ze ted nemam jak zjistit proc spadli. Procital jsem docker-compose logs, ale tam nic neni

    Jak ziskat tyto logy, aby byly aspon v logs? Nebo co pouzit jako monitorovaci nastroj? Doufal jsem ze https://www.portainer.io/ to umi, ale zatim ne :)
    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/
    Kliknutím sem můžete změnit nastavení reklam