Coder Legion - Recent posts tagged devops-infra

Webernetes: Kubernetes in your browser?

Mon, 17 Aug 2026 15:55:35 +0000

Webernetes is an experimental project developed by ngrok that ports a functional subset of Kubernetes directly into the browser, executing completely on the client side without relying on any backend server infrastructure. Built primarily as an interactive simulator, it allows users to boot up isolated virtual clusters and define simulated container images directly in TypeScript / JavaScript. Instead of pulling heavy container binaries or running Docker daemons, Webernetes mimics core control plane mechanics, pod scheduling, and network handling down to HTTP routing, service discovery, and deployment strategies right in the browser runtime.

Here is a test project that I spun-up for Webernetes:
https://ndouglas-edera.github.io/my-webernetes-demo

When compared to spinning up a real infrastructure cluster on cloud providers or managed platforms, Webernetes eliminates the operational weight of traditional cluster management. A real production or staging Kubernetes deployment requires provisioning control nodes, configuring container runtimes like containerd, managing complex networking overlays, and continuously maintaining underlying compute instances. Webernetes bypasses this entirely by mocking container lifecycles and TCP/HTTP traffic natively in JavaScript. All of the instructions can be easily scripted in a 100 lines or less of TypeScript through a centralised main.ts source file:
https://github.com/ndouglas-edera/my-webernetes-demo/edit/main/src/main.ts

This translates to near-instantaneous cluster startup times, with zero setup friction for end users, and a radically reduced maintenance burden for educators, technical writers, or visual platform creators who want to showcase Kubernetes concepts without wrestling with real cloud instances. In my cases, I want to build cluster labs where users can perform insecure behaviours, container escapes, and other Kubernetes security test scenarios, without actually allowing those same users to abuse cloud resources through cryptominers, exfiltrate real credentials, or any other obviously undesirable outcomes.

From a financial perspective, the cost savings of moving simulation workloads to Webernetes are substantial. Hosting interactive tutorials, live documentation, or architecture demos on traditional cloud infrastructure incurs ongoing costs for control planes, compute nodes, load balancers, and egress bandwidth that accumulate regardless of traffic volume. Webernetes shifts the entire computational load to the visitor’s device, completely cutting out backend compute, hosting, and API costs. Because the browser executes the cluster logic locally, the hosting requirements collapse down to serving static web assets, making long-term interactive Kubernetes content practically free to maintain forever. Essentially, I can recreate a sort of "fake" Katacoda (now deprecated) or Instruqt lab that users can mess around with at any time.

Evaluating scale against a physical homelab setup, such as my existing cluster of Raspberry Pis, reveals a distinct shift in trade-offs between my existing physical resource limits and seemingly limitless browser-bound agility. While a physical Raspberry Pi homelab provides actual ARM nodes, real Linux kernels, and genuine network interfaces capable of running real Docker containers, it demands physical power, cooling, cabling, and ongoing hardware upkeep. Furthermore, a homelab cluster is bounded by fixed hardware capacity and local network constraints, making it tricky to share scale horizontally with thousands of concurrent online users. In contrast, Webernetes scales endlessly across web visitors because each user instantly gets their own isolated, sandboxed cluster powered by their local machine's memory and CPU. Although Webernetes cannot run real un-ported container images, mount true block storage, or handle real raw IP/UDP protocols like physical hardware can, its client-side architecture makes it far superior for scaling interactive learning experiences, rapid prototyping, and reproducible architectural demos to a global audience without ever burning out a single physical node.

If anything in this project sounds exciting, or if you have questions for me on my usage of this project, feel free to ask in the comment sections. I hope you're as excited about Webernetes as I am.

Dashboard Design for Incident Response

Thu, 02 Jul 2026 15:12:56 +0000

Most dashboards answer one question: Is everything okay?

During an incident, nobody's asking that.

The real question: What broke, where, and what changed?

Most dashboards fail at incidents because they were built for monitoring, not troubleshooting.

The Problem

A typical dashboard shows CPU, memory, disk, network, requests, uptime.

Useful for routine checks.

During an outage? Just noise.

You're not looking for reassurance. You're looking for evidence.

Two Different Jobs

Most teams put everything on one dashboard. That's a compromise that doesn't work for either job.

Monitoring dashboard: Is the platform healthy? SLAs being met? Resources used correctly?

Incident dashboard: What failed? When? What changed? Where do I look next?

