[chef] Re: Re: Re: Re: AWS Spot instances for Integration-Testing Cookbooks on Github

[Tara Hernandez < >]

Oh, sorry — the wrapper automation makes use of environment variables for that stuff (e.g. AWS_SECRET_KEY etc.) — it’s not needed in the driver definition and we try and keep that stuff at least slightly secure…

From: Jeff Byrnes < "> >
Reply-To: " "> " < "> >
Date: Tuesday, October 28, 2014 at 10:12 AM
To: " "> " < "> >
Subject: [chef] Re: Re: Re: AWS Spot instances for Integration-Testing Cookbooks on Github

Ok! Sorry this took so long to get back to. Here’s the slides from our presentation back in Sept: http://evertrue.github.io/test-kitchen-travis-slides/

You can refer to these two cookbooks (one was done live during the preso) to guide you on how we set this up using EC2 & Travis:

• https://github.com/evertrue/et_travis_demo-cookbook
• https://github.com/evertrue/et_travis_live_demo-cookbook

Most pertinent is the .travis.yml & .kitchen.cloud.yml (which we force Test Kitchen to use by way of a Rake task).

Tara’s config, below, is very similar to ours, though clearly Jenkins-centric.

Bear in mind that kitchen-ec2, you’ll need to use the current HEAD of the Git repo (see this changeset for details on what’s missing from the current published release, v0.8.0). Hopefully they’ll cut a new version soon, but we use the bleeding edge version right now & it’s solid.

Tara, I’m curious, how did you get around the need for the AWS API keypair in your Test Kitchen config?

-- 

Jeff Byrnes
@berkleebassist

Lead DevOps Engineer

EverTrue

704.516.4628

On October 28, 2014 at 12:28:13 PM, Tara Hernandez ( "> ) wrote:

Here’s a sample of kitchen files we use for ec2 provisioning, now that you’ve found that driver (we have wrapper automation that fills in those env vars, obviously)

driver:

  name: ec2

  ssh_key: <%= ENV['SSH_KEY_FILE'] %>

  aws_ssh_key_id: <%= ENV['AWS_SSH_KEY_ID'] %>

  region: us-west-1

  availability_zone: <%= ENV['AWS_ZONE'] %>

  require_chef_omnibus: true

  subnet_id: <%= ENV['AWS_SUBNET'] %>

  security_group_ids: ‘<%= ENV[‘AWS_SEC_GROUP'] %>'

  flavor_id: 't1.micro'

provisioner:

  name: chef_solo

platforms:

  - name: centos-6.4

suites:

  - name: default

    run_list:

      - recipe[ci-jenkins::default]

    attributes: {

      "ci-jenkins": {

        "enable_cookbook_testing": true

      }

    }

From: Torben Knerr < "> >
Reply-To: " "> " < "> >
Date: Tuesday, October 28, 2014 at 12:32 AM
To: " "> " < "> >
Subject: [chef] Re: AWS Spot instances for Integration-Testing Cookbooks on Github

Weeeee, just found there is a kitchen-ec2 driver, and it has support for spot instances... neat! :-)

Am 28.10.2014 08:24 schrieb "Torben Knerr" < "> >:

Hi everybody,

having some cookbooks hosted on Github and using kitchen-ci for
integration-testing them, I would like to have the kitchen-ci tests
run on every commit / push.

With travis-ci (which I'm using for foodcritic / chefspec) this does
not work unfortunately, since it prohibits creation of nested
containers.

So I'm now considering to spin up an AWS spot instance during the
travis-ci build to run the integration tests on.

Anyone doing this already?

Any pointers or suggestions to get me kick-started are heartily welcome :-)

Cheers,
Torben