Wie im letzten Teil beschrieben, fehlt noch ein Puzzlestück zur Fertigstellung eines funktionierenden Feedback-Formulars. Im betont einfachen Beispiel sollen die Angaben, die im Formular eingegeben wurden, per Mail an den Betreiber der Website geschickt werden.
Mailversand mit PHP
Die einfachste Möglichkeit, die Nutzung der PHP-eigenen mail()-Funktion war schnell auszuschließen, da dies schlicht und einfach nicht funktionierte. Ich hatte mich dies auch bereits gedacht, denn zumindest muss PHP dazu entsprechend konfiguriert sein, einen SMTP-Server zu nutzen, der auch auf dem jeweils verwendeten Server installiert sein kann. Die zweite Möglichkeit bestand darin, sich per SMTP auf einen entfernten Mailserver zu verbinden, und zwar mit dem Mailserver des Empfängers. Da die Feedback-Mails ausschließlich an meine Mailadresse gerichtet sein sollten, lag es nahe, dass sich PHP mit meinem Mailserver verbindet und die Mails einfach einliefert. Um nicht allzu tief im SMTP-Protokoll, Socket-Verbindungen und ähnlichen Gegebenheiten waten zu müssen, sollte die Library PHPMailer eingesetzt werden. PHPMailer bietet eine Abstraktionsebene, auf der sich eine Vielzahl von Optionen zum Versenden von Mails sehr einfach einstellen lassen, das beinhaltet auch Möglichkeiten zur Authentifizierung, Versenden von Attachments usw.. Zwar brauchte ich nur wenig davon, aber immerhin konnte ich so auf eine erprobte und viel genutzte Lösung setzen.
Der erste Versuch mit PHPMailer bestand nun darin, eine SMTP-Verbindung mit dem Mailserver, der für die Domain geschke.net zuständig war, aufzunehmen. Lokal zu Testzwecken hatte dies prima funktioniert – der Port 25 meines Mailservers war erreichbar, die Mail konnte eingeliefert werden und wurde mir daraufhin umgehend zugestellt.
Als ich jedoch den Code in der Function Compute Umgebung deployed habe, erreichte mich keine einzige Mail. Auch wenn ich in der Dokumentation keine expliziten Hinweise darauf gefunden habe, vermute ich, dass es innerhalb der Function Compute Runtime einfach nicht erlaubt ist, sich per Port 25 mit externen Servern zu verbinden.
Die Cloud-Lösung
Aber Alibaba Cloud bietet ja auch einen Mail-Dienst zur Auslieferung von Mails, genannt DirectMail (DM). Dabei handelt es sich nicht um ein Mail-Postfach wie bei einem klassischen Provider, sondern um einen Service zum reinen Versand von Mails. Dabei wird auch eine größere Anzahl von Mails erlaubt, wobei jedoch Limits pro Tag bzw. Monat bestehen. Andererseits ist erneut ein kostenloses Kontingent enthalten, das für meine Zwecke mehr als ausreichend sein sollte. DirectMail kann entweder per eigener API oder mit dem Standard-Protokoll SMTP genutzt werden. Da Letzteres von PHPMailer nativ unterstützt wird, fiel meine Wahl auf SMTP.
Die Nutzung von DirectMail muss man, analog zu allen anderen Alibaba Cloud-Diensten, zunächst aktivieren.
Der folgende Screenshot zeigt die Orte der Rechenzentren, die DirectMail anbieten. Wie häufiger bei Cloud-Dienstleitern vorzufinden, stehen nicht alle Services an jedem Ort zur Verfügung. Da DirectMail noch nicht innerhalb von Rechenzentren in Europa verfügbar war, habe ich die Standard-Auswahl Singapur beibehalten. Zwar ist die Nutzung innerhalb der Alibaba Cloud-Dienste vollkommen transparent, aber somit reisen die Mails nun zunächst von Frankfurt, dem Ort, an dem der Function Compute Dienst verwendet wird, nach Singapur, und von dort zu meinem Mailserver, der sich laut Provider in Frankfurt, laut Geolocation-IP-Abfrage in Berlin befinden soll. Naja, Berlin oder Frankfurt ist letztlich irrelevant, denn was sind schon etwas mehr als 500 km gegenüber dem Hin- und Rückweg nach Singapur zu jeweils etwas mehr als 10200 km Luftlinie. Der einzige Unterschied in der Nutzung ergibt sich aus der Bezeichnung der SMTP-Server, deren Adressen in der Dokumentation genannt werden.
In der Übersicht von DirectMail werden der Status und die Quota angezeigt, netterweise sind wiederum einige Mails pro Tag völlig kostenlos. Auf die Credit Level will ich hier gar nicht weiter eingehen, weil ich mich auch nicht wirklich damit beschäftigt habe. Alibaba Cloud prüft die Qualität des Mailempfangs, vermutlich spielt dabei die Anzahl der Bounces eine entscheidende Rolle, und berechnet daraus das Credit Level. Da ich jedoch ausschließlich Mails an die eigene Mailadresse zustellen möchte, die hoffentlich immer funktioniert, habe ich den Punkt erstmal beiseite gelassen.
Zur Nutzung von DirectMail muss zunächst eine Domain eingerichtet werden. Das klingt soweit logisch, denn schließlich möchte man Mails nicht von einer Alibaba-eigenen Domain verschicken, sondern für den Empfänger den Eindruck erwecken, dass die Mails von dem eigenen Mailserver bzw. der eigenen Domain verschickt wird. Wobei dies auch für den konkreten Einsatz für das Feedback-Formular irrelevant wäre, aber um DirectMail zu nutzen, muss zwingend eine Domain eingerichtet werden.
Natürlich wollte ich keine neue Domain dafür registrieren, sondern meine Domain geschke.net nutzen. Der Haken: Der Mailserver, der sich für geschke.net zuständig zeigt, soll weiterhin so funktionieren wie zuvor, er soll auch nicht ersetzt oder abgelöst werden, sondern auch zukünftig meine Mails entgegen nehmen und versenden. Aus diesem Grund empfiehlt Alibaba Cloud, dass man unbedingt eine Subdomain nutzen möge, damit der ursprüngliche Mailserver weiterhin seine Aufgaben erfüllen kann. In der ersten Begeisterung des Ausprobierens habe ich noch versucht, meinen Domainnamen ohne Subdomain anzugeben, was jedoch tatsächlich keine gute Idee war. Denn in einem nächsten Schritt müssen DNS-Daten geändert werden, unter anderem auch zur Verifizierung, und spätestens damit hätte ich meinen normalen Mailserver außer Betrieb gesetzt, indem keine Mail mehr dort angekommen wäre.
Demzufolge habe ich letztlich die Subdomain „mailer.geschke.net“ verwendet und DirectMail dementsprechend konfiguriert. Somit kann DirectMail völlig unabhängig vom Standard-Mailserver der jeweiligen Domain agieren.
Die Mail- bzw. Subdomain muss zunächst verifiziert werden, bevor sie genutzt werden kann. Dazu sind einige Angaben in der DNS-Konfiguration der Domain zu tätigen, die unter „Configure“ zu finden sind.
Diese Angaben müssen in die DNS-Server-Konfiguration eingetragen werden, anschließend werden die Änderungen Alibaba Cloud gegenüber bestätigt. Danach prüft DirectMail, ob die gewünschten Einträge im DNS zu finden sind. Bei Erfolg wird die Verifizierung als abgeschlossen bestätigt.
Der nächste Screenshot zeigt einen Ausschnitt aus der DNS-Konfiguration mit BIND 9. Natürlich sind die DNS-Daten öffentlich, dementsprechend soll hiermit auch nur kenntlich gemacht werden, dass lediglich ein paar zusätzliche Einträge hinzu gefügt werden müssen, während der Rest unberührt bleibt. Ebenfalls zu erkennen ist der Eintrag für die Subdomain, die bei der Konfiguration der Website für das Hosting im Object Storage Service (OSS) eingetragen wurde (siehe Teil 5).
Nachdem die DNS-Konfiguration korrekt durchgeführt wurde, ändert sich der Status der eingerichteten Domain.
Um Mails zu verschicken, muss eine Absender-Adresse angelegt werden. Diese Adresse ist letztlich sichtbar in Mail-Programm des Empfängers. Es sollte unbedingt eine Reply-To-Adresse eingerichtet werden. Denn DirectMail ist ausschließlich zum Versenden von Mails gedacht und besitzt keinerlei Möglichkeit, eine Mail in Empfang zu nehmen, auch nicht in Form einer Weiterleitung. Das könnte ggf. ein Nachteil sein – je nach Anwendung. Für einen Newsletter, der von der klassischen „noreply@…“-Adresse gesendet wird, wäre es kein Problem – vorausgesetzt, dass die Mails, die an diese Adresse gesendet werden, auch wirklich im Nirvana verschwinden sollen. Durch das Setzen der Reply-To-Adresse hingegen wird dem Mailprogramm mitgeteilt, doch diese Adresse für eine Antwort zu nutzen. Nutzt man bei Alibaba Clout die DirectMail-API oder den Versand per Admin-UI wird laut Dokumentation die hier eingerichtet Reply-To-Adresse verwendet, bei Verwendung von SMTP hingegen muss man die Reply-To-Adresse explizit setzen. Um die Reply-To-Adresse zu verifizieren, wird eine Mail versendet, in der sich ein Bestätigungs-Link befindet.
An dieser Stelle muss ich auch ein wenig Kritik üben, denn das Verhalten von DirectMail erscheint mir suboptimal. Wenn schon ein Mailserver im DNS konfiguriert wird – schließlich wird ein MX-Eintrag gesetzt, sollte dieser auch in der Lage sein, Mails in Empfang zu nehmen. In diesem Fall würde es sich um die jeweils konfigurierte Sender-Adresse handeln. Wollte man Mails an jene Adresse senden, sollte die Möglichkeit bestehen, eine Weiterleitung einzurichten, so dass empfangene Mails wenigstens an eine andere Mailadresse – gerne nach Verifizierung und nur innerhalb der Haupt-Domain – zugestellt werden. Dass DirectMail keine Eingangspostfächer anbietet, ist völlig in Ordnung, dafür gibt es wiederum andere Dienste. Aber falls ein Nutzer doch einmal versehentlich, oder weil sein Mailprogramm die Reply-To-Adresse nicht verwendet, eine Mail an die Absender-Adresse schickt, sollte diese wenigstens irgendwo ankommen. Das ist jedoch tatsächlich nicht der Fall – einerseits wird dieses Verhalten genau so dokumentiert, andererseits habe ich es kurz getestet – und die Mail blieb verschwunden. Darüber sollte man sich im Klaren sein, wenn DirectMail genutzt wird. Für meine Anwendung, d.h. den Empfang der Angaben aus dem Feedback-Formular an meine eigene Mailadresse, ist DirectMail jedoch gut einsetzbar.
Nach Einrichtung der Sender-Adresse wird der aktuelle Status wiederum in der Übersicht angezeigt.
Möchte man SMTP nutzen, sollte man zur Authentifizierung ein Passwort setzen, da DirectMail SMTP-Auth nutzt.
Sind alle Konfigurationsschritte erfolgreich durchlaufen, ist die Verwendung innerhalb des PHP-Codes von Function Compute identisch zur Nutzung anderer Mailserver.
Daher ist der folgende Code mehr oder minder eine Kopie aus dem Beispiel von PHPMailer.
$fromMail = 'info@mailer.geschke.net'; // important!
$replyToMail = 'info@geschke.net';
$fromName = 'geschke.net Feedback';
$subject = 'Feedback geschke.net';
$toMail = 'ralf@geschke.net';
$toName = 'Ralf Geschke';
$replyToName = 'Feedback geschke.net';
$smtpHost = 'smtpdm-ap-southeast-1.aliyun.com';
$mail = new PHPMailer(true);
try {
//Server settings
$mail->isSMTP(); // Set mailer to use SMTP
$mail->Host = $smtpHost; // Specify main and backup SMTP servers
$mail->SMTPAuth = true; // Enable SMTP authentication
$mail->Username = 'info@mailer.geschke.net'; // SMTP username
$mail->Password = 'PASSWORT'; // SMTP password
$mail->Port = 80;
$mail->SMTPSecure = false;
$mail->SMTPAutoTLS = false;
//Recipients
$mail->setFrom($fromMail, $fromName);
$mail->addAddress($toMail, $toName); // Add a recipient
$mail->addReplyTo($replyToMail, $replyToName);
//Content
$mail->isHTML(false); // Set email format to HTML
$mail->Subject = $subject;
$mail->Body = $text;
$mail->send();
echo 'Message has been sent';
} catch (Exception $e) {
echo 'Message could not be sent. Mailer Error: ' . $mail->ErrorInfo;
}
Einzig der Port 80 könnte verwirren – Alibaba Cloud schreibt in ihrer Dokumentation, dass sie den Port 25 momentan gesperrt hätten und dass man statt dessen den Port 80 nutzen soll, falls man auf SSL verzichtet. Zur Reply-To-Adresse hatte ich mich bereits geäußert – in meiner Anwendung wäre sie zwar optional, da ich aus den Eingaben der Formularfelder den Inhalt der Mail generiere, in dem der Name und die Mailadresse zu finden sind, aber dennoch halte ich es für sinnvoll, die Reply-To-Adresse bei DirectMail konsequent zu nutzen. Der obige Code ist nur ein Beispiel zur Verdeutlichung und nicht zu 100% identisch mit den sehr ähnlichen Zeilen in der Produktionsumgebung.
Fazit, Ausblick und eine kleine Bewertung
Das war der vorerst letzte Teil meiner kleinen Artikelserie zur Alibaba Cloud. Natürlich gäbe es noch viel mehr zu entdecken – ich hatte mir ja nur eine Anwendung heraus gepickt, noch dazu eine der einfachsten, um die Alibaba Cloud-Dienste ein wenig kennenzulernen. Im Zuge dessen habe ich mir zunächst den Object Storage Service (OSS), dann die Function Compute Dienste (FC) und schließlich noch kurz DirectMail (DM) angeschaut. Natürlich habe ich auch einen Blick in die Abrechnung geworfen, aber da gab es außer vielen Nullen nichts zu sehen, insofern gab es auch nichts, worüber man hätte schreiben können. Davon abgesehen gibt es auch Dutzende weiterer Dienste, die allesamt eine nähere Betrachtung wert wären, aber momentan eher nicht in meinem Fokus liegen. Möglicherweise werde ich später noch einmal darauf zurück kommen und auch ggf. hier vorstellen.
Bewertung
Insgesamt ist mein Eindruck von Alibaba Cloud positiv, und zwar aus folgenden Gründen.
Der Einstieg ist mir relativ leicht gefallen. Dazu beigetragen hat einerseits die gute Dokumentation, die zwar an mancher Stelle – ich denke da an den Technologie-Stack von PHP im Rahmen von Function Compute – noch etwas weiter hätte gehen können, aber alles in allem ist die Dokumentation ausführlich, konsistent und gut verständlich. Da verzichte ich auch gerne auf entweder halbherzige und teils veraltete oder gar maschinelle Übersetzungen ins Deutsche, die dann nicht den aktuellen Stand widerspiegeln oder bei der man allenthalben gewillt ist, doch lieber das Original zu nutzen. Ohne nun auf alle weiteren Cloud-Dienste einzugehen – die Strukturierung der Dokumentation von Alibaba Cloud empfinde ich als praktischer als etwa bei Amazon AWS. Nehmen wir z.B. OSS vs. AWS S3 als Beispiel. In der OSS-Dokumentation finde ich alles an einer Stelle – Einführung, Developer Guide, API-Referenz, Quick Start, Tools, Best Practices usw.. Insgesamt nicht gerade wenig, aber unter einer Navigation sind alle Abschnitte, die es übrigens auch als PDF-Fassung gibt, schnell erreichbar. Im Vergleich dazu teilt sich die AWS S3-Dokumentation in unterschiedliche „Handbücher“ auf, von „Erste Schritte“ über das „Entwicklerhandbuch“ bis zur API-Referenz und Console User Guide. Befinde ich mich aber in einem der „Handbücher“, komme ich nur noch per Breadcrumb-Navigation auf die Übersichtsseite zurück, was den Eindruck erweckt, es nicht mit einer Dokumentations-Subsite zu tun zu haben, sondern mit vier – einer Site pro „Handbuch“. Noch verwirrender empfinde ich die Dokumentation bei Microsoft Azure – etwa bei Azure Storage. Hier habe ich nicht den Eindruck einer konsistenten Dokumentation, sondern von vielen, verlinkten Artikeln, die zu jedem Thema zwar einige Informationen verraten, aber irgendwie auch jeweils einzeln für sich stehen können.
Neben der Dokumentation habe ich auch die Admin-UI als angenehm empfunden. Einzig die Geschwindigkeit war an mancher Stelle verbesserungswürdig, insbesondere in den Abendstunden ist mir eine längere Antwortzeit aufgefallen. Ansonsten ist die Benutzung meines Erachtens wiederum konsistent und übersichtlich, somit fiel mir der Einstieg nicht schwer. In diesem Aspekt ähnelt Alibaba Cloud meines Erachtens auch Amazon AWS, auch in Bezug auf die Bezeichnungen der jeweiligen Dienste – statt EC2 (Elastic Compute Cloud) bei AWS nutzt man ECS (Elastic Compute Service) in der Alibaba Cloud. Ich gehe auch davon aus, dass Alibaba Cloud diese Ähnlichkeit zum Marktführer AWS bewusst anstrebt, wobei ich gar nicht auf den kulturellen Aspekt des Kopierens eingehen will, der in China eine lange Tradition hat, denn insgesamt wirkt Alibaba Cloud durchaus eigenständig, in manchen Aspekten bieten die Dienste wiederum Vorteile und Verbesserungen gegenüber AWS. Zwar bin ich hier ein wenig parteiisch, aber die Unterstützung von PHP im Function Compute Service hat mir sehr gefallen, vor allem da dies bis dato kein anderer Cloud-Dienstleister bietet, d.h. weder Amazon AWS, noch Microsoft Azure (bzw. nur in seltsamer Art und Weise, siehe im letzten Artikel), und ebenso wenig die Google Cloud Platform. Zwar ist dies nur ein kleines Detail, aber doch ein Alleinstellungsmerkmal von Alibaba Cloud, noch dazu handelt es sich um eine Eigenentwicklung, insofern kann von einer Kopie hier nicht die Rede sein.
Ebenfalls subjektiv mag der Eindruck sein, dass ich mich in der Alibaba Cloud – sagen wir mal – wohl gefühlt habe. Dazu ein kleines Beispiel, und zwar bezogen auf OSS. Objektspeicher. Die Bezeichnung klingt soweit logisch, die Verwendung wird klar und deutlich beschrieben. Dasselbe gilt für AWS mit S3, der Simple Storage Service. Hier weiß ich ebenfalls, welche Aufgaben sich damit erledigen lassen, erkenne den Sinn und Zweck auf den ersten Blick. Die Einrichtung ist auch in sich logisch und konsistent – Wahl der Location (bei OSS), Vergabe eines Namens, Zuweisen von Rechten – fertig. Nun heißt ein Dienst, der irgend etwas mit Speicherung von Dateien abseits von Datenbanken zu tun habe, bei Microsoft Azure einfach Azure Storage. Soweit ok, nur dann fängt die Verwirrung an. Laut Dokumentation handelt es sich um „hoch verfügbaren, sicheren, stabilen, skalierbaren und redundanten Cloud-Speicher“. Auch bis dahin kann ich folgen. Nur werden anschließend Azure-Blobs, Azure Data Lage Storage Gen2, Azure Dateien, Azure-Warteschlangen und Azure-Tabellen genannt. Jetzt müsste ich schon ein wenig überlegen – vermutlich würde ich Azure-Blobs benötigen. Gehen wir in die Admin-UI, um Azure Storage zu nutzen. Dort finden sich dann „Speicherkonten“, „Speicherkonten (klassisch)“, „StorSimple-Geräte-Manager“, „Data Lake Storage Gen1“, „Speicher-Explorer“, „StorSimple Data Manger“ und noch drei andere Dienste, die irgendwie mit Storage zusammenhängen, aber sich mir auf den ersten Blick überhaupt nicht erschließen. Dazu kommt, dass bei jedem Storage-Typ ein „Speicherkonto“ anlegen muss. Sicherlich ist irgendwo zu lesen, was ein „Speicherkonto“ ist, doch der Ausdruck hinterlässt bei mir erstmal jede Menge Fragezeichen. Eigentlich möchte ich nur Objektspeicher, der nach Nutzung abgerechnet wird, also was ist ein Speicherkonto, was kann ich damit anfangen? Und in der extrem langen Übersicht finde ich das Stichwort „Azure-Blobs“ beispielsweise überhaupt nicht, denn anscheinend gibt es keinen Dienst mit diesem Namen, da sich die Nutzung irgendwo hinter anderen Bezeichnungen versteckt. Das alles mag in der Vergangenheit von Azure liegen, oder auch in der zugrunde liegenden Technologie, aber insgesamt habe ich den Eindruck, dass Azure eine andere Sprache spricht (obwohl die Admin-UI auf Deutsch verfügbar ist), während sich AWS oder auch Alibaba Cloud in „meiner Welt“ befinden, die eine längere Vergangenheit mit Unix/Linux mit sich bringt.
Von den Kosten her ist Alibaba Cloud sicherlich konkurrenzfähig, wobei ich die Preise der einzelnen Dienste jetzt nicht im Detail verglichen habe. Meinem – wiederum sehr subjektiven – Eindruck zufolge behauptet jeder Cloud-Dienstleister, unglaublich günstig zu sein und die Konkurrenz zu unterbieten, was jedoch eher ein Aspekt kreativer Berechnungsmethoden zu sein scheint. Dazu kommt, dass die Gesamtkosten sich teilweise aus unterschiedlichen Aspekten zusammen setzen, etwa Abrechnung nach Traffic, Abrechnung nach Speicherkapazität, Abrechnung nach CPU-Einheiten usw., was wiederum die Vergleichbarkeit erschwert.
Letztlich kann ich jedem empfehlen, für den die Nutzung von Public-Cloud-Diensten in Frage kommt, sich die Alibaba Cloud einmal näher anzusehen. Falls man nicht zwingend Microsoft-spezifische Dienste benötigt, ist Alibaba Cloud sicherlich eine Alternative zum Platzhirsch Amazon AWS, aber auch zu Google Cloud Platform. Und für den Fall, dass auf rechtlicher Seite Bedenken bestehen oder man auf einen Vertragspartner in Deutschland besteht, könnte die Alibaba Cloud hosted by Vodafone eine Lösung sein. Vodafone als Cloud-Partner von Alibaba Cloud agiert hier nicht nur als Betreiber des Rechenzentrums, sondern auch als Vertrags- und Ansprechpartner in Deutschland.
Mir hat die Beschäftigung mit der Alibaba Cloud jedenfalls Spaß gemacht. Zwar werde ich nicht unter allen Umständen auf Cloud-Dienstleister zurück greifen, aber es schadet nicht, deren Leistungen einmal näher kennenzulernen. Vielleicht schaue ich mir bald mal die Public Cloud von Yandex an, leider wird deren UI bislang ausschließlich in russischer Sprache angeboten…
