Merkezi Olmayan Kukla Mimarisinin Artıları ve Eksileri


14

Şu anda bir Puppetmaster sunucusuna bağlı olan yaklaşık 300 RHEL sunucumuz var. Ancak, bazı performans darboğazlarını fark ettik ve sistemimizdeki başarısızlık noktası bu. Genel olarak kukla için oldukça yeniyim ve Kukla istemcilerinin Puppetmaster sunucusuna bağlanmak yerine merkezi olmayan bir kukla mimarisi oluşturmayı düşünüyorum. Performans kazanımı ve yeni makineler için SSL sertifikalarını imzalama ve takas etmeme gibi bir şeyden şüphelenmem dışında, merkezi olmayan bir mimari kurmanın diğer artıları ve eksileri nelerdir?


3
Öyle ya da böyle olması için bir neden var mı? Aradaki bir yerde seçenekleri düşündünüz mü? Bu kadar sunucuyla ve tek bir hata noktasıyla ilgili bir endişeniz varsa, neden ek yöneticiler kurmadınız? Birden fazla yüke balyalanmış kukla sunucusu kurma 'Pro Kukla' kitabında ele alınmıştır. Çok fazla esneklik var, eğer mantıklıysa, bir kukla sunucuları hiyerarşisi kurmak bile mümkün olmalıdır.
Zoredache

@Zoredache Bunun şu ya da bu şekilde olması için bir neden yok, karar vermeyi kolaylaştırmak için genel olarak merkezi olmayan bir mimari hakkında daha fazla bilgi arıyordum. Ek ustaları düşündüm ama bahsetmediğim için özür dilediğim fikrin özü, bütçemizi doğrudan etkilediğinden sunucu sayısını azaltmaktır. Katılıyorum, kukla sunucuları yük dengeleme mantıklı, ama bir sunucudan hep birlikte kurtulabilirsem bu en iyi çözüm olacaktır.
JMeterX

Yanıtlar:


7

Merkezsizleşin.

Sertifikaları imzalamak yerine ssh anahtarları oluşturun. Anahtarları yönetici olmayanlara verme

Git'i alt sürüm yerine aktarım olarak kullanabilirsiniz ve daha sonra farklı makineler / roller için şube açabilir ve daha sonra değişikliklerinizin yanı sıra izin verebilirsiniz ... ancak bu noktada DVCS spielini bilmeniz gerekir.

Kurulumu daha hızlı ve daha az titizdir. Akıl sağlığı kontrolü için bazı bağlantı kancaları ekleyin.

Şimdi, bu noktada, kukla yöneticisini, istemci-sunucu modeliyle, her ikisi de kuklacıdan daha iyi olan ssh ve git ile değiştirdiniz.

Şimdi, kuruluşunuzda hiyerarşi için bir ihtiyaç olabilir. Hiç sorun değil, sadece kesin bir şube içeren git repo güvenli bir yerde saklayın.

Bonus:

git blame

kimin değişiklik yaptığını görmenizi sağlayacaktır.

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

https://www.braintreepayments.com/braintrust/decentralize-your-devops-with-masterless-puppet-and-supply-drop ?


3

Yolcu kuklası mı kullanıyorsunuz? saklanan yapılandırmalar? Temel kurulum sorunlarını ele aldığınız sürece 300 düğümde gerçekten ölçeklenebilirlik sorunlarınız olmamalıdır.


1
Apache + Yolcu yapılandırmasını kullanıyoruz. Ayrıca değişiklikleri
Puppetmaster

1

Merkezi olmayan, her müşterinin kendi manifest'i manifest kaynağının yerel bir kopyasından derlemesine neden olmanın en iyi yoludur. Bu, say git sunucusundan her güncellemeye bastığınızda güncellenir. Müşteriler her çalıştırmada kukla yöneticisine başvurmak zorunda olmadığından bant genişliğinin çok daha verimli kullanımı. Ayrıca istemciler her yerden güncellenebildiği için tek hata noktalarını da ortadan kaldırır.

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.