Azure DevTest Labs altyapınızın ölçeğini artırma

DevTest Labs'in kurumsal ölçekte başarılı bir şekilde uygulanması için önemli karar noktalarının dikkate alınması ve Azure DevTest Labs'in hızlı dağıtımı ve uygulanması için bir yaklaşım planlanması gerekir.

Bu makalede, uygulamanızı planlarken göz önünde bulundurmanız gereken önemli karar noktaları açıklanır ve dağıtım için önerilen bir yaklaşım sağlanır.

Önemli karar noktaları

DevTest Labs'i kurumsal ölçekte uygulamadan önce birkaç önemli karar noktası vardır. Bu karar noktalarını üst düzeyde anlamak, bir kuruluşun gelecekte tasarım kararları almalarına yardımcı olur. Ancak bu noktalar bir kuruluşun kavram kanıtı başlatmasını engelleyemez.

İlk ölçeklendirme planlaması için ilk üç alan şunlardır:

• Ağ ve güvenlik
• Abonelik topolojisi
• Roller ve sorumluluklar

Ağ ve güvenlik

Ağ ve güvenlik, tüm kuruluşların temel taşlarıdır. Kuruluş genelinde dağıtım çok daha derin bir analiz gerektirir ancak kavram kanıtının başarılı bir şekilde gerçekleştirilmesi için gereken gereksinimlerin sayısı azalır. Birkaç önemli odak alanı şunlardır:

• Azure aboneliği – DevTest Labs'i dağıtmak için kaynak oluşturmak için uygun haklara sahip bir Azure aboneliğine erişiminiz olmalıdır. Azure aboneliklerine erişim kazanmanın Kurumsal Anlaşma ve Kullandıkça Öde gibi çeşitli yolları vardır. Azure aboneliğine erişim kazanma hakkında daha fazla bilgi için bkz . Kuruluş için Azure'ı lisanslama.
• Şirket içi kaynaklara erişim – Bazı kuruluşlar, DevTest Labs'deki kaynaklarının şirket içi kaynaklara erişmesini gerektirir. Şirket içi ortamınızdan Azure'a güvenli bir bağlantı gerekir. Başlamadan önce VPN veya Azure ExpressRoute bağlantısı kurmak ve yapılandırmak önemlidir. Daha fazla bilgi için bkz. Sanal Ağ genel bakış.
• Diğer güvenlik gereksinimleri – Makine ilkeleri, genel IP adreslerine erişim, İnternet'e bağlanma gibi diğer güvenlik gereksinimleri, kavram kanıtı uygulamadan önce gözden geçirilmesi gerekebilecek senaryolardır.

Abonelik topolojisi

DevTest Labs'i Enterprise'a dağıtırken abonelik topolojisi önemli bir tasarım konusudur. Ancak, bir kavram kanıtı tamamlanana kadar tüm kararları sağlamlaştırmak gerekmez. Kurumsal bir uygulama için gereken abonelik sayısını değerlendirirken iki uç noktası vardır:

• Kuruluşun tamamı için bir abonelik
• Kullanıcı başına abonelik

Ardından, her yaklaşımın avantajlarını vurgulayacağız.

Bir abonelik

Genellikle bir aboneliğin yaklaşımı büyük bir kuruluşta yönetilemez. Ancak abonelik sayısını sınırlamak aşağıdaki avantajları sağlar:

• Kuruluş maliyetlerini tahmin etme . Tüm kaynaklar tek bir havuzda olduğundan, tek bir abonelikte bütçeleme çok daha kolay hale gelir. Bu yaklaşım, bir faturalama döngüsünde herhangi bir zamanda maliyet denetimi ölçülerinin ne zaman uygulanacakları konusunda daha basit karar alma olanağı sağlar.
• Vm'lerin, yapıtların, formüllerin, ağ yapılandırmasının, izinlerin ve ilkelerin yönetilebilirliği daha kolaydır çünkü tüm güncelleştirmeler birçok abonelikte güncelleştirme yapmak yerine yalnızca bir abonelikte gereklidir.
• Şirket içi bağlantının bir gereksinim olduğu kuruluşlar için tek bir abonelikte ağ iletişimi daha kolaydır. Abonelikler arasında sanal ağları Bağlan (merkez-uç modeli), eklenen aboneliklerle birlikte gereklidir, daha fazla yapılandırma, yönetim ve IP adresi alanı gerektirir.
• Herkes aynı abonelikte çalışırken ekip işbirliği daha kolaydır. Örneğin, vm'yi bir iş arkadaşına yeniden atamak veya ekip kaynaklarını paylaşmak daha kolaydır.

Kullanıcı başına abonelik

