Docker学习笔记（二）

Docker学习笔记（二）

暑期加入了沃天宇老师的实验室进行暑期的实习。在正式开始工作之前，师兄先让我了解一下技术栈，需要了解的有docker、k8s、springboot、springcloud。

谨以一系列博客记录一下自己学习的笔记。更多内容见Github

2021/7/6

• 上一篇 Docker学习笔记（一）：https://www.cnblogs.com/SnowPhoenix/p/14974321.html

容器的文件系统

容器间的文件是相互隔离的，即使它们都使用同一个镜像。

实验

docker run -d ubuntu bash -c "shuf -i 1-10000 -n 1 -o /data.txt && tail -f /dev/null"

• -d选项表示detached模式，这个前面已经了解了；
• ubuntu应当是指定使用的镜像，因为输入指令之后我们就可以看到docker从中央仓库pull下来了ubuntu的镜像；
• bash我猜测是指定了运行的程序，bash体验确实优于sh；
• -c 后面指定了一个运行的命令，我猜测c是command的缩写，而后面的语句的意思应该是向/data.txt写入一个1~10000的随机数，然后不断向控制台输出/dev/null中新加入的内容；

通过docker ps拿到刚刚启动的容器的id后，我们通过以下指令可以拿到/data.txt中的随机数：

docker exec <CONTAINER> cat /data.txt

之后，我们再启动一个镜像：

docker run -it ubuntu ls /

• -it应当是一个区别于-d的选项，我们看到这条语句运行完成之后直接在console显示了结果；
• ls /应当是要在这个容器内执行的程序，因为我们可以看到这个语句完成之后打印了一个目录的列表；

这里我们也能看到在上一个run指令中，-c其实是传给bash的参数，而不是docker run的参数。

从这里的结果可以看出，新创建的镜像中没有第一个镜像中的/data.txt，这就证明了这两个使用相同镜像的容器中的文件系统是相互隔离的，它们互相无法访问到彼此的文件。

实验后的小探究

实验结束后，使用docker ps指令可以发现，第一个启动的容器并没有停止，而第二个容器已经停止了，通过docker ps -a可以看到被停止的容器。

仔细观察两次启动容器的区别，可以发现，第一个容器中，特地使用了tail -f，这个指令会进入一个有死循环的程序，只要不主动退出，就不会完成，而第二个容器中使用的是ls，当打印完目录的内容后，就结束了，此时容器就停止了。

为了探究-it的作用，先通过docker run --help得知，-i的作用是保持stdin为开启状态，即使没有attached，而-t是打开一个虚拟终端，二者通常一起使用。

直接运行

docker run -it ubuntu
docker run -it ubuntu bash

二者似乎会产生相同的效果，我们可以看到如下效果：

我们进入了一个终端，并且打开另一个Powershell终端输入docker ps，可以发现这个容器并没有停止，而是处于运行的状态，并且这个bash前面root@xxxxxx中的xxxxx就是这个容器的ID。

此外，我们还可以发现，就算启动时，我们没有指定bash这个参数，docker ps中的COMMAND一列，还是会显示为bash，看来bash很可能是一个默认的行为，猜测可能跟ubuntu镜像的Dockerfile相关。

我还对docker exec指令试验了-it的效果：

docker exec -it <CONTAINER> bash

这里的bash就不能省略了，否则会报错。我输入了第一个容器的id，通过cat /data.txt仍旧可以拿出之前获得的那个随机数。而如果输入了一个已经停止的容器的id，就会报错，exec指令只能用于访问一个正在运行的指令，而不能访问一个已经停止的容器。

从上述的探究来看，一个容器如果其指令全部执行完毕，就会停止，此时无法在通过docker exec来进入容器进行操作；倘若我们想要通过docker exec -it进入容器操作，我们就需要让容器进入一个不会退出的程序来保活。不过可能有一些指令能够让一个已经停止的容器恢复运行。

实验结束之后，我们需要清理一下这些容器：

docker rm -f $(docker ps -aq)

这个是搜索来的指令，其中docker rm -f我们已经熟悉了，它表示删除一个容器，如果容器正在运行，就会停止并删除，而后面的部分docker ps -aq中，-q的作用是只保留id，这样它的结果就是一串CONTAINER_ID，作为docker rm -f的参数。

