Dysk testowy usługi Azure Resource Manager

Artykuł
06/14/2024

Uwaga

Test Drive został już przestarzały. Alternatywą dla wersji testowych może być przejście na bezpłatne wersje próbne, co zapewnia klientom możliwość pełnego poznania produktu z użyciem spersonalizowanych ustawień i konfiguracji, spełniających ich konkretne wymagania. Zalecamy usunięcie dysków testowych z ofert i wyczyszczenie środowisk testowych.

Użyj tego typu, jeśli masz ofertę w witrynie Azure Marketplace lub usłudze AppSource, ale chcesz utworzyć dysk testowy tylko z zasobami platformy Azure. Szablon usługi Azure Resource Manager (ARM) to zakodowany kontener zasobów platformy Azure, który projektujesz najlepiej reprezentujące rozwiązanie. Dysk testowy przyjmuje podany szablon usługi ARM i wdraża wszystkie zasoby wymagane do grupy zasobów. Jest to jedyna opcja wersji testowej dla ofert maszyn wirtualnych lub aplikacji platformy Azure.

Jeśli nie znasz szablonu usługi ARM, przeczytaj artykuł Co to jest usługa Azure Resource Manager? i Zapoznaj się ze strukturą i składnią szablonów usługi ARM, aby lepiej zrozumieć, jak tworzyć i testować własne szablony.

Aby uzyskać informacje na temat dysku testowego hostowanej lub aplikacji logiki, zobacz Co to jest dysk testowy?

Napiwek

Aby wyświetlić widok wersji testowej klienta na platformie handlowej, zobacz Co to jest witryna Azure Marketplace? i Co to jest usługa Microsoft AppSource?.

Konfiguracja techniczna

Szablon wdrożenia zawiera wszystkie zasoby platformy Azure, które składają się na Twoje rozwiązanie. Produkty pasujące do tego scenariusza używają tylko zasobów platformy Azure. Ustaw następujące właściwości w Centrum partnerskim:

Regiony (wymagane) — obecnie dostępnych jest 26 regionów obsługiwanych przez platformę Azure. Aby uzyskać najlepszą wydajność, zalecamy wybranie jednego regionu, w którym spodziewasz się największej liczby klientów. Musisz upewnić się, że twoja subskrypcja może wdrożyć wszystkie zasoby potrzebne w każdym z wybranych regionów.
Wystąpienia — wybierz typ (gorąca lub zimna) i liczbę dostępnych wystąpień, które zostaną pomnożone przez liczbę regionów, w których oferta jest dostępna.
- Gorąca — ten typ wystąpienia jest wdrażany i oczekuje na dostęp w wybranym regionie. Klienci mogą natychmiast uzyskiwać dostęp do gorących wystąpień dysku testowego, zamiast czekać na wdrożenie. Kompromis polega na tym, że te wystąpienia są zawsze uruchomione w ramach subskrypcji platformy Azure, więc będą ponosić większy koszt czasu pracy. Zdecydowanie zaleca się posiadanie co najmniej jednego wystąpienia Gorąca, ponieważ większość klientów nie chce czekać na pełne wdrożenia, co powoduje spadek użycia klienta, jeśli nie jest dostępne żadne gorące wystąpienie.
- Cold — ten typ wystąpienia reprezentuje łączną liczbę wystąpień, które mogą być wdrażane w poszczególnych regionach. Zimne wystąpienia wymagają wdrożenia całego szablonu usługi Resource Manager dysku testowego, gdy klient zażąda dysku testowego, więc wystąpienia zimne są znacznie wolniejsze do załadowania niż wystąpienia gorąca . Kompromis polega na tym, że musisz zapłacić tylko za czas trwania dysku testowego, nie jest on zawsze uruchamiany w ramach subskrypcji platformy Azure, tak jak w przypadku wystąpienia Gorąca.
Testowanie szablonu usługi Azure Resource Manager — przekaż .zip zawierający szablon usługi Azure Resource Manager. Dowiedz się więcej na temat tworzenia szablonu usługi Azure Resource Manager w artykule Szybki start Tworzenie i wdrażanie szablonów usługi Azure Resource Manager przy użyciu witryny Azure Portal.

Uwaga

Aby pomyślnie opublikować, ważne jest zweryfikowanie formatowania szablonu usługi ARM. Dwa sposoby wykonania tej czynności to (1) przy użyciu narzędzia interfejsu API online lub (2) z wdrożeniem testowym.
Czas trwania dysku testowego (wymagany) — wprowadź liczbę godzin, przez które dysk testowy pozostanie aktywny. Dysk testowy kończy się automatycznie po upływie tego okresu. Użyj tylko liczb całkowitych (na przykład "2" godziny są prawidłowe, "1,5" nie).

