Kukla ve Şef araçları için yeni. Yaptıkları iş, kabuk komut dosyasıyla yapılabilir gibi görünüyor. Belki bunlar gelene kadar kabuk betiklerinde yapıldı.
Daha okunaklı olduklarına katılıyorum. Ancak, sadece okunabilir olmanın yanı sıra kabuk senaryolarına göre başka avantajlar var mı?
Yanıtlar:
Etki alanına özgü bir dil, yazdığınız kod miktarında büyük bir fark yaratır. Örneğin, aralarında çok fazla fark olmadığını iddia edebilirsiniz:
chmod 640 /my/file
ve
file { "/my/file":
mode => 640,
}
ancak bunlar arasında büyük bir fark var:
FILE=/my/file
chmod 640 $FILE
chown foo $FILE
chgrp bar $FILE
wget -O $FILE "http://my.puppet.server/dist/$FILE"
# where the URL contains "Hello world"
ve
file { "/my/file":
mode => 640,
owner => foo,
group => bar,
content => "Hello world",
}
Takım başarısız olursa ne olur? Senaryonuz bunu nasıl idare edecek? Ve betiğinizde bundan sonra $ FILE'in doğru içeriğe sahip olmasını gerektiren bir şey varsa ne olur?
echo "Hello world" > $FILEİlk örnekte komut dosyasının istemcide çalıştırılması gerektiği halde kuklanın hepsini sunucuda derlemesi dışında birinin bir senaryoya girebileceğini savunabilirsiniz . Dolayısıyla, içeriği değiştirirseniz, yalnızca sunucuda değiştirmeniz gerekir ve yerleştirmek istediğiniz kadar sistem için onu değiştirir. Ve kukla bağımlılıkları yönetir ve sizin için sorunları otomatik olarak aktarır.
Karşılaştırma yok - uygun yapılandırma yönetimi araçları size zaman ve karmaşıklık kazandırır. Ne kadar çok yapmaya çalışırsanız, o kadar fazla kabuk senaryosu yetersiz görünür ve kukla ile yaparak daha fazla çaba harcayacaksınız.
Bu popüler olmayan bir fikir olacaktır, ancak konfigürasyon yönetim sistemlerinin mutlaka daha iyi olması gerekmez. Bazen basit gerçekten en iyisidir.
Seçtiğiniz yapılandırma sistemiyle ilgili kesin bir öğrenme eğrisi ve idari ek yük vardır. Sonuçta bir bağımlılık getirdiniz. Herhangi bir otomasyonda olduğu gibi, konuşlandırılmış yapılandırmalarda güvenliğin korunmasına da dikkat etmelisiniz.
Konfigürasyon yönetimini devreye aldığımız ve takılıp kaldığımız birkaç örnek var. Her zaman tekrarlayan konfigürasyona sahip çok sayıda sistem olduğu ve konfigüre edilebilir çerez kesici dağıtımları gerçekleştirme ihtiyacı olduğu zaman olmuştur.
Kendi soruna cevap verdin.
Otomasyon daha ölçeklenebilir ve resmileştiriliyor . Kukla ve Şef bugünlerde standart olarak kabul edilir ( iş ilanlarına bakın ).
Cobbled-birlikte kabuk komut onların yeri vardır, ama onlar değil DevOps hareketi bağlamında ölçeklenebilir. Okunabilirlik bunun bir parçası.
Şef çok daha kolay yönetmek ve kolaylaştırır versiyonu manuel ftp veya bir unstandardized şekilde organize kabuk komut bir demet scp'yi zorunda vs özellikle bulut ortamının her tür karmaşık bir altyapının kurulum. Kaç tane bağımlılığı yönetmeniz gerektiğine bağlı olarak, bu kazanmanın büyüklüğü büyük ölçüde değişebilir ve bir CM çözümüne geçme kararı birçok insan için açık olmayan bir karardır.
Şef'in asıl (çoğu zaman ertelenmeyen) yararı azaptır . Örtüşen menfaatlerle çalışan tariflerin kombinasyonundan bağımsız olarak bir kaynağın durumundan emin olabilmek kabuk betiği konfigürasyonuna göre çok büyük bir avantajdır. Şimdi yapılandırma için kabuk komut dosyalarınız varsa, kaç tane istenmeyen / istenmeyen sonuçlar olmadan kaç kez çalıştırılabileceğini kendinize sorun.
Uygun bir CM çözümü, platformlar arası otomasyon ve ekip işbirliğini basitleştirerek ölçekte başarı sağlanmasına yardımcı olur. Tüm bunları, iyi düzenlenmiş, iyi bakımlı, sürümlü bir kabuk komut dosyası grubu ile gerçekleştirmek mümkün olsa da; Kendine "neden" diye sormalısın. Aşçı / Kukla ve benzer teknolojiler ortaya çıktı çünkü bir grup yetenekli SysOps bu sorunları tekrar tekrar çözmek zorunda kalmadan yoruldu ve bize daha iyi bir seçenek sunmak için yola çıktı.
Kukla ve Şef gibi modern konfigürasyon yönetimi araçları , yapılandırılmış bir sunucuyu elde etmek için gerekli faaliyetler hakkında endişelenmek yerine sistemin durumunu tanımlamanıza izin verir .
Örneğin, chmod komutunuz, dosyanın var olduğunu, dosyanın sahibi olan kullanıcının var olduğunu, dizinlerin oluşturulduğunu vb. Varsayar. Bu nedenle senaryonuz tüm bu önkoşulları dikkate almalıdır.
Durum tabanlı konfigürasyon yönetimi araçları basittir: sadece dosyanın doğru izinlere sahip olmasını önemsiyorsunuz. Bunun nasıl başarıldığı, aracın problemidir.
chmoddosya, dosya tarafından oluşturulduğundan ya da komut dosyası tarafından varolduğunu test ettiğinden var olduğunu varsaymıyor.
Sunucular sizin için tek kullanımlıksa veya bir seferde birkaç kişiden daha fazla ayağa kalkarsanız, tam gelişmiş bir CM sistemi gereksinimlerinizi bir dizi kabuk betiğinden daha iyi karşılayacaktır.
Yapım ihtiyaçlarınız mütevazı ise (veya organik serbest alanlı adil ticaret sunucularını ustaca elden yapmak gibi), o zaman basit tutun.
Şahsen, şefi geçmiş bir konserde yoğun bir şekilde kullandıktan sonra, bu konserde 'basit tutmaya' çalıştım, ama şefin sağladığı ilkelleri, soyutlamaları ve gücü gerçekten özledim. İhtiyacınız olanı bir kaç kabuk komutundan elde edebileceğiniz bir duruma bile sahip olsanız bile, bunları 'komut' bloğu ile çalıştırabilirsiniz, kabuk komutlarınızı tam olarak onları kabuğa yazdığınız gibi girebilirsiniz.
Bununla birlikte, Chef'i bir sunucusuz çalıştırabilirsiniz (chef-solo) ve Puppet'in bir analogu olduğundan eminim, yine de merkezi bir sunucuyu çalıştırmadan başkalarının yemek kitabı ve tariflerini kaldırabilirsin.
Diğer bir yarar topluluktur: birçok insan var (çoğu sizden daha akıllı ve / veya daha deneyimli olacak). Şahsen, işimi benim için bir başkası benim için yaptığında, genellikle benim yaptığımdan daha kapsamlı olarak seviyorum.
Bir kabuk betiği tabanlı sunucu otomasyon çerçevesi oluşturdum: https://github.com/myplaceonline/posixcube
Bu tür bir projeyi ilk yapan ben değilim, ancak ihtiyaçlarımı karşılayacak bir şey bulamadım, bu yüzden başkalarının bunu faydalı bulabileceğini düşündüm. Sadece Chef ile deneyimim oldu, ancak Ansible ve diğerlerine bakmaya başladığımda, kabuk senaryolarına bir şans vermek istedim ve sonucu çok beğendim.