111–120 of 201 posts
Edit: yes, it’s as straightforward as it sounds: https://unit.nginx.org/howto/integration/
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.
That's like when I see APIs that give you responses with a 200 code, but then in the message there's a backend error.
In such an approach, any http-level error would be a network, server maintenance or other unknown/fatal error type of things.
App errors are encoded in the response body in a app-defined way.
It's not a completely bogus way of handling things, as long as it is perfectly consistent throughout the project and properly documented, which is rarely the case.
Earlier quoted context omitted.
Unironically this. After trying Kubernetes, Terraform, Ansible, and various proprietary PaaS config formats, I've grown to love Compose files' simplicity.
Yes, when compared to extreme complexity, compose is simpler. But it's hardly simple.
Not trying to be salty or anything – I really think Compose hits the sweet spot of abstraction which is less complex than both the monstrosities I listed and the ad hoc Bash scripts copying code over SSH and restarting services approach (so, the other extremity of declarative v. imperative).
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.
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.
{ "responseMessage": "Reconfiguration done.", "responseCode": 133, "isSuccessful": true }
This way you can map to a custom message on your front-end based on the responseCode whether its successful or not, you can fallback to the response message if no mapping is found, and you can easily check if the transaction was successful or not.
Earlier quoted context omitted.
In this particular example, it’s actually a whole lot worse than that, by spec at least. Excerpt from their OpenAPI schema https://github.com/nginx/unit/blob/7dd5ad93a4c147b086a8d82ec... >: jsonSuccessMessage: type: object description: "JSON message on success." additionalProperties: type: string jsonErrorMessage: type: object description: "JSON message on error." additionalProperties: type: string Yes, this is as ba…
By Serde's classification, `success: {}` is a textbook externally tagged representation.
Nginx Unit + PHP seems to handedly out-perform Nginx + php-fpm[1][2][3]. Also, Docker environments running PHP via Nginx Unit will no longer need separate containers for http + fpm, as it works similar to Apache's mod_php. 1. https://habr.com/en/articles/646397/ 2. https://medium.com/@le_moment_it/nginx-unit-discover-and-ben... 3. https://github.com/nginx/unit/issues/6#issuecomment-38407362...
You don't need separate containers to run nginx and php-fpm.
in my experience those are the ones that kick and scream when they don’t start as root.
This is an interesting idea, but I feel like it is a big oversight not to have build in support for automatically getting certificates. Instead the docs have you do something manual with certbot (a complete nono if you believe in automatic SSL and are using docker images that don't persist data, as Docker is meant to be used). The only reason I have SSL on my domain in the first place is that my host offers a simple…
> using docker images that don't persist data, as Docker is meant to be used docker volumes entered the chat
Earlier quoted context omitted.
wait, did that continue to use php-fpm? if not I want details plz! :D (especially around the logging sync, unless it’s just php-fpm configured to collect child process output)
Yes, it did, not too much magic going on, the Go proxy also was a replacement for supervisord so it started nginx and fpm, reaped zombies and pulled all the important logs into stdout/stderr. The most remarkable thing was how this revitalized a team that wrote boring PHP software limited to deploying via FTP on PHP 5. They ended up really getting into stripping out every piece of PHP they didn't use because the image…