Ubuntu

Ubuntu

FAQ宝典之常见问题排查与修复方法

Rancher 发表了文章 • 1 个评论 • 1368 次浏览 • 2017-12-29 12:33 • 来自相关话题

一、服务/容器 #1、为什么我只能编辑容器的名称? Docker容器在创建之后就不可更改了。唯一可更改的内容是我们要存储的不属于Docker容器本身的那一部分数据。无论是停止、启动或是重新启动,它始终在使用相 ...查看全部
一、服务/容器

#1、为什么我只能编辑容器的名称?

Docker容器在创建之后就不可更改了。唯一可更改的内容是我们要存储的不属于Docker容器本身的那一部分数据。无论是停止、启动或是重新启动,它始终在使用相同的容器。如需改变任何内容都需要删除或重新创建一个容器。

你可以克隆,即选择已存在的容器,并基于已有容器的配置提前在添加服务界面中填入所有要设置的内容,如果你忘记填入某项内容,可以通过克隆来改变它之后删除旧的容器。

#2、service-link的容器/服务在Rancher中是如何工作的?

在Docker中,关联容器(在docker run中使用--link)的ID和IP地址会出现在容器的/etc/hosts中。在Rancher中,我们不需要更改容器的/etc/hosts文件,而是通过运行一个内部DNS服务器来关联容器,DNS服务器会返回给我们正确的IP。

#3、不能通过Rancher的界面打开命令行或查看日志,如何去访问容器的命令行和日志?

Agent主机有可能会暴露在公网上,Agent上接受到的访问容器命令行或者日志的请求是不可信的。Rancher Server中发出的请求包括一个JWT(JSON Web Token),JWT是由服务器签名并且可由Agent校验的,Agent可以判断出请求是否来自服务器,JWT中包括了有效期限,有效期为5分钟。这个有效期可以防止它被长时间使用。如果JWT被拦截而且没有用SSL时,这一点尤为重要。

如果你运行docker logs -f (rancher-agent名称或ID)。日志会显示令牌过期的信息,随后检查Rancher Server主机和Rancher Agent主机的时钟是否同步。

#4、在哪里可以看到我的服务日志?

在服务的详细页中,我们提供了一个服务日志的页签日志。在日志页签中,列出了和服务相关的所有事件,包括时间戳和事件相关描述,这些日志将会保留24小时。

#5、RANCHER SERVER 点击WEB shell屏幕白屏

如果RANCHER SERVER 运行在V1.6.2版本,点击WEB shell出现白屏,这是UI上的一个BUG,请选择升级server服务。

#二、跨主机通信

如果容器运行在不同主机上,不能够ping通彼此,可能是由一些常见的问题引起的。

#1、如何检查跨主机通信是否正常?

在应用->基础设施中,检查 healthcheck 应用的状态。如果是active跨主机通信就是正常的。

手动测试,你可以进入任何一个容器中,去ping另一个容器的内部IP。在主机页面中可能会隐藏掉基础设施的容器,如需查看点击“显示系统容器”的复选框。

#2、UI中显示的主机IP是否正确?

有时,Docker网桥的IP地址会被错误的作为了主机IP,而并没有正确的选择真实的主机IP。这个错误的IP通常是172.17.42.1或以172.17.x.x开头的IP。如果是这种情况,在使用docker run命令添加主机时,请用真实主机的IP地址来配置CATTLE_AGENT_IP环境变量。


sudo docker run -d -e CATTLE_AGENT_IP= --privileged \
-v /var/run/docker.sock:/var/run/docker.sock \
rancher/agent:v0.8.2 http://SERVER_IP:8080/v1/scripts/xxxx


#3、Rancher的默认子网(10.42.0.0/16)在我的网络环境中已经被使用或禁止使用,我应该怎么去更改这个子网?

Rancher Overlay网络默认使用的子网是10.42.0.0/16。如果这个子网已经被使用,你将需要更改Rancher网络中使用的默认子网。你要确保基础设施服务里的Network组件中使用着合适的子网。这个子网定义在该服务的rancher-compose.yml文件中的default_network里。

要更改Rancher的IPsec或VXLAN网络驱动,你将需要在环境模版中修改网络基础设施服务的配置。创建新环境模板或编辑现有环境模板时,可以通过单击编辑来配置网络基础结构服务的配置。在编辑页面中,选择配置选项>子网输入不同子网,点击配置。在任何新环境中将使用环境模板更新后的子网,编辑已经有的环境模板不会更改现在已有环境的子网。

这个实例是通过升级网络驱动的rancher-compose.yml文件去改变子网为10.32.0.0/16。


ipsec:
network_driver:
name: Rancher IPsec
default_network:
name: ipsec
host_ports: true
subnets:
# After the configuration option is updated, the default subnet address is updated
- network_address: 10.32.0.0/16
dns:
- 169.254.169.250
dns_search:
- rancher.internal
cni_config:
'10-rancher.conf':
name: rancher-cni-network
type: rancher-bridge
bridge: docker0
# After the configuration option is updated, the default subnet address is updated
bridgeSubnet: 10.32.0.0/16
logToFile: /var/log/rancher-cni.log
isDebugLevel: false
isDefaultGateway: true
hostNat: true
hairpinMode: true
mtu: 1500
linkMTUOverhead: 98
ipam:
type: rancher-cni-ipam
logToFile: /var/log/rancher-cni.log
isDebugLevel: false
routes:
- dst: 169.254.169.250/32


注意:随着Rancher通过升级基础服务来更新子网,以前通过API更新子网的方法将不再适用。



#4、VXLAN 网络模式下,跨主机容器无法通信

Vxlan 通过4789端口实现通信,检查防火墙有没有开放此端口;

执行iptables -t filter -L -n参看IPtable表,查看chain FORWARD 是不是被丢弃,如果是,执行sudo iptables -P FORWARD ACCEPT

三、DNS

#1、如何查看我的DNS是否配置正确?

如果你想查看Rancher DNS配置,点击应用 > 基础服务。点击network-services应用,选择metadata,在metadata中,找到名为network-services-metadata-dns-X的容器,通过UI点击执行命令行后,可以进入该容器的命令行,然后执行如下命令。


cat /etc/rancher-dns/answers.json


#2、在Ubuntu上运行容器时彼此间不能正常通信。

如果你的系统开启了UFW,请关闭UFW或更改/etc/default/ufw中的策略为:


DEFAULT_FORWARD_POLICY="ACCEPT"


四、负载均衡

#1、为什么我的负载均衡一直是Initializing状态?

负载均衡器自动对其启用健康检查。如果负载均衡器处于初始化状态,则很可能主机之间无法进行跨主机通信。

#2、我如何查看负载均衡的配置?

如果要查看负载均衡器的配置,你需要用进入负载均衡器容器内部查找配置文件,你可以在页面选择负载均衡容器的执行命令行


cat /etc/haproxy/haproxy.cfg


该文件将提供负载均衡器的所有配置详细信息。

#3、我在哪能找到HAproxy的日志?

HAProxy的日志可以在负载均衡器容器内找到。负载均衡器容器的docker logs只提供与负载均衡器相关的服务的详细信息,但不提供实际的HAProxy日志记录。


cat /var/log/haproxy


#4、如何自定义负载均衡的配置



如图,在自定义配置中,按照global、defaults、frontend、backend的格式配置。

五、健康检查

#1、为什么健康检查服务一直显示黄色初始化状态?

healthcheck不仅为其他服务提供健康检查,对系统组件(比如调度服务)也提供健康检查服务,healthcheck也对自己进行健康检查。多个healthcheck组件时,它们会相互交叉检查,只有健康检查通过后,容器状态才会变成绿色。而healthcheck一直显示黄色初始化状态,说明一直没有通过健康检查。健康检查都是通过网络访问的,所以一定是网络通信异常导致。

六、调度

为什么节点关机后,应用没有自动调度到其他节点上?Rancher上应用的调度,需要配合健康检查功能。当健康检查检查到应用不健康才会重新调度,如果没有配置健康检查,即使关机,cattle也不会对应用做调度处理。

七、CentOS

#1、为什么容器无法连接到网络?

如果你在主机上运行一个容器(如:docker run -it ubuntu)该容器不能与互联网或其他主机通信,那可能是遇到了网络问题。Centos默认设置/proc/sys/net/ipv4/ip_forward为0,这从底层阻断了Docker所有网络。

解决办法:


vi /usr/lib/sysctl.d/00-system.conf


添加如下代码:


net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1


重启network服务


systemctl restart network


查看是否修改成功


sysctl net.ipv4.ip_forward


如果返回为net.ipv4.ip_forward = 1则表示成功了

八、京东云

#1、京东云运行rancher server出现以下问题



解决办法:sudo sysctl -w net.ipv4.tcp_mtu_probing=1

推荐阅读:《FAQ宝典之Rancher Server》《FAQ宝典之Rancher Server、K8s、Docker》

原文链接:Rancher Labs

如何在Redhat/Centos上部署marathon bamboo+haproxy开源软件

回复

self_flying 发起了问题 • 2 人关注 • 0 个回复 • 1818 次浏览 • 2017-12-20 15:22 • 来自相关话题

在Kubernetes中用Helm安装Prometheus为什么PVC一直pending?

回复

online 发起了问题 • 1 人关注 • 0 个回复 • 6546 次浏览 • 2017-11-13 11:05 • 来自相关话题

如何安装centos7 的指定版本。

回复

如她 发起了问题 • 1 人关注 • 0 个回复 • 2101 次浏览 • 2017-10-11 00:24 • 来自相关话题

采用Docker技术,生产环境下建议采用CentOS(Fedora)还是Ubuntu(Debian)?

zhaojunlike@ 回复了问题 • 4 人关注 • 3 个回复 • 7188 次浏览 • 2017-04-13 15:42 • 来自相关话题

求助,centos7镜像创建的容器里面安装服务后,无法使用命令启动服务

yingz 回复了问题 • 7 人关注 • 4 个回复 • 51665 次浏览 • 2017-03-27 14:52 • 来自相关话题

咨询如何可以把现有的ubuntu系统做成镜像

gnuer 回复了问题 • 4 人关注 • 4 个回复 • 2977 次浏览 • 2016-12-21 15:29 • 来自相关话题

Docker 1.12 与 CentOS7的firewalld有冲突

徐磊 回复了问题 • 2 人关注 • 1 个回复 • 6231 次浏览 • 2016-11-15 10:53 • 来自相关话题

如何在CentOS6.5上安装docker1.9及以上版本?

陛下 回复了问题 • 2 人关注 • 1 个回复 • 6751 次浏览 • 2016-10-29 15:21 • 来自相关话题

CentOS系统故障 | 一桩"血案"引发的容器存储驱动比较

有容云 发表了文章 • 3 个评论 • 2261 次浏览 • 2016-08-04 11:11 • 来自相关话题

写在前面: 由于红帽在Linux界的影响力,相信很多朋友在测试和生产系统用的是RedHat或者CentOS系统,这次我在CentOS系统上遇到了一个很有意思的故障,通过这次故障的原因分析及解决,特意写了这篇文章分享给大家。 ...查看全部
写在前面:
由于红帽在Linux界的影响力,相信很多朋友在测试和生产系统用的是RedHat或者CentOS系统,这次我在CentOS系统上遇到了一个很有意思的故障,通过这次故障的原因分析及解决,特意写了这篇文章分享给大家。

我们在CentOS上部署了一套Docker系统,运行了一段时间后,突然发现所有容器运行异常,同时宿主机内核报磁盘I/O错误:

1.png


看到问题的第一反映是查看磁盘状态和空间使用情况,发现系统的根目录已经用完:

2.png


我们知道,Docker默认的存储目录是在/var/lib/docker/下,同时我们也知道,可以通过使用-g, --graph=”/var/lib/docker” 参数修改Docker 默认存放路径。知道了问题后,我们可以通过挂载一个大硬盘到系统,并将Docker的目录更改为新挂载到硬盘上:

3.png


我将Docker的存储目录设置到刚才新增加的/data目录下,但是原来的镜像和容器都找不到了,因为路径改了。原来的镜像是在/var/lib/docker/devicemapper/devicemapper/{data,metadata},转移文件后继续运行Docker服务,这样我们就有了一个300G的大房子给Docker们用了。

大家以为事情到了这里就完结了么?其实我也想,但是我顺便折腾了一下,于是又发生了接下来的事情。说我手贱也好,瞎折腾也罢,导入一堆容器镜像和运行一堆容器后,系统又光荣告诉我所有的容器根目录全部变成了只读,宿主机内核同样报磁盘I/O错误,一开始我以为data目录又被写满了,但是用df –Th命令查看后,发现目录还有很多空间:

4.png


但是残酷的现实是,只用了不到一半的空间后,所有的容器就全部出现异常了,这是我祭出了经典三板斧:重启容器,重启Docker服务,重启服务器。然并卵,容器还是运行异常。通过在网上爬了一堆资料,在http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/上查到,CentOS默认用的是Device Mapper作为容器的存储驱动的,大家可以用dockers info命令查看,Docker服务启动时默认会在/var/lib/docker/devicemapper/devicemapper/目录创建一个100G(由于1000和1024换算的关系,系统实际显示的是107.4G,其他数字亦同)的data文件,然后启动的容器的所有变更的数据全部保存到这个data文件中;也就是说当容器内产生的相关data数据超过100G后容器就再也没有多余的空间可用,从而导致所有容器的根目录变为只读!同时它会限制每个容器最大为 10GB。太坑爹了有木有,给了大房子只能用100G!

5.png


为了找到根本原因,我们需要了解Device Mapper存储驱动的原理: Device Mapper存储驱动是以精简配置的方式运行的,它实际上是目标块设备的快照。
Docker启动时会设置一个100G的sparse文件( /var/lib/docker/devicemapper/devicemapper/data,元数据为/var/lib/docker/devicemapper/devicemapper/metadata ),并将其作为Device Mapper的存储池,而所有容器都从该存储池中分配默认10G的存储空间使用,如下图所示:

6.png


当有实际读写后,这些存储块将在存储池中被标记为已使用(或者从池中拿走)。当实际读写的块容量大于池的容量时,容器的运行空间不足,所以报I/O错误。

Device Mapper存储驱动非常方便,你不需要做任何安装部署便可以使用:如创建额外的分区来存储 Docker 容器,或者建立LVM。然而它也有两个缺点:
• 存储池会有一个默认 100GB 的容量,满足不了大存储的需求。
• 它将会被稀疏文件所支持(精简配置,一开始基本不占用空间,只有当实际需要写的时候才会使用磁盘的存储块)但性能较差。

针对这些问题,有两个解决方案:
  1. 使用更大的文件/磁盘/逻辑卷创建data文件:

7.png


  1. 通过Docker启动参数的--storage-opt选项来限制每个容器初始化的磁盘大小,如-storage-opt dm.basesize=80G 这样每个容器启动后,根目录的总空间就是80G。

