• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    Docker aneb přístupný provoz kontejnerizovaných aplikací
    Docker(Hub), Compose, Swarm, boot2docker, DevOps, LXC, ECS, TumTum a jiné buzzwordy
    Bezpečnost v prostředí kontejnerů
    Related: automatizace [ Centralizovaná správa stanic a ostatních prvků v síti konfigurace/inventarizace/instalace/aktualizace/zalohovani ]
    rozbalit záhlaví
    JON
    JON --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    5 odpovědí
    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 --- ---
    1 odpověď+4
    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 --- ---
    1 odpověď-1
    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 --- ---
    4 odpovědi
    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 --- ---
    +1
    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 --- ---
    +1
    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 --- ---
    +1
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    +1
    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 --- ---
    3 odpovědi
    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
    MLEKAR_STEIN
    MLEKAR_STEIN --- ---
    1 odpověď+2
    osobně se kloním k tomu, mít normálně vlastní registrovanou doménu a mit lokálně nějakou subdoménu pro tyhle účely, na kreré si budu dělat různé vylomeniny.
    nez řešit nějaké loxal, svc, srv.
    RUDOLF
    RUDOLF --- ---
    REFLEX: to je milé;-)
    REFLEX
    REFLEX --- ---
    1 odpověď+5
    Jinak nejake vychytavky ze sveta dockeru? Ja si zvykl pouzivat https://github.com/jesseduffield/lazydocker
    REFLEX
    REFLEX --- ---
    JON: jezis no jo vlastne, tak pojedu .localhost nebo .loc
    JON
    JON --- ---
    1 odpověď
    REFLEX: to bych nedoporucoval, od nejaky doby je .dev regulerni top level domena: https://en.wikipedia.org/wiki/.dev
    pekne curacky rozhodnuti, co vam budu povidat
    REFLEX
    REFLEX --- ---
    1 odpověď
    VELDRANE: to je zajimave, tak mozna prejdu na .dev :D
    Kliknutím sem můžete změnit nastavení reklam