Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Michal Šiman 03. 04. 2019, 13:07:56
-
Potřeboval bych opět nasměrovat, pro naše vývojáře jsem implementoval GITLAB jako GIT server, všichni s ním začali pracovat a veškerý kód jde již pouze přes GITLAB. Jenže na produkční (a připadně předprodukční) server se kód stále dostává tak, že jej někdo pomocí FTP přenese. To bych chtěl změnit. Moje přesdstava je taková, že jednou nebo dvakrát týdně (nebo dle potřeby) se řekne teď to nasadíme na produkci a stiskne se někde nějaké tlačítko, které provede na produkčním serveru vše potřebné tedy jak nasypání kódu nového (PHP, Nette) tak např. úpravu v SQL databázi (pomocí .sql souboru samozřejmě) a případně to pošle nějaký informační email o nasazení nové verze. Tuším že k tomu slouží v GITLABu CI/CD, pletu se? Je to tak správně nebo jak to děláte u vás? Děkuji za nasměrování...
-
FTP v 2019 ? Fujky...
Ano tusis spravne, pouziva se na to CI, ale ne tak jak si predstavujes...
Tvoje "stisknuti tlacitka" muze byt nekolik akci ktere si muzes nadefinovat v Gitlab CI, zalezi jake workflow preferujete:
- Akceptovany pull request do protected master branche. To znamena ze "master" branch je LIVE verze projektu, do chraneneho branche muze prijmat pull requesty a pushovat kod jenom Owner uzivatel (ten zodpovedny za projekt) ostatni vyvojari (Developer) musi sve zmeny delat ve vlastnich branchich (vetsinou je dobre je pojmenovat dle issue na kterem pracuji etc.) a jak maji hotovo tak vytvori pull request na master branch, Owner udela PR rewiew a provede automaticky nebo manualni merge za predpokladu ze je vse ok. To spusti CI deploy.
- Vytvoreni noveho Git Tagu nad master branch ktery spusti CI deploy.
- Kombinaci obojiho vyse (doporucuji).
PS: Spravne by jsi mel mit v CI i unittest pro kazdy commit.
Tenhle Gitlab CI script pouzivam ja pro test pri kazdem commitu a deploy pri tagu (Python projekt s buildem do DEB a Pacman balicku + deploy do repa): https://github.com/Salamek/gitlab-tools/blob/master/.gitlab-ci.yml
Ty vlastne jen potrebujes stage: test a deploy
Samozrejme musis mit spusteny a nakonfigurovany gitlab-runner s pozadovanymi runnery
-
Rozhodne se primlouvam za Gitlab CI, kazdopadne je treba domluvit a nastavit procesy tak, aby na produkci sel vyhradne jiz schvaleny a otestovany kod (Merge requesty, review, testovani), to, jak se napise CI skript je implementace nejak nastavenejch procesu
-
@Adam Schubert jaké testy? Co testujes? Validitu kódu? Nebo co přesně. Nějak stručně jenom díky.
-
Pouzivam uz leta git-ftp :(
https://www.kutac.cz/blog/weby-a-vse-okolo/git-ftp/
-
@Adam Schubert jaké testy? Co testujes? Validitu kódu? Nebo co přesně. Nějak stručně jenom díky.
https://cs.wikipedia.org/wiki/Unit_testing
V pripade nette https://tester.nette.org/cs/
-
Dycky Docker!
-
Jak pomůže Docker?
-
Me by zajimalo, jak ma kdo implementovane nahrani samotneho kodu na produkcni server, kdyz se nejedna o package z repozitare, ale treba klasicky php. Webhooky nepocitam.
-
Jak pomuze Docker? Jak mam reseni nahrani kodu na produkcni server("klasicke" php)?
Gitlab CI: docker build, docker push (example .gitlab-ci.yml tam maji).
Na serveru: docker-compose pull, docker-compose up -d --force-recreate --remove-orphans (tady uz to chce mit na serveru nainstalovany gitlab-runner a napojeny do repository, aby se to spoustelo samo po zbuildeni docker image z tagu a aby se tam pres .env aplikoval spravny docker image tag)
-
A protoze mam na serveru vice webu tak je to pred tim dvojice nginx-proxy a letsencrypt companion (samozrejme docker)
https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/
https://hub.docker.com/r/jwilder/nginx-proxy
DEV server uplne stejne, diky letsencrypt vse na 443, vse "zelene" v prohlizecich... jakmile se nekde spusti nginx a ma env VIRTUAL_HOST (+ VIRTUAL_PORT, VIRTUAL_PROTO) tak si to ta proxyna odchyti, zaridi certifikaty...
-
@to_je_jedno: no priznam se bez muceni ze tomu co jsi napsal nerozumim, tusim ale nerozumim. nicmene zeptam se jeste jinak: docker v ostrem produkcnim prostredi? byl jsem na tom ze docker je spis urceny pro vyvoj a mozne rychle testovani, ale ne na produkcni intranet server ve vyrobe ktera jede 24/7 a je na intranetu zavisla. doporucis i v tomto pripade docker?
-
Docker v produkci ve vyrobe, pokud s tim nejsou rozsahle zkusenosti - NE. Docker jako pomucka testovani/vyvoje a distribuce aktualizace aplikace - klidne.
-
@to_je_jedno: no priznam se bez muceni ze tomu co jsi napsal nerozumim, tusim ale nerozumim. nicmene zeptam se jeste jinak: docker v ostrem produkcnim prostredi? byl jsem na tom ze docker je spis urceny pro vyvoj a mozne rychle testovani, ale ne na produkcni intranet server ve vyrobe ktera jede 24/7 a je na intranetu zavisla. doporucis i v tomto pripade docker?
Docker na produkci úplně v pohodě. Dneska spoustu firem běží na Kubernetes který je vlastně postavený celý nad Dockerem (jediné co, tak bych preferoval Kubernetes než čistý docker, protože to řeší spoustu věcí které by se v Dockeru museli dělat ručně).
-
Docker na produkci úplně v pohodě. Dneska spoustu firem běží na Kubernetes který je vlastně postavený celý nad Dockerem
Už ne nutně, Docker je přece jen pro Kubernet zbytečně těžkotonážní. https://cri-o.io/
Každopádně, jde hlavně o to, vycházet z ověřených kontejnerů (a nestahovat do produkce kdeco z docker hubu) a mít nějak rozumně pořešené updaty kontejnerů, pak je Docker v produkci naprosto v klidu :)
-
Jediny duvod nepouzit Docker na produkci je, ze ho neznas.
Naopak je podle me blbost vyvijet v Dockeru a na produkci jet bez nej protoze hlavni benefit vidim v tom, ze eliminujes "ale u me to funguje". Proste kazdy jeden vyvojar ma STEJNOU verzi prostredi a ta je stejna jako na stagingu a produkci.
(do Kubernetu jsem jeste nedosel, mam na kazdem projektu maximalne jeden produkcni server)
-
Ne docker neznam, zatim jsem nemel potrebu i kdyz vim o co jde s informacne se snazim zustavat v obraze.
Pouzivame Hyper-V (vcetne replikace vsech VM na druhy fyzicky stroj kvuli nepretrzite dostupnosti - zalohovano je pomoci Veeam na rackovy NAS) a mimo dalších WIN serveru mam i nekolik linux serveru jako samostatne VM, napr. produckni LAMP nebo testovaci LAMP a nebo i GITLAB. Když se mi v rámci té jedné VM něco pokazí, např. při upgade nebo při nasazování nějké nové featury, tak se mi pokazí jen jeden stroj, mám jeho zálohu - ostatní servery (tedy služby) jedou, výroba také v nějakém neúplném režimu. Když budu mít jeden stroj, a na něm výse uvedené v DOCKERu, a něco se mi pokazí s tím jedním VM, tak mi přestane jet všechno. To je důvod proč jsem o DOCKERu zatím neuvažoval v produkci, resp. nahradit jím jednotlivé samostatné servery.
-
To je důvod proč jsem o DOCKERu zatím neuvažoval v produkci, resp. nahradit jím jednotlivé samostatné servery.
No a přesně proto se to takhle v produkci nedělá ;-)
Zbavit se záložního serveru je nesmysl. Ty kontejnery mohou být na obou serverech, což se spravuje právě přes Kubernetes, nebo docker swarm (s tím zkušenosti nemám, ale je to o něco víc „lightweight“). Ale rozhodně to není usecase vhodný pro každého. Zvlášť pokud jediná náplň práce těch dvou serverů je daná aplikace, může to být kanon na vrabce (kubernetes rozhodně)
-
No a přesně proto se to takhle v produkci nedělá ;-)
Co se takhle nedělá?
Zbavit se záložního serveru je nesmysl. Ty kontejnery mohou být na obou serverech ...
Já používám záložní server ne pro to, abych měl zálohu datovou, ale pro to abych měl dostupnost 24/7 - replikace se provádí na záložní server okamžitě, takže když tam něco "pos*ru" tak je to "posr*ne" i na zaloznim serveru behem par sekund. Ani si toho nestihnu vsimnout. Mam k dispozici samozrejme nocni zalohu (nebo zalohu kterou si udelam rucne chvilku pred tim).
Jde mi o to co je lepsi, mit tri virtualni servery s ruznyma aplikacema a nebo mit jeden server a na nem pomoci tří DOCKERů tri aplikace?
-
Ocekavas jednoduche odpovedi na prilis komplexni otazky. Tohle je potreba videt zblizka, znat sitove prostredi atd.
Docker neni stribrna kulka, ale je to reseni na spoustu ruznych problemu.
-
Docker neni stribrna kulka, ale je to reseni na spoustu ruznych problemu.
Evidentne DOCKER neni reseni na muj puvodni dotaz, tedy jak uvolnovat kod z GITLABu na produkcni server - minimalne ne pro me a ne ted, kdyz s dockerem nemam zadne zkusenosti a nezda se nyni ze by nam mohl byt necim extra uzitecny.
Nevyrostl jsem ve velikem korporatnim prostredi, rostu s firmou a pred 6ti lety jsem psal kod v PSPadu a pomoci FTP uploadoval, dnes tu sedi dva programatori vedle a commituji na gitlab, protoze tu potrebu jsme meli. Nehledam jednoduche odpovedi ale pouze nasmerovani jakou cestou vubec jit, protoze to proste neznam, ale chci poznat. Notabene, i ten muj problem ma nekolik moznych reseni, zatim pujdu asi tou nejjednodussi cestou a uvidime co dal, ono se to nekam posune podle potreby :-)
-
No a přesně proto se to takhle v produkci nedělá ;-)
Co se takhle nedělá?
Zbavit se záložního serveru je nesmysl. Ty kontejnery mohou být na obou serverech ...
Já používám záložní server ne pro to, abych měl zálohu datovou, ale pro to abych měl dostupnost 24/7 - replikace se provádí na záložní server okamžitě, takže když tam něco "pos*ru" tak je to "posr*ne" i na zaloznim serveru behem par sekund. Ani si toho nestihnu vsimnout. Mam k dispozici samozrejme nocni zalohu (nebo zalohu kterou si udelam rucne chvilku pred tim).
Jde mi o to co je lepsi, mit tri virtualni servery s ruznyma aplikacema a nebo mit jeden server a na nem pomoci tří DOCKERů tri aplikace?
Ale vždyť o tom mluvím, bohové… Nikdo nemluví o rušení virtuálů, kontejnery jsou jen další úroveň abstrakce.
Zcela běžné nasazení je v takovém případě mít tři virtuály a na každém těch několik aplikací, každá v samostatném kontejneru. Usnadní se tím replikace, usnadní se tím deploy, navíc je jistota, že ty aplikace běží ve stejném prostředí ve kterém proběhly testy. A ještě k tomu je v tu chvíli triviální rollback, ve většině případů stačí spustit starší verzi kontejneru.
-
@to_je_jedno: no priznam se bez muceni ze tomu co jsi napsal nerozumim, tusim ale nerozumim. nicmene zeptam se jeste jinak: docker v ostrem produkcnim prostredi? byl jsem na tom ze docker je spis urceny pro vyvoj a mozne rychle testovani, ale ne na produkcni intranet server ve vyrobe ktera jede 24/7 a je na intranetu zavisla. doporucis i v tomto pripade docker?
Docker se samozřejmě normálně produkčně používá - používat ho jen na vývoj a testování je absurdní představa, základní smysl dockeru spočívá v tom že v produkci běží přesně totéž co se testovalo.
Na druhou stranu ale platí to co tu padlo - pokud jste o dockeru slyšeli jen z doslechu, tak si při hurá-nasazení do produkce nabijete hubu. Ale to snad není nic specifického pro docker, že.
Pokud nechcete předem investovat do vyrábění balíčků (ať už docker nebo deb/rpm), tak klidně můžete mít v gitlab CI script který aplikaci nahraje na server třeba přes ssh/rsync (o ftp bych fakt ani neuvažoval). Pro začátek to bude naprosto stačit, a časem snad budete mít lepší představu co a jak. Gitlab CI je dobře vybaven a jde i zajistit, aby do produkce neměl právo nasazovat každý vývojář (i když je to trochu komplikovanější - bude potřeba nastavit práva na větve a dobře odladit .gitlab-ci.yml).
-
Když se zaměřím na původní dotaz, tak já mám pro nasazení aplikace Jenkins. Ten stáhne git z Azure DevOps, provede build, balíčky nahraje do Nexusu. Pak na další kliknutí se balíčky stáhnou se všemi zavislostmi do složky, zabalí do ZIPu, přes SSH se nahraji na server (kontejner na Debian, Proxmox) a aplikace se vymění/restartuje. Tolik k tomu, že funkční řešení nemusí být hned Kubernetes a Docker. :)
-
Když se zaměřím na původní dotaz, tak já mám pro nasazení aplikace Jenkins. Ten stáhne git z Azure DevOps, provede build, balíčky nahraje do Nexusu. Pak na další kliknutí se balíčky stáhnou se všemi zavislostmi do složky, zabalí do ZIPu, přes SSH se nahraji na server (kontejner na Debian, Proxmox) a aplikace se vymění/restartuje. Tolik k tomu, že funkční řešení nemusí být hned Kubernetes a Docker. :)
Však nikdo neříká že to je jediné funkční řešení, ale z mého pohledu má nejvíc výhod :) Zajišťuje jednotné prostředí pro aplikaci a u takhle automaticky nasazovaných věcí jsem z principu o dost klidnější, když je nasazovaná aplikace oddělená od systému na serveru a nemůže si s ním dělat všechno co root.