 So, I hope that you have enjoyed the lunch and now you are in charge to learn some new things about how can you optimize your WordPress day-to-day tasks by automating them. A few words about me. My name is Ivan and I'm working at SiteGround at the moment. I've been with the company for five years and I pretty much went through most of the technical departments there, from technical support and doing some DevOps and QA tasks. And right now I'm working as an enterprise solutions engineer where we are building, designing and maintaining infrastructures for our biggest clients. I'm sure that you have heard some of them, for example, Yoast SEO or WP Forms or Most Trade Sites. So yeah, and actually in this position I have learned how important it is to automate the tasks that we are completing daily in order to have better time management and save time for more significant tasks. And there is a short summary of what this talk is going to be about. First of all, I'll say a few words about automation in general, then I will introduce you to Ansible and tell you how WordPress can benefit from it. And then I have three videos with practical examples, how Ansible is run, how you can write your configs and so on. So let's start with automation. And by automation I mean the use software to create repeatable instructions that will reduce the human interactions with tidy systems. And this is good because first of all we are saving a lot of time, then we are decreasing the errors that we are making by manually executing commands again and again. And from my experience I can say that automation is very, very useful when it comes to server provisioning, application deployment, configuration management or even continuous delivery. And now to the point, what is Ansible? If I should explain it without going into technical terms, I would say that Ansible is a software that allows us to create tasks and execute them to replace the things that we are doing manually every day. It is really simple but at the same time very powerful software which is agentless and it's only using cache to connect to the remote machines we are working on. And of course you don't need any specific cache skills to have, it is just the software using that type of connection to the remote systems and you don't need to create bus scripts or anything like that. And most of the definitions and the configuration files in Ansible are written in YAMU so it's really easy to read and understand even by inexperienced users and that's what I like the most because it's practically human readable. These are the cases which I think are more often the most common cases when we use Ansible. As I mentioned, provisioning, application deployment, configuration management and continuous delivery. And now some theory about Ansible and its parts. I know that we don't like theory but we need to go through this in order to have the practical examples more understandable at the end. So in order to avoid speaking with technical terms only, I am trying to compare Ansible with something from the real world and that is a car assembly line. So what we have whenever we are making a car is a specific set of instructions that are executed every time we make each model, right? So it's the same with Ansible. Ansible Playbook, which is the main part of the service, is a set of instructions that are executed in a certain way, in a certain order. These instructions, whenever we are in the car factory, we have a lot of machines, right? So each machine there is doing something and that's exactly what modules are in Ansible. There are small programs that are designed to perform small, simple tasks and they are based on parameters that we pass in our configuration files. So there are a list of modules on Ansible sites and there are literally hundreds, but if by chance there is a service you are using and there is no module for that, you can ride your own. And speaking of the machines in the car factory, each of them has completely and specifically defined tasks. For example, there are machines that are forming the metal parts, machines that are putting stuff under the hood, right? So we have the same thing in Ansible. We are defining tasks in YAMU syntax and then these tasks are executed with the help of the modules that I mentioned before that. And all car manufacturers have different models. They have cars with different colors and so on. So in the IT world, whenever we have 10 or 20 systems, we might want to execute the same set of instructions on each of them, but at the same time we want to keep the difference between the systems. We might have some different configuration files or something like that. So that's how Ansible handles the difference between our systems using variables and templates. Handlers are practically small and very simple tasks that are triggered after the execution of another task. So right here in the example, we have defined handler, which is restarting a patch service. And in the next slide, we have a task that is practically replacing the Apache configuration file with a template I'm passing to it. So with that notified line here, and then I'm specifying that I want to trigger the handler that I have specified in the previous slide. So what this block of code will do is it will replace the template with the source I have provided. And after that, the patch service will be restarted to apply the changes. And at the end, we have rows which are pretty much a combination of the parts I've said so far. Rows are a pretty comfortable way to gather groups of tasks, variables, modules, and which are related to one same server services. For example, if I want to install and configure Apache all the way from the beginning to the end, I would have tasks for downloading the package, installing the package, then I need to adjust the v-hosts, then configuration files, and so on. And all of these tasks might be grouped in one single row, which is code with just one line instead of calling each task separately in your playbook. Okay, and now, enough about Ansible only, let's see why I think Ansible is great to use with WordPress. And I know that there are a lot of one-click installers or applications that allow you to manage your WordPress dashboards of different sites, but it's cool to have everything that in one single application or software, which actually is installed on your computer and you don't need to log in anywhere to manage your sites, right? So I would say that Ansible would be very useful whenever we want to have WordPress deployed somewhere, and I'm not talking only about the WordPress core, I'm talking about creating a bundle, for example, with your favorite plugins or teams, which you want to have pre-installed every time you install the WordPress. So as well as environment changes, for example, if you're running WordPress in subfolder, what you usually do, I think, is that you are installing the WordPress with one-click installer or whatever, and then you go and manually adjust the WordPress to work in subfolder, which actually can be automated and you can have everything defined in Ansible and executed automatically without you having to do anything. Another useful example would be managing plugins of a lot of sites. I don't know how much of you here are managing most of five sites or 10 sites, which are on different servers, but it is a good way to have, for example, to install or update a plugin on all of your applications, no matter if they are located on the same or different servers, no matter. Also, Ansible is a very good option if you want to automate your code deployment because it has Git and Subversion modules, and of course, I think that it's very useful whenever it comes to any task that you are executing via SSH, I mean, not only related to WordPress as an application itself, but whenever you need to, let's say, change permissions of files or update your htaccess file or php.ini file, it is basically you can automate everything that you're doing manually in SSH. Can we read the practical examples? First of all, I would like to... Can you see it well? Okay. First of all, I'd like to show my Ansible project folder, which is... I've created it. It's very simple, and I've just created it for this conference to show you what I have in it. First of all, I have a playbooks folder where, obviously, I keep my playbooks that I will show you in the videos after that. Then I have roles that I have written and which will be executed in my playbooks later, and I have this hosts file here, which is actually a very important part of Ansible, and it's called inventory. The inventory file contains the information about your hosts, and you can also specify some variables there. I know that security is very important, as well as you, I'm sure, but this is just an example. Don't mind, for example, I have plain text passwords here or something like that. Just ignore it. I know you need to keep your safe sites and don't do that at home. Right here, these are group names. One group can contain multiple hosts. In my case, I have one host in each group here. Then you have the host name, which can be pretty much everything you want. Ansible port and Ansible hosts are very important variables because they are used by the software to connect via SSH to the server. And then you can add pretty much whatever variables you want in order to suit your roles and your playbooks. Whatever you need. In my case, I have database user name, password, WordPress directory where I will install my WordPress, and then memcached host and memcached port. So the first example is related to it in a deploying application, a WordPress application. And this is my playbook here, which will do that for me. As you can see, I have defined two plays, install WordPress core and install initial plugins, which is a typo, but okay. So in that first play, I'm calling one role, which is called install WordPress core. And then I'm calling three more tasks separately, which are create database and create database users. They are pretty straightforward. So I'm not going to open and review them. And at the end, I have configurable press in just a moment to the main .yml file is a file that is executed every time you are calling a role. I mean, it's executed first by default and every time you are calling a role. So in my main .yml file, I have two tasks. First the feature is ensure WordPress destination is present, which is creating my directory where the WordPress will be hosted. And the second one is actually WPC-LY command, where I'm using it to download the files, the core files of the application. The first task here, you can see that this defined using the file module, which in Ansible is a module, which is create files, directories and in that case, I am specifying that I want to create the WordPress directory variable here, which should be in state directory. It might be state file or state tepsant, which will remove that. And the second task is downloading the file, which is I'm using the command module. The command module is a pretty flexible thing because it's like you're just executing some message command via bash or on the remote server. So what I'm doing here is passing this bash command to all my remote hosts that I'm running Ansible on. And now let's get to the videos. Okay, there you go. Stopping for a second. Just to tell you that Ansible can be used in command line mode, not only defining playbooks and writing YAML code in order to have it executed, but in this example, you can see that I'm using the Ansible binary and passing some parameters, which will actually execute the command I'm specifying in the quotes on all my hosts I have defined in my inventory. And the purpose of what I'm showing you now is to show you that before running the playbook, there is nothing on the servers. You can see that I'm trying to access this folder and it is not existing at the moment. Then I'm going to show that there is no database is created also on the servers. And there we go. And then I am executing the actual command that will start our playbook execution, which has some important parameters here. The Iparameter specified the inventory file that I'm using, which contains the information of the remote hosts. Then I'm specifying here the name of the playbook, and then I'm passing some extra variables that are needed in order to have my roles executed correctly. The first task by default is this thing called gathering facts, which is practically going through your Ansible directory checking the files and getting information about the variables. And then we start with the tasks one by one executed on each host simultaneously. Here I'm going to stop for a second just to show you that there is a slight difference between creating database and creating database users. So first we have change status and then we have OK status. What this means is that Ansible is actually remembering states of the tasks and I have created a database user before running the playbook. So Ansible did not do any action, it just saw that the user is already created and its reporting task is OK because there is nothing more to do there. And then I have configuring and installing WordPress, which is actually WPCI commands, configuring install. And then after that we are going to the second play, which would install the plugin we have specified there, which are four plugins I have picked randomly. And at the end of each play we have that play recap, which is actually a summary of what we have done so far. After that I'm again using the Ansible command in order to show you that after the play there is actually some content on the servers. And the first thing is to show that there is WordPress core files inside the directory we have created. Then using the MySQL command line in order to show you that there are database created and the WordPress core tables are actually there on each host separately. And at the end again running WPCI plugin list command in order to show you that we don't only have the core installations there, but we now have core installations with the plugins we have specified pre-installed there without having to do that manually. So this was the first example as a whole. Of course it's very simple, but you can add so much more there if you want and if you have any customizations that you need to do on your site. The second thing is managing plugins and teams. And as I said, whenever we are managing 20 sites and I'm not sure, but I personally don't know which installation has any specific plugin. So whenever you see that a plugin is outdated and you might want to check if it's need to be updated on your site, Ansible is very good thing to automate that because it can go through all of your applications and update the plugin where it is present. Let me check the next video, there you go. So again I'm using Ansible binary in order to delete the plugin called Booking, only on two of my projects. So I will have this plugin installed on two WordPresses and then I will have it deleted from the rest of the hosts. So waiting for the confirmation message here. Then quick check with the installed option in order to see and confirm that this plugin is not present on these WordPresses, there you go. And now running again the Ansible Playbook command which will start executing the next playbook I have which is called plugins.yml again specifying the inventory file and passing some extra vars so that the role can be executed properly. Getting facts again, there we have this message, the bug message which is doing nothing just displaying some information I wanted to show you because it is a good way to debug whenever your playbook is failing or getting an error or there is an undefined variable, the debug message is a good way to see what value does the variable contains and it's just used to display some information. Then I have checking a plugin function which had something red there so it failed and actually this is another thing, there you go, we have failures on two of our hosts. And the thing is that whenever there is a playbook for example on four hosts and whenever a task fails on one host it is excluded until the rest of the play. So what this playbook does is first to check all of my hosts if the plugin is installed and then if it's installed to update it and since we don't have it on these two hosts they're excluded now from the play and at the end we have here the task for update only on the hosts that actually have the plugin present. And here it is the recap again, this time we have two failed hosts as we understood it and then just a quick check to see that the plugin is actually installed only on two of our hosts, there you go, we have two hosts which have the plugin installed and then we have two which doesn't have it. So moving on to the last example which is actually an example where you are using Git module and what it does is to download, in fact it's copy a repo which contains memcache drop-in then deploy it on our four hosts and then checking if, then replacing the host and the port inside the object cache PHP tool with the variables we want. So again gathering factory files, here we are cloning the repo then we are synchronizing the file to our hosts, fixing some permissions and non-ships and at the end I'm using a replace module which you pass a string to and it is replacing it with another string. So pretty much the result here can be seen, we now have the object cache PHP file and then we have changed the host and the port inside that file on all my four hosts without having to do anything manually. And the last example I don't have any views with because it's very simple and I mean that whenever you need to change HT access or PHP.in your WP config file or a lot of applications Ansible is very good choice in order to do that automated and do not do it manually. So in my opinion combining Ansible and WordPress would save you a lot of time and what's even better is that you don't need to have 50 applications in order to use Ansible. You can start really small with really simple tasks for example a task only for changing permissions and start running on your projects and as your projects grow your Ansible code base will grow gradually with it. That was all, thank you very much for your attention and if you have any questions. Your name please and the question. My name is Shun-Hui. So I'm just going to ask, so you're using the WordPress command line tools for the changes that are really inside WordPress, right? Yeah. So if I'm running my host setup in the Docker and everything will be authorized, what would be the good way, if I don't want to put the WordPress binary, command line binary Well Ansible in my case is just using that binary in order to have the plugins and the application installed. So I presume that you have installed WPCY already. But if you haven't you can do everything, pretty much everything as you do it in SH command line. So in order you can also use Wget or any Linux command in order to download the package on ZIP to extract the package and so on. So it's just more tasks defining and it's a little bit more work. David, how does this work in the team environment? Because it looks like it has the playbook and everything lives on your own computer, right? So how will it work in the team environment? I didn't understand the question. Can you repeat? Okay. So it looks like your playbook and are stored in your local machine. But what if I want to share these workflows with other members of my team? Well, personally in my team we have all of our Ansible configuration in a Git repo. So whenever someone wants to use it, just cloning the repo and reuses the tasks and the roles and everything. So it's pretty much comfortable to have it in a Git repo or on a machine, on a control machine whenever everybody can log in and use it. Any more questions? Maybe the last one. So my question is how would you secure your credentials for the machines that you have written upon? Yeah, I mentioned that this example was not secure at all but it was created only for the purpose of this conference. But for example Ansible has different modules where you can randomly generate a password, record it in a variable and then use this variable without having the password actually displayed anywhere. I think that's all we have. Thanks for sharing. Thank you very much.