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?

QUICK: Pokud nepotrebujes primo EC2, tak AWS LightSail ma 3TB transfer zahrnuty uz v $10/mesic planu. Ale tam je zase otazka, jestli ti staci jeden virtualni procesor, 2GB RAM a 60 GB SSD, ktere ten konkretni plan nabizi. Co jsem to kdysi pocital, tak LightSail vychazel podobne jako EC2, jen s vyrazne vetsim objemem dat v cene. Jen tam mas o hodne mensi moznosti konfigurace oproti "plnemu" EC2...

QUICK: Ja mam stejny setup (Django, Postgres a Elastic) a pouzivam to bez dockeru protoze mi to prislo jednodussi, jak to delam ja:
* docker pull
* pip install -r requirements.txt
* migrate/collectstatic/...
* restart gunicorn

Postgres i Elastic (take jeden node, kdyz neni potreba vic, tak je za nej zbytecne platit, nikoho zabijet nebudu :) ) mam na cloudu protoze to nechci resit (RDS a Elastic Cloud). Celkovy naklady na provoz jsou hluboko pod $100 mesicne na AWS (t4g.micro, t2.micro RDS a 1 node na elastic cloudu, mame ale zatim maly traffic).

Pokud uz to mas dockerizovany tak bych doporucil:
* nahrat novou image s novou verzi aplikace
* pustit docker
* idealne pustit nejaky smoke test
* prepnout nginx aby ukazoval na novy docker
* zabit stary docker

Budes to mit uplne bezvypadkove pokud ti to logika dovoli - nekde budes muset prizpusobit jak delas napriklad migrace aby sli delat tak, ze stara verze bude moct stale mluvit s novou DB.

KING: FALLENANGEL: Rád bych to rozebral konkrétněji. Provozuju střední web, historicky to běží na třech VPS instancích - jedna pro web (Django), jedna pro Postgres, třetí Elasticsearch (KINGu ty mě asi nakope za provoz elasticu na jednom nodu, ale pro ty objemy vyhledávání co mám je to zatím v poho)

Všechno teď mám nainstalované přímo v systému bez dockeru. Nasazení nové verze jsou v zásadě tři příkazy:
- git pull
- případná aktualizace db přes python manage.py migrate
- restart gunicornu

Což je pro mě docela jednoduchý na nasazení nové verze aplikace, a když se všechno povede, tak návštěvníci výpadek nezaznamenají. Ale uvědomuji si, že to není správný řešení. Nedá se spolehnout, že na devu a produkci se používají stejné verze všech balíků a knihoven. Updatu systému (apt get) / restart mašiny není bezvýpadkový a je potřeba se předtím pokřižovat, aby se nic nevysypalo. atp.

Lokální vývojové prostředí už do mám dockerizované, ale pořád se odhodlávám, jak to úspěšně převést na produkci. CI, Kubernetes a většina devops věci jde tak nějak mimo mě. Dokázali byste mě navést jaký zvolit postup?

Hlavně bych chtěl aby výsledný řešení bylo tak akorát robustní, nasazení bylo rychlý, předcházelo se výpadkům při nasazení a případný rollback, šel udělat rychle. V úplně nejdivočejších snech bych v budoucnu chtěl ještě spustit jeden extra cluster v Americe (django, postgres jako slave), aby dokázal pokrýt read-only requesty z Ameriky.

A AWS/Google cloud jsem nikdy nepoužíval, ale asi při mém trafficu (2-3 TB měsíční outbound) by to asi lezlo do peněz.

QUICK: Dobra otazka. Predpokladam, ze existuji i jine orchestracni platformy nez Kubernetes, ale vsechno co me ted napada jsou vlastne platformy postaveny prave na Kubernetesu (Rancher, Tanzu, GKE).

KING: Myslel jsem to tak, ze jedna aplikace ma vice komponent, kazdou v jinym kontejneru. Takze spis jde o to spustit kontejnery s novou verzi, presmerovat na ne ingress a smazat stare kontejner.

QUICK: samozrejme, stejne jako slo resit zero downtime deployment bez kontejneru. Typicky proste staci neshodit vsechny kontejnery najednou, ale jeden po druhym a nahradit je novym. Pokud je tam zabudovana redundance, tak to staci. Konkretni provedeni zalezi na zpusobu orchestrace

FALLENANGEL: pokud mám "appku v pár kontejnerech", jde řešit zero downtime deployment bez Kubernetes?

JON: :P 'jako jo, no...'

REFLEX: Jako jo, Kubernetes zvlada orchestrovat opravdu velky prostredi, takze pokud mas jednu malou appku v par kontejnerech, je to trochu overkill. Na druhou stranu kdyz tomu venujes cas a naucis se to, tak s nim muzes delat opravdu zajimavy veci. Nemluve o tom, o kolik stoupne tvoje cena na trhu prace ;)

