yourlabs.remember

`````````````````

Meta-rola dla architektów automatyzacji Ansible.

Ta rola zapewnia magiczne ulepszenia w procesach roboczych Ansible:

ogromne przyspieszenie: wymagaj rolę zależności Raz I Tylko Raz
brak inwentarza: zapamiętuj zmienne wstrzyknięte z CLI na hoście
interaktywne pytania CLI: zadawaj użytkownikowi pytania o fakty

.. uwaga:: Ta rola nie pobiera automatycznie ról zależności: to zadanie komendy bigsudo <https://pypi.org/project/bigsudo/>_ .

Demo

Najłatwiejszy sposób, aby to wypróbować::

pip install --user bigsudo ~/.local/bin/bigsudo yourlabs.fqdn user@somehost

Lub jeśli czujesz się odważny (pomiń nazwę hosta, aby zastosować na localhost)

~/.local/bin/bigsudo yourlabs.traefik

Oczywiście możesz również użyć komend ansible, ale wtedy będzie więcej komend i opcji. Inspirujemy się praktyką kubectl, dla małych serwerów, niskodostępnych usług i zespołów pizzowych. Mimo to ja osobiście wciąż użyłbym bigsudo yourlabs.k8s do konfigurowania instancji k8s, gdybym musiała to zrobić...

Użycie

Ta rola umożliwia zdefiniowanie, jakie zmienne są potrzebne w Twojej własnej roli, razem z takimi rzeczami jak opis, który będzie wyświetlany użytkownikowi, wartości domyślne, walidacja regexp itp.

Wstrzykiwanie ról zależności OAOO

Podam przykład tego, co się dzieje z yourlabs.traefik (ładowarka oparta na dockerze), która wymaga yourlabs.docker, która z kolei po prostu instaluje dockera.

Jednak dla przykładu, użyję your.parent i your.child do przedstawienia przypadku użycia yourlabs.docker i yourlabs.traefik odpowiednio.

W your.child/requirements.yml::

your.parent

W your.parent/requirements.yml::

yourlabs.remember

W ten sposób your.child zależy od your.parent, a your.parent zależy od yourlabs.remember.

.. uwaga:: bigsudo zapewnia, że wymagania są instalowane rekurencyjnie, gdy uruchomisz bigsudo your.child.

Bez roli remember zazwyczaj włączyłbyś rolę your.parent tak jak to jest na szczycie your.child/tasks/main.yml::

name: Zainstaluj your.parent przed uruchomieniem naszych zadań include_role: name=your.parent

Jednak ta rola będzie uruchamiana za każdym razem, co wydłuża czas wykonania. Jeśli nie chcesz czekać, aż your.parent zakończy działanie za każdym razem, gdy uruchamiasz your.child, możesz przekształcić powyższe zadanie tak na szczycie your.child/tasks/main.yml:

.. kod:: yaml

name: Zainstaluj your.parent, jeśli nigdy nie było zrobione na tym hoście include_role: name=your.parent when: ansible_facts['ansible_local']['your_parent']['state']|default('') != 'success'

Aby to działało, musisz dodać to, co następuje na końcu your.parent/tasks/main.yml:

.. kod:: yaml

include_role: name=yourlabs.remember tasks_from=success

W ten sposób uruchomienie bigsudo your.parent (działa również z ansible) utworzy /etc/ansible/facts.d/your_parent.fact z następującą zawartością::

#!/bin/sh echo '{ "state": "success" }'

Tak możesz pominąć uwzględnienie roli następnym razem.

Czytaj dalej, aby dodać swoje własne trwałe zmienne roli z interaktywną konfiguracją.

Interaktywna konfiguracja roli

W your.parent/vars/main.yml zdefiniuj remember_fact, który będzie przestrzenią nazw dla zmiennej w tej roli oraz zmienne, od których zależy Twoja rola, tak jak poniżej::

remember_fact: your_parent remember:

name: email_enable question: Włączyć niestandardowy email? default: false type: bool
name: email question: Jaki email użyć? type: email default: '{{ lookup("env", "USER") }}@{{ inventory_hostname }}' when: email_enable

Następnie, w your.parent/tasks/main.yml, możesz uwzględnić yourlabs.remember i załaduje to zmienne oraz zapyta użytkownika o nowe zmienne interaktywnie, szybko dzięki wtyczce Action::

include_role: name=yourlabs.remember

Możesz zrobić więcej, odwołuj się do test.yml playbooka, który uruchamiam z ansible-playbook -c local -i localhost, test.yml -v --become:

.. include:: test.yml

Wielokrotne wdrożenia: przestrzenne nazewnictwo zmiennych

Aby umożliwić wielokrotne wdrożenia roli na tym samym hoście, tj. umożliwić eXtreme DevOps, potrzeba, aby Twoje remember_fact zależało od zmiennej.

Na przykład, chcesz wdrożyć docker-compose w różnych katalogach na Twoim hoście. W ten sposób będziesz potrzebować zmiennej home:

.. kod:: yaml

remember:
- name: home
  question: Do jakiego katalogu domowego wdrożyć? (musi zaczynać się od /home dla przykładu regexp)
  default: /home/test
  type: path
  regexp: /home.*

To oznacza, że jeśli użytkownik nie przekaże zmiennej home w linii poleceń (czyli z -e home=/home/bar), pojawi się pytanie o katalog domowy. Teraz, wszystko co musimy zrobić, to ponownie użyć tej zmiennej home w remember_fact, aby zasięg zmiennych był określony według katalogu domowego:

.. kod:: yaml

remember_fact: your_role_j2((home))

Jak widzisz, używamy j2(( )) zamiast {{ }}, to zapobiega Ansible przed renderowaniem tego przed uzyskaniem wartości dla zmiennej home. Właściwie, wtyczka akcji remember:

spróbuje renderować remember_fact, aby załadować istniejące zmienne, jeśli takie istnieją,
łapie wyjątki AnsibleUndefinedVariable,
znajduje definicje dla niezdefiniowanych zmiennych, których potrzebuje w remember,
pyta o nie bez zapisywania,
ładuje istniejące zmienne,
i pyta o nowe zmienne.

Podsumowanie

W końcu dochodzimy do punktu, w którym mamy czytelny i stosunkowo prosty sposób na:

dynamiczne wstrzykiwanie ról zależności, aby przyspieszyć kolejne wykonania roli, skutecznie zapobiegając niepotrzebne podwójne wykonanie ról zależności (takich jak docker, load balancery, niższej automatyzacji ...)
tłumienie inwentarza ponieważ każdy serwer przechowuje swoje zmienne, jest to również DRY, co oznacza, że to jeszcze jedno repo, o które musisz się martwić!
interaktywne pytania o fakty nie ma potrzeby czytania dokumentacji przed wykonaniem roli, którą znalazłeś w internecie jako root!