Infrastructure as Code

Terraform Best Practices and Patterns

Core Concepts

• Declarative Syntax: Describe desired state, not execution steps
• State Management: Terraform state tracks infrastructure resources
• Providers: Plugins for interacting with cloud providers and services
• Modules: Reusable components for infrastructure

Best Practices

• State Management

  • Use remote state (S3, Azure Storage, GCS) for collaboration
  • Enable state locking with DynamoDB, Azure Blob lease, or GCS lock
  • Separate state files by environment (dev, staging, prod)
  • Use state workspaces for environment isolation
  • Implement state versioning and backups

• Module Structure

  • Use modules for reusable infrastructure components
  • Follow standard module structure: main.tf, variables.tf, outputs.tf
  • Document modules with README.md
  • Version control modules in separate repositories
  • Use module registries for sharing

• Resource Naming

  • Use consistent naming conventions
  • Include environment and region in resource names
  • Use name_prefix or name_suffix for dynamic naming
  • Avoid hard-coded names where possible

• Variables and Outputs

  • Use variables for configurable values
  • Provide sensible defaults for non-critical variables
  • Use variable validation for type checking
  • Output important resource attributes for other modules to consume

• Provider Configuration

  • Use provider blocks for cloud provider authentication
  • Configure provider regions and endpoints
  • Use provider aliases for multi-region or multi-cloud deployments
  • Store provider credentials securely (environment variables, vault)

Terraform Patterns

• Multi-Environment Pattern: Use workspaces or separate state files
• Multi-Region Pattern: Use provider aliases and module replication
• Multi-Cloud Pattern: Use multiple providers and provider aliases
• GitOps Pattern: Use Terraform with GitOps tools (Atlantis, TF-Controller)
• Zero-Downtime Pattern: Use create_before_destroy and lifecycle rules

Terraform Commands

• terraform init: Initialize working directory and download providers
• terraform plan: Preview changes before applying
• terraform apply: Apply configuration changes
• terraform destroy: Destroy infrastructure
• terraform import: Import existing resources into state
• terraform state mv: Move resources in state
• terraform refresh: Update state file with real resources

AWS CloudFormation Templates

Core Concepts

• Templates: JSON or YAML files describing AWS resources
• Stacks: Collections of resources managed as a single unit
• Change Sets: Preview changes before executing
• Parameters: Input values for template customization
• Outputs: Values returned after stack creation

Best Practices

• Template Organization

  • Use YAML for better readability
  • Use nested stacks for modularity
  • Use CloudFormation exports for cross-stack references
  • Use intrinsic functions for dynamic values
  • Use mappings for environment-specific values

• Resource Management

  • Use DeletionPolicy for resource protection
  • Use UpdateReplacePolicy for resource replacement behavior
  • Use DependsOn for explicit resource dependencies
  • Use CreationPolicy and UpdatePolicy for resource lifecycle management

• Parameter and Output Design

  • Use parameters for configurable values
  • Use parameter constraints for validation
  • Use default values for non-critical parameters
  • Output important resource attributes

• Change Set Management

  • Always create change sets before updating stacks
  • Review change sets carefully before execution
  • Use change sets for zero-downtime deployments
  • Cancel change sets if changes are unexpected

CloudFormation Intrinsic Functions

• !Ref: Reference parameters or resources
• !GetAtt: Get resource attributes
• !Sub: String substitution
• !Join: Join strings with a delimiter
• !Select: Select from a list
• !Split: Split a string into a list
• !If: Conditional logic
• !Equals: Compare values
• !And, !Or, !Not: Boolean logic
• !FindInMap: Look up values in a mapping
• !ImportValue: Import exported values from other stacks

Azure ARM Templates

Core Concepts

• Templates: JSON files describing Azure resources
• Resource Groups: Logical containers for Azure resources
• Deployments: Operations to create or update resources
• Parameters: Input values for template customization
• Variables: Internal values for template logic

Best Practices

• Template Structure

  • Use parameter files for environment-specific values
  • Use linked templates for modularity
  • Use deployment scripts for post-deployment actions
  • Use template specs for reusability
  • Use Azure Blueprints for governance

• Resource Management

  • Use dependsOn for explicit dependencies
  • Use copy loops for multiple resource instances
  • Use deployment mode (incremental vs complete)
  • Use resource identity for managed identities

• Parameter and Variable Design

  • Use parameters for external configuration
  • Use variables for internal calculations
  • Use parameter decorators for validation
  • Use secure strings for sensitive values

ARM Template Functions

