Herkese selam! Adım Pavel Agaletsky. Lamoda dağıtım sistemini geliştiren bir ekipte ekip lideri olarak çalışıyorum. 2018 yılında HighLoad++ konferansında konuştum ve bugün raporumun metnini sunmak istiyorum.

Konumuz, şirketimizin sistem ve hizmetleri farklı ortamlara dağıtma konusundaki deneyimine adanmıştır. Tüm sistemleri sıradan sanal sunuculara dağıttığımız tarih öncesi zamanlarımızdan başlayarak, Nomad'dan Kubernetes'te dağıtıma kademeli geçişle sona erdi. Bunu neden yaptığımızı ve bu süreçte ne gibi sorunlar yaşadığımızı anlatacağım.

Uygulamaları VM'ye dağıtma

3 yıl önce şirketin tüm sistem ve hizmetlerinin normal sanal sunuculara dağıtıldığı gerçeğiyle başlayalım. Teknik olarak sistemlerimizin tüm kodları depolanacak ve jenkins kullanılarak otomatik montaj araçları kullanılarak bir araya getirilecek şekilde organize edilmişti. Ansible kullanılarak sürüm kontrol sistemimizden sanal sunuculara aktarıldı. Ayrıca firmamızın sahip olduğu her sistem, biri kafada, ikincisi kuyrukta olmak üzere en az 2 sunucuya konuşlandırılmıştır. Bu iki sistem tüm ayarları, güçleri, konfigürasyonları vb. bakımından birbiriyle tamamen aynıydı. Aralarındaki tek fark, head'in kullanıcı trafiği alması, kuyruğun ise hiçbir zaman kullanıcı trafiği almamasıydı.

Bu neden yapıldı?

Uygulamamızın yeni sürümlerini dağıttığımızda, sorunsuz bir şekilde, yani kullanıcılar için fark edilebilir sonuçlar doğurmadan kullanıma sunulmasını sağlamak istedik. Bu, Ansible kullanılarak bir sonraki derlenmiş sürümün kuyruğa sunulması nedeniyle başarıldı. Orada, dağıtıma katılan kişiler her şeyin yolunda olup olmadığını kontrol edip emin olabiliyordu: tüm ölçümler, bölümler ve uygulamalar çalışıyordu; gerekli komut dosyaları başlatılır. Her şeyin yolunda olduğuna ikna olduktan sonra trafik açıldı. Daha önce kuyruk olan sunucuya gitmeye başladı. Ve daha önce kafa olan, uygulamamızın önceki sürümüne sahip olmasına rağmen kullanıcı trafiği olmadan kaldı.

Yani kullanıcılar için sorunsuzdu. Çünkü anahtarlama anında gerçekleşir, çünkü sadece dengeleyiciyi değiştirir. Sadece dengeleyiciyi geri çevirerek önceki sürüme çok kolay bir şekilde geri dönebilirsiniz. Ayrıca uygulamanın kullanıcı trafiğini almadan önce bile üretim kapasitesine sahip olduğunu doğrulayabildik ki bu oldukça kullanışlıydı.

Bütün bunlarda ne gibi avantajlar gördük?

1. Öncelikle bu kadarı yeterli sadece işe yarıyor. Herkes böyle bir dağıtım planının nasıl çalıştığını anlıyor çünkü çoğu kişi daha önce normal sanal sunuculara dağıtım yapmıştı.
2. Bu yeterli güvenilirDağıtım teknolojisi basit olduğundan binlerce şirket tarafından test edilmiştir. Milyonlarca sunucu bu şekilde konuşlandırılmıştır. Bir şeyi kırmak zordur.
3. Ve sonunda alabildik atom konuşlandırmaları. Eski sürüm ile yeni sürüm arasında fark edilebilir bir geçiş aşaması olmadan, kullanıcılar için eş zamanlı olarak gerçekleşen dağıtımlar.

Ancak tüm bunlarda bazı eksiklikler de gördük:

1. Üretim ortamına, geliştirme ortamına ek olarak başka ortamlar da vardır. Örneğin, qa ve üretim öncesi. O zamanlar çok sayıda sunucumuz ve 60'a yakın hizmetimiz vardı. Bu sebeple gerekliydi her hizmet için en son sürümü koruyun sanal makine. Üstelik kütüphaneleri güncellemek veya yeni bağımlılıklar yüklemek istiyorsanız bunu tüm ortamlarda yapmanız gerekir. Ayrıca uygulamanızın bir sonraki yeni sürümünü dağıtacağınız zamanı devops'un gerekli ortam ayarlarını gerçekleştirdiği zamanla senkronize etmeniz gerekiyordu. Bu durumda çevremizin tüm ortamlarda biraz farklı olacağı bir duruma aynı anda girmek kolaydır. Örneğin, bir QA ortamında kitaplıkların bazı sürümleri olacak ve bir üretim ortamında farklı sürümler olacak ve bu da sorunlara yol açacaktır.
2. Bağımlılıkları güncellemede zorluk başvurunuz. Bu sana değil karşı takıma bağlı. Yani sunucuların bakımını yapan devops ekibinden. Onlara uygun bir görev ve ne yapmak istediğinizin bir tanımını vermelisiniz.
3. O zamanlar elimizdeki büyük büyük monolitleri de ayrı küçük servislere bölmek istedik çünkü bunların giderek daha fazla olacağını anladık. O zamanlar zaten 100'den fazlasına sahiptik ve her yeni hizmet için ayrı bir yeni sanal makine oluşturmak gerekiyordu ve bunun da bakımı ve dağıtımı gerekiyordu. Ayrıca bir arabaya değil en az iki arabaya ihtiyacınız var. Tüm bunlara QA ortamı da eklendi. Bu sorunlara neden olur ve yeni sistemler kurup çalıştırmanızı zorlaştırır. karmaşık, pahalı ve uzun bir süreçtir.

Bu nedenle, normal sanal makinelerin dağıtımından uygulamalarımızı bir liman işçisi konteynerinde dağıtmaya geçmenin daha uygun olacağına karar verdik. Eğer docker'ınız varsa, sadece bir konteyneri yükseltemeyeceğiniz için uygulamayı bir kümede çalıştırabilecek bir sisteme ihtiyacınız vardır. Genellikle kaç konteynerin kaldırıldığını takip etmek istersiniz, böylece otomatik olarak kaldırılırlar. Bu nedenle bir kontrol sistemi seçmemiz gerekiyordu.

Hangisini alabileceğimizi uzun süre düşündük. Gerçek şu ki, o zamanlar sıradan sanal sunuculardaki bu dağıtım yığını, işletim sistemlerinin en son sürümlerine sahip olmadıkları için biraz eskiydi. Bir noktada desteklenmesi pek uygun olmayan FreeBSD bile vardı. Docker'a mümkün olduğunca çabuk geçmemiz gerektiğini anladık. Geliştiricilerimiz farklı çözümlerle mevcut tecrübelerini değerlendirip Nomad gibi bir sistemi tercih ettiler.

Nomad'a geç

Nomad, HashiCorp'un bir ürünüdür. Ayrıca diğer çözümleriyle de tanınırlar:

"Konsolos" hizmet keşfi için bir araçtır.

"Terraform" - kod olarak altyapı adı verilen, sunucuları yapılandırma yoluyla yapılandırmanıza olanak tanıyan, sunucuları yönetmeye yönelik bir sistem.

"Serseri" sanal makineleri yerel olarak veya belirli yapılandırma dosyaları aracılığıyla bulutta dağıtmanıza olanak tanır.

O zamanlar Nomad, tüm altyapıyı değiştirmeden hızla geçiş yapılabilecek oldukça basit bir çözüm gibi görünüyordu. Üstelik öğrenmesi oldukça kolaydır. Bu yüzden konteynerimizin filtreleme sistemi olarak bunu seçtik.

Sisteminizi Nomad'a dağıtmak için neye ihtiyacınız var?

