Cloud Native Application Bundles
Tip
Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.
Een belangrijke eigenschap van cloudtoepassingen is dat ze gebruikmaken van de mogelijkheden van de cloud om de ontwikkeling te versnellen. Dit ontwerp betekent vaak dat een volledige toepassing gebruikmaakt van verschillende soorten technologieën. Toepassingen kunnen worden verzonden in Docker-containers, sommige services kunnen Gebruikmaken van Azure Functions, terwijl andere onderdelen rechtstreeks kunnen worden uitgevoerd op virtuele machines die zijn toegewezen op grote metalen servers met hardware GPU-versnelling. Er zijn geen twee cloudtoepassingen hetzelfde, dus het is moeilijk geweest om één mechanisme te bieden voor het verzenden ervan.
De Docker-containers kunnen worden uitgevoerd op Kubernetes met behulp van een Helm-grafiek voor implementatie. De Azure Functions kan worden toegewezen met behulp van Terraform-sjablonen. Ten slotte kunnen de virtuele machines worden toegewezen met behulp van Terraform, maar zijn gebouwd met Behulp van Ansible. Dit is een grote verscheidenheid aan technologieën en er is geen manier om ze allemaal samen in een redelijk pakket te verpakken. Tot nu.
Cloud Native Application Bundles (CNABs) zijn een gezamenlijke inspanning van veel communitygerichte bedrijven zoals Microsoft, Docker en HashiCorp om een specificatie te ontwikkelen voor gedistribueerde toepassingen.
De inspanningen zijn aangekondigd in december 2018, dus er is nog steeds een behoorlijke hoeveelheid werk te doen om de inspanningen aan de grotere gemeenschap bloot te leggen. Er is echter al een open specificatie en een referentie-implementatie die bekend staat als Duffle. Dit hulpprogramma, dat in Go is geschreven, is een gezamenlijke inspanning tussen Docker en Microsoft.
De CNABs kunnen verschillende soorten installatietechnologieën bevatten. Met dit aspect kunnen bijvoorbeeld Helm-grafieken, Terraform-sjablonen en Ansible-playbooks naast elkaar worden gebruikt in hetzelfde pakket. Eenmaal gebouwd, zijn de pakketten zelfstandig en draagbaar; ze kunnen worden geïnstalleerd vanaf een USB-stick. De pakketten worden cryptografisch ondertekend om ervoor te zorgen dat ze afkomstig zijn van de partij die ze claimen.
De kern van een CNAB is een bestand met de naam bundle.json. Dit bestand definieert de inhoud van de bundel, of het nu Terraform of afbeeldingen zijn of iets anders. Afbeelding 11-9 definieert een CNAB die terraform aanroept. U ziet echter dat er daadwerkelijk een aanroepafbeelding wordt gedefinieerd die wordt gebruikt om terraform aan te roepen. Wanneer het is verpakt, wordt het Docker-bestand dat zich in de cnab-map bevindt, ingebouwd in een Docker-installatiekopie, die in de bundel wordt opgenomen. Als Terraform is geïnstalleerd in een Docker-container in de bundel, betekent dit dat gebruikers Terraform niet hoeven te installeren op hun computer om de bundeling uit te voeren.
{
"name": "terraform",
"version": "0.1.0",
"schemaVersion": "v1.0.0-WD",
"parameters": {
"backend": {
"type": "boolean",
"defaultValue": false,
"destination": {
"env": "TF_VAR_backend"
}
}
},
"invocationImages": [
{
"imageType": "docker",
"image": "cnab/terraform:latest"
}
],
"credentials": {
"tenant_id": {
"env": "TF_VAR_tenant_id"
},
"client_id": {
"env": "TF_VAR_client_id"
},
"client_secret": {
"env": "TF_VAR_client_secret"
},
"subscription_id": {
"env": "TF_VAR_subscription_id"
},
"ssh_authorized_key": {
"env": "TF_VAR_ssh_authorized_key"
}
},
"actions": {
"status": {
"modifies": true
}
}
}
Afbeelding 10-18 - Een voorbeeld van een Terraform-bestand
Hiermee bundle.json definieert u ook een set parameters die worden doorgegeven aan Terraform. Met parameterisatie van de bundel kunnen verschillende omgevingen worden geïnstalleerd.
De CNAB-indeling is ook flexibel, zodat deze kan worden gebruikt voor elke cloud. Het kan zelfs worden gebruikt voor on-premises oplossingen zoals OpenStack.
DevOps-beslissingen
Er zijn tegenwoordig zoveel geweldige hulpprogramma's in de DevOps-ruimte en nog meer fantastische boeken en documenten over hoe ze kunnen slagen. Een favoriet boek om aan de slag te gaan met het DevOps-traject is The Phoenix Project, dat de transformatie volgt van een fictief bedrijf van NoOps naar DevOps. Een ding is zeker: DevOps is niet langer een 'leuk te hebben' bij het implementeren van complexe, cloudeigen toepassingen. Het is een vereiste en moet worden gepland voor en resource aan het begin van een project.
