Ansible Automation For Sysadmins v2

Download as pdf or txt
Download as pdf or txt
You are on page 1of 23

Opensource.

com

Ansible Automation
for SysAdmins

A quickstart guide to Ansible


Open Source Cheat Sheets
Visit our cheat sheets collection for
free downloads, including:

Blender: Discover the most commonly and frequently used


hotkeys and mouse button presses.

Containers: Learn the lingo and get the basics in this quick and
easy containers primer.

Go: Find out about many uses of the go executable and the most
important packages in the Go standard library.

Inkscape: Inkscape is an incredibly powerful


vector graphics program that you can use to draw
scaleable illustrations or edit vector artwork that
other people have created.

Linux Networking: In this downloadable PDF cheat


sheet, get a list of Linux utilities and commands for
managing servers and networks.

Python 3.7: This cheat sheet rounds up a few


built-in pieces to get new Python programmers
started.

Raspberry Pi: See what you need to


boot your Pi, how to install the operating
system, how to enable SSH and connect
to WiFi, how to install software and update
your system, and links for where to get
further help.

SSH: Most people know SSH as a tool for


remote login, which it is, but it can be used
in many other ways.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Opensource.com

About Opensource.com

What is Opensource.com?

Opensource.com publishes stories about creating,


adopting, and sharing open source
solutions. Visit Opensource.com to learn more about how the open source
way is improving technologies, education, business, government, health, law,
entertainment, humanitarian efforts, and more.

Submit a story idea: https://opensource.com/story

Email us: [email protected]

Chat with us in Freenode IRC: #opensource.com

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 3


Opensource.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Introduction

Introduction 5

Chapters

Tips for success when getting started with Ansible 6


How to use Ansible to patch systems and install applications 8
A sysadmin’s guide to Ansible: How to simplify tasks 10
Testing Ansible roles with Molecule 14
Using Ansible for deploying serverless applications 17
4 Ansible playbooks you should try 19

Get Involved | Additional Resources

Get involved | Additional Resources 22


Write for Us | Keep in Touch 23

4 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction

Introduction
by Chris Short

A lot of great tools have come and gone


over the years. But none
of them have made an impact as large as the one that Ansible has made in
the IT automation space. From servers to networks to public cloud providers
to serverless to Kubernetes… Ansible has a lot of use cases.
Happy birthday, Ansible! We assembled this book to celebrate Ansible’s
seventh birthday. Whether you recently read the Ansible Getting Started
doc [1] and are just beginning your Ansible journey or have been going at it for
quite some time, this book—much like the Ansible community—offers a little
something for everyone.
We hope to spark your imagination about what you can automate next.
Here’s to seven years of Ansible!

Links
[1] 
https://docs.ansible.com/ansible/latest/user_guide/intro_getting_started.html

Author
Red Hat Ansible | CNCF Ambassador | DevOps
| opensource.com Community Moderator |
Writes devopsish.com | Partially Disabled USAF
Veteran | He/Him

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 5


Tips for success when getting started with Ansible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Tips for success when


getting started with Ansible
by Jose Delarosa

Key information for automating your data center with Ansible.

Ansible is an open source automation tool used to


configure servers, install software, and
perform a wide variety of IT tasks from one central loca-
tion. It is a one-to-many agentless mechanism where all
instructions are run from a control machine that communi-
cates with remote clients over SSH, although other protocols
are also supported.
While targeted for system administrators with privileged
access who routinely perform tasks such as installing
and configuring applications, Ansible can also be used by
non-privileged users. For example, a database administrator
using the mysql login ID could use Ansible to create databas-
es, add users, and define access-level controls. One important feature in Ansible is that a playbook de-
Let’s go over a very simple example where a system ad- scribes a desired state in a computer system, so a playbook
ministrator provisions 100 servers each day and must run can be run multiple times against a server without impact-
a series of Bash commands on each one before handing it ing its state. If a certain task has already been implemented
off to users. (e.g., “user sysman already exists”), then Ansible simply ignores
This is a simple example, but should illustrate how eas- it and moves on.
ily commands can be specified in yaml files and executed
on remote servers. In a heterogeneous environment, con- Definitions
ditional statements can be added so that certain commands • Tasks: A task is the smallest unit of work. It can be an ac-
are only executed in certain servers (e.g., “only execute yum tion like “Install a database,” “Install a web server,” “Create a
commands in systems that are not Ubuntu or Debian”). firewall rule,” or “Copy this configuration file to that server.”

6 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tips for success when getting started with Ansible

• Plays: A play is made up of tasks. For example, the play: • Test as often as you need to without fear of breaking things.
“Prepare a database to be used by a web server” is made Tasks describe a desired state, so if a desired state is al-
up of tasks: 1) Install the database package; 2) Set a pass- ready achieved, it will simply be ignored.
word for the database administrator; 3) Create a database; • Be sure all host names defined in /etc/ansible/hosts
and 4) Set access to the database. are resolvable.
• Playbook: A playbook is made up of plays. A playbook • Because communication to remote hosts is done using
could be: “Prepare my website with a database backend,” SSH, keys have to be accepted by the control machine,
and the plays would be 1) Set up the database server; and so either 1) exchange keys with remote hosts prior to start-
2) Set up the web server. ing; or 2) be ready to type in “Yes” to accept SSH key ex-
• Roles: Roles are used to save and organize playbooks and change requests for each remote host you want to manage.
allow sharing and reuse of playbooks. Following the previ- • Although you can combine tasks for different Linux distribu-
ous examples, if you need to fully configure a web server, tions in one playbook, it’s cleaner to write a separate play-
you can use a role that others have written and shared to book for each distro.
do just that. Since roles are highly configurable (if written
correctly), they can be easily reused to suit any given de- In the final analysis
ployment requirements. Ansible is a great choice for implementing automation in
• Ansible Galaxy: Ansible Galaxy [1] is an online repository your data center:
where roles are uploaded so they can be shared with oth- • It’s agentless, so it is simpler to install than other automa-
ers. It is integrated with GitHub, so roles can be organized tion tools.
into Git repositories and then shared via Ansible Galaxy. • Instructions are in YAML (though JSON is also supported)
These definitions and their relationships are depicted here: so it’s easier than writing shell scripts.