1. Öncelikle ihtiyacınız var liman işçisi resmi başvurunuz. Bunu oluşturmanız ve docker görüntü deposuna yerleştirmeniz gerekir. Bizim durumumuzda bu bir yapay yapıdır - farklı türdeki çeşitli eserleri içine itmenize izin veren bir sistem. Arşivleri, liman işçisi görüntülerini, besteci PHP paketlerini, NPM paketlerini vb. depolayabilir.
2. Ayrıca gerekli yapılandırma dosyasıBu Nomad'a neyi, nerede ve ne kadar konuşlandırmak istediğinizi söyleyecektir.

Nomad hakkında konuştuğumuzda bilgi dosyası formatı olarak HCL dilini kullanır. HashiCorp Yapılandırma Dili. Bu, hizmetinizi Nomad terimleriyle tanımlamanıza olanak tanıyan bir Yaml üst kümesidir.

Dağıtım sırasında kaç konteyner dağıtmak istediğinizi, hangi görüntülerin bunlara çeşitli parametreler aktaracağını söylemenize olanak tanır. Böylece Nomad'a bu dosyayı besliyorsunuz ve o da buna göre konteynerleri üretime alıyor.

Bizim durumumuzda, her hizmet için tamamen aynı HCL dosyalarını yazmanın pek uygun olmayacağını fark ettik çünkü çok sayıda hizmet var ve bazen bunları güncellemek istiyorsunuz. Bir hizmetin tek bir örnekte değil, çeşitli farklı hizmetlerde dağıtıldığı görülür. Örneğin üretimde sahip olduğumuz sistemlerden birinin üretimde 100'den fazla örneği var. Aynı görüntülerden çalıştırılırlar ancak yapılandırma ayarları ve yapılandırma dosyaları bakımından farklılık gösterirler.

Bu nedenle, dağıtım için tüm yapılandırma dosyalarımızı tek bir ortak depoda saklamanın bizim için uygun olacağına karar verdik. Bu şekilde görünür oldular: Bakımları kolaydı ve hangi sistemlere sahip olduğumuzu görebiliyorduk. Gerekirse bir şeyi güncellemek veya değiştirmek de kolaydır. Yeni bir sistem eklemek de zor değil; yalnızca yeni dizinde bir yapılandırma dosyası oluşturmanız yeterli. İçinde şu dosyalar bulunur: hizmetimizin açıklamasını içeren service.hcl ve üretimde dağıtılan bu hizmetin yapılandırılmasına izin veren bazı env dosyaları.

Ancak sistemlerimizden bazıları üretimde tek kopya olarak değil, aynı anda birkaç kopya halinde kullanılıyor. Bu nedenle yapılandırmaları saf haliyle değil, şablonlanmış haliyle saklamanın bizim için uygun olacağına karar verdik. Ve biz seçtik Jinja 2. Bu formatta, hem hizmetin yapılandırmalarını hem de onun için gereken env dosyalarını saklıyoruz.

Ek olarak, hizmetinizi üretime, istenen ortama, istenen hedefe başlatmanıza ve dağıtmanıza olanak tanıyan, tüm projeler için ortak olan bir dağıtım komut dosyasını depoya yerleştirdik. HCL yapılandırmamızı bir şablona dönüştürdüğümüz durumda, daha önce normal bir Nomad yapılandırması olan HCL dosyası bu durumda biraz farklı görünmeye başladı.

Yani, bazı yapılandırma konumu değişkenlerini env dosyalarından veya diğer kaynaklardan alınan değişken eklemelerle değiştirdik. Ayrıca HCL dosyalarını dinamik olarak toplama fırsatına sahip olduk, yani sadece sıradan değişken eklemeleri kullanamıyoruz. Jinja döngüleri ve koşulları desteklediğinden, burada uygulamalarınızı tam olarak nereye dağıttığınıza bağlı olarak değişen yapılandırma dosyaları da oluşturabilirsiniz.

Örneğin, hizmetinizi üretim öncesi ve üretime dağıtmak istiyorsunuz. Diyelim ki üretim öncesi cron komut dosyalarını çalıştırmak istemiyorsunuz, ancak hizmeti ayrı bir alanda görmek ve çalıştığından emin olmak istiyorsunuz. Hizmeti dağıtan herkes için süreç çok basit ve şeffaf görünüyor. Tek yapmanız gereken, konuşlandırma.sh dosyasını yürütmek, hangi hizmeti ve hangi hedefe dağıtmak istediğinizi belirtmektir. Örneğin belirli bir sistemi Rusya'ya, Beyaz Rusya'ya veya Kazakistan'a dağıtmak istiyorsunuz. Bunu yapmak için parametrelerden birini değiştirmeniz yeterlidir; doğru yapılandırma dosyasına sahip olursunuz.

