Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Lightning overview of creating custom AMIs
Ähnlich wie Lightning overview of creating custom AMIs (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Lightning overview of creating custom AMIs
- 1. Baking Custom AMIs Made Easy June 12, 2014 Joe Block <jpb@numenta.com>
- 3. Why not just use configuration management? Instances would get the most current version of all rpms, Python eggs, Ruby gems, etc
- 4. 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.
- 5. Rapid Response When we scale up, we really want the performance boost 5 minutes ago, not 10 minutes from now.
- 6. Cost A ten minute configuration run means you’re paying for an extra hour of EC2 time every 6 instances.
- 7. So how do we make it less painful?
- 8. AMI Toolkit • chef-solo / masterless puppet / ansible etc • fpm - one line rpm creation • packer - easy AMI building • jenkins - trigger ami build every commit
- 9. 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
- 10. 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
- 11. 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
- 12. jenkins • Keep the humans out of the loop • Generate AMIs every commit • Integration test every AMI build
- 13. 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>
Hinweis der Redaktion
- 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