We're Ramon and Greg from DocuSign, my name is, your name? My name is Ramon, I'm coming from Barcelona, I'm working at DocuSign as a software, sorry. Microphone? Yes. Because you don't have the remote control. No, exactly. I'm coming from Barcelona, I work at DocuSign as a software architect, and now I'm here.

Yeah, my name is Greg Robbins, I'm the technical director of e-commerce at DocuSign. 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 DocuSign 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, you know Ramon-VVV is kind of how he does things, 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. 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, test, 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? 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. 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 enjoy 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 this stuff we need to set up and buy. We would've saved two weeks off the lead time off of our project. So, 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've saved all of that 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 one, 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 produce some sort of caching mechanism. So that's a change that maybe happens later on in the software development lifecycle. So we need to reproduce some 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.

I 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. 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.

We're 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 going to talk

about DocuSign too much more. So what are 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. 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 to production. Vagrant and Chef Solo is what we need. And well, probably a visual designer for our presentations, because that's not what we're good at. So Ramon, do you wanna talk a little bit about the Toolbox? Yeah, okay. So the Toolbox, the Toolbox, the tools we're gonna use are mainly virtual bugs.

It's a software that will allow us to create virtual machines. Git, everybody knows Git. Next. And Vagrant. Vagrant is just a kind of software that wraps around below a 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 in stock, but their main operating system. One thing that it's awesome is that it offers a shared directory so you can run your application from the virtual machine,

but you edit your application from your horse with your preferred editor. For example, I don't know, PyCharm. Or Vim. Subversion. Vim. Yeah. Emacs? No, not Emacs. Okay, okay, okay. Is Nina out there? Yeah, we don't like Emacs. No, Nina was there. She left when we said no.

Yeah. So that you can code in local, run on the virtual machine. And then I have the two preferred commands. Greg commands. My favorite commands. Yeah, your favorite commands. So it's like the whip cracker on my team, right? 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 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. Yeah. 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 node mean, et cetera, et cetera. Basically what we're doing is vagrant add and saying as long as you are waking up 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, it's an open source tool and we like it. It allows us 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, you 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 its provision, this machine? Install some software into that virtual machine,

but in a way that we as developer like maybe more than if it were just C subs. It's doing code. With Chef, you can do whatever you can do in the common 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. I'd like to comment there that, so Chef is not a simple system. I mean, I think that we've given you, 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 all the 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. Oh, 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 things that we may need support. It's a big 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.

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. Actually, they've been bombarding my email box

for the last month, constantly trying to get me to buy this. And 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 it in the most proper way.

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 polls, in Catalan, my model tongue, that means lies. Yeah. The polls application, yes, and to do that.

It's just thinking about that word, sorry. Yeah, polls. Yeah, or lies. And for that we just use an Ubuntu server, 12.04, an NGINX, it's not used in the... So you can scratch him too, so, yeah. Wow, in the original tutorial, but it's interesting to have one of those.

Python, Django, and PostgreSQL as in NGINX, 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, virtual box,

vagrant, git, all the tools that we have been talking about. You can find in the tutorial all 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 is 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 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 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.

You 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'll like it more. Oh, because this is my attempt at artwork here. I'm actually a pretty good guitar player, but visual design is not my thing. So talking about Chef, Chef has these 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 repos, 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, you know, 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 Bergshelf and Bergsfile? Yeah, let's talk about Bergshelf and Bergsfile.

Bergshelf is... Which unfortunately don't have like food names, but... No, but Bergshelf is just a dependency manager. Think about Bergshelf as you could think about APTGAP or whatever. And the Bergsfile just lists what cookbooks we will need in order to install inside the virtual machine

as the structure of the file is quite simple. You see there's a source, a source line that says, I want all those cookbooks downloaded from supermarketketchef.com. You define what cookbooks do you want in the Bergsfile. 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 poll app. Exactly, it turns off. So you can grab cookbooks kind of from everywhere and Bergshelf is where you manage those dependencies. Bergshelf, in fact, gets installed with the GFTK

that we have set before we need it in order to start our adventure. 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 are projects, cookbooks are like a story,

you know, a group of related tasks. Recipe would be a specific task. Knife is the command line tool. So the Bergshelf is dependency management for. Because when you're new to the chef world, it can be quite confusing, the terminology that it uses. I'd like to have had that at the beginning.

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 lot to digest at first. Yes, a lot. Sorry, sorry. Okay. Sorry, sorry. 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. Databucks 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 Git repos. You can 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,

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, 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.conf file's gonna be more or less the same, except on different environments, I may want to 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 can see it's got quite a bit of configurability, depending on how you want to set up and how you want to 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, like it requires the Python cookbook in order to set up some of the dependencies. To create a user for the data, 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'll 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. Yeah, right, yeah. 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 knife solo init dot, 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 Burke Shelf, it was also really easy. All I did was create this Burke's file,

it's called Burke's file, the root directory of our project. I list the source, which is the supermarket, and then I put in the different dependencies, different places, different cookbooks that I want to 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 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 the command Burke's 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 recipes 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 the. In fact, this is a resource.

Yeah. We were talking before about that. Chef has many resources. One of them is Bash, it allows you to run, it allows you to run command line, command line, what? Yeah, command line code. Code, okay. Commands, right? 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? It's better than mine. And we have more resources. We have the resource gate, 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 Bash 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, yes, 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 to 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 and use. HTTP servers, databases, caching systems, Python, PHP, Ruby, whatever you need. And a lot of times they pretty much do what you need to do, but you might need to just tweak a few things. Or 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, you know, 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, you know, following the dry philosophy that we're all so fond of. If you do start using this technology, I recommend you take a look at this blog entry called Doing Wrapper 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 in the tutorial. So in summary, we're pretty much at the end here, you know. We hope you'll 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,

a get, you save a lot of time. It's cool, and they're skills that, you know, you can use in any project, really. It's not limited to Django at all. You know, we haven't really been talking about Django. We're 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.

We did it the right way. So we just wait for it. And that's the amazing Pulse tutorial application. WhatsApp, WhatsApp, NotMides, the Sky, both. Thank you. Five votes against five votes. So vote again, yes, please.

We're going to that page again, so it has worked. So once you get the components, you can download. You can do Vagrant up and you get this amazing application. It's a very amazing application. It's very hard to do. Absolutely for you and 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 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 the people want to go to have a beer. It's the last speech. I know I do. Yeah, yeah, we'll do it, we'll do it. So we'll do it. Okay.

Thank you.