Anfang Dezember ist mit der Ansible Automation Platform 2.1 (AAP 2.1) die erste stabile Version der AAP erschienen. Wir geben einen Überblick über die Neuerungen und wie eine Migration von Ansible Tower zu AAP erfolgen kann.
Was ist neu?
Die grosse Neuerung ist die Auftrennung des Towers in eine Control-Ebene (Ansible Controller) und eine Execution-Ebene (Execution Enviroments)
Ansible Controller
Vereinfacht heisst Ansible Tower neu Ansible Controller. Wer bereits die neuste Version von Tower (3.8.4) installiert hat, wird beim Einloggen bemerkt haben, dass das Naming im Logo schon zu AAP gewechselt hat:
Die Versionierung zwischen Ansible Tower und Ansible Controller ist übrigens fortlaufend: Auf die Versionen von Ansible Tower 3.X folgen die Versionen Ansible Controller 4.X.
Execution Environments
Bisher konnten auf Ansible Tower mit Python Virtual Enviroments verschiedene Umgebungen verwendet werden (Ansible Versionen, benötigte Python Module etc.). Neu werden solche Umgebungen in sogenannte Automation Execution Environments gepackt. Dies erfolgt mit dem CLI-Tool ansible-builder und resultiert in einem Container. Dieser basiert auf RHEL UBI 8 und beinhaltet Python, Ansible-Core und allfällige Collections sowie Python-Module. Auf der Red Hat Registry stehen vorgefertigte Versionen zur Verfügung. Selbstgebaute Execution Environments können über einen Private Automation Hub, also ein Repository mit Ansible Content, anderen Benutzern und Teams zur Verfügung gestellt werden. Die Erstellung dieser Execution Environments muss nicht bei den Administratoren liegen – Teams können Execution Environments selber bauen, auf den Automation Hub platzieren und benutzen!
Migrating from Tower to Controller
Das Installations-File für den Controller ist leider nicht bei den Tower-Releases zu finden. Etwas umständlich muss das neue File im Red Hat Customer Portal unter den Downloads gesucht werden. Dort steht aber wie gewohnt ein File für die „normale“ Installation und ein Bundle-Installer, der alle benötigten rpm-Packete beinhaltet.
Wir haben im folgenden Fall erfolgreich ein Update einer bestehenden Ansible-Tower Installation (Version 3.8.1, Bundle-Installer) zu Ansible-Controller 4.1 durchgeführt.
Nach erfolgreichen Download des Bundle-Installers muss dieser entpackt werden:
tower /opt# tar xvzf ansible-automation-platform-setup-bundle-2.1.0-1.tar.gz tower /opt# ll ansible-automation-platform-setup-bundle-2.1.0-1 ansible-automation-platform-setup-bundle-2.1.0-1.tar.gz ansible-tower-setup-bundle-3.8.1-1 ansible-tower-setup-bundle-3.8.1-1.tar.gz tower /opt#
Im neuen Folder musste das Inventory-File an die neuen Gegebenheiten angepasst werden. Hier das alte File „inventory“ für Ansible-Tower 3.8.1:
tower /opt/ansible-tower-setup-bundle-3.8.1-1# cat inventory
[tower]localhost ansible_connection=local [database] [all:vars] admin_password='XXXXX' pg_host='' pg_port='' pg_database='tower' pg_username='tower' pg_password='XXXXX' rabbitmq_port=5672 rabbitmq_vhost=tower rabbitmq_username=tower rabbitmq_password='XXXXX' rabbitmq_cookie=cookiemonster rabbitmq_use_long_name=false
Und das neue File „inventory“ für AAP 2.1 resp. Ansible-Controller 4.1:
tower /opt/ansible-automation-platform-setup-bundle-2.1.0-1# cat inventory
localhost ansible_connection=local [automationcontroller:vars] peers=execution_nodes [execution_nodes] [automationhub] [database] [servicescatalog_workers] [sso] [all:vars] admin_password='XXXXX' pg_host='' pg_port='' pg_database='tower' pg_username='tower' pg_password='XXXXX' registry_url='registry.redhat.io' registry_username='XXXXX' registry_password='XXXXX' receptor_listener_port=27199 automationhub_admin_password='' automationhub_pg_host='' automationhub_pg_port='' automationhub_pg_database='automationhub' automationhub_pg_username='automationhub' automationhub_pg_password='' automationhub_pg_sslmode='prefer'
Das neue Inventory-File beschreibt, dass auf dem Server nur der Ansible-Controller installiert und die Registry von Red Hat verwendet wird. Würde lokal ein Private Automation Hub installiert werden, könnte das mit demselben Bundle-Installer erfolgen. Aber Achtung! Ansible-Controller und Private Automation Hub können nicht auf demselben Server laufen und müssen auf getrennten Server installiert werden.
Nach dem Bereitstellen des Inventory-Files liess sich das Update in gewohnter Form starten:
tower /opt/ansible-automation-platform-setup-bundle-2.1.0-1# ./setup.sh
Das Update lief erfolgreich durch und eine neue Login-Maske präsentiert sich.
Einmal eingeloggt, stellen wir sofort fest, dass das Aussehen der Oberfläche ähnlich ist wie bis anhin. Das Update auf Patternfly 4 bringt nur geringfügige Änderungen der Menus mit sich.
Stolpersteine
Da das Ausführen eines Ansible Playbooks neu in einem Execution Environment erfolgt und diese in der vorliegenden Konfiguration von registry.redhat.io bezogen werden, mussten entsprechende Proxies unter Settings -> Job settings -> Extra Enviroment Variables definiert sein. Anderfalls hätte unsere Firewall die Versuche, die Execution Environments herunterzuladen, geblockt. Die bestehenden Git-Repositories, welche unsere Projekte beheimaten, mussten natürlich immer noch erreichbar sein. Zusammen mit der Tatsache, dass für Git eine CIDR-Notation (172.168.0.0/16) von Netzwerken nicht möglich ist, führte das zu folgender Konfiguration der zusätzlichen Environment Variables:
{
"http_proxy": "http://proxy.puzzle.ch:8080",
"https_proxy": "http://proxy.puzzle.ch:8080",
"no_proxy": "puzzle.ch"
}
Da eine neuere Version von Python (3.8) verwendet wird als vorher, verhielten sich gewisse Ansible Module leicht anders. So mussten wir bei vmware-Modulen explizit festhalten, dass das Self-Signed Zertifikat des ESX-Hosts nicht geprüft wird.
- name: get vm_info
vmware_vm_info:
hostname: "{{ vcenter }}"
username: "{{ username }}"
password: "{{ password }}"
vm_type: vm
validate_certs: no #<-- neu nötig! Default ist "yes"
delegate_to: localhost
Damit war alles Nötige getan und unsere bestehenden Playbooks liefen erfolgreich auf dem neuen Ansible Controller 4.1!
Zu beachten ist aber Folgendes: Hätten wir auf unserem Ansible-Tower zusätzliche Python-Module installiert, welche nicht in den Execution Environments auf registry.redhat.io vorhanden sind, so müssten wir diese in eigene Execution Environments packen. Um diese anschliessend zu verwenden, wäre die Installation eines Private Automation Hubs nötig.
Zusammenfassung
Wir konnten zeigen, dass ein Update von Ansible Tower zu Ansible Controller einfach möglich ist und einem Umstieg nichts im Wege steht. Lassen wir die wichtigen Punkte ganz in Ansible-Manier durch die Kuh sagen:
Kuh? Was es damit auf sich hat, kannst du in diesem Blogpost nachlesen.