Please note this is just one way to organize the tasks that • It’s open source software, so contribute back to it and make
need to be executed. We could have split up the installation it even better!
of the database and the web server into separate playbooks
and into different roles. Most roles in Ansible Galaxy install Links
and configure individual applications. You can see  exam- [1] https://galaxy.ansible.com/
ples for installing mysql [2] and installing httpd [3]. [2] https://galaxy.ansible.com/bennojoy/mysql/
[3] https://galaxy.ansible.com/xcezx/httpd/
Tips for writing playbooks [4] http://docs.ansible.com/
The best source for learning Ansible is the official documenta-
tion [4] site. And, as usual, online search is your friend. I rec- Author
ommend starting with simple tasks, like installing applications Jose is a Linux engineer at Dell EMC. He spends most days
or creating users. Once you are ready, follow these guidelines: learning new things, keeping stuff from breaking, and keeping
• When testing, use a small subset of servers so that your customers happy.
plays execute faster. If they are successful in one server,
they will be successful in others. Adapted from “Tips for success when getting started with Ansible” on
Opensource.com, published under a Creative Commons Attribution Share-
• Always do a dry run to make sure all commands are work- Alike 4.0 International License at https://opensource.com/article/18/2/tips-
ing (run with --check-mode flag). success-when-getting-started-ansible.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 7


How to use Ansible to patch systems and install applications . . . . . . . . . . . . . . . . . . . . . .

How to use Ansible to


patch systems and
install applications
by Jonathan Lozada De La Matta

Save time doing updates with the Ansible IT automation engine.

Have you ever wondered how to patch your sys-


tems, reboot, and continue working?
If so, you’ll be interested in Ansible [1], a simple configu-
ration management tool that can make some of the hardest
work easy. For example, system administration tasks that
can be complicated, take hours to complete, or have com-
plex requirements for security.
In my experience, one of the hardest parts of being a sys-
admin is patching systems. Every time you get a Common
Vulnerabilities and Exposure (CVE) notification or Informa-
tion Assurance Vulnerability Alert (IAVA) mandated by secu-
rity, you have to kick into high gear to close the security gaps.
(And, believe me, your security officer will hunt you down     async: 1
unless the vulnerabilities are patched.)     poll: 0
Ansible can reduce the time it takes to patch systems by
running packaging modules [2]. To demonstrate, let’s use the   - name: wait for 10 seconds
yum module [3] to update the system. Ansible can install, up-     pause:
date, remove, or install from another location (e.g., rpmbuild       seconds: 10
from continuous integration/continuous development). Here
is the task for updating the system:   - name: wait for the system to reboot
    wait_for_connection:
  - name: update the system       connect_timeout: 20
    yum:       sleep: 5
      name: "*"       delay: 5
      state: latest       timeout: 60

In the first line, we give the task a meaningful name so we   - name: install epel-release
know what Ansible is doing. In the next line, the yum module     yum:
updates the CentOS virtual machine (VM), then name: "*"       name: epel-release
tells yum to update everything, and, finally, state: latest       state: latest
updates to the latest RPM.
After updating the system, we need to restart and re- The shell module puts the system to sleep for 5 seconds
connect: then reboots. We use sleep to prevent the connection from
breaking, async to avoid timeout, and poll to fire & forget.
  - name: restart system to reboot to newest kernel We pause for 10 seconds to wait for the VM to come back
    shell: "sleep 5 && reboot" and use wait_for_connection to connect back to the VM

8 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . How to use Ansible to patch systems and install applications

as soon as it can make a connection. Then we install     service:


epel-release to test the RPM installation. You can run this       name: nginx
playbook multiple times to show the idempotent, and the       state: restarted
only task that will show as changed is the reboot since we
are using the shell module. You can use changed_when: In this role, we install the RPMs nginx, python-pip, py-
False to ignore the change when using the shell module if thon-devel, and devel and install uwsgi with PIP. Next, we
you expect no actual changes. use the template module to copy over the nginx.conf and
So far we’ve learned how to update a system, restart the index.html for the page to display. After that, we make sure
VM, reconnect, and install a RPM. Next we will install NGINX the service is enabled on boot and started. Then we use the
using the role in Ansible Lightbulb [4]. uri module to check the connection to the page.
Here is a playbook showing an example of updating, re-
  - name: Ensure nginx packages are present starting, and installing an RPM. Then continue installing nginx.
    yum: This can be done with any other roles/applications you want.
      name: nginx, python-pip, python-devel, devel
      state: present   - hosts: all
    notify: restart-nginx-service     roles:
      - centos-update
  - name: Ensure uwsgi package is present       - nginx-simple
    pip:
      name: uwsgi This was just a simple example of how to update, reboot,
      state: present and continue. For simplicity, I added the packages without
    notify: restart-nginx-service variables [5]. Once you start working with a large number of
hosts, you will need to change a few settings:
  - name: Ensure latest default.conf is present • async & poll [6]
    template: • serial [7]
      src: templates/nginx.conf.j2 • forks [8]
      dest: /etc/nginx/nginx.conf This is because on your production environment you might
      backup: yes want to update one system at a time (not fire & forget) and
    notify: restart-nginx-service actually wait a longer time for your system to reboot and
continue.
  - name: Ensure latest index.html is present
    template: Links
      src: templates/index.html.j2 [1] https://www.ansible.com/overview/how-ansible-works
      dest: /usr/share/nginx/html/index.html [2] https://docs.ansible.com/ansible/latest/list_of_packaging_
modules.html
  - name: Ensure nginx service is started and enabled [3] https://docs.ansible.com/ansible/latest/yum_module.html
    service: [4] https://github.com/ansible/lightbulb/tree/master/examples/
      name: nginx nginx-role
      state: started [5] https://docs.ansible.com/ansible/latest/playbooks_
      enabled: yes variables.html
