Altyapı Kodlaması (Infrastructure as Code - IaC) Temelleri

Bir sunucunun nasıl oluşturulduğunu yalnız onu kuran kişi biliyorsa, o altyapı gerçekte ne kadar yönetilebilir kabul edilebilir? On yıllık yazılım, DevOps ve bulut altyapısı deneyimimde en fazla zaman kaybettiren sorunların başında elle yapılan ve daha sonra kimsenin tam olarak hatırlamadığı altyapı değişikliklerinin geldiğini gördüm. Altyapı Kodlaması (Infrastructure as Code - IaC) Temelleri bu problemi sunucu, ağ, güvenlik politikası ve bulut servislerini kodla tanımlayarak çözmeye çalışan sistematik bir yaklaşım sunar. Bu rehberde Infrastructure as Code IaC nedir ve nasıl uygulanır, Terraform ile Infrastructure as Code altyapısı nasıl kurulur ve IaC ile bulut altyapısı versiyonlama CI/CD ve otomatik deployment nasıl yapılır sorularını gerçek operasyon ihtiyaçları üzerinden ele alacağız. Terraform Ansible Pulumi ve CloudFormation karşılaştırması, state yönetimi, drift, güvenlik, test, GitOps, platform engineering ve kurumsal Infrastructure as Code ve Terraform kurulum hizmeti gibi başlıklar sayesinde yalnız bir IaC aracı kullanmayı değil, sürdürülebilir altyapı yönetim kültürü oluşturmayı hedefleyeceğiz.

Infrastructure as Code (IaC) Nedir?

Infrastructure as Code, sunucu, ağ, veritabanı, load balancer, IAM rolü ve benzeri altyapı bileşenlerini elle oluşturmak yerine makine tarafından okunabilir kod veya yapılandırma dosyalarıyla tanımlama yaklaşımıdır. Temel amaç, altyapının nasıl görünmesi gerektiğini tekrar üretilebilir ve gözden geçirilebilir biçimde kaydetmektir. Bu kod Git gibi bir versiyon kontrol sisteminde tutulabilir, değişiklikler pull request üzerinden incelenebilir ve CI/CD pipeline aracılığıyla kontrollü biçimde uygulanabilir. Böylece cloud console üzerinde yapılan ve zamanla unutulan ayarlar yerine ekip tarafından görülebilen açık bir teknik kaynak oluşur. Altyapı Kodlaması (Infrastructure as Code - IaC) Temelleri açısından en önemli fikir, altyapının tek seferlik kurulum işi değil sürekli yönetilen bir yazılım varlığı olarak ele alınmasıdır.

Altyapıyı Kod Olarak Yönetmek Ne Demektir?

Altyapıyı kod olarak yönetmek, bir sanal makinenin boyutunu, network subnet'ini, firewall kuralını veya storage ayarını elle tıklamak yerine dosyada tanımlamak anlamına gelir. Kod değiştirildiğinde yapılacak altyapı değişikliği önceden görülebilir ve başka ekip üyeleri tarafından incelenebilir. Aynı kod geliştirme, staging ve production ortamlarında farklı parametrelerle tekrar kullanılabilir. Böylece “production neden development ortamından farklı?” sorusuna tahminle değil repository üzerinden cevap verilebilir. Pratikte IaC, altyapının bilgi olarak kişilerin hafızasında kalmasını engelleyip ekip tarafından paylaşılabilir hale getirir.

Geleneksel Manuel Altyapı Yönetimi Nasıl Çalışır?

Geleneksel modelde sistem yöneticisi veya geliştirici cloud console, SSH oturumu ya da yönetim paneli üzerinden kaynakları tek tek oluşturabilir. İşlem adımları dokümante edilmezse aynı ortamın yeniden kurulması kişinin hafızasına bağımlı hale gelir. Birkaç sunuculuk küçük sistemde bu yöntem hızlı görünebilir, fakat kaynak sayısı arttıkça tekrar üretilebilirlik zorlaşır. Acil bir değişiklik daha sonra kalıcı konfigürasyona yansıtılmadığında ortamlar arasında fark oluşmaya başlar. Bu nedenle manuel yönetim kısa vadede kolay görünse de büyüyen sistemlerde audit, recovery ve standartlaşma açısından ciddi operasyon yükü oluşturur.

ClickOps Nedir?

ClickOps, bulut kaynaklarının web arayüzlerinde tıklanarak oluşturulması ve değiştirilmesi için kullanılan yaygın bir ifadedir. Küçük denemelerde veya hızlı prototiplerde kullanışlı olabilir, çünkü yeni kullanıcı cloud servislerini görsel olarak keşfedebilir. Sorun, bu yöntemin production altyapısının temel yönetim şekline dönüşmesiyle başlar. Console üzerinde yapılan değişikliğin neden yapıldığı, kim tarafından yapıldığı ve başka ortamlara uygulanıp uygulanmadığı zaman içinde belirsizleşebilir. IaC yaklaşımı ClickOps kullanımını tamamen yasaklamak yerine kalıcı altyapı değişikliklerinin repository içinde temsil edilmesini ve manuel müdahalelerin sonradan koda geri yazılmasını hedefler.

IaC'ın Temel Çalışma Mantığı

IaC araçları genellikle istenen altyapı durumunu koddan okuyup mevcut cloud ortamıyla karşılaştırır. Araç hangi kaynakların oluşturulması, değiştirilmesi veya kaldırılması gerektiğini hesaplar. Bu fark kullanıcıya plan veya preview biçiminde gösterilebilir. Onay sonrasında provider API'leri kullanılarak gerekli işlemler yapılır ve araç kendi yönetim bilgisini günceller. Bu model altyapı yönetimini tek seferlik komut çalıştırmaktan çıkarıp sürekli desired state ile actual state arasındaki farkı kontrol eden bir sürece dönüştürür.

Desired State

Desired state altyapının kod üzerinde nasıl olması gerektiğinin tanımıdır. Örneğin iki application server, bir private subnet ve yalnız HTTPS trafiğine açık bir load balancer istenebilir. Bu beklenti repository içindeki IaC dosyalarında temsil edilir. Kod değişikliği desired state'in değişmesi anlamına gelir. Ekip hangi altyapıyı hedeflediğini cloud console yerine öncelikle bu tanım üzerinden konuşur.

Actual State

Actual state cloud veya altyapı sağlayıcısında o anda gerçekten bulunan kaynakları temsil eder. Manuel değişiklik, başarısız deployment veya farklı bir stack nedeniyle actual state koddan ayrılabilir. IaC aracı provider API üzerinden bu durumu okuyabilir. State dosyası bazı araçlarda gerçek kaynaklarla kod arasındaki eşleşmeyi takip etmeye yardım eder. Gerçek durumun düzenli kontrol edilmesi drift problemlerinin erken fark edilmesini sağlar.

Reconciliation

Reconciliation istenen durumla gerçek durum arasındaki farkın giderilmesi sürecidir. Eksik kaynak oluşturulabilir, yanlış konfigürasyon güncellenebilir veya artık kodda bulunmayan kaynak silinebilir. Her farkın otomatik düzeltilmesi doğru olmayabilir, özellikle production ortamlarında önce plan incelemesi yapmak önemlidir. GitOps ve controller tabanlı sistemlerde reconciliation sürekli çalışan bir kontrol döngüsüne dönüşebilir. Bu yaklaşım altyapıyı yalnız deploy edilen değil sürekli doğrulanan bir sistem olarak görmeyi sağlar.

Infrastructure as Code Bir Programlama Dili midir?

Infrastructure as Code tek başına bir programlama dili değildir, altyapı yönetim yaklaşımıdır. Terraform HCL gibi alan odaklı bir dil kullanırken Pulumi Python, TypeScript veya Go gibi genel amaçlı dilleri kullanabilir. CloudFormation YAML veya JSON template'leri üzerinden deklaratif yapı sunabilir. Bu nedenle IaC kavramıyla kullanılan dil veya araç birbirinden ayrılmalıdır. Ekip aracı değiştirerek IaC yaklaşımını sürdürebilir, çünkü temel ilkeler versiyonlama, tekrar üretilebilirlik, otomasyon ve kontrollü değişiklik etrafında şekillenir.

Infrastructure as Code Neden Ortaya Çıktı?

Bulut platformları birkaç fiziksel sunucunun elle yönetildiği dönemden çok daha dinamik altyapılar ortaya çıkardı. Uygulamalar yüzlerce sanal makine, managed database, queue, storage ve network bileşeni kullanabilir. Bu kaynakları insan eliyle aynı standartta oluşturmak giderek zorlaştı. DevOps kültürü deployment hızını artırırken altyapının da uygulama kodu kadar hızlı ve kontrollü değişebilmesi gerektiğini gösterdi. IaC bu ihtiyaca, altyapı değişikliklerini kod tabanlı, tekrar üretilebilir ve otomasyona uygun hale getirerek cevap verdi.

Cloud Altyapılarının Büyümesi

Bulut servisleri altyapı oluşturma süresini dakikalara indirdi ve ekiplerin çok daha fazla kaynak kullanmasını mümkün hale getirdi. Buna karşılık kaynak sayısı arttıkça elle yönetim zorlaştı. Bir şirket farklı region, account ve environment içinde binlerce nesneye sahip olabilir. Her kaynağın hangi amaçla oluşturulduğunu yalnız console ekranından anlamak mümkün değildir. IaC kaynakları mantıksal dosya, module ve repository yapılarıyla organize ederek bu büyümeyi yönetilebilir hale getirir.

Manuel Provisioning Problemleri

Manuel provisioning aynı işlemin her seferinde farklı yapılmasına neden olabilir. Bir kişi security group'a gerekli iki portu açarken başka biri yanlışlıkla daha geniş erişim verebilir. Kurulum dokümanı güncel kalmadığında yeni environment oluşturmak günler sürebilir. Disaster recovery sırasında hangi sırayla hangi kaynağın oluşturulacağı bilinmeyebilir. IaC bu adımları çalıştırılabilir tanıma dönüştürerek kurulum sürecini kişisel deneyime daha az bağımlı hale getirir.

Environment Tutarsızlığı

Development, staging ve production ortamlarının birbirinden beklenmedik biçimde farklı olması birçok deployment probleminin kaynağıdır. Manuel değişiklikler küçük farklar oluşturarak zamanla environment parity'yi bozar. Aynı module farklı parametrelerle kullanıldığında temel altyapı yapısı standart kalabilir. Production'a özgü kapasite farkları açık değişkenlerle yönetilebilir. Böylece ortam farkları tesadüfi değil bilinçli ve kod üzerinde görülebilir hale gelir.

İnsan Hataları

İnsan hatasını tamamen ortadan kaldırmak mümkün değildir, ancak tekrarlanan manuel adımlar azaltılabilir. Yanlış region seçmek, hatalı subnet oluşturmak veya güvenlik ayarını eksik yapmak sık görülen örneklerdir. IaC değişiklikleri validate, test ve policy kontrollerinden geçirilebilir. Pull request review ikinci bir kişinin değişikliği görmesini sağlar. Böylece hata production'a ulaşmadan önce yakalanabilecek daha fazla kontrol noktası oluşur.

Tekrarlanabilir Deployment İhtiyacı

Aynı environment'ın gerektiğinde yeniden oluşturulabilmesi disaster recovery ve test açısından önemlidir. Manuel doküman bu amaç için çoğu zaman yeterli değildir, çünkü gerçek altyapıyla zaman içinde ayrışabilir. IaC kodu çalıştırılabilir tanım olduğu için daha güçlü tekrar üretilebilirlik sunar. Ephemeral test environment'ları aynı koddan oluşturulup iş bittikten sonra kaldırılabilir. Bu özellik altyapıyı sabit varlık yerine gerektiğinde üretilebilen kaynak olarak düşünmeyi kolaylaştırır.

DevOps ve Cloud-Native Sistemlerin Etkisi

DevOps ekipleri yazılım teslim süresini kısaltırken altyapı provisioning sürecinin ticket kuyruğunda günlerce beklemesi büyük darboğaz oluşturdu. Container, Kubernetes ve managed cloud servisleri altyapının daha sık değişmesine neden oldu. IaC bu değişiklikleri Git, CI/CD ve code review süreçleriyle uyumlu hale getirdi. Application ve platform ekipleri ortak delivery pratikleri kullanmaya başladı. Sonuç olarak altyapı yönetimi yalnız operasyon ekibinin arka plandaki işi olmaktan çıkarak yazılım teslim yaşam döngüsünün görünür parçasına dönüştü.

Infrastructure as Code Nasıl Çalışır?

IaC süreci kodda kaynakları tanımlamakla başlar ve provider API üzerinden gerçek ortamın değiştirilmesiyle devam eder. Araç resource bağımlılıklarını hesaplayarak hangi işlemin önce yapılması gerektiğini belirleyebilir. Plan aşaması kod ile mevcut kaynaklar arasındaki farkı gösterir. Apply aşaması onaylanan değişikliği cloud platformuna iletir. Bu süreçte state, provider version ve execution identity gibi ayrıntılar güvenilir deployment için önemli hale gelir.

Altyapıyı Kodla Tanımlama

İlk adım oluşturulacak resource'ların kod veya template içinde tanımlanmasıdır. Network CIDR, instance size veya database engine gibi özellikler configuration olarak yazılır. Tekrarlanan değerler variable ile parametreleştirilebilir. Ortak yapı module haline getirilebilir. Kod okunabilir tutulduğunda repository aynı zamanda altyapının güncel teknik dokümantasyonu görevini de görebilir.

Provider API'leri ile Haberleşme

IaC aracı doğrudan sanal makine üretmez, cloud provider veya platform API'sine istek gönderir. Terraform provider bu API ayrıntılarını resource modeli üzerinden soyutlar. Kullanılan identity gerekli izinlere sahip olmalıdır. Provider API rate limit veya servis hataları apply sürecini etkileyebilir. Bu nedenle retry davranışı ve provider version yönetimi gerçek operasyon tasarımının parçasıdır.

Dependency Graph Oluşturma

Bir compute instance subnet oluşmadan kurulamayabilir ve load balancer instance hazır olmadan tamamlanamayabilir. IaC araçları referanslardan dependency graph çıkarabilir. Bağımsız kaynaklar paralel oluşturularak deployment süresi kısalabilir. Gizli dependency'ler açıkça tanımlanmadığında race condition oluşabilir. Resource graph'i doğru modellemek güvenilir apply sürecinin temelidir.

Mevcut ve İstenen Durumu Karşılaştırma

Araç kodda tanımlanan configuration ile mevcut altyapı bilgisini karşılaştırır. Yeni resource, değişen attribute veya kaldırılacak nesne belirlenir. Bazı property değişiklikleri yerinde update edilebilirken bazıları resource replacement gerektirebilir. Bu fark plan çıktısında görünmelidir. Kullanıcı yalnız kaç kaynak değişeceğine değil değişikliğin nedenine ve business etkisine de bakmalıdır.

Change Plan Oluşturma

Plan veya preview apply öncesinde önerilen değişiklikleri gösterir. Resource deletion ve replacement özellikle dikkat edilmesi gereken sonuçlardır. CI pipeline plan çıktısını pull request'e ekleyebilir. Reviewer kod diff ile altyapı diff'ini birlikte inceleyebilir. Bu iki aşamalı yaklaşım doğrudan production apply yapılmasına göre çok daha güvenli değişiklik süreci oluşturur.

Değişiklikleri Uygulama

Apply aşamasında onaylanan değişiklik provider API üzerinden gerçekleştirilir. Execution identity yalnız gerekli yetkilere sahip olmalıdır. Production ortamında human approval veya policy gate kullanılabilir. Apply log'ları audit için saklanabilir. Başarısız deployment durumunda hangi kaynakların oluşturulduğu state ve cloud reality üzerinden kontrol edilmelidir.

State'i Güncelleme

Terraform benzeri araçlar kaynaklarla configuration arasındaki mapping'i state içinde takip eder. Apply tamamlandıkça resource ID ve bazı attribute değerleri state'e yazılır. State kaybı aracın mevcut kaynakları tanımasını zorlaştırabilir. Remote backend, locking ve backup production için bu nedenle önemlidir. State hassas veri içerebileceği için sıradan repository dosyası gibi ele alınmamalıdır.

IaC Workflow'un Temel Aşamaları

Sağlam IaC workflow yalnız apply komutundan oluşmaz. Scope belirleme, kod yazma, validation, plan review ve deployment sonrası doğrulama birlikte ele alınmalıdır. Monitoring ve reconciliation süreci değişiklik tamamlandıktan sonra da devam eder. Bu model altyapı değişikliğini yazılım release süreciyle benzer kalite kapılarından geçirir. Kurumsal ortamda aynı workflow bütün ekipler için ortaklaştırıldığında hem güvenlik hem operasyon hızı artar.

Scope

Önce hangi altyapı bileşeninin değişeceği belirlenmelidir. Bir network modülü ile bütün account kaynaklarını aynı değişiklikte ele almak gereksiz blast radius oluşturabilir. Scope küçük tutulduğunda review daha kolay olur. Değişiklik sahibi etkilenen servisleri önceden belirleyebilir. Ticket veya pull request açıklaması kapsamı görünür hale getirmelidir.

Author

Geliştirici veya platform mühendisi IaC değişikliğini kod olarak hazırlar. Module ve naming standard'larına uyması beklenir. Local secret veya environment-specific sabit değer koda yazılmamalıdır. Değişiklik mümkün olduğunda küçük commit'lere ayrılır. Author plan etkisini anlayabilecek kadar cloud resource davranışına hâkim olmalıdır.

Validate

Validate syntax ve temel configuration hatalarını apply öncesinde yakalar. Provider schema ile resource attribute'ları kontrol edilebilir. Bu aşama gerçek cloud deployment testinin yerine geçmez. CI içinde otomatik çalıştırılması hızlı geri bildirim sağlar. Validation hatası bulunan değişiklik review aşamasına geçmeden düzeltilebilir.

Init

Init çalışma dizinini provider ve backend kullanımı için hazırlar. Gerekli provider plugin'leri indirilir. Remote state backend bağlantısı yapılandırılabilir. Lock file dependency version tutarlılığını sağlar. CI worker her temiz ortamda init aşamasını tekrarlanabilir biçimde çalıştırabilmelidir.

Plan / Preview

Plan proposed infrastructure diff'i üretir. Kaç resource ekleneceği, değişeceği veya silineceği görülür. Reviewer beklenmedik replacement fark edebilir. Plan artifact saklanarak apply aşamasında aynı sonuç kullanılabilir. Hassas değerlerin log içinde görünmemesi için CI çıktısı dikkatle yönetilmelidir.

Review

Review yalnız syntax değil mimari ve güvenlik etkisini değerlendirir. Açık network rule veya fazla yetkili IAM rolü fark edilebilir. Resource deletion business owner onayı gerektirebilir. Module owner ilgili standartlara uygunluğu kontrol edebilir. Review checklist ekipler arasında tutarlı kalite sağlar.

Apply / Deploy

Onaylanan plan gerçek altyapıya uygulanır. Production apply yetkisi herkese verilmemelidir. CI identity OIDC gibi kısa ömürlü credential kullanabilir. Apply status merkezi log ve deployment kaydında görünmelidir. Başarısız işlem otomatik olarak körlemesine tekrar edilmemelidir.

Verify

Apply başarılı mesajı kullanıcı açısından sistemin sağlıklı olduğu anlamına gelmez. Network erişimi, health check veya service endpoint doğrulanmalıdır. Smoke test çalıştırılabilir. Security policy gerçekten etkin mi kontrol edilebilir. Post-deployment validation değişikliğin amaçlanan sonucu oluşturduğunu doğrular.

Monitor

Deployment sonrasında performans ve hata metric'leri izlenmelidir. Yeni instance type CPU davranışını değiştirebilir. IAM veya network değişikliği erişim hatası üretebilir. Alert spike release ile ilişkilendirilmelidir. Infrastructure telemetry code change ile birlikte değerlendirilir.

Reconcile

Son aşamada gerçek ortamın kodla uyumlu kalması sağlanır. Manuel değişiklik drift üretirse detection mekanizması bunu bildirir. Emergency change repository'ye backport edilir. Controller tabanlı sistemlerde reconciliation otomatik çalışabilir. Böylece Git ve altyapı gerçeği arasındaki ilişki sürekli korunur.

Deklaratif ve Imperatif IaC Arasındaki Fark

Deklaratif yaklaşım hedef durumun ne olması gerektiğini tanımlarken imperatif yaklaşım işlemlerin hangi sırayla yapılacağını tarif eder. Terraform gibi araçlar ağırlıklı olarak deklaratif modele dayanır. Script veya configuration management çözümleri daha fazla adım odaklı kontrol sunabilir. Her iki yaklaşımın da uygun kullanım alanları vardır. Ekip hangi modelin kullanıldığını anlamazsa idempotency, retry ve drift davranışını yanlış yorumlayabilir.

Declarative IaC Nedir?

Deklaratif IaC kullanıcıdan final state tanımını ister. Araç bu duruma ulaşmak için gerekli işlemleri hesaplar. Kullanıcı çoğu zaman API çağrılarının sırasını tek tek yazmaz. Dependency graph otomatik oluşturulabilir. Bu model cloud resource yaşam döngüsü yönetiminde güçlü tekrar üretilebilirlik sağlar.

“Ne Olmalı?” Yaklaşımı

Bu yaklaşım “üç application instance olmalı” ifadesine odaklanır. Hangi instance'ın önce oluşturulacağını araç belirleyebilir. Resource eksikse eklenir, fazla ise configuration'a göre kaldırılabilir. Kullanıcı işlemin ayrıntısından çok hedef mimariyi tanımlar. Reconciliation fikri deklaratif modelin doğal devamıdır.

Imperative IaC Nedir?

Imperative model yapılacak adımları sırayla tanımlar. Önce network oluştur, ardından subnet ekle ve sonra instance başlat gibi komutlar yazılabilir. Kullanıcı execution akışı üzerinde daha fazla kontrol sahibidir. Aynı script tekrar çalıştırıldığında güvenli davranması için özel kontroller gerekebilir. Provisioning dışındaki bakım ve configuration görevlerinde bu model bazen daha doğal olur.

“Nasıl Yapılmalı?” Yaklaşımı

Burada sonuç kadar işlem sırası da kodun parçasıdır. Script belirli command veya API çağrılarını çalıştırabilir. Hata sonrası hangi adımda kalındığı önem kazanır. Retry logic ayrıca tasarlanmalıdır. Bu yaklaşım özel migration veya tek seferlik operasyonlarda yararlı olabilir.

Programmatic IaC Nedir?

Programmatic IaC genel amaçlı programlama diliyle altyapı tanımlamayı ifade eder. Pulumi veya AWS CDK bu modele örnek verilebilir. Loop, condition ve function gibi dil özellikleri doğal olarak kullanılabilir. Type system ve mevcut test framework'lerinden yararlanılabilir. Buna karşılık altyapı kodu normal application code kadar serbest hale geldiğinde okunabilirlik ve determinism dikkatle korunmalıdır.

Declarative Yaklaşımın Avantajları

Deklaratif configuration hedef durumu açık biçimde gösterir. Plan çıktısı mevcut ve istenen durum arasındaki farkı kolay hesaplayabilir. Idempotent davranış araç tarafından büyük ölçüde desteklenebilir. Code review sırasında resource intent daha net görülebilir. Cloud provisioning için bu nedenle çok yaygın bir modeldir.

Imperative Yaklaşım Ne Zaman Gereklidir?

Altyapı dışında özel bootstrap işlemleri veya sıralı migration adımları gerekebilir. Legacy sistem API'si deklaratif resource modeli sunmayabilir. One-off data migration script'i bu yönteme daha uygun olabilir. İşlemin state'i açıkça tutulmalıdır. Mümkün olduğunda tekrar çalıştırma güvenliği eklenmelidir.

Hybrid Yaklaşım Kullanılabilir mi?

Çoğu production sistemi zaten hybrid model kullanır. Terraform network ve compute oluştururken Ansible işletim sistemi configuration'ını uygulayabilir. Application migration script'i deployment sonrasında çalışabilir. Sınırlar açık tutulursa araçlar birbirini tamamlar. Aynı resource'un iki farklı araç tarafından yönetilmesi ise çakışma ve drift riskini artırır.

Idempotency Nedir?

Idempotency aynı IaC işleminin birden fazla çalıştırılmasının ilk başarılı çalıştırmadan sonra beklenmedik ek değişiklik oluşturmamasıdır. Altyapı otomasyonunda retry ve tekrar deployment için bu özellik kritik öneme sahiptir. Her çalışmada yeni bir security rule ekleyen script idempotent değildir. İstenen rule zaten varsa değişiklik yapmayan işlem ise idempotent davranır. Güvenilir IaC sistemi tekrar çalıştırılabilen ve sonunda öngörülebilir state üreten işlem modeli hedeflemelidir.

Aynı IaC Kodunu Birden Fazla Kez Çalıştırmak

İlk apply gerekli kaynakları oluşturabilir. İkinci apply configuration değişmediyse ideal olarak “değişiklik yok” sonucu vermelidir. Sürekli küçük fark çıkıyorsa provider davranışı veya nondeterministic değer araştırılmalıdır. Timestamp ile resource name üretmek gibi yöntemler planı her çalışmada değiştirebilir. Stable configuration operasyon güvenini artırır.

Idempotent ve Non-Idempotent İşlemler

Idempotent işlem mevcut durumu kontrol edip yalnız gerekli değişikliği yapar. Non-idempotent script her çalışmada yeni yan etki oluşturabilir. Örneğin dosyaya aynı satırı tekrar tekrar eklemek istenmeyen sonuç üretir. Configuration management araçları çoğu task için idempotent module sağlar. Custom script yazıldığında aynı özellik geliştirici tarafından düşünülmelidir.

Idempotency Neden Güvenilir Deployment İçin Önemlidir?

CI worker network hatası nedeniyle apply sonucunu net göremeyebilir. İşlem güvenli biçimde tekrar edilebiliyorsa recovery kolaylaşır. Manuel düzeltme ihtiyacı azalır. Disaster recovery runbook daha basit hale gelir. Idempotency otomasyonun hata anında da güvenilir kalmasını sağlayan temel engineering ilkesidir.

IaC ile Configuration Management Arasındaki Fark

Infrastructure provisioning kaynakları oluştururken configuration management çoğunlukla oluşturulmuş sunucuların iç ayarlarını yönetir. Terraform veya OpenTofu VPC, VM ve database yaratabilir. Ansible işletim sistemi paketi, dosya ve servis configuration'ını uygulayabilir. Modern immutable infrastructure yaklaşımında server configuration image build aşamasına taşındığı için sınır daha da değişebilir. Araç seçiminde “hangi ürün daha iyi?” sorusundan önce hangi yaşam döngüsü probleminin çözüldüğü belirlenmelidir.

Infrastructure Provisioning

Provisioning compute, network ve managed service kaynaklarını oluşturur. Resource lifecycle cloud API üzerinden yönetilir. State ve dependency graph önemlidir. Terraform bu alanda güçlü bir örnektir. Kaynak kaldırıldığında IaC kodu da güncellenmelidir.

Configuration Management

Configuration management mevcut makinenin işletim sistemi ve uygulama ayarlarını yönetebilir. Package installation ve service configuration yaygın örneklerdir. Agent veya agentless model kullanılabilir. Idempotent task aynı sunucuda güvenli tekrar sağlar. Dynamic inventory cloud kaynaklarıyla entegre edilebilir.

Terraform/OpenTofu ile Ansible Arasındaki Temel Fark

Terraform ve OpenTofu resource graph ve state üzerinden altyapı lifecycle yönetimine odaklanır. Ansible task ve playbook modeliyle configuration ve orchestration tarafında güçlüdür. Ansible cloud resource da oluşturabilir fakat state yaklaşımı farklıdır. Terraform sunucuyu oluşturup Ansible configuration uygulayabilir. Sorumluluk sınırları açık olduğunda birlikte kullanımları oldukça pratiktir.

IaC ve Ansible Birlikte Kullanılabilir mi?

Evet, farklı katmanları yönetmeleri halinde birlikte kullanılabilirler. Terraform instance ve network oluşturabilir. Output olarak IP veya inventory bilgisi Ansible'a aktarılabilir. Ansible işletim sistemi configuration'ını tamamlayabilir. Aynı firewall resource'un iki araç tarafından yönetilmesinden kaçınmak gerekir.

Immutable Infrastructure Yaklaşımı

Immutable model çalışan sunucuyu uzun süre değiştirmek yerine yeni image üretip eski instance'ı yenisiyle değiştirmeyi hedefler. Packer benzeri image build araçları kullanılabilir. Configuration drift azalır. Rollback eski image version'a dönmekle kolaylaşabilir. Stateful workload'lar ayrı veri katmanı gerektirir.

Infrastructure as Code'un Avantajları

IaC'ın en büyük faydası altyapının tekrar üretilebilir ve gözden geçirilebilir hale gelmesidir. Değişiklikler Git geçmişinde saklanabilir ve aynı module farklı environment'larda kullanılabilir. Automated validation ve security scan production riskini azaltır. Disaster recovery sırasında sıfırdan ortam kurma süresi önemli ölçüde kısalabilir. Self-service platformlarla birleştiğinde application ekipleri standart altyapıyı ticket beklemeden güvenli biçimde oluşturabilir.

Tekrarlanabilirlik

Aynı code aynı temel mimariyi yeniden oluşturabilir. Manuel kurulum farkları azalır. Yeni region açmak daha kolay hale gelir. Test environment kısa sürede üretilebilir. Recovery runbook çalıştırılabilir kodla desteklenir.

Tutarlılık

Standart module naming, tagging ve security configuration sağlar. Development ve production aynı temel yapıyı paylaşabilir. Manuel farklılıklar drift detection ile görünür olur. Compliance policy merkezi uygulanabilir. Ekipler altyapıyı ortak kalıplarla yönetir.

Daha Hızlı Provisioning

Elle saatler süren işlemler pipeline üzerinden dakikalarda tamamlanabilir. Onay sonrası otomatik deployment gerçekleşir. Paralel resource creation süreyi azaltabilir. Kullanıcı ticket beklemek yerine self-service workflow kullanabilir. Hız artışı kalite kontrolleri kaldırılmadan sağlanabilir.

Version Control

Her infrastructure change commit geçmişinde görünür. Eski version incelenebilir. Kimin hangi değişikliği yaptığı audit edilebilir. Branch ve tag release yönetimini destekler. Rollback için önceki configuration referans alınabilir.

Code Review

Infrastructure change başka mühendis tarafından incelenebilir. Security veya cost etkisi apply öncesinde fark edilebilir. Module standard'larına uyum kontrol edilir. Bilgi paylaşımı artar. Kritik değişiklik tek kişinin kararına daha az bağımlı olur.

Auditability

Git history ve CI deployment log'u güçlü audit izi sağlar. Plan artifact hangi değişikliğin önerildiğini gösterir. Approval kaydı saklanabilir. Cloud audit log gerçek API işlemini doğrular. Compliance incelemesi daha sistematik hale gelir.

Disaster Recovery

Kod infrastructure topology'yi yeniden oluşturabilir. Manual setup dokümanına bağımlılık azalır. Multi-region template hazır tutulabilir. Ancak IaC veritabanı içindeki veriyi geri getirmez. Backup ve restore planı ayrıca gereklidir.

Otomatik Test

Syntax ve lint kontrolü hızlı çalışır. Policy scanner yanlış network ayarını yakalayabilir. Integration test gerçek test environment oluşturabilir. Post-deploy health check eklenebilir. Infrastructure change software release kadar test edilebilir hale gelir.

Self-Service Infrastructure

Platform ekibi güvenli module ve template sunabilir. Application geliştiricisi gerekli parametreleri vererek ortam oluşturur. IAM ve network standard'ları otomatik uygulanır. Ticket sayısı azalır. Merkezi governance korunurken ekip bağımsızlığı artar.

Daha Kolay Multi-Environment Yönetimi

Aynı module dev, staging ve production için kullanılabilir. Environment farkları parameter üzerinden görünür olur. Account isolation uygulanabilir. Pipeline promotion süreci ortaklaşır. Environment parity daha kolay korunur.

Infrastructure as Code'un Dezavantajları ve Riskleri

IaC güçlü otomasyon sağlarken yanlış kullanıldığında çok hızlı biçimde büyük hasar da oluşturabilir. Hatalı bir plan yüzlerce kaynağı silebilir veya güvenlik ayarını genişletebilir. State, provider version ve module bağımlılıkları ayrıca yönetilmelidir. Araç kullanmak tek başına iyi mimari veya güvenlik garantisi sağlamaz. Bu nedenle IaC adoption eğitim, review, test, access control ve blast radius yönetimiyle birlikte ele alınmalıdır.

Öğrenme Eğrisi

Cloud resource davranışını ve IaC aracını birlikte öğrenmek zaman alır. HCL syntax öğrenmek tek başına yeterli değildir. Network, IAM ve state bilgisi gerekir. İlk module tasarımları deneyim kazandıkça değişebilir. Küçük projelerle başlamak öğrenme sürecini daha güvenli hale getirir.

Yanlış Kodun Büyük Blast Radius Oluşturması

Tek configuration yüzlerce resource yönetebilir. Yanlış değişken kritik subnet'i silebilir. Plan review ve policy gate önemlidir. State küçük bileşenlere ayrılabilir. Production apply yetkisi kontrollü tutulmalıdır.

State Yönetimi

State bazı IaC araçlarında merkezi bir bileşendir. Locking olmadan eş zamanlı apply çakışabilir. Hassas bilgiler state içine girebilir. Backup ve access control gerekir. State recovery prosedürü test edilmelidir.

Provider ve Module Bağımlılıkları

IaC kodu provider implementation davranışına bağlıdır. Version upgrade breaking change getirebilir. Module yeni major version yayınlayabilir. Lock file ve version pinning kontrollü güncelleme sağlar. Dependency değişikliği normal application dependency kadar dikkatle ele alınmalıdır.

Tool Lock-In

Belirli IaC aracına özgü syntax ve state migration maliyeti oluşturur. Terraform module doğrudan CloudFormation template'i değildir. İş mantığının çok fazla araca özgü extension kullanması geçişi zorlaştırır. Yine de her abstraction maliyetsiz değildir. Portability hedefi gerçek iş ihtiyacına göre belirlenmelidir.

Cloud Provider API Değişiklikleri

Provider resource modeli cloud API'ye dayanır. Deprecated API yeni provider sürümünde davranış değişikliği oluşturabilir. Version upgrade düzenli yapılmalıdır. Uzun süre update edilmeyen provider migration riskini büyütür. Changelog ve plan output dikkatle incelenmelidir.

IaC'ın Yanlış Güven Hissi Oluşturması

Kodda bulunması bir configuration'ın doğru olduğu anlamına gelmez. Public storage bucket yanlış biçimde IaC ile mükemmel tekrar üretilebilir. Güvenlik test ve policy gerekir. Cloud audit ve runtime monitoring devam etmelidir. IaC kalite kontrollerini mümkün kılar, fakat onların yerini kendiliğinden doldurmaz.

En Popüler Infrastructure as Code Araçları

IaC ekosisteminde tek bir araç bütün kullanım alanlarında en iyi değildir. Terraform ve OpenTofu multi-cloud resource yönetiminde güçlü bir provider ekosistemine sahiptir. Pulumi genel amaçlı programlama dillerini tercih eden ekipler için farklı bir geliştirme modeli sunar. CloudFormation, CDK ve Bicep cloud-native seçeneklerdir. Crossplane Kubernetes control plane yaklaşımını infrastructure provisioning ile birleştirirken Ansible configuration ve orchestration alanında değer sağlar.

Terraform

Terraform HCL tabanlı deklaratif IaC aracıdır. Provider ekosistemi çok sayıda cloud ve SaaS servisini destekler. Plan ve state workflow'u temel kullanım modelidir. Module sistemi reusable infrastructure oluşturmayı sağlar. Güncel çekirdek Terraform sürümleri HashiCorp'un source-available lisans modeli kapsamında değerlendirilmelidir.

OpenTofu

OpenTofu Terraform ekosisteminden türeyen açık kaynak IaC projesidir. HCL ve Terraform workflow'una yakın kullanım deneyimi sunar. Topluluk odaklı governance modeli önemli farklarından biridir. Terraform kod tabanından migration birçok senaryoda düşük sürtünmeyle yapılabilir. Provider ve module compatibility proje bazında doğrulanmalıdır.

Pulumi

Pulumi altyapıyı Python, TypeScript, Go ve benzeri genel amaçlı dillerle tanımlamaya izin verir. Type system ve mevcut package ecosystem kullanılabilir. Programmatic abstraction güçlüdür. State ve provider model yine önemli rol oynar. Yazılım geliştirici ağırlıklı ekipler için doğal bir geliştirme deneyimi sunabilir.

AWS CloudFormation

CloudFormation AWS'nin native deklaratif infrastructure deployment servisidir. YAML veya JSON template üzerinden resource tanımlanabilir. Stack değişiklikleri AWS içinde yönetilir. Change Sets apply öncesinde değişiklikleri gösterebilir. Multi-cloud ihtiyacı bulunmayan AWS odaklı ekiplerde güçlü seçenek olabilir.

AWS CDK

AWS CDK genel amaçlı programlama dilleriyle AWS infrastructure tanımlamayı sağlar. Kod sonunda CloudFormation template'lerine dönüştürülür. Construct abstraction reusable component oluşturmayı kolaylaştırır. CloudFormation deployment modelinin sınırları devam eder. AWS ecosystem içinde programmatic IaC tercih eden ekipler için uygundur.

Azure Bicep

Bicep Azure kaynaklarını deklaratif biçimde tanımlamak için geliştirilen domain-specific dildir. ARM template'lerine göre daha okunabilir syntax sunmayı amaçlar. Azure platform özelliklerine hızlı erişim sağlar. State dosyası yerine Azure Resource Manager gerçekliği temel alınır. Azure ağırlıklı kurumlarda cloud-native seçenek olarak değerlendirilebilir.

Google Cloud Infrastructure Manager

Google Cloud Infrastructure Manager, Terraform configuration kullanarak Google Cloud kaynaklarının yönetilmesine yönelik managed bir altyapı yaklaşımı sunar. Terraform tabanlı deployment lifecycle'ını Google Cloud içinde işletmeyi kolaylaştırabilir. Merkezi execution ve deployment yönetimi sağlar. Google Cloud kullanıcısı Terraform kodunu platform yönetimiyle birleştirebilir. Özellikle Deployment Manager sonrası Google Cloud'un yöneldiği managed IaC seçeneklerinden biridir.

Google Deployment Manager Neden Legacy Bir Teknolojidir?

Google Cloud Deployment Manager uzun süre YAML, Jinja ve Python template'leri üzerinden altyapı deployment hizmeti sundu. Google Cloud resmi dokümantasyonuna göre hizmet 1 Nisan 2026 itibarıyla destek dışı duruma geçti ve 2027 içinde tamamen kapatılacak bir geçiş takvimine sahip. Mevcut kullanıcılar migration planlamak zorunda olduğu için yeni IaC projelerinde tercih edilmesi doğru değildir. Google, Infrastructure Manager ve başka desteklenen altyapı araçlarına geçişi yönlendirmektedir. Bu nedenle legacy ifadesi yalnız teknolojik yaşla değil ürünün resmi yaşam döngüsü ve destek durumuyla ilgilidir.

Crossplane

Crossplane Kubernetes control plane modelini cloud resource provisioning için genişletir. Infrastructure resource'ları custom resource olarak temsil edilebilir. Reconciliation sürekli çalışır. Platform engineering ve self-service API senaryolarında güçlüdür. Kubernetes operasyon deneyimi gerektirdiği için her ekip için ilk IaC aracı olmak zorunda değildir.

Ansible

Ansible YAML playbook üzerinden configuration ve orchestration sağlar. Cloud module'leriyle infrastructure provisioning de yapabilir. Agentless model yaygın kullanım avantajıdır. Terraform benzeri resource state graph yaklaşımından farklıdır. İşletim sistemi configuration ve day-two operasyonlarında oldukça etkilidir.

Hangi IaC Aracı Hangi Senaryoda Kullanılmalı?

Multi-cloud ve geniş provider ihtiyacında Terraform veya OpenTofu güçlü adaylardır. Genel amaçlı dil tercih ediliyorsa Pulumi değerlendirilebilir. Tek cloud üzerinde native service kullanımına ağırlık veriliyorsa CloudFormation, CDK veya Bicep mantıklı olabilir. Kubernetes tabanlı platform API hedefinde Crossplane öne çıkabilir. Araç seçimi lisans, ekip yetkinliği, state modeli, testing ve uzun vadeli operasyon gereksinimlerinin birlikte değerlendirilmesiyle yapılmalıdır.

Terraform Nedir?

Terraform, altyapı kaynaklarını HCL configuration dosyaları üzerinden tanımlayan deklaratif IaC aracıdır. Provider modeli AWS, Azure, Google Cloud, Kubernetes ve birçok SaaS platformuyla çalışmasına izin verir. Resource, data source, variable ve module kavramları configuration yapısının temelidir. State gerçek resource kimlikleriyle kod arasındaki ilişkiyi takip eder. Terraform ile Infrastructure as Code altyapısı nasıl kurulur sorusunun pratik cevabı init, validate, plan, apply ve güvenli state yönetimi etrafında şekillenir.

HashiCorp Configuration Language (HCL)

HCL altyapı configuration'ını okunabilir biçimde tanımlamak için kullanılan domain-specific dildir. Block ve attribute yapısı resource ilişkilerini açık hale getirir. Expression ve function desteği bulunur. Çok fazla dynamic abstraction okunabilirliği azaltabilir. Kodun amacı birkaç ay sonra başka mühendisin anlayabileceği kadar açık tutulmalıdır.

Terraform Providers

