Как бихте версионирали няколко роли в Ansible за…

В банковия сектор, където е необходим строг контрол върху промените и съответствие с нормативните актове, управлението на версиите на ролите на Ansible е от съществено значение.

Ще използвам следната комбинация от подходи:

Система за контрол на версиите (Git): Всяка роля се съхранява в отделен репозиторий Git. Това позволява независимо версиониране, създаване на клонове и преглед на промените.
Семантично версиониране (SemVer): За всяка роля се прилага SemVer (MAJOR.MINOR.PATCH).
- MAJOR: Значителни промени, нарушаващи обратната съвместимост.
- MINOR: Добавяне на нови функции, запазващи обратната съвместимост.
- PATCH: Корекции на грешки, запазващи обратната съвместимост. Таговете в Git се използват за маркиране на конкретни версии.
GitFlow или подобен работен процес: Използване на клонове develop (за текуща разработка) и main (за стабилни, продукционни версии). Feature клонове се създават за разработка на нови функции или корекции.
Ansible Galaxy: За централизирано управление на зависимостите и версиите на ролите. Може да се използва частен инстанс на Ansible Galaxy за осигуряване на сигурност и контрол на достъпа.

Изисквания (requirements.yml): В плейбуците (или други роли), които използват други роли като зависимости, се посочва конкретната версия на необходимата роля във файла requirements.yml.

# requirements.yml
- name: common_config
  src: git@internal-git.bankname.com/ansible-roles/common_config.git
  version: 1.2.0 # Посочване на конкретна версия
- name: database_server
  src: git@internal-git.bankname.com/ansible-roles/database_server.git
  version: 2.1.5

Автоматизирано тестване: Всеки commit и всяка нова версия на ролята преминават автоматично тестване (например с Molecule). Ако тестовете не преминат, версията не може да бъде маркирана като стабилна.
Журнал на промените (Changelog): Във всеки репозиторий на ролята се води файл CHANGELOG.md или подобен, документиращ промените във всяка версия. Това е важно за одит и разбиране на историята на промените.

CI/CD конвейер: Автоматичен процес на изграждане, тестване и внедряване на ролите. При всяка промяна в main (или при създаване на таг) се стартира конвейерът, проверява се ролята, създава се таг и евентуално се публикува в Ansible Galaxy.

# Пример на стъпка в CI pipeline (използване на GitLab CI/GitHub Actions/Jenkins)
stages:
  - test
  - release

test_role:
  stage: test
  script:
    - molecule test

release_role:
  stage: release
  only:
    - tags # Стартира само при създаване на таг
  script:
    - ansible-galaxy role import --server https://galaxy.internal.bankname.com namespace role_name --role-version $CI_COMMIT_TAG
  needs:
    - test_role

Този подход осигурява проследимост, възможност за връщане към предишни версии, автоматично тестване и строг контрол върху промените на ролите, което е критично за съответствие с изискванията за сигурност и регулаторните изисквания в банковия сектор.

Как бихте версионирали няколко роли в Ansible за банковия сектор?