清理docker瘦身编译

⑴ 编译docker怎么运行docker.service

本文根据docker官方给出的docker代码编译环境搭建指南做更深入的分析。官方给出的指导比较简单，但是由于国内的网络问题经常会编译失败，了解了编译步骤后，也可以结合自身遇到的网络问题进行“规避”。 docker的编译环境实际上是创建一个docker容...

⑵ 如何在"特殊"的网络环境下编译 Docker

由于 Docker 编译需要依赖于 Docker Daemon ，所以只能在 64 位的 linux 环境下先安装 Docker 程序，再从 Github 上克隆 Docker 的代码进行编译。
在 Docker 的目录下执行 make 命令将默认执行 Makefile 中 make binary 指令进行编译。
?

default: binary

all: build
$(DOCKER_RUN_DOCKER) hack/make.sh

binary: build
$(DOCKER_RUN_DOCKER) hack/make.sh binary

cross: build
$(DOCKER_RUN_DOCKER) hack/make.sh binary cross

从以上的 Makefile 可以看出，执行 make、make binary、make all 或 make cross 都可以得到可运行的 Docker 程序。
在 Mac OS 环境下使用 brew 的命令安装 Docker ，只能得到一个 docker client 的二进制程序，如果以 daemon 的方式运行，会得到 ‘This is a client-only binary - running the Docker daemon is not supported.’ 的错误提示信息。
方法 1.
使用 VirtualBox 或者 VMWare Workstation 安装一个 Linux 的虚拟机。宿主机使用 VPN 等方案使网络“正常”访问各种“服务”，虚拟机网卡使用 NAT 模式。在 Linux 虚拟机内使用 make 进行编译 Docker 不会有任何网络问题。只是编译速度受限于 VPN 等网络解决方案，有可能等待时间很长。
方法 2.
Docker 每次发布新版本，都会在 docker-dev 的镜像仓库发布一个新的标签，这个镜像仓库包含了编译 Docker 镜像所依赖的所有环境，只需替换 Docker 代码目录下的 Dockerfile 即可实现编译 Docker 。
?

FROM docker.cn/docker/docker-dev:v1.2.0
VOLUME /var/lib/docker
WORKDIR /go/src/github.com/docker/docker
ENV DOCKER_BUILDTAGS apparmor selinux
ENTRYPOINT [“hack/dind”]
COPY . /go/src/github.com/docker/docker

Dockerfile 中只保留必要的步骤就可以实现编译了。
方法 3.
对 Docker 代码中的 Docker 进行彻底的改造，用国内的各种镜像替换其中不能在“正常”网络条件下访问的镜像，使得代码能够快速编译通过。
?

FROM docker.cn/docker/ubuntu:14.04.1
MAINTAINER Meaglith Ma <[email protected]> (@genedna)

RUN echo "deb http://mirrors.aliyun.com/ubuntu trusty main universe" > /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty main restricted" >> /etc/apt/sources.list && echo "deb http://mirrors.aliyun.com/ubuntu/ trusty-updates main restricted" >> /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty-updates main restricted" >> /etc/apt/sources.list && echo "deb http://mirrors.aliyun.com/ubuntu/ trusty universe" >> /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty universe" >> /etc/apt/sources.list && echo "deb http://mirrors.aliyun.com/ubuntu/ trusty-updates universe" >> /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty-updates universe" >> /etc/apt/sources.list && echo "deb http://mirrors.aliyun.com/ubuntu/ trusty-security main restricted" >> /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty-security main restricted" >> /etc/apt/sources.list && echo "deb http://mirrors.aliyun.com/ubuntu/ trusty-security universe" >> /etc/apt/sources.list && echo "deb-src http://mirrors.aliyun.com/ubuntu/ trusty-security universe" >> /etc/apt/sources.list

RUN apt-get update && apt-get install -y \
aufs-tools \
automake \
btrfs-tools \
build-essential \
curl \
dpkg-sig \
git \
iptables \
libapparmor-dev \
libcap-dev \
libsqlite3-dev \
lxc=1.0* \
mercurial \
parallel \
reprepro \
ruby1.9.1 \
ruby1.9.1-dev \
s3cmd=1.1.0* \
unzip \
--no-install-recommends

