Automatically run Postgres via container in local dev? #5

Open
opened 2022-05-15 02:44:44 +00:00 by bvisness · 1 comment
Owner

We want the HMN website to be pretty much plug-and-play in local development, which means we don't want the user to have to run lots of confusing scripts. An example of this is our db seed command, which tries to log in as root using common defaults and will then drop / recreate the database and user. Normally the user would have to do this manually, involving the confusing process of getting into psql and running commands manually, possibly needing to drop things first. We can avoid most of that pain, which is nice.

But, Postgres does not actually just ship with a default root password on most installations. This makes it essentially impossible for us to work this magic. Two options come to mind:

  • Prompt the user for the root password whenever the script runs (bleh)
  • Just have the HMN binary run Postgres on its own...?

The latter is appealing to me, but unfortunately this seems to be nearly impossible because Postgres doesn't like to run as a plain old program - it needs a "cluster" and background services and a bunch of other nonsense. However, containers make this fairly easy, assuming the user has a container runtime handy. For example, the official Docker image for Postgres not only can be started up / shut down using the usual Docker commands (run, ps, stop) but it can have the root password configured by environment variable. I assume podman works the same way (and that there is another sane container registry in the world in preparation for Docker's inevitable demise).

If we think this is viable and not too difficult, the HMN website could simply detect the presence of a functional container runtime and run Postgres on its own in the background as necessary.

Questions I would want to answer before doing this:

  • Do enough developers have a decent container runtime to make this worth doing? I suspect many do, but those tools are also subject to their own weird processes that might be too difficult for users.
  • How important is it that Postgres stays running even when you stop / restart the website binary?
  • Is it really that big a deal to have it be purely automatic, or is prompting for the root password on every script run ok? (Or, should we put the root password in the config????)
We want the HMN website to be pretty much plug-and-play in local development, which means we don't want the user to have to run lots of confusing scripts. An example of this is our `db seed` command, which tries to log in as root using common defaults and will then drop / recreate the database and user. Normally the user would have to do this manually, involving the confusing process of getting into `psql` and running commands manually, possibly needing to drop things first. We can avoid most of that pain, which is nice. _But_, Postgres does not actually just ship with a default root password on most installations. This makes it essentially impossible for us to work this magic. Two options come to mind: - Prompt the user for the root password whenever the script runs (bleh) - Just have the HMN binary run Postgres on its own...? The latter is appealing to me, but unfortunately this seems to be nearly impossible because Postgres doesn't like to run as a plain old program - it needs a "cluster" and background services and a bunch of other nonsense. However, containers make this fairly easy, assuming the user has a container runtime handy. For example, the [official Docker image](https://hub.docker.com/_/postgres/) for Postgres not only can be started up / shut down using the usual Docker commands (`run`, `ps`, `stop`) but it can have the root password configured by environment variable. I assume podman works the same way (and that there is another sane container registry in the world in preparation for Docker's inevitable demise). If we think this is viable and not too difficult, the HMN website could simply detect the presence of a functional container runtime and run Postgres on its own in the background as necessary. Questions I would want to answer before doing this: - Do enough developers have a decent container runtime to make this worth doing? I suspect many do, but those tools are also subject to their own weird processes that might be too difficult for users. - How important is it that Postgres stays running even when you stop / restart the website binary? - Is it _really_ that big a deal to have it be purely automatic, or is prompting for the root password on every script run ok? (Or, should we put the root password in the config????)
bvisness added reference localdev-2022 2022-05-15 02:45:44 +00:00
bvisness removed reference localdev-2022 2022-05-15 02:45:54 +00:00
bvisness added the
gimme feedback
label 2022-05-15 02:47:30 +00:00
Author
Owner

On further thought I think this probably is worth doing. I don't think it would be that hard to recognize e.g. Docker and Podman and just give it a go. There really are a lot of advantages for controlling local dev this way,

On further thought I think this probably is worth doing. I don't think it would be that hard to recognize e.g. Docker and Podman and just give it a go. There really are a lot of advantages for controlling local dev this way,
bvisness reopened this issue 2022-05-30 14:36:14 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hmn/hmn#5
No description provided.