- 01Infrastructure as Code, altyapı kaynaklarını manuel panel işlemleri yerine version control altında tutulan declarative veya imperative yapılandırmalarla yönetme yaklaşımıdır.
- 02Terraform ve OpenTofu IaC araçlarıdır; Infrastructure as Code kavramının kendisi tek bir ürüne bağlı değildir.
- 03State, declarative IaC araçlarında configuration ile gerçek provider kaynakları arasındaki ilişkiyi takip eder; ekip kullanımında remote state, locking ve erişim kontrolü önemlidir.
- 04Infrastructure drift, canlı ortamın repository'deki desired state'ten farklılaşmasıdır ve manuel panel değişiklikleri bunun yaygın nedenlerinden biridir.
- 05Production IaC değişiklikleri için pull request, validation, plan review ve kontrollü apply akışı değişiklik riskini azaltır.
Kısaca
Infrastructure as Code (IaC), sunucu, network, storage, DNS ve benzeri altyapı kaynaklarını manuel panel işlemleri yerine version control altında tutulan yapılandırma dosyalarıyla tanımlama ve yönetme yaklaşımıdır. Amaç altyapıyı tekrar üretilebilir, gözden geçirilebilir ve otomasyona uygun hale getirmektir. Dynamis Teknoloji, IaC'yi yalnız Terraform dosyası yazmak değil; değişikliklerin planlanması, review edilmesi, uygulanması ve drift'in kontrol edilmesi için ortak bir operasyon modeli olarak ele alır.
Infrastructure as Code nedir?
Infrastructure as Code, altyapı kaynaklarını kod veya yapılandırma dosyalarıyla tanımlama yöntemidir.
Örneğin manuel olarak panelden:
- VM oluşturmak
- network açmak
- firewall rule eklemek
- DNS kaydı tanımlamak
- Kubernetes cluster kaynağı hazırlamak
yerine bunlar repository içindeki dosyalarla ifade edilir.
Bu dosyalar daha sonra bir IaC aracı tarafından gerçek altyapıya uygulanır.
IaC ne işe yarar?
IaC'nin temel amacı manuel altyapı değişikliklerini azaltmak ve infrastructure değişikliklerini software delivery sürecine yaklaştırmaktır.
Başlıca faydaları:
- Tekrarlanabilir kurulum
- Version control
- Peer review
- Change history
- Otomasyon
- Environment consistency
- Drift tespiti
- Disaster recovery kolaylığı
- Daha hızlı provisioning
Aynı altyapıyı test, staging ve production için benzer modellerle oluşturmak mümkün hale gelir.
Declarative ve imperative yaklaşım farkı
IaC araçları iki ana yaklaşım kullanabilir.
Declarative
İstenen son durumu tanımlarsınız.
Örneğin:
- 3 VM olsun
- private network bağlı olsun
- load balancer iki backend'e trafik göndersin
Araç mevcut durum ile istenen durumu karşılaştırır ve gerekli değişikliği planlar.
Terraform ve OpenTofu bu modele örnektir.
Imperative
Hangi adımların hangi sırayla yapılacağını tarif edersiniz.
Örneğin:
- VM oluştur
- IP ata
- firewall rule ekle
- DNS kaydı oluştur
Script tabanlı otomasyon çoğu zaman imperative modele daha yakındır.
İki yaklaşım birlikte de kullanılabilir.
Desired state nedir?
Desired state, altyapının olması gereken tanımıdır.
Repository'de:
- VM sayısı
- CPU/RAM
- network
- security group
- DNS
- storage
tanımlanmış olabilir.
Gerçek altyapı bu tanımdan farklılaştığında drift oluşabilir.
IaC aracının görevi mevcut durum ile desired state arasındaki farkı görünür hale getirmektir.
Terraform nedir?
Terraform, HashiCorp tarafından geliştirilen yaygın bir Infrastructure as Code aracıdır.
Terraform configuration dosyalarıyla cloud ve altyapı kaynakları tanımlanabilir.
Tipik workflow:
- Configuration yazılır
- init çalıştırılır
- plan ile değişiklik görülür
- apply ile uygulanır
Terraform provider yapısı sayesinde çok sayıda platform ve servis desteklenir.
Bu sayfada Terraform'u IaC'nin kendisiyle eşitlemiyoruz.
Terraform yalnız araçlardan biridir.
OpenTofu nedir?
OpenTofu, açık kaynaklı Infrastructure as Code aracıdır ve Terraform-compatible workflow'a odaklanır.
HashiCorp Terraform ile benzer declarative model ve HCL syntax kullanır.
Takımlar araç seçerken:
- lisans
- provider desteği
- state workflow
- ecosystem
- mevcut kod tabanı
gibi kriterleri değerlendirmelidir.
State nedir?
Declarative IaC araçlarının önemli parçalarından biri state bilgisidir.
Terraform state:
- configuration içindeki kaynakları
- gerçek provider kaynaklarıyla
eşleştirmeye yardımcı olur.
Örneğin configuration içinde bir VM tanımlıdır.
State dosyası bu tanımın cloud provider'daki hangi gerçek VM'e karşılık geldiğini izleyebilir.
Bu sayede plan aşamasında:
- create
- update
- destroy
işlemleri hesaplanabilir.
State dosyası neden kritik?
State altyapının operasyonel verisini içerir.
Bu nedenle ekip kullanımında:
- merkezi storage
- erişim kontrolü
- locking
- encryption
- backup
gibi kontroller önemlidir.
State'i geliştirici laptop'larında dağınık halde tutmak ekip çalışmasını zorlaştırabilir.
Bazı provider attribute'ları hassas veri içerebildiği için state güvenliği ayrıca değerlendirilmelidir.
Remote state neden kullanılır?
Birden fazla kişinin aynı IaC repository'sinde çalıştığı ortamda local state sorun yaratır.
Remote state:
- ortak state kaynağı
- locking
- merkezi erişim
- automation
sağlamaya yardımcı olabilir.
Örneğin CI/CD pipeline plan çalıştırırken aynı state'e erişebilir.
Infrastructure drift nedir?
Infrastructure drift, gerçek ortamın repository'deki tanımdan farklılaşmasıdır.
Örnek:
Repository'de firewall rule yok.
Bir administrator panel üzerinden manuel olarak rule ekliyor.
Artık canlı ortam ile kod farklı.
Bu drift'tir.
Drift şu nedenlerle oluşabilir:
- manuel panel değişiklikleri
- başka automation
- emergency fix
- provider-side change
- IaC dışında oluşturulan kaynaklar
Drift neden risklidir?
Drift arttığında repository artık production'ın gerçek durumunu temsil etmez.
Sonuç:
- plan beklenmeyen değişiklik gösterir
- disaster recovery zorlaşır
- ekip hangi ayarın doğru olduğunu bilemez
- environment'lar birbirinden uzaklaşır
Bu nedenle production değişikliklerinin mümkün olduğunca IaC workflow üzerinden yapılması tercih edilir.
Plan neden apply'dan önce çalıştırılmalı?
Plan aşaması önerilen değişiklikleri önceden gösterir.
Örnek:
-
- 2 VM create
- ~ load balancer update
-
- eski security group destroy
Review yapan kişi değişikliğin beklenen sonucu üretip üretmediğini görebilir.
Bu yüzden production IaC workflow'unda doğrudan apply yerine:
pull request → validation → plan → review → apply
akışı daha güvenlidir.
IaC ile CI/CD nasıl bağlanır?
IaC repository'si normal application repository'si gibi version control altında tutulabilir.
Örnek pipeline:
Pull request
- format kontrolü
- syntax validation
- security scan
- plan
Review
Engineer plan çıktısını inceler.
Merge
Onaylanan değişiklik main branch'e alınır.
Apply
Production değişikliği manuel approval veya kontrollü automation ile uygulanır.
CI/CD nedir? rehberindeki delivery prensipleri infrastructure değişikliklerine de uygulanabilir.
IaC ile configuration management aynı şey mi?
Tam olarak değil.
IaC daha çok infrastructure resource provisioning'e odaklanır.
Configuration management ise oluşturulmuş makine içindeki:
- package
- service
- config file
- user
- OS setting
yönetimine odaklanabilir.
Örneğin:
Terraform VM'i oluşturabilir.
Ansible VM içine Nginx kurabilir.
Ancak modern image/container yaklaşımında bu sınırlar farklılaşabilir.
Module nedir?
Module, tekrar kullanılabilir IaC bileşenidir.
Örnek module:
- VM
- VPC
- load balancer
- Kubernetes node pool
Aynı yapı farklı environment'larda input değişkenleriyle kullanılabilir.
Module faydaları:
- standardizasyon
- tekrar kullanım
- review edilmiş pattern
- daha az duplication
Ancak aşırı generic module tasarımı karmaşıklığı artırabilir.
Environment'lar nasıl ayrılmalı?
Development, staging ve production'ın aynı state'i paylaşması genellikle tercih edilmez.
Environment'lar için:
- ayrı state
- ayrı variable
- gerektiğinde ayrı account/project
kullanılabilir.
Amaç bir environment değişikliğinin diğerini istemeden etkilememesidir.
Secret'lar IaC kodunda tutulmalı mı?
Hayır.
Password, token veya private key gibi secret'lar source code repository'ye açık şekilde yazılmamalıdır.
Tercih edilen yaklaşım:
- secret manager
- environment variable
- short-lived credential
- CI secret store
kullanmak olabilir.
IaC configuration yalnız secret reference içermelidir.
IaC ile cloud credential nasıl yönetilmeli?
Uzun ömürlü administrator key'leri pipeline içine koymak risklidir.
Mümkün olduğunda:
- least privilege
- role-based access
- short-lived credential
- workload identity / federation
tercih edilmelidir.
Production apply pipeline'ı yalnız gerekli kaynaklara erişmelidir.
IaC neden disaster recovery için değerlidir?
Infrastructure tanımı repository'de bulunuyorsa altyapının yeniden oluşturulması kolaylaşır.
Örneğin region kaybedildiğinde:
- network
- VM
- load balancer
- firewall
kaynakları koddan tekrar oluşturulabilir.
Ancak IaC veri kurtarmayı çözmez.
Database ve storage backup'ı ayrıca gerekir.
Disaster Recovery nedir? rehberi bu ayrımı detaylandırır.
IaC immutable infrastructure ile nasıl ilişkilidir?
Immutable infrastructure yaklaşımında mevcut server üzerinde sürekli manuel değişiklik yapmak yerine yeni image veya yeni resource oluşturulur.
Örneğin:
- Yeni VM image build edilir
- Yeni VM oluşturulur
- Trafik yeni VM'e alınır
- Eski VM kaldırılır
IaC bu modelin provisioning katmanını otomatikleştirebilir.
Bu yaklaşım configuration drift'i azaltabilir.
IaC Kubernetes'te nasıl kullanılır?
Kubernetes cluster infrastructure'ı IaC ile yönetilebilir.
Örneğin:
- network
- cluster
- node pool
- load balancer
- DNS
Terraform/OpenTofu ile oluşturulabilir.
Cluster içi Kubernetes manifest'leri ise:
- kubectl
- Helm
- GitOps
gibi araçlarla yönetilebilir.
Infrastructure IaC ile application deployment katmanını ayrı repository veya workflow'larda tutmak çoğu ekip için daha nettir.
GitOps ile IaC aynı şey mi?
Hayır.
IaC infrastructure definition yaklaşımıdır.
GitOps ise Git repository'yi desired state kaynağı olarak kullanıp otomatik reconciliation yapan operasyon modelidir.
GitOps Kubernetes dünyasında yaygın olsa da IaC daha geniş bir kavramdır.
Policy as Code nedir?
Policy as Code, infrastructure değişikliklerine otomatik kurallar uygulamayı sağlar.
Örnek:
- public IP yasak
- encryption zorunlu
- belirli region dışında resource açılamaz
- production resource tag zorunlu
CI pipeline plan çıktısını policy engine üzerinden kontrol edebilir.
Bu model governance ihtiyacı arttıkça değer kazanır.
IaC güvenliği için temel kontroller
Repository access
Production IaC repository'si kontrollü olmalıdır.
Pull request review
Tek kişinin kontrolsüz production apply yapması azaltılmalıdır.
State security
Remote state encryption ve erişim politikası uygulanmalıdır.
Secret scanning
Repository secret sızıntısına karşı taranmalıdır.
Provider version pinning
Beklenmeyen provider değişiklikleri sınırlandırılmalıdır.
Plan review
Destroy veya geniş kapsamlı değişiklikler production öncesi görünür olmalıdır.
Infrastructure as Code ne zaman gerekli?
IaC şu durumlarda yüksek değer sağlar:
- Birden fazla environment
- Çok sayıda cloud resource
- Sık infrastructure change
- Birden fazla engineer
- Disaster recovery ihtiyacı
- Standardizasyon
- Audit/change history
IaC ne zaman gereksiz karmaşıklık olabilir?
Çok küçük ve nadiren değişen bir ortamda IaC başlangıç maliyeti yaratabilir.
Örnek:
- tek VM
- sabit network
- yılda bir değişiklik
Bu ortamda basit dokümantasyon yeterli olabilir.
Ancak ortam büyüyecekse erken IaC standardı uzun vadede faydalı olabilir.
Küçük ekip için minimum IaC modeli
5-20 kişilik yazılım şirketinde başlangıç:
- Cloud account/project
- Network
- VM veya cluster
- Firewall/security group
- DNS
kaynaklarını version control'e almak olabilir.
İlk günden:
- yüzlerce module
- karmaşık policy engine
- özel platform abstraction
kurmak gerekmez.
IaC projesine nasıl başlanır?
Adım 1: Mevcut altyapı envanteri çıkarın
Hangi resource'lar var?
Adım 2: Manuel değişiklikleri belirleyin
En sık hangi panel işlemleri yapılıyor?
Adım 3: Araç seçin
Terraform, OpenTofu veya provider-native araç değerlendirilebilir.
Adım 4: State stratejisi belirleyin
Local yerine ekip kullanımı için remote state planlayın.
Adım 5: Küçük bir resource grubuyla başlayın
Önce network veya test environment.
Adım 6: PR + plan workflow kurun
Production apply'dan önce review ekleyin.
Adım 7: Drift'i azaltın
Panel değişikliklerini istisna haline getirin.
Adım 8: Module standardı geliştirin
Tekrarlanan pattern'leri zamanla module haline getirin.
Dynamis'te IaC yaklaşımı
Dynamis'in DevOps hizmeti kapsamında Infrastructure as Code çalışmasına doğrudan Terraform repository açarak başlamıyoruz.
Önce:
- mevcut cloud kaynakları
- environment yapısı
- deployment ownership
- credential modeli
- state ihtiyacı
- manuel değişiklikler
- disaster recovery hedefi
incelenir.
Ardından ihtiyaç varsa:
- Terraform veya OpenTofu
- remote state
- module standardı
- CI plan/review
- production approval
- drift kontrolü
kurulur.
Amaç altyapıyı "kod yazılmış" hale getirmek değil, değişiklikleri tekrar üretilebilir ve güvenli hale getirmektir.
Sık yapılan hatalar
IaC = Terraform demek: Terraform araçtır; IaC yöntemdir.
State dosyasını geliştirici laptop'unda tutmak: Ekip çalışması ve güvenlik riski yaratabilir.
Production'da manuel panel değişikliği yapmak: Drift oluşturur.
Plan çıktısını incelemeden apply yapmak: Beklenmeyen destroy riskini artırır.
Secret'ı tfvars veya repository'ye yazmak: Credential sızıntısı yaratabilir.
İlk günden aşırı module abstraction yapmak: Basit altyapıyı gereksiz karmaşıklaştırabilir.
Sırada ne var
- DevOps nedir?: IaC'nin DevOps çalışma modelindeki yerini görün.
- CI/CD nedir?: plan/review/apply workflow'unu pipeline'a bağlayın.
- Observability nedir?: altyapı değişikliğinin production etkisini telemetry ile izleyin.
- DevOps hizmeti: cloud altyapınızı IaC modeline geçirmek için mevcut yapınızı değerlendirin.
Kaynaklar
Kaynaklar
- 1.Terraform documentationHashiCorp · 2026-09-21
- 2.Terraform stateHashiCorp · 2026-09-21
- 3.OpenTofu documentationOpenTofu · 2026-09-21
- 4.Infrastructure as Code best practicesGoogle Cloud · 2026-09-21
Sık sorulan sorular
Infrastructure as Code nedir?
Infrastructure as Code (IaC), sunucu, network, storage, DNS ve benzeri altyapı kaynaklarını manuel panel işlemleri yerine version control altında tutulan yapılandırma dosyalarıyla tanımlama ve yönetme yaklaşımıdır.
IaC için Terraform kullanmak zorunlu mu?
Hayır. Terraform yaygın IaC araçlarından biridir ancak zorunlu değildir. OpenTofu, cloud-provider-native araçlar ve farklı configuration management/provisioning çözümleri de kullanılabilir. Araç seçimi provider, workflow, state ve ekip gereksinimlerine göre yapılmalıdır.
Terraform state dosyası neden önemlidir?
Terraform state, yapılandırmadaki kaynaklar ile gerçek altyapı nesneleri arasındaki ilişkiyi takip eder ve plan sırasında hangi değişikliklerin gerektiğini hesaplamaya yardımcı olur. Ekip kullanımında state erişimi, locking ve hassas veri güvenliği ayrıca yönetilmelidir.
Infrastructure drift nedir?
Infrastructure drift, canlı altyapının IaC repository'sinde tanımlanan beklenen durumdan farklılaşmasıdır. Manuel panel değişiklikleri, dış otomasyon veya provider tarafındaki değişiklikler drift oluşturabilir. Plan ve düzenli reconciliation süreçleri farkı görünür hale getirmeye yardımcı olur.
IaC kodu CI/CD pipeline'a eklenmeli mi?
Çoğu ekip için IaC değişikliklerinin version control, review ve otomatik validation/plan aşamalarından geçmesi faydalıdır. Production apply adımı risk seviyesine göre manuel approval veya kontrollü otomasyon içerebilir.