Kukla veya Şef, çok kiracılı bir ortamda çok temel sunucu yapılandırmasını yönetmek için uygun mu?


9

Bu, küçük bir barındırma şirketi gibi çok kiracılı ortamlarla ilgilidir.

Kukla (veya benzeri) temel fakat kritik kütle değişikliklerinin bakımı için uygun bir teknoloji midir? Örneğin:

  • DNS çözümleyicilerini güncelleme (resolv.conf)
  • SSH anahtarlarını ayarlama
  • NTP yapılandırmasını güncelleme
  • Snmpd yapılandırması
  • SNMP Perl uzantıları veya Nagios komut dosyaları gibi izleme komut dosyalarını dağıtma

Endişelerim güvenlik ve istilacılıkla ilgili:

  1. Herhangi bir sunucunun yapmaması gereken herhangi bir yapılandırmayı görebilmesini istemiyorum
  2. Bir Kukla ustasının güvenliği ihlal edilmiş bir sunucunun saldırısına karşı savunmasız olabileceğinden endişeleniyorum
  3. Kukla'nın yapmaması gereken değişiklikleri yapmasını veya sunucuda yapılan herhangi bir manuel değişikliği geri almasını istemiyorum.

Kukla üretimde hiç kullanmadığımı, sadece bir test laboratuvarında hızlı bir oyun oynadığımı söyleyerek bunu uyarmalıyım, bu yüzden bunu yanlış şekilde düşünüyorum.

Yanıtlar:


6

Ansible'ı (ansible.cc) deneyin. Belki senin için. İstemcilerinizde çalışan aracı yok. Çok hızlı büyüyor.

Bir başka çok iyi alternatif Tuz Yığını.

Ansible ve Salt'ın anlaşılması kolaydır, isterseniz dağıtılmış kabuk gibi bir komut satırı aracı olarak kullanabilirsiniz.


1
Bunu uzun zaman önce sorduğumu biliyorum. Bunun cevabı olduğunu düşündüğünüzü bilmekten memnun olacaksınız. Şimdi Ansible'ı günde 10'lu sunucuyu otomatik olarak kullanıma sunmak için kullanıyoruz ve 1000'leri ateşle ve unut tarzında yönetiyoruz. Bir yılı aşkın süredir harikaydı.
SimonJGreen

9

Evet, bu kesinlikle mümkün. Bunu yapıp yapmayacağınıza karar vermek size kalmış.

Sorgularınızla ilgili olarak:

1) yeterince adil. Trafik SSL tabanlıdır, bu nedenle sertifika yönetimi önemlidir. Ayrıca, müşterinin kimliğiyle ilgili sağladığı 'gerçeklere' güvenmeyin, çünkü bunlar müşteri tarafından değiştirilebilir. Sunucunun kim olduğunu doğrulamak için istemcinin SSL sertifikasına güvenmek istiyorsunuz. Dürüst olmak gerekirse, hiera gibi şeyleri düzgün bir şekilde kullanıyorsanız ve kodunuzda (gerçekten yapmanız gereken) büyük ana bilgisayar adı tabanlı if-bloklarından kaçınıyorsanız iyi olacaksınız.

2) Yamalı kaldığınızı varsayarak olmamalıdır. Düzgün yapılandırılmış, kukla yöneticisinin istemciler tarafından saldırıya uğraması için sadece küçük bir vektör vardır. Bununla birlikte, eğer tehlikeye düşerse etkileri büyüktür, bu yüzden kilitlemeye dikkat edin.

3) Bu gerçekten bir test ve dağıtım sorunu. Katı kukla kodunuz varsa, dosyalarınızı vidalamaz. Bunu sıralamak biraz zaman alır, ancak temeller için (ihtiyaç duyduğunuz gibi) uzun sürmez.


4

Kukla (veya benzeri) temel fakat kritik kütle değişikliklerinin bakımı için uygun bir teknoloji midir?

Evet, bu şekilde kullanılabilir. Bunu harici istemci sistemlerini desteklemek için kullanıyorum.

Herhangi bir sunucunun yapmaması gereken herhangi bir yapılandırmayı görebilmesini istemiyorum

Eğer kukla kullanıyorsanız, sen olmamalıdır sonra autosign etkinleştirin. Otomatik imza, ana makinelerin otomatik olarak sertifika istemesine izin verir. Yapılandırmanız ve izinleriniz neredeyse kesinlikle doğrudan sertifikadaki CN'ye bağlı olacaktır. Rastgele bilgisayar çevrimiçi geliyor ve aslında tüm gizli yüksek güvenlik şeyler ile sistem olduklarını iddia edebilmek istemiyorum.

Gerçekten paranoyaksanız, yalnızca bazı sistemlerin erişebileceği paylaşımlar oluşturmak için kuklalar dosya sunucusu ayarlarını yapabilirsiniz. Dosya sunucusu erişimi sertifikalara dayanır.

Kukla'nın yapmaması gereken değişiklikleri yapmasını veya sunucuda yapılan herhangi bir manuel değişikliği geri almasını istemiyorum.

Yerel değişikliklere izin vermek için birkaç farklı yaklaşım vardır.

Sık kullandığım yöntemlerden biri aşağıda. Temel olarak bir listeyi sourcea'ya iletirseniz, kukla listedeki her öğeyi deneyin. Bu yüzden listedeki ilk öğeyi yerel bir dosyayı gösterecek şekilde ekliyorum.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Başka bir seçenek de sembolik bağlantıları kullanmak olacaktır. Birisi kukla sürümünü kullanmak istiyorsa, bir dosyanın kukla sürümüne bağlanır. Yapılandırmalarını yerel olarak korumak istiyorlarsa, bir sembolik bağlantı oluşturmazlar.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

