GIT server - nasazení kódu do produkce

[to_je_jedno]

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)

[Reklama]

[Michal Šiman]

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.

[kate]

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

[Michal Šiman]

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?

[to_je_jedno]

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.

[Reklama]

[Michal Šiman]

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 :-)

[kate]

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.

[Kamil Podlešák]

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

[David]

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.

[kate]

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.