Monthly Archives: December 2013

Continuous Deployment in Windows Azure

Beim letzten Mal haben wir gesehen wie man MongoDB in Windows Azure betreiben kann. Heute möchte ich in eine andere Richtung gehen, die ich auch im letzten Jahr in einer vierteiligen Videoserie in Zusammenarbeit mit der Developer Platform Evangelism Group von Microsoft Deutschland aufgenommen habe. Es soll um Continuous Deployment in Windows Azure gehen. Die Videoserie damals beinhaltete die schnelle und sichere Bereitstellung von Webanwendung auf Windows Azure und setzte sich aus folgenden Teilen zusammen

Heute möchte ich das Thema erneut aufgreifen, da auf der einen Seite das Thema immer noch sehr aktuell ist und auf der anderen Seite hat sich Windows Azure in dieser Hinsicht stark weiterentwickelt. Wenn ich sage “stark weiterentwickelt” heißt das nicht, dass Microsoft alles über den Haufen geworfen hat, was vor einem Jahr noch aktuell ist. Ganz im Gegenteil: Alles, was damals möglich war ist es heute immer noch. Durch die großartige Arbeit des Team Foundation Server- und Windows Azure-Teams haben wir heute aber noch bessere und einfachere Möglichkeiten. Aber zuerst die Grundlagen!

Continue reading

MongoDB in Windows Azure

Nachdem es beim letzten Mal um agile Virtualisierung mit Windows Azure ging möchte ich heute in eine ähnliche Richtung gehen beziehungsweise darauf aufbauen.

Vor fast einem Jahr habe ich in Zusammenarbeit mit der Developer Platform Evangelism Group von Microsoft Deutschland eine Videoserie zum Thema “MongoDB auf Windows Azure” aufgenommen. Das ganze hat sich in vier Videos aufgeteilt:

Bereits ein Jahr davor habe ich auf TechNet einen Artikel veröffentlicht, wie man mit MongoDB auf Windows starten kann.

Warum komme ich immer wieder auf das Thema MongoDB zurück? MongoDB entwickelt sich immer weiter, bietet immer mehr Möglichkeiten und die Verbreitung nimmt immer mehr zu. In der heutigen Zeit, wo die Größe von Datensätzen immer stärker zunimmt, stoßen relationale Datenbanken immer mehr an ihre Grenzen. Natürlich kann man mit ihnen auch auf einem SQL Server arbeiten, aber NoSQL-Datenbanken bieten hier meistens mehr Komfort und verhindern eine Menge Overhead und Kopfschmerzen. Auch im Zusammenhang mit Cloud Computing gewinnen NoSQL-Lösungen immer noch an Bedeutung.

Insbesondere die Verbreitung von MongoDB lässt sich sehr einfach auf Windows Azure nachvollziehen. Vor zwei Jahren war es schwer möglich MongoDB auf Azure zum Laufen zu bringen. Letztes Jahr war ich noch auf die Windows Azure Virtual Machines beschränkt. Heute möchte ich den aktuellen Stand und die Möglichkeiten eines MongoDB-Deployments auf Windows Azure kurz vorstellen. Aber bevor wir starten ein kurzer Refresher…

Was ist MongoDB?

Ursprünglich von 10gen entwickelt nennt sich die Firma hinter MongoDB mittlerweile MongoDB, Inc. Sie beschreibt MongoDB wie folgt

MongoDB is an open-source database used by companies of all sizes, across all industries and for a wide variety of applications. It is an agile database that allows schemas to change quickly as applications evolve, while still providing the functionality developers expect from traditional databases, such as secondary indexes, a full query language and strict consistency.

In den verschiedenen Varianten von NoSQL-Datenbanken reiht sich MongoDB im Bereich der Dokumenten-orientierten Datenbanken ein. Wie der Name schon sagt werden bei diesen Datenbanken Daten in Dokumenten gespeichert. Bei MongoDB werden diese im sogenannten Binary JSON (BSON) Format abgespeichert. Für Entwickler bedeutet dies, dass Daten sehr einfach in JSON abgelegt werden. Muss man sich als Entwickler mit komplizierten APIs rumschlagen und das JSON selber zusammenbauen? An diesem Punkt zeigt MongoDB eine seine Stärken. Es gibt 13 supportete Driver und 37 von der Community entwickelte Driver. Diese Driver sind die Schnittstelle um mit MongoDB aus den verschiedensten Programmiersprachen heraus zu arbeiten, was im NoSQL-Bereich so nicht üblich ist. .NET-Entwickler können sich über eine sehr gute API, aber auch eine gute Dokumentation freuen.