Provider Terraform ile hedef API arasında entegrasyon katmanıdır. AWS provider EC2 veya VPC gibi resource tiplerini sunabilir. Provider version davranışı configuration sonucunu etkileyebilir. Version constraint ve lock file kullanılmalıdır. Upgrade planlı test süreciyle yapılmalıdır.

Resources

Resource oluşturulacak veya yönetilecek altyapı nesnesidir. Virtual network, instance veya database örnek olabilir. Her resource type provider tarafından tanımlanır. Attribute reference dependency graph oluşturabilir. Resource lifecycle özelliği replacement davranışını etkileyebilir.

Data Sources

Data source mevcut external bilgiyi okumak için kullanılır. Önceden var olan subnet veya image ID bulunabilir. Yeni resource oluşturmaz. Query sonucu değişken olabileceği için plan zamanında farklılık yaratabilir. Stable lookup criteria kullanılmalıdır.

Variables

Variables module ve environment parametrelerini dışarıdan almayı sağlar. Region veya instance size örnek olabilir. Default değer kullanılabilir. Sensitive variable output ve log davranışı açısından işaretlenebilir. Secret'ın yalnız sensitive flag verilerek güvenli hale gelmediği unutulmamalıdır.

Outputs

Output module tarafından üretilen değeri dışarı sunar. Load balancer endpoint veya resource ID paylaşılabilir. Başka stack veya pipeline bu değeri kullanabilir. Sensitive output dikkatle yönetilmelidir. Çok fazla internal ayrıntıyı output etmek module coupling'i artırabilir.

Modules

Module tekrar kullanılabilir Terraform configuration paketidir. Network veya application platform standardı module içinde toplanabilir. Input ve output public interface oluşturur. Versioning consumer migration'ını kolaylaştırır. Her üç satırlık configuration için module oluşturmak gereksiz abstraction yaratabilir.

State

Terraform state configuration resource'ları ile gerçek altyapı object'leri arasındaki mapping'i tutar. Resource ID ve bazı computed attribute değerleri burada bulunur. Production için remote backend kullanılması yaygındır. State hassas veri içerebilir. Backup, locking ve yetkilendirme temel güvenlik gereksinimleridir.

Terraform Workflow

Terraform workflow initialization ile başlar ve plan review sonrasında apply ile devam eder. Validate configuration hatalarını erken yakalar. Destroy kaynakları kaldırmak için kullanılabilir ve production ortamında yüksek risk taşır. CI/CD pipeline bu komutları kontrollü kimliklerle çalıştırabilir. Workflow'un amacı komutları ezberlemek değil değişiklik yaşam döngüsünü güvenli hale getirmektir.

terraform init

terraform init provider ve module bağımlılıklarını hazırlar. Backend configuration başlatılır. Lock file üretilebilir veya güncellenebilir. Yeni checkout sonrasında ilk çalıştırılması gereken komuttur. CI ortamında temiz workspace üzerinde tekrar üretilebilir olmalıdır.

terraform validate

terraform validate configuration'ın yapısal olarak geçerli olup olmadığını kontrol eder. Provider API'ye gerçek kaynak oluşturma isteği göndermez. Syntax ve reference hatalarını yakalayabilir. CI için hızlı kontrol aşamasıdır. Policy veya runtime doğrulamasının yerine geçmez.

terraform plan

terraform plan önerilen infrastructure diff'i hesaplar. Add, change ve destroy işlemleri görülür. Replacement işareti özellikle incelenmelidir. Plan file kaydedilebilir. Production apply öncesinde review için en önemli çıktılardan biridir.

terraform apply

terraform apply değişiklikleri provider API üzerinden uygular. Interactive veya saved plan ile çalıştırılabilir. CI ortamında approval gate eklenebilir. Apply identity least privilege yetkiye sahip olmalıdır. Sonuç post-deployment test ile doğrulanmalıdır.

terraform destroy

terraform destroy yönetilen resource'ları kaldırmayı amaçlar. Ephemeral test environment için kullanışlıdır. Production ortamında çok yüksek blast radius oluşturabilir. Approval ve access policy ile korunmalıdır. Data resource'larda backup veya prevent_destroy benzeri korumalar değerlendirilmelidir.

OpenTofu Nedir?

OpenTofu, Terraform ekosisteminden türemiş açık kaynak Infrastructure as Code projesidir. HCL tabanlı configuration ve state yaklaşımı Terraform kullanıcılarına tanıdık gelir. Proje açık kaynak governance modeliyle geliştirilir. Terraform lisans değişiklikleri sonrasında topluluk ve farklı teknoloji şirketlerinin desteğiyle ayrı yol izlemeye başlamıştır. Kurumlar seçim yaparken yalnız syntax compatibility değil uzun vadeli governance, provider ekosistemi ve destek modelini de değerlendirmelidir.

OpenTofu Neden Ortaya Çıktı?

Terraform'un lisans modelindeki değişiklik ekosistemde açık kaynak devamlılığı konusunda tartışma yarattı. Topluluk Terraform'un önceki açık kaynak kod çizgisinden ayrı bir proje oluşturdu. OpenTofu bu ihtiyacın sonucu olarak gelişti. Açık governance ve community contribution yaklaşımını sürdürmeyi amaçladı. Teknik tercih kadar lisans ve proje yönetimi de kararın parçası haline geldi.

Terraform ile OpenTofu Arasındaki İlişki

OpenTofu başlangıçta Terraform'un açık kaynak kod tabanından türediği için birçok temel kavramı paylaşır. HCL syntax ve provider modeli büyük ölçüde benzerdir. Zaman içinde iki proje bağımsız özellikler geliştirebilir. Compatibility her yeni version için otomatik varsayılmamalıdır. Migration öncesinde state, provider ve module test edilmelidir.

Açık Kaynak Governance Modeli

OpenTofu community-driven proje yönetimi modeline dayanır. Yol haritası ve katkı süreçleri açık kaynak topluluğu üzerinden ilerler. Tek vendor kontrolüne daha az bağımlı governance hedeflenir. Kurumsal kullanıcı yine commercial support ihtiyacını ayrıca değerlendirebilir. Açık kaynak olması operasyon sorumluluğunu ortadan kaldırmaz.

Terraform'dan OpenTofu'ya Geçiş

Migration birçok configuration için düşük değişiklikle mümkün olabilir. Yine de production state doğrudan değiştirilmeden önce test ortamında doğrulama yapılmalıdır. Provider ve backend compatibility incelenir. CI binary ve lock file davranışı güncellenebilir. Rollback planı hazırlanmadan kritik stack migration yapılmamalıdır.

Terraform mı OpenTofu mu?

Seçim yalnız syntax üzerinden yapılmamalıdır. Lisans, support, governance ve enterprise özellik ihtiyacı değerlendirilmelidir. Mevcut Terraform yatırımı migration maliyeti yaratabilir. Yeni projede iki araç da pilot workload üzerinde karşılaştırılabilir. Uzun vadeli platform standardı ekip yetkinliği ve kurum risk yaklaşımına göre belirlenmelidir.

Terraform Lisans Değişikliği IaC Ekosistemini Nasıl Etkiledi?

HashiCorp 2023 yılında Terraform dahil bazı ürünlerinin gelecekteki sürümlerini Business Source License modeli altında sunmaya yöneldi. Bu değişiklik Terraform çekirdek ürününün klasik açık kaynak lisansı yerine source-available kapsamda değerlendirilmesine neden oldu. İç kullanım birçok kurum için devam edebilirken ürünü rekabet eden hosted veya embedded teklif içinde sunan işletmeler lisans koşullarını ayrıca değerlendirmek zorundadır. Değişiklik OpenTofu'nun ortaya çıkışını hızlandırdı. IaC aracı seçerken lisans artık yalnız hukuk ekibinin değil platform mimarisinin de değerlendirdiği bir risk başlığı haline geldi.

Business Source License Nedir?

Business Source License kaynak kodun görüntülenmesine ve belirli kullanım biçimlerine izin veren source-available lisans modelidir. HashiCorp'un ek kullanım koşulları kurum içi kullanım ile rekabet eden ticari sunumları farklı değerlendirebilir. Lisans koşulları ürün ve version açısından hukuki olarak incelenmelidir. “Kaynak kodu görüyorum” ifadesi otomatik olarak açık kaynak anlamına gelmez. Kurumsal adoption sırasında satın alma ve hukuk ekipleri teknik ekiple birlikte çalışmalıdır.

Source-Available ile Open Source Arasındaki Fark

Open source lisansları Open Source Initiative tarafından kabul edilen belirli özgürlükleri temel alır. Source-available model kodu görünür kılabilir fakat kullanım veya ticari sunum üzerinde ek kısıtlar koyabilir. Bu ayrım vendor ürününü internal kullanan ekip için küçük görünebilir. Platform sağlayan veya managed service sunan şirket için daha önemli olabilir. Lisans sınıfı teknik dependency risk değerlendirmesine eklenmelidir.

OpenTofu'nun Ortaya Çıkışı

Topluluk önceki açık kaynak çizgisini sürdürecek bağımsız bir IaC projesi ihtiyacını dile getirdi. OpenTofu bu süreçte oluşturuldu ve açık kaynak governance modeli altında gelişmeye başladı. Terraform ile güçlü kavramsal benzerlik başlangıç adoption'ını kolaylaştırdı. Zamanla iki proje farklı yönlere gidebilir. Kurumlar yalnız bugünkü compatibility'ye bakarak uzun vadeli karar vermemelidir.

Kurumsal Projelerde Lisans Riskinin Değerlendirilmesi

Ürünün kurum içinde mi yoksa müşteriye sunulan platformun parçası olarak mı kullanılacağı belirlenmelidir. Vendor sözleşmesi ve lisans metni teknik varsayımla yorumlanmamalıdır. Enterprise support ihtiyacı ayrıca değerlendirilir. Exit plan ve alternatif tool maliyeti architecture decision record içinde tutulabilir. Büyük IaC yatırımlarında lisans değişikliği de provider deprecation kadar gerçek bir teknoloji yaşam döngüsü riskidir.

Pulumi Nedir?

Pulumi genel amaçlı programlama dilleri kullanarak Infrastructure as Code geliştirmeye izin veren bir platformdur. TypeScript, Python, Go, C#, Java ve desteklenen diğer dillerle cloud resource tanımlanabilir. Geliştiriciler function, class ve test framework gibi alışık oldukları araçlardan yararlanabilir. Bu esneklik güçlü abstraction imkânı sunarken altyapı kodunun gereğinden fazla yazılım soyutlamasına dönüşme riskini de getirir. Pulumi özellikle uygulama geliştirici yetkinliği yüksek ekiplerde doğal bir IaC deneyimi sunabilir.

Genel Amaçlı Programlama Dilleriyle IaC

DSL öğrenmek yerine mevcut yazılım dili kullanılabilir. Standard package manager ve IDE özelliklerinden yararlanılır. Type checking hataları geliştirme aşamasında yakalayabilir. Unit test framework'leri doğrudan kullanılabilir. Buna karşılık infrastructure intent çok fazla helper ve abstraction arkasında kaybolmamalıdır.

TypeScript

TypeScript güçlü type sistemi ve JavaScript ekosistemi sunar. Pulumi SDK birçok developer için tanıdıktır. Async resource output modelini anlamak gerekir. Reusable component class'ları yazılabilir. Frontend veya Node.js ekipleri hızlı adapte olabilir.

Python

Python basit syntax ve geniş kullanım alanıyla IaC geliştirmede tercih edilebilir. Veri ve otomasyon ekipleri aynı dili kullanabilir. Dynamic typing bazı hataları runtime'a bırakabilir. Type hint ve test kullanılabilir. Dependency environment tekrar üretilebilir tutulmalıdır.

Go

Go static typing ve compile-time feedback sunar. Platform ekiplerinde sık kullanılan bir dildir. Binary tool geliştirme ekosistemiyle uyumludur. Kod verbose olabilir. Component abstraction açık interface ile yönetilebilir.

C#

.NET ekipleri C# kullanarak mevcut geliştirme yetkinliğini IaC tarafına taşıyabilir. Strong typing ve IDE desteği avantaj sağlar. NuGet dependency yönetimi kullanılabilir. Cloud SDK pattern'leri tanıdık gelebilir. Infrastructure repository application standard'larıyla uyumlu hale getirilebilir.

Java

Java büyük kurumsal ekiplerde yaygın olduğu için Pulumi adoption'ını kolaylaştırabilir. Strong typing ve mevcut test araçları kullanılabilir. Build tool configuration ek operasyon getirir. Object abstraction aşırı kullanılmamalıdır. Platform component'leri ortak library biçiminde geliştirilebilir.

Pulumi vs Terraform

Terraform HCL tabanlı deklaratif DSL yaklaşımı sunar. Pulumi genel amaçlı dillerle programmatic model sağlar. Terraform provider ve module ekosistemi geniştir. Pulumi developer tooling ve type system avantajı sağlayabilir. Karar ekibin altyapı kodunda ne kadar programlama esnekliğine gerçekten ihtiyaç duyduğuna göre verilmelidir.

Programlama Dili Kullanmanın Avantajları

Mevcut test ve package ecosystem yeniden kullanılabilir. Type safety bazı hataları erken yakalar. Complex loop ve data structure doğal biçimde ifade edilir. Developer onboarding daha hızlı olabilir. Ortak internal library infrastructure component'lerini standardize edebilir.

Programlama Dili Kullanmanın Zorlukları

Altyapı intent'i normal software abstraction katmanları arkasında kaybolabilir. Developer gereksiz class hierarchy oluşturabilir. Runtime dependency ve package update ayrıca yönetilir. Nondeterministic code plan davranışını zorlaştırabilir. Kod incelemesinde infrastructure diff'in kolay anlaşılması öncelikli tutulmalıdır.

AWS CloudFormation ve AWS CDK

AWS CloudFormation ve AWS CDK AWS altyapısını native servislerle yönetmek isteyen ekipler için iki farklı geliştirme modeli sunar. CloudFormation deklaratif YAML veya JSON template kullanır. CDK genel amaçlı dil ile yüksek seviyeli construct tanımlar ve sonuçta CloudFormation template üretir. İki yaklaşım da AWS stack yaşam döngüsünden yararlanır. Multi-cloud portability öncelikli değilse native servis entegrasyonu önemli avantaj olabilir.

CloudFormation Nedir?

CloudFormation AWS resource'larını stack halinde deklaratif yönetir. Template desired infrastructure'ı tanımlar. AWS deployment ve rollback davranışını yönetir. State kullanıcı tarafından ayrı dosyada tutulmaz. Resource support AWS servis yaşam döngüsüyle yakından ilişkilidir.

YAML / JSON Templates

Template YAML veya JSON formatında yazılabilir. Parameters environment değerlerini taşır. Outputs stack bilgisini dışarı verir. Intrinsic function dynamic referans sağlar. Çok büyük template okunabilirlik açısından modülerleştirilmelidir.

Stack Kavramı

Stack birlikte yönetilen CloudFormation resource grubudur. Update aynı deployment sınırı içinde yapılır. Stack çok büyürse blast radius artabilir. Nested stack veya farklı component stack'leri kullanılabilir. Ownership sınırları stack tasarımını belirlemelidir.

Change Sets

Change Set update uygulanmadan önce proposed resource değişikliklerini gösterir. Deletion ve replacement incelenebilir. Production approval için kullanılabilir. CI pipeline output'u saklayabilir. Terraform plan benzeri güvenlik kapısı sağlar.

AWS CDK Nedir?

AWS CDK infrastructure'ı TypeScript, Python ve başka desteklenen dillerle tanımlamaya izin verir. High-level construct birçok AWS best practice'i paketleyebilir. Synthesis sonucunda CloudFormation template oluşur. Developer normal programming abstraction kullanabilir. Generated template'in ne yaptığını anlamak yine önemlidir.

CDK ile CloudFormation Arasındaki İlişki

CDK deployment motoru olarak CloudFormation'ı kullanır. Kod synth aşamasında template'e dönüştürülür. Stack lifecycle CloudFormation tarafından yönetilir. Bu nedenle CloudFormation limitleri ve davranışları CDK kullanırken de geçerlidir. CDK yüksek seviyeli developer experience sağlar ancak temel deployment platformunu değiştirmez.

Terraform/OpenTofu vs CloudFormation/CDK

Terraform ve OpenTofu multi-provider yaklaşımıyla AWS dışı sistemleri aynı modelde yönetebilir. CloudFormation ve CDK AWS-native servislerdir. Native özellik desteği AWS araçlarında daha hızlı olabilir. Multi-cloud veya SaaS provider ihtiyacı Terraform ekosistemini avantajlı hale getirebilir. Kurum çoğu durumda tek araç zorunluluğu yerine ownership ve platform standardı üzerinden karar vermelidir.

Azure Bicep ve Google Cloud Infrastructure Manager

Azure ve Google Cloud kendi platformlarına yakın IaC deneyimleri sunar. Azure Bicep ARM resource modelini daha okunabilir bir dil üzerinden kullanır. Google Cloud Infrastructure Manager ise Terraform configuration çalıştıran managed bir deployment hizmeti sağlar. Cloud-native araçlar provider'ın yeni servislerine hızlı erişim avantajı sunabilir. Multi-cloud araçlar ise farklı platformlarda ortak workflow oluşturmayı kolaylaştırabilir.

Azure Bicep Nedir?

Bicep Azure Resource Manager kaynaklarını deklaratif biçimde tanımlamak için kullanılır. ARM JSON'a göre daha sade syntax sunar. Module ve parameter desteği vardır. Azure portal ve deployment history ile entegre olabilir. Azure-only ekipler için güçlü native seçenek oluşturur.

ARM ile Bicep Arasındaki İlişki

Bicep configuration deployment sırasında ARM template modeline dönüştürülür. Resource Manager temel execution platformudur. Bicep authoring deneyimini iyileştirir. Existing ARM template'leri migration edilebilir. Deployment state Azure tarafında yönetilir.

Google Cloud Infrastructure Manager Nedir?

Infrastructure Manager Terraform configuration üzerinden Google Cloud resource deployment yönetimi sunar. Terraform execution için managed workflow sağlar. Deployment history ve merkezi operasyon modeli kurulabilir. Kullanıcı kendi runner altyapısını azaltabilir. Google Cloud ağırlıklı Terraform ekipleri için değerlendirilebilir.

Google Deployment Manager Neden Legacy Bir Teknolojidir?

Deployment Manager Google Cloud'un eski infrastructure deployment servisidir. Resmi destek dönemi 2026 içinde sona erdi ve hizmet kapatma sürecindedir. Yeni kullanıcıların bu teknolojiye yatırım yapması önerilmez. Mevcut kullanıcıların Infrastructure Manager veya başka desteklenen IaC çözümlerine migration planlaması gerekir. Bu durum IaC araç seçiminde ürün yaşam döngüsünü ve vendor roadmap'ini takip etmenin önemini gösterir.

Cloud-Native Araç mı Multi-Cloud Araç mı?

Tek cloud kullanan ekip native araçla servis entegrasyonunu daha doğrudan yönetebilir. Multi-cloud araç ortak syntax ve workflow sağlayabilir. Ortak araç kullanmak cloud özelliklerini birebir aynı hale getirmez. Cloud-specific module kullanmak kaçınılmaz olabilir. Seçim gerçek multi-cloud stratejisi ve ekip operasyon modeli üzerinden yapılmalıdır.

IaC State Nedir?

State, bazı IaC araçlarının kodda tanımlanan resource ile gerçek altyapı nesnesi arasındaki ilişkiyi takip etmek için kullandığı veri modelidir. Terraform ve OpenTofu açısından state temel çalışma bileşenidir. Cloud resource ID, computed attribute ve dependency bilgileri burada bulunabilir. State kaybolursa araç mevcut resource'ları yeni kaynak sanabilir veya mapping'i kaybedebilir. Production state bu nedenle güvenli backend, şifreleme, locking ve backup ile korunmalıdır.

State Neden Gereklidir?

Configuration resource'un ne olması gerektiğini söyler fakat cloud tarafından verilen gerçek ID'yi her zaman içermez. State bu eşleştirmeyi saklar. Plan önceki bilgiyi kullanarak değişikliği hesaplar. Dependency ve output değerleri state üzerinden yönetilebilir. Büyük altyapıda bu metadata olmadan lifecycle yönetimi zorlaşır.

Local State

Local state geliştiricinin makinesinde dosya olarak tutulur. Deneme projelerinde basittir. Ekip çalışmasında paylaşım ve locking sorunu oluşturur. Laptop kaybı state kaybına neden olabilir. Production için genellikle remote backend tercih edilir.

Remote State

Remote state merkezi storage veya managed backend üzerinde tutulur. Ekip aynı source of truth'a erişir. Locking eş zamanlı apply riskini azaltır. Backup ve encryption uygulanabilir. Access IAM ile sınırlandırılmalıdır.

State ile Cloud Gerçekliği Arasındaki İlişki

State cloud'un kendisi değildir, kaynak mapping bilgisidir. Manuel console değişikliği state ile actual resource arasında fark oluşturabilir. Refresh veya plan bu farkı okuyabilir. State'i doğrudan cloud gerçeği sanmak yanlış debugging kararlarına yol açar. Reconciliation her iki bilgiyi birlikte değerlendirir.

