Bundles d’applications cloud natives
Conseil
Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.
Une propriété clé des applications natives cloud est qu’elles tirent parti des fonctionnalités du cloud pour accélérer le développement. Cette conception signifie souvent qu’une application complète utilise différents types de technologies. Les applications peuvent être distribuées dans des conteneurs Docker, certains services peuvent utiliser Azure Functions, tandis que d’autres parties peuvent s’exécuter directement sur des machines virtuelles allouées sur de grands serveurs nus avec accélération GPU matérielle. Aucune des deux applications natives cloud n’étant la même, il est difficile de fournir un mécanisme unique pour les distribuer.
Les conteneurs Docker peuvent s’exécuter sur Kubernetes à l’aide d’un graphique Helm pour le déploiement. Azure Functions peut être alloué à l’aide de modèles Terraform. Enfin, les machines virtuelles peuvent être allouées à l’aide de Terraform, mais crées à l’aide d’Ansible. Il existe une grande variété de technologies et il n’y avait aucun moyen de les regrouper dans un package raisonnable jusqu’à présent.
Les bundles d’applications cloud natives ont été développés dans le cadre d’un effort conjoint par plusieurs entreprises animées d’un esprit communautaire telles que Microsoft, Docker et HashiCorp afin de définir une spécification pour empaqueter des applications distribuées.
Ce projet ayant fait l’objet d’une annonce en décembre 2018, il y a donc encore un peu de travail à faire pour accroître son exposition auprès d’une plus grande communauté. Toutefois, il existe déjà une spécification ouverte et une implémentation de référence appelée Duffle. Cet outil, écrit en Go, est le fruit d’une collaboration entre Docker et Microsoft.
Les bundles d’applications cloud natives peuvent contenir différents types de technologies d’installation. Cet aspect permet aux éléments tels que les graphiques Helm, les modèles Terraform et les playbooks Ansible de coexister dans le même package. Une fois générés, les packages sont autonomes et portables. Ils peuvent être installés à partir d’une clé USB. Les packages sont signés par chiffrement pour s’assurer qu’ils proviennent de la partie qu’ils prétendent.
Le cœur d’un bundle d’applications cloud natives est un fichier appelé bundle.json. Ce fichier définit le contenu du bundle, qu’il s’agisse de modèles Terraform, d’images ou de tout autre élément. La figure 11-9 définit un bundle d’applications cloud natives qui appelle un modèle Terraform. Notez toutefois qu’il définit en fait une image d’appel utilisée pour appeler le modèle Terraform. Une fois empaqueté, le fichier Docker situé dans le répertoire cnab est intégré à une image Docker, qui sera incluse dans le bundle. L’installation de Terraform à l’intérieur d’un conteneur Docker dans le bundle signifie que les utilisateurs n’ont pas besoin d’installer Terraform sur leur ordinateur pour effectuer le regroupement.
{
"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
}
}
}
Figure 10-18 - Exemple de fichier Terraform
Le bundle.json définit également un ensemble de paramètres transmis au modèle Terraform. Le paramétrage du bundle permet l’installation dans différents environnements.
Le format du bundle d’applications cloud natives est également flexible, ce qui permet de l’utiliser sur n’importe quel cloud. Il peut même être utilisé sur des solutions locales telles que OpenStack.
Décisions DevOps
Il y a tant d’outils formidables dans l’espace DevOps aujourd’hui, et des ouvrages et articles fantastiques sur la façon de réussir. The Phoenix Project est un ouvrage de référence pour se lancer dans un parcours DevOps. Celui-ci suit la transformation d’une société fictive du stade NoOps au stade DevOps. Une chose est toutefois certaine : les DevOps ne sont plus un simple « plus » dans le cadre du déploiement d’applications natives cloud complexes. Il s’agit d’un impératif qui doit être planifié et doté en ressources au début d’un projet.
