标签 Docker 下的文章

各位,今天我们将学习如何在Docker之中运行GUI程序。我们可以轻易地在Docker容器中运行大多数GUI程序且不出错。Docker是一个开源项目,提供了一个打包、分发和运行任意程序的轻量级容器的开放平台。它没有语言支持、框架或者打包系统的限制,并可以运行在任何地方、任何时候,从小型的家用电脑到高端的服务器都可以运行。这让人们可以打包不同的包用于部署和扩展网络应用,数据库和后端服务而不必依赖于特定的栈或者提供商。

下面是我们该如何在Docker容器中运行GUI程序的简单步骤。本教程中,我们会用Firefox作为例子。

1. 安装 Docker

在开始前,我们首先得确保在Linux主机中已经安装了Docker。这里,我运行的是CentOS 7 主机,我们将运行yum管理器和下面的命令来安装Docker。

# yum install docker

# systemctl restart docker.service

2. 创建 Dockerfile

现在,Docker守护进程已经在运行中了,我们现在准备创建自己的Firefox Docker容器。我们要创建一个Dockerfile,在其中我们要输入需要的配置来创建一个可以工作的Firefox容器。为了运行 Docker 镜像我们需要使用最新版本的CentOS。要创建 Docker 镜像,我们需要用文本编辑器创建一个名为Dockerfile的文件。

# nano Dockerfile

接着,在Dockerfile中添加下面的行并保存。

#!/bin/bash
FROM centos:7
RUN yum install -y firefox
# 用你自己的 uid /gid 替换下面的0
RUN export uid=0 gid=0
RUN mkdir -p /home/developer
RUN echo "developer:x:${uid}:${gid}:Developer,,,:/home/developer:/bin/bash" >> /etc/passwd
RUN echo "developer:x:${uid}:" >> /etc/group
RUN echo "developer ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
RUN chmod 0440 /etc/sudoers
RUN chown ${uid}:${gid} -R /home/developer

USER developer
ENV HOME /home/developer
CMD /usr/bin/firefox

注意:在第四行的配置中,用你自己的用户和组id来替换0。 我们可以用下面的命令在shell或者终端中得到uid和gid。

#  id $USER

3. 构造Docker容器

下面我们就要根据上面的Dockerfile构建一个容器。它会安装firefox浏览器和它需要的包。它接着会设置用户权限并让它可以工作。这里镜像名是firefox,你可以根据你的需要命名。

# docker build --rm -t firefox .

4. 运行Docker容器

现在,如果一切顺利,我们现在可以在运行在CentOS 7镜像中的Docker容器里面运行我们的GUI程序也就是Firefox浏览器了。

# docker run -ti --rm -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix firefox

总结

在Docker容器中运行GUI程序是一次很棒的体验,它对你的主机文件系统没有任何的伤害。它完全依赖你的Docker容器。本教程中,我尝试了CentOS 7 Docker中的Firefox。我们可以用这个技术尝试更多的GUI程序。如果你有任何问题、建议、反馈请在下面的评论栏中写下来,这样我们可以提升或更新我们的内容。谢谢!


via: http://linoxide.com/linux-how-to/run-gui-apps-docker-container/

作者:Arun Pyasi 译者:geekpi 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Ubuntu Core为运行容器提供了最小的轻量级Linux环境

Google为自己的云服务采用了一个简化版的Canonical Ubuntu Linux发行版,以优化运行Docker和其他容器。

Ubuntu Core被设计成仅提供在云上运行Linux所必需的组件。它发布了一个早期预览版,Canonical命名其为“Snappy”。这个新版本裁减了大量在普通Linux发行版中常见而在云应用中不实用的库和应用程序。

Google计算引擎(GCE)和Microsoft Azure加入了支持这个新的发行版的行列。

从Canonical了解到,Ubuntu Core将为用户提供一个部署Docker的简单方式,一个日益精简的虚拟容器允许用户快速启动工作负载并轻松地转移,甚至可以跨越不同的云服务提供商。

Google是Docker和基于容器的虚拟化的热心支持者。在去年六月份,这家公司用开源的方式发布了一个容器管理软件:Kubernetes。

Ubuntu Core在设计上类似于另一个发布于一年前的 Linux发行版 CoreOS。CoreOS 主要由两名前Rackspace工程师开发,CoreOS是一个轻量级Linux发行版,设计运行在集群中,被那些在网页上完成他们大部分或所有业务的公司所喜好的大规模环境。CoreOS很快被许多云服务提供商采用,包括Microsoft Azure,Amazon网站服务,DigitalOcean以及Google计算引擎。

如同CoreOS一样,Ubuntu Core提供了一个快速引擎来更新组件,减少系统管理员去手动处理的时间。


