Besteen Ansible kodearen berrikuspen asko egiten ditut eta nik neuk asko idazten dut. Akatsak (besteenak eta nireak) aztertzean, baita hainbat elkarrizketatan ere, Ansible-ren erabiltzaileek egiten duten akats nagusiaz konturatu nintzen: gauza konplexuetan sartzen dira oinarrizkoak menperatu gabe.

Injustizia unibertsal hori zuzentzeko, Ansibleren sarrera bat idaztea erabaki nuen jada ezagutzen dutenentzat. Ohartarazten dizut, hau ez da gizonen berrikusketa bat, hau gutun asko eta irudirik gabeko irakurketa luzea da.

Irakurlearen espero den maila da dagoeneko hainbat mila lerro idatzita daudela, dagoeneko zerbait ekoizten ari dela, baina "nolabait dena makurtuta dago".

izenak

Ansible erabiltzaile batek egiten duen akats nagusia zerbait nola deitzen den ez jakitea da. Izenak ezagutzen ez badituzu, ezin duzu ulertu dokumentazioak zer dioen. Adibide bizi bat: elkarrizketa batean, Ansible-n asko idatzi zuela esaten zuen pertsona batek ezin izan zion erantzun "zer elementuz osatuta dago playbook bat?" Eta "erantzuna jolas-liburua jolasez osatuta zegoela espero zen" iradoki nuenean, "ez dugu hori erabiltzen" iruzkin madarikatua jarraitu zen. Jendeak Ansible diruaren truke idazten du eta ez du jolasa erabiltzen. Benetan erabiltzen dute, baina ez dakite zer den.

Beraz, has gaitezen zerbait sinple batekin: nola deitzen da? Agian badakizu hori, edo agian ez, dokumentazioa irakurtzean kasurik egin ez duzulako.

ansible-playbook-ek playbook-a exekutatzen du. Playbook bat yml/yaml luzapena duen fitxategi bat da, eta horren barruan honelako zerbait dago:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

Dagoeneko konturatu ginen fitxategi osoa playbook bat dela. Rolak non dauden eta zereginak non dauden erakutsi dezakegu. Baina non dago jolasa? Eta zer desberdintasun dago antzezlanaren eta rolaren edo antzezlanaren artean?

Dokumentazioan dago dena. Eta faltan botatzen dute. Hasiberriak - gehiegi dagoelako eta ez duzulako dena aldi berean gogoratuko. Esperientziatua - "gauza hutsalak" direlako. Esperientziaduna bazara, irakurri orri hauek gutxienez sei hilean behin, eta zure kodea klase-buru bihurtuko da.

Beraz, gogoratu: Playbook play-ek eta osatutako zerrenda bat da import_playbook.
Hau antzezlan bat da:

- hosts: group1
  roles:
    - role1

eta hau ere beste antzezlan bat da:

- hosts: group2,group3
  tasks:
    - debug:

Zer da jolasa? Zergatik dago?

Jolasa funtsezko elementua da playbook baterako, jolasak eta soilik jolasak rol eta/edo zereginen zerrenda bat exekutatu behar diren ostalarien zerrendarekin lotzen baitu. Dokumentazioaren sakonean aipamena aurki dezakezu delegate_to, tokiko bilaketa-pluginak, sareko kli-ren ezarpen espezifikoak, salto ostalariak, etab. Zereginak egiten diren lekua apur bat aldatzeko aukera ematen dute. Baina, ahaztu. Aukera adimentsu horietako bakoitzak oso erabilera zehatzak ditu, eta zalantzarik gabe ez dira unibertsalak. Eta denek ezagutu eta erabili beharreko oinarrizko gauzei buruz ari gara.

"Zerbait" "nonbait" egin nahi baduzu, antzezlana idazten duzu. Ez rol bat. Ez da rol bat moduluekin eta delegatuekin. Hartu eta idazten duzu play. Bertan, ostalarien eremuan non exekutatu behar den zerrendatzen duzu eta rol/zereginetan - zer exekutatu.

Sinplea, ezta? Nola liteke bestela?

Jendeak jolasaren bidez ez egiteko gogoa duen une berezietako bat "dena ezartzen duen rola" da. Lehen motako zerbitzariak eta bigarren motako zerbitzariak konfiguratzen dituen rol bat izatea gustatuko litzaidake.

