Chef on existing infrastructure/nodes

Chef Infra (archive)
1

Hey y’all,

I heard something on a Puppet Labs podcast* recently that gave me a pause
for though: developing cookbooks (manifests in Puppet?) against production
machines as a way of migrating to a coded infrastructure.

i.e. instead of starting from scratch and attempting to duplicate current
infrastructure, slowly adding pieces (automating processes) to cookbooks in
order to gain immediate benefits.

Are there any patterns for this? Does anyone have any experience, good or
bad? I thought it was interesting at the least.

Cheers,
Mike Dillion

2

I tend to thing of the approach like this game:


In almost every company where I've introduced Chef or Puppet, the first
thing we did was:

  • Automate some basic mundane configuration on existing systems (ntp, ssh
    key distribution, whatever)
  • Find at least ONE blank system (virtualized, physical - it doesn't matter)
  • Start developing and rebuilding the system with cookbooks/modules
  • Do that one system OVER AND OVER AND OVER AND OVER until you can go soup
    to nuts (bootstrap to in-server)
  • Move it into production and terminate the old system
  • Use the newly decommissioned system to repeat the process with another
    component

This will take time. Lots of time but the end result is that you've rebuilt
your entire infra in something repeatable. At the last company it took me
about 3 months (we were all on AWS so I had free resources). At the current
company it took 6-8 months as we were running on cloudstack privately with
non-infinite resources.

On Tue, Apr 23, 2013 at 9:44 AM, Mike Dillion mike.dillion@gmail.comwrote:

Hey y'all,

I heard something on a Puppet Labs podcast* recently that gave me a pause
for though: developing cookbooks (manifests in Puppet?) against production
machines as a way of migrating to a coded infrastructure.

i.e. instead of starting from scratch and attempting to duplicate current
infrastructure, slowly adding pieces (automating processes) to cookbooks in
order to gain immediate benefits.

Are there any patterns for this? Does anyone have any experience, good or
bad? I thought it was interesting at the least.

Cheers,
Mike Dillion

3

+1 to John's post as that's the current plan we're trying to implement
migrating away from a golden image and moving towards infrastructure as
code. If you're a smaller shop it's a little bit easier, but if you're a
bigger shop where there are departments for different responsibilities it
can be like pulling teeth.

If you're a bigger shop, i would start with ingraining the philosophy or
concept you're trying to drive. THEN iterate over the process in doing so.
I've ran into more problems where people are the ones slowing the
implementation.

On Tue, Apr 23, 2013 at 9:54 AM, John E. Vincent (lusis) <
lusis.org+chef-list@gmail.com> wrote:

I tend to thing of the approach like this game:

http://s3itch.lusis.org/sliding-puzzle-20130423-094943.jpg

In almost every company where I've introduced Chef or Puppet, the first
thing we did was:

  • Automate some basic mundane configuration on existing systems (ntp, ssh
    key distribution, whatever)
  • Find at least ONE blank system (virtualized, physical - it doesn't
    matter)
  • Start developing and rebuilding the system with cookbooks/modules
  • Do that one system OVER AND OVER AND OVER AND OVER until you can go soup
    to nuts (bootstrap to in-server)
  • Move it into production and terminate the old system
  • Use the newly decommissioned system to repeat the process with another
    component

This will take time. Lots of time but the end result is that you've
rebuilt your entire infra in something repeatable. At the last company it
took me about 3 months (we were all on AWS so I had free resources). At the
current company it took 6-8 months as we were running on cloudstack
privately with non-infinite resources.

On Tue, Apr 23, 2013 at 9:44 AM, Mike Dillion mike.dillion@gmail.comwrote:

Hey y'all,

I heard something on a Puppet Labs podcast* recently that gave me a pause
for though: developing cookbooks (manifests in Puppet?) against production
machines as a way of migrating to a coded infrastructure.

i.e. instead of starting from scratch and attempting to duplicate current
infrastructure, slowly adding pieces (automating processes) to cookbooks in
order to gain immediate benefits.

Are there any patterns for this? Does anyone have any experience, good or
bad? I thought it was interesting at the least.

Cheers,
Mike Dillion

--
Elvin Abordo
Mobile: (845) 475-8744

4

This might give you a starting point. It’s pitched as a full-stack,
lightweight config management solution, but it can also do some light
reverse-engineering on systems and generate a Chef cookbook as the output.

http://devstructure.com/blueprint/

Thanks,
–Charles

–
Charles Johnson
Solutions Engineer - Opscode, Inc.
(510) 545-9485 - Direct Line
charles@opscode.com

From: Mike Dillion mike.dillion@gmail.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Tuesday, April 23, 2013 6:44 AM
To: "chef@lists.opscode.com" chef@lists.opscode.com
Subject: [chef] Chef on existing infrastructure/nodes

Hey y’all,

I heard something on a Puppet Labs podcast* recently that gave me a pause
for though: developing cookbooks (manifests in Puppet?) against production
machines as a way of migrating to a coded infrastructure.

i.e. instead of starting from scratch and attempting to duplicate current
infrastructure, slowly adding pieces (automating processes) to cookbooks in
order to gain immediate benefits.

Are there any patterns for this? Does anyone have any experience, good or
bad? I thought it was interesting at the least.

Cheers,
Mike Dillion