Start with the simple definition, then see why it matters.

A Docker object is any named thing that Docker creates and manages for you. When you build an image, you have created an object. When you start a container, you have created another. When you make a storage area or a virtual network, those are objects too. Each object has its own identity, its own settings, and its own life story from creation to removal.

Docker’s official documentation groups the main objects into a short list: images, containers, networks, volumes, and plugins. When Docker runs as a cluster, a few more objects appear, such as services, secrets, and configs. The word “object” is just a convenient label for “one of the things Docker keeps track of”.

Why learn the objects first?

Many beginners jump straight to commands and get lost. Every Docker command is really a request that does one of four things to an object: create it, look at it, change it, or delete it. If you know which object a command is talking about, you can guess what it will do. The objects are the nouns, and the commands are the verbs.

A quick tour before we go deep into each member.

flowchart TD
  IMG["Image - the template"] -->|"start from"| CON["Container - the running instance"]
  VOL["Volume - lasting storage"] -->|"attached to"| CON
  NET["Network - the connections"] -->|"joined by"| CON
  PLG["Plugin - the add-on"] -.->|"extends"| VOL
  PLG -.->|"extends"| NET
        

Look at the picture above. The container is the busy center of the family. It is born from an image, it may hold onto a volume for saving data, and it joins one or more networks to talk to others. Plugins sit in the background and extend what volumes and networks can do.

The first object you meet in any Docker journey.

What is an image?

An image is a read-only package that contains an application together with its libraries, tools, and settings. It is a frozen snapshot. You cannot run an image directly in the sense of changing it. Instead, you use it as a template to create containers.

Images exist so that software can be moved from one computer to another without the “it works on my machine” problem. Everything the program needs is already inside the package.

Where do images come from?

Three ideas explain why images are efficient and how they are named.

Layers

An image is a stack of thin layers. Each instruction in the Dockerfile that changes files produces one layer. Layers are read-only, and Docker can share them between images. If two images begin with the same base, that base is stored on disk once, not twice.

graph TD
  A["Layer 1: minimal operating system files"] --> B["Layer 2: language runtime"]
  B --> C["Layer 3: application libraries"]
  C --> D["Layer 4: your application files"]
  D --> E["Writable layer: added only when a container starts"]
        

Names and tags

An image name usually has three parts: where it lives, what it is called, and a tag. The tag is a label, often a version like a number. A repository is the collection of all versions of one image name, and each version is told apart by its tag. If you leave the tag out, Docker assumes a tag called “latest”.

Digests

A digest is a long fingerprint calculated from the exact contents of an image. Tags can be moved to point to a newer build, but a digest never changes. If you need absolute certainty about what you are running, refer to the image by its digest.

Where the action happens.

What is a container?

A container is a runnable instance of an image. When you start one, Docker takes the read-only layers of the image, adds a thin writable layer on top, gives the process its own private view of the system, and starts your application inside it.

A container is not a tiny computer. It is an ordinary process on the host that has been placed into an isolated space using features of the Linux kernel. Namespaces give it a private view of processes, network, and files. Control groups limit how much memory and processor it may use.

What can you control on a container?

Every container passes through predictable stages.

stateDiagram-v2
  [*] --> Created
  Created --> Running: start
  Running --> Paused: pause
  Paused --> Running: unpause
  Running --> Exited: stop or program ends
  Exited --> Running: restart
  Exited --> Removed: remove
  Removed --> [*]
        

Because containers are disposable, data needs a safer home.

Everything written inside a container’s writable layer disappears when the container is removed. For a simple web page that saves nothing, this is fine. For a database, it would be a disaster. A volume is a storage object created and managed by Docker that lives outside any single container. You can attach it to a container, detach it, and attach it to a different container later, and the data stays intact.

Why volumes are preferred

Volumes are one option among three, and each has its best moment.

How containers find each other and the outside world.

A network is a virtual connection managed by Docker. Each container can join one or more networks, and the network decides who may talk to whom. This is powerful when your system has several parts, such as a website, an API, and a database, because you can let the website reach the API while keeping the database private.

Network types

Finding each other by name

On a user-created bridge network, Docker provides built-in name lookup. Your API can reach the database simply by using its container name, without knowing its numeric address. If the database container is replaced and receives a new address, the name still works.

Publishing ports

By default, a container’s network is private. To let people outside reach a web application inside a container, you publish a port. This links a chosen port on the host to a port inside the container, like a doorbell on the front door that rings one specific apartment.

flowchart LR
  V["Visitor"] -->|"host port"| H["Host computer"]
  H -->|"published port"| W["Web container"]
  W -->|"private network"| A["API container"]
  A -->|"private network"| DB["Database container"]
        

The least known member of the family, but a useful one.

Docker’s built-in features cover most needs, but sometimes you want something more specialized. Plugins are add-ons that extend the Docker engine. They are installed, enabled, disabled, and removed like other objects.

When one computer is not enough, Docker adds more objects.

