Terraform'dan CloudFormation'a geçtim ve pişman oldum

Altyapıyı tekrarlanabilir metin biçimindeki kod olarak temsil etmek, farelerle uğraşmayı gerektirmeyen sistemler için basit bir en iyi uygulamadır. Bu uygulamanın bir adı var: Kod Olarak Altyapıve şu ana kadar bunu uygulamak için özellikle AWS'de iki popüler araç var: Terraform и BulutFormasyonu.

Terraform'dan CloudFormation'a geçtim ve pişman oldum
Terraform ve CloudFormation ile deneyimlerin karşılaştırılması

Kendine gelmeden önce Twitch (Aka Amazon Jr.) Çalıştım tek bir başlangıçta Terraform'u üç yıl boyunca kullandım. Yeni yerimde Terraform'u da tüm gücümle kullandım ve ardından şirket, CloudFormation da dahil olmak üzere Amazon'daki her şeye geçişi zorladı. Her ikisi için de özenle en iyi uygulamaları geliştirdim ve her iki aracı da çok karmaşık, kuruluş çapındaki iş akışlarında kullandım. Daha sonra Terraform'dan CloudFormation'a geçişin sonuçlarını dikkatle değerlendirdikten sonra Terraform'un kuruluş için muhtemelen en iyi seçim olduğuna ikna oldum.

Dünya Biçimi Korkunç

Beta yazılım

Terraform henüz 1.0 sürümünü yayınlamadı, bu da onu kullanmamak için iyi bir neden. İlk kez kendim denediğimden beri çok değişti, ama o zamanlar terraform apply genellikle birkaç güncellemeden sonra veya birkaç yıllık kullanımdan sonra bozulur. "Artık her şey farklı" derdim ama... sanki herkes bunu söylüyor, değil mi? Her ne kadar uygun olsalar da önceki sürümlerle uyumlu olmayan değişiklikler var ve hatta kaynak depolarının söz dizimi ve soyutlamalarına artık ihtiyacımız varmış gibi geliyor. Enstrüman gerçekten iyileşmiş gibi görünüyor, ama... :-0

Öte yandan AWS, geriye dönük uyumluluğu koruyarak iyi bir iş çıkardı. Bunun nedeni muhtemelen hizmetlerinin genellikle kuruluş içinde kapsamlı bir şekilde test edilmesi ve ancak bundan sonra yeniden adlandırılarak yayınlanmasıdır. Yani "çok çabaladılar" ifadesi yetersiz kalıyor. AWS kadar çeşitli ve karmaşık bir sistem için API'lerle geriye dönük uyumluluğu sürdürmek inanılmaz derecede zordur. Bu kadar yaygın olarak kullanılan halka açık API'lerin bakımını yapmak zorunda kalan herkes, bunu uzun yıllar boyunca yapmanın ne kadar zor olduğunu anlamalıdır. Ancak benim hafızamda CloudFormation'ın davranışı yıllar içinde hiç değişmedi.

Bacakla buluş... bu bir kurşun

Bildiğim kadarıyla kaynağı sil yabancı CF yığınınızdan CloudFormation yığını mümkün değildir. Aynı şey Terraform'da da geçerli. Mevcut kaynakları yığınınıza aktarmanıza olanak tanır. İşlevin muhteşem olduğu söylenebilir ancak büyük güç, büyük sorumluluğu da beraberinde getirir. Yığına bir kaynak eklemeniz yeterlidir ve yığınınızla çalışırken bu kaynağı silemez veya değiştiremezsiniz. Bir gün ters tepti. Bir gün Twitch'te birisi herhangi bir yaramazlık yapmamışken yanlışlıkla başka birinin AWS güvenlik grubunu kendi Terraform yığınına aktardı. Birkaç komut girdim ve... güvenlik grubu (gelen trafikle birlikte) ortadan kayboldu.

Terraform Harika

Tamamlanmamış durumlardan kurtarma

