Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Trond Hindenes - 18 months of learning: Notes from implementing Ansible in a “manual” Windows org

One of the first thing I did when I started at RiksTV was to start using Ansible for config management and provisioning. We made some great progress, but also some big mistakes along the way. This talk is all about learning from other’s mistakes (you get to learn from ours), along with some tips and tricks on how to get Ansible to play well in a Windows-centric org where modern config management tools were completely alien.

Why we (desperately) needed config management
How Ansible and Windows play together
Automating cloud
How we organized our Ansible code, realized our mistakes and re-organized it
Next steps for RiksTV

  • Be the first to comment

Trond Hindenes - 18 months of learning: Notes from implementing Ansible in a “manual” Windows org

  1. 1. Notes from implementing Ansible Trond Hindenes, RiksTV Norway
  2. 2. I’m Trond Background: “Traditional” Infrastructure dude turned Powershell nerd Discovered Ansible while waiting for DSC to be released @trondhindenes hindenes.com/trondsworking
  3. 3. I work at RiksTV
  4. 4. What I do at RiksTV “Make sure that we have the tooling and processes that allow us to scale and rapidly provision/replace components”
  5. 5. Why Config Management “Config Management”? “Automation”? What’s the difference anyway? Transactional vs Declarative Config Management Goal: Transition to an immutable model
  6. 6. What is ansible? Config Management / Orchestration tool Written in Python Not agent-based (central coordinator) Uses ssh/winrm Use as a “cli tool” or a server (Ansible Tower/AWX etc)
  7. 7. Ansible constructs ● Module: Comparable to a “rich” Powershell function (takes params, etc) ● Task: Execute a module against a group of nodes ● Inventory: Groups list of target nodes ● Play: Collection of tasks ● Playbook: Collection of plays ● Role: Componentized playbook(s)
  8. 8. Ansible DSL
  9. 9. Where we started Greenfield vs Brownfield Brownfield is essentially reverse-engineering (potentially) years of manual change
  10. 10. Organizing config V1 Each component in our stack (“server type”) had a separate playbook Playbooks deployed using standard CI/CD (“mainline” approach)
  11. 11. Organizing config V2 Global structure for injecting variables in a hierarchical manner One “global” playbook - use filters/tags to specifically target a certain group of nodes Docker-based CI/CD using “release/rc” pattern
  12. 12. Stuff we learned Radical change in developer’s way of working: - Make sure there’s buy-in (reluctance to change) Don’t underestimate the control plane - More accessible → shorter feedback cycle → faster adoption
  13. 13. Breakthru: First PR submitted by a developer
  14. 14. The virtuous cycle of tooling Tooling enables tooling - Our microservice approach to management components Architecture Implementation Architecture Implementation
  15. 15. Next steps for RiksTV Move from “manage” to “provision” (aka immutable infra) Break apart infrastructure monoliths Config Mgmt is here to stay (there will always be non-immutable items) Event-driven config management

×