NodeJS Deployment in der Cloud

Wed, 27 Apr 2011 07:14:00 -0700

Da ich eine NodeJS / Express basierte App aus Performance Gründen auf einen eigenen Server auslagern wollte, habe ich es einmal zum Anlass genommen die aktuellen Cloud Deployment Optionen für NodeJS Apps auszutesten.

Dabei sind mir zum jetzigen Zeitpunkt zwei Services bekannt:

- Cloud Foundry (VMWare)

- No.de (Joyent)

Beide versprechen ein einfaches und schnelles Deployment.

No.de

No.de ist ein Service von Joyent, die ein Anbieter von Cloud Servern ähnlich zu Amazon EC2 sind. Zudem sind Joyent der aktuelle Arbeitgeber von Ryan Dahl, dem Hauptentwickler von NodeJS. Nachdem man nun einen Joyent Account angelegt und einen "Coupon Code" zum Anlegen einer Node Smartmachine zugewiesen bekommen hat (der Service ist noch in der Beta), kann man loslegen. Das Deployment Verfahren läuft ähnlich wie zu Heroku über Git.

Zudem kann man sich auch direkt über SSH auf die Node Smartmachine einloggen und z.B. benötigte Node Libraries selber installieren. Auch eine Installation von MongoDB ist möglich (neben mysql und redis). Die Leistungsfähigkeit der Node Smartmachine lässt sich beim Erzeugen auswählen (RAM).

Cloud Foundry

Die Cloud Foundry von VMWare ist eine offene Applikationsplattform, die auch NodeJS unterstützt (neben Ruby on Rails und dem Java Spring Framework). Mit einem entsprechenden Cloud Foundry Account (momentan auch noch nicht frei verfügbar) kann man über ein Commandline Tool Anwendungen deployen. Git wird hier nicht direkt benötigt. Ausgehend vom Root Verzeichnis der NodeJS Anwendung kann man diesen Stand zur Cloud Foundry pushen. Dabei wird abgefragt wieviel RAM die Anwendung benötigt und auf wievielen Server Instanzen die Anwendung laufen soll.

Im Gegensatz zur No.de Smartmachine kann hier keinen Port angeben, auf dem die Anwendung laufen soll, sondern dieser wird durch die Plattform eigenständig zugewiesen. Zudem wird auch automatisch ein Webserver Proxy (Loadbalancer) erzeugt, der auf die verfügbaren NodeJS Anwendungsinstanzen verteilt, die man erzeugt hat.

Zudem kann man z.B. MongoDB oder Redis einfach als Services während des Deployments mit der Anwendung koppeln und darauf zugreifen. Die NodeJS Library Abhängigkeiten beschreibt man in einer JSON Datei im Rootverzeichnis der Anwendung und nutzt den "Bundle" Mechanismus von npm, um diese direkt mit der Anwendung auszuliefern. Das kann beim No.de Cloud Service zwar auch machen, bei Cloud Foundry ist es allerdings verpflichtend, da man keinen direkten Zugriff auf die Server Instanzen hat.

Fazit

Der Unterschied zwischen den beiden Cloud Services ist eindeutig. No.de erlaubt das Erzeugen von NodeJS optimierten Server Instanzen (also eher "Server Hosting" ähnlich zu Amazon EC2) und Cloud Foundry ist eine Applikationsplattform, die verwaltet wird und automatische Skalierung erlaubt (wie z.B. Heroku).

Ich habe mich für Cloud Foundry entschieden, da einem hier die Aufgabe der Skalierung der Anwendung abgenommen wird. Wenn man weitere Anwendungsinstanzen benötigt, kann man diese beim "Pushen der Anwendungen" zuweisen. Zudem sind notwendige Services wie z.B. MongoDB bereits vorhanden, können sofort genutzt werden und werden ohne eigenen Adminstrationsaufwand "mit skaliert". Braucht man mehr Kontrolle über den eigenen Server und z.B. einen direkten Zugriff auf das Filesystem sollte man sich eher für den No.de Service entscheiden.

Permalink | Leave a comment »

Was man tun kann, um auf eine EC2 Downtime vorbereitet zu sein

Fri, 22 Apr 2011 05:04:00 -0700

Backup, Backup, Backup...

