arrow-left

Only this pageAll pages
gitbookPowered by GitBook
1 of 15

Türkçe (Turkish)

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Kod Yapısı

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ü.

hashtag
Terraform konfigürasyon yapısını nasıl kurmalıyım?

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

circle-info

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.

hashtag
Terraform konfigürasyonlarının yapılandırılmasına başlarken

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.

terraform.tfvars dışında hiçbir yerde kullanılmamalıdır.

hashtag
Terraform yapılandırma yapısı hakkında nasıl düşünülür?

circle-info

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.

hashtag
Kod yapısı hakkında genel öneriler

  • 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

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.

hashtag
Altyapı modüllerinin ve kompozisyonlarının yönetimi

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:

  1. Terraform. Çok basit, geliştiricilerin işi halletmek için yalnızca Terraform'u bilmesi gerekiyor.

  2. 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.

  3. Şirket içi scriptler. Genellikle bu, düzenlemeye yönelik bir başlangıç noktası olarak ve Terragrunt'ı keşfetmeden önce olur.

Bunları akılda tutarak, bu kitap bu proje yapılarının ilk ikisini, sadece Terraform ve Terragrunt hakkında bilgi içermektedir.

Bir sonraki bölümde veya için kod yapısı örneklerine gözatabilirsiniz.

Anahtar Kavramlar

Resmi Terraform dökümanındaarrow-up-right 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.

Bu bölüm kitap içerisinde yer alan anahtar kavramların açıklamalarını içermektedir.

hashtag
Kaynak (Resource)

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).

hashtag
Kaynak Modülü (Resource module)

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.

hashtag
Altyapı Modülü (Infrastructure module)

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.

Ö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.

hashtag
Kompozisyon (Composition)

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.

hashtag
Veri Kaynağı (Data source)

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.

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.

hashtag
Endirekt Durum (Remote state)

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).

hashtag
Sağlayıcı, Hükümcü vb.(Provider, provisioner, etc)

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.

hashtag
Neden bu kadar zor?

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.

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.

Kompozisyonlar arasındaki erişim, genellikle endirekt durum veri kaynakları kullanılarak gerçekleştirilir. vardır.

Yukarıda açıklanan kavramlar kabaca aşağıdaki şekilde görülebilir.

Kod Yapısı Örnekleri

hashtag
Terraform Kod Yapıları

circle-info

Bu örnekler, AWS sağlayıcısını göstermektedir, ancak örneklerde gösterilen ilkelerin çoğu, diğer genel bulut sağlayıcılarının yanı sıra diğer sağlayıcı türlerine de (DNS, DB, İzleme, vb.) uygulanabilir.

Tip
Açıklama
Kullanılabilirlik

hashtag
Terragrunt kod yapıları

