Görünüşe göre Terraform geliştiricileri AWS altyapısıyla çalışmak için oldukça uygun en iyi uygulamaları sunuyor. Sadece bir nüans var. Zamanla her biri kendine has özelliklere sahip olan ortamların sayısı artar. Uygulama yığınının neredeyse bir kopyası komşu bölgede görünür. Ve Terraform kodunun yeni gereksinimlere göre dikkatlice kopyalanması ve düzenlenmesi veya bir kar tanesi haline getirilmesi gerekiyor.
Büyük ve uzun projelerde kaosla ve manuel rutinle mücadele etmek için Terraform'daki kalıplar hakkındaki raporum.
Video:
40 yaşındayım, 20 yıldır bilişim sektöründeyim. 12 yıldır Ixtens'te çalışıyorum. E-ticaret odaklı geliştirmeyle ilgileniyoruz. Ve 5 yıldır DevOps uygulamalarını yapıyorum.
Hikayem, adını söylemeyeceğim bir şirkette gizlilik anlaşması arkasına saklanarak yürüttüğüm bir projede yaşadığım deneyimi anlatacak.
Projenin ölçeğinin anlaşılabilmesi için slayttaki rakamlar belirtilmiştir. Ve bundan sonra söyleyeceğim her şey Amazon ile ilgili.
Bu projeye 4 yıl önce katıldım. Proje büyüdüğü için altyapının yeniden düzenlenmesi tüm hızıyla sürüyordu. Ve kullanılan kalıplar artık uygun değildi. Ve projenin planlanan tüm büyümesi göz önüne alındığında, yeni bir şey bulmak gerekiyordu.
Dün bize Dodo Pizza'da olanları anlatan Matvey'e teşekkürler. 4 yıl önce burada olan da buydu.
Geliştiriciler gelip altyapı kodu yapmaya başladılar.
Bunun gerekli olmasının en belirgin nedeni pazara sunma zamanıydı. Devreye alma sırasında DevOps ekibinin bir darboğaz yaşamamasını sağlamak gerekiyordu. Ve diğer şeylerin yanı sıra Terraform ve Puppet ilk seviyede kullanıldı.
Terraform, HashiCorp'un açık kaynaklı bir projesidir. Ve bunun ne olduğunu bile bilmeyenler için sonraki birkaç slayt.
Kod olarak altyapı, altyapımızı tanımlayabileceğimiz ve bazı robotlardan tanımladığımız kaynakları aldığımızdan emin olmalarını isteyebileceğimiz anlamına gelir.
Örneğin bir sanal makineye ihtiyacımız var. Gerekli birkaç parametreyi tanımlayıp ekleyeceğiz.
Bundan sonra konsolda Amazon'a erişimi yapılandıracağız. Ve Terraform planını isteyeceğiz. Terraform planı şunu söyleyecektir: "Tamam, kaynağınız için bunları yapabiliriz." Ve en az bir kaynak eklenecektir. Ve hiçbir değişiklik beklenmiyor.
Her şeyden memnun kaldığınızda Terraform'a başvurmasını isteyebilirsiniz, Terraform sizin için bir örnek oluşturacak ve bulutunuzda bir sanal makine alacaksınız.
Ayrıca projemiz gelişiyor. Oraya bazı değişiklikler ekliyoruz. Daha fazla örnek istiyoruz, 53 giriş ekliyoruz.
Ve tekrarlıyoruz. Lütfen planlayın. Hangi değişikliklerin planlandığını görüyoruz. Başvuruyoruz. Altyapımız da bu şekilde büyüyor.
Terraform, durum dosyaları adı verilen bir şey kullanır. Yani, Amazon'a giden tüm değişiklikleri, tanımladığınız her kaynak için Amazon'da oluşturulmuş karşılık gelen kaynakların bulunduğu bir dosyaya kaydeder. Böylece bir kaynağın tanımı değiştiğinde Terraform, Amazon'da tam olarak neyin değiştirilmesi gerektiğini bilir.
Bu durum dosyaları başlangıçta yalnızca dosyalardı. Ve bunları Git'te saklıyorduk ki bu son derece elverişsiz bir durumdu. Birisi her zaman değişiklik yapmayı unuttu ve birçok çatışma ortaya çıktı.
Artık arka ucu kullanmak mümkün, yani Terraform, durum dosyasının hangi pakette ve hangi anahtarla kaydedileceği belirtilir. Ve Terraform'un kendisi bu durum dosyasını almakla, tüm sihri yapmakla ve nihai sonucu geri koymakla ilgilenecektir.
Altyapımız büyüyor. İşte kodumuz. Artık sadece sanal makine oluşturmak istemiyoruz, aynı zamanda bir test ortamına da sahip olmak istiyoruz.
Terraform, modül gibi bir şey oluşturmanıza, yani aynı şeyi bir klasörde tanımlamanıza olanak tanır.
Ve örneğin, test sırasında bu modülü çağırın ve sanki modülün kendisinde Terraform application'ı çalıştırmışız gibi aynı şeyi elde edin. Test için bu kod olacak.
Üretim için oraya bazı değişiklikler gönderebiliriz çünkü testlerde büyük örneklere ihtiyacımız yoktur; üretimde büyük örnekler yalnızca faydalıdır.
Daha sonra projeye geri döneceğim. Zor bir işti, planlanan altyapı çok büyüktü. Ve tüm kodu bir şekilde herkes için uygun olacak şekilde yerleştirmek gerekiyordu: hem bu kodun bakımını yapanlar hem de değişiklik yapanlar için. Ve herhangi bir geliştiricinin platformun kendi payına düşen kısmı için gereken altyapıyı düzeltebilmesi planlandı.
Bu, büyük bir projeniz varsa ve tüm altyapıyı küçük parçalara bölüp her parçayı ayrı bir klasörde açıklamak mantıklıysa, HashiCorp'un kendisi tarafından önerilen bir dizin ağacıdır.
Kapsamlı bir kaynak kütüphanesine sahip olarak, test ve üretimde yaklaşık olarak aynı şeyi arayabilirsiniz.
Bizim durumumuzda bu pek uygun değildi çünkü geliştiriciler veya testler için test yığınının bir şekilde daha basit bir şekilde elde edilmesi gerekiyordu. Ancak klasörleri tarayıp gerekli sırayla uygulayıp veritabanının yükselmesinden ve ardından bu veritabanını kullanan örneğin yükselmesinden endişe etmek istemedim. Bu nedenle tüm testler tek bir klasörden başlatıldı. Orada da aynı modüller çağrıldı, ancak her şey tek seferde yapıldı.
Terraform tüm bağımlılıklarla ilgilenir. Ve örneğin yeni oluşturulan bir örnekten bir IP adresi alabilmeniz ve bu IP adresini Route53 kaydında alabilmeniz için her zaman sırayla kaynaklar oluşturur.
Ayrıca platform oldukça büyük. Ve bir saatliğine de olsa, 8 saatliğine de olsa bir test yığınını başlatmak oldukça pahalı bir girişim.
Ve bu konuyu otomatikleştirdik. Ve Jenkins'in işi yığını çalıştırmamıza olanak sağladı. İçinde geliştiricinin test etmek istediği değişiklikleri içeren bir çekme isteği başlatmak, gerekli tüm seçenekleri, bileşenleri ve boyutları belirtmek gerekiyordu. Performans testi istiyorsa daha fazla örnek alabilir. Eğer bir formun açılıp açılmadığını kontrol etmesi gerekiyorsa asgari ücretle başlayabilir. Ayrıca bir kümenin gerekli olup olmadığını vb. belirtin.
Daha sonra Jenkins, Terraform klasöründeki kodu biraz değiştiren bir kabuk betiği gönderdi. Gereksiz dosyaları kaldırdım ve gerekli dosyaları ekledim. Ve ardından bir Terraform uygulaması çalıştırmasıyla yığın yükseltildi.
Ve sonra girmek istemediğim başka adımlar da vardı.
Test için üretimdekinden biraz daha fazla seçeneğe ihtiyaç duymamız nedeniyle, modüllerin kopyalarını oluşturmak zorunda kaldık, böylece bu kopyalara yalnızca test için gerekli olan özellikleri ekleyebilmemiz gerekiyordu.
Ve öyle oldu ki, testlerde sonunda üretime girecek değişiklikleri test etmek istiyorum. Ama aslında bir şey test edildi ve üretimde biraz farklı bir şey kullanıldı. Ve üretimdeki tüm değişikliklerin operasyon ekibi tarafından uygulandığı kalıpta küçük bir kopukluk vardı. Ve bazen testten üretime geçmesi gereken değişikliklerin başka bir versiyonda kaldığı ortaya çıktı.
Ayrıca öyle bir sorun vardı ki, mevcut hizmetlerden biraz farklı olan yeni bir hizmet eklendi. Ve mevcut bir modülü değiştirmek yerine, onun bir kopyasını alıp gerekli değişiklikleri eklememiz gerekiyordu.
Esasen Terraform gerçek bir dil değildir. Bu bir beyandır. Bir şeyi açıklamamız gerekiyorsa bunu beyan ederiz. Ve hepsi işe yarıyor.
Bir noktada çekme taleplerimden biri tartışılırken meslektaşlarımdan biri kar taneleri oluşturmaya gerek olmadığını söyledi. Ne demek istediğini merak ettim. Dünyada birbirinin aynısı iki kar tanesinin bulunmadığı, hepsinin biraz farklı olduğu bilimsel bir gerçektir. Ve bunu duyduğum anda Terraform kodunun tüm ağırlığını hissettim. Çünkü sürümden sürüme geçmek gerektiğinde Terraform zincir değişikliklerinin kırılmasını gerektiriyordu, yani kod artık bir sonraki sürümle uyumlu değildi. Ve altyapıyı Terraform'un bir sonraki sürümüne taşımak için altyapıdaki dosyaların neredeyse yarısını kapsayan bir çekme isteği yapmak zorunda kaldık.
Ve böyle bir kar tanesi ortaya çıktıktan sonra, büyük, çok büyük bir kar yığınına dönüştürdüğümüz tüm Terraform kodu.
Operasyonun dışında olan harici bir geliştirici için bu onun için pek önemli değil, çünkü çekme isteğinde bulundu, kaynağı başladı. Ve hepsi bu, artık onun endişesi değil. Ve her şeyin yolunda olduğundan emin olan DevOps ekibinin tüm bu değişiklikleri yapması gerekiyor. Ve bu değişikliklerin maliyeti, her ilave kar tanesiyle birlikte çok ama çok arttı.
Bir seminerdeki bir öğrencinin tahtaya tebeşirle iki mükemmel daire çizdiğine dair bir hikaye var. Ve öğretmen pusula olmadan nasıl bu kadar düzgün çizim yapabildiğine şaşırıyor. Öğrenci şöyle cevap verir: "Çok basit, iki yılımı askerde kıyma makinesi çevirerek geçirdim."
Bu projede yer aldığım dört yılın yaklaşık iki yıldır Terraform yapıyorum. Ve elbette, Terraform kodunu nasıl basitleştireceğinize, onunla bir programlama dili gibi nasıl çalışacağınıza ve bu kodu güncel tutması gereken geliştiricilerin yükünü nasıl azaltacağınıza dair bazı püf noktalarım, bazı tavsiyelerim var.
Başlamak istediğim ilk şey Sembolik Bağlantılar. Terraform'da çok fazla tekrarlanan kod var. Mesela altyapı oluşturduğumuz hemen her noktada sağlayıcıya yapılan çağrı aynı. Ve onu ayrı bir klasöre koymak mantıklıdır. Ve sağlayıcının bu dosyaya Symlinks yapması gereken her yerde.
Örneğin, üretimde bazı harici Amazon hesaplarına erişim hakları kazanmanıza olanak tanıyan üstlenme rolünü kullanırsınız. Ve bir dosyayı değiştirdikten sonra kaynak ağacında kalanların tümü gerekli haklara sahip olacak, böylece Terraform hangi Amazon segmentine erişeceğini bilecek.
Sembolik bağlantılar nerede başarısız oluyor? Dediğim gibi Terraform'un durum dosyaları var. Ve onlar çok çok havalılar. Ancak olay şu ki Terraform ilk etapta arka ucu başlatıyor. Ve bu parametrelerde herhangi bir değişken kullanamaz; bunların her zaman metin olarak yazılması gerekir.
Sonuç olarak, birisi yeni bir kaynak oluşturduğunda kodun bir kısmını diğer klasörlerden kopyalar. Anahtarla ya da kovayla da hata yapabilir. Örneğin, sandbox'tan bir sandbox şeyi yapıyor ve sonra onu üretimde yapıyor. Ve böylece üretimdeki kovanın kum havuzundan kullanılacağı ortaya çıkabilir. Elbette çabuk bulacaklar. Bunu bir şekilde düzeltmek mümkün olacak, ancak yine de bu zaman ve bir dereceye kadar kaynak kaybıdır.
Bundan sonra ne yapabiliriz? Terraform ile çalışmaya başlamadan önce onu başlatmanız gerekir. Başlatma sırasında Terraform tüm eklentileri indirir. Bir noktada monolitten daha mikro hizmet mimarisine geçtiler. Ve her zaman Terraform init yapmanız gerekir ki tüm modülleri, tüm eklentileri çekebilsin.
Ve öncelikle tüm değişkenleri alabilen bir kabuk betiği kullanabilirsiniz. Kabuk betiği hiçbir şekilde sınırlı değildir. İkincisi ise yollar. Durum dosyasının anahtarı olarak her zaman depodaki yolu kullanırsak, buna göre buradaki hata ortadan kaldırılacaktır.
Verileri nereden alabilirim? JSON dosyası. Terraform, altyapıyı yalnızca hcl (HashiCorp Yapılandırma Dili) değil, JSON'da da yazmanıza olanak tanır.
JSON'un kabuk betiğinden okunması kolaydır. Buna göre konfigürasyon dosyasını kovayla birlikte bir yere koyabilirsiniz. Ve bu kovayı hem Terraform kodunda hem de başlatma için kabuk komut dosyasında kullanın.
Terraform için bir kovaya sahip olmak neden önemlidir? Çünkü uzak durum dosyaları diye bir şey var. Yani, Amazon'a "Lütfen örneği yükseltin" demek için bir kaynak yükselttiğimde, gerekli birçok parametreyi belirtmem gerekiyor.
Ve bu tanımlayıcılar başka bir klasörde saklanır. Ben de gidip şunu söyleyebilirim: "Terraform, lütfen o kaynağın durum dosyasına git ve bana bu tanımlayıcıları getir." Böylece farklı bölgeler veya ortamlar arasında belli bir birlik ortaya çıkıyor.
Uzak durum dosyasını kullanmak her zaman mümkün değildir. Örneğin, elle bir VPC oluşturdunuz. Ve VPC'yi oluşturan Terraform kodu o kadar farklı VPC'ler yaratıyor ki, bu çok uzun zaman alacak ve birini diğerine ayarlamanız gerekecek, böylece aşağıdaki hileyi kullanabilirsiniz.
Yani, bir VPC yapıyormuş gibi görünen ve size tanımlayıcılar veren bir modül yapın, ancak aslında aynı örneği oluşturmak için kullanılabilecek sabit kodlanmış değerlere sahip bir dosya vardır.
Durum dosyasını buluta kaydetmek her zaman gerekli değildir. Örneğin, modülleri test ederken, dosyanın test sırasında kolayca diske kaydedileceği arka uç başlatmayı kullanabilirsiniz.
Şimdi biraz test hakkında. Terraform'da neyi test edebilirsiniz? Muhtemelen pek çok şey mümkün ama ben bu 4 şeyden bahsedeceğim.
HashiCorp, Terraform kodunun nasıl formatlanması gerektiğine dair bir anlayışa sahiptir. Ve Terraform fmt, düzenlediğiniz kodu bu inanışa göre formatlamanıza olanak tanır. Buna göre, testlerin mutlaka formatın HashiCorp'un miras bıraktığı şeye uygun olup olmadığını kontrol etmesi gerekir, böylece köşeli parantezlerin vs. konumunu değiştirmeye gerek kalmaz.
Bir sonraki adım Terraform doğrulamasıdır. Tüm parantezlerin eşleştirilmiş olup olmadığını sözdizimini kontrol etmekten biraz daha fazlasını yapar. Burada önemli olan ne? Altyapımız oldukça geniş. İçinde birçok farklı baba var. Ve her birinde Terraform validate'i çalıştırmanız gerekiyor.
Buna göre, testi hızlandırmak için paralel kullanarak birden fazla işlemi paralel olarak çalıştırıyoruz.
Paralellik çok güzel bir şey, kullanın onu.
Ancak Terraform her başlatıldığında HashiCorp'a gider ve şunu sorar: "En son eklenti sürümleri nelerdir? Peki önbellekteki eklenti doğru mu yoksa yanlış mı?” Ve bu her adımda yavaşladı.
Terraform'a eklentilerin nerede olduğunu söylerseniz Terraform şunu söyleyecektir: "Tamam, bu muhtemelen oradaki en son şey. Hiçbir yere gitmeyeceğim, hemen Terraform kodunuzu doğrulamaya başlayacağım.”
Klasörü gerekli eklentilerle doldurmak için, başlatılması gereken çok basit bir Terraform kodumuz var. Burada elbette kodunuza bir şekilde katılan tüm sağlayıcıları belirtmeniz gerekiyor, aksi takdirde Terraform şunu söyleyecektir: "Belirli bir sağlayıcıyı tanımıyorum çünkü önbellekte yok."
Sırada Terraform planı var. Dediğim gibi gelişim döngüseldir. Kodda değişiklik yapıyoruz. Daha sonra altyapı için hangi değişikliklerin planlandığını öğrenmeniz gerekiyor.
Altyapı çok çok büyük olduğunda, bir modülü değiştirebilir, bazı test ortamlarını veya belirli bir bölgeyi düzeltebilir ve komşu olanlardan bazılarını kırabilirsiniz. Bu nedenle Terraform planı tüm altyapı için yapılmalı ve hangi değişikliklerin planlandığını göstermelidir.
Bunu akıllıca yapabilirsiniz. Örneğin bağımlılıkları çözen bir Python betiği yazdık. Ve neyin değiştiğine bağlı olarak: Terraform modülü veya yalnızca belirli bir bileşen, tüm bağımlı klasörler için planlar yapar.
Talep üzerine terraform planları yapılmalıdır. En azından biz bunu yapıyoruz.
Elbette her değişiklik, her taahhüt için test yapmak iyidir, ancak planlar oldukça pahalı bir şeydir. Çekme isteğinde ise "Lütfen bana planları verin" deriz. Robot başlıyor. Ve değişikliklerinizden beklenen tüm planları yorum olarak gönderir veya ekler.
Plan oldukça pahalı bir şeydir. Bu zaman alıyor çünkü Terraform Amazon'a gidiyor ve şunu soruyor: "Bu örnek hala mevcut mu?" Bu otomatik ölçeklendirme tamamen aynı parametrelere sahip mi?” Bunu hızlandırmak için de yenileme=yanlış gibi bir parametre kullanabilirsiniz. Bu, Terraform'un durumu S3'ten indireceği anlamına gelir. Ve devletin Amazon'dakiyle tam olarak eşleşeceğine inanacak.
Böyle bir Terraform planı çok daha hızlı ilerler, ancak durumun altyapınıza uygun olması gerekir, yani bir yerde, bazen Terraform yenilemesinin başlaması gerekir. Terraform yenilemesi tam olarak bunu yapar: durum, gerçek altyapıdakiyle eşleşir.
Ve güvenlik hakkında konuşmamız gerekiyor. İşte başlamamız gereken yer burasıydı. Terraform'u çalıştırdığınız yerde ve Terraform altyapınızda çalıştığında bir güvenlik açığı var. Yani aslında kodu çalıştırıyorsunuz. Çekme isteği bir tür kötü amaçlı kod içeriyorsa, bu durumda çok fazla erişimi olan bir altyapı üzerinde yürütülebilir. Bu yüzden Terraform planını nerede çalıştırdığınıza dikkat edin.
Bahsetmek istediğim bir sonraki şey kullanıcı verileri testidir.
Kullanıcı verileri nedir? Amazon'da bir örnek oluşturduğumuzda, örnek meta verilerini içeren belirli bir mektubu gönderebiliriz. Bulut sunucusu başlatıldığında genellikle bu bulut sunucularında her zaman cloud init bulunur. Cloud init bu mektubu okur ve şöyle der: "Tamam, bugün yük dengeleyici benim." Ve bu antlaşmalara uygun olarak bazı eylemlerde bulunur.
Ancak ne yazık ki Terraform planını yaptığımızda ve Terraform uyguladığımızda kullanıcı verileri bu tür bir sayı yığını gibi görünüyor. Yani, size sadece hash'i gönderir. Planda görebileceğiniz tek şey, herhangi bir değişiklik olup olmayacağı veya karmanın aynı kalıp kalmayacağıdır.
Ve eğer buna dikkat etmezseniz, o zaman bazı bozuk metin dosyaları gerçek altyapıda Amazon'a düşebilir.
Alternatif olarak, yürütme sırasında altyapının tamamını değil, yalnızca şablonu belirtebilirsiniz. Ve kodda şunu söyleyin: "Lütfen bu şablonu ekranımda görüntüleyin." Sonuç olarak verilerinizin Amazon'da nasıl görüneceğine dair bir çıktı alabilirsiniz.
Başka bir seçenek de kullanıcı verilerini oluşturmak için bir modül kullanmaktır. Bu modülü uygulayacaksınız. Dosyayı diskte alırsınız. Referans olanla karşılaştırın. Ve böylece, eğer birisi kullanıcı verilerini biraz düzeltmeye karar verirse, testleriniz şunu söyleyecektir: "Tamam, orada burada bazı değişiklikler var - bu normal."
Bahsetmek istediğim bir sonraki konu ise Terraform uygulamasını otomatikleştirmek.
Elbette Terraform'un otomatik olarak uygulanması oldukça korkutucu çünkü orada ne gibi değişikliklerin geldiğini ve bunların yaşayan altyapı için ne kadar yıkıcı olabileceğini kim bilebilir?
Bir test ortamı için bunların hepsi normaldir. Yani test ortamı oluşturan bir iş tüm geliştiricilerin ihtiyacı olan şeydir. Ve "her şey benim için çalıştı" gibi bir ifade komik bir meme değil, bir kişinin kafasının karıştığının, bir yığını kaldırdığının ve bu yığın üzerinde bazı testler yaptığını kanıtlıyor. Orada her şeyin yolunda olduğundan emin oldu ve şöyle dedi: "Tamam, yayınlayacağım kod test edildi."
Üretim, sanal alan ve iş açısından daha kritik olan diğer ortamlarda, bazı kaynakları oldukça güvenli bir şekilde kısmen kullanabilirsiniz çünkü bu, kimsenin ölmesine neden olmaz. Bunlar: otomatik ölçeklendirme grupları, güvenlik grupları, roller, Route53 ve buradaki liste oldukça büyük olabilir. Ancak neler olup bittiğine dikkat edin, otomatik uygulama raporlarını okuyun.
Başvuru yapmanın tehlikeli veya korkutucu olduğu durumlarda, örneğin bunlar bir veritabanındaki bazı kalıcı kaynaklarsa, altyapının bir kısmında uygulanmamış değişiklikler olduğuna dair raporlar alın. Mühendis ise gözetim altında, uygulayacağı işleri başlatır veya konsolundan yapar.
Amazon'un korumayı sonlandır diye bir özelliği var. Ve bazı durumlarda sizin için gerekli olmayan değişikliklere karşı koruma sağlayabilir. Yani Terraform Amazon'a gitti ve şöyle dedi: "Başka bir örnek oluşturmak için bu örneği öldürmem gerekiyor." Ve Amazon şöyle diyor: “Üzgünüm, bugün değil. Sonlandırma korumamız var."
Ve pastanın kreması kod optimizasyonudur. Terraform koduyla çalıştığımızda modüle çok fazla sayıda parametre aktarmamız gerekiyor. Bunlar bir tür kaynak oluşturmak için gerekli olan parametrelerdir. Ve kod, özellikle modüller iç içe geçmişse, modülden modüle, modülden modüle aktarılması gereken geniş parametre listelerine dönüşür.
Ve okunması çok zor. Bunu gözden geçirmek çok zordur. Ve çoğu zaman bazı parametrelerin gözden geçirildiği ve bunların tam olarak ihtiyaç duyulan şey olmadığı ortaya çıkıyor. Ve bu daha sonra düzeltmek için zaman ve paraya mal olur.
Bu nedenle, belirli bir değerler ağacını içeren karmaşık bir parametre gibi bir şeyi kullanmanızı öneririm. Yani, bir ortamda sahip olmak istediğiniz tüm değerlerin bulunduğu bir tür klasöre ihtiyacınız var.
Ve bu modülü çağırarak, ortak bir modülde, yani tüm altyapı için aynı şekilde çalışan ortak bir modülde oluşturulan bir ağaç elde edebilirsiniz.
Bu modülde Terraform'un locals gibi yeni bir özelliğini kullanarak bazı hesaplamalar yapabilirsiniz. Ve sonra, tek bir çıktıyla, dizi karmalarını vb. içerebilecek bazı karmaşık parametreler verin.
Burası, en iyi buluntularımın bittiği yer. Ve Columbus hakkında bir hikaye anlatmak istiyorum. Hindistan'ı keşfetme seferi için para ararken (o zamanlar öyle düşünüyordu), kimse ona inanmadı ve bunun imkansız olduğunu düşündüler. Sonra dedi ki: “Yumurtanın düşmediğinden emin olun.” Bütün bankacılar, çok zengin ve muhtemelen akıllı insanlar, bir şekilde yumurtayı yerleştirmeye çalıştılar ama yumurta düşmeye devam etti. Sonra Columbus yumurtayı aldı ve biraz bastırdı. Kabuk buruştu ve yumurta hareketsiz kaldı. "Ah, bu çok kolay!" dediler. Ve Columbus şöyle cevap verdi: “Evet, çok basit. Hindistan'ı açtığımda herkes bu ticaret yolunu kullanacak."
Ve size az önce anlattığım şeyler muhtemelen oldukça basit ve önemsiz şeylerdir. Ve bunları öğrenip kullanmaya başladığınızda her şey sırayla gerçekleşir. Bu yüzden yararlanın. Ve eğer bunlar sizin için tamamen normal şeylerse, o zaman en azından yumurtayı düşmeyecek şekilde nasıl yerleştireceğinizi biliyorsunuz.
Toparlamak gerekirse:
- Kar tanelerinden kaçınmaya çalışın. Ve ne kadar az kar tanesi varsa, geniş altyapınızda herhangi bir değişiklik yapmak için o kadar az kaynağa ihtiyacınız olacak.
- Sürekli değişiklikler. Yani kodda bazı değişiklikler meydana geldiğinde altyapınızı mümkün olan en kısa sürede bu değişikliklere uygun hale getirmeniz gerekiyor. Birinin iki üç ay sonra Elasticsearch'e gelip Terraform planı yapması ve beklemediği bir sürü değişikliğin olması gibi bir durum olmamalı. Ve her şeyi tekrar düzene koymak çok zaman alır.
- Testler ve otomasyon. Kodunuz ne kadar çok test ve özellik ile kaplanırsa, her şeyi doğru yaptığınıza dair güveniniz o kadar artar. Ve otomatik teslimat güveninizi kat kat artıracaktır.
- Test ve üretim ortamlarının kodu hemen hemen aynı olmalıdır. Pratik olarak, çünkü üretim hala biraz farklı ve test ortamının ötesine geçecek bazı nüanslar hala olacak. Ancak yine de artı veya eksi bu sağlanabilir.
- Ve çok fazla Terraform kodunuz varsa ve bu kodu güncel tutmak çok zaman alıyorsa, onu yeniden düzenlemek ve iyi bir şekle sokmak için asla geç değildir.
- Değişmez altyapı. AMI teslimatı zamanında.
- Çok sayıda girişiniz olduğunda ve bunların tutarlı bir sırada olmasını istediğinizde Route53'ün yapısı.
- API oranı sınırlarına karşı mücadele. İşte tam bu sırada Amazon, "İşte bu kadar, daha fazla isteği kabul edemem, lütfen bekleyin" diyor. Ve ofisin yarısı altyapının kullanıma sunulmasını bekliyor.
- Örnekleri tespit edin. Amazon ucuz bir etkinlik değil ve noktalar oldukça fazla tasarruf etmenize olanak sağlıyor. Ve orada bununla ilgili bir raporun tamamını anlatabilirsiniz.
- Güvenlik ve IAM rolleri.
- Kayıp kaynakları ararken Amazone'da kaynağı bilinmeyen örneklere sahip olduğunuzda para yerler. Bulut sunucularının maliyeti aylık 100-150 ABD Doları olsa bile bu, yıllık 1 ABD Dolarından fazladır. Bu tür kaynakları bulmak karlı bir iştir.
- Ve ayrılmış örnekler.
Benim için hepsi bu. Terraform çok güzel, onu kullanıyorsunuz. Teşekkür ederim!
sorular
Rapor için teşekkürler! Durum dosyanız S3'te, ancak birkaç kişinin bu durum dosyasını alıp genişletmeye çalışması sorununu nasıl çözersiniz?
Öncelikle acelemiz yok. İkinci olarak, bir kod parçası üzerinde çalıştığımızı bildirdiğimiz bayraklar var. Yani altyapının çok büyük olmasına rağmen bu birilerinin sürekli bir şeyler kullandığı anlamına gelmiyor. Aktif bir aşama olduğunda bu bir sorundu; durum dosyalarını Git'te saklıyorduk. Bu önemliydi, aksi takdirde birisi bir durum dosyası hazırlayacaktı ve her şeyin devam etmesi için bunları manuel olarak bir araya getirmek zorunda kaldık. Şimdi böyle bir sorun yok. Genel olarak Terraform bu sorunu çözdü. Ve eğer bir şeyler sürekli değişiyorsa, o zaman söylediklerinizi engelleyen kilitleri kullanabilirsiniz.
Açık kaynak mı yoksa kurumsal mı kullanıyorsunuz?
Kurumsal değil, yani gidebileceğiniz ve ücretsiz olarak indirebileceğiniz her şey.
Benim adım Stanislav. Küçük bir ekleme yapmak istedim. Bir örneği yok edilemez hale getirmenize olanak tanıyan bir Amazon özelliğinden bahsettiniz. Bu aynı zamanda Terraform'un kendisinde de vardır; Life Second bloğunda değişiklik yasağını veya yıkım yasağını belirleyebilirsiniz.
Zaman sınırlıydı. İyi bir nokta.
Ayrıca iki şey sormak istedim. Öncelikle testlerden bahsettiniz. Herhangi bir test aracı kullandınız mı? Test Kitchen eklentisini duydum. Belki daha fazlası vardır. Bir de Yerel Değerler konusunu sormak istiyorum. Giriş Değişkenlerinden temel olarak nasıl farklıdırlar? Ve neden bir şeyi yalnızca Yerel Değerler aracılığıyla parametreleştiremiyorum? Bu konuyu çözmeye çalıştım ama bir şekilde kendim çözemedim.
Bu odanın dışında daha detaylı konuşabiliriz. Test araçlarımız tamamen kendi yapımımızdır. Orada test edilecek hiçbir şey yok. Genel olarak, otomatik testlerin altyapıyı bir yerden alması, iyi olup olmadığını kontrol etmesi ve ardından altyapınızın hala iyi durumda olduğunu bildiren bir raporla her şeyi yok etmesi seçenekleri vardır. Buna sahip değiliz çünkü test yığınları her gün çalıştırılıyor. Ve bu yeterli. Ve eğer bir şey kırılmaya başlarsa, biz onu başka bir yere kontrol etmeden kırılmaya başlayacaktır.
Yerel Değerler konusuna gelince sohbete oda dışında devam edelim.
Merhaba! Rapor için teşekkürler! Çok bilgilendirici. Altyapıyı tanımlamak için aynı türde birçok koda sahip olduğunuzu söylediniz. Bu kodu oluşturmayı düşündünüz mü?
Harika soru, teşekkürler! Mesele şu ki, kod olarak altyapıyı kullandığımızda, koda baktığımızı ve o kodun arkasında hangi altyapının yattığını anladığımızı varsayıyoruz. Eğer kod üretilecekse orada nasıl bir altyapı olacağını anlamak için hangi kodun üretileceğini hayal etmemiz gerekiyor. Ya kod üretiriz, onu taahhüt ederiz ve aslında aynı şey olur. Biz de yazdığımız yolu izledik, başardık. Artı jeneratörler biraz sonra onları yapmaya başladığımızda ortaya çıktı. Ve artık değişmek için çok geçti.
Jsonnet hakkında bir şey duydun mu?
Hayır.
Bakın bu çok güzel bir şey. Bunu uygulayabileceğiniz ve bir veri yapısı oluşturabileceğiniz belirli bir durum görüyorum.
Tıraş makinesiyle ilgili şakada olduğu gibi, jeneratörler onlara sahip olduğunuzda iyidir. Yani ilk başta yüz farklıdır ama sonra herkesin yüzü aynıdır. Jeneratörler çok iyi çalışıyor. Ama ne yazık ki yüzlerimiz biraz farklı. Bu bir sorundur.
Sadece bakmak. Teşekkür ederim!
Adım Maxim, Sberbank'lıyım. Terraform'u bir programlama dilinin eşdeğerine nasıl getirmeye çalıştığınızdan biraz bahsettiniz. Ansible'ı kullanmak daha kolay değil mi?
Bunlar çok farklı şeyler. Ansible'da kaynak oluşturabilirsiniz ve Puppet, Amazon'da kaynak oluşturabilir. Ancak Terraform tamamen keskinleştirildi.
Yalnızca Amazon'unuz mu var?
Sadece Amazon'a sahip olduğumuzdan değil. Neredeyse sadece Amazon'umuz var. Ancak temel özellik Terraform'un hatırlamasıdır. Ansible'da, "Bana 5 örnek ver" derseniz yükselecektir ve sonra "Ve şimdi 3 örnek istiyorum" dersiniz. Ve Terraform şöyle diyecek: "Tamam, 2 tane öldüreceğim" ve Ansible şöyle diyecek: "Tamam, işte sana 3 tane." Toplam 8.
Merhaba! Raporunuz için teşekkürler! Terraform'u duymak çok ilginçti. Terraform'un hala kararlı bir sürümü olmadığı konusunda hemen küçük bir yorum yapmak istiyorum, bu nedenle Terraform'a çok dikkatli davranın.
Akşam yemeği için iyi bir kaşık. Yani, bir çözüme ihtiyacınız varsa, bazen dengesiz olanı vb. Ertelersiniz, ancak işe yarar ve bize yardımcı oldu.
Soru şudur. Uzak arka ucu kullanıyorsunuz, S 3'ü kullanıyorsunuz. Neden resmi arka ucu kullanmıyorsunuz?
Resmi?
Terraform Bulutu.
Ne zaman ortaya çıktı?
Yaklaşık 4 ay önce.
Eğer 4 yıl önce ortaya çıksaydı muhtemelen sorunuza cevap verirdim.
Zaten yerleşik bir işlev ve kilitler var ve bir durum dosyasını saklayabilirsiniz. Bir şans ver. Ama ben de test etmedim.
Yüksek hızda hareket eden büyük bir trende seyahat ediyoruz. Ve birkaç arabayı alıp çöpe atamazsınız.
Kar tanelerinden bahsettin, neden dal kullanmadın? Neden işler bu şekilde yürümedi?
Yaklaşımımız tüm altyapının tek bir depoda olmasıdır. Terraform, Puppet, bununla bir şekilde ilgili olan tüm scriptler, hepsi tek bir depoda. Bu şekilde artımlı değişikliklerin birbiri ardına test edilmesini sağlayabiliriz. Bir grup dal olsaydı, böyle bir projenin sürdürülmesi neredeyse imkansız olurdu. Altı ay geçti ve o kadar farklılaştılar ki bu sadece bir çeşit cezaydı. Yeniden düzenlemeden önce kaçmak istediğim şey buydu.
Yani çalışmıyor mu?
Bu hiç işe yaramıyor.
Şubede klasör slaytını kestim. Yani bunu her test yığını için yaparsanız, örneğin A takımının kendi klasörü var, B takımının kendi klasörü var, o zaman bu da işe yaramıyor. Herkese uyacak kadar esnek olan birleşik bir test ortamı kodu oluşturduk. Yani tek bir kod sunduk.
Merhaba! Benim adım Yura! Rapor için teşekkürler! Modüller hakkında soru. Modül kullandığınızı söylüyorsunuz. Bir modülde başka bir kişinin yaptığı değişiklikle uyumlu olmayan değişiklikler yapılmışsa sorunu nasıl çözersiniz? Bir şekilde modüllerin versiyonlarını mı oluşturuyorsunuz yoksa iki gereksinimi karşılamak için bir wunderwaffle mı getirmeye çalışıyorsunuz?
Bu büyük bir kar yığını sorunudur. Zararsız bir değişiklik altyapının bir kısmını bozabildiğinde yaşadığımız sıkıntı budur. Ve bu ancak uzun bir süre sonra fark edilecektir.
Yani henüz çözülmedi mi?
Evrensel modüller yapıyorsunuz. Kar tanelerinden kaçının. Ve her şey yoluna girecek. Raporun ikinci yarısı bunun nasıl önlenebileceğiyle ilgili.
Merhaba! Rapor için teşekkürler! Netleştirmek istiyorum. Perde arkasında almaya geldiğim büyük bir yığın vardı. Kukla ve rol dağılımı nasıl entegre edilir?
Kullanıcı bilgisi.
Yani, dosyayı tükürüp bir şekilde yürütüyor musunuz?
Kullanıcı verileri bir nottur, yani görüntünün bir klonunu oluşturduğumuzda Daemon orada yükselir ve kim olduğunu anlamaya çalışırken yük dengeleyici olduğuna dair notu okur.
Yani bu, başkalarına verilen bir tür ayrı süreç mi?
Bunu biz icat etmedik. Biz onu kullanıyoruz.
Merhaba! Kullanıcı verileriyle ilgili bir sorum var. Orada sorunlar olduğunu, birisinin bir şeyi yanlış yere gönderebileceğini söylediniz. Kullanıcı verilerini aynı Git'te saklamanın bir yolu var mı, böylece Kullanıcı verilerinin ne anlama geldiğinin her zaman açık olması sağlanır mı?
Şablondan Kullanıcı verilerini üretiyoruz. Yani orada belli sayıda değişken kullanılıyor. Ve Terraform nihai sonucu üretir. Dolayısıyla sadece şablona bakıp ne olacak diyemezsiniz çünkü tüm problemler geliştiricinin bu değişkende bir string geçirdiğini düşünmesinden fakat orada bir dizi kullanılmasından kaynaklanıyor. Ve o - bam ve ben - filanca, filanca, bir sonraki satırda ve her şey bozuldu. Bu yeni bir kaynaksa ve kişi onu alır ve bir şeyin işe yaramadığını görürse, o zaman sorun hızla çözülür. Ve eğer bu otomatik ölçeklendirme grubu güncellenirse, bir noktada otomatik ölçeklendirme grubundaki örnekler değiştirilmeye başlar. Ve kahretsin, bir şeyler yolunda gitmiyor. Acıtıyor.
Tek çözümün test etmek olduğu ortaya çıktı?
Evet sorunu görüyorsunuz, oraya test adımlarını ekliyorsunuz. Yani çıktı da test edilebilir. Belki o kadar kullanışlı olmayabilir, ancak bazı işaretler de koyabilirsiniz; Kullanıcı verilerinin buraya çivilenmiş olup olmadığını kontrol edin.
Benim adım Timur. Terraform'un nasıl düzgün bir şekilde organize edileceğine dair raporların olması çok güzel.
Daha başlamadım bile.
Belki bir sonraki konferansta da olacağını düşünüyorum. Basit bir sorum var. Neden değeri tfvars kullanmak yerine ayrı bir modüle kodluyorsunuz, yani neden değerleri olan bir modül tfvars'tan daha iyidir?
Yani buraya yazmalı mıyım (slayt: Production/environment/settings.tf): domain = değişken, domain vpcnetwork, değişken vpcnetwork ve stvars – aynı şeyi alabilir miyim?
Biz de tam olarak bunu yapıyoruz. Örneğin ayar kaynağı modülüne atıfta bulunuyoruz.
Esasen, bu böyle bir tfvars. Tfvars test ortamında çok kullanışlıdır. Küçük örnekler için büyük örnekler için tfvar'larım var. Ve klasöre bir dosya attım. Ve istediğimi aldım. Altyapıyı keserken her şeye bakıp anında anlamanın mümkün olmasını istiyoruz. Ve böylece buraya bakmanız ve ardından tfvars'a bakmanız gerektiği ortaya çıktı.
Her şeyin tek bir yerde olması mümkün mü?
Evet, tfvars tek kodunuz olduğu zamandır. Ve farklı nüanslarla birçok farklı yerde kullanılıyor. Sonra tfvar'ları atar ve nüanslarınızı alırsınız. Biz de kod olarak en saf haliyle altyapıyız. Baktım ve anladım.
Merhaba! Bulut sağlayıcının Terraform'u yaptığınız şeye müdahale ettiği durumlarla karşılaştınız mı? Diyelim ki meta verileri düzenledik. Ssh anahtarları var. Ve Google sürekli olarak meta verilerini ve anahtarlarını oraya koyar. Ve Terraform her zaman değişikliklerin olduğunu yazıyor. Her çalıştırmadan sonra hiçbir şey değişmese bile artık bu alanı güncelleyeceğini söylüyor.
Anahtarlarla birlikte evet, altyapının bir kısmı bundan etkileniyor, yani Terraform hiçbir şeyi değiştiremez. Elimizle de hiçbir şeyi değiştiremeyiz. Şimdilik bununla yaşayacağız.
Yani böyle bir şeyle karşılaştınız ama aklınıza bir şey gelmedi, bunu nasıl yapıyor ve kendisi yapıyor?
Maalesef evet.
Merhaba! Benim adım Starkov Stanislav. Posta. ru Grubu. Etiket oluşturma problemini nasıl çözersiniz..., onu içeriye nasıl aktarırsınız? Anladığım kadarıyla, ana bilgisayar adını belirtmek için Kullanıcı verileri aracılığıyla Puppet'ı açık hale getirelim mi? Ve sorunun ikinci kısmı. SG'de bu sorunu nasıl çözersiniz, yani SG'yi aynı türden yüzlerce örnek oluşturduğunuzda, bunlar için doğru ad nedir?
Bizim için çok önemli olan örnekleri güzelce adlandırıyoruz. İhtiyaç duyulmayanlar için bunun bir otomatik ölçeklendirme grubu olduğuna dair bir not vardır. Ve teoride onu çivileyip yenisini alabilirsiniz.
Etiket sorununa gelince, böyle bir sorun yok ama böyle bir görev var. Altyapı büyük ve pahalı olduğu için etiketleri çok ama çok yoğun bir şekilde kullanıyoruz. Paranın nereye gittiğine de bakmamız gerekiyor, böylece etiketler neyin nereye gittiğini ayrıntılı olarak anlamamızı sağlar. Ve buna göre burada çok para anlamına gelen bir şeyin arayışı harcanıyor.
Soru başka neyle ilgiliydi?
SG yüzlerce örnek oluşturduğunda bunların bir şekilde ayırt edilmesi gerekiyor mu?
Hayır, yapma. Her durumda bir sorunum olduğunu bildiren bir temsilci var. Bir temsilci rapor verirse, temsilci onun hakkında bilgi sahibidir ve en azından IP adresi mevcuttur. Zaten kaçabilirsin. İkinci olarak Kubernetes'in olmadığı Consul for Discovery'yi kullanıyoruz. Consul ayrıca örneğin IP adresini de gösterir.
Yani, ana bilgisayar adına değil, özellikle IP'ye mi odaklanıyorsunuz?
Ana bilgisayar adına göre gezinmek imkansızdır, yani. birçoğu var. Örnek tanımlayıcılar var - AE vb. Bir yerde bulabilirsin, aramaya atabilirsin.
Merhaba! Terraform'un bulutlar için tasarlanmış iyi bir şey olduğunu fark ettim.
Sadece değil
Beni ilgilendiren soru tam olarak bu. Diyelim ki tüm örneklerinizle toplu olarak Bare Metal'e geçmeye karar verirseniz? Herhangi bir sorun olacak mı? Yoksa yine de başka ürünleri, örneğin burada bahsedilen Ansible'ı mı kullanmak zorunda kalacaksınız?
Ansible biraz başka bir şeyle ilgili. Yani Ansible, örnek başlatıldığında zaten çalışıyor. Ve Terraform, örnek başlamadan önce çalışır. Bare Metal'e geçiş - hayır.
Şimdi değil ama iş dünyası gelip “Haydi” diyecek.
Başka bir buluta geçmek – evet ama burada biraz farklı bir numara var. Terraform kodunu başka bir buluta daha az çaba harcayarak geçebilecek şekilde yazmanız gerekiyor.
Başlangıçta görev, tüm altyapımızın agnostik olması, yani herhangi bir bulutun uygun olması gerektiği şeklinde belirlendi, ancak bir noktada iş pes etti ve şöyle dedi: “Tamam, önümüzdeki N yıl içinde hiçbir yere gitmeyeceğiz, hizmetleri kullanabiliriz Amazon'dan"
Terraform, Ön Uç işleri oluşturmanıza, PagerDuty'yi, veri belgesini vb. yapılandırmanıza olanak tanır. Çok sayıda kuyruğu vardır. Neredeyse tüm dünyayı kontrol edebiliyor.
Rapor için teşekkürler! Ben de 4 yıldır Terraform kullanıyorum. Terraform'a, altyapıya, bildirimsel tanımlamaya sorunsuz geçiş aşamasında, birisinin elle bir şeyler yaptığı, sizin ise plan yapmaya çalıştığınız bir durumla karşı karşıya kaldık. Ve orada bir tür hatayla karşılaştım. Bu tür sorunlarla nasıl başa çıkıyorsunuz? Listelenen kayıp kaynakları nasıl bulursunuz?
Çoğunlukla ellerimiz ve gözlerimizle, raporda tuhaf bir şey görürsek orada olanları analiz ederiz veya basitçe öldürürüz. Genel olarak çekme istekleri yaygın bir şeydir.
Hata varsa geri alma işlemi yapılıyor mu? Bunu yapmayı denedin mi?
Hayır, bu kişinin bir sorun gördüğü anda vereceği karardır.
Kaynak: habr.com