Społeczność Ansible ciągle zaskakuje nową zawartością – wtyczkami i modułami – co generuje wiele nowej pracy dla tych, którzy zajmują się utrzymaniem Ansible, ponieważ nowy kod należy jak najszybciej zintegrować z repozytoriami. Niekiedy nie udaje się dotrzymać terminów, co opóźnia uruchomienie niektórych gotowych produktów do następnej oficjalnej wersji Ansible Engine. Do niedawna użytkownicy końcowi mieli tylko jeden sposób na pozyskanie nowej zawartości Ansible – razem z nową wersją Ansible Engine.
Aby wyeliminować niedogodności, społeczność Ansible rozpoczęła pracę nad bardziej elastycznymi opcjami tworzenia i pozyskiwania zawartości.
Red Hat Ansible Engine 2.8: w kierunku nowych metod przetwarzania zawartości Ansible
W odpowiedzi na prośby użytkowników nastąpiły zmiany w Ansible Engine 2.8, dotyczące przetwarzania zawartości, która nie jest częścią oficjalnego wydania. Te zmiany pozwolą wprowadzić nowy sposób dostarczania zawartości użytkownikom, który nie będzie zależał od administratorów Ansible podczas zarządzania zarówno zawartością Ansible, jak i kodem samej platformy.
Planowane jest, że w następnych wydaniach twórcy (Creators) zawartości będą mogli dostarczać ją w postaci specjalnych paczek, tzw. Kolekcji (Collection), które będzie można instalować w odpowiednim miejscu na głównym węźle Ansible (węzeł kontrolny) lub na węźle zarządzanym (węzeł zarządzany). Twórca kolekcji będzie bezpośrednio w paczce określać szczegóły wykonywania za pomocą ról i playbooków. Dzięki powyższym zmianom w Ansible Engine kolekcje staną się jednym z narzędzi, które pozwolą odłączyć wydanie zawartości od wydania oficjalnych wersji Ansible Engine..
Nowa konstrukcja Become
Konstrukcja Become istnieje już od dawna, ale od wersji 2.8 słowo BECOME jest domyślnie używane w Ansible Engine do żądania hasła przy podnoszeniu uprawnień (uprawnienia sudo w systemach *nix lub tryb enable na urządzeniach sieciowych). Innymi słowy, teraz BECOME to standardowe narzędzie podnoszenia uprawnień, które samo radzi sobie z docelowym systemem.
Oto przykład jego użycia:
ansible-playbook --become --ask-become-pass site.yml
BECOME password:
Ponadto w Ansible Engine 2.8 pojawił się wtyczka BECOME, która działa jak doas w systemach Linux i jak runas w systemach Windows, pozwalając na wykonywanie działań w imieniu określonego użytkownika. Dla podniesienia uprawnień na urządzeniach sieciowych wykorzystywana jest wtyczka become o nazwie enable.
Wyszukiwanie interpretera Pythona
Możliwe, że napotkałeś taki błąd:
/usr/bin/python: bad interpreter: No such file or directory
Chodzi o to, że w poprzednich wersjach Ansible Engine domyślnie zakładano, że główny (używany domyślnie) interpreter Pythona znajduje się w folderze /usr/bin/python. Od wersji 2.8 Ansible wyszukuje interpreter na każdym docelowym systemie, najpierw porównując go z tabelą ścieżek i nazw plików wykonywalnych głównego interpretera Pythona w różnych dystrybucjach, a następnie używając uporządkowanych list zapasowych (fallback list), więcej informacji znajdziesz w .
Pliki Retry nie są już domyślnie tworzone
Czy długo szukałeś na dysku plików .retry? Jeśli od dawna korzystasz z Ansible, zapewne jest ich sporo, a tylko zajmują cenne miejsce. Od wersji 2.8 Ansible Engine domyślnie nie tworzy już tych plików (co można cofnąć, edytując używany plik ansible.cfg).
Zaktualizowane podsumowanie rozgrywki
Fragment z :
Podsumowanie rozgrywki teraz uwzględnia zadania (tasks) o statusie ignored i rescued, a także ok, changed, unreachable, failed oraz skipped, dzięki dwóm nowym licznikom statystyki w wtyczce callback o nazwie default. Zadania failed, dla których ustawiono flagę ignore_errors: yes, są traktowane jako ignored. Zadania failed, dla których następnie wykonano sekcję rescue, są traktowane jako rescued. Należy zauważyć, że w przeciwieństwie do poprzednich wersji Ansible, zadania rescued nie są już traktowane jako failed.
A w tabeli podsumowania rozgrywki po zakończeniu wykonywania playbooka w przypadku hostów pojawiły się dodatkowe kolumny skipped, rescued oraz ignored:
Chmury i kontenery
W wersji 2.8 wprowadzono ulepszenia i dodatki w modułach chmurowych i kontenerowych do pracy z Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, i . Warto również zauważyć, że pliki TOML można teraz używać jako źródło inventory.
Paramiko
Czy korzystasz z Red Hat Ansible Network Automation? Ansible Engine 2.8 nie zawiera już paramiko i nie jest od niego zależny. Domyślnie Ansible Engine używa ssh. Jeśli potrzebujesz paramiko, możesz go zainstalować poleceniem pip install paramiko.
Jeśli potrzebujesz wsparcia w korzystaniu z paramiko w ramach subskrypcji Red Hat, zapoznaj się z artykułem w bazie wiedzy .
Nowa wersja Red Hat Ansible Engine wzbogaciła się o imponującą listę ulepszeń i zmian, z którymi można zapoznać się w szczegółach .
Red Hat Ansible Tower 3.5: więcej automatyzacji
Od końca maja dostępna jest nowa wersja Red Hat Ansible Tower 3.5, oferująca kilka istotnych ulepszeń dla automatyzacji, o których porozmawiamy, jeśli jeszcze sam nie miałeś okazji ich sprawdzić.
Zacznijmy od kluczowych informacji:
- Wsparcie dla Red Hat Enterprise Linux 8;
- Wsparcie dla zewnętrznych magazynów danych uwierzytelniających za pomocą odpowiednich wtyczek;
- Wsparcie dla wtyczek become w Ansible Tower.
Dodatkowo w nowej wersji naprawiono ponad 160 zgłoszonych błędów i usterek.
Wsparcie dla Red Hat Enterprise Linux 8
Często powtarzamy, że Red Hat Enterprise Linux (RHEL) to niezawodna i uniwersalna baza do budowy, na przykład, chmur hybrydowych. Ansible Tower 3.5 (podobnie jak Ansible Engine 2.8) zapewnia zarządzanie hostami RHEL 8 i może działać na platformie Red Hat Enterprise Linux 8 jako węzeł zarządzający systemem Red Hat Ansible Automation.
Zewnętrzne magazyny danych uwierzytelniających
Oprócz wbudowanego magazynu danych uwierzytelniających, Ansible Tower 3.5 może teraz korzystać także z zewnętrznych magazynów danych, ponieważ czasami wymagane jest udostępnienie danych uwierzytelniających dla rozproszonych aplikacji. Dlatego nowa wersja Ansible Tower może bezpośrednio współpracować z różnymi rozwiązaniami do przechowywania haseł i kluczy, takimi jak:
- HashiCorp Vault;
- CyberArk AIM;
- CyberArk Conjur;
- Microsoft Azure Key Vault.
Szczegóły dotyczące współpracy z tymi systemami przedstawione są w dokumentach .
Nowe wtyczki do pracy z inwentory i podwyższania uprawnień
Śledząc rozwój Ansible Engine, Ansible Tower 3.5 oferuje nowe wtyczki inwentory oraz wtyczkę do korzystania z nowego narzędzia do podwyższania uprawnień.
Dzięki Ansible Tower może teraz korzystać jako źródło inwentory z platform Microsoft Azure, Google Cloud Platform oraz Red Hat OpenStack Platform, co zapewnia współpracę w hybrydowych środowiskach chmurowych 'od ręki'.
Nowa wtyczka do podwyższania uprawnień zapewnia kompleksową obsługę zadań związanych z podwyższaniem uprawnień, oferując znacznie większą elastyczność i kontrolę w porównaniu z tradycyjnymi sudo i su.
Przeprojektowany interfejs UI list
W nowej wersji praca z listami stała się znacznie łatwiejsza. Można je rozwijać, aby wyświetlić szczegóły, oraz zwijać, by pokazać więcej elementów na ekranie. Listy można również sortować według różnych pól i filtrować praktycznie według każdej cechy.
Ulepszone metryki
Metryki zyskały tzw. endpointy (/api/v2/metrics), dzięki którym Ansible Tower jest teraz łatwo monitorowane za pomocą Prometheus i innych podobnych systemów, a także można jednocześnie korzystać z kilku systemów, w tym chmurowych.
Ansible Tower 3.5 jest już dostępny do pobrania, może być zainstalowana zarówno lokalnie, jak i za pomocą Vagrant lub Amazon AMI.
Webinary o Ansible: podnieś swoje umiejętności
Nieustannie uzupełniane repozytorium webinarów na temat:
4 czerwca odbył się webinar , poświęcony nowym i ulepszonym funkcjom Red Hat Ansible Tower i Red Hat Ansible Engine. Wkrótce pojawi się w repozytorium.
W języku rosyjskim dostępny jest.
Źródło: habr.com
