MLEKAR_STEIN: zapomnel jsem to zminit, ma to byt pouze na dev

tak zavisi, jak moc to musi byt production ready.

taky se.da vytvořit docker network,.te udělat bridge se sitovkou a nastavit routování. pak je ta sit dostupna.
je to docela hack, ale da se to relativne automatizovat.
a pak se da udelat autoregistrace do dns. to ani hack neni, jen clovek musi mitinteeni dns.
pak to muze vypadat tak,ze na fyzickym serveru mam sit propagovanou ven a kontejner z te site se autoregistruje do nejake subdomeny
a pak se da ke kontaku pristupovat pres dns jmeno :)

REFLEX: Ty porty bych nedelal, protoze pak by si musel pres host. Poslu ti jak to mam :) Exposnout port DB je dobre pro tebe at se pripojis pres gui, ale ne mezi serivces

WOODMAKER: pravda to by slo taky, proste by exposoval port databaze, mozna jednodusi reseni

a nestaci, aby ten hlavni web exposnul nejaky porty? Ale ta stejna network zni lip.

REFLEX: tak musi byt na stejne network https://stackoverflow.com/questions/38088279/communication-between-multiple-docker-compose-projects

Mam n webu, kazdy ma svoje git repo a potrebuji pro ne rozbehat vyvojove prostredi

Kde je 1 hlavni web, ktery ma databazi na kterou se pripojuji i ty ostatni weby.

Jde se pripojit z jednoho docker-compose do druheho? Jak na to? :D

Muj plan je takovy ze v kazdem projektu by byl docker-compose a clovek by musel nejdriv pustit ten hlavni a pak ten nejaky jiny na kterym pracuje a komunikovali by mezi sebou

Mate nekdo trik jak udelat podman pull v rootles kontejnerech?

sh-4.4$ podman pull registry.redhat.io/ubi8/ubi:latest
WARN[0000] Failed to detect the owner for the current cgroup: stat /sys/fs/cgroup/systemd/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod2f195ec9_139e_4aa4_a216_b234d869a681.slice/crio-f86c6929612ccad07edd12119f4a968c2dad830e335500fc21416995225fb4e2.scope: no such file or directory
Trying to pull registry.redhat.io/ubi8/ubi:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob d0c9851d609d done
Copying blob 33db084abe90 done
Copying config 0724f7c987 done
Writing manifest to image destination
Storing signatures
Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:81 for /usr/libexec/dbus-1/dbus-daemon-launch-helper): Check /etc/subuid and /etc/subgid: lchown /usr/libexec/dbus-1/dbus-daemon-launch-helper: invalid argument
Error: Error committing the finished image: error adding layer with blob "sha256:33db084abe90803d3c1ed1fa2db456724adb80961c94c09f91bf5b2c046a9008": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 0:81 for /usr/libexec/dbus-1/dbus-daemon-launch-helper): Check /etc/subuid and /etc/subgid: lchown /usr/libexec/dbus-1/dbus-daemon-launch-helper: invalid argument

Why can’t rootless Podman pull my image? | Enable Sysadmin
https://www.redhat.com/sysadmin/rootless-podman

RUDOLF: AWS CDK > Terraform > Rucne vyklikat > Pulumi > Azure ARM :D

VELDRANE: Na tom asi neni nic spatnyho. Velka cast korporatnich zakazniku ma Azure first. I kdyz to asi neni uplne best of breed cloud.

MORTAELTH: Problem Tomase je trosku v tom ze je zamestnanec MS a tak imho dost tlaci Azure a ekosystem kolem nej, i kdyz je to nepochybne hodne chytrej typek.

Hele a co porovnání TF CDK a pulumi? Máte někdo zkušenosti?

MORTAELTH MORTAELTH: Díky!

MORTAELTH: za mě je to furt jen IaC a devops jen tooling se vyvíjí. Ale po téměř roční zkušenosti, že jsme v enterprise psali python wrapper kolem terrafromu, který řešil multiaccount, multitenant appraoch, kde máme koncept jednoho prostředí v kterým je n+ užitavatelských prostředí. Mi Pulumi přijde že je to správný řešení IaC v cloudu. A ústup od deklarací mi dává smysl, už z principu, jaký monstrum jsem tím wrapperem TF vytvořili:-)

ALMAD: a taky uz se od terraformu postupne odvazbuji. Jejich SDK byl puvodne automaticky konvertovany terraform. Ted treba pro Azure uz ale maji novou knihovnu, ktera je generovana z Azure ARM template. Tzn maji v rozumne dobre pokryte 100% azure api a nejsou zavisly na terraformu, ktery ma vetsi zpozdeni

ALMAD: nejvetsi vyhoda je vyuziti evoluce programovacich jazyku a toolu kolem toho. Vyuziti typovosti, interfacu, atd.

a ten bonus sideffect u nas bylo zapojeni vyvojaru do infrastruktury. Ucit se ansible / terraform byl problem.

MORTAELTH: Ad Pulumi, jaký to má výhody proti terraformu?

Já mám většinou pocit, že deklaarativní tooly maj omezenou flexibilitu a v nějakej moment do něj lidi začnou rvát imperativní funkce aby se nezbláznili, ale přijde mi, že v TF to s modulame et al funguje rozumně dobře a zrovna pro účel deklarace zdrojů mi deklarativní přístup přijde...odpovídající?

A jenom ta struktura, rozumim tomu dobře že jsou pořád oddělená repa pro definici kódu a definici infrastuktury? (což mi přijde rozumný, jenom ze stránek Pulumi to dává trochu jinej dojem)