Im Fall des Fehlers "denied: Unauthenticated request. Unauthenticated requests do not have permission" beim Pushen des Image kann die Lösung sein, docker explizit mit dem folgenden Befehl bei der Google Registry anzumelden:
Mit Docker in die Google Cloud – in drei Schritten

In der dynamischen Welt der Softwareentwicklung sind Geschwindigkeit und Flexibilität entscheidend. Unternehmen suchen ständig nach Möglichkeiten, neue Anwendungen schnell, effizient und kostengünstig zu entwickeln und bereitzustellen. Eine Lösung hierfür ist die Kombination von Docker, Google Cloud Run und Artifact Registry.
Diese leistungsstarken Tools ermöglichen es, Docker-Images nahtlos über die Google Cloud bereitzustellen und zu verwalten, ohne viel Bürokratie, Kosten oder eigene Server-Ressourcen vorhalten zu müssen. Damit können zum Beispiel erste Entwürfe und Proof of Concepts von Applikationen schnell für Kunden und Tester bereitgestellt werden, was sich positiv auf Geschwindigkeit und Qualität von Projekten auswirkt. In diesem Beitrag möchte ich aufzeigen, wie man in nur drei Schritten vom lokalen Projekt in die Google Cloud gelangt.
Die drei Schritte in die Cloud: Von Docker über Artifact Registry zu Cloud Run
Das klappt zumindest fast. Für die Umsetzung benötigen wir neben einer Docker-Umgebung die Google Cloud-Produkte Artifact Registry und Google Cloud Run sowie einen aktiven Google Cloud Account mit Rechten im gewünschten Ziel-Projekt. Diese Punkte nehme ich als gegeben an, nun aber ab in die Cloud.
Erstens: Die Artifact Registry
Im ersten Schritt wird ein neues Docker-Repository in der Artifact Registry erstellt, in das wir dann unsere Docker-Files laden können. Hierfür benötigen wir lediglich einen Namen und die passende Region, in meinem Fall europe-west3 (Frankfurt).
Die Kombination aus Projekt- und Repository-Name ist für den nächsten Schritt wichtig, kann aber einfach aus den Details des neu erstellten Repos kopiert werden. Das war schon alles, was in der Artifact Registry an Arbeit anfällt. Als Nächstes können wir das Docker-File bauen und in unser neues Repository laden.
Zweitens: Das Docker-File
Wie genau das Docker-File aussieht, hängt vom jeweiligen Projekt ab und kann durchaus komplex werden. Für diesen Blog will ich es aber simpel halten und ziehe eine Flutter-Demo aus dem Blogpost „Flutter Design Series: Glas Morphismus“ heran, die stellvertretend für eine beliebige Web-App einspringt.
Für die Umsetzung greife ich auf das nginx-Docker-Image zurück und kopiere einfach den Web-Build in den Container:
FROM nginx
COPY ./build/web /usr/share/nginx/html
Beim eigentlichen Bauen gibt es zwei Punkte, auf die man achten muss:
- Die Google Instanzen benutzen Linux-Maschinen, entsprechend sollte man die Plattform beim Build-Befehl angeben, wenn sich die Architektur des Systems, auf dem man den Befehl ausführt, unterscheidet.
- Der Tag muss den Repository-Pfad enthalten. Dieser setzt sich aus Region, Projekt- und Repositoryname zusammen und kann in der Artifact Registry kopiert werden. Am Ende wird der Image-Name und ggf. eine Versionsnummer angehängt.
In meinem Fall sieht der Build-Befehl wie folgt aus:
docker buildx build --platform linux/amd64 -t europe-west3-docker.pkg.dev/demoproject-404711/demorepo/aflutterdemo:v01 .
Sobald der Build durchgelaufen ist, müssen wir das neu erstellte Image nur noch in das eben erstellte Repository laden. Das erfolgt mittels des Befehls:
docker push europe-west3-docker.pkg.dev/demoproject-404711/demorepo/aflutterdemo:v01
Tipp
gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin europe-west3-docker.pkg.dev
Damit ist alles vorbereitet, um den Container mittels Cloud Run öffentlich verfügbar zu stellen.
Drittens: Google Cloud Run
Zu guter Letzt müssen wir das in die Cloud geladene Docker-Image noch verfügbar machen. Dafür nutzen wir Google Cloud Run, mit dem einfache Container bereitgestellt werden können. Dafür erstellen wir einen neuen Cloud Run Service und wählen bei der Container Image URL das in die Registry geladene Image aus dem letzten Schritt. Die restlichen Optionen hängen von den Anforderungen des Projekts ab. Für unsere Demo-App wählen wir wieder die Region Frankfurt und wählen die schwächsten Ressourcen-Optionen, um möglichst im kostenfreien Bereich zu bleiben. Ein wichtiger Punkt ist noch die Authentifizierung. Hier kann bestimmt werden, ob der Service öffentlich verfügbar ist oder mittels Google IAM abgesichert wird. Für diese Demo stelle ich die Option auf öffentlich, sie kann aber jederzeit geändert werden, um z.B. Testern nur zeitlich begrenzt öffentlichen Zugang zu gewähren. Nach dem Speichern erzeugt Google den Service und stellt ihn online.
Die automatisch von Google erzeugte URL für den Service kann der Seite entnommen werden, sobald die Bereitstellung abgeschlossen ist. Damit kommen wir zum Ende dieser kurzen Einführung. Natürlich kann nachträglich eine neue Revision mit einem neuen Docker-Image erstellt, mehr Ressourcen für den Service konfiguriert werden, wenn der Bedarf steigt oder eine eigene URL dem Service zugewiesen werden. Aber das übersteigt den Horizont dieses Beitrags.
Applikationen schnell bereitstellen - das funktioniert mit Docker, Artifact Registry und Cloud Run
Die Kombination aus Docker, Google Cloud Run und Artifact Registry bietet eine leistungsstarke und flexible Lösung für die Bereitstellung von Anwendungen in der Cloud. In nur drei Schritten können Entwickler ihre Projekte schnell und effizient vom lokalen Rechner in die Google Cloud übertragen und dort verwalten. Dies ermöglicht nicht nur eine schnellere Bereitstellung und Skalierung von Anwendungen, sondern auch eine einfache Verwaltung und Aktualisierung, wodurch Entwicklungszyklen optimiert und die Produktqualität verbessert werden. Mit diesen Tools sind Unternehmen bestens gerüstet, um den Anforderungen der modernen Softwareentwicklung gerecht zu werden.
Links
- Flutter Design Series: Glas Morphismus: https://www.exensio.de/news-medien/newsreader-blog/flutter-design-series-glas-morphismus
- Nginx Docker Image: https://hub.docker.com/_/nginx