Should I be using chef?

Chef Infra (archive)
1

Hi,

I’ve read a bit about chef and I tried the tutorials in
http://devops.mashion.net/. after following the installation instructions
on the site. I was able to follow it and see chef in action which is great.
After this, I can see an usage on managing server configs, which I want to
do on a future. For now, I was wondering if I could use chef to "manage"
developers environment like, installing and configuring eclipse, cvs, java
and whatever a developer might need to work.

I know this is possible with chef for what I have seen. But is this usual?
Or I am trying to use the tool for something it is not really made for?

Thanks

Kelly

2

On Monday, December 26, 2011 at 10:57 AM, Kelly Goedert wrote:

Hi,

I've read a bit about chef and I tried the tutorials in http://devops.mashion.net/. after following the installation instructions on the site. I was able to follow it and see chef in action which is great. After this, I can see an usage on managing server configs, which I want to do on a future. For now, I was wondering if I could use chef to "manage" developers environment like, installing and configuring eclipse, cvs, java and whatever a developer might need to work.

I know this is possible with chef for what I have seen. But is this usual? Or I am trying to use the tool for something it is not really made for?
The overwhelming majority of Chef users are using Chef to manage servers, but it also works quite well for developer setup. At Opscode we use Chef to manage our developer workstations, and this has dramatically reduced the amount of setup time required for a new developer to get a test environment running. Pivotal Labs also uses Chef to manage workstations[1].

To my knowledge, most people managing workstations are using chef-solo, with developers updating the recipes at their leisure. This implies that your developers would get comfortable with basic Chef usage, but if workstation setup is a one-shot deal this isn't strictly required.

Thanks

Kelly

  1. http://pivotallabs.com/users/cunnie/blog/articles/1872-got-lion-now-get-everything-else-

HTH,

--
Dan DeLeo

3

Thank you... helped me a lot

On Mon, Dec 26, 2011 at 4:34 PM, Daniel DeLeo dan@kallistec.com wrote:

On Monday, December 26, 2011 at 10:57 AM, Kelly Goedert wrote:

Hi,

I've read a bit about chef and I tried the tutorials in
http://devops.mashion.net/. after following the installation instructions
on the site. I was able to follow it and see chef in action which is great.
After this, I can see an usage on managing server configs, which I want to
do on a future. For now, I was wondering if I could use chef to "manage"
developers environment like, installing and configuring eclipse, cvs, java
and whatever a developer might need to work.

I know this is possible with chef for what I have seen. But is this
usual? Or I am trying to use the tool for something it is not really made
for?
The overwhelming majority of Chef users are using Chef to manage servers,
but it also works quite well for developer setup. At Opscode we use Chef to
manage our developer workstations, and this has dramatically reduced the
amount of setup time required for a new developer to get a test environment
running. Pivotal Labs also uses Chef to manage workstations[1].

To my knowledge, most people managing workstations are using chef-solo,
with developers updating the recipes at their leisure. This implies that
your developers would get comfortable with basic Chef usage, but if
workstation setup is a one-shot deal this isn't strictly required.

Thanks

Kelly

http://pivotallabs.com/users/cunnie/blog/articles/1872-got-lion-now-get-everything-else-

HTH,

--
Dan DeLeo

4

On Dec 26, 2011, at 12:34 PM, Daniel DeLeo wrote:

To my knowledge, most people managing workstations are using chef-solo, with developers updating the recipes at their leisure. This implies that your developers would get comfortable with basic Chef usage, but if workstation setup is a one-shot deal this isn't strictly required.

We're using Chef for our servers, but we're also going to be using Chef for our development systems. We'll install those machines just like regular servers (so that the developers get a working copy of a production system). but once we've done the initial install what we will be doing is removing the roles & recipes from the run_list that pertain to the development they're doing.

So, as I add new stuff to our "role[base]", it will get incorporated out onto all machines, both production and development, and those development machines will continue to stay current on the configuration for everything except what the developer is actually working on.

I do believe that this is the "best of both worlds" combination.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

5

Brad,

How do you mange your validator PEM? Do you end up doing the
initial install for the developers and put the PEM on manually, or do
you openly share the validator within your organization?

We're testing out using Vagrant instances for developers that get
built with our normal chef cookbooks. I'd love to just be able to
point people at a wiki page of instructions and let it be self-serve.

Thanks,
Jake.

On Mon, Dec 26, 2011 at 3:22 PM, Brad Knowles bknowles@ihiji.com wrote:

