3 ms·

It's a nice joke, but IMHO it's not true... unless you don't know how Docker works

edu 5y ago
But then, by definition, the joke is true. Even if learning Docker makes sense and has a positive ROI it’a still an extra problem.
PaulHoule 5y ago
It is. You might have a 10 second build process that does 1 MB of disk IO and it becomes a 100 second build process that does 10 GB of disk IO because you ran it in Docker. I see people who "know how Docker works" put no care at all in the order of their image builds and end up doing 10-100x more IO than they need to. Docker is fast compared to the time scale most people deploy servers at but is slow compared to the scale of a healthy software development process particularly if you are not running on a cloud server or are working on a gigabit connection. If you took the time you spent trying to eliminate entropy from Docker, Kubernetes and such and actually tracked down the entropy that comes in from your environment (like the vandal who set your platform charset to not be "utf-8") you might find you don't have time to check your phone or send your co-workers stupid GIFs on slack waiting for builds.
- majewsky 5y ago
  > I see people who "know how Docker works" put no care at all in the order of their image builds and end up doing 10-100x more IO than they need to. I don't want to go into no-true-scotsman territory here, but this really is a literal contradiction.
- sofixa 5y ago
  > You might have a 10 second build process that does 1 MB of disk IO and it becomes a 100 second build process that does 10 GB of disk IO because you ran it in Docker. How and why? Unless you use a wrong image ( like Alpine for Python) or your Dockerfile is poorly made and cache doesn't work, nothing should change besides immutability and proper and clean dependencies ( your code won't work because you have some lib installed on your local machine by chance, and fail in prod because the lib doesn't exist or is ot a wrong version).
  - foxhill 5y ago
    > Unless you use a wrong image ( like Alpine for Python) or your Dockerfile is poorly made and cache doesn't work 1. this is implementation detail. 2. it shouldn't be so easy to write a bad Dockerfile 3. if it works, it works, and Docker encourages this approach. 4. and this damn cache: Docker is only tolerated in any way at all because of this. alternatively, it might be that baking an apple pie from scratch by first creating the universe is not the sensible thing to do. i think given the mass proliferation of Docker, i'm going to face some disagreement with this opinion: i don't think we're in a particularly good place where we have a billion deployments musl libc, busybox, nginx, and what else, all of varying versions. on top of the security implications of this, think of all the time and energy wasted in transferring all of this repeated data, on every deployment. i think it's madness.
    - PaulHoule 5y ago
      I never got into the Docker habit because I spent a lot of time behind a slow DSL connection. Assuming it worked, I could wait a few hours to bring down an image for the the first time. Often I could get the job done in the time it takes to suck down the first image if "doing the job" could be done without Docker. I never managed to use it enough that the images were in the cache when I needed them! To make matters worse, unlike many systems that do big downloads (esp. BitTorrent) Docker is not reliable at doing large image downloads. What people don't get is that the internet infrastructure is more expensive than they think because it is paid for in bits and pieces everywhere -- for instance it is an environment disaster that console games now come in 100 GB + downloads: https://gizmodo.com/downloaded-games-have-a-larger-carbon-footprint-than-bl-1630230310 https://gizmodo.com/downloaded-games-have-a-larger-carbon-fo...
rovr138 5y ago
You know need to know how your server works, how docker works and how your application works. You are introducing another layer of complexity.
- denysvitali 5y ago
  But you are getting the advantage of not upgrading a system library and break your Go application because it's not anymore up-to-date with the latest and greatest dependency. Unless you built it statically, that's another thing
  - rovr138 5y ago
    Of course, but if you update your docker image, you're in the same boat. The solution shouldn't be don't install security updates. It should be having a workflow that tests and validates security updates before deploying them to production. And you should have this with or without docker.

edu 5y ago

But then, by definition, the joke is true. Even if learning Docker makes sense and has a positive ROI it’a still an extra problem.

PaulHoule 5y ago

It is. You might have a 10 second build process that does 1 MB of disk IO and it becomes a 100 second build process that does 10 GB of disk IO because you ran it in Docker. I see people who "know how Docker works" put no care at all in the order of their image builds and end up doing 10-100x more IO than they need to. Docker is fast compared to the time scale most people deploy servers at but is slow compared to the scale of a healthy software development process particularly if you are not running on a cloud server or are working on a gigabit connection. If you took the time you spent trying to eliminate entropy from Docker, Kubernetes and such and actually tracked down the entropy that comes in from your environment (like the vandal who set your platform charset to not be "utf-8") you might find you don't have time to check your phone or send your co-workers stupid GIFs on slack waiting for builds.

majewsky 5y ago
> I see people who "know how Docker works" put no care at all in the order of their image builds and end up doing 10-100x more IO than they need to. I don't want to go into no-true-scotsman territory here, but this really is a literal contradiction.
sofixa 5y ago
> You might have a 10 second build process that does 1 MB of disk IO and it becomes a 100 second build process that does 10 GB of disk IO because you ran it in Docker. How and why? Unless you use a wrong image ( like Alpine for Python) or your Dockerfile is poorly made and cache doesn't work, nothing should change besides immutability and proper and clean dependencies ( your code won't work because you have some lib installed on your local machine by chance, and fail in prod because the lib doesn't exist or is ot a wrong version).
- foxhill 5y ago
  > Unless you use a wrong image ( like Alpine for Python) or your Dockerfile is poorly made and cache doesn't work 1. this is implementation detail. 2. it shouldn't be so easy to write a bad Dockerfile 3. if it works, it works, and Docker encourages this approach. 4. and this damn cache: Docker is only tolerated in any way at all because of this. alternatively, it might be that baking an apple pie from scratch by first creating the universe is not the sensible thing to do. i think given the mass proliferation of Docker, i'm going to face some disagreement with this opinion: i don't think we're in a particularly good place where we have a billion deployments musl libc, busybox, nginx, and what else, all of varying versions. on top of the security implications of this, think of all the time and energy wasted in transferring all of this repeated data, on every deployment. i think it's madness.
  - PaulHoule 5y ago
    I never got into the Docker habit because I spent a lot of time behind a slow DSL connection. Assuming it worked, I could wait a few hours to bring down an image for the the first time. Often I could get the job done in the time it takes to suck down the first image if "doing the job" could be done without Docker. I never managed to use it enough that the images were in the cache when I needed them! To make matters worse, unlike many systems that do big downloads (esp. BitTorrent) Docker is not reliable at doing large image downloads. What people don't get is that the internet infrastructure is more expensive than they think because it is paid for in bits and pieces everywhere -- for instance it is an environment disaster that console games now come in 100 GB + downloads: https://gizmodo.com/downloaded-games-have-a-larger-carbon-footprint-than-bl-1630230310 https://gizmodo.com/downloaded-games-have-a-larger-carbon-fo...

rovr138 5y ago

You know need to know how your server works, how docker works and how your application works. You are introducing another layer of complexity.

denysvitali 5y ago
But you are getting the advantage of not upgrading a system library and break your Go application because it's not anymore up-to-date with the latest and greatest dependency. Unless you built it statically, that's another thing
- rovr138 5y ago
  Of course, but if you update your docker image, you're in the same boat. The solution shouldn't be don't install security updates. It should be having a workflow that tests and validates security updates before deploying them to production. And you should have this with or without docker.