From Solo to Happy: Migrating Chef Solo to Chef Server/Automate
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Rambow, Mark
Zryanina, Nadezda
Chef solo is a great choice for simple and light infrastructure automation. We all used it back in the day. But with Chef Automate becoming more compelling every day (resource discovery, shared data bags, cookbook distribution, automated workflow, ...), many of us want to migrate to a Chef server. Instead of only promoting the "why," this talk will also focus on the "how" and walk you through the migration of a Chef solo setup to a Chef Automate installation managed by Amazon Web Services and OpsWorks.
 Hello everyone, it's great to be here at Chef Fund and today with me is Nadir, she's an engineer at AWS Office for Chef Ornament and I'm an engineering manager and safety and today we want to put some light on Chef Solo, some use cases on that and what Chef Ornament could give you in that setting, maybe even if you want to, we can tell you how to migrate over. And yeah, so let me get started with everyone, so what do you expect from the talk? So there are people that using Chef Solo not only for testing but in large environments, so they're running that for all the infrastructure, if I may ask someone of you is using Chef Solo for all the infrastructure, oh yeah, you see, there are a couple of people doing that and I would like to compare how to use Chef Solo in a production environment and what you could benefit from using Chef Ornament and also how to use both things in combination because you can do that pretty easily and Nadir will guide you through a full migration of that. How do you use Chef? So for most people the answer is they use a Chef server with or without automation and AWS Office for Chef Ornament is giving you a full managed Chef server with automated line, so you just go to our console, you get that in sweet clicks and you have that up and running in AWS, which is pretty nice. And what does the Chef server doing that in that environment? So the Chef server stores all the state of your entire infrastructure, all the nodes coming in, they send you OHA data that you know and you can then discover from every node information about all the other nodes. The data is available for all the connected nodes and automate, give you on top deep insights and statistics about your whole infrastructure, which is nice because you want to know about all the Chef runs doing and maybe some history about them where the nodes are failing, all those things. And the alternative would be using Chef Solo and Office has a long history doing that actually with a lot of customers. AWS Office stacks is that product that is using Chef Solo under the hood and the cool thing about Chef Solo is you run them in isolation. You can have the nodes completely isolated from each other, they don't know anything about each other. You use Chef Zero server on that, that's an in memory Chef server, so you have all the features set up in the normal Chef server just on that one box, but you have no clue about your surrounding. And that's why it's called Solo because it's pretty lonely there because you don't know anything about your neighbors. Why Chef Solo? So usually people using Chef Solo in the development cycle. So something like test kits, and a paper and that's the normal way to do that. You want to check out if your new code book is working, if the recipes are working, you say converge, you want to have kind of a unit test environment where you have no state before you actually figure out if your code book is working. Also, Solo gives you the easiest way to use the Chef keys to configure the nodes. If you just want to have some kind of abstraction to install packages, configure services, making them up and running, the easiest way would be to grab a recipe and run the Chef Solo on a node and everything is set up for you. The good thing about having no dependency between nodes is it's easy to state because there's no single instance that needs to keep up with that scale of your infrastructure and that's why some master clients actually use it. So for example, there's also a stack, we have customers from small start-ups up to big enterprises that use it for large fees and one of the customers that is using that outside of those stacks is Airbnb, they have a nice write-up blog post about that and that they're pretty happy with that. But I think if you're growing that broad and you either want to do it yourself or even if you're using one of those solutions that are out there, you might miss out some good things that we talk about. So how do you put your nodes? That's not really easy to answer with Chef Solo. How do you share your recipes, your roles, your environments, your secrets? Let's do it yourself. How do you do your development workflow? How does that look like? How do you trigger a Chef fund that you might want to have at home? The most important one for me is how do you get feedback from all the nodes that you're running with Chef Solo? For me, this is the most critical part. If you run it only on a single instance and you have no back channel, you will not know if everything was configured correctly. So for that you need to build something. This is a rough slide about the comparison. If you're running Chef Solo, the wood strapping is usually done with user data. So you just install the Chef client and trigger the Chef client after it's booted up. You can do it either that or you do it manually via a SSA to an instance, installing all the Chef software and then you can run the Chef client. With Chef Automate or Chef Server, you have a tool that is called Knife and most of you use that for anything you're using with the Chef Server. And there's Knife Bootstrap, a nice C2 bootstrap that gives you a new machine. That's the key exchange for you and applies the run-less that you want to run. How do you share recipes between all the nodes that you're running? Maybe you're running 500 nodes with Chef Solo. They all need to somehow get the same recipes to be configured. Of course we're all developers so we use inversion control or using S3 to package everything up into an artifact and then you can wrap that from every single node and apply this. If you're using a Chef Server, you have to keep building. So you deliver your purpose to the Chef Server and all the nodes connected to the server getting their purpose from there. How do you know the state of the infrastructure? That's tricky, right? I said that everything is in isolation here and because that is, you need to care about information that you want to share. So either you put information that you know about your infrastructure into your corporate repository and your cookbooks so that you can share that because maybe you want to have certain environment variables set, you want to say for this environment I want to have this amount of node connections possible to my SQL Server, things like that. You need to share that. You can have somewhere a storage of JSON data that you can grab and transfer into Database or anything else but you take care of that yourself. And that's much, much better solved in a Chef Server where you can use Chef Search to query all information across the whole environment that you have. Chef Search gives you the ability to query everything in nodes that is connected to the server and you have all the information that you need from the OI data. And on top of that you can have Database where you have this context knowledge that is only for you and your application important. You can put that into the Chef Server and it's a set way for all the nodes to have each Chef run. And why that is important, and I will talk about it a little bit later. What about previewing Chef runs? So in Office we had an answer for that in that life-size event. What we do is that we react on changes that are happening to your infrastructure. So new nodes are booted up in that cluster. We recognize that and we trigger a Chef run across all the nodes because we have an active instance and agent on each of the instances so that we can actually trigger a Chef run. So we have multiple lifecycle events if you want to look that up, that might be interesting if you're interested in that. The other way would be just running a cron that you would also use when you're using a Chef Server. You have something that is applying to cookbooks every 15 minutes, every 30 minutes, before the future Chef plan for both. So you continuously apply the configuration so that also gives you the confidence that your instances are always configured the way that you describe them in your cookbooks. And no one can just access to the box, change some configuration, they are kind of out of sync. So applying them over and over again gives you the confidence that everything is compliant to what you expect them to have. With Chef Automate you also or Chef Server you also have the ability to use the 9SSH to trigger a Chef run while you're using the push-off plugin that is pretty popular. What about the development workflow? That's different. So that's very different. If you want to use Chef Server you need to somehow figure out how you want to work with your Git repository to make sure that your cookbooks are developed, tested, pushed to maybe a run like everything is doing there. And then on all of your Chef Server nodes you're checking out the branch that is maybe your development environment or your production environment and you kind of separate what kind of cookbooks are running by branching. That is one way to do that. That's all something that you need to figure out with your team what works for you. There's not enough guidance on how to use Chef Solo in a large scale like that. If you go with Chef Automate there's a new tool that's called workflow. I guess there were a couple of sessions around Chef Workflow here and in the Chef Fund. So at least those are all sessions so we don't go too deep into that. But that describes the full CD pipeline from doing a recipe or cookbook, checking it in one of your other developers, giving you a ship that's bubbling through the pipeline, a lot of tests. And it's going through several steps until it will be pushed to production. So this is a very nice late-order workflow that you can do and that's fully supported with Automate. And for me as I said the most important part is the run result reporting. So it does help you if you run across 400 nodes a Chef recipe and you have no feedback channel that tells you if it actually converged or not. So you're built in a black box scenario and you just hope that everything works. Of course you wouldn't do this, right? You would build something that helps you with that. For example you can use something like SatsD or AWS CloudWatch metrics where you can push events to say hey Chef run failed on that node and you can make it work. Of course it has tools and answers for that that gives you the exact run result that you can introspect and it tells you if it converged or not. The Chef Automate that's going on a completely different level. So the Chef Automate you have historical data about every Chef run that was running and you know exactly which failed, which resources there are, what kind of attributes are in there. You can really go deep into every single node and figuring out why it might not work or why it was. And just to recap, so with OfficeStacks we give you all the tooling that I just spoke about that you would build yourself if you want to run Chef Solo in a large scale. That is reporting through the Office UI that tells you if the nodes haven't run in fine or if it is unhealthy. We have to run results in a stream that is linked from each of the nodes that you can go into and you have clock watch logs for further introspection. We have this event based life cycle system that triggers Chef Run with a specific run that is set up on the SMD node coming to your cluster that is called Configure or on Tiered Out where you might want to ship the last log from that node somewhere before you actually tier it down. And you can also do an unhooked Chef Run with OfficeWorks and even Implication Departments that are done with the Chef recipe. And I think OfficeStacks also with a very simplistic thing in mind, we wanted to enable people to use the ChefDs to configure their cluster in AWS and to manage that through one console. So you wanted to have stacks and layers to set up your application. You will organize it by stacks and layers and you start in such a stock instances you have auto scaling auto healing in place. So this is giving you a lot of benefits just using Chef Solo in OfficeWorks and it's free. The downside is there is no equivalent tonight. So if you go through any tutorial of Chef at some point there is some nightmare that will probably not work with Chef Solo in this case. Also the Chef Search is limited. We inject a lot what we know about the stacks that you are running in AWS. So we give you also information about the RDS database that you have in place and maybe your EBS volumes and so on. So we have a little bit more context on what AWS but you don't have all the OI data that you usually would expect. And it's not fully compatible with the community. So if you use OfficeWorks and stacks for Solo in general things like the MongoDB cluster will not work. So because it expects to be running within the Chef server so that all nodes can be set up. Okay how to choose. So if you are just configuring your infrastructure with the ChefDs, OfficeWorks and stacks will give you a lot of benefits and you can go very far with it. You don't have to think about the server piece, the scaling, all those things that's all covered for you. And it's free. So if you just get started right now with Chefs that might be a good way to just explore that space. If you want to have the latest and greatest Chef experience you want to do all the new tools that Chefs come in up with all the time. If you want to have deep integration to a large cluster, if you want to know in depth what's going on in your infrastructure, Chef Automate gives you completely the best experience. And to get that one, you just waste three clicks in the OfficeConsole and you get an OfficeWorks for Chef Automate server. And now we'll hand over to Nadia and that is a bit more technical and starting with our automatic question. Thank you very much for the clear comparison between ChefSolo and Chef Automate. Now before we start getting our hands on the migration from Solo to very big community of Automate and where all the nodes are together, I have two good news to you. Very good news. If you haven't had good news today, you're getting these good news for free. First of all, unlike other migrations, these ones should not be scary. It's nothing went back and wide that you prepared for several weeks. You read some parts from scratch because you haven't had it in the previous system. You prepare, you test, you double check, you find some other bugs, you find some other systems that you didn't have. And then one day you're like, okay, let's do it on production. There is nothing like this. There are basically four steps how you can migrate and yeah, even if you are not sure whether you want to migrate, whether you're okay, you saw some really nice pictures of Chef Automate, you saw a lot of talks, how great it is, but you're still very comfortable with my Chef Solo setup. You can just make your Chef Solo report to Automate and then see what kind of insights you can get and then decide whether you actually want to migrate, whether you see some impact for you, for your systems and benefits. So getting a little bit overview over the whole migration that I will be talking today. As I mentioned, it's about four steps. First of all, you need to move your cookbooks to the Chef Server because previously had it somewhere in GitHub, maybe there was a category. They need to be in the Chef Service and not scan and have access to them. Then you bring in nodes so they can talk to Chef Server, Chef Server knows about them. Then you set up environments and roles. This is a pretty easy step where it's going to keep the connection. Then you bring in workflows that will complete the whole migration and have all your experience completed when you work with Chef Automate. Because workflows are actually moving your cookbooks, changes to the Chef Server so it's available to nodes. This is the final result that we would expect after the migration if you have a full migration. You have your nodes checking in with Chef Server. You have your workstation where developers are working and changing cookbooks. With the delivery track, it gets through the workflow, deliver it to the Chef Server and later pull to nodes. So yeah, if you just want to take a look in, how it will look if you will migrate. You can just add Chef Automate on your current solo infrastructure and report your Chef Solo runs to Chef Automate Server. I will come back to it in a second because before we start talking about it, we need to get Chef Automate Server. The easiest one would be author to Chef Automate. You don't need to set up your goals or three steps, multiple answers, questions and you wait for 10 minutes until it's up and running. You have it working with some extra curves on top, like backups, continuous tells monitoring maintenance where we make sure that your Chef Automate Server running the latest security updates and also we upgrade the version of Chef Automate for you. Besides that, you just click the button, you put in great region, whatever you need to have and then you have your service here. As well, since it's on the AWS, you can benefit a lot from all the AWS infrastructure and services that we have. Okay, so if only deep insights, what you should do. Get Chef Automate Server and then you can get Delivery Talking from the ETC Delivery Delivery RB file. It will be on your Chef Automate Server, you can SSH there and get the talking and then you configure your data collector to report your Chef runs to the Chef Automate. That's pretty much it. The next run, your note will be in Automate. As you can see on this screen, you have a check-in time when it was the last check-in. You have the uptime, some basic data, general data platform environment where it's running and once you have several more solar runs, you will, in the detailed note view, you will see more ahead data. You will also see when the Chef runs were performed. You will see how they performed. You can see what went wrong. If something went wrong, if something is fine, then you can see that it was fine. Okay, so imagine you take a look at this. This is something that you need. This is something that you need for your cluster and you decide to migrate. So you need to, once again, bring your book books to Chef Server and reconfigure your Chef clients to use the Chef Server. Then you have clear benefits from Chef Automate and work clothes, environments, roles, all the historical data, very clear overview on all your system. Okay, let's move. This is how I imagine where we are moving from. So you have workstation that runs Chef Solar using it for storing Google's Chef Solar runs in your instances, hopefully with Chrome, and then checks out it from it or some other way you deliver the Google's to the node. When you're launching Chef Server, when you launch a Chef Server with Officeworks Chef Automate, besides credentials, Chef says the UI, you're getting also Start a Kit. Start a Kit is simple archive. I really recommend you download it and pack it and you will see clear folder structure where it's already set up to communicate directly to your Chef Automate. And besides Google's environments, roles, folders where you need to store your Google's environments and roles, you have a very interesting file that is called userdata.sh. This is something that we prepared for you. So you can include it into the boot of your system as your node and not go automatically checking it with Chef Automate. You don't need to do anything, especially when you use Autospm, you just put it in the launch configuration, I'll be there. So, okay, let's start. First, let's move Google's to Chef Server. It seems a bit complicated. Very easy. You move into the folder on the Start a Kit and then you deny the folder. Wait for a little, it's on the Chef Server. You're done. Let's go for the second one. Bringing in nodes. This is a little bit more complicated. You need to know where your nodes are. You need to collect them in one place. Basically, to bootstrap the node and to bring the node into the Chef Automate Server, you need to know the node name and the IP it can be reached. If you have some different SHK tests or different user names that you have access to the node, you also grab the collected in one place and then just click through a file and check it in with a non-boostrap. Yes. So, this is like an example of a file. You have a node name, node IP, user, SSHK location. You just simply non-boostrap. You can also easily already know how you want to organize your cluster in environments and you can also include it in the Connect Bootstrap. Then you will save some time introducing nodes into roles or environments later. Yes, you wait for a little, they run through and they show up in your Chef Automate. It's actually the same view as you had when you were just running for Intel Dimetry from Chef Color Rounds into Chef Automate, but now they're running with the Chef Server. So, you don't need to organize them and making them checking out your Google from somewhere else. It's all on the Chef Server. They have talked into the Chef Server. They have all the infrastructure there. Yeah. High data, historical runs, if something fails, you know what fails, if everything is good, you know that it's good. Yeah. Now comes benefit. Basically, that's where you can start. If you don't want to spend more time, you're already pretty good setup. The most benefit you have here at Chef Search, your node, when it comes up and runs for a run to cookbooks, it already knows everything about your cluster. What's going on there? You can include it into your recipes. Hopefully you tested before you put it in the recipes with the Chef. Yeah, you can run it there. It's told directly to Chef Automate and Chef Server. You run it there, you see what data you have in your system. You make the search correct. You put it in the recipe. So now your web applications can know which databases are up and running, for example, right now, and configure themselves to talk to those databases. Or you can also use it in your scripts using Night Search. Another good thing is Databx. You can create them in the Chef Show. You can share it. So, the Databx is to share the data, the global data between all your nodes, right? And you can iterate over them in your recipes as well. So, that's pretty much it. If you want to go forward and bring workflows that I will actually hardly recommend because it's a very unified way to bring your cookbook changes to your nodes. Yeah, I skipped, as I mentioned, environments and roles because it's very simple setup. Just look up your documentation and straightforward. You know how you want to organize it. And you will set it up in a couple of minutes. And with the next checks all around, it will be in the Chef Automate also visible. So, now we need to set up, if you're setting up workflows, you're setting up the delivery truck that delivers, pushes your cookbook changes through the pipeline. And it looks like this. It's almost full CD pipeline. There are two steps that you need to do manually or manually approve and manually deliver. Because, which makes actually sense, like you were working through the whole week on your changes to your cookbook. It was approved by your colleagues. It builds, it runs tests, it runs smooth tests. And then it's ready to be delivered. But it's ready to be delivered. You would rather go and dream of your, right? You don't want to eat, you're going to production and having some of your weekend plans made this very hopefully not. And most likely not, but still. You would feel rather better if it will go out on Monday. So you have your next weekend to come back on Monday to work. First button, it's up to production. After several more stages. Just to make sure that nothing broke during the weekend. Right? So, just to recap, that's where we started. We have our radio long minutes running Chef Sol knowing nothing but what you actually told them with maybe some shared files or configurations. You had your workstation, you had your cookbooks in Git. Then you moved your cookbooks into the Chef server once you got the Chef host. Then you moved your notes into the Chef server. And then you set up the delivery truck and work flows to deliver the changes you had to cookbooks, the Chef server, and then it would later be picked up by your notes. So yeah, that's pretty much it. And the second good news that I didn't tell you before, and you didn't tell me that I only told you on the one good news, is that there is nothing heavy to be or coding. It's pretty straightforward. It's not that there were no walls or clothes, right? There was nothing that you would do like, wait a second. Wait a second. It's pretty straightforward. You know your notes, you know your environment, you know how it should be. You simply move it. And yeah, as I mentioned, you can already stop after the first two steps and wait for the work flows later because maybe you have some other process that was already done for several years. It's very unified. Everyone knows about that. So you might need to wait a little just for a second. And yeah. That's pretty much it. Yeah. Okay. So we are around in our booth, in our AWS booth. So if anyone wants to talk to us directly about their use cases and how that would apply to them, we have a chance for the rest of the day. And yeah, we are on. Thanks a lot. See you.
 Hello everyone, it's great to be here at Chef Fund and today with me is Nadir, she's  an engineer at AWS Office for Chef Ornament and I'm an engineering manager and safety  and today we want to put some light on Chef Solo, some use cases on that and what Chef  Ornament could give you in that setting, maybe even if you want to, we can tell you how to  migrate over. And yeah, so let me get started with everyone, so what do you expect from  the talk? So there are people that using Chef Solo not only for testing but in large  environments, so they're running that for all the infrastructure, if I may ask someone  of you is using Chef Solo for all the infrastructure, oh yeah, you see, there are a couple of people  doing that and I would like to compare how to use Chef Solo in a production environment  and what you could benefit from using Chef Ornament and also how to use both things in  combination because you can do that pretty easily and Nadir will guide you through a  full migration of that. How do you use Chef? So for most people the answer is they use  a Chef server with or without automation and AWS Office for Chef Ornament is giving you  a full managed Chef server with automated line, so you just go to our console, you get  that in sweet clicks and you have that up and running in AWS, which is pretty nice.  And what does the Chef server doing that in that environment? So the Chef server stores  all the state of your entire infrastructure, all the nodes coming in, they send you OHA  data that you know and you can then discover from every node information about all the  other nodes. The data is available for all the connected nodes and automate, give you  on top deep insights and statistics about your whole infrastructure, which is nice  because you want to know about all the Chef runs doing and maybe some history about them  where the nodes are failing, all those things. And the alternative would be using Chef Solo  and Office has a long history doing that actually with a lot of customers. AWS Office  stacks is that product that is using Chef Solo under the hood and the cool thing about  Chef Solo is you run them in isolation. You can have the nodes completely isolated from  each other, they don't know anything about each other. You use Chef Zero server on that,  that's an in memory Chef server, so you have all the features set up in the normal Chef  server just on that one box, but you have no clue about your surrounding. And that's why  it's called Solo because it's pretty lonely there because you don't know anything about  your neighbors. Why Chef Solo? So usually people using Chef Solo in the development cycle.  So something like test kits, and a paper and that's the normal way to do that. You want  to check out if your new code book is working, if the recipes are working, you say  converge, you want to have kind of a unit test environment where you have no state before  you actually figure out if your code book is working. Also, Solo gives you the easiest  way to use the Chef keys to configure the nodes. If you just want to have some kind of  abstraction to install packages, configure services, making them up and running, the easiest  way would be to grab a recipe and run the Chef Solo on a node and everything is set up for you.  The good thing about having no dependency between nodes is it's easy to state because there's  no single instance that needs to keep up with that scale of your infrastructure and that's  why some master clients actually use it. So for example, there's also a stack, we have  customers from small start-ups up to big enterprises that use it for large fees and one of the  customers that is using that outside of those stacks is Airbnb, they have a nice  write-up blog post about that and that they're pretty happy with that. But I think if you're  growing that broad and you either want to do it yourself or even if you're using one of  those solutions that are out there, you might miss out some good things that we talk about.  So how do you put your nodes? That's not really easy to answer with Chef Solo. How do you  share your recipes, your roles, your environments, your secrets? Let's do it yourself. How do  you do your development workflow? How does that look like? How do you trigger a Chef  fund that you might want to have at home? The most important one for me is how do you  get feedback from all the nodes that you're running with Chef Solo? For me, this is the  most critical part. If you run it only on a single instance and you have no back channel,  you will not know if everything was configured correctly. So for that you need to build something.  This is a rough slide about the comparison. If you're running Chef Solo, the wood  strapping is usually done with user data. So you just install the Chef client and trigger  the Chef client after it's booted up. You can do it either that or you do it manually  via a SSA to an instance, installing all the Chef software and then you can run the  Chef client. With Chef Automate or Chef Server, you have a tool that is called Knife and  most of you use that for anything you're using with the Chef Server. And there's Knife  Bootstrap, a nice C2 bootstrap that gives you a new machine. That's the key exchange  for you and applies the run-less that you want to run. How do you share recipes between  all the nodes that you're running? Maybe you're running 500 nodes with Chef Solo. They all  need to somehow get the same recipes to be configured. Of course we're all developers  so we use inversion control or using S3 to package everything up into an artifact and  then you can wrap that from every single node and apply this. If you're using a Chef  Server, you have to keep building. So you deliver your purpose to the Chef Server and all the  nodes connected to the server getting their purpose from there. How do you know the state  of the infrastructure? That's tricky, right? I said that everything is in isolation here  and because that is, you need to care about information that you want to share. So either  you put information that you know about your infrastructure into your corporate repository  and your cookbooks so that you can share that because maybe you want to have certain environment  variables set, you want to say for this environment I want to have this amount of node connections  possible to my SQL Server, things like that. You need to share that. You can have somewhere  a storage of JSON data that you can grab and transfer into Database or anything else but  you take care of that yourself. And that's much, much better solved in a Chef Server where  you can use Chef Search to query all information across the whole environment that you have.  Chef Search gives you the ability to query everything in nodes that is connected to the  server and you have all the information that you need from the OI data. And on top of that  you can have Database where you have this context knowledge that is only for you and your application  important. You can put that into the Chef Server and it's a set way for all the nodes to have  each Chef run. And why that is important, and I will talk about it a little bit later.  What about previewing Chef runs? So in Office we had an answer for that in that life-size  event. What we do is that we react on changes that are happening to your infrastructure.  So new nodes are booted up in that cluster. We recognize that and we trigger a Chef run  across all the nodes because we have an active instance and agent on each of the instances  so that we can actually trigger a Chef run. So we have multiple lifecycle events if you  want to look that up, that might be interesting if you're interested in that. The other way  would be just running a cron that you would also use when you're using a Chef Server.  You have something that is applying to cookbooks every 15 minutes, every 30 minutes, before  the future Chef plan for both. So you continuously apply the configuration so that also gives  you the confidence that your instances are always configured the way that you describe them  in your cookbooks. And no one can just access to the box, change some configuration, they  are kind of out of sync. So applying them over and over again gives you the confidence  that everything is compliant to what you expect them to have. With Chef Automate you also  or Chef Server you also have the ability to use the 9SSH to trigger a Chef run while you're  using the push-off plugin that is pretty popular. What about the development workflow?  That's different. So that's very different. If you want to use Chef Server you need to  somehow figure out how you want to work with your Git repository to make sure that your  cookbooks are developed, tested, pushed to maybe a run like everything is doing there.  And then on all of your Chef Server nodes you're checking out the branch that is maybe  your development environment or your production environment and you kind of separate what  kind of cookbooks are running by branching. That is one way to do that.  That's all something that you need to figure out with your team what works for you. There's  not enough guidance on how to use Chef Solo in a large scale like that. If you go with  Chef Automate there's a new tool that's called workflow. I guess there were a couple of  sessions around Chef Workflow here and in the Chef Fund. So at least those are all sessions  so we don't go too deep into that. But that describes the full CD pipeline from doing  a recipe or cookbook, checking it in one of your other developers, giving you a ship  that's bubbling through the pipeline, a lot of tests. And it's going through several steps  until it will be pushed to production. So this is a very nice late-order workflow that you  can do and that's fully supported with Automate. And for me as I said the most important part  is the run result reporting. So it does help you if you run across 400 nodes a Chef recipe  and you have no feedback channel that tells you if it actually converged or not. So you're  built in a black box scenario and you just hope that everything works. Of course you  wouldn't do this, right? You would build something that helps you with that. For example you  can use something like SatsD or AWS CloudWatch metrics where you can push events to say hey  Chef run failed on that node and you can make it work. Of course it has tools and answers  for that that gives you the exact run result that you can introspect and it tells you if  it converged or not. The Chef Automate that's going on a completely different level. So the  Chef Automate you have historical data about every Chef run that was running and you know  exactly which failed, which resources there are, what kind of attributes are in there.  You can really go deep into every single node and figuring out why it might not work or why  it was. And just to recap, so with OfficeStacks we give you all the tooling that I just spoke  about that you would build yourself if you want to run Chef Solo in a large scale. That  is reporting through the Office UI that tells you if the nodes haven't run in fine or if  it is unhealthy. We have to run results in a stream that is linked from each of the nodes  that you can go into and you have clock watch logs for further introspection. We have this  event based life cycle system that triggers Chef Run with a specific run that is set up  on the SMD node coming to your cluster that is called Configure or on Tiered Out where  you might want to ship the last log from that node somewhere before you actually tier it  down. And you can also do an unhooked Chef Run with OfficeWorks and even Implication  Departments that are done with the Chef recipe. And I think OfficeStacks also with a very  simplistic thing in mind, we wanted to enable people to use the ChefDs to configure their  cluster in AWS and to manage that through one console. So you wanted to have stacks and  layers to set up your application. You will organize it by stacks and layers and you start  in such a stock instances you have auto scaling auto healing in place. So this is giving you  a lot of benefits just using Chef Solo in OfficeWorks and it's free. The downside is there is no  equivalent tonight. So if you go through any tutorial of Chef at some point there is some  nightmare that will probably not work with Chef Solo in this case. Also the Chef Search  is limited. We inject a lot what we know about the stacks that you are running in AWS. So  we give you also information about the RDS database that you have in place and maybe your  EBS volumes and so on. So we have a little bit more context on what AWS but you don't  have all the OI data that you usually would expect. And it's not fully compatible with  the community. So if you use OfficeWorks and stacks for Solo in general things like the  MongoDB cluster will not work. So because it expects to be running within the Chef server  so that all nodes can be set up. Okay how to choose. So if you are just configuring your  infrastructure with the ChefDs, OfficeWorks and stacks will give you a lot of benefits  and you can go very far with it. You don't have to think about the server piece, the  scaling, all those things that's all covered for you. And it's free. So if you just get  started right now with Chefs that might be a good way to just explore that space. If  you want to have the latest and greatest Chef experience you want to do all the new tools  that Chefs come in up with all the time. If you want to have deep integration to a large  cluster, if you want to know in depth what's going on in your infrastructure, Chef Automate  gives you completely the best experience. And to get that one, you just waste three  clicks in the OfficeConsole and you get an OfficeWorks for Chef Automate server. And  now we'll hand over to Nadia and that is a bit more technical and starting with our  automatic question. Thank you very much for the clear comparison between ChefSolo and  Chef Automate. Now before we start getting our hands on the migration from Solo to  very big community of Automate and where all the nodes are together, I have two good  news to you. Very good news. If you haven't had good news today, you're getting these  good news for free. First of all, unlike other migrations, these ones should not be scary.  It's nothing went back and wide that you prepared for several weeks. You read some parts from  scratch because you haven't had it in the previous system. You prepare, you test, you  double check, you find some other bugs, you find some other systems that you didn't  have. And then one day you're like, okay, let's do it on production. There is nothing  like this. There are basically four steps how you can migrate and yeah, even if you  are not sure whether you want to migrate, whether you're okay, you saw some really nice  pictures of Chef Automate, you saw a lot of talks, how great it is, but you're still  very comfortable with my Chef Solo setup. You can just make your Chef Solo report to  Automate and then see what kind of insights you can get and then decide whether you actually  want to migrate, whether you see some impact for you, for your systems and benefits. So  getting a little bit overview over the whole migration that I will be talking today. As  I mentioned, it's about four steps. First of all, you need to move your cookbooks to the  Chef Server because previously had it somewhere in GitHub, maybe there was a category. They  need to be in the Chef Service and not scan and have access to them. Then you bring in  nodes so they can talk to Chef Server, Chef Server knows about them. Then you set up  environments and roles. This is a pretty easy step where it's going to keep the  connection. Then you bring in workflows that will complete the whole migration and have  all your experience completed when you work with Chef Automate. Because workflows are  actually moving your cookbooks, changes to the Chef Server so it's available to nodes.  This is the final result that we would expect after the migration if you have a full migration.  You have your nodes checking in with Chef Server. You have your workstation where developers  are working and changing cookbooks. With the delivery track, it gets through the workflow,  deliver it to the Chef Server and later pull to nodes. So yeah, if you just want to take  a look in, how it will look if you will migrate. You can just add Chef Automate on your  current solo infrastructure and report your Chef Solo runs to Chef Automate Server.  I will come back to it in a second because before we start talking about it, we need to  get Chef Automate Server. The easiest one would be author to Chef Automate. You don't  need to set up your goals or three steps, multiple answers, questions and you wait for  10 minutes until it's up and running. You have it working with some extra curves on top,  like backups, continuous tells monitoring maintenance where we make sure that your Chef  Automate Server running the latest security updates and also we upgrade the version of  Chef Automate for you. Besides that, you just click the button, you put in great region,  whatever you need to have and then you have your service here. As well, since it's on  the AWS, you can benefit a lot from all the AWS infrastructure and services that we have.  Okay, so if only deep insights, what you should do. Get Chef Automate Server and then  you can get Delivery Talking from the ETC Delivery Delivery RB file. It will be on your  Chef Automate Server, you can SSH there and get the talking and then you configure your  data collector to report your Chef runs to the Chef Automate. That's pretty much it.  The next run, your note will be in Automate. As you can see on this screen, you have a  check-in time when it was the last check-in. You have the uptime, some basic data, general  data platform environment where it's running and once you have several more solar runs,  you will, in the detailed note view, you will see more ahead data. You will also see when  the Chef runs were performed. You will see how they performed. You can see what went wrong.  If something went wrong, if something is fine, then you can see that it was fine.  Okay, so imagine you take a look at this. This is something that you need. This is something  that you need for your cluster and you decide to migrate. So you need to, once again, bring  your book books to Chef Server and reconfigure your Chef clients to use the Chef Server.  Then you have clear benefits from Chef Automate and work clothes, environments, roles, all  the historical data, very clear overview on all your system. Okay, let's move. This is  how I imagine where we are moving from. So you have workstation that runs Chef Solar  using it for storing Google's Chef Solar runs in your instances, hopefully with Chrome,  and then checks out it from it or some other way you deliver the Google's to the node.  When you're launching Chef Server, when you launch a Chef Server with Officeworks Chef  Automate, besides credentials, Chef says the UI, you're getting also Start a Kit. Start  a Kit is simple archive. I really recommend you download it and pack it and you will see  clear folder structure where it's already set up to communicate directly to your Chef  Automate. And besides Google's environments, roles, folders where you need to store your  Google's environments and roles, you have a very interesting file that is called userdata.sh.  This is something that we prepared for you. So you can include it into the boot of your  system as your node and not go automatically checking it with Chef Automate. You don't  need to do anything, especially when you use Autospm, you just put it in the launch  configuration, I'll be there. So, okay, let's start. First, let's move Google's to Chef  Server. It seems a bit complicated. Very easy. You move into the folder on the Start a Kit  and then you deny the folder. Wait for a little, it's on the Chef Server. You're done. Let's  go for the second one. Bringing in nodes. This is a little bit more complicated. You need  to know where your nodes are. You need to collect them in one place. Basically, to bootstrap  the node and to bring the node into the Chef Automate Server, you need to know the node name  and the IP it can be reached. If you have some different SHK tests or different user names  that you have access to the node, you also grab the collected in one place and then just  click through a file and check it in with a non-boostrap. Yes. So, this is like an example  of a file. You have a node name, node IP, user, SSHK location. You just simply non-boostrap.  You can also easily already know how you want to organize your cluster in environments and  you can also include it in the Connect Bootstrap. Then you will save some time introducing nodes  into roles or environments later. Yes, you wait for a little, they run through and they  show up in your Chef Automate. It's actually the same view as you had when you were just  running for Intel Dimetry from Chef Color Rounds into Chef Automate, but now they're running  with the Chef Server. So, you don't need to organize them and making them checking out  your Google from somewhere else. It's all on the Chef Server. They have talked into the  Chef Server. They have all the infrastructure there. Yeah. High data, historical runs, if  something fails, you know what fails, if everything is good, you know that it's good.  Yeah. Now comes benefit. Basically, that's where you can start. If you don't want to  spend more time, you're already pretty good setup. The most benefit you have here at Chef Search,  your node, when it comes up and runs for a run to cookbooks, it already knows everything  about your cluster. What's going on there? You can include it into your recipes. Hopefully  you tested before you put it in the recipes with the Chef. Yeah, you can run it there.  It's told directly to Chef Automate and Chef Server. You run it there, you see what data  you have in your system. You make the search correct. You put it in the recipe. So now  your web applications can know which databases are up and running, for example, right now,  and configure themselves to talk to those databases. Or you can also use it in your  scripts using Night Search. Another good thing is Databx. You can create them in the Chef  Show. You can share it. So, the Databx is to share the data, the global data between all  your nodes, right? And you can iterate over them in your recipes as well. So, that's pretty  much it. If you want to go forward and bring workflows that I will actually hardly recommend  because it's a very unified way to bring your cookbook changes to your nodes. Yeah, I skipped,  as I mentioned, environments and roles because it's very simple setup. Just look up your documentation  and straightforward. You know how you want to organize it. And you will set it up in  a couple of minutes. And with the next checks all around, it will be in the Chef Automate  also visible. So, now we need to set up, if you're setting up workflows, you're setting  up the delivery truck that delivers, pushes your cookbook changes through the pipeline.  And it looks like this. It's almost full CD pipeline. There are two steps that you need  to do manually or manually approve and manually deliver. Because, which makes actually sense,  like you were working through the whole week on your changes to your cookbook. It was approved  by your colleagues. It builds, it runs tests, it runs smooth tests. And then it's ready to  be delivered. But it's ready to be delivered. You would rather go and dream of your, right?  You don't want to eat, you're going to production and having some of your weekend plans made this  very hopefully not. And most likely not, but still. You would feel rather better if it will  go out on Monday. So you have your next weekend to come back on Monday to work. First button,  it's up to production. After several more stages. Just to make sure that nothing broke during  the weekend. Right? So, just to recap, that's where we started. We have our radio long  minutes running Chef Sol knowing nothing but what you actually told them with maybe some  shared files or configurations. You had your workstation, you had your cookbooks in Git.  Then you moved your cookbooks into the Chef server once you got the Chef host. Then you  moved your notes into the Chef server. And then you set up the delivery truck and work  flows to deliver the changes you had to cookbooks, the Chef server, and then it would later be  picked up by your notes. So yeah, that's pretty much it. And the second good news that I didn't  tell you before, and you didn't tell me that I only told you on the one good news, is that  there is nothing heavy to be or coding. It's pretty straightforward. It's not that there  were no walls or clothes, right? There was nothing that you would do like, wait a second.  Wait a second. It's pretty straightforward. You know your notes, you know your environment,  you know how it should be. You simply move it. And yeah, as I mentioned, you can already  stop after the first two steps and wait for the work flows later because maybe you have  some other process that was already done for several years. It's very unified. Everyone  knows about that. So you might need to wait a little just for a second. And yeah.  That's pretty much it. Yeah. Okay. So we are around in our booth, in our AWS booth.  So if anyone wants to talk to us directly about their use cases and how that would apply to them,  we have a chance for the rest of the day. And yeah, we are on. Thanks a lot. See you.
