Ansible auf Linux Arch installieren
Die Installation von Ansible auf Linux Arch ist weitestgehend ein No-Brainer. Für das Ansible selber ist das Paket „ansible“ notwendig. Wer, wie ich, seine Playbooks checken lassen möchte, installiert das Paket „ansible-lint“ einfach mit.
[root@barney ansible]# pacman -S ansible ansible-lint
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Pakete (3) python-ruamel-yaml-0.15.89-1 ansible-2.7.9-1 ansible-lint-4.1.0-1
Gesamtgröße des Downloads: 0,33 MiB
Gesamtgröße der installierten Pakete: 81,56 MiB
:: Installation fortsetzen? [J/n]
:: Empfange Pakete...
python-ruamel-yaml-0.15.89-1-x86_64 279,1 KiB 5,80M/s 00:00 [#######################################################################################################################] 100%
ansible-lint-4.1.0-1-any 60,9 KiB 0,00B/s 00:00 [#######################################################################################################################] 100%
(3/3) Prüfe Schlüssel im Schlüsselring [#######################################################################################################################] 100%
(3/3) Überprüfe Paket-Integrität [#######################################################################################################################] 100%
(3/3) Lade Paket-Dateien [#######################################################################################################################] 100%
(3/3) Prüfe auf Dateikonflikte [#######################################################################################################################] 100%
(3/3) Überprüfe verfügbaren Festplattenspeicher [#######################################################################################################################] 100%
:: Verarbeite Paketänderungen...
(1/3) Installiere ansible [#######################################################################################################################] 100%
Optionale Abhängigkeiten für ansible
sshpass: for ssh connections with password
python-passlib: crypt values for vars_prompt
python-pyopenssl: openssl modules
python-netaddr: for the ipaddr filter
python-systemd: log to journal
python-pywinrm: connect to Windows machines
python-dnspython: for dig lookup
python-ovirt-engine-sdk: ovirt support
python-boto3: aws_s3 module
python-jmespath: json_query support
acme-tiny: openssl_certificate module
(2/3) Installiere python-ruamel-yaml [#######################################################################################################################] 100%
(3/3) Installiere ansible-lint [#######################################################################################################################] 100%
:: Starte post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[root@barney ansible]#
Nachdem Installieren ist es wichtig seine zu managenden Nodes in der /etc/ansible/hosts einzutragen oder wer eine erheblich größere Infrastruktur hat, nutzt die Variante mit den Unterverzeichnissen. Für mich reicht die Variante mit den Textdateien allemale aus. Na dann trage ich mal die Nodes ein.
[root@barney bak]# nano /etc/ansible/hosts
[glusterfs]
192.168.2.143
192.168.2.144
192.168.2.145
192.168.2.146
192.168.2.25
Damit sind die fünf Nodes des zu bauenden GlusterFS eingetragen und ich prüfe auch gleich mal, ob sie für Ansible erreichbar sind, in dem in den klassichen PING Test mache.
[ansible@barney ~]$ ansible all -m ping
192.168.2.144 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.2.146 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.2.143 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.2.145 | SUCCESS => {
"changed": false,
"ping": "pong"
}
192.168.2.25 | SUCCESS => {
"changed": false,
"ping": "pong"
}
[ansible@barney ~]$
Läuft ja wie geschmiert. Alle fünf Odroid-HC2 melden sich, ergo kann sich Ansible über SSH einloggen und Python Befehle absetzen. Dann werde ich den fünf mal ein kleines Playbook vorspielen lassen, was sie zum Software-Update animieren sollte. Das Playbook ist ganz kurz und stößt nur lokal den Update selbst an.
[ansible@barney ~]$ cat syu.yml
---
- name: All hosts up-to-date
hosts: glusterfs
become: yes
tasks:
- name: full system upgrade
pacman:
update_cache: yes
upgrade: yes
[ansible@barney ~]$
Fertig ist das Playbook. Ich habe das Playbook einmal mittels ansible-lint geprüft.
[ansible@barney ~]$ ansible-lint syu.yml
[201] Trailing whitespace
syu.yml:5
[ansible@barney ~]$
Ja okay, es sind hinter dem Text tatäschlich noch Leerzeichen drin, kann ich mir verkneifen – ist aber funktional irrelevant. Na dann mal sehen, was die Nodes zu dem Playbook sagen..
[ansible@barney ~]$ ansible-playbook syu.yml
PLAY [All hosts up-to-date] ******************************************************
TASK [Gathering Facts] ***********************************************************
ok: [192.168.2.146]
ok: [192.168.2.143]
ok: [192.168.2.144]
ok: [192.168.2.145]
ok: [192.168.2.25]
TASK [full system upgrade] **************************************************************************************************************************************************************************************************************************************************************************************************
changed: [192.168.2.146]
changed: [192.168.2.144]
changed: [192.168.2.143]
changed: [192.168.2.145]
changed: [192.168.2.25]
PLAY RECAP ******************************************************************************************************************************************************************************************************************************************************************************************************************
192.168.2.143 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.144 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.145 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.146 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0
[ansible@barney ~]$
Ich freue mich, dass alle fünf sich neue Software geholt haben und der Software Update gut durch lief. Natürlich kann man da noch deutlich mehr steuern, aber für den ersten Test reicht mir das aus. Nach dem Software Update wollte ich auch noch probieren, ob ich alle fünf gleichzeitig Rebooten kann. Dafür habe ich ebenso ein Playbook geschrieben. Auch kein weltbewegendes Zeug.
[ansible@barney ~]$ cat reboot.yml
---
- name: All hosts reboot
hosts: glusterfs
become: yes
tasks:
- name: Unconditionally reboot the machine with all defaults
reboot:
[ansible@barney ~]$
Und das Playbook werfe ich jetzt den fünf Nodes mal vor die Füße und wenn ich das richtig Verstanden habe, rebooten alle fünf Nodes.
[ansible@barney ~]$ ansible-playbook reboot.yml
PLAY [All hosts reboot] **********************************************************
TASK [Gathering Facts] ***********************************************************
ok: [192.168.2.146]
ok: [192.168.2.143]
ok: [192.168.2.144]
ok: [192.168.2.145]
ok: [192.168.2.25]
TASK [Unconditionally reboot the machine with all defaults] **********************
changed: [192.168.2.143]
changed: [192.168.2.145]
changed: [192.168.2.146]
changed: [192.168.2.144]
changed: [192.168.2.25]
PLAY RECAP ***********************************************************************
192.168.2.143 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.144 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.145 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.146 : ok=2 changed=1 unreachable=0 failed=0
192.168.2.25 : ok=2 changed=1 unreachable=0 failed=0
[ansible@barney ~]$
Ist schon ein merkwürdiges Gefühl, wenn da fünf Nodes gleichzeitig rebooten und man das Anlaufen ihrer HDDs hören kann.
Für meinen ersten Ansible Test bin ich zufrieden. In dem nächsten Beitrag werde ich mich Stück für Stück an das automatische Aufsetzen des GlusterFS machen. Denn wenn später weitere Nodes dazu kommen, möchte ich das ja genau mit Playbooks ausführen.
Neueste Kommentare