Tento web používá soubory cookie. Dalším používáním webu s tímto souhlasíte.
jméno
heslo
přihlásit
zaregistrujte se
zapomněli jste heslo?
Continuous integration, App Deployment
SPACEANGEL
Pouzite metodiky, nastroje, CI servery, na kolik CI pouzivate, nakolik byste ji chteli pouzivat, proc ji pouzivate, ci naopak - proc ji nechcete pouzit...
Máte k tomu co říct? Vložte se do diskuze.
URPUTNIK --- 12:45:07 18.4.2019
URPUTNIK: tak neznate, vydaj to az v kvetnu :( nejaka podobna osvedcena alternativa?
URPUTNIK --- 12:29:49 18.4.2019
URPUTNIK --- 12:00:06 18.4.2019
DWICH: jasny, tohle znam, aplikace tak vicemene jsou napsany ..

pro mne aktualni orisek je, jak dynamicky vyrabet konfiguraci pro prostredi .. kazdopadne vedli jsme tu diskuzi s druhym vyvojarem a dospeli jsme k tomu, ze nechceme prejit hned/rovnou na ukladani secretu do vaultu .. prvni/mensi krok je vyrabet konfiguraci dynamicky, ale persistovat ji do docker image (uz to ze to bude docker image, je velka zmena) .. samozrejme ze vyhledove se dostaneme i k vaultu, ale asi ne hned/ted :) kazdopadne je urcite dobre delat to s predstavou toho, kam se clovek chce dostat a zohlednovat to, viz DWICH, takze diky :)
DWICH --- 11:40:37 18.4.2019
Je to starý a i když s tím člověk nemusí souhlasit, stejně je praktický si to přečíst:
The Twelve-Factor App
https://12factor.net/
Konkrétně:
The Twelve-Factor App
https://12factor.net/config
DWICH --- 11:39:07 18.4.2019
URPUTNIK: Koukni se taky na to, jak konfiguraci v kube clusterech řeší ostatní, jaký na to jsou best practices a pak se jim zkus přiblížit. Bude to lepší, než kdybyses na to nepodíval a zkoušel to vymejšlet sám a třeba cestou právě antipatternů.

Zrovna v kube je praktický ty konfigurace předávat např. jako env proměnný nebo je tam dotáhnout z nějakýho nástroje na správu secrets. A to právě proto, abys nemusel mountovat disky a na nich pár souborů s nastavením.

Kdybys měl team rozdělenej na dvě části (může to bejt i ten stejnej člověk, ale má tím pádem zároveň dvě role), tak jeden z nich je vývojář, kterej udělá tu aplikaci a doručí docker image. Druhej z nich je provozák, co má pod palcem infrastrukturu, stará se o secrets, který k tý infrastruktuře patří, stará se o env nebo jiný konfig proměnný, co k tomu taky patří.

Zkus se na to podívat z pohledu toho provozáka, jakej je nejlepší stav pro něj - mít secrets uložený v nástroji na to určenýmu a mít config taky uložený tak, jak je to správně (pro tu infrastrukturu). Pak vyvolej byť třeba fiktivní diskuzi na téma, jak to udělat, aby vývojář udělal aplikaci hostovatelnou na infrastruktuře, která má secrets a konfigy uložený podle best practices a ne podle toho, že to tak vývojář chtěl.
URPUTNIK --- 10:28:54 18.4.2019
ALMAD: super, to mne posunulo v tom, co mam googlit dal, diky :)

pro mne je to mix secrets (pripojeni do databaze, ktera je pustena v jinem podu), nejaka url glue magie (ale podle tohodle a tohodle bude daleko mensi nez aktualni pro nedockerizovany a neclusterovany prostredi, protoze to pojede mimo frontendu po k8s dns) a runtime konfigurace (treba produktovy/business definice v xml, ktery se v runtime loaduji ..)
ALMAD --- 17:53:00 17.4.2019
URPUTNIK: To co chceš udělat (namountuj remote storage) mi přijde v K8S prostředí jako antipattern, proto se snažim dobrat coho co v tom je, abych ti dokázal říct, co s tim.

Secrets? Pak by to chtělo odpovídající storage, třeba Vault.
Nastavení závislostí / lokace / služeb? Použij service discovery, etcd nebo whatever.
Nějaký url glue co to drží pohromadě? Pak to možná má být součást buildu co to zapeče do image.
Něco jinýho? Třeba to má bejt separátní služba, normální databáze, runtime konfigurace a nebo pentagram na vyvolávání konzultantů.

Bez toho abych věděl co rozumíš pod slovem konfigurace se to řiká špatně ;)
URPUTNIK --- 17:26:25 17.4.2019
MUXX: o k8s se u nas stara nekdo jiny, takze mozna mluvim trochu z cesty :)

kazdopadne jsem tu diskuzi o deploymentu pochopil tak, ze v typicke konfiguraci se v clusteru pusti pod, ktery obsahuje jednu docker sluzbu ..
ta docker sluzba ale potrebuje konfiguraci, v nasem pripade soubory, ktere se do toho docker image namountuji 'zvenci' .. protoze se budou poustet v clusteru, musi tam konfiguraci namountovat cluster
pochopil jsem, ze v k8s se tomu rika volume (resp volumeClaim), coz je defakto odkaz na nejaky uloziste (typicky treba pro zapis dat, aby se nedrzely v docker kontejneru) .. ale stejne tak to muze byt read-only odkaz do fs, kde jsme chteli vystavit ty soubory s konfiguraci ..
a protoze budeme chtit vyrabet tyhle konfigurace pro kazdou branch, vymyslime zpusob, jak nemuset neustale aplikovat novy .yaml file pro definici novych volume (s upravenyma konfiguracema pro danou branch) ..

posledni napad je, ze se v k8s pusti nfs server, ktery je bude vracet (tzn jenom prebuildime ten image pro nfs server a k8s si ho aktualizuje na novejsi)
MUXX --- 13:32:32 17.4.2019
URPUTNIK: Pises, ze “...Se to bude poustet...”. Ja myslim, ze prave ten “Se” by mohl tak nejak definovat kde to chce mit .)
URPUTNIK --- 9:13:57 17.4.2019
ALMAD: je to mix ruznych adresaru a souboru, podle sluzby, xml, php, properties, ..