Scaling with Ansible
Marani, Federico
Federico Marani - Scaling with Ansible Ansible is a powerful DevOps swiss-army knife tool, very easy to configure and with many extensions built-in. This talk will quickly introduce the basics of Ansible, then some real-life experience tips on how to use this tool, from setting up dev VMs to multi-server setups. - Infrastructure/Scaling is a topic really close to me, I'd like to have the chance to talk about how we set this up in the company I work for. Our infrastructure is around 10-15 servers, provisioned on different cloud providers, so a good size infrastructure. Presentation is going to be divided in 3 parts, first part is going to be focused on comparing sysadmin and devops, then there will be an introduction to the basic concepts of Ansible. I want to spend most on the last part, which is going to give some tips based on our experience with it. Many ideas will come from this presentation which i gave at DJUGL in London, with a longer session I will have more chances to delve into more detail, especially on how we use it, from vagrant boxes setup to AWS and DigitalOcean boxes, network configuration, software configurations, etc... I want to offer as many real-life tips as possible, without going too much offtopic as far as Ansible is concerned
 Now with us is Federico Marani talking about Ansible and DevOps. Hello everybody, my name is Federico Marani and I'm going to talk about Ansible. Ansible is a DevOps tool and we've been using it for a while now, we've been using it for around a year and a half, kind of started with like, version 1.2 I think, and then we kind of went through like some experiments and then we kind of turned our infrastructure into Ansible scripts and then we kind of like worked a lot on that idea and then we kind of extended it to do like many other things like such as school deployments and a lot of like kind of server setup. I've been trying some other tools like those tools and Ansible is a nice compromise because it's quite simple and like it just works in the way like it. Okay, so just to give a bit of introduction, I'm a coder so I've been coding Python for a long time and I've been involved with some open source projects but like many company work. I code with like many languages and Python, did some scarlet, did some PHP in the past and also like always like the kind of the sysami side of things because it's quite nice when you know both sides, you can code, you can deploy, you can configure server. So I always had an interest in kind of sysami first and then moving towards DevOps. Our first company called Tri-Reese, it's a startup, we are based in London and I had a very good engineering there. Before that, they work with other companies, some of you may recognize some names. Okay, so what is the thing about? Like, you know, obviously we like talk about Ansible but like what is the real problem behind it? The problem behind it is DevOps and the problem behind DevOps is system administration really. You can do DevOps if you don't, if you don't understand sysami, obviously you can use Ansible but like Ansible is just a tool that helps you to do the same sysami work but like you still need to know sysami in order to do that. Like it just kind of simplifies some of the things but like certainly it doesn't tell you how to configure in Ginect, it doesn't tell you how to configure Sudo, it doesn't tell you how to configure any other tools that you might use in your stock. So, yeah, I mean basically this failure is lots of the complexity of system administration. So, you really need to know how these systems work and then you can use Ansible to simplify your workflow, basically. So, what is DevOps? DevOps is like basically like one simple concept and is having infrastructure as code. So, like just saying historically, you had like this figure called sysami which like go on the server and then do this, all this manual thing and like nobody, nobody knew what they were doing, they were like just doing magic on the server and somehow the server got into a state it was working and then suddenly these people, I leave the company and nobody knows like what they've done to the server and like we basically lose track of like all these changes. So, like what changed some time ago, especially when kind of DevOps became a big thing, basically now every change you do on the system is going through this process of coding and then you basically have the coding as a first step and then these deployments of infrastructure changes like you basically roll them out on one server or many servers like you know whatever number of servers you have. And what DevOps is about is about automation as well because I mean we are engineers so we like to, without when things are automated like this, this less, it's just pretty nice, you don't have to think about these things anymore, you just have this automation in place. People leave companies, so that's another good point, like you don't want knowledge to escape the companies, you want to keep the knowledge within the company and anybody can read a code, anybody can understand how the system works. Another point I feel strongly about and there's a lot of DevOps tool out there which like they borrow too many ideas from programming languages. So I mean I love coding, I've done a lot of it but I don't feel necessarily the connection between like doing DevOps and doing coding. So I don't think DevOps should not require primary experience. This tool is like, you know, Chef is really kind of Ruby based for example and the Papa does like, you know, entire its own language. Yeah, I think that this, you know, I was looking for a tool that kind of made this distinction a bit clear and that's when I came to Ansible. Ansible is a really nice tool, it's really quick to get started, it's really easy, it builds on top of like tools that we all should know like Python, SSH, YAML files, it's written in Python, it's extensible with Python, you can write plugins in Python, you can write plugins in other languages I think. Like differently from other systems, it's based on the idea of like pushing updates to the server instead of the server having the responsibility of pulling updates. Obviously this behavior can be tweaked but the idea is like you run Ansible on your machine or a management machine and it basically connects to every server and pushes the operation that you want to run on the server. This operation may be like installing packages or maybe configuring packages, you know, whatever you chose to run. Yes, this push approach. The nice thing about this is it does require you to install agents on the servers, it does require you to have a central repository of configuration files. Yeah, I mean it's just a different way. It's based on the idea of playbooks, so you can use Ansible in a simpler way but like I'm going to talk about playbooks and playbooks are basically a list of tasks, so there is like a task section I'm going to describe and there's another file called inventory file, so those are like the two basic files you need to set up. Okay, you can use Ansible for many things. I generally like tend to distinguish in two big groups. One is configuration management and if you want you can use Ansible for code deployments but like that's quite a separate thing. Configuration management, that's like the traditional way to use these tools. So when I say configuration management, I mean like installing software on the server, bring like this software, making sure all the demos are started, making sure all the network interfaces are up, making sure all the firewalls are set, you know, these type of operations are basically like the traditional way to use these tools. Okay, so this is a playbook, this is like how you kind of the basic file for using Ansible. It's divided in three sections, you got like cross section, task section and the section. So really the most important part here is the task section. In this playbook there are three tasks, each one with a name and each one with an action. Action is in this case is APT template and service. So I mean this file is really easy to put this file down, specifically set up on GNX server on your machine, on many machines. So the very first thing you would do is make sure GNX is installed and it's the latest version. So to do that you basically need one line, APT line, which is like there, you specify the package name and you specify the state you want the package to be. When Ansible runs this action, what it will do is basically check if GNX is already installed, if it's already installed and it's already the latest version, it won't do anything, it won't cause any change in the server. If it's not installed or if it's out to date, it will be upgraded. Okay, so second action, like some say you probably do like for most of the software install, you have to use your own configuration files because I mean for instance actually you need to set up like you have a file to like configure the website so like you need to upload this. Template is basically a copy but like with some pre-processing down to it, just templating. Ansible is using a GINJA, GINJA is templating engine, the same one used with Flask and same autoflask. What the template action does is takes this GINJA file and you like feed it to the template engine with a bunch of variables that are available in Ansible and you can specify also variables in playbooks and that the output of this kind of templated file is then copied on the server to that destination path there. Yeah, that's basically it. Third action here is the service action. Service action basically is an interface to Winning scripts and in this case it's just about like making sure GINJA is running. So if it's not running, we call the InScript to start GINJA. If it's running, it won't do anything. So then there's another important section here called endless. So the basic idea around endless is basically you list your endless and you can execute those on demand like at the end of your task list and you can execute them only if there's been a change like kind of associated to the, in this case, to the template action. So if the template action caused a change in the target server, it basically triggers the notify which is then connected to the endless. So in this case, if the configuration file changed on the server, you want to restart GINJAX. So the notify will be triggered and then the endless will be executed. It's just like basically they are action you execute only when a notify has been called. So the last thing here is the host section. It's actually a section you need, you always need and basically like the group of servers you want to apply this playbook to. All right. So task order is important. That's how Ansible works. That's not how other tools work. It's really kind of typical of Ansible. And I mean, to be honest, like it really makes sense, like from my perspective, when you set up machines, when you set up servers, like you would do things in order. So like it's quite convenient for me to, you know, to reuse the same order when I define when I define this task, it's really kind of a nice way to think about problems like in steps. So like really kind of say the thing as it's an same party programming. So it's not like, you know, the order is quite important. That's how you define dependencies between tasks. That the thing is task card is important. Meaning that like you can execute the playbook as many times as you want and you won't try to install it twice. You won't try to override the configuration file if the configuration file is already on the server. That's a nice feature. And basically like you won't change the system. You won't try to change the system if the system is already in the state you want that to be. I already can describe the endos a bit. Basically there are commands fly for later execution. So we execute only if there has been a change in the system. Typical case reloading a demo. Okay. So the last type of file that you need to set up is the inventory file. That would be like much simpler than a playbook. It's just a list of domains or IP addresses. You can group them by OS group if it makes sense to you. Like, you know, like what we normally do is like list all the web servers in one section. List all the database servers in another section. We have monitoring servers. We have a trillion of type of servers. Like one thing you can do with inventory files that we found really helpful is you can define like variables per inventory per OS group. For example, like for all the web servers you want to declare that the build environment is production or staging or whatever environment you have. You may want to declare some database names in case you're running multiple versions of the same website on one machine. You can do the same thing like for database servers. Yeah, that's the feature we use a lot, basically. Okay. So the important things here are like OS groups. Like really kind of trying to understand how OS groups work. I mean, it's actually quite easy. But there are some little things that you need to know. There's a feature called roles in Ansible. We found it like really helpful, especially because basically defines like a common convention like to include files within your playbook. So if you have like a long list of tasks you need to run on the server, you may want to split this task into multiple files. I mean, the same idea behind the programming language is you basically split your file into multiple files. That's why there are includes and you should use them. And always try to use the actual inside effects. Meaning if you don't need to template a file, you can just use copy. Basically, there's less chances to trigger a change in the server and the change you don't really want to trigger. Okay. So this is how do you find includes. These are actually like a real snippet of production code we use. So you can basically see the operations you do on the server on a more logical level. Obviously to store what packages there are like many packages or many configuration files you need to apply. Just try to see that from a kind of higher ground. So you basically store all the web packages and then we configure on GNX, then we configure on a supervisor because we're using supervisor. Another thing we do is have a day restore backups. Everybody should do like backup testing. But like we restore it from production to staging. So you can do conditional includes if you want. And all the tasks in this include will be included only if that variable is, you know, if that is evaluating the truth. I'm going to come back to conditional except to be more later. You can tag operation, tags meaning you can just write tag SQL and any keyword. That's quite a nice thing because sometimes you only need to execute parts of your Ansible scripts or you may want to ignore some tags and that's a nice way to do it. Okay. So that was like kind of the basics basically. We introduced a playbook, we introduced inventory files, we did some other things. But like the operations you do on configuration management, they are quite similar. Unless you do, you know, like lots of Java and demos to start or anything crazy like that. The other thing we use Ansible for are code deployments. The problem with code deployments is that they can be really custom. Like the really like one, like, you know, when you write things like configure servers, they are always, you know, they normally quite standard. Code deployments, like it's really personalized like for your, for environment. We have like, you know, a ton of Python. We have many based on Django. So, you know, this is actually like some playbooks that work well for us. But, you know, just to describe, you know, the basic things we do, we basically create virtual environments. We store dependencies in the virtual environments. We use Bower, we use like Node.js and we use Grunt, like to do compilation of facets like server side. And Ansible has some support for these tools, especially in NPM. It doesn't support Bower, but I can always run shell commands so we can run Bower store with the shell command. We use Grunt, so we just trigger a shell command to run the ground compilation server side. And there's some, you know, standard operation you do with Django, like you basically collect all the static files, you run the migrations, you want to run the migrations only in the case the migrations are not already applied. And, yeah, I mean, there is some setup to do that. We use a whiskey, so when we finish all this, we are starting whiskey, we're starting celery, we're starting everything we need. Okay, so basically in this extra code that we have, like, it gets a bit trickier because there's like, you know, there's many things that we need to add which are not standard. They already introduced the conditioners. Conditioners are basically can be applied on any task. And it's just like an extra line saying one and then an expression. Expression is all the way to using Jinja, so we got all the power of Jinja for free. In this case, like, we don't want, like, when we deploy something, we need to know what environment we're deploying. So we first failure if the app environment is not defined. Yeah, I mean, that's quite easy. We just want to know the environment. Okay. It's another operation that we found quite useful. We used this in a few places. It's a register operation. The idea behind register is that, I mean, you can register a variable name. And that variable name at the end of the execution of that task will contain some information about the task. So the problem we had is we want, like, I want to deploy production only the version of the website which are being tagged with the version. Because I know if they've been tagged with the version, they are stable. So they might be deployed. There's no task support in the snow magnetic model to do tasks, to read the git tags. But you can still use a share command. So we run git tag. We put the output of this command in the git tags variable. And then we can reuse that variable in a conditional later on. So in this case, like, the conditional is a production and the tag is not in the git tags list. In that case, we need to fail. Like, I don't want to deploy the production version that they don't be tested. Yeah. And one thing to add is git tags basically contains many properties. And one of these properties is the standard output. But I also contains X equals, like the time this command took, many other things. Yeah. Just go and check the website that's written, everything there. One thing we use a lot in a lot of places is with items. So sometimes you want to run the same action multiple times on, like, many packages or you're going to store, like, for example, like many packages or many debut packages. What you can do is repeat the same action, copy and pasting it, like, for every package. And it might make sense. This is certainly like a nicer way to do it. So you basically run the same action. It's basically a loop. You run the same action on many items. In this case, you want to store virtual element supervisor with pip. Another nice thing that there is in Ansible is something called facts. Facts are basically data coming from the server, from the current server. Ansible facts may be like the hostname, for example, or the IP addresses that is machinous or the mount points or a distribution name, distribution version, and data about CPU, about disks. And you may need to do some of these, some of the information, when you, for example, like, you know, write template files or you directly in Ansible playbook. In this case, like, we as a company use Ipset, and we, like, I want to let everybody know that, like, something is in the ploy on a particular server with Ansible as a model called Ipset. It's already done for you, so you don't need to, you know, write any Python code to talk to Ipset. You specify the room, you specify the message. The message is trained that can be a template. And basically what happens is this action will be run for every server that is in your playbook, and this action is run, you will get, like, a different message. So, deploy to, W-W-W, deploy to whatever your hostname is, and you get that as many times as you have servers. Okay. So, there's a lot of packages in Ansible. I mean, Ipset is just one of the many. And there are some which are being more standard than others. Some of them are really specific on, with EC2 or with this solution or, like, something, or, like, interface to backtracking system. The actions or modules that we normally use are APT because we're using, like, Ubuntu everywhere. Service, if you know, like, kind of interface with Inescript. PIP packages, if you're in store, PIP packages. We use Git. The Pro with Git is quite limited. You can only check our repositories. You can do any other Git operation, which are many. There's a file module if you want to check the presence of directories, if you want to check the presence of files or links. And some more modules specific to the Python world, like supervisor, for example, is one, or jungle manage their interfaces to run jungle management commands or supervisor commands. As I said, there's many more. So just to give you, like, an idea of the size, like, we have more than a thousand lines of playbooks. We do a lot of things with them. We have, like, around, we have four environments, some of them production environments, some of them staging environments. We actually have more than the production machines. I just added a couple. We were on, like, Posca Square, Neo4j, NGINX, Solar Machines. Basically, like, the way you set up all of them is quite similar. There's a bit of extra setup for Solar and Neo4j because they're based on the JVM. We have, like, that machines, like, everyone of the team has, like, both like local machine and the dissolution box so they can deploy anytime. We have some brass machines. We run, like, on multiple cloud providers, like AWS dissolution. Every fragrant box is set up with sensible. So basically, it's quite nice because you do a big up, up, and then you run step provision automatically. So you actually get, like, the final server. It takes a while, but, like, you actually get it. Yeah. I mean, that's, I'm cutting to the end of the talk. You know, like a few suggestions. Just try to keep server stateless if you have, like, you know, especially when you scale, like, you really need to, like, not, for example, I store a file on a particular server and not on another. Because that file will become, like, a state and then that's kind of the thing that will stop you when you have to scale and you have to have more than one web server or more than, like, you know, many web servers. And the nice thing about DevOps is it kind of allows you to do things in the right place. You can do, like, IP geolocation, for example, both in code or in server, like infrastructure level, just like models for engine X to do that. So you might want to configure engine X in a way that does geolocation for you or you can do it in the code. Yeah. I mean, I think that's probably it. Thank you very much. Thank you. Yes. Do you have any questions? Okay. So the question is I was reading the question. Do you have any experience with that? We, like, we use load balance, sorry. So you were asking about load balance certainly for use, like load balance and modules when we do deployments. So you're talking about a specific type of load balance or load balance or load balance. Well, yeah, my company really gets five, but basically questions rather be of an experience with as a load load. Okay. We use load balancer for some of the, actually one of the environments we have. Well, like, we still do it manually pretty much. But like this, the sort of support like for is it true load balancer and other type of load balancer. But yeah, I mean, we don't do it. We kind of do that process manually. So we take the machine off the load balancer and then we deploy to that specific machine and then do this thing manually basically. Okay. So the question was about if there is a specific convention about like kind of where you put files and, you know, as a rule, you are the thing that in kind of forces you a lot of this is a lot of convention. So especially when you use Ansible, Ansible rules, basically automatically gives you like a folder structure you need to, you need to follow when you kind of declared various sections. The thing besides that you can pretty much come out with a structure you want. Yeah. Hi. How do you control who gets to configure the structure? So how do I get to control who figures who like kind of does the infrastructure, sets up the infrastructure. You can like because everything is like kind of committed to repository can always use the repository to do that level of control. Who gets to deploy this? I mean, if you have the kind of SSAs permission on the machine basically means you can run Ansible. So like the control is really kind of built on top of SSAs. I mean, there are tools that you can put on top of Ansible if you know, especially when you use management servers and this tool they release on Ansible Tower. I don't think it's free or maybe it's free for like some like a limited amount of servers. But like as it stands, basically control is on SSH. So if you have the SSH key you can configure SSH. Sorry, how do you copy SSH key? The way we do it now is basically like I have the permission to like to kind of apply this configuration files, scripts on all machines. Setting up like a master server now to do that. Sorry, if you have an error in the playbook. So the problem is if there is an error in the playbook, let's just say for example like you are copying a configuration file and then like an error happens so then this didn't run like how do you do that? Yeah, that's really annoying. And what I normally do is you can either like force a change in the file or like I'm sure there are like, you know, more clever ways to do it. But yeah, I mean the store, I don't have a purpose to wish of it. Okay. That was it. Thank you very much again. Thank you. Thank you.
 Now with us is Federico Marani talking about Ansible and DevOps.  Hello everybody, my name is Federico Marani and I'm going to talk about Ansible. Ansible  is a DevOps tool and we've been using it for a while now, we've been using it for around  a year and a half, kind of started with like, version 1.2 I think, and then we kind of went  through like some experiments and then we kind of turned our infrastructure into Ansible  scripts and then we kind of like worked a lot on that idea and then we kind of extended  it to do like many other things like such as school deployments and a lot of like kind  of server setup. I've been trying some other tools like those tools and Ansible is a nice  compromise because it's quite simple and like it just works in the way like it. Okay, so  just to give a bit of introduction, I'm a coder so I've been coding Python for a long  time and I've been involved with some open source projects but like many company work.  I code with like many languages and Python, did some scarlet, did some PHP in the past  and also like always like the kind of the sysami side of things because it's quite nice when  you know both sides, you can code, you can deploy, you can configure server. So I always  had an interest in kind of sysami first and then moving towards DevOps. Our first company  called Tri-Reese, it's a startup, we are based in London and I had a very good engineering  there. Before that, they work with other companies, some of you may recognize some names. Okay,  so what is the thing about? Like, you know, obviously we like talk about Ansible but like  what is the real problem behind it? The problem behind it is DevOps and the problem behind  DevOps is system administration really. You can do DevOps if you don't, if you don't understand  sysami, obviously you can use Ansible but like Ansible is just a tool that helps you  to do the same sysami work but like you still need to know sysami in order to do that. Like  it just kind of simplifies some of the things but like certainly it doesn't tell you how  to configure in Ginect, it doesn't tell you how to configure Sudo, it doesn't tell you  how to configure any other tools that you might use in your stock. So, yeah, I mean basically  this failure is lots of the complexity of system administration. So, you really need  to know how these systems work and then you can use Ansible to simplify your workflow,  basically. So, what is DevOps? DevOps is like basically like one simple concept and is having  infrastructure as code. So, like just saying historically, you had like this figure called  sysami which like go on the server and then do this, all this manual thing and like nobody,  nobody knew what they were doing, they were like just doing magic on the server and somehow  the server got into a state it was working and then suddenly these people, I leave the  company and nobody knows like what they've done to the server and like we basically lose  track of like all these changes. So, like what changed some time ago, especially when  kind of DevOps became a big thing, basically now every change you do on the system is going  through this process of coding and then you basically have the coding as a first step  and then these deployments of infrastructure changes like you basically roll them out on  one server or many servers like you know whatever number of servers you have. And what DevOps  is about is about automation as well because I mean we are engineers so we like to, without  when things are automated like this, this less, it's just pretty nice, you don't have  to think about these things anymore, you just have this automation in place. People leave  companies, so that's another good point, like you don't want knowledge to escape the companies,  you want to keep the knowledge within the company and anybody can read a code, anybody  can understand how the system works. Another point I feel strongly about and there's a  lot of DevOps tool out there which like they borrow too many ideas from programming languages.  So I mean I love coding, I've done a lot of it but I don't feel necessarily the connection  between like doing DevOps and doing coding. So I don't think DevOps should not require  primary experience. This tool is like, you know, Chef is really kind of Ruby based for  example and the Papa does like, you know, entire its own language. Yeah, I think that  this, you know, I was looking for a tool that kind of made this distinction a bit clear  and that's when I came to Ansible. Ansible is a really nice tool, it's really quick to  get started, it's really easy, it builds on top of like tools that we all should know  like Python, SSH, YAML files, it's written in Python, it's extensible with Python, you  can write plugins in Python, you can write plugins in other languages I think. Like differently  from other systems, it's based on the idea of like pushing updates to the server instead  of the server having the responsibility of pulling updates. Obviously this behavior can  be tweaked but the idea is like you run Ansible on your machine or a management machine and  it basically connects to every server and pushes the operation that you want to run  on the server. This operation may be like installing packages or maybe configuring packages, you  know, whatever you chose to run. Yes, this push approach. The nice thing about this is  it does require you to install agents on the servers, it does require you to have a central  repository of configuration files. Yeah, I mean it's just a different way. It's based  on the idea of playbooks, so you can use Ansible in a simpler way but like I'm going  to talk about playbooks and playbooks are basically a list of tasks, so there is like  a task section I'm going to describe and there's another file called inventory file,  so those are like the two basic files you need to set up. Okay, you can use Ansible  for many things. I generally like tend to distinguish in two big groups. One is configuration  management and if you want you can use Ansible for code deployments but like that's quite  a separate thing. Configuration management, that's like the traditional way to use these  tools. So when I say configuration management, I mean like installing software on the server,  bring like this software, making sure all the demos are started, making sure all the  network interfaces are up, making sure all the firewalls are set, you know, these type  of operations are basically like the traditional way to use these tools. Okay, so this is a  playbook, this is like how you kind of the basic file for using Ansible. It's divided  in three sections, you got like cross section, task section and the section. So really the  most important part here is the task section. In this playbook there are three tasks, each  one with a name and each one with an action. Action is in this case is APT template and  service. So I mean this file is really easy to put this file down, specifically set up  on GNX server on your machine, on many machines. So the very first thing you would do is make  sure GNX is installed and it's the latest version. So to do that you basically need  one line, APT line, which is like there, you specify the package name and you specify the  state you want the package to be. When Ansible runs this action, what it will do is basically  check if GNX is already installed, if it's already installed and it's already the latest  version, it won't do anything, it won't cause any change in the server. If it's not installed  or if it's out to date, it will be upgraded. Okay, so second action, like some say you  probably do like for most of the software install, you have to use your own configuration  files because I mean for instance actually you need to set up like you have a file to  like configure the website so like you need to upload this. Template is basically a copy  but like with some pre-processing down to it, just templating. Ansible is using a  GINJA, GINJA is templating engine, the same one used with Flask and same autoflask. What  the template action does is takes this GINJA file and you like feed it to the template  engine with a bunch of variables that are available in Ansible and you can specify also variables  in playbooks and that the output of this kind of templated file is then copied on the server  to that destination path there. Yeah, that's basically it. Third action here is the service  action. Service action basically is an interface to Winning scripts and in this case it's just  about like making sure GINJA is running. So if it's not running, we call the InScript  to start GINJA. If it's running, it won't do anything. So then there's another important  section here called endless. So the basic idea around endless is basically you list your  endless and you can execute those on demand like at the end of your task list and you  can execute them only if there's been a change like kind of associated to the, in this case,  to the template action. So if the template action caused a change in the target server,  it basically triggers the notify which is then connected to the endless. So in this  case, if the configuration file changed on the server, you want to restart GINJAX. So  the notify will be triggered and then the endless will be executed. It's just like basically  they are action you execute only when a notify has been called. So the last thing here is  the host section. It's actually a section you need, you always need and basically like  the group of servers you want to apply this playbook to. All right. So task order is important.  That's how Ansible works. That's not how other tools work. It's really kind of typical of  Ansible. And I mean, to be honest, like it really makes sense, like from my perspective,  when you set up machines, when you set up servers, like you would do things in order.  So like it's quite convenient for me to, you know, to reuse the same order when I define  when I define this task, it's really kind of a nice way to think about problems like  in steps. So like really kind of say the thing as it's an same party programming. So it's  not like, you know, the order is quite important. That's how you define dependencies between  tasks. That the thing is task card is important. Meaning that like you can execute the playbook  as many times as you want and you won't try to install it twice. You won't try to override  the configuration file if the configuration file is already on the server. That's a nice  feature. And basically like you won't change the system. You won't try to change the system  if the system is already in the state you want that to be. I already can describe the  endos a bit. Basically there are commands fly for later execution. So we execute only  if there has been a change in the system. Typical case reloading a demo. Okay. So the  last type of file that you need to set up is the inventory file. That would be like much  simpler than a playbook. It's just a list of domains or IP addresses. You can group them  by OS group if it makes sense to you. Like, you know, like what we normally do is like  list all the web servers in one section. List all the database servers in another section.  We have monitoring servers. We have a trillion of type of servers. Like one thing you can  do with inventory files that we found really helpful is you can define like variables per  inventory per OS group. For example, like for all the web servers you want to declare  that the build environment is production or staging or whatever environment you have.  You may want to declare some database names in case you're running multiple versions of  the same website on one machine. You can do the same thing like for database servers.  Yeah, that's the feature we use a lot, basically. Okay. So the important things here are like  OS groups. Like really kind of trying to understand how OS groups work. I mean, it's actually  quite easy. But there are some little things that you need to know. There's a feature called  roles in Ansible. We found it like really helpful, especially because basically defines  like a common convention like to include files within your playbook. So if you have like  a long list of tasks you need to run on the server, you may want to split this task into  multiple files. I mean, the same idea behind the programming language is you basically  split your file into multiple files. That's why there are includes and you should use them.  And always try to use the actual inside effects. Meaning if you don't need to template a file,  you can just use copy. Basically, there's less chances to trigger a change in the server  and the change you don't really want to trigger. Okay. So this is how do you find includes.  These are actually like a real snippet of production code we use. So you can basically  see the operations you do on the server on a more logical level. Obviously to store  what packages there are like many packages or many configuration files you need to apply.  Just try to see that from a kind of higher ground. So you basically store all the web  packages and then we configure on GNX, then we configure on a supervisor because we're  using supervisor. Another thing we do is have a day restore backups. Everybody should do  like backup testing. But like we restore it from production to staging. So you can do  conditional includes if you want. And all the tasks in this include will be included only  if that variable is, you know, if that is evaluating the truth. I'm going to come back  to conditional except to be more later. You can tag operation, tags meaning you can just  write tag SQL and any keyword. That's quite a nice thing because sometimes you only need  to execute parts of your Ansible scripts or you may want to ignore some tags and that's  a nice way to do it. Okay. So that was like kind of the basics basically. We introduced  a playbook, we introduced inventory files, we did some other things. But like the operations  you do on configuration management, they are quite similar. Unless you do, you know, like  lots of Java and demos to start or anything crazy like that. The other thing we use Ansible  for are code deployments. The problem with code deployments is that they can be really  custom. Like the really like one, like, you know, when you write things like configure  servers, they are always, you know, they normally quite standard. Code deployments, like it's  really personalized like for your, for environment. We have like, you know, a ton of Python. We  have many based on Django. So, you know, this is actually like some playbooks that work  well for us. But, you know, just to describe, you know, the basic things we do, we basically  create virtual environments. We store dependencies in the virtual environments. We use Bower,  we use like Node.js and we use Grunt, like to do compilation of facets like server side.  And Ansible has some support for these tools, especially in NPM. It doesn't support Bower,  but I can always run shell commands so we can run Bower store with the shell command.  We use Grunt, so we just trigger a shell command to run the ground compilation server side.  And there's some, you know, standard operation you do with Django, like you basically collect  all the static files, you run the migrations, you want to run the migrations only in the  case the migrations are not already applied. And, yeah, I mean, there is some setup to  do that. We use a whiskey, so when we finish all this, we are starting whiskey, we're  starting celery, we're starting everything we need. Okay, so basically in this extra  code that we have, like, it gets a bit trickier because there's like, you know, there's many  things that we need to add which are not standard. They already introduced the conditioners.  Conditioners are basically can be applied on any task. And it's just like an extra line  saying one and then an expression. Expression is all the way to using Jinja, so we got all  the power of Jinja for free. In this case, like, we don't want, like, when we deploy  something, we need to know what environment we're deploying. So we first failure if the  app environment is not defined. Yeah, I mean, that's quite easy. We just want to know the  environment. Okay. It's another operation that we found quite useful. We used this in a few  places. It's a register operation. The idea behind register is that, I mean, you can register  a variable name. And that variable name at the end of the execution of that task will  contain some information about the task. So the problem we had is we want, like, I want  to deploy production only the version of the website which are being tagged with the version.  Because I know if they've been tagged with the version, they are stable. So they might  be deployed. There's no task support in the snow magnetic model to do tasks, to read  the git tags. But you can still use a share command. So we run git tag. We put the output  of this command in the git tags variable. And then we can reuse that variable in a conditional  later on. So in this case, like, the conditional is a production and the tag is not in the  git tags list. In that case, we need to fail. Like, I don't want to deploy the production  version that they don't be tested. Yeah. And one thing to add is git tags basically contains  many properties. And one of these properties is the standard output. But I also contains  X equals, like the time this command took, many other things. Yeah. Just go and check  the website that's written, everything there. One thing we use a lot in a lot of places  is with items. So sometimes you want to run the same action multiple times on, like, many  packages or you're going to store, like, for example, like many packages or many debut  packages. What you can do is repeat the same action, copy and pasting it, like, for every  package. And it might make sense. This is certainly like a nicer way to do it. So you  basically run the same action. It's basically a loop. You run the same action on many items.  In this case, you want to store virtual element supervisor with pip. Another nice thing that  there is in Ansible is something called facts. Facts are basically data coming from the server,  from the current server. Ansible facts may be like the hostname, for example, or the  IP addresses that is machinous or the mount points or a distribution name, distribution  version, and data about CPU, about disks. And you may need to do some of these, some  of the information, when you, for example, like, you know, write template files or you  directly in Ansible playbook. In this case, like, we as a company use Ipset, and we, like,  I want to let everybody know that, like, something is in the ploy on a particular server with  Ansible as a model called Ipset. It's already done for you, so you don't need to, you know,  write any Python code to talk to Ipset. You specify the room, you specify the message.  The message is trained that can be a template. And basically what happens is this action  will be run for every server that is in your playbook, and this action is run, you will  get, like, a different message. So, deploy to, W-W-W, deploy to whatever your hostname  is, and you get that as many times as you have servers. Okay. So, there's a lot of packages  in Ansible. I mean, Ipset is just one of the many. And there are some which are being  more standard than others. Some of them are really specific on, with EC2 or with this  solution or, like, something, or, like, interface to backtracking system. The actions or modules  that we normally use are APT because we're using, like, Ubuntu everywhere. Service, if  you know, like, kind of interface with Inescript. PIP packages, if you're in store, PIP packages.  We use Git. The Pro with Git is quite limited. You can only check our repositories. You can  do any other Git operation, which are many. There's a file module if you want to check  the presence of directories, if you want to check the presence of files or links. And  some more modules specific to the Python world, like supervisor, for example, is one, or jungle  manage their interfaces to run jungle management commands or supervisor commands. As I said,  there's many more. So just to give you, like, an idea of the size, like, we have more than  a thousand lines of playbooks. We do a lot of things with them. We have, like, around,  we have four environments, some of them production environments, some of them staging environments.  We actually have more than the production machines. I just added a couple. We were on, like,  Posca Square, Neo4j, NGINX, Solar Machines. Basically, like, the way you set up all of  them is quite similar. There's a bit of extra setup for Solar and Neo4j because they're  based on the JVM. We have, like, that machines, like, everyone of the team has, like, both  like local machine and the dissolution box so they can deploy anytime. We have some  brass machines. We run, like, on multiple cloud providers, like AWS dissolution. Every  fragrant box is set up with sensible. So basically, it's quite nice because you do a big up,  up, and then you run step provision automatically. So you actually get, like, the final server.  It takes a while, but, like, you actually get it. Yeah. I mean, that's, I'm cutting to  the end of the talk. You know, like a few suggestions. Just try to keep server stateless  if you have, like, you know, especially when you scale, like, you really need to, like,  not, for example, I store a file on a particular server and not on another. Because that file  will become, like, a state and then that's kind of the thing that will stop you when  you have to scale and you have to have more than one web server or more than, like, you  know, many web servers. And the nice thing about DevOps is it kind of allows you to do  things in the right place. You can do, like, IP geolocation, for example, both in code  or in server, like infrastructure level, just like models for engine X to do that. So you  might want to configure engine X in a way that does geolocation for you or you can do  it in the code. Yeah. I mean, I think that's probably it. Thank you very much.  Thank you. Yes. Do you have any questions? Okay. So the question is I was reading the  question. Do you have any experience with that? We, like, we use load balance, sorry.  So you were asking about load balance certainly for use, like load balance and modules when  we do deployments. So you're talking about a specific type of load balance or load balance  or load balance. Well, yeah, my company really gets five, but basically questions rather  be of an experience with as a load load. Okay. We use load balancer for some of the, actually  one of the environments we have. Well, like, we still do it manually pretty much. But like  this, the sort of support like for is it true load balancer and other type of load balancer.  But yeah, I mean, we don't do it. We kind of do that process manually. So we take the  machine off the load balancer and then we deploy to that specific machine and then do  this thing manually basically. Okay. So the question was about if there is a specific  convention about like kind of where you put files and, you know, as a rule, you are the  thing that in kind of forces you a lot of this is a lot of convention. So especially when  you use Ansible, Ansible rules, basically automatically gives you like a folder structure  you need to, you need to follow when you kind of declared various sections. The thing besides  that you can pretty much come out with a structure you want. Yeah.  Hi. How do you control who gets to configure the structure?  So how do I get to control who figures who like kind of does the infrastructure, sets  up the infrastructure. You can like because everything is like kind of committed to repository  can always use the repository to do that level of control. Who gets to deploy this? I mean,  if you have the kind of SSAs permission on the machine basically means you can run Ansible.  So like the control is really kind of built on top of SSAs. I mean, there are tools that  you can put on top of Ansible if you know, especially when you use management servers  and this tool they release on Ansible Tower. I don't think it's free or maybe it's free  for like some like a limited amount of servers. But like as it stands, basically control is  on SSH. So if you have the SSH key you can configure SSH. Sorry, how do you copy SSH  key?  The way we do it now is basically like I have the permission to like to kind of apply this  configuration files, scripts on all machines. Setting up like a master server now to do  that.  Sorry, if you have an error in the playbook.  So the problem is if there is an error in the playbook, let's just say for example like  you are copying a configuration file and then like an error happens so then this didn't  run like how do you do that? Yeah, that's really annoying. And what I normally do is  you can either like force a change in the file or like I'm sure there are like, you  know, more clever ways to do it.  But yeah, I mean the store, I don't have a purpose to wish of it.  Okay.  That was it.  Thank you very much again.  Thank you.  Thank you.
