Azure Resource Manager test sürüşü

Makale
03/08/2023

Azure Market veya AppSource'ta bir teklifiniz varsa ancak yalnızca Azure kaynaklarıyla test sürüşü oluşturmak istiyorsanız bu türü kullanın. Azure Resource Manager (ARM) şablonu, çözümünüzü en iyi şekilde temsil etmek için tasarladığınız kodlanmış bir Azure kaynakları kapsayıcısıdır. Test sürüşü sağlanan ARM şablonunu alır ve gerekli tüm kaynakları bir kaynak grubuna dağıtır. Bu, sanal makine veya Azure uygulamasının sunduğu tek test sürüşü seçeneğidir.

ARM şablonunun ne olduğunu bilmiyorsanız, kendi şablonlarınızı nasıl oluşturup test ettiğinizi daha iyi anlamak için Bkz. Azure Resource Manager nedir?ve ARM şablonlarının yapısını ve söz dizimini anlama.

Barındırılan veya mantıksal uygulama test sürüşü hakkında bilgi için bkz. Test sürüşü nedir?

İpucu

Müşterinin ticari marketteki test sürüşü görünümünü görmek için bkz. Azure Market nedir? ve Microsoft AppSource nedir?.

Teknik yapılandırma

Dağıtım şablonu, çözümünüzü oluşturan tüm Azure kaynaklarını içerir. Bu senaryoya uyan ürünler yalnızca Azure kaynaklarını kullanır. İş Ortağı Merkezi'nde aşağıdaki özellikleri ayarlayın:

Bölgeler (gerekli) – Şu anda test sürüşünüzün kullanılabilir hale getirilebileceği Azure tarafından desteklenen 26 bölge vardır. En iyi performans için, en fazla sayıda müşterinin bulunacağı bir bölge seçmenizi öneririz. Aboneliğinizin seçtiğiniz bölgelerin her birinde gereken tüm kaynakları dağıtmasına izin verildiğinden emin olmanız gerekir.
Örnekler : Teklifinizin kullanılabilir olduğu bölge sayısıyla çarpılacak olan kullanılabilir örneklerin türünü (sık erişimli veya soğuk) ve sayısını seçin.
- Sık Erişimli – Bu tür bir örnek dağıtılır ve seçilen bölge başına erişim bekler. Müşteriler, bir dağıtımı beklemek zorunda kalmak yerine test sürüşünün Sık Erişimli örneklerine anında erişebilir. Bu örneklerin her zaman Azure aboneliğinizde çalışması, dolayısıyla daha büyük bir çalışma süresi maliyetine neden olmasıdır. Müşterilerin çoğu tam dağıtımları beklemek istemediği için en az bir Sık Erişimli örneğin olması önerilir; bu da Sık Erişimli örnek yoksa müşteri kullanımında bir bırakmayla sonuçlanır.
- Cold : Bu örnek türü, bölge başına dağıtılabilir örneklerin toplam sayısını temsil eder. Soğuk örnekler, müşteri test sürüşü istediğinde dağıtılması için Test Sürüşü Resource Manager şablonunun tamamını gerektirir, bu nedenle Soğuk örneklerin yüklenmesi Sık Erişimli örneklerden çok daha yavaştır. Sonuç olarak, yalnızca test sürüşü süresi boyunca ödeme yapmak zorunda olmanız gerekir. Bu işlem her zamanSık Erişimli örnekte olduğu gibi Azure aboneliğinizde çalışmaz.
Test sürüşü Azure Resource Manager şablonu – Azure Resource Manager şablonunuzu içeren .zip karşıya yükleyin. Azure portal kullanarak Azure Resource Manager şablonları oluşturma ve dağıtma başlıklı hızlı başlangıç makalesinde Azure Resource Manager şablonu oluşturma hakkında daha fazla bilgi edinin.

Not

