 Well, Ramon and Greg from DakiSign. My name is, what, your name? My name is Ramon. I'm coming from Barcelona. I'm working at DeguSign as a software architect. Sorry. Microphone. Yes. Because we don't have the remote control. No, exactly. I'm coming from Barcelona. I work at DeguSign as a software architect, and now he is. My name is Greg Robbins. I'm the technical director of e-commerce at DakiSign. As Ramon said, we worked together actually the last couple of years on a lot of projects, both here and in San Francisco, and in Barcelona, e-commerce related projects, marketing, lead acquisition related products. And right now we're working on some exciting Django projects for DakiSign for customer support and lead acquisition. So we are looking for Django developers who'd like to come to San Francisco and work with us. Just so you know, you can come catch up with us after the presentation if you'd like more information on that. So for this talk, we're going to talk about a pretty complex subject about setting up development environments. We've created a, actually Ramon has created an awesome repository that contains a full tutorial with extremely detailed step-by-step Ramon-vvv. Yeah, that's nice, vvvvv. But it's really helpful because it walks you through every step of installing the different components that you would need for this. It also contains this presentation, so I would recommend you grab that at some point. Okay, so talking about reproducing environments, who should care? Well, developers care. Developers write code that need to run on some sort of environment. On some sort of environment. Developers usually want to write code. We like to write code. We don't like mucking about with environments. Nope. Well, I do. But that's, I'm just kind of strange. Team leads, so as a team lead, I really like reproducible environments because I know that my team can get down to working on their tasks instead of crapping around with broken environments and strange bugs that appear because things aren't consistent from one place to the next. SysOps people tend to appreciate this a lot because the work that we do when we're setting up a development environment for an application can also be applied to staging tests, production environments as well. And just kind of geeky people in general. I can see four really geeky people there that I know. But in general, people that are involved in Django projects can probably benefit from having a way to set up environments. So why is it important? You know, a typical project is gonna have lots of software packages. It's going to have maybe a database. Maybe it's gonna have a web server. It's gonna have some caching system. It's going to have a queue of some sort. I don't know. There's myriad things that Django itself, Python, all kinds of different software packages. Setting these things up manually, while there are some people that are kind of strange that I'm joined doing this like myself, it is pretty slow. It tends to be inaccurate because I may do it a different way than he does it, then she does it, then he does it. And we end up with different environments that aren't accurate. They aren't consistent across the board. And most people generally find this to be really boring work anyway. So it can really turn into a nightmare when you have a team. Last year, Ramon and I, when we were in Barcelona doing a project, we had a remote team in South America that they were pretty good coders, but they really didn't have much of an idea about environments. And they, I think that if we had had this system that we have now to just create a Git repository with all the stuff you need to set up environment, we would have saved two weeks off the lead time off of our project. And probably a lot of problems going forward too because every time we installed a new, like we figured out we needed caching in the system. Hey you guys, you gotta install caching. We'd have to write this tutorial about how to install caching and then they'd break it. And then it was just, we could have saved all of that by, by using this exact same system here. Your environments can change from one realm to another. Like development's not gonna be the same as staging. It's not gonna be the same as production. Maybe in development I have some sort of debugger running where I probably wouldn't have that in production. Although I do know a guy who did that. But that's another, I can tell you over beer later if you want. I'll tell you, it's horrific. And these environments also change over time, right? I mean, our applications are awesomely fast, but when they're not fast enough, maybe we need to introduce some sort of caching mechanism. So that's a change that maybe happens later on in the software development lifecycle. So we need reproducible environments. I think I've belabored the point quite a bit. I wanna spin up these new instances in just minutes, not hours or days or weeks. We want consistent results from them. And I want all of this in version control so that we can track it, share it, update it. So when we talk about setting up the reproducible environments and this presentation here, we're gonna talk about the tools, what they do, some best practices, at least according to us. Yeah, this is what's, so we're not. Gurus. No, we're not gurus. We're really nice guys, but we're not world-class experts on this. We're just sharing with you the system that we've used that has worked for us and has given us pretty consistently good results. You were sharing with you the Git repo that has the complete written tutorial dash VVV that Ramon put together, which is awesome. And we're not gonna really look at a whole lot of code right now. So as I said, we're not covering Django development here. This is more about environments. We're not gonna look at the code and we're also not doing to talk about DocuSign too much more. So one of the kind of problems we have that we need to solve. We have multiple dependencies. We need specific software versions. We probably don't have installation and configuration skills across the board on our team. Some people do, some people don't. They shouldn't really be that concerned with it anyway. Setup can take a long time and we have deadlines. So the solution, the solution is having a single place where the entire environment is defined. I want this under version control able to be able to make and apply changes over time and have it reusable as much as possible for different environments as we go from dev to staging production. Vagrant and Chef Solo is what we need. Well, probably a visual designer for our presentations because that's not what we're good at. So Ramon, you wanna talk a little bit about the toolbox? Yeah, okay. So the toolbox, the toolbox, the tools we're gonna use, mainly Bureau Box, Bureau Box, it's a software that will allow us to create Bureau Machines, Git, everybody knows Git, next, and Vagrant. Vagrant is just a kind of software that wraps around Bureau Box. It allows us to script how do we want to provision a machine. Vagrant starts with vanilla boxes. Vanilla boxes meaning that they are bare bones. They have nothing installed but the main operating system. One thing that it's awesome is that it offers a shared directory so you can run your application from the Bureau Machine but you edit your application from your horse with your preferred editor, for example, I don't know. PyCharm, Subersion, yeah, Emacs? No, not Emacs. Okay, okay, okay, okay. Is Nina out there? Yeah, we don't like Emacs. No, Nina was there. She left when we said that. Yeah. So that you can code in local, run on the Bureau Machine, and then are the two preferred commands, Greg commands. My favorite commands. Yeah, your favorite commands. Yeah, so it's like the whipcracker on my team, right? I like all you have to do to get these development environments up and running is download the repository and go in and type vagrant up and it will spin up the fully working virtual machine. You don't have to spend any more time configuring mucking about just two lines or two words and you've got the machine up and running. And the other one is vagrant provision which is when we've made some changes to that environment, vagrant provision will apply all of the, it will make the virtual machine match what you've defined in your Chef code. And I think now would be a great time in order to spin up our demo machine, okay. So we can see all of that. I'm sorry, I need to do this. Okay. Just that. In the tutorial, just explain what does note mean, et cetera, et cetera. But basically what we're doing is vagrant ad and saying as long as you are waking at the virtual machine, just provision it, okay. By the end of the speech, we will see if it has worked or not. It might even work, yeah. It might do it. Okay, so that's vagrant and why we like vagrant. We like open source tools. So vagrant is an open source tool and we like it. It allows to do whatever we want with virtual machine. It's very well adapted to virtual box which is also an open source tool. There are a lot of ready made boxes. Ubuntu, CentOS, whatever flavor of Linux that you can imagine. If you want, it can also work with Windows. So it's cool. And you can create your own base boxes in an easy way, in a very easy way. The other tool we have in our toolbox is Chef. Okay, what does Chef? If vagrant is able to spin up a machine, Chef, what does it provision this machine? Install some software into that virtual machine. But in a way that we as developers like maybe more than if we're just C-sobs. It's doing code. With Chef, you can do whatever you can do in the command line. You can create files, directories, delete them, whatever, I don't care. It's easy to keep track of your configuration changes. It's easy to keep track in Git so you can then share those changes with all your team and you get sure that all your team will have just the same configuration for their development machine, for example. And Chef makes all of that accessible through the network using a server, okay? So what's the main difference between Chef and Chef Solo? Chef Solo is just an open source port to Chef. It has no server side, no server component. It's much more easy to get started with and it has a plugin for vagrant that just works. So it's great to get started with that. So I'd like to comment there that, so Chef is not a simple system. I mean, I think that we'll be giving you the steps in the tutorial and the repository of how to get up and running and you can kind of see it laid out in a single tutorial, how other pieces fit together, which is something we couldn't find out on the internet. But anything that we could do to simplify at the beginning was a big help. So removing the server component from Chef simplified a great deal. Having said that, we do like that Chef has the server because as we evolve our projects and we evolve our environments definitions, we'll probably want to use some variation of those on staging, test and production environments. So all that work that we've done is going to be usable later on in Chef server, which is what we do use it at DocuSign. We use Chef server to provision different environments for our product. Sorry. That's cool. So why do we like Chef and Chef Solo? Mainly by the same reason that we like it, Vagrant because it's open source. As a big company, there are some times that we may need support. It's a paid support, it's available for Chef. So that's cool. It just get integrated very well with virtual box. It's very widely used, there are a lot of, it works with lots of operating systems. You can have a lot of cookbooks ready-made in order to just get started with it. Chef Solo, it's great for local environments so you can start learning right after download that component. One thing that I like for it is if I'm running a team or if I'm running an organization, it's again the fact that you can get professional support from Ops code, which is the company that makes Chef. I mean they make this, actually they've been bombarding my email box for the last month constantly trying to get me to buy this, but I mean they also have training available so that if you do get serious, that you want to move forward with this across different parts of your development organization that they can provide training by experts on it so that make sure that you're using them in the most proper way. Yeah. So after all that, what we're trying to achieve, what we're trying to achieve is just to spin up a virtual machine that runs the pulse in Catalan, my model tongue, that means lice. Yeah. The pulse application, yes. And to do that. My head, it's just thinking about that word, sorry. Yeah, polish. Yeah, more lice. And for that we just use an Ubuntu server, 1204, an engine X. It's not used in the... It's just scratching too, so yeah. Wow, in the original tutorial, but it's interesting to have one of those. Python, Django, and Post-Berserker as in engine X, it's just to make things really interesting. Okay, so what do we need to do all of that? We need to have installed in our host machine, we need to have installed Ruby, the Chef Development Kit, Brutal Box, Vagrant Git, all the tools that we have been talking about. You can find in the tutorial the links to those applications. And what are the two main parts that are implied when creating a virtual machine? We need the Vagrant file. The Vagrant file, it's the file that it's created by Vagrant when you initialize it. And it will tell Vagrant how to create the virtual machine, okay? And we need that Chef Kitchen. Chef Kitchen will say what are the software that we need to get installed into the virtual machine? Okay, it looks... We're gonna go into all this in the tutorial in a minute. Thank you. And of course, the application we want to run, okay? So what is a Vagrant file? A Vagrant file just defines a virtual machine. And how is a virtual machine is defined? Just putting the required plugins that you may have installed for Vagrant, just saying how you want the network configuration for your virtual machine, the processors, whatever you can define in virtual box, you can define it in a script in a Vagrant file. And to sum it to it, a Vagrant file is a Ruby script. So you can use all the power of Ruby just for that file. So... Just script it up. Yeah, it's scripted. So as it's a script, it's very easy to keep track of it and whatever. I think that part you like it more. Oh, because this is my attempted artwork here. I'm actually a pretty good guitar player, but visual design is not my thing. So talking about Chef, like Chef has these kind of main concepts and they're really cute names that all fit together. They have kitchen and then they have cookbooks and then they have recipes and then they have the knife. So we'll just talk a little bit about what those are. A kitchen contains many cookbooks. A kitchen, it's like a project, right? A single project usually has a single kitchen, right? Cookbooks are collections of recipes. So you can get predefined cookbooks for common tasks. Actually, you get them from the Chef supermarket, as it's called, or from Git repose or you can create your own. A cookbook is like a collection of related tasks. So you could have like an Apache cookbook, right? Install Apache, set up virtual hosts, set permissions, create the log files, blah, blah, blah. Or a MySQL cookbook that would do all these things related to setting up a MySQL server. Recipes are just specific instructions that are contained in the cookbook to do certain things, right? And then there's also the command-by-tool for using Chef, which is called knife, right? And I guess following along with this, the application that you're going to serve up would be the main course, right? Do you want to talk about the Berkshelf and Berksfile? Yeah, let's talk about Berkshelf and Berksfile. Berkshelf is... Unfortunately, don't have like food names, but... No, but Berkshelf is just a dependency manager. Think about Berkshelf as you could think about PIP, APTGAP, or whatever. And the Berksfile just lists what cookbooks we will need, do we will need in order to install inside the Bureau of Machines. The destructor of the file is quite simple. You see there's a source, a source line that says, I want all those cookbooks downloaded from supermarketcachef.com. You define what cookbooks do you want in the Berkshelf file? For example, for the APT cookbook, we want the 2.5.2 version. But not all every cookbook has to be downloaded from the source, you have defined. You can say, hey, I want the PostgreSQL cookbook to be downloaded from a Git repo, okay? Or even a path, a path in your hard disk, okay? In your disk, I don't know how to say that, in your local, okay. So like we made one there that's a cookbook that's going to install the Polls app, right? So like, as you can see, it just points to the current directory, site cookbooks, Pollapp. Exactly, it comes off. So you can grab cookbooks kind of from everywhere and Berkshelf is where you manage those dependencies. Berkshelf, in fact, gets installed with the ChefDK that we have set before we needed in order to start our adventure. Okay, so. I created this another fine attempt at graphic art where I kind of lined up the cute chef names with what they really are. So you can take a look at that. Kitchens or projects, cookbooks or like a story, you know, a group of related tasks. Recipe would be a specific task. Knife is the command line tool. So Berkshelf is dependency management for. Because when you're new to the Chef wall, it can be quite confusing the terminology that it's used. So we like to have that at the beginning, okay? Yeah, we suffered a little bit with that, you know? It's pretty clever the way they thought of the naming conventions, but it's a little, it's a lot to digest at first. Yes, a lot. Sorry, sorry. Okay. So once we create the kitchen, what we will find in it? We will find environments and nodes, basically. And some of the things that we're not going to talk about would be a very long speech, a data box, and roles. The main things about, you know, the way that we're using it is environments and nodes. Yeah. Yeah, so we go. So what's an environment? An environment defines a type of machine. It can be a development machine, a production machine, a staging machine, wherever. But it's a type of machine. It's defined in a file named whatever you want.json. So it's a json file. And you can see an example here. There's nothing too much more to say about that. Okay. You can set attributes for the cookbooks you have inside the environment. Yeah, we have a pretty well-defined, like, you know, files in our, and I get reposts, you know, look at those. Yeah. So. It's just json. Yeah, after environment, you can find nodes. Nodes, as environments, were a type of machine. A node, it's a specific machine, particular machine. Okay. So in our case, we have a machine that's named balls.example.com. It's a json file, as it was an environment. And it has a very cute attribute named runList. And runList is a pretty important attribute, in fact, because it will list every recipe that we want our nodes to get installed. Okay. And not just which recipes, but in which order do those recipes have to be installed. So keep that in mind, because it's very important. Every recipe that we want to get installed has to be inside this runList. So cookbooks. You are pretty much good cook. All right. Yeah, I like the cookbooks. So the cookbooks, these define the recipes, specific instructions. They have some other components in well, in a cookbook. A cookbook also uses templates. So I suppose you could use it for a lot of things, but we've been using it for configuration files, right? So we have a prefab, a precooked configuration file, like for Apache, for example. And in the Apache files, basically the Apache.com file is gonna be more or less the same, except on different environments, I may wanna set different configurations, different amounts of memory and different paths and so on and so forth. So those things that change from one environment or one node to another, I would set in a tributes file, right? So you could see it's got a quite a bit of configurability, depending on how you wanna set up and how you wanna use it across different environments. There's also the concept of resources. So resources are, they're like reusable class methods from other cookbooks, dependencies. I think when you see in our code where you set up the PostgreSQL, it requires the Python cookbook in order to set up some of the... To create a user for the database, for example. Exactly, right. So this is kind of what cookbooks do. And once again, you can download existing cookbooks from the supermarket or from GitHub, you probably find a lot of them, or you can create your own. Creating your own kitchen is really easy. I'm not gonna go through code here. Step one. So this is where I'm breaking my promise that I wasn't going to use code, but just to show how easy it is, I was able to do KnifeSoloInit.knife, being the command line tool for Ruby, and it set up the entire directory structure for the kitchen, which was great. Setting up dependency management, which is called Berkshelf, it was also really easy. All I did was create this Berks file. It's called Berksfile, the root directory of a project. I list the source, which is the supermarket, and then I put in the different dependencies, different places, different cookbooks that I wanna grab in order to set up my machines. And those can be local, they can be remote, they can be from the supermarket, they can be from GitHub, et cetera. And then creating your own cookbook is really easy too. The tools that Chef and Chef Solo give you are really pretty good. So I was just, I went into this, there's a directory called site cookbooks, which is where you keep your own custom-made cookbooks or your extended cookbooks. And just by typing, you know, the command Berks cookbook, my cookbook, it set up the entire cookbook structure for me. And all I have to do at that point is add a little bit of code to the recipe's default file, default RB, and that's the one that's gonna be run when the cookbook is called. So like in this example, I think we're setting up. In fact, this is a resource we were talking before about that Chef has many resources, one of them is Baish. It allows you to run command line, command line, what? Yeah, command line, code, commands. Okay, thank you, commands. But there are more. I'm sorry, I'm not, as you can see, English native speaker. Your English is great. What are you talking about? Thank you. It's better than mine. More resources, we have the resource guide, resource template, that, every one of them is quite self-explanatory. There's a really pretty full set of commands that Chef uses that is really helpful to create files to set permissions to run Baish commands, set up networking parts. I don't know. There's a whole lot that you can do with it. So the point of this is just really to show that it is really pretty easy to get started. The next thing you need to make sure and do, and we put this in because we suffered horribly about this because I didn't realize that you had to do both of these things. You have to add it, you have to add your new cookbook that the dependency manager, otherwise it doesn't know it's there and it will just ignore it. And if you want it to actually run, then you need to add it to the. To the run list of the note. Right, to the run list of the note that you mentioned before. So those, we thought that was, we had enough suffering on our side that it was worth putting that into its own slide in our presentation. And tell it to you so you won't have to suffer. Yes. Okay, so we're kind of getting towards the end here. I want to talk just a little bit about wrapper cookbooks. This was an interesting concept for me in particular. As I've been saying, OpsCode has all these great cookbooks in the supermarket that you can get used. HTTP servers, databases, caching systems, Python, PHP, Ruby, whatever you need. At a lot of times they pretty much do what you need to do, but you might need to just tweak a few things. So you might need to set some sort of configuration that they hadn't included in the version that they've currently got published. So my first temptation, actually the first thing I did was start cloning these from GitHub. And then I realized that I'm kind of digging myself into a hole here. And I came across the concept of wrapper cookbooks, which is actually a lot easier than trying to clone and manage your own cookbook. You simply define a wrapper around one of the existing ones and add in the new functionality that you want to use. So it's really following the dry philosophy that we're also fond of. If you do start using this technology, I recommend you take a look at this blog entry called Doing Rapper Cookbooks Right by Julian Dunn. I guess I forgot to put the link in here, but just Google that and it'll come up. Everyone refers to it, it's very helpful. It's a good story, yeah. So in summary, we're pretty much at the end here. We hope you give it a try. Check out VirtualBox, Vagrant and Chef for Development Environments. They're reproducible quickly and accurately. Everything's going to go into version control and get. You save a lot of time. It's cool and they're skills that you can use in any project really. It's not limited to Django at all. We haven't really been talking about Django, talking about environments. So whether you have another project that's in some other language, PHP, Ruby, whatnot. Yeah, it's all valid for that. And we do use it at DocuSign. So there's the link again. Do you want to check and see if that actually worked? Yes. Environment you're trying to set up. It worked. I'm sorry. There it is. Okay, first has to go out. Looks like it has ended the right way. So we just. Wait for it. And that's the amazing polls. Tutorial application. What's up? What's up? Not much, the sky, both. Thank you. Five votes against five votes. So vote again. Yes, please. So we go into that page again. So it has worked. So once you get the components, you can download. You can do vagrant up. Yeah. You get this amazing application. This very amazing application. It's very hard to do. On your local environment. So thanks everyone for your time. Thanks for listening. If anyone has any questions, we'll try to answer them. As I said, we're not. We're not gurus on the topic, but we'll try to answer the best we can. And anybody who's interested in coming and hanging out with us in San Francisco and DocuSign and doing some Django development, we'd love to speak to you afterwards too. I think that people want to go to have a beer. It's a last speech. I know I do. Yeah. We'll do it, we'll do it. So we'll be back. Okay. Thanks. Thank you.