via: http://www.infoworld.com/article/2860401/cloud-computing/google-cloud-offers-streamlined-ubuntu-for-docker-use.html

作者:Joab Jackson 译者:zpl1025 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Docker - 迄今为止发生的那些事情

Docker 是一个专为 Linux 容器而设计的工具集,用于‘构建、交付和运行’分布式应用。它最初是 DotCloud 的一个开源项目,于2013年3月发布。这个项目越来越受欢迎,以至于 DotCloud 公司都更名为 Docker 公司(并最终出售了原有的 PaaS 业务)。Docker 1.0是在2014年6月发布的,而且延续了之前每月更新一个版本的传统。

Docker 1.0版本的发布标志着 Docker 公司认为该平台已经充分成熟,足以用于生产环境中(由该公司与合作伙伴提供付费支持选择)。每个月发布的更新表明该项目正在迅速发展,比如增添一些新特性、解决一些他们发现的问题。该项目已经成功地分离了‘运行’和‘交付’两件事,所以来自任何版本的 Docker 镜像源都可以与其它版本共同使用(具备向前和向后兼容的特性),这为 Docker 应对快速变化提供了稳定的保障。

Docker 之所以能够成为最受欢迎的开源项目之一可能会被很多人看做是炒作,但是也是由其坚实的基础所决定的。Docker 的影响力已经得到整个行业许多大企业的支持,包括亚马逊, Canonical 公司, CenturyLink, 谷歌, IBM, 微软, New Relic, Pivotal, 红帽和 VMware。这使得只要有 Linux 的地方,Docker 就可以无处不在。除了这些鼎鼎有名的大公司以外,许多初创公司也在围绕着 Docker 发展,或者改变他们的发展方向来与 Docker 更好地结合起来。这些合作伙伴们(无论大或小)都将帮助推动 Docker 核心项目及其周边生态环境的快速发展。

Docker 技术简要综述

Docker 利用 Linux 的一些内核机制例如 cGroups、命名空间和 SElinux 来实现容器之间的隔离。起初 Docker 只是 LXC 容器管理器子系统的前端,但是在 0.9 版本中引入了 libcontainer,这是一个原生的 go 语言库,提供了用户空间和内核之间的接口。

容器是基于 AUFS 这样的联合文件系统的,它允许跨多个容器共享组件,如操作系统镜像和已安装的相关库。这种文件系统的分层方法也被 Dockerfile 的 DevOps 工具所利用,这些工具能够缓存成功完成的操作。这就省下了安装操作系统和相关应用程序依赖包的时间,极大地加速测试周期。另外,在容器之间的共享库也能够减少内存的占用。

一个容器是从一个镜像开始运行的,它可以来自本地创建,本地缓存,或者从一个注册库(registry)下载。Docker 公司运营的 Docker Hub 公有注册库,为各种操作系统、中间件和数据库提供了官方仓库存储。各个组织和个人都可以在 docker Hub 上发布的镜像的公有库,也可以注册成私有仓库。由于上传的镜像可以包含几乎任何内容,所以 Docker 提供了一种自动构建工具(以往称为“可信构建”),镜像可以从一种称之为 Dockerfile 的镜像内容清单构建而成。

容器 vs. 虚拟机

容器会比虚拟机更高效,因为它们能够分享一个内核和分享应用程序库。相比虚拟机系统,这也将使得 Docker 使用的内存更小,即便虚拟机利用了内存超量使用的技术。部署容器时共享底层的镜像层也可以减少存储占用。IBM 的 Boden Russel 已经做了一些基准测试来说明两者之间的不同。

相比虚拟机系统,容器具有较低系统开销的优势,所以在容器中,应用程序的运行效率将会等效于在同样的应用程序在虚拟机中运行,甚至效果更佳。IBM 的一个研究团队已经发表了一本名为[虚拟机与 Linux 容器的性能比较]的文章11

容器只是在隔离特性上要比虚拟机逊色。虚拟机可以利用如 Intel 的 VT-d 和 VT-x 技术的 ring-1 硬件隔离技术。这种隔离可以防止虚拟机突破和彼此交互。而容器至今还没有任何形式的硬件隔离,这使它容易受到攻击。一个称为 Shocker 的概念攻击验证表明,在 Docker 1.0 之前的版本是存在这种脆弱性的。尽管 Docker 1.0 修复了许多由 Shocker 漏洞带来的较为严重的问题,Docker 的 CTO Solomon Hykes 仍然,“当我们可以放心宣称 Docker 的开箱即用是安全的,即便是不可信的 uid0 程序(超级用户权限程序),我们将会很明确地告诉大家。”Hykes 的声明承认,其漏洞及相关的风险依旧存在,所以在容器成为受信任的工具之前将有更多的工作要做。

