Kukla tarafından neler yönetilmemelidir?

Ben genel olarak konfigürasyon yönetimi aracılığıyla yoluma öğrenme ve kullanıyorum kukla herhangi olursa, özellikle uygulamak ve bir sistemin hangi yönlerini merak ediyorum değil kukla yönetilecektir?

Örnek olarak, genellikle sistem isimlerini kuklaların yönetimine vermeden önce zaten ana bilgisayar adlarının oluşturulduğunu kabul ediyoruz. Temel IP bağlantısı, en azından kuklacıya ulaşmak için kullanılan ağda çalışıyor olmalı. Dns bölgesi dosyalarını otomatik olarak oluşturmak için kuklanın kullanılması caziptir, ancak bir işlemi başlatmadan önce DNS ters işaretçilerinin zaten olması gerekirdi veya sertifikalar eğlenceli olacak.

Peki IP konfigürasyonunu kukladan bırakmalı mıyım? Yoksa ilk kez kuklaya başlamadan önce ayarlamalı mıyım ama yine de kukla ile ip adreslerini yönetmeli miyim? Birden fazla IP'li sistemler (örneğin WAN, LAN ve SAN için)?

IPMI ne olacak ? Hepsi olmasa da, hepsini ipmitool ile yapılandırabilir ve konsol erişimine (fiziksel, seri-üstü, uzaktan kumandalı KVM, her neyse) kukla ile otomatik olarak girmesini önleyebilirsiniz . Ancak, her kukla menajeri işletmesindeki durumunu tekrar kontrol etmek bana kulağa hoş gelmiyor ve sisteme erişimi basit bir şekilde başka bir şey yapmadan önce yapmak istediğim bir şey.

Diğer bir hikaye de güncellemeleri yüklemek. Bu özel noktaya girmiyorum, SF ile ilgili birçok soru ve farklı sistem yöneticileri arasında birçok farklı felsefe var. Kendim, kuklanın bazı şeyleri güncellemesine izin vermemeye karar verdim (örneğin sadece ensure => installed) ve daha önce alıştığımız gibi manuel olarak güncellemeler yaptım ; karışım).

Bunlar şu anda aklımda olan birkaç örnek vardı. Sistemin kuklaların ulaşamayacağı bir nokta var mı? Veya, başka bir şekilde, sağlama zamanında neyin ayarlanması gerektiği ve sistemde “statik olarak yapılandırılmış” ile merkezi konfigürasyon yönetimi arasında neler yapılması gerektiği arasındaki hattın neresi olduğunu söyledi.

Genel kural: Konfigürasyon yönetimi kullanıyorsanız, konfigürasyonun yapabileceğiniz her yönünü yönetin. Ne kadar merkezileşirseniz, ortamınızı o kadar kolay ölçeklendirirsiniz.

Spesifik örnekler (sorudan bahsedilir, hepsi "Bu yüzden neden yönetmek istiyorsun" anlatıları):

IP Ağı yapılandırması

Tamam, elbette, rafa düşürmeden önce makinede bir adres / ağ geçidi / NS yapılandırdınız. Yani yapmazsan, geri kalanını yapmak için kuklayı nasıl çalıştırırdın?

Ancak şimdi ortamınıza başka bir ad sunucusu eklediğinizi ve tüm makinelerinizi güncellemeniz gerektiğini söyleyin - yapılandırma yönetim sisteminizin sizin için yapmasını istemiyor musunuz?

Veya şirket edinilen alır ve yeni ana şirket söylemek talepleri onların numaralandırma sistemine uyacak şekilde 10.11.12.0/24 hitap senin 192.168.0.0/24 değişmesidir.

Ya da birdenbire büyük bir devlet sözleşmesi imzalarsınız - Yalnızca yakalamak, IPv6 DOĞRU FREAKIN ' i açmak zorunda kalırsınız ya da anlaşma patlar.

Ağ yapılandırması yönetmek istediğimiz bir şey gibi görünüyor ...

IPMI Yapılandırması

Tıpkı IP adreslerinde olduğu gibi, makineyi rafa koymadan önce ayarladığınızdan eminim - IPMI, uzak konsol vb. Özelliklere sahip herhangi bir makinede etkinleştirmek ve bu yapılandırmaları yapmak çok iyi bir fikirdir. fazla değişmeyin ...

... Yukarıdaki IP Konfigürasyonunda bahsettiğim varsayımsal kazanıma kadar - Bu 192.168-net adreslerini boşaltmak zorunda kalmanızın nedeni, bunun yeni şirket genel giderlerinize göre IPMI ülkesi olmasıdır ve tüm IPMI kartlarınızı güncellemeniz gerekir. ŞİMDİ çünkü birisinin ayrılmış IP alanına ayak basacaklar.