Pisanie szablonu dysku testowego

Po zaprojektowaniu żądanego pakietu zasobów napisz i skompiluj szablon usługi ARM dla dysku testowego. Ponieważ dysk testowy uruchamia wdrożenia w trybie w pełni zautomatyzowanym, szablony testów mają pewne ograniczenia:

Parametry

Większość szablonów ma zestaw parametrów, które definiują nazwy zasobów, rozmiary zasobów (takie jak typy kont magazynu lub rozmiary maszyn wirtualnych), nazwy użytkowników i hasła, nazwy DNS itd. Podczas wdrażania rozwiązań przy użyciu witryny Azure Portal można ręcznie wypełnić wszystkie te parametry, wybrać dostępne nazwy DNS lub nazwy kont magazynu itd.

Lista parametrów w usłudze Azure Resource Manager

Jednak dysk testowy działa automatycznie, bez interakcji człowieka, więc obsługuje tylko ograniczony zestaw kategorii parametrów. Jeśli parametr w szablonie usługi ARM dysku testowego nie należy do jednej z obsługiwanych kategorii, należy zastąpić ten parametr zmienną lub wartością stałą.

Możesz użyć dowolnej prawidłowej nazwy parametrów; test drive rozpoznaje kategorię parametrów przy użyciu wartości typu metadanych. Określ typ metadanych dla każdego parametru szablonu, w przeciwnym razie szablon nie przejdzie walidacji:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username"
    }
  },
  ...
}

Uwaga

Wszystkie parametry są opcjonalne, więc jeśli nie chcesz ich używać, nie musisz tego robić.

Zaakceptowane typy metadanych parametrów

Typ metadanych	Typ parametru	opis	Przykładowa wartość
baseuri	string	Podstawowy identyfikator URI pakietu wdrożeniowego	`https://<..>.blob.core.windows.net/<..>`
nazwa użytkownika	string	Nowa losowa nazwa użytkownika.	admin68876
hasło	ciąg bezpieczny	Nowe losowe hasło	Lp! ACS^2kh
identyfikator sesji	string	Unikatowy identyfikator sesji dysku testowego (GUID)	b8c8693e-5673-449c-badd-257a405a6dee

baseuri

Dysk testowy inicjuje ten parametr za pomocą identyfikatora URI podstawowego pakietu wdrożeniowego, dzięki czemu można użyć tego parametru do utworzenia identyfikatora URI dowolnego pliku zawartego w pakiecie.

Uwaga

Nie można użyć parametru baseUri w połączeniu z rozszerzeniem niestandardowego skryptu.

"parameters": {
  ...
  "baseuri": {
    "type": "string",
    "metadata": {
      "type": "baseuri",
      "description": "Base Uri of the deployment package."
    }
  },
  ...
}

Użyj tego parametru wewnątrz szablonu, aby skonstruować identyfikator URI dowolnego pliku z pakietu wdrożeniowego dysku testowego. W poniższym przykładzie pokazano, jak utworzyć identyfikator URI połączonego szablonu:

"templateLink": {
  "uri": "[concat(parameters('baseuri'),'templates/solution.json')]",
  "contentVersion": "1.0.0.0"
}

nazwa użytkownika

Dysk testowy inicjuje ten parametr przy użyciu nowej losowej nazwy użytkownika:

"parameters": {
  ...
  "username": {
    "type": "string",
    "metadata": {
      "type": "username",
      "description": "Solution admin name."
    }
  },
  ...
}

Przykładowa wartość: admin68876

Możesz użyć losowych lub stałych nazw użytkowników dla rozwiązania.

hasło

Dysk testowy inicjuje ten parametr przy użyciu nowego losowego hasła:

"parameters": {
  ...
  "password": {
    "type": "securestring",
    "metadata": {
      "type": "password",
      "description": "Solution admin password."
    }
  },
  ...
}

Przykładowa wartość: Lp!ACS^2kh

Możesz użyć losowych lub stałych haseł dla rozwiązania.

identyfikator sesji

Dysk testowy inicjuje ten parametr za pomocą unikatowego identyfikatora GUID reprezentującego identyfikator sesji dysku testowego:

"parameters": {
  ...
  "sessionid": {
    "type": "string",
    "metadata": {
      "type": "sessionid",
      "description": "Unique test drive session id."
    }
  },
  ...
}

Przykładowa wartość: b8c8693e-5673-449c-badd-257a405a6dee

