191–200 of 201 posts
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.
So much JSON... is that the real thing, as in comments are the gateway to hell, or is it actually some practical JSON superset like JSON5? I almost see myself jury-rigging some bespoke filesystem on-ramp to that REST configuration interface. Likely with at least half a dozen scary security compromises. Then on the other hand I guess they've never been afraid of getting called opinionated and that's certainly much bet…
JSON without comments is hell, forcing one to 1) convert JSON configuration to YAML. 2) add comments to YAML and admire it. 3) convert YAML to JSON for sending to the server.
How does this compare to uwsgi?
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
so I guess you are on Docker Swarm?
Actually yeah! A single node is usually enough for me though, but I like the ability to throw in more nodes as needed (more or less painlessly, as long as you properly guard services that need persistent volumes with a label constraint). Shameless plug: I also make a Docker Swarm dashboard, check it out: https://lunni.dev/
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?
Earlier quoted context omitted.
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.
Can you point to some examples of this?
LXC has profiles which can be mixed and matched for containers, it's got far more extensibility, compose files are a one-shot creation that gets copy/pasted/modified all over the place (we're all guilty of this), you need to read every single compose file and reboot unlike additively popping another profile on a linux container while it's running.
Earlier quoted context omitted.
Actually yeah! A single node is usually enough for me though, but I like the ability to throw in more nodes as needed (more or less painlessly, as long as you properly guard services that need persistent volumes with a label constraint). Shameless plug: I also make a Docker Swarm dashboard, check it out: https://lunni.dev/
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?
Edit: custom CSS for the homepage breaks navigation on inner pages on desktop. Should be fine now. Thanks for pointing this out!
Earlier quoted context omitted.
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.
> Compose can absolutely be used with Docker replacements Can you point to some examples of this? LXC has profiles which can be mixed and matched for containers, it's got far more extensibility, compose files are a one-shot creation that gets copy/pasted/modified all over the place (we're all guilty of this), you need to read every single compose file and reboot unlike additively popping another profile on a linux co…
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.
Earlier quoted context omitted.
In Linux where this is primarily expected to be used ASP.NET is extremely rare, as is C++ for web stuff, and Rust has a vanishingly small web presence still. Lots of people use Perl still though, if not for anything else, for legacy stuff. So might as well ask why it doesn't support Delphi.
I can’t say I know the percentage of Linux servers running ASP.NET Core but the percentage of ASP.NET Core apps running on Linux is no longer negligible. Bing runs it on Linux, iirc. This isn’t the dark days of .NET Framework anymore.
Earlier quoted context omitted.
>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
In this case, I think Nginx is trying to avoid the in-fighting that happens between platform teams and the various teams that they serve. Most platforms with static configuration don't make it easy to ACL the platform so that one user can't mess with another user. E.g. it would be hard to automatically prevent one user from trying to take another's domain name.
This config API could be ACL'ed so that you can update your application code, but not change it's domain name or IP. Or whatever else the platform team wants to cut off. This hopefully comes with ACLs like that, but if it doesn't you could always add it in a standard way with a reverse proxy that has ACLs. That's a lot easier to do than trying to write an nginx config parser to make sure platform users aren't tinkering with a particular setting in their config.