The only solution that I can think of would be to have a separate environment for these services. Otherwise, they all use the same managed network and can communicate between each other.
We had initially planned to lock down communication between containers with iptables so that they could only talk to things they were explicitly linked to, but that was never implemented.
With metadata there are now other ways to discover IPs that you might want to talk to so it probably couldn’t be enabled by default, but this could still potentially be an optional feature.
I just tested … like you said, the services in the two Stacks (environemts) seem to use the same managed network. It’s still possible to open a connection from one environment to an other.
@Vincent:
I think the way of managing iptables is a good one. The other big question will be:
Based on which metadata you re going to separate the networks? From Service to Service? From Stack to Stack?
It would be awesome to have the possibilit to “link” services but also stacks.
@Flo_B When I am referring to “environment”, I am referring to the UI term, which means you’d have separate hosts so all traffic would be separated by different overlay networks. In the API, it’s referred to as “projects”.
You mean, i have to setup a completely new environment by deploying a new rancher/rancher (maybe on the same host like my other rancher/rancher but on a different port) and also new hosts for this environment?
→ Of coure this would fit my needs. Did i understand you correct?
@Flo_B, you add more environments from <your rancher server>/settings/environments (Manage Environments menu option from the dropdown menu in the top right corner).
Each environment have their own dedicated hosts added to them (running rancher/agent) as usual.