Kategorien
News

Google App Engine 1.7.0 steht in den Startlöchern – Neuer Standort in Europa

Auf seiner Entwicklerkonferenz Google I/O 2012 wird Google die Version 1.7.0 seines Platform-as-a-Service Google App Engine präsentieren. Neben der Verschlüsselungen von eigenen Domains und einem neuen Standort in der EU und der Performance Optimierung von statischem Inhalt auf Webseiten, gibt es viele weitere Neuigkeiten.

Google App Engine 1.7.0 steht in den Startlöchern

App Engine SSL eigene Domains

Entwickler können ihre Anwendungen ab sofort via HTTPS unter einer eigenen Domain ausrollen. Dazu kann entweder SNI oder VIP basierend auf SSL genutzt werden.

Server Name Indication (SNI)

Per SNI können mehrere Domains mit der selben IP Adresse genutzt werden, wobei jede Domain ein eigenes Zertifikat erhalten kann. SNI wird von den meisten aktuellen Web Browsern unterstützt. Die Nutzung von SNI kostet 9 US-Dollar pro Monat und beinhaltet 5 Zertifikate.

Virtual IP (VIP)

Damit erhält man eine dedizierte IP Adresse, die einer entsprechenden Anwendungen zugewiesen wird. VIP wird von allen SSL/ TLS kompatiblen Web Clients unterstützt. Dabei kann jeder VIP einen einzigen Hostname, Wildcard oder ein Multi-Domain Zertifikat bedienen. Ein VIP kostet 99 US-Dollar pro Monat.

Weitere Google App Engine in der EU

Die letzten vier Jahre wurden App Engine Anwendungen aus den USA heraus bereitgestellt. Auf Grund der Problematik mit den Latenzen und das jede Millisekunde zählt, hat sich Google entschieden, einen eigenen App Engine Cluster in Europa aufzubauen.

Allerdings steht dieser neue Cluster zunächst nur Nutzern mit Premium Accounts zur Verfügung. Wer sich für einen Premium Account interessiert, um den europäischen Cluster nutzen zu dürfen sowie Premium Support benötigt, kann sich mit dem Vertrieb unter appengine_premier_requests@google.com in Verbindung setzen.

PageSpeed – Beschleunigt das Internet

Seit ca. einem Jahr arbeitet das PageSpeed Team daran, den statischen Inhalt von Webseiten zu optimieren um den Zugriff auf die Seiten damit zu beschleunigen. Ab sofort können alle HRD Anwendungen (High Replication Datastore) diesen Service nutzen. Die Kosten für die Nutzung betragen 0,39 US-Dollar pro Gigabyte an ausgehender Bandbreite zzgl. der normalen ausgehenden Bandbreite der App Engine.

GeoPoint Unterstützung in der Suche-API

Ab sofort können die Geographische Breite (Latitude) und die Geographische Länge (Longitude) als ein GeoPoint in einem GeoField gespeichert werden und genutzt werden um Dokumente anhand dieses GeoPoints zu suchen.

Blob Migration Tool

Das Blob Migration Tool ist ab sofort verfügbar. Das Tool ermöglicht die Migration von Blobstore and Datastore Daten in einem Schritt.

Erweiterung der Quellcode Größen-Limitierung

Das Limit der Code-Größe einer Anwendung wurde nun von 150 MB pro Version auf 1 GB pro Anwendungen erhöht.

Erweiterung der Log API

Kostenpflichtige Anwendungen sind nun in der Lage festzulegen, wie lange Logdateien gespeichert werden sollen. Das ist bis zu einem Jahr möglich. Die Abrechnung für den Zugriff auf die Log Dateien per API wurde ebenfalls überarbeitet. Für 0,12 US-Dollar pro Gigabyte kann nun per API auf Logs zugegriffen werden, wenn 100 MB erreicht sind.

Go SDK for Windows

Ab sofort steht eine Test-Version des Go SDK für Windows zur Verfügung.


Bildquelle: https://developers.google.com

Kategorien
Analysen

Analyse: Die Platform-as-a-Service Umgebung von VMware Cloud Foundry

