DEV Community: Citadel Cloud Management

Docker Multi-Stage Build Patterns That Cut My Image Sizes by 80%

Citadel Cloud Management — Thu, 09 Jul 2026 16:05:32 +0000

Every Docker image I inherited was over 1GB. After switching to multi-stage builds, the average dropped to 150MB. Here are the exact patterns I use.

Pattern 1: Builder and Runtime Separation

The most common pattern. Build dependencies stay in the builder stage; only the compiled output copies to the runtime stage.

# Stage 1: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --production=false
COPY . .
RUN npm run build

# Stage 2: Runtime
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
EXPOSE 3000
CMD ["node", "dist/main.js"]

Result: build stage has TypeScript compiler, test frameworks, dev dependencies. Runtime has only production code.

Pattern 2: Distroless for Compiled Languages

For Go, Rust, or any language that produces a static binary:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-s -w' -o /server ./cmd/server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /server /server
EXPOSE 8080
ENTRYPOINT ["/server"]

Distroless images have no shell, no package manager, no OS utilities. Attack surface drops to near zero. Image size: ~15MB.

Pattern 3: Python with Virtual Environment Copy

FROM python:3.12-slim AS builder
WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.12-slim AS runtime
COPY --from=builder /opt/venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app
COPY . .
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Copying the entire venv avoids reinstalling packages in the runtime stage.

Size Comparison

Approach	Image Size
`python:3.12` (no multi-stage)	1.2 GB
`python:3.12-slim` (no multi-stage)	450 MB
Multi-stage with slim + venv copy	180 MB
Go + distroless	15 MB

Common Mistakes

Copying everything in one COPY instruction. Each COPY creates a layer. Copy dependency files first, install, then copy source. This maximizes layer caching.
Not using .dockerignore. Without it, you copy node_modules/, .git/, and test fixtures into the build context.
Running as root. Add USER nonroot or USER 1000 in the runtime stage.

Full Docker guide: Docker vs Kubernetes

Implementing mTLS Across Multi-Cloud Services with SPIFFE/SPIRE

Citadel Cloud Management — Thu, 09 Jul 2026 16:04:28 +0000

One of the core zero trust principles is "never trust, always verify" -- and that includes service-to-service communication. Here is how I implemented mTLS across AWS, Azure, and GCP using SPIFFE and SPIRE.

Why Not Just Use a Service Mesh?

Service meshes (Istio, Linkerd) handle mTLS beautifully within a single Kubernetes cluster. The problem starts when you need mTLS between:

Services in Kubernetes and services on EC2 instances
Services across different cloud providers
Services running on-premises that need to communicate with cloud workloads

SPIFFE provides a universal identity framework. SPIRE is the reference implementation. Together, they issue short-lived X.509 certificates to workloads regardless of where they run.

Architecture Overview

                    +-----------------+
                    | SPIRE Server    |
                    | (Root CA)       |
                    +--------+--------+
                             |
              +--------------+--------------+
              |              |              |
     +--------+------+ +----+----+ +-------+------+
     | SPIRE Agent   | | Agent   | | Agent        |
     | (AWS EKS)     | | (Azure) | | (GCP GKE)    |
     +--------+------+ +----+----+ +-------+------+
              |              |              |
     +--------+------+ +----+----+ +-------+------+
     | Workload A    | | Work. B | | Workload C   |
     | SVID issued   | | SVID    | | SVID issued  |
     +---------------+ +---------+ +--------------+

Key Design Decisions

Certificate TTL of 1 hour. Short-lived certificates mean compromised credentials expire quickly.
Trust domain per organization, not per cloud. mycompany.com spans all three clouds. Workloads in AWS can validate certificates from GCP workloads because they share a trust domain.
Kubernetes PSAT attestation. This ties SPIFFE identity to Kubernetes service accounts.

Debugging mTLS Failures

The most common failure: "certificate signed by unknown authority." This means the client does not trust the SPIRE server CA. Check:

# Verify the SVID was issued
spire-agent api fetch x509 -socketPath /run/spire/sockets/agent.sock

# Check trust bundle
openssl x509 -in svid.pem -text -noout | grep Issuer

Full zero trust architecture guide: Zero Trust Multi-Cloud

Writing Kubernetes NetworkPolicies That Actually Work

Citadel Cloud Management — Thu, 09 Jul 2026 16:02:28 +0000

NetworkPolicies are the most under-used security feature in Kubernetes. Most clusters I audit have zero network segmentation -- every pod can talk to every other pod. Here is how to fix that.

