Add support for installing rubies from attribute. #79
Conversation
I often have a need to just blanket install rubies on all of my web machines. I think this is a better approach than having a cookbook which basically just does this for me. Definitely open to suggesetions, though!
|
@johnbellone I don't think it's a good idea to include this in the It's a common pattern to install a ruby and some gems for a machine an application is running on and the right place for this is in a recipe within that application's cookbook. |
|
@reset I agree the Do you not think its a valid pattern or case to have a role with a specific ruby version and gems? For example an utility machine that would install Rubinius instead of an application machine which would install MRI. My thought was creating a "wrapper cookbook" (lack of a better word) to install a ruby and gems would be overkill. |
|
@johnbellone I think the correct pattern is to have your application's cookbook setup it's dependencies in the requiring recipe. For example: your "my_app::app_server" recipe would setup the ruby and the gems that you need while the "my_app::database_server" would setup postgres or whatever all else you need. A "wrapper" cookbook is something specific to your organization that set's default values and makes slight modifications as a whole to a service that your applications may leverage. A good example of this is a "{org}_postgres" cookbook which you would include as a dependency in your application cookbook instead of the standard postgres one. This would ensure that your app has the default values necessary instead of setting them in each application cookbook which requires postgres. In the patterns I talk about and advocate I always start at the application cookbook and move backwards. There is never a generic cookbook or role that is on the edge that people actually would touch or see. Instead everything is abstracted in a collection of application cookbooks. The example that you're providing where you would have Rubinius on all of your application servers instead of MRI would only bubble up as an application cookbook in this pattern if you were a hosting company and providing that as your service ;) Does this make sense? If you still feel the need to have a |
|
We've been mainly using this for solo and zero deployments because we are able to quickly modify the build in our Vagrantfile. I think it's useful but I definitely get where you are coming from. Well, I am developing some PaaS patterns for my firm so in that way ;). I am definitely interested in learning more about patterns. What cookbooks, videos or literature would you suggest? — On Sat, Nov 30, 2013 at 4:35 PM, Jamie Winsor [email protected]
|
|
@johnbellone I honestly think there's quite a bit of confusion around the patterns we've outlined over the last two years because there just is no definitive place to learn about them. I gave a talk at Chef Conf 2013 that covers the application and library cookbook pattern but it was just a short 45 minute presentation that had a lot of stuff to cover. The Food Fight show has always been the an awesome source of information and if you aren't listening I'd definitely start there. I think it's time to spend a bit of effort on a set of blog posts or video casts. |
|
I listen to the podcasts already. Going to submit one about Enterprise problems so it'd be great for me to start reading up. Appreciate it! As for the PR I think it has it's purpose but TBH I think rbenv itself is an anti- pattern on production. But since I have a few dependencies that rely on rbenv cookbook it's likely going to be difficult to break those patterns. — On Sat, Nov 30, 2013 at 4:51 PM, Jamie Winsor [email protected]
|
|
I am definitely game for helping on the blog post writing end :). — On Sat, Nov 30, 2013 at 5:12 PM, John Bellone [email protected]
|
|
@johnbellone for what it's worth, I also agree that compiling Ruby in production is an anti-pattern. I like to use this cookbook in combination with packer to get a nice production ready image without deploying any of my application's actual code to it. Then I use that image in AWS as a nice jumping point before deploying the actual application. |
|
@reset Fully agree with you there. My actual concern would have been solved just using Fletcher's cookbook, but I ran into problem with dependencies trying to hack together an internal Chef server with Berkshelf API. |
|
I have the exact same need. Those who are building chef cookbooks with resources only, like the sous-chef group, are missing the initial purpose of the cookbooks. Chef should introduce a new kind of cookbook, named like "libraries" for example, which would be resources only made for the use case where one creates a cookbook which uses those resources, which would solve the confusion that so many people have now. I'm looking for a cookbook -- and by that I mean: A cookbook -- which installs Ruby. I'm using it from a Policyfile where I can't use those resources (until someone show me how to) and I don't want to create a micro cookbook to just tell "install Ruby 3". Until Chef introduce the new kind of cookbook, the "library" one, cookbooks implementing resources should have recipes covering 80% of the cases, like in this case, installing Ruby. Sorry, I'm really desesperate with this useless confusing some have about cookbook ... The PR needs a rebase since 9 years, so @johnbellone would you mind giving a try ? 🙏 |
I often have a need to just blanket install rubies on all of my web
machines. I think this is a better approach than having a cookbook which
basically just does this for me. Definitely open to suggesetions, though!