Same tools, different purposes.

What Works During an Outage

Error rate front and center. 5XX errors, exceptions, failed transactions. Failures tell the story faster than CPU metrics.

Timeline on the graph. Mark deployments, infrastructure changes, scaling events. Most incidents start right after something changed. Make this visible in one second.

Dependency health. A healthy app talking to a dead database is not healthy. Dependencies often point to root cause faster than app metrics.

Golden signals. Latency, traffic, errors, saturation. These beat hundreds of infrastructure metrics.

Logs visible. Top exceptions, error spikes, failed endpoints. Reduce tab-switching during incidents.

Service map. Which services depend on the failing one? Visual dependency maps answer this instantly.

Alert state. Which alerts fired? Which started first? First alert usually beats alert #100 for root cause.

The Test

For every panel: How does this help me resolve the incident faster?

If the answer isn't obvious, remove it.

Example

EKS outage. Don't show cluster CPU and memory.

Show:

Failed requests by service
Pod restarts
Readiness failures
Recent deployments
HPA scaling events
Dependency latency
Top exceptions
Queue backlogs

One tells you the cluster exists. The other helps you fix it.

The Point

Monitoring dashboards tell you something broke.

Incident dashboards help you figure out why.

During an outage, only the second one matters.

DevOps #SRE #Monitoring #Kubernetes #IncidentResponse #Dashboard

I released oteldoctor v0.1.0 — an open-source Go CLI for checking OpenTelemetry Collector config

Fri, 22 May 2026 14:34:21 +0000

OpenTelemetry Collector configs are easy to grow and hard to reason about.

A config can be valid and still have production risks:

exporters:
  otlphttp:
    endpoint: http://backend.example.com
    headers:
      X-API-KEY: "hardcoded-secret"

or:

service:
  pipelines:
    traces:
      processors: [batch, memory_limiter]

These are the kinds of things oteldoctor is designed to catch.

What it does

oteldoctor checks:

undefined receivers/processors/exporters
missing memory_limiter
wrong processor order
missing retry/queue config
hardcoded secrets
plain HTTP exporters
debug exporters in production
high-cardinality attributes
missing sampling/filtering hints
semantic convention issues
Kubernetes readiness gaps

Commands

oteldoctor analyze ./deploy --profile production
oteldoctor analyze ./deploy --format json
oteldoctor analyze ./deploy --format sarif > oteldoctor.sarif
oteldoctor graph collector.yaml --format mermaid
oteldoctor explain OTEL-SEC-202
oteldoctor fix collector.yaml --dry-run

Install

go install github.com/firfircelik/oteldoctor/cmd/oteldoctor@v0.1.0

Why it exists

This is not a replacement for Collector validation.

It is more like a production-readiness layer for Collector configs.

The goal is to catch reliability, security, cost, semantic, and Kubernetes deployment risks earlier — ideally in CI, before the config is deployed.

GitHub: https://github.com/firfircelik/oteldoctor

If you work with OpenTelemetry Collector, I’d really appreciate feedback, issue reports, and real-world config edge cases.

Tofu Provider Fabric

Fri, 24 Apr 2026 21:16:58 +0000

OpenTofu modules for simple cross-cloud VM and networking workflows on AWS and OpenStack. Built to keep small infrastructure setups practical, reusable, and easy to follow.

Building Friday: A Multi-Provider AI Agent That Lives in Your Terminal

Sat, 11 Apr 2026 16:07:32 +0000

Building Friday: A Multi-Provider AI Agent That Lives in Your Terminal

Every DevOps Engineer has a terminal open. What if that terminal could think?
Friday - an open-source, multi-provider AI agent that runs entirely in your terminal. No browser tabs, no Electron apps, no subscriptions bundling features you don't need. Just a clean, minimal CLI that connects to Gemini, ChatGPT, Claude, GitHub Copilot, or your own local Ollama server - and lets you switch between them with a single command.
In this post, I'll walk through why I built it, the architecture behind it, and how you can install it in one command.
In this post, I'll walk through why I built it, the architecture behind it, and how to install it with a single command.
What Friday Delivers
Friday is a terminal-native AI agent with three core capabilities:

Multi-Provider Chat
Connect to any major AI provider through a unified interface:
The Problem
Modern AI workflows are fragmented:
Multiple browser tabs (ChatGPT, Claude, Gemini)
Constant copy-paste between the terminal and AI tools
No direct execution - only suggestions

Even simple queries, like checking disk usage, require manual execution after being asked.
The requirement was clear:
A single interface that supports multiple models and can perform real actions on the machine.
What Friday Delivers

Unified Multi-Provider Interface
Friday integrates major AI providers into one CLI:
available providersModel availability is dynamically fetched via APIs - ensuring accuracy without manual updates.
Agentic Capabilities for DevOps
Friday is built for execution, not just conversation.
Core capabilities:
Shell command execution (with confirmation)
File operations (read, write, search)
Web search integration
System diagnostics (CPU, memory, disk)
Python execution

Example:
Instead of suggesting commands, Friday directly performs tasks like file discovery or diagnostics.
All critical operations require explicit confirmation, ensuring safety.

Voice Interaction
Voice support enables hands-free interaction:
Toggle via /voice
Speak queries with empty input
Configure pitch, speed, and voice profile

This is particularly useful during troubleshooting or multitasking scenarios.
Architecture Overview
Friday follows a modular, provider-agnostic architecture:
Application Layer (CLI + Commands)

↓

Friday Client (Abstraction Layer)

↓

Providers (Gemini, OpenAI, Claude, Copilot, Ollama)
Provider Abstraction
Each provider implements a common interface:
class BaseProvider(ABC):

def initialize(self): ...
def chat(self, message, history, tools): ...
@property
def model(self): ...

This enables seamless extensibility with minimal integration effort.
Tool System
Tools are defined once and adapted across providers:
@register_tool
def get_system_info():

return {...}

A universal schema ensures compatibility across different APIs.
Dynamic Model Discovery
Friday queries provider APIs at runtime:
Eliminates outdated configurations
Supports local and remote Ollama instances
Ensures real-time model availability

Command System
A structured command interface simplifies interaction:
/login Connect provider
/switch Change provider
/model Select model
/logout Remove credentials
/voice Toggle voice
/voice config Configure voice
/tools List tools
/help Show commands
bye Exit
Credentials are securely stored with restricted permissions.
User Interface
Built using the Rich library, the UI is clean and minimal:
Color-coded provider panels
Markdown rendering with syntax highlighting
Interactive menus
Lightweight terminal-first design

The focus remains on usability rather than visual complexity.
Getting Started
Installation
git clone https://github.com/mahinshanazeer/friday.git && cd friday && bash install.sh
First Run
friday
Authenticate using /login, and the session persists for future use.
Uninstall
cd friday && bash uninstall.sh
Key Learnings

Provider APIs Differ Significantly
Function-calling implementations vary widely across providers, requiring a unified abstraction layer.
Terminal UX Matters
Design improvements significantly impact usability and adoption.
Reliability Is Critical
Graceful handling of missing dependencies or failures ensures stability.
Persistence Improves Experience
Credential storage transformed the tool from experimental to practical.
Built Using AI
Friday itself was built using AI-assisted development:
Antigravity - architecture and scaffolding
GitHub Copilot - inline coding
Claude - design validation and reviews

Workflow:
Define architecture via prompts
Iteratively build features
Debug and refine using AI

Result: A production-ready system built in hours rather than weeks.
Roadmap
Planned improvements include:
Streaming responses
Chat export functionality
Plugin architecture
Multi-modal input (image support)
Git integration

Repository
https://github.com/mahinshanazeer/friday
git clone https://github.com/mahinshanazeer/friday.git && cd friday && bash install.sh
Closing Note
Friday is built on a simple principle:
Your terminal should not just execute commands - it should assist, decide, and act.

CI/CD That Ships Itself: Our GitHub Actions Blueprint

Tue, 09 Dec 2025 12:06:26 +0000

CI/CD That Ships Itself: Our GitHub Actions Blueprint

(Pocket Portfolio — 12 Weeks of Shipping)

Fast releases are only useful if they are consistent and safe.
This post breaks down Pocket Portfolio’s CI/CD pipeline on GitHub Actions: how we lint, type-check, test against Firebase emulators, run Playwright smoke tests, and then canary-deploy to the Edge.

The goal is simple: every commit proves it can ship itself.

Pipeline Overview

Stages executed per pull request and on main:

1) Lint and TypeCheck
2) Build with reproducible caching
3) Firebase emulator tests (unit and integration)
4) Playwright UI smoke tests
5) Artifact capture (build, coverage, screenshots)
6) Canary deploy to next.pocketportfolio.app with manual approval
7) Post-deploy health checks and auto-rollback

We use:

GitHub Actions matrix to cover Node versions and Next.js runtime modes
Project-level concurrency to avoid clobbering environments
Required checks enforced by branch protection rules

Repository Structure (relevant parts)


.github/
workflows/
ci.yml
deploy-canary.yml
apps/
web/                  # Next.js 14 app
packages/
ui/                   # shared components
config/               # ESLint, TS config
tests/
e2e/                  # Playwright specs
seeds/                # Firebase test data

Workflow 1: CI (PR and main)

./github/workflows/ci.yml

name: CI

on:
  pull_request:
    branches: [ main ]
  push:
    branches: [ main ]

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

jobs:
  setup:
    name: Setup
    runs-on: ubuntu-latest
    outputs:
      node: ${{ steps.matrix.outputs.node }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - name: Install
        run: pnpm install --frozen-lockfile

  lint_typecheck:
    name: Lint and TypeCheck
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - run: pnpm eslint .
      - run: pnpm tsc -p tsconfig.json --noEmit

  build:
    name: Build
    needs: [setup, lint_typecheck]
    runs-on: ubuntu-latest
    env:
      NEXT_TELEMETRY_DISABLED: 1
      NODE_ENV: production
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Build web
        run: pnpm --filter ./apps/web build
      - name: Upload build artifact
        uses: actions/upload-artifact@v4
        with:
          name: web-build
          path: apps/web/.next

  test_emulators:
    name: Firebase Emulator Tests
    needs: build
    runs-on: ubuntu-latest
    services:
      firestore:
        image: docker.io/bitnami/firebase-emulator:latest
        ports:
          - 4000:4000
          - 8080:8080
          - 9099:9099
          - 9199:9199
    env:
      FIREBASE_AUTH_EMULATOR_HOST: localhost:9099
      FIRESTORE_EMULATOR_HOST: localhost:8080
      GCLOUD_PROJECT: test-project
      NODE_ENV: test
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Seed test data
        run: pnpm tsx tests/seeds/seed.ts
      - name: Unit and integration tests
        run: pnpm test -- --reporter=junit --coverage
      - name: Upload coverage
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage

  e2e_smoke:
    name: Playwright Smoke (headless)
    needs: test_emulators
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Install browsers
        run: pnpm exec playwright install --with-deps
      - name: Run smoke tests
        env:
          BASE_URL: http://localhost:3000
        run: |
          pnpm --filter ./apps/web dev & sleep 8
          pnpm exec playwright test tests/e2e/smoke.spec.ts --reporter=line
      - name: Upload Playwright artifacts
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: playwright-artifacts
          path: |
            playwright-report
            test-results

What this does:

Cancels superseded runs automatically
Builds once and reuses artifacts
Spins Firebase emulators for realistic tests
Runs Playwright in headless mode against a local dev server

Workflow 2: Canary Deploy to Edge

./github/workflows/deploy-canary.yml

name: Deploy Canary

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches: [ main ]

permissions:
  contents: read
  deployments: write
  id-token: write

concurrency:
  group: deploy-canary
  cancel-in-progress: false

jobs:
  gate:
    name: Require green CI
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo "CI passed, proceeding to deploy."

  deploy:
    name: Deploy to next.pocketportfolio.app
    needs: gate
    runs-on: ubuntu-latest
    environment:
      name: canary
      url: https://next.pocketportfolio.app
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'
      - uses: pnpm/action-setup@v4
        with:
          version: 9
      - run: pnpm install --frozen-lockfile
      - name: Build
        run: pnpm --filter ./apps/web build
      - name: Vercel Deploy (Edge)
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          working-directory: ./apps/web
          scope: ${{ secrets.VERCEL_ORG_ID }}
          prod: false
      - name: Health check
        run: |
          curl -fsSL https://next.pocketportfolio.app/api/health || exit 1
          curl -fsSL https://next.pocketportfolio.app/api/health-price || exit 1

Notes:

workflow_run ensures deploy runs only after CI succeeds on main.
Environment protection rules can require manual approval inside GitHub before the deploy job starts.
We target Edge by configuring Vercel project functions to run on the Edge runtime.

Health Checks and Auto-Rollback

We keep deploys safe with a simple pattern:

After deployment, curl health and quote endpoints
If any return non-2xx, mark the job failed
A failing canary keeps production untouched

Optional rollback step (if you use Vercel Protected Branches):

      - name: Roll back canary to previous deployment
        if: failure()
        run: |
          echo "Rolling back..."
          # Example: pin to previous successful alias or commit sha via Vercel CLI

Speed and Stability Techniques

Caching: actions/setup-node with cache: pnpm cuts install time.
Concurrency: single deploy job at a time prevents environment drift.
Artifacts: store build output and Playwright results for debugging.
Separate concerns: CI proves code is safe; deploy workflow just ships.
Emulators: Firebase emulator suite catches integration issues locally and in CI.

Failure Modes We Handle

Stuck third-party provider: Playwright tests stub provider responses for critical flows.
Flaky UI timing: Playwright uses test id selectors and realistic waits.
Race conditions: matrix and concurrency settings keep builds deterministic.

Minimal Smoke Spec Example

tests/e2e/smoke.spec.ts

import { test, expect } from '@playwright/test';

test('dashboard loads and shows health badge', async ({ page }) => {
  await page.goto('/');
  await expect(page.getByTestId('health-badge')).toHaveText(/healthy|degraded/);
});

test('price endpoint responds', async ({ request }) => {
  const res = await request.get('/api/health-price');
  expect(res.ok()).toBeTruthy();
});

What To Measure

CI total duration (target: under 8 minutes for PRs)
Flake rate (target: below 1 percent over 30 days)
Canary failure rate and mean time to recovery
Playwright runtime and retries per suite

Assets

Workflow diagram (Setup -> Lint -> Build -> Emulators -> Playwright -> Canary Deploy)
Screenshots of GitHub Checks and Environment approvals
Example Playwright report

TL;DR

Every commit runs the same path production will run: build, test, verify, deploy, and prove it is healthy.
If any step fails, the release stops itself. That is CI/CD that ships itself.

CI/CD Security Mistake: Are You Giving Your Build Container Root Access to Your Server?

Sat, 01 Nov 2025 20:48:28 +0000

The Dangerous Truth About Running Docker Inside Docker (DinD vs. DooD)

A robust Continuous Integration/Continuous Delivery (CI/CD) pipeline often requires building, testing, or pushing new container images. To do this from within your Jenkins, GitLab, or GitHub Actions agent, you need access to a Docker daemon.

This need often leads developers to adopt one of two patterns, and choosing the wrong one is one of the most common and critical security mistakes you can make in production. This isn't just about convenience; it's about host security.

Pattern 1: Docker-Out-of-Docker (DooD) - The Hidden Trap ⚠️

DooD is the most common pattern because it's the easiest to set up, but it is fundamentally dangerous.

The Mechanism

In the DooD pattern, your build container (e.g., your Jenkins Agent) does not run its own Docker daemon. Instead, you mount the host machine's Docker socket into the container:

# docker-compose.yml (DooD Example)
volumes:
  - /var/run/docker.sock:/var/run/docker.sock

The Security Problem: Root Escape

The Docker socket (/var/run/docker.sock) is the gateway to the Docker Engine, which runs with root privileges on your host server. By mounting this socket, you grant the container full, unrestricted control over the entire host's Docker environment.

The Risk: A successful exploit (e.g., a vulnerable dependency in your build tool) inside your container can execute a command like this:
```
# A single command to escape the container sandbox:
docker run -v /:/host_root -it ubuntu sh
```
This command instantly mounts the host server's root filesystem (/) into the new container, giving the attacker root access to your entire build machine. This is a complete violation of the Principle of Least Privilege.

️ Pattern 2: Docker-in-Docker (DinD) - The Secure Standard

DinD is the secure, production-ready solution that isolates your build processes.

The Mechanism

With DinD, you don't use the host's socket. Instead, you launch a separate, isolated container dedicated solely to running a Docker daemon. Your build agent then communicates with this isolated daemon over the internal network.

Isolated Daemon Container: Runs a dedicated dind image (e.g., docker:dind).
Client Container (Agent): Runs a container that has the Docker CLI installed and uses the DOCKER_HOST environment variable to connect to the isolated daemon.

# docker-compose.yml (DinD Key Configuration)

jenkins-agent:
  image: custom-agent-with-docker-cli
  environment:
    # This redirects the agent's Docker commands to the isolated service!
    DOCKER_HOST: tcp://jenkins-dind:2375

jenkins-dind:
  image: docker:dind
  privileged: true # This container needs elevated privileges to run its own daemon

The Security Solution: Perfect Isolation

The agent communicates with a disposable, sandboxed environment. If the agent or any container it spawns is compromised, the attacker only gains control over the isolated DinD daemon and its temporary files. They cannot touch your host server's file system or other critical services.

Your Takeaway

Pattern	Connection Method	Security Posture	Best For
DooD	Mounts Host Socket (`/var/run/docker.sock`)	Low - Gives Host Root Access	Local development, quick proofs-of-concept.
DinD	Network Connection (`DOCKER_HOST`)	High - Isolates Risk from Host	All production CI/CD pipelines.

Don't sacrifice host security for convenience. If you must run Docker inside Docker, ensure you are using the DinD pattern to keep your production environment safe.

From Code Push to Docker Hub: CI/CD with GitHub Actions

Tue, 14 Oct 2025 05:04:53 +0000

Imagine you’re running a bakery. Every morning, you bring fresh ingredients (your new code). But instead of kneading, baking, packaging, and delivering each loaf by hand, you want a conveyor belt that handles everything the moment the ingredients arrive.

That conveyor belt is your CI/CD pipeline.
Each time you git push, it builds, tests, packages, and ships your product automatically.

In this article, we’ll create that conveyor belt for your Node.js app using GitHub Actions and Docker.

Why Automate Docker Builds?

Why It Matters
Manual builds are slow, repetitive, and error-prone. Automation brings consistency and peace of mind.

Explain Like a Friend
Think of manually assembling furniture for every order — you’ll eventually forget screws or swap panels. A factory line ensures the same result every single time. CI/CD is that factory line for software.

Real-World Example
A small dev team pushes hotfixes daily. Without automation, they rebuild locally, tag manually, and sometimes push to the wrong repo. With GitHub Actions, every push triggers a clean, predictable build → tag → push pipeline.

Action Step
Write down every manual command you currently run to deploy your Docker image. That’s your “to-automate” checklist.

Prerequisites: Accounts, Secrets & Permissions

Why It Matters
Your automation can’t log in or deploy if it doesn’t have the right keys.

Explanation
Think of GitHub and Docker Hub as two warehouses. Your CI/CD robot needs secure keys to both: one to collect the code, the other to store the built product (your image).

Real-World Example
In the demo, the author logs into Docker Hub using encrypted secrets:

DOCKER_HUB_USERNAME
DOCKER_HUB_TOKEN

These secrets are stored safely in GitHub → Settings → Secrets → Actions never in your source code.

Action Steps

Create or log into your Docker Hub account.
Generate a personal access token (instead of using your password).
In GitHub, go to Settings → Secrets → Actions, and add:

DOCKER_HUB_USERNAME

DOCKER_HUB_TOKEN

Writing the Workflow (main.yaml) — Step by Step

Why It Matters
The workflow file is your recipe — the step-by-step plan your robot will follow.

Explanation
In .github/workflows/main.yaml, you define:

When to run: (trigger event, like push)
What to run: (the jobs and steps)
How to run: (what tools or actions to use)

Key Parts

on: push: “Start the oven when new ingredients arrive.”
jobs: “Each job is a workstation — baking, packaging, shipping.”
actions/checkout@v3: “Fetch ingredients from the storage (repo).”
docker/login-action@v2: “Unlock the warehouse with your keycard (secret).”
docker/build-push-action@v3: “Bake and ship the final product.”

Example Workflow

name: Build and Push Docker Image

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_TOKEN }}

      - uses: docker/build-push-action@v3
        with:
          context: .
          push: true
          tags: yourname/app:latest

⚠️ Common Pitfalls

Wrong Dockerfile path → build fails.
Missing or misnamed secrets → login fails silently.
Forgot push: true → image never uploads.

✅ Action Step
Commit your file to .github/workflows/main.yaml and push it. Your pipeline is ready.

Build & Push: Watching It Run

Why It Matters
Seeing it work builds confidence that your automation truly works.

Explanation
Push your code, and watch:

GitHub detects the push.
Actions triggers the job.
The workflow checks out code, logs in to Docker Hub, builds, and pushes the image.

Real-World Example
In the demo, after pushing a small code change, the author refreshed Docker Hub and saw the new image tagged latest. No manual typing, no Docker commands.

Action Steps

Edit a small file (e.g., README).
Run git push.
Open GitHub → Actions tab → watch logs.
Open Docker Hub → confirm the new tag.

Counterpoints & Limitations

Private repos or registries: Require additional permissions or tokens.
Multi-service setups: Need multiple jobs or build matrix strategies.
Large images: Consider caching layers for faster builds.
Security: Always scan base images and protect secrets carefully.

Mini Case Study: “Solo Developer to One-Click Deployment”

Before:
X, a solo Node.js developer, manually built and pushed Docker images every update — often forgetting tags or pushing the wrong version.

After GitHub Actions:

Added main.yaml
Configured Docker Hub secrets
Now, every git push builds + pushes automatically

He cut his deployment time from 10 minutes to under 1, and never mistakes again.

Conclusion — From Kitchen Chaos to Conveyor Belt

We began with a bakery. You don’t want to bake, pack, and ship every loaf by hand. You want a conveyor belt that works reliably.

GitHub Actions and Docker give you that belt. As soon as you push code, your automation handles the rest — repeatable, consistent, hands-off.

Take this workflow file, plug in your secrets, push a change, and watch your pipeline come alive.

Automate your open-source project's builds & deployments with CI/CD using GitHub Actions!

Thu, 02 Oct 2025 07:00:54 +0000

Building CI/CD Pipelines (Without Losing Your Mind)

Beginner Level

Hey everyone! As members of the open-source community, we're all passionate about building awesome things – from libraries that power the internet to tools that make developers’ lives easier. But sometimes, getting those amazing contributions into production can feel… well, a bit like herding cats. That's where CI/CD pipelines come in!

What is a CI/CD Pipeline, Anyway? (Don't worry, it's not as scary as it sounds)

CI/CD stands for Continuous Integration and Continuous Delivery/Deployment. Think of it as an automated assembly line for your code.

Continuous Integration (CI): Whenever someone commits code to your repository, the CI system automatically pulls that code, builds it, runs tests, and checks for integration issues. It's like constantly merging small updates instead of waiting for a massive, potentially disastrous, merge at the end. This helps catch bugs early and keeps your codebase healthy.
Continuous Delivery (CD): Takes the CI step a little further by automating the process of releasing your code to a staging or testing environment. It ensures that your software is always in a deployable state.
Continuous Deployment (also CD): The ultimate goal! Automates the entire release process, including deploying code directly to production after passing all tests. This allows for faster feedback loops and quicker delivery of value to users.

Why Should We Care? (Besides Saving Our Sanity)

For open-source projects, a solid CI/CD pipeline offers huge benefits:

Faster Feedback: Developers get instant notifications when their code breaks something.
Reduced Risk: Automated tests catch bugs before they reach users. (Nobody likes a surprise bug!)
Increased Confidence: Knowing your code is consistently tested and deployed gives you peace of mind.
Easier Collaboration: Everyone benefits from clear, automated workflows.
More Time for Innovation: Less time spent on manual deployment means more time coding!

Building Your Own Pipeline

Okay, enough theory. Let's dive into how to build a CI/CD pipeline. There are tons of tools out there – Jenkins, GitLab CI, GitHub Actions, CircleCI, Azure DevOps… the list goes on! Don’t feel overwhelmed; you don't need to master everything at once.

I'll focus on GitHub Actions here, as it's widely used and integrates seamlessly with GitHub repositories (which is probably where your awesome open-source projects live). It also has a generous free tier – perfect for getting started!

Here’s a basic workflow example:

Create a .github/workflows directory in your repository. This is where you'll store your workflow files.
Create a YAML file (e.g., main.yml) inside the directory. This file defines the steps of your pipeline. Here’s an example:

name: CI/CD Pipeline

on:
  push:
    branches:
      - main  # Trigger the workflow on pushes to the 'main' branch

jobs:
  build:
    runs-on: ubuntu-latest  # Use a Linux runner

    steps:
      - uses: actions/checkout@v3 # Checkout the code from the repository

      - name: Set up Node.js 16
        uses: actions/setup-node@v3
        with:
          node-version: 16

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test  # Replace with your testing command (e.g., pytest, rspec)

      - name: Build the project
        run: npm run build # Replace with your build command

      - name: Deploy to staging (optional)
        if: github.ref == 'refs/heads/main'
        run: |
          # Add your deployment commands here - e.g., using SSH, cloud provider CLI tools etc.
          echo "Deploying to staging..."

Let’s break down that YAML:

name: A descriptive name for your workflow.
on: Specifies when the workflow should run (in this case, on pushes to the main branch).
jobs: Defines a set of tasks to be executed in parallel or sequentially. Here we have one job called build.
runs-on: Specifies the virtual environment where your job will run. ubuntu-latest is a common choice.
steps: A list of individual tasks to perform within the job. Each step uses pre-built actions from the GitHub Actions marketplace (like actions/checkout@v3).

Important Notes and Tips:

Actions Marketplace: The GitHub Actions marketplace has tons of community-created actions for everything from linting your code to sending Slack notifications on build failures. Explore it!
Secrets Management: Don't hardcode API keys or passwords in your workflow files! Use GitHub Secrets (Settings -> Secrets -> Actions) instead. It's much safer.
Testing is Key: Write good tests! They are the foundation of a robust CI/CD pipeline. Aim for high test coverage.
Branching Strategy: Consider adopting a branching strategy like Gitflow to streamline your development process.
Notifications: Configure notifications (e.g., Slack, email) to be alerted about build failures and deployments.

Troubleshooting: Because Things Always Go Wrong

Expect things to break! Your first pipeline won’t be perfect. Here are a few common troubleshooting tips:

Check the logs: The GitHub Actions UI provides detailed logs for each step of your workflow. Read them carefully!
Permissions: Make sure your workflow has the necessary permissions to access your repository and deploy to your target environment.
Dependencies: Double-check that all dependencies are installed correctly.
Don't Panic: Seriously, it happens to everyone. Debugging is part of the process!

Resources to Explore

GitHub Actions Documentation: https://docs.github.com/en/actions
GitLab CI Documentation: https://docs.gitlab.com/ee/ci/
CircleCI Documentation: https://circleci.com/docs/

The Takeaway

Building a CI/CD pipeline is an investment in the future of your open-source project. It might seem daunting at first, but it’s worth the effort. By automating your build, test, and deployment processes, you can free up time to focus on what truly matters – writing awesome code!

Now go forth and automate! And if you have any questions or tips of your own, share them in the comments below!

(P.S. If you accidentally deploy a broken version of your project to production, just blame the bot. It's always a good strategy.)

Coder Legion - Recent posts tagged devops-infra

Webernetes: Kubernetes in your browser?

Dashboard Design for Incident Response

Most dashboards answer one question: Is everything okay?

The Problem

Two Different Jobs

What Works During an Outage

The Test

Example

The Point

DevOps #SRE #Monitoring #Kubernetes #IncidentResponse #Dashboard

I released **oteldoctor v0.1.0** — an open-source Go CLI for checking OpenTelemetry Collector config

What it does

Commands

Install

Why it exists

Tofu Provider Fabric

Building Friday: A Multi-Provider AI Agent That Lives in Your Terminal

CI/CD That Ships Itself: Our GitHub Actions Blueprint

CI/CD That Ships Itself: Our GitHub Actions Blueprint

Pipeline Overview

Repository Structure (relevant parts)

Workflow 1: CI (PR and main)

Workflow 2: Canary Deploy to Edge

Health Checks and Auto-Rollback

Speed and Stability Techniques

Failure Modes We Handle

Minimal Smoke Spec Example

What To Measure

Assets

Links

TL;DR

CI/CD Security Mistake: Are You Giving Your Build Container Root Access to Your Server?

The Dangerous Truth About Running Docker Inside Docker (DinD vs. DooD)

Pattern 1: Docker-Out-of-Docker (DooD) - The Hidden Trap ⚠️

The Mechanism

The Security Problem: Root Escape

️ Pattern 2: Docker-in-Docker (DinD) - The Secure Standard

The Mechanism

The Security Solution: Perfect Isolation

Your Takeaway

From Code Push to Docker Hub: CI/CD with GitHub Actions

Why Automate Docker Builds?

Prerequisites: Accounts, Secrets & Permissions

Writing the Workflow (main.yaml) — Step by Step

Build & Push: Watching It Run

Mini Case Study: “Solo Developer to One-Click Deployment”

Conclusion — From Kitchen Chaos to Conveyor Belt

Automate your open-source project's builds & deployments with CI/CD using GitHub Actions!

Building CI/CD Pipelines (Without Losing Your Mind)

I released oteldoctor v0.1.0 — an open-source Go CLI for checking OpenTelemetry Collector config