Başkalarının Ansible koduyla ilgili birçok inceleme yapıyorum ve kendim de çok şey yazıyorum. Hataları (hem başkalarının hem de benim) analiz ederken ve bir dizi röportaj sırasında, Ansible kullanıcılarının yaptığı ana hatayı fark ettim - temel konularda uzmanlaşmadan karmaşık şeylere giriyorlar.

Bu evrensel adaletsizliği düzeltmek amacıyla, Ansible'ı zaten bilenler için bir giriş yazmaya karar verdim. Sizi uyarıyorum, bu bir adamın yeniden anlatımı değil, bu çok fazla mektup içeren ve hiç resim içermeyen uzun bir okuma.

Okuyucunun beklediği seviye, birkaç bin satır yamla'nın zaten yazılmış olması, bir şeyin zaten üretimde olması, ancak "bir şekilde her şeyin çarpık olmasıdır."

Названия

Ansible kullanıcısının yaptığı en büyük hata, bir şeyin ne dendiğini bilmemektir. İsimleri bilmiyorsanız belgelerin ne dediğini anlayamazsınız. Canlı bir örnek: Bir röportaj sırasında Ansible'da çok şey yazdığını söyleyen bir kişi, "Bir başucu kitabı hangi unsurlardan oluşur?" sorusuna cevap veremedi. Ve ben "oyun kitabının oyundan oluştuğu yönünde bir yanıt bekleniyordu" dediğimde, "bunu kullanmıyoruz" şeklindeki lanet yorum geldi. İnsanlar Ansible'ı para için yazıyor ve oyun kullanmıyorlar. Aslında kullanıyorlar ama ne olduğunu bilmiyorlar.

O halde basit bir şeyle başlayalım: Adı ne? Belki bunu biliyorsunuzdur, belki de bilmiyorsunuz çünkü belgeleri okurken dikkat etmediniz.

ansible-playbook oyun kitabını çalıştırır. Başucu kitabı, içinde şunun gibi bir şey bulunan, yml/yaml uzantılı bir dosyadır:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Bu dosyanın tamamının bir başucu kitabı olduğunun zaten farkına vardık. Rollerin nerede olduğunu, görevlerin nerede olduğunu gösterebiliriz. Peki oyun nerede? Peki oyun ile rol veya oyun kitabı arasındaki fark nedir?

Hepsi belgelerde var. Ve bunu özlüyorlar. Yeni başlayanlar - çünkü çok fazla şey var ve her şeyi aynı anda hatırlamayacaksınız. Deneyimli - çünkü "önemsiz şeyler". Deneyimliyseniz, bu sayfaları en az altı ayda bir yeniden okuyun; kodunuz sınıfında lider olacaktır.

Bu yüzden şunu unutmayın: Başucu Kitabı, oyun ve oyunlardan oluşan bir listedir. import_playbook.
Bu bir oyun:

- hosts: group1
  roles:
    - role1

ve bu da başka bir oyun:

- hosts: group2,group3
  tasks:
    - debug:

Oyun nedir? Neden o?

Oyun, bir oyun kitabı için önemli bir öğedir, çünkü oyun ve yalnızca oyun, rollerin ve/veya görevlerin bir listesini, bunların yürütülmesi gereken ana bilgisayarların bir listesiyle ilişkilendirir. Belgelerin derin derinliklerinde şunlardan bahsedebilirsiniz: delegate_to, yerel arama eklentileri, ağa özel ayarlar, atlama ana bilgisayarları vb. Görevlerin gerçekleştirildiği yeri biraz değiştirmenize izin veriyorlar. Ama unut gitsin. Bu akıllı seçeneklerin her birinin çok özel kullanımları vardır ve kesinlikle evrensel değildirler. Ve herkesin bilmesi ve kullanması gereken temel şeylerden bahsediyoruz.