On Dec 26, 2011, at 12:34 PM, Daniel DeLeo wrote:

To my knowledge, most people managing workstations are using chef-solo, with developers updating the recipes at their leisure. This implies that your developers would get comfortable with basic Chef usage, but if workstation setup is a one-shot deal this isn't strictly required.

We're using Chef for our servers, but we're also going to be using Chef for our development systems. We'll install those machines just like regular servers (so that the developers get a working copy of a production system). but once we've done the initial install what we will be doing is removing the roles & recipes from the run_list that pertain to the development they're doing.

So, as I add new stuff to our "role[base]", it will get incorporated out onto all machines, both production and development, and those development machines will continue to stay current on the configuration for everything except what the developer is actually working on.

I do believe that this is the "best of both worlds" combination.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

6

On Dec 27, 2011, at 9:31 AM, Jake Vanderdray wrote:

How do you mange your validator PEM? Do you end up doing the
initial install for the developers and put the PEM on manually, or do
you openly share the validator within your organization?

That's shared openly by all systems and users in the company. Of course, we're a small shop -- seven people at the moment, although I understand that they're looking to fill some positions. And of those, not all are developers. Of the developers we have, most aren't doing much of anything at all with Chef -- as the Ops guy, I'm the primary one doing most of the work with Chef.

Pretty much all of our systems are (or will be) VMs "in the cloud". Our developers do have local machines that they work from, but those are primarily used as a place to jump off into the actual development work that is done elsewhere.

To be honest, if you're using a Chef-managed environment, I don't see how you can avoid sharing the validator PEM amongst all systems. For those people who are developers but who don't need root access to their development machines, I could see where they wouldn't have open access to the validator PEM, but everyone doing anything with Chef would need to have access.

We're testing out using Vagrant instances for developers that get
built with our normal chef cookbooks. I'd love to just be able to
point people at a wiki page of instructions and let it be self-serve.

We could use vagrant, but we really want to get away from having any physical hardware that we have to manage, beyond the desktops that each person sits in front of -- and they're mostly responsible for managing those machines.

We do have a server with a few VMs loaded on it, and that machine has been used for some development to date, but going forward I think we're going to get away from that.

Of course, in a larger shop, I could see where our flat development architecture wouldn't necessarily work so well.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

7

We split Dev/testing/qa and staging/production into separate
organizations. We lock down access to production quite tightly but
five open access to everything else. This also allows us to lock down
what is in production a bit more so we don't have accidental
migrations of code and recipes to prod.

Not sure if this is the optimal way, but it is what we are currently
doing (and always looking for ways to improve!)
Adam

Adam Greene
Diabetes Data Management, Simplified

SweetSpot Diabetes Care, Inc.
http:/www.SweetSpotDiabetes.com
ph: 503.922.2223 | cell: 503.784.2104

On Dec 27, 2011, at 10:45 AM, Brad Knowles bknowles@ihiji.com wrote:

On Dec 27, 2011, at 9:31 AM, Jake Vanderdray wrote:

How do you mange your validator PEM? Do you end up doing the
initial install for the developers and put the PEM on manually, or do
you openly share the validator within your organization?

That's shared openly by all systems and users in the company. Of course, we're a small shop -- seven people at the moment, although I understand that they're looking to fill some positions. And of those, not all are developers. Of the developers we have, most aren't doing much of anything at all with Chef -- as the Ops guy, I'm the primary one doing most of the work with Chef.

Pretty much all of our systems are (or will be) VMs "in the cloud". Our developers do have local machines that they work from, but those are primarily used as a place to jump off into the actual development work that is done elsewhere.

To be honest, if you're using a Chef-managed environment, I don't see how you can avoid sharing the validator PEM amongst all systems. For those people who are developers but who don't need root access to their development machines, I could see where they wouldn't have open access to the validator PEM, but everyone doing anything with Chef would need to have access.

We're testing out using Vagrant instances for developers that get
built with our normal chef cookbooks. I'd love to just be able to
point people at a wiki page of instructions and let it be self-serve.

We could use vagrant, but we really want to get away from having any physical hardware that we have to manage, beyond the desktops that each person sits in front of -- and they're mostly responsible for managing those machines.

We do have a server with a few VMs loaded on it, and that machine has been used for some development to date, but going forward I think we're going to get away from that.

Of course, in a larger shop, I could see where our flat development architecture wouldn't necessarily work so well.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

8

It would be nice if Chef supported multiple validation keys and had ACL
support. Possibly something similar to how Amazon does
IAMhttp://aws.amazon.com/iam/policies.

