Shulou(Shulou.com)06/01 Report--

This article shows you how to carry out the analysis of Docker image management, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

Run the container sample Nginx

Download the image directly and start the container. Select the alpine version here:

$docker run-- name web1-p 8001VR 80-d nginx:alpineUnable to find image 'nginx:alpine' locallyalpine: Pulling from library/nginxe7c96db7181b: Downloading 3fb6217217ef: Download complete alpine: Pulling from library/nginxe7c96db7181b: Pull complete 3fb6217217ef: Pull complete Digest: sha256:17bd1698318e9c0f9ba2c5ed49f53d690684dab7fe3e8019b855c352528d57beStatus: Downloaded newer image for nginx:alpine01c17a72e943e93d71b56b433bea7a3d6ffa1f848dc3947f2adaf2bb2e3e7fee$

Description of startup parameters:

-d, which means that after starting the container, it runs in the background of the host.

-p, port mapping, which maps port 8001 of the host to port 80 inside the container. Port mapping is part of network and will be described in more detail later.

View the launched container:

$docker container lsCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMESf57cd5f9d50f nginx:alpine "nginx-g'daemon of..." 13 minutes ago Up 12 minutes 0.0.0.0 minutes ago Up 8001-> 80/tcp web1 $

You can see the port and port mapping.

The focus here is on COMMAND, and the above display is truncated:

$docker container ls-- no-trunc-- format'{{.Command}}'"nginx-g 'daemon off;'" $

Here the startup nginx adds parameters, and daemon off literally means to shut down the daemon. This is for nginx to run in the foreground.

If it is the default startup mode of nginx, then the nginx program will run in the background. Once the nginx is started, there will be no programs, and as a result, the container will exit.

To execute any program or service in a container, you must not run in the background in the container. As long as it runs in the background, it will be terminated as soon as it starts.

Now that Nginx is started, you can access it directly from the browser. And port mapping is done, so it can be accessed directly through the port of the host: the IP address of the http://[ host]: 8001.

Container log

The purpose of each container is simply to run a program that is the main process of the container, PID=1. The logs of traditional programs are generally saved in log files, but this is not necessary in the container. Because now the whole container is just to run a process, the log can be printed directly on the console, which is the effect of the program running directly in the foreground.

Use the following command to view the log:

$docker container logs web1

After viewing, visit the page several times to see if there is an access log refresh.

Redis

First, start a redis directly:

$docker container run-- name redis-d redis:alpine

After the container starts, it still stays in the command line interface of the host.

Enter the inside of the container

Now you need to go inside the container and operate, just like the previous busybox. However, this time a redis-server program is running inside the capacity, and there is usually only one program running inside a container. So there is no shell in the container.

Unlike the previous busybox container, there is a shell inside the busybox container. So there is no terminal interface for direct access. Here you need to start a shell and enter:

$docker container exec-it redis / bin/sh/data # psPID USER TIME COMMAND 1 redis 0:00 redis-server 12 root 0:00 / bin/sh 23 root 0:00 ps/data #

Enter and execute the command to view the processes in the current container.

As you can see here, in addition to the ps command, there is also the original redis-server and the shell that is started when you enter the container. So it's okay to run multiple processes inside the container, and that's the case now. However, this is generally the case in which multiple processes need to be run in the container.

Perform other actions

Now that you're all in, run some commands. Look at the time of the system:

/ data # dateTue Jul 16 13:03:05 UTC 2019/data #

The time is fine, but the time zone is not right. Skip this.

View port snooping:

/ data # netstat-tnlActive Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.06379 0.0.0.0 LISTEN tcp 0 0:: 6379:: * LISTEN / data #

Use the redis-cli command:

/ data # redis-cli127.0.0.1:6379 > set age 23OK127.0.0.1:6379 > set name AdamOK127.0.0.1:6379 > keys * 1) "name" 2) "age" 127.0.0.1 set age 23OK127.0.0.1:6379 6379 > exit/data # exit$

