• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    VELDRANE
    VELDRANE --- ---
    SUK: tak on to nemusi bejt plnej k8s, ale nejaka odlehcena verze (k3s/minikube apod). Uznavam ze uz sem asi trochu postizenej svou praci, osobne bych ale uz do cistyho dockeru sel jen ve vyjimecnych pripadech :)
    ADM
    ADM --- ---
    JON: to je mozny ze to jde i jak rikas. ja mam na takovym tom domacim sitovani jen openrc sluzbu, ktera spusti compose up a down, bez restart policy a nic mi zatim nechybelo
    JON
    JON --- ---
    ADM: no, to bych prave takhle vubec nedelal - restart policy se nastavi pro kazdou service v docker-compose jakou potrebuje (u webovejch backendu typicky restart: always) a je vystarano - kdyz se zrestartuje celej stroj, tak to docker daemon nahodi jak ma (jestli podle policy ma), kdyz to spadne samo, tak taky - a neni potreba nic v systemd.
    ADM
    ADM --- ---
    JON: vim co myslis, musela by se ta sluzba nastavit at to spusti jen compose up a down a nestara se o vysledek (coz i v systemd jde, jako ze neni service running ale active exited nebo jak - systemd nepouzivam pokud nemusim).
    on restart policy v docker-compose stejne asi potrebovat nebude a je lepsi pokud tu aplikaci pojme jako service rizeny init systemem
    JON
    JON --- ---
    ADM: to bych nedoporucoval - michat do toho systemd - nech to na dockeru pres restart policy: https://docs.docker.com/compose/compose-file/compose-file-v3/#restart_policy
    ADM
    ADM --- ---
    SUK: a pokud pouzivas letsencrypt, tak se v pripade jednoho nginx na hostu alespon nezblaznis z obnovy certifikatu
    ADM
    ADM --- ---
    SUK: pokud ty kontejnerovy webaplikace spolu nijak nesouvisi, tak si zapis kazdou zvlast do vlastniho docker-compose.yml (jde i o to, ze mas ten container nejak slusne a strukturovane popsany a definovany, a nemastis to nekde ve scriptech), a zarid si, aby to byla sluzba spravovana init systemem (nejspis systemd, tady neporadim, ale urcite bude existovat systemd-unit pro docker-compose).
    SUK
    SUK --- ---
    VELDRANE: Jedinej uzivatel a to teda fakt fullstack jsem ja ja ja jenom ja ;) Z toho duvodu mi prave k8s prijde jako kanonvrabce :P))
    ADM: jo, to zni docela rozumne. Ty dve veci (davical, agendav) nastesti fungujou s aktualnim pg a navic jsou na sobe navzajem zavisly :)

    Ohledne "ty kontejnerizovany aplikace si zapis do d-c": jenom ty aplikace nebo celou tu "infrastrukturu"? Uprimne jsem docker doted pouzival maximalne pro vyvoj na localu a poustel/vypinal jsem to rucne, takze netusim, jak se tohle vlastne resi na serveru...

    Diky za odpovedi :)
    ADM
    ADM --- ---
    SUK: ja budu mit jiny nazor nez VELDRANE prede mnou:
    - nginx jeden na hostovi pro vsechny weby/aplikace
    - kazda webaplikace (nodejs, php-fpm, ...) ve vlastnim docker containeru (docker network mode host pro aplikace poslouchajici na localhostu, kam na ne ta nginx proxy dosahne)
    - ten postgres spise jeden na hostu, ale pokud jsou rozdilny pozadavky od aplikaci napr. na verzi postgresql, tak to klidne rozdel zvlast na nekolik postgresu v containerech
    - ty kontejnerizovany aplikace si zapis do docker-compose
    VELDRANE
    VELDRANE --- ---
    SUK: naopak mi v tomto pripade prijde pouziti k8s vcelku logicke. Usetris zdroje (nektere veci jako cast tech nginxu muzes mit v jedny instanci), mas zajisteni sitovani a propjeni veci v ramci k8s clusteru. Nicmene by bylo vhodne si rozmyslet jak a ktery aplikace spolu komunikuji, kde mit ingress, kde mit externi ip, co resit pomocit nejake custom nginx instance apod, kolik na to mas casu a jak resit deployment, kolik na to mas lidi apod.

    Pokud ale chces podobne prostredi nejak konsolidovat, tak mi kubernetes prijde jako vhodnejsi volba nez to cpat na jednu virtualku. Osobne bych build jednotlivejch komponent delal v klasickym docerfilu a deployment pak pomoci helmu. To prostredi nemas nijak velkyntakze cpat tam neco jako argo je kanon na vrabce. Taky bych si byt tebou popremejslel nad tim kdo a jak bude nasazovat updaty aplikacni casti. Predpikladam zs ten php kod se nejak vyviji, aktualizuje, patchuje….
    SUK
    SUK --- ---
    Ahoj. Asi si chci zalozit virtual kde budu mit "vsechno" a to vsechno bude kontejnerizovany. Aktualne predpokladam:
    - nginx "naprimo" pro staticky weby (bude jeden az dva, hadam)
    - nginx + php-fpm (aktualne 3 weby)
    - nginx jako reverse proxy pro nodejs aplikace
    - nginx jako reverse proxy na web-storage ktera ale bude uplne nekde jinde
    - postgresql pro ty 3 php weby + mozna i dalsi
    - mozna mongo

    Me znalosti jsou na te urovni, ze toto vsechno dokazu dat bez potizi dokupy standalone i to dockerizovat, ale asi to nebude "spravne".

    Takze, otazek mam vic:
    1) Cim to skladat? Docker-compose nebo neco jinyho? k8s by byl asi komar na kanona
    2) 3 weby, 3 pgsql databaze muze znamenat 3x nginx + 3x pgsql + nginx jako rproxy. A nebo 1 nginx co dela vsechno a jedna pgsql, co dela vsechno? Jeden web navstivi jednotky mesicne, zbytek je ciste jen pro me :))
    3) Weby a databaze predpokladam jako externi mount (alias volume) nebo to delat jinak

    Ano, asi to prehanim a moc resim, ale snazim se to proste delat spravne/spravneji, co kdybych umrel a nekdo se mi podival na server? Diky danke gracias!
    HVJ3R
    HVJ3R --- ---
    10GB na image je moc. Ja zacinam bejt nervozni uz kdyz to leze k 1G. Voser s tim pracovat. Vic imgs a ruzne verze chapu, to mame taky, ale snazime se vychazet ze stejnyho base img, at se images/verze lisej jen max par layerama max 10kach MB. Pak tahas prd. Ale jestli mas ephemeral nodes, tak nepomuze ani tohle.
    ADMIX
    ADMIX --- ---
    ICARUS: 20MBps z S3 je brutalne pomaly, S3 bezne dava >200MBps a teoretickej limit je vpc connectivity. To je nakej limit docker pull? Jestli jsi je tahal z S3 anyways, tak co to stahnout na lokalni disk pres normalni GET, jestli to nebude rychlejsi?
    NYX
    NYX --- ---
    FB tohle resil bittorrentem :-)
    KAPLIK
    KAPLIK --- ---
    ICARUS: Tak pipelina ktera pri buildu jedne z tech docker image trigerne jeste pipeline co zbuildi ec2 image? :)
    Pripadne k tomu worker nodu pripojovat nejaky ebs/disk, kde by ty image byly, mozna furt rychlejsi nez to tahat pres klasickou sit z registry.
    ICARUS
    ICARUS --- ---
    KAPLIK: Jo, přesně tohle tam mám teďka. Blbý je, že ty změny té image jsou občas trošku nepředvídatelné a hlavně těch docker imagí je tam víc a různé verze, takže se mi úplně nechce pořád buildit nové custom EC2 image.
    KAPLIK
    KAPLIK --- ---
    ICARUS: Pokud se ta image tak casto nemeni, tak by si vyrabel custom image pro ec2/eks, kde by byla predcachovana, tzn by se nemusela cela tahat z docker registry, pripadne by se treba stahnul jen nejnovejsi layer (ale tam uz zalezi proc je ta image tak velka a co se v ni meni).
    Takto je to treba vyreseny na AKS (azure) worker nodech, kde os image obsahuje nacachovane image kontejneru ktere tam bezi by default, aby se furt vsechno nestahovalo.
    JON
    JON --- ---
    ICARUS: resilli jsme neco podobneho - u nas bylo resenim zmensit image, data z nej vyhazet uplne, a pro stahovani dat jsme udelali spesl sluzbu. V kazde geolokaci nam bezi jedna instance te sluzby a prubezne docachovava data z "centraly". Kdyz v lokaci startuje nova sluzba co ootrebuje ty data, tak je stahuje z prislusne geolokalizivane sluzby-cache.
    Nas usecase je odlisny v tom, ze neresime start/restart vsech stroju najednou.

    To co popisujes ty by jeste slo resit tak, ze se to stahne jednou na jeden stroj, ten to pak nakopiruje idealne nejakym dd na dalsi a tak dal - trochu zalezi na tom jak moc jsou ty stroje vzdalene. To se teda blbe dela s imagem, takze bych taky zacal zmensenim image a separaci dat ven.

    Pokud to co dela ten image velky nejsou data, tak blby no.
    ICARUS
    ICARUS --- ---
    Jak byste řešili situaci, kdy máte velké množství (třeba 64) strojů, které si najednou potřebujou stáhnout docela velký image (10GB)? Stroje se spawnují ondemand a po ukončení výpočtu zase zmizí, takže se ty image na ně těžko dají přednahrát. Všechny ty stroje jsou v jedné privátní síti a v AWS cloudu.

    Zkoušel jsem použít AWS ECR, ale pull je příšerně pomalej (10 MB/s). Ty stroje si ty image potřebujou stáhnout co nejrychleji. Zatím jsem koukal po Kraken od Uberu, ale vypadá to jako lehce abandoned projekt a nevím, jestli se mi chce setupovat tak složitej traktor. Pak jsem taky zkoušel vlastní Docker registry s S3 backupem, ale to dávalo "jen" 20 MB/s pull. Na tohle už přece musí být nějaké rozumné řešení, ne?
    REFLEX
    REFLEX --- ---
    MLEKAR_STEIN: to neni spatny napad
    Kliknutím sem můžete změnit nastavení reklam