Infrastructure as Code & GitOps Automation
Infrastructure as Code (IaC) is the practice of managing and provisioning computing infrastructure (servers, databases, networks, firewalls) through machine-readable definition files rather than manual console clicking. GitOps extends this by using Git as the single source of truth for desired system state.
1. Declarative vs. Imperative Infrastructure: Principles & Guarantees
IaC tooling falls into two fundamentally different paradigms: defining the desired end state (declarative) versus listing the step-by-step commands to execute (imperative):
Declarative IaC (Desired State)
Recommended StandardYou declare WHAT the infrastructure should look like (e.g. "I want 3 Kubernetes nodes and a VPC"). The engine calculates the diff and creates, updates, or destroys resources idempotently.
resource "aws_s3_bucket" "audit_logs" {
bucket = "clinical-audit-logs-prod"
force_destroy = false
versioning {
enabled = true
}
}Imperative Scripting (Procedural Steps)
Prone to State DriftYou define HOW to configure resources through sequence of CLI commands or bash scripts. Re-running the script may fail or create duplicate resources if not strictly guarded.
# Bash CLI Sequence
aws s3api create-bucket \
--bucket clinical-audit-logs-prod \
--region us-east-1
aws s3api put-bucket-versioning \
--bucket clinical-audit-logs-prod ...2. Remote State Backends & State Locking Patterns
IaC engines map declarative code to real-world cloud resource IDs using a state file (terraform.tfstate). In multi-engineer environments, state files must follow strict security rules:
Use DynamoDB or PostgreSQL backend locking to prevent two concurrent CI runners from executing conflicting infrastructure changes simultaneously.
State files frequently contain sensitive resource IDs and generated tokens. Remote backends (S3/GCS) must enforce server-side AES-256 encryption with customer-managed keys.
Separate state files by environment (dev.tfstate, prod.tfstate) and service boundary, minimizing blast radius and reducing plan execution time.
3. Configuration Drift Detection & Auto-Remediation
Configuration Drift occurs when engineers modify cloud resources directly in the cloud console or via emergency SSH, making real-world infrastructure diverge from the Git code repository.
- Scheduled Drift Scans: CI/CD runs
tofu plan -detailed-exitcodeon a nightly cron to detect unauthorized resource modifications. - Alert & Reconcile: When drift is detected, the pipeline alerts the platform team and automatically reapplies the Git-declared state.
- Revoke Write Permissions: Prevent drift at the root by revoking direct console write permissions from human IAM accounts.
4. GitOps Pull-Based Reconciliation Architecture
Traditional CI/CD uses a push model (CI runner holds production credentials and pushes changes). Modern cloud architectures use GitOps pull reconciliation (an in-cluster agent pulls from Git):
All Kubernetes manifests, Helm charts, and environment configs reside in Git. Every infrastructure change is audited through Pull Request reviews.
The GitOps operator runs inside the Kubernetes cluster, continuously comparing desired Git state with actual running state and self-healing discrepancies.
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.