 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 1.2 I think. And then we kind of went through like some experiments and then we kind of turned our own 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 code deployment and a lot of 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 it just works in the way I 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. I've been involved with some open source projects but like many company work. I code with like many languages and Python. I did some SCAR, I did some PSP in the past. And I also like always like the kind of the sesame 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 that interest in kind of sesame first and then moving towards DevOps. I work for a company called Tri-Rees. It's a startup, we are based in London. I'm the head of engineering there. Before that, I work with other companies. Some of you may organize some names. Okay, so what is the thing about? Like 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 understand sesame. Obviously you can use Ansible but like Ansible is just a tool that helps you to do the same sesame work but like you still need to know sesame in order to do that. It just kind of simplifies some of the things but like certainly it doesn't tell you how to configure engine access, 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 it's having infrastructure as code. So like just saying historically you had like these figures called sesame 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 this 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 on 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 less margin for error this 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 the code anybody can understand how the system works. That's 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 entirely its own language. 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 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 are 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 maybe configuring packages you know whatever you chose to run it has this push approach the nice thing about this is it doesn't require you to install agents on the servers it doesn't 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 which I'm going to describe and there's another FICO 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 it in two big groups one is configuration management and if you want you can use Ansible for code deployments but like that's quite like a separate thing configuration management like that's like the traditional way to use these tools so when I say configuration management I mean like installing software on the server configuring 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 like 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 host section, task section and ender section so really the most important part here is the task section in this 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 what this file does it's basically 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 it's the APT line which is like there you specify the package name and you specify the state you want the package to be and 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 of date it will be upgraded so second action something you probably do for most of the software you install you have to use your own configuration files because for GNX you need to set up you have a file to configure the website so you need to upload this the template is basically a copy but like with some pre-processing done to it which is templating Ansible is using a ginger ginger is templating engine the same one used with flask the same autoflask what the template action does is takes this you change a file you 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 any scripts and in this case it's just about making sure GNX is running so if it's not running we call the any scripts to start GNX if it's running it won't do anything so then there's another important section here called Anders the basic idea around Anders is basically you list your handlers 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 you basically triggers the notify which is then connected to the handlers so in this case if the configuration file changed on the server you want to restart GNX so the notify will be triggered and then the handlers will be executed it's just like basically there 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 basically like the group of servers you want to apply this playbook to alright 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 to be honest it really makes sense from my perspective when you set up machines when you set up servers you would do things in order so it's quite convenient for me to reuse the same order 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 see the thing as in-party programming so it's not like the order is quite important that's how you define the dependencies between tasks that the thing is task card is important meaning that 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 you won't change the system you won't try to change the system if the system is already 181 you want that to be and already can describe the endos a bit basically there are commands fly for later execution so we have to execute only if there has been a change in the system typical case reloading a demon so the last type of file that you need to set up is the inventory file it's actually much simpler than a playbook it's just a list of domains or IP addresses you can group them by ours group if it makes sense to you like what we normally do is list all the web servers in one section list of the database servers in another section we are monitoring servers we are 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 ours group so 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 are like ours groups like really trying to understand how ours 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 list side 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 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 like logical level obviously to store web packages there are like many packages or many configuration files you need to apply you know just try to see that like from a kind of background so like you basically install all the web packages and then we configure our GNAX then we configure our supervisor because we're using supervisor and the thing we do is have a day restore backups you know everybody should do 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 you know if that is evaluating to true I'm going to come back to conditional so this will be more later you can tag operation tags meaning you can just write tag, SQL and any keyword that's quite 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 and but like the operations you do on configuration management they are quite similar unless you do you know lots of Java and demos to start crazy like that the other thing we use Ansible for are code deployments and 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 always you know they normally quite standard code deployments like it's really personalized like for your for your environment we have like 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 like you know just to describe you know the basic things we do we basically 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 and especially MPM and 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 using whiskey so when we finish all this whiskey we will store celery we will store everything we need basically in this extra code that we have it gets a bit trickier because there's many things that we need to add which are not standard then I already introduced the conditionals so basically it can be applied on any task and it's just like an extra line saying one and then an expression expression is already using Jinja so we got all the power of Jinja for free in this case when we deploy something we need to know what environment we're deploying so we first know if the app environment is not defined yeah I mean that's quite easy we just want to know the environment 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 that variable name at the end of the end of the execution of that task will contain some information about the task so the problem we had is I want to deploy production only the version of the website which has been tagged with the version because I know if they've been tagged with the version they are stable so they will probably be deployed there's no githug support there's no magnetic module to re-githug but you can still use a shell command so we run githug we put the output of this command in the githug variable and then we can reuse that variable in a conditional later on in this case the condition is production and the tag is not in the githug list in that case we need to fail I don't want to deploy the production version they won't be tested one thing to add is githug basically contains many properties and one of these properties is the standard output but it also contains hexagons like the time this command took many other things just go and check the website that's written everything there and one thing we use a lot in a lot of places is this with items so sometimes you want to run the same action multiple times on many packages or you're going to store for example many packages or many Debian packages and what you can do is repeat the same action copy and pasting it for every package and it might make sense this is certainly 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 we want to store the virtual language supervisor with pip 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 these machines or the mount points or a distribution name distribution version and CPU about disks and you may need some of these information when you for example write template files or you directly in Ansible playbook in this case we as a company use Ipset I want to let everybody know that something is in the deploy on a particular server with Ansible so let's model call Ipset it's already done for you so you don't need to 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 it's time this action is run you will get a different message deploy to www whatever your hostname is and you get that as many times as you have service so there's a lot of packages in Ansible and Ipset is just one of the many there are some which are more standard than others some of them are really specific with EC2 with this solution or like interface to backtracking system the actions or modules that we normally use are APT because we're using Ubuntu everywhere service if you're not like interface with any scripts pip packages if you're not store pip packages we use git the pro with git is quite limited you can only check our repositories you can't do any other git operation which are many but 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 then there's some more modules specific to the Python world like supervisor for example is one or Django manage their interfaces to run Django management commands or supervisor commands by the side there's many more so just to give you an idea of the sites we have more than a thousand lines of playbooks we do a lot of things with them we have four environments some of them production environments some of them staging environments we actually have more than the production machines because I just added a couple we run like PostgreSQL we run Neo4j we run 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 and we have like depth machines like everyone of the team has both local machine and the dissolution box they can deploy anytime we have some brass machines we run like on multiple cloud providers like AWS Dissolution Abbey Breaker Box it's a talk with sensible so basically it's quite nice because you do a big up and then you run step provision automatically so you actually get the final server it takes a while but you actually get it yeah, I mean that's I'm getting to the end of the talk you know, like a few suggestions just try to keep server stateless if you have like especially when you scale you really need to 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 the thing that will stop you when you have to scale when you have to have more than more than one web server or more than many web servers and the nice thing about DevOps is 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 Nginx to do that so you might want to configure Nginx 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 we have any questions so my question is I was reading that Ansible can also handle load balancers so there's like a model for a pipeline balancing do you have any experience with that we like we use load balancers so you were asking about load balancers and if we use load balancer modules when we do deployments so you talk about a specific type of load balancer well yeah my company really get 5 but basically questions rather we have an experience with Ansible load balancers okay we use load balancer for some of the one actually one of the environments we have the well like we still do it manually pretty much but like there's a lot of support like for easy to 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 Ansible rows are the thing that forces you a lot of basically a lot of convention so especially when you use Ansible rows it basically automatically gives you like a folder structure you need to follow the new kind of declared value sections the same besides that you can pretty much come out with a structure you want yeah 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 and you can like because everything is like kind of committed to repository you can always use the repository to do that in level of control who gets to deploy this I mean if you have the kind of SSH permission on the machine basically means you can run Ansible so like the control is really kind of built on top of SSH 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 called 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 the control is on SSH so if you have the SSH key you can use SSH sorry how do you copy SSH key the way that's a single management server where everybody who has permission to access the management server gets to configure all of the infrastructure or do you have several developers who have SSH permission to move some of the machines the way we do it now like I have the permission to kind of apply these configuration files in scripts on all machines setting up like a management server now to do that one problem I have with Ansible is that you enter a code in the end that's hard to run sorry if you have an error in the playbook yeah then you enter in the end you don't have to pay for it I only ran it with the old playbook okay and there is a flash manual so you can just link it 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 the enders didn't run like how do you do that yeah that's really annoying and what I normally do is like 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'm in the stone I don't have a perfect solution for it that was this thank you very much