State İçinde Hassas Veri Bulunabilir mi?

Evet, provider bazı resource attribute değerlerini state içinde saklayabilir. Sensitive işareti CLI çıktısını gizlese bile değer state'te bulunabilir. Bu nedenle state erişimi secret store kadar ciddi ele alınmalıdır. Encryption at rest ve transit kullanılmalıdır. State dosyası Git repository'ye commit edilmemelidir.

Remote State Nasıl Yönetilir?

Remote state ekip halinde Terraform veya OpenTofu kullanmanın temel gereksinimlerinden biridir. Merkezi backend herkesin aynı state üzerinde çalışmasını sağlar. Locking aynı stack'e iki apply yapılmasını engeller. Encryption ve IAM hassas bilgileri korur. Backup ve recovery süreci state incident'larının production altyapıyı yönetilemez hale getirmesini önler.

Merkezi State Backend

Cloud object storage veya managed Terraform backend kullanılabilir. Backend yüksek availability sunmalıdır. State path environment ve component bazında ayrılabilir. Versioning etkinleştirilebilir. Backend configuration repository'de secret içermeden tanımlanmalıdır.

State Locking

Lock apply sırasında başka writer'ın state değiştirmesini önler. Race condition riskini azaltır. Lock stuck kalırsa neden araştırılmadan zorla kaldırılmamalıdır. CI job cancellation bunu oluşturabilir. Backend'in locking desteği production için önemlidir.

Concurrent Apply Problemi

İki pipeline aynı stack'i aynı anda değiştirdiğinde biri diğerinin state bilgisini geçersiz hale getirebilir. Resource conflict ve yanlış plan oluşabilir. Queue veya lock bu durumu engeller. Repository branch merge tek başına yeterli değildir. Deployment concurrency ayrıca kontrol edilmelidir.

State Encryption

Remote backend storage encryption kullanmalıdır. Transit sırasında TLS gerekir. Customer-managed key bazı compliance senaryolarında tercih edilebilir. Key access state access kadar sıkı yönetilir. Backup kopyaları da şifrelenmelidir.

State Backup

Object versioning state recovery için güçlü koruma sağlar. Her apply öncesi veya sonrası snapshot tutulabilir. Retention belirlenir. Backup restore işlemi test edilmelidir. Yedek var varsayımı tatbikat yapılmadan yeterli değildir.

State Recovery

State bozulduğunda önce apply durdurulmalıdır. Son sağlıklı version bulunabilir. Cloud gerçekliğiyle karşılaştırma yapılır. Restore sonrası plan dikkatle incelenir. Gerekirse resource import ile mapping yeniden kurulabilir.

State'e Erişim Yetkilendirmesi

Her developer production state'i değiştirememelidir. Read ve write permission ayrılabilir. CI identity write yetkisine sahip olabilir. Break-glass erişim audit edilir. Least privilege ve MFA gibi kontroller platform standardına göre uygulanmalıdır.

Terraform State Hataları ve Riskleri

State problemi çoğu zaman IaC kod hatasından daha riskli olabilir, çünkü araç gerçek kaynaklarla olan ilişkiyi yanlış yorumlayabilir. State corruption, kayıp state veya yanlış import resource destruction riskini artırır. Manuel editing son seçenek olmalıdır. Recovery öncesinde cloud ve state backup alınmalıdır. Production state için runbook hazırlanması incident anında panik kararlarını azaltır.

State Corruption

Eksik write veya hatalı manual işlem state yapısını bozabilir. Modern remote backend atomic davranışla riski azaltabilir. Apply durdurulmalıdır. Backup version geri yüklenebilir. Restore sonrası plan hiçbir beklenmedik işlem göstermeden doğrulanmalıdır.

Manual State Editing Riski

JSON dosyasını elle değiştirmek mapping ve serial bilgilerini bozabilir. State command'ları mümkün olduğunda tercih edilmelidir. Değişiklik öncesi backup alınır. İki kişi aynı anda müdahale etmemelidir. İşlem audit kaydında tutulmalıdır.

Kaybolan State

State tamamen kaybolursa infrastructure fiziksel olarak çalışmaya devam eder. IaC aracı resource'ları yönetilen olarak tanıyamaz. Import ile mapping tekrar kurulabilir. Büyük stack için bu süreç maliyetlidir. Remote backup kaybın etkisini ciddi ölçüde azaltır.

Yanlış Resource Mapping

Yanlış ID import edilirse kod farklı gerçek resource'u yönetmeye başlayabilir. Plan beklenmeyen değişiklik gösterir. Import sonrası read-only inspection yapılmalıdır. Naming ve tagging resource doğrulamasını kolaylaştırır. Production apply mapping onaylanmadan yapılmamalıdır.

State Lock Problemi

Başarısız pipeline lock'u bırakmayabilir. Force unlock komutu kullanılabilir fakat önce aktif apply olmadığından emin olunmalıdır. Aksi halde concurrent write riski doğar. Lock owner metadata incelenir. CI cancellation handling iyileştirilebilir.

State Recovery Stratejisi

Backend versioning ilk savunma katmanıdır. Recovery runbook hangi backup'ın nasıl seçileceğini açıklar. Restore sonrası plan çıktısı iki kişi tarafından incelenebilir. Critical resource import gerekebilir. Düzenli test state recovery'nin teorik plan olarak kalmasını engeller.

Mevcut Altyapı IaC Yönetimine Nasıl Alınır?

Brownfield environment'ı IaC'a geçirmek yeni bir greenfield ortam kurmaktan daha risklidir. Önce gerçek kaynakların envanteri çıkarılmalıdır. Resource import mevcut cloud object'ini state'e bağlar, ancak configuration ayrıca yazılmalıdır. İlk plan mümkün olduğunca sıfır değişiklik göstermelidir. Production kaynaklarını import ederken planı düzeltmek için gerçek altyapıyı değiştirmek yerine önce kodu mevcut duruma yaklaştırmak daha güvenli başlangıç sağlar.

Greenfield vs Brownfield Infrastructure

Greenfield kaynak baştan IaC ile oluşturulur. Brownfield zaten çalışan manuel veya başka araçla kurulmuş altyapıdır. Brownfield migration mevcut dependency'leri anlamayı gerektirir. Resource ownership çakışabilir. Migration adım adım yapılmalıdır.

Resource Import

Import mevcut resource'u IaC state ile ilişkilendirir. Tek başına configuration üretme davranışı araç ve version'a göre değişebilir. Import edilen object'in attribute'ları kodla eşleştirilmelidir. İlk plan değişiklik göstermemelidir. Deletion riski varsa lifecycle protection eklenebilir.

Önce Gerçek Altyapıyı Envanterlemek

Cloud account içindeki resource listesi çıkarılır. Owner, environment ve criticality tag'leri incelenir. Orphan kaynaklar ayrıştırılır. Dependency diagram oluşturulur. IaC migration scope bu envanter üzerinden planlanır.

Kod ile Gerçek Kaynakları Eşleştirmek

Resource name ve ID configuration'a doğru bağlanmalıdır. Default provider değerleri beklenmedik plan oluşturabilir. Import sonrası computed attribute farkları incelenir. Kod ilk aşamada gerçekliği temsil eder. Daha sonra standardization ayrı değişikliklerle yapılır.

İlk Planı Güvenli Şekilde İncelemek

Hedef mümkün olduğunda “no changes” sonucudur. Replacement görülen kritik resource hemen apply edilmemelidir. Ignore behavior yalnız neden anlaşıldığında kullanılmalıdır. Plan uzman ekip tarafından incelenebilir. Büyük migration component bazında ilerletilir.

Brownfield Migration Riskleri

Resource başka automation tarafından da yönetiliyor olabilir. Hidden dependency ve manual script bulunabilir. Import yanlış state boundary'ye yapılabilir. Production downtime riski vardır. Pilot olarak düşük kritik kaynakla süreç doğrulanmalıdır.

Infrastructure Drift Nedir?

Infrastructure drift, kodda tanımlanan desired state ile gerçek cloud configuration'ın zaman içinde ayrışmasıdır. Manuel console değişikliği en yaygın nedenlerden biridir. Emergency müdahale veya başka IaC stack'i de aynı resource'u değiştirerek drift oluşturabilir. Drift güvenlik ve compliance açısından görünmeyen risk yaratır. Sürekli detection ve değişikliklerin tekrar repository'ye yansıtılması Git'in güvenilir kaynak olarak kalmasını sağlar.

Desired State ve Actual State'in Ayrışması

Kod security group yalnız 443 portunu açık gösterirken cloud console'da 22 portu da açılmış olabilir. Bu fark drift'tir. Plan değişikliği yakalayabilir. Her fark hata değildir, bazı provider computed value'ları normaldir. Drift classification gerekir.

Manuel Cloud Console Değişiklikleri

Acil sorun çözmek için console kullanımı bazen kaçınılmazdır. Problem değişiklik koda geri yazılmazsa başlar. Bir sonraki apply manuel düzeltmeyi geri alabilir. Audit log kaynağı gösterir. Break-glass süreci backport adımı içermelidir.

Çakışan IaC Stacks

İki state aynı resource'u yönetmemelidir. Biri tag değiştirirken diğeri eski değeri geri yazabilir. Ownership boundary repository tasarımında belirlenir. Shared resource ayrı stack olabilir. Cross-stack output kontrollü kullanılmalıdır.

Emergency / Break-Glass Değişiklikleri

Incident sırasında hızlı manuel değişiklik gerekebilir. Yetki sınırlı ve süreli olmalıdır. Değişiklik kaydedilir. Incident sonrası IaC code güncellenir. Drift kapatılmadan normal operasyon tamamlanmış sayılmamalıdır.

Drift'in Güvenlik ve Compliance Etkisi

Manuel açılan public port security policy'yi ihlal edebilir. Encryption ayarı kapatılabilir. IaC scan kodu temiz gösterirken runtime environment farklı olabilir. Bu nedenle security yalnız static scan'e dayanamaz. Drift monitoring runtime compliance'in önemli parçasıdır.

Drift Detection ve Drift Management

Drift detection mevcut altyapının koddan ayrıldığını düzenli olarak kontrol eder. Terraform veya OpenTofu plan bu amaçla kullanılabilir. Cloud-native platformlar kendi drift araçlarını sunabilir. Detection sonrası otomatik remediation her durumda güvenli değildir. Kritik production değişikliklerinde önce alarm, root cause ve kontrollü düzeltme daha uygun olabilir.

Terraform/OpenTofu Plan ile Drift Detection

Scheduled plan gerçek provider state'i okuyabilir. Kod değişmediği halde diff çıkması drift sinyali olabilir. Output makine tarafından parse edilebilir. Resource replacement alarm seviyesi yüksek tutulabilir. Credential yalnız read ve plan için yeterli yetkiyle sınırlandırılabilir.

CloudFormation Drift Detection

CloudFormation stack resource'larının template'ten ayrışıp ayrışmadığını kontrol edebilir. Desteklenen resource property'leri incelenir. Drift sonucu stack seviyesinde görülebilir. Manuel AWS değişiklikleri fark edilebilir. Remediation ayrıca planlanmalıdır.

Sürekli Drift Monitoring

Günlük veya saatlik kontrol yapılabilir. Çok sık refresh cloud API maliyeti yaratabilir. Critical stack daha sık izlenebilir. Result merkezi dashboard'a gönderilir. Normal provider noise filtrelenmelidir.

Drift Alerting

Her drift aynı öneme sahip değildir. Public access veya IAM değişikliği yüksek severity olabilir. Tag farkı düşük öncelikte kalabilir. Alert owner bilgisine yönlendirilir. False positive sürekli azaltılmalıdır.

Manual Remediation

Drift nedeni bilinmeden otomatik apply yapmak risklidir. Önce değişikliğin bilinçli olup olmadığı araştırılır. Kod veya cloud state doğru kabul edilir. Plan review yapılır. Sonra kontrollü remediation uygulanır.

Automated Remediation

Düşük riskli policy ihlalleri otomatik düzeltilebilir. Public bucket gibi kritik security pattern'lerinde guardrail kullanılabilir. Otomasyon loop oluşturmamalıdır. Manual exception mekanizması bulunur. Her remediation audit log'a yazılır.

Emergency Değişikliği IaC'a Geri Yazmak

Incident sırasında yapılan doğru manuel değişiklik repository'ye eklenmelidir. Pull request olay kaydına bağlanabilir. Plan artık fark göstermemelidir. Gerekirse module standardı güncellenir. Böylece bir sonraki apply incident çözümünü yanlışlıkla geri almaz.

IaC Repository Yapısı Nasıl Tasarlanır?

Repository yapısı ekip sınırları, environment sayısı ve module paylaşım modeline göre seçilmelidir. Monorepo merkezi visibility sağlarken polyrepo bağımsız ownership sunabilir. Application ve infrastructure kodunun birlikte tutulması deployment coupling açısından avantajlı olabilir. Shared module repository kurum standardını ortaklaştırır. Tek doğru yapı yoktur, ancak ownership, review ve deployment sınırları repository yapısında anlaşılır olmalıdır.

Monorepo

Bütün infrastructure kodu tek repository içinde tutulabilir. Cross-component change tek pull request'te yapılabilir. Merkezi policy ve tooling kolaylaşır. Repository büyüdükçe CI selective execution gerekir. Ownership path bazında tanımlanabilir.

Polyrepo / Multi-Repo

Her platform veya ekip ayrı repository yönetebilir. Permission ve release bağımsız olur. Shared change birden fazla repo koordinasyonu gerektirebilir. Standard template uygulanmalıdır. Catalog hangi repo hangi stack'i yönetiyor bilgisini tutabilir.

Application ve Infrastructure Kodunu Birlikte Tutmak

Servise özel infrastructure application repo içinde bulunabilir. Kod ve altyapı version aynı release ile ilerler. Platform module external dependency olarak kullanılabilir. Shared network gibi kaynaklar ayrı repo'da kalmalıdır. Ownership application ekibine daha yakın olur.

Shared Modules Repository

Kurumsal module'ler merkezi repository'de versionlanabilir. Security ve tagging standardı burada uygulanır. Consumer semantic version ile bağımlılık kurar. Module owner açık olmalıdır. Breaking change migration guide ile yayınlanmalıdır.

Environment Bazlı Repository

Dev, staging ve production ayrı repo olabilir. Permission isolation güçlüdür. Aynı değişikliği üç repo'da tekrar etmek drift yaratabilir. Promotion otomasyonu gerekir. Genellikle component veya team bazlı yapı daha sürdürülebilir olabilir.

Team Ownership

Her path veya stack'in sorumlu ekibi belirlenmelidir. CODEOWNERS review sürecini otomatikleştirebilir. Incident owner hızlı bulunur. Shared resource için platform team sorumluluk alabilir. Ownership belirsizliği repository düzeninden daha büyük risktir.

IaC Projesinde Dosya ve Klasör Yapısı

Dosya yapısı küçük projede önemsiz görünse de büyüyen repository'de okunabilirlik sağlar. Terraform projelerinde main, variables ve outputs gibi dosya ayrımları yaygındır. Provider configuration ve environment-specific parametreler anlaşılır yerde tutulmalıdır. Module directory reusable component'leri ayırır. README dosyası kullanıcıya nasıl plan ve deploy yapacağını açıklamalıdır.

main

main dosyası temel resource ve module çağrılarını içerebilir. Dosya ismi Terraform davranışını değiştirmez. Ama ortak convention onboarding'i kolaylaştırır. Çok büyük main farklı domain dosyalarına ayrılabilir. Resource grouping okunabilirlik odaklı yapılmalıdır.

variables

Input variable tanımları ayrı dosyada tutulabilir. Description ve validation eklenmelidir. Default yalnız güvenli değerlerde kullanılmalıdır. Sensitive input işaretlenebilir. Kullanıcı module interface'ini buradan anlayabilir.

outputs

Dışarı sunulan resource bilgileri outputs içinde tanımlanabilir. Public interface sınırlı tutulur. Sensitive değer gizli işaretlenir. Cross-stack dependency ihtiyacı azaltılmalıdır. Output description bakım kolaylığı sağlar.

provider Configuration

Provider version ve temel ayarlar açık biçimde tanımlanır. Credential koda yazılmaz. Alias multi-region kullanımı sağlayabilir. Provider inheritance module davranışında anlaşılmalıdır. Upgrade controlled dependency sürecinden geçer.

Environment Variables

Runtime credential veya environment-specific değer taşımak için kullanılabilir. Secret manager entegrasyonu daha güvenlidir. Lokal geliştirici ve CI davranışı standardize edilmelidir. Variable precedence bilinmelidir. Shell history içine hassas değer yazılmamalıdır.

Module Directories

Reusable component ayrı module klasöründe tutulur. Public module bağımsız version alabilir. Local module küçük repository için yeterlidir. Deep nested module yapısı debugging'i zorlaştırabilir. Interface basit tutulmalıdır.

README ve Dokümantasyon

README kullanım amacı ve prerequisite bilgisi içerir. Plan ve apply workflow açıklanır. Input ve output örnekleri verilir. Ownership ve support kanalı belirtilir. Otomatik documentation generation güncelliği artırabilir.

IaC Modules Nedir?

Module tekrar kullanılan infrastructure pattern'ini paketler. Kurum standart VPC, Kubernetes cluster veya database kurulumunu module olarak sunabilir. Application ekipleri yüzlerce resource ayrıntısını bilmeden güvenli interface kullanır. Versioning ve ownership module yaşam döngüsünü yönetir. Her farklı kullanım alanını tek mega-module içine koymak yerine anlamlı sınırlar oluşturmak daha sağlıklı sonuç verir.

Modüler Kodun Avantajları

Tekrarlanan configuration azalır. Security standard merkezi güncellenebilir. Review aynı logic için tekrar yapılmaz. Consumer daha az kod yazar. Module unit olarak test edilebilir.

Reusable Infrastructure

Network veya database pattern farklı servislerde tekrar kullanılabilir. Input ile capacity değişir. Ortak tagging otomatik eklenir. Standard architecture hız kazandırır. Reuse zorunlu değil faydalı olduğu yerde uygulanmalıdır.

Input Variables

Module davranışının kontrollü parametreleridir. Çok fazla input interface'i zorlaştırır. Safe default kullanılabilir. Validation invalid combination'ı engeller. Secret parameter state etkisi açısından değerlendirilmelidir.

Outputs

Consumer'a gerekli bilgiyi sunar. Internal resource ayrıntısı dışarı açılmamalıdır. Endpoint ve ID yaygın örneklerdir. Output değişikliği downstream consumer'ı etkileyebilir. Public contract olarak versionlanmalıdır.

Public ve Private Module Registry

Public registry community module sunar. Private registry kurum içi standard'ları barındırabilir. Third-party module security review'dan geçmelidir. Version pinning yapılır. Ownership metadata registry içinde görünür olmalıdır.

Module Versioning

Semantic versioning consumer değişikliğini yönetir. Breaking interface yeni major version olabilir. Bug fix patch release olarak yayınlanabilir. Changelog migration süresini azaltır. Consumer version'ı bilinçli olarak upgrade eder.

Module Ownership

Her module bakım ekibine sahip olmalıdır. Security issue hızlı çözülür. Deprecation süreci owner tarafından yönetilir. SLO kritik shared module için tanımlanabilir. Sahipsiz module uzun vadede risk oluşturur.

Ne Zaman Yeni Module Oluşturulmamalı?

Yalnız bir kez kullanılan üç resource için module gereksiz olabilir. Interface tasarımı asıl configuration'dan daha fazla kod oluşturabilir. Henüz pattern oluşmadan abstraction erken yapılmamalıdır. Önce birkaç gerçek kullanım gözlemlenebilir. Module tekrar eden stabil ihtiyacı temsil etmelidir.

IaC Kodunda DRY İlkesi Ne Kadar Uygulanmalı?

DRY tekrar eden kodu azaltmayı hedefler, ancak infrastructure code içinde her benzer satırı abstraction'a dönüştürmek doğru değildir. Biraz tekrar bazen açık ve bağımsız stack'ler için kabul edilebilir. Generic mega-module onlarca condition ile yönetildiğinde değişiklik etkisini anlamak zorlaşır. Okunabilirlik production altyapısında önemli güvenlik özelliğidir. Reuse ile açık resource intent arasında dengeli tasarım yapılmalıdır.

Kod Tekrarını Azaltmak

Ortak tagging ve network pattern module haline getirilebilir. Copy-paste bug azalır. Security fix tek yerde uygulanır. Version management gerekir. Tekrar gerçekten aynı davranışı temsil ediyorsa abstraction yapılmalıdır.

Aşırı Abstraction Problemi

Module yüzlerce input alıyorsa kullanımı zorlaşır. Her environment farklı flag kombinasyonu kullanabilir. Planın hangi resource'u neden oluşturduğu anlaşılmaz hale gelir. Debugging süresi artar. Bazen iki küçük module daha iyi çözümdür.

Generic Mega-Module Anti-Pattern