From_Solo_to_Happy_0_131.png From_Solo_to_Happy_132_467.png From_Solo_to_Happy_468_899.png From_Solo_to_Happy_900_1991.png From_Solo_to_Happy_1992_3539.png From_Solo_to_Happy_3540_4751.png From_Solo_to_Happy_4752_7271.png From_Solo_to_Happy_7272_8339.png From_Solo_to_Happy_8340_18839.png From_Solo_to_Happy_18840_22415.png From_Solo_to_Happy_22416_23795.png From_Solo_to_Happy_23796_26219.png From_Solo_to_Happy_26220_27539.png From_Solo_to_Happy_27540_28127.png From_Solo_to_Happy_28128_28595.png From_Solo_to_Happy_28596_29627.png From_Solo_to_Happy_29628_30083.png From_Solo_to_Happy_30084_30767.png From_Solo_to_Happy_30768_31271.png From_Solo_to_Happy_31272_31823.png From_Solo_to_Happy_31824_32579.png From_Solo_to_Happy_32580_33215.png From_Solo_to_Happy_33216_34847.png From_Solo_to_Happy_34848_35219.png From_Solo_to_Happy_35220_36023.png From_Solo_to_Happy_36024_36155.png From_Solo_to_Happy_36156_37079.png From_Solo_to_Happy_37080_38099.png From_Solo_to_Happy_38100_38231.png From_Solo_to_Happy_38232_38531.png From_Solo_to_Happy_38532_38747.png From_Solo_to_Happy_38748_39635.png From_Solo_to_Happy_39636_39707.png From_Solo_to_Happy_39708_39815.png From_Solo_to_Happy_39816_40763.png From_Solo_to_Happy_40764_41267.png From_Solo_to_Happy_41268_42731.png From_Solo_to_Happy_42732_43247.png From_Solo_to_Happy_43248_43403.png From_Solo_to_Happy_43404_43523.png From_Solo_to_Happy_43524_43823.png From_Solo_to_Happy_43824_45863.png From_Solo_to_Happy_45864_45911.png From_Solo_to_Happy_45912_45959.png From_Solo_to_Happy_45960_45981.png