Step 1: Default Deny Everything

Apply this to every namespace before writing any allow rules:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This blocks ALL traffic to and from every pod in the namespace. Yes, your application will break. That is the point -- now you explicitly allowlist only the traffic that should exist.

Step 2: Allow DNS (Critical)

Without DNS egress, nothing works. Apply this immediately after the default deny:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Step 3: Allow Specific Service-to-Service Traffic

Example: allowing a frontend to talk to an API backend:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Common Mistakes

Forgetting DNS egress. Your pods need to resolve service names. Without the DNS egress rule, every network call hangs indefinitely.
Using namespaceSelector: {} (empty selector). This matches ALL namespaces, which defeats the purpose. Always use specific label selectors.
Not testing with a network policy-capable CNI. The default kubenet CNI does NOT enforce NetworkPolicies. You need Calico, Cilium, or Weave Net.
Applying directly to production. Test in a staging environment first.

Debugging NetworkPolicies

# List all policies in a namespace
kubectl get networkpolicy -n production

# Test connectivity between pods
kubectl exec -n production frontend-pod -- curl -m 5 api-backend:8080/health

If curl hangs (no connection refused, just timeout), a NetworkPolicy is blocking the traffic.

Comprehensive K8s security guide: Kubernetes Security Best Practices

Building a DevSecOps Pipeline with GitHub Actions: My Production Config

Citadel Cloud Management — Thu, 09 Jul 2026 15:55:56 +0000

Here is the exact GitHub Actions workflow I use to catch security vulnerabilities before they reach production. Every tool is open source. Total cost: $0.

The Workflow File

name: security-pipeline
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Gitleaks secret detection
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

  dependency-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy vulnerability scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'

  container-scan:
    runs-on: ubuntu-latest
    needs: [dependency-scan]
    steps:
      - uses: actions/checkout@v4
      - name: Build container
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy image scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'app:${{ github.sha }}'
          severity: 'CRITICAL'
          exit-code: '1'

  infrastructure-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Checkov IaC scan
        uses: bridgecrewio/checkov-action@master
        with:
          directory: ./terraform
          framework: terraform
          soft_fail: false

Why This Order Matters

Secret scanning runs first and independently. If there are hardcoded credentials, nothing else matters -- stop the pipeline immediately.

Dependency scanning runs before container scanning because if the dependency file has a critical CVE, building the container is wasted compute.

Infrastructure scanning runs independently because it does not depend on the application build.

Threshold Tuning

The most important decision is what severity breaks the build:

Secret detection: Any finding = build failure. Zero tolerance.
Dependency scanning: CRITICAL + HIGH with known exploits = build failure.
Container scanning: CRITICAL only = build failure. HIGH creates a ticket.
IaC scanning: Security misconfigurations = build failure. Best practice recommendations = warning.

Getting the thresholds wrong in either direction kills adoption. Too strict, and developers route around the pipeline. Too lenient, and the pipeline provides false confidence.

Full DevSecOps guide: DevSecOps Pipeline Tutorial

What Is DevOps? Everything You Need to Know in 2026

Citadel Cloud Management — Mon, 29 Jun 2026 14:41:49 +0000

Quick answer: DevOps combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.

Key Numbers

7,000+ deployments per day at elite organizations (DORA 2024)
208x faster lead time for elite vs low performers
24x faster incident recovery
$17.2 billion global DevOps market (2025)

The Three Pillars

Culture. Shared ownership, blameless postmortems, continuous learning.
Automation. CI/CD pipelines, Infrastructure as Code, automated testing.
Measurement. DORA metrics: deployment frequency, lead time, failure rate, recovery time.

Core Practices

CI/CD

Developers merge frequently. Each merge triggers automated builds and tests.
Tools: GitHub Actions, GitLab CI/CD, Jenkins, ArgoCD

Infrastructure as Code

Manage infrastructure through version-controlled config files.
Tools: Terraform, CloudFormation, Pulumi, Ansible

Monitoring and Observability

Three pillars: metrics, logs, traces.
Tools: Prometheus, Grafana, Datadog, OpenTelemetry

Read the full guide covering DevSecOps, team structures, and career paths ->

Originally published at Citadel Cloud Management.

How to Become a Cloud Architect in 2026: Step-by-Step Career Guide

Citadel Cloud Management — Mon, 29 Jun 2026 14:41:17 +0000

