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 thought this was going to be).
I imagine that if you are creating a web interface, with the associated risks it carries (login, vulnerabilities, permissions), the interface should have some advantages over just going into the terminal and editing the same files in the same way.
In fact, by reading the motivation of the project in the README, it seems that the problem it solved was the authentication part of it, and replaced it with... no authentication?
Without getting into a debate of whether or not it's a good idea for an inexpert person to be configuring nginx, GUIs can alleviate the need to remember specific terms or syntax, and guide the user through the process in general.
This appears to be a simple UI wrapper over the nginx CLI more than a config generator (like what DigitalOcean has). It's basically an assortment of text boxes for editing the config and then buttons for applying it.
This is certainly a good effort but I've yet to use a web ui to manage web server configs, especially these days when we're moving most of the configuration to code and version control. We usually deploy changes to a test server to test the changes and then move on to production.
Adding a UI doesn’t require you to take config out of your IaaC setup, it could Increase accessibility to logs, monitoring, security warnings, versioning, etc, that your IaaC might be strongly lacking. There are weaknesses to IaaC that a tool like this may supplement.
I don't really understand how a tool that enables configuration changes outside of the version controlled loop can improve an IaaC setup. It gives you a shortcut that you may end up taking, making it easier than modifying by hand some configuration via an SSH connection.
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.
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.
Surprised nobody else has mentioned the irony of delivering this - a tool designed to help you hand-edit configuration on a pet server - in a container.
"State of the art" doesn't really indicate age. It just means that there's nothing better. I'd be interested in learning about anything that's better than containers.
Solaris had zones, which are similar to LXC or OpenVZ, which Linux had almost as long ago. But neither Solaris zones nor LXC/OpenVZ envisioned the sort of container in which this application is being delivered.
(The key insight here is that "containerization" in the modern sense is about norms/expectations/practices and an ecosystem of tooling around a particular design that's convenient for certain use cases; it's not about a technical facility in the OS.)
Delivering applications in chroot/jail had some momentum circa 2003. The tooling was on par with current docker if chosen wisely, but surely not on the level of vagrant/docker-compose/docker swarm/kubernetes.
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?
I have done this for 10+ years and it's still working flawlessly, I don't see a reason to add more complexity to something that is working fine for my needs. I don't have to change config often, maybe once a year or so.
" I don't see a reason to add more complexity to something that is working fine for my needs" valid point though.
I would do it due to:
- keeping 'meantime to recovery' low due to having my configs in git -> fast recovery
- using something like ansible for your small case to have it in git (instead of a shellscript) -> backup
- perhaps a jenkins pipeline with testing the config before applying it automatically -> for quality
- automatisation for having fun with it, seeing what is out there besides ssh and manuel editing
At the end of the day, i assume that this automatisated process is also less dependend from myself. So i'm not sure who is doing things when you are on holiday or sick.
I'm now having a small k8s cluster at home. I have never had anything which allows me to have my whole setup in git so easy with autohealing, domain management and high availability.
Their user case seems a bit weird to me. If a new application is deployed, can you not make changes to the nginx config locally and redeploy it? That way everyone has access and it'll be part of the usual merge request -> review -> merge flow.
If anything this tool makes editing easier and may lead to more misconfiguration.
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.
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:
From what i gather, this is a Deployment & editor software for nginx specifically.
At work I've setup a pipeline using Azure Devops (also done it with Gitlab) that achieves the same thing. And I'm guessing it can be done with the other popular build & deploy tools such as Jenkins and .
So i wonder, who is this for?
And you'd think there'd be some automated pipeline that would deploy and reload nginx configs. That would be usable by all environments, from lab to prod, and would go through code review. A UI anyone can just go in and switch stuff for prod seems like a weird solution to the use case.
Nonetheless they had a problem, they fixed it and they shared the solution when they could've just kept it.