Docker has a built-in clustering mode called Swarm. In this mode, several machines work together as one group, and new objects appear to describe the group’s work. You do not need them on a single laptop, but knowing their names helps you read documentation and understand larger systems.

flowchart TD
  S["Service: web, 3 replicas wanted"] --> T1["Task 1"]
  S --> T2["Task 2"]
  S --> T3["Task 3"]
  T1 --> N1["Worker node A"]
  T2 --> N2["Worker node B"]
  T3 --> N2
        

Two cluster objects that keep settings out of your images.

Secrets

A secret is a small piece of sensitive information, such as a password, key, or certificate. In Swarm mode, secrets are stored in encrypted form in the cluster and are given only to the services that need them. Inside the container they appear as files in a temporary in-memory location, so they are not written into the image and are not sitting on disk.

Configs

A config is similar but meant for non-sensitive settings, such as a web server’s configuration file. It lets you change settings without rebuilding the image. The same image can behave differently in testing and production simply by receiving different configs.

Real applications combine many objects, and you can describe them all in one file.

A typical application needs several containers, a couple of volumes, and a network or two. Creating each one by hand is slow and easy to get wrong. Docker Compose lets you describe the whole set in a single text file: which images to use, which volumes to create, which networks to join, and what settings to apply. One instruction then creates everything, and one instruction removes it.

A group of objects started together this way is called a project. In Swarm mode, a similar group is called a stack. In both cases the idea is the same: treat many related objects as one unit that you can start, stop, and remove together.

Follow one request from your keyboard to a running application.

sequenceDiagram
  participant You
  participant Client as Docker Client
  participant Daemon as Docker Daemon
  participant Reg as Registry
  You->>Client: ask to run an application
  Client->>Daemon: send the request
  Daemon->>Daemon: look for the image locally
  Daemon->>Reg: download missing layers
  Reg-->>Daemon: image layers
  Daemon->>Daemon: create network and volume if needed
  Daemon->>Daemon: create and start the container
  Daemon-->>Client: report success
  Client-->>You: application is running
        

Notice the direction of dependence. A container needs an image, but an image needs nothing. A container may use a volume and a network, but those can exist without any container. Removing a container never deletes its image, and by default it never deletes named volumes either. Understanding this direction of dependence prevents many accidental deletions.

A few extra helpers you will bump into as you grow.

Each object carries its own risks and its own protections.

Because you cannot fix what you cannot see.

Listing and inspecting

Docker can list every object of a given kind, and it can show the complete detail of any single one. The detailed view shows settings, connections, storage attachments, and current state. This is the first place to look when something behaves unexpectedly.

Logs

Applications in containers should write their messages to the standard output and error streams. Docker collects these and lets you read them. In production, teams send logs to a central system, because a removed container takes its own local records with it.

Metrics and events

Docker can report how much processor, memory, network, and disk each container uses. It also records events such as objects being created, started, stopped, or deleted. Monitoring tools collect these numbers and draw graphs so you can spot trends, like memory rising steadily or a container restarting again and again.

Health checks

A container can be marked as running while the program inside is stuck. A health check is a small regular test, and Docker records whether it passes. Cluster tools use the result to replace containers that have quietly stopped working.

Why Docker splits everything into separate objects, and what it costs.

Good habits and bad habits when working with objects.

Helpful patterns

Harmful anti-patterns

A short checklist to keep your objects tidy and safe.

Mistakes beginners often make

Where these objects show up in everyday engineering.

Quick answers to the questions beginners ask most.

An image is a read-only template. A container is a running instance created from it, with a thin writable layer on top. One image can produce many containers.

The commonly listed core objects are images, containers, networks, volumes, and plugins. Cluster mode adds nodes, services, tasks, secrets, and configs, and there are supporting items like contexts and builders. The exact grouping varies by explanation, but the core five are the ones to learn first.

Data in the container’s writable layer is deleted with it. Data in a named volume stays until you remove the volume itself.

Not exactly. A Dockerfile is an ordinary text file you write. Docker uses it as a recipe to create an image, and the image is the object.

Yes. A container can attach several volumes and join several networks at the same time, which is a common way to separate public and private traffic.

Yes, but be careful. If several containers write to the same files at once, they can overwrite each other’s work. Sharing is safest when only one writes and the others read.

Most people do not, at least at the start. Plugins are for special needs, such as remote storage or specialized logging.

A container is a single running instance. A service is a cluster-level description of how many copies you want and how they should run. Docker creates the containers, through tasks, to match the service.

Docker does not delete objects on its own initiative, since it cannot know if you still need them. Regular cleanup, with a careful review, keeps disk use under control.

Start with images and containers, since everything else builds on them. Then learn volumes and networks, and only later look at cluster objects and plugins.

Docker objects are the named building blocks that every Docker command creates, inspects, changes, or removes. Images are the read-only templates, containers are the disposable running instances, volumes hold the data that must last, networks connect everything in a controlled way, and plugins extend the engine. In cluster mode, nodes, services, tasks, secrets, and configs describe the work of many machines. Once you know which object a command is about, the tool becomes far more predictable, and most beginner confusion melts away.