清理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. 如果大家發現自己需要處理高強度寫入工作負載，可以考慮使用數據分卷(它們會繞開存儲驅動程序)。