Przygotowywanie zasobów technicznych kontenera platformy Azure dla aplikacji Kubernetes

Ten artykuł zawiera zasoby techniczne i zalecenia ułatwiające utworzenie oferty kontenera na Azure Marketplace dla aplikacji Kubernetes.

Aby zapoznać się z kompleksowym przykładem zasobów technicznych wymaganych dla oferty kontenera opartej na aplikacji Kubernetes, zobacz Azure Marketplace przykłady ofert kontenera dla platformy Kubernetes.

Podstawowa wiedza techniczna

Projektowanie, kompilowanie i testowanie tych zasobów zajmuje trochę czasu i wymaga wiedzy technicznej zarówno platformy Azure, jak i technologii używanych do tworzenia oferty.

Oprócz domeny rozwiązania zespół inżynierów powinien mieć wiedzę na temat następujących technologii firmy Microsoft:

Wymagania wstępne

  • Aplikacja musi być oparta na wykresie helm.

  • Wszystkie odwołania do obrazu i szczegóły skrótu muszą być uwzględnione na wykresie. W czasie wykonywania nie można pobrać żadnych dodatkowych wykresów ani obrazów.

  • Musisz mieć aktywną dzierżawę publikowania lub dostęp do dzierżawy publikowania i konta Centrum partnerskiego.

  • Musisz utworzyć Azure Container Registry (ACR), do którego przekażesz pakiet aplikacji natywnej w chmurze (CNAB) i przyznasz uprawnienia do identyfikatora aplikacji firmy Microsoft w celu uzyskania dostępu do usługi ACR. Aby uzyskać więcej informacji, zobacz tworzenie Azure Container Registry.

  • Zainstaluj najnowszą wersję interfejsu wiersza polecenia platformy Azure.

  • Aplikacja musi być wdrażana w środowisku systemu Linux.

  • W przypadku ręcznego uruchamiania narzędzia do tworzenia pakietów CNAB konieczne będzie zainstalowanie platformy Docker na komputerze lokalnym.

Ograniczenia

  • Usługa Container Marketplace obsługuje tylko obrazy AMD64 oparte na platformie Linux.
  • Tylko zarządzana usługa AKS.
  • Pojedyncze kontenery nie są obsługiwane.
  • Połączone szablony usługi Azure Resource Manager nie są obsługiwane.

Ważne

Środowisko oferty oparte na aplikacji kubernetes jest dostępne w wersji zapoznawczej. Funkcje w wersji zapoznawczej są dostępne na zasadzie samoobsługi. Wersje zapoznawcze są udostępniane w wersji "as is" i "jako dostępne" i są wykluczone z umów dotyczących poziomu usług i ograniczonej gwarancji. Wersje zapoznawcze są częściowo objęte pomocą techniczną dla klientów. W związku z tym te funkcje nie są przeznaczone do użytku produkcyjnego.

Omówienie publikowania

Pierwszym krokiem do opublikowania oferty kontenera opartej na aplikacji Kubernetes w Azure Marketplace jest spakowanie aplikacji jako pakietu aplikacji natywnej dla chmury (CNAB). Ta usługa CNAB, składająca się z artefaktów aplikacji, zostanie po raz pierwszy opublikowana w prywatnej Azure Container Registry (ACR), a później wypchnięta do usługi ACR należącej do firmy Microsoft i będzie używana jako pojedynczy artefakt, do którego odwołujesz się w Centrum partnerskim.

Stamtąd skanowanie luk w zabezpieczeniach jest wykonywane w celu zapewnienia bezpieczeństwa obrazów. Na koniec aplikacja Kubernetes jest zarejestrowana jako typ rozszerzenia dla klastra Azure Kubernetes Service (AKS).

Po opublikowaniu oferty aplikacja będzie korzystać z rozszerzeń klastra dla usługi AKS w celu zarządzania cyklem życia aplikacji w klastrze usługi AKS.

Diagram przedstawiający trzy etapy przetwarzania pakietów, przepływające z

Udzielanie dostępu do Azure Container Registry

W ramach procesu publikowania firma Microsoft będzie kopiować nazwę CNAB z usługi ACR do należącej do firmy Microsoft, Azure Marketplace specyficznej dla usługi ACR. Ten krok wymaga udzielenia dostępu firmy Microsoft do rejestru.