Kullanıcı başına ayrı bir abonelik, alternatif spektruma eşit fırsatlar sağlar. Birçok aboneliğe sahip olmanın avantajları şunlardır:

• Azure ölçeklendirme kotaları benimsemeyi engelleyemez. Örneğin, bu yazıdan itibaren Azure abonelik başına 200 depolama hesabına izin verir. Azure'da çoğu hizmet için operasyonel kotalar vardır (çoğu özelleştirilebilir, bazıları özelleştiremez). Bu kullanıcı başına abonelik modelinde kotaların çoğuna ulaşılıyor olma olasılığı oldukça düşüktür. Geçerli Azure ölçeklendirme kotaları hakkında daha fazla bilgi için bkz . Azure aboneliği ve hizmet sınırları, kotalar ve kısıtlamalar.
• Gruplara veya bireysel geliştiricilere yapılan geri ödemeler , kuruluşların geçerli modellerini kullanarak maliyetleri hesaba katmasına olanak tanıyarak çok daha kolay hale gelir.
• DevTest Labs ortamlarının sahiplik ve izinleri basittir. Geliştiricilere abonelik düzeyinde erişim verirsiniz ve ağ yapılandırması, laboratuvar ilkeleri ve VM yönetimi dahil her şeyden %100 sorumludurlar.

Enterprise'da, spektrumun aşırı uçlarında yeterli kısıtlama olabilir. Bu nedenle, abonelikleri bu uç değerlerin ortasında olacak şekilde ayarlamanız gerekebilir. En iyi uygulama olarak, bir kuruluşun hedefi mümkün olan en az abonelik sayısını kullanmak olmalıdır. Toplam abonelik sayısını artıran zorlama işlevlerini unutmayın. Yinelemek için abonelik topolojisi DevTest Labs'in kurumsal dağıtımı için kritik öneme sahiptir ancak kavram kanıtını geciktirmemelidir. İdare makalesinde, kuruluşta abonelik ve laboratuvar ayrıntı düzeyine karar verme hakkında daha fazla ayrıntı vardır.

Roller ve sorumluluklar

DevTest Labs kavram kanıtının tanımlı sorumlulukları olan üç birincil rolü vardır: Abonelik sahibi, DevTest Labs sahibi, DevTest Labs kullanıcısı ve isteğe bağlı olarak Katkıda Bulunan.

• Abonelik sahibi : Abonelik sahibi, kullanıcı atama, ilkeleri yönetme, ağ topolojisi oluşturma ve yönetme ve kota artışı isteme gibi azure aboneliğini yönetme haklarına sahiptir. Daha fazla bilgi için bu makaleye bakın.
• DevTest Labs sahibi – DevTest Labs sahibinin laboratuvara tam yönetici erişimi vardır. Bu kişi kullanıcıları eklemek/kaldırmak, maliyet ayarlarını, genel laboratuvar ayarlarını ve diğer VM/yapıt tabanlı görevleri yönetmekle sorumludur. Laboratuvar sahibi ayrıca DevTest Labs Kullanıcısının tüm haklarına sahiptir.
• DevTest Labs kullanıcısı – DevTest Labs kullanıcısı laboratuvardaki sanal makineleri oluşturabilir ve kullanabilir. Bu kişiler, oluşturdukları VM'lerde (vm'lerini başlatma/durdurma/silme/yapılandırma) bazı en düşük yönetim özelliklerine sahiptir. Kullanıcılar diğer kullanıcıların VM'lerini yönetemez.

DevTest Labs uygulamasını düzenleme

Bu bölüm, Azure DevTest Labs'in hızlı dağıtımı ve uygulanması için önerilen bir yaklaşım sağlar. Aşağıdaki görüntüde genel süreç, çeşitli sektör gereksinimlerini ve senaryolarını destekleme esnekliğini gözlemlerken açıklayıcı rehberlik olarak vurgulamaktadır.

Varsayımlar

Bu makalede, DevTest Labs pilotunu uygulamadan önce aşağıdaki öğelere sahip olduğunuz varsayılır:

• Azure aboneliği: Pilot ekibin kaynakları bir Azure aboneliğine dağıtma erişimi vardır. İş yükleri yalnızca geliştirme ve test amaçlıysa, Ek kullanılabilir görüntüler ve Windows sanal makinelerinde daha düşük hızlar için Enterprise DevTest teklifini seçmeniz önerilir.
• Şirket İçi Erişim: Gerekirse, şirket içi erişim zaten yapılandırılmıştır. Şirket içi erişim, Siteden siteye VPN bağlantısı veya Express Route aracılığıyla gerçekleştirilebilir. Express Route aracılığıyla Bağlan üretkenliğin oluşturulması genellikle birkaç hafta sürebilir; projeyi başlatmadan önce Express Route'un yerinde olması önerilir.
• Pilot Ekipler: DevTest Labs kullanan ilk geliştirme projesi ekipleri, ilgili geliştirme veya test etkinlikleriyle birlikte belirlendi ve bu ekipler için gereksinimler/hedefler/hedefler belirlendi.

