I've been meaning to try this for a while now but the release of your new Ubuntu repo (as opposed to PPA, details here for other Ubuntu users: http://docs.docker.io/en/latest/installation/ubuntulinux/ ) has convinced me to finally install.
Congrats on the release. Love how fast the docker team is updating.
Ubuntu is going to drop it in the near future. So the idea of rebooting all servers to install a custom kernel with AUFS makes me not even want to try it.
I assume they are dropping it to allow much wider adoption. Docker makes use of AUFS for many of its cool features, like quickly spinning up containers, snapshots, diffs, etc. Ubuntu is dropping AUFS support in its stock kernels [1], and RHEL (CentOS, SL, etc) does not have support for AUFS in their stock kernels [2], and it is a major pain to try and add it (i.e. not even a simple recompile, you need custom patches, etc). So, given these two issues, you run the risk of alienating your user base pretty quickly.
I was talking about why Ubuntu was dropping AUFS, not why docker was. I've been following the UnionFS area in Linux for awhile now and AUFS still seems to be the only viable option.
So I was asking to find out if Ubuntu expects one of the alternatives to be ready soon.
Speaking as a dotCloud employee: yes, it's also our opinion that aufs is still the most viable option in a production setting. Finding a permanent solution to the clusterfuck of union filesystems in linux seems as likely as peace in the middle-east: those with a viable solution are powerless to impose it; those who could change the status quo seem paralyzed by bias, personal feuds or simply having other fish to fry. Meanwhile the rest of the World has thrown their hands up and stopped waiting. Aufs works in production, moving on.
Speaking as a Docker maintainer: we'll add support for whatever our users want most, and makes it easy to run docker everywhere.
btrfs is one of the alternatives we plan on supporting. In fact there is already an experimental branch with btrfs support.
However, wearing my user / operator hat, if I had to choose I would stick to aufs in production. If I had to switch (and the apparently stupid move by ubuntu to drop it might indeed force me to), I would first try to use more proven code, like lvm or raid/dm.
btrfs and overlayfs are neat, promising technology for the future - that place where our production deployments can't go :)
Soon. It's a core use case with a lot of interest around it. There have been experimental branches created to try out other filesystems and no major issues were found. It's a matter of getting the API right, which is what the Docker team and Community are working on together as I type this.
Given the recent thread I'm interested in what the security updates were given that the word security doesn't occur in the changelog. Can someone closer to the source please explain?
> We have tightened Docker’s default access control configuration, to make it more suitable for use on a host machine shared with untrusted applications. Running docker commands now requires either root privileges, or a user account included in the “docker” group.
> This means that after upgrading to 0.6, you will need sudo to run docker commands.
> Don’t worry, you can revert your configuration with the “-H” flag. Just make sure you understand the security implications!
23 comments
[ 3.1 ms ] story [ 62.7 ms ] threadHere's the full release pull request if you're interested: https://github.com/dotcloud/docker/pull/1628
Congrats on the release. Love how fast the docker team is updating.
Out of curiosity, what's your reasoning for preferring a custom repo instead of a PPA?
Ubuntu is going to drop it in the near future. So the idea of rebooting all servers to install a custom kernel with AUFS makes me not even want to try it.
1: http://blog.docker.io/2013/08/getting-to-docker-1-0/
[1] http://ubuntu.5.x6.nabble.com/RFC-AUFS-disabled-for-12-04-td...
[2] https://github.com/dotcloud/docker/issues/172
Speaking as a Docker maintainer: we'll add support for whatever our users want most, and makes it easy to run docker everywhere.
By creating your base image in a subvol or individual file you can then snapshot that and mount the snapshot into the container?
additionally it lets you piggy back on the stuff that inktank and openstack are doing with ceph and btrfs
distributed storage with cow images for VMs for your container servers
However, wearing my user / operator hat, if I had to choose I would stick to aufs in production. If I had to switch (and the apparently stupid move by ubuntu to drop it might indeed force me to), I would first try to use more proven code, like lvm or raid/dm.
btrfs and overlayfs are neat, promising technology for the future - that place where our production deployments can't go :)
What I've found is that the answer/preferred answer to your question is ultimately quite fragmented across organization and application types.
> We have tightened Docker’s default access control configuration, to make it more suitable for use on a host machine shared with untrusted applications. Running docker commands now requires either root privileges, or a user account included in the “docker” group.
> This means that after upgrading to 0.6, you will need sudo to run docker commands.
> Don’t worry, you can revert your configuration with the “-H” flag. Just make sure you understand the security implications!