4 ms·

Very good call out. For most use cases this actually turns out to be OK, but to reduce the surface area of this being a potential issue you could: - Vendor de

Very good call out. For most use cases this actually turns out to be OK, but to reduce the surface area of this being a potential issue you could: - Vendor dependencies (works to replace stuff like `go get` but probably not for apt packages etc.) - Create a base image which handles the stuff you need to reach out to the network for (`apt-get install openjdk-6-jre` etc.) and is infrequently updated. Then the Dockerfile for the final application is `FROM me/myjava` and just does a few things that don't use the network like `ADD . /code`. - Use `docker commit` instead of Dockerfiles for those steps (pretty gross IMO) - Use CM in your docker build to install a very specific version of a package if you need (I'm not 100% sure this exists but it seems probable). This isn't perfect but tightens things up if you're worried about upstream breaking apt packages etc. One of the goals of a new image format for Docker (this is 2.0 stuff) is to make the layers content-addressable by ID. That way, you will have a reasonable assurance that two Docker images constructed with the same Dockerfile in two different places will have the same IDs if they result in the exact same layers, and you will be able to see the point of divergence otherwise.

zwischenzug 12y ago
"- Create a base image which handles the stuff you need to reach out to the network for (`apt-get install openjdk-6-jre` etc.) and is infrequently updated. Then the Dockerfile for the final application is `FROM me/myjava` and just does a few things that don't use the network like `ADD . /code`. - Use `docker commit` instead of Dockerfiles for those steps (pretty gross IMO) - Use CM in your docker build to install a very specific version of a package if you need (I'm not 100% sure this exists but it seems probable). This isn't perfect but tightens things up if you're worried about upstream breaking apt packages etc." These are some of the goals of ShutIt. We had complex development needs due to technical debt, and dockerfiles simply didn't cut it, and I got frustrated with the indirection of chef/puppet/ansible. I also needed the several hundred devs in my company to get productive quickly, so transferring all the little bash scripts and storing it in docker was the path of least resistance. It's out of date and heavily edited, but I talk about this here: http://www.youtube.com/ianmiell http://www.youtube.com/ianmiell and here: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ and on my blog: http://zwischenzugs.wordpress.com/ http://zwischenzugs.wordpress.com/

zwischenzug 12y ago

"- Create a base image which handles the stuff you need to reach out to the network for (`apt-get install openjdk-6-jre` etc.) and is infrequently updated. Then the Dockerfile for the final application is `FROM me/myjava` and just does a few things that don't use the network like `ADD . /code`. - Use `docker commit` instead of Dockerfiles for those steps (pretty gross IMO) - Use CM in your docker build to install a very specific version of a package if you need (I'm not 100% sure this exists but it seems probable). This isn't perfect but tightens things up if you're worried about upstream breaking apt packages etc." These are some of the goals of ShutIt. We had complex development needs due to technical debt, and dockerfiles simply didn't cut it, and I got frustrated with the indirection of chef/puppet/ansible. I also needed the several hundred devs in my company to get productive quickly, so transferring all the little bash scripts and storing it in docker was the path of least resistance. It's out of date and heavily edited, but I talk about this here: http://www.youtube.com/ianmiell http://www.youtube.com/ianmiell and here: http://ianmiell.github.io/shutit/ http://ianmiell.github.io/shutit/ and on my blog: http://zwischenzugs.wordpress.com/ http://zwischenzugs.wordpress.com/