但是我总觉得这样的解决方式不够优雅,需要多步操作才能满足需求,同时,容器的空间还是被限制的,只是限制的大小变化而已。那有没有更好的办法呢? 让我们继续来爬资料,在Docker的官方网站上:
(https://docs.docker.com/engine/reference/commandline/dockerd/)

8.png


Docker在存储驱动方面支持 AUFS、Device Mapper、Btrfs、ZFS、 Overlay 、Overlay2等多址方式,现由于AUFS并未并入内核,目前只有Ubuntu系统上能够使用aufs作为docker的存储引擎,而在CentOS系统上默认使用Device Mapper,但是幸运的是,在Linux内核3.18.0以上的版本,是可以原生支持Overlay驱动方式的,Overlayfs跟AUFS很像,但是性能比AUFS好,有更好的内存利用。

Docker通过-s参数选择存储驱动, 通过-s=overlay,我们将存储驱动器设置为Overlay方式,再重启Docker应用。

9.png


大家可以看到,现在Docker已经是使用了OverlayFS(这里大家要注意,如果系统有存储的镜像和运行的容器,更改存储驱动后将都不可用,请先行备份)。

通过修改为OverlayFS,Device Mapper的存储池容量限制及单个容器运行最大空间限制统统没有了,同时Overlay的读写性能也好于Device Mapper,只需通过-s=overlay一个参数即可优雅的使用更好的文件系统来运行容器。

至此,容器运行时I/O错误的原因已经完美解决,希望这篇文章能帮到在使用过程中遇到相同问题的朋友。

温馨提示:
Docker Live时代●Online Meetup-第二期《容器安全问题及解决之道》开始报名啦!

10.jpg


容器使用愈加广泛,当前国内外容器安全现状如何?对于在生产环境中的容器使用需要注意到哪些安全问题?针对这些问题又该如何避免和解决?答案尽在8月17日,Docker Live时代●Online Meetup-第二期《容器安全问题及解决之道》;有容云首席架构师马洪喜携手美女总监雷伟为您揭晓!

活动详情请点击:《Docker Live时代 | Online Meetup第二期-容器安全问题及解决之道》
活动报名请戳我:http://www.youruncloud.com/videos/meetup.html#start

为了性能,请不要在CentOS中运行Docker,尽量用Ubuntu

chenhl 发表了文章 • 7 个评论 • 25648 次浏览 • 2016-01-20 00:07 • 来自相关话题

【编者的话】生产环境里Docker运行在CentOS上似乎是大家的共识,但本文的作者通过自己在CentOS上使用Docker比在Ubuntu上性能缓慢的体验差异,决定转向在Ubuntu上使用Docker。你们是否对Docker运行在CentOS或Ubuntu上 ...查看全部
【编者的话】生产环境里Docker运行在CentOS上似乎是大家的共识,但本文的作者通过自己在CentOS上使用Docker比在Ubuntu上性能缓慢的体验差异,决定转向在Ubuntu上使用Docker。你们是否对Docker运行在CentOS或Ubuntu上的性能差异有自己的见解,下面让我们看看作者的理由。

多年来,我一直是一个铁杆的CentOS用户。我很喜欢它最小安装创建的轻量环境,直观的安装过程和包管理软件。Docker是当今最流行的容器格式,为开发人员和爱好者提供了一个在容器环境里运行任务的简单方法。我在生产环境中使用Docker大约有一年时间,运行的服务有Plex媒体服务器,博客的Web服务器,ZNC服务器,MineCraft服务和MySQL服务等等。Dockerfile是一组用来创建Docker镜像的指令。我投入了很多时间使用CentOS和Fedora制作完美的Dockerfile,它能简化安装和部署。然而,我现在却想换个环境:)

Docker在CentOS和Fedora上的性能非常差。出现这种情况的原因是因为Docker使用device mapper作为默认存储。Device Mapper是基于内核的框架,给人们提供一个现成的简单方法来使用Docker,并被认为比Linux上许多先进的卷管理技术更好。虽然有Device Mapper的替代方法,如使用OverlayFS等等,但对我来说它们的效果不太理想。当我建立一个容器时,Dockerfile中的每个步骤可能需要一分钟或更长时间才能完成,如添加一个zip文件到镜像中或替换配置文件中文本。我已经发现有关此主题的许多博客文章和已经公布的bug,但是我现在需要对该问题的一个可行的解决方案。

DigitalOcean.com是个不错的托管服务提供商,可以让你的虚拟服务器或应用程序如Docker运行在固态硬盘驱动器上的虚拟机里,每个月只需要5美元。当我尝试在Digital Ocean或Ubuntu上使用Docker时,性能是难以置信的快。当在Digital Ocean上通过CentOS使用Docker时,我同样感到性能欠佳。在使用Docker Machine(它是一种在Mac操作系统上使用VirtuaBox运行Docker的简单方式)时Docker的性能同样很棒。昨天晚上,根据我以往的生活经验,我最终决定必须对我的服务器进行改变,将其切换到了Ubuntu操作系统上。

我安装了Ubuntu 15.10服务器版,它在大多数情况下工作的很好。我认为CentOS/Fedora的安装程序领先Ubuntu一光年。例如,Ubuntu有繁琐的提示,而且配置磁盘并不和CentOS一样简单。最后,我只是有一个启动和运行比Ubuntu快的CentOS系统而已。我真的很喜欢Ubuntu的软件库,因为他们有所有我需要的Docker软件包,如随手可用的docker-compose。但在CentOS上,我需要手动安装额外的Docker仓库来获得相同的功能。Ubuntu使用AUFS作为Docker存储驱动程序。我不得不改变我所有的Dockerfile使用Ubuntu作为基础操作系统,这是因为我的一些现有Dockerfile因Docker的bug不能工作, 这些bug是由于在AUFS上使用CentOS/Fedora镜像导致的。

总之,完成这些是一个巨大的工作量,并且我睡的很晚。但是我认为这是对未来的一个巨大投资,这可以节省构建Docker容器的时间。正因为Ubuntu没有像CentOS/Fedora上相同的Docker问题,我现在可以毫不费力在云提供商之间迁移。

原文链接:Goodbye Docker on CentOS. Hello Ubuntu!(翻译:chenhl)

DockOne技术分享(二十九): 蘑菇街基于Docker的私有云实践

H3CSE 发表了文章 • 3 个评论 • 8575 次浏览 • 2015-11-04 18:18 • 来自相关话题

【编者的话】本次主要想分享一下过去一年时间里,我们在建设基于Docker的私有云实践过程中,曾经遇到过的问题,如何解决的经验,还有我们的体会和思考,与大家共勉。 ***郭嘉是@Container容器技术大会讲师,想一睹大师风采的同学欢 ...查看全部
【编者的话】本次主要想分享一下过去一年时间里,我们在建设基于Docker的私有云实践过程中,曾经遇到过的问题,如何解决的经验,还有我们的体会和思考,与大家共勉。

***郭嘉是@Container容器技术大会讲师,想一睹大师风采的同学欢迎报名参加大会,现场交流。
@Container大会是专为一线开发者和运维工程师设计的顶级容器技术会议,会议强调实践和交流,话题设置围绕容器、运维、云计算等技术领域,力求全方位、多角度为参会者解读容器技术。***

很高兴今天能在这里分享一下蘑菇街在生产环境中使用Docker的一些经历和经验。蘑菇街的私有云项目是2014年圣诞节期间上线的,从无到有,经过了半年多的发展,经历了3次大促,已经逐渐形成了一定的规模。
架构
# 集群管理
大家知道,Docker自身的集群管理能力在当时条件下还很不成熟,因此我们没有选择刚出现的Swarm,而是用了业界最成熟的OpenStack,这样能同时管理Docker和KVM。我们把Docker当成虚拟机来跑,是为了能满足业务上对虚拟化的需求。今后的思路是微服务化,把应用进行拆分,变成一个个微服务,实现PaaS基于应用的部署和发布。

通过OpenStack如何管理Docker?我们采用的是OpenStack+nova-docker+Docker的架构模式。nova-docker是StackForge上一个开源项目,它做为nova的一个插件,通过调用Docker的RESTful接口来控制容器的启停等动作。

我们在IaaS基础上自研了编排调度等组件,支持应用的弹性伸缩、灰度升级等功能,并支持一定的调度策略,从而实现了PaaS层的主要功能。

同时,基于Docker和Jenkins实现了持续集成(CI)。Git中的项目如果发生了git push等动作,便会触发Jenkins Job进行自动构建,如果构建成功便会生成Docker Image并push到镜像仓库。基于CI生成的Docker Image,可以通过PaaS的API或界面,进行开发测试环境的实例更新,并最终进行生产环境的实例更新,从而实现持续集成和持续交付。
# 网络和存储
网络方面,我们没有采用Docker默认提供的NAT网络模式,NAT会造成一定的性能损失。通过OpenStack,我们支持Linux bridge和Open vSwitch,不需要启动iptables,Docker的性能接近物理机的95%。
# 容器的监控
监控方面,我们自研了container tools,实现了容器load值的计算,替换了原有的top、free、iostat、uptime等命令。这样业务方在容器内使用常用命令时看到的是容器的值,而不是整个物理机的。目前我们正在移植Lxcfs到我们的平台上。

我们还在宿主机上增加了多个阈值监控和报警,比如关键进程监控、日志监控、实时pid数量、网络连接跟踪数、容器oom报警等等。
#冗灾和隔离性
冗灾和隔离性方面,我们做了大量的冗灾预案和技术准备。我们能够在不启动docker daemon的情况下,离线恢复Docker中的数据。同时,我们支持Docker的跨物理机冷迁移,支持动态的CPU扩容/缩容,网络IO磁盘IO的限速。
# 遇到的问题及解决方法
接近一年不到的产品化和实际使用中我们遇到过各种的问题,使用Docker的过程也是不断优化Docker、不断定位问题、解决问题的过程。

我们现在的生产环境用的是CentOS 6.5。曾经有个业务方误以为他用的Docker容器是物理机,在Docker容器里面又装了一个Docker,瞬间导致内核crash,影响了同一台物理机的其他Docker容器。

经过事后分析是2.6.32-431版本的内核对network namespace支持不好引起的,在Docker内创建bridge会导致内核crash。upstream修复了这个bug,从2.6.32-431升级到2.6.32-504后问题解决。

还有一个用户写的程序有bug,创建的线程没有及时回收,容器中产生了大量的线程,最后在宿主机上都无法执行命令或者ssh登陆,报的错是"bash: fork: Cannot allocate memory",但通过free看空闲的内存却是足够的。

经过分析,发现是内核对pid的隔离性支持不完善,pid\_max(/proc/sys/kernel/pid\_max)是全局共享的。当一个容器中的pid数目达到上限32768,会导致宿主机和其他容器无法创建新的进程。最新的4.3-rc1才支持对每个容器进行pid_max限制。

我们还观察到docker的宿主机内核日志中会产生乱序的问题。经过分析后发现是由于内核中只有一个log\_buf缓冲区,所有printk打印的日志先放到这个缓冲区中,docker host以及container上的rsyslogd都会通过syslog从kernel的log\_buf缓冲区中取日志,导致日志混乱。通过修改container里的rsyslog配置,只让宿主机去读kernel日志,就能解决这个问题。

除此之外,我们还解决了device mapper的dm-thin discard导致内核crash等问题。
体会和思考
最后分享一下我们的体会和思考,相比KVM比较成熟的虚拟化技术,容器目前还有很多不完善的地方,除了集群管理、网络和存储,最重要的还是稳定性。影响稳定性的主要还是隔离性的不完善造成的,一个容器内引起的问题可能会影响整个系统。

容器的memcg无法回收slab cache,也不对dirty cache量进行限制,更容易发生OOM问题。还有,procfs上的一些文件接口还无法做到per-container,比如pid_max。

另外一点是对容器下的运维手段和运维经验的冲击。有些系统维护工具,比如ss,free,df等在容器中无法使用了,或者使用的结果跟物理机不一致,因为系统维护工具一般都会访问procfs下的文件,而这些工具或是需要改造,或是需要进行适配。

虽然容器还不完善,但是我们还是十分坚定的看好容器未来的发展。Kubernetes、Mesos、Hyper、CRIU、runC等容器相关的开源软件,都是我们关注的重点。
Q&A
Q:请问容器间的负载均衡是如何做的?

A: 容器间的负载均衡,更多是PaaS和SaaS层面的。我们的P层支持4层和7层的动态路由,通过域名的方式,或者名字服务来暴露出对外的接口。我们能够做到基于容器的灰度升级,和弹性伸缩。



Q:请问你们的OpenStack是运行在CentOS 6.5上的吗?

A: 是的,但是我们针对OpenStack和Docker依赖的包进行了升级。我们维护了内部的yum源。



Q:请问容器IP是静态编排还是动态获取的?

A: 这个跟运维所管理的网络模式有关,我们内部的网络没有DHCP服务,因此对于IaaS层,容器的IP是静态分配的。对于PaaS层来说,如果有DHCP服务,容器的App所暴露出来IP和端口就可以做到动态的。



Q:请问你们当时部署的时候有没有尝试过用Ubuntu,有没有研究过两个系统间的区别,另外请问你们在OpenStack上是怎样对这些虚拟机监控的?

A: 我们没有尝试过Ubuntu,因为公司生产环境上用的是CentOS。我们的中间件团队负责公司机器的监控,我们和监控团队配合,将监控的agent程序部署到宿主机和每个容器里,这样就可以当成虚拟机来进行监控。
当然,容器的数据是需要从cgroups里来取,这部分提取数据的工作,是我们来实现的。



Q:容器间的网络选型有什么建议,据说采用虚拟网卡比物理网卡有不小的性能损失,Docker自带的weaves和ovs能胜任吗?

A: 容器的网络不建议用默认的NAT方式,因为NAT会造成一定的性能损失。之前我的分享中提到过,不需要启动iptables,Docker的性能接近物理机的95%。Docker的weaves底层应该还是采用了网桥或者Open vSwitch。建议可以看一下nova-docker的源码,这样会比较容易理解。



Q:静态IP通过LXC实现的吗?

A: 静态IP的实现是在nova-docker的novadocker/virt/docker/vifs.py中实现的。实现的原理就是通过ip命令添加veth pair,然后用ip link set/ip netns exec等一系列命令来实现的,设置的原理和weaves类似。



Q:容器内的进程gdb你们怎么弄的,把gdb打包到容器内吗?

A: 容器内的gdb不会有问题的,可以直接yum install gdb。



Q:共享存储能直接mount到容器里吗?

A: 虽然没试过,但这个通过docker -v的方式应该没什么问题。



Q:不启动Docker Daemon的情况下,离线恢复Docker中的数据是咋做到的?

A: 离线恢复的原理是用dmsetup create命令创建一个临时的dm设备,映射到Docker实例所用的dm设备号,通过mount这个临时设备,就可以恢复出原来的数据。



Q:Docker的跨物理机冷迁移,支持动态的CPU扩容/缩容,网络IO磁盘IO的限速,是怎么实现的,能具体说说吗?

A:Docker的冷迁移是通过修改nova-docker,来实现OpenStack迁移的接口,具体来说,就是在两台物理机间通过docker commit,docker push到内部的registry,然后docker pull snapshot来完成的。
动态的CPU扩容/缩容,网络IO磁盘IO的限速主要是通过novadocker来修改cgroups中的cpuset、iops、bps还有TC的参数来实现的。



Q:请问你们未来会不会考虑使用Magnum项目,还是会选择Swarm?

A:这些都是我们备选的方案,可能会考虑Swarm。因为Magnum底层还是调用了Kubernetes这样的集群管理方案,与其用Magnum,不如直接选择Swarm或者是Kubernetes。当然,这只是我个人的看法。



Q:你们的业务是基于同一个镜像么,如果是不同的镜像,那么计算节点如何保证容器能够快速启动?

A:运维会维护一套统一的基础镜像。其他业务的镜像会基于这个镜像来制作。我们在初始化计算节点的时候就会通过docker pull把基础镜像拉到本地,这也是很多公司通用的做法,据我了解,腾讯、360都是类似的做法。



Q:做热迁移,有没有考虑继续使用传统共享存储的来做?

A: 分布式存储和共享存储都在考虑范围内,我们下一步,就计划做容器的热迁移。



Q:请问你们是直接将公网IP绑定到容器吗,还是通过其他方式映射到容器的私有IP,如果是映射如何解决原本二层的VLAN隔离?

A:因为我们是私有云,不涉及floating ip的问题,所以你可以认为是公网IP。VLAN的二层隔离完全可以在交换机上作。我们用Open vSwitch划分不同的VLAN,就实现了Docker容器和物理机的网络隔离。



Q:Device mapper dm-thin discard问题能说的详细些吗?

A:4月份的时候,有两台宿主机经常无故重启。首先想到的是查看/var/log/messages日志,但是在重启时间点附近没有找到与重启相关的信息。而后在/var/crash目录下,找到了内核crash的日志vmcore-dmesg.txt。日志的生成时间与宿主机重启时间一致,可以说明宿主机是发生了kernel crash然后导致的自动重启。“kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181!”。 从堆栈可以看出在做dm-thin的discard操作(process prepared discard),虽然不知道引起bug的根本原因,但是直接原因是discard操作引发的,可以关闭discard support来规避。
> 我们将所有的宿主机配置都禁用discard功能后,再没有出现过同样的问题。
> 在今年CNUTCon的大会上,腾讯和大众点评在分享他们使用Docker的时候也提到了这个crash,他们的解决方法和我们完全一样。



Q:阈值监控和告警那块,有高中低多种级别的告警吗,如果当前出现低级告警,是否会采取一些限制用户接入或者砍掉当前用户正在使用的业务,还是任由事态发展?

