How to Build Low‑Cost Automated DevOps with Ansible, Jenkins & Prometheus

Background and Challenges

The author’s team consists of three‑and‑a‑half developers managing dozens of cloud machines and dozens of legacy applications. Build and packaging happen on developers’ laptops, branches are all dev‑branch until merged to master, and production configuration must be inspected manually on each host. Basic machine‑level monitoring is missing, prompting a need for low‑cost automation.

Step 1: Monitoring and Alerting with Prometheus

Among many monitoring options (Zabbix, Open‑Falcon, Prometheus), Prometheus was chosen because it uses a pull model, stores configuration as text (easy to version), and offers a rich plugin ecosystem.

Pull‑based data collection

Text‑based configuration enables version control

Extensive exporter library covers most metrics

Learning one well‑documented tool aligns with Google SRE recommendations

Installation of Prometheus is fully automated with Ansible and Git, producing a reproducible setup.

Prometheus Server collects and stores metrics, Alertmanager handles alert routing, and node‑exporter exposes host metrics via HTTP. The ecosystem integrates seamlessly with Grafana for visualization.

Alerting is extended with the community‑maintained prometheus-webhook-dingtalk component to push alerts to DingTalk.

Step 2: Configuration Versioning with Ansible

All configuration files are extracted into a dedicated Git repository, separating deployment logic from application code. The repository follows a directory layout per environment (dev, stage, prod) with hierarchical variable files.

├── environments/
│   ├── dev/
│   │   ├── group_vars/
│   │   │   ├── all
│   │   │   ├── db
│   │   │   └── web
│   │   └── hosts
│   ├── prod/
│   │   ├── group_vars/
│   │   │   ├── all
│   │   │   ├── db
│   │   │   └── web
│   │   └── hosts
│   └── stage/
│       ├── group_vars/
│       │   ├── all
│       │   ├── db
│       │   └── web
│       └── hosts

Ansible’s built‑in support for Consul (via consul_module) makes future migration to a centralized configuration center straightforward.

Step 3: Jenkins for Build Automation

Jenkins is provisioned with the ansible-role-jenkins role, which automatically installs required plugins via the jenkins_plugins variable.

---
- hosts: all
  vars:
    jenkins_plugins:
      - blueocean
      - ghprb
      - greenballs
      - workflow-aggregator
    jenkins_plugin_timeout: 120
  pre_tasks:
    - include_tasks: java-8.yml
  roles:
    - geerlingguy.java
    - ansible-role-jenkins

Projects are built using a Jenkinsfile (pipeline as code). The author prefers the Jenkinsfile approach for versioning and flexibility.

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh './gradlew clean build'
                archiveArtifacts artifacts: '**/target/*.jar', fingerprint: true
            }
        }
    }
}

Jenkins integrates with the existing GitLab instance; the connection method can be chosen based on network constraints.

Step 4: Running Ansible from Jenkins

The Jenkins Ansible plugin enables pipeline‑level execution of playbooks. Sensitive data (SSH keys, Vault passwords) are supplied via the Credentials Binding plugin.

withCredentials([sshUserPrivateKey(keyFileVariable:"deploy_private",credentialsId:"deploy"),file(credentialsId: 'vault_password', variable: 'vault_password')]) {
    ansiblePlaybook vaultCredentialsId: 'vault_password', inventory: "environments/prod", playbook: "playbook.yaml",
        extraVars:[
            ansible_ssh_private_key_file: [value: "${deploy_private}", hidden: true],
            build_number: [value: "${params.build_number}", hidden: false]
        ]
}

The ansiblePlaybook step mirrors the command‑line ansible-playbook invocation, while withCredentials safely injects secrets.

Step 5: Organizing Ansible Scripts per Project

Each project contains its own ansible directory. During the packaging phase the directory is zipped; at deployment time the archive is unpacked and the playbook executed.

Step 6: Automating Script Generation with Cookiecutter

To avoid repetitive manual work, the team uses cookiecutter to scaffold both Jenkinsfiles and Ansible scripts for new projects, ensuring a consistent layout.

Conclusion

The practical roadmap for a small team’s automation journey is:

Deploy basic monitoring (Prometheus + Grafana) and alerting.

Version control configuration with Ansible.

Set up Jenkins and integrate it with GitLab.

Implement CI/CD pipelines using Jenkinsfiles.

Execute Ansible playbooks from Jenkins pipelines.

With this foundation, the team can evolve toward more advanced capabilities such as CMDB generation, blue‑green releases, auto‑scaling via Prometheus alerts, and ChatOps integrations.