• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    VELDRANE
    VELDRANE --- ---
    Ahoj,
    je nejaka cesta treba pres pluginy jak rozsirit built in variables v Helmu ? A ted nemyslim pres samotny _helpers.tpl ale nakou casti kodu, ktera mi bude zavola nejakej command a na zaklade jeho vystupu mi nastavi nejakou buil-in promenou kterou pak se pak pouzije v nejake template ? Priklad:

    Mame k8s clustery, ktery maj ruzny verze a nak tery se ruzny aplikace instalujou jinym stylem. Potrebuju zjistit treba pres kubectl co to je za cluster a na zaklade neho si vyplnit promenny ohledne lokace image a dalsi veci. Myslel sem ze by to mohlo jit pres pluginy, ale z tech prikladu mi prijde ze ta ficura je pro neco uplne jinyho nez potrebuju.

    A dotaz cislo dve. Jde nejak bez nejakejch externich obezlicek vyplnit release.version na zaklade toho co je v gitu ?
    JON
    JON --- ---
    ADM:
    MLEKAR_STEIN:
    Dekuju za rady - zvysil jsem ty max pull a max push, pridal delsi timeout pro docker-compose a situace je vyrazne lepsi (i kdyz ne 100% dobra).
    Porad se obcas nektery docker-daemon zasekne na tom pushovani, ktere nemuze uspet, ale je to vyrazne vyrazne min - tj ted uz si dokazu predstavit, ze pro tuhle eventualitu tam budeme mit nejakej automatickej restart - a jeste zkusim trochu potunit ty parametry, aby to bylo ok.
    ADM
    ADM --- ---
    JON: kdysi jsme resili podobny problem s tim, ze docker-registry proste nestihal vic simultanich push pull image (tech deploymentu bylo hodne a casto se to proste seslo) a koncilo to timeoutem. uz si nevzpominam jak se to vyresilo, to znamena, ze asi nejak standardne zvysenim limitu (a nebo to byl primo nejaky problem s limity v bamboo, ktery buildoval a pushoval). vas problem vypada jinak, ale na docker-registry bych se urcite podival. ssd jak tu nekdo zminoval na vytizenejsich /var/lib/docker to potvrzuju
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    JON:

    pokud to je tak, ze selze ten push a zaloguje to tyhle dve hlasky, a ta failed mount je tak trochu matouci
    tak me napada v konfiguraci docker registry
    storage:
      filesystem:
        rootdirectory: /var/lib/registry
        maxthreads: 100
    zvysit maxthreads: 100 treba na 300
    Configuring a registry | Docker Documentation
    https://docs.docker.com/registry/configuration/

    pokud je to obracene, tak nevim, muze byt nekde omezeny pocet otevrenych souboru?

    a kdyz tak nad tim premyslim, tak bych tak jako tak zvysil maxthreads v registry a
    v dockeru na masine kde se to buildi max-concurrent-downloads na treba 8 a max-concurrent-uploads na 10

    --max-concurrent-downloads int Set the max concurrent downloads for each pull (default 3)
    --max-concurrent-uploads int Set the max concurrent uploads for each push (default 5)
    dockerd | Docker Documentation
    https://docs.docker.com/engine/reference/commandline/dockerd/
    JON
    JON --- ---
    MLEKAR_STEIN: diky za obsirne info - podivam se co by se mi mohlo hodit, ale nas problem mi prijde odlisnej:

    Akorat my to vsechno mame na NVMe diskach a ve chvili, kdy je docker daemon neschopny pushovat (opravdu je neschopny docker demon, ne compose, zkusil jsem to na tom stroji pres `docker push`) tak tam uz zadny kontejner nebezi treba nekolik hodin.
    Restart celeho stroje nebyl nikdy potreba, staci `systemctl restart docker`. :(

    stav se bezpecne pozna podle toho, ze `journalctl -u docker` se porad plni hlaskama jako tato:
    Jun 21 09:24:46 runner6 dockerd[1280290]: time="2022-06-21T09:24:46.476585833Z" level=info msg="failed to mount layer sha256:649677b0b4a4f861845499fd7c06dbccce5445a3eb931d146da3c01c1ec216c3 (sha256:d9596064
    beeaf2e31c97a60091a5443eb7e68b3ad568e1067345db51b417d48c) from docker.nase.domena/skupina/projekt/buildovaci-image: Post \"https://docker.nase.domena/v2/skupina/projekt/jinej-image/blobs/uploads/?from=skupina%2Fprojekt%2Fbuildovaci-image&mount=sha256%3Ad9596064beeaf2e31c97a60091a5443eb7e68b3ad568e1067345db51b417d48c\": unauthorized: HTTP Basic: Access denied"
    Jun 21 09:24:47 runner6 dockerd[1280290]: time="2022-06-21T09:24:47.096387050Z" level=error msg="Upload failed: unauthorized: HTTP Basic: Access denied"
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    RATTKIN: jo, nam to hodne pomohlo.
    a nepouzivat compose pro docker push a docker pull.
    a pokud ma nekdo naladu, tak stoji za to, pohrát si s temi parametry vm.*
    RATTKIN
    RATTKIN --- ---
    MLEKAR_STEIN: takže TL_DR všude mít SSD?
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    JON:
    1. udelal jsem zkusenost, ze docker ma problem s IOPS na diskove operace. /var/lib/docker by melo byt na ssd disku. a to i v pripade, kdy se na stroji nepouzivaji volumes pro persistentni data.
    jako best practice bych pridal, ze pokud mam vetsi mnozstvi volumes, ktere neco delaji, treba mam elastic a generuji indexy, tak je dobre mit volumes na vlastnim disku. to se da resit bud symlnkem, nebo pomoci direktivy bind v /etc/fstab

    2. docker-compose ma timeout na vlastnim dockeru, povazuji za hodne nepravdepodobne, ze by to melo trable kvuli registry, kam se to pushuje, pokud to registry neni na stejnem stroji.
    timeout se da nastavit promennou COMPOSE_HTTP_TIMEOUT.
    Viz https://docs.docker.com/compose/reference/envvars/
    trochu to pomuze, chcipne to o par minut pozdeji

    3. je nejakej trabl v komunikaci compose a docker daemona, uz docela dlouho, chovani je takove, ze compose uz nereaguje a zaroven docker docela v pohode funguje. kdyz tohle nastalo, tak jsem opravdu nikdy nemel cas pustit strace abych zjistil, ktere volani v compose blbne. :)
    da se to nasimulovat pomoci nekolika elastic serveru, ktere generuji indexy a elastic data volumes lezi vsechny na jednom tocivem sata disku spolecne ve /var/lib/docker. :D
    doporucuji pouzivat "docker push" misto compose.


    4. runnery - umiraji na iops. klinicky jsem otestoval na serveru s 15k SAS disky. kdyz se jich pusti vetsi mnozstvi, tak to na tocivych discich chcipne. plati pro ne to same, co pro vsechny docker kontejnery a /var/lib/docker. radeji na levnejsim SSD nez na drahem SAS. delalo to uz pred par lety. kdyz se pustilo nekolik vetsich kompilaci v C++, hromada malejch blbosti a par kompilaci javy tak to chcipalo uz na gitlab 12-13.
    kompilace zerou disky :D

    5. vec, ktera umre na iops se obvyukle sama od sebe nikdy nevzpamatuje a zustane v ni nejaky proces v D stavu, Uninterruptible Sleep, kdy ceka na IO. neda se s tim delat vubec nic, krome restartu stroje, v pripade dockeru restartu kontejneru. protoze v tomhle stavu to nereaguje na zadny signal.

    6. podle popisu bych tipoval, ze se pokousi cist layers ze socketu a zaroven bezi nejaka kompilace a umre to na IOPS..

    7. mozna reseni.
    dat tam ssd disk pro /var/lib/docker
    zkusit si pohrat s parametry vm.dirty_background_ratio, vm.dirty_ratio
    nejaky info je na strance u glusterFS, https://docs.gluster.org/en/main/Administrator-Guide/Linux-Kernel-Tuning/
    pripadne neco dalsiho, co me ted nenapada a ani nejsem schopnej nejak rychle najit.
    DANIELSOFT
    DANIELSOFT --- ---
    JON: to by mozna stalo za nejaky bugreport smerem k vyrobcum Dockeru ci Docker-Compose
    JON
    JON --- ---
    Cau, resim zapeklitej problem:
    Od te doby, co jsme upgradovali gitlab na verzi 15 (gitlab i runnery) se potkavame s tim, ze se docker na nekterem runneru dostane do nestabilniho stavu, kdy neni schopnej pushnout image do registry (obcas ani pullnout). Dockery na ostatnich runnerech pushujou/pullujou ok. Restart dockeru problem vyresi. V journalctl je u toho failujiciho dockeru videt, ze se snazi opakovane pushovat hromady layeru a failuje u toho http basic auth do registry.

    Na kazdem runneru se to stane tak cca jednou, 2x za den. Vetsinou v situaci, kdy se spusti hodnemoc jobu naraz. Nebo (domnivam se), kdyz se hodne rozjetejch jobu zastavi. Spolehlive reprodukovat to neumim. Ten chybovej stav vydrzi trvat hodiny - takze fakt vopruz.

    Podeziram nasledujici situaci:
    na build a push imagu pouzivame docker-compose. Kdyz se nasype hodne jobu = hodne pullu a pushu najednou, tak asi dojde k pretizeni site/registry. docker-compose vytimeoutuje a ukonci job, tim zrusi validitu job_tokenu do registru ale docker daemon se porad pokousi pushuvat, ale je z registry odmitan.

    Netusite, jak nastavit bud vetsi timeout pro docker-compose a nebo hlavne mensi pocet retries na push v docker daemonu? V dokumentaci jsem nasel jen limit na maximalni pocet paralelne stahovanych ci pushovanych layeru - ale to mi neprijde jako vhodna cesta - vetsinu casu to funguje ok, a beznej beh bych nerad zpomaloval.
    MARTEN
    MARTEN --- ---
    KAPLIK: Kouknu, to by znelo dobre s tema dependency.
    Gitops neznam, ale vim ze ten proces jen tak nezmenim. Ono je na to navazane schvalovani nekolika lidma a to i manazerama. Ale co koukam, tak to vypada jen jako actions/pipeline v gitlabu nebo necem. Coz by od Jenkinse nebylo ve vysledku nic jineho.
    KAPLIK
    KAPLIK --- ---
    MARTEN: jako zakladni/rychlo reseni muzes vyuzit toho, ze helm umi dependency, tzn muzes mit jeden helm chart verzi X, ktery bude mit jako dependence servisu A ve verzi 1 a servisu B ve verzi 2... pak teda delas "helm upgrade -i" na ten "umbrella" chart, ktery si pak dotahne dependence (s tim ze v ramci toho musis poresit values tech dependenci)... dale viz: https://helm.sh/docs/helm/helm_dependency/

    nicmene delat jenkinsem helm install/ugprade mi prijde takovy meh... gitops na vas! :)
    MARTEN
    MARTEN --- ---
    Ma tady nekdo vetsi zkusenosti s helm? Potreboval bych mini konzultaci, nebo jestli je to realne vyresit.
    Mame projekt, ktery ma 4 tymy, kazdy tym ma nekolik microservice (10-20). Vsechno se nasazuje do openshift. Kazda service ma svoje verzovani a v openshift vlastni project s nekolika deployment configama. Zatim neresene pres helm. Rozdelene jsou to projekty kvuli rozdilnym budgetum tymu a kolik maji zaplacenych cpu apod (korporace, s timhle se asi moc neudela).
    V tuhle chvili se nasazuje na jenkins. Vyberou se verze service, klikne se a pocka.
    Budu ted predelavat celou pipeline a chci i trochu lepe udelat nasazovani. Treba i tim, ze je pozadavek na to mit moznost nasadit verz 1.2.3 a clovek ktery to nasazuje, tak ho nezajima, jaka microservice potrebuje jakou verzi (ted dostane seznam a musi kazdou service udelat podle toho).
    Nechci na tohle vymyslet nic vlastniho, napadlo me jestli helm by tohle nevyresil, ale znam ho jen okrajoe. Jde tam udelat ze mam chart ve verze 1.2.3, ten obsahuje deploymentConfig pro nekolik sluzeb a u kazde ma recene jako image se ma nasadit? Podobne i s rollbackem, kdy reknu ze se chci vratit na predchozi (helm rollback myslim ze jsem zahledl).
    Vice chartum (4) se asi nevyhnu, ale to se da spustit paralelne.
    MORTAELTH
    MORTAELTH --- ---
    DANIELSOFT: kromě rad, ktere již padly (config mapa, zmena v přímo v imagi pokud je to zapečené) tu je možnost init containeru (https://www.magalix.com/blog/kubernetes-patterns-the-init-container-pattern).

    Každopádně pokud to má být konfigurační soubor, doporučuju config mapu (Secret)
    GIOMIKY
    GIOMIKY --- ---
    https://twitter.com/kantrn/status/1511791378497384454?
    FAANG promo committees are killing Kubernetes: A Short Thread
    VELDRANE
    VELDRANE --- ---
    DANIELSOFT: Neni nahodou ten file soucasti nejaky configmapy a nestaci zmenit pouze tu configmapu ? Pripadne vytvorit, namountovat v deploymentu/statefullsetu a premastit jim ten originalni xml file ?

    To xml je k cemu ? K aplikaci co bezi v tom clusteru ?
    DANIELSOFT
    DANIELSOFT --- ---
    AQUARIUS: no jo, ale to vyžaduje změnu v jiné komponentě, než je "naše", takže já zrovna tam commitovat nemám práva... proto jsem právě zkoušel tu partyzánštinu "změnit to přímo v kontejneru na prostředí, na kterém o nic nejde"... možná mi na to řekneš něco jako "tím spíš je dobře, že tě to hlídá a že to nemůžeš udělat" :)
    AQUARIUS
    AQUARIUS --- ---
    DANIELSOFT: pokud je prostredi postaveny dobre, bude stejne zmena jen o jednom spravne umistenym commitu, ne? Zbytek je kandidat na automatizaci v ramci CI/CD pipeline. (to se mi to keca, kdyz s tim mam jen omezeny prakticky zkusenosti, navic jen na vlastnim piskovisti, zeano...)
    DANIELSOFT
    DANIELSOFT --- ---
    AQUARIUS: tohle je testovací throw-away virtuálka v R&D oddělení, žádná produkční nebo zákaznická data. ale chápu, co tím myslíš.
    AQUARIUS
    AQUARIUS --- ---
    DANIELSOFT: prijde mi, ze zabraneni podobnemu chovani (ja chci "jenom" ...) je primarni duvod, proc se kontejnery pouzivaji. Kdyz disciplina neni, je treba ji vynutit. Neber si to osobne, sam se tesim, az se moje produkcni prostredi dostane do podobneho stavu, aby kolegove nemohli "jenom" pres ssh menit nahodna nastaveni s tim, ze audit trail takovych akci se v lepsim pripade sestavuje hrozne spatne.
    Kliknutím sem můžete změnit nastavení reklam