Eğer “bir yerde” “bir şey” yapmak istiyorsanız oyun yazarsınız. Bir rol değil. Modüller ve delegeler içeren bir rol değil. Alırsın ve oyun yazarsın. Burada, hosts alanında nerede yürütüleceğini ve roller/görevlerde nelerin yürütüleceğini listelersiniz.

Basit, değil mi? Aksi nasıl olabilir?

İnsanların bunu oyun yoluyla değil de yapma arzusunun olduğu karakteristik anlardan biri, "her şeyi ayarlayan rol"dür. Hem birinci türdeki sunucuları hem de ikinci türdeki sunucuları yapılandıran bir role sahip olmak istiyorum.

Arketipsel bir örnek izlemedir. İzlemeyi yapılandıracak bir izleme rolüne sahip olmak istiyorum. İzleme rolü, izleme ana bilgisayarlarına atanır (oyuna göre). Ancak, izleme için, izlediğimiz ana bilgisayarlara paketleri teslim etmemiz gerektiği ortaya çıktı. Neden temsilci kullanmıyorsunuz? Ayrıca iptables'ı da yapılandırmanız gerekir. temsilci? Ayrıca izlemeyi etkinleştirmek için DBMS'ye yönelik bir yapılandırma yazmanız/düzeltmeniz gerekir. temsilci! Ve eğer yaratıcılık eksikse, o zaman bir delegasyon yapabilirsiniz include_role grup listesinde zorlayıcı bir filtre kullanan iç içe geçmiş bir döngüde ve içinde include_role daha fazlasını yapabilirsin delegate_to Tekrar. Ve uzaklaşıyoruz...

İyi bir dilek - "her şeyi yapan" tek bir izleme rolüne sahip olmak - bizi çoğu zaman tek bir çıkış yolunun olduğu tam bir cehenneme götürür: her şeyi sıfırdan yeniden yazmak.

Burada hata nerede yapıldı? X sunucusunda "x" görevini yapmak için Y sunucusuna gitmeniz ve orada "y" yapmanız gerektiğini keşfettiğiniz anda, basit bir alıştırma yapmanız gerekiyordu: gidip oyun yazın, Y sunucusunda y bunu yapar. "X"e bir şey eklemeyin, sıfırdan yazın. Sabit kodlanmış değişkenlerle bile.

Yukarıdaki paragraflarda her şeyin doğru söylendiği anlaşılıyor. Ama bu senin durumun değil! Çünkü yeniden kullanılabilir, DRY ve kütüphane benzeri kod yazmak istiyorsunuz ve bunun nasıl yapılacağına dair bir yöntem aramanız gerekiyor.

İşte burada başka bir ciddi hata gizleniyor. Pek çok projeyi tolere edilebilir bir şekilde yazılmış olmaktan (daha iyi olabilirdi, ancak her şey işe yarıyor ve bitirmek kolay) yazarın bile çözemeyeceği tam bir dehşete dönüştüren bir hata. İşe yarıyor, ama Tanrı herhangi bir şeyi değiştirmenizi yasakladı.

Hata şudur: rol bir kütüphane işlevidir. Bu benzetme o kadar çok güzel başlangıcı mahvetti ki izlemesi gerçekten üzücü. Rol bir kitaplık işlevi değil. Hesaplama yapamıyor ve oyun düzeyinde kararlar alamıyor. Bana oyunun hangi kararları verdiğini hatırlatır mısın?

Teşekkürler, haklısın. Play, hangi ana bilgisayarlarda hangi görevlerin ve rollerin yerine getirileceğine dair bir karar verir (daha doğrusu bilgi içerir).

Bu kararı bir role devrederseniz ve hatta hesaplamalarla kendinizi (ve kodunuzu ayrıştırmaya çalışacak kişiyi) sefil bir varoluşa mahkum edersiniz. Rol nerede gerçekleştirileceğine karar vermez. Bu karar oyunla verilir. Rol kendisine söyleneni, söylendiği yerde yapar.

