Start deployment migration #78

New issue

Open

opened 2025-01-27 13:19:16 +01:00 by fricklerhandwerk · 0 comments

fricklerhandwerk commented

2025-01-27 13:19:16 +01:00

Owner

As an operator,
given I have the Fediversity info from my deployment at the old environment (#77),
I want to reproduce my deployment with my applications and data in the new environment,
so that I may enjoy data portability (#100).

implementation notes

get the info from the migration string (see #77)
get IP of the new node (available in say TF)
for the new node, update the deployment configuration's SOA/NS/A/AAAA records to point to the new node itself (needs #110)
to reproduce the applications with their data, create and run a deployment
get the source node back-up and pass it through service scripts (c.f. #159) handling:
1. back-up restore (needs #123): handled in SelfHostBlocks restoreScripts for select applications
2. application-specific migration business logic, e.g. reconfiguring of connections/URLs (also see the migration column of our apps sheet)
update SOA/NS record on old node
update SOA/NS record at registrar (registrar-specific so manual)
await TTL monitoring for propagation to ensure service restarts if needed
optionally, on user confirmation:
1. remove the back-up key (or even the bucket, given key permission) to reduce risk of leaking
2. decommission (the SOA-serving nameserver at) the old instance

**As** an operator, **given** I have the Fediversity info from my deployment at the old environment (#77), **I want** to reproduce my deployment with my applications and data in the new environment, **so that** I may enjoy data portability (#100). ## implementation notes 1. get the info from the migration string (see #77) 1. get IP of the new node (available in say TF) 1. for the new node, update the deployment configuration's SOA/NS/A/AAAA records to point to the new node itself (needs #110) 1. to reproduce the applications with their data, create and run a deployment 1. get the source node back-up and pass it through service scripts (c.f. #159) handling: 1. back-up restore (needs #123): handled [in SelfHostBlocks](https://shb.skarabox.com/contracts.html) `restoreScript`s for select applications 1. application-specific migration business logic, e.g. reconfiguring of connections/URLs (also see the `migration` column of our [apps sheet](https://git.fediversity.eu/Fediversity/apps-sheet/media/branch/main/apps.ods)) - [mastodon](https://docs.joinmastodon.org/admin/migrating/) - [pixelfed](https://github.com/pixelfed/pixelfed/discussions/4661) - [peertube](https://docs.joinpeertube.org/maintain/migration) 1. update SOA/NS record on old node 1. update SOA/NS record at registrar (registrar-specific so manual) 1. await TTL monitoring for propagation to ensure service restarts if needed 1. optionally, on user confirmation: 1. remove the back-up key (or even the bucket, given key permission) to reduce risk of leaking 1. decommission (the SOA-serving nameserver at) the old instance