True Engineering olarak biz, güncellemelerin müşteri sunucularına sürekli olarak sunulması için bir süreç oluşturduk ve bu deneyimi paylaşmak istiyoruz.
Başlangıç olarak müşteri için çevrimiçi bir sistem geliştirdik ve bunu kendi Kubernetes kümemize yerleştirdik. Artık yüksek yüklü çözümümüz, tam otomatik bir Sürekli Dağıtım süreci kurduğumuz müşterinin platformuna taşındı. Bu sayede pazara çıkış süresini, yani ürün ortamındaki değişikliklerin uygulanmasını hızlandırdık.
Bu yazıda Sürekli Dağıtım (CD) sürecinin tüm aşamalarından veya güncellemelerin müşterinin platformuna tesliminden bahsedeceğiz:
- Bu süreç nasıl başlıyor?
- müşterinin Git deposuyla senkronizasyon,
- arka uç ve ön uç montajı,
- test ortamında otomatik uygulama dağıtımı,
- Prod'a otomatik dağıtım.
Kurulum ayrıntılarını yol boyunca paylaşacağız.
1. CD'yi başlatın
Sürekli Dağıtım, geliştiricinin değişiklikleri Git depomuzun sürüm dalına göndermesiyle başlar.
Uygulamamız mikro servis mimarisi üzerinde çalışmakta olup tüm bileşenleri tek bir depoda saklanmaktadır. Bu sayede, biri değişse bile tüm mikro hizmetler toplanır ve kurulur.
Çalışmayı birkaç nedenden dolayı tek bir depo aracılığıyla düzenledik:
- Geliştirme kolaylığı - Uygulama aktif olarak geliştirilmektedir, böylece tüm kodlarla aynı anda çalışabilirsiniz.
- Uygulamanın tek bir sistem olarak tüm testleri geçmesini ve müşterinin üretim ortamına teslim edilmesini garanti eden tek bir CI/CD hattı.
- Sürümlerdeki karışıklığı ortadan kaldırıyoruz; mikro hizmet sürümlerinin bir haritasını saklamamıza ve Helm komut dosyalarında her bir mikro hizmet için yapılandırmasını açıklamamıza gerek yok.
2. Müşterinin kaynak kodunun Git deposuyla senkronizasyon
Yapılan değişiklikler müşterinin Git deposuyla otomatik olarak senkronize edilir. Orada, şubeyi güncelledikten sonra başlatılan uygulama derlemesi yapılandırılır ve devamına dağıtım yapılır. Her iki süreç de kendi ortamlarında bir Git deposundan kaynaklanır.
Geliştirme ve test için kendi ortamlarımıza ihtiyacımız olduğundan doğrudan müşterinin deposuyla çalışamayız. Git depomuzu bu amaçlar için kullanırız; onların Git deposuyla senkronize edilir. Bir geliştirici değişiklikleri havuzumuzun uygun şubesine gönderir göndermez GitLab bu değişiklikleri derhal müşteriye iletir.
Bundan sonra montajı yapmanız gerekir. Birkaç aşamadan oluşur: arka uç ve ön uç montajı, test etme ve üretime teslimat.
3. Arka uç ve ön ucun montajı
Arka uç ve ön ucun oluşturulması GitLab Runner sisteminde gerçekleştirilen iki paralel görevdir. Orijinal montaj konfigürasyonu aynı depoda bulunur.
.
GitLab Runner, kodu gerekli depodan alır, Java application build komutuyla birleştirir ve Docker kayıt defterine gönderir. Burada arka uç ve ön ucu bir araya getiriyoruz, müşteri tarafındaki bir depoya koyduğumuz Docker görüntülerini alıyoruz. Docker görüntülerini yönetmek için kullandığımız .
İmajlarımızın sürümlerini Docker'da yayınlanacak yayın sürümüyle senkronize ediyoruz. Sorunsuz çalışma için çeşitli ayarlamalar yaptık:
1. Test ortamı ile üretim ortamı arasında konteynerler yeniden oluşturulmaz. Aynı konteynerin hem test ortamında hem de üretimde tüm ayarlarla, ortam değişkenleriyle ve hizmetlerle yeniden yapılandırmaya gerek kalmadan çalışabilmesi için parametrelendirmeler yaptık.
2. Bir uygulamayı Helm aracılığıyla güncellemek için sürümünü belirtmeniz gerekir. Arka ucu oluşturuyoruz, ön ucu oluşturuyoruz ve uygulamayı güncelliyoruz; bunlar üç farklı görevdir, dolayısıyla uygulamanın her yerde aynı sürümünü kullanmak önemlidir. K8S kümesi yapılandırmamız ve uygulamalarımız aynı Git deposunda olduğundan bu görev için Git geçmişindeki verileri kullanıyoruz.
Uygulama sürümünü komut yürütme sonuçlarından alıyoruz
git describe --tags --abbrev=7.
4. Tüm değişikliklerin test ortamına (UAT) otomatik olarak dağıtılması
Bu derleme komut dosyasındaki bir sonraki adım, K8S kümesini otomatik olarak güncellemektir. Bu, uygulamanın tamamının oluşturulmuş olması ve tüm yapıtların Docker Registry'de yayınlanması koşuluyla gerçekleşir. Bundan sonra test ortamı güncellemesi başlar.
Küme güncellemesi kullanılarak başlatıldı . Sonuç olarak bir şeyler planlandığı gibi gitmezse Helm, yapılan tüm değişiklikleri otomatik ve bağımsız olarak geri alacaktır. Yaptığı işin kontrol edilmesine gerek yoktur.
K8S küme konfigürasyonunu montajla birlikte sağlıyoruz. Bu nedenle bir sonraki adım onu güncellemektir: configMaps, dağıtımlar, hizmetler, sırlar ve değiştirdiğimiz diğer K8S yapılandırmaları.
Helm daha sonra test ortamında uygulamanın RollOut güncellemesini çalıştırır. Uygulama üretime dağıtılmadan önce. Bu, kullanıcıların test ortamına koyduğumuz iş özelliklerini manuel olarak test edebilmeleri için yapılır.
5. Tüm değişikliklerin Prod'a otomatik olarak dağıtılması
Üretim ortamına bir güncelleme dağıtmak için GitLab'da tek bir düğmeye tıklamanız yeterlidir; kapsayıcılar hemen üretim ortamına teslim edilir.
Aynı uygulama, yeniden oluşturma gerekmeden farklı ortamlarda (test ve üretim) çalışabilir. Uygulamada hiçbir şeyi değiştirmeden aynı yapıtları kullanıyoruz ve parametreleri dışarıdan ayarlıyoruz.
Uygulama ayarlarının esnek parametrelendirilmesi, uygulamanın yürütüleceği ortama bağlıdır. Tüm ortam ayarlarını harici olarak taşıdık: her şey K8S konfigürasyonu ve Helm parametreleri aracılığıyla parametrelendi. Helm bir montajı test ortamına dağıttığında, test ayarları ona, ürün ayarları da üretim ortamına uygulanır.
En zor şey, kullanılan tüm hizmetleri ve ortama bağlı değişkenleri parametreleştirmek ve bunları Helm için ortam değişkenlerine ve ortam parametrelerinin açıklama-yapılandırmalarına dönüştürmekti.
Uygulama ayarları ortam değişkenlerini kullanır. Değerleri, Go şablonları kullanılarak şablonlanan K8S yapılandırma haritası kullanılarak kaplarda ayarlanır. Örneğin, alan adına bir ortam değişkeni ayarlamak şu şekilde yapılabilir:
APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}
.Values.global.env – bu değişken ortamın adını saklar (prod, stage, UAT).
.Values.app.properties.app_external_domain – bu değişkende .Values.yaml dosyasında istenen etki alanını ayarladık
Bir uygulamayı güncellerken Helm, şablonlardan bir configmap.yaml dosyası oluşturur ve uygulama güncellemesinin başladığı ortama bağlı olarak APP_EXTERNAL_DOMAIN değerini istenen değerle doldurur. Bu değişken kapsayıcıda zaten ayarlanmıştır. Uygulamadan erişilebilir, dolayısıyla her uygulama ortamı bu değişken için farklı bir değere sahip olacaktır.
Nispeten yakın zamanda, Spring Cloud'da configMaps ile çalışma da dahil olmak üzere K8S desteği ortaya çıktı: . Proje aktif olarak gelişip kökten değişirken üretimde kullanamıyoruz. Ancak durumunu aktif olarak izliyoruz ve DEV konfigürasyonlarında kullanıyoruz. Stabil hale gelir gelmez ortam değişkenlerini kullanmaktan buna geçeceğiz.
Toplam
Böylece Sürekli Dağıtım yapılandırıldı ve çalışıyor. Tüm güncellemeler tek tuş vuruşuyla gerçekleşir. Değişikliklerin ürün ortamına iletilmesi otomatiktir. Ve daha da önemlisi güncellemeler sistemi durdurmaz.
Gelecek planları: otomatik veritabanı geçişi
Veritabanını yükseltmeyi ve bu değişiklikleri geri alma olasılığını düşündük. Sonuçta uygulamanın iki farklı sürümü aynı anda çalışıyor: eskisi çalışıyor ve yenisi çalışıyor. Ve eski sürümü ancak yeni sürümün çalıştığından emin olduğumuzda kapatacağız. Veritabanı geçişi, uygulamanın her iki sürümüyle de çalışmanıza izin vermelidir.
Bu nedenle sütun adını veya diğer verileri kolayca değiştiremeyiz. Ancak yeni bir sütun oluşturabilir, eski sütundaki verileri bu sütuna kopyalayabilir ve verileri güncellerken aynı anda onu başka bir sütuna kopyalayıp güncelleyecek tetikleyiciler yazabiliriz. Uygulamanın yeni sürümünün başarılı bir şekilde konuşlandırılmasının ardından, lansman sonrası destek döneminden sonra, eski sütunu ve gereksiz hale gelen tetikleyiciyi silebileceğiz.
Uygulamanın yeni sürümü düzgün çalışmazsa veritabanının önceki sürümü de dahil olmak üzere önceki sürüme geri dönebiliriz. Kısacası değişikliklerimiz uygulamanın birkaç sürümüyle aynı anda çalışmanıza olanak tanıyacak.
Veritabanı geçişini K8S işi aracılığıyla CD sürecine entegre ederek otomatikleştirmeyi planlıyoruz. Ve bu deneyimi Habré'de mutlaka paylaşacağız.
Kaynak: habr.com