Her zaman kullanımda olan bir sitede bakım çalıştırmayla ilgili fikirleriniz var mı?


18

Avustralya'da büyük bir oyun sitesine yardım ediyorum. Haftanın her günü, ertesi gün sabah 7'den akşam 1'e kadar yarışmalar düzenliyoruz. Site yayınlanmasından bu yana bir gün geçmedik. Doğal olarak, bu bakımın yapılmasını son derece zorlaştırıyor ve evreleme sunucumuzun üretim şubemizden 50 komisyona kadar ileride olduğunu görüyoruz. Genellikle, ana geliştirici dalları birleştirmek ve her şeyin düzgün çalıştığından emin olmak için son derece erken uyanmak zorundadır.

Evreleme sitemizi üretim tesisine olabildiğince benzer hale getirmeye çalışıyoruz, ancak bunu ancak benzer hale getirebiliriz.

Sitemiz gerçek zamanlı olarak Node.JS sunucusu ile Laravel merkezli. Laravel Forge kullanıyoruz.

Güncellemeleri daha sık nasıl iletebileceğimiz konusunda herhangi bir öneriniz var mı? Biz her şeye açığız.


Bir dağıtım neden bu kadar uzun sürüyor?
Michael Hampton

@MichaelHampton Deplokslarımız uzun sürmüyor, sadece bir şeyler ters giderse kesinti süresini karşılayamıyoruz.
cheese5505

1
Sanırım soru şu: Bir geri alma neden bu kadar uzun sürüyor?
Michael Hampton

@MichaelHampton, geri dönüşlere düzgün bir şekilde bakmadık, ancak bazen siteyi çok uzun süre kaldıracak büyük güncellemeler yapıyoruz.
cheese5505

5
Büyük zaman bloklarını alan her neyse, bakmanız gereken şey budur.
Michael Hampton

Yanıtlar:


22

Dağıtım sürecinizi iyileştirmek için yapabileceğiniz birçok şey var. Bunlardan birkaçı:

  • Kodunuzun iyi test edildiğinden emin olun.

    İdeal olarak,% 100 birim test kapsamının yanı sıra akla gelebilecek her senaryo için entegrasyon testine sahip olmanız gerekir.

    Eğer buna sahip değilseniz, muhtemelen her şeyi bırakmalı ve bununla ilgilenmelisiniz.

    Davranış odaklı gelişime bakın.

    Eksiksiz bir test paketine sahip olmanız ...

  • Sürekli entegrasyonu çalıştırın.

    Birisi her değişiklik yaptığında, CI otomatik olarak üzerinde test paketini çalıştırabilir. Test paketi başarılı olursa, hemen dağıtılabilir (veya bir dağıtım zamanlayabilir). Veritabanlarınızda önemli bir değişiklik gerektirmeyen değişiklikler için, bu tek başına size çok fazla zaman ve baş ağrısı kazandıracaktır.

    Bir sorun olması durumunda, CI size tek tıklamayla geri alma da sağlayabilir.

    Test paketiniz tam ve doğru değilse CI çok daha az kullanışlıdır, çünkü tüm tesis kodunuzu otomatik bir şekilde doğrulamaya dayanır.

  • Atomik güncellemeler yapın.

    İdeal olarak, sadece üretim sunucusundaki eski dosyaları kopyalamamalısınız. Bunun yerine, her dosyayı yeni bir konuma kopyalayan capistrano gibi bir araç kullanın ve ardından istenen dağıtımı işaret etmek için sembolik bir bağlantı kullanın. Geri sarma anlıktır, çünkü symlink'i önceki konuşlandırmaya işaret edecek şekilde değiştirmeyi içerir. (Ancak bu, veritabanı taşıma işleminizi kapsamıyor olmayabilir.)

    Ayrıca Docker gibi kapların size yardımcı olup olamayacağını da görün.

  • Daha küçük, daha sık değişiklikler yapın.

    Testleriniz, CI ya da hiçbir şeyiniz olmasa da, bu tek başına önemli ölçüde yardımcı olabilir. Her değişikliğin kendi git dalı olmalı ve konuşlandırmanın mümkün olduğunca az değişikliği olmalıdır. Değişiklikler daha küçük olduğundan, dağıtım sırasında potansiyel olarak yanlış gitme olasılığı daha azdır.

    Bu notta, mümkün olduğunda değişiklikleri daha yalıtılmış hale getirin. Omaha oyununda bir değişiklik yaptıysanız ve bu Texas Hold'em, 5 kart stud veya başka bir şeyi etkilemezse, bu bir bakım için askıya alınması gereken tek oyundur.

  • Uzun süren bir şeyi analiz edin.

    Dağıtımlarınızın bazı bölümlerinin uzun sürdüğünden bahsettiniz. Bu muhtemelen veritabanı şeması değişiklikleri. Neyin daha iyi performans gösterebileceğini görmek için veritabanınızın her şema değişikliğiyle birlikte bir DBA'ya bakmaya değer.

    Bir konunun uzmanının, dağıtımın büyük zaman alan tüm bölümlerine bakmasını sağlayın.

  • Garip saatler çalışın.

    Bunu zaten yapıyor olabilirsiniz, ama bundan bahsediyor. Geliştiricilerin (ve sistem yöneticilerinin!) Artık özellikle 7x24 çalışma için "9 ila 5" çalışması beklenmemelidir. Birinin bir gecede konuşlandırılması için bebek bakımı yapması, sorunları çözmesi ve daha sonra gündüz bir program tutması bekleniyorsa, beklentileriniz gerçekçi değildir ve o kişiyi tükenmişlik için hazırlıyorsunuz.


