Docker runs software as containers: packaged units that carry application code and its dependencies. This separates deployment from machine-specific library setup; a team can deploy the container rather than verify that every host has the required PostgreSQL client libraries. Docker also hides many operating-system process details that an orchestration system would otherwise need to handle across Linux, macOS, and Windows. section 3.1 section 3.5
A useful operational model is simple: create a container with its configuration, start it to perform work, inspect it to learn its state, and stop it when the work should end. Docker exposes those operations both through the command line and programmatically through its API. section 3.1 section 3.5
Container configuration groups the information needed to run and manage a workload:
- Identification, including names and container IDs used to find a running or stopped container. section 3.5
- Resource allocation, such as the memory and disk fields carried by a task. section 3.5 section 4.2
- Networking, including exposed ports and port bindings that make a service reachable. section 3.5 section 4.2
- Error handling and lifecycle state, including whether a container is running or exited and its exit code. section 3.1 section 3.5
Run and inspect a PostgreSQL container
A PostgreSQL container can be started in the foreground with a name, credentials supplied as environment variables, and port 5432 mapped to the local machine. A local psql client can then create a table through that port. docker inspect reports a running state while it is active; after docker stop, inspection reports an exited state and finish time. section 3.1
Listing 3.1 Running the Postgres database server as a Docker container
$ docker run -it \ -p 5432:5432 \ --name cube-book \ -e POSTGRES_USER=cube \ -e POSTGRES_PASSWORD=secret \ postgres
This command shows the core runtime inputs together: foreground execution, a host-to-container port mapping, a container name, environment variables, and the PostgreSQL image. section 3.1
Docker can serve as the execution layer beneath an orchestrator. A task is the smallest unit of work, with a one-to-one relationship to a Docker container. A worker receives a task and uses Docker to start or stop its container; the manager, worker, and scheduler therefore organize work around container lifecycle rather than directly managing operating-system processes. section 3.5 section 4.2
Programmatic control follows the same model as the CLI. Docker API methods ContainerCreate, ContainerStart, and ContainerStop let code create and run containers or end them. A Go-based implementation can keep a Docker client and configuration together, then use that client while workers act on task records containing image, state, container ID, resources, ports, restart policy, and timestamps. section 1.7 section 3.5 section 4.2
