GitOps Nedir ve Neden (Neredeyse) Yararsızdır? Bölüm 1

Yeni bir havayolu şirketinde. Bir hostes yolcu kabinine giriyor: "Yeni havayolumuzdasınız. Uçağın burnunda bir sinema salonumuz var. Kuyruk kısmında kumar makinelerinin olduğu bir salon. Alt güvertede bir yüzme havuzu. üst güverte - sauna Şimdi beyler, emniyet kemerlerinizi bağlayın ve tüm bu gereksiz şeylerle birlikte havalanmaya çalışacağız.

Merhaba, adım Andrii. Hayatımın büyük bir kısmını bilişim sektöründe geçirdim. Altyapı konfigürasyon yönetimi mühendisliğinin gelişimiyle çok ilgileniyorum. Son 8 yıldır DevOps ile ilgileniyorum.

Yeni popüler trendlerden biri, 2017 yılında Weaveworks CEO'su Alexis Richardson tarafından tanıtılan GitOps konseptidir. Weaveworks, GitOps'unu geliştirmek için 2020'de 36 milyondan fazla yatırım toplayan büyük bir yetişkin şirketidir.

Önceki makalemde Elastic Stack'ten Grafana'ya nasıl geçiş yaptığımıza dair maliyet düşürücü bir başarı öyküsünden söz ediyordum. Şimdi bu kavramı benimserken sizi bekleyebilecek, bariz olmayan zorluklardan bahsetmeye çalışacağım. Kısacası GitOps bir "Gümüş Kurşun" değildir. Muhtemelen birçok karmaşık geçici çözümle yeniden düzenleme yapmak zorunda kalacaksınız. Ben de bu yoldan geçtim ve GitOps hakkındaki diğer makaleleri okurken göremediğiniz en sinir bozucu sorunları size göstermek istiyorum.

İçeriğe Genel Bakış

• GitOps nedir ve neden ona ihtiyacınız var (gerekmiyor)
• Snowflake Sunucuları Sorunu
• GitOps - Tüm Sorunlarınız için Her derde deva (ya da değil)
• Flux'u Helm ile Kullanmanın Mantığı
• Özel Akı Kaynakları
• GitOps için kontrol listesi
• Tek Kaynak Hakikat Kavramının İhlali
• Küçük Sonuç

GitOps nedir ve neden ona ihtiyacınız var (gerekmiyor)

Haydi hemen dalalım!

Vatansız ve Devletli

Günümüzde altyapı inşaatının en umut verici kavramı değişmez altyapıdır. Temel fikri, altyapıyı temelde iki farklı parçaya bölmektir: Durumsuz ve Durumlu.

Altyapının Vatansız kısmı değişmez ve değişmezdir. Durum biriktirmez (veri saklamaz) veya birikmiş duruma bağlı olarak çalışmasını değiştirmez. Durum Bilgisiz bölümünün örnekleri bazı temel yapıları, komut dosyalarını ve derlemeleri içerebilir. Kural olarak bunları bulut/sanallaştırılmış ortamlardaki temel görüntülerden oluşturuyorum. Kırılgan ve geçicidirler: Yeni temel görüntülerden örnekleri yeniden oluşturarak uygulamaların yeni sürümlerini sunuyorum.

Kalıcı veriler Durum bilgisi bölümünde saklanır. Klasik şema ile özel sunucularla veya bazı bulut mekanizmalarıyla (DBaaS, nesne veya blok depolama) gerçekleştirilebilir.

Bu "hayvanat bahçesini" yönetilebilir hale getirmek ve doğru şekilde çalışmak için mühendislik ve DevOps ekipleri arasında işbirliğinin yanı sıra tam otomatik dağıtım hatlarına ihtiyacımız var.

CI kısmı

Ekstrem programlama çevik geliştirme metodolojilerinden biridir. Müşterinin ihtiyaçlarıyla senkronizasyonu korumanıza olanak tanıyan birçok geri bildirim döngüsüyle ayırt edilir.

Teslimat boru hatlarının otomasyonunu CI/CD sistemlerini kullanarak uyguluyoruz. CI (Sürekli Entegrasyon) terimi 1994 yılında Grady Booch tarafından önerildi ve 1997'de Kent Beck ve Ron Jeffries onu ekstrem programlama disiplinine dahil etti. CI'da değişikliklerimizi mümkün olduğunca sık projemizin ana çalışma koluna entegre etmemiz gerekiyor.

Bu, öncelikle görevlerin daha ayrıntılı bir şekilde ayrıştırılmasını gerektirir: küçük değişiklikler daha atomiktir ve takip edilmesi, anlaşılması ve entegre edilmesi daha kolaydır. İkincisi, yeni yazılmış kodları öylece birleştiremeyiz. Şubeleri birleştirmeden önce, daha önce işe yarayan hiçbir şeyin bozulmadığından emin olmalıyız. Bunu yapmak için en azından uygulamanın derlenmesi gerekir. Kodu testlerle ele almak da iyi bir fikirdir.

