Molnbaserade programpaket
Dricks
Det här innehållet är ett utdrag från eBook, Architecting Cloud Native .NET Applications for Azure, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
En viktig egenskap för molnbaserade program är att de utnyttjar molnets funktioner för att påskynda utvecklingen. Den här designen innebär ofta att ett fullständigt program använder olika typer av tekniker. Program kan levereras i Docker-containrar, vissa tjänster kan använda Azure Functions, medan andra delar kan köras direkt på virtuella datorer som allokerats på stora metallservrar med GPU-maskinvaruacceleration. Inga två molnbaserade program är desamma, så det har varit svårt att tillhandahålla en enda mekanism för att skicka dem.
Docker-containrarna kan köras på Kubernetes med hjälp av ett Helm-diagram för distribution. Azure Functions kan allokeras med Hjälp av Terraform-mallar. Slutligen kan de virtuella datorerna allokeras med Terraform men byggas ut med Ansible. Detta är en stor mängd olika tekniker och det har inte funnits något sätt att paketera dem alla i ett rimligt paket. Förrän nu.
Cloud Native Application Bundles (CNAB) är en gemensam insats av många community-sinnade företag som Microsoft, Docker och HashiCorp för att utveckla en specifikation för att paketera distribuerade program.
Insatsen tillkännagavs i december 2018, så det finns fortfarande en hel del arbete att göra för att exponera ansträngningen för det större samhället. Det finns dock redan en öppen specifikation och en referensimplementering som kallas Duffle. Det här verktyget, som skrevs i Go, är en gemensam insats mellan Docker och Microsoft.
CNAB:erna kan innehålla olika typer av installationstekniker. Med den här aspekten kan saker som Helm-diagram, Terraform-mallar och Ansible-spelböcker samexistera i samma paket. När de har byggts är paketen fristående och bärbara. de kan installeras från ett USB-minne. Paketen är kryptografiskt signerade för att säkerställa att de kommer från den part som de hävdar.
Kärnan i en CNAB är en fil med namnet bundle.json. Den här filen definierar innehållet i paketet, oavsett om det är Terraform eller bilder eller något annat. Bild 11-9 definierar en CNAB som anropar vissa Terraform. Observera dock att den faktiskt definierar en anropsbild som används för att anropa Terraform. När den paketeras är Docker-filen som finns i cnab-katalogen inbyggd i en Docker-avbildning, som kommer att ingå i paketet. Att terraform har installerats i en Docker-container i paketet innebär att användarna inte behöver ha Terraform installerat på sin dator för att köra paketering.
{
"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
}
}
}
Bild 10-18 – Ett exempel på Terraform-fil
Definierar bundle.json också en uppsättning parametrar som skickas ned till Terraform. Parameterisering av paketet möjliggör installation i olika miljöer.
CNAB-formatet är också flexibelt, vilket gör att det kan användas mot alla moln. Det kan även användas mot lokala lösningar som OpenStack.
DevOps-beslut
Det finns så många bra verktyg i DevOps utrymme dessa dagar och ännu mer fantastiska böcker och papper om hur man lyckas. En favoritbok att komma igång med DevOps-resan är The Phoenix Project, som följer omvandlingen av ett fiktivt företag från NoOps till DevOps. En sak är säker: DevOps är inte längre ett "trevligt att ha" när du distribuerar komplexa, molnbaserade program. Det är ett krav och bör planeras för och resurshanteras i början av alla projekt.
