Docker for Production Use of Third Party Software



  • Having this discussion elsewhere. Having looked into Docker as a deployment tool for production, the question came up if Docker should be used for the production deployments of third party software.

    Let me break down what we mean because this is very specific...

    Using Docker for developers is out of scope, of course Docker is "production ready for development", that's its wheelhouse.

    Using Docker for testing software is out of scope, there is no "production" in testing, Docker (in theory) is very good for this.

    Using Docker for production deployments of your own bespoke software where you control the entire stack is out of scope, that is not third party.

    If Docker itself is production ready is not in question. It is process

    The question is about running production server side workloads, when the software that you are running is third party. Only this case is in scope.

    My answer is "no", it is not a "production ready process." Production readiness is the culmination of your processes, not about a single product in isolation in the stack. The use of Docker for production is promoted for the purpose of platform independence, ease of deployment (basically the IT use of the Jurassic Park Effect) , quick and easy deployments without understanding the product, etc. Basically going against "production mindset."

    For a production workload, we want the opposite. We want to do our due diligence up front (before we are live) so that we are best prepared to understand and support the workload once it deploys. We don't want "deploy anywhere", we want to carefully deploy where it makes sense and is tested. We don't want to skip pieces, because when things break we need to be ready to fix them.

    It's nothing against Docker, or containers. It's the reasons why third parties make software in Docker and the reasons that we choose that for development that make it a problem. Docker tends to "black box" software, and add complexity. It feels like it doesn't, until we need to fix something. Then suddenly we realize how much more complex it is. And for production mindset, we always have to consider how we will fix it when it breaks, not just hope that it doesn't.



  • Good discussion to have, allows one to bypass the "hype".

    Specific question:
    Using mailcow: dockerized ...good idea, bad idea?



  • @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...

    Screenshot from 2019-05-13 10-51-01.png



  • @scottalanmiller

    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.


Log in to reply