Ve bu, gelişiminde uzun bir yol kat eden ve bu yolun ortasında bir yerde CI/CD sistemlerine dönüşen CI sistemleri tarafından gerçekleştirilen görevdir.

CD parçası

CD nedir? Martin Fowler 2 CD tanımını birbirinden ayırıyor :

• Sürekli Teslimat. Bu, Sürekli Entegrasyon uygulamaları ve DevOps kültürünün yardımıyla projenizin ana dalını sürekli olarak üretime dağıtılmaya hazır tuttuğunuz zamandır.

  
  

• Sürekli Dağıtım. Ana şubeye giden her şeyin kümenize, üretiminize boşaltıldığı Sürekli Teslimattır.

Daha ileri gidelim.

Snowflake sunucuları sorunu

Ne yazık ki, değişmez altyapının birçok sorunu var. Bunlardan aslan payı Kod Olarak Altyapı (IaC) kavramından miras alınmıştır.

Her şeyden önce, konfigürasyon kaymasıdır. Bu terim Puppet Labs'da (ünlü Puppet SCM'nin yazarları) doğmuştur ve hedef sistemlerdeki tüm değişikliklerin sistem konfigürasyon yönetimi (SCM) yardımıyla yapılmadığını belirtmektedir. Bazıları manuel olarak, onları atlayarak yapılır.

Bu tür çoklu değişiklik sürecinde, SCM'de açıklanan konfigürasyon ile gerçek durum arasındaki fark olan konfigürasyon sapması ortaya çıkar.

Bu da otomasyon korkusu sarmalına yol açıyor.

Ne kadar çok manuel değişiklik yapılırsa, bir SCM betiğinin çalıştırılmasının kaydedilmemiş değişiklikleri bozma olasılığı da o kadar artar. Çalıştırılması ne kadar korkutucu olursa, yeni manuel düzenlemelerin yapılma olasılığı da o kadar artar.

Sonunda, bu kısır olumlu geri bildirim, kar tanesi sunucularının oluşmasına yol açar; bu sunucular o kadar tutarsız hale gelir ki, artık kimse içeride ne olduğunu anlayamaz. Manuel düzenlemelerin ardından düğüm, kar yağışındaki her bir kar tanesi kadar benzersiz hale gelir.

Bu sürüklenme, sunucuları değişmez altyapı içerisinde daha yüksek seviyelerde bırakıyor: artık GCP Project/AWS VPC/Kubernetes-cluster-snowflakes'ten bahsedebiliriz. Bunun nedeni, değişikliklerin uygulanmasının değişmez altyapı üzerinde düzenlenmemesidir. Üstelik kimse bunun nasıl doğru şekilde yapılacağını bilmiyor.

GitOps - tüm sorunlarınız için her derde deva (ya da değil)

Sonra Weaveworks ortaya çıkıyor ve şöyle diyor: "Arkadaşlar, ihtiyacınız olan şey bizde var - GitOps". GitOps'u tanıtmak için "Kubernetes'in zor yolu" kılavuzunu oluşturan Kelsey Hightower gibi ağır sıklet bir adamı getirdiler. Halkla İlişkiler sırasında, "Erkek ol, b...! Komut Dosyası Yazmayı Durdurun ve Gönderime Başlayın" mesajını yoğun bir şekilde yayınlıyor. Ve bir miktar pazarlama saçmalığı bingo diyor.

Bana göre en heyecan verici faydalar şunlardı:

• Dağıtımların geliştirilmiş tutarlılığı ve standardizasyonu
• Geliştirilmiş güvenlik güvencesi
• Hatalardan daha kolay ve daha hızlı kurtarma
• Erişimlerin ve gizli dizilerin daha kolay yönetimi
• Kendi kendini belgeleyen dağıtımlar
• Ekip içinde bilgi dağılımı

GitOps'un ne olduğunu anlamaya çalışan herkes bu ders kitabı slaytıyla karşılaşacaktır.

Daha sonra, biraz artırılmış IaC ilkelerine benzeyen GitOps ilkelerini buluyoruz:

• GitOps bildirimseldir
• GitOps uygulamaları sürümlendirilmiştir ve değiştirilemez
• GitOps uygulamaları otomatik olarak çekilir
• GitOps uygulamaları sürekli olarak mutabakata varılır

Yine de bu, boşlukta küresel bir açıklama olduğundan araştırmamıza devam ediyoruz. GitOps.tech web sitesini ve burada birçok önemli açıklamayı buluyoruz.

Öncelikle GitOps'un Git'te bunu otomatik olarak altyapıya uygulayan CD araçlarına sahip altyapı benzeri bir kod olduğunu öğreniyoruz.

