Jenkins + Ansible

Everything so far ran from your terminal. Your new shop runs it from Jenkins: a pipeline checks out the repo, runs the playbook, and posts the result to the PR or the deploy channel. This lesson is the seam between those worlds — the Ansible half is lessons 1–40, the Jenkins half is two steps and a credential ID.

Two ways in

There are exactly two integration approaches, and most shops mix them:

1. Shell out. Install Ansible on the Jenkins agent and call it like you would: sh 'ansible-playbook site.yml -i inventories/prod/hosts'. Every flag from lesson 29 — --check, --diff, --tags, --limit — works unchanged, because it is the CLI.
2. The Ansible plugin. Jenkins’s Ansible plugin adds pipeline steps — ansiblePlaybook and ansibleAdhoc — that wrap the CLI in Groovy and wire directly into Jenkins credentials. Ansible still has to be installed on the agent. The plugin only drives it.

The stage you’ll actually read

Here is the pattern lesson 26 promised you’d meet verbatim — checkout, install dependencies, run:

pipeline {
  agent any                 // an agent with Ansible installed
  stages {
    stage('Deploy') {
      steps {
        checkout scm        // the playbook repo, same commit as the PR
        sh 'ansible-galaxy install -r requirements.yml' // agent starts empty
        ansiblePlaybook credentialsId: 'private_key',   // SSH key, by ID
          inventory: 'inventories/prod/hosts',
          playbook: 'site.yml'
      }
    }
  }
}

Three lines carry the weight. checkout scm pulls the repo the pipeline belongs to. The ansible-galaxy install line exists because a CI agent has none of your collections or roles. The pinned requirements.yml from lesson 26 makes the agent’s run match yours. ansiblePlaybook maps one-to-one onto the CLI. inventory is -i, playbook is the positional argument, and credentialsId names an SSH private key stored in the Jenkins credential store — the key material never appears in the Jenkinsfile or the repo.

That store also ties off lesson 27’s loose end. The vault password that decrypts your secrets lives in Jenkins as a credential too. The pipeline hands it to the run at execution time — the --vault-password-file route from lesson 27, fed by Jenkins instead of a file in the repo. Encrypted values in Git, key in the credential store. The two only meet inside a job.

Making it liveable

Four practicalities:

• Colors. Ansible detects it isn’t writing to a terminal and strips color. Set ANSIBLE_FORCE_COLOR=true in the stage’s environment and install the AnsiColor plugin. The console log then reads like your terminal.
• Timeouts. A serial rolling update across forty hosts takes real time. Raise the job timeout before the first long run gets killed at the default and leaves half a fleet updated.
• Targeted deploys. --limit is how pipelines do blue-green: run the play against the idle pool’s group, verify, flip traffic, rerun against the rest. Same playbook, two invocations.
• Division of labour. Keep the Jenkinsfile orchestration-only — when to run, which inventory, which credentials — and keep configuration logic in playbooks and roles. Groovy that templates config files is logic your Ansible tooling can’t lint, test or reuse.

One version note: the plugin’s test matrix currently covers ansible 2.18–2.20 , while core sits at 2.21 — plugin coverage trails core releases. That’s rarely a blocker, but it’s one more reason teams keep the shell-out path handy: sh plus the CLI has no compatibility matrix at all.

Lesson 37 already gave this pipeline its first stage — lint before deploy. With this lesson you can read, run and modify the whole file your new team lives in. What’s left is vocabulary: lesson 42 closes the course with the jargon, debugging reflexes and interview answers.