Infrastructure as Code, sunucu, ağ, veritabanı, depolama ve yük dengeleyici gibi altyapı kaynaklarının elle yapılandırılmak yerine kod dosyalarıyla tanımlanmasını ve yönetilmesini sağlayan bir DevOps yaklaşımıdır. Kısaca IaC olarak adlandırılır ve Türkçede “Kod Olarak Altyapı” anlamına gelir.
Geleneksel yöntemde sistem yöneticileri bulut sağlayıcısının yönetim paneline girerek kaynakları tek tek oluşturabilir. Bu yaklaşım küçük ortamlarda işe yarasa da sistem büyüdükçe yapılandırma hataları, ortam farklılıkları ve takip edilemeyen değişiklikler ortaya çıkabilir.
Infrastructure as Code sayesinde altyapının istenen durumu bir dosyada tanımlanır. IaC aracı bu dosyayı okuyarak gerekli kaynakları oluşturur, günceller veya kaldırır.
Infrastructure as Code Nedir?
Infrastructure as Code, uygulama altyapısının yazılım koduna benzer biçimde tanımlanmasıdır. Altyapı dosyaları sürüm kontrol sisteminde saklanabilir, ekip arkadaşları tarafından incelenebilir, test edilebilir ve otomatik dağıtım süreçlerine bağlanabilir.
Kodla yönetilebilecek altyapı kaynaklarına şu örnekler verilebilir:
- Sanal sunucular
- Sanal ağlar
- Güvenlik grupları
- Yük dengeleyiciler
- Veritabanları
- Depolama alanları
- DNS kayıtları
- Kubernetes kümeleri
- Kullanıcı ve erişim rolleri
- İzleme ve alarm kuralları
HashiCorp’un Terraform açıklamasına göre Terraform; bulut ve şirket içi kaynakların okunabilir yapılandırma dosyalarıyla tanımlanmasını, sürümlenmesini, yeniden kullanılmasını ve paylaşılmasını sağlayan bir Infrastructure as Code aracıdır.
Manuel Altyapı Yönetiminin Sorunları
Bir geliştirme ortamının elle kurulması başlangıçta kolay görünebilir. Ancak test, ön üretim ve üretim ortamlarının da aynı biçimde hazırlanması gerektiğinde süreç karmaşıklaşır.
Karşılaşılabilecek temel sorunlar şunlardır:
- Aynı ortamın tekrar oluşturulamaması
- Yapılandırma adımlarının unutulması
- Geliştirme ve üretim ortamlarının farklılaşması
- Değişiklikleri kimin yaptığının bilinmemesi
- Yanlış kaynağın silinmesi veya değiştirilmesi
- Yeni ortam kurulumunun uzun sürmesi
- Felaket durumunda altyapının yeniden oluşturulamaması
- Güvenlik ayarlarının ortamlara göre değişmesi
Microsoft’un Infrastructure as Code rehberi, manuel yönetilen ortamların zaman içerisinde birbirinden farklı ve tekrar oluşturulması zor yapılara dönüşebileceğini belirtmektedir. Bu durum “configuration drift” yani yapılandırma sapması olarak adlandırılır.
Infrastructure as Code Nasıl Çalışır?
IaC süreci genellikle üç temel aşamadan oluşur.
Yazma
İhtiyaç duyulan altyapı kaynakları yapılandırma dosyalarında tanımlanır. Örneğin iki uygulama sunucusu, bir yük dengeleyici, özel ağ ve veritabanı istenen durum olarak yazılabilir.
Planlama
IaC aracı mevcut altyapıyla kodda tanımlanan altyapıyı karşılaştırır. Hangi kaynakların oluşturulacağını, güncelleneceğini veya silineceğini gösteren bir değişiklik planı üretir.
Uygulama
Plan incelenip onaylandıktan sonra değişiklikler gerçek altyapıya uygulanır. Araç, kaynaklar arasındaki bağımlılıkları dikkate alarak işlemleri uygun sırada gerçekleştirir.
Terraform’un temel iş akışı da Write, Plan ve Apply olmak üzere bu üç aşamadan oluşur.
Bildirimsel ve Buyruksal IaC Arasındaki Fark
Infrastructure as Code araçları bildirimsel veya buyruksal yaklaşımla çalışabilir.
Bildirimsel Yaklaşım
Bildirimsel yöntemde ulaşılmak istenen son durum tanımlanır. Kaynakların hangi adımlarla oluşturulacağını IaC aracı belirler.
Örneğin “Üç adet uygulama sunucusu çalışsın” şeklinde bir hedef tanımlanır. Mevcut ortamda iki sunucu varsa araç üçüncü sunucuyu ekleyerek istenen duruma ulaşır.
Buyruksal Yaklaşım
Buyruksal yöntemde işlemlerin hangi sırayla gerçekleştirileceği adım adım belirtilir. Önce ağ oluştur, ardından alt ağı ekle ve son olarak sunucuyu başlat gibi talimatlar yazılır.
Bildirimsel yaklaşım tekrar kullanılabilirlik ve istenen durum yönetimi açısından genellikle daha kolaydır. Ancak bazı özel iş akışlarında buyruksal komutlara da ihtiyaç duyulabilir.
DevOps’u Güçlendiren 7 Kritik IaC Avantajı
1. Tekrarlanabilir ve Tutarlı Ortamlar Oluşturur
Infrastructure as Code kullanılarak aynı altyapı tanımı birden fazla ortamda uygulanabilir. Geliştirme, test ve üretim ortamları ortak modüllerden oluşturulduğunda aralarındaki farklılıklar azalır.
Bu yaklaşım “Benim bilgisayarımda çalışıyordu” probleminin altyapı tarafındaki karşılığını önlemeye yardımcı olur.
IaC dosyasında tanımlanan kaynaklar doğru ve güncelse aynı ortam farklı bölgelerde yeniden oluşturulabilir. Ortama özel değerler değişkenlerle yönetilebilir.
2. Altyapı Değişikliklerini Sürümlendirir
IaC dosyaları Git gibi bir sürüm kontrol sisteminde saklanabilir. Böylece altyapının zaman içerisinde nasıl değiştiği görülebilir.
Sürüm kontrolü şu bilgileri sağlar:
- Değişikliği kim yaptı?
- Hangi satırlar değiştirildi?
- Değişiklik ne zaman gerçekleştirildi?
- Değişiklik neden yapıldı?
- Hangi ekip üyesi onay verdi?
- Önceki yapılandırma nasıldı?
Kod inceleme süreci sayesinde altyapı değişiklikleri uygulanmadan önce başka ekip üyeleri tarafından kontrol edilebilir. Bu durum hataların üretim ortamına ulaşma ihtimalini azaltabilir.
3. Altyapı Kurulumunu Hızlandırır
Manuel olarak birkaç saat veya gün sürebilecek ortam kurulumları otomasyonla çok daha kısa sürede tamamlanabilir.
Bir geliştirici geçici test ortamına ihtiyaç duyduğunda destek talebi açarak günlerce beklemek yerine onaylanmış IaC modülünü kullanabilir. Test tamamlandıktan sonra geçici kaynaklar yine kod üzerinden kaldırılabilir.
Bu yöntem özellikle aşağıdaki işlemlerde faydalıdır:
- Yeni proje ortamı oluşturma
- Otomatik test ortamı hazırlama
- Yeni bölgeye dağıtım yapma
- Geçici geliştirme ortamları kurma
- Müşteriye özel izole ortam oluşturma
- Felaket kurtarma ortamını hazırlama
4. Manuel Hataları Azaltır
Elle yapılan işlemlerde yanlış ağın seçilmesi, güvenlik kuralının unutulması veya kaynak adının hatalı yazılması mümkündür. Aynı işlemi farklı kişilerin gerçekleştirmesi de farklı sonuçlar doğurabilir.
Infrastructure as Code, onaylanan yapılandırmanın aynı biçimde uygulanmasını sağlar. Otomatik kontrollerle dosyaların sözdizimi, güvenlik kuralları ve kurum standartları dağıtımdan önce doğrulanabilir.
Ancak IaC bütün hataları otomatik olarak ortadan kaldırmaz. Yanlış yazılan bir altyapı tanımı tutarlı biçimde yanlış kaynaklar oluşturabilir. Bu nedenle kod incelemesi, test ve plan kontrolü önemlidir.
5. Felaket Kurtarmayı Kolaylaştırır
Bir veri merkezi veya bulut bölgesi kullanılamaz hale geldiğinde altyapının başka bir bölgede yeniden oluşturulması gerekebilir. Manuel olarak kurulan sistemlerde bütün ayarların eksiksiz biçimde hatırlanması zor olabilir.
Infrastructure as Code dosyaları altyapının yeniden oluşturulabilir tanımını sağlar. Yedeklenen uygulama ve veriler, kodla yeniden oluşturulan altyapıya taşınabilir.
Etkili bir felaket kurtarma planında şu unsurlar birlikte bulunmalıdır:
- Güncel IaC dosyaları
- Veri yedekleri
- Şifreli sır yönetimi
- DNS geçiş planı
- Kurtarma testleri
- Hedef kurtarma süreleri
- Alternatif bölge veya sağlayıcı
IaC dosyasının bulunması tek başına yeterli değildir. Kurtarma süreci düzenli olarak test edilmelidir.
6. CI/CD Süreçleriyle Entegre Çalışır
Infrastructure as Code değişiklikleri CI/CD işlem hattına bağlanabilir. Yeni bir değişiklik gönderildiğinde otomatik biçimde doğrulama, güvenlik taraması ve plan üretimi yapılabilir.
Örnek bir süreç şu şekilde ilerleyebilir:
- Geliştirici IaC dosyasında değişiklik yapar.
- Değişiklik için bir inceleme isteği açılır.
- Sözdizimi ve güvenlik testleri çalıştırılır.
- IaC değişiklik planı oluşturulur.
- Ekip üyeleri planı inceler.
- Gerekli onaylar verilir.
- Değişiklik kontrollü biçimde uygulanır.
- Sonuçlar ve kayıtlar merkezi sistemde saklanır.
Bu yöntem geliştirme ve operasyon ekiplerinin ortak bir iş akışında çalışmasını destekler. Platform Engineering yaklaşımı kapsamında geliştiricilere güvenli, standart ve tekrar kullanılabilir altyapı modülleri sunulabilir.
7. Maliyet ve Güvenlik Standartlarını Uygular
Yeniden kullanılabilir IaC modülleri kurum standartlarını doğrudan altyapı tanımlarına ekleyebilir. Böylece yeni oluşturulan kaynaklara zorunlu güvenlik ve maliyet ayarları otomatik olarak uygulanabilir.
Standart modüller şunları içerebilir:
- Zorunlu disk şifrelemesi
- Özel ağ kullanımı
- Onaylanmış sunucu tipleri
- Kaynak etiketleri
- Yedekleme politikaları
- Loglama ve izleme ayarları
- Bütçe ve kapasite sınırları
- Güvenli varsayılan erişim kuralları
Örneğin bütün kaynaklara proje sahibi, ortam ve maliyet merkezi etiketi eklenmesi zorunlu hale getirilebilir. Böylece kullanılmayan veya sahipsiz kaynakların bulunması kolaylaşır.
Infrastructure as Code Araçları Nelerdir?
IaC ekosisteminde farklı ihtiyaçlara yönelik birçok araç bulunur.
Terraform
Terraform, farklı bulut sağlayıcıları ve hizmetleri ortak bir iş akışıyla yönetebilen bildirimsel bir IaC aracıdır. Kaynakların mevcut durumunu takip etmek için state dosyası kullanır.
AWS CloudFormation
CloudFormation, AWS kaynaklarını şablonlarla tanımlamak ve yönetmek için kullanılır. AWS ortamıyla yerel entegrasyon sağlar.
Azure Bicep
Bicep, Microsoft Azure kaynaklarını bildirimsel biçimde tanımlamak için geliştirilen bir dildir. Azure Resource Manager üzerinde çalışır.
Pulumi
Pulumi, altyapının TypeScript, Python, Go ve C# gibi genel amaçlı programlama dilleriyle tanımlanmasını sağlar.
Ansible
Ansible ağırlıklı olarak yapılandırma yönetimi ve otomasyon için kullanılır. Sunucu oluşturma işlemlerinde de kullanılabilse de IaC araçlarıyla birlikte kullanılarak işletim sistemi ve uygulama yapılandırmalarını yönetebilir.
Araç seçimi mevcut bulut sağlayıcısı, ekibin deneyimi, çoklu bulut gereksinimi ve güvenlik politikalarına göre yapılmalıdır.
Terraform State Dosyası Neden Önemlidir?
Terraform gibi bazı IaC araçları, kodda tanımlanan kaynaklarla gerçek altyapı arasındaki eşleşmeyi state dosyasında tutar.
Bu dosya yanlış yönetilirse kaynak çakışmaları veya beklenmeyen değişiklikler oluşabilir. Ekip ortamında state dosyası yerel bilgisayarlarda tutulmamalıdır.
Güvenli state yönetimi için:
- Uzaktan ve merkezi depolama kullanılmalıdır.
- Şifreleme etkinleştirilmelidir.
- Erişim izinleri sınırlandırılmalıdır.
- Sürümleme ve kilitleme kullanılmalıdır.
- State dosyası herkese açık depolara gönderilmemelidir.
- Düzenli yedek alınmalıdır.
- Hassas veri içerebileceği kabul edilmelidir.
IaC İçerisinde Parolalar Nasıl Yönetilmelidir?
Parolalar, API anahtarları ve erişim belirteçleri doğrudan IaC dosyasına yazılmamalıdır. Dosya özel bir depoda bulunsa bile sır bilgileri sürüm geçmişinde kalabilir.
Bunun yerine güvenli bir secret manager kullanılmalıdır. CI/CD sistemi gerekli sırları yalnızca çalışma anında almalı ve loglara yazmamalıdır.
Ayrıca:
- Kısa ömürlü kimlik bilgileri tercih edilmelidir.
- Gereksiz yönetici yetkilerinden kaçınılmalıdır.
- Servis hesapları ayrı tutulmalıdır.
- Anahtarlar düzenli olarak yenilenmelidir.
- Depolara sır taraması uygulanmalıdır.
Infrastructure as Code Örneği
Bir e-ticaret şirketinin yeni test ortamına ihtiyaç duyduğunu düşünelim. Manuel yöntemde ağ, sunucular, güvenlik kuralları, veritabanı ve yük dengeleyici tek tek oluşturulabilir.
IaC yaklaşımında ise ekip daha önce onaylanmış modülleri kullanarak ortamın kapasite ve bölge değerlerini belirler. Sistem değişiklik planını üretir. Plan onaylandıktan sonra bütün kaynaklar doğru bağımlılık sırasıyla oluşturulur.
Test tamamlandığında aynı tanım kullanılarak geçici kaynaklar kaldırılabilir. Böylece gereksiz bulut maliyetlerinin devam etmesi önlenebilir.
Infrastructure as Code Kurarken Yapılan Hatalar
Yaygın hatalar şunlardır:
- Altyapı kodunu sürüm kontrolüne almamak
- State dosyasını kişisel bilgisayarda tutmak
- Parolaları doğrudan dosyalara yazmak
- Değişiklik planını incelemeden uygulamak
- Üretim ortamında manuel değişiklik yapmak
- Büyük ve yönetilemez tek bir yapılandırma oluşturmak
- Modülleri sürümlemeden güncellemek
- Test ortamı kurmadan üretime geçmek
- Silme işlemleri için koruma kullanmamak
- IaC koduna güvenlik taraması uygulamamak
- Kaynak sahipliği ve etiketleme standardı belirlememek
IaC kullanmaya başladıktan sonra bulut yönetim panelinden elle değişiklik yapılması sınırlandırılmalıdır. Aksi halde kodla gerçek altyapı arasında yapılandırma sapması oluşabilir.
30 Günde Infrastructure as Code’a Geçiş
İlk hafta mevcut altyapı envanteri çıkarılabilir. Kritik olmayan ve kolay yeniden oluşturulabilecek bir kaynak pilot olarak seçilebilir.
İkinci hafta IaC aracı belirlenerek ağ, sunucu veya depolama gibi temel kaynaklar kodla tanımlanabilir. Dosyalar sürüm kontrol sistemine alınabilir.
Üçüncü hafta otomatik doğrulama, güvenlik taraması ve plan inceleme adımları CI/CD sürecine eklenebilir.
Dördüncü hafta merkezi state yönetimi, modül sürümleme ve onay politikaları hazırlanabilir. Pilot ortam silinerek kod üzerinden yeniden oluşturulmalı ve sonuçlar karşılaştırılmalıdır.
Sıkça Sorulan Sorular
Infrastructure as Code ne anlama gelir?
Infrastructure as Code, sunucu, ağ ve veritabanı gibi altyapı kaynaklarının manuel işlemler yerine kod dosyalarıyla tanımlanması ve yönetilmesidir.
IaC neyin kısaltmasıdır?
IaC, “Infrastructure as Code” ifadesinin kısaltmasıdır. Türkçede Kod Olarak Altyapı anlamına gelir.
Terraform bir programlama dili midir?
Terraform bir IaC aracıdır. Altyapı kaynaklarını tanımlamak için HashiCorp Configuration Language adı verilen bildirimsel yapılandırma dilini kullanır.
Infrastructure as Code yalnızca bulutta mı kullanılır?
Hayır. Bulut kaynaklarının yanında şirket içi altyapılar, sanal makineler, ağ cihazları ve çeşitli SaaS hizmetleri de uygun araçlarla yönetilebilir.
IaC üretim ortamında güvenli midir?
Doğru erişim kontrolleri, kod incelemesi, state güvenliği, secret yönetimi ve değişiklik onayları uygulandığında üretim ortamında güvenli biçimde kullanılabilir.
Sonuç
Infrastructure as Code, altyapı yönetimini manuel ve tekrarlanması zor işlemlerden çıkararak sürümlenebilir, test edilebilir ve otomatik bir sürece dönüştürür.
Tutarlı ortamlar oluşturma, değişiklikleri takip etme, hızlı kurulum, felaket kurtarma ve CI/CD entegrasyonu IaC yaklaşımının en önemli avantajlarıdır.
Başarılı bir geçiş için küçük bir pilotla başlanmalı, kod inceleme kültürü oluşturulmalı ve manuel altyapı değişiklikleri zaman içerisinde azaltılmalıdır.
