View on GitHub

Debootstrap-container

simple way of running multiple debian containers on a (openvz) VPS

Download this project as a .zip file Download this project as a tar.gz file

debootstrap-container

simple way of running multiple debian ssh-able containers on a (openvz) VPS

CAUTION: this shellscript requires root, use at own risk.

Usage

Usage: 

debootstrap-container delete <containername>
debootstrap-container add <containername> [release] [variant]
debootstrap-container run <containerdir/name> 
debootstrap-container showreleases

Howto

$ sudo debootstrap-container add foo
enter user which should be 'root'? foo 
adding new user 'foo'
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully 
redirect user into container upon ssh-login? (y/n) y
[x] created container '/srv/containers/foo'

$ ssh foo@localhost
foo@foo# whoami
uid=1003(foo) gid=1004 groups=1004

foo@foo# sudo whoami
root

foo@foo# sudo apt-get install python2
foo@foo# exit

now the funpart is: python2 is only installed in the container, and the sudo is actually fakeroot.

Why

I am a huge fan of docker but unfortunately I had to do multiple projects inside one VPS server. I could not get docker working, and solutions like sekexe or jailkit pointed into more possible hassle. I had to go another road to satisfy my needs:

Docker compatibility

It should be compatible with docker, just tar your jail-dir like so:

tar -C /srv/containers/mycontainer -c . | docker import myname/mycontainer

TIP: shared directories

Sharing directories across containers (originating from outside the container) can be handy. However, avoid symbolic links since it will confuse applications when resolving absolute paths, instead mount like so:

mount --bind /opt/somefolder /srv/containers/mycontainer/opt/somefolder

WARNING: always use 'debootstrap-container delete ' to delete a container. Using a plain 'sudo rm -rf /srv/containers/yourcontainer' might cause dataloss for folders using 'mount --bind'

TIP: persistent containers

To keep the container alive after logouts/timeouts, first get a passwordless ssh-login working:

$ su foo
foo $ ssh-keygen <enter><enter><enter>
foo $ ssh-copy-id foo@localhost
foo $ exit
$ ln -fs /srv/containers/foo/home/foo/.ssh /home/foo/.

Then:

By doing so, the master-screen process will always be persistent, and you can just ssh from anywhere directly into your ssh-container. You can even run a screen inside your container if you want to. The following files would automate this:

/root/.screen

screen -T xterm -t container_foo 1 su foo -c 'ssh foo@localhost'
screen -T xterm -t container_bar 2 su bar -c 'ssh bar@localhost'

/etc/init.d/screen

#!/bin/bash
find /srv/containers -mindepth 1 -maxdepth 1 -type d | while read dir; do       
  /root/lemon/server/debootstrap-container/debootstrap-container mount_dirs "$dir"
done
echo /usr/bin/flock -w 0 /root/.screen.lock /usr/bin/screen -s /bin/bash -d -m &

This would mount some needed folders (/sys /proc) and start+detach the screen during startup. To start services by default just do something like:

echo "/etc/init.d/mysql status || /etc/init.d/mysql restart" >> /srv/containers/foo/.bashrc

Sudo

The containers use a sudo-shellscript at /usr/bin/sudo which uses fakeroot. To prevent users from installing software please remove the /usr/bin/fakeroot binary.

History

Conclusion

This is definately not secure or as cool as docker, but it is an tidy way to deploy applications on a openvz container (which doesnt run docker).