 So this is more structured towards a hand-on workshop, but I'll just try to make it into a short talk about what Anspill is. How many of you here are already using Anspill? So usually you have like 10 or 15 people who raise their hands. So Anspill is one of those tools which makes configuration and deployment within the same tool. Earlier on you had configuration tools like CFMG, Profit, Chef, and all that. And then, again, deployment, you have different kinds of deployment tools like Capstone or Fabricade. And some people usually have their own in-house built deployment tools also. So what Anspill has brought together is its own DSL domain-specific language to make both configuration and deployment within the same tool. And this one reduces the overhead because you don't have to learn another tool for deployment tools. And Anspill is very, so it saw one of the few pain points of most developers and operation guys saying that, before it used to be like the developers used to also say like, hey, it's working on my mission. Why isn't it working over there? Right now, the scenario is not that much different. It's more like, it's working on my container why it's not working there. But this is the scenario before and even now. All we are doing is finding better ways to package software and better ways to deploy and deliver software. So Anspill is one of those simple tools which, if you take a look at it, there are about 3 million open source projects combined, GitHub, SourceForge, and all of that. Only 20,000 of these make it to upstream distributions to Katerina or to Fedora. And only like five or 6,000 of these packages make it into a supported Linux distribution like Red Hat or Ubuntu LTS. So one of the things which I would like you guys to think is, why do these? There are lots of open source software. Like every day, somebody in some development will be dubbed a page and putting out their school hacks. What really works in the infrastructure space and with open source is the most stable of these softwares are the ones which, stable and the most simplest of these softwares make a huge impact than our softwares with more advanced features. So Anspill is a very simple intern of dependencies. Like how many of you had to deploy an application like a Ruby application or a Python application where the developer's source code is only like 15,000 lines of code or 10,000 lines of code? But the dependencies of that thing are like 200, 250 packages which come from PIP and Ruby gems. This is the thing, when people write software for infrastructure like Anspill, the dependencies, the only dependencies, I mean, you don't really need to have Anspill installed on your target missions. All you need is Python and OpenSSH. How cool is that? So these are one of the things which made Anspill very famous and stateless. And you just need Python 2.x, 2.7 for the most stable ones, Python 2.x and OpenSSH. Since most of the computers use TCP as one of the forms speaking to each other and OpenSSH is installed in most of the computers, these are the things which were kept in mind with the designers of these things. And these are few of the things which I wanted to cover. But yes, I'll do it in my web tutorials there. What was not covered in this tutorial was topics like Anspill, Trouble, Vault, and Role. These are advanced Anspill topics. So this is one of the things. If you are trying to deploy systems, how many of you use BASH for deployment? Not many, right? Set for CF Engine or Puppet? Quite a few. So deployment and configurations has been evolving over a period of time. So there has been a saying that we have been able to send Linux to the Mars on the rover for that. But we have not been able to solve the packaging problems. So one other thing is there's no perfect packaging solution and deployment solution. We will always evolve to better solutions over a period of time. This given part of that, Anspill was written by a person who was Michael Rihan. Rihan acquired it, it's supported by Rihan. And also the open source version is still available and the licenses have not been changed as such. And you can launch. It is primarily an automation tool. Even if you're just a developer, you can start using Anspill to get your infrastructure to a desired state. What do you mean a desired status? You expect something in your system to be at one certain state. The data we should be there for these number of applications. And these applications should always be running on these machines. So Anspill is one of the tools which automates most of your infrastructure and deployments. And yeah, let's say agentless, as I said, it uses a push model for sending what you need to work, how your infrastructure should be, how much data it should be. Let's talk about monitoring. As in the tasks are executed one by one and you can also group these tasks together. It uses YAML, a few of the configuration management tools use JSON. YAML is also a simple representation form. So basically you have the basic architecture also very simple. You have the control node and your managed nodes. Control node is where you need to install your Anspill and where your playbooks, where something on a place would be installed from which you can get your infrastructure to a desired state. The only thing which you need under control node is Fighter 207 and then you can install Anspill. Most of the distributions, most of the popular Linux distributions only ship Anspill with them. Fedora does centers. You need to enable one repository known as the EPL repository. Windows also has a PBA where you can just do, after you install the repository, just do the app, you have to install the Anspill and the Anspill installs of the system. Managed nodes, just need Fighter 207 and open it. So you need something known as an inventory file. Just show what inventory file you look like in this machine. So let me explain what an inventory file would look like. It's like, say, on your machine or on your infrastructure, you have like 10 hosts. Say, four are your web services and four are your database services. All you have to do is you need to provide the IP addresses of the FQDn of these nodes on an inventory file and save it. You can save it as anything, hosts or web server.yaml This is how an Anspill playbook looks like. And your file can look like. So this is how your inventory file would look like. You can say, these three machines are my Red Hat machines. This is my Fedora machine. That's my Windows machine. And within the Nux, we have different flavors of Linux. You can just mention that these are the Nux. Or you can, if you want to say, send a command, ping all to all the systems in this network or a group of computers. So you can specify tasks as ad hoc to only these particular machines or you can provision and deploy for all the machines which are available in the network. These are how few of the inventory files would look like. So you can define the range of servers also, saying that, okay, these X number of servers need to be provisioned with this particular kind of workload. So you can use the range functions and also, it's like your Python range. And you can also get particular tasks to particular computers also. So most of you, if you're from the developer add-on, you can see one of the formats as YAML formats. It's pretty popular on the Python developers. So Ansible will, the parser will recognize the YAML file. All the YAML files have three dashes on the top and three dots on the bottom. And this is basically like your, you're logically defining certain groups. You can think of it like a dictionary also. For example, the name is Phubar Drop System Administrator Spill Rai. And then it is very strict about its indentation. So you have the two-space indentation and the four-space indentation if you want to group. For example, you want to say, I want to run Nginx at one level, and at the same level, you want to say, I want these options to harden Nginx with SNLX. So you can mention it in particular groups, but you want a configuration in a particular way. So this is how a list in a YAML will look like. So, and this is basically, it's like a Python list. Here it's basically denoted by the dashes with the proper indentation. And all the dictionary will look something like this, where you have a key and a value, key and a value. For example, this one comes, this YAML file conveys both your list and your dictionaries with the key value and also the list below that. This is, you can use, you can group your system to see your servers together as a form of dictionary or as a list. And you have Boolean values. So you want to install in these, you want to find certain software that's already running and you don't have to install it again. You can check for those things before, or if you want to see these group of servers somewhere like or somewhere not like, then it's one of the ways which you can group into. And you can also use the pipe and the grid and symbol for line spanning and also chaining your commands. If for example, you want to see, you want to get the idea of the user and also you want to see what groups the user is, part of the system, then you can use the pipe command. So these are a few of the, so I don't think so, as soon as it's installed in the system, but what I can say is there are three main concepts in Ansible, one is a host system, next is a playbook, and then you have the repository of modules and plugins which install. So one of the tools is Ansible doc. If you have Ansible installed, you can also install this tool known as Ansible doc. And most of the cloud providers, AWS is the most supported one for the cloud providers, and you want to see what AWS operations you can use. You just give a command ansible-doc and that module name, it will show what are the operations that you can do. And the community around models is very popular and very strong. All your favorite databases, your MariaDB, MySQL, Post-Praise, all of the developers and the community members have put their modules. If there is a operation which you have to do on a particular database, it is already there in the Ansible module. It's most probably there in the Ansible module. All you have to see is how you have to consume that operation. If you just do Ansible doc, say like AWS or Post-Praise, it gives that what the operation is and how you can consume that operation. So playbooks are one of the ways you can get your system or infrastructure in a design state. So all these plays are written in a young format and these plays can consist of lists of tasks and you can also group these tasks to check, modify, or all this other thing. And one thing about Ansible is its identity. Identity doesn't, for example, you have 10 servers and in these 10 servers you have to group, you have to install engineering on all these 10 servers. And three of these servers doesn't have ACLinux, okay? So what happens is Ansible would run on all these servers and then error out with this message saying that in these three servers, ACLinux was not installed. Then what happens is you can actually program it in a YAML, I mean you can write a task in YAML saying that install engineering from these three servers and then again you rerun these things. The first seven systems, it would not rerun again because it's already done. And the next systems, it'll install and it'll give an output saying that yes, it has been successfully installed. So in a playbook you can contain more than one play and these are a few attributes of a playbook. I can show you a playbook. This is how a playbook would look like. So basically if you take a look into this, this is like, you can mention host is control. It is going to look at all the machines which you have given in your inventory file. Your inventory is basically all your VMs, your hardware, your containers, it can be anything. It's IP address or you're FD doing. So in this thing it is saying that on all these machines you install engineering package and you can specify a version. Or you can say it is, get the latest package from that repository. Right now in Ansible 2.3 and 2.4 it has been abstracted in a way that you don't really have to tell Ansible that this is the Ubuntu machine or this is a Fedora machine or CentOS. It is going to figure out which operating system is running and then install the dependencies too. Like you might have in a case where you have paid subscriptions for few hardware and then you want to run in an open source version, unsupported versions on different set of hardware. You can provision it that way also. And you can mention where it needs to be installed for a particular thing and what the package name is. And each of these tasks are placed saying that you install this package, you create this directory and then you update the configuration file. Now here the ones which you see in your site name this variable is in a variable. Okay, this one is a Jinja variable. We'll come to Jinja a bit later. It's a temporary thing. For example, say you have 10 system switch area web server facing through a load balancer. Then you can mention the range of that thing and site name will automatically get it and put it over here and then install in each of these nodes. And you can also mention like how it needs to be run. So this is what I mentioned by design strategy of installing the system. Not only installing, you're telling engineers to restart it and again get these names, put it restart each service and then give me an output and mention the state. So you're kind of automating the whole process where before you try to bash them saying that install this, then exit out. Install this, then exit out, and then here you can mention it for group of computers together. No matter you do have five computers or even 10,000 computers, it's the same. As long as you can get your host names and you can get the whole, I mean, if you get all the IP address into the inventory file, you can provision thousands of computers together in a single command. So, and another one is, yeah, privilege escalation attributes. Privilege escalation attributes would mean, so for example, you can log in as a user and then become Sulu and or then get root access to a, so you can mention these things in a playbook saying that once you become a root user, then start getting all of these privileges. One thing to note that all the configuration is based on our Ansible.cfg file. You either put it in your project repository where you want to, your controller node or your project, where you want to trigger these applications from. It'll either look for your project-based configuration in Ansible.cfg script or if you take a look into slash edc ansible.cfg for a whole system-wide preference. Then you have task attributes. Again, you need to mention that in a YAML format and these are tasks. You can tell first task, second task, third task, you know. And then it goes from top down in the order. For example, you can say enable HTTP D and enable root. For example, you can tell install the package HTTP and then the first task is start the service, HTTP and make it root. And then you can say the second task, third task, like that. You can view multiple tasks. So even these are few tasks. You can group these tasks also together. The level of indentation would define the priority of the task, even within a given task. And also there is a tool from Ansible. You can also check the syntax of what is right and what is wrong in a YAML script. Sometimes the most common errors which people face while getting used to Ansible is the indentation in YAML. Since it's idempotent, it doesn't really hurt a lot over here. The other concept is the variables. You can set the variables. It's like most programming language. You have a scope of a variable which is local and then global. Even here I can mention certain variables for a task which needs to be done across clusters for a group of computers or within a same computer with a specific, say you have your performance tuning some of your software and you need particular version of kernel to be there. You can mention what version of kernel with maybe even with a patch to be on particular systems and then you can group them as variables saying that these are for this performance testing and these are with all the patch for checking the same workload on a different machine with similar migrations. The same thing, variables with the same name that will take a precedence of have you given it in the commanding or have you given it in the playbook or inventory. But usually people use a playbook of course because ad hoc commands are okay for doing certain tasks saying that hey, just ping for the system and get me a particular variable or see the time scale. But playbooks are the way most of people need to start deploying, are the only way to deploy large scale systems. Say you have more than computers which can't manage. Say you have like 700 computers or something. So this is how we can use variables. You can start a var's block and then you can define the variables and then you can keep all of this in a users.yaml file and every time you call a user, you take it in this format as your var's file, as your var syntax over here. So even for, you can also group your hosts and groups as variables also. Here you have the web servers group and you can say these are the connections and these are defined for these groups that you're engineering, you're stating a variable has these systems, your production environments has these systems and then you can start assigning your users to full. Saying that certain, the developers in your company get access to similar systems but their group will be used to this. So for example, the users, people in your engineering group would just get access to this. People in your DevOps would get access to production machines. So you don't have to change the whole yaml script but you just have to put the right key value pairs over there. So you can either run it like this or you can run the notebooks for a particular system or you can run it for all the systems and you can also get different kinds of notational values sort of. Like for example, then you can also do, you have a debug command and also a registered command. For example, you would like to have a report of how this deployment went. You can use a register option to get the output of what a particular command did or what a particular script did in all your systems or in a group of systems. And also you can use a debug value in your yaml scripts suppose you're deploying to a few systems and then you want to see what is particularly going on in a particular level. Then you have different levels of opacity in which you can get the output. And if you have used the debug symbols, you can also use, once you're giving your command, end of the command you can give opacity hyphen b for one level of opacity, hyphen b for two levels of opacity and hyphen b for three levels of opacity. So the other thing, other variable is something known as facts. For example, you have installed certain group of systems and then you have new to the team or something. You want to gather some facts out of your system. Say you give a range of IPs to see what is exactly running in this system. So you can use the facts variable and then you can get the facts and also you can filter those as key value pairs saying that just get me a fact of which kernel version is running on these X number of systems. And these systems just need to be in your inventory file. You don't really have to, the only thing which you have to make sure that there's Python and OpenSS installed on your group of machines, VMs or their metro machines or containers and you can get all the facts particular to that machine or a service which is running within that machine. And again, like in programming languages, you have the conditioners saying that like for example, in this one, when you say the inventory hosting X number of IDs or X number of FQ events of this particular group is databases, then you can say you can create database and when there's a keyword which you need to look over here when that particular machine is part of the DB group. So you can create a, this is one of the smaller tasks and you can use the same Boolean expressions saying that check for all the systems which has Ansible where the kernel version is 3.10 with this particular one and the inventory hosting is this one. So you can group these things or you can group with the or, when, and so you can check for name in item, group in item, you can follow the, you can group them together and then you can loop over machines. Even these are pretty helpful, you can script out, you can automate most of the tasks which you can think of using these control flows. You can mix loops with conditions and for example, you want to check on how many machines can I install this new software and then I'll say a certain number of machines. You can query saying that is it more than 30 GB, is it more than 20 GB disk space available on these particular machines? You can, on the route over here, that's, I mean, you can do commands with this to figure out what is happening or how it is happening or even if you want to reprovision the systems and deploy your applications, you can just deploy on systems where you have more than 30 GB of disk space on the route. Also, error states, for example, you're trying to install something that's in the, the package is not available. You can choose, is this package necessary for the tasks or you can ignore these errors. Sometimes you get warnings and errors which can fill up your screen. You can choose to ignore a few errors in which, or you can override and then you can install. Like for example, if there is something missing or something is failing, then you can notify, notify or abort that script and again rerun the script by installing the right packages which is all of this would be automated. And like any infrastructure tool, you can log it and you can also find the, most of the unit applications log the standard error or standard out. Even service answerable. But if you, I mean, it doesn't do it by default, but you can, you might want to continue if you want to abstract part for more here and it's been long, it should run way now. You can also use something like the Elf stack, EFK stack or the ELK stack or Prometheus to see how these log on. If you want to index and search your logs. Yeah, as I said, you can run the verbosity levels and you can run these playbooks with that. And you can batch process different systems. For example, like you can say the number of tasks which needs to be run in serial or parallel one after the other or linearly together. Or you can delegate it to a particular host also or you can delegate the tasks with your own to a particular host. Maybe you have a system which is monitoring and also it needs to say, like right now you have the infrastructure changes like Kubernetes or something where it sees a particular application is failing and it responds a new instance of that application since it's failing. You can use similar techniques over here saying that you can have one controller node or another node which keeps on monitoring a few other systems and every time that system is down or not reachable it responds another instance of that. You can automate stuff like that too. This is what I had in the tutorial and what I'll do is I'll send out nodes for installation and I'll also share these slides. There's also a workshop workbook which I have made for this which I'll be sharing and it has the nodes to set up your local environment if you're on a Linux based one or a Mac computer. Windows, you might have to install a VMware. You might have to install a virtual machine on top of your windows and then we can go through the workshop exercises. So that's all I had, any questions? It's a tool which requires at least a half day of a workshop to understand what it's doing or how it is doing. So how does this compare against the general script? Slight differences but configuration and deployment are the same tool. I'm not sure Chef does that. The second thing is I think Chef uses JSON as its input. I'm not really familiar with Chef. I have just CF engine and now I'm using Ansible. One of the popular things about Ansible is the community around it. It's not only the Ansible community. The community is like AWS, OpenStack, Azure. All these people are contributing scripts to Ansible so that it's becoming, it's almost becoming a single de facto tool in the cloud for doing deployments. For example, if you have your own in-house software and you're deploying to a particular set of machines or a group of machines which are both in your data center and also the cloud you can start writing custom modules for yourself and it's very easy to do that in Python. Ansible is written in Python. The modules also can be written in Python and the only learning curve is you need to, most of the disciplines now there is no Python. The only learning curve is something known as the Ginger template engine where you have to define your variables and all. So you can define those. You just have to pick up that small tool. It's not a tool, it's a programming template. So it's a templating engine which you have to pick it up. Rest of all, if you are already using the popular stack like your PostgreSQL, your MySQL, or Cassandra, the real stack or the LAN stack, those modules are already there and it's pretty much that you are not solving anything new. There will be common cases but it takes care of most of the tasks which most of the people are doing, the general tasks which most of the people are doing and even very specific tasks which you can do. And also with cloud providers also it's pretty popular. Not only the big ones like AWS or Azure, it's popular even with GCE and it's also popular in private clouds like you have scripts for Nebula, you have scripts for open stack if you are having your own private infrastructure. So the thing is it's one advantage clearly as is they getting both the configuration and the deployment tool together, it's solving a lot of issues and the thing about getting your cluster to a desired state. So yes. Yeah, we don't have any more time for questions. But there is the end of the subject so you can have your questions over the end of the subject. Yeah. And also one thing the Ansible community is very friendly. There is Hatch Ansible on freedom and also on Slack. They do reply to your queries very fast and it's a growing community and if you have specific tasks in your company or if you want to start contributing the barrier is also very good. What you need to know is Python. Even basic Python, it's not like really advanced Python over there it's just basic concepts of Python can get you contributing to it. Yeah.