Infrastructure as Code Nedir? Terraform ile Altyapıyı Kodla Yönetmek

Infrastructure as Code nedir?

Infrastructure as Code (IaC, kod olarak altyapı), sunucu, ağ ve veritabanı gibi kaynakları panelde elle tıklamak yerine metin dosyalarındaki tanımlarla kurup yönetme yöntemidir. Ekip bu dosyaları sürüm kontrolünde tutar, gözden geçirir ve her çalıştırmada aynı sonucu üretir. Altyapıyı da yazılım gibi kodlarsınız.

Basit bir benzetme yapalım. Bir mutfağı her seferinde aklınızdaki tarife göre kurarsanız sonuç değişir. Yazılı bir tarif ve ölçü listesi varsa, mutfağı başka biri de aynı şekilde kurar. IaC, altyapı için bu yazılı tariftir.

Bu yazı tek bir terimi anlatır: Infrastructure as Code ve onun en bilinen aracı Terraform. Belirli bir ürünü övmeyiz. Kavramı, çalışma mantığını, faydalarını ve risklerini sade bir dille konuşuruz. Komşu terimlere yalnızca tabloda ve kısa bağlamda değiniriz.

Infrastructure as Code nedir ve elle kurulumdan farkı nedir?

Elle kurulumda bir kişi bulut panelini açar, sunucu oluşturur, güvenlik kuralı ekler ve veritabanı ayarlar. Bu adımların çoğu kimsenin aklından ve ekran görüntülerinden başka yerde kayıtlı değildir. İşler küçükken sorun çıkmaz. Ancak ortam büyüdükçe kimin neyi neden değiştirdiği belirsizleşir.

IaC'de ise her kaynak bir dosyada tanımlıdır. Değişiklik yapmak isteyen kişi önce dosyayı düzenler, sonra ekip arkadaşı bu değişikliği okur. Yani altyapı değişikliğini de kod değişikliği gibi önerir, onaylar ve gerekirse geri alırsınız.

• Elle kurulum: Hızlı başlar, ancak kayıt tutmaz ve tekrar edilemez.
• Kodla kurulum: Başta emek ister, ama tekrarlanabilir ve denetlenebilir.
• Karma durum: Yarısı elle, yarısı kodla yönetilen ortam en riskli durumdur.

Karma durum özellikle tehlikelidir. Çünkü kodunuz gerçek ortamdan sapar ve kimse hangisine güveneceğini bilmez.

Infrastructure as Code nasıl çalışır?

Çalışma mantığı üç adımdır. Önce istediğiniz altyapıyı tanım dosyasına yazarsınız. Sonra araç, bu tanımı gerçek ortamla karşılaştırıp neyin değişeceğini gösterir. Son olarak onaylarsanız araç, değişiklikleri sağlayıcının API'si üzerinden uygular. API, yani uygulama programlama arayüzü, yazılımların birbiriyle konuşma yoludur.

Terraform'un resmi belgeleri bu akışı yazma, plan ve apply olarak anlatır. Plan adımı "ne olacak?" sorusunu cevaplar. Apply adımı ise onaylanan değişikliği gerçekleştirir. Araç ayrıca kaynaklar arasındaki bağımlılıkları çözer. Örneğin bir veritabanı, ağ hazır olmadan ayağa kalkmaz.

Bu akışın değeri öngörülebilirliktir. Değişiklik uygulanmadan önce ne yapacağını görürsünüz. Böylece sürprizler azalır.

Bir kavram daha önemlidir: aynı tanımı tekrar çalıştırmak aynı sonucu vermelidir. Buna tutarlılık diyebiliriz. Örneğin üç sunucu istediğinizi yazdınız ve zaten üç sunucu var. Bu durumda araç yeni sunucu kurmaz. Yani dosyayı bir kez daha çalıştırmak güvenlidir, çünkü araç yalnızca farkı uygular.

Bildirimsel ve buyurgan yaklaşım arasındaki fark nedir?

Bildirimsel (declarative) yaklaşımda ulaşmak istediğiniz sonucu tarif edersiniz. Buyurgan (imperative) yaklaşımda ise o sonuca götüren adımları sırayla yazarsınız. Birincisi "üç sunucu olsun" der, ikincisi "bir sunucu oluştur, sonra bir tane daha oluştur" der.