Cloud architects earn between $150,000 and $250,000 per year in the US (Robert Half 2026). Remote cloud architects from Africa report $60,000-$120,000 annually.

What a Cloud Architect Actually Does

Designing infrastructure -- Selecting AWS, Azure, GCP configurations
Creating architecture blueprints -- System designs for engineering teams
Security and compliance -- IAM, encryption, SOC 2, HIPAA, PCI-DSS
Cost optimization -- Enterprise cloud bills exceed $1M/month
Stakeholder communication -- Presenting to CTOs and VPs

Required Skills: Four Pillars

Pillar 1: Cloud Platform Expertise

Deep proficiency in at least one: AWS (31%), Azure (25%), or GCP (11%)

Pillar 2: Infrastructure and DevOps

Terraform, Docker, Kubernetes, CI/CD, Monitoring

Pillar 3: Security Architecture

IAM, encryption, network security, compliance frameworks

Pillar 4: Communication and Leadership

Design documents, executive presentations, technical tradeoffs

Career Timeline

Stage	Timeline	Salary (US)
Junior Cloud Engineer	Years 0-2	$80K-$120K
Mid-Level	Years 2-4	$120K-$155K
Senior Cloud Engineer	Years 4-6	$150K-$185K
Cloud Architect	Years 6-10	$170K-$220K
Principal Architect	Years 10+	$200K-$300K+

Read the full guide with portfolio projects and interview prep ->

Originally published at Citadel Cloud Management.

Dimension	Containers	Serverless
Startup time	Seconds to minutes	Milliseconds to seconds
Max execution	Unlimited	15 minutes (Lambda)
Cost model	Per-hour (even idle)	Per-invocation + duration
Best for	Long-running services	Event-driven processing

Remote Cloud Jobs From Africa: How to Land $2K-$8K/Month Working Remotely

Citadel Cloud Management — Mon, 29 Jun 2026 14:40:27 +0000

There are over 47,000 open remote cloud computing positions that accept candidates from African countries (April 2026 data from 14 job platforms). That number was 12,000 in 2022.

Salary Ranges

Nigeria: Junior $2K-3.5K/mo, Mid $3.5K-5.5K/mo, Senior $5.5K-8K/mo, Architect $7K-12K/mo
Kenya: Mid-level $3K-5K/mo (Nairobi = Silicon Savannah)
South Africa: Senior $6K-8.5K/mo
Ghana: Mid-level $3K-5K/mo

Where to Find These Jobs

Turing.com -- AI-matched, pays in USD
Toptal -- Top 3% screening, premium rates
Andela -- Africa-focused
Arc.dev -- Transparent salaries
LinkedIn Remote -- Filter Remote, target US/EU companies

Full guide with payment methods, tax strategies, interview tips ->

Originally published at Citadel Cloud Management.

Best Cloud Certifications 2026: 12 Certs Ranked by ROI and Salary Impact

Citadel Cloud Management — Mon, 29 Jun 2026 14:40:00 +0000

Certifications are an investment. They cost money, they consume study hours, and they carry an opportunity cost.

I have held certifications across AWS, Azure, and Kubernetes since 2018. This ranking is built on direct observation combined with 2025-2026 salary data from Global Knowledge, Dice, and LinkedIn.

How ROI Was Calculated

ROI score is a weighted composite: Salary uplift (40%), Market demand (25%), Cost efficiency (20%), Time efficiency (15%).

Top 5 Certifications by ROI

1. AWS Solutions Architect Associate (SAA-C03) -- ROI: 9.4/10

Exam Cost: $150 | Study Time: 120-160 hrs | Salary Uplift: +$26K/year

2. Azure Administrator (AZ-104) -- ROI: 8.9/10

3. Terraform Associate -- ROI: 8.7/10

4. Kubernetes CKA -- ROI: 8.5/10

5. AWS Solutions Architect Professional -- ROI: 8.3/10

Certification Stacking Strategy

Cloud Engineer Stack: AWS SAA + Terraform + CKA
Enterprise Architect Stack: AZ-104 + AZ-305 + AWS SAA

Read the full ranking of all 12 certifications ->

Originally published at Citadel Cloud Management.

DevOps vs SRE: Key Differences Explained [2026 Guide]

Citadel Cloud Management — Mon, 29 Jun 2026 14:38:43 +0000

After managing infrastructure teams at Lockheed Martin, Cigna Healthcare, and BP Refinery, I have seen the DevOps-versus-SRE question play out in hiring committees, organizational redesigns, and vendor negotiations hundreds of times.