Buradaki en basit çözüm, dağıtım komut dosyalarını Capistrano gibi bir araçta kullanmak ve hatta yük dengeleme yapmaktır.
JakeGould

Tavsiye için teşekkürler. Bunu inceleyeceğiz. Şu anda bir test paketimiz yok ve siteye 8 aydan fazla bir süredir geliştirilmekte ve o kadar büyük ki bir tane yapmak için bir haftadan fazla sürecek. Yeni sürümü nginx'in kurulduğu klasöre bağlayan Laravel Forge'ı çalıştırıyoruz. Okul yüzünden tuhaf saatler çalışamıyorum ve aynı şey diğer geliştiriciler için de geçerli.
cheese5505

1
@ cheese5505 Bunun sinir bozucu olduğunu ve sorununuzu çözmediğini biliyorum ama bunu söylediğinizde, “… o kadar büyük ki, bir tane yapmak bir haftadan fazla zaman alacaktı” . Herhangi bir aklı geliştirme ve dağıtım süreci, bir sunucunun bir günden daha kısa sürede veya belki birkaç saatten bir saate kadar oluşturulmasına izin verecektir. Bunu önlemek için yönetilemez şeyler yığını oluşturmak için ne yaptığınızı gerçekten gözden geçirmelisiniz. Sorun karmaşıklık değil, planlamada temel öngörüdür.
15:15

1
"Şu anda hiç bir test paketimiz yok" - yeni özellikler geliştirmeden önce bunu şimdi düzeltin . Bu, en büyük ağrı noktanızdır ve kullanılabilirlik riski olacaktır. Otomatik test, kesintileri önlemeye doğru uzun bir yol kat edecek ve ops ağrısını önemli ölçüde azaltacaktır.
Josh

6

Her gün 1'den 7'ye kadar bir bakım penceresine sahip olduğunuzu söylediğinizden anlaşılıyor, sorun her zaman zaman değil kolaylık. Bu normaldir ve birçok insan işin bir parçası olarak onunla ilgilenir.

Trafiği şu anda canlı olanlara yönlendiren bir ön uca sahip 2 (veya daha fazla arka uç) sisteminiz olabilir. Bir sürümün çalışacağından memnun olduğunuzda, kullanıcı arabirimine yeni sisteme geçmesini söylersiniz. bu kısa bir süre için komut dosyası oluşturmak kolay olmalıdır.

