This includes critical security updates for boot2docker to resolve a RCE vulnerability. Docker itself containers a lower priority security update. Users, especially those of boot2docker, are highly encouraged to upgrade.
For those wanting to avoid upgrading to a new boot2docker release you can patch the vulnerability with the following command from the boot2docker shell:
sudo sed -i "s/DOCKER_TLS:=''/DOCKER_TLS:=auto/g" /etc/init.d/docker && sudo /etc/init.d/docker restart
This will enable TLS by default and restart the docker daemon. Note that this will also kill all of your running containers.
> our recommended approach of “one app per container.” Instead, we’re responding to users who’ve told us they sometimes need helper processes
Isn't it quite normal for an "app" to consist of multiple processes? Maybe a web server, app server, database system, message queue, object store, cron jobs and the like.
Yes, but often you are better off isolating these processes from each other, and only allow communication over the network.
Most of the time these processes only need the network to communicate with each other. When there is a legitimate reason for processes to share the same filesystem, process namespace or network address (for example for debugging), that's when `docker exec` becomes helpful.
Sure, if I was designing a production grade system I probably would isolate a lot of the services.
But I thought the whole idea of Docker was I could download something like a "Wordpress image" from the Docker marketplace, and it would just work in a self-contained way. Unless there is some higher level tool to download multiple Docker images for different apps and configure them together to provide a service of some kind.
You're right, ideally you could get the best of both worlds: 1) multi-container stack that mimics the production setting, and 2) something you can 'docker pull' and 'docker run' as a single unit.
For now you need 3d-party tools to define their own multi-container constructs, like Fig or Kubernetes. Eventually Docker needs to implement a multi-container construct of its own, to avoid fragmentation (interoperable containers are not as useful if they're bundled in non-interoperable wrappers). Luckily, the authors of Fig work at Docker and we're working closely with the authors of Kubernetes. So if you use either of those tools, you will probably be familiar with the native Docker version :)
I personally believe this is somewhere something like fig comes into play nicely. You can still have the isolated services, but with super simple setup: download the fig.yml and run fig up.
It seems like phrasing it as "one service per container" (with service being in the SOA sense), might be better.
Certainly, I think of an SOA app being composed of multiple services, and I'm pretty sure the thing you're suggesting that the thing you want one of in the container is what I'm calling a service.
It's not that a container can't run multiple processes, but Docker will itself only start one process.
If you use, for instance, Apache with the forking MPM, this will work as expected (it'll work).
If you want to start multiple separate processes, then you'll need to use some sort of init system. This is not really any different than Linux itself.
I can already see that `docker exec` and `docker create` will allow me to get rid of a number of admin and configurator containers.
When I started playing around with boot2docker, I was gagging for the ability to share directories with OS X. However, it turns out that I didn't really need that once I realised that caching means that building images is very fast.
Yeah, build caching makes it much more practical to rebuild in many cases. But there are still some workflows where even waiting a few seconds is too long - most commonly when you're writing frontend code and want to just refresh the browser every time you edit a line of css.
As far as I can tell, the current implementation of signed images hardcodes the Docker, Inc cert-- effectively locking in users to only Docker, Inc's trusted images.
Ideally docker users could sign their own images and provide their own keys to do signature validations. What is the timeline on this work? With out this, "digitally signed images" means "locked into Docker, Inc- otherwise no security", and is very misleading.
A very basic implementation would be to read certs out of a directory on the filesystem and is how all other package managers handle this.
Edit: I missed the part in the post that even if the signature fails, the container still runs. The signatures do nothing. Got it. Preview.
Absolutely, the full implementation will allow each user to sign with their own keys, and provide user-configurable trust rules ("allow images only signed by this key"). The Docker CA will be used as a default convenience to provide a common namespace if you want it, but users who want to use their own custom PKI will have all the flags to do that, and there will be an "escape hatch" to opt out of the entire trust infrastructure altogether.
The only reason we're starting with verification-only, and only for images produced by the official library maintainers, is because the other side of the tools (signing) are not yet ready to be merged in Docker. By releasing a subset now, we can start getting some feedback and ironing out the quirks, while the contributors finish their work on the signing tools, using the library maintainers as guinea pigs. Hope this helps.
PS. to state the obvious, all of this is taking place in the open on #docker-dev in Freenode. It is being designed by key contributors from multiple companies, and you are welcome to join the fun.
User namespaces will come. Patches are in progress and you can refer to github for the status of that effort.
I'd hesitate before calling it a "security problem" with Docker. It's a highly-requested security feature. The absence of it makes containers less secure, but does not make them vulnerable. There are use-cases for Docker without user namespaces, but user namespaces will make Docker better and will make containers more secure.
We do distinguish between the security of the Docker engine and the pieces of our ecosystem and the security of containers themselves. We seek to improve both.
Vulnerabilities such as the one fixed today in boot2docker 1.3 whereby either web browsers or containers may control the Docker daemon and perform remote code execution are serious issues in Docker itself and/or its ecosystem of products. Resolving such vulnerabilities is not, for me, less important than adding user namespaces.
I'm guessing that would be a second dot release (1.3.1) monthly. If you look at the github milestones, it appears a dot release is scheduled for every 3 months. https://github.com/docker/docker/milestones
"One release per month. Every first week of the month, we release a new version of Docker. For example, in the first week of March we will release 0.9."
Thank you. We will be updating the blog to support higher versions of TLS as well as to evaluate its cipher suite. It has taken longer than it should, and for that we apologize. It has not been forgotten or abandoned and will be resolved as promptly as possible.
Our other sites, including the Docker website and the Docker Hub already have relatively aggressive cipher suites and have disabled SSLv3, protecting it from POODLE.
Actually, maybe I'm not on 1.3... I did do a "boot2docker upgrade", but when I do "boot2docker version", I'm still getting 1.2.0:
(py)cmbpr:~ caleb$ boot2docker upgrade
Downloading boot2docker ISO image...
Latest release is v1.3.0
Success: downloaded https://github.com/boot2docker/boot2docker/releases/download...
to /Users/caleb/.boot2docker/boot2docker.iso
Waiting for VM and Docker daemon to start...
..............................
Started.
Writing /Users/caleb/.docker/boot2docker-vm/ca.pem:
Writing /Users/caleb/.docker/boot2docker-vm/cert.pem:
Writing /Users/caleb/.docker/boot2docker-vm/key.pem:
To connect the Docker client to the Docker daemon, please set:
export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/caleb/.docker/boot2docker-vm
hope 1.3 will be soon in the homebrew, we're migrating tomorrow to docker and all of our office is OSX. that is regarding new standard folder sharing feature.
Your entire office is OS X and you're migrating to a Linux-only non-portable technology stack that requires a VM to run on your desktop?
Is this really cheaper and more effective than cleaning up your code base so that it doesn't require complete ownership of the host environment in order to run?
Why assume that they are using Docker because they have a portability problem?
They probably like OS X as a workstation OS, and want to use Docker for the DevOps benefits that they gain from it. boot2docker is just a lightweight solution for running Docker locally.
...maybe I'm confused... Is your premise that they will only run their application/service internally?
Normally what I've seen is, develop on OSX and then push to Heroku (Linux) / <infrastructure provider of choice, running a Linux VM>. Why then wouldn't the natural progression be, develop in boot2docker and push to <docker PASS of preference>?
But almost always the module or service that you work on relies on other services and datastores. boot2docker can help you pull down an entire stack to your workstation and not rely on connecting to an external network. You can essentially work on Airplane mode.
Or, you can architect your module/service to run the things it depends on in a self-contained manner and avoid creating a hard dependency on virtualization of Linux.
https://groups.google.com/forum/#!topic/docker-announce/aQoV...