6 ms·

Docker is a bit overkill; just use what it's built on, Linux containers. `sudo lxc-unshare -s "NETWORK|PID" sudo -u nobody python script.py` will do the trick f

Docker is a bit overkill; just use what it's built on, Linux containers. `sudo lxc-unshare -s "NETWORK|PID" sudo -u nobody python script.py` will do the trick for you. (all one command--the first sudo to make you root, so you can create a new container; the second sudo to make the user inside the container unprivileged) You'll need to communicate with the Python script using IPC.

sitkack 13y ago
Docker is lxc.
- shykes 13y ago
  Docker is not lxc. See http://stackoverflow.com/questions/17989306/what-does-docker-add-to-just-plain-lxc http://stackoverflow.com/questions/17989306/what-does-docker...
  - sitkack 13y ago
    Docker is a clean and thin layer on top of lxc. Not managing lxc instances without it seems like a mistake given portability/reproducability of container management.
    - chrismonsanto 13y ago
      I stand by what I wrote. - Portability: it's just as portable as lxc, so if you meant portability in the sense of 'well he could use it on FreeBSD if he wants to switch from Linux' I don't think there's a win there. If you mean that his containers won't depend on the environment used to spawn them, I guess I don't think that's so important. I always make sure my environments are easily reproducible, and I am happy to reap the reward of that--the reward being that I can do 'unportable' things and not have to worry. Instead of running the environment you want in a container, why not just run it normally and skip that step? - Reproducibility: see last point. If he wants reproducibility, he can shove that one-liner in a script somewhere and call it. All he wants to do is isolate a process. You don't need a chroot for that, or service discovery, or lifecycle managment, or a Dockerfile, or whatever else. It's like if someone advocated the use of a 'grep manager' instead of just running grep. The simplest possible thing to do is unshare the namespaces he wants to isolate from harm. So I suggested exactly that. EDIT: also re portability, it sounds like the rest of his environment depends on these Python scripts anyway, so I don't think he'd gain anything from being able to use them in a different environment.

sitkack 13y ago

Docker is lxc.

shykes 13y ago
Docker is not lxc. See http://stackoverflow.com/questions/17989306/what-does-docker-add-to-just-plain-lxc http://stackoverflow.com/questions/17989306/what-does-docker...
- sitkack 13y ago
  Docker is a clean and thin layer on top of lxc. Not managing lxc instances without it seems like a mistake given portability/reproducability of container management.
  - chrismonsanto 13y ago
    I stand by what I wrote. - Portability: it's just as portable as lxc, so if you meant portability in the sense of 'well he could use it on FreeBSD if he wants to switch from Linux' I don't think there's a win there. If you mean that his containers won't depend on the environment used to spawn them, I guess I don't think that's so important. I always make sure my environments are easily reproducible, and I am happy to reap the reward of that--the reward being that I can do 'unportable' things and not have to worry. Instead of running the environment you want in a container, why not just run it normally and skip that step? - Reproducibility: see last point. If he wants reproducibility, he can shove that one-liner in a script somewhere and call it. All he wants to do is isolate a process. You don't need a chroot for that, or service discovery, or lifecycle managment, or a Dockerfile, or whatever else. It's like if someone advocated the use of a 'grep manager' instead of just running grep. The simplest possible thing to do is unshare the namespaces he wants to isolate from harm. So I suggested exactly that. EDIT: also re portability, it sounds like the rest of his environment depends on these Python scripts anyway, so I don't think he'd gain anything from being able to use them in a different environment.