• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPACEANGELContinuous integration, App Deployment
    URPUTNIK
    URPUTNIK --- ---
    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 --- ---
    URPUTNIK: Pises, ze “...Se to bude poustet...”. Ja myslim, ze prave ten “Se” by mohl tak nejak definovat kde to chce mit .)
    URPUTNIK
    URPUTNIK --- ---
    ALMAD: je to mix ruznych adresaru a souboru, podle sluzby, xml, php, properties, ..
    ALMAD
    ALMAD --- ---
    URPUTNIK: Čemu přesně řikáš konfigurace / co v ní je?
    URPUTNIK
    URPUTNIK --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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 --- ---
    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."
    RUDOLF
    RUDOLF --- ---
    používáte někdo na tagování: git rev-parse --short HEAD ?

    Asi není pravděpodobný že při 1000-10000 buildech se ten hash zopakuje dvakrát?
    URPUTNIK
    URPUTNIK --- ---
    JON: "by mel" :) ale stavalo se nam, ze jsme meli treba neuplny pom (takze nejaky nastaveni sly 'z defaultu', ktery se ale mohlo podle lisit na kazdem stroji co to buildil) .. taky nam obcas litaly konkretni verze javy (resp patche), napriklad jdk1.8.0_131 a jdk1.8.0_181 (btw, da se to nejak lip specifikovat v pomu? nasel jsem ze muzu nastavit JAVA_HOME, ale na co vlastne bude ukazovat neomezim)
    u nas je to jeste specificky tim, ze 'netagujeme' maven buildy (aka v masteru je snapshot a mel by byt nasaditelny kdykoli) .. ale to nas nuti napriklad na nexusu zahazovat starsi verze snapshotu (aby se to zbytecne nehromadilo, kdyz si maven stejne stahuje tu nejnovejsi verzi) .. do dusledku, kdyz se nasazuje dalsi verze do produkce, clovek ma 2 buildy, ktery jsou oba snapshot, ale ten co je nahrazovan uz nemusi byt v nexusu (protoze od ty doby bylo vic commitu, aka buildu), proto ta zaloha
    ADMIX
    ADMIX --- ---
    WOODMAKER: CI/CD :)
    WOODMAKER
    WOODMAKER --- ---
    A máte nějaký způsob, abych už jednou vydanou image už nikdy neztratil? Abych ji jako omylem nepřepsal.
    JON
    JON --- ---
    URPUTNIK: ok, jasny - ale ten build z mavenu by mel bejt 100% deterministickej podle dodanejch zdrojaku, ne? Ale chapu, ze pro sichr to tam jeste zazalohujete..
    Jinak presne jak rika ZOID - protoze (s dockerem) i minula verze byla nasazovana pomoci image, tak je automaticky zazalohovana tim imagem.
    Kliknutím sem můžete změnit nastavení reklam