Başarıyla yayımlamak için ARM şablonunun biçimlendirmesini doğrulamak önemlidir. Bunu yapmanın iki yolu(1) çevrimiçi API aracı kullanılarak veya (2) test dağıtımıyla yapılır.
Test sürüşü süresi (gerekli) – Test sürüşünün etkin kalacağı saat sayısını girin. Bu süre sona erdikten sonra test sürüşü otomatik olarak sona erer. Yalnızca tamsayıları kullanın (örneğin, "2" saat geçerlidir, "1,5" geçerli değildir).

Test sürüşü şablonunu yazma

İstenen kaynak paketini tasarladıktan sonra test sürüşü ARM şablonunu yazın ve derleyin. Test sürüşü dağıtımları tam otomatik modda çalıştırdığından test sürüşü şablonlarının bazı kısıtlamaları vardır:

Parametreler

Çoğu şablon kaynak adlarını, kaynak boyutlarını (depolama hesabı türleri veya sanal makine boyutları gibi), kullanıcı adlarını ve parolaları, DNS adlarını vb. tanımlayan bir dizi parametreye sahiptir. Azure portal kullanarak çözümleri dağıttığınızda, tüm bu parametreleri el ile doldurabilir, kullanılabilir DNS adlarını veya depolama hesabı adlarını seçebilirsiniz.

Azure Resource Manager parametreleri listesi

Ancak test sürüşü, insan etkileşimi olmadan otomatik olarak çalışır, bu nedenle yalnızca sınırlı bir parametre kategorisi kümesini destekler. Test sürüşü ARM şablonundaki bir parametre desteklenen kategorilerden birine girmezse, bu parametreyi bir değişken veya sabit değerle değiştirmeniz gerekir.

Parametreleriniz için geçerli herhangi bir ad kullanabilirsiniz; test sürücüsü, meta veri türü değerini kullanarak parametre kategorisini tanır. Her şablon parametresi için meta veri türünü belirtin; aksi takdirde şablonunuz doğrulamayı geçirmez:

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

Not

Tüm parametreler isteğe bağlıdır, bu nedenle herhangi bir parametre kullanmak istemiyorsanız, kullanmak zorunda değilsiniz.

Kabul Edilen Parametre Meta Veri Türleri

Meta Veri Türü	Parametre Türü	Description	Örnek Değer
Baseuri	string	Dağıtım paketinizin temel URI'si	`https://<..>.blob.core.windows.net/<..>`
Username	string	Yeni rastgele kullanıcı adı.	admin68876
parola	güvenli dize	Yeni rastgele parola	Lp!ACS^2kh
oturum kimliği	string	Benzersiz test sürüşü oturum kimliği (GUID)	b8c8693e-5673-449c-badd-257a405a6dee

Baseuri

Test sürücüsü bu parametreyi dağıtım paketinizin Temel Uri'si ile başlatır, böylece bu parametreyi kullanarak paketinize dahil edilen herhangi bir dosyanın Uri'sini oluşturabilirsiniz.

Not

baseUri parametresi özel betik uzantısıyla birlikte kullanılamaz.

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

Test sürüşü dağıtım paketinizdeki herhangi bir dosyanın Uri'sini oluşturmak için şablonunuzun içinde bu parametreyi kullanın. Aşağıdaki örnekte, bağlantılı şablonun Uri'sinin nasıl uri'si oluşturacakları gösterilmektedir:

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

username

Test sürüşü bu parametreyi yeni bir rastgele kullanıcı adıyla başlatır:

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

Örnek değer: admin68876

Çözümünüz için rastgele veya sabit kullanıcı adları kullanabilirsiniz.

password

Test sürüşü bu parametreyi yeni bir rastgele parolayla başlatır:

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

Örnek değer: Lp!ACS^2kh

Çözümünüz için rastgele veya sabit parolalar kullanabilirsiniz.

oturum kimliği

Test sürücüsü bu parametreyi Test sürüşü oturum kimliğini temsil eden benzersiz bir GUID ile başlatır:

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

Örnek değer: b8c8693e-5673-449c-badd-257a405a6dee

Gerekirse test sürüşü oturumunu benzersiz olarak tanımlamak için bu parametreyi kullanabilirsiniz.

Benzersiz Adlar

