vBACD - Introduction to Opscode Chef - 2/29

Editor's Notes

• #3: Contratulations! You have yourself some clooooud. But now what?
• #4: But then what? 5 minutes later, you can have an entire rack of servers at your disposal. But until you do one important thing, all they ’re doing is sitting around eating electricity and costing you money.
• #6: Introducing Chef. Hopefully you ’ve already met! Today we're going to talk about what Chef is and what it's good for.
• #7: APIs are awesome. They ’re what make the Cloud the Cloud. You can provision resources by simply flinging the right combination of packets at the appropriate DNS address.
• #8: And Chef can help with that. Knife is our command line tool for talking to APIs And we have plugins for all sorts of cloud providers, both public and private. This lets you provision a server, install the chef agent on it and configure it as a database, webserver, tomcat stack or whatever from a single command.
• #9: Let's walk through the evolution of your infrastructure. Things are going well, you've just started a new project and your new application has come online.
• #10: As you get your feet under you and get a feel for what you're doing, you move your database to another machine to help handle the overloaded box.
• #11: Turns out, the database was the bottleneck, so you add another.
• #12: Demand continues to grow, so you add another application server.
• #13: You're going to need a load balancer for that of course, so everyone can use the same IP.
• #14: And things are really taking off now, 2 load balancers, 5 application servers and a pair of databases. We're growing fast!
• #15: Caching, time to add some
• #16: This Infrastructure has a Topology. All the nodes are talking to each other and need to know about their individual interests. Maybe you don ’t want to do it that way.
• #17: How should I know. It ’s your application. Your application is unique, and so is your infrastructure. They evolve organically.
• #18: And as they evolve, things continue to change as you switch out components and scale
• #19: And success breeds success, we're going nuts now.
• #20: And a basic fact about Infrastructure -- it EVOLVES.
• #21: Currently, the most widely used configuration management strategy is Cloning and Snapshotting. THIS DOES NOT WORK (and you know it.)
• #22: OK, it's a JBoss stack on PostgreSQL with Nagios monitoring.
• #23: Policy change time!!! SSH on port 22 is a security liability (OK, maybe not, but stick with the story)
• #24: First we'll update the sshd_config on 6 golden images
• #25: We'll have to replace the instances that are there
• #26: 12 new boxes, be careful not to break anything. We only have 30 minutes
• #27: IP addresses all changed, since we're in the cloud right? Oh wait, Bob screwed up.
• #28: Tracking all these changes by hand breaks down fast. Mistakes get made and things get overlooked.
• #29: Keep track of all the steps required to take bare metal systems to doing their job in the infrastructure. It is all about the policy. Taking all the systems that have been configured to do their job, and make them work together to actually run the infrastructure.
• #30: How do we do this? WRT Chef, we talk about Fully Automated Infrastructure. Chef provides a framework for fully automating infrastructure, and has some important design principles. Chef makes it easy to reason about your infrastructure at scale and the predictable ordering makes it easy to understand what ’s going on. The declarative Ruby configuration language is easy to read, easy to share and flexible enough to do powerful things. Chef gives you the tools you need to manage large scale infrastructure in a coherent, logical fashion that can be picked up by the next person doing your job.
• #31: In Chef a Node is an Abstraction of a server. With the chef server, node state data is persisted between runs. The edge node does all the heavy lifting. Resources are the things on Nodes that we manage. ... a collection of Resources that can span nodes and networks. Resources are simple things that you deal with every day as a systems administrator or developer. Resources include files, directories, mounts, routes, users, groups, packages installations, source code deployments, configuration files, and “stuff” in general.
• #32: All this is arranged in a very specific way, to it acts in concert to provide ...
• #33: a service. That ’s it. An Application Infrastructure provides a view of all it’s component nodes and their attributes, as well as information that needs to be shared among resources.
• #34: When dealing with Chef, need to literally “think outside the box”, by shifting your thinking about configuration away from a single system, to that of an Application Infrastructure. The concept of an Infrastructure is an abstract one with a specific technical meaning. When we talk about Infrastructure, we mean..
• #35: Chef gives you declarative interfaces into the Resources on those Nodes. Being declarative means that you say what you want to do, instead of how to do it. For example, you declare that package foobar-1.2.3 should be installed, or that the directory /var/log/foobar should exist. Chef pulls down policy from the chef-server, ensuring that a node down for maintenance will receive its policy update when it comes back online.
• #36: Because we use a 3GL for the recipe config files, we can use features of ruby like case statements and iterative loops. Sysadmins don ’t need to be afraid of Ruby, they’ve been dealing with sub-standard programming languages like configuration files for years. They ’re also not limited to what the language tells them they can do.
• #37: By using Ruby we can make calls to web services, in this case we're calling search against the Chef server for all the users stored there. We're going to iterate over them, create the users, their home directories and write out the authorized_keys file. As you need to do more complex and powerful things with your infrastructure, Chef's use of Ruby will allow you to harness whatever resources you need.
• #39: The nodes are going to execute their run lists to configure their Resources defined in your Cookbooks and Recipes. The chef-client maintains the state of your machines, and are also responsible for generating the configuration that is the topology of the infrastructure.
• #47: This is where the sauce is, and what enables systems integration. (back up to previous slide) When provisioning on Clouds, you typically don ’t get to do up front IP address planning So how do you point a web server to its database? You search for it.
• #57: Chef is hackable! Permissive Apache2 license, vibrant community of awesome folks. More than 360 individual contributors, over 70 corporate contributors. Community is very important to us. That's why we're here.