Pakiety aplikacji natywnych dla chmury

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. 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 bardziej uwidocznić go szerszej 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 mogą zawierać różne rodzaje technologii instalacji. Ten aspekt umożliwia współistnienie takich elementów jak Helm Charts, szablony Terraform i playbooki Ansible w tym samym pakiecie. Po zbudowaniu pakiety są samodzielne i przenośne, można je zainstalować z pendrive'a. Pakiety są podpisane kryptograficznie, aby upewnić się, że pochodzą one od podmiotu, który deklarują.

Rdzeniem CNAB jest plik o nazwie bundle.json. Ten plik definiuje zawartość pakietu, czyli Terraform, obrazy lub inne treści. Rysunek 11-9 definiuje CNAB, który wywołuje Terraform. Należy jednak zauważyć, że faktycznie definiuje obraz wywołania, który jest używany do wywoływania narzędzia Terraform. Gdy plik Dockera znajdujący się w katalogu cnab zostanie spakowany, jest on zbudowany jako obraz Dockera, który zostanie dołączony do pakietu. 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ą, od której można rozpocząć podróż DevOps, jest The Phoenix Project, która opowiada o transformacji fikcyjnej firmy od NoOps do DevOps. Jedno jest pewne: Metodyka DevOps nie jest już tylko dodatkową korzyścią podczas wdrażania złożonych aplikacji natywnych dla chmury. Jest to wymaganie i powinno się zaplanować oraz zabezpieczyć zasoby na początku dowolnego projektu.

Źródła

• Azure DevOps
• Menedżer Zasobów Azure
• Terraform
• Interfejs wiersza polecenia platformy Azure