Job control.

01 / Context

The problem

Running an operational command through a web interface involves more than starting a process. Users need permission to launch it, a way to follow its progress, and a reliable record of how it finished. Concurrent requests and interrupted execution also need explicit handling.

02 / Responsibility

My contribution

I built a web interface for running operational commands as Kubernetes Jobs, with execution tracking, captured output and protection against duplicate launches.

03 / Approach

The decisions

I made commands opt in to web execution through an allowlist, with separate permissions for launching and viewing jobs. A persistent job model tracks the lifecycle, while ordered row locks serialize claims and prevent equivalent jobs from running concurrently. Kubernetes Jobs inherit the configured environment from a CronJob template. They have no automatic retries, keeping repeat execution an explicit decision. Output is buffered and appended to the database, and reconciliation checks unfinished records against Kubernetes state.

1. 01

   Authorize

   Check user permissions and restrict the launch form to explicitly allowed commands.

2. 02

   Claim and execute

   Persist the request, serialize competing claims and launch a Kubernetes Job.

3. 03

   Report and reconcile

   Capture output and terminal state; reconcile unfinished records with Kubernetes.

04 / Result

The outcome

Delivered and merged the workflow across the data model, execution logic, Kubernetes integration and web interface. Permissioned users can request an allowed command, follow its status and read its output. An end-to-end verification command exercises the path from the UI to job reporting.