Tego parametru można użyć do unikatowego zidentyfikowania sesji dysku testowego, jeśli jest to konieczne.

Unikatowe nazwy

Niektóre zasoby platformy Azure, takie jak konta magazynu lub nazwy DNS, wymagają globalnie unikatowych nazw. Oznacza to, że za każdym razem, gdy dysk testowy wdraża szablon usługi ARM, tworzy nową grupę zasobów o unikatowej nazwie dla wszystkich jej zasobów. W związku z tym należy użyć funkcji uniquestring połączonych z nazwami zmiennych na identyfikatorach grup zasobów, aby wygenerować losowe unikatowe wartości:

"variables": {
  ...
  "domainNameLabel": "[concat('contosovm',uniquestring(resourceGroup().id))]",
  "storageAccountName": "[concat('contosodisk',uniquestring(resourceGroup().id))]",
  ...
}

Upewnij się, że łączysz ciągi parametrów/zmiennych (contosovm) z unikatowymi danymi wyjściowymi ciągu (resourceGroup().id), ponieważ gwarantuje to unikatowość i niezawodność każdej zmiennej.

Na przykład większość nazw zasobów nie może zaczynać się cyfrą, ale unikatowa funkcja ciągu może zwracać ciąg, który zaczyna się od cyfry. Dlatego jeśli używasz nieprzetworzonych unikatowych danych wyjściowych ciągu, wdrożenia zakończy się niepowodzeniem.

Dodatkowe informacje na temat reguł nazewnictwa zasobów i ograniczeń można znaleźć w temacie Opracowywanie strategii nazewnictwa i tagowania zasobów platformy Azure.

Lokalizacja wdrożenia

Możesz udostępnić dysk testowy w różnych regionach świadczenia usługi Azure.

Gdy dysk testowy tworzy wystąpienie laboratorium, zawsze tworzy grupę zasobów w jednym z wybranych regionów, a następnie wykonuje szablon wdrożenia w tym kontekście grupy. Dlatego szablon powinien wybrać lokalizację wdrożenia z grupy zasobów:

"variables": {
  ...
  "location": "[resourceGroup().location]",
  ...
}

Następnie użyj tej lokalizacji dla każdego zasobu dla określonego wystąpienia laboratorium:

"resources": [
  {
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/publicIPAddresses",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/virtualNetworks",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Network/networkInterfaces",
    "location": "[variables('location')]",
    ...
  },
  {
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[variables('location')]",
    ...
  }
]

Upewnij się, że twoja subskrypcja może wdrażać wszystkie zasoby, które mają być wdrażane w każdym z wybranych regionów. Upewnij się również, że obrazy maszyn wirtualnych są dostępne we wszystkich regionach, które włączysz, w przeciwnym razie szablon wdrożenia nie będzie działać w niektórych regionach.

Dane wyjściowe

Zwykle przy użyciu szablonów usługi Resource Manager można wdrażać bez tworzenia żadnych danych wyjściowych. Jest to spowodowane tym, że znasz wszystkie wartości używane do wypełniania parametrów szablonu i zawsze można ręcznie sprawdzić właściwości dowolnego zasobu.

W przypadku szablonów usługi Resource Manager dla wersji testowej należy jednak powrócić do wersji testowej wszystkich informacji, które są wymagane do uzyskania dostępu do laboratorium (identyfikatory URI witryny sieci Web, nazwy hostów maszyny wirtualnej, nazwy użytkowników i hasła). Upewnij się, że wszystkie nazwy danych wyjściowych są czytelne, ponieważ te zmienne są prezentowane klientowi.

Nie ma żadnych ograniczeń związanych z danymi wyjściowymi szablonu. Dysk testowy konwertuje wszystkie wartości wyjściowe na ciągi, więc jeśli wyślesz obiekt do danych wyjściowych, użytkownik zobaczy ciąg JSON.

Przykład:

"outputs": {
  "Host Name": {
    "type": "string",
    "value": "[reference(variables('pubIpId')).dnsSettings.fqdn]"
  },
  "User Name": {
    "type": "string",
    "value": "[parameters('adminName')]"
  },
  "Password": {
    "type": "string",
    "value": "[parameters('adminPassword')]"
  }
}

Limity subskrypcji