Volumes

我也不知道该怎么翻译这个词，Edge自带的翻译将它翻译成了“卷”，我就姑且先叫它数据卷吧。

它的出现，就是为了解决容器间/容器-宿主机间的数据共享问题。通过容器内到宿主机的文件系统的映射，来实现数据的共享/持久化。

通过如下命令建立一个名为todo-db的Volume：

docker volume create todo-db

然后再次启动我们之前构建好的demo的镜像：

docker run -dp 3000:3000 -v todo-db:/etc/todos getting-started

然后再在3001启动一遍：

docker run -dp 3001:3000 -v todo-db:/etc/todos getting-started

用浏览器访问3000和3001，并且在3000添加新的todo，在3001刷新一下就能发现数据同步过来了：

此后，我们停止并删除这两个容器之后，再在3002启动一个新的容器，发现这个todo还是存在的：

这里发生了什么事呢？

肯定是和Volume的使用相关，我们注意到我们在启动容器的指令中添加了参数-v todo-db:/etc/todos，该指令将容器中的/etc/todos/文件夹绑定到我们刚刚创建的名为todo-db的Volume中了，而/etc/todos/文件夹下正是我们启动的这个项目的sqlite数据库存放.db文件的目录，参见docker\gov-sample-app\src\persistence\sqlite.js第3行：

const location = process.env.SQLITE_DB_LOCATION || '/etc/todos/todo.db';

而通过Volume，我们将sqlite的文件映射到了宿主机上，这样不同容器间就可以共享这个sqlite文件，并且容器被销毁后sqlite文件不会随之被销毁。

至于具体被保存在了宿主机的哪里，通过docker volume inspect <VOLUME NAME>来查看。注意Windows和mac中，docker都是运行在虚拟机上的，所以这里得到的并不是系统路径，而是虚拟机中的路径。

这里我使用阿里云的服务器进行实验：（删去了一些个人信息）

snowphoenix@xxx:~$ sudo docker run -it -v test:/tmp/test ubuntu bash
Unable to find image 'ubuntu:latest' locally
latest: Pulling from library/ubuntu
c549ccf8d472: Pull complete 
Digest: sha256:aba80b77e27148d99c034a987e7da3a287ed455390352663418c0f2ed40417fe
Status: Downloaded newer image for ubuntu:latest
root@f1fd90b64c48:/# ls
bin   dev  home  lib32  libx32  mnt  proc  run   srv  tmp  var
boot  etc  lib   lib64  media   opt  root  sbin  sys  usr
root@f1fd90b64c48:/# cd tmp
root@f1fd90b64c48:/tmp# ls
test
root@f1fd90b64c48:/tmp# cd test/
root@f1fd90b64c48:/tmp/test# ls
root@f1fd90b64c48:/tmp/test# echo "123" >num
root@f1fd90b64c48:/tmp/test# cat num
123
root@f1fd90b64c48:/tmp/test# exit
exit
snowphoenix@xxx:~$ sudo docker volume inspect test
[
    {
        "CreatedAt": "2021-07-06T18:40:16+08:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/test/_data",
        "Name": "test",
        "Options": {},
        "Scope": "local"
    }
]
snowphoenix@xxx:~$ sudo cat /var/lib/docker/volumes/test/_data/num
123

我先启动了一个ubuntu镜像，并将/tmp/test目录映射到名为test的volume中，在容器中，我们发现/tmp/test这个目录已经被创建好了，我在这个目录下创建一个num文件并写入123。退出容器之后，通过docker volume inspect test查看到了Volume的实际路径，然后打开了该路径下的num文件，获得了在容器中写入的123。

绑定挂载（Bind mounts）

不同于Volume，通过这种方式可以指定宿主机与容器映射的文件夹。方法就是在-v选项后面，使用宿主机的文件夹路径代替Volume名。

这种方法可以用于开发时的热更新，即在容器内运行，在容器外进行开发，并且利用开发工具让容器内运行的程序随时进行更新。

在命令行切换到gov-sample-app文件夹，然后输入以下命令运行之前的getting-started：

