Aggregazioni di applicazioni cloud native
Suggerimento
Questo contenuto è un estratto dell'eBook, Progettazione di applicazioni .NET native del cloud per Azure, disponibile in .NET Docs o come PDF scaricabile gratuitamente che può essere letto offline.
Una proprietà chiave delle applicazioni native del cloud è che sfruttano le funzionalità del cloud per velocizzare lo sviluppo. Questa progettazione spesso significa che un'applicazione completa usa diversi tipi di tecnologie. Le applicazioni possono essere fornite in contenitori Docker, alcuni servizi possono usare Funzioni di Azure, mentre altre parti possono essere eseguite direttamente nelle macchine virtuali allocate in server di grandi dimensioni con accelerazione GPU hardware. Non esistono due applicazioni native del cloud uguali, quindi è stato difficile fornire un unico meccanismo per la spedizione.
I contenitori Docker possono essere eseguiti in Kubernetes usando un grafico Helm per la distribuzione. È possibile allocare Funzioni di Azure usando i modelli Terraform. Infine, le macchine virtuali possono essere allocate usando Terraform, ma compilate usando Ansible. Si tratta di una grande varietà di tecnologie e non c'è stato modo di assemblarle tutti insieme in un pacchetto ragionevole. l'argomento.
I bundle di applicazioni native cloud (CNAB) sono uno sforzo congiunto di molte aziende basate sulla community, ad esempio Microsoft, Docker e HashiCorp, per sviluppare una specifica per creare pacchetti di applicazioni distribuite.
Lo sforzo è stato annunciato nel dicembre del 2018, quindi c'è ancora un bel po' di lavoro da fare per esporre lo sforzo alla comunità più grande. Tuttavia, esiste già una specifica aperta e un'implementazione di riferimento nota come Duffle. Questo strumento, scritto in Go, è uno sforzo congiunto tra Docker e Microsoft.
I CNAB possono contenere diversi tipi di tecnologie di installazione. Questo aspetto consente di far coesistere nello stesso pacchetto elementi come i grafici Helm, i modelli Terraform e i playbook Ansible. Una volta compilati, i pacchetti sono autonomi e portatili; possono essere installati da una chiavetta USB. I pacchetti sono firmati crittograficamente per assicurarsi che provengano dall'entità richiesta.
Il nucleo di un CNAB è un file denominato bundle.json. Questo file definisce il contenuto del bundle, ad esempio Terraform o immagini o qualsiasi altro elemento. La figura 11-9 definisce un CNAB che richiama alcuni Terraform. Si noti, tuttavia, che in realtà definisce un'immagine di chiamata usata per richiamare Terraform. Quando viene creato un pacchetto, il file Docker che si trova nella directory cnab viene integrato in un'immagine Docker, che verrà inclusa nel bundle. Dopo aver installato Terraform all'interno di un contenitore Docker nel bundle, gli utenti non devono avere Terraform installato nel computer per eseguire il bundle.
{
"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
}
}
}
Figura 10-18 - File Terraform di esempio
bundle.json definisce anche un set di parametri passati in Terraform. La parametrizzazione del bundle consente l'installazione in diversi ambienti.
Il formato CNAB è anche flessibile, consentendone l'uso in qualsiasi cloud. Può anche essere usato in soluzioni locali, ad esempio OpenStack.
Decisioni DevOps
Al giorno d'oggi esistono tantissimi strumenti eccellenti nello spazio DevOps e un numero ancora maggiore di libri e documenti fantastici su come avere successo. Uno dei libri preferiti per iniziare il percorso DevOps è The Phoenix Project, che segue la trasformazione di un'azienda fittizia da NoOps a DevOps. Una cosa è certa: DevOps non è più una cosa "utile da avere" quando si distribuiscono applicazioni cloud native complesse. È un requisito e deve essere pianificato e dotato di risorse all'inizio di qualsiasi progetto.
