Přejít k navigační liště

Zdroják » PHP » Deploy aplikace přes git

Deploy aplikace přes git

Články PHP

Verzování projektů je snad pro každého vývojáře už úplně běžná věc. Jakmile ale přijde na deploy, je zle. V lepším případě má vývojář nějaký spatlaný skript, který mu synchronizuje data se serverem, v tom horším měněné soubory nahrává manuálně na web přes FTP. Ani jeden z těchto přístupů navíc neřeší další nezbytné úkony jako migraci databáze, invalidaci cache a úpravu práv souborů a podobně.

Představte si, že se celého harakiri kolem ručního nasazení webu můžete zbavit jedním příkazem.

git push deploy master:production

V tomto článku nastíním, jaké jsou běžné metody použití gitu pro deploy (způsob, jakým se soubory aplikace dostanou na server) a jaké nástroje nám můžou pomoct.

Článek je mířený především na PHP komunitu, celý postup nahrávání aplikace na server je ale nezávislý na konkrétním programovacím jazyku.

Syrový git

Obejdete-li se bez detailních oprávnění a speciálních funkcí (např. dynamické repozitáře a VREF u Gitolite), vystačíte si na serveru pouze se samotným gitem. Běžně se serverové repozitáře (remote) vytvářejí jako bare, což znamená, že neobsahují žádné kopie souborů samotné aplikace (při čtení repozitáře je ale samozřejmě umí poskytnout).

Protože git umí kromě HTTP, git a file fungovat i přes ssh, stačí na serveru připravit repozitář takto:

ssh [user@]host
cd repos/are/here/
mkdir project.git
cd project.git
git init --bare

Je běžné vytvořit uživatele git a poté k repozitáři přistupovat přes git@host:path/repo.git.

Do lokálního repozitáře poté pouze přidáme adekvátní remote:

cd projects/are/here/project
git remote add origin [user@]host:repos/are/here/project.git
git push -u origin master

Hlavní nevýhoda tohoto nastavení je, že každý uživatel pracující s repozitáři musí mít na server ssh přístup.

Zdroj: SO community wiki

Deploy můžeme naskriptovat pomocí hooků update a post-receive. Výstup těchto skriptů (a to jak stdout, tak stderr) je přesměrován ke klientovi s předponou remote:. Toho se dá náležitě využít pro průběžné informování o stavu deploye a o proběhlých změnách.

Ukázka výstupu git hooks

Nástroje pro obohacení serverového gitu

git-deploy; de facto pouze prostředí pro snažší skriptování hooků, přidává akce sync, finish, revert, hotfix atp. Samotný deploy souborů spouští serverový skript deploy/sync/$app.sync, který je nutné doimplementovat. Z bezpečnosti řeší pouze zamykání (lockfile, deploy může okamžitě provádět pouze jeden uživatel), oprávnění je ale nutné ošetřit jinde, například pomocí Gitolite.

GitLab je prakticky open source kopie GitHub. Původně využívala pro správu repositářů gitosis, později gitolite a v nějnovější verzi využívá pro práci s gitem vlastní software gitlab-shell. Podobně jako ostatní nástroje umožňuje spouštění vlastních skriptů update a post-receive, pomocí kterých je možné dělat deploy. GitLab je nejlepší alternativa k Gitolite, pokud potřebujete webové prostředí ve stylu GitHubu.

Pro deploy jsou také využívány proprietární technologie; na vlastní servery můžete nasadit například DeployHQ. Některé hostovací služby mají deploy přes git jako jednu z hlavních předností – Heroku.

Svého času byl oblíbený nástroj Gitosis, už ale není udržovaný a neposkytuje takové funkce jako Gitolite.

Gitolite – nejrozšířenější[citation needed] nástroj pro správu repozitářů na serveru. Na rozdíl od samostatného gitu odděluje unixové uživatele a uživatele repozitářů, není tedy nutné pro každého vývojáře nastavovat shell přístup. Mimo spousty dalších vlastnostní má dynamické repositáře a rovnou předpřipravené kontroly zápisu; pro ukázku, následující konfigurace zakáže uživatelům ve skupině junior-devs měnit soubor composer.json:

repo foo
    RW+                         = @all-devs
    -   VREF/NAME/composer.json = @junior-devs

viz VREF.

Suma sumárum, je nyní na výběr mezi GitLab a Gitolite a záleží pouze na tom, jestli chcete webové rozhraní. Protože GitLab má lépe zdokumentovanou instalaci, budu pokračovat s instalací Gitolite.

Instalace Gitolite

Oficiální dokument.

  1. Vytvořte účet, pod kterým Gitolite nainstalujete. Jeho jméno se objeví v každé adrese repozitáře, a to jako zvoleny-ucet@host:repository. Pro jednotnost je nejlepší tento účet pojmenovat git.
  2. Nahrajte na server svůj veřejný klíč, například do ~/tmp/VaseJmeno.pub. Protože Gitolite nevyužívá unixové uživatele a jejich oprávnění, potřebuje vás po instalaci rozpoznat jako administrátora. Název tohoto klíče se objeví, až budete nastavovat oprávnění pro jednotlivé repozitáře. Je vhodné držet se formátu JmenoPrijmeni.
  3. Následuje naklonování Gitolite a jeho registrace:
git clone git://github.com/sitaramc/gitolite
mkdir -p ~/bin
gitolite/install -to ~/bin
~/bin/gitolite setup -pk ~/tmp/VaseJmeno.pub

Správa Gitolite

Pokud máte Gitolite správně nainstalovaný, můžete si u sebe na localhostu naklonovat administrátorský repozitář , který slouží k jeho spravování (byl vytvořený při instalaci). Přímo se soubory Gitolite nesmí na serveru upravovat.

