Ansible Automation Ansible Testing with Molecule 2 — Questions and Answers
Question 1: In Molecule's molecule.yml, what does the 'platforms' section define?
- The test instances (containers/VMs) to create, including their names, images, and configuration (Correct answer)
- The Linux distributions that the role supports
- The Ansible platforms (versions) to test against
- The CI/CD platforms where Molecule tests will run
Correct answer: The test instances (containers/VMs) to create, including their names, images, and configuration
The 'platforms' section specifies what test instances Molecule should create—their names, Docker images, OS versions, etc.
The 'platforms' section in molecule.yml defines test instances: platforms: - name: instance-centos8 image: centos:8 pre_build_image: true - name: instance-ubuntu22 image: ubuntu:22.04 pre_build_image: true - name: instance-debian11 image: debian:11 pre_build_image: true With this configuration, 'molecule test' creates three containers and tests the role on all three simultaneously. This is how you verify cross-platform compatibility. Driver-specific options are also set here (memory, CPU, network settings for VM drivers).
Question 2: What is Molecule's 'idempotency' test and why is it important?
- Molecule runs the converge playbook twice and fails if any task reports 'changed' on the second run, verifying that the role doesn't make unnecessary changes (Correct answer)
- Molecule checks that all role variable names are unique
- Molecule verifies that the role produces identical results across different OS versions
- Molecule tests that the role can be run in parallel without conflicts
Correct answer: Molecule runs the converge playbook twice and fails if any task reports 'changed' on the second run, verifying that the role doesn't make unnecessary changes
The idempotency check enforces a core Ansible principle—a properly written role should only make changes when needed, not on every run.
Idempotency is a core Ansible design principle: running a playbook N times should produce the same result as running it once. The Molecule idempotency test: 1. Runs converge.yml a first time (changes expected) 2. Runs converge.yml a second time 3. Fails if any task reports 'changed' (yellow in Ansible output) Common idempotency failures: using 'command' or 'shell' modules without 'creates/removes' arguments, improper 'changed_when' settings, or operations that inherently make changes (database seeds, etc.). Idempotency failures suggest the role may cause service interruptions if run repeatedly.
Question 3: How do you run Molecule tests for a specific scenario when multiple scenarios exist?
- molecule test --scenario-name scenarioname (Correct answer)
- molecule test -s scenarioname
- molecule test scenarioname
- molecule test --scenario scenarioname
Correct answer: molecule test --scenario-name scenarioname
The '--scenario-name' flag (or '-s' shorthand) specifies which scenario to run when a role has multiple test scenarios.
When roles have multiple scenarios (e.g., default, centos8, ubuntu-systemd), specify which to run: molecule test --scenario-name centos8 # or shorthand: molecule test -s centos8 # or just converge: molecule converge -s ubuntu-systemd To run all scenarios: molecule test --all Scenario names map to directories under molecule/: molecule/ default/ centos8/ ubuntu-systemd/ Different scenarios can use different drivers, platforms, or test different aspects of the role (full install vs upgrade scenarios, minimal vs full configuration).
Question 4: What is the purpose of Molecule's 'prepare' phase?
- It runs a prepare.yml playbook to configure test prerequisites on instances before the role under test is applied (Correct answer)
- It installs Molecule dependencies on the test instances
- It validates the molecule.yml configuration before creating instances
- It prepares the Ansible control node with required collections
Correct answer: It runs a prepare.yml playbook to configure test prerequisites on instances before the role under test is applied
The prepare phase runs before converge to set up any prerequisites that the role expects (users, directories, packages) without those prerequisites being part of the role itself.
Molecule's lifecycle phases: 1. dependency: Install required roles/collections 2. lint: Run linting (yamllint, ansible-lint) 3. syntax: ansible-playbook --syntax-check 4. create: Provision test instances 5. prepare: Run prepare.yml (optional) — set up prerequisites 6. converge: Apply the role under test 7. idempotency: Run converge again 8. verify: Run tests 9. destroy: Remove test instances The prepare.yml is used for things like: creating prerequisite users the role needs to manage, installing base packages the role assumes exist, or configuring test-specific settings. This keeps the prepare logic separate from the role's actual responsibilities.
Question 5: How does Molecule integrate with CI/CD pipelines like GitHub Actions or GitLab CI?
- Molecule runs as a standard CLI tool in pipeline jobs; Docker-in-Docker or Docker socket mounting is needed for the Docker driver (Correct answer)
- Molecule requires a dedicated CI/CD plugin not available in all platforms
- Molecule can only run in Jenkins with specific plugins
- Molecule automatically detects CI environments and adjusts its behavior
Correct answer: Molecule runs as a standard CLI tool in pipeline jobs; Docker-in-Docker or Docker socket mounting is needed for the Docker driver
Molecule is a standard Python CLI tool that runs in any CI environment with Docker and Python available.
GitHub Actions example for Molecule: name: Molecule Tests on: push jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Install dependencies run: pip install molecule molecule-plugins[docker] ansible - name: Run Molecule tests run: molecule test working-directory: roles/myrole For GitLab CI: stage: test image: python:3.11 services: - docker:dind variables: DOCKER_HOST: tcp://docker:2375 script: - pip install molecule molecule-plugins[docker] ansible - cd roles/myrole && molecule test Docker-in-Docker (DinD) is needed because Molecule uses Docker to create test containers.
Question 6: What is the 'delegated' Molecule driver used for?
- It delegates instance management to custom playbooks (create.yml and destroy.yml), enabling Molecule to work with any infrastructure not supported by built-in drivers (Correct answer)
- It delegates test execution to a remote Molecule server
- It runs tests on delegated hosts via Ansible's delegate_to feature
- It delegates verify steps to external testing frameworks
Correct answer: It delegates instance management to custom playbooks (create.yml and destroy.yml), enabling Molecule to work with any infrastructure not supported by built-in drivers
The delegated driver allows complete customization of instance lifecycle—create and destroy playbooks handle infrastructure provisioning, enabling testing on any platform.
The delegated driver is Molecule's 'bring your own infrastructure' option: - molecule.yml specifies 'driver: name: delegated' - Create.yml: Custom playbook to provision test instances (e.g., spin up cloud VMs, configure bare metal) - Destroy.yml: Custom playbook to terminate instances - Molecule handles all other phases (converge, verify) normally Use cases: - Testing on bare metal servers - Custom cloud providers without native Molecule drivers - Testing with specific hardware configurations - Integration testing with existing infrastructure The instance connection details (host, SSH key, user) must be output from create.yml in a format Molecule understands.
Ansible Automation Ansible Testing with Molecule 2
In Molecule's molecule.yml, what does the 'platforms' section define?