Ansible'da programlama yapmak neden tehlikelidir ve COBOL'un Ansible'dan neden daha iyi olduğunu bu bölümde değişkenler ve jinjadan bahsedeceğiz. Şimdilik bir şey söyleyelim; her hesaplamanız arkasında küresel değişkenlerdeki değişikliklerin silinmez bir izini bırakıyor ve bu konuda hiçbir şey yapamazsınız. İki "iz" kesiştiği anda her şey kaybolmuştu.

Titreyenler için not: Rol kesinlikle kontrol akışını etkileyebilir. Yemek yemek delegate_to ve makul kullanımları vardır. Yemek yemek meta: end host/play. Ancak! Temel bilgileri öğrettiğimizi hatırlıyor musun? Unuttum delegate_to. En basit ve en güzel Ansible kodundan bahsediyoruz. Okunması kolay, yazılması kolay, hata ayıklaması kolay, test edilmesi kolay ve tamamlanması kolay. Yani bir kez daha:

play ve only play hangi ana bilgisayarların neyin yürütüleceğine karar verir.

Bu bölümde oyun ve rol arasındaki karşıtlığı ele aldık. Şimdi görevler ve rol ilişkisi hakkında konuşalım.

Görevler ve Roller

Oyunu düşünün:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

Diyelim ki foo yapmanız gerekiyor. Ve öyle görünüyor foo: name=foobar state=present. Bunu nereye yazmalıyım? önceden mi? postalamak? Bir rol oluşturulsun mu?

...Peki görevler nereye gitti?

Tekrar temel bilgilerle başlıyoruz: oyun cihazı. Bu konunun üzerinde durursanız, oyunu diğer her şeyin temeli olarak kullanamazsınız ve sonucunuz "sarsıntılı" olur.

Oyun cihazı: ana bilgisayar yönergesi, oyunun kendisi ve pre_tasks ayarları, görevler, roller, post_tasks bölümleri. Oyun için geri kalan parametreler artık bizim için önemli değil.

Görev ve rollerle bölümlerinin sırası: pre_tasks, roles, tasks, post_tasks. Anlamsal olarak yürütme sırası şu şekildedir: tasks и roles net değilse, en iyi uygulamalar bir bölüm eklediğimizi söylüyor tasks, ancak değilse roles. Eğer varsa roles, ardından tüm ekli görevler bölümlere yerleştirilir pre_tasks/post_tasks.

Geriye kalan tek şey, her şeyin anlamsal olarak açık olmasıdır: ilk önce pre_taskso zaman roleso zaman post_tasks.

Ancak hala şu soruyu cevaplamış değiliz: Modül çağrısı nerede? foo yazmak? Her modül için bir rolün tamamını yazmamız gerekiyor mu? Yoksa her şeyde kalın bir role sahip olmak daha mı iyi? Ve eğer bir rol değilse, o zaman nereye yazmalıyım - öncesinde mi yoksa sonrasında mı?

Bu soruların mantıklı bir cevabı yoksa, bu, sezgi eksikliğinin, yani aynı "sallantılı temellerin" bir işaretidir. Hadi çözelim. İlk olarak bir güvenlik sorusu: Eğer oyun pre_tasks и post_tasks (ve hiçbir görev veya rol yok), o zaman ilk görevi şu andan itibaren gerçekleştirirsem bir şeyler bozulabilir mi? post_tasks Bunu sonuna kadar taşıyacağım pre_tasks?

Elbette sorunun üslubu kırılacağını ima ediyor. Ama tam olarak ne?

... İşleyiciler. Temelleri okumak önemli bir gerçeği ortaya çıkarır: her bölümden sonra tüm işleyiciler otomatik olarak temizlenir. Onlar. tüm görevler pre_tasks, ardından bilgilendirilen tüm işleyiciler. Daha sonra rollerde bildirilen tüm roller ve tüm işleyiciler yürütülür. Sonrasında post_tasks ve onların idarecileri.

