The Terraform Mental Model

Terraform operates on a plan-then-apply lifecycle. You write declarative HCL (HashiCorp Configuration Language) code describing the desired state of your infrastructure. When you run terraform plan, Terraform compares your code against the current state (tracked in a state file) and produces a diff showing exactly what will be created, modified, or destroyed. Only when you run terraform apply does Terraform actually make API calls to provision or change resources.

This separation of plan and apply is what makes Terraform safe for production use. You can review every change before it happens, integrate plan output into pull request reviews, and require approvals for changes to production environments. The deterministic nature — the same code always produces the same infrastructure — is what separates IaC from the chaos of manually configured environments where nobody is quite sure what’s actually deployed or why.

Structuring Your First AWS VPC

A well-structured VPC is the foundation of secure AWS architecture. The standard pattern is a VPC with public subnets (for load balancers and NAT gateways), private subnets (for application tier), and isolated subnets (for databases and other sensitive resources). Each subnet tier spans multiple availability zones for redundancy. Internet access for private subnets routes through NAT Gateways in the public subnets, so outbound traffic is possible without exposing private resources directly.

Terraform makes this repeatable. Define your CIDR blocks as variables, use count or for_each to create subnets across AZs dynamically, and use aws_route_table resources to wire up routing. A well-organized Terraform module for VPC creation can be instantiated repeatedly for dev, staging, and production environments with just a few variable changes.

# vpc/main.tf — Core VPC and subnets
variable "vpc_cidr"         { default = "10.0.0.0/16" }
variable "public_subnets"   { default = ["10.0.1.0/24", "10.0.2.0/24"] }
variable "private_subnets"  { default = ["10.0.11.0/24", "10.0.12.0/24"] }
variable "azs"              { default = ["us-east-1a", "us-east-1b"] }
variable "env"              { default = "prod" }

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = { Name = "${var.env}-vpc" }
}

resource "aws_subnet" "public" {
  count                   = length(var.public_subnets)
  vpc_id                  = aws_vpc.main.id
  cidr_block              = var.public_subnets[count.index]
  availability_zone       = var.azs[count.index]
  map_public_ip_on_launch = true
  tags = { Name = "${var.env}-public-${count.index + 1}" }
}

resource "aws_subnet" "private" {
  count             = length(var.private_subnets)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.private_subnets[count.index]
  availability_zone = var.azs[count.index]
  tags = { Name = "${var.env}-private-${count.index + 1}" }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
  tags   = { Name = "${var.env}-igw" }
}

State Files: The Most Important File You Never Edit

Terraform’s state file (terraform.tfstate) is the source of truth that maps your HCL code to real cloud resources. Never edit it manually, never delete it, and never store it in a local filesystem for anything beyond personal experiments. For team environments and production use, store state in a remote backend: S3 with DynamoDB locking for AWS, Azure Blob Storage for Azure, or Terraform Cloud. Remote backends enable collaboration, state locking (preventing concurrent runs from corrupting state), and encryption at rest.

State locking is particularly important in CI/CD pipelines where multiple engineers or automated runs might trigger Terraform simultaneously. Without locking, two concurrent terraform apply runs can corrupt the state file, leaving your infrastructure in an unknown state. DynamoDB-backed state locking on AWS is straightforward to configure and adds minimal overhead. Make configuring remote state the very first thing you do in any new Terraform project — retrofitting it later is painful.

Modules for Reusable Infrastructure

Terraform modules are the building blocks of reusable infrastructure. A module is simply a directory of .tf files with defined inputs (variables) and outputs. The VPC example above is a perfect module candidate — you define it once and call it with different parameters for each environment. The Terraform Registry hosts thousands of community and official modules for common patterns like VPCs, EKS clusters, RDS instances, and more, saving substantial boilerplate.

Module versioning is critical for production stability. Pin your module sources to specific version tags rather than using “latest” or a branch. When you’re ready to upgrade a module, test it in a non-production environment first. Structure your Terraform codebase into separate state roots (workspaces or separate directories) for each environment, with a shared module library. This prevents a staging change from accidentally affecting production state and gives you clear promotion paths through environments.

The post Terraform on AWS: Managing Infrastructure as Code Without the Headaches appeared first on InfoTech Ninja.

The Flat Network Model

Kubernetes enforces a fundamental networking requirement: every pod must be able to communicate directly with every other pod in the cluster, without NAT. This “flat network” model is implemented by a Container Network Interface (CNI) plugin — popular choices include Calico, Flannel, Cilium, and Weave. Each pod gets its own IP address from a cluster-wide CIDR range, and the CNI plugin is responsible for ensuring pods across different nodes can reach each other.

This design has important implications. Because all pods share a flat network space, network policies (covered later) are your primary isolation mechanism — without them, any pod can talk to any other pod by default. This is fine for development but should be hardened for production multi-tenant workloads. The pod IP is ephemeral: when a pod is deleted and recreated, it gets a new IP. This is why you never communicate with pods directly by IP — that’s what Services are for.

Services: ClusterIP, NodePort, LoadBalancer

A Service is a stable network endpoint that abstracts a set of pods. Services use label selectors to determine which pods they route traffic to — when pods are replaced (during a rolling update, for example), the Service automatically routes to the new pods without any configuration change. The kube-proxy component on each node maintains iptables or IPVS rules that implement this routing.

ClusterIP is the default Service type — it creates a virtual IP that’s only reachable from within the cluster. NodePort exposes the service on a static port on every node’s external IP — useful for development and simple setups, but not recommended for production. LoadBalancer provisions a cloud load balancer (an AWS ELB, GCP Load Balancer, etc.) that routes external traffic to the Service. For most production workloads, you don’t use LoadBalancer Services directly for HTTP/HTTPS — you use an Ingress controller instead.

# Service YAML — ClusterIP example for an internal API
apiVersion: v1
kind: Service
metadata:
  name: api-service
  namespace: production
spec:
  selector:
    app: api-server
    tier: backend
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
# LoadBalancer Service for a public-facing component
apiVersion: v1
kind: Service
metadata:
  name: frontend-lb
  namespace: production
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  selector:
    app: frontend
  ports:
    - port: 443
      targetPort: 8443
  type: LoadBalancer

Ingress: Your Single Entry Point

An Ingress resource defines HTTP and HTTPS routing rules for external traffic entering the cluster. Instead of provisioning a separate LoadBalancer Service for every application (which creates a separate cloud load balancer and public IP for each), an Ingress controller provides a single entry point that routes traffic based on hostnames and URL paths to different backend Services. This is both more cost-effective and operationally cleaner.

The nginx Ingress controller is the most widely deployed, though cloud providers offer their own (AWS Load Balancer Controller, GKE Ingress). Cert-manager integrates with Ingress to automatically provision and renew TLS certificates from Let’s Encrypt, making TLS termination at the Ingress level straightforward. Combined, nginx Ingress plus cert-manager handles host-based routing and TLS for your entire cluster through a simple Ingress resource annotation.

Network Policies for Pod Isolation

By default, Kubernetes allows all pods to communicate with all other pods. Network Policies let you restrict this by specifying allowed ingress and egress traffic using pod selectors, namespace selectors, and IP blocks. They’re implemented by the CNI plugin (Calico and Cilium have the richest Network Policy support). A good default posture is a “deny all” baseline policy in each namespace, then explicit allow policies for required communication paths.

Network Policies are additive — if multiple policies apply to a pod, all of them are enforced. This makes it safe to layer policies: a namespace-wide deny-all, plus specific allows for your application tiers. Writing and testing Network Policies is notoriously tricky; tools like Cilium’s Network Policy Editor (a visual tool) combined with careful testing in a staging environment before production rollout will save you significant frustration.

# NetworkPolicy — deny all ingress to namespace, then allow specific paths
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-from-frontend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-server
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

The post Kubernetes Networking Explained: Pods, Services, and Ingress Controllers appeared first on InfoTech Ninja.

How Containers Differ from VMs

A virtual machine runs a full guest operating system on top of a hypervisor. Each VM has its own kernel, its own memory allocation, and its own virtual hardware — which is why VMs take minutes to boot and consume gigabytes of RAM even before your application starts. Containers take a different approach: they share the host OS kernel and use Linux kernel features (namespaces for isolation, cgroups for resource limits) to create isolated process environments. A container starts in seconds and consumes only the memory your application actually needs.

The isolation a container provides is less complete than a VM’s — a kernel vulnerability could theoretically allow container escape. But for most workloads, the trade-off is worth it. The operational benefits — fast startup, small image sizes, easy replication, portable images that run the same everywhere — have made containers the dominant packaging format for modern applications. From a sysadmin perspective, think of containers as very lightweight, portable, and reproducible application packages.

The Dockerfile: Your Repeatable Build

A Dockerfile is a script that defines how to build a container image. It starts from a base image (typically an official image from Docker Hub — things like ubuntu:22.04, python:3.12-slim, or nginx:alpine), then layers on commands that install dependencies, copy application code, set environment variables, and configure the entry point. Each command in a Dockerfile creates a new layer in the image, and Docker caches these layers — only layers that change need to be rebuilt.

Image hygiene matters for security. Use minimal base images (Alpine or distroless images where possible), avoid running processes as root inside the container, use multi-stage builds to keep build tooling out of production images, and regularly rebuild images to pick up upstream security patches. A multi-stage Dockerfile compiles code in one stage and copies only the compiled artifact into a slim final stage, keeping the production image lean and attack-surface-minimal.

# Multi-stage Dockerfile for a Go application
# Stage 1: build
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /bin/server ./cmd/server

# Stage 2: minimal runtime image
FROM gcr.io/distroless/static:nonroot
COPY --from=builder /bin/server /server
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["/server"]

Docker Compose for Multi-Container Apps

Real applications rarely consist of a single container. A typical web stack might include an application container, a database, a cache (Redis), and a reverse proxy. Docker Compose lets you define and manage all of these as a single unit with a YAML file. With one command (docker compose up -d), Compose creates all containers, the networks between them, and any required volumes. It’s ideal for local development environments and small-scale production deployments.