对于许多用户案例而言,在容器和虚拟机之间二者选择其一是种错误的二分法。Docker 同样可以在虚拟机中工作的很好,这让它可以用在现有的虚拟基础措施、私有云或者公有云中。同样也可以在容器里跑虚拟机,这也类似于谷歌在其云平台的使用方式。像 IaaS 服务这样普遍可用的基础设施,能够即时提供所需的虚拟机,可以预期容器与虚拟机一起使用的情景将会在数年后出现。容器管理和虚拟机技术也有可能被集成到一起提供一个两全其美的方案;这样,一个硬件信任锚微虚拟化所支撑的 libcontainer 容器,可与前端 Docker 工具链和生态系统整合,而使用提供更好隔离性的不同后端。微虚拟化(例如 Bromium 的 vSentry 和 VMware 的 Project Fargo)已经用于在桌面环境中以提供基于硬件的应用程序隔离,所以类似的方法也可以用于 libcontainer,作为 Linux内核中的容器机制的替代技术。

‘容器化’ 的应用程序

几乎所有 Linux 应用程序都可以在 Docker 容器中运行,并没有编程语言或框架的限制。唯一的实际限制是以操作系统的角度来允许容器做什么。即使如此,也可以在特权模式下运行容器,从而大大减少了限制(与之对应的是容器中的应用程序的风险增加,可能导致损坏主机操作系统)。

容器都是从镜像开始运行的,而镜像也可以从运行中的容器获取。本质上说,有两种方法可以将应用程序放到容器中,分别是手动构建和 Dockerfile。

手动构建

手动构建从启动一个基础的操作系统镜像开始,然后在交互式终端中用你所选的 Linux 提供的包管理器安装应用程序及其依赖项。Zef Hemel 在‘使用 Linux 容器来支持便携式应用程序部署’的文章中讲述了他部署的过程。一旦应用程序被安装之后,容器就可以被推送至注册库(例如Docker Hub)或者导出为一个tar文件。

Dockerfile

Dockerfile 是一个用于构建 Docker 容器的脚本化系统。每一个 Dockerfile 定义了开始的基础镜像,以及一系列在容器中运行的命令或者一些被添加到容器中的文件。Dockerfile 也可以指定对外的端口和当前工作目录,以及容器启动时默认执行的命令。用 Dockerfile 构建的容器可以像手工构建的镜像一样推送或导出。Dockerfile 也可以用于 Docker Hub 的自动构建系统,即在 Docker 公司的控制下从头构建,并且该镜像的源代码是任何需要使用它的人可见的。

单进程?

无论镜像是手动构建还是通过 Dockerfile 构建,有一个要考虑的关键因素是当容器启动时仅启动一个进程。对于一个单一用途的容器,例如运行一个应用服务器,运行一个单一的进程不是一个问题(有些关于容器应该只有一个单独的进程的争议)。对于一些容器需要启动多个进程的情况,必须先启动 supervisor 进程,才能生成其它内部所需的进程。由于容器内没有初始化系统,所以任何依赖于 systemd、upstart 或类似初始化系统的东西不修改是无法工作的。

容器和微服务

全面介绍使用微服务结构体系的原理和好处已经超出了这篇文章的范畴(在 InfoQ eMag: Microservices 有全面阐述)。然而容器是绑定和部署微服务实例的捷径。

大规模微服务部署的多数案例都是部署在虚拟机上,容器只是用于较小规模的部署上。容器具有共享操作系统和公用库的的内存和硬盘存储的能力,这也意味着它可以非常有效的并行部署多个版本的服务。

连接容器

一些小的应用程序适合放在单独的容器中,但在许多案例中应用程序需要分布在多个容器中。Docker 的成功包括催生了一连串新的应用程序组合工具、编制工具及平台作为服务(PaaS)的实现。在这些努力的背后,是希望简化从一组相互连接的容器来创建应用的过程。很多工具也在扩展、容错、性能管理以及对已部署资产进行版本控制方面提供了帮助。

连通性

Docker 的网络功能是相当原始的。在同一主机,容器内的服务可以互相访问,而且 Docker 也可以通过端口映射到主机操作系统,使服务可以通过网络访问。官方支持的提供连接能力的库叫做 libchan,这是一个提供给 Go 语言的网络服务库,类似于channels。在 libchan 找到进入应用的方法之前,第三方应用仍然有很大空间可提供配套的网络服务。例如,Flocker 已经采取了基于代理的方法使服务实现跨主机(以及底层存储)的移植。

合成

Docker 本身拥有把容器连接在一起的机制,与元数据相关的依赖项可以被传递到相依赖的容器中,并用于环境变量和主机入口。如 Figgeard 这样的应用合成工具可以在单一文件中展示出这种依赖关系图,这样多个容器就可以汇聚成一个连贯的系统。CenturyLink 公司的 Panamax 合成工具类似 Fig 和 geard 的底层实现方法,但新增了一些基于 web 的用户接口,并直接与 GitHub 相结合,以便于应用程序分享。