Nomad hizmeti kümenize zaten dağıtıldığında şu şekilde görünür.

Öncelikle dışarıda tüm kullanıcı trafiğini alacak bir tür dengeleyiciye ihtiyacınız var. Consul ile birlikte çalışacak ve belirli bir alan adına karşılık gelen belirli bir hizmetin nerede, hangi düğümde, hangi IP adresinde bulunduğunu öğrenecek. Consul'daki hizmetler Nomad'ın kendisinden gelir. Bunlar aynı firmanın ürünleri olduğundan birbirleriyle oldukça ilişkilidirler. Nomad'ın kutudan çıktığı gibi Consul'da başlatılan tüm hizmetleri kaydedebildiğini söyleyebiliriz.

Ön uç yük dengeleyiciniz hangi hizmete trafik göndereceğini öğrendikten sonra, bunu uygun konteynere veya uygulamanızla eşleşen birden fazla konteynere iletir. Doğal olarak güvenliği de düşünmek gerekiyor. Tüm hizmetler konteynerlerdeki aynı sanal makinelerde çalışsa da, bu genellikle herhangi bir hizmetten diğerine ücretsiz erişimin engellenmesini gerektirir. Bunu segmentasyonla başardık. Her hizmet, yönlendirme kuralları ve diğer sistem ve hizmetlere erişime izin verme/reddetme kurallarının belirlendiği kendi sanal ağında başlatıldı. Hem bu kümenin içinde hem de dışında bulunabilirler. Örneğin, bir hizmetin belirli bir veritabanına bağlanmasını engellemek istiyorsanız bu, ağ düzeyinde segmentasyon yoluyla yapılabilir. Yani, yanlışlıkla bile test ortamından üretim veritabanınıza yanlışlıkla bağlanamazsınız.

Geçiş bize insan kaynakları açısından ne kadara mal oldu?

Şirketin tamamının Nomad'a geçişi yaklaşık 5-6 ay sürdü. Hizmetten hizmete göre hareket ettik, ancak oldukça hızlı bir tempoyla. Her ekibin hizmetler için kendi kapsayıcılarını oluşturması gerekiyordu.

Öyle bir yaklaşım benimsedik ki, her ekip kendi sistemlerine ait docker görüntülerinden bağımsız olarak sorumlu oluyor. Devops, dağıtım için gerekli genel altyapıyı, yani kümenin kendisine destek, CI sistemi desteği vb. sağlar. Ve o dönemde 60'tan fazla sistemi Nomad'a taşıdık, bu da yaklaşık 2 bin konteynere tekabül ediyor.

Devops, dağıtım ve sunucularla ilgili her şeyin genel altyapısından sorumludur. Ve her geliştirme ekibi, belirli bir konteynerde genel olarak neye ihtiyaç duyduğunu bilen ekip olduğundan, kendi özel sistemi için konteynerleri uygulamaktan sorumludur.

Nomad'ı terk etme nedenleri

Diğerlerinin yanı sıra Nomad ve docker'ı kullanarak dağıtıma geçerek ne gibi avantajlar elde ettik?

