Upgrading Seattlematrix's Etherpad
High level goals and considerations
Considerations:
- The current Etherpad (https://etherpad.seattlematrix.org| https://pad.seattlematrix.org) is in active use, and we should attempt to preserve existing pads
- The admin interface is not currently enabled, we should enable it
- There are currently no tested backups of Etherpad at all, we should back up and restore regularly
Goals:
- Migrate https://etherpad.seattlematrix.org Postgres to new, consolidated Postgres as a Service, which saves money for the SM team
- CI/CD the build/deployment/backups
Decisions:
- do we just use upstream and add our ENVs (SM public repo? Etherpad upstream repo?) ?
- how do we secure API keys, Postgres keys etc.
Breaking this down into smaller, ordered steps
- Move docker build into Gitlab, and store image in Gitlab Docker repository - owner Don/sntxrr
- backup existing database one time, and restore it to new psql DO instance
- this allows us to validate that the new postgres db can/will work
- this starts us down the path of working out the DB backup/restore procedures
- gives us some sort of data to work with to verify updated Etherpad container
- traefik will need to be updated such that we have "etherpad-new.seattlematrix.com|pad-new.seattlematrix.com" enabled, and served to new, upgraded container
- CI/CD the Docker build in Gitlab (research for examples)
- this should leverage ENV vars to inject our customizations
- admin w/admin password
- custom text we currently inject
- notice of lifetime enforcement
- CI/CD the deployment to the host
- take Gitlab repo from private to public
- are there any secrets exposed now, or previously that we should fix up?
The procedures we would use for the actual migration
We have the new Etherpad and the old Etherpad up in parallel.
- backup existing database one time, and restore it to new psql DO instance
- traefik will need to be updated such that we have "etherpad-new.seattlematrix.com|pad-new.seattlematrix.com" enabled, and served to new, upgraded container
- once we've validated the new container image, we do another backup/restore using our newly established procedure
- remove "-new" designation and repoint DNS (if needed, probably not, traefik)
Want to help out with this migration? Come find me @sntxrr in the CoffeeOps slack, or in Seattle Matrix's matrix: #seattlematrix:seattlematrix.org