项目作者: geerlingguy

项目描述 :
This is an example from the Ansible 101 livestream
高级语言:
项目地址: git://github.com/geerlingguy/molecule-playbook-testing.git
创建时间: 2020-05-13T15:44:06Z
项目社区:https://github.com/geerlingguy/molecule-playbook-testing

开源协议:

下载


Ansible 101 - Molecule playbook testing

This example is derived from Chapter 12 of Ansible for DevOps, version 1.23

This playbook installs Apache and should work on the latest versions of Red Hat-based and Debian-based OSes, at a minimum:

  • CentOS 8
  • Debian 10

Create a new molecule scenario:

  1. molecule init scenario

Edit the converge.yml playbook:

  1. ---
  2. - name: Converge
  3. hosts: all
  4. tasks:
  5. - name: Update apt cache (on Debian).
  6. apt:
  7. update_cache: true
  8. cache_valid_time: 3600
  9. when: ansible_os_family == 'Debian'
  10. - import_playbook: ../../main.yml

Then run:

  1. molecule converge

Uh oh… something failed. Log in and check it out:

  1. $ molecule login
  2. [root@instance /]# systemctl status httpd
  3. Failed to get D-Bus connection: Operation not permitted

Yikes, I can’t take this entire episode to explain the details of what’s going on, but at a basic level, Molecule’s default configuration sets up a container and runs the command:

  1. bash -c "while true; do sleep 10000; done"

(use docker ps to confirm that.)

Unfortunately, this means the process that’s running in this container is not systemd’s init system, meaning you can’t use systemd to manage services like Apache.

In normal container usage, this is perfectly fine—running an init system in a container is kind of an anti-best-practice.

But in our case, we’re using containers for testing. And lucky for you, I maintain a large set of Ansible testing containers that have systemd built in and ready to go! So for these tests, since we want to make sure Ansible can manage the Apache service correctly, we need to change a few things in Molecule’s molecule.yml configuration.

Go ahead and exit and destroy the environment.

  1. [root@instance /]# exit
  2. $ molecule destroy

Now edit the platforms in molecule.yml:

  1. platforms:
  2. - name: instance
  3. image: "geerlingguy/docker-${MOLECULE_DISTRO:-centos7}-ansible:latest"
  4. command: ""
  5. volumes:
  6. - /sys/fs/cgroup:/sys/fs/cgroup:ro
  7. privileged: true
  8. pre_build_image: true

Now try running it again:

  1. molecule test

Yay, it works!

Now, since we added an environment variable, MOLECULE_DISTRO, we can substitute whatever distro we want there, assuming I maintain a Docker image for that distro:

  1. MOLECULE_DISTRO=debian10 molecule test

Yay, still works!

Verify with Molecule

Now add to verify.yml:

  1. ---
  2. - name: Verify
  3. hosts: all
  4. tasks:
  5. - name: Verify Apache is serving web requests.
  6. uri:
  7. url: http://localhost/
  8. status_code: 200

You can just run the verify playbook with molecule verify.

Add lint configuration

Assuming you have yamllint and ansible-lint installed, you can configure Molecule to run them in the lint build stage:

  1. lint: |
  2. set -e
  3. yamllint .
  4. ansible-lint

Then run molecule lint. It doesn’t even need to build an environment to do the linting.

GitHub Actions Testing

Go ahead and slap this repo up on GitHub. Do it!

Now add a .github/workflows folder.

Add a ci.yml workflow file.

Here’s the whole workflow we’re targeting:

  1. ---
  2. name: CI
  3. 'on':
  4. pull_request:
  5. push:
  6. branches:
  7. - master
  8. jobs:
  9. test:
  10. name: Molecule
  11. runs-on: ubuntu-latest
  12. strategy:
  13. matrix:
  14. distro:
  15. - centos8
  16. - debian10
  17. steps:
  18. - name: Check out the codebase.
  19. uses: actions/checkout@v2
  20. - name: Set up Python 3.
  21. uses: actions/setup-python@v2
  22. with:
  23. python-version: '3.x'
  24. - name: Install test dependencies.
  25. run: pip3 install molecule docker yamllint ansible-lint
  26. - name: Run Molecule tests.
  27. run: molecule test
  28. env:
  29. PY_COLORS: '1'
  30. ANSIBLE_FORCE_COLOR: '1'
  31. MOLECULE_DISTRO: ${{ matrix.distro }}