Artık eski sistemi olduğu gibi bırakma seçeneğiniz var, böylece bir sonraki güncellemeleri oluşturma / test etme zamanı gelene kadar canlı sistem için yedek olarak kullanılabilmesi için geri çekebilir veya güncel hale getirebilirsiniz.


Arka ucu ön uçtan ayırdığınızda, tamamen modüler yazılım mimarisini mi kastediyorsunuz? Veya yük dengeleyici gibi sunucu mimarisi mi?
15:15

2
sadece bağlantıları kabul eden ve mevcut birincil arka uca ileten bir şey.
user9517 GoFundMonica

5

Diğer cevapları değiştirme: Mavi-yeşil dağıtım modelini izlemelisiniz . Yeni bir sürüm yayınlamak istediğinizde bu sürümü dahili bir web sitesine dağıtırsınız. Ardından, bir sonraki sürüm üretim sitesinde otomatik testler gerçekleştirebilirsiniz. Testler bittiğinde, yük dengeleyiciyi yeni web sitesini kullanmaya yönlendirin.

Bu, aşağıdaki şekilde yardımcı olur:

  1. Sıfır kesinti süresi ile her zaman ciddi sorunlar bulunur.
  2. Yeni sürüme geçilmesi, yeni sürüm zaten başlatıldığı ve ısındığı için tamamen sıfır kesinti süresine sahiptir.
  3. Hala fiziksel olarak çalıştığı için istediğiniz zaman eski sürüme geri dönebilirsiniz.

Siz ve başkalarının bahsettiği diğer tüm sorunlar, istediğiniz zaman stressiz bir şekilde dağıtılabildiğinizde daha az şiddetlenir. Mavi-yeşil dağıtım modeli, dağıtım sorunları için oldukça eksiksiz bir çözümdür.


Zaten test etmek için kullandığımız bir hazırlama sunucumuz var, ancak şu anda üretim ve aşamalandırma farklı konumlardaki farklı sunucu sağlayıcılarında. Bizim için daha iyi performans sağladığı için üretimi sahnelemeye taşımaya çalışıyoruz.
cheese5505

1
Anahtar, yük dengeleyiciyi kanıtlanmış bir çalışma versiyonuna geçirmektir. Şu anki modelde buna sahip değilsiniz.
usr

1
Bir modelin ne kadar iyi olduğu, sitenin ne yaptığına çok bağlıdır. Site vatansız sonra büyük ama vatansız değilse nasıl bu devlet geçiş üzerinde transfer olacak çalışmak zorunda.
Peter Green

@PeterGreen, kümelenmeye izin vermediği ve yeniden dağıtım / yeniden başlatma / çökme / bluescreen vb.
usr

@ usr çoğu web sitesinin durumu vardır. Bu durum dosyalarda veya veritabanında saklanabilir. İkinci durumda, veritabanı yerel veya uzak olabilir. Bazı yükseltmelerin bu durum üzerinde bir etkisi olması muhtemeldir, yani yükseltme ve geri alma sadece kodu değiştirmek kadar basit değildir.
Peter Green

3

Ana veri merkeziniz zaman zaman tüm veri merkezlerinde meydana gelen bir kesinti yaşarsa ne yapacaksınız? Arıza süresini kabul edebilir, başka bir veri merkezine geçebilirsiniz, her zaman birden fazla veri merkezinde aktif-aktif modda çalışıyor olabilirsiniz veya başka bir planınız olabilir. Bunlardan hangisi olursa olsun, sürümleri yaptığınızda yapın ve daha sonra bir sürüm sırasında ana veri merkezinizi aşağı indirebilirsiniz. Veri merkezinizde bir kesinti olduğunda kesinti yaşamaya hazırsanız, kesinti yaşamaya hazırsınız demektir, bu nedenle bir sürüm sırasında sorun olmamalıdır.


2

