Export web.* host environment variables

[mbrodala]

It would be useful if there where WEB_*_HOST environment variables in addition to the existing DATA_*_HOST environment variables.

Background: I'm trying to use Nanobox to run acceptance tests using Selenium. Adding a data component for selenium was easy (see #365):

data.chrome:
  image: selenium/standalone-chrome

Afterwards I see a DATA_CHROME_HOST environment variable in my app container. This is good to instruct my testing framework (CodeCeption) how to talk to Selenium via the WebDriver protocol.

However, I'd also need a way to expose the IP address of the app container with its running web server to the Selenium container since Chrome needs to perform HTTP requests against the app container.

Thus basically an environment variable WEB_SITE_HOST (for a component web.site) needs to be exported in the data.chrome container. These are the environment variables currently available within data containers:

HOSTNAME=<hash>
TERM=xterm
LC_ALL=en_US.UTF-8
PATH=/data/sbin:/data/bin:/opt/gonano/sbin:/opt/gonano/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
LANG=en_US.UTF-8
HOME=/data/var/home/gonano
SHLVL=1
LANGUAGE=en_US:en
_=/usr/bin/env

(Taken from a mysql container, consoling into custom containers currently does not work, see #383)

[sanderson]

Correct me if I'm wrong @lyondhill, but you wouldn't actually want the IP of your web container. You'd want the IP of portal (the router), which acts as the http endpoint for your web. We auto-generate the PORTAL_HOST evar, so you should just be able to use that.

[danhunsaker]

You wouldn't have Portal with nanobox run, which is how it's used with CI (which is the only use case this component actually has).

[mbrodala]

Correct. I could use nanobox deploy dry-run but that takes ages, thus it'd be nice to have this working in nanobox run.

[sanderson]

Ah, gotcha. In that case a web container wouldn't be created either, so to hit the app with an http requests, you'd have to have the "Env IP". This is currently available in the nanobox info local output and could be grep'd from there, but we could possibly create an evar for it to make it a little easier. @lyondhill or @notxarb, thoughts?

[lyondhill]

we are not currently creating evars in data components. I believe the hook structure does not support this behavior. Adding the ENV_HOST (in a run that is the running container and in dry-run it is the portal vm) would work. The other idea of adding WEB_*_HOST wont work since we need the data components up before we can start the webs/workers. It is a chicken egg problem.

[mbrodala]

I see the problem here. You cannot inject environment variables into containers after they have been started?

[lyondhill]

Although it is possible to inject env vars into the container we made a decision not to since that would require all the data components to be reconfigured. And at that point a failure in a the reconfigure would be nearly impossible to undo.

[danhunsaker]

There's no mechanism for adding env vars to an already-running system; they're handled by the shell, which means (at the very minimum) restarting the shell, and all its child processes - including your server process(es) - to bring in those new values. For many engines, the environment is only consulted on the first run, and ignored after that, so even then the changes would be ignored. That, I'm sure, is part of why the current architecture actually requires a full rebuild to get the updated env vars into your components.

It would probably be a good idea to add the ENV_HOST var, though, since that should be known before even the data components come up...

Also, as a side note, the only reason a data component is in need of such values in this case is because there are no local-only component types - this one is being used to bring in Docker images for testing purposes (though there are other potential uses of such containers, of course).