Auf welchen Betriebssystemen kann man mit MongoDB arbeiten? Viele Entwickler werden überrascht sein, dass man MongoDB sehr einfach unter Windows zum Laufen bekommt. Das natürliche Umfeld für MongoDB ist aber Linux. Microsoft selber nutzt in Großteilen der Dokumentation zu Windows Azure CentOS als Grundlage, aber man ist hier ziemlich frei in der Auswahl.

Wie kann ich MongoDB auf Windows Azure nutzen?

Es gibt vom Prinzip her zwei Varianten, wie man MongoDB auf Windows Azure betreiben kann: Die Windows Azure Virtual Machines und den Windows Azure Store. Diese beiden wiederum teilen sich in mehrere Lösungen auf. Beginnen wir mit den Windows Azure Virtual Machines.

Man kann MongoDB selber auf einer Linux VM in Windows Azure aufsetzen. Einen Ansatz dafür habe ich letztes Jahr in meiner Video-Serie gezeigt. Einfacher ist es aber, das beim letzten Mal vorgestellte VM Depot von Microsoft Open Technologies zu nutzen. Hier findet man zwei vorbereitete VMs für MongoDB

  1. Den MEAN Stack auf Ubuntu von BitNami. Diese VM beinhaltet MongoDB, Express, Angular, Node.js, Git, PHP und MongoRock
  2. MongoDB v2.2.3 von Cognosys

VM Depot

Um diese VMs zu nutzen geht man genauso vor wie ich es beim letzten Mal beschrieben habe. Im Management Portal von Windows Azure sucht man sich die entsprechende VM raus, läd sie herunter, registriert sie und letzendlich startet man sie.

Es gibt aber noch eine zweite Möglichkeit, den sogenannten Windows Azure Store. Dieser enthält mehrere Services, die in Azure genutzt werden können. Neben MongoDB gehören ClearDB MySQL, New Relic und SendGrid zu den bekanntesten Add-Ons. Wie kann man den Windows Azure Store aus dem Management Portal heraus nutzen? Wie in Azure üblich wählt man New und dann Store aus.

New Add-On

Interessant für uns sind hier zwei Add-Ons: MongoDB – Preview und MongoLab.

Store

Die MongoDB – Preview wird von MongoDB, Inc. selbst bereitgestellt und bietet zurzeit nur eingeschränkte Möglichkeiten. Um sie nutzen zu können ist eine Einladung nötig. Weiterhin ist ein Deployment nur in das West US Rechenzentrum möglich.
MongoLab gibt es schon länger auf Windows Azure und ist derzeit die bessere Lösung. Mit MongoLab ist neben Azure auch ein Deployment auf Amazon, Google, Joyent und Rackspace möglich. Ein großer Vorteil ist, dass man schnell eine Testdatenbank erstellen kann, da eine 500 MB Datenbank frei ist. Ein Nachteil ist, dass man nur in eins von zwei US Rechenzentren deployen kann. Insbesondere aus Europa muss hier mit höherem Traffic gerechnet werden. Neben dem Erstellen einer MongoDB-Instanz anhand von MongoLab aus dem Management Portal kann das Deployen auch über die Seite von MongoLab durchgeführt werden. Diese bietet im Anschluss gute Möglichkeiten für das Monitoring.

Zusammenfassung

Es ist nicht schwer MongoDB auf Azure zum Laufen zu bringen. Wie gezeigt hat man als Entwickler zwei primäre Möglichkeiten des Deployments

  1. Das Einrichten einer Instanz über die Windows Azure Virtual Machines.
  2. Das Einrichten einer Instanz über den Windows Azure Store anhand der MongoDB – Preview oder MongoLab.

Beide Varianten haben ihr Vor- und Nachteile. Wenn eine Testinstanz schnell zur Verfügung stehen muss oder der Administrationsaufwand minimiert werden soll, ist der Windows Azure Store die beste Alternative. Steht Skalierung und mehr Kontrolle über die einzelnen Instanzen oder das Cluster im Fokus stößt man bei MongoLab schnell an seine Grenzen. In diesem Fall bieten sich die Virtual Machines an.

Ein Wort der Warnung: Der Windows Azure Store befindet sich derzeit noch in einer Preview und ist nicht in jedem Land verfügbar. Dies wird sich aber mit hoher Wahrscheinlichkeit in den nächsten Monaten ändern.

– Jan (@Horizon_Net)

Agile Virtualisierung mit Windows Azure

Agil, agil, agil müsst ihr sein! Wer hat diesen Satz noch nicht in den letzten Jahren gehört. Alles soll agiler werden. Meist bezieht sich das Wort “agil” aber nur auf die Entwicklerteams. Müssen nur Entwickler agil sein? Sollte sich nicht auch ihre Umgebung, in diesem Fall die benötigte Infrastruktur, agil verhalten, sprich sich an ihre Bedürfnisse anpassen?

