Policyfiles
Hedgpeth, Micheal
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.
 So my name is Michael Hedgebeth. There was a dinner or two, but we're not going to talk about that. My name is Michael Hedgebeth and I am a software architect at NCR. And policy files are a really great and important feature for us. And for a while after their development, they kind of went out of style for a little bit. And I've worked a lot in the last, I guess, nine months to a year to try to bring them back into style. Because I believe that they're a simple and awesome way to do Chef development and to make things, make great things happen in Chef simply. So today we're going to talk about a little bit of my journey. We're going to talk about why policy files like some good things in policy files. We're going to go through a walkthrough of the feature itself. And then we're going to talk about what all the people say on why you wouldn't use policy files and some legitimate and not so legitimate reasons people would say you shouldn't use policy files. We're going to do a demo of policy files in Automate, but a demo as in a screenshot of things they're telling me they're working on. Which is, that's a demo when you're in marketing, right? Not that I'm in marketing. And then we'll answer your question. So my hope today is that you will see policy files as a viable and great method and hopefully going forward the method for doing Chef development. It is so simple. It's a great feature. It makes everything wonderful. So I'm going to make that real for you hopefully this afternoon. So a little bit about me and us. NCR is a 100 plus year old company. We invented the cash register. Yeah. Thank you. Thank you. And actually inventing the cash register was a really big technology revolution. If you can think about what happened before the cash register, there was, you know, they called the mom and pop for a reason. There was mom, pop and family because you could not trust, you could, you didn't have an audit trail of what was happening in a store. So stores couldn't scale past a family because you have the cash drawer that's with no audit. And so with the cash register, that changed all that. And that began the retail revolution 130 years ago, or I guess more than that now. I can't do math right now. 130 something years. And so that was really awesome. And throughout the 20th century, that whole platform was a big deal. Like the IBM, people who started IBM came from NCR. And for the first 25 years of the 20th century, like being at NCR as an executive was your pathway to awesome things in high technology at the time. And, but toward the end of the 20th century, we got into retail. We got into ATMs. But we realized that hardware was becoming a commodity. People were interested in software, software was eating the world. And so we began, NCR began investing in software solutions. One of those is a company that got acquired that I was a part of, Radiant Systems. And my division of NCR focuses on restaurant technology. So anywhere from a fast food restaurant to a fine dining restaurant, they all have my software running in it. And one of our key strategic directions was to try to become an omnichannel platform for our customers who would be anywhere from Home Depot to Chase Bank to Wendy's, for example. And help them go into this omnichannel world, which means you're going to want to order a chicken sandwich potentially on your phone. You might want to drive by. You might want to call ahead. You have a lot of different ways that you want to interact with the business. And in NCR, we help people do that. And so they're really interested in making delivery faster. We are interested in making delivery faster. And so Chef was a part of that strategy. So for me, I started out in development. I still have a development title. And so I kind of grew up in a world of just make the disruptive change and the dumb people will get out of the way and we'll make a ton of money. That's sort of the programmer or developer pattern. I would call it an anti-pattern now as I've learned more. And I was really happy in development. In fact, development is pretty awesome because you don't really have to deal with any real world stuff. You could just blame them on other people. But what I did not like is the fact that investments I was making in our products weren't reaching the customer. And the value that the company was investing in me was not being realized because I did the features, but maybe they weren't the right features because we didn't have a good feedback loop or maybe the features were delayed because we didn't have an efficient and effective way for deploying things. And so almost as a moral thing, I got into DevOps and release automation stuff because I wanted to unblock that value flow going to our customers. And I realized that delivery is really the key to value. But if me as a developer, my feature is not delivered, it's worthless. In fact, it's worse than worthless because they paid me to make something that wasn't delivered. And I'm actually looking forward to, let's what I love about DevOps is that it's sort of making delivery a first-class citizen of the problem domain. And hopefully, I can see a future where delivery is more than a first-class citizen. It's more important to organizations for delivery to happen than for the actual development of the code. So we looked into Chef. Reasons we wanted to do Chef were that we wanted more consistency in our deployments. We're looking at it from an app-centric model, not so much infrastructure. I came from a development background. We wanted to be more efficient. We wanted to speed up. But then I was really excited and I talked to my security team. And they weren't as excited at first because they very accurately sensed my immature attitude of thinking, I'm just going to do all this cool stuff and the dummies are going to get out of the way. And I've had to learn how to be empathetic with them and treat them as first-class citizens, treat operations as first-class citizens. And I'm not that person today. But they were not really happy with this whole Chef stuff. And one of the things that they didn't like is that you can make a lot of different changes to a Chef server and those changes could have drastic effects on your infrastructure. If you think about it, if you're going to change an environment pin to a new cookbook version, you may have just changed the code running on your entire production infrastructure. If you're all sharing a prod environment. And that scared them deeply because if a bad actor got in and made a bad actor change, then they are going to very easily own your whole production infrastructure. That's a scary thing. If I think about this like beyond just Chef, I heard in the news that S3 on the East Coast went down like a few weeks ago. Anybody remember that? So that was due to somebody entering into a search string like too permissive of a wild card on the search. And so they involved orders of magnitude more servers than they thought they would, which brought the Internet down. And to a developer or even in a POC type of thing, that seems really cool. Like, awesome. We can do anything we want to with this thing. But then in that real-world situation, and if you're a security person, if you're worried about change management, that awesome feature that your development or operations people may be salivating over is the potential thing that would bring your whole business down. And NCR provides, this is marketing for a second, NCR powers many of the world's transactions from banking to retail to restaurant. If we went down, you would know about it. It would be in the news. And we live on the trust that our customers give us to be that platform for transactions. And so, no, we're not going to just make some change to a Chef server that is potentially not tested. So change management is hugely important. We also have air-gapped environments, which means that you cannot, you know, from your workstation at your desk, SSH into our prod servers. There's a block there. There are firewalls. There's a whole other network there. And so you can't have the one Chef server that rules them all model. And then you have to have a repeatable way to go from a Chef server to a Chef server where you know what you did before and you know what you did after. And in both locations are consistent. And finally, I mean, the quotable moment was, I'm not going to do DevOps because I'm not going to have developers making changes to production. Like, security felt that the security team felt that Chef or even DevOps, the brand itself, was sort of this chaotic thing. Like, we're going to, we're just, you know, we're getting everybody out of the way. And there's a lot of the kind of cultural undertones to that that they see. And I think there's some reality to that. And so I had to change my mentality and realize, empathize with what they were saying. I think that these concerns are completely legitimate. And you know, I was talking to a friend the other day and they were adopting Chef, very new. And they were talking to me about this team that they were struggling with. And you know, I'm sure you've all been there. I've been there too where you say, you know, that person's stupid or they're just dumb or they just don't want to change. And you've all had that moment if you're trying to get people to implement Chef. But the reality is they probably have very real concerns that you just don't, you're not thinking about. And the way to handle things is to go out to lunch with them and go through their concerns and legitimize them in your mind first. And then try to come up with a collaborative solution because if they're not going to see that you are taking them seriously, that they're not going to listen to you. So off topic, I hope I don't go over time. But this is a little off topic, but pro tip. One of the things that changed my relationship with my security person is one weekend, my security person, the PCI expert at my organization, kept not meeting with me. And finally I got, after three weeks of delay, delay, delay, I finally got a meeting with them. What are we going to do about PCI compliance with our Chef implementation? And realized that I was going to have that meeting on a Monday and it was Friday afternoon. And so I went and bought a PCI book, a 400 page PCI book. And I was motivated because I was so frustrated with not making any progress with this element of my implementation. I read the book over the weekend. And in that meeting that I went to with them, he came up with a requirement and I said, are we talking about requirement 12 or requirement nine here? He said 9.3. And then at that moment, that's when our relationship changed. Because he knew that I wasn't just kind of recklessly coming like the drunk uncle at Thanksgiving. You know, you don't know what that person is going to do, but it's going to be fun. And he didn't want that person at his business Thanksgiving. So we had kind of an impasse of security, not wanting this chaotic DevOps thing happening, but me wanting to drive change with me, starting to understand where they were coming from. This is a real problem that people that they're showing me. And we do not want our whole business to go down even at the service of automation. And so we remember the day Chef blog put out a policy file post I had never heard about the feature until then. And I read through it and I thought, my God, this is exactly what we are needing and looking for. And I immediately wrote out a whole spec on what policy files would look like for us. And they immediately said, yeah, that's exactly what we're talking about. We need proper change management. We need a controlled environment. So overview of policy files real quick. The traditional model with, if you don't have Chef or anything, is you're going to go do your code of application or stuff. You're going to go through QA. You're going to go through UAT. You're going to go to prod. But right before prod, you're going to have all this stuff shoved in at the end. So the consultants will say, let's shift left. And that's really what they mean. They want you to put all of these things all the way at the beginning of QA or whatever. So this is what we're trying to get rid of. We're trying to create a consistent implementation through all the environments. So then if we think about Chef, when I talked to my security team, Chef to them looked like this. And if you're an expert at Chef, like Noah, Noah, do you totally understand all this, right? Yeah, thumbs up. Noah gets it, right? This is not the problem, though. The problem is, when a security person is looking at all of this, they are thinking chaos. So what I'm illustrating here is that in the traditional Chef model, you have a lot of different elements in Chef that could be change events to your servers. And that should scare you because it's harder to control. The more change events that happen, the more difficult to control. So you could be changing your role, and that could change everything in production. Did you test that role in earlier environments? Maybe not. You could change your environment. You could change a cookbook. You could accidentally not increment a cookbook version, but then change a cookbook. And that's really difficult to figure out. So this traditional Chef model, I am going to argue, is much more difficult to manage from a change management perspective. And the policy files model says, let's take all of what was there before, all of these roles, all these environments, all these cookbooks, and let's put them into a policy. And all of the concerns that we are looking at go into that policy as well. And those policies and the code that go alongside them can go through the environments where you can trust that I'm running this Chef code with this version of software or whatever, or these versions of software, and I'm promoting them through the environment. By the way, if you're looking at Docker, which is the cool stuff these days, that's this Docker file right there, right? You've got something that you promote through your environments. If you look at Habitat, which is the even cooler stuff these days, it's the same thing. You have a Habitat package that goes through your environments. So what policy files do is they take the model that we've proven with Docker, the model that we've proven with Habitat, and it also applies that same model to a Chef workflow, which makes everything better. You get all of the benefits that those smart people and those other tools have realized, by making their tooling that way, that's what you get with policy files as well. So the other benefit with policy files that I've seen, and I've heard this from my friends in the community, so it's not just me. I believe that with policy files, you will onboard people with Chef in 20% of the time that you have been onboarding them. If people say Chef is difficult to learn, you need to ask yourself the question, are Cookbooks difficult to write? In my experience at NCR, Cookbooks are not difficult to write. You set people up with a skeleton Cookbook, you tell them, here's the resources, and you show them a process. Great, they can code a Cookbook. The problem comes about when you're talking about a role, an environment, pinning, Birkshelf, all these other things that go around with Cookbook development are difficult to teach and learn. People don't want to. So what we do at NCR is we leave all that out of it. We say, okay, you're dealing with data bags and you're dealing with policy files. The policy files, I don't even have to tell them this is a policy file. I'll just show them the four lines that we'll see in just a few minutes of what the policy file is, and they deal with data bags. Then with these other things, they don't even have to worry about them. That's a feature and not a bug because it simplifies everything for them. So those are some of the benefits of policy files. Let me take a second for questions. Anybody have questions so far about? Yeah? Make a sense? Okay, cool. So let's go through policy files. Now, let me be fully full disclosure here. You can find all of this. What I'm going to tell you is basically ripped off of my blog post on policy files. So hedge-ops.com forward slash policy files. You can read all this in that. And then if you go onto the hashtag policy files channel on the Chef community Slack, that blog post is pinned as well. So I'm just sort of talking to you about what you can read. But it's part of the talk. So there we go. So policy file, this is the basic feature. This is almost like anybody ever do a DevOps demo where you push the button and you tell people the whole point of this is it should be boring because it just does all the things. And you don't want to show them the command line because that's not really a big deal. So demoing policy files is similar because policy files are very simple. So I'm going to try to make it as interesting as I possibly can even though it's incredibly simple. So a policy file starts with a policy file dot rb. It is generated by a notepad or notepad, Windows, right? Adam, is that what the cool kids are using? It's generated with that or it's generated with Chef command. So you can generate the policy file. But an example is probably more instructive is this. So we've got four lines here. First off, you've got the policy name. So the policy name is like maybe a role name for a server. So for us, we would have insight-webserver, so a product name and then a role. So policy name is like a role. You can think of a set of servers to get a policy name that you are categorizing. The other thing is where are you getting your cookbooks from? So that's similar to what you may notice with Birkshelf. I'm getting it from the supermarket. We use a private supermarket, which I highly recommend. It's awesome. But you can use the Chef supermarket. You can even use two supermarkets so you can fall back on the public supermarket but use a private supermarket for your own stuff. Then it asks for a run list. Hopefully you know what that is. And then it asks for any exceptions that you have to what you just told them. So hey, I'd like to get all my cookbooks from the supermarket, but there's this one that I need to have a particular pull request or a forked branch or something like that or my internal cookbook or whatever. I'm not using a supermarket. So that's a policy file. So another aside, it was always funny like when we're learning Chef, you get on these calls where something goes wrong and then people start blaming Chef. Well, maybe it's Chef. Chef is this mythical God of war. It's not, I mean, Chef isn't magical. It ends up being code somewhere. And it usually isn't Chef because Chef is way more tested than any other thing that, or the way we're doing it. It's way more tested than anything that they're dealing with otherwise. And so like when you hear policy files, you know, oh, policy files. Well, it's those four lines. It's really simple. Okay. It's just a file that says what is a category of servers that I'm dealing with? That's the policy name. Where do I get my cookbooks from? And what am I going to run on that machine? Okay. This is sometimes checked in on your cookbook. And well, I guess I'll get to that later, but it's sometimes checked in your cookbook. It's checked in the source somewhere. All right. So that's a policy file. You might think, what am I going to do with attributes? So maybe you stopped listening to me a few minutes ago because I didn't like queue you up with this and think, oh, you're going to get rid of environments and you're going to get rid of roles. You know, that really scares me because I use those for some attributes. So there are different ways that you can handle this. So you're going to have to do some change of using attributes and environments or roles. One way is that you can declare attributes inside the policy file as well. So some of our policy files, in fact, many of our policy files are not four lines long because they include attribute information. And if you can see here, there is the attributes here are defined in hash, but it's grouped by kind of what you could think of as an environment. So I have attributes grouped by QA, UAT, and production. And those groups are called policy groups. We can think of a policy group as an environment. It's kind of the same thing. So I declared the attributes right there. And I can consume those attributes in a recipe. Noah told me that the Chef Config policy group can be node policy group, sorry, no, for not updating that slide. But you can also use Noah's poise. You say poise, right? Yeah, poise hoist. I practiced a lot to try to say that the right way because I was nervous. So what poise hoist does is it takes your policy group and it promotes attributes that were based on that group like in this previous slide here. Like the default QA, you have MyApp database. If you're running poise hoist, it will hoist those attributes up to the node level. So I would see MyApp database and it would do that based on the policy group that's there. So very many things to Noah for creating that. Noah has been, I guess we've been hand in hand on let's get policy files working. We're both on the crusade together. So attributes are pretty easy. And I think if you're talking about migration, that's probably one of the biggest pain points is if you have nodes, if you have attributes declaring your roles or your environments, you can declare them there or you can declare them in a role cookbook. That's probably a good pattern for you. And then this would take care of the environment stuff. So that's how you handle attributes. And now it's time to generate a lock file. So a lock file is basically all of the dependencies that you need to run Chef in a JSON file. So you run that with this command right here, Chef install, and then the policy file. And what that does is it takes your, it's kind of like if you use Birx, it's a Birx install. So it takes all of what you declared and it says, okay, I'm going to, you're told me to get this cookbook from the supermarket. I'm going to go to the supermarket, look for the latest version or whatever it is and get that cookbook locally and then save what cookbook I'm using to this lock file. So here we have the very top of a lock file. The very coolest part of this is the revision ID, which looks like a confusing set of characters and it is, but the awesome part about this is that you can know exactly based on this JSON file, if you check it into Git, you can know exactly what you're running in production. So the very first thing that you'll see whenever you're running Chef Client is we're running the policy named this, again, script this with revision ID, that one. And so you can go and know exactly what you're running. This is the policy that I'm running. And by the way, this happens way before your code runs. This is totally separate. You are doing all of your calculations for dependencies and everything that needs to run with Chef in your development environment, inside of your build part of the process, not in your run part of the process. And then there is also cookbook data in there. So this made the security people get really excited because there's a little bit of a problem with secure change management with cookbooks in traditional Chef. And that is I can have version 1.0.0 of a cookbook and I can be a bad actor and put in a virus in that cookbook code and I can force push that cookbook version 1.0.0 to my Chef server and if that's connected to a role that is global or something, all of a sudden my whole infrastructure got owned because even though it says 1.0.0, it's not really 1.0.0.0. There's no guarantee there. And that's scary. Even if you did all the good things around roles, even if you did all the good things around environments with change management, you did everything right down the row with what people are telling you, you still have that problem. You can deal with it with access control, but maybe. So here you have this, my favorite feature of policy files to be honest. This dotted decimal, no, yeah, yeah. Is it, no, it's the identifier. Is Dan here? It's the identifier. It's the identifier. Thanks. You get this identifier. My favorite feature, I don't even know where it is. The identifier is a checksum of the cookbook's contents. And Chef will not run if that checksum is different. So you get all the way to production and it says, okay, I want this, I want to download this cookbook. Awesome. Wait a minute. Somebody has tampered with this cookbook. We're not running Chef right now. And so you have full change control. This is, I tell my Windows friends, of which I am in the Windows community, I tell them this is almost like taking Chef and compiling it into an executable. Like there is, you are doing static binding to other DLLs in Windows world terms, but you're doing a static binding to your cookbooks so that you cannot unbreak those bindings. You could try to do some things, but Chef Client will not run for that. And so this makes it extremely controllable. Everything is declared in one place and everything is safe and simple to use and run. So after you get the lock file, you are now ready to push it to your Chef server. So how do I push a policy? I just do Chef push policy group and then my policy file. Behind there is the lock file that you already created. So that policy group, again, is a set of servers. This is kind of an environment concept where you have a QA environment, a production environment. Or you can split things into policy groups in however many ways you want. You could have prod A and prod B policy group. And we've done some of that. If you want to test out a Chef change even within production. Those are just completely arbitrary, by the way. By putting push QA, you're actually creating that policy group on Chef server. So it's not really any management around that. It's just you're giving an arbitrary name. And if you're using an air gap environment, this is the coolest feature ever other than the identifier one. You can say I want to export my entire policy into a file. And you can do whatever it is you do to get that thing to production. If it's walking through, walking past the machine gun people, it's that. Or you have the, I guess the, what was it, the USB inside of the Rubik's cube or whatever. That's an Everstone reference. If you, whatever you need to do to get your stuff to production, you can have a file that does it all. And the cool thing here too is that feature itself kind of tells you the coolness of policy files and that policy files are an encapsulated set of dependencies on the Chef server. Like you, another policy file because you have that awesome identifier thing is never going to mess with your policy file. You are getting a guarantee of here is the Chef code that is going to run on the server, period. There's nothing around it. It's a guarantee. It's a contract that this feature gives you, that you are not going to get anywhere else. And so I can put that, put all of those dependencies into a archive. So it's got all the cookbook dependencies and everything. And then I can walk it to production or whatever it is I do and upload it to the Chef server with Chef push archive, sorry, Chef push archive to the policy group and then give it the file name. So if you are struggling with your Chef implementation with regard to air gap environments because it's difficult for you to move Chef objects from one Chef server to the other, it behooves you to use this feature. And I was going to bet that I would use the word behoove in this talk because it's an awesome kind of old English word. But it behooves you to use this feature because it makes everything so much simpler and controllable. And actually, it follows the spirit of an air gap environment way better than you're rolling a lot of different changes to the Chef server and hoping that you have a consistency with other environments that you're dealing with. Okay. So now, how would I bootstrap something? You can do that with Knife Bootstrap. You would use the policy group and policy name and you would get a node that bootstrap with policy files. So, and I know it is kind of weird that we're talking about policy files as sort of an out of vogue feature in the past, but it's fully baked into Chef right now and I've been running it into production for over a year. So this is an old feature that's been tested and we're not announcing anything today, right? This is just how it is. So, you can bootstrap with the policy group and policy name. You can also, maybe, yeah, you can also include policy group and policy name in your attributes. So this is how you're defining, here's my node, what's the name of the policy? Like it's my insight web server, what's the policy group? This is a QA policy group. So you do that in attributes.json that you'd pass in as Chef Client as your bootstrapping or you can even change the node object and give it a policy group and policy name and then it would switch to policy file mode. So even if you're running something with classic Chef right now, all you have to do is define these two things here and you are now in policy file mode magically like that. It's already baked into everything and it just works that way. There's nothing really else to turn on. All right. So then pipeline for us. If you go to my blog, hedge-ops.com, that's hdge-ops.com, you'll see a lot of blog posts that I wrote in the last week largely because I didn't feel like I could explain this very succinctly. And so I've written a lot of blog posts of how do we use policy files and how do we promote them through an environment with Jenkins and Artifactory, et cetera. But the basic here is we package the policies because everything for us is an air-gapped environment. We package the policies and we publish them to Artifactory and then we push them to an air-gapped Artifactory and consume them there by using those Chef push archive commands. If you want to read more, check out my blog on that. So then here's running Chef. Like I said earlier, Chef, when you run it with policy files, it just works. I would argue it works way better. And it just says here I'm running policies. So some potential drawbacks. Why people would not use policy files? I've heard before, more in the past than in the present, I won't use policy files because Chef does not support policy files. And I will brag on my customer success team and the Chef support team. They have completely supported policy files for NCR. It's been fantastic. There's no problem there. And so that should not be a concern of yours if you're a Chef customer. The community is there and the support's there. And does Chef automate support policy files? That's a little bit different in question. Up until now, they have not. There are no current concrete plans to do that in Chef workflow because the Chef workflow stuff is a little different than policy files workflow. But for visibility, it is in active development. And let me try. In the few minutes I have left to show you that. So this is what I saw just yesterday. These are mockups of what policy files inside of automate would look like. And this is under active development by Chef Inc. at the moment. So they're thinking, they're just going to put policy group and policy name in a filter there. So you can see your nodes by policy group, policy name. And then when you get to the node level, you'll see policy group, policy name in the node data. And then when you look at your run list, you'll see the cookbook, the full hash version of the cookbook rather than just the cookbook version. We talked about that earlier. So what's cool about this is all we need to do is turn on data source of policy file information into Chef automate. These are pretty simple. I think UI changes are going to be made to Chef automate to support policy files. And we're very excited about those. We're going to appreciate it to Chef for being on board with making them. So yes, it will be supported in Chef automate and in the visibility component. And finally, what do I do about zero day changes? So I got like three minutes left. I'm going to race through this. But this is a big concern. So if you're thinking about policy files, you really need to listen up because this is a potential negative. If you have policy files, you potentially have a policy file per group of servers all throughout your infrastructure. And if you have a zero day incident and need to roll out a cookbook to everything to recover from the zero day incident, that's going to be more difficult with policy files than it will be without it. Because we were talking about how policy files are encapsulated behavior that you promote through everything. You can't just push one button and update all the things. I view that as a feature, not a bug. We talked about that earlier that with great power comes great responsibility. And I do not want that responsibility. So your results may vary. If you really feel that you're using Chef just because you want to be able to update things in production immediately, great. Go for it. And you may not want to use policy files. But I believe that the control and the change management that you get from policy files will give you that speed of delivery and safe delivery. So the zero day change could be done with policy files if you focus on having a solid pipeline going through all your stuff. And that you could use this, but it will help you do that a lot more safer, especially for the days in which you don't need zero day changes. So hopefully this got you excited with policy files. You can find me on Twitter on at Michael Hedgepeth. Also there's the text of my blog where you can find all of the policy files post and all the other posts related to how we do deployment. And also I monitor this channel pretty regularly along with the people at Chef who have developed policy files, know is there. This policy files channel and the Chef community is a great place to get help. So hopefully a lot of you are inspired to implement this awesome feature to make your lives better. And I am looking forward to the future and hearing how it goes. Thanks everybody. Thank you. Thank you.
 So my name is Michael Hedgebeth.  There was a dinner or two, but we're not going to talk about that.  My name is Michael Hedgebeth and I am a software architect at NCR.  And policy files are a really great and important feature for us.  And for a while after their development, they kind of went out of style for a little bit.  And I've worked a lot in the last, I guess, nine months to a year to try to bring them  back into style.  Because I believe that they're a simple and awesome way to do Chef development and to  make things, make great things happen in Chef simply.  So today we're going to talk about a little bit of my journey.  We're going to talk about why policy files like some good things in policy files.  We're going to go through a walkthrough of the feature itself.  And then we're going to talk about what all the people say on why you wouldn't use policy  files and some legitimate and not so legitimate reasons people would say you shouldn't use  policy files.  We're going to do a demo of policy files in Automate, but a demo as in a screenshot of  things they're telling me they're working on.  Which is, that's a demo when you're in marketing, right?  Not that I'm in marketing.  And then we'll answer your question.  So my hope today is that you will see policy files as a viable and great method and hopefully  going forward the method for doing Chef development.  It is so simple.  It's a great feature.  It makes everything wonderful.  So I'm going to make that real for you hopefully this afternoon.  So a little bit about me and us.  NCR is a 100 plus year old company.  We invented the cash register.  Yeah.  Thank you.  Thank you.  And actually inventing the cash register was a really big technology revolution.  If you can think about what happened before the cash register, there was, you know, they  called the mom and pop for a reason.  There was mom, pop and family because you could not trust, you could, you didn't have  an audit trail of what was happening in a store.  So stores couldn't scale past a family because you have the cash drawer that's with no audit.  And so with the cash register, that changed all that.  And that began the retail revolution 130 years ago, or I guess more than that now.  I can't do math right now.  130 something years.  And so that was really awesome.  And throughout the 20th century, that whole platform was a big deal.  Like the IBM, people who started IBM came from NCR.  And for the first 25 years of the 20th century, like being at NCR as an executive was your  pathway to awesome things in high technology at the time.  And, but toward the end of the 20th century, we got into retail.  We got into ATMs.  But we realized that hardware was becoming a commodity.  People were interested in software, software was eating the world.  And so we began, NCR began investing in software solutions.  One of those is a company that got acquired that I was a part of, Radiant Systems.  And my division of NCR focuses on restaurant technology.  So anywhere from a fast food restaurant to a fine dining restaurant, they all have my  software running in it.  And one of our key strategic directions was to try to become an omnichannel platform for  our customers who would be anywhere from Home Depot to Chase Bank to Wendy's, for example.  And help them go into this omnichannel world, which means you're going to want to order  a chicken sandwich potentially on your phone.  You might want to drive by.  You might want to call ahead.  You have a lot of different ways that you want to interact with the business.  And in NCR, we help people do that.  And so they're really interested in making delivery faster.  We are interested in making delivery faster.  And so Chef was a part of that strategy.  So for me, I started out in development.  I still have a development title.  And so I kind of grew up in a world of just make the disruptive change and the dumb people  will get out of the way and we'll make a ton of money.  That's sort of the programmer or developer pattern.  I would call it an anti-pattern now as I've learned more.  And I was really happy in development.  In fact, development is pretty awesome because you don't really have to deal with any real  world stuff.  You could just blame them on other people.  But what I did not like is the fact that investments I was making in our products weren't reaching  the customer.  And the value that the company was investing in me was not being realized because I did  the features, but maybe they weren't the right features because we didn't have a good feedback  loop or maybe the features were delayed because we didn't have an efficient and effective  way for deploying things.  And so almost as a moral thing, I got into DevOps and release automation stuff because  I wanted to unblock that value flow going to our customers.  And I realized that delivery is really the key to value.  But if me as a developer, my feature is not delivered, it's worthless.  In fact, it's worse than worthless because they paid me to make something that wasn't  delivered.  And I'm actually looking forward to, let's what I love about DevOps is that it's sort  of making delivery a first-class citizen of the problem domain.  And hopefully, I can see a future where delivery is more than a first-class citizen.  It's more important to organizations for delivery to happen than for the actual development  of the code.  So we looked into Chef.  Reasons we wanted to do Chef were that we wanted more consistency in our deployments.  We're looking at it from an app-centric model, not so much infrastructure.  I came from a development background.  We wanted to be more efficient.  We wanted to speed up.  But then I was really excited and I talked to my security team.  And they weren't as excited at first because they very accurately sensed my immature attitude  of thinking, I'm just going to do all this cool stuff and the dummies are going to get  out of the way.  And I've had to learn how to be empathetic with them and treat them as first-class citizens,  treat operations as first-class citizens.  And I'm not that person today.  But they were not really happy with this whole Chef stuff.  And one of the things that they didn't like is that you can make a lot of different changes  to a Chef server and those changes could have drastic effects on your infrastructure.  If you think about it, if you're going to change an environment pin to a new cookbook  version, you may have just changed the code running on your entire production infrastructure.  If you're all sharing a prod environment.  And that scared them deeply because if a bad actor got in and made a bad actor change,  then they are going to very easily own your whole production infrastructure.  That's a scary thing.  If I think about this like beyond just Chef, I heard in the news that S3 on the East Coast  went down like a few weeks ago.  Anybody remember that?  So that was due to somebody entering into a search string like too permissive of a wild  card on the search.  And so they involved orders of magnitude more servers than they thought they would, which  brought the Internet down.  And to a developer or even in a POC type of thing, that seems really cool.  Like, awesome.  We can do anything we want to with this thing.  But then in that real-world situation, and if you're a security person, if you're worried  about change management, that awesome feature that your development or operations people  may be salivating over is the potential thing that would bring your whole business down.  And NCR provides, this is marketing for a second, NCR powers many of the world's transactions  from banking to retail to restaurant.  If we went down, you would know about it.  It would be in the news.  And we live on the trust that our customers give us to be that platform for transactions.  And so, no, we're not going to just make some change to a Chef server that is potentially  not tested.  So change management is hugely important.  We also have air-gapped environments, which means that you cannot, you know, from your  workstation at your desk, SSH into our prod servers.  There's a block there.  There are firewalls.  There's a whole other network there.  And so you can't have the one Chef server that rules them all model.  And then you have to have a repeatable way to go from a Chef server to a Chef server  where you know what you did before and you know what you did after.  And in both locations are consistent.  And finally, I mean, the quotable moment was, I'm not going to do DevOps because I'm  not going to have developers making changes to production.  Like, security felt that the security team felt that Chef or even DevOps, the brand itself,  was sort of this chaotic thing.  Like, we're going to, we're just, you know, we're getting everybody out of the way.  And there's a lot of the kind of cultural undertones to that that they see.  And I think there's some reality to that.  And so I had to change my mentality and realize, empathize with what they were saying.  I think that these concerns are completely legitimate.  And you know, I was talking to a friend the other day and they were adopting Chef, very  new.  And they were talking to me about this team that they were struggling with.  And you know, I'm sure you've all been there.  I've been there too where you say, you know, that person's stupid or they're just dumb  or they just don't want to change.  And you've all had that moment if you're trying to get people to implement Chef.  But the reality is they probably have very real concerns that you just don't, you're  not thinking about.  And the way to handle things is to go out to lunch with them and go through their concerns  and legitimize them in your mind first.  And then try to come up with a collaborative solution because if they're not going to see  that you are taking them seriously, that they're not going to listen to you.  So off topic, I hope I don't go over time.  But this is a little off topic, but pro tip.  One of the things that changed my relationship with my security person is one weekend, my  security person, the PCI expert at my organization, kept not meeting with me.  And finally I got, after three weeks of delay, delay, delay, I finally got a meeting with  them.  What are we going to do about PCI compliance with our Chef implementation?  And realized that I was going to have that meeting on a Monday and it was Friday afternoon.  And so I went and bought a PCI book, a 400 page PCI book.  And I was motivated because I was so frustrated with not making any progress with this element  of my implementation.  I read the book over the weekend.  And in that meeting that I went to with them, he came up with a requirement and I said,  are we talking about requirement 12 or requirement nine here?  He said 9.3.  And then at that moment, that's when our relationship changed.  Because he knew that I wasn't just kind of recklessly coming like the drunk uncle at  Thanksgiving.  You know, you don't know what that person is going to do, but it's going to be fun.  And he didn't want that person at his business Thanksgiving.  So we had kind of an impasse of security, not wanting this chaotic DevOps thing happening,  but me wanting to drive change with me, starting to understand where they were coming from.  This is a real problem that people that they're showing me.  And we do not want our whole business to go down even at the service of automation.  And so we remember the day Chef blog put out a policy file post I had never heard about  the feature until then.  And I read through it and I thought, my God, this is exactly what we are needing and looking  for.  And I immediately wrote out a whole spec on what policy files would look like for us.  And they immediately said, yeah, that's exactly what we're talking about.  We need proper change management.  We need a controlled environment.  So overview of policy files real quick.  The traditional model with, if you don't have Chef or anything, is you're going to go do  your code of application or stuff.  You're going to go through QA.  You're going to go through UAT.  You're going to go to prod.  But right before prod, you're going to have all this stuff shoved in at the end.  So the consultants will say, let's shift left.  And that's really what they mean.  They want you to put all of these things all the way at the beginning of QA or whatever.  So this is what we're trying to get rid of.  We're trying to create a consistent implementation through all the environments.  So then if we think about Chef, when I talked to my security team, Chef to them looked like  this.  And if you're an expert at Chef, like Noah, Noah, do you totally understand all this,  right?  Yeah, thumbs up.  Noah gets it, right?  This is not the problem, though.  The problem is, when a security person is looking at all of this, they are thinking chaos.  So what I'm illustrating here is that in the traditional Chef model, you have a lot of  different elements in Chef that could be change events to your servers.  And that should scare you because it's harder to control.  The more change events that happen, the more difficult to control.  So you could be changing your role, and that could change everything in production.  Did you test that role in earlier environments?  Maybe not.  You could change your environment.  You could change a cookbook.  You could accidentally not increment a cookbook version, but then change a cookbook.  And that's really difficult to figure out.  So this traditional Chef model, I am going to argue, is much more difficult to manage  from a change management perspective.  And the policy files model says, let's take all of what was there before, all of these  roles, all these environments, all these cookbooks, and let's put them into a policy.  And all of the concerns that we are looking at go into that policy as well.  And those policies and the code that go alongside them can go through the environments where  you can trust that I'm running this Chef code with this version of software or whatever,  or these versions of software, and I'm promoting them through the environment.  By the way, if you're looking at Docker, which is the cool stuff these days, that's this  Docker file right there, right?  You've got something that you promote through your environments.  If you look at Habitat, which is the even cooler stuff these days, it's the same thing.  You have a Habitat package that goes through your environments.  So what policy files do is they take the model that we've proven with Docker, the model that  we've proven with Habitat, and it also applies that same model to a Chef workflow, which makes  everything better.  You get all of the benefits that those smart people and those other tools have realized,  by making their tooling that way, that's what you get with policy files as well.  So the other benefit with policy files that I've seen, and I've heard this from my friends  in the community, so it's not just me.  I believe that with policy files, you will onboard people with Chef in 20% of the time  that you have been onboarding them.  If people say Chef is difficult to learn, you need to ask yourself the question, are  Cookbooks difficult to write?  In my experience at NCR, Cookbooks are not difficult to write.  You set people up with a skeleton Cookbook, you tell them, here's the resources, and you  show them a process.  Great, they can code a Cookbook.  The problem comes about when you're talking about a role, an environment, pinning, Birkshelf,  all these other things that go around with Cookbook development are difficult to teach  and learn.  People don't want to.  So what we do at NCR is we leave all that out of it.  We say, okay, you're dealing with data bags and you're dealing with policy files.  The policy files, I don't even have to tell them this is a policy file.  I'll just show them the four lines that we'll see in just a few minutes of what the policy  file is, and they deal with data bags.  Then with these other things, they don't even have to worry about them.  That's a feature and not a bug because it simplifies everything for them.  So those are some of the benefits of policy files.  Let me take a second for questions.  Anybody have questions so far about?  Yeah?  Make a sense?  Okay, cool.  So let's go through policy files.  Now, let me be fully full disclosure here.  You can find all of this.  What I'm going to tell you is basically ripped off of my blog post on policy files.  So hedge-ops.com forward slash policy files.  You can read all this in that.  And then if you go onto the hashtag policy files channel on the Chef community Slack,  that blog post is pinned as well.  So I'm just sort of talking to you about what you can read.  But it's part of the talk.  So there we go.  So policy file, this is the basic feature.  This is almost like anybody ever do a DevOps demo where you push the button and you tell  people the whole point of this is it should be boring because it just does all the things.  And you don't want to show them the command line because that's not really a big deal.  So demoing policy files is similar because policy files are very simple.  So I'm going to try to make it as interesting as I possibly can even though it's incredibly  simple.  So a policy file starts with a policy file dot rb.  It is generated by a notepad or notepad, Windows, right?  Adam, is that what the cool kids are using?  It's generated with that or it's generated with Chef command.  So you can generate the policy file.  But an example is probably more instructive is this.  So we've got four lines here.  First off, you've got the policy name.  So the policy name is like maybe a role name for a server.  So for us, we would have insight-webserver, so a product name and then a role.  So policy name is like a role.  You can think of a set of servers to get a policy name that you are categorizing.  The other thing is where are you getting your cookbooks from?  So that's similar to what you may notice with Birkshelf.  I'm getting it from the supermarket.  We use a private supermarket, which I highly recommend.  It's awesome.  But you can use the Chef supermarket.  You can even use two supermarkets so you can fall back on the public supermarket but use  a private supermarket for your own stuff.  Then it asks for a run list.  Hopefully you know what that is.  And then it asks for any exceptions that you have to what you just told them.  So hey, I'd like to get all my cookbooks from the supermarket, but there's this one that  I need to have a particular pull request or a forked branch or something like that or  my internal cookbook or whatever.  I'm not using a supermarket.  So that's a policy file.  So another aside, it was always funny like when we're learning Chef, you get on these  calls where something goes wrong and then people start blaming Chef.  Well, maybe it's Chef.  Chef is this mythical God of war.  It's not, I mean, Chef isn't magical.  It ends up being code somewhere.  And it usually isn't Chef because Chef is way more tested than any other thing that,  or the way we're doing it.  It's way more tested than anything that they're dealing with otherwise.  And so like when you hear policy files, you know, oh, policy files.  Well, it's those four lines.  It's really simple.  Okay.  It's just a file that says what is a category of servers that I'm dealing with?  That's the policy name.  Where do I get my cookbooks from?  And what am I going to run on that machine?  Okay.  This is sometimes checked in on your cookbook.  And well, I guess I'll get to that later, but it's sometimes checked in your cookbook.  It's checked in the source somewhere.  All right.  So that's a policy file.  You might think, what am I going to do with attributes?  So maybe you stopped listening to me a few minutes ago because I didn't like queue you  up with this and think, oh, you're going to get rid of environments and you're going to  get rid of roles.  You know, that really scares me because I use those for some attributes.  So there are different ways that you can handle this.  So you're going to have to do some change of using attributes and environments or roles.  One way is that you can declare attributes inside the policy file as well.  So some of our policy files, in fact, many of our policy files are not four lines long  because they include attribute information.  And if you can see here, there is the attributes here are defined in hash, but it's grouped  by kind of what you could think of as an environment.  So I have attributes grouped by QA, UAT, and production.  And those groups are called policy groups.  We can think of a policy group as an environment.  It's kind of the same thing.  So I declared the attributes right there.  And I can consume those attributes in a recipe.  Noah told me that the Chef Config policy group can be node policy group, sorry, no, for not  updating that slide.  But you can also use Noah's poise.  You say poise, right?  Yeah, poise hoist.  I practiced a lot to try to say that the right way because I was nervous.  So what poise hoist does is it takes your policy group and it promotes attributes that  were based on that group like in this previous slide here.  Like the default QA, you have MyApp database.  If you're running poise hoist, it will hoist those attributes up to the node level.  So I would see MyApp database and it would do that based on the policy group that's there.  So very many things to Noah for creating that.  Noah has been, I guess we've been hand in hand on let's get policy files working.  We're both on the crusade together.  So attributes are pretty easy.  And I think if you're talking about migration, that's probably one of the biggest pain points  is if you have nodes, if you have attributes declaring your roles or your environments,  you can declare them there or you can declare them in a role cookbook.  That's probably a good pattern for you.  And then this would take care of the environment stuff.  So that's how you handle attributes.  And now it's time to generate a lock file.  So a lock file is basically all of the dependencies that you need to run Chef in a JSON file.  So you run that with this command right here, Chef install, and then the policy file.  And what that does is it takes your, it's kind of like if you use Birx, it's a Birx install.  So it takes all of what you declared and it says, okay, I'm going to, you're told me  to get this cookbook from the supermarket.  I'm going to go to the supermarket, look for the latest version or whatever it is and get  that cookbook locally and then save what cookbook I'm using to this lock file.  So here we have the very top of a lock file.  The very coolest part of this is the revision ID, which looks like a confusing set of characters  and it is, but the awesome part about this is that you can know exactly based on this  JSON file, if you check it into Git, you can know exactly what you're running in production.  So the very first thing that you'll see whenever you're running Chef Client is we're running  the policy named this, again, script this with revision ID, that one.  And so you can go and know exactly what you're running.  This is the policy that I'm running.  And by the way, this happens way before your code runs.  This is totally separate.  You are doing all of your calculations for dependencies and everything that needs to  run with Chef in your development environment, inside of your build part of the process,  not in your run part of the process.  And then there is also cookbook data in there.  So this made the security people get really excited because there's a little bit of a  problem with secure change management with cookbooks in traditional Chef.  And that is I can have version 1.0.0 of a cookbook and I can be a bad actor and put in a virus  in that cookbook code and I can force push that cookbook version 1.0.0 to my Chef server  and if that's connected to a role that is global or something, all of a sudden my whole  infrastructure got owned because even though it says 1.0.0, it's not really 1.0.0.0.  There's no guarantee there.  And that's scary.  Even if you did all the good things around roles, even if you did all the good things  around environments with change management, you did everything right down the row with  what people are telling you, you still have that problem.  You can deal with it with access control, but maybe.  So here you have this, my favorite feature of policy files to be honest.  This dotted decimal, no, yeah, yeah.  Is it, no, it's the identifier.  Is Dan here?  It's the identifier.  It's the identifier.  Thanks.  You get this identifier.  My favorite feature, I don't even know where it is.  The identifier is a checksum of the cookbook's contents.  And Chef will not run if that checksum is different.  So you get all the way to production and it says, okay, I want this, I want to download  this cookbook.  Awesome.  Wait a minute.  Somebody has tampered with this cookbook.  We're not running Chef right now.  And so you have full change control.  This is, I tell my Windows friends, of which I am in the Windows community, I tell them  this is almost like taking Chef and compiling it into an executable.  Like there is, you are doing static binding to other DLLs in Windows world terms, but  you're doing a static binding to your cookbooks so that you cannot unbreak those bindings.  You could try to do some things, but Chef Client will not run for that.  And so this makes it extremely controllable.  Everything is declared in one place and everything is safe and simple to use and run.  So after you get the lock file, you are now ready to push it to your Chef server.  So how do I push a policy?  I just do Chef push policy group and then my policy file.  Behind there is the lock file that you already created.  So that policy group, again, is a set of servers.  This is kind of an environment concept where you have a QA environment, a production environment.  Or you can split things into policy groups in however many ways you want.  You could have prod A and prod B policy group.  And we've done some of that.  If you want to test out a Chef change even within production.  Those are just completely arbitrary, by the way.  By putting push QA, you're actually creating that policy group on Chef server.  So it's not really any management around that.  It's just you're giving an arbitrary name.  And if you're using an air gap environment, this is the coolest feature ever other than  the identifier one.  You can say I want to export my entire policy into a file.  And you can do whatever it is you do to get that thing to production.  If it's walking through, walking past the machine gun people, it's that.  Or you have the, I guess the, what was it, the USB inside of the Rubik's cube or whatever.  That's an Everstone reference.  If you, whatever you need to do to get your stuff to production, you can have a file that  does it all.  And the cool thing here too is that feature itself kind of tells you the coolness of policy  files and that policy files are an encapsulated set of dependencies on the Chef server.  Like you, another policy file because you have that awesome identifier thing is never  going to mess with your policy file.  You are getting a guarantee of here is the Chef code that is going to run on the server,  period.  There's nothing around it.  It's a guarantee.  It's a contract that this feature gives you, that you are not going to get anywhere else.  And so I can put that, put all of those dependencies into a archive.  So it's got all the cookbook dependencies and everything.  And then I can walk it to production or whatever it is I do and upload it to the Chef server  with Chef push archive, sorry, Chef push archive to the policy group and then give  it the file name.  So if you are struggling with your Chef implementation with regard to air gap environments because  it's difficult for you to move Chef objects from one Chef server to the other, it behooves  you to use this feature.  And I was going to bet that I would use the word behoove in this talk because it's an  awesome kind of old English word.  But it behooves you to use this feature because it makes everything so much simpler and controllable.  And actually, it follows the spirit of an air gap environment way better than you're  rolling a lot of different changes to the Chef server and hoping that you have a consistency  with other environments that you're dealing with.  Okay.  So now, how would I bootstrap something?  You can do that with Knife Bootstrap.  You would use the policy group and policy name and you would get a node that bootstrap  with policy files.  So, and I know it is kind of weird that we're talking about policy files as sort of an out  of vogue feature in the past, but it's fully baked into Chef right now and I've been running  it into production for over a year.  So this is an old feature that's been tested and we're not announcing anything today, right?  This is just how it is.  So, you can bootstrap with the policy group and policy name.  You can also, maybe, yeah, you can also include policy group and policy name in your attributes.  So this is how you're defining, here's my node, what's the name of the policy?  Like it's my insight web server, what's the policy group?  This is a QA policy group.  So you do that in attributes.json that you'd pass in as Chef Client as your bootstrapping  or you can even change the node object and give it a policy group and policy name and  then it would switch to policy file mode.  So even if you're running something with classic Chef right now, all you have to do is define  these two things here and you are now in policy file mode magically like that.  It's already baked into everything and it just works that way.  There's nothing really else to turn on.  All right.  So then pipeline for us.  If you go to my blog, hedge-ops.com, that's hdge-ops.com, you'll see a lot of blog posts  that I wrote in the last week largely because I didn't feel like I could explain this very  succinctly.  And so I've written a lot of blog posts of how do we use policy files and how do we promote  them through an environment with Jenkins and Artifactory, et cetera.  But the basic here is we package the policies because everything for us is an air-gapped  environment.  We package the policies and we publish them to Artifactory and then we push them to an  air-gapped Artifactory and consume them there by using those Chef push archive commands.  If you want to read more, check out my blog on that.  So then here's running Chef.  Like I said earlier, Chef, when you run it with policy files, it just works.  I would argue it works way better.  And it just says here I'm running policies.  So some potential drawbacks.  Why people would not use policy files?  I've heard before, more in the past than in the present, I won't use policy files because  Chef does not support policy files.  And I will brag on my customer success team and the Chef support team.  They have completely supported policy files for NCR.  It's been fantastic.  There's no problem there.  And so that should not be a concern of yours if you're a Chef customer.  The community is there and the support's there.  And does Chef automate support policy files?  That's a little bit different in question.  Up until now, they have not.  There are no current concrete plans to do that in Chef workflow because the Chef workflow  stuff is a little different than policy files workflow.  But for visibility, it is in active development.  And let me try.  In the few minutes I have left to show you that.  So this is what I saw just yesterday.  These are mockups of what policy files inside of automate would look like.  And this is under active development by Chef Inc. at the moment.  So they're thinking, they're just going to put policy group and policy name in a filter  there.  So you can see your nodes by policy group, policy name.  And then when you get to the node level, you'll see policy group, policy name in the node  data.  And then when you look at your run list, you'll see the cookbook, the full hash version of  the cookbook rather than just the cookbook version.  We talked about that earlier.  So what's cool about this is all we need to do is turn on data source of policy file  information into Chef automate.  These are pretty simple.  I think UI changes are going to be made to Chef automate to support policy files.  And we're very excited about those.  We're going to appreciate it to Chef for being on board with making them.  So yes, it will be supported in Chef automate and in the visibility component.  And finally, what do I do about zero day changes?  So I got like three minutes left.  I'm going to race through this.  But this is a big concern.  So if you're thinking about policy files, you really need to listen up because this  is a potential negative.  If you have policy files, you potentially have a policy file per group of servers all  throughout your infrastructure.  And if you have a zero day incident and need to roll out a cookbook to everything to recover  from the zero day incident, that's going to be more difficult with policy files than  it will be without it.  Because we were talking about how policy files are encapsulated behavior that you promote  through everything.  You can't just push one button and update all the things.  I view that as a feature, not a bug.  We talked about that earlier that with great power comes great responsibility.  And I do not want that responsibility.  So your results may vary.  If you really feel that you're using Chef just because you want to be able to update  things in production immediately, great.  Go for it.  And you may not want to use policy files.  But I believe that the control and the change management that you get from policy files  will give you that speed of delivery and safe delivery.  So the zero day change could be done with policy files if you focus on having a solid  pipeline going through all your stuff.  And that you could use this, but it will help you do that a lot more safer, especially for  the days in which you don't need zero day changes.  So hopefully this got you excited with policy files.  You can find me on Twitter on at Michael Hedgepeth.  Also there's the text of my blog where you can find all of the policy files post and  all the other posts related to how we do deployment.  And also I monitor this channel pretty regularly along with the people at Chef who have developed  policy files, know is there.  This policy files channel and the Chef community is a great place to get help.  So hopefully a lot of you are inspired to implement this awesome feature to make your  lives better.  And I am looking forward to the future and hearing how it goes.  Thanks everybody.  Thank you.  Thank you.