Bazen CloudFormation bir durumdan diğerine tamamen geçiş yapamıyor. Aynı zamanda bir öncekine dönmeye çalışacaktır. Bunun her zaman mümkün olmaması üzücü. Daha sonra olanların hatalarını ayıklamak oldukça korkutucu olabilir - CloudFormation'un saldırıya uğramasından memnun olup olmayacağını asla bilemezsiniz - sadece düzeltmek için bile. Önceki duruma dönmenin mümkün olup olmayacağını gerçekten nasıl belirleyeceğini bilmiyor ve varsayılan olarak saatlerce bir mucize bekleyerek asılı kalıyor.

Öte yandan Terraform, başarısız geçişlerden çok daha iyi bir şekilde kurtulma eğilimindedir ve gelişmiş hata ayıklama araçları sunar.

Belge durumunda daha net değişiklikler

“Tamam yük dengeleyici, değişiyorsun. Ama nasıl?"

— "kabul et" düğmesine basmaya hazır endişeli mühendis.

Bazen CloudFormation yığınındaki yük dengeleyiciyle bağlantı noktası numarası eklemek veya güvenlik grubunu değiştirmek gibi bazı değişiklikler yapmam gerekiyor. ClouFormation değişiklikleri kötü bir şekilde gösteriyor. Gerekli hiçbir şeyi silmediğimden ve gereksiz bir şey eklemediğimden emin olmak için yaml dosyasını on kez kontrol ediyorum.

Terraform bu konuda çok daha şeffaf. Bazen çok şeffaftır (okuyun: sinir bozucu). Neyse ki, en son sürüm, değişikliklerin daha iyi görüntülenmesini içerir; böylece artık tam olarak neyin değiştiğini görebilirsiniz.

Esneklik

Yazılımı tersten yazın.

Açıkça söylemek gerekirse uzun ömürlü yazılımların en önemli özelliği değişime uyum sağlayabilmektir. Herhangi bir yazılımı tersten yazın. Çoğu zaman "basit" bir hizmet alarak ve ardından her şeyi tek bir CloudFormation veya Terraform yığınına sıkıştırmaya başlayarak hatalar yaptım. Ve elbette aylar sonra her şeyi yanlış anladığım ve hizmetin aslında basit olmadığı ortaya çıktı! Ve şimdi bir şekilde büyük bir yığını küçük bileşenlere ayırmam gerekiyor. CloudFormation ile çalıştığınızda, bu yalnızca ilk önce mevcut yığının yeniden oluşturulmasıyla yapılabilir, ancak bunu veritabanlarımla yapmıyorum. Terraform ise yığının parçalara ayrılarak daha anlaşılır küçük parçalara bölünmesini mümkün kıldı.

Git'teki modüller

Terraform kodunu birden fazla yığında paylaşmak, CloudFormation kodunu paylaşmaktan çok daha kolaydır. Terraform ile kodunuzu bir git deposuna koyabilir ve anlamsal sürüm kontrolünü kullanarak ona erişebilirsiniz. Bu depoya erişimi olan herkes paylaşılan kodu yeniden kullanabilir. CloudFormation'ın eşdeğeri S3'tür, ancak aynı faydalara sahip değildir ve git'ten vazgeçerek S3'ü tercih etmemiz için hiçbir neden yoktur.

Organizasyon büyüdü ve ortak yığınları paylaşma yeteneği kritik seviyeye ulaştı. Terraform tüm bunları kolay ve doğal hale getirirken CloudFormation, böyle bir şeyi çalıştırmadan önce engellerin üzerinden geçmenizi sağlayacaktır.

Kod olarak işlemler

"Hadi senaryoyu yazalım ve tamam."

— Terraform bisikletini icat etmeden 3 yıl önce bir mühendis.

Yazılım geliştirme söz konusu olduğunda Go veya Java programı sadece koddan ibaret değildir.

Terraform'dan CloudFormation'a geçtim ve pişman oldum
Kod Olarak Kod

Üzerinde çalıştığı altyapı da var.

Terraform'dan CloudFormation'a geçtim ve pişman oldum
Kod Olarak Altyapı

Peki o nereli? Nasıl izlenir? Kodunuz nerede yaşıyor? Geliştiricilerin erişim iznine ihtiyacı var mı?

Terraform'dan CloudFormation'a geçtim ve pişman oldum
Kod Olarak İşlemler

