• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    ALMADDocker a kontejnery
    KING
    KING --- ---
    QUICK: na observability v Djangu mi dobre funguje Elastic APM, plus k tomu pres filebeat beru logy z nginxu a ze systemu (kvuli security auditum) a posilam na Elastic Cloud. Za par penez to mam komplet a kdybych chtel tak ani nemusim platit za ten Elastic Cloud a provozovat si to sam, sw je free.
    DWICH
    DWICH --- ---
    QUICK: Ahoj, do Stackdriveru (Google Cloud Logging) posílám klidně i všechny SQL queries v rámci debugu. Nejsou to milióny záznamů za sekundu, ale hodně jich je a na limit jsem zatím nenarazil. Můžeš zkusit mrknout na spojení Stackdriver + Django. Ohledně nginxu nevím, spíš loguju věci z aplikace než z webserveru
    QUICK
    QUICK --- ---
    RUDOLF: moc děkuji za podněty.

    Souběh běžích replik v různých verzích je s Djangem ok. Ale je samozřejmě potřeba myslet, když se nasazují nějaké destruktivní změny v db (odebrání sloupců nebo tabulek, přejmenování sloupců). U toho je potřeba trochu myslet :)

    S tím monitoringem máš pravdu, to bych měl zlepšit. Teď používám jen Sentry a Better Uptime, ale jsou nástroje spíš pro hašení než prevenci. Teď koukám, že New Relic má i sympatický free plan. Na to kouknu.

    Chtěl bych v budoucnu přejít na Digital Ocean, protože mají managed Kubernetes. Tohle je takový mezistav, abych si vyzkoušel všechny věci okolo.
    RUDOLF
    RUDOLF --- ---
    QUICK:

    - mi máme Django ve dvou EC2 replikách, udělal bych to stejně i ve swarmu, vlastně to tak mám asi pro wagtail. Při aktualizace service nahradí swarm ty repliky postupně myslím. Otázka jestli to nemá nějaký side-effect, když běží pár vteřin ty repliky souběžně, tj. že něco zapisuje appka se starým db modelem a něco appka s novým db model. Vůbec netuším jestli to má Django nějak ošetřený, ale děláme to tak na produkci:-)

    - GCP neznám, jen je rozumný tím kontejnerům nastavit limit v MB na logy a počet souborů. Obzvlášť pokud má host malý úložiště. Logy stejně posíláme do centrální služby a ta má zpravidla vlastní retenční politiku.

    - obecně je dobrý nechat ty appky běžet pod non-roootem.Tj. když tam není nějaký app-specific voser, tak se to vyplatí.

    Na co si dát pozor - monitoring hosta a kontejnerů, kdyby bylo nějaký issue, abys to viděl. Tj. je užitečný sledovat paměť, CPU a udělat si alerting. Samosebou, je dobrý monitoring SQL queries při debugování. Ale na to jsme používali New Relic, který má hezký insight do appky. Tj. app monitoring je vždycky dobrý:--)

    No a určitě je dobrý mít sepsaný postup, jak ten swarm budeš upgradovat:-) Pro mě upgrade clusteru hlavní důvod proč přejít do managed orchestraci:-) Dělám to pomocí nějakýho AWS CF od dockeru a jen se modlím ať to tvůrce udělal co nejsprávněji -> většinou je to jen nahrazení EC2 instancí novějšíma verzema dockeru. TTaky se hodí si vyzkoušet, jestli umíš obnovit stav swarmu, když ztratí raft konsenzus:-) Mě se to nikdy nepovedlo nahodit na testovacím prostředí a vždy jsem ty stacky znova deploynul. A na produkci se mi to nikdy nestalo.
    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)
    Kliknutím sem můžete změnit nastavení reklam