Ayrıca mevcut AWS altyapısını Terraform'a geçirme durumundayım, bu nedenle geliştirirken yanıtı güncellemeyi hedefleyeceğim.
Emin olmadığım alanları belirlemek için resmi Terraform örneklerine ve çoklu deneme yanılma yöntemlerine büyük ölçüde güveniyorum .
.tfstate Dosyalar
Terraform yapılandırması, her biri farklı bir duruma sahip olabilen farklı altyapı üzerinde birçok kutu sağlamak için kullanılabilir. O da birden fazla kişi tarafından çalıştırılabilir gibi bu durum (S3) gibi merkezi bir konumda olmalı ama değil git'e.
Bu, Terraform'a bakılarak doğrulanabilir .gitignore.
Geliştirici kontrolü
Amacımız, geliştiricilere altyapının daha fazla kontrolünü sağlarken, tam bir denetim (git log) ve değişiklikleri mantıklı kontrol etme yeteneği (çekme istekleri) sağlamaktır. Bunu göz önünde bulundurarak, hedeflediğim yeni altyapı iş akışı:
- Yeniden kullanılabilir modüller içeren ortak AMI'lerin temel temeli, örneğin kukla.
- Terraform kullanılarak DevOps tarafından sağlanan çekirdek altyapı.
- Geliştiriciler, Git'te Terraform yapılandırmasını gerektiği gibi değiştirir (örnek sayısı; yeni VPC; bölge / kullanılabilirlik bölgesi eklenmesi vb.).
- Git yapılandırması itildi ve DevOps ekibinin bir üyesi tarafından akıl sağlığının kontrol edilmesi için bir çekme isteği gönderildi.
- Onaylanırsa, oluşturmak ve dağıtmak için webhook'u CI'ye çağırır (şu anda birden fazla ortamı nasıl bölümleyeceğinizden emin değilsiniz)
Düzenleme 1 - Mevcut durumda güncelleme
Bu yanıta başladığımdan beri çok fazla TF kodu yazdım ve durumumuzda kendimi daha rahat hissediyorum. Yol boyunca hatalarımız ve kısıtlamalarımız var, ancak bunun yeni, hızla değişen yazılımları kullanmanın bir özelliği olduğunu kabul ediyorum.
Yerleşim
Her biri birden çok alt ağa sahip birden çok VPC içeren karmaşık bir AWS altyapımız var. Bunu kolayca yönetmenin anahtarı, altyapı kodumuzu (hem terraform hem de kukla) düzenlemek için kullanabileceğimiz bölge, çevre, hizmet ve sahibi kapsayan esnek bir sınıflandırma tanımlamaktı.
Modüller
Sonraki adım, terraform modüllerimizi depolamak için tek bir git deposu oluşturmaktı. Modüller için üst düzey dir yapımız şu şekildedir:
tree -L 1 .
Sonuç:
├── README.md
├── aws-asg
├── aws-ec2
├── aws-elb
├── aws-rds
├── aws-sg
├── aws-vpc
└── templates
Her biri bazı aklı başında varsayılanları ayarlar ancak bunları "yapıştırıcımız" tarafından üzerine yazılabilen değişkenler olarak gösterir.
Tutkal
glueYukarıda bahsedilen modülleri kullanan ikinci bir depomuz var . Sınıflandırma belgemiz doğrultusunda düzenlenmiştir:
.
├── README.md
├── clientA
│ ├── eu-west-1
│ │ └── dev
│ └── us-east-1
│ └── dev
├── clientB
│ ├── eu-west-1
│ │ ├── dev
│ │ ├── ec2-keys.tf
│ │ ├── prod
│ │ └── terraform.tfstate
│ ├── iam.tf
│ ├── terraform.tfstate
│ └── terraform.tfstate.backup
└── clientC
├── eu-west-1
│ ├── aws.tf
│ ├── dev
│ ├── iam-roles.tf
│ ├── ec2-keys.tf
│ ├── prod
│ ├── stg
│ └── terraform.tfstate
└── iam.tf
İstemci düzeyinde .tf, küresel kaynakları (IAM rolleri gibi) sağlayan AWS hesabına özel dosyalarımız var; ikincisi, EC2 SSH genel anahtarlarının bulunduğu bölge düzeyidir; Nihayet bizim ortamda ( dev, stg, prodvs) bizim VPC kurulumları, örnek oluşturma ve vb bağlantıları saklanır bakan bulunmaktadır.
Yan Not: Gördüğünüz gibi terraform.tfstategitte kalmaya ilişkin kendi tavsiyeme karşı çıkıyorum . Bu, S3'e geçene kadar geçici bir önlem ancak şu anda tek geliştirici olduğum için bana uygun.
Sonraki adımlar
Bu hala manuel bir süreç ve henüz Jenkins'te değil, ancak oldukça büyük, karmaşık bir altyapı taşıyoruz ve şimdiye kadar çok iyi. Dediğim gibi, birkaç böcek ama iyi gidiyor!
Edit 2 - Değişiklikler
Bu ilk cevabı yazalı neredeyse bir yıl oldu ve hem Terraform'un hem de benim durumum önemli ölçüde değişti. Şimdi bir Azure kümesini yönetmek için Terraform kullanarak yeni bir konumdayım ve Terraform şimdi v0.10.7.
Durum
İnsanlar sürekli bana devlet gerektiğini söylediler değil Git gitmek - ve doğrudur. Bunu, geliştirici iletişimine ve disiplinine güvenen iki kişilik bir ekiple geçici bir önlem olarak kullandık. Daha büyük, dağıtılmış bir ekiple artık DynamoDB tarafından sağlanan kilitleme ile S3'te uzak durumdan tamamen yararlanıyoruz . İdeal olarak, bu konsolosluğa taşınacaktır, şimdi çapraz bulut sağlayıcılarını kesmek için v1.0'dır.
Modüller
Önceden dahili modüller oluşturup kullandık. Yine de durum bu, ancak Terraform kayıt defterinin gelişi ve büyümesiyle bunları en azından bir temel olarak kullanmaya çalışıyoruz.
Dosya yapısı
Yeni konum, yalnızca iki infx ortamıyla çok daha basit bir sınıflandırmaya sahiptir - devve prod. Her birinin kendi değişkenleri ve çıktıları vardır ve yukarıda oluşturulan modüllerimizi yeniden kullanırız. remote_stateSağlayıcı ayrıca ortamları arasında yaratılan kaynakların çıktılarını paylaşmak yardımcı olur. Senaryomuz, farklı Azure kaynak gruplarındaki alt etki alanlarından genel olarak yönetilen bir TLD'ye yöneliktir.
├── main.tf
├── dev
│ ├── main.tf
│ ├── output.tf
│ └── variables.tf
└── prod
├── main.tf
├── output.tf
└── variables.tf
Planlama
Yine, dağıtılmış bir ekibin ekstra zorluklarıyla, artık terraform plankomut çıktımızı her zaman kaydediyoruz . planVe applyaşama arasında bazı değişiklikler riski olmadan neyin çalıştırılacağını inceleyebilir ve bilebiliriz (kilitlemenin buna yardımcı olmasına rağmen). Olasılıkla düz metin "gizli" değişkenler içerebileceğinden bu plan dosyasını silmeyi unutmayın.
Genel olarak Terraform'dan çok memnunuz ve eklenen yeni özelliklerle öğrenmeye ve geliştirmeye devam ediyoruz.