• parameters(): Reference parameters
• variables(): Reference variables
• reference(): Get resource properties
• concat(): Concatenate strings
• substring(): Extract substring
• replace(): Replace string
• toUpper(), toLower(): Case conversion
• uniqueString(): Generate unique strings
• resourceId(): Get resource ID
• subscription(), resourceGroup(): Get deployment scope

Kubernetes Manifests and Helm Charts

Kubernetes Manifests

• Core Concepts

  • YAML files describing Kubernetes resources
  • Declarative configuration for pods, services, deployments, etc.
  • Use kubectl for applying manifests

• Best Practices

  • Use labels and selectors for resource organization
  • Use namespaces for resource isolation
  • Use resource requests and limits for resource management
  • Use liveness and readiness probes for health checks
  • Use ConfigMaps and Secrets for configuration
  • Use persistent volumes for data persistence
  • Use services for service discovery
  • Use ingress for external access

• Common Resources

  • Pod: Smallest deployable unit
  • Deployment: Manages replica sets and pods
  • Service: Exposes pods as network services
  • ConfigMap: Stores configuration data
  • Secret: Stores sensitive data
  • PersistentVolumeClaim: Claims storage
  • Ingress: Manages external access to services
  • Namespace: Logical partition for resources

Helm Charts

• Core Concepts

  • Helm is a package manager for Kubernetes
  • Charts are packages of Kubernetes manifests
  • Values files for chart customization
  • Templates for dynamic manifest generation

• Best Practices

  • Use semantic versioning for chart versions
  • Use Chart.yaml for chart metadata
  • Use values.yaml for default values
  • Use values files for environment-specific configuration
  • Use templates for dynamic manifest generation
  • Use Helm hooks for lifecycle events
  • Use chart dependencies for modularity
  • Document charts with README.md

• Helm Commands

  • helm create: Create a new chart
  • helm install: Install a chart
  • helm upgrade: Upgrade a release
  • helm uninstall: Uninstall a release
  • helm template: Render templates
  • helm lint: Validate charts
  • helm repo add: Add chart repository

Ansible Playbooks

Core Concepts

• Playbooks: YAML files describing automation tasks
• Modules: Reusable units of work
• Inventory: List of managed hosts
• Roles: Organized collections of playbooks, tasks, and files

Best Practices

• Playbook Structure

  • Use descriptive playbook names
  • Use roles for modularity
  • Use handlers for service restarts
  • Use tags for selective execution
  • Use variables for configuration

• Task Design

  • Use idempotent modules
  • Use become for privilege escalation
  • Use when for conditional execution
  • Use loop for iteration
  • Use register for capturing output

• Inventory Management

  • Use dynamic inventory for cloud resources
  • Use inventory groups for host organization
  • Use host variables for host-specific configuration
  • Use group variables for group-specific configuration

State Management and Drift Detection

State Management

• Terraform State

  • Use remote state for collaboration
  • Enable state locking
  • Implement state backups
  • Use state workspaces for isolation
  • Implement state versioning

• CloudFormation Stack State

  • Use stack sets for multi-account deployments
  • Use stack policies for resource protection
  • Use drift detection for configuration changes
  • Use stack notifications for events

• Kubernetes State

  • Use GitOps for desired state management
  • Use controllers for reconciliation
  • Use operators for complex applications
  • Use admission controllers for validation

Drift Detection

• Terraform Drift

  • Use terraform plan to detect drift
  • Use terraform refresh to update state
  • Implement automated drift detection
  • Use drift detection tools (tfsec, checkov)

• CloudFormation Drift Detection

  • Enable drift detection for stacks
  • Use AWS Config for compliance monitoring
  • Implement automated drift remediation
  • Use AWS CloudTrail for audit logging

• Kubernetes Drift

  • Use tools like OPA Gatekeeper for policy enforcement
  • Use tools like Kyverno for validation
  • Use tools like Argo CD for GitOps and drift detection
  • Implement admission webhooks for validation

Security Considerations

• Secrets Management

  • Use secret stores (Vault, AWS Secrets Manager, Azure Key Vault)
  • Never commit secrets to version control
  • Use environment variables or secret injection
  • Rotate secrets regularly

• Access Control

  • Use IAM roles and policies for access control
  • Implement least privilege access
  • Use service accounts for application access
  • Use temporary credentials where possible

• Compliance

  • Use security scanning tools (tfsec, checkov, kube-bench)
  • Implement policy as code (OPA, Sentinel)
  • Use audit logging for compliance
  • Regular security reviews