© feverpitched, 123RF

Laufen Applikationen in einem Cloudsystem wie den Amazon Web Services, spart sich der Betreiber die Verwaltung und kann sich stattdessen auf das Wesentliche der App konzentrieren. Mike Schilli führt im ersten Teil des Workshops die grundlegende Einrichtung des Webservice aus.

Startup-Firmen, die blitzartig den Markt aufmischen und sich auf den Ansturm von Millionen glücklicher User vorbereiten, wollen sich kaum mit einer Serverfarm aufhalten, deren Betrieb ein Händchen für Patches, Ausfallsicherheit und Skalierung erfordert. Movie-Primus Netflix oder Musik-Strömer Spotify machen kein Geheimnis daraus, dass große Teile ihrer Infrastruktur auf gemieteten Wolken der Amazon Web Services (AWS) laufen. Das macht sie zwar abhängig vom Betreiber, bietet aber offensichtlich auch Branchenriesen Vorteile.

Auswahl

Wer klein beginnen und die ersten paar Schritte in Richtung Clouddeployment wagen möchte, steht erst einmal vor einem Wust verschiedener Services und der emotionalen Hürde des Kreditkarten-basierten Serverbetriebs, für den Amazon aber nur Geld nimmt, sollte der Benutzer den Rahmen des “Free Tier” [2] sprengen.

Als ich mir neulich vornahm, das im Magazin 12/2016 erschienene Verfahren zur Bewegungserkennung in Überwachungsvideos [3] in der Cloud öffentlich verfügbar zu machen, las ich mich erst einmal in die kürzlich erschienenen Werke [4] und [5] ein und war überrascht, wie zügig sich einerseits ein Webservice von der Kommandozeile aus einrichten lässt, und dass es andererseits eine erstaunlich unübersichtliche Anzahl von Konfigurationsrädchen zu verstellen gilt.

Speichern in Eimern

Alles was einen Webservice ausmacht, also der Code, der abläuft, wenn ein Browser darauf zeigt, oder die Konfiguration der Zugangsberechtigungen, speichert Amazon in seinem “S3” genannten Storage-System. Da AWS dort liegende Dateien auf Wunsch auch gleich als statischen Inhalt auf einem Webserver ausliefern kann, ist dies oft der erste Schritt in die Welt der Clouds, dem dann kompliziertere Aufgaben folgen, etwa das Einrichten von Datenbanken, der Betrieb von Backend-Servern oder die Prüfung von Userkennungen.

Die Konsole auf http://console.aws.amazon.com ist der zentrale Einstiegspunkt (Abbildung 1), an dem der User seine Amazon-Kennung eingibt und auf dessen Konto bei notorischen Onlineshoppern bereits eine Kreditkarte hinterlegt ist. Der Reiter »Services« führt dann zu einer Seite, die einige Dutzend von Amazons Serverangeboten auflistet, von denen der Neuling »IAM« (Identity and Access Management) auswählen muss, um zunächst einen neuen User anzulegen und ihm die erforderlichen Berechtigungen zum Cloudbetrieb zuzuweisen.

Abbildung 1: Ein neuer User auf AWS bekommt den goldenen Schlüssel der Stadt.

Wer das Kästchen »Programmatic Access« aktiviert, bekommt eine Access-ID und einen Secret Access Key, mit dem das Kommandozeilentool »aws« unter dem Account des Users die Cloud konfigurieren kann.

Auf der folgenden Seite weist der Admin dem neuen User mittels so genannter Policies Rechte zu. Aus dem Wust von ein paar Dutzend ist hier über den Schalter »Attach existing policies directly« die Policy »AdministratorAccess« auszuwählen, damit der User neue S3-Buckets zum Ablegen seiner Codedateien anlegen darf (Abbildung 2). Später stehen für den laufenden Betrieb zum Live-Schalten neuer Releases oder zur Nutzung installierter Applikationen Policies mit weniger weit reichenden Rechten zur Verfügung, die sich wiederum mit Hilfe von Rollen praktisch kombinieren lassen.

Abbildung 2: Mit »AdministratorAccess«-Rechten darf der User neue S3-Buckets einrichten.

Drückt der Admin den Knopf zur Bestätigung, spuckt die Konsole für die spätere Identifizierung des neuen Users eine Access-ID aus, dazu einen passwortähnlichen Secret Access Key (Abbildung 3). Das Kommandozeilentool »aws« selbst ist in Python geschrieben und unter Linux flugs mittels

Abbildung 3: Per Access-ID und Secret Access Key kann der User mit Skripten auf den Account zugreifen.

sudo apt-get install python-pip
sudo pip install awscli

installiert. Damit das Tool später auf den Cloudserver zugreifen darf, konfiguriert der Kommandozeilen-Aufruf in Abbildung 4 die lokale Datei »~/.aws/credentials« mit den vom User eingespeisten Werten, damit spätere Aufrufe dort die Zugangsparameter finden und die AWS-Pforte passieren können.

Abbildung 4: Der Kommandozeilen-Client »aws« erhält Key-ID und Secret Key für späteren Onlinezugriff.