Dies hört sich meist einfacher an als es in Wirklichkeit ist. In großen Unternehmen kann man von Glück reden, wenn innerhalb weniger Tage die gewünschte Infrastruktur bereitsteht. Dieses Problem beschränkt sich aber nicht nur auf große Unternehmen. Diese besitzen in der Regel alles, was benötigt wird. Aber wer hat nicht schon mal mit der Bürokratie zu kämpfen gehabt. Auch Kleinunternehmer und Startups treffen dieses Problem öfter an als gewünscht.

Wie lässt sich dieses Problem lösen?

Was ist eigentlich das Problem?

Um das Problem zu verdeutlichen stellen wir uns stellvertretend die Firma XYZ vor. XYZ ist ein kleines Startup, das in den verschiedensten Bereichen vertreten ist. Neben eigener App-Entwicklung für iOS, Android, Windows Phone und Windows 8 agiert XYZ als Berater in verschiedenen Entwicklungsprojekten für Kunden. Diese Entwicklungsprojekte reichen von Java EE-Projekten bis hin zur Web-Entwicklung mit Node.js. Die Entwickler bedienen sich der mehr und mehr beliebten Arbeitsweise des Bring-Your-Own-Device. Einer dieser Entwickler ist Max Mustermann. Max, seines Zeichens ein Allround-Talent, wirkt derzeit sowohl in der eigenen App-Entwicklung als auch in einem Node.js-Projekt mit. Was braucht Max als Entwickler hierfür? Erstellen wir eine kurze Liste. Er benötigt

  • IntelliJ für die Android-Entwicklung
  • Visual Studio für die App-Entwicklung auf Windows Phone und Windows 8
  • Eine Node.js-IDE seiner Wahl und diverse Browser
  • Windows 8 + Windows Phone Simulator

Kann man das auf Max seinem Laptop noch unterbringen? Sicherlich, aber damit sind wir ja noch nicht am Ende unserer Weisheit. Welche Sachen fehlen noch, damit Max wirklich so arbeiten kann wie er es möchte?

  • Einen Web-Server
  • Codeverwaltung + Bug-Tracking
  • Einen Build Server
  • Einen Datenbank-Server

Mit diesem Setup sind wir von der Wirklichkeit gar nicht so weit entfernt. Was macht Max mit den letzten vier Komponenten? Auch auf seinem Laptop installieren? Was passiert wenn noch ein anderer Entwickler Zugriff auf die Codeverwaltung braucht? Mindestens ein, besser noch vier Server müssen her. Kann sich das XYZ leisten? Für ein Projekt, das vielleicht in ein paar Wochen wieder vorbei ist?

Wie könnte eine (mögliche) Lösung aussehen?

Eine Möglichkeit, die seit Jahren genutzt wird, ist die Virtualisierung. Sei es nun auf dem eigenen Rechner oder einem Server, man schwitzt stundenlang beim Einrichten der gewünschten VM und wehe man muss mal ein System aufsetzen mit dem man keine Erfahrung besitzt.

Wie sieht das für Max aus? Aufgrund eines fehlenden IT-Administrators hat Max das Glück seine gewünschten vier Server selber einzurichten. Als erstes macht er sich an den Web-Server. Hier hat er die Qual der Wahl: Windows Server oder doch besser mit einem Linux-Derivat gehen? Aufgrund der Lizenzkosten für einen Windows Server entschließt sich Max für einen Ubuntu Server. Als jemand, der mit Windows aufgewachsen ist und froh ist dass grafische Oberflächen erfunden wurden, für ihn mehr eine Qual als Vergnügen. Aber halt, muss Max wirklich einen eigenen Web-Server einrichten? Eigentlich nicht. Die Windows Azure Web Sites nehmen ihm hier den Einrichtungsaufwand und die Administration ab. Problem 1 gelöst, aber jetzt geht es schon an die Codeverwaltung.
Auch hier hat Max die Qual der Wahl, aber aufgrund eigener Erfahrung kann er es schnell auf den Team Foundation Server oder Git eingrenzen. Aber halt zum zweiten, muss Max sich wirklich für eines von beiden entscheiden? Was die Art der Versionsverwaltung angeht ein deutliches Ja, aber betrifft das auch die Plattform? Seit geraumer Zeit ist auf dem TFS auch Git möglich. Natürlich möchte Max nicht selber den TFS einrichten und könnte hierfür auf den TFS Online zurückgreifen. Max ist aber eigentlich kein TFS-Freund und möchte lieber etwas in die Richtung GitHub haben und ist bereits über GitLab gestolpert. Es heißt aber wieder Linux aufsetzen und GitLab einrichten. Eigener Server? Fehlanzeige, aber es gibt ja die Windows Azure Virtual Machines. Problem 2 gelöst, jetzt fehlt noch der Build-Server. Aufgrund der Entscheidung gegen den TFS muss etwas anderes her.
Wie wäre es mit Jenkins? Und das bekannte Problem, Linux und Jenkins einrichten.
Max hat schon eine Vorahnung was den Datenbank-Server betrifft. Hier würde er am liebsten MongoDB einsetzen, aber MongoDB auf einem Windows Server installieren? Ziemlich unhandlich, also ein letztes Mal Linux aufsetzen und MongoDB einrichten.

