How to Run Your First Docker Container

How to Run Your First Docker Container

Stepping into the world of containerization represents one of the most transformative decisions you can make in modern software development. Whether you're a developer tired of hearing "it works on my machine," a system administrator seeking consistency across environments, or a curious technologist wanting to understand what makes Docker so revolutionary, learning to run your first container opens doors to deployment strategies that were unimaginable just a decade ago. The technology has fundamentally changed how we think about application packaging, distribution, and execution, making it possible to encapsulate entire application environments into portable, reproducible units that run identically anywhere.

Docker containers provide a lightweight, standardized way to package applications with all their dependencies, ensuring they run consistently regardless of where they're deployed. Unlike traditional virtual machines that require a full operating system for each instance, containers share the host system's kernel while maintaining complete isolation of the application environment. This approach dramatically reduces overhead, speeds up deployment times, and simplifies the complex challenge of managing dependencies across development, testing, and production environments.

Throughout this comprehensive guide, you'll discover everything needed to successfully run your first Docker container, from understanding the fundamental concepts and installing the necessary software to executing practical commands and troubleshooting common issues. We'll explore the Docker architecture, walk through real-world examples, examine best practices that professionals use daily, and provide you with actionable knowledge that transforms abstract concepts into tangible skills. By the end, you'll have not just run a container, but gained the foundational understanding to incorporate Docker into your development workflow confidently.

Understanding Docker Architecture and Core Concepts

Before diving into practical commands, grasping the architectural foundations of Docker helps demystify what happens when you run a container. Docker operates on a client-server architecture where the Docker client communicates with the Docker daemon, which does the heavy lifting of building, running, and distributing containers. When you type a Docker command, the client sends instructions to the daemon, which can run on the same system or remotely, providing flexibility in how you manage containerized applications.

The Docker ecosystem revolves around several key components that work together seamlessly. Images serve as read-only templates containing the application code, runtime, libraries, and dependencies needed to run your software. Think of images as blueprints or recipes that define exactly what should be in a container. Containers are the running instances created from these images—they're the actual execution environments where your applications live and process data. Registries like Docker Hub act as repositories where images are stored and distributed, similar to how GitHub hosts code repositories.

The beauty of containers lies not in their complexity, but in their elegant simplicity—they do one thing exceptionally well: create reproducible, isolated environments that eliminate the friction between development and deployment.

Understanding the difference between images and containers proves crucial for effective Docker usage. An image remains static and unchanged, while containers are dynamic and stateful during execution. You can create multiple containers from a single image, each running independently with its own filesystem, network interfaces, and process space. When a container stops, any changes made to its filesystem are lost unless explicitly saved, which encourages the practice of treating containers as ephemeral and disposable—a fundamental principle of modern cloud-native architecture.

The Layered Filesystem Architecture

Docker images utilize a layered filesystem architecture that optimizes storage efficiency and speeds up image distribution. Each instruction in a Dockerfile creates a new layer, and these layers are stacked on top of each other to form the complete image. When you pull an image, Docker only downloads the layers you don't already have, significantly reducing bandwidth usage and storage requirements. This layering system also enables image caching during builds, where unchanged layers can be reused, dramatically accelerating the development cycle.

The layered approach brings significant practical benefits. If you have ten different applications that all use the same base Ubuntu image, Docker stores that base layer only once and shares it across all images. This copy-on-write strategy means containers can start almost instantaneously because they don't need to copy entire filesystems—they simply add a thin writable layer on top of the read-only image layers. Understanding this architecture helps you write more efficient Dockerfiles and troubleshoot storage-related issues effectively.

Installing Docker on Your System

Getting Docker running on your machine varies slightly depending on your operating system, but the process has become increasingly streamlined across all platforms. Docker Desktop provides the easiest installation experience for Windows and macOS users, bundling the Docker Engine, CLI client, Docker Compose, and Kubernetes support into a single package. For Linux users, Docker Engine can be installed directly through package managers, offering a more lightweight option without the additional desktop interface.