Terraform ve OpenTofu bildirimsel çalışır. Resmi belgeler de adım adım talimat yazmanıza gerek olmadığını vurgular. Araç, mevcut durumla istenen durum arasındaki farkı hesaplar ve yalnızca gerekeni yapar.

Hiçbiri mutlak olarak iyi değildir. Bildirimsel yaklaşım altyapı için doğal bir uyum sağlar, çünkü altyapıda çoğu zaman "ne olmalı" sorusu "işi nasıl yaparım" sorusundan önemlidir.

State (durum) dosyası nedir ve neden bu kadar kritiktir?

State, aracın yönettiği gerçek kaynaklarla sizin tanım dosyalarınız arasındaki eşleşmeyi tutan kayıttır. Terraform belgeleri state'i, uzak sistemdeki nesneler ile yapılandırmadaki kaynak örnekleri arasındaki bağların saklanması olarak tarif eder. Araç neyi yönettiğini bu kayıttan bilir.

State olmasa araç, "bu sunucu zaten var mı, yoksa yeni mi kurmalıyım?" sorusunu cevaplayamaz. Bu yüzden state, ortamınızın gerçek kaynağı gibi çalışır. Kaybolursa araç ortamı tanımaz. Bozulursa yanlış kararlar verebilir.

Ayrıca state yalnızca teknik bir kayıt değildir. State, kaynakların ayrıntılarını ve bazen hassas değerleri de tutar. Bu nedenle state'i sıradan bir dosya gibi görmeyin.

Bir kural daha koyun: state dosyasını elle düzenlemeyin. Aracın kendi komutları bu kaydı güvenli biçimde değiştirmek için vardır. Elle müdahale, kaydı gerçek ortamla tutarsız hâle getirebilir. Dolayısıyla sorun yaşarsanız önce yedeğe ve aracın resmi belgelerine bakın.

• Resmi belgeler, state'i kilitleme desteği olmayan ya da erişim kontrolü zayıf bir yerde saklamaktan kaçınmanızı söyler.
• Ekip çalışması için uzak bir saklama alanı (remote backend) kullanmanızı öneririz.
• Kilitleme (locking), iki kişinin aynı anda state'i değiştirmesini engeller.

Plan ve apply mantığı ne anlama gelir?

Plan, değişikliği uygulamadan önce önizleme almanızdır. Araç, tanım dosyalarınızı ve state'i okur, gerçek ortamı kontrol eder ve neyin eklenip silineceğini listeler. Apply ise bu planı gerçekleştirir. İki adımı ayırmak, hatalı bir değişikliği üretime ulaşmadan yakalamanıza yardım eder.

Örnek senaryo: bir ekip, test ortamındaki bir veritabanının adını değiştirmek istiyor. Plan çıktısı, bu işlemin eski veritabanını silip yenisini oluşturacağını gösteriyor. Ekip bunu fark ediyor ve yaklaşımı değiştiriyor. Plan adımı olmasaydı veri kaybı yaşanabilirdi.

Bu nedenle plan çıktısını okumak bir alışkanlık olmalı. Özellikle silme ve yeniden oluşturma satırlarına dikkat edin. Onay vermeden önce, değişikliği yapan kişiden başka biri de bakmalı.

Planın çıktısı başlangıçta kalabalık görünebilir. Ancak birkaç denemeden sonra okumak kolaylaşır. Önce eklenen, değişen ve silinen kaynakların sayısına bakın. Sonra beklemediğiniz bir satır olup olmadığını kontrol edin. Beklemediğiniz her satır, durup sormanız gereken bir işarettir.

Terraform nedir ve Infrastructure as Code ile ilişkisi nedir?

Terraform, HashiCorp'un geliştirdiği bir IaC aracıdır. Resmi tanıma göre bulut ve şirket içi kaynakları insan tarafından okunabilir yapılandırma dosyalarıyla oluşturmanıza, değiştirmenize ve sürümlemenize izin verir. Yani Terraform bir terim değil, IaC fikrini uygulayan bir araçtır.

Terraform kaynakları sağlayıcılar (providers) üzerinden yönetir. Sağlayıcı, belirli bir platformun API'siyle konuşan eklentidir. Resmi belgelere göre kayıt defterinde pek çok platform için sağlayıcı vardır. Bulut hizmetleri, Kubernetes ve kod barındırma platformları bunlara örnektir.