Adibide arketipikoa monitorizazioa da. Jarraipena konfiguratuko duen jarraipen-funtzio bat izatea gustatuko litzaidake. Jarraipen-eginkizuna monitorizazio ostalariei esleitzen zaie (jolasaren arabera). Baina ikusten da monitorizaziorako paketeak entregatu behar ditugula kontrolatzen ari garen ostalariei. Zergatik ez erabili delegatua? iptables ere konfiguratu behar duzu. delegatu? Gainera, DBMSrako konfigurazio bat idatzi/zuzendu behar duzu monitorizazioa gaitzeko. ordezkaria! Eta sormena falta bada, ordezkaritza bat egin dezakezu include_role begizta habiaratu batean taldeen zerrendako iragazki delikatua erabiliz, eta barruan include_role gehiago egin dezakezu delegate_to berriz. Eta alde egiten dugu...

Desio on batek - jarraipen-eginkizun bakarra edukitzea, "dena egiten duena" - infernu osora garamatza, gehienetan aterabide bakarra baitago: dena hutsetik berridaztea.

Non gertatu da akatsa hemen? X ostalariaren "x" ataza egiteko Y ostalarira joan eta bertan "y" egin behar zenuela deskubritu zenuen momentuan, ariketa sinple bat egin behar zenuten: joan eta idatzi jolasa, Y ostalarian y egiten duena. Ez gehitu ezer "x", baina idatzi hutsetik. Nahiz eta gogor kodetutako aldagaiekin.

Badirudi goiko paragrafoetan dena zuzen esaten dela. Baina hau ez da zure kasua! Lehorra eta liburutegi modukoa den kode berrerabilgarria idatzi nahi duzulako, eta nola egin jakiteko metodo bat bilatu behar duzulako.

Hor ezkutatzen da beste akats larri bat. Akats bat, proiektu asko modu jasangarritik idatzita (hobea izan liteke, baina dena funtzionatzen du eta erraz bukatzen da) egileak ere asmatu ezin duen izugarrizko ikara bihurtu zuen. Funtzionatzen du, baina Jainkoak ez dizu ezer aldatzea.

Errorea hau da: rola liburutegiko funtzio bat da. Analogia honek hainbeste hasiera on hondatu ditu, non ikustea besterik ez da tristea. Eginkizuna ez da liburutegiko funtzio bat. Ezin du kalkulurik egin eta ezin du joko-mailako erabakirik hartu. Gogoratu zer erabaki hartzen dituen jolasak?

Eskerrik asko, arrazoi duzu. Play-ek erabakia hartzen du (zehazkiago, informazioa dauka) zein ataza eta rol zein ostalaritan egin behar den.

Erabaki hau rol bati delegatzen badiozu, eta kalkuluekin ere, zeure burua (eta zure kodea analizatzen saiatuko dena) existentzia miserable batera kondenatzen duzu. Rolak ez du erabakitzen non egiten den. Erabaki hau jokoz hartzen da. Rolak kontatzen dena egiten du, kontatzen den lekuan.

Zergatik da arriskutsua Ansible-n programatzea eta zergatik COBOL Ansible baino hobea den aldagaiei eta jinja-ri ​​buruz hitz egingo dugu kapituluan. Oraingoz, esan gauza bat: zure kalkulu bakoitzak aldagai globalen aldaketen aztarna ezabaezin bat uzten du atzean, eta ezin duzu ezer egin. Bi “arrastoak” gurutzatu bezain pronto, dena desagertu zen.

Oharra: rolak kontrol-fluxuan eragin dezake. Jan delegate_to eta zentzuzko erabilerak ditu. Jan meta: end host/play. Baina! Gogoratzen al duzu oinarriak irakasten ditugula? Ahaztua delegate_to. Ansible kode sinple eta ederrenaz ari gara. Irakurtzeko erraza, idazteko erraza, arazketarako erraza, probatzeko erraza eta osatzeko erraza dena. Beraz, berriro ere:

jolastu eta jolasak bakarrik erabakitzen du zein ostalari zer exekutatzen den.

Atal honetan, jolasaren eta rolaren arteko oposizioaz aritu gara. Orain hitz egin dezagun zereginen eta rolen arteko erlazioari buruz.

Zereginak eta Rolak

Demagun jolastea:

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

Demagun foo egin behar duzula. Eta badirudi foo: name=foobar state=present. Non idatzi behar dut hau? in pre? mezua? Rol bat sortu?

...Eta nora joan ziren zereginak?