Jenom si ted nejsem jistej, jestli porad podporujou Docker jako container runtime.

REFLEX: jako jo, a ne - kdyz chces jen pustit par apek v kontejnerech je to nesmysl.
Ale jakmile nad tim chces nejake blue-green, canary deploymenty, nebo rolling update / zero downtime, pripadne testy celeho deploymentu usetri to fakt hrozne moc prcani.
Proste to tam uz je vymysleny a udelany, a kdyz to budes chtit zorchestrovat nejak jinak, tak to budes muset napsat nejak sam.

REFLEX: Asi jdu s krizkem po funuse, ale tohle velmi dobre zvlada Kubernetes, jak psal MUXX.

Deployments | Kubernetes
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

Pokud by te zajimaly blue/green nebo canary deploymenty, tak si mysli, ze bys potreboval ke Kubernetu nasadit Istio, ktery to zvlada velmi dobre.

A este jeden dotaz - na fyzickem stroji si spoustim LXD container, uvnitr nainstaluju docker, v docker neco spustim - potud krasa nadhere, presne to co jsem hledal. ALE:
Pokud je LXD container ubuntu/18.04, ubuntu/20.10 nebo debian/9 (z ofiko image repa) tak to bezi OK.
Kdyz je ale LXD container debian/10, tak sam se na internet dostane, uvnitr nej bezici docker kontejnery se ale na internet dostanou jen kdyz jsou privileged. Hazi to (pro me) dost nezvyklou hlasku:

root@test-lxc-d10:~# docker run --rm busybox ping -c 4 8.8.8.8
ping: can't create raw socket: Permission denied
PING 8.8.8.8 (8.8.8.8): 56 data bytes

K internetu se nedostane ani ping, ani wget, ani nic jinyho (jako ze to neni problem s pingem).
Nenapada vas, cim to muze bejt?
Pripadne jak nejak low-level debugovat networking?

Nevite o nejakem lightweight nastroji, ktery by mi usnadnil startovani N LXC kpntejneru a nejaky sitovani kolem toho? Neco jako docker-compose.
Vsechno co jsem nasel je bud kanon na vrabce, nebo dyl jak rok neudrzovany.

REFLEX: Docker-compose umi scale ne? Zvednes na dva, pockas, snizis na jeden. Samozrejme kubernetes ti to udela samo, ale to nechces pro jeden docker-compose

Mam dalsi dotaz :D aspon to tu zije

Jak resite 0 downtime releasy?

Mam docker-compose - container na front end (nodejs) a back (php) a cele to "routuje" nginx, ktery expouje 80 a 443 port.

Vite o nejakem clanku/tutorialu? :)

Mozna to nepoustet pres docker-compose?

REFLEX: By default nejsou (host ip muze bejt verejna a dockery muzou brat adresy z privatniho rozsahu, exponujic jen explicitne recene porty). Samozrejme kolize muze nastavat na tom stroji, tj. kdyz dockerum das privatni rozsah, tak provoz ku 192.168.0.1 pujde z toho stroje na bezici docker s touto adresou, ne na jiny stroj s touhle adresou.

Ahoj, mam dotaz na docker-compose, mam server, ktery je v nejake vnitrni siti, na servery jede docker-compose a 4 kontejnery, ted se stalo ze ty kontejnery sezrali IP 192.168.0.1 (nebo neco podobneho) co zaclo kolidovat s tou vnitrni siti.

Je tam asi default docker co jede network v bridge modu.

Jestli to teda chapu tak v ramci vnitrni site jsou kontejnery dostupne z ostatnich pocitacu? :)

Realne nemam moznost to vyzkouset, zkousel jsem procitat dokumentaci a jeste budu :)

Ahoj

nepotuluje se tu zkuseny devopsak se zamerenim na azure & aks ekosystem na par (placenych) konzultaci?

MARTEN:
to jsem zkousel pokud neni v image/vytvorenej user tak kdyz das jenom parameter user a spustis v conteineru interaktivni shell tak mi to napise neco jako i don't know user name a pak kdyz das vytvorit file tak ho vytvori jako root. (docker 18.09.5)

RAGNAROK: Docker by soubory mel vytvaret pod uid uzivatele, ktery je uvnitr containeru. Container by nemel bezet jako root. Zkus jestli by ti nestacilo spustit container s parametrem --user 1000:1000. Mozna by ti to mohlo stacit, pokud chapu dobre tvuj problem.
Omezeni na host filessytem je tezsi. Docker daemon defaultne snad vsude bezi jako root, takze kdo se bude snazit, dostane se na jakykoliv soubor v systemu jen s pouzitim hello-world containeru. Ale jestli to neni sdileny server, asi te to nemusi trapit.