5 ms·

Dockerfiles are not a replacement for chef or puppet scripts. They're a very lightweight way to assemble a container by running unix commands, and then freezing

by shykes 13y ago

Dockerfiles are not a replacement for chef or puppet scripts. They're a very lightweight way to assemble a container by running unix commands, and then freezing that container into an immutable, portable unit of deployment. Some of thos unix commands may be calls to Chef. If you're a chef user, you can use docker to "just-in-time" compile your chef recipes into a container almost as portable as a static binary. You can then send that container to me, and I'll be able to run it regardless of what configuration management I like to use on my machine.

chrisfarms 13y ago
Cool, makes sense thanks.
bryanlarsen 13y ago
It seems to me that you should be able to roll back an built via a Dockerfile back to any step in the build, and then rebuild from that point. A deployment via another CM tool would probably lose that ability. Perhaps it's my inexperience, but I find chef scripts to be very fragile because of the large amount of external dependencies they generally contain. All of these dependencies are very stable: nobody takes down tarballs and packages randomly, but a large number of low probability events can add up to a high probability. That makes image based deployments appealing, but you still need to have a reliable, repeatable capture of the steps that went into building the image...
- jacquesc 13y ago
  I've used Chef extensively and found this to be exactly the case. In my experience, going back and running deploy scripts I wrote a year ago have about 10% probability of still working. Aside from chef's breaking changes (and versioning mess), there's a ton of things outside of my control that take things down. Debugging has been a nightmare. I love the concepts and community around Chef, but I've found for my use case, it was an all around bad choice.
wiremine 13y ago
I think the confusion is the difference between a box and a container: I grok that I would use a dockerfile to configure a container, and I would use chef/puppet to configure a box. But, _why_ can't I use chef/puppet to configure a container? Why is a dockerfile (in concept or syntax) _better_ than chef/puppet?
- shykes 13y ago
  I think the fundamental difference is that a container is built from the _outside_ (the way you would build an executable), whereas a box is configured from the _inside_ (the way you configure a physical computer). Docker is designed for the former, and Chef is designed for the latter. What causes the confusion, I think, is Docker's premise that the best executable format for software is a virtual computer encapsulating all of the program's dependencies. Because of this, the software you're running starts looking a lot like the computer it's running on - because they're both computers! It's just computers running on computers running on computers, or as Alan Kay liked to say it, "Real Computers All The Way Down" [1]. I believe things are bound to get more confusing for a while, but the result I believe will be one of computing's most exciting development. [1] http://www.computerworld.com.au/article/352182/z_programming_languages_smalltalk-80/?pp=2 http://www.computerworld.com.au/article/352182/z_programming...
StavrosK 13y ago
> then freezing that container into an immutable, portable unit of deployment. Doesn't doing that make a git repo of all the files currently in the container? Wouldn't it take ages to upload this to your machine, versus just uploading a dockerfile and having it rebuild the image from scratch? I get that Docker containers are sort-of VMs, but I don't really understand the freeezing functionality at the moment... It seems to me that you'd have to freeze the entire binary image, whereas an ansible script/Docker build file would be much more portable and result in the same thing.
- bryanlarsen 13y ago
  AFAICT, Docker can easily give you the diff between the base image and your built image, which should be small and portable.
  - StavrosK 13y ago
    Ah, errnoh on IRC also explained some things to me, it seems that Docker reuses "parent" images, so if you launch 10 Ubuntu containers they will only take up 10x20mb plus the parent image of 600 mb, rather than 10x600, hence the freezing. That's amazing, it means that I can replace my small VMs with Docker containers on a big box.

by shykes 13y ago

chrisfarms 13y ago

Cool, makes sense thanks.

bryanlarsen 13y ago

It seems to me that you should be able to roll back an built via a Dockerfile back to any step in the build, and then rebuild from that point. A deployment via another CM tool would probably lose that ability. Perhaps it's my inexperience, but I find chef scripts to be very fragile because of the large amount of external dependencies they generally contain. All of these dependencies are very stable: nobody takes down tarballs and packages randomly, but a large number of low probability events can add up to a high probability. That makes image based deployments appealing, but you still need to have a reliable, repeatable capture of the steps that went into building the image...

jacquesc 13y ago
I've used Chef extensively and found this to be exactly the case. In my experience, going back and running deploy scripts I wrote a year ago have about 10% probability of still working. Aside from chef's breaking changes (and versioning mess), there's a ton of things outside of my control that take things down. Debugging has been a nightmare. I love the concepts and community around Chef, but I've found for my use case, it was an all around bad choice.

wiremine 13y ago

I think the confusion is the difference between a box and a container: I grok that I would use a dockerfile to configure a container, and I would use chef/puppet to configure a box. But, _why_ can't I use chef/puppet to configure a container? Why is a dockerfile (in concept or syntax) _better_ than chef/puppet?

shykes 13y ago
I think the fundamental difference is that a container is built from the _outside_ (the way you would build an executable), whereas a box is configured from the _inside_ (the way you configure a physical computer). Docker is designed for the former, and Chef is designed for the latter. What causes the confusion, I think, is Docker's premise that the best executable format for software is a virtual computer encapsulating all of the program's dependencies. Because of this, the software you're running starts looking a lot like the computer it's running on - because they're both computers! It's just computers running on computers running on computers, or as Alan Kay liked to say it, "Real Computers All The Way Down" [1]. I believe things are bound to get more confusing for a while, but the result I believe will be one of computing's most exciting development. [1] http://www.computerworld.com.au/article/352182/z_programming_languages_smalltalk-80/?pp=2 http://www.computerworld.com.au/article/352182/z_programming...

StavrosK 13y ago

> then freezing that container into an immutable, portable unit of deployment. Doesn't doing that make a git repo of all the files currently in the container? Wouldn't it take ages to upload this to your machine, versus just uploading a dockerfile and having it rebuild the image from scratch? I get that Docker containers are sort-of VMs, but I don't really understand the freeezing functionality at the moment... It seems to me that you'd have to freeze the entire binary image, whereas an ansible script/Docker build file would be much more portable and result in the same thing.

bryanlarsen 13y ago
AFAICT, Docker can easily give you the diff between the base image and your built image, which should be small and portable.
- StavrosK 13y ago
  Ah, errnoh on IRC also explained some things to me, it seems that Docker reuses "parent" images, so if you launch 10 Ubuntu containers they will only take up 10x20mb plus the parent image of 600 mb, rather than 10x600, hence the freezing. That's amazing, it means that I can replace my small VMs with Docker containers on a big box.