Skip to content
← Docs

Resource manager

Browse and manage live Kubernetes and Docker resources from the UI — without kubectl or SSH. Every create, edit and lifecycle action is dispatched to the agent as a task, RBAC-scoped and recorded.

The inventory and its actions live on the Resources page in the console at app.subnomic.com.

A kubernetes- or docker-mode agent inventories the cluster / daemon and streams it here; actions you take in the UI are sent back to that agent to run inside your network.

The inventory

Resources lists what each agent reports, grouped by kind. Kubernetes covers workloads, config, network, storage and cluster objects (Deployments, Services, ConfigMaps, Secrets, Ingresses, …); Docker covers Containers, Images, Volumes, Networks and — on a swarm manager — Services, Nodes and Stacks. Open any item for its details, raw object, logs (where available) and its task history. The Docker Services list shows each service's image and replica count (running / desired) in place of a namespace.

Create & edit (apply)

Form-driven kinds have a New button and (Kubernetes) an Edit button. You fill in fields; Subnomic builds the manifest / spec and sends it as an apply task. Apply is idempotent — re-applying the same name updates the existing object rather than failing:

  • Kubernetes — a server-side apply, so it creates or updates the live object and reconciles only the fields the form owns.
  • Docker service — updated in place (rolling) when it already exists, else created.
  • Docker container — recreated with the new spec when the name already exists (brief downtime; the new image is pulled first so a bad reference never destroys the running container).
Docker resources have no in-place edit form (a container "edit" is a recreate, and the inventory can't repopulate every field) — so for Docker you re-create from the New form, or use the lifecycle actions below. Kubernetes objects edit and re-apply cleanly.

Update just the image

To roll out a new image without touching anything else, open the resource and use Update image (or schedule it — see Scheduled tasks). It operates on the live object, so it always applies to whatever is running:

  • Kubernetes (Deployment / StatefulSet / DaemonSet / ReplicaSet) — patches one named container's image and waits for the rollout. Pick the container from the dropdown; the current image is prefilled so you only change the tag.
  • Docker service — swaps the image on the live service spec and lets swarm roll the tasks (no downtime).
  • Docker container — pulls the new image, then recreates the container with the same config, name, volumes and networks (brief downtime; its id changes).

Lifecycle actions

Per-kind buttons dispatch a task to the agent: restart, scale to N replicas (workloads / swarm services), start / stop (Docker containers), update image, and delete in cluster. The Schedule button pre-fills a scheduled task for the same resource + action.

Private registries

When an image lives in a private registry:

  • Docker — the agent reuses the docker host's own credentials (a prior docker login, i.e. ~/.docker/config.json and any credential helper). No extra setup: if the host can pull it, so can the agent.
  • Kubernetes — create a registry secret (Secret → type kubernetes.io/dockerconfigjson): just fill in the registry server, username and password and Subnomic builds the credential for you. Then reference it from a workload's Image pull secrets field (below).

Attaching secrets & config to workloads

Deployment / StatefulSet / CronJob forms can wire Secrets and ConfigMaps into the pod, every way Kubernetes supports:

  • Image pull secrets — names of registry secrets used to pull private images.
  • Env from secrets / configmaps — inject every key of a Secret / ConfigMap as environment variables (envFrom).
  • Env from a single key — one variable from one key, written as VAR → secret:key (or configmap:key).
  • File mounts — mount a Secret / ConfigMap as files at a path (name → /path), read-only. Other volumes you manage outside the form (e.g. a PVC) are preserved on edit.

Guardrails & audit

Every mutating action (apply, update image, scale, restart, start / stop, delete) is gated by guardrails (target type kube / docker) and written to the activity log. A denied action is blocked before it reaches the agent; an action that requires approval is blocked too (a fire-and-forget task can't be approved interactively).

Permissions

resource.read resource.delete task.create

resource.read browses the inventory; task.create runs create / edit / lifecycle actions (they execute as tasks). Whether an action actually succeeds also depends on the agent's own rights — its Kubernetes ServiceAccount RBAC, or its access to the Docker daemon.