Przygotowywanie zasobów technicznych kontenera platformy Azure dla aplikacji Kubernetes

  • Artykuł

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

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

Podstawowa wiedza techniczna

Projektowanie, kompilowanie i testowanie tych zasobów wymaga 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.

  • Jeśli masz wiele wykresów, możesz dołączyć inne wykresy helm jako wykresy podrzędne oprócz głównego wykresu 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 innych wykresów ani obrazów.

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

  • Musisz utworzyć usługę Azure Container Registry (ACR), która należy do aktywnej dzierżawy publikowania powyżej. Do tego przekażesz pakiet aplikacji natywnej chmury (CNAB). Aby uzyskać więcej informacji, zobacz Tworzenie usługi Azure Container Registry.

  • Instalowanie najnowszej wersji interfejsu wiersza polecenia platformy Azure.

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

  • Obrazy muszą być wolne od luk w zabezpieczeniach. Aby dowiedzieć się więcej na temat skanowania pod kątem luk w zabezpieczeniach, zobacz Oceny luk w zabezpieczeniach dla platformy Azure za pomocą Zarządzanie lukami w zabezpieczeniach w usłudze Microsoft Defender.

  • W przypadku ręcznego uruchamiania narzędzia do tworzenia pakietów należy zainstalować maszynę lokalną. Aby uzyskać więcej informacji, zobacz sekcję zaplecza WSL 2 w dokumentacji platformy Docker dla systemu Windows lub Linux. Jest to obsługiwane tylko na maszynach z systemem Linux/Windows AMD64.

Ograniczenia

  • Platforma 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.

Omówienie publikowania

Pierwszym krokiem do opublikowania oferty kontenera opartej na aplikacji Kubernetes w witrynie Azure Marketplace jest spakowanie aplikacji jako pakietu aplikacji natywnej dla chmury (CNAB). CnAB składający się z artefaktów aplikacji jest po raz pierwszy publikowany w prywatnej usłudze Azure Container Registry (ACR), a później wypchnięty do publicznego rejestru ACR należącego do firmy Microsoft i jest używany 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 klastra usługi Azure Kubernetes Service (AKS).

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

A diagram showing the three stages of bundle processing, flowing from 'Copy the bundle to a Microsoft-owned registry' to 'Vulnerability scanning' to 'Extension type registration'.

Udzielanie dostępu do usługi Azure Container Registry

W ramach procesu publikowania firma Microsoft kopiuje plik CNAB z usługi ACR do należącego do firmy Microsoft, usługi ACR specyficznego dla witryny Azure Marketplace. Obrazy są przekazywane do publicznego rejestru, który jest dostępny dla wszystkich. Ten krok wymaga udzielenia firmie Microsoft dostępu do rejestru. Usługa ACR musi znajdować się w tej samej dzierżawie firmy Microsoft, która jest połączona z kontem Centrum partnerskiego.

Firma Microsoft ma 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 Twoje konto nie ma uprawnień do tworzenia jednostki usługi, az ad sp create zwraca komunikat o błędzie zawierający komunikat "Niewystarczające uprawnienia do ukończenia operacji". Skontaktuj się z administratorem firmy Microsoft Entra, aby utworzyć jednostkę usługi.

az login

Sprawdź, czy jednostka usługi już istnieje dla aplikacji:

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

Jeśli poprzednie polecenie nie zwraca żadnych wyników, utwórz nową jednostkę usługi:

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ć:

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 usługi 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 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 plik deployment.yaml szablonu wykresu helm, aby wskazać te obrazy. Dzięki temu blok obrazów może zostać zaktualizowany w celu odwołania się do obrazów usługi ACR w witrynie Azure Marketplace. Screenshot showing the extended adding tag support reference example.Screenshot showing adding image reference.

  • Jeśli masz wiele wykresów, możesz dołączyć inne wykresy helm jako wykresy podrzędne oprócz głównego wykresu helm. Następnie zaktualizuj poszczególne odwołania do obrazu zależnego, aby wskazywały obrazy uwzględnione na wykresie values.yamlgłównym.

  • Podczas odwoływania się do obrazów można używać tagów lub skrótów. Należy jednak pamiętać, że obrazy są wewnętrznie ponownie oznaczone, aby wskazać usługę Azure Container Registry (ACR) należącą do firmy Microsoft. Po zaktualizowaniu tagu do witryny Azure Marketplace musi zostać przesłana nowa wersja CNAB. Dzięki temu zmiany mogą zostać odzwierciedlone we wdrożeniach klientów.

    Screenshot showing adding tag support reference example.

Dostępne modele rozliczeń

W przypadku wszystkich dostępnych modeli rozliczeniowych zapoznaj się z opcjami licencjonowania aplikacji platformy Azure Kubernetes.

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 modelach rozliczeń Na rdzeń, Na zasobnik, Na węzeł :

  • Dodaj etykietę azure-extensions-usage-release-identifier identyfikatora rozliczeń do specyfikacji zasobnika w plikach yaml obciążenia .

    • Jeśli obciążenie jest określone jako Wdrożenia lub Zestawy replik lub Stanowe lub Specyfikacje demonów, dodaj tę etykietę w obszarze .spec.template.metadata.labels.

    • Jeśli obciążenie jest określane bezpośrednio jako specyfikacje zasobnika, dodaj tę etykietę w obszarze .metadata.labels.

      A screenshot of a properly formatted billing identifier label in a deployment.yaml file. The content resembles the sample depoyment.yaml file linked in this article.

      A screenshot of a properly formatted billing identifier label in a statefulsets.yaml file. The content resembles the sample statefulsets.yaml file linked in this article.

      A screenshot of CPU resource requests in a daemonsets.yaml file. The content resembles the sample daemonsets.yaml file linked in this article.

      A screenshot of CPU resource requests in a pods.yaml file. The content resembles the sample pods.yaml file linked in this article.

  • W przypadku modelu rozliczeń na rdzenie określ żądanie procesora CPU, dołączając resources:requests pole w manifeście zasobu kontenera. Ten krok jest wymagany tylko dla modelu rozliczeniowego dla rdzeni .

    A screenshot of CPU resource requests in a pods.yaml file. The content resembles the sample per core billing model file linked in this article.

W czasie wdrażania funkcja rozszerzeń klastra zastępuje wartość identyfikatora rozliczeń nazwą wystąpienia rozszerzenia.

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

W przypadku niestandardowego modelu rozliczeń mierników dodaj pola wymienione poniżej w pliku values.yaml szablonu narzędzia Helm

  • clientId należy dodać w obszarze global.azure.identity
  • Klucz planId należy dodać w obszarze global.azure.marketplace. identyfikator planu
  • identyfikator resourceId należy dodać w obszarze global.azure.extension.resrouceId

Screenshot of custom metering billing.

W czasie wdrażania funkcja rozszerzeń klastra zastępuje te pola odpowiednimi wartościami. Aby zapoznać się z przykładami, zobacz aplikację opartą na niestandardowych miernikach głosowania na platformie Azure.

Tworzenie pliku parametru testowego

Plik parametrów testowych jest plikiem JSON używanym w połączeniu z szablonem usługi ARM w celu wdrożenia zasobu na platformie Azure. W przypadku aplikacji lub rozszerzeń, które można wdrożyć w klastrach zarządzanych (AKS), wymagane jest określenie pliku parametrów na potrzeby walidacji wdrożenia. Plik parametrów testowych powinien zawierać wartości, które umożliwiłyby pomyślne wdrożenie testowe.

Uwaga

Nie wszystkie parametry muszą być uwzględnione w pliku parametrów, tylko parametry, które nie mają wartości domyślnej. Aby uzyskać wskazówki, zobacz tutaj.

Oto przykładowy plik parametrów testu:

Sample test parameter file. Po utworzeniu pliku parametrów testu dodaj go do pliku manifestu:

Example of created test parameter file.

Uwaga

W sytuacjach, w których plik parametrów testowych nie będzie miał zastosowania do aplikacji (na przykład aplikacja wymaga wpisów tajnych do wdrożenia, takich jak klucz interfejsu API lub aplikacja wdrażana w połączonych klastrach), flaga pomijania wdrożenia jest udostępniana, aby umożliwić pominięcie testowania wdrożenia.

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 funkcji wykrywania niektórych błędów generowania szablonów.

