GitHub Actions ile Azure altyapısına dağıtma

Bu kılavuzda, GitHub Actions ile Azure'a otomatik ve tekrarlanabilir bir şekilde dağıtım yapmak için CI/CD ve Kod Olarak Altyapı'yı (IaC) kullanmayı ele alacağız.

Bu makale bir mimariye genel bakıştır ve Azure'da ölçeklenebilir, güvenli, dayanıklı ve yüksek oranda kullanılabilir bir uygulama tasarlamaya yönelik yapılandırılmış bir çözüm sunar. Bulut mimarilerinin ve çözüm fikirlerinin daha gerçek dünya örneklerini görmek için Azure mimarilerine göz atın.

Dağıtımlar için IaC ve otomasyon kullanmanın avantajları

Azure portalı, CLI, API ve daha fazlası dahil olmak üzere Azure'a dağıtmanın birçok yolu vardır. Bu kılavuz için IaC ve CI/CD otomasyonu kullanacağız. Bu yaklaşımın avantajları şunlardır:

• Bildirim temelli: Altyapınızı ve dağıtım sürecinizi kodda tanımladığınızda, standart yazılım geliştirme yaşam döngüsü kullanılarak sürüm oluşturulabilir ve gözden geçirilebilir. IaC, yapılandırmanızda herhangi bir kaymayı önlemeye de yardımcı olur.

• Tutarlılık: IaC işleminin ardından, tüm kuruluşun en iyi yöntemleri içeren ve güvenlik gereksinimlerinizi karşılayacak şekilde sağlamlaştırılmış bir altyapı dağıtmak için standart, iyi oluşturulmuş bir yönteme uymasını sağlar. Merkezi şablonlarda yapılan tüm iyileştirmeler kuruluş genelinde kolayca uygulanabilir.

• Güvenlik: Merkezi olarak yönetilen şablonlar, iç standartları karşılamak için bir bulut operasyonları veya güvenlik ekibi tarafından sağlamlaştırılabilir ve onaylanabilir.

• Self Servis: Ekipler, merkezi olarak yönetilen şablonları kullanarak kendi altyapılarını dağıtma yetkisine sahip olabilir.

• Geliştirilmiş Üretkenlik: Ekipler, standart şablonları kullanarak tüm uygulama ayrıntıları konusunda endişelenmeye gerek kalmadan yeni ortamları hızla sağlayabilir.

Ek bilgiler Azure Mimari Merkezi'ndeki yinelenebilir altyapı altında veya DevOps Kaynak Merkezi'nde kod olarak altyapı nedir?

Mimari

Veri akışı

