Infrastructure as Code nedir?
Everything as Code : Infrastructure as Code
Merhaba arkadaşlar,
Everything as Code ana başlığı altında anlatmayı planladığım bir serinin ilkini sizlere sunuyorum.
Öncelikle ben “Nedir ?” yerine “Neden ?” sorusunun daha önemli olduğunu düşünüyorum. Çünkü bence yazılım sektöründe birşeyin nedenini bilmeden onu bilmemiz ve kullanmamız çokta anlamlı olmuyor.
Neden Infrastructure as Code ?
Günün haberinden bahsedelim uzaklara gidersek daha acı şeyler ortaya çıkabilir. Şirketinizdeki altyapınızı bulut’a taşıdığınızı varsayalım. Bu ortamların herhangi birinde (AWS EC2, Azure VM, GCP Compute Engine) çalışan bir uygulamanız var. ( Şimdilik sadece bir uygulamanızı bulut’a taşıdığınızı varsayalım. ) Diyelim ki uygulamanızda bir problem oluştu ve beklediğiniz gibi çalışmamaya başladı ve bu problemler için rutin işlemler yaparak problemi bulup çözmeye çalışıyorsunuz. Bu uygulamanın çalışması sizin için önemli bir veya birden fazla kişi problemi debug etmeye başladınız ve birisi logları takip ederken problemi görüp Application Server’den kaynaklandığını söylüyor. Sistemi tekrar konfigure eden bir dökümantasyona sahip olabilirsiniz.
Ama bunları sürekli manuel olarak gerçekleştirmek için yapmanız gereken yatırımı ve harcayacağınız zamanı düşünün.
Diyelim ki birde hatayı duyup oradan seslenen birisi var ve dedi ki :
Elimde sistemi yeniden konfigure eden bir scriptim var, bunu çalıştırıp sorunu çözebiliriz.
Evet bu şekilde problemi çözebiliriz ama artık bunu çok daha iyi bir şekilde yapabiliriz, tabii ki Infrastructure as Code sayesinde. Günün haberinden anlatmak istediğim sisteminiz bulutta olsa bile aşmanız gereken ciddi problemleriniz olabilir.
Sadece bir uygulamanızın bulut üzerinde çalıştığını düşünmenizi istemiştim, gerçekten de böyle bir senaryonuz olabilir. Buradaki şema Amazon Web Services içerisinde bulunan bir EC2'yu simgeliyor. Uygulamanızın çalıştığı EC2 için bir sahip olmanız gereken Security Group (Firewall)’unuz, storage için bir EBS Volume’nuz ( default olarak AWS tarafından konfigure edilir), sadece bir Availability Zone( bu da default olarak AWS tarafından konfigure edilir. ) ve instance’a SSH ile bağlanabilmeniz için gereken private keyiniz var. Şimdi bu yapıyı manuel olarak yönetmek kolay olabilir.
Peki diyelim ki sisteminizdeki bütün uygulamaları taşıdınız ve artık aşağıdaki gibi bir şemaya sahipseniz:
İşte bu yapıyı manuel olarak yönetmeniz oldukça zor ve stresli olacaktır. Şemaya baktığımız zaman birden fazla VPC ( Virtual Private Cloud ), birden fazla Availability Zone, Load Balancerlar, private ve public olmak üzere birçok Security Group rules, Internet ve NAT Gateway konfigurasyonları ek olarak S3 Buckets, Internatl DNS Records ve dahası. Eğer böyle bir şemaya sahip bulut mimariniz var ise ve bu mimari birileri ya da birisi tarafından manuel yönetiliyor ise, o adamın/adamların ölmemesi için hergün dua etmek gerekir :)
Bizim görmek isteyeceğimiz şey Cloud Provider üzerindeki şema ile birlikte aşağıdakine benzer bir görüntü olmalıdır.
Burada bu yazının devamı olacak olan diğer yazılarda yapacağımız demonun ana dosyasını görmektesiniz.
Yukarıda görmüş olduğunuz kod bloğu bir Terraform kodudur. Terraform json’dan türetilmiş olan HCL ( HashiCorp Configuration Language ) dilini kullanır. Bu kod ile AWS’nin default VPC opsiyonunu kullanarak bir Public Security Group ( Firewall) , Internet Gateway, Subnet, oluşturup 1 core ve 1 GB belleğe ( t2.micro ), ubuntu 16.04 LTS imajına sahip bir EC2 ( Elastic Compute Cloud ) oluşturup bu instance içerisine Nginx’in apt paketini kuruyoruz.
Çok fazla detaya girmiyorum, bu kısımları yazının devamı olacak olan yerler de değineceğim.
Kısaca kodun yaptığı iş AWS üzerine belirli AWS hizmetlerini kullanarak bir instance ayağa kaldırıp içine Nginx’i kurmak.
Infrastructure as Code nedir?
Yazı boyunca en çok faydalandığım kişi Kief Morris, kitap ise yine Kief Morris’e ait olan Infrastructure as Code kitabıdır. Eğer DevOps ile ilgileniyorsanız bu kitabı mutlaka okumanızı tavsiye ederim.
Kief Morris der ki;
Altyapıyı kod olarak kullanmayı etkinleştirme fikri, yazılımı çalıştırmak için kullanılan sistemlerin ve aygıtların kendileri gibi, bir yazılım gibi ele alınabilmesidir.
Infrastructure as Code ( yazının ilerleyen kısımların da IaC olarak isimlendirilecektir. ) veya programmable infrastructure, sisteme ek olarak konfigurasyonların yönetilmesi ve altyapının sağlanmasının otomatikleştirilmesi için kod yazılması anlamına gelir.
Temel olarak altyapınızı bir yazılım olarak değerlendirmenizdir. Bu hızlı ve kolay aynı zamanda güvenilir bir şekilde değişiklikler yapmanıza yardımcı olur.
IaC tıpkı yazılım geliştirirken kullandığımız gibi kullanıcıların altyapıyı yönetmek için versiyon kontrol sistemleri (VCS), test otomasyon kütüphalerini ve deployment orkestrasyonu gibi yazılım geliştirme araçlarını kullanabilmemizi sağlar. Bu aynı zamanda test odaklı geliştirme(TDD), sürekli entegrasyon (CI) ve sürekli teslimat (CD) gibi geliştirme yöntemlerinden yararlanmanın kapısını açar.
IaC’den önceki problemlerimiz nelerdi?
- Farklı ortamlar için aynı altyapıyı kullanmak
Genellikle uygulamaların koşturulduğu ortamlar test, pre-prod ve prod olarak vb. çeşitli bölümlere ayrılırlar.Bu ortamları çok büyük değişikliklere sahip olmasa bile ayrı ayrı manuel oluşturmak ciddi maliyet ve zaman kaybı demektir.IaC ile oluşturmuş olduğunuz herhangi bir ortamı istediğiniz ortam bazlı ufak değişiklikler ile çok hızlı bir şekilde aynı altyapıya sahip olarak oluşturabilirsiniz.
- Altyapıyı hızlıca oluşturabilmek
Geliştiricilerin en büyük şikayet ettikleri konu sistem yöneticilerinin onlara bir ortam sağlamalarını beklemektir. IaC ile oluşturup test ettiğiniz herhangi bir ortamın yeniden yaratılması dakikalar belki de saniyeler içerisinde hazır hale gelebilir. Bu sayede ortamlara olan yaklaşım bir bebek bezine dönüşür, herhangi bir ortamı kaybetmiş olmanız ise çok büyük maliyetler yerine en az maliyetle yeniden oluşturabileceğiniz bir hale gelmiş olur.
- Versiyonlama
Bazen altyapı da istenmedik durumlar oluşabilir, yaptığımız son değişiklikler firewall içerisinde bir açığa sebep olup sistemi saldırıya açık bir konuma getirebilir ya da sistemin doğru çalışan bir bölümünü bozup tüm sistemi kullanılamaz hale getirebilirsiniz. Bundan olabildiğince hızlı geri dönüşler sağlamak için bir versiyonlama yapısına ihtiyacınız vardır. IaC ile yaptığınız tüm işlemleri ufak ufak versiyonlayarak oluşabilecek herhangi bir problemde hızlıca rollback yapabilirsiniz.
- Immutable Infrastructure
IaC ile oluşturduğunuz altyapınızı testleriniz başarılı bir şekilde yarattıysanız o altyapı her tekrar oluşturduğunuz da aynı şekilde çalışabilir durumda demektir. Bu altyapıyı eski yöntemleri kullanarak kullanıcılar veya sistem yöneticilerinin SSH vb. şekilde bağlanıp herhangi bir değişiklik yapmasına izin verilmez. Eğer bir değişiklik isteniyor ise altyapıyı oluşturan kodlarda değişiklik yapılır ve altyapıyı kullanan tüm ortamlarda aynı değişiklik gerçekleştirilmiş olur. Böylece altyapınız her zaman tutarlı ve tanımladığınız şekilde çalışır.
IaC’in Amaçları
- IT altyapısı bir engel veya kısıt olmaktan ziyade değişimi destekler bir hale gelir.
- Sistemdeki değişiklikler, kullanıcılar veya sistem yöneticileri (IT personelleri) için stresli bir durum olmak yerine rutin bir duruma dönüşür.
- IT personelleri zamanlarını tekrar eden görevlerde değil, yeteneklerini kullanabilecekleri daha değerli şeyler üzerine harcayabilirler.
- Kullanıcılar, sistem yöneticilerinin kendileri için yapmasına gerek kalmadan ihtiyaç duydukları kaynakları tanımlayıp, provision edip ve yönetebilirler.
- Takımlar hata yapmaktan korkmadan yani hatayı tamamen önlemeye uğraşmadan kolayca ve hızlı bir şekilde kurtulabilirler.
- Pahalı ve riskli olan büyük “Big Bang” projeleri oluşturup ardından iyileştirme yapmak yerine sürekli ve küçük iyileştirmeler yapılmasını sağlamak.
- Problemlerin çözümleri toplantılarda ve dökümanlar üzerinde tartışarak vakit kaybetmek yerine implemantasyona başlayıp problemleri görüp ve bunlara çözüm bulunarak, test ederek ve ölçülerek kanıtlanır.
IaC sadece Cloud için değildir
Yazının ilk başlarında vermiş olduğum örneklerde IaC’i bulut üzerinde ki kullanımına yer vermiştim fakat IaC sadece bulut için kullanılan bir metodoloji değildir.
Bununla birlikte IaC, bulut ile iç içe bir şekilde gelmiştir.
Çünkü IaC’siz bir bulut ortamını yönetmek oldukça zor ve maliyetlidir.
Ancak IaC prensip ve pratikleri bulut, sanallaştırılmış sistemler hatta bare metal olarak isimlendirilen fiziksel makineler üzerinde de uygulanabilir.
Çevik Olun!
IaC düzgün bir şekilde uygulamak için üç şeye ihtiyacınız vardır: çevik geliştirme süreçleri ( agile development processes ), DevOps ortamı ve kodu yazabileceğiniz araçlar.
Burada çevik olmak çok önemlidir çünkü IaC ile ilgili her şeyin amacı hız ile ilgilidir.
Morris der ki:
If you use automation tools but still manage your infrastructure with the Iron Age approaches to change management, you’re losing the benefit. IaC is more reliable, particularly if you use Agile engineering practices like test driven development, continuous integration and continuous delivery.
Eğer otomasyon araçlarını kullanıyor fakat hala altyapınızı Demir Çağı anlayışına göre değiştiriyorsanız,( Fotoğraftaki arkadaş gibi yaptığınız değişiklikleri uygulamak için eliniz kolunuz bağlı ise ) bu işin kazancını kaybediyorsunuz. Özellikle de test odaklı geliştirme(TDD), sürekli entegrasyon (CI) ve sürekli teslimat (CD) gibi çevik mühendislik uygulamalarını kullanıyorsanız IaC daha güvenilirdir.
Kaynakçalar