Araç ayrıca modül kavramını sunar. Modül, tekrar eden bir altyapı parçasını yeniden kullanılabilir pakete çevirir. Böylece her projede aynı ağ düzenini baştan yazmazsınız.

Güncel özellikleri ve sürüm ayrıntılarını Terraform'un resmi giriş belgesinden kontrol edin. Biz burada kavramın değişmeyen çekirdeğine odaklanıyoruz.

OpenTofu nedir ve Terraform'dan farkı var mı?

OpenTofu, Terraform ile aynı fikri izleyen, topluluk yönetiminde geliştirilen bir IaC aracıdır. Resmi sitesi projenin Linux Foundation çatısı altında bir proje olduğunu belirtir. Yazma, plan ve apply akışı ile state mantığı Terraform'dakine çok benzer.

OpenTofu belgeleri, Terraform eklenti SDK'sı ile kendi sağlayıcınızı yazabileceğinizi söyler. Bu da iki araç arasındaki mimari yakınlığı gösterir. Ancak uyumluluğun kapsamı sürümlere göre değişebilir.

İki araç arasındaki lisans ve yönetişim farkları ayrı bir tartışma konusudur. Bu konuda kendi yorumumuzu eklemeyiz. Karar vermeden önce her iki projenin resmi belgelerini ve lisans metinlerini okuyun. Kurumsal bir ortam kuruyorsanız hukuk ekibinize de danışın.

Kavramı öğrenmek için hangisini seçtiğiniz çok önemli değildir. Mantık aynıdır. Araç seçimi, ekibinizin ihtiyacına ve kurumsal kurallara göre değişir.

Diğer IaC araç kategorileri nelerdir?

Terraform ve OpenTofu tek seçenek değildir. IaC araçlarını üç geniş kategoride düşünebilirsiniz. Bu ayrım marka listesi değil, yaklaşım farkıdır.

• Genel amaçlı bildirimsel araçlar: Birden çok bulutu ve hizmeti aynı dille yönetir.
• Bulut sağlayıcısının kendi araçları: Tek bir buluta sıkı bağlıdır, o bulutun yeniliklerini hızla destekler.
• Programlama diliyle yazılan araçlar: Altyapıyı tanıdık bir dilde, döngü ve koşullarla tarif etmenizi sağlar.

Hangisi doğru? Bu, ekibinizin yetkinliğine ve kullandığınız bulutlara bağlıdır. Tek bulutta kalacaksanız sağlayıcının kendi aracı yeterli olabilir. Birden çok platform yönetiyorsanız genel amaçlı araç daha mantıklıdır.

Seçim yaparken şu soruları sorun: ekibimiz hangi dili rahat okuyor, hangi bulutları kullanıyoruz ve topluluk desteği ne kadar güçlü? Ayrıca aracın belgelerinin güncel olup olmadığına bakın. Çünkü iyi belge, öğrenme süresini kısaltır.

Belirli bir ürünü "en iyi" ilan etmiyoruz. Küçük bir deneme ortamında iki aracı da deneyip ekibinizin hangisiyle rahat çalıştığına bakmak en sağlıklı yoldur.

Infrastructure as Code nedir ve hangi faydaları sağlar?

IaC'nin temel faydası tekrarlanabilirliktir. Aynı tanım dosyasıyla test, hazırlık ve üretim ortamını benzer şekilde kurarsınız. "Bende çalışıyordu" sorunu azalır, çünkü ortamlar arasındaki farkı dosyada görürsünüz.

İkinci fayda sürüm kontrolüdür. Tanım dosyaları Git gibi bir sistemde durduğu için her değişikliğin yazarı, tarihi ve gerekçesi kayıtlıdır. Hatalı bir değişiklikte önceki duruma dönmek kolaylaşır. Git hakkında temel bilgi için Git ve GitHub kullanım rehberimize bakabilirsiniz.

Üçüncü fayda felaket kurtarmadır. Bir ortam çöktüğünde elinizde yazılı tarif varsa yeniden kurmak saatler yerine daha öngörülebilir bir süreye iner. Ancak veri yedeği ayrı bir konudur. IaC altyapıyı geri getirir, verinizi değil.

