Rails 3 and ruby 1.9.2 application with chef

Chef Infra (archive)
1

I have some questions about chef and Rails3 applications:

1 - What is the best way to create a Rails 3 application server using chef?

We’ve tried to use the application cookbook (
https://github.com/opscode/cookbooks/tree/master/application), but it is
not working. It creates the application in the rightdirectory, and it runs
unicorn and listen on port 8080, but when I try to access it, it doesnt
respond.

2 - As Rails 3 requires ruby >=1.9.2, how to configure the application
cookbook to use it?

3 - Is there any other working cookbook to use instead of application?

Thanks a lot

Daniel Cukier

2

On Tue, Apr 24, 2012 at 5:21 PM, Daniel Cukier danicuki@gmail.com wrote:

3 - Is there any other working cookbook to use instead of application?

Take a look at Andrea Campi's refactor of the application cookbook:
http://lists.opscode.com/sympa/arc/chef/2012-04/msg00329.html

Bryan

3

On Apr 24, 2012, at 3:21 PM, Daniel Cukier wrote:

I have some questions about chef and Rails3 applications:

1 - What is the best way to create a Rails 3 application server using chef?

We've tried to use the application cookbook (https://github.com/opscode/cookbooks/tree/master/application), but it is not working. It creates the application in the rightdirectory, and it runs unicorn and listen on port 8080, but when I try to access it, it doesnt respond.

2 - As Rails 3 requires ruby >=1.9.2, how to configure the application cookbook to use it?

Rails 3 requires ruby >= 1.8.7. So you don't strictly need 1.9.2. But if you can, I would recommend using 1.9.2 (1.9.3 is even better).

3 - Is there any other working cookbook to use instead of application?

Thanks a lot

Daniel Cukier

4

Hi Wes! Thanks for you answer.

How to configure chef to use ruby 1.9.3 instead of 1.8.7?

On Tue, Apr 24, 2012 at 6:32 PM, Wes Morgan cap10morgan@gmail.com wrote:

On Apr 24, 2012, at 3:21 PM, Daniel Cukier wrote:

I have some questions about chef and Rails3 applications:

1 - What is the best way to create a Rails 3 application server using chef?

We've tried to use the application cookbook (
https://github.com/opscode/cookbooks/tree/master/application), but it is
not working. It creates the application in the rightdirectory, and it runs
unicorn and listen on port 8080, but when I try to access it, it doesnt
respond.

2 - As Rails 3 requires ruby >=1.9.2, how to configure the application
cookbook to use it?

Rails 3 requires ruby >= 1.8.7. So you don't strictly need 1.9.2. But if
you can, I would recommend using 1.9.2 (1.9.3 is even better).

Ruby on Rails 3.0 Release Notes — Ruby on Rails Guides

3 - Is there any other working cookbook to use instead of application?

Thanks a lot

Daniel Cukier

--
Daniel Cukier
Software Artist
+55 11 9991-3913

5

If you use omnibus to install chef, it's already being installed into
a ruby 1.9x embedded container.

I'd recommend using the ruby cookbook, and setting the attributes so
that it installs ruby1.9.x -- it'll end up in your standard system
location; then any other service you can deploy will use that ruby due
to it being in $PATH.

At Heavy Water, we have our continuous delivery platform build a Ruby
artefact for the architectures being used in the deployment with a
custom cookbook (instead of the opscode Ruby) to deploy that.
Eventually we may try to work in compatibility there.

We've had a little trouble with this route when you need to install
gems with gem_package into either VM, but it's easily worked around
with the gem_binary parameter.

Cheers,

--AJ

On 25 April 2012 13:23, Daniel Cukier danicuki@gmail.com wrote:

Hi Wes! Thanks for you answer.

How to configure chef to use ruby 1.9.3 instead of 1.8.7?

On Tue, Apr 24, 2012 at 6:32 PM, Wes Morgan cap10morgan@gmail.com wrote:

On Apr 24, 2012, at 3:21 PM, Daniel Cukier wrote:

I have some questions about chef and Rails3 applications:

1 - What is the best way to create a Rails 3 application server using
chef?

We've tried to use the application cookbook
(https://github.com/opscode/cookbooks/tree/master/application), but it is
not working. It creates the application in the rightdirectory, and it runs
unicorn and listen on port 8080, but when I try to access it, it doesnt
respond.

2 - As Rails 3 requires ruby >=1.9.2, how to configure the application
cookbook to use it?

Rails 3 requires ruby >= 1.8.7. So you don't strictly need 1.9.2. But if
you can, I would recommend using 1.9.2 (1.9.3 is even better).

http://edgeguides.rubyonrails.org/3_0_release_notes.html#rails-3-requires-at-least-ruby-1-8-7

3 - Is there any other working cookbook to use instead of application?

Thanks a lot

Daniel Cukier

--
Daniel Cukier
Software Artist
+55 11 9991-3913

6

On Apr 24, 2012, at 7:43 PM, AJ Christensen wrote:

If you use omnibus to install chef, it's already being installed into
a ruby 1.9x embedded container.

I'd recommend using the ruby cookbook, and setting the attributes so
that it installs ruby1.9.x -- it'll end up in your standard system
location; then any other service you can deploy will use that ruby due
to it being in $PATH.

Doesn't the ruby cookbook only know how to install the distro packaged Ruby versions? On Ubuntu, that means Ruby 1.9.1, which won't work with Rails 3. Ruby 1.9.2+ or Ruby 1.8.7 is required (so I got that slightly wrong before).

I ended up using the rbenv cookbook to install 1.9.3.

At Heavy Water, we have our continuous delivery platform build a Ruby
artefact for the architectures being used in the deployment with a
custom cookbook (instead of the opscode Ruby) to deploy that.
Eventually we may try to work in compatibility there.

We've had a little trouble with this route when you need to install
gems with gem_package into either VM, but it's easily worked around
with the gem_binary parameter.

Cheers,

--AJ

** snip **

7

Yo,

The packages say ruby1.9.1 but they're 1.9.2-someshit~crapubuntu101

Package: ruby1.9.1-full (1.9.2.290-2) [universe]

http://packages.ubuntu.com/oneiric/ruby1.9.1-full

I've had no trouble running Rails on them as an interim solution
between deploying a slightly more controlled Ruby VM installation.

--AJ

On 25 April 2012 13:49, Wes Morgan cap10morgan@gmail.com wrote:

On Apr 24, 2012, at 7:43 PM, AJ Christensen wrote:

If you use omnibus to install chef, it's already being installed into
a ruby 1.9x embedded container.

I'd recommend using the ruby cookbook, and setting the attributes so
that it installs ruby1.9.x -- it'll end up in your standard system
location; then any other service you can deploy will use that ruby due
to it being in $PATH.

Doesn't the ruby cookbook only know how to install the distro packaged Ruby versions? On Ubuntu, that means Ruby 1.9.1, which won't work with Rails 3. Ruby 1.9.2+ or Ruby 1.8.7 is required (so I got that slightly wrong before).

I ended up using the rbenv cookbook to install 1.9.3.

At Heavy Water, we have our continuous delivery platform build a Ruby
artefact for the architectures being used in the deployment with a
custom cookbook (instead of the opscode Ruby) to deploy that.
Eventually we may try to work in compatibility there.

We've had a little trouble with this route when you need to install
gems with gem_package into either VM, but it's easily worked around
with the gem_binary parameter.

Cheers,

--AJ

** snip **

8

Yo,

On 25 April 2012 13:49, Wes Morgan cap10morgan@gmail.com wrote:

On Apr 24, 2012, at 7:43 PM, AJ Christensen wrote:

If you use omnibus to install chef, it's already being installed into
a ruby 1.9x embedded container.

I'd recommend using the ruby cookbook, and setting the attributes so
that it installs ruby1.9.x -- it'll end up in your standard system
location; then any other service you can deploy will use that ruby due
to it being in $PATH.

Doesn't the ruby cookbook only know how to install the distro packaged Ruby versions? On Ubuntu, that means Ruby 1.9.1, which won't work with Rails 3. Ruby 1.9.2+ or Ruby 1.8.7 is required (so I got that slightly wrong before).

I ended up using the rbenv cookbook to install 1.9.3.

It would be my complete and total recommendation to seek not the
installation of compilers to build huge Language packages.

You can easily manage this process out of band (once or repeatedly)
and publish them to all nodes through very well suited package
distribution channels.

--AJ

At Heavy Water, we have our continuous delivery platform build a Ruby
artefact for the architectures being used in the deployment with a
custom cookbook (instead of the opscode Ruby) to deploy that.
Eventually we may try to work in compatibility there.

We've had a little trouble with this route when you need to install
gems with gem_package into either VM, but it's easily worked around
with the gem_binary parameter.

Cheers,

--AJ

** snip **

9

Bryan, I've looked to this refactor, but actually I did not find a good
documentation of how to use it.

From what I've understood, I need to create a cookbook for my_app and add
the application code block to the default.rb of my cookbook. Is it correct?

If it is so, then it is worse than before, when all I needed to do was
create a data_bag, put some configuration there and create a my_app role
with the application default recipe in its run_list.

Another thing is: with this new refactor, do I still need to add the
application recipe to the node run_list?

Could you help me with a step-by-step of what do I have to do to change my
old application cookbook to the new one?

Thanks so much

Daniel

On Tue, Apr 24, 2012 at 6:29 PM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Apr 24, 2012 at 5:21 PM, Daniel Cukier danicuki@gmail.com wrote:

3 - Is there any other working cookbook to use instead of application?

Take a look at Andrea Campi's refactor of the application cookbook:
chef - [chef] Application cookbook refactoring

Bryan

--
Daniel Cukier
Software Artist
+55 11 9991-3913

10

Hello Team

Please do the needful.

On 25 April 2012 14:22, Daniel Cukier danicuki@gmail.com wrote:

Bryan, I've looked to this refactor, but actually I did not find a good
documentation of how to use it.

From what I've understood, I need to create a cookbook for my_app and add
the application code block to the default.rb of my cookbook. Is it correct?

If it is so, then it is worse than before, when all I needed to do was
create a data_bag, put some configuration there and create a my_app role
with the application default recipe in its run_list.

Another thing is: with this new refactor, do I still need to add the
application recipe to the node run_list?

Could you help me with a step-by-step of what do I have to do to change my
old application cookbook to the new one?

Thanks so much

Daniel

On Tue, Apr 24, 2012 at 6:29 PM, Bryan McLellan btm@loftninjas.org wrote:

On Tue, Apr 24, 2012 at 5:21 PM, Daniel Cukier danicuki@gmail.com wrote:

3 - Is there any other working cookbook to use instead of application?

Take a look at Andrea Campi's refactor of the application cookbook:
chef - [chef] Application cookbook refactoring

Bryan

--
Daniel Cukier
Software Artist
+55 11 9991-3913

11

On Apr 24, 2012, at 7:55 PM, AJ Christensen aj@junglist.gen.nz wrote:

Yo,

On 25 April 2012 13:49, Wes Morgan cap10morgan@gmail.com wrote:

On Apr 24, 2012, at 7:43 PM, AJ Christensen wrote:

If you use omnibus to install chef, it's already being installed into
a ruby 1.9x embedded container.

I'd recommend using the ruby cookbook, and setting the attributes so
that it installs ruby1.9.x -- it'll end up in your standard system
location; then any other service you can deploy will use that ruby due
to it being in $PATH.

Doesn't the ruby cookbook only know how to install the distro packaged Ruby versions? On Ubuntu, that means Ruby 1.9.1, which won't work with Rails 3. Ruby 1.9.2+ or Ruby 1.8.7 is required (so I got that slightly wrong before).

I ended up using the rbenv cookbook to install 1.9.3.

It would be my complete and total recommendation to seek not the
installation of compilers to build huge Language packages.

I don't have many servers, and this only needs to be done once, at
bootstrap time. It got me up and running quickly with a much newer,
faster Ruby than Ubuntu's packages.

You can easily manage this process out of band (once or repeatedly)
and publish them to all nodes through very well suited package
distribution channels.

Which would make sense if I had more servers or needed to do this more
often. In this case it's far simpler to just build ruby 1.9.3 via
ruby-build during bootstrapping.

--AJ

At Heavy Water, we have our continuous delivery platform build a Ruby
artefact for the architectures being used in the deployment with a
custom cookbook (instead of the opscode Ruby) to deploy that.
Eventually we may try to work in compatibility there.

We've had a little trouble with this route when you need to install
gems with gem_package into either VM, but it's easily worked around
with the gem_binary parameter.

Cheers,

--AJ

** snip **

12

I am traveling at the moment, and I am on GMT+8, so I may reply to
this and other threads with quite a bit of latency...

On Wed, Apr 25, 2012 at 10:22 AM, Daniel Cukier danicuki@gmail.com wrote:

Bryan, I've looked to this refactor, but actually I did not find a good
documentation of how to use it.

Interesting. The documentation is one of the areas I am looking for feedback on.
If you can spare a few minutes, can you elaborate on what you find
unclear in the documentation? Here or private email.

I guess a "how to convert from the old version" tutorial, as you
suggest, would be helpful.

From what I've understood, I need to create a cookbook for my_app and add
the application code block to the default.rb of my cookbook. Is it correct?

That's correct.

If it is so, then it is worse than before, when all I needed to do was
create a data_bag, put some configuration there and create a my_app role
with the application default recipe in its run_list.

To be clear: I don't think removal of the data bag was a goal of the
project, it's more of a side casualty.

Data bags are not very expressive; while it was pretty easy to get
started, people with more advanced use cases kept bumping into
limitations. For example, some attributes were per-environment, some
weren't.

Since the new DSL is more complete and powerful than the old recipe,
it would be quite hard to create a purely data bag-driven mode that is
useful and generic for everybody.

On the other hand, it's pretty easy to roll your own, as Joshua has
demonstrated: chef - [chef] Re: Re: Application cookbook refactoring
Nobody knows what you need better than you, so if you'd rather use a
data bag I suggest you look into that approach.

Another thing is: with this new refactor, do I still need to add the
application recipe to the node run_list?

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.
Moreover, the application::default recipe (and the stack-specific
ones) will be deprecated. Once you are done converting all your apps
to the "new style", you should remove that recipe from the run_list.
We will be keeping backward compatibility, with a deprecation warning,
for about 3 months.

13

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.

It is application_ruby or application_rails? I'm confused... :slight_smile:

On Wed, Apr 25, 2012 at 1:51 AM, Andrea Campi
andrea.campi@zephirworks.comwrote:

I am traveling at the moment, and I am on GMT+8, so I may reply to
this and other threads with quite a bit of latency...

On Wed, Apr 25, 2012 at 10:22 AM, Daniel Cukier danicuki@gmail.com
wrote:

Bryan, I've looked to this refactor, but actually I did not find a good
documentation of how to use it.

Interesting. The documentation is one of the areas I am looking for
feedback on.
If you can spare a few minutes, can you elaborate on what you find
unclear in the documentation? Here or private email.

I guess a "how to convert from the old version" tutorial, as you
suggest, would be helpful.

From what I've understood, I need to create a cookbook for my_app and add
the application code block to the default.rb of my cookbook. Is it
correct?

That's correct.

If it is so, then it is worse than before, when all I needed to do was
create a data_bag, put some configuration there and create a my_app role
with the application default recipe in its run_list.

To be clear: I don't think removal of the data bag was a goal of the
project, it's more of a side casualty.

Data bags are not very expressive; while it was pretty easy to get
started, people with more advanced use cases kept bumping into
limitations. For example, some attributes were per-environment, some
weren't.

Since the new DSL is more complete and powerful than the old recipe,
it would be quite hard to create a purely data bag-driven mode that is
useful and generic for everybody.

On the other hand, it's pretty easy to roll your own, as Joshua has
demonstrated:
chef - [chef] Re: Re: Application cookbook refactoring
Nobody knows what you need better than you, so if you'd rather use a
data bag I suggest you look into that approach.

Another thing is: with this new refactor, do I still need to add the
application recipe to the node run_list?

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.
Moreover, the application::default recipe (and the stack-specific
ones) will be deprecated. Once you are done converting all your apps
to the "new style", you should remove that recipe from the run_list.
We will be keeping backward compatibility, with a deprecation warning,
for about 3 months.

--
Daniel Cukier
Software Artist
+55 11 9991-3913

14

When I try

knife cookbook site vendor application_ruby

or

knife cookbook site vendor application_rails

both do not work...

Daniel

On Wed, Apr 25, 2012 at 9:22 AM, Daniel Cukier danicuki@gmail.com wrote:

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.

It is application_ruby or application_rails? I'm confused... :slight_smile:

On Wed, Apr 25, 2012 at 1:51 AM, Andrea Campi <
andrea.campi@zephirworks.com> wrote:

I am traveling at the moment, and I am on GMT+8, so I may reply to
this and other threads with quite a bit of latency...

On Wed, Apr 25, 2012 at 10:22 AM, Daniel Cukier danicuki@gmail.com
wrote:

Bryan, I've looked to this refactor, but actually I did not find a good
documentation of how to use it.

Interesting. The documentation is one of the areas I am looking for
feedback on.
If you can spare a few minutes, can you elaborate on what you find
unclear in the documentation? Here or private email.

I guess a "how to convert from the old version" tutorial, as you
suggest, would be helpful.

From what I've understood, I need to create a cookbook for my_app and
add
the application code block to the default.rb of my cookbook. Is it
correct?

That's correct.

If it is so, then it is worse than before, when all I needed to do was
create a data_bag, put some configuration there and create a my_app role
with the application default recipe in its run_list.

To be clear: I don't think removal of the data bag was a goal of the
project, it's more of a side casualty.

Data bags are not very expressive; while it was pretty easy to get
started, people with more advanced use cases kept bumping into
limitations. For example, some attributes were per-environment, some
weren't.

Since the new DSL is more complete and powerful than the old recipe,
it would be quite hard to create a purely data bag-driven mode that is
useful and generic for everybody.

On the other hand, it's pretty easy to roll your own, as Joshua has
demonstrated:
chef - [chef] Re: Re: Application cookbook refactoring
Nobody knows what you need better than you, so if you'd rather use a
data bag I suggest you look into that approach.

Another thing is: with this new refactor, do I still need to add the
application recipe to the node run_list?

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.
Moreover, the application::default recipe (and the stack-specific
ones) will be deprecated. Once you are done converting all your apps
to the "new style", you should remove that recipe from the run_list.
We will be keeping backward compatibility, with a deprecation warning,
for about 3 months.

--
Daniel Cukier
Software Artist
+55 11 9991-3913

--
Daniel Cukier
Software Artist
+55 11 9991-3913

15

If your cookbook correctly depends on application and
application_rails (if it's a Rails app), you don't need to explicitly
include the application cookbook.

It is application_ruby or application_rails? I'm confused... :slight_smile:

Indeed it is application_ruby

On Wed, Apr 25, 2012 at 8:50 PM, Daniel Cukier danicuki@gmail.com wrote:

When I try

knife cookbook site vendor application_ruby

or

knife cookbook site vendor application_rails

both do not work...

These are not yet on the community website; not until we are satisfied
with this work and ready to go live.
You will need to check them out from their github repo; how you do
that depends on your workflow.

Andrea