Senior Ansible Automation Engineer -- 2

@ambar

Are you already running Ansible from a central control node, or directly from Jenkins? Are WinRM certificates already configured on all servers? Do you currently version your playbooks in Git? I’ve done similar Windows + Jenkins automation work before. This looks straightforward honestly. Windows servers, Ansible roles, Jenkins pipeline. Nothing unusual. I would first standardize WinRM (HTTPS + proper auth), then cleanly split roles: base-windows, web/IIS, MongoDB, ELK, microservices. One role per layer, not per server. That keeps it simple. I’ll enforce idempotency properly (handlers for reboot detection, service restart only when changed). Add retry logic for flaky Windows updates. Also include environment-specific group_vars instead of duplicating playbooks. In Jenkins: declarative pipeline with stages — lint → syntax check → test run (check mode) → apply. Fail fast if lint breaks. I’ll also add build logs in JSON callback so failures are clear. Secrets handled via ansible-vault with separate vault IDs per environment. I normally include a small bootstrap PowerShell script so a fresh Windows node can self-register and be managed immediately. Docs will explain repo structure, how to lint, how to deploy fresh. Anyone can clone and run. Should dev/test/prod live in separate inventory files (Yes/No)?

@yeswanthmedida19

Hello, This is exactly the kind of structured automation ownership I’ve handled before — stabilising and standardising Ansible across on-prem Windows environments and integrating it tightly with Jenkins-driven CI. On Windows, Ansible requires disciplined role design, WinRM handling, and strict idempotency to avoid drift. My focus would be to turn your automation layer into a predictable, Git-driven system where every change flows cleanly from commit → lint → test → promote. Approach • Refactor infrastructure into modular, reusable roles (web, DB, MongoDB, ELK, microservices) • Design environment-based dynamic inventories (dev/test/prod separation) • Enforce idempotency and safe re-runs • Integrate ansible-lint + syntax validation into Jenkins • Create declarative Jenkins pipelines for controlled promotion • Add rollback strategy using tagged releases and state validation • Document structure so any engineer can clone and deploy confidently Deliverables will include fully version-controlled playbooks, Jenkins job definitions, documented execution flow, and a final walkthrough demonstrating repeatable idempotent runs. The goal is not just working playbooks — but a rock-solid, maintainable automation framework. Timeline: 4 weeks Budget: ₹68,000 Happy to review your current repo structure before finalizing scope.

@Hemantt841

I understand that you need a seasoned Ansible Automation Engineer to take full ownership of your automation layer, focusing on provisioning, configuration, patching, and deployment for your on-premises environment. The project requires creating reusable roles, integrating with Jenkins, and ensuring seamless workflows for your web servers, database servers, and microservices stack, including MongoDB and ELK. With over 15 years of experience and more than 200 projects delivered, I specialize in DevOps and automation, particularly with Ansible. My background includes extensive work with Jenkins and Git, which aligns perfectly with your requirements for crafting version-controlled playbooks and defining Jenkins jobs that provide clear feedback. My approach would involve analyzing your existing workflows to create a set of well-structured Ansible playbooks and roles tailored for your environment. I would ensure tight integration with Jenkins, allowing for continuous optimization and troubleshooting alongside your DevOps team, aiming for a smooth transition within a realistic timeframe of 4 to 6 weeks. I’d be happy to discuss how my experience aligns with your needs.

@BrainstackTech

Hello there, We have 8 years in DevOps automation, CI/CD pipelines, and infrastructure-as-code for on-prem environments — including the specific friction points of Ansible against Windows targets via WinRM: transport tuning, credential vaulting, and idempotency quirks. We'd structure layered role hierarchies — base OS, middleware (web servers, MongoDB, ELK), and app deployment — driven by dynamic inventory from your CMDB. Jenkins declarative pipelines trigger ansible-lint and molecule tests on every PR, then promote through dev → test → prod with stage-gated approvals, using `win_dsc` and `win_feature` modules for native idempotency over raw PowerShell. Ansible because you're Git-centric and agentless matters on Windows — no daemons, no PKI overhead. Jenkins declarative over scripted for readable, auditable job definitions. Molecule with Docker/Vagrant for role-level testing before touching real infra. We've built orchestration platforms handling 60,000+ records with queue-based processing and multi-stage deployments — similar complexity to your microservices, MongoDB, and ELK coordination. Biggest risk: WinRM failures silently breaking runs mid-execution. We'd implement block/rescue patterns with explicit failure callbacks to Jenkins so no server is half-configured without an alert. Phases: Week 1-2 base roles, inventories, Jenkins scaffolding; Week 3 MongoDB/ELK roles and molecule tests; Week 4 docs, walkthrough, rollback demos. Naveen Brainstack Technologies

@nashtribes

I’m a senior Ansible automation engineer with 5+ years building production-grade playbooks for complex on-prem environments. I can take full ownership of your automation layer—designing reusable roles, dynamic inventories, and idempotent workflows for web, database, MongoDB, and ELK stacks on Windows infrastructure. I’ll integrate everything into Jenkins using declarative pipelines with linting, Molecule testing, and Git-based promotion across dev/test/prod. Deliverables include fully version-controlled playbooks, documented Jenkins jobs, and clear deployment documentation. Timeline: 3–5 weeks depending on scope. Happy to share similar CI/CD automation examples. Nadir S.