Jak co nejjednodušeji syncnout projekt z gitu

Terka04

Zdravím,
začala jsem se učit s gitem a master odzkoušené commity dávám do private repozitáře na githubu. Je tam vlastně obsaženo vše, co by projekt měl obsahovat, kromě nastavení loginu do db, obrázky, dokumenty, atp. Pouze tedy zdrojové kódy, které vyvíjím na localhostu.

Nicméně ráda bych se zeptala. Na produkčním serveru mám projekt veřejný a ráda bych co nejjednodušší a nejbezpečnější cestou stáhla a aplikovala změny z githubu, které jsou v tom master repozitáři. V repo vždy bude vyzkoušený a funkční commit.

Napadla mě prasečinka, že bych si stáhla přes PHP git, extrahovala a začala přepisovat soubory (skrze PHP). Tomu bych se chtěla vyhnout.
Potom mě napadlo stahovat to přes composer, ale tam nechci aktualizovat ostatní knihovny (případnou aktualizaci řeším na localu a jsou součástí commitu). Navíc bych musela povolit fci exec() a tam se bojím nějakých zranitelností.
Ráda bych nějakým rozumným způsobem (přes PHP) spustila „git pull“ – opět fce exec()?

Jakým způsobem to řešíte vy? Ráda bych bez přístupu k terminálu rovnou z PHP jako funkci „Aktualizovat“, kterou si spustí sám klient.

Děkuji všem za radu, přeji fajn víkend. :)

Editoval Terka04 (15. 1. 2022 16:01)

Polki

Od nejhloupějšího po nejlepší řešení:

Jakmile to tam někdo pushne, tak si stáhneš co je v masteru a ručně to tam nahraješ přes FTP/SFTP/Rsync… Ruční a pomalá práce
Na Gitu si vytvoříš deploy aplikace, kdy se GIT připojí na FTP a vlastně udělá při každém PUSHi bod 1 automaticky za tebe. Přístupové údaje k FTP jsou sdíleny s gitem. Špatné stejně jako commitovat přístupové údaje k FTP apod.

NÁSLEDUJÍCÍ ŘEŠENÍ POTŘEBUJÍ NA OSTRÉM SERVERU NAINSTALOVANÝ GIT A PŘIPOJENÍ K REPOZITÁŘI

Na ostrém serveru si Vytvoříš CRON, který bude v intervalech zapínat maintenance spouštět git-pull nad repem, promazání cache, aktualizování balíčků pomocí composer update a opět vypnutí maintenance. Při každém spuštění skriptu se stáhne znovu repo, které se nemuselo změnit, takže bude spousta zbytečných dotazů. Taky když se změna nahraje na git, tak může trvat celý cyklus spuštění cronu,než se změna uživatelům projeví
Mít vlastní GIT na ostrém serveru tedy nenahrávat aplikaci na servery GitLabu/GitHubu atp. ale vlastního GIT serveru, na který budeš dělat push do mastera a tento master bude rovnou přístupný z webu jako aplikace. Instalování celého gitu, nutnost nahrávat vendor složku, soubory config.local atp.
Na gitu si nastavit Push webhooky, které se zavolají při pushi do mastera. Ty informují tvůj server, že se něco změnilo a server spustí příkaz git-pull. Tento webhook nemusí být v PHP může poslouchat klidně nějaká C++ aplikace apod. To jakým způsobem webhook obsloužíš a jak na to v návaznosti spustíš pull z gitu je na tobě. Toto už je relativně fajn řešení. Akorát musíš mít na paměti, že občas je problém s právy PHP a spouštěním příkazů.

NÁSLEDUJÍCÍ ŘEŠENÍ PŘEDPOKLÁDAJÍ NAINSTALOVANÝ DOCKER NA SERVERU A ROZBĚHNUTÝ SERVER PŘES DOCKER.

Vytvoříš si docker image, který poslouží jako server. Následně na něj založíš Docker repozitář a pushneš jej tam. V Gitu si nastavíš Pipeline, která vezme aplikaci, otevře docker image z tvého repa, zkopíruje aplikaci na místo kam potřebuješ (jakoby deployne na server ale ten server je ten docker image) a pushne nový docker image zpátky do docker repa. Následně se opět zavolá webhook, který spustí docker pull, čímž se docker image nainstaluje a server běží. Záleží, jaká je infrastruktura, ale když to uděláš špatně, tak musíš dávat pozor na synchronizaci. Například pokud databázi máš taky v docker image, tak je třeba zajistit, aby image databáze byl spuštěn dříve, než image aplikace, aby nenastala například chyba při migracích.
Řešení jako výše, ale na synchronizaci různých image použít nějaký automatizovaný nástroj, který umí spouštět image v daném pořadí jak potřebuješ a čekat na plné spuštění. Například DOCKER COMPOSE.

KUBERNETES (s ním jsem ještě nepracoval a zatím se ani nechystám. Mě stačí bod 6 zatím. Jen jsem slyšel že pracuje jako bod 7 ale že se nemusíš o nic starat a dokáže dělat automatický deploy na Clustery. Nejlepší je prý jej využít s nějakým 3d party poskytovatelem, ale to mi zase smrdí password leakem.)

Editoval Polki (15. 1. 2022 19:24)

Terka04

Děkuji moc za vyčerpávající odpověď. Takto mi to stačí, už na tom pracuji. Mnohokrát děkuji! Myslím, že to i ostatním pomůže. :)

Petr Parolek

Ahoj, nepoužívanější je nasazování nových verzí na produkci a podle mě nejlepší přes CI (GitHUb Actions GitLab CI atd.) – spustí se ti automaticky build, testy atd . a když je vše v pořádku, automaticky se aplikace nahraje na produkci.

Našel jsem článek https://dev.to/…-actions-k07 – GitHub Actions moc nepoužívám – jen z donucení. Je zbytečné vymýšlet kolo, když tu máme continuous integration.

Polki

@PetrParolek
CI je Continuous Integration tedy nemá co dělat s deployem. Jde o testování, zajišťování integrity apod. a nemá to moc co dělat s dotazem. Samozřejmě díky tomu taky můžeš nahrát aplikaci na server, což popisuje přesně můj bod 2, ale to není vůbec dobrý způsob viz můj komentář. + všechno se buildí na straně gitu a je kvůli toho obří přenosová kapacita při deployi a tedy zatížený server a zbytečně dlouhé odstavení aplikace a navíc gitu dáváš přístup komplet k serveru a aplikaci včetně hesel což pokud nepoužíváš vlastní git je vhodné pro svoje malé projekty kde ti to je fuk jinak je to průser.
CD narozdíl oproti tomu je přizpůsobeno to co projde přes CI deploynout na server a k tomu se používají ideálně deploye přes Docker/Kubernetes jak jsem popsal opět v mém komentáři. CD má jednoduchou syntaxi, kterou ten docker image dokáže zbuildit, nakonfigurovat apod. a pushnout jej, aby si jej mohl server v klidečku stáhnout. A jelikož docker si image stáhne, spustí a až běží, tak se mu přidělí port a co se udělá je že se switchnou porty na kterých appka běží, což je okamžitě, tak k odstavení webu nedojde vůbec. starý docker image se pak vypne a zahodí.

Možná je to nastavení trochu složitější, ale je to potom bezpečné. Pokud ti ale nevadí používat služby 3 stran jako je třeba CircleCI apod., kterým musíš dát svá přístupová hesla ke všemu a zpřístupnit jim i produkční databázi, data a kdo ví co a pak to řešit v rámci GDPR, tak prosím nikdo tě nenutí kolo vynalézat. :)