Containers should mount an EFS filesystem and use it for SSL certs and backups

cgolubi1 commented 6 months ago

Partially addresses #2908.

Testing:

I tried this out both on a standard dev site deployment with no remote database, and on a deployment with a remote database and the EIP rds.dev.buttonweavers.com (both torn down now)
In both cases, i tested the sequence:
- Do an initial deployment
- Do a second deployment to replace the container/task when the site already exists
- Stop the task from within ECS so that the ECS service replaces it
In all cases, if /mnt/efs/${FQDN}/letsencrypt/live didn't exist, the letsencrypt negotiation happened after startup. If it did exist, negotiation didn't happen, and the existing cert was reused with a message like:
```
Cert not yet due for renewal
Keeping the existing certificate
```
In the EIP case, all three of the test cases led to a fully functional site without further intervention.
In the dev DNS case, the first two led to a fully functional site without further intervention. In the third case, running my DNS sync script manually got the site back online (but of course it had the default database, because i haven't solved that problem for local dev databases --- see checklist on #2908).
In all cases, test_buttonmen_config after deployment yields no errors
In all cases, database backup succeeds, and the backup is stored to the EFS volume

So i assert this does what i expected it to, and solves:

The persistent backup storage blocker
The letsencrypt deployment limit blocker
The need for certbot to be rerun when a dev site is replaced (but not the DNS piece, as noted above)

cgolubi1 commented 6 months ago

blackshadowshade commented 6 months ago

Changes have to do with deployment. CircleCI passes. Merging now.

buttonmen-dev / buttonmen