高级镜像制作 – Cedar-记录日常的小破站

本文最后更新于110 天前，其中的信息可能已经过时，如有错误请发送邮件到big_fw@foxmail.com

一. 信号终止容器

容器中的应用优雅的退出

进程关闭慢的原因;
1.进程占用资源比较多，退出时候清理的动作比较多，所以会有点慢
2.进程是通过脚本启动的，脚本不能识别信号
正常情况下如果不sigterm级别退出的话，他会kill级别退出，如果进程正在运行，会有好多数据保存在内存中并没有写入磁盘，很可能导致文件缺失或者损坏，在生产环境中一定要尽最大可能不要用kill -9

容器中的应用优雅的退出

1、进程的退出 - Linux

1.1、kill 参数

信号的前提是进程听得懂，如果一个进程在开发的时候压根就没有捕获信号的功能，那么发啥信号都不行

1	SIGHUP	启动被终止的程序，可让该进程重新读取自己的配置文件，类似重新启动。
2	SIGINT	相当于用键盘输入 [ctrl]-c 来中断一个程序的进行。
9	SIGKILL	代表强制中断一个程序的进行，如果该程序进行到一半，那么尚未完成的部分可能会有“半产品”产生，类似 vim会有 .filename.swp 保留下来。
15	SIGTERM	以正常的方式来终止该程序。由于是正常的终止，所以后续的动作会将他完成。不过，如果该程序已经发生问题，就是无法使用正常的方法终止时，输入这个 signal 也是没有用的。
19	SIGSTOP	相当于用键盘输入 [ctrl]-z 来暂停一个程序的进行。

1.2、信号

信号是一种进程间通信的形式。一个信号就是 内核发送给进程 的一个消息，告诉进程发生了某种事件。当一个信号被发送给一个进程后，进程会立即中断当前的执行流并开始执行信号的处理程序。如果没有为这个信号指定处理程序，就执行默认的处理程序。
进程需要为自己感兴趣的信号注册处理程序，比如为了能让程序优雅的退出(接到退出的请求后能够对资源进行清理)一般程序都会处理 SIGTERM 信号。与 SIGTERM 信号不同，SIGKILL 信号会粗暴的结束一个进程。因此我们的应用应该实现这样的目录：捕获并处理 SIGTERM 信号，从而优雅的退出程序。如果我们失败了，用户就只能通过 SIGKILL 信号这一终极手段了。除了 SIGTERM 和 SIGKILL ，还有像 SIGUSR1 这样的专门支持用户自定义行为的信号

2、容器中的信号

Gitee.com 底层就是Git控制器

版本控制器：在代码的组建下开启一个分支，在这个分支上进行二次开发，等开发完了就可以放回组件了，版本控制器会自己对开发完的分支进行识别，看哪些发生了修改放在组件中，避免了多分支修改的不一样，版本冲突等问题

2.1、容器中的 1 号进程可以接收到SIG信号

Docker 的 stop 和 kill 命令都是用来向容器发送信号的。注意，只有容器中的 1 号进程能够收到信号，这一点非常关键！stop 命令会首先发送 SIGTERM 信号，并等待应用优雅的结束。如果发现应用没有结束(用户可以指定等待的时间)，就再发送一个 SIGKILL 信号强行结束程序。kill 命令默认发送的是 SIGKILL 信号，当然你可以通过 -s 选项指定任何信号

# main go的源码，有协程监听信号，死循环加一并输出结果
package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"
    "time"
)

// 优雅退出go守护进程
func main()  {
    //创建监听退出chan
    c := make(chan os.Signal)
    //监听指定信号 ctrl+c kill
    signal.Notify(c, syscall.SIGHUP, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGUSR1, syscall.SIGUSR2)
    go func() {
        for s := range c {
            switch s {
            case syscall.SIGTERM, syscall.SIGHUP, syscall.SIGINT, syscall.SIGQUIT:
                fmt.Println("退出", s)
                ExitFunc()
            case syscall.SIGUSR1:
                fmt.Println("usr1", s)
            case syscall.SIGUSR2:
                fmt.Println("usr2", s)
            default:
                fmt.Println("other", s)
            }
        }
    }()

    fmt.Println("进程启动...")
    sum := 0
    for {
        sum++
        fmt.Println("sum:", sum)
        time.Sleep(time.Second)
    }
}