A:告警这块,运维有专门的PE负责线上业务的稳定性。当出现告警时,业务方和PE会同时收到告警信息。如果是影响单个虚拟机的,PE会告知业务方,如果严重的,甚至可以及时下掉业务。我们会和PE合作,让业务方及时将业务迁移走。



Q:你们自研的container tools有没有开源,GitHub上有没有你们的代码,如何还没开源,后期有望开源吗,关于监控容器的细粒度,你们是如何考虑的?

A:虽然我们目前还没有开源,单我觉得开源出来的是完全没问题的,请大家等我们的好消息。关于监控容器的细粒度,主要想法是在宿主机层面来监控容器的健康状态,而容器内部的监控,是由业务方来做的。



Q:请问容器的layer有关心过层数么,底层的文件系统是ext4么,有优化策略么?

A:当然有关心,我们通过合并镜像层次来优化docker pull镜像的时间。在docker pull时,每一层校验的耗时很长,通过减小层数,不仅大小变小,docker pull时间也大幅缩短。



Q:容器的memcg无法回收slab cache,也不对dirty cache量进行限制,更容易发生OOM问题。----这个缓存问题你们是怎么处理的?

A:我们根据实际的经验值,把一部分的cache当做used内存来计算,尽量逼近真实的使用值。另外针对容器,内存报警阈值适当调低。同时添加容器OOM的告警。如果升级到CentOS 7,还可以配置kmem.limit_in_bytes来做一定的限制。



Q:能详细介绍下你们容器网络的隔离?

A:访问隔离,目前二层隔离我们主要用VLAN,后面也会考虑VXLAN做隔离。 网络流控,我们是就是使用OVS自带的基于port的QoS,底层用的还是TC,后面还会考虑基于flow的流控。



Q:请问你们这一套都是用的CentOS 6.5吗,这样技术的实现。是运维还是开发参与的多?

A:生产环境上稳定性是第一位的。CentOS 6.5主要是运维负责全公司的统一维护。我们会给运维在大版本升级时提建议。同时做好虚拟化本身的稳定性工作。



Q:请问容器和容器直接是怎么通信的?网络怎么设置?

A:你是指同一台物理机上的吗?我们目前还是通过IP方式来进行通信。具体的网络可以采用网桥模式,或者VLAN模式。我们用Open vSwitch支持VLAN模式,可以做到容器间的隔离或者通信。



Q:你们是使用nova-api的方式集成Dcoker吗,Docker的高级特性是否可以使用,如docker-api,另外为什么不使用Heat集成Docker?

A:我们是用nova-docker这个开源软件实现的,nova-docker是StackForge上一个开源项目,它做为nova的一个插件,替换了已有的libvirt,通过调用Docker的RESTful接口来控制容器的启停等动作。
> 使用Heat还是NOVA来集成Docker业界确实一直存在争议的,我们更多的是考虑我们自身想解决的问题。Heat本身依赖的关系较为复杂,其实业界用的也并不多,否则社区就不会推出Magnum了。



Q:目前你们有没有容器跨DC的实践或类似的方向?

A:我们已经在多个机房部署了多套集群,每个机房有一套独立的集群,在此之上,我们开发了自己的管理平台,能够实现对多集群的统一管理。同时,我们搭建了Docker Registry V1,内部准备升级到Docker Registry V2,能够实现Docker镜像的跨DC mirror功能。



Q:我现在也在推进Docker的持续集成与集群管理,但发现容器多了管理也是个问题,比如容器的弹性管理与资源监控,Kubernetes、Mesos哪个比较好一些,如果用在业务上,那对外的域名解析如何做呢,因为都是通过宿主机来通信,而它只有一个对外IP?

A: 对于Kubernetes和Mesos我们还在预研阶段,我们目前的P层调度是自研的,我们是通过etcd来维护实例的状态,端口等信息。对于7层的可以通过Nginx来解析,对于4层,需要依赖于naming服务。我们内部有自研的naming服务,因此我们可以解决这些问题。对外虽然只有一个IP,但是暴露的端口是不同的。



Q:你们有考虑使用Hyper Hypernetes吗? 实现容器与宿主机内核隔离同时保证启动速度?

A:Hyper我们一直在关注,Hyper是个很不错的想法,未来也不排除会使用Hyper。其实我们最希望Hyper实现的是热迁移,这是目前Docker还做不到的。



Q:你们宿主机一般用的什么配置?独立主机还是云服务器?

A:我们有自己的机房,用的是独立的服务器,物理机。



Q:容器跨host通信使用哪一种解决方案?

A: 容器跨host就必须使用3层来通信,也就是IP,容器可以有独立的IP,或者宿主机IP+端口映射的方式来实现。我们目前用的比较多的还是独立ip的方式,易于管理。



Q:感觉贵公司对Docker的使用比较像虚拟机,为什么不直接考虑从容器的角度来使用,是历史原因么?

A:我们首先考虑的是用户的接受程度和改造的成本。从用户的角度来说,他并不关心业务是跑在容器里,还是虚拟机里,他更关心的是应用的部署效率,对应用本身的稳定性和性能的影响。从容器的角度,一些业务方已有的应用可能需要比较大的改造。比如日志系统,全链路监控等等。当然,最主要的是对已有运维系统的冲击会比较大。容器的管理对运维来说是个挑战,运维的接受是需要一个过程的。
> 当然,把Docker当成容器来封装应用,来实现PaaS的部署和动态调度,这是我们的目标,事实上我们也在往这个方向努力。这个也需要业务方把应用进行拆分,实现微服务化,这个需要一个过程。



Q:其实我们也想用容器当虚拟机使用。你们用虚拟机跑什么中间件?我们想解决测试关键对大量相对独立环境WebLogic的矛盾?

A:我们跑的业务有很多,从前台的主站Web,到后端的中间件服务。我们的中间件服务是另外团队自研的产品,实现前后台业务逻辑的分离。



Q:贵公司用OpenStack同时管理Docker和KVM是否有自己开发Web配置界面,还是单纯用API管理?

A:我们有自研的Web管理平台,我们希望通过一个平台管理多个集群,并且对接运维、日志、监控等系统,对外暴露统一的API接口。



Q:上面分享的一个案例中,关于2.6内核namespace的bug,这个低版本的内核可以安装Docker环境吗,Docker目前对procfs的隔离还不完善,你们开发的container tools是基于应用层的还是需要修改内核?

A:安装和使用应该没问题,但如果上生产环境,是需要全面的考虑的,主要还是稳定性和隔离性不够,低版本的内核更容易造成系统crash或者各种严重的问题,有些其实不是bug,而是功能不完善,比如容器内创建网桥会导致crash,就是network namespace内核支持不完善引起的。
> 我们开发的container tools是基于应用的,不需要修改内核。



Q:关于冗灾方面有没有更详细的介绍,比如离线状态如何实现数据恢复的?

A:离线状态如何实现恢复数据,这个我在之前已经回答过了,具体来说,是用dmsetup create命令创建一个临时的dm设备,映射到docker实例所用的dm设备号,通过mount这个临时设备,就可以恢复出原来的数据。其他的冗灾方案,因为内容比较多,可以再另外组织一次分享了。你可以关注一下http://mogu.io/,到时候我们会分享出来。



Q:贵公司目前线上容器化的系统,无状态为主还是有状态为主,在场景选择上有什么考虑或难点?

A:互联网公司的应用主要是以无状态的为主。有状态的业务其实从业务层面也可以改造成部分有状态,或者完全不状态的应用。不太明白你说的场景选择,但我们尽量满足业务方的各种需求。
> 对于一些本身对稳定性要求很高,或对时延IO特别敏感,比如redis业务,无法做到完全隔离或者无状态的,我们不建议他们用容器。



=============================================================
以上内容根据2015年11月03日晚微信群分享内容整理。分享人:郭嘉,蘑菇街平台技术部高级工程师,虚拟化组责任人。2014年加入蘑菇街,目前主要专注于蘑菇街的私有云建设,关注Docker、KVM、OpenStack、Kubernetes等领域。DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesx,进群参与,您有想听的话题可以给我们留言。

CentOS 7上安装Docker 1.8

unodba 发表了文章 • 0 个评论 • 28696 次浏览 • 2015-08-26 23:54 • 来自相关话题

【编者的话】本文主要根据官方安装文档翻译而来,添加了部分安装过程遇到的问题解析。 Docker支持运行在以下CentOS版本: * CentOS 7.X 安装在二进制兼容的EL7版本 ...查看全部
【编者的话】本文主要根据官方安装文档翻译而来,添加了部分安装过程遇到的问题解析。

Docker支持运行在以下CentOS版本:

* CentOS 7.X

安装在二进制兼容的EL7版本如 Scientific Linux也是可能成功的,但是Docker
没有测试过并且不官方支持。

此文带你通过使用Docker管理的发行包和安装机制来安装。使用这些报能确保你使用最新的Docker版本。
如果你希望使用CentOS管理的包,请阅读你的CentOS文档。
#要求
不过你的系统版本是多少,Docker都要求64位。并且当CentOS7时你的内核必须不小于3.10。

检查当前内核版本:
# uname -r
3.10.0-229.el7.x86_64

建议将系统升级到最新。
#安装
有两种方式可安装Docker Engine。脚本安装和yum安装。
##脚本安装
1.使用root权限登陆系统。
2.更新系统包到最新。
# yum -y update

3.执行Docker安装脚本
# curl -sSL https://get.docker.com/ | sh
# yum install -y docker-selinux

这个脚本会添加`docker.repo` 配置并安装Docker。
4.启动Docker
# systemctl start docker.service

5.验证docker已经正常安装
# docker run hello-world

##yum安装
1.使用root权限登陆系统。
2.更新系统包到最新。
# yum -y update

3.添加yum仓库
# cat >/etc/yum.repos.d/docker.repo <<-EOF
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

4.安装Docker包
# yum install -y docker-engine
# yum install -y docker-selinux
# yum list installed | grep docker
docker-engine.x86_64 1.8.1-1.el7.centos @dockerrepo
docker-selinux.x86_64 1.7.1-108.el7.centos @extras

这里有个非常坑的情况,官方文档没有提到docker-selinux的安装,笔者在使用VirtualBox,配置一个桥接,一个Host-Only的网卡时,只安装docker-engine启动会报错,需要在安装docker-selinux方可。
可以看github上的两个issues,1.8.0: Systemd can't start docker on Centos 7.1 #15498,Docker start times out if firewalld is started #13019
5.启动Docker
# systemctl start docker.service

6.验证docker已经正常安装
# docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
535020c3e8ad: Pull complete
af340544ed62: Already exists
library/hello-world:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:d5fbd996e6562438f7ea5389d7da867fe58e04d581810e230df4cc073271ea52
Status: Downloaded newer image for hello-world:latest

Hello from Docker.
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
$ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker Hub account:
https://hub.docker.com

For more examples and ideas, visit:
https://docs.docker.com/userguide/

#创建docker组
Docker daemon绑定到Unix socket而不是TCP端口。默认下Unix socket属于root用户拥有并且其他用户可以通过sudo访问。因为这个原因docker daemon总是使用root用户运行。

为了避免每次使用docker命令都使用sudo,创建一个docker的Unix组并且将用户加入。当docker daemon启动时,使得Unix socket对docker组是可读写的。

警告:docker组等同于root用户;关于这会如何影响你系统的安全性,详情参考Docker Daemon Attack Surface
1.使用超户权限登陆并添加docker用户
# useradd -g docker docker
# echo "docker" | passwd --stdin docker

2.创建docker用户组
# usermod -aG docker your-user

your-user指预使用的普通用户,第一步如果创建docker用户时需要制定属于docker组,不然会再次创建docker,无法创建docker用户。
3.登出并使用docker重新登陆
这保证你的用户正确的权限运行。
4.不使用sudo运行docker验证正常
$ docker run hello-world

#开机自启动
配置Docker开机自启动:
  #  systemctl enable docker.service

If you need to add an HTTP Proxy, set a different directory or partition for the Docker runtime files, or make other customizations, read our Systemd article to learn how to customize your Systemd Docker daemon options.
#卸载
使用yum卸载Docker。
1.列出安装的软件包
$ yum list installed | grep docker
yum list installed | grep docker
docker-engine.x86_64 1.8.1-1.el7.centos @dockerrepo
docker-selinux.x86_64 1.7.1-108.el7.centos @extras

2.移除软件包
$ sudo yum -y remove docker-engine.x86_64

上面的命令不会删除镜像,容器,卷组和用户自配置文件。
3.删除所有镜像,容器和卷组
$ rm -rf /var/lib/docker

4.删除用户自配置文件

为什么我们不允许非root用户在CentOS、Fedora和RHEL上直接运行Docker命令

KiwenLau 发表了文章 • 0 个评论 • 13148 次浏览 • 2015-08-15 16:40 • 来自相关话题

【编者的话】容器技术最大的弱点是安全性不足,Docker也不例外。因此,如何加强Docker的安全性是每一个Docker用户必须慎重考虑的问题。这篇文章介绍了不用sudo而直接运行Docker命令所存在的安全漏洞,并强烈建议通过设置sudo规则作为暂时的解决方 ...查看全部
【编者的话】容器技术最大的弱点是安全性不足,Docker也不例外。因此,如何加强Docker的安全性是每一个Docker用户必须慎重考虑的问题。这篇文章介绍了不用sudo而直接运行Docker命令所存在的安全漏洞,并强烈建议通过设置sudo规则作为暂时的解决方法。

我经常会收到用户反馈的Bug,他们问我们『为什么默认情况下不能使用非root用户直接运行Docker命令』。

Docker能够将`/run/docker.socket`的文件访问权限设为660,并将其所属的用户组设为`docker`。 这使得非root用户只要加入`docker`用户组,就无需使用`sudo`,或者通过`su`命令切换到root用户的情况下运行Docker命令。这听起来很不错。
ls -l /var/run/docker.sock 
srw-rw----. 1 root docker 0 Aug 3 13:02 /var/run/docker.sock

但是,在RHEL、Fedora和CentOS上,我们更喜欢将`doker.socket`设置为:
ls -l /var/run/docker.sock 
srw-rw----. 1 root root 0 Aug 3 13:02 /var/run/docker.sock

为什么呢?原因很简单:如果用户可以与Docker Socket通信,他们就能够执行以下命令:
docker run -ti --privileged -v /:/host fedora chroot /host

这时用户将拥有主机的完全控制权。这就相当于将sudoers文件修改为以下内容(译者注:dwalsh为用户名):
grep dwalsh /etc/sudoers
dwalsh ALL=(ALL) NOPASSWD: ALL

这将允许(dwalsh)用户无密码运行所有命令,获得主机的完全控制权。但是这有一个很大的安全漏洞。Docker命令没有内置的审计和日志功能,但是sudo有。

Docker目前会记录事件,但是Docker daemon重启时事件会消失。Docker目前没有审计功能。

从安全性的角度,红帽已经表达了允许非root用户在没有审计(auditing)和适当的日志的情况下访问Docker Daemon的顾虑。我们已经在PR14446实现了这些控制,它依靠了一个认证机制,但这个机制还在讨论中。在我们实现了审计和日志功能之前,我们推荐通过设置sudo规则来访问Docker Daemon。这将允许sudo来提供审计和日志功能。
##设置sudo规则
如果你希望非root用户能够直接执行Docker命令,我们推荐通过设置sudo规则来实现。下面是设置Docker规则的简单教程。

在`/ect/sudoers`中添加以下内容: [译者注:使用visudo命令修改]
grep dwalsh /etc/sudoers
dwalsh ALL=(ALL) NOPASSWD: /usr/bin/docker

这允许特定用户无需密码直接执行Docker命令。

注意:我并不推荐使用NOPASSWD,这可能会导致你的系统中的任意进程都能获取root权限。如果你要求使用密码,则用户在运行Docker命令时需要输入密码,这将使得系统稍微安全一点。如果执行命令时输入了一次密码,则sudo将允许你在5分钟内再次运行Docker命令时不再需要输入密码。

紧接着,为Docker命令设置别名。
alias docker="sudo /usr/bin/docker"

现在,非root用户将被允许直接执行Docker命令(译者注:不需要使用sudo),并且记录了日志。
docker run -ti --privileged -v /:/host fedora chroot /host

