Docker + Joyent + OpenVPN = Bliss (opens in new tab)

The first thing is that containers allow you to securely isolate software and its configuration without impacting that software's usage of resources the same way a vm does.

Isolation of configuration is extremely valuable here, you now have a collection of containers that aren't polluting your host system with its dependencies and configuration, now containers can inter-operate with each other over known protocols and upgrade/downgrade their configurations or software without any impact to the surrounding host system.

Security is a big one too, containerization allows you to completely isolate the permissions of the given application - if something is compromised only that one thing and its container are compromised. Fix the issue, throw away the old container, build a new one, deploy it, voila!

The second reason containers are awesome is the ability to build, test, and "deploy" your software. Your build process (if you've actually worked on it!) with Docker is now to have it part of your automated testing cycle, build cycle, and packaging cycle where when you, say, tag a release - an automated build gets kicked off that builds the whole application in a Docker image with the explicitly listed dependencies (as they may be updated!!!), if that succeeds without error then go on to automated/QA testing, if that passes then packaging as a docker image ready to be installed. You drop it on the server and you're ready to go!

[EDIT] I use a similar set-up to the author but I'm on FreeBSD; in FreeBSD we have ZFS and ezjails which provides most of the same functionality (but slightly more "cool" because of ZFS) as Docker but as a set of shell scripts, you can have certain jails start up with the host system.

I run OpenVPN, TOR, a web server with OwnCloud on it, and a few other experiments on the machine and it's a joy to be able to throw away a jail and build a new one, or create new jails whenever I want to experiment but never worry about it polluting the host system and also not worry about performance impact on my cheap hardware.

- I can shutdown one of those "experiments" without affecting others. - If I want to migrate one of those things elsewhere (because it turns out to need more resources), it's already "Dockerized" (i.e. trivial to redeploy elsewhere). - When I remove one of those things, I don't have to worry about leftover packages, dependencies, files, etc. lying around.

Otherwise it would indeed be a poor use of my time :-)

Agreed, the approach is far from perfect.

1. Process supervision is kept very simple, because there are many other tutorials and demos out there using Supervisor and other systems. I'd love to know what is inherently wrong with using `while true` and hanging on logs. Personally, replacing Supervisor (or monit, or god, or $yourfavoriteprocessmonitor) with 3 lines of shell script is fine with me, especially as the focus is to show that Docker can now run OpenVPN.

2. Handle multiple log streams: indeed! I considered running two separate containers, and the only reason why I didn't do it is to simplify the setup process. I also explored the other option (using two separate containers for TCP and UDP connections), and it works almost the same; it looks like:

docker run openvpn genkeys docker run -volumes-from $CID openvpn tcp docker run -volumes-from $CID openvpn udp docker run -volumes-from $CID openvpn serveconfig

Hopefully, the way the project is laid out makes it fairly trivial for someone to change it to run each openvpn process in its own container.

3. Here again, it's a (not-so-good) trade-off. In many cases, you need something simple and straightforward to move the configuration file to the device, e.g. when the device is a phone or tablet. Downloading a combined file over HTTPS is the simplest solution I found (even if in the Android case, it is slightly crippled by the Download Manager bug). It uses SSL to prevent eavesdropping. It protects against a system which would passively record e.g. WiFi traffic. It doesn't protect against a system which would actively detect such a transfer, and immediately initiate the same transfer, before you have the opportunity to stop the `serveconfig` container. I considered adding some HTTP basic auth, but that would have required a "real" HTTP server in `serveconfig` (or to hack further with socat, but I'm already quite ashamed of the current hack, TBH).

I agree that the setup can be greatly improved (what can't?), but I disagree with "there must be better way in every step". This is certainly not the setup that you want if you have a large number of clients, or if you are in an extremely compromised network (then again, it's only a concern during key exchange), but I don't see why it can't be acceptable for 99% of the personal users out there.