Aplikační komplety nativní pro cloud
Tip
Tento obsah je výňatek z eBooku, Architekting Cloud Native .NET Applications for Azure, který je k dispozici na webu Docs pro .NET nebo jako soubor PDF zdarma ke stažení, který si můžete přečíst offline.
Klíčovou vlastností aplikací nativních pro cloud je, že ke zrychlení vývoje využívají možnosti cloudu. Tento návrh často znamená, že úplná aplikace používá různé druhy technologií. Aplikace se můžou dodávat v kontejnerech Dockeru, některé služby můžou používat Azure Functions, zatímco jiné části můžou běžet přímo na virtuálních počítačích přidělených na velkých kovových serverech s hardwarovou akcelerací GPU. Žádné dvě aplikace nativní pro cloud nejsou stejné, takže je obtížné poskytnout jediný mechanismus pro jejich odeslání.
Kontejnery Dockeru se můžou spouštět v Kubernetes pomocí chartu Helm pro nasazení. Funkce Azure Functions se můžou přidělovat pomocí šablon Terraformu. Nakonec se virtuální počítače můžou přidělovat pomocí Terraformu, ale sestavené pomocí Ansible. Jedná se o širokou škálu technologií a neexistuje způsob, jak je všechny zabalit do rozumného balíčku. Tato chvíle přichází nyní.
Balíčky cloudových nativních aplikací (CNABs) jsou společným úsilím mnoha společností založených na komunitě, jako jsou Microsoft, Docker a HashiCorp, a vyvíjejí specifikaci pro zabalení distribuovaných aplikací.
Úsilí bylo oznámeno v prosinci 2018, takže stále existuje poměrně málo práce, které by se daly zpřístupnit úsilí větší komunitě. Existuje však otevřená specifikace a referenční implementace označovaná jako Duffle. Tento nástroj, který byl napsán v Go, je společným úsilím mezi Dockerem a Microsoftem.
CNAB mohou obsahovat různé druhy instalačních technologií. Tento aspekt umožňuje, jako jsou charty Helm, šablony Terraformu a playbooky Ansible, společně existovat ve stejném balíčku. Po sestavení jsou balíčky samostatné a přenosné; mohou být nainstalovány z USB flash disku. Balíčky jsou kryptograficky podepsané, aby se zajistilo, že pocházejí ze strany, kterou si vyžádají.
Jádrem CNAB je soubor s názvem bundle.json
. Tento soubor definuje obsah sady, ať už terraform, obrázky nebo cokoli jiného. Obrázek 11–9 definuje CNAB, který vyvolá nějaký Terraform. Všimněte si však, že ve skutečnosti definuje vyvolání image, která se používá k vyvolání Terraformu. Při zabalení je soubor Dockeru, který se nachází v adresáři cnab , integrovaný do image Dockeru, která bude součástí sady. Když je Terraform nainstalovaný uvnitř kontejneru Dockeru v sadě prostředků, znamená to, že uživatelé nemusí mít na svém počítači nainstalovaný Terraform, aby mohli spouštět sdružování.
{
"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
}
}
}
Obrázek 10–18 – ukázkový soubor Terraformu
Definuje bundle.json
také sadu parametrů, které se předávají do Terraformu. Parametrizace sady umožňuje instalaci v různých prostředích.
Formát CNAB je také flexibilní a umožňuje ho používat pro jakýkoli cloud. Dá se dokonce použít pro místní řešení, jako je OpenStack.
Rozhodnutí o DevOps
V těchto dnech je v devOps tolik skvělých nástrojů a ještě více fantastických knih a dokumentů o tom, jak uspět. Oblíbenou knihou, která začíná na cestě DevOps, je Phoenix Project, který sleduje transformaci fiktivní společnosti z NoOps na DevOps. Jedna věc je pro jistotu: DevOps už není při nasazování složitých aplikací nativních pro cloud "příjemné". Je to požadavek a měl by být naplánován a měl by být naplánován na začátku libovolného projektu.