Tip
Açıklama
Kullanılabilirlik
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

  • 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.

  • Tutarlı bir yapı ve adlandırma kuralı uygulayın:

    • 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

  • 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.

  • randomarrow-up-right
    localarrow-up-right
    terraformarrow-up-right
    nullarrow-up-right
    timearrow-up-right
    kompozisyon
    Terraform
    Terragrunt

    Hayır

    small

    Az kaynak, dış bağımlılık yok. Tek AWS hesabı. Tek bölge. Tek ortam.

    Evet

    medium

    Birkaç AWS hesabı ve ortamı, Terraform kullanan hazır altyapı modülleri.

    Evet

    large

    Birçok AWS hesabı, birçok bölge, kopyala-yapıştır, özel altyapı modülleri, yoğun kompozisyon kullanımı azaltma acil ihtiyacı. Terraform'u kullanma.

    Geliştirme Aşamasında

    very-large

    medium

    Birkaç AWS hesabı ve ortamı, kullanıma hazır altyapı modülleri, Terragrunt kullanan kompozisyon kalıbı.

    Hayır

    large

    Birçok AWS hesabı, birçok bölge, kopyala-yapıştır, özel altyapı modülleri, yoğun kompozisyon kullanımı azaltma acil ihtiyacı. Terragrunt'u kullanma.

    Hayır

    very-large

    Birkaç sağlayıcı (AWS, GCP, Azure). Çoklu bulut dağıtımları. Terragrunt'u kullanma.

    Hayır

    Birkaç sağlayıcı (AWS, GCP, Azure). Çoklu bulut dağıtımları. Terraform'u kullanma.

    Terragrunt

    AWS VPC Terraform Modulearrow-up-right
    terraform-aws-atlantilsarrow-up-right
    AWS Fargatearrow-up-right
    Atlantis'inarrow-up-right
    terraform-aws-vpcarrow-up-right
    terraform-aws-security-grouparrow-up-right
    terraform-aws-cloudqueryarrow-up-right
    terraform-aws-modulesarrow-up-right
    externalarrow-up-right
    httparrow-up-right
    Terraform statearrow-up-right
    Terraform statearrow-up-right
    terraform-aws-security-grouparrow-up-right
    Konfigürasyonlar arasında veri paylaşmanın birden çok yoluarrow-up-right
    Simple infrastructure composition
    composition-1 {
      infrastructure-module-1 {
        data-source-1 => d1
    
        resource-module-1 {
          data-source-2 => d2
          resource-1 (d1, d2)
          resource-2 (d2)
        }
    
        resource-module-2 {
          data-source-3 => d3
          resource-3 (d1, d3)
          resource-4 (d3)
        }
      }
    
    }

    Terraform ile küçük ölçekli altyapı yönetimi

    Kaynak:

    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.

    circle-check
    • Başlamak ve geriye yönelik güncelleme yapmak için mükemmel.

    Kodlama Tarzı

    circle-info
    • Örnekler ve Terraform modülleri, özellikleri ve bunların nasıl kullanılacağını açıklayan belgeler içermelidir.

    • README.md dosyası içerisinde tüm linkler açıklayıcı bir şekilde mevcut olmalıdır.

    Atölye

    Bu kılavuzda açıklanan bazı şeyleri uygulamak isteyenler için de bir atölye var.

    İçeriğe buradan ulaşabilirsiniz -

    Dökümantasyon mermaidarrow-up-right ile oluşturulan diagram, cloudcraft.coarrow-up-right tarafından oluşturulan blueprint içerebilir.

  • Terraform kodunuzun geçerli, düzgün biçimlendirilmiş ve otomatik olarak belgelendiğinden emin olmak için Terraform pre-commitarrow-up-right hooks kullanılabilir.

  • hashtag
    Belgeleme

    hashtag
    Otomatik oluşturulan dökümantasyon

    pre-commitarrow-up-right çoklu dil destekli pre-commit hooklarını kontrol etmeyi sağlayan bir frameworktur. Python ile yazılmıştır ve kod bir git reposuna işlenmeden önce geliştiricinin makinesinde otomatik olarak bir şeyler yapmak için güçlü bir araçtır. Normalde, linterleri çalıştırmak ve kodu biçimlendirmek için kullanılır (desteklenen hooklaraarrow-up-right gözatabilirsiniz).

    Terraform konfigürasyonları ile pre-commit, kodu formatlamak, doğrulamak ve belgeleri güncellemek için kullanılabilir.

    Kendinizi daha iyi tanımak için pre-commit-terraformarrow-up-right reposuna ve bunun zaten kullanıldığı mevcut repolara (örneğin, terraform-aws-vpcarrow-up-right) gözatabilirsiniz.

    hashtag
    terraform-docs

    terraform-docsarrow-up-right, Terraform modüllerinden çeşitli çıktı formatlarında dokümantasyon üreten bir araçtır. Belgeleri otomatik olarak güncellemek için manuel olarak çalıştırabilir (pre-commit hooklarıarrow-up-right olmadan) veya pre-commit-terraform hooklarını kullanabilirsiniz.

    hashtag
    Kaynaklar

    1. pre-commit framework homepagearrow-up-right

    2. Collection of git hooks for Terraform to be used with pre-commit frameworkarrow-up-right

    3. Blog post by Dean Wilsonarrow-up-right: pre-commit hooks and terraform - a safety net for your repositoriesarrow-up-right

  • 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)

  • circle-exclamation

    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)

    https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraformarrow-up-right
    https://github.com/antonbabenko/terraform-best-practices-workshoparrow-up-right

    Hoşgeldiniz...

    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.

    Çoğu DevOps aracı gibi Terraformarrow-up-right için de oldukça yeni bir proje diyebiliriz. (2014'de kullanıma açıldı.)

    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.

    Bu kitap 2018'de bir Madrid yazında yazılmaya başlandı ve https://www.terraform-best-practices.com/arrow-up-right adresinden ulaşabilirsiniz.

    Sözün özü, bu kitap Terraform kullanıcıları için en iyi uygulama metodlarını ve önerileri içermektedir ve içermelidir.

    hashtag
    Sponsors

    Please if you want to become a sponsor.

    hashtag
    Translations

    Bu kitabın başka dillere çevirisi için yardım etmek istiyorsanız benle iletişime geçebilirsiniz.

    hashtag
    Katkıda Bulunma

    Belirli bir konu hakkında ilgileniyorsanız, işini açabilirsiniz veya açık işi işaretleyerek ön plana çıkarabilirsiniz.

    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!)

    hashtag
    Authors

    Bu kitap tarafından katkı sağlayanlar ve çevirmenlerin yardımıyla düzenlenmektedir.

    hashtag
    Lisans

    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.

    Terraform ile orta ölçekli altyapı yönetimi

    Kaynak: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/medium-terraformarrow-up-right

    Bu örnek, aşağıdakileri kullanan orta ölçekli bir altyapı için Terraform konfigürasyonlarının yapılandırılmasına örnek kodları içerir:

    • 2 AWS hesabı

    • 2 ayrı ortam (tamamen birbirlerinden izole prod ve stage). Her ortam ayrı bir AWS hesabında yaşar

    • Her ortam, Terraform Registry kaynaklı hazır altyapı modülünün (alb) farklı bir sürümünü kullanır.

    • Her ortam, dahili modüllerin aynı versiyonu kullanır.

    circle-check
    • Altyapının mantıksal olarak ayrıldığı projeler için mükemmel (ayrı AWS hesapları)

    • AWS hesapları arasında paylaşılan kaynakları değiştirmeye gerek olmadığında iyidir (bir ortam = bir AWS hesabı = bir durum dosyası)

    circle-exclamation

    Proje büyüdükçe bu ortamları birbirleriyle güncel tutmak zorlaşacaktır. Tekrarlanabilir görevler(task) için altyapı modüllerini (kullanıma hazır veya dahili) kullanmayı düşünün.

    hashtag

    Ortamlar arasındaki değişikliklerin yönetilmesine gerek olmadığında iyidir

  • Altyapı kaynakları ortam başına farklı olduğunda ve genelleştirilemediğinde iyidir (örneğin, bazı kaynaklar bir ortamda veya bazı bölgelerde yoktur)

  • arrow-up-right

    Compliance.tfarrow-up-right — Terraform Compliance Simplified. Make your Terraform modules compliance-ready.

    —

    contact mearrow-up-right
    العربية (Arabic)chevron-right
    Bosanski (Bosnian)chevron-right
    Português (Brazilian Portuguese)chevron-right
    Englishchevron-right
    Français (French)chevron-right
    ქართული (Georgian)chevron-right
    Deutsch (German)chevron-right
    ελληνικά (Greek)chevron-right
    עברית (Hebrew)chevron-right
    हिंदी (Hindi)chevron-right
    Bahasa Indonesia (Indonesian)chevron-right
    Italiano (Italian)chevron-right
    日本語 (Japanese)chevron-right
    ಕನ್ನಡ (Kannada)chevron-right
    한국어 (Korean)chevron-right
    Polski (Polish)chevron-right
    Română (Romanian)chevron-right
    简体中文 (Simplified Chinese)chevron-right
    Español (Spanish)chevron-right
    Українська (Ukrainian)chevron-right
    اردو (Urdu)chevron-right
    açabilirsinizarrow-up-right
    Anton Babenkoarrow-up-right

    Referanslar

    circle-info

    Harika içerik oluşturan ve Terraform topluluğuyla ilgili açık kaynaklı projeleri yöneten birçok insan var, ancak awesome-terraformarrow-up-right gibi listeleri kopyalamadan bu bağlantıları burada listelemek için en iyi yapı nedir bilemiyorum.

    https://twitter.com/antonbabenko/lists/terraform-expertsarrow-up-right - Terraform'u aktif olarak kullanan insanların bulunduğu bir liste.

    https://github.com/shuaibiyy/awesome-terraformarrow-up-right - HashiCorp'un Terraform'ındaki kaynakların derlenmiş listesi.

    http://bit.ly/terraform-youtubearrow-up-right - Anton Babenko'nun "Your Weekly Dose of Terraform" YouTube kanalı. İncelemeler, röportajlar, Soru-Cevap, canlı kodlama ve bazı Terraform korsanlığı içeren canlı yayınlar.

    - Terraform Haftalık haber bülteni. Anton Babenko tarafından Terraform dünyasından çeşitli haberler (projeler, duyurular, tartışmalar).

    SSS

    FTP (Frequent Terraform Problems)

    hashtag
    Farkında olmam ve kullanmayı düşünmem gereken araçlar nelerdir?

    • Terragruntarrow-up-right - Yönetim aracı

    • - Statik kod analiz aracı

    • - Versiyon yönetimi

    • - Pull Request otomasyonu

    • - pre-commit'lerde kullanılabilecek git hooklarının birleşimi olan bir framework.

    • - Pull requestlerde Terraform için bulut maliyet tahminleri. Terragrunt, Atlantis ve pre-commit-terraform ile de çalışır.

    hashtag
    Modüllerle bağımlılık cehennemine (dependency hell) çözümler nelerdir?

    Kaynak ve altyapı modüllerinin sürümleri belirtilmelidir. Sağlayıcılar, modüllerin dışında, ancak yalnızca bileşimde yapılandırılmalıdır. Sağlayıcıların sürümü ve Terraform da kilitlenebilir.

    Ana bağımlılık yönetimi aracı yoktur, ancak bağımlılık belirtimlerini daha az sorunlu hale getirmek için bazı ipuçları vardır. Örneğin, , bağımlılık güncellemelerini otomatikleştirmek için kullanılabilir. Dependabot, bağımlılıklarınızı güvenli ve güncel tutmak için çekme istekleri oluşturur. Dependabot, Terraform konfigürasyonlarını destekler.

    Terraform Konfigürasyonu Yazma

    hashtag
    Kaynaklar arasındaki açık bağımlılıkları belirtmek için locals kullanın

    Terraform konfigürasyonlarında doğrudan bağımlılık olmasa bile bazı kaynakların daha önce silinmesi gerektiğine dair Terraform'a bir ipucu vermenin yararlı yolu.

    https://weekly.tfarrow-up-right
    tflintarrow-up-right
    tfenvarrow-up-right
    Atlantisarrow-up-right
    pre-commit-terraformarrow-up-right
    Infracostarrow-up-right
    Dependabotarrow-up-right
    hashtag
    Terraform 0.12 - Zorunlu Zorunlu(Requiered) vs. Opsiyonel(Optional) Argümanlar
    1. var.website boş bir map değilse, zorunlu argüman index_document ayarlanmalıdır.

    2. İsteğe bağlı argüman error_document göz ardı edilebilir

    https://raw.githubusercontent.com/antonbabenko/terraform-best-practices/master/snippets/locals.tfarrow-up-right
    main.tf
    variable "website" {
      type    = map(string)
      default = {}
    }
    
    resource "aws_s3_bucket" "this" {
      # omitted...
    
      dynamic "website" {
        for_each = length(keys(var.website)) == 0 ? [] : [var.website]
    
        content {
          index_document = website.value.index_document
          error_document = lookup(website.value, "error_document", null)
        }
      }
    }
    terraform.tfvars
    website = {
      index_document = "index.html"
    }

    Terraform ile büyük ölçekli altyapı yönetimi

    Kaynak:

    Bu örnek, büyük boyutlu bir altyapı için Terraform konfigürasyonları yapılandırılmasına yönelik örnek kodları içerir.

    • 2 AWS hesabı

    • 2 bölge

    2 ayrı ortam (tamamen birbirlerinden izole prod ve stage). Her ortam ayrı bir AWS hesabında bulunur ve kaynakları 2 bölge arasında dağıtır

  • Her ortam, Terraform Registry kaynaklı hazır altyapı modülünün (alb) farklı bir sürümünü kullanır.

  • Her ortam, dahili modüllerin aynı versiyonu kullanır.

  • circle-info

    Burada açıklanan gibi büyük bir projede Terragrunt kullanmanın faydaları çok görünür hale gelir. Terragrunt ile Kod Yapıları örneklerine gözatabilirsiniz.

    circle-check
    • Altyapının mantıksal olarak ayrıldığı projeler için mükemmel (ayrı AWS hesapları)

    • AWS hesapları arasında paylaşılan kaynakları yönetmeye gerek olmadığında iyidir (bir ortam = bir AWS hesabı = bir durum dosyası)

    • Ortamlar arasındaki değişikliklerin yönetilmesine gerek olmadığında iyi

    • Altyapı kaynakları ortam başına farklı olduğunda ve genelleştirilemediğinde iyidir (örneğin, bazı kaynaklar bir ortamda veya bazı bölgelerde yoktur)

    circle-exclamation

    Proje büyüdükçe bu ortamları birbirleriyle güncel tutmak zorlaşacaktır. Tekrarlanabilir görevler(task) için altyapı modüllerini (kullanıma hazır veya dahili) kullanmayı düşünebilirsiniz.

    hashtag

    https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraformarrow-up-right

    Adlandırma Kuralları

    hashtag
    Genel Kurallar

    circle-info

    En azından bu kurallara uymamak için hiçbir sebep olmamalı :)

    circle-info

    Gerçek bulut kaynaklarının genellikle izin verilen adlarda kısıtlamalara sahip olduğuna dikkat edin. Örneğin, bazı kaynaklar tire içeremez, bazıları camelCased olmalıdır. Bu kitaptaki kurallar, Terraform adlarının kendilerine atıfta bulunur.

    1. Her yerde - (tire) yerine _ (alt çizgi) kullanın (kaynak adlarında, veri kaynağı adlarında, değişken adlarında, çıktılarda vb.).

    2. Küçük harf ve rakam kullanmayı tercih edin (UTF-8 desteklense de).

    hashtag
    Kaynak ve veri kaynağı parametreleri

    1. Kaynak adında kaynak türünü tekrar etmeyin (kısmen veya tamamen değil):

    circle-check
    triangle-exclamation
    triangle-exclamation
    1. Daha fazla açıklayıcı ve genel ad yoksa veya kaynak modülü bu türde tek bir kaynak oluşturuyorsa (örneğin, AWS VPC modülünde aws_nat_gateway türünde tek bir kaynak varsa ve typeaws_route_table türünde birden çok kaynak varsa) kaynak adı bu şekilde adlandırılmalıdır: aws_nat_gateway bu şekilde adlandırılmalı ve aws_route_table daha açıklayıcı adlara sahip olmalıdır - private, public, database gibi).

    2. Mutlaka tekli isimler kullanın.

    3. - Çizgiyi parametre değerlerinin girildiği değişkenlerde kullanabilirsiniz.

    4. 'count' veya 'for_each' kullanan bir parametre veya veri kaynağı bloğu ilk parametre olmalıdır ve yeni bir satırla ayrılarak en üstte konumlanmalıdır.

    5. Mümkün olduğunca son parametrede depends_on, lifecycle gibi etiketleri(tags) kullanmaya çalışın.

    6. 'count' veya 'for_each' kullanırken mümkün olduğunca boolean değerleri tercih edin. Length veya başka karşılaştırmaları ikinci plana atmanız iyi olacaktır.

    hashtag
    'Kaynak(Resource)' kod örneği

    hashtag
    count/for_each kullanımı

    circle-check
    triangle-exclamation

    hashtag
    Etiketlerin Kullanımı (tags)

    circle-check
    triangle-exclamation

    hashtag
    count içerisindeki karşılaştırmalar

    circle-check

    hashtag
    Değişkenler

    1. Kaynak modüllerinde tekerleği yeniden icat etmeyin: birlikte çalıştığınız kaynak için "Argüman Referansı" bölümünde tanımlandığı gibi değişkenler için ad, açıklama ve varsayılan değeri kullanın.

    2. Değişkenlerde doğrulama desteği oldukça sınırlıdır (örneğin, diğer değişkenlere erişemez veya arama yapamaz). Buna göre plan yapın çünkü çoğu durumda bu özellik işe yaramaz.

    3. Tür list(...) veya map(...) olduğunda, değişken adında çoğul formu kullanın.

    4. 'Key'leri aşağıdaki sırada olacak şekilde bir değişken bloğunda muhafaza ediniz. Tanım(Description), tip(type), default(Fabrika Ayarı), doğrulama(validation)

    5. Açık olduğunu düşünseniz bile her zaman tüm değişkenlere açıklama ekleyin (gelecekte buna ihtiyacınız olacak).

    6. Her bir anahtar üzerinde katı kısıtlamalarınız olması gerekmedikçe, object() gibi belirli türler yerine basit türleri (number, string, list(...), map(...), herhangi biri) kullanmayı tercih edin.

    7. map'in tüm öğeleri aynı türe sahipse (ör. string) veya buna dönüştürülebiliyorsa (ör. number türü stringe dönüştürülebilirse) map(map(string)) gibi belirli türleri kullanın.

    8. Belirli bir derinlikten başlayarak veya birden çok türün desteklenmesi gerektiğinde tür doğrulamasını devre dışı bırakmak için 'any' kullanın.

    9. {} değeri bazen bir map, bazen de bir objedir. Map'e çevirmek için tomap(...) kullanın çünkü bir obje yapmanın yolu yoktur.

    hashtag
    Çıktılar

    Çıktıları kapsamı dışında tutarlı ve anlaşılır hale getirin (bir kullanıcı bir modül kullanırken, döndürdüğü değerin türünü ve niteliğini açıkça belirtmelidir).

    1. Çıktının adı, içerdiği özelliği tanımlamalı ve normalde istediğinizden daha az serbest biçimli olmalıdır.

    2. Çıktı adı için iyi bir yapı {name}_{type}_{attribute}gibi görünür, burada:

      1. {name} bir kaynak veya veri kaynağı olabilir. Tabiki sağlayıcı prefixi olmadan. aws_subnet için {name} 'subnet'dir, foraws_vpc 'vpc'dir.

      2. {type} ise kaynağın tipini belirtmektedir.

      3. {attribute}, çıktı tarafından döndürülen bir niteliktir

      4. .

    3. Eğer çıktılar interpolation fonksiyonlarını veya çoklu kaynak barındıran bir değer döndürüyorsa {name} ve {type} mümkün olduğunca genel olmalıdır.

    4. Eğer döndürülen değer bir list ise çoğul bir isme sahip olmalıdır.

    5. Çok açık olduğunu düşündüğünüz çıktılar dahil mutlaka tüm çıktılara tanım(description) ekleyiniz.

    6. Tüm modüllerde bu çıktının kullanımını tamamen kontrol etmedikçe sensetive argüman kullanmaktan kaçının.

    7. element(concat(...)) yerine try()'ı (Terraform 0.13'ten beri mevcuttur) tercih edin (0.13'ten önceki sürüm için eski yaklaşım)

    hashtag
    Çıktı(Output) için kod örnekleri

    En fazla güvenlik grubunun bir ID'sini döndürün:

    circle-check

    Aynı türden birden fazla kaynağa sahip olduğunda, çıktı adına bu kaçınılmalıdır:

    triangle-exclamation

    hashtag
    Eğer dönen değer list ise çoğul isim kullanımı

    circle-check
    `resource "aws_route_table" "public" {}`
    `resource "aws_route_table" "public_route_table" {}`
    `resource "aws_route_table" "public_aws_route_table" {}`
    main.tf
    resource "aws_route_table" "public" {
      count = 2
    
      vpc_id = "vpc-12345678"
      # ... remaining arguments omitted
    }
    
    resource "aws_route_table" "private" {
      for_each = toset(["one", "two"])
    
      vpc_id = "vpc-12345678"
      # ... remaining arguments omitted
    }
    main.tf
    resource "aws_route_table" "public" {
      vpc_id = "vpc-12345678"
      count  = 2
    
      # ... remaining arguments omitted
    }
    main.tf
    resource "aws_nat_gateway" "this" {
      count = 2
    
      allocation_id = "..."
      subnet_id     = "..."
    
      tags = {
        Name = "..."
      }
    
      depends_on = [aws_internet_gateway.this]
    
      lifecycle {
        create_before_destroy = true
      }
    }   
    main.tf
    resource "aws_nat_gateway" "this" {
      count = 2
    
      tags = "..."
    
      depends_on = [aws_internet_gateway.this]
    
      lifecycle {
        create_before_destroy = true
      }
    
      allocation_id = "..."
      subnet_id     = "..."
    }
    outputs.tf
    resource "aws_nat_gateway" "that" {    # Best
      count = var.create_public_subnets ? 1 : 0
    }
    
    resource "aws_nat_gateway" "this" {    # Good
      count = length(var.public_subnets) > 0 ? 1 : 0
    }
    outputs.tf
    output "security_group_id" {
      description = "The ID of the security group"
      value       = try(aws_security_group.this[0].id, aws_security_group.name_prefix[0].id, "")
    }
    outputs.tf
    output "this_security_group_id" {
      description = "The ID of the security group"
      value       = element(concat(coalescelist(aws_security_group.this.*.id, aws_security_group.web.*.id), [""]), 0)
    }
    outputs.tf
    output "rds_cluster_instance_endpoints" {
      description = "A list of all cluster instance endpoints"
      value       = aws_rds_cluster_instance.this.*.endpoint
    }
    Örnekleri inceleyebilirsiniz
    Örneği inceleyebilirsiniz.

    Terraform