如何用Dockerfile创建镜像

2023-02-24 01:20:02Python025

如何用Dockerfile创建镜像,第1张

创建镜像的目的

首先说DockerHub或其它一些镜像仓库已经提供了够多的镜像，有最小版本，也有一些安装了mysql、nginx、apache等等第三方软件的版本可以直接拿来使用。虽然已经足够多了，但是有些情况下并不能满足我们的需求，例如需要安装一些比较少用到的第三方软件，这个时候只能先用公共仓库中的镜像，启动容器，然后在容器中按照我们的需求安装软件，修改配置等等操作，之后提交镜像。这些操作在之前的文章中介绍了。这样操作完成之后，可以用如下两种方式实现定制镜像的目的：

1.用save和export的方式将镜像保存为tar包，然后在需要的时候导入tar镜像包

2.将已经配置好的镜像push到我们的私有仓库（docker创建私有仓库）或者已注册过的共有仓库中，需要的时候直接pull下来使用

这两种方式都可以，但是自动化程度低、自由度不够、定制起来比较麻烦。既然如此，那就来说一下更加自动化的创建方式。

Dockerfile结构

dockerfile由4部分信息组成：基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令。

# This dockerfile uses the ubuntu image

# VERSION 2 - EDITION 1

# Author: docker_user

# Command format: Instruction [arguments / command] ..

# Base image to use, this must be set as the first line

FROM ubuntu

# Maintainer: docker_user <docker_user at email.com>(@docker_user)

MAINTAINER docker_user [email protected]

# Commands to update the image

RUN echo "deb http://archive.ubuntu.com/ubuntu/ raring main universe" >>/etc/apt/sources.list

RUN apt-get update &&apt-get install -y nginx

RUN echo "\ndaemon off" >>/etc/nginx/nginx.conf

# Commands when creating a new container

CMD /usr/sbin/nginx

其中#表注释，可以标注一些说明性的文字。

FROM关键字指定镜像的来源，默认为DockerHub，也可以写私有仓库的镜像，例如：localhost：5000/centos:6.7，如果本地已经存在指定的镜像名称，则会从本地缓存直接获取。MAINTAINER 指定镜像的作者，之后为镜像操作执行RUN、ADD等，最后是容器启动时发起的指令。

Dockerfile中的指令

FROM: 指定镜像名称，格式为FROM <image>或FROM <image>:<tag>，例如FROM ubuntu 或 FROM ubuntu:12.04　

MAINTAINER: 镜像作者，格式为 MAINTAINER <name>

RUN：格式为 RUN <command>或 RUN ["executable", "param1", "param2"]。

前者将在 shell 终端中运行命令，即 /bin/sh -c；后者则使用 exec 执行。指定使用其它终端可以通过第二种方式实现，例如 RUN ["/bin/bash", "-c", "echo hello"]。

每条 RUN 指令将在当前镜像基础上执行指定命令，并提交为新的镜像。当命令较长时可以使用 \ 来换行。

CMD:支持三种格式

1.CMD ["executable","param1","param2"] 使用 exec 执行，推荐方式；

2.CMD command param1 param2 在 /bin/sh 中执行，提供给需要交互的应用；

3.CMD ["param1","param2"] 提供给 ENTRYPOINT 的默认参数；

指定启动容器时执行的命令，每个 Dockerfile 只能有一条 CMD 命令。如果指定了多条命令，只有最后一条会被执行。如果用户启动容器时候指定了运行的命令，则会覆盖掉 CMD 指定的命令。

EXPOSE:格式为 EXPOSE <port>[<port>...]。

告诉 Docker 服务端容器暴露的端口号，供互联系统使用。在启动容器时需要通过 -P，Docker 主机会自动分配一个端口转发到指定的端口。

ENV:格式为 ENV <key><value>。指定一个环境变量，会被后续 RUN 指令使用，并在容器运行时保持。这就对应程序语言中的变量定义，可在需要的时候引用。例如：

ENV PG_MAJOR 9.3

ENV PG_VERSION 9.3.4

RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress &&…

ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH

ADD:格式为 ADD <src><dest>。

该命令将复制指定的 <src>到容器中的 <dest>。其中 <src>可以是Dockerfile所在目录的一个相对路径；也可以是一个 URL；还可以是一个 tar 文件（自动解压为目录）。

COPY:格式为 COPY <src><dest>。

复制本地主机的 <src>（为 Dockerfile 所在目录的相对路径）到容器中的 <dest>。当使用本地目录为源目录时，推荐使用 COPY。

COPY和ADD的不同就是：ADD多了自动解压和支持URL路径的功能。

ENTRYPOINT：

两种格式：

ENTRYPOINT ["executable", "param1", "param2"]

ENTRYPOINT command param1 param2（shell中执行）。

配置容器启动后执行的命令，并且不可被 docker run 提供的参数覆盖。

每个 Dockerfile 中只能有一个 ENTRYPOINT，当指定多个时，只有最后一个起效。

CMD和ENTRYPOINT比较：两个命令都是只能使用一次，并且都是在执行docker run指令时运行，如果有多个，只执行最后一条。

