Ansible kurulumunda provizyon ve konfigürasyon nasıl test edilir?

Tedarik ve konfigürasyon ile ilgili olan Ansible kurulumumuza biraz esneklik kazandırmaya çalışmak.

Bazı şeylerin konfigürasyon tarafında yapılan birkaç test yöntemini anlıyorum ama şeylerin sunumunda testin nasıl uygulanabileceğini ve bu tip uygulamalarda yardımcı olabilecek herhangi bir araç olup olmadığını merak ediyorum.

Şu anda testlerimizin birçoğu seri olarak, "hizmet geldi; vip müsait; bu async görevi bitmiş" gibi şeyler için çok anlamlı olan oyun kitabı boyunca gerçekleştirildi. hem uygulama hem de tedarik katmanında yapılandırma (VM yapılandırması gibi). Ansible'ın konfigürasyon kayması ile çalışmak için en iyi araç olmadığını biliyorum ama kendi görüşlerinizi görmeyi merak ediyorum.

İşlemi tamamen otomatikleştirmek için bir şeyiniz varsa daha da iyi. (Her gün gevşek kaldığını bildiren birkaç çirkin senaryo var).

Not : Şu anda bir reprovision işleminin ortaya çıkabileceği birkaç koşul var (örneğin, yedeklemeden yeniden oluşturma, kritik sistemler sorunu) ancak tipik olarak, bazı yapılandırılabilir yapılandırma görevlerinden geçiyor ve artık bunu düşünmüyor.

Orada bazı seçenekler var ..

Test araçları: Github yıldızlarına göre sıralanmış

• Serverspec - Ruby'nin en popüler aracı Ruby, Ruby'nin Rspec'i üzerine kurulu.
• Goss - YAML, basit, <10MB kendi kendine yeten ikili, son derece hızlı, sistem durumundan testler üretebilir
• Inspec - Ruby, şef adamlar tarafından yapılmış, neredeyse aynı sözdizimi olan gelişmiş bir serverpec olarak düşünün. Sunucu özelliklerinden daha kolay genişletilebilmesi için üretildi
• Testinfra - Python, Ansible envanterini / varsını kullanabilme becerisine sahiptir

Aralarındaki büyük farklar:

Nihayetinde, kendinize karar vermeden önce onlar için bir fikir edinmek için hepsini deneyerek bir gün geçirmenizi öneririm.

• Goss hariç, tüm çerçeveler uzaktaki bir makineye (örneğin, ssh) karşı çalıştırılabilir. Goss sadece yerel olarak veya liman işçisi w / dgoss ile çalışır.
• Tüm çerçeveler sunucuda yerel olarak çalıştırılabilir, ancak Python veya Ruby'nin kurulmasını veya gömülmesini gerektirir. Inspec, gömülü bir yakut versiyonuyla kendi kendine yeten <150 MB'lık bir paket sunar. Goss, dış bağımlılıkları olmayan tek bir <10 MB ikilidir.
• Goss, nagios / sensu çıkışı için destek sağlamıştır, bu da izleme araçlarıyla daha kolay entegrasyon sağlar.
• Goss testleri YAML'ye dayandığından daha basit, fakat daha az esnek olma eğilimindedir. Diğer çerçeveler testler yazmak veya aracın işlevselliğini genişletmek için temel dil Python / Ruby'nin gücünden yararlanmanıza izin verir. (sadelik ve esneklik)
• Goss mevcut sistem durumundan testler oluşturmanıza olanak sağlar
• Bildiğim kadarıyla Testinfra, sorumlu envanter ve değişkenler için yerleşik destek olan tek kişidir
• Inspec Chef tarafından desteklenmektedir

Sürekli / ayrışma testi:

• Şef Uyumluluğu - sunucularınızı ve ücretli ürünlerinizi sürekli olarak test etmek için inspec ile çalışır
• Goss - Kolayca Nagios veya Sensu'ya bağlanabilir. Ayrıca, sunucu testlerini http uç noktası olarak göstermeyi de destekler.

Geliştirme için koşumların test edilmesi:

• mutfak - Test kablo demeti aracı, örneği başlatır, config yönetim kodunu çalıştırır, test takımını çalıştırır. Şef çocuklar tarafından yapılan
• Molekül - Test mutfağına benzer, ancak özellikle sorumlu olanlar için yazılmış

