Docker --build --save --load --serve chaining for Compose Usage

[ndoo]

Is your feature request related to a problem? Please describe.

The Docker image currently requires running --build --save in foreground followed by --load --serve which can be daemonized.

This makes the Docker image not compatible with headless workflows like running services with Compose.

Attempting this currently results in this error by design:
ERROR [main] (OTPMain.java:93) Parameter error: --load, --build can not be used together. Use --help to see available options.

Goal / high level use-case
Make the Docker image headless by re-build and immediately serving.

Describe the solution you'd like
Make it possible to specify --build --save --load --serve simultaneously resulting in the correct sequential execution resulting in the same as if they were run separately.

Describe alternatives you've considered
A custom Dockerfile with a script that achieves the same.

Additional context

[leonardehrenfried]

Have you tried removing --save and --load?

[ndoo]

Have you tried removing --save and --load?

Yes that does work but what I mean is that allowing these to be chained allows a workflow where users don't have to interactively wait for the build to complete before starting the daemon.

I.e. docker compose restart [service] would rebuild and start serving the new files.

[ndoo]

Or, is there a better workflow to rebuild in background for a server that is already running, then have the server reload the new files seamlessly? That's the objective

[leonardehrenfried]

Well, OTP needs the graph before it starts itself up so you will have to wait one way or another.

I'm not 100% sure what workflow you're after but it sounds like you want to add some scripting somewhere.

[ndoo]

Basically, for a single service in Docker compose to build the graph and serve OTP, as long as the container is subjected to:

• Pull (no existing graph) -> Create -> Start
• Running (existing graph) -> Pull -> Recreate -> Start
• Running (existing graph but older than X duration from now) -> Recreate -> Start (but should trigger a rebuild of graph in the background)

Alternatively, some kind of built in way to (re)build the graph as a background task using SIGHUP or an API call, would also be great.

Basically the transition from building to serving should be non interactive.

The main problem for not being able to use a single docker compose service now is that serving a fresh graph always needs an interactive build to take place (i.e. I need to wait for the build) OR a lack of signaling to tell OTP in serve mode to reload the graph from disk.

[leonardehrenfried]

We removed the feature to reload the graph of a running OTP instance in version 2 as it was a very difficult to maintain.

The biggest users just do a bit of scripting/devops to make sure a graph build is finished before (re)starting the process.

[tkalvas]

Also for the biggest users the situation is that there only needs to be one build of the graph, while there can be dozens of servers running using that graph. We actually do the build completely separately, and only restart the servers when the build is done.

[ndoo]

Thank you for the context. In that case, the ability to watch for changes to the graph file and reload automatically, or reload manually, still sounds like a nice-to-have, especially if it temporarily stops the web server or otherwise triggers an unhealthy state that would let my reverse proxy (Traefik) know to RR to another instance.

Being able to reload would be a nice feature to add back in.

Nonetheless I will try to figure a way to script/devops a solution on my own, though of course having some kind of sanctioned, documented way to run OTP as a production containerized service (beyond just what's already in the docs) would be great.

Thanks all.

[leonardehrenfried]

The thing is that there is no agreement how to "officially" run OTP (container or not). All the big users do a bit differrently.

If you want to publish your setup somewhere we would be happy to link to it.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days