制做本身的docker镜像

制做本身的Docker镜像主要有以下两种方式：

1.使用docker commit 命令来建立镜像

1. 经过docker run命令启动容器
2. 修改docker镜像内容
3. docker commit提交修改的镜像
4. docker run新的镜像

2.使用 Dockerfile 来建立镜像

使用 docker commit 来扩展一个镜像比较简单，可是不方便在一个团队中分享。咱们可使用 docker build 来建立一个新的镜像。为此，首先须要建立一个 Dockerfile，包含一些如何建立镜像的指令。

Dockerfile 基本的语法

• 使用#来注释
• FROM 指令告诉 Docker 使用哪一个镜像做为基础
• 接着是维护者的信息
• RUN开头的指令会在建立中运行，好比安装一个软件包，在这里使用 apt-get 来安装了一些软件

构建镜像的步骤

1.新建一个目录和一个 Dockerfile

$ mkdir new_folder
$ cd new_folder
$ touch Dockerfile

　　

# 这里是注释2.编写Dockerfile，Dockerfile中每一条指令都建立镜像的一层，例如：

# 设置继承自哪一个镜像
FROM ubuntu:14.04
# 下面是一些建立者的基本信息
MAINTAINER birdben (191654006@163.com)
# 在终端须要执行的命令
RUN apt-get install -y openssh-server RUN mkdir -p /var/run/sshd

　　

3.编写完成 Dockerfile 后可使用 docker build 来生成镜像。

$ sudo docker build -t="birdben/ubuntu:v1" .
# 下面是一堆构建日志信息
 
############
我是日志
############
 
# 参数：
# -t 标记来添加 tag，指定新的镜像的用户和镜像名称信息。
# “.” 是 Dockerfile 所在的路径（当前目录），也能够替换为一个具体的 Dockerfile 的路径。
 
# 以交互方式运行docker
$ docker run -it birdben/ubuntu:v1 /bin/bash
 
# 运行docker时指定配置
$ sudo docker run -d -p 10.211.55.4:9999:22 ubuntu:tools '/usr/sbin/sshd' -D
 
# 参数：
# -i：表示以“交互模式”运行容器，-i 则让容器的标准输入保持打开
# -t：表示容器启动后会进入其命令行，-t 选项让Docker分配一个伪终端（pseudo-tty）并绑定到容器的标准输入上
# -v：表示须要将本地哪一个目录挂载到容器中，格式：-v <宿主机目录>:<容器目录>，-v 标记来建立一个数据卷并挂载到容器里。在一次 run 中屡次使用能够挂载多个数据卷。
# -p：指定对外80端口
# 不必定要使用“镜像 ID”，也可使用“仓库名:标签名”

镜像构建上下文（Context）
若是注意，会看到 docker build 命令最后有一个 .。. 表示当前目录，而 Dockerfile 就在当前目录，所以很多初学者觉得这个路径是在指定 Dockerfile 所在路径，这么理解实际上是不许确的。若是对应上面的命令格式，你可能会发现，这是在指定上下文路径。那么什么是上下文呢？

首先咱们要理解 docker build 的工做原理。Docker 在运行时分为 Docker 引擎（也就是服务端守护进程）和客户端工具。Docker 的引擎提供了一组 REST API，被称为 Docker Remote API，而如 docker 命令这样的客户端工具，则是经过这组 API 与 Docker 引擎交互，从而完成各类功能。所以，虽然表面上咱们好像是在本机执行各类 docker 功能，但实际上，一切都是使用的远程调用形式在服务端（Docker 引擎）完成。也由于这种 C/S 设计，让咱们操做远程服务器的 Docker 引擎变得垂手可得。

当咱们进行镜像构建的时候，并不是全部定制都会经过 RUN 指令完成，常常会须要将一些本地文件复制进镜像，好比经过 COPY 指令、ADD 指令等。而 docker build 命令构建镜像，其实并不是在本地构建，而是在服务端，也就是 Docker 引擎中构建的。那么在这种客户端/服务端的架构中，如何才能让服务端得到本地文件呢？

