• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    SPACEANGELContinuous integration, App Deployment
    Pouzite metodiky, nastroje, CI servery, na kolik CI pouzivate, nakolik byste ji chteli pouzivat, proc ji pouzivate, ci naopak - proc ji nechcete pouzit...
    rozbalit záhlaví
    URPUTNIK
    URPUTNIK --- ---
    URPUTNIK: tak neznate, vydaj to az v kvetnu :( nejaka podobna osvedcena alternativa?
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    https://www.oreilly.com/library/view/kubernetes-patterns/9781492050278/ mate, znate, doporucili by jste?
    URPUTNIK
    URPUTNIK --- ---
    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
    DWICH --- ---
    1 odpověď
    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
    DWICH --- ---
    1 odpověď+3
    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
    URPUTNIK --- ---
    1 odpověď
    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
    ALMAD --- ---
    1 odpověď+1
    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
    URPUTNIK --- ---
    1 odpověď
    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
    MUXX --- ---
    1 odpověď
    URPUTNIK: Pises, ze “...Se to bude poustet...”. Ja myslim, ze prave ten “Se” by mohl tak nejak definovat kde to chce mit .)
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    ALMAD: je to mix ruznych adresaru a souboru, podle sluzby, xml, php, properties, ..
    ALMAD
    ALMAD --- ---
    1 odpověď
    URPUTNIK: Čemu přesně řikáš konfigurace / co v ní je?
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    tak uz mam zase cas venovat se CI :) diskutovali jsme tu, jakym zpusobem vystavovat souborovy konfigurace pro jednotlivy service (je mix vseho moznyho), protoze se to bude poustet v K8S, ktery to teda bude muset odnekud brat .. takze, pokud pouzivate souborove konfigurace, jak je vystavujete tak, aby je mel dostupny i cluster? zatim se klonime vystavit je pres NFS server, ktery se pusti jako sluzba v clusteru

    resime to kvuli tomu, ze musime resit i branche, aktualne je v planu v clusteru poustet cele prostredi pro danou branch .. coz znamena teda v clusteru pod vlastnim namespace pustit treba 15sluzeb .. kazdopadne tohle prostredi potrebuje konfiguraci, neco je pro konfiguraci uvnitr clusteru mezi servicama, neco je na veci, ktere nejsou a nebudou clusterovany .. takze plan je pouzit docker image s upravenou konfiguraci (konkretizace sablony konfigurace pro danou branch), ktery se vystavi pres ten nfs server .. lepsi napad?

    (edit: upraveno o to, co jsem se dozvedevel v ofiko dokumentaci o adresovatelnosti)
    RUDOLF
    RUDOLF --- ---
    +2
    URPUTNIK: Je to spíš o tom, jak blízko chceš být best practice. Ale obecně, jde o to to nasadit podle vašich potřeb a možností a ty jsou všude jiný. Každápádně, obecně ty best practice mají imho smysl.

    a.) Máme sice image v privátním dockerhubu. Repo se zdrojáky v privátním gitu. Ale jakmile k těmhle věcem má přístup nový dev nebo třetí strana. Můžou secrets vynést ven. Asi jim můžeme důvěřovat, ale třeba taky vůbec ne. Tj. chci poskytnou kontejner bez secrets a přístup k repozitáři tak, aby ideálně ani naši devs, nemuseli znát hesla k ničemu. A jim to i tak vyhovuje. Tj. pokud security není problém, tak bych klidně skrz ENV jen volal konfiguráky pro dané prostředí, což už v kontejneru jsou. Jestli je to security priorita, tak bych určitě šel cestou vkládání konfigruace až při deploy.

    b.) Já třeba provozuji Swarm, u některým old school appek jsem musel secret vkládat do swarmu, aby si ho kontejner přimountoval jako soubor. Mělo to jeden nemilej důsledek, když jsem kontejner aktualizoval, musel jsem připojit novej secret a starej odebrat páč swarm neumí update operaci nad secret/config (měl jsem ošklivej bash na přidání secret_temp, odebráný původního secret, přidání nového secret a odebrání secret_temp:-). Když jedu jen z ENV tak nic neřeším a nemusím používat Swarm secrets. Mám pocit, že podobně je to i v Kubernetes. Že config/secret objekt musíš nahradit a nemůžeš udělat update, tak je snažší to všechno rvát přes ENV.
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    MUXX: RUDOLF: chapu vas .. ale protoze ted mame konfiguraci vytahanou do vlastnich souboru (a je jich hodne), prijde mi nejlepsi metoda namountovat do image ty spravny soubory (nez abych to cely tahal do promennych a resil to dplnovani, protoze jsou to 3 ruzny technologie apod) ..

    kazdopadne, ten duvod "proc nedavat secrety do image" je ten, ze se pak neda reusnout image v jinem prostredi, nebo je to kvuli bezpecnosti (protoze image snadno leakne)?
    RUDOLF
    RUDOLF --- ---
    1 odpověď+3
    URPUTNIK: já to dělám tak, že mám docker compose (pro swarm) jako ansible template, podle toho kam se to deployuje (local, test, prod), ansible vyplní proměné. Když je to test/prod, tak to ansible krmí z vaultu.
    MUXX
    MUXX --- ---
    1 odpověď+1
    URPUTNIK: Jop. Mas nejaky startup skript, ktery nacte env var a nacpe je kam patri. Ja php aplikace nemam ale treba by te inspirovalo toto: https://github.com/linuxserver/docker-projectsend/blob/master/root/etc/cont-init.d/30-config
    URPUTNIK
    URPUTNIK --- ---
    2 odpovědi
    MUXX: jedna z aplikaci, kterou bude dockerizovat, jsou stare php skripty .. takze jestli te chapu dobre, navrhujes pres environment variables dostat udaje do docker-compose, ktery s nima prepise nejaky prazdny hodnoty ve zdrojacich?
    MUXX
    MUXX --- ---
    1 odpověď
    URPUTNIK: Heh to je tak dlouhy ze vlastne nevim co chces :) konfiguraci mas jako environment variables ne? Nastavujes to pri deploy. At uz to dela jenkins nebo ansible. To nestaci?
    URPUTNIK
    URPUTNIK --- ---
    1 odpověď
    tak jiny, predpokladam casto pokladany, dotaz :) runtime konfigurace pro kontejnery .. predem - vim ze a proc, nemam konfiguraci cpat do kontejneru :) neresim secrety, ktery potrebuje build (napr pristupy na privatni repo, do gitu ..), ale ty, co jsou potreba v runtime aplikace (pripojeni do databaze, dalsi endpointy v nasi SOA) .. ty zpravidla zalezi na konkretnim prostredi i verzi aplikace

    aktualne mame konfigurace soucasti stejny repo jako zdrojaky, kvuli svazani verze konfigurace s verzi aplikace ... jsou teda vysypany v gitu bokem, mimo adresar se zdrojaky, takze do nasazene aplikace se doplnuji az deployment skripty, ktere si git-repo checknou ..

    moje prvni idea byla defakto zbuildit (dockerizovat) cistou app bez konfigurace, adresare s konfiguraci checknout tema deployment skriptama (defakto stavajici model) a zkompletovat pri pousteni .. tam bych ale musel checkovat repo z nejakeho konkretniho commitu (tzn asi si predavat commit hash pres tag u image, viz RUDOLF)

    dalsi varianta byla zbuildit image s aplikaci a v ramci jeho FS nechat nekde bokem konfigurace pro vsechny prostredi (aka verze prvni, ale bez gitu, konfigurace se sveze s image), ale prijde mi, ze to porusuje to 'nedavejte konfiguraci do kontejneru :)

    takze ted zvazuju, ze bych v ramci jednoho buildu vyrobil vic image (napriklad jeden jen s aplikaci + image pro kazde prostredi jen s konfiguraci, jejich kompletaci pak vyresi treba docker-compose) .. defakto bych potreboval obraceny multi-stage build, tusite o nejakem? ritim se do zahuby? :)
    SEZI
    SEZI --- ---
    +1
    RUDOLF: jsem líný hledat jak je to přesně, ale IMHO git od novějších verzí pro tyhle --short a --abbrev a podobné parametry zajišťuje jakousi unikátnost, tzn. pokud je potřeba prodlouží délku vypsaného short sha stringu aby zajistil unikátnost.

    někde jsem tuším viděl že když by tam ten konflikt na abbrev hashi opravdu byl (např. mám někde poznamenaný starý krátký hash, který od té doby dostal duplicitního kamaráda), tak se bude používat ten hash který se v repu vyskytnul v historii jako první (ale tady možná vařím z vody)

    nicméně ve skriptech pracuju s celým SHA1 a krátké varianty spíš informativně někde jako label na webu
    RUDOLF
    RUDOLF --- ---
    2 odpovědi+2
    RUDOLF: Když si ten image:tag přepíše jednou za pár let, tak to stejně bolet nebude..

    ale hezké ukázky..

    "Generally, eight to ten characters are more than enough to be unique within a project. For example, as of June 2018, the Linux kernel (which is a fairly sizable project) has over 700,000 commits and almost six and a half million objects in its object database, with no two objects whose SHA-1s are identical in the first 11 characters."

    "Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (6.5 million Git objects) and pushing it into one enormous Git repository, it would take roughly 2 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. Thus, a SHA-1 collision is less likely than every member of your programming team being attacked and killed by wolves in unrelated incidents on the same night."
    Kliknutím sem můžete změnit nastavení reklam