Tutorials on Docker — Day 2
Docker Architecture And Docker Objects
Welcome, I’m pleased to take you on a tour of Docker’s most impressive architecture. I’ll also take you on a little journey to show you two well-known docker objects. Are you all set?
Docker is built on a client-server model. The user interacts with the daemon through the Docker client rather than directly with the daemon. Docker’s main user interface is the Docker client. It receives user commands and talks with a Docker daemon “back and forth.”
The Docker client communicates with the Docker daemon, which handles the construction, execution, and distribution of your Docker containers. The Docker daemon is also known as the Docker engine or the Docker server.
The Docker daemon
The Docker daemon (dockerd) handles Docker objects such as images, containers, networks, and volumes by listening for Docker API calls. To manage Docker services, a daemon can communicate with other daemons.
The Docker client
Many Docker users interact with Docker primarily through the Docker client (docker). When you perform commands like docker run, the client transmits them to dockerd, which executes them. The Docker API is used by the docker command. The Docker client has the ability to communicate with many daemons.
Docker registries
Docker images are stored on a Docker registry. Docker Hub is a public registry that anybody may access, and Docker is set up by default to seek for images on it. It’s even possible to establish your own private register.
The relevant images are retrieved from your specified registry when you use the docker pull or docker run commands. Your image gets pushed to your configured registry when you run the docker push command.
The following are some of the Public Registries:
- Google Container Registry — GCR
- Amazon Elastic Container Registry — ECR
- Azure Container Registry — ACR
- Private Docker Registry
Docker Objects
You create and utilise images, containers, networks, volumes, plugins, and other objects when you use Docker. This section provides a quick summary of a two of them
Docker Images
The Docker ecosystem relies heavily on Docker images. You may use dockerfiles to generate your own images, or you can utilise those made by others and published in a registry like Docker hub.
Docker images are used to define instructions for your containers to execute. You can select to have a certain operating system, install specific packages, or run a set of predefined tasks on Docker images.
Using the docker images command, you may see a list of all the images on your local system.
The docker run command or the docker pull command may be used to get images from Docker Hub, as demonstrated below.
To construct your own image, develop a Dockerfile using simple syntax that defines the steps required to create and execute the image. A simple docker file for building a node image is shown below.
FROM node:14
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
EXPOSE 80
CMD [ "node", "server.js" ]Now, using the docker build command, we can create a docker image from this dockerfile, as seen in the image below.
Each Dockerfile instruction builds a layer in the image. Only the layers that have changed are rebuilt when you edit the Dockerfile and rebuild the image. When compared to other virtualization methods, this is part of what makes images so light, tiny, and quick.
Docker images are stored in a Docker registry like Docker Hub, which is a public registry with a huge number of images to choose from. Many repositories, such as mysql, nginx, Ubuntu, and Redis, may be found here. Docker, Inc., the corporation that created Docker, sponsors a dedicated staff that is in charge of vetting and releasing all material from the official repository.
Docker Containers
A Docker container image is a lightweight, portable encapsulations of executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. If an image is a class, then a container is an instance of a class, a runtime object. Containers are hopefully why you’re using Docker; that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
We create a container from an image, and then run the container. And inside that container, we have all the binaries and dependencies we need to run our application.
We can display all the running and stopped containers using docker ps -aq command as demonstrated below.
That’s it for now. I’m excited to meet you again to “Run Your First Container” in the next post. Until then take care ….
