Azure giriş bölgelerinde uygulama geliştirme ortamlarını yönetme
Bu makalede, bulut platformu ekiplerinin Azure giriş bölgelerindeki uygulama ortamlarını yönetmek için korumaları nasıl uygulayabileceği açıklanmaktadır. Ayrıca çeşitli uygulama geliştirme ortamlarını çerçeveleriyle nasıl uyumlu hale getirmeleri de açıklanmaktadır. Uygun ortamı oluşturmanın önemli bir yönü, abonelikleri uygun yönetim gruplarına yerleştirmektir.
Temeli ayarlama
Geliştirme ekiplerinin hızla yineleme yapabilmesi, bulut idaresi ve platform ekiplerinin ise kurumsal risk, uyumluluk ve güvenliği büyük ölçekte yönetmesi gerekir. İki temel Azure giriş bölgesi tasarım ilkesine odaklanarak uygulama ortamlarını düzgün bir şekilde yönetebilirsiniz: ilke temelli idare ve abonelik demokratikleştirme. Bu ilkeler temel korumalar sağlar ve denetimleri uygulama ekiplerine devretmeyi açıklar. Uygulama ekipleri, iş yüklerini tasarlamak için Azure İyi Tasarlanmış Çerçeve kılavuzunu kullanır. Kendi giriş bölgesi kaynaklarını dağıtır ve yönetir ve platform ekibi Azure ilkeleri atayarak kaynakları denetler.
Uygulama ekiplerinin teknolojiler ve özelliklerle denemeler yapabilmesi için yarı yönetilen kaynaklar için korumalı alan kaynakları sağlamak önemlidir.
Uygulama sahipleri abonelik aracı veya diğer abonelik oluşturma işlemlerini kullandığında, birden çok geliştirme ortamı için abonelik istemeyi bilmeleri gerekir.
Bu makalede yönetim grupları, ilkeler ve paylaşılan platform mimarisi ile iş yükü veya uygulama giriş bölgesi de dahil olmak üzere Azure giriş bölgesi açıklanmaktadır.
Not
Bu makaledeki yönergeler yalnızca iş yükü veya uygulama giriş bölgeleri içindir. Azure giriş bölgesi platformunun kendisi için test ve ortam ayrımını görmek için bkz . Kanarya yaklaşımını açıklayan Azure giriş bölgeleri için test yaklaşımı.
Uygulamada, aşamalı ortamın herhangi bir sayısını ve türünü kullanabilirsiniz. Bu makalede aşağıdaki aşamalı ortamlar ele alınıyor.
| Environment | Veri Akışı Açıklaması | Yönetim grubu |
|---|---|---|
| Sandbox | Prototiplerin hızlı yenilenmesi için kullanılan ancak üretime bağlı yapılandırmaların kullanılmadığı ortam | Korumalı alan yönetim grubu |
| Geliştirme | Olası sürüm adaylarını oluşturmak için kullanılan ortam | Corp veya online gibi arketip yönetim grubu |
| Test | Birim testi, kullanıcı kabul testi ve kalite güvencesi testi dahil olmak üzere test gerçekleştirmek için kullanılan ortam | Corp veya online gibi arketip yönetim grubu |
| Üretim | Müşterilere değer sunmak için kullanılan ortam | Corp veya online gibi arketip yönetim grubu |
Daha fazla bilgi için bkz . Uygulama iş yükleri için geliştirme, test ve üretim ortamlarını işleme ve Azure'da kaç abonelik kullanmalıyım?
Ortamlar, abonelikler ve yönetim grupları
Bu bölümün önkoşulu olarak bkz . Kaynak kuruluşu tasarım alanı.
Azure giriş bölgesi uygulamalarını benimserken aboneliklerinizi düzgün bir şekilde düzenlemeniz gerekir. İdeal olarak, her uygulama ortamının kendi aboneliği olmalıdır. Bu yöntem, ortamları yalıtılmış tutan güvenlik ve ilke denetimleri sağlar. Tek bir ortamda olası sorunlar içerir.
Ayrı abonelikler arketip düzeyinde aynı ilkelere sahiptir. Gerekirse, uygulama sahipleri uygulamaya ve ortama özgü davranışı zorunlu kılmak için aboneliğe özgü ilkeler atayabilir.
Bazı uygulama mimarileri, hizmetlerin ortamlar arasında paylaştırılmalarını gerektirir. Böyle bir durum söz konusuysa, birden çok ortam için tek bir abonelik kullanabilirsiniz. İş yükü sahiplerinin bulut platformu ekipleriyle birlikte çalışarak birden çok ortam için tek bir abonelik gerekip gerekmediğini belirlemelerini öneririz.
Aşağıdakiler durumunda birden çok uygulama ortamı için tek bir abonelik kullanın:
Ortamlar kendi aboneliklerinde yalıtılamaz.
Ortamlar, ağ işleçleri gibi işlevsel rollere atanmış olan ekiplere sahiptir.
Ortamlar aynı ilkeleri kullanabilir.
Bir uygulama veya hizmet iş yükünün tek bir abonelikte olması gerekiyorsa ve her ortama uygulanan ilkelerde değişiklik yapmanız gerekiyorsa şunları yapabilirsiniz:
Giriş bölgeleri yönetim grubunun altında yeni bir arketip uyumlu yönetim grubu oluşturun. Daha fazla bilgi için bu makaledeki Yönetim grubu hiyerarşisine bakın.
Geliştirme etkinlikleri için korumalı alan aboneliklerini kullanın. Korumalı alanlar daha az kısıtlayıcı bir ilke kümesine sahiptir.
Yönetim grubu düzeyi yerine abonelik düzeyinde uygulanan ilkeleri kullanın. İlke tanımlarına etiketleri ekleyerek ilkeleri doğru ortama filtrelemeye ve uygulamaya yardımcı olabilirsiniz. Ayrıca, ilkeleri belirli kaynak gruplarına atayabilir veya bunların dışında tutabilirsiniz.
abonelik oluşturma işlemi sırasında abonelik aracı bir parçası olarak ilke atayabilirsiniz.
Maliyetleri denetlemeye yardımcı olmak için uyguladığınız ilkeler için, ilke tanımını gerektiğinde abonelik düzeyinde uygulayın. Ya da giriş bölgesi sahibini maliyetlerden sorumlu hale getirebilirsiniz ve bu da gerçek özerklik sağlar. Daha fazla bilgi için bkz . Platform otomasyonu ve DevOps.
Uyarı
Yönetim grubu düzeyindeki ilke ve denetimlerden farklı olarak abonelik tabanlı ilkeler ve etiketler, abonelik için yükseltilmiş izinlere sahip kişiler tarafından değiştirilebilir. uygun rollere sahip Yönetici istrator'lar ilkeleri dışlayarak, ilkeleri değiştirerek veya kaynaklardaki etiketleri değiştirerek bu denetimleri atlayabilir.
Sonuç olarak, güvenlik odaklı ilkelerin tanımlarına etiket uygulamamalısınız. Ayrıca, aşağıdaki eylemler için izinleri her zaman etkin olarak atayın:
Microsoft.Authorization/policyAssignments/*Microsoft.Authorization/policyDefinitions/*Microsoft.Authorization/policyExemptions/*Microsoft.Authorization/policySetDefinitions/*
Privileged Identity Management (PIM) kullanarak bu eylemleri denetleyebilirsiniz.
Yönetim grubu hiyerarşisi
Karmaşık yönetim grubu hiyerarşilerinden kaçının. Bunlar sık değişiklik yapılmasını, verimsiz ölçeklendirmeyi ve değer eksikliğini gerektirebilir. Bu olası sorunları önlemek için Azure giriş bölgesi yönetim grupları iş yükü arketipine göre hizalanır. Daha fazla bilgi için bkz . Yönetim grubu ve abonelik kuruluşu.
Arketipe hizalanmış , yönetim gruplarının yalnızca belirli iş yükü arketipleri için oluşturulduğu anlamına gelir. Örneğin, kavramsal mimaride, giriş bölgeleri yönetim grubunun kuruluş ve çevrimiçi çocuk yönetim grupları vardır. Bu alt yönetim grupları, barındırdıkları iş yükleri için ayrı arketip desenleriyle hizalanır. Alt yönetim grupları, yalnızca iç ve genel kullanıma yönelik uygulamalar ve hizmetler gibi karma bağlantı (VPN/Azure ExpressRoute) gereksinimlerine odaklanır.
Korumalı alan ortamları hariç, çeşitli uygulama ortamları dağıtım için aynı arketipi kullanmalıdır. Ortamlar çeşitli aboneliklere ayrılmış olsalar bile, yönetim grubu arketipi ve gereksinimlerine bağlı olarak aynı tek yönetim grubunda (corp veya online) tutulurlar.
Kişisel laboratuvarlar gibi yapılandırılmamış geliştirme için veya arketipi olmayan bir iş yükü için korumalı alan aboneliklerini kullanabilirsiniz. Uygulama veya hizmet iş yükü ekibi, gereksinimleri için en uygun olanı belirlemek üzere çeşitli Azure hizmetlerini test etmek için bir korumalı alan yönetim grubu kullanır. Hizmetlere karar verdikten sonra ekip için bir giriş bölgesi (giriş bölgeleri yönetim grubu hiyerarşisindeki doğru iş yükü arketipi uyumlu yönetim grubunda) sağlayabilirler.
Korumalı alan ortamları belirli uygulamalar için veya bir iş yükü ekibi bunları deneme için kullanabilir.
Daha fazla bilgi için bkz.
- Yönetim grupları.
- Kaynak kuruluşu tasarım alanı.
- Gereksinimleri karşılamak için Azure giriş bölgesi mimarisini uyarlayın.
Ortam tabanlı yönetim grubu zorlukları
Arketipler içindeki ortamlar için yönetim grupları yönetim yükü ekleyebilir ve minimum değer sağlayabilir.
Giriş bölgeleri yönetim grubu, hem kurumsalhem de çevrimiçi çocuk yönetim grupları için korumalar uygulayan evrensel ilkelere sahip olmalıdır. Şirket ve çevrimiçi, genel ve özel kullanıma yönelik iş yükleriyle ilgili şirket yönergelerini zorunlu kılan benzersiz ilkelere sahiptir.
Birçok kuruluş, ortam ilkeleri ve denetimleri atamak için iş yükü yazılım geliştirme yaşam döngüsü (SDLC) ortamları için ayrı yönetim grupları oluşturur. Pratikte bu yöntem, iş yükü ekipleri için çözdüğünden daha fazla zorluk oluşturur. SDLC ortamlarında farklı ilkeler olmamalıdır, bu nedenle ayrı yönetim grupları önermiyoruz.
Uygulama sahipleri, bir iş yükünün topolojisini veya kaynak yapılandırmasını yükseltilen birden çok SDLC ortamındaki ilkelerle uyumlu olacak şekilde değiştirebilir. Bu yöntem riski artırır. Her ortama özgü kurallar, geliştirici ve kalite güvencesi ekipleri için kötü bir geliştirme deneyimine neden olabilir. Bir uygulamanın tek bir ortamda çalışan bir dizi koruma ilkesi varsa ve uygulama yükseltme döngüsünün ilerleyen bölümlerinde farklı bir ilke kümesine açıksa da sorunlar ortaya çıkabilir. Denetimler değişirse uygulamada ayarlamalar yapmanız gerekebilir.
Bu ek çalışmayı önlemek için SDLC ortamlarında kodun yükseltilmesi boyunca tutarlı ilkeler oluşturun. Her ortam için ilke oluşturmamanız, bunun yerine korumalı alan ortamları hariç tüm geliştirme ortamları için tutarlı bir küme sağlamanız gerekir.
Örneğin, bir kuruluşun genel ağlardan girişi önlemek için depolama hesaplarının belirli güvenlik duvarı kurallarıyla yapılandırılmasını gerektiren bir ilke tanımladığını düşünün. Bunun yerine, depolama hesapları iletişim için Azure giriş bölgesi ağlarının içindeki özel uç noktaları kullanır. Geliştirme ortamı böyle bir ilkeye sahip değilse, iş yükünün test edilmesi depolama hesabının genel erişime izin veren yanlış yapılandırılmasını bulmaz. Test dağıtımları geliştirme ortamında çalışır ve üzerinde yinelenir. Çözüm, depolama hesabı ilkesine sahip başka bir ortama yükseltildiğinde, zorunlu ilke nedeniyle dağıtım başarısız olur.
Sonuç olarak, uygulama geliştirme ekibinin zaten önemli bir çabaya yatırım yaptıktan sonra dağıtım ve mimarilerini yeniden işlemesi gerekir. Bu örnekte, çeşitli ortamlardaki farklı ilkelerin nasıl sorun oluşturabileceği gösterilmektedir.
Not
Aşağıdaki denklemde her ortam veya iş yükü için ayrı bir yönetim grubunun neden iyi ölçeklendirilmediği gösterilmektedir: N iş yükleri x Z yönetim grupları = toplam yönetim grupları.
Bir kuruluşun her biri geliştirme, test ve üretim ortamları için bir yönetim grubu ve bir alt yönetim grubu gerektiren 30 iş yükü varsa, kuruluşta şunlar kalır:
N = iş yükü/uygulama sayısı = 30
Z = iş yükü ve ortamlar için yönetim gruplarının sayısı (iş yükü için 1 + ortamlar için 3) = 4
N (30) x Z (4) = 120 toplam yönetim grubu
Uygulama sahiplerinin birden çok ortam için farklı uygulama ilkeleri gerekebilir. Örneğin, uygulama sahipleri üretim ortamları için yedekleme yapılandırmaları gerektirebilir ancak diğer ortamlar için gerekli olmayabilir.
Bazı ilkeler yönetim grubu düzeyinde denetim ilkeleri olarak etkinleştirilebilir. Uygulama ekipleri denetimin nasıl uygulandığını belirler. Bu yöntem dağıtımları engellemez, ancak farkındalık oluşturur ve uygulama ekiplerinin benzersiz ihtiyaçlarını yönetmesini sağlar. Daha sonra alt düzey ilkeleri oluşturabilir veya bu gereksinimleri kod olarak altyapı (IaC) dağıtım modüllerine dahil edebilirler.
Bu paylaşılan sorumluluk modelinde platform ekibi uygulamaları denetler ve uygulamayı uygulama ekibi yönetir. Bu model dağıtımların çevikliğini artırabilir.
Platform operatörlerinin gereksinimlerini anlamak için her uygulama veya hizmet iş yükü ekibiyle (giriş bölgesi sahipleri) birlikte çalışması gerekir. Platform operatörleri, uygulama gereksinimlerine ve planlarına göre abonelikler sağlayabilir. Platform operatörleri ayrıca, uygulama veya hizmet iş yükü ekiplerinin yaygın gereksinimlerine göre abonelik oluşturma işlemleri ve araçları oluşturabilmeleri için çeşitli iş yükü türleri için ürün satırları belirlemeye karar verebilir.
Senaryo: Sanal makine (VM) tabanlı iş yükleri
Azure giriş bölgelerindeki ilk iş yükleri genellikle Azure VM'lerinden oluşur. Bu iş yüklerini Azure'a dağıtabilir veya mevcut veri merkezlerinden geçirebilirsiniz.
VM'leri tek bir abonelikteki birden çok ortam için dağıtmak yerine şunları yapabilirsiniz:
Her uygulama ortamı için abonelikler oluşturun ve hepsini aynı arketip yönetim grubuna yerleştirin.
Uygun abonelikteki her uygulama ortamı için bir sanal ağ dağıtın. Sanal ağ boyutunu uygulama ortamının boyutuna göre belirleyebilirsiniz.
VM'leri uygun aboneliklerine dağıtın. VM'ler uygunsa her ortam için farklı SKU'lar ve farklı kullanılabilirlik yapılandırmaları kullanabilir.
Çeşitli uygulama ortamı kaynakları farklı erişim denetimleriyle korunur. Sonuç olarak, uygulama geliştiricileri dağıtım işlem hatlarını kurduğunda, her işlem hattının kimliği ortamla sınırlandırılabilir. Bu yapılandırma, ortamların yanlışlıkla yapılan dağıtımlara karşı korunmasına yardımcı olur.
Senaryo: Azure Uygulaması Hizmeti
App Service kullanan çevre aboneliklerine sahip bir iş yükü güçlükler oluşturabilir. Uygulama geliştiricileri için App Service'in en iyi uygulaması, bir web uygulamasında yapılan değişiklikleri ve güncelleştirmeleri yönetmeye yardımcı olmak için dağıtım yuvalarını kullanmaktır.
Ancak bu özellik yalnızca App Service planındaki uygulamayla kullanılabilir ve bu uygulama yalnızca tek bir abonelikte bulunabilir. Platform operatörleri uygulama sahiplerinin geliştirme, test ve üretim ortamları için ayrı abonelikler kullanmasını zorunlu hale getirmekteyse, uygulama dağıtım yaşam döngüsünü yönetmek daha zor olabilir.
Bu örnekte en iyi seçenek, uygulama veya hizmet iş yükü için tek bir aboneliktir. Uygulama sahipleri, daha fazla güvenlik için kaynak grubu düzeyinde PIM ile Azure rol tabanlı erişim denetimini (RBAC) kullanabilir.