Portal Community
Portal / Nodes / Docker

Docker Node

Control Docker containers, images, volumes, and networks — build IaaS automation workflows for deployments, monitoring, and infrastructure management.

  What this node does: The Docker Node connects to a Docker daemon via Unix socket or TCP (with optional TLS) and exposes 28 operations across 5 resources: containers, images, volumes, networks, and system. Use it to drive CI/CD pipelines, manage container lifecycles, automate deployments, and build full infrastructure management workflows — all without leaving BizFirst.
28
Total Operations
10
Container Ops
5
Image Ops
4
Volume Ops
6
Network Ops

Resource Reference

Container — 10 operations

Full container lifecycle management: create, run, stop, inspect, exec, and monitor.

container/list container/inspect container/create container/start container/stop container/restart container/remove container/logs container/exec container/stats

Image — 5 operations

Pull, tag, inspect, list, and remove Docker images.

image/list image/inspect image/pull image/remove image/tag

Volume — 4 operations

Create named volumes, inspect configuration, list, and remove.

volume/list volume/create volume/inspect volume/remove

Network — 6 operations

Create and manage Docker networks; connect and disconnect containers.

network/list network/create network/inspect network/connect network/disconnect network/remove

System — 3 operations

Query daemon info, version, and connectivity status.

system/info system/version system/ping

Connection Modes

Connection TypeValueUse CaseSecurity
Unix SocketunixsocketLocal Docker daemon on the same hostOS-level file permissions — most secure for local use
TCPtcpRemote Docker daemon (dev/testing only)No encryption — never use in production
TCP+TLStcptlsRemote Docker daemon in productionMutual TLS authentication — required for remote hosts
  Remote Docker Security: Exposing the Docker daemon TCP port without TLS grants root-equivalent access to the host. Always use tcptls for any remote connection. Store TLS certificate paths in BizFirst Credentials Manager — never hard-code them in node settings.

Connection Fields

FieldTypeDefaultDescription
dockerHoststringunix:///var/run/docker.sockDocker socket path or TCP endpoint (e.g. tcp://192.168.1.10:2376)
connectionTypestringunixsocketOne of: unixsocket, tcp, tcptls
tlsCertPathstring—Path to TLS certificate directory. Required when connectionType is tcptls.
timeoutSecondsint30Operation timeout. Increase for long-running operations like image pulls.

Error Codes

CodeMeaningCommon Cause
CONFIG_ERRORSettings resolution failedMissing or invalid connection settings
MISSING_INPUTRequired field not providedContainerId or Image field left empty
NOT_FOUNDResource not found (HTTP 404)Container ID or image name does not exist
CONFLICTResource conflict (HTTP 409)Container already running, name collision
AUTH_FAILEDAuthentication failureInvalid TLS certificates, registry auth
DOCKER_API_ERRORGeneric Docker API errorDaemon error, out-of-resources conditions
UNKNOWN_ROUTEInvalid resource/operationTypo in resource or operation field

Node Policies & GuardRails

PolicyEnforcement
Never expose Docker daemon TCP without TLSUse tcptls connection type for any remote Docker host. Plain tcp is blocked in production GuardRail profiles.
Store TLS certificates in Credentials ManagerSet tlsCertPath via {{ $credentials.dockerTlsCertPath }} — never hard-code filesystem paths.
Never interpolate user input into Command or Env fieldsAny container/exec or container/create command that includes unvalidated user data triggers a GuardRail block.
Stop containers before removalCalling container/remove on a running container returns CONFLICT. Workflows must call container/stop first.
Use named containers in workflowsAlways assign a Name when creating containers. Relying on auto-generated IDs reduces workflow readability and idempotency.
Limit container/exec to approved commandsArbitrary exec is root-equivalent inside the container. GuardRail exec policies restrict allowed command prefixes.
Always handle the error portDocker daemon may be unreachable. Workflows without error port handling will silently fail on daemon downtime.

Rate Limits & Concurrency

  The Docker API itself has no built-in rate limiting, but running too many concurrent operations (especially image pulls or container starts) can exhaust daemon resources and cause DOCKER_API_ERROR. Use the BizFirst workflow concurrency limiter to cap parallel Docker node executions to a safe threshold for your host capacity.

Common Workflow Patterns

Blue-Green Deployment

  1. Pull new image with image/pull
  2. Create new container with container/create (blue)
  3. Start blue container with container/start
  4. Verify health with container/exec (run health check script)
  5. Stop green container with container/stop
  6. Remove green container with container/remove

Continuous Monitoring

  1. List all containers with container/list on a schedule
  2. Filter for containers in exited state
  3. For each exited container, retrieve logs with container/logs
  4. Send log summary to Slack / Email alert node
  5. Restart or escalate based on exit code

Ephemeral Job Runner

  1. Create job container with container/create
  2. Start it with container/start
  3. Poll container/inspect until State.Status is exited
  4. Collect output with container/logs
  5. Remove with container/remove