RUN git clone --no-checkout https://coding.net/genedna/lvm2.git /usr/local/lvm2 && cd /usr/local/lvm2 && git checkout -q v2_02_103

RUN cd /usr/local/lvm2 && ./configure --enable-static_link && make device-mapper && make install_device-mapper

RUN curl -sSL http://docker-cn.qiniudn.com/go1.3.1.src.tar.gz | tar -v -C /usr/local -xz
ENV PATH /usr/local/go/bin:$PATH
ENV GOPATH /go:/go/src/github.com/docker/docker/vendor
ENV PATH /go/bin:$PATH
RUN cd /usr/local/go/src && ./make.bash --no-clean 2>&1

ENV DOCKER_CROSSPLATFORMS \
linux/386 linux/arm \
darwin/amd64 darwin/386 \
freebsd/amd64 freebsd/386 freebsd/arm
ENV GOARM 5
RUN cd /usr/local/go/src && bash -xc 'for platform in $DOCKER_CROSSPLATFORMS; do GOOS=${platform%/*} GOARCH=${platform##*/} ./make.bash --no-clean 2>&1; done'

RUN mkdir -p /go/src/github.com/gpmgo \
&& cd /go/src/github.com/gpmgo \
&& curl -o gopm.zip http://gopm.io/api/v1/download?pkgname=github.com/gpmgo/gopm\&revision=dev --location \
&& unzip gopm.zip \
&& mv $(ls | grep "gopm-") gopm \
&& rm gopm.zip \
&& cd gopm \
&& go install

RUN gopm bin -v code.google.com/p/go.tools/cmd/cover

RUN gem sources --remove https://rubygems.org/ \
&& gem sources -a https://ruby.taobao.org/ \
&& gem install --no-rdoc --no-ri fpm --version 1.0.2

RUN gopm bin -v -d /go/bin github.com/cpuguy83/go-md2man@tag:v1

RUN git clone -b buildroot-2014.02 https://github.com/jpetazzo/docker-busybox.git /docker-busybox

RUN /bin/echo -e '[default]\naccess_key=$AWS_ACCESS_KEY\nsecret_key=$AWS_SECRET_KEY' > /.s3cfg

RUN git config --global user.email '[email protected]'

RUN groupadd -r docker
RUN useradd --create-home --gid docker unprivilegeser

VOLUME /var/lib/docker
WORKDIR /go/src/github.com/docker/docker
ENV DOCKER_BUILDTAGS apparmor selinux

ENTRYPOINT ["hack/dind"]

COPY . /go/src/github.com/docker/docker

以上的命令把 Ubuntu 镜像中的源替换为国内速度较快的阿里源；把 lvm2 镜像到国内的 Git 托管服务 coding.net；从 七牛云存储 保存的 Golang 源码进行获取和编译；使用 gopm 下载编译所需要的 Library ；最后把其中 gem 源切换到淘宝。至此，可以在“特殊”的网络条件下快速编译 Docker 。

⑶ 如何通过 alpine linux 让 docker 瘦身 7 倍

Docker 是一个开源工具，它可以让创建和管理 Linux 容器变得简单。容器就像是轻量级的虚拟机，并且可以以毫秒级的速度来启动或停止。Docker 帮助系统管理员和程序员在容器中开发应用程序，并且可以扩展到成千上万的节点。
容器和 VM（虚拟机）的主要区别是，容器提供了基于进程的隔离，而虚拟机提供了资源的完全隔离。虚拟机可能需要一分钟来启动，而容器只需要一秒钟或更短。容器使用宿主操作系统的内核，而虚拟机使用独立的内核。
Docker 的局限性之一是，它只能用在 64 位的操作系统上。

⑷ Docker的主要作用是什么

目前来看，Docker至少有以下应用场景：

1）测试：Docker 很适合用于测试发布，将 Docker 封装后可以直接提供给测试人员进行运行，不再需要测试人员与运维、开发进行配合，进行环境搭建与部署。

