Ansible jest narzędziem wykorzystywanym do automatyzacji procesów administracyjnych, orkiestracji oraz zarządzania konfiguracją. Jest bezagentowy, co oznacza że nie musi być zainstalowany żaden agent na serwerach klientów i nie są one niepotrzebnie obciążane przez niego. Za jego pomocą możemy w krótkim czasie wdrożyć setki serwerów z zainstalowanym i skonfigurowanym oprogramowaniem, które będzie w pełni zdefiniowanym przez nas. Może to być skonfigurowany serwer hostingowy z cPanel lub DirectAdmin, a nawet pojedyncza usługa zainstalowana na tysiącach serwerów. Ograniczeniem w wykorzystaniu tego narzędzia jest tylko nasza wyobraźnia i czas jakim dysponujemy na przygotowanie konfiguracji samego Ansible.
Możemy zarządzać zarówno systemami Linux jak i systemami Windows. Ponadto, możliwe jest wykorzystanie go w urządzeniach sieciowych, dzięki czemu zmiana kawałka konfiguracji w switchach jest znacznie łatwiejsza do wykonania.
Ansible możemy używać na dwa sposoby. Pierwszym z nich jest wydanie komendy ad-hoc bezpośrednio z konsoli dla poszczególnych serwerów z wcześniej zdefiniowanego inventory. Możemy również użyć playbook w którym zawarte są wszystkie zdarzenia jakie mają się wykonać. Playbook wykorzystujemy głównie kiedy chcemy wdrożyć jakąś konfiguracje czy zainstalować kilka usług.
Kiedy chcemy wykonać tą samą komendę na kilku serwerach, użyjemy do tego bezpośrednio komendy ad-hoc. Poniżej demonstruję jedną z prostszych komend oraz krótkiego playbook zawartego w jednym pliku.
[email protected] ~ # ansible localhost -m shell -a "hostname"
localhost | SUCCESS | rc=0 >>
ansible-host.kylos.net.pl
Instalacja httpd - playbook
---
- hosts: localhost
tasks:
- name: Install httpd
yum: name=httpd state=latest
Wynik z uruchomienia playbooka
[[email protected] tmp]# ansible-playbook playbook.yml
PLAY [localhost] ****************************************************************************************************************************************************************************
TASK [Gathering Facts] **********************************************************************************************************************************************************************
ok: [localhost]
TASK [Install httpd] ************************************************************************************************************************************************************************
changed: [localhost]
PLAY RECAP **********************************************************************************************************************************************************************************
localhost : ok=2 changed=1 unreachable=0 failed=0
Powyżej zademonstrowałem tylko instalacje na jednym hoście (konkretnie na localhost). W dalszej części artykułu pokażę użycie Ansible z wykorzystaniem serwerów AWS. Instalować możemy na wszystkich zdefiniowanych hostach w naszym inventory, które może być statyczne lub dynamiczne do wyszukiwania wszystkich instancji przykładowo w AWS EC2. Statyczne inventory domyślnie znajduje się w pliku /etc/ansible/hosts.
Przykładowo może wyglądać tak:
Inventory
[grupa-serwerow]
serwer1.kylos.pl
serwer2.kylos.pl ansible_port=2222 ansible_user=kylos
[www]
www[001:006].kylos.pl
Jeśli połączenie do serwerów odbywa się z użyciem klucza ssh i mamy uprawnienia root, wtedy nie musimy nic konfigurować. Jeśli natomiast chcemy użyć innego użytkownika niż ten z którego obecnie korzystamy oraz port ssh to w inventory możemy użyć parametrów jak przy serwer2.kylos.pl.
Ansible-Galaxy to publiczna biblioteka ról Ansibla napisana przez społeczność. Jej zasoby są ogólnie dostępne i mogą być używane do realizacji najróżniejszych zadań administracyjnych. Niestety w większości przypadków zawarte w niej role mają funkcję wspierającą. Praktyka pokazuje że wdrożenie kompleksowego rozwiązania wymaga w nich wielu modyfikacji, aby spełniały nasze wszystkie oczekiwania.
Biblioteka znajduje się pod adresem https://galaxy.ansible.com/. Jeśli wykorzystamy znajdującą się pod tym linkiem wyszukiwarkę i wpiszemy słowo „apache”, prawdopodobnym jest jako pierwsze w wynikach wyszukiwania może pojawić się nam poniższa rola:
https://galaxy.ansible.com/geerlingguy/apache
Na jej przykładzie w dalszej części artykułu zademonstrujemy instalacje serwera WWW opartego o Apache.
Instalacja czy pobranie takiej roli może odbyć się przez wydanie poniższego polecenia:
ansible-galaxy install geerlingguy.apache
To i inne polecenia możecie znaleźć również bezpośrednio w dokumentacji danej roli w bibliotece.
W tej części użyje 3 serwerów uruchomionych w AWS z zainstalowanym systemem Amazon Linux. Na dwóch z tych serwerów zainstalujemy serwer www, a na trzecim nie uwzględnimy żadnych zmian
W pierwszej kolejności ściągamy role (chyba, że zrobiliśmy to wcześniej) geerlingguy.apache:
ansible-galaxy install geerlingguy.apache
# ansible-galaxy install geerlingguy.apache
- downloading role 'apache', owned by geerlingguy
- downloading role from https://github.com/geerlingguy/ansible-role-apache/archive/3.0.0.tar.gz
- extracting geerlingguy.apache to /root/.ansible/roles/geerlingguy.apache
- geerlingguy.apache (3.0.0) was installed successfull
Użyjemy tutaj wcześniej zdefiniowanego inventory i skonfigurowanego Ansibla tak aby logował się bezpośrednio po kluczu na instancje po użytkowniku ec2-user i nadawał uprawnienia użytkownika root.
Do tego w konfiguracji ansible.cfg użyłem:
[privilege_escalation]
become=True
become_method=sudo
Nasze inventory wygląda teraz tak jak poniżej:
ansible_inventory
[all]
ansible00 ansible_host=54.211.109.9 ansible_user=ec2-user
ansible01 ansible_host=18.208.169.62 ansible_user=ec2-user
ansible02 ansible_host=35.170.202.224 ansible_user=ec2-user
Nasz playbook wygląda tak:
ansible-playbook.yml
---
- hosts: all
roles:
- role: geerlingguy.apache
when: ( inventory_hostname == "ansible00" ) or ( inventory_hostname == "ansible01" )
tasks:
- name: Verify hosts with apache
service: name=httpd state=running
ignore_errors: yes
Teraz możemy przejść do uruchomienia playbooka wydając komendę:
ansible-playbook -i ansible_inventory ansible-playbook.yml
Poniżej przedstawiam zrzut ekranu z ostatnimi informacjami widocznymi na ekranie:
W artykule zostały zawarte tylko częściowe informacje ogólne, które pomogą zacząć pracę z tym narzędziem. Domyślnie na końcu wykonania playbooka nie dostaniecie Państwo informacji z czasem wykonania poszczególnych zadań. Do tego wykorzystuje tzw. „callback_whitelist” z parametrem „profile_tasks”. Upraszcza on znacznie możliwość optymalizacji poszczególnych zadań co przydaje się przy dużych projektach.