Oinarrizkoekin hasiko gara berriro: jolasteko gailua. Gai honetan flotatzen baduzu, ezin duzu jolasa beste guztiaren oinarri gisa erabili, eta zure emaitza "dardarka" izango da.

Erreproduzitzeko gailua: ostalarien zuzentaraua, jolaserako ezarpenak eta atazen aurrekoak, atazak, rolak, ataza osteko atalak. Jolaserako gainerako parametroak ez dira garrantzitsuak guretzat orain.

Beren atalen ordena zeregin eta rolekin: pre_tasks, roles, tasks, post_tasks. Semantikoki exekuzio-ordena artean dagoenez tasks и roles ez dago argi, orduan praktika onek esaten dute atal bat gehitzen ari garela tasks, ez bada bakarrik roles... Bada roles, ondoren erantsitako zeregin guztiak ataletan jartzen dira pre_tasks/post_tasks.

Semantikoki dena argi dagoela da geratzen dena: lehenik pre_tasks, gero roles, gero post_tasks.

Baina oraindik ez diogu galderari erantzun: non dago moduluaren deialdia? foo idatzi? Modulu bakoitzeko rol oso bat idatzi behar al dugu? Edo hobe al da denetarako paper lodi bat izatea? Eta rol bat ez bada, non idatzi behar dut - aurre edo post-ean?

Galdera hauei erantzun arrazoiturik ez badago, intuizio faltaren seinale da, hau da, "oinarri astindu" horiek. Asma dezagun. Lehenik eta behin, segurtasun galdera bat: jolastu badu pre_tasks и post_tasks (eta ez dago zereginik edo rolik), orduan zerbait hautsi daiteke lehenengo zeregina egiten badut post_tasks Bukaera arte eramango dut pre_tasks?

Jakina, galderaren idazkerak hautsi egingo duela adierazten du. Baina zer zehazki?

... Kudeatzaileak. Oinarriak irakurtzeak datu garrantzitsu bat erakusten du: kudeatzaile guztiak automatikoki garbitzen dira atal bakoitzaren ondoren. Horiek. zeregin guztiak pre_tasks, gero jakinarazi ziren kudeatzaile guztiak. Ondoren, roletan jakinarazi ziren rol eta kudeatzaile guztiak exekutatzen dira. Ondoren post_tasks eta haien kudeatzaileak.

Horrela, zeregin bat arrastatuz gero post_tasks в pre_tasks, orduan potentzialki kudeatzailea exekutatu aurretik exekutatu egingo duzu. adibidez, sartzen bada pre_tasks web zerbitzaria instalatuta eta konfiguratuta dago, eta post_tasks zerbait bidaltzen zaio, gero zeregin hau atalera transferitu pre_tasks "Bidaltzeko" momentuan zerbitzaria oraindik ez da martxan jarriko eta dena hautsi egingo da.

Orain pentsa dezagun berriro, zergatik behar dugun pre_tasks и post_tasks? Esaterako, eginkizuna bete aurretik beharrezkoa dena (kudeatzaileak barne) osatzeko. A post_tasks rolak exekutatzeko emaitzekin lan egiteko aukera emango digu (kudeatzaileak barne).

Ansible aditu aditu batek esango digu zer den. meta: flush_handlers, baina zergatik behar ditugu flush_handlers jokoan dauden atalen exekuzio-ordenan oinarritzen bagara? Gainera, meta: flush_handlers erabiltzeak ustekabeko gauzak eman diezaguke kudeatzaile bikoiztuekin, abisu bitxiak ematen dizkigute erabiltzen denean. when у block etab. Zenbat eta hobeto ezagutu ansiblea, orduan eta ñabardura gehiago eman diezaiokezu irtenbide "delikatua" bati. Eta irtenbide sinple batek -aurre/rolen/ondoren arteko banaketa naturala erabiliz- ez du ñabardurarik sortzen.

Eta, itzuli gure 'foo'ra. Non jarri behar dut? Aurre, post edo roletan? Jakina, hau foo kudeatzailearen emaitzak behar ditugun ala ezaren araberakoa da. Ez badaude, orduan foo ez da beharrezkoa ez aurretik edo ondorengoan jarri behar - atal hauek esanahi berezia dute - kode nagusiaren aurretik eta ondoren zereginak exekutatzen.

Orain "rola edo zeregina" galderaren erantzuna dagoeneko jokoan dagoenari dagokio - zereginak badaude, zereginetara gehitu behar dituzu. Rolak badaude, rol bat sortu behar duzu (baita zeregin batetik ere). Gogorarazten dizut zereginak eta rolak ez direla aldi berean erabiltzen.