docker run -dp 3000:3000 -w /app -v "$(pwd):/app" node:12-alpine sh -c "yarn install && yarn run dev"

• -w指定了工作目录；
• -v指定了映射关系，其中用$(pwd)来表示宿主机的当前工作目录，即gov-sample-app文件夹；
• node:12-alpine是使用的镜像名，注意这里没有使用我们构建的getting-started镜像；
• 最后是镜像中运行的指令，这里以热更新的模式启动这个项目。值得注意的是Apline并没有bash，所以只能用sh；

当我们在Windows上执行该命令时，会收到一个警告，因为我们将一个Windows下的文件夹映射到了一个docker容器中，这将导致性能较差。

此时访问localhost:3000并没有显示，通过查看以下命令查看运行情况：

docker container logs <CONTAINER>

这个命令可以查看容器中stdout的输出。我们可以发现这个时候正在执行yarn install，而我们之前先构建镜像再直接运行的是偶，是很快就能访问localhost:3000的，我们看Dockerfile，发现是在Dockerfile的RUN语句中执行的，那么就说明RUN语句中的部分是在构建镜像的时候执行的，那我们可以合理猜测CMD中的内容应该是在docker run的时候才执行。

等了一阵子，终于结束了构建，可以在localhost:3000访问到我们的程序了：

同时，我们可以发现gov-sample-app文件夹下出现了mode_modules文件夹，这个是构建node.js项目产生的，文件数目极其之多，得赶紧加一个gitignore。

然后对src/static/js/app.js第109行进行修改：

 -                         {submitting ? 'Adding...' : 'Add Item'}
 +                         {submitting ? 'Adding...' : 'Add'}

保存，然后刷新浏览器：

我们的更改已经生效了。通过bind-mount方式，我们在本地的更改能够影响到容器内的文件。

多容器协作

我们使用容器的时候，应当尽量地解耦，多个应用（如数据库）最好能够运行在不同的容器中，这样能够更加灵活地进行部署和使用。

而当我们将不同应用部署于不同容器后，我们怎样让它们进行协作呢？答案是网络。这一点和现在分布式的微服务架构的思想有些类似。

启动MySQL

首先，创建一个网络network，这个命令与创建一个volume很类似：

docker network create todo-app

然后，启动一个MySQL镜像的容器：

docker run -d --network todo-app --network-alias mysql -v todo-mysql-data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=secret -e MYSQL_DATABASE=todos mysql:5.7

• -d表示detached模式运行，老朋友了；
• --network表示这个容器需要连接到我们刚创建的todo-app网络；
• --network-alias表示为这个容器所在的ID起了一个“域名”，在同一个network的其它容器可以通过DNS来找到这个容器；
• -v表示进行文件系统的volume映射，注意这里我们使用了一个名为todo-mysql-data的volume，但我们从未创建过它，事实上，docker将为我们自动创建；
• -e用来添加环境变量；
• mysql:5.7使我们使用的镜像，我们一般会省略冒号后面的标签，此时缺省的标签为latest，这里我们指定了这个标签；

通过exec我们可以进入容器查看状态：

docker exec -it <CONTAINER> mysql -u root -p

其中密码是之前通过环境变量指定的secret，通过show databases命令可以看到MySQL中现在有了我们通过环境变量指定的todos数据库。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| todos              |
+--------------------+
5 rows in set (0.01 sec)

启动netshoot

netshoot是一个docker/k8s常用的debug工具，用于定位和发现问题的工具箱。详见：https://github.com/nicolaka/netshoot。

docker run -it --network todo-app nicolaka/netshoot

以交互模式启动netshoot并且将其添加到todo-app中，即和MySQL位于同一网络中。

这里我们使用netshoot的dig命令，这是一个DNS工具，我们获得了如下结果：

06dfbe6b6d3e  ~  dig mysql

; <<>> DiG 9.16.16 <<>> mysql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20457
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mysql.                         IN      A

;; ANSWER SECTION:
mysql.                  600     IN      A       172.18.0.2

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11)
;; WHEN: Tue Jul 06 14:11:27 UTC 2021
;; MSG SIZE  rcvd: 44

可见通过我们在启动MySQL时指定的--network-alias，成功地添加了一个DNS信息，使得通过mysql域名可以寻找到MySQL容器中的数据库服务。

利用MySQL作为数据库启动原来的项目

docker run -dp 3000:3000 `
   -w /app -v "$(pwd):/app" `
   --network todo-app `
   -e MYSQL_HOST=mysql `
   -e MYSQL_USER=root `
   -e MYSQL_PASSWORD=secret `
   -e MYSQL_DB=todos `
   node:12-alpine `
   sh -c "yarn install && yarn run dev"

我们这里定义了很多环境变量，通过这些环境变量，我们可以将数据库从sqlite切换到MySQL。

我们可以通过docker container logs来查看stdout，可以看到其中包含一下输出：

Waiting for mysql:3306.
Connected!
Connected to mysql db at host mysql

这说明通过我们设定的MySQL的域名mysql连接到了之前的MySQL的容器。

访问localhost:3000，添加一个TODO：

然后通过docker exec进入到MySQL的容器中，可以看到我们的这条信息成功添加到了数据库：

mysql> select * from todo_items;
+--------------------------------------+--------+-----------+
| id                                   | name   | completed |
+--------------------------------------+--------+-----------+
| ffb87e95-b514-4c33-937c-caee9bcbb5a5 | hellow |         0 |
+--------------------------------------+--------+-----------+
1 row in set (0.00 sec)

Docker Compose

Docker Compose是一个多容器docker项目的管理工具，通过yml文件来定义每一个容器（服务启动的参数）。

在gov-sample-app文件夹下创建docker-compose.yml，然后写上如下内容：

version: "3.7"

services:
  app:
    image: node:12-alpine
    command: sh -c "yarn install && yarn run dev"
    ports:
      - 3000:3000
    working_dir: /app
    volumes:
      - ./:/app
    environment:
      MYSQL_HOST: mysql
      MYSQL_USER: root
      MYSQL_PASSWORD: secret
      MYSQL_DB: todos

  mysql:
    image: mysql:5.7
    volumes:
      - todo-mysql-data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: todos

volumes:
  todo-mysql-data:

再在gov-sample-app文件夹下输入:

docker-compose up -d

即可实现启动一个MySQL服务再使用这个数据库启动我们的node.js服务程序。

相比于在命令行手动启动这两个容器，这样的方式无疑更加方便，就如同手动调用gcc和编写Makefile使用make工具来构建一样。

比较有意思的是，我们这次并没有让两个容器添加到同一个network中，它们还是实现了通讯，并且我们没有定义别名的情况下，node.js仍旧通过mysql这个名字路由到了MySQL的容器中。

通过docker network ls我们可以发现有一个名为gov-sample-app_default的network被创建了。那么我们可以合理猜测，使用DockerCompose可以使得不同的服务自动添加到同一个defualt网络下，并且使用服务的名字来作为网络中的别名。

此外，我在实验的时候，发现docker compose也是可以的（中间少了一个连接符），并且在PowerShell下显示效果更好。

最后，输入docker compose down即可关闭所有容器。

值得注意的是，通过DockerCompose创建的容器、Volume、network的名字都带有工程名作为前缀，也就是说即使在docker-compose.yml中指定了volumes为todo-mysql-data，实际上使用的却是gov-sample-app_todo-mysql-data。

并且docker compsoe down默认是停止并删除所有容器、删除network（default被删除了，不知道其它的会不会被删除），但是不删除volume，除非带上--volumes选项。

镜像构建的最佳实现

这一部分来自官网。

镜像安全扫描

docker scan <IMAGE>

该命令使用Snyk对镜像进行扫描，并给出一些建议和提示。

镜像层与缓存

通过以下命令我们可以看到镜像的每一次更改：

docker image history getting-started

