Общността на Ansible постоянно радва с ново съдържание – плъгини и модули – създавайки и много нова работа за тези, които се занимават с поддръжката на Ansible, тъй като новият код трябва да бъде интегриран в репозitories възможно най-бързо. Понякога не успяват да спазят сроковете и пускането на някои готови за издаване продукти се отлага за следващата официална версия на Ansible Engine. До неотдавна крайният потребител имаше само един начин да получи ново съдържание на Ansible – заедно с новата версия на Ansible Engine.
За да се отстрани неудобството, общността на Ansible започна работа над по-гъвкави опции за създаване и получаване на съдържание.
Red Hat Ansible Engine 2.8: по пътя към нови методи за обработка на Ansible съдържание
В отговор на запитванията на потребителите в Ansible Engine 2.8 бяха въведени промени, свързани с обработката на съдържание, което не е включено в официалното издание. Тези промени ще позволят да се реализира нов начин на доставка на съдържание на потребителите, който няма да зависи от лицата, които поддържат Ansible при управлението както на съдържанието на Ansible, така и на кода на самата платформа.
Планира се, че в следващите издания, създателите на съдържание ще могат да го доставят под формата на специални пакети, наречени Колекции (Collection), които могат да бъдат инсталирани в съответстващото място за изпълнение на основния възел Ansible (control node) или на управляван възел (managed node). Създателят на колекции ще опише подробностите за изпълнение в пакета с помощта на роли и плейбукове. Благодарение на горепосочените промени в Ansible Engine, колекциите ще станат един от инструментите, които ще позволят да се раздели пускането на съдържание от излизането на официалните версии на Ansible Engine.
Нова конструкция Become
Конструкцията Become е налична отдавна, но с версия 2.8 думата BECOME по подразбиране се използва в Ansible Engine за искане на парола при повишаване на правата (sudo права на *nix системи или режим enable на мрежови устройства). С други думи, сега BECOME е стандартен инструмент за повишаване на правомощията, който сам обработва целевата система.
Ето как изглежда пример за използването му:
ansible-playbook --become --ask-become-pass site.yml
BECOME парола:
Освен това, в Ansible Engine 2.8 се появи и плъгинът BECOME, който работи като doas на Linux и като runas на Windows, и позволява изпълнение на действия от името на зададения потребител. За повишаване на привилегиите на мрежовите устройства се използва плъгинът become enable.
Търсене на Python интерпретатор
Възможно е да сте се сблъсквали с такава грешка:
/usr/bin/python: bad interpreter: No such file or directory
Става въпрос, че в предишните версии на Ansible Engine по подразбиране се смяташе, че основният (използван по подразбиране) Python интерпретатор е разположен в папката /usr/bin/python. Започвайки от версия 2.8, Ansible търси интерпретатор на всяка целева система, първо сверявайки с таблицата пътища и имена на изпълними файлове на основния Python интерпретатор в различни дистрибуции, а след това използвайки подредените списъци на резервни интерпретатори (fallback list), подробнее смотрите в .
Retry файловете вече не се създават по подразбиране
Отдавна търсите на диска файлове .retry? Ако отдавна използвате Ansible, техният брой вероятно е значителен, а те само заемат полезно място. Започвайки от версия 2.8, Ansible Engine по подразбиране повече не създава тези файлове (което може да бъде отменено, като редактирате използвания по подразбиране файл ansible.cfg).
Актуализиран Play Recap
Извадка от :
Play Recap сега брои задачите (tasks) със статус ignored и rescued, както и ok, changed, unreachable, failed и skipped, благодарение на два нови статистически брояча в callback плъгина default. Задачите с failed статус, за които е зададен флаг ignore_errors: yes, се считат за ignored. Задачите с failed статус, за които след това е обработена секцията rescue, се считат за rescued. Обърнете внимание, че за разлика от предишните версии на Ansible, rescued задачите вече не се считат за failed.
А в таблицата Play Recap по време на изпълнението на плейбука при хостовете се появиха допълнителни колони skipped, rescued и ignored:
Облаци и контейнери
В версия 2.8 са реализирани подобрения и допълнения в облачните и контейнерните модули за работа с Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, и . Също така е важно да се отбележи, че файловете TOML вече могат да бъдат използвани като източник на инвентар.
Paramiko
Използвате ли Red Hat Ansible Network Automation? Ansible Engine 2.8 вече не съдържа paramiko и не зависи от него. По подразбиране Ansible Engine използва ssh. Ако ви е необходим paramiko, можете да го инсталирате с командата pip install paramiko.
Ако имате нужда от подкрепа за използването на paramiko в контекста на абонамента за Red Hat, моля, консултирайте се с статията в базата знания. .
Така, новата версия на Red Hat Ansible Engine е обогатена с впечатляващ списък от подобрения и промени, с които можете да се запознаете подробно. .
Red Hat Ansible Tower 3.5: Повече автоматизация.
От края на май е налична новата версия Red Hat Ansible Tower 3.5, предлагаща няколко значителни подобрения за автоматизация, за които ще говорим, ако все още не сте ги проверили сами.
И така, най-важното:
- Поддръжка на Red Hat Enterprise Linux 8;
- Поддръжка на външни хранилища на удостоверения с използване на съответните приставки;
- Поддръжка на become-приставки в Ansible Tower.
Освен това, в новата версия са коригирани над 160 регистрирани грешки и проблеми.
Поддръжка на Red Hat Enterprise Linux 8
Често повтаряме, че Red Hat Enterprise Linux (RHEL) е надеждна и универсална основа за изграждане на, например, хибридно облако. Ansible Tower 3.5 (както и Ansible Engine 2.8) осигурява управление на хостове RHEL 8 и може да се стартира на платформата Red Hat Enterprise Linux 8 като управляващ възел на системата Red Hat Ansible Automation.
Външни хранилища на удостоверения
Освен вграденото хранилище на удостоверения, Ansible Tower 3.5 вече може да използва и външни хранилища на удостоверения, тъй като понякога е необходимо да се направят удостоверенията по-достъпни за разпределени приложения. Поради това новата версия на Ansible Tower може да работи директно с различни решения за съхранение на пароли и ключове, например:
- HashiCorp Vault;
- CyberArk AIM;
- CyberArk Conjur;
- Microsoft Azure Key Vault.
Подробности за работата с тези системи са представени в документите. .
Нови приставки за работа с inventory и повишаване на привилегиите.
Следвайки развитието на Ansible Engine, Ansible Tower 3.5 предлага нови inventory-приставки и приставка за новото средство за повишаване на правата.
Благодарение на Ansible Tower вече може да използва платформите Microsoft Azure, Google Cloud Platform и Red Hat OpenStack Platform като източник на inventory, осигурявайки работа с хибридни облачни среди "извън кутията".
Новата приставка за повишаване на правата предлага комплексна обработка на задачи за повишаване на правата, предлагаща много повече гъвкавост и контрол в сравнение с традиционните sudo и su.
Преосмислен UI интерфейс на списъците.
В новата версия работата със списъците стана значително по-удобна. Можете да ги разкривате за показване на подробности и да ги свивате, за да показвате повече елементи на екрана. Списъците също могат да се сортират по различни полета и да се филтрират практически по всяко свойство.
Подобрени метрики
Метрите вече разполагат с така наречените endpoint (/api/v2/metrics), благодарение на които Ansible Tower вече може лесно да се мониторира с помощта на Prometheus и други подобни системи, като същевременно могат да се използват няколко системи, включително облачни.
Ansible Tower 3.5 вече е наличен за изтегляне, може да бъде инсталирана както локално, така и през Vagrant или Amazon AMI.
Уебинари по Ansible: усъвършенствайте своите умения
Постоянно се обновява хранилището на уебинари по темата:
На 4 юни се проведе уебинар , посветен на новите и подобрените функции на Red Hat Ansible Tower и Red Hat Ansible Engine. Скоро ще се появи в хранилището.
На български език е наличен.
Източник: habr.com