两者的不同在于参数的传递方式，如果在Dockerfile中定义如下指令

CMD echo hello

或

ENTRYPOINT ["echo","hello"]　

那么在运行命令docker run containerId echo hello时，指定了CMD的输入结果为world，可以看出Dockerfile中指定的命令被覆盖了，而指定了ENTRYPOINT时，输出结果为hello echo world，可以看出指定的命令被作为ENTRYPOINT指定指令的参数了。

VOLUME:格式为 VOLUME ["/data"]。创建一个可以从本地主机或其他容器挂载的挂载点，一般用来存放数据库和需要保持的数据等。不过此属性在Dockerfile中指定并没有什么意义，因为没有办法指定本地主机的目录。如果需要指定挂载点可以在执行docker run命令时指定：

docker run -it -v /home/fengzheng/ftp/:/data 859666d51c6d /bin/bash

USER:格式为 USER daemon。指定运行容器时的用户名或 UID，后续的 RUN 也会使用指定用户。

当服务不需要管理员权限时，可以通过该命令指定运行用户。并且可以在之前创建所需要的用户，例如：RUN groupadd -r postgres &&useradd -r -g postgres postgres。要临时获取管理员权限可以使用 gosu，而不推荐 sudo。

WORKDIR:格式为 WORKDIR /path/to/workdir。为后续的 RUN、CMD、ENTRYPOINT 指令配置工作目录。可以使用多个 WORKDIR 指令，后续命令如果参数是相对路径，则会基于之前命令指定的路径。例如

WORKDIR /a

WORKDIR b

WORKDIR c

RUN pwd

则最终路径为 /a/b/c。

ONBUILD:格式为 ONBUILD [INSTRUCTION]。

配置当所创建的镜像作为其它新创建镜像的基础镜像时，所执行的操作指令。

例如，Dockerfile 使用如下的内容创建了镜像 image-A。

[...]

ONBUILD ADD . /app/src

ONBUILD RUN /usr/local/bin/python-build --dir /app/src

[...]

如果基于 image-A 创建新的镜像时，新的Dockerfile中使用 FROM image-A指定基础镜像时，会自动执行ONBUILD 指令内容，等价于在后面添加了两条指令。

FROM image-A

#Automatically run the following

ADD . /app/src

RUN /usr/local/bin/python-build --dir /app/src

使用 ONBUILD 指令的镜像，推荐在标签中注明，例如 ruby:1.9-onbuild。

基于CentOS6.7并源码安装nginx

首先准备了nginx-1.9.9.tar.gz安装包和CentOS6-Base-163.repo（163源），将这两个文件放到同一目录下，并在此目录下创建名称为Dockerfile的文件。之后在此文件中实现源替换、nginx编译安装、及一些依赖包的安装，Dockerfile内容如下：

# this is a test ubuntu 12.04 image dockerfile

# Author:fengzheng

# Base image,this must be set as the first line

#localhost:5000/centos:6.7是我的私有仓库的镜像，可替换为centos:6.7（DockerHub中的镜像）

FROM localhost:5000/centos:6.7

MAINTAINER fengzheng

# Commands to update the image

RUN mkdir /usr/nginx1.9.9

ADD nginx-1.9.9.tar.gz /usr/nginx1.9.9/

#RUN yum -y install tar

#RUN tar -zxvf /usr/nginx1.9.9/nginx-1.9.9.tar.gz

RUN cd /etc/yum.repos.d/ &&mv CentOS-Base.repo CentOS-Base.repo.bak

ADD CentOS6-Base-163.repo /etc/yum.repos.d/

RUN cd /etc/yum.repos.d/ &&mv CentOS6-Base-163.repo CentOS-Base.repo \

&&yum clean all &&yum makecache \

&&yum -y install gcc \

&&yum -y install yum install -y pcre-devel \

&&yum -y install zlib zlib-devel \

&&yum -y install openssl openssl--devel \

&&cd /usr/nginx1.9.9/nginx-1.9.9/ &&./configure &&make &&make install

#如果设置daemon offnginx无法启动

#RUN echo "\ndaemon off" >>/etc/nginx/nginx.conf

# Commands when creating a new container

# 启动nginx 需进入/usr/local/nginx/sbin 执行./configure

CMD /bin/bash

最后执行命令"docker build -t nginx-centos:6.7 ."

其中.表示在当前目录下搜索Dockerfile文件，-t参数指定镜像名称和tag。

## 背景 ##

我最初使用Docker的时候，每个人都在说它用起来有多简单方便，它内部的机制是有多么好，它为我们节省了多少时间。但是当我一使用它就发现，几乎所有镜像都是臃肿而且不安全的（没有使用包签名，盲目相信上游的镜像库以<code>curl

| sh</code>的方式安装)，而且也没有一个镜像能实现Docker的初衷：隔离，单进程，容易分发，简洁。

Docker镜像本来不是为了取代复杂的虚拟机而设计的，后者有完整的日志、监控、警报和资源管理模块。而Docker则倾向于利用内核的<code>cgroups</code>和<code>namespaces</code>特性进行封装组合，这就好像：

