OpenVZ Forum


Home » General » Support » External IP access to containers (Is this a showstopper?)
External IP access to containers [message #49818] Fri, 21 June 2013 11:55 Go to next message
dsl101 is currently offline  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 Go to previous messageGo to next message
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 #49824 is a reply to message #49823] Fri, 21 June 2013 15:56 Go to previous messageGo to next message
dsl101 is currently offline  dsl101
Messages: 3
Registered: June 2013
Junior Member
Well, the good news is that we'll control the HN and all containers, so we can put whatever we like wherever we like Smile

The containers have to run a highly customised version of Joomla though, and we can't hack it's configuration too much without breaking things.

If all the routing can be done on the HN, then that would be fine - so long as the container can't tell...

Would nginx be better than apache for this? I don't know either very well, but given the containers are using apache, perhaps that would be best...

Thanks,

Dave.
Re: External IP access to containers [message #50602 is a reply to message #49824] Fri, 20 September 2013 10:12 Go to previous messageGo to next message
votsalo is currently offline  votsalo
Messages: 26
Registered: December 2011
Location: Greece
Junior Member
I use pound for the reverse proxying, and shorewall to setup the HN iptables so that the incoming port 80 is forwarded to the pound container. There is some additional configuration on the final CT: I changed the apache "combined" definition in apache2.conf to use the %{X-Forwarded-For}i field.

I don't know about Joomla, but I use Drupal and I had to make some configuration changes: For example, I had to tweek the configuration so that drupal logged the original ip in the database access logs, instead of the proxy ip. You have to do similar things if the end application has some access control based on incoming ip.
Re: External IP access to containers [message #50618 is a reply to message #50602] Sun, 22 September 2013 08:28 Go to previous message
dsl101 is currently offline  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...
Previous Topic: template not found, but i can create container
Next Topic: How to Disable nf_conntrack on vz start
Goto Forum:
  


Current Time: Wed Sep 04 15:21:00 GMT 2024

Total time taken to generate the page: 0.05831 seconds