03 May 2012, 09:51
Io001_pragsmall

Giuseppe Bertini (2 posts)

Hello, I have read the first few chapters of beta2 and repeatedly scrolled up and down the table of contents, and I cannot seem to find any reference on how to… er… DEPLOY MassiveApp.

What I mean is–everything seems to happen within the virtual boxes, but what if:

  • I do have a good ol’ box in the basement whirring away happily, which I intend to use as a staging server and pound on it night and day with all kinds of demanding tests
  • I have just acquired a fresh new Linode, and that’s where I want my MassiveApp to be hosted

What now? How do I automate setting up the two hosts so that they run identical instances of Ubuntu Precise Pangolin 32, packages, gems, and all?

The Vagrant mechanism only applies to virtual boxes, right? Or is it possible one way or another to push to a physical box or to a VPS a locally-built package? Or, do we perform a minimal install on each host, and rely entirely on puppet from then on?

I am assuming that the answers to my questions are already embedded in the existing structure of the book, and that I will simply know how to do these things once I have properly digested the material.

But, in my humble opinion, a short chapter describing how to get your app from the virtual to the real world would be reassuring.

Thanks and keep up the good work, Giuseppe

03 May 2012, 22:01
Tom_sq_150_pragsmall

Tom Copeland (78 posts)

Thanks for the feedback!

The actual deployment is described in the Capistrano chapter; by that time the hope is that the servers that you’re deploying to (Vagrant or otherwise) has been built out using Puppet as described in the Puppet on Rails chapter.

So the OS is set up by Linode, the directories (/var/massiveapp, etc) and services (mysql, apache) are set up by Puppet, and then the deployment happens via Capistrano.

18 May 2012, 02:29
Generic-user-small

Manu J (6 posts)

Can the server be bootstrapped completely? i.e how will ruby and puppet be installed in the server?

20 May 2012, 00:53
Tom_sq_150_pragsmall

Tom Copeland (78 posts)

I think it depends on your hosting provider. For example, for EC2, you could build an AMI with Puppet and Ruby and such installed, and then when you fire up a new box you could set the box role and Puppet would apply the appropriate manifests. I see Linode has some setup instructions on Puppet here: http://library.linode.com/application-stacks/puppet/installation

What you said in your first post is what I usually do: “do we perform a minimal install on each host, and rely entirely on puppet from then on?”

26 Sep 2012, 09:50
Generic-user-small

Niels Hamaker (1 post)

Hi there,

I just wanted to add my “+1” to Giuseppe’s remarks, and particularly the one about the additional chapter. I went through the book several times searching for this step into the real world: for me, the book feels incomplete without it. “Deploying Rails” is certainly useful and valuable as it is, but as there are so many sides to a Rails deployment, it can’t be expected to cover them all. Maybe an idea to write a “Deploying Rails: volume 2”? Covering moving to the real world, comparisons of Passenger and Unicorn, thin, apache and nginx, how to stress-test your app, etc.

27 Sep 2012, 21:38
Tom_sq_150_pragsmall

Tom Copeland (78 posts)

You’re right, deployment is a big topic, and scaling/infrastructure is a big part of it. But scaling also such an application-dependent thing that we didn’t feel comfortable in diving into that; we didn’t feel like we could write something that would be applicable to the all the various situations that people run into. I think we felt like we’d have to write something that was really general and wouldn’t answer anyone’s questions anyway.

So all that to say that we focused instead on how to automate, manage, and monitor your infrastructure whatever it is.

07 Nov 2012, 22:14
Tjc_pragsmall

Tim Chambers (1 post)

me too. I just wanted to add my “+1” to Giuseppe’s remarks. I was perhaps naively expecting more of a final production approach, although I feel I could extend what was already written to a physical box environment.

I feel as though I was left hanging and an additional explanation of Virtual to Physical would have been appropriate.

05 Mar 2013, 11:16
Generic-user-small

Craig Miles (1 post)

I have merrily worked through setting up virtual environments and had great success with Vagrant and VirtualBox, Puppet and Passenger. It was all an enlightenment to me and I feel much more knowledgeable about the whole area.

I had naively expected that all the work was done. Now that I have gone to great pains to set up and prove my configuration in the virtual world I was expecting to be able to just deploy my configuration to the “cloud”.

But when I thought about it more it dawned on me that I didnt really know how to apply this to the real world, a real server with a hosting provider.

So I spent a while on Google, and didnt arrive at any conclusion that the best or even a possible approach is to deploy a VB setup to the cloud somewhere.

Then I thought I must have missed this somewhere in the book, and looked again. Like others on this thread, I am left feeling that this is certainly missing. There is no clear instruction of how to proceed to a production environment.

The suggestion earlier in the thread that this is to be inferred by the Capistrano section leaves me confused, as this section appears to be geared totally to a virtual environment.

Am I therefore to conclude that having configured a virtual environment that the only way to proceed to production is to repeat all of the steps from scratch on the production environment?

If so, how then have the steps taken to produce an easily replicated virtual environment for testing benefited the move to production when I can still end up with entirely different configuration.

Maybe I have missed the point of what I had thought was the whole “Deploying Rails” mantra, one of repeatability, predictability and automation.

So I guess I am stating a much longer way of agreeing with Tim Chambers!

  You must be logged in to comment