Tam Açıklama: Ben dedikodunun yazarıyım

GÜNCELLEME: InSpec 4.x veya üzeri, karma bir ticari / açık kaynaklı lisans kullanıyor - yorumlara bakın.

Bunun için gördüğüm iki araç InSpec ve ServerSpec . Serverspec üzerine inşa Ruby tabanlı bir araçtır RSpec . InSpec, RSpec ve ServerSpec'ten ilham almıştır.

ServerSpec kullandım. Serin, ama belki de% 100 kararlı değil. Ubuntu'da belirli yazılım sürümleri için testler yaparken sorun yaşadım.

InSpec belgelerini okudum ama henüz derine inmedim. Temelde Serverspec ile aynı şeyi yapar.

Github'un görevine bakılırsa, ServerSpec'teki işler biraz azaldı gibi gözüküyor, oysa InSpec sadece hızlanıyor.

GÜNCELLEME: InSpec 4.x veya üzeri, karma bir ticari / açık kaynaklı lisans kullanıyor - yorumlara bakın.

Ansible gibi konfigürasyon yönetimi araçlarını kullanırken, aracın kendisi konfigürasyonun kaymasını önlemekten sorumlu olacaktır. Belirli bir konfigürasyon ayarlamak için Ansible'ı kullandıktan sonra, Ansible'ın tekrar tekrar çalıştırılması konfigürasyonunuzun sizin tanımladığınız şekilde olmasını sağlayacaktır. Bu aynı zamanda Ansible kodunuzun iddiasız bir şekilde yazılmasını gerektirir.

Yukarıdakiler göz önüne alındığında, Ansible playbook'larınızı bir sunucudan bir döngüde çalıştırarak test provizyonu yapılabilir. Örneğin, bir cron işi ya da Jenkins, oyun kitaplarını her 30 dakikada bir uygulayabilir ve herhangi bir başarısızlığı rapor edebilir. Hata olmaması, yapılandırmanızın kontrol altında olduğu anlamına gelir; hataların olması, sunucuların istediğiniz duruma getirilmesinde bir sorun olduğu anlamına gelir .

Kodunuzun iddiasız olarak yazılmasına güvenemeyeceğiniz bir durumda ve bu nedenle Ansible'ı otomatik olarak bir otomatik sunucudan bir döngüde tekrarlı olarak çalıştıramazsanız, geçici bir çözüm vardır. Yukarıdakiyle aynı şeyi yapabilirsiniz (bir döngüde Ansible'ı çalıştırın) ancak kuru çalışma modunu kullanın . Ansible, değişikliklerin gerekli olduğunu bildirdiği her zaman, Jenkins işi (veya cron işi), size sağlanan yapılandırmanızın değiştirildiğini ve sunucuların istenen durumda olmadığını bildirir .

Ansible kodunuzun aslında yapılması gerektiğini düşündüğünüz şeyi yaptığından emin olmak için Dave Swersky tarafından belirtilen çözümler uygulanır. Hem Inspec ve Serverspec bir doğrulamak araçlardır farklı senin playbooks aslında ne anlama biçimi. Bu tür aletleri test ortamlarında (liman işçisi konteynırları) bile kullanmanın harika bir yolu , çeşitli infra ünite test aletleri arasındaki tüm tutkalı ve mutfak kitaplarınızın / modüllerin / yemek kitaplarınızın yürütülmesini sağlayan kitchen.ci'yi kullanmaktır .

Kitchen.ci başlangıçta Şef yemek kitaplarını test etmek için kullanılıyordu, ancak Ansible ve diğer CM araçları için de eklentiler mevcut .

Test Kitchen, Ansible kodunun test edilmesi için mutfağa duyarlı bir provizyon eklentisine sahiptir. Şef entegrasyonu kadar derin değildir, ancak çoğu durumda bu işi yapar. Ayrıca Ansible test sistemi olan daha yeni bir Molekül projesi var.

Outthentic kullanarak konfigürasyon / altyapı tutarsızlıklarını / sapmalarını takip edebilirsiniz , istenen durumu "düzeltmek" ve istenmeyen değişiklikleri izlemek için ihtiyaç duyduğunuz her seferinde yeniden çalıştırmak için bir test paketi oluşturmak kolaydır.