Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to use Ansible to configure automation. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

First of all, because we need to do more than just install the package files, we have to do some re-organization. Now, we have a script called local.yml that contains the following:

-hosts: localhost become: true tasks:-name: Install packages apt: name= {{item}} with_items:-htop-mc-tmux

If we only want to implement a task, then the above configuration is sufficient. As we continue to add content to our configuration, this file will become quite large and messy. * our action play can be divided into separate files according to different types of configurations. To meet this requirement, create something called the Task Manual taskbook, which is similar to the script playbook but more streamlined. Let's create a directory for the task manual in the Git library.

Mkdir tasks

The code in the local.yml script is a good transition to the task manual for installing package files. Let's move this file to the task directory we just created and rename it.

Mv local.yml tasks/packages.yml

Now, we edit the packages.yml file to make it a lot smaller, in fact, we can simplify everything except the independent task itself. Let's edit the packages.yml into the following form:

-name: Install packages apt: name= {{item}} with_items:-htop-mc-tmux

As you can see, it uses the same syntax, but we remove everything that is useless and unnecessary for this task. Now we have a task manual for installing package files. However, we still need a file called local.yml, because we will still look for it when we execute the ansible-pull command. So we will create a new file that contains these contents in the root directory of our library (not in the task directory):

-hosts: localhost become: true pre_tasks:-name: update repositories apt: update_cache=yes changed_when: False tasks:-include: tasks/packages.yml

This new local.yml plays the role of importing the index into our task manual. I've added something to this file that you haven't seen in this series. First, at the beginning of the file, I added pre_tasks, which is used to run a task before all other tasks run. In this case, our command to Ansible is to update the index of our distribution's software library, and the following configuration will perform this task:

Apt: update_cache=yes

The apt module is usually used to install package files, but we can also use it to update the software library index. The purpose of this is to allow each of our actions to work with a * index while Ansible is running. This will ensure that there will be no problems when we install a package using an old index. Because the apt module only works under Debian, Ubuntu and their derivative distributions. If you are running a different distribution, you should use modules specific to your distribution instead of apt. If you need to use a different module, please check the relevant documentation of Ansible.

The following line also needs further explanation:

Changed_when: False

This line in a task prevents Ansible from reporting the result of an action change, even if it itself causes a change in the system. Here, we don't care whether the library index contains new data; it almost always does, because the library is always changing. We don't care about the changes to the apt library, because changing the index is a normal process. If we delete this line, we will see all the changes later in the process report, even if it is just an update to the library. * ignore such changes.

Next is the phase of the general task, where we will import the created task manual. Each time we add another task manual, we add the following line:

Tasks:-include: tasks/packages.yml

If you run the ansible-pull command now, it should be basically the same as in the previous article. The difference is that we have improved the way we organize and can expand it more effectively. To save you from looking in the previous article, the syntax reference for the ansible-pull command is as follows:

Sudo ansible-pull-U https://github.com//ansible.git

If you remember, ansible-pull 's command pulls a Git repository and applies the configuration it contains.

Now that our foundation is in place, we can now extend our Ansible and add functionality. More specifically, we will add configurations to automate the deployment of changes to workstations. To support this requirement, we first need to create a special account to apply our Ansible configuration. This is not necessary, we can still run the Ansible configuration under our own users. But using an isolated user can isolate it into a system process that runs in the background without our participation.

We can create this user in the usual way, but since we are using Ansible, we should try to avoid using manual changes. Instead, we will create a task manual to handle user-created tasks. This task manual will currently create only one user, but you can add additional actions to this task manual to create more users. I'll name this user ansible, and you can name it as you like (make sure you update all places if you make this change). Let's create a task manual called user.yml and write the following code in it:

-name: create ansible user user: name=ansible uid=900

Next, we need to edit the local.yml file and add this new task manual, as shown below:

-hosts: localhost become: true pre_tasks:-name: update repositories apt: update_cache=yes changed_when: False tasks:-include: tasks/users.yml-include: tasks/packages.yml

Now when we run the ansible-pull command, a user named ansible will be created on the system. Notice that I specifically declare the user ID to be 900 for this user through the parameter uid. This is not necessary, but it is recommended to create a UID directly. Because UID below 1000 is not displayed on the login screen, which is great, because we don't need to use an ansibe account to log in to our desktop at all. UID 900is arbitrary; it should be any number below 1000 that is not used. You can use the following command to verify that UID 900 is already in use on the system:

Cat / etc/passwd | grep 900

However, you should have no problem using this UID, because so far I haven't encountered it being used by default in any distribution I use.

We now have an account called ansible, which will be used later in automated configuration. Next, we can create an actual scheduled job to automate the operation. Instead of placing it in the users.yml file we just created, we should separate it into its own file. Create a task manual called cron.yml in the task directory and write the following code in it:

-name: install cron job (ansible-pull) cron: user= "ansible" name= "ansible provision" minute= "* / 10" job= "/ usr/bin/ansible-pull-o-U https://github.com//ansible.git > / dev/null"

The syntax of the cron module hardly needs to be explained. With this action, we create a scheduled job that runs through the user ansible. This job will be executed every 10 minutes, and here are the commands it will execute:

/ usr/bin/ansible-pull-o-U https://github.com//ansible.git > / dev/null

Similarly, we can add additional scheduled jobs that we want all our workstations to deploy to this file. We just need to add additional actions to the new scheduled job. However, it is not enough to add a scheduled task manual, we also need to add it to the local.yml file so that it can be called. Add the following line to the end:

-include: tasks/cron.yml

Now when the ansible-pull command is executed, it will set a new scheduled job with the user ansible every ten minutes. However, running an Ansible job every ten minutes is not a good way, because it consumes a lot of CPU resources. Running every ten minutes is pointless for Ansible unless we have changed something in the Git repository.

However, we have solved this problem. Notice that my command ansible-pill in the scheduled job adds the parameter-o that we have never used before. This parameter tells Ansible that the library will not run until it has changed since the last ansible-pull call. If the library doesn't change anything, it won't do anything. In this way, you will not waste CPU resources for no reason. Of course some CPU resources are used when pulling the repository, but not as much as when the entire configuration is applied again. When ansible-pull is executed, it will traverse all the tasks in the script and task manual, but at least it will not run aimlessly.

Although we have added all the necessary configuration elements to automate ansible-pull, it still doesn't work properly. The ansible-pull command requires the permission of sudo to run, which allows it to execute system-level commands. However, the user ansible we created is not set to execute commands with the privileges of sudo, so execution will fail when a scheduled job is triggered. Usually we can use the command visudo to manually set the user ansible to have this permission. However, we should now operate in the Ansible way, and this will be an opportunity to show you how the copy module works. The copy module allows you to copy a file from the library to any location on the file system. In this case column, we will copy a configuration file from sudo to / etc/sudoers.d/ so that user ansible can perform tasks with administrator privileges.

Open users.yml and add the following action to the end of the file.

-name: copy sudoers_ansible copy: src=files/sudoers_ansible dest=/etc/sudoers.d/ansible owner=root group=root mode=0440

As we can see, the copy module copies a file from our repository to any other location. In the process, we are grabbing a file called sudoers_ansible (we will create it later) and copying it as / etc/sudoers/ansible, and the owner is root.

Next, we need to create the file we are going to copy. Under the root directory of your repository, create a directory called files:

Mkdir files

Then, in the files directory we just created, create a file called sudoers_ansible that contains the following:

Ansible ALL= (ALL) NOPASSWD: ALL

As we are doing, creating a file in the / etc/sudoer.d directory allows us to configure sudo permissions for a particular user. Now we are using sudo to allow the user ansible to have full control without a password prompt. This will allow ansible-pull to run as background tasks without having to run it manually.

Now, you can pull the changes by running ansible-pull again:

Sudo ansible-pull-U https://github.com//ansible.git

From here, ansible-pull 's scheduled job will run every ten minutes in the background to check your warehouse for changes, and if it finds any changes, it will run your script and apply your task manual.

So now we have a complete workable plan. When you set up a new laptop or desktop computer every time, you have to run the ansible-pull command manually, but only for * times. After *, the user ansible will take over the subsequent running tasks in the background. When you want to make changes to your machine, you simply pull your Git repository to make the changes, and then send the changes back to the repository. Then, the next time the scheduled job runs on each machine, it will pull the changed parts and apply them. You only need to make one change now, and all your workstations will change with it. Although this approach is a little unusual, you usually have a list file that contains a list of your machines and the rules to which different machines belong. However, the ansible-pull approach, as described in this article, is a very effective way to manage workstation configuration.

This is the end of this article on "how to use Ansible to configure automation". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.