Should we persist nested dind data on user's env?

[fgrehm]

I took a stab at implementing the support for exposing ports for web servers on my fork and the way I made it work was to recreate the nested docker instance passing in the appropriate --expose flags.

In order for that to work, I had to be able to recreate the docker instance without losing the data I already had there, so I ended up passing in --volume "$HOST_ROOT/users/$USER/docker/$ENVIRON:/var/lib/docker" to the environment container and was wondering if it would make sense to have this over here too.

WDYT?

[progrium]

You shouldn't have to recreate the DinD environment instance. But in any case, I'm not sure what you mean by "over here too". You mean upstream in this repo?

What do the expose flags give you?

[fgrehm]

You shouldn't have to recreate the DinD environment instance.

But what if we want / need to upgrade the DinD image to a new Docker version or switch over to some other image based on another distro? As of current master (and based on my current Docker knowledge) I think that would require us to recreate things from scratch right?

For sure we can figure out a way of grabbing the volume and reusing it for a new DinD instance but by keeping it on a well known place I believe will make things easier 😄

But in any case, I'm not sure what you mean by "over here too". You mean upstream in this repo?

Right on! I'm hacking away on a separate repo and I'm holding back from sending PRs this way to avoid the noise as I saw on your video that you are putting up some cool things in Go. I just want to make sure I'm relying on appropriate behavior that is likely to land on Envy's core to avoid having trouble upgrading my environments on the future.

What do the expose flags give you?

With that I was able to attach a simple nginx container on a docker events stream and automagically expose DinD container's --exposed ports from http://<port>-<environment>.envy.host:80. Similar to the envy-proxy project mentioned on another issue on this repo, with the difference being the fact that we can hit any port out of the port 80 on the "outer world", allowing me to access multiple web apps running on different ports under the same environment.

I know you are planning to use iptables for port redirection but I still need to be able to access the web apps from port 80 regardless of the underlying port exposed and the reason behind that is some firewall rules I face on a couple networks I plan to use Envy from 😞

[progrium]

Good point on upgrading DinD. I just don't expect it should be restarted
for ports. But because it would need to be recreated eventually, a volume
mounted with host makes sense.

Glad you're exploring more and sending back feedback like this.

Okay cool, I just wanted to make sure you didn't find something iptables
wouldn't cover. The iptables bit will allow arbitrary socket traffic to be
exposed, not just web, and it would behave the same except for having an
HTTP frontend involved. Perhaps the admin sets up a shared environment to
manage the system NGINX...

On Tue, Jul 14, 2015 at 7:31 PM, Fabio Rehm notifications@github.com
wrote:

You shouldn't have to recreate the DinD environment instance.

But what if we want / need to upgrade the DinD image to a new Docker
version or switch over to some other image based on another distro? As of
current master (and based on my current Docker knowledge) I think that
would require us to recreate things from scratch right?

For sure we can figure out a way of grabbing the volume and reusing it for
a new DinD instance but by keeping it on a well known place I believe will
make things easier [image: 😄]

But in any case, I'm not sure what you mean by "over here too". You mean
upstream in this repo?

Right on! I'm hacking away on a separate repo
https://github.com/fgrehm/devstep-envy and I'm holding back from
sending PRs this way to avoid the noise as I saw on your video that you are
putting up some cool things in Go. I just want to make sure I'm relying on
appropriate behavior that is likely to land on Envy's core to avoid having
trouble upgrading my environments on the future.

What do the expose flags give you?

With that I was able to attach a simple nginx container on a docker events
stream and automagically expose DinD container's --exposed ports from
http://-.envy.host:80. Similar to the envy-proxy
project mentioned on another issue on this repo, with the difference being
the fact that we can hit any port out of the port 80 on the "outer
world", allowing me to access multiple web apps running on different ports
under the same environment.

I know you are planning to use iptables for port redirection but I still
need to be able to access the web apps from port 80 regardless of the
underlying port exposed and the reason behind that is some firewall rules I
face on a couple networks I plan to use Envy from [image: 😞]

—
Reply to this email directly or view it on GitHub
#42 (comment).

Jeff Lindsay
http://progrium.com

[jgallen23]

@fgrehm I actually just added support for multiple ports on envy-proxy. just pass in -e PROXY_PORTS=80,8080,3000 -p 80:80 -p 8080:8080 -p 3000:3000

Sounds like you did something similar to envy-proxy, which just uses nginx to proxy to the dind and uses docker-gen to auto gen the nginx conf

[fgrehm]

@jgallen23 cool! I'll give it another spin and will see if I can be of any help over there 😄 🍻