Böylece, bir görevi sürüklerseniz post_tasks в pre_tasks, o zaman potansiyel olarak işleyici yürütülmeden önce onu yürüteceksiniz. örneğin, eğer pre_tasks web sunucusu kurulup yapılandırılmıştır ve post_tasks kendisine bir şey gönderilir, ardından bu görevi bölüme aktarın pre_tasks "Gönderme" sırasında sunucunun henüz çalışmamasına ve her şeyin bozulmasına yol açacaktır.

Şimdi tekrar düşünelim, neden ihtiyacımız var? pre_tasks и post_tasks? Örneğin, rolü yerine getirmeden önce gerekli olan her şeyi (işleyiciler dahil) tamamlamak için. A post_tasks rollerin yürütülmesinin sonuçlarıyla (işleyiciler dahil) çalışmamıza izin verecektir.

Zeki bir Ansible uzmanı bize bunun ne olduğunu söyleyecektir. meta: flush_handlersancak oyundaki bölümlerin yürütülme sırasına güvenebilirsek neden floş_işleyicilerine ihtiyacımız var? Dahası, meta:flush_handlers kullanımı bize yinelenen işleyicilerle beklenmedik şeyler verebilir, kullanıldığında garip uyarılar verebilir. when у block vesaire. Ansible'ı ne kadar iyi tanırsanız, "zor" bir çözüm için o kadar fazla nüansı adlandırabilirsiniz. Ve basit bir çözüm (ön/roller/sonra arasında doğal bir ayrım kullanmak) nüanslara neden olmaz.

Ve 'foo'ya geri dönelim. Nereye koymalıyım? Öncesinde, sonrasında veya rollerde mi? Açıkçası bu, foo için işleyicinin sonuçlarına ihtiyacımız olup olmadığına bağlıdır. Eğer orada değilse, foo'nun ana kod gövdesinden önce ve sonra görevleri yürütmek için önce veya sonra yerleştirilmesine gerek yoktur - bu bölümlerin özel bir anlamı vardır.

Artık "rol veya görev" sorusunun cevabı halihazırda oyunda olana iniyor - eğer orada görevler varsa, bunları görevlere eklemeniz gerekir. Roller varsa, bir rol oluşturmanız gerekir (tek bir görevden bile olsa). Görev ve rollerin aynı anda kullanılmadığını hatırlatayım.

Ansible'ın temellerini anlamak, görünüşte zevkle ilgili sorulara makul yanıtlar sağlar.

Görevler ve roller (ikinci bölüm)

Şimdi bir taktik kitabı yazmaya yeni başladığınızda durumu tartışalım. Foo, bar ve baz yapmalısın. Bu üç görev mi, tek bir rol mü yoksa üç rol mü? Soruyu özetlemek gerekirse: Rolleri yazmaya hangi noktada başlamalısınız? Görev yazabiliyorken rol yazmanın ne anlamı var?... Rol nedir?

En büyük hatalardan biri (bundan daha önce bahsetmiştim), rolün bir programın kütüphanesindeki fonksiyon gibi olduğunu düşünmektir. Genel bir işlev açıklaması neye benzer? Giriş argümanlarını kabul eder, yan nedenlerle etkileşime girer, yan etkiler yaratır ve bir değer döndürür.

Şimdi dikkat. Rolde bundan ne yapılabilir? Her zaman yan etkiler diyebilirsiniz, tüm Ansible'ın özü budur - yan etkiler yaratmak. Yan nedenleri var mı? İlköğretim. Ancak "bir değer ilet ve onu geri gönder" ile işe yaramıyor. İlk olarak, bir role değer aktaramazsınız. Rolün vars bölümünde, ömür boyu oyun boyutuna sahip global bir değişken ayarlayabilirsiniz. Rol içinde kullanım ömrü boyunca global bir değişken ayarlayabilirsiniz. Veya ömür boyu taktik kitaplarıyla bile (set_fact/register). Ancak "yerel değişkenlere" sahip olamazsınız. "Bir değer alıp" "geri veremezsiniz".

