Docker for Production Use of Third Party Software
-
@FATeknollogee said in Docker for Production Use of Third Party Software:
Using mailcow: dockerized ...good idea, bad idea?
Great for testing, but I wouldn't run it in production that way because if something breaks, I have to be the person who knows how it works and how to fix or configure it. That it is nothing to do with mailcow, it's a general "how to deploy in production" thing.
-
Unfortunately, Docker seems to be the only "supported" method of installing mailcow, unless I read that wrong.
Maybe someone else has better or more up to date info? -
@FATeknollogee said in Docker for Production Use of Third Party Software:
Unfortunately, Docker seems to be the only "supported" method of installing mailcow, unless I read that wrong.
Maybe someone else has better or more up to date info?Pretty sure that there was another option the last time that I looked. But it has been a little while.
-
Putting Docker installs behind Nginx proxies seems to be consistently a problem.
-
@FATeknollogee looking now though, I don't see any other process
This follows @JaredBusch concern that the product was losing steam as their main guy appeared to have stepped away from it as a full time thing. -
Honestly, the changes on MailCow's website make me feel like they are being paid to promote Docker. Stuff like this...
-
I agree with the black box argument, and harder to maintain.
DevOps and the Death of the System Admin...
-
@Emad-R said in Docker for Production Use of Third Party Software:
DevOps and the Death of the System Admin...
I don't see Docker as DevOps in any way, just an avoidance of it. The anti-devops. DevOps as we see it in enterprise is just "system admins on steroids." Docker is for "we didn't have operations at all and just let the devs run loose". No ops, at all.
-
It depends. I often don't trust just being given a Docker image. I want to see the Dockerfile. Then I can decide whether or not I want to make my own based off of that Dockerfile, or use that one. So that means understanding it.
For example, if I was going to provide a MailCow hosted service, I'm not going to just build the stack and call it good if it works. As the maintainer of that service I need to know how all the components work together.
Now it could be a different story if that image/stack came with direct support. I would still have to know how my Docker Swarm/Kubernetes Cluster works, but is it much different than installing software? We have to know how the OS and networking works, but there can be a lot that the software is doing that is a black box to us. Docker just takes it up another level.
-
@flaxking said in Docker for Production Use of Third Party Software:
It depends. I often don't trust just being given a Docker image. I want to see the Dockerfile. Then I can decide whether or not I want to make my own based off of that Dockerfile, or use that one. So that means understanding it.
For example, if I was going to provide a MailCow hosted service, I'm not going to just build the stack and call it good if it works. As the maintainer of that service I need to know how all the components work together.
Now it could be a different story if that image/stack came with direct support. I would still have to know how my Docker Swarm/Kubernetes Cluster works, but is it much different than installing software? We have to know how the OS and networking works, but there can be a lot that the software is doing that is a black box to us. Docker just takes it up another level.
Yeah, I agree. It's that Docker is "meant" to avoid all this that bothers me. It's not the Docker tech itself, and there are ways to use it well. But once we are doing all of that, what is Docker really getting for us? Not very much.
-
@scottalanmiller these discussions echo my thoughts exactly. I'm only (hesitantly) learning Docker now, but it feels like it's not a long term answer(I'm possibly too late to the party?), as other approaches are increasing in mind-share.
