4 ms·

> Docker images create a bigger burden on your deployment as you have these large images to distribute, modify, manage Compared to what, though? Of course if y

by shykes 13y ago

> Docker images create a bigger burden on your deployment as you have these large images to distribute, modify, manage Compared to what, though? Of course if your environment is homogenous enough that you can express your application as, say a Jar or a gem - then you are part of the lucky few and may indeed not need docker, because you share enough context with your target infrastructure that a lot of the bits are already implicitly deployed. (In other words: someone else had to move a big-ass system image around so that you don't have to). But the typical application stack is not like that. It is heterogeneous and custom, and the only practical way to ship it reliably is to ship the entire system with it, because you've run your tests on a particular libc, postgres and ruby, built by a particular gcc, etc. In that case, your options are limited: 1) ship a VM or 2) ship system packages. And if your current options are indeed to either ship a VM or system packages - then Docker suddenly doesn't seem that heavyweight after all :)

peterwwillis 13y ago
Compared to, for example, using separate systems to manage the development, change management, approval, deployment, bug tracking, revision control, and other aspects of making a change to production. The Docker image may include several of those subsystems, or cross multiple of them, and so it now needs to be flexible enough to change one or several of those parts before it can be pushed to production to fix a bug. And what production environment will it be applied to? And is it possible that indeed you will have several images that are almost the same, except for key parts that can't be easily handled by yet-another overlay? (How many overlays will you have? Will you eventually stop adding overlays and redo the image to include the fix? What else will that affect?) Complex systems require complex interaction, and Docker images do not allow for that; they are monolithic, all-or-nothing changes which can only be "modified" by either remaking the entire image (expensive), or adding another layer of overhead on top, which I don't think anyone has ever investigated to find bottlenecks or overhead problems. To put it in simpler terms: Cfengine delivering a single change on a single file to a dynamically-assigned set of nodes is a lot faster, lower overhead, and direct than deploying a Docker change.
- contingencies 13y ago
  A lot of your concerns are around ops, and I agree that docker has a pretty immature approach there. That said, most of the sysadmin world has the same problem. Hell, people still do things manually or with PFCTs (post-facto configuration tinkerers) ... without prior testing! Cfengine delivering a single change on a single file to a dynamically-assigned set of nodes is a lot faster, lower overhead, and direct than deploying a Docker change. To container-based architectures' credit, cfengine-style changes are not as 'known', since there are aspects of the environments that may differ. Containers can be 100% accurately cloned so significant testing can be performed before deployment. Of course, you could test with cfengine as well, it's just that when you attempt to set up nodes to do the tests against you'll suddenly realize the utility of container-based virt ;)
  - peterwwillis 13y ago
    Containers can be 100% accurately cloned so significant testing can be performed before deployment. This has been the catch-22 i've had problems explaining, so bear with me here. Your docker container and my cfengine change are exactly the same thing in terms of testing and guarantees of sameness. So, you have a Docker, and you hand-built it to an exact specification, and made an image that does a specific thing. You ship that image to 1000 nodes and it works "exactly the same" across all of them. So, I have Cfengine, and I hand-configured it to an exact specification of operations, and made a config file that does a specific thing. I ship that config to 1000 nodes and it works exactly the same across all of them. Why did they both end up giving me exactly what I expected? Because I controlled the input and the structure of the files to exactly my specifications, and nothing changed in those files once it was copied to the nodes, so they worked exactly as I expected. We can also assume I had no other dependencies for either to work. (The Cfengine dependencies were the cfengine binary, which we can ensure is the same version across all hosts pretty easily. The Docker version, and the whole "ecosystem" of docker tools, is similar to enforce, though the much wider range of dependencies will make it much harder to support the same ones on all platforms, which is where we have to start using a unified platform, which is where the whole "run it anywhere on anything" bullshit becomes painfully unrealistic) Uh-oh, here comes trouble! A developer comes over and wants 10 of the 1000 nodes to work a little differently. OK, we make a config file that Docker will read to configure the service a little different. Separately, we can make Cfengine read a similar config file that tells it how to configure the node differently. We ship the config file off to the 10 nodes, and Docker/Cfengine reads it in and changes its operations. All of a sudden we have unexpected behavior due to the new instructions in the config file. One hundredth of our hosts are doing something different and we have to now account for that in anything else that happens in the future. (That is not some drawback of some technology, btw; that is called "I have a real network where things work differently across it"). The practical differences between these two is that the Cfengine change can be tested and applied quicker than a Docker, it doesn't force you to choose how to update your application ("am I updating the image? am I adding an image? am I changing the Dockerfile? am I changing the config? should I restart the docker or the service? do I have to reconfigure the autodetecting whatsit?" etc), and instead of hiding changes in a "Dockerfile" which is only parsed at build time, it keeps changes forefront in a configuration parsed at run time. You can make either one work just as reliably as the other. But one is a hell of a lot clunkier to get working in all cases than the other. Also, i'm comparing a configuration management tool to a chroot environment network transfer tool, so take all of this with a grain of salt.

