If you need just reverse proxy, Caddyfile syntax looks simpler:
myapp.company.com {
reverse_proxy localhost:3000
}Nginx Unit – Universal web app server
141–150 of 201 posts
Re: Nginx Unit – Universal web app server
#142[deleted]
Re: Nginx Unit – Universal web app server
#143Earlier quoted context omitted.
What strikes you as difficult with compose files? In fact, I would say it’s the most concise format to describe a desired state of running applications currently available.
Nothing is difficult about them, compose is easy enough that you can grok it in a day. You saw the lament in my comment though and that speaks a deeper truth. If WSL took off quick enough we could have had lxc as the main player rather than the bastardisation of lxc that is docker.com For an open source project they make it incredibly hard to access what are essentially text files for containerisation setups on windo…
Compose is an open source project entirely separate to hub, though. The compose file specification is versioned separately, and will outlive Docker, probably. So I don’t quite get your criticism?
Re: Nginx Unit – Universal web app server
#144Earlier quoted context omitted.
Eric S. Raymond, in his guide "The Art of Unix Programming", mentions this principle as Rule of Silence: "When a program has nothing surprising to say, it should say nothing." His statement probably related to command line applications, but it makes sense for a lot of cases.
It sounds smart but what counts as surprising is entirely context dependent and most programs won't be aware of your context. E.g. a command line app where you put a subtly wrong switch in that does exactly what it thought you wanted and prints nothing while outputting a 0 exit code is dangerous.
I follow your point, however it actually supports mine: An HTTP response isn’t intended to be the output of a command line app. A command line app should take the response from the lower-level HTTP communication and articulate whatever appropriate message to the user, depending on the verbosity level for example. Talking in OSI terms - this is a presentation layer problem, not a link layer one.
Re: Nginx Unit – Universal web app server
#145If you need just reverse proxy, Caddyfile syntax looks simpler: myapp.company.com { reverse_proxy localhost:3000 }
Came here to say Caddy still seems like the way to go for most use cases. Although I don't use it in any 'prod' environments it checks all the boxes.
Re: Nginx Unit – Universal web app server
#146Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?
>Why the obsession (it seems to be the prominent point in the readme) with configuration via API?
Infrastructure As Code (in all its forms, chef/puppet/ansible/tfe etc.) is the standard for all enterprise cloud setups these days. It makes sense to support that as a first class feature.
Re: Nginx Unit – Universal web app server
#147Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?
If the state you need at startup isn't the same as you need for production, this could be incredibly useful. It also means that you can save a lot of time starting and stopping containers for many common configuration changes in production. There's a lot more utility in this than just PHP.
Re: Nginx Unit – Universal web app server
#148Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?
This allows you to start up generic machines with no configuration and customize them after boot from a remote host. It's not so much "on the fly", as it is moving the long-term config storage to a different system.
I don't buy it. For this situation I would much rather have the software load its (regular) configuration file from a URL.
Re: Nginx Unit – Universal web app server
#149Re: Nginx Unit – Universal web app server
#150Why the obsession (it seems to be the prominent point in the readme) with configuration via API? How often do you need to add php support on the fly? I want to configure my app server via files so it just starts up in the state that I expect. What am I missing?
>Why the obsession (it seems to be the prominent point in the readme) with configuration via API? Infrastructure As Code (in all its forms, chef/puppet/ansible/tfe etc.) is the standard for all enterprise cloud setups these days. It makes sense to support that as a first class feature.
but this is the opposite of infrastructure-as-code
This is infrastructure-as-state
You have to manage automatically loading configs and keeping in sync with what you have in code, instead of deploying with a static configuration file