Note: In a docker container, a server can only be available outside of the container / pod if it is bound to the "any host" IP¹. Binding a server to localhost / the loopback IP² will mean the server is only reachable within the container / pod.

Consider the following Express …

TL;DR: You can remove a misbehaving pod from a service without deleting it. Use kubectl label pod ... cyberdyne-service- ... to remove a label / labels. Once the labels are gone it will be removed from the Kubernetes service that routes traffic to pods.

When a Kubernetes node is misbehaving, it's common …

TL;DR: Prefer inclusion of the protocol in configurable environment variables

VAULT_ADDR=https://vault.sandbox.invalid:8200

over

VAULT_HOST=vault.sandbox.invalid

since this enables targeting a local server, e.g. http://localhost:8200 without any code changes.

We utilize sandbox, staging and other siloed environments to test changes before …

In order to run vault locally (I did this because I was on an airplane), first start the server with a known root token

export VAULT_TOKEN=root VAULT_ADDR=http://localhost:8200
vault server -dev -dev-root-token-id="${VAULT_TOKEN}"

vault version  # As a baseline, this is the version of `vault` I am using …

Why?

Using app.use('trust proxy', true) is likely too permissive, this post explains concretely why.

Example Applications

Consider two Express applications index-first.js that uses app.set("trust proxy", true)

const express = require("express");
const app = express();
const port = 3000;

app.set("trust proxy", true);
app.get("/", (req, res …