This is our summary of PuppetConf 2014. In our previous post we gave an overview of the first day of the conference. This post will provide an
overview of the final day.
There were even more inspiring keynotes and lots more talks which have given us plenty of ideas to go home and think about.
Animating the Puppet: Creating a Culture of Puppet Adoption - Dan Spurling (@spurling), Getty Images - Slides
Dan Spuring, VP of Tech Services at Getty came out of the gate with a strong message. His GSD t-shirt
giving you a clear understanding of who he is. His talk about creating a culture of Puppet adoption at his company was a great story of how challenging it
can be to move various business units with projects of various ages to a configuration-management (with Puppet) ethos.
I think it is good to hear that they are rolling cm out into that huge backlog of legacy infrastructure that we all try to pretend isn’t there.
How do you make it integrate into existing processes? How do you sell the DevOps message at the same time as introducing a tool like Puppet into the mix as
part of that message? Dan gave some thoughts on this and it was good to hear some of that from someone who appears to be on the other side of that challenge.
One of the analogies that he used I that found quite useful was that undertaking a project like this is like moving a boulder. It requires an executive sponsor to
get the thing moving at all and then it requires everyone pulling in the same direction if it’s ever doing to get anywhere.
The big take-away was that you need to puppetize right away - that you can’t wait for the right environment or conditions to start doing it, you just need
start now and demonstrate it. This echo’s the Continuous Delivery ideal of “if it hurts, then do it more often”.
Decentralize Your Infrastructure - Alan Green, Sony Computer Entertainment America - Slides
Alan’s talk posed an interesting argument: decentralise and let your developers choose the tools and services that they want - just make it easy for them to
do so. This obviously flies in the face of conventional sysadmin wisdom of trying to centralise, standardise and control everything but for an organisation the
size of scale of SCEA this is just never going to work. Sony has many different studios, each has their own special requirements and tooling that they need to
try and support.
The story of the interaction with these studios is a great classic sysadmin story that is worth repeating. It starts with something we have all heard before “I
need to X right now because it’s preventing me from releasing this game on time”. The reaction here is to either say Yes and risk burning out your people getting
it done or No risk your career if the release date gets pushed. As a sysadmin you’re on the back-foot at this point - you pretty much have to do whatever it takes.
If you decentralize your infrastructure you get to turn the tables “No I don’t have tool X but we do have tool Y and Z that will meet your needs”. This gives
the engineers/managers the choice to make rather than you - they can go out on their own and implement their first choice tool and it will take a bit longer or
they can have something supported by the team right now. Alan also made a interesting call-back to Kate Matsudaira’s keynote of the previous day when he said that
it’s all about honesty and trust. Be truthful with your engineers about what you are capable of achieving or not.
This is the sort of thing we do here at OpenTable and it’s been working very well. You need to design puppet to be as flexible as possible and to support those
teams that need support in their puppet implementations. Having a diverse set of tools is not a bad thing - especially when you are dealing with creative people -
it keeps them creative and you can push that creativity back into the product. You’re also decentralising control, giving teams the ability to move their
infrastructure as fast as they need to move the product - meaning that your business is going to move faster get meet it’s ROI (because managers care about that
sort of thing)
The last “keynote” of the conference brought Luke back to the stage for a Q&A with the audience. Allowing people to text in questions live led to some amusement
and once the silly questions were out of the way ( what is your favourite book?, what is your favourite animal? ) we got down to some of the big questions that
people really wanted answers to.
Q: What is the roadmap for Puppet Apps?
A: I would be surprised if we release more than one per quarter, I’d rather put out four than 20, with five releases for each app. We are a small company,
and we have to try not to get overextended to the point where we can’t evolve the apps. They have to be evolved to be successful.
This seems fair, they is a lot of work involved in putting together something that is polished and tested and ready for market.
Q: What is the future of Open Source Puppet?
A: My goal is to keep the two products complementary, and to understand each is used for different reasons .. We’re trying to change how the market works
and thinks and this is done better with software that’s absolutely everywhere.
He probably gets asked this all the time. The more features that are poured into Enterprise it would be easy to think that the OSS efforts are diminishing and
that there is even motivation for them to close-source. My conversations with various parties suggest that this is far from the case and I think that open source
puppet community will continue to be vibrant for a long time yet.
Q: Where does Puppet fit into environments that don’t require convergence, where instead of adjusting the container you just re-provision?
A: Containers are a result of 10 to 15 years of investment in virtualization, so it’s easy to switch from the virtualization world to the containers world —
but a container can’t do everything.
This is a very pragmatic argument and he’s right. Containers are a very exciting space right now and there is no doubt that it will be a big part of the future
but the community and tooling needs to mature and there is also going to be a very long tail of “traditional” virtualisation technologies around for a very
long time yet.
Q: Are there any plan to integration remote orchestration into Puppet?
A: It’s an area we are investing heavily in, and I’m personally investing heavily in. … I’m a big fan of small independent tools that do one job and do it
correctly, rather than big huge tools that do a lot. I want to make our orchestration better, not by adding to Puppet, but by adding tools. I don’t want to add
more functionality to Puppet, but add functionality to the Puppet ecosystem.
MCollective has been in the puppet eco-system for a while now. It’s going to be getting a lot more attention over the next year so I am very excited to see how
Continuous Integration for Infrastructure as Code - Gareth Rushgrove, Puppet Labs - Slides
Arguable one of the most interesting talks of the conference. This talk took the idea of infrastructure TDD to the next level. What would it be like to be able
to test common expectations of your infrastructure (monitoring, backups, machines in each region, budget limitations). There are lots of built-in assumptions
that we make about of infrastructure and a lot of business decisions that have been difficult to codify. This talk raising the challenge of providing a complete
API for your infrastructure and then testing against it.
- usual tools (serverspec, wrecker)
- for containers
- Policy Driven development
- Infrastructure as an API
- common expectations (budget etc)
- can you generate serverspec tests from PuppetDB data??? - yes!
- rake test::role::web_server
- rspec outputter - monitoring - using it as a bridge
Experiences from Running Masterless Puppet - Erik Dalén, Spotify - Slides
Erik (this years MVP) always has a lot of interesting insights about Puppet from scaling out the infrastructure at Spotify and this talk is no exception.
This talk explains their decision to go masterless and the challenges in doing so. It seems that they have put in a lot of work in writing services to manage
things like hiera data and managing secrets. It is great to see how this approach scales, one can only hope that future work by PuppetLabs with the Apps project
improves this as option for most people.
- scaling workflow rather than puppet masters
- complex modules dependencies make it easy to break things
- r10k is still a fixed environment (upgrade apache and progress at the same time)
- they use their own tool for secret management
Getting Started with Puppet on Windows - Josh Cooper, Puppet Labs - Slides
This was a basic introduction to Puppet on windows. It covers what is possible and the many edge cases that you might run into. It was also the time to
re-announce the recent support for 64-bit puppet on windows. Thanks to Josh we also got a shout-out for the work we have done with our
- Basic intro
- powershell, registry_key
- installing - mention of 64-bit
- puppet resource
- supported modules
- community modules (inc OT)
- geppetto vs VS
- case sensitivity
Test Driven Development with Puppet - Gareth Rushgrove, Puppet Labs - Slides
This is Gareth’s basic introduction to TDD with Puppet. It covers the latest tooling and how to build yourself a recent CI pipeline for your modules so that
they are forge-ready. Useful for anyone who is new to the space or who hasn’t released any modules yet.
- beaker (vagrant + serverspec)
- puppet module skeleton
Using Docker with Puppet - James Turnbull, Kickstarter - Slides
James gave a good introduction to Docker. Showing off the things that Docker is good at and also detailing some of the things that it isn’t.
He also showed how and when to use Puppet in this environment. For anyone moving from a traditional set-up to a Docker based one then this talk is a must.
- what is docker
- what it does
- what it doesn’t
- resource dependencies
- what runs, when
- don’t install puppet inside your containers
- puppet apply
Tools and Virtualization to Manage our Operations at Puppet Labs - Cody Herriges, Puppet Labs - Slides
Cody, is a member of the PuppetLabs operations team and wow they seriously have their work cut out for them. They have to manage pretty much every network,
vm technology and cloud platform available. This gives some of the challenges in doing that and some of the tools they have built to help them in
- all the VM technologies
- all the cloud platforms
- all the network providers
- monitoring (ELK)
- vmpooler (https://github.com/puppetlabs/vmpooler)
- The Switch as a Server - Leslie Carr, Cumulus Networks - Slides
- Intro to Using MCollective - Devon Peters, Jive Software - Slides
- How Puppet Enables the Use of Lightweight Virtualized Containers - Jeff McCune, Puppet Labs - Slides
- Server Locality Using Razor and LLDP - Jonas Rosland, EMC - Slides
- Node Classifier Fundamentals - Dan Lidral-Porter, Puppet Labs - Slides
- What’s Next for Puppet Enterprise - Lindsey Smith, Puppet Labs & Susannah Axelrod, Puppet Labs - Slides
- The DevOps Field Guide to Cognitive Biases (2nd Edition) - Lindsay Holmwood, Bulletproof Networks
- Delegated Configuration with Multiple Hiera Databases - Robert Terhaar, Atlantic Dynamic - Slides
- Understanding OpenStack Deployments - Chris Hoge, OpenStack Foundation - Slides
- Implementing Puppet at a South American Government Agency, Challenges and Solutions - Pablo Wright, Edrans - Slides
- Infrastructure as Software - Dustin J. Mitchell, Mozilla, Inc. - Slides
- Dev to Delivery with Puppet - Sam Bashton, Bashton Ltd. - Slides
- Get Puppet Enterprise into Your Company - Iko Saadhoff, KPN
- The Puppet Master on the JVM - Chris Price, Puppet Labs - Slides
- The Grand Puppet Sub-Systems Tour - Nicholas Fagerlund, Puppet Labs - Slides
- Building Community: One Puppet Module at a Time - Diane Mueller, Red Hat & Diego Castro, Getup Cloud
- Puppet for Everybody! - Federated and Hierarchical Puppet Enterprise - Chris Bowles, University of Texas at Austin - Slides
- Puppetizing Multitier Architecture - Reid Vandewiele, Puppet Labs - Slides
- The Evolving Design Patterns of Puppet Enterprise - Jonathan Spinks, Sourced Group & John Painter, Sourced Group - Slides
- From Development to Testing to Deployment with Puppet Enterprise and Microsoft Azure - Ross Gardler, Microsoft Open Technologies, Inc. - Slides
- Exploring the Final Frontier of Data Center Orchestration: Network Elements - Jason Pfeifer, Cisco - Slides
- An In-Depth Introduction to the Puppet Enterprise Console - Ruth Linehan, Puppet Labs - Slides
- Packaging Software, Puppet Labs Style - Melissa Stone, Puppet Labs - Slides
- Orchestrated Functional Testing with Puppet-spec and Mspectator - Raphaël Pinson, Camptocamp - Slides
- Fully Automate Application Delivery with Puppet and F5 - Colin Walker, F5 - Slides
- Managing the File and Exposing the API - Christopher Webber, Chef Software
- Case Study: Developing a Vblock Systems Based Private Cloud Platform with Puppet and VMware vCloud Suite - Peng Liu & Paul Harb, VCE - Slides
- Got Logs? Get Answers with Elasticsearch ELK - Jordan Sissel, Elasticsearch - Slides
- Managing Network Security Monitoring at Large Scale with Puppet - Michael Pananen & Chris Nyhuis, Vigilant Technology Services - Slides
- Building and Testing from Scratch a Puppet Environment with Docker - Carla Souza, Reliant - Slides