Azure Resource Manager şablonlarınızın (ARM şablonları) yönetimini modüler hale getirmek, yinelemeyi azaltmanıza, altyapı geliştirmede en iyi yöntemleri modellemenize ve tutarlı standart dağıtımlara sahip olmanıza olanak tanır.
Bu tür modülerleştirmenin uygulanması için örnek bir kullanım örneği, tişört boyutları metaforu kullanılarak sanal makinelerin (VM) dağıtılmasıdır. Onlarca veya yüzlerce VM dağıtmış olduğunuzu varsayalım. Bu dağıtımlar şablonlarınızın 1.0.0 sürümünü kullanır ve standart orta büyüklükte eski bir seriye sahiptir. Yeni bir seriye geçiş yapmak için, yalnızca yeni şablonlar dağıttıysanız kısa bir hizmet kesintisi gerekebilir. Ancak sürüm 1.5.0'ı oluşturup modülerleştirme kullanarak yeni altyapıyı güncelleştirilmiş standartla dağıtabilir ve eski altyapıyı dağıtılabilir durumda tutabilirsiniz. Altyapının eski sürümlerinin kullanılabilir olmasıyla, ürün ve uygulama ekipleriniz zamanları olduğu için yeni sürüme yükseltirken güvenmeleri gereken bilinen iyi bir yapılandırmaya sahiptir.
Depoların katman pastası: Kuruluşlar için bir örnek
Şablonlarınızın nereye gittiği, nasıl güncelleştirildiği vb. için neden güçlü bir tercihe sahip olmak isteyebileceğiniz konusunda başlıca iki nokta vardır: dallanma ve iç kaynak oluşturma.
Dallanma. Bu örnek senaryo, Gitflow ve GitHub akışını destekleyen git dallanma modellerini kolaylaştırır. Gitflow hakkında daha fazla bilgi için jeff Kreeftmeijer'ın blog gönderisi olan Git dallanma iş akışınızı otomatikleştirmek için git-flow kullanma bölümüne bakın. GitHub akışı hakkında daha fazla bilgi için GitHub belgelerindeki GitHub akışı bölümüne bakın.
İç kaynak. İkincisi, açık kaynak yazılım geliştirmenin işbirliğine dayalı uygulamalarını şirket içi geliştirmeye getiren iç kaynak oluşturmadır. Böyle bir senaryoda, dağıtım modellerinin izinleri konusunda endişelenmenize gerek kalmadan farklı şablonları ve modül kaynak kodunu güvenle paylaşabilirsiniz. İç kaynak geliştirme hakkında daha fazla bilgi için bkz . GitHub'da innersource'a giriş,
Bicep, Azure kaynaklarını dağıtmak için bildirim temelli bir dildir. Bicep'in yeniden kullanılabilir kodu, azure container registry'i sürümlenmiş ARM şablonlarını barındırmak için özel kayıt defteri olarak kullanabilir. Container Registry'yi bu şekilde kullanarak, kuruluşunuz altyapı için sürekli tümleştirme ve sürekli teslim (CI/CD) sürecine sahip olabilir. CI işleminin bir parçası olarak tümleştirme ve birim testleri çalıştırabilirsiniz ve kapsayıcı kayıt defteri başarıyla oluşturulduktan sonra modülleri alabilir. Uygulama ekipleri, yükseltmeye hazır olana kadar eski sürümleri kullanmaya devam edebilir veya şablonların yeni sürümlerindeki özelliklerden yararlanacak şekilde güncelleştirebilir.
Container Registry'nin bu kullanımına ek olarak, bu modeli Azure Doğrulanmış Modülleri gibi bir şeyle birleştirebilirsiniz. Uygulamanız genel kayıt defterinden tüketebilir veya tercihen genel depoları izleyebilir ve değişiklikleri daha fazla kullanmak üzere özel kayıt defterinize çekebilir. Değişiklikleri kendi kapsayıcı kayıt defterinize çekmek, kalite ve güvenlik uygulamaları dahil edilene kadar üretimde kullanılmamalarını sağlarken genel modüllerde test çalıştırmanıza olanak tanır.
Katmanlar
Bu örnek senaryoda önerilen model, yığılan modeldir. Yığının en üstüne yakın katmanlar daha sık yapılan dağıtımlara ve dağıtımlara sahiptir. Bicep kodu tutarlı dağıtımlar sağlar. Katkıları için katmanlarda çalışan geliştirme ekipleri, aşağıdaki katmanlarda sağlanan hizmetlerden ve altyapıdan oluşturulur. Alt katmandaki hiçbir şey yukarıdaki bir katmandaki kaynaklara güvenmemelidir. Katman 0'dan 3'e genel kitaplık, genel altyapı (genel olarak paylaşılan hizmetler), ürün platformu (paylaşılan hizmetler) ve uygulamalardır.
Bu model, hizalama ile özerklik oluşturur, bu da aşağıdakilere sahip olmak anlamına gelir:
Kurumsal kolaylık için yaygın araçlar. Örneğin, herkes kaynak denetimi için git kullanır ve herkes CI/CD için GitHub Actions'ı kullanır. Ancak fazla ulaşmıyoruz. Örneğin, tüm ekiplerin Bicep kullanmasını zorunlu kmıyoruz; Terraform, ARM şablonları ve diğer araçları kullanabilirler.
En iyi yöntemleri paylaşma olanağı. ARM şablonları, altın resimler veya kod parçacıkları biçiminde olabilirler. En iyi yöntemler belirli tekniklerin belgeleri de olabilir. Örneğin, ortamınızdaki anahtarları döndürme ve kodu test etme.
Bazı hizmetler yığında aşağı doğru hareket eder. Örneğin, bir uygulama ekibi başlangıçta daha sonra paylaşılan hizmet olarak ürün platformuna çekilen bir Kubernetes kümesi dağıtmak için bir şablon geliştirebilir. Bu şablon o kadar kullanışlı hale gelir ki örnek kitaplığına çekilir.
Katman 0 - Genel kitaplık
Alt katman, üretime dağıtılmayan kullanışlı tidbitlerin deposu olan genel kitaplıktır. Erişim denetimi açısından bakıldığında, şirkette isteyen herkese okuma erişimi sağlanmalıdır. Değişiklikler, öneriler vb. için, Bulut Mükemmellik Merkeziniz (CCoE) çekme isteklerini onaylar ve bu başka bir ürün gibi bir kapsamı yönetir.
Katman 0 şu içeriği içermemelidir:
- Üretimde dağıtılan şablonlar.
- Gizli diziler veya ortama özgü yapılandırmalar.
Katman 0'da şu değerler bulunmalıdır :
- Kod parçacıkları (Python, C# vb. içinde).
- Azure İlkesi örnekleri.
- Örnek olarak kullanılabilecek ARM şablonları, Bicep şablonları veya Terraform dosyaları.
Bunun bir örneği, şirketinizin ortama özgü bilgiler olmadan üç katmanlı bir uygulama için nasıl dağıtım yazacağını gösteren örnek bir mimaridir. Bu örnek mimari etiketler, ağlar, ağ güvenlik grupları vb. içerebilir. Ortam için belirli bilgileri dışarıda bırakmak yararlıdır, çünkü her şey bir modüle eklenemez veya yerleştirilmemesi gerekir. Bunu yapmaya çalışmak aşırı parametreleştirmeye neden olabilir.
Ayrıca Katman 0, Terraform Kayıt Defteri veya Azure Kaynak Modülleri gibi bilinen diğer iyi örnek kod kaynaklarına bağlanabilir. Kuruluşunuz bu kaynaklardan herhangi birinden kod veya desen benimsediyse, kodu veya deseni doğrudan genel kaynaklardan çekmek yerine kendi Katman 0'ınıza çekmenizi öneririz. Katman 0'ınıza güvenerek kendi testlerinizi, ayarlamalarınızı ve güvenlik yapılandırmalarınızı yazabilirsiniz. Genel kaynaklara güvenmediğinizde beklenmedik şekilde silinebilecek bir şeye güvenme riskini azaltmış olursunuz.
İyi örnek kod olarak kabul edilebilmek için şablonlarınız ve modülleriniz, güvenlik ve kuruluş gereksinimleri için giriş doğrulaması da dahil olmak üzere iyi geliştirme uygulamalarını izlemelidir. Bu katılık düzeyini korumak için, ana dala çekme istekleri (PR) ve önerilen değişiklikler için kod gözden geçirmeleri gerektirecek ilkeler eklemeniz gerekir ve bu da birleştirilirse değişikliklerin ana kapsayıcı kayıt defterine akmasını sağlar.
Katman 0, Azure Container Registry'de otomatik olarak sürümlenmiş yapıtlar oluşturmak için Azure Pipelines'a veya GitHub Actions'a aktarılır. Yapıtların anlamsal sürümünü uygulamak için git işleme iletileri için otomasyon oluşturabilirsiniz. Bunun doğru çalışması için otomasyonu zaman içinde sürdürülebilir hale getirmek için service.bicep> gibi <belirleyici bir adlandırma standardına sahip olmanız gerekir. Uygun dal ilkeleriyle, kod gözden geçirmeleri için önkoşul olarak tümleştirme testleri de ekleyebilirsiniz. Pester gibi araçları kullanarak bunu izleyebilirsiniz.
Bu tür ilkeler ve korumalar söz konusu olduğundan, kapsayıcı kayıt defteri kuruluştaki kullanıma hazır tüm altyapı modülleri için gerçek kaynağı olabilir. Bu kodun bulunabilirliğini sağlamak için değişiklik günlüklerini ve kullanılabilir kod örneklerinin dizinlerini standartlaştırmayı düşünmelisiniz. Bilinmeyen kod kullanılmayan kod!
Katman 1 - Genel altyapı: Genel olarak paylaşılan hizmetler
Katman 1, Azure giriş bölgesi yapılarınızın deposudur. Microsoft, Azure giriş bölgelerinin dağıtımı için şablonlar sağlarken, belirli bileşenleri değiştirmek ve bir parametre dosyası sağlamak istersiniz. Bu, daha önce açıklandığı gibi genel kayıt defteri ve modül depolarını Katman 0'a çekme yönteminize benzer.
Azure Container Registry bu mimarinin kritik bir parçasıdır. Şirketinizin kapsayıcıları kullanma planı olmasa bile, Bicep şablonlarını sürüm oluşturmada başarılı olmak için Container Registry'yi dağıtmanız gerekir. Container Registry, kurumsal düzeyde güvenlik ve erişim denetimi sağlarken modülleriniz için önemli esneklik ve yeniden kullanılabilirlik sağlar.
Katman 1'de şuler bulunmalıdır:
- Yönetim grubu veya abonelik düzeyinde uygulanan ilke atamaları ve tanımları. Bu ilkeler, kurumsal idare gereksinimlerinizle eşleşmelidir.
- ExpressRoute, VPN'ler, sanal WAN ve sanal ağlar (paylaşılan veya hub) gibi temel ağ altyapısı şablonları.
- DNS.
- Çekirdek izleme (log analytics).
- Kurumsal kapsayıcı kayıt defteri.
Bu depoya değişiklik gönderme özelliğini kısıtlamak için dal korumasını yapılandırmanız gerekir. Diğer geliştiricilerden gelen PR'lerin onayını CCoE veya Bulut İdaresi üyeleriyle kısıtlayın. Bu katmana katkıda bulunanlar öncelikle bu katmandaki bileşenlerle geçmişte ilişkili grupların üyeleridir. Örneğin, ağ ekibi ağ için şablonları oluşturur, operasyon ekibi izlemeyi yapılandırıyor vb. Ancak, diğer gruplardan geliştiricilerin çekirdek altyapılarda değişiklik önermesini sağlamak istediğiniz için, bunu isteyen kişilere salt okunur erişim vermelisiniz. Değişikliklerin onay ve test olmadan birleştirilmesine izin vermeseniz de, bunlar geliştirmelere katkıda bulunabilir.
Bu dosyalar standart bileşenler için kapsayıcı kayıt defterinizdeki modülleri tüketmelidir. Ancak, kuruluşunuzun Azure giriş bölgelerini veya benzer bir idare yapısını uygulamasına göre özelleştirilmiş bir Bicep dosyanız veya bir dizi Bicep dosyanız da olacaktır.
Katman 2 - Ürün platformu: Paylaşılan hizmetler
Katman 2'yi, ürün platformunu belirli bir ürün hattı veya iş birimi için paylaşılan hizmetler olarak düşünebilirsiniz. Bu bileşenler kuruluş genelinde evrensel değildir, ancak belirli bir iş gereksinimine uygun olmalıdır. Bu, genel altyapı olan Katman 1'de hub ile eş olan bir sanal ağ için uygun bir katman olacaktır. Anahtar kasası bu katman için başka bir örnek bileşendir. Anahtar kasası, paylaşılan gizli dizileri bir depolama hesabında veya bu platformdaki farklı uygulamalar tarafından paylaşılan bir veritabanında depolayabilir.
Katman 2'nin içermesi gerekenler:
- Ürüne özgü gereksinimlerle eşleşmesi için bir abonelikte veya kaynak grubunda uygulanan ilke atamaları.
- Anahtar kasaları, log analytics, SQL veritabanı (ürün içindeki çeşitli uygulamalar veritabanını kullanıyorsa) ve Azure Kubernetes Service için ARM şablonları.
Değişiklikleri bu depoya gönderme özelliğini kısıtlayan izinler uygulamanız gerekir. Diğer katmanlarda olduğu gibi, bir ürün müşteri adayının veya sahibin diğer geliştiricilerden gelen ÇEKME isteklerini onaylayabilmesi için dal korumasını kullanmanız gerekir. Ürün platformuna okuma erişimiyle ilgili sabit bir kural yoktur, ancak en azından uygulama ekiplerinden herhangi birinden geliştiricilere değişiklik önerebilmeleri için okuma erişimi verilmelidir. Katman 2 bazı özel mimariler veya benzer bilgiler içerebileceğinden, kuruluştaki platformu kullananlara erişimi kısıtlamayı seçebilirsiniz. Ancak böyle bir durum söz konusuysa, katman 0 olan genel kitaplıkla paylaşmak üzere bu depodan iyi uygulamalar ve kod parçacıkları toplama işlemi oluşturduğunuzdan emin olmak istersiniz.
Katman 3 - Uygulama
Uygulama katmanı olan 3. katman, ürün platformunun üzerinde oluşturulan bileşenleri içerir. Bu bileşenler, işletmenin istediği özellikleri sunar. Örneğin, bir akış platformu için bir uygulama arama işlevini sağlarken farklı bir uygulama öneriler sağlayabilir.
Katman 3'de şuler bulunmalıdır:
- C#, Python vb.'de uygulama kodu.
- Tek tek bileşenler için altyapı (yani yalnızca bu uygulamada kullanılır): işlevler, Azure Container Instances, Event Hubs.
İzinler, değişiklikleri bu depoya gönderebilmek için kısıtlanmıştır. Bu uygulamanın ekip üyesinin başka bir ekip üyesi tarafından yapılan çekme isteğini onaylamasını sağlamak için dal korumasını kullanmalısınız. Ekip üyelerinin kendi değişikliklerini onaylamasına izin verilmemelidir. Bu katman özel mimari, iş mantığı veya benzer bilgiler içerebileceğinden, kuruluştaki bu uygulamayı oluşturanlara erişimi kısıtlamayı seçebilirsiniz. Ancak, böyle bir durum söz konusuysa, 0. katmandaki genel kitaplıkla paylaşmak üzere bu katmandan iyi uygulamalar ve kod parçacıkları toplama işlemi de oluşturmanız gerekir.
Katmanlar arasındaki yaygınlıklar
Bu makalede her katman için bazı belirli ayrıntılar açıklanıyor olsa da, tüm katmanlar için dikkate almanız gereken bazı nitelikler de vardır.
Altyapınız bir uygulama gibi çalışmalıdır. Bu, birim testleri, duman testleri ve tümleştirme testleri ile yeni özelliklerin tam olarak test edilmesi için sürekli tümleştirme (CI) sürecine sahip olmanız gerektiği anlamına gelir. Yalnızca bu testleri ana sürüm dalı içine geçiren kodu birleştirmeniz gerekir.
Ayrıca, kişilerin süreci aşmasını önlemek için, daha fazla deneyim için bile dal ilkelerine sahip olduğunuzdan emin olmalısınız. CI işleminiz bir engel olarak görülüyorsa, bu, ilgilenmeniz gereken teknik bir borçla karşıladığınız anlamına gelir. Bu, ilkeleri ve korumaları kaldırmanız gerektiği anlamına gelmez.
Son olarak, tüm depoların ve içindeki kodun dizinine sahip olmayabilirsiniz ancak kuruluşunuz, kişilerin depolara erişim istemesi için bir süreç geliştirmelidir. Bazı kurallar tamamen otomatikleştirilebilir. Örneğin, söz konusu ürün kapsamındaki herhangi bir uygulama için ürün ekibinde yer alan bir katkıda bulunana gözden geçirmeden okuma erişimi veren bir kural uygulayabilirsiniz. Bu tür kurallar genellikle ortamlarınızdaki grup tabanlı üyelik ve grup tabanlı rol atamalarıyla uygulanabilir. Bu tür bir erişimin yapılandırılması, iç kaynak oluşturmayı ve kurumsal bilgileri kolaylaştırmaya yardımcı olmalıdır.
Katkıda Bulunanlar
Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.
Asıl yazarlar:
- Tim Sullivan | Üst Düzey Bulut Çözümü Mimarı
Diğer katkıda bulunanlar:
- Gary Moore | Programcı/Yazar
Sonraki adımlar
- Tasarım alanı: Platform otomasyonu ve DevOps
- Olgun ekip yapıları
- Kod Olarak Altyapı nedir?
- Azure/ResourceModules: Bu depo, olgun ve seçilmiş Bicep modülleri için bir CI platformu ve koleksiyonu içerir. Platform hem Azure Resource Manager'ı hem de Bicep'i destekler ve özelliklerini GitHub eylemleri ve Azure Pipelines ile kullanabilirsiniz.
- Bicep modülü için özel kayıt defteri oluşturma