Sysadminka sistem yöneticisi buluşmaları Chelyabinsk'te yapılıyor ve son toplantıda Kubernetes'te 1C-Bitrix üzerinde uygulama çalıştırma çözümümüz hakkında bir rapor verdim.
Bitrix, Kubernetes, Ceph - harika bir karışım mı?
Size tüm bunlardan işe yarar bir çözümü nasıl bir araya getirdiğimizi anlatacağım.
Hadi gidelim!
Buluşma 18 Nisan'da Çelyabinsk'te gerçekleşti. Buluşmalarımızı şuradan okuyabilirsiniz: ve bak .
Bize bir raporla veya dinleyici olarak gelmek istiyorsanız - hoş geldiniz, bize yazın. [e-posta korumalı] ve Telegram t.me/vadimisakanov'da.
Benim raporum
Çözüm "Kubernetes'te Bitrix, Güney Köprüsü 1.0 sürümü"
Çözümümüzü buluşmada olduğu gibi “Kubernetes'teki aptallar için” formatında anlatacağım. Ancak Bitrix, Docker, Kubernetes, Ceph kelimelerini en azından Vikipedi'deki makaleler düzeyinde bildiğinizi varsayıyorum.
Kubernetes'te Bitrix'in hazır özellikleri nelerdir?
Bitrix uygulamalarının Kubernetes'te çalışması hakkında tüm internette çok az bilgi var.
Sadece şu malzemeleri buldum:
Qsoft'tan Alexander Serbul, 1C-Bitrix ve Anton Tuzlukov'un raporu:
Dinlemeni tavsiye ederim.
Kullanıcıdan kendi çözümünüzü geliştirme .
Daha fazlasını buldum .
Vee... aslında hepsi bu.
Sizi uyarıyorum, yukarıdaki bağlantılardaki çözümlerin kalitesini kontrol etmedik :)
Bu arada çözümümüzü hazırlarken Alexander Serbul ile konuştum, o zaman raporu henüz çıkmamıştı, dolayısıyla slaytlarımda “Bitrix Kubernetes kullanmıyor” maddesi var.
Ancak Bitrix'i Docker'da çalıştırmak için zaten çok sayıda hazır Docker görüntüsü var:
Bu, Kubernetes'te Bitrix için eksiksiz bir çözüm oluşturmak için yeterli mi?
HAYIR. Çözülmesi gereken çok sayıda sorun var.
Kubernetes'te Bitrix'in sorunları nelerdir?
Öncelikle Dockerhub'dan alınan hazır görseller Kubernetes'e uygun değil
Bir mikro hizmet mimarisi oluşturmak istiyorsak (ki genellikle Kubernetes'te bunu yaparız), Kubernetes uygulamamızı konteynerlere ayırmamız ve her konteynerin küçük bir işlevi yerine getirmesini sağlamamız (ve bunu iyi bir şekilde yapması) gerekir. Neden sadece bir tane? Kısacası ne kadar basitse o kadar güvenilirdir.
Daha spesifik olmak gerekirse, bu makaleyi ve videoyu izleyin, lütfen:
Dockerhub'daki Docker görüntüleri temel olarak hepsi bir arada prensibine dayanıyordu, bu yüzden yine de kendi bisikletimizi yapmamız ve hatta sıfırdan görüntüler oluşturmamız gerekiyordu.
İkincisi - site kodu yönetici panelinden düzenlenir
Sitede yeni bir bölüm oluşturduk - kod güncellendi (yeni bölümün adını taşıyan bir dizin eklendi).
Bir bileşenin özelliklerini yönetici panelinden değiştirdiyseniz kod değişti.
Kubernetes "varsayılan olarak" bununla çalışamaz; konteynerlerin durum bilgisi olmayan olması gerekir.
Sebep: Kümedeki her kapsayıcı (pod) trafiğin yalnızca bir kısmını işler. Kodu yalnızca bir kapta (kapsülde) değiştirirseniz, kod farklı bölmelerde farklı olacak, site farklı çalışacak ve sitenin farklı sürümleri farklı kullanıcılara gösterilecektir. Böyle yaşayamazsın.
Üçüncüsü - sorunu dağıtımla çözmeniz gerekiyor
Monolit ve bir "klasik" sunucumuz varsa, her şey oldukça basittir: yeni bir kod tabanı dağıtırız, veritabanını taşırız, trafiği kodun yeni sürümüne geçiririz. Anahtarlama anında gerçekleşir.
Kubernetes'te mikro hizmetlere ayrılmış bir sitemiz varsa, kodlu çok sayıda kapsayıcı vardır - oh. Kodun yeni bir sürümünü içeren kapları toplamanız, eskileri yerine bunları dağıtmanız, veritabanını doğru şekilde taşımanız ve ideal olarak bunu ziyaretçiler tarafından fark edilmeden yapmanız gerekir. Neyse ki Kubernetes, birçok farklı dağıtım türünü destekleyerek bize bu konuda yardımcı oluyor.
Dördüncüsü - statiği saklama sorununu çözmeniz gerekiyor
Siteniz "yalnızca" 10 gigabayt ise ve onu tamamen kapsayıcılara dağıtırsanız, dağıtılması sonsuza dek süren 10 gigabaytlık kapsayıcıya sahip olursunuz.
Sitenin "en ağır" kısımlarını konteynerlerin dışında saklamanız gerekiyor ve bunun nasıl doğru şekilde yapılacağı sorusu ortaya çıkıyor
Çözümümüzde eksik olan ne?
Bitrix kodunun tamamı mikro işlevlere/mikro hizmetlere bölünmez (böylece kayıt ayrıdır, çevrimiçi mağaza modülü ayrıdır vb.). Kod tabanının tamamını her kapta saklıyoruz.
Veritabanını Kubernetes'te de saklamıyoruz (Geliştirme ortamları için hala Kubernetes'te veritabanı içeren çözümler uyguladım, ancak üretim için değil).
Sitenin Kubernetes üzerinde çalıştığı site yöneticileri tarafından hala fark edilecektir. “Sistem kontrolü” fonksiyonu doğru çalışmıyor, admin panelinden site kodunu düzenlemek için öncelikle “Kodu düzenlemek istiyorum” butonuna tıklamanız gerekmektedir.
Sorunlar belirlendi, mikro hizmetlerin uygulama ihtiyacı belirlendi, amaç açık - Bitrix'teki uygulamaları Kubernetes'te çalıştırmak için hem Bitrix'in yeteneklerini hem de Kubernetes'in avantajlarını koruyan bir çalışma sistemi elde etmek. Uygulamaya başlayalım.
Mimari
Bir web sunucusuna (işçilere) sahip birçok "çalışan" bölme vardır.
Cron görevleri olan bir alt (yalnızca bir tanesi gereklidir).
Site kodunu yönetici panelinden düzenlemek için bir yükseltme (ayrıca yalnızca bir tane gereklidir).
Soruları çözüyoruz:
- Oturumlar nerede depolanır?
- Önbellek nerede saklanmalı?
- Gigabaytlarca statiği bir grup konteynere yerleştirmek yerine statik nerede saklanmalı?
- Veritabanı nasıl çalışacak?
Docker görüntüsü
Bir Docker imajı oluşturarak başlıyoruz.
İdeal seçenek, tek bir evrensel imaja sahip olmamızdır; buna dayanarak işçi bölmeleri, Crontasks'lı bölmeler ve yükseltme bölmeleri elde ederiz.
.
Nginx, Apache/php-fpm (derleme sırasında seçilebilir), posta göndermek için msmtp ve cron içerir.
Görüntüyü birleştirirken, sitenin kod tabanının tamamı /app dizinine kopyalanır (ayrı bir paylaşılan depolama alanına taşıyacağımız parçalar hariç).
Mikro hizmetler, hizmetler
işçi bölmeleri:
- Nginx + konteyner apache/php-fpm + msmtp içeren konteyner
- Msmtp'yi ayrı bir mikro hizmete taşımak işe yaramadı, Bitrix doğrudan posta gönderemediği için kızmaya başlıyor
- Her konteynerin eksiksiz bir kod tabanı vardır.
- Kaplarda kod değiştirme yasağı.
cron altında:
- apache, php, cron içeren kapsayıcı
- tam kod tabanı dahildir
- kaplarda kod değiştirme yasağı
altında yükseltme:
- nginx kapsayıcısı + apache/php-fpm kapsayıcısı + msmtp
- Konteynerlerde kod değiştirme yasağı yoktur
oturum depolama
Bitrix önbellek depolama
Bir diğer önemli şey: Veritabanından postaya kadar her şeye bağlanmak için gereken şifreleri kubernetes sırlarında saklıyoruz. Bir bonusumuz var: Şifreler yalnızca sırlara erişim verdiğimiz kişiler tarafından görülebilir, projenin kod tabanına erişimi olan herkes tarafından görülemez.
Statik için depolama
Her şeyi kullanabilirsiniz: ceph, nfs (ancak üretim için nfs'yi önermiyoruz), bulut sağlayıcılardan ağ depolama vb.
Depolamanın, konteynerler halinde sitenin /upload/ dizinine ve statik içeriğe sahip diğer dizinlere bağlanması gerekecektir.
veritabanı
Basit olması açısından veritabanını Kubernetes'in dışına taşımanızı öneririz. Kubernetes'teki temel ayrı bir karmaşık görevdir; şemayı daha da karmaşık hale getirecektir.
Oturum depolama
Memcached kullanıyoruz :)
Oturum depolamayı iyi yönetir, kümelenir ve php'de session.save_path olarak "yerel olarak" desteklenir. Böyle bir sistem, çok sayıda web sunucusuna sahip kümeler oluşturduğumuz klasik monolitik mimaride birçok kez test edilmiştir. Dağıtım için dümen kullanıyoruz.
$ helm install stable/memcached --name sessionphp.ini - burada görüntü, oturumları memcached'de depolamaya yönelik ayarları içerir
Memcached'li ana bilgisayarlar hakkındaki verileri iletmek için Ortam Değişkenlerini kullandık .
Bu, geliştirme, aşama, test, üretim ortamlarında aynı kodu kullanmanıza olanak tanır (içlerindeki memcached ana bilgisayar adları farklı olacaktır, dolayısıyla her ortama oturumlar için benzersiz bir ana bilgisayar adı aktarmamız gerekir).
Bitrix önbellek depolama
Tüm bölmelerin yazıp okuyabileceği, hataya dayanıklı depolamaya ihtiyacımız var.
Ayrıca memcached kullanıyoruz.
Bu çözüm Bitrix'in kendisi tarafından önerilmektedir.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - burada Bitrix'te önbelleğin nerede depolandığı belirtilir
Ayrıca Ortam Değişkenlerini de kullanıyoruz.
Krontaski
Kubernetes'te Crontasks'ı çalıştırmanın farklı yaklaşımları vardır.
- Crontasks'ı çalıştırmak için bir bölmeyle ayrı dağıtım
- crontasks'ı yürütmek için cronjob (eğer bu bir web uygulamasıysa - wget ile) veya çalışan bölmelerinden birinin içindeki kubectl exec vb.)
- vb.
En doğrusunu tartışabilirsiniz ancak bu durumda “Crontasks için pod'larla ayrı dağıtım” seçeneğini seçtik.
Nasıl yapılır:
- ConfigMap veya config/addcron dosyası aracılığıyla cron görevleri ekleyin
- bir örnekte, işçi poduyla aynı olan bir konteyneri başlatıyoruz + içindeki taç görevlerinin yürütülmesine izin veriyoruz
- aynı kod tabanı kullanılır, birleştirme sayesinde konteyner montajı basittir
Ne fayda elde ediyoruz:
- geliştiricilerin ortamına (docker) benzer bir ortamda çalışan Crontasks'ımız var
- Crontask'ların Kubernetes için "yeniden yazılmasına" gerek yoktur, daha önce olduğu gibi aynı biçimde ve aynı kod tabanında çalışırlar
- cron görevleri yalnızca yöneticiler tarafından değil, üretim şubesine taahhüt haklarına sahip tüm ekip üyeleri tarafından eklenebilir
Southbridge K8SDeploy modülü ve yönetici panelinden kod düzenleme
Altında yükseltmeden mi bahsediyorduk?
Oraya trafik nasıl yönlendirilir?
Yaşasın, bunun için PHP'de bir modül yazdık :) Bu, Bitrix için küçük, klasik bir modül. Henüz halka açık değil ama açmayı planlıyoruz.
Modül, Bitrix'te normal bir modül gibi kurulur:
Ve şuna benziyor:
Site yöneticisini tanımlayan ve Kubernetes'in yükseltme bölmesine trafik göndermesine olanak tanıyan bir çerez ayarlamanıza olanak tanır.
Değişiklikler tamamlandığında, git Push'a tıklamanız gerekir; kod değişiklikleri git'e gönderilir, ardından sistem, kodun yeni bir sürümünü içeren bir görüntü oluşturacak ve eski bölmeleri değiştirerek bunu küme genelinde "yayacaktır" .
Evet, bu biraz zahmetli ama aynı zamanda mikro hizmet mimarisini koruyoruz ve Bitrix kullanıcılarının en sevdikleri, yönetici panelinden kodu düzeltme fırsatını elinden almıyoruz. Sonuçta bu bir seçenek; kodu düzenleme problemini farklı bir şekilde çözebilirsiniz.
Dümen tablosu
Kubernetes'te uygulamalar oluşturmak için genellikle Helm paket yöneticisini kullanırız.
Kubernetes'teki Bitrix çözümümüz için lider sistem yöneticimiz Sergey Bondarev özel bir Helm şeması yazdı.
Çalışan, yükseltme, cron bölmeleri oluşturur, girişleri, hizmetleri yapılandırır ve değişkenleri Kubernetes gizli dizilerinden bölmelere aktarır.
Kodu Gitlab'da saklıyoruz ve ayrıca Helm yapısını Gitlab'dan çalıştırıyoruz.
Kısaca şöyle görünüyor
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm ayrıca dağıtım sırasında aniden bir şeyler ters giderse "kesintisiz" bir geri alma işlemi yapmanıza da olanak tanır. "Ürün düştüğü için kodu ftp yoluyla düzeltin" diye panik yapmamanız güzel, ancak Kubernetes bunu otomatik olarak ve kesinti olmadan yapıyor.
Dağıtmak
Evet Gitlab & Gitlab CI hayranıyız, kullanıyoruz :)
Gitlab'da proje deposuna taahhütte bulunulduğunda Gitlab, ortamın yeni bir sürümünü dağıtan bir işlem hattı başlatır.
Adımlar:
- derleme (yeni bir Docker görüntüsü oluşturma)
- test (test)
- temizleme (test ortamını kaldırma)
- push (Docker kayıt defterine gönderiyoruz)
- dağıtma (uygulamayı Helm aracılığıyla Kubernetes'e dağıtıyoruz).
Yaşasın, hazır, hadi uygulayalım!
Peki, ya da varsa sorular sorun.
Peki ne yaptık
Teknik açıdan bakıldığında:
- docker'a dönüştürülmüş Bitrix;
- Bitrix'i her biri minimum işlevi yerine getiren kaplara "kesin";
- konteynerlerin vatansız durumuna ulaşıldı;
- Kubernetes'te Bitrix'in güncellenmesiyle ilgili sorunu çözdü;
- tüm Bitrix fonksiyonları çalışmaya devam etti (hemen hemen hepsi);
- Kubernetes'e dağıtım ve sürümler arasında geri alma üzerinde çalıştık.
İş açısından bakıldığında:
- hata toleransı;
- Kubernetes araçları (Gitlab CI ile kolay entegrasyon, sorunsuz dağıtım vb.);
- gizli şifreler (yalnızca şifrelere doğrudan erişim izni verilen kişiler tarafından görülebilir);
- Tek bir altyapı içerisinde ek ortamlar (geliştirme, testler vb. için) oluşturmak uygundur.
Kaynak: habr.com