Asıl mesele bundan kaynaklanıyor: Ansible'da yan etkilere neden olmadan bir şey yazamazsınız. Global değişkenleri değiştirmek her zaman bir fonksiyon için bir yan etkidir. Örneğin Rust'ta global bir değişkeni değiştirmek unsafe. Ve Ansible'da bir rolün değerlerini etkilemenin tek yöntemi budur. Kullanılan kelimelere dikkat edin: "role bir değer iletmek" değil, "rolün kullandığı değerleri değiştirmek". Roller arasında izolasyon yoktur. Görevler ve roller arasında izolasyon yoktur.

Toplam: rol bir işlev değildir.

Rolün nesi iyi? İlk olarak, rolün varsayılan değerleri vardır (/default/main.yaml), ikincisi, rolün dosyaları depolamak için ek dizinleri vardır.

Varsayılan değerlerin faydaları nelerdir? Çünkü Maslow'un piramidinde, Ansible'ın oldukça çarpık değişken öncelikler tablosunda, rol varsayılanları en düşük önceliklidir (Ansible komut satırı parametreleri hariç). Bu, varsayılan değerleri sağlamanız gerekiyorsa ve bunların envanterden veya grup değişkenlerinden gelen değerleri geçersiz kılmalarından endişe etmiyorsanız, rol varsayılanlarının sizin için tek doğru yer olduğu anlamına gelir. (Biraz yalan söylüyorum - daha fazlası var |d(your_default_here), ancak sabit yerlerden bahsedersek, o zaman yalnızca rol varsayılanları).

