EL6 users (RHEL, CentOS, SL), I've just learned Docker is now in EPEL (testing for now, but will hit release soon): yum --enablerepo=epel-testing install docker-io PS: make sure you have "cgconfig" service running
Thanks for paying it forward :)
Docker 0.7 runs on all Linux distributions
71–80 of 131 posts
Re: Docker 0.7 runs on all Linux distributions
#72Does anyone know if it is possible to set a disk quota on a container?
FWICT, storage limits are still not directly supported.
You can however create a user per container and limit that user's quota.
This is the relevant user comment (but the full discussion is insightful): https://github.com/dotcloud/docker/issues/471#issuecomment-2...
Re: Docker 0.7 runs on all Linux distributions
#73Hey, docker newb here. Can I easily put my own software in it? I've got this c++ program that has a few dependencies in ubuntu.
I couldn't reply to your deeper comment so I'm going to do it here. You can use the Dockerfile to copy files from you local system onto the image and then run various commands on the image. You have access to a full linux environment inside the docker image so you can do anything on the image that you can do in your normal development environment.
> I couldn't reply to your deeper comment so I'm going to do it here. You can use the Dockerfile to copy files from you local system onto the image and then run various commands on the image.
I wonder if this would be good for (large) embedded systems. Thanks for the tip.
Re: Docker 0.7 runs on all Linux distributions
#74I see docker come around every now and then here. I'm a smalltime developer shop, small team, small webspps. What can docker do for me? Can this reduce the time it takes me to put up and Ubuntu installation on Digital Ocean? Is this more for larger companies ?
Yes, Docker should be able to help you. It is definitely not just for large companies. Docker can help you streamline your development and deployment process across all the machines, from the development laptop to the production server. The result should be that your development environment is easier to setup and replicate, more similar to production, and easier to customize as you evaluate new tools, hosting provide…
Thank you, I will definitely do so.
Re: Docker 0.7 runs on all Linux distributions
#75Earlier quoted context omitted.
The easiest way is to add a Dockerfile to your source repository, and use 'docker build' to create a container image from it. Documentation link: http://docs.docker.io/en/master/use/builder/
Hmm. this is good. but my build environment is kind of wonky. Can I just hand it a .tar.gz and say, put it in /usr/asdf and let it run? What about python scripts? Maybe I just give it a location to an RPM? like in this document? http://docs.docker.io/en/master/examples/python_web_app/
You can use the ADD build instruction in the Dockerfile to upload any part of your source repo into the container. Then more RUN instructions to manipulate that, for example compile the code etc.
Here are 2 examples:
https://github.com/steeve/docker-opencv https://github.com/shykes/docker-znc
Re: Docker 0.7 runs on all Linux distributions
#76Earlier quoted context omitted.
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 :)
how would you compare aufs/lvm performance vs with the upcoming btrfs support? That is the one that I presume will have the most long term continuity because of btrfs becoming the default sooner than later (isnt it already for opensuse/fedora ?)
btrfs will probably compare favorably to lvm.. But it's just an educated guess at this point.
Re: Docker 0.7 runs on all Linux distributions
#77Earlier quoted context omitted.
That depends on the backend a bit i guess. devicemapper "flattens" each layer, so the depth should have zero effect on the performance. For aufs, I have no real data, but I assume that a 42 layer image is somewhat slower than a 1 layer image. The fix for going to > 42 layers is to recreate a full image snapshot (using hard links to share file data) every N layers, so the performance would be somewhere between the per…
Doesn't 'flatten' mean that there's going to be a tradeoff between IO performance and storage size? If that's the case I'd like to have some control over what happens, at least with one of the implementations. Say, during development of a Dockerfile just use the layers as before, potentially without any depth limits, but when an image is ready being able to call 'flatten' manually. Some background: Using 0.65 it took…
"flatten" is a simplification, what I mean is that the devicemapper thin provisioning module uses a data structure on disk that has a complexity that is independent of the snapshot depth. I did not mean that the Docker image itself is somehow flattened.
I don't think there will be any performance problems with deep layering of images, either on dm or ads.
Re: Docker 0.7 runs on all Linux distributions
#78Earlier quoted context omitted.
It's both. Everyone using docker benefits from the "software distribution" feature. Some people using docker also benefit from the security and isolation features - it depends on your needs and the security profile of your application. Because the underlying namespacing features of the kernel are still young, it's recommended to avoid running untrusted code as root inside a container on a shared machine. If you drop…
Which namespacing features are still young? Is it still possible to evade LXC as described in this post? http://blog.bofh.it/debian/id_413
To my knowledge there are currently no known exploits. It's more a matter of risk management: newer codebases are less secure because we had less time to find bugs and spread best practices. That problem is amplified for larger codebases (but diminished by a more active developer community).
Re: Docker 0.7 runs on all Linux distributions
#79Nice to see Docker 0.7 hit with some very useful changes. I see lots of people are getting some generic Docker questions answered in here, and want to ask one I have been wondering about. What is the easiest way to use dockers like I would virtual machines? I want to boot an instance, make some changes e.g. apt-get install or edit config files, shutdown the instance, and have the changes available next time I boot th…
There's no need to manually take snapshots, docker does this automatically every time you run a process inside a container. In your example of running /bin/bash, after you exit bash and return to the host machine docker will give you the id for the container which has your changes. You can restart the container or run a new command inside it and your changes will still be there. If you want to access it more easily later, you can run 'docker commit' which will create an image from the container with a name you can reference. You can also use that new image as a base for other containers.
This is great for development or playing around with something new, but the best practice for creating a reusable image with your custom changes would be to write a Dockerfile which describes the steps necessary to build the image: http://docs.docker.io/en/latest/use/builder/
Re: Docker 0.7 runs on all Linux distributions
#80Nice to see Docker 0.7 hit with some very useful changes. I see lots of people are getting some generic Docker questions answered in here, and want to ask one I have been wondering about. What is the easiest way to use dockers like I would virtual machines? I want to boot an instance, make some changes e.g. apt-get install or edit config files, shutdown the instance, and have the changes available next time I boot th…
There's no need to manually take snapshots, docker does this automatically every time you run a process inside a container. In your example of running /bin/bash, after you exit bash and return to the host machine docker will give you the id for the container which has your changes. You can restart the container or run a new command inside it and your changes will still be there. If you want to access it more easily l…
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# ls
root@0a8f96822140:/root# vim shouldStayHere
bash: vim: command not found
root@0a8f96822140:/root# apt-get install -qq vim
......
Setting up vim (2:7.3.429-2ubuntu2) ...
root@0a8f96822140:/root# vim shouldStayHere
...Not exactly necessary, but I added a line to the file so I could identify it...
root@0a8f96822140:/root# exit
root@chris-VM:~# docker ps
ID IMAGE COMMAND CREATED STATUS PORTS
root@chris-VM:~# docker ps -a
ID IMAGE COMMAND CREATED STATUS PORTS
0a8f96822140 ubuntu:12.04 /bin/bash About a minute ago Exit 0
root@chris-VM:~# docker attach 0a8f96822140
2013/11/26 10:29:41 Impossible to attach to a stopped container, start it first
root@chris-VM:~# docker start 0a8f96822140
0a8f96822140
root@chris-VM:~# docker attach 0a8f96822140
ls
bin boot dev etc home lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var
root@0a8f96822140:/# cd /root
root@0a8f96822140:/root# ls
shouldStayHere
root@0a8f96822140:/root# cat shouldStayHere
Hello World!
root@0a8f96822140:/root#