Staging and Production on same server?

[Gaius]

I have deployed several intranet applications with the staging and
production versions running on the same server. I've used Passenger
with different directories, and everything seemed to go smoothly.

I'm trying to get up to speed on an application that is available to
the public Internet. One of the problems is that there is no staging
environment. Does anyone have any horror stories about putting staging
and production on the same server? The production version won't ever
be getting millions of hits every day - probably a few thousand at the
most.

[Nick Quaranto]

Disclaimer: I'm not a sysadmin, and for good reasons, too.

Gemcutter had a staging and production versions on the same machine until a few weeks ago, when we got a small SliceHost instance set up with it. It really wasn't a problem to run both on the same box. 

The big deal is when you want to try out new setups and not affect the production environment. Once we had a separate staging server we upgraded to Passenger 2.2.9 and REE, worked out the kinks in doing that upgrade, and were confident the production environment would go smoothly.

-Nick

--
You received this message because you are subscribed to the Boston Ruby Group mailing list
To post to this group, send email to boston-r...@googlegroups.com
To unsubscribe from this group, send email to boston-rubygro...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/boston-rubygroup

[Ronald Cotoni]

On Wed, Feb 17, 2010 at 4:45 PM, Gaius <james....@gmail.com> wrote:

> --
> You received this message because you are subscribed to the Boston Ruby Group mailing list
> To post to this group, send email to boston-r...@googlegroups.com
> To unsubscribe from this group, send email to boston-rubygro...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/boston-rubygroup

I can think of some horror stories. Your staging environment causing
your machine to run out of memory by some misconfiguration or
something along those lines. Best thing to do is run a staging
environment on a local VM or setup your server with
VMWare/Xen/VirtualBox and run two vms, one for production and one for
staging and make sure neither can take over all available resources.
Examples of how this is beneficial, updating system level apps. What
if you need to update something in the staging environment but not in
the production environment. What if your staging environment requires
a different version of Ruby, a global app or a library. If you run a
local staging environment, it is cheap and free. You can also set
your hosts file to connect to that instead of the real production
instance. Just remember to change it back when you are done.

[Wyatt Greene]

For an app that I'm hosting I decided to use two separate Linode VPSs:
one for staging and one for production. Linodes start out at $20/
month, so it's not expensive to have a separate staging server. The
bigger expense is the time it takes you to set up two servers.

The engineer in me likes to keep them separate. It somehow feels
safer. If that new feature that I deploy to staging has some crazy
side effect like deleting data or hogging resources, my production app
isn't affected. Also, there are different security concerns for the
staging server and the production server. Another advantage would be
if you wanted to do some load testing on a production-like
environment. You could do it on your separate staging server.

However, a disadvantage is that when you upgrade/install software you
have to do it twice. Also, there is the chance that the
configurations of the production server and the staging server drift
apart, which makes the staging server less useful for testing your
code in a production-like environment.

Cheers,
Wyatt

On Feb 17, 2010, at 4:57 PM, Ronald Cotoni wrote:

> On Wed, Feb 17, 2010 at 4:45 PM, Gaius <james....@gmail.com>
> wrote:
>> I have deployed several intranet applications with the staging and
>> production versions running on the same server. I've used Passenger
>> with different directories, and everything seemed to go smoothly.
>>
>> I'm trying to get up to speed on an application that is available to
>> the public Internet. One of the problems is that there is no staging
>> environment. Does anyone have any horror stories about putting
>> staging
>> and production on the same server? The production version won't ever
>> be getting millions of hits every day - probably a few thousand at
>> the
>> most.
>>
>> --
>> You received this message because you are subscribed to the Boston
>> Ruby Group mailing list
>> To post to this group, send email to boston-

>> ruby...@googlegroups.com

[Josh Nichols]

Please don't do that.

Part of the point of staging is to have a facsimile of production
where you can test changes out. Beyond just code, this would include
things like versions of ruby, mysql, library dependencies, etc, etc,
basically anything that affects how your application runs.

