分类目录归档：linux资料

搭建docker内网私服

linux资料

主要思路：
docker-registry-deploy

1. Docker Registry 说明

关于如何创建和使用本地仓库，其实已经有很多文章介绍了。因为docker技术正处于发展和完善阶段，所以有些文章要么内容已经过时，要么给出了错误的配置，导致无法正常创建仓库。本文记录的是个人完整的搭建过程，docker version为1.1.2。

官方提供了Docker Hub网站来作为一个公开的集中仓库。然而，本地访问Docker Hub速度往往很慢，并且很多时候我们需要一个本地的私有仓库只供网内使用。

Docker仓库实际上提供两方面的功能，一个是镜像管理，一个是认证。前者主要由docker-registry项目来实现，通过http服务来上传下载；后者可以通过docker-index（闭源）项目或者利用现成认证方案（如nginx）实现http请求管理。

docker-registry既然也是软件应用，自然最简单的方法就是使用官方提供的已经部署好的镜像registry。官方文档中也给出了建议，直接运行sudo docker run -p 5000:5000 registry命令。这样确实能启动一个registry服务器，但是所有上传的镜像其实都是由docker容器管理，放在了/var/lib/docker/….某个目录下。而且一旦删除容器，镜像也会被删除。因此，我们需要想办法告诉docker容器镜像应该存放在哪里。registry镜像中启动后镜像默认位置是/tmp/registry，因此直接映射这个位置即可，比如到本机的/opt/data/registry目录下。

 

2. 在CentOS上搭建docker私服

2.1 安装docker-registry

方法有多种，直接运行下面的命令：

1
# docker run -d -e SETTINGS_FLAVOR=dev -e STORAGE_PATH=/tmp/registry -v /opt/data/registry:/tmp/registry -p 5000:5000 registry

如果本地没有拉取过docker-registry，则首次运行会pull registry，运行时会映射路径和端口，以后就可以从/opt/data/registry下找到私有仓库都存在哪些镜像，通过主机的哪个端口可以访问。
你也可以把项目 https://github.com/docker/docker-registry.git 克隆到本地，然后使用Dockerfile来build镜像：

1
2
3
4
5
6
7
8
9
10
11
12
13
# git clone https://github.com/docker/docker-registry.git
# cd docker-registry && mkdir -p /opt/data/registry
# docker build -t "local-sean" .
build完成后，就可以运行这个docker-registry
我们先配置自己的config.yml文件，第一种方法是直接在run的时候指定变量
# cp config/config_sample.yml /opt/data/registry/config.yml
# vi /opt/data/registry/config.yml
##这里可以设置本地存储SETTINGS_FLAVOR=dev，local STORAGE_PATH:/tmp/registry等待
# docker run -d -v /opt/data/registry:/tmp/registry -p 5000:5000 -e DOCKER_REGISTRY_CONFIG=/tmp/registry/config.yml registry
或
docker run -d -e SETTINGS_FLAVOR=dev -e STORAGE_PATH=/tmp/registry -v /db/docker-images:/tmp/registry -p 5000:5000 registry

2.2 客户端使用

要从私服上获取镜像或向私服提交镜像，现在变得非常简单，只需要在仓库前面加上私服的地址和端口，形如172.29.88.222:5000/centos6。注意，这里可以选择不使用IP，而是用hostname，如registry.domain.com:5000，但不能仅用不带.的主机名registry，docker会认为registry是用户名，建议使用带域名的hostname加port来表示。

于是在另外一台要使用docker的主机上就可以通过这台私服拉取和推送镜像了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
从私服上搜索存在哪些可用镜像
# curl -X GET http://sean.domain.com:5000/v1/search
{"num_results": 2, "query": "", "results": [{"description": "", "name": "library/centos6"}, {"description": "", "name": "library/nginx"}]}
按条件搜索nginx
# curl -X GET http://sean.domain.com:5000/v1/search?q=centos6
拉取image到本地
docker pull library/centos6
## 本地对份镜像启动起来，形成container
## 给container去另外一个名字
# docker tag 68edf809afe7 registry.domain.com:5000/centos6-test
## 最后将新的docker images推送到私服上
docker push registry.domain.com:5000/centos6-test

第一次push到私服上时会提示用户名、密码和邮箱，创建即可。也可以在docker私服端加入认证机制。

3. 加入nginx认证

（请在实际操作以前，先阅读完本节，再确定是否在前端加入nginx）

3.1 安装及配置nginx

从上面的过程可以看到，除非防火墙限制，否则任何主机可以创建账号并想私服推送镜像，更安全的做法是在外层加入登录认证机制。

1
2
3
4
5
6
7
8
9
10
最好安装1.4.x版本，不然下面的有些配置可能会不兼容
# yum install nginx
创建两个登录用户
# htpasswd -c /etc/nginx/docker-registry.htpasswd sean
New password:
Re-type new password:
Adding password for user sean
# htpasswd /etc/nginx/docker-registry.htpasswd itsection

为了让nginx使用这个密码文件，并且转发8080端口的请求到Docker Registry，新增nginx配置文件
vi /etc/nginx/sites-enabled/docker-registry：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# For versions of Nginx > 1.3.9 that include chunked transfer encoding support
# Replace with appropriate values where necessary
upstream docker-registry {
server localhost:5000;
}
server {
listen 8080;
server_name sean.domain.com; -- your registry server_name
# ssl on;
# ssl_certificate /etc/ssl/certs/docker-registry;
# ssl_certificate_key /etc/ssl/private/docker-registry;
proxy_set_header Host $http_host; # required for Docker client sake
proxy_set_header X-Real-IP $remote_addr; # pass on real client IP
client_max_body_size 0; # disable any limits to avoid HTTP 413 for large image uploads
# required to avoid HTTP 411: see Issue #1486 (https://github.com/dotcloud/docker/issues/1486)
chunked_transfer_encoding on;
location / {
# let Nginx know about our auth file
auth_basic "Restricted";
auth_basic_user_file docker-registry.htpasswd;
proxy_pass http://docker-registry;
}
location /_ping {
auth_basic off;
proxy_pass http://docker-registry;
}
location /v1/_ping {
auth_basic off;
proxy_pass http://docker-registry;
}
}
1
2
3
4
让nginx来使用这个virtual-host
# ln -s /etc/nginx/sites-enabled/docker-registry /etc/nginx/conf.d/docker-registry.conf
重启nginx来激活虚拟主机的配置
# service nginx restart

3.2 加入认证后使用docker-registry

此时主机的5000端口应该通过防火墙禁止访问（或者在docker run端口映射时只监听回环接口的IP -p 127.0.0.1:5000:5000）。

1
2
# curl localhost:5000
"docker-registry server (dev) (v0.8.1)"

如果直接访问访问将得到未授权的信息：

1
2
3
4
5
6
7
8
# curl localhost:8080
<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.4.7</center>
</body>
</html>

带用户认证的docker-registry：

1
2
3
4
5
6
7
8
9
10
# curl http://sean:sean@sean.domain.com:8080/v1/search
{"num_results": 2, "query": "", "results": [{"description": "", "name": "library/centos6"}, {"description": "", "name": "library/nginx"}]}
# docker login registry.domain.com:8080
Username: sean
Password:
Email: zhouxiao@domain.com
Login Succeeded
# docker pull registry.domain.com:8080/library/centos6

不出意外的话，上面的docker pull会失败：

1
2
3
4
5
6
7
8
9
10
11
12
13
# docker pull registry.domain.com:8080/library/centos6
Pulling repository registry.domain.com:8080/library/centos6
2014/11/11 21:00:25 Could not reach any registry endpoint
# docker push registry.domain.com:8080/ubuntu:sean
The push refers to a repository [registry.domain.com:8080/ubuntu] (len: 1)
Sending image list
Pushing repository registry.domain.com:8080/ubuntu (1 tags)
2014/11/12 08:11:32 HTTP code 401, Docker will not send auth headers over HTTP.
nginx日志
2014/11/12 07:03:49 [error] 14898#0: *193 no user/password was provided for basic
authenticatGET /v1/repositories/library/centos6/tags HTTP/1.1", host: "registry.domain.com:8080"

本文后的第1篇参考文档没有出现这个问题，但评论中有提及。
有人说是backend storage的问题，这里是本地存储镜像，不应该。经过查阅大量资料，并反复操作验证，是docker-registry版本的问题。从v0.10.0开始，docker login虽然Succeeded，但pull或push的时候，~/.dockercfg下的用户登录信息将不允许通过HTTP明文传输。（如果你愿意可以查看v0.10.0的源码 registry.go，在分支v0.9.1及以前是没有HTTP code 401, Docker will not send auth headers over HTTP的）
目前的办法三个：

  • 撤退，这就是为什么先说明在操作前线查看到这的原因了
  • 换成v0.9.1及以下版本。现在都v1.3.1了，我猜你不会这么做
  • 修改源码session.go，去掉相应的判断行，然后git下来重新安装。我猜你更不会这么做
  • 安装SSL证书，使用HTTPS传输。这是明智的选择，新版本docker也推荐我们这么做，往下看。

3.3 为nginx安装ssl证书

首先打开nginx配置文件中ssl的三行注释

1
2
3
4
5
6
7
8
9
10
11
# vi /etc/nginx/conf.d/docker-registry.conf
...
server {
listen 8000;
server_name registry.domain.com;
ssl on;
ssl_certificate /etc/nginx/ssl/nginx.crt;
ssl_certificate_key /etc/nginx/ssl/nginx.key;
...

保存之后，nginx会分别从/etc/nginx/ssl/nginx.crt和/etc/nginx/ssl/nginx.key读取ssl证书和私钥。如果你自己愿意花钱买一个ssl证书，那就会变得非常简单，把证书和私钥拷贝成上面一样即可。关于SSL以及签署ssl证书，请参考其他文章。
这里我们自签署一个ssl证书，把当前系统作为（私有）证书颁发中心（CA）。

创建存放证书的目录

1
# mkdir /etc/nginx/ssl

确认CA的一些配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# vi /etc/pki/tls/openssl.cnf
...
[ CA_default ]
dir = /etc/pki/CA # Where everything is kept
certs = $dir/certs # Where the issued certs are kept
crl_dir = $dir/crl # Where the issued crl are kept
database = $dir/index.txt # database index file.
#unique_subject = no # Set to 'no' to allow creation of
# several ctificates with same subject.
new_certs_dir = $dir/newcerts # default place for new certs.
certificate = $dir/cacert.pem # The CA certificate
serial = $dir/serial # The current serial number
crlnumber = $dir/crlnumber # the current crl number
# must be commented out to leave a V1 CRL
crl = $dir/crl.pem # The current CRL
private_key = $dir/private/cakey.pem # The private key
RANDFILE = $dir/private/.rand # private random number file
...
default_days = 3650 # how long to certify for
...
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = CN
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = GD
...[ req_distinguished_name ]部分主要是颁证时一些默认的值，可以不动

(1) 生成根密钥

1
2
# cd /etc/pki/CA/
# openssl genrsa -out private/cakey.pem 2048

为了安全起见，修改cakey.pem私钥文件权限为600或400，也可以使用子shell生成( umask 077; openssl genrsa -out private/cakey.pem 2048 )，下面不再重复。

(2) 生成根证书

1
# openssl req -new -x509 -key private/cakey.pem -out cacert.pem

会提示输入一些内容，因为是私有的，所以可以随便输入，最好记住能与后面保持一致。上面的自签证书cacert.pem应该生成在/etc/pki/CA下。

(3) 为我们的nginx web服务器生成ssl密钥

1
2
# cd /etc/nginx/ssl
# openssl genrsa -out nginx.key 2048

我们的CA中心与要申请证书的服务器是同一个，否则应该是在另一台需要用到证书的服务器上生成。

(4) 为nginx生成证书签署请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# openssl req -new -key nginx.key -out nginx.csr
...
Country Name (2 letter code) [AU]:CN
State or Province Name (full name) [Some-State]:GD
Locality Name (eg, city) []:SZ
Organization Name (eg, company) [Internet Widgits Pty Ltd]:COMPANY
Organizational Unit Name (eg, section) []:IT_SECTION
Common Name (e.g. server FQDN or YOUR name) []:your.domain.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
...

同样会提示输入一些内容，其它随便，除了Commone Name一定要是你要授予证书的服务器域名或主机名，challenge password不填。

(5) 私有CA根据请求来签发证书

1
# openssl ca -in nginx.csr -out nginx.crt

上面签发过程其实默认使用了-cert cacert.pem -keyfile cakey.pem，这两个文件就是前两步生成的位于/etc/pki/CA下的根密钥和根证书。

到此我们已经拥有了建立ssl安全连接所需要的所有文件，并且服务器的crt和key都位于配置的目录下，唯有根证书cacert.pem位置不确定放在CentOS6下的哪个地方。
经验证以下几个位置不行：（Adding trusted root certificates to the server）
/etc/pki/ca-trust/source/anchors、/etc/pki/ca-trust/source、/etc/pki/ca-trust/extracted、
/etc/pki/ca-trust/extracted/pem/、/etc/pki/tls/certs/cacert.crt
都会报错：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# docker login https://registry.domain.com:8000
Username (sean): sean
2014/11/14 02:32:48 Error response from daemon: Invalid Registry endpoint: Get https://registry.domain.com:8000/v1/_ping: x509: certificate signed by unknown authority
# curl https://sean:sean@registry.domain.com:8000/
curl: (60) Peer certificate cannot be authenticated with known CA certificates
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.

(6) 目前让根证书起作用的只发现一个办法：

1
2
3
4
5
# cp /etc/pki/tls/certs/ca-bundle.crt{,.bak} 备份以防出错
# cat /etc/pki/CA/cacert.pem >> /etc/pki/tls/certs/ca-bundle.crt
# curl https://sean:sean@registry.domain.com:8000
"docker-registry server (dev) (v0.8.1)"

将cacert.pem根证书追加到ca-bundle.crt后一定要重启docker后台进程才行。

如果docker login依然报错certificate signed by unknown authority，参考Running Docker with https，启动docker后台进程时指定信任的CA根证书：

1
2
3
4
5
6
7
# docker -d --tlsverify --tlscacert /etc/pki/CA/cacert.pem
或者将cacert.pem拷贝到~/.docker/ca.pem
# mkdir ~/.docker && cp /etc/pki/CA/cacert.pem ~/.docker/ca.pem
# docker -d
最好重启一下registry
# docker restart <registry_container_id>

上面用“如果”是因为一开始总提示certificate signed by unknown authority，有人说将根证书放在/etc/docker/certs.d下，还有人说启动docker daemon收加入--insecure-registry .. 但终究是因为版本差异不成功。但后来又奇迹般的不需要--tlscacert就好了。
这个地方挣扎了很久，重点关注一下这个下面几个issue：

  • https://github.com/docker/docker-registry/issues/82
  • https://github.com/docker/docker/pull/2687
  • https://github.com/docker/docker/pull/2339

(7) 最终搞定：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# docker login https://registry.domain.com:8000
Username: sean
Password:
Email: zhouxiao@domain.com
Login Succeeded
# curl https://sean:sean@registry.domain.com:8000
"docker-registry server (dev) (v0.8.1)"
# docker push registry.domain.com:8000/centos6:test_priv
The push refers to a repository [registry.domain.com:8000/centos6] (len: 1)
Sending image list
Pushing repository registry.domain.com:8000/centos6 (1 tags)
511136ea3c5a: Image successfully pushed
5b12ef8fd570: Image successfully pushed
68edf809afe7: Image successfully pushed
40627956f44c: Image successfully pushed
Pushing tag for rev [40627956f44c] on {https://registry.domain.com:8000/v1/repositories/centos6/tags/test_priv}

但还有一个小问题没解决，虽然已经可以正常使用，但每次请求在nginx的error.log中还是会有[error] 8299#0: *27 no user/password was provided for basic authentication，应该是这个版本docker暂未解决的bug。

3.3 其它问题

(1) docker后台进程意外中断后，重新docker start <container_id>报错

1
2
3
4
5
# docker start b36bd796bd3d
Error: Cannot start container b36bd796bd3d: Error getting container b36bd796bd3d463c4fedb70d98621e7318ec3d5cd14b2f60b1d182ad3cbcc652
from driver devicemapper: Error mounting '/dev/mapper/docker-253:0-787676-b36bd796bd3d463c4fedb70d98621e7318ec3d5cd14b2f60b1d182ad3cbcc652'
on '/var/lib/docker/devicemapper/mnt/b36bd796bd3d463c4fedb70d98621e7318ec3d5cd14b2f60b1d182ad3cbcc652': device or resource busy
2014/11/08 15:14:57 Error: failed to start one or more containers

经分析产生这个问题的原因是做了一个操作：在docker后台进程启动的终端，继续回车后会临时退出后台进程的日志输出，我就在这个shell下使用yum安装软件包，但由于网络原因yum卡住不动，于是我就另起了一个终端kill了这个yum进程，不知为何会影响到表面已经退出前台输出的docker。解决办法是umount容器的挂载点：（见这里）

1
2
3
# umount /var/lib/docker/devicemapper/mnt/b36bd796bd3d463c4fedb70d98621e7318ec3d5cd14b2f60b1d182ad3cbcc652
# service docker start 正常

能想到的另外一个办法是，启动docker后台进程时，重定向输出docker -d > /dev/null 2>&1（/var/log/docker已自动记录了一份日志）。

(2) 配置完nginx的docker-registry.conf后启动报错

1
2
# service nginx start
[emerg] 14714#0: unknown directive "upstream" in /etc/nginx/conf.d/docker-registry.conf:4

原因是nginx版本太低，一些配置指令不兼容，使用yum install nginx默认安装了1.0.x，卸载重新下载nginx-1.4.7-1.el6.ngx.x86_64.rpm安装解决。

(3) 网络设置代理问题
pull, push官网的镜像时由于GFW的原因需要设置代理，但不是http_proxy而是HTTP_PROXY，对于docker来说同时设置这两个值就会出问题，有时出于安装软件包的需要设置http_proxy，就会导致冲突。在docker-registry中如果忘记了当前哪一个在起作用，找遍所有问题都发现不了原因，而docker返回给我们的错误也难以判断。切记~

TO-DO
如何删除docker-registry的里的镜像

4. 参考

  • 部署自己的私有 Docker Registry [英文]
  • Official docker-registry README
  • How To Set Up a Private Docker Registry on Ubuntu 14.04
  • The Docker Hub and the Registry spec

从敏捷开发到敏捷运维DevOps将带来革命

java资料， linux资料

你听说过DevOps一词，或者听说过敏捷运维这个运动么？人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。传统的工作流程中，开发和运维之间存在很多的沟通错位而造成部署上的问题，由此，DevOps理念应运而生。

【51CTO精选译文】如果你对IT管理感兴趣，尤其是对Web运维感兴趣，那么最近一定会注意到“DevOps”这一热词的出现。现在#DevOps标签频繁出现在微博客Twitter上，同时DevOps相关的技术交流聚会也在慢慢增多。

在许多方面，DevOps是一个集合性概念，指的是能够理顺开发和运维之间相互配合关系的任何事物（51CTO编辑注：在英文中，Developer指开发者，Operations指运维，所以DevOps一词本身含有开发+运维的意思）。但是DevOps背后的理念要比上述说法更深远。

什么是DevOps？

人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。

正如李·汤普森（Lee Thompson）和安德鲁·谢福尔（Andrew Shafer）所言，在开发和运维之间存在一面“混乱之墙”。相互冲突的动机、流程和工具导致了这面“墙”的存在。

相互冲突的动机、流程和工具导致了这面“墙”的存在
开发与运维之间的“混乱之墙”

以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。

而运维人员则往往视变化为敌人。企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。我们已经多次听到过如下统计数字：在所有宕机事件中有80%情况是源于自杀式的改变（根据51CTO之前进行的调查，很多时候，仅仅是给系统应用补丁就会造成生产服务器无法正常重启）。

开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。

更糟糕的是，开发和运维团队通常处于公司组织架构的不同部分，通常具有不同管理者的和竞争关系，而且通常工作在不同的地点。

开发和运维团队通常处于公司组织架构的不同部分
开发与运维通常工作在不同的地点

让混乱之墙更坚固的还包括开发和运维工具之间的错位。看一下开发者要求和日常使用的常见工具，再看一下系统管理员，你会发现两者存在很大不同，开发人员没有兴趣使用运维人员的工具，反之亦然；而且两部分工具之间也不存在重要的集成。即使在某些工具类型上有一些重叠之处，使用方式也完全不同。

开发者要求和日常使用的常见工具
开发与运维常用工具的不集成

当应用程序变动需要从开发团队推向运维团队时，混乱之墙的存在则将变得更加明显。有人将其称为一个“版本发布（Release）”，有人则称其为一次“部署（deployment）”，但有一件事情是公认的，问题可能会随之而来。下图虽然是一个抽象化场景，但是如果你经历过这一过程，一定会感觉到它的真实性。

版本发布与部署
应用程序变动从开发到运维

开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已完成的工作；而糟糕的情况是，他们将引入或发现新的漏洞。

运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。当然，期间如果发生一个问题，开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同，开发人员诊断问题也并非一件易事。

没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。

本来应该一帆风顺的部署过程最后变成一场救火行动
本来应该一帆风顺的部署过程最后变成一场救火行动

部署阶段已经非常明显的需要DevOps理念来解决问题，但需要DevOps的绝不仅仅是这一阶段。正如约翰·阿尔斯帕瓦（John Allspaw）所指出的那样，开发和运维之间的协作需求在部署之前就已存在，同时也会在部署之后的长时间之内继续存在。

DevOps所带来的好处

DevOps是一个非常强大的概念，因为它可以在众多不同层面上产生共鸣。

从开发或运维的一线人员的观点来看，DevOps可以让他们从众多烦恼中解脱出来。它虽然不是具有魔力的万灵药，但是如果你能够让DevOps奏效，则会节省大量时间，而且不至于打击自己的士气。显而易见，投入精力将DevOps落到实处，我们应该会更加高效、更加敏捷和减少挫败感。有些人可能会反驳称DevOps是一个遥不可及的目标，但这并非说我们不应该去尝试实现它。

DevOps会节省大量的时间
DevOps会节省大量的时间

对于企业来说，DevOps直接有助于实现两个强大战略性企业品质，“业务敏捷性”和“IT融合”。它们可能不是IT人士所担忧的事情，但是却应该获得掌握财政大权的管理者的注意。

IT融合的一个简单定义是，“企业渴望达到的一个状态，能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力。”

通过从共同企业目标角度出发来校准开发和运维的职责和流程，DevOps有助于实现IT融合。开发和运维人员需要明白，它们仅仅是一个统一业务流程中的一部分。DevOps思想确保个体决策和行为应力求支持和改进这个统一的业务流程，无论你是来自哪一个组织架构。

DevOps有助于实现IT融合
DevOps有助于实现IT融合

业务敏捷性的一个简单定义是，“一个机构以高效、经济的方式迅速适应市场和环境变化的能力。”

当然对于开发人员来说，“敏捷”有专门的含义（参考51CTO开发频道的专题：初探敏捷开发），但目标是非常类似的。敏捷开发方法旨在保持软件开发工作与客户/公司的目标同步，尽管需求不断变化，也可以产生高品质软件。对于多数机构来说，迭代项目管理方法Scrum是敏捷的代名词。

Scrum
Scrum

业务敏捷性承诺，在企业权益集团作出决策和开发者进行响应之间能够紧密互动和快速反馈。看一下一家运转良好的敏捷开发团体的产品，你会看到一个与业务需求保持一致的稳定持续改进。

但是，当你从企业角度回顾一下整个开发-运维周期，敏捷方法的相关优势通常会变得非常模糊。混乱之墙导致了应用程序生命周期的分裂。开发和运维分别按照不同的节奏进行。实际上，产品部署之间的长期间隔使得一个团体的敏捷工作变成了它一直试图避免的瀑布生命周期。当存在混乱之墙时，无论开发团体有多么敏捷，改变企业缓慢和迟钝的特点是极其困难的。

敏捷开发与企业结构的不同步
敏捷的开发与瀑布式企业结构的步调不同

DevOps使得敏捷开发的优势可以体现在机构层面上。通过考虑到快速、反应灵敏但稳定的业务运维，使其能够与开发过程的创新保持同步，DevOps可以做到这一点。

如果你希望在自己的组织内建立一个DevOps项目，务必牢记“IT融合” 和“业务敏捷性”。

如何将DevOps落到实处？

和多数新出现的话题一样，发现问题的共性特点要比找到解决方案容易的多。

要想实现DevOps相关解决方案，以下三方面需要关注：

1、评价和鼓励改变文化

改变文化和激励系统从来不是一件易事。但是，如果你不改变企业文化，兑现DevOps的承诺将非常困难。考察一个企业的主导文化时，你需要紧密关注如何评价和判断企业业绩。评价的内容将影响和刺激行为的发生。开发-运维生命周期中的所有当事方需要明白，在更大的企业流程中自己只是其中一部分。个体和团队的成功都要放在整个开发-运维生命周期内来进行评价。对于许多机构来说，这是一个转变，不再是孤立的来进行业绩评价，每一个团队不再是基于自己的团队来评价和判断业绩好坏。

2、统一标准化的流程

这是DevOps的一个重要主题，整个开发-运维生命周期必须被看作一个端对端过流程。流程的不同阶段可以采取不同的方法，只要这些流程可以被组合到一起创建一个统一的流程。与评价和激励的问题相似的是，实现这个统一的流程时每个组织可能会有略微不同的需求。

3、统一的工具

这是大多数DevOps讨论一直在关注的领域。这一点不令人吃惊，因为当技术专家在考虑解决一个问题时，第一反应往往就是直接跳转到工具讨论上。如果你关注Puppet、Chef或ControlTier等工具社区，那么你可能已经意识到人们对在开发和运维工具之间建立桥梁的重大关注。“基础设施即代码（Infrastructure as code）”、“模型驱动自动化（model driven automation）”和“持续性部署（continuous deployment）”都是可以划归DevOps旗下的概念。

关于把DevOps变为现实需要哪些类型的工具，杰克·索罗夫曼（Jake Sorofman）提出如下建议：

一个版本控制软件库

它可以确保所有系统产品在整个版本发布生命周期中被很好的定义，且能够实现一致性共享，同时保持最新信息。开发和QA机构能够从中取得相同平台版本，生产机构部署已经被QA机构验证过的相同版本。

深层模型系统

它的版本系统清晰的描述了软件系统相关的所有组件、策略和依赖性，从而可以简单的根据需要复制一个系统或在无冲突的情况下引入变化。

人工任务的自动化

在依赖关系发现、系统构造、配置、更新和回滚等过程中，减少人工干涉。自动操作变为高速、无冲突和大规模系统管理的命令和控制基础。

在从开发到运维的生命周期中存在许多不同的工具。工具选择和执行决策需要根据它们对端到端生命周期的影响来决定。

关于DevOps的澄清

现在某些系统管理员正在试图把自己的岗位名称改为“DevOps”。但是，DevOps不应该是一个单一的位置或职称。把DevOps变成一个新职位名称或特定角色是一件非常危险的事情。例如这会导致以下错误端点：你是一个DBA？或者是一个安全专家？那么不用担心DevOps，因为那是DevOps团队的问题。

设想一下，你不会说“我需要招聘一个Agile”或“我需要招聘一个Scrum”或“我需要招聘一个ITIL”，而只是会说需要招聘了解这些概念或方法的开发人员、项目经理、测试人员或系统管理员。DevOps也是同样道理。

与DevOps具有相同理念的术语很多，例如敏捷运维（Agile Operations）、敏捷基础设施（Agile Infrastructure）和Dev2Ops。还有很多人虽然没有提及“DevOps”，但却在遵循着类似的理念。

原文：http://dev2ops.org/blog/2010/2/22/what-is-devops.html

Linux下配置ip地址四种方法

linux资料

来源：http://www.cnblogs.com/adforce/p/3363681.html

linux系统安装完，以后通过命令模式配置网卡IP。
配置文件通常是/etc/sysconfig/network-scripts/ifcfg-interface-name
ifconfig后显示的内容，lo代表loop回路。

一、Ifconfig命令

第一种使用ifconfig命令配置网卡的ip地址。此命令通常用来零时的测试用，计算机启动后，ip地址的配置将自动失效。具体用法如下：
Ifconfig ethx ipaddr netmask x.x.x.x

ethx中的x代表第几快以太网卡，默认第一块为0；ipaddr代表ip地址；x.x.x.x为子网掩码。
例如给网卡eth0配置的ip地址为192.168.1.1 子网掩码为 255.255.255.0 。

如下下图所示：

注意：此方法配置的ip地址后计算机从新启动将会失效。

 

二、neat命令

Neat命令=redhat-config-network 图形下配置ip地址：

双击图下画红线的部分

双击划线部分后出现下图所示：根据要求配置相关信息

双击ok配置完毕。配置完后重启服务，并查看配置ip地址。

注意：此方法配置的ip地址后计算机从新启动仍然有效。

 

三、netconfig命令

输入netconfig后将会出现下图所示，单击yes按钮。

进行相关配置后ok退出。

注意：此方法配置的ip地址后计算机从新启动仍然有效。

 

四、vi  /etc/sysconfig/network-scripts/ifcfg-ethx

配置完以后重启动服务，ip地址就配置好了。其实前面3个的配置方法最终还是改变了/etc/sysconfig/network-scripts/ifcfg-ethx下的配置文件罢了。

 

 

转载：http://nanwangting.blog.51cto.com/608135/200097

八种最常见Docker开发模式

linux资料
Docker已迅速成为本人最喜欢的基础工具之一，以便构建可重复软件产品，从而带来尽可能静 态的服务器环 境。我在本文中将概述我在使用Docker的过程中开始反复出现的几种模式。我不指望它们会带来多少新奇或惊喜，但希望其中一些有用，我也很想听听各位在 使用Docker过程中遇到的模式。

八种最常见Docker开发模式 别说你还不知道

Docker已迅速成为本人最喜欢的基础工具之一，以便构建可重复软件产品，从而带来尽可能静态的服务器环境。

我在本文中将概述我在使用Docker的过程中开始反复出现的几种模式。我不指望它们会带来多少新奇或惊喜，但希望其中一些有用，我也很想听听各位在使用Docker过程中遇到的模式。

我试用Docker的基础是保持在卷中持续的状态，那样Docker容器本身可以随意重建，而不会丢失数据(除非我改动容器状态，而不更新Docker文件(Dockerfile)的状态，而经常重建容器有助于改掉这个坏习惯)。

下面的示例Docker文件都专注于此：构建容器――在这种环境下，容器本身可以随时更换，没必要考虑它。

1. 共享基础容器

Docker 鼓励“继承”，所以这应该并不奇怪――继承是高效使用Docker的一个基本方面，尤其是由于它有助于减少构建新容器所需的时间，因为 没必要那么频繁地重新执行步骤。Docker会试图将中间步骤放入到缓存，它在这方面做得很好――有时太好了，不过要是没有明确注明，也很容易错过共享的 机会。

将我的各种容器迁移到Docker上时明显出现的事情之一是，存在太多的冗余设置。

我为预计部署到任何地方的大多数项目运行单独的容器，至少它需要任何长时间运行的进程，或者需要“标准”程序包集之外的任何特定程序包时，是这样，因而我有好多容器，而程序包迅速变得越来越多。

等到我考虑迁移时，就试图在Docker中运行“一切”(包括我依赖的少数几个桌面应用程序)，以便让我的mybase环境完全可以随意使用。

于是我很快开始将我的基本设置提取到基础容器，用于众多用途。下面是我当前的“devbase”Docker文件：

  1. FROM debian:wheezy
  3. RUN apt-get update
  5. RUN apt-get -y install ruby ruby-dev build-essential git
  7. RUN apt-get install -y libopenssl-ruby libxslt-dev libxml2-dev
  9. # 用于调试
  11. RUN apt-get install -y gdb strace
  13. # 设置我的用户
  15. RUN useradd vidarh -u 1000 -s /bin/bash --no-create-home
  17. RUN gem install -n /usr/bin bundler
  19. RUN gem install -n /usr/bin rake
  21. WORKDIR /home/vidarh/
  23. ENV HOME /home/vidarh
  25. VOLUME ["/home"]
  27. USER vidarh
  29. EXPOSE 8080

这里没有什么需要特别说明的――它安装了我往往喜欢随时可用的一些特定工具。这些工具对大多数人来说恐怕不一样。选择什么样的发行版很随意。值得考虑的是，如果/当你重建容器时，就要指定一个特定的标记以避免意外。

它在默认情况下暴露了端口8080，因为那是我通常暴露Web应用程序的端口，我通常将这些容器用于这些Web应用程序。

它为我添加了一个用户，将userid设置为服务器上的用户ID，并不创建/home目录。之所以不创建/home目录，是由于我从主机绑定挂载共享/ home，这就引出了下一种模式。

2. 共享卷开发容器

我 的所有开发容器与主机至少共享一个卷：/ home，这么做是为了便于开发。就许多应用程序而言，它让我可以让与合适的基于文件-系统-变更的代码重载器一起运行的应用程序处于开发模式，那样容器 就可以封装操作系统/发行版层面的依赖项，并且帮助证实捆绑的应用程序在原始环境中运行，我用不着针对每处代码变更，需要完全重启/重建虚拟机。与此同 时，我可以相当频繁地重启虚拟机，确保没有什么错失。

至于其他，它让我可以只要重启(而不是重建)容器，即可接受代码变更。

对于测试/试运行容器和生产容器，我在大多数情况下会避免通过卷共享代码，而是使用“ADD”命令，将相应代码添加到Docker容器本身中。

比如说，下面是我“homepage”开发容器的Docker文件，它含有我自主开发的个人维基，可利用来自“devbase”容器的已经共享的/home卷，并展示了共享基础容器和我如何使用共享/home卷：

  1. FROM vidarh/devbase
  3. WORKDIR /home/vidarh/src/repos/homepage
  5. ENTRYPOINT bin/homepage web

(注意：我确实应该对我的devbase容器加上版本标记)

至于我博客的开发版本：

  1. FROM vidarh/devbase
  3. WORKDIR /
  5. USER root
  7. # 针对Graphivz整合
  9. RUN apt-get update
  11. RUN apt-get -y install graphviz xsltproc imagemagick
  13. USER vidarh
  15. WORKDIR /home/vidarh/src/repos/hokstad-com
  17. ENTRYPOINT bundle exec rackup -p 8080

因为它们从共享软件库获取代码，而且基于共享的基础容器，当我添加/修改/删除依赖项时，这些容器通常可以极其迅速地重建，我觉得这很重要，以便确保我没有忍不住采用疏忽未记录依赖项的变通方法。

即 便如此，肯定有些方面是我想改进的。尽管上述基础容器是轻量级，但它们肯定不止这样：这些容器中的大多数内容仍然未使用。由于Docker采用写 时拷贝(copy-on-write)覆盖，这不会导致庞大开销，但确实仍意味着我并没有真正体现最基本需求，也没有尽可能减少攻击或出错风险(我倒不是 很担心这些特定情况的攻击风险，因为我的博客并不在“实时”版本中含有任何重要状态。)。

3. 开发工具容器

这对像我们这些喜欢依靠通过ssh连接至屏幕会话来编写代码的人来说可能最有吸引力，而对IDE人群来说不太有吸引力;但对我来，上述方案的一个好处就是，它让我可以将编辑和测试执行部分代码与运行开发中的应用程序分离开来。

过去开发系统方面很烦人的问题之一是，开发及生产依赖项与开发工具依赖项很容易混在一起。你可以试着将它们分开来，但除非这些设置真正做到了分离开来，否则很容易建立未记录依赖项。

在过去，我花了几周对应用程序的依赖项进行“反向工程”后，总算搞清楚了这个问题。由于开发环境、测试和初始原型部署环境混在一起，这个应用程序积累了各种各样的未记录依赖项。

虽然有很多方法可以解决这个问题：只要确保你进行定期的测试部署，结合上述模式，但我还是有一种个人很喜欢的解决方案，因为它可以从根本上防止问题出现：

我 有一个单独的容器含有Emacs安装环境，还有我喜欢随时可用的其他各种工具。我仍试图保持精简，但问题是，我的屏幕会话可以驻留在这个容器中， 结合我那台笔记本电脑上设置的“autossh”，几乎总是有一条连接与容器相连，那样我就可以编辑与我的其他开发容器“实时”共享的代码。

在这个容器，我还允许偶尔出错：直接安装程序包，因为它只影响调试和开发。

目前，它看起来如下：

  1. FROM vidarh/devbase
  3. RUN apt-get update
  5. RUN apt-get -y install openssh-server emacs23-nox htop screen
  7. #用于调试
  9. RUN apt-get -y install sudo wget curl telnet tcpdump
  11. # 针对32位试验
  13. RUN apt-get -y install gcc-multilib
  15. # 参考手册页和“most”viewer:
  17. RUN apt-get install -y man most
  19. RUN mkdir /var/run/sshd
  21. ENTRYPOINT /usr/sbin/sshd -D
  23. VOLUME ["/home"]
  25. EXPOSE 22
  27. EXPOSE 8080

结合共享“/ home“，这给了我一个足够实用的小地方可以通过ssh连入。我确信，用它用得越多，我会补充它，但眼下它证明完全能满足我的需要。

八种最常见Docker开发模式 别说你还不知道

4. 不同环境下测试容器

我特别喜欢Docker的一个方面是，可以在不同环境下轻松测试代码。比如说，我升级Ruby编译项目以便处理Ruby 1.9(早就该有了)后，创建了这个小小的Docker文件，好让我在将主开发环境迁移到1.9之后，在Ruby 1.8环境中生成一个外壳。

  1. FROM vidarh/devbase
  3. RUN apt-get update
  5. RUN apt-get -y install ruby1.8 git ruby1.8-dev

当然，你可以用rbenv等获得类似的效果。但我总是觉得这些工具很烦人，因为我更喜欢尽量使用发行版程序包来部署，尤其是由于，如果我确保这顺利开展，它让其他人更容易使用我的代码。

拥有这样一个Docker容器：当我暂时需要不同的环境时，只要运行“docker run”，圆满地解决了这个问题，而且还有这个好处：它并不受制于像Ruby这种有预包装自定义工具来处理版本的编程语言。

我还可以使用标准虚拟机来达到目的，但是可以在短得多的时间内启动上述docker容器。

5. 构建容器

如今我编写的代码大多是用解释语言编写的，但即使那样，还是常常会有实用的“构建”(build)步骤需要花很大的开销，我宁可不是一直执行它们。

一个例子是为Ruby应用程序运行“捆绑工具”(bundler)。捆绑工具可为Rubygem更新缓存的依赖项(还可视情况更新全部的gem文件，甚至更新未打包的内容)，针对较大的应用程序运行捆绑工具要花一段时间。

它 还常常需要应用程序运行时并不需要的依赖项。比如说，安装依赖原生扩展的gem常常依赖众多的程序包――常常没有记录到底是哪些程序包，通过获取 所有的build-essential程序包及其依赖项，就更容易启动。与此同时，虽然你可以事先让捆绑工具做所有的工作，但我真的不想在主机环境中运行 它，主机环境可能与容器兼容，也可能不兼容。

这方面的解决办法就是创建构建容器。如果依赖项不同的话，你可以创建单独的Docker文件，也可以重复使用主应用程序Docker文件，只要覆盖命令来运行你所需要的构建命令。比如说，Docker文件看起来如下：

  1. FROM myapp
  3. RUN apt-get update
  5. RUN apt-get install -y build-essential [assorted dev packages for libraries]
  7. VOLUME ["/build"]
  9. WORKDIR /build
  11. CMD ["bundler", "install","--path","vendor","--standalone"]

然后，只要你更新了依赖项，将你的build/source目录挂载到容器的”build”目录下，就可以运行这段命令。只要更换合适的项就行。

关键在于，你可以将应用程序的构建或者其一部分与最后的包装分开来，同时仍封装Docker容器中的进程和依赖项，只要将进程细分到两个或多个容器中。

6.安装容器

这 种方法虽非我原创，但确实值得一提。出色的nsenter和docker-enter工具随带一个安装选项，这与流行的，但又令人畏惧的 “curl [你无法控制的某个URL] | bash”模式相比是个很大的进步。它通过提供实现上述“构建容器”模式的Docker容器来做到这一点，不过更进了一步。它值得关注。

这是Docker文件的最后部分，之后下载并构建了一个合适的nsenter版本(我要提醒的一点是，对下载文档没有进行完整性检查)：

  1. ADD installer /installer
  3. CMD /installer
  5. “installer”看起来如下：
  7. #!/bin/sh
  9. if mountpoint -q /target; then
  11. echo "Installing nsenter to /target"
  13. cp /nsenter /target
  15. echo "Installing docker-enter to /target"
  17. cp /docker-enter /target
  19. else
  21. echo "/target is not a mountpoint."
  23. echo "You can either:"
  25. echo "- re-run this container with -v /usr/local/bin:/target"
  27. echo "- extract the nsenter binary (located at /nsenter)"
  29. fi

虽然恶意攻击者仍有可能企图利用容器可能存在的特权提升问题大做手脚，但是攻击风险至少要小得多。

但这种模式最可能立即吸引我们大多数人的地方在于，避免了这一风险：本意良好的开发人员偶尔在安装脚本方面犯下很危险的错误。

我确实很喜欢这种方法。但愿它会有助于减少大家对“curl [something] | bash”的厌恶感(但即使没有起到这个作用，至少我们可以轻松控制容器里面的东西)。

7. 盒子中默认服务容器

如果我“认真对待”某个应用程序，会比较迅速地准备好合适的容器，为开发项目处理数据库等服务，但我觉得拥有一系列“基本”的基础设施容器非常重要，我可以进行合适的调整/改动，就能启动所选择的数据库，或者所选择的有合适默认设置的队列系统。

当 然你也可以“基本上如愿以偿”，只要试一试“docker run [某个应用程序名称]”，祈祷Docker索引中有一个出色的替代者，而且这个替代者常常就在索引中。但我喜欢先审查，比如弄清楚它们如何处理数据，然后 我更有可能将自己的修改后版本添加到自己的“库”中。

比如说，我有一个Beanstalkd的Docker文件：

  1. FROM debian:wheezy
  3. ENV DEBIAN_FRONTEND noninteractive
  5. RUN apt-get -q update
  7. RUN apt-get -y install build-essential
  9. ADD http://github.com/kr/beanstalkd/archive/v1.9.tar.gz /tmp/
  11. RUN cd /tmp && tar zxvf v1.9.tar.gz
  13. RUN cd /tmp/beanstalkd-1.9/ && make
  15. RUN cp /tmp/beanstalkd-1.9/beanstalkd /usr/local/bin/
  17. EXPOSE 11300
  19. CMD ["/usr/local/bin/beanstalkd","-n"]

我 的目标是能够“OK，我将需要memcached、postgres和beanstalk”，运行三个快速“docker run”命令后，会启动并运行三个容器，它们都针对我的环境和默认环境个人偏好已经过了改动，随时可以使用。设置“标准”基础设施部件应该只需要1分钟， 而不是占用开发本身的时间。

8. 基础设施/粘合剂容器

许多这种模式专注于开发环境(这意味着生产环境方面还有更多需要讨论的)，但缺少了一大类别：粘合剂容器。

其目的是把你的环境组合成统一整体的容器。这是到目前为止有待我进一步研究的领域，不过我会提到一个特别的例子：

为了能够轻松访问我的容器，我有一个小小的haproxy容器。我有一个指向主服务器的通配符DNS项，一个iptable项允许访问我的haproxy容器。Docker文件没什么特别之处：

  1. FROM debian:wheezy
  3. ADD wheezy-backports.list /etc/apt/sources.list.d/
  5. RUN apt-get update
  7. RUN apt-get -y install haproxy
  9. ADD haproxy.cfg /etc/haproxy/haproxy.cfg
  11. CMD ["haproxy", "-db", "-f", "/etc/haproxy/haproxy.cfg"]
  13. EXPOSE 80
  15. EXPOSE 443

这 里有趣的部分是haproxy.cfg，它由一段从“docker ps”的输出结果生成后端部分(就像这里)的脚本和前端定义中的一批acls和use_backend语句共同生成，前端定义将 [hostname].mydomain发送到右边的backend.backend测试。

  1. backend test
  3. acl authok http_auth(adminusers)
  5. http-request auth realm Hokstad if !authok
  7. server s1 192.168.0.44:8084

如果我想玩点花样，可以部署像AirBnB的Synapse这样的产品，但它拥有的选项数量之多超出了我对开发使用的要求。

就我的家用环境而言，这满足了我的大多数基础设施要求。我仍在不断推出了一系列基础设施容器，其目的是让实际应用程序部署起来轻而易举，就像我将一个完整的私有云系统向Docker迁移那样。

win7下DOCKER详细安装教程

linux资料

windows必须是64位的

1.下载程序包

安装包 https://github.com/boot2docker/windows-installer/releases(这个地址国内下载很慢)

用这个： https://get.daocloud.io/toolbox/

随着Docker的发展如日中天，着手安装使用Docker却成了大家的拦路虎，不过有了Toolbox，再也不用担心Docker的安装与使用了。本文对比于大家所熟知Boot2Docker命令行工具，简单的剖析了Toolbox安装器。

近日，Docker公司发布了Toolbox。Toolbox是一个安装器，目前支持Mac和Windows平台。使用它可以快速地在安装Docker工具集。本文翻译自Docker官方博客。

过去我们总听到有人说，在开发中很难使用入手使用Docker，尤其是你已经根据Compose定义过了你的应用程序，然后接下来要去单独安装Compose的情况。随着Compose、Kitematic以及Boot2Docker的普及，我们意识到我们需要让这些零碎的工具更好的在一起工作。

Toolbox可以安装你在开发中运行Docker时所需要的一切：Docker客户端、Compose（仅Mac需要）、Kitematic、Machine以及VirtualBox。Toolbox使用Machine和VirtualBox在虚拟机中创建了一个引擎来运行容器。在该虚拟机上，你可以使用Docker客户端、Compose以及Kitematic来运行容器。

它取代了Boot2Docker吗？

是的，玩转Docker，我们推荐Toolbox。

尽管Boot2Docker安装程序已经相当的受欢迎，但DockerToolbox是设计用来安装正在不断发展的Docker开发者工具集合，比如Kitematic、Machine、Swarm还有Compose。之前Boot2Docker还安装了一个叫Boot2Docker的命令行工具，以用来管理Docker虚拟机，在Toolbox中它已经被Machine取代了。

然而，在这个引擎下，Machine依然采用了Boot2DockerLinux发行版来运行容器。所不同的是，现在由Machine代替Boot2Docker命令行工具来管理这些容器。

如果你现在正在使用官方Boot2Docker（boot2docker-VM），DockerToolbox会提示你自动迁移到使用DockerMachine的虚拟机上。
 

下载最新版本的：Docker-install.exe即可。
该安装包安装完成后，系统上会多出三个软件：

Oracle VM VirtualBox
Git
Boot2Docker for Windows

以上三个默认安装即可。

2. 设置环境变量

在命令窗口中，输入ls 如果能找到命令说明环境添加正确。

3. 启动DOCKERT

在命令窗口中，切到docker的安装目录下

输入sh:
然后输入start.sh,等待启动


第一次启动中，如果有新版本会更新，时间比较长。

如果第二次启动，就非常快了。

4. 分析start.sh

#!/bin/bashset -e

# clear the MSYS MOTD
clear

cd "$(dirname "$BASH_SOURCE")"

ISO="$HOME/.boot2docker/boot2docker.iso"

if [ ! -e "$ISO" ]; then
    echo 'copying initial boot2docker.iso (run "boot2docker.exe download" to update)'
    mkdir -p "$(dirname "$ISO")"
    cp ./boot2docker.iso "$ISO"fi

echo 'initializing...'
./boot2docker.exe init
echo

echo 'starting...'
./boot2docker.exe start
echo

./boot2docker.exe ip

echo 'connecting...'
./boot2docker.exe ssh
echo

echoecho '[Press any key to exit]'read

从内容上看主要是执行，如下语句

boot2docker.exe init
boot2docker.exe start
boot2docker.exe ssh

所有在命令行下执行 sh start.sh 即可

5. 利用SSH工具管理

在windows命令行进入docker后，不能复制，而且操作也不方便，因此用支持SSH的工具来管理是很好的，比如SECURECRT, PUTTY等，推荐用SECURECRT.
在命令行下用boot2docker ip 可以查询到IP

默认的用户名和密码是： docker/tcuser

登录后的界面：

6. 下载镜像

6.1 下载地址

http://download.openvz.org/template/precreated
选择下载 ubuntu-14.04-x86_64.tar.gz

6.2 用FTP工具上传tar包

推荐使用：FileZilla

6.3 安装

命令：cat ubuntu-14.04-x86_64.tar.gz |docker import - ubuntu:ubuntu14
速度非常快，大概10几秒就完成了。

6.4 查看镜像

查看： docker images

6.5 运行

运行：docker run -i -t ubuntu:ubuntu14 /bin/bash

可以开始DOCKER旅行了。

来源： http://blog.csdn.net/zistxym/article/details/42918339