Generische URLs für lokale Entwicklungsumgebungen

Als Webentwickler kennt man das vielleicht: Für das x-te Kundenprojekt legt man eine neuen Ordner in seinem WWW-Root an und fängt an, entweder „localhost/kundenprojekt.de“ zu nutzen oder lustige Spielereien mit VirtualHost-Konfigurationen und der Hosts-Datei zu veranstalten („127.0.0.1 kundenprojekt.de“).

Das muss nicht mehr sein! Zumindest unter Linux, BSD und vermutlich Mac OSX.

Der Apache-Part funktioniert ohne Probleme auch unter Windows, das Problem ist hier das generische Domain-Auflösen. Wenn jemand dafür eine Lösung hat, her damit!

Was brauchen wir?

  • Linux, BSD, Mac OSX, Windows
  • Als Entwicklungswebserver benutzen wir den Apachen
  • Unter Linux/Unix/BSD/OSX wird Dnsmasq installiert
    Unter Ubuntu oder Debian mit „apt-get install dnsmasq“ bzw. „aptitude install dnsmasq
  • Unter Windows gibt es das Tool „Acrylic DNS Proxy
  • Dnsmasq / Acrylic ist als primärer DNS-Server eingetragen.

Was macht dieses Dnsmasq eigentlich?

Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP server.

So weit, so gut. Dnsmasq kann einiges mehr und besonders interessieren wir uns für die Funktion, die in der Manpage mit „–address“ beschrieben ist. Sehr unscheinbar, aber das ElDorado für uns. Die Option besagt, dass jede Domain, die in das Muster passt, mit der definierten IP aufgelöst wird.

Dafür legen wir unter Debian/Ubuntu die Datei /etc/dnsmasq.d/localdev.conf an. In diese kommt folgender Inhalt:
address=/localdev/127.0.0.1

Unter Windows bearbeitet man die Datei „AcrylicHosts“ und fügt dort die Zeile „127.0.0.1 *.localdev“ ein.

Man könnte auch eine beliebige andere TLD nehmen („erfinden“), z.b. „.dev“ oder „.locales-netz-von-chris“.

Damit werden alle Domains, die auf „localdev“ enden, auf die lokale IP aufgelöst.

Okay, jetzt kann ich alles mit einer bestimmten Domain auf meinen Server umleiten. Und nun?

Dnsmasq löst nun Domains wie „kunde.localdev“ und „kunde2.localdev“, alle auf den lokalen Webserver um.

Normalerweise hätte man dann ja immer noch das Problem, dass man mit den VirtualHost-Konfigs basteln müsste. Hierfür hat Uberspace eine super Lösung präsentiert:

Die Apache-Config wird in der VirtualHost-Direktive erweitert. XAMPP/LAMPP/MAMPP-User müssen diese erst erzeugen.

RewriteEngine On

# If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/
RewriteCond /var/www/%{HTTP_HOST} -d
RewriteRule (.*) /var/www/%{HTTP_HOST}/$1

Dieser nette Trick erlaubt folgendes: Wenn ein Verzeichnis existiert, welches den gleichen Namen hat, wie die URL, die aufgerufen wird, wird es als „DocumentRoot“ verwendet. Bei der Verwendung von .htaccess-Rewrites innerhalb des Verzeichnisses muss allerdings ein „RewriteBase /“ stehen.

Was bedeutet das für die Praxis?

Ich muss in Zukunft nur noch ein Verzeichnis „kunde123.localdev“ anlegen und schon kann ich darin loslegen. Ich habe eine Top-Level-Domain und muss am Ende beim Umzug auf die Live-Seite nicht mehr soviel ändern. Im Falle von WordPress muss ich nur beispielsweise noch in der Datenbank das „.localdev“ durch „.de“ ersetzen und schon kann das Projekt live gehen.

Außerdem ist mein /var/www/ -Verzeichnis dann auch zwangsläufig gut organisiert.

Im Übrigen: eine spezifische Auflösung in der resolv.conf oder der Hosts-Datei hat Vorrang vor der Dnsmasq-Auflösung.

Update

Ein Tool für Windows wurde nachgetragen

Dieser Eintrag entstand durch eine Verkettung von Inspirationen: Ich habe Alex zum testen von Uberspace inspiriert, deren VirtualHost-Konfiguration hat Alex zum testen von Dnsmasq (Wikipedia) auf seinem Notebook inspiriert und seine Demonstation davon hat mich zu diesem Eintrag inspiriert. Soviel zum Thema „geistiges Eigentum“.

Kommentare sind geschlossen.