Pakiety aplikacji natywnych dla chmury
Napiwek
Ta zawartość jest fragmentem książki eBook, Architekting Cloud Native .NET Applications for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.
Kluczową właściwością aplikacji natywnych dla chmury jest wykorzystanie możliwości chmury w celu przyspieszenia opracowywania. Ten projekt często oznacza, że pełna aplikacja używa różnych rodzajów technologii. Aplikacje mogą być dostarczane w kontenerach platformy Docker, niektóre usługi mogą korzystać z usługi Azure Functions, podczas gdy inne części mogą być uruchamiane bezpośrednio na maszynach wirtualnych przydzielonych na dużych serwerach metalowych ze sprzętowym przyspieszeniem procesora GPU. Żadne dwie aplikacje natywne dla chmury nie są takie same, więc trudno było zapewnić jeden mechanizm ich wysyłania.
Kontenery platformy Docker mogą być uruchamiane na platformie Kubernetes przy użyciu pakietu Helm Chart do wdrożenia. Usługę Azure Functions można przydzielić przy użyciu szablonów programu Terraform. Na koniec maszyny wirtualne mogą być przydzielane przy użyciu narzędzia Terraform, ale utworzone przy użyciu rozwiązania Ansible. Jest to duża różnorodność technologii i nie było możliwości spakowania ich wszystkich razem w rozsądny pakiet. Aż do tej pory.
Pakiety aplikacji natywnych dla chmury (CNAB) to wspólne wysiłki wielu firm, takich jak Microsoft, Docker i HashiCorp w celu opracowania specyfikacji dla aplikacji rozproszonych.
Wysiłek został ogłoszony w grudniu 2018 r., więc nadal jest sporo pracy do zrobienia, aby odsłonić wysiłki na rzecz większej społeczności. Jednak istnieje już otwarta specyfikacja i implementacja referencyjna znana jako Duffle. To narzędzie, które zostało napisane w języku Go, jest wspólnym wysiłkiem między platformą Docker i firmą Microsoft.
CNAB może zawierać różne rodzaje technologii instalacji. Ten aspekt umożliwia współistnienie elementów takich jak Helm Charts, Szablony programu Terraform i podręczniki rozwiązania Ansible. Po skompilowanych pakietach są samodzielne i przenośne; Można je zainstalować z pamięci USB. Pakiety są podpisane kryptograficznie, aby upewnić się, że pochodzą one ze strony, której żądają.
Rdzeniem CNAB jest plik o nazwie bundle.json
. Ten plik definiuje zawartość pakietu, czyli terraform, obrazy lub inne elementy. Rysunek 11-9 definiuje CNAB, który wywołuje niektóre narzędzia Terraform. Należy jednak zauważyć, że faktycznie definiuje obraz wywołania, który jest używany do wywoływania narzędzia Terraform. Po spakowanym pliku platformy Docker znajdującego się w katalogu cnab jest wbudowany w obraz platformy Docker, który zostanie uwzględniony w pakiecie. Zainstalowanie narzędzia Terraform w kontenerze platformy Docker w pakiecie oznacza, że użytkownicy nie muszą mieć zainstalowanego programu Terraform na swojej maszynie, aby uruchomić pakiet.
{
"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
}
}
}
Rysunek 10–18 — przykładowy plik Terraform
Element bundle.json
definiuje również zestaw parametrów przekazywanych do narzędzia Terraform. Parametryzacja pakietu umożliwia instalację w różnych środowiskach.
Format CNAB jest również elastyczny, co pozwala na korzystanie z niej w dowolnej chmurze. Można go nawet używać w przypadku rozwiązań lokalnych, takich jak OpenStack.
Decyzje metodyki DevOps
Istnieje tak wiele wspaniałych narzędzi w przestrzeni DevOps w dzisiejszych czasach, a jeszcze więcej fantastycznych książek i dokumentów na temat tego, jak odnieść sukces. Ulubioną książką, którą można rozpocząć w podróży DevOps, jest The Phoenix Project, która następuje po transformacji fikcyjnej firmy z NoOps do metodyki DevOps. Jedną z rzeczy jest pewne: Metodyka DevOps nie jest już "miła do posiadania" podczas wdrażania złożonych aplikacji natywnych dla chmury. Jest to wymaganie i powinno być planowane i zasób na początku dowolnego projektu.