编制

Decking、New Relic 公司的 Centurion 和谷歌公司的 Kubernetes 这样的编制系统都是旨在协助容器的部署和管理其生命周期系统。也有许多 Apache Mesos (特别是 [Marathon(马拉松式)持续运行很久的框架])的案例(例如Mesosphere)已经被用于配合 Docker 一起使用。通过为应用程序与底层基础架构之间(例如传递 CPU 核数和内存的需求)提供一个抽象的模型,编制工具提供了两者的解耦,简化了应用程序开发和数据中心操作。有很多各种各样的编制系统,因为许多来自内部系统的以前开发的用于大规模容器部署的工具浮现出来了;如 Kubernetes 是基于谷歌的 Omega 系统的,Omega 是用于管理遍布谷歌云环境中容器的系统。

虽然从某种程度上来说合成工具和编制工具的功能存在重叠,但这也是它们之间互补的一种方式。例如 Fig 可以被用于描述容器间如何实现功能交互,而 Kubernetes pods(容器组)可用于提供监控和扩展。

平台(即服务)

有一些 Docker 原生的 PaaS 服务实现,例如 DeisFlynn 已经显现出 Linux 容器在开发上的的灵活性(而不是那些“自以为是”的给出一套语言和框架)。其它平台,例如 CloudFoundry、OpenShift 和 Apcera Continuum 都已经采取将 Docker 基础功能融入其现有的系统的技术路线,这样基于 Docker 镜像(或者基于 Dockerfile)的应用程序也可以与之前用支持的语言和框架的开发的应用一同部署和管理。

所有的云

由于 Docker 能够运行在任何正常更新内核的 Linux 虚拟机中,它几乎可以用在所有提供 IaaS 服务的云上。大多数的主流云厂商已经宣布提供对 Docker 及其生态系统的支持。

亚马逊已经把 Docker 引入它们的 Elastic Beanstalk 系统(这是在底层 IaaS 上的一个编制系统)。谷歌使 Docker 成为了“可管理的 VM”,它提供了GAE PaaS 和GCE IaaS 之间的中转站。微软和 IBM 也都已经宣布了基于 Kubernetes 的服务,这样可以在它们的云上部署和管理多容器应用程序。

为了给现有种类繁多的后端提供可用的一致接口,Docker 团队已经引进 libswarm, 它可以集成于众多的云和资源管理系统。Libswarm 所阐明的目标之一是“通过切换服务来源避免被特定供应商套牢”。这是通过呈现一组一致的服务(与API相关联的)来完成的,该服务会通过特定的后端服务所实现。例如 Docker 服务器将支持本地 Docker 命令行工具的 Docker 远程 API 调用,这样就可以管理一组服务供应商的容器了。

基于 Docker 的新服务类型仍在起步阶段。总部位于伦敦的 Orchard 实验室提供了 Docker 的托管服务,但是 Docker 公司表示,收购 Orchard 后,其相关服务不会置于优先位置。Docker 公司也出售了之前 DotCloud 的PaaS 业务给 cloudControl。基于更早的容器管理系统的服务例如 OpenVZ 已经司空见惯了,所以在一定程度上 Docker 需要向主机托管商们证明其价值。

Docker 及其发行版

Docker 已经成为大多数 Linux 发行版例如 Ubuntu、Red Hat 企业版(RHEL)和 CentOS 的一个标准功能。遗憾的是这些发行版的步调和 Docker 项目并不一致,所以在发布版中找到的版本总是远远落后于最新版本。例如 Ubuntu 14.04 版本中的版本是 Docker 0.9.1,而当 Ubuntu 升级至 14.04.1 时 Docker 版本并没有随之升级(此时 Docker 已经升至 1.1.2 版本)。在发行版的软件仓库中还有一个名字空间的冲突,因为 “Docker” 也是 KDE 系统托盘的名字;所以在 Ubuntu 14.04 版本中相关安装包的名字和命令行工具都是使用“Docker.io”的名字。

在企业级 Linux 的世界中,情况也并没有因此而不同。CentOS 7 中的 Docker 版本是 0.11.1,这是 Docker 公司宣布准备发行 Docker 1.0 产品版本之前的开发版。Linux 发行版用户如果希望使用最新版本以保障其稳定、性能和安全,那么最好地按照 Docker 的安装说明进行,使用 Docker 公司的所提供的软件库而不是采用发行版的。

