Terraform’u Azure ile Kullanma

Terraform, kod dağıtım çözümleri olarak altyapı oluşturmak için özel bir dildir ve en büyük öne çıkan özelliklerinden biri de Azure dahil birden fazla farklı bulut satıcısını desteklemesidir. Benim üzerinde çalıştığım ve dağıtımlarını yaptığım ortamların % 90’ı veya daha fazlası ARM şablonlarıdır. Terraform’un son zamanlarda öne çıkması ile bazı temel Azure kaynaklarını dağıtmak için Terraform kullanmaya başladım ve sonrasında bu makaleyi oluşturmak için gereken iyi ve kötü noktalara dair görüşlerim oluştu. Bu görüşlerimi sizler ile paylaşmak istiyorum.

Önce, ARM şablonlarıyla karşılaştırdığımda kendi adıma artı bir değer sağlayan Terraform’da bulduğum şeylere bir göz atalım.

  • Yukarıda bahsettiğim gibi, Terraform’un en büyük öne çıkan özelliği, aynı dili Azure, AWS, GCE, OpenStack vb. genel bulut ortamlarınızda dağıtımlar yapmak için ve ayrıca kurum içi bare metal dağıtımları için kullanabilirsiniz. Bunun faydaları gerçekten multicloud kullanan kurumlar için paha biçilemez.
  • Terraform, HashiCorp Konfigürasyon Dili (HCL) adlı özel bir dil kullanır. HCL, insan tarafından okunabilir ve makine dostu olmak arasında bir uzlaşma olacak şekilde tasarlanmıştır ve benim tecrübeme göre bu kodu okuması genel olarak ARM şablon JSON’dan daha kolaydır.
  • Terraform’a bakmaya başladığımda bunu beklemiyordum, ama aslında ARM şablonlarında bulunmayan bazı nesneler yaratma olanağı sunuyor. Açık olanı, Terraform şablonunda birinci sınıf nesneler olarak tanımlanan ve bunlara yerleştirilmiş kaynaklar olarak tanımlanan kaynak gruplarıdır, bu yaklaşımı, kaynak grubunun şablonu çalıştırmak için komuttan ziyade yerine çalıştırılması komutuyla ima edildiği ARM’a tercih ederim. Kaynak gruplarına ek olarak Terraform, bir ARM şablonunda şu anda mümkün olmayan create storage containers, queues, tables ve file shares oluşturabilir.
  • Bir ARM şablonuyla dağıtımın tümü, Azure’da çalışan kendi dağıtımındadır, ancak bir Terraform şablonunu dağıttığınızda bir durum dosyası oluşturur – “terraform.tfstate”. Bu durum dosyası, konuşlandırıldığı altyapının durumunu, bu altyapıdan ayrı olarak depolamak için kullanılır. Bir ARM şablon dünyasından gelince, bu başlangıçta biraz garip görünüyor, çünkü şimdi altyapının kendisine güvenmek yerine ayrı bir dosyayı yönetmeniz gerekiyor, ancak bu yaklaşımı kullanmanın bazı faydaları var:
    • Terraform, kullandığı kaynakların bilgisini ve sahipliğini korur, bu nedenle “Terraform Destroy” çalıştırmak gibi şeyler yapabilir ve bir ARM şablonunda kaynak grubunu kaldırmak için kullanabilirsiniz.
    • Terraform, dağıtımla ilgili meta verileri depolayabilir; bu, Terraform’un kaynak API’nin sağladığı şeyden daha fazla işlevsellik sağlamasına olanak tanıyarak, özellikle dağıtdığınız kaynakların bir parçası olmayan şeyler hakkında bilgi sahibi olabileceği anlamına gelir.
    • Bir dağıtım için durum dosyaları giriş verileri olarak başkaları tarafından kullanılabilir, bu nedenle mevcut bir altyapı dağıtımının üzerine bir uygulama dağıtımı yapıyorsanız, ayrıntıları almak için bu duruma başvurabilirsiniz.
    • Durumdosyaları, şirket içi dağıtımlar gibi, durumdan alınacak karmaşık bir kaynak API’si sunmayan sağlayıcılarla çalışırken çok önemli hale gelir.

