Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Bu döküman Terraform aracının en iyi uygulama metodlarını ve Terraform kullanıcılarının sık karşılaştığı problemlere yönelik çözüm önerilerini sistematik bir şekilde açıklamaktadır.
Terraform yetenekli, güçlü ve altyapıyı kod ile kontrol etmenize olanak sağlayan en fazla kullanılan araçlardan biridir. Tamamiyle geliştirici dostu, çok fazla operasyonu yapmaya olanak sağladığı gibi yapılan operasyonlarda entegrasyonu sağlayabilmek için kısıtlayıcı şekilde sadece tek bir yol sunmaz. Oldukça esnek bir araçtır.
Bu kitaptaki bazı bilgiler Terraform'un en iyi uygulama metodları gibi görünmeyebilir. Bunu biliyorum ve kullanıcıların neyin en iyi uygulamalar, neyin konu hakkında başka bir bakış açısı olduğunu ayırt etmesi için bazı yerlerde küçük ipuçları, simgeler ve bağlamlar kullandım.
Sözün özü, bu kitap Terraform kullanıcıları için en iyi uygulama metodlarını ve önerileri içermektedir ve içermelidir.
Bu kitabın başka dillere çevirisi için yardım etmek istiyorsanız benle iletişime geçebilirsiniz.
Belirli bir konu hakkında ilgileniyorsanız, işini açabilirsiniz veya açık işi işaretleyerek ön plana çıkarabilirsiniz.
Bu çalışma Apache 2 Lisans'ı ile lisanslanmıştır. Lisans'ın tüm detaylarını okuyabilirsiniz.
Bu içeriğin yazarları ve katkıda bulunanlar, burada bulunan bilgilerin geçerliliğini garanti edemez. Lütfen burada verilen bilgilerin ücretsiz olarak verildiğini anladığınızdan ve proje ile ilişkili herhangi bir kişi arasında hiçbir tür anlaşma veya sözleşme oluşturulmamış olduğundan emin olabilirsiniz. Yazarlar ve katkıda bulunanlar, bu içerikte yer alan, içerikle ilişkili veya bu içerikten bağlantı verilen bilgilerdeki hata veya eksikliklerden kaynaklanan herhangi bir kayıp, hasar veya kesinti için, bu tür hatalar veya eksikliklerden kaynaklanıp kaynaklanmadığına bakılmaksızın, herhangi bir tarafa herhangi bir sorumluluk kabul etmez ve burada sorumluluk kabul etmez.
Tüm hakları saklıdır © 2018-2023 Anton Babenko.
Bu bölüm kitap içerisinde yer alan anahtar kavramların açıklamalarını içermektedir.
aws_vpc
, aws_db_instance
kaynak örneği olarak verilebilir. Her bir kaynak bir sağlayıcıya(provider) aittir, argüman kabul eder, özelliklerini çıktı olarak oluşturur ve birer yaşam döngüsü vardır. Kaynaklar oluşturulabilir(create), geri alınabilir(retrieve), güncellenebilir(update) veya silinebilir(delete).
Kaynak moullerinin bir araya gelmesiyle altyapı modülü oluşur. Bunlar mantıksal olarak birbiriyle bağlantılı olmayabilir ama var olan projede veya kurulumda aynı amaca hizmet eder.Altyapı modülünde sağlayıcı(provider) için gerekli konfigürasyonlar belirlenir. Bu konfigürasyonlar kaynak modülüne ve kaynaklara geçecektir. Altyapı modülü genellikle her mantıksal ayraç (AWS Region, Google Project) için bir özellikle limitlenmektedir.
Kompozisyon çeşitli mantıksal olarak birbirlerinden ayrılan(AWS Regions, AWS Accounts) altyapı modüllerinin bir araya gelmesinden oluşur. Genellikle Kompozisyonlar bir organizasyondaki veya projedeki tüm altyapıyı tanımlamak için kullanılır.
Bir kompozisyon altyapı modüllerinden oluşur ki altyapı modülü de çeşitli kaynak modülleri ve kişisel olarak oluşturulan kaynaklardan oluşur.
Veri kaynakları sadece okuma (read-only) modunda hizmet vermektedir ve sağlayıcının konfigürasyonlarına bağımlıdır. Veri kaynakları bir kaynak modülü veya altyapı modülü içerisinde kullanılabilir.
Veri kaynağı terraform_remote_state
üst seviye modülleri ve kompozisyonları bir arada tutmak için tutkal vazifesi görür.
Sağlayıcı, hükümcü ve diğer birtakım terimler resmi dökümantasyonda çok güzel açıklanmış durumda ve bunları papağan gibi tekrarlamanın alemi yok. Bana göre bunları bilmenin iyi terraform modülleri yazmakla da çok alakası yok.
Moleküller arası (kaynak modülleri ve altyapı modülleri) verilere erişim, modüllerin çıktıları ve veri kaynakları kullanılarak gerçekleştirilir.
Yukarıda açıklanan kavramlar kabaca aşağıdaki şekilde görülebilir.
Bu örnek, hiçbir harici bağımlılığın kullanılmadığı küçük boyutlu bir altyapı için Terraform konfigürasyonları yapılandırılmasına yönelik örnek kodları içerir.
Başlamak ve geriye yönelik güncelleme yapmak için mükemmel.
Küçük kaynak modülleri için harika
Küçük ve doğrusal altyapı modülleri için iyi (ör. terraform-aws-atlantis).
Az sayıda kaynak için iyi (20-30'dan az)
Tüm kaynaklar için tek durum dosyası, kaynak sayısı artıyorsa Terraform ile çalışma sürecini yavaşlatabilir (kaynak sayısını sınırlamak için -target argümanını kullanmayı düşününebilirsiniz)
Terraform kod yapısıyla ilgili sorular, toplulukta açık ara en sık sorulan sorulardır. Herkes bir noktada proje için en iyi kod yapısını da düşündü.
Bu, birçok çözümün bulunduğu ve genel bir tavsiye vermenin çok zor olduğu sorulardan biridir, o yüzden neyle uğraştığımızı anlamakla başlayalım.
Projeniz ne kadar karışık?
Bağımlı olduğu kaynakların sayısı
Terraform sağlayıcılarının sayısı (Mantıksal ayraçlar hakkındaki not için aşağıya gözatınız)
Altyapınız ne sıklıkla değişiyor?
Ayda/yılda/günde bir defadan
Sürekli değişen bir yapıya (Her committe güncellenen bir yapı)
Kod değişikliği başlatıcıları? Yeni bir çıktı üretildiğinde CI aracınızın repoyu güncellemesine izin veriyor musunuz?
Altyapı reposunda sadece geliştiriciler kod değişikliği yapabilir.
Herkes, altyapı reposunda değişiklik için PR(Pull Request) açabilir (Buna CI aracı ve diğer botlar da dahil.)
Hangi geliştirme platformunu veya dağıtım servisini kullanıyorsunuz?
AWS CodeDeploy, Kubernetes veya OpenShift için farklı farklı yaklaşımlar sergilemeniz gerekebilir.
Hangi özelliğe göre gruplandırma yapıyorsunuz?
Ortam(environment), bölge(region), proje
Başlarken veya bir örnek kod yazarken tüm kodu main.tf
'ye koymak iyi bir fikirdir. Diğer tüm durumlarda, aşağıdaki gibi mantıksal olarak bölünmüş birkaç dosyaya sahip olmak daha iyi olacaktır:
main.tf
- tüm kaynakları oluşturmak için modülleri, yerelleri ve veri kaynaklarını çağıran dosyadır.
variables.tf
- main.tf
'de kullanılan değişkenlerin tanımlamalarını içerir.
outputs.tf
- main.tf
'de oluşturulan kaynaklardan çıktıları içerir
versions.tf
- Terraform ve sağlayıcılar için sürüm gereksinimlerini içerir
Aşağıdaki örneklerde kullanıldığı şekliyle kaynak modülü, altyapı modülü ve kompozisyon gibi temel kavramları anladığınızdan lütfen emin olun.
Daha az sayıda kaynakla çalışmak daha kolay ve hızlıdır
terraform plan
ve terraform apply
, kaynakların durumunu doğrulamak için bulut API istekleri yapar
Tüm altyapınız tek bir kompozisyondaysa bu biraz zaman alabilir.
Patlama çapı (güvenlik ihlali durumunda) daha az kaynakla daha küçüktür
Birbiriyle ilgisi olmayan kaynakları ayrı bileşimlere yerleştirerek birbirinden yalıtmak, bir şeyler ters giderse oluşacak sorun riskini azaltır.
Projenizdi endirekt durum kullanarak başlatın çünkü
Dizüstü bilgisayarınız, altyapınızın kaynaklarını barındırmak için için doğru bir yer değil.
Git'te bir tfstate
dosyasını yönetmek kabustur.
Daha sonra altyapı katmanları birden çok yönde (bağımlılık veya kaynak sayısı) büyümeye başladığında, işleri kontrol altında tutmak daha kolay olacaktır.
Prosedürel kod gibi, Terraform kodu da insanların okuyabilmesi için yazılmalıdır, bundan altı ay sonra değişiklikler olduğunda tutarlılık yardımcı olacaktır.
Kaynakları Terraform durum dosyasında taşımak mümkündür ancak tutarsız yapı ve adlandırmalarınız varsa bunu yapmak daha zor olabilir.
Kaynak modüllerini olabildiğince sade tutun.
Değişken olarak iletilebilecek veya veri kaynakları kullanılarak keşfedilebilecek değerleri sabit kodlamayın.
Veri kaynaklarını ve terraform_remote_state'i
özellikle kompozisyon içindeki altyapı modülleri arasında bir tutkal olarak kullanın
Bu kitapta, örnek projeler karmaşıklığa göre gruplandırılmıştır - küçük ölçekli yapılardan en büyüğene. Bu ayrım kesin çizgilerle ayrılmamıştır, bu nedenle diğer yapılara da göz gezdirmeniz iyi olacaktır.
Küçük bir altyapıya sahip olmak, az sayıda bağımlılık ve az kaynak olduğu anlamına gelir. Proje büyüdükçe, Terraform konfigürasyonlarının büyümesi ve bağımlılıklarının artmasıyla, farklı altyapı modülleri birbirine bağlama ve bir kompozisyon içindeki değerleri geçirme ihtiyacı ortaya çıkması kaçınılmazdır.
Geliştiricilerin kullandığı en az 5 farklı düzenleme çözümünden söz edebiliriz:
Terraform. Çok basit, geliştiricilerin işi halletmek için yalnızca Terraform'u bilmesi gerekiyor.
Terragrunt. Tüm altyapıyı düzenlemek ve bağımlılıkları işlemek için kullanılabilen saf düzenleme aracı. Terragrunt, altyapı modülleri ve kompozisyonları ile kendi makinenizde çalışır, böylece kod tekrarını azaltır.
Şirket içi scriptler. Genellikle bu, düzenlemeye yönelik bir başlangıç noktası olarak ve Terragrunt'ı keşfetmeden önce olur.
Ansible veya benzeri genel amaçlı otomasyon aracı. Genellikle Ansible'dan sonra Terraform benimsendiğinde veya Ansible UI aktif olarak kullanıldığında kullanılır.
Crossplane ve Kubernetes'ten ilham alan diğer çözümler. Bazen, Terraform konfigürasyonlarınızın istenen durumunu elde etmek için Kubernetes ekosistemini kullanmak ve bir mutabakat döngüsü özelliği kullanmak mantıklıdır. Daha fazla bilgi için Crossplane vs Terraform videosunu izleyin.
Bunları akılda tutarak, bu kitap bu proje yapılarının ilk ikisini, sadece Terraform ve Terragrunt hakkında bilgi içermektedir.
Tip | Açıklama | Kullanılabilirlik |
---|---|---|
Tip | Açıklama | Kullanılabilirlik |
---|---|---|
Çoğu DevOps aracı gibi için de oldukça yeni bir proje diyebiliriz. (2014'de kullanıma açıldı.)
Bu kitap 2018'de bir Madrid yazında yazılmaya başlandı ve adresinden ulaşabilirsiniz.
Please if you want to become a sponsor.
Bir konu hakkında yazacak şeyleriniz olduğunu hissediyorsanız ve bunları paylaşmak istiyorsanız, bir taslak hazırlayıp 'Pull Request' . (Bu noktada mükemmel bir şekilde yazmayabilirsiniz!)
Bu kitap tarafından katkı sağlayanlar ve çevirmenlerin yardımıyla düzenlenmektedir.
Resmi Terraform tüm bakış açılarını ve konfigürasyonları detaylı bir şekilde bulabilirsiniz. Bölümün geri kalanını anlamak için belirtilen dökümanı okumanız yararlı olacaktır.
Kaynak modülü, birlikte ortak eylemi gerçekleştiren bağlı kaynakların topluluğudur (Örnepin, , VPN, sunet, NAT gateway gibi kaynaklar oluşturur). Bu durum kaynak modülünün içinde veya daha üst seviye bir yapıda (Altyapı Modülü) tanımlanan sağlayıcıdan sağlayıcıya göre değişiklik gösterebilir.
Örneğin, modülü üzerinde çalışan altyapısını yönetmek için ve gibi çeşitli kaynak modüllerine ihtiyaç duyar.
Bir başka örnek ise modülü ve ün birtakım modülleri Docker kaynaklarının derlenmesi(build), ortak bir alana gönderilmesi (push) ve Docker imagelarının deploy edilmesi için kullanılır. Hepsi bir arada.
Harici () veri kaynağı, harici bir programın bir veri kaynağı olarak hareket etmesine ve Terraform konfigürasyonunda başka bir yerde kullanım için rasgele verileri açığa çıkarmasına izin verir. Burada, dosya adının harici bir Python betiği çağrılarak hesaplandığı terraform-aws-lambda modülünden bir örnek verilmiştir.
veri kaynağı, verilen URL'ye bir HTTP GET isteği yapar ve yerel bir Terraform sağlayıcısının bulunmadığı uç noktalardan bilgi almak için genellikle yararlı olan yanıtla ilgili bilgileri dışa aktarır.
Infrastructure modules and compositions should persist their in a remote location where it can be retrieved by others in a controllable way (e.g., specify ACL, versioning, logging).
Altyapı modülleri ve kompozisyonları, Terraform durumlarını () başkaları tarafından kontrol edilebilir bir şekilde alınabilecekleri uzak bir konumda sürdürmelidir (örneğin, versiyonlama, loglama).
Bireysel kaynaklar altyapıdaki atomlar gibiyken, kaynak modülleri (atomlardan oluşan) moleküllerdir. Modül, en küçük sürümlü ve paylaşılabilir birimdir. Tam bir argüman listesine sahiptir, böyle bir birimin gerekli işlevi yapması için temel mantığı uygular. Örneğin, modülü, girdiye dayalı olarak aws_security_group
ve aws_security_group_rule
kaynakları oluşturur. Bu kaynak modülü tek başına diğer modüllerle birlikte altyapı modülünü oluşturmak için kullanılabilir.
Kompozisyonlar arasındaki erişim, genellikle endirekt durum veri kaynakları kullanılarak gerçekleştirilir. vardır.
Kaynak:
Mantıksal sağlayıcılar tamamen Terraform'un mantığı içinde çalışır ve çoğu zaman başka hizmetlerle etkileşime girmez, bu nedenle karmaşıklıklarını O(1) olarak düşünebiliriz. En yaygın mantıksal sağlayıcılar arasında rastgele(), yerel(), , , bulunur.
terraform.tfvars
dışında hiçbir yerde kullanılmamalıdır.
Tutarlı bir yapı ve kuralı uygulayın:
Bir sonraki bölümde veya için kod yapısı örneklerine gözatabilirsiniz.