Optimaliseren van IT Automatisering: Ansible Best Practices

Red Hat Ansible Best Pratices

Ansible is een zeer flexibel en eenvoudig te gebruiken tool voor automatisering. Dit is geweldig omdat je er snel mee aan de slag kunt om je taken te automatiseren. Maar dit betekent ook dat er veel verschillende manieren zijn om het in te stellen. Daarom zijn enkele tips en beste praktijken essentieel om de zaken op de lange termijn soepel te laten verlopen en tijd en moeite te besparen. Zonder verder oponthoud, hier zijn enkele overwegingen die we hebben opgedaan uit ons werk met Ansible, Tower en AWX gedurende het afgelopen decennium.

Directory structure
Gebruik gewoon de standaard directorystructuur voor je rollen. Je kunt eenvoudig een nieuwe rolstructuur maken met ansible-galaxy init. Voor je playbooks en inventories kun je iets dergelijks gebruiken:

In deze tree zie je vier 00-superglobal.yml bestanden. Die in de all directories zijn symbolische koppelingen naar die in de environments directory. Dit geeft je een manier om variabelen over alle omgevingen in te stellen, zonder ze te herhalen. group_1 en group_2 kunnen ofwel bestanden zijn (ze moeten dan eindigen op .yml) of mappen bevatten met yaml-bestanden.

Ik vind het prettig om de variabele- en inventarisbestanden te voorzien van een nummer als prefix, omdat ansible de bestanden in de group_vars en inventories in lexicografische volgorde verwerkt. Op die manier kan ik de volgorde van het lezen van variabelen controleren, wat handig kan zijn als je yaml-ismen zoals referenties en pointers gebruikt.

Playbook structuur

Als je veel taken in een playbook hebt, wil je misschien overwegen om de taken in dat playbook om te zetten naar een rol. Stel geen variabelen in een playbook in (als je het kunt vermijden). Ik zal daarover verderop in dit document nog wat opmerken. Als je andere playbooks wilt opnemen voor uitvoering in het playbook waar je aan werkt, moet je overwegen dat andere playbook om te zetten naar een rol. Structureer je playbook logisch. Als je niet de pre-tasks, roles en/of post-tasks manier van werken gebruikt, orden je playbook dan op zijn minst op een vergelijkbare manier.

Als je meerdere packages moet installeren op een op yum based systeem, gebruik dan het yum module in plaats van package, en gebruik de lijstfunctie van het naamgedeelte. Dit is veel sneller dan het gebruik van package met een lijst van packages. Als je een echt lange lijst van packages hebt om te installeren, zou je kunnen overwegen packages_fact te gebruiken en vervolgens het verschil in lijsten om de uiteindelijke lijst van packages te krijgen.

Gebruik het laagste niveau van permissions. Gebruik geen blanket become: yes aan het begin van je playbook. Ja, het is makkelijk en handig, maar je opent jezelf ook voor onbedoelde bevoorrechte privileged files en settings.

Role inclusion Gebruik roles/requirements.yml om rollen in je playbook op te nemen. Dit elimineert duplicatie van code. Pin de versie van de rol aan de versie die je wilt. Maak een roles/requirements.yml aan.
Als je playbooks wilt gebruiken met verschillende versies van dezelfde rol, maak dan een apart playbook-directory voor elk playbook aan, en daaronder een aparte roles/requirements.yml.

Collections inclusion: Gebruik collections/requirements.yml om rollen in je playbook op te nemen. Niet alle collecties en modules zijn standaard beschikbaar voor AWX (bijvoorbeeld maven_artifact van community_general). Je moet de gebruikte collecties toevoegen aan het requirements.yml bestand. AWX zal de collecties automatisch downloaden voordat het playbook wordt uitgevoerd.

Ansible.cfg configuration file
Ansible ondersteunt verschillende bronnen voor het configureren van zijn gedrag, waaronder een ini-bestand genaamd ansible.cfg. Het ansible.cfg bestand wordt geplaatst in de directory boven de directories met de playbooks, rollen en omgevingen.

Host key checking is standaard uitgeschakeld in AWX. De controle kan worden ingeschakeld voor Ansible Tower omdat deze op hostbasis is in plaats van containerbasis. U moet het known-hosts-bestand voor de toepassingsgebruiker van de toren vullen voordat u een host in de toren kunt gebruiken.

