Çoğumuz, BT blog dünyasında veya konferansında yeni bir terimin daha farkına varıyoruz, er ya da geç benzer bir soru soruyoruz: “Bu nedir? Sadece başka bir moda kelime, bir "moda kelime" mi yoksa gerçekten yakından ilgilenilmeye, çalışmaya ve yeni ufuklar vaad etmeye değer bir şey mi? Terim konusunda aynı şey bana da oldu GitOps bir süre önce. Mevcut birçok makalenin yanı sıra şirketteki meslektaşların bilgileriyle donanmış Bunun ne tür bir canavar olduğunu ve pratikte kullanımının nasıl görünebileceğini anlamaya çalıştım.
Bu arada, terimin yeniliği hakkında GitOps Son anketimiz şunu da söylüyor: Ankete katılanların yarısından fazlası henüz bu ilkeleri uygulamaya başlamadı.
Dolayısıyla altyapı yönetimi sorunu yeni değil. Pek çok bulut sağlayıcısı, bir düzine yıldır genel kullanıma açık durumda ve öyle görünüyor ki, altyapıdan sorumlu ekiplerin işini basit ve anlaşılır hale getirmeleri gerekiyordu. Bununla birlikte, (otomasyonun giderek yeni seviyelere ulaştığı) uygulama geliştirme süreciyle karşılaştırıldığında, altyapı projeleri hâlâ çoğu zaman birçok manuel görevi içeriyor ve özellikle günümüzün hata toleransı, esneklik, ölçeklenebilirlik ve esneklik gereksinimleri göz önüne alındığında, özel bilgi ve uzmanlık gerektiriyor.
Bulut hizmetleri bu gereksinimleri çok başarılı bir şekilde yerine getirdi ve yaklaşımın geliştirilmesine önemli bir ivme kazandıran da onlardı. IAC. Bu anlaşılabilir. Sonuçta tamamen sanal bir veri merkezi yapılandırmayı mümkün kıldılar: fiziksel sunucular, raflar veya ağ bileşenleri yok; tüm altyapı, komut dosyaları ve yapılandırma dosyaları kullanılarak tanımlanabiliyor.
Peki fark tam olarak nedir? GitOps itibaren IAC? Araştırmama bu soruyla başladım. Meslektaşlarımla konuştuktan sonra aşağıdaki karşılaştırmayı yapabildim:
GitOps
IAC
Tüm kodlar git deposunda saklanır
Kod sürümü oluşturma isteğe bağlıdır
Bildirim Kodu Açıklama / Bağımsızlık
Hem bildirimsel hem de emir niteliğindeki açıklamalar kabul edilebilir
Değişiklikler Birleştirme İsteği / Çekme İsteği mekanizmaları kullanılarak etkili olur
Anlaşma, onay ve işbirliği isteğe bağlıdır
Güncellemenin kullanıma sunulması süreci otomatiktir
Güncelleme dağıtım süreci standartlaştırılmamıştır (otomatik, manuel, dosyaları kopyalama, komut satırını kullanma vb.)
Başka bir deyişle GitOps tam olarak ilkelerin uygulanmasıyla doğdu IAC. Öncelikle altyapı ve konfigürasyonlar artık uygulamalarla aynı şekilde depolanabiliyor. Kodun saklanması, paylaşılması, karşılaştırılması ve sürüm oluşturma özelliklerinin kullanılması kolaydır. Sürümler, dallar, geçmiş. Ve tüm bunlar, tüm ekibin erişebileceği, herkesin erişebileceği bir yerde. Dolayısıyla versiyon kontrol sistemlerinin kullanılması tamamen doğal bir gelişme haline geldi. Özellikle git en popüler olanı.
Öte yandan altyapı yönetim süreçlerinin otomatize edilmesi mümkün hale geldi. Artık bu daha hızlı, daha güvenilir ve daha ucuz bir şekilde yapılabiliyor. Üstelik CI/CD'nin ilkeleri yazılım geliştiriciler arasında zaten biliniyordu ve popülerdi. Sadece halihazırda bilinen bilgi ve becerilerin yeni bir alana aktarılması ve uygulanması gerekiyordu. Ancak bu uygulamalar, Altyapının kod olarak standart tanımının ötesine geçti, dolayısıyla kavram GitOps.
Merak GitOpselbette herhangi bir satıcıyla bağlantılı bir ürün, eklenti veya platform olmaması da gerçeğiyle. Bu daha çok aşina olduğumuz başka bir terime benzeyen bir paradigma ve ilkeler dizisidir: DevOps.
Şirket Bu yeni terimin iki tanımını geliştirdik: teorik ve pratik. Teorik olanla başlayalım:
GitOps; sürüm kontrolü, işbirliği, orkestrasyon, CI/CD gibi uygulama geliştirme için kullanılan en iyi DevOps ilkelerini alan ve bunları altyapı yönetimini otomatikleştirmenin zorluklarına uygulayan bir metodolojidir.
Tüm süreçler GitOps Mevcut araçları kullanarak çalışıyorum. Tüm altyapı kodları zaten tanıdık olan git deposunda saklanır, değişiklikler diğer program kodlarıyla aynı onay sürecinden geçer ve kullanıma sunma süreci otomatikleştirilir; bu da insan hatalarını en aza indirmemize, güvenilirliği ve tekrarlanabilirliği artırmamıza olanak tanır.
Pratik bir bakış açısıyla açıklıyoruz GitOps следующим обрахом:
Bu formülün temel bileşenlerinden biri olan kod olarak altyapıyı daha önce tartışmıştık. Geri kalan katılımcıları tanıtalım.
Birleştirme İsteği (alternatif ad Çekme İsteği). Süreç açısından MR, kod değişikliklerinin uygulanmasına ve ardından dalların birleştirilmesine yönelik bir taleptir. Ancak kullandığımız araçlar açısından bu, yapılan tüm değişikliklerin tam bir resmini elde etmek için bir fırsattır: yalnızca belirli sayıda taahhütten toplanan kod farkı değil, aynı zamanda bağlam, test sonuçları ve beklenen nihai sonuç. Altyapı kodundan bahsediyorsak, altyapının tam olarak nasıl değişeceği, kaç yeni kaynağın ekleneceği, kaldırılacağı, değiştirileceği ile ilgileniyoruz. Tercihen daha kullanışlı ve okunması kolay bir formatta. Bulut sağlayıcıları için bu değişikliğin mali etkisinin ne olacağını bilmek iyi bir fikirdir.
Ancak MR aynı zamanda bir işbirliği, etkileşim ve iletişim aracıdır. Kontrol ve denge sisteminin devreye girdiği yer. Basit yorumlardan resmi onaylara ve onaylara kadar.
Son bileşen: CI/CD, zaten bildiğimiz gibi, altyapı değişiklikleri yapma ve test etme sürecini (basit sözdizimi kontrolünden daha karmaşık statik kod analizine kadar) otomatikleştirmeyi mümkün kılar. Ve ayrıca sürüklenmenin daha sonraki tespitinde: sistemin gerçek durumu ile istenen durumu arasındaki farklar. Örneğin yetkisiz manuel değişiklikler veya sistem arızası sonucu.
Evet terim GitOps bizi tamamen yeni bir şeyle tanıştırmıyor, tekerleği yeniden icat etmiyor, sadece halihazırda birikmiş deneyimi yeni bir alanda uyguluyor. Ama gücünün yattığı yer burasıdır.
Ve birdenbire tüm bunların pratikte nasıl göründüğüyle ilgilenmeye başlarsanız, o zaman sizi bizim incelememize davet ediyorum. GitLab'ın nasıl kullanılacağını size adım adım anlatacağım:
-
GitOps'un temel ilkelerini uygulayın
-
Bulut altyapısı oluşturma ve değişiklik yapma (Yandex Bulut örneğini kullanarak)
-
Aktif izlemeyi kullanarak sistemin istenen durumdan sapmasını tespit etmeyi otomatikleştirin
https://bit.ly/34tRpwZ
Kaynak: habr.com