Canlı yeni kod dağıtımı

Yeni bir kodu canlı (e-ticaret) sitesinde dağıtmak için en iyi uygulama nedir?

Dizini yeniden adlandırılırken Şimdilik ben +/- 10 saniye boyunca apache durmuş public_html_newetmek public_htmlve eski public_html_old. Apache'yi yeniden başlatmadan önce bu, kısa bir zaman kaybı yaratır.

Yeni repoyu canlı dizine çekmek için Git'i kullanıyorsanız aynı soru geçerlidir. Site aktifken repoyu çekebilir miyim? Peki ya bir DB'yi kopyalamam gerekirse?

Canlı sitenin tar (yedekleme amacı) sıkıştırması sırasında değişikliklerin medya dizininde gerçekleştiğini fark ettim. Bu bana dosyaları düzenli aralıklarla değişmeye devam ettiğini gösterdi. Ve eğer bu değişiklikler Apache'nin konuşlandırma sırasında durdurulmamasına engel olabilirse.

Yük dengeleyici kullanmak iyi bir fikirdir. Eğer site birkaç saniye kapalı kalma süresi için endişe edecek kadar önemliyse, hata toleransı için endişe edecek kadar önemlidir.

Bu bir yana, eğer bu bir UNIX sistemindeyse, Apache'yi yeniden adlandırma (veya sembolik bağlantı güncellemesi, vb.) Sırasında beklemeye alabilirsiniz.

killall -STOP httpd  # Pause all httpd processes
mv public_html public_html_orig
mv public_html_new public_html
killall -CONT httpd  # Resume all httpd processes

Bu, Apache'nin yeniden adlandırma sırasında yeni istekleri kabul etmesini önleyecektir. Eğer linkleri veya başka bir yaklaşımı tercih ederseniz, aynı fikir kullanılabilir:

killall -STOP httpd  # Pause all httpd processes
rm /var/www/html
ln -s /var/www/version/03 /var/www/html
killall -CONT httpd  # Resume all httpd processes

Bekleyen bağlantıların veya paketlerin işletim sisteminde sıraya gireceğini unutmayın. Çok yoğun bir site için httpd çalışan türünüze uygunsa ListenBacklog ayarını düşünün ve TCP dinleme iş listesi ile ilgili işletim sistemi ayarlarınızı kontrol edin.

DocumentRoot'u httpd.conf'ta da değiştirebilir ve zarif bir restart ( apachectl graceful) yapabilirsiniz. Buradaki dezavantaj, herhangi bir Directoryyapılandırmayı da güncellemeniz gerekeceğinden, artan hata riskidir .

En hızlı ve en kolay, gibi bir sürüm dizini kullanmaktır.

/var/www/version/01
/var/www/version/02

ve html_root'unuz olarak güncel bir sembolik bağlantı kullanın:

/var/www/html -> /var/www/version/02

Bu teknik , dalları ve etiketleri kontrol edebileceğiniz, sembolik bağı değiştirdiği ve Apache'yi yeniden yükleyebileceğiniz gibi, revizyon kontrol sistemine (svn, git, mercurial, ...) mükemmel şekilde entegre olur . Kesintinin en alt düzeyde bu teknik kullanılarak ve onu tanır çok kolay geri alma .

Ayrıca, RPM paketleri veya yapılandırma değişikliği yönetimi (şef, kukla vb.) Altyapısı gibi daha karmaşık dağıtım sistemiyle iyi bir şekilde bütünleşir.

Dizinleri Apache'yi kapatmadan yeniden adlandırmak da işe yaramalı. Bu, pencereyi önemli ölçüde kısaltacaktır. mv public_html public_html_old && mv public_html_new public_htmlbir saniyenin kesriyle bitmelidir.

Birkaç dezavantajı, bu yaklaşımın 404pencerede gerçekleşmeyi başaran herhangi bir talebi yerine getirmesidir. Ve eğer yukarıdaki komutu bir public_html_newdizine sahip olmadan çalıştırırsanız, başarısız olur ve sizi 404her istekte bulunan bir siteyle birlikte bırakır .

Dizinler ile atomik olarak yapmak desteklemiyor. Ama semboliklerle yapabilirsin. Bunun yerine adlı bir dizin sahip public_html, adlı bir dizin var public_html.version-numberve adında bir sembolik public_htmlbu dizine işaret. Şimdi adı verilen bir dizin public_html.new-version-numberve adı verilen yeni bir sembolik bağlantı oluşturabilirsiniz public_html.new.

Sonra atomik geçiş public_html.newyapmak public_htmliçin yeniden adlandırabilirsiniz . mvBu yeniden adlandırmayı gerçekleştirmek için "çok akıllı" olduğuna dikkat edin , ancak os.renamepython veya renamesistem çağrısı yapmayı akıllı olmaya çalışmadan başka bir şey kullanarak yapılabilir .

Veri tabanıyla ne yapılması, hangi veritabanını kullandığınıza ve ne için kullandığınıza bağlıdır. Sorunuzun bu bölümüne size iyi bir cevap verebilmemiz için önce veritabanı hakkında daha fazla ayrıntı vermeniz gerekir.

