DOKK Library

Ansible Automation for SysAdmins - A quickstart guide to Ansible

Authors Red Hat Inc.

License CC-BY-SA-4.0


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

         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.
    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


                What is

                                 publishes stories about creating,
                                                         adopting, and sharing open source
                solutions. Visit 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:

                Email us:

                Chat with us in Freenode IRC:

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


              Introduction                                                                                                               5


              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 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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!


                                                                               Red Hat Ansible | CNCF Ambassador | DevOps
                                                                               | Community Moderator |
                                                                               Writes | Partially Disabled USAF
                                                                               Veteran | He/Him

Ansible Automation for SysAdmins                       . CC BY-SA 4.0 .                                                                 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 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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]
ples for installing mysql [2] and installing httpd [3].              [2]
Tips for writing playbooks                                           [4]
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
                                                           , 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
   ing (run with --check-mode flag).                                 success-when-getting-started-ansible.

Ansible Automation for SysAdmins                 . CC BY-SA 4.0 .                                                               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
         - 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 .
. . . . . . . . . . . . . . . . . . . . . . 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
      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
  - name: Ensure latest index.html is present
    template:                                                     Links
      src: templates/index.html.j2                                [1]
      dest: /usr/share/nginx/html/index.html                      [2]
  - name: Ensure nginx service is started and enabled             [3]
    service:                                                      [4]
      name: nginx                                                      nginx-role
      state: started                                              [5]
      enabled: yes                                                     variables.html
  - name: Ensure proper response from localhost can be received   [7]
    uri:                                                               delegation.html#rolling-update-batch-size
      url: "http://localhost:80/"                                 [8]
      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, published under a Creative Commons Attribution Share-
# handlers file for nginx-example                                 Alike 4.0 International License at
  - name: restart-nginx-service                                   patch-systems.

Ansible Automation for SysAdmins                  . CC BY-SA 4.0 .                                                              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 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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/'), 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:     "{{ }}"                                        example, if you want to ignore GPG keys and install all the
    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
    - { 
        user: 'admin1', key: "{{ lookup('file', '/data/test_           You can use loop when installing packages, but they are
 '), state: 'present', comment: 'admin1 key' }   processed individually if you pass a list:

Ansible Automation for SysAdmins                    . CC BY-SA 4.0 .                                               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
            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 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A sysadmin’s guide to Ansible: How to simplify tasks

     region_name: andromeda                                       Links
     image: 923569a-c777-4g52-t3y9-cxvhl86zx345                   [1]
     flavor_ram: 20146                                            [2]
     flavor: big                                                  [3]
     auto_ip: yes                                                       getting_started.html
     volumes: cloudera-namenode                                   [4]
All OpenStack modules start with os, which makes it easier to     [5]
find them. The above configuration uses the osp-server mod-       [6]
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]
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]
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]
   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]
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]
to start from scratch).                                                 module.html
   Here is an example that starts the server and tells the        [12]
modules the name of the instance:                                       system_modules.html
 - name: restart some servers                                           module.html#service-module
   os_server_action:                                              [14]
     action: start                                                      playbooks_intro.html#handlers-running-operations-on-
     cloud: openstack                                                   change
     region_name: andromeda                                       [15]
     server: cloudera-namenode                                          playbooks_best_practices.html#directory-layout
Most OpenStack modules use similar options. Therefore,                  module.html
to rebuild the server, we can use the same options but            [17]
change the action to rebuild and add the image we want                  playbooks_templating.html
it to use:                                                        [18]
 os_server_action:                                                      playbooks_variables.html#variable-examples
   action: rebuild                                                [20]
   image: 923569a-c777-4g52-t3y9-cxvhl86zx345                           configuration/index.html
Doing other things                                                      configuration/index.html
There are modules for a lot of system admin tasks, but what       [22]
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]
you to run any command just like you do on the command
line. Here’s an example using the OpenStack CLI [23]:
 - 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
                                                        , published under a Creative Commons Attribution Share-
hardest task into a simple solution, save you time, and make      Alike 4.0 International License at
your work days shorter and more relaxed.                          tasks-ansible.

Ansible Automation for SysAdmins                . CC BY-SA 4.0 .                                                               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

       14                                                     Ansible Automation for SysAdmins                               . CC BY-SA 4.0 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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/
                                                                      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 .                                                    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://')                                           Links
             assert socket.is_listening                                                           [2]
       def test_mgmt_user_authentication(host):                                                   [4]
             command = """
                          curl --digest -L -D - http://localhost:9990/ \                          [5]
                              management -u ansible:ansible"""                                    [6]
             cmd =                                                              [8]
             assert 'HTTP/1.1 200 OK' in cmd.stdout                                               [10] Phase Test.html
       This example test case for a Wildfly role verifies that OS                                 [12]
       service is enabled, a process is listening in port 8080, and                               [13]
       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,
       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

       16                                                     Ansible Automation for SysAdmins                               . CC BY-SA 4.0 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 .                                                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]
      module that will work just as well:                                      [2]
      - serverless:                                                            [4]
           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.
                                                                               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

      18                                          Ansible Automation for SysAdmins                      . CC BY-SA 4.0 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
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 .                                                 19
4 Ansible playbooks you should try .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

                     app: galaxy                                                                              type: dword
                     service: web                                                                             data: '0x00000000'
                  - 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: "{{ }}"
       # Passing the object definition from a file                                                            data: "{{ }}"
       - name: 
               Create a Deployment by reading the definition from a                                           type: "{{ item.type }}"
                   local file                                                                              with_items: "{{ registry_keys }}"
             state: present                                                                           handlers:
             src: /mynamespace/deployment.yml                                                            - name: reboot windows system
       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
                 - 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

                 #                                - 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 .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Ansible playbooks you should try

roles:                                                              # The names of the samples that should be installed as well.
  -                                                # 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
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]
ing extremely large hybrid and multi-cloud deployments. The       [2]
service mesh with Istio [9] lets you connect, secure, control,          playbooks.html
and observe services instead of developers through a dedi-        [3]
cated infrastructure such as an Envoy sidecar container. The      [4]
following playbook snippets show how to install Istio locally     [5]
on your machine:                                                        speculativeexecution
---                                                                     meltdown-spectre-linux.yml
  Whether the cluster is an Openshift (ocp) or upstream           [8]
  Kubernetes (k8s) cluster                                        [9]
cluster_flavour: ocp                                              [10]

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

                                                                  Adapted from “4 Ansible playbooks you should try” on,
  # A set of add-ons to install, for example kiali
                                                                  published under a Creative Commons Attribution Share-Alike 4.0 International
  addon: []                                                       License at

Ansible Automation for SysAdmins               . CC BY-SA 4.0 .                                                                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 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 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 .
     . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Write for us

Write for Us

     Would you like to write for Our editorial calendar includes upcoming themes,
     community columns, and topic suggestions:
     Learn more about writing for at:
     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
                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 to subscribe.

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