Offres groupées d’applications natives cloud

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 livré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 métalliques avec accélération GPU matérielle. Aucune des deux applications natives cloud n’est la même, il est donc difficile de fournir un mécanisme unique pour les expédier.

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 générées à l’aide d’Ansible. Il s’agit d’une grande variété de technologies et il n’y a pas eu de moyen de les empaqueter ensemble dans un package raisonnable. Jusqu’à maintenant.

Cloud Native Application Bundles (CNABs) sont un effort conjoint de nombreuses entreprises d’esprit communautaire telles que Microsoft, Docker et HashiCorp pour développer une spécification pour empaqueter des applications distribuées.

L’effort a été annoncé en décembre 2018, il y a donc encore un peu de travail à faire pour exposer l’effort à la 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 un effort conjoint entre Docker et Microsoft.

Les CNAB peuvent contenir différents types de technologies d’installation. Cet aspect permet aux éléments tels que Helm Charts, 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 CNAB est un fichier appelé bundle.json. Ce fichier définit le contenu du bundle, qu'il s'agisse de Terraform, d'images ou d'autres éléments quelconques. 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 Terraform. En cas d’empaquetage, 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 exécuter 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

bundle.json définit également un ensemble de paramètres passés dans Terraform. Le paramétrage de l’offre groupée permet l’installation dans différents environnements.

Le format CNAB est également flexible, ce qui lui permet d’être utilisé sur n’importe quel cloud. Il peut même être utilisé sur des solutions locales telles que OpenStack.

Décisions DevOps

Il y a tellement d’outils formidables dans l’espace DevOps ces jours-ci et encore plus fantastiques livres et papiers sur la façon de réussir. Un livre favori pour commencer le parcours DevOps est The Phoenix Project, qui suit la transformation d’une société fictive de NoOps à DevOps. Une chose est pour certain : DevOps n’est plus un « bon à avoir » lors du déploiement d’applications natives cloud complexes. Il s’agit d’une exigence et doit être planifiée et mise en ressources au début d’un projet.

références

• Azure DevOps
• Azure Resource Manager
• Terraform
• Azure CLI