Birçok kişi Terraform'u günlük işlerinde biliyor ve kullanıyor ancak bunun için en iyi uygulamalar henüz oluşturulmadı. Her takımın kendi yaklaşımlarını ve yöntemlerini icat etmesi gerekiyor.
Altyapınız neredeyse kesinlikle basit bir şekilde başlar: birkaç kaynak + birkaç geliştirici. Zamanla her yöne doğru büyür. Kaynakları Terraform modülleri halinde gruplandırmanın, kodları klasörler halinde düzenlemenin ve başka nelerin yanlış gidebileceğinin yollarını buluyor musunuz? (Ünlü son sözler)
Zaman geçiyor ve altyapınızın yeni evcil hayvanınız olduğunu hissediyorsunuz, ama neden? Altyapıda açıklanamayan değişikliklerden endişeleniyorsunuz, altyapıya ve koda dokunmaktan korkuyorsunuz - bunun sonucunda yeni işlevleri geciktiriyorsunuz veya kaliteyi düşürüyorsunuz...
Üç yıl boyunca Github'da AWS için Terraform topluluk modülleri koleksiyonunu yönettikten ve Terraform'un üretimde uzun vadeli bakımını yaptıktan sonra Anton Babenko deneyimini paylaşmaya hazır: gelecekte zarar görmemesi için TF modüllerinin nasıl yazılacağı.
Konuşmanın sonunda katılımcılar Terraform'daki kaynak yönetimi ilkelerine, Terraform'daki modüllerle ilgili en iyi uygulamalara ve altyapı yönetimiyle ilgili bazı sürekli entegrasyon ilkelerine daha aşina olacaklar.
Yasal Uyarı: Bu raporun Kasım 2018 tarihli olduğunu belirtmek isterim; üzerinden 2 yıl geçti. Raporda tartışılan Terraform 0.11 sürümü artık desteklenmiyor. Geçtiğimiz 2 yılda pek çok yenilik, iyileştirme ve değişiklik içeren 2 yeni sürüm yayınlandı. Lütfen buna dikkat edin ve belgeleri kontrol edin.
Bağlantılar:
- +
- — kodu ve belgeleri otomatik biçimlendirme
- — Terraform modüllerinin jeneratörü (WIP)
- — Görsel diyagramlardan (WIP) Terraform kod üreteci
- www.terraform-best-practices.com
- (Yeni yazılar kişisel web sitem www.antonbabenko.com/'da)
- @antonbabenko - Twitter ve bir sürü farklı Slack
Benim adım Anton Babenko. Muhtemelen bazılarınız benim yazdığım kodu kullanmıştır. Artık bu konu hakkında her zamankinden daha güvenle konuşacağım çünkü istatistiklere erişimim var.
Terraform üzerinde çalışıyorum ve 2015 yılından bu yana Terraform ve Amazon ile ilgili çok sayıda açık kaynak projede aktif katılımcı ve katkıda bulunuyorum.
O zamandan beri bunu ilginç bir şekilde ifade edecek kadar kod yazdım. Ve şimdi size bunu anlatmaya çalışacağım.
Terraform ile çalışmanın inceliklerinden ve özelliklerinden bahsedeceğim. Ancak bu aslında HighLoad'un konusu değil. Ve şimdi nedenini anlayacaksınız.
Zamanla Terraform modülleri yazmaya başladım. Kullanıcılar sorular yazdı, ben yeniden yazdım. Daha sonra kodu bir ön işleme kancası vb. kullanarak biçimlendirmek için çeşitli yardımcı programlar yazdım.
Çok ilginç projeler vardı. Kod oluşturmayı seviyorum çünkü bilgisayarın benim ve programcı için giderek daha fazla iş yapmasını seviyorum, bu yüzden şu anda görsel diyagramlardan bir Terraform kod oluşturucu üzerinde çalışıyorum. Belki bazılarınız onları görmüştür. Bunlar oklu güzel kutular. Ve "Dışa Aktar" düğmesini tıklayıp hepsini kod olarak alabilmenizin harika olacağını düşünüyorum.
Ukraynalıyım. Uzun yıllardır Norveç'te yaşıyorum.
Ayrıca bu rapora ilişkin bilgiler adımı bilen ve beni sosyal ağlarda bulan kişilerden toplanmıştır. Neredeyse her zaman aynı takma adı taşıyorum.
Bahsettiğim gibi, VPC, Otomatik Ölçeklendirme, RDS gibi en yaygın görevler için modülleri barındırdığımız GitHub'daki en büyük depolardan biri olan Terraform AWS modüllerinin ana sorumlusuyum.
Ve şimdi duyduklarınız en temel olanı. Terraform'un ne olduğunu anladığınızdan şüpheniz varsa, zamanınızı başka bir yerde geçirmeniz daha iyi olur. Burada çok fazla teknik terim olacak. Ve raporun seviyesini en yüksek seviye olarak ilan etmekten çekinmedim. Bu, çok fazla açıklama yapmadan mümkün olan tüm terimleri kullanarak konuşabileceğim anlamına geliyor.
Terraform, 2014 yılında altyapıyı kod olarak yazmanıza, planlamanıza ve yönetmenize olanak tanıyan bir yardımcı program olarak ortaya çıktı. Buradaki anahtar kavram “kod olarak altyapı”dır.
Söylediğim gibi tüm belgeler, . Umarım çoğu kişi bu siteyi biliyordur ve belgeleri okumuştur. Eğer öyleyse, o zaman doğru yerdesiniz.
Normal bir Terraform konfigürasyon dosyası bu şekilde görünür, ilk önce bazı değişkenleri tanımlıyoruz.
Bu durumda "aws_region"ı tanımlıyoruz.
Daha sonra hangi kaynakları oluşturmak istediğimizi açıklıyoruz.
Bağımlılıkları ve sağlayıcıları yüklemek için başta “terraform init” olmak üzere bazı komutları çalıştırıyoruz.
Ve belirtilen konfigürasyonun oluşturduğumuz kaynaklarla eşleşip eşleşmediğini kontrol etmek için “terraform application” komutunu çalıştırıyoruz. Daha önce hiçbir şey oluşturmadığımız için Terraform bizden bu kaynakları oluşturmamızı istiyor.
Bunu onaylıyoruz. Böylece deniz salyangozu adı verilen bir kova oluşturuyoruz.
Benzer birkaç yardımcı program da vardır. Amazon'u kullanan çoğunuz AWS CloudFormation'u, Google Cloud Deployment Manager'ı veya Azure Resource Manager'ı biliyor. Her birinin, bu genel bulut sağlayıcılarının her birinde kaynakların yönetimi için bir tür kendi uygulaması vardır. Terraform özellikle kullanışlıdır çünkü 100'den fazla sağlayıcıyı yönetmenize olanak tanır. (Daha fazla detay )
Terraform'un en başından beri takip ettiği hedefler:
- Terraform, kaynakların tek bir görünümünü sağlar.
- Tüm modern platformları desteklemenizi sağlar.
- Ve Terraform, en başından itibaren altyapıyı güvenli ve öngörülebilir bir şekilde değiştirmenize olanak tanıyan bir yardımcı program olarak tasarlandı.
2014 yılında "tahmin edilebilir" kelimesi bu bağlamda çok alışılmadık geliyordu.
Terraform evrensel bir yardımcı programdır. Bir API'niz varsa, kesinlikle her şeyi kontrol edebilirsiniz:
- İstediğiniz her şeyi yönetmek için 120'den fazla sağlayıcıyı kullanabilirsiniz.
- Örneğin GitHub depolarına erişimi tanımlamak için Terraform'u kullanabilirsiniz.
- Jira'da hatalar bile oluşturabilir ve kapatabilirsiniz.
- New Relic metriklerini yönetebilirsiniz.
- Gerçekten istiyorsanız dropbox'ta bile dosyalar oluşturabilirsiniz.
Bunların tümü, Go'da açıklanabilecek açık bir API'ye sahip Terraform sağlayıcıları kullanılarak gerçekleştirilir.
Diyelim ki önceki slaytlarda gösterdiğim gibi Terraform'u kullanmaya başladık, sitedeki bazı belgeleri okuduk, biraz video izledik ve main.tf yazmaya başladık.
Ve her şey harika, VPC oluşturan bir dosyanız var.
VPC oluşturmak istiyorsanız yaklaşık olarak bu 12 satırı belirtirsiniz. Hangi bölgede oluşturmak istediğinizi, hangi cidr_block IP adresini kullanacağınızı açıklayın. Bu kadar.
Doğal olarak proje yavaş yavaş büyüyecek.
Ve oraya bir sürü yeni şey ekleyeceksiniz: kaynaklar, veri kaynakları, yeni sağlayıcılarla entegre olacaksınız, aniden GitHub hesabınızdaki kullanıcıları yönetmek için Terraform'u kullanmak isteyeceksiniz, vb. DNS sağlayıcıları her şeyi çaprazlar. Terraform bunu kolaylaştırıyor.
Aşağıdaki örneğe bakalım.
VPC'nizdeki kaynakların internet erişimine sahip olmasını istediğiniz için yavaş yavaş internet_gateway'i eklersiniz. Bu iyi bir fikir.
Sonuç şu main.tf:
Bu main.tf'nin üst kısmıdır.
Bu main.tf dosyasının alt kısmıdır.
Daha sonra alt ağ eklersiniz. NAT ağ geçitlerini, rotaları, yönlendirme tablolarını ve diğer alt ağları eklemek istediğinizde, 38 hattınız olmayacak, yaklaşık 200-300 hattınız olacak.
Yani main.tf dosyanız yavaş yavaş büyüyor. Ve çoğu zaman insanlar her şeyi tek bir dosyaya koyarlar. Main.tf'de 10-20 Kb görünür. 10-20 Kb'ın metin içeriği olduğunu düşünün. Ve her şey her şeyle bağlantılıdır. Bununla çalışmak giderek zorlaşıyor. 10-20 Kb iyi bir kullanıcı durumudur, bazen daha da fazladır. Ve insanlar her zaman bunun kötü olduğunu düşünmezler.
Normal programlamada olduğu gibi, yani kod olarak altyapıda değil, bir sürü farklı sınıf, paket, modül, gruplama kullanmaya alışkınız. Terraform hemen hemen aynı şeyi yapmanıza olanak sağlar.
- Kod büyüyor.
- Kaynaklar arasındaki bağımlılık da artıyor.
Ve çok büyük bir ihtiyacımız var. Artık bu şekilde yaşayamayacağımızı anlıyoruz. Kodumuz muazzam hale geliyor. 10-20 Kb elbette çok büyük değil ama biz sadece ağ yığınından bahsediyoruz, yani sadece ağ kaynaklarını eklediniz. 100 Kb'nin kolayca dahil edilebileceği Application Load Balancer, dağıtım ES kümesi, Kubernetes vb.'den bahsetmiyoruz. Tüm bunları yazarsanız çok geçmeden Terraform'un Terraform modülleri sağladığını öğreneceksiniz.
Terraform modülleri, grup olarak yönetilen, bağımsız bir Terraform yapılandırmasıdır. Terraform modülleri hakkında bilmeniz gereken tek şey bu. Hiç akıllı değiller, bir şeye bağlı olarak karmaşık bağlantılar kurmanıza izin vermiyorlar. Bunların hepsi geliştiricilerin omuzlarına düşüyor. Yani bu, daha önce yazdığınız bir tür Terraform konfigürasyonudur. Ve bunu basitçe grup olarak adlandırabilirsiniz.
Yani 10-20-30 Kb kodumuzu nasıl optimize edeceğimizi anlamaya çalışıyoruz. Yavaş yavaş bazı modülleri kullanmamız gerektiğinin farkına varıyoruz.
Karşılaştığınız ilk modül türü kaynak modülleridir. Altyapınızın ne olduğunu, işinizin ne olduğunu, nerede ve şartların ne olduğunu anlamıyorlar. Bunlar tam olarak açık kaynak topluluğuyla birlikte benim yönettiğim ve altyapınızın ilk yapı taşları olarak öne sürdüğümüz modüllerdir.
Bir kaynak modülü örneği.
Bir kaynak modülünü çağırdığımızda içeriğini hangi yoldan yüklememiz gerektiğini belirtiriz.
Hangi sürümü indirmek istediğimizi belirtiyoruz.
Orada bir sürü argüman aktarıyoruz. Bu kadar. Bu modülü kullanırken bilmemiz gereken tek şey bu.
Birçok kişi en son sürümü kullanırlarsa her şeyin stabil olacağını düşünüyor. Ama hayır. Altyapının versiyonlanması gerekiyor; şu veya bu bileşenin hangi versiyona konuşlandırıldığını açıkça cevaplamalıyız.
İşte bu modülün içindeki kod. Güvenlik grubu modülü. Burada kaydırma 640. satıra gidiyor. Amazon'da mümkün olan her konfigürasyonda bir güvenlik grubu kaynağı oluşturmak, hiç de önemsiz olmayan bir görevdir. Sadece bir güvenlik grubu oluşturup ona hangi kuralları aktaracağını söylemek yeterli değildir. Çok basit olurdu. Amazon'da milyonlarca farklı kısıtlama var. Örneğin, eğer kullanıyorsanız VPC uç noktası, önek listesi, çeşitli API'ler ve tüm bunları diğer her şeyle birleştirmeye çalışırsa Terraform bunu yapmanıza izin vermez. Amazon API'si de buna izin vermiyor. Dolayısıyla tüm bu berbat mantığı bir modül içerisine saklayıp, aynı buna benzeyen kullanıcı kodunu vermemiz gerekiyor.
Kullanıcının içeride nasıl yapıldığını bilmesine gerek yoktur.
Kaynak modüllerinden oluşan ikinci tip modüller zaten işinize daha uygun olan sorunları çözmektedir. Çoğu zaman burası Terraform'un bir uzantısı olan ve şirket standartları için etiketler için bazı katı değerler belirleyen bir yerdir. Ayrıca Terraform'un şu anda kullanmanıza izin vermediği işlevleri de buraya ekleyebilirsiniz. Bu şu anda. Artık sürüm 0.11, bu da geçmişte kalmak üzere. Ancak yine de ön işlemciler, jsonnet, cookiecutter ve diğer birçok şey, tam teşekküllü çalışma için kullanılması gereken yardımcı mekanizmalardır.
Daha sonra bunun bazı örneklerini göstereceğim.
Altyapı modülü de aynı şekilde çağrılıyor.
İçeriğin indirileceği kaynak belirtilir.
Bu modüle bir sürü değer aktarılır ve aktarılır.
Daha sonra, bu modülün içinde, bir VPC veya Application Load Balancer oluşturmak veya bir güvenlik grubu oluşturmak veya bir Elastic Container Service kümesi için bir dizi kaynak modülü çağrılır.
İki tip modül vardır. Bunu anlamak önemlidir çünkü bu raporda gruplandırdığım bilgilerin çoğu belgelerde yazılı değildir.
Ve Terraform'daki dokümantasyon şu anda oldukça sorunlu çünkü sadece bu özelliklerin var olduğunu, bunları kullanabileceğinizi söylüyor. Ancak bu özelliklerin nasıl kullanılacağını, neden bunları kullanmanın daha iyi olduğunu söylemiyor. Bu nedenle çok sayıda insan yaşayamayacağı şeyler yazıyor.
Şimdi bu modüllerin nasıl yazılacağına bir göz atalım. Daha sonra onları nasıl çağıracağımızı ve kodla nasıl çalışacağımızı göreceğiz.
Terraform Kaydı -
İpucu #0, kaynak modülleri yazmamaktır. Bu modüllerin çoğu zaten sizin için yazılmıştır. Dediğim gibi açık kaynaktırlar, hiçbir iş mantığınızı içermezler, IP adresleri, şifreler vb. için sabit kodlanmış değerlere sahip değildirler. Modül oldukça esnektir. Ve büyük olasılıkla zaten yazılmıştır. Amazon'daki kaynaklar için birçok modül var. 650 civarında. Ve çoğu kaliteli.
Bu örnekte birisi yanınıza geldi ve şöyle dedi: “Bir veritabanını yönetebilmek istiyorum. Bir modül oluştur ki ben de bir veritabanı oluşturabileyim." Kişi Amazon veya Terraform'un uygulama ayrıntılarını bilmiyor. Sadece şöyle diyor: "MSSQL'i yönetmek istiyorum." Yani modülümüzü çağıracak, motor tipini oraya geçirecek, saat dilimini belirtecek demek istiyoruz.
Ve bu modülün içinde iki farklı kaynak oluşturacağımızı bilmemeli: Biri MSSQL için, ikincisi diğer her şey için, çünkü Terraform 0.11'de saat dilimi değerlerini isteğe bağlı olarak belirleyemezsiniz.
Ve bu modülden çıkışta kişi basitçe bir adres alabilecek. Tüm bunları dahili olarak hangi veri tabanından, hangi kaynaktan oluşturduğumuzu bilemeyecek. Bu çok önemli bir gizleme unsurudur. Ve bu sadece açık kaynakta herkese açık olan modüller için değil, aynı zamanda projelerinizin ve ekiplerinizin içine yazacağınız modüller için de geçerlidir.
Bu, eğer Terraform'u bir süredir kullanıyorsanız oldukça önemli olan ikinci argümandır. Şirketiniz için tüm Terraform modüllerinizi koyacağınız bir havuzunuz var. Ve zamanla bu projenin bir veya iki megabayt boyutuna ulaşması da oldukça normal. Bu iyi.
Ancak sorun Terraform'un bu modülleri nasıl adlandırdığıdır. Örneğin, her bir kullanıcıyı oluşturmak için bir modül çağırırsanız, Terraform önce deponun tamamını yükleyecek ve ardından söz konusu modülün bulunduğu klasöre gidecektir. Bu şekilde her seferinde bir megabayt indireceksiniz. 100 veya 200 kullanıcıyı yönetiyorsanız 100 veya 200 megabayt indirip o klasöre gideceksiniz. Doğal olarak "Terraform init"e her basışınızda bir sürü şey indirmek istemezsiniz.
Bu sorunun iki çözümü var. Birincisi göreceli yolları kullanmaktır. Bu şekilde kodda klasörün yerel (./) olduğunu belirtirsiniz. Herhangi bir şeyi başlatmadan önce yerel olarak bu deponun Git klonunu yaparsınız. Bu şekilde bir kez yaparsınız.
Elbette birçok olumsuzluk var. Örneğin sürüm oluşturmayı kullanamazsınız. Ve bazen bununla yaşamak zordur.
İkinci çözüm. Çok sayıda alt modülünüz varsa ve zaten bir tür yerleşik işlem hattınız varsa, o zaman bir tek depodan birçok farklı paketi toplamanıza ve bunları S3'e yüklemenize olanak tanıyan MBT projesi vardır. Bu çok iyi bir yol. Bu nedenle, iam-user-1.0.0.zip dosyasının ağırlığı yalnızca 1 Kb olacaktır çünkü bu kaynağı oluşturmaya yönelik kod çok küçüktür. Ve çok daha hızlı çalışacak.
Modüllerde nelerin kullanılamayacağından bahsedelim.
Modüllerdeki bu kötülük neden? En kötü şey kullanıcıyı varsaymaktır. Kullanıcının farklı kişiler tarafından kullanılabilecek bir sağlayıcı kimlik doğrulama seçeneği olduğunu varsayalım. Mesela hepimiz bu rolü özümseyeceğiz. Bu da Terraform'un bu rolü üstleneceği anlamına geliyor. Daha sonra bu rol ile diğer eylemleri gerçekleştirecektir.
Kötü olan şu ki, eğer Vasya, örneğin varsayılan ortam değişkenini kullanarak Amazon'a bir şekilde bağlanmayı seviyorsa ve Petya, gizli bir yerde sahip olduğu paylaşılan anahtarını kullanmayı seviyorsa, o zaman ikisini de belirtemezsiniz. Terraform. Ve acı çekmemeleri için bu bloğu modülde belirtmeye gerek yoktur. Bunun daha yüksek bir düzeyde belirtilmesi gerekir. Yani bir kaynak modülümüz, bir altyapı modülümüz ve bir de kompozisyonumuz var. Ve bu daha yüksek bir yerde belirtilmelidir.
İkinci kötülük ise rızık verendir. Burada kötülük o kadar da önemsiz değil, çünkü eğer kod yazıyorsanız ve işinize yarıyorsa, o zaman eğer işe yarıyorsa neden değiştireceğinizi düşünebilirsiniz.
Kötü olan şey, öncelikle bu sağlayıcının ne zaman başlatılacağını her zaman kontrol edememenizdir. İkincisi, aws ec2'nin ne anlama geldiğini kontrol edemezsiniz, yani şu anda Linux'tan mı yoksa Windows'tan mı bahsediyoruz. Yani farklı işletim sistemlerinde veya farklı kullanıcı durumları için aynı şekilde çalışacak bir şey yazamazsınız.
Resmi belgelerde de belirtilen en yaygın örnek, aws_instance yazıp bir dizi argüman belirtirseniz, orada "local-exec" provizörünü belirleyip ansible'ınızı çalıştırmanız durumunda bunda yanlış bir şey olmamasıdır. başucu kitabı.
Aslında evet bunda yanlış bir şey yok. Ancak çok geçmeden bu local-exec olayının, örneğin launch_configuration'da mevcut olmadığını fark edeceksiniz.
Launch_configuration'ı kullandığınızda ve bir örnekten otomatik ölçeklendirme grubu oluşturmak istediğinizde, launch_configuration'da "sağlayıcı" kavramı yoktur. “Kullanıcı verileri” kavramı var.
Bu nedenle kullanıcı verilerini kullanmak daha evrensel bir çözümdür. Ve örnek açıldığında örneğin kendisinde veya otomatik ölçeklendirme grubu bu launch_configuration'ı kullandığında aynı kullanıcı verilerinde başlatılacaktır.
Provizyonu yine de çalıştırmak istiyorsanız, çünkü bu bir yapıştırma bileşenidir, bir kaynak oluşturulduğunda, o anda provizörünüzü, komutunuzu çalıştırmanız gerekir. Bu tür pek çok durum var.
Bunun için en doğru kaynağa da null_resource denir. Null_resource aslında hiçbir zaman yaratılmayan sahte bir kaynaktır. Hiçbir şeye dokunmuyor, API yok, otomatik ölçeklendirme yok. Ancak komutun ne zaman çalıştırılacağını kontrol etmenizi sağlar. Bu durumda komut oluşturma sırasında çalıştırılır.
Bağlantı
Birkaç işaret var. Tüm işaretlere ayrıntılı olarak girmeyeceğim. Bununla ilgili bir makale var. Ancak Terraform ile çalıştıysanız veya başkalarının modüllerini kullandıysanız, çoğu modülün, açık kaynak kodların çoğu gibi, insanlar tarafından kendi ihtiyaçları için yazıldığını sıklıkla fark etmişsinizdir. Bir adam bunu yazdı ve sorununu çözdü. GitHub'a yerleştirdim, yaşamasına izin verdim. Yaşayacak, ancak orada belge ve örnek yoksa kimse onu kullanmayacaktır. Ve eğer kendi özel görevinden biraz daha fazlasını çözmenize izin veren bir işlevsellik yoksa, o zaman kimse onu da kullanmayacaktır. Kullanıcı kaybetmenin pek çok yolu var.
İnsanların kullanması için bir şeyler yazmak istiyorsanız bu işaretleri takip etmenizi öneririm.
Bunlar şunlardır:
- Dokümantasyon ve örnekler.
- Tam işlevsellik.
- Makul varsayılanlar.
- Kodu temizleyin.
- Testler.
Testler farklı bir durumdur çünkü yazılması oldukça zordur. Ben belgelere ve örneklere daha çok inanıyorum.
Böylece modüllerin nasıl yazılacağına baktık. İki argüman var. İlki ve en önemlisi, eğer yapabiliyorsanız yazmamaktır, çünkü bu görevleri sizden önce bir grup insan zaten yapmıştır. İkincisi, eğer hala karar verirseniz, modüllerde ve provizyon sağlayıcılarda sağlayıcıları kullanmamaya çalışın.
Bu, belgelerin gri kısmıdır. Şimdi şöyle düşünüyor olabilirsiniz: “Bir şeyler belirsiz. İkna olmadım." Ama altı ay sonra göreceğiz.
Şimdi bu modülleri nasıl çağıracağımızdan bahsedelim.
Kodumuzun zamanla büyüdüğünü biliyoruz. Artık tek dosyamız yok, zaten 20 dosyamız var. Hepsi tek bir klasörde. Ya da belki beş klasör. Belki bunları bir şekilde bölgelere, bazı bileşenlere ayırmaya başlıyoruz. O zaman artık senkronizasyon ve orkestrasyonun bazı temel ilkelerine sahip olduğumuzu anlıyoruz. Yani, ağ kaynaklarını değiştirirsek ne yapmamız gerektiğini, geri kalan kaynaklarımızla ne yapmamız gerektiğini, bu bağımlılıklara nasıl sebep olacağımızı vb. anlamalıyız.
İki aşırı uç var. İlk aşırılık hepsi bir arada. Bir tane ana dosyamız var. Şimdilik bu, Terraform web sitesindeki resmi en iyi uygulamaydı.
Ama şimdi kullanımdan kaldırılmış olarak yazılıyor ve kaldırılıyor. Zamanla Terraform topluluğu bunun en iyi uygulamadan uzak olduğunu fark etti çünkü insanlar projeyi farklı şekillerde kullanmaya başladı. Ve sorunlar var. Örneğin tüm bağımlılıkları tek bir yerde listelediğimizde. “Terraform planı”na tıkladığımızda Terraform’un tüm kaynakların durumlarını güncellemesine kadar çok zaman geçebildiği durumlar olabiliyor.
Çok fazla zaman, örneğin 5 dakikadır. Bazıları için bu çok uzun bir süre. 15 dakika süren vakalar gördüm. AWS API, her bir kaynağın durumunda neler olduğunu anlamaya çalışmak için 15 dakika harcadı. Bu çok geniş bir alan.
Ve doğal olarak, bir yerde bir şeyi değiştirmek istediğinizde, 15 dakika beklediğinizde buna bağlı bir sorun ortaya çıkacaktır ve bu size bazı değişikliklerin tuvalini verir. Tükürdün, "Evet" yazdın ve bir şeyler ters gitti. Bu çok gerçek bir örnek. Terraform sizi sorunlardan korumaya çalışmaz. Yani istediğini yaz. Sorunlar olacak - sizin sorunlarınız. Terraform 0.11 size hiçbir şekilde yardımcı olmaya çalışmıyor. 0.12'de şunu söylemenizi sağlayan bazı ilginç yerler var: "Vasya, bunu gerçekten istiyorsun, aklını başına toplayabilir misin?"
İkinci yol ise bu alanı azaltmaktır, yani bir yerden gelen çağrılar diğer yerden daha az bağlanabilir.
Tek sorun daha fazla kod yazmanız gerekmesi, yani çok sayıda dosyadaki değişkenleri tanımlamanız gerekiyor, bunu güncelleyin. Bazı insanlar bundan hoşlanmaz. Bu benim için normaldir. Bazıları da şöyle düşünüyor: "Bunu neden farklı yerlere yazayım ki, hepsini bir yere koyayım." Bu mümkündür, ancak bu ikinci uç noktadır.
Bütün bunları tek bir yerde yaşayan kim? Bir, iki, üç kişi yani birisi kullanıyor.
Peki belirli bir bileşeni, bir bloğu veya bir altyapı modülünü kim çağırıyor? Beş ila yedi kişi. Bu havalı.
En yaygın cevap ortada bir yerdedir. Proje büyükse, çoğu zaman hiçbir çözümün uygun olmadığı ve her şeyin yolunda gitmediği bir durumla karşılaşırsınız ve sonuçta bir karışım elde edersiniz. Her ikisinin de avantajları olduğunu anladığınız sürece bunda yanlış bir şey yok.
Yığın VPC'sinde bir şey değiştiyse ve bu değişiklikleri EC2'ye uygulamak istiyorsanız, yani yeni bir alt ağınız olduğu için otomatik ölçeklendirme grubunu güncellemek istiyorsanız, o zaman bu tür bir bağımlılık düzenlemesi derim. Bazı çözümler var: Kim neyi kullanıyor?
Hangi çözümlerin mevcut olduğunu önerebilirim. Sihri yapmak için Terraform'u kullanabilir veya Terraform'u kullanmak için makefile dosyalarını kullanabilirsiniz. Orada bir şeylerin değişip değişmediğine bakın, onu buradan başlatabilirsiniz.
Bu kararı nasıl buldunuz? Bunun harika bir çözüm olduğuna inanan var mı? Bir gülümseme görüyorum, görünüşe göre şüpheler içeri girmiş.
Elbette bunu evde denemeyin. Terraform hiçbir zaman Terraform'dan çalıştırılacak şekilde tasarlanmamıştır.
Bir raporda bana şunu söylediler: "Hayır, bu işe yaramayacak." Mesele şu ki, işe yaramaması gerekiyor. Terraform'u Terraform'dan ve ardından Terraform'u başlattığınızda çok etkileyici görünse de, bunu yapmamalısınız. Terraform her zaman çok kolay başlamalıdır.
Tek bir yerde bir şeyler değiştiğinde çağrı düzenlemeye ihtiyacınız varsa Terragrunt var.
Terragrunt, altyapı modüllerine yapılan çağrıları koordine etmenize ve düzenlemenize olanak tanıyan, Terraform'a eklenen bir yardımcı programdır.
Tipik bir Terraform yapılandırma dosyası şuna benzer.
Hangi modülü çağırmak istediğinizi siz belirlersiniz.
Modülün hangi bağımlılıkları var?
Ve bu modül hangi argümanları kabul ediyor? Terragrunt hakkında bilmeniz gereken tek şey bu.
Belgeler orada ve GitHub'da 1 yıldız var. Ancak çoğu durumda bilmeniz gereken şey budur. Ve bunu Terraform ile yeni çalışmaya başlayan firmalarda uygulamak çok kolaydır.
Yani orkestrasyon Terragrunt'tur. Başka seçenekler de var.
Şimdi kodla nasıl çalışılacağından bahsedelim.
Kodunuza yeni özellikler eklemeniz gerekiyorsa çoğu durumda bu kolaydır. Yeni bir kaynak yazıyorsunuz, her şey basit.
Eğer önceden oluşturduğunuz bir kaynağınız varsa, örneğin Terraform’u AWS hesabı açtıktan sonra öğrendiniz ve halihazırda sahip olduğunuz kaynakları kullanmak istiyorsanız modülünüzü bu şekilde genişletmeniz uygun olacaktır. Mevcut kaynakların kullanımını destekler.
Ve blok kaynağı kullanılarak yeni kaynakların oluşturulmasını destekledi.
Çıkışta, kullanılana bağlı olarak her zaman çıkış kimliğini döndürürüz.
Terraform 0.11'deki ikinci çok önemli sorun listelerle çalışmaktır.
Buradaki zorluk, eğer böyle bir kullanıcı listemiz varsa.
Ve bu kullanıcıları blok kaynağı kullanarak oluşturduğumuzda her şey yolunda gider. Her biri için bir dosya oluşturarak listenin tamamını gözden geçiriyoruz. Herşey yolunda. Ve daha sonra örneğin ortadaki user3'ün buradan kaldırılması gerekir, daha sonra indeks değişeceği için ondan sonra oluşturulan tüm kaynaklar yeniden oluşturulacaktır.
Durum bilgisi olan bir ortamda listelerle çalışma. Durum bilgisi olan bir ortam nedir? Bu kaynak yaratıldığında yeni bir değerin yaratılması durumudur. Örneğin AWS Erişim Anahtarı veya AWS Gizli Anahtarı yani bir kullanıcı oluşturduğumuzda yeni bir Erişim veya Gizli Anahtar alıyoruz. Ve bir kullanıcıyı her sildiğimizde bu kullanıcının yeni bir anahtarı olacaktır. Ancak bu feng shui değil, çünkü takımdan her ayrıldığında onun için yeni bir kullanıcı oluşturursak kullanıcı bizimle arkadaş olmak istemeyecektir.
Çözüm bu. Bu Jsonnet'te yazılmış koddur. Jsonnet, Google'ın şablon oluşturma dilidir.
Bu komut, bu şablonu kabul etmenizi sağlar ve çıktı olarak şablonunuza göre yapılmış bir json dosyası döndürür.
Şablon şuna benziyor.
Terraform, hem HCL hem de Json ile aynı şekilde çalışmanıza olanak tanır; dolayısıyla Json oluşturma yeteneğiniz varsa, onu Terraform'a kaydırabilirsiniz. .tf.json uzantılı dosya başarıyla indirilecektir.
Ve sonra her zamanki gibi onunla çalışıyoruz: terraform init, terramorm application. Ve iki kullanıcı oluşturuyoruz.
Artık birisinin takımdan ayrılmasından korkmuyoruz. Sadece json dosyasını düzenleyeceğiz. Vasya Pupkin gitti, Petya Pyatochkin kaldı. Petya Pyatochkin yeni bir anahtar almayacak.
Terraform'u diğer araçlarla entegre etmek aslında Terraform'un işi değil. Terraform, kaynak yaratmak için bir platform olarak yaratıldı ve hepsi bu. Ve sonradan ortaya çıkan her şey Terraform'u ilgilendirmiyor. Ve onu orada örmeye gerek yok. İhtiyacınız olan her şeyi yapan Ansible var.
Ancak Terraform'u genişletmek istediğimizde ve bir şey tamamlandıktan sonra bazı komutları çağırmak istediğimizde durumlar ortaya çıkar.
İlk yol. Bu komutu yazdığımız bir çıktı oluşturuyoruz.
Daha sonra bu komutu kabuk terraform çıktısından çağırıp istediğimiz değeri belirtiyoruz. Böylece komut, değiştirilen tüm değerlerle yürütülür. Çok rahat.
İkinci yol. Bu, altyapımızdaki değişikliklere bağlı olarak null_resource kullanımıdır. Bazı kaynakların ID'si değiştiğinde aynı local-exe'yi çağırabiliriz.
Doğal olarak, kağıt üzerinde her şey yolunda çünkü Amazon, diğer tüm kamu sağlayıcıları gibi, kendi uç durumlarına sahip.
En yaygın uç durum, bir AWS hesabı açtığınızda hangi bölgeleri kullandığınızın önemli olmasıdır; bu özellik orada etkin mi; belki Aralık 2013'ten sonra açtınız; belki VPC'de varsayılanı kullanıyorsunuz vb. Birçok kısıtlama var. Ve Amazon bunları belgelerin tamamına dağıttı.
Kaçınmanızı tavsiye ettiğim birkaç şey var.
Başlamak için Terraform planı veya Terraform CLI içindeki tüm gizli olmayan tartışmalardan kaçının. Bütün bunlar bir tfvars dosyasına veya bir ortam değişkenine yerleştirilebilir.
Ancak bu sihirli komutun tamamını ezberlemenize gerek yok. Terraform planı – var ve yola çıkıyoruz. İlk değişken var, ikinci değişken var, üçüncüsü dördüncü. Kod olarak altyapının en sık kullandığım en önemli prensibi, sadece koda bakarak orada neyin, hangi durumda ve hangi değerlerle konuşlandırıldığını net bir şekilde anlamam gerektiğidir. Böylece belgeleri okumama veya Vasya'ya kümemizi oluşturmak için hangi parametreleri kullandığını sormama gerek kalmıyor. Genellikle ortamla eşleşen tfvars uzantılı bir dosyayı açmam ve oradaki her şeye bakmam gerekiyor.
Ayrıca kapsamı daraltmak için hedef bağımsız değişkenleri kullanmayın. Bunun için küçük altyapı modüllerini kullanmak çok daha kolaydır.
Ayrıca paralelliği sınırlamaya ve artırmaya gerek yoktur. 150 kaynağım varsa ve Amazon paralelliğini varsayılan 10'dan 100'e çıkarmak istersem, büyük olasılıkla bir şeyler ters gidecektir. Ya da şu anda her şey yolunda gidebilir ama Amazon çok fazla arama yaptığınızı söylediğinde başınız belaya girer.
Terraform bu sorunların çoğunu yeniden başlatmayı deneyecek, ancak neredeyse hiçbir şey başaramayacaksınız. Parallelism=1, AWS API'sinde veya Terraform sağlayıcısında bir hatayla karşılaşırsanız kullanmanız gereken önemli bir şeydir. Ve sonra şunu belirtmeniz gerekir: paralellik=1 ve Terraform bir çağrıyı, ardından ikinciyi, ardından üçüncüyü bitirene kadar bekleyin. Bunları birer birer fırlatacak.
İnsanlar bana sık sık şu soruyu soruyor: "Terraform çalışma alanlarının neden kötü olduğunu düşünüyorum?" Kod olarak altyapının ilkesinin, hangi altyapının hangi değerlerle oluşturulduğunu görmek olduğuna inanıyorum.
Çalışma alanları kullanıcılar tarafından oluşturulmadı. Bu, kullanıcıların GitHub'a Terraform çalışma alanları olmadan yaşayamayacağımız sorunlar yazdığı anlamına gelmiyor. Hayır bu şekilde değil. Terraform Enterprise ticari bir çözümdür. HashiCorp'tan Terraform çalışma alanlarına ihtiyacımız olduğuna karar verdi ve bu yüzden onu dosyaladık. Ayrı bir klasöre koymanın çok daha kolay olduğunu düşünüyorum. Sonra biraz daha dosya olacak ama daha net olacak.
Kodla nasıl çalışılır? Aslında listelerle çalışmak tek acıdır. Ve Terraform'u daha kolay kullanın. Bu sizin için her şeyi harika yapacak şey değil. Belgelerde yazılan her şeyi oraya itmeye gerek yok.
Raporun konusu “gelecek için” yazılmıştı. Bu konuya çok kısaca değineceğim. Gelecek için bu, 0.12'nin yakında yayınlanacağı anlamına geliyor.
0.12 bir ton yeni şey. Düzenli programlamadan geliyorsanız, sol ve sağ tarafların aynı anda hesaplanmadığı, ancak duruma bağlı olarak her türlü dinamik bloğu, döngüyü, doğru ve koşullu karşılaştırma işlemlerini kaçırırsınız. Çok özlüyorsunuz, bu yüzden 0.12 sizin için çözecektir.
Ancak! Hazır modüller ve üçüncü taraf çözümleri kullanarak daha az ve daha basit yazarsanız, o zaman beklemek zorunda kalmazsınız ve 0.12'nin gelip sizin için her şeyi düzelteceğini ummazsınız.
Rapor için teşekkürler! Altyapıdan kod olarak bahsettiniz ve testler hakkında tam anlamıyla bir kelime söylediniz. Modüllerde testlere ihtiyaç var mı? Bu kimin sorumluluğundadır? Bunu kendim mi yazmam gerekiyor yoksa modüllerin sorumluluğunda mı?
Gelecek yıl her şeyi test etmeye karar verdiğimize dair raporlarla dolu olacak. Neyin test edileceği en büyük sorudur. Farklı sağlayıcılardan çok fazla bağımlılık ve birçok kısıtlama var. Sen ve ben konuşurken ve sen "Testlere ihtiyacım var" dediğinde ben de şunu soruyorum: "Neyi test edeceksin?" Bölgenizde test yapacağınızı söylüyorsunuz. Sonra bu benim bölgemde işe yaramıyor diyorum. Yani bu konuda anlaşamayacağız bile. Pek çok teknik sorunun yaşandığını da söylemeden geçemeyeceğiz. Yani bu testlerin yeterli olması için nasıl yazılacağı.
Bu konuyu, yani yazdığınız altyapıya dayalı olarak testlerin otomatik olarak nasıl oluşturulacağını aktif olarak araştırıyorum. Yani bu kodu siz yazdıysanız çalıştırmam gerekiyor, buna dayanarak testler oluşturabilirim.
Terraform için entegrasyon testleri yazmanıza olanak sağlayan, en çok bahsedilen kütüphanelerden biridir. Bu yardımcı programlardan biridir. DSL türünü tercih ediyorum, örneğin rspec.
Anton, rapor için teşekkürler! Benim adım Valery. Küçük bir felsefi soru sorayım. Koşullu olarak provizyon var, dağıtım var. Provizyon benim altyapımı oluşturur, dağıtım sırasında onu yararlı bir şeyle doldururuz, örneğin sunucular, uygulamalar vb. Ve kafamda Terraform'un daha çok provizyon için ve Ansible'ın daha çok dağıtım için olduğu, çünkü Ansible'ın aynı zamanda fiziksel altyapı için olduğu da düşünülüyor. nginx, Postgres'i yüklemenizi sağlar. Ancak aynı zamanda Ansible, örneğin Amazon veya Google kaynaklarının sağlanmasına da izin veriyor gibi görünüyor. Ancak Terraform ayrıca bazı yazılımları modüllerini kullanarak dağıtmanıza da olanak tanır. Sizin bakış açınıza göre Terraform ile Ansible arasında bir tür sınır var mı, nerede ve neyin kullanılması daha iyi? Veya örneğin Ansible'ın zaten çöp olduğunu mu düşünüyorsunuz, her şey için Terraform'u kullanmayı denemelisiniz?
Güzel soru Valery. Terraform'un 2014'ten bu yana amaç açısından değişmediğine inanıyorum. Altyapı için yaratıldı ve altyapı için öldü. Ansible konfigürasyon yönetimine hâlâ ihtiyacımız vardı ve olacak. Sorun, launch_configuration'ın içinde kullanıcı verilerinin bulunmasıdır. Ve işte Ansible'ı vb. çekiyorsunuz. Bu benim en sevdiğim standart ayrımdır.
Güzel bir altyapıdan bahsediyorsak Packer gibi bu imajı toplayan yardımcı programlar var. Daha sonra Terraform bu görüntüyü bulmak ve launch_configuration'ı güncellemek için veri kaynağını kullanır. Yani, bu şekilde boru hattı önce Tracker'ı, ardından Terraform'u çekmemizdir. Ve eğer yapı oluşursa, yeni bir değişiklik meydana gelir.
Merhaba! Rapor için teşekkürler! Adım Misha, RBS şirketi. Kaynak oluştururken ön hazırlık aracılığıyla Ansible'ı arayabilirsiniz. Ansible'ın dinamik envanter adı verilen bir konusu da var. Ve önce Terraform'u arayabilir, ardından eyaletten kaynakları alıp çalıştıracak olan Ansible'ı arayabilirsiniz. Ne daha iyi?
İnsanlar her ikisini de eşit başarıyla kullanıyor. Bana öyle geliyor ki, otomatik ölçeklendirme grubundan bahsetmiyorsak, Ansible'daki dinamik envanter kullanışlı bir şey. Çünkü otomatik ölçeklendirme grubunda launch_configuration adı verilen kendi araç setimiz zaten var. launch_configuration'da yeni bir kaynak oluşturduğumuzda başlatılması gereken her şeyi kaydediyoruz. Bu nedenle Amazon'da dinamik envanter kullanmak ve Terraform ts dosyasını okumak bence aşırıdır. Ve "otomatik ölçeklendirme grubu" kavramının olmadığı başka araçlar kullanırsanız, örneğin, DigitalOcean'ı veya otomatik ölçeklendirme grubunun bulunmadığı başka bir sağlayıcıyı kullanırsanız, o zaman orada API'yi manuel olarak çekmeniz, IP adreslerini bulmanız, oluşturmanız gerekecektir. dinamik bir envanter dosyası ve Ansible zaten bu dosyanın içinde dolaşacak. Yani Amazon için launch_configuration var ve diğer her şey için dinamik envanter var.
Kaynak: habr.com