What is Docker?
Docker is an open platform for developing, shipping, and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same ways you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.
Docker architecture
Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers. The Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface. Another Docker client is Docker Compose, that lets you work with applications consisting of a set of containers.
The Docker daemon
The Docker daemon (dockerd) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services.
The Docker client
The Docker client (docker) is the primary way that many Docker users interact with Docker. When you use commands such as docker run, the client sends these commands to dockerd, which carries them out. The docker command uses the Docker API. The Docker client can communicate with more than one daemon.
Docker Desktop
Docker Desktop is an easy-to-install application for your Mac or Windows environment that enables you to build and share containerized applications and microservices. Docker Desktop includes the Docker daemon (dockerd), the Docker client (docker), Docker Compose, Docker Content Trust, Kubernetes, and Credential Helper. For more information, see Docker Desktop.
Docker registries
A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry.
When you use the docker pull or docker run commands, the required images are pulled from your configured registry. When you use the docker push command, your image is pushed to your configured registry.
Docker objects
When you use Docker, you are creating and using images, containers, networks, volumes, plugins, and other objects. This section is a brief overview of some of those objects.
Images
An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the ubuntu image, but installs the Apache web server and your application, as well as the configuration details needed to make your application run.
You might create your own images or you might only use those created by others and published in a registry. To build your own image, you create a Dockerfile with a simple syntax for defining the steps needed to create the image and run it. Each instruction in a Dockerfile creates a layer in the image. When you change the Dockerfile and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization technologies.
Containers
A container is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state.
By default, a container is relatively well isolated from other containers and its host machine. You can control how isolated a container’s network, storage, or other underlying subsystems are from other containers or from the host machine.
A container is defined by its image as well as any configuration options you provide to it when you create or start it. When a container is removed, any changes to its state that are not stored in persistent storage disappear.
How EXPOSE and –expose work
Basically, EXPOSE is a documentation mechanism that gives configuration information another command can use, provides a hint about which initial incoming ports will provide services, or informs the decisions that the container operator makes. EXPOSE does not provide much networking control to an image developer.
As earlier explained, you can use the –expose flag in a Docker run string to add to the exposed ports.
By default, the EXPOSE instruction does not expose the container’s ports to be accessible from the host. In other words, it only makes the stated ports available for inter-container interaction.
For example, let’s say you have a Node.js application and a Redis server deployed on the same Docker network. To ensure the Node.js application communicates with the Redis server, the Redis container should expose a port.
If you check the Dockerfile of the official Redis image, a line is included that says EXPOSE 6379. This is what allows the two containers to talk with one another.
Therefore, when your Node.js application connects to the 6379 port of the Redis container, the EXPOSE directive is what ensures the inter-container communication takes place.
Publishing Docker ports via -P or -p
There are two ways of publishing ports in Docker:
- Using the -P flag
- Using the -p flag
Let’s talk about each of them.
a) Using the -P flag
Using the -P (upper case) flag at runtime lets you publish all exposed ports to random ports on the host interfaces. It’s short for –publish-all.
As earlier mentioned, EXPOSE is usually used as a documentation mechanism; that is, hinting to the container operator about the port(s) providing services.
Docker allows you to add -P at runtime and convert the EXPOSE instructions in the Dockerfile to specific port mapping rules.
Docker identifies all ports exposed using the EXPOSE directive and those exposed using the –expose parameter. Then, each exposed port is mapped automatically to a random port on the host interface. This automatic mapping also prevents potential port mapping conflicts.
b) Using the -p flag
Using the -p (lower case) flag at runtime lets you publish a container’s specific port(s) to the Docker host. It’s short for –publish.
It allows you to map a container’s port or a range of ports to the host explicitly—instead of exposing all Docker ports.
Note that irrespective of the EXPOSE instructions in the Dockerfile, using the -p flag at runtime allows you to override them.
There are different formats for declaring the -p flag:
Here is how you can run it:
Basically, you may leave out either ip or hostPort references. However, you should always state the containerPort to expose. If ip or hostPort is left out, Docker will automatically provide them.
Furthermore, each of the publishing rules defaults to the TCP protocol. If you want UDP, you’ll need to specify it.
Here are some Docker expose port examples using the -p flag:
How publishing ports works
By default, if you use the docker run or docker create command to run or create a container, they do not make any Docker’s ports accessible by services in the outside world.
So, while it’s possible for your Docker containers to connect to the outside world without making any changes to your code, it’s not possible for the outside world to connect to your Docker containers.
If you want to override this default behavior, you can use either the -P or the -p flag in your Docker run string.
Publishing ports produce a firewall rule that binds a container port to a port on the Docker host, ensuring the ports are accessible to any client that can communicate with the host.
It’s what makes a port accessible to Docker containers that are not connected to the container’s network, or services that are outside of your Docker environment.
Differences between EXPOSE and publish
Whereas publishing a port using either -P or -p exposes it, exposing a port using EXPOSE or –expose does not publish it.
So, while exposed ports can only be accessed internally, published ports can be accessible by external containers and services. That’s the main difference between exposing and publishing ports in Docker.