The core components of Docker are:

  • Docker client and server, also known as docker engine;
  • Docker mirror
  • registry
  • Docker container

Docker client and server

Docker is a client/server (C/S) architecture program. The Docker client simply issues a request to the Docker server or daemon, which does all the work and returns the result. Docker daemons are sometimes called Docker engines. Docker provides a command line tool Docker and a set of RESTful apis to interact with daemons. Users can run Docker daemons and clients on the same host, or connect from a local Docker client to a remote Docker daemon running on another host. Docker architecture is shown below:

Docker mirror

Images are the building blocks of the Docker world. Users run their own containers based on images. Mirroring is also the “build” part of the Docker life cycle. A mirror is a layered structure based on a Union file system, built step by step from a series of instructions. You can also think of the image as the “source code” for the container. Images are small, very “portable” and easy to share, store, and update.

registry

Docker uses Registry to hold user-built images. Registry is classified as public and private. Docker operates a public Registry called Docker Hub. Users can register with Docker Hub to share and save their images. At last count, there were over 10, 000 registered users building and sharing images on Docker Hub. Need a Docker image of the Nginx Web server, or an image of the PABX Asterix open source system, or an image of the MySQL database? These images are available on Docker Hub and in multiple versions. Users can also save their own private images on the Docker Hub. For example, an image that contains source code or patent information that needs to be kept secret, or that is only visible within the team or organization. Users can even set up their own private Registry. Private Registry can be protected by a firewall, keeping images behind the firewall to meet the special needs of some organizations.

The container

Docker helps users build and deploy containers by packaging their applications or services into them. As we mentioned earlier, the container is launched based on an image, and one or more processes can run in the container. We can think of images as the build or package phase of the Docker life cycle, and containers as the start or execution phase. Docker containers are:

  • A mirror format
  • A series of standard operations
  • An execution environment

Docker borrows from the standard container concept. Standard containers transport goods to all parts of the world, and Docker applies this model to its design philosophy. The only difference is that containers transport goods, while Docker transport software. Each container contains a software image, the container’s “cargo,” and just like real cargo, the software image inside the container can do something. For example, images can be created, started, shut down, restarted, and destroyed. Like a container, Docker doesn’t care what’s inside the container, whether it’s a Web server, a database, or an application server. All containers “load” content in the same way. Docker also doesn’t care where users ship containers: can users build containers in their laptops, upload them to Registry, download them to a physical or virtual server for testing, and then deploy the containers to Ama? On The EC2 host cluster. Like standard containers, Docker containers are easy to replace, can be stacked, easy to distribute, and as versatile as possible. With Docker, you can quickly build an application server, a message bus, a set of utilities, a Continuous Integration (CI) test environment, or any kind of application, service, or tool. You can build a complete test environment locally, or you can quickly replicate a complex set of application stacks for production or development. It can be said that Docker has a wide range of application scenarios.