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

This article is about how linux uses Ansible to automate system management. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

What is Ansible?

Ansible's website interprets it as "a super simple IT automation engine that automates cloud provisioning, configuration management, application deployment, internal service orchestration, and many other IT requirements." By defining a collection of servers in a centralized location, Ansible can perform the same task on multiple servers.

If you are familiar with Bash's for loop, you will find that the Ansible operation is similar. The difference is that Ansible is the idempotent of curtain, etc. In popular terms, Ansible generally performs the requested action only if it does change. For example, suppose you execute a for loop of Bash to create users for multiple machines, like this:

For server in serverA serverB serverC; do ssh ${server} "useradd myuser"; done

This creates a myuser user on serverA, serverB, and serverC; however, regardless of whether this user exists or not, the useradd command is executed each time the for loop is run. A screen-waiting system will first check whether the user exists and create it only if it does not exist. Of course, this example is simple, but the benefits of tools such as curtains will become more obvious over time.

How does Ansible work?

Ansible converts Ansible playbooks into commands that run through SSH, which has many advantages when managing a UNIX-like environment:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Most UNIX-like machines have SSH turned on by default.

Relying on SSH means that the remote host does not need to have an agent.

In most cases, there is no need to install additional software, Ansible requires version 2.6 or later of Python. Most Linux distributions install this version (or newer version) of Python by default.

Ansible does not need a primary node. It can run on any host that has Ansible installed and can be accessed through SSH.

Although you can run Ansible in cron, by default, Ansible will only run when you explicitly require it.

Configure SSH key authentication

A common way to use Ansible is to configure a password-free SSH key login for ease of management. You can use Ansible Vault to protect sensitive information such as passwords, but this is beyond the scope of this article. Now you only need to generate an SSH key using the following command, as shown in example 1.

[09:44 user] $ssh-keygenGenerating public/private rsa key pair. Enter file in which to save the key (/ home/user/.ssh/id_rsa): Created directory'/ home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again:Your identification has been saved in / home/user/.ssh/id_rsa. Your public key has been saved in / home/user/.ssh/id_rsa.pub . The key fingerprint is:SHA256:TpMyzf4qGqXmx3aqZijVv7vO9zGnVXsh7dPbXAZ+LUQ user@user-fedoraThe key's randomart image is:+--- [RSA 2048]-+ | E | | o. . . | |. + S o +. | |. .o *. . + ooo | |. . + oo o oo+. * | |. .ooo * o. *. * + | |. Oval roomBO.o.o | +-[SHA256]-+ example 1: generate a SSH key

In example 1, press enter directly to accept the default value. Any unprivileged user can generate a SSH key and can also install it into the authorized_keys file of any user's SSH on a remote system. After generating the key, you also need to copy it to the remote host and run the following command:

Ssh-copy-id root@servera

Note: running Ansible itself does not require root permissions; however, if you are using non-root users, you need to configure appropriate sudo permissions for the tasks you want to perform.

Enter the root password of servera and this command will install your SSH key to the remote host. After the SSH key is installed, you no longer need to enter the root password to log in to the remote host through SSH.

Install Ansible

You only need to install Ansible on the host where the SSH key was generated in example 1. If you are using Fedora, enter the following command:

Sudo dnf install ansible-y

If you are running CentOS, you need to configure additional packages for the EPEL repository:

Sudo yum install epel-release-y

Then use yum to install Ansible:

Sudo yum install ansible-y

For Ubuntu-based systems, you can install Ansible from PPA:

Sudo apt-get install software-properties-common-ysudo apt-add-repository ppa:ansible/ansiblesudo apt-get updatesudo apt-get install ansible-y

If you are using macOS, it is recommended to install it through Python PIP:

Sudo pip install ansible

For other distributions, see the Ansible installation documentation.

Ansible Inventory

Ansible uses an INI-style file to track the server to be managed, which is called inventory Inventory. By default, this file is located in / etc/ansible/hosts. In this article, I use the Ansible inventory shown in example 2 to operate on the required hosts (tailored for brevity):

[arch] nextcloudprometheusdesktop1desktop2vm-host15 [fedora] netflix [centos] conanconfluence7-repovm-server1gitlab [ubuntu] trusty-mirrornwnkids-tvmedia-centrenas [satellite] satellite [ocp] lb00ocp_dnsmaster01app01infra01 example 2: Ansible host file

Each group is identified by brackets and a group name (like this [group1]) and is any group name applied to a set of servers. A server can exist in multiple groups without any problems. In this case, I have grouping by operating system (arch, ubuntu, centos, fedora) and grouping by server function (ocp, satellite). Ansible host files can handle much more complex situations than this. For more information, please refer to the inventory document.

