Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker 0.7 runs on all Linux distributions

blog.docker.io

Post reply on HN
Print view View original

91–100 of 131 posts

Re: Docker 0.7 runs on all Linux distributions

#91

Post by idupree »

shykes wrote: post #52
shykes wrote: post #44

Earlier quoted context omitted.

Documentation is definitely part of the process :) Apparently the documentation service triggered an incorrect build overnight. Until we fix that you can browse the latest version of the docs from the master branch: http://docs.docker.io/en/master

Quick update: until we figure out what broke the build on our ReadTheDocs.org setup, we switched the default branch to master. So if you visit http://docs.docker.io you will get the bleeding edge build of the documentation, which happens to be accurate since we released it this morning :) Sorry about that. One more lesson learned on our quest to ultimate quality!

The Arch Linux instructions are still wrong; they say that aufs3 is required but it isn't anymore. http://docs.docker.io/en/master/installation/archlinux/

Is the warning "This is a community contributed installation path. The only ‘official’ installation is using the Ubuntu installation path. This version may be out of date because it depends on some binaries to be updated and published." still true? Fedora also has this warning (and no instructions). The "Look for your favorite distro in our installation docs!" link does not give me up-to-date instructions for any of my favorite Linux distros. I can't even see where in that installation documentation it says how to install from source code on generic Linux. What am I missing? (Of course I can get the source code and build it, but I want the documentation to be great :-D)

Re: Docker 0.7 runs on all Linux distributions

#92

Post by throwaway092834 »

shykes wrote: post #88
throwaway092834 wrote: post #86

Earlier quoted context omitted.

Yes, it is trivial for a root user in an LXC container to break out. One can load a kernel module from within a container, for example. LXC containers do not provide security partitioning at all.

This is just totally wrong. Any decent container configuration (including the default docker configuration) will agressively drop capabilities, preventing you from doing this, and any other script-kiddie attack. See my other comment in this thread for a more accurate answer.

Not wrong at all. He asked about LXC. Privilege restrictions are not part of LXC.

Re: Docker 0.7 runs on all Linux distributions

#93

Post by Legion »

Could someone explain the logistics of Docker in a distributed app development scenario? I feel like I am on the outskirts of understanding.

My goal is having a team of developers use Docker to have their local development environments match the production environment. The production environment should use the same Docker magic to define its environment.

Is the idea that developers define their Docker environment in the Dockerfile, and then on app deployment, the production environment builds its world from the same Dockerfile? How does docker push/pull of images factor into that, if at all?

Or is the idea that developers push a container, which contains the app code, up to production?

What happens when a developer makes changes to his/her environment from the shell rather than scripted in the Dockerfile?

What about dealing with differences in configuration between production and dev? (Eg. developers need a PostgreSQL server to develop, but on production, the Postgres host is separate from the app server - ideally running PG in a Docker container, but the point being multiple apps share a PG server rather than each running their own individual PG instance). Is the idea that in local dev, the app server and PG are in two separate Docker containers, and then in deployment, that separation allows for the segmentation of app server and PG instance?

I see the puzzle pieces but I am not quite fitting them together into a cohesive understanding. Or possibly I am misunderstanding entirely.

Re: Docker 0.7 runs on all Linux distributions

#94

Post by jeffheard »

This is crazy talk of course, but I wonder if there'd be some way to use rsync or git to support distributed development of images the way git does with code?

I mean, it'd be neat to be able to do a "pull" of diffs from one image into another related image. Merge branches and so on. I don't know, possibly this would be just too unreliable, but I would have previously thought that what docker is doing right now would be too unreliable for production use, and lo and behold we have it and it's awesome.

Re: Docker 0.7 runs on all Linux distributions

#95

Post by shykes »

yebyen wrote: post #84
dmunoz wrote: post #80

Earlier quoted context omitted.

Yes, my goal here is ease of playing around with something new. I would setup a dockerfile after I knew exactly what setup I wanted. You're right, I misunderstood what docker was doing when shutting down the container. Seems like I can start and reattach just fine. Here is an example workflow for anyone curious: root@chris-VM:~# docker run -i -t ubuntu /bin/bash root@0a8f96822140:/# cd /root root@0a8f96822140:/root#…

Yes, I wrote a long wordy response and neglected to mention "docker start" which is a perfectly good way to come back to a stopped container after the first "docker run". I prefer to never keep anything important in a stopped container (for very long) without committing it back to an image, and I don't like dealing with numeric ids. Recently (it looks like you don't have this change yet) docker added the automatic na…

You can assign permanent names to containers. We're designing the naming syatem to make it completely OK to keep persistent containers. They're just named directories, docker will never remove them on its own.

For example a common pattern is to create a placeholder database container with reference dara as a volume, but no actual process running and no network ports. Then successive versions of the database container are started on the side, with shared access to the placeholder's volume. Later you might run a backup container on the same volume. In other words you can point to a particular dataset as a container of its own, separate of the various applications which might access it. All of these interactions are visible to docker so it can authenticate, restrict, log, or hook them in all the standard ways.

In fact internally images and containers are stored side-by-side. In future versions we are going to accentuate that similarity.

Re: Docker 0.7 runs on all Linux distributions

#96

Post by deserted »

andyl wrote: post #6
shykes wrote: post #2

A few details on the "standard linux support" part. To remove the hard dependency on the AUFS patches, we moved it to an optional storage driver, and shipped a second driver which uses thin LVM snapshots (via libdevmapper) for copy-on-write. The big advantage of devicemapper/lvm, of course, is that it's part of the mainline kernel. If your system supports AUFS, Docker will continue to use the AUFS driver. Otherwise i…

does this mean that docker will run on 32 bit systems ?

Docker already runs fine on 32 bit systems if you compile it yourself and remove the check for 64-bit-ness.

Re: Docker 0.7 runs on all Linux distributions

#97

Post by andyl »

deserted wrote: post #96
andyl wrote: post #6

Earlier quoted context omitted.

does this mean that docker will run on 32 bit systems ?

Docker already runs fine on 32 bit systems if you compile it yourself and remove the check for 64-bit-ness.

Didn't know that - I'll try it!

What happens if you put a 64bit executable in a container they try to run the container on a 32bit machine? Or a Rasberry/Arm device?

Re: Docker 0.7 runs on all Linux distributions

#98

Post by cschmidt »

Legion wrote: post #93

Could someone explain the logistics of Docker in a distributed app development scenario? I feel like I am on the outskirts of understanding. My goal is having a team of developers use Docker to have their local development environments match the production environment. The production environment should use the same Docker magic to define its environment. Is the idea that developers define their Docker environment in…

Since no one has answered you, I'll take a stab. I haven't actually used Docker yet, but I've been lurking extensively. Hopefully someone will correct me if I get this wrong.

A developer will use a Dockerfile to build the main dependencies that you need, and then save an image. Then to deploy code (or other frequently changing data), you pull that base image, add or update whatever else is needed, and save it again. (You can add layers to an image as often as desired.)

Then this saved image is pushed into a production environment. It seems like configuration data is often saved in images, so they require zero configuration. However, you can pass as many command line parameters as desired to run the image in production, so you can keep your configuration separated (like http://12factor.net/config) if you want.

Re: Docker 0.7 runs on all Linux distributions

#100

Post by nl »

shykes wrote: post #48
knitatoms wrote: post #24

Earlier quoted context omitted.

Any drawbacks to using lvm comapared to AUFS? I'd like to switch to Debian from Ubuntu - will I notice any performance differences or other restrictions?

There is a slight performance overhead with lvm, but nothing dramatic. The other advantage of the AUFS driver is that it is more proven. If you have a way to get aufs on your system (and I believe debian does), my pragmatic ops advice would be to use that and give the other drivers some time to get hardened. Of course my advice as a maintainer is that all of them are equally awesome :)

LVM would use more disk space, wouldn't it?
Post reply on HN