A big project not handling HTTPS themselves (like docmost), adds tons of complexity on the server side. Now, I have to install that service as a container to isolate that, then need to add a reverse proxy on top, etc.
That leads to resource inflation when I just want to use a small VM for that single task. Now, instead I deploy a whole infrastructure to run that small thing.
You can setup a Traefik (or some other ingress service) instance in a container and let it handle all the reverse proxying thingies for you. And if you do it right, the services should automatically register to the ingress service as they start up, and a port/HTTP route should be automatically assigned to them.
Do it in the old bare is harder and probably will always be harder, since you will be directly interact with OS facilities that was probably designed for something else than what you might try to run. Container management service such as Docker and Kubernetes abstracted away a lot of these complexities.
Funny enough, Traefik is written in Go... guess we've gone some (maybe not full) cycle on this one.
Containers are not bad per se, but cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO. Because not all of us have homelabs at home to install an onion of services to run a simple service open to outside.
A good example of this is Wiki.js. It's desinged as container native, but handles its own ingress, HTTPS and Let's Encrypt certificates. I have no qualms to it, but when another tool just cuts corners and tells you that "It's easy to install, but bring your own secure ingress layer on top", it gets ugly.
Because it adds moving parts, most importantly wastes resources for a 3 person installation on small hardware, etc. Keep in mind, these are tools designed for small user-bases. They're not enterprise software.
On my day job, we call 80 machine clusters "small". But this is not about things I install/manage at my job.
> it involves less moving parts
Every sane person who experienced a few server updates will not put out claim like that. One day you ran `apt upgrade -y`, minutes later 30% of your clients PHP website somehow went down? "less moving parts"?
In fact, Docker was invented to address this exact "it worked on my machine, why not yours" problem, by actually introducing "less moving parts".
> cutting corners just because "this will run in a container, so they can just add another HTTPS terminator" is just carelessness IMHO
Stop trying to misrepresent anything. No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator". Also, for real, how can you terminate HTTPS twice?
Also, from your another post:
> Traefik plus my service is two layers. My service has a DB hidden behind it, it's three layers. I put a VPN in front of it, and now it's four.
Why stop there, if you start from user's keyboard as a layer, then there's 5, and screen 6, then countless Internet cable and routers. Man! so many layers, it's crazy!
Also, that's not how you structure things. You have a reverse proxy, and then a service, 2 layers total.
And VPN? Oh boy you'll probably be surprised that Docker has cross-node communication built right in (https://docs.docker.com/engine/network/drivers/overlay/), so you don't even need VPN to connect to your database.
Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.
No!?
> everybody is down voting your 42133422 post to shit
They can, we don't have to agree on everything.
> so you're down voting everyone who replied you?
You can't downvote replies to your own comments, plus I don't downvote people because they have a different view than mine. Heck, I don't downvote as a principle. As long as the comment needs a flag, too.
> No one is trying to solve a problem by wrapping HTTPS terminator with "another HTTPS terminator"
Ow. I say "people don't add https functionality to their code, because they expect it to be done elsewhere, and that's bad practice". Do you read what I have written?
> Why stop there, if you start from user's keyboard as a layer...
Can you just calm down?
> And VPN? Oh boy you'll probably be surprised that Docker has cross-node communication built right in (https://docs.docker.com/engine/network/drivers/overlay/), so you don't even need VPN to connect to your database.
Who said I use a VPN to connect to my database? I have a closed/dark network of hosts on different locations sitting behind a NATs forming a personal network. This is what that VPN is about.
> Alright, alright, please, just admit that currently containerization is not a technology you can correctly take advantage of, and then you go ahead and learn more about it. It will be an useful tool for you, as it did for many, I'm sure.
Alright, alright, please just admit that you didn't understood a single bit of my posts, and can't paint a picture of what I'm talking about, and then you go ahead and read it all again. It will be a useful exercise for you, as it did for many, I'm sure.
Now I need to clean my keyboard of this coffee, and need to handle my OpenStack cluster. Oh, boy...
Thank you.
:)