by John Keiser
Your important new distributed application is a month from the go-live
date. Developers have carefully built it up, piece by piece, with
fault tolerance designed in. It has been performance optimized, and
unit tested to an unprecedented 85% coverage! Now you get operations
and development collaborating to get it deployed, using tools they
both understand. Devops, right?
Yet everyone is angry, frustrated and stressed. The product fails to
run when you deploy it, due to elementary issues. It's slow. The
built-in fault tolerance doesn’t work. Debugging the issues takes
weeks. Your one month to go-live turns into six months, and
development and operations are ready to kill each other at the end.
What went wrong?
It went wrong on day one. For the entire development cycle, every
line of code in the application was exercised, but nobody ever ran the
application. If this scenario sounds familiar to you, come to this
talk and learn why it happened, and how you can address it.
We're slowly starting to see Configuration Management become a default rather than an exception. Increasingly large numbers of organizations see CM as a requirement and not an extra. Sadly we don't see this maturity reflected in the monitoring world. Change has been slow, we're often not monitoring the right things or the right places and environments remain heavily manual.
So why hasn't monitoring advanced at the same pace as CM? What's different about it? More importantly, what can we do about it?
This talk will take you through a potted, comparative history of monitoring and configuration management and propose some ideas about how configuration management combined with continuous integration and delivery can help you level up your monitoring.*
P.S. Warning. May also contain containers.
Everything you ever wanted to know about Ansible, but may have been afraid to ask. Greg DeKoenigsberg of Ansible will sit down for an open discussion about Ansible the project, the company, and the community.
OpenShift V3 has arrived and is now leveraging Docker, Google Kubernetes to automate and orchestrate application deployment. In this talk, I'll discuss how this changes the game for application configuration management and what this means for configuration management going forward.
Reflections on maintaining Chef cookbooks. Observations on design
patterns, re-usability, and technical debt. Insights gained from
mistakes. Advice on testing. Gripes about packaging policies. Thoughts
by Liam Bennett
How do I test my modules? How do I test my roles and profiles? How do I set those complex multi-node clusters? Do I even care about acceptance testing at all when I can just test the catalogue?
This talk aims to take a look at testing Puppet with Beaker, not just the how but also the why. It will look at the main use-cases for Beaker, some useful information for those running systems that are not Debian or RedHat and give a good overview of how Beaker works internally.
The CFEngine Roadshow is a live demonstration of the power of CFEngine. In this demonstration in which I bring up and configure into the desired state up to 20 virtual machines. Laptop attendees that have a virtual machine available are invite to submit their machine for configuration.
Smartphone users are invited to login to a given set of servers configured by CFEngine. I will try Raspberry Pi and Android.
The Roadshow will be available in the background throughout the conference.
I will install and configure java tomcat7 webservers among others.
The content of the demonstration is Open Source, https://github.com/Webhuis/CFEng...
The purpose of the CFEngine Roadshow is to develop a complete coherent working setup for a CFEngine3 implementation, that works out of the box.
We are having drinks across the street, more info on http://cfgmgmtcamp.eu/
by Jez Humble
Configuration management is an essential ingredient in creating high performance IT. But how you implement it matters. In this talk Jez will present the principles that enable high throughput and stability and the configuration management practices behind then, using models drawn from the Lean movement.
by Ramez Hanna
At Goo we started with manually creating VPCs and slowly moved into CloudFormation, and after discovering Ansible our lives got much easier. There was a lot of thought about the most efficient and flexible way. The way forward was not a simple choice; CloudFormation templates seemed like a good standard and offered a lot, but lacked flexibility and Ansible offered the flexibility, but lacked in other areas. In this talk I will present the path we took and how we got there.
"DevOps" means different things to different people. But now many
vendors are slapping a "DevOps" sticker on the same software they've
sold for 20 years and calling it new. How can we say that's not
DevOps when we can't wrap our heads around the general practices of
We don't all need to deploy 10+ times per day to production, but
there's still a common set of practices we're embracing as a
community. The DevOps talent pool needs to grow faster before more
half-baked "DevOps Toolkits" try to fill the void we should be filling
with experienced practitioners. So how do we get there?
We'll look at observations from having helped many orgs in different
phases of adopting DevOps to ask the question: if Mr Miyagi was
training the next wave of DevOps Engineers, what chores would he use
to instill the right bits of muscle memory that turn us into prize
This talk is for users who are familiar with SaltStack configuration management, or with configuration management concepts in general, but want to learn more about the latest features delivered in the newest Salt releases. Highlights include:
- The Salt state altering system - Used to make sure states are evaluated exactly as the user expects.
- Runtime modification - One of the major requests in Salt has long been adding the ability to install all packages defined at the same time. The mod_aggregate system makes this a reality and these runtime modifications make it easy to run groups of states together.
- New requisites - The Salt requisite system is used to create relationships between states, so when one state is dependent on another, that inter-dependency can be easily defined with Salt requisites like onchanges, onfail, and listen / listen_in.
- More fileserver backend support.
This talk will cover the basic life cycle of a Puppet Catalog from compilation request to report processing. It will explore the performance of some of the life cycle steps and show how you might instrument these steps using tools Puppet make available.
Along the way it will provide hints and tips on how to write performant facts and manifests.
Despite all the talk of cloud and DevOps, the overlap is more in theory than practice. In the DevOps community today, there's a near-total lack of interaction between people who started on the dev side and on the ops side. Donnie will present data based on configuration-management frameworks to support the divide between dev and ops across a variety of scenarios.
What can we do to build empathy and collaboration across these disparate groups? Is it even possible in the enterprise? Uniting dev and ops requires leveling up in your thinking. Donnie will share a new way of thinking about DevOps, and how we can move the conversation and the community forward.
He'll also share never-before-seen data from his FOSDEM talk comparing the state of the community across config management frameworks.
Cfengine is a proven flexible and trustworthy tool for ensuring desired state in distributed systems. Salt is a powerful parallel execution system based on ZMQ. Why not combine the two, and get the best from two worlds? It turns out that it is easy to enable salt simply by reusing the existing Cfengine PKI (if you already have a Cfengine installation in place.)
"In the Pleistocene epoch, Foreman used to only manage one workflow, one configuration management system, and was limited to only a few use cases. We have been meaning to fix this problem by making an interface which has allowed the community to have things like Salt support, Docker containers management, and even provide SCAP compatibility for your systems.
During this talk we will cover the basics of how plugins should be started, how to extend Foreman models, test them and modify the interface. The Foreman organization can take care of some annoyances like packaging and distribution of your plugin, so we will also explain how to make your plugin official."
(More in depth talk)
The emergence of configuration management supported by improved tooling has been an awesome force to behold and be part of over the last decade, but configuration as a node level primitive was never enough. As a consequence, all manner of scripts and orchestration tools are required to translate from node level configurations to meaningful deployments and other ongoing operational considerations. This presentation will show making services the first level primitive, integrating per node configuration capabilities with declarative multi-node service definitions, can help solve some of the most common problems. BOSH was originally developed as a deployment tool for Cloud Foundry’s Elastic Runtime, but is also a general purpose configuration solution. BOSH powers Pivotal’s production Cloud Foundry deployment supporting thousands of applications, and a growing number of deployments of Kubernetes, Cassandra, MySQL, RabbitMQ and many other popular services.
The last two years have seen both a renewed interest in containerization technology and the meteoric rise of Docker. With the decreased need for run-time state management, is there still room for convergent configuration management technologies like Chef or Puppet?
In this talk, I will discuss how traditional CM technologies must adapt to a containerized world, and also where they will continue to be relevant. I will also discuss the coming impacts of containerization on a company's culture and processes, and how CM tools can evolve to reinforce and retain positive cultural values even in a containerized world.
by Nils De Moor
Ansible is often coined to differ from config management tools like Puppet, by only executing actions instead of reaching a desired server state. But what if I told you a best of both worlds is readily available? In this talk we'll propose the dream team, that is Ansible and Serverspec, and configure a cluster with instances that always reach the desired state.
Foreman Discovery is the Foreman projects solution to the metal-as-a-service problem (discovering, registering, and provisioning bare metal systems without recording the MAC address beforehand).
In this talk, we'll do a quick intro to Discovery for those unfamiliar with it, before going on to cover the new features in Discovery 2.0. This will include (but is not limited to):
by David Boucha
This talk will demonstrate how SaltStack can be used with either imperative or declarative configuration languages allowing systems administrators and DevOps pros to deploy and manage their applications and infrastructure in the way that makes the most sense for a unique environment. SaltStack state auto order is a major change in how states are evaluated in Salt. State auto order evaluates and executes states in the order in which they are defined in the sls file. This feature makes it easy to see the finite order in which things will be executed, making SaltStack now, fully imperative and fully declarative. The requisite system still takes precedence over the order in which states are defined, maintaining the old lexicographical order, but now users have options and flexibility to better meet their needs.
Deployments, rollbacks, pushing the right code in the right place are common operations in configuration management. Such operations (and many more) are significantly easier with the support of a version control system. If we have the right repository structure and the right tools, that is.
I'll explain why we went for a single repository with everything in it and how we built simple tools to get the maximum advantage from that structure. The code for our tool cf-deploy will also be described. Everything will be explained at a level that all participants will be able to apply the same principles and use the same code at their premises, regardless of the configuration management tool used.
We've all been there. In fact, most of us started with 'knife
bootstrap'. While our trusty knife has served us well from the
beginning, there are better approaches to interacting with
infrastructure and the Chef server as you progress. This talk will
dive into patterns and practices including source control, automated
testing and cookbook deployment...all without knife.
Every release of Puppet has the potential to unleash catastrophic infrastructure failure across the world. Our users require absolute reliability and consistency. In a development culture that prizes rapid iteration and “moving fast and breaking things,” Puppet Labs walks a fine line between innovation and reliability. We ship software in a state of perpetual tension, internally and externally, culturally and technically. Breaking puppet, intentionally or not, has a ripple effect across our ecosystem. We must do it well, and only when we want to. How do we reconcile a need to be agile while building trust in our mission-critical software?
This talk will outline the steps we’ve taken with open source Puppet to accelerate development while protecting and preparing our users for change in our software. It will highlight examples of where we’ve failed, what we’ve learned from those failures, and how we think we’ve created a framework for success.
In our role administering an OpenStack IaaS Cloud, we’ve developed a release train allowing local development and testing of configuration management, testing in virtualised environments and automated deployment to staging and production, for the building and maintenance of an IaaS Cloud using upstream vendor OpenStack packages.
In this talk we'll cover the tools (Salt, jenkins, test-kitchen, git/gerrit, gitshelf) & techniques we used to build an effective pipeline for delivering salt managed infrastructure while retaining good engineering practices (peer review, automated component testing, automated integration testing, packaging solutions, safe & realistic dev environments, upgrade & greenfield deployments).
We’re moving from a world of files, packages and individual hosts to one of containers, platform as a service and distributed config stores. What does that mean for the problem space of configuration management and the tools we use today?
As different communities we may use different tools, but we can agree on the fundamentals of configuration management, which date back to the 1950s (this is Config Management Camp, you’ve all read MIL–HDBK–61 right?). Let’s apply some of those fundamentals — control, accounting and verification — and take a look at our new problems.
This presentation will:
At ConfigMgmtCamp 2014, Julian presented a talk with tips &
tricks on using Chef on Windows. A great deal has changed in the
intervening year. This is a refreshed "state-of-the-union" for
automating Windows, and what lies ahead for Chef on this platform.
2nd–3rd February 2015