在物理机器环境下，一旦内核完成了初始化，<code>init</code>进程就起来了。

这也是为什么当你在Dockerfile的<code>CMD</code>指令启动的进程PID是1，这是与Unix中的进程机制类似的。

现在请查看一下你的进程列表，使用<code>top</code>或者<code>ps</code>，你会看到<code>init</code>进程占用的也是这个PID，这是每个类Unix系统的核心进程，所有进程的父进程，一旦你理解这个概念：在类Unix系统上每个进程都是init进程的子进程，你会理解Docker容器里不应该有无关的修饰文件，它应该是刚好满足进程运行需要。

如何开始

现在的应用多数是大型复杂的系统，通常都需要很多依赖库，例如有调度，编译和很多其他相关工具类应用，它们的架构通常封装性良好，通过一层层的抽象和接口把底层细节隐藏了，从某种程度上说，这也算是一种容器，但是从系统架构视角看，我们需要一种比以往虚拟环境更简单的方案了。

以Java为例

从零开始，思考你要构建一个最通用的基础容器，想想你的应用本身，它运行需要什么？

可能性有很多，如果你要运行Java应用，它需要Java运行时；如果运行Rails应用，它需要Ruby解释器，对Python应用也一样。Go和其他一些编译型语言有些许不同，我以下会提到。

在Java例子中，下一步要想的是：JRE需要什么依赖才能运行？因为它是让应用能运行的最重要的组件，所以很自然的下一步就是要想清楚JRE运行依赖于什么。

而实际上JRE并没太多依赖，它本来就是作为操作系统的抽象层，使代码不依赖于宿主系统运行，因此安装好JRE就基本准备就绪了。

（实际上，对操作系统的独立性并不是理所当然的事，有非常多的系统特有API和专有的系统扩展，但是便于举例，我们把注意力放在简单的情况下）

在Linux上，JVM主要是调用系统的C语言库，Oracle的官方JRE，使用的是libc，也就是glibc，这意味着你要运行任何Java程序，都需要先装好glibc。另外你可能需要某种shell来管理环境，还有一个与外部通讯的接口，例如网络和资源的接口。

我们总结一下Java应用示例需要的最低配置是：

JRE，在例子中我们使用Oracle JRE

glibc，JRE的依赖

一个基础环境（包含网络、内存、文件系统等资源管理工具）

## 走进Alpine Linux ##

Alpine Linux最近得到很多关注，主要是因为它打包了一系列的经过验签的可信任的依赖，并且还保持体积在2MB！而在本文发布时，其他的一些镜像分发版如下：

ubuntu:latest: 66MB (已经瘦身了非常多了，以前有些版本超过600MB)

debian:latest: 55MB (同上，一开始是200MB以上的）

arch:latest: 145MB

busybox:latest: 676KB (是的！KB，我稍后会讨论它)

alpine:latest: 2MB (2MB，包含一个包管理工具的Linux系统)

** Busybox是最小的竞争者？**

从上边的对比中你可以看到，在体积上唯一能打败Alpine Linux的是Busybox，所以现在几乎所有嵌入式系统都是使用它，它被应用在路由器，交换机，ATM，或者你的吐司机上。它作为一个最最基础的环境，但是又提供了足够容易维护的shell接口。

在网上有很多文章解释了为什么人们会选择Alpine Linux而不是Busybox，我在这总结一下：

开放活跃的软件包仓库：Alpine

Linux使用apk包管理工具，它集成在Docker镜像中，而Busybox你需要另外安装一个包管理器，例如opkg，更甚者，你需要寻找一个稳定的包仓库源（这几乎没有），Alpine的包仓库中提供了大量常用的依赖包，例如，如果你仍然需要在容器中编译NodeJS或Ruby之类的代码，你可以直接运行apk来添加nodejs和ruby，这在几秒内便可以完成。

体积确实重要，但是当你在功能性，灵活性，易用性和1.5MB之间衡量，体积就不那么重要了，Alpine上添加的包使这些方面都大大增强了。

广泛的支持：Docker公司已经聘请了Alpine Linux的作者来维护它，所有官方镜像，在以后都将基于Alpine Linux来构建。没有比这个更有说服力的理由去让你在自己的容器中使用它了吧。

希云cSphere 很早就意识到镜像越来越庞大的问题，因此在去年推出微镜像，也是引导大家如何更好地构建和理解镜像，镜像只是一种软件包格式而已。

** 构建一个Java环境基镜像 **

正如我刚解释的，Alpine Linux是一个构建自有镜像时不错的选择，因此，我们在此将使用它来构建简洁高效的Docker镜像，我们开始吧!

组合：Alpine + bash

每个Dockerfile第一个指令都是指定它的父级容器，通常是用于继承，在我们的例子中是<code>alpine:latest</code>:

FROM alpine:latest

MAINTAINER cSphere [email protected]>

我们同时声明了谁为这个镜像负责，这个信息对上传到Docker Hub的镜像是必要的。

就这样，你就有了往下操作的基础，接下来安装我们选好的shell,把下边的命令加上：

RUN apk add --no-cache --update-cache bash