Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Solution for internal services #436

Open
enxebre opened this issue Jul 30, 2015 · 2 comments
Open

Solution for internal services #436

enxebre opened this issue Jul 30, 2015 · 2 comments

Comments

@enxebre
Copy link
Contributor

enxebre commented Jul 30, 2015

So the way it is at the moment as the haproxy template is very simplistic every service will be exposed to the outside as service-name.example.com via the elb using the port 80 both the elb and the haproxies. Could create another "haproxy fronted" bound to a different port (e.g 1234) so no accessible from the outside and populate the backends according to consul tags, then in the bastion put in place a solution for resolving your chosen “haproxy_internal_domain” to a given slave so your interal services would be available in the bastion VPN via “app.haproxy_internal_domain:1234”. Other possibilty would be to expose a given weave subnetwork to the bastion so all the internal services would be accesible via consul DNS as in your case like *.service.consul. We are pending on weaveworks/weave#117 (comment) so we can be more granular at the time of creating weave subnets.

@tayzlor
Copy link
Member

tayzlor commented Jul 30, 2015

Kinda Related #122

@enxebre
Copy link
Contributor Author

enxebre commented Nov 4, 2015

See posible solution here #468

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants