GIT server - nasazení kódu do produkce

[Michal Šiman]

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í...

[Reklama]

[Adam Schubert]

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

[Ziktofel]

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

[Michal Šiman]

@Adam Schubert jaké testy? Co testujes? Validitu kódu? Nebo co přesně. Nějak stručně jenom díky.

[Zdeno Sekerák]

Pouzivam uz leta git-ftp   
https://www.kutac.cz/blog/weby-a-vse-okolo/git-ftp/

[Reklama]

[Adam Schubert]

@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/

[to_je_jedno]

Dycky Docker!

[Michal Šiman]

Jak pomůže Docker?

[czechsys]

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.

[to_je_jedno]

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)

[to_je_jedno]

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...

[Michal Šiman]

@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?

[czechsys]

Docker v produkci ve vyrobe, pokud s tim nejsou rozsahle zkusenosti - NE. Docker jako pomucka testovani/vyvoje a distribuce aktualizace aplikace - klidne.

[narg]

@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ě).

[kate]

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