与Dockerfile的构建过程类似，对compose启动服务过程中的构建也做类似的测试，对其构建过程也能有个比较清晰的了解，新建一个docker-compose.yml：

version: "3"
services:
    casual:
        build: .
        ports:
          - "50808:50808"
在构建前我们试试先用Dockerfile构建：
 
kimono@kimono:~/dockerTest$ docker build -t casual .
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM python:latest
 ---> 2c31ca135cf9
Step 2/3 : ENV PYTHONUNBUFFERED 0
 ---> Running in 94583acf1f9c
Removing intermediate container 94583acf1f9c
 ---> 76bb8b5bf3de
Step 3/3 : RUN mkdir -p /home/coredumped
 ---> Running in b899fa987840
Removing intermediate container b899fa987840
 ---> 96df3fda6c07
Successfully built 96df3fda6c07
Successfully tagged casual:latest
然后在用compose启动服务：
 
kimono@kimono:~/dockerTest$ docker-compose up -d
Building casual
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM python:latest
 ---> 2c31ca135cf9
Step 2/3 : ENV PYTHONUNBUFFERED 0
 ---> Using cache
 ---> 76bb8b5bf3de
Step 3/3 : RUN mkdir -p /home/coredumped
 ---> Using cache
 ---> 96df3fda6c07
Successfully built 96df3fda6c07
Successfully tagged dockertest_casual:latest
WARNING: Image for service casual was built because it did not already exist. To rebuild this image you must use `docker-compose build` or `docker-compose up --build`.
Creating dockertest_casual_1 ... done
可以发现compose确实就是一个集成功能的工具，调用的还是原有docker的api，这里与原有的build过程没有任何区别。
 
看一下容器和镜像：
 
kimono@kimono:~/dockerTest$ docker ps -a
CONTAINER ID   IMAGE                  COMMAND                  CREATED         STATUS                      PORTS     NAMES
e3284ccc5bf5   dockertest_casual      "python3"                2 minutes ago   Exited (0) 2 minutes ago              dockertest_casual_1
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED         SIZE
casual              latest    96df3fda6c07   3 minutes ago   885MB
dockertest_casual   latest    96df3fda6c07   3 minutes ago   885MB
虽然两个库用的都是相同的镜像（ID: 96df3），但compose启动服务还是会新建一个库，然后新建的容器也是用的该库。compose创建的库名会带上文件夹名作为前缀，容器则会用数字作后缀。
 
如果我们再用compose启动一次服务，会直接启动已有的容器。
 
kimono@kimono:~/dockerTest$ docker-compose up -d
Starting dockertest_casual_1 ... done
即使删除容器也不过是重新根据 dockertest_casual 库再创建一次容器：
 
kimono@kimono:~/dockerTest$ docker rm dockertest_casual_1 
dockertest_casual_1
kimono@kimono:~/dockerTest$ docker-compose up -d
Creating dockertest_casual_1 ... done
可以判断这个compose中的casual服务是与 dockertest_casual 库名绑定的。这一点也可以由前面的一句 WARNING: Image for service casual was built because it did not already exist. 佐证。
 
尝试一下之前提到的--build选项，该选项是重新构建的镜像的意思。
 
kimono@kimono:~/dockerTest$ docker-compose up -d --build
Building casual
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM python:latest
 ---> 2c31ca135cf9
Step 2/3 : ENV PYTHONUNBUFFERED 0
 ---> Using cache
 ---> 76bb8b5bf3de
Step 3/3 : RUN mkdir -p /home/coredumped
 ---> Using cache
 ---> 96df3fda6c07
Successfully built 96df3fda6c07
Successfully tagged dockertest_casual:latest
Starting dockertest_casual_1 ... done
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
casual              latest    96df3fda6c07   12 minutes ago   885MB
dockertest_casual   latest    96df3fda6c07   12 minutes ago   885MB
继续验证一下之前关于库名绑定的想法：
 
kimono@kimono:~/dockerTest$ docker rm dockertest_casual_1 
dockertest_casual_1
kimono@kimono:~/dockerTest$ docker rmi dockertest_casual:latest 
Untagged: dockertest_casual:latest
kimono@kimono:~/dockerTest$ docker tag casual:latest dockertest_casual:latest
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
casual              latest    96df3fda6c07   19 minutes ago   885MB
dockertest_casual   latest    96df3fda6c07   19 minutes ago   885MB
kimono@kimono:~/dockerTest$ docker rmi casual:latest 
Untagged: casual:latest
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
dockertest_casual   latest    96df3fda6c07   20 minutes ago   885MB
启动casual服务：
 
kimono@kimono:~/dockerTest$ docker-compose up -d
Creating dockertest_casual_1 ... done
呵，果然。不过还可以再极端一点，删除原有的库，重新构建一个 dockertest_casual 库：
 
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED              SIZE
dockertest_casual   latest    c7c812ca7836   About a minute ago   885MB
构建完毕后修改Dockerfile的内容：
 
FROM python:latest
ENV PYTHONUNBUFFERED 3
RUN mkdir -p /home/core
不加入--build选项启动服务：
 
kimono@kimono:~/dockerTest$ docker-compose up -d
Creating dockertest_casual_1 ... done
看来绑定库名是毫无疑问的事情了，现在加入--build选项：
 
kimono@kimono:~/dockerTest$ docker-compose up -d --build
Building casual
Sending build context to Docker daemon  3.072kB
Step 1/3 : FROM python:latest
 ---> 2c31ca135cf9
Step 2/3 : ENV PYTHONUNBUFFERED 3
 ---> Running in 17f3e839f53a