Ursprünglich startete Cloud Foundry als Plattform für das Deployment von Java Spring Anwendungen auf die Amazon Web Services. Im April 2011 folgte dann die Übernahme durch VMware, wodurch Cloud Foundry zu einem Open Source und Multi-Framework Platform-as-a-Service Angebot wurde, das eine Vielzahl von unterschiedlichen Sprachen und Laufzeitumgebungen unterstützt. Dazu gehören u.a. Java, Spring, Ruby, Scala und Node.js. VMware bezeichnet Cloud Foundry auch als ein Open PaaS, da die Plattform vom gewöhnlichen Notebook, über einen PC bis hin zu einer Public Cloud auf unterschiedlichen Systemen und Umgebungen genutzt werden kann.

Cloud Foundry ermöglicht das Multi-Cloud Deployment

Die Cloud Foundry Plattform setzt sich aus drei Bereichen zusammen. Der Erste bezieht sich auf die Wahl des Frameworks, der Zweite auf die Serviceunterstützung der Anwendung und die Dritte auf das Deployment.

Die Wahl des Frameworks

Cloud Foundry unterstützt neben Spring for Java, Rails und Sinatra for Ruby und Node.js ebenfalls JVM Sprachen wie Groovy, Grails und Scala. Hinzu kommt die Unterstützung für das Microsoft .NET Framework wodurch Cloud Foundry zur ersten nicht Microsoft Plattform gehörte, auf der .NET Anwendungen ausgerollt werden konnten. Alles zusammen macht Cloud Foundry zu einem der ersten mehrsprachigen PaaS.

Services für die Anwendung

In der Cloud sind Entwickler auf zuverlässige Messaging-Systeme, NoSQL Datenbanken zusammen mit relationalen Datenbanken angewiesen. Cloud Foundry unterstützt dafür neben RabbitMQ als Messaging-System sowie MongoDB und Redis als NoSQL Datenbanken, MySQL als relationale Datenbank. Die Liste der unterstützten Dienste wächst, so hat die Plattform zuletzt eine PostgreSQL-Unterstützung erhalten.

Das Deployment

Anhand von „Micro Cloud Foundry“ kann Cloud Foundry auf gewöhnlichen Notebooks oder Computer genutzt werden. Dazu beinhaltet die Micro Cloud Foundry den vollständigen Cloud Foundry Stack, mit dem virtuelle Maschinen auf einem PC oder Mac gestartet werden können. Cloud Foundry kann zudem in Private Cloud oder Public Cloud Umgebungen wie den Amazon Web Services betrieben werden. Das macht Cloud Foundry zu einem äußerst flexiblen PaaS.

Ausrollen von Anwendungen auf Cloud Foundry

Entwickler können Anwendungen entweder mit der SpringSource Tool Suite (STS) oder VMC, einer Ruby Gem Kommandozeile deployen.

Das Messaging System ist das Rückgrat von Cloud Foundry. Es handelt sich dabei um das zentrale Kommunikationssystem, über das alle Komponenten miteinander sprechen. Der HTTP Verkehr zu den einzelnen Anwendungen wird von Routern gesteuert. Diese routen die URLs zu den jeweiligen Anwendungen und übernehmen ebenfalls das Load Balancing des Verkehrs über die Instanzen.

Cloud Controller sind die Schlüsselkomponenten, die für die Verwaltung der Anwendungen zuständig sind. Sie verknüpfen die verschiedenen Services mit einer Anwendung und ermöglichen den Zugriff durch die externe REST API.

Ein Health Manager überwacht den Zustand aller ausgeführten Anwendungen. Fällt eine Anwendung aus, informiert er den Cloud Controller. Dieser ergreift die weiteren Maßnahmen.

Der ausführbare Code wird in Cloud Foundry zu Einheiten zusammengefasst und wiederum zu einem Droplet verpackt. Ein Droplet abstrahiert den zugrunde liegenden Code und stellt eine generische ausführbaren Code Einheit dar. Ein Droplet Execution Agent ist für die Ausführung des Codes innerhalb jedes Droplets verantwortlich und stellt das Betriebssystem und die Laufzeitumgebung bereit.