Tek module bütün database türlerini ve network modellerini desteklemeye çalışabilir. Condition sayısı büyür. Test matrisi kontrol edilemez hale gelir. Breaking change blast radius'u artar. Domain-specific küçük module'ler daha anlaşılır olur.

Okunabilirlik ve Reusability Dengesi

Infrastructure code review sırasında insan tarafından hızlı anlaşılmalıdır. Reuse değer sağladığı yerde uygulanır. Explicit configuration bazen daha güvenlidir. Module documentation interface'i açık tutar. Ekip standardı gerçek kullanım deneyimiyle gelişmelidir.

Provider ve Dependency Yönetimi

IaC kodu provider ve module bağımlılıklarına sahiptir. Kontrolsüz latest version kullanmak aynı kodun farklı günlerde farklı davranmasına neden olabilir. Version pinning ve lock file tekrar üretilebilir build sağlar. Dependency update yine gereklidir, çünkü eski provider security ve API uyumluluk problemi oluşturabilir. Güncelleme kontrollü pull request ve test süreciyle yapılmalıdır.

Provider Version Pinning

Version constraint kabul edilen aralığı belirler. Exact veya compatible range kullanılabilir. Major upgrade otomatik alınmamalıdır. Changelog incelenir. Plan farkları staging ortamında test edilir.

Lock File

Lock file seçilen provider binary version ve checksum bilgisini tutar. Ekip aynı dependency'yi kullanır. Repository'ye commit edilmesi yaygındır. Platform-specific provider davranışı anlaşılmalıdır. Update bilinçli komutla yapılır.

Module Version Pinning

Shared module ref version veya commit ile sabitlenmelidir. Main branch'e doğrudan bağlanmak risklidir. Consumer upgrade zamanını kendisi seçebilir. Security fix adoption ayrıca takip edilir. Registry version yönetimi kolaylaştırır.

Breaking Changes

Provider resource schema değiştirebilir. Deprecated argument kaldırılabilir. Plan replacement gösterebilir. Migration guide okunmalıdır. Büyük update küçük component üzerinde denenmelidir.

Dependency Update Süreci

Otomatik bot yeni version için pull request açabilir. CI validate ve plan çalıştırır. Reviewer changelog inceler. Staging apply doğrulanır. Production promotion kontrollü yapılır.

Otomatik Dependency Update'lerinin Riski

Her update'i otomatik merge etmek infrastructure için risklidir. Provider minor sürümü davranış farkı oluşturabilir. Plan review gerekir. Critical module için manual approval kullanılır. Otomasyon öneri üretmeli, production değişikliğini bağlamdan bağımsız yapmamalıdır.

Development, Staging ve Production Ortamları Nasıl Yönetilir?

Environment yönetiminde hedef, temel mimariyi ortak tutarken risk ve kapasite farklarını açık parametrelerle yönetmektir. Aynı module farklı input'larla kullanılabilir. Production isolation için ayrı cloud account, subscription veya project güçlü sınır sağlar. Workspace bazı kullanım alanlarında yararlı olsa da tam security isolation yerine geçmez. Environment parity deploy edilen application'ın production davranışını daha erken test etmeyi sağlar.

Aynı Modülü Farklı Parametrelerle Kullanmak

Dev küçük instance, production büyük instance kullanabilir. Network pattern aynı module'den gelir. Fark configuration dosyasında görünür olur. Module version tüm ortamlar için kontrollü promote edilir. Drift azalır.

Environment Isolation

Production credential dev ortamından ayrı tutulur. State backend ayrı olabilir. Network peering kontrollü yapılır. Yanlış apply blast radius'u sınırlandırılır. Logging ve cost attribution kolaylaşır.

Ayrı Cloud Account / Subscription / Project

Provider'ın native isolation sınırı kullanılır. IAM policy daha güvenli olur. Quota ve billing ayrılır. Production kaynaklarına yanlış dev erişimi azalır. Platform standardı hesap vending otomasyonuyla uygulanabilir.

Workspaces

Workspace aynı configuration için farklı state kopyaları sağlar. Basit environment ayrımında kullanılabilir. Code aynı kalır. Resource name workspace'e göre değişebilir. Security boundary olmadığı unutulmamalıdır.

Workspace'ların Sınırları

Aynı backend ve code coupling oluşturabilir. Farklı environment policy'leri yönetmek zorlaşabilir. Yanlış workspace seçimi risklidir. Büyük production sistemleri ayrı root module ve state tercih edebilir. Tool özelliği organization boundary yerine kullanılmamalıdır.

Environment Parity

Staging production'ın temel topology'sini yansıtmalıdır. Kapasite daha küçük olabilir. Security policy mümkün olduğunca aynı kalır. Farklar bilinçli ve belgeli olmalıdır. Deployment sorunları production öncesinde yakalanır.

IaC ve Git Arasındaki İlişki

Git Infrastructure as Code yaklaşımının merkezi parçalarından biridir, çünkü altyapı değişikliklerine geçmiş, review ve sahiplik kazandırır. Repository yalnız depolama alanı değil karar kaydı olarak da kullanılabilir. Pull request plan diff'iyle birlikte değerlendirilebilir. Commit geçmişi incident sırasında hangi değişikliğin ne zaman yapıldığını gösterir. Git source of truth olarak kullanılacaksa manuel cloud değişiklikleri düzenli olarak koda geri yansıtılmalıdır.

Infrastructure Repository

IaC code merkezi repository'de tutulur. Module ve environment yapısı açık olur. Ownership tanımlanır. CI pipeline repository event'leriyle tetiklenir. Secret repository içinde bulunmaz.

Branching Strategy

Trunk-based veya kısa feature branch kullanılabilir. Uzun yaşayan environment branch drift yaratabilir. Production state code branch ile karıştırılmamalıdır. Merge approval standardı belirlenir. Tag release tracking için kullanılabilir.

Pull Request

Infrastructure change önerisi PR üzerinden yapılır. Code diff ve plan output birlikte görülür. Security scanner sonucu eklenir. Owner review verir. Merge deployment approval anlamına gelmek zorunda değildir.

Code Review

Reviewer architecture ve risk etkisine bakar. Resource deletion kontrol edilir. Naming ve tagging standardı doğrulanır. IAM permission değerlendirilir. Review checklist tutarlılık sağlar.

Commit History

Her değişiklik zaman ve author bilgisi taşır. Incident root cause analizi kolaylaşır. Revert mümkündür. Commit message business nedeni açıklamalıdır. Generated formatting değişiklikleri gerçek infrastructure diff'i gizlememelidir.

Git'i Source of Truth Olarak Kullanmak

Desired infrastructure Git'te temsil edilir. Console yalnız observation veya kontrollü emergency için kullanılır. Merge edilmiş configuration deployment'a gider. Drift detection actual state farkını raporlar. Git ile cloud gerçeği arasındaki ilişki governance sürecinin temelidir.

CI/CD Pipeline İçinde IaC

IaC ile bulut altyapısı versiyonlama CI/CD ve otomatik deployment nasıl yapılır sorusunun cevabı, değişiklikleri bir dizi otomatik kalite kontrolünden geçirmekle başlar. Pull request açıldığında format, validate, security scan ve policy kontrolü çalışabilir. Plan çıktısı reviewer'a gösterilir. Production apply için human approval veya risk tabanlı otomasyon kullanılabilir. Deployment sonrası doğrulama pipeline'ı yalnız apply sonucuna güvenmekten daha güvenli hale getirir.

Pull Request Oluşturma

Developer infrastructure değişikliğini branch üzerinde hazırlar. PR açıklaması amaç ve etkilenebilecek resource'ları belirtir. Ticket veya incident bağlantısı eklenebilir. CI otomatik başlar. Reviewer plan oluşmadan onay vermez.

Format ve Lint

Formatter ortak code style sağlar. Linter suspicious pattern yakalayabilir. Hızlı çalıştığı için ilk pipeline aşamasıdır. Failure developer'a erken feedback verir. Style review tartışması azalır.

Validate

Configuration syntax ve reference kontrol edilir. Provider schema error bulunabilir. Gerçek deployment yapılmaz. Her PR'da çalışmalıdır. Local pre-commit hook ile daha erken feedback sağlanabilir.

Security Scan

Static scanner public storage veya açık port gibi riskleri yakalayabilir. Rule severity belirlenir. False positive exception süreci bulunur. Custom organizational policy eklenebilir. Scan sonucu PR içinde görünür olur.

Policy Check

Policy as Code tagging, region ve IAM kurallarını kontrol eder. Security dışındaki cost rule'ları da uygulanabilir. Production standard code haline gelir. Violation merge'i durdurabilir. Exception approval audit edilir.

Plan / Preview

CI gerçek veya read-only credential ile plan çıkarır. Output artifact olarak saklanır. Resource deletion vurgulanır. Sensitive value maskelenir. Reviewer kodun gerçek infrastructure etkisini görür.

Human Approval

Production değişikliği belirli owner tarafından onaylanabilir. Küçük düşük riskli change otomatik olabilir. High-risk resource için ek approval gerekir. Approval plan artifact'e bağlı olmalıdır. Sonradan code değişirse yeni plan üretilmelidir.

Apply

CI kısa ömürlü credential alır. Saved plan uygulanabilir. State lock aktif olur. Deployment log merkezi kaydedilir. Failure runbook devreye girer.

Post-Deployment Validation

Resource created status yeterli değildir. Health endpoint ve network connectivity test edilir. Security policy yeniden kontrol edilebilir. Monitoring alarmı takip edilir. Başarısız verification rollback veya forward fix tetikleyebilir.

CI/CD ve kod kalite süreçlerini altyapı otomasyonunun ötesinde daha ayrıntılı incelemek için https://www.diyarbakiryazilim.com.tr/posts/ci-cd-boru-hatlarinda-pipelines-kod-kalite-analizleri adresindeki içeriğe de bakabilirsiniz. IaC pipeline'ları uygulama pipeline'larından farklı risklere sahip olsa da format, test, review ve kontrollü promotion prensipleri büyük ölçüde ortaktır. Infrastructure plan çıktısının PR sürecine eklenmesi kod kalite kontrollerini gerçek altyapı etkisiyle ilişkilendirir. Bu yaklaşım ekiplerin yalnız syntax değil güvenlik, maliyet ve availability sonuçlarını da release öncesinde değerlendirmesini sağlar. Özellikle production altyapısında CI/CD'nin amacı değişiklikleri yalnız hızlandırmak değil öngörülebilir ve denetlenebilir hale getirmektir.

IaC Pipeline'ında Plan ve Apply Neden Ayrılmalıdır?

Plan ile apply'ın ayrılması production değişikliğinin etkisini uygulamadan önce inceleme fırsatı verir. Bir resource'un silineceği veya yeniden oluşturulacağı plan aşamasında görülebilir. Human approval yanlış değişikliğin gerçek cloud ortamına ulaşmasını önleyebilir. Saved plan code ve apply arasındaki farkı azaltır. İki aşamanın birleştirildiği kontrolsüz otomasyon, küçük bir configuration hatasını saniyeler içinde büyük production incident'ına çevirebilir.

Proposed Change'i Önceden Görmek

Plan resource diff'i görünür kılar. Reviewer yalnız kod satırlarına bakmak zorunda kalmaz. Provider computed change görülebilir. Cost estimate eklenebilir. Change intent daha açık değerlendirilir.

Resource Deletion Tespiti

Destroy işareti yüksek riskli sinyaldir. Yanlış rename resource replacement yaratabilir. Data resource silinmesi backup gerektirir. Pipeline deletion için özel approval isteyebilir. Policy belirli resource'larda silmeyi engelleyebilir.

Replacement Tespiti

Bazı property yerinde değiştirilemez. Provider resource'u silip yeniden oluşturmak ister. Plan bunu replacement olarak gösterir. Downtime ve data loss etkisi değerlendirilir. Blue-green alternatif kullanılabilir.

Human Approval

İnsan review bağlam ve business risk ekler. Otomatik testlerin göremediği zamanlama problemi fark edilebilir. Emergency durum için farklı approval path olabilir. Approval identity kaydedilir. Her küçük change için gereksiz bürokrasi yaratmamak önemlidir.

Plan ile Apply Arasındaki Değişiklik Riski

Plan üretildikten sonra code veya cloud state değişebilir. Yeni commit eski planı geçersiz kılmalıdır. Drift apply sonucunu değiştirebilir. Saved plan ve kısa approval window riski azaltır. Critical stack için state lock ayrıca kullanılabilir.

Saved Plan Kullanımı

Binary veya platform-specific plan artifact apply aşamasına aktarılabilir. Reviewer'ın gördüğü değişiklik uygulanır. Artifact integrity korunmalıdır. Expired plan yeniden üretilmelidir. Secret içerebileceği için güvenli storage gerekir.

Infrastructure as Code Testleri

IaC testleri syntax kontrolünden gerçek environment doğrulamasına kadar farklı seviyelere ayrılır. Her değişiklik için full end-to-end test çalıştırmak pahalı olabilir. Hızlı static kontroller PR aşamasında, integration testler kritik module release'lerinde kullanılabilir. Ephemeral environment gerçek provider davranışını production'ı etkilemeden test etmeyi sağlar. Test stratejisi risk ve maliyet dengesine göre katmanlı kurulmalıdır.

Syntax Validation

Parser configuration'ın geçerli olup olmadığını kontrol eder. En hızlı test seviyesidir. Typo ve block hatalarını yakalar. Cloud API davranışını test etmez. Her commit'te çalıştırılabilir.

Formatting

Formatter code style'ı standardize eder. Diff daha okunabilir olur. Review noise azalır. CI format check yapabilir. Developer local hook kullanabilir.

Linting

Linter kötü kullanım pattern'lerini yakalayabilir. Deprecated argument veya unused variable uyarılabilir. Rule set tool'a göre değişir. Custom organization standard eklenebilir. Warning ve error severity ayrılmalıdır.

Static Analysis

Code çalıştırılmadan güvenlik ve configuration pattern'leri incelenir. Public port veya encryption eksikliği bulunabilir. Fast feedback sağlar. Runtime cloud policy'nin yerine geçmez. False positive yönetimi gerekir.

Unit Testing

Module output ve logic küçük kapsamda test edilir. Programmatic IaC'da normal test framework kullanılabilir. Terraform test özellikleri değerlendirilebilir. External API mock gerekebilir. Public module behavior contract olarak doğrulanır.

Integration Testing

Gerçek cloud resource oluşturulabilir. Provider permission ve API davranışı test edilir. Cost ve süre unit testten yüksektir. Dedicated test account kullanılmalıdır. Cleanup güvenilir olmalıdır.

End-to-End Testing

Tam infrastructure topology ve uygulama birlikte test edilir. Network, IAM ve service dependency doğrulanır. Production'a en yakın sonuç verir. Pahalı olduğu için kritik release'lerde kullanılır. Test data ve credential güvenli yönetilmelidir.

Ephemeral Test Environment

PR için geçici environment oluşturulabilir. Test tamamlandıktan sonra destroy edilir. Module gerçek koşulda doğrulanır. Cost kontrolü gerekir. Cleanup failure orphan resource yaratabileceği için monitoring eklenmelidir.

Policy as Code Nedir?

Policy as Code güvenlik, compliance ve maliyet kurallarını makine tarafından değerlendirilebilir biçimde tanımlar. Örneğin public storage yasaklanabilir veya production resource'larının belirli region'larda oluşturulması zorunlu tutulabilir. CI plan çıktısı policy engine tarafından kontrol edilir. Böylece governance yalnız reviewer's kişisel hafızasına bağlı kalmaz. Exception gerektiğinde onay ve audit süreciyle yönetilebilir.

Güvenlik Politikalarının Kodlanması

Network port ve encryption kuralları policy haline getirilebilir. Her pull request otomatik değerlendirilir. Security team merkezi rule set yönetebilir. App team sonucu erken görür. Production sonrası remediation ihtiyacı azalır.

Compliance Politikaları

Tagging ve data residency kuralları uygulanabilir. Belirli resource type yasaklanabilir. Audit sonucu saklanır. Policy version kontrol altında tutulur. Regulatory değişiklik merkezi rule update ile yansıtılır.

Cost Policies

Çok büyük instance veya gereksiz public IP engellenebilir. Budget threshold plan aşamasında kontrol edilebilir. Production ve dev için farklı limit belirlenebilir. Exception business approval isteyebilir. FinOps governance deployment sürecine taşınır.

Open Policy Agent

Open Policy Agent genel amaçlı policy engine'dir. JSON benzeri input üzerinde karar verebilir. Kubernetes, CI ve IaC planlarıyla kullanılabilir. Policy deployment application logic'ten ayrılır. Merkezi authorization ve compliance senaryolarında değerlidir.

Rego

Rego OPA policy kurallarını yazmak için kullanılan dildir. Input document üzerinde query oluşturur. IaC plan resource'ları filtrelenebilir. Unit test yazılabilir. Policy code da normal software gibi versionlanmalıdır.

Sentinel

Sentinel HashiCorp ekosisteminde policy enforcement için kullanılan policy framework'üdür. Terraform workflow ile entegre edilebilir. Mandatory veya advisory policy tanımlanabilir. Enterprise platform özellikleriyle ilişkili olabilir. Lisans ve hosting modeli seçim öncesinde değerlendirilmelidir.

Deployment Öncesi Policy Enforcement

Policy apply sonrasında yalnız alarm vermek yerine deployment'ı engelleyebilir. Bu shift-left security sağlar. Critical violation hard fail olabilir. Düşük risk warning olarak kalabilir. Exception kayıt altına alınmalıdır.

IaC Security Temelleri

IaC yanlış configuration'ı hızla çoğaltabildiği için güvenlik kontrolünün erken yapılması gerekir. Public storage, açık port ve fazla yetkili IAM roller yaygın risklerdir. Static scanning ve policy check CI içinde çalıştırılabilir. Runtime cloud policy ve drift monitoring yine devam etmelidir. Güvenli IaC kodu, güvenli secret yönetimi ve minimum yetkili deployment identity birlikte ele alınmalıdır.

Misconfiguration

Yanlış attribute security açığı oluşturabilir. Default değer beklenenden farklı olabilir. Module güvenli default sunmalıdır. Scanner riskli pattern'i yakalar. Review business context ekler.

Public Storage

Object storage yanlışlıkla internet erişimine açılabilir. Policy default public access'i engelleyebilir. Explicit exception gerekir. Sensitive data classification dikkate alınır. Runtime monitoring public değişikliği fark eder.

Açık Network Port'ları

0.0.0.0/0 rule kolay fakat riskli olabilir. Yalnız gerekli port açılmalıdır. Source CIDR sınırlandırılır. Security scanner geniş rule'u raporlar. Break-glass network değişikliği sonradan kapatılır.

Fazla Yetkili IAM Rolleri

Admin wildcard permission hızlı çözüm gibi görünebilir. Compromise blast radius'u büyütür. Least privilege policy tercih edilir. Access analyzer kullanılabilir. CI identity yalnız gerekli resource action'larına sahip olmalıdır.

Encryption Eksikliği

Storage ve database encryption açık olmalıdır. Module safe default sağlayabilir. Customer-managed key ihtiyacı policy ile belirlenir. Transit encryption ayrıca kontrol edilir. Compliance scanner eksik configuration'ı yakalar.

Insecure Defaults

Module default değeri en güvenli davranışı seçmelidir. Public access opt-in olmalıdır. Logging ve encryption varsayılan açık olabilir. Kullanıcı güvenliği kapatmak için explicit karar vermelidir. Default değişikliği backward compatibility açısından yönetilmelidir.

IaC Security Scanning

Static scanner code ve plan üzerinde çalışabilir. Tool farklı provider rule set sunabilir. CI integration hızlı feedback sağlar. Scanner sonucu bağlamdan bağımsız kabul edilmemelidir. High-severity rule'lar policy gate'e bağlanabilir.

Secret Management ve IaC

Secret değerler IaC repository'sine düz metin olarak yazılmamalıdır. Terraform state içinde bazı secret'lar saklanabileceği için state de hassas veri gibi korunmalıdır. CI/CD sistemi kısa ömürlü credential kullanmalıdır. Vault veya cloud-native secret manager runtime erişim sağlayabilir. OIDC uzun ömürlü cloud access key ihtiyacını ciddi ölçüde azaltabilir.

Secret'ları IaC Dosyasına Yazmamak

Password ve API key Git history'den tamamen silmek zordur. Secret scanner commit öncesi uyarı verebilir. Runtime secret injection kullanılmalıdır. Example config gerçek secret içermemelidir. Yanlışlıkla commit edilen secret hemen rotate edilmelidir.

Terraform State İçindeki Secrets

Resource attribute secret değeri state'e yazılabilir. CLI sensitive flag yalnız display davranışını etkiler. Backend access sıkı tutulmalıdır. Encryption ve audit gerekir. Mümkün olduğunda provider'ın secret reference özelliği kullanılmalıdır.

Environment Variables

CI secret değerini environment variable olarak verebilir. Process ve log exposure riski düşünülmelidir. Shell echo kapatılmalıdır. Local developer kullanımında secure credential helper tercih edilir. Uzun ömürlü secret yerine kısa ömürlü token daha iyidir.

