On 19 May 2011, at 14:07, frankblizzard wrote:
BTW, why would you run Apache or nginx on port 3000 when you can just
run everything on the same webserver?
I don't have apache running on 3000 - it have Webbrick still running
there so the clients can reach the rails app, but I want to deploy it
via passenger to them as it seems more stable and better for
production. Just we can't reach it running on Passenger from the
clients in the intranet.
I just wondered if anyone ever configured a scenario like this and can
share his experience, I know it has little to do with rails actually,
hope you guys don't mind.
Deploying for your intranet is basically the same as deploying on a
"public" server. Passenger is a module for Apache or Nginx just like
the PHP processor is. You follow the instructions on the Passenger
site to get it installed, nothing more, nothing less.
Then there's the other three things I talked about that have more to
do with the actual webserving side of things:
- Apache/Nginx Vhost configuration: allows you to map internal
"domains" like myapp.rails or myrailsapp.local or whatever flavor you
prefer to a certain directory with a certain interpreter. This allows
you to host your wiki on wiki.mycompany.local and your railsapp on
railsapp.mycompany.local.
- DNS configuration: in order for your internal desktop/laptop
computers to know about these domains, they need to be set up in the
DNS you are choosing (MacOS X server has BIND built-in and it has a
nice configuration utility called Server Admin to manage it). I myself
find the setup in OS X quite easy to get a hang of and if you can't
get a hang of it google should be your friend to figure out how to do
it. It's specific to your internal structure and there is no clearcut
answer as to how to do it. A DNS is basically a "post office" that
knows how to translate human readable URLs to network addresses. "Can
you tell me the address of myrailsapp.mycompany.local?" "Why yes sir,
you'll find him at 192.1.1.55". You can also configure the MacOS X
server DNS in its turn to pass on URLs it doesn't know about to for
example your ISPs DNS.
- Network settings through DHCP: most people use some kind of router,
whether that's a physical box or a service you run on a server to
configure clients on the network: assign IP addresses from either a
static pool or a dynamic pool, tell them which DNS to use (your ISP
will also have a DNS, but that one won't know about your internal
addresses of course). Again, this is going to depend on what you are
using internally and you'll have to search for documentation specific
to your setup in order to know how to configure it. Suppose you have
your OS X Server at 192.1.1.44, then you'll need to set your DHCP
server to tell the clients to set their DNS to 192.1.1.44.
If all of the above is sounding way too complicated or completely out
of your comfort zone and you don't want to invest time (and thus
probably billable hours aka money) in figuring out the nuts and bolts,
you should just hire someone that's comfortable with it. You'll have
to decide whether spending a couple of hundred bucks on a server admin
will be more cost effective than you spending a day or two figuring
out how your network needs to be set up (and you being able to adjust
things afterwards because you know how everything works of course).
I'll add as a last note that if you have the theoretical background on
how network setup and webserving work, it shouldn't take you all too
long to get things done.
I know this probably isn't the "download application X and run it and
everything magically will start working" or "here's a blog post I made
with step by step instructions on how to set up a web serving
infrastructure", but that's just because there is no "one way to rule
them all" information board out there. It seems you pretty much have a
setup in your company already, you'll need to (have someone) find out
how to glue everything together.
Best regards
Peter De Berdt
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
