docker实践入门之五

image的派生

上面这个例子 有一个问题就是,如果应用程序修改了,就需要重新build一次,问题是重build的时候需要把前面一堆的命令都跑一遍,特别是安装软件那些还是挺慢 的,而且是不必要的重复工作,实际上我们只是修改了应用程序而已,所以更机智的办法是把这个image分成两个image,一个是python3基础环 境,一个是应用程序image。

先来python3环境的Dockerfile:

FROM alpine
MAINTAINER raptor
COPY repositories /etc/apk/
RUN apk update \
    && apk add python3 curl \
    && curl -O https://bootstrap.pypa.io/get-pip.py \
    && python3 get-pip.py \
    && rm get-pip.py

这是python3基础image:

docker build -t python3 .

然后是应用程序Dockerfile:

FROM python3
MAINTAINER raptor
EXPOSE 5000
RUN mkdir /var/app
COPY app /var/app/
WORKDIR /var/app/
RUN pip3 install -r requirements.txt
CMD python3 start.py

然后创建应用程序image:

docker build -t app1 .

这样以后修改了应用程序只需要build第二个image即可。不过因为安装依赖包也是很慢的,还可以考虑再加一层image,作为应用程序的基础环境。

image的标签

image分层以后又会带来一个新的问题:比如我们用了三层image来部署两个应用A和B,最底层的是osimage,然后是py3image,然后是两个应用:Aimage, Bimage。

刚 开始总是很简单,直接按顺序一个个build即可。但是用了一段时间以后,比如应用B修改了,增加了一些新的依赖包,这时就需要重新build py3image,但是因为Aimage又依赖py3image,所以不一定能直接重build(比如A应用有些地方与新依赖包不兼容,可能需要A应用作 一些修改以后才能切过来),只能新建一个py3image2,然后让新的Bimage去依赖py3image2。那么以后要是os层也改了呢?再搞一个 osimage2吗?那分层的意义何在?如果不止两个应用,而是有十几个应用呢?那不是要麻烦死?

所以这时我们需要tag(标签)

tag在某种意义上相当于版本号,其中latest是一个特殊tag,如果在build image时不指定tag,默认就是这个,其好处就在于它总是对应于最新一个版本。

在 不指定tag的情况下,每次build一个同名的image,就是把它的latest给覆盖掉——不过如果这个image已经运行为container或 者有派生的image,则并不会被实际覆盖,只是旧版本会不显示,并且被标记为删除,一旦不再有其它引用,它才会被实际删除。

仍然以简单的AB两个应用的情况为例:

现在build一个baseimage,然后派生Aimage和Bimage。然后假设这时A应用需要有新的依赖,所以修改了baseimage,但是Bimage没有需要,暂时也不想跟着升级,则可以这样做:

docker tag baseimage baseimage:1

即生成一个版本号为1的baseimage。

注意,这个操作只是打个标签,并没有生成两个image,通过查看images可以知道,它们的ID是一样的。

docker images

这时用修改过的Dockerfile重新build:

docker build -t baseimage .

则会生成一个新的baseimage:latest,这时二者的ID就不一样了。而A应用的Dockerfile里只要保持这一句,它就始终是依赖latest的:

FROM baseimage

而B应用只要重新build一次,即可同样更新到新的latest,如果不想更新到latest,也可以修改Dockerfile,改成:

FROM baseimage:1

即可用旧版build。

以上的做法是在build新版前给旧版打标签,但实际上更好的做法是在build的同时就给新版打上标签,这样就可以很清楚地知道,从这个时间点以后生成的派生image默认都是用这个版本的base。

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页