Firma Microsoft utworzyła aplikację innej firmy odpowiedzialną za obsługę tego procesu za pomocą elementu id32597670-3e15-4def-8851-614ff48c1efa. Aby rozpocząć, utwórz jednostkę usługi na podstawie aplikacji:

Uwaga

Jeśli konto nie ma wystarczających uprawnień do utworzenia jednostki usługi, polecenie az ad sp create zwróci komunikat „Uprawnienia niewystarczające do ukończenia operacji”. Skontaktuj się z administratorem usługi Azure Active Directory w celu utworzenia jednostki usługi.

az login
az ad sp create --id 32597670-3e15-4def-8851-614ff48c1efa

Zanotuj identyfikator jednostki usługi, który ma być używany w poniższych krokach.

Następnie uzyskaj pełny identyfikator rejestru:

az acr show --name <registry-name> --query "id" --output tsv

Dane wyjściowe powinny wyglądać podobnie do następujących:

...
},
"id": "/subscriptions/ffffffff-ff6d-ff22-77ff-ffffffffffff/resourceGroups/myResourceGroup/providers/Microsoft.ContainerRegistry/registries/myregistry",
...

Następnie utwórz przypisanie roli, aby przyznać jednostce usługi możliwość ściągania z rejestru przy użyciu uzyskanych wcześniej wartości:

Aby przypisać role platformy Azure, musisz mieć następujące elementy:

az role assignment create --assignee <sp-id> --scope <registry-id> --role acrpull

Na koniec zarejestruj dostawcę Microsoft.PartnerCenterIngestion zasobów w tej samej subskrypcji użytej do utworzenia Azure Container Registry:

az provider register --namespace Microsoft.PartnerCenterIngestion --subscription <subscription-id> --wait

Przed kontynuowaniem monitoruj rejestrację i potwierdź jej ukończenie:

az provider show -n Microsoft.PartnerCenterIngestion --subscription <subscription-id>

Zbieranie artefaktów w celu spełnienia wymagań dotyczących formatu pakietu

Każdy CNAB będzie składać się z następujących artefaktów:

  • Wykres helm

  • CreateUiDefinition

  • Szablon ARM

  • Plik manifestu

Aktualizowanie wykresu programu Helm

Upewnij się, że pakiet Helm jest zgodny z następującymi regułami:

  • Wszystkie nazwy obrazów i odwołania są sparametryzowane i reprezentowane jako values.yaml odwołania global.azure.images. Zaktualizuj deployment.yaml , aby wskazać te obrazy. Dzięki temu blok obrazu może zostać zaktualizowany i przywołyany przez usługę ACR Azure Marketplace.

    Zostanie wyświetlony zrzut ekranu przedstawiający poprawnie sformatowany plik deployment.yaml. Wyświetlane są sparametryzowane odwołania do obrazu, podobne do zawartości w przykładowym pliku deployment.yaml połączonym w tym artykule.

  • Jeśli masz jakiekolwiek wykresy podrzędne, wyodrębnij zawartość w obszarze wykresów i zaktualizuj każde odwołanie do obrazu zależnego, aby wskazać obrazy zawarte w wykresie values.yamlgłównym .

  • Obrazy muszą używać skrótów zamiast tagów. Dzięki temu budynek CNAB jest deterministyczny.

    Zostanie wyświetlony zrzut ekranu przedstawiający poprawnie sformatowany plik values.yaml. Obrazy używają skrótów. Zawartość przypomina przykładowy plik values.yaml połączony w tym artykule.

Dostępne modele rozliczeń

