“Bulut yerel” veya kısaca “bulut” uygulamalar, özellikle bulut altyapılarında çalışmak üzere yaratılmıştır. Bunlar genellikle bir bulut platformu tarafından yönetilen, kaplar içinde paketlenmiş, gevşek bağlı mikro hizmetler kümesi olarak oluşturulur. Bu tür uygulamalar varsayılan olarak arızalara karşı hazırlıklıdır; bu, ciddi altyapı düzeyinde arızalar durumunda bile güvenilir bir şekilde çalıştıkları ve ölçeklendikleri anlamına gelir. Madalyonun diğer yüzü, bulut platformunun konteyner uygulamalarını otomatik olarak yönetebilmek için bunlara uyguladığı kısıtlamalar (sözleşmeler) dizisidir.
Bulut tabanlı uygulamalara geçmenin gerekliliği ve öneminin tamamen farkında olan birçok kuruluş, hâlâ nereden başlayacağını bilmiyor. Bu yazıda, konteynerli uygulamalar geliştirirken takip edilmesi halinde, bulut platformlarının potansiyelini gerçekleştirmenize ve BT altyapısında ciddi arızalar olması durumunda bile uygulamaların güvenilir şekilde çalıştırılmasına ve ölçeklendirilmesine olanak sağlayacak bir dizi prensibe bakacağız. seviye. Burada özetlenen ilkelerin nihai hedefi, Kubernetes gibi bulut platformları tarafından otomatik olarak yönetilebilecek uygulamaların nasıl oluşturulacağını öğrenmektir.
Yazılım Tasarım İlkeleri
Programlama dünyasında ilkeler, yazılım geliştirirken uyulması gereken oldukça genel kuralları ifade eder. Herhangi bir programlama diliyle çalışırken kullanılabilirler. Her prensibin kendi hedefleri vardır ve bunları gerçekleştirmeye yönelik araçlar genellikle şablonlar ve uygulamalardır. Yüksek kaliteli yazılım yaratmanın, diğerlerinin de kaynağı olan bir takım temel ilkeleri de vardır. İşte temel ilkelere bazı örnekler:
- (Basit tutun, aptalca) – karmaşıklaştırmayın;
- (Kendinizi tekrarlamayın) - kendinizi tekrarlamayın;
- (İhtiyacınız olmayacak) - hemen ihtiyaç duyulmayan bir şey yaratmayın;
- Endişelerin ayrılması – sorumlulukların paylaşılması.
Gördüğünüz gibi, bu ilkeler herhangi bir özel kural belirlemez, ancak birçok geliştirici tarafından paylaşılan ve düzenli olarak atıfta bulunulan, pratik deneyime dayalı sözde sağduyulu düşünceler kategorisine aittir.
Ayrıca, var – Robert Martin tarafından formüle edilen, nesne yönelimli programlama ve tasarımın ilk beş ilkesinden oluşan bir dizi. SOLID, birlikte uygulandığında daha iyi yazılım sistemleri oluşturmaya ve bunların uzun vadede daha iyi korunmasına yardımcı olan geniş, açık uçlu, tamamlayıcı ilkeler içerir.
SOLID ilkeleri OOP alanına aittir ve sınıflar, arayüzler ve kalıtım gibi kavram ve kavramların dilinde formüle edilmiştir. Benzer şekilde, bulut uygulamaları için de geliştirme ilkeleri formüle edilebilir, burada yalnızca temel unsur sınıf değil, konteyner olacaktır. Bu ilkeleri takip ederek Kubernetes gibi bulut platformlarının amaç ve hedeflerini daha iyi karşılayan konteynerli uygulamalar oluşturabilirsiniz.
Bulutta yerel konteynerler: Red Hat yaklaşımı
Günümüzde hemen hemen her uygulama nispeten kolay bir şekilde kaplara paketlenebilmektedir. Ancak uygulamaların Kubernetes gibi bir bulut platformunda etkili bir şekilde otomatikleştirilmesi ve düzenlenmesi için ek çaba gerekmektedir.
Aşağıda özetlenen fikirlerin temeli metodolojiydi. ve kaynak kodu yönetiminden ölçeklendirme modellerine kadar web uygulamaları oluşturmanın çeşitli yönleri üzerine birçok çalışma. Açıklanan ilkeler yalnızca mikro hizmetlerin üzerine inşa edilen ve Kubernetes gibi bulut platformları için tasarlanan konteynerli uygulamaların geliştirilmesi için geçerlidir. Tartışmamızdaki temel öğe konteyner görüntüsüdür ve hedef konteyner çalışma zamanı konteyner düzenleme platformudur. Önerilen ilkelerin amacı, çoğu düzenleme platformunda planlama, ölçeklendirme ve izleme görevlerinin otomatikleştirilebileceği kapsayıcılar oluşturmaktır. İlkeler belirli bir sıraya göre sunulmamaktadır.
Tek Endişe İlkesi (SCP)
Bu ilke birçok bakımdan Tek Sorumluluk İlkesine benzemektedir. ), SOLID kümesinin bir parçasıdır ve her nesnenin bir sorumluluğa sahip olması gerektiğini ve bu sorumluluğun tamamen bir sınıfa dahil edilmesi gerektiğini belirtir. SRP'nin amacı, her sorumluluğun bir değişim nedeni olması ve bir sınıfın değişim için yalnızca bir nedene sahip olması gerektiğidir.
SCP'de, bir konteynerin OOP sınıfına kıyasla daha yüksek düzeyde soyutlamayı ve daha geniş amacını belirtmek için "sorumluluk" kelimesi yerine "endişe" kelimesini kullanırız. Ve eğer SRP'nin amacı değişim için tek bir nedene sahip olmaksa, o zaman SCP'nin arkasında kapları yeniden kullanma ve değiştirme yeteneğini genişletme arzusu vardır. SRP'yi takip ederek ve tek bir sorunu çözen ve bunu işlevsel olarak eksiksiz bir şekilde yapan bir kapsayıcı oluşturarak, bu kapsayıcı görüntüsünü farklı uygulama bağlamlarında yeniden kullanma şansını artırırsınız.
SCP prensibi, her konteynerin tek bir problemi çözmesi ve bunu iyi bir şekilde yapması gerektiğini belirtir. Üstelik konteyner dünyasında SCP'yi elde etmek, OOP dünyasındaki SRP'den daha kolaydır çünkü konteynerler genellikle tek bir işlemi çalıştırır ve çoğu zaman bu süreç tek bir görevi çözer.
Bir konteyner mikro hizmetinin aynı anda birden fazla sorunu çözmesi gerekiyorsa, tek görevli konteynerlere bölünebilir ve sepet ve başlangıç konteyner şablonları kullanılarak tek bir bölmede (konteyner platformu dağıtımının bir birimi) birleştirilebilir. Ek olarak SCP, eski bir konteynerin (bir web sunucusu veya mesaj komisyoncusu gibi) aynı sorunu çözen ancak işlevselliği genişleten veya daha iyi ölçeklenen yeni bir konteynerle değiştirilmesini kolaylaştırır.
Yüksek Gözlemlenebilirlik Prensibi (HOP)
Kapsayıcılar uygulamaları paketlemek ve çalıştırmak için birleşik bir yol olarak kullanıldığında, uygulamaların kendisi bir kara kutu olarak ele alınır. Ancak bunlar bulut konteynerleriyse konteynerlerin durumunu izlemek ve gerekirse uygun eylemi gerçekleştirmek için çalışma zamanına özel API'ler sağlamaları gerekir. Bu olmadan, konteynerlerin güncellenmesi ve yaşam döngülerinin yönetilmesi otomasyonunu birleştirmek mümkün olmayacak ve bu da yazılım sisteminin kararlılığını ve kullanılabilirliğini kötüleştirecektir.
Uygulamada, kapsayıcıya alınmış bir uygulamanın en azından çeşitli durum denetimleri türleri için bir API'ye sahip olması gerekir: canlılık testleri ve hazırlık testleri. Bir uygulama daha fazlasını yapacağını iddia ediyorsa, durumunu izlemek için başka araçlar sağlamalıdır. Örneğin, Fluentd, Logstash ve diğer benzer araçları kullanarak günlük toplama için STDERR ve STDOUT aracılığıyla önemli olayların günlüğe kaydedilmesi. OpenTracing, Prometheus vb. gibi izleme ve ölçüm koleksiyonu kitaplıklarıyla entegrasyonun yanı sıra.
Genel olarak uygulama yine de bir kara kutu olarak ele alınabilir ancak uygulamanın mümkün olan en iyi şekilde izlenebilmesi ve yönetilebilmesi için platformun ihtiyaç duyduğu tüm API'lerin sağlanması gerekir.
Yaşam Döngüsü Uygunluk Prensibi (LCP)
LCP, HOP'un antitezidir. HOP, konteynerin okuma API'lerini platforma sunması gerektiğini belirtirken LCP, uygulamanın platformdan bilgi kabul edebilmesini gerektirir. Üstelik konteyner sadece olayları almakla kalmamalı, aynı zamanda onlara uyum sağlamalı, başka bir deyişle tepki vermelidir. Platforma yazma API'leri sağlamanın bir gereği olarak değerlendirilebilecek prensibin adı da buradan gelmektedir.
Platformlar, bir konteynerin yaşam döngüsünü yönetmeye yardımcı olacak farklı türde olaylara sahiptir. Ancak bunlardan hangisini algılayacağına ve nasıl tepki vereceğine karar vermek uygulamanın kendisine kalmıştır.
Bazı olayların diğerlerinden daha önemli olduğu açıktır. Örneğin, bir uygulama çökmeleri iyi tolere edemiyorsa, sinyal: sonlandırma (SIGTERM) mesajlarını kabul etmeli ve SIGTERM'den sonra gelen sinyal: öldürme (SIGKILL) sinyalini yakalamak için mümkün olduğunca hızlı bir şekilde sonlandırma yordamını başlatmalıdır.
Ayrıca PostStart ve PreStop gibi olaylar bir uygulamanın yaşam döngüsü açısından önemli olabilir. Örneğin, bir uygulamayı başlattıktan sonra isteklere yanıt verebilmesi için biraz ısınma süresi gerekebilir. Veya uygulama kapatıldığında kaynakları özel bir şekilde serbest bırakmalıdır.
Görüntü Değişmezliği İlkesi (IIP)
Container mimarisine alınmış uygulamaların, farklı ortamlarda çalıştırılsalar bile oluşturulduktan sonra değişmeden kalması gerektiği genel olarak kabul edilir. Bu, çalışma zamanında veri depolamayı harici hale getirme (başka bir deyişle bunun için harici araçlar kullanma) ihtiyacını ve her ortam için benzersiz kapsayıcıları değiştirmek veya oluşturmak yerine harici, çalışma zamanına özgü yapılandırmalara güvenme ihtiyacını gerektirir. Uygulamada yapılan herhangi bir değişiklikten sonra konteyner görüntüsünün yeniden oluşturulması ve kullanılan tüm ortamlara dağıtılması gerekir. Bu arada, BT sistemlerini yönetirken, sunucuların ve altyapının değişmezliği ilkesi olarak bilinen benzer bir prensip kullanılıyor.
IIP'nin amacı, farklı çalışma zamanı ortamları için ayrı konteyner görüntüleri oluşturulmasını önlemek ve aynı görüntünün ortama özel uygun konfigürasyonla birlikte her yerde kullanılmasını sağlamaktır. Bu prensibi takip etmek, bulut sistemlerinin otomasyonu açısından uygulama güncellemelerinin geri alınması ve ileri alınması gibi önemli uygulamaları uygulamanıza olanak tanır.
Proses Tek Kullanımlık Prensibi (PDP)
Bir kapsayıcının en önemli özelliklerinden biri geçici olmasıdır: Bir kapsayıcının bir örneğinin oluşturulması ve yok edilmesi kolaydır, dolayısıyla herhangi bir zamanda başka bir örnekle kolayca değiştirilebilir. Böyle bir değişimin birçok nedeni olabilir: hizmet verilebilirlik testinin başarısız olması, uygulamanın ölçeklendirilmesi, başka bir ana bilgisayara aktarım, platform kaynaklarının tükenmesi veya diğer durumlar.
Sonuç olarak, konteynerli uygulamaların bazı harici araçlar kullanarak durumlarını korumaları veya bunun için yedekli dahili dağıtılmış şemaları kullanmaları gerekir. Ayrıca uygulamanın hızlı bir şekilde başlatılıp hızlı bir şekilde kapanması ve ani ölümcül donanım arızalarına karşı hazırlıklı olması gerekir.
Bu prensibin uygulanmasına yardımcı olan uygulamalardan biri kapları küçük tutmaktır. Bulut ortamları, bir konteyner örneğinin başlatılacağı ana bilgisayarı otomatik olarak seçebilir; böylece konteyner ne kadar küçük olursa o kadar hızlı başlar; ağ üzerinden hedef ana bilgisayara daha hızlı kopyalanır.
Kendi Kendine Yeterlilik İlkesi (S-CP)
Bu prensibe göre montaj aşamasında gerekli tüm bileşenler konteynerin içerisine dahil edilir. Kap, sistemin yalnızca saf bir Linux çekirdeğine sahip olduğu varsayımı üzerine inşa edilmeli, dolayısıyla gerekli tüm ek kütüphaneler kabın kendisine yerleştirilmelidir. Ayrıca ilgili programlama dilinin çalışma zamanı, uygulama platformu (gerekirse) ve konteyner uygulaması çalışırken gerekli olacak diğer bağımlılıklar gibi şeyleri de içermelidir.
Ortamdan ortama değişen ve örneğin Kubernetes ConfigMap aracılığıyla çalışma zamanında sağlanması gereken yapılandırmalar için istisnalar yapılmıştır.
Bir uygulama, konteynere alınmış bir web uygulaması içindeki ayrı bir DBMS konteyneri gibi konteynere alınmış çeşitli bileşenler içerebilir. S-CP ilkesine göre, bu kaplar tek bir kapta birleştirilmemeli, ancak DBMS kabı veritabanının çalışması için gerekli her şeyi içerecek ve web uygulama kabı da web'in çalışması için gerekli her şeyi içerecek şekilde yapılmalıdır. uygulama, aynı web sunucusu. Sonuç olarak, çalışma zamanında web uygulaması kapsayıcısı DBMS kapsayıcısına bağlı olacak ve gerektiğinde ona erişecektir.
Çalışma Zamanını Sınırlandırma İlkesi (RCP)
S-CP ilkesi, kabın nasıl oluşturulması gerektiğini ve görüntü ikilisinin neleri içermesi gerektiğini tanımlar. Ancak bir kapsayıcı yalnızca tek bir özelliği olan dosya boyutuna sahip bir “kara kutu” değildir. Yürütme sırasında kapsayıcı başka boyutlar alır: kullanılan bellek miktarı, CPU süresi ve diğer sistem kaynakları.
Ve burada, konteynerin sistem kaynaklarına yönelik gereksinimlerini ayırması ve bunları platforma aktarması gerektiğine göre RCP ilkesi kullanışlı oluyor. Platform, her konteynerin kaynak profiliyle (ne kadar CPU, bellek, ağ ve disk kaynağına ihtiyaç duyduğu) planlama ve otomatik ölçeklendirmeyi en iyi şekilde gerçekleştirebilir, BT kapasitesini yönetebilir ve konteynerler için SLA düzeylerini koruyabilir.
Container'ın kaynak ihtiyaçlarının karşılanmasının yanı sıra uygulamanın kendi sınırlarının dışına çıkmaması da önemlidir. Aksi takdirde, bir kaynak sıkıntısı meydana geldiğinde platformun bunu sonlandırılması veya taşınması gereken uygulamalar listesine dahil etmesi daha olasıdır.
Bulut öncelikli olmaktan bahsettiğimizde çalışma şeklimizden bahsediyoruz.
Yukarıda, bulut ortamları için yüksek kaliteli konteyner uygulamaları oluşturmaya yönelik metodolojik temeli belirleyen bir dizi genel prensibi formüle ettik.
Bu genel ilkelere ek olarak, kapsayıcılarla çalışmak için ek gelişmiş yöntem ve tekniklere de ihtiyacınız olacağını unutmayın. Ayrıca, daha spesifik olan ve duruma göre uygulanması (veya uygulanmaması) gereken birkaç kısa önerimiz var:
- Görüntülerin boyutunu küçültmeye çalışın: geçici dosyaları silin ve gereksiz paketleri kurmayın - kapsayıcı boyutu ne kadar küçük olursa, o kadar hızlı bir şekilde birleştirilir ve ağ üzerinden hedef ana bilgisayara kopyalanır.
- Rastgele Kullanıcı Kimliklerine odaklanın: Kaplarınızı başlatmak için sudo komutunu veya herhangi bir özel kullanıcı kimliğini kullanmayın.
- Önemli bağlantı noktalarını işaretleyin: Bağlantı noktası numaralarını çalışma zamanında ayarlayabilirsiniz, ancak bunları EXPOSE komutunu kullanarak belirtmek daha iyidir; bu, diğer kişilerin ve programların görsellerinizi kullanmasını kolaylaştıracaktır.
- Kalıcı verileri birimlerde saklayın: Container yok edildikten sonra kalması gereken veriler birimlere yazılmalıdır.
- Görüntü meta verilerini yazın: etiketler, etiketler ve açıklamalar görüntülerin kullanımını kolaylaştırır; diğer geliştiriciler size teşekkür edecektir.
- Ana makineyi ve görüntüleri senkronize edin: Konteynerli bazı uygulamalar, konteynerin ana bilgisayarla zaman veya makine kimliği gibi belirli niteliklere göre senkronize edilmesini gerektirir.
- Sonuç olarak, yukarıda listelenen ilkeleri daha etkili bir şekilde uygulamanıza yardımcı olacak şablonları ve en iyi uygulamaları paylaşıyoruz:
11 Haziran, 11.00
Ne öğreneceksin:
- Değişmez Red Hat Enterprise Linux CoreOS
- OpenShift servis ağı
- Operatör çerçevesi
- Yerel çerçeve
Kaynak: habr.com