Docker 的到来也催生了新的 Linux 发行版,如 CoreOS 和红帽的 Project Atomic,它们被设计为能运行容器的最小环境。这些发布版相比传统的发行版,带着更新的内核及 Docker 版本,对内存的使用和硬盘占用率也更低。新发行版也配备了用于大型部署的新工具,例如 fleet(一个分布式初始化系统)和etcd(用于元数据管理)。这些发行版也有新的自我更新机制,以便可以使用最新的内核和 Docker。这也意味着使用 Docker 的影响之一是它抛开了对发行版和相关的包管理解决方案的关注,而对 Linux 内核(及使用它的 Docker 子系统)更加关注。

这些新发行版也许是运行 Docker 的最好方式,但是传统的发行版和它们的包管理器对容器来说仍然是非常重要的。Docker Hub 托管的官方镜像有 Debian、Ubuntu 和 CentOS,以及一个‘半官方’的 Fedora 镜像库。RHEL 镜像在Docker Hub 中不可用,因为它是 Red Hat 直接发布的。这意味着在 Docker Hub 的自动构建机制仅仅用于那些纯开源发行版下(并愿意信任那些源于 Docker 公司团队提供的基础镜像)。

Docker Hub 集成了如 Git Hub 和 Bitbucket 这样源代码控制系统来自动构建包管理器,用于管理构建过程中创建的构建规范(在Dockerfile中)和生成的镜像之间的复杂关系。构建过程的不确定结果并非是 Docker 的特定问题——而与软件包管理器如何工作有关。今天构建完成的是一个版本,明天构建的可能就是更新的版本,这就是为什么软件包管理器需要升级的原因。容器抽象(较少关注容器中的内容)以及容器扩展(因为轻量级资源利用率)有可能让这种不确定性成为 Docker 的痛点。

Docker 的未来

Docker 公司对核心功能(libcontainer),跨服务管理(libswarm) 和容器间的信息传递(libchan)的发展上提出了明确的路线。与此同时,该公司已经表明愿意收购 Orchard 实验室,将其纳入自身生态系统。然而 Docker 不仅仅是 Docker 公司的,这个项目的贡献者也来自许多大牌贡献者,其中不乏像谷歌、IBM 和 Red Hat 这样的大公司。在仁慈独裁者、CTO Solomon Hykes 掌舵的形势下,为公司和项目明确了技术领导关系。在前18个月的项目中通过成果输出展现了其快速行动的能力,而且这种趋势并没有减弱的迹象。

许多投资者正在寻找10年前 VMware 公司的 ESX/vSphere 平台的特征矩阵,并试图找出虚拟机的普及而带动的企业预期和当前 Docker 生态系统两者的距离(和机会)。目前 Docker 生态系统正缺乏类似网络、存储和(对于容器的内容的)细粒度版本管理,这些都为初创企业和创业者提供了机会。

随着时间的推移,在虚拟机和容器(Docker 的“运行”部分)之间的区别将变得没那么重要了,而关注点将会转移到“构建”和“交付”方面。这些变化将会使“Docker发生什么?”变得不如“Docker将会给IT产业带来什么?”那么重要了。


via: http://www.infoq.com/articles/docker-future

作者:Chris Swan 译者:disylee 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

最近使用Docker下载“官方”容器镜像的时候,我发现这样一句话:

ubuntu:14.04: The image you are pulling has been verified (您所拉取的镜像已经经过验证)

起初我以为这条信息引自Docker大力推广的镜像签名系统,因此也就没有继续跟进。后来,研究加密摘要系统的时候——Docker用这套系统来对镜像进行安全加固——我才有机会更深入的发现,逻辑上整个与镜像安全相关的部分具有一系列系统性问题。

Docker所报告的,一个已下载的镜像经过“验证”,它基于的仅仅是一个标记清单(signed manifest),而Docker却从未据此清单对镜像的校验和进行验证。一名攻击者以此可以提供任意所谓具有标记清单的镜像。一系列严重漏洞的大门就此敞开。

镜像经由HTTPS服务器下载后,通过一个未加密的管道流进入Docker守护进程:

[decompress] -> [tarsum] -> [unpack]

这条管道的性能没有问题,但是却完全没有经过加密。不可信的输入在签名验证之前是不应当进入管道的。不幸的是,Docker在上面处理镜像的三个步骤中,都没有对校验和进行验证。

然而,不论Docker如何声明,实际上镜像的校验和(Checksum)从未经过校验。下面是Docker与镜像校验和的验证相关的代码片段,即使我提交了校验和不匹配的镜像,都无法触发警告信息。