Nie zapomnij o limitach subskrypcji i usług. Jeśli na przykład chcesz wdrożyć maksymalnie dziesięć 4-rdzeniowych maszyn wirtualnych, musisz upewnić się, że subskrypcja używana w laboratorium umożliwia korzystanie z 40 rdzeni. Aby uzyskać więcej informacji na temat limitów subskrypcji i usług platformy Azure, zobacz Limity subskrypcji i usług platformy Azure, limity przydziału i ograniczenia. Ponieważ jednocześnie można wykonać wiele testów, sprawdź, czy subskrypcja może obsługiwać liczbę rdzeni pomnożonych przez łączną liczbę współbieżnych dysków testowych, które można wykonać.

Co należy przekazać

Szablon usługi ARM dla wersji testowej jest przekazywany jako plik zip, który może zawierać różne artefakty wdrożenia, ale musi mieć jeden plik o nazwie main-template.json. Jest to szablon wdrożenia usługi ARM, który używa dysku testowego do utworzenia wystąpienia laboratorium. Jeśli masz dodatkowe zasoby poza tym plikiem, możesz odwoływać się do nich jako zasoby zewnętrzne wewnątrz szablonu lub dołączyć je do pliku zip.

Podczas publikowania certyfikatu dysk testowy rozpakowuje pakiet wdrożeniowy i umieszcza jego zawartość w wewnętrznym kontenerze obiektów blob dysku testowego. Struktura kontenera odzwierciedla strukturę pakietu wdrożeniowego:

package.zip	Kontener obiektów blob dysku testowego
`main-template.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/main-template.json`
`templates/solution.json`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/templates/solution.json`
`scripts/warmup.ps1`	`https:\//\<\...\>.blob.core.windows.net/\<\...\>/scripts/warmup.ps1`

Wywołujemy identyfikator URI tego kontenera obiektów blob Base URI. Ponieważ każda wersja laboratorium ma własny kontener obiektów blob, każda poprawka laboratorium ma własny identyfikator URI base. Dysk testowy może przekazać podstawowy identyfikator URI rozpakowanego pakietu wdrożeniowego do szablonu za pomocą parametrów szablonu.

Przekształcanie przykładów szablonów dla wersji testowej

Proces przekształcania architektury zasobów w szablon usługi Resource Manager na dysku testowym może być zniechęcający. Aby uzyskać dodatkową pomoc, zobacz te przykłady najlepszego przekształcania bieżących szablonów wdrażania w temacie Co to jest dysk testowy?.

Szczegóły subskrypcji wdrożenia wersji testowej

Ostatnia sekcja do ukończenia polega na automatycznym wdrożeniu dysków testowych przez połączenie subskrypcji platformy Azure i identyfikatora Entra firmy Microsoft.

Uzyskaj identyfikator subskrypcji platformy Azure. Daje to dostęp do usług platformy Azure i witryny Azure Portal. Subskrypcja to miejsce, w którym jest zgłaszane użycie zasobów, a opłaty za usługi są naliczane. Jeśli nie masz jeszcze oddzielnej subskrypcji platformy Azure tylko dla wersji testowych, utwórz ją. Identyfikatory subskrypcji platformy Azure (takie jak 1a83645ac-1234-5ab6-6789-1h234g764ghty1) można znaleźć, logując się do witryny Azure Portal i wybierając pozycję Subskrypcje z menu po lewej stronie.
Uzyskaj identyfikator dzierżawy entra firmy Microsoft. Jeśli masz już dostępny identyfikator dzierżawy, możesz go znaleźć w identyfikatorze katalogu właściwości>entra>firmy Microsoft:

Jeśli nie masz identyfikatora dzierżawy, utwórz nowy identyfikator w usłudze Microsoft Entra ID. Aby uzyskać pomoc dotyczącą konfigurowania dzierżawy, zobacz Szybki start: konfigurowanie dzierżawy.
Aprowizuj aplikację Microsoft Test-Drive do dzierżawy. Użyjemy tej aplikacji do wykonywania operacji na zasobach dysku testowego.
1. Jeśli jeszcze go nie masz, zainstaluj moduł Azure Az programu PowerShell.
2. Dodaj jednostkę usługi dla aplikacji Microsoft Test-Drive.
  1. Uruchom Connect-AzAccount polecenie i podaj poświadczenia, aby zalogować się do konta platformy Azure, co wymaga ról uprzywilejowanych identyfikatora entra firmy Microsoft według wbudowanej roli zadania.
  2. Utwórz nową jednostkę usługi: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
  3. Upewnij się, że jednostka usługi została utworzona: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'.
