GitOps özünde Git’i kullanan, kod tabanlı altyapı ve operasyonel prosedürlerden oluşur.
GitOps’u anlarken hoşuma giden bir yazıyı sizlerle paylaşmak istedim.
GitOps Infrastructure as Code(IaC) yaklaşımının bir evrimidir. Git’i gerçek /mevcut altyapı/sistem durumunun tek kaynağı olarak kullanan; sistem mimarisini oluşturmak, güncellemek ve silmek için en iyi DevOps uygulamasıdır. Daha basit bir tanım ile, Git Pull Request özelliği ile sistem altyapı değişikliklerini kontrollü ve otomatik bir şekilde uygulamayı sağlar.
GitOps, sistemin cloud altyapısını Git reposundaki son duruma göre tekrar oluşturabilmeyi sağlar. Pull request’ler ile git reposunun state’i değiştirilir. Pull request onaylanıp merge edilmesi ile birlikte çalışan altyapının/sistemin son durumu git reposundaki son duruma eşitlenir. Online olarak pull requestin gerçek ortam ile eşitlenmesi GitOps’un temel özelliğini teşkil eder.
GitOps’un Tarihi
Git, pull request ve code review özelliklerini sağlayarak yazılım geliştirmede oldukça kritik bir öneme sahiptir. Pull requestler codebase’e gelen değişikliklerin görünürlüğünü ve takım içerisinde iletişim, tartışma ve değişikiklerin gözden geçirilmesini sağlar.
Pull requestler katılımcı/takım olarak yazılım geliştirmede önemli bir özelliktir. Pull request özelliği takımların ve şirketlerin yazılım geliştirme şekillerini değiştirdi. Yine pull request özelliği GitOps evriminin yazılım geliştirmeye uygulanmasına da yardımcı oldu.
Sistemde değişiklik yapmaya tereddütlü olan tipik sistem adminleri artık agile ve DevOps gibi development uygulamalarına ısınıyorlar. Sistem adminliğinin yarım yamalak bir geçmişi var. Sistem adminleri önceden donanımları manuel olarak yönetirlerdi. Adminler bir dizi imperative script ve configleri bir rutin olarak birçok farklı yerde saklarlardı. Bu scriptler herhangi bir zamanda bozulabilir ve kaybolabilirlerdi. Scriptler düzenli olarak dokümante edilmediği için ve paylaşılmadığı için işbirliği yapmayı zorlaştırıyordu.
DevOps hareketi, sistem yönetiminin bu ilkel ortamından ortaya çıktı. DevOps, yazılım mühendisliğinden en iyi fikirleri aldı ve bunları sistem yönetimine uyguladı; bu noktada, bir araya getirilmiş araçlar, sürüm kontrolüne tabi tutulan kod haline geldi.
IaC(Infrastructure as Code) yaklaşımı DevOps’un en büyük keşiflerinden biridir. Önceden sistem yöneticileri sistemleri configure etmek için imperative scriptleri tercih ederlerdi. Imperative yazılım amaca ulaşmak için bir dizi adımı takip eder;
Imperative yazılımlar hataya meyillidir ve sıranın değişmesinden kaynaklı olarak kolay bozulabilirler. Modern yazılım geliştirme, imperative patternlerden declarative patternlere eğilim gösterdiler.
Declarative yazılım bir dizi komutttan ziyade istenen durumun bildirimini/tarifini takip eder. Aşağıda imperative ve declarative devops statement’lerini görüyoruz.
Imperative yaklaşım;
- Bu makinaya bir işletim sistemi kur
- Bu paketleri kur
- Bu URL’deki kodları indir
- Kodu bu dizine taşı
- Bunları diğer 3 makine için yap
Declarative yaklaşım;
4 makinede bu URL’deki yazılım var ve bu dizinde kurulu.
IaC, declarative sistem yönetim araçlarını, custom imperative çözümlere göre cesaretlendirdi ve destekledi. Bu, statik declarative configurations dosyalarını kullanan Docker Containers, Ansible, Terraform ve Kubernetes gibi araçların doğuşuna yol açtı. İnsan tarafından okunabilirlik ve tutarlı tekrar oluşturulabilir state, bunun faydalı çıktılarındandır. Bu config dosyaları doğal olarak takip ve inceleme için Git’e ekli durumdalar. Bu, GitOps’a yakın fakat tam olarak GitOps olmayan noktaya gelindiğini gösteriyor.
Birçok geleneksel sistem yönetimi problemleri bu noktada çözülmüştür. Config dosyaları artık ekip üyeleri tarafından erişilebilir merkezi bir noktada, dokümante edilmiş durumdadır. Commits ve pull request’ler, yapılandırma değişikliklerini izlemek ve işbirliği, tartışma ve incelemeyi teşvik etmek için kullanıldı. Bu noktada geriye kalan problem; config ile canlı sistem hala tam bağlı durumda değil. Yani canlı sistemde manuel yapılan bir değişiklik config üzerinde olmayabilir. Bir config değişikliği pull request onaylandığında ve repo’ya merge edildiğinde, canlı sistem, statik repo’nun durumuyla eşitlenecek şekilde manuel olarak güncellenir. Yani configleri çalışan ortama uygulamak için bazı komutları manuel olarak çalıştırmak gerekir. Bu, tam olarak, GitOps’un çözdüğü sorundur.
İlk GitOps fikri kurumsal bir Kubernetes yönetim firması olan WeaveWorks tarafından ortaya atıldı ve paylaşıldı. Ve o zamandan beri DevOps topluluklarına hızla yayıldı. GitOps, IaC ve declarative configuration’ın bir eklentisidir. GitOps canlı sistem state’ini static config reposuna eşitleyerek, pull request workflow’una yeni bir özellik katıyor.
GitOps’un Faydaları
GitOps “feature branch software development” workflow’unun birçok avantajını paylaşıyor. İlk büyük faydası, Git gibi ortak araçların kullanılmasından dolayı benimsenmesi kolaydır. Git, defakto standart olan version control sistemidir ve bir çok developer, geliştirme ekibi için ortak kullanılan bir araçtır. Bu, Git’e aşina olan developerları cross functional hale getirerek GitOps’a katılmalarını ve katkı sağlamalarını kolaylaştırır.
Bir verison kotrol sistemi kullanmak takımın, sistemi configure eden tüm değişiklikleri takip edebilmesini sağlar. Eğer birşeyler bozuldu ya da istenmeyen durumlar ortaya çıktı ise, bu bize “source of truth”(doğrunun kaynağı ya da mevcut durumun kaynağı) bilgisini verir. Takımlar GitOps geçmişini inceleyebilir ve istenmeyen durumun ne zaman ortaya çıktığını görebilir. Ek olarak, bu denetim izi kurum politikaları ya da güvenlik denetimleri için bir referans olarak kullanılabilir. GitOps history’si , örneğin şifreleme sertifikaları güncellendiğinde bir kanıt olarak kullanılabilir.
GitOps, bir organizasyonun altyapı ihtiyaçlarına merkezi bir repo altında, şeffalık ve açıklık getirir. Tüm sistemin config’lerinin merkezi bir repoda olması, takımın katkılarını ölçmeye yardımcı olur. Pull request’ler tüm mühendislik takımlarına altyapı değişikliklerini inceleme ve izlemesine izin veren pasif iletişim dönüleri oluşturur.
GitOps bir DevOps takımının üretkenliğini büyük ölçüde arttırabilir. DevOps takımına yeni altyapı configlerini hızlıca deneyimleme fırsatı verir. Eğer yeni değişiklikler istenen şekilde davranmazsa, takım Git history’sinden değişiklikleri bilinen düzgün noktaya geri alabilir. Bu, karmaşık altyapıların olduğu ortamlar için inanılmaz bir güçtür.
GitOps Nasıl Çalışır?
GitOps prosedürleri temel orkestrasyon araçları ile gerçekleştirilir. GitOps’un kendisi bağımsız bir uygulama pattern’idir. Günümüzde birçok GitOps çözümü orkestrasyon aracı olarak öncelikli Kubernetes’i kullanır. Doğrudan Terraform değişikliklerini destekleyen bazı alternatif GitOps araçları markete çıkıyor.
Tam bir GitOps kurulumuna ulaşmak için bir pipeline platformunu gereklidir. Jenkis, CircleCi gibi. Pipeline’lar otomatikleştirerek, git pull request ile orkestrasyon sistemi arasında boşluk için köprü sağlar. Pipeline hook oluşturulduktan ve pull requestler ile tetiklendikten sonra, komutlar orkestrasyon tarafı için çalıştırılır.
Pipeline ile orkestrasyon aracı arasında yer alan hizmet yeni bir pattern ya da araç olarak, GitOps “operatörü” adıyla sunuldu. Bir pull request sonrasında operatör’ü tetikleyecek bir pipeline’ı başlatır. Operatör reponun durumunu inceler, orkestratörün durumunu inceler ve ikisini senkronize eder. Operatör GitOps’un sihirli aracıdır. En bilinen operatörlerden birisi ArgoCD’dir.
GitOps Örnekleri
Performans darboğazı yaşayan ya da yüksek trafik alan bir sistemin takımını hayal edin; takım load balancer’ın istendiği şekilde çalışmadığını fark eder. Altyapı configlerini barındıran GitOps reposuna bakarlar ve load balancer’ı configure eden ve deloy eden config dosyasını bulurlar. Bazı incelemelerden ve tartışmalardan sonra load balancer için bazı config değerlerinin optimal olmadığını ve değerleri tekrar ayarlamaları gerektiğini belirlerler.
Bir takım üyesi load balancer değerlerini optimize eden bir pull request açar. Bu pull request başka bir takım üyesi tarafından gözden geçirilir, onaylanır ve repoya merge edilir. Merge işlemi GitOps operatörünü tetikleyen bir GitOps pipeline başlatır. GitOps operatörü load balancer config’inin değiştiğini görür. Değişikliğin canlı ortam ile eşleşmediğini orkestrasyon aracı üzerinden doğrular.
Operatör orkestrasyon aracına load balancer configini güncellemesi için sinyal gönderir. Orkestrasyon aracı gerisini halleder; yeni config ile load balancer’ı tekrar deploy eder. Takım yeni güncellenmiş sistemi izler ve sağlıklı duruma döndüğünü görür. Bu ideal bir GitOps senaryosudur.
GitOps kullanımını biraz daha genişletelim;
Takım mevcut parametreleri optimize etmek yerine daha agresif bir karar alarak configleri tamamen değiştirip yeni bir load balancer tipi deploy etmeye karar verirler. Mevcut load balancer’ın temel olarak problemli olduğunu düşünüp başka bir alternatif denemek isterler. Buradaki workflow parametreleri optimize etmekle aynıdır. Takım tamamen yeni bir load balancer configi sağlayan ve eskisini silen bir pull request oluşturur. Bu onaylanır ve pipeline aracılığı ile deploy edilir.
Maalesef yeni load balancer’ın cluster’daki bazı servisler ile uyumsuz olduğunu görürler. Yeni load balancer ciddi trafik problemlerine ve kullanıcı işlemlerinin durmasına sebep olur. Neyse ki ekip tam bir GitOps pipeline’ına sahip olduğundan, bu load balancer değişikliklerini hızlıca geri alabilir. Takım eski load balancer’ı tekrar devreye alacak pull request’i history’den geri alma işlemi ile oluşturur. Bu, tekrar pipeline tarafından otomatik olarak deploy edilecektir. Bu hızlıca altyapıyı iyileştirir ve takımın güvenilirlik puanını arttırır.
Özet Olarak
GitOps modern cloud altyapılarını yönetmek için inanılmaz güçlü bir workflow patternidir. Her ne kadar öncelikle Kubernetes cluster yönetimine odaklanmış olsa da, DevOps topluluğu GitOps çözümlerini Kubernetes dışı diğer sistemlere uygluyor ve yayınlıyor. GitOps, mühendislik ekibine gelişmiş iletişim, görünürlük, kararlılık ve sistem güvenilirliği dahil olmak üzere birçok fayda sağlayabilir. GitOps deneyiminin temel gereksinimlerinden biri, Bitbucket gibi modern Git platformudur.