It's creating the VirtualBox of Linux Containers. Docker image files are extremely light weight when compared to VirtualBox images and use Union File systems to allow for complete isolation rather than using VM volumes.
An example scenario for when you'd want something like this is if you want to load an experimental library for a specific application that some part of your system depends on the stability of. Fire up a docker image for just that application with the experimental library replacing the stable library and just the applications inside the docker image will see it. No need to even play around with library versions or links. And since the Docker images are so light weight and incur extremely little performance penalty (I think it is limited to just the cost of using the Union FS over your normal FS), you can do this for dozens of scenarios at once.
Eventually, there may be some way to merge images together, though I imagine that will always be a little harry compared to a simple stack up.
Documentation is more than a little sparse right now, unfortunately. It took me a few days to figure out how all the pieces work together.
lxc is a tool for sysadmins to deploy and configure virtual servers on their machines.
docker is a tool for developers to package their application into a deployable object without worrying about how the sysadmin will deploy it, and for sysadmins to deploy applications without worrying about how they were packaged.
When you tinker long enough with lxc, eventually you start building something like docker on top of it, because it just makes sense. Now instead of reinventing the wheel you can just use docker.
No no no. Do NOT do this. Kids these days...
Gtk+, the widget toolkit used to develop GNOME and many free software applications, supports rendering applications via HTML5. One of the developers has demonstrated using it to run desktop applications on OpenShift, Red Hat's PaaS, that you then access via your web browser.
http://blogs.gnome.org/alexl/2013/03/19/broadway-on-openshif...
http://blogs.gnome.org/alexl/2013/04/03/more-gtk-in-the-clou...
The idea behind NX is to "fake" an X client on the server side and fake a NX server on the client side. This reduces the number of roundtrips required for each action. The improved responsiveness is dramatic -- even on a low speed and high-latency link, using the remote desktop feels like a local machine...
http://en.wikipedia.org/wiki/NX_technology
http://freenx.berlios.de/
http://code.google.com/p/neatx/source/list
Is there any open-source equivalent to things like Citrix's XenApp, VMWare's ThinApp, Microsoft's App-V, or independent tools like Sandboxie? http://alternativeto.net/software/sandboxie/
how is this any better than simply running virtualbox on your OS to begin with?
http://stackoverflow.com/questions/16296753/can-you-run-gui-...
Edit: Ironically Docker itself has the potential to help solve the problem of running untrusted open source code. I think every open source project should include either a Dockerfile or Vagrantfile to help users get up and running quickly, and safely run untrusted projects.
For example, I would notice that it requires apt-get
echo "Ensuring basic dependencies are installed..."
apt-get -qq update
apt-get -qq install lxc wget bsdtar
How is this different, other than a graphical installer being completely unauditable, whereas curl|sh is quite trivially auditable? Both run code as root.
But the URL should be HTTPS.
Of course, don't do this on your most beloved production machine, if you can package it properly, test it, etc
But rendering a font gives execution with your user, so don't be so afraid of a installer "you can read" and has an interesting purpose.
Would you point us to a reference, or a further explanation for this claim ? I am genuinely interested...
The usability of the curl pipe approach is here to stay, so the least we can do is help people be safe with it.
Anyone have other ideas for making curl pipes safer?
Food for thought: http://www.cs.dartmouth.edu/~sergey/langsec/
p.s. I know, that there should not be direct copy-paste from browser to console and this method leaves a file in /tmp on installation failure
I don't think this is true. It's just going to take a very popular project getting their DNS hijacked before everyone wakes up.
Well, you are right about the usability part. That part is amazing. It's just that curl-pipe is not the answer.
Ideally it would download a file from Github too, that way you can be sure it's coming straight from the publicly visible open source repo, and you can audit if you want.
But I think the general outrage over this technique is overblown.
As an aside, I miss some of the raw diversity that was present in the old Linux distros. Slackware was my drug of choice due to its steadfastly BSD flavor. I guess Slackware is still around, but have no idea what its status is and whether Patrick ever moved it over to system v-ish convention in order to be more like other Linux distros. I guess that distinction is even a bit anachronistic given all the fancy changes to the way init is done nowadays.
in a jail, one user who attempts to monopolize disk io will succeed. in a cgroup, he can be restricted to exactly 10% of available i/o bandwidth, so you can guarantee that he doesn't starve the other containers.
there are also easy and documented ways to break out of a chroot if you are able to obtain root in the chroot. those holes are plugged by lxc and docker. Most notably, access to devices can be restricted.
I don't know what you mean by "carry fat binaries and a kernel for chrooting an environment" -- you don't need a separate kernel for chroot, any more than you need a separate kernel for docker. There's no advantage to static linked binaries (fat binaries?) when you can put the storage of your containers in a zpool or btrfs with deduplification. Same as your chroots.
Try out docker. Read about cgroups. I first gave LXC a try a few years ago and I was really sad about the extent of support for creating guests and keeping them properly isolated. It was really not friendly at all. You basically had to commit to using kernel patches that made your system pretty unusable as a desktop. (Was that xen dom0 or lxc?)
Everyone was saying, "Ohh, LXC is no better than a chroot." It's insecure, easy to break yourself out. Not so much anymore, with the current state of Docker you don't even have to know all the advances in cgroup and namespaces.
It's worth a look. Really, go check it out.
One key thing is, that it makes sense to run containers without root privileges (greatly improving security), while it is much harder to realistically run a VM without root processes. As a result, it could be said that containers are much safer, because before even thinking about breaking out of the container, you have to work on a root exploit - on a system which, by essence, only runs the processes that you really need, and has a much smaller attack surface.
We're working on a more elaborated answer, to be included within Docker docs!
Seriously, Docker is perfect for creating a sandbox with all dependencies to help new users get up and running quickly and safely. Every project should come with a Dockerfile and/or Vagrantfile.
Hm, the only problem is installing Docker in the first place ...
I don't know much about docker, but doing a "curl | sh" peeks my interest, then downloading additional binaries into /usr/local/bin, I'd want to take a closer look. Obviously, this is a case by case review, till it sits well with me. If I was going to run this in production, I'd want to have a really good idea of what this was doing and what to expect, so I'd probably take a closer look at the source if it was not clear from the documentation.
This can go on pretty far - trust is always an eventually unsolvable issue.
There is a certain level of trust that is easy to achieve and easy to get. Trusting dotcloud is easier than trusting everyone on the internet is pink bunny. Happens to be that HTTPS and signing aren't exactly hard either ;-)
You either have to trust Docker (a fairly well known project built by reputable people) isn't going to root your machine, or download the source yourself and audit it.
This is no worse than suggesting you "git clone whatever; cd whatever; make" (aside from the lack of SSL)
...and everybody else on my network, with that method. Doing that I don't even get the chance to think "Hey wait a second, why was this only 50 bytes of shell script...".
The reason that you see outrage for this "method" is because it is born of laziness and far too reminiscent of more disturbing times in computer security.
Why do we need an instruction on downloading the source to begin with? It really just promotes bad habits with those who know no better, i.e. new/inexperienced developers. The problem is when people see instructions like that on 20% of the guides they read in earnest, trusting that everything is OK if enough people say it. One hopes they stumble upon a discussion like this so that they can consider the consequences but that just isn't going to happen to everyone. True, one should exercise equal caution while cloning, gem-ing[1], etc. It would be great if authors would just link to the source and paste the relevant lines from the README if necessary.
[1] http://andre.arko.net/2013/03/29/rubygems-openssl-and-you/
That is all.