Tworzenie i testowanie elementu createUiDefinition

CreateUiDefinition to plik JSON, który definiuje elementy interfejsu użytkownika dla witryny Azure Portal podczas wdrażania aplikacji. Aby uzyskać więcej informacji, zobacz:

Po utworzeniu pliku createUiDefinition.json dla aplikacji należy przetestować środowisko użytkownika. Aby uprościć testowanie, skopiuj zawartość pliku do środowiska piaskownicy. Piaskownica przedstawia interfejs użytkownika w bieżącym środowisku portalu pełnoekranowym. 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. Domyślnie wdrożysz zasób rozszerzenia klastra dla aplikacji witryny 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

Zobacz na przykład ten przykładowy szablon usługi ARM zaprojektowany w celu uzyskania wyników z przykładowej definicji interfejsu użytkownika połączonej wcześniej i przekazania parametrów do aplikacji.

Przepływ parametrów użytkownika

Ważne jest, aby zrozumieć, jak parametry użytkownika przepływają w artefaktach tworzonych i pakujących. W przykładzie aplikacji Azure Voting parametry są początkowo definiowane podczas tworzenia interfejsu użytkownika za pośrednictwem pliku createUiDefinition.json:

A screenshot of the createUiDefinition example linked in this article. Definitions for 'value1' and 'value2' are shown.

Parametry są eksportowane za pośrednictwem outputs sekcji:

A screenshot of the createUiDefinition example linked in this article. Output lines for application title, 'value1', and 'value2' are shown.

Następnie wartości są przekazywane do szablonu usługi Azure Resource Manager i są propagowane do wykresu Helm podczas wdrażania:

A screenshot of the Azure Resource Manager template example linked in this article. Under 'configurationSettings', the parameters for application title, 'value1', and 'value2' are shown.

Na koniec wartości są przekazywane do wykresu Helm, values.yaml jak pokazano poniżej.

A screenshot of the Helm chart example linked in this article. Values for application title, 'value1', and 'value2' are shown.

Uwaga

W tym przykładzie extensionResourceName parametry są również sparametryzowane i przekazywane 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.

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ć artefakty zależne.

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