Yazılımcı olmak sadece kod yazmak anlamına gelmiyor.

AWS tek değil: muhtemelen başka sağlayıcılar kullanıyorsunuz. SignalFx, PagerDuty veya Github. Belki CI/CD için dahili bir Jenkins sunucunuz veya izleme için dahili bir Grafana kontrol paneliniz vardır. Infra as Code farklı nedenlerle seçilir ve her biri yazılımla ilgili her şey için eşit derecede önemlidir.

Twitch'te çalışırken Amazon'un karma yerleşik ve AWS sistemleri içindeki hizmetleri hızlandırdık. Operasyonel maliyetleri artırarak birçok mikro hizmeti seri olarak ürettik ve destekledik. Tartışmalar şöyle gelişti:

  • Я: Lanet olsun, bir mikro hizmette hız aşırtma yapmak için bu kadar çok hareket gerekiyor. Bir AWS hesabı oluşturmak için bu çöpü kullanmam gerekecek (2 hesaba gittik) mikro hizmet), sonra bu uyarıları ayarlamak için, bu bir kod deposu için ve bu bir e-posta listesi için ve sonra bu...
  • Yol göstermek: Hadi senaryoyu yazalım ve tamam.
  • Я: Tamam ama senaryonun kendisi değişecek. Tüm bu yerleşik Amazon aygıtlarının güncel olup olmadığını kontrol etmenin bir yoluna ihtiyacımız olacak.
  • Yol göstermek: Kulağa iyi geliyor. Ve bunun için bir senaryo yazacağız.
  • Я: Harika! Ve betiğin muhtemelen hala parametreleri ayarlaması gerekecek. Bunları kabul edecek mi?
  • Yol göstermek: Gittiği yere götürsün!
  • Я: Süreç değişebilir ve geriye dönük uyumluluk kaybolabilir. Bir tür anlamsal sürüm kontrolü gerekli olacaktır.
  • Yol göstermek: İyi fikir!
  • Я: Araçlar kullanıcı arayüzünden manuel olarak değiştirilebilir. Bunu kontrol edip düzeltmenin bir yoluna ihtiyacımız olacak.

…3 yıl sonra:

  • Yol göstermek: Ve terraform'umuz var.

Hikayeden alınacak ders şudur: Amazon'daki her şeyde sırılsıklam, hâlâ AWS'ye ait olmayan bir şey kullanıyorsunuz ve bu hizmetlerin, bu durumu senkronize tutmak için bir yapılandırma dili kullanan bir durumu var.

CloudFormation lambda vs git modülleri terraform

lambda, CloudFormation'un özel mantık sorununa çözümüdür. Lambda ile şunları yapabilirsiniz makrolar oluştur veya kullanıcı kaynağı. Bu yaklaşım, Terraform'un git modüllerinin semantik versiyonunda mevcut olmayan ek karmaşıklıkları ortaya çıkarır. Benim için en acil sorun, tüm bu kullanıcı lambdalarına (ve bunlar düzinelerce AWS hesabına) ilişkin izinleri yönetmekti. Bir diğer önemli sorun da “önce ne gelir, tavuk mu yumurta mı?” problemiydi: Lambda koduyla ilgiliydi. Bu işlevin kendisi bir altyapı ve koddur ve kendisinin de izlenmesi ve güncellenmesi gerekir. Tabuttaki son çivi, lambda kodu değişikliklerini anlamsal olarak güncellemenin zorluğuydu; ayrıca doğrudan komut olmadan yapılan yığın eylemlerinin çalıştırmalar arasında değişmediğinden emin olmamız gerekiyordu.

Bir keresinde, klasik bir yük dengeleyiciyle Elastic Beanstalk ortamı için bir kanarya dağıtımı oluşturmak istediğimi hatırlıyorum. Yapılacak en kolay şey, EB için üretim ortamının yanında ikinci bir dağıtım yapmak ve bunu bir adım daha ileri taşımaktır: otomatik ölçeklendirme kanarya dağıtım grubunu üretim ortamına dağıtım LB ile birleştirmek. Ve Terraform kullandığından beri Sonuç olarak ASG konuşması, bu Terraform'da fazladan 4 satır kod gerektirecektir. CloudFormation'da benzer bir çözüm olup olmadığını sorduğumda, beni bir dağıtım hattı ve her şeyi içeren tam bir git deposuna yönlendirdiler; bunların hepsi, 4 satırlık zayıf Terraform kodunun yapabileceği bir şey uğruna.

