Ansible-fællesskabet glæder sig konstant over nyt indhold – plugins og moduler – hvilket skaber meget nyt arbejde for dem, der er involveret i at vedligeholde Ansible, da ny kode skal integreres i repositorier så hurtigt som muligt. Det lykkes ikke altid at overholde tidsfristerne, og lanceringen af nogle produkter, der er klar til frigivelse, udskydes til den næste officielle version af Ansible Engine. Indtil for nylig havde slutbrugeren kun én måde at få nyt Ansible-indhold på – sammen med den nye version af Ansible Engine.
For at afhjælpe dette ubehag er Ansible-fællesskabet begyndt at arbejde på mere fleksible måder at skabe og få indhold på.
Red Hat Ansible Engine 2.8: på vej mod nye metoder til behandling af Ansible-indhold
Som svar på brugernes anmodninger er der i Ansible Engine 2.8 kommet ændringer, der vedrører behandlingen af indhold, som ikke er en del af den officielle udgivelse. Disse ændringer vil muliggøre en ny måde at levere indhold til brugerne, der ikke afhænger af dem, der vedligeholder Ansible, til at styre både Ansible-indhold og koden til selve platformen.
Det er planlagt, at skabere af indhold i kommende udgivelser vil kunne levere det i form af særlige pakker, såkaldte Samlinger (Collection), som kan installeres det relevante sted til udførelse på hovednoden Ansible (control node) eller på den administrerede node (managed node). Skaberen af samlingen vil direkte skrive udførelsesdetaljerne i pakken ved hjælp af roller og playbooks. Takket være de førnævnte ændringer i Ansible Engine vil samlinger blive et af de værktøjer, der gør det muligt at adskille udgivelsen af indhold fra frigivelsen af officielle versioner af Ansible Engine..
Den nye Become-konstruktion
Become-konstruktionen har eksisteret i et stykke tid, men fra version 2.8 bruges BECOME som standard i Ansible Engine til at anmode om adgangskode ved forhøjelse af privilegier (sudo-rettigheder på *nix-systemer eller enable-tilstand på netværksenheder). Med andre ord, nu er BECOME et standardværktøj til at erhverve rettigheder, som selv håndterer målsystemet.
Sådan ser et eksempel på dens brug ud:
ansible-playbook --become --ask-become-pass site.yml
BECOME password:
Derudover er der kommet en BECOME-plugin i Ansible Engine 2.8, som fungerer som doas på Linux og som runas på Windows, og som giver mulighed for at udføre handlinger på vegne af en bestemt bruger. For at hæve rettighederne på netværksenheder bruges become-pluginen enable.
Søgning efter Python-fortolker
Du har måske oplevet en sådan fejl:
/usr/bin/python: bad interpreter: No such file or directory
Det er sådan, at i tidligere versioner af Ansible Engine blev det antaget, at den primære (standardbrugte) Python-fortolker befandt sig i mappen /usr/bin/python. Fra version 2.8 søger Ansible efter fortolkeren på hver målmaskine, først ved at tjekke med tabellen over stier og navne for den primære Python-fortolker i forskellige distributioner, og derefter bruger den de sortere lister af backup-fortolkere (fallback list), se nærmere i .
Retry-filer oprettes ikke længere som standard
Har du længe ledt efter .retry-filer på disken? Hvis du længe har brugt Ansible, er der sikkert mange af dem, og de optager kun værdifuld plads. Fra version 2.8 opretter Ansible Engine ikke længere disse filer som standard (hvilket kan ændres ved at redigere den anvendte standard ansible.cfg-fil).
Opdateret Play Recap
Uddrag fra :
Play Recap tæller nu opgaver (tasks) med status ignored og rescued, samt ok, changed, unreachable, failed og skipped, takket være to nye statistik tællere i callback-pluginet default. Failed-opgaver, som har flaget ignore_errors: yes, tælles som ignored. Failed-opgaver, hvor ræddningssektionen er blevet udført, tælles som rescued. Vær opmærksom på, at i modsætning til tidligere versioner af Ansible tælles rescued-opgaver ikke længere som failed.
Og i Play Recap-tabellen efter udførelsen af playbooken er der tilføjet ekstra kolonner skipped, rescued og ignored for værterne:
Skylagring og containere
Version 2.8 indeholder forbedringer og udvidelser i cloud- og container-moduler til arbejde med Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, og . Det er også værd at bemærke, at TOML-filer nu kan bruges som en inventory-kilde.
Paramiko
Bruger du Red Hat Ansible Network Automation? Ansible Engine 2.8 indeholder ikke længere paramiko og er ikke afhængig af det. Som standard bruger Ansible Engine ssh. Hvis du har brug for paramiko, kan det installeres med kommandoen pip install paramiko.
Hvis du har brug for support til brug af paramiko i forbindelse med Red Hat-abonnementet, så se venligst vidensartiklen. .
Den nye version af Red Hat Ansible Engine har fået en imponerende liste af forbedringer og ændringer, som du kan læse mere om. .
Red Hat Ansible Tower 3.5: Mere automatisering.
Fra slutningen af maj er den nye version Red Hat Ansible Tower 3.5 tilgængelig, som tilbyder flere væsentlige forbedringer til automatisering, og vi vil tale om disse, hvis du ikke har haft tid til selv at tjekke dem.
Så først nøglepunkterne:
- Understøttelse af Red Hat Enterprise Linux 8;
- Understøttelse af eksterne credentials-lagre ved hjælp af relevante plugins;
- Understøttelse af become-plugins i Ansible Tower.
Desuden er mere end 160 registrerede fejl og problemer blevet løst i den nye version.
Understøttelse af Red Hat Enterprise Linux 8.
Vi gentager ofte, at Red Hat Enterprise Linux (RHEL) er en pålidelig og alsidig grundlag for fx opbygning af et hybridcloud. Ansible Tower 3.5 (ligesom Ansible Engine 2.8) muliggør administration af RHEL 8-værter og kan også køre på Red Hat Enterprise Linux 8-platformen som styringsnode i Red Hat Ansible Automation-systemet.
Eksterne credentials-lagre.
Ud over det indbyggede credentials-lager kan Ansible Tower 3.5 nu også bruge eksterne credentials-lagre, da det nogle gange er nødvendigt at gøre credentials lettere tilgængelige for distribuerede applikationer. Derfor kan den nye version af Ansible Tower arbejde direkte med forskellige løsninger til opbevaring af adgangskoder og nøgler, som fx:
- HashiCorp Vault;
- CyberArk AIM;
- CyberArk Conjur;
- Microsoft Azure Key Vault.
Detaljer om arbejde med disse systemer findes i dokumenterne. .
Nye plugins til arbejde med inventory og privilegier.
I takt med udviklingen af Ansible Engine tilbyder Ansible Tower 3.5 nye inventory-plugins og et plugin til det nye privilegeringstjeneste.
Takket være Ansible Tower kan nu bruge Microsoft Azure, Google Cloud Platform og Red Hat OpenStack Platform som inventory-kilder, hvilket muliggør arbejde med hybride cloudmiljøer 'out of the box'.
Det nye privilegeringsplugin giver omfattende håndtering af privilegeringsopgaver og tilbyder betydeligt mere fleksibilitet og kontrol sammenlignet med traditionelle sudo og su.
Forbedret UI til lister.
I den nye version er det blevet meget nemmere at arbejde med lister. De kan udvides for at vise detaljer og foldes sammen for at vise flere elementer på skærmen. Lister kan også sorteres efter forskellige felter og filtreres næsten efter enhver egenskab.
Forbedrede målinger
Målingerne har nu såkaldte endpoints (/api/v2/metrics), som gør det nemt at overvåge Ansible Tower med Prometheus og andre lignende systemer. Derudover kan flere systemer, herunder cloud-baserede, bruges samtidig.
Ansible Tower 3.5 er allerede tilgængelig til download, kan installeres både lokalt og via Vagrant eller Amazon AMI.
Webinarer om Ansible: Opgradér dine færdigheder
Bliver konstant opdateret webinararkivet om emnet:
Den 4. juni blev der afholdt webinar , som fokuserede på de nye og forbedrede funktioner i Red Hat Ansible Tower og Red Hat Ansible Engine. Snart tilgængelig i arkivet.
På russisk er der tilgængeligt.
Kilde: habr.com
