block<\/code> enzovoorts. Hoe beter je Ansible kent, hoe meer nuances je kunt opnoemen voor een \"slim\" ontwerp. Een eenvoudige oplossing is het gebruik van natuurlijke scheiding tussen pre\/roles\/post \u2014 dit roept geen nuances op.<\/p>\n<\/p>\n
En, terugkomend op onze 'foo'. Waar moeten we het plaatsen? In pre, post of in roles? Dit hangt duidelijk af van of we de resultaten van de handler nodig hebben voor foo. Als dat niet het geval is, hoeft foo niet in pre of in post te worden geplaatst \u2014 deze secties hebben een speciale betekenis \u2014 het uitvoeren van taken v\u00f3\u00f3r en n\u00e1 de belangrijkste code.<\/p>\n
<\/p>\n
Nu wordt het antwoord op de vraag \"rol of taak\" afhankelijk van wat er al in play is \u2014 als er taken zijn, dan moet je die in taken aanvullen. Als er rollen zijn, moet je een rol maken (ook al is het maar uit \u00e9\u00e9n taak). Ik herinner je eraan dat taken en rollen niet tegelijkertijd worden gebruikt.<\/p>\n
<\/p>\n
Het begrijpen van de basisprincipes van Ansible geeft onderbouwde antwoorden op vragen die schijnbaar om persoonlijke voorkeur draaien.<\/p>\n
<\/p>\n
Taken en rollen (deel twee)<\/h1>\n <\/p>\n
Laten we nu de situatie bespreken waarin je net begint met het schrijven van een playbook. Je moet foo, bar en baz maken. Zijn dit drie taken, \u00e9\u00e9n rol of drie rollen? Om de vraag te generaliseren: wanneer moet je beginnen met het schrijven van rollen? Wat is de betekenis van het schrijven van rollen als je ook taken kunt schrijven?\u2026 En wat is een rol?<\/p>\n
<\/p>\n
Een van de grootste fouten (daar heb ik het al over gehad) is denken dat een rol als een functie in de bibliotheek van een programma is. Hoe ziet een algemene beschrijving van een functie eruit? Het neemt argumenten als invoer, interacteert met side causes, heeft side effects en geeft een waarde terug.<\/p>\n
<\/p>\n
Nu, let op. Wat hiervan kan in een rol worden gedaan? Bijwerkingen oproepen \u2014 altijd welkom, dat is de essentie van Ansible \u2014 bijwerkingen maken. Hebben side causes? Eenvoudig. Maar met \"een waarde doorgeven en deze retourneren\" \u2014 daar gaat het mis. Ten eerste kun je geen waarde naar een rol doorgeven. Je kunt een globale variabele instellen met een levensduur die de play beslaat in de sectie vars voor de rol. Je kunt een globale variabele instellen met een levensduur in de play binnen de rol. Of zelfs met een levensduur van playbooks (set_fact<\/code>\/register<\/code>). Maar je kunt geen \"lokale variabelen\" hebben. Je kunt geen \"waarde ontvangen\" en deze \"teruggeven\".<\/p>\n<\/p>\n
Hieruit volgt het belangrijkste: je kunt in Ansible niets schrijven zonder side effects op te roepen. Het wijzigen van globale variabelen is altijd een side effect voor een functie. In Rust, bijvoorbeeld, is het wijzigen van een globale variabele unsafe<\/code>. In Ansible is er maar \u00e9\u00e9n manier om waarden voor een rol te be\u00efnvloeden. Let op de gebruikte woorden: niet "waarde doorgeven aan de rol", maar "waarden wijzigen die de rol gebruikt". Er is geen isolatie tussen rollen. Er is geen isolatie tussen taken en rollen.<\/p>\n<\/p>\n
Kortom: een rol is geen functie<\/strong>.<\/p>\n<\/p>\n
Wat is er goed aan rollen? Ten eerste hebben rollen standaardwaarden (\/default\/main.yaml<\/code>), ten tweede hebben rollen extra mappen om bestanden op te slaan.<\/p>\n<\/p>\n
Wat is er zo goed aan standaardwaarden? In de behoorlijk verdraaide prioriteitstabel van Maslow voor variabelen in Ansible zijn de rolstandaardwaarden de minst prioritaire (behalve de commandoregelparameters van Ansible). Dit betekent dat als je standaardwaarden moet geven zonder je zorgen te maken dat ze de waarden uit de inventory of groepsvariabelen overschrijven, de standaardwaarden van de rol de enige juiste plek voor je zijn. (Ik lieg een beetje - er is ook nog |d(your_default_here)<\/code>, maar als we het hebben over vaste plekken - dan zijn het alleen de standaardwaarden van de rollen).<\/p>\n<\/p>\n
Wat is er nog meer goed aan rollen? Ze hebben hun eigen mappen. Dit zijn mappen voor variabelen, zowel statische (d.w.z. berekend voor de rol) als dynamische (er is een of andere patroon, of anti-patroon - include_vars<\/code> samen met {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Dit zijn mappen voor files\/<\/code>, templates\/<\/code>. Bovendien stelt het je in staat om je eigen modules en plugins te hebben (library\/<\/code>). Maar in vergelijking met taken in een playbook (waar ook alles kan zijn), is het voordeel hier alleen dat de bestanden niet in \u00e9\u00e9n grote hoop zijn gestapeld, maar in verschillende kleine stapels.<\/p>\n<\/p>\n
Een ander detail: je kunt proberen rollen te maken die beschikbaar zijn voor hergebruik (via galaxy). Na de introductie van collecties kan de verspreiding van rollen als bijna vergeten worden beschouwd.<\/p>\n
<\/p>\n
Dus hebben rollen twee belangrijke kenmerken: ze hebben standaardwaarden (een unieke eigenschap) en ze stellen je in staat om de code te structureren.<\/p>\n
<\/p>\n
Terugkomend op de oorspronkelijke vraag: wanneer gebruik je taken en wanneer rollen? Taken in een playbook worden meestal gebruikt ofwel als "lijm" voor\/na rollen, of als onafhankelijke bouwstenen (dan mogen rollen niet in de code staan). Een stapel normale taken door elkaar met rollen is duidelijk slordig. Je moet je aan een specifieke stijl houden \u2014 of taken of rollen. Rollen bieden scheiding van entiteiten en standaarden, taken maken het gemakkelijker om de code te lezen. Gewoonlijk worden meer "stationaire" (belangrijke en complexe) code in de rol geplaatst, terwijl bij de stijl van taken ondersteunende scripts worden geschreven.<\/p>\n
<\/p>\n
Er is de mogelijkheid om import_role als taak te maken, maar als je dat schrijft, wees dan bereid om jezelf uit te leggen waarom je dat zou willen doen.<\/p>\n
<\/p>\n
Een kritische lezer kan zeggen dat rollen rollen kunnen importeren, dat rollen afhankelijkheden kunnen hebben via galaxy.yml, en er is ook het gruwelijke en vreselijke include_role<\/code> \u2014 ik herinner je eraan dat we onze vaardigheden in basis Ansible verbeteren, en niet in ritmische gymnastiek.<\/p>\n<\/p>\n
Handlers en taken<\/h1>\n <\/p>\n
Laten we nog iets voor de hand liggends bespreken: handlers. De vaardigheid om ze correct te gebruiken is bijna een kunst. Wat is het verschil tussen een handler en een taak?<\/p>\n
<\/p>\n
Omdat we de basisherinneringen opfrissen, hier is een voorbeeld:<\/p>\n
<\/p>\n
- hosts: group1\n taken:\n - foo:\n notify: handler1\n handlers:\n - naam: handler1\n bar:<\/code><\/pre>\n<\/p>\n
De handlers van de rol bevinden zich in rolename\/handlers\/main.yaml. Handlers worden gedeeld tussen alle deelnemers aan de play: pre\/post_tasks kunnen de handlers van de rol aanroepen, en de rol kan handlers uit de play aanroepen. Echter, "kruisrol" aanroepen van handlers zorgt voor veel grotere verwarring dan het herhalen van een triviale handler. (Een ander element van de best practices is om te proberen herhalingen van de namen van handlers te vermijden).<\/p>\n
<\/p>\n
Het belangrijkste verschil is dat een taak altijd (bijna altijd met uitzondering van tags en when<\/code>), idempotent wordt uitgevoerd, terwijl de handler wordt uitgevoerd op basis van statuswijzigingen (notify wordt alleen geactiveerd als er iets is veranderd). Wat houdt dat in? Bijvoorbeeld, dat bij een herhaalde uitvoering, als er geen wijzigingen zijn geweest, er ook geen handler zal zijn. Maar waarom kan het zo zijn dat we een handler moeten uitvoeren, terwijl er geen wijzigingen waren bij de veroorzakende taak? Bijvoorbeeld omdat er iets kapot was en er wel wijzigingen waren, maar de uitvoering kwam niet bij de handler. Bijvoorbeeld omdat het netwerk tijdelijk uit viel. De configuratie is veranderd, de service is niet herstart. Bij de volgende uitvoering verandert de configuratie al niet meer, en blijft de service met de oude versie van de configuratie.<\/p>\n<\/p>\n
De situatie met de configuratie is niet oplosbaar (eigenlijk, je kunt voor jezelf een speciaal herstartprotocol uitvinden met bestandsvlaggen, enzovoort, maar dat is al niet meer ‘basis ansible’ in welke vorm dan ook). Maar er is een andere veelvoorkomende situatie: we hebben een applicatie ge\u00efnstalleerd, hebben deze genoteerd. .service<\/code>-bestand, en nu willen we deze daemon_reload<\/code> en state=started<\/code>. En een natuurlijke plek hiervoor lijkt de handler. Maar als je het geen handler maar een taak aan het einde van de takenlijst of rol maakt, zal het idempotent worden uitgevoerd elke keer. Zelfs als de playbook halverwege faalt. Dit lost het probleem van restarted absoluut niet op (je kunt geen taak met de eigenschap restarted doen, omdat de idempotentie verloren gaat), maar het is zeker beter om state=started te doen, omdat de algehele stabiliteit van playbooks toeneemt, omdat het aantal afhankelijkheden en dynamische toestand vermindert.<\/p>\n<\/p>\n
Een ander positief kenmerk van de handler is dat deze de output niet vervuilt. Er waren geen wijzigingen \u2014 geen overbodige skipped of ok in de output \u2014 het is gemakkelijker te lezen. Dit is ook een negatief kenmerk \u2014 als je een spelfout in een lineair uitgevoerde taak bij de eerste poging vindt, worden handlers alleen uitgevoerd bij veranderingen, dat wil zeggen onder bepaalde voorwaarden \u2014 zeer zeldzaam. Bijvoorbeeld, de eerste keer in je leven na vijf jaar. En natuurlijk zal er een spelfout in de naam zijn en alles zal mislukken. De tweede keer kun je ze niet uitvoeren \u2014 er zijn geen wijzigingen.<\/p>\n
<\/p>\n
Er moet apart gesproken worden over de beschikbaarheid van variabelen. Bijvoorbeeld, als je notify voor een taak met een loop, wat zal er dan in de variabelen staan? Je kunt dat analytisch afleiden, maar het is niet altijd triviaal, vooral als de variabelen uit verschillende bronnen komen.<\/p>\n
<\/p>\n
Handlers zijn dus veel minder nuttig en veel problematischer dan ze lijken. Als het mogelijk is om iets mooi (zonder franje) te schrijven zonder handlers, doe het dan zonder. Als het niet mooi lukt, gebruik ze dan beter.<\/p>\n
<\/p>\n
De oplettende lezer merkt terecht op dat we niet hebben besproken listen<\/code>, dat handlers notify kunnen aanroepen voor andere handlers, dat een handler import_tasks kan bevatten (die include_role met with_items kan doen), dat het systeem van handlers in Ansible Turing-compleet is, dat handlers uit include_role op een intrigerende manier overlappen met handlers uit plays, etc. - dit is allemaal duidelijk geen \"basis\".<\/p>\n<\/p>\n
Maar er is \u00e9\u00e9n bepaalde WTF die eigenlijk een feature is, en waar je aan moet denken. Als je een taak uitvoert met delegate_to<\/code> en het heeft notify, dan wordt de bijbehorende handler uitgevoerd zonder delegate_to<\/code>, dat wil zeggen, op de host waarop de play is toegewezen. (Hoewel een handler uiteraard ook kan hebben delegate_to<\/code> ook).<\/p>\n<\/p>\n
Ik wil apart een paar woorden zeggen over herbruikbare rollen. Tot de komst van collecties was er het idee dat je universele rollen kon maken die je kon ansible-galaxy install<\/code> en verder gegaan. Werkt op alle besturingssystemen in alle varianten in alle situaties. Dus, mijn mening: dit werkt niet. Elke rol met een massale include_vars<\/code>, het ondersteunen van 100500 gevallen is gedoemd tot diepten van corner case bugs. Ze kunnen worden afgedekt door middel van uitgebreide tests, maar zoals bij elke test, ofwel heb je een cartesiaans product van invoerwaarden en een totale functie, ofwel heb je \"specifieke scenario's gedekt\". Mijn mening - het is veel beter als de rol lineair is (cyclomatische complexiteit 1).<\/p>\n<\/p>\n
Hoe minder if-statements (expliciet of declaratief - in de vorm van when<\/code> of vorm include_vars<\/code> per set variabelen), hoe beter de rol. Soms moet je takken maken, maar nogmaals, hoe minder, hoe beter. Dus het lijkt alsof een goede rol met galaxy (werkt immers!) met een hoop when<\/code> kan minder gewenst zijn dan \"eigen\" rol van vijf taken. Het moment waarop de rol met Galaxy beter is - wanneer je iets begint te schrijven. Het moment waarop het slechter wordt - wanneer er iets fout gaat, en je vermoedt dat dit te maken heeft met de \"rol uit Galaxy\". Je opent het, en daar zijn vijf inclusies, acht taaklijsten en een stapel when<\/code>\u2018en... En daar moet je doorheen. In plaats van 5 taken in een lineaire lijst, waarin er eigenlijk niets stuk kan gaan.<\/p>\n<\/p>\n
In de volgende delen<\/h1>\n <\/p>\n
\nEen beetje over inventory, groepsvariabelen, host_group_vars plugin, hostvars. Hoe je spaghetti omzet in een Gordiaanse knoop. Scope en precedentie van variabelen, Ansible geheugenmodel. \"Dus waar moet je de gebruikersnaam voor de database opslaan?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nosense zachte klei. Het is overal, zelfs daar waar je het niet verwacht. Een beetje over !!unsafe<\/code> en smakelijke yaml.<\/li>\n<\/ul>\nBron: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f \u0434\u0435\u043b\u0430\u044e \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0432\u044c\u044e \u0434\u043b\u044f \u0447\u0443\u0436\u043e\u0433\u043e \u043a\u043e\u0434\u0430 \u043d\u0430 \u0410\u043d\u0441\u0438\u0431\u043b \u0438 \u043c\u043d\u043e\u0433\u043e \u043f\u0438\u0448\u0443 \u0441\u0430\u043c. \u0412 \u0445\u043e\u0434\u0435 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u043e\u0448\u0438\u0431\u043e\u043a (\u043a\u0430\u043a \u0447\u0443\u0436\u0438\u0445, \u0442\u0430\u043a \u0438 \u0441\u0432\u043e\u0438\u0445), \u0430 \u0442\u0430\u043a \u0436\u0435 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0439, \u044f \u043f\u043e\u043d\u044f\u043b \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u043e\u0448\u0438\u0431\u043a\u0443, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0410\u043d\u0441\u0438\u0431\u043b\u0430 \u2014 \u043e\u043d\u0438 \u043b\u0435\u0437\u0443\u0442 \u0432 \u0441\u043b\u043e\u0436\u043d\u043e\u0435, \u043d\u0435 \u043e\u0441\u0432\u043e\u0438\u0432 \u0431\u0430\u0437\u043e\u0432\u043e\u0433\u043e. \u0414\u043b\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439 \u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u043e\u0439 \u043d\u0435\u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u043e\u0441\u0442\u0438 \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0410\u043d\u0441\u0438\u0431\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87084","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t