Daneben legt der Aufruf auch noch die Region mit »us-east-1« fest, um aus Amazons weltweit verstreuten Datacentern ein nahe liegendes auszuwählen. Nicht alle Datacenter bieten die gleichen Services an, da sollte der Admin vorab klären, ob das nächstgelegene auch alle Voraussetzungen erfüllt.

Ra-Ru-Rick, Servertrick

Die Befehlsfolge aus Abbildung 5 kreiert einen neuen S3-Bucket, der Dateien wie »index.html« einer statischen Testseite aufnimmt, und schiebt Letztere mit dem Kommando »sync« dorthin. Das Unterkommando »website« legt anschließend noch »index.html« als Einstiegs- und »error.html« als Fehlermeldungsdatei fest – und schon liefert Amazon unter dem ausgewiesenen Entry-Point Seiten aus, als wäre es ein ganz normaler Webserver (Abbildung 6).

Abbildung 5: Das Tool »aws« richtet einen S3-Bucket ein, kopiert ein »index.html« dorthin und konfiguriert die statische Webseite.

Abbildung 6: Eine Index.html-Datei in einem neu angelegten S3-Bucket dient als Testserver.

Für leichter zu merkende DNS-Einträge außerhalb der »amazonaws.com«-Domain ist der Anwender dann wieder selbst zuständig, ein »CNAME«-Eintrag beim Provider seines Vertrauens zeigt anschließend auf den Cloudserver.

Verstecktes Lambda

Wer statt statischer Webseiten Programme auf Amazons Backend-Servern ablaufen lassen möchte, greift auf das Lambda-Angebot zu. Es führt in Javascript, Python oder Java programmierte Funktionen in isolierten Containern aus, wahlweise per Web-API ausgelöst oder mit Events von anderen Services verknüpft.

So kann Amazons dynamische Datenbank Dynamo ein Event erzeugen, falls ein neuer Datensatz ankommt, der wiederum eine Lamda-Funktion auslöst, die weitere Schritte im Workflow geht. So besteht eine Cloudapplikation nicht aus einem durch Programmlogik orchestrierten Ablauf, sondern bildet sich durch Verknüpfen einzelner Komponenten zu einer Gesamtarchitektur.

Als Testfunktion in der Lambda-Welt dient das Python-Skript in Listing 1. Auf der Webkonsole ist hierzu der Eintrag »Lambda« in der Sektion »Computing« zu drücken. Nach einer Übersicht fordert der Service dazu auf, einen »Blueprint« für die Testfunktion zu wählen. Der Tester nimmt die »Blank Funktion«, überspringt die mit »Configure Triggers« überschriebene nächste Seite, trägt auf der folgenden – wie Abbildung 7 zeigt – den Namen ein (hier »wellHelloThere«) und kopiert den Code von Listing 1 in das unter »Edit Code Inline« gezeigte Textfenster.

1 def lambda_handler(event, context):
2     return "Well, hello from Lambda!"

Abbildung 7: Vorbereitung des Testskripts in Python als Lambda-Funktion.

Auf der folgenden Seite (Abbildung 8) hat die Konsole bereits den Namen der Handlerfunktion eingetragen. Da einer Runtime-Umgebung mehrere Dateien mit vielen Funktionen beiliegen können, spezifiziert der Admin hier sowohl Dateinamen als auch die darin liegende Funktion.

Abbildung 8: Zugriffsrechte vergibt AWS hier als Rolle.

Als Rolle für Ausführungsrechte lässt er »Create new role from template(s)« selektiert und gibt einen später erneut verwendbaren Namen an (hier »myBasicExecutionRole«). Nach der Bestätigung installiert Amazon die Lambda-Funktion in der Cloud und lässt sie vom User testen (Abbildung 9). Der kann einige Parameter im Json-Format hinzupacken, die das Skript später dynamisch auswertet.

Abbildung 9: Die Test-Konsole feuert eine in Python programmierte Lambda-Funktion ab.

Auch der Kommandozeilen-Client »aws« hat Zugriff auf das Lambda-Skript. Wie der Aufruf in Abbildung 10 zeigt, nimmt das Tool den Namen der vorher im Web-UI definierten Funktion »wellHelloThere« (nicht den Namen der Python-Funktion) entgegen sowie einen Json-Hash mit Eingabeparametern unter »–payload«, der im vorliegenden Testfall leer bleibt. Später landen etwaige Parameter in der »event«-Variablen der Python-Funktion, die sie dynamisch interpretiert.

Abbildung 10: Die Kommandozeile kann die Lambda-Funktion aufrufen.

Jetzt gilt es, dem Lambda-Skript beizubringen, die URL mit einem Video entgegenzunehmen, dieses vom Web zu pumpen und durch das Programm mit der Bewegungsanalyse aus [3] zu laden. Das benötigt nicht nur ein simples Python-Skript ohne Abhängigkeiten, sondern eine Laufzeitumgebung mit der Open-CV-Library und einem vorkompilierten statischen Binary. Wie das geht, wie man das Ergebnis verpackt, in die Cloud einspeist und einen Webservice definiert, der das Verfahren ausführt und das Ergebnis als Bilddatei zurückgibt, zeigt der Snapshot in der nächsten Ausgabe.