IMAGE          CREATED          CREATED BY                                      SIZE      COMMENT
d46ea4c442cd   13 seconds ago   CMD ["/bin/sh" "-c" "node src/index.js"]        0B        buildkit.dockerfile.v0
<missing>      13 seconds ago   RUN yarn install --production # buildkit        83.2MB    buildkit.dockerfile.v0
<missing>      37 seconds ago   COPY . . # buildkit                             58.6MB    buildkit.dockerfile.v0
<missing>      28 hours ago     WORKDIR /app                                    0B        buildkit.dockerfile.v0
<missing>      28 hours ago     RUN /bin/sh -c apk add --no-cache python g++…   205MB     buildkit.dockerfile.v0
<missing>      28 hours ago     RUN /bin/sh -c sed -i 's/dl-cdn.alpinelinux.…   93B       buildkit.dockerfile.v0
<missing>      2 months ago     /bin/sh -c #(nop)  CMD ["node"]                 0B
<missing>      2 months ago     /bin/sh -c #(nop)  ENTRYPOINT ["docker-entry…   0B        
<missing>      2 months ago     /bin/sh -c #(nop) COPY file:238737301d473041…   116B
<missing>      2 months ago     /bin/sh -c apk add --no-cache --virtual .bui…   7.62MB
<missing>      2 months ago     /bin/sh -c #(nop)  ENV YARN_VERSION=1.22.5      0B
<missing>      2 months ago     /bin/sh -c addgroup -g 1000 node     && addu…   75.7MB
<missing>      2 months ago     /bin/sh -c #(nop)  ENV NODE_VERSION=12.22.1     0B
<missing>      2 months ago     /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B
<missing>      2 months ago     /bin/sh -c #(nop) ADD file:282b9d56236cae296…   5.62MB

可以看到，大部分我们在Dockerfile中写下的命令，都对应着一次修改。而事实上，每一次修改，Docker都会创建一个新的层（Layer），这也能解释为什么我们之前在第二次docker build的时候，有些步骤没有实际执行，因为Docker为其建立了层，只要层的内容没有更改，就无须重新执行，只需要从以前的层那里开始构建即可。

在这里，官方文档也给出了Dockerfile中COPY的作用：将宿主机中的文件拷贝至镜像中。COPY本身是无法被cache的，但是，如果COPY结束之后，镜像中的内容跟上一次是一样的，那么后面的几步仍旧可以使用之前的镜像层。

这样，就有了最大化利用cache的方法：每次将构建的最小单元拷贝至镜像中，然后进行构建。比如先拷贝项目的依赖的清单，然后恢复项目依赖，然后再拷贝项目本体，然后构建项目，这样如果项目依赖的清单没有改动，则无需再次恢复项目依赖，事实上恢复项目依赖往往占据了大量构建镜像的时间。

在gov-sample-app项目中，我们就可以先拷贝package.json和yarn.lock，然后进行yarn install，然后再拷贝整个项目。改造后如下（这里也注释掉了无用的apk add）：

# syntax=docker/dockerfile:1
FROM node:12-alpine
# RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories 
# RUN apk add --no-cache python g++ make
WORKDIR /app
COPY package.json yarn.lock ./
RUN yarn install --production
COPY . .
CMD node src/index.js

此外，因为我们曾经使用bind-mount直接修改了gov-sample-app文件夹，多了node_modules，我们这里要让docker忽略掉这个文件夹，我们需要像.gitignore那样，在gov-sample-app文件夹中创建.dockerignore文件并写入：

node_modules

此时执行docker build，然后改动一下src/static/index.html（比如加个回车），再执行docker build，

[+] Building 2.1s (12/12) FINISHED
 => [internal] load build definition from Dockerfile                                           0.0s 
 => => transferring dockerfile: 32B                                                            0.0s 
 => [internal] load .dockerignore                                                              0.0s 
 => => transferring context: 34B                                                               0.0s 
 => resolve image config for docker.io/docker/dockerfile:1                                     1.3s 
 => CACHED docker-image://docker.io/docker/dockerfile:1@sha256:e2a8561e419ab1ba6b2fe6cbdf49fd  0.0s 
 => [internal] load metadata for docker.io/library/node:12-alpine                              0.0s 
 => [1/5] FROM docker.io/library/node:12-alpine                                                0.0s 
 => [internal] load build context                                                              0.1s 
 => => transferring context: 3.46kB                                                            0.0s 
 => CACHED [2/5] WORKDIR /app                                                                  0.0s 
 => CACHED [3/5] COPY package.json yarn.lock ./                                                0.0s 
 => CACHED [4/5] RUN yarn install --production                                                 0.0s 
 => [5/5] COPY . .                                                                             0.1s 
 => exporting to image                                                                         0.2s 
 => => exporting layers                                                                        0.1s 
 => => writing image sha256:ecad588cb07eb9a41fdfede453b0ef587b2afc70a40a7344f4f1ab1ad7b71597   0.0s 
 => => naming to docker.io/library/getting-started                                             0.0s 

