Soru Kukla, ansible veya kumaş ile güncellemeler


Önceden bir yükleyici ile bazı iskele sunucularım var. Şimdi uygulamamı kesinti yaşamadan güncellemek istiyorum. Bir iskelet aşağı indiğinde ve artık erişilemediğinde, yük dengeleyici otomatik olarak listeden kaldırır, bu nedenle sorun bu değildir.

Asıl sorun, zaman aşımından kaçınmaktır: bu yüzden, bir seferde sadece bir iskelenin yeniden başlatıldığından emin olmak zorundayım - ya da en azından N jettys'in çevrim içi olduğundan emin olun!

Şu anda basit bir bash komut dosyası kullanıyorum ve bir iskelenin bir sonraki iskeleyi yeniden başlatmadan önce tekrar çevrimiçi olarak tekrar gelmesini beklemek zorundayım.

Şimdi bash bu tür şeyler için çok uygun değil ve umarım tüm işi otomatik hale getirmek için daha uygun araçlar vardır. Örneğin. Basit bir ping URL'si kullanabilirdim http://jetty-number-n.com/ping n-th iskele çevrimiçi ise Tamam (200) yanıt verir.

Bu görevi nasıl çözebilirim ve hangi araçla?

@Ceejayoz için teşekkürler haddeleme güncellemesi ansible için. Ama sabit bir zaman aşımı ayarladığım için hala optimal değil.


6
2018-03-26 20:06


Menşei




Cevaplar:


Ansible ile bu oldukça kolaydır. Kaba sözde ansible oyun kitabı:

---
  - hosts: your_server_group
    sudo: yes
    serial: 1
    tasks:
      - shell: reboot now
      - wait_for: port=22

9
2018-03-26 21:26



Bunun için varsayılan zaman aşımını unutmayın. wait_for 300 saniyedir, bu yüzden onu isteyebilirsiniz. - ceejayoz
Güzel! Sabit bir zaman aşımı yerine - bir sonraki sunucuyu yeniden başlatmayı beklemek için ping-URL'imi nasıl kullanabilirim? - Karussell
@Karussell belirsiz zaman aşımı istemiyorsunuz çünkü sunucunuz asla geri gelmiyorsa sonsuza kadar bekleyeceksiniz. Yapabilecekleriniz, bu zaman aşımına bir bayrak yükseltmek için bu oyunu güncellemek ve ardından bu bayrak ayarlanmışsa ana bilgisayarların geri kalanına dağıtmaktan kurtarmaktır. Bu şekilde tüm ev sahiplerinizi seri şekilde öldürmeyeceksiniz. :) - Mxx
Ne demek istediğini anladığımdan emin değilim. İstediğim şey, ping URL’si TAMAM’a dönene kadar bekleyeceği ve daha sonra sabit uzunlukta zaman aşımı yerine (çok uzun ama aynı zamanda da çok kısa) devam edeceğidir. - Karussell
@Karussell Sabit bir zaman aşımı değil. Bağlantı noktası 22'nin (SSH) tekrar gelmesini kontrol ediyor. Ayrıca 80 numaralı bağlantı noktasından (web sunucusu) veya sisteminize özgü başka bir şey de hedefleyebilirsiniz. Zamanaşımı, bağlantı noktası gelmediğinde başarısız olacağı noktadır. - ceejayoz


Tuzun uygun bir parti seçeneği var.

salt -G 'os:RedHat' --batch-size 25% service.restart jetty

İskele hizmetini bir seferde RedHat sunucularının% 25'inde yeniden başlatın.

salt -N group1 -b 2 system.restart

Sunucuları önceden tanımlanmış "grup1", 2'de bir seferde yeniden başlatın.


4
2018-04-04 15:57





Kukla kavramları vardır Hizmetler ve Sipariş. Ancak kukla tek bir sunucu üzerinde çalışır. Yani, üzerinde çalıştığı diğer sistemlere dair bir içgörüsü yok.

Kukla kullanmak istediyseniz, bir ana kontrol sunucusunun her sunucunun servislerini yönetmek için bir init betiğine sahip olmasını sağlayabilirsiniz. Böylece init betiği her sunucuda yeniden başlatmayı çalıştıracak ve durum kodunu geri gönderecektir. Bunu yapabilir ve her bir hizmet sunucusunu yeniden başlatıp zincirleme veya zincirleme ya da bir sonraki mesaja geçmek için abone olabilirsiniz.

Ayrıca kukla için bir sunucuyu ana kontrol sunucusu olarak ele alan, ancak init komut dosyalarını kullanmak yerine özel bir kitaplık yazabilirsiniz. Her sunucunun hizmetlerini yönetmek için özel bir yakut kitaplığı kullanabilir. Kurmak biraz daha karmaşık, ama işe yarayabilir.


1
2018-03-26 20:40



Açıklama için teşekkürler! Hmmh kukla muhtemelen yanlış bir araç ... - Karussell
Yanlış bir araç gerekli değil, ama bulmacanın bir parçası olabilir - Ryan Gibbons


Kukla'yı şu an işyerinde kullanıyorum, ancak ilk posterin yanıtı olarak, bu Kukla için ideal bir ilk görev gibi gelmiyor. Ben sesle konuşamıyorum (yine de denemeye başlamak istiyorum).

Kukla, değişiklikleri / yeniden başlatma sistemlerini eş zamanlı olarak açmak için daha fazla düzenlenmiştir - bir kukla daemon her bir istemci üzerinde çalışır ve programlanmış bir aralıkta (her yarım saatte bir) merkezi bir sunucuya karşı kontrol eder. Varsayılan programlamayı yapmak istiyorsanız, genellikle kukla aramak için farklı bir mekanizma kullanırsınız.

