Not. tercüme: Kişisel olarak gördüğümüz gibi, Kubernetes topluluğunda GitOps adlı bir trend bariz bir popülerlik kazanıyor. KubeCon Europe 2019. Bu terim nispeten yeniydi Weaveworks'ün başkanı Alexis Richardson tarafından ve operasyonel sorunları çözmek için geliştiricilerin aşina olduğu araçların (öncelikle Git, dolayısıyla adı) kullanılması anlamına geliyor. Özellikle Kubernetes'in yapılandırmalarını Git'te saklayarak ve değişiklikleri otomatik olarak kümeye dağıtarak çalışmasından bahsediyoruz. Matthias Jg bu makalede bu kullanıma sunma konusunda iki yaklaşımdan bahsediyor.
Geçen yıl, (aslında bu resmi olarak Ağustos 2017'de gerçekleşti - yaklaşık çeviri) Kubernetes'te uygulamaların dağıtımına yönelik yeni bir yaklaşım var. Buna GitOps denir ve dağıtım sürümlerinin Git deposunun güvenli ortamında izlendiği temel fikrine dayanır.
Bu yaklaşımın başlıca avantajları şunlardır::
- Dağıtım sürümü oluşturma ve değişiklik geçmişi. Tüm kümenin durumu Git deposunda depolanır ve dağıtımlar yalnızca taahhütler aracılığıyla güncellenir. Ayrıca tüm değişiklikler taahhüt geçmişi kullanılarak takip edilebilir.
- Tanıdık Git komutlarını kullanarak geri alma işlemleri... Sade
git resetdağıtımlardaki değişiklikleri sıfırlamanıza olanak tanır; geçmiş durumlar her zaman mevcuttur. - Hazır erişim kontrolü. Tipik olarak Git sistemi çok sayıda hassas veri içerir, bu nedenle çoğu şirket bu verileri korumaya özel önem verir. Buna göre bu koruma aynı zamanda konuşlandırmalı işlemler için de geçerlidir.
- Dağıtımlara İlişkin Politikalar. Çoğu Git sistemi, yerel olarak şube bazında politikaları destekler; örneğin, yalnızca çekme istekleri ana öğeyi güncelleyebilir ve değişikliklerin başka bir ekip üyesi tarafından incelenip kabul edilmesi gerekir. Erişim kontrolünde olduğu gibi dağıtım güncellemelerinde de aynı politikalar geçerlidir.
Gördüğünüz gibi GitOps yönteminin pek çok faydası var. Geçtiğimiz yıl boyunca iki yaklaşım özellikle popülerlik kazandı. Biri itme tabanlı, diğeri çekme tabanlı. Bunlara bakmadan önce tipik Kubernetes dağıtımlarının nasıl göründüğüne bakalım.
Dağıtım Yöntemleri
Son yıllarda Kubernetes'te dağıtımlara yönelik çeşitli yöntemler ve araçlar oluşturuldu:
- Yerel Kubernetes/Kustomize şablonlarını temel alır. Bu, uygulamaları Kubernetes'te dağıtmanın en kolay yoludur. Geliştirici temel YAML dosyalarını oluşturur ve bunları uygular. Sürekli aynı şablonları yeniden yazmaktan kurtulmak için Kustomize geliştirildi (Kubernetes şablonlarını modüllere dönüştürür). Not. tercüme: Özelleştirme kubectl'e entegre edilmiştir .
- Dümen Haritaları. Dümen grafikleri, uygulamaları şablon tabanlı bir yaklaşıma göre daha esnek özelleştirme seçenekleriyle dağıtmak için kullanılan şablonlar, başlangıç kapsayıcıları, yardımcı dosyalar vb. kümeleri oluşturmanıza olanak tanır. Bu yöntem şablonlu YAML dosyalarını temel alır. Helm bunları çeşitli parametrelerle doldurur ve ardından bunları kümeye dağıtan ve güncellemelere ve geri almalara izin veren bir küme bileşeni olan Tiller'a gönderir. Önemli olan Helm'in esasen sadece istenen değerleri şablonlara yerleştirmesi ve daha sonra bunları geleneksel yaklaşımda yapıldığı gibi uygulamasıdır. (tüm bunların nasıl çalıştığı ve bunu nasıl kullanabileceğinizle ilgili daha fazla bilgiyi sitemizde bulabilirsiniz.) - yaklaşık. çeviri.). Çok çeşitli görevleri kapsayan çok çeşitli hazır Dümen çizelgeleri vardır.
- Alternatif Araçlar. Birçok alternatif araç var. Hepsinin ortak noktası, bazı şablon dosyalarını Kubernetes tarafından okunabilen YAML dosyalarına dönüştürüp kullanmalarıdır.
Çalışmamızda, önemli araçlar için sürekli olarak Helm grafiklerini (çünkü zaten birçok şey hazır olduğundan hayatı çok daha kolaylaştırır) ve kendi uygulamalarımızı dağıtmak için "saf" Kubernetes YAML dosyalarını kullanırız.
Çekme itme
Son blog yazılarımdan birinde aracı tanıttım Bu, şablonları Git deposuna kaydetmenize ve kapsayıcının her kaydedilmesinden veya itilmesinden sonra dağıtımı güncellemenize olanak tanır. Deneyimlerim, bu aracın çekme yaklaşımını destekleyen ana araçlardan biri olduğunu gösteriyor, bu yüzden ona sık sık başvuracağım. Nasıl kullanılacağı hakkında daha fazla bilgi edinmek istiyorsanız, burada .
NB! GitOps kullanmanın tüm faydaları her iki yaklaşım için de aynı kalır.
Çekme temelli yaklaşım
Çekme yaklaşımı, tüm değişikliklerin küme içinden uygulanması gerçeğine dayanmaktadır. Kümenin içinde, ilgili Git ve Docker Registry depolarını düzenli olarak kontrol eden bir operatör vardır. Bunlarda herhangi bir değişiklik olması durumunda kümenin durumu dahili olarak güncellenir. Hiçbir harici istemcinin küme yöneticisi haklarına erişimi olmadığından bu işlemin genellikle çok güvenli olduğu kabul edilir.
Artıları:
- Hiçbir harici istemcinin kümede değişiklik yapma hakkı yoktur; tüm güncellemeler küme içerisinden dağıtılır.
- Bazı araçlar aynı zamanda Dümen grafiği güncellemelerini senkronize etmenize ve bunları kümeye bağlamanıza da olanak tanır.
- Docker Registry yeni sürümler için taranabilir. Yeni bir görüntü mevcutsa Git deposu ve dağıtımı yeni sürüme güncellenir.
- Çekme araçları, farklı Git depoları ve izinleriyle farklı ad alanlarına dağıtılabilir. Bu sayede çok kiracılı bir model kullanılabilmektedir. Örneğin, A ekibi A ad alanını kullanabilir, B ekibi B ad alanını kullanabilir ve altyapı ekibi küresel alanı kullanabilir.
- Kural olarak, aletler çok hafiftir.
- Operatör gibi araçlarla birleştirilmiştir , sırlar Git deposunda şifrelenmiş olarak saklanabilir ve küme içinde alınabilir.
- Dağıtımlar küme içinde gerçekleştiğinden CD ardışık düzenlerine bağlantı yoktur.
Eksileri:
- Helm grafiklerinden dağıtım sırlarını yönetmek normal olanlardan daha zordur, çünkü bunların önce örneğin mühürlü sırlar biçiminde oluşturulması, ardından dahili bir operatör tarafından şifresinin çözülmesi ve ancak bundan sonra çekme aracı tarafından kullanılabilir hale gelmeleri gerekir. Daha sonra sürümü Helm'de önceden konuşlandırılmış sırlardaki değerlerle çalıştırabilirsiniz. En kolay yol, dağıtım için kullanılan tüm Helm değerleri ile bir sır oluşturmak, şifresini çözmek ve Git'e teslim etmektir.
- Çekme yaklaşımını benimsediğinizde çekme araçlarına bağımlı hale gelirsiniz. Bu, bir kümedeki dağıtım sürecini özelleştirme yeteneğini sınırlar. Örneğin, Kustomize, son şablonların Git'e kaydedilmesinden önce çalıştırılması gerektiği gerçeği nedeniyle karmaşıktır. Bağımsız araçları kullanamayacağınızı söylemiyorum ancak bunların dağıtım sürecinize entegre edilmesi daha zordur.
İtmeye dayalı yaklaşım
Push yaklaşımında, harici bir sistem (çoğunlukla CD ardışık düzenleri), Git deposuna taahhütte bulunulduktan sonra veya önceki CI ardışık düzeni başarılı olursa kümeye dağıtımları başlatır. Bu yaklaşımda sistemin kümeye erişimi vardır.
Avantajları::
- Güvenlik Git deposu ve derleme hattı tarafından belirlenir.
- Helm grafiklerini dağıtmak daha kolaydır ve Helm eklentilerini destekler.
- Sırların yönetilmesi daha kolaydır çünkü sırlar işlem hatlarında kullanılabilir ve ayrıca Git'te şifrelenmiş olarak saklanabilir (kullanıcının tercihlerine bağlı olarak).
- Herhangi bir tür kullanılabildiğinden belirli bir alete bağlantı yoktur.
- Konteyner sürümü güncellemeleri derleme işlem hattı tarafından başlatılabilir.
Eksileri:
- Küme erişim verileri derleme sisteminin içindedir.
- Dağıtım kapsayıcılarını güncellemek çekme işlemiyle hâlâ daha kolaydır.
- İhtiyacımız olan işlem hatları orijinal olarak Gitlab Runners için yazılmış olabileceğinden ve ardından ekip Azure DevOps veya Jenkins'e geçmeye karar verdiğinden ve çok sayıda derleme işlem hattını taşımak zorunda kalacağından CD sistemine büyük bağımlılık.
Sonuçlar: İtmek mi, Çekmek mi?
Genellikle olduğu gibi her yaklaşımın artıları ve eksileri vardır. Bazı görevlerin biriyle başarılması daha kolay, diğerinin başarılması ise daha zordur. İlk başta dağıtımları manuel olarak yapıyordum ancak Weave Flux ile ilgili birkaç yazıya rastladıktan sonra GitOps süreçlerini tüm projeler için uygulamaya karar verdim. Temel şablonlar için bu kolaydı ancak daha sonra Helm grafiklerinde zorluklarla karşılaşmaya başladım. O zamanlar Weave Flux, Helm Chart Operator'un yalnızca ilkel bir versiyonunu sunuyordu, ancak şimdi bile bazı görevler, sırları manuel olarak oluşturma ve uygulama ihtiyacı nedeniyle daha zor. Çekme yaklaşımının çok daha güvenli olduğunu, çünkü küme kimlik bilgilerine küme dışından erişilemediğini ve bunun da ekstra çabaya değecek kadar güvenliği artırdığını iddia edebilirsiniz.
Biraz düşündükten sonra, bunun böyle olmadığı yönünde beklenmedik bir sonuca vardım. Maksimum koruma gerektiren bileşenlerden bahsedecek olursak bu listede gizli depolama, CI/CD sistemleri ve Git depoları yer alacaktır. İçlerindeki bilgiler çok savunmasızdır ve maksimum korumaya ihtiyaç duyar. Ek olarak, birisi Git deponuza girerse ve oraya kod gönderebilirse, istediği her şeyi dağıtabilir (ister çekme ister gönderme olsun) ve kümenin sistemlerine sızabilir. Bu nedenle korunması gereken en önemli bileşenler, küme kimlik bilgileri değil, Git deposu ve CI/CD sistemleridir. Bu tür sistemler için iyi yapılandırılmış politikalarınız ve güvenlik kontrolleriniz varsa ve küme kimlik bilgileri ardışık düzenlere yalnızca sır olarak çıkarılıyorsa, çekme yaklaşımının ek güvenliği başlangıçta düşünüldüğü kadar değerli olmayabilir.
Peki çekme yaklaşımı daha emek yoğunsa ve güvenlik açısından bir fayda sağlamıyorsa sadece itme yaklaşımını kullanmak mantıklı değil mi? Ancak birisi, itme yaklaşımında CD sistemine çok bağlı olduğunuzu ve belki de gelecekte geçişleri gerçekleştirmenin daha kolay olması için bunu yapmamanın daha iyi olacağını iddia edebilir.
Bana göre (her zaman olduğu gibi), belirli bir durum veya kombin için en uygun olanı kullanmalısınız. Şahsen ben her iki yaklaşımı da kullanıyorum: Çoğunlukla kendi hizmetlerimizi içeren çekme tabanlı dağıtımlar için Weave Flux ve Helm grafiklerini kümeye uygulamayı kolaylaştıran ve gizli dizileri sorunsuz bir şekilde oluşturmanıza olanak tanıyan Helm ve eklentilerle bir push yaklaşımı. Hiçbir zaman tüm durumlara uygun tek bir çözümün olmayacağını düşünüyorum çünkü her zaman çok sayıda nüans vardır ve bunlar spesifik uygulamaya bağlıdır. Bununla birlikte GitOps'u şiddetle tavsiye ediyorum; hayatı çok daha kolay hale getiriyor ve güvenliği artırıyor.
Bu konudaki deneyimimin, dağıtım türünüz için hangi yöntemin daha uygun olduğuna karar vermenize yardımcı olacağını umuyorum ve görüşünüzü duymaktan memnuniyet duyarım.
Çevirmenden PS Notu
Çekme modelinin dezavantajı, işlenmiş bildirimleri Git'e yerleştirmenin zor olmasıdır, ancak çekme modelindeki CD hattının kullanıma sunmadan ayrı olarak yaşaması ve esasen bir kategori hattı haline gelmesi gibi bir dezavantaj yoktur. Sürekli Uygula. Bu nedenle, tüm dağıtımlardan durumlarını toplamak ve tercihen CD sistemine referansla bir şekilde günlüklere/durumlara erişim sağlamak için daha fazla çaba gerekecektir.
Bu anlamda itme modeli, en azından bazı kullanıma sunma garantileri vermemize olanak tanır, çünkü boru hattının ömrü, kullanıma sunmanın ömrüne eşit hale getirilebilir.
Her iki modeli de denedik ve makalenin yazarıyla aynı sonuçlara ulaştık:
- Çekme modeli, sistem bileşenlerinin güncellemelerini çok sayıda kümede organize etmemiz için uygundur (bkz. ).
- GitLab CI'yı temel alan push modeli, Helm grafiklerini kullanarak uygulamaların kullanıma sunulması için çok uygundur. Aynı zamanda, araç kullanılarak işlem hatları içindeki dağıtımların kullanıma sunulması izlenir. . Bu arada bu projemiz kapsamında KubeCon Europe'19'daki standımızda DevOps mühendislerinin acil sorunlarını tartıştığımızda sürekli “GitOps” sesini duyduk.
çevirmenden PPS
Blogumuzda da okuyun:
- «";
- «";
- «";
- «'.
Ankete sadece kayıtlı kullanıcılar katılabilir. Lütfen.
GitOps'u kullanıyor musunuz?
-
Evet, çekme yaklaşımı
-
Evet, it
-
Evet, çek + it
-
Evet, başka bir şey
-
Hayır
30 kullanıcı oy kullandı. 10 kişi çekimser kaldı.
Kaynak: habr.com