查看journal日志或者/var/log信息:
journalctl -b | grep docker.*privileged
Aug 04 09:02:56 dhcp-10-19-62-196.boston.devel.redhat.com sudo[23422]: dwalsh : TTY=pts/3 ; PWD=/home/dwalsh/docker/src/github.com/docker/docker ; USER=root ; COMMAND=/usr/bin/docker run -ti --privileged -v /:/host fedora chroot /host

查看审计日志:
ausearch -m USER_ROLE_CHANGE -i
type=USER_ROLE_CHANGE msg=audit(08/04/2015 09:02:56.514:1460) : pid=23423 uid=root auid=dwalsh ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='newrole: old-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
new-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe=/usr/bin/sudo hostname=? addr=? terminal=/dev/pts/3 res=success'

##更强的安全性
如果你打算只允许用户访问一个特定的容器,你可以写一个简单的脚本:
cat /usr/bin/docker-fedora
#!/bin/sh
docker run -ti --rm fedora /bin/sh

写好脚本之后,配置sudoers:
grep dwalsh /etc/sudoers
dwalsh ALL=(ALL) NOPASSWD: /usr/bin/docker-fedora

这个用户将仅能在没有权限限制下运行Fedora容器。
##认证
我们还在开发其它程序补丁来增强Docker Daemon安全性,其中包括认证方面。我们有一个正在讨论的问题#13697“为Docker增加kerberos支持”
##授权
我们还提议为Docker增加授权/RBAC(基于角色的访问控制),这样管理员就可以控制哪些用户可以使用哪些容器/镜像进行哪些活动。如果你想查看这个提议或者评论或者提出建议,提议地址为:GitHub: rhatdan/docker-rbac
##结论
如果需要支持非root用户直接运行Docker命令之前,那Docker Daemon的安全性还需要很多改进。但在这些改进实现之前,设置sudo规则是最好的选择。我们正在开发更好的解决方案,暂时我们仍然强烈推荐使用sudo。。

原文链接:Why we don't let non-root users run Docker in CentOS, Fedora, or RHEL (翻译:刘凯 审校:李颖杰)

========================================
译者介绍:
刘凯:毕业于中国科学技术大学,目前在日本国立信息学研究所攻读云计算方向的博士学位,近期专注于Docker技术的研究。个人站点:GitHubKiwenLau

如何在Docker上运行Ubuntu Core

jeffsui 发表了文章 • 0 个评论 • 6413 次浏览 • 2015-06-17 17:43 • 来自相关话题

【编者的话】Snappy是一个极度精简的Ubuntu镜像,因为它可以快速部署在云端,并且提供了简便的基础功能组件更新,所以很多人用来在云端上构建(微)系统架构。很可惜Snappy并不包含在Docker的官方镜像中,本文通过一个实例演示了如何在Docker中运行 ...查看全部
【编者的话】Snappy是一个极度精简的Ubuntu镜像,因为它可以快速部署在云端,并且提供了简便的基础功能组件更新,所以很多人用来在云端上构建(微)系统架构。很可惜Snappy并不包含在Docker的官方镜像中,本文通过一个实例演示了如何在Docker中运行Ubuntu Core镜像,并构建自己的Snappy容器。文章短小精悍,希望能给使用Snappy系统并希望用Docker来构建系统架构的人一些有益的借鉴。

有很多人已经听说过 Ubuntu Core的大名,没听过也不要紧, Ubuntu Core 是一个极度精简的ubuntu版本。它通过Snappy(一个包管理器)来运行一些基本服务并提供主要的功能组件更新。Ubuntu Core 提供轻量级的基本运行时系统,给使用者以快速部署和方便的持续更新功能。并且在它上面还使用了 security model

上述这些令人激动的特性使得Snappy可以快速部署在云平台上。与此同时,人们已经开始考虑使用它在云端上来构建他们自己的(微)服务架构。就在几周前,一个用户在 Ask Ubuntu 上提问题:Can I run Snappy Ubuntu Core as a guest inside Docker? 。问题在于Ubuntu Core并不包含在Docker提供的官方镜像库中,所以我们自己手动创建镜像了。下面是一个例子:
# 创建 Docker 镜像
#步骤一: 获取最新的Ubuntu Core镜像
截止发稿时为止,Ubuntu Core 的版本是 alpha 3 ,下载地址为 :
$ wget http://cdimage.ubuntu.com/ubuntu-core/releases/alpha-3/ubuntu-core-WEBDM-alpha-03_amd64-generic.img.xz

(如果你访问这个网址 cdimage.ubuntu.com,可以获取带有hash签名的版本)

下载的镜像是通过XZ方式压缩的,所以要通过下面的命令解压:
$ unxz ubuntu-core-WEBDM-alpha-03_amd64-generic.img.xz

#步骤二: 使用`qemu-nbd`方式连接镜像
解压后的文件不是普通的文件格式,上一个版本(Alpha 2)镜像是`QCOW2`文件格式,为了能够使用这个镜像内容,我们有几个解决方案。这里我介绍其中的一种,既可以使用文件系统又可以使用`QCOW2` 镜像的方式。下面的小技巧包含使用`qemu-nbd`(一个基于 qemu-utils)的工具包):
# qemu-nbd -rc /dev/nbd0 ubuntu-core-WEBDM-alpha-03_amd64-generic.img

运行上面的命令将会创建一个名为 `/dev/nbd0`的虚拟设备,并且创建 名为 `/dev/nbd0p1`、`/dev/nbd0p2`,诸如此类的虚拟分区,可以通过 使用`fdisk -l /dev/nbd0`命令,查看关于`QCOW2` 镜像相关的信息。
#步骤三: 挂载文件系统
例如我们感兴趣的是`/dev/nbd0p3`,我们通过下面的命令来挂载分区:
# mkdir nbd0p3
# mount -r /dev/nbd0p3 nbd0p3

#步骤四:创建一个基于docker的基础镜像
建议阅读 Docker官方手册,创建一个简单的Docker基础镜像。
tar -C nbd0p3 -c . | docker import - ubuntu-core alpha-3

通过运行`docker images`命令,我们可以查看我们刚刚创建的Docker镜像。
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu-core alpha-3 f6df3c0e2d74 5 seconds ago 543.5 MB

通过这个命令`docker run ubuntu-core:alpha-3 Snappy`,让我们验证一下Snappy是否可以访问:
# docker run ubuntu-core:alpha-3 Snappy
Usage:Snappy [-h] [-v]
{info,versions,search,update-versions,update,rollback,install,uninstall,tags,config,build,booted,chroot,framework,fake-version,nap}
...

如果看到上面的信息,那么恭喜你,已经成功将Ubuntu Core融入到Docker镜像中,第一次运行了Snappy容器。
安装软件
废话不多说,下面演示如何在docker中安装并运行 ` xkcd-webserver` Snappy包管理器。
# docker run -p 8000:80 ubuntu-core:alpha-3 /bin/sh -c 'Snappy install xkcd-webserver 

原文链接:Running Ubuntu Snappy inside Docker(翻译:隋鑫 审校:魏小红)

DockOne技术分享(六):新浪SCE Docker最佳实践

wangzi19870227 发表了文章 • 13 个评论 • 11776 次浏览 • 2015-06-03 11:36 • 来自相关话题

【编者的话】本文主要从IaaS视角,分享SCE通过怎样的实践来支持上层产品线的容器化诉求。首先聊聊我们为什么做支持Docker技术这件事情,然后介绍下Docker支持实践的方方面面。最后给出实践过程中总结出来的一些经验及踩过的一些坑,以及后续需要深耕的点。 ...查看全部
【编者的话】本文主要从IaaS视角,分享SCE通过怎样的实践来支持上层产品线的容器化诉求。首先聊聊我们为什么做支持Docker技术这件事情,然后介绍下Docker支持实践的方方面面。最后给出实践过程中总结出来的一些经验及踩过的一些坑,以及后续需要深耕的点。

先假定今晚的听众至少已经小范围使用过Docker技术,熟悉相关概念及原理。

前几期DockOne技术分享已经针对Docker的几个技术要点做了深入分析,所以我今晚主要从IaaS视角,分享SCE通过怎样的实践来支持上层产品线的容器化诉求。

----------

为何支持Docker技术

#为何做这件事
先介绍下我浪SCE。SCE是新浪研发中心主推私有云产品,已经覆盖到公司内部所有产品线。基于OpenStack定制,整合了公司通道机、CMDB,为公司内部全产品线提供IaaS服务。公有云版本近期开始内测。

首先,OpenStack与Docker天生互补。

  • OpenStack面向IaaS,以资源为中心,打包OS;能够提供成熟的资源限制与隔离能力;多OS系列支持;
  • Docker则面向PaaS,以服务为中心,打包service;轻快好省;

目前IaaS业界主要以提供云主机服务为主,有着成熟的资源限制、资源隔离能力,但本质上是对OS的打包,无法满足在应对峰值访问、快速伸缩、快速部署等方面诉求。而docker与生俱来的特性”轻、快、好、省“,则恰恰可以弥补IaaS在此方面的不足。当然OpenStack社区为了能够更好的支持docker也尝试做了很多努力,这个后面会讲到。

其次,SCE运维过程发现,产品线对容器技术需求相当旺盛。

- 快速部署;
- 快速起停、创建与销毁;
- 一致的开发测试环境;
- 演示、试用环境;
- 解决设备成本,充分利用资源;
- 技术方案快速验证;
- 更多......

IaaS短板+需求驱动,让我们意识到:SCE很有必要也很适合做支持容器技术这件事。

#IaaS厂商Docker支持概况

调研分析了几个IaaS圈子比较有代表性的巨头及新贵,从调研结果可以看出,目前IaaS厂商对Docker的支持还比较薄弱。

只有阿里云为Docker用户多做了一些事情,提供了阿里官方Registry。但没有提供较新的支持Docker的云主机,只有一个第三方提供了一个很老的镜像,几乎没有可用性。

UnitedStack和青云只提供了CoreOS。而实际上,CoreOS的用户接受度很低。我们SCE也尝试过提供CoreOS,但由于和公司CentOS系统使用方式差异太大,基本没有产品线愿意使用并迁移到CoreOS上面来。

----------

Docker支持实践的方方面面
基于以上需求及调研,SCE主要在Registry、Hub、支持Docker的虚拟机镜像、日志存储与检索、网络及存储驱动等方面做了一些实践,致力于让产品线用户更方便高效的使用Docker技术,推动Docker在公司内的使用。
#Registry+Hub方案
Registry后端存储方案方面,其实大家已分享较多,大多是用dev及s3。SCE当然使用自家新浪S3了,当时的第一个方案就是Docker Registry sinastorage driver + sina s3。可靠性性自然不用多言,但由于依赖storage driver,追查问题过程中,调试及维护都比较麻烦,并且更新后还需要自动构建新镜像。

既然自家提供可靠云硬盘,为什么不为自己提供服务呢。果断将忍了老鼻子时间的方案一改为了localstorage + SCE云硬盘,不再依赖driver的日子舒服多了,另外还能享受到云硬盘的snapshot、resize等高级特性。

所以,对于正在Registry storage backend选型的朋友,给出一些建议以供参考:

- 对镜像存储可靠性无要求的使用场景,建议直接使用dev;
- 对镜像存储可靠性要求较高的使用场景,如果你是在IaaS上跑,强烈建议使用localstorage + 云硬盘方案;
- 对镜像存储可靠性要求较高的使用场景,如果你没在IaaS上跑,可以拿点大洋出来用S3等;
- 对镜像存储可靠性要求较高的使用场景,如果你没在IaaS上跑,又不想花钱,想用自家存储,就只能写个自家的driver了。我才不会告诉你,这种情况排查问题有多么糟心。

为了给产品线提供便捷的镜像查看及检索服务,SCE与微博平台合作,共同推出了SCE docker hub,基于docker-registry-frontend开发实现。与SCE现有服务打通,并支持repo、tag、详细信息、Dockerfile的查看、检索与管理等。

为了产品线更方便使用Docker官方镜像,我们的自动同步工具会依据镜像注册表,周期性的自动同步Docker官方镜像到SCE分布式后端存储集群,使得产品线用户可以通过内网快速pull到Docker官方镜像。

由于SCE不保证也不可能保证Docker Hub官方镜像的安全性,所以建议产品线最好使用SCE官方发布的image或构建自己的baseimage。

对于产品线私有Registry的需求,SCE也提供了相应的一键构建工具集。

#CentOS 7 + Docker镜像
SCE在Docker支持方面主要做了如下一些工作:
1)集成Docker 1.5、Docker-Compose 1.2环境;
2)提供docker-ip、docker-pid、docker-enter等cli,简化用户使用;
3)与DIP合作,支持rsyslog-kafka,解决日志监控检索问题;
4)与微博平台合作,提供muti-if-adapter工具,解决同一主宿机相同服务端口冲突的问题;
5) 更多......

#SCE上使用Docker
有了如上工作支撑,在SCE上使用docker就变得相当便捷。
SCE上使用docker.png

#日志方案
目前SCE主要支持3中日志方案:

- app打container logfile;
- app打stdout,stderr;
- app+agent打远端;

前两种方案适用于对日志要求不高的使用场景,如开发测试。
第三种方案则适用于真实的业务场景、生产环境,这些场景对日志持久化、检索、监控、告警等方面都有较强需求;

Docker 1.6的syslog driver目前可用性、易用性都还不太理想,但值得关注。

##app+rsyslog-kafka方案
上面提到的第三种日志方案,我们是通过ELK方案实现的。

架构图

elk.png


日志流
app >>> container rsyslog-kafka >>> kafka >>> logstash >>> elasticsearch >>> kibana

业务流

1. 产品线走DIP实时日志分析服务接入;
2. DIP审批;
1. config_web基于Docker Swarm api动态扩展logstash集群;
2. 给出用户接入所需数据,如Kafka broker、topic;
3. 产品线依据接入数据创建container;
1. `docker run -d -e KAFKA_ADDR=... -e KAFKA_TOPIC=... -e LOG_FILE=... -v $(pwd)/kafka_config.sh:${SOME_DIR}/kafka_config.sh ...`
2. 遵守SCE log接入规范,container中的run.sh需要调用SCE提供给的日志配置工具docker/tools/rsyslog_config.sh;
3. rsyslog_config.sh会按需自动配置rsyslog,接入过程及细节对产品线透明;


#网络模式
目前产品线大多使用的还是bridge和host,虽然这两种模式都存在一些问题。

两者虽存在一些问题,但还是能够满足中小规模集群网络需求的。

但规模上来后,上面两种模式就不适用了。对于大规模网络解决方案,我们后续将积极跟进,主要计划调研ovs/weave/Flannel等方案。

Libnetwork driver除了平移过来的bridge、host、null,还提供了remote,以支持分布式bridge;后续计划提供更多driver以解决目前的网络问题,值得重点关注。

另外,对于产品线提出的一些有意义的需求,如微博平台提出的“同一主宿机相同服务端口冲突的问题”,SCE会和产品线一道积极探索相应的解决方案;

#存储驱动选型
这部分主要是开始时,存储驱动方案选型的一些考虑。

- aufs。Docker最初采用的文件系统,一直没能合入内核,因此兼容性差,仅有Ubuntu支持。需要用户自己编译,使用起来比较麻烦;
- btrfs。数据并没有直接被写入而是先是被写入到日志,在有连续地写入流的情况下,性能可能会折半;
- overlayfs。一种新的unionfs,但对内核版本要求太高,需要kernel 3.18+;
- devicemapper。默认driver。可以说是目前一般情况下的最优方案了。SCE就是采用此driver。

devicemapper相关的一些实践及坑会在稍后提到。

#集群管理
目前SCE主要推荐3个集群管理工具:Shipyard、Swarm、Kubernetes。

Shipyard

- 支持跨主机的container集群管理
- 轻量级,学习成本低
- 支持简单的资源调度
- 支持GUI图表展示
- 支持实例横向扩展

Swarm

- Docker官方主推的集群管理方案
- 相对轻量级,学习成本较低
- 支持多discovery backend
- 丰富的资源调度Filter
- Rest API,完全兼容Docker API
- 尚有一些坑
- 目前产品线最易接受,且使用率最多的方案

Kubernetes