Nazwisko Typ danych opis
applicationName String Nazwa aplikacji
Wydawca String Nazwa wydawcy
opis String Krótki opis pakietu
version 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.
helmChart String Katalog lokalny, w którym można znaleźć wykres Helm w stosunku do tego manifest.yaml
clusterARMTemplate String Ścieżka lokalna, w której można znaleźć szablon usługi ARM opisujący klaster usługi AKS spełniający wymagania dotyczące ograniczeń.
uiDefinition String Ścieżka lokalna, w której można znaleźć plik JSON opisujący środowisko tworzenia witryny Azure Portal
registryServer String ACR, w którym należy wypchnąć końcowy pakiet CNAB
extensionRegistrationParameters Kolekcja Specyfikacja parametrów rejestracji rozszerzenia. Uwzględnij co najmniej defaultScope parametr i jako parametr.
defaultScope String Domyślny zakres instalacji rozszerzenia. Akceptowane wartości to cluster lub namespace. Jeśli cluster zakres jest ustawiony, tylko jedno wystąpienie rozszerzenia jest dozwolone dla klastra. Jeśli namespace wybrano zakres, dozwolone jest tylko jedno wystąpienie na przestrzeń nazw. Ponieważ klaster Kubernetes może mieć wiele przestrzeni nazw, może istnieć wiele wystąpień rozszerzenia.
namespace String (Opcjonalnie) Określ przestrzeń nazw instalowaną przez rozszerzenie. Ta właściwość jest wymagana, gdy defaultScope jest ustawiona na clusterwartość . Aby uzyskać informacje o ograniczeniach nazewnictwa przestrzeni nazw, zobacz Przestrzenie nazw i SYSTEM DNS.
supportedClusterTypes Kolekcja (Opcjonalnie) Określ typy klastrów obsługiwane przez aplikację. Dozwolone typy to "managedClusters", "connectedClusters". "managedClusters" odnosi się do klastrów usługi Azure Kubernetes Service (AKS). "connectedClusters" odnosi się do klastrów Kubernetes z obsługą usługi Azure Arc. Jeśli nie podano obsługiwanych parametrówClusterTypes, wszystkie dystrybucje elementów "managedClusters" są domyślnie obsługiwane. Jeśli jest podana wartość supportedClusterTypes, a podany typ klastra najwyższego poziomu nie jest podany, wszystkie dystrybucje i wersje kubernetes dla tego typu klastra są traktowane jako nieobsługiwane. Dla każdego typu klastra określ listę co najmniej jednej dystrybucji z następującymi właściwościami:
-Dystrybucji
- distributionSupported
- nieobsługiwaneVersions
Dystrybucji List Tablica rozkładów odpowiadających typowi klastra. Podaj nazwę określonych dystrybucji. Ustaw wartość na ["All"], aby wskazać, że wszystkie dystrybucje są obsługiwane.
distributionSupported Wartość logiczna Wartość logiczna reprezentująca, czy określone dystrybucje są obsługiwane. Jeśli wartość false, podanie parametru UnsupportedVersions powoduje błąd.
nieobsługiwaneversions List Lista wersji określonych dystrybucji, które nie są obsługiwane. Obsługiwane operatory:
- "=" Podana wersja nie jest obsługiwana. Na przykład "=1.2.12"
- ">" Wszystkie wersje większe niż dana wersja nie są obsługiwane. Na przykład ">1.1.13"
- "<" Wszystkie wersje mniejsze niż dana wersja nie są obsługiwane. Na przykład "<1.3.14"
- "..." Wszystkie wersje w zakresie są nieobsługiwane. Na przykład "1.1.2...1.1.1.15" (zawiera wartość po prawej stronie i wyklucza wartość po lewej stronie)

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

Tworzenie struktury aplikacji

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

Aby zapoznać się z przykładem prawidłowo ustrukturyzowanego katalogu, zobacz Przykładowe głosowanie na platformie Azure.

Aby zapoznać się z przykładem aplikacji do głosowania obsługującej klastry Kubernetes z obsługą usługi Azure Arc, zobacz przykład Połączenie edCluster-only .

Aby zapoznać się z przykładową aplikacją do głosowania, która obsługuje klastry usługi Azure Kubernetes Service (AKS) i klastry Kubernetes z obsługą usługi Azure Arc, zobacz przykład Połączenie ed i Managed Cluster (Klaster zarządzany).

Aby uzyskać więcej informacji na temat konfigurowania klastra Kubernetes z włączoną usługą Azure Arc w celu weryfikacji aplikacji, zobacz Szybki start: Połączenie istniejącego klastra Kubernetes do usługi Azure Arc.

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ą nowym formatem i mają krzywą szkoleniową, utworzyliśmy obraz platformy Docker dla container-package-app programu z użyciem środowiska bootstrapping i narzędzi wymaganych do pomyślnego uruchomienia narzędzia do tworzenia pakietów.

Dostępne są dwie opcje użycia narzędzia do tworzenia pakietów. 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 tworzenia pakietów 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 tworzenia pakietów, 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 ~/<path-to-content> Docker instaluje się /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>

Aby uwierzytelnić usługę ACR, dostępne są dwie opcje. Jedną z opcji jest użycie az login metody , jak pokazano wcześniej, a druga opcja to docker, uruchamiając polecenie docker login 'yourACRname'.azurecr.io. Wprowadź nazwę użytkownika i hasło (nazwa użytkownika powinna być nazwą usługi ACR, a hasło jest wygenerowanym kluczem podanym w witrynie Azure Portal) i uruchom polecenie .

docker login <yourACRname.azurecr.io>

Screenshot of docker login command in CLI.

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 usługi Azure Container Registry. Polecenie cpa buildbundle uruchamia również proces weryfikacji przed utworzeniem

cpa verify

Screenshot of cpa verify command in CLI. 

cpa buildbundle

Uwaga

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

Integracja 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

Rozwiązywanie problemów

Następne kroki