Azure DevTest Labs altyapısının idaresi

Bu makale, kuruluşunuzdaki DevTest Labs kaynaklarının hizalamasını ve yönetimini ele alır.

Kaynaklar

Azure aboneliği içindeki DevTest Labs kaynaklarını hizalama

Bir kuruluş genel uygulama geliştirme için Azure'ı kullanmaya başlamadan önce BT planlayıcılarının genel hizmet portföylerinin bir parçası olarak bu özelliği nasıl tanıtacaklarını gözden geçirmeleri gerekir. Gözden geçirme alanları aşağıdaki endişeleri gidermelidir:

• Uygulama geliştirme yaşam döngüsüyle ilişkili maliyet nasıl ölçülür?
• Kuruluş, önerilen hizmet teklifini kurumsal güvenlik ilkesiyle nasıl uyumlu hale getirmeli?
• Geliştirme ve üretim ortamlarını ayırmak için segmentasyon gerekli mi?
• Uzun vadeli yönetim, kararlılık ve büyüme kolaylığı için hangi denetimler kullanıma sunulmuştur?

Önerilen ilk uygulama , kuruluşların üretim ve geliştirme abonelikleri arasındaki bölümlerin özetlendiği Azure taksonomisini gözden geçirmektir. Aşağıdaki diyagramda, önerilen taksonomi geliştirme/test ve üretim ortamlarının mantıksal ayrımını sağlar. Bu yaklaşımla kuruluş, her ortamla ilişkili maliyetleri ayrı ayrı izlemek için faturalama kodları ekleyebilir. Daha fazla bilgi için bkz . Açıklayıcı abonelik idaresi. Ayrıca, izleme ve faturalama amacıyla kaynakları düzenlemek için Azure etiketlerini kullanabilirsiniz.

Önerilen ikinci uygulama , Azure Enterprise portalda DevTest aboneliğini etkinleştirmektir. Bir kuruluşun normalde Azure kurumsal aboneliğinde bulunmayan istemci işletim sistemlerini çalıştırmasına olanak tanır. Ardından, yalnızca işlem için ödeme yaptığınız ve lisanslama konusunda endişelenmediğiniz kurumsal yazılımları kullanın. Microsoft SQL Server gibi IaaS'deki galeri görüntüleri de dahil olmak üzere belirlenen hizmetler için faturalamanın yalnızca tüketime dayalı olmasını sağlar. Azure DevTest aboneliğiyle ilgili ayrıntıları Kurumsal Anlaşma (EA) müşterileri için burada ve Kullandıkça Öde müşterileri için burada bulabilirsiniz.

Bu model, bir kuruluşa Azure DevTest Labs'i büyük ölçekte dağıtma esnekliği sağlar. Bir kuruluş, paralel olarak çalışan 100 ile 1000 arası sanal makine ile çeşitli iş birimleri için yüzlerce laboratuvarı destekleyebilir. Yapılandırma yönetimi ve güvenlik denetimlerinin aynı ilkelerini paylaşabilen merkezi bir kurumsal laboratuvar çözümü anlayışını teşvik eder.

Bu model, kuruluşun Azure aboneliğiyle ilişkili kaynak sınırlarını tüketmemesini de sağlar. Abonelik ve hizmet sınırları hakkında ayrıntılı bilgi için bkz . Azure aboneliği ve hizmet sınırları, kotalar ve kısıtlamalar. DevTest Labs sağlama işlemi çok sayıda kaynak grubu kullanabilir. Azure DevTest aboneliğindeki bir destek isteği aracılığıyla sınırların artırılmasını isteyebilirsiniz. Geliştirme aboneliği kullanımda büyüdükçe üretim aboneliğindeki kaynaklar etkilenmez. DevTest Labs'i ölçeklendirme hakkında daha fazla bilgi için bkz . DevTest Labs'de kotaları ve sınırları ölçeklendirme.

