21–30 of 70 posts
I would suggest the only truly whitebox images are the ones that can be recreated from github (or similar) repositories.
This gave me an (probably non-novel) idea: "double-layered" Docker image creation. One thing that rubs me the wrong way is how Docker images contain stuff like apt (and all the related supporting stuff) when they don't really need them (at runtime). On the other hand you need to install/compile/setup the environment somewhere, and relying on the host system would break any hopes of reproducibility. To reconcile these…
This must be a bug? Why should it legitimately behave this way?
"Thus it seems that if you leave a file on disk between steps in your Dockerfile, the space will not be reclaimed when you delete the file." This must be a bug? Why should it legitimately behave this way?
"Thus it seems that if you leave a file on disk between steps in your Dockerfile, the space will not be reclaimed when you delete the file." This must be a bug? Why should it legitimately behave this way?
i wanted to use public docker images and spin on it AWS and quickly use a sanity check/vet the app if it can be something I want to use internally or recommend for customers.
Realized there is nothing of such sort and started xdocker.io -- open source initiative.
Currently we support security monkey and ice (both from netflix).
Just love docker and learning quite a bit of tricks along the way.
This article just helps us to do our job better by following the best practices to build docker images.
I would also appreciate if experts on this can help us screen the docker files we have created and share the feedback with us. https://github.com/XDocker/Dockerfiles.
This will remove the .debs apt just downloaded and installed that are being cached in /var/cache/apt/archives, saving you a little disk space.
Google takes this a step further and creates single binary containers with the minimal OS bits needed [1, 2]. Personally, I think this is where we need to be headed vs running a full blown ubuntu/debian/centos OS inside the container. Three benefits, 1) no OS to manage eg. no apt-get update or configuration management, 2) container has less of an attack surface (think shellshock -- the container does not have bash, w…
Interesting this approach of building single binary containers. I think that would be like packr [1] for Java, already discussed here [2]. I wonder if there is something like this for other languages/platforms like python/ruby/node. [1] https://github.com/libgdx/packr [2] https://news.ycombinator.com/item?id=7696564
"Pin package versions" -- yes. One of the things that has been bugging me about Docker is that if you begin every Dockerfile with an `apt-get -y update`, you never know what you're going to end up with. On the other hand, pinning every package that you install would end up being pretty verbose.
I see a few reasons to build your own from the Dockerfile:
- 1) You don't trust the image and want to build your own.
- 2) You want to build something slightly different
- 3) You want an up-to-date version.
Something the article doesn't touch on in its pursuit of a smaller image - when you run "apt-get install" or "apt-get upgrade" you should do "&& apt-get clean" in the same RUN command. This will remove the .debs apt just downloaded and installed that are being cached in /var/cache/apt/archives, saving you a little disk space.
On one hand, I consider this a good default behavior for building docker containers, so I'm glad it's there. On the other hand, I didn't know about it until I investigated. It's strong evidence for the great point @amouat made regarding base images being blackboxes in most (all?) cases.