Terraform, aynı ortamda çalışan ve ortamlar arasında (çalışma alanları) farklı durumlara sahip kişiler arasında durumu paylaşmanın yollarını içerir. Mevcut dağıtım ile aynı hizada olduğundan emin olmak için durumu yenilemek de mümkündür.

  • Durum kullanmanın diğer bir avantajı, konuşlandırma yapmadan önce “Terraform Plan” komutunu çalıştırabilmenizdir. Bu durum dosyasına ve dağıtmaya çalıştığınız şablona bakar ve yapması gereken değişiklikleri belirler, aslında herhangi bir şey yapmadan, size dağıtımın bu ortamda neyin değişeceğine dair bir özet sunar. Bu sadece neyin değişeceğini belgelemekle kalmıyor, aynı zamanda kaynakları oluşturmak için kullanacağı dağıtım planını da yaratıyor. Bunu bir dosyaya çıkarmak için -out parametresini plan komutuyla belirleyebilir ve ardından “Terraform Apply” komutunu kullanabilirsiniz.
  • Veri kaynakları, Terraform’daki Terraform dışından veri toplamanıza izin veren yapılandırma nesneleridir. Her sağlayıcıda bulunan geniş bir veri kaynağı yelpazesi vardır, örneğin Azure sağlayıcısında, DNS Bölgeleri, RBAC Rolleri, Disk Görüntüleri vb. gibi mevcut kaynaklar hakkında bilgi almak için veri kaynaklarını kullanabiliriz, AWS kaynakları için benzer sağlayıcılar mevcuttur ve diğer bulut sağlayıcıları için de. Git, Data Dog, New Relic vb. gibi hizmetler için bir dosyadan veya zip’ten veri çekmenize olanak sağlayan daha genel veri kaynakları da vardır. Bu yerleşik sağlayıcıların hiçbiri ihtiyaçlarınızı karşılamıyorsa, bir komut dosyasını çağırmanıza ve JSON olarak döndürüldüğü sürece bu verileri okumanıza izin veren harici bir veri kaynağı da vardır.
  • Terraform’daki modüller yeniden kullanılabilir kod oluşturmanın bir yolunu sunar. Temelde bir modül, başka bir Terraform şablonu veya birlikte paketlenmiş bir dizi şablondur ve daha sonra ana şablonunuzdan çağırılabilir.