Brad,

For now you could always pre-generate a pool of client/node keys if you
really need to keep your validation key secret.

Fellow Austinite - Charles

On Tue, Dec 27, 2011 at 9:45 AM, Brad Knowles bknowles@ihiji.com wrote:

On Dec 27, 2011, at 9:31 AM, Jake Vanderdray wrote:

How do you mange your validator PEM? Do you end up doing the
initial install for the developers and put the PEM on manually, or do
you openly share the validator within your organization?

That's shared openly by all systems and users in the company. Of course,
we're a small shop -- seven people at the moment, although I understand
that they're looking to fill some positions. And of those, not all are
developers. Of the developers we have, most aren't doing much of anything
at all with Chef -- as the Ops guy, I'm the primary one doing most of the
work with Chef.

Pretty much all of our systems are (or will be) VMs "in the cloud". Our
developers do have local machines that they work from, but those are
primarily used as a place to jump off into the actual development work that
is done elsewhere.

To be honest, if you're using a Chef-managed environment, I don't see how
you can avoid sharing the validator PEM amongst all systems. For those
people who are developers but who don't need root access to their
development machines, I could see where they wouldn't have open access to
the validator PEM, but everyone doing anything with Chef would need to have
access.

We're testing out using Vagrant instances for developers that get
built with our normal chef cookbooks. I'd love to just be able to
point people at a wiki page of instructions and let it be self-serve.

We could use vagrant, but we really want to get away from having any
physical hardware that we have to manage, beyond the desktops that each
person sits in front of -- and they're mostly responsible for managing
those machines.

We do have a server with a few VMs loaded on it, and that machine has been
used for some development to date, but going forward I think we're going to
get away from that.

Of course, in a larger shop, I could see where our flat development
architecture wouldn't necessarily work so well.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

--
Charles Sullivan
charlie.sullivan@gmail.com

9

There's an FAQ with a recommended approach for managing individual
credentials and knife.rb when multiple developers will be using the same
chef-repo.

http://wiki.opscode.com/display/chef/Troubleshooting+and+Technical+FAQ#TroubleshootingandTechnicalFAQ-Istherearecommendedapproachformanagingindividualcredentialsandknife.rbwhenmultipledeveloperswillbeusingthesamechefrepo%3F

Perhaps that will be of use to you.

  • Tom

On Tue, Dec 27, 2011 at 8:14 AM, Charles Sullivan <
charlie.sullivan@gmail.com> wrote:

It would be nice if Chef supported multiple validation keys and had ACL
support. Possibly something similar to how Amazon does IAMhttp://aws.amazon.com/iam/policies.

Brad,

For now you could always pre-generate a pool of client/node keys if you
really need to keep your validation key secret.

Fellow Austinite - Charles

On Tue, Dec 27, 2011 at 9:45 AM, Brad Knowles bknowles@ihiji.com wrote:

On Dec 27, 2011, at 9:31 AM, Jake Vanderdray wrote:

How do you mange your validator PEM? Do you end up doing the
initial install for the developers and put the PEM on manually, or do
you openly share the validator within your organization?

That's shared openly by all systems and users in the company. Of course,
we're a small shop -- seven people at the moment, although I understand
that they're looking to fill some positions. And of those, not all are
developers. Of the developers we have, most aren't doing much of anything
at all with Chef -- as the Ops guy, I'm the primary one doing most of the
work with Chef.

Pretty much all of our systems are (or will be) VMs "in the cloud". Our
developers do have local machines that they work from, but those are
primarily used as a place to jump off into the actual development work that
is done elsewhere.

To be honest, if you're using a Chef-managed environment, I don't see how
you can avoid sharing the validator PEM amongst all systems. For those
people who are developers but who don't need root access to their
development machines, I could see where they wouldn't have open access to
the validator PEM, but everyone doing anything with Chef would need to have
access.

We're testing out using Vagrant instances for developers that get
built with our normal chef cookbooks. I'd love to just be able to
point people at a wiki page of instructions and let it be self-serve.

We could use vagrant, but we really want to get away from having any
physical hardware that we have to manage, beyond the desktops that each
person sits in front of -- and they're mostly responsible for managing
those machines.

We do have a server with a few VMs loaded on it, and that machine has
been used for some development to date, but going forward I think we're
going to get away from that.

Of course, in a larger shop, I could see where our flat development
architecture wouldn't necessarily work so well.

--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1

--
Charles Sullivan
charlie.sullivan@gmail.com