Here you can see that redis-cli has its own user interface, so you can enter directly without starting / bin/sh:

$docker container exec-it redis redis-cli127.0.0.1:6379 > exit$Docker image

The basics of Docker mirroring.

Mirror start

The docker image contains the file system and its contents needed to start the container, so it is used to create and start the docker container.

The hierarchical construction mechanism is adopted, and the lowest layer is bootfs, followed by rootfs:

Bootfs: file systems used for system booting, including bootloader and kernel, are unmounted after the container is started to save memory resources

Rootfs: located on top of bootfs and represented as the root file system of the docker container:

In traditional mode, when the system starts up, the kernel mounts rootfs in "read-only" mode first, and then mounts it back to read-write mode after the integrity self-test is completed.

In docker, rootfs is mounted from the kernel to "read-only" mode, and then an additional "writable" layer is mounted through the "joint mount" technology.

Start a busybox container and command ls to look inside the container and have a complete file system:

$docker container run-- name shell-it busybox/ # lsbin dev etc home proc root sys tmp usr var/ # exit$ hierarchical construction

Images built in layers:

The image located in the lower layer is the parent image (parent image), and the lowest image is called the base image (base image).

The top layer is the "read-write" layer, and the bottom layer is the "read-only" layer.

As shown in the picture, it is an Apache image. At the bottom is a basic image of Debian, a pure operating system. On top of the system, an emacs is added, which is a code editor. Then an Apache is added. Each software added here is a separate layer.

The bottom bootfs is uninstalled and removed (removed from memory) as soon as the rootfs is booted when the container starts.

For a container, all write operations can only be done at the top read / write layer. If the container is deleted, the top read / write layer will be deleted as well.

Operating system basic image

For the basic image of the Linux operating system, please refer to the following table to select the appropriate basic image:

Busybox: for ad hoc testing

Alpine: mainly for testing, but also for production environments

Centos: mainly used in production environment, supporting CentOS/Red Hat, often used in enterprise applications in pursuit of stability

Ubuntu: mainly used in production environment, often used in artificial intelligence computing and enterprise applications

Debian: mainly used in production environment

Alpine mirroring is recommended because it is tightly controlled and kept to a minimum size (currently smaller than 5MB), but it is still a complete distribution.

The main advantages of alpine are its small size and complete basic functions. It is very convenient for testing, and it can also be used in production. Although this is not recommended, it is mainly due to the lack of debugging tools.

Busybox's image is smaller than alpine's, and it's not a system distribution. The original purpose of this tool was to create a bootable GNU/Linux system on a floppy disk, which can be used as an installation disk and a first aid disk. It is a software that integrates more than 300 of the most commonly used Linux commands and tools. So if you need to start a container and run some system tools and commands, you can use this as the base image.

The other three are commonly used Linux distributions, which are recommended for production systems. A large image is not a problem, because the container is layered, so multiple local images theoretically share the same basic image.

File system

The hierarchical construction and federated mount of a Docker image depend on its proprietary file system.

Aufs

In the early days, this file system was aufs (advanced multi-layered unification filesystem), an advanced multi-tier unified file system.

Overlayfs

Aufs's competitor is that overlayfs,overlayfs has been incorporated into the Linux kernel since version 3.18. Use the docker info command to find the file system that is currently in use:

Storage Driver: overlay2 Backing Filesystem: xfs Supports d_tpe: true Native Overlay Diff: true

Overlay2 is an abstract secondary file system that needs to be built on top of the local file system. The above information shows that the local file system here as the base is xfs.

Other file system

The layered image of docker supports btrfs,devicemapper and vfs in addition to aufs. File systems supported by earlier default:

Ubuntu system, using aufs by default

CentOS system, using devicemapper by default

Device Mapper is a general device mapping mechanism supporting logical volume management in the Linux2.6 kernel. It provides a highly modular kernel architecture for the implementation of block device drivers for storage resource management.

Docker Registry

The most famous Registry is Docker Hub: https://hub.docker.com/

Others have, such as this Quay: https://quay.io/

