Re: /etc and databases
- From: "Colin Walters" <walters verbum org>
- To: "Davis Roman via ostree-list" <ostree-list gnome org>
- Subject: Re: /etc and databases
- Date: Wed, 05 Jun 2019 10:26:56 -0400
On Wed, Jun 5, 2019, at 4:12 AM, Menny Hamburger via ostree-list wrote:
Hi,
I am a newcomer to OSTREE and I'm trying to understand whether putting
database files (let's say PostgreSQL) in /etc is the right thing to do.
I think you really want this in /var. /etc is for human-editable files; it's "config" whereas /var is
"state".
I have a piece of software that uses PostgreSQL and implements DB
schema versioning and DB migration between versions.
Today the software is deployed as a tarball and extracted onto a mount
point over /var (where both binaries and the DB are deployed).
The tarball includes an installation script that runs the database
migration in case of upgrade and rolls back to the previous DB in case
installation fails.
If you're deploying as a tarball outside of the host, I think you'd be better off going to a full container
system (e.g. podman).
I am considering the following setup:
1) Deploy software as a layered package (
That said obviously rpm-ostree does support this.
2) Set up the DB in /etc and run the installation (including DB
migration) script in %post.
Not sure where /etc comes in here. I would avoid doing anything in %post. If you're going the "on host"
path, what you really want to do is execute any custom migrations as part of something like ExecStartPre= in
a systemd unit. That way the migration code runs with the same privileges/config as the database, its
failure won't block other services/upgrades of the host, etc.
If you want to roll back if the database upgrade fails, that is a more complex scenario. Gets a bit into the
"auto rollbacks" we've been discussing for Fedora CoreOS, see e.g. https://github.com/LorbusChris/greenboot/
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]