Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A better first touch experience #137

Open
1 of 6 tasks
danielledeleo opened this issue Apr 5, 2024 · 5 comments
Open
1 of 6 tasks

A better first touch experience #137

danielledeleo opened this issue Apr 5, 2024 · 5 comments

Comments

@danielledeleo
Copy link
Contributor

danielledeleo commented Apr 5, 2024

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:

  • Command line alternatives to writing Unit configurations in JSON (tedious and slow)
  • Unit's default behaviour to launch in daemon mode can be surprising to new users
  • Make running Unit as an unprivileged user easier (automatic --flag overrides for .pid, .log, and .sock files)
@avahahn
Copy link
Contributor

avahahn commented Apr 18, 2024

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
Copy link
Contributor Author

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
Copy link
Member

ac000 commented Apr 19, 2024

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

@lcrilly
Copy link
Contributor

lcrilly commented Apr 19, 2024

Also consider Docker CMD arguments so that a read-only filesystem can be used. See nginx/unit#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
Copy link
Contributor Author

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

A little tedious, but yes.

@danielledeleo danielledeleo removed their assignment May 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants