Feldstudie.net

Picdump 02.06.13

von Torsten Feld // June 2nd, 2013 // 1 Comment » // Picdump //

Lange vernachlässigt und doch begehrt, hier ist er wieder, der Picdump!   Weiterlesen...

Das Portfolio von Hosteurope unter die Lupe genommen

von Torsten Feld // June 1st, 2013 // 4 Comments » // Blog / Website, IT //

Die Zeiten des Web 1.0 sind vorbei. Statisches HTML ist nicht nur seit Jahren out, es wird im besten Falle nur noch müde belächelt. Meiner Ansicht nach, sind wir derzeit in einem Wandel vom Web 2.0, in welchem Webseiten dynamisch und das Netz zu einem "Mitmach-Web" wurde, zu einem Web 3.0. Diese "next Generation" des Internets geht weg von einer Seite, welche lediglich Informationen, wenn auch dynamisch generiert, bereitstellt. Die Zukunft sind Applikationen, die Logik sowohl client- als auch serverseitig ausführen können und welche kaum von nativen Programmen, auf Rechnern oder mobilen Geräten auf iOS- oder Android-Basis, unterschieden werden können.

Doch welche Voraussetzungen müssen erfüllt werden, um Kunden und Nutzern solche Applikationen anbieten zu können? Die üblichen Webhosting-Pakete, bei denen meist lediglich Dateien auf den Webserver gelegt werden können, bieten hier mittlerweile nicht mehr genügend Möglichkeiten, um die o.g. Funktionalität zu bieten. Anbieter wie Hosteurope bieten daher als kleinste Option vServer und dedicated bzw. root-Server an. Hier ist die Besonderheit, dass ein SSH-Zugang, mit meist administrativem Zugriff, bereitgestellt wird, der einem die Möglichkeit gibt, Anwendungen, Dienste, etc. nachzuinstallieren und anzupassen. Möchte man mehr als ein einfaches CMS wie WordPress nutzen, ist dies zwingend erforderlich. Ich habe mir daher die verschiedenen Angebote von Hosteurope mal angeschaut: Weiterlesen...

Apache access.log mit node.js in Realtime parsen und zur Weiterverabeitung in RabbitMQ queuen

von Torsten Feld // May 17th, 2013 // 3 Comments » // IT, Node.js, Tutorials //

Für ein firmeninternes Projekt (nein, hier werden keine 'Internals' preisgegeben ) werte ich Apache access.log Dateien aus. Dies geschieht aktuell mittels eines Cronjobs, welcher ein PHP Script startet und das Log Zeile für Zeile ausliest, die Daten via Regular Expressions und StringSplit parsed und anschließend in eine MySQL-Datenbank schreibt. Das Problem hierbei ist, dass sowohl die Dateien (Logrotation ist auf 15 Minuten eingestellt) als auch die Zeilen seriell bearbeitet werden und dies natürlich sehr lange dauert. Zwischenzeitlich habe ich mir bereits gearman angeschaut, um trotz der Verwendung mit PHP diese Prozesse zu parallelisieren, jedoch habe ich hierbei bereits nach kurzer Zeit die Flinte ins Korn geworfen.

Nachdem ich mich nun mittlerweile seit einiger Zeit mit Node.js beschäftigt habe und nach einer knappen Woche auch gut mit RabbitMQ und dem Node.js-Modul node-amqp zurechtkomme, kam mir eine neue Idee. Warum nicht das access.log in Echtzeit auslesen, neu hinzugekommene Zeilen in eine RabbitMQ Queue zu schreiben und dann mit mehreren Worker-Prozessen parallel zu parsen und in eine Datenbank zu schreiben. Somit müsste nicht mehr auf die nächste Log-Rotation (15 min) und die Fertigstellung des Parsing-Scripts gewartet werden und es stünden die Daten nahezu in Echtzeit zur Verfügung.

Hier also die ersten Schritte, um das neue Konzept umzusetzen: Weiterlesen...

Prozesse unter Linux anhand des Prozessnamen beenden

von Torsten Feld // May 7th, 2013 // 2 Comments » // IT, Tutorials //