1. Biz eşit koşullar sağlandı tüm ortamlar için. Geliştirme, QA ortamı, üretim öncesi ve üretim aşamalarında aynı bağımlılıklarla aynı kapsayıcı görüntüleri kullanılır. Buna göre, üretimde ortaya çıkacak şeyin daha önce yerel olarak veya test ortamınızda test ettiğiniz şey olmaması ihtimali neredeyse yoktur.
2. Ayrıca bunun yeterli olduğunu gördük. yeni bir hizmet eklemek kolay. Dağıtım açısından bakıldığında, herhangi bir yeni sistem çok basit bir şekilde başlatılır. Yapılandırmaları saklayan depoya gidin, sisteminiz için oraya başka bir yapılandırma ekleyin, artık hazırsınız. Devops'un herhangi bir ek çabasına gerek kalmadan sisteminizi üretime dağıtabilirsiniz.
3. tüm yapılandırma dosyaları ortak bir depoda inceleme altında olduğu ortaya çıktı. Sistemlerimizi sanal sunucular kullanarak dağıttığımızda, yapılandırmaların aynı depoda olduğu Ansible'ı kullanıyorduk. Ancak çoğu geliştirici için bununla çalışmak biraz daha zordu. Burada, hizmeti dağıtmak için eklemeniz gereken yapılandırma ve kod hacmi çok daha küçük hale geldi. Ayrıca geliştiricilerin bunu düzeltmesi veya değiştirmesi çok kolaydır. Örneğin Nomad'ın yeni bir sürümüne geçiş durumunda, aynı yerde bulunan tüm işletim dosyalarını alıp toplu olarak güncelleyebilirler.

Ancak birkaç dezavantajla da karşılaştık:

Görünüşe göre biz kusursuz dağıtımlar sağlanamadı Nomad'ın durumunda. Konteynerleri farklı koşullar altında kullanıma sunduğunda çalışır durumda olduğu ortaya çıkabilir ve Nomad, onu trafik almaya hazır bir konteyner olarak algıladı. Bu, içindeki uygulamanın başlatılma şansı bile bulamadan gerçekleşti. Bu nedenle trafik henüz kabul etmeye hazır olmayan bir konteynere akmaya başladığından sistem kısa süreliğine 500 hata üretmeye başladı.

Bazılarıyla karşılaştık bataklıklar tarafından. En önemli hata, çok sayıda sisteminiz ve konteyneriniz varsa Nomad'ın büyük bir kümeyi pek iyi idare edememesidir. Nomad kümesinde bulunan sunuculardan birini bakım için çıkarmak istediğinizde, kümenin pek iyi hissetmemesi ve dağılması ihtimali oldukça yüksektir. Örneğin bazı konteynerler düşebilir ve yükselmeyebilir; eğer tüm üretim sistemleriniz Nomad tarafından yönetilen bir kümede bulunuyorsa, bu size daha sonra çok pahalıya mal olacaktır.

Bu yüzden bundan sonra nereye gitmemiz gerektiğini düşünmeye karar verdik. O noktada neyi başarmak istediğimizin çok daha fazla farkına vardık. Yani: güvenilirlik, Nomad'ın sağladığından biraz daha fazla işlev ve daha olgun, daha kararlı bir sistem istiyoruz.

Bu bağlamda tercihimiz, küme başlatmak için en popüler platform olarak Kubernetes'e düştü. Özellikle konteynerlerimizin boyutu ve sayısının yeterince büyük olduğu göz önüne alındığında. Bu tür amaçlar için Kubernetes bakabileceğimiz en uygun sistem gibi görünüyordu.

Kubernetes'e geçiş

Sizlere Kubernetes'in temel kavramlarından ve Nomad'dan nasıl farklı olduklarından biraz bahsedeceğim.

Öncelikle Kubernetes'teki en temel kavram pod kavramıdır. Koza her zaman birlikte çalışan bir veya daha fazla konteynerden oluşan bir gruptur. Ve her zaman sanki her zaman aynı sanal makinedeymiş gibi çalışırlar. Farklı portlarda IP 127.0.0.1 üzerinden birbirlerine erişilebilirler.

Klasik şema olan nginx ve php-fpm'den oluşan bir PHP uygulamanız olduğunu varsayalım. Büyük ihtimalle hem nginx hem de php-fpm konteynerlerini her zaman bir arada tutmak isteyeceksiniz. Kubernetes, bunları ortak bir bölme olarak tanımlayarak bunu başarmanıza olanak tanır. Bu tam olarak Nomad'da elde edemediğimiz şeydi.

