Unfortunate that you had issues using knife-ec2 with an SSH gateway; I worked that out like so:
knife ec2 server create \
--environment stage \
--node-name stage-new-instance \
--flavor m1.small \
--ssh-gateway
\
--ssh-user ec2-user \
--security-group-ids sg-dd0bc0b6 \
--run-list "recipe[et_base]"
I'd encourage taking one last quick stab at using knife-ec2 for this, as it will simplify a lot of things.
As an aside, eventually, we avoided using an SSH proxy by forking knife-ec2 (see https://github.com/evertrue/knife-ec2) to not handle the initial provision directly, but instead by pushing user data to S3, and using a signed URL to bootstrap the node. See my compatriot’s commits at evertrue/knife-ec2.
--
On March 17, 2014 at 4:12:52 PM, Daniel Condomitti (
">
) wrote:
I would just include bc-location::default and place the
location-detection logic in that recipe based on the EC2
availability zone or the GCE equivalent. You can always swap out
how that’s handled (even a huge case statement for now just to get
everything working if you’re facing a deadline) with a better
approach later. This way you can keep all that ugly logic
abstracted away and out of the rest of your cookbooks.
We use a combination of chef searches (service discovery),
cookbook attributes (node-specific configuration like users and
locations) and data bags (environment-specific configuration data
and sensitive stuff like keys) which isn’t perfect but it works
well for us.
On Monday, March 17, 2014 at 1:07 PM,
Douglas Garstang wrote:
Daniel,
Using Jeff's approach above, I'd still need to
use
include_recipe
"bc-location::#{some-special-key-to-determine-location}"
in every situation
where this data was needed, correct? Am I the only one that thinks
this is ugly?
Doug.
On Mon, Mar 17, 2014 at 12:59 PM, Daniel Condomitti <
" target="_blank">
> wrote:
You don’t need to use knife-ec2 to get those attributes.
Create /etc/chef/hints/ec2.json (empty file is fine) and ohai will
automatically set a LOT of instance metadata attributes including
ec2.placement_availability_zone.
On Monday, March 17, 2014 at 12:51 PM,
Douglas Garstang wrote:
Jeff,
We are using EC2 (and GCE). However, we aren't using
knife to provision systems. We weren't able to get the knife ec2
plugin to work with an ssh proxy and gave up in the
end.
I just tried a different approach, where I have one
cookbook, with one recipe per location. This gets around the issue
of having to depend on an arbitrary list of location cookbooks in
the metadata.rb of every cookbook we write. However, the trade-off
is that I have to do this:
include_recipe
"bc-location::#{some-special-key-to-determine-location}"
every single time I need to access location data. This
is horrid. I simply can't understand why people keep saying not to
use roles. Roles are just so much more convenient. All the include
magic is done automatically for you.
Douglas.
On Mon, Mar 17, 2014 at 11:23 AM, Jeff Byrnes <
" target="_blank">
> wrote:
Doug:
I’m not sure if you’re
using EC2, but if so, and you’re launching instances using
knife-ec2, you should have node['ec2']['placement_availability_zone']
available. You could build a single wrapper cookbook, that depends
on that attribute’s value, and determines the requisite data
center-specific attributes.
On March 17, 2014 at 1:54:21 PM, Douglas Garstang (
" target="_blank">
) wrote:
Doing what I read to be a best practice, I just took a
bunch of roles that defined set attributes for specific data
centers, and moved them into cookbooks, one per location,
ie:
bc-location-u1
bc-location.eu1
and so on. I just occurred to me that if I do this, then
all cookbooks will need to depend (in the metadata.rb) file on ALL
of these location based cookbooks.
is this correct? What am I missing?
Doug
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email:
" target="_blank">
Cell: +1-805-340-5627
--
Regards,
Douglas Garstang
http://www.linkedin.com/in/garstang
Email:
">
Cell: +1-805-340-5627
|