Dies ist vmtl. eher eine Notiz für mich, als ein ausgewachsener Artikel. Nichtsdestotrotz habe ich ab und an das Problem, dass sich PHP-Prozesse die über die CLI per Cron gestartet werden, nicht sauber beenden. Grundsätzlich sollte hier natürlich nach der Ursache des Problems gesucht werden, aber um erstmal wieder Herr über den Server und seine Prozesse zu werden, ist das Beenden dieser der erste Schritt.

Hierzu muss lediglich folgender Befehl ausgeführt werden:

Verwenden von mehreren GitHub Repositories in Jenkins

von Torsten Feld // May 6th, 2013 // No Comments » // IT, Tutorials //

Für ein neues GitHub (Enterprise) Projekt wollte ich heute auf Jenkins einen neuen Job anlegen. Da ich bereits in der Vergangenheit für einen anderen Jenkins-Job einen SSH-Key erstellt habe, wollte ich diesen auch für das neue GitHub-Repository nutzen. Beim Hinzufügen des Deploy-Keys erschien jedoch folgende Fehlermeldung:

Leider ist es scheinbar nicht möglich, einen SSH-Key für mehrere Repositories zu nutzen. Da es sich um GitHub:Enterprise handelt, war es außerdem nicht möglich einen extra Benutzer anzulegen, welcher einfach dem Projekt hinzugefügt hätte werden können. Nach kurzer Recherche bin ich auf diese Anleitung gestoßen, welche sowohl das Problem beschreibt als auch direkt eine Lösung bereitstellt.

Zuerst erstellt man für jedes Repository einen eigenen SSH-Key, bei welchem der Schlüssel am besten bereits den Namen des Projekts beinhaltet und somit später einfacher zu identifizieren ist:

Der Befehl sollte möglichst unter dem gleichen Benutzer ausgeführt werden, unter welchem der Schlüssel später verwendet werden soll (in meinem Fall "jenkins"), so dass dieser direkt in das .ssh Verzeichnis im Home erstellt wird. Damit später für jedes GitHub-Repository der korrekte Schlüssel benutzt wird, legt man im Verzeichnis die Datei config an und gibt einen virtuellen Host, den echten Host, den User mit welchem die Verbindung aufgebaut werden soll und den absoluten Pfad zum SSH-Key an.

In der Konfiguration von Jenkins gibt man nun anstelle von z.B.

folgendes an:

Bei dem Aufruf wird zuerst in der .ssh/config nach dem angebenen Hostnamen geschaut und anschließend werden die dort konfigurierten Einstellungen für diese Verbindung übernommen.

Dynamisches Setzen von NODE_ENV für Produktions- bzw. Entwicklungsumgebung mit Node.js

von Torsten Feld // May 5th, 2013 // No Comments » // IT, Node.js, Tutorials //

In den meisten Fällen empfiehlt es sich, für Produktions- und Entwicklungsumgebungen unterschiedliche Konfigurationen zu wählen. Insbesondere ist hier das Logging zu nennen, da auf den Umgebungen, auf welchen entwickelt wird, meist mehr Informationen während der Ausführung benötigt werden, als auf Produktivumgebungen.

Grundsätzlich ist die Empfehlung, die Umgebungsvariable NODE_ENV im Betriebssystem zu setzen. Dies funktioniert jedoch nur dann, wenn das entsprechende System grundsätzlich nur für Produktion oder Entwicklung genutzt wird. Für das letzte Testen von Änderungen vor dem 'Release' verwende ich jedoch das gleiche System, auf welchem später die Anwendung auch produktiv läuft, um Betriebssystem-abhängige Fehler auszuschließen (siehe z.B. diesen Beitrag). Würde ich also auf diesem System für die Umgebungsvariable NODE_ENV auf 'production' setzen, würde auch das Testing ohne erweitertes Logging durchgeführt. Hier macht es also Sinn, die Variable dynamisch anhand von bestimmten Kriterien zu setzen und diese dann zu nutzen, um die Umgebung und somit die Konfiguration zu bestimmen.

Da ich (bisher) grundsätzlich unter Windows entwickle, das Produktivsystem jedoch auf Linux läuft, ist das erste Kriterium bereits klar. Da auf dem Produktivsystem jedoch auch das letzte Testing läuft muss hier nochmals unterschieden werden. Glücklicherweise läuft dieses immer in einem Verzeichnis, welches 'dev' enthält. Somit ist auch das zweite Kriterium festgelegt. Hier der Code dazu: Weiterlesen...