İkinci kavram ise açılma. Gerçek şu ki kapsülün kendisi geçici bir şeydir; başlar ve kaybolur. Önce tüm önceki kapsayıcılarınızı sonlandırıp ardından yeni sürümleri tek seferde mi başlatmak istiyorsunuz, yoksa bunları kademeli olarak kullanıma sunmak mı istiyorsunuz? Bu, dağıtım kavramının sorumlu olduğu süreçtir. Pod'larınızı nasıl, hangi miktarda dağıtacağınızı ve bunları nasıl güncelleyeceğinizi açıklar.

Üçüncü kavram ise hizmet. Hizmetiniz aslında trafiğinizin bir kısmını alan ve ardından bunu hizmetinize karşılık gelen bir veya daha fazla bölmeye ileten sisteminizdir. Yani şu veya bu isimle şu veya bu hizmete gelen tüm trafiğin bu belirli bölmelere gönderilmesi gerektiğini söylemenizi sağlar. Ve aynı zamanda trafik dengelemeyi de sağlar. Yani, uygulamanızın iki bölmesini başlatabilirsiniz ve gelen tüm trafik, bu hizmetle ilgili bölmeler arasında eşit şekilde dengelenecektir.

Ve dördüncü temel kavram Giriş. Bu, Kubernetes kümesinde çalışan bir hizmettir. Tüm istekleri devralan harici bir yük dengeleyici görevi görür. Ingress, Kubernetes API'yi kullanarak bu isteklerin nereye gönderilmesi gerektiğini belirleyebilir. Üstelik bunu çok esnek bir şekilde yapıyor. Bu hosta ve falanca URL'ye gelen tüm isteklerin bu servise gönderildiğini söyleyebilirsiniz. Ve bu hosta ve başka bir URL'ye gelen bu istekler başka bir servise gönderiliyor.

Bir uygulama geliştiren birinin bakış açısına göre en güzel şey, hepsini kendi başınıza yönetebilmenizdir. Giriş yapılandırmasını ayarlayarak, şu veya bu API'ye gelen tüm trafiği, örneğin Go'da yazılan ayrı kaplara gönderebilirsiniz. Ancak aynı etki alanına ancak farklı bir URL'ye gelen bu trafiğin, çok fazla mantığın olduğu ancak çok hızlı olmayan PHP ile yazılmış kapsayıcılara gönderilmesi gerekir.

Tüm bu kavramları Nomad ile karşılaştıracak olursak ilk üç kavramın hepsinin bir arada Hizmet olduğunu söyleyebiliriz. Ve son kavram Nomad'ın kendisinde yok. Bunun için harici bir dengeleyici kullandık: haproxy, nginx, nginx+ vb. olabilir. Küp söz konusu olduğunda bu ek konsepti ayrıca tanıtmanıza gerek yoktur. Bununla birlikte, Ingress'e dahili olarak bakarsanız, bunun ya nginx, haproxy ya da traefik olduğunu, ancak bir nevi Kubernetes'e yerleşik olduğunu görürsünüz.

Tanımladığım tüm kavramlar aslında bir Kubernetes kümesinde var olan kaynaklardır. Bunları küpte tanımlamak için, Nomad durumunda HCL dosyalarından daha okunaklı ve tanıdık olan bir yaml formatı kullanılır. Ancak yapısal olarak, örneğin pod durumunda aynı şeyi tanımlarlar. Diyorlar ki - Şu ve bu bölmeleri, şu ve bu görüntülerle, şu miktarlarda konuşlandırmak istiyorum.

Ayrıca her bir kaynağı elle oluşturmak istemediğimizi fark ettik: dağıtım, hizmetler, Giriş vb. Bunun yerine, gerekli tüm kaynak bağımlılıklarını doğru sırayla manuel olarak yeniden oluşturmak zorunda kalmamak için dağıtım sırasında sistemlerimizin her birini Kubernetes açısından tanımlamak istedik. Bunu yapmamızı sağlayan sistem olarak Helm seçildi.

Helm'deki temel kavramlar