HashiCorp Vault

Vault merkezi secret ve dynamic credential yönetimi sağlayabilir. IaC pipeline kısa ömürlü cloud credential alabilir. Policy access sınırlar. Vault'un kendisi yüksek availability ve güvenlik operasyonu gerektirir. Her küçük ekip için zorunlu değildir.

AWS Secrets Manager

AWS native secret storage ve rotation sağlayabilir. Application veya pipeline runtime'da secret okuyabilir. IAM access kontrolü uygulanır. Secret ARN IaC içinde tutulabilir. Değer repository ve loglardan uzak tutulur.

CI/CD Secret Yönetimi

Pipeline platformu encrypted secret store sunabilir. Environment bazlı permission ayrılır. Production secret yalnız protected branch veya approval sonrası kullanılabilir. Secret log masking uygulanır. Access audit düzenli incelenir.

OIDC ve Short-Lived Credentials

CI platform kimliği OIDC token ile cloud provider'a güvenli biçimde doğrulanabilir. Uzun ömürlü access key saklama ihtiyacı azalır. Token dakikalar içinde geçersiz olur. Role claim repository ve branch bilgisine göre sınırlandırılabilir. Modern IaC pipeline'larında güçlü security pattern'lerinden biridir.

IaC Supply Chain Güvenliği

IaC kodu yalnız kendi repository'nizden oluşmaz. Provider binary, public module ve üçüncü taraf action'lar supply chain riskidir. Version pinning ve provenance kontrolü dependency'nin beklenmedik biçimde değişmesini azaltır. Public module kullanmadan önce source code ve bakım geçmişi incelenmelidir. Infrastructure deployment credential'ı güçlü olduğu için supply chain ihlali application dependency probleminden daha geniş blast radius oluşturabilir.

Güvenilmeyen Modules

Public module yüzlerce resource oluşturabilir. Source code review yapılmalıdır. Maintainer ve release history incelenir. Version pinlenir. Critical kullanımda internal fork veya verified registry tercih edilebilir.

Provider Güvenliği

Provider binary cloud credential ile çalışır. Trusted registry kullanılmalıdır. Checksum lock file tarafından doğrulanabilir. Yeni provider review edilir. CI network erişimi mümkün olduğunca sınırlandırılır.

Version Pinning

Unbounded latest dependency risklidir. Exact veya kontrollü range kullanılır. Upgrade pull request ile yapılır. Changelog incelenir. Security patch geciktirilmeden fakat kontrollü alınmalıdır.

Module Provenance

Module'un kim tarafından ve hangi repository'den üretildiği bilinmelidir. Signed release değerlendirilebilir. Private registry trusted artifact sunar. Commit hash belirli source version'ı sabitleyebilir. Provenance metadata audit için değerlidir.

Dependency Review

Yeni module veya provider eklenmesi normal code dependency gibi review edilmelidir. License kontrol edilir. Security history incelenir. İhtiyaç gerçekten var mı değerlendirilir. Dependency sayısı gereksiz büyütülmemelidir.

Third-Party IaC Kodlarını İncelemek

README'e güvenmek yeterli değildir. Resource permission ve network davranışı source code üzerinden görülmelidir. Plan test account'ta çalıştırılır. Unexpected external data source kontrol edilir. Production adoption buna göre yapılır.

GitOps ile IaC Arasındaki Fark

IaC altyapının kodla tanımlanması ve provision edilmesini çözerken GitOps desired state değişikliklerinin Git üzerinden sürekli reconciliation ile uygulanmasına odaklanır. İki kavram örtüşür fakat aynı değildir. Terraform CI pipeline push-based apply yapabilir ve yine IaC kullanır. Kubernetes GitOps controller Git'ten configuration çekip sürekli uygulayabilir. Birlikte kullanıldıklarında infrastructure provisioning ve application platform reconciliation arasında güçlü otomasyon zinciri kurulabilir.

IaC Neyi Çözer?

Infrastructure resource definition ve lifecycle yönetimini kodlaştırır. Reproducibility sağlar. Plan ve apply workflow sunabilir. Git kullanımı zorunlu kavram değildir ama yaygındır. Cloud provisioning temel kullanım alanıdır.

GitOps Neyi Çözer?

Git desired state'in merkezi kaynağı olur. Controller değişiklikleri sürekli çeker ve reconcile eder. Deployment credential developer makinesinde bulunmaz. Drift otomatik kapatılabilir. Kubernetes application delivery'de yaygın modeldir.

Push-Based Deployment

CI runner cloud API'ye bağlanıp değişikliği uygular. Terraform pipeline yaygın örnektir. Credential CI tarafında bulunur. Apply job başarısız olabilir. Drift detection ayrıca schedule edilir.

Pull-Based Reconciliation

Cluster içindeki controller Git'ten desired state'i çeker. External CI doğrudan production API'ye yazmak zorunda değildir. Controller sürekli farkı düzeltir. Git commit deployment trigger olur. Access model daha farklıdır.

Git as the Source of Truth

Approved state repository'de bulunur. Runtime manual değişiklik geçici kabul edilir. Controller veya operator Git'e dönmeye çalışır. Emergency workflow gerekir. Audit commit history üzerinden kolaylaşır.

IaC ve GitOps Birlikte Nasıl Kullanılır?

Terraform Kubernetes cluster ve network oluşturabilir. GitOps controller cluster application ve platform configuration'ını yönetebilir. Sınırlar açık olmalıdır. Aynı Kubernetes object iki araç tarafından yönetilmemelidir. Platform lifecycle iki katmanda standardize edilebilir.

Infrastructure as Code ve Platform Engineering

Platform engineering IaC module ve otomasyonlarını geliştiricilerin kullanabileceği ürünlere dönüştürür. Platform ekibi güvenli cloud pattern'lerini reusable component ve self-service API olarak sunar. Application ekibi her network veya IAM ayrıntısını öğrenmek zorunda kalmaz. Golden path hız ve governance arasında denge kurar. IaC burada arka plandaki implementation mechanism olurken developer experience daha yüksek seviyeli platform interface üzerinden sağlanabilir.

Platform Team

Ortak cloud ve deployment capability geliştirir. Module ve policy owner olabilir. Reliability ve security standard'larını uygular. App team feedback'i roadmap'e alınır. Platform iç müşteri için ürün gibi yönetilir.

Application Team

Servis ve business logic'e odaklanır. Platformun sunduğu infrastructure product'larını tüketir. Parametrelerle gerekli kapasiteyi seçer. Low-level IAM veya network ayrıntısı azalır. Gerektiğinde escape hatch bulunabilir.

Self-Service Infrastructure

Portal, CLI veya API üzerinden environment talep edilebilir. Arkada IaC pipeline çalışır. Policy otomatik uygulanır. Ticket bekleme süresi azalır. Approval yalnız yüksek riskli taleplerde kullanılır.

Golden Paths

Önerilen deployment ve infrastructure pattern'idir. Zorunlu tek yol olmak zorunda değildir. Security ve observability varsayılan hazır gelir. Yeni servis açmak hızlanır. Platform adoption developer deneyimine bağlıdır.

Internal Developer Platform

İç geliştirici platformu infrastructure ve delivery capability'lerini ortak interface altında sunar. Service catalog ve environment management içerebilir. IaC implementation ayrıntısını gizleyebilir. Ownership ve lifecycle yönetir. Başarısı ticket azalması ve deployment hızıyla ölçülebilir.

Reusable Infrastructure Products

Database veya Kubernetes cluster bir ürün gibi versionlanabilir. SLO ve support owner tanımlanır. Consumer stable interface kullanır. Upgrade roadmap sunulur. Module tek başına platform product değildir, operasyon ve support da gerekir.

Governance Without Tickets

Security rule policy as code içinde uygulanabilir. Kullanıcı her talep için manuel approval beklemez. Uygun configuration otomatik geçer. Exception özel akışa yönlenir. Governance delivery hızını durdurmadan uygulanabilir.

IaC ile Disaster Recovery

IaC disaster recovery sırasında compute, network ve managed service altyapısını yeniden oluşturmayı hızlandırır. Ancak infrastructure code veri yedeklerinin yerini tutmaz. Database içeriği, object storage verisi ve encryption key için ayrı backup stratejisi gerekir. Multi-region topology kodla önceden hazırlanabilir. DR test otomasyonu teorik recovery planının gerçekten çalışıp çalışmadığını gösterir.

Ortamı Baştan Oluşturabilme

IaC yeni region'da temel infrastructure oluşturabilir. Manual adım sayısı azalır. Dependency sırası kodda bulunur. Recovery time ölçülebilir. Provider quota önceden kontrol edilmelidir.

Multi-Region Infrastructure

Aynı module iki region için kullanılabilir. Region-specific variable tanımlanır. DNS veya global load balancing ayrıca kurulur. Data replication infrastructure'dan farklı konudur. Failover düzenli test edilmelidir.

Infrastructure Code ile Backup Arasındaki Fark

IaC database instance'ını oluşturabilir. İçindeki veriyi kendiliğinden geri getirmez. Backup storage ve retention ayrıca gerekir. Restore resource provisioning sonrası yapılır. İki süreç runbook içinde birlikte tanımlanmalıdır.

Data'nın IaC ile Geri Gelmemesi

Empty database oluşturmak recovery değildir. Snapshot veya log restore gerekir. Secret ve key de erişilebilir olmalıdır. RPO hedefi backup frequency'yi belirler. IaC yalnız platform iskeletini tekrar üretir.

Recovery Runbook

Hangi stack'in hangi sırada uygulanacağı yazılır. Data restore adımları eklenir. DNS cutover tanımlanır. Validation checklist bulunur. Runbook automation zaman içinde artırılabilir.

DR Test Automation

Test account'ta periyodik recovery yapılabilir. IaC clean deployment doğrulanır. Backup restore edilir. Application smoke test çalışır. Ölçülen RTO hedefle karşılaştırılır.

Multi-Cloud IaC Gerçekten Gerekli mi?

Multi-cloud stratejisi yalnız tek IaC aracı kullanmakla oluşmaz. AWS ve Azure aynı Terraform syntax altında yönetilse bile servis modelleri farklıdır. İkinci cloud operasyon ve güvenlik yükünü ciddi ölçüde artırır. İş gereksinimi yoksa soyut bir cloud-agnostic hedef gereksiz maliyet oluşturabilir. IaC aracı portability sağlar, fakat application architecture'ın gerçekten taşınabilir olması ayrı konudur.

Multi-Cloud'un Avantajları

Vendor concentration riski azaltılabilir. Regulatory requirement farklı provider gerektirebilir. Belirli servis avantajları kullanılabilir. Acquisition sonrası farklı cloud'lar birlikte yönetilebilir. Gerçek ihtiyaç olduğunda common tooling operasyonu kolaylaştırır.

Multi-Cloud'un Operasyonel Maliyeti

İki IAM modeli öğrenilir. Network ve security tool'ları farklıdır. On-call ekip daha geniş bilgi taşır. Cost management zorlaşır. Availability hedefi otomatik olarak artmaz.

Ortak IaC Aracı Kullanmanın Avantajı

Terraform veya OpenTofu aynı workflow sağlar. Plan ve module convention ortaklaşır. CI pipeline tekrar kullanılabilir. Developer switching cost azalır. Cloud resource semantics yine öğrenilmelidir.

Cloud-Native Özellikleri Kaybetme Riski

Aşırı ortak abstraction provider-specific güçlü servisi gizleyebilir. Lowest common denominator architecture oluşabilir. Performance ve cost avantajı kaçırılabilir. Module cloud-specific olabilir. Ortak workflow ile native özellik kullanımı birlikte mümkündür.

Cloud-Agnostic ile Cloud-Portable Arasındaki Fark

Cloud-agnostic hiçbir provider özelliğine bağımlı olmamayı hedefler. Cloud-portable migration'ın mümkün olmasını hedefleyebilir. İkinci yaklaşım daha gerçekçidir. Data ve service migration maliyeti planlanır. IaC code portability toplam migration maliyetinin yalnız bir bölümüdür.

IaC Değişikliklerinde Blast Radius Nasıl Azaltılır?

Blast radius tek hatalı değişikliğin ne kadar altyapıyı etkileyebileceğini ifade eder. Bütün şirket altyapısını tek state içinde tutmak küçük hatayı geniş incident'a çevirebilir. Component boundary ve environment isolation riski sınırlar. Plan review ve policy yanlış değişikliği apply öncesinde yakalayabilir. Progressive deployment kritik altyapı değişikliğinin küçük kapsamda doğrulanmasını sağlar.

Küçük Stack'ler

Network ve application stack ayrılabilir. Değişiklik yalnız ilgili resource grubunu etkiler. State lock süresi kısalır. Team ownership daha net olur. Aşırı parçalama cross-stack dependency sayısını artırabilir.

Component Boundaries

Resource'lar lifecycle ve ownership'e göre gruplanır. Shared network ayrı component olabilir. Application database başka sınırda tutulur. Dependency interface output üzerinden tanımlanır. Boundary organization yapısıyla uyumlu olmalıdır.

Ayrı State Files

Her component kendi state'ine sahip olabilir. Yanlış apply bütün platformu etkilemez. Concurrent deployment kolaylaşır. Cross-state data paylaşımı dikkatle yapılır. State sayısı operasyon tooling'iyle yönetilmelidir.

Environment Isolation

Dev apply production hesabına erişememelidir. Ayrı account güçlü kontrol sağlar. Credential environment-specific olur. Yanlış variable etkisi sınırlanır. Network connection explicit tanımlanır.

Plan Review

Destroy ve replacement önceden görülür. Unexpected resource count dikkat çeker. Reviewer blast radius'u değerlendirir. Saved plan kullanılır. High-risk değişiklik ek approval gerektirir.

Policy Enforcement

Critical resource deletion policy ile engellenebilir. Public network rule block edilir. Production region sınırı uygulanır. Policy otomatik kontrol sağlar. Exception kontrollü workflow ister.

Progressive Deployment

Yeni module version önce dev'de kullanılır. Sonra staging ve küçük production scope'a geçer. Metric izlenir. Sorun varsa rollout durdurulur. Infrastructure change de application release gibi kademeli yapılabilir.

Break-Glass Infrastructure Changes Nasıl Yönetilir?

Incident sırasında normal pull request süreci çok yavaş kalabilir ve manuel cloud müdahalesi gerekebilir. Break-glass access bu acil duruma kontrollü kapı sağlar. Yetki süreli, sınırlı ve audit edilebilir olmalıdır. Incident bittikten sonra yapılan değişiklik IaC koduna backport edilmelidir. Emergency access kapatılmadan ve drift giderilmeden süreç tamamlanmış sayılmamalıdır.

Incident Sırasında Manuel Müdahale

Production availability için hızlı firewall veya scaling değişikliği gerekebilir. Yetkili kişi break-glass role alır. İşlem minimum kapsamda yapılır. Normal credential yerine özel emergency erişim kullanılır. Değişiklik incident kaydına yazılır.

Manuel Değişikliği Audit Etmek

Cloud audit log kullanıcı ve API işlemini gösterir. Incident timeline'a eklenir. Değişikliğin nedeni açıklanır. Security review gerekebilir. Sonradan hangi resource'un farklılaştığı net görülür.

Değişikliği IaC'a Backport Etmek

Manuel çözüm kalıcı olacaksa code güncellenir. PR incident'a referans verir. Plan runtime state ile uyumlu hale gelir. Geçici değişiklikse code eski desired state'i korur. Sonraki apply bilinçli biçimde davranır.

Drift'i Kapatmak

Plan artık beklenmeyen fark göstermemelidir. Manual change ya geri alınır ya configuration'a eklenir. Drift alert çözülür. Root cause automation eksikliği gösteriyorsa module güncellenir. Incident learning platform standardına dönüşür.

Emergency Access'i Sonlandırmak

Süreli credential otomatik expire olabilir. Temporary role kaldırılır. Session log saklanır. Normal least privilege modele dönülür. Açık emergency access uzun vadeli güvenlik açığı bırakmamalıdır.

IaC Başarısı Nasıl Ölçülür?

IaC adoption yalnız repository'deki Terraform dosyası sayısıyla ölçülmemelidir. Asıl hedef environment oluşturma süresini azaltmak, change güvenilirliğini artırmak ve manuel müdahaleyi düşürmektir. Deployment frequency ve change failure rate operasyon etkisini gösterir. Drift ve policy violation metrikleri governance kalitesini ölçer. Module reuse oranı platform standard'larının gerçekten kullanılıp kullanılmadığını görünür hale getirebilir.

Time-to-Environment

Yeni environment talebinden kullanılabilir hale gelmesine kadar geçen süredir. Ticket günlerinden dakikalara düşebilir. Self-service etkisini gösterir. Approval süresi ayrıca ölçülebilir. Environment quality aynı anda korunmalıdır.

Infrastructure Deployment Frequency

Ekip ne kadar sık güvenli infrastructure change yapabiliyor sorusunu cevaplar. Çok düşük frequency korku veya manual süreç gösterebilir. Yüksek frequency tek başına başarı değildir. Failure rate ile birlikte değerlendirilir. Component bazında ölçülebilir.

Change Lead Time

Commit ile production apply arasındaki süredir. Review ve approval darboğazını gösterir. Critical environment için hedef farklı olabilir. Automated test süreyi azaltır. Uzun queue platform problemi işareti olabilir.

Change Failure Rate

Infrastructure deployment'ların ne kadarı incident veya rollback gerektiriyor ölçülür. Riskli module tespit edilebilir. Test ve review iyileştirmeleri etkisi görülür. Severity ayrımı yapılabilir. Küçük warning failure sayılmamalıdır.

Deployment Success Rate

Planlanan apply'ların başarı oranıdır. Provider API ve state issue'ları görünür olur. Retry sonrası başarı ayrıca izlenebilir. Sürekli transient failure normal kabul edilmemelidir. Root cause category faydalıdır.

Drift Sayısı

Manuel veya external değişiklik sayısını gösterir. Environment bazında ölçülür. Artış ClickOps alışkanlığını gösterebilir. Emergency drift ayrı kategori olabilir. Amaç her zaman mutlak sıfır olmayabilir.

Mean Time to Remediate Drift

Drift tespitinden çözülmesine kadar geçen süredir. Security drift için kısa hedef gerekir. Ownership ve alert kalitesini ölçer. Automation süreyi azaltabilir. Root cause tekrar sayısı ayrıca takip edilir.

Manuel Cloud Değişikliği Oranı

Toplam infrastructure change içinde console veya manual API değişikliklerinin oranıdır. IaC adoption ilerledikçe düşmesi beklenir. Emergency action ayrı tutulur. Audit log verisi kullanılabilir. Yüksek oran workflow sürtünmesine işaret edebilir.

Module Reuse Rate

Yeni service'lerin ne kadarı standard module kullanıyor ölçülebilir. Düşük oran developer deneyimi problemini gösterebilir. Zorla kullanım iyi metric üretip kötü sonuç oluşturabilir. Kullanıcı feedback'i birlikte değerlendirilmelidir. Module kalitesi ve adoption ilişkisi izlenir.

Policy Violation Rate

PR başına security veya compliance violation sayısı ölçülebilir. Zaman içinde azalması eğitim etkisini gösterir. Çok yüksek false positive adoption'ı düşürür. Rule kategori bazında analiz edilir. Platform standard'ı sık yapılan hataları default ile önleyebilir.

Infrastructure as Code İçin Hangi Programlama Dili Kullanılır?

IaC için HCL, YAML ve JSON gibi domain veya configuration dilleri kullanılabilir. Pulumi ve CDK gibi araçlar Python, TypeScript, Go, C# ve Java ile çalışabilir. Dil seçimi IaC aracının çalışma modelinden ayrı değerlendirilmemelidir. Ekip TypeScript biliyor diye programmatic IaC otomatik olarak doğru seçim değildir. State, provider ekosistemi, testing ve uzun vadeli platform yönetimi dil tercihi kadar önemlidir.

HCL

Terraform ve OpenTofu ekosisteminin temel configuration dilidir. Declarative resource tanımına uygundur. Okunabilirliği genellikle yüksektir. Dynamic block aşırı kullanıldığında zorlaşabilir. Geniş community örneği bulunur.

YAML

CloudFormation ve Ansible gibi araçlarda yaygındır. İnsan tarafından kolay okunabilir. Indentation hataları sorun olabilir. Programlama logic'i sınırlıdır. Template büyüdükçe modularity önem kazanır.

JSON

Makine üretimi ve API entegrasyonu için uygundur. Comment ve readability YAML'a göre zayıf olabilir. CloudFormation ve policy document'lerde kullanılır. Generated artifact olarak yaygındır. İnsan authoring için her zaman ilk tercih değildir.

Python

Pulumi ve CDK ekosisteminde kullanılabilir. Automation ekiplerine tanıdıktır. Dynamic typing dikkat gerektirir. Test framework güçlüdür. Dependency environment standardize edilmelidir.

TypeScript

