App Mod-Workshop

1. Einführung

Zuletzt aktualisiert: 01.11.2024

Wie modernisieren wir eine alte PHP-Anwendung für Google Cloud?

(📽️ 7-minütiges Einführungsvideo zu diesem Codelab ansehen)

Häufig werden lokale Legacy-Anwendungen ausgeführt, die modernisiert werden müssen. Das bedeutet, dass sie skalierbar, sicher und in verschiedenen Umgebungen bereitstellbar sein müssen.

In diesem Workshop:

Containerisieren Sie die PHP-Anwendung.
Wechseln Sie zu einem verwalteten Datenbankdienst ( Cloud SQL).
In Cloud Run bereitstellen (die Zero-Ops-Alternative zu GKE/Kubernetes).
Sichern Sie die Anwendung mit Identity and Access Management (IAM) und Secret Manager.
Definieren Sie eine CI/CD-Pipeline über Cloud Build. Cloud Build kann mit Ihrem Git-Repository verbunden werden, das bei beliebten Git-Anbietern wie GitHub oder GitLab gehostet wird. Der Build kann beispielsweise bei jedem Push in den Hauptzweig ausgelöst werden.
Hosten Sie die Anwendungsbilder in Cloud Storage. Dies wird durch das Einbinden erreicht. Es ist kein Code erforderlich, um die App zu ändern.
Gen AI-Funktionen über Gemini einführen, orchestriert über Cloud Functions (serverlos).
Machen Sie sich mit SLOs und dem Betrieb Ihrer neu aktualisierten App vertraut.

Wenn Sie diese Schritte ausführen, können Sie Ihre PHP-Anwendung schrittweise modernisieren und ihre Skalierbarkeit, Sicherheit und Flexibilität bei der Bereitstellung verbessern. Außerdem können Sie durch die Migration zu Google Cloud die leistungsstarke Infrastruktur und die Dienste nutzen, um sicherzustellen, dass Ihre Anwendung in einer cloudnativen Umgebung reibungslos ausgeführt wird.

Wir sind der Meinung, dass Sie das, was Sie mit diesen einfachen Schritten lernen, auf Ihre eigene Anwendung und Organisation mit einer anderen Sprache/einem anderen Stack und anderen Anwendungsfällen anwenden können.

Über die App

Die Anwendung ( Code, unter MIT-Lizenz), die Sie forken, ist eine einfache PHP 5.7-Anwendung mit MySQL-Authentifizierung. Die App soll eine Plattform bieten, auf der Nutzer Fotos hochladen können und Administratoren die Möglichkeit haben, unangemessene Bilder zu taggen. Die Anwendung hat zwei Tabellen:

Nutzer Wird mit Administratoren vorkompiliert. Neue Nutzer können sich registrieren.
Bilder Enthält einige Beispielbilder. Angemeldete Nutzer können neue Bilder hochladen. Wir werden hier etwas Magie hinzufügen.

Dein Ziel

Wir möchten die alte Anwendung modernisieren, damit sie in Google Cloud verfügbar ist. Wir werden die Tools und Dienste von Google Cloud nutzen, um die Skalierbarkeit zu verbessern, die Sicherheit zu erhöhen, die Infrastrukturverwaltung zu automatisieren und erweiterte Funktionen wie Bildverarbeitung, Monitoring und Datenspeicherung mithilfe von Diensten wie Cloud SQL, Cloud Run, Cloud Build und Secret Manager zu integrieren.

Vor allem möchten wir das schrittweise tun, damit Sie nachvollziehen können, was hinter jedem Schritt steckt. In der Regel eröffnet jeder Schritt neue Möglichkeiten für die nächsten (z. B. Modul 2 –> 3 und 6 –> 7).

Noch nicht überzeugt? Dieses 7‑minütige Video auf YouTube kann dir dabei helfen.

Voraussetzungen

Einen Computer mit einem Browser, der mit dem Internet verbunden ist.
Einige GCP-Guthaben. Nächster Schritt
Sie verwenden Cloud Shell. Sie enthält alle vorinstallierten Befehle, die Sie benötigen, und eine IDE.
GitHub-Konto Sie benötigen dies, um den ursprünglichen Code 🧑🏻‍💻 gdgpescara/app-mod-workshop in Ihrem eigenen Git-Repository zu verzweigen. Dies ist erforderlich, um eine eigene CI/CD-Pipeline (automatisches Commit -> Build -> Bereitstellung) zu haben.

Beispiellösungen finden Sie hier:

Das Autoren-Repository: https://github.com/Friends-of-Ricc/app-mod-workshop
Das ursprüngliche Workshop-Repository in den .solutions/-Ordnern nach Kapitel.

Dieser Workshop ist für die Ausführung in Cloud Shell (in einem Browser) konzipiert.

Sie können es aber auch von Ihrem lokalen Computer aus versuchen.

2. Guthaben einrichten und Fork

GCP-Guthaben einlösen und GCP-Umgebung einrichten [optional]

Für diesen Workshop benötigen Sie ein Rechnungskonto mit Guthaben. Wenn Sie bereits ein eigenes Abrechnungssystem haben, können Sie diesen Schritt überspringen.

Erstellen Sie ein neues Google Gmail-Konto (*), das Sie mit Ihrem GCP-Guthaben verknüpfen. Bitten Sie Ihren Kursleiter um den Link zum Einlösen des GCP-Guthabens oder verwenden Sie das Guthaben hier: bit.ly/PHP-Amarcord-credits .

Melden Sie sich mit dem neu erstellten Konto an und folgen Sie der Anleitung.

(

) Warum benötige ich ein brandneues Gmail-Konto?*

Wir haben festgestellt, dass Nutzer das Codelab nicht bestanden haben, weil ihr Konto (insbesondere Arbeits- oder Schüler-E-Mail-Adressen) bereits mit GCP in Berührung gekommen war und Organisationsrichtlinien ihre Möglichkeiten einschränkten. Wir empfehlen, entweder ein neues Gmail-Konto zu erstellen oder ein vorhandenes Gmail-Konto (gmail.com) zu verwenden, das noch nicht mit GCP in Berührung gekommen ist.

Klicken Sie auf die Schaltfläche, um das Guthaben einzulösen.

Füllen Sie das folgende Formular mit Ihrem Vor- und Nachnamen aus und stimmen Sie den Nutzungsbedingungen zu.

Es kann einige Sekunden dauern, bis das Rechnungskonto hier angezeigt wird: https://console.cloud.google.com/billing.

Öffnen Sie dann die Google Cloud Console und erstellen Sie ein neues Projekt. Klicken Sie dazu oben links auf die Projektauswahl, wo „Keine Organisation“ angezeigt wird. Siehe unten.

Erstellen Sie ein neues Projekt, falls Sie noch keines haben. Oben rechts befindet sich die Option „NEUES PROJEKT“.

Verknüpfen Sie das neue Projekt so mit dem GCP-Testabrechnungskonto:

Sie können die Google Cloud Platform jetzt verwenden. Wenn Sie ein Anfänger sind oder alles in einer Cloud-Umgebung erledigen möchten, können Sie über die folgende Schaltfläche oben links auf Cloud Shell und den zugehörigen Editor zugreifen.

Prüfen Sie, ob Ihr neues Projekt oben links ausgewählt ist:

Nicht ausgewählt (schlecht):

Ausgewählt (gut):

App von GitHub forken

Rufen Sie die Demo-App unter https://github.com/gdgpescara/app-mod-workshop auf.
Klicken Sie auf 🍴 Fork.
Wenn Sie kein GitHub-Konto haben, müssen Sie ein neues erstellen.
Bearbeiten Sie die Dinge nach Belieben.

App-Code klonen mit
git clone https://github.com/YOUR-GITHUB-USER/YOUR-REPO-NAME

Öffnen Sie den geklonten Projektordner mit Ihrem bevorzugten Editor. Wenn Sie Cloud Shell auswählen, können Sie auf Editor öffnen klicken, wie unten dargestellt.

Mit dem Google Cloud Shell-Editor haben Sie alles, was Sie brauchen, wie die folgende Abbildung zeigt.

Klicken Sie dazu auf „Ordner öffnen“ und wählen Sie den Ordner aus, wahrscheinlich app-mod-workshop in Ihrem Basisordner.

3. Modul 1: SQL-Instanz erstellen

Google Cloud SQL-Instanz erstellen

Unsere PHP-App stellt eine Verbindung zu einer MySQL-Datenbank her. Daher müssen wir sie für eine reibungslose Migration in Google Cloud replizieren. Cloud SQL ist die perfekte Lösung, da Sie damit eine vollständig verwaltete MySQL-Datenbank in der Cloud ausführen können. So gehts:

Rufen Sie die Cloud SQL-Seite auf: https://console.cloud.google.com/sql/instances
Klicken Sie auf „Create Instance“ (Instanz erstellen).
API aktivieren (falls erforderlich). Dies kann einige Sekunden dauern.
Wählen Sie MySQL aus.
(Wir versuchen, dir die günstigste Version zu besorgen, damit sie länger hält):

Version: Enterprise
Voreinstellung: Entwicklung (wir haben die Sandbox ausprobiert, aber sie hat für uns nicht funktioniert)
Mysql Ver: 5.7 (wow, a blast from the past!)

Instanz-ID: Wählen Sie appmod-phpapp aus. Wenn Sie diese ändern, müssen Sie auch zukünftige Skripts und Lösungen entsprechend ändern.
Passwort: beliebig, aber notieren Sie es sich als CLOUDSQL_INSTANCE_PASSWORD.
Region: Behalten Sie die Region bei, die Sie für den Rest der App ausgewählt haben (z. B. Mailand = europe-west8).
Zonale Verfügbarkeit: Einzelne Zone (wir sparen Geld für die Demo)

Klicken Sie auf die Schaltfläche „Instanz erstellen“, um die Cloud SQL-Datenbank bereitzustellen. ⌛Das dauert etwa 10 Minuten.⌛ Lesen Sie in der Zwischenzeit die Dokumentation weiter. Sie können auch mit dem nächsten Modul („PHP-App in einen Container packen“) beginnen, da es im ersten Teil (bis Sie die DB-Verbindung repariert haben) keine Abhängigkeiten von diesem Modul hat.

Hinweis: Diese Instanz sollte Sie etwa 7 $ pro Tag kosten. Bitte sorge dafür, dass das Projekt nach dem Workshop weitergeführt wird.

