Az Ansible közösség folyamatosan új tartalmakkal örvendeztet meg – bővítményekkel és modulokkal – ezzel rengeteg új munkát teremtve azok számára, akik Ansible-t támogató munkát végeznek, mivel az új kódot a lehető leggyorsabban integrálni kell a tárolókba. Nem mindig sikerül határidőre elkészülni, így néhány teljesen kész termék kiadása a következő hivatalos Ansible Engine verzióra halasztódik. Nemrégig a végfelhasználóknak csupán egy módja volt az új Ansible tartalom megszerzésének – a legújabb Ansible Engine verzióval együtt.
A kényelmetlenségek kiküszöbölésére az Ansible közösség elkezdett dolgozni a tartalom létrehozásának és megszerzésének rugalmasabb megoldásain.
Red Hat Ansible Engine 2.8: Új módszerek az Ansible tartalom kezelésére
A felhasználók kérésére az Ansible Engine 2.8-ban olyan változások léptek életbe, amelyek a tartalom kezelésére vonatkoznak, amelyek nem részei a hivatalos kiadásnak.. Ezek a változások lehetővé teszik egy új tartalomszállítási mód bevezetését a felhasználók számára, amely nem fog függeni az Ansible-t támogatóktól, amikor az Ansible tartalmát és magának a platformnak a kódját kezelik.
A tervek szerint a következő kiadásokban a tartalomkészítők (Creators) speciális csomagokban, úgynevezett Gyűjteményekben (Collection) fogják tudni biztosítani a tartalmat, amelyeket a fő Ansible csomópontban (control node) vagy a kezelt csomópontban (managed node) lehet majd telepíteni. A gyűjtemények készítői közvetlenül a csomagban fogják leírni a végrehajtás részleteit szerepek és playbookok segítségével. A fenti változásoknak köszönhetően az Ansible Engine-ben a gyűjtemények az egyik eszközzé válnak, amelyek leválasztják a tartalom kiadását a hivatalos Ansible Engine verziók kiadásáról..
Új Become konstrukció
A Become konstrukció már régóta létezik, de a 2.8-as verziótól kezdődően a BECOME szó alapértelmezés szerint használatos az Ansible Engine-ben a jelszó kérésére a privilégiumok felemelésekor (sudo privilégiumok *nix rendszereken vagy enable mód routereken). Más szóval, most a BECOME egy szabványos jogosultság-emelő eszköz, amely önállóan kezeli a célrendszert.
Így néz ki a használatának példája:
ansible-playbook --become --ask-become-pass site.yml
BECOME jelszó:
Az Ansible Engine 2.8-ban megjelent a BECOME plugin is, amely a Linux alatt a doas-ként, míg Windows alatt a runas-ként működik, és lehetővé teszi a műveletek végrehajtását adott felhasználó nevében. Az adminisztrátori jogok megszerzéséhez a hálózati eszközökön a become plugin enable használatos.
Python-értelmező keresése
Talán már találkozott a következő hibával:
/usr/bin/python: bad interpreter: No such file or directory
A helyzet az, hogy az Ansible Engine korábbi verzióiban alapértelmezés szerint feltételezték, hogy a fő (alapértelmezett) Python-értelmező a /usr/bin/python mappában található. A 2.8-as verziótól kezdve az Ansible az összes célrendszeren keresi az értelmezőt, először összehasonlítva az alapértelmezett Python-értelmező futtatható fájlok útvonal- és névtáblázatát a különböző disztribúciókban, majd a tartalékértelmezők rendezett listáit használva (fallback list), részletezve a .
A Retry-fájlok alapértelmezés szerint már nem készülnek
Sokáig kereste a .retry fájlokat a lemezen? Ha régóta használja az Ansible-t, biztosan sok van belőlük, és csak értékes helyet foglalnak el. A 2.8-as verzióval az Ansible Engine alapértelmezés szerint már nem hozza létre ezeket a fájlokat (ami visszavonható az alapértelmezett ansible.cfg fájl szerkesztésével).
Frissített Play Recap
Kivonat a :
A Play Recap most már figyelembe veszi az ignored és rescued státuszú feladatokat (tasks), valamint az ok, changed, unreachable, failed és skipped állapotokat, köszönhetően a callback plugin default két új statisztikai számlálójának. A failed feladatok, amelyekhez az ignore_errors: yes jelzőt állították be, ignored-ként számítanak. A failed feladatok közül, amelyekre azután a rescue szakaszt végrehajtották, rescued-ként számítanak. Felhívjuk figyelmét, hogy az Ansible korábbi verzióival ellentétben a rescued feladatok már nem számítanak failed-nek.
A Play Recap táblázatában a playbook végrehajtásának eredményeként a hosztoknál új oszlopok jelentek meg: skipped, rescued és ignored:
Felhők és konténerek
A 2.8-as verzióban javítások és bővítések valósultak meg a felhő- és konténermodulokban az Amazon Web Services, a Microsoft Azure, a Google Cloud, a Digital Ocean, és . Érdemes megjegyezni, hogy a TOML fájlokat most már inventory-forrásként is használhatja.
Paramiko
Használja a Red Hat Ansible Network Automation-t? Az Ansible Engine 2.8 már nem tartalmazza a paramikót, és nem is függ tőle. Az Ansible Engine alapértelmezés szerint ssh-t használ. Ha szüksége van a paramikóra, a pip install paramiko parancsot használva telepítheti.
Ha segítségre van szüksége a paramiko használatához a Red Hat-előfizetés keretében, kérjük, nézze meg a tudásbázis cikket .
Így az új Red Hat Ansible Engine verzió egy jelentős fejlesztés- és változáslistával büszkélkedhet, amelyről részletesebben is olvashat .
Red Hat Ansible Tower 3.5: több automatizálás
Május végétől elérhető az új Red Hat Ansible Tower 3.5 verzió, amely számos komoly fejlesztést kínál az automatizálás terén, amelyeket meg fogunk beszélni, ha még nem ellenőrizték őket.
Tehát először a kulcsfontosságúak:
- Támogatás Red Hat Enterprise Linux 8-hoz;
- Külső hitelesítő tárolók támogatása a megfelelő pluginok segítségével;
- Become-pluginok támogatása az Ansible Towerben.
Ezenkívül az új verzióban több mint 160 bejegyzett hibát és problémát javítottak ki.
Támogatás Red Hat Enterprise Linux 8-hoz
Gyakran ismételjük, hogy a Red Hat Enterprise Linux (RHEL) megbízható és sokoldalú alapot biztosít például a hibrid felhő építéséhez. Az Ansible Tower 3.5 (mint az Ansible Engine 2.8) biztosítja a RHEL 8 hosztok kezelését, és futtatható a Red Hat Enterprise Linux 8 platformon mint a Red Hat Ansible Automation irányító csomópontja.
Külső hitelesítő tárolók
A beépített hitelesítő tárolón kívül az Ansible Tower 3.5 most már külső hitelesítő tárolókat is használhat, hiszen néha szükség van a hitelesítők elérhetőségének javítására a megosztott alkalmazások számára. Ezért az új Ansible Tower verzió közvetlenül képes együttműködni különböző jelszó- és kulcstároló megoldásokkal, például:
- HashiCorp Vault;
- CyberArk AIM;
- CyberArk Conjur;
- Microsoft Azure Key Vault.
A rendszerekkel kapcsolatos további részletek a dokumentációkban találhatók .
Új pluginok az inventory kezelésére és a privilégiumok növelésére
Az Ansible Engine fejlődéséhez követve, az Ansible Tower 3.5 új inventory pluginokat és egy új jogosultságnövelő plugint kínál.
Köszönhetően Az Ansible Tower most már képes Microsoft Azure, Google Cloud Platform és Red Hat OpenStack Platform mint inventory forrást használni, amely lehetővé teszi a hibrid felhő környezetek 'out-of-the-box' működését.
Az új Privilege Escalation plugin átfogó kezelést biztosít a jogosultságok növelésének feladataival kapcsolatban, sokkal nagyobb rugalmasságot és kontrollt kínálva a hagyományos sudo és su megoldásokkal szemben.
Átdolgozott UI-lista felület
Az új verzióban sokkal kényelmesebbé vált a listák kezelése. Azokat ki lehet bontani a részletek megjelenítésére, és össze lehet csukni, hogy több elemet lehessen a képernyőn megjeleníteni. A listák különböző mezők szerint is rendezhetők, és gyakorlatilag bármilyen jellemző szerint szűrhetők.
Fejlettebb metrikák
A metrikák megkapták a szükséges endpointokat (\/api\/v2\/metrics), amelyeknek köszönhetően az Ansible Tower most már könnyen figyelhető Prometheus és más hasonló rendszerek által, és egyszerre több rendszert, köztük felhőbeli megoldásokat is lehet használni.
Az Ansible Tower 3.5 már letölthető, helyben, valamint Vagrant vagy Amazon AMI segítségével is telepíthető.
Webináriumok az Ansible-ről: fejleszd a készségeidet
Folyamatosan bővül a webináriumok adattára a következő témában:
Június 4-én zajlott le webináriumot , amely az új és fejlesztett funkciókat mutatta be a Red Hat Ansible Tower és Red Hat Ansible Engine számára. Hamarosan elérhető lesz a tárolóban.
Orosz nyelven elérhető.
Forrás: habr.com
