Kā jūs versijonētu vairākas lomas Ansible banku…

Banku sektorā, kur nepieciešama stingra izmaiņu kontrole un atbilstība normatīvajiem aktiem, Ansible lomu versiju kontrole ir izšķiroša.

Es izmantotu sekojošo pieeju kombināciju:

Versiju kontroles sistēma (Git): Katru lomu glabā atsevišķā Git repozitorijā. Tas ļauj neatkarīgi versijot, zaru veidot un pārskatīt katras lomas izmaiņas.
Semantiskā versiju numerācija (SemVer): Katrai lomai tiek piemērota SemVer (MAJOR.MINOR.PATCH).
- MAJOR: Lielas izmaiņas, kas pārkāpj atgriezenisko saderību.
- MINOR: Jaunas funkcionalitātes pievienošana, saglabājot atgriezenisko saderību.
- PATCH: Kļūdu labojumi, saglabājot atgriezenisko saderību. Git tagi tiek izmantoti konkrētu versiju marķēšanai.
GitFlow vai līdzīgs darba process: Izmanto zarus develop (aktīvajai izstrādei) un main (stabilajām, ražošanas versijām). Izstrādes jaunas funkcijas vai kļūdu labojumi tiek veidoti jaunos zaros.
Ansible Galaxy: Centralizētai atkarību pārvaldībai un to versijām. Var izmantot privātu Ansible Galaxy instanci, lai nodrošinātu drošību un piekļuves kontroli banku vidē.

Prasības (requirements.yml): Playbookos (vai citās lomās), kas izmanto citas lomas kā atkarības, norāda konkrētu nepieciešamās lomas versiju requirements.yml failā.

# requirements.yml
- name: common_config
  src: git@internal-git.bankname.com/ansible-roles/common_config.git
  version: 1.2.0 # Konkrētas versijas norādīšana
- name: database_server
  src: git@internal-git.bankname.com/ansible-roles/database_server.git
  version: 2.1.5

Automatizēta testēšana: Katrs komits un katra jauna lomas versija tiek automatizēti pārbaudīta (piemēram, ar Molecule). Ja testi neizdodas, versija nevar tikt atzīmēta kā stabila.
Izmaiņu žurnāls (Changelog): Katram lomas repozitorijam ir CHANGELOG.md vai līdzīgs fails, kurā dokumentētas izmaiņas katrā versijā. Tas ir svarīgi audita un izmaiņu vēstures izpratnei.

CI/CD caurplūdums: Automātisks būvniecības, testēšanas un izvietošanas process lomām. Katru reizi, kad tiek veiktas izmaiņas main zarā (vai tiek izveidots tags), tiek palaists caurplūdums, pārbaudīta loma, izveidots tags un, iespējams, tā tiek publicēta Ansible Galaxy.

# Piemērs CI caurplūduma solim (GitLab CI/GitHub Actions/Jenkins)
stages:
  - test
  - release

test_role:
  stage: test
  script:
    - molecule test

release_role:
  stage: release
  only:
    - tags # Palaist tikai, ja tiek izveidots tags
  script:
    - ansible-galaxy role import --server https://galaxy.internal.bankname.com namespace role_name --role-version $CI_COMMIT_TAG
  needs:
    - test_role

Šī pieeja nodrošina izsekojamību, iespēju atgriezties iepriekšējās versijās, neatkarīgu testēšanu un stingru izmaiņu kontroli lomās, kas ir kritiski svarīgi drošības un regulatoru prasību ievērošanai banku sektorā.

Kā jūs versijonētu vairākas lomas Ansible banku sektoram?