GitOps'ta en az 2 repository'miz olmalıdır:

• Uygulama deposu. Uygulamanın kaynak kodunu ve bu uygulamanın dağıtımını açıklayan bildirimleri açıklar.
• Altyapı deposu. Altyapı bildirimlerini ve dağıtım ortamını açıklar.

Ayrıca GitOps ideolojisinde itme odaklı yaklaşım yerine çekme odaklı yaklaşım tercih edilir. Bu, ağır sıklet çekme canavarları Puppet ve Chef'den hafif, itme tabanlı Ansible ve Terraform'a kadar SCM sistemlerinin evrimine bir şekilde aykırıdır.

Ve eğer GitOps öncelikle bir araç seti hikayesiyse, Flux tabanlı konsepti Weaveworks'ün kendisinden alıp yapısını bozmak mantıklı olacaktır. Fikrin yazarları referans uygulaması yapmış olmalıdır.

Flux artık sürüm 2'ye kadar çıktı ve mimari olarak bir küme içinde çalışan denetleyicilerden oluşuyor:

• Kaynak denetleyicisi
• Denetleyiciyi özelleştirin
• HELM denetleyici
• Bildirim denetleyicisi
• Görüntü otomasyon kontrolörleri

Şimdi Flux ve Helm ile çalışmayı tartışalım.

Flux'u Helm ile kullanma mantığı

Flux 2'de Helm paket yöneticisini kullanarak bir uygulamayı dağıtma örneğini daha ayrıntılı olarak anlatacağım.

Neden? CNCF Anketi 2021'e göre HELM paket yöneticisi %50'den fazla payla en popüler Paketleme uygulaması oldu.

Ne yazık ki daha güncel veri bulamadım ama o zamandan bu yana pek bir şeyin değiştiğini düşünmüyorum.

Öyleyse Flux 2'nin Helm ile nasıl çalıştığının temel mantığını inceleyelim. 2 havuzumuz var: uygulama ve altyapı.

Uygulama deposundan bir HELM grafiği ve docker görüntüsü oluşturup bunları sırasıyla Helm grafiği deposuna ve docker kayıt defterine ekliyoruz.

Daha sonra, akış denetleyicilerini çalıştıran bir Kubernetes kümesine sahibiz.

Uygulamamızı kullanıma sunmak için özel kaynak (CR) HelmRelease'i tanımlayan bir YAML hazırlıyoruz ve bunu altyapı deposuna ekliyoruz.

Flux'un bunu elde etmesine yardımcı olmak için Kubernetes kümesinde bir CR GitRepository oluşturuyoruz. Kaynak denetleyici onu görür, git'e gider ve indirir.

Bu YAML'yi bir kümeye dağıtmak için bir Özelleştirme kaynağı tanımlıyoruz.

Özelleştirme denetleyicisi bunu görür, Kaynak denetleyicisine gider, YAML'yi alır ve kümeye dağıtır.

Helm denetleyicisi, kümede bir CR HelmRelease'in göründüğünü görür ve açıklanan HELM grafiğini almak için Kaynak denetleyicisine gider.

Kaynak denetleyicinin HELM denetleyicisine istenen grafiği vermesi için CR kümesinde bir HelmRepository oluşturmamız gerekir.

Helm-controller, Source-controller'dan bir grafik alır, bir sürüm oluşturur ve bunu kümeye dağıtır. Daha sonra Kubernetes gerekli bölmeleri oluşturur, liman işçisi kayıt defterine gider ve ilgili görüntüleri indirir.

Buna göre, uygulamamızın yeni bir sürümünü kullanıma sunmak için yeni bir görüntü, yeni bir HelmRelease dosyası ve muhtemelen yeni bir HELM grafiği oluşturmamız gerekiyor. Daha sonra bunları uygun depolara koymalı ve Flux kontrolörlerinin yukarıda anlatılan zincirdeki işi tekrarlamasını beklemeliyiz.

Ve işimizi bitirmek için bir yere, neyin yanlış gittiğini bize bildiren bir Bildirim denetleyicisi koyarız.

Özel Akı kaynakları

Şimdi Flux'un birlikte çalıştığı özel kaynakları tartışalım.

Bunlardan ilki Git deposudur. Burada Git deposunun adresini (14. satır) ve baktığı şubeyi (10. satır) belirtebiliriz.

Böylece deponun tamamını değil, yalnızca tek bir şubeyi indiriyoruz. Ancak! Sorumlu mühendisler olduğumuz ve Sıfır Güven konseptine uymaya çalıştığımız için depoya erişimi kilitliyoruz, Kubernetes kümesinde bir anahtarla bir sır oluşturuyoruz ve oraya gidebilmesi için bunu Flux'a veriyoruz (satır 12).