Datenbank „image_catalog“ und Nutzer in Cloud SQL erstellen

Das App-Projekt enthält einen Ordner db/ mit zwei SQL-Dateien:

01_schema.sql : Enthält SQL-Code zum Erstellen von zwei Tabellen mit Nutzer- und Bilddaten.
02_seed.sql: Enthält SQL-Code zum Einfügen von Daten in die zuvor erstellten Tabellen.

Diese Dateien werden später verwendet, wenn die image_catalog-Datenbank erstellt wird. So gehts:

Öffnen Sie Ihre Instanz und klicken Sie auf den Tab „Datenbanken“:
Klicken Sie auf „Datenbank erstellen“.
Nennen Sie sie image_catalog (wie in der PHP-App-Konfiguration).

Anschließend erstellen wir den Datenbanknutzer. Damit können wir uns in der Datenbank „image_catalog“ authentifizieren.

Klicken Sie nun auf den Tab Nutzer.
Klicken Sie auf „Nutzerkonto hinzufügen“.
Nutzer: Lass uns eins erstellen:

Nutzername: appmod-phpapp-user
Passwort: Wählen Sie ein Passwort aus, das Sie sich merken können, oder klicken Sie auf „Generieren“.
Behalten Sie Beliebigen Host zulassen (%) bei.

Klicken Sie auf „HINZUFÜGEN“.

Öffnen Sie die Datenbank für bekannte IP-Adressen.

Alle Datenbanken in Cloud SQL sind von Anfang an isoliert. Sie müssen explizit ein Netzwerk einrichten, über das auf die Instanz zugegriffen werden kann.

Klicken Sie auf Ihre Instanz.
Öffnen Sie das Menü „Verbindungen“.
Klicken Sie auf den Tab „Netzwerk“.
Klicken Sie unter „Autorisierte Netzwerke“. Fügen Sie nun ein Netzwerk (d. h. ein Subnetz) hinzu.

Wählen Sie vorerst eine schnelle, aber UNSICHERE Einstellung aus, damit die App funktioniert. Sie können sie später auf die IP-Adressen beschränken, denen Sie vertrauen:
Name: „Alle auf der Welt – UNSICHER“
Netzwerk: „0.0.0.0/0"“ (Hinweis: Dies ist der UNSICHERE Teil!)
Klicken Sie auf „Fertig“.

Klicken Sie auf "Speichern".

Auf dem Bildschirm sollte Folgendes zu sehen sein:

Hinweis: Diese Lösung ist ein guter Kompromiss, um den Workshop in O(Stunden) abzuschließen. Sehen Sie sich jedoch das SECURITY-Dokument an, um Ihre Lösung für die Produktion zu schützen.

Zeit, die Datenbankverbindung zu testen

Sehen wir uns an, ob der Nutzer image_catalog, den wir zuvor erstellt haben, funktioniert.

Rufen Sie „Cloud SQL Studio“ in der Instanz auf und geben Sie die Datenbank, den Nutzer und das Passwort für die Authentifizierung ein, wie unten gezeigt:

Sie können jetzt den SQL-Editor öffnen und mit dem nächsten Abschnitt fortfahren.

Datenbank aus dem Code importieren

Importieren Sie die image_catalog-Tabellen mit ihren Daten über den SQL-Editor. Kopieren Sie den SQL-Code aus den Dateien im Repository ( 01_schema.sql und dann 02_seed.sql) und führen Sie sie nacheinander aus.

Danach sollten Sie im image_catalog zwei Tabellen sehen: users und images, wie unten dargestellt:

Sie können es testen, indem Sie Folgendes im Editor ausführen: select * from images;

Notieren Sie sich auch die öffentliche IP-Adresse der Cloud SQL-Instanz, da Sie sie später benötigen. Die IP-Adresse finden Sie auf der Hauptseite der Cloud SQL-Instanz auf der Seite Übersicht. („Übersicht“ > „Mit dieser Instanz verbinden“ > „Öffentliche IP-Adresse“).

4. Modul 2: PHP-Anwendung containerisieren

Wir möchten diese App für die Cloud entwickeln.

Dazu muss der Code in einer ZIP-Datei verpackt werden, die alle Informationen enthält, die für die Ausführung in der Cloud erforderlich sind.

Dafür gibt es mehrere Möglichkeiten:

Docker Sehr beliebt, aber die Einrichtung ist recht komplex.
Buildpacks Weniger beliebt, aber es wird in der Regel automatisch erraten, was erstellt und ausgeführt werden soll. Oft funktioniert es einfach!

Im Rahmen dieses Workshops gehen wir davon aus, dass Sie Docker verwenden.

Wenn Sie sich für die Verwendung der Cloud Shell entschieden haben, ist jetzt der richtige Zeitpunkt, sie wieder zu öffnen (klicken Sie oben rechts in der Cloud Console).

Dadurch sollte unten auf der Seite eine Shell geöffnet werden, in der Sie den Code im Einrichtungsschritt geforkt haben.

Docker

Wenn Sie die Kontrolle behalten möchten, ist das die richtige Lösung für Sie. Das ist sinnvoll, wenn Sie bestimmte Bibliotheken konfigurieren und bestimmte nicht offensichtliche Verhaltensweisen einfügen müssen (z. B. ein chmod bei Uploads oder eine nicht standardmäßige ausführbare Datei in Ihrer App).

Da wir unsere Containeranwendung letztendlich in Cloud Run bereitstellen möchten, sehen Sie sich die folgende Dokumentation an. Wie würden Sie es von PHP 8 zu PHP 5.7 zurückportieren? Vielleicht können Sie Gemini dafür verwenden. Alternativ können Sie diese vorkonfigurierte Version verwenden:

# Use the official PHP image: https://hub.docker.com/_/php
FROM php:5.6-apache

# Configure PHP for Cloud Run.
# Precompile PHP code with opcache.
# Install PHP's extension for MySQL
RUN docker-php-ext-install -j "$(nproc)" opcache mysqli pdo pdo_mysql && docker-php-ext-enable pdo_mysql

RUN set -ex; \
  { \
    echo "; Cloud Run enforces memory & timeouts"; \
    echo "memory_limit = -1"; \
    echo "max_execution_time = 0"; \
    echo "; File upload at Cloud Run network limit"; \
    echo "upload_max_filesize = 32M"; \
    echo "post_max_size = 32M"; \
    echo "; Configure Opcache for Containers"; \
    echo "opcache.enable = On"; \
    echo "opcache.validate_timestamps = Off"; \
    echo "; Configure Opcache Memory (Application-specific)"; \
    echo "opcache.memory_consumption = 32"; \
  } > "$PHP_INI_DIR/conf.d/cloud-run.ini"

# Copy in custom code from the host machine.
WORKDIR /var/www/html

COPY . .

# Setup the PORT environment variable in Apache configuration files: https://cloud.google.com/run/docs/reference/container-contract#port
ENV PORT=8080

# Tell Apache to use 8080 instead of 80.
RUN sed -i 's/80/${PORT}/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf

# Note: This is quite insecure and opens security breaches. See last chapter for hardening ideas.
# Uncomment at your own risk:
#RUN chmod 777 /var/www/html/uploads/

# Configure PHP for development.
# Switch to the production php.ini for production operations.
# RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"
# https://github.com/docker-library/docs/blob/master/php/README.md#configuration
RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"

# Expose the port
EXPOSE 8080

Die aktuelle Version von Dockerfile ist hier verfügbar.

Um unsere Anwendung lokal zu testen, müssen wir die Datei config.php so ändern, dass unsere PHP-App eine Verbindung zur MYSQL-Datenbank in Google Cloud SQL herstellt. Füllen Sie die Lücken entsprechend Ihrer bisherigen Einrichtung aus:

<?php
// Database configuration
$db_host = '____________';
$db_name = '____________';
$db_user = '____________';
$db_pass = '____________';

try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("Errore di connessione: " . $e->getMessage());
}

session_start();
?>

DB_HOST ist die öffentliche IP-Adresse von Cloud SQL. Sie finden sie in der SQL-Konsole:

DB_NAME sollte unverändert bleiben: image_catalog
DB_USER sollte appmod-phpapp-user sein
DB_PASS ist etwas, das Sie ausgewählt haben. Setzen Sie den Wert in einfache Anführungszeichen und verwenden Sie bei Bedarf Escapezeichen.

Übersetze die wenigen 🇮🇹 italienischen Textstellen mit Gemini ins Englische.

Ok, jetzt haben Sie die Dockerfile und Ihre PHP-App ist für die Verbindung mit Ihrer Datenbank konfiguriert. Probieren wir es aus.

Installieren Sie Docker, falls Sie es noch nicht haben ( Link). Wenn Sie Cloud Shell verwenden, ist dies nicht erforderlich.

Erstellen und führen Sie Ihre containerisierte PHP-App jetzt mit den entsprechenden Docker-Build- und ‑Ausführungsbefehlen aus.

# Build command - don't forget the final . This works if Dockerfile is inside the code folder:
$ docker build -t my-php-app-docker .   

# Local Run command: most likely ports will be 8080:8080
$ docker run -it -p <CONTAINER_PORT>:<LOCAL_MACHINE_PORT> my-php-app-docker

Wenn alles funktioniert, sollten Sie die folgende Webseite sehen, wenn Sie mit dem lokalen Host verbunden sind. Ihre App wird jetzt auf Port 8080 ausgeführt. Klicken Sie auf das Symbol für die Webvorschau (ein Browser mit einem Auge) und dann auf Vorschau auf Port 8080 (oder auf „Port ändern“ für einen anderen Port).

Ergebnis im Browser testen

Ihre Anwendung sollte jetzt in etwa so aussehen:

Wenn Sie sich mit Admin/admin123 anmelden, sollten Sie etwa Folgendes sehen.

Super! Abgesehen vom italienischen Text funktioniert es! 🎉🎉🎉

Wenn Ihre Dockerisierung gut ist, die DB-Anmeldedaten jedoch falsch sind, erhalten Sie möglicherweise eine Fehlermeldung wie diese:

Versuchen Sie es noch einmal. Sie sind nah dran.

In Artifact Registry speichern [optional]