Hesaba bağlanması gereken yaygın bir abonelik düzeyi sınırı, ağ IP aralığı atamalarının hem üretim hem de geliştirme aboneliklerini desteklemek için nasıl ayrıldığıdır. Bu atamalar zaman içinde büyümeyi dikkate almalıdır (şirket içi bağlantı veya kuruluşun Azure'ın uygulamasını varsayılan olarak kullanmak yerine ağ yığınını yönetmesini gerektiren başka bir ağ topolojisi varsayılarak). Önerilen uygulama, küçük alt ağlara sahip birden çok sanal ağa sahip olmak yerine, atanmış ve birçok büyük alt ağa bölünmüş büyük IP adresi ön ekine sahip birkaç sanal ağın olmasıdır. Örneğin, 10 abonelikle 10 sanal ağ tanımlayabilirsiniz (her abonelik için bir tane). Yalıtım gerektirmeyen tüm laboratuvarlar aboneliğin sanal ağında aynı alt ağı paylaşabilir.

Kuruluş başına laboratuvar ve laboratuvar başına kullanıcı sayısı

Aynı geliştirme projesiyle ilişkili iş birimleri ve geliştirme grupları aynı laboratuvarla ilişkilendirilmelidir. Aynı tür ilkelerin, görüntülerin ve kapatma ilkelerinin her iki gruba da uygulanmasını sağlar.

Coğrafi sınırları da göz önünde bulundurmanız gerekebilir. Örneğin, kuzey doğu Birleşik Devletler (ABD) geliştiricileri Doğu ABD2'de sağlanan bir laboratuvarı kullanabilir. Dallas, Texas ve Denver, Colorado'daki geliştiriciler de ORTA Güney ABD'deki bir kaynağı kullanmaya yönlendirilebilir. Bir üçüncü tarafla işbirliğine dayalı bir çalışma varsa, şirket içi geliştiriciler tarafından kullanılmayan bir laboratuvara atanabilir.

Azure DevOps Projeleri içindeki belirli bir proje için de laboratuvar kullanabilirsiniz. Ardından, güvenliği belirtilen bir Microsoft Entra grubu aracılığıyla uygularsınız ve bu da her iki kaynak kümesine de erişim sağlar. Laboratuvara atanan sanal ağ, kullanıcıları birleştirmek için başka bir sınır olabilir.

Kaynakların silinmesini önleme

Yalnızca yetkili kullanıcıların kaynakları silmesi veya laboratuvar ilkelerini değiştirmesi için izinleri laboratuvar düzeyinde ayarlayın. Geliştiriciler DevTest Labs Kullanıcıları grubuna yerleştirilmelidir. Baş geliştirici veya altyapı lideri DevTest Labs Sahibi olmalıdır. Yalnızca iki laboratuvar sahibiniz olması önerilir. Bu ilke bozulmayı önlemek için kod deposuna doğru genişletir. Laboratuvar kullanımları kaynakları kullanma haklarına sahiptir ancak laboratuvar ilkelerini güncelleştiremez. Her yerleşik grubun bir laboratuvarda sahip olduğu rolleri ve hakları listeleyen aşağıdaki makaleye bakın: Azure DevTest Labs'de sahip ve kullanıcı ekleme.

Maliyeti ve sahipliği yönetme

Geliştirme ve test ortamlarınızı oluşturmayı göz önünde bulundurarak maliyet ve sahiplik önceliklidir. Bu bölümde, maliyeti iyileştirmenize ve ortamınızdaki sahipliği uyumlu hale getirmenize yardımcı olacak bilgiler bulacaksınız.

Maliyet için iyileştirme

DevTest Labs'in çeşitli yerleşik özellikleri, maliyeti iyileştirmenize yardımcı olur. Kullanıcılarınızın etkinliklerini sınırlamak için maliyet yönetimi, eşikler ve ilkeler makalelerine bakın.

Geliştirme ve test iş yükleri için DevTest Labs kullanıyorsanız, Kurumsal Anlaşma parçası olan Kurumsal Geliştirme/Test Aboneliği Avantajı'nı kullanmayı göz önünde bulundurun. Alternatif olarak Kullandıkça Öde müşterisiyseniz Kullandıkça öde DevTest teklifini de göz önünde bulundurun.

Bu yaklaşım çeşitli avantajlar sağlar:

• Windows sanal makinelerinde, bulut hizmetlerinde, HDInsight'ta, App Service'te ve Logic Apps'te özel daha düşük Geliştirme/Test oranları
• Diğer Azure hizmetlerinde harika Kurumsal Anlaşma (EA) fiyatları
• Windows 8.1 ve Windows 10 görüntüleri dahil olmak üzere Galeri'deki özel Geliştirme ve Test görüntülerinin tamamına erişme olanağı

Yalnızca etkin Visual Studio aboneleri (standart abonelikler, yıllık bulut abonelikleri ve aylık bulut abonelikleri) kurumsal Geliştirme/Test aboneliğinde çalışan Azure kaynaklarını kullanabilir. Ancak, son kullanıcılar geri bildirim sağlamak veya kabul testi yapmak için uygulamaya erişebilir. Bu abonelik içindeki kaynakları yalnızca uygulama geliştirme ve test etme amacıyla kullanabilirsiniz. Çalışma süresi garantisi yoktur.

DevTest teklifini kullanmaya karar verirseniz, bu avantajı yalnızca uygulama geliştirme ve test etme amacıyla kullanın. Abonelik içindeki kullanım, Azure DevOps ve HockeyApp kullanımı dışında finansal olarak desteklenen bir SLA taşımaz.

Kuruluşunuz genelinde rol tabanlı erişim tanımlama

Merkezi BT yalnızca gerekli olan şeylere sahip olmalı ve proje ve uygulama ekiplerinin gerekli denetim düzeyine sahip olmasını sağlamalıdır. Genellikle, merkezi BT'nin aboneliğe sahip olduğu ve ağ yapılandırmaları gibi temel BT işlevlerini işlediği anlamına gelir. Bir aboneliğin sahip kümesi küçük olmalıdır. Bu sahipler, ihtiyaç olduğunda diğer sahipleri belirleyebilir veya "Genel IP Yok" gibi abonelik düzeyinde ilkeler uygulayabilir.

Katman 1 veya Katman 2 desteği gibi abonelik genelinde erişim gerektiren bir kullanıcı alt kümesi olabilir. Bu durumda, bu kullanıcılara kaynakları yönetebilmeleri, ancak kullanıcı erişimi sağlamamaları veya ilkeler ayarlamaları için katkıda bulunan erişimi vermenizi öneririz.

DevTest Labs kaynak sahipleri proje veya uygulama ekibine yakın olmalıdır. Bu sahipler makine ve yazılım gereksinimlerini anlar. Çoğu kuruluşta DevTest Labs kaynağının sahibi proje veya geliştirme lideridir. Bu sahip, laboratuvar ortamında kullanıcıları ve ilkeleri yönetebilir ve DevTest Labs ortamındaki tüm sanal makineleri yönetebilir.

DevTest Labs Kullanıcıları rolüne proje ve uygulama ekibi üyeleri ekleyin. Bu kullanıcılar laboratuvar ve abonelik düzeyi ilkelerine uygun olarak sanal makineler oluşturabilir. Kullanıcılar kendi sanal makinelerini de yönetebilir, ancak diğer kullanıcılara ait sanal makineleri yönetemez.

Daha fazla bilgi için bkz . Azure kurumsal iskelesi – açıklayıcı abonelik idaresi.

Şirket ilkesi ve uyumluluğu

Bu bölümde, Azure DevTest Labs altyapısı için şirket ilkesini ve uyumluluğunu idare etme konusunda rehberlik sağlanır.

Genel ve özel yapıt deposu karşılaştırması

Ortak yapıt deposu , en yaygın olarak kullanılan ilk yazılım paketleri kümesini sağlar. Yaygın geliştirici araçlarını ve eklentilerini yeniden oluşturmak için zaman harcamadan hızlı dağıtıma yardımcı olur. Kendi özel depolarını dağıtmayı seçebilirsiniz. Ortak ve özel depoları paralel olarak kullanabilirsiniz. Genel depoyu devre dışı bırakabilirsiniz. Özel depo dağıtma ölçütleri aşağıdaki sorulara ve dikkat edilmesi gereken noktalara göre yönlendirilmelidir:

• Kuruluşun DevTest Labs teklifinin bir parçası olarak kurumsal lisanslı yazılıma sahip olma gereksinimi var mı? Yanıt evet ise özel bir depo oluşturulmalıdır.
• Kuruluş, genel sağlama sürecinin bir parçası olarak gerekli olan belirli bir işlemi sağlayan özel yazılım geliştiriyor mu? Yanıt evet ise, özel bir depo dağıtılmalıdır.
• Kuruluşun idare ilkesi yalıtım gerektiriyorsa ve dış depolar kuruluş tarafından doğrudan yapılandırma yönetimi altında değilse, özel yapıt deposu dağıtılmalıdır. Bu işlemin bir parçası olarak, ortak deponun ilk kopyası kopyalanabilir ve özel depoyla tümleştirilebilir. Daha sonra, kuruluştaki hiç kimsenin erişebilmesi için genel depo devre dışı bırakılabilir. Bu yaklaşım, kuruluştaki tüm kullanıcıları kuruluş tarafından onaylanan tek bir depoya sahip olacak ve yapılandırma kaymasını en aza indirecek şekilde zorlar.

Tek depo veya birden çok depo

Kuruluşunuzun genel idare ve yapılandırma yönetimi stratejisinin bir parçası olarak merkezi bir depo kullanmanızı öneririz. Birden çok depo kullandığınızda, bunlar zaman içinde yönetilmeyen yazılımların siloları haline gelebilir. Merkezi bir depoyla, birden çok ekip projeleri için bu depodan yapıtları kullanabilir. Standartlaştırmayı, güvenliği, yönetim kolaylığını zorlar ve çabaların yinelenmesini ortadan kaldırır. Merkezileştirme kapsamında, uzun vadeli yönetim ve sürdürülebilirlik için aşağıdaki eylemler önerilir:

• Azure Repos'u Azure aboneliğinin kimlik doğrulaması ve yetkilendirme için kullandığı Microsoft Entra kiracısıyla ilişkilendirin.
• Merkezi olarak yönetilen Microsoft Entra Id'de Tüm DevTest Labs Developers adlı bir grup oluşturun. Yapıt geliştirmeye katkıda bulunan tüm geliştiriciler bu gruba yerleştirilmelidir.
• Azure Repos deposuna ve laboratuvara erişim sağlamak için aynı Microsoft Entra grubu kullanılabilir.
• Azure Repos'ta dallanma veya çatal oluşturma, birincil üretim deposundan ayrı bir geliştirme deposuna kullanılmalıdır. İçerik, yalnızca doğru bir kod gözden geçirmesinin ardından çekme isteğiyle ana dala eklenir. Kod gözden geçiren değişikliği onayladıktan sonra, ana dalın bakımdan sorumlu olan baş geliştirici güncelleştirilmiş kodu birleştirir.

Kurumsal güvenlik ilkeleri

Bir kuruluş, şirket güvenlik ilkelerini şu şekilde uygulayabilir:

• Kapsamlı bir güvenlik ilkesi geliştirme ve yayımlama. İlke, kullanım yazılımı, bulut varlıklarıyla ilişkili kabul edilebilir kullanım kurallarını ifade eder. Ayrıca ilkeyi açıkça ihlal eden şeyleri tanımlar.
• Active Directory ile tanımlanan güvenlik bölgesi içinde düzenlemeye olanak tanıyan özel görüntü, özel yapıtlar ve dağıtım işlemi geliştirme. Bu yaklaşım kurumsal sınırı zorlar ve ortak bir ortam denetimleri kümesi ayarlar. Bir geliştiricinin genel sürecinin bir parçası olarak güvenli bir geliştirme yaşam döngüsünü geliştirirken ve takip ederken değerlendirebileceği ortama yönelik bu denetimler. Amaç ayrıca geliştirmeyi engelleyebilecek aşırı kısıtlayıcı olmayan bir ortam sağlamak, ancak makul bir denetim kümesi sağlamaktır. Laboratuvar sanal makinelerini içeren kuruluş birimindeki (OU) grup ilkeleri, üretimde bulunan toplam grup ilkelerinin bir alt kümesi olabilir. Alternatif olarak, belirlenen riskleri düzgün bir şekilde azaltmak için başka bir küme olabilir.

Veri bütünlüğü

Kuruluş, uzaktan iletişim geliştiricilerin kodu kaldıramamasını, kötü amaçlı yazılım veya onaylanmamış yazılım tanıtmamasını sağlamak için veri bütünlüğünü sağlayabilir. DevTest Labs'de işbirliği yapmak için uzaktan iletişimde olan dış danışmanların, yüklenicilerin veya çalışanların tehdidini azaltmak için çeşitli denetim katmanları vardır.

Daha önce belirtildiği gibi, ilk adımın, birisi ilkeyi ihlal ettiğinde sonuçlarını açıkça özetleyen kabul edilebilir bir kullanım ilkesinin hazırlanması ve tanımlanması gerekir.

Uzaktan erişim için ilk denetim katmanı, laboratuvara doğrudan bağlı olmayan bir VPN bağlantısı aracılığıyla uzaktan erişim ilkesi uygulamaktır.

İkinci denetim katmanı, uzak masaüstü aracılığıyla kopyalayıp yapıştırmayı engelleyen bir grup ilkesi nesneleri kümesi uygulamaktır. FTP ve RDP hizmetleri gibi ortamdan giden hizmetlere ortamdan izin verilmemesi için bir ağ ilkesi uygulanabilir. Kullanıcı tanımlı yönlendirme, tüm Azure ağ trafiğini şirket içi ortamına geri döndürmeye zorlayabilir, ancak yönlendirme, içeriği ve oturumları taramak için bir ara sunucu aracılığıyla denetlenmediği sürece verilerin karşıya yüklenmesine izin verebilecek tüm URL'leri hesaba aktaramaz. Genel IP'ler DevTest Labs'i destekleyen sanal ağ içinde bir dış ağ kaynağının köprülenmesine izin vermeyecek şekilde kısıtlanabilir.

Sonuç olarak, kuruluş genelinde aynı tür kısıtlamaların uygulanması gerekir. Bu, bir içerik gönderisini kabul edebilecek tüm olası çıkarılabilir medya yöntemlerini veya dış URL'leri de hesaba eklemek zorunda olacaktır. Güvenlik ilkesini gözden geçirmek ve uygulamak için güvenlik uzmanınıza danışın. Daha fazla öneri için bkz . Microsoft Siber Güvenlik.

Uygulama geçişi ve tümleştirmesi

Geliştirme/test laboratuvarı ortamınız oluşturulduktan sonra aşağıdaki soruları düşünmeniz gerekir:

• Proje ekibinizin içindeki ortamı nasıl kullanırsınız?
• Gerekli kuruluş ilkelerini izlediğinizden ve uygulamanıza değer katmak için çevikliği koruduğunuzdan nasıl emin olursunuz?

Azure Market görüntüleriyle özel görüntüleri karşılaştırma

Azure Market, belirli endişeleriniz veya kuruluş gereksinimleriniz olmadığı sürece varsayılan olarak kullanılmalıdır. Bazı yaygın örnekler şunlardır:

• Temel görüntünün parçası olarak bir uygulamanın eklenmesini gerektiren karmaşık yazılım kurulumu.
• Bir uygulamanın yüklenmesi ve kurulumu saatler sürebilir; bu, Azure Market bir görüntüye eklenmesi için işlem süresinin verimli bir şekilde kullanılması değildir.
• Geliştiriciler ve test ediciler, bir sanal makineye hızlı bir şekilde erişim gerektirir ve yeni bir sanal makinenin kurulum süresini en aza indirmek ister.
• Tüm makineler için geçerli olması gereken uyumluluk veya mevzuat koşulları (örneğin, güvenlik ilkeleri).

Özel görüntüleri dikkatle kullanmayı göz önünde bulundurun. Artık temel alınan temel görüntüler için VHD dosyalarını yönetmeniz gereken özel görüntüler daha karmaşık hale geliyor. Ayrıca bu temel görüntüleri yazılım güncelleştirmeleriyle düzenli olarak düzeltme eki uygulamanız gerekir. Bu güncelleştirmeler, yeni işletim sistemi (OS) güncelleştirmelerini ve yazılım paketinin kendisi için gereken tüm güncelleştirmeleri veya yapılandırma değişikliklerini içerir.

Formül ve özel görüntü karşılaştırması

Bu senaryodaki belirleyici faktör genellikle maliyet ve yeniden kullanımdır.

Şu durumlarda özel görüntü oluşturarak maliyeti düşürebilirsiniz:

• Birçok kullanıcı veya laboratuvar için görüntü gerekir.
• Gerekli görüntünün temel görüntünün üzerinde çok fazla yazılım vardır.

Bu çözüm, görüntüyü bir kez oluşturduğunuz anlamına gelir. Özel görüntü, sanal makinenin kurulum süresini azaltır. Kurulum sırasında sanal makineyi çalıştırma maliyetlerine neden olmazsınız.

Bir diğer faktör de yazılım paketinizdeki değişikliklerin sıklığıdır. Günlük derlemeler çalıştırıyorsanız ve bu yazılımın kullanıcılarınızın sanal makinelerinde olmasını gerektiriyorsanız, özel görüntü yerine bir formül kullanmayı göz önünde bulundurun.

Ağ yapılandırmasını ayarlamak için desenler

Geliştirme ve test sanal makinelerinin genel İnternet'e erişemediğinden emin olduğunuzda dikkate alınması gereken iki nokta vardır: gelen ve giden trafik.

Gelen trafik : Sanal makinenin genel IP adresi yoksa İnternet bu adrese ulaşamaz. Yaygın bir yaklaşım, hiçbir kullanıcının genel IP adresi oluşturamayan bir abonelik düzeyi ilkesi ayarlamaktır.

Giden trafik : Sanal makinelerin doğrudan genel İnternet'e geçmesini engellemek ve şirket güvenlik duvarı üzerinden trafiği zorlamak istiyorsanız, zorlamalı yönlendirmeyi kullanarak Azure ExpressRoute veya VPN aracılığıyla şirket içi trafiği yönlendirebilirsiniz.

Sanal makineler veya alt ağlar için ağ güvenlik gruplarını da kullanabilirsiniz. Bu adım, trafiğe izin vermek veya trafiği engellemek için başka bir koruma katmanı ekler.

Yeni ve mevcut sanal ağ karşılaştırması

VM'lerinizin mevcut altyapıyla etkileşim kurması gerekiyorsa DevTest Labs ortamınızda mevcut bir sanal ağı kullanmayı düşünmelisiniz. ExpressRoute kullanıyorsanız, aboneliklerinize atanan IP adresi alanını parçalamamak için sanal ağ ve alt ağ sayısını en aza indirin. Ayrıca burada sanal ağ eşleme desenini kullanmayı da göz önünde bulundurun (Hub-Spoke modeli). Bu yaklaşım, belirli bir bölgedeki abonelikler arasında sanal ağ ve alt ağ iletişimi sağlar.

Her DevTest Labs ortamının kendi sanal ağı olabilir, ancak abonelik başına sanal ağ sayısıyla ilgili sınırlar vardır. Varsayılan tutar 50'dir, ancak bu sınır 100'e yükseltilebilir.

Paylaşılan, genel veya özel IP

Siteden siteye VPN veya Express Route kullanıyorsanız makinelerinize iç ağınız üzerinden ve genel İnternet üzerinden erişilemeyecek şekilde özel IP'ler kullanmayı göz önünde bulundurun.

Paylaşılan genel IP'leri kullanırken, laboratuvardaki sanal makineler genel IP adresini paylaşır. Bu yaklaşım, belirli bir abonelik için genel IP adreslerindeki sınırları ihlal etmekten kaçınmanız gerektiğinde yararlı olabilir.

Laboratuvar sınırları

Bilmeniz gereken birkaç laboratuvar sınırı vardır. Bu sınırlar aşağıdaki bölümlerde açıklanmıştır.

Abonelik başına laboratuvar sınırları

Abonelik başına oluşturulabilecek laboratuvar sayısıyla ilgili belirli bir sınır yoktur. Ancak abonelik başına kullanılan kaynak miktarı sınırlıdır. Azure aboneliklerinin sınırları ve kotaları ve bu sınırları nasıl artırabileceğinizi okuyabilirsiniz.

Laboratuvar başına VM'lerin sınırları

Laboratuvar başına oluşturulabilecek VM sayısıyla ilgili belirli bir sınır yoktur. Ancak, kullanılan kaynaklar (VM çekirdekleri, genel IP adresleri vb.) abonelik başına sınırlıdır. Azure aboneliklerinin sınırları ve kotaları ve bu sınırları nasıl artırabileceğinizi okuyabilirsiniz.

Kullanıcı veya laboratuvar başına sanal makine sayısı sınırları

Kullanıcı başına veya laboratuvar başına sanal makine sayısını dikkate aldığınızda üç temel sorun vardır:

• Ekibin laboratuvardaki kaynaklara harcayabileceği genel maliyet. Birçok makineyi çalıştırmak kolaydır. Maliyetleri denetlemek için bir mekanizma, kullanıcı başına veya laboratuvar başına VM sayısını sınırlamaktır
• Laboratuvardaki toplam sanal makine sayısı, kullanılabilir abonelik düzeyi kotalarından etkilenir. Üst sınırlardan biri abonelik başına 800 kaynak grubudur. DevTest Labs şu anda her VM için yeni bir kaynak grubu oluşturur (paylaşılan genel IP'ler kullanılmadığı sürece). Abonelikte 10 laboratuvar varsa laboratuvarlar her laboratuvara yaklaşık 79 sanal makine (800 üst sınır – 10 laboratuvar için 10 kaynak grubu) = laboratuvar başına 79 sanal makine sığabilir.
• Laboratuvar Express Route aracılığıyla şirket içi ağa bağlıysa (örneğin), sanal ağ/alt ağ için tanımlı IP adresi alanları vardır . Laboratuvardaki VM'lerin oluşturulamamasından emin olmak için (hata: IP adresi alınamıyor), laboratuvar sahipleri kullanılabilir IP adresi alanıyla hizalanmış laboratuvar başına maksimum VM'leri belirtebilir.

Resource Manager şablonlarını kullanma

Test ortamları için Azure DevTest Labs kullanma adımlarını kullanarak Resource Manager şablonlarınızı dağıtın. Temel olarak, Resource Manager şablonlarınızı bir Azure Repos veya GitHub Git deposunda denetler ve şablonlarınız için laboratuvara özel bir depo eklersiniz.

Geliştirme makinelerini barındırmak için DevTest Labs kullanıyorsanız bu senaryo yararlı olmayabilir. Bu senaryo, üretimi temsil eden bir hazırlama ortamı oluşturmak için kullanın.

Laboratuvar başına veya kullanıcı başına sanal makine sayısı seçeneği yalnızca laboratuvarın kendisinde yerel olarak oluşturulan makinelerin sayısını sınırlar. Bu seçenek, Resource Manager şablonlarıyla herhangi bir ortam tarafından oluşturulmasını sınırlamaz.