• ú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 --- ---
    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)?
    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.
    ZOID
    ZOID --- ---
    URPUTNIK: Ta „původní verze" může být otagovaná už z buildu. Takže by to pak odpovídalo tomu spustit bud image:puvodni_verze nebo image:nova_verze.
    Osobně se domnívám, že je v produkčním prostředí výhodné vždy explicitně specifikovat tag určující verzi. Předejde se tak nepříjemným překvapením.
    Osobně používám k tagování část commit hash, abych si svázal bežící službu s kódem.


    URPUTNIK
    URPUTNIK --- ---
    JON: v gitu jsou zdrojaky, maven to zbuildi a nasype do nexusu .. vysledny binarky uz do gitu nesypem ..
    JON
    JON --- ---
    URPUTNIK: proc tam mate zalohu minule verze? ta by mela byt v gitu, ne?
    URPUTNIK
    URPUTNIK --- ---
    jsem v noci nemohl spat a zamyslel se nad deploymentem .. ted (bez dockerizace) nase deployment skripty nejdriv zalohujou puvodni verzi, pak ji premazou novou verzi a pusti ji .. kdyz je problem, clovek se vrati k zaloze ..
    rekneme ze bychom to dockerizovali a zdrojaky budou zabaleny uvnitr image .. jak se "zalohuje predchozi verze", kdyz se budem bavit o imagich? zatim mne napada vygenerovat nejaky unikatni id (ktery odpovida instanci deploymentu), tim otaguju stavajici image, pullnu novej, pustim ho .. kdyz bude problem, aktualne pusteny vypnu a pustim ten puvodni pres tag .. tak nejak?
    JON
    JON --- ---
    ADMIX: aha, tem filosofickejm duvodum rozumim, to je celkem jasny a pochopitelny.
    me slo spis o to, ze ten pripad, kdy to pouziju jako deployment mechanismus a data ukladam do mountovaneho volume, je taky nedoporucovany. Me tam napada jen nadbytecna vrstva mezi databazi a diskem, ale to mi prijde jako malej duvod proti.
    kazdopadne stejne pouzivame db v dockeru na development, a na produkci jsou db, kafky apod. normalne instalovane.
    tak kdyby i nekdo dalsi vedel proc se tomuvyhnout, nebo jaka rizika hrozi, tak by me to zajimalo.
    ADMIX
    ADMIX --- ---
    JON: To je takovy tema na delsi povidani :)) Ale pro me osobne je potencialni problem treba to, ze kontejner v ramci beznejch deploymentu typu kubernetes je zavrenej do cgroupy s jasnyma limitama, a pokud ti treba databaze vybehne v pameti, tak kontejner dostane OOM a nazdar.
    A deployment typu "vezmu si celej stroj a do nej si pustim jeden kontejner bez omezeni zdroju a mimo scheduler" pro me neni dobrej priklad kontejnerizace, ktera by (opet podle me) mela bejt dynamicka, immutable a co nejvic stateless, aby byl ten system schopnej reagovat rychle a bez dependenci.
    Dalsi vec je ze databaze obvykle neni neco, co budes zapinat a vypinat v ramci autoscalingu.

    Asi by se dalo uvazovat o kontejnerovy databazi ciste jako deployment mechanismus, ve smyslu ze to spusti nakej skript z cloud-initu tim, ze stahne docker image a pripoji si nakej EBS volume, ale s tim popravde zkusenost nemam.

    V minuly praci jsem delal prototyp docker image pro developery, kde meli oracle databazi v kontejneru, kterej trval par minut stahnout a spustit, na dev ucely uplne v pohode.

    Zadnou vetsi zkusenost bohuzel nemam, muj projekt v minuly praci management utratil jeste v postylce, a v soucasny praci jsme sice The Cloud, ale interne se jedou stary, stabilni systemy z dob, kdy kontejnery jeste nebyly :)
    JON
    JON --- ---
    ADMIX: o problemech s databazemi v kontejnerech jsem slysel, ale informace ktere k tomu mam jsou takove "kargokulticke": proste to nedelejte, je to spatny a shnijou vam nehty na nohou. you were warned.
    Mas k tomu nejaky blizsi info? Nerkuli snad osobni zkusenost?
    ADMIX
    ADMIX --- ---
    URPUTNIK: Pro me osobne je diskutabilni uz samotna databaze v kontejneru, ale jinak obecne cokoliv co potrebuje persistenci (mimo databaze treba MQ, veci typu grafana nebo prometheus) musi mit namapovanej volume do kontejneru, pak to jde
    Kliknutím sem můžete změnit nastavení reklam