- Google Borg/Omega开源实现
- 更新迭代太块,架构及实现相对复杂,学习成本、改造成本较高
- 资源调度
- 扩容缩容
- 故障自动恢复
- 多实例负载均衡
- 对OpenStack支持较好
- 跟进中

三者各有优劣,具体使用哪个工具还是需要依据具体的业务需要而定,而并不是说Kubernetes强大就一定是好的。

根据目前产品线使用及反馈来看,swarm还是更容易被接收一些。

#与OpenStack集成进展
接下来,我们是IaaS,所以必须要说一下与OpenStack集成进展。如何与OpenStack更好的集成,充分发挥两者优势,是我们一直关注的一个点。

目前主要有三种方案:

- nova + docker driver;
- heat + docker driver;
- magnum;

Nova driver及heat driver两种方案,都存在一些硬伤。如nova driver方案把container当作VM处理,会牺牲掉Docker的所有高级特性,这显然是不能被接收的;又如heat driver方案,没有资源调度,创建时必须要指定host,这显然只能适用于小微规模。

OpenStack社区本年初终于开始发力CaaS新项目magnum。通过集成Heat,来支持使用Docker的高级功能;可以集成Swarm、Gantt或Mesos,实现Docker集群资源调度(现计划是使用swarm做调度);Magnum还将与Kubernetes深度整合。

Magnum已找准此前两种解决方案的痛点,并正在用恰当的方式解决此问题。非常值得跟进。

另外,此次温哥华OpenStack Summit上,OpenStack基金会除了还表示将积极推进Magnum子项目,在技术上实现容器与OpenStack的深度整合。

----------

实践经验&踩过的坑

下面介绍的内容,大多是产品线问到的,以及SCE在Docker实践过程中总结出来的经验教训,都已文档化到SCE官方Docker wiki。从SCE Docker wiki里摘取了一些实践经验&踩过的坑,想必大家或多或少已经实践过或踩过。如果还没遇到这些问题,希望我们的这些经验总结能对你有所帮助。

镜像制作方面

建议用Dockerfile build镜像,镜像文档化;
Dockerfile中,value千万别加""。因为docker会把你的""作为value的一部分;
最小化镜像大小,分层设计,尽量复用;

运行容器方面

一容器一进程,便于服务监控与资源隔离;
不建议用latest
对于提供服务的container,建议养成加--restart的习惯

数据存放方面

建议采用volume挂载方式
不依赖host目录,便于共享与迁移;

资源限制方面

cgroup允许进程超限使用,即:在有空余资源的情况下,允许使用超出资源限制的更多资源。
cgroup仅在必要时(资源不足时)限制资源使用,比如:当若干进程同时大量地使用CPU。
cpu share enforcement仅会在多个进程运行在相同核上的情况下发生。也就是说,即使你机器上的两个container cpu限制不同,如果你把一个container绑定在core1,而把另外一个container绑定在core2,那么这两个container都能打满各自的核。

资源隔离方面

user ns是通过将container的uid、gid映射为node上的uid、gid来实现user隔离的;
也就是说,你在node上只能看到container的uid,而看不到uname,除非这个uid在container和node上的uname相同;
也就是说,你在node上看到的container上的进程的所属用户的uname不一定是container上运行这个进程的uname,但uid一定是container上运行这个进程的uid;

swarm & compose使用方面

注意swarm strategies尚不成熟,binpack strategy实现存在一些问题,会导致最后调度出来的node不是你预期的。
注意compose尚不成熟,可能会遇到单个启container没问题,放到compose启就失败的问题。如:部署启动时间依赖性强的容器很可能会导致失败;

container方面

注意dm默认pool及container存储空间大小问题。container默认10G,pool默认100G,你可能需要通过dm.basesize、dm.loopdatasize按需扩容;
注意nsenter进容器,看不到配置在container里的env变量;查看env建议用docker exec或docker inspect;
注意docker daemon、docker daemon的default-ulimit和docker run的ulimit三者间的继承关系;

由于篇幅所限,这里就不再过多列举。

----------

后续计划

下面给出SCE后续需要继续深耕的几个点。

- 提供CI & CD解决方案
- 探索大规模集群网络方案
- 持续跟进大规模集群管理方案
- 深入调研OpenStack与Docker整合方案

----------

Q&A

问:如何实现跨机部署?
答:shipyard和swarm都可,当然还有其它方案。shipyard有不错的web UI,支持container多机部署,调度基于tag,还可以scale。swarm调度策略比较灵活,可以依据你指定的filter、weighter进行调度部署。

问:Compose能否实现跨机编排?
答:不行。目前只支持单机编排。

问:container监控是如何实现的?
答:cadvisor做container监控。监控这部分也是有一定工作需要去想去做的,比如说可以考虑和EK结合提来,提供一个独立的docker集群监控解决方案出来。

问:如何对某一容器进行扩容?
答:目前没有比较好的解决办法,我们的建议的做法是删了再启个大的。

数据存放方案如何选择,以保证数据安全性和易扩展、易迁移?

- 对于保证数据安全性需求,建议使用local + 云硬盘方案;
- 对于易扩展、易迁移需求,建议使用数据写image或volume挂载方案;
- 如果有高性能需求,并且你的container是跑在物理机上的,建议使用local volume + host dev方案;

没有方案是最优的,具体方案选型还是需要依据具体的使用场景而定。

问:SCE方案中,docker container大概是跑在那一层?
答:大概的栈是IaaS >>> CaaS,SCE docker container是跑在CaaS。

===========================

感谢我们合作伙伴首都在线对本次群分享的支持。

以上内容根据2015年6月2日晚微信群分享内容整理。分享人赵海川,新浪SCE工程师,主要负责虚拟化和Docker相关工作,致力于推动Docker在公司内的使用。微博:wangzi19870227。接下来,DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学参与。

更新 Ubuntu 系统,避免报错「校验和不符」

bnuhero 发表了文章 • 0 个评论 • 12350 次浏览 • 2015-05-08 19:12 • 来自相关话题

【编者的话】网络运营商的 HTTP 缓存,会导致用户更新 Ubuntu 系统时报错「校验和不符」。如果构建以 Ubuntu 为基础的容器镜像过程出现这个错误, Dockerfile 后续指令不会再被执行。本文提出三种解决方案:(1)加 HTTP 或者 SOCK ...查看全部
【编者的话】网络运营商的 HTTP 缓存,会导致用户更新 Ubuntu 系统时报错「校验和不符」。如果构建以 Ubuntu 为基础的容器镜像过程出现这个错误, Dockerfile 后续指令不会再被执行。本文提出三种解决方案:(1)加 HTTP 或者 SOCKS 代理;(2)修改软件源的访问协议为 HTTPS 或者 FTP;(3)修改 apt 源码,用 IP 地址指定软件源服务器。

# 1. 问题

使用 Ubuntu 操作系统,执行


sudo apt-get update


更新系统时,经常会见到类似如下所示的报错信息:

W: 无法下载 http://cn.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/source/Sources Hash 校验和不符



,系统更新失败。

这是一个烦人的问题,尤其是当以 Ubuntu 为基础构建容器镜像时,如果系统更新失败, Dockerfile 中的后续指令不会被执行。


「校验和不符」( Hash Sum mismatch) 在 2012 年已经被确认是 Ubuntu 的一个 BUG , 但是几年过去,还是没改好。

出现这个错误的原因是 Ubuntu 下载的索引文件不是来自指定的软件源,而是网络服务提供商的缓存。

网上给出的解决方案:


sudo apt-get clean
sudo rm -rf /var/lib/apt/lists
sudo apt-get update


经实际验证,这种方法是无效的。

# 2. 解决方法

(1)代理

指定使用 HTTP 代理。如果是设置只对当前会话有效的临时代理,执行


export http_proxy=http://yourproxyaddress:proxyport
sudo apt-get update
sudo apt-get upgrade


如果要设置持久代理,编辑 `/etc/apt/apt.conf`,添加一行:


Acquire::http::Proxy "http://yourproxyaddress:proxyport";


,然后执行:


sudo apt-get update
sudo apt-get upgrade


如果没有 HTTP 代理,只有 SOCKS 代理,首先安装 `proxychains` 程序,编辑 `/etc/proxychains.conf` ,指定 SOCKS 服务器的 IP 地址和端口;接下来,执行:


sudo proxychains apt-get update
sudo apt-get upgrade


(2)换协议

网络服务商只使用了 HTTP 缓存,如果软件源还支持 HTTPS 或者 FTP 协议,修改 `/etc/apt/sources.list` ,把其中所有的 `http://` 换成 `ftp://` ,再执行系统更新。

这种方法的不足是中国境内的软件源不支持 FTP 协议访问, Ubuntu 主服务器支持,但是网络速度会比较慢。

(3)黑科技

警告:这种方法是否有潜在问题,还有待持续一段时间的观察。不要在生产环境中使用。

第一步:修改 `apt` 包的源代码,不让它报这个错。


sudo apt-get install build-essential
sudo apt-get build-dep apt
sudo apt-get source apt


此时,有一个 `apt-1.0.1ubuntu2.7` 的文件夹,包含 `apt` 包的源代码。修改 `apt-pkg/accquire-item.cc` ,查找 `HashSumMismatch` 关键词。第一个出现的地方是打印报错信息的函数,不用管。把剩下的五段代码都注释掉。例如,


/*
if (!ExpectedHash.empty() && !ExpectedHash.VerifyFile(DestFile))
{
RenameOnError(HashSumMismatch);
Dequeue();
return;
}
*/


然后,在 `apt-1.0.1ubuntu2.7` 目录下,执行:


make
dpkg-buildpackage -us -uc -nc


成功执行后,在 `apt-1.0.1ubuntu2.7` 的上一级目录中有新创建的一系列 `.deb` 文件。我们的修改,包含在 `libapt-pkg4.12_1.0.1ubuntu2.7_amd64.deb` 中。

安装这个软件包,并标记为不更新:


sudo dpkg -i libapt-pkg4.12_1.0.1ubuntu2.7_amd64.deb
sudo apt-mark hold libapt-pkg4.12


第二步:把 `/etc/apt/sources.list` 中的软件源域名换成对应的 IP 地址。以中国服务器镜像为例,首先查找 `cn.archive.ubuntu.com` 对应的 IP 地址:


dig cn.archive.ubuntu.com


查询结果是:


cn.archive.ubuntu.com. 133 IN CNAME mirrors.aliyun.com.
mirrors.aliyun.com. 133 IN A 112.124.140.210
mirrors.aliyun.com. 133 IN A 115.28.122.210


原来中国服务器就是阿里云镜像。编辑 `/etc/apt/sources.list` , 把 `cn.arhive.ubuntu.com` 替换成 `112.124.140.210` ,保存。

从此以后,就可以无烦恼更新系统了。

=========================

作者:柳泉波,读书喝茶踢球写程序。

如何在Ubuntu系统中使用Overlay文件系统

刘凯宁 发表了文章 • 5 个评论 • 10876 次浏览 • 2015-03-10 19:19 • 来自相关话题

【编者的话】本文用最简洁的语言介绍了如何在Ubuntu系统上运行Overlay文件系统,正如作者所说:AUFS是过去时代的王者,现在新的国王是Overlay。看来Overlay以后将是Docker存储的首选。 在上周的Docker伦敦 ...查看全部
【编者的话】本文用最简洁的语言介绍了如何在Ubuntu系统上运行Overlay文件系统,正如作者所说:AUFS是过去时代的王者,现在新的国王是Overlay。看来Overlay以后将是Docker存储的首选。

在上周的Docker伦敦大会上面,Jérôme Petazzoni分享了「深度研究Docker存储驱动」的演讲,非常棒。如果这件事还没有令我足够信服,那么Jessie Frazelle则完全说服了我,她在Qcon组织的演讲中宣称:AUFS是过去时代的王者,现在新的国王是Overlay。在Jessie的演讲过程中,我打算为我自己搭建这样的一个环境,因为我没有办法找到一个比我现在写的这个更加简单明了的手册。
##3.18 Kernel(3.18版本的内核)
OverlayFS之前已经加入到了Ubuntu内核中,但是那并不是我们想要的。Overlay(没有FS)是一个不同的内核模块,因此你需要安装3.18(或者以上)的内核:
cd /tmp/ 
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-headers-3.18.0-031800-generic_3.18.0-031800.201412071935_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-headers-3.18.0-031800_3.18.0-031800.201412071935_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-image-3.18.0-031800-generic_3.18.0-031800.201412071935_amd64.deb
sudo dpkg -i linux-headers-3.18.0-[i].deb linux-image-3.18.0-[/i].deb

我已经在Ubuntu14.04和12.04环境下测试成功了。
##Docker
你需要安装Docker 1.4或者更高版本(我使用1.5版本做测试的),具体可以参考官方文档来安装。
在有了新的内核并且重新启动以后,现在需要在/etc/default/docker中给DOCKER_OPTS设置`-s overlay`:
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="-s overlay"

设置好以后,重新启动Docker服务,如果一切顺利的话,你可以从`docker info`命令中得到如下的信息:
$ sudo docker info
Containers: 0
Images: 0
Storage Driver: overlay
Backing Filesystem: extfs
Execution Driver: native-0.2
Kernel Version: 3.18.0-031800-generic
Operating System: Ubuntu 14.04.1 LTS
etc...

为了使Overlay正常跑起来,你可能需要在Ubuntu 12.04的环境下执行`modprobe overlay`。还有一点需要注意:如果 Docker 不能成功地使用 Overlay 作为存储后端,那么将会转为使用DeviceMapper(而不是AUFS)机制存储。

原文链接:Using Overlay file system with Docker on Ubuntu(翻译:刘凯宁 校对:李颖杰)
===========================
译者介绍
刘凯宁,中南大学信息管理与信息系统专业,本科三年级在读,热爱互联网,热爱软件开发技术。大一下开始编程,熟悉Java SE,PHP,Go,有若干小型商业项目实践经验(网站、微信平台、JavaSE实用软件)和软件公司实习经历(上海热璞科技,201407-201409)技术博客:C2P技术博客;QQ:929025296 ;很高兴和各位前辈交流!

采用Docker技术,生产环境下建议采用CentOS(Fedora)还是Ubuntu(Debian)?

回复

zhaojunlike@ 回复了问题 • 4 人关注 • 3 个回复 • 7188 次浏览 • 2017-04-13 15:42 • 来自相关话题

咨询如何可以把现有的ubuntu系统做成镜像

回复

gnuer 回复了问题 • 4 人关注 • 4 个回复 • 2977 次浏览 • 2016-12-21 15:29 • 来自相关话题

ubuntu:14.04image上安装openssh-server无法通过root用户登陆

回复

adolphlwq 回复了问题 • 2 人关注 • 1 个回复 • 3461 次浏览 • 2015-12-16 21:05 • 来自相关话题

kubernetes进行kubectl version出现localhost:8080 connection refused的问题

回复

Ichuncun 回复了问题 • 6 人关注 • 5 个回复 • 25550 次浏览 • 2015-10-23 11:09 • 来自相关话题

在Ubuntu Docker上写的程序能否在CentOS的Docker上运行

回复

cxshun 回复了问题 • 7 人关注 • 4 个回复 • 6593 次浏览 • 2015-07-18 10:55 • 来自相关话题

ubuntu下容器无法启动-device or resource busy

回复

叶落无声 发起了问题 • 2 人关注 • 0 个回复 • 5339 次浏览 • 2015-07-09 14:13 • 来自相关话题

Docker官方镜像将会使用Alpine Linux替换Ubuntu

DockOne 发表了文章 • 8 个评论 • 20929 次浏览 • 2016-02-10 18:51 • 来自相关话题

Docker容器的优势是轻量和可移植,所以承载它的操作系统也应该尽量迎合这个特性。我想这也可能是为什么最近有消息说Docker准备使用Alpine Linux替代之前的Ubuntu做为官方默认的宿主环境(基础镜像)。 1月底,Dock ...查看全部
Docker容器的优势是轻量和可移植,所以承载它的操作系统也应该尽量迎合这个特性。我想这也可能是为什么最近有消息说Docker准备使用Alpine Linux替代之前的Ubuntu做为官方默认的宿主环境(基础镜像)。

1月底,Docker公司创始人Solomon曾经说道,Alpine Linux的创始人Natanael Copa已经加入Docker,他正在将Docker的官方镜像包从Ubuntu切换到Alpine。


