Status
Eine einzelne App ist auf Deploio schnell deployt. Bis aber eine komplette Umgebung mit Datenbank, Object Storage und allen Zugangsdaten steht, braucht es immer noch einige manuelle Schritte.
An einem Freitag im September haben wir uns an einem internen Hackathon genau diese Handgriffe vorgenommen. Drei Teams hatten je einen Tag Zeit für ein Konzept oder einen Prototyp. Vorweg: Nichts davon ist heute produktiv im Einsatz, und was davon auf die Roadmap kommt, ist noch offen. Gerade deshalb zeigen wir hier, was wir ausprobiert haben, wo wir an Grenzen gestossen sind und worüber wir noch diskutieren.
Ein «Deploy to Deploio»-Button für ganze Setups
Die Webagentur Renuo, die ihre Kundenprojekte auf Deploio betreibt, hatte den Wunsch schon früher eingebracht: einen Deploy-Button wie bei Heroku, den man in eine README packt, um ein Projekt direkt in Deploio zu starten. Die erste Gruppe hat daraus einen Prototyp gebaut, der nicht bloss einen einzelnen Container startet, sondern den gesamten Stack samt Datenbank und Service-Verbindung anlegt.
Ein Klick auf den Button öffnet eine vorausgefüllte Ansicht im Cockpit. Das Cockpit fragt nur noch projektspezifische Werte ab (etwa einen initialen Admin-User) und kann Secrets automatisch generieren. Vor dem Klick auf «Deploy» lassen sich Details wie Datenbankversion, Standort oder Backup-Einstellungen noch anpassen.
Technisch basiert der Button auf einer YAML-Datei, die Repository, Umgebungsvariablen, Jobs und angebundene Services beschreibt. Weil niemand ein weiteres YAML-Schema von Hand schreiben will, hat das Team gleich einen Wizard dazu gebaut: Er zieht die gültigen Parameter direkt aus unserer API, validiert die Eingaben und gibt das fertige Snippet für die Dokumentation aus.
Spannend ist das vor allem für Agenturen, die denselben Basis-Stack für Dutzende Kundenprojekte immer wieder frisch aufsetzen. Beim Bau des Prototyps zeigten sich aber auch klare Hürden:
- Private Repositories werden im Prototyp noch nicht unterstützt.
- Cockpit-Architektur: Das Cockpit ist heute darauf ausgelegt, Ressourcen einzeln anzulegen. Ganze Setups in einem Schritt zu orchestrieren, erfordert im UI-Unterbau einigen Umbau.
- Zielgruppe und Leitplanken: Soll der Button nur für Agenturen und ihre eigenen Templates gedacht sein oder auch für Open-Source-Projekte? Und wenn sich ein komplexer Stack mit einem Klick starten lässt: Wie verhindern wir, dass Leute Setups deployen, die sie im Betrieb oder bei Fehlern nicht selbst überblicken?
Object Storage ohne Copy-Paste von Zugangsdaten
Datenbanken, Key-Value Stores und OpenSearch lassen sich auf Deploio über eine Service-Verbindung direkt an eine App hängen: Die Zugangsdaten landen automatisch als Umgebungsvariablen im Container. Object Storage tanzt hier noch aus der Reihe: Wer einen Bucket einbinden will, muss ihn anlegen, einen Bucket-User erstellen, Berechtigungen setzen und die Keys von Hand in die App kopieren. Wird die App später gelöscht, bleiben verwaiste User und Berechtigungen meist liegen.
Um zu testen, wie sich das abkürzen lässt, hat die zweite Gruppe einen bestehenden S3-Browser von GitHub per Dockerfile auf Deploio deployt, ohne den Code anzufassen. Dabei zeigte sich schnell: Die meisten Tools erwarten für S3-Zugangsdaten dieselben Standard-Variablennamen (wie AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY).
Das Konzept, das daraus entstanden ist: Beim Aktualisieren einer App mit nctl übergibst du künftig nur noch den gewünschten Bucket-Namen, und Deploio übernimmt den Rest. Die Plattform legt automatisch einen User mit Lese- und Schreibrechten an, reicht die Credentials unter den üblichen Standardnamen an die App weiter und räumt User sowie Berechtigungen beim Löschen der App wieder auf, während der Bucket und die Daten erhalten bleiben. Für Apps, die andere Variablennamen erwarten, liessen sich später Aliase ergänzen. Kurz: Ein Bucket soll sich genauso anfühlen wie jeder andere On-Demand Service.
One-Click-Apps: Wo ziehen wir die Grenze?
Die dritte Gruppe hat keinen Code geschrieben, sondern eine Produktfrage geklärt: Wenn wir auf Deploio vorgefertigte Apps anbieten, welche ergeben Sinn und wer trägt die Verantwortung für den Betrieb?
Wenn von «One-Click-Apps» die Rede ist, sind meist drei sehr unterschiedliche Dinge gemeint:
- Endkunden-Applikationen (wie WordPress), die wir selbst warten.
- Offene Community-Templates, bei denen wir Pull Requests prüfen.
- Entwickler-Tools, die unsere bestehenden Managed Services ergänzen.
Die ersten beiden Varianten haben wir schnell verworfen. Unsere Erfahrung zeigt: Sobald man Endkunden-Software wie WordPress oder ein Videokonferenz-Tool per Knopfdruck anbietet, verschwimmt im Alltag die Support-Grenze. Wenn ein Plugin-Update die Seite lahmlegt, landen die Tickets bei uns, selbst wenn wir offiziell keinen Applikations-Support leisten. Diesen Betreuungs- und Update-Aufwand gibt der Preis einer kleinen Deploio-App schlicht nicht her. Natürlich kannst du WordPress oder Nextcloud weiterhin selbst auf Deploio deployen; dann ist aber von Anfang an klar, dass Betrieb und Updates der Applikation bei dir liegen (während wir wie gewohnt bei Problemen mit der Plattform selbst helfen).
Sinnvoll ist dagegen die dritte Kategorie: Werkzeuge für technische Teams und Agenturen wie ein S3-Browser, phpMyAdmin oder OpenSearch Dashboards. Als Machbarkeitsnachweis hat die Gruppe OpenSearch Dashboards neben einer On-Demand-OpenSearch-Instanz aufgesetzt und über eine Service-Verbindung automatisch verknüpft. Ebenfalls auf der Wunschliste vieler Agenturen steht Mailpit, um E-Mails aus Staging-Umgebungen abzufangen. Daran scheitert es im Moment noch aus einem einfachen Grund: Mailpit benötigt einen SMTP-Port, und Deploio nimmt aktuell ausschliesslich HTTP- und HTTPS-Traffic entgegen.
Was würde dir den Alltag erleichtern?
Bevor wir entscheiden, welche dieser Prototypen wir zu regulären Features ausbauen, interessiert uns deine Sicht: Welches Begleit-Tool würdest du auf Deploio sofort per Klick starten, und welcher manuelle Schritt beim Deployen nervt dich heute am meisten? Schreib es uns in die Kommentare oder wirf einen Blick in die Deploio-Dokumentation, um zu sehen, was heute schon geht.