Ansibleren oinarriak ulertzeak zentzuzko erantzunak ematen ditu itxuraz gustuko galderei.

Zereginak eta eginkizunak (bigarren zatia)

Orain eztabaida dezagun jolas-liburua idazten hasten zarenean. Foo, taberna eta baz egin behar dituzu. Hiru zeregin hauek, rol bat edo hiru rol dira? Galdera laburbiltzeko: zein momentutan hasi beharko zenuke rolak idazten? Zertarako balio du rolak idazteak zereginak idazten dituzunean?... Zer da rol bat?

Akats handienetako bat (dagoeneko honetaz hitz egin dut) rol bat programa baten liburutegiko funtzio bat bezalakoa dela pentsatzea da. Nolakoa da funtzioaren deskribapen generiko bat? Sarrerako argumentuak onartzen ditu, alboko kausekin elkarreragin egiten du, bigarren mailako efektuak egiten ditu eta balio bat itzultzen du.

Orain, arreta. Zer egin daiteke honetatik paperean? Beti ongi etorria zara bigarren mailako efektuak deitzea, hau da Ansible osoaren funtsa - bigarren mailako efektuak sortzeko. Alboko arrazoiak al dituzu? Oinarrizkoa. Baina "balio bat pasa eta itzuli"-rekin, hor ez da funtzionatzen. Lehenik eta behin, ezin diozu balio bat eman rol bati. Aldagai global bat ezar dezakezu bizitza osorako joko-tamaina duen rolaren vars atalean. Rolaren barruan bizitza osoa duen aldagai global bat ezar dezakezu. Edo jolas-liburuen bizitzarekin ere (set_fact/register). Baina ezin dituzu "aldagai lokalak" izan. Ezin duzu "balio bat hartu" eta "itzuli".

Gauza nagusia honetatik dator: ezin duzu ezer idatzi Ansible-n albo-ondoriorik sortu gabe. Aldagai globalak aldatzea beti da funtzio baten albo-ondorioa. Rust-en, adibidez, aldagai global bat aldatzea da unsafe. Eta Ansible-n rol baten balioetan eragiteko metodo bakarra da. Kontuan izan erabilitako hitzak: ez "balio bat rolari pasa", baizik eta "rolak erabiltzen dituen balioak aldatu". Rolen artean ez dago isolamendurik. Ez dago zereginen eta rolen arteko isolamendurik.

Guztira: rol bat ez da funtzio bat.

Zer da ona rolak? Lehenik eta behin, rolak balio lehenetsiak ditu (/default/main.yaml), bigarrenik, rolak fitxategiak gordetzeko direktorio osagarriak ditu.

Zeintzuk dira balio lehenetsien abantailak? Maslow-en piramidean, Ansibleren lehentasun aldagaien taula nahiko distortsionatua denez, rol lehenetsiak lehentasun baxuenak dira (Ansible komando-lerroko parametroak kenduta). Horrek esan nahi du balio lehenetsiak eman behar badituzu eta inbentarioaren edo talde-aldagaien balioak gainditzeaz kezkatu ez bazara, rol lehenetsiak leku apropos bakarra dira zuretzat. (Gezurra apur bat ari naiz - gehiago daude |d(your_default_here), baina leku geldiez hitz egiten badugu, rol lehenetsiak bakarrik).