Run command

After copying your SSH key to all the servers in the inventory, you can start using Ansible. One of the basic functions of Ansible is to run specific commands. The syntax is:

Ansible-a "some command"

For example, suppose you want to upgrade all CentOS servers, you can run:

Ansible centos-a 'yum update-y' Note: grouping is not necessary according to the server operating system. As I'll mention below, Ansible Facts can be used to collect this information; however, if you use Facts, it becomes complicated to run specific commands, so if you are managing heterogeneous environments, for convenience, I recommend creating groups based on the operating system.

This traverses all the servers in the centos group and installs all updates. A more useful command should be Ansible's ping module, which can be used to verify that the server is ready to accept commands:

Ansible all-m ping

This will cause Ansible to try to log in to all the servers in the inventory through SSH. You can see some of the output of the ping command in example 3.

Nwn | SUCCESS = > {"changed": false, "ping": "pong"} media-centre | SUCCESS = > {"changed": false, "ping": "pong"} nas | SUCCESS = > {"changed": false, "ping": "pong"} kids-tv | SUCCESS = > {"changed": false, "ping": "pong"}. Example 3: Ansible ping command output

The ability to run specified commands helps with fast tasks, but what if I want to be able to run the same tasks in the future in the same way? That's what Ansible playbooks is for.

Complex tasks using Ansible playbooks

The Ansible screenplay playbook is a file in YAML format that contains Ansible instructions. I'm not going to talk about more advanced content like Roles and Templates here. If you are interested, please read the Ansible documentation.

In the previous chapter, I recommended that you use the ssh-copy-id command to pass your SSH key; however, this article focuses on how to accomplish the task in a consistent and repeatable manner. Example 4 demonstrates an implementation that ensures correctness even if the SSH key already exists on the target host.

-hosts:all gather_facts:false vars: ssh_key:'/root/playbooks/files/laptop_ssh_key' tasks:-name:copy sshkey authorized_key: key: "{{lookup ('file',ssh_key)}}" user:root sample 4:Ansible script "pushsshkeys.yaml"

-hosts: the line indicates that this script should be executed on which host group. In this example, it checks all the hosts in the inventory.

Gather_facts: the line indicates whether Ansible searches for the details of each host. I will do a more detailed examination later. Now to save time, let's set gather_facts to false.

Vars: part, as the name implies, is used to define the variables used in the script. This short script in example 4 is not really necessary, but by convention we have set a variable.

* * this part marked by tasks: is the place where the main instruction is stored. Each task has a-name:. Ansbile displays this name when running the script.

Authorized_key: is the name of the Ansible module used in the script. You can query information about the Ansible module by using the command ansible-doc-a; however, it may be more convenient to view the documentation through a web browser. The authorized_key module has many good examples to refer to. To run the script in example 4, simply run the ansible-playbook command:

Ansible-playbook push_ssh_keys.yaml

If you add the SSH key for * times, SSH will prompt you to enter the password of the root user.

Now that the SSH key has been transferred to the server, it's time to do something interesting.

Use Ansible to collect information

Ansible can collect all kinds of information about the target system. If you have a large number of hosts, it can be particularly time-consuming. In my experience, each host takes about 1 to 2 seconds or more; however, sometimes it is good to collect information. Consider the following scenario, which prohibits root users from logging in to the system remotely through a password:

-hosts:all gather_facts:true vars: tasks:-name:Enabling ssh-key only root access lineinfile: dest:/etc/ssh/sshd_config regexp:' ^ PermitRootLogin' line:'PermitRootLogin without-password' notify:-restart_sshd-restart_ssh handlers:-name:restart_sshd service: name:sshd state:restarted enabled : true when:ansible_distribution = 'RedHat'-name:restart_ssh service: name:ssh state:restarted enabled:true when:ansible_distribution = =' Debian' example 5: lock SSH access to root

In example 5, the modification of the sshd_config file is conditional and will only be performed if a matching distribution is found. In this case, Red Hat-based distributions and Debian-based distributions have different names for SSH services, which is why conditional statements are used. Although there are other ways to achieve the same effect, this example is a good demonstration of the role of Ansible information. If you want to see all the information collected by Ansible by default, you can run the setup module locally:

Ansible localhost-m setup | less

All the information collected by Ansible can be used to make judgments, as demonstrated in the vars: section of example 4. The difference is that the Ansible information is treated as a built-in variable and does not need to be defined by the system administrator.

Thank you for reading! This is the end of this article on "how linux uses Ansible to automate system management". 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, you can share it out 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.