• ú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í
    FALLENANGEL
    FALLENANGEL --- ---
    SINC: A jaky nastroje pouzivate?
    SINC
    SINC --- ---
    FALLENANGEL: My mame kompletni infrastrukturu vcetne konfigurace k8s clusteru, networking, DNS, node groupy, helm ... v gitu a ciste pozitiva. Bez toho se neda delat review. Jedno repo je na sdilenou infrastrukturu (clustery, networking, ...) a kazdy aplikacni repo pak obsahuje svoje vlastni resources (s3 buckety, load balancery, ...).

    K prerotovani stejne jednou za cas musi dojit i na produkci, kdyz se updatujou nody. Navic jedem na spot instancich, takze oni stejne nezijou moc dlouho :)
    FALLENANGEL
    FALLENANGEL --- ---
    INDIAN: Jde mi spis o obecnej nazor, nez ze bych mel na mysli konkretni pouziti. Jeden muj zakaznik planuje mit vsechny definice infrastruktury i kod a nastaveni aplikaci v gitu a vsechno vcetne spravy ridit pres updatovani gitu. Dalsi zakaznik premysli nad docela zajimavym konceptem Dev clusteru, kdy vsechno bude opet nadefinovany v gitu a kazdej tyden stavajici cluster odstrani a z gitu vytvori novej, cimz se vyhnou nejruznejsim problemum, ktery muze hnijici Dev cluster prinest.

    Na druhou stranu slycham, ze GitOps jeste nejsou 'production ready', chybi poradnej tooling i standardizace workflow.
    INDIAN
    INDIAN --- ---
    FALLENANGEL: pro jaky pouziti? ja neco v podobnym duchu provozuju, ale sou to mozna dost specificky zalezitosti...
    FALLENANGEL
    FALLENANGEL --- ---
    Mate nekdo zkusenosti s GitOps? Pripadne nazory? Vnimam nejake smisene signaly.
    SH_PANDA
    SH_PANDA --- ---
    MARTEN: heroku?
    KING
    KING --- ---
    MARTEN: ja bych to poskladal z ruznych sluzeb a v nekterych vecech udelal kompromis, alespon ze zacatku. Napriklad potrebujes skutecne rabbitmq, nestacil by redis nebo sqs? Zbytek bych pak resil bud klasickym VM (EC2, GCP, ...) a nebo nejakou kontejnerovou sluzbou (ECS, GKE, ...) a hlavne bych se nebal externich sluzeb jako treba Elastic Cloud na ten elk nebo Citus pokud potrebuje hodne postgresu (vetsinou budou umet lokaci ve stejnem cloudu jako zbytek takze rychlost bude v pohode)
    REFLEX
    REFLEX --- ---
    MARTEN: tyjo vlastni projekty bych dal na cloud ve chvili kdy to vydelava penize a vzal bych na to nejakyho profika a udelal to s nim, strasne moc prace a na zacatku minimalni profit
    LITTLELI
    LITTLELI --- ---
    MARTEN: Podíval bych se na Hetzner https://www.hetzner.com
    SADY
    SADY --- ---
    MARTEN: za me aws a vlastni image postavenej na nejakem zakladu co ma vetsinu veci co potrebujes uz v sobe, lepe si pak muzes managovat upgrade na vyssi verze, zvednes jen to co uz je dele stable a opravdu vyuzijes ty nove features, je to nejaka rucni prace, ale zase mas plnou kontrolu vcetne detailu instalaci, napr. TZ apod.
    MARTEN
    MARTEN --- ---
    Uplne nevim jestli to davat sem, ale kdyz uz je tu debata o cloudech a toolech.
    Pro vsechny klientske projekty jsem vzdy mel moznost pouzit nejake self hosted cloud reseni (openshift,....). S AWS, GCP mam minimalni zkusenost. Ale ted mam vlastni projekt, ktery nechci hostovat na vlastnim serveru (i kdyz docker), ale rad bych to dal do cloudu. Hlavne kvuli SLA a protoze cekam vetsi navstevnost, tak skalovani muze byt taky dulezity faktor.
    Otazka je kam to nejlepe dat. Technologicky php, nodejs, python, postgres, redis, rabbitmq, elk. Kdyz koukam ne nektere cloud reseni, tak vetsina ma postgres, ale treba ne rabbitmq a elk. Vzdy tam muzu mit vlastni image, ale urcite by bylo prijemne pouzit pripravene cele reseni a nemuset zbytecne nic nastavovat. Je neco co osobne preferujete? Koukam i na cenu, precejen to zatim budu dotovat ze sveho, nejlepe i datacentrum v CR nebo blizko. Zahranicni traffic bude minimalni.
    DWICH
    DWICH --- ---
    Nejsem expert, takže s rezervou :) Co mi přijde super, že jsem vlastně nemusel nic nastavovat, pustím aplikaci v Google Cloud Runu (nebo Cloud Function) a ... věci fungujou tak nějak samy. Aplikace logujou, když mi aplikace hodí chybu, mám ji v GCP konzoli v errorech včetně stack trace apod. Mám aplikaci napojenou i na Sentry, ale je dobrý, že GCP tohle nějak sám ví, eviduje a nabízí nad tím featury jako Cloud Debugger, Trace atd. Že prostě ta platforma pro provoz a observability je integrovaná a vlastně dost věcí se nemusí ani nastavovat.
    Debugging, distributed tracing, and profiling for web applications
    https://www.youtube.com/watch?v=CjGv1bDy9rI


    Jo a na co se chystám, je Cloud SQL Insights. Využívá to https://google.github.io/sqlcommenter/ a poskytuje to dobrý data
    Get ahead of database performance issues with Cloud SQL Insights | Google Cloud Blog
    https://cloud.google.com/blog/products/databases/get-ahead-of-database-performance-issues-with-cloud-sql-insights
    https://www.youtube.com/watch?v=qN7x3ngwz1o
    KING
    KING --- ---
    RATTKIN: jj, v djangu to jde i hezky propojit, ze je videt transakce z klienta az do databaze, klidne pres nekolik service. Bez toho bych si casto prisel jak slepy
    RATTKIN
    RATTKIN --- ---
    APM je super, hlášení chyb v jedné konzoli spolu s výkonnostními údaji.
    pro SPA je taky výborný RUM - to samý jako APM, ale na klientu
    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?
    Kliknutím sem můžete změnit nastavení reklam