Zer gehiago da handia rolak? Euren katalogoak dituztelako. Hauek aldagaien direktorio dira, bai konstanteak (hau da, rolerako kalkulatuak) bai dinamikoak (eredu bat edo ereduaren aurkakoa dago - include_vars elkarrekin {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). Hauek dira direktorioa files/, templates/. Gainera, zure moduluak eta pluginak edukitzeko aukera ematen du (library/). Baina, jolas-liburu bateko zereginekin alderatuta (hau guztia ere izan dezakeena), hemen onura bakarra fitxategiak ez direla pila batera botatzen dira, hainbat pila bereizi baizik.

Xehetasun bat gehiago: berrerabiltzeko erabilgarri egongo diren rolak sortzen saia zaitezke (galaxia bidez). Bildumen etorrerarekin, rol banaketa ia ahaztutzat jo daiteke.

Horrela, rolek bi ezaugarri garrantzitsu dituzte: lehenetsiak dituzte (ezaugarri berezia) eta zure kodea egituratzeko aukera ematen dizute.

Jatorrizko galderara itzuliz: noiz egin zereginak eta noiz egin rolak? Jolas-liburuko atazak gehienetan erabiltzen dira rolen aurretik/ondoren "kola" gisa, edo eraikuntza elementu independente gisa (orduan ez luke rolik egon behar kodean). Rolekin nahastutako zeregin normal pila bat anbiguotasunik gabeko alferkeria da. Estilo zehatz bati atxiki behar diozu, zeregin bati edo rol bati. Rolek entitateak eta lehenetsiak bereizten dituzte, atazek kodea azkarrago irakurtzeko aukera ematen dute. Normalean, kode "geldiagoa" (garrantzitsua eta konplexua) jartzen da roletan, eta script laguntzaileak zereginen estiloan idazten dira.

Posible da import_role zeregin gisa egitea, baina hau idazten baduzu, prest egon zure edertasun zentzuari zergatik egin nahi duzun hori azaltzeko.

Irakurle aditu batek esan dezake rolak rolak inporta ditzaketela, rolek menpekotasunak izan ditzaketela galaxy.yml bidez, eta ikaragarria eta izugarria ere badago. include_role — Gogorarazten dizut oinarrizko Ansible-n trebetasunak hobetzen ari garela, eta ez figura-gimnasian.

Kudeatzaileak eta zereginak

Eztabaida dezagun ageriko beste gauza bat: kudeatzaileak. Ondo erabiltzen jakitea ia arte bat da. Zein da kudeatzaile baten eta arrastatzearen arteko aldea?

Oinarriak gogoratzen ari garenez, hona hemen adibide bat:

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

Rolaren kudeatzaileak rolename/handlers/main.yaml-en daude. Kudeatzaileek antzezlaneko parte-hartzaile guztien artean arakatzen dute: pre/post_tasks-ek rol-kudeatzaileak atera ditzake, eta rol batek antzezlanetik kudeatzaileak atera ditzake. Hala ere, kudeatzaileei egindako "rol gurutzatuak" deiek kudeatzaile hutsal bat errepikatzeak baino askoz wtf gehiago eragiten dute. (Praktika egokien beste elementu bat kudeatzaileen izenak ez errepikatzen saiatzea da).

Desberdintasun nagusia da zeregina beti exekutatzen dela (ipotenteki) (plus/minus etiketak eta when), eta kudeatzailea - egoera aldaketaren arabera (jakinarazi suteak aldatu bada bakarrik). Zer esan nahi du honek? Adibidez, berrabiarazten duzunean, aldaketarik ez bazegoen, orduan ez dela kudeatzailerik egongo. Zergatik izan liteke kudeatzailea exekutatu behar dugula sortzeko zereginean aldaketarik egon ez denean? Adibidez, zerbait hautsi eta aldatu zelako, baina exekuzioa ez zen kudeatzaileari heldu. Adibidez, sarea behin-behinean behera geratu zelako. Konfigurazioa aldatu da, zerbitzua ez da berrabiarazi. Abiarazten duzun hurrengoan, konfigurazioa jada ez da aldatzen eta zerbitzuak konfigurazioaren bertsio zaharrarekin jarraitzen du.

Konfigurazioaren egoera ezin da konpondu (zehatzago esanda, berrabiarazi protokolo berezi bat asma dezakezu zuk zeuk fitxategi-markekin, etab., baina hori jada ez da 'oinarrizko ansible' inolaz ere). Baina bada beste istorio arrunt bat: aplikazioa instalatu dugu, grabatu .service-fitxategia, eta orain nahi dugu daemon_reload и state=started. Eta horretarako leku naturala kudeatzailea dela dirudi. Baina ez baduzu kudeatzailea, baizik eta ataza-zerrenda edo rol baten amaieran zeregina bihurtzen baduzu, aldi bakoitzean idempotently exekutatuko da. Jolas liburua erdian hautsi bazen ere. Honek ez du batere konpontzen berrabiarazitako arazoa (ezin duzu zeregin bat egin berrabiarazi atributuarekin, idempotentzia galtzen delako), baina, zalantzarik gabe, merezi du state=started egiteak, playbooken egonkortasun orokorra handitzen baita, zeren konexio kopurua eta egoera dinamikoa gutxitzen dira.

Kudeatzailearen beste propietate positibo bat irteera ez oztopatzen da. Ez zen aldaketarik egon - irteeran ez da ezer saltatu edo ondo - irakurtzeko errazagoa. Propietate negatiboa ere bada - lehen exekuzioan linealki exekutatzen den zeregin batean akatsen bat aurkitzen baduzu, kudeatzaileak aldatzen direnean bakarrik exekutatuko dira, hau da. baldintza batzuetan - oso gutxitan. Adibidez, nire bizitzan lehen aldiz bost urte geroago. Eta, noski, izenean akats bat egongo da eta dena hautsiko da. Eta bigarren aldiz exekutatzen ez badituzu, ez dago aldaketarik.

Bereiz, aldagaien erabilgarritasunaz hitz egin behar dugu. Adibidez, zeregin bati begizta batekin jakinarazten badiozu, zer egongo da aldagaietan? Analitikoki asma dezakezu, baina ez da beti hutsala, batez ere aldagaiak leku ezberdinetatik badatoz.

... Beraz, kudeatzaileak diruditen baino askoz ere ez dira erabilgarriak eta askoz problematikoagoak. Kudeatzailerik gabe zerbait ederki idazten baduzu (erretxikirik gabe), hobe da horiek gabe egitea. Ederki ateratzen ez bada, hobe da haiekin.

Irakurle korrosiboak zuzen adierazten du ez dugula eztabaidatu listenKudeatzaileak beste kudeatzaile bati jakinarazpena dei diezaiokeela, kudeatzaileak import_tasks sar ditzakeela (include_role with_items-ekin egin dezakeela), Ansible-en kudeatzaile-sistema Turing-complete dela, include_role-ko kudeatzaileak modu bitxian gurutzatzen direla jokoko kudeatzaileekin, eta abar .d. - argi eta garbi hori guztia ez da "oinarriak").