Strong typing ve JavaScript ekosistemi avantaj sağlar. Pulumi ve CDK için yaygın tercihtir. IDE autocomplete geliştirici deneyimini iyileştirir. Async resource output kavramı öğrenilmelidir. Genel amaçlı dil abstraction kontrol edilmelidir.

Go

Platform engineer'lar arasında yaygındır. Static typing ve hızlı tooling sunar. Pulumi kullanılabilir. Internal platform CLI ile aynı dil paylaşılabilir. Kod miktarı DSL'e göre artabilir.

C#

.NET ekipleri mevcut becerilerini kullanabilir. Pulumi veya CDK desteği bulunabilir. Strong typing faydalıdır. Enterprise tooling güçlüdür. IaC ve application package dependency'leri ayrılmalıdır.

Java

Büyük kurumsal ekiplerde yaygındır. Programmatic IaC için kullanılabilir. Compile-time kontrol sağlar. Build lifecycle ek configuration gerektirir. Sade infrastructure intent korunmalıdır.

“En İyi Programlama Dili” Yerine IaC Aracı Nasıl Seçilir?

Önce cloud ve provider ihtiyacı belirlenmelidir. State ve deployment workflow değerlendirilir. Ekip hangi testing modelini kullanacak sorusu cevaplanır. Lisans ve support gereksinimi incelenir. Dil bu kararların içindeki geliştirme deneyimi bileşenlerinden biri olarak ele alınmalıdır.

Terraform, OpenTofu ve Pulumi Nasıl Seçilir?

Üç araç da modern IaC ihtiyacını çözebilir fakat geliştirme modeli ve ekosistem yaklaşımı farklıdır. Terraform ve OpenTofu HCL tabanlı deklaratif model sunar. Pulumi genel amaçlı dillerle programmatic yaklaşım sağlar. Lisans ve governance Terraform ile OpenTofu ayrımında önemli hale gelmiştir. Ekip yetkinliği kadar state operasyonu, provider compatibility ve uzun vadeli support modeli değerlendirilmelidir.

DSL vs Genel Amaçlı Programlama Dili

DSL infrastructure intent'i sınırlı ve açık tutabilir. Genel dil güçlü abstraction sağlar. Complex logic programmatic modelde daha kolaydır. Basit resource graph HCL'de daha okunabilir olabilir. Ekip gerçek complexity ihtiyacını ölçmelidir.

Ekosistem

Provider ve module sayısı adoption'ı etkiler. Terraform ekosistemi oldukça geniştir. OpenTofu compatibility güçlüdür fakat bağımsız gelişebilir. Pulumi kendi provider paketleriyle çalışır. Gerekli kritik servislerin desteği pilotta doğrulanmalıdır.

State Management

Üç araç da resource state yönetimine ihtiyaç duyar. Backend modeli farklılık gösterebilir. Managed SaaS veya self-hosted seçenekleri değerlendirilir. Locking ve encryption önemlidir. Migration state portability açısından test edilmelidir.

Multi-Cloud

Hepsi farklı cloud provider'larla çalışabilir. Ortak tooling avantaj sağlar. Module yine cloud-specific olabilir. Multi-cloud hedefi yalnız syntax ortaklığına indirgenmemelidir. Provider quality kaynak bazında değerlendirilir.

Testing

Terraform ve OpenTofu static validation ve IaC test araçlarıyla çalışır. Pulumi normal language test framework'lerini doğal biçimde kullanabilir. Integration test hepsinde cloud maliyeti taşır. Plan validation güçlü ortak yöntemdir. Test strategy ekip maturity'sine göre seçilir.

Lisans

Terraform çekirdek ürününün güncel lisans modeli source-available kapsamındadır. OpenTofu açık kaynak alternatifidir. Pulumi'nin ürün ve açık kaynak bileşenleri kendi lisans koşullarıyla değerlendirilmelidir. Kurumsal kullanım ve hosted offering farkı önemlidir. Hukuk review teknik seçim sürecine eklenmelidir.

Ekip Yetkinlikleri

HCL bilen platform ekibi Terraform veya OpenTofu ile hızlı ilerleyebilir. TypeScript developer ağırlıklı ekip Pulumi'yi doğal bulabilir. Tool öğrenmek cloud bilgisinin yerini tutmaz. Training maliyeti hesaplanmalıdır. Standard bütün organization için anlaşılır olmalıdır.

Operasyonel Karmaşıklık

Managed backend operasyon yükünü azaltabilir. Self-hosted kontrolü artırır. Provider upgrade ve state recovery süreçleri karşılaştırılır. CI integration kolaylığı önemlidir. Tool seçimi günlük on-call deneyimini de dikkate almalıdır.

Open Source ve İşbirliğinin IaC Ekosistemindeki Rolü

IaC ekosistemi provider, module ve policy projelerinde yoğun açık kaynak katkısından yararlanır. OpenTofu açık governance modelinin önemli örneklerinden biridir. Open Policy Agent güvenlik ve policy otomasyonunda farklı sistemler tarafından kullanılabilir. Crossplane Kubernetes tabanlı control plane yaklaşımını topluluk katkısıyla geliştirir. Community module paylaşımı öğrenmeyi hızlandırırken production kullanımı öncesinde güvenlik ve bakım kalitesi mutlaka değerlendirilmelidir.

OpenTofu

OpenTofu açık kaynak IaC alternatifi sunar. Topluluk issue ve pull request ile katkıda bulunabilir. Governance farklı organizasyonların katılımına açıktır. Terraform deneyimi adoption'ı kolaylaştırabilir. Production support modeli ayrıca seçilebilir.

Open Policy Agent

OPA policy decision'larını uygulamadan ayırır. IaC planlarıyla entegre olabilir. Rego policy community tarafından paylaşılabilir. Kubernetes ve API authorization'da da kullanılır. Ortak policy dili kurum içinde standardization sağlayabilir.

Crossplane

Crossplane Kubernetes reconciliation modelini cloud resource'lara taşır. Provider ve composition community geliştirmesine açıktır. Platform API oluşturmayı kolaylaştırır. Custom resource abstraction güçlüdür. Kubernetes deneyimi adoption için önemlidir.

Community Modules

Hazır module geliştirme süresini kısaltır. Common cloud pattern'leri öğrenilebilir. Her module production standardına uygun değildir. Version ve maintainer incelenmelidir. Güvenlik review zorunlu tutulabilir.

Provider Geliştirme

Yeni API için custom provider yazılabilir. Provider SDK resource lifecycle modelini destekler. Internal SaaS platformu IaC ile yönetilebilir hale gelir. Testing ve versioning gerekir. Community provider upstream contribution olarak paylaşılabilir.

GitHub Üzerinden Katkı

Issue açmak bile değerli katkıdır. Reproduction adımları maintainer işini kolaylaştırır. Documentation PR ile başlanabilir. Provider bug fix daha ileri katkı olabilir. Açık iletişim ecosystem bilgisini geliştirir.

Module ve Template Paylaşımı

Topluluk common architecture pattern'lerini paylaşabilir. Eğitim workshop'larında reusable örnekler kullanılır. Secret veya gerçek account bilgisi paylaşılmamalıdır. Security default iyi tasarlanmalıdır. Örnek code version güncel tutulmalıdır.

Güvenlik Açıklarının Topluluk Tarafından İncelenmesi

Açık kod birçok geliştirici tarafından incelenebilir. Bu otomatik güvenlik garantisi değildir. Responsible disclosure süreci gerekir. Maintainer response hızı önemlidir. Kurum yine kendi dependency review'unu yapmalıdır.

Yazılım Topluluklarının IaC Öğrenimindeki Rolü

Infrastructure as Code yalnız dokümantasyon okuyarak tam öğrenilen bir alan değildir. Network, IAM ve state hataları gerçek laboratuvar ortamında daha iyi anlaşılır. Yazılım toplulukları workshop ve ortak projelerle bu deneyimi daha erişilebilir hale getirebilir. Açık kaynak module geliştirmek hem Git hem cloud hem code review pratiği kazandırır. Terraform ve IaC DevOps danışmanlığı yakınımda gibi aramalar yapan geliştiriciler için yerel topluluk etkinlikleri de teknik öğrenme ve deneyim paylaşımı açısından güçlü başlangıç noktası olabilir.

Terraform/OpenTofu Workshop'ları

Katılımcılar gerçek cloud sandbox üzerinde network oluşturabilir. Plan ve apply farkı görülür. Remote state birlikte kurulur. Deliberate drift oluşturulup düzeltilir. Workshop teori yerine operasyon döngüsünü öğretir.

Cloud Infrastructure Laboratuvarları

Temporary account güvenli deney alanı sağlar. IAM ve network senaryoları uygulanabilir. Cost limit önceden belirlenir. Lab sonunda resource destroy edilir. Katılımcılar hata yapmanın sonuçlarını production riski olmadan görür.

DevOps Hackathon'ları

Kısa sürede çalışan platform prototipi oluşturulabilir. CI/CD ve IaC birlikte kullanılır. Ekipler problem çözme pratiği kazanır. Security policy challenge eklenebilir. Sonuçlar community review ile geliştirilir.

Açık Kaynak Module Geliştirme

Topluluk ortak VPC veya container platform module'ü geliştirebilir. Issue ve PR workflow uygulanır. Semantic versioning öğrenilir. Security scanning eklenir. Gerçek open source maintenance deneyimi kazanılır.

Diyarbakır Yazılım Topluluğu İçin IaC Proje Fikirleri

Diyarbakır Yazılım Topluluğu için düşük maliyetli cloud sandbox otomasyonu iyi bir başlangıç projesi olabilir. Terraform veya OpenTofu ile network ve compute kaynakları oluşturulup CI pipeline ile güvenlik kontrolü eklenebilir. İkinci aşamada drift detection ve policy as code uygulanabilir. Topluluğun proje çalışmalarını https://www.diyarbakiryazilim.com.tr/projects adresinden inceleyerek benzer teknik üretimlerin nasıl yapılandırıldığı görülebilir. Böyle bir çalışma yalnız IaC syntax öğretmek yerine Git, cloud security, CI/CD ve takım içi code review yetkinliklerini aynı proje içinde geliştirebilir.

Yazılımcı Olmak İsteyenler IaC Alanında Nasıl İlerlemeli?

IaC öğrenmeye doğrudan yüzlerce Terraform resource ezberleyerek başlamak verimli değildir. Linux, networking, Git ve cloud temel kavramları önce anlaşılmalıdır. Sonra Terraform veya OpenTofu ile küçük environment oluşturulabilir. CI/CD, IAM ve Kubernetes bilgisi ilerleyen aşamada eklenebilir. Açık kaynak projelerde issue ve module katkısı gerçek production düşünme biçimini geliştirir.

Linux Temelleri

Process, file permission ve networking kavramları öğrenilmelidir. VM içinde ne olduğunu anlamadan compute provisioning eksik kalır. SSH ve systemd pratiği faydalıdır. Log ve disk yönetimi bilinmelidir. Container altyapısını anlamayı da kolaylaştırır.

Networking

CIDR, subnet ve routing temel kavramlardır. Security group ve firewall mantığı öğrenilir. DNS ve load balancing IaC projelerinde sürekli kullanılır. Private ve public network farkı anlaşılmalıdır. Küçük VPC laboratuvarı güçlü pratik sağlar.

Git

Commit, branch ve pull request bilinmelidir. Infrastructure change review Git üzerinden yapılır. Revert ve history debugging için kullanılır. Secret commit etme riski öğrenilmelidir. CI trigger repository event'lerine dayanır.

Cloud Computing

Önce tek provider üzerinde temel servisler öğrenilebilir. IAM, compute, network ve storage yeterli başlangıçtır. Managed database ve queue sonra eklenir. Fiyatlama temel olarak anlaşılmalıdır. Console üzerinden öğrenilen resource daha sonra IaC ile kurulabilir.

Terraform veya OpenTofu

İlk proje network ve küçük VM olabilir. Variables ve outputs kullanılır. State davranışı gözlemlenir. Sonra module ve remote backend eklenir. Plan sonucu ezberden çok dikkatle yorumlanmalıdır.

CI/CD

Validate ve plan pipeline'a taşınır. Pull request review uygulanır. OIDC credential kullanılır. Production apply approval eklenir. Security scan ile workflow genişletilir.

Docker ve Kubernetes

Container platform modern infrastructure'ın önemli parçasıdır. IaC cluster ve supporting network oluşturabilir. Kubernetes manifests GitOps ile yönetilebilir. State ve application configuration sınırları anlaşılır. Crossplane gibi araçları öğrenmek kolaylaşır.

Security ve IAM

Least privilege temel ilkedir. Role ve policy tasarımı öğrenilir. Secret management ve OIDC uygulanır. Public network riskleri anlaşılır. Security IaC'ın son aşamasına bırakılmamalıdır.

Açık Kaynak Projelere Katkı

Documentation issue ile başlanabilir. Module örneği geliştirilebilir. Test veya bug reproduction yapılabilir. Community code review farklı yaklaşımları öğretir. Portföy açısından da gerçek teknik üretim sağlar.

İlk IaC Projesi Nasıl Yapılır?

İlk IaC projesi mümkün olduğunca küçük tutulmalıdır. Basit network ve compute resource hem provider hem state hem dependency mantığını öğrenmek için yeterlidir. Ardından variables, outputs ve remote state eklenebilir. Git ve CI süreçleri ikinci aşamada projeyi gerçek ekip çalışma modeline yaklaştırır. Security scan, policy ve drift detection eklendiğinde küçük laboratuvar production yaklaşımının temel bileşenlerini kapsar.

Adım 1 — Cloud Hesabı Oluşturma

Öğrenme için ayrı sandbox account kullanılmalıdır. Budget alarmı kurulmalıdır. Production credential kullanılmamalıdır. MFA etkinleştirilmelidir. Deneme resource'ları düzenli temizlenmelidir.

Adım 2 — IaC Aracı Seçme

Terraform veya OpenTofu başlangıç için uygundur. Tek tool ile temel kavramlar öğrenilir. Lisans ve kurulum farkı incelenebilir. Local binary version sabitlenir. Çok araç aynı anda öğrenilmeye çalışılmamalıdır.

Adım 3 — Provider Yapılandırma

Cloud provider seçilir. Region tanımlanır. Credential koda yazılmaz. CLI veya OIDC authentication kullanılabilir. Provider version constraint eklenir.

Adım 4 — Basit Bir Network Oluşturma

VPC ve subnet tanımlanır. CIDR mantığı uygulanır. Public ve private farkı gözlemlenir. Plan incelenir. Apply sonrası cloud console yalnız doğrulama için kullanılabilir.

Adım 5 — Compute Resource Eklemek

Küçük VM oluşturulur. Network dependency referansla kurulur. Security rule minimum tutulur. Output olarak IP alınabilir. Cost nedeniyle test sonrası resource kaldırılır.

Adım 6 — Variables Kullanmak

Region ve instance type variable yapılır. Default değer eklenebilir. Validation kullanılabilir. Environment-specific config ayrılır. Secret variable koddan uzak tutulur.

Adım 7 — Outputs Oluşturmak

Resource ID veya endpoint dışarı verilir. Output public interface kavramını öğretir. Sensitive değerlerden kaçınılır. Başka module kullanımına hazırlık sağlar. CLI output gözlemlenir.

Adım 8 — Plan'ı İncelemek

Her resource action tek tek okunur. Replacement ve destroy işaretleri öğrenilir. Code değişikliğiyle plan ilişkisi gözlemlenir. Aynı code tekrar plan edildiğinde değişiklik olmaması beklenir. Bu alışkanlık production güvenliği için önemlidir.

Adım 9 — Apply

Onaylanan değişiklik uygulanır. Provider API işlemleri gözlemlenir. State güncellenir. Resource health kontrol edilir. Failure durumunda plan yeniden incelenir.

Adım 10 — State'i Remote Backend'e Taşımak

Cloud object storage backend kurulabilir. Encryption etkinleştirilir. Versioning açılır. Locking destekleniyorsa kullanılır. Local state güvenli biçimde migrate edilir.

Adım 11 — Git Repository Oluşturmak

IaC dosyaları repository'ye eklenir. State ignore edilir. README hazırlanır. İlk commit geçmiş oluşturur. Branch protection daha sonra eklenebilir.

Adım 12 — CI Pipeline Eklemek

PR açıldığında format ve validate çalışır. Plan output üretilebilir. Credential read-only scope ile başlar. Merge sonrası apply ayrı job olabilir. Pipeline log güvenli tutulur.

Adım 13 — Security Scan Eklemek

IaC scanner repository'yi kontrol eder. Public port intentional olarak test edilebilir. Rule sonucunun nasıl çıktığı görülür. High severity merge'i durdurabilir. Exception süreci öğrenilir.

Adım 14 — Policy Check Eklemek

Tag veya region policy yazılabilir. PR aşamasında değerlendirilir. Yanlış config fail eder. Policy code Git içinde versionlanır. Governance automation pratiği kazanılır.

Adım 15 — Drift Detection Kurmak

Console'dan küçük manuel değişiklik yapılabilir. Scheduled plan farkı yakalar. Alert oluşturulur. Değişiklik code veya cloud tarafında düzeltilir. Böylece full IaC lifecycle deneyimlenir.

Kurumsal IaC Olgunluk Modeli

Kurumsal IaC adoption tek seferde manuel yapıdan self-service platforma geçmez. Olgunluk aşamalı ilerler. Önce tekil script'ler version control altına alınır, sonra CI/CD ve test eklenir. Shared module ve policy standardizasyonu bir sonraki adımı oluşturur. En ileri seviyede application ekipleri kontrollü self-service platform üzerinden altyapı tüketirken drift sürekli yönetilir.

Seviye 0 — Manuel Provisioning

Cloud console ana yönetim aracıdır. Değişiklikler kişisel bilgiye bağlıdır. Environment farkları yüksektir. Audit zayıftır. İlk hedef en kritik resource'ları envanterlemektir.

Seviye 1 — Tekil IaC Scriptleri

Bazı resource'lar kodla oluşturulur. Ortak repository standardı olmayabilir. Local state kullanılabilir. Ekip temel kavramları öğrenir. Manuel değişiklikler devam eder.

Seviye 2 — Version-Controlled IaC

Kod Git repository'de tutulur. Pull request kullanılır. Remote state standardı başlar. Ownership görünür olur. Değişiklik geçmişi audit edilebilir hale gelir.

Seviye 3 — CI/CD ve Automated Testing

Validate ve plan otomatik çalışır. Security scan eklenir. Apply pipeline üzerinden yapılır. Production approval uygulanır. Manual laptop deployment azalır.

Seviye 4 — Modules ve Standards

Reusable module catalog oluşturulur. Naming ve tagging standard'ı merkezi hale gelir. Module versioning uygulanır. App team ortak pattern kullanır. Platform ownership gelişir.

Seviye 5 — Policy as Code ve Continuous Drift Management

Security ve compliance kuralları otomatik enforce edilir. Drift scheduled izlenir. Break-glass process standardize edilir. Policy exception audit edilir. Runtime ve Git state arasındaki fark sürekli yönetilir.

Seviye 6 — Self-Service Platform Engineering

Application ekipleri infrastructure product'larını portal veya API üzerinden tüketir. Golden path varsayılan güvenlik sağlar. Ticket bağımlılığı azalır. Platform metric'lerle yönetilir. IaC kullanıcıdan büyük ölçüde gizlenen implementation katmanına dönüşebilir.

Infrastructure as Code'da Yapılan Yaygın Hatalar

IaC adoption sırasında en sık görülen hatalar genellikle state, dependency ve manuel değişiklik yönetiminden kaynaklanır. Local state production'da kullanıldığında ekip çalışması riskli hale gelir. Provider version pinlenmediğinde aynı code farklı tarihte farklı plan üretebilir. Security ve policy sonradan eklenirse hatalı pattern çok sayıda module içine yayılmış olabilir. Brownfield migration ve drift yönetimi özellikle kontrollü yapılmalıdır.

Local State'i Production'da Kullanmak

Laptop tek hata noktası olur. Ekip aynı state'e erişemez. Locking bulunmaz. Backup zayıftır. Remote backend production standardı olmalıdır.

State'i Git'e Commit Etmek

State secret içerebilir. Repository history'de kalıcı hale gelir. Concurrent edit riski oluşur. Remote backend kullanılmalıdır. Yanlışlıkla commit edilen secret rotate edilmelidir.

Provider Version'larını Pinlememek

Yeni provider beklenmedik breaking behavior getirebilir. Build tekrar üretilemez olur. Lock file kullanılmalıdır. Upgrade PR üzerinden yapılır. Changelog incelenmelidir.

Manuel Cloud Console Değişikliklerini Sürdürmek

Git source of truth olmaktan çıkar. Drift artar. Sonraki apply manuel değişikliği geri alabilir. Break-glass dışında console write sınırlandırılabilir. Değişiklikler koda backport edilmelidir.

Her Şeyi Tek Bir State İçinde Tutmak

Blast radius büyür. Apply süresi uzar. Lock contention artar. Team ownership çakışır. Component bazlı state ayrımı yapılabilir.

Aşırı Büyük Module Oluşturmak