Sie sollten jetzt eine funktionierende containerisierte PHP-Anwendung haben, die in der Cloud bereitgestellt werden kann. Als Nächstes benötigen wir einen Ort in der Cloud, an dem wir unser Docker-Image speichern und für die Bereitstellung in Google Cloud-Diensten wie Cloud Run zugänglich machen können. Diese Speicherlösung heißt Artifact Registry. Sie ist ein vollständig verwalteter Google Cloud-Dienst, der für das Speichern von Anwendungsartefakten wie Docker-Container-Images, Maven-Paketen und npm-Modulen entwickelt wurde.

Erstellen wir mit der entsprechenden Schaltfläche ein Repository in Google Cloud Artifact Registry.

Wählen Sie einen gültigen Namen, das Format und die Region aus, die für die Speicherung der Artefakte geeignet sind.

Taggen Sie in Ihrer lokalen Entwicklungsumgebung das App-Container-Image und übertragen Sie es per Push in das gerade erstellte Artifact Registry-Repository. Führen Sie dazu die folgenden Befehle aus.

docker tag SOURCE_IMAGE[:TAG] TARGET_IMAGE[:TAG]
docker push TARGET_IMAGE[:TAG]

Das Ergebnis sollte wie im folgenden Screenshot aussehen.

Hurra! 🎉🎉🎉 Du kannst mit dem nächsten Level fortfahren. Nimm dir vorher vielleicht zwei Minuten Zeit, um das Hochladen, Anmelden und Abmelden auszuprobieren und dich mit den App-Endpunkten vertraut zu machen.Du wirst sie später benötigen.

Mögliche Fehler

Wenn Containerisierungsfehler auftreten, können Sie Gemini verwenden, um den Fehler zu erläutern und zu beheben. Geben Sie dazu Folgendes an:

Ihr aktuelles Dockerfile
Die erhaltene Fehlermeldung
[falls erforderlich] der ausgeführte PHP-Code.

Berechtigungen zum Hochladen Versuchen Sie es auch mit dem Endpunkt /upload.php und laden Sie ein Bild hoch. Möglicherweise wird der folgende Fehler angezeigt. Wenn ja, müssen Sie einige chmod/chown in der Dockerfile beheben.

Warnung: move_uploaded_file(uploads/image (3).png): failed to open stream: Permission denied in /var/www/html/upload.php on line 11

PDOException „could not find driver“ (oder „Errore di connessione: could not find driver“) Achten Sie darauf, dass Ihr Dockerfile die richtigen PDO-Bibliotheken für MySQL (pdo_mysql) enthält, um eine Verbindung zur Datenbank herzustellen. Hier finden Sie Beispiele für Lösungen.

Ihre Anfrage kann nicht an ein Backend weitergeleitet werden. Verbindung zu einem Server auf Port 8080 konnte nicht hergestellt werden. Das bedeutet, dass Sie wahrscheinlich den falschen Port freigeben. Achten Sie darauf, dass Sie den Port freigeben, über den Apache/Nginx tatsächlich bereitgestellt werden. Das ist nicht trivial. Wenn möglich, verwenden Sie Port 8080, da dies die Verwendung von Cloud Run erleichtert. Wenn Sie Port 80 beibehalten möchten (z. B. weil Apache dies erfordert), verwenden Sie einen anderen Befehl zum Ausführen:

$ docker run -it -p 8080:80 # force 80

# Use the PORT environment variable in Apache configuration files.

# https://cloud.google.com/run/docs/reference/container-contract#port

RUN sed -i 's/80/${PORT}/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf

5. Modul 3: App in Cloud Run bereitstellen

Warum Cloud Run?

Gute Frage! Vor einigen Jahren hätten Sie sich sicher für Google App Engine entschieden.

Einfach gesagt: Cloud Run hat heute einen neueren Technologie-Stack, ist einfacher bereitzustellen, günstiger und lässt sich auf 0 skalieren, wenn Sie es nicht verwenden. Dank der Flexibilität, beliebige zustandslose Container auszuführen, und der Integration in verschiedene Google Cloud-Dienste eignet sich Cloud Run ideal für die Bereitstellung von Microservices und modernen Anwendungen mit minimalem Aufwand und maximaler Effizienz.

Cloud Run ist eine vollständig verwaltete Plattform von Google Cloud, mit der Sie zustandslose containerisierte Anwendungen in einer serverlosen Umgebung ausführen können. Die gesamte Infrastruktur wird automatisch verwaltet. Die Skalierung erfolgt von null an, um eingehenden Traffic zu bewältigen, und wird bei Inaktivität wieder heruntergefahren. Das macht den Dienst kostengünstig und effizient. Cloud Run unterstützt jede Sprache oder Bibliothek, solange sie in einem Container verpackt ist. Das ermöglicht eine hohe Flexibilität bei der Entwicklung. Cloud Run lässt sich gut in andere Google Cloud-Dienste einbinden und eignet sich zum Erstellen von Mikrodiensten, APIs, Websites und ereignisgesteuerten Anwendungen, ohne dass Sie die Serverinfrastruktur verwalten müssen.

Voraussetzungen

Für diese Aufgabe muss gcloud auf Ihrem lokalen Computer installiert sein. Falls nicht, folgen Sie dieser Anleitung. Wenn Sie Google Cloud Shell verwenden, müssen Sie nichts unternehmen.

Vor der Bereitstellung

Wenn Sie in Ihrer lokalen Umgebung arbeiten, authentifizieren Sie sich mit dem folgenden Befehl bei Google Cloud:

$ gcloud auth login –update-adc # not needed in Cloud Shell

Dadurch sollten Sie sich über eine OAuth-Anmeldung in Ihrem Browser authentifizieren. Achten Sie darauf, dass Sie sich über Chrome mit demselben Nutzer (z. B. vattelapesca@gmail.com) anmelden, der in Google Cloud mit aktivierter Abrechnung angemeldet ist.

Aktivieren Sie die Cloud Run API mit dem folgenden Befehl:

$ gcloud services enable run.googleapis.com cloudbuild.googleapis.com

Jetzt kann alles in Cloud Run bereitgestellt werden.

App über gcloud in Cloud Run bereitstellen

Mit dem Befehl gcloud run deploy können Sie die App in Cloud Run bereitstellen. Es gibt mehrere Optionen, die Sie festlegen können, um Ihr Ziel zu erreichen. Die Mindestanzahl an Optionen, die Sie über die Befehlszeile angeben können oder für die Sie vom Tool über eine interaktive Eingabeaufforderung aufgefordert werden, sind die folgenden:

Name des Cloud Run-Dienstes, den Sie für Ihre App bereitstellen möchten. Ein Cloud Run-Dienst gibt eine URL zurück, die einen Endpunkt für Ihre App bereitstellt.
Google Cloud-Region, in der Ihre App ausgeführt wird. (--region REGION)
Container-Image, in dem Ihre App enthalten ist.
Umgebungsvariablen, die Ihre App während der Ausführung verwenden muss.
Das Allow-Unauthenticated-Flag, das jedem den Zugriff auf Ihre App ohne weitere Authentifizierung ermöglicht.

In der Dokumentation erfahren Sie, wie Sie diese Option auf Ihre Befehlszeile anwenden. Scrollen Sie nach unten, um eine mögliche Lösung zu finden.

Die Bereitstellung dauert einige Minuten. Wenn alles korrekt ist, sollte in der Google Cloud Console Folgendes angezeigt werden.

Klicken Sie auf die von Cloud Run bereitgestellte URL und testen Sie Ihre Anwendung. Nach der Authentifizierung sollte etwa Folgendes angezeigt werden.

„gcloud run deploy“ ohne Argumente

gcloud run deploy stellt Ihnen die richtigen Fragen und füllt die Lücken, die Sie gelassen haben. Das ist ja fantastisch!

In einigen Modulen fügen wir diesen Befehl jedoch einem Cloud Build-Trigger hinzu, sodass wir uns keine interaktiven Fragen leisten können. Wir müssen jede Option im Befehl ausfüllen. Sie müssen also die goldene gcloud run deploy --option1 blah --foo bar --region your-fav-region erstellen. Wie gehst du es an?

Wiederholen Sie die Schritte 2, 3 und 4, bis gcloud keine Fragen mehr stellt:
[LOOP] gcloud run deploy mit den bisher gefundenen Optionen
[LOOP] systems ask for option X
[LOOP] Suche in öffentlichen Dokumenten nach Informationen zum Einrichten von X über die Befehlszeile und füge die Option --my-option [my-value] hinzu.
Kehren Sie jetzt zu Schritt 2 zurück, sofern gcloud ohne weitere Fragen abgeschlossen wird.
Dieser gcloud run-Befehl zum Bereitstellen von BLAH BLAH BLAH ist einfach genial! Speichern Sie den Befehl, da Sie ihn später für den Cloud Build-Schritt benötigen.

Eine mögliche Lösung finden Sie hier. Die Dokumentation finden Sie hier.

Hooray 🎉🎉🎉 Sie haben Ihre App erfolgreich in Google Cloud bereitgestellt und damit den ersten Schritt der Modernisierung abgeschlossen.

6. Modul 4: Passwort mit Secret Manager bereinigen

Im vorherigen Schritt konnten wir unsere App erfolgreich in Cloud Run bereitstellen und ausführen. Wir haben dies jedoch mit einer Sicherheits-Best-Practice umgesetzt: Einige Secrets werden im Klartext angegeben.

Erste Iteration: config.php für die Verwendung von ENV aktualisieren

Sie haben vielleicht bemerkt, dass wir das Datenbankpasswort direkt in den Code in der Datei „config.php“ eingefügt haben. Das ist für Testzwecke und um zu sehen, ob die App funktioniert, in Ordnung. Sie können den Code jedoch nicht in einer Produktionsumgebung committen oder verwenden. Das Passwort (und andere Parameter für die Datenbankverbindung) sollten dynamisch gelesen und der App zur Laufzeit bereitgestellt werden. Ändern Sie die Datei config.php so, dass die Datenbankparameter aus Umgebungsvariablen gelesen werden. Wenn das nicht funktioniert, sollten Sie Standardwerte festlegen. Das ist hilfreich, falls das Laden der Umgebungsvariablen fehlschlägt. In der Seitenausgabe sehen Sie dann, ob die Standardwerte verwendet werden. Füllen Sie die Lücken aus und ersetzen Sie den Code in der Datei „config.php“.