Aşağıdakiler de ARM şablonları ile karşılaştırdığımda gördüğüm bazı eksikler olarak söylenebilir.

  • Açıkçası Terraform’daki kaynaklar Hashicorp tarafından yaratılıyor, bu nedenle Microsoft tarafından Azure kaynaklarının yayınlanması ve Terraform’da oluşturmaya hazır olmaları arasında bir gecikme potansiyeli var. Kaynaklar oldukça hızlı bir şekilde eklenmiş gibi görünüyor, örneğin zaten AKS için bir kaynak var, ancak bazı eksiklikler var. Örneğin, şu anda bir Azure Kurtarma Hizmeti Kasası veya bir Uygulama Hizmeti sertifikası oluşturacak bir kaynak bulunmamaktadır. Daha düşük bir seviyede, Terraform kullanarak oluşturabileceğim bazı PaaS kaynakları (web uygulaması, SQL vb.) Oluşturduğunda bir ARM şablonum var, ancak ARM şablonum da bu kaynakları teşhis verilerini Log Analytics’e gönderecek şekilde yapılandırıyor. Bunu yapmak için işlevsellik şu anda Azure için TerraForm şablonlarında mevcut değildir.
  • Yukarıda durum dosyalarının kullanılmasının yararlarından bahsettik, ancak bazı olumsuz yanları da var. Öncelikle, dağıtımlarınız için yönetmeniz ve güvende tutmanız gereken önemli bir ek dosyanız var. Durum dosyanızı kaybederseniz veya üzerine yazılırsa, başınız büyük belada demektir. Durum dosyanızı varolan altyapıya karşı yenilemek için “Terraform Refresh” komutunu kullanabilirsiniz, böylece bir kullanıcı bir kaynağı sildiyse veya eklediyse veya yapılandırmasını değiştirdiyse düzeltebilir, ancak bu yaklaşımdan tamamen yeni bir durum dosyası elde edemezsiniz . Terraform’un durum dosyasına kaydettiği meta veriler, durum dosyasından başka bir yerde değildir. Açıkçası, durum dosyanızı, yedeklenmiş merkezi bir konumda depolayarak çalışabilirsiniz ancak bunu düşünmeniz gerekir. Ek olarak, durum ortamınıza bağlıdır, bu nedenle her seferinde altyapınızın başka bir örneğini dağıtmak istediğinizde başka bir durum dosyasını yönetmeniz gerekir. Çalışma alanlarının kullanımı bunu bazı açılardan sizin için yöneterek, ortamlar arasında kolayca geçiş yapmanızı sağlar, ancak yine de bu dosyayı yönetmeniz ve bunlara bakmanız gerekir. ARM şablonlarıyla, doğru kaynak grubuna dağıttığınız sürece, her şeyin ihtiyaç duyduğu yere gitmesi gerektiğini biliyoruz. State ile ikinci konu güvenlikle ilgili. Bir durum dosyasına bakarsanız, dağıtımınızla ilgili birçok bilgiyi düz metin olarak kaydettiğini göreceksiniz, buna değişkenler, kaynak bilgileri vb. gibi şeyler de dahildir. Bu öğeler hassassa, bu gerçek bir sorun olabilir.
  • ARM şablonları ile Parametreleri bir parametre dosyasında tutabilir ve dağıtım zamanında konuşlandırma komutuna aktarabilirsiniz. Farklı bir parametre seti kullanmak isterseniz, sadece farklı bir dosyaya geçebilirsiniz. Bu tür bir esneklik Terraform’da birkaç nedenden ötürü yoktur:
    • Durum – Farklı bir değişkenler grubu varsa, aynı durum dosyasını kullanmaya devam eder ve bu nedenle mevcut durumla çalışmayı bekleyebilirsiniz, bu önemli bir karışıklığa neden olabilir.
    • Dosya birleştirme – Bir Terraform dağıtımını çalıştırırken, ARM’de olduğu gibi bir şablon ve parametre dosyası belirtmezsiniz, sadece belirtilen bir klasörden çalıştırırsınız. Terraform, dağıtımınızı oluşturmak için bu klasördeki tüm .tf dosyalarını bir araya getirir. Değişkenler sadece başka bir şey gibi bir .tf dosyasında saklanır, bu yüzden iki değişken grubuna sahip olmak için iki klasöre sahip olmalısınız ve içindeki tüm dosyaları çoğaltmalısınız.
  • ARM’deki parametre dosyalarının bir diğer avantajı, bir Azure Keyvault’a doğrudan secretlar için başvurabilmenizdir. Dağıtım hesabınızın kasaya erişimi olduğunu varsayarsak, secretları doğrudan çekip kullanabilirsiniz. Bu şu anda Terraform’da mümkün değildir.
  • Testlerimde de karşılaştığım bir konu, Terraform hata mesajlarının yararsızlığından ve hata ayıklama kayıtlarının sık sık kullanılmadığından şikayet eden çevrimiçi bir çok makale var.

Terraform’un gerçekten ilginç kavramları var, bazı alanlarda ARM şablonlarına göre kesin faydaları göze çarpıyor ve Terraform ile çalışmaktan gerçekten zevk aldım. Çok bulutlu bir dağıtım gerçekleştirme ya da yerinde dağıtma gereksiniminiz varsa, kesinlikle Terraformdan yararlanmanızı tavsiye ederim.

Facebooktwitterredditpinterestlinkedinmailby feather

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.