CI araçlarıyla süreç çalıştırmak mantıklı mıdır?

Benim şirketimde, yıllarca süren hızlı gelişim ve müteakip ihmal sonucunda, işlerimizi çalışır halde tutan süreçlerimizi (birden fazla sistemde) ve farklı cron işlerine dair bir bataklığa sahibiz.

Bir gün, bariz nedenlerden dolayı daha merkezi bir çözüm bulmamız gerekecek.

Etrafta dolaştığımız bir düşünce, Sürekli Entegrasyon yazılımımızı (Jenkins) mantıklı görünen bu işlemleri yürütmek için kullanmaktır.

Sorum şu: Başka şirketler bunu yapıyor mu? Bu genel olarak kabul gören bir uygulama mı? Bu, CI aracının tanımıyla örtüşmüyor mu? Başka seçenek var mı?

Not: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins, "cron işleri ve procmail işleri gibi dış kaynaklı işlerin yürütülmesini izleme" konusuna odaklandığını iddia ediyor. Tam olarak bahsettiğim şeyin bu olup olmadığından emin değilim.

Jenkins'i birkaç yıldır cron düşmesi olarak kullanıyoruz ve işte bazı artılar ve eksiler:

Artıları

• Düzinelerce sunucu ve çoklu ortamlar arasında çok sayıda işlemi yönetiyorsanız, birçok şeyi kolaylaştırır. Kutudan e-posta uyarıları, her şey için ortak bir kontrol paneli, günlükler için bir web arayüzü ve işleri yürütmek için ek düğümler ayarlamanın kolay bir yolunu alırsınız. Destek ekipleri, sorunları kontrol etmek ve işleri yeniden yürütmek için bu merkezi konuma sahip olmayı özellikle takdir eder.

• Jenkins plug-in ekosistemi çok aktiftir ve çok sayıda ek işlevsellik sunar ... Bence bu gerçekten Jenkins 'katil' özelliğidir, çünkü Jenkins'in kendisi aradığınızı sağlamazsa (çoğu durumda) genellikle olmayan bir eklenti yoktur. Favorilerimden bazıları: Cron Sütunu, Yeniden Oluşturma, NodeLabel Parametresi, Günlük Ayrıştırıcı ve E-posta Eklentisi.

• Gelişmiş zamanlama / tetikleme desteği: Zamanlama sözdizimi temel olarak cron'dur, bu nedenle orada aynı esnekliğe sahipsiniz, ancak bu Tetikleyiciler, REST API ve Groovy / Java API ile desteklenir

Eksileri

• Merkezi başarısızlık: Çünkü bütün işleriniz tek bir sunucu tarafından başlatılıyor, eğer bu kutu kapanır ve kimse farketmezse Büyük Sorun. Böylece, kesintileri hemen yakalamak ve kaynak kontrolüne kaydedilen tüm konfigürasyonlarınızı yakalamak için iyi izlemeniz daha iyi olur. Orijinal sunucuyu yedekleyemiyor olsanız bile, iş yapılandırmanız olduğu sürece, başka bir yere kurulum yapma önemsizdir. Çözünürlük zamanı bir endişe ise, bir yerde önceden yapılandırılmış bir bekleme moduna sahip olmak da muhtemelen iyi bir fikirdir.

• Birden fazla ortamınız varsa (Dev, UAT, Prod), genellikle her ortamda çalışan bir işin biraz farklı sürümleri vardır. Bütün bu işleri tek bir Jenkins üzerinde yapmak istemeyerek olabilir ve manuel olarak yapılandırmak çok büyük bir acıya dönüşür. Bizim durumumuzda, her ortam için ayrı bir Jenkins 'Cron' örneği kullanıyoruz. Örnekler bir şirket içi dağıtım aracı kullanılarak otomatik olarak yüklenir ve yapılandırılır. Bunun gibi bir şeye sahip olmayabilirsin, ama benzer şeyler yapan açık kaynak araçları var (şablonları kullanarak configs). Konfigürasyon oluşturma problemini çözebiliyorsanız, bu Jenkins'i kurmayı ve dağıtmayı çok daha kolay hale getirir ve ayrıca tüm malzemelerinizi kaynak kontrolünde tutmayı kolaylaştırır.

