{"action":"created","issue":{"url":"https://api.github.com/repos/cirocosta/l7/issues/6","repository_url":"https://api.github.com/repos/cirocosta/l7","labels_url":"https://api.github.com/repos/cirocosta/l7/issues/6/labels{/name}","comments_url":"https://api.github.com/repos/cirocosta/l7/issues/6/comments","events_url":"https://api.github.com/repos/cirocosta/l7/issues/6/events","html_url":"https://github.com/cirocosta/l7/issues/6","id":252623273,"number":6,"title":"Multi-ns single-host proxy","user":{"login":"cirocosta","id":3574444,"avatar_url":"https://avatars0.githubusercontent.com/u/3574444?v=4","gravatar_id":"","url":"https://api.github.com/users/cirocosta","html_url":"https://github.com/cirocosta","followers_url":"https://api.github.com/users/cirocosta/followers","following_url":"https://api.github.com/users/cirocosta/following{/other_user}","gists_url":"https://api.github.com/users/cirocosta/gists{/gist_id}","starred_url":"https://api.github.com/users/cirocosta/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cirocosta/subscriptions","organizations_url":"https://api.github.com/users/cirocosta/orgs","repos_url":"https://api.github.com/users/cirocosta/repos","events_url":"https://api.github.com/users/cirocosta/events{/privacy}","received_events_url":"https://api.github.com/users/cirocosta/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-08-24T14:38:08Z","updated_at":"2017-08-25T03:32:28Z","closed_at":null,"body":"tl;dr: add ability to specify `domain=mydomain.com,address=127.0.0.1,port=80,ns=12313` such that connections to `mydomain.com` would have a server where the connection to upstream server `127.0.0.1:80` would be performed over the network namespace `12313` (with the restriction that `ns=12313` exist). \r\n\r\n---\r\n\r\nHey,\r\n\r\nI was wondering if we can put a `l7` in the host machine and make it forward requests to overlay-networks that are not having their containers with a port bound  to the machine (but the containers itself are in the machine). \r\n\r\n```\r\n                                              ns 456\r\n                                           +----------------------+\r\n                                    +----->|  network1_container1 |\r\n                                    |      +----------------------+ \r\n                    (host namespace)|  \r\n  HOST: mycontainer.com  --> l7 ----+       ns 123\r\n                                    |     +----------------------+\r\n                                    +---->|  network2_container1 | \r\n                                          +----------------------+\r\n```\r\n\r\nnaturally that places the constraint of running the `network1_container` and `network2_container1` in the same host. \r\n\r\nA use-case that comes to my mind is providing a way to touching local containers via a single address. For instance:\r\n\r\n```sh\r\ndocker network create --driver overlay --attachable network1\r\ndocker network create --driver overlay --attachable network2\r\ndocker run --name nginx1 --detach --network network1 nginx:alpine\r\ndocker run --name nginx2 --detach --network network1 nginx:alpine\r\n\r\n# no ports are bound, thus even if we \r\n# inspect `nginx` container and get its\r\n# network IP we won't be able to get the\r\n# response back. \r\n\r\n# Now say that we make `l7` load-balance\r\n# across the two network namespaces.\r\n# We could then bypass veths/bridges relying\r\n# solely on `l7` to make the requests across\r\n# both networks with only 1 port binding (l7).\r\n\r\ncurl <l7-ip>:80 ---> nginx1    # from network 1\r\ncurl <l7-ip>:80 ---> nginx2    # from network 2\r\n... \r\n```\r\n\r\nThis is useful in the scenario where an agent run in a machine in the host namespace but the containers that are running in this machine are not in such namespace (naturally, they're on their own network-isolated contexts). \r\n\r\nIf this agent wants to touch the service provided by these containers then this agent must perform the connections entering those namespaces. \r\n\r\nI'm not very sure how could we specify that without tying it too much to docker though ...\r\nMaybe something like:\r\n\r\n```\r\ndomain=mydomain.com,address=127.0.0.1,port=80,ns=12313\r\n```\r\n\r\nsuch that by specifying `ns` the upstream tcp connection would be perform inside the `12313` ns."},"comment":{"url":"https://api.github.com/repos/cirocosta/l7/issues/comments/324815185","html_url":"https://github.com/cirocosta/l7/issues/6#issuecomment-324815185","issue_url":"https://api.github.com/repos/cirocosta/l7/issues/6","id":324815185,"user":{"login":"cirocosta","id":3574444,"avatar_url":"https://avatars0.githubusercontent.com/u/3574444?v=4","gravatar_id":"","url":"https://api.github.com/users/cirocosta","html_url":"https://github.com/cirocosta","followers_url":"https://api.github.com/users/cirocosta/followers","following_url":"https://api.github.com/users/cirocosta/following{/other_user}","gists_url":"https://api.github.com/users/cirocosta/gists{/gist_id}","starred_url":"https://api.github.com/users/cirocosta/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cirocosta/subscriptions","organizations_url":"https://api.github.com/users/cirocosta/orgs","repos_url":"https://api.github.com/users/cirocosta/repos","events_url":"https://api.github.com/users/cirocosta/events{/privacy}","received_events_url":"https://api.github.com/users/cirocosta/received_events","type":"User","site_admin":false},"created_at":"2017-08-25T03:32:28Z","updated_at":"2017-08-25T03:32:28Z","body":"It turns out that managing multiple netns are not very manageable right now with Go:\r\n\r\n- https://www.weave.works/blog/linux-namespaces-and-go-don-t-mix\r\n- https://github.com/golang/go/issues/20676"}}
{"actor":{"display_login":"cirocosta"}}