Hi all, I’m currently using chef and bootstrapping my instances with user
data. However, I’ve found that just the process of bootstrapping the
instance (installing the required packages, updating, etc) takes longer
than I’d like it to. So what I’d like to do is to bootstrap an instance
with a run list that I’m going to be using often (ie. a www server) and
then create an AMI out of that instance. Then, later, when I want to launch
another instance of that AMI, I’ll just re-run the chef bootstraping to
make sure the instance is configured how I’d like to be.
My question is then, how do I “clean” the instance of chef before I create
an AMI from it so that I can bootstrap it again upon a new creation?
Thanks!
This question gets asked often. Someone please add this to the Opscode
wiki.
On Fri, Nov 11, 2011 at 4:05 PM, Chris Streeter chris@chrisstreeter.comwrote:
Hi all, I'm currently using chef and bootstrapping my instances with user
data. However, I've found that just the process of bootstrapping the
instance (installing the required packages, updating, etc) takes longer
than I'd like it to. So what I'd like to do is to bootstrap an instance
with a run list that I'm going to be using often (ie. a www server) and
then create an AMI out of that instance. Then, later, when I want to launch
another instance of that AMI, I'll just re-run the chef bootstraping to
make sure the instance is configured how I'd like to be.
My question is then, how do I "clean" the instance of chef before I create
an AMI from it so that I can bootstrap it again upon a new creation?
Thanks!
--
Charles Sullivan
charlie.sullivan@gmail.com
Not sure if this got added to the Opscode wiki, but if not, is there a good
source in list archives that I could check out? Or would someone like to
point to a good resource somewhere?
Thanks.
On Fri, Nov 11, 2011 at 14:08, Charles Sullivan
charlie.sullivan@gmail.comwrote:
This question gets asked often. Someone please add this to the Opscode
wiki.
On Fri, Nov 11, 2011 at 4:05 PM, Chris Streeter chris@chrisstreeter.comwrote:
Hi all, I'm currently using chef and bootstrapping my instances with user
data. However, I've found that just the process of bootstrapping the
instance (installing the required packages, updating, etc) takes longer
than I'd like it to. So what I'd like to do is to bootstrap an instance
with a run list that I'm going to be using often (ie. a www server) and
then create an AMI out of that instance. Then, later, when I want to launch
another instance of that AMI, I'll just re-run the chef bootstraping to
make sure the instance is configured how I'd like to be.
My question is then, how do I "clean" the instance of chef before I
create an AMI from it so that I can bootstrap it again upon a new creation?
Thanks!
--
Charles Sullivan
charlie.sullivan@gmail.com
On Fri, Nov 11, 2011 at 5:05 PM, Chris Streeter chris@chrisstreeter.com wrote:
My question is then, how do I "clean" the instance of chef before I create
an AMI from it so that I can bootstrap it again upon a new creation?
The chef-client looks for the existence of the file specified by the
client_key configuration value in client.rb. By default, this file is
/etc/chef/client.pem. If you remove this key, on the next chef-client
run will register with the chef server as a new client.
Optionally you can also clean out /var/chef/cache.
Of course, when you utilize a golden image, each system must have a
unique hostname, which chef will utilize for uniqueness when creating
the client and node objects. EC2 makes this relatively easy, but in
private infrastructure you will need dynamic addressing and DNS
pre-configured.
On Fri, Nov 11, 2011 at 5:08 PM, Charles Sullivan
charlie.sullivan@gmail.com wrote:
This question gets asked often. Someone please add this to the Opscode
wiki.
It is a public wiki, please feel encouraged to add to it yourself.
Bryan
I use a multi-pronged approach to this. I have a image (Amazon AMI) with only the changes being the installation of the Omnibus client and the validation.pem. I then use that and a base-image role which only installs packages that all of my systems use. I use the base-image as my golden image as I ran into a networking problem that caused new images to hang due to package installations/updates. When new images are spun up they only have to configure software that's already installed and then deploy my company's software so my deploy time has decreased and I've lessened my dependencies somewhat as well.
--
cjs
On Friday, November 11, 2011 at 4:05 PM, Chris Streeter wrote:
Hi all, I'm currently using chef and bootstrapping my instances with user data. However, I've found that just the process of bootstrapping the instance (installing the required packages, updating, etc) takes longer than I'd like it to. So what I'd like to do is to bootstrap an instance with a run list that I'm going to be using often (ie. a www server) and then create an AMI out of that instance. Then, later, when I want to launch another instance of that AMI, I'll just re-run the chef bootstraping to make sure the instance is configured how I'd like to be.
My question is then, how do I "clean" the instance of chef before I create an AMI from it so that I can bootstrap it again upon a new creation?
Thanks!
On Nov 14, 2011, at 9:43 AM, Clif Smith wrote:
I use a multi-pronged approach to this. I have a image (Amazon AMI) with only the changes being the installation of the Omnibus client and the validation.pem.
I'm confused. I was under the impression that burning your own AMIs for use with Chef was considered to be one of the worst possible anti-patterns.
Did I miss something?
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
On Mon, Nov 14, 2011 at 1:28 PM, Brad Knowles bknowles@ihiji.com wrote:
On Nov 14, 2011, at 9:43 AM, Clif Smith wrote:
I use a multi-pronged approach to this. I have a image (Amazon AMI) with only the changes being the installation of the Omnibus client and the validation.pem.
I'm confused. I was under the impression that burning your own AMIs for use with Chef was considered to be one of the worst possible anti-patterns.
Did I miss something?
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
It's a bit of an eternal debate. I'm a fan of JEOS myself but after a
while you get serious drift in system packages. Eventually boostraps
take longer and longer.
I've been considering rolling a new AMI with ruby and chef-client
baked in for a while now just to speed up new instance creation.
±-----------------------------------------------------------------------------
| On 2011-11-14 14:24:01, John E. Vincent (lusis) wrote:
|
| It’s a bit of an eternal debate. I’m a fan of JEOS myself but after a
| while you get serious drift in system packages. Eventually boostraps
| take longer and longer.
Initial base package installation is by far the biggest time sink for spinning
new instances for me. (When create instance isn’t being pathological, anyway).
For my SmartOS KVM templates, I’ve taken to creating new template snapshots
when the base changes enough to be annoying.
I have been considering doing the same for my EC2 JEOS AMIs.
Cheers.
bdha
cyberpunk is dead. long live cyberpunk.
On Monday, November 14, 2011 at 10:28 AM, Brad Knowles wrote:
On Nov 14, 2011, at 9:43 AM, Clif Smith wrote:
I use a multi-pronged approach to this. I have a image (Amazon AMI) with only the changes being the installation of the Omnibus client and the validation.pem.
I'm confused. I was under the impression that burning your own AMIs for use with Chef was considered to be one of the worst possible anti-patterns.
Did I miss something?
The so-called "golden image" pattern where you hand roll some sort of VM image, copy it, and then manage it by hand thereafter is definitely considered an anti-pattern by config management advocates.
Baking some configuration into an image and managing it with Chef after boot isn't so much about good vs. evil as it is about tradeoffs and discipline. If you need or want low instance spin up times and have the time and discipline to keep your image(s) up to date and you have an automated, repeatable process for doing so, that's fine. Depending on your situation, you may even reduce the amount of by-hand work this way. Maximizing value trumps adhering to dogma, so do the right thing for your infrastructure.
--
Dan DeLeo
--
Brad Knowles <bknowles@ihiji.com (mailto:bknowles@ihiji.com)>
SAGE Level IV, Chef Level 0.0.1
My use case isn't traditional as most of my instances run for hours and then are destroyed as their work is completed. I started building from scratch upon each instance but ran into 2 problems, time to productivity and sw install/updates causing systems to hang due to an Amazon networking issue. While we're not likely to incur the networking issue again (let's hope), we decided we also didn't want to be beholden to the resiliancy of apt repositories.
--
cjs
On Monday, November 14, 2011 at 12:28 PM, Brad Knowles wrote:
On Nov 14, 2011, at 9:43 AM, Clif Smith wrote:
I use a multi-pronged approach to this. I have a image (Amazon AMI) with only the changes being the installation of the Omnibus client and the validation.pem.
I'm confused. I was under the impression that burning your own AMIs for use with Chef was considered to be one of the worst possible anti-patterns.
Did I miss something?
--
Brad Knowles <bknowles@ihiji.com (mailto:bknowles@ihiji.com)>
SAGE Level IV, Chef Level 0.0.1