But they are not the same role. The distinction matters for your career trajectory, your compensation, and the type of problems you solve daily.

Origins: Where Each Discipline Came From

DevOps emerged around 2008-2009 from the Agile and Lean movements. The core insight was that separating development and operations into isolated teams created bottlenecks.

Site Reliability Engineering (SRE) was formalized at Google by Ben Treynor Sloss around 2003.

Core Responsibilities Compared

Dimension	DevOps Engineer	Site Reliability Engineer
Primary focus	Delivery velocity and automation	System reliability and performance
Key metric	Deployment frequency, lead time	SLOs, SLIs, error budgets
Code ratio	40-60% automation, 40-60% operations	50%+ software engineering

Salary Comparison (2026)

Role	US Average	Remote (International)
DevOps Engineer	$130K-$170K	$50K-$100K
Senior DevOps Engineer	$155K-$195K	$70K-$120K
Site Reliability Engineer	$150K-$200K	$60K-$120K
Senior SRE	$180K-$240K	$80K-$150K

SRE roles consistently pay 10-20% more than equivalent DevOps roles.

Read the full comparison with tool stacks, career transition paths, and hiring patterns ->

Originally published at Citadel Cloud Management. 17 free cloud courses available -- no credit card required.

Terraform for Beginners: Your First Infrastructure as Code Project

Citadel Cloud Management — Mon, 29 Jun 2026 14:32:47 +0000

When I first joined Patterson UTI as a cloud architect, the infrastructure team was managing hundreds of EC2 instances through a mix of hand-clicked AWS Console actions and homegrown Bash scripts. Rebuilding the same stack in a disaster recovery scenario took two engineers three days. After we moved to Terraform, that rebuild became a fifteen-minute terraform apply.

That is the promise of Infrastructure as Code -- not a theoretical improvement, but a concrete operational shift that changes how your team recovers, scales, and audits.

What Terraform Is (And What It Is Not)

Terraform is an open-source Infrastructure as Code tool built by HashiCorp. You describe the infrastructure you want in HCL files, and Terraform figures out what to create, modify, or destroy to reach that desired state. It is declarative -- you describe the end state, not the steps to get there.

Your First HCL File: The AWS Provider

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

Creating an S3 Bucket

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-terraform-demo-bucket-2026"
  tags = {
    Environment = "dev"
    ManagedBy   = "terraform"
  }
}

Run these three commands:

terraform init    # Download the AWS provider
terraform plan    # Preview what Terraform will create
terraform apply   # Create the resources

Read the full guide covering modules, workspaces, production patterns, and a complete EC2 + VPC project ->

Originally published at Citadel Cloud Management. 17 free cloud courses available -- no credit card required.

Kubernetes CKA Certification Study Guide 2026: Pass First Try

Citadel Cloud Management — Mon, 29 Jun 2026 14:30:03 +0000

I passed the CKA exam on my first attempt in 2024. The certification cost $395, required two hours of hands-on problem-solving in a live terminal, and tested knowledge that I use daily in production Kubernetes environments. It was the second most valuable certification I have earned after the AWS Solutions Architect Professional.

This guide is the study plan I wish I had before starting.

CKA Exam Overview: 2026 Format

Detail	Value
Certifying body	CNCF / Linux Foundation
Kubernetes version	1.30+
Exam format	Performance-based (live terminal, real clusters)
Duration	2 hours
Tasks	15-20 practical tasks
Passing score	66%
Cost	$395 USD (includes one free retake)
Validity	3 years
Allowed resources	Official Kubernetes docs during exam

The exam is not multiple choice. You solve real problems in real clusters.

Exam Domains and Weights

Domain	Weight
Cluster Architecture, Installation, and Configuration	25%
Workloads and Scheduling	15%
Services and Networking	20%
Storage	10%
Troubleshooting	30%

Two critical observations:

Troubleshooting is 30% of the score. If you cannot diagnose a broken cluster, a failed kubelet, or a misconfigured NetworkPolicy under time pressure, you will not pass.
Cluster management is 25%. This is frequently under-practiced. You need to upgrade a cluster using kubeadm and restore an etcd snapshot from the command line without looking up every flag.

8-Week Study Plan (10-15 hrs/week)

Weeks 1-2: Core Concepts and Cluster Setup

Kubernetes architecture: control plane and worker node components
Install a multi-node cluster using kubeadm
kubectl fluency: create, get, describe, edit, delete, apply, explain

