Udostępnij!FacebookTwitterLinkedInWraz z wersją 2.8, w Ansible pojawiła się pewna nowość – Ansible Content Collection. Jest to nowa struktura danych (dotychczas największa pod względem contentu), która pozwala łączyć w jednej jednostce role, playbooki, pluginy, czy moduły. Collection znajduje się m.in. w największym repozytorium dla Ansible – hubie Galaxy od wersji 3.2. Podobnie jak role, collection przyjmuje […]
Udostępnij!
Wraz z wersją 2.8, w Ansible pojawiła się pewna nowość – Ansible Content Collection.
Jest to nowa struktura danych (dotychczas największa pod względem contentu), która pozwala łączyć w jednej jednostce role, playbooki, pluginy, czy moduły. Collection znajduje się m.in. w największym repozytorium dla Ansible – hubie Galaxy od wersji 3.2.
Podobnie jak role, collection przyjmuje formę elementów hierarchicznie ustrukturyzowanych w katalogach. Przykładowo, stworzenie schematu dla nowego pustego collection wygląda następująco:
[ansible@poznan ~]$ ansible-galaxy collection init altkom.collection
[ansible@poznan ~]$ tree altkom
altkom
└── collection
├── docs
├── galaxy.yml
├── plugins
│ └── README.md
├── README.md
└── roles
Jak sama nazwa wskazuje, folder docs służy do przechowywania dokumentacji o collection; galaxy.yml to plik zawierający niezbędne informacje (metadane) do jego zbudowania. Z kolei w folderze plugins możemy umieścić dodatkowe wykorzystywane pluginy i moduły, folder roles będzie zaś zawierał poszczególne role wchodzące w skład naszego collection. Oprócz roles, czasami będziemy potrzebować plików playbook dołączanych w osobnym folderze playbooks, testów w folderze tests albo skryptów w folderze scripts. Pliki README dołączane są do collection w formacie Markdown.
Aby zainstalować collection z Ansible Galaxy, należy posłużyć się schematem:
ansible-galaxy collection install namespace.collection
gdzie namespace – nazwa organizacji, usera community itp.
collection – nazwa collection, które chcemy zainstalować z określonego namespace
Dla przykładu posłużymy się collection php_roles z namespace geerlingguy:
ansible-galaxy collection install 'geerlingguy.php_roles’
Podczas instalacji collection, domyślnie instaluje się ostatnia wersja. Możemy jednak również wybrać poprzednie, np.
ansible-galaxy collection install 'geerlingguy.php_roles:==0.9.5'
zainstaluje collection php_roles z namespace geerlingguy w wersji 0.9.5.
Innym przykładem identyfikatorów wersji collection może być np.:
!=0.9.6 – zainstaluj collection byle nie w wersji 0.9.6
<0.9.6 – zainstaluj collection w wersji niższej od 0.9.6
Aktualną stabilną wersją Ansible jest 2.9.9. W wydaniu deweloperskim znajduje się także opcja pobrania collection. Aby to zrobić w celu udostępnienia offline bez dostępu do servera zewnętrznego, możemy posłużyć się poleceniem:
ansible-galaxy collection download geerlingguy.php_roles
Jak obrazowo przedstawić specyfikę collection?
W Ansible Galaxy znajduje się kolekcja poszczególnych, związanych z PHP, roles autorstwa Jeffa Geerlinga. Posiada ona namespace geerlingguy:
[ansible@poznan ansible]$ ansible-galaxy search --author geerlingguy php | grep php
geerlingguy.apache-php-fpm Apache 2.4+ PHP-FPM support for Linux.
geerlingguy.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
geerlingguy.php-memcached PHP Memcached support for Linux
geerlingguy.phpmyadmin phpMyAdmin installation for Linux
geerlingguy.php-mysql PHP MySQL support for Linux.
geerlingguy.php-pear PHP PEAR library installation.
geerlingguy.php-pecl PHP PECL extension installation.
geerlingguy.php-pgsql PHP PostgreSQL support for Linux.
geerlingguy.php-redis PhpRedis support for Linux
geerlingguy.php-tideways Tideways PHP Profiler Extension for Linux
geerlingguy.php-versions Allows different PHP versions to be installed.
geerlingguy.php-xdebug PHP XDebug for Linux
geerlingguy.php-xhprof PHP XHProf for Linux
Aby użyć jednej z nich, np. php-pgsql w celu komunikacji PHP z bazą danych Postgresql, możemy użyć komendy instalującej role:
[ansible@poznan ~]$ ansible-galaxy role install geerlingguy.php-pgsql
Zakładając, że nasza aplikacja będzie korzystać z buforowania pamięci podręcznej, bazy danych Postgresql, biblioteki PEAR, repozytorium rozszerzeń PECL oraz kilku innych technologii – używając struktur roles musielibyśmy zainstalować co najmniej kilka z nich.
W celu utrzymania wszystkich niezbędnych dla developera PHP technologii w jednej strukturze, lepszym pomysłem jest stworzenie struktury wyższego rzędu – collection, takiego jak przywołane tu collection geerlingguy.php_roles. Jeśli spojrzymy na katalog, w którym zainstalowane zostało collection, zauważymy logiczną i czytelną strukturę:
[ansible@poznan ansible_collections]$ tree -L 3 geerlingguy/
geerlingguy/
└── php_roles
├── FILES.json
├── MANIFEST.json
├── README.md
├── roles
│ ├── php
│ ├── php_memcached
│ ├── php_mysql
│ ├── php_pear
│ ├── php_pecl
│ ├── php_pgsql
│ ├── php_redis
│ ├── php_tideways
│ ├── php_versions
│ ├── php_xdebug
│ └── php_xhprof
├── scripts
│ ├── deploy.yml
│ └── templates
└── tests
└── integration
W drzewie katalogów collection geerlingguy.php_roles dobrze widoczna jest koncepcja jednej większej struktury mieszczącej role związane ze środowiskiem PHP (które poza tym mogą występować samodzielnie). Dodatkowo w collection znalazło się miejsce na skrypt deploy.yml zawierający m.in. zadania, które mają się wykonać jako pierwsze (pre_tasks), sekcję budowania collection (build) czy też publikację (publish).
Folder templates zawiera wzorce Jinja2. Nie zabrakło również miejsca na kolejny folder, w którym znalazł się playbook związany z testowaniem środowiska.
Po udanej instalacji collection geerlingguy.php_roles jest gotowe do użycia np. w takim playbooku:
[ansible@poznan ansible]$ cat collection_php_roles.yml
---
- hosts: all
collections:
- geerlingguy.php_roles
roles:
- php
- role: php-versions
vars:
php_version: '7.3'
Źródłem metadanych, dzięki którym dowiadujemy się, czy dane collection spełni nasze oczekiwania jest plik galaxy.yml. Oto lista elementów, które Ansible collection powinien zawierać w galaxy.yml:
- namespace – nazwa miejsca, gdzie collection jest przechowywane. Może zawierać wyłącznie małe litery i podkreślnik.
- name – nazwa collection
- version – bieżąca wersja
- readme – ścieżka do pliku readme w formacie Markdown
- authors – informacja o autorach collection
- license – akceptowalne przez Ansible Galaxy licencje: https://spdx.org/licenses/
- tag
- dependencies – informacja o zależnych collection, które muszą zostać zainstalowane włącznie z bieżącym collection
- repository – URL do repozytorium
- description – krótki opis funkcjonalności danego collection.
Schemat budowy collection składa się z czterech etapów:
-
- Przygotowania szkieletu konstrukcji
ansible-galaxy collection init namespace.collection_name
-
- Dokonania odpowiednich zmian w kodzie – edycji pliku galaxy.yml, dodania role, playbook, scripts itp.
- Zbudowania collection (musi być wykonane z katalogu, w którym znajduje się collecion):
ansible-galaxy collection build
W wyniku tego polecenia tworzony jest plik namespace-collection_name-1.0.0.tar.gz
- Publikacji, np. w Ansible Galaxy:
ansible-galaxy collection publish
Stale rosnąca popularność Ansible jako narzędzia do automatyzacji, coraz większa użyteczność tego rozwiązania i jego szerokie zastosowanie, skutkują pojawianiem się kolejnych udogodnień i pomysłów na całościowe ujęcie spotykanych na co dzień problemów. Pojawienie się collection pozwala ujednolicić i ustrukturyzować szerszy zakres zadań, przed którymi stoi administrator zarządzający automatyzacją instalacji, konfiguracji czy wprowadzeniem jakiejkolwiek zmiany w środowisku, nad którym ma panować.