[6] https://docs.ansible.com/ansible/latest/playbooks_async.html
  - name: Ensure proper response from localhost can be received [7] https://docs.ansible.com/ansible/latest/playbooks_
    uri: delegation.html#rolling-update-batch-size
      url: "http://localhost:80/" [8] https://docs.ansible.com/ansible/latest/intro_configuration.
      return_content: yes html#forks
    register: response
    until: 'nginx_test_message in response.content' Author
    retries: 10 Jlozadad is a Ansible Consultant. I’m from Carolina, Puerto
    delay: 1 Rico and I love IT & Gaming. Spend Most of my time playing
video games, looking at open source software and laughing.
And the handler that restarts the nginx service:
Adapted from “How to use Ansible to patch systems and install applications”
on Opensource.com, published under a Creative Commons Attribution Share-
# handlers file for nginx-example Alike 4.0 International License at https://opensource.com/article/18/3/ansible-
  - name: restart-nginx-service patch-systems.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 9


A sysadmin’s guide to Ansible: How to simplify tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A sysadmin’s guide
to Ansible: How to
simplify tasks
by Jonathan Lozada De La Matta

There are many ways to automate common sysadmin tasks with Ansible. Here are several of them.

Diving deeper into Ansible


In the previous chapter, I discussed
how to use Ansible
to patch systems and install applications. In this chapter, I’ll
Sharing ideas about how to resolve issues is one of the
best things we can do in the IT and open source world, so I
show you how to do other things with Ansible that will make went looking for help by submitting issues in Ansible [1] and
your life as a sysadmin easier. First, though, I want to share asking questions in roles others created [2].
why I came to Ansible. Reading the documentation (including the following top-
I started using Ansible because it made patching systems ics) is the best way to get started learning Ansible.
easier. I could run some ad-hoc commands here and there • Getting started [3]
and some playbooks someone else wrote. I didn’t get very • Best practices [4]
in depth, though, because the playbook I was running used • Ansible Lightbulb [5]
a lot of lineinfile modules, and, to be honest, my regex • Ansible FAQ [6]
techniques were nonexistent. I was also limited in my capac- If you are trying to figure out what you can do with Ansible,
ity due to my management’s direction and instructions: “You take a moment and think about the daily activities you do,
can run this playbook only and that’s all you can do.” the ones that take a lot of time that would be better spent on
After leaving that job, I started working on a team where other things. Here are some examples:
most of the infrastructure was in the cloud. After getting used • Managing accounts in systems: Creating users, adding
to the team and learning how everything works, I started try- them to the correct groups, and adding the SSH keys…
ing to find ways to automate more things. We were spending these are things that used to take me days when we had a
two to three months deploying virtual machines in large num- large number of systems to build. Even using a shell script,
bers—doing all the work manually, including the lifecycle of this process was very time-consuming.
each virtual machine, from provision to decommission. Our • Maintaining lists of required packages: This could be
work often got behind schedule, as we spent a lot of time do- part of your security posture and include the packages re-
ing maintenance. When folks went on vacation, others had to quired for your applications.
take over with little knowledge of the tasks they were doing. • Installing applications: You can use your current docu-
mentation and convert application installs into tasks by
finding the correct module [7] for the job.
• Configuring systems and applications: You might want
to change /etc/ssh/sshd_config for different environments
(e.g., production vs. development) by adding a line or two,
or maybe you want a file to look a specific way in every
system you’re managing.
• Provisioning a VM in the cloud: This is great when you
need to launch a few virtual machines that are similar for
your applications and you are tired of using the UI.
Now let’s look at how to use Ansible to automate some of
these repetitive tasks.

10 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A sysadmin’s guide to Ansible: How to simplify tasks

Managing users     - { 
user: 'dbadmin', key: "{{ lookup('file',
If you need to create a large list of users and groups with '/data/vm_temp_key.pub'), state: 'absent',
the users spread among the different groups, you can use comment: 'dbadmin key' }
loops. Let’s start by creating the groups:
Here, we specify the user, how to find the key by using
- name: create user groups lookup, the state, and a comment describing the purpose
  group: of the key.
    name: "{{ item }}"
  loop: Installing packages
    - postgresql Package installation can vary depending on the packaging
    - nginx-test system you are using. You can use Ansible facts [8] to de-
    - admin termine which module to use. Ansible does offer a generic
    - dbadmin module called package [9] that uses ansible_pkg_mgr and
    - hadoop calls the proper package manager for the system. For exam-
