Quick Start
What you will learn
You will understand three separate runtime concerns: ports move network traffic, volumes preserve files and environment variables provide configuration. You will also learn why none of these should be used as a careless secret-management shortcut.
Start from Basics
When a container starts, ask:
- How will users or services reach it? Publish a port or connect it to a Docker network.
- What must survive when it is replaced? Store that data in a volume or external managed service.
- What changes between development, test and production? Supply runtime configuration, commonly through environment variables or platform-managed secrets.
Mixing these responsibilities creates confusing systems. A port is not storage. A volume is not configuration. An environment variable is not automatically a secure secret vault.
Simple Tanglish — three jobs
Port = app door. Volume = data notebook. Environment variable = start-time setting. மூன்றும் different problem solve பண்ணும். Door-ஐ data save பண்ண use செய்ய முடியாது; volume-ஐ setting change பண்ண use செய்ய முடியாது.
Core Explanation
Three problems, three separate tools
Choose the learner’s problem before choosing the Docker feature.
Connect the laptop address to the application address inside the container.
$ docker run -p 8080:8000 delivery-status:1.0Click execute — no real system changes are made
The created object will appear here
Architecture / Flow Diagram
Types / Components
Port: connect traffic
A web application can listen on port 8000 inside its container while your laptop exposes it on port 8080:
01docker run --name api -p 8080:8000 python-health:1.0Read the mapping as HOST_PORT:CONTAINER_PORT. A request to localhost:8080 is forwarded to port 8000 inside the container.
Publishing a port makes a service reachable through the host. Containers on the same user-defined Docker network can normally communicate by service or container name without publishing every internal port.
Volume: keep selected data
A container has a writable layer, but that layer belongs to the container lifecycle. If you remove the container, relying on that layer can lose important data. A named volume has an independent lifecycle:
01docker volume create app-data02docker run --name notes-api -v app-data:/app/data notes-api:1.0
Here, Docker mounts app-data at /app/data inside the container. A replacement container can mount the same volume.
Named volume or bind mount?
| Storage option | Managed by | Best fit |
|---|---|---|
| Named volume | Docker | Persistent application data with Docker-managed location |
| Bind mount | You and the host filesystem | Live source editing or explicit host-file access |
| Container writable layer | Container lifecycle | Temporary, disposable runtime files |
| Managed database/object store | Cloud or platform | Production data needing availability, backups and scaling |
A volume improves persistence, not backup. You still need a backup and recovery plan.
Environment variable: configure at startup
Use one image across environments and change its external configuration:
01docker run --name api \02-e APP_ENV=development \03-e LOG_LEVEL=debug \04-p 8080:8000 \05python-health:1.0
The application reads APP_ENV and LOG_LEVEL when it starts. This is better than building one image for development and a different image only to change a URL or feature flag.
An environment file can reduce command length:
01APP_ENV=development02LOG_LEVEL=debug
01docker run --env-file .env -p 8080:8000 python-health:1.0Keep .env out of source control when it contains sensitive or local values. In production, prefer the deployment platform’s secret store and access controls.
Port vs Volume vs Environment Variable
| Learner question | Docker feature | What it changes |
|---|---|---|
| How does the browser reach the app? | Port mapping | Network path |
| What must survive container replacement? | Volume | Selected data location |
| What setting changes between environments? | Environment variable | Startup configuration |
Real-World Examples
One application, three runtime needs
A feedback API listens on container port 8000. Learners reach it through host port 8080, so the team publishes 8080:8000. Uploaded evidence must survive application upgrades, so the team mounts a volume at /app/uploads. The database URL and logging level differ between test and production, so they are injected at runtime.
When version 1.1 is released, the team removes the old container and starts a new one from the new image. The address mapping is recreated, the existing volume is remounted and production configuration is supplied again. The container is replaceable; the data and environment policy are deliberate.
- Before Docker
- The API runs inside the container, but the browser cannot reach it.
- Team action
- Publish laptop port 8080 to container port 8000.
- After Docker
- localhost:8080 reaches the API.
- Before Docker
- A replacement container loses files stored in its writable layer.
- Team action
- Mount the app-data volume at /app/data.
- After Docker
- The new container sees the existing files.
- Before Docker
- Test needs debug logs, but the team does not want another image.
- Team action
- Start the same image with LOG_LEVEL=debug.
- After Docker
- Configuration changes without rebuilding.
Imagine Pannunga
Think of a small office: the port is the numbered entrance, the volume is the records cupboard that remains when a desk is replaced, and an environment variable is the instruction card handed to the employee at the start of a shift.
Use Cases
“Which port and settings does my app expect?”
Document the runtime contract“Will data survive replacement?”
Test with the mounted volume“How does each environment configure the app?”
Inject runtime configuration“Where did the request or data path fail?”
Inspect ports, mounts and logsKey Takeaways
- Port mappings create a path from the host to the container.
- Read
8080:8000as host port followed by container port. EXPOSEdocuments a port; it does not publish it.- Important data should not depend on a replaceable container layer.
- A named volume has a lifecycle separate from one container.
- A volume supports persistence but does not replace backups.
- Environment variables provide startup configuration.
- Secrets need stronger controls than committed
.envfiles.
Final Thought + Next Path
Remember three separate jobs: port = reach the app, volume = keep selected data, environment variable = change a startup setting. In Byte 04, you will connect an API and database as separate services and manage them together with Docker Compose.
FAQ + Knowledge Check
Choose an answer, inspect the explanation and explain the idea in your own words.
Does EXPOSE 8000 make the app reachable from the laptop? No. Publish a host mapping such as -p 8080:8000.
Does a volume automatically create a backup? No. Persistence and backup are different responsibilities.
Knowledge check: Which feature changes LOG_LEVEL without rebuilding the image? Environment variable. Which feature keeps /app/data across replacement? Volume.
Trace one request
01Browser: localhost:808002↓ host port03Docker port publishing04↓ container port05API process: 0.0.0.0:800006↓ writes file07Volume mount: /app/uploads
If a request fails, follow the path in this order: Is the container running? Is the process listening on the expected interface and port? Is the host mapping correct? Is a firewall or platform policy blocking access?
Inspect before changing
01docker ps02docker port api03docker logs api04docker inspect api05docker volume ls06docker volume inspect app-data
docker inspect can reveal port bindings, mounts and environment metadata. Remember that people with sufficient Docker access may be able to inspect container configuration, another reason not to treat plain environment variables as perfect secret protection.
Common mistakes
Common mistakes
- Reversing
HOST_PORT:CONTAINER_PORT. - Publishing a database port to the host when only another container needs it.
- Writing durable data only to the container’s writable layer.
- Assuming a named volume is automatically backed up.
- Committing a populated
.envfile to Git. - Baking environment-specific URLs or API keys into the image.
Interview answer
How do ports, volumes and environment variables differ?
Strong answer: Port publishing connects a host address to a container’s listening port. Volumes store selected data independently of a container’s lifecycle. Environment variables provide runtime configuration so one image can be reused across environments. For sensitive values, I use the platform’s secret-management mechanism rather than committing them or baking them into the image.