Config automation

Configuration automation enables organizations to programmatically manage and deploy software configurations in a reliable and repeatable way. It helps manage complex deployments, allowing administrators to treat configuration as code and leverage modern DevOps practices.

Use cases for config automation

Config automation features have been developed with the following use cases in mind:

Infrastructure as Code (IaC)
Manage Airlock IAM configurations using the same version control and CI/CD pipelines as your application code. This enables proper change tracking, and peer reviews before deployment.
Multi-environment consistency
Ensure consistent configurations across multiple states or environments. Configuration automation eliminates the risk of manual errors when promoting changes between stages.
Modularize configurations
Break down complex configurations into manageable building blocks and compose individual configurations from such modules.
Automate configurations
Automatically compose and adapt configurations using scripts, pipelines, and the like. This allows for the modeling and management of differences between similar configurations rather than all configuration files.

Config “API guarantees”

Using scripts and pipelines to adapt configurations means writing and maintaining code against IAM configurations. In particular, such code will rely on the format, IDs, property, and plugin type names to be stable.

To support reliable automation, Airlock IAM makes the following commitments regarding the YAML configuration files:

Limited backward compatibility
Breaking changes to the configuration format and structure between minor releases are minimized (but not completely eliminated).
Change documentation:
Any necessary modifications to the configuration when upgrading to an IAM minor version will be documented in the release notes.
Validation CLI tool:
We provide a CLI to validate configurations before deployment, reducing the risk of runtime errors.

The guarantees apply to the config format (YAML), plugin type names, property names, and property values.

Functional limitation

Limitations:

The above-mentioned commitments only apply to the YAML config format and not to the XML config format.
Manual changes to code manipulating the configuration may be required when upgrading to a minor release (e.g. 8.4 to 8.5).
The above-mentioned commitments hold for minor releases but not for major releases. See also Airlock semantic versioning scheme.
Short plugin identifier names are available as of IAM 8.5. Fully-qualified plugin type identifiers - as required in IAM 8.4 - may have to be replaced by short ones to minimize the need for manual adaptations.

Info

Upgrading without changing config code

If upgrading IAM to a minor version without using new features, the following upgrade path may eliminate the need to adapt config automation code:

When upgrading from version x.a to x.b:

Keep the config automation code that produces a configuration valid for version x.a.
Use the iam upgrade CLI command in the config automation code to upgrade the resulting configuration to x.b before deploying it.

In most cases, the iam upgrade command does not require interaction.

Related features

Config automation is implemented using the following IAM features: