首页 > 资讯 > 宏观 > 正文

5 个技巧,让你的 Dockerfile 像个大师! 天天讯息

2023-06-27 20:44:11来源:程序员鱼皮  

今天给朋友们分享的是我们的嘉宾- 前端大佬神光的关于 Dockerfile 使用技巧的文章,希望能对大家有所帮助。

以下是大佬原文:


Docker 是一种容器技术,它可以在操作系统上创建多个相互隔离的容器。容器内独立安装软件、运行服务。


(资料图片)

但是,这个容器和宿主机还是有关联的,比如可以把宿主机的端口映射到容器内的端口、宿主机某个目录挂载到容器内的目录。

比如映射了 3000 端口,那容器内 3000 端口的服务,就可以在宿主机的 3000 端口访问了。

比如挂载了 /aaa 到容器的 /bbb/ccc,那容器内读写 /bbb/ccc 目录的时候,改的就是宿主机的 /aaa 目录,反过来,改宿主机 /aaa 目录,容器内的 /bbb/ccc 也会改,这俩同一个。

这分别叫做端口映射、数据卷(volume)挂载。

这个容器是通过镜像起来的,通过 docker run image-name。

比如:

dockerrun-p3000:3000-v/aaa:/bbb/ccc--namexxx-containerxxx-image

通过 xxx-image 镜像跑起来一个叫做 xxx-container 的容器。

-p 指定端口映射,映射宿主机的 3000 到容器的 3000 端口。

-v 指定数据卷挂载,挂载宿主机的 /aaa 到容器的 /bbb/ccc 目录。

这个镜像是通过 Dockerfile 经过 build 产生的。

也就是这样的流程:

一般在项目里维护 Dockerfile ,然后执行 docker build 构建出镜像、push 到镜像仓库,部署的时候 pull 下来用 docker run 跑起来。

基本 CI/CD 也是这样的流程:

CI 的时候 git clone 项目,根据 dockerfile 构建出镜像,打上 tag,push 到仓库。

CD 的时候把打 tag 的镜像下下来,docker run 跑起来。

这个 Dockerfile 是在项目里维护的,虽然 CI/CD 流程不用自己搞,但是 Dockefile 还是要开发者自己写的。

比如我创建一个 nest 项目:

npxnestnewdockerfile-test-pnpm

然后执行 npm run build,之后把它跑起来:

npmrunbuildnode./dist/

这时候访问 http://localhost:3000 可以看到 hello world,说明服务跑成功了:

那如何通过 Docker 部署这个服务呢?

首先,如果你没安装 docker,可以从 下载 docker desktop,它自带了 docker 命令:

跑起来可以看到本地的所有 docker 容器和镜像:

命令行也是可用的:

然后我们来写下 Dockerfile:

FROMnode:18WORKDIR/*.:///RUNnpminstallCOPY..RUNnpmrunbuildEXPOSE3000CMD["node","./dist/"]

FROM node:18 是继承 node:18 基础镜像。

WORKDIR /app 是指定当前目录为 /app

COPY 复制宿主机的 和 lock 文件到容器的当前目录,也就是 /app 下

RUN 是执行命令,这里执行了 npm install。

然后再复制其余的文件到容器内。

EXPOSE 指定容器需要暴露的端口是 3000。

CMD 指定容器跑起来时执行的命令是 node ./dist/。

然后通过 docker build 把它构建成镜像:

dockerbuild-tdockerfile-test:first.

-t 是指定名字和标签,这里镜像名为 dockerfile-test 标签为 first。

然后在 docker desktop 的 images 里就可以看到这个镜像了:

就是现在镜像稍微大了点,有 G。

我们先跑起来看看:

docker run -d -p 2333:3000 --name first-container dockerfile-test:first

-d 是后台运行。

-p 指定端口映射,映射宿主机的 2333 端口到容器的 3000 端口。

--name 指定容器名

然后就可以看到容器部分有了这个容器了:

浏览器访问 http://localhost:2333 就可以访问容器内跑的这个服务:

这就是 Dockerfile 构建成镜像,然后通过容器跑起来的流程。

但是刚才也发现了,现在镜像太大了,有 呢,怎么优化一下呢?

这就涉及到了第一个技巧:

使用 alpine 镜像,而不是默认的 linux 镜像

docker 容器内跑的是 linux 系统,各种镜像的 dockerfile 都会继承 linux 镜像作为基础镜像。

比如我们刚刚创建的那个镜像,点开详情可以看到它的镜像继承关系:

最终还是继承了 debian 的 Linux 镜像,这是一个 linux 发行版。

但其实这个 linux 镜像可以换成更小的版本,也就是 alpine。

它裁剪了很多不必要的 linux 功能,使得镜像体积大幅减小了。

alpine 是高山植物,就是很少的资源就能存活的意思。

我们改下 dockerfile,使用 alpine 的镜像:

node: 是使用 18 版本的 node 镜像,它底层使用 alpine 的基础镜像。

然后 docker build

dockerbuild-tdockerfile-test:second.

这次的 tag 为 second。

然后在 docker desktop 里看下:

好家伙,足足小了 900M。

我们点开看看:

可以看到它的底层 linux 镜像是 。

体积小了这么多,功能还正常么?

我们跑跑看:

dockerrun-d-p2334:3000--namesecond-containerdockerfile-test:second

docker desktop 可以看到这个跑起来的容器:

浏览器访问下,依然是正常的:

alpine 只是去掉了很多 linux 里用不到的功能,使得镜像体积更小。

这就是第一个技巧。

然后再来看第二个:

使用多阶段构建

看下这个 dockerfile,大家发现有啥问题没:

有的同学可能会说:为什么先复制 进去,安装依赖之后再复制其他文件,直接全部复制进去不就行了?

不是的,这两种写法的效果不同。

docker 是分层存储的,dockerfile 里的每一行指令是一层,会做缓存。

每次 docker build 的时候,只会从变化的层开始重新构建,没变的层会直接复用。

也就说现在这种写法,如果 没变,那么就不会执行 npm install,直接复用之前的。

那如果一开始就把所有文件复制进去呢?

那不管 变没变,任何一个文件变了,都会重新 npm install,这样没法充分利用缓存,性能不好。

我们试试看就知道了:

现在重新跑 docker build,不管跑多少次,速度都很快,因为文件没变,直接用了镜像缓存:

dockerbuild-tdockerfile-test:second.

现在我们改下 :

然后重新跑 build:

现在花了 25s,其实是没有重新 npm install 的。

然后改下 :

再跑 docker build

时间明显多了很多,过程中你可以看到在 npm install 那层停留了很长时间。

这就是为什么要这样写:

这里没问题,大家还能发现有没有什么别的问题么?

问题就是源码和很多构建的依赖是不需要的,但是现在都保存在了镜像里。

实际上我们只需要构建出来的 ./dist 目录下的文件还有运行时的依赖。

那怎么办呢?

这时可以用多阶段构建:

FROMnode:.RUNnpminstallCOPY..RUNnpmrunbuild#productionstageFROMnode:=build-stage/app/dist/appCOPY--from=build-stage/app//app//appRUNnpminstall--productionEXPOSE3000CMD["node","/app/"]

FROM 后面添加一个 as 来指定当前构建阶段的名字。

通过 COPY --from=xxx 可以从上个阶段复制文件过来。

然后 npm install 的时候添加 --production,这样只会安装 dependencies 的依赖。

docker build 之后,只会留下最后一个阶段的镜像。

也就是说,最终构建出来的镜像里是没有源码的,有的只是 dist 的文件和运行时依赖。

这样镜像就会小很多。

我们来试试看:

dockerbuild-tdockerfile-test:.

标签为 third。

-f 是指定 Dockerfile 的名字。

然后 desktop 里看下构建出来的镜像:

镜像体积比没有用多阶段构建的时候小了 250 M。

然后跑起来试试看:

这次映射 2335 端口到容器内的 3000 端口。

依然能正常访问:

这就是第二个技巧,多阶段构建。

使用 ARG 增加构建灵活性

我们写一个

();();

打印了环境变量 aaa、bbb

跑一下:

exportaaa=1bbb=2node./

可以看到打印了这俩环境变量:

然后我们写个 dockerfile,文件名是 :

FROMnode:/appCOPY./=${aaa}\bbb=${bbb}CMD["node","/app/"]

使用 ARG 声明构建参数,使用 ${xxx} 来取

然后用 ENV 声明环境变量。

dockerfile 内换行使用 \

之后构建的时候传入构建参数:

dockerbuild--build-argaaa=3--build-argbbb=.

通过 --build-arg xxx=yyy 传入 ARG 参数的值。

点击查看镜像详情,可以看到 ARG 已经被替换为具体的值了:

然后跑起来:

dockerrun--namefourth-containerarg-test

这次就不用 -d 后台运行了,直接看下日志:

可以看到容器内拿到的环境变量就是 ENV 设置的。

也就是说 ARG 是构建时的参数,ENV 时运行时的变量。

灵活使用 ARG,可以增加 dockerfile 的灵活性。

这就是第三个技巧。

CMD 结合 ENTRYPOINT

前面我们指定容器跑起来之后运行什么命令,用的是 CMD:

其实还可以写成 ENTRYPOINT:

这两种写法有什么区别么?

我们来试试:

写个

FROMnode:["echo","光光","到此一游"]

然后 build:

.

然后 run 一下:

dockerruncmd-test

没有指定 --name 时,会生成一个随机容器名。

就是这种:

这不是重点。

重点是用 CMD 的时候,启动命令是可以重写的:

dockerruncmd-testecho"东东"

可以替换成任何命令。

而用 ENTRYPOINT 就不会:

FROMnode:["echo","光光","到此一游"]

docker build:

.

docker run:

dockerruncmd-testecho"东东"

可以看到,现在 dockerfile 里 ENTRYPOINT 的命令依然执行了。

docker run 传入的参数作为了 echo 的额外参数。

这就是 ENTRYPOINT 和 CMD 的区别。

一般还是 CMD 用的多点,可以灵活修改启动命令。

其实 ENTRYPOINT 和 CMD 是可以结合使用的。

比如这样:

FROMnode:["echo","光光"]CMD["到此一游"]

docker build:

.

docker run:

dockerruncmd-testdockerruncmd-test66666

当没传参数的时候,执行的是 ENTRYPOINT + CMD 组合的命令,而传入参数的时候,只有 CMD 部分会被覆盖。

这就起到了默认值的作用。

所以,用 ENTRYPOINT + CMD 的方式更加灵活。

这是第四个技巧。

COPY vs ADD

其实不只是 ENTRYPOINT 和 CMD 相似,dockerfile 里还有一对指令也比较相似,就是 ADD 和 COPY。

这俩都可以把宿主机的文件复制到容器内。

但有一点区别,就是对于 这种压缩文件的处理上:

我们创建一个 aaa 目录,下面添加两个文件:

使用 tar 命令打包:

./aaa

然后写个

FROMnode:.//aaaCOPY.//bbb

docker build 生成镜像:

.

docker run 跑起来:

dockerrun-d--namesixth-containeradd-test

可以看到,ADD 把 给解压然后复制到容器内了。

而 COPY 没有解压,它把文件整个复制过去了:

也就是说,ADD、COPY 都可以用于把目录下的文件复制到容器内的目录下。

但是 ADD 还可以解压 文件。

一般情况下,还是用 COPY 居多。

案例代码上传了 github:

/QuarkGluonPlasma/nestjs-course-code/tree/main/dockerfile-test

总结

Docker 是流行的容器技术,它可以在操作系统上创建多个隔离的容器,在容器内跑各种服务。

它的流程是 Dockerfile 经过 docker build 生成 docker 镜像,然后 docker run 来跑容器。

docker run 的时候可以通过 -p 指定宿主机和容器的端口映射,通过 -v 挂载数据卷到容器内的某个目录。

CI/CD 基本也是这套流程,但是 Dockerfile 是要开发者自己维护的。

Dockerfile 有挺多技巧:

使用 alpine 的镜像,而不是默认的 linux 镜像,可以极大减小镜像体积,比如 node: 这种
使用多阶段构建,比如一个阶段来执行 build,一个阶段把文件复制过去,跑起服务来,最后只保留最后一个阶段的镜像。这样使镜像内只保留运行需要的文件以及 dependencies。
使用 ARG 增加构建灵活性,ARG 可以在 docker build 时通过 --build-arg xxx=yyy 传入,在 dockerfile 中生效,可以使构建过程更灵活。如果是想定义运行时可以访问的变量,可以通过 ENV 定义环境变量,值使用 ARG 传入。
CMD 和 ENTRYPOINT 都可以指定容器跑起来之后运行的命令,CMD 可以被覆盖,而 ENTRYPOINT 不可以,两者结合使用可以实现参数默认值的功能。
ADD 和 COPY 都可以复制文件到容器内,但是 ADD 处理 的时候,还会做一下解压。

灵活使用这些技巧,可以让你的 Dockerfile 更加灵活、性能更好。


最后,欢迎学编程的朋友们加入鱼皮的,和上万名学编程的同学共享知识、交流进步,学习原创项目并享有答疑指导服务。

往期推荐

标签:

相关阅读

404 Not Found

404 Not Found


nginx
404 Not Found

404 Not Found


nginx
404 Not Found

404 Not Found


nginx

相关词

推荐阅读