• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    QUICK
    QUICK --- ---
    Tak jsem vše připravil na migraci na docker swarm (QUICK). Původně jsem měl jeden webový stroj na něm nginx, gunicorn (python django appka), memcached a varnish. Rozsekal jsem to do 4 docker service, docker swarm má jen 1 node (stejně výkoný jako aktuální produkce). Na build a uložení image jsem použil Google Cloud služby. Chtěl jsem si primárně vyzkoušet provoz na dokerizovaných aplikací a bezvýpadkové přenasazení. V budoucnu bych chtěl swarm rozšířit o další node, který bude v jiné geo (USA), tak aby obsluhoval traffic z USA.

    Měl bych k tomu pár otázek:
    - má z nějakého důvodu cenu spouštět na jednom nodu víc replik gunicorn služby?
    - máte nějakou zkušenost s použitím Google Cloud Logging? Ngnix do stdout posílá access log, tak aby se docker kvůli tomu nějak nezakuckával...
    - standardní nginx, varnish, memcached image spouští proces pod rootem. Je to ok? V různých best practices jsem četl, že je lepší aby běželo pod jiným uživatelem (gunicorn container mi tak běží)

    Obecně je něco na co bych si při provozu v tomhle setupu měl dát pozor?
    ADMIX
    ADMIX --- ---
    QUICK: Vzdycky je lepsi drzet non-secret veci v secrets, nez secret veci v non-secrets :D connection string s heslama nevadi nicemu az do chvile, nez ti to nekdo commitne do repa nebo nekomu omylem posles produkcni connection string misto UAT apod. Je tezsi drzet spravny security boundaries kdyz vsechny informace mas v jednom artifactu.
    Tohle vsechno samozrejme zalezi na ostatni strukture, jak mate oddelenej pristup k tem informacim, jak kriticky to je, jak distribuovany to musi bejt ... muj osobni nazor je ze drzet konfiguraci a secrets oddelene je best practice a nestoji to o moc vic, ale ber to jako IMHO :)
    DWICH
    DWICH --- ---
    Vadí nečemu, když aplikace dostane jeden connection string (DSN) pro DB, kterej je uloženej někde ve vaultu?

    V čem je výhoda mít oddělenej host/port a k tomu username/password? Chápu, že host/port někdo může vnímat jako konfiguraci a ne credential. Nicméně zpátky k otázce - vadí něčemu, když aplikace přebírá jeden connection string, kterej je bezpečně uloženej jako ostatní secrets/credentials?
    HOUMLES
    HOUMLES --- ---
    QUICK: jj je to tak.. neni to nic extra kompikovanyho, kdyz to clovek pochopi a naskriptuje si to kolem tak se to na to nemusi vubec myslet
    QUICK
    QUICK --- ---
    ADMIX: máš pravdu, db host a db name jsou spíš konfigurace, tak asi do env nebo docker config. Na druhou stranu vadí něčemu, když to budu držet v secrets? Můžu to stejně držet v docker config, který má v podstatě stejnou logiku jako secrets, jen se hodnoty nešifrují.

    HOUMLES: jo, jednodušší je mít hromadu souborů a nezavádět složitosti. Půjdu touhle cestou. Díky za upozornění na neměnost secrets, to jsem netušil. Ale teď jsem si s tím hrál a nevypadá, že změna by byla velká pruda. V docker-compose.yml:

    secrets:
      my_test:
        external: true
        name: my_test-v1
    services:
      nginx:
        image: nginx:1.18.0
        secrets:
          - my_test
    


    V službě je to vždy dostupné pod /var/run/secrets/my_test. Při změně secret je nutný vytvořit nový secret v swarmu a inkrementovat my_test-v1 v konfigu. Pak už volat docker stack na přenasazení nebo samostatně přes docker service:

    docker service update nginx_nginx --secret-rm my_test-v1 --secret-add source=my_test-v2,target=my_test
    
    HOUMLES
    HOUMLES --- ---
    QUICK: ja bych na to sel takhle... co je jednodussi? spravovat hromadu souboru s heslama a loginama nebo spravovat min souboru, ale k tomu navic spravovat kod, kterej to bude parsovat?
    ja to mam teda vsude rozdeleny zvlast, jeden file = jedna promena ..pak se s tim i lip pracuje (napr. staci cat na soubor a mas heslo).
    ale jinak zalezi na prostredi, tohle vsecko lze delat i pres env nebo pres docker-compose.. u nas se treba pouzivaj secrets protoze mame komplet kod v gitlabu, kde probiha i build a je docker repository, ale do gitu maji pristup i lidi co by nemeli ty secrety znat, treba heslo do produkcni db.
    takze pokud se k tomu secretu nemuze dostat nikdo jinej nejak jinak tak bych to zbytecne moc nekomplikoval...
    a nevim jestli uz jsi na to narazil, ale priprav se na to, ze je s tim pekny srani.. musis zajistit verzovani tech secertu ve swarmu, protoze pokud neco uvnitr souboru zmenis a on se jmenuje porad stejne, tak ti ho docker nenacte jako novej.
    ADMIX
    ADMIX --- ---
    QUICK: Nikdy nedavej jakykoliv credentials do connection strings; db host and db name nejsou credentials, ty patri do nakejch configu (ktery pak zalezi na tom jak planujes DR, failovers etc.), a jmena/hesla/privatni klice prave do nakyho vaultu (nemam zadnou zkusenost s docker secrets :D )
    QUICK
    QUICK --- ---
    Ahoj, v návaznosti na QUICK jsem se rozhodl na projektu produkční deploy zmodernizovat. Rozhodl jsem se využívat pro provoz docker swarm. Na hesla plánuji použít docker secrets a řeším v jakém formátu údaje do docker secrets ukládat. Třeba pro DB se nabízí buď vytvořit čtyř secrets (database_host, database_user, database_password, database_dbname) nebo použít jedno secret a uložit vše ve DSN formátu jako postgres://login:heslo@hostname/dbname

    Druhý mi přijde takový elegantní, ale před použitím je to potřeba rozparsovat (což v python aplikaci není problém, jinde by být mohl). Je na tohle nějaká best practice jak postupovat?

    Obecně bych zvolený princip rád uplatnil na další credentials, například k přístupu na jednu službu mám jen jméno a heslo. Buď můžu uložit jako 2 secrets service_x_login, service_x_password nebo pouze jedno secret a uložit ve formátu login:heslo.

    Jaký způsob byste zvolili vy?
    MARTEN
    MARTEN --- ---
    WOODMAKER: pozor, run spusti novy container. Pokud chces spustit neco v jiz bezicim, tak od toho je exec
    RAGNAROK
    RAGNAROK --- ---
    WOODMAKER:
    to jen kdyz zmenim neco v docker-compose jinak to neni potreba.
    WOODMAKER
    WOODMAKER --- ---
    RAGNAROK: proc restartujes kontas?
    WOODMAKER
    WOODMAKER --- ---
    SH_PANDA: container mu jede a on v nem pomoci RUN pousti ruzny prikazy (treba bash)
    RAGNAROK
    RAGNAROK --- ---
    SH_PANDA:
    1. Je to pohodlnejsi nez vypisovat vsechny nastaveni v commandline za pouziti docker run

    2. Ostatni containery bezi ale potrebuju otestovat nejakou zmenu v kodu v jednom kontasu.

    Pomoci dockefile mam vybuldeny prostredi a kod leze do konteineru krz volume, takze nemusim buildit image po kazdy zmene kodu. Zmenim kod a restartnu kontas.

    Dobry to je pro golang, python, bash kod.

    treba:
    docker-compose run contname bash
    a pak si jde hrat v containeru.

    samozrejme to jde i jinak
    SH_PANDA
    SH_PANDA --- ---
    RAGNAROK: aby jsi nemenil compode ale si jenom neco zkusil s kontajnerem a pak ho restartnul?
    RAGNAROK
    RAGNAROK --- ---
    SH_PANDA:
    na test
    SH_PANDA
    SH_PANDA --- ---
    RAGNAROK: a proc poustis docker-compse run? (jsem lama, chci znat odpoved)
    RAGNAROK
    RAGNAROK --- ---
    fuck ted jsem 3 hodiny zjistoval proc se nemuzu z hostu dostat na container kdyz ho spoustim pomoci docker-compose run. Staci dat --service-ports.

    docker-compose run --service-ports
    RUDOLF
    RUDOLF --- ---
    QUICK: Děláme streaming kamer včetně broadcastingu. Takže máme edge servery všude kde jsou dobré linky za dobré peníze. Aplikační servery s daty máme v AWS, caching standardně přes Cloudfront a segmenty s nahrávkáma tahá zákazník z S3. Live view segmenty and broadcasting míjejí AWS kompletně, zákazník dostává segmenty přímo z edge serveru připojenýho ke kameře.

    Caching děláme hlavně kvůli latenci, máme jedno django pro zákoše ve dvou ec2 a další django ve swarmu jako marketing web. Všechno jede přes ALB, krom videa.

    Každopádně kdybych designoval něco nového, šel bych do spot instancí, lambdy a asi zůstal u ALB a Clloudfront. Abych řekl pravdu, náš hlavní cost v AWS je S3, computing při nahrávání a až pak dole networking. Tak největší optimalizace jsou na S3 a rust appkách v computing. K tomu se váže přesun do EKS kvůli servisám, který běží za ALB a nechceme je řešit jako instance.
    QUICK
    QUICK --- ---
    RUDOLF: "outbound rveme mimo AWS" - chápu teda správně, že webový/aplikační servery máte mimo AWS? Můžeš to trochu rozepsat kde a jak to provozujete?
    RUDOLF
    RUDOLF --- ---
    QUICK: serverless;-) ale to není trik, ale tuna práce;-)

    Všechno co má outbound rveme mimo AWS;-) Ale CDN používáme globálně, hoříme hlavně na storage.
    Kliknutím sem můžete změnit nastavení reklam