For Windows users, Docker Desktop requires Windows 10 64-bit Pro, Enterprise, or Education editions with Hyper-V enabled, or Windows 10 Home with WSL 2 (Windows Subsystem for Linux 2). Download the installer from the official Docker website, run it, and follow the installation wizard. After installation, Docker Desktop will start automatically and display a whale icon in your system tray when it's running. You may need to enable virtualization in your BIOS settings if it's not already activated, as Docker relies on hardware virtualization to run containers efficiently.

macOS users can install Docker Desktop by downloading the appropriate version for their processor architecture (Intel or Apple Silicon). The installation process involves dragging the Docker application to your Applications folder and launching it. Docker Desktop for Mac uses a lightweight Linux virtual machine to run the Docker daemon, providing a native-like experience that integrates seamlessly with macOS. The application includes a menu bar icon that provides quick access to Docker settings, container management, and troubleshooting tools.

Linux Installation Process

Linux installations offer the most direct path to running Docker, as containers share the host's kernel without requiring an intermediary virtual machine. The installation process varies by distribution, but Ubuntu serves as a common example. First, update your package index and install prerequisite packages to allow apt to use repositories over HTTPS:

sudo apt-get update
sudo apt-get install ca-certificates curl gnupg lsb-release

Next, add Docker's official GPG key and set up the stable repository:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Finally, install Docker Engine, CLI, and containerd:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

To avoid typing sudo before every Docker command, add your user to the docker group:

sudo usermod -aG docker $USER

After logging out and back in, you can run Docker commands without elevated privileges. This step improves workflow efficiency while maintaining security boundaries appropriate for development environments.

Verifying Your Installation

Regardless of your operating system, verifying that Docker installed correctly ensures you're ready to run containers. Open a terminal or command prompt and execute:

docker --version

This command displays the installed Docker version, confirming the client is accessible. To verify the complete Docker setup, including the daemon, run:

docker run hello-world

This command performs several operations: it checks for the hello-world image locally, pulls it from Docker Hub if not found, creates a container from the image, runs it, and displays a confirmation message. If you see a message explaining what just happened, congratulations—your Docker installation is fully functional and ready for real work.

Running Your First Container Step by Step

The moment has arrived to run your first real container. While the hello-world example confirms installation, running a more practical container demonstrates Docker's true capabilities. We'll start with an Nginx web server, a popular choice that showcases how containers can run services and expose them to your host system.

Execute the following command in your terminal:

docker run -d -p 8080:80 --name my-nginx nginx:latest

This single command accomplishes multiple tasks, and understanding each component reveals how Docker operates. The docker run command creates and starts a new container. The -d flag runs the container in detached mode, meaning it runs in the background rather than occupying your terminal. The -p 8080:80 flag maps port 8080 on your host machine to port 80 inside the container, allowing you to access the web server. The --name my-nginx assigns a friendly name to your container instead of using Docker's auto-generated names. Finally, nginx:latest specifies the image to use, with "nginx" being the image name and "latest" being the tag indicating the version.

Every Docker command tells a story of what you want to accomplish, and learning to read that story transforms you from someone who copies commands to someone who crafts solutions.

After running this command, Docker performs several operations behind the scenes. If the nginx image isn't already on your system, Docker pulls it from Docker Hub, which may take a moment depending on your internet connection. Once downloaded, Docker creates a new container from the image, configures the network settings to map the ports, and starts the Nginx process inside the container. You can verify the container is running by opening a web browser and navigating to http://localhost:8080, where you should see the default Nginx welcome page.

Managing Your Running Container

Now that your container is running, several commands help you interact with and manage it. To see all running containers, use:

docker ps

This command displays a table showing container IDs, image names, commands being executed, creation times, status, ports, and names. To see all containers including stopped ones, add the -a flag:

docker ps -a

To view the logs from your Nginx container, which shows access logs and any errors:

docker logs my-nginx

Adding the -f flag follows the logs in real-time, similar to tail -f on Linux systems. This proves invaluable for debugging and monitoring container behavior during development.

Stopping and Removing Containers

When you're finished with a container, proper cleanup prevents resource waste and keeps your system organized. To stop the running Nginx container:

docker stop my-nginx