Opcja licencjonowania Proces transakcji
Bezpłatna Podaj bezpłatną listę ofert klientom.
Bring your own licensing (BYOL) Opcja Bring Your Own Licensing umożliwia klientom przenoszenie istniejących licencji na oprogramowanie na platformę Azure.*
Na każdy rdzeń w klastrze Wyświetl ofertę kontenera platformy Azure z cenami naliczanymi na podstawie łącznej liczby rdzeni procesora CPU w klastrze (zgłaszanych z częstotliwością godzinową). Podasz cenę jednego rdzenia procesora CPU i będziemy zwiększać ceny na podstawie całkowitej liczby rdzeni procesora CPU w klastrze.
Na rdzeń Wyświetl ofertę kontenera platformy Azure z opłatami za każdy rdzeń używany przez wystąpienie rozszerzenia aplikacji Kubernetes (zgłaszane z częstotliwością godzinową). Podasz cenę dla jednego rdzenia procesora CPU i będziemy zwiększać ceny na podstawie rdzeni używanych przez wystąpienie aplikacji Kubernetes w klastrze.
Na klaster Wyświetl ofertę kontenera platformy Azure z opłatami za każde wystąpienie rozszerzenia aplikacji Kubernetes w klastrze (zgłaszane z częstotliwością godzinową). Podasz cenę dla jednego wystąpienia aplikacji Kubernetes i zwiększamy ceny na podstawie liczby wystąpień aplikacji Kubernetes w klastrze.
Na każdy węzeł w klastrze Wyświetl ofertę kontenera platformy Azure z cennikiem naliczonymi na podstawie całkowitej liczby węzłów w klastrze (zgłaszanej z częstotliwością godzinową). Podasz cenę dla jednego węzła w klastrze i zwiększamy ceny na podstawie rozmiaru sprzętu w klastrze.
Na węzeł Wyświetl ofertę kontenera platformy Azure z opłatami za każdy węzeł, na którym działa wystąpienie rozszerzenia aplikacji Kubernetes (zgłaszane z częstotliwością godzinową). Podasz cenę dla jednego węzła w klastrze i zwiększamy ceny na podstawie liczby węzłów, w których wystąpienie aplikacji Kubernetes działa w klastrze.
Na zasobnik Wyświetl ofertę kontenera platformy Azure z opłatami za każdy zasobnik, na którym działa wystąpienie rozszerzenia aplikacji Kubernetes (zgłaszane z częstotliwością godzinową). Podasz cenę dla jednego węzła w klastrze i zwiększamy ceny na podstawie liczby zasobników używanych w wystąpieniu aplikacji Kubernetes w klastrze.
  • Jako wydawca obsługujesz wszystkie aspekty transakcji licencji oprogramowania, w tym (ale nie tylko) zamówienie, realizacja, pomiary, rozliczenia, fakturowanie, płatność i zbieranie.

Wprowadzanie aktualizacji na podstawie modelu rozliczeniowego

Po przejrzeniu dostępnych modeli rozliczeniowych wybierz jeden odpowiedni dla twojego przypadku użycia i wykonaj następujące kroki:

Wykonaj następujące kroki, aby dodać identyfikator w modelu rozliczeń na rdzeń :

  • Dodaj etykietę identyfikatora rozliczeń i żądanie rdzeni procesora cpu do deployment.yaml pliku.

    Zrzut ekranu przedstawiający prawidłowo sformatowaną etykietę identyfikatora rozliczeń w pliku deployment.yaml. Zawartość przypomina przykładowy plik depoyment.yaml połączony w tym artykule

    Zrzut ekranu przedstawiający żądania zasobów procesora CPU w pliku deployment.yaml. Zawartość przypomina przykładowy plik depoyment.yaml połączony w tym artykule.

  • Dodaj wartość identyfikatora rozliczeń dla elementu global.azure.billingidentifier w pliku values.yaml.

    Zrzut ekranu przedstawiający poprawnie sformatowany plik values.yaml z globalnym polem > BillingIdentifier platformy Azure > .

Wykonaj następujące kroki, aby dodać etykietę identyfikatora rozliczeń w modelu rozliczeń Na zasobnik i Na węzeł :

  • Dodaj etykietę azure-extensions-usage-release-identifier identyfikatora rozliczeń do deployment.yaml pliku (w obszarzeEtykiety>metadanych szablonu>>).

Należy pamiętać, że w czasie wdrażania funkcja rozszerzeń klastra zastąpi wartość identyfikatora rozliczeń nazwą typu rozszerzenia podaną podczas konfigurowania szczegółów planu.

Aby zapoznać się z przykładami skonfigurowanymi do wdrożenia aplikacji Azure Voting, zobacz następujące kwestie:

Weryfikowanie wykresu helm

