Cloud-native Anwendungsbündel

Eine wichtige Eigenschaft von cloudeigenen Anwendungen besteht darin, dass sie die Funktionen der Cloud nutzen, um die Entwicklung zu beschleunigen. Dieses Design bedeutet oft, dass eine vollständige Anwendung verschiedene Arten von Technologien verwendet. Anwendungen können in Docker-Containern ausgeliefert werden, einige Dienste verwenden möglicherweise Azure-Funktionen, während andere Teile möglicherweise direkt auf virtuellen Computern ausgeführt werden, die auf großen Metallservern mit Hardware-GPU-Beschleunigung zugeordnet sind. Keine zwei cloudeigenen Anwendungen sind identisch, daher war es schwierig, einen einzigen Mechanismus zum Versand bereitzustellen.

Die Docker-Container können auf Kubernetes mit einem Helm-Chart für die Bereitstellung ausgeführt werden. Die Azure-Funktionen können mithilfe von Terraform-Vorlagen zugewiesen werden. Schließlich können die virtuellen Maschinen mithilfe von Terraform zugewiesen werden, aber mit Ansible aufgebaut werden. Dies ist eine vielzahl von Technologien, und es gab keine Möglichkeit, sie alle zusammen in ein vernünftiges Paket zu packen. Allerdings nur bis jetzt.

Cloud Native Application Bundles (CNABs) sind gemeinsame Anstrengungen vieler communityorientierter Unternehmen wie Microsoft, Docker und HashiCorp, um eine Spezifikation für verteilte Anwendungen zu entwickeln.

Die Bemühungen wurden im Dezember 2018 angekündigt, daher gibt es noch einiges an Arbeit zu tun, um die Bemühungen der breiteren Gemeinschaft näherzubringen. Es gibt jedoch bereits eine offene Spezifikation und eine Referenzimplementierung, die als Duffle bezeichnet wird. Dieses Tool, das in Go geschrieben wurde, ist ein gemeinsamer Aufwand zwischen Docker und Microsoft.

Die CNABs können verschiedene Arten von Installationstechnologien enthalten. Dieser Aspekt ermöglicht es Dingen wie Helm Charts, Terraform-Vorlagen und Ansible Playbooks, in demselben Paket koexistieren zu können. Nach der Erstellung sind die Pakete eigenständig und portierbar; sie können über einen USB-Stick installiert werden. Die Pakete werden kryptografisch signiert, um sicherzustellen, dass sie von der Partei stammen, die sie beanspruchen.

Der Kern eines CNAB ist eine Datei namens bundle.json. Diese Datei definiert den Inhalt des Bündels, sei es Terraform oder Bilder oder etwas anderes. Abbildung 11-9 definiert ein CNAB, das einige Terraform-Inhalte aufruft. Beachten Sie jedoch, dass es tatsächlich ein Aufrufbild definiert, das zum Aufrufen der Terraform verwendet wird. Beim Packen ist die Docker-Datei, die sich im cnab-Verzeichnis befindet, in ein Docker-Image integriert, das im Bundle enthalten ist. Das Installieren von Terraform in einem Docker-Container im Bundle bedeutet, dass Benutzer Terraform nicht auf ihrem Computer installiert haben müssen, um die Bündelung auszuführen.

{
    "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
        }
    }
}

Abbildung 10-18 – Beispiel einer Terraform-Datei

Die bundle.json definiert auch eine Reihe von Parametern, die an den Terraform-Inhalt übergeben werden. Die Parametrisierung des Bundles ermöglicht die Installation in verschiedenen Umgebungen.

Das CNAB-Format ist auch flexibel, sodass es für jede Cloud verwendet werden kann. Sie kann sogar für lokale Lösungen wie OpenStack verwendet werden.

DevOps-Entscheidungen

Es gibt so viele großartige Tools im DevOps-Raum in diesen Tagen und noch fantastischer Bücher und Papiere darüber, wie man erfolgreich ist. Ein Lieblingsbuch für die ersten Schritte auf der DevOps-Reise ist The Phoenix Project, das der Transformation eines fiktiven Unternehmens von NoOps zu DevOps folgt. Eine Sache ist sicher: DevOps ist nicht mehr ein "schön zu haben", wenn komplexe, cloud native Anwendungen bereitgestellt werden. Es ist eine Anforderung und sollte zu Beginn eines Projekts geplant und ressourceniert werden.

Verweise

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