• Tekrarlanabilirlik: Aynı tanım, aynı ortamı üretir.
• Denetlenebilirlik: Kimin neyi ne zaman değiştirdiğini izlersiniz.
• Hız: Yeni ortam kurmak bir işlem hâline gelir.
• İş birliği: Altyapı değişikliği de inceleme sürecinden geçer.

Dördüncü bir fayda da ekibe yeni katılanlar içindir. Altyapıyı anlamak isteyen biri, birine sormak yerine dosyaları okuyabilir. Yani bilgi kişilerin kafasından çıkar ve ortak bir kaynağa taşınır. Bu, küçük ekipler için bile büyük bir rahatlıktır.

Infrastructure as Code nedir ve hangi riskleri taşır?

IaC güçlü bir araçtır, bu yüzden hatası da büyük etki yaratır. Tek bir yanlış satır, bir ortamdaki pek çok kaynağı silebilir. Plan çıktısını okumadan onay vermek bu riskin en yaygın kaynağıdır.

İkinci risk state dosyasıdır. Kaybolan, bozulan ya da yetkisiz kişilerin eline geçen bir state, hem operasyonel hem güvenlik sorunu yaratır. Üçüncü risk gizli bilgilerin kodda unutulmasıdır. Bu riski sonraki bölümde ayrıca ele alıyoruz.

Dördüncü risk kayma (drift) denen durumdur. Biri paneli açıp bir ayarı elle değiştirirse gerçek ortam ile kodunuz birbirinden uzaklaşır. Sonraki çalıştırmada araç bu farkı geri almak isteyebilir. Bu nedenle ekipte "değişiklik yalnızca kodla" kuralı koymak gerekir.

• Plan çıktısını okumadan onay vermeyin.
• State'i güvenli ve kilitli bir yerde saklayın.
• Elle değişikliği yasaklayın ya da bilinçli bir istisna olarak kaydedin.
• Kritik kaynaklarda silme korumasını kullanın.

Gizli anahtarlarınızı ve parolalarınızı IaC'de nasıl korursunuz?

Parola, API anahtarı ve erişim belirteçlerini tanım dosyalarına düz metin olarak yazmayın. Bu dosyalar sürüm kontrolüne girer ve geçmişte kalır. Bir anahtar bir kez depoya girdiyse, sonradan silseniz bile geçmişte durmaya devam edebilir.

Daha güvenli yol, gizli bilgiyi ayrı bir gizli bilgi yönetim sistemine koymak ve kodda yalnızca ona referans vermektir. Ayrıca state dosyasının da gizli değerler içerebileceğini unutmayın. Terraform belgeleri, state'in erişim kontrolü olmayan bir yerde tutulmasının sırların açığa çıkmasına yol açabileceğini söyler.

Yeni parola üretirken parola oluşturucu aracımızı kullanabilirsiniz. Ancak üretilen parolayı tanım dosyasına değil, gizli bilgi yönetim sistemine kaydedin.

1. Depoya girmeden önce dosyaları gizli bilgi taramasından geçirin.
2. Anahtarlara yalnızca gereken en düşük yetkiyi verin.
3. Sızdığından şüphelendiğiniz anahtarı hemen iptal edip yenileyin.
4. State'e erişimi kişi ve rol bazında sınırlayın.

IaC, yapılandırma yönetimi ve konteyner arasındaki fark nedir?

Bu üç terim sık karışır, çünkü üçü de "ortamı otomatik kurmak" gibi görünür. Oysa her biri farklı katmanda çalışır. IaC altyapıyı kurar, yapılandırma yönetimi sunucunun içini ayarlar, konteyner ise uygulamayı paketler.

Üçü birbirinin rakibi değildir. Birçok ekip IaC ile sunucuları kurar, konteynerlerle uygulamayı çalıştırır. Yapılandırma yönetimi ise daha çok sunucuların içinde kalıcı ayar gerektiğinde devreye girer.

Docker ve Kubernetes ile IaC'yi nasıl birlikte kullanırsınız?

Konteyner, uygulamayı bağımlılıklarıyla birlikte paketleyen birimdir. Konteynerlerin nasıl çalıştığını Docker rehberimizde anlattık. Burada tekrar etmeyeceğiz. Önemli olan, konteynerin çalışacağı yerin de bir yere kurulması gerektiğidir.

