Nginx UI – Access and modify the Nginx configurations files without CLI(github.com)
github.com
Nginx UI – Access and modify the Nginx configurations files without CLI
https://github.com/schenkd/nginx-ui
60 comments
I'm using this https://www.digitalocean.com/community/tools/nginx that I find it pretty good
Oh sweet! Didn’t know about this. Would have definitely helped when I was getting my Django app working on DO and was using NGINX for the first time.
Thanks for sharing. the tool is amazing. I have always been wondering if there is a better way to config NGINX.
One directory up they have some other tools people might find useful https://www.digitalocean.com/community/tools
Nice, I love stuff like this. I can then take the generated files and pull them apart for understanding knowing that they are "working" examples.
Thanks for sharing. This is exactly what I need.
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.
It can give beginners a place to start. Until you have that critical base of understanding it can seem very frustrating starting from scratch.
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:
https://github.com/nginxinc/crossplane (credit to @aluttik who was the primary author)
It parses an NGINX configuration files into JSON and vice-versa.
In case you didn't know, the configuration parsing library we created for the NGINX Amplify agent is open source under Apache 2.0:
https://github.com/nginxinc/crossplane (credit to @aluttik who was the primary author)
It parses an NGINX configuration files into JSON and vice-versa.
What is wrong with the current config via CLI?
Edit file, reload... Voilà
Edit file, reload... Voilà
how many cooks does one need in the kitchen, to continuously re-configure a single nginx server? His described use case seems like a strange setup.
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.
Nonetheless they had a problem, they fixed it and they shared the solution when they could've just kept 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.
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.
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).
Yeah, it's a bit early for this to hit HN.
what's the goal of that? Which person needing to configure nginx does not know how to edit text?
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?
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.
If i have to edit text wither way, what's the point of UI?
It's just an extra thing to install, update, maintain and hack.
It's just an extra thing to install, update, maintain and hack.
- better discoverbility of keywords
- less error prone
- less error prone
[deleted]
I just loved it, docker is a good choice but I would've love to have non-docker version as well.
Well, the Dockerfile says exactly how to start the software and how to install all the packages etc. locally, so why not use that? :)
[deleted]
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?
"Containerization is now state of the art and therefore the application is delivered in a container."
I wouldn't say it is "state of the art". Solaris had containers in 2004/2005.
I wouldn't say it is "state of the art". Solaris had containers in 2004/2005.
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.)
(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.
"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.
state of the art
/ˌstād ə(v) T͟Hə ˈärt/
phrase of state
the most recent stage in the development of a product, incorporating the newest ideas and the most up-to-date features.
incorporating the newest ideas and the most up-to-date features.
"a new state-of-the-art hospital"
phrase of state
the most recent stage in the development of a product, incorporating the newest ideas and the most up-to-date features.
incorporating the newest ideas and the most up-to-date features.
"a new state-of-the-art hospital"
newest =/= new
something can be quite old, but if nothing has replaced it, it's still "newest" and "most up-to-date"
something can be quite old, but if nothing has replaced it, it's still "newest" and "most up-to-date"
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.
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.
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.
This. I never understood the "every idiot can do it gui server" thing, just because everybody can doesn't mean everybody should.
Have we already forgotten how Microsoft Exchange singlehandedly launched an entire spam industry?
Have we already forgotten how Microsoft Exchange singlehandedly launched an entire spam industry?
Weird. Not sure why i would like to update/change a live config.
That would probably not mean that there is an Infrastructure code in git.
That would probably not mean that there is an Infrastructure code in git.
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.
And your solutio is to log into a VM through ssh instead of fixing it?
I don't mean this as offending but my personal action is to fix the underlying issue.
If you add more tests etc. you will have to do that less often until it doesn't is the norm anymore.
I don't mean this as offending but my personal action is to fix the underlying issue.
If you add more tests etc. you will have to do that less often until it doesn't is the norm anymore.
Always run `nginx -t` before reloading to test the new config.
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?
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?
Why not?
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 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.
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.
NginxProxyManager is the preferred choice in the Unraid (home server) community - good to have another contender to help nginx n00bs like myself.
There are also more feature rich control panels:
http://ajenti.org/
http://vestacp.com/
For some use cases, these can feel bloated, so I understand there could be room for a more minimalistic option.
http://ajenti.org/
http://vestacp.com/
For some use cases, these can feel bloated, so I understand there could be room for a more minimalistic option.
Nice way to shoot yourself in the foot if you manage configs without version control
I'd rather track it in the repo and let the pipeline deploy it. No need to modify it by hand.
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.
If anything this tool makes editing easier and may lead to more misconfiguration.
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'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.
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.