Weeks 3-4: Workloads and Scheduling

Deployments, ReplicaSets, DaemonSets, StatefulSets
Resource requests and limits
Node selectors, affinity, taints, and tolerations

Weeks 5-6: Services, Networking, and Storage

ClusterIP, NodePort, LoadBalancer services
Ingress controllers and rules
NetworkPolicies
PersistentVolumes, PersistentVolumeClaims, StorageClasses

Weeks 7-8: Troubleshooting and Exam Practice

Diagnose node failures, pod failures, service connectivity
Backup and restore etcd
Cluster upgrades with kubeadm
Timed practice exams

Time Management: The Real Exam Skill

The CKA is a speed test. You have 120 minutes for 15-20 tasks. That is 6-8 minutes per task. The candidates who fail are not the ones who lack knowledge -- they are the ones who spend 15 minutes on a 4-point question and run out of time before reaching the 12-point questions.

My approach: scan all questions first. Answer every question you can solve in under 5 minutes. Flag harder questions for a second pass.

Read the complete study guide with kubectl cheat sheet, lab setup instructions, and practice scenarios ->

Originally published at Citadel Cloud Management. 17 free cloud courses available -- no credit card required.

DEV Community: Citadel Cloud Management

Docker Multi-Stage Build Patterns That Cut My Image Sizes by 80%

Pattern 1: Builder and Runtime Separation

Pattern 2: Distroless for Compiled Languages

Pattern 3: Python with Virtual Environment Copy

Size Comparison

Common Mistakes

Implementing mTLS Across Multi-Cloud Services with SPIFFE/SPIRE

Why Not Just Use a Service Mesh?

Architecture Overview

Key Design Decisions

Debugging mTLS Failures

Writing Kubernetes NetworkPolicies That Actually Work

Step 1: Default Deny Everything

Step 2: Allow DNS (Critical)

Step 3: Allow Specific Service-to-Service Traffic

Common Mistakes

Debugging NetworkPolicies

Building a DevSecOps Pipeline with GitHub Actions: My Production Config

The Workflow File

Why This Order Matters

Threshold Tuning

What Is DevOps? Everything You Need to Know in 2026

Key Numbers

The Three Pillars

Core Practices

CI/CD

Infrastructure as Code

Monitoring and Observability

How to Become a Cloud Architect in 2026: Step-by-Step Career Guide

What a Cloud Architect Actually Does

Required Skills: Four Pillars

Pillar 1: Cloud Platform Expertise

Pillar 2: Infrastructure and DevOps

Pillar 3: Security Architecture

Pillar 4: Communication and Leadership

Career Timeline

Top 30 Cloud Architect Interview Questions and Answers [2026]

Foundational Architecture Questions

1. What is the difference between high availability and fault tolerance?

2. Explain the CAP theorem and how it applies to cloud database selection.

3. How do you design a multi-region active-active architecture?

4. Containers vs. serverless -- when do you choose each?

Remote Cloud Jobs From Africa: How to Land $2K-$8K/Month Working Remotely

Salary Ranges

Where to Find These Jobs

Best Cloud Certifications 2026: 12 Certs Ranked by ROI and Salary Impact

How ROI Was Calculated

Top 5 Certifications by ROI

1. AWS Solutions Architect Associate (SAA-C03) -- ROI: 9.4/10

2. Azure Administrator (AZ-104) -- ROI: 8.9/10

3. Terraform Associate -- ROI: 8.7/10

4. Kubernetes CKA -- ROI: 8.5/10

5. AWS Solutions Architect Professional -- ROI: 8.3/10

Certification Stacking Strategy

DevOps vs SRE: Key Differences Explained [2026 Guide]

Origins: Where Each Discipline Came From

Core Responsibilities Compared

Salary Comparison (2026)

Terraform for Beginners: Your First Infrastructure as Code Project

What Terraform Is (And What It Is Not)

Your First HCL File: The AWS Provider

Creating an S3 Bucket

Kubernetes CKA Certification Study Guide 2026: Pass First Try

CKA Exam Overview: 2026 Format

Exam Domains and Weights

8-Week Study Plan (10-15 hrs/week)

Weeks 1-2: Core Concepts and Cluster Setup

Weeks 3-4: Workloads and Scheduling

Weeks 5-6: Services, Networking, and Storage

Weeks 7-8: Troubleshooting and Exam Practice

Time Management: The Real Exam Skill