Yanıtlar:
Ansible'ı hiç kullanmadım ama birkaç haftadan beri, Ansible'ın kabuk komut dosyalarına kıyasla ne kadar iyi olabileceğini anlamaya çalışıyorum. Bu, en azından benim durumumda, akıl almaz reklam kampanyalarının etkili olduğunu kanıtladı! Birçok başarısız denemeden sonra - ki bu, belgelerinin en açık soruyu cevaplamada nasıl başarısız olduğunu kanıtladı - sanırım sonunda:
Şimdi tanıtım videosunu izleyelim ve potansiyel olarak yeni bir kullanıcı olarak Ansible ans tanıtım materyali üzerinden rastgele gidelim. Bunu, yetenekli bir kabuk programcısının hemen raftan ne üretebileceği ile karşılaştıralım.
Sonucum, kabuk komut yazması üzerine Ansible'ın temelde 1 olduğunu söylüyor: Bir sistemin istenen bir durumu kabul ettiğini kontrol etme imkanı, 2. İzleme yeteneklerini içeren bir ödeme sistemi olan Ansible Tower ile entegrasyon yeteneği. Bazı önemli durumlarda, değişmez sunucu modelini uygularken olduğu gibi, nokta 1 muhtemelen çok kullanışlı değildir, bu yüzden liste oldukça zayıftır.
Sonuç olarak, Ansible tarafından kabuk betiğine göre sunulan faydaların, belgelerin sunulduğu haliyle, mevcut modüller tarafından iyi ele alınan birkaç avuç iyimser vaka için mantıklı olabileceği, ancak genel vaka için küçük veya hatta varsayımsal olabileceğidir. Muhtemelen yetenekli bir kabuk programcısı için, bu avantajlar büyük olasılıkla takasın diğer yönleriyle dengelenir.
Ancak bu belki tanıtım malzemesinin ne kadar kötü olduğunu kanıtlar!
Bir yoktur hızlı başlangıç Video . Şunu iddia eden bir sayfa ile başlar: bunlar gerçekten iddia değil, bunlar madde listeleridir, sunumlarda eleştirel yargıları askıya almak için yaygın olarak kullanılan bir eserdir (mantık gösterilmediğinden, eleştirilemez!).
1.1 İnsan tarafından okunabilir otomasyon - Teknik özellikler teknik belgelerdir, nasıl olabilir?
name: upgrade all packages
yum:
name: '*'
state: latest
Bir kabuk betiğinde bulunan ilgili yum çağrısından daha kolay okunabilir mi? Ayrıca, AppleScript ile teması olan herhangi biri, “insan tarafından okunabilir otomasyon” okuduğunda gülmekten ölür.
1.2 Özel bir kodlama becerisine gerek yok - Resmi spesifikasyonlar yazmıyorsa kodlama nedir? Şartlıları, değişkenleri var, kodlama nasıl değil? Ve neden programlayamayacağım, dolayısıyla esnek olamayacak bir şeye ihtiyacım olsun ki? Açıklama mutlu bir şekilde yanlış!
1.3 Düzenli olarak yürütülen görevler - Pekala, belki bazı kodlayıcı meraklıları düzensizlikleri yerine getiren dilleri bilirler , ancak sırayla görevlerini yerine getirmeleri olağanüstü görünmez .
1.4 Hızlı bir şekilde üretken olun - Nitelikli kabuk programcıları şimdi üretkendir. Bu karşı-argüman ilk argüman kadar ciddi.
Eserleri satmak için popüler bir satıcı hilesi, insanları bu eserlerin “gücünü” kazanacaklarına inanmaya kandırmaktır. Otomobiller veya izotonik içecekler için reklam tarihçesinde ikna edici örnekler verilmelidir.
Burada Ansible “uygulama dağıtımı” yapabilir - ancak kabuk betiği kesinlikle “yapılandırma yönetimi” yapar, ancak bu, bir özellik değil aracın amacına ilişkin bir ifadedir ve biraz iddialı görünen, ancak hiçbir işe yaramayan “iş akışı düzenleme” dir. GNU Parallel’in yapabileceklerinin ötesinde .
Sütunu doldurmak için, üç farklı şekilde, bunun sadece ssh'ye ihtiyaç duyduğunu yazdılar , çünkü herkesin bir servet olduğunu ve bu ajanların dünya konfigürasyon yönetimini çevreleyen ile ilgisi olmadığını söyledi !
Videonun geri kalanı, statik kaynak listeleri (sunucular gibi) olan ve Apache'nin aynı anda üç sunucuya nasıl dağıtılacağını gösteren envanterleri tanıtıyor. Bu gerçekten benim çalışma biçimime uymuyor, kaynakların oldukça dinamik olduğu ve bulut sağlayıcım tarafından sağlanan komut satırı araçlarıyla numaralandırılabildiği ve boru |operatörü kullanılarak kabuk işlevlerimin tükettiği şekilde uyuşmuyor . Ayrıca, Apache'yi aynı anda üç sunucuya dağıtmıyorum, bunun yerine, diğerlerinden birinin tam kopyaları olan 3 örneği başlatmak için kullandığım bir ana örnek görüntüsü oluşturuyorum. Dolayısıyla tartışmanın “düzenleyici” kısmı pek uygun görünmüyor.
EC2, Amazon'un bilgi işlem servisidir ve onunla etkileşime girerek bazı Ansible modülleri tarafından desteklenmektedir . (Diğer popüler bulut bilişim sağlayıcıları da sağlanmıştır):
# demo_setup.yml
- hosts: localhost
connection: local
gather_facts: False
tasks:
- name: Provision a set of instances
ec2:
key_name: my_key
group: test
instance_type: t2.micro
image: "{{ ami_id }}"
wait: true
exact_count: 5
count_tag:
Name: Demo
instance_tags:
Name: Demo
register: ec2
Karşılık gelen kabuk betiği JSON ile değiştirilen YAML ile temelde aynı olacaktır:
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --image-id …
}
veya JSON sürümü
provision_a_set_of_instances()
{
aws --output=text ec2 run-instances --cli-input-json "$(provision_a_set_of_instances__json)"
}
provision_a_set_of_instances__json()
{
cat <<EOF
{
"ImageId": …
}
EOF
}
Her iki sürüm de esasen aynıdır, yükün büyük kısmı bir YAML veya JSON yapılarında başlatma değerlerinin sayımıdır.
Bu kılavuzun en büyük kısmı gerçekten ilginç bir özellik göstermiyor: değişkenleri tanıtıyor (IIRC, kabuk komut dosyalarının da değişkenleri var) !, ve bir Ansible modülü mysql'i ele alıyor; XY ayrıcalıklarına sahip ”ve gibi bir şeyle bit
# Create Application DB User
mysql --host "${mysql_host}" --user "${mysql_user}" --password "${mysql_password}" "${mysql_table}" <<EOF
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';
EOF
" XY'de izin verilen ayrıcalıklara sahip bir mysql kullanıcısı nasıl oluşturabilirim ? " ifadesinden sonra arama yaparsınız.
- name: Create Application DB User
mysql_user: name={{ dbuser }} password={{ upassword }}
priv=*.*:ALL host='%' state=present
Fark hala muhtemelen çok anlamlı değil. Bu sayfada ayrıca Ansible'ın bir şablon meta programlama dili olduğunu da keşfettik.
{% for host in groups['monitoring'] %}
-A INPUT -p tcp -s {{ hostvars[host].ansible_default_ipv4.address }} --dport 5666 -j ACCEPT
{% endfor %}
Bunu gördüğümde, gerçekten rahatlık bölgemdeyim. Bilgilendirici diller için bu kadar basit bir meta-programlama, BSD Makefiles ile tam olarak aynı teorik paradigmadır! Hangi yoğun programlamış olur (Ben YAML ayrıştırıcı aracılığıyla benim playbooks koşamam böylece bu pasaj gösterileri bize YAML dosyası ile çalışma sözü kırık olduğunu örn ). Ayrıca, Ansible'ın değerlendirme düzeninin ince sanatını tartışması gerektiğini gösterir: değişkenlerin dilin “bildirimsel kısmında” mı yoksa dilin “zorunlu” meta kısmında mı genişletileceğine karar vermeliyiz. Burada kabuk programlama daha basittir, açık eval veya harici kod kaynak kullanımı dışında meta programlama yoktur . Varsayımsal eşdeğer kabuk alıntı
enumerate_group 'monitoring' | {
while read host; do
…
done
}
Ansible değişkenine göre karmaşıklığı muhtemelen tolere edilebilir: dilde sade, düzenli, sıkıcı yapıları kullanıyor.
Son olarak, Ansible'ın ilk ilginç özelliği olarak ortaya çıkan şeyleri karşılıyoruz : “Ansible kaynakları istenen durum modelleridir. Bu nedenle, hizmetlerin başlatıldığını, paketlerin yüklendiğini veya başka şeylerin test edilmesine gerek yoktur. Ansible, bu şeylerin yasal olarak doğru olmasını sağlayacak sistemdir. Bunun yerine, bu şeyleri oyun kitaplarınızda iddia edin. ”Şimdi biraz ilginç olmaya başlıyor, ancak:
Mevcut modüller tarafından kolayca uygulanan bir avuç standart durum dışında, testi uygulayan bitleri beslemem gerekecek, muhtemelen bazı kabuk komutları içerecektir.
Kurulumların uygunluğunu kontrol etmek, değişmez sunucu modelinin uygulandığı bağlamda çok ilgili olmayabilir: çalışan tüm sistemlerin genellikle bir ana görüntüden üretildiği (örneğin, örnek görüntü veya liman işçisi görüntüsü) - asla güncellenmez - bunun yerine yeni.
Ansible'dan gelen tanıtım materyali , sürdürülebilirlik sorusunu görmezden geliyor. Esasen hiçbir tip sistem bulunmadığından, kabuk komut dosyası çalıştırma JavaScript, Lisp veya Python'un bakım kolaylığı sağlar: kapsamlı yeniden yapılandırmalar, yalnızca kapsamlı bir otomatik testsuite - veya en azından etkileşimli testlere izin veren tasarımlar sayesinde başarılı bir şekilde gerçekleştirilebilir. Bununla birlikte, kabuk kodlaması , sistem konfigürasyonundan ve bakımdan gelen dil frangı olsa da, hemen hemen her programlama dili kabukla arayüze sahiptir. Bu nedenle, gelişmiş kabuk dil bitlerinin çeşitli bitlerini birbirine yapıştırmak için kullanarak, gelişmiş dillerin korunabilirlik avantajından yararlanmak tamamen olanaklıdır. OCaml için Rashell'i yazdım . Bu aslında, alt işlemler için ortak etkileşim kalıplarının bir elini sağlar; bu, yapılandırma komut dosyalarının OCaml'e çevirisini esasen önemsiz kılar.
Ansible'ın yanında, oyun kitaplarının çok zayıf bir yapısı ve bir meta-programlama özelliğinin varlığı, durumu kabuk komut dosyası için olduğu kadar kötü kılar; eksi bir durumda Ansible için birim testleri nasıl yazıldığının açık olmadığı noktalara dikkat çeker. ve geçici olarak daha yüksek seviyeli bir dil sunma argümanı taklit edilemez.
Ansible'ın dokümantasyonu, belirsiz yapılandırma adımları yazmanın gerekliliğine dikkat çeker. Daha doğrusu, yapılandırma adımlarının adım dizisi böylece yazılmalıdır aba basitleştiirlebilir ab , biz tekrar yapılandırma adımı gerekmez yani. Bu, idrarsızlıktan daha güçlü bir durumdur. Ansible, oyun kitaplarının keyfi kabuk komutlarını kullanmalarına izin verdiğinden, Ansible'ın kendisi bu daha güçlü duruma uyulduğunu garanti edemez. Bu sadece programcının disiplinine dayanır.
Bu şekilde koyduğunuzda, Ansible'ın doğasında bazı avantajlar olsa bile, tanıdık araçlar kullanmanın (bu durumda kabuk komut dosyası yazma) faydaları değerlendirilmeli. Bunun kesin bir cevabı olduğunu sanmıyorum.
Eğer takım Ansible'ın sunduğu şeyleri shell ile başarabilirse:
o zaman muhtemelen bildiklerine bağlı kalabiliyorlardı.
Sonuçta, “korumaları” BASH'da uygulayabilirsiniz. Orada çeşitli sunucu yapılandırma görevlerini çözmek için birçok BASH çalışması bulabilirsiniz (temelde% 90 bash kurulum kodu olan herhangi bir Dockerfile). Var olan tüm çözümünüzü bu araçlara aktarmak zorunda kalmadan, Ansible / Salt / Chef-Zero'nun size sunduklarına oldukça yaklaşabilirsiniz.
NIH (burada icat edilmedi) eğilimleri arasında dengeleyici bir hareket ve daha sağlam bir çözüm lehine iyi, yerleşmiş senaryolar çıkarmak.
Akılda tutulması gereken son bir husus: takıma daha fazla insan almayı denediğinizde teknoloji yığınız nasıl ölçülür? Ansible deneyimine sahip insanları bulmak, evde yetiştirilen özel komut dosyası CM aracınızda deneyimi olan kişileri bulmaktan çok daha kolaydır. Bu kesinlikle teknik bir düşünce değil, daha çok kültürel bir konu. Kendi Ansible'ını icat eden tuhaf bir kuruluş mu olmak istiyorsunuz yoksa iş için doğru aracı bulan makul bir kuruluş mu olmak istiyorsunuz? Bu karar yetenek yeteneğini etkiliyor.
Yukarıdaki cevap bir kısmını kapsar ancak önemli unsurlardan birini özlüyor: yakınsak tasarım. Bir süre önce https://coderanger.net/thinking/ adresindeki Chef bağlamında bu konuda bazı kelimeler yazdım, ancak kısa versiyon bir Bash betiğinin bir dizi talimat olduğunu belirtirken, bir Ansible oyun kitabı (veya Chef tarifi, Salt). devlet, vs.) istenen durumun bir açıklamasıdır. Oraya almak istediğiniz adımlardan ziyade istediğiniz durumu belgeleyerek, daha birçok başlangıç durumuyla başa çıkabilirsiniz. Bu uzun zaman önce CFEngine'de belirtildiği gibi Promise Theory'nin kalbi ve biz (config yönetim araçları) o zamandan beri kopyaladığımız bir tasarımdı.
tl; dr Ansible kodu istediğinizi söylüyor, bash kodu nasıl bir şey yapılacağını söylüyor.
Ayrıca, eğlenceli oyun kitaplarınızı uzak ana bilgisayarlarda da çalıştırırken daha az sorun yaşayacağınıza dikkat etmeniz gerekir. Sorumluluk sahibi olmanın asıl nedeni olduğu gibi. Kabuk komut dosyası kullanıyorsanız, scp'ing'i uzaktaki ana bilgisayara komut dosyası yazmanın bir yolunu bulmanız gerekir.
Bu 2019 ve ben sadece birkaç gün sürdürebilir bir öğrenme eğrisine harcadım ve işte mutlak gerçek şu: Ansible belaya değmez.
bitmedi, pencerelerde çalışmıyor ve YAML config ve yanıltıcı hata mesajlarının kombinasyonu gözlerinizin kanamasına neden olur. Neredeyse bilerek korkunç görünüyor ve ben ciddiye demek. Bu açıkça redhat sysadmins sinirli geliştirici yan projesinin ürünü. Muhtemelen bir hipster.
Eğer şartnamenin ötesinde herhangi bir özellik gerektirmiyorsa ve sadece belirli bir işletim sistemi için hazırlık yapıyorsunuzdur. Yazık iyiliği için iyi bir shell.script yazın.
Şu an itibariyle, tüm proje bana noob'ların RTFM'ye söylendiği ve neden birinin grafik ayarlarının yapılandırılması için bir GUI yazamadığını sordukları linux forumlarını hatırlatıyor. Sadece anlamıyorsun değil mi? Pencerelere yapışmalısın ... belki ben çiftleşeceğim .. mutlu VI-ing.
Docker'ı kullanın. Bir şey tercih olarak. Docker, fevkalade basit ve güçlü.
Ama önceden var olan kalay üzerinde kesinlikle provizyon yapmanız gerekiyorsa ne olacak? Gerçek alternatifler neler?
Şey ... henüz yok. Ama sana söz veriyorum, suçlu iyileşmezse, yakında olacak. Çünkü hayranların zorlaması ne kadar zor olursa olsun, başarısızlıklarını affetmek ... çaba için 10 üzerinden 5'tir.
Bir bash betiği SCP ve kendinize sorun kurtarın.