Wenn Sie App Engine auf der Google Cloud Platform (GCP) verwenden, sollten Sie nicht allzu überrascht sein, wenn Sie eine E-Mail erhalten, in der Ihnen mitgeteilt wird, dass die aktuelle Version, die Sie verwenden, veraltet ist. Wahrscheinlich haben Sie Googles Verwerfungsrichtlinie nicht gelesen, die auch für App Engine gilt ( hier aufgelistet). Darin heißt es im Grunde, dass Google, wenn es beschließt, seine Dienste zu aktualisieren und ältere Versionen zu verwerfen, dies tun kann. Und wird es auch. Und Sie werden gezwungen sein, mitzuziehen. Die E-Mail, die am 27. Juni 2019 kam, sollte Sie also nicht überraschen:
Hallo Google App Engine Kunde, wir möchten Sie darüber informieren, dass Go-Versionen vor 1.11 nicht mehr von App Engine unterstützt werden. Neue Implementierungen mit diesen Sprachversionen (1.6, 1.8 und 1.9) sind ab dem 1. Oktober 2019 nicht mehr möglich.
Damit blieben etwa 3 Monate für das Upgrade.
Wie viel Aufwand?
Was bedeutet dieses Upgrade genau? Werden dabei nur einige Konfigurationsdateien geändert? Nun, ja und nein. Die Migrationsanleitung erklärt, was Sie tun müssen. Er enthält einige erforderliche und einige empfohlene Änderungen.
Erforderliche Änderungen
Für das Upgrade auf die go1.11-Laufzeitumgebung sind mehrere Änderungen erforderlich, wobei die App Engine-spezifischen APIs weiterhin verwendet werden.
App.yaml
In Ihrer app.yaml (oder service.yaml) sollte die "runtime" auf go111 gesetzt und die "api_version" entfernt werden. Unter der url-Eigenschaft sollte "application_readable: true" entfernt werden, dies gilt jetzt standardmäßig. Außerdem sollte die Eigenschaft "script: _go_app" durch "script: auto" ersetzt werden. Der Tag "includes" ist veraltet, kann aber glücklicherweise noch verwendet werden. Der url-Handler "login:admin" kann weiterhin verwendet werden, ist aber ebenfalls veraltet und wird mit der go1.12-Laufzeit nicht mehr unterstützt. Möglicherweise müssen Sie noch einige Dinge ändern, aber Sie erhalten eindeutige Fehlermeldungen, wenn Sie Ihre Anwendung mit "gcloud app deploy [...]" bereitstellen.
Einstiegspunkt der Anwendung
Sie müssen den Einstiegspunkt Ihrer Anwendung ändern. Das Paket muss "main" heißen und die Einstiegsfunktion muss ebenfalls "main()" heißen. Der Dateiname spielt dabei keine Rolle. Am Ende dieser main()-Funktion müssen Sie "appengine.Main()" hinzufügen, wenn Sie weiterhin App Engine spezifische APIs verwenden möchten. Wenn Sie das nicht tun, sollten Sie die Umgebungsvariable PORT auslesen und sie für den Aufruf der http listen und serve Methode verwenden, da Ihre Anwendung sonst nach dem Start nicht weiterläuft.
App Engine Build-Tag
In der alten Laufzeitumgebung konnte man zwei Dateien mit identischen Funktionsnamen haben, eine mit "//build appengine" am Anfang und eine andere mit "//build !appengine". Während des Build-Prozesses würde eine der Dateien in der App-Engine-Umgebung gebaut werden, die andere z.B. während der Ausführung von Unit-Tests. Diese Funktion ist veraltet, d.h. die Datei mit dem App Engine build-Tag wird komplett ignoriert. Es gibt natürlich mehrere Lösungen. Unser Ansatz war, zwischen einer App Engine und einer Mock-Funktion auf der Grundlage der Funktion "appengine.IsAppengine()" umzuschalten. Oder vielleicht noch besser, die Prüfung durchzuführen os.Getenv("GAE_ENV") == "standard"
Empfohlene Änderungen
Sobald Sie Ihre Anwendung erfolgreich bereitgestellt haben, werden Sie feststellen, dass Ihre Protokolle nicht mehr so schön sind wie früher. Die automatische Gruppierung der Ausdrucke pro Anfrage ist nicht mehr Teil der Standardprotokollierung und erfordert etwas Arbeit, um sie zu perfektionieren. Mehr dazu in einem späteren Beitrag.
Bindung an den Lieferanten
An diesem Punkt könnten Sie denken: "Moment mal, ich habe so viel Zeit damit verbracht, meine Go-Anwendung in App Engine zum Laufen zu bringen, indem ich ihre APIs verwendet habe, und jetzt zwingt man mich plötzlich, auf eine neuere Version zu migrieren und einige dieser APIs zu entfernen". Sie könnten dies als eine schlechte Folge der Anbieterbindung sehen. Sie sind an einen bestimmten Anbieter gebunden und im Grunde dessen Launen ausgeliefert. Es gibt jedoch einen Grund für diese Verrücktheit. Um dies besser zu verstehen, müssen wir zur Entstehungsgeschichte von App Engine zurückgehen. App Engine wurde 2008 von Google auf den Markt gebracht und war zusammen mit dem Datastore das erste Google Cloud-Produkt. Zu dieser Zeit war AWS von Amazon bereits seit einigen Jahren aktiv. Amazon bot zunächst eine Möglichkeit, ohne große Anpassungen von On-Premise in die Cloud zu wechseln, indem es Dateispeicher und virtuelle Maschinen bereitstellte. Google verfolgte mit App Engine jedoch einen anderen Ansatz. Sie sagten im Grunde: "Laden Sie Ihren Code hoch und wir führen ihn aus". Der Einfachheit halber wurden der App Engine spezielle APIs hinzugefügt, von denen einige jetzt veraltet sind. Die Veraltung dieser App Engine-spezifischen APIs zugunsten allgemeinerer Cloud-APIs ist wohl tatsächlich eine gute Sache. Zum einen erhalten Sie eine idiomatischere Go-Anwendung, die ein Hauptpaket und eine Funktion zum Starten verwendet. Da Sie weniger von den spezifischen App Engine-APIs abhängig sind, haben Sie außerdem die Freiheit, Ihre Go-Anwendung außerhalb der Google Cloud zu hosten und auszuführen, wodurch die Bindung an einen bestimmten Anbieter aufgehoben wird.
Fazit
Auf den ersten Blick mag diese Migration wie eine gewaltige Aufgabe aussehen, aber im Großen und Ganzen ist sie durchaus machbar. Sie kommen zwar nicht um diese Migration herum, wenn Sie weiterhin neue Versionen Ihrer Anwendung bereitstellen wollen, aber sie bringt einige nette zusätzliche Vorteile mit sich, wie z.B. die Möglichkeit, Go-Module zu verwenden. Dieser Blog ist der Beginn einer Reihe von Blogs, in denen wir die empfohlenen Änderungen besprechen, um sicherzustellen, dass Sie für Go 1.12 bereit sind. Geschrieben von Laurence de Jong und Benjamin Komen
Verfasst von
Benjamin Komen
Unsere Ideen
Weitere Blogs
Contact