This command sends a SIGTERM signal to the main process in the container, allowing it to shut down gracefully. If the container doesn't stop within a default timeout period (usually 10 seconds), Docker sends a SIGKILL signal to force termination. You can specify a custom timeout with the -t flag if your application requires more time for cleanup operations.

Stopping a container doesn't remove it—it remains on your system in a stopped state, preserving any data or configuration changes made during its runtime. To completely remove a container:

docker rm my-nginx

You can combine stopping and removing in a single command:

docker rm -f my-nginx

The -f flag forces removal even if the container is still running, though gracefully stopping before removing is generally preferable for production scenarios.

Exploring Interactive Containers and Shell Access

While running services like web servers demonstrates one use case for containers, interactive containers offer a powerful way to experiment with different operating systems and tools without affecting your host system. Running an interactive container gives you a shell prompt inside the container, allowing you to explore its filesystem, install packages, and execute commands as if you were logged into a separate machine.

To run an interactive Ubuntu container:

docker run -it ubuntu:latest bash

The -it flags combine two options: -i keeps STDIN open even if not attached, and -t allocates a pseudo-TTY, essentially giving you an interactive terminal session. The bash at the end specifies the command to run inside the container—in this case, the Bash shell. When you execute this command, you'll see a prompt indicating you're inside the container, typically showing a hash representing the container ID.

Interactive containers transform learning into experimentation—you can try anything, break everything, and simply delete the container to start fresh, making mistakes not just acceptable but encouraged.

Inside the container, you can run standard Linux commands, install software using apt, create files, and modify configurations. For example, update the package list and install a tool:

apt-get update
apt-get install curl -y
curl --version

These changes exist only within this specific container. When you exit the shell by typing exit or pressing Ctrl+D, the container stops, and unless you commit the changes to a new image, they're lost. This ephemeral nature encourages treating containers as disposable, which aligns with modern infrastructure practices where configuration is defined in code rather than manually applied to running systems.

Accessing Running Containers

Sometimes you need to access a container that's already running to inspect its state, debug issues, or perform maintenance tasks. The docker exec command allows you to execute commands in a running container without stopping it:

docker exec -it my-nginx bash

This command opens an interactive Bash shell in the my-nginx container while it continues running. You can explore the container's filesystem, check running processes with ps aux, view configuration files, or investigate logs. When you exit this shell, the container continues running unchanged—you've simply disconnected from it.

The docker exec command proves invaluable for troubleshooting. You can execute single commands without entering an interactive session:

docker exec my-nginx ls -la /etc/nginx

This lists the contents of the Nginx configuration directory without opening a shell, useful for quick checks or scripting scenarios where you need to query container state programmatically.

Understanding Docker Images and Tags

Every container starts from an image, and understanding how images work, how they're named, and how to find the right one dramatically improves your Docker effectiveness. Docker images follow a naming convention: repository:tag. The repository name identifies the image, while the tag specifies a particular version or variant. When you omit the tag, Docker assumes you want the latest tag, though this doesn't necessarily mean the most recent version—it simply means whatever the image maintainer tagged as "latest."

Docker Hub serves as the default public registry containing thousands of official and community-maintained images. Official images undergo security reviews and follow best practices, making them reliable starting points for your projects. To search for images from the command line:

docker search python

This command displays available Python images along with their descriptions, star ratings, and official status. However, browsing Docker Hub through a web browser often provides more detailed information, including available tags, documentation, and usage examples.

Pulling Images Before Running

While docker run automatically pulls images if they're not available locally, explicitly pulling images beforehand can be useful, especially when preparing for offline work or when you want to ensure you have the latest version:

docker pull python:3.11-slim

This command downloads the Python 3.11 slim variant, which contains Python and essential dependencies but excludes many packages included in the full image, resulting in a smaller size. Understanding tag variants helps you choose the right balance between functionality and image size:

• 🏷️ latest – The default tag, typically points to the most recent stable release
• 📦 alpine – Based on Alpine Linux, extremely small but may lack some utilities
• ⚖️ slim – Smaller than full images but larger than alpine, good balance
• 🔢 version numbers – Specific versions like 3.11, 3.11.5, providing version control
• 🔧 variant suffixes – Additional descriptors like -bullseye or -buster indicating base OS