git clone git@host:gitolite-admin

Nepodaří-li se vám gitolite-admin naklonovat, zkontrolujte, že se ověřujete klíčem, který jste přiložili při instalaci.

Samotný konfigurační repozitář obsahuje dvě složky. Méně zajímavá je /keys, ve které jsou veřejné klíče oprávněných uživatelů (práva viz dále). Jména těchto souboru jsou důležitá, přímo odpovídají uživatelský jménům, která se přiřazují k repozitářům. Druhou složkou je /conf se souborem gitolite.conf, ve kterém jsou všechny repozitáře a oprávnění k nim. Oficiální dokumentace.

Zjednodušeně ke konfiguraci: blok repo nazev označuje repozitáře a obsahuje řádky s oprávněním. RW+ = uzivatel značí, že uzivatel má možnost repo číst (clone, fetch, archive) i do něj zapisovat. Symbol + povoluje destruktivní příkazy push --force a mazání ref (větví a tagů). Kromě toho může uzivatel být i skupina:

@devs = alice bob
@deployers = carol

repo webova-aplikace
    RW            = @devs @deployers
    -  production = @devs

Tímto způsobem povolíme pouze uživatelům ze skupině @deployers (pouze carol) spravovat větěv production a oběma skupinám volně přistupovat k ostatním větvím. (Málo známá vlastnost Gitolite je tzv. wild repos.)

Změny je poté nutné commitnout, „změny uložit“, na server obligátním git push origin master. Všimněte si, že úpravy jako vytvoření nového repozitáře uvidíte ve výstupu pushe.

Jediný soubor, který není verzovaný a upravuje se přímo na serveru, je .gitolite.rc, který obsahuje základní technické nastavení.

Deploy skripty

Nyní máme na serveru pouze bare repozitář s aplikací, který chceme v hooku post-receive nějakým způsobem dostat do složky, kterou očekává http server.

Nejjednoduší způsob je na serveru původní bare repozitář naklonovat do adekvátní lokace, typicky jako variantu git clone -b production git@localhost:repo /srv/sites/repo.com. Pokud už aplikace v cílovém místě existuje, stačí nechat deploy skript zavolat git fetch origin production && git reset --hard origin/production.

Poznámka: při spouštění hooku je git prostředí nastaveno na práci s konkrétním bare git repozitářem. Před voláním git příkazů nad klonovaným repozitářem je nutné přepsat nebo smazat proměnnou GIT_DIR.

Všechny uvedené nástroje až na Gitolite mají hooky update i post-update volně upravitelné. Gitolite totiž využívá update hook interně; místo toho stačí nastavit vlastní viz VREF (která dostává minimálně ty samé argumenty jako update). Ukázka nastavení vlastního VREF pro všechny repozitáře:

repo @all
    -    VREF/deploy_hook   =   @all

Ukázka deploy skriptů, která čte nastavení cílové složky ze souboru deploy.json.

V hooku update lze kontrolovat cokoliv. Můžete zamezit nahrání nové verze aplikace, pokud neprojde testy, odmítnout push v době, kdy je na webu nejvíc uživatelů, nebo kontrolovat, jestli byla před produkční verzí nejprve deploynuta testovací (staging) verze.

V post-receive můžete kromě kopírovaní samotných aplikačních souborů opravit práva, která git nehlídá, smazat cache, spustit migraci databáze, ohlásit deploy monitorovací službě (např. New Relic), nebo stáhnout aktualizované závislosti (composer install --no-dev).

Ukázkový kód na odkazu výše čte hooky rovnou z deployované aplikace, což je neuvěřitelně praktické, ale také potenciálně nebezpečné a vyžaduje důsledně nastavená práva.

Závěr

Nastavením serveru a připravením dobrých hooků strávíte několik hodin. Myslete ale na to, že vám každý den ulehčí práci. Nemusíte si pamatovat, jaké soubory je nutné nahrát na server a nezapomenete zavolat žádný z nezbytných příkazů, všechno se zkopíruje a spustí automaticky. A když omylem na server nahrajete větev s kritickou chybou, nemusíte panikařit a uděláte rollback na předchozí verzi.

Komentáře

Subscribe
Upozornit na
guest
5 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
jlx

Možná mi něco uniká, ale podle mne se deploy přes git nechá udělat mnohem jednodušším způsobem:

1) Na serveru si založím repozitář:
cd /path/to/repo/; git init –bare

2) Přidám post-receive hook ve tvaru (kde „worktree“ je místo kam se má aplikace vybalit):
#!/bin/sh
GIT_WORK_TREE=/path/to/worktree/ git checkout -f

3) lokálně si přidám repozitář:
git remote add production ssh://example.com/path/to/repo

4) a pošlu to na server:
git push production master

Celé nastavení je záležitostí pár minut. Repozitář je oddělený od work-tree (což je může být výhoda i nevýhoda). Samozřejmě, že to neřeší dodatečné úkony, ale ty lze prostě dopsat do post-receive hooku..

Tomáš

díky za článek. Mám rád jednoduché věci. Deploy přes Git je výborný nápad pro jednotlivce. Na java/groovy projekty používám Gradle. Kdysi jsem používal Ant a Maven.

Tomáš Fejfar

Nevim, jestli jsem to špatně nepochopil, ale opravdu se po každém deploynutí zavolá hard reset?! Takže pokud si například nahraje obrázek do složky public/images (která je verzovaná) tak mu ho chceme smazat?

To je právě problém na který jsem narazil – jak donutit git, aby vůbec nesledoval změny v souborech – např. změnu práv z 644 na 777 u logu, atp. Protože jinak při pullnutí dojde k tomu, že je tam konflikt s WorkingCopy

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.