Screen-Shot-2016-02-05-at-10-00-35.png


目前,Docker官方使用的默认镜像是Ubuntu,之前就有人比较过几个基础镜像的大小。具体如下。从图中可以看出,Ubuntu有4层,188M,而Alpine Linux只有1层,5M。知名的云计算专家Brian Christner在他的博客中表示,如果Docker的官方镜像使用Alpine Linux,将会有如下4个好处:

  1. 下载速度加快。
  2. 安全性提高。
  3. 主机之间的切换更方便。
  4. 不用再占用那么多磁盘空间。

Docker_Image_Size.png


Alpine Linux 是一个社区开发的面向安全应用的轻量级 Linux 发行版。Alpine采用了musl libc和busybox以减小系统的体积和运行时资源消耗,在保持瘦身的同时,Alpine Linux还提供了自己的包管理工具apk,可以在其网站上查询,或者直接通过apk命令查询和安装。当然,Docker还会继续支持Ubuntu,只不过他不再是默认的操作系统。

Solomon表示这样的切换对于Docker用户来说非常有益,因为Alpine更小,更轻。像Ubuntu这样的操作系统,它基于Linux内核和GNU工具组,同时默认安装了一些程序。但Docker可能并不需要那些被默认安装的程序,所以还有很大的可以精简的空间。

目前这项消息还未得到官方证实,不过,切换与否,对于Docker使用者来说并没有太大的影响,用户可以选择他们最喜欢的Linux发行版本。

为了性能,请不要在CentOS中运行Docker,尽量用Ubuntu

chenhl 发表了文章 • 7 个评论 • 25648 次浏览 • 2016-01-20 00:07 • 来自相关话题

【编者的话】生产环境里Docker运行在CentOS上似乎是大家的共识,但本文的作者通过自己在CentOS上使用Docker比在Ubuntu上性能缓慢的体验差异,决定转向在Ubuntu上使用Docker。你们是否对Docker运行在CentOS或Ubuntu上 ...查看全部
【编者的话】生产环境里Docker运行在CentOS上似乎是大家的共识,但本文的作者通过自己在CentOS上使用Docker比在Ubuntu上性能缓慢的体验差异,决定转向在Ubuntu上使用Docker。你们是否对Docker运行在CentOS或Ubuntu上的性能差异有自己的见解,下面让我们看看作者的理由。

多年来,我一直是一个铁杆的CentOS用户。我很喜欢它最小安装创建的轻量环境,直观的安装过程和包管理软件。Docker是当今最流行的容器格式,为开发人员和爱好者提供了一个在容器环境里运行任务的简单方法。我在生产环境中使用Docker大约有一年时间,运行的服务有Plex媒体服务器,博客的Web服务器,ZNC服务器,MineCraft服务和MySQL服务等等。Dockerfile是一组用来创建Docker镜像的指令。我投入了很多时间使用CentOS和Fedora制作完美的Dockerfile,它能简化安装和部署。然而,我现在却想换个环境:)

Docker在CentOS和Fedora上的性能非常差。出现这种情况的原因是因为Docker使用device mapper作为默认存储。Device Mapper是基于内核的框架,给人们提供一个现成的简单方法来使用Docker,并被认为比Linux上许多先进的卷管理技术更好。虽然有Device Mapper的替代方法,如使用OverlayFS等等,但对我来说它们的效果不太理想。当我建立一个容器时,Dockerfile中的每个步骤可能需要一分钟或更长时间才能完成,如添加一个zip文件到镜像中或替换配置文件中文本。我已经发现有关此主题的许多博客文章和已经公布的bug,但是我现在需要对该问题的一个可行的解决方案。

DigitalOcean.com是个不错的托管服务提供商,可以让你的虚拟服务器或应用程序如Docker运行在固态硬盘驱动器上的虚拟机里,每个月只需要5美元。当我尝试在Digital Ocean或Ubuntu上使用Docker时,性能是难以置信的快。当在Digital Ocean上通过CentOS使用Docker时,我同样感到性能欠佳。在使用Docker Machine(它是一种在Mac操作系统上使用VirtuaBox运行Docker的简单方式)时Docker的性能同样很棒。昨天晚上,根据我以往的生活经验,我最终决定必须对我的服务器进行改变,将其切换到了Ubuntu操作系统上。

我安装了Ubuntu 15.10服务器版,它在大多数情况下工作的很好。我认为CentOS/Fedora的安装程序领先Ubuntu一光年。例如,Ubuntu有繁琐的提示,而且配置磁盘并不和CentOS一样简单。最后,我只是有一个启动和运行比Ubuntu快的CentOS系统而已。我真的很喜欢Ubuntu的软件库,因为他们有所有我需要的Docker软件包,如随手可用的docker-compose。但在CentOS上,我需要手动安装额外的Docker仓库来获得相同的功能。Ubuntu使用AUFS作为Docker存储驱动程序。我不得不改变我所有的Dockerfile使用Ubuntu作为基础操作系统,这是因为我的一些现有Dockerfile因Docker的bug不能工作, 这些bug是由于在AUFS上使用CentOS/Fedora镜像导致的。

总之,完成这些是一个巨大的工作量,并且我睡的很晚。但是我认为这是对未来的一个巨大投资,这可以节省构建Docker容器的时间。正因为Ubuntu没有像CentOS/Fedora上相同的Docker问题,我现在可以毫不费力在云提供商之间迁移。

原文链接:Goodbye Docker on CentOS. Hello Ubuntu!(翻译:chenhl)

Ubuntu创始人 :Linux容器将完全颠覆虚拟化

Leo_li 发表了文章 • 0 个评论 • 6265 次浏览 • 2015-12-03 18:55 • 来自相关话题

新一轮的服务器虚拟化浪潮看起来并不像上一次,Mark Shuttleworth如是说。Shuttleworth在十几年前发起了Ubuntu Linux项目,现在他在Canonical(运作Ubuntu的公司)公司负责战略和用户体验。 ...查看全部
新一轮的服务器虚拟化浪潮看起来并不像上一次,Mark Shuttleworth如是说。Shuttleworth在十几年前发起了Ubuntu Linux项目,现在他在Canonical(运作Ubuntu的公司)公司负责战略和用户体验。

在他的领导下,和其他的Linux玩家一样,Canonical迎来并相继支持了一波又一波的虚拟化技术,从一开始的Xen hypervisor,到后来的KVM,再到Docker。Ubuntu曾支持过Eucalyptus,当完全开源的OpenStack出现之后,它就转而支持OpenStack。Docker及其将软件容器化的方式完全类似于虚拟化并且让云计算服务商为之癫狂,但是让Shuttleworth兴奋的是另一种称为Linux容器 (缩写为LXC)的技术及与之相应的称为LXD的Hypervisor。LXD是由Canonical开发的一个后台进程来管理这些容器并且提供了或多或少与开源的Xen及KVM、微软的Hyper-V或者VMware的ESXi这些服务器虚拟化Hypervisor类似的功能(LXD与Docker的思路不同,Docker是PAAS,LXD是IAAS)。

Shuttlworth向The Next Platform表示:“我们相信这是(LXD)十年来对Linux虚拟化最大的突破,你可以看到我们对此是多么兴奋”。

LXC容器的想法和初期的工作都是由Google完成的,容器化应用程序已经在其基础架构上运行了超过十年时间,而且据说每天会启动超过20亿的容器。Canonical和其他大约80个组织已经开始致力于LXC的商业化,因为LXC最初并不是一个对用户很友好的技术。商业化是为了让其具有常见服务器虚拟化的观感和体验,尽管它使用的是非常不同且简化的技术。

“对于容器,很多人并不了解的是我们用来配置容器的系统其实可以用很多种方法来做虚拟或者模拟”,Shuttleworth解释说,有时你希望模仿看起和Docker类似的东西,而有时你又想模拟其他的东西。就LXC而言,我们想要创建容器的途径是创建假想的主机,而不是运行操作系统的主机或者构成一个操作系统的所有进程。这与Docker完全不同,虽然它们都使用相同的底层原语,但是创建了不同的的东西。LXC的宗旨是不借助硬件虚拟化来创建虚拟机。

说起Docker,它在早期是基于LXC的但是现在它有了自己的抽象层,它更像一个运行在文件系统之上的单个进程,就好比你启动了主机但并没有运行Init和所有构成操作系统的进程而是直接运行数据库或者其他的东西,然后在一台主机上启动多个容器并把它们一起置于其中。通过LXC及其LXD守护进程,Canonical希望保持拥有一个完整Debian、CentOS、Ubuntu或其他Linux操作系统的感观。

在LXC 1.0中,常见的情景是程序员说:“给我创建这个容器”。现在我们的做法是接收代码然后将其纳入LXD守护进程来管理,因此并不需要由程序员去创建每一个容器,我可以拥有上百个虚拟机并且与LXD守护进程进行通信来进行统一管理,因此我所拥有的虚拟机集群与你使用VMware ESXi hypervisor所构建的类似。把LXC打包到一个守护进程中就使得它变成了一个hypervisor。什么是ESXi?它基本上是一个操作系统,你可以通过网络跟它通信并且让它给你创建一个虚拟机。通过LXD,你可以跟一个运行LXC的主机说给我创建一个运行CentOS的新容器。这成为一个集群的导引机制。

LXD也提供了另一个重要功能:它是运行的在两台不同物理主机上的一个软件,从而使得LXC实例能够在主机间在线地迁移。

本周,Canonical发布了首次包括LXD hypervisor的LXC 2.0 beta版本。在本月将要发布的Ubuntu Server 15.10的更新中就包括这两个组件,而Canonical也通过统一步骤把LXC 2.0反推入Ubuntu Server 14.04 LTS(LTS是Long Term Support的缩写)的服务器版本。LTS版本每两年发布一次而且具有五年的支持生命期。由于它的稳定性有保证,所以70%的客户都在生产环境中运行Ubuntu服务器的LTS版本。

据Shuttleworth说,包含LXD hypervisor的LXC 2.0生产级别版本将在明年亮相,根据命名方案的建议可能就在二月或者三月最迟到4月就与新的企业级版本 – Ubuntu Server 16.04 LTS一同发布。负责Ubuntu产品和战略的Dustin Kirklan对TheNext Platform说,从下一个LTS版本开始,在每一个Ubuntu Server中就会缺省安装LXC和LXD组件,这样每个主机都可以运行几十到几百个容器 –IBM在最大的使用POWER处理器的服务器上甚至可以运行数千个容器。

相比于依靠硬件虚拟化的常规虚拟机,LXC容器具有两个巨大的优势:一台主机上可以打包的容器数量和这些容器的启动速度。尽管为了在一台硬件上用不同的容器运行不同的Linux需要一些额外的工作,但是由于LXC其实就是用Linux运行Linux,所以不需要虚拟什么。

“这在性能方面前进了一步,而在密度方面的改进则是巨大的”,Shuttleworth无不得意地说:“而这对于低延迟、实时型的应用程序具有显著的改善。在云计算环境中这类事情都变得容易处理了,当然过去他们可不是这样。如果你的云平台运行了LXC,很快高性能计算可以搞定了,云计算平台上的实时计算也可以搞定了,而且如果你是一个需要低传输延迟的电信运营商的话,那么NFV(网络功能虚拟化)也可以搞定了。在这些需要巨大资金投入的领域,人们真的希望使用云计算和虚拟化,而LXC使其成为可能。这是非常令人振奋的”

Shuttleworth说LXC容器在密度方面可以达到诸如EXSi、Xen或KVM这类使用虚拟机的hypervisor的14倍,而且LXC和LXD组合在开销方面却只占基于硬件虚拟化的Hypervisor的20%不到。对于空闲的负载而言,VM和LXC容器就和大多数VM和物理主机所作的一样大部分时间在等待。对于繁忙的VM而言,LXC容器则能够提供明显要好得多的I/O吞吐量和更低的延迟。因此,对于空闲的主机你专注于整合,而对于繁忙的主机你专注于吞吐量和延迟。而且由于Hypervisor和VM的特定开销可以释放出来用于实际工作,所以你可以得到大约20%的性能提升。

现在已经开始对LXC及LXD组合进行基准测试。在上周东京召开的OpenStack峰会上,Canonical LXD开发团队的Tycho Andersen展示了一些在虚拟化环境中的测试基准,其中一个是使用Hadoop TeraSort测试而另一个是对Cassandra NoSQL数据存储的压力测试。这两个测试中,主机运行的是在峰会期间发布的最新OpenStack “Liberty”云控制器和同样刚发布的Ubuntu 15.10. 15.10,它既有KVM也有LXD hypervisor和各自的虚拟机和容器。这些服务器配备了24核和48GB内存,一个控制器负责管理OpenStack而其他三台用作基本的计算节点。

1.jpg

在TeraSort测试开始的时候,在三台主机上LXC和KVM的表现基本一致,但是当OpenStack/Hadoop集群中的主机数量随着数据集的规模增长后,两种不同的虚拟化手段在性能方面的差异开始显现。

2.jpg

你可以看到LXC/LXD同KVM在延迟和吞吐量上的差异是非常明显的。

爱立信研究院和阿尔托大学发表了一篇很有意思的论文,它表明主机在运行LXD和Docker时比运行Xen和KVM能节省更多的能耗,你可以点击这里查看。在CPU和内存的基准测试结果中,随着更多的VM或者容器加到主机上,服务器的功率随之消耗上升而且两者之间的差距并不明显,但是当他们处理网络流量时,Docker和LXC在完成相同的工作时要少消耗10%的能耗。

由于容器的轻便特性,使得LXC容器毫无意外地用于很多云计算平台,而且极有可能成为未来基础架构云的基础 – 至少是那些只运行Linux的云基础架构平台,因为LXC不能运行在数据中心中的另一种重要操作系统 – Windows server上。但尽管如此,大多数重要的新软件是在Linux之上开发的 – Hadoop、Spark、NoSQL数据库、多种文件系统等等,所以这不会受限于人们所构建的平台的特定部分。

有意思的是正如那句俗话“吃自家的狗食”所言,现在Canonical也在用LXC容器部署他们的Ubuntu OpenStack。这使得管理员能够分步地升级OpenStack或者把部分负载从硬件上移走来发挥硬件的性能。

Shuttleworth说,在一个典型的小规模OpenStack云中你可以用八台管理节点来运行管理平台的所有组件,而且你希望以一式三份的方式来运行它,这样即使有你失去了一个节点,还能通过另外两个来保持高可用。这就需要32台物理服务器。通过把这些组件打包到LXC容器并通过LXD hypervisor进行管理,这些管理平台的大部分组件都可以打包到同一个物理服务器上从而缩减了OpenStack管理平台的物理服务器规模却不会牺牲性能和可用性。

程序员都追求简洁而且他们喜欢保持事物有序和整洁。在某种程度上,只是因为硬件虚拟化的成本很高就不得不把程序部署到多个主机上已经成了一个痛点。现在,你可以快速地在一台主机上运行多个程序而没有这些开销并且始终保持他们的原始状态和隔离。

谈起LXC,Shuttleworth告诉我们红帽很难忽视我们而且他们最终把LXC加到了RHEL 7当中,而Kirklan说尽管Canonical做了很多努力使得KVM管理工具libvirt支持LXC,但是libvirt的维护者还是专注于KVM虚拟机而非容器。所以他认为这事儿有点棘手。而Shuttleworth说:红帽一直以来想试图把容器的想法曲解为轻量级的VM,因为他们在KVM投入了大量的资金,而这就扭曲了他们的世界观。

推动LXC和LXD普及的关键因素是这样的一个事实,即企业(超大规模的)和高性能计算(HPC – High Performance Computing)中心里的大量负载都是运行在Linux之上,而且这些组织希望在迁移基础架构的时候能够保留这些应用程序。恰恰是这个需求使得VMware成为企业数据中心领域60亿美元的巨头。

作为一个例证,Shuttleworth说Canonical已经与Intel和其他一些不具名的HPC中心在LXC容器基础上利用LXD hypervisor以近乎裸机的性能来测试以前的仿真和建模代码。”想一想这是怎样的场景。现在一个超级计算机运行着管理员最喜欢的操作系统,而科学家们能够获得裸机的性能同时还可以访问他们最熟悉的操作环境。这一切都得益于虚拟化而且两者获得了所期望的东西而没有任何物理主机虚拟化带来的困惑。
私有云先行,而后公有云
LXC和LXD都不需要使用OpenStack云控制器,但是在数据中心里这三者将极有可能要在一起配合。Shuttleworth说根据OpenStack社区的最新统计,Ubuntu server支撑着全世界一半以上已安装的OpenStack云而且它也占据了最大的OpenStack集群中百分之六十五的份额。

