5 ms·

>"We don't need more complex provisioning tools. We have plenty of provisioning tools." Absolutely. Thankfully, the Docker team seems in agreement with this b

>"We don't need more complex provisioning tools. We have plenty of provisioning tools." Absolutely. Thankfully, the Docker team seems in agreement with this based statements about avoiding making Dockerfiles "too clever" and the response to various proposals. As you point out, most of the "issues" here are really misconceptions. I expect it's a tough balance for any new(er) project. Maximizing exposure and adoption, but avoiding negative perceptions from being applied in ways aren't optimal.

zwischenzug 12y ago
Dockerfiles are deliberately dumb to let other tools take over as necessary, is my understanding. My experience (over the last year) is that they're so limited as to be pretty useless. They don't even do what they're advertised to do, ie give you a reliable way to reproduce a build, and they're inflexible for my idea of real-world work with Docker. Where they're good is in giving everyone a point of reference. I had a discussion with the maintainers last year about this: https://groups.google.com/forum/#!topic/docker-user/3pcVXU4hgko https://groups.google.com/forum/#!topic/docker-user/3pcVXU4h... I have a problem with most CM tools in that they're for moving target systems, not immutable ones. Ansible is the closest, but our experience has been that development on it is slow relative to the tool we use (see below). It's saved us a ton of money. I blog on this and similar topics here: http://zwischenzugs.wordpress.com/ http://zwischenzugs.wordpress.com/ The "tool for building and maintaining complex Docker deployments" is here: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ https://github.com/ianmiell/shutit https://github.com/ianmiell/shutit I also talk about this here: https://www.youtube.com/watch?v=zVUPmmUU3yY https://www.youtube.com/watch?v=zVUPmmUU3yY
- incision 12y ago
  >"They don't even do what they're advertised to do, ie give you a reliable way to reproduce a build, and they're inflexible for my idea of real-world work with Docker." Not exactly, as the thread you link points out you can reference an image ID in FROM rather than the name:tag which has potential to change silently. It's the equivalent of using a package manager against a repo you don't own without pinning - expect problems. This can be mitigated by FROM'ing via ID or avoided entirely by running your registry where tags are reliable. Admittedly, these things are not necessarily obvious, but I think it's a bit disingenuous to paint Dockerfiles as worthless or broken. That said, ShutIt looks very cool and seems to address exactly some of my concerns / desires about working with Docker. I just don't agree with framing it in opposition to and at the expense of what exists. There's value in a container description that is fully self-contained, transferable and 'dumb' enough to be transparent.
  - zwischenzug 12y ago
    Hi, yes you're right - you can reference an image ID. However, as soon as you go to the network you're lost - any apt-get/yum update or install could break your system in surprising ways. Having done _lots_ of builds lately I can vouch for that (see my blog for some examples). In the end the image ID _is_ useful, but the dockerfile itself has limitations. I agree with your last point as well - my evangelism comes from solving problems at my company in this way (which I know are not uncommon problems) rather than any belief that it beats others objectively.

zwischenzug 12y ago

Dockerfiles are deliberately dumb to let other tools take over as necessary, is my understanding. My experience (over the last year) is that they're so limited as to be pretty useless. They don't even do what they're advertised to do, ie give you a reliable way to reproduce a build, and they're inflexible for my idea of real-world work with Docker. Where they're good is in giving everyone a point of reference. I had a discussion with the maintainers last year about this: https://groups.google.com/forum/#!topic/docker-user/3pcVXU4hgko https://groups.google.com/forum/#!topic/docker-user/3pcVXU4h... I have a problem with most CM tools in that they're for moving target systems, not immutable ones. Ansible is the closest, but our experience has been that development on it is slow relative to the tool we use (see below). It's saved us a ton of money. I blog on this and similar topics here: http://zwischenzugs.wordpress.com/ http://zwischenzugs.wordpress.com/ The "tool for building and maintaining complex Docker deployments" is here: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ https://github.com/ianmiell/shutit https://github.com/ianmiell/shutit I also talk about this here: https://www.youtube.com/watch?v=zVUPmmUU3yY https://www.youtube.com/watch?v=zVUPmmUU3yY

incision 12y ago
>"They don't even do what they're advertised to do, ie give you a reliable way to reproduce a build, and they're inflexible for my idea of real-world work with Docker." Not exactly, as the thread you link points out you can reference an image ID in FROM rather than the name:tag which has potential to change silently. It's the equivalent of using a package manager against a repo you don't own without pinning - expect problems. This can be mitigated by FROM'ing via ID or avoided entirely by running your registry where tags are reliable. Admittedly, these things are not necessarily obvious, but I think it's a bit disingenuous to paint Dockerfiles as worthless or broken. That said, ShutIt looks very cool and seems to address exactly some of my concerns / desires about working with Docker. I just don't agree with framing it in opposition to and at the expense of what exists. There's value in a container description that is fully self-contained, transferable and 'dumb' enough to be transparent.
- zwischenzug 12y ago
  Hi, yes you're right - you can reference an image ID. However, as soon as you go to the network you're lost - any apt-get/yum update or install could break your system in surprising ways. Having done _lots_ of builds lately I can vouch for that (see my blog for some examples). In the end the image ID _is_ useful, but the dockerfile itself has limitations. I agree with your last point as well - my evangelism comes from solving problems at my company in this way (which I know are not uncommon problems) rather than any belief that it beats others objectively.