• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    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.
    ADM
    ADM --- ---
    DANIELSOFT: to xml je v containeru? pokud ano, tak neni jina moznost nez nova image
    DANIELSOFT
    DANIELSOFT --- ---
    velmi lama dotaz o Kubernetu: mám rozběhlý nějaký cluster, který nasetupoval kolega. dokážu reprodukovat chybu, kterou mám opravit. mám tam XML soubor, přidáním jednoho řádku by se měla opravit chyba (systém by se měl chovat jinak), zkusil jsem naivně editovat soubor vimem , který v kontejneru je, ale soubor je v nějakém read-only layeru, že ani když root udělá :w! nedaří se uložit změněný soubor

    je nějaký jednoduchý způsob, jak tam tu změnu podstrčit?

    systém je totiž velký a builduje a setupuje se složitým způsobem, do kterého jsem ještě nepronikl a když chci jenom změnit ten soubor, tak mi přijde nejpřímočařejší zkusit změnu nejdříve takhle ručně
    WOODMAKER
    WOODMAKER --- ---
    REFLEX: pro odretardovani se s pravama si dovolim to popsat:
    na disku jsou inody, kazdy ma sve cislo
    adresar je specialni typ inodu, ktery je oznacen jako adresar a jako obsah ma seznam paru jmeno:cislo inodu
    soubor je specialni typ inodu, ktery je oznacen jako soubor a obsah je obsah souboru

    A inode drzi ony atributy
    mode - typ a prava souboru
    link count - pocet odkazu (kolik na nej odkazuje adresaru - pokud to klesne na 0, inode se smaze)
    uid - cislo uzivatele
    gid - cislo skupiny
    nejaky dalsi malickosti a data

    snad ti to pomuze v reseni

    MARTEN
    MARTEN --- ---
    REFLEX: vytvareni stejneho uzivatele v image je dost na prd. Ale taky jsem to parkrat udelal. Jinak nejde o jmeno, ale musel by mit stejne UID
    Kliknutím sem můžete změnit nastavení reklam