1. Yeni bir dal oluşturun ve gerekli IaC kodu değişikliklerini denetleyin.
2. Değişikliklerinizi ortamınızda birleştirmeye hazır olduğunuzda GitHub'da çekme isteği (PR) oluşturun.
3. GitHub Actions iş akışı, kodunuzun iyi biçimlendirildiğinden, dahili olarak tutarlı olduğundan ve güvenli altyapı ürettiğinizden emin olmak için tetiklenir. Ayrıca, Azure ortamınızda gerçekleşecek değişikliklerin önizlemesini oluşturmak için bir Terraform Planı veya Bicep durum analizi çalıştırılır.
4. Uygun şekilde gözden geçirildikten sonra PR, ana dalınızla birleştirilebilir.
5. Başka bir GitHub Actions iş akışı ana daldan tetiklenir ve IaC sağlayıcınızı kullanarak değişiklikleri yürütür.
6. (Terraform'a özel) Düzenli olarak zamanlanmış bir GitHub Action iş akışı da çalıştırılarak ortamınızdaki herhangi bir yapılandırma kayması olup olmadığını aramalı ve değişiklikler algılanırsa yeni bir sorun oluşturmalıdır.

Önkoşullar

Bicep kullanma

1. GitHub Ortamları Oluşturma

   İş akışları, Azure kimlik bilgilerini depolamak ve dağıtımlar için bir onay işlemi ayarlamak için GitHub ortamlarını ve gizli dizilerini kullanır. Bu yönergeleri izleyerek adlı production bir ortam oluşturun. production Ortamda bir koruma kuralı ayarlayın ve üretim dağıtımlarında oturumunu kapatması gereken gerekli onaylayanları ekleyin. Ortamı ana dalınızla da sınırlayabilirsiniz. Ayrıntılı yönergelere buradan ulaşabilirsiniz.

2. Azure Kimliğini ayarlama:

   Azure aboneliğinizde dağıtma izinlerine sahip bir Azure Active Directory uygulaması gereklidir. Tek bir uygulama oluşturun ve Azure aboneliğinizde uygun okuma/yazma izinlerini verin. Ardından, GitHub'ın OpenID Bağlan (OIDC) kullanarak kimliği kullanmasına izin vermek için federasyon kimlik bilgilerini ayarlayın. Ayrıntılı yönergeler için Azure belgelerine bakın. Üç federasyon kimlik bilgilerinin eklenmesi gerekir:

   • Varlık Türünü olarak Environment ayarlayın ve ortam adını kullanın production .
   • Varlık Türünü olarak Pull Requestayarlayın.
   • Varlık Türünü olarak Branch ayarlayın ve dal adını kullanın main .

3. GitHub gizli dizileri ekleme

   Dekont

   Azure kimlikleriyle ilgili verilerin hiçbiri gizli dizi veya kimlik bilgisi içermese de, ortam başına kimlik bilgilerini parametreleştirmek için kullanışlı bir yöntem olarak GitHub gizli dizilerini kullanmaya devam ediyoruz.

   Azure kimliğini kullanarak depoda aşağıdaki gizli dizileri oluşturun:

   • AZURE_CLIENT_ID : Azure'da uygulama kaydının uygulama (istemci) kimliği
   • AZURE_TENANT_ID : Uygulama kaydının tanımlandığı Azure Active Directory kiracı kimliği.
   • AZURE_SUBSCRIPTION_ID : Uygulama kaydının tanımlandığı abonelik kimliği.

   Depoya gizli dizi ekleme yönergeleri burada bulunabilir.

Terraform kullanma

1. Terraform Durum Konumunu Yapılandırma

   Terraform, yönetilen altyapınızın ve ilişkili yapılandırmanızın geçerli durumu hakkındaki bilgileri depolamak için bir durum dosyası kullanır. Bu dosyanın iş akışının farklı çalıştırmaları arasında kalıcı olması gerekir. Önerilen yaklaşım, bu dosyayı bir Azure Depolama Hesabı veya benzer bir uzak arka uç içinde depolamaktır. Normalde, bu depolama el ile veya ayrı bir iş akışı aracılığıyla sağlanır. Terraform arka uç bloğunun seçtiğiniz depolama konumuyla güncelleştirilmiş olması gerekir (belgeler için buraya bakın).

2. GitHub ortamı oluşturma

   İş akışları, Azure kimlik bilgilerini depolamak ve dağıtımlar için bir onay işlemi ayarlamak için GitHub ortamlarını ve gizli dizilerini kullanır. Bu yönergeleri izleyerek adlı production bir ortam oluşturun. production Ortamda bir koruma kuralı ayarlayın ve üretim dağıtımlarında oturumunu kapatması gereken gerekli onaylayanları ekleyin. Ortamı ana dalınızla da sınırlayabilirsiniz. Ayrıntılı yönergelere buradan ulaşabilirsiniz.

3. Azure Kimliğini ayarlama:

   Azure aboneliğinizde dağıtma izinlerine sahip bir Azure Active Directory uygulaması gereklidir. ve read/write hesapları için ayrı bir read-only uygulama oluşturun ve azure aboneliğinizde uygun izinleri verin. Buna ek olarak, her iki rolün de 1. adımdaki Terraform durumunun bulunduğu depolama hesabında en az Reader and Data Access izinlere sahip olması gerekir. Ardından, GitHub'ın OpenID Bağlan (OIDC) kullanarak kimliği kullanmasına izin vermek için federasyon kimlik bilgilerini ayarlayın. Ayrıntılı yönergeler için Azure belgelerine bakın.

   Kimlik için read/write aşağıdaki gibi bir federasyon kimlik bilgisi oluşturun:

   • olarak ayarlayın Entity Type ve ortam adını kullanınproduction.Environment

   Kimlik için read-only aşağıdaki gibi iki federasyon kimlik bilgisi oluşturun:

   • Entity Type seçeneğini Pull Request olarak ayarlayın.
   • olarak ayarlayın Entity Type ve dal adını kullanınmain.Branch

4. GitHub gizli dizileri ekleme

   Dekont

   Azure kimlikleriyle ilgili verilerin hiçbiri gizli dizi veya kimlik bilgisi içermese de, ortam başına kimlik bilgilerini parametreleştirmek için kullanışlı bir yöntem olarak GitHub gizli dizilerini kullanmaya devam ediyoruz.

   Kimliği kullanarak depoda aşağıdaki gizli dizileri read-only oluşturun:

   • AZURE_CLIENT_ID : Azure'da uygulama kaydının uygulama (istemci) kimliği
   • AZURE_TENANT_ID : Uygulama kaydının tanımlandığı Azure Active Directory kiracı kimliği.
   • AZURE_SUBSCRIPTION_ID : Uygulama kaydının tanımlandığı abonelik kimliği.

   Depoya gizli dizi ekleme yönergeleri burada bulunabilir.

   Kimliği kullanarak read-write ortamda başka bir gizli dizi production oluşturun:

   • AZURE_CLIENT_ID : Azure'da uygulama kaydının uygulama (istemci) kimliği

   Gizli dizileri ortama ekleme yönergelerini burada bulabilirsiniz. Ortam gizli dizisi, yükseltilmiş okuma/yazma izinleri gerektiğinde ortama dağıtma adımı yapılırken depo gizli dizisini production geçersiz kılar.

GitHub Eylemleriyle dağıtma

Bicep kullanma

Başvuru mimarisine iki ana iş akışı dahildir:

1. Bicep Birim Testleri

   Bu iş akışı her işlemede çalışır ve altyapı kodundaki bir birim test kümesinden oluşur. Bicep derlemesini çalıştırarak bicep'i bir ARM şablonuna derler. Bu, biçimlendirme hatası olmamasını sağlar. Ardından, şablonun dağıtılabilir olduğundan emin olmak için bir doğrulama gerçekleştirir. Son olarak, IaC için açık kaynak bir statik kod çözümleme aracı olan checkov, güvenlik ve uyumluluk sorunlarını algılamak için çalışacaktır. Depo GitHub Advanced Security (GHAS) kullanıyorsa sonuçlar GitHub'a yüklenir.

2. Bicep What-If / Deploy

   Bu iş akışı her çekme isteğinde ve ana dala yapılan her işlemede çalışır. İş akışının durum aşaması, durum çalıştırılarak IaC değişikliklerinin Azure ortamı üzerindeki etkisini anlamak için kullanılır. Bu rapor daha sonra kolayca gözden geçirebilmek için çekme isteğine eklenir. Dağıtım aşaması, iş akışı ana dala yapılan bir gönderimle tetiklendiğinde durum analizinden sonra çalışır. Bu aşama, el ile yapılan bir gözden geçirme tamamlandıktan sonra şablonu Azure'a dağıtır .

Terraform kullanma

Başvuru mimarisine üç ana iş akışı dahildir:

1. Terraform Birim Testleri

   Bu iş akışı her işlemede çalışır ve altyapı kodundaki bir birim test kümesinden oluşur. Kodun düzgün bir şekilde lint olduğundan emin olmak için terraform fmt çalıştırır ve terraform en iyi yöntemlerini izler. Ardından terraform doğrulamasını gerçekleştirerek kodun söz dizimsel olarak doğru ve dahili olarak tutarlı olup olmadığını denetler. Son olarak, IaC için açık kaynak bir statik kod çözümleme aracı olan checkov, güvenlik ve uyumluluk sorunlarını algılamak için çalışacaktır. Depo GitHub Advanced Security (GHAS) kullanıyorsa sonuçlar GitHub'a yüklenir.

2. Terraform Planı / Uygula

   Bu iş akışı her çekme isteğinde ve ana dala yapılan her işlemede çalışır. İş akışının plan aşaması, terraform planını çalıştırarak IaC değişikliklerinin Azure ortamı üzerindeki etkisini anlamak için kullanılır. Bu rapor daha sonra kolayca gözden geçirebilmek için çekme isteğine eklenir. Uygulama aşaması, iş akışı ana dala yapılan bir gönderimle tetiklendiğinde plandan sonra çalıştırılır. Bu aşama plan belgesini alır ve ortamda bekleyen değişiklikler varsa el ile gözden geçirme imzalandıktan sonra değişiklikleri uygular .

3. Terraform Kayması Algılama

   Bu iş akışı, terraform dışında yapılan tüm yapılandırma kaymalarına veya değişikliklere karşı ortamınızı taramak için düzenli aralıklara göre çalışır. Herhangi bir kayma algılanırsa, projenin bakımcılarını uyarmak için bir GitHub Sorunu oluşturulur.

İlgili Kaynaklar

• Kod Olarak Altyapı nedir?
• Yinelenebilir altyapı
• Terraform ve Bicep karşılaştırması
• Checkov ve kaynak kodu
• GitHub Gelişmiş Güvenlik