DevOps

Important

Is the production server unreachable? Follow this simple steps:

1. See docker ps and docker compose logs -tf...
2. Check if it's possible to either:
   • create a database back-up with save-postgres.
   • use convert-backup (if the container parkour2-rsnapshot was running, as it should.) Adjust volume in convert-backup.yml if you wanted any interval/ time different from the previous day at 00:00, daily.0. (See misc/rsnapshot/config/rsnapshot.conf for details!)
3. Confirm the database you're about to load is the desired one: file misc/latest.sqldump.
4. Restart everything make prod load-backup.
5. See that parkour2-rsnapshot container is running, create one snapshot: docker exec parkour2-rsnapshot rsnapshot halfy.

---

Note

We are providing a Makefile with rules that wrap some of the common operations that admins and developers would need. Try make -n <rule> to see what's going to be run, and decide/ adjust accordingly.

• List most common available routines: make help.

• Instant back-up from running instance: make save-postgres save-media.

• Turning it off: make down. Or, without removing containers: make stop.

• Turning it on: make prod. Or, on staging VM (e.g. parkour-test): make dev. Or, on dev's laptop: make dev-easy.

• Instant SQL restoration to running instance: make db. Assuming there's a previous SQL back-up (misc/*.sqldump file.)

• Instant restoration of media files: make load-media.

Note

We have two VMs. First, production (hostname: parkour), and secondly, a staging environment (hostname: parkour-test). In both cases, the directory that holds the repo is ~/parkour2.

• Re-deploy locally with latest database snapshot: make import-pgdb dev-easy db.

• Re-deploy in staging VM with latest database snapshot: make import-pgdb dev db.

• To re-deploy in staging VM with latest database snapshot, while having updated code that entails new migrations, you'd run: make import-pgdb dev db-migras.

  • Basically, db-migras is a drop-in replacement for db. It requires misc/migras.tar.gz, that can be generated with tar-old-migras beforehand, on the code version that matches the production database schema (e.g. on your production VM; or via git checkout <tag to version number>).
  • When the code has new migrations compared to the production deployment and its database snapshot, we'll run db-migras which is an alias for put-old-migras db put-new-migras. The put-old-migras removes your migrations and puts in place the ones in misc/migras.tar.gz, so that the correct database schema is in place when loading the SQL dump. After that, the current migrations are restored and applied, thanks to put-new-migras.
  • The same chaining could be done for load-fixtures if because of reasons you were using JSON files instead of SQL dump: put-old-migras load-fixtures put-new-migras...