Canonical的Ubuntu OpenStack发行版本已经被沃尔玛、AT&T、Verizon、NTT、彭博社及德国电信所采用 – 都是成功的大单。此外,上周在东京的OpenStack峰会上,Shuttleworth补充说他看到没有一个在Ubuntu上运行OpenStack的企业客户对LXD不感兴趣,因为其经济性和密度实在是太棒了。

总体而言,这些都是私有云的成功案例。Shuttleworth认为长期目标是使公有云服务商把LXC和LXD作为其基础架构和平台服务的基础,但是要实现这个目标大多数公有云服务商可能要等到X86、Power及ARM服务器拥有虚拟化专用电路来为LXC和LXD提供与KVM、Xen或者Hyper-V等同的硬件安全(当然,这和平台有关)。当前,Linux社区能够为LXC容器提供Linux内核内的安全防护,但是这对于云服务提供商而言是不够的。至于这些功能合适会加入到至强、Opteron、Power和ARM芯片中还不得而知,而且Shuttleworth也没有透漏Canonical的硬件合作伙伴的路线图。

原文链接:Linux Containers Will Disrupt Virtualization Incumbents(翻译:李毅)

========================================================
译者介绍
李毅,中国惠普大学资深培训专家。

Ubuntu 14.40 安装Kubernetes 1.0.1

King_NJ 发表了文章 • 13 个评论 • 13305 次浏览 • 2015-08-27 10:16 • 来自相关话题

【编者的话】本文主要根据官方的指南,在ubuntu 14.04 上做了实践,并解决阐述了可能遇到的问题,提供了基本的安装包,可以快速安装kubernetes。 官方地址:https://github.com/kubernetes/ku ...查看全部
【编者的话】本文主要根据官方的指南,在ubuntu 14.04 上做了实践,并解决阐述了可能遇到的问题,提供了基本的安装包,可以快速安装kubernetes。

官方地址:https://github.com/kubernetes/kubernetes/blob/master/docs/getting-started-guides/ubuntu.md

首先在各节点安装docker,可以参见
http://blog.onos.top/docker/2015/08/26/install-docker-1.8.1-on-ubuntu14.04/

笔者的实验环境如下:
10.0.0.27 docker3
10.0.0.26 docker2
10.0.0.25 docker1
三个节点是Openstack上的虚拟机,启动docker3配置了浮动IP和笔者的PC相连。

准备工作:三个节点的SSH无密码访问,因为三个节点是VM,docker2,docker1不能和PC直连,只能通过docker3 SSH跳转。

下载Kubernetes安装包,只需要下载tar.gz结尾即可,并上传至docker3,并下载build.sh备用。
root@docker3:~/k8s# ls
build.sh etcd-v2.1.1-linux-amd64.tar.gz flannel-0.5.2-linux-amd64.tar.gz kubernetes.tar.gz
root@docker3:~/k8s# tar -xvf kubernetes.tar.gz
root@docker3:~/k8s# ls
build.sh etcd-v2.1.1-linux-amd64.tar.gz flannel-0.5.2-linux-amd64.tar.gz kubernetes kubernetes.tar.gz
root@docker3:~/k8s# cd kubernetes/cluster/ubuntu/
root@docker3:~/k8s/kubernetes/cluster/ubuntu# vim build.sh

编辑build.sh,原先的代码主要是从网络下载三个tar.gz包并解压操作,笔者修改为直接使用上传的包操作。
可以用之前下载的build.sh直接覆盖解压后原先的脚本
root@docker3:~/k8s/kubernetes/cluster/ubuntu# ./build.sh

移动解压tar.gz并创建新的binaries目录
root@docker3:~/k8s/kubernetes/cluster/ubuntu/binaries# ls
kubectl master minion

上面的操作把需要部署的二进制文件集中到了cluster/ubuntu/binaries内,后面我们进入cluster/ubuntu目录进行节点的部署。
root@docker3:~/k8s/kubernetes/cluster/ubuntu# vim config-default.sh 

主要配置以下参数:
export nodes=${nodes:-"root@docker3 root@docker2 root@docker1"}  

节点的用户名@IP,因为笔者在/etc/hosts配置了主机名和IP
所以此处用的是域名
roles=${roles:-"ai i i"
}
节点的角色a:master i:minion ai:master and minion 分别是单词的第二个字母
export NUM_MINIONS=${NUM_MINIONS:-3}
笔者刚好是说那个节点所以,基本上只修改了nodes这个值,其它均保留。注意nodes和roles位置是一一对应的。
#cd ~/k8s/kubernetes/cluster
$ KUBERNETES_PROVIDER=ubuntu ./kube-up.sh

上面的脚本会根据config-defualt的节点配置把cluster/ubuntu/binaries里面的文件拷贝到nodes配置的节点上。

如果之前配置了docker3到docker1,docker2以及自己的无密码访问就无需输入密码,负责需要输入节点密码。

以上脚本可能会执行失败,主要是docker安装配置的网桥和k8s启动docker的配置不一致。
root@docker3:~# ifconfig docker0
docker0 Link encap:Ethernet HWaddr 02:42:e7:a0:83:09
inet addr:172.16.8.1 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::42:e7ff:fea0:8309/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1372 Metric:1
RX packets:2481 errors:0 dropped:0 overruns:0 frame:0
TX packets:2293 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4196199 (4.1 MB) TX bytes:1948029 (1.9 MB)
root@docker3:~# cat /etc/default/docker
DOCKER_OPTS="-H tcp://127.0.0.1:4243 -H unix:///var/run/docker.sock --bip=172.16.8.1/24 --mtu=1372 --insecure-registry=docker3:5000"

其中Linux网桥docker0的IP需要和docker启动参数bip的地址一致。

三个节点都修改一致后,重启docker,然后在docker3查看集群情况
root@docker3:~# kubectl get nodes
NAME LABELS STATUS
docker1 kubernetes.io/hostname=docker1 Ready
docker2 kubernetes.io/hostname=docker2 Ready
docker3 kubernetes.io/hostname=docker3 Ready

至此Kubernetes的基本安装部署就完成了,如果kubectl提示没有,可以从cluster/ubuntu/binaries里面拷贝至/usr/bin等某个系统目录即可,或者配置PATH指向kubectl所在路径。下一步可以着手安装kube-ui,请参考笔者其它博文。

原文链接

如何在Docker上运行Ubuntu Core

jeffsui 发表了文章 • 0 个评论 • 6413 次浏览 • 2015-06-17 17:43 • 来自相关话题

【编者的话】Snappy是一个极度精简的Ubuntu镜像,因为它可以快速部署在云端,并且提供了简便的基础功能组件更新,所以很多人用来在云端上构建(微)系统架构。很可惜Snappy并不包含在Docker的官方镜像中,本文通过一个实例演示了如何在Docker中运行 ...查看全部
【编者的话】Snappy是一个极度精简的Ubuntu镜像,因为它可以快速部署在云端,并且提供了简便的基础功能组件更新,所以很多人用来在云端上构建(微)系统架构。很可惜Snappy并不包含在Docker的官方镜像中,本文通过一个实例演示了如何在Docker中运行Ubuntu Core镜像,并构建自己的Snappy容器。文章短小精悍,希望能给使用Snappy系统并希望用Docker来构建系统架构的人一些有益的借鉴。

有很多人已经听说过 Ubuntu Core的大名,没听过也不要紧, Ubuntu Core 是一个极度精简的ubuntu版本。它通过Snappy(一个包管理器)来运行一些基本服务并提供主要的功能组件更新。Ubuntu Core 提供轻量级的基本运行时系统,给使用者以快速部署和方便的持续更新功能。并且在它上面还使用了 security model

上述这些令人激动的特性使得Snappy可以快速部署在云平台上。与此同时,人们已经开始考虑使用它在云端上来构建他们自己的(微)服务架构。就在几周前,一个用户在 Ask Ubuntu 上提问题:Can I run Snappy Ubuntu Core as a guest inside Docker? 。问题在于Ubuntu Core并不包含在Docker提供的官方镜像库中,所以我们自己手动创建镜像了。下面是一个例子:
# 创建 Docker 镜像
#步骤一: 获取最新的Ubuntu Core镜像
截止发稿时为止,Ubuntu Core 的版本是 alpha 3 ,下载地址为 :
$ wget http://cdimage.ubuntu.com/ubuntu-core/releases/alpha-3/ubuntu-core-WEBDM-alpha-03_amd64-generic.img.xz

(如果你访问这个网址 cdimage.ubuntu.com,可以获取带有hash签名的版本)

下载的镜像是通过XZ方式压缩的,所以要通过下面的命令解压:
$ unxz ubuntu-core-WEBDM-alpha-03_amd64-generic.img.xz

#步骤二: 使用`qemu-nbd`方式连接镜像
解压后的文件不是普通的文件格式,上一个版本(Alpha 2)镜像是`QCOW2`文件格式,为了能够使用这个镜像内容,我们有几个解决方案。这里我介绍其中的一种,既可以使用文件系统又可以使用`QCOW2` 镜像的方式。下面的小技巧包含使用`qemu-nbd`(一个基于 qemu-utils)的工具包):
# qemu-nbd -rc /dev/nbd0 ubuntu-core-WEBDM-alpha-03_amd64-generic.img

运行上面的命令将会创建一个名为 `/dev/nbd0`的虚拟设备,并且创建 名为 `/dev/nbd0p1`、`/dev/nbd0p2`,诸如此类的虚拟分区,可以通过 使用`fdisk -l /dev/nbd0`命令,查看关于`QCOW2` 镜像相关的信息。
#步骤三: 挂载文件系统
例如我们感兴趣的是`/dev/nbd0p3`,我们通过下面的命令来挂载分区:
# mkdir nbd0p3
# mount -r /dev/nbd0p3 nbd0p3

#步骤四:创建一个基于docker的基础镜像
建议阅读 Docker官方手册,创建一个简单的Docker基础镜像。
tar -C nbd0p3 -c . | docker import - ubuntu-core alpha-3

通过运行`docker images`命令,我们可以查看我们刚刚创建的Docker镜像。
# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu-core alpha-3 f6df3c0e2d74 5 seconds ago 543.5 MB

通过这个命令`docker run ubuntu-core:alpha-3 Snappy`,让我们验证一下Snappy是否可以访问:
# docker run ubuntu-core:alpha-3 Snappy
Usage:Snappy [-h] [-v]
{info,versions,search,update-versions,update,rollback,install,uninstall,tags,config,build,booted,chroot,framework,fake-version,nap}
...

如果看到上面的信息,那么恭喜你,已经成功将Ubuntu Core融入到Docker镜像中,第一次运行了Snappy容器。
安装软件
废话不多说,下面演示如何在docker中安装并运行 ` xkcd-webserver` Snappy包管理器。
# docker run -p 8000:80 ubuntu-core:alpha-3 /bin/sh -c 'Snappy install xkcd-webserver 

原文链接:Running Ubuntu Snappy inside Docker(翻译:隋鑫 审校:魏小红)

更新 Ubuntu 系统,避免报错「校验和不符」

bnuhero 发表了文章 • 0 个评论 • 12350 次浏览 • 2015-05-08 19:12 • 来自相关话题

【编者的话】网络运营商的 HTTP 缓存,会导致用户更新 Ubuntu 系统时报错「校验和不符」。如果构建以 Ubuntu 为基础的容器镜像过程出现这个错误, Dockerfile 后续指令不会再被执行。本文提出三种解决方案:(1)加 HTTP 或者 SOCK ...查看全部
【编者的话】网络运营商的 HTTP 缓存,会导致用户更新 Ubuntu 系统时报错「校验和不符」。如果构建以 Ubuntu 为基础的容器镜像过程出现这个错误, Dockerfile 后续指令不会再被执行。本文提出三种解决方案:(1)加 HTTP 或者 SOCKS 代理;(2)修改软件源的访问协议为 HTTPS 或者 FTP;(3)修改 apt 源码,用 IP 地址指定软件源服务器。

# 1. 问题

使用 Ubuntu 操作系统,执行


sudo apt-get update


更新系统时,经常会见到类似如下所示的报错信息:

W: 无法下载 http://cn.archive.ubuntu.com/ubuntu/dists/trusty-updates/main/source/Sources Hash 校验和不符



,系统更新失败。

这是一个烦人的问题,尤其是当以 Ubuntu 为基础构建容器镜像时,如果系统更新失败, Dockerfile 中的后续指令不会被执行。


「校验和不符」( Hash Sum mismatch) 在 2012 年已经被确认是 Ubuntu 的一个 BUG , 但是几年过去,还是没改好。

出现这个错误的原因是 Ubuntu 下载的索引文件不是来自指定的软件源,而是网络服务提供商的缓存。

网上给出的解决方案:


sudo apt-get clean
sudo rm -rf /var/lib/apt/lists
sudo apt-get update


经实际验证,这种方法是无效的。

# 2. 解决方法

(1)代理

指定使用 HTTP 代理。如果是设置只对当前会话有效的临时代理,执行


export http_proxy=http://yourproxyaddress:proxyport
sudo apt-get update
sudo apt-get upgrade


如果要设置持久代理,编辑 `/etc/apt/apt.conf`,添加一行:


Acquire::http::Proxy "http://yourproxyaddress:proxyport";


,然后执行:


sudo apt-get update
sudo apt-get upgrade


如果没有 HTTP 代理,只有 SOCKS 代理,首先安装 `proxychains` 程序,编辑 `/etc/proxychains.conf` ,指定 SOCKS 服务器的 IP 地址和端口;接下来,执行:


sudo proxychains apt-get update
sudo apt-get upgrade


(2)换协议

网络服务商只使用了 HTTP 缓存,如果软件源还支持 HTTPS 或者 FTP 协议,修改 `/etc/apt/sources.list` ,把其中所有的 `http://` 换成 `ftp://` ,再执行系统更新。

这种方法的不足是中国境内的软件源不支持 FTP 协议访问, Ubuntu 主服务器支持,但是网络速度会比较慢。

(3)黑科技

警告:这种方法是否有潜在问题,还有待持续一段时间的观察。不要在生产环境中使用。

第一步:修改 `apt` 包的源代码,不让它报这个错。


sudo apt-get install build-essential
sudo apt-get build-dep apt
sudo apt-get source apt


此时,有一个 `apt-1.0.1ubuntu2.7` 的文件夹,包含 `apt` 包的源代码。修改 `apt-pkg/accquire-item.cc` ,查找 `HashSumMismatch` 关键词。第一个出现的地方是打印报错信息的函数,不用管。把剩下的五段代码都注释掉。例如,


/*
if (!ExpectedHash.empty() && !ExpectedHash.VerifyFile(DestFile))
{
RenameOnError(HashSumMismatch);
Dequeue();
return;
}
*/


然后,在 `apt-1.0.1ubuntu2.7` 目录下,执行:


make
dpkg-buildpackage -us -uc -nc


成功执行后,在 `apt-1.0.1ubuntu2.7` 的上一级目录中有新创建的一系列 `.deb` 文件。我们的修改,包含在 `libapt-pkg4.12_1.0.1ubuntu2.7_amd64.deb` 中。

安装这个软件包,并标记为不更新:


sudo dpkg -i libapt-pkg4.12_1.0.1ubuntu2.7_amd64.deb
sudo apt-mark hold libapt-pkg4.12


第二步:把 `/etc/apt/sources.list` 中的软件源域名换成对应的 IP 地址。以中国服务器镜像为例,首先查找 `cn.archive.ubuntu.com` 对应的 IP 地址:


dig cn.archive.ubuntu.com


查询结果是:


cn.archive.ubuntu.com. 133 IN CNAME mirrors.aliyun.com.
mirrors.aliyun.com. 133 IN A 112.124.140.210
mirrors.aliyun.com. 133 IN A 115.28.122.210


原来中国服务器就是阿里云镜像。编辑 `/etc/apt/sources.list` , 把 `cn.arhive.ubuntu.com` 替换成 `112.124.140.210` ,保存。