Dümen Paketleme yöneticisi Kubernetes için. Programlama dillerindeki paket yöneticilerinin çalışma şekline çok benzer. Örneğin, dağıtım nginx, dağıtım php-fpm, Giriş için yapılandırma, yapılandırma haritalarından (bu, sisteminiz için env ve diğer parametreleri ayarlamanıza izin veren bir varlıktır) oluşan bir hizmeti şu şekilde saklamanıza izin verir: grafikler denir. Aynı zamanda Helm Kubernetes'in üzerinde çalışır. Yani bu bir kenara bırakılan bir tür sistem değil, küpün içinde başlatılan başka bir hizmettir. Bir konsol komutu aracılığıyla API'si aracılığıyla onunla etkileşime girersiniz. Kolaylığı ve güzelliği, dümen kırılsa veya onu kümeden çıkarsanız bile, dümen aslında yalnızca sistemi başlatmaya hizmet ettiğinden hizmetleriniz kaybolmayacaktır. Bu durumda Kubernetes'in kendisi hizmetlerin performansından ve durumundan sorumludur.

Bunu da fark ettik şablonlaştırmaDaha önce jinja'yı konfigürasyonlarımıza dahil ederek kendimiz yapmak zorunda kaldığımız dümenin ana özelliklerinden biridir. Sistemleriniz için oluşturduğunuz tüm yapılandırmalar, jinja'ya biraz benzeyen, ancak aslında Kubernetes gibi, dümenin yazıldığı Go dilinin şablonunu kullanan şablonlar biçiminde dümen içinde saklanır.

Helm bizim için birkaç konsept daha ekliyor.

Grafik - bu, hizmetinizin açıklamasıdır. Diğer paket yöneticilerinde buna paket, paket veya benzeri bir şey denir. Burada buna grafik denir.

Değerler yapılandırmalarınızı şablonlardan oluşturmak için kullanmak istediğiniz değişkenlerdir.

Bırakın. Dümen kullanılarak dağıtılan bir hizmet, sürümün artımlı bir sürümünü her aldığında. Helm, önceki sürümdeki hizmet yapılandırmasının ne olduğunu, ondan önceki sürümü vb. hatırlar. Bu nedenle, geri almanız gerekiyorsa, önceki sürüm sürümünü işaret ederek dümen geri çağırma komutunu çalıştırmanız yeterlidir. Geri alma sırasında deponuzdaki ilgili yapılandırma mevcut olmasa bile, helm yine de bunun ne olduğunu hatırlayacak ve sisteminizi önceki sürümde bulunduğu duruma geri döndürecektir.

Dümen kullandığımız durumda, Kubernetes için normal yapılandırmalar aynı zamanda değişkenleri, işlevleri kullanmanın ve koşullu ifadeleri uygulamanın mümkün olduğu şablonlara dönüşür. Bu şekilde, ortama bağlı olarak hizmet yapılandırmanızı toplayabilirsiniz.

Uygulamada işleri Nomad'da yaptığımızdan biraz farklı yapmaya karar verdik. Nomad'da hizmetimizi dağıtmak için gereken hem dağıtım yapılandırmaları hem de n değişkeni tek bir depoda depolandıysa, burada bunları iki ayrı depoya ayırmaya karar verdik. "Dağıtım" deposu yalnızca dağıtım için gereken n değişkeni depolar ve "dümen" deposu yapılandırmaları veya grafikleri depolar.

Bu bize ne verdi?

Yapılandırma dosyalarında gerçekten hassas hiçbir veri saklamamamıza rağmen. Örneğin veritabanlarının şifreleri. Kubernetes'te sır olarak saklanıyorlar ama yine de herkesin erişmesine izin vermek istemediğimiz bazı şeyler var. Bu nedenle, "dağıtım" deposuna erişim daha sınırlıdır ve "dümen" deposu yalnızca hizmetin açıklamasını içerir. Bu nedenle daha geniş bir kitle tarafından güvenli bir şekilde ulaşılabilir.

Yalnızca üretime değil aynı zamanda diğer ortamlara da sahip olduğumuz için, bu ayırma sayesinde dümen çizelgelerimizi hizmetleri yalnızca üretime değil aynı zamanda örneğin bir Kalite Güvence ortamına dağıtmak için yeniden kullanabiliriz. Bunları kullanarak yerel olarak dağıtmak için bile Miniküp - bu Kubernetes'i yerel olarak çalıştırmak için bir şey.