2）测试数据分离：在测试中，经常由于测试场景变换，需要修改依赖的数据库数据或者清空变动 memcache、Redis 中的缓存数据。Docker 相较于传统的虚拟机，更轻量与方便。可以很容易的将这些数据分离到不同的镜像中，根据不同需要随时进行切换。

3）开发：开发人员共同使用同一个 Docker 镜像，同时修改的源代码都被挂载到本地磁盘。不再因为环境的不同而造成的不同程序行为而伤透脑筋，同时新人到岗时也能迅速建立开发、编译环境。

4）PaaS 云服务：Docker 可以支持命令行封装与编程，通过自动加载与服务自发现，可以很方便的将封装于 Docker 镜像中的服务扩展成云服务。类似像 Doc 转换预览这样的服务封装于镜像中，根据业务请求的情况随时增加和减少容器的运行数量，随需应变。

具体到Docker技术在测试领域的应用，可以体现在：

1）快速搭建兼容性测试环境

从Docker的镜像与容器技术特点可以预见，当被测应用要求在各类Web服务器、中间件、数据库的组合环境中得到充分验证时，可以快速地利用基础Docker镜像创建各类容器，装载相应的技术组件并快速启动运行，测试人员省去了大量花在测试环境搭建上的时间。

2）快速搭建复杂分布式测试环境

Docker的轻量虚拟化特点决定了它可以在一台机器上（甚至是测试人员的一台笔记本电脑上）轻松搭建出成百上千个分布式节点的容器环境，从而模拟以前需要耗费大量时间和机器资源才能搭建出来的分布式复杂测试环境。

3）持续集成

Docker可以快速创建和撤销容器，在持续集成的环境中，可以频繁和快速地进行部署和验证工作。

⑸ 谁可以简单介绍一下docker到底是干什么用的

参考sf上好雨科技的回答：
docker主要有2大核心贡献和对于软件交付的影响：
2大贡献：
1、封装，将运行环境与代码封装到一个盒子中
2、镜像仓库，将镜像以类似代码仓库的方式分发

软件交付的影响：作为一个IT界“集装箱” 它把整个软件交付的流程和方式都改变了，就相当于 集装箱 一样改变了整个航运、空运、陆运的方式，让生产者产出的产品到最终用户完全一致，无论中途经过多少过程。有了这个核心的“集装箱” 整个生态都围着它打转。

⑹ 如何编译docker 1.2.0版本的源码

经过研究docker的官方编译脚步，发现本地编译也很简单，只需要在docker源码的目录下执行如下命令即可：
./hack/make.sh binary
上面这条命令就只会生成docker的二进制文件，不过肯定不会这么顺利的，执行这个命令你就会发现错误。如果第一次执行报的错误应该是找不到相应的go依赖包。那么现在就开始解决第一个问题，go依赖包。
解决go依赖包最直接的方法就一个一个去github或者其他地方去下载到本地，但是这样做很麻烦，docker依赖的go语言包很多，然后依赖包可能又依赖其他包。这里有一个简单实用的办法，也是go语言管理项目的方便之处。通过go get命令来自动下载，例如发现报错的是docker某一个目录下的依赖包，那么可以如下执行：
go get -v ./src/github.com/docker/docker/...
这条命令执行以后整个docker目录下源文件依赖的包都会被自动下载。如果发现其他目录下源文件也报同样的错误，可以按照次方法解决。不过这里需要强调一点， 这些下载都是会下载最新的包，如果编译老的docker肯定会出问题 ，如果编译最新的docker代码肯定不会有问题，因为官方的编译是这种方式。
上面执行的命令都是建立在go语言环境建立成功的基础上，我安装的go遇到是1.3.3版本的，采用源码方式安装。安装在/export/servers/go下面，然后所有的go语言工程源码目录放在 /export/servers/gopath。然后配置环境变量在用户的根目录下的.bashrc文件里面如下：
export GOPATH=/export/servers/gopath
export GOROOT=/export/servers/go
export GOARCH=amd64
export GOOS=linux
然后docker的代码目录如下：/export/servers/gopath/src/github.com/docker/docker。这样才能在gopath下面进行依赖包的下载。通过上面的方法把所有依赖包下载完以后就可以进行编译了。
在继续编译的过程中还会遇到缺少c语言依赖包缺少的问题，主要有三个，（1）sqlite3;（2）device-mapper;（3）btrfs.
第一个sqlite3可以使用如下命令安装依赖：yum install sqlite-devel.x86_64