Tamam, burada biraz gerginlik var ama dediğiniz gibi - hepsi yönetilebilir ipmitool, peki neden kukla aleti çalıştırıp diğer şeyleri yaparken konfigürasyonu onaylamıyor? Yani hiçbir şeye zarar vermeyecek, bu yüzden IPMI'yi de dahil edebiliriz ...

Güncellemeler

Yazılım güncellemeleri daha çok gri bir alandır - Örgütümde kuklaları bunun için değerlendirdik ve “fena halde eksik” bulduk, bu yüzden radmindbu amaçla kullanıyoruz. Puppet'in radmind'i arayamamasının bir nedeni yok - Aslında / eğer konfigürasyon yönetimi için Puppet'e taşınırsak tam olarak olacak olan bu!

Burada önemli olan, tüm güncellemelerinizin standart bir şekilde kurulmasını sağlamaktır (organizasyon genelinde standart veya platformlarda standart) - Kukla'ın, güncelleme işleminizi tam olarak test ettiğiniz sürece başlatmaması için hiçbir neden yoktur. Kukla'nın hiçbir şeyi mahvetmemesini sağlamak için her şey.
Kukla'nın kendi başına iyi bir iş çıkarmayacağına karar verdiyseniz, Kukla'nın bu görev için daha uygun bir aleti çağırmamasının da bir nedeni yoktur.

Tekerleği yeniden icat etme.

Evet, 50 kukla sanal kullanıcı kaynağına sahip olabilir ve bunları modüllerinizde gerektiği gibi gerçekleştirebilirsiniz ... ancak yapabilirseniz, LDAP kullanın.

Acı deneyimden konuşuyorum. Her ne kadar ldap burada bir seçenek olmasa da.

Başka bir örnek, sadece DNS kullanmak yerine ana bilgisayar dosyalarını dışarı atmaktır.

• Kukla bir orkestrasyon sistemi değildir. Özellikle:
  • Kukla, VM düzenlemesine uygun değil, çünkü VM'lerde saygı duyulması gereken bir yaşam döngüsü var.
  • Kukla, uygulama yayın yönetimi / karmaşık yükseltmeler için uygun değildir. Bunun için bağımsız kukla koşularından yararlanılabilir, fakat en azından kontrolündeki Kukla değil, sarıcı betikleriniz veya iyi bir insan robotudur.
• Kukla iyi bir kullanıcı yönetim sistemi değildir ( Etkili olması için her kullanıcı girişini, silinmiş kullanıcıları bile yönetmelidir . Öyleyse başka bir çözüm bulun)
• Kukla iyi bir yapılandırma veritabanı değildir (bir tür harici veri tabanı, bir ENC, Hiera veya benzeri bir yapıştırıcı kullanmaya bakın)

Elbette bütün bunları Kukla ile yapabilirsiniz .. ama bu onlar için en iyi çözüm değil. Bazen çekici indirmeli ve bir İngiliz anahtarı aramalısın.

Ancak kukla, bir makinenin temel konfigürasyonunu korumada ve VM yapmanıza ve düzenleme, kullanıcı yönetimi vb.

Çoğunlukla voretaq7 ile aynı fikirdeyim, ancak birkaç uyarı aldım.

• Sistem DHCP kullanmıyorsa, IP adreslemesini nadiren kukla yapıyorum (çoğu "bulut" sağlayıcısının bunu yaptığını farz ediyorum). Ağ yapılandırmalarını kukla ile yaptığım durumlar yaşadım, ancak kukla ile bağlantı kuracak herhangi bir yolu olmadığı için kukla ile düzeltemedim.

• Güncelleme yönetiminin sistem araçlarının elinde olduğuna inandığım konusunda oldukça katıyım ve bir kukla olarak iyileştirilmiş bir cron olarak kullanıldığını görmüyorum.

Benim durumumda, minimal sistem config (Ubuntu): Ruby, Rubygems, build-essential, git, vb. Yükleyen bir bootstrap betiğim var. Oradan, bootstrap betiğim hostname --shortgeçerli olan bir varsayımı yapar ve dener puppet apply /root/infrastructure/puppet/hosts/$( hostname --short ).pp.

Soruna cevap vermek için:

• Komut dosyalarım temel ağ bağlantısını (DNS, IP) kabul eder ve yönetmez veya değiştirmez;
• Komut dosyalarım, makinenin kimliğinin doğru olduğunu varsayar ve değiştirmez;
• Benim komut Yakut / RubyGems / Git mevcut olduğunu varsayalım, ama yok sonradan yönetmek.

Ağ yapılandırması için kukla kullanmanız gerekmediğini düşünün. Genellikle bir kez yapılandırılmış bir şeydir. Ayrıca IP ya da MAC ile bir hata veya kuklaların getireceği bir şeyle karşılaşırsanız bazı şeyler alabilirsiniz.