Uitrollen vanuit een GitHub-repository

Een Container App kan rechtstreeks uit een GitHub-repository worden gebouwd: koppel de repository één keer, kies een branch, en elke push naar die branch wordt voor je gebouwd en uitgerold. Een Dockerfile is niet vereist, maar wordt gebruikt als hij er is. Deze gids loopt door de eerste deploy, wat er bij een push gebeurt en hoe je een mislukte build leest.

Wat je nodig hebt

Een Headpat Space-account met een geverifieerd e-mailadres en ingevulde factuurgegevens.
Een GitHub-repository met een webapplicatie erin: Node, Python, Go, Ruby, PHP, Rust, Java, of iets met een Dockerfile. Je moet GitHub Apps mogen installeren op het account of de organisatie die de repository bezit.

1. Maak de app vanuit GitHub

Log in op het paneel, open Apps in de zijbalk en klik op App aanmaken.
Kies onder Template voor Container App.
Kies bij de bronopties Vanaf GitHub en klik op GitHub koppelen. GitHub opent, vraagt op welk account of welke organisatie de Headpat-app geïnstalleerd moet worden en welke repositories hij mag zien. Kies de repository, of allemaal, en bevestig; GitHub stuurt je terug naar de wizard.
Kies het GitHub-account, de Repository en de Branch die je wilt uitrollen. Een notitie onder de branch herinnert je eraan dat elke push ernaar de app opnieuw bouwt en uitrolt.
Stel de Container-poort in: de poort waarop je app binnen de container luistert, bijvoorbeeld 3000 voor een Node-server. Het platform stuurt HTTPS-verkeer daarnaartoe.
Voeg de Omgevingsvariabelen toe die je app tijdens het draaien nodig heeft, en Build-variabelen als de build er nodig heeft (een token voor een package-registry, een NODE_ENV). Geheimen horen hier, nooit in de repository.
Stel optioneel Permanente opslag in op een map waarvan de inhoud deploys moet overleven, zoals /data voor een SQLite-database of uploads. Laat het leeg voor stateless apps.
Kies een pakket, vul een Weergavenaam in, klik op App deployen en rond de betaling af.

2. De eerste build

De app-pagina toont een kaart Build. De build haalt je branch op, herkent de taal en bouwt een image. Bevat de repository een Dockerfile, dan wordt die ongewijzigd gebruikt; anders kiest de build een recept op basis van de bestanden die hij vindt: package.json, requirements.txt of pyproject.toml, go.mod, Gemfile, composer.json, enzovoort.

Klik op Logs bekijken om live mee te kijken. Het logboek is verdeeld in drie fasen, fetch, prepare en build; een fout noemt de fase en toont de laatste regels, meestal genoeg om de ontbrekende dependency of het mislukte commando te zien.

Zodra de build slaagt start de app, krijgt hij zijn hostnaam en een TLS-certificaat, en toont de kaart Build geslaagd. Tot de eerste geslaagde build is er niets om te serveren, en dat zegt de kaart ook.

3. Wijzigingen uitrollen

Push naar de branch. Binnen enkele seconden toont de Build-kaart een nieuwe build voor die commit, met de korte commit-hash in de status. Bij apps zonder persistente opslag blijft de oude versie verkeer bedienen tot het nieuwe image klaar is; apps met een volume stoppen even terwijl de nieuwe versie het volume overneemt. Push je opnieuw terwijl er een build loopt, dan wordt die build geannuleerd en wint de nieuwste commit.

Andere manieren om uit te rollen:

Opnieuw bouwen bouwt de huidige branch-head opnieuw zonder nieuwe commit, handig na het wijzigen van build-variabelen.
Broncode vervangen schakelt de app over naar een geüpload archief in plaats van GitHub; Broncode downloaden geeft je precies de boom van de huidige build.
Build-geschiedenis somt elke build met zijn uitkomst op, zodat je ziet wat wanneer is uitgerold.

Het wijzigen van omgevingsvariabelen of de poort in de kaart Configuratie herstart de app met de nieuwe waarden; daar is geen rebuild voor nodig. Build-time variabelen wel: wijzig ze en klik op Opnieuw bouwen.

Als de build mislukt

Het logboek vertelt je waar. De gangbare oorzaken:

Geen recept gevonden: de root van de repository bevat geen van de bestanden die de detector herkent, of de app staat in een submap. Voeg een Dockerfile toe, of verplaats de app naar de root.
Een dependency-installatie mislukt: lockfile en manifest komen niet overeen, of een privé-package heeft een token nodig. Herstel de lockfile, of voeg het token toe als build-time variabele.
De app bouwt maar wordt nooit gereed: hij luistert op een andere poort dan je hebt ingesteld, of bindt aan localhost in plaats van aan alle interfaces. Bind aan 0.0.0.0 en laat de poort overeenkomen.
De app crasht bij het starten: meestal een ontbrekende omgevingsvariabele. De kaart Logs & diagnose toont de stacktrace.

Goed om te weten

De GitHub App heeft alleen leestoegang nodig tot de repositories die je toekent. Intrekken op GitHub stopt toekomstige deploys; de draaiende app wordt niet geraakt.
Eén repository kan meerdere apps voeden, bijvoorbeeld main voor productie en staging voor een testinstantie.
Je kunt het image ook zelf pushen en het paneel het laten draaien; zie Elk Docker-image draaien met Container App. Dat uitrollen vanuit je eigen CI staat in Het paneel automatiseren met API-sleutels en de CLI.