ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Docker for Production Use of Third Party Software

    IT Discussion
    docker containerization
    5
    13
    1.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • scottalanmillerS
      scottalanmiller
      last edited by

      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.

      Emad RE 1 Reply Last reply Reply Quote 2
      • FATeknollogeeF
        FATeknollogee
        last edited by

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

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

        scottalanmillerS 1 Reply Last reply Reply Quote 0
        • scottalanmillerS
          scottalanmiller @FATeknollogee
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • FATeknollogeeF
            FATeknollogee
            last edited by

            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?

            scottalanmillerS 2 Replies Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @FATeknollogee
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • scottalanmillerS
                scottalanmiller
                last edited by

                Putting Docker installs behind Nginx proxies seems to be consistently a problem.

                1 Reply Last reply Reply Quote 0
                • scottalanmillerS
                  scottalanmiller @FATeknollogee
                  last edited by

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

                  1 Reply Last reply Reply Quote 1
                  • scottalanmillerS
                    scottalanmiller
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • Emad RE
                      Emad R @scottalanmiller
                      last edited by

                      @scottalanmiller

                      I agree with the black box argument, and harder to maintain.

                      DevOps and the Death of the System Admin...

                      scottalanmillerS 1 Reply Last reply Reply Quote 0
                      • scottalanmillerS
                        scottalanmiller @Emad R
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • F
                          flaxking
                          last edited by

                          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.

                          scottalanmillerS 1 Reply Last reply Reply Quote 0
                          • scottalanmillerS
                            scottalanmiller @flaxking
                            last edited by

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

                            warren.stanleyW 1 Reply Last reply Reply Quote 0
                            • warren.stanleyW
                              warren.stanley @scottalanmiller
                              last edited by

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

                              1 Reply Last reply Reply Quote 1
                              • 1 / 1
                              • First post
                                Last post