Kukla aslında çok uyarılı ortamlara, uyarılarla oldukça iyi bir şekilde ödünç verilir. En önemlisi? Kuklanın bir çok kısmı merkezileşmeyi sever. Sertifika yetkilisi, envanter ve gösterge tablosu / rapor hizmetleri, dosya kâğıtları ve depolanan yapılandırmalar - hepsi, konuşacakları tek bir yer olan bir kurulumda en iyi durumdadır (veya yalnızca gerektirir).
Bununla birlikte, birincil sitenizi kaybettiğinizde bazı işlevlerin zarif bir şekilde kaybolması konusunda sorun yaşıyorsanız, çok hareketli bir ortamda çalışan bu hareketli parçaların çoğunu almak oldukça uygulanabilir.
Bir master'a düğüm raporlaması için temel işlevsellik ile başlayalım:
Modüller ve Manifestler
Bu bölüm basit. Sürüm onları kontrol eder. Eğer bir dağıtılmış versiyon kontrol sistemiyse, sadece merkezileştirin ve senkronize edin ve yük devretme yerinde itme / çekme akışınızı gerektiği gibi değiştirin. Subversion ise, muhtemelen svnsyncyük devretme sitenize repo yapmak istersiniz .
Sertifika yetkilisi
Buradaki bir seçenek, sertifika yetkilisi dosyalarını yöneticiler arasında eşitlemektir, böylece hepsi aynı kök sertifikayı paylaşır ve sertifikaları imzalayabilir. Bu beni her zaman "yanlış yapmak" olarak etkiledi;
- Bir kaptan gerçekten başka bir kaptandan gelen bağlantı için müşteri onayında sunulan kendi sertifikasını geçerli olarak görmeli mi?
- Bu, envanter hizmeti, gösterge tablosu vb. İçin güvenilir bir şekilde çalışır mı?
- Ek geçerli DNS alt adlarını yolun altına nasıl eklersiniz?
Dürüst olmak gerekirse, bu seçenek üzerinde kapsamlı bir test yaptığımı söyleyemem, çünkü korkunç görünüyor. Ancak, Kukla Labs Not başına bu seçeneği teşvik etmek aramıyorsanız görünüyor burada .
Yani, bırakılan şey merkezi bir CA ustasına sahip olmak. Tüm istemciler ve diğer yöneticiler CA sertifikasını ve CRL'yi önbelleğe aldıklarından (CRL'yi gerektiği kadar yenilemese de) CA kapalı olduğunda tüm güven ilişkileri çalışmaya devam eder, ancak yeni sertifikaları imzalayamazsınız. birincil siteyi yedekler veya yedek sistemdeki yedeklemelerden CA yöneticisini geri yüklersiniz.
CA olarak davranmak için bir ana öğe seçeceksiniz ve diğer tüm yöneticilerin devre dışı bırakmasını sağlayabilirsiniz:
[main]
ca_server = puppet-ca.example.com
[master]
ca = false
Ardından, bu merkezi sistemin sertifikayla ilgili tüm trafiği almasını istersiniz. Bunun için birkaç seçenek var;
SRVTüm aracı düğümlerini CA için doğru yere yönlendirmek üzere 3.0'da yeni kayıt desteğini kullanın -_x-puppet-ca._tcp.example.com- Tüm aracılardan
ca_serveryapılandırma seçeneğini ayarlayınpuppet.conf
Aracılardan gelen CA ile ilgili tüm isteklerin doğru yöneticiye doğru şekilde gönderilmesini sağlayın. Örneğin, tüm master'larınızı Yolcu aracılığıyla Apache'de çalıştırıyorsanız, bunu CA olmayanlar üzerinde yapılandırın:
SSLProxyEngine On
# Proxy on to the CA.
ProxyPassMatch ^/([^/]+/certificate.*)$ https://puppet-ca.example.com:8140/$1
# Caveat: /certificate_revocation_list requires authentication by default,
# which will be lost when proxying. You'll want to alter your CA's auth.conf
# to allow those requests from any device; the CRL isn't sensitive.
Ve bunu yapmalı.
Yan hizmetlere geçmeden önce, bir yan not;
Ana Sertifikalar için DNS Adları
Bence bu, 3.0'a geçmek için en zorlayıcı sebep. Diyelim ki bir düğümü "herhangi bir çalışan usta" ya yönlendirmek istiyorsunuz.
2.7 altında, genel bir DNS adına ihtiyacınız olacak puppet.example.comve tüm ustaların sertifikalarında buna ihtiyacı var. Bu dns_alt_names, yapılandırmalarında ayar yapmak, master olarak yapılandırılmadan önce sahip oldukları sertifikayı yeniden vermek, listeye yeni bir DNS adı eklemeniz gerektiğinde sertifikayı yeniden vermek (birden çok DNS adının acentaları kendi alanlarında ustaları tercih edin) .. çirkin.
3.0 ile SRVkayıtları kullanabilirsiniz . Tüm müşterilerinize bunu verin;
[main]
use_srv_records = true
srv_domain = example.com
Ardından, ustaları için gerekli özel certs - Sadece için yeni bir kayıt eklemek SRVde RR _x-puppet._tcp.example.comsen seti ve bu gruptaki canlı ustası. Daha da iyisi, ana seçim mantığını daha sofistike hale getirebilirsiniz; "herhangi bir çalışma ustası, ancak sitenizde olanı tercih edin" SRVfarklı siteler için farklı kayıt kümeleri oluşturarak ; gerek yok dns_alt_names.
Raporlar / Gösterge Tablosu
Bu en iyi şekilde merkezileştirilir, ancak birincil siteniz kapalıyken onsuz yaşayabilirseniz sorun olmaz. Sadece raporlarınızı koymak için tüm ustalarınızı doğru yerle yapılandırın.
[master]
reports = http
reporturl = https://puppetdash.example.com/reports/upload
..ve hazırsınız. Rapor yüklenememesi yapılandırma çalışması için ölümcül değildir; sadece kontrol paneli sunucusunun tostu kaybolur.
Gerçek Envanter
Gösterge tablonuza yapıştırılmış bir başka güzel şey de envanter hizmetidir. İle facts_terminuskarşı sette restmerkezi envanter hizmet aşağı olduğunda belgelerinde önerildiği şekilde, bu aslında yapılandırma çalışır kırarım. Buradaki hile inventory_service, zarif olmayan başarısızlığa izin veren merkezi olmayan ustaların sonunu kullanmaktır.
facts_terminus = inventory_service
inventory_server = puppet-ca.example.com
inventory_port = 8140
Merkezi envanter sunucunuzun, envanter verilerini ActiveRecord veya PuppetDB aracılığıyla depolayacak şekilde ayarlamasını sağlayın ve hizmet kullanılabilir olduğunda her zaman güncel kalmalıdır.
Yani - geri yükleninceye kadar yeni bir düğümün sertifikasını imzalamak için CA'yı bile kullanamayacağınız güzel bir barebone yapılandırma yönetimi ortamına girme konusunda sorun yaşıyorsanız, bu gerçekten işe yarayabilir - gerçekten güzel olsa da bu bileşenlerden bazıları olsaydı dağıtıldı için biraz daha samimi .