Compose handles service dependencies (start the database before the app), environment variable injection, log aggregation, and scaling (spin up multiple app replicas behind a load balancer). For local development, Compose can bind-mount your source code directory into the container, so code changes are reflected immediately without rebuilding the image. This eliminates the “works on my machine” problem — everyone on the team uses the exact same environment defined in the Compose file.

# docker-compose.yml — Web app with PostgreSQL and Redis
services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://appuser:secret@db:5432/appdb
      REDIS_URL: redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

Data Persistence with Volumes

Containers are ephemeral by default — when a container is removed, any data written inside it is lost. For stateful applications like databases, you need Docker volumes. Named volumes are managed by Docker and stored in a Docker-managed directory on the host. They survive container removal, can be backed up, and can be shared between containers. Named volumes are the recommended approach for production data.

Bind mounts map a specific path on the host filesystem directly into the container. They’re extremely useful during development (mount your source code in, see changes immediately) but less ideal for production because they create tight coupling between the container and the host filesystem layout. For production databases and stateful services, always use named volumes. For secrets and configuration, consider Docker secrets or environment variable injection rather than bind-mounting sensitive files from the host.

The post Docker for SysAdmins: Containers Without the Complexity appeared first on InfoTech Ninja.

No Agents, No Drama: The Ansible Model

Ansible’s architecture is deliberately simple. The control node (your workstation, a bastion host, or a CI/CD runner) connects to managed nodes over SSH (or WinRM for Windows), executes tasks, and disconnects. There’s no agent process running on managed nodes consuming resources or requiring updates. The only requirement on managed nodes is Python (which is present on virtually every Linux system) and a user account with appropriate sudo privileges.

Idempotency is Ansible’s most important design principle. Every built-in module is designed so that running a task multiple times produces the same result as running it once. If nginx is already installed and running, the package and service modules report “OK” rather than reinstalling or restarting. This means you can run your playbooks safely at any time — to enforce desired state, to verify compliance, or to bring a drifted system back in line — without worrying about destructive side effects.

Your Inventory File

Ansible’s inventory defines the hosts and groups your playbooks target. The simplest format is an INI-style text file. You can also use YAML format or dynamic inventory plugins that query cloud provider APIs (AWS EC2, Azure VMs, GCP instances) to build the inventory automatically from your actual running infrastructure — no manual list maintenance required.

Groups make targeting flexible. You might have a [webservers] group, a [dbservers] group, and a [production] group containing hosts from both. Group variables (stored in group_vars/ directories) let you define different settings per group — staging might use a self-signed certificate while production uses a real one, but the same playbook handles both.

# inventory/hosts.ini — Sample inventory file
[webservers]
web01.example.com ansible_user=ubuntu
web02.example.com ansible_user=ubuntu

[dbservers]
db01.example.com ansible_user=ubuntu ansible_port=2222

[production:children]
webservers
dbservers

[production:vars]
env=production
nginx_worker_processes=4

# Test connectivity to all hosts:
# ansible all -i inventory/hosts.ini -m ping

Writing Your First Playbook

A playbook is a YAML file containing one or more plays. Each play targets a group of hosts and defines a list of tasks to execute in order. Tasks use modules — the unit of work in Ansible. There are thousands of built-in modules covering package management, file operations, service management, cloud resources, network devices, and more. The module name is self-documenting: ansible.builtin.apt, ansible.builtin.copy, ansible.builtin.systemd.

The playbook below installs nginx, deploys a custom configuration, and ensures the service is running and enabled. Run it with ansible-playbook -i inventory/hosts.ini playbooks/nginx.yml. Add --check for a dry run that shows what would change without making any changes.

# playbooks/nginx.yml — Install and configure nginx
---
- name: Configure web servers
  hosts: webservers
  become: true

  vars:
    nginx_port: 80
    server_name: "{{ inventory_hostname }}"

  tasks:
    - name: Ensure nginx is installed
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Deploy nginx configuration
      ansible.builtin.template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/sites-available/default
        owner: root
        group: root
        mode: "0644"
      notify: Reload nginx

    - name: Ensure nginx is started and enabled
      ansible.builtin.systemd:
        name: nginx
        state: started
        enabled: true

  handlers:
    - name: Reload nginx
      ansible.builtin.systemd:
        name: nginx
        state: reloaded

Variables, Templates, and Handlers

Variables in Ansible can be defined at multiple levels — in the playbook itself, in separate variable files, in the inventory, or passed on the command line with -e. Jinja2 templates (files ending in .j2) use double-brace syntax ({{ variable_name }}) to interpolate variables into configuration files. This is how one nginx template can produce correctly configured files for dozens of different servers, each with the right hostname, port, and SSL certificate path.

Handlers are tasks that only run when notified by another task. The classic use case: a task that updates a configuration file notifies the “Reload nginx” handler. If the configuration file didn’t change (because it was already correct), the handler never fires and nginx isn’t unnecessarily reloaded. If multiple tasks in a play all notify the same handler, the handler runs only once at the end of the play. This prevents redundant service restarts and makes your playbooks more efficient.

The post Getting Started with Ansible: Write Your First Playbook in 30 Minutes appeared first on InfoTech Ninja.