Laufen Applikationen nicht auf dezidierten Servern sondern in einem Cloud-System wie Amazon Web Services, spart sich der Betreiber die Verwaltung und kann sich statt dessen auf das Wesentliche der App konzentrieren.
Startup-Firmen, die blitzartig den Markt aufmischen und sich auf den Ansturm von Millionen glücklicher User vorbereiten wollen, können sich kaum mit einer Serverfarm aufhalten, deren Betrieb ein stetiges Händchen für Sicherheits-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 zweifelsohne abhängig vom Betreiber, bietet aber offensichtlich auch Branchenriesen genügend Vorteile.
Wer klein beginnen und die ersten paar Schritte in Richtung Cloud-Deployment wagen möchte, steht erst einmal vor einem Wust verschiedener Services und der emotionalen Hürde des Kreditkarten-basierten Serverbetriebs, von der Amazon aber nur Geld nimmt, falls der Benutzer die Rahmenbedingungen des generösen "Free Tier" [2] sprengt. Als ich mir neulich vornahm, das in der Dezemberausgabe erschienene Verfahren zur Bewegungserkennung in Überwachungsvideos [3] auf der Wolke öffentlich verfügbar zu machen, las ich mich erst einmal in die kürzlich erschienenen Werke [4] und [5] ein und war erstaunt, wie zügig sich einerseits Webservice von der Kommandozeile aus einrichten lässt, und dass es andererseits eine erstaunlich unübersichtliche Anzahl von Konfigurationsrädchen zu verstellen gilt.
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 Cloud-Welt, dem dann kompliziertere Aufgaben, wie das Einrichten von Datenbanken, der Betrieb von Backend-Servern oder die Prüfung von User-Kennungen folgen.
| |
| Abbildung 1: Ein neuer User auf AWS erhält den goldenen Schlüssel der Stadt. |
Die Konsole auf console.aws.amazon.com ist der zentrale Einstiegspunkt
(Abbildung 1), an dem der User seine Amazon-Kennung eingibt, auf dessen Konto
bei notorischen Online-Shoppern praktischerweise bereits eine Kreditkarte
hinterlegt ist. Der Reiter "Services" führt dann zu einer Seite, die einige
Dutzend von Amazons Server-Angeboten auflistet, und von denen der Neuling "IAM"
(Identity and Access Management) auswählen muss, um zunächst einmal einen neuen
User anzulegen und diesem die erforderlichen Berechtigungen zum Cloudbetrieb
zuzuweisen. Wer das Kästchen "Programmatic Access" aktiviert, bekommt eine
Access ID und einen "Secret Access Key", mit dem das Kommandozeilen-Tool aws
unter dem Account des Users die Cloud konfigurieren kann.
 |
| Abbildung 2: Mit "AdministratorAccess"-Rechten darf der User neue S3-Buckets einrichten. |
Auf der folgenden Seite weist der Admin dem neuen User mittels sogenannter "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 Code-Dateien anlegen darf (Abbildung 2). Später stehen für den laufenden Betrieb zum Live-Schalten neuer Releases oder zur Nutzung von installierten Applikationen Policies mit weniger weitreichenden Rechten zur Verfügung, die sich wiederum mit Hilfe von Rollen praktisch kombinieren lassen. 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, sowie einen passwort-ähnlichen "Secret Access Key".
 |
| Abbildung 3: Mit Access ID und Secret Access Key kann der User mit Skripts auf den Account zugreifen. |
Das Kommandozeilen-Tool aws selbst ist in Python geschrieben und wird auf
Linux flugs mittels
sudo apt-get install python-pip
sudo pip install awscli
installiert. Damit das Python-Tool
aws später auf Cloud-Server zugreifen darf, konfiguriert
der Kommandozeilenaufruf 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. Daneben legt der Aufruf auch noch die
Region mit us-east-1 fest, um aus Amazons weltweit verstreuten
Datacentern ein naheliegendes auszuwählen. Nicht alle Datacenter bieten
die gleichen Services an, da sollte der Admin vorab klären, ob der
nächstgelegenste auch alle Voraussetzungen erfüllt.
 |
|
Abbildung 4: Der Kommandozeilen-Client C |
Die Befehlsfolge aus Abbildung 5 kreiert dann einen neuen s3-Bucket zur
Aufnahme von Dateien einer statischen Testseite in index.html und schiebt
letztere mit dem Kommando "sync" dorthin. Das Unterkommando "website" legt
anschließend 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 normaler Webserver (Abbildung 6).
Für leichter zu merkende DNS-Einträge außerhalb der amazonaws.com-Domain ist
der Anwender selbst zuständig, ein CNAME-Eintrag beim Provider seines
Vetrauens zeigt anschließend auf den Cloud-Server.
 |