Fazit

Cloud Foundry ist ein schnell gewachsener und offener PaaS. Viele Hersteller haben ihre Unterstützung angekündigt und werden mit weiteren Plattformen und Services den Stack erweitern, was Cloud Foundry zu einer echten Alternative zu kommerziellen PaaS Angeboten wie Microsoft Windows Azure oder der Google App Engine werden lässt.

Kategorien
Tutorials

Einrichten eines Proxy Server mit der Google App Engine

Im Internet findet man viele Skripte die dabei helfen einen Proxy Server auf Basis von PHP zu erstellen. Einziger Nachteil ist, dass dafür ein eigener Webserver benötigt wird, um die Skripte zu hosten sowie eine eigene Domain, um den Proxy zu adressieren. Amit Agarwals beschreibt auf seinem Blog http://www.labnol.org wie man in 5 Minuten seinen eigenen kostenlosen Proxy Server unter Verwendung der Google App Engine einrichtet.

Dieser Artikel beschreibt, wie dabei vorzugehen ist.

Schritt 1: Google App Engine Account

Wenn nicht schon vorhanden muss zuerst ein Google App Engine Account eingerichtet werden. Dazu gehen wir auf http://appengine.google.com

Schritt 2: Erstellen der Application

Hier klicken wir auf „Create an Application“. Sollte dieses die erste Applikation sein, die für diesen Account erstellt wird, erhalten wir einen Verifizierungscode an unsere hinterlegte Mobilfunknummer. Diesen tragen wir in das dafür vorgesehene Feld ein.

Schritt 3: Auswahl einer Sub-Domain

Als nächstes wählen wir einen für die Sub-Domain, um den Proxy-Server zu adressieren. Die Sub-Domain entspricht dabei außerdem der App ID die als eindeutiger Identifier für die spätere Proxy Anwendung dient. In diesem Beispiel wird als Sub-Domain der Name labnol-proxy-server verwendet.

Schritt 4: Herunterladen von Python

Es ist soweit alles vorbereitet, um die Anwendung für den Proxy Server zur Google App Engine hochzuladen. Zunächst wird aber Python benötigt, dass wir uns unter http://python.org herunterladen und installieren.

Schritt 5: Installation des Google App Engine SDK

Als nächstes laden wir uns das Google App Engine SDK for Python von http://code.google.com herunter und installieren es.

Schritt 6: Herunterladen der Proxy Server Applikation

Mit http://img.labnol.org/files/proxy.zip steht bereits eine fertige Proxy Server Applikation bereit. Diese kann unter den oben genannten Link heruntergeladen werden und wird auf unserem Rechner entpackt.

Schritt 7: Einstellungen für die Google App Engine vornehmen

Unter der Einstellungen der Google App Engine müssen folgende Einstellungen vorgenommen werden.

Schritt 8: Anwendung der Google App Engine hinzufügen

In der (lokalen) Google App Engine klicken wir auf „File >> Add Exisiting Application“ und wählen die Anwendung aus, die wir in Schritt 6 heruntergeladen haben. Unter „Edit“ muss „YOUR_APP_ID“ noch gegen die eigene in Schritt 3 erstellte Sub-Domain ausgetauscht werden.

Schritt 9: Deployment der Proxy Server Applikation

Mit dem Button „Deploy“ kann die Anwendung veröffentlicht und genutzt werden.

Durch das Ändern der main.html kann aus Aussehen der Webseite des Proxys geändert werden. Zusätzlich können Google Analytics and AdSense hinzugefügt werden. Wurden Änderungen vorgenommen, reicht ein Klick auf den Button „Deploy“ oder der Befehl -- appcfg.py update

Beispiel Live

Unter http://labnol-proxy-server.appspot.com kann der Proxy Server auf Basis der Google App Engine Live getestet werden.

Video Tutorial

Amit Agarwals hat zusätzlich ein Video veröffentlicht, in dem die oben beschriebene Vorgehensweise nachvollzogen werden kann.

Quelle