W przypadku identyfikatora aplikacji Entra firmy Microsoft wklej następujący identyfikator aplikacji: d7e39695-0b24-441c-a140-047800a05ede.
W przypadku klucza aplikacji Entra firmy Microsoft, ponieważ nie jest wymagany wpis tajny, wstaw fikcyjny wpis tajny, taki jak "no-secret".
Ponieważ używamy aplikacji do wdrażania w ramach subskrypcji, musimy dodać aplikację jako współautor w ramach subskrypcji z witryny Azure Portal lub programu PowerShell:
1. Z witryny Azure Portal:
  1. Wybierz subskrypcję używaną dla wersji testowej.
  2. Wybierz pozycję Kontrola dostępu (IAM) .
  3. Wybierz pozycję Dodaj > przypisanie roli.
  4. Na karcie Rola wybierz pozycję Współautor.
  5. Na karcie Członkowie wybierz pozycję Użytkownik, grupa lub jednostka usługi, a następnie wybierz pozycję Wybierz członków.
  6. Wybierz wcześniej utworzoną jednostkę usługi Microsoft TestDrive .
  7. Na karcie Przeglądanie i przypisywanie wybierz pozycję Przejrzyj i przypisz, aby przypisać rolę.
    
    Aby uzyskać więcej informacji na temat przypisań ról, zobacz Przypisywanie ról platformy Azure przy użyciu witryny Azure Portal
2. W przypadku korzystania z programu PowerShell:
  1. Uruchom polecenie , aby uzyskać identyfikator obiektu ServicePrincipal: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
  2. Uruchom to za pomocą identyfikatora ObjectId i identyfikatora subskrypcji: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Uwaga

Przed usunięciem starego identyfikatora appID przejdź do witryny Azure Portal, a następnie pozycję Grupy zasobów i wyszukaj ciąg CloudTry_. Sprawdź zdarzenie zainicjowane przez kolumnę.

Nie usuwaj starego identyfikatora appID, chyba że co najmniej jeden zasób (nazwa operacji) jest ustawiony na microsoft TestDrive.

Aby usunąć identyfikator appID, w menu nawigacji po lewej stronie wybierz pozycję Rejestracje aplikacji Microsoft Entra ID>, a następnie kartę Wszystkie aplikacje. Wybierz aplikację i wybierz pozycję Usuń.

Ponowne publikowanie

Teraz, gdy wszystkie pola wersji testowej zostaną ukończone, opublikuj ponownie ofertę. Po przejściu testu testowego certyfikatu przetestuj środowisko klienta w wersji zapoznawczej oferty:

Uruchom dysk testowy w interfejsie użytkownika.
Otwórz subskrypcję platformy Azure w witrynie Azure Portal.
Sprawdź, czy dysk testowy jest wdrażany poprawnie.

Nie usuwaj żadnych wystąpień wersji testowych aprowizowania dla klientów; usługa testowania automatycznie wyczyści te grupy zasobów po zakończeniu pracy klienta.

Gdy będziesz dobrze korzystać z oferty w wersji zapoznawczej, nadszedł czas, aby przejść na żywo! Istnieje ostateczny proces przeglądu, aby dokładnie sprawdzić całe kompleksowe środowisko pracy. Jeśli odrzucimy ofertę, wyślijmy wiadomość e-mail na adres kontaktu inżynieryjnego z Twoją ofertą, wyjaśniając, co należy naprawić.

Jeśli wykonano instrukcje tworzenia oferty w Centrum partnerskim, użyj strzałki Wstecz, aby powrócić do tego tematu.
Dowiedz się więcej o innych typach testów na stronie Co to jest dysk testowy?.

Udostępnij za pośrednictwem

Dysk testowy usługi Azure Resource Manager

Konfiguracja techniczna

Pisanie szablonu dysku testowego

Parametry

Zaakceptowane typy metadanych parametrów

baseuri

nazwa użytkownika

hasło

identyfikator sesji

Unikatowe nazwy

Lokalizacja wdrożenia

Dane wyjściowe

Limity subskrypcji

Co należy przekazać

Przekształcanie przykładów szablonów dla wersji testowej

Szczegóły subskrypcji wdrożenia wersji testowej

Ponowne publikowanie

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Dysk testowy usługi Azure Resource Manager

Konfiguracja techniczna

Pisanie szablonu dysku testowego

Parametry

Zaakceptowane typy metadanych parametrów

baseuri

nazwa użytkownika

hasło

identyfikator sesji

Unikatowe nazwy

Lokalizacja wdrożenia

Dane wyjściowe

Limity subskrypcji

Co należy przekazać

Przekształcanie przykładów szablonów dla wersji testowej

Szczegóły subskrypcji wdrożenia wersji testowej

Ponowne publikowanie

Powiązana zawartość

Opinia

Dodatkowe zasoby