WTF espezifiko bat dagoen arren, benetan kontuan izan behar duzun ezaugarri bat den. Zure zeregina exekutatzen bada delegate_to eta jakinarazi du, orduan dagokion kudeatzailea gabe exekutatzen da delegate_to, hau da. jolasa esleitzen den ostalarian. (Nahiz eta kudeatzaileak, noski, izan delegate_to Berdin).

Bereiz, rol berrerabilgarriei buruz hitz batzuk esan nahi ditut. Bildumak agertu aurretik, izan zitezkeen rol unibertsalak egin ditzakezula ideia bat zegoen ansible-galaxy install eta joan zen. Egoera guztietan aldaera guztietako OS guztietan funtzionatzen du. Beraz, nire iritzia: ez du funtzionatzen. Masarekin edozein rol include_vars, 100500 kasu onartzen ditu, izkinako kasu akatsen amildegira kondenatuta dago. Proba masiboekin estali daitezke, baina edozein probarekin bezala, sarrerako balioen produktu cartesiarra eta funtzio osoa daukazu, edo "eszenatoki indibidualak estalita" dituzu. Nire iritzia da askoz hobea dela rola lineala bada (1. konplexutasun ziklomatikoa).

Zenbat eta bada gutxiago (esplizitua edo deklaratiboa - forman when edo forma include_vars aldagai multzoen arabera), orduan eta rol hobea. Batzuetan adarrak egin behar dituzu, baina, errepikatzen dut, zenbat eta gutxiago izan, orduan eta hobeto. Beraz, paper ona dirudi galaxiarekin (funtzionatzen du!) sorta batekin when bost zereginetatik "norberaren" rola baino hobeagoa izan daiteke. Galaxiarekin rola hobea den momentua zerbait idazten hasten zarenean da. Okerrera egiten duen momentua zerbait apurtzen denean eta “galaxiarekin duen rolagatik” dela susmoa duzu. Ireki duzu, eta bost inklusio, zortzi zeregin-orri eta pila bat daude when'ov... Eta hau asmatu behar dugu. 5 zereginen ordez, apurtzeko ezer ez dagoen zerrenda lineal bat.

Ondorengo zatietan

• Inbentarioari, talde aldagaiei, host_group_vars pluginari eta hostvars buruz apur bat. Nola lotu gordiar korapilo bat espagetiekin. Esparrua eta lehentasun-aldagaiak, Ansible memoria-eredua. "Beraz, non gordetzen dugu datu-basearen erabiltzaile-izena?"
• jinja: {{ jinja }} — nosql notype nosense plastilina biguna. Nonahi dago, nahiz eta espero ez duzun tokian. Apur bat buruz !!unsafe eta yaml goxoa.

Iturria: www.habr.com