Hoe zou je meerdere rollen in Ansible voor de…

In de banksector, waar strikte controle over wijzigingen en naleving van regelgeving vereist is, is versiebeheer van Ansible-rollen van cruciaal belang.

Ik zou de volgende combinatie van benaderingen gebruiken:

Versiebeheersysteem (Git): Elke rol wordt opgeslagen in een aparte Git-repository. Dit maakt het mogelijk om elke rol onafhankelijk te versioneren, te brancheren en wijzigingen te reviewen.
Semantische versiebeheer (SemVer): Voor elke rol wordt SemVer (MAJOR.MINOR.PATCH) toegepast.
- MAJOR: Grote veranderingen die backward compatibility breken.
- MINOR: Toevoegingen van nieuwe functionaliteiten die compatibiliteit behouden.
- PATCH: Bugfixes die compatibiliteit behouden. Git-tags worden gebruikt om specifieke versies te markeren.
GitFlow of een vergelijkbaar werkproces: Gebruik van de takken develop (voor lopende ontwikkeling) en main (voor stabiele, productieklare versies). Feature-takken worden aangemaakt voor nieuwe functies of bugfixes.
Ansible Galaxy: Voor gecentraliseerd beheer van afhankelijkheden en versies van rollen. Een privé-instantie van Ansible Galaxy kan worden gebruikt om veiligheid en toegangscontrole te waarborgen in een bankomgeving.

Requirements (requirements.yml): In playbooks (of andere rollen die afhankelijk zijn van andere rollen) wordt de specifieke versie van de benodigde rol aangegeven in het bestand requirements.yml.

# requirements.yml
- name: common_config
  src: git@internal-git.bankname.com/ansible-roles/common_config.git
  version: 1.2.0 # Specifieke versie
- name: database_server
  src: git@internal-git.bankname.com/ansible-roles/database_server.git
  version: 2.1.5

Geautomatiseerde tests: Elke commit en elke nieuwe versie van de rol doorloopt automatische tests (bijvoorbeeld met Molecule). Als de tests falen, kan de versie niet als stabiel worden gemarkeerd.
Wijzigingslogboek (Changelog): In elke rol-repository wordt een bestand CHANGELOG.md of vergelijkbaar bijgehouden, waarin de wijzigingen in elke versie worden gedocumenteerd. Dit is belangrijk voor audits en het begrijpen van de wijzigingsgeschiedenis.

CI/CD-pipeline: Geautomatiseerd proces voor het bouwen, testen en uitrollen van rollen. Bij elke wijziging in main (of bij het aanmaken van een tag) wordt de pipeline uitgevoerd, wordt de rol gecontroleerd, wordt de tag aangemaakt en wordt deze mogelijk gepubliceerd in Ansible Galaxy.

# Voorbeeld van een stap in de CI-pipeline (gebruik van GitLab CI/GitHub Actions/Jenkins)
stages:
  - test
  - release

test_role:
  stage: test
  script:
    - molecule test

release_role:
  stage: release
  only:
    - tags # Alleen uitvoeren bij het aanmaken van een tag
  script:
    - ansible-galaxy role import --server https://galaxy.internal.bankname.com namespace role_name --role-version $CI_COMMIT_TAG
  needs:
    - test_role

Deze aanpak zorgt voor traceerbaarheid, de mogelijkheid om terug te keren naar eerdere versies, onafhankelijke tests en strikte controle over wijzigingen in rollen, wat cruciaal is voor het voldoen aan beveiligings- en regelgevingsvereisten in de banksector.

Hoe zou je meerdere rollen in Ansible voor de banksector versieëren?