Im letzten Artikel PhpStorm, Git und ein Remote Webserver ging es um die Einrichtung von PhpStorm + Git und die automatische Synchronisierung des lokalen Projektverzeichnisses mit einem Remote Verzeichnis auf dem Testserver. In diesem Artikel geht es um die Einrichtung eines sehr einfachen Deploymentprozesses den man vom Git Server aus anstoßen kann.

Alle Teile dieser Artikel Serie

Update eines Git Repository auf dem Live Server

Da Git ein dezentrales Versionierungssystem ist, legt man einfache einen Clone auf dem Live Server an. Zum wechseln der Version loggt man sich auf dem Live Server ein und führt ein "git pull" aus. Dabei wird das Repository und im Anschluss die Dateien des Work Tree aktualisiert. Nun muss man sich aber für diesen Ablauf jedes mal mit dem Live Server verbinden, was bei vielen Systemen unhandlich ist.

Git Hooks und wie man das Update damit vereinfachen kann

Git bringt einige nützliche Hooks mit die nach bestimmten Aktionen ausgeführt werden und die man für seine Zwecke nutzen kann. Für das Update von einem Zentralen Ort aus, ist der post-update Hook interessant. Dieser wird nach einem Repository Update von extern (git push) ausgeführt. Damit ist es möglich vom Git Server aus durch ein einfaches git push die Version auf dem Zielserver zu aktualisieren. In meinem Fall richte ich das Live Repository als production ein (git push production). Mit dieser Methode kann man auch weitere Repositories anschließen. Zum Beispiel Staging oder auch mehrere Repositories auf unterschiedlichen Servern mit einem Befehl aktualisieren.

Nun hatte ich in einem vorherigen Artikel das Git FAQ zitiert, das sagt das man nicht in ein Git Repository pushen soll an dem ein Work Tree hängt. In diesem Fall ist dies aber Okay, da der Hook auf die daraus resultierenden Probleme eingeht. Persönlich benutze ich den Hook der im Git FAQ beschrieben wird, aber es gibt weitere die ebenfalls ihre Aufgabe erfüllen.

Vorbereiten des Live Servers

Auf dem Live Server muss ein SSH Account zur Verfügung stehen mit dem man sich einloggen kann. Er muss also eine Shell und ein Homedir (wenn man Key Auth benutzen möchte) zugewiesen haben und für die Anmeldung freigegeben sein. Zu bedenken ist außerdem das Dateien und Verzeichnisse mit den Rechten dieses Users geschrieben werden. Hat man also ein Webserver Setup das mit unterschiedlichen Usern arbeitet, sollte man der Einfachheit halber den User des VHosts benutzen. Damit man Git überhaupt benutzen kann, muss dieses natürlich auch installiert sein.

$ aptitude install git-core
$ usermod -d /var/www/vh-example/htdocs/ vh-example
$ usermod -s /bin/bash vh-example
$ passwd vh-example

Dies installiert git-core, setzt ein Homedir, eine Shell und ein Passwort für vh-example. Jetzt noch gucken ob Public Key Auth aktiviert ist und der User auf der Allowed User Liste steht.

$ nano /etc/ssh/sshd_config
$ /etc/init.d/ssh restart

Public Key Auth vom Git Server aus aktivieren

Damit man nicht bei jeder Aktualisierung das Passwort des Ziel SSH Accounts eingeben muss, legt man auf dem Git Server für den mygituser ein Key Pair an und kopiert den Public Key auf seine Ziel Systeme.

Git Server als mygituser

$ cd ~
$ sh-keygen -t rsa

In diesem Fall sollte man eine Passphrase angeben. Lässt man sie weg, kann jeder der Zugriff auf den Private Key des Git Servers hat auch auf die Live Server zugreifen. Setzt man eine Passphrase muss man diese bei jedem push angeben. Da es aber immer die gleiche ist, ist dies meiner Ansicht nach vertretbar und immer noch einfacher als verschiedene Ziel Account Passwörter zu benutzen.

Public Key des Git Servers im Live Account einrichten

Der Public Key wird nun in die authorized_keys des Live SSH Accounts eingetragen.

$ cd ~
$ if [ ! -d .ssh ]; then mkdir .ssh ; chmod 700 .ssh ; fi
$ cd .ssh/
$ if [ ! -f authorized_keys ]; then touch authorized_keys ; \
chmod 600 authorized_keys ; fi
$ nano authorized_keys

Repository Clonen und Hook einrichten

Als nächstes wird ein Clone des Repository auf dem Live Server angelegt.

$ git clone ssh://gituser@server.com/home/projectname.git projectname

Nun ist der Hook dran. Ich benutze wie erwähnt den im Git FAQ genannten Hook: http://utsl.gen.nz/git/post-update.

$ cd projectname
$ nano .git/hooks/post-update
$ chmod +x .git/hooks/post-update
$ git config receive.denyCurrentBranch ignore

Der letzte Befehl sorgt dafür das man keine Warnungen bekommt die durch das pushen in ein Repository mit Work Tree entstehen.

Git Server Repository Config anpassen

Als letztes muss man nur noch dem zentralen Git Repository auf dem Git Server sagen wohin er pushen soll.

$ nano ~/repos/projectname.git/config
[remote "production"]
    url = ssh://user@live.com/var/www/projectname/.git

Den remote Namen kann man frei wählen und man kann mehrere urls angeben.

.git und .gitignore beim Apache sperren

Man sollte dafür sorgen das der .git Config Ordner sowie die .gitignore nicht über den Webserver erreichbar sind. Das kann man bewerkstelligen in dem man die Document Root des VHosts in ein Unterverzeichnis des Repositories legt, aber das ist nicht bei jeder Anwendung möglich. Man kann die Auslieferung aber auch einfach in der Apache Config unterbinden. Der beste mir bekannte Weg dafür ist die gleiche Technik zu benutzen wie für .ht* Dateien.

$ nano /etc/apache2/apache2.config
...
<Files ~ "^\.git">
    Order allow,deny
    Deny from all
    Satisfy all
</Files>
...

Fertig

Jetzt kann man an seinem lokalen Git Repository mit PhpStorm arbeiten und seine Commits auf den Git Server pushen. Von dort aus kann man dann auf den Live Server pushen. Wenn man will, kann man den kompletten Prozess ohne Passworteingabe realisieren. :)

Related Links

Leave a Reply