External IP access to containers [message #49818] |
Fri, 21 June 2013 11:55  |
dsl101
Messages: 3 Registered: June 2013
|
Junior Member |
|
|
I've got a HN running on an Amazon EC2 instance, with several containers running inside it. I'm stuck at the point of trying to figure out how to make these containers visible to the big wide world - they'll be running CMS software and so all need to serve stuff on port 80/443.
Amazon seem to limit the number of public IP addresses which can be assigned to an instance - I can easily get 2 addresses, but it's costly to go higher, and can't go beyond 8 anyway. I can easily imagine having more containers than this.
So, my question is, if I want each container to have it's own external DNS entry and domain name, which will work seamlessly for users by simply typing the domain name into a web browser, am I stuffed unless the HN can have different IPs for each container associated with it? Can the routing on the HN be based on the domain name requested, rather than the IP address?
It's my first foray into OpenVZ, so apologies if this is a FAQ - I didn't see it anywhere so far...
|
|
|
Re: External IP access to containers [message #49823 is a reply to message #49818] |
Fri, 21 June 2013 15:46   |
Paparaciz
Messages: 302 Registered: August 2009
|
Senior Member |
|
|
you can install nginx or apache in HN, or in separate CT, and then do reverse proxying. that will be "routing" by domain.
if you can't control which domains are added (users owns and controls CTs), than without more public ip addresses it will be imposible.
|
|
|
|
|
Re: External IP access to containers [message #50618 is a reply to message #50602] |
Sun, 22 September 2013 08:28  |
dsl101
Messages: 3 Registered: June 2013
|
Junior Member |
|
|
Thanks - I ended up using an empirical approach (e.g. start with the minimal setup and wait until some users complained about things not working). Nobody has complained so far. The HN is on 'domain.com', and I just have these 2 lines in the apache config for each CT (note I've used '|' instead of '/' here - the forum thinks I'm posting links!).
ProxyPass / https:||sub.domain.com/
ProxyPassReverse / https:||sub.domain.com/
SSL works by virtue of the CTs all being subdomains, and the HN can authenticate using the same wildcard certificate for *.domain.com. Obviously this wouldn't work if we had fqdns for the CTs, but at the moment everyone is happy with subdomains.
I _think_ there is a way round that even for CTs with different certificates, but it relies on a browser capability so might not be perfect.
Anyway, all well so far - thanks. I'll look into your suggestion though to get the logging more accurate - again, not a problem for now...
|
|
|