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
- Praca na temat programu Helm
- Znajomość funkcji createUiDefinition
- Wiedza na temat szablonów usługi Azure Resource Manager (ARM)
Wymagania wstępne
Aplikacja musi być oparta na wykresie helm.
Pakiet Helm nie powinien zawierać
.tgzplików archiwum. 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 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 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ć 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.
- Oferta witryny Container Marketplace obsługuje wdrażanie w zarządzanych rozwiązaniach AKS i Kubernetes z obsługą usługi Arc. Pojedyncza oferta może dotyczyć tylko jednego typu klastra— zarządzanego usługi AKS lub platformy Kubernetes z obsługą usługi 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 Planowanie oferty 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 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.
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 id 32597670-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/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 pakiet Helm jest zgodny z następującymi regułami:
Wszystkie nazwy obrazów i odwołania są sparametryzowane i reprezentowane jako
values.yamlodwołania 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.
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-identifieridentyfikatora 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.
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 .
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
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 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:
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 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/managedClustersMicrosoft.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:
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, values.yaml jak pokazano poniżej.
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: -dystrybucja - distributionSupported - nieobsługiwaneVersions |
| dystrybucja | 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 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ż 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>
Następnie uruchom polecenie cpa verify , aby iterować artefakty i zweryfikować je pojedynczo i rozwiązać wszelkie błędy. 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
Rozwiązywanie problemów
- Pomoc dotycząca rozwiązywania problemów z pakowaniem
- Pomoc dotycząca rozwiązywania problemów z publikowaniem