Każdy rozwinięty projekt osiąga taki moment , w którym niezbędne jest wprowadzenie w nim pewnych zmian. Mają one zapewnić jego dalszy rozwój i jeszcze większy sukces. Do takiego punktu niewątpliwie doszedł Ansible. Wraz z wydaniem Ansible 2.10, prawdopodobnie w okolicach połowy tego roku, ujrzymy ten sam produkt, ale w nieco odmienionej formule budowy i zarządzania kodem. Dla mnie, jako jednego z programistów, którego kod i całe moduły są częścią Ansible, jest to ciekawe doświadczenie.
Kombajn
Ansible to produkt, w którym dostajemy pełen zestaw narzędzi do automatyzacji procesów związanych z konfiguracją i zarządzaniem elementami infrastruktury. Przez wiele lat ilość kodu w projekcie nieprzerwanie rosła. Dochodziły nowe moduły, część z nich było wspieranych oficjalnie i komercyjnie przez RedHat, inne miały status community supported. Do tej drugiej kategorii należą między innymi mojego autorstwa moduły dla Docker Swarm.
Dla użytkownika Ansible to bardzo wygodny produkt, gdyż w jednej paczce otrzymujemy narzędzia dla szerokiej gamy platform sprzętowych i programowych. Czasami musieliśmy jedynie doinstalować dodatkowe biblioteki dla języka Python, z których moduły Ansible korzystały. Z punktu widzenia utrzymania repozytorium kodu, i kontroli zmian w całym projekcie, zadanie stawało się coraz trudniejsze dla osób zarządzających projektem.
Opiekunowie projektu podjęli decyzję, aby rozdzielić główny kod Ansible od modułów funkcjonalnych, które do wersji 2.9 włącznie znajdowały się w jednym repozytorium.
Nowa struktura projektu Ansible 2.10
Począwszy od wersji Ansible 2.10 główne repozytorium projektu na GitHub, czyli ansible/ansible zawierać będzie jedynie:
- Kod głównych elementów programowych Ansible, czyli
ansible-playbook,ansible-galaxy,ansible-docczyansible-test. - Dokumentację projektu.
- Minimalny zestaw pluginów i modułów niezbędnych do działania Ansible.
Tak utworzony szkielet produktu będzie nosił nazwę ansible-base.
Wszystkie pozostałe moduły czy pluginy zostaną wydzielone do niezależnych zbiorów (Collections). Poszczególne zbiory będą mogły mieć własne polityki life cycle, a co za tym idzie, ich kolejne wersje mogą być wydawane niezależnie od wydań samego Ansible. Oczywiście nie oznacza to, że mogą przestać być one zgodne z narzuconymi standardami programowania czy testowania. Nadal każdy element musi poprawnie przechodzić pełne testy funkcjonalne. Każdy zbiór będzie zamknięty we własnym repozytorium, co niewątpliwie ułatwi zarządzanie zmianami w ich kodzie.
Ułatwienia dla programistów
Z punktu widzenia programisty widzę bardzo dobrą zmianę polegającą na wprowadzeniu bardzo przejrzystej struktury modułów i odwołań do nich. Służyć do tego będą FQCN (Fully Qualified Collection Name). Każdy moduł znajdować się będzie we własnej kolekcji identyfikowanej przez Namespace, których nazwy będą przydzielane przez RedHat. Wiele przestrzeni nazw będzie powiązanych z nazwami vendorów. Na przykład w cisco.ios.ios_config ‘cisco’ odnosić będzie się do namespace, ‘ios’ do kolekcji, a ‘ios_config’ to nazwa modułu. Dodatkowo nazwa kolekcji prawdopodobnie będzie wskazywać, czy dany zbiór utrzymywany jest przez społeczność, czy przez producenta danej platformy.
Instalacja modułów ze wskazanej kolekcji odbywać będzie się za pośrednictwem ansible-galaxy. Dla osób, które Ansible instalują z pakietów przygotowywanych przez wydawcę systemu operacyjnego, prawdopodobnie nic się nie zmieni. Spodziewam się, że szerokie spektrum kolekcji zostanie domyślnie w nich umieszczone.
2 marca zablokowano możliwość dodawania jakichkolwiek zmian do gałęzi devel repozytorium ansible/ansible. 9 marca nastąpi pierwsza migracja modułów i ich testowanie. 23 marca zmiany powinny zostać zakończone i moduły rozdzielone do poszczególnych kolekcji.
[…] Mam nadzieję, że teraz po rozdzieleniu modułów od głównej części projektu Ansible, o czym pisałem niedawno, Cisco zgłosi moduły do oficjalnej […]