Kilometre Taşı 1: İlk ağ topolojisi ve tasarımını oluşturma

Azure DevTest Labs çözümü dağıtılırken ilk odak alanı, sanal makineler için planlanan bağlantıyı kurmaktır. Aşağıdaki adımlarda gerekli yordamlar özetlenmiştir:

1. Azure'da DevTest Labs aboneliğine atanan ilk IP adresi aralıklarını tanımlayın. Bu adım, gelecekteki genişletme için yeterince büyük bir blok sağlayabilmeniz için VM sayısı olarak beklenen kullanımın tahminini gerektirir.
2. DevTest Labs'e istenen erişim yöntemlerini tanımlayın (örneğin, dış /iç erişim). Bu adımın önemli bir noktası, sanal makinelerin genel IP adreslerine (yani doğrudan İnternet'ten erişilebilir) sahip olup olmadığını belirlemektir.
3. Azure bulut ortamının geri kalanı ve şirket içi ile bağlantı yöntemlerini belirleyin ve oluşturun. Express Route ile zorlamalı yönlendirme etkinleştirildiyse, büyük olasılıkla sanal makinelerin şirket güvenlik duvarından geçiş yapmak için uygun ara sunucu yapılandırmalarına ihtiyacı vardır.
4. VM'ler etki alanına katılmış olacaksa, bunların bulut tabanlı bir etki alanına mı (örneğin Microsoft Entra Directory Services) yoksa şirket içi etki alanına mı katılacağını belirleyin. Şirket içi için, sanal makinelerin Active Directory'de hangi kuruluş birimine (OU) katılacağını belirleyin. Ayrıca, kullanıcıların katılma erişimi olduğunu onaylayın (veya etki alanında makine kayıtları oluşturabilen bir hizmet hesabı oluşturun)

Kilometre Taşı 2: Pilot laboratuvarı dağıtma

Ağ topolojisi oluşturulduktan sonra, aşağıdaki adımlar izlenerek ilk/pilot laboratuvar oluşturulabilir:

1. İlk DevTest Labs ortamını oluşturun.
2. Laboratuvar ile kullanmak için izin verilebilen VM görüntülerini ve boyutlarını belirleyin. Özel görüntülerin DevTest Labs ile kullanılmak üzere Azure'a yüklenip yüklenmeyeceğine karar verin.
3. Laboratuvar (laboratuvar sahipleri ve laboratuvar kullanıcıları) için ilk Azure rol tabanlı erişim denetimi (Azure RBAC) oluşturarak laboratuvara erişimin güvenliğini sağlayın. DevTest Labs ile kimlik için Microsoft Entra Id ile eşitlenmiş Active Directory hesapları kullanmanızı öneririz.
4. DevTest Labs'i zamanlamalar, maliyet yönetimi, talep edilebilir VM'ler, özel görüntüler veya formüller gibi ilkeleri kullanacak şekilde yapılandırın.
5. Azure Repos/Git gibi çevrimiçi bir depo oluşturun.
6. Genel veya özel depoların kullanımına veya her ikisinin birleşimine karar verin. Dağıtımlar ve uzun vadeli süreklilik için JSON Şablonlarını düzenleyin.
7. Gerekirse özel yapıtlar oluşturun. Bu adım isteğe bağlıdır.

Kilometre Taşı 3: Belgeler, destek, öğrenme ve geliştirme

İlk pilot takımlar, kullanmaya başlamak için ayrıntılı destek gerektirebilir. Azure DevTest Labs'in sürekli dağıtımı için doğru belge ve desteğin sağlandığından emin olmak için deneyimlerini kullanın.

1. Pilot ekipleri yeni DevTest Labs kaynaklarıyla tanıştırın (tanıtımlar, belgeler)
2. Pilot ekiplerin deneyimlerini temel alarak, gerektiğinde belgeleri planlayın ve teslim edin
3. Yeni ekipler ekleme (laboratuvar oluşturma ve yapılandırma, erişim sağlama vb.) için süreci resmileştirin
4. İlk alıma bağlı olarak, IP adresi alanının özgün tahmininin hala makul ve doğru olduğunu doğrulayın
5. Uygun uyumluluk ve güvenlik gözden geçirmelerinin tamamlandığından emin olun

Sonraki adımlar

Bu serideki sonraki makaleye bakın: Azure DevTest Labs altyapısının idaresi