İşte bu noktada IaC devreye girer. Sunucular, ağ ve küme gibi zemini kodla kurarsınız, uygulamayı konteynerle çalıştırırsınız. Konteyner orkestrasyonu (çok sayıda konteyneri yönetme) konusunda Kubernetes ve Docker farkını anlattığımız yazıya göz atabilirsiniz.

Örnek senaryo: bir ekip, küçük bir uygulama için bir küme ve veritabanı kuruyor. IaC dosyaları kümeyi ve ağı tanımlıyor. Uygulamayı ise konteyner olarak kümeye gönderiyor. Böylece hem zemin hem uygulama kayıt altında ve tekrarlanabilir oluyor.

Modül ve değişken IaC dosyalarını nasıl sadeleştirir?

Altyapı büyüdükçe aynı tanımı tekrar tekrar yazmak sorun olur. Modül, tekrar eden bir parçayı tek bir paket hâline getirir. Örneğin bir ağ düzeni için yazdığınız tanımı, farklı projelerde yeniden kullanırsınız. Böylece hem emek hem hata payı azalır.

Değişken ise aynı tanımı farklı değerlerle çalıştırmanızı sağlar. Yani test ortamında küçük bir sunucu, üretimde daha güçlü bir sunucu isteyebilirsiniz. Tanım aynı kalır, yalnızca değer değişir. Bu yaklaşım ortamlar arasındaki farkı tek bir yerde gösterir.

Ancak modülü fazla soyutlamak da tuzaktır. Her şeyi parametreye çevirirseniz okumak zorlaşır. Basit başlayın ve tekrar ortaya çıktığında modüle geçin.

Test, hazırlık ve üretim ortamlarını IaC ile nasıl ayırırsınız?

Birçok ekip en az üç ortamla çalışır: test, hazırlık ve üretim. IaC bu ortamların benzer kurulmasını kolaylaştırır. Çünkü her ortam aynı tanımdan türer, yalnızca boyut ve erişim kuralları değişir.

Örnek senaryo: bir ekip yeni bir ağ kuralını önce test ortamında dener. Plan çıktısı beklenen değişikliği gösteriyor. Ardından aynı değişikliği hazırlık ortamına, en son üretime uyguluyor. Ekip hatayı erken yakalıyor ve müşteri sorun yaşamıyor.

Her ortamın state'ini ayrı tutmak iyi bir alışkanlıktır. Böylece test ortamındaki bir hata üretimin kaydını bozmaz. Ayrıca erişim yetkilerini de ortam bazında ayırabilirsiniz.

Bu ayrım yalnızca teknik bir titizlik değildir. Üretim ortamına dokunma yetkisini daha az kişiye verirsiniz. Böylece yanlışlıkla yapılan bir komutun etkisi sınırlı kalır. Ayrıca denetim kayıtları da daha anlaşılır olur, çünkü hangi değişikliğin hangi ortamda yapıldığı net görünür.

IaC güvenliği için hangi kontroller gerekir?

IaC, altyapıya kodla dokunduğu için güvenlik de koda taşınmalıdır. İlk kontrol en az yetki ilkesidir. Aracın kullandığı hesaba yalnızca gereken izinleri verin. Çünkü bu hesap ele geçerse saldırgan tüm altyapıyı değiştirebilir.

İkinci kontrol, değişikliklerin gözden geçirilmesidir. Altyapı değişikliği için de kod incelemesi isteyin. Üçüncü kontrol, kodun otomatik taranmasıdır. Bu tarama, herkese açık kalan bir depolama alanı ya da çok geniş bir ağ kuralı gibi riskleri yakalayabilir.

• Aracın hesabına en düşük yetkiyi verin.
• Altyapı değişikliğini ikinci bir kişiye inceletin.
• Kodu yayına almadan önce otomatik güvenlik taramasından geçirin.
• Erişim kayıtlarını saklayın ve düzenli kontrol edin.

Sunucu tarafında ek koruma için Fail2ban rehberimize bakabilirsiniz. Bu araç IaC'nin yerine geçmez, ama kurulan sunucuyu korumaya yardım eder.

