4 ms·

Sometimes it's like HN is reading my mind. I just finished a setup where I run PostgreSQL as a quadlet on CoreOS, and in order to manage backups I use systemd

Sometimes it's like HN is reading my mind. I just finished a setup where I run PostgreSQL as a quadlet on CoreOS, and in order to manage backups I use systemd Require so the postgres container depends on a pgbackrest container that just runs a relatively simple script to check if storage is empty or not, and restores the backup from S3 if storage is empty. And another container runs as a oneshot timer that takes full and incremental backups to S3. Instead of this [1] I use a much simpler while ! pg_isready loop. 1. https://gist.github.com/efrecon/86456960e2110b287632fd7f42c1cd31/1c5c811126d981507bbd6bbd70c0cfe7e9521644 https://gist.github.com/efrecon/86456960e2110b287632fd7f42c1...

teaearlgraycold 3y ago
Why use which instead of just calling nc directly?
- INTPenis 3y ago
  It's not my script, it's the script used by the linked project. I use pg_isready. Unfortunately I won't link my project because I try to keep this HN account separate from my true identity.
mati365 3y ago
How do you update postgres on CoreOS? Its better to keep IT immutable so in case of change the whole image must be recreated?
- INTPenis 3y ago
  I assume you mean major release upgrade, I haven't gotten that far yet so I view it as a problem to solve once it arises. Obviously it runs in a container, but I have to run the pg_upgrade tool before I start the new container image tag. An immutable OS like CoreOS for example isn't much different than a regular distro. You can still do a lot of manual work on it if you want. I try to avoid doing manual work on it because I want to be strict IaC, but I can for example test doing a major release upgrade in staging, manually over SSH, and work out the kinks, before I put it into practice using containers and scripts in production. Though I see very little reason to automate the hell out of a major release upgrade, better do it safely and slowly with SOP's.

teaearlgraycold 3y ago

Why use which instead of just calling nc directly?

INTPenis 3y ago
It's not my script, it's the script used by the linked project. I use pg_isready. Unfortunately I won't link my project because I try to keep this HN account separate from my true identity.

mati365 3y ago

How do you update postgres on CoreOS? Its better to keep IT immutable so in case of change the whole image must be recreated?

INTPenis 3y ago
I assume you mean major release upgrade, I haven't gotten that far yet so I view it as a problem to solve once it arises. Obviously it runs in a container, but I have to run the pg_upgrade tool before I start the new container image tag. An immutable OS like CoreOS for example isn't much different than a regular distro. You can still do a lot of manual work on it if you want. I try to avoid doing manual work on it because I want to be strict IaC, but I can for example test doing a major release upgrade in staging, manually over SSH, and work out the kinks, before I put it into practice using containers and scripts in production. Though I see very little reason to automate the hell out of a major release upgrade, better do it safely and slowly with SOP's.