Bu bir PHP uygulaması. Kod kodunun tamamını güncellerken duruş süresini nasıl en aza indirebilirim?
Bu bir PHP uygulaması. Kod kodunun tamamını güncellerken duruş süresini nasıl en aza indirebilirim?
Yanıtlar:
Genelde ne yapıyoruz, işte:
/www/app-2009-09-01/www/application/www/app-2009-09-08/www/applicationfakat yeni kaynaklara işaret eden yeni bir sembolik link oluşturuyoruz :/www/app-2009-09-08Tüm bu işlemler otomatik bir komut dosyası ile yapılır (otomatik olmayan tek şey, gerektiğinde başlatmamızdır). Bunun anlamı :
Bu sembolik bağlantı önceliğinin bir başka avantajı, yalnızca kaynakların yeni versiyonunu üretime koyduktan sonra felaket bir hata olduğunu fark edersek bir güncellemeyi "geri almanın" çok kolay olmasıdır: sadece sembolik bağları geri çevirmemiz gerekir.
Tabii ki bu, prodüksiyona koymadan önce evreleme sunucunuzdaki yeni sürümü test etmenizi engellemez - ama kim bilir ... Bazen kimsenin göremediği çok büyük bir hata olabilir. sınama :-(
Örneğin, hazırlama makinesinde düzenli olarak yapılan bir yükleme testi olmadığından.
("geri alma" olayının 3 yılda 4 veya 5 kez gibi bir şey kullandığını gördüm - her seferinde, günü kurtardım - ve web siteleri ^^)
İşte size bir tür hızlı örnek: Apache yapılandırmamda bu VirtualHost'a sahip olduğumu varsayalım:
<VirtualHost *>
ServerName example.com
DocumentRoot /www/application
<Directory /www/application>
# Whatever you might need here (this example is copy-pasted from a test server and test application ^^ )
Options Indexes FollowSymLinks MultiViews +SymLinksIfOwnerMatch
AllowOverride All
php_value error_reporting 6135
php_value short_open_tag on
</Directory>
</VirtualHost>
Oldukça "standart" ... Tek şey /www/applicationgerçek bir dizin değil: bu sadece kaynakların güncel versiyonuna sembolik bir bağlantı.
Bu, kaynakları sunucuya koyduğunuz, ancak henüz anahtarlamadığınız zaman şöyle bir anlama gelir:
root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:08 application -> /www/app-2009-09-01
Sembolik bağlantının "eski sürüm" olduğuna dikkat edin.
Şimdi, yeni sürüm tamamen sunucuya yüklendi, hadi:
root@shark:/www
# rm /www/application
root@shark:/www
# ln -s /www/app-2009-09-08 /www/application
Ve şimdi, /www/applicationkaynakların yeni versiyonuna işaret ediyor:
root@shark:/www
# ll
total 8
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-01
drwxr-xr-x 2 root root 4096 2009-09-08 22:07 app-2009-09-08
lrwxrwxrwx 1 root root 19 2009-09-08 22:09 application -> /www/app-2009-09-08
Ve sadece Apache'yi yeniden başlatmalıyız:
root@shark:/www
# /etc/init.d/apache2 restart
* Restarting web server apache2
" Bağlantıyı kaldır; yeni bağlantı oluştur; apache'yi yeniden başlat " adı verilen üç adım hızlı bir şekilde gerçekleştirilmelidir; yani, otomatik bir senaryo ile değil, bir insan tarafından değil.
Bu çözümü kullanarak:
Ve 0'da stat seçeneğiyle APC gibi bazı opcode önbellek kullanıyorsanız, duruş süresinin daha da az olması anlamına gelebilir, sanırım.
Elbette, bu "basit" versiyondur - eğer yüklenen dosyalarınız varsa, örneğin, başka bir yerde başka bir sembol link veya başka bir VirtualHost ya da her neyse ...
Umarım bu daha açıktır :-)
Güncellenen kod temeli ile ikinci bir sunucu kurun ve mümkün olduğunca hızlı bir şekilde değiştirin. :-)
Mümkünse, kod tabanınızın düzinelerce daha küçük parçaya bölündüğünden emin olun. O zaman aksama süresi, o zaman sadece bir tane alt kısım ile sınırlı olacaktır. Küçük kod bloklarının değiştirilmesi kolaydır ve çoğu problemsizce çalışmaya devam eder. Sadece bunu önce bir test ortamında deneyin!
Öncelikle, sık sık Pascal MARTIN'in yanıtına benzer bir yöntem kullanıyorum.
Benim de sevdiğim bir diğer yöntem ise yeni kodu zorlamak için SCM'mi kullanmak. Kesin işlem SCM türünüze bağlıdır (git vs svn vs ...). Svn kullanıyorsanız, sunucuda belge kökü olarak satın aldığım "çevrimiçi" veya "üretim" dalı oluşturmayı seviyorum. Daha sonra, ne zaman yeni bir kod / etiket / ana hattan yeni kod itmek istediğimde, yeni kodu "çevrimiçi" dalda kabul ediyorum ve svn güncellemesini belge kökünde çalıştırıyorum. Bu, sunucuya neyin aşağı / yukarı gittiğinin, kimin ve ne zaman yaptığı hakkında eksiksiz bir revizyon günlüğü olduğundan çok kolay geri alma işlemlerine izin verir. Ayrıca, bu "çevrimiçi" şubeyi test etmek için kolayca çalıştırabilirsiniz, böylece zorlamak üzere olduğunuz uygulamayı gözden geçirebilirsiniz.
Bu süreç git ve diğer SCM stilleri için benzer, sadece çalışma akış tarzları için daha doğal olacak şekilde değiştirildi.
Güncelleştirmeleri zorlamak yerine çekmek / yoklamak mı istiyorsunuz? Sadece bir cron işi veya başka bir akıllı mekanizma otomatik olarak svn güncellemesini çalıştırın.
Ekstra: Bu işlemi, uygulamanızın diske yazdığı dosyaları yedeklemek için de kullanabilirsiniz. Sadece bir cron iş veya svn taahhüt çalıştırmak başka bir mekanizma var. Artık, uygulamanızın oluşturduğu dosyalar SCM'nizde yedeklenir, revizyon günlüğü vb. Yedeklenir (ör. Bir kullanıcı diskteki bir dosyayı güncellerse, ancak geri almanızı istiyorsa, eski revizyona basmanız yeterli olur).
Ben de Pascal MARTIN’lara benzer bir yaklaşım kullanıyorum. Ancak, uygulamamın birden fazla sürümünü üretim sunucusuna yüklemek yerine, her birini yapı numarası ve tarih içeren ayrı bir dizinde güvenlik duvarımın arkasındaki "yapıları" tutar. Yeni bir sürüm yüklemek istediğimde "rsync -avh --delay-updates" içeren basit bir komut dosyası kullanıyorum. "Delay = updates" bayrağı, tüm güncellemeler gelinceye kadar her şeyi (farklı olan) geçici bir klasöre yükler ve aktarımın sonunda bir kerede her şeyi uygun yollarına taşır, böylece uygulama asla yarı eski yarı yeni devlet. Uygulamanın yalnızca bir sürümünü prodüksiyon sitesinde tutmama dışında (IMO yalnızca üretim sunucusundaki temel temel dosyalara sahip olmak en iyisidir), yukarıdaki yöntemle aynı etkiye sahiptir.