IAG 5 introduces architectural improvements and new capabilities while removing some IAG 4 features. This document outlines key changes when upgrading from IAG 4.
New features
Git-native code storage
IAG 5 provides first-class Git support for storing and retrieving custom code with robust version control.
Flexible deployment architectures
IAG 5 supports multiple deployment architectures to meet different scalability and availability requirements:
- All-in-one deployments: Single gateway servers handle both management and execution
- Distributed execution: Gateway servers manage coordination while dedicated runner nodes handle service execution
- High availability configurations: Multiple gateway servers in active/standby mode with automatic failover
- Multiple cluster architecture: Independent clusters for geographic distribution or network segmentation
For more information, see Architecture & Deployment Models.
Environment builder
IAG 5 automatically builds and maintains Python, Ansible, and OpenTofu environments based on your requirements files.
Key differences for users
- Git-based workflow: All automation content managed through Git repositories
- No graphical user interface: All configuration uses command-line interface with context-sensitive help (
--help) - No vault integration: No support for Hashicorp Vault or Cyberark integrations as of IAG 5.1
- Configuration Manager applications: Not currently supported for IAG 5
Feature Comparison
IAG 5 is an evolution of IAG 4 that serves the same core purpose of enabling device access. IAG 5 replaces IAG 4, though both can coexist to enable gradual migration.
| Feature | IAG 4 | IAG 5 | Change type |
|---|---|---|---|
| Ansible content & dependencies | Playbooks, collections, modules, and roles must exist on the server filesystem before IAG 4 can access them. Collections and roles must exist on the filesystem at design time. | Services retrieve playbook files from Git repositories at runtime. IAG 5 obtains required collections and roles by consulting requirements.yml files stored in Git repositories. This allows you to auto-deploy your latest Ansible dependencies at runtime. |
Enhancement |
| Python scripts & dependencies | Python scripts must exist on the filesystem before IAG 4 can execute them. You must manually install Python dependencies in the script's environment on the server. | Services retrieve script content from Git repositories at runtime. IAG 5 obtains required Python libraries from requirements.txt or pyproject.toml files stored in Git alongside the scripts. This allows you to auto-deploy your latest Python dependencies at runtime. |
Enhancement |
| Scaling | Difficult to scale due to architectural limitations. | Supports multiple deployment architectures, including distributed execution with runner nodes. | Enhancement |
| Decorators | Associates decorators with individual scripts or playbooks using a limited JSON schema subset that only accepts strings. | Decorators can work with multiple gateway services and support the full JSON schema specification. | Enhancement |
| Service discovery | Manual service discovery. | Automatic discovery and registration of available gateway services. | New Feature |
| Database support | Limited to built-in storage. | External database support (etcd, Amazon DynamoDB) to enable clustered deployments. | New Feature |
| Execution history | Dedicated store to display Python script and Ansible playbook execution history. | Gateway service execution history available through application log files. | Change |
| Platform integration | Leverages a combination of Automation Gateway Manager and IAG Adapter for Platform connectivity. | Leverages Gateway Manager for Platform connectivity. | Change |
| Device inventory | Multiple inventory options: internal inventory stored in sqlite database, Ansible DSL files, and Ansible dynamic inventory plugins for Nautobot, NetBox, SolarWinds, ServiceNow, and ZPE Cloud. | No internal device inventory as of IAG 5.1. IAG 5 supports external inventory sources the same way as IAG 4. Define inventory on a per-service basis using the --inventory parameter with iagctl create service ansible-playbook commands. |
Breaking Change |
Migration from IAG 4
Migration best practices
- Assign migration team: Designate a primary individual to oversee the migration with additional support staff
- Inventory current assets: Document all scripts, playbooks, and other items that need migration
- Plan Git repository structure: Define git repository layout to organize and manage your gateway services
Migration steps
- Migrate content to Git: Move Ansible playbooks, Python scripts, and OpenTofu plans to Git repositories
- Build development environment: Set up IAG 5 in local mode for development and testing
- Configure IAG 5 resources: Set up repositories, services, decorators, secrets, and users
- Deploy staging and production: Evaluate appropriate IAG 5 deployment models and build instances
Migration timeline
Plan to remain on IAG 4 only as long as necessary for migration. IAG 5 represents the next generation of Itential's automation gateway technology with enhanced architecture and simplified deployment. This release supports concurrent operation with existing IAG installations. You can evaluate IAG 5 capabilities while maintaining current operations.
Future gateway features will be developed for IAG 5 and later versions as older versions transition to maintenance mode.