Looks basically like a web-based text-editor. More effort needs to be put into adding UI controls for modifying common settings, or at least some macros for adding settings to a config file. (e.g. insert a common setting at cursor location). Better yet, hide editing the config file in an "advanced" mode, and allow UI controls (checkboxes, input boxes, and dropdowns) for editing parts of the config. (that's what I tho…
what's the goal of that? Which person needing to configure nginx does not know how to edit text?
10 years young me would have liked having something like this. Nowadays any manual configuration is a big no-no. All my configuration parsing and building happen in the CI pipeline in an automated manner.
If you use this, you lose the ability to version control, which is the most important feature of text files. I'm not against generating configuration, but that should not require an always-running instance.
I think version controlling configuration is important.
I don't understand why you think a GUI necessitates losing version control though, or why you think version control is a "feature" of text files.
If you need version control of always-running live-changing nginx configuration then you can run `nginx -T` to dump the parsed configuration to stdout. Just save that to version control.
IMHO, I might as well just use Vim. Maybe this has a use case, it's not for me. I literally need to type just one line and and press enter: sudo vi /etc/nginx/...
Generally speaking, a UI DOES have a use case - when you can't be bothered to learn the configuration language and its keys / values / nuances. The UI can help you create a sane and safe config, instead of having to scour the internet for - potentially outdated - information. Mind you, I've had more trouble with that with Apache given how they changed their config files around on multiple occasions.
I'd argue that if you are neither willing nor able to learn nginx's config file format, you should not be configuring nginx. The default config has example blocks with comments anyway. If that's not enough, nginx maintains current documentation. But if you're configuring a web server (or anything, for that matter), you should take some time to learn how to configure it.
Well i have 1M+ users and still ssh into the VMs and live-change nginx configs. Once in a while the reload fails because i messed up something.
I have over 100k uniques daily, 7 servers and I also change nginx config manually via ssh.
But why?
Even if you don't use kubernetes or docker images, you do wanna have it in code right?
Having something like ansible would do the same thing but allows you to have your config backuped by git and allows you to recreate the env without any issues.
How do you keep your mean time to recovery low? How do you document your setup? How do you automated tests if you change your config manual?
Neat! Felt a little nostalgic seeing reading the title as it was a somewhat big emphasis as the "next thing to do" when I was part of the NGINX Amplify team.
In case you didn't know, the configuration parsing library we created for the NGINX Amplify agent is open source under Apache 2.0: