This talk focuses on introducing a modern, DevOps approach to infrastructure to a legacy organization. We will cover how to convert "curmudgeonly" team members to a new product and workflow, as well as introducing Chef and DevOps to non-infrastructure teams
We set out to solve the following business problems; reduce the time on task for audit work within the regulatory space, reduce unplanned work, project rework and unplanned outages. In this session I will cover why we kick started our DevOps transition using Chef Compliance and InSpec rather than diving straight into automate.
Habitat is the best way for software developers to build, deploy, and manage modern applications - regardless of their expertise. Habitat provides a self-healing, self-configuring, stack-agnostic, frictionless abstraction for running applications—regardless of their complexity on whatever infrastructure you prefer, from physical hardware and virtual machines to containers and everything in between. This session will show you how to build and run your own application. You will learn how scaffolding helps you quickly and easily package your application. Explore the build system used for generating Habitat artifacts. Run an application using the Habitat supervisor. This is the talk for anyone who's just learning about Habitat or those that are interested in seeing some of the newer features of the framework.
At healthcare-focused companies, compliance is serious business and automating compliance is the only way to stay ahead. The team at Optum are one year into their infrastructure and compliance automation journey. Adam Leff, Technical Community Advocate for InSpec at Chef, talks with Odie Routh (Foundation Engineer) and Tom Rennaker (manager of the Compliance Support Services team) from Optum about where they started, where they are now, how they got here, and where they're headed next.
Did you know the public Chef Supermarket has recommended cookbooks from Chef Partners? Last year DNSimple was approached by Chef to be part of their Chef Partner Cookbook program. You'll hear their side of the story from Anthony Eden, DNSimple's founder, and Aaron Kalin, one of the developers and system administrators at DNSimple. Anthony will talk about the business side of joining the program and considerations he took before joining the partner program. After, Aaron will talk about the technical challenges that were faced when trying to make the already published cookbook comply with Chef's Partner Cookbook guidelines. You'll come away knowing more about the Partner Cookbook program and how you could participate with your company including some tips on how to work through the technical and business challenges.
How cloud computing has changed the way in which we as technology companies have to ingest new companies and how we have to deal with industry and compliance through that process.
In this session, we will explore the building blocks of Chef, assemble the pieces, and demonstrate how it all works on Microsoft Azure. There will be several practical demonstrations showcasing how to use Chef to configure your virtual machines (VMs) and your infrastructure in Azure, and to automate your enterprise compliance. The session will bridge infrastructure as code as well as immutable infrastructure via Chef Habitat. Habitat particularly shines in striking the right balance between manageability, portability, and consistency in managing a fleet of microservice applications. We will also explore how we make it easy to run Habitat applications in Azure Container Service – Kubernetes.
Did you know you can buy Chef Automate directly from AWS? AWS OpsWorks now offers managed instances of Chef Automate with easy setup, scheduled backups and upgrades, native API endpoints, and hourly per-node billing. This talk will include the basics of Chef Automate, AWS OpsWorks features and benefits, and a live demo.
Learn how to effectively deploy Python-based applications with Habitat. This is a tale of the effort behind deploying a Sentry (real-time error tracking) cluster to production. Covering the things I wish that I had known when getting started and helping you avoid the same mistakes.
Cascadeo will demonstrate how they use Chef to deploy and manage operational infrastructure in multi-cloud environments for their managed services customers. Chef-driven automation deploys, configures, populates inventory, and validates the telemetry application stack in a distant customer-owned cloud account. Our engineers will demonstrate visualization and reporting based on this data: tickets, device performance graphs, etc. as well as connectivity to services like Slack and PagerDuty for notification and escalation. Companies struggling with operational, monitoring, performance and analytics challenges will find this presentation particularly engaging, as will individuals interested in self-healing distributed systems at scale.
As a content delivery network, Fastly operates a large internetwork and a global application environment. Fastly developed its Incident Command protocol, which it uses to deal with large-scale events. Lisa will cover in detail the typical struggles a company Fastly's size runs into when building around-the-clock incident operations and the things Fastly has put in place to make dealing with incidents easier and more effective. She will also cover common mistakes and lessons learned as Fastly continuously improves its Incident Management framework.
Attend this to learn how you can take advantage of Habitat and enhance your current Chef-based ecosystem. We will share our journey and learnings from building "software as a service delivery system" with Chef and how Habitat's packaging, supervision and service discovery made it simpler, faster and more reliable. You will take home: Where to use Chef and where to introduce Habitat. Benefits of using Habitat. How distributed and complex system deployment can be simplified with Habitat. You will see Chef and Habitat live, in action, delivering a highly available ELK stack (ElasticSearch, Logstash and Kibana) within minutes.
Pitfalls, brick walls, and struggles I faced while navigating the seas of Internet dependent software in an air-gapped environment. This discussion will be from the perspective of a new member of the Chef community, Sandia National Laboratories. Our team has been researching and adopting DevOps techniques to automate our workflows and deliverables. Being one of the architects tasked with exploring Chef as a solution to configuration management, I have had the pleasure to design some of our development process and architecture. This process is continually evolving to suit our specific needs. All of our products are deployed to air-gapped production environments. We are working toward not only using Chef to build our environments but also delivering our environments as fully functional Chef organizations to ensure our contracted work is predictable after delivery. Having developed a mechanism to accomplish this, I would like to share my lessons learned and our approach for developing an [Abstract cut off due to character limit. Please provide us with concise, complete abstract. Thank you!]
Just starting to play around with InSpec and wanna figure out how to make the most of it? This talk will cover an introduction to InSpec and all of its wonderfulness. It will cover everything from awesome features and how they can be used in your CI pipeline to how Chef Automate can help you tie it all together and visualize it to tips and tricks for using InSpec to its fullest potential.
While we all know workflow provides an easy way to do continuous integration/delivery for cookbooks, we also all have other parts that need to be developed and maintained for a successful DevOps environment. This talk will provide information on how to extend the power of delivery to those other projects, and provide the basics needed to understand creating build cookbooks well enough to create one for any project. Topics covered: Understanding the build cookbook, what the phases of the build cookbook are, and how workflow uses them. Using dependencies to tie together both cookbook and non-cookbook items. Demo: Using workflow to build a small web application including building the Web server from source, and delivering to an end environment.
In addition to composition and portability, one of the more commonly overlooked advantages of moving to microservices, containers, and infrastructure-as-a-Service is the ability to create highly-ephemeral, one-off environments for almost any purpose. Imagine a world where a code change can be tested in a completely isolated environment where 100% of the resources are ephemeral. Say goodbye to long-lived staging or QA environments and say hello to Chef, Terraform, Nomad, and Habitat. Terraform and Chef provide the foundation to build and provision infrastructure resources for your application. Running in parallel, these tools can often provision all the infrastructure required for a cluster in 2-3 minutes. Part of that process installs Nomad, an application scheduler akin to Mesos or Kubernetes, and the supporting resources for Habitat, which enables you to automate any app on any platform. Joined together, this toolset enables rapid development, testing, QA, staging, and more. This demo-driven talk with go from nothing to fully-empheral in snap of, press of a button.
As a developer, you don't really think you'll ever get deep into Chef code. As an ops person, you're not sure you want developers messing with your infrastructure anyway. Those were mindsets present at our company until about a year ago. With more software being written and deployed as the company grew and our ops team getting closer to burnout dealing with it all, something about our process had to change. The developers and ops team came to a mutual agreement that the developers should join in to learn how to work with our Chef deployment infrastructure. This talk will cover the process taken to get buy in from developers and how we spread the Chef knowledge around. In addition to less pressure on our ops people, this talk will cover additional benefits gained. Then it will conclude with a few pitfalls that you need to be aware of if you want to go through a similar process with your development team.
Monitoring systems generate a wide variety of data relating to the health and state of services and data all over the network. This data is often useful to resources and recipes, but the check results themselves may reside on a separate server. Chefs are then forced to reimplement the checks themselves, leading to duplication of effort and the opportunity for confusion (when the reimplementation results do not match the original in all cases). In this talk, we will explore ways to make monitoring results easily available to Chef, leading to simpler code, better visibility, and faster, more reliable development.
The DoD's Security Technical Implementation Guides (STIGs) are the baseline for a vast majority of companies, But with 9 different profiles, and hundreds of individual action items how do you even begin? Join me as we look at how to use InSpec to ingest STIG data, how to read and determine what STIGs apply to you, and how to remediate those STIGs with Chef. We will explore the anatomy of a well written InSpec control and some of the more complex Chef and Ruby resources that allow you to successfully implement security hardening. Learn how to edit files in place, search and replace documents, and lessons learned from implementing the RHEL 6 STIG in both on premise and cloud environments.
Chef solo is a great choice for simple and light infrastructure automation. We all used it back in the day. But with Chef Automate becoming more compelling every day (resource discovery, shared data bags, cookbook distribution, automated workflow, ...), many of us want to migrate to a Chef server. Instead of only promoting the "why," this talk will also focus on the "how" and walk you through the migration of a Chef solo setup to a Chef Automate installation managed by Amazon Web Services and OpsWorks.
There is one thing that makes up DevOps. Tools. Tools and process. Okay two things. Tools, process and culture. Among the things that make up DevOps, tools, process and culture are three. And of course, nobody expects the Spanish Inquisition, which makes it tough to get teams to buy into new ways of doing things. We are delighted to share our DevOps transformation journey with you. First, there's the technical journey, such as how we are automating our infrastructure, and our software engineering practices (see www.practicesofmastery.com). Then there's the process journey such as how we have redefined our SDLC to remove friction, and our use of scrum. Finally, there's the cultural journey, such as how we're forming teams around customer value rather than functional silos, as well as our guerilla marketing campaigns (see www.productivitypact.org). Software mediates every interaction with our customers and the purpose of our transformation is to increase our ability to deliver higher quality software at higher velocity in the pursuit of customer value.
DevOps transformation works in seemingly mysterious ways: some organizations thrive like unicorns while others spin their wheels and make little progress. Why do some companies manage to nail it while others struggle to make it past finding the right hammer? There's plenty of conjecture at any conference, so instead let's drop some science. In this talk, we'll look at a wide set of data sources that tell us objectively what works by the numbers. We'll unpack the numbers in those emergent patterns and examine what they mean and what behaviors they represent. We'll also look at how tools shape outcomes and examine what choices make the difference between driving change and struggling to stay afloat. Along the way, we'll look to Chef Automate for examples and we'll break down practical places to dig in if your teams are losing traction.
Many of us have kicked ourselves after giving a bad explanation of a familiar topic or sounding less than competent when discussing a less-familiar one. This talk will cover how we improve at sharing what we know and at being clear about what we don't know, both as individuals and as teams.
With the growing demand for developers, the IT industry is tasked with bringing more workers into the field. Stereotypes and ignorance are a major blocker to this initiative. With the shortage of security and compliance professionals combined with the industry's desire to move security left, it is dire that we think outside of the box to find a solution. My journey into technology (from a background in film and art) begins by learning the InSpec framework and creating a website and using version control for the first time to blog about my journey. I attained the skills necessary to become a cloud automation engineer in 4 months, and I am continuing the narrative into my consulting career by leveraging InSpec and moving security left.
You just want to connect to a remote Windows machine. Sometimes it "just works." Sometimes it doesn't and it's not clear why. We'll dissect some typical WinRM failures. I'll point out the questions to ask and some basic commands (for Windows and Linux) to run that will help you navigate your way to diagnosing your issue and hopefully leading to a successful connection. We'll look at the key points that influence WinRM connectivity and how they need to be configured to facilitate communication between nodes. We'll focus on some nuances specific to various Chef ecosystem tools that affect these settings and how you can configure these tools for the least amount of friction. What has changed and progressed in the last year with regards to the Ruby WinRM client used by knife-windows, Chef provisioning, Vagrant and Test Kitchen? How can you leverage these changes to provide a better remote experience? What works and does not work over WinRM and how can you work around the limitations?
Let's dive into how with policyfiles we can onboard others onto Chef in 1/4 of the time, define a change management approach that everyone can be comfortable with, and allow you to effectively implement Chef within an air-gapped environment. We'll provide an overview of the policyfiles feature, how to manage it through a pipeline, how to migrate an existing Chef structure to a policyfiles structure, and some considerations for when the feature is not the best choice.
Chef is a vibrant, welcoming open source community, but it can seem intimidating to contribute to any open source project when you don't have "engineer" in your title. This talk is for the hand-wavers amongst us—the architects, the planners, the visionaries—who might not be intimately familiar with registers, slices vs arrays, or what the heck a "constructor" is, but still have great ideas. I'll gently guide you through ways to help improve your favorite open source projects, give direction on how to submit a pull request that won't get immediately rejected, and how to prioritize which mountains to tackle first. We'll also explore some of my own journey in "leveling up" in languages, and how to get help turning your ugly, but special to you, code into something that will delight the true code wranglers out there.
The challenge of balancing the need for security with the need for usability is nothing new. Managing secrets when using configuration management tools like Chef is no exception to this rule. Add in the fact that there are multiple tools attempting to solve this problem - each with advantages and drawbacks - and the balance becomes even more precarious! This talk will provide a brief overview of secrets management and then take a deep, technical dive into one tool in particular - Chef Vault. You will walk away understanding how it works - what theories and technologies drive it - as well as how to use it and evaluate whether Chef Vault is the right tool for your particular need. You will also walk away knowing the limitations of Chef Vault - it is not the right tool for every secrets management situation - and how to evaluate whether you safely can work around those limits or need to look at another tool.
Sports move fast; infrastructure testing has to keep pace. The team responsible for the cloud that powers Wimbledon, The US Open and some of the world's largest sporting events uses Chef to manage their infrastructure. Developing a testing framework presented many challenges, including: Scaling infrastructure testing to handle a distributed enterprise. Testing in remote locations without the fastest internet speeds. Contending with the Great Firewall in China. The team has spent 100s of hours optimizing test environments to support fast testing by distributed teams. Learn how the team approached test optimization, what worked and what failed.
Tokens, passwords, certificates, API keys, and other secrets are vital to applications and infrastructure functioning properly. In the modern world of rapid, continuous delivery, we want to maintain agility and keep our secrets safe. While speed and safety feel mutually exclusive, modern tools with appropriate practices enable both at the same time. This talk will discuss patterns and show practical methods for keeping secrets safe from developer environments to production where tight access controls and continuous delivery are priorities.
Automated infrastructure allows us to move fast, but moving fast is scary without proper testing. Where to start though? The state of the art in Chef cookbook testing has changed rapidly in the last few years with the introduction of new and improved tools and much of what you'll find in Web searches is often outdated. In this presentation I'll give an overview of the available tools for testing and techniques to avoid busy work in your testing. We'll cover cookbook linting, unit testing, and integration testing using Cookstyle, ChefSpec, and Test Kitchen / InSpec. We'll also cover wiring up your testing in Travis CI to perform full integration tests on every PR.
The risks faced by corporate IT teams have been rapidly changing in recent years, causing us to forego many of our previous assumptions about security, perimeters, and endpoint management in particular. To lay a foundation, we will discuss our assessment of the organization's corporate IT attack surface, as well as our corporate IT threat model and technology stack. We will delve into the processes and technologies we rely on to mitigate these known and unknown risks, with a focus on how we are utilizing Chef for securing our macOS-based fleet.
Many organizations say they want diverse teams. In this talk, I address how, beyond recruitment, individuals and managers can create a culture that sustains a truly diverse environment. Using my own transition, starting out as a functional business analyst, to working as a DBA before becoming a DevOps/Infrastructure Engineer, I discuss how individuals and managers can take specific actions to foster creativity and diversity of thought and empower team members that may be subject to unconscious bias. Culture is a choice, and every team member makes a difference, regardless of their level. Good culture benefits everyone, and communication is key to creating good culture. I will discuss how specific communication choices can help anyone enable their team to create a positive, productive environment.
The Habitat Supervisor is responsible for deploying, managing, and choreographing running Habitat services. This session will explore a number of the operational concerns that the supervisor enables. See how to manage secrets, store configuration changes in version control systems, update running applications, and choreograph application upgrades. This is the talk for anyone who is ready to run Habitat services in a production environment.