Yüzlerce input ve condition oluşur. Test zorlaşır. Consumer ne yaptığını anlamaz. Breaking change çok sistemi etkiler. Daha küçük domain module tercih edilir.

Secret'ları Kod İçinde Tutmak

Git history secret'ı kalıcı saklar. Fork ve backup kopyaları riski büyütür. Secret manager kullanılmalıdır. OIDC uzun ömürlü key ihtiyacını azaltır. Scanner pre-commit kontrol sağlayabilir.

Plan İncelemeden Apply Etmek

Unexpected destroy görülmez. Replacement downtime oluşturabilir. CI doğrudan production'a yazar. Plan review zorunlu olmalıdır. Düşük riskli otomasyon bile guardrail kullanmalıdır.

Automated Tests Kullanmamak

Syntax hatası review süresini boşa harcar. Security regression production'a ulaşır. Module behavior bilinmez. Basit validation düşük maliyetlidir. Test kapsamı riskle birlikte artırılmalıdır.

Policy ve Security Kontrollerini Sonradan Eklemek

Hatalı pattern module'lere yayılır. Düzeltme migration gerektirir. Safe default en başta tasarlanmalıdır. Scanner CI ilk sürümden eklenebilir. Governance development hızını engellemeden uygulanabilir.

Brownfield Kaynakları Körlemesine Import Etmek

Import sonrası plan resource replacement gösterebilir. Dependency bilinmeyebilir. Mevcut ownership çakışabilir. Önce inventory gerekir. İlk plan no-change hedeflemelidir.

Drift Monitoring Yapmamak

Console değişiklikleri aylarca fark edilmeyebilir. Security code ile runtime farklılaşır. Incident sırasında neden anlaşılmaz. Scheduled plan basit başlangıçtır. Critical stack sürekli izlenebilir.

AI ve Infrastructure as Code

AI araçları Terraform veya OpenTofu configuration taslağı üretme, refactoring ve plan açıklama konusunda yardımcı olabilir. Buna karşılık üretilen kodun cloud provider tarafından gerçekten desteklenip desteklenmediği mutlaka doğrulanmalıdır. Var olmayan resource veya yanlış IAM policy production riski yaratabilir. AI agent'a doğrudan sınırsız apply yetkisi vermek güvenli bir varsayılan değildir. Human-in-the-loop, policy check ve sandbox validation AI destekli IaC kullanımında temel koruma katmanlarıdır.

AI ile Terraform/OpenTofu Kodu Üretmek

Model başlangıç resource configuration'ı yazabilir. Developer provider dokümantasyonuyla doğrular. Validate ve plan çalıştırılır. Security scan yapılır. Generated code doğrudan production'a uygulanmaz.

AI ile IaC Refactoring

Tekrarlanan blokları module önerisine dönüştürebilir. Variable naming iyileştirilebilir. Refactor planının no-op olması beklenebilir. State address değişiklikleri dikkatle yönetilir. Reviewer behavior farkını kontrol eder.

AI ile Plan Analizi

Uzun plan output insan dilinde özetlenebilir. Destroy ve replacement vurgulanabilir. Model kritik resource'u kaçırabilir. Original plan yine incelenmelidir. AI yardımcı yorum katmanı olmalıdır.

AI ile Policy Önerileri

Security finding'den Rego rule taslağı üretilebilir. Kurum standard'ına göre düzenlenir. Test case yazılır. False positive değerlendirilir. Policy owner review verir.

AI Tarafından Üretilen IaC'ın Güvenlik Riski

Model insecure default önerebilir. Eski provider syntax kullanabilir. IAM wildcard üretebilir. Secret'ı yanlış biçimde configuration'a koyabilir. Static scan ve uzman review zorunlu tutulmalıdır.

Hallüsinasyon ve Var Olmayan Provider Kaynakları

AI gerçek olmayan resource type uydurabilir. Yanlış attribute adı verebilir. Provider validate bunu yakalayabilir. Resmi dokümantasyon source of truth olmalıdır. Model cevabı otorite kabul edilmemelidir.

AI Agent'a Apply Yetkisi Verilmeli mi?

Varsayılan olarak sınırsız production apply yetkisi verilmemelidir. Agent plan üretebilir. Policy ve approval sonrasında kontrollü job çalışabilir. Credential scope düşük tutulur. High-risk action insan onayı gerektirir.

Human-in-the-Loop Infrastructure Deployment

AI change önerir. CI otomatik test eder. İnsan planı inceler. Policy sonucu doğrulanır. Onaylanan artifact apply edilir.

Agentic Infrastructure

Agent monitoring sinyaline göre infrastructure change önerebilir. Cost veya capacity optimizasyonu yapabilir. Reconciliation policy sınırında çalışmalıdır. Tam otonom production write yüksek risk taşır. Audit ve rollback mekanizması zorunludur.

Infrastructure as Code'un Geleceği

Infrastructure as Code yaklaşımı giderek platform engineering ve sürekli reconciliation modelleriyle birleşiyor. Developer doğrudan yüzlerce resource yazmak yerine yüksek seviyeli infrastructure API tüketebilir. Policy deployment yaşam döngüsünün doğal parçası haline geliyor. OpenTofu gibi açık kaynak projeler governance çeşitliliğini artırıyor. AI destekli authoring hız sağlayabilir, fakat güvenli altyapı yönetiminde deterministik plan, policy ve insan sorumluluğu önemini korumaya devam edecektir.

IaC'dan Platform Engineering'e Geçiş

IaC low-level implementation olarak kalabilir. Developer platform üzerinden service talep eder. Module ve policy arka planda çalışır. Platform ekibi developer experience'e odaklanır. Infrastructure product yaklaşımı yaygınlaşır.

Continuous Reconciliation

Scheduled apply yerine controller sürekli state farkını izleyebilir. Drift daha hızlı kapanır. Git desired state olur. Exception mekanizması gerekir. Kubernetes modeli cloud resource'lara taşınabilir.

Policy-Driven Infrastructure

Security ve cost kuralları otomatik uygulanır. User yalnız izin verilen configuration'ı oluşturabilir. Guardrail ticket ihtiyacını azaltır. Policy test ve version yönetimi gerekir. Compliance sürekli hale gelir.

Self-Service Cloud Platforms

Developer portal environment provisioning sunabilir. Template güvenli default içerir. Cloud ayrıntısı kullanıcıdan gizlenir. Time-to-environment azalır. Platform adoption ölçülür.

Infrastructure APIs

Internal API veya custom resource yüksek seviyeli capability sunabilir. “Database oluştur” isteği standard module tetikler. Provider değişikliği kullanıcı interface'ini etkilemeyebilir. Versioned API contract gerekir. Platform team implementation sorumluluğunu taşır.

OpenTofu ve Açık Kaynak Ekosistemi

Açık governance IaC alanında alternatif gelişim yolu sunar. Community provider ve module çalışmaları devam eder. Enterprise kullanıcılar farklı support seçenekleri seçebilir. Compatibility zaman içinde izlenmelidir. Tool diversity vendor bağımlılığı tartışmasını canlı tutacaktır.

AI-Assisted IaC

AI code authoring ve review süresini azaltabilir. Plan açıklama geliştirici deneyimini iyileştirir. Policy suggestion automation artabilir. Validation ve resmi provider schema zorunlu kalır. Human accountability kaybolmamalıdır.

Autonomous Infrastructure Operations

Sistem metric'e göre scaling veya remediation yapabilir. Policy action sınırını belirler. Change audit edilir. Rollback otomatik hazırlanabilir. Kritik production değişikliklerinde insan kontrolü risk seviyesine göre korunmalıdır.

Sıkça Sorulan Sorular

Infrastructure as Code öğrenmeye başlayan ekiplerin soruları çoğunlukla Terraform, state, GitOps ve araç seçimi etrafında toplanır. Tek bir ürün bütün altyapı problemlerini çözmez. Provisioning, configuration management ve reconciliation farklı sorumluluklardır. Doğru araç seçimi cloud strategy, ekip yetkinliği ve governance modeline dayanmalıdır. Aşağıdaki cevaplar Altyapı Kodlaması (Infrastructure as Code - IaC) Temelleri konusunda hızlı bir karar çerçevesi sunar.

Infrastructure as Code nedir?

Infrastructure as Code altyapı kaynaklarının kodla tanımlanması ve yönetilmesidir. Sunucu, network ve cloud servisleri repository içinde temsil edilir. Değişiklikler versionlanabilir. CI/CD üzerinden otomatik uygulanabilir. Amaç tekrar üretilebilir ve denetlenebilir altyapı oluşturmaktır.

IaC nasıl çalışır?

Kod desired state'i tanımlar. Araç actual cloud state'i okur. Fark plan olarak gösterilir. Onaylanan değişiklik provider API üzerinden uygulanır. State veya reconciliation mekanizması sonucu takip eder.

Infrastructure as Code neden kullanılır?

Manuel provisioning hatalarını azaltır. Environment tutarlılığını artırır. Code review ve audit sağlar. Disaster recovery'yi hızlandırabilir. Self-service platformların teknik temelini oluşturabilir.

Terraform nedir?

Terraform HCL tabanlı deklaratif IaC aracıdır. Provider ekosistemi geniştir. Resource ve module modeli kullanır. State ile lifecycle yönetir. Plan ve apply temel workflow'dur.

OpenTofu nedir?

OpenTofu açık kaynak IaC projesidir. Terraform'un önceki açık kaynak kod çizgisinden türemiştir. HCL ve benzer workflow kullanır. Community governance modeli vardır. Compatibility production öncesinde test edilmelidir.

Terraform ile OpenTofu arasındaki fark nedir?

Temel syntax ve çalışma modeli önemli ölçüde benzerdir. Governance ve lisans yaklaşımı ayrışır. Zaman içinde feature farkları oluşabilir. Provider ve module compatibility izlenmelidir. Kurumsal seçim support ve risk modeliyle yapılmalıdır.

Terraform açık kaynak mı?

Güncel Terraform çekirdek ürününün HashiCorp dağıtımı klasik açık kaynak lisansı yerine source-available Business Source License modeli kapsamındadır. Public Terraform provider'larının önemli bölümü açık kaynak lisanslarla dağıtılabilir. Bu iki konu birbirine karıştırılmamalıdır. Kurumsal kullanım amacı lisans değerlendirmesinde önemlidir. Hukuki karar için güncel lisans metni esas alınmalıdır.

Pulumi ile Terraform arasındaki fark nedir?

Terraform HCL kullanır. Pulumi genel amaçlı programlama dillerini destekler. Pulumi type system ve normal test framework'lerinden yararlanabilir. Terraform daha sınırlı deklaratif syntax ile infrastructure intent'i açık tutabilir. Ekip yetkinliği ve abstraction ihtiyacı seçimde önemlidir.

CloudFormation ile Terraform arasındaki fark nedir?

CloudFormation AWS-native deployment servisidir. Terraform multi-provider yaklaşımı sunar. CloudFormation state yönetimini AWS içinde tutar. Terraform ayrı state modeline sahiptir. AWS-only ve multi-cloud ihtiyaçları seçimde belirleyicidir.

Ansible bir IaC aracı mıdır?

Ansible altyapı otomasyonu ve configuration management için kullanılabilir. Cloud resource oluşturma module'leri vardır. Terraform benzeri state graph yaklaşımı kullanmaz. İşletim sistemi configuration tarafında güçlüdür. Birçok ekip Terraform veya OpenTofu ile birlikte kullanır.

Declarative ve imperative IaC arasındaki fark nedir?

Declarative yaklaşım hedef durumun ne olacağını tanımlar. Imperative yaklaşım yapılacak adımları belirtir. Terraform ağırlıklı olarak deklaratiftir. Script ve bazı automation flow'ları imperative olabilir. Hybrid model pratikte yaygındır.

Terraform state nedir?

State Terraform resource ile gerçek altyapı arasındaki mapping bilgisidir. Resource ID ve computed değerler bulunabilir. Production için remote backend tercih edilir. Hassas veri içerebilir. Backup ve locking gerektirir.

Remote state neden kullanılır?

Ekip ortak state'e erişir. Local laptop bağımlılığı azalır. Locking concurrent apply riskini düşürür. Backup ve encryption merkezi uygulanabilir. IAM ile write erişimi sınırlandırılır.

Infrastructure drift nedir?

Cloud gerçeğinin IaC kodundan ayrışmasıdır. Manuel console değişikliği yaygın nedendir. Plan farkı yakalayabilir. Security ve compliance riski oluşturabilir. Drift ya code'a backport edilir ya actual state desired duruma döndürülür.

IaC ile GitOps arasındaki fark nedir?

IaC altyapının kodla tanımlanmasına odaklanır. GitOps Git tabanlı sürekli reconciliation sürecidir. IaC GitOps olmadan kullanılabilir. GitOps da IaC artifact'lerinden yararlanabilir. İki yaklaşım birlikte güçlü platform modeli oluşturur.

Policy as Code nedir?

Güvenlik ve compliance kurallarının kodlanmasıdır. CI planı otomatik kontrol edilir. OPA veya Sentinel kullanılabilir. Violation deployment'ı engelleyebilir. Exception audit süreciyle yönetilir.

IaC için hangi programlama dili kullanılmalıdır?

HCL, YAML veya genel amaçlı diller kullanılabilir. Dil tek başına seçim kriteri değildir. Provider ekosistemi ve state modeli önemlidir. Ekip yetkinliği değerlendirilmelidir. Tool gerçek infrastructure problemine göre seçilmelidir.

Infrastructure as Code öğrenmeye nereden başlanmalı?

Önce cloud, networking ve Git temelleri öğrenilmelidir. Sonra küçük Terraform veya OpenTofu projesi yapılabilir. Remote state eklenir. CI plan workflow'u kurulur. Security scan ve drift detection ileri adım olur.

Küçük projelerde IaC kullanmak gerekli midir?

Tek deneme VM'i için zorunlu değildir. Ancak production'a dönüşecek küçük proje IaC'tan erken fayda görebilir. Tekrar kurulabilirlik değer sağlar. Git history büyümeyi kolaylaştırır. Tool operasyon yükü proje ömrüyle karşılaştırılmalıdır.

AI ile Terraform kodu yazmak güvenli midir?

AI yardımcı araç olarak kullanılabilir. Üretilen configuration validate ve plan edilmelidir. Resmi provider dokümantasyonu doğrulanmalıdır. Security scan ve insan review gerekir. AI'ya doğrudan sınırsız production apply yetkisi verilmemelidir.

Infrastructure as Code Hakkında Ek Sık Sorulan Sorular

Kurumsal ekiplerin IaC konusunda sorduğu sorular çoğunlukla otomasyonun sınırları, araçların görevleri ve güvenli production workflow'u çevresinde birleşir. Terraform Ansible Pulumi ve CloudFormation karşılaştırması yapılırken yalnız syntax değil resource lifecycle yaklaşımı değerlendirilmelidir. IaC repository, CI/CD, state backend ve security policy bir arada tasarlandığında gerçek operasyon faydası ortaya çıkar. Kurumsal Infrastructure as Code ve Terraform kurulum hizmeti değerlendiren kurumların brownfield migration, module standardı ve drift yönetimini de proje kapsamına dahil etmesi önemlidir. Aşağıdaki cevaplar bu kararların uygulamadaki karşılığını daha kısa biçimde özetler.

Altyapı Kodlaması (Infrastructure as Code - IaC) nedir ve nasıl çalışır?

IaC sunucu, network, database ve cloud servislerini kod veya deklaratif configuration üzerinden tanımlama yaklaşımıdır. Kullanıcı desired state'i repository içinde belirtir ve araç gerçek cloud ortamıyla farkı hesaplar. Plan veya preview aşaması resource ekleme, update ve silme işlemlerini apply öncesinde gösterir. Onay sonrasında provider API üzerinden değişiklik uygulanır ve state ya da reconciliation mekanizması sonucu takip eder. Güvenilir kullanım için Git, code review, remote state, automated test ve drift detection aynı workflow'un parçaları olmalıdır.

Terraform, Ansible, Pulumi ve AWS CloudFormation arasındaki farklar nelerdir?

Terraform ağırlıklı olarak HCL tabanlı deklaratif infrastructure provisioning ve state yönetimine odaklanır. Ansible configuration management ve task orchestration alanında güçlüdür, ancak cloud resource da oluşturabilir. Pulumi Python ve TypeScript gibi genel amaçlı dillerle programmatic IaC deneyimi sunar. CloudFormation AWS'ye özgü native stack deployment hizmetidir ve multi-cloud hedeflemez. Hangi aracın seçileceği cloud kapsamı, state ihtiyacı, ekip dili, configuration yönetimi ve vendor bağımlılığı kriterlerine göre belirlenmelidir.

IaC kullanarak sunucu, ağ ve bulut kaynakları nasıl otomatik olarak oluşturulur ve yönetilir?

Önce provider ve authentication yöntemi tanımlanır. Network, subnet, compute ve diğer kaynaklar IaC dosyasında resource olarak yazılır. CI veya local workflow plan üretir ve dependency graph üzerinden uygulanacak değişiklikleri hesaplar. Apply sonrasında cloud API kaynakları oluşturur ve araç state bilgisini günceller. Production kullanımında remote state, locking, IAM sınırları, post-deployment test ve scheduled drift detection eklenerek otomasyon güvenli yaşam döngüsüne dönüştürülmelidir.

Infrastructure as Code süreçlerinde versiyon kontrolü, güvenlik, test ve CI/CD entegrasyonu nasıl uygulanır?

IaC kodu Git repository içinde tutulmalı ve değişiklikler pull request üzerinden ilerlemelidir. CI önce format, validate, lint, security scan ve policy kontrollerini çalıştırabilir. Ardından gerçek infrastructure diff plan olarak reviewer'a gösterilir ve yüksek riskli production değişiklikleri human approval alır. Apply için uzun ömürlü cloud key yerine OIDC üzerinden kısa ömürlü credential kullanmak güvenliği güçlendirir. Deployment sonrasında health kontrolü ve drift monitoring çalıştırıldığında pipeline yalnız resource oluşturan değil sürekli doğrulanan bir altyapı teslim sistemi haline gelir.

Infrastructure as Code (IaC) kurulumu ve eğitimi konusunda yakınımda danışmanlık nerede bulabilirim?

Terraform ve IaC DevOps danışmanlığı yakınımda araması yapan ekiplerin yalnız Terraform dosyası yazdırmak yerine state yönetimi, CI/CD, security, module standardı ve brownfield migration başlıklarını birlikte ele alan yaklaşımı tercih etmesi daha sağlıklıdır. Diyarbakır Yazılım Topluluğu hakkında bilgi almak için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz. Topluluğun teknik proje çalışmalarına https://www.diyarbakiryazilim.com.tr/projects adresinden ulaşabilirsiniz. Eğitim planında yalnız komut ezberlemek yerine remote state, Git workflow, plan review, policy as code, OIDC ve drift senaryolarının uygulamalı laboratuvarla ele alınması kalıcı öğrenme sağlar. Kurumsal kurulum tarafında ise mevcut cloud envanteri çıkarıldıktan sonra düşük riskli bir stack ile pilot başlatmak ve standard'ları gerçek deployment deneyimine göre geliştirmek en güvenli ilerleme yollarından biridir.

Sonuç

Infrastructure as Code, cloud console üzerindeki tıklamaları başka bir syntax'a çevirmekten çok daha kapsamlı bir altyapı yönetim yaklaşımıdır. Gerçek fayda kodun Git ile versionlanması, planların incelenmesi, state'in güvenli tutulması, policy ve testlerin CI/CD içine eklenmesiyle ortaya çıkar. Terraform, OpenTofu, Pulumi, CloudFormation veya başka bir araç seçilebilir, ancak tekrar üretilebilirlik, idempotency, küçük blast radius ve drift yönetimi temel ilkeler olarak kalır. Altyapı Kodlaması (Infrastructure as Code - IaC) Temelleri doğru uygulandığında environment oluşturma süresini azaltırken change güvenilirliğini ve audit kapasitesini artırır. Uzun vadede IaC, platform engineering ve self-service cloud yaklaşımının teknik temel taşlarından biri haline gelir.

Kurumunuzda altyapı değişiklikleri hâlâ kişisel cloud hesaplarından, manuel console işlemlerinden veya dokümante edilmeyen script'lerden ilerliyorsa ilk hedef her şeyi aynı gün dönüştürmek olmamalıdır. Önce kritik kaynak envanterini çıkarın, küçük bir component'i IaC yönetimine alın ve remote state ile plan review sürecini güvenli hale getirin. Ardından CI/CD, security scanning, policy as code ve drift detection katmanlarını ekleyerek olgunluğu aşamalı artırın. Diyarbakır Yazılım Topluluğu'nun yazılım, DevOps ve teknoloji odaklı çalışmalarını takip etmek için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz. Sağlam IaC kültürünün başarısı kaç satır Terraform yazıldığıyla değil, altyapının ne kadar tekrar üretilebilir, gözden geçirilebilir, güvenli ve ekip tarafından yönetilebilir hale geldiğiyle ölçülmelidir.