We would like to have multiple managed rancher networks. That would be possible using different rancher environments, however we need some services to be in two environments at the same time.
I tried to put the database into a different stack, however the managed network spans across stacks, at least when I know the specific managed IP adress of the database container in the other stack. So this does not work as a isolation mechanism.
What would be the best route to go if I want to create a setup like this?
Currently, Rancher doesn’t support multiple managed rancher networks. In the future, we are considering adding this. I recommend creating a feature request for this in Github.
But I don’t believe any service will be available in 2 different environments. With the current managed network, we look as environments as completely separate resource pools and nothing would overlap.
I just found this response Cross-host intercontainer communication trouble from the docker team.
Seems like one could set up such isolated networks be tweaking the physical connections between the hosts.
If you’re referring to me, @denise and I work for Rancher, not Docker.
Yes you can create “islands” of hosts that can communicate with each other but not hosts in other islands with physical networking or firewalling. But I don’t think that really helps you because you can’t have any one container “on” more than one island.
As Denise said there is one managed network per environment, and a host can only be in one environment. So we don’t have any good way to do this today. Multiple networks and attaching containers to many networks is one option; we’ve also talked about disabling the default ability for any container to talk to any other and requiring explicit links as an option before: https://github.com/rancher/rancher/issues/2817#issuecomment-172047720
You can have a separate environments & host(s) for each thing you want isolated, but that doesn’t leave any way for the different tiers to talk to each other. Then you could publish the ports of those services to the public IPs of the hosts (which might be internal/non-routable), and then at that point there’s probably no reason to have them be isolated in the first place.