Altyapı değişikliği için onay süreci nasıl işler?

Olgun bir IaC düzeninde kimse değişikliği doğrudan canlıya göndermez. Önce biri tanım dosyasında değişiklik önerir. Ardından otomatik bir adım planı üretir ve çıktıyı gözden geçirenin önüne koyar. Gözden geçiren kişi, plan çıktısına bakarak onay verir.

Bu akış, yazılım geliştirmedeki kod inceleme sürecine benzer. Fark şudur: burada yanlış bir satırın etkisi canlı sistemde hemen görünebilir. Bu nedenle onay adımını atlamayın.

1. Değişikliği bir dalda hazırlayın ve açıklamasını yazın.
2. Plan çıktısını üretip inceleme isteğine ekleyin.
3. Başka bir kişi hem kodu hem plan çıktısını okusun.
4. Onaydan sonra değişikliği uygulayın ve sonucu kaydedin.

Acil durumlarda bile bu akışı tamamen bırakmayın. Kısaltılmış bir sürüm kullanın, ama kaydı koruyun.

Altyapı kodunu nerede tutmalı ve nasıl izlemelisiniz?

Altyapı kodu da bir depoda yaşar. Bazı ekipler uygulama kodu ile altyapı kodunu aynı depoda, bazıları ayrı depolarda tutar. Her iki seçeneğin artıları ve eksileri vardır. Bu tartışmayı monorepo yazımızda ayrıntılı ele aldık.

Altyapıyı kurmak işin yarısıdır. Çalışmaya başladıktan sonra neler olduğunu görmeniz gerekir. Log, metrik ve izleme verisi bu noktada önem kazanır. Bu konuyu observability ve OpenTelemetry yazımızda anlattık.

Kısacası IaC tek başına bir son nokta değildir. Depo düzeni, gözden geçirme süreci ve izleme ile birlikte bir bütün oluşturur.

Infrastructure as Code nedir sorusunun işletme tarafı: ne zaman gerekir?

Her işletmenin IaC'ye hemen ihtiyacı yoktur. Tek bir paylaşımlı hosting hesabında çalışan küçük bir kurumsal site için bu yöntem gereksiz yük olabilir. Ancak birden çok ortamınız, birden çok kişi çalışıyorsa ya da altyapıyı sık değiştiriyorsanız fayda belirginleşir.

Şu işaretler, IaC'ye geçme zamanının geldiğini gösterir:

• Aynı ortamı ikinci kez kurmak gerektiğinde hatırlanan adımlar yetmiyor.
• Test ve üretim ortamı arasında açıklanamayan farklar çıkıyor.
• Altyapıyı yalnızca bir kişi biliyor ve o kişi ayrılırsa bilgi kayboluyor.
• Değişikliklerin kaydını tutmak denetim açısından gerekiyor.

Sunucu türünü seçerken VPS, VDS ve bulut sunucu farkını anlattığımız yazıdan da yararlanabilirsiniz. Altyapı kararı, IaC kararından önce gelir.

Örnek senaryo: bir e-ticaret ekibi kampanya dönemlerinde geçici olarak ek sunucu kuruyor. Her sezon aynı adımları baştan hatırlamaya çalışmak yerine, tanımı dosyada tutuyor. Kampanya bitince ek kaynakları aynı dosyayla kaldırıyor. Böylece hem kurulum hızlanıyor hem de unutulan sunucuların gereksiz maliyeti ortadan kalkıyor.

IaC'ye nasıl başlarsınız?

Büyük bir geçiş planı yapmayın. Küçük, riski düşük bir kaynakla başlayın. Örneğin bir test ortamı ya da yeni projenin ağ düzeni iyi bir ilk adımdır. Mevcut üretim ortamını kodlamak daha sonra gelir.

1. Önce bir aracı seçin ve resmi giriş belgelerini okuyun.
2. Küçük bir kaynağı kodla tanımlayın ve plan çıktısını inceleyin.
3. State için güvenli ve kilitleme destekli bir saklama alanı belirleyin.
4. Tanım dosyalarını sürüm kontrolüne alın ve inceleme kuralı koyun.
5. Elle yapılan değişiklikleri yavaş yavaş koda taşıyın.