func ExitFunc()  {
    fmt.Println("开始退出...")
    fmt.Println("执行清理...")
    fmt.Println("结束退出...")
    os.Exit(0)

# dockerfile
FROM wangyanglinux/go:run1.0
RUN mkdir /go/src/signal
ADD ./main.go /go/src/signal
RUN cd /go/src/signal && GO111MODULE=off CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
RUN chmod a+x /go/src/signal/main

$ docker build --no-cache -t signal-app -f Dockerfile .

$ docker run -it --rm -p 3000:3000 --name="my-app" signal-app
#指定信号的级别，向指定的容器发指定信号
$ docker container kill --signal="SIGTERM" my-app

2.2、容器的 1 号进程接收不到SIG信号

创建 app1.sh 文件

#!/bin/bash
node app

创建 Dockerfile1 文件
和之前的步骤一样，就是多了一个启动脚本，开启以后执行启动脚本，脚本可以进行动态镜像

FROM iojs:onbuild
COPY ./app.js ./app.js
COPY ./app1.sh ./app1.sh
COPY ./package.json ./package.json
RUN chmod +x ./app1.sh
EXPOSE 3000
ENTRYPOINT ["./app1.sh"]

$ docker build --no-cache -t signal-app1 -f Dockerfile1 .
$ docker run -it --rm -p 3000:3000 --name="my-app1" signal-app1

正常build镜像，启动容器
stop会卡好久，因为脚本接收不到信号，并且没有结束语，证明直接被一刀斩的

docker container kill --signal="SIGTERM" my-app
执行kill无法关闭容器，因为1进程是启动脚本，无法识别信号
stop可以关闭，是因为一直没有响应，系统执行了9级别的信号，一刀斩，这很恐怖，如果是数据库，那就会出现半成品文件

结论：

1、容器中的 1 号进程是容器的启动命令
2、DockerServer 发送的信号只能传递给容器中的 1 号进程
3、当 DockerServer 像容器多次发送 15 号信号后，如果容器没有退出，那么将执行 9 级别信号

2.3、在脚本中捕获信号

创建 app2.sh 文件

#!/bin/bash
# 打开调试级别
set -x

# 指定当前 pid 号
pid=0

# SIGUSR1-handler
my_handler() {
  echo "my_handler"
}

# SIGTERM-handler
term_handler() {
  if [ $pid -ne 0 ]; then
    kill -SIGTERM "$pid"
    # wait是用来阻塞当前进程的执行，直至指定的子进程执行结束后，才继续执行
    wait "$pid"
  fi
  exit 143; # 128 + 15 -- SIGTERM
}
# setup handlers
# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler

# 　trap 'commands' signal-list 当脚本收到 signal-list 清单内列出的信号时, trap 命令执行双引号中的命令
trap 'kill ${!}; my_handler' SIGUSR1
trap 'kill ${!}; term_handler' SIGTERM

# run application
node app &
pid="$!"

# wait forever
while true
do
  tail -f /dev/null & wait ${!}
done

先设置变量PID=0，声明函数term
通trap命令当小弟去监控，管理员发没发出SIGTERM信号，如果发了，就调用term函数，并且杀死后面的while循环
wait 等待上一个命令是否退出，退出了就不等了，没退出就一直等，等你结束
执行main，并且放在后台运行，pid=“$!” 只能看见放在后台的进程的PID
由于容器必须有一个放在前台的进程，所以设置一个while循环，最小的资源去保持前台进程
当有信号来时，小弟先接收，调用term函数，优雅退出主进程，并且结束while循环，容器停止

创建 Dockerfile2 文件

FROM iojs:onbuild
COPY ./app.js ./app.js
COPY ./app2.sh ./app2.sh
COPY ./package.json ./package.json
RUN chmod +x ./app2.sh
EXPOSE 3000
ENTRYPOINT ["./app2.sh"]

$ docker build --no-cache -t signal-app2 -f Dockerfile2 .
$ docker run -it --rm -p 3000:3000 --name="my-app2" signal-app2

二、多级镜像

要在编译型语言的运行环境才能封装
因为要从源码编译成可执行文件，以后就可以被计算机识别，不用再次解释了
但是解释型语言每次都要去解释成计算机认识的，CPU才能执行

镜像 Cache 机制

Docker Daemnon 通过 Dockerfile 构建镜像时，当发现即将新构建出的镜像与已有的某镜像重复时，可以选择放弃构建新的镜像，而是选用已有的镜像作为构建结果，也就是采取本地已经 cache 的镜像作为结果

Cache 机制的注意事项：

1. ADD 命令与 COPY 命令：Dockerfile 没有发生任何改变，但是命令ADD run.sh / 中 Dockerfile 当前目录下的 run.sh 却发生了变化，从而将直接导致镜像层文件系统内容的更新，原则上不应该再使用 cache。那么，判断 ADD 命令或者 COPY 命令后紧接的文件是否发生变化，则成为是否延用 cache 的重要依据。Docker 采取的策略是：获取 Dockerfile 下内容（包括文件的部分 inode 信息），计算出一个唯一的 hash 值，若 hash 值未发生变化，则可以认为文件内容没有发生变化，可以使用 cache 机制；反之亦然**

2. RUN 命令存在外部依赖：一旦 RUN 命令存在外部依赖，如RUN apt-get update，那么随着时间的推移，基于同一个基础镜像，一年的 apt-get update 和一年后的 apt-get update，由于软件源软件的更新，从而导致产生的镜像理论上应该不同。如果继续使用 cache 机制，将存在不满足用户需求的情况。Docker 一开始的设计既考虑了外部依赖的问题，用户可以使用参数 --no-cache 确保获取最新的外部依赖，命令为docker build --no-cache -t="my_new_image" .

3. 树状的镜像关系决定了，一次新镜像的成功构建将导致后续的 cache 机制全部失效：这一点很好理解，一旦产生一个新的镜像，同时意味着产生一个新的镜像 ID，而当前宿主机环境中肯定不会存在一个镜像，此镜像 ID 的父镜像 ID 是新产生镜像的ID。这也是为什么，书写 Dockerfile 时，应该将更多静态的安装、配置命令尽可能地放在 Dockerfile 的较前位置

传统 Build 流程

1.创建Dockerfile
创建Reptile目录
把go语言的源码放进这个目录
删除上级镜像的启动脚本
把自己的启动脚本放进去
2.启动脚本
先删的是之前编译的main，现在封装进来的是main.go！！！

3.main.go执行的效果就是再一个网站去爬图片，

docker run --name rep -v /data:/go/src/Reptile/img  --rm  reptile:v1

多级镜像build构建

流程描述：

先在大的镜像环境中启动容器，在这个功能依赖都很全的容器内把我们需要的源码进行编译，编译完成后直接把编译完产生的可执行文件拿出来，拿出来以后就可以删除这个容器，之后就可以在高山镜像的基础上把这个可执行文件放进去封装成一个非常小的镜像，实现的效果和在原有镜像的效果一样，但是小了很多倍，很方便传输，而且功能少，更安全

multistage.sh


#!/bin/sh
echo Building multistagescript:build
# 构建编译应用程序的镜像
docker build --no-cache -t multistagescript:build . -f Dockerfile
# 创建应用程序
docker run --name extract -d multistagescript:build

# 等待应用编译成功
sleep 40s

# 拷贝编译好的应用程序
docker cp extract:/go/src/Reptile/main .
docker rm -f extract

echo Building multistagescript:latest
# 构建运行应用程序的镜像
docker build --no-cache -t multistagescript:latest . -f Dockerfile.Run

dockerfile

FROM wangyanglinux/go:run1.0
RUN mkdir /go/src/Reptile
COPY ./main.go /go/src/Reptile
RUN rm -rf /root/run.sh
COPY ./run.sh /root
CMD /bin/bash /root/run.sh

启动脚本run.sh

#!/bin/bash
rm -rf /go/src/Reptile/main
cd /go/src/Reptile
GO111MODULE=off CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .
tail -f /root/run.sh

dockerfile.run

FROM alpine:latest
WORKDIR /root/
COPY main .
RUN mkdir /root/img
CMD ["./main"]

镜像对比：

官方的多级镜像

在多机构建上进行优化，原理一样，就是直接写在了Dockerfile上

FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/sparkdevo/href-counter/
RUN go get -d -v golang.org/x/net/html
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/sparkdevo/href-counter/app .
CMD ["./app"]

在docker17.05版本后面有的新命令
COPY --from=0 0代表第一个from的镜像，把之前产生的可执行文件拿到当前镜像中
如果有多个FROM，可以调用多个，COPY --from多个，注意，只能后面的调用前面的
但是如果一个Dockerfile中有很多很多的FROM，那么123456789很容易数错，所以这里支持别名
例：
```
FROM golang:1.7.3 as builder
COPY --from=builder    /go/src/github.com/sparkdevo/href-counter/app .
```

三、.dockerignore

.dockerignore 文件说明

.dockerignore 文件的作用类似于 git 工程中的 .gitignore 。不同的是 .dockerignore 应用于 docker 镜像的构建，它存在于 docker 构建上下文的根目录，用来排除不需要上传到 docker 服务端的文件或目录。

docker 在构建镜像时首先从构建上下文找有没有 .dockerignore 文件，如果有的话则在上传上下文到 docker 服务端时忽略掉 .dockerignore 里面的文件列表。这么做显然带来的好处是：

构建镜像时能避免不需要的大文件上传到服务端，从而拖慢构建的速度、网络带宽的消耗；
可以避免构建镜像时将一些敏感文件及其他不需要的文件打包到镜像中，从而提高镜像的安全性；

.dockerignore 文件编写方法

.dockerignore 文件的写法和 .gitignore 类似，支持正则和通配符，具体规则如下：

每行为一个条目；
以 # 开头的行为注释；
空行被忽略；
构建上下文路径为所有文件的根路径；

文件匹配规则具体语法如下

规则	行为
/temp	匹配根路径下一级目录下所有以 temp 开头的文件或目录
//temp*	匹配根路径下两级目录下所有以 temp 开头的文件或目录
temp?	匹配根路径下以 temp 开头，任意一个字符结尾的文件或目录
*/.go	匹配所有路径下以 `.go` 结尾的文件或目录，即递归搜索所有路径
*.md	匹配根路径下所有以 `.md` 结尾的文件或目录，但 README.md 除外
!README.md

注意事项

如果两个匹配语法规则有包含或者重叠关系，那么以后面的匹配规则为准，比如：

*.md
!README*.md

README-secret.md

这么写的意思是将根路径下所有以 .md 结尾的文件排除，以 README 开头 .md 结尾的文件保留，但是 README-secret.md 文件排除。

再来看看下面这种写法（同上面那种写法只是对换了后面两行的位置）：

*.md
README-secret.md
!README*.md

这么写的意思是将根路径下所有以 .md 结尾和名称为 README-secret.md 的文件排除，但所有以 README 开头 .md 结尾的文件保留。这样的话 README-secret.md 依旧会被保留，并不会被排除，因为 README-secret.md 符合 !README*.md 规则。

最终演示

我们先看当前的目录下的文件列表。我将会在其中：

排除 .git 文件或者目录
*排除 .log 文件，或者以 -log-= 的文件**
*排除 .tag.gz 文件**
.war 文件，以及 jenkins_home 下的 .txt 文件
Dockerfile 文件
*.dockerignore 文件，包括所有的 .md 文件，但是 info.md 除外**

那么最终就剩下 jenkins_home 下的 mark 目录和 info.md 了

[root@wangyanglinux /root/2021/ignore]# tree -a .
.
├── 0.log
├── 1.log
├── 2.log
├── Dockerfile
├── .dockerignore
├── .git
├── info.md
├── jenkins-2.2365.tar.gz
├── jenkins_home
│   ├── 2021-01-11_10:15:47.txt
│   └── mark
├── jenkins.war
├── link.md
└── readme.md

2 directories, 12 files

.dockerignore文件

[root@wangyanglinux /root/2021/ignore]# cat .dockerignore 
# 排除 .git 文件或者目录
.git
# 排除 .log 文件，或者包含  -log- 的文件
**/*.log
**/*-log-*
# 排除 *.tag.gz 文件
**/*.tar.gz
# .war 文件，以及 jenkins_home 下的* .txt 文件
**/*.war
jenkins_home/*.txt
# Dockerfile 文件
Dockerfile
# .dockerignore 文件，包括所有的 *.md 文件，但是 info.md 除外
.dockerignore
*.md
!info.md

Dockerfile

FROM alpine:3.1
MAINTAINER wangyanglinux 宝典
WORKDIR /opt/
COPY . /opt/
CMD ["sleep","66666666"]

Build

[root@wangyanglinux /opt/2021/ignore]# docker build -t ignore .
Sending build context to Docker daemon  10.608kB
Step 1/5 : FROM alpine:3.1
 ---> caa27325b098
Step 2/5 : MAINTAINER wangyanglinux 宝典
 ---> Using cache
 ---> c1603397aeb5
Step 3/5 : WORKDIR /opt/
 ---> Using cache
 ---> 10t23827358f
Step 4/5 : COPY . /opt/
 ---> cei0c655d1971
Step 5/5 : CMD ["sleep","66666666"]
 ---> Running in b1o1bd2833bf
Removing intermediate container b1e1bdc803bf
 ---> 811de39aad48
Successfully built a12dekcaad48
Successfully tagged ignore:latest

验证

[root@wangyanglinux /opt/2021/ignore]# docker run --rm -it  ignore sh
/opt # ls -a
.             ..            info.md       jenkins_home
/opt # ls -a jenkins_home/
.     ..    mark
/opt # ls -a jenkins_home/mark/
.   ..
/opt #

一. 信号终止容器

容器中的应用优雅的退出

1、进程的退出 - Linux

1.1、kill 参数

1.2、信号

2、容器中的信号

2.1、容器中的 1 号进程可以接收到SIG信号

2.2、容器的 1 号进程接收不到SIG信号

结论：

2.3、在脚本中捕获信号

二、多级镜像

镜像 Cache 机制

Cache 机制的注意事项：

传统 Build 流程

多级镜像build构建

官方的多级镜像

三、.dockerignore

.dockerignore 文件说明

.dockerignore 文件编写方法

文件匹配规则具体语法如下

注意事项

最终演示

发送评论 编辑评论

推荐文章

发送评论编辑评论