Birden çok ön uç sunucuya kod dağıtma

Ortak bir veritabanına işaret eden birden fazla yük dengeli sunucumuz olduğu bir durum var.

İşlerin normal çalışmasında bu iyi çalışır ve fazlalık, ölçeklenebilirlik vb.

Ancak konuşlandırmayı biraz angarya olarak görüyoruz.

Özellikleri yoğun bir şekilde kullanıyoruz ve dağıtımı otomatikleştirmeye çalışıyoruz. Şu anda dağıtım çok güvenilir değil.

Basitleştirilmiş bir formda, her sunucu için konuşlandırma komut dosyasının iki aşaması vardır

1. Dosyaları Güncelle

2. Özellikleri Geri Döndür (bağımlılıkları, ayar değişikliklerini vb. Yönetecek)

Birden fazla sunucuda tutarsız olmalarına neden olmadan dağıtmak için en iyi uygulamalar var mı?

Adım 1 ve 2'yi sunucu A'ya dağıtıp dağıtmadığınızı görebildiğimde, sunucu B'nin bozulmasına neden olur, adım 2'ye geçmeden önce her iki sunucuda da birinci adımı denerseniz, her ikisi de bir süre kırılır.

Muhtemelen en esnek ve en güçlü Drupal site yönetimi / dağıtım sistemi olan Aegir'e bakmalısınız . Acros çoklu web kafalarını veya 'kümeleri' kapsayan 'platformları' ve çeşitli diğer yapılandırmaları yönetebilir.

Onların arasında aracılığıyla okuma sahip öneririm topluluk belgelerine genellikle oldukça iyidir, hem de okuyarak mig5 mükemmel bakış ve tanıtım makale ve benzeri onun diğer bazı makaleler bu bir .

#Aegir IRC kanalında da iyi destek alabilirsiniz.

Biraz iş akışı değişikliği olacak, bu da kafanızı almak için biraz zaman alabilir, ancak bir kez orada olduğunuzda geriye bakmayacaksınız.

Şirketimizde çok sayıda Drupal sitesi bulunduruyoruz, mevcut kurulumumuz şuna benzer:

• Her sitenin kod tabanının kendi git repo'su vardır
• Bir sonraki sürüm için yeterince kararlı olması muhtemel olmayan yeni özellikler git'te kendi özellik dallarını edinin

Yukarıda söyleyebilirim çoğu Drupal siteleri için oldukça yaygındır.

Şirketimizde özel olarak yaptığımız şey, özel bir drush komutu olan ' Drush Debian Packaging ' kullanarak dağıtım alanlarını debian paketidir .

Drush Debian Packaging, Drupal sitelerini Debian veya Ubuntu sunucularına dağıtmanın bir yolu olarak Drupal sitelerinin Debian paketlerini oluşturmak için bir Drush komutu sağlar.

Drush Debian Packaging, sitelerinizin ihtiyaçlarına en uygun Debian paketini oluşturmak için Drupal kanca sistemini kullanır. Özellikler:

• Apache2 ve Nginx web sunucuları için otomatik sanal ana bilgisayar yapılandırması
• /Etc/cron.d içinde cron kurulumu
• Siteler / varsayılan / dosyalar için bölüm bölünmüş otomatik kod dağıtımı
• Dpkg debconf ayarları aracı ile otomatik yapılandırma
• Otomatik dağıtım işlemi
• 'dan paket oluşturmak için özel Git VCS işleyicisi

Ne anlama geliyor?

Bir sürüm oluşturmak için:

cd /path/to/drupal-root
drush dh-make

Bir sürümü dağıtmak için önce .deb dosyasını kümedeki tüm web sunucularına SCP yapın. Sonra tüm web sunucularında çalıştırın ( komutu aynı anda gruptaki tüm sunuculara yazmak için linux cssh paketini kullanabilirsiniz ):

sudo dpkg -i drupal-site-yoursitehere.2011.05.25-1.all.deb

Bir web sunucusunda:

cd /path/to/drupal-root
sudo -u drupal-site-yoursitehere drush updb && drush fra -y && drush cron

Bitti

Tabii ki bu geri almak artık bir kod tabanı bakış açısından önemsiz, sadece .deb'nin önceki sürümünü tüm web sunucularına yükleyin ve veritabanını geri alın.

Bununla ilgili sorularınızı cevaplamaktan mutluluk duyarız

Dağıtım sürecinin hangi kısmı angarya / güvenilmezdir?

"Güncelleme sunucusu A sonra B / tutarsızlık" sorunu ise, itme süresi boyunca bakım sayfasını hazırlamaya ne dersiniz? Bakım sayfası yukarı, her iki web başlığında da güncelleme kodu, bunlardan birinde update.php çalıştırın , bakım sayfası aşağı. Bu oldukça kolay yazılabilir.