Aynı anda yeniden başlatmayla tamamsanız, bir hizmeti yeniden başlatmak,

file { 'your_war_file.war':
    ensure  => file,
    source  => "puppet:///...",
}
service { 'jetty':
    subscribe  => File['your_war_file.war'],
    hasrestart => True,
}

kaynak direktifleri, daha sonra tezahür ettirmek ve Kukla'nın kendi işini yapmasına izin vermek. Bu çağrı ile tamam olduğunu varsayar

/etc/init.d/jetty restart

kabul edilebilir veya kabul edilemez veya mümkün olmayabilir.

Aynı zamanda, sizin için özel kaynak türlerinizi de tanımlayabilirsiniz, ki bu kesinlikle basit bir ilk kukla görevi kapsamı dışındadır.

Çıkış yapmak http://forge.puppetlabs.com/Ancak, başka birinin benzer bir sorunu çözüp çözmediğini görmek için.


1
2018-03-26 20:46



Teşekkürler! Ancak eşzamanlı yeniden başlatma, uygulamanızı birkaç metrik saniye boyunca kullanamaz hale getirecek, başka bir araç / hile biliyor musunuz? - Karussell


Yapmak istediğiniz görev ansible kullanılarak yapılabilir ve kesinlikle Kukla kullanılarak yapılabilir. Kukla kullanarak nasıl başaracağınıza odaklanacağım.

WAR dosyalarınızı, kukla kullanarak, normal bir "dosya" kaynağı ve her bir uygulama için başlattığınız tanımlanmış bir kaynak kullanarak dağıtabilirsiniz.

Kukla belirttiğiniz URL'den (Kukla Yöneticiniz) indirilecektir. Jetty, WAR dosyası değişiklik zamanı değiştiğinde, WAR dosyalarını yeniden başlatmadan yeniden aktarabiliyor. Yani manifestiniz bir kopya oluşturuyorsa $JETTY_HOME/webapps otomatik olarak Jetty tarafından alınmalıdır. Bu şekilde (veya context.xml'ye dokunarak), Jetty'yi manuel olarak yeniden başlatmanız gerekmez.

WAR dosyasını Puppet Master'ınızdan Uygulama Dizini'ne indirmek için aşağıdaki bildirime ihtiyacınız olacak ($ ​​JETTY_HOME yerine):

define jetty::deployment($path) {

  notice("Deploying ${name} to http://$hostname:${appserver-jetty::port}/"),
  include jetty,

  file { "$JETTY_HOME/webapps/${name}.war":
    owner => 'root',
    source => $path,
  }
}

ve düğümlerinize uygulamanızın belirli bir sürümünü birbiri ardına almaları için talimat vermeniz gerekir (düğümlerden birinde başarılı bir şekilde başlatıldığından emin olduktan sonra). Bu bir kullanarak yapılabilir ENC (harici düğüm sınıflandırıcı) veya ENC kullanmıyorsanız, her düğüm (veya düğüm grubu) için site.pp bölümünüzü değiştirerek:

node jetty-node1 {
   jetty::deployment { "servlet":
     path => '/srv/application/Servlet-1.2.3.war'
   }
},
node jetty-node2 {
   jetty::deployment { "servlet":
     path => '/srv/application/Servlet-2.0.1.war'
   }
}

include jetty Örneğin Jetty konfigürasyonunuzu örneğin kukla kullanarak kukla yoluyla yönetmek istiyorsanız hat gereklidir. https://github.com/maestrodev/puppet-jetty ve bu tanımlanmış kaynak bir appserver-jetty :: $ port değişkenine ihtiyaç duyar. Bu örnek, uygulamanın hangi sürümünün hangi düğüme göre çalıştığını denetlemenin en basit yolunu gösterir. Bu şekilde, dağıtımınızı, sağlık kontrollerinize göre yapılandırabilir ve yalnızca node1, yeni sürümü başarıyla çalıştırdıktan sonra node2'ye dağıtabilirsiniz.

Bu örnek sadece kavramı göstermektedir.

Daha fazla bilgi ve fikir için bu ek kaynakları kontrol etmek isteyebilirsiniz: İçeriklerin yeniden yüklenmesi hakkında: https://stackoverflow.com/questions/13965643/auto-reloading-war-in-jetty-standalone

Bu, tomcat'in dağıtımı ve yönetimi içindir, ancak fikirler (ve manifestolar) benzerdir: http://www.tomcatexpert.com/blog/2010/04/29/deploying-tomcat-applications-puppet

Bu, IMO'nun, WAR dosyalarını doğrudan kopyalamak için daha iyi bir alternatiftir - uygulamanızı dağıtmak için yerel paketleri (örn. RPM) kullanarak: http://www.slideshare.net/actionjackx/automated-java-deployments-with-rpm


1
2018-03-27 09:58



Sanırım asıl sorun zamanlamadır: Ya tüm iskele sunucuları aynı anda yeniden başlatılıyorsa? - Karussell
Her düğümde (site.pp veya ENC içinde) yüklenecek uygulamanın sürümünü ayarlayan siz olduğunuzdan, siz (komut dosyanız) yeni düğümün çalışır durumda olduğundan emin olmalısınız. Açıklayıcı snippet'lerin sözdizimini çözeceğim. - zorlem
Yeniden başlatma olmadan yeniden dağıtım, uzun zaman dilimi boyunca çalışmaz (yığın akışındaki permgenError sorunlarına bakın). Özellikle de ona çok fazla savaş / kavanoz yerleştirirseniz. - Karussell