Aby upewnić się, że pakiet Helm jest prawidłowy, przetestuj, czy można go zainstalować w klastrze lokalnym. Można również użyć helm install --generate-name --dry-run --debug do wykrywania niektórych błędów generowania szablonu.

Tworzenie i testowanie elementu createUiDefinition

CreateUiDefinition to plik JSON, który definiuje elementy interfejsu użytkownika dla Azure Portal podczas wdrażania aplikacji. Aby uzyskać więcej informacji, zobacz CreateUiDefinition.json dla platformy Azure lub zobacz przykład definicji interfejsu użytkownika, która prosi o dane wejściowe dla nowego lub istniejącego wyboru klastra i przekazuje parametry do aplikacji.

Po utworzeniu pliku createUiDefinition.json dla aplikacji należy przetestować środowisko użytkownika. Aby uprościć testowanie, użyj środowiska piaskownicy , które ładuje plik w portalu. Piaskownica przedstawia interfejs użytkownika w bieżącym, pełnoekranowym środowisku portalu. Piaskownica jest zalecanym sposobem wyświetlania podglądu interfejsu użytkownika.

Tworzenie szablonu usługi Azure Resource Manager (ARM)

Szablon usługi ARM definiuje zasoby platformy Azure do wdrożenia. Wdrożysz zasób rozszerzenia klastra dla aplikacji Azure Marketplace. Opcjonalnie możesz wybrać wdrożenie klastra usługi AKS.

Obecnie zezwalamy tylko na następujące typy zasobów:

  • Microsoft.ContainerService/managedClusters

  • Microsoft.KubernetesConfiguration/extensions

Na przykład zobacz ten przykładowy szablon usługi ARM zaprojektowany do podejmowania wyników z przykładowej definicji interfejsu użytkownika połączonej powyżej i przekazywania parametrów do aplikacji.

Tworzenie pliku manifestu

Manifest pakietu to plik yaml opisujący pakiet i jego zawartość oraz informuje narzędzie do tworzenia pakietów, gdzie można zlokalizować zależne artefakty.

Pola używane w manifeście są następujące:

Nazwa Typ danych Opis
applicationName Ciąg Nazwa aplikacji
publisher Ciąg Nazwa wydawcy
description (opis) Ciąg Krótki opis pakietu
Wersja Ciąg w #.#.# formacie Ciąg wersji opisujący wersję pakietu aplikacji może lub nie jest zgodny z wersją plików binarnych wewnątrz. Mapowane na pole wersji portera
helmChart Ciąg Katalog lokalny, w którym można znaleźć wykres Helm względem tego manifest.yaml
clusterARMTemplate Ciąg Ścieżka lokalna, w której można znaleźć szablon usługi ARM opisujący klaster usługi AKS spełniający wymagania w polu ograniczenia.
uiDefinition Ciąg Ścieżka lokalna, w której można znaleźć plik JSON opisujący środowisko tworzenia Azure Portal
registryServer Ciąg Usługa ACR, w której należy wypchnąć końcowy pakiet CNAB
extensionRegistrationParameters Kolekcja Specyfikacja parametrów rejestracji rozszerzenia. Uwzględnij co najmniej defaultScope parametr i jako parametr.
defaultScope Ciąg Domyślny zakres instalacji rozszerzenia. Akceptowane wartości to cluster lub namespace. Jeśli cluster zakres jest ustawiony, dozwolone jest tylko jedno wystąpienie rozszerzenia na klaster. Jeśli namespace wybrano zakres, dozwolone jest tylko jedno wystąpienie dla przestrzeni nazw. Ponieważ klaster Kubernetes może mieć wiele przestrzeni nazw, wiele wystąpień rozszerzenia może istnieć.
namespace Ciąg (Opcjonalnie) Określ przestrzeń nazw instalowaną w rozszerzeniu. Ta właściwość jest wymagana, gdy defaultScope jest ustawiona na clusterwartość . Aby uzyskać ograniczenia nazewnictwa przestrzeni nazw, zobacz Przestrzenie nazw i SYSTEM DNS.

Przykład skonfigurowany dla aplikacji do głosowania można znaleźć w poniższym przykładzie pliku manifestu.

Przepływ parametrów użytkownika

