We herkennen het allemaal wel: Je hebt een container oplossing. Je bouwt het, implementeert het, werkt het bij en beheert het. In feite de gehele lifecycle. Maar helaas nog altijd handmatig. Dit werkt wellicht voor één container, of bijvoorbeeld twee. Maar stel je even voor dat je 15 verschillende container images moet onderhouden! Dat wordt nog even veel klikken en typen!
De oplossing?
GitHub Workflows en Actions.
GitHub Workflows en Actions zijn twee GitHub-functies waarmee gebruikers taken en workflows voor hun softwareontwikkelingprojecten kunnen automatiseren. Het helpt de gebruikers ervan tijd te besparen, de kwaliteit te verbeteren en en het helpt om effectiever samen te werken. Een geschikte oplossing dus om handmatige taken hierin te omzijlen?
Een GitHub Workflow is een reeks regels die definieert wanneer en hoe een bepaalde actie moet worden uitgevoerd. Zo kan een workflow code bouwen, tests uitvoeren, applicaties implementeren of meldingen verzenden, elke keer wanneer er een nieuwe commit wordt gepusht, een pullverzoek wordt geopend, of een gepland evenement plaatsvindt. Kortom, een waardevolle aanvulling je Cloud Native Azure omgeving!
Een GitHub Action is een herbruikbare code om een specifieke taak uit te voeren binnen een workflow. Zo kan een ‘actie’ een repository uitchecken, afhankelijkheden installeren, een script uitvoeren, of een artifact uploaden. Acties kunnen worden geschreven in elke programmeertaal en kunnen elk hulpmiddel of framework gebruiken. Acties worden gemaakt door GitHub, door de community, of door de gebruikers zelf. Acties worden opgeslagen in repositories en kunnen worden gerefereerd door workflows met behulp van de syntax owner/repo@ref.
Enkele voordelen van het gebruik van GitHub Workflows en Actions zijn:
Een voorbeeld van een ‘use case’ voor Github Actions is die van een geautomatiseerde workflow voor het bouwen, scannen, patchen, pushen en implementeren van containers. Dit kan developers helpen om het leveren van veilige en betrouwbare gecontaineriseerde applicaties versimpelen.
Stap 1: De eerste stap is het creëren van een Dockerfile die definieert hoe het containerbeeld voor die toepassing gebouwd moet worden. De Dockerfile specificeert het basisbeeld, de afhankelijkheden, de commando's, en de omgevingsvariabelen voor de container. De Dockerfile moet worden opgeslagen in de repository samen met de code.
Stap 2: Creëer de workflow. Om een GitHub-workflowbestand te maken dat de stappen definieert die moeten worden uitgevoerd wanneer bepaalde gebeurtenissen optreden in de repository, (zoals een push of een pull request) wordt het workflow bestand geschreven in YAML en opgeslagen in de .github/workflows map van het repository. Het workflowbestand kan de triggers, de taken, de runners, en de acties voor de workflow specificeren.
Stap 3: Gebruik GitHub Actions om het containerbeeld te bouwen vanuit de Dockerfile: Dit kan worden gedaan met de docker/build-push-action actie, die het beeld kan bouwen en taggen, inloggen op een containerregister, en het beeld naar het register kan pushen. De actie kan ook de beeldlagen cachen om de volgende builds te versnellen. De actie vereist enkele invoer, zoals de naam van het beeld, de contextdirectory, het pad naar de Dockerfile, en de referenties van het register.
Stap 4: Scan je containerimages op kwetsbaarheden, via Trivy. Dat is een tool die kwetsbaarheden in het beeld kan detecteren. Dit kan via de aquasecurity/trivy-action actie, die Trivy kan uitvoeren op het beeld en een kwetsbaarhedenrapport kan genereren. De actie kan ook de workflow laten mislukken als het beeld kritieke of hoog-ernstige kwetsbaarheden heeft. De actie vereist enkele invoer, zoals de naam van het beeld en het ernstniveau, om te mislukken.
Stap 5: Als kwetsbaarheden worden gevonden, willen we het beeld patchen (vergeet niet om de kwetsbaarheid in de code te herstellen voor je volgende release!). Om het beeld te patchen, gebruiken we Copa, een tool die patches kan toepassen op het beeld zonder het opnieuw te bouwen. Dit kan via de actie copa/copa-action, die Copa kan uitvoeren op het beeld en een gepatcht beeld kan maken. Deze actie kan ook het gepatchte beeld naar het register pushen. De actie vereist enkele invoer, zoals de naam van het originele beeld, de naam van het gepatchte beeld, en de referenties voor het register.
Stap 6: Tenslotte de implementatie. Dit kan worden gedaan door de Azure/k8s-deploy actie te gebruiken, die het beeld naar een gespecificeerde AKS-cluster en namespace kan implementeren. Deze actie kan tevens Kubernetes-resources maken of bijwerken, zoals implementaties, services en geheimen. De actie vereist wel meerdere invoering, zoals bijvoorbeeld de naam van het beeld, de naam van de cluster, de naam van de namespace en de referenties voor de cluster.
Hopelijk heeft het bovenstaande je geholpen om meer over Github Workflow en Actions te weten te komen. We hebben uitgelegd hoe het je kan ondersteunen, en illustreerden aan de hand van een user case welke stappen een hierbij een rol spelen.
Zoals je ziet gaat het zeker om een flink aantal stappen, maar geen zorgen, Mocht je geïnteresseerd zijn in het bouwen en implementeren van een vergelijkbare oplossing en wat hulp nodig hebben, dan zijn we er voor je. Ons team te allen tijde voor je klaar!
We kunnen je begeleiden bij het starten van dit proces en voorbeelden van workflows bieden die je kunt aanpassen. Aarzel niet om contact met ons op te nemen. Onze experts helpen je graag!
Leer alles over Github Security in ons nieuwste e-book!
Download het e-book