Die Anwendungsdaten sollten so "beweglich" wie möglich sein, d.h. man sollte sich nicht nur auf seine EBS Laufwerke verlassen. Wie die aktuelle EC2 Downtime in der us-east Verfügbarkeitszone gezeigt hat, kann man sich nicht nur darauf verlassen Snapshots von seinen Laufwerken zu haben. Unter Umständen kann man keine neuen Laufwerke aus Snapshots erzeugen. Daher sollte man zusätzlich S3 Backups machen und am Besten auch noch ein Cloud Backup ausserhalb von AWS haben.

Wenn man es sich leisten kann, ist eine Datenbank Replikation ausserhalb der eigenen AWS Verfügbarkeitszone sinnvoll (auch problemlos mit RDS möglich). Auch hier gilt, am Besten auch ausserhalb von AWS...

Automatisiere deine Server Infrastruktur

Wenn deine EC2 Server Images nur auf EBS Laufwerke zur Verfügung stehen, kann das auch problematisch sein. Wenn EBS nicht verfügbar ist, können keine neuen Server Instanzen daraus gestartet werden, die man dann per Elastic IP verbinden könnte.

Daher sollte man sein komplettes Server Setup zusätzlich per Skript (z.B mit Chef) in einer anderen AWS Verfügbarkeitszone oder bei einem anderen Cloud Provider wiederherstellen können. Das Erstellen dieser Skripte kann unter Umständen zeitaufwendig sein, aber wenn es eine massive EC2 Downtime gibt, ist man dankbar für die investierte Zeit.

Bundle everything...

Auch die Library Abhängigkeiten deiner Anwendung können dir in den Weg kommen, wenn du kurzfristig auf eine neue Umgebung umgeziehst. Im Falle von Ruby on Rails sollte man darüber nachdenken, die Gem Abhängigkeit per Bundler direkt in die Anwendung zu integrieren (Packaging). Das erhöht den Grad der Mobilität deiner Anwendung und verringert den Einrichtungsaufwand deiner Server Umgebung. Hier muss dann nur Ruby und Bundler verfügbar sein, statt eine Vielzahl von Gems in der korrekten Version.

Neue Library Versionen haben oft kleinere API Änderungen zur Folge und können dann beim Umzug deiner Anwendung auch noch in Codeanpassungen enden oder eine Debugging Hölle verursachen, bis man das entsprechende Problem in einer Library gefunden hat.

Hab deine DNS Zone unter Kontrolle

Wenn man kurzfristig die komplette Anwendung umziehen muss, können die DNS Einstellungen deines Domain Providers ein großes Hindernis sein. Hier empfiehlt es sich die DNS Zone bei einem Provider zu betreiben, der extrem geringe TTL Zeiten und eine eigene Verwaltung erlaubt. Somit kann man schnell auf andere Elastic IP's verweisen oder gar auf eine IP bei einem anderen Cloud Provider. Also Massenprovider für DNS absolut vermeiden! Die Flexibilität bei diesen reicht einfach nicht und auch der Kontakt zum Support kann sehr frustrierend sein... Auch eine Sache, die einem erst im Notfall klar wird ;)

Verstehe die Abhängigkeiten der Cloud Services, die du benutzt

Meine Website z.B. war auch von der Downtime in der us-east Verfügbarkeitszone betroffen. Warum? Die Website selber läuft nicht in us-east, aber ich nutze als Cloud Service "mongohq", bei denen meine MongoDB betrieben wird. Dieser Cloud Service wiederum nutzt wie so viele alle andere Cloud Services auch EC2 Server Instanzen... Daher war ich dann auch direkt betroffen. Wusste ich im Vorfeld das mongohq seine Server in us-east bei AWS betreibt? Nicht wirklich...

Fazit

Sollte man nun auf EC2 und andere Cloud Provider verzichten? Nein. Downtimes können überall vorkommen und sind im Falle von EC2 recht selten. Aber man sollte der Cloud auch nicht blind trauen und vor allem muss man gut vorbereitet sein. Wie immer wenn es um den professionellen Betrieb von Webanwendungen geht, sind die Themen Standardisierung und Automatisierung extrem wichtig...

Permalink | Leave a comment »

Managing complexity

NodeJS Deployment in der Cloud

Was man tun kann, um auf eine EC2 Downtime vorbereitet zu sein