One place for hosting & domains

      Roles

      The Ultimate Guide to WordPress User Roles


      WordPress is a powerful, flexible Content Management System (CMS) that can be an excellent solution for collaboration. However, to make the most of the CMS, it’s important to understand how to navigate and leverage its user roles and permissions features.

      WordPress user roles let you assign certain levels of access to people who are registered to your website. This can help you manage and control what tasks are possible and can ultimately help strengthen your site’s security and performance.

      In this post, we’ll explain what WordPress user roles and permissions are. Then, we’ll provide you with advice for assigning them and cover some helpful troubleshooting tips and useful plugins to help you manage your users. Let’s get started!

      An Introduction to WordPress User Roles and Permissions (And Why They’re Important)

      WordPress user roles and permissions are two different but interdependent concepts. User roles determine what a user can and can’t do on your WordPress site, based on their user type. These limitations are generalized for anyone who carries a certain user role status.

      Permissions, on the other hand, are more individualized. You can create custom permissions for specific users, and control exactly what they are allowed to do on your site. Moreover, you can give different users distinct permissions depending on their role.

      With this double-layered system, you can ensure that each user only sees and accesses the features that are appropriate for them. Furthermore, you can create custom roles with unique capabilities, which is a great way to provide additional functionality for advanced users or clients who need certain abilities not available in the default roles.

      Both user roles and permissions are set by the Administrator, which is typically the WordPress site owner. By default, there are six different user roles: Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Each role has its own set of capabilities, which we’ll discuss in more detail below.

      User roles and permissions play an important role in ensuring that your WordPress website is secure and runs smoothly. By managing these settings, you can control who has access to what areas of your site, and what they can do there.

      If someone has too many privileges, they can end up publishing low-quality content or changing settings that impact the functionality or appearance of your site. The good news is that when you implement user roles and capabilities, you can have peace of mind knowing that only trusted parties have full admin access.

      An Overview of the Default User Roles in WordPress

      Now that you know a bit about the importance of user roles, let’s take a closer look at the six default user roles you can choose from when managing your WordPress website. Keep in mind that as an Administrator, you have the ability to create new user roles and assign them to specific users on your site. You can also manage permissions for existing user roles.

      Super Admin

      The Super Admin is the highest level of user on a WordPress site. This user has complete control over the site, including the ability to add and delete users, install and activate plugins, manage themes, and more. Super Admins are typically only found on multisite installations of WordPress.

      Super Admins can manage every setting and feature for each site within a multi-site network. They can add and delete other Administrators, create new sites, and control content across each site.

      Administrator

      Administrators have complete control over a single WordPress site. They can add and delete users, install and activate plugins, manage themes, etc. Usually, they are the site owners or main authors:

       

      WordPress Dashboard

      This powerful role has complete access to content, features, and site settings. They can update the CMS as well as plugins and themes. The Admin is also responsible for assigning user roles and capabilities to other registered users. Ideally, you should only have one Administrator per website.

      Editor

      Editors can manage and publish posts and pages, as well as moderate comments. They can also schedule content and edit categories. However, they cannot install or activate plugins, or manage themes:

      WordPress Dashboard

      In a nutshell, an editor can modify content created by themselves and other users with a lower status, such as Authors and Contributors. They can’t change content for users with permissions higher than theirs, such as an Administrator. Typically, this role is reserved for content managers or similar titles.

      Author

      As you may have guessed, authors can write and publish their own posts and pages. They can also delete their own posts.  However, they cannot publish, edit, or delete anyone else’s posts. Additionally, authors cannot add or delete users, install or activate plugins, or manage themes:

      WordPress Dashboard

      Unlike Contributors, Authors have access to the WordPress Media Library. While they can edit reader comments, they can only do so on their own posts.

      Contributor

      WordPress Contributors can write and submit their own posts for review by an Administrator or Editor. Once a post is published, they cannot edit it. Furthermore, contributors cannot add or delete users, install or activate plugins, or manage themes.

      Contributors are usually roles assigned to freelance writers or guest bloggers. This role is also commonly used for new hires whose content needs editing or reviewing before it can be published on the site.

      Once submitted for review, only the Editor or Administrator can publish their posts. Contributors cannot access the Media Library.

      Subscriber

      Subscribers can manage their own profiles and read posts and pages on a WordPress site. They cannot write or publish their own posts or pages, nor can they add or delete users, install or activate plugins, or manage themes:

      WordPress User Profile Personal Options screen

      Subscribers have the fewest permissions and capabilities of all the WordPress roles. It is the default user role set for new registrations.

      There are a few additional user role options available on some WordPress sites. For example, if you’re running a WooCommerce site, Shop Managers have similar capabilities to Administrators, but with some added features specifically for managing WooCommerce stores. For instance, they can add and delete products, manage orders, and more.

      How to Manage User Roles in WordPress 

      Now that you have a better sense of what each user role can do, let’s get into how to manage them. Below, you’ll find instructions for how to add, delete, and update users and user roles in WordPress.

      1. Creating and Deleting Users in WordPress

      Before you assign a user role in WordPress, you first need to have a user to attach it to. To add a new user in WordPress, you can navigate to Users > Add New, then fill in the information. This will include details such as username, email, and password:

      WordPress add new User

      Note that, by default, the Role is automatically set to Subscriber. When you’re done, you can click on the Add New User button at the bottom of the screen.

      Alternatively, you can create a new user through your database. To do this, you can navigate to phpMyAdmin from your cPanel dashboard (or whichever system your host uses), then select your WordPress database.

      Next, locate the wp_users table (name may vary depending on your database prefix):

      phpMyAdmin user database

      Once you click on the users table, you can select the Insert tab:

      phpMyAdmin user database

      On this screen, you can enter the following credentials:

      • user_login: The username you want to assign the user.
      • user_pass: The password for the user’s account; you can select MD5 in the Function drop-down.
      • user_email: The email address you want to use.
      • user_registered: The date and time for when the user will be registered.
      • user_status: You can set this value to “0”.

      When you’re done filling out the details, you can click on the Go button at the bottom of the screen. Next, navigate back to your WordPress database, then select the wp_usermeta table, followed by the Insert tab:

      phpMyAdmin user database

      You can insert the following details in the form:

      • unmeta_id: This is autogenerated, so you can leave it blank.
      • User_id: The id of the user you created.
      • Meta_key: You can set this as “wp_capabilities”.
      • meta_value: Add this as “a:1:{s:13:”administrator”;b:1;}”

      Finally, you can add another row. Then, input the following information:

      • Unmeta_id: You can leave this blank.
      • User_id: The id of the user you created.
      • Meta_key: You can make this “wp_user_level”.
      • Meta_value: You can put this as “10”.

      When you’re finished, you can click on the Go button to save your changes.

      To find a full list of your users, you can go to Users > All Users from your admin interface:

      WordPress Users screen

      To delete a user from your WordPress dashboard, you can hover your mouse over the name of the user, then click on the Delete link. That’s it!

      You can delete a user from your WordPress database as well. To do so, log into phpMyAdmin, then navigate to the wp_users table:

      phpMyAdmin user database

      Next to each user, you’ll find an Edit, Copy, and Delete option. Simply select Delete to remove the user.

      Skip the line and get tips right in your inbox

      Click below to sign up for more how-to’s and tutorials just like this one, delivered to your inbox.

      marketing tips

      2. Adding a User Role 

      There are a few ways to create a new user role in WordPress. The easiest way is to go through the admin interface. As you may have noticed in the last section, you can assign a user role at the time of creating a new user.

      To assign or update a role to an existing user, you can navigate to User from your WordPress dashboard, then select the Edit link under the user name:

      WordPress User Editor

      At the bottom of the screen, you can select an option from the Role drop-down menu:

      WordPress select User Role Administrator

      When you’re done, you can simply select the Add New User or Update User button at the bottom of the screen.

      Another way you can add a new user role in WordPress is by manually editing your code. For instance, you can add a custom user role, such as Moderator, with the add_role() function.

      To do so, you can add the following code to your theme’s functions.php file:

      add_role( 'new_user_role', __( 'Moderator' ), array( 'read' => true, 'edit_posts' => true, 'delete_posts' => true ) );

      When you’re done, be sure to update the file to save your changes. It’s as simple as that!

      3. Deleting a User Role in WordPress

      If you want to delete a user role in WordPress so that it is no longer an option, you can do so by editing your theme’s files. Keep in mind that modifying theme files can be risky, so it’s best to create a backup of your site before you continue on.

      To get started, go to Appearance > Theme File Editor in your WordPress dashboard. Next, locate and open the Theme Functions file:

      WordPress Theme Editor

      In this file, you can add one (or all) of the following code snippets, depending on which user role(s) you want to remove:

      remove_role( 'subscriber' );
      remove_role( 'editor' );
      remove_role( 'contributor' );
      remove_role( 'author' );

      When you’re done, select the Update File to save your changes.

      4. Updating Existing User Roles and Permissions

      If you want to update an existing user’s permissions, you can select the Edit link from the User list. You can then scroll to the bottom of the screen and modify the role by selecting a new one from the User Role drop-down menu. Remember to save your changes.

      Another option is to use a plugin, such as User Role Editor:

      WordPress User Role editor plugin

      This free version of this tool lets you easily change user roles and capabilities. Once installed and activated on your site, you can browse to Users > User Role Editor:

      WordPress User Role Editor

      Next, you can select the checkboxes of the capabilities you want to allow the selected role to have. When you’re done, click on the Update button at the bottom of the screen to save your changes.

      The plugin also lets you add new roles or delete ones that you aren’t using. It even lets you assign capabilities on a per-user basis.

      Tips for Picking the Right User Roles and Permissions

      As a general rule of thumb, it’s a smart idea to set the user role as low as possible. In other words, you want to give users as few permissions as possible that won’t interfere with or impact their ability to do their assigned tasks.

      Selecting the roles for your users should be based on the level of access that’s necessary.There are also specific roles for certain use cases.

      For example, if you have a full-time writer for your WordPress website, you can assign them the Author role. They’ll be able to write, draft, and publish posts on your site, as well as access the Media Library. However, they won’t be able to access, edit, or delete other pages and posts. Therefore, if this is a necessary capability, you may want to assign them the Editor role.

      On the other hand, if you have a freelance writer or a new hire that you don’t want to give publishing privileges to, you can make them a Contributor. This will let them write pages and posts, but they won’t be able to publish them. They can only submit it to the Editor (or Admin) for review.

      Consider assigning the Contributor role to anyone that doesn’t work in-house. We also recommend having as few Administrators as possible. This can help safeguard your site and prevent errors.

      If you have a multi-site installation, it’s a good idea to have one Super Admin. That way, they can handle any security or site issues that arise on any of the sites without interference or confusion from other admins. However, you could assign a single Administrator or Editor for each of the sites within your multisite network.

      Troubleshooting WordPress User Role and Permission Issues

      WordPress user roles and permissions are relatively straightforward and easy to use. However, sometimes issues arise, which can make it difficult for users with certain roles or permissions to carry out their tasks properly.

      One of the most common is being locked out of your WordPress admin and encountering a page with the message “Sorry, you are not allowed to access this page”. This error can be frustrating because it can be challenging to nail down the cause of it.

      However, if you see this message it’s likely because there’s a permission setting that is preventing you from accessing a certain area for security purposes. If you’re an Administrator or should have access, there are a few potential solutions you can try out.

      If this issue occurred directly after a WordPress update, restore the previous version of your site. Next, you can try disabling all of your plugins and re-enabling them one-by-one. You can also try activating a default WordPress theme. These steps can help you narrow down the source of the notification.

      Alternatively, you can check to ensure that you have the necessary Administrator privileges. To do this, navigate to phpMyAdmin then to the wp_users table.

      Next, locate your username and make a note of your ID. Browse to the wp_usermeta table and locate your metauser ID:

      phpMyAdmin user database

      Under the Metavalue column, it should read as the following:

      A:1:{s:13:"administrator";s:1:"1";}

      If there is something else in this field, we recommend editing it to replace it with the above. Simply save your changes when you’re done.

      Useful WordPress User Role and Permissions Plugins

      At this point, you likely understand the various settings and options you have for changing user roles and permissions in WordPress. However, to make the process even easier, you might consider using a plugin.

      We already discussed the User Role Editor plugin, but there are a handful of additional options to choose from. Below, we’ll take a look at some of the most popular ones and explain what you can use them for.

      Members

      Members is a plugin that lets you manage the permissions of registered users:

      MemberPress

      It’s beginner-friendly, boasting an intuitive interface that is easy to navigate. You can use it to create new roles and add permissions to each one. You can also clone user roles and customize the permissions for blog content.

      PublishPress Capabilities

      PublishPress Capabilities is another useful tool that can help you gain more control over your user roles:

      PublishPress

      It lets you add new roles, clone existing ones, and add individual permissions for each role. You can also backup, migrate, and restore the permissions. It can be used for single websites or on multisite networks. The plugin also integrates seamlessly with WooCommerce, which is helpful for store and product management.

      WPFront User Role Editor

      WPFront User Role Editor is a popular plugin you can use for managing user roles in WordPress:

      WPFront

      You can use it to create, delete, and modify user permissions. You can add new names for roles and clone existing ones. It also lets you assign multiple roles to users.

      Take Control of User Role Management on Your WordPress Site

      If you’re looking to manage WordPress user roles and permissions, it’s important to understand the different capabilities associated with each role. With this information, you can better manage your site and ensure that users have the appropriate level of access to your content and features.

      Whether you’re managing a simple blog or creating a complex website with multiple authors, user permissions are an important part of WordPress. With the right set of permissions in place, you can ensure that your site remains secure and runs smoothly.

      Are you interested in learning about more ways you can make managing your WordPress site as simple as possible? Check out our Managed WordPress Hosting solutions to learn about DreamPress!

      Do More with DreamPress

      DreamPress’ automatic updates, caching, and strong security defenses take server management off your hands so you can focus on content creation.

      Managed WordPress Hosting - DreamPress



      Source link

      How To Implement Continuous Testing of Ansible Roles Using Molecule and Travis CI on Ubuntu 18.04


      The author selected the Mozilla Foundation to receive a donation as part of the Write for DOnations program.

      Introduction

      Ansible is an agentless configuration management tool that uses YAML templates to define a list of tasks to be performed on hosts. In Ansible, roles are a collection of variables, tasks, files, templates and modules that are used together to perform a singular, complex function.

      Molecule is a tool for performing automated testing of Ansible roles, specifically designed to support the development of consistently well-written and maintained roles. Molecule’s unit tests allow developers to test roles simultaneously against multiple environments and under different parameters. It’s important that developers continuously run tests against code that often changes; this workflow ensures that roles continue to work as you update code libraries. Running Molecule using a continuous integration tool, like Travis CI, allows for tests to run continuously, ensuring that contributions to your code do not introduce breaking changes.

      In this tutorial, you will use a pre-made base role that installs and configures an Apache web server and a firewall on Ubuntu and CentOS servers. Then, you will initialize a Molecule scenario in that role to create tests and ensure that the role performs as intended in your target environments. After configuring Molecule, you will use Travis CI to continuously test your newly created role. Every time a change is made to your code, Travis CI will run molecule test to make sure that the role still performs correctly.

      Prerequisites

      Before you begin this tutorial, you will need:

      Step 1 — Forking the Base Role Repository

      You will be using a pre-made role called ansible-apache that installs Apache and configures a firewall on Debian- and Red Hat-based distributions. You will fork and use this role as a base and then build Molecule tests on top of it. Forking allows you to create a copy of a repository so you can make changes to it without tampering with the original project.

      Start by creating a fork of the ansible-apache role. Go to the ansible-apache repository and click on the Fork button.

      Once you have forked the repository, GitHub will lead you to your fork’s page. This will be a copy of the base repository, but on your own account.

      Click on the green Clone or Download button and you’ll see a box with Clone with HTTPS.

      Copy the URL shown for your repository. You’ll use this in the next step. The URL will be similar to this:

      https://github.com/username/ansible-apache.git
      

      You will replace username with your GitHub username.

      With your fork set up, you will clone it on your server and begin preparing your role in the next section.

      Step 2 — Preparing Your Role

      Having followed Step 1 of the prerequisite How To Test Ansible Roles with Molecule on Ubuntu 18.04, you will have Molecule and Ansible installed in a virtual environment. You will use this virtual environment for developing your new role.

      First, activate the virtual environment you created while following the prerequisites by running:

      • source my_env/bin/activate

      Run the following command to clone the repository using the URL you just copied in Step 1:

      • git clone https://github.com/username/ansible-apache.git

      Your output will look similar to the following:

      Output

      Cloning into 'ansible-apache'... remote: Enumerating objects: 16, done. remote: Total 16 (delta 0), reused 0 (delta 0), pack-reused 16 Unpacking objects: 100% (16/16), done.

      Move into the newly created directory:

      The base role you've downloaded performs the following tasks:

      • Includes variables: The role starts by including all the required variables according to the distribution of the host. Ansible uses variables to handle the disparities between different systems. Since you are using Ubuntu 18.04 and CentOS 7 as hosts, the role will recognize that the OS families are Debian and Red Hat respectively and include variables from vars/Debian.yml and vars/RedHat.yml.

      • Includes distribution-relevant tasks: These tasks include tasks/install-Debian.yml and tasks/install-RedHat.yml. Depending on the specified distribution, it installs the relevant packages. For Ubuntu, these packages are apache2 and ufw. For CentOS, these packages are httpd and firewalld.

      • Ensures latest index.html is present: This task copies over a template templates/index.html.j2 that Apache will use as the web server's home page.

      • Starts relevant services and enables them on boot: Starts and enables the required services installed as part of the first task. For CentOS, these services are httpd and firewalld, and for Ubuntu, they are apache2 and ufw.

      • Configures firewall to allow traffic: This includes either tasks/configure-Debian-firewall.yml or tasks/configure-RedHat-firewall.yml. Ansible configures either Firewalld or UFW as the firewall and whitelists the http service.

      Now that you have an understanding of how this role works, you will configure Molecule to test it. You will write test cases for these tasks that cover the changes they make.

      Step 3 — Writing Your Tests

      To check that your base role performs its tasks as intended, you will start a Molecule scenario, specify your target environments, and create three custom test files.

      Begin by initializing a Molecule scenario for this role using the following command:

      • molecule init scenario -r ansible-apache

      You will see the following output:

      Output

      --> Initializing new scenario default... Initialized scenario in /home/sammy/ansible-apache/molecule/default successfully.

      You will add CentOS and Ubuntu as your target environments by including them as platforms in your Molecule configuration file. To do this, edit the molecule.yml file using a text editor:

      • nano molecule/default/molecule.yml

      Add the following highlighted content to the Molecule configuration:

      ~/ansible-apache/molecule/default/molecule.yml

      ---
      dependency:
        name: galaxy
      driver:
        name: docker
      lint:
        name: yamllint
      platforms:
        - name: centos7
          image: milcom/centos7-systemd
          privileged: true
        - name: ubuntu18
          image: solita/ubuntu-systemd
          command: /sbin/init
          privileged: true
          volumes:
            - /lib/modules:/lib/modules:ro
      provisioner:
        name: ansible
        lint:
          name: ansible-lint
      scenario:
        name: default
      verifier:
        name: testinfra
        lint:
          name: flake8
      

      Here, you're specifying two target platforms that are launched in privileged mode since you're working with systemd services:

      • centos7 is the first platform and uses the milcom/centos7-systemd image.
      • ubuntu18 is the second platform and uses the solita/ubuntu-systemd image. In addition to using privileged mode and mounting the required kernel modules, you're running /sbin/init on launch to make sure iptables is up and running.

      Save and exit the file.

      For more information on running privileged containers visit the official Molecule documentation.

      Instead of using the default Molecule test file, you will be creating three custom test files, one for each target platform, and one file for writing tests that are common between all platforms. Start by deleting the scenario's default test file test_default.py with the following command:

      • rm molecule/default/tests/test_default.py

      You can now move on to creating the three custom test files, test_common.py, test_Debian.py, and test_RedHat.py for each of your target platforms.

      The first test file, test_common.py, will contain the common tests that each of the hosts will perform. Create and edit the common test file, test_common.py:

      • nano molecule/default/tests/test_common.py

      Add the following code to the file:

      ~/ansible-apache/molecule/default/tests/test_common.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')
      
      
      @pytest.mark.parametrize('file, content', [
        ("/var/www/html/index.html", "Managed by Ansible")
      ])
      def test_files(host, file, content):
          file = host.file(file)
      
          assert file.exists
          assert file.contains(content)
      

      In your test_common.py file, you have imported the required libraries. You have also written a test called test_files(), which holds the only common task between distributions that your role performs: copying your template as the web servers homepage.

      The next test file, test_Debian.py, holds tests specific to Debian distributions. This test file will specifically target your Ubuntu platform.

      Create and edit the Ubuntu test file by running the following command:

      • nano molecule/default/tests/test_Debian.py

      You can now import the required libraries and define the ubuntu18 platform as the target host. Add the following code to the start of this file:

      ~/ansible-apache/molecule/default/tests/test_Debian.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('ubuntu18')
      

      Then, in the same file, you'll add test_pkg() test.

      Add the following code to the file, which defines the test_pkg() test:

      ~/ansible-apache/molecule/default/tests/test_Debian.py

      ...
      @pytest.mark.parametrize('pkg', [
          'apache2',
          'ufw'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
          assert package.is_installed
      

      This test will check if apache2 and ufw packages are installed on the host.

      Note: When adding multiple tests to a Molecule test file, make sure there are two blank lines between each test or you'll get a syntax error from Molecule.

      To define the next test, test_svc(), add the following code under the test_pkg() test in your file:

      ~/ansible-apache/molecule/default/tests/test_Debian.py

      ...
      @pytest.mark.parametrize('svc', [
          'apache2',
          'ufw'
      ])
      def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      

      test_svc() will check if the apache2 and ufw services are running and enabled.

      Finally you will add your last test, test_ufw_rules(), to the test_Debian.py file.

      Add this code under the test_svc() test in your file to define test_ufw_rules():

      ~/ansible-apache/molecule/default/tests/test_Debian.py

      ...
      @pytest.mark.parametrize('rule', [
          '-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT'
      ])
      def test_ufw_rules(host, rule):
          cmd = host.run('iptables -t filter -S')
      
          assert rule in cmd.stdout
      

      test_ufw_rules() will check that your firewall configuration permits traffic on the port used by the Apache service.

      With each of these tests added, your test_Debian.py file will look like this:

      ~/ansible-apache/molecule/default/tests/test_Debian.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('ubuntu18')
      
      
      @pytest.mark.parametrize('pkg', [
          'apache2',
          'ufw'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
          assert package.is_installed
      
      
      @pytest.mark.parametrize('svc', [
          'apache2',
          'ufw'
      ])
      def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      
      
      @pytest.mark.parametrize('rule', [
          '-A ufw-user-input -p tcp -m tcp --dport 80 -j ACCEPT'
      ])
      def test_ufw_rules(host, rule):
          cmd = host.run('iptables -t filter -S')
      
          assert rule in cmd.stdout
      

      The test_Debian.py file now includes the three tests: test_pkg(), test_svc(), and test_ufw_rules().

      Save and exit test_Debian.py.

      Next you'll create the test_RedHat.py test file, which will contain tests specific to Red Hat distributions to target your CentOS platform.

      Create and edit the CentOS test file, test_RedHat.py, by running the following command:

      • nano molecule/default/tests/test_RedHat.py

      Similarly to the Ubuntu test file, you will now write three tests to include in your test_RedHat.py file. Before adding the test code, you can import the required libraries and define the centos7 platform as the target host, by adding the following code to the beginning of your file:

      ~/ansible-apache/molecule/default/tests/test_RedHat.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('centos7')
      

      Then, add the test_pkg() test, which will check if the httpd and firewalld packages are installed on the host.

      Following the code for your library imports, add the test_pkg() test to your file. (Again, remember to include two blank lines before each new test.)

      ~/ansible-apache/molecule/default/tests/test_RedHat.py

      ...
      @pytest.mark.parametrize('pkg', [
          'httpd',
          'firewalld'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
            assert package.is_installed
      

      Now, you can add the test_svc() test to ensure that httpd and firewalld services are running and enabled.

      Add the test_svc() code to your file following the test_pkg() test:

      ~/ansible-apache/molecule/default/tests/test_RedHat.py

      ...
      @pytest.mark.parametrize('svc', [
          'httpd',
          'firewalld'
      ])
        def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      

      The final test in test_RedHat.py file will be test_firewalld(), which will check if Firewalld has the http service whitelisted.

      Add the test_firewalld() test to your file after the test_svc() code:

      ~/ansible-apache/molecule/default/tests/test_RedHat.py

      ...
      @pytest.mark.parametrize('file, content', [
          ("/etc/firewalld/zones/public.xml", "<service name="http"/>")
      ])
      def test_firewalld(host, file, content):
          file = host.file(file)
      
          assert file.exists
          assert file.contains(content)
      

      After importing the libraries and adding the three tests, your test_RedHat.py file will look like this:

      ~/ansible-apache/molecule/default/tests/test_RedHat.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('centos7')
      
      
      @pytest.mark.parametrize('pkg', [
          'httpd',
          'firewalld'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
          assert package.is_installed
      
      
      @pytest.mark.parametrize('svc', [
          'httpd',
          'firewalld'
      ])
      def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      
      
      @pytest.mark.parametrize('file, content', [
          ("/etc/firewalld/zones/public.xml", "<service name="http"/>")
      ])
      def test_firewalld(host, file, content):
          file = host.file(file)
      
          assert file.exists
          assert file.contains(content)
      

      Now that you've completed writing tests in all three files, test_common.py, test_Debian.py, and test_RedHat.py, your role is ready for testing. In the next step, you will use Molecule to run these tests against your newly configured role.

      Step 4 — Testing Against Your Role

      You will now execute your newly created tests against the base role ansible-apache using Molecule. To run your tests, use the following command:

      You'll see the following output once Molecule has finished running all the tests:

      Output

      ... --> Scenario: 'default' --> Action: 'verify' --> Executing Testinfra tests found in /home/sammy/ansible-apache/molecule/default/tests/... ============================= test session starts ============================== platform linux -- Python 3.6.7, pytest-4.1.1, py-1.7.0, pluggy-0.8.1 rootdir: /home/sammy/ansible-apache/molecule/default, inifile: plugins: testinfra-1.16.0 collected 12 items tests/test_common.py .. [ 16%] tests/test_RedHat.py ..... [ 58%] tests/test_Debian.py ..... [100%] ========================== 12 passed in 80.70 seconds ========================== Verifier completed successfully.

      You'll see Verifier completed successfully in your output; this means that the verifier executed all of your tests and returned them successfully.

      Now that you've successfully completed the development of your role, you can commit your changes to Git and set up Travis CI for continuous testing.

      Step 5 — Using Git to Share Your Updated Role

      In this tutorial, so far, you have cloned a role called ansible-apache and added tests to it to make sure it works against Ubuntu and CentOS hosts. To share your updated role with the public, you must commit these changes and push them to your fork.

      Run the following command to add the files and commit the changes you've made:

      This command will add all the files that you have modified in the current directory to the staging area.

      You also need to set your name and email address in the git config in order to commit successfully. You can do so using the following commands:

      • git config user.email "sammy@digitalocean.com"
      • git config user.name "John Doe"

      Commit the changed files to your repository:

      • git commit -m "Configured Molecule"

      You'll see the following output:

      Output

      [master b2d5a5c] Configured Molecule 8 files changed, 155 insertions(+), 1 deletion(-) create mode 100644 molecule/default/Dockerfile.j2 create mode 100644 molecule/default/INSTALL.rst create mode 100644 molecule/default/molecule.yml create mode 100644 molecule/default/playbook.yml create mode 100644 molecule/default/tests/test_Debian.py create mode 100644 molecule/default/tests/test_RedHat.py create mode 100644 molecule/default/tests/test_common.py

      This signifies that you have committed your changes successfully. Now, push these changes to your fork with the following command:

      • git push -u origin master

      You will see a prompt for your GitHub credentials. After entering these credentials, your code will be pushed to your repository and you'll see this output:

      Output

      Counting objects: 13, done. Compressing objects: 100% (12/12), done. Writing objects: 100% (13/13), 2.32 KiB | 2.32 MiB/s, done. Total 13 (delta 3), reused 0 (delta 0) remote: Resolving deltas: 100% (3/3), completed with 2 local objects. To https://github.com/username/ansible-apache.git 009d5d6..e4e6959 master -> master Branch 'master' set up to track remote branch 'master' from 'origin'.

      If you go to your fork's repository at github.com/username/ansible-apache, you'll see a new commit called Configured Molecule reflecting the changes you made in the files.

      Now, you can integrate Travis CI with your new repository so that any changes made to your role will automatically trigger Molecule tests. This will ensure that your role always works with Ubuntu and CentOS hosts.

      Step 6 — Integrating Travis CI

      In this step, you're going to integrate Travis CI into your workflow. Once enabled, any changes you push to your fork will trigger a Travis CI build. The purpose of this is to ensure Travis CI always runs molecule test whenever contributors make changes. If any breaking changes are made, Travis will declare the build status as such.

      Proceed to Travis CI to enable your repository. Navigate to your profile page where you can click the Activate button for GitHub.

      You can find further guidance here on activating repositories in Travis CI.

      For Travis CI to work, you must create a configuration file containing instructions for it. To create the Travis configuration file, return to your server and run the following command:

      To duplicate the environment you've created in this tutorial, you will specify parameters in the Travis configuration file. Add the following content to your file:

      ~/ansible-apache/.travis.yml

      ---
      language: python
      python:
        - "2.7"
        - "3.6"
      services:
        - docker
      install:
        - pip install molecule docker
      script:
        - molecule --version
        - ansible --version
        - molecule test
      

      The parameters you've specified in this file are:

      • language: When you specify Python as the language, the CI environment uses separate virtualenv instances for each Python version you specify under the python key.
      • python: Here, you're specifying that Travis will use both Python 2.7 and Python 3.6 to run your tests.
      • services: You need Docker to run tests in Molecule. You're specifying that Travis should ensure Docker is present in your CI environment.
      • install: Here, you're specifying preliminary installation steps that Travis CI will carry out in your virtualenv.
        • pip install molecule docker to check that Ansible and Molecule are present along with the Python library for the Docker remote API.
      • script: This is to specify the steps that Travis CI needs to carry out. In your file, you're specifying three steps:
        • molecule --version prints the Molecule version if Molecule has been successfully installed.
        • ansible --version prints the Ansible version if Ansible has been successfully installed.
        • molecule test finally runs your Molecule tests.

      The reason you specify molecule --version and ansible --version is to catch errors in case the build fails as a result of ansible or molecule misconfiguration due to versioning.

      Once you've added the content to the Travis CI configuration file, save and exit .travis.yml.

      Now, every time you push any changes to your repository, Travis CI will automatically run a build based on the above configuration file. If any of the commands in the script block fail, Travis CI will report the build status as such.

      To make it easier to see the build status, you can add a badge indicating the build status to the README of your role. Open the README.md file using a text editor:

      Add the following line to the README.md to display the build status:

      ~/ansible-apache/README.md

      [![Build Status](https://travis-ci.org/username/ansible-apache.svg?branch=master)](https://travis-ci.org/username/ansible-apache)
      

      Replace username with your GitHub username. Commit and push the changes to your repository as you did earlier.

      First, run the following command to add .travis.yml and README.md to the staging area:

      • git add .travis.yml README.md

      Now commit the changes to your repository by executing:

      • git commit -m "Configured Travis"

      Finally, push these changes to your fork with the following command:

      • git push -u origin master

      If you navigate over to your GitHub repository, you will see that it initially reports build: unknown.

      build-status-unknown

      Within a few minutes, Travis will initiate a build that you can monitor at the Travis CI website. Once the build is a success, GitHub will report the status as such on your repository as well — using the badge you've placed in your README file:

      build-status-passing

      You can access the complete details of the builds by going to the Travis CI website:

      travis-build-status

      Now that you've successfully set up Travis CI for your new role, you can continuously test and integrate changes to your Ansible roles.

      Conclusion

      In this tutorial, you forked a role that installs and configures an Apache web server from GitHub and added integrations for Molecule by writing tests and configuring these tests to work on Docker containers running Ubuntu and CentOS. By pushing your newly created role to GitHub, you have allowed other users to access your role. When there are changes to your role by contributors, Travis CI will automatically run Molecule to test your role.

      Once you're comfortable with the creation of roles and testing them with Molecule, you can integrate this with Ansible Galaxy so that roles are automatically pushed once the build is successful.



      Source link

      How To Test Ansible Roles with Molecule on Ubuntu 18.04


      The author selected the Mozilla Foundation to receive a donation as part of the Write for DOnations program.

      Introduction

      Unit testing in Ansible is key to making sure roles function as intended. Molecule makes this process easier by allowing you to specify scenarios that test roles against different environments. Using Ansible under the hood, Molecule offloads roles to a provisioner that deploys the role in a configured environment and calls a verifier (such as Testinfra) to check for configuration drift. This ensures that your role has made all of the expected changes to the environment in that particular scenario.

      In this guide, you will build an Ansible role that deploys Apache to a host and configures firewalld on CentOS 7. To test that this role works as intended, you will create a test in Molecule using Docker as a driver and Testinfra, a Python library for testing the state of servers. Molecule will provision Docker containers to test the role and Testinfra will verify that the server has been configured as intended. When you’re finished, you’ll be able to create multiple test cases for builds across environments and run these tests using Molecule.

      Prerequisites

      Before you begin this guide you’ll need the following:

      Step 1 — Preparing the Environment

      If you’ve followed the prerequisites, you should have Python 3, venv, and Docker installed and correctly configured. Let’s begin by creating a virtual environment to test Ansible with Molecule.

      Start by logging in as your non-root user and creating a new virtual environment:

      Activate it to ensure that your actions are restricted to that environment:

      • source my_env/bin/activate

      Next, in your activated environment, install the wheel package, which provides the bdist_wheel setuptools extension that pip uses to install Ansible:

      • python3 -m pip install wheel

      You can now install molecule and docker with pip. Ansible will be automatically installed as a dependency for Molecule:

      • python3 -m pip install molecule docker

      Here is what each of these packages will do:

      • molecule: This is the main Molecule package that you will use to test roles. Installing molecule automatically installs Ansible, along with other dependencies, and enables the use of Ansible playbooks to execute roles and tests.
      • docker: This Python library is used by Molecule to interface with Docker. You will need this since you're using Docker as a driver.

      Next, let's create a role in Molecule.

      Step 2 — Creating a Role in Molecule

      With your environment set up, you can use Molecule to create a basic role that you will use to test an installation of Apache. This role will create the directory structure and some initial tests, and specify Docker as the driver so that Molecule uses Docker to run its tests.

      Create a new role called ansible-apache:

      • molecule init role -r ansible-apache -d docker

      The -r flag specifies the name of the role while -d specifies the driver, which provisions the hosts for Molecule to use in testing.

      Change into the directory of the newly created role:

      Test the default role to check if Molecule has been set up properly:

      You will see output that lists each of the default test actions. Before starting the test, Molecule validates the configuration file molecule.yml to make sure everything is in order. It also prints this test matrix, which specifies the order of test actions:

      Output

      --> Validating schema /home/sammy/ansible-apache/molecule/default/molecule.yml. Validation completed successfully. --> Test matrix └── default ├── lint ├── destroy ├── dependency ├── syntax ├── create ├── prepare ├── converge ├── idempotence ├── side_effect ├── verify └── destroy ...

      We will discuss each test action in detail once you've created your role and customized your tests. For now, pay attention to the PLAY_RECAP for each test, and be sure that none of the default actions returns a failed status. For example, the PLAY_RECAP for the default 'create' action should look like this:

      Output

      ... PLAY RECAP ********************************************************************* localhost : ok=5 changed=4 unreachable=0 failed=0

      Let's move on to modifying the role to configure Apache and firewalld.

      Step 3 — Configuring Apache and Firewalld

      To configure Apache and firewalld, you will create a tasks file for the role, specifying packages to install and services to enable. These details will be extracted from a variables file and template that you will use to replace the default Apache index page.

      Still in the ansible-apache directory, create a tasks file for the role using nano or your favorite text editor:

      You'll see that the file already exists. Delete what's there and replace it with the following code to install the required packages and enable the correct services, HTML defaults, and firewall settings:

      ~/ansible-apache/tasks/main.yml

      ---
      - name: "Ensure required packages are present"
        yum:
          name: "{{ pkg_list }}"
          state: present
      
      - name: "Ensure latest index.html is present"
        template:
          src: index.html.j2
          dest: /var/www/html/index.html
      
      - name: "Ensure httpd service is started and enabled"
        service:
          name: "{{ item }}"
          state: started
          enabled: true
        with_items: "{{ svc_list }}"
      
      - name: "Whitelist http in firewalld"
        firewalld:
          service: http
          state: enabled
          permanent: true
          immediate: true
      

      This playbook includes 4 tasks:

      • "Ensure required packages are present": This task will install the packages listed in the variables file under pkg_list. The variables file will be located at ~/ansible-apache/vars/main.yml and you will create it at the end of this step.
      • "Ensure latest index.html is present": This task will copy a template page, index.html.j2, and paste it over the default index file, /var/www/html/index.html, generated by Apache. You will also create the new template in this step.
      • "Ensure httpd service is started and enabled": This task will start and enable the services listed in svc_list in the variables file.
      • "Whitelist http in firewalld": This task will whitelist the http service in firewalld. Firewalld is a complete firewall solution present by default on CentOS servers. For the http service to work, you will need to expose the required ports. Instructing firewalld to whitelist a service ensures that it whitelists all of the ports that the service requires.

      Save and close the file when you are finished.

      Next, let's create a templates directory for the index.html.j2 template page:

      Create the page itself:

      • nano templates/index.html.j2

      Paste in the following boilerplate code:

      ~/ansible-apache/templates/index.html.j2

      <div style="text-align: center">
          <h2>Managed by Ansible</h2>
      </div>
      

      Save and close the file.

      The final step in completing the role is writing the variables file, which provides the names of packages and services to our main role playbook:

      Paste over the default content with the following code, which specifies pkg_list and svc_list:

      ~/ansible-apache/vars/main.yml

      ---
      pkg_list:
        - httpd
        - firewalld
      svc_list:
        - httpd
        - firewalld
      

      These lists contain the following information:

      • pkg_list: This contains the names of the packages that the role will install: httpd and firewalld.
      • svc_list: This contains the names of the services that the role will start and enable: httpd and firewalld.

      Note: Make sure that your variables file doesn't have any blank lines or your test will fail during linting.

      Now that you've finished creating your role, let's configure Molecule to test if it works as intended.

      Step 4 — Modifying the Role for Running Tests

      In our case, configuring Molecule involves modifying the Molecule configuration file molecule.yml to add platform specifications. Because you're testing a role that configures and starts the httpd systemd service, you will need to use an image with systemd configured and privileged mode enabled. For this tutorial, you will use the milcom/centos7-systemd image available on Docker Hub. Privileged mode allows containers to run with almost all of the capabilities of their host machine.

      Let's edit molecule.yml to reflect these changes:

      • nano molecule/default/molecule.yml

      Add the highlighted platform information:

      ~/ansible-apache/molecule/default/molecule.yml

      ---
      dependency:
        name: galaxy
      driver:
        name: docker
      lint:
        name: yamllint
      platforms:
        - name: centos7
          image: milcom/centos7-systemd
          privileged: true
      provisioner:
        name: ansible
        lint:
          name: ansible-lint
      scenario:
        name: default
      verifier:
        name: testinfra
        lint:
          name: flake8
      

      Save and close the file when you are done.

      Now that you've successfully configured the test environment, let's move on to writing the test cases that Molecule will run against your container after executing the role.

      Step 5 — Writing Test Cases

      In the test for this role, you will check the following conditions:

      • That the httpd and firewalld packages are installed.
      • That the httpd and firewalld services are running and enabled.
      • That the http service is enabled in your firewall settings.
      • That index.html contains the same data specified in your template file.

      If all of these tests pass, then the role works as intended.

      To write the test cases for these conditions, let's edit the default tests in ~/ansible-apache/molecule/default/tests/test_default.py. Using Testinfra, we will write the test cases as Python functions that use Molecule classes.

      Open test_default.py:

      • nano molecule/default/tests/test_default.py

      Delete the contents of the file so that you can write the tests from scratch.

      Note: As you write your tests, make sure that they are separated by two new lines or they will fail.

      Start by importing the required Python modules:

      ~/ansible-apache/molecule/default/tests/test_default.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      

      These modules include:

      • os: This built-in Python module enables operating-system-dependent functionality, making it possible for Python to interface with the underlying operating system.
      • pytest: The pytest module enables test writing.
      • testinfra.utils.ansible_runner: This Testinfra module uses Ansible as the backend for command execution.

      Under the module imports, add the following code, which uses the Ansible backend to return the current host instance:

      ~/ansible-apache/molecule/default/tests/test_default.py

      ...
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')
      

      With your test file configured to use the Ansible backend, let's write unit tests to test the state of the host.

      The first test will ensure that httpd and firewalld are installed:

      ~/ansible-apache/molecule/default/tests/test_default.py

      ...
      
      @pytest.mark.parametrize('pkg', [
        'httpd',
        'firewalld'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
          assert package.is_installed
      

      The test begins with the pytest.mark.parametrize decorator, which allows us to parameterize the arguments for the test. This first test will take test_pkg as a parameter to test for the presence of the httpd and firewalld packages.

      The next test checks whether or not httpd and firewalld are running and enabled. It takes test_svc as a parameter:

      ~/ansible-apache/molecule/default/tests/test_default.py

      ...
      
      @pytest.mark.parametrize('svc', [
        'httpd',
        'firewalld'
      ])
      def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      

      The last test checks that the files and contents passed to parametrize() exist. If the file isn't created by your role and the content isn't set properly, assert will return False:

      ~/ansible-apache/molecule/default/tests/test_default.py

      ...
      
      @pytest.mark.parametrize('file, content', [
        ("/etc/firewalld/zones/public.xml", "<service name="http"/>"),
        ("/var/www/html/index.html", "Managed by Ansible")
      ])
      def test_files(host, file, content):
          file = host.file(file)
      
          assert file.exists
          assert file.contains(content)
      

      In each test, assert will return True or False depending on the test result.

      The finished file looks like this:

      ~/ansible-apache/molecule/default/tests/test_default.py

      import os
      import pytest
      
      import testinfra.utils.ansible_runner
      
      testinfra_hosts = testinfra.utils.ansible_runner.AnsibleRunner(
          os.environ['MOLECULE_INVENTORY_FILE']).get_hosts('all')
      
      
      @pytest.mark.parametrize('pkg', [
        'httpd',
        'firewalld'
      ])
      def test_pkg(host, pkg):
          package = host.package(pkg)
      
          assert package.is_installed
      
      
      @pytest.mark.parametrize('svc', [
        'httpd',
        'firewalld'
      ])
      def test_svc(host, svc):
          service = host.service(svc)
      
          assert service.is_running
          assert service.is_enabled
      
      
      @pytest.mark.parametrize('file, content', [
        ("/etc/firewalld/zones/public.xml", "<service name="http"/>"),
        ("/var/www/html/index.html", "Managed by Ansible")
      ])
      def test_files(host, file, content):
          file = host.file(file)
      
          assert file.exists
          assert file.contains(content)
      

      Now that you've specified your test cases, let's test the role.

      Step 6 — Testing the Role with Molecule

      Once you initiate the test, Molecule will execute the actions you defined in your scenario. Let's now run the default molecule scenario again, executing the actions in the default test sequence while looking more closely at each.

      Run the test for the default scenario again:

      This will initiate the test run. The initial output prints the default test matrix:

      Output

      --> Validating schema /home/sammy/ansible-apache/molecule/default/molecule.yml. Validation completed successfully. --> Test matrix └── default ├── lint ├── destroy ├── dependency ├── syntax ├── create ├── prepare ├── converge ├── idempotence ├── side_effect ├── verify └── destroy

      Let's go through each test action and the expected output, starting with linting.

      The linting action executes yamllint, flake8, and ansible-lint:

      • yamllint: This linter is executed on all YAML files present in the role directory.
      • flake8: This Python code linter checks tests created for Testinfra.
      • ansible-lint: This linter for Ansible playbooks is executed in all scenarios.

      Output

      ... --> Scenario: 'default' --> Action: 'lint' --> Executing Yamllint on files found in /home/sammy/ansible-apache/... Lint completed successfully. --> Executing Flake8 on files found in /home/sammy/ansible-apache/molecule/default/tests/... Lint completed successfully. --> Executing Ansible Lint on /home/sammy/ansible-apache/molecule/default/playbook.yml... Lint completed successfully.

      The next action, destroy, is executed using the destroy.yml file. This is done to test our role on a newly created container.

      By default, destroy is called twice: at the start of the test run, to delete any pre-existing containers, and at the end, to delete the newly created container:

      Output

      ... --> Scenario: 'default' --> Action: 'destroy' PLAY [Destroy] ***************************************************************** TASK [Destroy molecule instance(s)] ******************************************** changed: [localhost] => (item=None) changed: [localhost] TASK [Wait for instance(s) deletion to complete] ******************************* ok: [localhost] => (item=None) ok: [localhost] TASK [Delete docker network(s)] ************************************************ skipping: [localhost] PLAY RECAP ********************************************************************* localhost : ok=2 changed=1 unreachable=0 failed=0

      After the destroy action is complete, the test will move on to dependency. This action allows you to pull dependencies from ansible-galaxy if your role requires them. In this case, our role does not:

      Output

      ... --> Scenario: 'default' --> Action: 'dependency' Skipping, missing the requirements file.

      The next test action is a syntax check, which is executed on the default playbook.yml playbook. It works in a similar way to the --syntax-check flag in the command ansible-playbook --syntax-check playbook.yml:

      Output

      ... --> Scenario: 'default' --> Action: 'syntax' playbook: /home/sammy/ansible-apache/molecule/default/playbook.yml

      Next, the test moves on to the create action. This uses the create.yml file in your role's Molecule directory to create a Docker container with your specifications:

      Output

      ... --> Scenario: 'default' --> Action: 'create' PLAY [Create] ****************************************************************** TASK [Log into a Docker registry] ********************************************** skipping: [localhost] => (item=None) skipping: [localhost] TASK [Create Dockerfiles from image names] ************************************* changed: [localhost] => (item=None) changed: [localhost] TASK [Discover local Docker images] ******************************************** ok: [localhost] => (item=None) ok: [localhost] TASK [Build an Ansible compatible image] *************************************** changed: [localhost] => (item=None) changed: [localhost] TASK [Create docker network(s)] ************************************************ skipping: [localhost] TASK [Create molecule instance(s)] ********************************************* changed: [localhost] => (item=None) changed: [localhost] TASK [Wait for instance(s) creation to complete] ******************************* changed: [localhost] => (item=None) changed: [localhost] PLAY RECAP ********************************************************************* localhost : ok=5 changed=4 unreachable=0 failed=0

      After create, the test moves on to the prepare action. This action executes the prepare playbook, which brings the host to a specific state before running converge. This is useful if your role requires a pre-configuration of the system before the role is executed. Again, this does not apply to our role:

      Output

      ... --> Scenario: 'default' --> Action: 'prepare' Skipping, prepare playbook not configured.

      After prepare, the converge action executes your role on the container by running the playbook.yml playbook. If multiple platforms are configured in the molecule.yml file, Molecule will converge on all of these:

      Output

      ... --> Scenario: 'default' --> Action: 'converge' PLAY [Converge] **************************************************************** TASK [Gathering Facts] ********************************************************* ok: [centos7] TASK [ansible-apache : Ensure required packages are present] ******************* changed: [centos7] TASK [ansible-apache : Ensure latest index.html is present] ******************** changed: [centos7] TASK [ansible-apache : Ensure httpd service is started and enabled] ************ changed: [centos7] => (item=httpd) changed: [centos7] => (item=firewalld) TASK [ansible-apache : Whitelist http in firewalld] **************************** changed: [centos7] PLAY RECAP ********************************************************************* centos7 : ok=5 changed=4 unreachable=0 failed=0

      After coverge, the test moves on to idempotence. This action tests the playbook for idempotence to make sure no unexpected changes are made in multiple runs:

      Output

      ... --> Scenario: 'default' --> Action: 'idempotence' Idempotence completed successfully.

      The next test action is the side-effect action. This lets you produce situations in which you'll be able to test more things, like HA failover. By default, Molecule doesn't configure a side-effect playbook and the task is skipped:

      Output

      ... --> Scenario: 'default' --> Action: 'side_effect' Skipping, side effect playbook not configured.

      Molecule will then run the verifier action using the default verifier, Testinfra. This action executes the tests you wrote earlier in test_default.py. If all the tests pass successfully, you will see a success message and Molecule will proceed to the next step:

      Output

      ... --> Scenario: 'default' --> Action: 'verify' --> Executing Testinfra tests found in /home/sammy/ansible-apache/molecule/default/tests/... ============================= test session starts ============================== platform linux -- Python 3.6.5, pytest-3.7.3, py-1.5.4, pluggy-0.7.1 rootdir: /home/sammy/ansible-apache/molecule/default, inifile: plugins: testinfra-1.14.1 collected 6 items tests/test_default.py ...... [100%] ========================== 6 passed in 41.05 seconds =========================== Verifier completed successfully.

      Finally, Molecule destroys the instances completed during the test and deletes the network assigned to those instances:

      Output

      ... --> Scenario: 'default' --> Action: 'destroy' PLAY [Destroy] ***************************************************************** TASK [Destroy molecule instance(s)] ******************************************** changed: [localhost] => (item=None) changed: [localhost] TASK [Wait for instance(s) deletion to complete] ******************************* changed: [localhost] => (item=None) changed: [localhost] TASK [Delete docker network(s)] ************************************************ skipping: [localhost] PLAY RECAP ********************************************************************* localhost : ok=2 changed=2 unreachable=0 failed=0

      The test actions are now complete, verifying that your role worked as intended.

      Conclusion

      In this article you created an Ansible role to install and configure Apache and firewalld. You then wrote unit tests with Testinfra that Molecule used to assert that the role ran successfully.

      You can use the same basic method for highly complex roles, and automate testing using a CI pipeline as well. Molecule is a highly configurable tool that can be used to test roles with any providers that Ansible supports, not just Docker. It's also possible to automate testing against your own infrastructure, making sure that your roles are always up-to-date and functional. The official Molecule documentation is the best resource for learning how to use Molecule.



      Source link