Not. tercüme: Yakın zamanda yayınlanan bir yayından sonra GitOps'taki çekme ve itme yöntemleri hakkında genel olarak bu modele ilgi gördük, ancak bu konuyla ilgili çok az sayıda Rusça yayın vardı (Habré'de hiç yok). Bu nedenle, neredeyse bir yıl önce de olsa, başka bir makalenin çevirisini dikkatinize sunmaktan mutluluk duyuyoruz! - başkanı "GitOps" terimini icat eden Weaveworks'ten. Metin, yaklaşımın özünü ve mevcut yaklaşımlardan temel farklılıkları açıklıyor.
Bir yıl önce yayınlamıştık . O zamanlar Weaveworks ekibinin tamamen Kubernetes tabanlı bir SaaS'ı nasıl başlattığını ve bulut yerel ortamında dağıtım, yönetim ve izleme için bir dizi kuralcı en iyi uygulamayı nasıl geliştirdiğini paylaşmıştık.
Makalenin popüler olduğu ortaya çıktı. Diğer insanlar GitOps hakkında konuşmaya ve bunun için yeni araçlar yayınlamaya başladı. , , , , ve benzeri. Web sitemizde ortaya çıktı yayınlar ve GitOps kullanım örnekleri. Ancak bazı kişilerin hâlâ soruları var. Modelin geleneksel olandan farkı nedir? ve sürekli teslimat ()? Kubernetes kullanmak gerekli mi?
Çok geçmeden aşağıdakileri sunan yeni bir açıklamaya ihtiyaç olduğunu fark ettik:
- Çok sayıda örnek ve hikaye;
- GitOps'un özel tanımı;
- Geleneksel sürekli teslimatla karşılaştırma.
Bu yazımızda tüm bu konuları ele almaya çalıştık. GitOps'a güncellenmiş bir giriş ve geliştirici ve CI/CD perspektifi sağlar. Model genelleştirilebilse de öncelikle Kubernetes'e odaklanıyoruz.
GitOps'la tanışın
Alice'i hayal et. Sözleşmelerin tüm ayrıntılarını kendileri çözemeyecek kadar meşgul olan kişilere sağlık, otomobil, ev ve seyahat sigortası sunan Aile Sigortası'nı yönetiyor. İşi, Alice bir bankada veri bilimcisi olarak çalışırken bir yan proje olarak başladı. Bir gün verileri daha etkili bir şekilde analiz etmek ve sigorta paketlerini formüle etmek için gelişmiş bilgisayar algoritmalarını kullanabileceğini fark etti. Yatırımcılar projeyi finanse etti ve şirketi şu anda yılda 20 milyon dolardan fazla gelir sağlıyor ve hızla büyüyor. Halen çeşitli pozisyonlarda 180 kişi istihdam edilmektedir. Buna web sitesini ve veritabanını geliştiren, bakımını yapan ve müşteri tabanını analiz eden bir teknoloji ekibi de dahildir. 60 kişilik ekibe şirketin teknik direktörü Bob liderlik ediyor.
Bob'un ekibi üretim sistemlerini bulutta devreye alıyor. Temel uygulamaları GKE üzerinde çalışıyor ve Google Cloud'daki Kubernetes'in avantajlarından yararlanıyor. Ayrıca çalışmalarında çeşitli veri ve analiz araçlarını kullanırlar.
Family Insurance, konteyner kullanmaya başlamadı ancak Docker coşkusuna kapıldı. Şirket kısa sürede GKE'nin yeni özellikleri test etmek için kümeleri dağıtmayı kolaylaştırdığını keşfetti. Konteyner kayıt defterini düzenlemek için CI için Jenkins ve Quay eklendi; Jenkins için GKE'ye yeni konteynerler ve yapılandırmalar aktaran komut dosyaları yazıldı.
Bir süre geçti. Alice ve Bob, seçtikleri yaklaşımın performansından ve bunun iş üzerindeki etkisinden dolayı hayal kırıklığına uğradılar. Konteynerlerin kullanıma sunulması, üretkenliği ekibin umduğu kadar artırmadı. Bazen dağıtımlar kesintiye uğrayabiliyordu ve bundan kod değişikliklerinin sorumlu olup olmadığı belli değildi. Ayrıca yapılandırma değişikliklerini takip etmenin de zor olduğu ortaya çıktı. Çoğu zaman yeni bir küme oluşturmak ve uygulamaları ona taşımak gerekiyordu çünkü bu, sistemin dönüştüğü karmaşayı ortadan kaldırmanın en kolay yoluydu. Alice, uygulama geliştikçe durumun daha da kötüleşeceğinden korkuyordu (ayrıca makine öğrenimine dayalı yeni bir proje hazırlanıyordu). Bob işin çoğunu otomatikleştirmişti ve boru hattının neden hala istikrarsız olduğunu, iyi ölçeklenmediğini ve periyodik olarak manuel müdahale gerektirdiğini anlamadı mı?
Daha sonra GitOps'u öğrendiler. Bu kararın, güvenle ilerlemek için tam olarak ihtiyaç duydukları şey olduğu ortaya çıktı.
Alice ve Bob yıllardır Git, DevOps ve altyapının kod iş akışları olduğunu duyuyor. GitOps'un benzersiz yanı, bu fikirleri Kubernetes bağlamında uygulamaya yönelik hem tanımlayıcı hem de normatif bir dizi en iyi uygulamayı getirmesidir. Bu tema İçinde dahil .
Family Insurance GitOps'u uygulamaya karar verir. Şirketin artık Kubernetes ile uyumlu ve birleştiren otomatik bir operasyon modeli var. hız ile istikrarÇünkü onlar:
- ekibin verimliliğinin kimse çıldırmadan iki katına çıktığını buldu;
- komut dosyalarının sunulması durduruldu. Bunun yerine artık yeni özelliklere odaklanabilir ve mühendislik yöntemlerini geliştirebilirler; örneğin, kanarya kullanıma sunma ve testleri iyileştirme;
- dağıtım sürecini, nadiren bozulacak şekilde iyileştirdik;
- kısmi arızalardan sonra dağıtımları manuel müdahaleye gerek kalmadan geri yükleme fırsatı buldu;
- satın alınmış kullanılmışоTeslimat sistemlerine daha fazla güven. Alice ve Bob, ekibi paralel çalışan mikro hizmet ekiplerine ayırabileceklerini keşfettiler;
- Her grubun çabasıyla projede her gün 30-50 değişiklik yapıp yeni teknikler deneyebilir;
- Birkaç saat içinde çekme isteklerini kullanarak güncellemeleri üretime sunma fırsatına sahip olan yeni geliştiricileri projeye çekmek kolaydır;
- SOC2 çerçevesinde denetimden kolayca geçin (hizmet sağlayıcıların güvenli veri yönetimi gerekliliklerine uyumu için; daha fazlasını okuyun, örneğin, - yaklaşık. çeviri.).
Ne oldu?
GitOps iki şeydir:
- Kubernetes ve bulut yereline yönelik operasyonel model. Konteynerli kümeleri ve uygulamaları dağıtmak, yönetmek ve izlemek için bir dizi en iyi uygulamayı sağlar. Formdaki zarif tanım itibaren :
- Geliştirici merkezli bir uygulama yönetimi ortamı oluşturmanın yolu. Git iş akışını hem operasyonlara hem de geliştirmeye uyguluyoruz. Bunun yalnızca Git push ile ilgili olmadığını, aynı zamanda tüm CI/CD ve UI/UX araçları setinin düzenlenmesiyle ilgili olduğunu lütfen unutmayın.
Git hakkında birkaç söz
Sürüm kontrol sistemlerine ve Git tabanlı iş akışına aşina değilseniz bunları öğrenmenizi kesinlikle öneririz. Şubeler ve çekme istekleriyle çalışmak ilk başta kara büyü gibi görünebilir, ancak faydaları çabaya değer. Burada Bir başlangıç için.
Kubernetes nasıl çalışır?
Hikayemizde Alice ve Bob, Kubernetes ile bir süre çalıştıktan sonra GitOps'a yöneldiler. Aslında GitOps, Kubernetes ile yakından ilişkilidir; Kubernetes'e dayalı altyapı ve uygulamalar için operasyonel bir modeldir.
Kubernetes kullanıcılara ne sağlıyor?
İşte bazı temel özellikler:
- Kubernetes modelinde her şey bildirimsel biçimde tanımlanabilir.
- Kubernetes API sunucusu bu bildirimi girdi olarak alır ve ardından sürekli olarak kümeyi bildirimde açıklanan duruma getirmeye çalışır.
- Bildirimler çok çeşitli iş yüklerini, yani “uygulamaları” tanımlamak ve yönetmek için yeterlidir.
- Sonuç olarak, uygulamada ve kümede aşağıdaki nedenlerden dolayı değişiklikler meydana gelir:
- kapsayıcı görsellerindeki değişiklikler;
- bildirim spesifikasyonundaki değişiklikler;
- ortamdaki hatalar - örneğin konteynerin çökmesi.
Kubernetes'in Mükemmel Yakınsama Yetenekleri
Bir yönetici yapılandırma değişiklikleri yaptığında Kubernetes orkestratörü, durumu aynı olduğu sürece bunları kümeye uygulayacaktır. yeni konfigürasyona yaklaşmayacak. Bu model tüm Kubernetes kaynakları için çalışır ve Özel Kaynak Tanımları (CRD'ler) ile genişletilebilir. Bu nedenle Kubernetes dağıtımları aşağıdaki harika özelliklere sahiptir:
- Otomasyon: Kubernetes güncellemeleri, değişikliklerin hassas bir şekilde ve zamanında uygulanma sürecini otomatikleştirmek için bir mekanizma sağlar.
- yakınsama: Kubernetes başarılı olana kadar güncelleme denemelerine devam edecek.
- iktidarsızlık: Tekrarlanan yakınsama uygulamaları aynı sonuca yol açar.
- Determinizm: Kaynaklar yeterli olduğunda güncellenen kümenin durumu yalnızca istenen duruma bağlıdır.
GitOps nasıl çalışır?
GitOps'un nasıl çalıştığını açıklamak için Kubernetes hakkında yeterince şey öğrendik.
Family Insurance'ın mikro hizmet ekiplerine dönelim. Genellikle ne yapmaları gerekir? Aşağıdaki listeye bakın (eğer herhangi bir öğe garip veya tanıdık gelmiyorsa, lütfen eleştirmeyi bırakın ve bizimle kalın). Bunlar yalnızca Jenkins tabanlı iş akışlarının örnekleridir. Diğer araçlarla çalışırken birçok başka süreç vardır.
Önemli olan, her güncellemenin yapılandırma dosyalarında ve Git depolarında yapılan değişikliklerle bittiğini görmemizdir. Git'te yapılan bu değişiklikler "GitOps operatörünün" kümeyi güncellemesine neden olur:
1.Çalışma süreci: "Jenkins yapısı - ana dal'.
Görev listesi:
- Jenkins etiketli görselleri Quay'e gönderiyor;
- Jenkins, yapılandırma ve Helm grafiklerini ana depolama grubuna aktarır;
- Bulut işlevi, yapılandırmayı ve grafikleri ana depolama grubundan ana Git deposuna kopyalar;
- GitOps operatörü kümeyi günceller.
2. Jenkins derlemesi - yayın veya düzeltme dalı:
- Jenkins, etiketlenmemiş görselleri Quay'e gönderiyor;
- Jenkins, yapılandırma ve Helm grafiklerini hazırlama depolama paketine aktarır;
- Bulut işlevi, yapılandırmayı ve grafikleri hazırlama depolama grubundan hazırlama Git deposuna kopyalar;
- GitOps operatörü kümeyi günceller.
3. Jenkins derlemesi - geliştirmesi veya özellik dalı:
- Jenkins, etiketlenmemiş görselleri Quay'e gönderiyor;
- Jenkins, yapılandırma ve Helm grafiklerini geliştirme depolama grubuna aktarır;
- Bulut işlevi, yapılandırmayı ve grafikleri geliştirme depolama grubundan geliştirme Git deposuna kopyalar;
- GitOps operatörü kümeyi günceller.
4. Yeni bir müşteri ekleme:
- Yönetici veya yönetici (LCM/ops), ağ yük dengeleyicilerini (NLB'ler) başlangıçta dağıtmak ve yapılandırmak için Gradle'ı çağırır;
- LCM/ops, dağıtımı güncellemelere hazırlamak için yeni bir yapılandırma gerçekleştirir;
- GitOps operatörü kümeyi günceller.
GitOps'un kısa açıklaması
- Her ortam için bildirimsel spesifikasyonları kullanarak tüm sistemin istenen durumunu tanımlayın (hikayemizde Bob'un ekibi tüm sistem yapılandırmasını Git'te tanımlar).
- Git deposu, tüm sistemin istenen durumuna ilişkin tek gerçek kaynaktır.
- İstenilen durumdaki tüm değişiklikler Git'teki taahhütler aracılığıyla yapılır.
- İstenilen tüm küme parametreleri kümenin kendisinde de gözlemlenebilir. Bu şekilde çakışıp çakışmadıklarını (yakınsak, yakınsak) belirleyebiliriz. yakınsamak) veya farklı (farklı, sapmak) arzu edilen ve gözlemlenen durumlar.
- İstenilen ve gözlemlenen durumlar farklıysa, o zaman:
- Hedef ve gözlemlenen durumları er ya da geç otomatik olarak senkronize eden bir yakınsama mekanizması vardır. Kümenin içinde Kubernetes bunu yapar.
- Süreç, "değişiklik tamamlandı" uyarısıyla hemen başlar.
- Yapılandırılabilir bir sürenin ardından, durumlar farklıysa bir "fark" uyarısı gönderilebilir.
- Bu şekilde Git'teki tüm taahhütler, kümede doğrulanabilir ve bağımsız güncellemelere neden olur.
- Geri alma, daha önce istenen bir duruma yakınlaşmadır.
- Yakınsama nihaidir. Oluşumu şu şekilde gösterilir:
- Belirli bir süre boyunca fark uyarısı yok.
- "birleşik" uyarısı (ör. web kancası, Git geri yazma olayı).
Diverjans nedir?
Tekrar tekrar edelim: istenen tüm küme özellikleri kümenin kendisinde gözlemlenebilir olmalıdır.
Bazı farklılık örnekleri:
- Git'teki dalların birleştirilmesi nedeniyle yapılandırma dosyasındaki değişiklik.
- GUI istemcisi tarafından yapılan Git işlemi nedeniyle yapılandırma dosyasında yapılan değişiklik.
- Git'teki PR nedeniyle istenen durumda birden fazla değişiklik yapılması ve ardından konteyner görüntüsünün oluşturulması ve yapılandırma değişiklikleri.
- Bir hata nedeniyle kümenin durumunda meydana gelen değişiklik, "kötü davranış" ile sonuçlanan kaynak çatışması veya orijinal durumdan rastgele sapma.
Yakınsama mekanizması nedir?
Birkaç örnek:
- Konteynerler ve kümeler için yakınsama mekanizması Kubernetes tarafından sağlanır.
- Aynı mekanizma Kubernetes tabanlı uygulamaları ve tasarımları (Istio ve Kubeflow gibi) yönetmek için kullanılabilir.
- Kubernetes, görüntü depoları ve Git arasındaki operasyonel etkileşimi yönetmeye yönelik bir mekanizma şunları sağlar: , bir parçası olan .
- Temel makineler için yakınsama mekanizması bildirimsel ve özerk olmalıdır. Kendi deneyimlerimize dayanarak şunu söyleyebiliriz bu tanıma en yakın olanıdır ancak yine de insan kontrolünü gerektirir. Bu anlamda GitOps, Kod Olarak Altyapı geleneğini genişletiyor.
GitOps, kullanım için bir model sağlamak amacıyla Git'i Kubernetes'in mükemmel yakınsama motoruyla birleştirir.
GitOps şunları söylememize olanak sağlar: Yalnızca tanımlanabilen ve gözlemlenebilen sistemler otomatikleştirilebilir ve kontrol edilebilir.
GitOps, bulut yerel yığınının tamamı için tasarlanmıştır (örneğin, Terraform vb.)
GitOps yalnızca Kubernetes değildir. Tüm sistemin bildirimsel olarak yönetilmesini ve yakınsama kullanmasını istiyoruz. Sistemin tamamı derken, Kubernetes ile çalışan ortamların bir koleksiyonunu kastediyoruz - örneğin, "geliştirme kümesi 1", "üretim" vb. Her ortam, makineleri, kümeleri, uygulamaları ve ayrıca veri, izleme sağlayan harici hizmetler için arayüzleri içerir. ve benzeri.
Bu durumda Terraform'un önyükleme sorunu açısından ne kadar önemli olduğuna dikkat edin. Kubernetes'in bir yere konuşlandırılması gerekiyor ve Terraform'u kullanmak, Kubernetes'i ve uygulamaları destekleyen kontrol katmanını oluşturmak için aynı GitOps iş akışlarını uygulayabileceğimiz anlamına geliyor. Bu yararlı bir en iyi uygulamadır.
GitOps kavramlarını Kubernetes'in üzerindeki katmanlara uygulamaya güçlü bir şekilde odaklanılıyor. Şu anda Istio, Helm, Ksonnet, OpenFaaS ve Kubeflow'un yanı sıra örneğin Pulumi için bulut tabanlı uygulamalar geliştirmek için bir katman oluşturan GitOps tipi çözümler var.
Kubernetes CI/CD: GitOps'u diğer yaklaşımlarla karşılaştırmak
Belirtildiği gibi GitOps iki şeydir:
- Yukarıda açıklanan Kubernetes ve bulut yereline yönelik işletim modeli.
- Geliştirici merkezli bir uygulama yönetimi ortamına giden yol.
Çoğu kişi için GitOps, öncelikle Git push'larına dayalı bir iş akışıdır. Biz de onu seviyoruz. Ancak hepsi bu kadar değil: Şimdi CI/CD ardışık düzenlerine bakalım.
GitOps, Kubernetes için sürekli dağıtımı (CD) mümkün kılar
GitOps, ayrı "dağıtım yönetimi sistemlerine" olan ihtiyacı ortadan kaldıran sürekli bir dağıtım mekanizması sunar. Kubernetes sizin için tüm işi yapar.
- Uygulamanın güncellenmesi Git'te güncelleme yapılmasını gerektirir. Bu istenen duruma yönelik işlemsel bir güncellemedir. Daha sonra "Dağıtım", güncellenmiş açıklamaya göre küme içinde Kubernetes tarafından gerçekleştirilir.
- Kubernetes'in çalışma şekli gereği bu güncellemeler yakınsaktır. Bu, tüm güncellemelerin atomik olduğu sürekli dağıtım için bir mekanizma sağlar.
- Not: Git ve Kubernetes'i entegre eden bir GitOps operatörü sunar ve kümenin istenen ve mevcut durumu uzlaştırılarak CD gerçekleştirilmesine olanak tanır.
Kubectl ve komut dosyaları olmadan
Kümenizi güncellemek için Kubectl kullanmaktan kaçınmalı ve özellikle kubectl komutlarını gruplamak için komut dosyaları kullanmaktan kaçınmalısınız. Bunun yerine GitOps işlem hattıyla kullanıcı Kubernetes kümesini Git aracılığıyla güncelleyebilir.
Avantajlar şunları içerir:
- Sağ. Bir grup güncelleme uygulanabilir, birleştirilebilir ve sonunda doğrulanabilir, bu da bizi atom konuşlandırma hedefine yaklaştırabilir. Buna karşılık, komut dosyalarının kullanılması herhangi bir yakınsama garantisi sağlamaz (bununla ilgili daha fazla bilgi aşağıdadır).
- güvenlik. Kelsey Hightower: "Kubernetes kümenize erişimi, hata ayıklama veya bakımından sorumlu olan otomasyon araçları ve yöneticilerle sınırlayın." Ayrıca bakınız güvenlik ve teknik spesifikasyonlara uygunluk hakkında ve ayrıca Dikkatsizce yazılmış bir Jenkins senaryosundan kimlik bilgilerini çalarak.
- Kullanıcı deneyimi. Kubectl, Kubernetes nesne modelinin oldukça karmaşık olan mekaniğini ortaya koyuyor. İdeal olarak, kullanıcıların sistemle daha yüksek bir soyutlama düzeyinde etkileşime girmesi gerekir. Burada yine Kelsey'e değineceğim ve izlemenizi tavsiye edeceğim .
CI ve CD arasındaki fark
GitOps mevcut CI/CD modellerini geliştirir.
Modern bir CI sunucusu bir düzenleme aracıdır. Özellikle, CI boru hatlarını düzenlemek için bir araçtır. Bunlar arasında derleme, test etme, ana hatla birleştirme vb. yer alır. CI sunucuları, karmaşık çok adımlı işlem hatlarının yönetimini otomatikleştirir. Yaygın olarak görülen bir istek, bir dizi Kubernetes güncellemesinin komut dosyasını oluşturmak ve değişiklikleri kümeye göndermek için bunu bir ardışık düzenin parçası olarak çalıştırmaktır. Aslında pek çok uzmanın yaptığı da budur. Ancak bu optimal değildir ve nedeni budur.
Güncellemeleri bagaja göndermek için CI kullanılmalı ve Kubernetes kümesi, CD'yi dahili olarak yönetmek için bu güncellemelere göre kendisini değiştirmelidir. Biz buna diyoruz CI push modelinden farklı olarak. CD bir parçasıdır çalışma zamanı orkestrasyonu.
CI Sunucuları Neden Kubernetes'te Doğrudan Güncellemeler Yoluyla CD Yapmamalı?
Kubernetes'e yönelik doğrudan güncellemeleri bir dizi CI işi olarak düzenlemek için CI sunucusu kullanmayın. Bahsettiğimiz anti-örüntü bu blogunuzda.
Alice ve Bob'a geri dönelim.
Hangi sorunlarla karşılaştılar? Bob'un CI sunucusu değişiklikleri kümeye uygular, ancak işlem sırasında çökerse Bob, kümenin hangi durumda olduğunu (veya olması gerektiğini) ya da nasıl düzeltileceğini bilemeyecektir. Başarı durumunda da aynı durum geçerlidir.
Bob'un ekibinin yeni bir görüntü oluşturduğunu ve ardından görüntüyü dağıtmak için dağıtımlarına yama yaptığını varsayalım (tümü CI hattından).
Görüntü normal şekilde oluşuyor ancak işlem hattı başarısız oluyorsa ekibin şunları bulması gerekir:
- Güncelleme yayınlandı mı?
- Yeni bir yapıya mı başlıyoruz? Bu, aynı değişmez görüntünün iki yapısına sahip olma olasılığıyla birlikte gereksiz yan etkilere yol açacak mı?
- Derlemeyi çalıştırmadan önce bir sonraki güncellemeyi beklemeli miyiz?
- Tam olarak ne ters gitti? Hangi adımların tekrarlanması gerekiyor (ve hangilerinin tekrarlanması güvenlidir)?
Git tabanlı bir iş akışı oluşturmak Bob'un ekibinin bu sorunlarla karşılaşmayacağını garanti etmez. Taahhüt işleminde, etikette veya başka bir parametrede hala hata yapabilirler; ancak bu yaklaşım hala açık bir ya hep ya hiç yaklaşımına çok daha yakındır.
Özetlemek gerekirse, CI sunucularının CD ile ilgilenmemesinin nedeni şu:
- Güncelleme komut dosyaları her zaman belirleyici değildir; Onlarda hata yapmak kolaydır.
- CI sunucuları bildirime dayalı küme modeline yakınlaşmaz.
- İdempotluğu garanti etmek zordur. Kullanıcılar sistemin derin anlamlarını anlamalıdır.
- Kısmi bir başarısızlıktan kurtulmak daha zordur.
Helm hakkında not: Helm'i kullanmak istiyorsanız, onu aşağıdaki gibi bir GitOps operatörüyle birleştirmenizi öneririz: . Bu yakınlaşmanın sağlanmasına yardımcı olacaktır. Miğferin kendisi ne deterministik ne de atomiktir.
Kubernetes için Sürekli Teslimatı uygulamanın en iyi yolu olarak GitOps
Alice ve Bob'un ekibi GitOps'u uyguluyor ve yazılım ürünleriyle çalışmanın, yüksek performansı ve kararlılığı korumanın çok daha kolay hale geldiğini keşfediyor. Bu makaleyi yeni yaklaşımlarının neye benzediğini gösteren bir illüstrasyonla bitirelim. Çoğunlukla uygulamalar ve hizmetlerden bahsettiğimizi ancak GitOps'un tüm platformu yönetmek için kullanılabileceğini unutmayın.
Kubernetes için işletim modeli
Aşağıdaki şemaya bakın. Git'i ve kapsayıcı görüntü deposunu iki düzenlenmiş yaşam döngüsü için paylaşılan kaynaklar olarak sunar:
- Dosyaları Git'e okuyup yazan ve kapsayıcı görüntüleri deposunu güncelleyebilen sürekli bir entegrasyon hattı.
- Dağıtımı yönetim ve gözlemlenebilirlikle birleştiren bir Çalışma Zamanı GitOps işlem hattı. Dosyaları Git'e okur ve yazar ve kapsayıcı görüntülerini indirebilir.
Ana bulgular nelerdir?
- Endişelerin ayrılması: Her iki işlem hattının da yalnızca Git'i veya görüntü deposunu güncelleyerek iletişim kurabileceğini lütfen unutmayın. Başka bir deyişle CI ile çalışma zamanı ortamı arasında bir güvenlik duvarı vardır. Biz buna "değişmezlik güvenlik duvarı" diyoruz (değişmezlik güvenlik duvarı), çünkü tüm depo güncellemeleri yeni sürümler oluşturur. Bu konu hakkında daha fazla bilgi için 72-87 numaralı slaytlara bakın. .
- Herhangi bir CI ve Git sunucusunu kullanabilirsiniz: GitOps her bileşenle çalışır. Favori CI ve Git sunucularınızı, görüntü depolarınızı ve test paketlerinizi kullanmaya devam edebilirsiniz. Piyasadaki hemen hemen tüm Sürekli Teslimat araçları, kendi CI/Git sunucusuna veya görüntü deposuna ihtiyaç duyar. Bu, bulut yerelinin geliştirilmesinde sınırlayıcı bir faktör haline gelebilir. GitOps ile tanıdık araçları kullanabilirsiniz.
- Bir entegrasyon aracı olarak etkinlikler: Git'teki veriler güncellenir güncellenmez Weave Flux (veya Weave Cloud operatörü) çalışma zamanını bildirir. Kubernetes bir değişiklik kümesini kabul ettiğinde Git güncellenir. Bu, aşağıda gösterildiği gibi GitOps için iş akışlarını düzenlemek için basit bir entegrasyon modeli sağlar.
Sonuç
GitOps, herhangi bir modern CI/CD aracının gerektirdiği güçlü güncelleme garantilerini sağlar:
- otomasyon;
- yakınsama;
- idempotens;
- determinizm.
Bu önemlidir çünkü bulut yerel geliştiricilere operasyonel bir model sunar.
- Sistemleri yönetmeye ve izlemeye yönelik geleneksel araçlar, bir runbook içinde çalışan operasyon ekipleriyle ilişkilidir (bir dizi rutin prosedür ve operasyon - yaklaşık çeviri), belirli bir dağıtıma bağlı.
- Bulut tabanlı yönetimde gözlemlenebilirlik araçları, geliştirme ekibinin hızlı bir şekilde yanıt verebilmesi için dağıtımların sonuçlarını ölçmenin en iyi yoludur.
Farklı bulutlara dağılmış birçok kümenin ve kendi ekipleri ve dağıtım planlarıyla birçok hizmetin olduğunu hayal edin. GitOps, tüm bu bolluğu yönetmek için ölçekle değişmeyen bir model sunuyor.
çevirmenden PS
Blogumuzda da okuyun:
- «";
- «";
- «'.
Ankete sadece kayıtlı kullanıcılar katılabilir. Lütfen.
Bu iki çeviri Habré'de yayınlanmadan önce GitOps'u biliyor muydunuz?
-
Evet her şeyi biliyordum
-
Sadece yüzeysel olarak
-
Hayır
35 kullanıcı oy kullandı. 10 kişi çekimser kaldı.
Kaynak: habr.com