⑺ 如何使用Docker 进行java 开发

1、java项目开发，假定已有一个java项目能够编译成jar/war并且运行了。

2、编写dockerfile，docker是一个容器技术每一个容器就是一个“完整”的linux系统，这个dockerfile需要提供这个系统包含内容的描述，比如FROM maven:3.3.3、FROM ubuntu:16.04。如果这个java项目是个web项目那么还需要提供tomcat环境。添加项目构建信息。比如采用maven编译项目的话该如何如何。

ADDpom.xml/tmp/build/
RUNcd/tmp/build&&mvn-qdependency:resolve

ADDsrc/tmp/build/src
#构建应用RUNcd/tmp/build&&mvn-q-DskipTests=truepackage
#拷贝编译结果到指定目录
&&rm-rf$CATALINA_HOME/webapps/*
&&mvtarget/*.war$CATALINA_HOME/webapps/ROOT.war
#清理编译痕迹
&&cd/&&rm-rf/tmp/build

3、暴漏接口：EXPOSE 8080
CMD ["catalina.sh","run"]

4、执行镜像构建

dockerbuild-tdocker-demo-java-tomcat.

5、基于创建好的镜像创建容器

dockerrun-d-p8080:8080docker-demo-java-tomcat

6、访问

http://127.0.0.1:8080/demo

来源于dockercloud文档，可自去查看。

⑻ 如何有效地压缩镜像体积并缩短构建时间

时至今日，大家已经能够从多种Docker支持的存储驱动程序中做出选择，从而确保其与我们的实际环境以及用例切实吻合——然而，除非深入理解镜像层(更不用提镜像与容器本身)，否则一般用户根本不会考虑这方面问题。很明显，这些简单而且缺乏吸引力的技术元素层虽然是构成镜像的基本条件，但却往往得不到高度关注——因为闪亮的新型工具往往比基本信息更能抓人眼球。

在今天的文章中，我们将探讨镜像体积及构建时间方面的话题——而这两项工作也已经成为用户们迫切需要实现的目标。
让我们首先着眼于镜像与层，对其概念加以阐述：
Docker镜像是一套由只读层外加部分元数据构成的标签化结构。
每个层都拥有自己的UUID，而且每个连续层都建立在其下的层之上。
每个Dockerfile指令都会生成一个新层。
看起来基本理念非常简单，且不需要再做过多解释，不过我曾经遇上过这样一个让人如坠雾里的Dockerfile：
FROM centos:7.1.1503
RUN yum -y install java-1.8.0-openjdk-devel-1:1.8.0.65-2.b17.el7_1.x86_64
RUN yum clean all
这个Dockerfile到底出了什么问题?这个嘛，其中第二个RUN命令并没能真正影响到镜像体积——虽然它看起来确实应该有效削减镜像大小。让我们重新审视Docker镜像与层的定义，并着重强调其中的语法表达：
Docker镜像是一套由只读层外加部分元数据构成的标签化结构。
每个层都拥有自己的UUID，而且每个连续层都建立在其下的层之上。
每个Dockerfile指令都会生成一个新层。
现在，可以明确看到该Dockerfile并没能优化镜像体积。无论如何，让我们进行深入探讨，看看这些yum缓存是如何被从镜像层当中移除出去的。
不过为了保证文章浅显易懂的特性，我们首先将关注范畴限定在AUFS存储驱动程序身上。AUFS存储驱动程序能够添加一个疏排文件以覆盖镜像中底部只读层内文件的存在，从而将其从层内删除出去。除此之外，大家可以推断出镜像的大小相当于各层体积的总和，而添加到Dockerfile中的每条附加指令都会进一步增加镜像的体积。
只要将两项RUN指令加以合并，我们就能轻松对上面提到的Dockfile进行修复：
FROM centos:7.1.1503
RUN yum -y install java-1.8.0-openjdk-devel-1:1.8.0.65-2.b17.el7_1.x86_64 &&
yum clean all
下面让我们构建并检查这两套镜像以证明其瘦身效果。大家需要执行docker build -t 以在Dockerfile所容纳的目录当中构建一套镜像。在此之后，我们会发现两套镜像的体积有所不同：
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
combined-layers latest defa7a199555 4 seconds ago 407 MB
separate-layers latest b605eff36c7b About a minute ago 471.8 MB
大家应该能够轻松判断哪套镜像是通过哪个Dockerfile构建而成，但让我们进一步查看两套镜像各自包含的层：
$ docker history --no-trunc separate-layers
IMAGE CREATED CREATED BY SIZE
2 minutes ago /bin/sh -c yum clean all 2.277 MB
2 minutes ago /bin/sh -c yum -y install java-1.8.0-openjdk-devel-1:1.8.0.65-2.b17.el7_1.x86_64 257.5 MB
8 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
8 weeks ago /bin/sh -c #(nop) ADD file: in / 212.1 MB
7 months ago /bin/sh -c #(nop) MAINTAINER The CentOS Project - ami_creator 0 B
$ docker history --no-trunc combined-layers
IMAGE CREATED CREATED BY SIZE
48 seconds ago /bin/sh -c yum -y install java-1.8.0-openjdk-devel-1:1.8.0.65-2.b17.el7_1.x86_64 && yum clean all 195 MB
8 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
8 weeks ago /bin/sh -c #(nop) ADD file: in / 212.1 MB
7 months ago /bin/sh -c #(nop) MAINTAINER The CentOS Project - ami_creator 0 B
这清楚地表明链式命令能帮助我们在对各层进行提交前进行清理工作，不过这并不意味着我们应当将一切都塞进单一层当中。如果大家重新审视以上命令的输出结果，就会发现两套镜像的3个最底层拥有着同样的UUID，这意味着两套镜像共享这些层(有鉴于此，docker images命令才能够报告各镜像的虚拟体积)。
有人可能会说，如今磁盘空间的使用成本已经如此低廉，我们真的有必要如此纠结于所谓镜像体积吗?但除了缓存镜像层之外，大家还有其它方面需要关注。其中最重要的一点在于镜像的构建时间。简单来讲，如果大家能够复用某个层，则无需对其进行重新构建。另外，如果大家的镜像需要通过网络进行传输(例如在流程中分阶段进行构建推进)，那么更为袖珍的镜像体积与缓存层运用能够显着节约传输时长(并降低网络流量负载)，因为需要实际传输的镜像层中有相当一部分已经被整合在新版本镜像当中。
现在结论已经显而易见，大家应当尽可能减少Dockerfile顶层的指令数量，从而提高缓存复用比例并努力着眼于底层对Dockerfile进行变更。
考虑到以上各项因素，有些朋友可以认为优化程度最高的解决方案应当是将全部发生变更的元素塞进各自不同的层当中，从而清理每个层的执行流程; 但一般来讲，这种作法并不会简化工作负担。首先，Docker对层数做出了限制，即不可超过127个，而且大家最好与上限之间保持一定距离。包含有大量层的Dockerfile既不易于后期维护，也不太可能排除那些不必要的数据; 相反，其结果是我们会面对一套非常臃肿的镜像，且最好将其拆分成多个不同镜像。而更重要的是，层的实现并非毫无成本，具体取决于我们使用的存储驱动程序，由此造成的额外负担也有所区别。举例来说，在AUFS当中，每个层都会在面向镜像层堆栈中各现有文件的首次写入时给容器写入性能造成延迟，特别在文件体积庞大且存在于大量镜像层之下的情况当中。
因此在文章最后，我们需要再次强调：要想切实提升镜像体积优化效果并压缩构建时间，大家必须了解自己想要优化什么，并有意识地做出必要妥协。
1. 如果大家需要了解或者深入掌握容器中的层概念，请点击此处查看Docker说明文档。
2. 查看存储驱动程序说明文档以了解与其性能表现相关的各项细节信息。
3. 如果大家发现自己需要处理高强度写入工作负载，可以考虑使用数据分卷(它们会绕开存储驱动程序)。