Policyfiles_0_131.png Policyfiles_132_2855.png Policyfiles_2856_6623.png Policyfiles_6624_9599.png Policyfiles_9600_10079.png Policyfiles_10080_19283.png Policyfiles_19284_19979.png Policyfiles_19980_20711.png Policyfiles_20712_21479.png Policyfiles_21480_23891.png Policyfiles_23892_24047.png Policyfiles_24048_25739.png Policyfiles_25740_27779.png Policyfiles_27780_28079.png Policyfiles_28080_29087.png Policyfiles_29088_29975.png Policyfiles_29976_30395.png Policyfiles_30396_33899.png Policyfiles_33900_34631.png Policyfiles_34632_35567.png Policyfiles_35568_36935.png Policyfiles_36936_37703.png Policyfiles_37704_38087.png Policyfiles_38088_38747.png Policyfiles_38748_40199.png Policyfiles_40200_43679.png Policyfiles_43680_45059.png Policyfiles_45060_47171.png Policyfiles_47172_48287.png Policyfiles_48288_49355.png Policyfiles_49356_50399.png Policyfiles_50400_51851.png Policyfiles_51852_51935.png Policyfiles_51936_52247.png Policyfiles_52248_52319.png Policyfiles_52320_52391.png Policyfiles_52392_53099.png Policyfiles_53100_53855.png Policyfiles_53856_54239.png Policyfiles_54240_54455.png Policyfiles_54456_54563.png Policyfiles_54564_54731.png Policyfiles_54732_55607.png Policyfiles_55608_55775.png Policyfiles_55776_57875.png Policyfiles_57876_57983.png Policyfiles_57984_59039.png Policyfiles_59040_59135.png Policyfiles_59136_59231.png Policyfiles_59232_59248.png
So my name is Michael Hedgebeth. There was a dinner or two, but we're not going to talk about that. My name is Michael Hedgebeth and I am a software architect at NCR. And policy files are a really great and important feature for us. And for a while after their development, they kind of went out of style for a little bit. And I've worked a lot in the last, I guess, nine months to a year to try to bring them back into style. Because I believe that they're a simple and awesome way to do Chef development and to make things, make great things happen in Chef simply. So today we're going to talk about a little bit of my journey. We're going to talk about why policy files like some good things in policy files. We're going to go through a walkthrough of the feature itself. And then we're going to talk about what all the people say on why you wouldn't use policy files and some legitimate and not so legitimate reasons people would say you shouldn't use policy files. We're going to do a demo of policy files in Automate, but a demo as in a screenshot of things they're telling me they're working on. Which is, that's a demo when you're in marketing, right? Not that I'm in marketing. And then we'll answer your question. So my hope today is that you will see policy files as a viable and great method and hopefully going forward the method for doing Chef development. It is so simple. It's a great feature. It makes everything wonderful. So I'm going to make that real for you hopefully this afternoon. So a little bit about me and us. NCR is a 100 plus year old company. We invented the cash register. Yeah. Thank you. Thank you. And actually inventing the cash register was a really big technology revolution. If you can think about what happened before the cash register, there was, you know, they called the mom and pop for a reason. There was mom, pop and family because you could not trust, you could, you didn't have an audit trail of what was happening in a store. So stores couldn't scale past a family because you have the cash drawer that's with no audit. And so with the cash register, that changed all that. And that began the retail revolution 130 years ago, or I guess more than that now. I can't do math right now. 130 something years. And so that was really awesome. And throughout the 20th century, that whole platform was a big deal. Like the IBM, people who started IBM came from NCR. And for the first 25 years of the 20th century, like being at NCR as an executive was your pathway to awesome things in high technology at the time. And, but toward the end of the 20th century, we got into retail. We got into ATMs. But we realized that hardware was becoming a commodity. People were interested in software, software was eating the world. And so we began, NCR began investing in software solutions. One of those is a company that got acquired that I was a part of, Radiant Systems. And my division of NCR focuses on restaurant technology. So anywhere from a fast food restaurant to a fine dining restaurant, they all have my software running in it. And one of our key strategic directions was to try to become an omnichannel platform for our customers who would be anywhere from Home Depot to Chase Bank to Wendy's, for example. And help them go into this omnichannel world, which means you're going to want to order a chicken sandwich potentially on your phone. You might want to drive by. You might want to call ahead. You have a lot of different ways that you want to interact with the business. And in NCR, we help people do that. And so they're really interested in making delivery faster. We are interested in making delivery faster. And so Chef was a part of that strategy. So for me, I started out in development. I still have a development title. And so I kind of grew up in a world of just make the disruptive change and the dumb people will get out of the way and we'll make a ton of money. That's sort of the programmer or developer pattern. I would call it an anti-pattern now as I've learned more. And I was really happy in development. In fact, development is pretty awesome because you don't really have to deal with any real world stuff. You could just blame them on other people. But what I did not like is the fact that investments I was making in our products weren't reaching the customer. And the value that the company was investing in me was not being realized because I did the features, but maybe they weren't the right features because we didn't have a good feedback loop or maybe the features were delayed because we didn't have an efficient and effective way for deploying things. And so almost as a moral thing, I got into DevOps and release automation stuff because I wanted to unblock that value flow going to our customers. And I realized that delivery is really the key to value. But if me as a developer, my feature is not delivered, it's worthless. In fact, it's worse than worthless because they paid me to make something that wasn't delivered. And I'm actually looking forward to, let's what I love about DevOps is that it's sort of making delivery a first-class citizen of the problem domain. And hopefully, I can see a future where delivery is more than a first-class citizen. It's more important to organizations for delivery to happen than for the actual development of the code. So we looked into Chef. Reasons we wanted to do Chef were that we wanted more consistency in our deployments. We're looking at it from an app-centric model, not so much infrastructure. I came from a development background. We wanted to be more efficient. We wanted to speed up. But then I was really excited and I talked to my security team. And they weren't as excited at first because they very accurately sensed my immature attitude of thinking, I'm just going to do all this cool stuff and the dummies are going to get out of the way. And I've had to learn how to be empathetic with them and treat them as first-class citizens, treat operations as first-class citizens. And I'm not that person today. But they were not really happy with this whole Chef stuff. And one of the things that they didn't like is that you can make a lot of different changes to a Chef server and those changes could have drastic effects on your infrastructure. If you think about it, if you're going to change an environment pin to a new cookbook version, you may have just changed the code running on your entire production infrastructure. If you're all sharing a prod environment. And that scared them deeply because if a bad actor got in and made a bad actor change, then they are going to very easily own your whole production infrastructure. That's a scary thing. If I think about this like beyond just Chef, I heard in the news that S3 on the East Coast went down like a few weeks ago. Anybody remember that? So that was due to somebody entering into a search string like too permissive of a wild card on the search. And so they involved orders of magnitude more servers than they thought they would, which brought the Internet down. And to a developer or even in a POC type of thing, that seems really cool. Like, awesome. We can do anything we want to with this thing. But then in that real-world situation, and if you're a security person, if you're worried about change management, that awesome feature that your development or operations people may be salivating over is the potential thing that would bring your whole business down. And NCR provides, this is marketing for a second, NCR powers many of the world's transactions from banking to retail to restaurant. If we went down, you would know about it. It would be in the news. And we live on the trust that our customers give us to be that platform for transactions. And so, no, we're not going to just make some change to a Chef server that is potentially not tested. So change management is hugely important. We also have air-gapped environments, which means that you cannot, you know, from your workstation at your desk, SSH into our prod servers. There's a block there. There are firewalls. There's a whole other network there. And so you can't have the one Chef server that rules them all model. And then you have to have a repeatable way to go from a Chef server to a Chef server where you know what you did before and you know what you did after. And in both locations are consistent. And finally, I mean, the quotable moment was, I'm not going to do DevOps because I'm not going to have developers making changes to production. Like, security felt that the security team felt that Chef or even DevOps, the brand itself, was sort of this chaotic thing. Like, we're going to, we're just, you know, we're getting everybody out of the way. And there's a lot of the kind of cultural undertones to that that they see. And I think there's some reality to that. And so I had to change my mentality and realize, empathize with what they were saying. I think that these concerns are completely legitimate. And you know, I was talking to a friend the other day and they were adopting Chef, very new. And they were talking to me about this team that they were struggling with. And you know, I'm sure you've all been there. I've been there too where you say, you know, that person's stupid or they're just dumb or they just don't want to change. And you've all had that moment if you're trying to get people to implement Chef. But the reality is they probably have very real concerns that you just don't, you're not thinking about. And the way to handle things is to go out to lunch with them and go through their concerns and legitimize them in your mind first. And then try to come up with a collaborative solution because if they're not going to see that you are taking them seriously, that they're not going to listen to you. So off topic, I hope I don't go over time. But this is a little off topic, but pro tip. One of the things that changed my relationship with my security person is one weekend, my security person, the PCI expert at my organization, kept not meeting with me. And finally I got, after three weeks of delay, delay, delay, I finally got a meeting with them. What are we going to do about PCI compliance with our Chef implementation? And realized that I was going to have that meeting on a Monday and it was Friday afternoon. And so I went and bought a PCI book, a 400 page PCI book. And I was motivated because I was so frustrated with not making any progress with this element of my implementation. I read the book over the weekend. And in that meeting that I went to with them, he came up with a requirement and I said, are we talking about requirement 12 or requirement nine here? He said 9.3. And then at that moment, that's when our relationship changed. Because he knew that I wasn't just kind of recklessly coming like the drunk uncle at Thanksgiving. You know, you don't know what that person is going to do, but it's going to be fun. And he didn't want that person at his business Thanksgiving. So we had kind of an impasse of security, not wanting this chaotic DevOps thing happening, but me wanting to drive change with me, starting to understand where they were coming from. This is a real problem that people that they're showing me. And we do not want our whole business to go down even at the service of automation. And so we remember the day Chef blog put out a policy file post I had never heard about the feature until then. And I read through it and I thought, my God, this is exactly what we are needing and looking for. And I immediately wrote out a whole spec on what policy files would look like for us. And they immediately said, yeah, that's exactly what we're talking about. We need proper change management. We need a controlled environment. So overview of policy files real quick. The traditional model with, if you don't have Chef or anything, is you're going to go do your code of application or stuff. You're going to go through QA. You're going to go through UAT. You're going to go to prod. But right before prod, you're going to have all this stuff shoved in at the end. So the consultants will say, let's shift left. And that's really what they mean. They want you to put all of these things all the way at the beginning of QA or whatever. So this is what we're trying to get rid of. We're trying to create a consistent implementation through all the environments. So then if we think about Chef, when I talked to my security team, Chef to them looked like this. And if you're an expert at Chef, like Noah, Noah, do you totally understand all this, right? Yeah, thumbs up. Noah gets it, right? This is not the problem, though. The problem is, when a security person is looking at all of this, they are thinking chaos. So what I'm illustrating here is that in the traditional Chef model, you have a lot of different elements in Chef that could be change events to your servers. And that should scare you because it's harder to control. The more change events that happen, the more difficult to control. So you could be changing your role, and that could change everything in production. Did you test that role in earlier environments? Maybe not. You could change your environment. You could change a cookbook. You could accidentally not increment a cookbook version, but then change a cookbook. And that's really difficult to figure out. So this traditional Chef model, I am going to argue, is much more difficult to manage from a change management perspective. And the policy files model says, let's take all of what was there before, all of these roles, all these environments, all these cookbooks, and let's put them into a policy. And all of the concerns that we are looking at go into that policy as well. And those policies and the code that go alongside them can go through the environments where you can trust that I'm running this Chef code with this version of software or whatever, or these versions of software, and I'm promoting them through the environment. By the way, if you're looking at Docker, which is the cool stuff these days, that's this Docker file right there, right? You've got something that you promote through your environments. If you look at Habitat, which is the even cooler stuff these days, it's the same thing. You have a Habitat package that goes through your environments. So what policy files do is they take the model that we've proven with Docker, the model that we've proven with Habitat, and it also applies that same model to a Chef workflow, which makes everything better. You get all of the benefits that those smart people and those other tools have realized, by making their tooling that way, that's what you get with policy files as well. So the other benefit with policy files that I've seen, and I've heard this from my friends in the community, so it's not just me. I believe that with policy files, you will onboard people with Chef in 20% of the time that you have been onboarding them. If people say Chef is difficult to learn, you need to ask yourself the question, are Cookbooks difficult to write? In my experience at NCR, Cookbooks are not difficult to write. You set people up with a skeleton Cookbook, you tell them, here's the resources, and you show them a process. Great, they can code a Cookbook. The problem comes about when you're talking about a role, an environment, pinning, Birkshelf, all these other things that go around with Cookbook development are difficult to teach and learn. People don't want to. So what we do at NCR is we leave all that out of it. We say, okay, you're dealing with data bags and you're dealing with policy files. The policy files, I don't even have to tell them this is a policy file. I'll just show them the four lines that we'll see in just a few minutes of what the policy file is, and they deal with data bags. Then with these other things, they don't even have to worry about them. That's a feature and not a bug because it simplifies everything for them. So those are some of the benefits of policy files. Let me take a second for questions. Anybody have questions so far about? Yeah? Make a sense? Okay, cool. So let's go through policy files. Now, let me be fully full disclosure here. You can find all of this. What I'm going to tell you is basically ripped off of my blog post on policy files. So hedge-ops.com forward slash policy files. You can read all this in that. And then if you go onto the hashtag policy files channel on the Chef community Slack, that blog post is pinned as well. So I'm just sort of talking to you about what you can read. But it's part of the talk. So there we go. So policy file, this is the basic feature. This is almost like anybody ever do a DevOps demo where you push the button and you tell people the whole point of this is it should be boring because it just does all the things. And you don't want to show them the command line because that's not really a big deal. So demoing policy files is similar because policy files are very simple. So I'm going to try to make it as interesting as I possibly can even though it's incredibly simple. So a policy file starts with a policy file dot rb. It is generated by a notepad or notepad, Windows, right? Adam, is that what the cool kids are using? It's generated with that or it's generated with Chef command. So you can generate the policy file. But an example is probably more instructive is this. So we've got four lines here. First off, you've got the policy name. So the policy name is like maybe a role name for a server. So for us, we would have insight-webserver, so a product name and then a role. So policy name is like a role. You can think of a set of servers to get a policy name that you are categorizing. The other thing is where are you getting your cookbooks from? So that's similar to what you may notice with Birkshelf. I'm getting it from the supermarket. We use a private supermarket, which I highly recommend. It's awesome. But you can use the Chef supermarket. You can even use two supermarkets so you can fall back on the public supermarket but use a private supermarket for your own stuff. Then it asks for a run list. Hopefully you know what that is. And then it asks for any exceptions that you have to what you just told them. So hey, I'd like to get all my cookbooks from the supermarket, but there's this one that I need to have a particular pull request or a forked branch or something like that or my internal cookbook or whatever. I'm not using a supermarket. So that's a policy file. So another aside, it was always funny like when we're learning Chef, you get on these calls where something goes wrong and then people start blaming Chef. Well, maybe it's Chef. Chef is this mythical God of war. It's not, I mean, Chef isn't magical. It ends up being code somewhere. And it usually isn't Chef because Chef is way more tested than any other thing that, or the way we're doing it. It's way more tested than anything that they're dealing with otherwise. And so like when you hear policy files, you know, oh, policy files. Well, it's those four lines. It's really simple. Okay. It's just a file that says what is a category of servers that I'm dealing with? That's the policy name. Where do I get my cookbooks from? And what am I going to run on that machine? Okay. This is sometimes checked in on your cookbook. And well, I guess I'll get to that later, but it's sometimes checked in your cookbook. It's checked in the source somewhere. All right. So that's a policy file. You might think, what am I going to do with attributes? So maybe you stopped listening to me a few minutes ago because I didn't like queue you up with this and think, oh, you're going to get rid of environments and you're going to get rid of roles. You know, that really scares me because I use those for some attributes. So there are different ways that you can handle this. So you're going to have to do some change of using attributes and environments or roles. One way is that you can declare attributes inside the policy file as well. So some of our policy files, in fact, many of our policy files are not four lines long because they include attribute information. And if you can see here, there is the attributes here are defined in hash, but it's grouped by kind of what you could think of as an environment. So I have attributes grouped by QA, UAT, and production. And those groups are called policy groups. We can think of a policy group as an environment. It's kind of the same thing. So I declared the attributes right there. And I can consume those attributes in a recipe. Noah told me that the Chef Config policy group can be node policy group, sorry, no, for not updating that slide. But you can also use Noah's poise. You say poise, right? Yeah, poise hoist. I practiced a lot to try to say that the right way because I was nervous. So what poise hoist does is it takes your policy group and it promotes attributes that were based on that group like in this previous slide here. Like the default QA, you have MyApp database. If you're running poise hoist, it will hoist those attributes up to the node level. So I would see MyApp database and it would do that based on the policy group that's there. So very many things to Noah for creating that. Noah has been, I guess we've been hand in hand on let's get policy files working. We're both on the crusade together. So attributes are pretty easy. And I think if you're talking about migration, that's probably one of the biggest pain points is if you have nodes, if you have attributes declaring your roles or your environments, you can declare them there or you can declare them in a role cookbook. That's probably a good pattern for you. And then this would take care of the environment stuff. So that's how you handle attributes. And now it's time to generate a lock file. So a lock file is basically all of the dependencies that you need to run Chef in a JSON file. So you run that with this command right here, Chef install, and then the policy file. And what that does is it takes your, it's kind of like if you use Birx, it's a Birx install. So it takes all of what you declared and it says, okay, I'm going to, you're told me to get this cookbook from the supermarket. I'm going to go to the supermarket, look for the latest version or whatever it is and get that cookbook locally and then save what cookbook I'm using to this lock file. So here we have the very top of a lock file. The very coolest part of this is the revision ID, which looks like a confusing set of characters and it is, but the awesome part about this is that you can know exactly based on this JSON file, if you check it into Git, you can know exactly what you're running in production. So the very first thing that you'll see whenever you're running Chef Client is we're running the policy named this, again, script this with revision ID, that one. And so you can go and know exactly what you're running. This is the policy that I'm running. And by the way, this happens way before your code runs. This is totally separate. You are doing all of your calculations for dependencies and everything that needs to run with Chef in your development environment, inside of your build part of the process, not in your run part of the process. And then there is also cookbook data in there. So this made the security people get really excited because there's a little bit of a problem with secure change management with cookbooks in traditional Chef. And that is I can have version 1.0.0 of a cookbook and I can be a bad actor and put in a virus in that cookbook code and I can force push that cookbook version 1.0.0 to my Chef server and if that's connected to a role that is global or something, all of a sudden my whole infrastructure got owned because even though it says 1.0.0, it's not really 1.0.0.0. There's no guarantee there. And that's scary. Even if you did all the good things around roles, even if you did all the good things around environments with change management, you did everything right down the row with what people are telling you, you still have that problem. You can deal with it with access control, but maybe. So here you have this, my favorite feature of policy files to be honest. This dotted decimal, no, yeah, yeah. Is it, no, it's the identifier. Is Dan here? It's the identifier. It's the identifier. Thanks. You get this identifier. My favorite feature, I don't even know where it is. The identifier is a checksum of the cookbook's contents. And Chef will not run if that checksum is different. So you get all the way to production and it says, okay, I want this, I want to download this cookbook. Awesome. Wait a minute. Somebody has tampered with this cookbook. We're not running Chef right now. And so you have full change control. This is, I tell my Windows friends, of which I am in the Windows community, I tell them this is almost like taking Chef and compiling it into an executable. Like there is, you are doing static binding to other DLLs in Windows world terms, but you're doing a static binding to your cookbooks so that you cannot unbreak those bindings. You could try to do some things, but Chef Client will not run for that. And so this makes it extremely controllable. Everything is declared in one place and everything is safe and simple to use and run. So after you get the lock file, you are now ready to push it to your Chef server. So how do I push a policy? I just do Chef push policy group and then my policy file. Behind there is the lock file that you already created. So that policy group, again, is a set of servers. This is kind of an environment concept where you have a QA environment, a production environment. Or you can split things into policy groups in however many ways you want. You could have prod A and prod B policy group. And we've done some of that. If you want to test out a Chef change even within production. Those are just completely arbitrary, by the way. By putting push QA, you're actually creating that policy group on Chef server. So it's not really any management around that. It's just you're giving an arbitrary name. And if you're using an air gap environment, this is the coolest feature ever other than the identifier one. You can say I want to export my entire policy into a file. And you can do whatever it is you do to get that thing to production. If it's walking through, walking past the machine gun people, it's that. Or you have the, I guess the, what was it, the USB inside of the Rubik's cube or whatever. That's an Everstone reference. If you, whatever you need to do to get your stuff to production, you can have a file that does it all. And the cool thing here too is that feature itself kind of tells you the coolness of policy files and that policy files are an encapsulated set of dependencies on the Chef server. Like you, another policy file because you have that awesome identifier thing is never going to mess with your policy file. You are getting a guarantee of here is the Chef code that is going to run on the server, period. There's nothing around it. It's a guarantee. It's a contract that this feature gives you, that you are not going to get anywhere else. And so I can put that, put all of those dependencies into a archive. So it's got all the cookbook dependencies and everything. And then I can walk it to production or whatever it is I do and upload it to the Chef server with Chef push archive, sorry, Chef push archive to the policy group and then give it the file name. So if you are struggling with your Chef implementation with regard to air gap environments because it's difficult for you to move Chef objects from one Chef server to the other, it behooves you to use this feature. And I was going to bet that I would use the word behoove in this talk because it's an awesome kind of old English word. But it behooves you to use this feature because it makes everything so much simpler and controllable. And actually, it follows the spirit of an air gap environment way better than you're rolling a lot of different changes to the Chef server and hoping that you have a consistency with other environments that you're dealing with. Okay. So now, how would I bootstrap something? You can do that with Knife Bootstrap. You would use the policy group and policy name and you would get a node that bootstrap with policy files. So, and I know it is kind of weird that we're talking about policy files as sort of an out of vogue feature in the past, but it's fully baked into Chef right now and I've been running it into production for over a year. So this is an old feature that's been tested and we're not announcing anything today, right? This is just how it is. So, you can bootstrap with the policy group and policy name. You can also, maybe, yeah, you can also include policy group and policy name in your attributes. So this is how you're defining, here's my node, what's the name of the policy? Like it's my insight web server, what's the policy group? This is a QA policy group. So you do that in attributes.json that you'd pass in as Chef Client as your bootstrapping or you can even change the node object and give it a policy group and policy name and then it would switch to policy file mode. So even if you're running something with classic Chef right now, all you have to do is define these two things here and you are now in policy file mode magically like that. It's already baked into everything and it just works that way. There's nothing really else to turn on. All right. So then pipeline for us. If you go to my blog, hedge-ops.com, that's hdge-ops.com, you'll see a lot of blog posts that I wrote in the last week largely because I didn't feel like I could explain this very succinctly. And so I've written a lot of blog posts of how do we use policy files and how do we promote them through an environment with Jenkins and Artifactory, et cetera. But the basic here is we package the policies because everything for us is an air-gapped environment. We package the policies and we publish them to Artifactory and then we push them to an air-gapped Artifactory and consume them there by using those Chef push archive commands. If you want to read more, check out my blog on that. So then here's running Chef. Like I said earlier, Chef, when you run it with policy files, it just works. I would argue it works way better. And it just says here I'm running policies. So some potential drawbacks. Why people would not use policy files? I've heard before, more in the past than in the present, I won't use policy files because Chef does not support policy files. And I will brag on my customer success team and the Chef support team. They have completely supported policy files for NCR. It's been fantastic. There's no problem there. And so that should not be a concern of yours if you're a Chef customer. The community is there and the support's there. And does Chef automate support policy files? That's a little bit different in question. Up until now, they have not. There are no current concrete plans to do that in Chef workflow because the Chef workflow stuff is a little different than policy files workflow. But for visibility, it is in active development. And let me try. In the few minutes I have left to show you that. So this is what I saw just yesterday. These are mockups of what policy files inside of automate would look like. And this is under active development by Chef Inc. at the moment. So they're thinking, they're just going to put policy group and policy name in a filter there. So you can see your nodes by policy group, policy name. And then when you get to the node level, you'll see policy group, policy name in the node data. And then when you look at your run list, you'll see the cookbook, the full hash version of the cookbook rather than just the cookbook version. We talked about that earlier. So what's cool about this is all we need to do is turn on data source of policy file information into Chef automate. These are pretty simple. I think UI changes are going to be made to Chef automate to support policy files. And we're very excited about those. We're going to appreciate it to Chef for being on board with making them. So yes, it will be supported in Chef automate and in the visibility component. And finally, what do I do about zero day changes? So I got like three minutes left. I'm going to race through this. But this is a big concern. So if you're thinking about policy files, you really need to listen up because this is a potential negative. If you have policy files, you potentially have a policy file per group of servers all throughout your infrastructure. And if you have a zero day incident and need to roll out a cookbook to everything to recover from the zero day incident, that's going to be more difficult with policy files than it will be without it. Because we were talking about how policy files are encapsulated behavior that you promote through everything. You can't just push one button and update all the things. I view that as a feature, not a bug. We talked about that earlier that with great power comes great responsibility. And I do not want that responsibility. So your results may vary. If you really feel that you're using Chef just because you want to be able to update things in production immediately, great. Go for it. And you may not want to use policy files. But I believe that the control and the change management that you get from policy files will give you that speed of delivery and safe delivery. So the zero day change could be done with policy files if you focus on having a solid pipeline going through all your stuff. And that you could use this, but it will help you do that a lot more safer, especially for the days in which you don't need zero day changes. So hopefully this got you excited with policy files. You can find me on Twitter on at Michael Hedgepeth. Also there's the text of my blog where you can find all of the policy files post and all the other posts related to how we do deployment. And also I monitor this channel pretty regularly along with the people at Chef who have developed policy files, know is there. This policy files channel and the Chef community is a great place to get help. So hopefully a lot of you are inspired to implement this awesome feature to make your lives better. And I am looking forward to the future and hearing how it goes. Thanks everybody. Thank you. Thank you.
use policy files and some legitimate and not so about change management, that awesome feature be that platform for transactions. And so, no, get people to implement Chef. But the reality is We need a controlled environment. So overview of much more difficult to manage from a change people with Chef in 20% of the time that you have policy into a file. And you can do whatever it is policy files and how do we promote them through push them to an air-gapped Artifactory and