DEV Community: koh-sh

How to do "if a package is installed, do something" with Ansible

koh-sh — Sun, 14 Jun 2020 14:45:16 +0000

When you create Playbook, sometimes you may want to do these kinds of tasks.

if a package is installed, do something
if a user exists, do something

To only check the existence of packages or users without actually installing them.
For this kind of task, command or shell modules works fine.

  tasks:
    - name: check if httpd is installed
      shell: rpm -qa | grep httpd
      register: httpd_installed
      ignore_errors: True
      check_mode: False
      changed_when: False

    - name: print
      debug:
        msg: "httpd is installed"
      when: httpd_installed.rc == 0

But this is a little bit of trouble when you use it many times.

Extra parameters like changed_when or ignore_errors should be set
Warnings may be thrown at running Playbook or ansible-lint

So this article introduces some modules which can replace your command modules and make your Playbook simpler.

Test Environment

ansible: v2.9.9

targetOS: CentOS7.7 and Ubuntu 18.04

stat

https://docs.ansible.com/ansible/latest/modules/stat_module.html

stat module gets info of files.
Not only existence, it also checks file type(file/directory/link) or owner/group etc.

  tasks:
    - name: check if /etc/hosts exists
      stat:
        path: /etc/hosts
      register: etchosts

    - name: print
      debug:
        msg: "/etc/hosts exists"
      when: etchosts.stat.exists

    - name: print
      debug:
        msg: "/etc/hosts is directory"
      when: etchosts.stat.isdir # this should be False

package_facts

https://docs.ansible.com/ansible/latest/modules/package_facts_module.html

package_facts module gets installed packages list.
The info is available with ansible_facts.packages

  tasks:
    - name: check packages
      package_facts:
        manager: auto

    - name: print
      debug:
        msg: "Version of NetworkManager is {{ ansible_facts.packages['NetworkManager'][0]['version'] }}"
      when: "'NetworkManager' in ansible_facts.packages"

getent

https://docs.ansible.com/ansible/latest/modules/getent_module.html

getent module is a wrapper of getent command and can get info from passwd or group.
The info is available with getent_*** (*** is the name of database)
*Available databases varies on each OS and version.

  tasks:
    - name: check users
      getent:
        database: passwd

    - name: print
      debug:
        msg: "app1 user exists"
      when: "'app1' in getent_passwd"

service_facts

https://docs.ansible.com/ansible/latest/modules/service_facts_module.html

service_facts module get services list.
The info is available with ansible_facts.services

  tasks:
    - name: check services
      service_facts:

    - name: print
      debug:
        msg: "firewalld is {{ ansible_facts.services['firewalld.service']['status'] }}"
      when: "'firewalld.service' in ansible_facts.services"

Conclusion

By using each module instead of command module makes your Playbooks simpler and more useful for multiple OSs.

Connectivity check WITH Ansible

koh-sh — Sat, 21 Dec 2019 14:39:23 +0000

Using telnet or nc command to make sure DNS, routing and firewalls are set correctly is a kind of common use case for server engineers.
But these commands are not always installed on servers, and they don't seem to be usable for Ansible.
In this situation, wait_for module is the right module to use.

What is wait_for

https://docs.ansible.com/ansible/latest/modules/wait_for_module.html

Main use cases for this module are,

wait until a port becomes LISTEN state after starting
wait for specific strings by tailing log files

But if you use this module with a very short timeout, it works as a port-level connectivity check.

Example

※Version of Ansible is 2.9.0
I created the below Playbook for example.

% cat test.yml
---
- hosts: Vag1
  gather_facts: False
  tasks:
    - name: check if github.com:22 is accessible
      wait_for:
        host: github.com
        port: 22
        state: started
        delay: 0
        timeout: 1

    - name: check if 192.168.33.12:25 is accessible
      wait_for:
        host: 192.168.33.12
        port: 25
        state: started
        delay: 0
        timeout: 1
        search_regex: Postfix

checking access to github.com with 22 port at the 1st task
checking access to 192.168.33.12 with 25 port and weather the string "Postfix" is shown at the 2nd task

Executing.

[koh@kohs-MBP] ~/vag_test
% ansible-playbook test.yml

PLAY [Vag1] *****************************************************************************************

TASK [check if github.com:22 is accessible] *********************************************************
ok: [Vag1]

TASK [check if 192.168.33.12:25 is accessible] ******************************************************
ok: [Vag1]

PLAY RECAP ******************************************************************************************
Vag1                       : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

[koh@kohs-MBP] ~/vag_test
%

If the destinations are accessible, its result should be ok

Next, I tried blocking accesses at 192.168.33.12 with firewalld.

[vagrant@Vag2] ~
% hostname -I 
10.0.2.15 192.168.33.12
[vagrant@Vag2] ~
% sudo systemctl start firewalld
[vagrant@Vag2] ~
%

Tried again.

[koh@kohs-MBP] ~/vag_test
% ansible-playbook test.yml

PLAY [Vag1] *****************************************************************************************

TASK [check if github.com:22 is accessible] *********************************************************
ok: [Vag1]

TASK [check if 192.168.33.12:25 is accessible] ******************************************************
fatal: [Vag1]: FAILED! => {"changed": false, "elapsed": 1, "msg": "Timeout when waiting for search string Postfix in 192.168.33.12:25"}

PLAY RECAP ******************************************************************************************
Vag1                       : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

zsh: exit 2     ansible-playbook test.yml
[koh@kohs-MBP] ~/vag_test
%

An error is thrown and you can see you couldn't access.

Conclusion

Googling Ansible connectivity check always returns about connectivity between a play node and target node, so it is kind of hard to find out.

Ref

https://devops.stackexchange.com/questions/1658/ansible-other-option-available-for-telnet-check-of-open-ports

Configuration of ansible-lint

koh-sh — Sun, 17 Nov 2019 14:27:54 +0000

ansible-lint is a tool to check Ansible Playbook.

ansible / ansible-lint

ansible-lint checks playbooks for practices and behavior that could potentially be improved and can fix some of the most common ones for you

Ansible-lint

ansible-lint checks playbooks for practices and behavior that could potentially be improved. As a community-backed project ansible-lint supports only the last two major versions of Ansible.

Visit the Ansible Lint docs site

Using ansible-lint as a GitHub Action

This action allows you to run ansible-lint on your codebase without having to install it yourself.

# .github/workflows/ansible-lint.yml
name: ansible-lint
on:
  pull_request:
    branches: ["main", "stable", "release/v*"]
jobs:
  build:
    name: Ansible Lint # Naming the build is important to use it as a status check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run ansible-lint
        uses: ansible/ansible-lint@main
        # optional (see below):
        with:
          args: ""
          setup_python: "true"
          working_directory: ""
          requirements_file: ""

All the arguments are optional and most users should not need them:

args: Arguments to be passed to ansible-lint…

View on GitHub

It helps you to find syntax problems like extra spaces or lines, or point out where doesn't follow Ansible best practice.