Kaymayı daha iyi algılar

Gerçekliğin beklentilerle eşleştiğinden emin olun.

Sürüklenme tespiti kod özelliği olarak çok güçlü bir işlemdir çünkü gerçekliğin beklentilerle eşleşmesini sağlamaya yardımcı olur. Hem CloudFormation hem de Terraform ile kullanılabilir. Ancak üretim yığını büyüdükçe CloudFormation'da sürüklenme arayışı giderek daha fazla yanlış tespite yol açtı.

Terraform ile sürüklenme tespiti için çok daha gelişmiş yaşam döngüsü kancalarına sahip olursunuz. Örneğin şu komutu giriyorsunuz: görmezden_değişiklikler ECS dağıtımınızın tamamındaki değişiklikleri göz ardı etmeden belirli bir görev tanımındaki değişiklikleri yoksaymak istiyorsanız doğrudan ECS görev tanımında.

CDK ve CloudFormation'un geleceği

CloudFormation'un büyük, altyapılar arası ölçeklerde yönetilmesi zordur. Bu zorlukların çoğu kabul edilmektedir ve aracın aşağıdaki gibi şeylere ihtiyacı vardır: aws-cdk, bulut altyapısını kodda tanımlamaya ve onu AWS CloudFormation aracılığıyla çalıştırmaya yönelik bir çerçeve. Aws-cdk'nin gelecekte neler getireceğini görmek ilginç olacak ancak Terraform'un diğer güçlü yönleriyle rekabet etmekte zorlanacak; CloudFormation'ı güncel hale getirmek için küresel değişiklikler gerekli olacaktır.

Terraform'un hayal kırıklığı yaratmaması için

Bu, “metin olarak” değil, “kod olarak altyapıdır”.

Terraform'la ilgili ilk izlenimim oldukça kötüydü. Sanırım yaklaşımı anlamadım. Neredeyse tüm mühendisler istemeden bunu istenilen altyapıya dönüştürülmesi gereken bir metin formatı olarak algılıyorlar. BU ŞEKİLDE YAPMAYIN.

İyi yazılım geliştirmenin gerçekleri Terraform için de geçerlidir.

İyi kod oluşturmak için benimsenen birçok uygulamanın Terraform'da göz ardı edildiğini gördüm. Yıllarca iyi bir programcı olmak için çalıştınız. Terraform ile çalışıyorsunuz diye bu deneyimden vazgeçmeyin. İyi yazılım geliştirmenin gerçekleri Terraform için de geçerlidir.

Kod nasıl belgelenemez?

Kesinlikle hiçbir belgeye sahip olmayan devasa Terraform yığınları gördüm. Hiçbir belge olmadan sayfalar halinde nasıl kod yazabilirsiniz? Açıklamanızı açıklayan belgeleri ekleyin kod Terraform ("kod" kelimesine vurgu yapın), bu bölümün neden bu kadar önemli olduğunu ve ne yaptığınızı öğrenin.

Bir zamanlar büyük bir main() işlevi olan hizmetleri nasıl dağıtabiliriz?

Tek bir modül olarak sunulan çok karmaşık Terraform yığınlarını gördüm. Yazılımı neden bu şekilde dağıtmıyoruz? Neden büyük fonksiyonları daha küçük fonksiyonlara ayırıyoruz? Aynı cevaplar Terraform için de geçerlidir. Modülünüz çok büyükse onu daha küçük modüllere ayırmanız gerekir.

Şirketiniz kütüphane kullanmıyor mu?

Terraform'u kullanarak yeni bir proje geliştiren mühendislerin, diğer projelerden büyük parçaları aptalca kopyalayıp kendi projelerine nasıl yapıştırdıklarını ve sonra çalışmaya başlayana kadar onlarla nasıl uğraştıklarını gördüm. Şirketinizde “mücadele” koduyla böyle çalışır mıydınız? Sadece kütüphaneleri kullanmıyoruz. Evet, Her şeyin bir kütüphane olması gerekmiyor, ama prensipte ortak kütüphaneler olmadan neredeyiz?!

