nginx / unit-docs

NGINX Unit's official website and documentation
https://unit.nginx.org
Creative Commons Attribution 4.0 International
54 stars 108 forks source link

A better first touch experience #137

Open danielledeleo opened 7 months ago

danielledeleo commented 7 months ago

This issue serves as a place discuss and create tasks related to improving the first touch experience. Recent on-the-ground experiences at Wasm I/O with @tippexs and @danielledeleo have highlighted the need for an improved "first touch" experience for new NGINX Unit users.

Tasks need to be defined and issues created for the following:

Loosely defined ideas that may require changes to the nginx/unit repo:

avahahn commented 7 months ago

Make running Unit as an unprivileged user easier (automatic --flag overrides for .pid, .log, and .sock files)

We dont have to modify Unit if we suggest using the Docker container by default. If we can offer a one-size-fits-all docker container with all language runtimes enabled in addition to our current offerings then we can offer a very simple process to get developers started with a docker container that wont require changes to their systemd configuration.

danielledeleo commented 7 months ago

What I was thinking of was more along the lines of what is already being done in our Homebrew compilation flags.

There are still some quality-of-life and friction issues with Docker that I point out in issue #139. Until we address these I'm reluctant to point users to Docker as a way to get started.

ac000 commented 7 months ago

You can of course set --control, --pid, --log & --statedir at runtime.

lcrilly commented 7 months ago

Also consider Docker CMD arguments so that a read-only filesystem can be used. See https://github.com/nginx/unit/issues/1144

A PID file is redundant, logs could go directly to /dev/stderr instead of a symlink and the state directory is pretty much redundant when we won't be restarting unitd.

danielledeleo commented 7 months ago

You can of course set --control, --pid, --log & --statedir at runtime.

A little tedious, but yes.