 to this first meetup of the DevOps workshops. The purpose of starting this, my name is Gaurav Shah. And I come from India. I was actually here for some of my training assignments. And with that, I thought of doing something and start sharing knowledge. And part of that, I also do some meetups in India. And I thought of starting something here. And you guys are actually the founding members of our meetup here. So congratulations, everyone, on that. And the purpose and the idea of this meetup is to not only just go and listen to people talking about some technology, but rather take something out of this. So at the end of every session that we do here, you should achieve something and take home a new knowledge on at least a new technology or a new tool or something out of that. And today, we start with a very interesting tool called Ansible. So how many of you are already aware of Ansible? You are, OK? So are you guys using it already? No? Trying it out? OK, so that's going to accelerate your journey to try things out. And I'm going to also share some material with you, which will help you with your learning from here onwards. And we're going to begin. So the purpose of this today's session is to give you a very brief overview of what Ansible is. And get you started with the learning Ansible, set up an environment. We're going to use a cloud-based environment here. But later on, you can do it on your own as well. It might take you about an hour to set it up. So instead of wasting time doing the setup, I'm going to give you a ready-made setup. And then you can try this out on your own. And once we're done with the introduction, we are also going to start writing some playbooks. So Ansible allows you to write your infrastructure as a code using a concept called as playbooks. And we're going to get you started with the playbooks. So at the end of this session, you should have a cluster of four nodes and one Ansible controller setup. And then you should have written one simple playbook to configure a very simple application. That's the idea. And coming back to my introduction, my name is Gaurav Shah. I've been part of Ops and DevOps teams for the last more than a decade, actually. I've had IT operations from a previous company, after which I went on to start my own consulting firm by name Init Kron. I have my office out of Bangalore, India. Apart from that, I do a lot of corporate training. So I've delivered about close to 180 trainings now. I have trained about 2,000 professionals. I do a lot of trainings mainly focused on the DevOps automation space. I train on tools such as Ansible, Docker, Puppet, Chef. I talk about CI CD, DevOps in general. I just delivered a tech talk in Visa today on DevOps. And apart from that, I've also authored a book on Ansible. It goes by the name Ansible Playbook Essentials. It was published in August of last year by Packet Publications from London, from UK. And that's about me. And with that, we are going to get started with Ansible. So how many of you know about the concept of writing infrastructure as a code, or are familiar with some other similar tools, such as Chef, or Puppet, or Solstack, or even CFND? You are? OK. Can someone tell me about what you mean by writing infrastructure as a code, and how is it different than, let's say, scripting approach towards automation or doing things manually? Maybe we can start on that note. So what do you mean by writing infrastructure as a code, and how is it different than the scripts, for example? Instances, or the servers using code. That's right. Now, what is the advantage of doing that? So you are actually writing the state of your infrastructure or defining the state of your infrastructure using code. Now, once you do that, what is the advantage that you achieve? Over, let's say, scripts. What's that? Reproducible. Reproducible, consistent, recreatible, environments, absolutely. Yes? What else? Delivery. Continuous delivery is sort of a concept, and infrastructure as a code is a small part of it, yes. But if we talk about, let's say, scripting versus infrastructure as a code, sure. Continuous delivery is part of it, but it's not direct comparison with the scripts in general. It can be versioned. It can be versioned. Exactly. That's a big thing. Actually, ability to revision control that code is a big thing, because that's what allows you to recreate it as many times as you want. And you can also take that and share it with others. And you can collaborate with your colleagues. And I mean, you don't generally do that with scripts. So with scripts, well, everybody writes their own code. Everybody is like an independent warrior. And everybody has their own favorite scripting language. And the most important difference between scripts and, let's say, infrastructure as a code is this. Scaling up, absolutely, yes. And the fundamental difference that I would see between scripts and, let's say, infrastructure as a code is basically with scripts, what you do is take a procedural approach towards automation. And you focus on how to do something, and you basically write a procedure to get that thing done. With infrastructure as a code, you move away from that imperative approach and start using a declarative approach towards it. And if you want to take an analogy, let's say you want to build a house. Now, when you want to build a house, you hire a contractor who gets some construction workers, and they're the ones who are going to build it brick by brick for you. They're the ones who are going to focus on the approach, how to do something. They're going to build it brick by brick for you. On the other hand, you hire an architect. Now, what does architect do, if I may ask you? Design. Designs or creates a blueprint or creates a design for your building. And if you look at the approach that he takes or he or she takes, basically the way it works is the architect thinks about the end state of your building or the desired state of your building, breaks it down into components, and then he or she writes a specification for it, stitches it together, and then creates a blueprint. And that's the specification of the state that is given to the contractor. And they look at the state and then build it up to the specification. And that's exactly what we start doing with infrastructure as a core tools. We think about the end state of our IT infrastructure. It could be application, it could be databases, it could be our services, and we break it down into components. Components can be a package, a service, a file, a network device, a user, a group. And then we start writing specification for each of that. And that's how it looks like. So that's the analogy that I'm talking about here. And that specification would simply look like this. So let's say I want to create a user. Instead of defining how to create a user, the procedure to do that or commands to do that, we just start defining what we want, right? And that's the desired state. Let's say I want a user with a name X, Y, Z, with a shell, with a UID, with some group, with some password, right? I don't care about how it is achieved. And that's exactly where the tools come in. So the tools like Ansible or Chef or Puppet, because I mean, they're similar kind of tool. They take the similar approach. So they allow you to write abstracted specification like this, and they take care of all the state management and the procedure. So there are procedures, there are scripts underlying. In case of Ansible, it's the Python code, typically it is. In case of Chef and Puppet, there's gonna be Ruby code, which does the state management, and that takes away all the complexity of managing the desired state from us, right? And we just focus on what we want, the desired state for it, and we're done with that. And that simplifies the way we manage it. And this allows us to define or write the state of our infrastructure as a code. And once you write it as a code, you can start using all the best practices that developers have been following for years, such as test-driven development. You can revision control the code. Once you revision control the code, you can start creating the same state across your environments. It could be development, it could be staging, it could be production. And you can use better editing and refactoring tools, right? And you can do pair programming, code reviews and stuff like that, right? Now that's an important concept and that's what Ansible allows us to do essentially, right? Now there are some other features such as separating code and data, and there's idempotence, and there are a lot of other concepts which are quite interesting. But since we don't have a lot of time, we're gonna skip that part, but I'm gonna share this presentation with you, and you can go through it independently and have a look at what Ansible is really all about, right? Now, with that brief introduction, what we're gonna do is we're gonna start setting up the environment, and the environment is gonna be the cloud-based, and that's an interesting open source project that we have started from my company. And what we do is, if you have to set up an environment, right? One of the roadblocks of getting started with most of the DevOps tools is the complexity of setting up the environment itself, right? Before you get started with Ansible, you need to set up at least like two or three machines. One of that will act as a control node, you need to have a couple of manage nodes, because you are writing infrastructure as a code, you need to simulate the infrastructure, and to simulate the infrastructure, you need some virtual environment, right? And that may take some time. So what we have done is we have leveraged, you see a lot of, how many of you know tools like Cloud9 and the cloud-based ID environments? Are there any other tools that you are aware of? So Cloud9, for example, recently acquired by AWS, what it allows you to do is, gives you an editor on the cloud, and then it gives you a terminal as well. So we've taken a similar editor, open source editor, and we've extended it to make it work for DevOps. So we have an environment which I'm gonna show you here, which contains the ID, and then there are four nodes which come with that. All of this works out of one single box, and that will help you get started with tools like Ansible within minutes, and this is all Docker-based. So the nodes that you connect to, let's say I have four nodes here, and I can connect to node one right here. This is node two, node three, and node four, right? And you also get an ID, so you can start writing the code here and start executing it right there in the terminals there, right? And that gives you the complete environment. You don't have to install different ID, different editor. You don't have to set up the nodes. And this is all Docker-based, and I'm gonna give you an access to it right now, but you can set it up on your own by visiting, let's say, code spaces.io. And you can go to the GitHub page. If you have Docker installed, you can actually get started in few minutes. And we have code spaces for not only Ansible, but also for Chef, Puppet, Docker, and you can get started with that pretty quickly. Now, I'm gonna give you an access to one environment, and what I want you to do is... Okay, where's my hip chart? Are you all connected to the internet? You need to do that first. Okay, so if you browse it, I'm connecting with this. This is the one-to-one connection. So, this is the three-to-two connection. Do you want to... Yeah. Do you send something that you want to do? Do you use the node or all? Yes, I'm gonna do that. Yeah, so what I want you to do is connect to this. Go to this URL. It's shtpshipchat.com, and that is case-sensitive. The last bit. G, I, M, U is caps, A, Z, or Z. That's in caps. Q, A, and I are in caps. So, go to that URL. Yes. It should just let you log in by providing a name, providing your name. It should not ask you to sign up, sign in, nothing. It should just let you log in with your name. If you get something else, you probably have typed it wrong. Sure. It's right here. Everybody has a link? I'll actually write it down here. It's shtpshipchat.com. All right, so I've shared a spreadsheet with you. So what you should start doing is just pick one IP and write down your name after that. Maybe we can do it in series. So this side takes the E series, A series. So there are a couple of series there. Yeah. So there is an A series. Let's not create some conflicts. Yeah. You guys can just decide how you want to do that. Don't take the B series right now. Don't take the B series because this is not working. I'm going to give you new IPs. So take either A or C. Yeah. Just write down your name or something. You can, in fact, write down your email so that I can later on share the links with you guys along with some material that I have. Yeah. So there is a C series if you scroll down and I'm going to add the D series. And what you do with that IP is go to SEDP IP address colon 8000. Go to SEDP IP address colon 8000. All right. So I've added D series as well. So those of you did not have IP, you can take that. Everybody has their own IP? Yes. No. Yes. Okay. Are you able to access your own code space or workspace? Not yet. Not yet? Go to the IP colon 8000. If you have a trouble, let me know. You have the IP? Yeah. And you go to SEDP IP colon 8000. 8000? All right. What's the IP? Which one you picked? Yeah. Which series, which one? Didi, what? CC, what? What is the, what is in your column B? Seventh. You have this one? Yeah. 124, huh? Yeah. It does work. The office network. That's right. Yeah. Don't, don't connect to VPNs or stuff. This kind of VPN works too. You want me to write the same code? Yes. It would be better because it works in this network. And what we have here, once you log in, you can just provide your email or just any name there. That's fine. Once you log in, you'll get a workspace right here. You have an, you see an editor on the right-hand side. And if you click on the terminal, you have the terminal open there. Now, what you can do also is there are four nodes. It's based on Docker. So there are four Docker nodes. You can connect to it. But right now, there is a bug there. So if you connect to one, that's fine. But if you connect to the other one, the first goes away. Okay. First goes away. So there is a known bug. It's a very new product that we've launched last couple of weeks ago. So you can help us fix the bugs. So it's open source product. It's there on GitHub actually. Workspace is empty right now. I'm going to give you the URL to check out the repository. So I have a repository for you, which I'm going to share the URL for. This is code spaces. All right. So if you're on hipchat, I'm going to share this link with you. What you need to do is check out this repository. How do you check out the repositories? Go to the repository and clone the repository there. And this is the repository that you're going to use. So clone the Ansible Tutorials repository. How do you do that is let me pick one unused. You don't have to do that. We're just going to use it, try something out, and then we'll do this. You don't have to commit nothing. So when you connect to this workspace, this is empty. And that's when you go to the repository, you say clone remote repository. Use that link that I shared with you. And that is your workspace. So the introductory presentation that I shared with you, I'm going to share a link for that. And the next one that I'm going to use right now is right there. So Ansible allows you to do multiple things in one. So if you look at the configuration management space, you have Chef and Puppet, which are quite popular. However, Chef and Puppet are purely or mostly configuration management tools. In addition to Chef and Puppet, what you would end up using is, let's say for provisioning infrastructure on cloud. You typically would use cloud formation. You'd use Terraform. You might use OpenStack Heat. But Ansible does that too. So it lets you provision because it has a pretty nice interface to call those APIs. That's another thing that it does. The third thing that it could also do is ad hoc server management. With Chef and Puppet, it's centralized configuration management and centralized configuration management alone. You cannot just run some ad hoc commands in parallel. If you want to do that, you need certain tools which allow you to do that in parallel. So you have parallel SH, CSSH, and tools like that. So you would end up using a mix of tools for provisioning of infrastructure, for configuration management, for ad hoc server management, also for application deployment. For application deployment, you have tools such as Capistrano or CodeDeploy, which lets you do the deployment, rolling updates. Now Ansible supports those features too, and it is agentless system. Chef and Puppet are agent-based systems, whereas you have to have an agent running on each system which is managed, whereas Ansible relies on the battle-hardened SSH. So you don't have to have an agent. It just works over SSH, and that's another advantage with Ansible. Now with the approach that Chef and Puppet takes, it's a pull approach versus Ansible is a push approach with SSH. There are advantages and disadvantages with both approaches. Ansible is a simpler version. Ansible works well with fewer number of systems. When you are doing things at scale, I would still recommend using Chef or Puppet because that works really well with the scale. Let's say we're talking about tens of thousands of servers, and that scale Ansible will obviously slow down, and we have few clients who use, let's say, 5,000 nodes, and then they're facing issues with Ansible because it's the push approach, and it typically slows down after some point of time. But if you need something very simple, if you have homogeneous systems, if you have less number of systems, or if you want to have control over the orchestration or the sequencing, you definitely would consider Ansible instead of those tools. Alright, so the pizza is here. We're going to take a break, and we'll take like 15-20 minutes break and then come back and then do that. Let's eat it while it's hot. And we're connected to our own workspaces, and you should also have the Ansible repository checked out there, and we're going to use that and talk about some inventories, and we're going to talk about the playbooks, and we'll write a very simple playbook using the language that Ansible gives us, that is YAML. How many of you are familiar with YAML? Why YAML? Okay, so at least half of you, that's great. YAML, Ansible chose YAML because the design principles of Ansible are based on the simplicity. YAML is a very simple language which is human readable, as well as it is machine readable. So a lot of YAML gets converted to JSON, and that's what Ansible reads and executes in the background, but when you write the code, if you really look at the Ansible code, it's very easy to understand. It is self-documentable as well, so you don't have to write a documentation to make understand the Ansible code that you've written. It is self-sufficient of sorts. What we have here are four nodes, and you should open a terminal there, and this is our control node. So we have a control node. I'm just going to draw it here, or I might have it in the slides, so let's refer to that. Can we connect to the instance? Yes, one second. Yeah. So we have four nodes. Was there a question? Yeah, I'm not going to connect to the instance. Instance? Okay. Just pick another one. Make sure you're connected to the Internet first. Right? You have the Internet connectivity. Do you have a proxy? I mean, the instance is available on the cloud, and I don't believe there is a proxy or anything here. As long as you are able to browse something else, you should be able to do that. If not, just go to the spreadsheet, pick up IP which has not been assigned, and then use that with port 8000. Okay? So the terminal, once you open that, you get to get an access to the control node. And from there, we're going to have four nodes which are managed. Right? And we're going to connect to those and start managing those and write a playbook. And we're going to execute that playbook on one of the nodes later on. You can try that on a few other nodes or try writing your own playbook as well. Right? Now, in order for control node to be able to connect to the managed nodes, it needs to have an inventory. And how do you generate an inventory? Either you write your own inventory statically. That's the static way of doing it. It's just the machine names, the host names. How do you connect to those? The connection details. If you are using passwords or keys or any of that, you provide it there. We don't have to do much because this comes with passwordless SSH setup. Right? And so we'll use SSH as we mentioned. So either you have to provide the connection details or you have to set up a passwordless SSH that we have here. And inventory looks like this. It's the list of servers to manage, categorized by the groups. And you can also create group of groups. So in this case, we have, let's say, application servers. So there's a group called app. There's a group called DB. And then we have, let's say, you have a data center and you have a location. You can say that I have these servers part of location BLR or location SG or whatever it is. Along with the inventories, the host names. You can also have groups. You can define connection parameters. Connection parameters are how do you connect, which port SSH is running on, on that host. Do I need a username? Do I need a password? Do I need a key? All of that. And along with that, you can also define some variables inside your inventory. So those are called as inventory variables. Now we are not going to touch base on the variables. So we're going to skip that part. But the idea is you can have variables as part of your inventories too, along with the connection information and everything else. And connection information options are these generally. The Ansible host, the port to connect to, the username to use, and the password if you have one. And there could be two types of inventories. The one we are defining here is the static inventory because we are defining it statically. You can also have a dynamic inventory, especially when you're using clouds. So when you're using cloud, you can fetch the information from the cloud and then that can dynamically be generated. So you can write a script to do that, which generally, I mean there are scripts or there are inventory files or let's say there are Python scripts. Ansible return is Python. So you will find a lot of inventory scripts available. Let's say for EC2, for Digital Ocean, for Azure, for OpenStack and so on. Now we already have an inventory. What I'm going to do is I'm just going to take you through that inventory. So this code has setup. So what you do is browse or expand setup. Go to code. We're going to go to chapter five right here. And if you go to chapter five, you'll see two files. One is an inventory. Second is a configuration file. Now you can create a local configuration, which is what we have done. Or the default configuration for Ansible goes in etcansible.cfg. That's the default configuration. And you can overwrite those from your local directory. And that's what we have done. So this is a local inventory and this is a local configuration file. And we have the node names that we are using are slightly different. So the node names, if you look at it, we have node 1 to 4. So I can do ping node 1, 2, 3, 4. So what I want you to do is change this. So load balancer. Instead of LB, app 1, app 2, DB, I'll just give you the node names. LB becomes node 1, maybe. You can choose any, basically. We have four nodes, app 1, app 2, DB. This becomes node 1, 2, node 3, node 4. Let's just update the inventory accordingly. So instead of LB, I'm going to use node 1, node 2, node 3, node 4. That's it. Why are we doing this is because our inventory, our host names are different than the ones which were there. And when you go here, we are on the control node. You go to the same directory. So you're already in the workspace. The workspace directory there, when you open a terminal, you're already in the workspace. Yes. Zoom. Zoom. All right. Is that better? Yeah. OK. Yeah. Yeah. You should have told me earlier. Yeah. So don't wait. You need to change the prod colon. Which one? No. Prod colon children is a group of groups. So this indicates these groups. We're not changing those. So when I call, let's say prod, it's, I mean, you can define, you can say that, OK, I want to connect to just the prod machines, just the application servers, just the database servers. And that's why we have those groups. And then you have a top level group, which encompasses all of those. And once you have made the changes, save it. And we're going to connect and check whether it all works or not. By going to the terminal, you should be in the same directory that the inventory file is in. So that's CD setup code chapter five. Just verify that you're in the same directory. Why? Because we have the configuration here. There's a local configuration which points to the inventory. If not, you'll have to define where the inventory is and then use that as well. You're right here. And we're going to ping our nodes, validate the connectivity. And how do we do that is we use a utility called Ansible. So Ansible comes with a few utilities. Those are, if you just type in Ansible and tab, you have all of these Ansible, Ansible doc, playbook, vault, pull, Galaxy console. We're going to use just Ansible utility. And then we're going to define which hosts we want to connect to from the inventory, which group. And you can use also wildcards or some keywords like all. All will take all the hosts in the inventory or you can define. I want to connect to just the TB, just production servers, just load balancer, just app, either of that. And all will also take the local host too. So we're going to say Ansible all hyphen m ping. This will ping all the host and it will return pong. So if it says pong, that's fine. That's we're all set. So we are connected and we have four nodes which we can start managing and start running playbooks on. Behind the scene is just doing a ping. Ping is it's going to connect to the nodes and validate that everything works fine. It's just a smoke test of sorts. This will validate your connectivity as well. So SSH, whether SSH works or not. And since we have a password list as such, it just worked fine. If you don't have a password list, you'll have to set up the passwords or the keys or the connection information that you have for your nodes. You app that's prod current children. So if you just call prod, it's going to call all those nodes. So you can instead of all, where do you use that? Where do you use that? The groups is here. So I can say I want to just connect to my prod nodes. Have an imping. Children is group of groups. If you want to create a group of groups, so you have applications, databases, load balances. Now I'm going to say, okay, some of these are part of my Singapore data center. So I'm going to go to say Singapore children and then app DB and whatever. And then I might have multiple data centers. So you can group them as per your requirement. It looks for Ansible config. Where does it look for Ansible config? It's going to look at current directory. If it does not find it, it's going to go and look. There are multiple ways to traverse, right? And the default is the ATC host, ATC Ansible Ansible.cfg. And then comes, let's say there are environment variables, then there are a few other locations. There's a home directory Ansible.cfg. And then on top of everything is a local one, local path. And what we have in local path is this, this is my inventory and which user I want to connect as. So it's actually connecting as DevOps user and not as Ubuntu or root. It's using a DevOps user. Right. So we are ready to manage those nodes and we're going to talk about playbooks very quickly. So we are connected that we have validated the connection. There is a procedure to set up a password. All of that is part of the slides. So do have a look at the slides later. Now next is about playbooks. Yeah, I'm sharing the presentation for the playbooks. That's case sensitive. There is a right now. No, how it's supposed to connect to the other nodes. How it connects to other nodes depends on your inventory. Yeah, you can use Ansible user. We can use any other user too. Doesn't matter because you're going to connect using SSH. What user you use really won't matter that much, but it's recommended to use Ansible or non-root user. And no, which user you connect as is defined in Ansible.conf. Yeah. So remote user is what I've defined, and that is what is going to be important. Right. So that's the most important part. Now you can use Ansible to do. Yes. Where do we define number of nodes? Yes. Right now, the environment that we've given you has four nodes, and that's pretty static right now. But when you create your own environment, you may have any number of nodes, and you can define that in the inventory. And the tool that we're using, the code spaces, we're going to add the ability to define how many nodes you want. And when you have that ability, you can define that in the inventory. Yeah, inventory. So right now it's a pretty restricted environment, and since it has four nodes, we have defined just four. Now we can use Ansible to do ad hoc server management, or we can start writing the infrastructure as a code using a concept of playbooks. And playbooks are the ones which allow us to write that infrastructure as a code, and later on you can refactor this playbooks and also start creating reusable block of codes called as roles. So if you're familiar with Chef Cookbooks, or if you're familiar with puppet modules, the similar concept that Ansible is roles. So you create roles for every single application, such as Pache, or Nginx, or Java, or Maven, or Tomcat, or your own deployment. And that's how you typically do it. But we're not going to look at the roles. We're going to restrict ourselves just to the playbooks right now. And playbooks allow us to write a very basic infrastructure as a code specification and using a YAML language. And that's when YAML starts coming into play. And this is how the playbooks look like. And playbooks are the mapping between what configuration gets applied to which nodes. So you can define an orchestration pieces here saying that, okay, if you have application deployment, you may want to stop the applications or load balancer, then update, let's say, database schema, then go and do something on the web servers, then come back and start load balancers. All of that orchestration gets written in the playbook. And this is where you define the plates. So play for a database, play for an application server, then you again run something on all the hosts. And that's how it looks like. So there's one play which has host and the task mapping. Later on, the tasks will be replaced with the roles. But right now, we're just going to write the hosts and tasks. That's how we're going to write it. The tasks use modules. And what we mean by modules is one of the features of Ansible is comes with the batteries included. Now, what is the batteries included approach? It comes with almost everything that you would need built in. Let's say you want to connect to AWS, you have modules for do that. You want to provision databases on MySQL, you have module to do that. You want to say, let's say, integrate with Slack, you have a built-in module to do that. Ansible comes with more than 450 modules. And that's one of the interesting features of Ansible if you compare it with less than Chef and Puppet because Chef and Puppet, you have to rely on a plugin or external extra resources or what you call as LWRP and stuff like that. So you write custom resources with Chef and Puppet, but with Ansible, almost everything comes built in. And that's another advantage with Ansible. And those features or those plugins are the modules. So modules allow you to define or talk to or to manage each of these entities. What kind of entities? It could be your system entities, it could be your network entities, it could be network interfaces, network devices, clouds, all of that gets managed through the modules there. And how do modules look like? If you go to docs.ansible.com, these are the categories of modules, actually. There are about 23 categories. 23 categories and each one has a lot of different modules. Let's say a network modules. Yeah, so you have A10, AOS, AVI, basic, big switch, Citrix, a lot of different modules right there. So you can manage almost all sort of networking devices. And even for networking devices, this is a very interesting tool if you compare it with, let's say, other tools because it does not require you to have an agent on any of those devices. There are modules for, let's say, sole control. There are system modules. System modules let you manage most of the system entities such as users and groups and file systems for host names, IP tables, mount points, packages, services. There are database modules which let you directly, let's say, create a database, set up replications, do all sort of things. And how do you use these modules? All these modules go as part of the playbooks. And let's find out, let's look at maybe a package module or a user module, maybe, yeah. So this is how you write how do you want to create a user. And this is all YAML specification. This is just a specification on what you want to create, which entity you want to manage, what state it should have and with what properties. That's what you define. You define what you want, which entity, in what state, with what properties. Let's say I want a user to be present with certain shell, with certain passwords, certain UID, GID, you just define it that way. And that's about the modules here. So I'll share this with you, the documentation because we're going to start writing some playbooks which will contain some of these modules. And each of that playbook contains play and each play defines which hosts from the inventory, the hosts come from the inventory, do what and that what comes from the task. And tasks are going to call the modules, right? And each play has a name, you know, hosts, you can become, become is for, okay, you are non-root, you're connecting, we're going to connect to the host as non-root user. That's DevOps. Now on the system itself, the DevOps user is limited, so it cannot do much. It needs to have a pseudo-privileges. So earlier this used to be called a pseudo, or, you know, pseudo, right? Now it is called as become because it supports not only pseudo, but it supports various similar kind of, you know, privileged mechanisms or privileged escalation utilities, including pseudo, pseudo, there is VI pseudo, and then there are few other utilities on different systems. So they have generalized it and created a become method. You can also define variables. Variables are for creating, you know, dynamic configurations, and then you finally define the tasks. And this is an example of a play. And in this case, we are creating our app server configuration and we're defining which hosts come from the inventory. So we have a group called app in the inventory and that's what we define here. And then we define become user is, let's say admin, or we can just say if you don't leave it blank, it's going to do a root. And if you can also define a become method, if you want to, by default, it's pseudo. So you say become true and that's going to be enough as well. You can define the variables if you want to. And this is the important part, the tasks. Tasks is where you define the state, action, and so on. So you hear me saying, you want to create a user whose name is that, who should be present and with the UID. That's all. Yeah, so it supports all these methods, pfxx, do ads, pbrun, dzdo, ksu, and some other. And this was added with the version 1.9 of Ansible. Right now we're on to 2.x version. And tasks define the state. So there's generally one has to one mapping between the task and the system entity. So you're going to write one task to manage one system entity. And then you're going to call the module to do that. Right? And that's the reason why modules are also created called as task plugins. And this is an example of a playbook where we have two different plays, one for all hosts and second for just the application servers. And later on you take the tasks out and put it in the roles and you create a modular reusable configuration. Right now we just want to focus on the playbooks. So we are already in chapter 5. We have the configuration there. And we're going to write a playbook which will create an admin user, a user called admin, remove a user called dojo. Now this is going to be interesting. So now this user called dojo is not available on the system at all. So what do you think will happen if I write a code to remove that user? I'm just going to say I want this user to be absent on my system. What will happen? Will it throw an error if the user is not there? No. Why? Because it will check that the requested state is equal to the state and system. That's right. And then it will just pass. Exactly. So that's where the id importance comes in, id importance and convergence. So the property of a resource to know what state it is in and based on that it's going to compare. Every time you run Ansible it's going to compare what is my current state? The user is not there. What is the desired state? The desired state is what we define here. Desired state says the user should not be there. In that case, we are at the same state. So we have already achieved the desired state. So it's going to skip that. However, if the user is there, it's going to remove it. Similarly, I mean it does state management very nicely. And this is just to create a user. Let's say we ask it to create a user. User is there with different properties. In that case, instead of adding a user with user add, it's going to use user mod. If the user is there, the properties are same except for the password. It's not going to take user add. It's not going to use user mod. It's going to use PSSWD, password. On a Linux system that we are talking. And then it supports Windows too. So all these state management becomes easier in comparison with shell script. If you are doing this with shell script, you have to write code for every single state that you are in. And based on that, you have to decide, okay, if the user is there, don't add it. Skip. If the user is there with different properties, check for the properties. If the properties are different, based on that you write a command to do that. With Ansible, you just write one single line and that will take care of the state. And that's where idempotence comes in. And that's a very important property of any of these today's configuration management systems, including Chef, puppet, style stack. So we're going to use write a playbook to do all of this. So let's go ahead and write that. So what we do is we go to our editor. So the previous point you mentioned. Yes. It's not there in the Chef and other tools as well. idempotence? Yeah. It is there in Chef and puppet too. Because all of these are desired state management systems. So they take care of that. So that concept is same. It is also called as convergent infrastructure. Every time you run the tool, it converges towards the desired state. So based on what you have and each of that resource, each of this task, each of the module in Ansible is idempotent. Each module is idempotent. And the tool itself follows the convergent architecture, convergent approach. Yeah. So let's write it. So where you write it, we write it in setup chapter five. Right. You can right click and clear new file right here and call it as playbook. Yeah. And this is going to be our first playbook. And what do we write inside is our first playbook. How does it look like? It's going to look like this. So we're going to start with the name hosts become tasks. And this is a YAML document. So you have to be very, very careful with the indentation. Right. Because YAML is very strict with indentation. So let's write this together. So how does a YAML document start? This is a convention. Best practice. So it starts with three, three dashes. And then you have two spaces. And then you start here. So name of the playbook. We're going to have become then hosts tasks. Let's write this first. Name hosts become tasks. The order doesn't matter here. Except it's named. Yeah. Oh, something. Okay. Got it here. Hosts you can just define, let's say app initially become true. Tasks is going to be list. This is going to be a list array. So you go to the next line indent and we're going to write a few tasks. So every task follow the same standard. So there's going to be name. So what we want to do is create a user call admin, remove a user called dojo. Now there are multiple different conventions that YAML follows. I typically use this. So if I want to put it on new lines, you can actually write all of this in one line. But if you want to put in multiple lines, you should use this greater than symbol. So you start with a name. So each task has a name. Each task has a type of task that you're going to use. And that comes from the documentation here. This is similar to this. What do you have here? So you can either write directly like user or you can have a name there and write it. Okay. I have a problem with this create admin user. And then it's going to use a module called user. Since I'm going to write it on multiple lines, we just add greater than arrow. And then start writing the specifications like these. So I'm going to have you write the rest of the specifications, name, UID, shell, home, state. The user has a name, has a UID, shell, home, state. How do you know? You can go and look at the user documentation here. And these are the properties that we are talking about here. It has a UID. It has a group, a home. It can have a password. It can have a shell. If you define a password, it has to be encrypted hash, not plain text. A state. State is very important. And then there is a default state as well. So there is a default. So if you do not define the state, it will take the default, which is present. Let's write the name. UID. What all we have? UID shell, home, state. If you don't define the state, it's going to take present. Home is going to be home and admin. You can omit the quotes. Let's say 5001. Name of the user is admin. Similarly, you're going to write a second resource. Everything should follow the indentation. So you're going to follow that here. Now, since we are writing four resources, I'll just create that structure. If I want to remove a user, the state should change to absent. Yes, it should be key value, this one. And in fact, I need to have the user here. Install a couple of utilities. That's it. And now installation will depend on the type of system that you have. There is a one generic resource called package, which has been created right now. But otherwise, you typically define it based on the system that you're working on. And that's one of the differences between Ansible and ChefPuppet. Chef and Puppet have one generic package resource, which works on all systems. Whereas Ansible depends on the system. So you define either YAM or APT or the PKG add or whatever is specific to that particular system. Now, they have recently added the resource called package as well. But that works on limited systems and it has a prerequisite on some of the utilities, like Python. And how do you find out? Again, package resources are here. So if you go to the documentation and if you search for let's say package resources, packaging modules. It's mainly dependent on the system. You have homebrews and APT, you have PKG5, Red Hat. There's a YAM package, there's Zyfer for openSUSE. We're using the same one. No, I thought we're using the same one. Screws up my game. I think my playbook.yml got overwritten. Okay, take it from here for now. Yeah, so add the packages called tree and NDP. You can also combine, you can create an array and define an array and say with items instead of writing multiple different tasks for different packages. You can club that and iterate over an array as well. But we'll keep it simple and this is applicable for my production servers. I'll just change it to app. And this becomes your playbook. And how do you, everybody's done writing. Still need some time. Now, since it's a YAML, you should always verify the syntax. There's one way to do that. There's a utility as well, but otherwise you can go to yaml lint.com. There are two ways to do that. Either you go to yaml lint.com, copy or code, paste it here and verify. Or there is a utility which comes with Ansible as well called as Ansible Playbook. And the playbook.yaml and then syntax check. This is going to be quite an useful utility. Ansible playbook. Ansible-playbook is what we're going to use when we start executing the playbooks anyways. So if you're done writing this, open a terminal. You should be in the same directory. So set up code chapter 5. This is where I have my playbook.yaml. And I'm going to check for the syntax errors using Ansible playbook.yaml syntax check. And once you validate the syntax, we can run that. If you want to do a dry run, that's also possible. If everything works fine for the first time, you can try breaking the syntax and see how that would look like otherwise. Now, you can do a lot of things with Ansible playbooks. If you want to list the hosts that are part of the playbook, you can use hyphen-lyst-host. You can do a dry run using hyphen-checkmode. Hyphen-checkmode does a dry run. It will not commit the changes. It will just tell you what would happen. List-host tells you which hosts are part of this play-by-play. If you have multiple plays, it will show you all those. For every play, it will show you some hosts. You can also tag-host. Tags are for if you want to run hosts or run playbooks on particular tags alone, you can do that as well selectively. If you use hyphen-check, it will do a dry run. It shows you what would happen. And for the user dojo, if you look at it when you execute it or do a dry run, it will show you that nothing changed. It says OK because it's already in the desired state. Whatever is not in the desired state is going to change. And it will also show you a recap where it will show you how many tasks or how many modules, how many entities changed, how many are OK. If there are failures, it will show that as well. And that's a play recap. And since we are running it on app group, it shows us only two hosts, no 2 and no 3. And once you're ready to commit the changes, you just run that. As will playbook, playbook.yaml. If you run it again, it's a converted infrastructure. So if you run it again, since it has already made changes, since it is already in the desired state, it won't do anything because everything is already in time. All right, so I'll let you finish that exercise. If you have any trouble, let me know. Yeah. We can keep it that way. Yes. So this requires an argument. All right. It's hyphen f. OK, so syntax hyphen check. Oh, OK. It's 1. OK, so there is some problem which you need to fix. It will also tell you where the problem is. May I do the syntax check? Yes. What's your support number? Yeah. YAM is the name of the module. It's talking to YAM. Database disk image is malformed. OK, this might be a completely different error. Forget about node. Does it work on one of the nodes? Yeah, it works on other nodes. Maybe that particular node has some problems. Yeah, yeah, yeah. It looks like that particular one has a problem. All of the nodes are OK. Yeah, so that's fine. That's OK. Everything is OK. Works. Works. Yeah. All right. Yeah, what's the problem? Syntax. It happens to have been in, it tells you, play with that YAML, line number 9, column number 11. Let's have a look at here. Line number 9, column number 11. So must be something before that. No, line number line is UID. Yeah. OK. You have saved this, right? So let's also copy this. We have a user whose name is admin. UID is 5001 and shall this. Oh, that looks OK. Do we have tabs somewhere? No. OK. Come on, let's try now Syntax check again. Yeah, I did. Yeah, I did. So you can go back to terminal and save it. Yes. Is there a key in everything set up for root or nodes? Yes. I'm not able to SSH as root. You can SSH as root. You can SSH as DevOps at the rate node 1. That will work. No, it's the same error, right? Yeah. So there is an error before that line somewhere. Also, I think it's the indentation problem because if you look at this, there's an indentation problem. So just check that. So that's your first playbook actually with Ansible. And that's what we wanted to achieve, right? So write one playbook, get an understanding of, a very basic understanding of what Ansible does and how it works. And where do you go from here is if you are interested in learning Ansible, I can suggest you a few things. One is the repository that I gave you had some tutorials. So the Ansible tutorial repository, I think it has some, yeah. So it has some tutorials here, right here, which you can go through. It also has the code chapter by chapter. So you can go to set up that chapter and try it out. Introduction won't have it because it's in the part of the slide. Setting up learning environment also part of the slides, but I'd also have a management onwards, okay. All right. I'll just check this repository and make sure that it is available. The other resources that I suggest is you can go to this slides.com page and you would have access to or you should have access to the slides that I have for Ansible. It's basically a program. Inside it should be here. Let me just give you one minute. Oh, yeah. I have everything here. Yeah. All my slides are here. So what I suggest you do is go to schoolofdevelops.teachable.com and subscribe to. So if you go to schoolofdevelops.teachable.com, it will take you to this page. And I mean it will actually take you to this page. And you can enroll to the Ansible. Along with that, we have some other courses out there. Right now this Ansible fundamentals is going through updates. So we are updating a lot of video content as well as quizzes. So it will be a cum-full-fledged video-based training, self-paced learning, along with the code spaces that you could use. Code spaces URL is go to codespaces.io. It will take you to the GitHub page. You have to set up Docker. We have Docker. It's a five-minute thing to set up this code space that we see here. And you can try the tutorials out from here. And along with that, we have a few other courses on Chef, Puppet, and Docker. Right now it's all free because we're just updating right now. But if you subscribe now, you'll have access to it continually, even when we make it paid. So that's going to happen pretty soon. So just subscribe to any of those that you want to. If you have any feedbacks, do let us know. And we can sort of improve on top of that. And for code spaces, I've already shared the link with you. I'll do that again. The GitHub page is this one. And what you have to do is you check it out. Go to any of those directories. There is a Docker compose file. And we should have instruction somewhere here. How to set it up? Yeah. So it's very easy to set this up with Docker. And I can actually show you. I can connect to one of the nodes and show it to you. So all we have done is, let's say, copy this. So we've just checked out the code here. And let's say I want to set up code space for Ansible. Just go to the directory and run Docker compose. Up, minus t. Provided that you have Docker installed. Right now it's already up. I can actually tear down and bring it up as well. Yeah. So it would take just that much time to set up this environment. And once you have run this, you could go to that IP address and go to port 8,000. And you should get this interface, basically. And you can get started learning Ansible from there onwards. It should be pretty quick. And you can subscribe to, obviously, the teachable.com. And you have access to the slides and the tutorials that we would have. So that should at least get you started with this tool. And then we have a few other courses, too. And I hope you learned something out of these two hours. It was pretty quick to our session. So we don't talk too much about in-depth sessions, but it was just a brief interview. And in addition to that, whatever else you would like to learn, we would want to continue doing this session. So I'm going to be here again. I'm flying back to India on Friday. But I'll be back on, I think, end of April. So I would like to do another session. And if you're interested in whichever tool you're interested in, please let us know on the Meetup group. We have Shanwath's and Rakuten team. And we could get other sponsors as well for the venue and stuff. And whatever you want to learn, do let us know. We would try to get that done. If you would like to come and talk about something and share your knowledge, we are very welcome. We definitely need you guys to keep this initiative rolling and do contribute, do attend, and please spread the word. Thank you. Maybe we can take a photograph, actually, together.