Uitleg van de instellingen
inventory = environments/sandbox; Omdat in de voorbeeldmappenstructuur alle omgevingen in één project staan, wilt u dat de standaardomgeving wordt verwezen naar degene die het minst schade toebrengt als deze kapot is. Op deze manier moet u een kritischer omgeving specificeren bij het uitvoeren van playbooks via de opdrachtregel.
host_key_checking = False; Dit schakelt de controle van de ssh-hostsleutel uit. In AWX is dit de standaardinstelling, omdat de feitelijke uitvoering van de playbooks plaatsvindt op een aparte uitvoeringscontainer, die op elk moment kan worden vernietigd. Aangezien ook de ssh-gebruiker voor elk playbook anders kan zijn, is er geen gemakkelijke manier om een known_hosts-bestand in awx te pushen. Merk ook op dat de known_hosts-methoden alleen een goede beveiligingsmaatregel zijn als deze vanaf het begin van het bestaan van de host bekend zijn. Bij het gebruik van ansible vanaf de opdrachtregel op een host die persistent is (bestaat al lange tijd), zou ik willen dat host_key_checking wordt ingesteld op true(==uitgelaten), wat de standaardinstelling is voor Ansible.
remote_tmp = /tmp/.ansible/tmp; Dit kan worden gedaan als een extra beveiligingsmaatregel. Bij de initiële installatie van de host, maak een aparte tijdelijke map aan met alleen machtigingen voor de bedoelde ansible-externe gebruiker. Dit zorgt ervoor dat een lokale aanvaller (op het doelsysteem) niet bij de tijdelijke gegevens/scripts kan komen die ansible op het doelwit pusht, zolang die aanvaller geen verhoogde rechten heeft.
remote_user = ansible; Dit is de standaard externe gebruiker die wordt gebruikt. Deze instelling wordt overschreven in AWX door de machine-credentials die zijn ingesteld in het playbook-template.

Variabeldefinities en hun locaties

Ansible is echt flexibel als het gaat om variabelen en hun voorrang. Dit kan je voor een wereld van problemen stellen. Je kunt variabelen definiëren op 22 niveaus in je playbooks. Dat betekent niet dat je ze allemaal moet gebruiken. Minimaliseer het aantal locaties dat je gebruikt.

Ik gebruik meestal alleen het volgende:

• rol/defaults
• 00-superglobal
• group_vars/all
• group_vars/group
• host_vars/host als ik absoluut geen andere optie heb.
• ansible-playbook -e wanneer ik er extra zeker van wil zijn dat ik iets wil doen (schoonmaken van een sandbox-installatie voordat ik opnieuw implementeer)

Ik ben situaties tegengekomen waarin ik door 10 verschillende bestanden moest zoeken, terwijl ik het voorrangsniveau in gedachten hield en het feit dat dictionaries werden samengevoegd en niet overschreven, om te achterhalen waar de variabele veranderde naar het onverwachte resultaat.

Variabelnaamgeving

Gebruik underscores voor je langere variabelennamen. Gebruik alsjeblieft geen CaMeLCaSiNg. Je variabelennaam kan lang genoeg zijn om niet te hoeven overschakelen naar CaMeLCaSiNg om te besparen op typen. Het verbetert ook de leesbaarheid.
Volgens de YAML 1.1-specificatie kunnen eenvoudige sleutels tot 1024 tekens lang zijn.
Gebruik duidelijke variabelennamen. In eenvoudige lussen kun je wegkomen met het gebruik van een enkele letter voor de iterator, maar de leesbaarheid verbetert aanzienlijk wanneer je duidelijke en beschrijvende variabelennamen gebruikt.
Als je ervoor kiest om een andere methode voor het benoemen van variabelen te gebruiken, doe dit dan op een uniforme manier en gebruik overal dezelfde conventie.

Lijsten

Ik gebruik graag een extra inspringniveau om lijsten te definiëren. Dit geeft iets betere leesbaarheid. Kijk naar het onderstaande voorbeeld. Het lijkt misschien geen groot verschil, maar wanneer je dit gebruikt voor complexe dictionaries, zal het duidelijk worden.

YAML ANKERS

YAML heeft een handige functie om YAML-configuraties te dupliceren om op verschillende plaatsen opnieuw te gebruiken. Door de & syntax te gebruiken, kun je de optie van een vorige taak als basis nemen voor de huidige:

Door deze handige verkorte notatie te gebruiken, kun je voorkomen dat je steeds dezelfde dingen moet herhalen, zoals gebruikersnamen, wachtwoorden, URL’s, en andere dingen.

Met meer dan tien jaar ervaring in Ansible, Tower en AWX, hebben we ons helemaal toegelegd op het automatiseren van IT-operaties. We hebben de kunst van automatisering tot in de puntjes onder de knie. Onze kennis van de beste werkwijzen voor Ansible is niet alleen gebaseerd op onze expertise, maar ook op onze toewijding om ervoor te zorgen dat jouw reis naar automatisering zo soepel en effectief mogelijk verloopt. Terwijl de technologie blijft evolueren, kunnen we niet genoeg benadrukken hoe belangrijk het is om beveiliging in je automatisering op te nemen. We lopen voorop bij het integreren van de nieuwste trends en beveiligingsmaatregelen om jouw infrastructuur te beschermen.

We begrijpen dat het navigeren door de complexiteit van automatisering en het zorgen dat je systemen robuust en veilig zijn, best intimiderend kan zijn. Daarom hebben we een team van gecertificeerde experts klaarstaan om je te helpen bij het overwinnen van deze uitdagingen. Of je nu je huidige setup wilt verbeteren, nieuwe automatiseringsstrategieën wilt omarmen, of wilt zorgen dat je systemen veilig zijn tegen de nieuwste dreigingen, wij zijn er om te helpen.

Laat je niet tegenhouden door de complexiteit van automatisering. Maak gebruik van onze expertise en laat ons je begeleiden bij elke stap van je automatiseringsavontuur. Neem vandaag nog contact met ons op om te ontdekken hoe we je organisatie kunnen helpen om voorop te blijven in dit voortdurend veranderende technologische landschap.