Feature request - Startup script

[johncokos]

Feature Request ...

When KM starts up and has a running container, it would be nice if it set the appropriate environment variables about the container/image that we could make use of ... things like the current Dev IP, DOCKER_HOST, DOCKER_CERT_PATH, DOCKER_TLS_VERIFY, etc. I'm sure we're not alone in doing loads of shell scripting that wants to refer to things that only are known to the KM/Docker System.

Additionally cool would be the ability to specify a startup script that KM could run after it starts up a container ... a script that we would write ourselves and could expect to be auto-run.

As an example use case, in our system, we need to setup a series of SSH Tunnels to map localhost ports to their equivalents inside the container. Our current process is to tell folks to fire up kitematic, and then go to the terminal and run these 5 commands (query the IP, and then set up the tunnels). I'd much prefer to script that, and have KM just call that script on startup. That totally removes a level of grok from our users.

Make it so ...

[TeckniX]

@johncokos Would you mind sharing the 5 commands to get a feel for what your users are usually doing?

I'm not opposed to a startup script, but everything you've described seems to point to terminal/shell variables, in which case could be added to the .bashrc (or whatever startup file for the shell) instead of actual Kitematic startup, since none of it would work until you created a new terminal.

Maybe the idea would be to create a .kitematicrc file (similar to bashrc) and load that too during terminal startup?

[johncokos]

Once the container is up and running, we ask our users to open the terminal and then setup a number of ssh tunnels like this, once we know the container's IP address, which we get by having first run

netstat -rn

and looking for the vboxnet line.

ssh -fN -g -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -o StrictHostKeyChecking=no -i ~/.docker/machine/machines/dev/id_rsa docker@$DOCKER_IP -L 3000:localhost:3000 $DOCKER_IP

Additionally, we might be piping in the host's IP address into the container via an ssh exec (remember our discussion yesterday?).

If the .kitematicrc was executed each time the container started, great, but its not useful enough just to have it executed when we open a terminal.

Remember, that the vast majority of our userbase is non-technical, especially when it comes to using Terminal.

[TeckniX]

Couple of things to note, which makes the above confusing to me.

1. Your vboxnet line should never change aka it's hard-coded to be 192.168.99.100
2. Your ssh command doesn't actually ssh into the container, but rather the VirtualBox that runs docker-machine, which in-turn runs the container. Creating a tunnel at that level doesn't seem useful to me, since all ports should be available. (unless this is for your remote access of the port?)

With all of the above in mind, you could cut-down on a lot of work/effort by enabling port-forwarding on the VirtualBox directly using the VirtualBox manager: http://www.howtogeek.com/122641/how-to-forward-ports-to-a-virtual-machine-and-use-it-as-a-server/

[johncokos]

1. The IP of "dev" will change if it craps out and you do the whole "Delete and Retry setup" thing ... I've got folks where their dev is .107
2. Those commands just setup a tunnel via the port so that we can use "localhost" to access the container instead of the 192 number. Don't ask why, but apparently node-inspector requires either localhost or 127.0.0.1 to work in Chrome, so I have to make folks do the tunnel.

I like your suggestion. If that works, we may be in business ... can that be automated somehow at installation is the question that pops.