if img.Checksum != "" && img.Checksum != checksum {
  log.Warnf("image layer checksum mismatch: computed %q,
             expected %q", checksum, img.Checksum)
}

不安全的处理管道

解压缩

Docker支持三种压缩算法:gzip、bzip2和xz。前两种使用Go的标准库实现,是内存安全(memory-safe)的,因此这里我预计的攻击类型应该是拒绝服务类的攻击,包括CPU和内存使用上的当机或过载等等。

第三种压缩算法,xz,比较有意思。因为没有现成的Go实现,Docker 通过执行(exec)xz二进制命令来实现解压缩。

xz二进制程序来自于XZ Utils项目,由大概2万行C代码生成而来。而C语言不是一门内存安全的语言。这意味着C程序的恶意输入,在这里也就是Docker镜像的XZ Utils解包程序,潜在地存在可能会执行任意代码的风险。

Docker以root权限运行 xz 命令,更加恶化了这一潜在威胁。这意味着如果在xz中出现了一个漏洞,对docker pull命令的调用就会导致用户整个系统的完全沦陷。

Tarsum

对tarsum的使用,其出发点是好的,但却是最大的败笔。为了得到任意一个加密tar文件的准确校验和,Docker先对tar文件进行解密,然后求出特定部分的哈希值,同时排除剩余的部分,而这些步骤的顺序都是固定的

由于其生成校验和的步骤固定,它解码不可信数据的过程就有可能被设计成攻破tarsum的代码。这里潜在的攻击既包括拒绝服务攻击,还有逻辑上的漏洞攻击,可能导致文件被感染、忽略、进程被篡改、植入等等,这一切攻击的同时,校验和可能都是不变的。

解包

解包的过程包括tar解码和生成硬盘上的文件。这一过程尤其危险,因为在解包写入硬盘的过程中有另外三个已报告的漏洞

任何情形下未经验证的数据都不应当解包后直接写入硬盘。

libtrust

Docker的工具包libtrust,号称“通过一个分布式的信任图表进行认证和访问控制”。很不幸,对此官方没有任何具体的说明,看起来它好像是实现了一些javascript对象标记和加密规格以及其他一些未说明的算法。

使用libtrust下载一个清单经过签名和认证的镜像,就可以触发下面这条不准确的信息(说不准确,是因为事实上它验证的只是清单,并非真正的镜像):

ubuntu:14.04: The image you are pulling has been verified(您所拉取的镜像已经经过验证)

目前只有Docker公司“官方”发布的镜像清单使用了这套签名系统,但是上次我参加Docker管理咨询委员会的会议讨论时,我所理解的是,Docker公司正计划在未来扩大部署这套系统。他们的目标是以Docker公司为中心,控制一个认证授权机构,对镜像进行签名和(或)客户认证。

我试图从Docker的代码中找到签名秘钥,但是没找到。好像它并不像我们所期望的把密钥嵌在二进制代码中,而是在每次镜像下载前,由Docker守护进程通过HTTPS从CDN远程获取。这是一个多么糟糕的方案,有无数种攻击手段可能会将可信密钥替换成恶意密钥。这些攻击包括但不限于:CDN供应商出问题、CDN初始密钥出现问题、客户端下载时的中间人攻击等等。

补救

研究结束前,我报告了一些在tarsum系统中发现的问题,但是截至目前我报告的这些问题仍然没有修复。

要改进Docker镜像下载系统的安全问题,我认为应当有以下措施:

摒弃tarsum并且真正对镜像本身进行验证

出于安全原因tarsum应当被摒弃,同时,镜像在完整下载后、其他步骤开始前,就对镜像的加密签名进行验证。

添加权限隔离

镜像的处理过程中涉及到解压缩或解包的步骤必须在隔离的进程(容器?)中进行,即只给予其操作所需的最小权限。任何场景下都不应当使用root运行xz这样的解压缩工具。

替换 libtrust

应当用更新框架(The Update Framework)替换掉libtrust,这是专门设计用来解决软件二进制签名此类实际问题的。其威胁模型非常全方位,能够解决libtrust中未曾考虑到的诸多问题,目前已经有了完整的说明文档。除了已有的Python实现,我已经开始着手用Go语言实现的工作,也欢迎大家的贡献。

作为将更新框架加入Docker的一部分,还应当加入一个本地密钥存储池,将root密钥与registry的地址进行映射,这样用户就可以拥有他们自己的签名密钥,而不必使用Docker公司的了。

我注意到使用非Docker公司官方的第三方仓库往往会是一种非常糟糕的用户体验。Docker也会将第三方的仓库内容降为二等地位来看待,即使不因为技术上的原因。这个问题不仅仅是生态问题,还是一个终端用户的安全问题。针对第三方仓库的全方位、去中心化的安全模型既必须又迫切。我希望Docker公司在重新设计他们的安全模型和镜像认证系统时能采纳这一点。

结论

Docker用户应当意识到负责下载镜像的代码是非常不安全的。用户们应当只下载那些出处没有问题的镜像。目前,这里的“没有问题”并包括Docker公司的“可信(trusted)”镜像,例如官方的Ubuntu和其他基础镜像。

最好的选择就是在本地屏蔽 index.docker.io,然后使用docker load命令在导入Docker之前手动下载镜像并对其进行验证。Red Hat的安全博客有一篇很好的文章,大家可以看看。

感谢Lewis Marshall指出tarsum从未真正验证。

参考


via: https://titanous.com/posts/docker-insecurity

作者:titanous 译者:Mr小眼儿 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Docker 是一个开源工具,它可以让创建和管理 Linux 容器变得简单。容器就像是轻量级的虚拟机,并且可以以毫秒级的速度来启动或停止。Docker 帮助系统管理员和程序员在容器中开发应用程序,并且可以扩展到成千上万的节点。

容器和 VM(虚拟机)的主要区别是,容器提供了基于进程的隔离,而虚拟机提供了资源的完全隔离。虚拟机可能需要一分钟来启动,而容器只需要一秒钟或更短。容器使用宿主操作系统的内核,而虚拟机使用独立的内核。

Docker 的局限性之一是,它只能用在 64 位的操作系统上。

在这篇文章中我们将讨论如何在 CentOS 7.x 中安装 docker。

CentOS 7 中 Docker 的安装

Docker 软件包已经包括在默认的 CentOS-Extras 软件源里。因此想要安装 docker,只需要运行下面的 yum 命令:

[root@localhost ~]# yum install docker

启动 Docker 服务

安装完成后,使用下面的命令来启动 docker 服务,并将其设置为开机启动:

[root@localhost ~]# service docker start
[root@localhost ~]# chkconfig docker on

(LCTT 译注:此处采用了旧式的 sysv 语法,如采用CentOS 7中支持的新式 systemd 语法,如下:

[root@localhost ~]# systemctl  start docker.service
[root@localhost ~]# systemctl  enable docker.service

下载官方的 CentOS 镜像到本地 (LCTT 译注:由于 Docker 被 :-< ,所以请使用 http://docker.cn镜像,感谢 @马全一 的镜像。 )

[root@localhost ~]# docker pull centos
Pulling repository centos
192178b11d36: Download complete 
70441cac1ed5: Download complete 
ae0c2d0bdc10: Download complete 
511136ea3c5a: Download complete 
5b12ef8fd570: Download complete

确认 CentOS 镜像已经被获取:

[root@localhost ~]# docker images centos
REPOSITORY    TAG          IMAGE ID      CREATED       VIRTUAL SIZE
centos        centos5      192178b11d36  2 weeks ago   466.9 MB
centos        centos6      70441cac1ed5  2 weeks ago   215.8 MB
centos        centos7      ae0c2d0bdc10  2 weeks ago   224 MB
centos        latest       ae0c2d0bdc10  2 weeks ago   224 MB

运行一个 Docker 容器:

[root@localhost ~]# docker run -i -t centos /bin/bash
[root@dbf66395436d /]#

我们可以看到,CentOS 容器已经被启动,并且我们得到了 bash 提示符。在 docker 命令中我们使用了 “-i 捕获标准输入输出”和 “-t 分配一个终端或控制台”选项。若要断开与容器的连接,输入 exit。

[root@cd05639b3f5c /]# cat /etc/redhat-release 
CentOS Linux release 7.0.1406 (Core) 
[root@cd05639b3f5c /]# exit
exit
[root@localhost ~]#

我们还可以搜索基于 Fedora 和 Ubuntu 操作系统的容器。

[root@localhost ~]# docker search ubuntu
[root@localhost ~]# docker search fedora

显示当前正在运行容器的列表


via: http://www.linuxtechi.com/install-docker-on-centos-7/

作者:Pradeep Kumar 译者:felixonmars 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

使用“容器”来保证主机环境的安全性,这个概念早在十年前就已经存在(例如 FreeBSD 的 jail 虚拟化技术),但是直到最近,随着部署云架构需求越来越多,像 LXC 和 Docker 这种 Linux 下的容器才成为被关注的焦点。当然,由于主流厂商(云服务商如亚马逊主推 AWS,微软主推 Azure;发行版如红帽、Ubuntu等)组成的强大靠山,Docker 已经被放在媒体的聚光灯下面,其实,Docker 里面所谓的“容器”技术是由 LXC 提供的。

你只是一个普通的 Linux 用户,那 Docker/LXC 能为你带来什么好处呢?容器可以将你的应用在不同的 Linux 发行版之间迁移。想像一下这个场景:你正在用的发行版是 Debian,你喜欢它的稳定性,同时你又想玩一款最新的 Ubuntu 游戏,你不需要在电脑上装双系统然后重启进入 Ubuntu,也不需要在 Debian 上跑一个耗资源的 Ubuntu 虚拟机,你只需要简单地生成一个 Ubuntu 容器就够了。

抛开 Docker 的好处不谈,让我们聊一下 LXC 容器的好处:我可以使用 libvirt 提供的接口来管理 LXC,这些接口和 Docker 没有任何关系。如果你有使用基于 libvirt 库的管理工具(例如 virt-manager 和 virsh),你就可以使用它们来管理 LXC 容器。

在这篇教程中,我只介绍标准 LXC 容器管理工具的命令行操作,来教你如何在 Ubuntu 下创建和管理 LXC 容器

Ubuntu 下安装 LXC

使用下面的命令安装 LXC 在用户态的工具:

$ sudo apt-get install lxc

然后检查当前内核是否支持 LXC。如果所有结果都是“enable”,说明内核支持:

$ lxc-checkconfig 

安装完 LXC 工具后,就能看到 LXC 自动创建了一块桥接网卡(lxcbr0,可以在 /etc/lxc/default.conf 中设置)。

当你创建了 LXC 容器后,它的网口会自动链接到这个桥接网卡上,然后这个容器就能和外部世界通信了。

创建 LXC 容器

为了在指定环境下(比如 Debian Wheezy 64位)创建 LXC 容器,你需要一个相应的 LXC 模板。幸运的是 LXC 提供的工具集成了一整套现成的 LXC 模板,你可以在 /usr/share/lxc/templates 目录下找到它们。

 $ ls /usr/share/lxc/templates 

一个 LXC 模板实质上就是一个脚本,用于创建指定环境下的容器。当你创建 LXC 容器时,你需要用到它们。

比如你要新建 Ubuntu 容器,使用下面的命令即可:

$ sudo lxc-create -n <container-name> -t ubuntu 

默认情况下,这个命令会创建一个最小的 Ubuntu 环境,版本号与你的宿主机一致,我这边是“活泼的蝾螈”(版本号是13.10),64位。

当然你也可以创建任何你喜欢的版本,只要在命令里面加一个版本参数即可。举个例子,创建 Ubuntu 14.10 的容器:

$ sudo lxc-create -n <container-name> -t ubuntu -- --release utopic 

这个命令就会下载安装指定环境下的软件包,创建新容器。整个过程需要几分钟时间,与容器的类型有关,所以,你可能需要耐心等待。

下载安装完所有软件包后,LXC 容器镜像就创建完成了,你可以看到默认的登录界面。容器被放到 /var/lib/lxc/<容器名> 这个目录下,容器的根文件系统放在 /var/lib/lxc/<容器名>/rootfs 目录下。

创建过程中下载的软件包保存在 /var/cache/lxc 目录下面,当你想另外建一个一样的容器时,可以省去很多下载时间。

用下面的命令看看主机上所有的 LXC 容器:

$ sudo lxc-ls --fancy 

NAME  STATE    IPV4  IPV6  AUTOSTART  
------------------------------------
test-lxc   STOPPED  -     -     NO         

使用下面的命令启动容器。参数“-d”将容器作为后台进程打开。如果没有指定这个参数,你可以在控制台界面上直接把容器的运行程序关闭(LCTT译注:Ctrl+C组合键)。

$ sudo lxc-start -n <container-name> -d 

打开容器后,看看状态:

$ sudo lxc-ls --fancy 

NAME  STATE    IPV4       IPV6  AUTOSTART  
-----------------------------------------
lxc   RUNNING  10.0.3.55  -     NO         

容器状态是“运行中”,容器 IP 是10.0.3.55。

你也可以看到容器的网络接口(比如我这里是 vethJ06SFL)自动与 LXC 内部网桥(lxcbr0)连上了:

$ brctl show lxcbr0 

管理 LXC 容器

我们已经学习了怎么创建和启动 LXC 容器,现在来看看怎么玩一个正在运行着的容器。

第一步:打开容器控制台:

$ sudo lxc-console -n <container-name> 

使用“Crtl+a q”组合键退出控制台。

停止、删除容器:

$ sudo lxc-stop -n <container-name>
$ sudo lxc-destroy -n <container-name> 

复制容器,用下面的命令:

$ sudo lxc-stop -n <container-name>
$ sudo lxc-clone -o <container-name> -n <new-container-name>

常见问题

这个小节主要介绍你们在使用 LXC 过程中碰到过的问题。

  1. 创建 LXC 容器时遇到下面的错误:

$ sudo lxc-create -n test-lxc -t ubuntu


lxc-create: symbol lookup error: /usr/lib/x86_64-linux-gnu/liblxc.so.1: undefined symbol: cgmanager_get_pid_cgroup_abs_sync

错误的原因是你运行了最新的 LXC,但是它所依赖的 libcgmanager 版本较老,两者不兼容。升级下 libcmanager 即可解决问题:

$ sudo apt-get install libcgmanager0 

via: http://xmodulo.com/lxc-containers-ubuntu.html

作者:Dan Nanni 译者:bazz2 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出