Sektörden Haberler

Mikro Servisler, Uygulama Dağıtımı (deployment) ve Otomasyon

26 Eylül 2021 Pazar





Sürekli teslimat ve mikro hizmetler hakkında yazılanlar insanın kulağına bir masal gibi gelebilir. Hizmetler yazılmaya başlanır, etrafına biraz CI-sihri koyulur ve seçtiğiniz CD araçlarıyla onu geliştirme, hazırlama ve üretim ortamlarına dağıtırsınız.  Altyapı kısmı genellikle denklemin dışında tutulur ve bu, özellikle bulut ortamlarında yaşam döngüsü boyunca ciddi bir sorun haline gelebilir.  Ortamlarınızda uygun gözlemlenebilirliğe sahip olduğunuz andan itibaren otomasyon mümkün olsa da, testlerin sonuçlarını “teşvik etmek” veya onaylamak için genellikle bir insana ihtiyaç duyma eğiliminde oluruz.  Uygulamalarımızı, uygulamada en iyi kalite kapısı olmayabilecek fakat belirli bir uyumda dağıtmanın genellikle iyi olduğunu düşünürüz.  SRE uygulamaları ve gözlemlenebilirlik platformunuzda toplanan veriler sayesinde otomasyona ve güvenilirliğe olan güven artırılır.

Bizim burada tartışacaklarımız:

  • Infra- ve App-Ops arasındaki ayrım
  •  Bu iki dünya arasındaki sürüm sorunları
  • Veriye dayalı dağıtımlar
  • Dağıtım (Deploy) ve serbest bırakma (Release) arasındaki fark

Bu makalede, sürekli teslim yolculuklarında ve son dönemlerde uzmanların öğrenilen dersleri ve dağıtılan uygulamalarınıza olan güveni artırmak için en iyi uygulamalarla ilgili bazı önerileri okuyacaksınız.

Altyapı ve Sürekli Teslimat Hakkında:

DevOps ve NoOps, günümüzde sıklıkla duyduğumuz terminolojilerdir.  Uygulamamızın her yapı taşı için sorumluluğu paylaşmak mantıklı olsa da, altyapımızla ayrı ayrı ilgilenmenin ve araçları farklı tutmanın daha güvenli olduğunu düşünmemize neden olan uyumluluk gereksinimleri ve başka şeyler olabilir.

  Bulut hizmetleri mikro hizmetleri (veritabanları, depolama paketleri gibi) desteklemek için kullanılıyorsa, tam olarak bu ayrım çok fazla soruna neden olabilir.Bu durumda ilk sorunlardan biri, bu tür altyapı değişikliklerine de hızlı uyum sağlayamamaktır.  Sürekli teslimat dünyamızda, uygulamamızın yeni bir sürümünü dağıtmadan önce manuel bir adıma kadar bekletilemez. Bu, doğru şekilde ele alınmazsa, bir mikro hizmetin altyapıya ihtiyaç duyduğu sırada, uygulama dağıtımını bozabilecek bir duruma yol açabilir.  Bu sorunu çözmenin en geçerli yaklaşımı, birleşik bir altyapı dağıtım iş akışı ve bunu her iki dünyada da tutarlı tutacak uygulamadır.

Uygulama dağıtımına başlamadan önce platformun kendisinin (Kubernetes) hazırlanması gerekir.  Büyük olasılıkla birçok hizmet aynı platformu paylaştığından, onu belirli bir hizmete bağlamak mümkün olmayabilir.  Bu nedenle, platform altyapı kodu uygulama kapsamı dışında ele alınmalıdır.  Daha önce açıklandığı gibi, platform ve uygulama kodunu senkronize tutmak sorunlu olabilir.  Bu nedenle, platform altyapısını mikro seviyede ek  bir hizmet olarak görmeli ve uygulama ekibinin güvenebileceği bazı “Contract-Sözleşme” ler tanımlamalıyız.

 Bunlar aşağıdakilerini içerebilirler:

  • Kullanılmış Kubernetes Sürümleri
  • Tanımlanmış Depolama Sınıfları, Giriş Denetleyicileri ve Kümedeki kullanılabilir Öncelik Sınıfları
  • Ağ kısıtlamaları ve hizmet ağı kullanılabilirliği
  • Yerinde politikalar ve hizmet şablonları.

Bu tür sözleşmelerin kullanılması, özellik ekiplerinin uygulama altyapılarının iyi oluşturmasını sağlar ve özellik ile platform ekibi arasında minimum bir bağımlılık sağlar.

Yönetim ekipleri tarafından kullanılan altyapı parçaları da onlar tarafından tüketilecek ve yönetilecektir.  Bu nedenle, mikro hizmetlerde bir Veritabanına (Örn:MongoDB) ihtiyaç duyan ekip, uygulama dağıtımından önce bunu CD iş akışına da yükleyecek ve sürdürecektir.  Bu, uygulamayı çalıştırmak için yeterli altyapının olmasını sağlar.