这就引入了上下文的概念。当构建的时候，用户会指定构建镜像上下文的路径，docker build 命令得知这个路径后，会将路径下的全部内容打包，而后上传给 Docker 引擎。这样 Docker 引擎收到这个上下文包后，展开就会得到构建镜像所需的一切文件。

若是在 Dockerfile 中这么写：

COPY ./package.json /app/
这并非要复制执行 docker build 命令所在的目录下的 package.json，也不是复制 Dockerfile 所在目录下的 package.json，而是复制 上下文（context） 目录下的 package.json。

所以，COPY 这类指令中的源文件的路径都是相对路径。这也是初学者常常会问的为何 COPY ../package.json /app 或者 COPY /opt/xxxx /app 没法工做的缘由，由于这些路径已经超出了上下文的范围，Docker 引擎没法得到这些位置的文件。若是真的须要那些文件，应该将它们复制到上下文目录中去。

如今就能够理解刚才的命令 docker build -t nginx:v3 . 中的这个 .，其实是在指定上下文的目录，docker build 命令会将该目录下的内容打包交给 Docker 引擎以帮助构建镜像。

若是观察 docker build 输出，咱们其实已经看到了这个发送上下文的过程：

$ docker build -t nginx:v3 .
Sending build context to Docker daemon 2.048 kB
...
理解构建上下文对于镜像构建是很重要的，避免犯一些不该该的错误。好比有些初学者在发现 COPY /opt/xxxx /app 不工做后，因而干脆将 Dockerfile 放到了硬盘根目录去构建，结果发现 docker build 执行后，在发送一个几十 GB 的东西，极为缓慢并且很容易构建失败。那是由于这种作法是在让 docker build 打包整个硬盘，这显然是使用错误。

通常来讲，应该会将 Dockerfile 置于一个空目录下，或者项目根目录下。若是该目录下没有所需文件，那么应该把所需文件复制一份过来。若是目录下有些东西确实不但愿构建时传给 Docker 引擎，那么能够用 .gitignore 同样的语法写一个 .dockerignore，该文件是用于剔除不须要做为上下文传递给 Docker 引擎的。

那么为何会有人误觉得 . 是指定 Dockerfile 所在目录呢？这是由于在默认状况下，若是不额外指定 Dockerfile 的话，会将上下文目录下的名为 Dockerfile 的文件做为 Dockerfile。

这只是默认行为，实际上 Dockerfile 的文件名并不要求必须为 Dockerfile，并且并不要求必须位于上下文目录中，好比能够用 -f ../Dockerfile.php 参数指定某个文件做为 Dockerfile。

固然，通常你们习惯性的会使用默认的文件名 Dockerfile，以及会将其置于镜像构建上下文目录中。

镜像构建上下文

 

Docker的网络功能相对简单，没有过多复杂的配置，Docker默认使用birdge桥接方式与容器通讯，启动Docker后，宿主机上会产生docker0这样一个虚拟网络接口， docker0不是一个普通的网络接口， 它是一个虚拟的以太网桥，能够为绑定到docker0上面的网络接口自动转发数据包，这样可使容器与宿主机之间相互通讯。每次Docker建立一个容器，会产生一对虚拟接口，在宿主机上执行ifconfig，会发现多了一个相似veth**这样的网络接口，它会绑定到docker0上，因为全部容器都绑定到docker0上，容器之间也就能够通讯。Docker网络

在宿主机上执行ifconfig，会看到docker0这个网络接口， 启动一个container，再次执行ifconfig, 会有一个相似veth**的interface，每一个container的缺省路由是宿主机上docker0的ip，在container中执行netstat -r能够看到以下图所示内容：
container路由

在容器中使用netstat -r命令查看容器的IP地址

容器中的默认网关跟docker0的地址是同样的：

在宿主机中使用ifconfig查看docker0的IP地址

docker0
当容器退出以后，veth*虚拟接口也会被销毁。

 

转载自：https://birdben.github.io/2015/11/17/Docker/Docker%E5%AE%9E%E6%88%98%EF%BC%88%E4%BA%8C%EF%BC%89%E5%88%B6%E4%BD%9C%E8%87%AA%E5%B7%B1%E7%9A%84Docker%E9%95%9C%E5%83%8F/