Jak řešíte deployment vašich aplikací? rubrika: Administrace: Software

Anonym
položil/-a 20.3.2013

Podělte se o vaše postupy při deployování aplikací, ať už jde o služby nebo produkty.

odkaz
6 hever
odpověděl/-a 22.3.2013
 
upravil/-a 25.3.2013

Programovací jazyky: linuxový bash
Nástroje: git, rsync

Stroje:

  • pracovní stanice
  • server A pro git repozitář (v mém případě moje VPS, potřebuju jen obyčejný SSH přístup)
  • server B pro aplikaci (opět jen s SSH přístupem, může to být i stejný server jako pro repozitář, těchto serverů může obecně existovat mnoho)

Workflow
V pracovní stanici vyvíjím kód. Na serveru A mám repozitář se kterým provádím pull/push - spolupráce s ostatními a záloha kódu. Dále zde mám jiný repozitář, který používám pouze pro push. Ten slouží k deployi. V tomto repozitáři mám v hooks/post-receive bashový skript (post-receive se pouští po každém pushnutí). Skript provede tvrdý checkout souborů do nějakého temporary adresáře a potom provede kopii těchto souborů do cílové složky. Ta je někde na serveru B (může být i na tom stejném). Kopírování/synchronizace se provádí pomocí rsync (nebo neefektivním scp). Cílových složek nebo serverů B může být víc, je to jen otázka víc rsync příkazů v post-receive skriptu.

Požadoval jsem od toho

  • pracovní stanice se zbavuje důležité odpovědnosti za zálohování
  • pracovních stanic (vývojářů) může být více
  • serverů B s aplikací může být mnoho
  • bude v tom použito minimum programovacích jazyků (nakonec jeden)
  • na pracovní stanice i na servery bude potřeba instalovat co nejmenší množství nástrojů (nakonec dva)
  • zvládne to i spustit/vykonat potřebné události (ať už promazání cache, spuštění skriptu pro aktualizaci db, kompilace, minifikaci, zastavení a znovu puštění aplikace, atp.; do post-receive skriptu, před a za příkaz rsync lze přidat cokoliv)

Je potřeba vyřešit

  • pochopit rsync (že je to prostě chytrý příkaz ke kopírování, prozkoumá co je potřeba přenést a přenese jen potřebné; velmi rychlé)
  • zprůchodnit rsync mezi servery A a B (pro znalého rutijní minuta, pro neznalého chvíle googlení)
  • ovládnutí práce s gitem (to se hodí)

Kde co instalovat

  • na pracovní stanici: git
  • na serveru A: git, rsync
  • na serverech B: rsync

Moje poznámky k nastavení

Server A

mkdir /var/git/
mkdir /tmp/git/
mkdir /var/git/projekt1_deploy.git
mkdir /tmp/git/projekt1_deploy
cd /var/git/projekt1_deploy.git
git init --bare
nano hooks/post-receive
chmod 777 hooks/post-receive

Post-receive skript

#!/bin/sh
GIT_WORK_TREE=/tmp/git/projekt1_deploy git checkout -f
rsync arvx --delete /tmp/git/projekt1_deploy/ login@serverB.neco.cz:/var/www/projekt1
# chci promazat cache treba, atp
# ssh <a href="mailto:login@serverB.neco.cz">login@serverB.neco.cz</a> 'rm /var/www/projekt1/cache/*'
# ____^ devel.cz to převádí na tag a, tak to být samozřejmě nemá

Pro rsync přidávám ještě --exclude-from=/tmp/git/projekt1_deploy/.gitignore, v tomto souboru jsou vyjmenovány adresáře/soubory, které se mají ignorovat (s tímto je potřeba si pohrát, aby všechno fungovalo jak má).

Potom nastavit přihlašování k serverB.neco.cz, ideálně bez hesla tedy pomocí klíče (ssh-keygen a třeba ssh-copy-id) nebo heslo uložit do souboru předat rsynkovi cestu k souboru s přepínačem --password-file.

Pracovní stanice

git remote add deploy_nebo_neco_proste login@serverA.neco.cz:/var/git/projekt1_deploy.git
git push deploy_nebo_neco_proste +master:refs/heads/master

"The red button" k aktivaci deploye je potom

git push deploy_nebo_neco_proste 

Obdobně si nastavím repozitář pro spolupráci, nebo pro jiný(é) B servery, takže v různých scénáříh budu používat třeba
git push projekt
git push testovaci_server
git push ostre_servery
apod.

Komentáře

  • hever : Zajímaly by mě důvody pro down-vote :) 24.5.2013
  • Martin Kuchař : Skvělé, díky. Přesně to jsem potřeboval. 1.11.2013
  • Vašek Ch. : Proč se soubory z repozitáře checkoutují na serverA místo rovnou na serverB? A nebylo by lepší použít jen switchnutí symlinku na serveruB, než nějaký (relativně) pomalý rsync? 4.11.2013
  • Anonym : Mít VCS repository na produkčním serveru je bezpečnostní riziko jako prase. Z chutí do toho. 5.11.2013
  • Vašek Ch. : ...a logická otázka: Proč? 5.11.2013
  • Anonym : Když pominu kolik webů má .git folder přístupný z venku, i kdyby neměli, různými útoky se k němu stejně nějak dostat dá. Na produkční servery by se měl nasazovat pouze balíček obsahující soubory nutné pro běh aplikace, nic víc. Jinak je to lenost, lajdáctví a potenciální průser. 5.11.2013
  • hever : Vašek: za předpokladu, že se checkout (vyplivnutí souborů gitem do adresáře) provede do jiného adresáře, než je .git folder, tak by to mohlo být. Toto řešení jsem navrhoval tak, abych se nemusel zabývat otázkou kde je produkční adresář aplikace umístěný a kolik jich je, aby se to řešilo vždy jen skrz jeden server (server A) - abych se nemusel zabývat jak se všichni vývojáři dostanou na všechny možné servery a aby se na cílové servery nemuselo ideálně nic instalovat, nastavovat (instaluji jenom rsync, ale i bez toho by se to mohlo obejít, pokud bych použil scp). Při tvém navrhovaném switchnutí symlinků musíš navíc přizpůsobit návrh adresářů, kdy případné soubory s aplikačními daty, konfigurační soubory, nebo uploadované soubory, musí být mimo hlavní strukturu, nebo je musíš taky nějak symlinkem switchovat (prostě to co bys normálně dal do .gitignore a rsync s gitem by na to nesahali). 5.11.2013
  • Vašek Ch. : Asi bych to tak černě neviděl. Kdyby se na server dostali, mohli by si zdrojáky tahat pravidelně, a taky by tu historii vývoje projektu vytvořili. Ukrást databázi nebo ukrást konfiguráky s API klíči všude možně je podle mě horší. (Ale oka, point taken. Pravě jsem zjistil, že ani my nemame na produkčním .git, takže s tebou můžu souhlasit ;-).) Nicméně to nic nemění na tom, že i na produkčním serveru můžeš soubory zkopírovat nejprve do vedlejší složky a teprve potom vyměnit složky bleskurychle pomocí symlinku. 5.11.2013
  • Vašek Ch. : hever: Jo, souhlas, musí se to ošetřit a prosymlinkovat. Ale ten výpadek jen dvě vteřiny za to stojí ;-). 5.11.2013

Pro zobrazení všech 17 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.