Depolama hesapları veya DNS adları gibi bazı Azure kaynakları genel olarak benzersiz adlar gerektirir. Bu, test sürüşü ARM şablonunu her dağıttığında, tüm kaynakları için benzersiz bir ada sahip yeni bir kaynak grubu oluşturduğu anlamına gelir. Bu nedenle, rastgele benzersiz değerler oluşturmak için kaynak grubu kimliklerinde değişken adlarınızla birleştirilmiş uniquestring işlevini kullanmanız gerekir:

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

Parametre/değişken dizelerinizi (contosovm) benzersiz bir dize çıkışıresourceGroup().id () ile birleştirdiğinizden emin olun çünkü bu, her değişkenin benzersizliğini ve güvenilirliğini garanti eder.

Örneğin, kaynak adlarının çoğu bir rakamla başlayamaz, ancak benzersiz dize işlevi bir rakamla başlayan bir dize döndürebilir. Bu nedenle ham benzersiz dize çıkışı kullanırsanız dağıtımlarınız başarısız olur.

Kaynak adlandırma kuralları ve kısıtlamaları hakkında ek bilgileri bu makalede bulabilirsiniz.

Dağıtım Konumu

Test sürüşünüzü farklı Azure bölgelerinde kullanılabilir hale getirebilirsiniz.

Test sürüşü Laboratuvarın bir örneğini oluşturduğunda, her zaman seçili bölgelerden birinde bir kaynak grubu oluşturur ve ardından dağıtım şablonunuzu bu grup bağlamında yürütür. Bu nedenle, şablonunuz kaynak grubundan dağıtım konumunu seçmelidir:

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

Ardından bu konumu belirli bir Laboratuvar örneği için her kaynak için kullanın:

"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')]",
    ...
  }
]

Aboneliğinizin seçtiğiniz her bölgede istediğiniz tüm kaynakları dağıtmasına izin verildiğinden emin olun. Ayrıca, sanal makine görüntülerinizin etkinleştirilecek tüm bölgelerde kullanılabildiğinden emin olun; aksi takdirde dağıtım şablonunuz bazı bölgelerde çalışmaz.

Çıkışlar

Normalde Resource Manager şablonlarıyla herhangi bir çıkış oluşturmadan dağıtabilirsiniz. Bunun nedeni, şablon parametrelerini doldurmak için kullandığınız tüm değerleri bilmeniz ve her zaman herhangi bir kaynağın özelliklerini el ile inceleyebilmenizdir.