• Jenkins'i yükseltme bazen, özellikle eklentilerde işlevselliği bozuyor. Yeni sürümü ilk önce başka bir yerde deneyinceye kadar görev kritik Jenkins örneğinizi yükseltmeyin. Bu, kendi Jenkins örneği olan bir Dev ortamına sahip olmanın gerçekten kullanışlı olduğu yerdir.

Belki vurgulamak için bir şey: Gerçekten de CI için Jenkins kullanıyoruz, ama bu ayrı bir örnek ... 'cron' örnekleri iş yönetimine adanmış ve 'CI' örneği CI'ye adanmıştır. Endişeleri ayırmak işleri daha da temizliyor gibi görünüyor.

Not olarak evde Linux kutumda cron yerine Jenkins kullanıyorum :)

Bu arada, bu aslında oldukça yaygın bir Jenkins kullanım örneği. Örneğin, Sandia National Lab, Jenkins'i bu şekilde kullanır: https://software.sandia.gov/trac/fast/wiki/Hudson

Ve bunu açıklayan çok sayıda blog yazısı ve öğretici var. İşte birkaç örnek: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/1108

Ayrıca, bunun genel olarak tüm CI araçlarına değil, sadece Jenkins ile ilgili olduğunu da eklemeliyim. Sadece Jenkins bunu yapmaya çok uygun olduğu için başkalarının (TeamCity, buildbot vb.) Olduğu anlamına gelmez.

Buradaki iş için doğru aracı kullanmayacağınızı, CI araçlarının temel noktası olduğunu söylerdim: bir şeyi izlerler - tipik olarak kaynak kodunuz - ve bir değişiklik olduğunda bir derleme / dağıtım / ne olursa olsun .

Ancak, bu araçlar olabilir (örneğin) bir web sitesi dağıtmak, böylece etrafında kimse yokken, (TeamCity örneğin yapar) işler planlandığı çalıştırın. Yani yürüttüğünüz tüm görevlerin tek bir merkezi listesine sahip olmak aslında iyi bir fikir. Araçlar ayrıca, bu işlerin ne zaman ve ne sıklıkla çalıştırılacağına karar vermenize de izin vermelidir.

Diğer bir yararı da sistemi uzaktan izleyebilmenizdir (isterseniz).

Yani, dengede, yapılacak mantıklı bir şey olduğunu söyleyebilirim.

Cron, ihtiyaçlarınız için zaten uygun bir araç gibi geliyor. Sisteminizi daha iyi belgelendirerek başlamanızı öneririm. Çeşitli sistemleri denetleyin ve hangi işlemlerin hangi makinelerde çalıştığını içeren kapsamlı bir liste hazırlayın.

Ardından, tüm bu cron işlemlerini yürütmek için özel bir makine tasarlamayı düşünün. Bunun hangi makine olduğunu belgelendiğinizden emin olun ve kontrol etmek için uygun yönetici ayrıcalıkları atayın. Tüm cronjobs'ları bu makineye koyun ve ardından çeşitli otomatik işlemleriniz için merkezi bir kontrol noktanız olur.

Bağırsak tepkimem aynı, bir iş zamanlayıcısının işini yapmak için içinde zamanlama kavramı olan bir araç kullanıyorsunuz.

İşlerinizin ne olduğunu söylemediniz, ancak CRON'dan bahsetmeniz bana kabuk betikleri olduğunu tahmin etmemi sağlıyor. Açık kaynak kodlu ve ticari iş zamanlayıcı paketleri var. Bazen toplu zamanlayıcılar olarak adlandırılırlar. Bazıları sadece CRON'u saracak ve onu dostça yapacak. Bazıları, Quartz Zamanlayıcı gibi, işlerin güçlü yönetimini yapar, ancak Java sınıfları olarak uygulanmasını gerektirir. Potansiyel olarak bunu kullanabilir ve çalışma zamanı çağrılarını bir java sarmalayıcısı kullanarak çeşitli komut dosyalarınıza sarabilirsiniz. Daha fazla bakarsanız çok fazla seçenek bulacağınıza inanıyorum.

CI'yi, derlemeyle ilgili olmayan periyodik görevleri yürütmek için kullanmayın.

Ayrıca, sistem bakımıyla ilgili olmayan görevler için crondan kaçının.

