Przygotowywanie zasobów technicznych kontenera platformy Azure dla aplikacji Kubernetes
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:
- Podstawowa wiedza na temat usług platformy Azure
- Jak projektować i projektować aplikacje platformy Azure
- Znajomość usługi Azure Resource Manager
- Wiedza na temat formatu JSON
- Znajomość Helm w stopniu podstawowym
- Znajomość funkcji createUiDefinition
- Wiedza na temat szablonów usługi Azure Resource Manager (ARM)
Wymagania wstępne
Aplikacja musi być oparta na wykresie Helm chart.
W wykresie Helm nie powinno się znajdować
.tgzpliki archiwalne; wszystkie pliki powinny być rozpakowane.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 obrazów oraz 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 oraz konto centrum partnerskiego.
Musisz mieć utworzoną usługę Azure Container Registry (ACR), która należy do wyżej wymienionej aktywnej dzierżawy publikacyjnej. 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 uzyskać wskazówki dotyczące określania wymagań dotyczących skanowania luk w zabezpieczeniach, zobacz Rozwiązywanie problemów z certyfikacją kontenera. 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ć Docker na lokalnej maszynie. 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 systemie Linux.
- Oferta Container Marketplace obsługuje wdrażanie na zarządzanych AKS oraz Kubernetes z obsługą Arc. Pojedyncza oferta może dotyczyć tylko jednego typu klastra — zarządzanego AKS lub Kubernetes z obsługą Arc.
- Oferty dla klastrów Kubernetes z obsługą usługi Arc obsługują tylko wstępnie zdefiniowane modele rozliczeń. Aby uzyskać więcej informacji na temat modeli rozliczeniowych, zobacz Zaplanuj ofertę kontenera platformy Azure.
- 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 elementów aplikacji, jest najpierw publikowany w prywatnym rejestrze Azure Container Registry (ACR), a następnie przesłany do publicznego rejestru ACR należącego do firmy Microsoft i wykorzystywany jako pojedynczy element referencyjny 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.
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 Microsoft Entra, która jest połączona z kontem Centrum Partnerskiego.
Firma Microsoft ma aplikację wewnętrzną odpowiedzialną za obsługę tego procesu za pomocą elementu id32597670-3e15-4def-8851-614ff48c1efa. Aby rozpocząć, utwórz główną jednostkę usługi, opierając się na 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 główna usługa 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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ć:
-
Microsoft.Authorization/roleAssignments/writeuprawnienia, takie jak administrator dostępu użytkowników lub właściciel
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 schemat Helm jest zgodny z następującymi regułami:
Wszystkie nazwy obrazów i odwołania są sparametryzowane i przedstawiane w
values.yamljako odwołania do global.azure.images. Zaktualizuj plikdeployment.yamlszablonu 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.
Jeśli masz wiele wykresów, możesz dołączyć inne wykresy helm jako wykresy podrzędne oprócz głównego wykresu helm. Wszystkie zależne odwołania do obrazów wykresów helm będą wymagały aktualizacji i powinny wskazywać obrazy zawarte w 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.
Dostępne modele rozliczeń
W przypadku wszystkich dostępnych modeli rozliczeniowych zapoznaj się z opcjami licencjonowania aplikacji platformy Azure Kubernetes.
Wprowadź aktualizacje 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ę identyfikatora rozliczeń
do specyfikacji Pod w plikach YAML dla obciążenia . Jeśli obciążenie jest określone jako Wdrożenia lub Zestawy replik lub Zestawy z pamięcią stanu lub Zestawy demonów, dodaj tę etykietę w obszarze .spec.template.metadata.labels.
Jeśli obciążenie jest definiowane bezpośrednio jako specyfikacje Pod, dodaj tę etykietę pod .metadata.labels.
W przypadku modelu rozliczeń na rdzenie określ żądanie procesora CPU, dołączając
resources:requestspole w manifeście zasobu kontenera. Ten krok jest wymagany tylko dla modelu rozliczeniowego dla rdzeni .
Podczas wdrażania funkcja rozszerzeń klastra zastępuje wartość identyfikatora rozliczeń nazwą instancji rozszerzenia.
Aby zapoznać się z przykładami skonfigurowanymi do wdrożenia aplikacji Azure Voting, zobacz następujące:
W przypadku modelu rozliczeń niestandardowych mierników, dodaj poniższe pola w pliku values.yaml Twojego szablonu Helm.
- clientId należy dodać pod global.azure.identity
- Klucz planId należy dodać pod global.azure.marketplace. identyfikator planu
- identyfikator resourceId należy dodać w obszarze global.azure.extension.resrouceId
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.
Weryfikowanie wykresu helm
Aby upewnić się, że chart Helm jest poprawny, przetestuj, czy można go zainstalować na lokalnym klastrze. 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:
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, skopiuj zawartość pliku do środowiska piaskownicy. Piaskownica przedstawia interfejs użytkownika w obecnym portalu pełnoekranowym. Piaskownica jest zalecanym sposobem przeglądania interfejsu użytkownika.
Tworzenie szablonu usługi Azure Resource Manager (ARM)
Szablon ARM definiuje zasoby Azure do wdrożenia. Domyślnie wdrożysz zasób rozszerzenia klastra dla aplikacji witryny Azure Marketplace. Możesz opcjonalnie wybrać wdrożenie klastra AKS.
Obecnie zezwalamy tylko na następujące typy zasobów:
Microsoft.ContainerService/managedClustersMicrosoft.KubernetesConfiguration/extensions
Na przykład, spójrz na ten przykładowy szablon ARM zaprojektowany, aby uzyskać wyniki z przykładowej definicji interfejsu użytkownika, połączonego wcześniej, i przekazać parametry do aplikacji.
Przepływ parametrów użytkownika
Ważne jest, aby zrozumieć, jak parametry użytkownika przepływają przez artefakty, które tworzysz i pakujesz. W przykładzie aplikacji Azure Voting parametry są początkowo definiowane podczas tworzenia interfejsu użytkownika za pośrednictwem pliku createUiDefinition.json:
Parametry są eksportowane za pośrednictwem outputs sekcji:
Następnie wartości są przekazywane do szablonu usługi Azure Resource Manager i są propagowane do wykresu Helm podczas wdrażania:
Na koniec wartości są przekazywane do wykresu Helm przez values.yaml, jak pokazano.
Uwaga
W tym przykładzie extensionResourceName jest 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 |
|---|---|---|
| nazwaAplikacji | String | Nazwa aplikacji |
| wydawca | String | Nazwa wydawcy |
| opis | Sznurek | 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. |
| helmChart | String | Katalog lokalny, w którym można znaleźć wykres Helm w stosunku do tego manifest.yaml |
| clusterARMTemplate | String | Ścieżka lokalna, gdzie można znaleźć szablon ARM opisujący klaster AKS spełniający wymagania w polu ograniczeń. |
| uiDefinition | String | Ścieżka lokalna, w której można znaleźć plik JSON opisujący doświadczenie tworzenia w portalu Azure |
| serwer rejestru | String | ACR, do którego należy przesłać końcowy pakiet CNAB. |
| parametryRejestracjiRozszerzenia | Kolekcja | Specyfikacja parametrów rejestracji rozszerzenia. Uwzględnij co najmniej defaultScope oraz 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 zakres namespace jest wybrany, to w przestrzeni nazw dozwolone jest tylko jedno wystąpienie. Ponieważ klaster Kubernetes może mieć wiele przestrzeni nazw, może istnieć wiele wystąpień rozszerzenia. |
| przestrzeń nazw | String | (Opcjonalnie) Określ przestrzeń nazw instalowaną przez rozszerzenie. Ta właściwość jest wymagana, gdy defaultScope jest ustawione na cluster. Aby uzyskać informacje o ograniczeniach nazewnictwa przestrzeni nazw, zobacz Przestrzenie nazw i SYSTEM DNS. |
| obsługiwane_typy_klastrów | 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 zarządzanych za pomocą usługi Azure Arc. Jeśli nie podano obsługiwanych typów klastrów, wszystkie dystrybucje zarządzanych klastrów są domyślnie obsługiwane. Jeśli wartość supportedClusterTypes jest podana, a dany typ klastra najwyższego poziomu nie jest uwzględniony, 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: -dystrybucja - obsługaDystrybucji - nieobsługiwaneWersje |
| dystrybucja | Lista | 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. |
| obsługiwane dystrybucje | Wartość logiczna | Wartość logiczna reprezentująca, czy określone dystrybucje są obsługiwane. Jeśli wartość false, podanie parametru UnsupportedVersions powoduje błąd. |
| nieobsługiwane wersje | Lista | 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 tego zakresu 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 ConnectedCluster-only .
Aby uzyskać więcej informacji na temat konfigurowania klastra Kubernetes z obsługą usługi Azure Arc w celu weryfikacji aplikacji, zobacz Szybki start: łączenie istniejącego klastra Kubernetes z usługą Azure Arc.
Korzystanie z narzędzia do tworzenia pakietów kontenerów
Po dodaniu wszystkich wymaganych artefaktów uruchom narzędzie container-package-app do tworzenia pakietów, aby zweryfikować artefakty, skompilować pakiet i przekazać pakiet do usługi Azure Container Registry.
Ponieważ CNAB jest nowym formatem i ma krzywą uczenia się, utworzyliśmy obraz Dockera dla container-package-app ze środowiskiem startowym i narzędziami wymaganymi do pomyślnego uruchomienia narzędzia do tworzenia pakietów.
Dostępne są dwie opcje użycia narzędzia do pakowania. Można go użyć ręcznie lub zintegrować go z potokiem wdrażania.
Uruchom narzędzie do tworzenia pakietów ręcznie
Najnowszy obraz narzędzia do tworzenia pakietów można pobrać z mcr.microsoft.com/container-package-app:latest.
Następujące polecenie Docker pobiera najnowszy obraz narzędzia do tworzenia pakietów, a także montuje katalog.
Zakładając, że ~\<path-to-content> jest katalogiem zawierającym zawartość do spakowania, następujące polecenie Docker przyłącza ~/<path-to-content> do /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> 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, jak pokazano wcześniej, a drugą opcją jest uruchomienie docker login 'yourACRname'.azurecr.io poprzez docker. Wprowadź nazwę użytkownika i hasło (nazwa użytkownika powinna być Twoją nazwą ACR, a hasło jest wygenerowanym kluczem podanym w portalu Azure), a następnie uruchom polecenie.
docker login <yourACRname.azurecr.io>
Następnie uruchom polecenie cpa verify, aby przejść przez artefakty, zweryfikować je pojedynczo i rozwiązać wszelkie problemy. 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 proces weryfikacji, kompiluje pakiet i przekazuje pakiet do usługi Azure Container Registry.
cpa verify
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
Aby zapoznać się z przykładem integrowania CNAB z Github Actions, zobacz przykład akcji Github
Rozwiązywanie problemów
- Pomoc dotycząca rozwiązywania problemów z pakowaniem
- Pomoc dotycząca rozwiązywania problemów z publikowaniem