从此以后,就可以无烦恼更新系统了。

=========================

作者:柳泉波,读书喝茶踢球写程序。

如何在Ubuntu系统中使用Overlay文件系统

刘凯宁 发表了文章 • 5 个评论 • 10876 次浏览 • 2015-03-10 19:19 • 来自相关话题

【编者的话】本文用最简洁的语言介绍了如何在Ubuntu系统上运行Overlay文件系统,正如作者所说:AUFS是过去时代的王者,现在新的国王是Overlay。看来Overlay以后将是Docker存储的首选。 在上周的Docker伦敦 ...查看全部
【编者的话】本文用最简洁的语言介绍了如何在Ubuntu系统上运行Overlay文件系统,正如作者所说:AUFS是过去时代的王者,现在新的国王是Overlay。看来Overlay以后将是Docker存储的首选。

在上周的Docker伦敦大会上面,Jérôme Petazzoni分享了「深度研究Docker存储驱动」的演讲,非常棒。如果这件事还没有令我足够信服,那么Jessie Frazelle则完全说服了我,她在Qcon组织的演讲中宣称:AUFS是过去时代的王者,现在新的国王是Overlay。在Jessie的演讲过程中,我打算为我自己搭建这样的一个环境,因为我没有办法找到一个比我现在写的这个更加简单明了的手册。
##3.18 Kernel(3.18版本的内核)
OverlayFS之前已经加入到了Ubuntu内核中,但是那并不是我们想要的。Overlay(没有FS)是一个不同的内核模块,因此你需要安装3.18(或者以上)的内核:
cd /tmp/ 
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-headers-3.18.0-031800-generic_3.18.0-031800.201412071935_amd64.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-headers-3.18.0-031800_3.18.0-031800.201412071935_all.deb
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/linux-image-3.18.0-031800-generic_3.18.0-031800.201412071935_amd64.deb
sudo dpkg -i linux-headers-3.18.0-[i].deb linux-image-3.18.0-[/i].deb

我已经在Ubuntu14.04和12.04环境下测试成功了。
##Docker
你需要安装Docker 1.4或者更高版本(我使用1.5版本做测试的),具体可以参考官方文档来安装。
在有了新的内核并且重新启动以后,现在需要在/etc/default/docker中给DOCKER_OPTS设置`-s overlay`:
# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="-s overlay"

设置好以后,重新启动Docker服务,如果一切顺利的话,你可以从`docker info`命令中得到如下的信息:
$ sudo docker info
Containers: 0
Images: 0
Storage Driver: overlay
Backing Filesystem: extfs
Execution Driver: native-0.2
Kernel Version: 3.18.0-031800-generic
Operating System: Ubuntu 14.04.1 LTS
etc...

为了使Overlay正常跑起来,你可能需要在Ubuntu 12.04的环境下执行`modprobe overlay`。还有一点需要注意:如果 Docker 不能成功地使用 Overlay 作为存储后端,那么将会转为使用DeviceMapper(而不是AUFS)机制存储。

原文链接:Using Overlay file system with Docker on Ubuntu(翻译:刘凯宁 校对:李颖杰)
===========================
译者介绍
刘凯宁,中南大学信息管理与信息系统专业,本科三年级在读,热爱互联网,热爱软件开发技术。大一下开始编程,熟悉Java SE,PHP,Go,有若干小型商业项目实践经验(网站、微信平台、JavaSE实用软件)和软件公司实习经历(上海热璞科技,201407-201409)技术博客:C2P技术博客;QQ:929025296 ;很高兴和各位前辈交流!

如何在Ubuntu14.04的Docker容器中运行OpenVPN?

zyx_today 发表了文章 • 2 个评论 • 16353 次浏览 • 2015-03-01 23:29 • 来自相关话题

【编者的话】本文来自DigitalOcean,DigitalOcean是美国的虚拟专用服务器提供商,本文主要介绍了如何在Ubuntu14.04上创建使用OpenVPN Docker容器。 介绍 本教程将介绍如何使用Do ...查看全部
【编者的话】本文来自DigitalOcean,DigitalOcean是美国的虚拟专用服务器提供商,本文主要介绍了如何在Ubuntu14.04上创建使用OpenVPN Docker容器。

介绍
本教程将介绍如何使用Docker来设置和运行OpenVPN容器。

OpenVPN提供了一种方法来创建TLS加密(SSL的演进)的虚拟专用网络(VPN)。它可以防止网络流量被窃取和中间人(MITM)攻击。专用网络可以用来安全地连接设备,例如,它可以把在不安全的WiFi环境下的笔记本电脑或移动电话连接到远程服务器,然后走Internet流量。它也可用于互联网设备之间的安全连接。

Docker提供了一种封装OpenVPN服务进程和配置数据的方式,以便更容易管理。Docker的OpenVPN镜像是预建的,它包含了在一个稳健环境中运行服务器所需的所有依赖。镜像中包含自动化构建标准案例的脚本,想要手动配置也可以。Docker卷容器可以保存配置以及 EasyRSA PKI证书数据。

Docker Registry是一个中央存储仓库,它包含官方以及用户开发的Docker镜像。在本教程中使用的镜像是用户贡献的(译者注:非官方),你可以在kylemanna/ OpenVPN中找到。该镜像由基于GitHub仓库的Docker Registry云构建服务组装而成。链接在GitHub上的云服务器构建增加了审计Docker 镜像的功能,使用户可以查看源Dockerfile和相关的代码,称为Trusted Build。当GitHub仓库的代码有更新,那么新的Docker image就会被构建并发布到Docker Registry。
使用案例

    []在不可信的公共(无线)网络安全的路由到互联网[/][]用于连接笔记本电脑,办公室电脑,家用电脑,或移动电话的专用网络[/][]用于不具备NAT穿越能力,在NAT路由后面用来安全服务的私有网络[/]
目标
    []在Ubuntu14.04 LTS创建Docker守护进程。[/][]创建用来保存配置数据的Docker卷容器。[/][]生成EasyRSA PKI数字证书(CA)。[/][]提取自动生成的客户端配置文件。[/][]配置可选数量的OpenVPN客户端。[/][]处理在开机时启动Docker容器。[/][]介绍高级主题。[/]
需要准备的知识
    []Linux shell知识。本教程假定用户能够建立并运行Linux守护进程。[/][]远程服务器上的root访问权限[/]
* 一台DigitalOcean的单核CPU/512内存,且运行Ubuntu14.04操作系统的机器。 * 只要主机具有QEMU/ KVM或Xen虚拟化技术,虚拟主机就能运行; OpenVZ的将无法正常工作。 * 你需要在服务器上的root访问权限。本教程假定用户正在运行的是可以使用sudo的非特权用户。如果需要,可以查看在Ubuntu14.04关于用户管理的 Digital Ocean的教程
    []本地客户端设备,如Android手机、笔记本电脑或PC。几乎所有的操作系统都提供了OpenVPN客户端支持。[/]

步骤 1-创建、测试Docker
Docker发展的非常快,而Ubuntu的LTS版本没有及时跟上。为了解决这一问题,我们需要安装一个PPA,以便获取最新的Docker版本。

添加上游的Docker库包签名密钥。`apt-key`命令通过`sudo`来提升权限,所以可能会提示用户输入密码。

curl https://get.docker.io/gpg | sudo apt-key add -

提示:如有必要,在闪烁的光标处输入你的sudo密码。

添加上游Docker库到系统列表:

echo deb http://get.docker.io/ubuntu docker main | sudo tee /etc/apt/sources.list.d/docker.list

更新软件包列表,并安装Docker:

sudo apt-get update && sudo apt-get install -y lxc-docker

将用户添加到`docker`组,以保证它能与Docker守护进程正常通信,`sammy`是你的用户名。退出并重新登录以确保新组生效

sudo usermod -aG docker sammy

重现登陆后,可以使用`id`命令验证组成员,如下:

uid=1001(test0) gid=1001(test0) groups=1001(test0),27(sudo),999(docker)

可选:在一个简单的Debian Docker 镜像中(`-rm` 退出后清理容器 `-it`用于交互)运行`bash` 来验证我们在主机上的Docker操作:

docker run --rm -it debian:jessie bash -l


当Docker载入镜像和建立容器时,会输出如下内容:

Unable to find image 'debian:jessie' locally
debian:jessie: The image you are pulling has been verified
511136ea3c5a: Pull complete
36fd425d7d8a: Pull complete
aaabd2b41e22: Pull complete
Status: Downloaded newer image for debian:jessie
root@de8ffd8f82f6:/#

一旦在容器内你看到`root@:/#`提示,这表示当前shell是在一个容器中。为了确认它不在主机,检查容器中运行的Debian的版本:

cat /etc/issue.net

在进行写操作时,预期OpenVPN会输出:

Debian GNU/Linux jessie/sid

如果你看到一个不同版本的Debian,那也没关系。输入`logout`退出容器,主机的提示会再次出现。
步骤2-建立easyrsa PKI证书存储
这一步对于那些熟悉OpenVPN或经常使用PKI的服务的人来说也非常麻烦。幸运的是,Docker和Docker镜像中的脚本通过生成配置文件以及所有必要的验证文件来简化这一步。

创建一个卷容器。本教程将使用`$ ovpn_data`环境变量。默认`ovpn-data`值推荐使用单个OpenVPN Docker容器服务,这样在Shell中我们就可以使用环境变量:

OVPN_DATA="ovpn-data"

使用`busybox`作为一个最小的Docker镜像,创建一个空Docker volume容器:

docker run --name $OVPN_DATA -v /etc/openvpn busybox

初始化`ovpn_data`容器,它将包含配置文件和证书,并用你的FQDN替代`vpn.example.com`。`vpn.example.com`的值必须是完全合格的域名,你需要用它来与服务器通信,这里假设你已经配置了DNS。另外,也可以使用IP地址,但不推荐。

docker run --volumes-from $OVPN_DATA --rm kylemanna/openvpn ovpn_genconfig -u udp://vpn.example.com:1194

生成EasyRSA PKI 证书授权中心时,可能会要求你输入CA私有密钥的密码。

docker run --volumes-from $OVPN_DATA --rm -it kylemanna/openvpn ovpn_initpki

注意, `$OVPN_DATA`容器的安全性很重要。它包含所有的承担服务和客户端证书的私钥。记住它并适当地控制访问权限。默认的OpenVPN脚本通过密码来为CA key提高安全性以及防止发行假证书。
更多关于备份证书存储细节看下面的结论。

步骤3-开始OpenVPN服务
使用`nano`或`vim`创建一个Upstart初始化文件来自动运行OpenVPN服务进程(更多关于Docker Host Integration )的Docker容器:

sudo vim /etc/init/docker-openvpn.conf

内容放在`/etc/init/docker-openvpn.conf`:

description "Docker container for OpenVPN server"
start on filesystem and started docker
stop on runlevel [!2345]
respawn
script
exec docker run --volumes-from ovpn-data --rm -p 1194:1194/udp --cap-add=NET_ADMIN kylemanna/openvpn
end script

使用Upstart初始化机制来启动进程:

sudo start docker-openvpn

通过看`STATUS`列确认容器开启,容器没有立即崩溃:

test0@tutorial0:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c3ca41324e1d kylemanna/openvpn:latest "ovpn_run" 2 seconds ago Up 2 seconds 0.0.0.0:1194->1194/udp focused_mestorf

步骤4-生成客户端证书和配置文件
在本节中我们将使用在上步创建的PKI CA 创建一个客户端证书。一定要适当的替换`CLIENTNAME`(不一定非要是FQDN)。在客户端的名字是用来识别正在运行的OpenVPN客户端的机器(例如,“家用电脑”,“笔记本电脑”,“nexus5“等)。`easyrsa`工具会提示CA密码。这是我们上面在`ovpn_initpki`命令阶段设定的密码。创建客户端证书:

docker run --volumes-from $OVPN_DATA --rm -it kylemanna/openvpn easyrsa build-client-full CLIENTNAME nopass

当所有的客户端都创建之后,服务就可以准备接受连接了。

客户端需要证书以及配置文件来进行连接。嵌入式脚本自动执行此任务,允许用户在一个单独的文件填写配置,最后传送到客户端。同样,要适当更换`CLIENTNAME`:

docker run --volumes-from $OVPN_DATA --rm kylemanna/openvpn ovpn_getclient CLIENTNAME > CLIENTNAME.ovpn

作为结果的clientname.ovpn文件包含连接到VPN所必要的私钥和证书。要确保这些文件的安全,不要乱放。你需要用他们把.ovpn文件安全地传输到客户端。出于安全考虑,在传送文件时,尽可能地避免使用公共服务,如电子邮件或云存储。
如果可以,推荐使用SSH / SCP,HTTPS,USB和microSD卡进行转移。

步骤5-准备OpenVPN客户端
下面是运行在客户端上的命令和操作,用以连接到上文配置的OpenVPN服务。
Ubuntu和Debian的分布通过原生OpenVPN
在Ubuntu12.04/14.04和Debian wheezy/jessie客户端(或者类似的):
安装OpenVPN:

sudo apt-get install openvpn

从服务上复制客户端配置文件,设置安全权限:

sudo install -o root -m 400 CLIENTNAME.ovpn /etc/openvpn/CLIENTNAME.conf

配置初始化脚本, 自动启动所有匹配/etc/openvpn/*.conf的配置:

echo AUTOSTART=all | sudo tee -a /etc/default/openvpn

重启OpenVPN客户端的服务进程:

sudo /etc/init.d/openvpn restart

Arch Linux通过原生OpenVPN
安装OpenVPN:

pacman -Sy openvpn

从服务上复制客户端配置文件,设置安全权限:

sudo install -o root -m 400 CLIENTNAME.ovpn /etc/openvpn/CLIENTNAME.conf

启动OpenVPN客户端的服务进程:

systemctl start openvpn@CLIENTNAME

可选:启动时配置systemd 来开始/etc/openvpn/CLIENTNAME.conf :

systemctl enable openvpn@CLIENTNAME

MacOS X通过tunnelblick

下载并安装tunnelblick
从服务器复制`CLIENTNAME.ovpn`到Mac。
通过双击`*.ovpn`文件导入配置. TunnelBlick将引用和导入配置。
打开TunnelBlick,选择配置,然后选择连接。

Android通过OpenVPN连接

从Google Play商店安装OpenVPN Connect App
以安全的方式从服务器复制`CLIENTNAME.ovpn`到Android设备上。USB或MicroSD卡更加安全。把文件放到你的SD卡上便于打开。
导入配置:菜单->导入->从SD卡导入文件
选择连接

步骤6-验证操作
有几种通过VPN路由来验证网络连接的方法。
网页浏览器
访问网站来确定外部IP地址。外部IP地址应该是OpenVPN服务器。
试试google“what is my ip”icanhazip.com
命令行
从命令行,`wget`或`curl`命令派上用场。以`curl`为例:

curl icanhazip.com

以`wget`为例:

wget -qO - icanhazip.com

预期的反应应该是OpenVPN服务器的IP地址。
另一个选择是使用`dig`或使用`host`到一个特殊配置的DNS服务器做专用的DNS查询。基于`host`的例子:

host -t A myip.opendns.com resolver1.opendns.com

基于`dig`的例子:

dig +short myip.opendns.com @resolver1.opendns.com

预期的反应应该是OpenVPN服务器的IP地址。
额外检查
回顾你的网络接口的配置。在基于UNIX操作系统,这跟运行`ifconfig`终端,查找OpenVPN的`tunX`接口一样简单。
审核日志。在UNIX操作系统,旧的distributions审核 `/var/log `,在systemd distributions审核`journalctl`。
结论
这里创建和运行的Docker镜像是开源的,而且功能远超本文的描述。你可以在docker-openvpn的GitHub仓库浏览源代码或者创建修改分支。

原文链接:How To Run OpenVPN in a Docker Container on Ubuntu 14.04 (翻译:张逸仙 校对:夕口夕)

===========================
译者介绍
张逸仙,码农一枚,Docker爱好者。翻译的错误和不足请指教zyx_today@126.com或直接私信我。
Ubuntu是一个自由、开源、基于Debian的Linux发行版,发行周期为6个月,由 Canonical 公司和自由软件社区开发。 普通的桌面应用版可以获得18个月的支援,标为LTS(“长期支持版”)的桌面版本获得3年、服务器版本5年的支持。