-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creates a Docker container to run algo #331
Conversation
Neat! Glad to hear the Creator's Build will have WSL based on Ubuntu 16.04. I hope this resolves the many issues that Windows users seem to run into. I'm happy to support this if others want to contribute the missing pieces. |
I've just cleaned things up a bit, mostly to make the container smaller. I'll put together the other missing pieces -- namely, the second and third points from the list -- and add them in over the weekend. It should probably also cover provisioning nodes in GCP as well; that should be reasonably simple, as it's just another bind-mount. |
I've addressed the first of the three points above, so this should now be ready for review and testing. Right now this falls into the "works for me" category; I'm not sure how to go about writing automated tests for this. Note that I've just marked trailofbits as the maintainer, and the documentation points people to a currently-nonexistent Docker Hub repository. For now, you can EDIT: Alternatively, just don't provide pre-built images, and instruct folks on building their own. It's pretty simple: |
Cool! I would drop the instructions from the main README. I think this is still kind of "experimental" and will need some time to fully bake. At that point, we can think about how best to put it in the main readme. |
I wasn't sure about the main README update, hence it being a distinct commit; it's now dropped! |
Need to make some tests in .travis.yml |
I nearly submitted a pull request for running the client in Docker last week as well! Very cool to see interest. My solution is simpler. Here's my Dockerfile:
I built the container and successfully created a VPN with the following commands:
|
algo-docker.sh
Outdated
fi | ||
|
||
# Ensure that `config.cfg` has the appropriate line endings | ||
tr -d '\r' < config.cfg > config.cfg.new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One could do an in place edit using
sed -i -e 's/\r//' config.cfg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.... oh dear, I'm not sure what I was thinking here. Thanks, I'd much rather use sed
in this case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, turns out you can't, which is probably why I did it in this weird way in the first place:
When you do the in-place sed
, it actually moves the file and tries to re-create it, which isn't possible because of the bind-mount of the single file. We can either put everything in a single directory and point algo
at that, or go back to this weird way of doing things.
I would LOVE to have Algo in a Docker container! But it seems Docker may not offer a working IPsec stack from the StrongSWAN docs: https://wiki.strongswan.org/projects/strongswan/wiki/Cloudplatforms Container Virtualization"Container virtualized environments often do not offer a working IPsec stack to software in the container. Therefore, kernel-libipsec has to be used instead. To use kernel-libipsec, tun devices have to be available. Keep in mind that using kernel-libipsec has drawbacks and is generally discouraged. Change to a hardware virtualized virtual machine, if possible." I'd love to run this in a container on Kubernetes. Anyone try that and get it working? |
Thanks, but that is not what this PR is about. |
This would make it much easier to set up ephemeral provisioning environments, especially from external things like web apps. :-) love it. choice base container seems correct; use of a full ubuntu:16.04 image would not be needed for the algo client. |
Granted this is off topic but I'm not sure about the claim that IPSec does
not work in a container. Simply searching for "docker IPSec" via Google
seems to indicate this is possible albeit not necessarily with strongSwan.
I think it bears more investigation but on a separate thread.
…On Sat, Apr 15, 2017 at 8:30 AM, Dan Stroot ***@***.***> wrote:
I would LOVE to have Algo in a Docker container! But it seems Docker may
not offer a working IPsec stack from the StrongSWAN docs:
https://wiki.strongswan.org/projects/strongswan/wiki/Cloudplatforms
Container Virtualization
Container virtualized environments *often do not offer a working IPsec
stack to software in the container.* Therefore, kernel-libipsec has to be
used instead. To use kernel-libipsec, tun devices have to be available. *Keep
in mind that using kernel-libipsec has drawbacks and is generally
discouraged.* Change to a hardware virtualized virtual machine, if
possible.
I'd love to run this in a container on Kubernetes. Anyone try that and get
it working?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#331 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAA0-jHQlowaRWe8GtdxMJ7n0d4rA3rCks5rwOKJgaJpZM4MwWj_>
.
|
Yes, this is getting off topic but the process is documented here: |
Thanks @gsf! @mutemule: Do you want to update your PR with anything from #331 (comment)? I've never used docker before and try to avoid it where ever possible, so I have no idea how to judge the value of each possible solution here. |
There's a lot of hype around containers in general but in all honesty, I think it's likely the way forward particularly since we can probably use Docker Compose to containerize the various pieces. For instance, we can chose to pull in ad-blocker, dnscrypt functionality etc. based on features selected. But we'll have to work through figuring out how to get IPSec working in a container first. |
@jauderho we won't be doing that, and that is not what this PR is about. This just makes it easier to install the dependencies and deploy new Algo servers for some users. You can't effectively run a strongswan inside a container. I don't trust kernel-libipsec enough. |
@dguido I don't think kernel-libipsec is needed in a Docker container when using the Macvlan network driver for the container networking. I haven't fully tested it for ipsec comms yet though.
https://docs.docker.com/engine/userguide/networking/get-started-macvlan |
@dguido: I need to update the docs as I found a bug in how I'm running the container, but I think what #331 (comment) is trying to do is somewhat distinct from what I'm proposing: I'm trying to get a good container image pushed to Docker Hub that anyone can use without needing to install Algo at all. I also want to have a look, as I suspect basing this off Alpine -- which makes the Dockerfile somewhat more complex -- results in a considerably smaller image, which makes this easier for folks to consume arbitrarily. |
The article about cloud platforms and container virtualization does not pertain docker, but surely OpenVZ and Virtuozzo. The reason is that whatever the devs did broke something that breaks XFRM or the ABI to it (protocol over netlink socket). If the container virtualization you use didn't break it (so it doesn't inherit from OpenVZ) and your container has the privileges, it will work just fine. I wrote that article, so I know that . Give the application in the container CAP_NET_ADMIN and it will work. |
haha oh great, now I have to update the new documentation I wrote this weekend :-( https://github.com/trailofbits/algo/blob/master/docs/deploy-to-unsupported-cloud.md |
Sorry. :( |
I've also updated the docs to reflect the bug that I found: namely, when running under Linux, it needs Now that this part is done, I'm going to tackle tests. Not entirely certain how to do that just yet. (New builds have been pushed to EDIT: Fixed a few more issues; the SHA in the build above is now outdated. But the image itself doesn't run, because of volume permissions that I'm trying to sort out. Windows makes this quite hard... |
Okay, worked around the volume mounting permissions thing. Docker on Windows actually runs from a Linux VM, so when you bind-mount a Windows directory, file system permissions can only every be 0755 as a result of the mount type (CIFS, I believe?). So we no longer use the configuration data directly, and simply copy it into and out of I've successfully used the container to provision three VMs in the last few hours, with varying configurations, from Windows. This means that I've also made some headway with running tests, in that I have some ideas as to how to approach testing. I'll play a bit with this in the coming days. |
Neat, keep at it! |
Don't forget to resync with master now and again too btw |
Yeah, I am. Pretty much anytime I do any work, I pull in latest master. |
I've added simple instructions (71f01ad) to test building a Docker image. CI time doesn't seem to have increased significantly, which is good.
I misunderstood the way tests were being run, but I think this is going to work out reasonably straightforward, at least for rough tests. Just trying to sort out the appropriate invocation syntax now. |
I've left the commits for two distinct approaches to testing in place. The latter is more thorough but more complex; the former is more straightforward but less thorough. Also, it looks like Travis can actually push the Docker image up to a repository (or you can configure Docker to build images itself). Doing so will make building images considerably easier, but I don't think you can use Content Trust (signed images) in that case. |
This simply uses the same LXC system that was just tested. It's functional, but minimal.
This doubles the number of LXC containers in use, but does provide a more thorough test of the Docker image.
For a long while, I couldn't run Docker on Windows, so I hadn't touched this. I've just rebased on latest master, built new images, and pushed them up to Docker |
Thanks for picking this up again! We had a "needs tests" label on this before, but it looks like you updated the Travis testing scripts and it passes now. I'm ready to merge this but I want Jack to check it out quickly. I requested his review. |
Yes, that's great. How about make a repository on the docker hub and push the image every build with tags by Travis? |
* Creates a Docker container to run algo * Simplistic testing of the Docker image This simply uses the same LXC system that was just tested. It's functional, but minimal. * More thorough tests against Docker This doubles the number of LXC containers in use, but does provide a more thorough test of the Docker image.
* Creates a Docker container to run algo * Simplistic testing of the Docker image This simply uses the same LXC system that was just tested. It's functional, but minimal. * More thorough tests against Docker This doubles the number of LXC containers in use, but does provide a more thorough test of the Docker image.
This does not enable you to run your VPNs from within a container.
(I'm not even sure how that would be possible, given Docker networking.)
The current version of WSL (the Ubuntu layer) provided by Windows in the Anniversary Update is based on Ubuntu 14.04 (Trusty), whereas Creators Update (expected April 11) is based on Ubuntu 16.04 (Xenial). You can get early access to the WSL update by enabling Insider Preview builds.
I just underwent another re-image of a Windows workstation, and I can't enable Insider Preview builds, as it conflicts with some other settings I have. But I do want to be able to run
algo
on my machine, so I put together a quick Dockerfile so this can be run via Docker. Thus far, I've successfully provisioned analgo
instance in EC2 using this container.You can give this a shot right now:
config.cfg
in your local filesystem: .e.gC:\Users\mutemule\VPNs\config.cfg
configs
: e.g.C:\Users\mutemule\VPNs\configs
docker run --cap-drop ALL -it -v C:\Users\mutemule\VPNs\configs:/algo/configs -v C:\Users\mutemule\VPNs\config.cfg:/algo/config.cfg mutemule/algo:latest
docker run --cap-drop ALL -it -v C:\Users\mutemule\VPNs\configs:/algo/configs mutemule/algo:latest
Since I needed this for myself anyhow, I figured I would share this upstream. This PR probably shouldn't be merged as-is, but I'm happy to clean it up for merging if there's interest:
The maintainer probably shouldn't be me.Resolved.It needs some documentation indicating how to run the container.Resolved.It may benefit from something in the image to ensure the container is invoked properly (Resolved.configs/
is actually bind-mounted to the host; container is launched interactively with a TTY; etc.) -- I've already got something like this locally, but it's thoroughly untested.algo
needs to run as root -- this is probably okay, but it's not ideal, and may break when user namespacing is enabled (I haven't tested this). I don't know a way around this.