by shykes 13y ago

peterwwillis 13y ago

Compared to, for example, using separate systems to manage the development, change management, approval, deployment, bug tracking, revision control, and other aspects of making a change to production. The Docker image may include several of those subsystems, or cross multiple of them, and so it now needs to be flexible enough to change one or several of those parts before it can be pushed to production to fix a bug. And what production environment will it be applied to? And is it possible that indeed you will have several images that are almost the same, except for key parts that can't be easily handled by yet-another overlay? (How many overlays will you have? Will you eventually stop adding overlays and redo the image to include the fix? What else will that affect?) Complex systems require complex interaction, and Docker images do not allow for that; they are monolithic, all-or-nothing changes which can only be "modified" by either remaking the entire image (expensive), or adding another layer of overhead on top, which I don't think anyone has ever investigated to find bottlenecks or overhead problems. To put it in simpler terms: Cfengine delivering a single change on a single file to a dynamically-assigned set of nodes is a lot faster, lower overhead, and direct than deploying a Docker change.

contingencies 13y ago
A lot of your concerns are around ops, and I agree that docker has a pretty immature approach there. That said, most of the sysadmin world has the same problem. Hell, people still do things manually or with PFCTs (post-facto configuration tinkerers) ... without prior testing! Cfengine delivering a single change on a single file to a dynamically-assigned set of nodes is a lot faster, lower overhead, and direct than deploying a Docker change. To container-based architectures' credit, cfengine-style changes are not as 'known', since there are aspects of the environments that may differ. Containers can be 100% accurately cloned so significant testing can be performed before deployment. Of course, you could test with cfengine as well, it's just that when you attempt to set up nodes to do the tests against you'll suddenly realize the utility of container-based virt ;)
- peterwwillis 13y ago
  Containers can be 100% accurately cloned so significant testing can be performed before deployment. This has been the catch-22 i've had problems explaining, so bear with me here. Your docker container and my cfengine change are exactly the same thing in terms of testing and guarantees of sameness. So, you have a Docker, and you hand-built it to an exact specification, and made an image that does a specific thing. You ship that image to 1000 nodes and it works "exactly the same" across all of them. So, I have Cfengine, and I hand-configured it to an exact specification of operations, and made a config file that does a specific thing. I ship that config to 1000 nodes and it works exactly the same across all of them. Why did they both end up giving me exactly what I expected? Because I controlled the input and the structure of the files to exactly my specifications, and nothing changed in those files once it was copied to the nodes, so they worked exactly as I expected. We can also assume I had no other dependencies for either to work. (The Cfengine dependencies were the cfengine binary, which we can ensure is the same version across all hosts pretty easily. The Docker version, and the whole "ecosystem" of docker tools, is similar to enforce, though the much wider range of dependencies will make it much harder to support the same ones on all platforms, which is where we have to start using a unified platform, which is where the whole "run it anywhere on anything" bullshit becomes painfully unrealistic) Uh-oh, here comes trouble! A developer comes over and wants 10 of the 1000 nodes to work a little differently. OK, we make a config file that Docker will read to configure the service a little different. Separately, we can make Cfengine read a similar config file that tells it how to configure the node differently. We ship the config file off to the 10 nodes, and Docker/Cfengine reads it in and changes its operations. All of a sudden we have unexpected behavior due to the new instructions in the config file. One hundredth of our hosts are doing something different and we have to now account for that in anything else that happens in the future. (That is not some drawback of some technology, btw; that is called "I have a real network where things work differently across it"). The practical differences between these two is that the Cfengine change can be tested and applied quicker than a Docker, it doesn't force you to choose how to update your application ("am I updating the image? am I adding an image? am I changing the Dockerfile? am I changing the config? should I restart the docker or the service? do I have to reconfigure the autodetecting whatsit?" etc), and instead of hiding changes in a "Dockerfile" which is only parsed at build time, it keeps changes forefront in a configuration parsed at run time. You can make either one work just as reliably as the other. But one is a hell of a lot clunkier to get working in all cases than the other. Also, i'm comparing a configuration management tool to a chroot environment network transfer tool, so take all of this with a grain of salt.