Klingt nach viel Arbeit und viel Aufwand, oder? Nicht unbedingt!

3W

Und wie mache ich das praktisch?

Klingen die Probleme von Max bekannt? Wie könnte Max jetzt effektiv und ohne viel Aufwand seine Umgebung einrichten? Eine Möglichkeit wäre die VM Gallery der Windows Azure Virtual Machines durchzugucken, die Basisinstallation des Betriebssystems durchzuführen und anschließend die gewünschte Anwendung installieren. Es geht aber leichter!

Wer sich intensiver mit den Windows Azure Virtual Machines auseinandergesetzt hat, dem wird im unteren Bereich ein kleines Icon auffallen:

Browse VM Depot

Browse VM Depot ist unser Einstieg in eine wunderschöne, doch relativ unbekannte Welt.

Choose an image

Diese Übersicht ist aber ziemlich unhandlich und lässt Max nicht auf die Schnelle finden, was er benötigt. Hinter dieser Übersicht versteckt sich aber keine andere Quelle als eine Webseite: Das VM Depot von Microsoft Open Technologies. Dieses bietet Max eine einfache Möglichkeit nach den benötigten Anwendungen zu suchen. Was benötigt er also?

  • GitLab
  • Jenkins
  • MongoDB

Die Suche kann beginnen. Den Anfang macht GitLab. Hier haben wir bereits die Qual der Wahl zwischen den verschiedensten Versionen, aber definitiv vorhanden. Weiter geht es mit Jenkins. Hier sieht das Ergebnis ähnlich aus. Fehlt noch MongoDB und auch dieses ist vorhanden.

Aber was ist das VM Depot überhaupt? Ähnlich wie die VM Gallery im Windows Azure Management Portal bietet es verschiedenste VMs, die man ohne viel Aufwand in eine Windows Azure Virtual Machine installieren kann. Hier ist aber der Hauptpunkt: Man muss sich nicht um die Betriebssystem-Installation kümmern und man verhindert das mühsame Aufsetzen der jeweiligen Anwendung (was insbesondere bei GitLab ein Segen sein kann). Es sind in der Regel nur drei Schritte notwendig

  1. Herunterladen des gewünschten Images
  2. Registrieren des Images
  3. Bereitstellen des Images

Alle diese Schritte sind weitesgehend automatisiert und ohne große Benutzerinteraktion möglich.

Und was macht man, wenn bspw. MongoDB nicht mehr benötigt wird? Einfach VM und Image löschen und schon ist alles beim Alten.

Max, mittlerweile ziemlich begeistert, möchte jetzt noch einen Schritt weitergehen. Wäre es nicht gut eine Entwicklungsumgebung zu haben, die mehr Power hat als sein kleiner Laptop? Auch dies ist durch die VM Gallery möglich. Hier gibt es bereits vorgefertigte Images für Visual Studio 2013 auf einem Windows Server 2012.

VS 2013

Fazit

Es kann schwierig sein als Entwickler seine Entwicklungsumgebung an die eigenen Bedürfnisse anzupassen. Es fehlt die Erfahrung in der Installation verschiedenster Systeme. Meistens fehlt aber die Zeit. Mit dem VM Depot kann man beide Probleme elegant lösen und die eigene Infrastruktur immer den Erfordernissen anpassen, die gegenwärtig vorhanden sind. Ist es aber eine Allzweckwaffe, die Max einsetzen kann? Nicht immer. Welche Alternativen hätte er noch gehabt? Visual Studio Online und MongoLab wären zwei gewesen.

Dieser Artikel ist hauptsächlich von Windows Azure als Cloud Plattform ausgegangen. Ist dies auch bei anderen Cloud-Anbietern möglich? Natürlich! Jeder Anbieter, der Infrastructure-as-a-Service (IaaS) bereitstellt, kann für agile Virtualisierung genutzt werden. Der Komfort beim Einrichten ist aber durchaus unterschiedlich.

Zum Abschluss ein kleines Video, das die Arbeit mit dem Windows Azure VM Depot und der Windows Azure VM Gallery veranschaulicht. In diesem wird eine Cassandra Datenbank, ein SQL Server, ein Visual Studio 2013 und GitLab aufgesetzt.

– Jan (@Horizon_Net)