Skip to main content

Ansible Infrastructure Evolution: A Structured Approach to Configuration Management

· 2 min read

Overview​

As our infrastructure grows, we need a more structured and maintainable approach to configuration management. This post outlines our plan to evolve our Ansible setup to better handle different Ubuntu versions, architectures, and machine types while maintaining simplicity and reusability.

Current State​

Our current Ansible setup has served us well but faces several challenges:

  1. Mixed concerns in inventory structure
  2. Inconsistent variable management
  3. Limited role reusability
  4. Manual tracking of OS versions and architectures

New Approach​

1. Hierarchical Inventory Structure​

We've implemented a new inventory structure that clearly separates hosts based on:

  • Ubuntu version (22.04, 24.04)
  • Architecture (ARM, x86)
  • Machine type (server, workstation, laptop)
all:
  children:
    ubuntu22:
      children:
        ubuntu22_arm:
          children:
            servers_22_arm:
            workstations_22_arm:
            laptops_22_arm:
        ubuntu22_x86:
          # Similar structure
    ubuntu24:
      # Similar structure

2. Layered Variable Management​

Variables are now organized in layers:

  1. Global Variables (group_vars/all.yml)

    • Common packages
    • Python setup
    • Security defaults
    • System locale/timezone

  2. OS Version Variables (group_vars/ubuntu22.yml, group_vars/ubuntu24.yml)

    • Version-specific packages
    • Kernel parameters
    • System configurations

  3. Architecture Variables (group_vars/ubuntu22_arm.yml, etc.)

    • Architecture-specific optimizations
    • Binary paths
    • Compiler flags

  4. Role Variables (group_vars/servers.yml, etc.)

    • Role-specific configurations
    • Service settings
    • Security policies

3. Role-Based Configuration​

Roles are now tagged with clear purposes:

  • Base roles (common, security)
  • Machine-type roles (server, workstation, laptop)
  • Service roles (docker, development, monitoring)

Implementation Plan​

Phase 1: Foundation (Week 1-2)​

  • Implement new inventory structure
  • Create base group_vars files
  • Update common roles for new structure
  • Add validation for host categorization

Phase 2: Role Refactoring (Week 3-4)​

  • Split roles by machine type
  • Implement role dependencies
  • Add role documentation
  • Create role test playbooks

Phase 3: Variable Management (Week 5-6)​

  • Implement layered variables
  • Add variable validation
  • Create variable documentation
  • Set up defaults hierarchy

Phase 4: Testing & Documentation (Week 7-8)​

  • Create test scenarios
  • Implement CI/CD for Ansible
  • Write comprehensive documentation
  • Create playbook examples

Benefits​

  1. Clarity: Clear separation of concerns in inventory
  2. Maintainability: Structured variable management
  3. Reusability: Well-defined roles and playbooks
  4. Scalability: Easy addition of new hosts and configurations
  5. Testability: Improved testing capabilities

Migration Strategy​

  1. Start with new hosts using the new structure
  2. Gradually migrate existing hosts
  3. Use tags for selective execution
  4. Maintain backward compatibility
  5. Document all changes

Next Steps​

  1. Complete Phase 1 implementation
  2. Review and update existing roles
  3. Begin role refactoring
  4. Set up testing framework

Conclusion​

This structured approach to Ansible configuration management will help us maintain a clean, efficient, and scalable infrastructure. The clear separation of concerns and layered variable management will make it easier to add new hosts and configurations while maintaining existing ones.

Tags​

#ansible #infrastructure #devops #configuration-management