可以看到除了最后一步，全部使用了Cache。

多个stage

我们在构建的时候和我们部署在生产环境中的时候，往往需要不同的依赖，旧的方式会导致在最后的镜像中保留了构建工具，但事实上，这些构建工具应该像手脚架一样，结束构建就抛弃。

这里就要再一次提到FROM语句，其完整格式为：

FROM <IMAGE> AS <STAGE>

每一个FROM语句是一个stage的开始，只有最后一个stage会被保留在最后的镜像中（可以通过--target参数来指定最后保留在镜像中的stage）。

官方给了两个示例：

• Maven+Tomcat：

# syntax=docker/dockerfile:1
FROM maven AS build
WORKDIR /app
COPY . .
RUN mvn package

FROM tomcat
COPY --from=build /app/target/file.war /usr/local/tomcat/webapps 

• React：

# syntax=docker/dockerfile:1
FROM node:12 AS build
WORKDIR /app
COPY package* yarn.lock ./
RUN yarn install
COPY public ./public
COPY src ./src
RUN yarn run build

FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html

我们看到，在最后的一个stage中，COPY语句采用了--from=build来从其它stage拷贝文件，而不是宿主机。

另一方面，在React这里使用了利用cache的优化操作，可见，即使不在最后的镜像中，应该也可以利用cache。

总结

后面的学习可能还会回头来使用docker，所以当前阶段的学习就先高一段落。

先回顾开头的问题：什么是docker？

用“容器”这个词来形容docker确实十分形象了，在Windows和macOS上运行需要一个Linux的虚拟机，其实从这里我们就可以合理推测出来了——docker应该是共享内核的。所有的镜像使用的应该是宿主机的Linux内核。虚拟机需要将方方面面与宿主机进行隔离，而docker只着重于“表层环境”（shell）的隔离。docker的出现，就是为了方便部署，在不同设备转移的时候携带一定的环境“闭包”，来避免重新安装环境。

总的来说，docker就是一个用来装目标应用程序和其依赖的容器，我们可以方便地整个容器整个容器地移动、管理。

docker最主要的两个操作就是构建和部署。

构建上，需要使用Dockerfile，我们可以控制好COPY的精度来最大化利用镜像的layer机制进行缓存，提高构建的速度。

部署上，我们利用docker push和docker pull来移动镜像，使用DockerCompose来自动化启动多个容器。

此外，有2个重要工具：

1. vloume/bind-mount，用于文件的共享/持久化，前者将文件在宿主机的情况交由docker托管，而后者需要手动管理；
2. network，利用网络，使得不同的容器间、容器与宿主机间进行通信；

这两个工具是容器和外界进行通信的重要方式。

遗留问题

RUN和CMD的区别

参考官方文档：https://docs.docker.com/engine/reference/builder/

RUN是在构建阶段运行的指令，而CMD是运行阶段运行的默认指令。即前者在docker build的时候生效，而后者在docker run的时候生效。

关于CMD，一个Dockerfile只有最后一个CMD会生效，并且docker run指令最后的参数可以覆盖掉它（这可能也是我们在docker run -it ubuntu的时候后面跟不跟bash效果都一样的原因）。

并且还有一个和CMD类似的命令ENTRYPOINT，如果一个镜像指定了ENTRYPOINT，那么CMD的内容（无论是Dockerfile中的CMD还是用户输入的）将作为参数传递给ENTRYPOINT。ENTRYPOINT只能通过--entrypoint在启动时覆盖。

所以ENTRYPOINT有两种用法，一种是将镜像包装成一个应用，这样只需要传递参数，比较方便，一种就是编写一个脚本，这个脚本完成一些需要在运行阶段进行的初始化工作，然后将传入的参数作为命令来执行。

WORKDIR有什么作用

参考官方文档：https://docs.docker.com/engine/reference/builder/#workdir

相当于在容器内执行cd，只不过如果目录不存在，会自动创建。