Ancak, test sürüşü Resource Manager şablonları için, laboratuvara erişmek için gereken tüm bilgileri (Web Sitesi URI'leri, Sanal Makine ana bilgisayar adları, kullanıcı adları ve parolalar) test sürüşü için geri dönmek önemlidir. Bu değişkenler müşteriye sunulduğundan tüm çıkış adlarınızın okunabilir olduğundan emin olun.

Şablon çıkışlarıyla ilgili herhangi bir kısıtlama yoktur. Test sürüşü tüm çıkış değerlerini dizelere dönüştürür, bu nedenle çıkışa bir nesne gönderirseniz kullanıcı JSON dizesini görür.

Örnek:

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

Abonelik Sınırları

Abonelik ve hizmet sınırlarını unutmayın. Örneğin, en fazla on adet 4 çekirdekli sanal makine dağıtmak istiyorsanız, laboratuvarınız için kullandığınız aboneliğin 40 çekirdek kullanmanıza izin verdiğinden emin olmanız gerekir. Azure aboneliği ve hizmet sınırları hakkında daha fazla bilgi için bkz. Azure aboneliği ve hizmet sınırları, kotalar ve kısıtlamalar. Aynı anda birden çok test sürücüsü alınabileceğinden, aboneliğinizin çekirdeğe sahip çekirdek sayısını alınabilecek toplam eş zamanlı test sürücüsü sayısıyla çarparak işleyebildiğini doğrulayın.

Karşıya yüklenecekler

Test sürüşü ARM şablonu, çeşitli dağıtım yapıtları içerebilen ancak adlı main-template.jsonbir dosyaya sahip olması gereken bir zip dosyası olarak karşıya yüklenir. Bu, test sürüşü tarafından bir laboratuvarın örneğini oluşturmak için kullanılan ARM dağıtım şablonudur. Bu dosyanın ötesinde başka kaynaklarınız varsa, bunlara şablonun içinde dış kaynak olarak başvurabilir veya zip dosyasına ekleyebilirsiniz.

Yayımlama sertifikası sırasında, test sürüşü dağıtım paketinizi çıkarır ve içeriğini bir iç test sürüşü blob kapsayıcısına yerleştirir. Kapsayıcı yapısı, dağıtım paketinizin yapısını yansıtır:

package.zip	Test sürüşü blob kapsayıcısı
`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`

Bu blob kapsayıcısı Temel Uri'sinin Uri'sini adlandırıyoruz. Laboratuvarınızın her düzeltmesinin kendi blob kapsayıcısı olduğundan, laboratuvarınızın her düzeltmesinin kendi Temel Uri'leri vardır. Test sürüşü, sıkıştırması açılmış dağıtım paketinizin Temel Uri'sini şablon parametreleri aracılığıyla şablonunuz içine geçirebilir.

Test sürüşü için şablon örneklerini dönüştürme

Kaynak mimarisini test sürüşü Resource Manager şablonuna dönüştürme işlemi göz korkutucu olabilir. Ek yardım için geçerli dağıtım şablonlarını en iyi şekilde dönüştürme örnekleri için test sürüşü nedir? konusuna bakın.

Test sürüşü dağıtımı abonelik ayrıntıları

Tamamlanacak son bölüm, Azure Aboneliğinizi ve Azure Active Directory'yi (AD) bağlayarak test sürücülerini otomatik olarak dağıtabilmektir.

Test sürüşü dağıtımı abonelik ayrıntıları

Bir Azure Abonelik Kimliği alın. Bu, Azure hizmetlerine ve Azure portal erişim verir. Abonelik, kaynak kullanımının bildirildiği ve hizmetlerin faturalandırıldığı yerdir. Yalnızca test sürüşleri için ayrı bir Azure aboneliğiniz yoksa bir abonelik oluşturun. Azure portal'de oturum açıp sol gezinti menüsünden Abonelikler'i seçerek Azure Abonelik Kimliklerini (örneğin1a83645ac-1234-5ab6-6789-1h234g764ghty1) bulabilirsiniz.
Azure AD Kiracı Kimliği alın. Zaten kullanılabilir bir Kiracı Kimliğiniz varsa, bunu Azure Active Directory>Özellikleri>Dizin Kimliği'nde bulabilirsiniz:

Kiracı kimliğiniz yoksa Azure Active Directory'de yeni bir kimlik oluşturun. Kiracı ayarlama konusunda yardım için bkz . Hızlı Başlangıç: Kiracı ayarlama.
Microsoft Test-Drive uygulamasını kiracınıza sağlayın. Test sürüşü kaynaklarınızda işlemler gerçekleştirmek için bu uygulamayı kullanacağız.
1. Henüz sahip değilseniz Azure Az PowerShell modülünü yükleyin.
2. Microsoft Test-Drive uygulaması için Hizmet Sorumlusunu ekleyin.
  1. Azure hesabınızda oturum açmak için Azure Active Directory Genel Yöneticisiyerleşik rolünü gerektiren kimlik bilgilerini çalıştırın Connect-AzAccount ve sağlayın.
  2. Yeni bir hizmet sorumlusu oluşturun: New-AzADServicePrincipal -ApplicationId d7e39695-0b24-441c-a140-047800a05ede -DisplayName 'Microsoft TestDrive'.
  3. Hizmet sorumlusunun oluşturulduğundan emin olun: Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive'.
Azure AD Uygulama Kimliği için şu Uygulama Kimliği'ne yapıştırın: d7e39695-0b24-441c-a140-047800a05ede.
Azure AD Uygulama Anahtarı için gizli dizi gerekli olmadığından"gizli dizi yok" gibi sahte bir gizli dizi ekleyin.
Uygulamayı aboneliğe dağıtmak için kullandığımızdan, uygulamayı Azure portal veya PowerShell'den aboneliğe katkıda bulunan olarak eklememiz gerekir:
1. Azure portalından:
  1. Test sürüşü için kullanılan aboneliği seçin.
  2. Erişim denetimi (IAM) öğesini seçin.
  3. Rol ataması ekle'yi >seçin.
  4. Rol sekmesinde Katkıda Bulunan'ı seçin.
  5. Üyeler sekmesinde Kullanıcı, grup veya hizmet sorumlusu'na ve ardından Üye seç'e tıklayın.
  6. Daha önce oluşturduğunuz Microsoft TestDrive hizmet sorumlusunu seçin.
  7. Gözden geçirme + atama sekmesinde Gözden geçir + ata’yı seçerek rolü atayın.
    
    Rol atamaları hakkında daha fazla bilgi için bkz. Azure portal kullanarak Azure rolleri atama
2. PowerShell kullanılıyorsa:
  1. ServicePrincipal object-id değerini almak için bunu çalıştırın: (Get-AzADServicePrincipal -DisplayName 'Microsoft TestDrive').id.
  2. Bunu ObjectId ve abonelik kimliğiyle çalıştırın: New-AzRoleAssignment -ObjectId <objectId> -RoleDefinitionName Contributor -Scope /subscriptions/<subscriptionId>.

Not

Eski appID'yi silmeden önce Azure portal gidin, ardından Kaynak grupları'na gidin ve araması yapınCloudTry_. Olay tarafından başlatılan sütununu denetleyin.

En az bir kaynak (İşlem adı) Microsoft TestDrive olarak ayarlanmadığı sürece eski appID'yi silmeyin.

appID'yi silmek için sol gezinti menüsünde Azure Active Directory>Uygulama Kayıtları'nı ve ardından Tüm uygulamalar sekmesini seçin. Uygulamanızı seçin ve Sil'i seçin.

Yeniden yayımlama

Tüm test sürüşü alanlarınız tamamlandıktan sonra teklifinizi yeniden yayımlayın . Test sürüşü sertifikayı geçtikten sonra teklifinizin önizlemesinde müşteri deneyimini test edin:

Kullanıcı arabiriminde bir test sürüşü başlatın.
Azure aboneliğinizi Azure portal açın.
Test sürücünüzün doğru dağıtıldığını doğrulayın.

Müşterileriniz için sağlanan test sürüşü örneklerini silmeyin; test sürüşü hizmeti, bir müşteri tarafından tamamlandıktan sonra bu Kaynak Gruplarını otomatik olarak temizler.

Önizleme teklifinizi rahatça kullanmaya başlayın, artık canlı yayına geçebilirsiniz! Uçtan uca deneyimin tamamını bir kez daha kontrol etmek için son bir gözden geçirme işlemi vardır. Teklifi reddedersek, teklifiniz için mühendislik ilgili kişisine neyin düzeltilmesi gerektiğini açıklayan bir e-posta göndereceğiz.

Sonraki adımlar

İş Ortağı Merkezi'nde teklifinizi oluşturmak için yönergeleri izliyorsanız, bu konuya dönmek için Geri okunu kullanın.
Diğer test sürüşü türleri hakkında daha fazla bilgi için bkz. Test sürüşü nedir?.

Azure Resource Manager test sürüşü

Teknik yapılandırma

Test sürüşü şablonunu yazma

Parametreler

Kabul Edilen Parametre Meta Veri Türleri

Baseuri

username

password

oturum kimliği

Benzersiz Adlar

Dağıtım Konumu

Çıkışlar

Abonelik Sınırları

Karşıya yüklenecekler

Test sürüşü için şablon örneklerini dönüştürme

Test sürüşü dağıtımı abonelik ayrıntıları

Yeniden yayımlama

Sonraki adımlar

Ek kaynaklar

Ek kaynaklar