- Kod olarak altyapı ve Terraform nedir?
- Başlamadan önce hangi bilgiler gerekir?
- Adım adım: ilk altyapıdan ekip akışına
- State yönetimi: en çok hata burada çıkar
- Modüller, gelişmiş HCL ve çok bulutlu yaklaşım
- Örnek senaryo: üç ortamlı bir uygulama
- Sık yapılan hatalar
- Mindset programlarında nerede çalışılır?
- Sık sorulan sorular
Terraform ile Altyapı Otomasyonu: Kod Olarak Altyapı Rehberi
Terraform ile altyapıyı kodla tanımlamanın adımları: HCL, state yönetimi, modüller, CI/CD akışı, sık hatalar ve başlangıçtan ileriye öğrenme yolu.
Kod olarak altyapı ve Terraform nedir?
Kod olarak altyapı (Infrastructure as Code, IaC), sunucu, ağ, veritabanı ve depolama gibi kaynakları arayüzden elle tıklayarak değil, dosyalarda tanımlayarak kurma yaklaşımıdır. Terraform bu yaklaşımın en yaygın araçlarından biridir. HCL adlı bildirimsel bir dille "şu kaynaklar olsun" dersiniz; Terraform mevcut durumla istenen durumu karşılaştırır ve farkı uygular.
Bildirimsel olması önemlidir: adımları değil sonucu yazarsınız. Aynı dosyayı tekrar çalıştırdığınızda zaten istenen durumda olan kaynaklara dokunulmaz. Bu, altyapının sürüm kontrolünde tutulmasını, değişikliklerin gözden geçirilmesini ve aynı ortamın test, hazırlık ve üretim için tekrar üretilmesini mümkün kılar.
Başlamadan önce hangi bilgiler gerekir?
Terraform'u verimli kullanmak için önce şu zeminlere ihtiyaç vardır:
- Bir bulut sağlayıcısının temel kavramları: sanal makine, sanal ağ, alt ağ, güvenlik grubu, depolama, kimlik ve yetki.
- Komut satırı ve sürüm kontrolü (Git) alışkanlığı.
- Ağ temelleri: IP aralıkları, yönlendirme ve güvenlik duvarı mantığı.
Terraform bir bulutu bilmenin yerine geçmez. Hangi kaynağın ne işe yaradığını bilmeden yazdığınız kod, hatalı yapılandırmayı hızla ve tekrar tekrar üretir. Önce el ile küçük bir ortam kurup ne yaptığınızı anlamak, sonra aynısını kodla tanımlamak sağlam bir öğrenme yoludur.
Adım adım: ilk altyapıdan ekip akışına
Bir Terraform çalışması tipik olarak şu sırayı izler:
- Sağlayıcıyı tanımlayın: Hangi bulut ya da hizmetle konuşacağınızı ve kimlik doğrulama biçimini belirtin.
- Kaynakları yazın: Sanal ağ, alt ağ, bir sanal makine gibi küçük bir küme ile başlayın.
- Değişken ve çıktı kullanın: Ortama göre değişen değerleri değişkene, diğer kodların ihtiyaç duyacağı bilgileri çıktıya taşıyın.
- Planı okuyun: Uygulamadan önce Terraform'un ne ekleyip değiştireceğini gösteren planı satır satır inceleyin.
- Uygulayın ve durumu saklayın: Kurulan kaynakların kaydı state dosyasında tutulur.
- Modüllere bölün: Tekrar eden yapıları (örneğin standart bir ağ) modül haline getirin.
- Otomasyona alın: Plan ve uygulamayı CI/CD hattında, onay adımlarıyla çalıştırın.
İlk denemede küçük tutun: tek bir sanal ağ ve bir sanal makine kurun, planı okuyun, uygulayın, sonra değişkenlerden birini değiştirip planın yalnızca o farkı gösterdiğini doğrulayın. Son olarak kaynakları kaldırarak deneme ortamını temizleyin. Bu döngü, bildirimsel mantığı ve planın okunmasının önemini en hızlı gösteren alıştırmadır.
State yönetimi: en çok hata burada çıkar
State dosyası, Terraform'un hangi gerçek kaynağın hangi koda karşılık geldiğini bildiği defterdir. Kaybolursa ya da bozulursa Terraform var olan kaynakları tanımaz, yenisini kurmaya veya silmeye çalışabilir. Bu yüzden state'i yerel bilgisayarda tutmak yalnızca öğrenme aşamasında kabul edilebilir.
Ekip çalışmasında state uzak bir backend'de tutulur. İyi bir backend iki şeyi sağlar: aynı anda iki kişinin state'i değiştirmesini engelleyen kilit mekanizması ve geçmiş sürümlere dönebilme. State içinde gizli değerler bulunabileceğinden erişimi sıkı yetkilendirin ve state dosyasını sürüm kontrolüne koymayın.
Büyük altyapıyı tek state'te toplamak da risklidir: bir hata her şeyi etkiler. Ortam ve uygulama sınırlarına göre state'leri bölmek, değişikliğin etki alanını küçültür.
Modüller, gelişmiş HCL ve çok bulutlu yaklaşım
Kod büyüdükçe tekrar kaçınılmaz olur. Modül, ilgili kaynakları bir paket halinde adlandırıp farklı yerlerde yeniden kullanmanızı sağlar. İyi modül, dışarıya az sayıda net değişken sunar ve içindeki ayrıntıyı saklar. Aşırı esnek modül ise kullanımı zorlaştırır.
Gelişmiş HCL tarafında döngüler (count, for_each), koşullu ifadeler, dinamik bloklar ve yerleşik fonksiyonlar vardır. Amaç kodu kısaltmak değil, aynı yapının farklı ortamlarda tutarlı üretilmesini sağlamaktır. Okunabilirliği bozacak kadar zekice yazılan kod bakım borcuna dönüşür.
Birden fazla bulut ya da hizmet kullanan kurumlar, aynı araçla farklı sağlayıcıları yönetebilir. Burada asıl zorluk araç değil, her bulutun kimlik, ağ ve adlandırma kurallarının farklı olmasıdır; ortak bir standart ve modül yapısı belirlemek gerekir. Politika ve uyumluluk otomasyonu ise yanlış yapılandırmaları (örneğin herkese açık depolama) uygulamadan önce yakalamak için kullanılır.
Örnek senaryo: üç ortamlı bir uygulama
Örneğin bir yazılım ekibi geliştirme, test ve üretim ortamlarını elle kuruyor ve ortamlar zamanla birbirinden ayrışıyor. Ekip önce üretimdeki yapıyı inceler, ortak olan parçaları (ağ, veritabanı, uygulama sunucuları) modüllere ayırır. Her ortam için ayrı bir değişken dosyası ve ayrı bir state tanımlar.
Kod Git deposuna alınır. Bir değişiklik önerisi açıldığında CI hattı planı üretir ve çıktıyı gözden geçirenlere gösterir. Onaydan sonra uygulama adımı çalışır. Üretimde manuel onay kapısı bulunur. Sonuçta yeni bir ortam gerektiğinde ekip değişken dosyasını kopyalayıp planı çalıştırır; ortamlar aynı koddan türediği için farklılaşma azalır.
Sık yapılan hatalar
- State'i yerelde ve tek kişide tutmak: Ekip çalışmasında çakışma ve veri kaybı doğurur.
- Planı okumadan uygulamak: Yanlışlıkla bir kaynağı silip yeniden kurmak üretimde kesintiye yol açabilir.
- Gizli bilgiyi koda yazmak: Parola ve anahtarları değişken değeri olarak depoya koymak risktir; gizli bilgi yönetim hizmetlerinden okunmalıdır.
- Elle değişikliği karıştırmak: Konsoldan elle yapılan değişiklik koddan sapma yaratır (drift). Değişiklik yalnız kod üzerinden yapılmalıdır.
- Sürüm sabitlememek: Sağlayıcı ve Terraform sürümlerini sabitlemeyen proje, bir güncellemeyle beklenmedik biçimde kırılabilir.
- Modülleri erken soyutlamak: İhtiyaç ortaya çıkmadan genel modül yazmak karmaşıklık ekler.
Mindset programlarında nerede çalışılır?
Mindset'in Terraform ile Altyapı Otomasyonu programı şu modülleri içerir: Durum Yönetimi ve Backend, Terraform Temelleri ve HCL Dili, Modüler Terraform Mimarisi, Gelişmiş HCL ve Fonksiyonlar, Politika ve Uyumluluk Otomasyonu, CI/CD ile Terraform İş Akışları, Çok Bulutlu Terraform Stratejisi. Bu sayfadaki konu başlıklarının her biri bu modül adlarıyla örtüşür.
İlgili Mindset programı
Terraform ile Altyapı Otomasyonu
Sık sorulan sorular
Terraform ile Ansible aynı şey mi?
Hayır. Terraform altyapı kaynaklarını (ağ, sanal makine, veritabanı) kurmaya, Ansible ise kurulu sunucuların içindeki yazılım ve yapılandırmayı yönetmeye daha uygundur. Birçok ekip ikisini birlikte kullanır: önce Terraform ile sunucu, sonra Ansible ile yapılandırma.
Terraform öğrenmek için programcı olmak gerekir mi?
Gerekmez. HCL, genel amaçlı bir programlama dili değil bildirimsel bir tanım dilidir. Ancak bulut kavramlarını, komut satırını ve Git'i bilmek ciddi avantaj sağlar. Sistem yöneticiliği geçmişi olanlar için geçiş genellikle rahattır.
Terraform state dosyasını neden uzak depolarız?
Ekip üyelerinin aynı güncel state'i görmesi, aynı anda değişiklik yapılmasını kilitle engellemek ve yedek geçmişi tutmak için. Yerel state, tek kişilik deneme için uygundur; ortak projede veri kaybı ve çakışma riski taşır.
Drift nedir, nasıl önlenir?
Drift, gerçek altyapının koddaki tanımdan sapmasıdır; genellikle konsoldan elle yapılan değişikliklerle oluşur. Örneğin biri acil bir güvenlik kuralını konsoldan açarsa, kod bunu bilmez ve bir sonraki uygulamada kural geri alınabilir. Değişikliklerin yalnız kod üzerinden yapılması, düzenli plan çalıştırarak farkları görmek ve yetkileri kısıtlamak sapmayı azaltır.