Podejść do tematu zdalnego zarządzania komputerami miałem już kilka. Mając powierzone sobie komputery czy to w salach lekcyjnych czy też w pracowni jakoś nie bardzo chce mi się biegać od komputera do komputera. Stąd poszukiwania jakiegoś wytrychu, którym można by sobie ułatwić życie. Dla pracowni napisałem nawet mały program do zarządzania update'mi i upgrade'ami systemów (w oparciu o Qt4). Pisanie od nowa takiego oprogramowania to jednak dużo pracy i efekt mały w stosunku do włożonego wysiłku. Stąd pomysł, aby wykorzystać coś gotowego.
Znanym i szeroko stosowanym narzędziem jest Puppet. Jednak nie podoba mi się pomysł stosowania ciężkiego klienta na komputerach, które ledwo radzą sobie z zainstalowanym już użytkowym oprogramowaniem. Bliżej za to zainteresowałem się CFEnginem. Wydaje mi się lepszym rozwiązaniem niż Puppet. Napisany w C, zarówno klient jak i serwer nie wymaga dużej ilości zasobów, szczególnie po stronie klienta. Niestety ma on spory minus w postaci dość skomplikowanego języka zapisu oczekiwanego stanu zarządzanych komputerów. Nie jest to problem dla kogoś kto chce się zajmować tym na co dzień. Jednak jeśli chcemy zarządzać komputerami od czasu do czasu to wysoki próg wejścia jest dość odstraszający. Istnieje ciekawy projekt Rudder napisany w Scali, który umożliwia zarządzanie CFEnginem za pomocą przeglądarki. Jednak jak dla mnie to rozwiązanie jest za ciężkie. Na szczęście na horyzoncie pojawił się Ansible.
Ansible jest dość wyjątkowy jak na narzędzie typu "provisionig" ze względu na to, że nie używa dedykowanego programu klienta i wszystkie operacje wykonywane są na klientach za pomocą połączenia ssh. Wystarczy więc zainstalować na zarządzanych komputerach ssh serwer (na serwerach www zazwyczaj już jest) oraz dodać klucz ssh zarządzającego komputera (w pliku ~/.ssh/authorized_keys) . Na komputerze z którego chcemy prowadzić kontrolę instalujemy Ansible i możemy zacząć pracę (może to być inny serwer lub nasz laptop).
Sposób działania Ansible dla jednych będzie wadą, a dla innych zaletą. Wykonując zadania widzimy od razu efekty i wiemy czy zaplanowane działania powiodły się czy też nie. W CFEngine piszemy plik "promises" i przy najbliższym połączeniu klient pobiera go i stara się osiągnąć stan zapisany w pliku. Jeśli chcemy uzyskać informacje czy udało się uzyskać to co chcieliśmy to musimy dopisać kod odpowiedzialny za pobranie raportów. Ansible wydaje się więc wygodniejsze do zarządzania serwerami szczególnie gdy nie jest ich bardzo dużo (chociaż radzi sobie również gdy jest ich sporo). Niestety nie obsługuje na razie komputerów z Windows.
Zarządzanie nie wymaga wiele nauki. Istnieją dwa tryby pracy. Pierwszy to pojedyncze polecenia, przykładowo:
ansible all -m ping - pingowanie klientów. Pierwszy parametr
all oznacza wybór wszystkich grup hostów zdefiniowanych w pliku /etc/ansible/hosts. Można też osobno odwoływać się do grup lub pojedynczych serwerów (po ip lub domenie).
ansible all -a "jakieś polecenie bash" --user=administrator -K - uruchomienie polecenia powłoki jako użytkownik administrator gdzie parametr K każe uruchomić polecenie za pomocą sudo i zapytać ansible o hasło (raz dla wszystkich hostów - stąd muszą mieć ustawione te same hasło jeśli chcemy załatwić pracę jednym poleceniem).
ansible all -m apt -a "pkg=eclipse state=present" --user=administrator -K - użycie modułu apt do instalacji pakietów na systemach debianowych - instalujemy eclipse.
Drugim sposobem jest wykonywanie wielu działań na raz za pomocą tzw. playbook. Są to pliki w YAML, których składnia jest bardzo prosta:
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: write the apache config file
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
notify:
- restart apache
- name: ensure apache is running
service: name=httpd state=started
handlers:
- name: restart apache
service: name=httpd state=restarted
Kolejno deklarujemy w nim z jaką grupą hostów pracujemy, dodajemy zmienne, użytkownika na koncie którego będziemy wykonywać polecenia, oraz zadania. Zadanie ma swój opis - komentarz (name) oraz podany moduł (np. yum) i stan. Po kilku minutach nauki składni można zacząć już pracę i tworzyć proste playbooki.
Małym problemem Ansible może być fakt, że w pliku hosts wpisujemy IP (lub domeny) i gdy mamy komputery o zmiennym IP z DHCP to nie możemy tego zrobić. W przypadku niepowodzenia polecenie nie jest automatycznie ponawiane.
Samo Ansible bardzo mi się podoba i decydujące tutaj poza faktem lekkości po stronie klienta (serwer ssh) jest fakt, że od razu wiem jaki skutek odniosły moje działania. Jednak dla osób, które chciałyby zarządzać dużą ilością desktopów lepszym rozwiązaniem może okazać się CFEngine. Natomiast dla moich potrzeb Ansible świetnie nada się do systemu zarządzania komputerami, który planuje napisać (o czym wkrótce).