Başka bir seçenek: çalıştırdığınız sitenin türüne bağlı olarak, tüm kullanıcıları çevrimdışı yapan ve giriş / kayıt özelliğini devre dışı bırakan bir "salt okunur mod" oluşturabilirsiniz. DB'nizi aynı db kutusundaki ikinci bir DB'ye kopyalayın, ön ucunuzu yeni bir docroot'a kopyalayın, güncellemelerinizi orada yapın, ardından Apache'nin docroot'unu yeni ön uç docroot'a ekleyin. İş akışı şuna benzer:

1. Salt okunur mod açık
2. Current_db INTO Instagram Hesabındaki Resim ve Videoları new_db
3. cp -R current_docroot Instagram Hesabındaki Resim ve Videoları new_docroot
4. new.yourdomain.com ==> / new_docroot
5. kodu new_docroot'a güncelleyin
6. update.php
7. symlink / new_docroot ==> current_docroot
8. Salt okunur mod kapalı.

Entendu'nun önerdiği gibi, yaptığınız değişikliklere bağlı olacaktır. Veritabanı henüz güncellenmemişse, hata güncellemelerinin ne kadarı hataya neden olmadan çalıştırılabilir? Veritabanı güncellemelerine bağımlı olmayan herhangi bir şey için (ve belki de bunu daha yaygın hale getirmek için geliştirme sürecini biraz değiştirebilirsiniz) gerçekten özel bir şey yoktur. En az kesinti süresi olan dağıtımlar yapmak istediğinizi varsayalım, aksi takdirde bu sadece bazı temel senkronizasyon işlemlerini gerektirir. Bu durumda her zaman istenmeyen etkileri olan bir zaman penceresi olacaktır (sadece siteyi salt okunur modda olsa bile), ancak çoğu zaman oldukça küçük olabileceğini düşünürdüm.

Önceden her sunucuda "yeni" bir dizin oluşturmak ve daha sonra bunları aynı anda yeni dizine yönlendirmek (belki de Entendu'nun cevabı gibi semboller kullanarak) gibi temel optimizasyon yapabilirsiniz. sunucular 5-10 saniye içinde yeni dosyalara geçti.

Bu veritabanı güncellemeleri sorununu bırakır. Yalnızca bir sunucudan yapılması gereken türdeyse, diğerlerini bakım moduna geçirmek veya yük dengeleyiciyi bu durumdayken kullanmamaları için ayarlamak isteyebilirsiniz. Tabii ki kullanıcılar sitede etkinken yapılamazsa, bakım modunda her şeye sahip olmanız gerekir, ancak basit güncellemeler için bu yaklaşık 30 saniye veya daha kısa sürede yapabileceğiniz bir şey olabilir.

Farklı türdeki değişiklikler için farklı dağıtım komut dosyalarına sahip olmaya değer olabilir, bu nedenle yalnızca dosyaları kopyalamak, küçük bir veritabanı güncellemesi yapmak veya büyük bir veritabanı değişikliği yapmak için gereken minimum işlemi çalıştırabilirsiniz.

Dosya ve veritabanı güncellemelerinizi optimize edebilir ve işlerin geliştirilme biçiminde yapabileceğiniz basit değişiklikler olup olmadığına bakarsanız, bu sizi daha da yaklaştırabilir, ancak bunların herhangi birinin sizin için yeni olup olmadığını bilmiyorum :)

Aegir bir site ağını yönetmekte faydalıdır. Tek bir istemci için 2000'den fazla siteyi dağıtmak ve yönetmek için kullandım.

Sorunuz, birden çok web başlığına sahip tek bir siteyi yönetmek istediğinizi gösteriyor. Bu durumda Aegir sizin için daha az yararlı olabilir. Bunun yerine ağ oluşturmayı destekleyen bir dosya sistemi kullanmanızı öneririm. Bu sadece kodunuzun senkronize olmasını sağlamakla kalmaz, aynı zamanda yüklemelerinizin tüm düğümlerde kullanılabilir olduğu anlamına gelir.

Tarihsel olarak insanlar bir sunucunun dosya sisteminin diğer düğümlerle paylaşılmasına izin veren NFS kullanmışlardır. Ne yazık ki bu tek bir hata noktası getiriyor, çünkü NFS sunucusu kilitlenir veya ölürse sitenize hizmet verilemez.

Daha güvenilir bir sunucu lehine biraz performanstan ödün vermek istiyorsanız, GlusterFS'yi tavsiye ederim . Birkaç üretim ortamında kullandım. Mükemmel değil ama NFS'den daha iyi. Gluster, webhead'in her zaman yerel olarak okumasına izin verir ve daha sonra yazma işlemleri diğer düğümlere çoğaltılır.

Dağıtım stratejiniz açısından, listenizdeki ilk araç olarak acele edin. Drush ile dağıtım adımlarınızı otomatikleştirebilmelisiniz. Dağıtım işlerinizi takip edebilmeniz ve bir şeyler başarısız olursa kalıpları belirleyebilmeniz için karışıma Jenkins eklemeyi düşünmelisiniz. Capistrano, konuşlandırmayla ilgili adımları otomatikleştirmek için yararlı olabilir. İşleri düzgün bir şekilde yaparsanız, kullanıcılarınızın bir dağıtım yaptığınızı asla bilmedikleri şekilde yapabilirsiniz.