To see which images you have downloaded locally:

docker images

This command lists all images on your system, showing repository names, tags, image IDs, creation dates, and sizes. Over time, you'll accumulate many images, and periodically cleaning up unused ones helps reclaim disk space:

docker image prune

This removes dangling images—those not associated with any container and not tagged. Adding the -a flag removes all unused images, not just dangling ones, though use this cautiously as it will delete images you might want to use again.

Working with Environment Variables and Configuration

Containers often need configuration specific to your environment, and Docker provides several mechanisms for passing configuration data. Environment variables represent the most common approach, allowing you to customize container behavior without modifying the image itself. This separation of configuration from code embodies the twelve-factor app methodology, making applications more portable and easier to manage across different environments.

To set environment variables when running a container, use the -e flag:

docker run -d -e MYSQL_ROOT_PASSWORD=secretpassword -e MYSQL_DATABASE=myapp mysql:8.0

This command runs a MySQL container with two environment variables: one setting the root password and another creating a database named "myapp" on startup. Many official images use environment variables for initial configuration, and their Docker Hub documentation details which variables are available and what they control.

Configuration through environment variables transforms static images into flexible components that adapt to any environment, from local development to production clusters, without requiring image rebuilds.

For containers requiring multiple environment variables, typing them individually becomes cumbersome. Docker supports environment files that contain variable definitions:

docker run -d --env-file ./config.env mysql:8.0

The config.env file contains variable definitions in KEY=VALUE format, one per line. This approach keeps sensitive configuration out of command history and version control, improving security and maintainability.

Mounting Volumes for Persistent Data

By default, data written inside a container exists only within that container and disappears when the container is removed. For applications that need to persist data—databases, file uploads, logs—Docker volumes provide a solution. Volumes are stored outside the container's filesystem, allowing data to survive container deletion and be shared between containers.

To create and use a named volume:

docker volume create my-data
docker run -d -v my-data:/var/lib/mysql mysql:8.0

The -v flag mounts the volume named "my-data" to the path /var/lib/mysql inside the container, where MySQL stores its data files. Now, even if you remove and recreate the container, the data persists in the volume. You can also mount host directories directly:

docker run -d -v /path/on/host:/path/in/container nginx:latest

This bind mount makes the host directory available inside the container at the specified path, useful for development scenarios where you want to edit files on your host and see changes reflected immediately in the container without rebuilding images.

Networking Basics for Container Communication

Containers don't exist in isolation—they often need to communicate with each other, with the host system, and with external networks. Docker provides several networking modes that define how containers connect to networks and each other. Understanding these networking concepts enables you to build multi-container applications where services communicate securely and efficiently.

When you run a container without specifying a network, Docker connects it to the default bridge network. Containers on the same bridge network can communicate using their IP addresses, but Docker also provides DNS resolution, allowing containers to reach each other by container name. To create a custom bridge network:

docker network create my-network

Then run containers on this network:

docker run -d --name web --network my-network nginx:latest
docker run -d --name app --network my-network python:3.11

Now the "app" container can reach the "web" container by simply using "web" as the hostname in network requests. This automatic DNS resolution simplifies configuration and makes applications more portable, as you don't need to hardcode IP addresses that might change.

Port Publishing and Host Access

By default, containers can make outbound connections to the internet, but inbound connections require explicit port publishing. We've seen the -p flag earlier, but understanding its full syntax reveals more possibilities:

docker run -d -p 8080:80 nginx:latest          # Map host port 8080 to container port 80
docker run -d -p 127.0.0.1:8080:80 nginx:latest  # Bind only to localhost
docker run -d -p 80 nginx:latest                 # Map random host port to container port 80

The format follows host_ip:host_port:container_port, with optional components. Publishing ports makes services accessible from outside the container, essential for web applications, APIs, and any service that needs external access. You can publish multiple ports by using multiple -p flags:

docker run -d -p 8080:80 -p 8443:443 nginx:latest

This exposes both HTTP and HTTPS ports, allowing the container to handle both protocols. To see which ports are published for a running container:

docker port my-nginx

Networking in Docker mirrors real-world networking principles but abstracts away complexity, letting you focus on application architecture rather than network infrastructure minutiae.

Troubleshooting Common Issues

Even with straightforward commands, you'll occasionally encounter issues when running containers. Understanding common problems and their solutions accelerates your learning and prevents frustration. Many issues stem from misunderstandings about how Docker works rather than actual bugs, and recognizing these patterns helps you debug effectively.

One frequent issue involves port conflicts. If you try to map a host port that's already in use, Docker returns an error. To identify what's using a port on Linux or macOS:

lsof -i :8080

On Windows, use:

netstat -ano | findstr :8080

Either stop the conflicting service or choose a different host port for your container. Remember that port conflicts occur on the host side—multiple containers can use the same internal port as long as they map to different host ports.

Container Won't Start or Exits Immediately

If a container exits immediately after starting, the logs usually reveal why:

docker logs container-name

Common causes include incorrect environment variables, missing required configuration, or the container's main process exiting because it has nothing to do. For example, running a container with bash as the main process without the -it flags causes immediate exit because bash has no terminal to attach to. Understanding that containers run only as long as their main process runs clarifies many mysterious exits.

Permission issues often arise when mounting host directories, especially on Linux systems. If your container can't write to a mounted volume, check the directory permissions on your host and consider using the --user flag to run the container as a specific user ID:

docker run -d --user 1000:1000 -v /host/path:/container/path image:tag

Image Pull Failures

Network issues, authentication problems, or incorrect image names cause pull failures. Verify the image name and tag exist by searching Docker Hub. If you're behind a corporate proxy, configure Docker to use it by adding proxy settings to Docker's daemon configuration. For authentication issues with private registries, log in first:

docker login registry.example.com

Then provide your credentials. Docker stores authentication tokens, allowing subsequent pulls from that registry without re-authentication.

Resource Constraints

Containers consume host resources, and running many containers or resource-intensive applications can exhaust available memory or CPU. Docker Desktop on Windows and macOS allows you to configure resource limits in the settings. On Linux, the host's resources are directly available to containers, but you can limit individual containers:

docker run -d --memory="512m" --cpus="1.5" nginx:latest

This limits the container to 512 megabytes of memory and 1.5 CPU cores, preventing a single container from monopolizing system resources. Monitoring resource usage helps identify containers that need optimization:

docker stats

This command displays real-time resource usage for all running containers, showing CPU percentage, memory usage, network I/O, and block I/O, invaluable for performance troubleshooting.

Best Practices for Running Containers

As you become comfortable running containers, adopting best practices ensures your Docker usage remains secure, efficient, and maintainable. These principles apply whether you're experimenting locally or deploying to production environments, forming habits that scale from simple tests to complex applications.

Use specific image tags rather than "latest" in any scenario beyond experimentation. While "latest" is convenient for testing, it introduces unpredictability because the image it points to changes over time. Specifying exact versions like nginx:1.24.0 ensures reproducibility—your container behaves identically whether you run it today or six months from now. This version pinning prevents unexpected breakage when image maintainers release updates.

Run containers as non-root users whenever possible. Many images run processes as root by default, which poses security risks if a vulnerability allows container escape. Check the image documentation for how to run as a non-privileged user, or use the --user flag. Some images include specific user accounts designed for running the application safely.

Clean up unused resources regularly to prevent disk space exhaustion. Docker accumulates stopped containers, unused images, and dangling volumes over time. Periodic cleanup maintains system health:

docker system prune

This command removes stopped containers, dangling images, and unused networks. Add -a to also remove unused images, and --volumes to remove unused volumes, though be cautious with volumes as they may contain data you want to keep.

Best practices aren't restrictions that limit what you can do—they're guardrails that keep you safe while you explore the full potential of containerization.

Use environment variables for configuration rather than building configuration into images. This separation allows the same image to run in development, staging, and production with different configurations, embodying the principle of building once and deploying everywhere. Store sensitive values like passwords in secrets management systems rather than environment variables when possible, especially in production environments.

Monitor container logs and health to catch issues early. Many production-ready images include health checks that Docker can monitor:

docker run -d --health-cmd="curl -f http://localhost/ || exit 1" --health-interval=30s nginx:latest

This runs a health check every 30 seconds, marking the container as unhealthy if the command fails. Docker can restart unhealthy containers automatically with the appropriate restart policy:

docker run -d --restart=unless-stopped nginx:latest

Restart policies ensure containers recover from failures without manual intervention, improving reliability in production scenarios.

Exploring Real-World Use Cases

Understanding practical applications helps contextualize the commands and concepts we've covered. Containers excel in numerous scenarios, from simplifying development workflows to enabling sophisticated deployment strategies. Exploring these use cases reveals how professionals leverage Docker daily.

Development environment consistency represents one of Docker's most immediate benefits. Instead of installing multiple versions of programming languages, databases, and tools directly on your machine, you run them in containers. Need to test your application against PostgreSQL 14 and 15? Run both in separate containers:

docker run -d --name postgres14 -e POSTGRES_PASSWORD=secret -p 5432:5432 postgres:14
docker run -d --name postgres15 -e POSTGRES_PASSWORD=secret -p 5433:5432 postgres:15

Your application can connect to either database by changing the port number, and you avoid conflicts between different PostgreSQL installations on your host system. When you're done, remove the containers without affecting your system configuration.

Microservices architecture benefits enormously from containerization. Each service runs in its own container, communicating over networks, allowing independent scaling and deployment. You might run a web frontend, API backend, database, and cache, each in separate containers:

docker network create app-network
docker run -d --name redis --network app-network redis:latest
docker run -d --name postgres --network app-network -e POSTGRES_PASSWORD=secret postgres:14
docker run -d --name api --network app-network -p 8000:8000 myapi:latest
docker run -d --name web --network app-network -p 80:80 myweb:latest

This setup creates an isolated network where services communicate by name, with only the web and API containers exposing ports to the host. This architecture mirrors production deployments, making local development more representative of real-world conditions.

Testing and Continuous Integration

Containers provide consistent, reproducible environments for running tests. CI/CD pipelines use containers to ensure tests run in identical environments regardless of which machine executes them. You can run tests in containers locally before pushing code, catching issues earlier:

docker run --rm -v $(pwd):/app -w /app python:3.11 python -m pytest

This command runs pytest inside a Python container, mounting your current directory as /app and setting it as the working directory. The --rm flag automatically removes the container after tests complete, keeping your system clean. This approach guarantees tests run with the exact Python version and dependencies defined in your requirements, eliminating "works on my machine" problems.

Learning and experimentation become risk-free with containers. Want to try a new database system, programming language, or tool? Run it in a container, experiment freely, and delete it when finished without leaving artifacts on your system. This disposability encourages exploration and learning, as mistakes have no lasting consequences. You can even run graphical applications in containers with appropriate X11 forwarding on Linux or using specialized images designed for GUI applications.

Moving Beyond Basic Commands

Running containers manually with docker run works well for learning and simple scenarios, but real applications typically involve multiple containers working together. Docker Compose addresses this need, allowing you to define multi-container applications in a YAML file and manage them with simple commands. While Compose goes beyond running your first container, understanding it exists and what it solves helps you recognize when to graduate from individual commands to more sophisticated orchestration.

Similarly, creating your own images using Dockerfiles transforms you from a consumer of containers to a creator. Dockerfiles define the steps to build an image, allowing you to package your applications for distribution and deployment. Learning to write Dockerfiles represents the natural next step after mastering container basics, enabling you to leverage Docker's full potential in your projects.

Container orchestration platforms like Kubernetes, Docker Swarm, and others handle running containers at scale across multiple machines, providing features like automatic scaling, load balancing, and self-healing. While these platforms introduce significant complexity, they build upon the same fundamental concepts you've learned: images, containers, networks, and volumes. The skills you've developed running your first container form the foundation for understanding these advanced topics.

Every expert started by running their first container, making mistakes, reading error messages, and gradually building understanding through experimentation and practice.

Security Considerations