| 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 in der Amazon-Cloud. |
Wer statt statischer Webseiten Programme auf Amazons Backend-Servern ablaufen lassen möchte, greift auf das sogenannte 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 verknüpft, die von anderen Services abgefeuert wurden. So kann zum Beispiel Amazons dynamische Datenbank Dynamo einen Event erzeugen, falls ein neuer Datensatz ankommt, der dann wiederum eine Lamda-Funktion auslöst, die ihrerseits weitere Schritte im Workflow auslöst. So besteht eine Cloud-Applikation nicht aus einem explizit durch Programmlogik orchestrierten Ablauf, sondern bildet sich implizit durch Verknüpfen einzelner Komponenten zu einer Gesamtarchitektur.
Als Testfunktion in der Lambda-Welt soll dass Python-Skript in Listing 1 herhalten. Auf der Webkonsole auf amazonaws.com ist hierzu der Eintrag "Lambda" in der Sektion "Computing" zu drücken und nach einer Übersicht fordert der Service den User auf, einen "Blueprint" für die Testfunktion auszuwählen. Der quirlige Tester wählt ist "Blank Funktion" aus, überspringt die mit "Configure Triggers" überschriebene nächste Seite, trägt auf der folgenden wie in Abbildung 7 gezeigt den Namen ein (im Beispiel "wellHelloThere") und kopiert den Code in Listing 1 in das unter "Edit Code Inline" angezeigte Textfenster.
 |
| Abbildung 7: Vorbereitungs des Testskripts in Python als Lambda-Funktion. |
Weiter geht es auf der folgenden Seite in Abbildung 8, wo die Konsole bereits den Namen der Handlerfunktion eingetragen hat. Da einer Runtime-Umgebung mehrere Dateien mit vielen Funktionen beiliegen können, spezifiziert der Admin hier sowohl Dateinamen als auch die darinliegende Funktion. Als Rolle für Ausführungsrechte lässt er "Create new role from template(s)" selektiert und gibt einen später wiederverwendbaren Namen an (hier "myBasicExecutionRole").
 |
| Abbildung 8: Zugriffsrechte vergibt AWS hier als Rolle. |
1 def lambda_handler(event, context):
2 return "Well, hello from Lambda!"
Nach der Bestätigung installiert Amazon die Lambda-Funktion in der Cloud und lässt sie vom User austesten. Dieser kann einige Parameter im JSON-Format hinzupacken, die das Skript später dynamisch auswerten kann.
 |
| Abbildung 9: Die Test-Konsole feuert eine in Python programmierte Lambda-Funktion ab. |
Auch der Kommandozeilen-Client aws hat Zugriff auf das neu installierte
Lambda-Skript. Wie der Aufruf in Abbildung 10 zeigt, nimmt das Tool den Namen
der vorher in der Web-UI definierten Funktion wellHelloThere (wohlgemerkt:
nicht den Namen der Python-Funktion, sondern den Namen der in der Web-UI
definierten Lambda-Funktion) entgegen, sowie einen JSON-Hash mit
Eingabeparametern unter --payload, der allerdings
im vorliegenden Testfall leer bleibt. Später landen etwaige Parameter so
in der event-Variablen der Python-Funktion und können von dieser
dynamisch interpretiert werden.
 |
| Abbildung 10: Auch der Kommandozeilen-Client kann die Lambda-Funktion aufrufen. |
Was nun noch fehlt, ist, dem Lambda-Skript beizubringen, eine URL mit einem Video entgegenzunehmen, dieses vom Web zu pumpen und durch das Programm mit der Bewegungsanalyse aus [3] zu laden. Das Verfahren benötigt jedoch nicht nur ein simples Python-Skript ohne Abhängigkeiten, sondern eine Laufzeitumgebung mit der openCV-Library und einem vorcompilierten statischen Binary. Wie das geht, wie man das Ergebnis verpackt, in die Amazon-Cloud einspeist und dann einen Webservice definiert, der das Verfahren ausführt und das Ergebnis als Bilddatei zurückgibt, das zeigt der Snapshot nächsten Monat. Bis dann!
Listings zu diesem Artikel: http://www.linux-magazin.de/pub/listings/magazin/2017/02/perl-snapshot
"AWS Free Tier", Maximale Nutzungsraten für den kostenlosen Betrieb der AWS-Wolke, https://aws.amazon.com/free
"Schaut auf diese Stadt", Michael Schilli, Linux-Magazin 2016/12, http://www.linux-magazin.de/Ausgaben/2016/12/Perl-Snapshot
"AWS Lambda in Action", Danilo Poccia, Manning 2017
"Serverless Single Page Apps: Fast, Scalable and Available", Ben Rady, The Pragmatic Bookshelf, 2016
 |
Michael Schilliarbeitet als Software-Engineer in der San Francisco Bay Area in Kalifornien. In seiner seit 1997 laufenden Kolumne forscht er jeden Monat nach praktischen Anwendungen verschiedener Programmiersprachen. Unter mschilli@perlmeister.com beantwortet er gerne Ihre Fragen. |