> be banned if I asked about it
I assume this means the maintainer(s) have experienced the above a few times, and have given up trying to be more polite about it!
Don't take it personally. If you want to use a tool with that plumbing then feel free to DIY. If you make it work well, perhaps publish your process and/or images and support it for others who need/want that support.
Also, it doesn't even make sense on the engineering point of view. I understand not liking Docker the company or Kubernetes the product, but Linux namespaces are a kernel level facility, and banning people because they dare ask how to integrate this product with a native subsystem seems absolute zealotry from people with oversized ego.
Nothing wrong with that, but let's call a spade a spade. It's their project, so it's their right to be a prick about it, but that shouldn't stop other people to call them out on it.
There is. And I'm suggesting that the water filling that ocean has come from having the same discussion over and over again with people who have asked in the past, each thinking they might be the one to finally help you see the light. I've not personally dealt with it from the point of view of infrastructure choices, but I hear tale of those who have, and I've been subject to it with regard to people who didn't agree with a licence choice so can speak for how much it makes you not want to engage at all just-in-case.
I'm not suggesting you'd be like that, but I understand not wanting to engage on the matter based on previous experiences.
> that would take less effort than
Unfortunately, not always. Sometimes the only way to convince people that it isn't worth their time continuing to try to change your mind, is to blatantly be a dick about it. I try not to jump straight to dickishness though: I'll state my position politely once, I may have time to repeat that once or twice more, then out come the big guns.
On a public mailing list or similar I might be more blunt: linking to past discussions in the first instance then jumping to DickCon1. On a public group the discussion is taking more than just my time and might encourage others to chime in and drag the matter instead of letting it close.
And again: the suggestion of “banning on sight” could have been intended as an attempt at humour by way of hyperbole, rather than the direct “off you fuck” that was felt. Communication of sentiment online is very prone to errors like that.
This is exactly my point: given that online communication is low bandwidth, why are you attempting humour with someone new, who is therefore very unlikely to get it? (And, given Drew's track record, I find it extremely unlikely that he is just trying to be funny, but that's a different matter.)
Also, your point about not wanting to spend more time on a discussion than is necessary, you can simply... not. Say not interested, post a link to a FAQ that covers your stance, and simply don't engage. You don't need to be offensive. You don't need to be worried about people dragging the matter. It's just a discussion.
I will be very surprised if Drew isn't called in by his communities at some point.
I asked once and didn't get a response for what I think was 3-5 days and asked again (it is a low frequency channel, but that gap seemed appropriate). I wasn't making a religious argument, literally just asking about the availability of images.
> Don't take it personally. If you want to use a tool with that plumbing then feel free to DIY. If you make it work well, perhaps publish your process and/or images and support it for others who need/want that support.
I mean Drew was pretty clear that I couldn't even ask questions related to either subject in that channel. I don't take it personally, but it certainly affected the way that I view the project and Drew as a human being.
https://gist.github.com/GavinRay97/e3c166c5ba24c2c1bc4a09d7b...
He said "Docker isn't a supported installation mechanism."
I wasn't aware of Drew's anti-docker stance, whoops.
https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d28...
I was researching Keycloak integration with Kubernetes (a project needed it at the office).
I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS.
If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is.
The person didn't learn how to use and administer Keycloak, didn't make good judgement calls about security and published bad information while doing that.
Docker is easy to abuse and creates people who think know stuff, but do not in reality.
Docker. Pull Responsibly (TM).
Listen, I understand not liking containers. That's fine. But just say so, or try to give more concrete arguments to the table than "I saw a guy in a video creating an insecure container. Thus Docker creates ignorance."
As if configuring servers by hand isn't prone to misconfiguration or bad security practices. Perhaps we have namespaces today because people have been creating insecure, unmaintainable pet systems since the stone age, yet it doesn't save you from hurting yourself if you don't know what you're doing.
You're building rest of your comment on this misinterpretation of my comment.
What I say is "Docker is easy, but it lowers the bar for making mistakes too much. Using Docker without enough information creates bigger problems, faster".
You can do a lot of mistakes, and fatal ones at that, while working on bare metal too. I'm managing systems for 15+ years, using Linux close to 20, and had my fair share on any abstraction level (metal, VM, container, etc.).
However, K8S and Docker is susceptible to create a whole set of problems, and more importantly without knowing it, until it's too late. VMs and bare metal fail relatively early and with more noise. If you do something wrong with your K8S deployment, you can't mend it, and need to re-deploy it.
I do not prefer Docker and K8S, and avoid the latter if I can, but I'm not an hard-line extremist against any of them. I also manage containers and a K8S cluster at work, too.
And no, I never patronize anyone. This is not my style. I just shared my experience, and told that "learning wrong things is easier with Docker", that's all.
I know excellent developers and sysadmins who do wonders with containers, too. Docker and K8S are sharp knives with no warnings on them. That's all.
And that's nothing wrong with that. You might also "hurt" yourself by installing software by hand.
Let's agree to disagree, this "it could be dangerous!" argument feels like doubling down on a weak position, but I honestly do not care about fighting someone over the internet about it. Your computer, your rules :-)
Yes, except poor documentation and lots of open secrets.
There is no need to fight. We're just discussing. We can do things differently and obtain the same brilliant or disastrous results regardless of the underlying abstraction layer/platform.
All approaches have advantages and disadvantages, so all takes are equally weak IMHO.
Have a nice day,
Cheers.
> I saw a guy in a video creating an insecure container. Thus Docker creates ignorance
It's more than a guy. Once you see that kubernetes is corporate bloat you gotta ask for the responsability of the people making it. Yes it's creating people that don't understand how things are actually wired (and no, this is not a "natural" direction of history). It's making people dependent on complex stuff and it's actually hiding from mainstream knowledge the simple ways to do simple stuff. I recently had to help someone deploy stuff on an openshift hosting and i must say the experience is infuriating (not even talking about the runtime efficiency of managing the bazillion moving parts).
> If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is.
Would you mind sharing your argumentation about this, both in the context of Keycloak and in general?
In my eyes, enabling TLS on whatever application you want to run directly is almost always a bad choice, because you now need to deal with its unique implementation, as well as any vulnerabilities that the implementation could have. For example, even if all of your services run Java, you might find that a Spring application, a Spring Boot application, a Quarkus and a Vert.X application all have different ways of enabling it:
Spring example: https://www.baeldung.com/spring-channel-security-https
Spring Boot example: https://www.baeldung.com/spring-boot-https-self-signed-certificate
Quarkus example: https://quarkus.io/guides/http-reference#ssl
Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs)
In contrast, when you have a web server as your point of ingress, that then acts as a transparent reverse proxy in front of your applications:
- it takes care of all of the certificates, in a common format, they're easy to renew or can be provisioned thanks to ACME
- it can take care of other concerns, like path rewriting, HTTP to HTTPS redirects, rate limiting, additional caching or headers
- your applications can talk to one another in the internal network through HTTP, whereas encryption there can be added transparently
- with containers, this might be an overlay network where the clustering/networking solution takes care of internal certificates and rotates them often
- it's easier to screw things up and expose stuff directly (e.g. port mappings, instead of overlay networks)
- one could feasibly argue that sometimes the application itself might want to look at the certificates and do something with them (e.g. expiry alerts)
- one could also argue that reverse proxies won't necessarily be perfect and some software might not correctly deal with headers