Ważne jest, aby zrozumieć, jak parametry użytkownika przepływają w artefaktach tworzonych i pakujących. Parametry są początkowo definiowane podczas tworzenia interfejsu użytkownika za pomocą pliku createUiDefinition.json :

Zrzut ekranu przedstawiający przykład createUiDefinition połączony w tym artykule. Wyświetlane są definicje wartości

Uwaga

W tym przykładzie extensionResourceName jest również sparametryzowany i przekazywany do zasobu rozszerzenia klastra. Podobnie można sparametryzować inne właściwości rozszerzenia, takie jak włączanie automatycznego uaktualniania dla wersji pomocniczych. Aby uzyskać więcej informacji na temat właściwości rozszerzenia klastra, zobacz parametry opcjonalne.

i są eksportowane za pośrednictwem outputs sekcji:

Zrzut ekranu przedstawiający przykład createUiDefinition połączony w tym artykule. Wyświetlane są wiersze wyjściowe tytułu aplikacji,

Z tego miejsca wartości są przekazywane do szablonu usługi Azure Resource Manager i będą propagowane do wykresu helm podczas wdrażania:

Zrzut ekranu przedstawiający przykład szablonu usługi Azure Resource Manager połączony w tym artykule. W obszarze

Na koniec wartości są używane przez wykres Helm:

Zrzut ekranu przedstawiający przykład wykresu helm połączony w tym artykule. Wyświetlane są wartości tytułu aplikacji,

Struktura aplikacji

Umieść plik createUiDefinition, szablon usługi ARM i plik manifestu obok wykresu Helm aplikacji.

Przykład prawidłowego katalogu ustrukturyzowanego można znaleźć w przykładowym repozytorium.

Korzystanie z narzędzia do tworzenia pakietów kontenerów

Po dodaniu wszystkich wymaganych artefaktów uruchom narzędzie container-package-appdo tworzenia pakietów .

Ponieważ bazy CNAB są ogólnie nowym formatem i mają krzywą szkoleniową, utworzyliśmy obraz platformy Docker dla programu container-package-app z użyciem środowiska rozruchowego i narzędzi wymaganych do pomyślnego uruchomienia narzędzia do pakowania.

Dostępne są dwie opcje korzystania z narzędzia do pakowania. Można go użyć ręcznie lub zintegrować go z potokiem wdrażania.

Ręczne uruchamianie narzędzia do tworzenia pakietów

Najnowszy obraz narzędzia do pakowania można ściągnąć z mcr.microsoft.com/container-package-app:latestpliku .

Następujące polecenie platformy Docker ściąga najnowszy obraz narzędzia do pakowania, a także instaluje katalog.

Zakładając, że ~\<path-to-content> jest to katalog zawierający zawartość do spakowania, następujące polecenie platformy Docker zainstaluje ~/<path-to-content> element /data w kontenerze. Pamiętaj, aby zastąpić ~/<path-to-content> element lokalizacją własnej aplikacji.

docker pull mcr.microsoft.com/container-package-app:latest

docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v ~/<path-to-content>:/data --entrypoint "/bin/bash" mcr.microsoft.com/container-package-app:latest 

Uruchom następujące polecenia w powłoce kontenera container-package-app . Pamiętaj, aby zastąpić <registry-name> ciąg nazwą usługi ACR:

export REGISTRY_NAME=<registry-name>

az login 

az acr login -n $REGISTRY_NAME 

cd /data/<path-to-content>

Następnie uruchom polecenie cpa verify , aby iterować artefakty i zweryfikować je pojedynczo. Rozwiąż wszelkie błędy i uruchom polecenie cpa buildbundle , gdy wszystko będzie gotowe do spakowania i przekazania pliku CNAB do Azure Container Registry. Polecenie cpa buildbundle uruchomi również proces weryfikacji przed utworzeniem.

cpa verify

cpa buildbundle 

Uwaga

Użyj cpa buildbundle --force tylko wtedy, gdy chcesz zastąpić istniejący tag. Jeśli ten plik CNAB został już dołączony do oferty Azure Marketplace, zamiast tego zwiększ wersję w pliku manifestu.

Integrowanie z usługą Azure Pipeline

Przykład integracji container-package-app z usługą Azure Pipeline można znaleźć w przykładzie usługi Azure Pipeline.

Następne kroki