Skip to main content

Understanding Artifact Lifecycle Management

This topic explores how Infrahub's artifact system works with Nornir to enable sophisticated configuration management workflows. Understanding artifact lifecycle management is crucial for implementing robust, auditable network automation.

Introduction​

Artifacts in Infrahub are generated outputs based on your infrastructure data and templates. They represent the "rendered truth" of your infrastructure at any point in time. This document explains:

  • What artifacts are and why they matter
  • How artifacts flow through generation, storage, and deployment
  • The relationship between artifacts, templates, and infrastructure data
  • How version control applies to generated configurations

What are artifacts?​

Definition​

An artifact is any generated content that represents infrastructure state:

  • Device configurations
  • Compliance reports
  • Documentation
  • API payloads
  • Validation results

Key characteristics​

Artifacts are:

  • Generated: Created from templates + data, not manually written
  • Versioned: Each generation creates a new version
  • Immutable: Once generated, artifacts don't change
  • Traceable: Linked to the exact data and templates used

The artifact lifecycle​

1. Definition phase​

Artifacts start with an artifact definition in the .infrahub.yml file:

# Example artifact definition structure
# (Actual structure may vary - see Infrahub documentation)
kind: CoreArtifactDefinition
name: startup-config
template_path: templates/ios/startup.j2
targets:
  - kind: InfraDevice
    filter: platform__name="ios"

This defines:

  • What template to use
  • Which devices to target
  • When to regenerate

2. Generation phase​

Generation combines:

  • Template: Jinja2 template with logic
  • Data: Current state from Infrahub
  • Context: Device-specific variables
{# templates/ios/startup.j2 #}
hostname {{ device.name }}
!
interface Loopback0
 ip address {{ device.loopback_ip.address }} 255.255.255.255
!
{% for interface in device.interfaces %}
interface {{ interface.name }}
 description {{ interface.description }}
 ip address {{ interface.ip_address.address }} {{ interface.ip_address.netmask }}
{% endfor %}

3. Storage phase​

Generated artifacts are stored in a S3 bucket or locally in Infrahub:

  • Content saved with checksum
  • Metadata tracks generation time, user, branch
  • Previous versions retained for history

4. Retrieval phase​

Artifacts can be retrieved for:

  • Deployment to devices
  • Compliance validation
  • Change review
  • Disaster recovery

Artifact management with Nornir​

Task plugin functions​

The Nornir-Infrahub plugin provides three key functions:

generate_artifacts()​

Triggers generation for all targets in a definition:

# Generate configs for all IOS devices
nr.run(task=generate_artifacts, artifact="startup-config")

This is typically used:

  • After template updates
  • On scheduled intervals
  • Before deployment windows

regenerate_host_artifact()​

Regenerates artifact for specific hosts:

# Regenerate after device-specific change
changed_devices = nr.filter(name="router1")
changed_devices.run(task=regenerate_host_artifact, artifact="startup-config")

Use cases:

  • After individual device updates
  • Testing template changes
  • Troubleshooting specific devices

get_artifact()​

Retrieves stored artifact content:

# Get current config for deployment
result = nr.run(task=get_artifact, artifact="startup-config")
for host, task_result in result.items():
    config = task_result.result
    # Deploy config to device

Version control integration​

Branch-aware artifacts​

Artifacts are generated per branch:

main branch:
  router1 startup-config v3 (current)
  router1 startup-config v2
  router1 startup-config v1

feature branch:
  router1 startup-config v2 (testing changes)
  router1 startup-config v1

This enables:

  • Safe testing in feature branches
  • Comparison between branches
  • Controlled promotion to production

Change tracking​

Every artifact generation is tracked:

# Artifact metadata includes
{
    "generated_at": "2024-01-15T10:30:00Z",
    "generated_by": "automation-user",
    "branch": "feature/new-acl",
    "template_version": "abc123",
    "data_version": "def456"
}

Architecture and design​

Generation flow​

┌────────────┐     ┌───────────┐     ┌─────────────┐
│   Trigger  │────▶│ Generator │────▶│   Storage   │
└────────────┘     └───────────┘     └─────────────┘
                          │
                          ▼
                   ┌──────────┐
                   │ Template │
                   │  Engine  │
                   └──────────┘
                          │
                          ▼
                   ┌──────────┐
                   │   Data   │
                   │  Query   │
                   └──────────┘

Storage architecture​

Artifacts use content-addressable storage:

  • Same content = same storage location
  • Deduplication happens automatically
  • Metadata links content to devices/versions

Practical workflows​

Configuration deployment​

  1. Generate: Create new configs from current data
  2. Validate: Check configs before deployment
  3. Deploy: Push to devices
  4. Verify: Confirm successful application

Compliance auditing​

  1. Define: Create compliance report template
  2. Generate: Run against all devices
  3. Review: Identify non-compliant devices
  4. Remediate: Fix issues and regenerate

Disaster recovery​

  1. Regular Generation: Keep artifacts current
  2. Backup Storage: Replicate artifact store
  3. Rapid Recovery: Deploy last-known-good configs

Advanced concepts​

Artifact dependencies​

Artifacts can depend on other artifacts:

# BGP config depends on base config
kind: CoreArtifactDefinition
name: bgp-config
depends_on:
  - startup-config
template_path: templates/bgp.j2

Conditional generation​

Generate only when needed:

# Check if regeneration needed
if device.last_modified > artifact.generated_at:
    nr.run(task=regenerate_host_artifact, artifact="startup-config")

Further reading​