A Container Entrypoint Can Break a Perfectly Valid Validation Command
CI failed because the image entrypoint changed how arguments were interpreted, not because the OpenBao configuration was invalid.
TOPIC
Lessons, explainers, experiments, and implementation notes.
CI failed because the image entrypoint changed how arguments were interpreted, not because the OpenBao configuration was invalid.
A configuration should render successfully from a clean checkout before it is trusted on a production host.
A mutable tag tells you what to ask for; a digest tells you what bytes you actually accepted.
A configuration file copied with the wrong mode can behave differently depending on the build context and base image defaults.
Live files that are absent from Git are technical debt even when the service is currently healthy.
Container process state only proves that PID 1 exists; readiness has to test the behavior the dependency actually needs.
You cannot reliably roll back to yesterday's image if the tag you used yesterday points somewhere else today.
A container command is only reproducible when you know whether the image entrypoint wraps, replaces or transforms it.
Separating image construction, configuration injection and runtime startup makes failures easier to localize.
A production checkout owned by another identity can be readable on disk while Git refuses to trust it.
A posture check should distinguish evidence it cannot read from evidence that proves the system is wrong.
Comparing HEAD with origin/main proves consistency with the last fetched view, not with the current remote repository.
Cleanliness answers whether local tracked files changed; freshness answers whether the revision is the one you intended to run.
When a deployment fails later, the first forensic question is which reviewed source revision actually produced it.
Operational confusion falls when desired configuration, mutable data and confidential values stop competing to be one source of truth.
Seeing a service in Portainer does not tell you which repository, runbook or backup path can recreate it.
Repository boundaries should not become operational blind spots on a shared production host.
Production work continued in multiple streams, so safe synchronization had to preserve both histories rather than overwrite whichever side moved first.
Schema declarations are executable code; a one-word typo can prevent the application model from initializing correctly.
An application can pass isolated logic tests while its database schema still fails to create, upgrade or enforce the intended constraint.
When a network response is lost, retrying a create request can duplicate the side effect even if the first request succeeded remotely.
When the remote API lacks your preferred idempotency primitive, deterministic discovery can recover an uncertain previous attempt.
Content intent and remote-delivery progress are different state machines and should not be collapsed into one post status.
A scheduler can enqueue work before crashing; recovery logic must discover incomplete deliveries after the process returns.
If the provider already reports scheduled, publishing or published, the reconciler should observe rather than repeat the side effect.
Retry counts and backoff are not just performance settings when the job performs external side effects.
The authoritative article text can remain stable while each destination has its own mutable publishing lifecycle.
An audit trail is only useful if its schema is simpler and more dependable than the systems it records.
A successful target deployment is not a full success if the change quietly damages another workload on the same host.
A service can be reachable and still be routed through the wrong authentication or application layer.
A reviewed repository can still be disconnected from the state actually running on the host.
Infrastructure source is incomplete if Compose points at files that only exist on the current server.
The safest time to decide how to recover is before the change has modified the evidence you depend on.
Recording containers, ports and revisions after deployment gives future incident response a known-good comparison point.
Fixing one incident is useful; changing the system so the same class of failure becomes detectable or impossible is more valuable.