Removing intermediate container 17f3e839f53a
 ---> ae1917d51d08
Step 3/3 : RUN mkdir -p /home/core
 ---> Running in 15bf5f88fbce
Removing intermediate container 15bf5f88fbce
 ---> 4c59d7c9e9a8
Successfully built 4c59d7c9e9a8
Successfully tagged dockertest_casual:latest
Recreating dockertest_casual_1 ... done
由于重新构建库时每一层镜像都会重新构建，因此会出现跟原来的库很大的不同（毕竟Dockerfile不同了），虽然库名没变，但里面的每一层镜像都发生了改变，甚至是新建的镜像，并将原来的 dockertest_casual_1 容器重新构建。那么原来的那个镜像去哪了？
 
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
dockertest_casual   latest    4c59d7c9e9a8   34 seconds ago   885MB
<none>              <none>    c7c812ca7836   5 minutes ago    885MB
显然，原有的镜像还保留着id，但库名和tag名都被取代了（none）。
 t_casual_1 容器重新构建。那么原来的那个镜像去哪了？
 
kimono@kimono:~/dockerTest$ docker images
REPOSITORY          TAG       IMAGE ID       CREATED          SIZE
dockertest_casual   latest    4c59d7c9e9a8   34 seconds ago   885MB
<none>              <none>    c7c812ca7836   5 minutes ago    885MB
显然，原有的镜像还保留着id，但库名和tag名都被取代了（none）。
                    docker笔记记录在使用docker过程中产生的一些思考和问题。其他资料：基础原理指令doc实例解析关于dockerfile构建镜像的过程在原理里已经提到过镜像是一层层只读层构成的，上层由下层构建，并指向下层。这点在使用Dockerfile的build过程中也可以看出，每一层都有其ID。也可以透过history命令看出。其中最上层就作为库有着自己的名字和tag，当然镜像ID也是有的，这可以通过docker images查看。由于Docker的镜像是分层（Diff层）构建的，因此每一层
最近在做一个比赛，要求使用docker提交，就入门了一下。在入门的过程中，网上关于docker的内容太理论和繁琐，这里给出一个快速上手并使用docker的方法。
1 Dcoker基础
关于docker入门的第一步请参考,下面的两个网址，我就不重复造轮子了，看的很快：
Docker 教程
https://yeasy.gitbooks.io/docker_practice/content/i...
Untagged: ubuntu:14.04
Deleted: sha256:a8e78858b03ba02c3df71d555f90057f890495aabc86e7a39396c68c87ed5ff2
当我们在docker中执行docker images命令查看到一些不想使用的镜像或容器时，会执行docker rmi -f xxx来对相应的目标进行删除操作，但相应的命令执行完成后会出现上面的两种情况，一种是删除成功，另一种则只是将镜像对应的标签解除了
				
故障描述[root@entel1 ~]# docker rmi entel_zmc_images:zmc_base 
Untagged: entel_zmc_images:zmc_base操作步骤先移除掉exited状态的容器 ,然后删除dangling 状态的镜像docker rm $(docker ps -q -f status=exited)
docker rmi $(docker image
Cappuccinooos-MacBook-Pro:.docker Cappuccinooo$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
runoob/centos       6.7                 4994f...
				
背景测试环境和生产环境 部署了不同的registry服务，通过cli 操作过生产环境或测试环境push／pull  image功能。本地虚拟机，docker image 残留了很多image ，现在想删除掉，发现有一个imageid（e9d3f7300f03）无法删除。
  原因：docker rmi 只能删除tag ，多处引用将无法删除
测试环境export QCOSINDEXHOST=https
				
### 回答1：
我可以回答这个问题。Docker 是一种容器化技术，可以将应用程序及其依赖项打包成一个可移植的容器，方便在不同的环境中部署和运行。构建 Docker 镜像可以使用 Dockerfile 文件来定义镜像的构建过程，推送镜像可以使用 Docker Hub 或其他镜像仓库来存储和分享镜像。  
### 回答2：
Docker是一种开源的容器化平台，能够帮助开发人员和运维人员更高效地构建、打包、分发和运行应用程序。Docker的核心概念是镜像（Image）和容器（Container）。
首先，构建镜像是指将一个应用程序的代码、依赖项以及配置文件等打包成一个可执行的镜像文件。在构建镜像之前，我们需要编写一个Dockerfile，其中包含了构建镜像所需的步骤和指令。Dockerfile可以指定基础镜像、安装软件、配置环境变量等内容。通过执行docker build命令，Docker会根据Dockerfile的指令来逐步构建镜像，并生成一个唯一的镜像标识符。
接下来，推送镜像是将构建好的镜像上传到Docker镜像仓库中，以便其他人或其他机器可以下载和使用这个镜像。Docker镜像仓库是一个集中存储和管理镜像的地方，可以方便地共享和分发镜像。推送镜像之前，我们需要先登录到镜像仓库，然后使用docker push命令将本地镜像推送到指定的仓库地址和版本号。
通过Docker构建镜像并推送到镜像仓库，可以带来一些好处。首先，镜像可以快速部署和启动，减少了应用程序的依赖和配置问题。其次，镜像具有良好的可重复性，可以在不同的环境中使用相同的镜像来保持一致性。此外，镜像可以方便地进行版本控制和更新，而且可以在不同的主机上快速部署相同的应用程序。
总体而言，Docker构建镜像和推送镜像是Docker平台的核心功能之一，可以帮助开发人员和运维人员更加高效地管理和分发应用程序。通过合理地使用Docker构建和推送镜像，可以提高开发效率、降低部署成本，并且可以方便地进行版本控制和更新。