Docker + Joyent + OpenVPN = Bliss

/has karma, uses it.

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.

I don't fully get it, but am trying to follow along. Basically, s small box you can install 1-x s-Linux software apps on, and deploy it on another machine, or inside a VM on that machine.

It's not a real box, or hardware, but a small chunk of software that essential is a pre-made .iso with whatever single, or multi-packackaged goody you desire?

I don't get, with spinning up a VPS being a few clicks, what is the advantage? Can't you make images of your VPS on amazon, or any of the other cloud providers, and save a snapshot of your config? What is the difference?

These are totally posable? Where do they get their real hardware resources from, such as RAM and drive? If I set up a LAMP server in a Docker container, allocate 50GB of memory to Apache, and drop that docker into a micro instance on Amazon, what is going to happen?