Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx Unit – Universal web app server

github.com

Post reply on HN
Print view View original

171–180 of 201 posts

Re: Nginx Unit – Universal web app server

#171

Post by pstuart »

22c wrote: post #152
fragmede wrote: post #151

Earlier quoted context omitted.

> How often do you need to add php support on the fly? Restarting the binary means you'll lose requests while it's restarting, so adding php (or whatever) support on the fly is what you need when running a system where losing those requests is material. Which it won't be for most people, but for, eg, Google (who don't use Nginx), losing those requests is a problem.

Although it doesn't directly go against what you're saying, many Unix daemons have supported HUP signals for decades which can achieve the same outcome. No need to configure via API, just change the configuration on disk and send HUP. I suppose arguably that becomes a bit trickier for containers, so perhaps that's why you'd want to configure via an API?

Nginx can reload configs on HUPs -- https://docs.nginx.com/nginx/admin-guide/basic-functionality...

Re: Nginx Unit – Universal web app server

#172

Post by warvariuc »

wongarsu wrote: post #102
conradfr wrote: post #101

Earlier quoted context omitted.

You don't need separate containers to run nginx and php-fpm.

Are you implying that docker containers don't run a unikernel that can only run one application at a time? /s

I am happily running Nginx + supervisord + several Python apps in a single Docker container.

Re: Nginx Unit – Universal web app server

#173

Post by rob-olmos »

e12e wrote: post #126
martinsnow wrote: post #121

Earlier quoted context omitted.

I too would like to see a properly configured php+php-fpm container benchmark. There's a lot of overhead when you link by http instead of a unix socket, in the same container.

Technically, you should be able to share a domain socket via a shared volume too (between an "app" and "web" container) - as with postgres: https://github.com/sameersbn/docker-postgresql/issues/30#iss... Curious about benchmarks and tests of TCP vs Unix domain sockets between docker containers.

Another example is API Platform's docker setup:

Volume config: https://github.com/api-platform/api-platform/blob/main/docke...

Caddy config: https://github.com/api-platform/api-platform/blob/main/api/d...

php-fpm config: https://github.com/api-platform/api-platform/blob/main/api/d...

I'm also curious on the performance differences between containers.

Re: Nginx Unit – Universal web app server

#175

Post by 9dev »

Grimburger wrote: post #161
9dev wrote: post #143

Earlier quoted context omitted.

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?

How are you using compose without docker? They are joined at the hip, criticism of one is criticism of the other. The days of cheap money are over, it's inevitable that certain SaaS companies will start tightening the screws on their users to match the returns they can get with cash in a bank. I just wish lxc (which docker was built off) got a chance to gain traction. It's miles ahead in DX and sure they serve differ…

No, that isn't true. Compose can absolutely be used with Docker replacements, and there is no reason you couldn't create an implementation for LXC, for example.

Re: Nginx Unit – Universal web app server

#176

Post by nirse »

pbreit wrote: post #174

Can someone explain what this is to a novice web app developer?

This is a webserver that can run various web applications for you. In a typical setup you'd run a web/http server (nginx or Apache etc) to handle the 'slow' connections to the client and a separate app server (say, an express application, or Django or Rails etc) that is completely separate from the webserver. The web server acts as a reverse proxy, sending the request on to the app server. The response from the app server is then passed to the webserver, which sends it back tot he client. So a request would this path: client -> web server -> app server -> web server -> client.

This is done because web servers are optimised to handle (many) requests from clients (including things like TLS termination, optimised handling of static files, orchestrate to which backend service to send a request and much more), while application servers are optimised to run the application code.

In this model, the web and app servers run separately, for example in separate containers and they have to talk to each other so you have to somehow connect them (often this is done through a network socket).

So what Nginx Unit does is combining the two: it can do the standard web server stuff (not everything a normal nginx can do, but often that's not needed anyway), but also run your application for you, which could, depending on your setup, make your life a bit easier, as now you don't have to tie the two together.

Re: Nginx Unit – Universal web app server

#177

Post by riobard »

bewuethr wrote: post #135
layer8 wrote: post #103

They should make a page explaining how this differs from Nginx and why it needs to be its own separate thing. I couldn’t find such a page.

Here maybe? https://www.nginx.com/products/nginx-unit/

I think the puzzle essentially boils down to: what does it mean by "natively run application code"?

Re: Nginx Unit – Universal web app server

#178

Post by joaofs »

ramesh31 wrote: post #146
gibmeat wrote: post #90

Why 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.

First step to create a terraform provider.

Re: Nginx Unit – Universal web app server

#179

Post by aforwardslash »

_cenw wrote: post #32
mindwok wrote: post #11

Well I commend the Nginx team for trying something new and launching this, even though I'm not sure what I would use it for personally. Slightly tangental, but it always irks me when I see these kinds of responses in JSON: { "success": "Reconfiguration done." } Really this should be something like "result": "success". Using "success" as a key name tells me nothing about the data it's representing.

Unit has been around for half a decade. It feels like an evolution to something like Phusion Passenger, but it's not quite cloud-native. A lot of the documentation is tailored to installing directly on a server and some essentials (i.e. prometheus metrics) are missing. I briefly evaluated it for bringing a PHP team into our Kubernetes cluster, but then ended up writing a bit of Go code to proxy into a real nginx+fcgi…

depending on the desired metrics, the Unit /status endpoint may provide enough info, and transformation of json to prometheus metrics is somewhat easy with existing tooling

Re: Nginx Unit – Universal web app server

#180

Post by gertrunde »

Nginx Unit helped me out of a hole recently - needing to deal with a legacy Python 2.7 web application, while trying to keep it as 'supported' as possible (ignoring the whole python 2.7 thing for the moment!).

Nginx Unit, with their python 2 module, on Debian 11 ended up working petty well.

Post reply on HN