Rollerin başka nesi harika? Çünkü onların kendi katalogları var. Bunlar hem sabit (yani rol için hesaplanmış) hem de dinamik (bir model veya bir anti-model vardır) değişkenlere yönelik dizinlerdir. include_vars ile {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Bunlar dizinlerdir files/, templates/. Ayrıca kendi modüllerinize ve eklentilerinize sahip olmanızı sağlar (library/). Ancak, bir oyun kitabındaki görevlerle karşılaştırıldığında (tüm bunlara da sahip olabilir), buradaki tek avantaj, dosyaların tek bir yığına değil, birkaç ayrı yığına atılmasıdır.

Bir ayrıntı daha: Yeniden kullanılabilecek roller oluşturmayı deneyebilirsiniz (galaksi aracılığıyla). Koleksiyonların ortaya çıkışıyla birlikte rol dağılımının neredeyse unutulduğu düşünülebilir.

Dolayısıyla rollerin iki önemli özelliği vardır: varsayılanlara sahiptirler (benzersiz bir özellik) ve kodunuzu yapılandırmanıza olanak tanırlar.

Asıl soruya dönersek: Görevler ne zaman yapılmalı ve roller ne zaman yapılmalı? Bir oyun kitabındaki görevler çoğunlukla ya önceki/sonraki rollerin "yapıştırıcısı" olarak ya da bağımsız bir yapı öğesi olarak kullanılır (bu durumda kodda hiçbir rol olmamalıdır). Rollerle karıştırılmış bir yığın normal görev, kesin bir özensizliktir. Belirli bir stile (bir göreve veya role) bağlı kalmalısınız. Roller, varlıkların ve varsayılanların ayrılmasını sağlar; görevler, kodu daha hızlı okumanıza olanak tanır. Genellikle rollere daha fazla "sabit" (önemli ve karmaşık) kod yerleştirilir ve yardımcı komut dosyaları görev tarzında yazılır.

Bir görev olarak import_role yapmak mümkündür, ancak bunu yazarsanız, bunu neden yapmak istediğinizi kendi güzellik anlayışınıza açıklamaya hazır olun.

Zeki bir okuyucu, galaxy.yml aracılığıyla rollerin rolleri içe aktarabildiğini, rollerin bağımlılıklara sahip olabileceğini ve aynı zamanda korkunç ve berbat bir durumun da mevcut olduğunu söyleyebilir. include_role — Size figür jimnastiğinde değil, temel Ansible'da becerilerimizi geliştirdiğimizi hatırlatırım.

İşleyiciler ve görevler

Başka bir bariz konuyu tartışalım: işleyiciler. Bunları nasıl doğru şekilde kullanacağınızı bilmek neredeyse bir sanattır. Bir işleyici ile sürükleme arasındaki fark nedir?

Temelleri hatırladığımız için işte bir örnek:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

Rolün işleyicileri rol adı/işleyiciler/main.yaml dosyasında bulunur. İşleyiciler tüm oyun katılımcıları arasında araştırma yapar: ön/sonraki görevler, rol işleyicilerini çekebilir ve bir rol, işleyicileri oyundan çekebilir. Bununla birlikte, işleyicilere yapılan "çapraz rol" çağrıları, önemsiz bir işleyicinin tekrarlanmasından çok daha fazla sıkıntıya neden olur. (En iyi uygulamaların bir diğer unsuru da işleyici adlarını tekrarlamamaya çalışmaktır).

Temel fark, görevin her zaman (aynı zamanda) yürütülmesidir (artı/eksi etiketleri ve when) ve işleyici - durum değişikliğine göre (yangınları yalnızca değiştirilmişse bilgilendirin). Bu ne anlama gelir? Örneğin, yeniden başlattığınızda herhangi bir değişiklik yapılmadıysa hiçbir işleyicinin olmayacağı gerçeği. Oluşturma görevinde herhangi bir değişiklik olmadığında neden işleyiciyi yürütmemiz gerekebilir? Örneğin, bir şey bozuldu ve değişti, ancak yürütme işleyiciye ulaşmadı. Örneğin, ağ geçici olarak kapalı olduğundan. Yapılandırma değişti, hizmet yeniden başlatılmadı. Bir sonraki başlatışınızda yapılandırma artık değişmez ve hizmet, yapılandırmanın eski sürümünde kalır.

Yapılandırmayla ilgili durum çözülemiyor (daha doğrusu, dosya bayrakları vb. ile kendinize özel bir yeniden başlatma protokolü icat edebilirsiniz, ancak bu artık hiçbir biçimde 'temel ansible' değildir). Ancak ortak bir hikaye daha var: Uygulamayı kurduk, kaydettik .service-file ve şimdi onu istiyoruz daemon_reload и state=started. Ve bunun doğal yeri de işleyici gibi görünüyor. Ancak bunu bir işleyici değil de görev listesinin veya rolün sonundaki bir görev haline getirirseniz, o zaman her seferinde önemsiz bir şekilde yürütülecektir. Oyun kitabı ortasında kırılsa bile. Bu, yeniden başlatılan sorunu hiçbir şekilde çözmez (yeniden başlatılan öznitelikle bir görevi yapamazsınız, çünkü idempotency kaybolur), ancak kesinlikle durum = başlatıldı yapmaya değer, başucu kitaplarının genel kararlılığı artar, çünkü bağlantı sayısı ve dinamik durum azalır.

İşleyicinin bir diğer olumlu özelliği de çıkışı tıkamamasıdır. Herhangi bir değişiklik olmadı - çıktıda fazladan atlanan veya tamamlanan bir şey yok - okunması daha kolay. Bu aynı zamanda olumsuz bir özelliktir - ilk çalıştırmada doğrusal olarak yürütülen bir görevde bir yazım hatası bulursanız, işleyiciler yalnızca değiştirildiğinde yürütülür; bazı koşullar altında - çok nadiren. Mesela hayatımda ilk kez beş yıl sonra. Ve elbette isimde bir yazım hatası olacak ve her şey bozulacak. Ve bunları ikinci kez çalıştırmazsanız hiçbir değişiklik olmaz.

Ayrı olarak değişkenlerin kullanılabilirliği hakkında da konuşmamız gerekiyor. Örneğin bir görevi döngüyle bildirirseniz değişkenlerde ne olacak? Analitik olarak tahminde bulunabilirsiniz ancak bu her zaman önemsiz değildir, özellikle de değişkenler farklı yerlerden geliyorsa.

... Yani işleyiciler göründüğünden çok daha az kullanışlı ve çok daha sorunlu. İşleyiciler olmadan güzel bir şekilde (gösterişsiz) bir şeyler yazabiliyorsanız, bunu onlarsız yapmak daha iyidir. Eğer güzel bir şekilde yürümezse, onlarla daha iyi olur.

Aşındırıcı okuyucu haklı olarak tartışmadığımıza işaret ediyor listenbir işleyicinin başka bir işleyici için notify çağrısı yapabileceğini, bir işleyicinin import_tasks içerebileceğini (with_items ile include_role yapabilir), Ansible'daki işleyici sisteminin Turing-tamamlandığını, include_role işleyicilerinin oyundaki işleyicilerle ilginç bir şekilde kesiştiğini, vb. - tüm bunlar açıkça "temel" değildir).

Aslında aklınızda tutmanız gereken bir özellik olan belirli bir WTF olmasına rağmen. Göreviniz ile yürütülürse delegate_to ve bildirimde bulunduktan sonra karşılık gelen işleyici, delegate_toyani oyunun atandığı ana bilgisayarda. (Her ne kadar işleyici elbette delegate_to fazla).

Ayrı olarak, yeniden kullanılabilir roller hakkında birkaç söz söylemek istiyorum. Koleksiyonlar ortaya çıkmadan önce, evrensel roller oluşturabileceğinize dair bir fikir vardı. ansible-galaxy install ve gitti. Her durumda, tüm varyantların tüm işletim sistemlerinde çalışır. Yani benim fikrim: işe yaramıyor. Kütleli herhangi bir rol include_vars100500 vakayı destekleyen . Bunlar kapsamlı testlerle kapsanabilir, ancak herhangi bir testte olduğu gibi, ya giriş değerlerinin ve toplam fonksiyonun Kartezyen çarpımına sahip olursunuz ya da "kapsanan bireysel senaryolara" sahipsiniz. Benim düşünceme göre rolün doğrusal olması çok daha iyi (döngüsel karmaşıklık 1).

Formda daha az sayıda if (açık veya bildirimsel) when veya biçim include_vars değişkenler kümesine göre), rol ne kadar iyi olursa. Bazen dallar açmanız gerekir ama tekrar ediyorum, ne kadar az olursa o kadar iyi. Yani Galaxy'de iyi bir rol gibi görünüyor (işe yarıyor!) when beş görevden “kişinin kendi” rolüne göre daha az tercih edilebilir. Galaxy'deki rolün daha iyi olduğu an, bir şeyler yazmaya başladığınız zamandır. Daha da kötüleştiği an, bir şeyin kırıldığı ve bunun “galaksideki rol”den kaynaklandığına dair şüpheye kapıldığınız zamandır. Açıyorsunuz ve karşınıza beş içerik, sekiz görev sayfası ve bir yığın çıkıyor when'ov... Ve bunu çözmemiz gerekiyor. 5 görev yerine kırılacak hiçbir şeyin olmadığı doğrusal bir liste.

Aşağıdaki bölümlerde

• Envanter, grup değişkenleri, host_group_vars eklentisi, hostvars hakkında biraz bilgi. Gordion düğümü spagetti ile nasıl bağlanır? Kapsam ve öncelik değişkenleri, Ansible bellek modeli. “Peki veritabanının kullanıcı adını nerede saklayacağız?”
• jinja: {{ jinja }} — nosql nottype Nosense yumuşak hamuru. Her yerde, hatta beklemediğiniz yerde bile. Hakkında biraz !!unsafe ve lezzetli yaml.

Kaynak: habr.com