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

This article is about how to use Ansible to manage the configuration of a workstation. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Configuration management is a very important aspect of server management and DevOps. The "infrastructure is code infrastructure as code" approach makes it easy to deploy servers in various configurations and dynamically extend your organization's resources to meet user needs. However, less attention is paid to personal administrators who want to set up their laptops and desktops (workstations) automatically.

In this series, I'll show you how to automate your workstation settings through Ansible, which allows you to easily restore the entire configuration if you want or need to reinstall your machine. In addition, if you have multiple workstations, you can use the same method to do the same configuration on each workstation. In this article, we will set up basic configuration management for personal or work computers and lay the foundation for the rest of this series. By the end of this article, you will have an environment in which to work. Each subsequent article in this series will automate more content and add complexity.

Why use Ansible?

There are many configuration management solutions, including Salt Stack, Chef, and Puppet. I prefer Ansible because it is lighter in terms of resource utilization, the syntax is easier to read, and if used correctly can revolutionize your configuration management. The lightweight nature of Ansible is particularly relevant to this topic because we may not want to run an entire server but just to automate our laptop and desktop settings. Generally we always want to be faster; we can use something to get up and running quickly to synchronize our configuration on the workstations we need to recover or across multiple machines. My specific approach to using Ansible (which I'll demonstrate in this article) works well here without the need to maintain the server. You just need to download the configuration and run it.

My method.

Typically, Ansible runs on a central server. It uses an inventory inventory file, which is a text file that contains a list of all hosts and their IP addresses or domain names that we want Ansible to manage. This is useful for static environments, but not ideal for workstations. The reason is that we really don't know the state of our workstation at some point. Maybe I turned off my desktop, or my laptop might hang up and put it in my bag. In either case, the Ansible server complains because if they are offline, Ansible cannot reach my machine. What we need more is an on-demand approach, and we achieve this goal by using ansible-pull. The ansible-pull command is a command from Ansible that allows you to download the configuration from the Git repository and apply it immediately. You don't need to maintain the server or inventory; just run the ansible-pull command, give it a Git repository URL, and it will do the rest for you.

Start

First, install Ansible on the computer you want to manage. One problem is that many distributions come with older versions of Ansible. Based on experience, you must want to get the * version. New features are often introduced into Ansible, and if you are running an old version, the sample syntax you find online may not work properly because it uses features that are not implemented in the version you installed. Even small versions released have a lot of new features. One example is the dconf module, which is a new feature starting with Ansible 2.4. If you try to use the syntax of this module, you will fail unless you use version 2.4 or later. In Ubuntu and its derivatives, we can easily install the * * version of Ansible using the official personal package Archive (PPA). The following command solves this problem:

Sudo apt-get install software-properties-commonsudo apt-add-repository ppa:ansible/ansiblesudo apt-get updatesudo apt-get install ansible

If you are not using Ubuntu, please refer to Ansible's documentation to learn how to get it for your platform.

Next, we need a Git repository to save our configuration. The easiest way to meet this requirement is to create an empty repository on GitHub, or you can use your own Git server, if any. For simplicity, I assume that you are using GitHub, so if you are using another warehouse, please adjust the command accordingly. Create a warehouse in GitHub; you'll end up with a warehouse URL similar to this:

Git@github.com:/ansible.git

Clone the warehouse to your local working directory (ignore any messages complaining that the warehouse is empty):

Git clone git@github.com:/ansible.git

Now we have an empty warehouse to use. Change your working directory to the repository (such as cd. / ansible) and create a file called local.yml in your favorite text editor. Put the following configuration in this file:

-hosts: localhost become: true tasks:-name: Install htop apt: name=htop

The file you just created is called script playbook, and the instructions to install htop (one of my random packages as an example) is called Action play. The script itself is a file in YAML format, which is an easy-to-read markup language. A complete account of YAML is beyond the scope of this article, but you don't need a professional understanding to be proficient in using Ansible. The configuration is easy to read; just look at this file and you can easily understand the htop package we are installing. Note the apt module on the * * line, which applies only to Debian-based systems. If you use the Red Hat platform, you can change it to yum instead of apt, or if you are using Fedora, change it to dnf. The name line only provides information about our task and will be displayed in the output. Therefore, you need to make sure that the name is descriptive so that it is easy to find when you need to troubleshoot multiple actions.

Next, let's submit the new file to our warehouse:

Git add local.ymlgit commit-m "initial commit" git push origin master

Now our new script should appear in the warehouse on our GitHub. We can apply the script we created using the following command:

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

If executed correctly, the htop package should be installed on your system. You may see some warnings near the beginning complaining about the lack of inventory files. This is good because we don't use inventory files (and we don't need to). At the end of the output, it outlines what it does. If htop is installed correctly, you should see changed = 1 on the * * line of the output.

How does it work? The ansible-pull command uses the-U option, which requires a warehouse URL. For security reasons, I gave it the https version of the repository URL because I didn't want any hosts to have write access to the repository (https is read-only by default). Local.yml is the default script name, so we don't need to provide a file name for the script: if it finds a script named local.yml in the root directory of the repository, it will run it automatically. Next, we use sudo before the command because we are modifying the system.

Let's continue to add more packages to our script. I'll add two packages to make it look like this:

-hosts: localhost become: true tasks:-name: Install htop apt: name=htop-name: Install mc apt: name=mc-name: Install tmux apt: name=tmux

I added more actions (tasks) to install the other two packages, mc and tmux. It doesn't matter which packages you choose to install in this script; I just pick them at random. You should install the software packages that you want all systems to have. The only thing to note is that you must know that the package exists in the software repository before you distribute it.

Before we submit and apply this updated script, we should sort it out. It works well, but (to be honest) it looks a little messy. Let's try to install all three packages in one action. Replace your local.yml content with the following:

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

It looks cleaner and more efficient now. We use with_items to merge our package list into one action. If we want to add another package, we just need to add another line with a hyphen and a package name. Think of with_items as similar to a for loop. Each package we listed will be installed.

Submit our new changes back to the warehouse:

Git add local.ymlgit commit-m "added additional packages, cleaned up formatting" git push origin master

Now we can run our script to accept the new configuration:

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

Admittedly, this example hasn't done much; all it does is install some software packages. You can use the package manager to install these packages faster. However, as this series continues, these examples will become more complex and we will automate more things. * the Ansible configuration you create will automatically perform more and more tasks. For example, the configuration I use myself can automatically install hundreds of software packages, set up cron jobs, handle desktop configurations, and so on.

Judging from what we have achieved so far, you may have a general idea. All we have to do is create a warehouse, place a script in the warehouse, then pull the warehouse using the ansible-pull command and apply it to our machine. We don't need to set up a server. In the future, if we want to change the configuration, we can pull the warehouse, update it, and then push it back to our warehouse and apply it. If we want to set up a new machine, we just need to install Ansible and apply the configuration.

Thank you for reading! This is the end of this article on "how to use Ansible to manage workstation configuration". 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 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.