Our great sponsors
-
NGINX Unit
NGINX Unit is a lightweight and versatile open-source web app server that has three core capabilities. It is a HTTP reverse proxy, a web server for static media assets, and an application server that can natively execute application code in seven different languages.
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
docker-postgresql
Dockerfile to build a PostgreSQL container image which can be linked to other containers.
-
ngx-php
ngx-php - Embedded php7 or php8 scripting language for nginx module. Mainline development version of the ngx-php.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
gunicorn
gunicorn 'Green Unicorn' is a WSGI HTTP Server for UNIX, fast clients and sleepy applications.
-
-
-
nerdctl
contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
This is great to read! Thanks for all the great input!
I check the comments next week and make sure to address the issues / ideas mentioned. If you don’t mind feel free to drop a comment here as well with your ideas / needs. https://github.com/nginx/unit/issues/945
I will work on a compression between Nginx and Unit to close this gap in our documentation.
Nope that's https://caddyserver.com/, which also improves on nginx in a number of other ways.
Honestly when I saw this post on the top of HN I thought I'd time-warped back to 2013. There is a better choice today. It's called Caddy.
> Yes, this is as bad as it looks: “success” isn’t even part of the schema. It’s in the examples, but not the actual schema definition.
Having gone through a pretty heavy overhaul of an "OpenAPI" (full code in Elixir at https://github.com/etalab/transport-site/pull/3351), I stumbled on that exact type of problem!
At the scale of nginx, having automatic verification that the examples (and the output of the API in general) match the specification would be great.
At our scale, here is what really helped me go through the rework (and ensure we do not regress too easily):
- setting additionalProperties to "false" to detect key field "rot"
- using "required: [x,y,z]" on everything, and by default specify "all the property keys", with an opt-out (so that each time a developer adds a field later, it is considered mandatory, unless otherwise specified)
- use tooling during the tests: "assert_schema" (with OpenAPISpex) to ensure our API endpoints responses pass the spec (additionalProperties: false helps ensure we get an exception in case of key field rot, again!)
- even more useful: crawl our production most important endpoints and tweak the spec until everything is green (an example of useful use of Task.async_stream in Elixir, by the way) https://github.com/etalab/transport-site/pull/3351/files#dif...
It can be super frustrating for users to live with the uncertainty of the response of an API for sure, and I was happy to discover the Elixir tooling (OpenAPISpex in particular) worked so nicely once I understood what I had to do.
I recently found this open source postman typed alternative, hadn't had time to really try it yet but the types stuff should help here no?
https://recipeui.com/
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.
Two questions:
1. Does Unit + PHP doing the typical “initialize & teardown” that PHP is know for?
Or is Unit persisting the initialization/setup, hence why it’s achieving the way faster results?
2. How is Unit/PHP architecturally different than NGX-PHP (an event loop)?
https://github.com/rryqszq4/ngx-php
I'm hoping so – gunicorn has a long-open pull request that would fix `--reuse-port`, which currently does nothing
https://github.com/benoitc/gunicorn/pull/2938
I found the actual file more illuminating:
https://github.com/PrivateBin/docker-unit-alpine/blob/master...
I am on docker swarm, too, and I like it.
Lunni? cool, thank you for sharing it, I'll give it a try
How to navigate the docs? in https://lunni.dev I only reach https://lunni.dev/docs/install/ while I see a lot of good docs https://gitlab.com/lunni/lunni.dev/-/tree/master/docs ...maybe not ready for the website?
Using nerdctl: https://github.com/containerd/nerdctl
I'd really disagree that compose files are somehow one-shot, or blindly modified. To the contrary, really, we have them checked in with the source code. Upon deployment to the cluster, the (running) services will be intelligently updated or replaced (in a rolling manner, causing zero downtime). LXC might be more elegant, but I have no idea what simple, file-based format I could use to let engineers describe the environment their app should run in without compose.
I need something that even junior devs can start up with a single command, that can be placed in the VCS along with the code, and that will not require deep Linux knowledge to get running. Open for suggestions here, really.