Your SlideShare is downloading. ×
Lightning overview of creating custom AMIs
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Lightning overview of creating custom AMIs

107
views

Published on

Slides from my lightning talk about baking custom AMIs using Jenkins

Slides from my lightning talk about baking custom AMIs using Jenkins

Published in: Technology, Self Improvement

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
107
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Installing at run time means you rely on upstream being performant
    SPOF that is out of your control
    Immutable instance AMIs = scale any time

  • The longer your configuration management takes to run, the longer the lag between starting to scale up and seeing actual performance improvement in your infrastructure. Bad enough we have to wait for the instances to start up.
  • Using rpms lets you minimize what you have to specify in your chef recipes
    fpm lets you specify dependencies, versions, all the good stuff without dealing with spec files
  • One line AMI builds
  • More often the integration tests run, the less painful fixing the failures becomes
    Nobody ever complained that they found a problem too soon after it was introduced
  • Transcript

    • 1. Baking Custom AMIs Made Easy June 12, 2014 Joe Block <jpb@numenta.com>
    • 2. Why not just use configuration management? Instances would get the most current version of all rpms, Python eggs, Ruby gems, etc
    • 3. Reliability If any of your upstream repositories have an issue, suddenly you can’t scale up with configuration management. Or move to a new AZ.
    • 4. Rapid Response When we scale up, we really want the performance boost 5 minutes ago, not 10 minutes from now.
    • 5. Cost A ten minute configuration run means you’re paying for an extra hour of EC2 time every 6 instances.
    • 6. So how do we make it less painful?
    • 7. AMI Toolkit • chef-solo / masterless puppet / ansible etc • fpm - one line rpm creation • packer - easy AMI building • jenkins - trigger ami build every commit
    • 8. chef solo • I’m not crazy, we use configuration management to create the master AMIs. • Keep the instances used in bake process out of your chef server = 1 less SPOF in your life. • No need to purge certs from resulting AMI
    • 9. fpm • Packing your app in rpm/deb files simplifies your chef recipes - keep the app-specific things in the app’s git repo • Creating packages doesn’t have to be a PITA. fpm reduces package creation to a literal one-liner - fpm --verbose -s dir -t rpm --architecture noarch --name yourrpm.rpm --version 1.1.1 —iteration 3 -C /path/to/fakeroot etc
    • 10. packer • Supports multiple output formats - AWS, VMWare, etc • Simple JSON configuration files • Can automatically copy the resulting AMIs to the regions you’re deployed in • Written in Go, no dependency hell to interfere with the other software installed on your build box
    • 11. jenkins • Keep the humans out of the loop • Generate AMIs every commit • Integration test every AMI build
    • 12. AMI Toolkit Summary • chef-solo / masterless puppet /ansible etc • fpm - https://github.com/jordansissel/fpm • packer - http://www.packer.io/ • S3 yum plugin - https://github.com/jbraeuer/yum- s3-plugin • jenkins - http://jenkins-ci.org/ Joe Block <jpb@numenta.com>