Jak wersjonowałbyś kilka ról w Ansible dla sektora…

W sektorze bankowym, gdzie wymagana jest ścisła kontrola zmian i zgodność z przepisami, zarządzanie wersjami ról Ansible ma kluczowe znaczenie.

Używałbym następującej kombinacji podejść:

System kontroli wersji (Git): Każda rola jest przechowywana w osobnym repozytorium Git. Pozwala to na niezależne wersjonowanie, tworzenie gałęzi i przeglądanie zmian każdej roli.
Semantyczne wersjonowanie (SemVer): Dla każdej roli stosuje się SemVer (MAJOR.MINOR.PATCH).
- MAJOR: Znaczące zmiany, które naruszają kompatybilność wsteczną.
- MINOR: Dodanie nowych funkcji, które zachowują kompatybilność.
- PATCH: Poprawki błędów, które zachowują kompatybilność. Tagami Git oznacza się konkretne wersje.
GitFlow lub podobny proces pracy: Użycie gałęzi develop (do bieżącego rozwoju) i main (do stabilnych wersji gotowych do produkcji). Tworzone są gałęzie funkcji do rozwoju nowych funkcji lub poprawek.
Ansible Galaxy: Do centralnego zarządzania zależnościami i wersjami ról. Można używać prywatnej instancji Ansible Galaxy, aby zapewnić bezpieczeństwo i kontrolę dostępu w środowisku bankowym.

Wymagania (requirements.yml): W playbookach (lub innych rolach zależnych) określa się konkretną wersję potrzebnej roli w pliku requirements.yml.

# requirements.yml
- name: common_config
  src: git@internal-git.bankname.com/ansible-roles/common_config.git
  version: 1.2.0 # Określenie konkretnej wersji
- name: database_server
  src: git@internal-git.bankname.com/ansible-roles/database_server.git
  version: 2.1.5

Automatyczne testy: Każdy commit i każda nowa wersja roli przechodzi przez automatyczne testy (np. z Molecule). Jeśli testy nie przejdą, wersja nie może być oznaczona jako stabilna.
Dziennik zmian (Changelog): W każdym repozytorium roli prowadzony jest plik CHANGELOG.md lub jego odpowiednik, dokumentujący zmiany w każdej wersji. Jest to ważne dla audytu i zrozumienia historii zmian.

Pipeline CI/CD: Automatyczny proces budowania, testowania i wdrażania ról. Przy każdej zmianie w main (lub przy tworzeniu tagu) uruchamia się pipeline, sprawdza rolę, tworzy tag i ewentualnie publikuje ją w Ansible Galaxy.

# Przykład kroku w pipeline CI (użycie GitLab CI/GitHub Actions/Jenkins)
stages:
  - test
  - release

test_role:
  stage: test
  script:
    - molecule test

release_role:
  stage: release
  only:
    - tags # Uruchamia się tylko przy tworzeniu tagu
  script:
    - ansible-galaxy role import --server https://galaxy.internal.bankname.com namespace role_name --role-version $CI_COMMIT_TAG
  needs:
    - test_role

Podejście to zapewnia śledzenie, możliwość powrotu do wcześniejszych wersji, niezależne testy i ścisłą kontrolę nad zmianami w rolach, co jest krytyczne dla spełnienia wymagań bezpieczeństwa i regulacji w sektorze bankowym.

Jak wersjonowałbyś kilka ról w Ansible dla sektora bankowego?