Git: Deploy Repo auf Webserver ohne .git-Files

Wer sein Projekt in einem Git-Repository verwaltet, kann Git nutzen, um die Dateien via Git auf den Webserver zu übertragen. Wird ein einfaches „git clone“ genutzt, dann befinden sich die Meta-Dateien von Git auf dem Webserver (.git-Verzeichnis) und geben Hackern & Co. Angriffsvektoren.

Wer jetzt nicht Tools wie Jenkins etc einsetzen will, kann mit Git aber trotzdem ein sicheres Deployen ermöglichen. Dazu wird auf dem Webserver ein „bare“ Repo (nacktes Repo) angelegt und über einen post-receive-Hook festgelegt, wo die Dateien ausgecheckt werden sollen.

Lokaler Rechner = Workstation zum Entwickeln, Remote Server = Webserver, wo die Dateien ausgecheckt werden sollen (im DOCUMENT_ROOT).

Annahme: Das „bare“-Repo soll in einem Homeverzeichnis untergebracht werden (/home/user/production.git). Die Pfadendung .git soll hier anzeigen, dass sich in diesem Ordner das Repo befindet. Es könnte auch in einem Ordner ausserhalb des DOCUMENT_ROOT liegen (zB /var/repo). Der Webserver DOCUMENT_ROOT soll /var/www/production sein. Der Name des Webserver-Users ist „user“, die Gruppe „users“.

Remote (myserver.de):

$ mkdir production.git
$ cd production.git
$ git init --bare
$ cd hooks
$ nano post-receive

#!/bin/sh
git –work-tree=/var/www/production –git-dir=/home/user/production.git checkout -f master

Dateiinhalt: /home/user/production.git/hooks/post-receive
$ chmod +x post-receive
# Der Hook muss ausführbar sein.
$ mkdir  /var/www/production
$ chown -R user:users /var/www/production
# Das Verzeichnis muss von dem User beschrieben werden können.

Lokal (Workstation, mit existierendem Repo „production“):

$ cd /home/localuser/production
$ git remote add web ssh://myserver.de/home/user/production.git

„web“ ist in diesem Fall der frei gewählte Name des remote Repos. Mit „git push web master“ wird nun eine Änderung in den Master-Branch des „web“-Repos gepusht. D.h in myserver.de/home/user/production.git befinden sich die Dateien für Git (vergleichbar dem lokalen Ordner /home/localuser/production/.git/) – aber nicht die Verzeichnisstruktur für den Webserver. Diese Dateien werden nach dem Push über den Git-Hook „post-receive“ in den Work-Tree kopiert (/var/www/production)

Shell: Rekursiv nach verschiedenen Dateitypen suchen 

find ./ -type f \( -name \*.gz -o -name \*.tgz -o -name \*.tar -o -name \*.zip \)

Hier werden verschiedene Archiv-Typen in einem find-Durchgang gesucht.
Damit mehrere Extensions gefunden werden können, werden sie mit „-o“ (ODER) verknüpft und in einer runden Klammer (escaped und mit Leerzeichen nach/vor der Klammer) zusammengefasst. Statt dem Parameter „-name“ kann auch „-iname“ verwendet werden, der dann Groß- und Kleinschreibung abdeckt (zB -iname \.jpg)

Shell: Rekursiv Dateitypen ermitteln und zählen

Manchmal möchte man wissen, welche Dateitypen und wieviele davon in einem Ordner (mit Unterordnern) abgelegt sind.

Lösung:

find . -type f -name '*.*' | sed 's/.*\.//' | sort | uniq -c

Die Ausgabe sieht dann in etwa so aus:

32 doc
49 docx
3 gif
147 jpg
61 mp4
562 pdf
60 png

Sollen nur die unterschiedlichen Extensions ermittelt werden reicht:

find . -type f -name '*.*' | sed 's/.*\.//' | sort -u

Ausgabe:
doc
docx
gif
…

Wenn Endungen in Groß- und Kleinbuchstaben vorliegen (.PNG, .png) hilft ein Filter vor dem sort-Befehl ( tr ‚[A-Z]‘ ‚[a-z]‘ für lowercase):

find . -type f -name '*.*' | sed 's/.*\.//' | tr '[A-Z]' '[a-z]' | sort -u

Postgresql: Grafische Ausgabe von Explain Analyze

Wenn eine Datenbankabfrage zu lange dauert, kann man sich in Postgres die Informationen vom Query-Planer anzeigen lassen. Dies geschieht, indem der Abfrage ein EXPLAIN oder EXPLAIN ANALYZE vorangestellt wird. Leider ist diese Ausgabe sehr unübersichtlich.

EXPLAIN zeigt an, wie der Query-Planer die Abfrage auszuführen gedenkt.
EXPLAIN ANALYZE führt zusätzlich die Abfrage aus und verändert gegebenenfalls auch Daten (DELETE, INSERT, UPDATE). Um das zu verhindern kann die EXPLAIN ANALYZE-Abfrage als Transaktion ausgeführt und zurückgedreht werden:

BEGIN; –Transaktionsbeginn
EXPLAIN ANALYZE DELETE FROM payments WHERE id > 100;
ROLLBACK; — zurückdrehen der Änderungen

Dankbarerweise gibt es ein paar Seiten im Netz, die die unübersichtliche Ausgabe grafisch aufbereiten können.

http://tatiyants.com/pev/ benötigt die Ausgabe im JSON-Format, was wie folgt erreicht werden kann:
a) EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS, FORMAT JSON)
b) psql mydatabse -qAt -f explain.sql > analyze.json

mydatabase ist der Name der DB und explain.sql ist ein Textfile mit dem EXPLAIN-Ausdruck aus a) und dem SQL, was ausgewertet werden soll.

Eine Vorgängerseite, die aber auch mit der RAW-Ausgabe von Postgres umgehen kann:
https://explain.depesz.com/

Git: Python mit pycodestyle als pre-commit hook

Python Skripe können über das Pythonmodul pycodestyle vor dem Commit auf syntaktische Fehler geprüft werden.

Dazu muss pycodestyle (Nachfolger von pep8) installiert sein:
python -m pip install pycodestyle

Danach kann im .git-Verzeichnis der pre-commit hook angelegt werden:

.git/hooks/pre-commit:

#!/bin/sh
FILES=$(git diff --cached --name-only --diff-filter=ACMR)
python -m pycodestyle ${FILES}

Damit würde im Fall eines Fehlers der Commit NICHT durchgeführt werden.Der diff-filter-Parameter greift bei folgenden Typen:

Der diff-filter – Parameter greift bei folgenden Typen:

  • A=Added (hinzugefügt)
  • C=Copied (kopiert)
  • M=Modified (geändert)
  • R=Renamed (umbenannt)