By having staging == production, anytime you change the server, you'd
be affecting both staging and production.

At Rails Machine, we generally encourage people to use separate
servers for each application, and for each stage (ie production vs
staging). This lets you isolate your environments fully.

On Wed, Feb 17, 2010 at 4:45 PM, Gaius <james....@gmail.com> wrote:

[Josh Nichols]

Inline.

On Wed, Feb 17, 2010 at 5:11 PM, Wyatt Greene <techi...@gmail.com> wrote:
> However, a disadvantage is that when you upgrade/install software you have
> to do it twice.  Also, there is the chance that the configurations of the
> production server and the staging server drift apart, which makes the
> staging server less useful for testing your code in a production-like
> environment.

I was actually going to address this in a talk I was planning for next
month. Basically, managing stuff like this stuff by hand sucks, but
automating it is awesome.

In particular, I was going to demonstrate using moonshine for managing
your deployment environments, without having the hassle of having to
manually keep the environments in sync.

http://github.com/railsmachine/moonshine

[Wyatt Greene]

I would be very much interested in hearing about moonshine.

Also, Linode recently came out with StackScripts (they are like Rails
application templates for servers). But they are Linode-specific. http://blog.linode.com/2010/02/09/introducing-stackscripts/

[Gaius]

The problem is that getting another server set up is an absolute
nightmare. The customer requires that all code run on their machines,
and the process for getting another one up and running with a public
IP address will likely take months.

I can, of course, do some internal staging, but that won't be publicly-
addressable, so I won't be able to get good feedback. It will give me
good information about deployment, though.

I definitely appreciate the concerns with being able to try out new
configurations. That is going to take some ... work.

[Wyatt Greene]

It's all about costs, benefits, and risks. In my case, the cost of
another server was low. In your case, though, it might make more
sense to have both the production and staging environments on one
machine if you're comfortable with the increased risks (make sure you
have a good backup and restore process!). Perhaps you could install
virtualization software so you can still have two separate servers on
the one machine?

[Gaius]

The virtualization idea might work. It'll take a while to set up, but
definitely less than a whole new box. Definitely worth considering!

[Victor Costan]

Perhaps you can set up a reverse proxy from the production box with a
public IP to the staging box? If the production box also has an
internal IP, this should work, right?

Victor

[Vikram Kumar]

I believe in keeping the staging and production environments separate.

It actually reduces the time and effort if you think about it for a small cost. The ports, directories, rc.d/init.d scripts can be identical between the two. If they are colocated, you have to separate every nitty-gritty detail.

It also gives you a chance to test maintenance scripts and deployment tasks which your local box might not be able to handle.

Keeping them in sync is an effort. But if you get into the habit of always staging first before going production, then it gets easier.

Vikram

--
- Vikram

[Gaius]

Vikram: that's a great point. On previous deploys with this pattern I
have rc.d.dev and rc.d.prod, and likewise for init.d and others. I
keep those all in the project version control and symlink on redeploy
to keep things from getting _too_ bad. Still, it's a pain when it
doesn't really have to be.

On Feb 17, 7:05 pm, Vikram Kumar <vikrambku...@gmail.com> wrote:
> I believe in keeping the staging and production environments separate.
>
> It actually reduces the time and effort if you think about it for a small
> cost. The ports, directories, rc.d/init.d scripts can be identical between
> the two. If they are colocated, you have to separate every nitty-gritty
> detail.
>
> It also gives you a chance to test maintenance scripts and deployment tasks
> which your local box might not be able to handle.
>
> Keeping them in sync is an effort. But if you get into the habit of always
> staging first before going production, then it gets easier.
>
> Vikram
>
>
>
> On Wed, Feb 17, 2010 at 6:49 PM, Victor Costan <cos...@gmail.com> wrote:
> > Perhaps you can set up a reverse proxy from the production box with a
> > public IP to the staging box? If the production box also has an
> > internal IP, this should work, right?
>
> >    Victor
>