Home on Nimbus

Getting Started

Fri, 01 Mar 2024 00:00:00 +0000

Prerequisites

Hugo Extended ≥ 0.146.0 — check with hugo version.
Node.js (any recent LTS) — needed for the Tailwind/PostCSS build step.

Run the example site

The example site lives in exampleSite/ and references the theme one directory up, so it’s built with the --themesDir flag rather than a copy of the theme inside it:

1
2
3
4


git clone https://github.com/your-org/hugo-theme-nimbus.git
cd hugo-theme-nimbus/exampleSite
npm install
hugo server -D --themesDir ../..

Open http://localhost:1313 to see it running.

Installation (v1.0)

Wed, 01 Nov 2023 00:00:00 +0000

This is the v1.0 install method

Nimbus v2.0 changed the build tooling from Gulp to native Hugo Pipes + PostCSS. If you’re starting a new site, follow the current Installation guide instead.

1. Add the theme

1

git submodule add https://github.com/your-org/hugo-theme-nimbus.git themes/nimbus

2. Install the v1.0 Gulp toolchain

1
2
3


npm install -g gulp-cli
npm install
gulp build

This workflow is no longer maintained — see the current docs for the PostCSS-based build.

Installation

Tue, 05 Mar 2024 00:00:00 +0000

1. Add the theme

As a Git submodule (recommended for most sites):

1

git submodule add https://github.com/your-org/hugo-theme-nimbus.git themes/nimbus

Or as a Hugo Module:

1
2


hugo mod init github.com/you/your-site
hugo mod get github.com/your-org/hugo-theme-nimbus

2. Point your site config at it

1

theme = "nimbus"

3. Copy the build tooling

Nimbus’s styling is compiled with Tailwind, ahead of time, into a plain CSS file — Hugo itself never runs Node or PostCSS. Copy these files from exampleSite/ into your site root:

Shortcodes

Fri, 12 Apr 2024 00:00:00 +0000

Note boxes

type can be info (default), warning, success, or error.

1
2
3


{{< note type="tip" title="Pro tip" >}}
Your content here.
{{< /note >}}

Pro tip

type can also be passed positionally, but not combined with title= in the same call — Hugo rejects mixing positional and named arguments.

Terminal

1
2
3


{{< terminal command="bash" user="dev" host="prod-01" path="~/app" >}}
kubectl get pods
{{< /terminal >}}

bash

dev@prod-01:~/app$

kubectl get pods NAME READY STATUS RESTARTS AGE api-7d8f9c6b5d-x2k9p 1/1 Running 0 3m

Badges

1
2


{{< badge "kubernetes" "Kubernetes v1.28" >}}
{{< badge type="terraform" label="Terraform v1.5" url="https://terraform.io" >}}

Kubernetes v1.28 Docker Terraform v1.5 AWS

API Reference

Mon, 20 May 2024 00:00:00 +0000

This page is rendered entirely from the openapi.yaml file sitting next to it in this page bundle — no separate Swagger UI build step, no JS widget to keep updated, just Hugo parsing the spec at build time.

Deploys API

v1.0

Trigger and inspect deployments for a service.

Adopt GitOps for cluster configuration

Sat, 01 Jun 2024 00:00:00 +0000

Context

Cluster configuration changes currently happen via direct kubectl apply from engineer laptops. We have no audit trail and drift between clusters is common.

Decision

Adopt a GitOps workflow (Argo CD) where the Git repository is the single source of truth for cluster state, and all changes go through pull request review.

Consequences

Every config change is reviewable and revertible via Git history.
Emergency changes need a documented break-glass procedure, since direct kubectl apply will be restricted in production namespaces.
Requires migrating ~40 existing manifests into the GitOps repo before enforcement can begin.

Use PostgreSQL as the primary datastore

Sat, 10 Feb 2024 00:00:00 +0000

Context

We need a primary datastore for the new billing service. The team has production experience with both PostgreSQL and MongoDB, and the data model is relational (accounts, invoices, line items with foreign keys).

Decision

We will use PostgreSQL 16, managed via RDS, as the primary datastore for all new services unless a specific workload has a strong document-store or time-series justification.

Consequences

Schema migrations require a formal review (see docs/migrations).
We standardize on one connection-pooling strategy (PgBouncer) across services, simplifying on-call runbooks.
Document-shaped data (e.g. audit logs) will need a deliberate exception request rather than defaulting to Postgres JSONB columns.

About

Mon, 01 Jan 2024 00:00:00 +0000

Nimbus is a Tailwind CSS Hugo theme built for DevOps knowledge hubs — blog posts, sidebar-navigation docs, Architecture Decision Records, and native OpenAPI reference docs, all in one theme.

This site is the theme’s exampleSite — a working demo you can build locally to see every feature in context, and a template for your own site.

What’s demonstrated here

Blog — a standard post feed with tags, categories, related posts, and social sharing.
Documentation — sidebar-navigation docs with a version switcher, table of contents, and a full shortcode reference.
Architecture Decision Records — a purpose-built content type for tracking infrastructure decisions.

See the Installation guide to use Nimbus on your own site.

Building an Observability Stack with Prometheus and Grafana

Wed, 15 Mar 2023 11:00:00 -0700

Most teams don’t have a metrics problem — they have a too many dashboards nobody looks at problem. This is the minimal setup we use to go from “no visibility” to “useful alerts and three dashboards people actually open during an incident.”

Prometheus v2.51 Grafana v10.4

Terraform State Management: Lessons from Production

Wed, 15 Feb 2023 10:00:00 -0700

Local Terraform state works fine for a weekend project. It falls apart the moment a second engineer runs terraform apply against the same infrastructure. Here’s the setup we settled on after a state file conflict took down a staging environment for an afternoon.

State files contain secrets

Terraform state can include plaintext values for anything marked sensitive in your provider — database passwords, API keys, TLS private keys. Treat your state backend’s access controls with the same care as a secrets manager, not like a build artifact.

Move to a remote backend

A local terraform.tfstate file has no locking and no history. The fix is a remote backend with state locking built in:

Deploying with Kubernetes: A Practical Guide

Sun, 15 Jan 2023 09:00:00 -0700

Getting a service running reliably on Kubernetes comes down to a handful of building blocks: a container image, a Deployment, and a Service to expose it. This walkthrough covers the essentials.

Before you start

You’ll need kubectl configured against a cluster (Minikube, kind, or a managed cluster all work fine for this walkthrough).

1. Build and tag the image

1
2


docker build -t registry.example.com/api:1.4.0 .
docker push registry.example.com/api:1.4.0

2. Define the Deployment

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


apiVersion: apps/v1
kind: Deployment
metadata:
 name: api
spec:
 replicas: 3
 selector:
 matchLabels:
 app: api
 template:
 metadata:
 labels:
 app: api
 spec:
 containers:
 - name: api
 image: registry.example.com/api:1.4.0
 ports:
 - containerPort: 8080
 readinessProbe:
 httpGet:
 path: /healthz
 port: 8080

3. Roll it out

bash

dev@k8s-master:~/api$

kubectl apply -f deployment.yaml deployment.apps/api created kubectl rollout status deployment/api deployment “api” successfully rolled out

Watch your readiness probes

A missing or too-strict readiness probe is the most common cause of a rollout that “succeeds” but serves traffic to pods that aren’t actually ready.

Architecture

Request flow

graph LR A[Client] --> B[Ingress] B --> C[Service] C --> D[Pod 1] C --> E[Pod 2] C --> F[Pod 3]

That’s the core loop: build, define, apply, verify. From here you’d typically add a HorizontalPodAutoscaler and wire this into CI so every merge to main triggers a new rollout automatically.