Son olarak, platform ekibi, ilkeler ve şablonlar tanımlayarak platformdaki kaynakların ve bulut altyapısının kullanımını kontrol edebilir.  İlkeleri kullanarak (örneğin, Open Policy Agent), mikro hizmet dağıtımları için sınırlar tanımlayabilirsiniz.

 Örnek olarak, Platform operatörleri, kaynak isteklerinin ve sınırlarının tanımlanmasını zorunlu kılan politikalar tanımlayabilir ve yalnızca güvenilir kayıtlardan alınan görüntüler kullanılabilir.  Şablonlar (Çapraz düzlem kompozisyonları, Operatörler/CRD'ler), geliştiricilerin bulut ve platform kaynaklarının kullanılma şeklini tüketip kontrol edebileceği, kullanımı kolay yapı taşları sağlar.  Altyapı kodu ile yapılandırma arasında kesin bir ayrım, platform operatörlerinin kod değişikliklerini uygulama koduyla aynı şekilde test edebilmesini sağlar (ör. boyutlandırma, adlar).  Bu aşamalı teslim yaklaşımı, altyapıdaki değişikliklerin çok erken test edilmesini ve üretimi kesintiye uğratmamasını sağlar.

Yukarıda tartışılan şeyler çoğu zaman işe yarayacaktır ve uygulama ile altyapı arasındaki sözleşmelere güvenmek mümkündür.  Bazen kazalar olur ve bir uygulama veya platform operatörü, eksik altyapıdan kaynaklanan sorunlardan kaçınmak ister.  Örneğin, bir uygulama yapılandırması, Kubernetes Kümesinde bulunmayan ve böyle bir uygulama güncellendiğinde hantallaşabilen belirli bir Storage- veya IngressClass kullanabilir.

Daha sorunlu başka bir örnek, hedef ortamda mevcut olmayan hizmet şablonlarını kullanmak olabilir.  Bu durumda, güncelleme yapmadan önce altyapının kullanılabilir olduğundan emin olmak için işlem öncesi bazı kontrollerin yapılması yardımcı olabilir.  Operatör tabanlı bir dağıtım kullanırken, ön koşulları kontrol etmek ve beklemek mümkündür.  Son olarak, dağıtım belirli bir zaman diliminden sonra iptal edilebilir veya gereksinimler karşılandığında yürütülebilir.

Veriye dayalı dağıtım ve serbest bırakma:

Yazılımı dağıtmak ve yayınlamak için mükemmel zaman konusunda birçok farklı görüş vardır.  Literatürde, mümkün olduğunca sık konuşlandırmamız gerektiğini ve konuşlandırmayı tören haline getirmememiz gerektiğini sık sık okuruz.  Bu kulağa çok romantik gelse de, müşterilerimizin ödedikleri mükemmel yazılımı almalarını sağlamak için yazılımımıza yeterince güvenmeliyiz.  Bu nedenle, bunu sağlamak için teslimat sürecinde yeterince test yapmalı ve çok değerli veriler toplamalıyız.

Mikro hizmetleri dağıtırken ve yayınlarken, genellikle sınırlı bağlamımızı ve hizmetimize ait şeyleri düşünürüz.  İlk başta, uygulama geliştirme düzeyinde bir sisteme dağıtılır ve teslim edilebilir olup olmadığını bulmaya çalışırız ve bunu beklediğimiz gibi başlar.  Daha sonraki testler yürütülür ve testler ne kadar manuel olursa, o kadar pahalı olurlar.  Bu nedenle, CD iş akışındaki her test otomatik ve mümkün olduğunca değerli ve kesin olmalıdır.

Peki hangi testler yapılmalı?

 Bizce konuşlandırılmış ve yazılım hizmetlerinize güven veren (ve çok uzun sürmeyen) her test faydalıdır.  Bu nedenle, dağıtımdan sonra her şeyin beklendiği gibi çalıştığından emin olmak için duman testleri yapmak iyi bir başlangıç noktası olacaktır.

 Ayrıca, yük ve performans testleri, hizmetin beklenen bir yük modelini sürdürmesini sağlayacaktır.  Ayrıca, yük ve kaos testleri birlikte sistemimizin esnekliğine olan güveni artırabilir ve pod çökmeleri, düğüm güncellemeleri gibi “beklenmeyen” olaylara dayanmasını sağlayabilir.

Çoğu zaman, bir mikro hizmet daha kapsamlı bir sisteme aittir ve davranışı (etmemesi gerekir) diğer hizmetleri etkileyebilir.  Bu nedenle, bir sistem bağlamında test etmek, diğer hizmetlerin hizmetin yeni sürümünü kullanarak bozulmamasını sağlayacaktır.  Sonuç olarak, yeni hizmet sürümü, bir sonraki aşamaya geçmeden önce kapsamlı bir dizi uçtan uca test ile test edilmelidir.

Mevcut yazılım dağıtımımıza daha fazla güvenmeye çalışsak da, yazılımımızın başarısına karar veren müşteridir.  Bu nedenle, en önemli metrikler müşterinin bakış açısından yakalananlardır.  Bunun için uygulama sürekli olarak izlenir ve veriler toplanır.  Örneğin, kaos uygulandığında sistemin davranışı Hizmet Düzeyi Hedeflerini ihlal etmemelidir.  Otomatik ölçeklendirme ile sistemin davranışı yüksek yüklerde değişmemelidir.  Bu, gözlemlenebilirlik platformunuzu CD iş akışınıza entegre ederek başarılabilir.

Dağıtmak için mükemmel zamanı düşünürken, mümkün olduğunca hızlı ve mümkün olduğunca güvenle dağıtmak iyi bir fikir olabilir.  Dağıtım, ana dalda her başarılı CI çalıştırmasından veya bir taahhütün bir sürümle etiketlenmesinden sonra tetiklenebilir.  Yazılımı dağıtmak (deploy), yazılımı serbest bırakmakla (release) aynı şey değildir.  Bu nedenle, yeni uygulamayı eskisine paralel olarak dağıtabilir, bazı testler yapabilir ve her şey yolundaysa (Örn: mavi-yeşil ve kanarya dağıtımları) trafiği  değiştirebiliriz.  Ayrıca, sürüm kararlarımızı hata paylarına dayandırabiliriz (bkz. Makaleye Git).

 Bu nedenle, CD araçları, gözlemlenebilirlik platformundaki hata paylarını kontrol edebilir ve daha yeni sürüme geçerken sorunları sürdürmek için yeterli hata bütçesi kaldığında yayınlayabilir.

Araçlar:

Bunu başarmak için, bir kontrol düzlemi olarak CNCF projesi Keptn (https://keptn.sh/) ile tam olarak bu kullanım senaryosunu oluşturabiliriz.  Bu, farklı araçların tek bir çatı altında entegrasyonuna izin verir ve her bir mikro hizmet için dağıtım deneyimini birleştirir.

Yukarıdaki ekran görüntüsü, altyapı etkin bir Keptn dizisinin bir örneğini göstermektedir.  İlk önce izlememizi (Dynatrace Monitoring As Code) yapılandırıyoruz. https://dynatrace-oss.github.io/dynatrace-monitoring-as-code/

Daha sonra altyapı güncellenir ve uygulama teslim edilebilir. Son olarak, bazı duman testleri yürütülür ve konuşlandırmayı bir sonraki aşamaya geçirmek için yeşil bir bayrak kaldırılmadan önce testler çalıştırılır.

Bu yaklaşımı kullanarak, uygulamaları ve altyapıyı birlikte dağıtmak ve altyapı ile uygulama işlemleri arasında net bir sözleşmeye sahip olmak mümkündür.  Uygulamaları mümkün olduğunca hızlı ancak kendinden emin bir şekilde sunarak kodumuz ile üretim ortamları arasındaki yapılandırma kaymasını azaltabiliriz.  Son olarak, kararları otomatikleştirmek ve hizmetimizin kalitesinin müşterinin gereksinimlerini karşılamasını sağlamak için SRE araçlarını (hata payları ve SLI'ler/SLO'lar olarak) kullanabiliriz.

Bir mikro hizmet ortamında altyapı ve uygulama dağıtımının nasıl birleştirileceği ve otomatikleştirileceği, ilk olarak Dynatrace Engineering on Medium'da yayınlanmıştı.

Detaylı bilgi için lütfen tıklayınız.



SEKTÖRDEN HABERLER

Dynatrace, 2021 APM ‘Gartner Magic Quadrant’ Raporunda

Vizyon Bütünlüğü ve Başarılı Proje Gerçekleştirme Açısından En Yüksek ve En İleride Olarak Konumlandırılmıştır.

2020 Gartner Raporu

Dynatrace üst üste 10. kez lider. Gartner'ın 2020 APM Raporu Yayınlandı.

Perform Europe 2018

Perform Europe 2018 in Barcelona

Constantly innovating. 7 years a Gartner MQ leader.

Gartner recognizes Dynatrace as a leader for the 7th consecutive year in the 2016

Compuware - Yazılım Performans Mühendisliği

18 – 19 Şubat 2014 tarihlerinde Hollanda Amsterdam'da düzenlenen Yazılım Performans Yönetimi, Network Performans Yönetimi

"Network Performans" Eğitimi

31 Mart – 5 Nisan 2014 tarihlerinde Compuware-İngiltere - Maidenhead ofisinde, "Network Performans Yönetimi"