While containers provide isolation, they're not a complete security solution. Understanding basic security principles helps you use Docker safely, especially when running containers from public registries. Only use images from trusted sources—official images and verified publishers undergo security reviews, while random images from unknown maintainers might contain malware or vulnerabilities.

Scan images for vulnerabilities using tools like Docker Scout or Trivy:

docker scout quickview nginx:latest

These tools analyze image layers for known security vulnerabilities, helping you make informed decisions about which images to use. Keep images updated by regularly pulling new versions, as maintainers patch security issues in updated releases.

Limit container capabilities and privileges to reduce the attack surface. Docker provides numerous security options, from dropping Linux capabilities to using security profiles like AppArmor or SELinux. While these advanced features require deeper understanding, awareness of their existence helps you recognize when to investigate them further.

Never store secrets like passwords, API keys, or certificates in images or pass them via command line arguments that appear in logs and process listings. Use environment variables as a minimum, and investigate Docker secrets or external secrets management systems for production deployments.

Performance Optimization Tips

Container performance generally matches native performance, but certain practices ensure optimal resource utilization. Choose appropriate base images—Alpine-based images offer minimal size but may lack libraries your application needs, while full images include everything but consume more disk space and memory. Slim variants often provide the best balance.

Use .dockerignore files when building images to exclude unnecessary files from the build context, speeding up builds and reducing image size. Similar to .gitignore, .dockerignore lists patterns of files and directories to exclude.

Leverage Docker's layer caching by ordering Dockerfile instructions from least to most frequently changing. Instructions that rarely change should appear early in the Dockerfile, allowing Docker to reuse cached layers instead of rebuilding everything.

Monitor resource usage with docker stats and adjust limits as needed. Some applications benefit from specific resource allocations, while others work fine with defaults. Profiling helps identify bottlenecks and optimization opportunities.

What does "docker run" actually do?

The docker run command creates a new container from a specified image and starts it. If the image isn't available locally, Docker automatically pulls it from the configured registry (typically Docker Hub). The command combines several operations: creating a container, configuring its network and storage, and starting the process defined in the image. Various flags modify this behavior, allowing you to customize networking, mount volumes, set environment variables, and control how the container runs.

How do I stop a running container?

Use docker stop container-name to gracefully stop a container by sending a SIGTERM signal to its main process, allowing it to shut down cleanly. If the container doesn't stop within the timeout period (default 10 seconds), Docker sends SIGKILL to force termination. For immediate termination without graceful shutdown, use docker kill container-name. After stopping, the container remains on your system in a stopped state until you explicitly remove it with docker rm container-name.

What's the difference between an image and a container?

An image is a read-only template containing the application code, runtime, libraries, and dependencies needed to run software. Think of it as a blueprint or recipe. A container is a running instance created from an image—it's the actual execution environment where your application runs. You can create multiple containers from a single image, each running independently. Images are static and unchanging, while containers are dynamic and maintain state during execution. When a container is removed, changes made during its lifetime are lost unless explicitly saved to a new image or stored in volumes.

Why does my container exit immediately after starting?

Containers run only as long as their main process runs. If the main process exits or completes quickly, the container stops. This commonly happens when running shell commands without keeping the terminal open (missing -it flags), when the application encounters an error during startup, or when the container's main process is designed to run a one-time task rather than a long-running service. Check the container logs with docker logs container-name to see what happened. For interactive containers, ensure you use both -i and -t flags to keep STDIN open and allocate a terminal.

How do I access files inside a running container?

Several methods allow file access. Use docker exec -it container-name bash to open a shell inside the container and navigate its filesystem interactively. To copy files between the host and container, use docker cp: docker cp container-name:/path/in/container /path/on/host copies from container to host, while reversing the arguments copies from host to container. For persistent access during development, mount host directories using the -v flag when running the container, making host files available inside the container and vice versa.

Can multiple containers use the same port?

Multiple containers can use the same internal port without conflict because each container has its own network namespace. However, you cannot map multiple containers to the same host port—each container must map to a different host port. For example, three containers can all run web servers on port 80 internally, but you'd map them to different host ports like 8080, 8081, and 8082. This allows multiple instances of the same service to run simultaneously on one machine, each accessible through its unique host port.