PEP8 veya gofmt kullanmıyor musun?

Çoğu dilin standart, kabul edilmiş bir biçimlendirme şeması vardır. Python'da bu PEP8'dir. Go'da - gofmt. Terraform'un kendine has özellikleri var: terraform fmt. Sağlığınız için tadını çıkarın!

React'ı JavaScript bilmeden mi kullanacaksınız?

Terraform modülleri, oluşturduğunuz karmaşık altyapının bir kısmını basitleştirebilir, ancak bu, onunla hiçbir şekilde ilgilenemeyeceğiniz anlamına gelmez. Kaynakları anlamadan Terraform'u doğru kullanmak mı istiyorsunuz? Ölüme mahkumsun: zaman geçecek ve asla Terraform'da usta olamayacaksın.

Singleton'larla mı yoksa bağımlılık enjeksiyonuyla mı kodlıyorsunuz?

Bağımlılık enjeksiyonu, yazılım geliştirme için tanınmış bir en iyi uygulamadır ve tekil uygulamalara tercih edilir. Bu Terraform'da nasıl faydalıdır? Uzak duruma bağlı Terraform modüllerini gördüm. Uzak durumu alan modüller yazmak yerine parametre alan bir modül yazın. Daha sonra bu parametreleri modüle aktarın.

Kütüphaneleriniz on şeyi iyi mi yapıyor yoksa bir şeyi harika mı yapıyor?

En iyi çalışan kütüphaneler, çok iyi yaptıkları tek bir göreve odaklananlardır. Her şeyi aynı anda yapmaya çalışan büyük Terraform modülleri yazmak yerine, bunların tek bir şeyi iyi yapan parçalarını oluşturun. Daha sonra bunları gerektiği gibi birleştirin.

Geriye dönük uyumluluk olmadan kitaplıklarda nasıl değişiklik yaparsınız?

Normal bir kütüphane gibi ortak bir Terraform modülünün, geriye dönük olarak uyumlu olmadan değişiklikleri bir şekilde kullanıcılara iletmesi gerekir. Bu değişikliklerin kütüphanelerde gerçekleşmesi can sıkıcı olduğu gibi Terraform modüllerinde geriye dönük uyumlu olmayan değişiklikler yapılması da bir o kadar sinir bozucudur. Terraform modüllerini kullanırken git tagları ve semver kullanılması tavsiye edilir.

Prodüksiyon hizmetiniz dizüstü bilgisayarınızda mı yoksa bir veri merkezinde mi çalışıyor?

Hashicorp'un gibi araçları var Dünya bulutu Terraform'unuzu çalıştırmak için. Bu merkezi hizmetler, dünya değişikliklerinin yönetilmesini, denetlenmesini ve onaylanmasını kolaylaştırır.

Test yazmıyor musun?

Mühendisler kodun test edilmesi gerektiğinin farkındadırlar ancak Terraform ile çalışırken genellikle kendileri test etmeyi unuturlar. Altyapı açısından bu durum tehlikeli anlarla doludur. Benim tavsiyem, CI/CD sırasında test için doğru şekilde dağıtılabilecek modülleri kullanarak yığınları "test etmek" veya "örnek oluşturmak"tır.

Terraform ve mikro hizmetler

Mikro hizmet şirketlerinin yaşamı ve ölümü, yeni mikro hizmet iş yığınlarının hızına, yenilikçiliğine ve bozulmasına bağlıdır.

Mikroservis mimarilerinde en sık karşılaşılan ve ortadan kaldırılamayan olumsuzluk kodla değil yapılan işle ilgilidir. Terraform'u yalnızca mikro hizmet mimarisinin altyapı tarafını otomatikleştirmenin bir yolu olarak düşünüyorsanız, sistemin gerçek faydalarını kaçırıyorsunuz demektir. Şimdi zaten her şey kod gibidir.

Kaynak: habr.com

Yorum ekle