ple, if you’re using Fedora, the package module will call the
You can create users with specific parameters like this: DNF package manager.
The package module will work if you’re doing a simple in-
- name: all users in the department stallation of packages. If you’re doing more complex work,
  user: you will have to use the correct module for your system. For
    name:  "{{ item.name }}" example, if you want to ignore GPG keys and install all the
    group: "{{ item.group }}" security packages on a RHEL-based system, you need to
    groups: "{{ item.groups }}" use the yum module. You will have different options depend-
    uid: "{{ item.uid }}" ing on your packaging module [10], but they usually offer
    state: "{{ item.state }}" more parameters than Ansible’s generic package module.
  loop: Here is an example using the package module:
    - {
name: 'admin1', group: 'admin', groups: 'nginx', uid:
'1234', state: 'present' }   - name: install a package
    - {
name: 'dbadmin1', group: 'dbadmin', groups: 'postgres',     package:
uid: '4321', state: 'present' }       name: nginx
    - { 
name: 'user1', group: 'hadoop', groups: 'wheel', uid:       state: installed
'1067', state: 'present' }
    - { 
name: 'jose', group: 'admin', groups: 'wheel', uid: The following uses the yum module to install NGINX, disable
'9000', state: 'absent' } gpg_check from the repo, ignore the repository’s certificates,
and skip any broken packages that might show up.
Looking at the user jose, you may recognize that state: 'ab-
sent' deletes this user account, and you may be wondering   - name: install a package
why you need to include all the other parameters when you’re     yum:
just removing him. It’s because this is a good place to keep       name: nginx
documentation of important changes for audits or security       state: installed
compliance. By storing the roles in Git as your source of truth,       disable_gpg_check: yes
you can go back and look at the old versions in Git if you later       validate_certs: no
need to answer questions about why changes were made.       skip_broken: yes
To deploy SSH keys for some of the users, you can use the
same type of looping as in the last example. Here is an example using Apt [11]. The Apt module tells Ansi-
ble to uninstall NGINX and not update the cache:
- name: copy admin1 and dbadmin ssh keys
  authorized_key:   - name: install a package
    user: "{{ item.user }}"     apt:
    key: "{{ item.key }}"       name: nginx
    state: "{{ item.state }}"       state: absent
    comment: "{{ item.comment }}"       update_cache: no
  loop:
    - { 
user: 'admin1', key: "{{ lookup('file', '/data/test_ You can use loop when installing packages, but they are
temp_key.pub'), state: 'present', comment: 'admin1 key' } processed individually if you pass a list:

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 11


A sysadmin’s guide to Ansible: How to simplify tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  - name: This is the task that calls the handler:


      - nginx
      - postgresql-server   - name: configure postgresql
      - ansible     template:
      - httpd       src: postgresql.service.j2
      dest: /usr/lib/systemd/system/postgresql.service
NOTE: Make sure you know the correct name of the pack-     notify: 
reload postgresql for new configuration and reload
age you want in the package manager you’re using. Some daemon
names change depending on the package manager.
It configures PostgreSQL by changing the systemd file, but
Starting services instead of defining the restart in the tasks (like before), it
Much like packages, Ansible has different modules to start calls the handler to do the restart at the end of the run. This is
services [12]. Like in our previous example, where we used a good way to configure your application and keep it idempo-
the package module to do a general installation of packag- tent since the handler only runs when a task changes—not in
es, the service [13] module does similar work with services, the middle of your configuration.
including with systemd and Upstart. (Check the module’s The previous example uses the template module [16] and
documentation for a complete list.) Here is an example: a Jinja2 file [17]. One of the most wonderful things about
configuring applications with Ansible is using templates. You
  - name: start nginx can configure a whole file like postgresql.service with the
    service: full configuration you require. But, instead of changing every
      name: nginx line, you can use variables and define the options some-
      state: started where else. This will let you change any variable at any time
and be more versatile. For example:
You can use Ansible’s service module if you are just starting
and stopping applications and don’t need anything more so- [database]
phisticated. But, like with the yum module, if you need more DB_TYPE  = "{{ gitea_db }}"
options, you will need to use the systemd module. For ex- HOST     = "{{ ansible_fqdn}}:3306"
ample, if you modify systemd files, then you need to do a NAME     = gitea
daemon-reload, the service module won’t work for that; you USER     = gitea
will have to use the systemd module. PASSWD   = "{{ gitea_db_passwd }}"
SSL_MODE = disable
  - name: 
reload postgresql for new configuration and reload daemon PATH     = "{{ gitea_db_dir }}/gitea.db
    systemd:
      name: postgresql This configures the database options on the file app.ini
      state: reload for Gitea [18]. This is similar to writing Ansible tasks, even
      daemon-reload: yes though it is a configuration file, and makes it easy to define
variables and make changes. This can be expanded fur-
This is a great starting point, but it can become cumbersome ther if you are using group_vars [19], which allows you to
because the service will always reload/restart. This a good define variables for all systems and specific groups (e.g.,
place to use a handler [14]. production vs. development). This makes it easier to man-
If you used best practices and created your role using age variables, and you don’t have to specify the same ones
ansible-galaxy init "role name", then you should have in every role.
the full directory structure [15]. You can include the code
above inside the handlers/main.yml and call it when you Provisioning a system
make a change with the application. For example: We’ve gone over several things you can do with Ansible on
your system, but we haven’t yet discussed how to provision
handlers/main.yml a system. Here’s an example of provisioning a virtual ma-
chine (VM) with the OpenStack cloud solution.
  - name: 
reload postgresql for new configuration and reload
daemon   - name: create a VM in openstack
    systemd:     osp_server:
      name: postgresql       name: cloudera-namenode
      state: reload       state: present
      daemon-reload: yes       cloud: openstack

12 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A sysadmin’s guide to Ansible: How to simplify tasks

      region_name: andromeda Links


      image: 923569a-c777-4g52-t3y9-cxvhl86zx345 [1]  https://github.com/ansible/ansible/issues/18006
      flavor_ram: 20146 [2]  https://github.com/abaez/ansible-role-user/issues/1
      flavor: big [3]  http://docs.ansible.com/ansible/latest/user_guide/intro_
      auto_ip: yes getting_started.html
      volumes: cloudera-namenode [4]  http://docs.ansible.com/ansible/latest/user_guide/
playbooks_best_practices.html
All OpenStack modules start with os, which makes it easier to [5]  https://github.com/ansible/lightbulb
find them. The above configuration uses the osp-server mod- [6] https://docs.ansible.com/ansible/latest/reference_
ule, which lets you add or remove an instance. It includes the appendices/faq.html
name of the VM, its state, its cloud options, and how it au- [7]  https://docs.ansible.com/ansible/latest/modules/modules_
thenticates to the API. More information about cloud.yml [20] by_category.html
is available in the OpenStack docs, but if you don’t want to [8] https://docs.ansible.com/ansible/latest/user_guide/
use cloud.yml, you can use a dictionary that lists your creden- playbooks_variables.html#information-discovered-from-
tials using the auth option. If you want to delete the VM, just systems-facts
change state: to absent. [9]  http://docs.ansible.com/ansible/latest/modules/package_
Say you have a list of servers you shut down because module.html
you couldn’t figure out how to get the applications work- [10] http://docs.ansible.com/ansible/latest/modules/list_of_
ing, and you want to start them again. You can use os_ packaging_modules.html
server_action to restart them (or rebuild them if you want [11] https://docs.ansible.com/ansible/latest/modules/apt_
to start from scratch). module.html
Here is an example that starts the server and tells the [12] http://docs.ansible.com/ansible/latest/modules/list_of_
modules the name of the instance: system_modules.html
[13] http://docs.ansible.com/ansible/latest/modules/service_
  - name: restart some servers module.html#service-module
    os_server_action: [14] https://docs.ansible.com/ansible/latest/user_guide/
      action: start playbooks_intro.html#handlers-running-operations-on-
      cloud: openstack change
      region_name: andromeda [15] http://docs.ansible.com/ansible/latest/user_guide/
      server: cloudera-namenode playbooks_best_practices.html#directory-layout
[16] https://docs.ansible.com/ansible/latest/modules/template_
Most OpenStack modules use similar options. Therefore, module.html
to rebuild the server, we can use the same options but [17] https://docs.ansible.com/ansible/latest/user_guide/
change the action to rebuild and add the image we want playbooks_templating.html
it to use: [18] https://gitea.io/en-us/
[19] https://docs.ansible.com/ansible/latest/user_guide/
  os_server_action: playbooks_variables.html#variable-examples
    action: rebuild [20] https://docs.openstack.org/python-openstackclient/pike/
    image: 923569a-c777-4g52-t3y9-cxvhl86zx345 configuration/index.html
[21] https://docs.openstack.org/python-openstackclient/pike/
Doing other things configuration/index.html
There are modules for a lot of system admin tasks, but what [22] https://docs.ansible.com/ansible/latest/modules/
should you do if there isn’t one for what you are trying to do? command_module.html
Use the shell [21] and command [22] modules, which allow [23] https://docs.openstack.org/python-openstackclient/pike/
you to run any command just like you do on the command
line. Here’s an example using the OpenStack CLI [23]:
Author
  - name: run an opencli command Jlozadad is a Ansible Consultant. I’m from Carolina, Puerto
    command: "openstack hypervisor list" Rico and I love IT & Gaming. Spend Most of my time playing
video games, looking at open source software and laughing.
They are so many ways you can do daily sysadmin tasks
with Ansible. Using this automation tool can transform your Adapted from “A sysadmin’s guide to Ansible: How to simplify tasks” on
Opensource.com, published under a Creative Commons Attribution Share-
hardest task into a simple solution, save you time, and make Alike 4.0 International License at https://opensource.com/article/18/7/sysadmin-
your work days shorter and more relaxed. tasks-ansible.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 13


Testing Ansible roles with Molecule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Testing Ansible roles


with Molecule
by Jairo da Silva Junior

Learn how to automate your verifications using Python.

Test techniques play an important


role in software de-
velopment, and this is no different when we are talking about
In the end, your workflow would be:

1. vagrant up
Infrastructure as Code (IaC). 2. Edit playbook.
Developers are always testing, and constant feedback is 3. vagrant provision
necessary to drive development. If it takes too long to get feed- 4. vagrant ssh to verify VM state.
back on a change, your steps might be too large, making errors 5. Repeat steps 2 to 4.
hard to spot. Baby steps and fast feedback are the essence
of TDD (test-driven development). But how do you apply this Occasionally, the VM should be destroyed and brought up
approach to the development of ad hoc playbooks or roles? again (vagrant destroy -f; vagrant up) to increase the
When you’re developing an automation, a typical workflow reliability of your playbook (i.e., to test if your automation is
would start with a new virtual machine. I will use Vagrant [1] working end-to-end).
to illustrate this idea, but you could use libvirt [2], Docker [3], Although this is a good workflow, you’re still doing all the
VirtualBox [4], or VMware [5], an instance in a private or pub- hard work of connecting to the VM and verifying that every-
lic cloud, or a virtual machine provisioned in your data center thing is working as expected.
hypervisor (oVirt [6], Xen [7], or VMware, for example). When tests are not automated, you’ll face issues similar to
When deciding which virtual machine to use, balance feed- those when you do not automate your infrastructure.
back speed and similarity with your real target environment. Luckily, tools like Testinfra [8] and Goss [9] can help auto-
The minimal start point with Vagrant would be: mate these verifications.
vagrant init centos/7 # or any other box I will focus on Testinfra, as it is written in Python and is the
Then add Ansible provisioning to your Vagrantfile: default verifier for Molecule. The idea is pretty simple: Auto-
mate your verifications using Python:
config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml" def test_nginx_is_installed(host):
end     nginx = host.package("nginx")
    assert nginx.is_installed
    assert nginx.version.startswith("1.2")

def test_nginx_running_and_enabled(host):
    nginx = host.service("nginx")
    assert nginx.is_running
    assert nginx.is_enabled

In a development environment, this script would connect to


the target host using SSH (just like Ansible) to perform the
above verifications (package presence/version and service
state):

14 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Testing Ansible roles with Molecule

py.test --connection=ssh --hosts=server your code? Is there a more simple and fast way to develop
our playbooks and roles with automated tests?
In short, during infrastructure automation development, the
challenge is to provision new infrastructure, execute play- Molecule
books against them, and verify that your changes reflect the Molecule [11] helps develop roles using tests. The tool can
state you declared in your playbooks. even initialize a new role with test cases: molecule init
• What can Testinfra verify? role –role-name foo
• Infrastructure is up and running from the user’s point of Molecule is flexible enough to allow you to use different driv-
view (e.g., HTTPD or Nginx is answering requests, and ers for infrastructure provisioning, including Docker, Vagrant,
MariaDB or PostgreSQL is handling SQL queries). OpenStack, GCE, EC2, and Azure. It also allows the use of
• OS service is started and enabled different server verification tools, including Testinfra and Goss.
• A process is listening on a specific port Its commands ease the execution of tasks commonly used
• A process is answering requests during development workflow:
• Configuration files were correctly copied or generated • lint - Executes yaml-lint, ansible-lint, and flake8, re-
from templates porting failure if there are issues
• Virtually anything you do to ensure that your server state • syntax - Verifies the role for syntax errors
is correct • create - Creates an instance with the configured driver
• What safeties do these automated tests provide? • prepare - Configures instances with preparation playbooks
• Perform complex changes or introduce new features with- • converge - Executes playbooks targeting hosts
out breaking existing behavior (e.g., it still works in RHEL- • idempotence - Executes a playbook twice and fails in case
based distributions after adding support for Debian-based of changes in the second run (non-idempotent)
systems). • verify -  Execute server state verification tools (testinfra
• Refactor/improve the codebase when new versions of An- or goss)
sible are released and new best practices are introduced. • destroy - Destroys instances
What we’ve done with Vagrant, Ansible, and Testinfra so far • test - Executes all the previous steps
is easily mapped to the steps described in the Four-Phase The login command can be used to connect to provisioned
Test [10] pattern—a way to structure tests that makes the servers for troubleshooting purposes.
test objective clear. It is composed of the following phases:
Setup, Exercise, Verify, and Teardown: Step by step
How do you go from no tests at all to a decent codebase
• Setup: Prepares the environment for the test execution being executed for every change/commit?
(e.g., spins up new virtual machines):
1. virtualenv (optional)
vagrant up
The virtualenv tool creates isolated environments, while
• Exercise: Effectively executes the code against the system virtualenvwrapper is a collection of extensions that facili-
under test (i.e., Ansible playbook): tate the use of virtualenv.
These tools prevent dependencies and conflicts between
vagrant provision Molecule and other Python packages in your machine.

• Verify: Verifies the previous step output: sudo pip install virtualenvwrapper
export WORKON_HOME=~/envs
py.test (with Testinfra) source /usr/local/bin/virtualenvwrapper.sh
mkvirtualenv mocule
• Teardown: Returns to the state prior to Setup:
2. Molecule
vagrant destroy
Install Molecule with the Docker driver:
The same idea we used for an ad hoc playbook could be
applied to role development and testing, but do you need to pip install molecule ansible docker
do all these steps every time you develop something new?
What if you want to use containers, or an OpenStack, in- Generate a new role with test scenarios:
stead of Vagrant? What if you’d rather use Goss than Testin-
fra? How do you run this continuously for every change in molecule init role -r role_name

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 15


Testing Ansible roles with Molecule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

or for existing roles: CI


Continuously executing your Molecule tests is simple. The
molecule init scenario -r my-role example above works for TravisCI with the Docker driver,
but it could be easily adapted for any CI server and any in-
All the necessary configuration is generated with your role, frastructure drivers supported by Molecule.
and you need only write test cases using Testinfra:
---
import os sudo: required
language: python
import testinfra.utils.ansible_runner services:
 - docker
testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner( before_install:
    os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')  - sudo apt-get -qq update
  - pip install molecule
def test_jboss_running_and_enabled(host):   - pip install docker
    jboss = host.service('wildfly') script:
 - molecule test
    assert jboss.is_enabled
Visit Travis CI [13] for sample output.
def test_jboss_listening_http(host):
    socket = host.socket('tcp://0.0.0.0:8080') Links
[1] https://github.com/hashicorp/vagrant
    assert socket.is_listening [2]  https://libvirt.org/
[3] https://www.docker.com/
def test_mgmt_user_authentication(host): [4]  https://www.virtualbox.org/
    command = """
curl --digest -L -D - http://localhost:9990/ \ [5]  https://www.vmware.com/
management -u ansible:ansible""" [6]  https://ovirt.org/
[7]  https://www.xenproject.org/
    cmd = host.run(command) [8]  https://testinfra.readthedocs.io/en/latest/
[9]  https://github.com/aelsabbahy/goss
    assert 'HTTP/1.1 200 OK' in cmd.stdout [10] http://xunitpatterns.com/Four Phase Test.html
[11]  https://molecule.readthedocs.io/en/latest/
This example test case for a Wildfly role verifies that OS [12] https://testinfra.readthedocs.io/en/latest/
service is enabled, a process is listening in port 8080, and [13] https://travis-ci.org/jairojunior/ansible-role-jboss/
authentication is properly configurated. builds/345731738
Coding these tests is straightforward, and you basi-
cally need to think about an automated way to verify Author
something. Jairo da Silva Junior—Developer, speaker at DevOps con-
You are already writing tests when you log into a machine ferences, open source contributor, occasional writer, and ob-
targeted by your playbook, or when you build verifications for sessed with tests and automation. Can’t live without CLI tools.
your monitoring/alerting systems. This knowledge will con-
Adapted from “Testing Ansible roles with Molecule” on Opensource.com,
tribute to building something with the Testinfra API [12] or published under a Creative Commons Attribution Share-Alike 4.0 International
using a system command. License at https://opensource.com/article/18/12/testing-ansible-roles-molecule.

16 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Ansible for deploying serverless applications

Using Ansible for deploying


serverless applications
by Ryan Scott Brown

Serverless is another step in the direction of managed services and plays nice with Ansible’s
agentless architecture.

Ansible [1] is designed as the simplest deploy-


ment tool that actually works. What that
means is that it’s not a full programming language. You write
Ansible takes the first view. Before “serverless” was a term
of art, users had to manage and provision EC2 instances,
virtual private cloud (VPC) networks, and everything else.
YAML templates that define tasks and list whatever tasks Serverless is another step in the direction of managed ser-
you need to automate your job. vices and plays nice with Ansible’s agentless architecture.
Most people think of Ansible as a souped-up version of Before we go into a Lambda [3] example, let’s look at a
“SSH in a ‘for’ loop,” and that’s true for simple use cases. simpler task for provisioning a CloudFormation stack:
But really Ansible is about tasks, not about SSH. For a lot
of use cases, we connect via SSH but also support things - name: Build network
like Windows Remote Management (WinRM) for Windows   cloudformation:
machines, different protocols for network devices, and the     stack_name: prod-vpc
HTTPS APIs that are the lingua franca of cloud services.     state: present
In a cloud, Ansible can operate on two separate layers:     template: base_vpc.yml
the control plane and the on-instance resources. The con-
trol plane consists of everything not running on the OS. This Writing a task like this takes just a couple minutes, but it
includes setting up networks, spawning instances, provision- brings the last semi-manual step involved in building your
ing higher-level services like Amazon’s S3 or DynamoDB, infrastructure—clicking “Create Stack”—into a playbook with
and everything else you need to keep your cloud infrastruc- everything else. Now your VPC is just another task you can
ture secure and serving customers. call when building up a new region.
On-instance work is what you already know Ansible for: Since cloud providers are the real source of truth when
starting and stopping services, templating config files, it comes to what’s really happening in your account, An-
installing packages, and sible has a number of ways
everything else OS-related to pull that back and use
that you can do over SSH. the IDs, names, and oth-
Now, what about server- er parameters to filter and
less [2]? Depending who you query running instances or
ask, serverless is either the networks. Take for example
ultimate extension of the the cloudformation_facts
continued rush to the public module that we can use to
cloud or a wildly new para- get the subnet IDs, network
digm where everything is an ranges, and other data back
API call, and it’s never been out of the template we just
done before. created.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 17


Using Ansible for deploying serverless applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

- name: Pull all new resources back in as a variable That’s not quite everything you need, since the serverless
  cloudformation_facts: project also must exist, and that’s where you’ll do the heavy
    stack_name: prod-vpc lifting of defining your functions and event sources. For this
  register: network_stack example, we’ll make a single function that responds to HTTP
requests. The Serverless Framework uses YAML as its con-
For serverless applications, you’ll definitely need a com- fig language (as does Ansible), so this should look familiar.
plement of Lambda functions in addition to any other Dy-
namoDB tables, S3 buckets, and whatever else. Fortu- # serverless.yml
nately, by using the lambda modules, Lambda functions service: fakeservice
can be created in the same way as the stack from the
last tasks: provider:
  name: aws
- lambda:   runtime: python3.6
    name: sendReportMail
    zip_file: "{{ deployment_package }}" functions:
    runtime: python3.6   main:
    handler: report.send     handler: test_function.handler
    memory_size: 1024     events:
    role: "{{ iam_exec_role }}"       - http:
  register: new_function           path: /
          method: get
If you have another tool that you prefer for shipping the
serverless parts of your application, that works as well. The Links
open source Serverless Framework [4] has its own Ansible [1] https://www.ansible.com/
module that will work just as well: [2]  https://en.wikipedia.org/wiki/Serverless_computing
[3] https://aws.amazon.com/lambda/
- serverless: [4] https://serverless.com/
    service_path: '{{ project_dir }}'
    stage: dev Author
  register: sls Ryan is a Senior Software Engineer and spends most of
- name: 
Serverless uses CloudFormation under the hood, so you his time on cloud-adjacent Open Source tooling, including
can easily pull info back into Ansible Ansible and the Serverless Framework.
  cloudformation_facts:
Adapted from “Using Ansible for deploying serverless applications” on Opensource.
    stack_name: "{{ sls.service_name }}" com, published under a Creative Commons Attribution Share-Alike 4.0 International
  register: sls_facts License at https://opensource.com/article/17/8/ansible-serverless-applications.

18 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Ansible playbooks you should try

4 Ansible playbooks
you should try
by Daniel Oh

Streamline and tighten automation processes in complex IT environments


with these Ansible playbooks.

In a complex IT environment, even the smallest tasks can


seem to take forever. Sprawling systems are hard to devel-
op, deploy, and maintain. Business demands only increase
complexity, and IT teams struggle with management, avail-
ability, and cost.
How do you address this complexity and while meeting to-
day’s business demands? There is no doubt that Ansible [1]
can improve your current processes, migrate applications for
better optimization, and provide a single language for DevOps
practices across your organization.
More importantly, you can declare configurations through
Ansible playbooks [2], but they orchestrate steps of any man-
ual ordered process, even as different steps must bounce - name: Create a k8s namespace
back and forth between sets of machines in particular orders.   k8s:
They can launch tasks synchronously or asynchronously.     name: mynamespace
While you might run the main /usr/bin/ansible program for     api_version: v1
ad-hoc tasks, playbooks are more likely to be kept in source     kind: Namespace
control and used to push out your configuration or ensure     state: present
the configurations of your remote systems are in spec. Be-
cause the Ansible playbooks are configuration, deployment, - name: Create a Service object from an inline definition
and orchestration language, they can describe a policy you   k8s:
want your remote systems to enforce or a set of steps in a     state: present
general IT process.     definition:
Here are four Ansible playbooks that you should try to fur-       apiVersion: v1
ther customize and configure how your automation works.       kind: Service
      metadata:
Managing Kubernetes objects         name: web
When you perform CRUD operations on Kubernetes [3]         namespace: mynamespace
objects, Ansible playbooks enable you to quickly and eas-         labels:
ily access the full range of Kubernetes APIs through the           app: galaxy
OpenShift Python client. The following playbook snippets           service: web
show you how to create specific Kubernetes namespace       spec:
and service objects:         selector:

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 19


4 Ansible playbooks you should try . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

          app: galaxy         type: dword


          service: web         data: '0x00000000'
        ports:
        - protocol: TCP   tasks:
          targetPort: 8000     - name: Install security updates
          name: port-8000-tcp       win_updates:
          port: 8000         category_names:
          - SecurityUpdates
- name: 
Create a Service object by reading the definition from       notify: reboot windows system
a file
  k8s:     - name: Enable kernel protections
    state: present       win_regedit:
    src: /mynamespace/service.yml         path: "{{ item.path }}"
        name: "{{ item.name }}"
# Passing the object definition from a file         data: "{{ item.data }}"
- name: 
Create a Deployment by reading the definition from a         type: "{{ item.type }}"
local file       with_items: "{{ registry_keys }}"
  k8s:
    state: present   handlers:
    src: /mynamespace/deployment.yml     - name: reboot windows system
      win_reboot:
Mitigate critical security concerns like Meltdown         shutdown_timeout: 3600
and Spectre         reboot_timeout: 3600
In the first week of January 2018, two flaws were announced:       when: reboot_after_update
Meltdown and Spectre [4]. Both involved the hardware at the
heart of more or less every computing device on the planet: You can also find other playbooks for Linux [6].
the processor. There is a great in-depth review of the two
flaws here [5]. While Meltdown and Spectre are not com- Integrating a CI/CD process with Jenkins
pletely mitigated, the following playbook snippets show how Jenkins [7] is a well-known tool for implementing CI/CD. Shell
to easily deploy the patches for Windows: scripts are commonly used for provisioning environments or
to deploy apps during the pipeline flow. Although this could
- name: Patch Windows systems against Meltdown and Spectre work, it is cumbersome to maintain and reuse scripts in the
  hosts: "{{ target_hosts | default('all') }}" long run. The following playbook snippets show how to pro-
vision infrastructure in a Continuous Integration/Continuous
  vars: Delivery (CI/CD) process using a Jenkins Pipeline [8].
    reboot_after_update: no
    registry_keys: ---
      - path: 
HKLM:\SYSTEM\CurrentControlSet\Control\Session - name: Deploy Jenkins CI
Manager\Memory Management hosts: jenkins_server
        name: FeatureSettingsOverride remote_user: vagrant
        data: 0 become: yes
        type: dword
roles:
      - path: 
HKLM:\SYSTEM\CurrentControlSet\Control\Session   - geerlingguy.repo-epel
Manager\Memory Management   - geerlingguy.jenkins
        name: FeatureSettingsOverrideMask   - geerlingguy.git
        data: 3   - tecris.maven
        type: dword   - geerlingguy.ansible

      # https://support.microsoft.com/en-us/help/4072699 - name: Deploy Nexus Server


      - path: 
HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\ hosts: nexus_server
QualityCompat remote_user: vagrant
        name: cadca5fe-87d3-4b96-b7fb-a231484277cc become: yes

20 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Ansible playbooks you should try

roles:   # The names of the samples that should be installed as well.


  - geerlingguy.java   # The available samples are in the istio_simple_samples variable
  - savoirfairelinux.nexus3-oss   # 
In addition to the values in istio_simple_samples,
'bookinfo' can also be specified
- name: Deploy Sonar Server   samples: []
hosts: sonar_server
remote_user: vagrant   # Whether or not to open apps in the browser
become: yes   open_apps: false

roles:   # W
hether to delete resources that might exist from previous
  - wtanaka.unzip Istio installations
  - zanini.sonar   delete_resources: false

- name: On Premises CentOS Conclusion


hosts: app_server You can find full sets of playbooks that illustrate many of
remote_user: vagrant these techniques in the ansible-examples repository [10].
become: yes I recommend looking at these in another tab as you go
along.
roles: Hopefully, these tips and snippets of Ansible playbooks
  - jenkins-keys-config have provided some interesting ways to use and extend your
automation journey.
Starting a service mesh with Istio
With a cloud platform, developers must use microservices Links
to architect for portability. Meanwhile, operators are manag- [1] https://www.ansible.com/
ing extremely large hybrid and multi-cloud deployments. The [2] https://docs.ansible.com/ansible/devel/user_guide/
service mesh with Istio [9] lets you connect, secure, control, playbooks.html
and observe services instead of developers through a dedi- [3] https://kubernetes.io/
cated infrastructure such as an Envoy sidecar container. The [4] https://meltdownattack.com/
following playbook snippets show how to install Istio locally [5] https://access.redhat.com/security/vulnerabilities/
on your machine: speculativeexecution
[6] https://github.com/ansible/ansible-lockdown/blob/master/
--- meltdown-spectre-linux.yml
[7] https://jenkins.io/
# 
Whether the cluster is an Openshift (ocp) or upstream [8] https://jenkins.io/doc/book/pipeline/
Kubernetes (k8s) cluster [9] https://istio.io/
cluster_flavour: ocp [10] https://github.com/ansible/ansible-examples

istio: Author
  # 
Install istio with or without istio-auth module Daniel Oh—DevOps Evangelist, CNCF Ambassador, Devel-
  auth: false oper, Public Speaker, Writer, Opensource.com Author

Adapted from “4 Ansible playbooks you should try” on Opensource.com,


  # A set of add-ons to install, for example kiali
published under a Creative Commons Attribution Share-Alike 4.0 International
  addon: [] License at https://opensource.com/article/18/8/ansible-playbooks-you-should-try.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 21


Get Involved | Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Get Involved

If you find these articles useful, get involved! Your feedback helps improve the status
quo for all things DevOps.
Contribute to the Opensource.com DevOps resource collection, and join the team of
DevOps practitioners and enthusiasts who want to share the open source stories
happening in the world of IT.
The Open Source DevOps team is looking for writers, curators, and others who can help
us explore the intersection of open source and DevOps. We’re especially interested in
stories on the following topics:

• D
 evOps practical how to’s
• D
 evOps and open source
• D
 evOps and talent
• D
 evOps and culture
• D
 evSecOps/rugged software

Learn more about the Opensource.com DevOps team: https://opensource.com/devops-team

Additional Resources

The open source guide to DevOps monitoring tools


This free download for sysadmin observability tools includes analysis of open source
monitoring, log aggregation, alerting/visualizations, and distributed tracing tools.
Download it now: The open source guide to DevOps monitoring tools

The ultimate DevOps hiring guide


This free download provides advice, tactics, and information about the state of DevOps
hiring for both job seekers and hiring managers.
Download it now: The ultimate DevOps hiring guide

The Open Organization Guide to IT Culture Change


In The Open Organization Guide to IT Culture Change, more than 25 contributors from
open communities, companies, and projects offer hard-won lessons and practical ad-
vice on how to create an open IT department that can deliver better, faster results and
unparalleled business value.
Download it now: The Open Organization Guide to IT Culture Change

22 Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Write for us

Write for Us

Would you like to write for Opensource.com? Our editorial calendar includes upcoming themes,
community columns, and topic suggestions: https://opensource.com/calendar
Learn more about writing for Opensource.com at: https://opensource.com/writers
We're always looking for open source-related articles on the following topics:
Big data: Open source big data tools, stories, communities, and news.
Command-line tips: Tricks and tips for the Linux command-line.
Containers and Kubernetes: Getting started with containers, best practices,
security, news, projects, and case studies.
Education: Open source projects, tools, solutions, and resources for educators,
students, and the classroom.
Geek culture: Open source-related geek culture stories.
Hardware: Open source hardware projects, maker culture, new products, howtos,
and tutorials.
Machine learning and AI: Open source tools, programs, projects and howtos for
machine learning and artificial intelligence.
Programming: Share your favorite scripts, tips for getting started, tricks for
developers, tutorials, and tell us about your favorite programming languages and
communities.
Security: Tips and tricks for securing your systems, best practices, checklists,
tutorials and tools, case studies, and security-related project updates.

Keep in touch!
Sign up to receive roundups of our best articles,
giveaway alerts, and community announcements.
Visit opensource.com/email-newsletter to subscribe.

Ansible Automation for SysAdmins . CC BY-SA 4.0 . Opensource.com 23

You might also like