Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We're a small business and trying to decide on the best architecture for our internal boxes. We have some dev, production and staging environments. All of them are publicly accessible (but of course restricted by password).

For a rather simple need, I really don't see the need to have multiple ip addresses for each box. Seems to add un-necessary complexity. Instead I'm debating that it's better at this stage to just have a single public IP address with a Reverse Proxy (e.g. Squid) or just use rewriting in Apache to forward the requests to appropriate servers (depending on the domain name).

What are your thoughts? Have I got this wrong and Multiple IP Addresses are the way to go regardless of the size of the organisation? What approach have you typically chosen?

share|improve this question

3 Answers 3

up vote 1 down vote accepted

I'd favour varnish or ha-proxy over squid for reverse proxying. However having seperate IP addresses gives a lot more flexibility - e.g. if you want to access boxes remotely using different protocols such as ssh. Proxying also entails one more tier, affecting perfromance and complicating diagnostics.

share|improve this answer
    
That's a good point. I had only originally thought about port 80 (since most of them are HTTP servers) but they will also need SSH access. This is definitely easier with IP separation. –  Anton Babushkin Jul 14 '11 at 4:19
    
(it also makes it simpler to check that all the nodes are up if you add unique names for each IP address) –  symcbean Jul 15 '11 at 12:35

We use apache for rewriting/proxing to internal web servers, and it works pretty well. However, be careful how you setup your virtual hosts on the server, as the first rule that matches the pattern is the one that is chosen. The order can matter.. For example, if you have a default or fallback place to forward to (such as your main site) it needs to be last.

Also, SSL gets a bit trickier. You would need wildcard cert for *.yourdomain.com and then use URL matching for each virtual host to forward. The wildcard certs can be a bit trickier, but not too bad.

share|improve this answer
    
That's a good point. I had only originally thought about port 80 (since most of them are HTTP servers) but they will also need SSH access. This is definitely easier with IP separation. –  Anton Babushkin Jul 14 '11 at 4:16

I don't see any inherit badness with using Apache to proxy back to the appropriate internal servers. Just setup windcard DNS so you can have dev.foo.com, test.foo.com, etc, then setup vhost definitions with the corresponding proxy rules to route back to the appropriate boxes. That said, you can use a few tools to do this; Apache's not the only solution.

As for certs, unless you absolutely need valid dev/test certs, just make your own wildcard cert.

Also, Squid's a good FORWARD proxy, but it's pretty heavy/crap the other way around.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.