Diğer olasılık, tüm dosyaları değiştirmek yerine satır düzeyinde değişiklikler yapmak için augeas kullanmaktır. Neleri değiştirdiğiniz konusunda çok tutucu olun.


1

3> Kuklada veya bu tür araçlarda otomatik geri alma yoktur. Geri almak için açık kod yazmanız gerekir. Ayrıca, kuklanın Ortamlar özelliğini araştırabilir, yeni kodun test edildiği (VM'ler olabilir) bir Test laboratuvarına sahip olabilir ve kod incelemesini kullanabilirsiniz.


Tam olarak doğru değil. Chef, /var/lib/chefvarsayılan olarak değiştirdiği herhangi bir dosyanın yedeklemesini yapar (kaynak, hassas veriler için hiçbir yedekleme bırakmayacak şekilde yapılandırılmadığı sürece) ve docbiçimlendirici ile terminal çıkışında bir fark görürsünüz.
Maciej Pasternacki

Evet, Kukla da birden fazla yedekleme yapabilir . Ancak hangi yedeğin geri yükleneceğini nasıl bilebilirsiniz? Bu eylemi gerçekleştirmek için bazı Şef / Kukla kodu veya harici komut dosyası yazmanız gerekir mi? Belirli bir sürümü olan önceki bir pakete geri dönmek gibi dosya dışı kaynaklara ne dersiniz? Hizmetler ne olacak? "Çalıştığından emin olun" yazan bir kodunuz varsa ve bunu değiştirmek istiyorsanız, "durduğundan emin olmak" için kodu değiştirmeniz gerekir.
Şimdi Değil

Fikir, yapılandırma yönetimi çalışmasının tek yönlü olmasıdır. Desteklenen bir geri alma prosedürü veya tamamen çalışan "kuru çalışma" yoktur (Chef'de tam simülasyon yerine yalnızca bir öneri / akıl kontrolü olan bir whyrun modu vardır (bkz. Blog.afistfulofservers.net/post/2012/12/21/ … Daha uzun bir açıklama için) Kullanıcı parolasını değiştiremezsiniz, vb. Bu yüzden "tam olarak doğru değil" yazdım - desteklenen bir geri alma yok, ancak yedeklemeyi görmenizi sağlayan bir güvenlik / hata ayıklama ağı var bir şeyler ters gidiyor ve bir göz atmanız gerekiyor, başka bir şey yok, ama yine de faydalı
Maciej Pasternacki

Ve yorumunuzu yanlış okudum - bu otomatik geri alma yoktur ve otomatikleştirmek için çalıştı açık (ve büyük olasılıkla hatalı) kodu yazmanız gerektiği doğrudur. Yanıtlandığından beri orijinal yorumumu düzenleyemiyorum - otomatik geri alma yerine felaket kurtarmayı düşünüyordum. Otomatik geri alma işlemini görmek istiyorsanız, nixos.org , BTW adresine bakın .
Maciej Pasternacki

1

Kukla'nın yapmaması gereken değişiklikleri yapmasını veya sunucuda yapılan herhangi bir manuel değişikliği geri almasını istemiyorum.

Kuklalar Dosya türü kullanılarak oluşturulan yapılandırma dosyaları için bu ayar aşağıdakilerle gerçekleştirilebilir:

replace => false,

Bir uygulamayı bir sunucuya ilk kez dağıtıldığında bazı yapılandırma dosyaları oluşturmak için kullanırım, ancak bu yapılandırma dosyasında yapılan herhangi bir düzenlemenin üzerine Kukla tarafından yazılmaz.

Ancak bu Kukla felsefesinin idempotent konuşlandırma senaryosu olması felsefesine aykırıdır.

Kukla tarafından yönetilmeyen ve kukla tarafından yönetilen dosyalardan gelen ayrı olarak düzenlenebilir ayrı dosyalara sahip olmanız daha iyi olabilir.


0

Kukla aynı yapılandırmaya sahip birçok sunucu için en iyi sonucu verir. Örneğin, şirketiniz tarafından sağlanan paylaşılan bir web sunucusunun tüm yapılandırmasını yazıp, bu sunucunun N örneğini oluşturursunuz. Daha sonra tüm örneklerde aynı anda değişiklik yapmak (örneğin, tüm apache sanal ana bilgisayarları için AllowOverride'ı değiştirmeniz gerektiğini öğrenirsiniz) gerçekten kolay olacaktır. Ayrıca tüm yapılandırma bilgilerini tek bir yerde saklayabilir ve sürüm kontrolü altında tutabilirsiniz. Mükemmel durumda, bozuk ana bilgisayarı atarak, yenisiyle değiştirerek, aynı ana bilgisayar adını ayarlayarak ve gerekli sertifikayı imzalayarak bir donanım arızasını halledebilirsiniz. Diğer her şey Kukla tarafından yapılabilir.

Ancak, iki ana bilgisayar arasında neredeyse hiç yapılandırma paylaşımı yoksa, kukla kullanmak yapılandırmayı el ile yapmaktan daha az verimli olabilir. Ayrıca sunucunun yapılandırmasının yarısını kukla ve diğer yarısını manuel olarak yönetmek pek mantıklı olmayabilir.

Özet : Yöneteceğiniz ana bilgisayarlar için tek biçimli ve yapılandırılmış yapılandırma oluşturabiliyorsanız, Kukla en iyi arkadaşınızdır, ancak her bir hizmeti (ana bilgisayar, sanal ana bilgisayar, veritabanı) özel olarak işlemeniz gerekiyorsa Kukla eklemez çok değer.

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.