Symlinks ve mv arkadaşınızdır, ancak yeni bir sürümü dağıtırken son kullanıcıların bir hata sayfası almaktan kaçınmanız gerekiyorsa, en az 2 arka uç sunucusunun önünde bir ters proxy veya bir yük dengeleyici bulundurmalısınız (apache) Senin durumunda).

Dağıtım sırasında, bir seferde bir arka ucu durdurmanız, yeni kodu dağıtmanız, yeniden başlatmanız ve ardından kalan arka uçları yinelemeniz yeterlidir.

Son kullanıcılar her zaman vekil tarafından iyi arka uçlara yönlendirilecektir.

Bir üretim sisteminde düzenli olarak değişiklikler uyguluyorsanız, yapısal bir yaşam döngüsüyle ben ilgilenirim. İyi bir uygulama Capistrano http://capistranorb.com/ . Bu, yazılımı birkaç platformda ve yapılandırmada bir veya daha fazla sunucuya dağıtmak için açık kaynaklı bir çözümdür.

Magento için bir eklenti bile var: https://github.com/augustash/capistrano-ash/wiki/Magento-Example

Tek sunucu ve neredeyse kesintisiz geçişler için, sembolik bağlantılar kullanmanızı öneririz.

Bunu yapmak, yerel dev ortamımdan Github gibi bir çevrimiçi Git deposuna değişikliklerimi yapmak. Üretim ortamım uzak bir havuzda çalışıyor, bu yüzden tek yapmam gereken sunucuya ssh koymak ve git pullen son değişiklikleri getirmek için çalışıyor. Web sunucunuzu durdurmanıza gerek yok.

Projenizde ayarları ve / veya içeriği yerel sürümünüzden farklı olan dosyalarınız (yapılandırma dosyaları ve medya yüklemeleri gibi) varsa, ortam değişkenlerini kullanabilir ve / veya .gitignoredepo ile senkronizasyonu önlemek için bu dosyaları / dizinleri bir dosyaya ekleyebilirsiniz .

Benim ilk fikrim:

# deploy into public_html_new, and then:
rsync -vaH --delete public_html_new/ public_html/

İyi bir çözüm rsync kullanmaktı. Sadece gerçekten değiştirilen dosyaları değiştirdi. Dikkat edin, yolun sonundaki eğik çizgiler yolların burada önemli olduğunu unutmayın.

Normalde apache'nin yeniden başlatılması gerekmez, java dünyası değildir. İstek üzerine her php dosyasının değişimini kontrol eder ve değişimin üzerine otomatik olarak yeniden okur (ve yeniden belirtir).

Git çekme benzer verimli, ancak komut dosyası biraz zor olsa da. Tabii ki, farklı birleşme / değişim tespit olanakları geniş yelpazesinde olanak sağlamıştır.

Bu çözüm sorunsuz bir şekilde ancak gerçekten büyük değişiklikler olmazsa - dağıtımda büyük değişiklikler varsa, kodun kısmen değiştirileceği zaman ihmal edilemez bir zaman aralığı olmadığından, bir miktar tehlike kapatılamaz ve kısmen değil.

Büyük değişiklikler varsa, önerim ilk çözümünüzdü (iki yeniden adlandırma).

İşte biraz sert ama% 100 atomik çözüm:

(1) magento'nuzun gerçekleştiği bazı dosya sisteminizi, alternatif bir montaj yapın:

mount /dev/sdXY /mnt/tmp

(2) --bindpublic_html_new ile public_html arasında bir bağlantı yapın:

mount --bind /path/to/public_html_new /path/to/public_html

Bu noktadan itibaren, apache yeni dağıtımınızı görecektir. 404'te herhangi bir değişiklik yapılması mümkün değildir.

(3) senkronizasyonu rsync ile fakat alternatif bağlama noktasında yapın):

rsync -vaH --delete /mnt/tmp/path/to/public_html_new/ /mnt/tmp/path/to/public_html/

(4) bağlama düzeneğini çıkarın

umount /path/to/public_html

Http sunucunuz çalışmaya devam ederken , http_publicklasörün değiştirilmesi / değiştirilmesi basit mvveya ln -skomutlar veya eşdeğeri ile sağlanabilir . Arıza süresini önemli ölçüde azaltmak için bazı komut dosyaları kullanabilirsiniz, ancak işlemi otomatik hale getirirseniz komut dosyalarınızın komut kodlarını dikkatlice kontrol edin.

Bu, hiçbir kesinti elde etmek istemiyorsanız, uygulamanın da desteklemesi gerektiğini söyledi. Çoğu uygulama kalıcılık için bir veritabanı kullanır. Uygulamanızın N sürümünün, veri modelinizin N + 1 (veya tersi) ile karıştırılması, geliştirme ekibi tarafından öngörülmediği takdirde işleri bozabilir.

Tecrübelerden, yükseltme işlemlerinde böyle bir tutarlılığın sağlanması çoğu uygulama için verilmez. Arıza süresine rağmen uygun bir kapanma, tutarlılık sorunlarından kaçınmak için iyi bir yoldur.