Sırada Özelleştirme var. Burada Flux'un Kustomize denetleyicisi ile Kubernetes'in yazarlarının Kustomize denetleyicisinin 2 farklı şey olduğuna dikkatinizi çekmek istiyorum. Neden bu kadar kafa karıştırıcı bir isimlendirmenin seçildiğini bilmiyorum ama onları karıştırmamak önemli.

Özelleştirme, YAML'yi (herhangi bir) Git deposundan bir kümeye dağıtmanın bir yoludur. Burada onu koyacağımız kaynağı (12. satır - yukarıda açıklanan CR GitRepository'nin adı), YAML'leri aldığımız dizini (8. satır) belirtmemiz gerekir ve bunların depolanacağı hedef ad alanını belirtebiliriz. (satır 13).

Sırada Helm sürümü var.

Burada adı ve grafik versiyonunu belirtebiliriz (satır 10,11). Burada, Helm'in ortamdan ortama sürümü özelleştirebilmesi için değişken değerleri belirtirsiniz (15-19. satırlar). Ortamlarınız önemli ölçüde farklılık gösterebileceğinden bu son derece önemli ve gerekli bir özelliktir. Ayrıca Dümen grafiğini alacak kaynağı da belirtirsiniz (satır 12, 13, 14). Bu durumda Helm deposudur.

Ancak! Hâlâ sorumlu mühendisler olduğumuz için Helm deposuna da yakın erişimimiz var ve Flux'a oraya ulaşması için bir sır veriyoruz (7, 8. satırlar).

GitOps için kontrol listesi

O halde, az önce üzerinden geçtiklerimizi yakalamak için küçük bir kontrol listesi yapalım. GitOps yapmaya başlamak için birdenbire bir dizi komut dosyası yazmamız gerekiyor (Değiştirilemez altyapının tamamen otomatik dağıtım hatlarıyla ilgili olduğunu hatırlıyoruz). Yani her şeyden önce şunları yaratmalıyız:

• Görüntüleri oluşturmak ve Docker kayıt defterine göndermek için komut dosyası
• Altyapı Git deposu
• Altyapı GIT deposuna CI sistemi erişimini hesaba katın
• HelmRelease dosyasını oluşturmak ve göndermek için komut dosyası
• Dümen Deposu
• Helm deposuna CI sistemi erişimi hesabı
• Helm grafiğini oluşturmak ve yayınlamak için komut dosyası`
• Altyapı deposu için Flux hesabı
• Helm grafiği deposu için Flux hesabı

Harika, artık GitOps için bir kontrol listeniz var. Devam et.

Tek Kaynak Hakikat Kavramının İhlali

Helm sürümümüzle genel olarak neler elde edeceğimizi görelim. Bu özel durumda Git'in gerçeğin tek kaynağı olamayacağı oldukça açıktır. Bu Helm sürümünün bağlı olduğu, git dışında en az 2 kaynağımız ve 2 yapıtımız var:

• Dümen haritası (satır 8-14)
• Docker görüntüsü (satır 19)

Ve işleri daha da karmaşık hale getirebilir ve Helm grafiği versiyonlarının aralığını belirleyebiliriz.

Bu durumda Flux, bu aralıkta görünen yeni Helm grafiklerini izleyecek ve ayarlayacaktır. Ayrıca sahip olduğumuz Kaynak denetleyicisi, S3 paketleri dahil olmak üzere YAML'yi kaynak olarak kullanabilir.

Oradan hem YAML hem de Helm grafiklerini tutabiliriz.

Ayrıca Docker kayıt defterindeki yeni görselleri takip edebilen ve altyapı deposunu düzenleyebilen Image otomasyon denetleyicilerimiz de var.

Ancak HELM Chart repo-Ops'u veya Docker kayıt defteri-Ops'unu istemiyoruz. Mümkün olduğunca GitOps olmak istiyoruz. Bu nedenle, Helm grafiğimizi GIT deposundan dağıtmak için belgelere bakarız ve süreçleri düzeltiriz (saklamak için uygulama deposunu seçeriz).

Bu bizi uygulama deposu için başka bir CR GitRepository oluşturmaya, Flux'un ona erişebilmesi için bir hesap oluşturmaya ve anahtarlarla bir sır oluşturmaya zorlar.

Aynı zamanda Docker imajına karmaşık bağımlılık sorununu da hiçbir şekilde çözmüyoruz.

Küçük Sonuç

Sanırım bugünlük bu kadar yeter. 2. bölümde bu iyiliğin ne gibi sorunları olduğunu anlatacağım. Ben tartışıcağım:

• Çoklu ortam sorunu
• Değerler
• Sırlar sorunu
• CI Ops ve GitOps karşılaştırması
• Güvenlik
• Geri alma prosedürü
• Çoklu küme sorunu
• GitOps'a gerçekten kimin ihtiyacı var?

Umarım bu makale sizin için faydalı olmuştur!