DB Tunnels within local containers?

1

We recently switched to using docker in our dev environments. One of our dev environment use cases is running some reporting queries using Jupyter notebooks.

However, I can’t figure out a reasonable way to enable a call to aptible db:tunnel that’s able to be accessed by a running container.

  1. Since db:tunnel binds to the loopback interface, it’s not visible to other hosts, including virtualized hosts like a running dev container. I think this is even the case with host networking, but I’m certainly no pro at this.

  2. It seems a little messy to have folks log into aptible inside a running container (and it’s certainly not as easily scripted). But also, the reliance on ruby 2.2 means that stable releases of debian and ubuntu are out of play, as are our standard docker images (like python/2.7 and such).

So before I go down a path to make a different build process for reporting, I’m wondering if anyone has a setup they like for this kind of thing.

2

Hey there. While I don’t know if those will solve your problem, there are a few things we released recently that you might not be aware of that could actually be useful.

First, the Aptible CLI actually supports an APTIBLE_ACCESS_TOKEN environment variable. If you set it to a valid token, you won’t need to aptible login. This is here explicitly to support scripting use cases (we rely on it ourselves for integration testing of aptible logs).

You can extract the token from your current session via e.g., but other languages can of course be used (you really just need to load that JSON file and extract your token):

token_file = File.join ENV['HOME'], '.aptible', 'tokens.json'
token_hash = JSON.parse(File.read(token_file))
token = token_hash[Aptible::Auth.configuration.root_url]

The Aptible toolbelt is a packaged install that can be installed on stable releases of Ubuntu and Debian via a simple .deb download. If needing Ruby 2.2 to run the CLI (I don’t think such a recent version should be a requirement for the CLI though, did you run into an error otherwise?) is a problem, this could be a solution!

Hope this helps.

I should mention that --net=host might actually work in some cases, but it won’t if your docker daemon is running on a VM (e.g. if you’re using docker-machine / boot2docker). A good heuristic is that it’ll probably work if your DOCKER_HOST environment is unset (or set to the local UNIX socket), and it probably won’t work otherwise.

1 Like
3

Quick correction; the variable is actually called APTIBLE_ACCESS_TOKEN; sorry about that!

4

Rather than parsing out the token and setting environment variable in the container another alternative would be to mount ~/.aptible:~/.aptible on the running container. That way once a user is logged in on the host aptible installed in the container is also ready to go. This should be perfectly reasonable in a development environment.

5

@rvause Definitely; thanks for the suggestion! :smile:

Do keep in mind that there are some edge cases where that might not work (mainly if using boot2docker without volume sharing, or depending on permissions, etc.), but you’re certainly correct that it should work just fine in the general case!

6

The access token will expire, correct? Is there a way to generate a token which doesn’t expire?

7

That’s correct, access tokens expire, and you can’t currently create access tokens that don’t expire.

That being said, if you extract it from your tokens file using code like the sample I provided, you’re probably going to periodically update the token every time you log back in via the CLI.

8

Yes that’s correct: access tokens do expire, and you can’t currently create an access token that does not expire.