Önceki cevaplara eklemek için:

  • Geri dönüşlere ve anında geçişe izin veren bir dağıtım stratejisi kullanın, Capistrano veya hemen hemen diğer tüm dağıtım sistemleri bu konuda yardımcı olacaktır. Hızlı bir şekilde önceki bir duruma geri dönmek için veritabanı anlık görüntüleri ve kod simgeleri gibi şeyleri kullanabilirsiniz.

  • Tam yapılandırma yönetimini kullanın, hiçbir şeyi manuel olarak yönetmeyin. SaltStack, Ansible ve Kukla gibi sistemler örnek olarak verilebilir. Docker konteyner konfigürasyonlarına ve vagrant kutularına da uygulanabilirler.

  • Bir düğümü yükseltirken istekleri teslim edebileceğinizden emin olmak için HA kullanın. Yükseltme başarısız olursa, sadece düğümü aşağı indirin ve geri alındığında, geri getirin ve HA çözümünüz fark eder ve talepleri tekrar belirtilen düğüme iletir. HAProxy bir örnektir, ancak nginx de iyi çalışır.

  • Uygulamanın, önbellek gibi diskte depolanması gereken kod dışı veriler için eşzamanlı örnekleri, kullanılan merkezi sürüm veri havuzlarını işleyebildiğinden emin olun. Bu şekilde, farklı bir sürümdeki dosyaları önbelleğe almak için hiçbir zaman yükseltilmiş uygulama çalıştırılmaz. Bu, önbellek temizliği ve elbette önbellek ısınmalarının yapılması üzerine yapılacaktır. (Önbellekleme işi sadece bir örnektir)

Genellikle ekip yöneticilerinin tüm normal CI işlerini yapan özel bir şubeye birleştirme isteklerini onaylayabileceği iş akışları ayarladım, ancak ek bir son adım olarak üretim düğümlerine zorlamaya başlar. Temelde yaptığınız şey, bir üretim örneğine manuel bir CI dağıtımı çalıştırmaktır. Bu örnek geçersiz yanıtlar üretmezse, verilerinize garip bir şey yapmazsa veya CI tercih çözümünüzü kullanarak tüm düğümleri toplu olarak yükseltirsiniz. Bu şekilde, bir dağıtım çalışırsa, tüm dağıtımların belirli bir etiket / taahhüt için çalışacağını bilirsiniz.

Şu anda, tek bir düğümde, bir dağıtım işlemi, bir kaynak ve bir hedef ile bir üretim uygulaması çalıştırıyormuşsunuz gibi geliyor. Bu, pratikte bu iş akışındaki her adımın web sitesini bozabilecek bir hata noktası olduğu anlamına gelir. Böyle bir şeyin gerçekleşmemesini sağlamak, tüm CI, HA ve yük devretme süreçlerinin temelidir. Sadece bir düğüm çalıştırmayın, sadece bir HA işlemi çalıştırmayın, sadece bir IP adresinde çalıştırmayın, sadece bir CDN vb. Çalıştırmayın. Kulağa pahalı gelebilir, ancak zaten sahip olduklarınızın bir kopyasını koyarak kendi bağlantısı olan bir sunucudaki bir rafta genellikle bir iş sitesinde bir saatten daha az çalışmama süresine mal olur.


0

Michael ile her noktasında küresel olarak anlaşıyorum ( /server//a/739449/309477 ).

Bence ilk yapmanız gereken bir dağıtım aracı (Capistrano) kullanmak.

Huzurlu bir şekilde konuşlandırmanıza, ardından anında yeni sürüme geçmenize izin verir. Bir şeyler ters giderse, geçerli symlink'i çalışan bir sürüme değiştirerek anında çalışma sürümüne dönebilirsiniz.

Ve Capistrano ilk işlemek için oldukça hızlı (daha büyük bir zaman yatırımı olacak testler ve CI kullanmaya kıyasla).

İkincisi, para ana sorununuz değilse, üretimde dağıtmadan önce uygulamanızı test etmek için iso-prod geliştirme sunucunuz olmalıdır. VPS örneklerini yönetmek için endüstriyel bir çözüm (Ansible, Chef, Kukla) kullanın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.