Her deponun içinde, her hizmet için ayrı dizinlere ayrılmış bir bölüm bıraktık. Yani, her dizinin içinde ilgili grafikle ilgili ve sistemimizi çalıştırmak için dağıtılması gereken kaynakları açıklayan şablonlar bulunur. “Dağıtım” deposunda yalnızca env'leri bıraktık. Bu durumda, jinja kullanarak şablon oluşturmayı kullanmadık, çünkü dümenin kendisi kutudan çıktığı gibi şablonlamayı sağlar - bu onun ana işlevlerinden biridir.

Dümen kullanılarak dağıtımın başlatılmasını basitleştiren ve standartlaştıran bir dağıtım betiği bıraktık - konuşlandırma.sh. Dolayısıyla dağıtım yapmak isteyen herkes için dağıtım arayüzü, Nomad aracılığıyla dağıtım yaparken olduğu gibi tamamen aynı görünüyor. Aynı konuşlandırma.sh, hizmetinizin adı ve onu dağıtmak istediğiniz yer. Bu, dümenin dahili olarak başlatılmasına neden olur. O da şablonlardan yapılandırmaları toplar, bunlara gerekli değer dosyalarını ekler, ardından bunları dağıtarak Kubernetes'te başlatır.

Bulgular

Kubernetes hizmeti Nomad'dan daha karmaşık görünüyor.

Burada giden trafik Giriş'e geliyor. Bu, tüm istekleri devralan ve ardından bunları istek verilerine karşılık gelen hizmetlere gönderen yalnızca ön denetleyicidir. Bunları, uygulamanızın dümenindeki açıklamasının bir parçası olan ve geliştiricilerin kendi başlarına belirlediği yapılandırmalara göre belirler. Hizmet, istekleri kendi pod'larına, yani belirli kapsayıcılara göndererek, bu hizmete ait tüm kapsayıcılar arasında gelen trafiği dengeler. Ve elbette ağ düzeyinde güvenlikten de bir yere gitmememiz gerektiğini unutmamalıyız. Bu nedenle segmentasyon, etiketlemeye dayalı bir Kubernetes kümesinde çalışır. Tüm hizmetlerde, hizmetlerin küme içindeki veya dışındaki belirli harici/dahili kaynaklara erişim haklarının ilişkilendirildiği belirli etiketler bulunur.

Geçişi yaptığımızda Kubernetes'in daha önce kullandığımız Nomad'ın tüm yeteneklerine sahip olduğunu ve birçok yeniliğin de eklendiğini gördük. Eklentiler aracılığıyla ve aslında özel kaynak türleri aracılığıyla genişletilebilir. Yani, yalnızca Kubernetes ile birlikte gelen bir şeyi kullanma değil, aynı zamanda kaynağınızı okuyacak kendi kaynağınızı ve hizmetinizi oluşturma fırsatına da sahipsiniz. Bu size Kubernetes'i yeniden kurmanıza ve değişiklik yapmanıza gerek kalmadan sisteminizi genişletmeniz için ek seçenekler sunar.

Bu tür kullanıma bir örnek, Kubernetes kümemizin içinde çalışan Prometheus'tur. Belirli bir hizmetten metrikleri toplamaya başlaması için, hizmet açıklamasına hizmet monitörü adı verilen ek bir kaynak türü eklememiz gerekir. Prometheus, Kubernetes'te başlatıldığında özel bir kaynak türünü okuyabildiği için yeni sistemden otomatik olarak metrik toplamaya başlıyor. Oldukça kullanışlı.

Kubernetes'e yaptığımız ilk dağıtım Mart 2018'de gerçekleşti. Ve bu süre zarfında hiçbir sorun yaşamadık. Önemli hatalar olmadan oldukça kararlı çalışır. Ayrıca bunu daha da genişletebiliriz. Bugün sahip olduğu yeteneklerden yeterince sahibiz ve Kubernetes'in gelişme hızını gerçekten seviyoruz. Şu anda Kubernetes'te 3000'den fazla konteyner bulunuyor. Küme birkaç Düğümü kaplar. Aynı zamanda kullanışlı, stabil ve son derece kontrol edilebilirdir.

Kaynak: habr.com