Aus einem GitHub-Repository deployen

Eine Container App lässt sich direkt aus einem GitHub-Repository bauen: Repository einmal verbinden, Branch wählen, und jeder Push auf diesen Branch wird für dich gebaut und ausgerollt. Ein Dockerfile ist nicht nötig, wird aber benutzt, wenn eines da ist. Diese Anleitung geht durch das erste Deployment, durch das, was bei einem Push passiert, und durch das Lesen eines fehlgeschlagenen Builds.

Was du brauchst

• Ein Headpat-Space-Konto mit bestätigter E-Mail-Adresse und ausgefüllten Rechnungsdaten.
• Ein GitHub-Repository mit einer Webanwendung darin: Node, Python, Go, Ruby, PHP, Rust, Java oder irgendetwas mit einem Dockerfile. Du musst GitHub Apps auf dem Konto oder der Organisation installieren dürfen, der das Repository gehört.

1. App aus GitHub erstellen

1. Melde dich im Panel an, öffne Apps in der Seitenleiste und klicke auf App erstellen.
2. Wähle unter Vorlage die Container App.
3. Wähle bei den Quelloptionen Von GitHub und klicke auf GitHub verbinden. GitHub öffnet sich, fragt, auf welchem Konto oder welcher Organisation die Headpat-App installiert werden soll und welche Repositories sie sehen darf. Wähle das Repository, oder alle, und bestätige; GitHub schickt dich zurück in den Assistenten.
4. Wähle das GitHub-Konto, das Repository und den Branch, der ausgerollt werden soll. Ein Hinweis unter dem Branch erinnert daran, dass jeder Push darauf die App neu baut und ausrollt.
5. Setze den Container-Port: den Port, auf dem deine App im Container lauscht, etwa 3000 für einen Node-Server. Die Plattform leitet den HTTPS-Verkehr dorthin.
6. Ergänze die Umgebungsvariablen, die deine App zur Laufzeit braucht, und Build-Variablen, falls der Build welche braucht (ein Token für eine Paket-Registry, ein NODE_ENV). Geheimnisse gehören hierher, nie ins Repository.
7. Setze optional Persistenter Speicher auf einen Ordner, dessen Inhalt Deployments überleben muss, etwa /data für eine SQLite-Datenbank oder Uploads. Für zustandslose Apps bleibt das leer.
8. Wähle ein Paket, trage einen Anzeigenamen ein, klicke auf App bereitstellen und schließe die Zahlung ab.

2. Der erste Build

Die App-Seite zeigt eine Karte Build. Der Build holt deinen Branch, erkennt die Sprache und baut ein Image. Enthält das Repository ein Dockerfile, wird es unverändert benutzt; sonst wählt der Build ein Rezept anhand der gefundenen Dateien: package.json, requirements.txt oder pyproject.toml, go.mod, Gemfile, composer.json und so weiter.

Klicke auf Logs ansehen, um live mitzulesen. Das Protokoll ist in drei Phasen geteilt, fetch, prepare und build; ein Fehler nennt die Phase und zeigt die letzten Zeilen, was meist reicht, um die fehlende Abhängigkeit oder den gescheiterten Befehl zu sehen.

Sobald der Build gelingt, startet die App, bekommt ihren Hostnamen und ein TLS-Zertifikat, und die Karte zeigt Build erfolgreich. Bis zum ersten erfolgreichen Build gibt es nichts auszuliefern, und die Karte sagt das auch.

3. Änderungen ausrollen

Pushe auf den Branch. Innerhalb von Sekunden zeigt die Build-Karte einen neuen Build für diesen Commit, mit dem kurzen Commit-Hash im Status. Bei Apps ohne persistenten Speicher bedient die alte Version den Verkehr weiter, bis das neue Image bereit ist; Apps mit einem Volume halten kurz an, während die neue Version das Volume übernimmt. Pushst du erneut, während ein Build läuft, wird dieser abgebrochen, und der neueste Commit gewinnt.

Weitere Wege zum Ausrollen:

• Neu bauen baut den aktuellen Branch-Stand ohne neuen Commit erneut, nützlich nach geänderten Build-Variablen.
• Quellcode ersetzen stellt die App auf ein hochgeladenes Archiv statt GitHub um; Quellcode herunterladen liefert genau den Stand des aktuellen Builds.
• Build-Verlauf listet jeden Build mit Ergebnis, sodass du siehst, was wann ausgerollt wurde.

Umgebungsvariablen oder den Port in der Karte Konfiguration zu ändern startet die App mit den neuen Werten neu; ein Rebuild ist dafür nicht nötig. Build-Variablen schon: ändern und auf Neu bauen klicken.

Wenn der Build fehlschlägt

Das Protokoll sagt, wo. Die häufigen Fälle:

• Kein Rezept gefunden: das Repository-Root enthält keine der Dateien, die der Detektor kennt, oder die App liegt in einem Unterordner. Füge ein Dockerfile hinzu oder verschiebe die App ins Root.
• Eine Abhängigkeitsinstallation scheitert: Lockfile und Manifest widersprechen sich, oder ein privates Paket braucht ein Token. Repariere das Lockfile oder hinterlege das Token als Build-Variable.
• Die App baut, wird aber nie bereit: sie lauscht auf einem anderen Port als dem gesetzten oder bindet an localhost statt an alle Schnittstellen. Binde an 0.0.0.0 und gleiche den Port an.
• Die App stürzt beim Start ab: meistens eine fehlende Umgebungsvariable. Die Karte Logs & Diagnose zeigt den Stacktrace.

Gut zu wissen

• Die GitHub App braucht nur Lesezugriff auf die Repositories, die du ihr gewährst. Ein Widerruf auf GitHub stoppt künftige Deployments; die laufende App bleibt unberührt.
• Ein Repository kann mehrere Apps versorgen, zum Beispiel main für Produktion und staging für eine Testinstanz.
• Du kannst das Image auch selbst pushen und das Panel es betreiben lassen; siehe Beliebiges Docker-Image mit Container App deployen. Das Ausrollen aus der eigenen CI steht in Das Panel mit API-Schlüsseln und der CLI automatisieren.