When you start the container, you will first try to get the relevant image locally. If the local image does not exist, download the image from Registry and save it locally.

A Registry usually consists of two parts:

Repository

Index

Repository (warehouse)

Repository, an image repository consisting of all iterative versions of a particular docker image. There can be more than one Repository in a Registry. Each repository can contain multiple Tag (tags), and each tag corresponds to a mirror image.

Repository can be divided into top-level warehouse and user warehouse, and the user warehouse name format is "user name / warehouse name". Use the docker search command to take a look:

Docker search-- limit 3 nginxNAME DESCRIPTION STARS OFFICIAL AUTOMATEDnginx Official build of Nginx. 11704 [OK] jwilder/nginx-proxy Automated Nginx reverse proxy for docker con... 1628 [OK] bitnami/nginx Bitnami nginx Docker Image 69 [OK] $

Three are shown here, the first of which is a top-level warehouse without a user name. Behind this is the user warehouse, where you can see the user names to which they belong.

Index

The role of Idxex:

Maintain user accounts, image verification, and public namespace information

It is equivalent to providing a retrieval interface for Registry to complete the user authentication function.

Cloud origin

This is just a simple mention of this concept, mainly about the program configuration file.

One problem with the use of mirrors is the configuration information used inside the images. Configuration information can be injected directly into the image, but this will generate many different versions of the image for different configurations.

Cloud Native is an application that is designed to run in a cloud computing environment and can solve the problem of information in different configurations.

Take Nginx as an example, traditional development programs that run on servers use configuration files to manage configurations. If it is hosted and run on the container cloud, there will be a lot of inconvenience, and the biggest problem is to modify the configuration file.

Programs that are developed natively in the cloud will use interfaces that are convenient for cloud computing scenarios to provide configuration logic. When it comes to the container, it is equivalent to adding a shell to the application, and then it is not convenient to manipulate the data inside. One approach is to pass configuration information by passing environment variables to the container, while the configuration can be automatically injected into the configuration from the environment variable load.

A large number of cloud native configurations can be obtained directly through environment variables.

Make an image based on the container

Using the command docker commint creates the top writeable layer of the container as a separate mirror layer, generating a new image.

Other ways to make mirrors, and the most important way to make mirrors, is to make mirrors based on Dockerfile. This part of the content is very important and many, need to write a separate article.

Modify the contents of the basic image

Based on busybox, add a httpd service.

$docker run-name httpd-it busybox/ # echo "Hello world. Busybox httpd." > / var/www/index.html/ # cat / var/www/index.html Hello world. Busybox httpd./ #

Make changes inside the container

Now that you have created a html file, it will not be available the next time docker starts the container. What needs to be done now is to save the previous changes.

Save the changes to the container and generate a new image

To keep the container running, open another session and execute the commit command:

$docker commit-p httpdsha256:5bd093efd84001a2f7412292431ead5c760acef8f4e3a2298abf9f28aa7b3cd7 $

The-p parameter here pauses the container to prevent operations that may change the contents of the container during image production. It is recommended to add the-p parameter.

Modify image label

Check the image information. The newly created image information is as follows:

$docker image lsREPOSITORY TAG IMAGE ID CREATED SIZE 5bd093efd840 2 minutes ago 1.22MBbusybox latest e4db68de4ff2 4 weeks ago 1.22MB $

Because the warehouse name and label signature are not specified at the time of production, it is all empty. These two fields are allowed to be empty, so the image can only be indicated by the ID of the image.

Add tag information

For convenience in quoting, add the warehouse name and label signature:

$docker image tag 5bd093efd840 myimg/httpd:v1 $docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEmyimg/httpd v1 5bd093efd840 9 minutes ago 1.22MBbusybox latest e4db68de4ff2 4 weeks ago 1.22MB$

An image can have multiple tags, plus a latest tag:

$docker image tag myimg/httpd:v1 myimg/httpd:latest$ docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEmyimg/httpd latest 5bd093efd840 11 minutes ago 1.22MBmyimg/httpd v1 5bd093efd840 11 minutes ago 1.22MBbusybox latest e4db68de4ff2 4 weeks ago 1.22MB$

You can confirm here that the ID of the image of the two tags is the same, so this is an image, but two tags have been added to the image.

Delete label

There is no command to delete a tag. To delete a tag, just use the command to delete the image:

$docker image tag myimg/httpd:v1 myimg/httpd:tmp1 $docker image rm myimg/httpd:tmp1Untagged: myimg/httpd:tmp1 $

Another tag is added here, and then the tag is deleted, and the result of the command execution shows that the specified tag is just removed. So there are multiple tags on the same image, and only one copy is stored locally. Delete the image of a tag, just remove the tag from the list of mirror tags. After that, a mirror image is actually deleted when the last tag is deleted.

Modify the default startup command for the image

Use the inspect command to view the underlying information of the docker object. What you are looking for here is the default startup command in the underlying information of the image, as shown below:

$docker image inspect busybox "Cmd": ["sh"], $

The command that runs at startup is sh, which is also the command that the busybox image runs when it starts by default, because this is not specified when making a new image.

Remake a new version of the image, this time specifying the command to run by default at startup:

$docker commit-c 'CMD ["httpd", "- f", "- h", "/ var/www/"]'-p httpd myimg/httpd:v2sha256:850da6d87c65a2c6084cdbfcabbeeeaf6c13ddbb9fbb984fec5ca05cab38830d$

The parameter-c is not used to specify the command, but to specify all the changes to be made, of course, as long as the startup command is modified.

Httpd command parameter description

For the startup command httpd-f-h / var/www/, you can see the parameter description of httpd. The-f indicates that it runs in the foreground as a daemon, and the-h parameter specifies the path to the home page.

Start the verification image

Start the image with parameters:

$docker container run-- name httpd2-d-p 8002 myimg/httpd:v280522bb422e16dae4ea052bcb36e51203f4d7b023fefdf3de4114598b3e95b29 80 myimg/httpd:v280522bb422e16dae4ea052bcb36e51203f4d7b023fefdf3de4114598b3e95b29

After the mirror starts, you can use the browser to access the IP address of the host and the mapped port number to open this page, such as: http://192.168.24.170:8002/

Mirror Import and Export

You can package the image on the host that already has the image, copy the packaged file to another host and import the image, and then transfer the image between hosts. This method does not need to connect to the image repository.

Export Mirror

To export an image is to export the image to a tar package:

$docker image save-o httpd.tar myimg/httpd

This command omits the Tag tag, which packages the entire repository, that is, all versions.

The save command has only one argument,-o, which specifies the location of the export. If there is no-o parameter, it is output to the terminal. However, it cannot be output directly to the terminal, which is to save the content through output redirection. So the effect of this command is the same:

$docker image save myimg/httpd > httpd2.tar

You can add the tag information to specify the image of the Tag corresponding to the package. You can pass more than one parameter for an image, and package multiple images:

$docker image save-o httpd3.tar myimg/httpd:v1 myimg/httpd:v2

Export to tar Fil

The imported file name can be specified at will, but it is recommended that you use the tar extension. This is indeed a tar package. Use the tar command to view a list of files inside the tar package:

$tar-tvf httpd.tar-rw-r--r-- 0amp 0 1491 2019-07-18 15:10 25079c1e47bf896a028e55d715dc06e251f3efe53ca655ad63f6085ce6a465a8.json Movie Rwkub Rwkashi Rwkashi Rwkuf-02019-07-18 15:05 7f36d8e3488df22381081d68c7f2215750167250114abd0b2f31d99e81a7bfd7.jsondrwxr-xr-x 0gama 02019-07-18 15:05 957ac2430f81aaa485efe07e872a460156d73e48f53f31a9743ed0df044d7MARWLYR Meltel-0803 2019-07-18 15:05 957ac2430f81aaa485efe07e872a460156d73e48f53f31a9743ed0d5f0fa44d7/ VERSION-rw-r--r-- 0 1081 2019-07-18 15:05 957ac2430f81aaa485efe07e872a460156d73e48f53f31a9743ed0d5f0fa44d7 Movie RW Murray rwmurf Murray rwmurf-0Yuk 4608 2019-07-18 15:05 957ac2430f81aaa485efe07e872a460156d73e48f53f31a9743ed0d5f0fa44d7/layer.tardrwxr-xr-x 0GPU 0 2019-07-18 15:10 a24e93a2c2b0548055a10d18f0c88dc138c57ee6f13020538bf80da2bfefc59f the RWL Rafe-0803 2019-07-18 15:10 a24e93a2c2b0548055a10d18f088dc138c57f130538b802bf59f55a10d18f0c57f538b80bfef59f10d18f0c88dc57f2038bf80da2bfefc59f10d18f0c88dc138c576f13020538bf80da2bfefc59f Rafael Rafael-0 2019-07-18 15:10 a24e93a2c2b0548055a10d18f0c88dc138c57ee6f13020538bf80da2bfefc59fMot2bfefc59fMot2bfefc59fMotWhen Muffin rwmurf-0 4608 2019-07-18 15:10 a24e93a2c2b0548055a10d18f0c88dc138c57ee6f13020538bf80da2bfefc59f/layer.tardrwxr-xr-x 0 a24e93a2c2b0548055a10d18f0c88dc138c57ee6f13020538bf80da2bfefc59f/layer.tardrwxr-xr-x 02019-07-18 15:05 dea411b43d1b59da62f22c37c8507e7757c2dd9a5467a523f92e612d88e83ae8/-rw-r--r-- 0Three 2019-07-18 15:05 dea411b43d1b59da62f22c37c8507e7757c2dd9a5467a523f92e612d88e83ae8/VERSION-rw-r--r 0406 2019-07-18 15:05 dea411b43d1b59da62f22c37c8507e7757c2dd9a5467a523f92e612d88e83ae8/json-rw-r--r-- 0 1441280 2019-07-18 15:05 dea411b43d1b59da62f22c37c8507e7757c2dd9a5467a523f92e612d88e83ae8/layer.tar-rw-r--r-- 0579 1970-01-01 08:00 manifest.json-rw-r--r-- 0238 1970-01-01 08:00 repositories$

As you can see from IMAGE ID, the two versions are indeed mirrored to the package.

Export and compress

Complete the export and compress it using the following methods:

$docker save myimage:latest | gzip > myimage_latest.tar.gz import image

Use the load command to easily import images:

$docker image load-I httpd3.tar 6194458b07fc: Loading layer [= = >] 1.441MB/1.441MBdd0dd7cb79c9: Loading layer [= = >] 4.608kB/4.608kBLoaded image: myimg/httpd:latestLoaded image: myimg/httpd:v1698704828883: Loading layer [= = >] 4.608kB/4.608kBLoaded image: myimg/httpd:v2 $docker image lsREPOSITORY TAG IMAGE ID CREATED SIZEmyimg/httpd v2 25079c1e47bf 30 minutes ago 1.22MBmyimg/httpd latest 7f36d8e3488d 35 minutes ago 1.22MBmyimg/httpd v1 7f36d8e3488d 35 minutes ago 1.22MB$

The last file packaged above was httpd3.tar. The package command was executed with the v1 and v2 tags specified, but not the latest tag. But you can see all three tags here. So a tag is just one tag, and a single image can have multiple tags, but the images of different tags are the same image.

If the-I parameter is not used, it is imported from standard output by default, which is the same with the following methods:

$docker image load < httpd3.tar

Import a compressed file

Load an image or repository from a tar archive (even if compressed with gzip, bzip2, or xz) from a file or STDIN. It restores both images and tags.

Import images can be imported from tar files or directly from several compressed files. The operation is all the same, and the program will recognize it. It should be through the suffix of the file name.

The above content is how to analyze Docker image management. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.