Her adımda kaydı tutmak, ekibe güven verir. Ayrıca ilk denemeyi canlı olmayan bir ortamda yapın. Hata yapma payınız orada daha geniştir.

IaC için pratik kontrol listesi nedir?

Aşağıdaki liste, bir IaC düzenini gözden geçirirken bakabileceğiniz temel maddeleri toplar. Hepsi kavram düzeyindedir. Aracınıza göre uygulama ayrıntısı değişir.

• Tüm tanım dosyaları sürüm kontrolünde ve yetkisiz değişikliğe kapalı mı?
• State uzak, kilitli ve erişimi sınırlı bir yerde mi duruyor?
• Gizli bilgileri kodun dışında mı tutuyorsunuz?
• Her değişikliği plan çıktısıyla birlikte inceliyor musunuz?
• Silme ve yeniden oluşturma satırlarını kimin onayladığı belli mi?
• Elle değişiklik (drift) için bir kural ve tespit yöntemi var mı?
• Veri yedeğini IaC'den bağımsız olarak ayrıca alıyor musunuz?
• Ekipte altyapıyı anlayan birden fazla kişi var mı?

Yedekleme için web sitesi yedekleme stratejisi yazımıza bakın. Hosting kaynaklı kavramları hatırlamak isterseniz hosting terimleri sözlüğü işinize yarar.

IaC'de en sık yapılan hatalar nelerdir?

İlk hata, state'i yerel bir dizininde bırakıp tek bir bilgisayara bağımlı kalmaktır. Bilgisayar bozulursa araç ortamı tanımaz. İkinci hata, her şeyi tek dosyaya yığmaktır. Okunabilirlik düşer ve değişiklik riski artar.

Üçüncü hata, plan çıktısını okumadan onay vermektir. Dördüncü hata ise gizli bilgileri koda gömmektir. Beşinci hata, kodu yazan kişinin ayrılmasıyla bilginin kaybolmasıdır. Bu yüzden dosyalara kısa açıklamalar ekleyin ve süreci belgeleyin.

Son olarak, aracı öğrenmeden üretim ortamında denemek en pahalı hatadır. Öğrenme sürecini ayrı bir ortamda geçirin. Hata yapmaktan korkmanıza gerek kalmaz.

Küçük bir ekip için IaC gerçekçi mi?

Evet, ancak ölçülü başlamak şartıyla. Küçük ekiplerde IaC'nin en büyük kazancı, bilginin kişilerden dosyalara geçmesidir. Bir kişi izne çıktığında ya da ayrıldığında altyapı bilgisi kaybolmaz.

Küçük bir ekipte rol dağılımı da önemlidir. Örneğin bir kişi altyapıyı kodlarken, bir başkası değişiklikleri inceleyebilir. İki kişilik bir ekip bile bu düzeni kurabilir. Ancak herkesin plan çıktısını okumayı öğrenmesi gerekir.

Buna karşılık öğrenme eğrisi gerçektir. İlk haftalar yavaş geçebilir. Bu nedenle ilk hedefiniz her şeyi kodlamak değil, tekrar eden ve hata riski taşıyan işleri kodlamak olmalı.

Önce sağlayıcı, kaynak, state ve plan kavramlarını oturtun. Bunlar araçtan bağımsız olarak diğer IaC araçlarında da karşınıza çıkar. Ardından modül ve değişken kavramlarına geçin.

Ayrıca ağ, kimlik ve erişim yönetimi gibi bulut temellerini bilmeniz gerekir. Çünkü IaC bu temelleri otomatikleştirir, ama yerlerine geçmez. Temel bilgi eksikse otomasyon hatayı da otomatikleştirir.

Alan adı ve DNS kayıtlarının nasıl çalıştığını görmek için DNS sorgulama aracımızı deneyebilirsiniz. Birçok altyapı sorunu aslında bir DNS kaydına dayanır.

Not: Bu yazı vergi, hukuk ya da lisans danışmanlığı değildir. Araç lisansları ve güncel özellikler için sağlayıcıların resmi belgelerini kontrol edin.

Talha Aslan ve ekibi olarak yazılım projelerinde altyapının sürdürülebilir kurulması gerektiğini görüyoruz. İşinize uygun bir yapı kurmak için özel yazılım geliştirme hizmetimizden bilgi alabilirsiniz.