Ansible In Cicd Overview

In the previous module, we completed our exploration of includes and imports, which allow you to modularize your tasks, roles, and playbooks. By breaking your configurations into independent, reusable files, you keep your project structure maintainable. However, in modern operations workflows, executing these playbooks manually from a local machine is a bottleneck and a security risk.

To automate operations, you must integrate your playbooks into CI/CD (Continuous Integration/Continuous Delivery) pipelines. This ensures that infrastructure changes are tested, validated, and deployed automatically whenever code is pushed to your version control repository.

In this guide, we will cover the core principles of using Ansible in automated pipelines, analyze the execution life cycle, and review key pipeline design patterns.

1. Why Run Ansible in CI/CD?

Manual executions are subject to human error: an operator might run a playbook against the wrong inventory, fail to pass the correct variables, or execute commands from an uncommitted local branch. Running Ansible in a centralized CI/CD pipeline solves these issues by:

• Enforcing GitOps: The repository is the single source of truth. You cannot execute changes on servers without committing your code to Git first.
• Standardizing Environments: Playbooks run inside clean, identical runner containers rather than developer workstations with different software versions.
• Automating Testing: You can run validation tasks, syntax checks, and molecule tests automatically on every pull request before changes reach production.
• Auditing and Logs: Every execution is logged centrally inside your pipeline platform, providing a complete audit trail of what was changed, when, and by whom.

2. The Execution Life Cycle in a Pipeline

When a commit is pushed to your Git repository, the pipeline runner triggers a multi-stage execution flow:

Commit Pushed to Git
         │
         ▼
Stage 1: Lint & Verify ──► Run ansible-lint and syntax checks
         │
         ▼
Stage 2: Test ───────────► Execute Molecule tests in ephemeral containers
         │
         ▼
Stage 3: Provision ──────► Run provision playbooks (Terraform/Ansible)
         │
         ▼
Stage 4: Deploy ─────────► Run configuration updates (site.yml) to target hosts

Each stage must complete successfully before the pipeline progresses to the next. If a syntax check fails in Stage 1, the pipeline halts immediately, preventing broken code from reaching staging or production.

3. Runner Architecture: Push vs. Pull Model

When running Ansible in pipelines, you can choose one of two execution models:

The Push Model (Standard)

The pipeline runner acts as the control node. It checkout your Git repository, installs Ansible, retrieves Vault passwords from secrets manager, and executes the playbook, pushing configuration changes to remote hosts over SSH.

• Pros: Simple to set up, centralized execution logs, aligns with standard local development flows.
• Cons: The runner requires direct SSH access to your target servers, which can be a security concern in restricted networks.

The Pull Model (ansible-pull)

Target servers run a local cron job or systemd service that regularly executes ansible-pull. The server pulls the playbook repository directly from Git and runs the configuration locally against localhost using connection plugins.

• Pros: High scalability (no control node bottleneck), target hosts do not require open inbound SSH ports.
• Cons: Harder to orchestrate synchronous rolling updates across multiple hosts, and local execution logs are distributed across servers.

4. Operational Best Practices: CI/CD Pipelines

• Pin Ansible Versions: Ensure that your pipeline runner uses a fixed Ansible version (e.g., in a Docker image or requirements file) to avoid surprise breaks when new major versions are released.
• Use Ephemeral Environments: Always run test plays inside temporary docker containers or staging virtual machines before applying changes to production.
• Protect Credentials: Never store SSH private keys or Vault passwords in raw text in your repository. Use pipeline environment secrets.

5. Pipeline Integration Reference Summary

Now that we have covered the conceptual framework of running Ansible in automated environments, the next step is looking at hands-on platform integrations. In the next section, we will cover how to configure and execute Ansible playbooks inside Jenkins build pipelines.