1. BRIDGE NETWORK (DEFAULT)-When a container is executed without specifying a network for it, the docker places them on the default bridge network. Now, these containers can communicate with each other using IP addresses, which might not be so convenient.
2. USER DEFINED BRIDGE NETWORKS- When the programmer creates a custom bridge network now the containers can communicate with each other using using container names as host names. The docker sets up internal DNS so webapp can communicate with the database just by name.
3. DOCKER COMPOSE- Compose automatically creates a network for your services. All services in the same docker-compose.yml can communicate with each other by name.
4. VOLUMES (FOR FILE SHARING)- If containers need to share files, you can mount a shared volume. This isn’t for network communication, but it’s another form of interaction.
5. HOST NETWORKING (ADVANCE)- Containers share the host’s network stack. This is useful for performance but removes isolation.
PORT MAPPING
By default, containers are isolated from the host network. If a service (like a web server) is running inside a container, we won’t be able to access it from the browser or another machine unless we map its internal port to a port on the host.
SYNTAX
docker run -p <host_port>:<container_port> image_name
EXPOSE
The EXPOSE instruction in a Docker file declares which port the containerized application will listen on at runtime.
It serves as documentation for inter-container communication, not for external access.
It does not publish the port to the host machine.
To make the port accessible externally, use the -p or --publish flag when running the container.
TIPS TO REMEMBER-
- Use “
docker ps"to see which ports are mapped. - Use
-Pto publish all exposed ports to random host ports. - Be cautious when exposing sensitive services like databases.
BIND MOUNTS
Bind mounts in docker allow us to link a specific file or directory on the host machine directly into a container, i.e. any changes made in the container are instantly reflected on the host, and vice versa.
THEY ARE USED FOR-
- Sharing source code during development
- Persisting logs or config files
- Accessing host resources like
"/etc/resolv.conf“
BIND MOUNTS VS VOLUMES
| FEATURES | BIND MOUNTS | VOLUMES |
| LOCATION | any path is possible on the host file | managed by docker in /var/lib/docker/volumes |
| SETUP | it requires full path to host directory | Created and managed by Docker CLI or API |
| PORTABILITY | Less portable—depends on host directory structure | More portable—Docker handles storage location |
| SECURITY | Less secure—can access sensitive host files | More secure—isolated from host filesystem |
| USE CASE | Useful for development and debugging with live code changes | Recommended for production and persistent container data |
| BACKUP & RESTORE | Manual and error-prone | Easier with Docker tooling and volume drivers |
| PERFORMANCE | May be slower on non-Linux systems (e.g., Windows, macOS) | Optimized for Docker, especially on Linux |
DOCKER COMPOSE- THE TOOL
Docker compose is a good tool for managing multi-container applications with ease. Instead of running multiple docker run commands, you define everything in a single “docker-compose.yml” file. This spins up both containers, connects them via a shared network, and maps ports as defined.
CORE CONCEPTS-
- Networks: Compose creates a default network so services can talk to each other by name.
- Services: Each container (e.g., web, database) is defined as a service.
- Volumes: Used to persist data across container restarts.
- Dependencies: You can control startup order using
depends_on.
EXAMPLE CODE-
version: ‘3.8’
services:
web:
image: nginx
ports:
– “8080:80”
db:
image: postgres
environment:
POSTGRES_PASSWORD: mysecret