Federico_Marani_-_Scaling_with_Ansible_0_4127.png Federico_Marani_-_Scaling_with_Ansible_4128_6359.png Federico_Marani_-_Scaling_with_Ansible_6360_6503.png Federico_Marani_-_Scaling_with_Ansible_6504_7499.png Federico_Marani_-_Scaling_with_Ansible_7500_9155.png Federico_Marani_-_Scaling_with_Ansible_9156_9383.png Federico_Marani_-_Scaling_with_Ansible_9384_9503.png Federico_Marani_-_Scaling_with_Ansible_9504_9599.png Federico_Marani_-_Scaling_with_Ansible_9600_9815.png Federico_Marani_-_Scaling_with_Ansible_9816_10115.png Federico_Marani_-_Scaling_with_Ansible_10116_22427.png Federico_Marani_-_Scaling_with_Ansible_22428_22679.png Federico_Marani_-_Scaling_with_Ansible_22680_24251.png Federico_Marani_-_Scaling_with_Ansible_24252_24383.png Federico_Marani_-_Scaling_with_Ansible_24384_24527.png Federico_Marani_-_Scaling_with_Ansible_24528_24743.png Federico_Marani_-_Scaling_with_Ansible_24744_24959.png Federico_Marani_-_Scaling_with_Ansible_24960_25115.png Federico_Marani_-_Scaling_with_Ansible_25116_25223.png Federico_Marani_-_Scaling_with_Ansible_25224_27311.png Federico_Marani_-_Scaling_with_Ansible_27312_28115.png Federico_Marani_-_Scaling_with_Ansible_28116_28427.png Federico_Marani_-_Scaling_with_Ansible_28428_28571.png Federico_Marani_-_Scaling_with_Ansible_28572_28619.png Federico_Marani_-_Scaling_with_Ansible_28620_29891.png Federico_Marani_-_Scaling_with_Ansible_29892_29987.png Federico_Marani_-_Scaling_with_Ansible_29988_30371.png Federico_Marani_-_Scaling_with_Ansible_30372_31499.png Federico_Marani_-_Scaling_with_Ansible_31500_36035.png Federico_Marani_-_Scaling_with_Ansible_36036_36359.png Federico_Marani_-_Scaling_with_Ansible_36360_36407.png Federico_Marani_-_Scaling_with_Ansible_36408_36623.png Federico_Marani_-_Scaling_with_Ansible_36624_36851.png Federico_Marani_-_Scaling_with_Ansible_36852_37247.png Federico_Marani_-_Scaling_with_Ansible_37248_37619.png Federico_Marani_-_Scaling_with_Ansible_37620_37775.png Federico_Marani_-_Scaling_with_Ansible_37776_37943.png Federico_Marani_-_Scaling_with_Ansible_37944_38375.png Federico_Marani_-_Scaling_with_Ansible_38376_38927.png Federico_Marani_-_Scaling_with_Ansible_38928_39083.png Federico_Marani_-_Scaling_with_Ansible_39084_39359.png Federico_Marani_-_Scaling_with_Ansible_39360_39563.png Federico_Marani_-_Scaling_with_Ansible_39564_39623.png Federico_Marani_-_Scaling_with_Ansible_39624_39743.png Federico_Marani_-_Scaling_with_Ansible_39744_40187.png Federico_Marani_-_Scaling_with_Ansible_40188_43055.png Federico_Marani_-_Scaling_with_Ansible_43056_43163.png Federico_Marani_-_Scaling_with_Ansible_43164_44003.png Federico_Marani_-_Scaling_with_Ansible_44004_46343.png Federico_Marani_-_Scaling_with_Ansible_46344_46727.png Federico_Marani_-_Scaling_with_Ansible_46728_47003.png Federico_Marani_-_Scaling_with_Ansible_47004_51131.png Federico_Marani_-_Scaling_with_Ansible_51132_51179.png Federico_Marani_-_Scaling_with_Ansible_51180_52187.png Federico_Marani_-_Scaling_with_Ansible_52188_52247.png Federico_Marani_-_Scaling_with_Ansible_52248_60905.png
Now with us is Federico Marani talking about Ansible and DevOps. Hello everybody, my name is Federico Marani and I'm going to talk about Ansible. Ansible is a DevOps tool and we've been using it for a while now, we've been using it for around a year and a half, kind of started with like, version 1.2 I think, and then we kind of went through like some experiments and then we kind of turned our infrastructure into Ansible scripts and then we kind of like worked a lot on that idea and then we kind of extended it to do like many other things like such as school deployments and a lot of like kind of server setup. I've been trying some other tools like those tools and Ansible is a nice compromise because it's quite simple and like it just works in the way like it. Okay, so just to give a bit of introduction, I'm a coder so I've been coding Python for a long time and I've been involved with some open source projects but like many company work. I code with like many languages and Python, did some scarlet, did some PHP in the past and also like always like the kind of the sysami side of things because it's quite nice when you know both sides, you can code, you can deploy, you can configure server. So I always had an interest in kind of sysami first and then moving towards DevOps. Our first company called Tri-Reese, it's a startup, we are based in London and I had a very good engineering there. Before that, they work with other companies, some of you may recognize some names. Okay, so what is the thing about? Like, you know, obviously we like talk about Ansible but like what is the real problem behind it? The problem behind it is DevOps and the problem behind DevOps is system administration really. You can do DevOps if you don't, if you don't understand sysami, obviously you can use Ansible but like Ansible is just a tool that helps you to do the same sysami work but like you still need to know sysami in order to do that. Like it just kind of simplifies some of the things but like certainly it doesn't tell you how to configure in Ginect, it doesn't tell you how to configure Sudo, it doesn't tell you how to configure any other tools that you might use in your stock. So, yeah, I mean basically this failure is lots of the complexity of system administration. So, you really need to know how these systems work and then you can use Ansible to simplify your workflow, basically. So, what is DevOps? DevOps is like basically like one simple concept and is having infrastructure as code. So, like just saying historically, you had like this figure called sysami which like go on the server and then do this, all this manual thing and like nobody, nobody knew what they were doing, they were like just doing magic on the server and somehow the server got into a state it was working and then suddenly these people, I leave the company and nobody knows like what they've done to the server and like we basically lose track of like all these changes. So, like what changed some time ago, especially when kind of DevOps became a big thing, basically now every change you do on the system is going through this process of coding and then you basically have the coding as a first step and then these deployments of infrastructure changes like you basically roll them out on one server or many servers like you know whatever number of servers you have. And what DevOps is about is about automation as well because I mean we are engineers so we like to, without when things are automated like this, this less, it's just pretty nice, you don't have to think about these things anymore, you just have this automation in place. People leave companies, so that's another good point, like you don't want knowledge to escape the companies, you want to keep the knowledge within the company and anybody can read a code, anybody can understand how the system works. Another point I feel strongly about and there's a lot of DevOps tool out there which like they borrow too many ideas from programming languages. So I mean I love coding, I've done a lot of it but I don't feel necessarily the connection between like doing DevOps and doing coding. So I don't think DevOps should not require primary experience. This tool is like, you know, Chef is really kind of Ruby based for example and the Papa does like, you know, entire its own language. Yeah, I think that this, you know, I was looking for a tool that kind of made this distinction a bit clear and that's when I came to Ansible. Ansible is a really nice tool, it's really quick to get started, it's really easy, it builds on top of like tools that we all should know like Python, SSH, YAML files, it's written in Python, it's extensible with Python, you can write plugins in Python, you can write plugins in other languages I think. Like differently from other systems, it's based on the idea of like pushing updates to the server instead of the server having the responsibility of pulling updates. Obviously this behavior can be tweaked but the idea is like you run Ansible on your machine or a management machine and it basically connects to every server and pushes the operation that you want to run on the server. This operation may be like installing packages or maybe configuring packages, you know, whatever you chose to run. Yes, this push approach. The nice thing about this is it does require you to install agents on the servers, it does require you to have a central repository of configuration files. Yeah, I mean it's just a different way. It's based on the idea of playbooks, so you can use Ansible in a simpler way but like I'm going to talk about playbooks and playbooks are basically a list of tasks, so there is like a task section I'm going to describe and there's another file called inventory file, so those are like the two basic files you need to set up. Okay, you can use Ansible for many things. I generally like tend to distinguish in two big groups. One is configuration management and if you want you can use Ansible for code deployments but like that's quite a separate thing. Configuration management, that's like the traditional way to use these tools. So when I say configuration management, I mean like installing software on the server, bring like this software, making sure all the demos are started, making sure all the network interfaces are up, making sure all the firewalls are set, you know, these type of operations are basically like the traditional way to use these tools. Okay, so this is a playbook, this is like how you kind of the basic file for using Ansible. It's divided in three sections, you got like cross section, task section and the section. So really the most important part here is the task section. In this playbook there are three tasks, each one with a name and each one with an action. Action is in this case is APT template and service. So I mean this file is really easy to put this file down, specifically set up on GNX server on your machine, on many machines. So the very first thing you would do is make sure GNX is installed and it's the latest version. So to do that you basically need one line, APT line, which is like there, you specify the package name and you specify the state you want the package to be. When Ansible runs this action, what it will do is basically check if GNX is already installed, if it's already installed and it's already the latest version, it won't do anything, it won't cause any change in the server. If it's not installed or if it's out to date, it will be upgraded. Okay, so second action, like some say you probably do like for most of the software install, you have to use your own configuration files because I mean for instance actually you need to set up like you have a file to like configure the website so like you need to upload this. Template is basically a copy but like with some pre-processing down to it, just templating. Ansible is using a GINJA, GINJA is templating engine, the same one used with Flask and same autoflask. What the template action does is takes this GINJA file and you like feed it to the template engine with a bunch of variables that are available in Ansible and you can specify also variables in playbooks and that the output of this kind of templated file is then copied on the server to that destination path there. Yeah, that's basically it. Third action here is the service action. Service action basically is an interface to Winning scripts and in this case it's just about like making sure GINJA is running. So if it's not running, we call the InScript to start GINJA. If it's running, it won't do anything. So then there's another important section here called endless. So the basic idea around endless is basically you list your endless and you can execute those on demand like at the end of your task list and you can execute them only if there's been a change like kind of associated to the, in this case, to the template action. So if the template action caused a change in the target server, it basically triggers the notify which is then connected to the endless. So in this case, if the configuration file changed on the server, you want to restart GINJAX. So the notify will be triggered and then the endless will be executed. It's just like basically they are action you execute only when a notify has been called. So the last thing here is the host section. It's actually a section you need, you always need and basically like the group of servers you want to apply this playbook to. All right. So task order is important. That's how Ansible works. That's not how other tools work. It's really kind of typical of Ansible. And I mean, to be honest, like it really makes sense, like from my perspective, when you set up machines, when you set up servers, like you would do things in order. So like it's quite convenient for me to, you know, to reuse the same order when I define when I define this task, it's really kind of a nice way to think about problems like in steps. So like really kind of say the thing as it's an same party programming. So it's not like, you know, the order is quite important. That's how you define dependencies between tasks. That the thing is task card is important. Meaning that like you can execute the playbook as many times as you want and you won't try to install it twice. You won't try to override the configuration file if the configuration file is already on the server. That's a nice feature. And basically like you won't change the system. You won't try to change the system if the system is already in the state you want that to be. I already can describe the endos a bit. Basically there are commands fly for later execution. So we execute only if there has been a change in the system. Typical case reloading a demo. Okay. So the last type of file that you need to set up is the inventory file. That would be like much simpler than a playbook. It's just a list of domains or IP addresses. You can group them by OS group if it makes sense to you. Like, you know, like what we normally do is like list all the web servers in one section. List all the database servers in another section. We have monitoring servers. We have a trillion of type of servers. Like one thing you can do with inventory files that we found really helpful is you can define like variables per inventory per OS group. For example, like for all the web servers you want to declare that the build environment is production or staging or whatever environment you have. You may want to declare some database names in case you're running multiple versions of the same website on one machine. You can do the same thing like for database servers. Yeah, that's the feature we use a lot, basically. Okay. So the important things here are like OS groups. Like really kind of trying to understand how OS groups work. I mean, it's actually quite easy. But there are some little things that you need to know. There's a feature called roles in Ansible. We found it like really helpful, especially because basically defines like a common convention like to include files within your playbook. So if you have like a long list of tasks you need to run on the server, you may want to split this task into multiple files. I mean, the same idea behind the programming language is you basically split your file into multiple files. That's why there are includes and you should use them. And always try to use the actual inside effects. Meaning if you don't need to template a file, you can just use copy. Basically, there's less chances to trigger a change in the server and the change you don't really want to trigger. Okay. So this is how do you find includes. These are actually like a real snippet of production code we use. So you can basically see the operations you do on the server on a more logical level. Obviously to store what packages there are like many packages or many configuration files you need to apply. Just try to see that from a kind of higher ground. So you basically store all the web packages and then we configure on GNX, then we configure on a supervisor because we're using supervisor. Another thing we do is have a day restore backups. Everybody should do like backup testing. But like we restore it from production to staging. So you can do conditional includes if you want. And all the tasks in this include will be included only if that variable is, you know, if that is evaluating the truth. I'm going to come back to conditional except to be more later. You can tag operation, tags meaning you can just write tag SQL and any keyword. That's quite a nice thing because sometimes you only need to execute parts of your Ansible scripts or you may want to ignore some tags and that's a nice way to do it. Okay. So that was like kind of the basics basically. We introduced a playbook, we introduced inventory files, we did some other things. But like the operations you do on configuration management, they are quite similar. Unless you do, you know, like lots of Java and demos to start or anything crazy like that. The other thing we use Ansible for are code deployments. The problem with code deployments is that they can be really custom. Like the really like one, like, you know, when you write things like configure servers, they are always, you know, they normally quite standard. Code deployments, like it's really personalized like for your, for environment. We have like, you know, a ton of Python. We have many based on Django. So, you know, this is actually like some playbooks that work well for us. But, you know, just to describe, you know, the basic things we do, we basically create virtual environments. We store dependencies in the virtual environments. We use Bower, we use like Node.js and we use Grunt, like to do compilation of facets like server side. And Ansible has some support for these tools, especially in NPM. It doesn't support Bower, but I can always run shell commands so we can run Bower store with the shell command. We use Grunt, so we just trigger a shell command to run the ground compilation server side. And there's some, you know, standard operation you do with Django, like you basically collect all the static files, you run the migrations, you want to run the migrations only in the case the migrations are not already applied. And, yeah, I mean, there is some setup to do that. We use a whiskey, so when we finish all this, we are starting whiskey, we're starting celery, we're starting everything we need. Okay, so basically in this extra code that we have, like, it gets a bit trickier because there's like, you know, there's many things that we need to add which are not standard. They already introduced the conditioners. Conditioners are basically can be applied on any task. And it's just like an extra line saying one and then an expression. Expression is all the way to using Jinja, so we got all the power of Jinja for free. In this case, like, we don't want, like, when we deploy something, we need to know what environment we're deploying. So we first failure if the app environment is not defined. Yeah, I mean, that's quite easy. We just want to know the environment. Okay. It's another operation that we found quite useful. We used this in a few places. It's a register operation. The idea behind register is that, I mean, you can register a variable name. And that variable name at the end of the execution of that task will contain some information about the task. So the problem we had is we want, like, I want to deploy production only the version of the website which are being tagged with the version. Because I know if they've been tagged with the version, they are stable. So they might be deployed. There's no task support in the snow magnetic model to do tasks, to read the git tags. But you can still use a share command. So we run git tag. We put the output of this command in the git tags variable. And then we can reuse that variable in a conditional later on. So in this case, like, the conditional is a production and the tag is not in the git tags list. In that case, we need to fail. Like, I don't want to deploy the production version that they don't be tested. Yeah. And one thing to add is git tags basically contains many properties. And one of these properties is the standard output. But I also contains X equals, like the time this command took, many other things. Yeah. Just go and check the website that's written, everything there. One thing we use a lot in a lot of places is with items. So sometimes you want to run the same action multiple times on, like, many packages or you're going to store, like, for example, like many packages or many debut packages. What you can do is repeat the same action, copy and pasting it, like, for every package. And it might make sense. This is certainly like a nicer way to do it. So you basically run the same action. It's basically a loop. You run the same action on many items. In this case, you want to store virtual element supervisor with pip. Another nice thing that there is in Ansible is something called facts. Facts are basically data coming from the server, from the current server. Ansible facts may be like the hostname, for example, or the IP addresses that is machinous or the mount points or a distribution name, distribution version, and data about CPU, about disks. And you may need to do some of these, some of the information, when you, for example, like, you know, write template files or you directly in Ansible playbook. In this case, like, we as a company use Ipset, and we, like, I want to let everybody know that, like, something is in the ploy on a particular server with Ansible as a model called Ipset. It's already done for you, so you don't need to, you know, write any Python code to talk to Ipset. You specify the room, you specify the message. The message is trained that can be a template. And basically what happens is this action will be run for every server that is in your playbook, and this action is run, you will get, like, a different message. So, deploy to, W-W-W, deploy to whatever your hostname is, and you get that as many times as you have servers. Okay. So, there's a lot of packages in Ansible. I mean, Ipset is just one of the many. And there are some which are being more standard than others. Some of them are really specific on, with EC2 or with this solution or, like, something, or, like, interface to backtracking system. The actions or modules that we normally use are APT because we're using, like, Ubuntu everywhere. Service, if you know, like, kind of interface with Inescript. PIP packages, if you're in store, PIP packages. We use Git. The Pro with Git is quite limited. You can only check our repositories. You can do any other Git operation, which are many. There's a file module if you want to check the presence of directories, if you want to check the presence of files or links. And some more modules specific to the Python world, like supervisor, for example, is one, or jungle manage their interfaces to run jungle management commands or supervisor commands. As I said, there's many more. So just to give you, like, an idea of the size, like, we have more than a thousand lines of playbooks. We do a lot of things with them. We have, like, around, we have four environments, some of them production environments, some of them staging environments. We actually have more than the production machines. I just added a couple. We were on, like, Posca Square, Neo4j, NGINX, Solar Machines. Basically, like, the way you set up all of them is quite similar. There's a bit of extra setup for Solar and Neo4j because they're based on the JVM. We have, like, that machines, like, everyone of the team has, like, both like local machine and the dissolution box so they can deploy anytime. We have some brass machines. We run, like, on multiple cloud providers, like AWS dissolution. Every fragrant box is set up with sensible. So basically, it's quite nice because you do a big up, up, and then you run step provision automatically. So you actually get, like, the final server. It takes a while, but, like, you actually get it. Yeah. I mean, that's, I'm cutting to the end of the talk. You know, like a few suggestions. Just try to keep server stateless if you have, like, you know, especially when you scale, like, you really need to, like, not, for example, I store a file on a particular server and not on another. Because that file will become, like, a state and then that's kind of the thing that will stop you when you have to scale and you have to have more than one web server or more than, like, you know, many web servers. And the nice thing about DevOps is it kind of allows you to do things in the right place. You can do, like, IP geolocation, for example, both in code or in server, like infrastructure level, just like models for engine X to do that. So you might want to configure engine X in a way that does geolocation for you or you can do it in the code. Yeah. I mean, I think that's probably it. Thank you very much. Thank you. Yes. Do you have any questions? Okay. So the question is I was reading the question. Do you have any experience with that? We, like, we use load balance, sorry. So you were asking about load balance certainly for use, like load balance and modules when we do deployments. So you're talking about a specific type of load balance or load balance or load balance. Well, yeah, my company really gets five, but basically questions rather be of an experience with as a load load. Okay. We use load balancer for some of the, actually one of the environments we have. Well, like, we still do it manually pretty much. But like this, the sort of support like for is it true load balancer and other type of load balancer. But yeah, I mean, we don't do it. We kind of do that process manually. So we take the machine off the load balancer and then we deploy to that specific machine and then do this thing manually basically. Okay. So the question was about if there is a specific convention about like kind of where you put files and, you know, as a rule, you are the thing that in kind of forces you a lot of this is a lot of convention. So especially when you use Ansible, Ansible rules, basically automatically gives you like a folder structure you need to, you need to follow when you kind of declared various sections. The thing besides that you can pretty much come out with a structure you want. Yeah. Hi. How do you control who gets to configure the structure? So how do I get to control who figures who like kind of does the infrastructure, sets up the infrastructure. You can like because everything is like kind of committed to repository can always use the repository to do that level of control. Who gets to deploy this? I mean, if you have the kind of SSAs permission on the machine basically means you can run Ansible. So like the control is really kind of built on top of SSAs. I mean, there are tools that you can put on top of Ansible if you know, especially when you use management servers and this tool they release on Ansible Tower. I don't think it's free or maybe it's free for like some like a limited amount of servers. But like as it stands, basically control is on SSH. So if you have the SSH key you can configure SSH. Sorry, how do you copy SSH key? The way we do it now is basically like I have the permission to like to kind of apply this configuration files, scripts on all machines. Setting up like a master server now to do that. Sorry, if you have an error in the playbook. So the problem is if there is an error in the playbook, let's just say for example like you are copying a configuration file and then like an error happens so then this didn't run like how do you do that? Yeah, that's really annoying. And what I normally do is you can either like force a change in the file or like I'm sure there are like, you know, more clever ways to do it. But yeah, I mean the store, I don't have a purpose to wish of it. Okay. That was it. Thank you very much again. Thank you. Thank you.
Federico Marani and I'm going to talk about kind of turned our infrastructure into Ansible moving towards DevOps. Our first company called and I had a very good engineering there. Before you how to configure in Ginect, it doesn't tell like they borrow too many ideas from programming came to Ansible. Ansible is a really nice tool, you to have a central repository of configuration It's based on the idea of playbooks, so you can basic file for using Ansible. It's divided in this file is really easy to put this file down, you probably do like for most of the software triggers the notify which is then connected to want to restart GINJAX. So the notify will be already in the state you want that to be. I the last type of file that you need to set up is do it. Okay. So that was like kind of the basics to give you, like, an idea of the size, like, we around, we have four environments, some of them environments. We actually have more than the run, like, on multiple cloud providers, like AWS experience with as a load load. Okay. We use load convention. So especially when you use Ansible, much come out with a structure you want. Yeah. when you use management servers and this tool like I have the permission to like to kind of