Doğru araçları kullanın. Uygulama ihtiyaçları için - AMQP tabanlı çözümleri kullanmaya çalışın.

PS Görüyorum ki, bu cron senin davan için uyuyor. Öte yandan, birçok göreviniz var - bu yüzden onlar için gözetmen uygulaması yazmaya çalışın.

Bu tür bir görev için bir kurumsal servis veriyolu (ESB) kullanmanız gerekir .

Şimdi arkaplanım pencerelerde / BizTalk'ta ama bütün eşdeğerlerin işlerin unix tarafında da bulunduğundan eminim. Normalde yapacağımız şey, BizTalk kutusundaki diğer kutusundaki işleri başlatmaktan, ilerlemeyi / hataları izlemekten ve durumu SharePoint (veya web) portalına bildirmekten ya da e-postalar göndermekten sorumlu olacak süreçleri ayarlamaktır. dikkat gerekiyorsa böyle.

Bu yaklaşımın avantajları, çeşitli iş süreçlerinizin tüm konfigürasyon ve yönetiminin merkezi olarak konumlandırılmış olmasıdır, bu nedenle nereye bakacağınızı bilirsiniz. Kodlama bölümünü fiziksel konfigürasyondan soyutlamanıza izin veren bir yazılım zaten mevcuttur (BizTalk'da bir sql sunucusu gibi mantıksal bir 'port'a' karşı programlayabilirsiniz ve sonra bir sql kutusu yer değiştirirse veya yükseltilirse veya ne olursa olsun prod'de Yapılandırılmış fiziksel portu admin aracını kullanarak değiştirebilir, yine unix tarafında eşdeğerlerin bulunduğundan emin olabilirim).

Bir CI araçlarını kullanmanın yararları, işlem hatalarınız otomatik olarak yapılabiliyorsa, iletileri fiziksel olarak yeniden gönderebilir ve kümelenmiş bir arızalı ortam kurabilir, daha iyi bir kayıt ve kayıt sistemine sahip olabilirsiniz; ayrıca, sistemi kurduktan sonra, kuruluşunuzu kullanmak için SOA'yı daha iyi kullanmaya veya daha iyi kullanmaya başlamanıza izin verir. Aşağı tarafı, kuruluşunuzun büyüklüğüne bağlı olarak geliştirme çabalarının yüksek olabileceği ve lisans maliyetlerinin yasaklayıcı olabileceği yönündedir.

Teorik olarak, tüm farklı işleri kontrol etmek için tek bir yere sahip olmanız mantıklı geliyor, ancak “Kutsal Kase” gibi olan endüstri deneyimine dayanarak burada cron işlerine, buradaki basma senaryolarına ve buradaki senaryolara ihtiyacınız olacak.

"Kırılmadıysa, tamir etmeyin" diyen bir mantra da var, bu yüzden onlar yanlarına taşınırken, ilk önce hangi komut dosyalarını çalıştırdığınızı, ne yaptıklarını ve hangi sistemleri dokunduğunuzu belgelemeye odaklandığınızı belgelemeye odaklanın " "işiniz nasıl yürüyor?

Sonra uzun vadeli bir strateji işleri yürütmek için merkezi bir sistem kurarken, çözümünüzü akıllıca seçin çünkü bununla birlikte yaşamak zorunda kalacaksınız. Daha sonra her değişiklik talebi için, geliştirme, hata düzeltme veya iş mimarinize eklediğiniz yeni çözümler için zamanlanmış ve otomatikleştirilmiş görevlerin "kurumsal kontrol çözümünüze" eklenmesini sağlayın.

Bu şekilde, kademeli olarak bir komut dosyası grubundan daha kurumsal bir ortama geçiş yaparsınız.

Çalıştığım büyük kurumsal sistemlerde, zamanlama için tasarlanmış bir araç kullanma eğilimindedirler. Kullandığım en popüler CA7. Tüm sistemleriniz için tüm zamanlamaları merkezileştirmenizi sağlar.

Cron genellikle tek makinede kullanılır, ancak ssh uzaktan çağrıları yaparak "kesebilirsin". Ancak, bağımlılık kavramı ve diğer şeyler olmaz. Kapsamlarının daha da sınırlı olduğu operasyon ekiplerine gelince, bir takımın kullanılması en iyisidir.