[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[201] Trailing whitespace
site.yml:6
        msg: hello

[403] Package installs should not use latest
site.yml:8
Task/Handler: install httpd

[koh@kohs-MBP] ~/work/linttest
%

Below is the list of default rules.

https://docs.ansible.com/ansible-lint/rules/default_rules.html

But each playbook or teams might have their own rules that oppose to Ansible best practice.

Here is how to configure ansible-lint.
*Version of ansible-lint is 4.1.0.

Config with command line options

Rules are configurable with options of ansible-lint command.



[koh@kohs-MBP] ~/work/linttest
% ansible-lint --help
Usage: ansible-lint [options] playbook.yml [playbook2 ...]

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -L                    list all the rules
  -q                    quieter, although not silent output
  -p                    parseable output in the format of pep8
  --parseable-severity  parseable output including severity of rule
  -r RULESDIR           specify one or more rules directories using one or
                        more -r arguments. Any -r flags override the default
                        rules in
                        /Users/koh/.pyenv/versions/3.7.3/lib/python3.7/site-
                        packages/ansiblelint/rules, unless -R is also used.
  -R                    Use default rules in
                        /Users/koh/.pyenv/versions/3.7.3/lib/python3.7/site-
                        packages/ansiblelint/rules in addition to any extra
                        rules directories specified with -r. There is no need
                        to specify this if no -r flags are used
  -t TAGS               only check rules whose id/tags match these values
  -T                    list all the tags
  -v                    Increase verbosity level
  -x SKIP_LIST          only check rules whose id/tags do not match these
                        values
  --nocolor             disable colored output
  --force-color         Try force colored output (relying on ansible's code)
  --exclude=EXCLUDE_PATHS
                        path to directories or files to skip. This option is
                        repeatable.
  -c C                  Specify configuration file to use.  Defaults to
                        ".ansible-lint"
[koh@kohs-MBP] ~/work/linttest
%

Basically, you can configure everything with command line options but it is better to use a configuration file to share with your team, or to implement into CI.

Next is how to configure with a file.

Configuration file

It should be placed at ./.ansible-lint by default, or a file which specified with the option -c.
This is an example from the official doc.



exclude_paths:
  - ./my/excluded/directory/
  - ./my/other/excluded/directory/
  - ./last/excluded/directory/
parseable: true
quiet: true
rulesdir:
  - ./rule/directory/
skip_list:
  - skip_this_tag
  - and_this_one_too
  - skip_this_id
  - '401'
tags:
  - run_this_tag
use_default_rules: true
verbosity: 1

https://docs.ansible.com/ansible-lint/configuring/configuring.html#configuration-file

exclude_paths (--exclude)

Specify paths or files to exclude from lint.

parseable (-p)

Change the format of the output.
Each error will be converted to one line.



# parseable: false

[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[201] Trailing whitespace
/Users/koh/work/linttest/roles/201/tasks/main.yml:4
    msg: hello

[202] Octal file permissions must contain leading zero or be a string
/Users/koh/work/linttest/roles/202/tasks/main.yml:2
Task/Handler: error 202

[203] Most files should not contain tabs
/Users/koh/work/linttest/roles/203/tasks/main.yml:4
    msg: "     tab"

[koh@kohs-MBP] ~/work/linttest
%



# parseable: true

[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
/Users/koh/work/linttest/roles/201/tasks/main.yml:4: [E201] Trailing whitespace
/Users/koh/work/linttest/roles/202/tasks/main.yml:2: [E202] Octal file permissions must contain leading zero or be a string
/Users/koh/work/linttest/roles/203/tasks/main.yml:4: [E203] Most files should not contain tabs
[koh@kohs-MBP] ~/work/linttest
%

quiet (-q)

Reduce output.
Not completely 0 but a bit reduced.



# quiet: true

[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[201] /Users/koh/work/linttest/roles/201/tasks/main.yml:4
[202] /Users/koh/work/linttest/roles/202/tasks/main.yml:2
[203] /Users/koh/work/linttest/roles/203/tasks/main.yml:4
[koh@kohs-MBP] ~/work/linttest
%

rulesdir (-r)

Specify files or directories in which you put original rule files.

skip_list (-x)

Specify tags or error IDs that should be skipped.
You can check about tags with -T option.



[koh@kohs-MBP] ~/work/linttest
% ansible-lint -T
ANSIBLE0002 ['[201]']
ANSIBLE0004 ['[401]']
ANSIBLE0005 ['[402]']
ANSIBLE0006 ['[303]']
ANSIBLE0007 ['[302]']
ANSIBLE0008 ['[103]']
ANSIBLE0009 ['[202]']
ANSIBLE0010 ['[403]']
ANSIBLE0011 ['[502]']
ANSIBLE0012 ['[301]']
ANSIBLE0013 ['[305]']
ANSIBLE0014 ['[304]']
ANSIBLE0015 ['[104]']
ANSIBLE0016 ['[503]']
ANSIBLE0017 ['[501]']
ANSIBLE0018 ['[101]']
ANSIBLE0019 ['[102]']
behaviour ['[503]']
bug ['[304]']
command-shell ['[305]', '[302]', '[304]', '[306]', '[301]', '[303]']
deprecated ['[105]', '[104]', '[103]', '[101]', '[102]']
formatting ['[104]', '[203]', '[201]', '[204]', '[206]', '[205]', '[202]']
idempotency ['[301]']
idiom ['[601]', '[602]']
metadata ['[701]', '[704]', '[703]', '[702]']
module ['[404]', '[401]', '[403]', '[402]']
oddity ['[501]']
readability ['[502]']
repeatability ['[401]', '[403]', '[402]']
resources ['[302]', '[303]']
safety ['[305]']
task ['[502]', '[503]', '[504]', '[501]']
[koh@kohs-MBP] ~/work/linttest
%

tags (-t)

Opposite of skip_list, specify tags that you want to check.

use_default_rules (-R)

If True, default rules are applied.
If you want to check only your original rules, set it to False.

verbosity (-v)

Specify the verbosity of the output.
It only takes 2 kinds of values which are 0 or greater than 0.



        for file in files:
            if self.verbosity > 0:
                print("Examining %s of type %s" % (file['path'], file['type']))
            matches.extend(self.rules.run(file, tags=set(self.tags),
                           skip_list=self.skip_list))

https://github.com/ansible/ansible-lint/blob/5170c04201e71400421b27255280902c211f8548/lib/ansiblelint/__init__.py#L281

Configure inside Playbook

By adding a comment, you can skip checks by lines.

Below is an example of the Playbook.



[koh@kohs-MBP] ~/work/linttest
% cat site.yml
---
- hosts: all
  tasks:
    - name: install latest httpd
      yum:
        name: httpd
        state: latest

    - name: install mysql
      yum:
        name: mysql
        state: installed
[koh@kohs-MBP] ~/work/linttest
%

This playbook throws 403 error.



[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[403] Package installs should not use latest
site.yml:4
Task/Handler: install latest httpd

[koh@kohs-MBP] ~/work/linttest
%

If you really want to keep your httpd updated but not other packages, you can do like below. (you still should not do that though.)



[koh@kohs-MBP] ~/work/linttest
% cat site.yml
---
- hosts: all
  tasks:
    - name: install latest httpd
      yum:
        name: httpd
        state: latest # noqa 403

    - name: install mysql
      yum:
        name: mysql
        state: installed
[koh@kohs-MBP] ~/work/linttest
%

By adding # noqa ID, the line will be skipped from checks.



[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[koh@kohs-MBP] ~/work/linttest
%

Original rules

You can create your own rules.
There are some explanations on README and also I recommend you to have a look at scripts of the default rules.

https://github.com/ansible/ansible-lint#creating-custom-rules

https://github.com/ansible/ansible-lint/tree/master/lib/ansiblelint/rules

Here is my example of how to create my own rule.



[koh@kohs-MBP] ~/work/linttest
% cat origrules/True4BooleanRule.py
from ansiblelint import AnsibleLintRule


class True4BooleanRule(AnsibleLintRule):
    id = '99'
    shortdesc = 'Use "True" for boolean'
    description = 'We should "True" for boolean not "yes" or "true".'
    tags = ['formatting']

    def match(self, file, line):
        return ': yes' in line or ': true' in line
[koh@kohs-MBP] ~/work/linttest
%

Playbook can take yes , true to set True for boolean.
With this rule, it throws errors if yes or true are used.
*This is a really cheap script only for this explanation please use it with your own risk.

In .ansible-lint



[koh@kohs-MBP] ~/work/linttest
% cat .ansible-lint
rulesdir:
  - ./origrules/
[koh@kohs-MBP] ~/work/linttest
%

With this site.yml, it throws 2 errors as intended.



[koh@kohs-MBP] ~/work/linttest

  
  
  % cat site.yml




hosts: all

tasks:


name: this should be error
service:
name: httpd
state: started
enabled: yes
name: this should be error too
service:
name: mysqld
state: started
enabled: true
name: this is ok
service:
name: haproxy
state: started
enabled: True
[koh@kohs-MBP] ~/work/linttest
% ansible-lint site.yml
[99] Use "True" for boolean
site.yml:8
enabled: yes




[99] Use "True" for boolean

site.yml:14

        enabled: true

[koh@kohs-MBP] ~/work/linttest

%

Conclusion

Creating own rules is much easier than I expected.
So it is good to try one.

Using Testinfra with Ansible

koh-sh — Sun, 10 Nov 2019 06:38:31 +0000

Testinfra which tests infrastructure works really well with Ansible.
I posted about Testinfra previously so please check if you like.

Play with Testinfra which tests states of infrastructure

koh-sh ・ Nov 9 '19 ・ 4 min read

#testing #python #linux

Sharing Inventory

Testinfra can refer to Inventories of Ansible.
So you don't have to re-define hosts information for Ansible and tests too.

https://testinfra.readthedocs.io/en/latest/backends.html#ansible

$ py.test --hosts='ansible://all' # tests all inventory hosts
$ py.test --hosts='ansible://host1,ansible://host2'
$ py.test --hosts='ansible://web*'
$ py.test --force-ansible --hosts='ansible://all'
$ py.test --hosts='ansible://host?force_ansible=True'

If the inventory file is not specified with ansible.cfg, you can specify with --ansible-inventory=ANSIBLE_INVENTORY in command lines.

Executing modules of Ansible

You can execute modules of Ansible while testing.

https://testinfra.readthedocs.io/en/latest/modules.html#ansible

[koh@kohs-MBP] ~/vag_test
% ipython
Python 3.7.3 (default, May  1 2019, 16:07:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import testinfra

In [2]: host = testinfra.get_host("ansible://Vag1")

In [3]: host.ansible("command", "echo foo", check=False)
Out[3]:
{'ansible_facts': {'discovered_interpreter_python': '/usr/bin/python'},
 'changed': True,
 'cmd': ['echo', 'foo'],
 'delta': '0:00:00.004734',
 'end': '2019-10-05 15:07:42.251008',
 'rc': 0,
 'start': '2019-10-05 15:07:42.246274',
 'stderr': '',
 'stderr_lines': [],
 'stdout': 'foo',
 'stdout_lines': ['foo']}

In [4]:

This is an example of executing command module of Ansible with Testinfra.

As a result of executing a module, you can get like changed, rc or stdout same as Ansible.

setup module would fit well with testing.

[koh@kohs-MBP] ~/vag_test
% cat test_ansible.py
def test_dns(host):
    nameservers = host.ansible("setup")["ansible_facts"]["ansible_dns"]["nameservers"]
    assert '10.1.1.1' in nameservers
[koh@kohs-MBP] ~/vag_test
% 
[koh@kohs-MBP] ~/vag_test
% py.test -v test_ansible.py --hosts='ansible://Vag1'
======================================== test session starts ========================================
platform darwin -- Python 3.7.3, pytest-4.4.1, py-1.8.0, pluggy-0.9.0 -- /Users/koh/.pyenv/versions/3.7.3/bin/python3.7
cachedir: .pytest_cache
rootdir: /Users/koh/vag_test, inifile: pytest.ini
plugins: xonsh-0.8.12, testinfra-3.0.5
collected 1 item

test_ansible.py::test_dns[ansible://Vag1] FAILED                                              [100%]

============================================= FAILURES ==============================================
_____________________________________ test_dns[ansible://Vag1] ______________________________________

host = <testinfra.host.Host object at 0x10e9be748>

    def test_dns(host):
        nameservers = host.ansible("setup")["ansible_facts"]["ansible_dns"]["nameservers"]
>       assert '10.1.1.1' in nameservers
E       AssertionError: assert '10.1.1.1' in ['10.0.2.3']

test_ansible.py:3: AssertionError
===================================== 1 failed in 2.17 seconds ======================================
zsh: exit 1     py.test -v test_ansible.py --hosts='ansible://Vag1'
[koh@kohs-MBP] ~/vag_test
%

This is an example of checking nameserver of resolv.conf with setup module.

Refering Variable

You can refer to variables of Ansible.
host_vars, group_vars and magic variables like inventory_hostname can be referred from Testinfra.
Variables defined with include_vars in Playbooks cannot be referred.

[koh@kohs-MBP] ~/vag_test
% ipython
Python 3.7.3 (default, May  1 2019, 16:07:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import testinfra

In [2]: host = testinfra.get_host("ansible://Vag1")

In [3]: host.ansible.get_variables()
Out[3]:
{'aaa': 'bbb',
 'foo': 'bar',
 'hoge': 'fuga',
 'inventory_hostname': 'Vag1',
 'group_names': ['Vag'],
 'groups': {'Vag': ['Vag1', 'Vag2', 'Vag3'], 'all': ['Vag1', 'Vag2', 'Vag3']}}

In [4]:

Conclusion

As currently, Molecule use Testinfra as the default test tool, Testinfra works really well with Ansible.
Testinfra can be used with Docker or Kubernetes too, so I would keep trying them out.

Automatic ansible-lint with Github Actions

koh-sh — Sat, 09 Nov 2019 15:45:45 +0000

Now my account has access to Github Actions beta so I am trying to use it for syntax check and run ansible-lint for my Ansible playbook repository.
This article is based on the specification of Github Actions on 7th Sep 2019.

Configuration

I referred to the official doc for setting up.
https://help.github.com/en/categories/automating-your-workflow-with-github-actions

Until the first run

This time I use my repository which has Ansible Playbook to set up my MacBook.

koh-sh / macbook-playbook

ansible playbook to setup macbook

macbook-playbook

Ansible playbook to setup macbook

View on GitHub

Clicking Actions tab which is newly added.

You can use many templates of workflow provided by Github and I am using python package.
After clicking the template, you can modify the workflow template for your repo.
I edited the file like below. (I also changed the name of the file too)

name: Ansible lint

  on: [push]

  jobs:
   build:

      runs-on: macOS-latest
     strategy:
       max-parallel: 4
       matrix:
         python-version: [2.7, 3.5, 3.6, 3.7]

      steps:
     - uses: actions/checkout@v1
     - name: Set up Python ${{ matrix.python-version }}
       uses: actions/setup-python@v1
       with:
         python-version: ${{ matrix.python-version }}
     - name: Install dependencies
       run: |
         python -m pip install --upgrade pip
         pip install ansible ansible-lint
     - name: Lint playbook
       run: |
         ansible-playbook site.yml --syntax-check
         ansible-lint site.yml

The Playbook is for macOS, so I changed runs-on to macOS-latest.

Below tasks are supposed to run.

Install ansible and ansible-lint with pip
run ansible-playbook with --syntax-check option
run ansible-lint

After committing this file, tests were run automatically.

You can see the result at Actions tab.

https://github.com/koh-sh/macbook-playbook/commit/3daeb98a056981335938e74c530ebb5f6ae1f6e3/checks

The number of python-version is 4 and max-parallel is 4 too so 4 tests were run concurrently.
You can refer to the official doc about the limit of resources.
https://help.github.com/en/articles/workflow-syntax-for-github-actions#usage-limits

You can click each version of builds for details.
This time ansible-lint threw some errors so the status is failed.

Until test success

ansible-lint threw errors so fixing with this commit.
Removing trailing space and omit the error about shell modules with .ansible-lint file as I needed them.

https://github.com/koh-sh/macbook-playbook/commit/577519c6213c4a1e7a3c047808ef146ca2d67f86

I pushed to the master branch and the tests run automatically.

https://github.com/koh-sh/macbook-playbook/commit/577519c6213c4a1e7a3c047808ef146ca2d67f86/checks

Tests are completed without problems.

Also, you can see the results of tests for each commit with symbols.

Trying Pull Requests

How about pull requests?
Let's see how they work.

to trigger github actions test #1

koh-sh posted on Sep 07, 2019

This is test PR to trigger Github actions test

View on GitHub

By opening a pull request, tests run automatically and the results are available at PR summary.

And this repository is integrated into my slack workspace and the result was notified too.
https://slack.github.com

But when I pushed to master, the test result was not notified.
Another setting might be necessary but I haven't checked yet.

Testing with multiple version of Ansible

Currently, these tests are run with the latest version of Ansible and 4 versions of python.
Let's change it to 2.7.x, 2.8.x of Ansible and 2.x and 3.x of python matrix.

I modified the workflow file as below.

name: Ansible lint

on: [push]

jobs:
  build:

    runs-on: macOS-latest
    strategy:
      max-parallel: 4
      matrix:
        python-version: [2.7, 3.7]
        ansible-version: [2.7.13, 2.8.4]

    steps:
    - uses: actions/checkout@v1
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v1
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install Ansible ${{ matrix.ansible-version }}
      run: |
        python -m pip install --upgrade pip
        pip install ansible-lint ansible==${{ matrix.ansible-version }}
    - name: Lint playbook
      run: |
        ansible-playbook site.yml --syntax-check
        ansible-lint site.yml

After a push, the test setting was updated and run as I intended.

https://github.com/koh-sh/macbook-playbook/commit/0ffab4e73391ab8f3d39d5c149307bab9c06714f/checks

Conclusion

With Github Actions, I can ansible-lint automatically for each commit.
All of the settings in this article took only 1 hour since these are very simple and easy to use.
Also, Github Actions are available not only tests but also deploys too so I will keep trying them out.

How to check if an IP address is within a range in Ansible Playbook

koh-sh — Sat, 09 Nov 2019 14:59:08 +0000

I was trying to have tasks for each site and multiple regions in Cloud respectively.
My idea was to use the IP address to determine where the host is, but it was kind of struggling to create the condition.
So here is my memo down below.

TL;DR

This when statement checks if the IP address is within the specified range.

- name: test
  debug:
    msg: work
  when: ansible_default_ipv4.address | ipaddr('10.0.2.0/24') | ipaddr('bool')

This task prints "work" if ansible_default_ipv4.address is within 10.0.2.0/24

Explanation

I am using ipaddr filter
https://docs.ansible.com/ansible/latest/user_guide/playbooks_filters_ipaddr.html

First half

[IP list] | ipaddr('172.30.0.0/16')

Above syntax extracts IP addresses in [IP list] which is within 172.30.0.0/16

% cat test.yml
---
- hosts: Vag1
  gather_facts: True
  tasks:
    - set_fact:
        testip:
          - "192.168.1.2"
          - "10.0.2.15"

    - name: test
      debug:
        msg: "{{ testip | ipaddr('10.0.2.0/24') }}"

By Running test.yml above.

[koh@kohs-MacBook-Pro] ~/vag_test
% ansible-playbook test.yml
PLAY [Vag1] ***************************************************************************************************************************

TASK [set_fact] ***********************************************************************************************************************
ok: [Vag1]

TASK [test] ***************************************************************************************************************************
ok: [Vag1] => {
    "msg": [
        "10.0.2.15"
    ]
}

PLAY RECAP ****************************************************************************************************************************
Vag1                       : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

[koh@kohs-MacBook-Pro] ~/vag_test
%

There are 2 IPs in testip and only 10.0.2.15 was printed since it is within 10.0.2.0/24

The second half

[IP address] | ipaddr('bool')

It returns True if [IP address] is a valid IP address.

% cat test2.yml
---
- hosts: Vag1
  gather_facts: True
  tasks:
    - set_fact:
        testip:
          - "192.168.1.2"
          - "10.0.2.15.14.22"
          - "hogehoge"
          - ""

    - name: test
      debug:
        msg: "{{ item | ipaddr('bool')  }}"
      with_items: "{{ testip }}"

By Running test2.yml above.

[koh@kohs-MacBook-Pro] ~/vag_test
% ansible-playbook test2.yml

PLAY [Vag1] ****************************************************************************************************************************

TASK [set_fact] ****************************************************************************************************************************
ok: [Vag1]

TASK [test] ****************************************************************************************************************************
ok: [Vag1] => (item=192.168.1.2) => {
    "msg": true
}
ok: [Vag1] => (item=10.0.2.15.14.22) => {
    "msg": false
}
ok: [Vag1] => (item=hogehoge) => {
    "msg": false
}
ok: [Vag1] => (item=) => {
    "msg": false
}

PLAY RECAP ****************************************************************************************************************************
Vag1                       : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

[koh@kohs-MacBook-Pro] ~/vag_test
%

With these 2 syntaxes, you can check if an IP address of hosts is within a range automatically.

Reference

https://stackoverflow.com/questions/38725204/regular-expression-matching-for-ip-range-in-ansible-playbooks-for-grouping

Redis can make Ansible only a bit faster

koh-sh — Sat, 09 Nov 2019 14:27:26 +0000

Ansible has a function called "Gather Facts" which retrieves variables from target hosts.
By default, the facts are cached in memory and gathered every time you run Playbook.
Usually, it takes only a few seconds but I know some people get annoyed by it.

So in this post, I will try to avoid the struggles with Redis instead of memory.

Environment

Local Machine: MacOS Mojave 10.14.5
Target Host: CentOS 7.5 on Vagrant
Ansible: 2.8.1
Redis: 5.0.5

Redis

It is only a test so I am using docker.

[koh@kohs-MBP] ~/vag_test
% docker run -d -p 6379:6379 --name ansibleredis redis
Unable to find image 'redis:latest' locally
latest: Pulling from library/redis
f5d23c7fed46: Pull complete
a4a5c04dafc1: Pull complete
605bafc84bc9: Pull complete
f07a4e35cd96: Pull complete
17944e5e3eb7: Pull complete
6f875a8605e0: Pull complete
Digest: sha256:8888f6cd2509062a377e903e17777b4a6d59c92769f6807f034fa345da9eebcf
Status: Downloaded newer image for redis:latest
cbb0b15a703b2044b8a3d0d7b5b58f6dbd8d0b09d7b16bb5560cec57a221c39e
[koh@kohs-MBP] ~/vag_test
% docker container ls
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                    NAMES
cbb0b15a703b        redis               "docker-entrypoint.s…"   8 seconds ago       Up 7 seconds        0.0.0.0:6379->6379/tcp   ansibleredis
[koh@kohs-MBP] ~/vag_test
%

Done. Docker is awesome as you know.

Ansible

Using the official document as a reference, I added the below entries to ansible.cfg.
https://docs.ansible.com/ansible/latest/plugins/cache.html

[koh@kohs-MBP] ~/vag_test
% cat ansible.cfg
[defaults]

# Specify cache plugin
fact_caching = redis
# Prefix of key name
fact_caching_prefix = ansible_facts_
# Connection info of Redis(host:port)
fact_caching_connection = localhost:6379
# timeout until cache expire(s)
fact_caching_timeout = 60
# Policy of using cache. smart: if valid cache exists, Ansible would use.
gathering = smart
[koh@kohs-MBP] ~/vag_test
%

I set timeout short for testing. Please set it as you like.

Playbook

I prepared the below simple Playbook.
After gather_facts, prints ansible_hostname.

[koh@kohs-MBP] ~/vag_test
% cat test.yml
---
- hosts: Vag1
  gather_facts: True
  tasks:
    - name: debug
      debug:
        var: ansible_hostname
[koh@kohs-MBP] ~/vag_test
%

Test

Default(memory)

First, I commented out all fact_caching_foobar lines. Then check the time with time command.

[koh@kohs-MBP] ~/vag_test
% time ansible-playbook test.yml

PLAY [Vag1] *****************************************************************************************

TASK [Gathering Facts] ******************************************************************************
ok: [Vag1]

TASK [debug] ****************************************************************************************
ok: [Vag1] => {
    "ansible_hostname": "Vag1"
}

PLAY RECAP ******************************************************************************************
Vag1                       : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ansible-playbook test.yml  1.02s user 0.30s system 67% cpu 1.955 total
[koh@kohs-MBP] ~/vag_test
%

It took about 2 seconds.
I tested multiple times but it takes about 1.8 to 2.0 seconds.

Redis

Now enabled fact_caching_foobar lines in ansible.cfg and check time.

[koh@kohs-MBP] ~/vag_test
% cat ansible.cfg
[defaults]

# Specify cache plugin
fact_caching = redis
# Prefix of key name
fact_caching_prefix = ansible_facts_
# Connection info of Redis(host:port)
fact_caching_connection = localhost:6379
# timeout until cache expire(s)
fact_caching_timeout = 60
# Policy of using cache. smart: if valid cache exists, Ansible would use.
gathering = smart
[koh@kohs-MBP] ~/vag_test
% time ansible-playbook test.yml

PLAY [Vag1] *****************************************************************************************

TASK [Gathering Facts] ******************************************************************************
ok: [Vag1]

TASK [debug] ****************************************************************************************
ok: [Vag1] => {
    "ansible_hostname": "Vag1"
}

PLAY RECAP ******************************************************************************************
Vag1                       : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ansible-playbook test.yml  1.02s user 0.30s system 77% cpu 1.713 total
[koh@kohs-MBP] ~/vag_test
% time ansible-playbook test.yml

PLAY [Vag1] *****************************************************************************************

TASK [debug] ****************************************************************************************
ok: [Vag1] => {
    "ansible_hostname": "Vag1"
}

PLAY RECAP ******************************************************************************************
Vag1                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

ansible-playbook test.yml  0.69s user 0.20s system 97% cpu 0.901 total
[koh@kohs-MBP] ~/vag_test
%

The first run after enabling was pretty much the same as the default since it retrieved the facts, but the second run took only 0.9 second which was 0.8-second faster.

How Redis works

Let's check what kind of values are in Redis DB.

[koh@kohs-MBP] ~/vag_test
% docker exec -it ansibleredis redis-cli
127.0.0.1:6379> keys *
1) "ansible_facts_Vag1"
2) "ansible_cache_keys"
127.0.0.1:6379>

There are 2 keys. ansible_cache_keys and { fact_cache_prefix } { hostname }


[koh@kohs-MBP] ~/vag_test
% docker exec -it ansibleredis redis-cli
127.0.0.1:6379> ZRANGE ansible_cache_keys 0 -1
1) "Vag1"
127.0.0.1:6379>

ansible_cache_keys has a list of cached hosts.

I have only one target so the number of value should be one too.

[koh@kohs-MBP] ~/vag_test
% docker exec -it ansibleredis redis-cli
127.0.0.1:6379> get ansible_facts_Vag1
"{\n    \"_ansible_facts_gathered\": true,\n    \"ansible_all_ipv4_addresses\": [\n        \"10.0.2.15\",\n        \"192.168.33.11\"\n    ],\n    \"ansible_all_ipv6_addresses\": [\n        \"fe80::590e:8e97:c90c:cc33\",\n        \"fe80::a00:27ff:fe71:612b\"\n    ],\n    \"ansible_apparmor\": {\n        \"status\": \"disabled\"\n    },\n    \"ansible_architecture\": \"x86_64\",\n    \"ansible_bios_date\": \"12/01/2006\",\n    \"ansible_bios_version\": \"VirtualBox\",\n    \"ansible_cmdline\": {\n        \"BOOT_IMAGE\": \"/vmlinuz-3.10.0-862.11.6.el7.x86_64\",\n        \"LANG\": \"en_US.UTF-8\",\n        \"biosdevname\": \"0\",\n        \"crashkernel\": \"auto\",\n        \"net.ifnames\": \"0\",\n        \"quiet\": true,\n        \"rd.lvm.lv\": \"centos/swap\",\n        \"rhgb\": true,\n        \"ro\": true,\n        \"root\": \"/dev/mapper/centos-root\"\n    },\n    \"ansible_date_time\": {\n        \"date\": \"2019-07-17\",\n        \"day\": \"17\",\n        \"epoch\": \"1563371875\",\n        \"hour\": \"22\",\n        \"iso8601\": \"2019-07-17T13:57:55Z\",\n        \"iso8601_basic\": \"20190717T225755697435\",\n        \"iso8601_basic_short\": \"20190717T225755\",\n        \"iso8601_micro\": \"2019-07-17T13:57:55.697505Z\",\n        \"minute\": \"57\",\n        \"month\": \"07\",\n        \"second\": \"55\",\n        \"time\": \"22:57:55\",\n        \"tz\": \"JST\",\n        \"tz_offset\": \"+0900\",\n        \"weekday\": \"Wednesday\",\n        \"weekday_number\": \"3\",\n        \"weeknumber\": \"28\",\n        \"year\": \"2019\"\n    },\n    \"ansible_default_ipv4\": {\n        \"address\": \"10.0.2.15\",\n        \"alias\": \"eth0\",\n        \"broadcast\": \"10.0.2.255\",\n        \"gateway\": \"10.0.2.2\",\n        \"interface\": \"eth0\",\n        \"macaddress\": \"08:00:27:8b:c9:3f\",\n        \"mtu\": 1500,\n        \"netmask\": \"255.255.255.0\",\n        \"network\": \"10.0.2.0\",\n        \"type\": \"ether\"\n    },\n    \"ansible_default_ipv6\": {},\n    \"ansible_device_links\": {\n        \"ids\": {\n            \"dm-0\": [\n                \"dm-name-centos-root\",\n                \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3rbL1yYbzzPZGdVlveHAelfn7TdiL4PPMK\"\n            ],\n            \"dm-1\": [\n                \"dm-name-centos-swap\",\n                \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3r5Se12VYk5F7OofGC3mzqUxBtHLOc6f0i\"\n            ],\n            \"dm-2\": [\n                \"dm-name-centos-home\",\n                \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3rBnDGTj2yA0ImV13Ife64zvRL20DXAcBp\"\n            ],\n            \"sda\": [\n                \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af\"\n            ],\n            \"sda1\": [\n                \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af-part1\"\n            ],\n            \"sda2\": [\n                \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af-part2\",\n                \"lvm-pv-uuid-xkveE6-q5bs-AFQm-GG2X-lWDs-nZNn-v1DuLs\"\n            ]\n        },\n        \"labels\": {},\n        \"masters\": {\n            \"sda2\": [\n                \"dm-0\",\n                \"dm-1\",\n                \"dm-2\"\n            ]\n        },\n        \"uuids\": {\n            \"dm-0\": [\n                \"214cf212-d7f8-41fe-89a4-6b5e1f1d469c\"\n            ],\n            \"dm-1\": [\n                \"0f5a6474-6d09-4220-8eb4-f97e79b41ea0\"\n            ],\n            \"dm-2\": [\n                \"0fb2cf77-ad36-4728-a3f5-b53dc134e3fd\"\n            ],\n            \"sda1\": [\n                \"ec9d8bfa-8da0-43ce-b469-f0178aa904b5\"\n            ]\n        }\n    },\n    \"ansible_devices\": {\n        \"dm-0\": {\n            \"holders\": [],\n            \"host\": \"\",\n            \"links\": {\n                \"ids\": [\n                    \"dm-name-centos-root\",\n                    \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3rbL1yYbzzPZGdVlveHAelfn7TdiL4PPMK\"\n                ],\n                \"labels\": [],\n                \"masters\": [],\n                \"uuids\": [\n                    \"214cf212-d7f8-41fe-89a4-6b5e1f1d469c\"\n                ]\n            },\n            \"model\": null,\n            \"partitions\": {},\n            \"removable\": \"0\",\n            \"rotational\": \"1\",\n            \"sas_address\": null,\n            \"sas_device_handle\": null,\n            \"scheduler_mode\": \"\",\n            \"sectors\": \"85950464\",\n            \"sectorsize\": \"512\",\n            \"size\": \"40.98 GB\",\n            \"support_discard\": \"0\",\n            \"vendor\": null,\n            \"virtual\": 1\n        },\n        \"dm-1\": {\n            \"holders\": [],\n            \"host\": \"\",\n            \"links\": {\n                \"ids\": [\n                    \"dm-name-centos-swap\",\n                    \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3r5Se12VYk5F7OofGC3mzqUxBtHLOc6f0i\"\n                ],\n                \"labels\": [],\n                \"masters\": [],\n                \"uuids\": [\n                    \"0f5a6474-6d09-4220-8eb4-f97e79b41ea0\"\n                ]\n            },\n            \"model\": null,\n            \"partitions\": {},\n            \"removable\": \"0\",\n            \"rotational\": \"1\",\n            \"sas_address\": null,\n            \"sas_device_handle\": null,\n            \"scheduler_mode\": \"\",\n            \"sectors\": \"4194304\",\n            \"sectorsize\": \"512\",\n            \"size\": \"2.00 GB\",\n            \"support_discard\": \"0\",\n            \"vendor\": null,\n            \"virtual\": 1\n        },\n        \"dm-2\": {\n            \"holders\": [],\n            \"host\": \"\",\n            \"links\": {\n                \"ids\": [\n                    \"dm-name-centos-home\",\n                    \"dm-uuid-LVM-cXud4zK75fureDdfCQfo5enloeKDIc3rBnDGTj2yA0ImV13Ife64zvRL20DXAcBp\"\n                ],\n                \"labels\": [],\n                \"masters\": [],\n                \"uuids\": [\n                    \"0fb2cf77-ad36-4728-a3f5-b53dc134e3fd\"\n                ]\n            },\n            \"model\": null,\n            \"partitions\": {},\n            \"removable\": \"0\",\n            \"rotational\": \"1\",\n            \"sas_address\": null,\n            \"sas_device_handle\": null,\n            \"scheduler_mode\": \"\",\n            \"sectors\": \"41959424\",\n            \"sectorsize\": \"512\",\n            \"size\": \"20.01 GB\",\n            \"support_discard\": \"0\",\n            \"vendor\": null,\n            \"virtual\": 1\n        },\n        \"sda\": {\n            \"holders\": [],\n            \"host\": \"\",\n            \"links\": {\n                \"ids\": [\n                    \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af\"\n                ],\n                \"labels\": [],\n                \"masters\": [],\n                \"uuids\": []\n            },\n            \"model\": \"VBOX HARDDISK\",\n            \"partitions\": {\n                \"sda1\": {\n                    \"holders\": [],\n                    \"links\": {\n                        \"ids\": [\n                            \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af-part1\"\n                        ],\n                        \"labels\": [],\n                        \"masters\": [],\n                        \"uuids\": [\n                            \"ec9d8bfa-8da0-43ce-b469-f0178aa904b5\"\n                        ]\n                    },\n                    \"sectors\": \"2097152\",\n                    \"sectorsize\": 512,\n                    \"size\": \"1.00 GB\",\n                    \"start\": \"2048\",\n                    \"uuid\": \"ec9d8bfa-8da0-43ce-b469-f0178aa904b5\"\n                },\n                \"sda2\": {\n                    \"holders\": [\n                        \"centos-root\",\n                        \"centos-swap\",\n                        \"centos-home\"\n                    ],\n                    \"links\": {\n                        \"ids\": [\n                            \"ata-VBOX_HARDDISK_VB1c9995b6-54c424af-part2\",\n                            \"lvm-pv-uuid-xkveE6-q5bs-AFQm-GG2X-lWDs-nZNn-v1DuLs\"\n                        ],\n                        \"labels\": [],\n                        \"masters\": [\n                            \"dm-0\",\n                            \"dm-1\",\n                            \"dm-2\"\n                        ],\n                        \"uuids\": []\n                    },\n                    \"sectors\": \"132118528\",\n                    \"sectorsize\": 512,\n                    \"size\": \"63.00 GB\",\n                    \"start\": \"2099200\",\n                    \"uuid\": null\n                }\n            },\n            \"removable\": \"0\",\n            \"rotational\": \"1\",\n            \"sas_address\": null,\n            \"sas_device_handle\": null,\n            \"scheduler_mode\": \"deadline\",\n            \"sectors\": \"134217728\",\n            \"sectorsize\": \"512\",\n            \"size\": \"64.00 GB\",\n            \"support_discard\": \"0\",\n            \"vendor\": \"ATA\",\n            \"virtual\": 1\n        }\n    },\n    \"ansible_distribution\": \"CentOS\",\n    \"ansible_distribution_file_parsed\": true,\n    \"ansible_distribution_file_path\": \"/etc/redhat-release\",\n    \"ansible_distribution_file_variety\": \"RedHat\",\n    \"ansible_distribution_major_version\": \"7\",\n    \"ansible_distribution_release\": \"Core\",\n    \"ansible_distribution_version\": \"7\",\n    \"ansible_dns\": {},\n    \"ansible_domain\": \"\",\n    \"ansible_effective_group_id\": 1000,\n    \"ansible_effective_user_id\": 1000,\n    \"ansible_env\": {\n        \"HOME\": \"/home/vagrant\",\n        \"LANG\": \"C\",\n        \"LC_ALL\": \"C\",\n        \"LC_CTYPE\": \"UTF-8\",\n        \"LC_MESSAGES\": \"C\",\n        \"LOGNAME\": \"vagrant\",\n        \"MAIL\": \"/var/mail/vagrant\",\n        \"PATH\": \"/usr/local/bin:/usr/bin\",\n        \"PWD\": \"/home/vagrant\",\n        \"SELINUX_LEVEL_REQUESTED\": \"\",\n        \"SELINUX_ROLE_REQUESTED\": \"\",\n        \"SELINUX_USE_CURRENT_RANGE\": \"\",\n        \"SHELL\": \"/usr/bin/zsh\",\n        \"SHLVL\": \"1\",\n        \"SSH_CLIENT\": \"192.168.33.1 57299 22\",\n        \"SSH_CONNECTION\": \"192.168.33.1 57299 192.168.33.11 22\",\n        \"SSH_TTY\": \"/dev/pts/0\",\n        \"TERM\": \"xterm-256color\",\n        \"USER\": \"vagrant\",\n        \"XDG_RUNTIME_DIR\": \"/run/user/1000\",\n        \"XDG_SESSION_ID\": \"17\",\n        \"_\": \"/usr/bin/python\"\n    },\n    \"ansible_eth0\": {\n        \"active\": true,\n        \"device\": \"eth0\",\n        \"features\": {\n            \"busy_poll\": \"off [fixed]\",\n            \"fcoe_mtu\": \"off [fixed]\",\n            \"generic_receive_offload\": \"on\",\n            \"generic_segmentation_offload\": \"on\",\n            \"highdma\": \"off [fixed]\",\n            \"hw_tc_offload\": \"off [fixed]\",\n            \"l2_fwd_offload\": \"off [fixed]\",\n            \"large_receive_offload\": \"off [fixed]\",\n            \"loopback\": \"off [fixed]\",\n            \"netns_local\": \"off [fixed]\",\n            \"ntuple_filters\": \"off [fixed]\",\n            \"receive_hashing\": \"off [fixed]\",\n            \"rx_all\": \"off\",\n            \"rx_checksumming\": \"off\",\n            \"rx_fcs\": \"off\",\n            \"rx_udp_tunnel_port_offload\": \"off [fixed]\",\n            \"rx_vlan_filter\": \"on [fixed]\",\n            \"rx_vlan_offload\": \"on\",\n            \"rx_vlan_stag_filter\": \"off [fixed]\",\n            \"rx_vlan_stag_hw_parse\": \"off [fixed]\",\n            \"scatter_gather\": \"on\",\n            \"tcp_segmentation_offload\": \"on\",\n            \"tx_checksum_fcoe_crc\": \"off [fixed]\",\n            \"tx_checksum_ip_generic\": \"on\",\n            \"tx_checksum_ipv4\": \"off [fixed]\",\n            \"tx_checksum_ipv6\": \"off [fixed]\",\n            \"tx_checksum_sctp\": \"off [fixed]\",\n            \"tx_checksumming\": \"on\",\n            \"tx_fcoe_segmentation\": \"off [fixed]\",\n            \"tx_gre_csum_segmentation\": \"off [fixed]\",\n            \"tx_gre_segmentation\": \"off [fixed]\",\n            \"tx_gso_partial\": \"off [fixed]\",\n            \"tx_gso_robust\": \"off [fixed]\",\n            \"tx_ipip_segmentation\": \"off [fixed]\",\n            \"tx_lockless\": \"off [fixed]\",\n            \"tx_nocache_copy\": \"off\",\n            \"tx_scatter_gather\": \"on\",\n            \"tx_scatter_gather_fraglist\": \"off [fixed]\",\n            \"tx_sctp_segmentation\": \"off [fixed]\",\n            \"tx_sit_segmentation\": \"off [fixed]\",\n            \"tx_tcp6_segmentation\": \"off [fixed]\",\n            \"tx_tcp_ecn_segmentation\": \"off [fixed]\",\n            \"tx_tcp_mangleid_segmentation\": \"off\",\n            \"tx_tcp_segmentation\": \"on\",\n            \"tx_udp_tnl_csum_segmentation\": \"off [fixed]\",\n            \"tx_udp_tnl_segmentation\": \"off [fixed]\",\n            \"tx_vlan_offload\": \"on [fixed]\",\n            \"tx_vlan_stag_hw_insert\": \"off [fixed]\",\n            \"udp_fragmentation_offload\": \"off [fixed]\",\n            \"vlan_challenged\": \"off [fixed]\"\n        },\n        \"hw_timestamp_filters\": [],\n        \"ipv4\": {\n            \"address\": \"10.0.2.15\",\n            \"broadcast\": \"10.0.2.255\",\n            \"netmask\": \"255.255.255.0\",\n            \"network\": \"10.0.2.0\"\n        },\n        \"ipv6\": [\n            {\n                \"address\": \"fe80::590e:8e97:c90c:cc33\",\n                \"prefix\": \"64\",\n                \"scope\": \"link\"\n            }\n        ],\n        \"macaddress\": \"08:00:27:8b:c9:3f\",\n        \"module\": \"e1000\",\n        \"mtu\": 1500,\n        \"pciid\": \"0000:00:03.0\",\n        \"promisc\": false,\n        \"speed\": 1000,\n        \"timestamping\": [\n            \"tx_software\",\n            \"rx_software\",\n            \"software\"\n        ],\n        \"type\": \"ether\"\n    },\n    \"ansible_eth1\": {\n        \"active\": true,\n        \"device\": \"eth1\",\n        \"features\": {\n            \"busy_poll\": \"off [fixed]\",\n            \"fcoe_mtu\": \"off [fixed]\",\n            \"generic_receive_offload\": \"on\",\n            \"generic_segmentation_offload\": \"on\",\n            \"highdma\": \"off [fixed]\",\n            \"hw_tc_offload\": \"off [fixed]\",\n            \"l2_fwd_offload\": \"off [fixed]\",\n            \"large_receive_offload\": \"off [fixed]\",\n            \"loopback\": \"off [fixed]\",\n            \"netns_local\": \"off [fixed]\",\n            \"ntuple_filters\": \"off [fixed]\",\n            \"receive_hashing\": \"off [fixed]\",\n            \"rx_all\": \"off\",\n            \"rx_checksumming\": \"off\",\n            \"rx_fcs\": \"off\",\n            \"rx_udp_tunnel_port_offload\": \"off [fixed]\",\n            \"rx_vlan_filter\": \"on [fixed]\",\n            \"rx_vlan_offload\": \"on\",\n            \"rx_vlan_stag_filter\": \"off [fixed]\",\n            \"rx_vlan_stag_hw_parse\": \"off [fixed]\",\n            \"scatter_gather\": \"on\",\n            \"tcp_segmentation_offload\": \"on\",\n            \"tx_checksum_fcoe_crc\": \"off [fixed]\",\n            \"tx_checksum_ip_generic\": \"on\",\n            \"tx_checksum_ipv4\": \"off [fixed]\",\n            \"tx_checksum_ipv6\": \"off [fixed]\",\n            \"tx_checksum_sctp\": \"off [fixed]\",\n            \"tx_checksumming\": \"on\",\n            \"tx_fcoe_segmentation\": \"off [fixed]\",\n            \"tx_gre_csum_segmentation\": \"off [fixed]\",\n            \"tx_gre_segmentation\": \"off [fixed]\",\n            \"tx_gso_partial\": \"off [fixed]\",\n            \"tx_gso_robust\": \"off [fixed]\",\n            \"tx_ipip_segmentation\": \"off [fixed]\",\n            \"tx_lockless\": \"off [fixed]\",\n            \"tx_nocache_copy\": \"off\",\n            \"tx_scatter_gather\": \"on\",\n            \"tx_scatter_gather_fraglist\": \"off [fixed]\",\n            \"tx_sctp_segmentation\": \"off [fixed]\",\n            \"tx_sit_segmentation\": \"off [fixed]\",\n            \"tx_tcp6_segmentation\": \"off [fixed]\",\n            \"tx_tcp_ecn_segmentation\": \"off [fixed]\",\n            \"tx_tcp_mangleid_segmentation\": \"off\",\n            \"tx_tcp_segmentation\": \"on\",\n            \"tx_udp_tnl_csum_segmentation\": \"off [fixed]\",\n            \"tx_udp_tnl_segmentation\": \"off [fixed]\",\n            \"tx_vlan_offload\": \"on [fixed]\",\n            \"tx_vlan_stag_hw_insert\": \"off [fixed]\",\n            \"udp_fragmentation_offload\": \"off [fixed]\",\n            \"vlan_challenged\": \"off [fixed]\"\n        },\n        \"hw_timestamp_filters\": [],\n        \"ipv4\": {\n            \"address\": \"192.168.33.11\",\n            \"broadcast\": \"192.168.33.255\",\n            \"netmask\": \"255.255.255.0\",\n            \"network\": \"192.168.33.0\"\n        },\n        \"ipv6\": [\n            {\n                \"address\": \"fe80::a00:27ff:fe71:612b\",\n                \"prefix\": \"64\",\n                \"scope\": \"link\"\n            }\n        ],\n        \"macaddress\": \"08:00:27:71:61:2b\",\n        \"module\": \"e1000\",\n        \"mtu\": 1500,\n        \"pciid\": \"0000:00:08.0\",\n        \"promisc\": false,\n        \"speed\": 1000,\n        \"timestamping\": [\n            \"tx_software\",\n            \"rx_software\",\n            \"software\"\n        ],\n        \"type\": \"ether\"\n    },\n    \"ansible_fibre_channel_wwn\": [],\n    \"ansible_fips\": false,\n    \"ansible_form_factor\": \"Other\",\n    \"ansible_fqdn\": \"Vag1\",\n    \"ansible_hostname\": \"Vag1\",\n    \"ansible_hostnqn\": \"\",\n    \"ansible_interfaces\": [\n        \"lo\",\n        \"eth1\",\n        \"eth0\"\n    ],\n    \"ansible_is_chroot\": true,\n    \"ansible_iscsi_iqn\": \"\",\n    \"ansible_kernel\": \"3.10.0-862.11.6.el7.x86_64\",\n    \"ansible_lo\": {\n        \"active\": true,\n        \"device\": \"lo\",\n        \"features\": {\n            \"busy_poll\": \"off [fixed]\",\n            \"fcoe_mtu\": \"off [fixed]\",\n            \"generic_receive_offload\": \"on\",\n            \"generic_segmentation_offload\": \"on\",\n            \"highdma\": \"on [fixed]\",\n            \"hw_tc_offload\": \"off [fixed]\",\n            \"l2_fwd_offload\": \"off [fixed]\",\n            \"large_receive_offload\": \"off [fixed]\",\n            \"loopback\": \"on [fixed]\",\n            \"netns_local\": \"on [fixed]\",\n            \"ntuple_filters\": \"off [fixed]\",\n            \"receive_hashing\": \"off [fixed]\",\n            \"rx_all\": \"off [fixed]\",\n            \"rx_checksumming\": \"on [fixed]\",\n            \"rx_fcs\": \"off [fixed]\",\n            \"rx_udp_tunnel_port_offload\": \"off [fixed]\",\n            \"rx_vlan_filter\": \"off [fixed]\",\n            \"rx_vlan_offload\": \"off [fixed]\",\n            \"rx_vlan_stag_filter\": \"off [fixed]\",\n            \"rx_vlan_stag_hw_parse\": \"off [fixed]\",\n            \"scatter_gather\": \"on\",\n            \"tcp_segmentation_offload\": \"on\",\n            \"tx_checksum_fcoe_crc\": \"off [fixed]\",\n            \"tx_checksum_ip_generic\": \"on [fixed]\",\n            \"tx_checksum_ipv4\": \"off [fixed]\",\n            \"tx_checksum_ipv6\": \"off [fixed]\",\n            \"tx_checksum_sctp\": \"on [fixed]\",\n            \"tx_checksumming\": \"on\",\n            \"tx_fcoe_segmentation\": \"off [fixed]\",\n            \"tx_gre_csum_segmentation\": \"off [fixed]\",\n            \"tx_gre_segmentation\": \"off [fixed]\",\n            \"tx_gso_partial\": \"off [fixed]\",\n            \"tx_gso_robust\": \"off [fixed]\",\n            \"tx_ipip_segmentation\": \"off [fixed]\",\n            \"tx_lockless\": \"on [fixed]\",\n            \"tx_nocache_copy\": \"off [fixed]\",\n            \"tx_scatter_gather\": \"on [fixed]\",\n            \"tx_scatter_gather_fraglist\": \"on [fixed]\",\n            \"tx_sctp_segmentation\": \"on\",\n            \"tx_sit_segmentation\": \"off [fixed]\",\n            \"tx_tcp6_segmentation\": \"on\",\n            \"tx_tcp_ecn_segmentation\": \"on\",\n            \"tx_tcp_mangleid_segmentation\": \"on\",\n            \"tx_tcp_segmentation\": \"on\",\n            \"tx_udp_tnl_csum_segmentation\": \"off [fixed]\",\n            \"tx_udp_tnl_segmentation\": \"off [fixed]\",\n            \"tx_vlan_offload\": \"off [fixed]\",\n            \"tx_vlan_stag_hw_insert\": \"off [fixed]\",\n            \"udp_fragmentation_offload\": \"on\",\n            \"vlan_challenged\": \"on [fixed]\"\n        },\n        \"hw_timestamp_filters\": [],\n        \"ipv4\": {\n            \"address\": \"127.0.0.1\",\n            \"broadcast\": \"host\",\n            \"netmask\": \"255.0.0.0\",\n            \"network\": \"127.0.0.0\"\n        },\n        \"ipv6\": [\n            {\n                \"address\": \"::1\",\n                \"prefix\": \"128\",\n                \"scope\": \"host\"\n            }\n        ],\n        \"mtu\": 65536,\n        \"promisc\": false,\n        \"timestamping\": [\n            \"rx_software\",\n            \"software\"\n        ],\n        \"type\": \"loopback\"\n    },\n    \"ansible_local\": {},\n    \"ansible_lsb\": {},\n    \"ansible_machine\": \"x86_64\",\n    \"ansible_machine_id\": \"b8ae4e7c6e42490b801633d8d903c9a0\",\n    \"ansible_memfree_mb\": 769,\n    \"ansible_memory_mb\": {\n        \"nocache\": {\n            \"free\": 874,\n            \"used\": 117\n        },\n        \"real\": {\n            \"free\": 769,\n            \"total\": 991,\n            \"used\": 222\n        },\n        \"swap\": {\n            \"cached\": 0,\n            \"free\": 2047,\n            \"total\": 2047,\n            \"used\": 0\n        }\n    },\n    \"ansible_memtotal_mb\": 991,\n    \"ansible_mounts\": [\n        {\n            \"block_available\": 226495,\n            \"block_size\": 4096,\n            \"block_total\": 259584,\n            \"block_used\": 33089,\n            \"device\": \"/dev/sda1\",\n            \"fstype\": \"xfs\",\n            \"inode_available\": 523962,\n            \"inode_total\": 524288,\n            \"inode_used\": 326,\n            \"mount\": \"/boot\",\n            \"options\": \"rw,seclabel,relatime,attr2,inode64,noquota\",\n            \"size_available\": 927723520,\n            \"size_total\": 1063256064,\n            \"uuid\": \"ec9d8bfa-8da0-43ce-b469-f0178aa904b5\"\n        },\n        {\n            \"block_available\": 10398487,\n            \"block_size\": 4096,\n            \"block_total\": 10738562,\n            \"block_used\": 340075,\n            \"device\": \"/dev/mapper/centos-root\",\n            \"fstype\": \"xfs\",\n            \"inode_available\": 21453369,\n            \"inode_total\": 21487616,\n            \"inode_used\": 34247,\n            \"mount\": \"/\",\n            \"options\": \"rw,seclabel,relatime,attr2,inode64,noquota\",\n            \"size_available\": 42592202752,\n            \"size_total\": 43985149952,\n            \"uuid\": \"214cf212-d7f8-41fe-89a4-6b5e1f1d469c\"\n        },\n        {\n            \"block_available\": 5233400,\n            \"block_size\": 4096,\n            \"block_total\": 5242367,\n            \"block_used\": 8967,\n            \"device\": \"/dev/mapper/centos-home\",\n            \"fstype\": \"xfs\",\n            \"inode_available\": 10489816,\n            \"inode_total\": 10489856,\n            \"inode_used\": 40,\n            \"mount\": \"/home\",\n            \"options\": \"rw,seclabel,relatime,attr2,inode64,noquota\",\n            \"size_available\": 21436006400,\n            \"size_total\": 21472735232,\n            \"uuid\": \"0fb2cf77-ad36-4728-a3f5-b53dc134e3fd\"\n        }\n    ],\n    \"ansible_nodename\": \"Vag1\",\n    \"ansible_os_family\": \"RedHat\",\n    \"ansible_pkg_mgr\": \"yum\",\n    \"ansible_proc_cmdline\": {\n        \"BOOT_IMAGE\": \"/vmlinuz-3.10.0-862.11.6.el7.x86_64\",\n        \"LANG\": \"en_US.UTF-8\",\n        \"biosdevname\": \"0\",\n        \"crashkernel\": \"auto\",\n        \"net.ifnames\": \"0\",\n        \"quiet\": true,\n        \"rd.lvm.lv\": [\n            \"centos/root\",\n            \"centos/swap\"\n        ],\n        \"rhgb\": true,\n        \"ro\": true,\n        \"root\": \"/dev/mapper/centos-root\"\n    },\n    \"ansible_processor\": [\n        \"0\",\n        \"GenuineIntel\",\n        \"Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz\"\n    ],\n    \"ansible_processor_cores\": 1,\n    \"ansible_processor_count\": 1,\n    \"ansible_processor_threads_per_core\": 1,\n    \"ansible_processor_vcpus\": 1,\n    \"ansible_product_name\": \"VirtualBox\",\n    \"ansible_product_serial\": \"NA\",\n    \"ansible_product_uuid\": \"NA\",\n    \"ansible_product_version\": \"1.2\",\n    \"ansible_python\": {\n        \"executable\": \"/usr/bin/python\",\n        \"has_sslcontext\": true,\n        \"type\": \"CPython\",\n        \"version\": {\n            \"major\": 2,\n            \"micro\": 5,\n            \"minor\": 7,\n            \"releaselevel\": \"final\",\n            \"serial\": 0\n        },\n        \"version_info\": [\n            2,\n            7,\n            5,\n            \"final\",\n            0\n        ]\n    },\n    \"ansible_python_version\": \"2.7.5\",\n    \"ansible_real_group_id\": 1000,\n    \"ansible_real_user_id\": 1000,\n    \"ansible_selinux\": {\n        \"config_mode\": \"enforcing\",\n        \"mode\": \"enforcing\",\n        \"policyvers\": 31,\n        \"status\": \"enabled\",\n        \"type\": \"targeted\"\n    },\n    \"ansible_selinux_python_present\": true,\n    \"ansible_service_mgr\": \"systemd\",\n    \"ansible_ssh_host_key_ecdsa_public\": \"AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBA5XlGiLVt6/NnCPwaH89VKPo+cvKjyzwnje1z9LkaiFXRNhWTsxYsMYPjx5cf5HQbJs4VCKIaPxK20QFYSabLc=\",\n    \"ansible_ssh_host_key_ed25519_public\": \"AAAAC3NzaC1lZDI1NTE5AAAAIGhrt2KMmJ0a2QdNNsFElTnHSdhufURJmAIo39+5R1hP\",\n    \"ansible_ssh_host_key_rsa_public\": \"AAAAB3NzaC1yc2EAAAADAQABAAABAQC99JJpb04/QLprQKr1Duz7dBfAHvbwuaouvVkMPKVoxQ7u2xUiTqKMWwckPBw3GfRC+soM6KXj+WnaIFsIFmYBYOwN1dl4ldpJxvp/+rz4VUvOsjqiAK6Ju7Hi2zlvN/Cz8n8NMC7+BT295s1jGYJU7SGVVJ/uLDVoiDa/dcptk17V4bgN8Wqe3hiEDbtbRMgZdwQ01o8b1uM6GQAAbz1S6kwnZ3fOXHU7Z29lZu2g5/xIYX48yhV8YnqwWmI2+i0zd06b+HoXwQH2+OVlZEMfv2Gc+xp4E0Pqu6VDyOPJGIkRuV0aBX6qT/6FDBUWvcGXs7gVdUL2wdvi5V8uf/rV\",\n    \"ansible_swapfree_mb\": 2047,\n    \"ansible_swaptotal_mb\": 2047,\n    \"ansible_system\": \"Linux\",\n    \"ansible_system_capabilities\": [\n        \"\"\n    ],\n    \"ansible_system_capabilities_enforced\": \"True\",\n    \"ansible_system_vendor\": \"innotek GmbH\",\n    \"ansible_uptime_seconds\": 3839,\n    \"ansible_user_dir\": \"/home/vagrant\",\n    \"ansible_user_gecos\": \"vagrant\",\n    \"ansible_user_gid\": 1000,\n    \"ansible_user_id\": \"vagrant\",\n    \"ansible_user_shell\": \"/usr/bin/zsh\",\n    \"ansible_user_uid\": 1000,\n    \"ansible_userspace_architecture\": \"x86_64\",\n    \"ansible_userspace_bits\": \"64\",\n    \"ansible_virtualization_role\": \"guest\",\n    \"ansible_virtualization_type\": \"virtualbox\",\n    \"discovered_interpreter_python\": \"/usr/bin/python\",\n    \"gather_subset\": [\n        \"all\"\n    ],\n    \"module_setup\": true\n}"
127.0.0.1:6379>

As you see that is how facts are registered to Redis.

Right after running Playbook, I checked TTL of the key and the value was the same as fact_caching_timeout.

[koh@kohs-MBP] ~/vag_test
% docker exec -it ansibleredis redis-cli
127.0.0.1:6379> ttl ansible_facts_Vag1
(integer) 57
127.0.0.1:6379>

Conclusion

Now we know how to make Ansible only a bit faster.
It is only a few seconds but might be useful when you have to run Playbook many times.
Also please be noted that if Redis is down, Ansible cannot be run.
So if you are interested in using this for production CI/CD, you have to ensure the availability of Redis.

Difference between Ansible's copy and template module

koh-sh — Sat, 09 Nov 2019 09:26:12 +0000

Ansible has copy module and template module.
Basically, both modules are to copy files from local machine to remote machines, but technically behaviors are a bit different.
In this note, I would like to go through the difference between them and points to care.

*Version of Ansible is 2.8.1

copy

https://docs.ansible.com/ansible/latest/modules/copy_module.html#copy-module

Basic features

Variables cannot be used in the file
default path to src files are under roles/{{ rolename }}/files
with remote_src parameter, you can copy files from remote machines to the machine's other place
with content parameter, you can specify the contents of files directly without src files

template

https://docs.ansible.com/ansible/latest/modules/template_module.html#template-module

Basic features

with Jinja2, you can program like for loop or if conditions in files
Variables can be used in files
default path to src files are under roles/{{ rolename }}/templates

About Jinja2

I would like to explain about Jinja2 a bit.

http://jinja.pocoo.org/docs/2.10/#

Jinja2 is a modern and designer-friendly templating language for Python, modelled after Django’s templates.

Here are simple examples of for loop and if conditions

[koh@kohs-MBP] ~/vag_test
% cat test.j2
{% for item in ["foo","bar","baz"] %}
{{ item }}
{% endfor %}

{% if inventory_hostname == "Vag2" %}
hostname is Vag2
{% else %}
hostname is not Vag2
{% endif %}
[koh@kohs-MBP] ~/vag_test
%

With for loop it prints foo,bar,baz.
After that, if inventory_hostname is Vag2, then print hostname is Vag2
if not, print hostname is not Vag2.

Below is the result.

[koh@kohs-MBP] ~/vag_test
% ansible Vag1 -m template -a "src=test.j2 dest=."
Vag1 | CHANGED => {
    "ansible_facts": {
        "discovered_interpreter_python": "/usr/bin/python"
    },
    "changed": true,
    "checksum": "c2383df182afda3f4de83ce7171885ce7fd4839a",
    "dest": "././test.j2",
    "gid": 1000,
    "group": "vagrant",
    "md5sum": "54a03d50ba7a7751f6d647afdeb80e02",
    "mode": "0644",
    "owner": "vagrant",
    "secontext": "unconfined_u:object_r:user_home_t:s0",
    "size": 34,
    "src": "/home/vagrant/.ansible/tmp/ansible-tmp-1562164682.016716-96505856164811/source",
    "state": "file",
    "uid": 1000
}
[koh@kohs-MBP] ~/vag_test
% ssh Vag1 "cat test.j2"
foo
bar
baz

hostname is not Vag2
[koh@kohs-MBP] ~/vag_test
%

By using Jinja2 or Ansible's variables, your Playbook would be much better for practical uses like the below cases.

using for loops for configs of reverse proxies like HAProxy or Nginx
using variables is useful to share the same templates for prod/stg/dev environments

Important points

As I explained template module is very convenient, but as long as it modifies original files at execution of Ansible, there is a possibility of miss configurations.

Wrong syntax is common mistakes, but worse cases are wrong recognition of Jinja2 format by Ansible.

For example, Apache's config about LogFormat might be recognized as Jinja2.
Here is a template with Logformat entry and running Ansible.

[koh@kohs-MBP] ~/vag_test
% cat logformat.j2
LogFormat "%{%d/%b/%Y %T}t.%{msec_frac}t %{%z}t"
[koh@kohs-MBP] ~/vag_test
%
[koh@kohs-MBP] ~/vag_test
% ansible Vag1 -m template -a "src=logformat.j2 dest=."
Vag1 | FAILED! => {
    "changed": false,
    "msg": "AnsibleError: template error while templating string: Encountered unknown tag 'd'.. String: LogFormat \"%{%d/%b/%Y %T}t.%{msec_frac}t %{%z}t\"\n"
}
zsh: exit 2     ansible Vag1 -m template -a "src=logformat.j2 dest=."
[koh@kohs-MBP] ~/vag_test
%

{%d in the template is recognized as a Tag of Jinja2 and Ansible threw the error.

How to avoid these errors

Below ideas are good for avoiding the above errors and miss configurations.

Use copy module when Jinja2 templating or variables are not used

Copy module never modifies the source file so using copy module is properly is the best way to make Playbook safer.

Use validate parameter

Template module has validate parameter which executes a command to check the validity of templates.
It really works when setting up critical configurations that cannot be failed like sshd or sudoers.
Copy module also has this parameter so it is still useful for copy module too.

- name: Copy a new sudoers file into place, after passing validation with visudo
  template:
    src: /mine/sudoers
    dest: /etc/sudoers
    validate: /usr/sbin/visudo -cf %s

Use check mode

Ansible has check mode(-C) you can check how the Playbook works without making any changes to the actual environment.
It works great with Diff option(-D).

[koh@kohs-MBP] ~/vag_test
% ansible Vag1 -m template -a "src=test.j2 dest=." -D -C
--- before: ./test.j2
+++ after: /Users/koh/.ansible/tmp/ansible-local-90545ps884h5s/tmpuvs9nt1z/test.j2
@@ -1,4 +1,4 @@
-foo
+fooooo
 bar
 baz


Vag1 | CHANGED => {
    "changed": true
}
[koh@kohs-MBP] ~/vag_test
%

Conclusion

By using template module effectively, your Playbook would be more practical.
Ansible is famous for simplicity, but template can bring chaos to your Playbook so please use with consideration not to use too much.

Play with Testinfra which tests states of infrastructure

koh-sh — Sat, 09 Nov 2019 05:14:46 +0000

This is my note about Testinfra which can be an alternative of ServerSpec.
I previously wrote about goss which is also a testing tool for infrastructure.
This might be nice to compare with.

Work with Serverspec alternative tool Goss

koh-sh ・ Nov 8 '19 ・ 4 min read

#go #testing #linux

What is Testinfra

https://testinfra.readthedocs.io/en/latest/

About
With Testinfra you can write unit tests in Python to test actual state of your servers configured by management tools like Salt, Ansible, Puppet, Chef and so on.

Testinfra aims to be a Serverspec equivalent in python and is written as a plugin to the powerful Pytest test engine

To put it simply, Testinfra is like ServerSpec but written in Python, and works great with configuration management tools like Ansible, Chef.

Features

Compared with ServerSpec, Testinfra has the below features.

Lots of Connection Backend

Testinfra has several options for connecting remote hosts other than plain SSH.
Testinfra can refer to an inventory of Ansible, also able to connect containers by docker or kubectl.

https://testinfra.readthedocs.io/en/latest/backends.html

local
paramiko
docker
ssh
salt
ansible
kubectl
winrm
LXC/LXD

Above is the list of connection backend.

Interactive testing

https://testinfra.readthedocs.io/en/latest/api.html

It can connect to host and test interactively so you don't even have to write a test file.
And I think Testinfra works great with ipython.

[koh@kohs-MBP] ~/vag_test
% ipython
Python 3.7.3 (default, May  1 2019, 16:07:48)
Type 'copyright', 'credits' or 'license' for more information
IPython 7.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import testinfra

In [2]: host = testinfra.get_host("paramiko://vagrant@Vag1:22", sudo=True)

In [3]: host.file("/etc/passwd").mode == 0o644
Out[3]: True

In [4]:

Let's try

Environment

Client

MacOS Mojave 10.14.5
Python 3.7.3

Remote host

CentOS 7.5.1804 on Vagrant
Python 2.7.5

Install

Installing with pip on the client machine.

$ pip install testinfra

writing a test

Writing a test file.

def test_passwd_file(host):
    passwd = host.file("/etc/passwd")
    assert passwd.contains("root")
    assert passwd.user == "root"
    assert passwd.group == "root"
    assert passwd.mode == 0o644


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


def test_selinux(host):
    cmd = host.run("/usr/sbin/getenforce")
    assert cmd.stdout == "Enforcing\n"

In this test example, it tests

contents, owner/permission of /etc/passwd
is-active, is-enabled of NGINX
status of selinux

Test execution

So from here, I am running Testinfra.
Testing from local machine to CentOS on Vagrant with SSH.
Also, NGINX is running on the remote machine.

[koh@kohs-MBP] ~/vag_test
% py.test -v test_first.py --connection=ssh --host=Vag1
======================================== test session starts ========================================
platform darwin -- Python 3.7.3, pytest-4.4.1, py-1.8.0, pluggy-0.9.0 -- /Users/koh/.pyenv/versions/3.7.3/bin/python3.7
cachedir: .pytest_cache
rootdir: /Users/koh/vag_test
plugins: xonsh-0.8.12, testinfra-3.0.5
collected 3 items

test_first.py::test_passwd_file[ssh://Vag1] PASSED                                            [ 33%]
test_first.py::test_nginx_running_and_enabled[ssh://Vag1] PASSED                              [ 66%]
test_first.py::test_selinux[ssh://Vag1] PASSED                                                [100%]

===================================== 3 passed in 3.22 seconds ======================================
[koh@kohs-MBP] ~/vag_test
%

It is clear and easy to check the result.
And now I stop NGINX.

[koh@kohs-MBP] ~/vag_test
% py.test -v test_first.py --connection=ssh --host=Vag1
======================================== test session starts ========================================
platform darwin -- Python 3.7.3, pytest-4.4.1, py-1.8.0, pluggy-0.9.0 -- /Users/koh/.pyenv/versions/3.7.3/bin/python3.7
cachedir: .pytest_cache
rootdir: /Users/koh/vag_test
plugins: xonsh-0.8.12, testinfra-3.0.5
collected 3 items

test_first.py::test_passwd_file[ssh://Vag1] PASSED                                            [ 33%]
test_first.py::test_nginx_running_and_enabled[ssh://Vag1] FAILED                              [ 66%]
test_first.py::test_selinux[ssh://Vag1] PASSED                                                [100%]

============================================= FAILURES ==============================================
____________________________ test_nginx_running_and_enabled[ssh://Vag1] _____________________________

host = <testinfra.host.Host object at 0x103826438>

    def test_nginx_running_and_enabled(host):
        nginx = host.service("nginx")
>       assert nginx.is_running
E       assert False
E        +  where False = <service nginx>.is_running

test_first.py:11: AssertionError
================================ 1 failed, 2 passed in 3.06 seconds =================================
zsh: exit 1     py.test -v test_first.py --connection=ssh --host=Vag1
[koh@kohs-MBP] ~/vag_test
%

It is obvious that which item is failed and how it failed.
Also able to test multiple hosts.

[koh@kohs-MBP] ~/vag_test
% py.test -v test_first.py --connection=ssh --host=Vag1,Vag2
======================================== test session starts ========================================
platform darwin -- Python 3.7.3, pytest-4.4.1, py-1.8.0, pluggy-0.9.0 -- /Users/koh/.pyenv/versions/3.7.3/bin/python3.7
cachedir: .pytest_cache
rootdir: /Users/koh/vag_test
plugins: xonsh-0.8.12, testinfra-3.0.5
collected 6 items

test_first.py::test_passwd_file[ssh://Vag1] PASSED                                            [ 16%]
test_first.py::test_nginx_running_and_enabled[ssh://Vag1] PASSED                              [ 33%]
test_first.py::test_selinux[ssh://Vag1] PASSED                                                [ 50%]
test_first.py::test_passwd_file[ssh://Vag2] PASSED                                            [ 66%]
test_first.py::test_nginx_running_and_enabled[ssh://Vag2] FAILED                              [ 83%]
test_first.py::test_selinux[ssh://Vag2] FAILED                                                [100%]

============================================= FAILURES ==============================================
____________________________ test_nginx_running_and_enabled[ssh://Vag2] _____________________________

host = <testinfra.host.Host object at 0x11026f4e0>

    def test_nginx_running_and_enabled(host):
        nginx = host.service("nginx")
>       assert nginx.is_running
E       assert False
E        +  where False = <service nginx>.is_running

test_first.py:11: AssertionError
_____________________________________ test_selinux[ssh://Vag2] ______________________________________

host = <testinfra.host.Host object at 0x11026f4e0>

    def test_selinux(host):
        cmd = host.run("/usr/sbin/getenforce")
>       assert cmd.stdout == "Enforcing\n"
E       AssertionError: assert 'Permissive\n' == 'Enforcing\n'
E         - Permissive
E         + Enforcing

test_first.py:17: AssertionError
================================ 2 failed, 4 passed in 6.14 seconds =================================
zsh: exit 1     py.test -v test_first.py --connection=ssh --host=Vag1,Vag2
[koh@kohs-MBP] ~/vag_test
%

Conclusion

Compared with ServerSpec, ServerSpec has more resources, and many more documents on the internet (especially in Japanese).
But as I mentioned there are some pros of Testinfra so if you prefer Python, it is worth trying at least once.

Finally I am using journalctl

koh-sh — Fri, 08 Nov 2019 13:17:22 +0000

I know it is too late but now I found out journalctl is convenient.

What is journalctl

From the output of man journalctl

NAME
       journalctl - Query the systemd journal

SYNOPSIS
       journalctl [OPTIONS...] [MATCHES...]

DESCRIPTION
       journalctl may be used to query the contents of the systemd(1) journal as written by
       systemd-journald.service(8).

OK, then what is journald?
Let's see man systemd-journald

DESCRIPTION
       systemd-journald is a system service that collects and stores logging data. It creates and
       maintains structured, indexed journals based on logging information that is received from a
       variety of sources:

To put it simply, journald corrects and manages many kinds of logs.
It can correct the below logs. Pretty much every log.

Kernel log messages, via kmsg
Simple system log messages, via the libc syslog(3) call
Structured system log messages via the native Journal API, see sd_journal_print(3)
Standard output and standard error of service units. For further details see below.
Audit records, originating from the kernel audit subsystem

Work with journalctl

So let's play with journalctl.
Environment: CentOS 7.5.1804 on Vagrant.

Without any options, it prints all logs stated above.
Older entries come top and operated with a pager like less command.

% sudo journalctl

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 14:26:56 JST. --
Apr 13 14:05:21 localhost.localdomain systemd-journal[84]: Runtime journal is using 6.1M (max allowed 49.5M, trying to leave 74.3M free of 489.6M available <E2><86><92> current limit 49.5M).
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpuset
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpu
<ellipsis>
Apr 13 14:20:01 Vag2 systemd[1]: Stopping User Slice of root.
Apr 13 14:20:32 Vag2 systemd[1]: Starting Cleanup of Temporary Directories...
Apr 13 14:20:32 Vag2 systemd[1]: Started Cleanup of Temporary Directories.
Apr 13 14:23:18 Vag2 sudo[2428]:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl

Options can be used to filter logs.
Here are some useful options.

Kernel messages

-k prints kernel messages like dmesg command.

% sudo journalctl -k

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 14:34:48 JST. --
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpuset
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpu
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpuacct
Apr 13 14:05:21 localhost.localdomain kernel: Linux version 3.10.0-862.11.6.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC) ) #1 SMP Tue Aug 14 21:49:04 UTC 2018
Apr 13 14:05:21 localhost.localdomain kernel: Command line: BOOT_IMAGE=/vmlinuz-3.10.0-862.11.6.el7.x86_64 root=/dev/mapper/centos-root ro net.ifnames=0 biosdevname=0 crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF-8

Units

-u prints specific unit logs.
Printing HAproxy's log for example.

% sudo journalctl -u haproxy

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 15:00:48 JST. --
Apr 13 14:05:31 Vag2 systemd[1]: Started HAProxy Load Balancer.
Apr 13 14:05:31 Vag2 systemd[1]: Starting HAProxy Load Balancer...
Apr 13 14:05:31 Vag2 haproxy-systemd-wrapper[1019]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds
Apr 13 15:00:45 Vag2 systemd[1]: Reloaded HAProxy Load Balancer.
Apr 13 15:00:45 Vag2 haproxy-systemd-wrapper[1019]: haproxy-systemd-wrapper: re-executing on SIGUSR2.
Apr 13 15:00:45 Vag2 haproxy-systemd-wrapper[1019]: haproxy-systemd-wrapper: executing /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 1036

Priority

-p prints a specific priority level of logs.
Specified with below numbers or strings.

emerg(0)
alert(1)
crit(2)
err(3)
warning(4)
notice(5)
info(6)
debug(7)

% sudo journalctl -p err

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 14:48:50 JST. --
Apr 13 14:05:31 Vag2 systemd[1]: Failed to start Crash recovery kernel arming.

Priorities can be multiple.

% sudo journalctl -p err -p warning

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 14:49:58 JST. --
<ellipsis>
Apr 13 05:05:29 Vag2 kernel: 00:00:00.000268 main     Executable: /opt/VBoxGuestAdditions-5.2.18/sbin/VBoxService
                             00:00:00.000268 main     Process ID: 906
                             00:00:00.000269 main     Package type: LINUX_64BITS_GENERIC
Apr 13 05:05:29 Vag2 kernel: 00:00:00.003419 main     5.2.18 r124319 started. Verbose level = 0
Apr 13 14:05:31 Vag2 chronyd[647]: Forward time jump detected!
Apr 13 14:05:31 Vag2 systemd[1]: Failed to start Crash recovery kernel arming.
Apr 13 14:05:31 Vag2 systemd[1]: kdump.service failed.
Apr 13 14:05:41 Vag2 kernel: 00:00:10.017183 timesync vgsvcTimeSyncWorker: Radical guest time change: 32 411 887 294 000ns (GuestNow=1 555 131 941 050 133 000 ns GuestLast=1

Other than filtering

There are some options which change how to print.

Reverse order

-r prints newer logs first.

% sudo journalctl -r

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 14:56:44 JST. --
Apr 13 14:56:44 Vag2 sudo[2609]:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl -r
Apr 13 14:56:24 Vag2 sudo[2605]:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl -r
Apr 13 14:50:01 Vag2 systemd[1]: Stopping User Slice of root.
Apr 13 14:50:01 Vag2 systemd[1]: Removed slice User Slice of root.
Apr 13 14:50:01 Vag2 CROND[2596]: (root) CMD (/usr/lib64/sa/sa1 1 1)

Follow

-f keep printing new entries while using it. Like tail -f command.

% sudo journalctl -f

-- Logs begin at Sat 2019-04-13 14:05:21 JST. --
Apr 13 14:50:01 Vag2 systemd[1]: Created slice User Slice of root.
Apr 13 14:50:01 Vag2 systemd[1]: Starting User Slice of root.
Apr 13 14:50:01 Vag2 systemd[1]: Started Session 8 of user root.
Apr 13 14:50:01 Vag2 systemd[1]: Starting Session 8 of user root.
Apr 13 14:50:01 Vag2 CROND[2596]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Apr 13 14:50:01 Vag2 systemd[1]: Removed slice User Slice of root.
Apr 13 14:50:01 Vag2 systemd[1]: Stopping User Slice of root.
Apr 13 14:56:24 Vag2 sudo[2605]:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl -r

Non pager

-no-pager prints logs without pager.

% sudo journalctl --no-pager

-- Logs begin at Sat 2019-04-13 14:05:21 JST, end at Sat 2019-04-13 15:02:30 JST. --
Apr 13 14:05:21 localhost.localdomain systemd-journal[84]: Runtime journal is using 6.1M (max allowed 49.5M, trying to leave 74.3M free of 489.6M available → current limit 49.5M).
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpuset
Apr 13 14:05:21 localhost.localdomain kernel: Initializing cgroup subsys cpu
<ellipsis>
Apr 13 15:01:01 Vag2 anacron[2654]: Will run job `cron.daily' in 30 min.
Apr 13 15:01:01 Vag2 anacron[2654]: Will run job `cron.weekly' in 50 min.
Apr 13 15:01:01 Vag2 anacron[2654]: Jobs will be executed sequentially
Apr 13 15:02:30 Vag2 sudo[2661]:  vagrant : TTY=pts/0 ; PWD=/home/vagrant ; USER=root ; COMMAND=/bin/journalctl --no-pager

Conclusion

I think if you are familiar with these options, journalctl should be very convenient for you.
I know some people don't like it but I personally like it.

Work with Serverspec alternative tool Goss

koh-sh — Fri, 08 Nov 2019 10:51:47 +0000

What is Goss?

Goss is a YAML based server testing tool written in Go.
It checks statuses of process, ports and else.

goss-org / goss

Quick and Easy server testing/validation

Goss - Quick and Easy server validation

Goss in 45 seconds

Note: For testing containers see the dgoss wrapper. Also, user submitted wrapper scripts for Kubernetes kgoss and Docker Compose dcgoss.

Note: For some Docker/Kubernetes healthcheck, health endpoint, and container ordering examples, see my blog post here.

Introduction

What is Goss?

Goss is a YAML based serverspec alternative tool for validating a server's configuration. It eases the process of writing tests by allowing the user to generate tests from the current system state. Once the test suite is written they can be executed, waited-on, or served as a health endpoint.

Why use Goss?

Goss is EASY! - Goss in 45 seconds
Goss is FAST! - small-medium test suites are near instantaneous, see benchmarks
Goss is SMALL! - <10MB single self-contained binary

Installation

Note: For macOS and Windows, see: platform-feature-parity.

This will install goss and dgoss.

…

View on GitHub

Differences from Serverspec

As it is Serverspec alternative tool, there are some differences between them.

Pros of Goss

Easier to write as it is YAML

Tests can be defined by a single YAML file, easier to manage and doesn't require much time to learn.

Able to create test suite within a second.

Goss provides a command to define a test state automatically.

Easy to install

Goss comes with one single binary so no need to think about dependency.

Pros of Serverspec

Executable from remote

Like Ansible or Chef, able to execute from a remote node with SSH

More Resources

Goss supports about 20 Resources but Serverspec has twice (as of Mar 28th, 2019)

More flexible

Serverspec is more flexible as it allows us to code with Ruby.

Let's try

CentOS 7.5.1804 on Vagrant.
Goss v0.3.6.

Install

A script is prepared officially so it cannot be easier to install.
Also, dgoss which is a command for Docker container would be installed but I am not going to use it this time.

And please be noted that the script is not recommended for production environment.
Try manual install instead.



[vagrant@Vag2] ~
% curl -fsSL https://goss.rocks/install | sudo sh
Downloading https://github.com/aelsabbahy/goss/releases/download/v0.3.6/goss-linux-amd64
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   606    0   606    0     0    808      0 --:--:-- --:--:-- --:--:--   809
100 8324k  100 8324k    0     0   236k      0  0:00:35  0:00:35 --:--:--  240k
Goss v0.3.6 has been installed to /usr/local/bin/goss
goss --version
goss version v0.3.6
Downloading https://raw.githubusercontent.com/aelsabbahy/goss/master/extras/dgoss/dgoss
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3803  100  3803    0     0   9722      0 --:--:-- --:--:-- --:--:--  9726
dgoss master has been installed to /usr/local/bin/dgoss
[vagrant@Vag2] ~
% which goss
/usr/local/bin/goss
[vagrant@Vag2] ~
%

Create a test suite

As I mentioned earlier, Goss has commands to create a test suite automatically.
goss.yaml will be created by goss autoadd or goss add [resource].

In this post, I will work on a host which HAProxy is installed.



[vagrant@Vag2] ~/work
% goss autoadd haproxy
Adding Group to './goss.yaml':

haproxy:
  exists: true
  gid: 188


Adding Package to './goss.yaml':

haproxy:
  installed: true
  versions:
  - 1.5.18


Adding Process to './goss.yaml':

haproxy:
  running: true


Adding Service to './goss.yaml':

haproxy:
  enabled: true
  running: true


Adding User to './goss.yaml':

haproxy:
  exists: true
  uid: 188
  gid: 188
  groups:
  - haproxy
  home: /var/lib/haproxy
  shell: /sbin/nologin


[vagrant@Vag2] ~/work
%

After goss autoadd, the created goss.yaml is here.



[vagrant@Vag2] ~/work
% ls -l goss.yaml
-rw-r--r-- 1 vagrant vagrant 347 Mar 23 03:55 goss.yaml
[vagrant@Vag2] ~/work
% cat goss.yaml
package:
  haproxy:
    installed: true
    versions:
    - 1.5.18
service:
  haproxy:
    enabled: true
    running: true
user:
  haproxy:
    exists: true
    uid: 188
    gid: 188
    groups:
    - haproxy
    home: /var/lib/haproxy
    shell: /sbin/nologin
group:
  haproxy:
    exists: true
    gid: 188
process:
  haproxy:
    running: true
[vagrant@Vag2] ~/work
%

Just a single command, below test items are created.

Test items vary on the target.
Installed packages
is-active, is-enabled of service
User definition
Group definition
Process status

You can use add [resource] command to specify each item one by one.

Test execution

Success

Then Let's try testing.
Of course, it is easy to execute.



[vagrant@Vag2] ~/work
% goss validate
.............

Total Duration: 0.033s
Count: 13, Failed: 0, Skipped: 0
[vagrant@Vag2] ~/work
%

Each dots(...) mean each test.
The speed of the test is incredible.
It takes only 0.033 sec to test 13 items.

Fail

So next, we let the test fail.
Stopped the process.



[vagrant@Vag2] ~/work
% sudo systemctl stop haproxy
[vagrant@Vag2] ~/work
% sudo systemctl is-active haproxy
inactive
zsh: exit 3     sudo systemctl is-active haproxy
[vagrant@Vag2] ~/work
%

Then retry.



[vagrant@Vag2] ~/work
% goss validate
..F.........F

Failures/Skipped:

Process: haproxy: running:
Expected
    <bool>: false
to equal
    <bool>: true

Service: haproxy: running:
Expected
    <bool>: false
to equal
    <bool>: true

Total Duration: 0.051s
Count: 13, Failed: 2, Skipped: 0
zsh: exit 1     goss validate
[vagrant@Vag2] ~/work
%

As expected, process/service checks failed.

Changing format

Goss has several formats to output the result.
It has like JSON, and tap is the most human readable I think.



[vagrant@Vag2] ~/work

% goss validate --format tap

1..13

ok 1 - Group: haproxy: exists: matches expectation: [true]

ok 2 - Group: haproxy: gid: matches expectation: [188]

not ok 3 - Process: haproxy: running: doesn't match, expect: [true] found: [false]

ok 4 - User: haproxy: exists: matches expectation: [true]

ok 5 - User: haproxy: uid: matches expectation: [188]

ok 6 - User: haproxy: gid: matches expectation: [188]

ok 7 - User: haproxy: home: matches expectation: ["/var/lib/haproxy"]

ok 8 - User: haproxy: groups: matches expectation: [["haproxy"]]

ok 9 - User: haproxy: shell: matches expectation: ["/sbin/nologin"]

ok 10 - Package: haproxy: installed: matches expectation: [true]

ok 11 - Package: haproxy: version: matches expectation: [["1.5.18"]]

ok 12 - Service: haproxy: enabled: matches expectation: [true]

not ok 13 - Service: haproxy: running: doesn't match, expect: [true] found: [false]

zsh: exit 1     goss validate --format tap

[vagrant@Vag2] ~/work

%

Check with http

Goss can serve http mode and work as Healthcheck endpoint.



[vagrant@Vag2] ~/work

% goss serve &

2019/03/23 04:00:20 Starting to listen on: :8080

[vagrant@Vag2] ~/work

% curl localhost:8080/healthz

2019/03/23 04:00:23 [::1]:48704: requesting health probe

2019/03/23 04:00:23 [::1]:48704: Stale cache, running tests

..F.........F

Failures/Skipped:

Process: haproxy: running:

Expected

    <bool>: false

to equal

    <bool>: true

Service: haproxy: running:

Expected

    <bool>: false

to equal

    <bool>: true

Total Duration: 0.044s

Count: 13, Failed: 2, Skipped: 0

[vagrant@Vag2] ~/work

%

Conclusion

As I tried, Goss is extremely great since it allows us to test within a minute.
In this post, it was only a simple test but it can be applied to production environment with more customize.

I assume Ansible can be a good match with Goss when comes to production use.
Or maybe it can extend monitoring accuracy with Goss healthcheck mode.