This switches our production config. I actually found it easier to start with prod on this one, but updates to the dev environment instructions and Nix config will follow.
Details
I ran the web application and clicked around a bunch. Full test plan will come later
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
It's great to see this happening!
keyserver/docker-compose.yml | ||
---|---|---|
19–22 ↗ | (On Diff #14398) | Maybe something more generic, e.g. DATABASE? |
keyserver/docker-compose.yml | ||
---|---|---|
19–22 ↗ | (On Diff #14398) | Hmm, so arguably from the perspective of the Node application, it's still connecting to a MySQL server. We're still using the mysql2 npm package to connect. That said, while working on this I've realized there are some incompatible changes we'll need to make (where MariaDB needs one query and MySQL needs another). To make the transition smooth for devs, and to maintain a potential path to migrate prod back if we see a serious issue after deploying, I'm going to make sure this stack maintains support for both MySQL and MariaDB in the near term. So the Node application will need to have some awareness of MySQL 5.7 vs. MariaDB 10.8. After we deprecate MySQL we can consider changing these variable names. But it's worth noting that MariaDB clients tend to continue calling themselves MySQL clients (eg. mysql and mysqldump CLI). |
27 ↗ | (On Diff #14398) | Good call. My initial reason for going with focal was because we're using Debian bullseye for the Node image. Whereas Ubuntu focal is based on Debian bullseye, Ubuntu jammy is based on Debian bookworm... so my thinking was it's better to keep the same Debian versions across all of the images. But actually there's not really a super good reason why that matters. And I didn't notice we could use a newer version of MariaDB if we went with jammy. I'll switch this. |
Committed the rest of the stack, but decided to defer this one for a bit. I want to test:
- MySQL 5.7 to make sure it still works correctly after these changes
- MariaDB 10.8 to make 100% sure that there aren't any extant issues
The rest of the stack is now live on prod, which is one way to test and make sure things still work with MySQL 5.7