<?php
// Database configuration with ENV variables. Set default values as well 
$db_host = getenv('DB_HOST') ?: 'localhost';
$db_name = getenv('DB_NAME') ?: 'image_catalog';
$db_user = getenv('DB_USER') ?: 'appmod-phpapp-user';
$db_pass = getenv('DB_PASS') ?: 'wrong_password';
// Note getenv() is PHP 5.3 compatible
try {
    $pdo = new PDO("mysql:host=$db_host;dbname=$db_name", $db_user, $db_pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
} catch (PDOException $e) {
    die("Errore di connessione: " . $e->getMessage());
}

session_start();
?>

Da Ihre App in einem Container ausgeführt wird, müssen Sie die Umgebungsvariablen auf eine der folgenden Arten bereitstellen:

Zur Build-Zeit im Dockerfile. Fügen Sie Ihrem vorherigen Dockerfile die vier Parameter mit der Syntax ENV DB_VAR=ENV_VAR_VALUE hinzu. Dadurch werden Standardwerte festgelegt, die zur Laufzeit überschrieben werden können. Beispielsweise könnten „DB_NAME“ und „DB_USER“ hier und nirgendwo sonst festgelegt werden.
Zur Laufzeit. Sie können diese Variablen für Cloud Run einrichten, sowohl über die CLI als auch über die Benutzeroberfläche. Hier können Sie alle vier Variablen einfügen, sofern Sie nicht die im Dockerfile festgelegten Standardwerte beibehalten möchten.

In localhost können Sie Ihre ENV-Variablen in eine .env-Datei einfügen (siehe Ordner solutions).

Achten Sie auch darauf, dass .env zu Ihrer .gitignore hinzugefügt wird, damit Ihre Secrets nicht auf GitHub übertragen werden.

echo .env >> .gitignore

Danach können Sie die Instanz lokal testen:

docker run -it -p 8080:8080 --env-file .env my-php-app-docker

Sie haben jetzt Folgendes erreicht:

Ihre App liest Variablen dynamisch aus Ihrer Umgebung.
Sie haben die Sicherheit verbessert, da Sie das Datenbankpasswort aus Ihrem Code entfernt haben.

Sie können jetzt eine neue Überarbeitung in Cloud Run bereitstellen. Legen wir die Umgebungsvariablen manuell über die Benutzeroberfläche fest:

Rufen Sie https://console.cloud.google.com/run auf.
Klicken Sie auf Ihre App.
Klicken Sie auf „Neue Überarbeitung bearbeiten und bereitstellen“.
Klicken Sie auf dem ersten Tab „Container“ auf den unteren Tab „Variablen und Secrets“.
Klicken Sie auf „+ Variable hinzufügen“ und fügen Sie alle erforderlichen Variablen hinzu. Das Ergebnis sollte etwa so aussehen:

Ist das perfekt? Nein. Ihr PASS ist für die meisten Betreiber weiterhin sichtbar. Dies kann mit Google Cloud Secret Manager verhindert werden.

Zweite Iteration: Secret Manager

Ihre Passwörter sind aus Ihrem eigenen Code verschwunden – ein voller Erfolg! Aber Moment – sind wir schon in Sicherheit?

Ihre Passwörter sind weiterhin für alle sichtbar, die Zugriff auf die Google Cloud Console haben. Wenn Sie auf die YAML-Bereitstellungsdatei für Cloud Run zugreifen, können Sie sie abrufen. Wenn Sie versuchen, eine neue Cloud Run-Revision zu bearbeiten oder bereitzustellen, ist das Passwort im Bereich „Variablen und Secrets“ sichtbar, wie in den Screenshots unten dargestellt.

Google Cloud Secret Manager ist ein sicherer, zentralisierter Dienst zum Verwalten sensibler Informationen wie API-Schlüssel, Passwörter, Zertifikate und anderer Secrets.

Damit können Sie Secrets mit präzisen Berechtigungen und robuster Verschlüsselung speichern, verwalten und darauf zugreifen. Secret Manager ist in Identity and Access Management (IAM) von Google Cloud eingebunden. So können Sie steuern, wer auf bestimmte Secrets zugreifen kann, und für Datensicherheit und Einhaltung von Vorschriften sorgen.

Außerdem werden die automatische Rotation und Versionsverwaltung von Secrets unterstützt, was die Verwaltung des Secret-Lebenszyklus vereinfacht und die Sicherheit in Anwendungen in allen Google Cloud-Diensten erhöht.

Um auf Secret Manager zuzugreifen, rufen Sie über das Dreistrich-Menü die Security-Dienste auf und suchen Sie im Bereich Data Protection danach, wie im Screenshot unten dargestellt.

Aktivieren Sie die Secret Manager API, wie im folgenden Bild dargestellt.

Klicken Sie nun auf Secret erstellen. Nennen wir es rational:
Name: php-amarcord-db-pass
Secret-Wert: „Ihr DB-Passwort“ (ignorieren Sie den Teil „Datei hochladen“).
Kommentiere diesen geheimen Link. Er sollte so aussehen: projects/123456789012/secrets/php-amarcord-db-pass. Dies ist der eindeutige Zeiger auf Ihr Secret (für Terraform, Cloud Run und andere). Die Nummer ist Ihre eindeutige Projektnummer.

Tipp: Verwenden Sie für Ihre Secrets konsistente Namenskonventionen, die von links nach rechts immer spezifischer werden, z. B. cloud-devrel-phpamarcord-dbpass.

Organisation (mit dem Unternehmen)
Team (innerhalb der Organisation)
Anwendung (im Team)
Variablenname (in der App)

So können Sie ganz einfach reguläre Ausdrücke verwenden, um alle Ihre Geheimnisse für eine einzelne App zu finden.

Neue Cloud Run-Überarbeitung erstellen

Da wir jetzt ein neues Secret haben, müssen wir die Umgebungsvariable DB_PASS entfernen und durch das neue Secret ersetzen. Das bedeutet:

Über die Google Cloud Console auf Cloud Run zugreifen
Wählen Sie die App aus.
Klicken Sie auf „Neue Überarbeitung bearbeiten und bereitstellen“.
Suchen Sie den Tab „Variablen und Secrets“.
Verwenden Sie die Schaltfläche „+ Auf ein Secret verweisen“, um die Umgebungsvariable DB_PASS zurückzusetzen.
Verwenden Sie dasselbe „DB_PASS“ für die referenzierten Secrets und die neueste Version.

Danach sollten Sie die folgende Fehlermeldung erhalten:

Versuchen Sie, das Problem zu beheben. Um dieses Problem zu beheben, müssen Sie auf den Bereich IAM & Verwaltung zugreifen und die Berechtigungen ändern. Viel Spaß beim Debuggen!

Wenn Sie das Problem behoben haben, kehren Sie zu Cloud Run zurück und stellen Sie eine neue Überarbeitung bereit. Das Ergebnis sollte so aussehen:

Tipp: In der Developer Console (UI) werden Berechtigungsprobleme gut angezeigt. Nehmen Sie sich Zeit, alle Links für Ihre Cloud-Entitäten aufzurufen.

7. Modul 5: CI/CD mit Cloud Build einrichten

Warum eine CI/CD-Pipeline?

Inzwischen haben Sie gcloud run deploy wahrscheinlich schon einige Male eingegeben und vielleicht immer wieder dieselbe Frage beantwortet.

Sie möchten Ihre App nicht mehr manuell mit „gcloud run deploy“ bereitstellen? Wäre es nicht toll, wenn Ihre App sich automatisch bereitstellen könnte, wenn Sie eine neue Änderung an Ihr Git-Repository übertragen?

Um eine CI/CD-Pipeline zu verwenden, benötigen Sie zwei Dinge:

Ein persönliches Git-Repository: Glücklicherweise haben Sie das Workshop-Repository in Schritt 2 bereits in Ihr GitHub-Konto geforkt. Falls nicht, holen Sie dies nach. Das geforkte Repository sollte so aussehen: https://github.com/<YOUR_GITHUB_USER>/app-mod-workshop
Cloud Build Mit diesem erstaunlichen und günstigen Dienst können Sie Build-Automatisierungen für so gut wie alles konfigurieren: Terraform, Docker-Apps usw.

In diesem Abschnitt geht es um die Einrichtung von Cloud Build.

Cloud Build

Wir verwenden Cloud Build für diesen Zweck:

Erstellen Sie Ihre Quelle (mit Dockerfile). Stellen Sie sich das als eine „große ZIP-Datei“ vor, die alles enthält, was Sie zum Erstellen und Ausführen der App benötigen (Ihr „Build-Artefakt“).
Übertragen Sie dieses Artefakt per Push in Artifact Registry (AR).
Stellen Sie dann die App „php-amarcord“ von AR in Cloud Run bereit.
Dadurch wird eine neue Version („Revision“) der vorhandenen App erstellt (stellen Sie sich eine Ebene mit dem neuen Code vor). Wir konfigurieren sie so, dass der Traffic zur neuen Version umgeleitet wird, wenn der Push erfolgreich ist.

Hier sehen Sie ein Beispiel für einige Builds für meine php-amarcord-App:

Wie setzen wir das alles um?

Durch Erstellen einer perfekten YAML-Datei: cloudbuild.yaml
Sie erstellen einen Cloud Build-Trigger.
Sie können eine Verbindung zu unserem GitHub-Repository über die Cloud Build-Benutzeroberfläche herstellen.

Trigger erstellen (und Repository verbinden)

Rufen Sie https://console.cloud.google.com/cloud-build/triggers auf.
Klicken Sie auf „Trigger erstellen“.
Kompilieren:
Name: Geben Sie einen aussagekräftigen Namen ein, z. B. on-git-commit-build-php-app.
Ereignis: Push zum Branch
Quelle: „Neues Repository verbinden“
Dadurch wird rechts das Fenster „Repository verbinden“ geöffnet.
Quellanbieter: „Github“ (zuerst)
„Weiter“
Durch „Authenticate“ wird ein Fenster auf GitHub geöffnet, in dem Sie sich authentifizieren können. Folgen Sie dem Ablauf und haben Sie Geduld. Wenn Sie viele Repos haben, kann das eine Weile dauern.
„Select repo“ (Repository auswählen): Wählen Sie Ihr Konto/Repository aus und setzen Sie ein Häkchen bei „I understand...“ (Ich habe verstanden...).
Wenn Sie den Fehler „Die GitHub-App ist in keinem Ihrer Repositories installiert“ erhalten, klicken Sie auf „Google Cloud Build installieren“ und folgen Sie der Anleitung.
Klicken Sie auf „Verbinden“.
Bingo! Ihr Repository ist jetzt verbunden.
Zurück zum Trigger…
Konfiguration: Automatisch erkannt (*)
Erweitert: Wählen Sie das Dienstkonto „[PROJECT_NUMBER]- compute@developer.gserviceaccount.com“ aus.
xxxxx ist Ihre Projekt-ID.
Das Standarddienstkonto von Compute ist für einen Lab-Ansatz geeignet, sollte aber nicht in der Produktion verwendet werden. Weitere Informationen
Lassen Sie alles andere unverändert.
Klicken Sie auf die Schaltfläche „Erstellen“.

(*) Dies ist die einfachste Methode, da nach Dockerfile oder cloudbuild.yaml gesucht wird. Mit cloudbuild.yaml haben Sie jedoch die Möglichkeit, bei jedem Schritt zu entscheiden, was als Nächstes geschehen soll.

Ich habe die Power!

Der Trigger funktioniert erst, wenn Sie dem Cloud Build-Dienstkonto (Was ist ein Dienstkonto? Die E-Mail-Adresse eines „Roboters“, der in Ihrem Namen eine Aufgabe ausführt – in diesem Fall das Erstellen von Elementen in der Cloud.

Die Erstellung und Bereitstellung Ihrer SA schlägt fehl, wenn Sie sie nicht dazu autorisieren. Das ist ganz einfach.

Rufen Sie „Cloud Build“ > Einstellungen auf.
Dienstkonto „[PROJECT_NUMBER]- compute@developer.gserviceaccount.com“
Klicken Sie auf die folgenden Kästchen:
Cloud Run
Secret Manager
Dienstkonten
Cloud Build
Setzen Sie außerdem ein Häkchen bei „Als bevorzugtes Dienstkonto festlegen“.

Wo ist die Cloud Build-YAML-Datei?

Wir empfehlen Ihnen dringend, sich etwas Zeit zu nehmen, um Ihre eigene Cloud Build-YAML-Datei zu erstellen.

Wenn Sie jedoch keine Zeit haben oder sich keine Zeit nehmen möchten, können Sie sich in diesem Lösungsordner inspirieren lassen: .solutions

Jetzt können Sie eine Änderung per Push an GitHub übertragen und beobachten, wie Cloud Build reagiert.

Die Einrichtung von Cloud Build kann schwierig sein. Es ist mit einigen Rückfragen zu rechnen:

Logs unter https://console.cloud.google.com/cloud-build/builds;region=global prüfen
Fehler finden
Beheben Sie den Fehler im Code und führen Sie „git commit“ / „git push“ noch einmal aus.
Manchmal liegt der Fehler nicht im Code, sondern in einer Konfiguration. In diesem Fall können Sie einen neuen Build über die Benutzeroberfläche ausführen (Cloud Build > „Triggers“ > „Run“).

Wenn Sie diese Lösung verwenden, müssen Sie noch einige Aufgaben erledigen. Sie müssen beispielsweise die Umgebungsvariablen für die neu erstellten Entwicklungs-/Produktionsendpunkte festlegen:

Dafür haben Sie die beiden folgenden Möglichkeiten:

Über die Benutzeroberfläche – durch erneutes Festlegen von Umgebungsvariablen
Über die CLI, indem das „perfekte“ Skript für Sie erstellt wird. Ein Beispiel finden Sie hier: gcloud-run-deploy.sh . Sie müssen einige Dinge anpassen, z. B. den Endpunkt und die Projektnummer. Ihre Projektnummer finden Sie in der Cloud-Übersicht.

Wie übertrage ich Code auf GitHub?

Es würde den Rahmen dieses Workshops sprengen, Ihnen die beste Methode zum git push auf GitHub zu vermitteln. Wenn Sie jedoch nicht weiterkommen und sich in Cloud Shell befinden, haben Sie zwei Möglichkeiten:

CLI. Fügen Sie lokal einen SSH-Schlüssel und ein Remote-Repository mit git@github.com:YOUR_USER/app-mod-workshop.git (anstelle von http) hinzu.
VSCode. Wenn Sie den Cloud Shell-Editor verwenden, können Sie auf den Tab „Quellcodeverwaltung“ (Strg+Umschalt+G) klicken, auf „Änderungen synchronisieren“ klicken und der Anleitung folgen. Sie sollten Ihr GitHub-Konto in VS Code authentifizieren können. Das Pull- und Push-Verfahren wird dann zum Kinderspiel.

Denken Sie daran, git add clodubuild.yaml in die Liste aufzunehmen, da es sonst nicht funktioniert.

Tiefer vs. oberflächlicher „Entwicklungs-/Produktionsgleichstand“ [optional]

Wenn Sie die Modellversion hier kopiert haben, haben Sie zwei identische DEV- und PROD-Versionen. Das ist praktisch und entspricht Regel 10 der Twelve-Factor App.

Wir verwenden jedoch zwei verschiedene Webendpunkte, damit eine App auf dieselbe Datenbank verweist. Für einen Workshop ist das ausreichend. In der Praxis sollten Sie sich jedoch etwas Zeit nehmen, um eine geeignete Produktionsumgebung zu erstellen. Das bedeutet, dass Sie zwei Datenbanken (eine für die Entwicklung und eine für die Produktion) benötigen und auch festlegen müssen, wo sie für die Notfallwiederherstellung / Hochverfügbarkeit gehostet werden sollen. Das würde den Rahmen dieses Workshops sprengen, aber es ist ein guter Denkanstoß.

Wenn Sie Zeit für eine „umfassende“ Version der Produktion haben, denken Sie bitte an alle Ressourcen, die Sie duplizieren müssen, z. B.:

Cloud SQL-Datenbank (und wahrscheinlich SQL-Instanz).
GCS-Bucket
Cloud Functions-Funktion
Sie können Gemini 1.5 Flash als Modell in der Entwicklung (günstiger, schneller) und Gemini 1.5 Pro (leistungsstärker) verwenden.

Überlegen Sie sich bei jeder Änderung an der App kritisch, ob der Produktionsversion derselbe Wert zugewiesen werden sollte. Wenn nicht, wiederholen Sie den Vorgang. Mit Terraform ist das natürlich viel einfacher, da Sie Ihre Umgebung (-dev, -prod) als Suffix in Ihre Ressourcen einfügen können.

8. Modul 6: Zu Google Cloud Storage migrieren

Speicher

Derzeit wird der Status in einem Docker-Container gespeichert. Wenn die Maschine kaputt geht, die App abstürzt oder Sie einfach eine neue Überarbeitung pushen, wird eine neue Überarbeitung mit einem neuen, leeren Speicher geplant: 🙈

Wie können wir das Problem beheben? Dafür gibt es mehrere Ansätze.

Bilder in der Datenbank speichern Das habe ich auch mit meiner vorherigen PHP-App gemacht. Es ist die einfachste Lösung, da sie die App nicht komplexer macht. Dadurch werden jedoch Latenz und Last Ihrer Datenbank erhöht.
Cloud Run-Anwendung zu einer speicherfreundlichen Lösung migrieren: GCE + nichtflüchtiger Speicher? Vielleicht GKE + Speicher? Hinweis: Was Sie an Kontrolle gewinnen, verlieren Sie an Agilität.
Wechseln Sie zu GCS. Google Cloud Storage bietet erstklassigen Speicher für die gesamte Google Cloud und ist die Cloud-freundlichste Lösung. Dazu müssen wir uns jedoch mit PHP-Bibliotheken beschäftigen. Gibt es PHP 5.7-Bibliotheken für GCS? Wird PHP 5.7 überhaupt von Composer unterstützt? PHP 5.3.2 ist die früheste Version, die von Composer unterstützt wird.
Vielleicht sollten Sie einen Docker-Sidecar verwenden.
Oder Sie verwenden Cloud Run-Volume-Mounts für GCS. Das klingt toll.

🤔 Speicher migrieren (offen)

[Offen] In dieser Übung sollen Sie eine Lösung finden, um Ihre Bilder so zu verschieben, dass sie auf irgendeine Weise gespeichert werden.

Abnahmetest

Ich möchte dir die Lösung nicht verraten, aber ich möchte, dass Folgendes passiert:

Sie laden newpic.jpg hoch. Sie sehen es in der App.
Sie führen ein Upgrade der App auf eine neue Version durch.
newpic.jpg ist noch da und sichtbar.

💡 Mögliche Lösung (GCS-Cloud Run-Volume-Mounts)

Das ist eine sehr elegante Lösung, mit der wir zustandsbehaftete Dateiuploads realisieren können, ohne den Code überhaupt zu ändern (abgesehen von der Anzeige einer Bildbeschreibung, was trivial ist und nur der Optik dient).

Damit sollten Sie einen Ordner aus Cloud Run in GCS einbinden können:

Alle Uploads in GCS sind in Ihrer App sichtbar.
Alle Uploads in Ihre App werden tatsächlich auf GCS hochgeladen.
Objekte, die in GCS hochgeladen werden, werden automatisch verarbeitet (Kapitel 7).

Hinweis: Bitte lesen Sie die FUSE-Hinweise. Das ist NICHT in Ordnung, wenn die Leistung ein Problem darstellt.

GCS-Bucket erstellen

GCS ist der allgegenwärtige Speicherdienst von Google Cloud. Es ist bewährt und wird von jedem GCP-Dienst verwendet, der Speicherplatz benötigt.

In Cloud Shell wird PROJECT_ID als GOOGLE_CLOUD_PROJECT exportiert:

$ export PROJECT_ID=$GOOGLE_CLOUD_PROJECT

#!/bin/bash

set -euo pipefail

# Your Cloud Run Service Name, eg php-amarcord-dev
SERVICE_NAME='php-amarcord-dev'
BUCKET="${PROJECT_ID}-public-images"
GS_BUCKET="gs://${BUCKET}"

# Create bucket
gsutil mb -l "$GCP_REGION" -p "$PROJECT_ID" "$GS_BUCKET/"

# Copy original pictures there - better if you add an image of YOURS before.
gsutil cp ./uploads/*.png "$GS_BUCKET/"

Cloud Run so konfigurieren, dass der Bucket im Ordner „/uploads/“ bereitgestellt wird

Kommen wir nun zum eleganten Teil. Wir erstellen ein Volume php_uploads und weisen Cloud Run an, eine FUSE-Bereitstellung für MOUNT_PATH durchzuführen (etwa /var/www/html/uploads/):

#!/bin/bash

set -euo pipefail

# .. keep variables from previous script..

# Uploads folder within your docker container.
# Tweak it for your app code.
MOUNT_PATH='/var/www/html/uploads/'

# Inject a volume mount to your GCS bucket in the right folder.
gcloud --project "$PROJECT_ID" beta run services update "$SERVICE_NAME" \
    --region $GCP_REGION \
    --execution-environment gen2 \
    --add-volume=name=php_uploads,type=cloud-storage,bucket="$BUCKET"  \
    --add-volume-mount=volume=php_uploads,mount-path="$MOUNT_PATH"

Wiederholen Sie diesen Schritt nun für alle Endpunkte, die auf Cloud Storage verweisen sollen.

Sie können dasselbe auch über die Benutzeroberfläche erreichen.

Erstellen Sie auf dem Tab „Volumes“ eine Volume-Bereitstellung, die auf Ihren Bucket verweist. Der Typ muss „Cloud Storage-Bucket“ sein, z. B. mit dem Namen „php_uploads“.
Stellen Sie unter „Container(s)“ > „Volume Mounts“ das gerade erstellte Volume am von Ihrer App angeforderten Volume-Punkt bereit. Das hängt von der Dockerfile ab, könnte aber so aussehen: var/www/html/uploads/ .

In beiden Fällen sollte beim Bearbeiten der neuen Cloud Run-Überarbeitung Folgendes angezeigt werden:

Testen Sie die neue Anwendung, indem Sie ein neues Bild auf den /upload.php-Endpunkt hochladen.

Die Bilder sollten nahtlos in GCS übertragen werden, ohne dass eine einzige Zeile PHP-Code geschrieben werden muss:

Was ist gerade passiert?

Etwas Magisches ist passiert.

Eine alte Anwendung mit altem Code funktioniert weiterhin. Ein neuer, modernisierter Stack ermöglicht es uns, alle Bilder in unserer App in einem zustandsbehafteten Cloud-Bucket zu speichern. Jetzt sind der Kreativität keine Grenzen mehr gesetzt:

Möchten Sie jedes Mal eine E-Mail erhalten, wenn ein Bild mit dem Label „Gefährlich“ oder „Nackt“ eingeht? Dazu müssen Sie den PHP-Code nicht bearbeiten.
Sie möchten jedes Mal ein multimodales Gemini-Modell verwenden, wenn ein Bild eingeht, um es zu beschreiben, und die Datenbank mit der Beschreibung hochladen? Dazu müssen Sie den PHP-Code nicht bearbeiten. Du glaubst mir nicht? Lesen Sie im Kapitel 7 weiter.

Wir haben hier gerade ein großes Potenzial erschlossen.

9. Modul 7: Google Gemini in Ihre App einbinden

Sie haben jetzt eine moderne, glänzende neue PHP-Anwendung (wie ein Fiat 126 von 2024) mit Cloud-Speicher.

Was kann man damit machen?

Voraussetzungen

Im vorherigen Kapitel haben wir eine Modelllösung verwendet, mit der wir Bilder /uploads/ in GCS einbinden konnten. Dadurch wurde die App-Logik de facto vom Bildspeicher getrennt.

Für diese Übung müssen Sie Folgendes tun:

Sie haben die Übung in Kapitel 6 (Speicher) erfolgreich abgeschlossen.
Sie haben einen GCS-Bucket mit den Bild-Uploads, in den Nutzer Bilder in Ihrer App hochladen und die Bilder in Ihren Bucket übertragen werden.

Cloud-Funktion einrichten (in Python)

Haben Sie sich schon einmal gefragt, wie Sie eine ereignisgesteuerte Anwendung implementieren können? Beispiel:

wenn <event> eintritt => E-Mail senden
wenn <event> eintritt => wenn <condition> wahr ist, dann aktualisiere die Datenbank.

Ein Ereignis kann alles sein, z. B. ein neuer Datensatz in BigQuery, ein neues Objekt, das in einem Ordner in GCS geändert wurde, oder eine neue Nachricht, die in einer Warteschlange in Pub/Sub wartet.

Google Cloud unterstützt mehrere Paradigmen, um dies zu erreichen. Insbesondere:

EventArc Informationen zum Empfangen von GCS-Ereignissen Ideal zum Erstellen von DAGs und zum Orchestrieren von Aktionen basierend auf If-Then-Else-Bedingungen in der Cloud.
Cloud Scheduler. Das ist beispielsweise ideal für einen Mitternachts-Cronjob in der Cloud.
Cloud Workflows Ähnlich wie bei Event Arc haben Sie folgende Möglichkeiten:
Cloud Run Functions (auch bekannt als lambdas).
Cloud Composer: Im Grunde die Google-Version von Apache Airflow, die sich auch hervorragend für DAG eignet.

In dieser Übung werden wir uns mit Cloud Functions beschäftigen, um ein spektakuläres Ergebnis zu erzielen. Außerdem stellen wir Ihnen optionale Übungen zur Verfügung.

Beispielcode ist unter .solutions/ verfügbar.

Cloud-Funktion einrichten (🐍 Python)

Wir versuchen, einen sehr ehrgeizigen GCF zu schaffen.

Wenn ein neues Image in GCS erstellt wird: (wahrscheinlich, weil jemand es in der App hochgeladen hat – aber nicht nur)
.. Gemini aufrufen, um das Bild zu beschreiben und eine Textbeschreibung des Bildes zu erhalten .. (Es wäre gut, den MIME-Typ zu prüfen und sicherzustellen, dass es sich um ein Bild und nicht um eine PDF-, MP3- oder Textdatei handelt.)
.. and update the DB with this description. Dazu muss die Datenbank möglicherweise gepatcht werden, um der Tabelle images eine description-Spalte hinzuzufügen.

Patchen Sie die Datenbank, um `description` zu Bildern hinzuzufügen.

Cloud SQL Studio öffnen:

Geben Sie Ihren Nutzernamen und Ihr Passwort für die Bilderdatenbank ein.
Fügen Sie diesen SQL-Code ein, um eine Spalte für eine Bildbeschreibung hinzuzufügen:

ALTER TABLE images ADD COLUMN description TEXT;

Und bingo! Prüfen Sie jetzt, ob es funktioniert hat:

SELECT * FROM images;

Die neue Spalte „Beschreibung“ sollte angezeigt werden:

Schreiben Sie die Gemini-Funktion f(x).

Hinweis: Diese Funktion wurde mit Unterstützung von Gemini Code Assist erstellt.

Hinweis: Beim Erstellen dieser Funktion können IAM-Berechtigungsfehler auftreten. Einige sind unten im Abschnitt „Mögliche Fehler“ dokumentiert.

APIs aktivieren
Rufen Sie https://console.cloud.google.com/functions/list auf.
Klicken Sie auf „Funktion erstellen“.
APIs über den API-Assistenten aktivieren:

Sie können die GCF entweder über die Benutzeroberfläche oder über die Befehlszeile erstellen. Hier verwenden wir die Befehlszeile.

Einen möglichen Code finden Sie unter .solutions/.

Erstellen Sie einen Ordner zum Hosten des Codes, z. B. „gcf/“. Rufen Sie den Ordner auf.
requirements.txt-Datei erstellen:

google-cloud-storage
google-cloud-aiplatform
pymysql

Erstellen Sie eine Python-Funktion. Beispielcode: gcf/main.py.

#!/usr/bin/env python

"""Complete this"""

from google.cloud import storage
from google.cloud import aiplatform
import vertexai
from vertexai.generative_models import GenerativeModel, Part
import os
import pymysql
import pymysql.cursors

# Replace with your project ID
PROJECT_ID = "your-project-id"
GEMINI_MODEL = "gemini-1.5-pro-002"
DEFAULT_PROMPT = "Generate a caption for this image: "

def gemini_describe_image_from_gcs(gcs_url, image_prompt=DEFAULT_PROMPT):
    pass

def update_db_with_description(image_filename, caption, db_user, db_pass, db_host, db_name):
    pass

def generate_caption(event, context):
    """
    Cloud Function triggered by a GCS event.
    Args:
        event (dict): The dictionary with data specific to this type of event.
        context (google.cloud.functions.Context): The context parameter contains
                                                event metadata such as event ID
                                                and timestamp.
    """
    pass

Übertragen Sie die Funktion per Push: Sie können ein ähnliches Skript wie gcf/push-to-gcf.sh verwenden.

Hinweis 1: Achten Sie darauf, dass die ENVs mit den richtigen Werten versehen sind, oder fügen Sie sie einfach oben hinzu (GS_BUCKET=blah, ..):

Hinweis 2: Dadurch wird der gesamte lokale Code (.) übertragen. Achten Sie also darauf, Ihren Code in einem bestimmten Ordner zu platzieren und .gcloudignore professionell zu verwenden, um das Übertragen großer Bibliotheken zu vermeiden. ( Beispiel)

#!/bin/bash

set -euo pipefail

# add your logic here, for instance:
source .env || exit 2 

echo "Pushing ☁️ f(x)☁ to 🪣 $GS_BUCKET, along with DB config.. (DB_PASS=$DB_PASS)"

gcloud --project "$PROJECT_ID" functions deploy php_amarcord_generate_caption \
    --runtime python310 \
    --region "$GCP_REGION" \
    --trigger-event google.cloud.storage.object.v1.finalized \
    --trigger-resource "$BUCKET" \
    --set-env-vars "DB_HOST=$DB_HOST,DB_NAME=$DB_NAME,DB_PASS=$DB_PASS,DB_USER=$DB_USER" \
    --source . \
    --entry-point generate_caption \
    --gen2

Hinweis: In diesem Beispiel ist generate_caption die aufgerufene Methode und die Cloud-Funktion übergibt das GCS-Ereignis mit allen relevanten Informationen (Bucket-Name, Objektname usw.) an sie. Nehmen Sie sich etwas Zeit, um das Python-Dictionary für das Ereignis zu debuggen.

Funktion testen

Unit Tests

Die Funktion hat viele bewegliche Teile. Möglicherweise möchten Sie alle einzelnen Tests durchführen.

Ein Beispiel finden Sie unter gcf/test.py.

Cloud Functions-UI

Nehmen Sie sich auch etwas Zeit, um sich Ihre Funktion auf der Benutzeroberfläche anzusehen. Es lohnt sich, alle Tabs anzusehen, insbesondere Source (mein Favorit), Variables, Trigger und Logs. Sie werden viel Zeit mit der Fehlerbehebung auf dem Tab Logs verbringen (siehe auch mögliche Fehler unten auf dieser Seite). Sehen Sie sich auch Permissions an.

E2E-Test

Zeit, die Funktion manuell zu testen.

Rufen Sie Ihre App auf und melden Sie sich an.
Laden Sie ein Bild hoch (nicht zu groß, da es bei großen Bildern Probleme geben kann).
Prüfen Sie in der Benutzeroberfläche, ob das Bild hochgeladen wurde.
Prüfen Sie in Cloud SQL Studio, ob die Beschreibung aktualisiert wurde. Melden Sie sich an und führen Sie die folgende Abfrage aus: SELECT * FROM images.

Die Ergebnisse sprechen für sich: Möglicherweise müssen wir auch das Frontend aktualisieren, damit die Beschreibung angezeigt wird.

PHP aktualisieren, um [optional]anzuzeigen

Wir haben nachgewiesen, dass die App funktioniert. Es wäre jedoch schön, wenn die Nutzer diese Beschreibung auch sehen könnten.

Wir müssen keine PHP-Experten sein, um die Beschreibung zu index.php hinzuzufügen. Dieser Code sollte Folgendes tun (ja, Gemini hat ihn auch für mich geschrieben):

<?php if (!empty($image['description'])): ?>
    <p class="font-bold">Gemini Caption:</p>
    <p class="italic"><?php echo $image['description']; ?></p>
<?php endif; ?>

Positionieren Sie diesen Code nach Belieben innerhalb von foreach.

In den nächsten Schritten sehen wir auch eine ansprechendere UI-Version, die durch Gemini Code Assist ermöglicht wird. Eine ansprechende Version könnte so aussehen:

Fazit

Sie haben eine Cloud-Funktion, die ausgelöst wird, wenn neue Objekte in GCS landen. Sie kann den Inhalt des Bildes wie ein Mensch annotieren und die Datenbank automatisch aktualisieren. Wow!

Nächste Schritte Mit derselben Logik lassen sich zwei nützliche Funktionen realisieren.

[Optional] Weitere Cloud Functions hinzufügen [offen]

Mir fallen noch ein paar zusätzliche Funktionen ein.

📩 E-Mail-Trigger

Ein E-Mail-Trigger, der Ihnen jedes Mal eine E-Mail sendet, wenn jemand ein Bild sendet.

Zu oft? Fügen Sie eine weitere Einschränkung hinzu: ein großes Bild oder ein Bild, dessen Gemini-Inhalt die Wörter „nackt/Nacktheit/gewalttätig“ enthält.
Weitere Informationen finden Sie unter EventArc.

🚫 Unangemessene Bilder automatisch moderieren

Derzeit werden Bilder von einem menschlichen Administrator als „unangemessen“ gekennzeichnet. Wie wäre es, wenn Gemini die Arbeit übernimmt und den Gruppenbereich moderiert? Fügen Sie einen Test hinzu, um unangemessene Triggerinhalte zu kennzeichnen, und aktualisieren Sie die Datenbank wie in der vorherigen Funktion beschrieben. Dazu wird im Grunde die vorherige Funktion verwendet, der Prompt geändert und die Datenbank anhand der Antwort aktualisiert.

Hinweis: Die Ausgaben generativer KI sind unvorhersehbar. Achten Sie darauf, dass die „Creative-Ausgabe“ von Gemini „auf dem richtigen Weg“ ist. Sie können eine deterministische Antwort wie einen Konfidenzwert zwischen 0 und 1 oder ein JSON anfordern. Das ist auf verschiedene Arten möglich, z. B. * mit Python-Bibliotheken wie pydantic oder langchain * mit strukturierter Gemini-Ausgabe.

Tipp Sie können MEHRERE Funktionen haben oder einen einzelnen Prompt verwenden, der eine JSON-Antwort erzwingt (funktioniert gut mit „Gemini Structured Output“, wie oben beschrieben):

Wie lautet der Prompt, um das zu generieren?

{
    "description": "This is the picture of an arrosticino",
    "suitable": TRUE
}

Sie können dem Prompt zusätzliche Felder hinzufügen, um Informationen wie „Gibt es etwas Gutes daran?“ zu erhalten. Was ist daran schlecht? Erkennst du den Ort? Ist Text vorhanden (OCR war noch nie so einfach):

goods: „It looks like yummie food“ (Es sieht aus wie leckeres Essen)
bads: „Es sieht aus wie ungesundes Essen“
OCR: „Da consumare preferibilmente prima del 10 Novembre 2024“
location: „Pescara, Lungomare“

Es ist zwar in der Regel besser, eine N-Funktion für N-Ergebnisse zu haben, aber es ist unglaublich lohnend, eine Funktion zu erstellen, die 10 Dinge erledigt. In diesem Artikel von Riccardo erfährst du, wie das geht.

Mögliche Fehler (meist IAM / Berechtigungen)

Als ich diese Lösung zum ersten Mal entwickelt habe, bin ich auf einige Probleme mit IAM-Berechtigungen gestoßen. Ich werde sie hier hinzufügen, um Empathie zu zeigen und einige Ideen zur Behebung zu geben.

Fehler: Nicht genügend Berechtigungen für das Dienstkonto

Hinweis: Wenn Sie eine GCF-Funktion bereitstellen, die auf einen GCS-Bucket wartet, müssen Sie die entsprechenden Berechtigungen für das Dienstkonto einrichten, das Sie für den Job verwenden, wie in der Abbildung dargestellt:

Möglicherweise müssen Sie auch EventArc-APIs aktivieren. Es kann einige Minuten dauern, bis sie vollständig verfügbar sind.

Fehler: Cloud Run Invoker fehlt

Ein weiterer Kommentar aus der Benutzeroberfläche für die GCF-Berechtigung ist dieser ( Cloud Run-Aufruferrolle):

Dieser Fehler kann behoben werden, indem Sie den Befehl im Bild ausführen, der fix-permissions.sh ähnelt.

Dieses Problem wird hier beschrieben: https://cloud.google.com/functions/docs/securing/authenticating

Fehler: Speicherlimit überschritten

Beim ersten Ausführen der Funktion wurde in meinen Logs Folgendes angezeigt: „Das Speicherlimit von 244 MiB wurde mit 270 MiB überschritten. Erhöhen Sie das Speicherlimit. Weitere Informationen finden Sie unter https://cloud.google.com/functions/docs/configuring/memory.“ Fügen Sie Ihrem GCF noch einmal RAM hinzu. Das lässt sich ganz einfach über die Benutzeroberfläche erledigen. Hier ist ein Beispiel:

Alternativ können Sie auch Ihr Cloud Run-Bereitstellungsskript korrigieren, um MEM/CPU zu erhöhen. Das dauert etwas länger.

Fehler: PubSub Published

Beim Erstellen eines Triggers mit GCF v1 wurde dieser Fehler einmal ausgegeben:

Auch dieses Problem lässt sich leicht beheben, indem Sie unter IAM Ihrem Dienstkonto die Rolle „Pub/Sub-Publisher“ zuweisen.

Fehler: Vertex AI wurde nicht verwendet

Wenn Sie diese Fehlermeldung erhalten:

Berechtigung verweigert: 403 Die Vertex AI API wurde im Projekt YOUR_PROJECT noch nicht verwendet oder ist deaktiviert. Aktivieren Sie sie unter https://console.developers.google.com/apis/api/aiplatform.googleapis.com/overview?project=YOR_PROJECT.

Sie müssen nur die Vertex AI APIs aktivieren. So aktivieren Sie ALLE erforderlichen APIs am einfachsten:

https://console.cloud.google.com/vertex-ai
Klicken Sie auf „Alle empfohlenen APIs aktivieren“.

Fehler: EventArc-Trigger nicht gefunden.

Wenn Sie diese Meldung erhalten, stellen Sie die Funktion bitte noch einmal bereit.

Fehler 400: Dienst-Agents werden bereitgestellt

400 Service-Agents werden bereitgestellt ( https://cloud.google.com/vertex-ai/docs/general/access-control#service-agents ). Service-Agents sind erforderlich, um die bereitgestellte Cloud Storage-Datei zu lesen. Bitte versuchen Sie es in ein paar Minuten noch einmal.

Warten Sie in diesem Fall einige Zeit oder fragen Sie einen Googler.

10. Modul 8: SLOs für die Verfügbarkeit erstellen

In diesem Kapitel versuchen wir, Folgendes zu erreichen:

SLIs erstellen
SLOs auf Grundlage der SLIs erstellen
Benachrichtigungen basierend auf SLOs erstellen

Dies ist ein sehr wichtiges Thema für den Autor, da Riccardo im Bereich SRE / DevOps von Google Cloud arbeitet.

(offen) SLIs und SLOs für diese App erstellen

Wie gut ist eine App, wenn Sie nicht wissen, wann sie nicht funktioniert?

Was ist ein SLO?

Meine Güte! Google hat SLOs erfunden. Weitere Informationen dazu finden Sie hier:

SRE Book – Kapitel 2 – Implementing SLOs ( 👉 Weitere SRE-Bücher)
Art of SLOs ( tolles Video). In dieser Schulung erfahren Sie, wie Sie das perfekte SLO für Ihren Dienst erstellen.
SRE-Kurs auf Coursera Ich habe dazu beigetragen!

Schritt 1: SLI/SLO für die Verfügbarkeit erstellen

Beginnen wir mit dem SLO für die Verfügbarkeit, da es am einfachsten und möglicherweise das Wichtigste ist, was Sie messen möchten.

Glücklicherweise bietet Cloud Run dank Istio eine integrierte SLO-Unterstützung.

https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/ui/create-slo

Sobald Ihre App in Cloud Run ausgeführt wird, ist das ganz einfach. Es dauert nur 30 Sekunden.

Rufen Sie die Cloud Run-Seite auf.
Klicken Sie auf Ihre App oder wählen Sie sie aus.
Wählen Sie den Tab SLOs aus.
Klicken Sie auf „+ SLO erstellen“.
Verfügbarkeit, auf Anfrage
Weiter
Kalendermonat / 99%.
Klicken Sie auf „SLO erstellen“.

Schritt 2: Benachrichtigungen für dieses SLO einrichten

Ich schlage vor, zwei Benachrichtigungen zu erstellen:

Eine mit einer niedrigen Burnrate („Slowburn“), um Sie per E-Mail zu benachrichtigen (simuliert ein Ticket mit niedriger Priorität).
Eine mit einer hohen Burnrate („Fastburn“), um Sie per SMS zu benachrichtigen (simuliert Ticket mit hoher Priorität / Pager)

Rufen Sie Ihr SLO tab von zuvor auf.

Führen Sie die folgenden Schritte zweimal aus:

Klicken Sie rechts auf „SLO-Benachrichtigung erstellen“ (die Glocke 🔔 mit einem Pluszeichen).
Lookback-Dauer, Burn-Rate-Grenzwert:
[SCHNELL]. Erste: 60 Minuten / 10-mal
[LANGSAM]. Zweite: 720 Minuten / 2-mal
Benachrichtigungskanal: Klicken Sie auf „Benachrichtigungskanäle verwalten“.
Zuerst „E-Mail“ –> „Neu hinzufügen“ –> …
Zweitens: „SMS“ –> „Neu hinzufügen“ –> „Auf dem Smartphone bestätigen“.
Tipp: Ich verwende gerne Emojis in den Namen. Das ist für Demos ganz praktisch.
Wenn Sie fertig sind, klicken Sie rechts oben auf das große „X“.
Wählen Sie zuerst das Telefon (schnell) und dann die E‑Mail-Adresse (langsam) aus.
Fügen Sie einige Beispieldokumente hinzu, z. B.:
[PHP Amarcord] Riccardo told me to type sudo reboot or to check documentation in http://example.com/playbooks/1.php but I guess he was joking.

Bingo!

Endergebnis

Die Übung gilt als abgeschlossen, sobald Sie ein funktionierendes SLO und zwei Benachrichtigungen für Ihre Verfügbarkeit haben, die an Ihre E‑Mail-Adresse und Ihr Telefon gesendet werden.

Sie können eine Latenz hinzufügen (was ich Ihnen dringend empfehle) oder sogar eine komplexere. Wählen Sie für die Latenz einen Wert aus, der Ihnen angemessen erscheint. Im Zweifelsfall wählen Sie 200 ms.

11. Nächste Schritte

Du hast ALLES erledigt. Was fehlt?

Einige Denkanstöße:

Google Play und Gemini

Sie können Gemini in zwei Varianten nutzen:

Vertex AI Die „Enterprise-Methode“ ist eng mit Ihrer GCP verknüpft, die wir in Kapitel 7 (GCF+Gemini) behandelt haben. Die gesamte Authentifizierung funktioniert wie von Zauberhand und die Dienste sind nahtlos miteinander verbunden.
Google AI Der „Consumer Way“ Sie erhalten einen Gemini API-Schlüssel hier und können mit dem Erstellen kleiner Skripts beginnen, die an jede beliebige Arbeitslast gebunden werden können (proprietäre Arbeit, andere Clouds, localhost usw.). Sie müssen nur Ihren API-Schlüssel ersetzen und der Code funktioniert wie von Zauberhand.

Wir empfehlen Ihnen, (2) mit Ihren eigenen Projekten auszuprobieren.

UI-Lifting

Ich bin nicht gut im Erstellen von Benutzeroberflächen. Gemini ist es aber. Sie können einfach eine einzelne PHP-Seite nehmen und Folgendes eingeben:

I have a VERY old PHP application. I want to touch it as little as possible. Can you help me:

1. add some nice CSS to it, a single static include for tailwind or similar, whatever you prefer
2. Transform the image print with description into cards, which fit 4 per line in the canvas?

Here's the code:

-----------------------------------
[Paste your PHP page, for instance index.php - mind the token limit!]

Das ist ganz einfach und dauert weniger als 5 Minuten – mit nur einem Cloud Build-Vorgang. :)

Die Antwort von Gemini war perfekt (d. h., ich musste nichts ändern):

Und so sieht das neue Layout in der persönlichen App des Autors aus:

Hinweis: Der Code wird als Bild eingefügt, da wir Sie nicht dazu ermutigen möchten, den Code zu übernehmen, sondern Gemini den Code für Sie schreiben zu lassen, mit Ihren eigenen kreativen UI-/Frontend-Einschränkungen. Vertrauen Sie mir, danach sind nur sehr geringfügige Änderungen erforderlich.

Sicherheit

Die ordnungsgemäße Sicherung dieser App ist kein Ziel dieses 4-stündigen Workshops, da sie die Zeit für den Abschluss dieses Workshops um 1 bis 2 Größenordnungen verlängern würde.

Dieses Thema ist jedoch sehr wichtig. Wir haben einige Ideen in SECURITY zusammengestellt.

12. Glückwunsch!

Herzlichen Glückwunsch 🎉🎉🎉 , Sie haben Ihre Legacy-PHP-Anwendung erfolgreich mit Google Cloud modernisiert.

Zusammenfassend haben Sie in diesem Codelab Folgendes gelernt:

Wie Sie eine Datenbank in Google Cloud SQL bereitstellen und Ihre vorhandene Datenbank dorthin migrieren.
PHP-Anwendung mit Docker und Buildpacks containerisieren und das Image in Google Cloud Artifact Registry speichern
Containerisierte App in Cloud Run bereitstellen und mit Cloud SQL ausführen
Vertrauliche Konfigurationsparameter (z. B. DB-Passwort) mit Google Secret Manager sicher speichern/verwenden
So richten Sie Ihre CI/CD-Pipeline mit Google Cloud Build ein, um Ihre PHP-App bei jedem Code-Push in Ihr GitHub-Repository automatisch zu erstellen und bereitzustellen.
Cloud Storage zum „Cloudifizieren“ von App-Ressourcen verwenden
Wie Sie serverlose Technologien nutzen können, um beeindruckende Workflows in Google Cloud zu erstellen, ohne den App-Code zu ändern.
Verwenden Sie die multimodalen Funktionen von Gemini für einen passenden Anwendungsfall.
SRE-Prinzipien in Google Cloud implementieren

Das ist ein guter Anfang für Ihre Reise zur Anwendungsmodernisierung mit Google Cloud.

🔁 Feedback

Wenn Sie uns von Ihren Erfahrungen mit diesem Workshop berichten möchten, können Sie dieses Feedbackformular ausfüllen.

Wir freuen uns über Ihr Feedback und Pull-Requests für Code, auf den Sie besonders stolz sind.

🙏 Vielen Dank

Der Autor möchte sich bei Mirko Gilioli und Maurizio Ipsale von Datatonic für die Unterstützung beim Verfassen und Testen der Lösung bedanken.

App Mod-Workshop

1. Einführung

Wie modernisieren wir eine alte PHP-Anwendung für Google Cloud?

Über die App

Dein Ziel

Voraussetzungen

2. Guthaben einrichten und Fork

GCP-Guthaben einlösen und GCP-Umgebung einrichten [optional]

App von GitHub forken

3. Modul 1: SQL-Instanz erstellen

Google Cloud SQL-Instanz erstellen

Datenbank „image_catalog“ und Nutzer in Cloud SQL erstellen

Öffnen Sie die Datenbank für bekannte IP-Adressen.

Zeit, die Datenbankverbindung zu testen

Datenbank aus dem Code importieren

4. Modul 2: PHP-Anwendung containerisieren

Docker

Ergebnis im Browser testen

In Artifact Registry speichern [optional]

Mögliche Fehler

5. Modul 3: App in Cloud Run bereitstellen

Warum Cloud Run?

Voraussetzungen

Vor der Bereitstellung

App über gcloud in Cloud Run bereitstellen

„gcloud run deploy“ ohne Argumente

6. Modul 4: Passwort mit Secret Manager bereinigen

Erste Iteration: config.php für die Verwendung von ENV aktualisieren

Zweite Iteration: Secret Manager

Neue Cloud Run-Überarbeitung erstellen

7. Modul 5: CI/CD mit Cloud Build einrichten

Warum eine CI/CD-Pipeline?

Cloud Build

Trigger erstellen (und Repository verbinden)

Ich habe die Power!

Wo ist die Cloud Build-YAML-Datei?

Wie übertrage ich Code auf GitHub?

Tiefer vs. oberflächlicher „Entwicklungs-/Produktionsgleichstand“ [optional]

8. Modul 6: Zu Google Cloud Storage migrieren

Speicher

🤔 Speicher migrieren (offen)

Abnahmetest

💡 Mögliche Lösung (GCS-Cloud Run-Volume-Mounts)

GCS-Bucket erstellen

Cloud Run so konfigurieren, dass der Bucket im Ordner „/uploads/“ bereitgestellt wird

Was ist gerade passiert?

9. Modul 7: Google Gemini in Ihre App einbinden

Voraussetzungen

Cloud-Funktion einrichten (in Python)

Cloud-Funktion einrichten (🐍 Python)

Patchen Sie die Datenbank, um description zu Bildern hinzuzufügen.

Schreiben Sie die Gemini-Funktion f(x).

Funktion testen

Unit Tests

Cloud Functions-UI

E2E-Test

PHP aktualisieren, um [optional]anzuzeigen

Fazit

[Optional] Weitere Cloud Functions hinzufügen [offen]

📩 E-Mail-Trigger

🚫 Unangemessene Bilder automatisch moderieren

Mögliche Fehler (meist IAM / Berechtigungen)

Fehler: Nicht genügend Berechtigungen für das Dienstkonto

Fehler: Cloud Run Invoker fehlt

Fehler: Speicherlimit überschritten

Fehler: PubSub Published

Fehler: Vertex AI wurde nicht verwendet

Fehler: EventArc-Trigger nicht gefunden.

Fehler 400: Dienst-Agents werden bereitgestellt

10. Modul 8: SLOs für die Verfügbarkeit erstellen

(offen) SLIs und SLOs für diese App erstellen

Was ist ein SLO?

Schritt 1: SLI/SLO für die Verfügbarkeit erstellen

Schritt 2: Benachrichtigungen für dieses SLO einrichten

Endergebnis

11. Nächste Schritte

Google Play und Gemini

UI-Lifting

Sicherheit

12. Glückwunsch!

Patchen Sie die Datenbank, um `description` zu Bildern hinzuzufügen.