trade-iac/doc/workflow.md

Workflow trade-iac

Cel: utrzymywać konfigurację IaC w Git i wdrażać ją kontrolowanie na mevnode.

1. Dodanie klucza SSH na hoście (operator)

Host operatora musi mieć klucz do dostępu do repo trade/trade-iac.

Przykład:

ssh-keygen -t ed25519 -C "trade-iac-host" -f ~/.ssh/trade_iac
cat ~/.ssh/trade_iac.pub

Publiczny klucz dodajemy w Gitei (Settings -> SSH Keys), a potem test:

ssh -T git@gitea.mpabi.pl

2. Dodanie klucza SSH na VPS

VPS (runner/deployer) musi mieć osobny klucz do klonowania/pull z trade/trade-iac.

Przykład:

ssh-keygen -t ed25519 -C "trade-iac-vps" -f ~/.ssh/trade_iac
cat ~/.ssh/trade_iac.pub
ssh -T git@gitea.mpabi.pl

Ten publiczny klucz też dodajemy do Gitei.

3. Wdrożenie na mevnode (runner na VPS)

Po zmianach w repo:

1. doc/ (opis etapu),
2. implementacja (playbook/vars),
3. test/syntax-check,
4. commit + push,
5. wdrożenie z VPS na mevnode,
6. testy powdrożeniowe.

Minimalny przepływ:

# VPS
git -C /opt/trade-iac pull --ff-only origin main
cd /opt/trade-iac

# uruchom Ansible w kontenerze (bez instalacji Ansible na hoście)
docker run --rm -t \
  -v "$PWD/ansible:/ansible" \
  -v "$HOME/.ssh:/home/runner/.ssh:ro" \
  -w /ansible \
  quay.io/ansible/ansible-runner:latest \
  ansible-playbook -i inventory/hosts.ini playbooks/doc-rpc-sol-min.yml

Zasada pracy

• Zmiany zawsze przez PR/commit (bez ręcznych zmian na mevnode poza awarią).
• mevnode traktujemy jako target deploymentu, nie źródło prawdy.
• Źródłem prawdy jest repo trade/trade-iac.