标签 容器 下的文章

这是 LXD 2.0 系列介绍文章的第七篇。

  1. LXD 入门
  2. 安装与配置
  3. 你的第一个 LXD 容器
  4. 资源控制
  5. 镜像管理
  6. 远程主机及容器迁移
  7. LXD 中的 Docker
  8. LXD 中的 LXD
  9. 实时迁移
  10. LXD 和 Juju
  11. LXD 和 OpenStack
  12. 调试,及给 LXD 做贡献

为什么在 LXD 中运行 Docker

正如我在系列的第一篇中简要介绍的,LXD 的重点是系统容器,也就是我们在容器中运行一个完全未经修改的 Linux 发行版。LXD 的所有意图和目的并不在乎容器中的负载是什么。它只是设置容器命名空间和安全策略,然后运行 /sbin/init 来生成容器,接着等待容器停止。

应用程序容器,例如由 Docker 或 Rkt 所实现的应用程序容器是非常不同的,因为它们用于分发应用程序,通常在它们内部运行单个主进程,并且比 LXD 容器生命期更短暂。

这两种容器类型不是相互排斥的,我们的确看到使用 Docker 容器来分发应用程序的价值。这就是为什么我们在过去一年中努力工作以便让 LXD 中运行 Docker 成为可能。

这意味着,使用 Ubuntu 16.04 和 LXD 2.0,您可以为用户创建容器,然后可以像正常的 Ubuntu 系统一样连接到这些容器,然后运行 Docker 来安装他们想要的服务和应用程序。

要求

要让它正常工作要做很多事情,Ubuntu 16.04 上已经包含了这些:

  • 支持 CGroup 命名空间的内核(4.4 Ubuntu 或 4.6 主线内核)
  • 使用 LXC 2.0 和 LXCFS 2.0 的 LXD 2.0
  • 一个自定义版本的 Docker(或一个用我们提交的所有补丁构建的)
  • Docker 镜像,其受限于用户命名空间限制,或者使父 LXD 容器成为特权容器(security.privileged = true

运行一个基础的 Docker 载荷

说完这些,让我们开始运行 Docker 容器!

首先你可以用下面的命令得到一个 Ubuntu 16.04 的容器:

lxc launch ubuntu-daily:16.04 docker -p default -p docker

-p default -p docker 表示 LXD 将 defaultdocker 配置文件应用于容器。default 配置文件包含基本网络配置,而 docker 配置文件告诉 LXD 加载几个必需的内核模块并为容器设置一些挂载。 docker 配置文件还支持容器嵌套。

现在让我们确保容器是最新的并安装 docker:

lxc exec docker -- apt update
lxc exec docker -- apt dist-upgrade -y
lxc exec docker -- apt install docker.io -y

就是这样!你已经安装并运行了一个 Docker 容器。

现在让我们用两个 Docker 容器开启一个基础的 web 服务:

stgraber@dakara:~$ lxc exec docker -- docker run --detach --name app carinamarina/hello-world-app
Unable to find image 'carinamarina/hello-world-app:latest' locally
latest: Pulling from carinamarina/hello-world-app
efd26ecc9548: Pull complete 
a3ed95caeb02: Pull complete 
d1784d73276e: Pull complete 
72e581645fc3: Pull complete 
9709ddcc4d24: Pull complete 
2d600f0ec235: Pull complete 
c4cf94f61cbd: Pull complete 
c40f2ab60404: Pull complete 
e87185df6de7: Pull complete 
62a11c66eb65: Pull complete 
4c5eea9f676d: Pull complete 
498df6a0d074: Pull complete 
Digest: sha256:6a159db50cb9c0fbe127fb038ed5a33bb5a443fcdd925ec74bf578142718f516
Status: Downloaded newer image for carinamarina/hello-world-app:latest
c8318f0401fb1e119e6c5bb23d1e706e8ca080f8e44b42613856ccd0bf8bfb0d

stgraber@dakara:~$ lxc exec docker -- docker run --detach --name web --link app:helloapp -p 80:5000 carinamarina/hello-world-web
Unable to find image 'carinamarina/hello-world-web:latest' locally
latest: Pulling from carinamarina/hello-world-web
efd26ecc9548: Already exists 
a3ed95caeb02: Already exists 
d1784d73276e: Already exists 
72e581645fc3: Already exists 
9709ddcc4d24: Already exists 
2d600f0ec235: Already exists 
c4cf94f61cbd: Already exists 
c40f2ab60404: Already exists 
e87185df6de7: Already exists 
f2d249ff479b: Pull complete 
97cb83fe7a9a: Pull complete 
d7ce7c58a919: Pull complete 
Digest: sha256:c31cf04b1ab6a0dac40d0c5e3e64864f4f2e0527a8ba602971dab5a977a74f20
Status: Downloaded newer image for carinamarina/hello-world-web:latest
d7b8963401482337329faf487d5274465536eebe76f5b33c89622b92477a670f

现在这两个 Docker 容器已经运行了,我们可以得到 LXD 容器的 IP 地址,并且访问它的服务了!

stgraber@dakara:~$ lxc list
+--------+---------+----------------------+----------------------------------------------+------------+-----------+
|  NAME  |  STATE  |         IPV4         |                      IPV6                    |    TYPE    | SNAPSHOTS |
+--------+---------+----------------------+----------------------------------------------+------------+-----------+
| docker | RUNNING | 172.17.0.1 (docker0) | 2001:470:b368:4242:216:3eff:fe55:45f4 (eth0) | PERSISTENT | 0         |
|        |         | 10.178.150.73 (eth0) |                                              |            |           |
+--------+---------+----------------------+----------------------------------------------+------------+-----------+

stgraber@dakara:~$ curl http://10.178.150.73
The linked container said... "Hello World!"

总结

就是这样了!在 LXD 容器中运行 Docker 容器真的很简单。

现在正如我前面提到的,并不是所有的 Docker 镜像都会像我的示例一样,这通常是因为 LXD 带来了额外的限制,特别是用户命名空间。

在这种模式下只有 Docker 的 overlayfs 存储驱动可以工作。该存储驱动有一组自己的限制,这进一步限制了在该环境中可以有多少镜像工作。

如果您的负载无法正常工作,并且您信任该 LXD 容器中的用户,你可以试下:

lxc config set docker security.privileged true
lxc restart docker

这将取消激活用户命名空间,并以特权模式运行容器。

但是请注意,在这种模式下,容器内的 root 与主机上的 root 是相同的 uid。现在有许多已知的方法让用户脱离容器,并获得主机上的 root 权限,所以你应该只有在信任你的 LXD 容器中的用户可以具有主机上的 root 权限才这样做。

额外信息

LXD 的主站在: https://linuxcontainers.org/lxd

LXD 的 GitHub 仓库: https://github.com/lxc/lxd

LXD 的邮件列表: https://lists.linuxcontainers.org

LXD 的 IRC 频道: #lxcontainers on irc.freenode.net


作者简介:我是 Stéphane Graber。我是 LXC 和 LXD 项目的领导者,目前在加拿大魁北克蒙特利尔的家所在的Canonical 有限公司担任 LXD 的技术主管。


via: https://www.stgraber.org/2016/04/13/lxd-2-0-docker-in-lxd-712/

作者:Stéphane Graber 译者:geekpi 校对:wxy

本文由 LCTT 组织翻译,Linux中国 荣誉推出

这是一篇摘录,取自于 Karl Matthias 和 Sean P. Kane 撰写的 Docker 即学即用。其中或许包含一些引用到本文中没有的内容,因为那些是整本书中的一部分。

2013 年 3 月 15 日,在加利福尼亚州圣克拉拉召开的 Python 开发者大会上,dotCloud 的创始人兼首席执行官 Solomon Hvkes 在一场仅五分钟的微型演讲中,首次提出了 Docker 这一概念。当时,仅约 40 人(除 dotCloud 内部人员)获得了使用 Docker 的机会。

这在之后的几周内,有关 Docker 的新闻铺天盖地。随后这个项目很快在 Github 上开源,任何人都可以下载它并为其做出贡献。在之后的几个月中,越来越多的业界人士开始听说 Docker 以及它是如何彻底地改变了软件的开发、交付和运行的方式。一年之内,Docker 的名字几乎无人不知无人不晓,但还是有很多人不太明白 Docker 究竟是什么,人们为何如此兴奋。

Docker 是一个工具,它致力于为任何应用程序创建分发版本而简化封装流程,将其部署到各种规模的环境中,并将敏捷软件组织的工作流程和响应流水化。

Docker 带来的希望

虽然表面上被视为一个虚拟化平台,但 Docker 远远不止如此。Docker 涉及的领域横跨了业界多个方面,包括 KVM、 Xen、 OpenStack、 Mesos、 Capistrano、 Fabric、 Ansible、 Chef、 Puppet、 SaltStack 等技术。或许你已经发现了,在 Docker 的竞争产品列表中有一些很值得关注。例如,大多数工程师都不会认为,虚拟化产品和配置管理工具是竞争关系,但 Docker 和这两种技术都有点关系。前面列举的一些技术常常因其提高了工作效率而获得称赞,这就导致了大量的探讨。而现在 Docker 正是这些过去十年间最广泛使用的技术之一。

如果你要拿 Docker 分别与这些领域的卫冕冠军按照功能逐项比较,那么 Docker 看上去可能只是个一般的竞争对手。Docker 在某些领域表现的更好,但它带来的是一个跨越广泛的解决工作流程中众多挑战的功能集合。通过将类似 Capistrano 和 Fabric 这样的易用的应用部署工具和易于管理的虚拟系统结合起来,提供钩子使工作流自动化、编排易于实施,Docker 提供了一套非常强大的功能集。

大量的新技术来来去去,因此对这些新事物保持一定的怀疑总是好的。如果不深入研究,人们很容易误以为 Docker 只是另一种为开发者和运营团队解决一些具体问题的技术。如果把 Docker 单独看作一种虚拟化技术或者部署技术,它看起来并不引人注目。不过 Docker 可比表面上看起来的强大得多。

即使在小型团队中,团队内部的沟通和相处也往往是困难的。然而在我们生活的这个世界里,团队内部对于细节的沟通是迈向成功越来越不可或缺的因素。而一个能够降低沟通复杂性,协助开发更为强健软件的工具,无疑是一个巨大的成功。这正是 Docker 值得我们深入了解的原因。当然 Docker 也不是什么灵丹妙药,它的正确使用还需深思熟虑,不过 Docker 确实能够解决一些组织层面的现实问题,还能够帮助公司更好更快地发布软件。使用精心设计的 Docker 工作流程能够让技术团队更加和谐,为组织创造实实在在的收益。

那么,最让公司感到头疼的问题是什么呢?现如今,很难按照预期的速度发布软件,而随着公司从只有一两个开发人员成长到拥有若干开发团队的时候,发布新版本时的沟通负担将越来越重,难以管理。开发者不得不去了解软件所处环境的复杂性,生产运营团队也需要不断地理解所发布软件的内部细节。这些通常都是不错的工作技能,因为它们有利于更好地从整体上理解发布环境,从而促进软件的鲁棒性设计。但是随着组织成长的加速,这些技能的拓展很困难。

充分了解所用的环境细节往往需要团队之间大量的沟通,而这并不能直接为团队创造值。例如,为了发布版本 1.2.1、开发人员要求运维团队升级特定的库,这个过程就降低了开发效率,也没有为公司创造价值。如果开发人员能够直接升级他们所使的库,然后编写代码,测试新版本,最后发布软件,那么整个交付过程所用的时间将会明显缩短。如果运维人员无需与多个应用开发团队相协调,就能够在宿主系统上升级软件,那么效率将大大提高。Docker 有助于在软件层面建立一层隔离,从而减轻团队的沟通负担。

除了有助于解决沟通问题,在某种程度上 Docker 的软件架构还鼓励开发出更多健壮的应用程序。这种架构哲学的核心是一次性的小型容器。在新版本部署的时候,会将旧版本应用的整个运行环境全部丢弃。在应用所处的环境中,任何东西的存在时间都不会超过应用程序本身。这是一个简单却影响深远的想法。这就意味着,应用程序不会意外地依赖于之前版本的遗留产物;对应用的短暂调试和修改也不会存在于未来的版本中;应用程序具有高度的可移植性,因为应用的所有状态要么直接包含于部署物中,且不可修改,要么存储于数据库、缓存或文件服务器等外部依赖中。

因此,应用程序不仅具有更好的可扩展性,而且更加可靠。存储应用的容器实例数量的增减,对于前端网站的影响很小。事实证明,这种架构对于非 Docker 化的应用程序已然成功,但是 Docker 自身包含了这种架构方式,使得 Docker 化的应用程序始终遵循这些最佳实践,这也是一件好事。

Docker 工作流程的好处

我们很难把 Docker 的好处一一举例。如果用得好,Docker 能在多个方面为组织,团队,开发者和运营工程师带来帮助。从宿主系统的角度看,所有应用程序的本质是一样的,因此这就决定了 Docker 让架构的选择更加简单。这也让工具的编写和应用程序之间的分享变得更加容易。这世上没有什么只有好处却没有挑战的东西,但是 Docker 似乎就是一个例外。以下是一些我们使用 Docker 能够得到的好处:

使用开发人员已经掌握的技能打包软件

许多公司为了管理各种工具来为它们支持的平台生成软件包,不得不提供一些软件发布和构建工程师的岗位。像 rpm、mock、 dpkg 和 pbuilder 等工具使用起来并不容易,每一种工具都需要单独学习。而 Docker 则把你所有需要的东西全部打包起来,定义为一个文件。

使用标准化的镜像格式打包应用软件及其所需的文件系统

过去,不仅需要打包应用程序,还需要包含一些依赖库和守护进程等。然而,我们永远不能百分之百地保证,软件运行的环境是完全一致的。这就使得软件的打包很难掌握,许多公司也不能可靠地完成这项工作。常有类似的事发生,使用 Scientific Linux 的用户试图部署一个来自社区的、仅在 Red Hat Linux 上经过测试的软件包,希望这个软件包足够接近他们的需求。如果使用 Dokcer、只需将应用程序和其所依赖的每个文件一起部署即可。Docker 的分层镜像使得这个过程更加高效,确保应用程序运行在预期的环境中。

测试打包好的构建产物并将其部署到运行任意系统的生产环境

当开发者将更改提交到版本控制系统的时候,可以构建一个新的 Docker 镜像,然后通过测试,部署到生产环境,整个过程中无需任何的重新编译和重新打包。

将应用软件从硬件中抽象出来,无需牺牲资源

传统的企业级虚拟化解决方案,例如 VMware,以消耗资源为代价在物理硬件和运行其上的应用软件之间建立抽象层。虚拟机管理程序和每一个虚拟机中运行的内核都要占用一定的硬件系统资源,而这部分资源将不能够被宿主系统的应用程序使用。而容器仅仅是一个能够与 Linux 内核直接通信的进程,因此它可以使用更多的资源,直到系统资源耗尽或者配额达到上限为止。

Docker 出现之前,Linux 容器技术已经存在了很多年,Docker 使用的技术也不是全新的。但是这个独一无二的集强大架构和工作流程于一身的 Docker 要比各个技术加在一起还要强大的多。Docker 终于让已经存在了十余年的 Linux 容器走进了普通技术人员的生活中。Docker 让容器更加轻易地融入到公司现有的工作流程中。以上讨论到的问题已被很多人认可,以至于 Docker 项目的快速发展超出了所有人的合理预期。

Docker 发布的第一年,许多刚接触的新人惊讶地发现,尽管 Docker 还不能在生产环境中使用,但是来自 Docker 开源社区源源不断的提交,飞速推动着这个项目向前发展。随着时间的推移,这一速度似乎越来越快。现在 Docker 进入了 1.x 发布周期,稳定性好了,可以在生产环境中使用。因此,许多公司使用 Docker 来解决它们在应用程序交付过程中面对的棘手问题。

Docker 不是什么

Docker 可以解决很多问题,这些问题是其他类型的传统工具专门解决的。那么 Docker 在功能上的广度就意味着它在特定的功能上缺乏深度。例如,一些组织认为,使用 Docker 之后可以完全摈弃配置管理工具,但 Docker 真正强大之处在于,它虽然能够取代某些传统的工具,但通常与它们是兼容的,甚至与它们结合使用还能增强自身的功能。下面将列举一些 Docker 还未能完全取代的工具,如果与它们结合起来使用,往往能取得更好的效果。

企业级虚拟化平台(VMware、KVM 等)

容器并不是传统意义上的虚拟机。虚拟机包含完整的操作系统,运行在宿主操作系统之上。虚拟化平台最大的优点是,一台宿主机上可以使用虚拟机运行多个完全不同的操作系统。而容器是和主机共用同一个内核,这就意味着容器使用更少的系统资源,但必须基于同一个底层操作系统(如 Linux)。

云平台(Openstack、CloudStack 等)

与企业级虚拟化平台一样,容器和云平台的工作流程表面上有大量的相似之处。从传统意义上看,二者都可以按需横向扩展。但是,Docker 并不是云平台,它只能在预先安装 Docker 的宿主机中部署,运行和管理容器,并能创建新的宿主系统(实例),对象存储,数据块存储以及其他与云平台相关的资源。

配置管理工具(Puppet、Chef 等)

尽管 Docker 能够显著提高一个组织管理应用程序及其依赖的能力,但不能完全取代传统的配置管理工具。Dockerfile 文件用于定义一个容器构建时内容,但不能持续管理容器运行时的状态和 Docker 的宿主系统。

部署框架(Capistrano、Fabric等)

Docker 通过创建自成一体的容器镜像,简化了应用程序在所有环境上的部署过程。这些用于部署的容器镜像封装了应用程序的全部依赖。然而 Docker 本身无法执行复杂的自动化部署任务。我们通常使用其他工具一起实现较大的工作流程自动化。

工作负载管理工具(Mesos、Fleet等)

Docker 服务器没有集群的概念。我们必须使用其他的业务流程工具(如 Docker 自己开发的 Swarm)智能地协调多个 Docker 主机的任务,跟踪所有主机的状态及其资源使用情况,确保运行着足够的容器。

虚拟化开发环境(Vagrant 等)

对开发者来说,Vagrant 是一个虚拟机管理工具,经常用来模拟与实际生产环境尽量一致的服务器软件栈。此外,Vagrant 可以很容易地让 Mac OS X 和基于 Windows 的工作站运行 Linux 软件。由于 Docker 服务器只能运行在 Linux 上,于是它提供了一个名为 Boot2Docker 的工具允许开发人员在不同的平台上快速运行基于 Linux 的 Docker 容器。Boot2Docker 足以满足很多标准的 Docker 工作流程,但仍然无法支持 Docker Machine 和 Vagrant 的所有功能。

如果没有强有力的参考标准,很难理解 Docker 的作用。下一章我们将概览 Docker,它是什么,它的目标使用场景,以及它的优势。


作者简介:

Karl Matthias

Karl Matthias 曾在创业公司和世界 500 强企业中担任过开发人员,系统管理员和网络工程师。在德国和英国的初创公司工作了若干年后,他和家人回到了美国俄勒冈州波特兰,在 New Relic 公司担任首席网站可靠性工程师。业余时间,他会和他的两个女儿玩,用他那老式相机摄摄影,或者骑骑自行车。

Sean Kane

Sean Kane 目前在 New Relic 公司的共享基础设施团队中担任首席网站可靠性工程师。他在生产运维领域有很长的职业生涯,在不同的行业中工作过,有许多不同的头衔。他在各类聚会和技术论坛做过演讲,涉及过疲劳预警和硬件自动化等话题。他的青年阶段大部分在海外度过,毕业于林林兄弟及巴纳姆和贝利小丑学院,在美国中央情报局做过两次实习等等,他一直在探索生活的真谛。


via: https://www.oreilly.com/learning/what-is-docker

作者:Karl Matthias,Sean Kane 译者:Cathon 校对:jasminepeng

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

Linux 容器正在改变 IT 从业者的工作方式。相比于庞大、沉重的虚拟机,一些组织发现把他们的应用部署在容器中更有效,可以提供更快的速度,更加密集,提升他们操作的敏捷性。

从安全的角度看,容器带来了一些优势,但是也面临着它们自己的一些安全挑战。和传统的基础设施一样,为了避免安全缺陷,确保运行在一个容器内的组件和系统库的定期更新是至关重要的。但是你如何知道什么东西运行在你的容器内?为了帮助你应对这些的安全挑战,一个名为 Anchore的初创公司正在开发一个同名的开源项目,它用来帮助展示 Linux 容器中的内容。

为了了解更多关于 Anchore,我找到了 Anchore 的市场和产品的发言人 Andrew Cathrow,来了解更多关于这个开源项目背后的公司。

简而言之 Anchore 是什么? 它如何工作?

Anchore 的目标是提供一套工具,允许开发人员、运营团队、安全团队在容器的整个开发周期中保持对“监管链(Chain of Custody)”的全程可见,并提供生产部署所需的可见性、可预测性和控制性。Anchore 的引擎通过插件可以进行分析(通过提取镜像数据和元数据)、查询(允许对容器进行分析)、以及策略评估(这里的策略指可以被指定的管理的图像)。

虽然市场上有很多扫描工具,但是大部分不开源。我们认为安全合规的产品应该是开源的,否则你怎么才能信任他们。

Anchore 除了开源以外,还有两大优势,使它可以区别于市场中的商业产品。

首先,我们看的不止是操作系统的镜像。如今的扫描工具专注于操作系统的软件包,比如“你的 RPM 或 DEB 包中有CVE(安全漏洞)么?”这虽然是很重要的,你不希望你的镜像中有不安全的包,但是操作系统包只是镜像的基础。其他的层次都需要进行验证,包括配置文件、语言模块、中间件等等。你可以用的全是最新的软件包,但是可能一个配置文件配置出现错误,不安全就出现在里面。第二个不同就是允许用户添加自己的数据、查询或策略来扩展这个引擎。

什么推动了容器的校验和分析工具的需求出现?这个工具可以解决运营面临的什么问题呢?

企业使用 Docker 首要关注的就是安全,特别是他们正在部署的容器的分配和合规性。在生产环境中,从公共镜像库拉取一个镜像,运行它,并在几秒钟部署,是非常简单的,甚至不知道下面可能发生什么。终端用户在部署应用时,必须信任他们所部署的是安全、高效和易于维护的。

容器是不透明的,它们是一个包含应用程序的可部署的“黑盒”。虽然非常容易把这些镜像看作“打包的应用程序”,但是它们包括了系统的镜像和多达数百个包和成千上万个文件。如同所有在物理服务器、虚拟机或者云上的操作系统一样,镜像也需要维护。镜像或许包含了未补丁的安全缺陷、带有 bug 和错误配置的过期软件。

要对您的容器部署有信心,你需要知道底层是什么,并基于容器镜像的内容来做出决定。

如今容器的创新基本上都是开源的,你认为是为什么呢?是什么促使了它们开源呢?

在过去的 20 年中,各个组织已经经历了开源带来的优势,节省成本,减少锁定,提高了安全性和更快的创新。容器,特别是 Docker,都是非常好的例子。Docker 公司的团队不能在专有系统上创建一个新的软件部署模式,他们不能要求在修改专有系统的代码,而是与行业领导者比如谷歌、IBM、英特尔、红帽合作,朝着一个共同的目标。开源和 Linux 总是开启创新和激励产业困境。在过去,实现一个大的想法需要一个大的团队和很多资源。在开源世界,一个有着很大的创意的小公司可以工作在一个更大的社区中,通过知识共享的力量来协作,提供真正的企业创新。

为了深入的说明开源的使用,Anchroe 团队最近刚从多伦多的 LinuxCon 回来,在哪里,令人难以相信的是,微软作为钻石级的赞助商,展示了他们用在 Linux 上的产品投入的增长。Linus Toravlds 曾说过,“如果微软为 Linux 开发应用就意味着我赢了”。我要把这句话改为“开源赢了”。

容器领域的通用标准的创建还需要时间,在容器的几乎所有部分,仍有许多挑战。在这个领域,创业公司有哪些挑战?

这里有个很重要的点,就是没有开放的标准和开源,我们不可能看到快速推动容器的采用和改变行业格局的创新。开放容器倡议(OCI)由 Linux 和容器行业的行业领导者组成,正在为运行环境和镜像格式创造标准,这将使我们能够看到更多的创新。Anchore 很自豪能成为 OCI 的新成员,我们期待帮助形成标准。

你将如何围绕 Anchor 项目建立一个开源社区?

Anchore 团队来自 Ansible、Eucalyptus Systems 和 Red Hat 的领导团队,在开源社区中拥有丰富的工作经验。从一开始,Anchore 就准备创建一个强大的开源社区,我们正在应用我们在开源世界中学到的经验和教训。第一课,当然,发布要尽早尽快。我们在 6 月开源我们的检测和分析引擎,远远早于我们的商用产品,以便了确保开源项目能够独立运行,使更多的直接用户能够使用它,而无需购买 Anchore 的商用产品。通过支持、服务和增强型的数据源,有很多机会给商用产品创造更多价值,但是如果开源引擎本身没有用,我们将看不到活跃的社区。

我们将 Anchore 模块化,允许添加分析、报告和策略插件,而不需要更改核心的引擎。我们希望保证任何人都可以创建插件,所以我们选择了 Python 作为项目的基本语言,因为 Python 被开发者和系统管理员广泛应用。但是,即使你不熟悉 Python,你仍然可以使用任何你喜欢的语言或者脚本环境创建插件。如果你可以创建一个 Bash 脚本,那么你也可以创建一个 Anchore 插件。我们的目标是最大化的吸引社区的参与。虽然我们鼓励用户将贡献回馈给社区,但是我们也为这个项目构建并进行了授权,来确保可以独立创建和维护私有的插件和模块。

容器的用途不止是在服务器上更大密度的部署应用程序或者技术层面更快的速度,而且还有不同工具的组合,这些工具提供了一种不同的方式来拉近开发者和操作者共同工作。作为在这个领域工作的公司,你们希望提供一个什么样的消息来让开发者和运营产生共鸣?

随着越来越多的运行环境、编排、监控和集成产品,容器的生态系统正在快速发展。所以,我们的架构中的第一个考虑因素不是限定 Anchore 的部署和使用。我们需要确保我们可以适应任何 CI/CD 工作流,无论是私有部署还是云端部署。一个经常问到我们的问题是,Anchore 是否将提供一个包含了镜像扫描和分析的容器仓库。虽然这将大大简化我们的工作,但是这会迫使用户进入特定的部署架构,并限制了用户部署他们自己最好的组件的能力。我们已经确保 Anchore 可以和所有领先的仓库、运行环境平台、 CI/CD 平台和编排工具配合使用。

一些开发者掌握了运营技能,并转换为 DevOps 角色,我们看到系统管理员/运营团队也在更多的了解开发,转换成 DevOps 角色。我们也看到了具有混合能力的团队。我们设计了可供开发运营和安全团队使用的 Anchore ,以便他们共同定义规则和策略来评估开发周期中的任何一个环节。另外一个例子是插件/模块的架构,使任何人都可以在他们喜欢的环境中轻松创建一个模块 —— 无论是以 Python、Go、Perl、C 甚至是一个 Bash 脚本。


via: https://opensource.com/business/16/10/interview-andy-cathrow-anchore

作者:Jason Baker 译者:Bestony 校对:wxy

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

这是 LXD 2.0 系列介绍文章的第五篇。

  1. LXD 入门
  2. 安装与配置
  3. 你的第一个 LXD 容器
  4. 资源控制
  5. 镜像管理
  6. 远程主机及容器迁移
  7. LXD 中的 Docker
  8. LXD 中的 LXD
  9. 实时迁移
  10. LXD 和 Juju
  11. LXD 和 OpenStack
  12. 调试,及给 LXD 做贡献

因为 lxd 容器管理有很多命令,因此这篇文章会很长。 如果你想要快速地浏览这些相同的命令,你可以尝试下我们的在线演示

容器镜像

如果你以前使用过 LXC,你可能还记得那些 LXC “模板”,基本上都是导出一个容器文件系统以及一点配置的 shell 脚本。

大多数模板是通过在本机上执行一个完整的发行版自举来生成该文件系统。这可能需要相当长的时间,并且无法在所有的发行版上可用,另外可能需要大量的网络带宽。

回到 LXC 1.0,我写了一个“下载”模板,它允许用户下载预先打包的容器镜像,用模板脚本在中央服务器上生成,接着高度压缩、签名并通过 https 分发。我们很多用户从旧版的容器生成方式切换到了使用这种新的、更快更可靠的创建容器的方式。

使用 LXD,我们通过全面的基于镜像的工作流程向前迈进了一步。所有容器都是从镜像创建的,我们在 LXD 中具有高级镜像缓存和预加载支持,以使镜像存储保持最新。

与 LXD 镜像交互

在更深入了解镜像格式之前,让我们快速了解下 LXD 可以让你做些什么。

透明地导入镜像

所有的容器都是由镜像创建的。镜像可以来自一台远程服务器并使用它的完整 hash、短 hash 或者别名拉取下来,但是最终每个 LXD 容器都是创建自一个本地镜像。

这有个例子:

lxc launch ubuntu:14.04 c1
lxc launch ubuntu:75182b1241be475a64e68a518ce853e800e9b50397d2f152816c24f038c94d6e c2
lxc launch ubuntu:75182b1241be c3

所有这些引用相同的远程镜像(在写这篇文章时),在第一次运行这些命令其中之一时,远程镜像将作为缓存镜像导入本地 LXD 镜像存储,接着从其创建容器。

下一次运行其中一个命令时,LXD 将只检查镜像是否仍然是最新的(当不是由指纹引用时),如果是,它将创建容器而不下载任何东西。

现在镜像被缓存在本地镜像存储中,你也可以从那里启动它,甚至不检查它是否是最新的:

lxc launch 75182b1241be c4

最后,如果你有个名为“myimage”的本地镜像,你可以:

lxc launch my-image c5

如果你想要改变一些自动缓存或者过期行为,在本系列之前的文章中有一些命令

手动导入镜像

从镜像服务器中复制

如果你想复制远程的某个镜像到你本地镜像存储,但不立即从它创建一个容器,你可以使用lxc image copy命令。它可以让你调整一些镜像标志,比如:

lxc image copy ubuntu:14.04 local:

这只是简单地复制一个远程镜像到本地存储。

如果您想要通过比记住其指纹更容易的方式来记住你引用的镜像副本,则可以在复制时添加别名:

lxc image copy ubuntu:12.04 local: --alias old-ubuntu
lxc launch old-ubuntu c6

如果你想要使用源服务器上设置的别名,你可以要求 LXD 复制下来:

lxc image copy ubuntu:15.10 local: --copy-aliases
lxc launch 15.10 c7

上面的副本都是一次性拷贝,也就是复制远程镜像的当前版本到本地镜像存储中。如果你想要 LXD 保持镜像最新,就像它在缓存中存储的那样,你需要使用 –auto-update 标志:

lxc image copy images:gentoo/current/amd64 local: --alias gentoo --auto-update
导入 tarball

如果某人给你提供了一个单独的 tarball,你可以用下面的命令导入:

lxc image import <tarball>

如果你想在导入时设置一个别名,你可以这么做:

lxc image import <tarball> --alias random-image

现在如果你被给了两个 tarball,要识别哪个是含有 LXD 元数据的。通常可以通过 tarball 的名称来识别,如果不行就选择最小的那个,元数据 tarball 包是很小的。 然后将它们一起导入:

lxc image import <metadata tarball> <rootfs tarball>
从 URL 中导入

lxc image import 也可以与指定的 URL 一起使用。如果你的一台 https Web 服务器的某个路径中有 LXD-Image-URLLXD-Image-Hash 的标头设置,那么 LXD 就会把这个镜像拉到镜像存储中。

可以参照例子这么做:

lxc image import https://dl.stgraber.org/lxd --alias busybox-amd64

当拉取镜像时,LXD 还会设置一些标头,远程服务器可以检查它们以返回适当的镜像。 它们是 LXD-Server-ArchitecturesLXD-Server-Version

这相当于一个简陋的镜像服务器。 它可以通过任何静态 Web 服务器提供一中用户友好的导入镜像的方式。

管理本地镜像存储

现在我们本地已经有一些镜像了,让我们瞧瞧可以做些什么。我们已经介绍了最主要的部分,可以从它们来创建容器,但是你还可以在本地镜像存储上做更多。

列出镜像

要列出所有的镜像,运行 lxc image list

stgraber@dakara:~$ lxc image list
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|     ALIAS     | FINGERPRINT  | PUBLIC |                     DESCRIPTION                      |  ARCH  |   SIZE   |         UPLOAD DATE          |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| alpine-32     | 6d9c131efab3 | yes    | Alpine edge (i386) (20160329_23:52)                  | i686   | 2.50MB   | Mar 30, 2016 at 4:36am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| busybox-amd64 | 74186c79ca2f | no     | Busybox x86_64                                       | x86_64 | 0.79MB   | Mar 30, 2016 at 4:33am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| gentoo        | 1a134c5951e0 | no     | Gentoo current (amd64) (20160329_14:12)              | x86_64 | 232.50MB | Mar 30, 2016 at 4:34am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| my-image      | c9b6e738fae7 | no     | Scientific Linux 6 x86_64 (default) (20160215_02:36) | x86_64 | 625.34MB | Mar 2, 2016 at 4:56am (UTC)  |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| old-ubuntu    | 4d558b08f22f | no     | ubuntu 12.04 LTS amd64 (release) (20160315)          | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
| w (11 more)   | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315)              | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+
|               | 75182b1241be | no     | ubuntu 14.04 LTS amd64 (release) (20160314)          | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
+---------------+--------------+--------+------------------------------------------------------+--------+----------+------------------------------+

你可以通过别名或者指纹来过滤:

stgraber@dakara:~$ lxc image list amd64
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
|     ALIAS     | FINGERPRINT  | PUBLIC |               DESCRIPTION               |  ARCH  |   SIZE   |          UPLOAD DATE         |
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
| busybox-amd64 | 74186c79ca2f | no     | Busybox x86_64                          | x86_64 | 0.79MB   | Mar 30, 2016 at 4:33am (UTC) |
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+
| w (11 more)   | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315) | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
+---------------+--------------+--------+-----------------------------------------+--------+----------+------------------------------+

或者指定一个镜像属性中的键值对来过滤:

stgraber@dakara:~$ lxc image list os=ubuntu
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|    ALIAS    | FINGERPRINT  | PUBLIC |                  DESCRIPTION                |  ARCH  |   SIZE   |          UPLOAD DATE         |
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
| old-ubuntu  | 4d558b08f22f | no     | ubuntu 12.04 LTS amd64 (release) (20160315) | x86_64 | 155.09MB | Mar 30, 2016 at 4:30am (UTC) |
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
| w (11 more) | d3703a994910 | no     | ubuntu 15.10 amd64 (release) (20160315)     | x86_64 | 153.35MB | Mar 30, 2016 at 4:31am (UTC) |
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+
|             | 75182b1241be | no     | ubuntu 14.04 LTS amd64 (release) (20160314) | x86_64 | 118.17MB | Mar 30, 2016 at 4:27am (UTC) |
+-------------+--------------+--------+---------------------------------------------+--------+----------+------------------------------+

要了解镜像的所有信息,你可以使用lxc image info

stgraber@castiana:~$ lxc image info ubuntu
Fingerprint: e8a33ec326ae7dd02331bd72f5d22181ba25401480b8e733c247da5950a7d084
Size: 139.43MB
Architecture: i686
Public: no
Timestamps:
 Created: 2016/03/15 00:00 UTC
 Uploaded: 2016/03/16 05:50 UTC
 Expires: 2017/04/26 00:00 UTC
Properties:
 version: 12.04
 aliases: 12.04,p,precise
 architecture: i386
 description: ubuntu 12.04 LTS i386 (release) (20160315)
 label: release
 os: ubuntu
 release: precise
 serial: 20160315
Aliases:
 - ubuntu
Auto update: enabled
Source:
 Server: https://cloud-images.ubuntu.com/releases
 Protocol: simplestreams
 Alias: precise/i386
编辑镜像

编辑镜像的属性和标志的简单方法是使用:

lxc image edit <alias or fingerprint>

这会打开默认文本编辑器,内容像这样:

autoupdate: true
properties:
 aliases: 14.04,default,lts,t,trusty
 architecture: amd64
 description: ubuntu 14.04 LTS amd64 (release) (20160314)
 label: release
 os: ubuntu
 release: trusty
 serial: "20160314"
 version: "14.04"
public: false

你可以修改任何属性,打开或者关闭自动更新,或者标记一个镜像是公共的(后面详述)。

删除镜像

删除镜像只需要运行:

lxc image delete <alias or fingerprint>

注意你不必移除缓存对象,它们会在过期后被 LXD 自动移除(默认上,在最后一次使用的 10 天后)。

导出镜像

如果你想得到目前镜像的 tarball,你可以使用lxc image export,像这样:

stgraber@dakara:~$ lxc image export old-ubuntu .
Output is in .
stgraber@dakara:~$ ls -lh *.tar.xz
-rw------- 1 stgraber domain admins 656 Mar 30 00:55 meta-ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz
-rw------- 1 stgraber domain admins 156M Mar 30 00:55 ubuntu-12.04-server-cloudimg-amd64-lxd.tar.xz

镜像格式

LXD 现在支持两种镜像布局,unified 或者 split。这两者都是有效的 LXD 格式,虽然后者在与其他容器或虚拟机一起运行时更容易重用其文件系统。

LXD 专注于系统容器,不支持任何应用程序容器的“标准”镜像格式,我们也不打算这么做。

我们的镜像很简单,它们是由容器文件系统,以及包含了镜像制作时间、到期时间、什么架构,以及可选的一堆文件模板的元数据文件组成。

有关镜像格式的最新详细信息,请参阅此文档。

unified 镜像(一个 tarball)

unified 镜像格式是 LXD 在生成镜像时使用的格式。它们是一个单独的大型 tarball,包含 rootfs 目录下的容器文件系统,在 tarball 根目录下有 metadata.yaml 文件,任何模板都放到 templates 目录。

tarball 可以用任何方式压缩(或者不压缩)。镜像散列是压缩后的 tarball 的 sha256 。

Split 镜像(两个 tarball)

这种格式最常用于滚动更新镜像并已经有了一个压缩文件系统 tarball 时。

它们由两个不同的 tarball 组成,第一个只包含 LXD 使用的元数据, metadata.yaml 文件在根目录,任何模板都在 templates 目录。

第二个 tarball 只包含直接位于其根目录下的容器文件系统。大多数发行版已经有这样的 tarball,因为它们常用于引导新机器。 此镜像格式允许不经修改就重用。

两个 tarball 都可以压缩(或者不压缩),它们可以使用不同的压缩算法。 镜像散列是元数据的 tarball 和 rootfs 的 tarball 结合的 sha256。

镜像元数据

典型的 metadata.yaml 文件看起来像这样:

architecture: "i686"
creation_date: 1458040200
properties:
 architecture: "i686"
 description: "Ubuntu 12.04 LTS server (20160315)"
 os: "ubuntu"
 release: "precise"
templates:
 /var/lib/cloud/seed/nocloud-net/meta-data:
  when:
   - start
  template: cloud-init-meta.tpl
 /var/lib/cloud/seed/nocloud-net/user-data:
  when:
   - start
  template: cloud-init-user.tpl
  properties:
   default: |
    #cloud-config
    {}
 /var/lib/cloud/seed/nocloud-net/vendor-data:
  when:
   - start
  template: cloud-init-vendor.tpl
  properties:
   default: |
    #cloud-config
    {}
 /etc/init/console.override:
  when:
   - create
  template: upstart-override.tpl
 /etc/init/tty1.override:
  when:
   - create
  template: upstart-override.tpl
 /etc/init/tty2.override:
  when:
   - create
  template: upstart-override.tpl
 /etc/init/tty3.override:
  when:
   - create
  template: upstart-override.tpl
 /etc/init/tty4.override:
  when:
   - create
  template: upstart-override.tpl
属性

两个唯一的必填字段是 creation date(UNIX 纪元时间)和 architecture。 其他都可以保持未设置,镜像就可以正常地导入。

额外的属性主要是帮助用户弄清楚镜像是什么。 例如 description 属性是在 lxc image list 中可见的。 用户可以使用其它属性的键/值对来搜索特定镜像。

相反,这些属性用户可以通过 lxc image edit来编辑,creation datearchitecture 字段是不可变的。

模板

模板机制允许在容器生命周期中的某一点生成或重新生成容器中的一些文件。

我们使用 pongo2 模板引擎来做这些,我们将所有我们知道的容器信息都导出到模板。 这样,你可以使用用户定义的容器属性或常规 LXD 属性来自定义镜像,从而更改某些特定文件的内容。

正如你在上面的例子中看到的,我们使用在 Ubuntu 中使用它们来进行 cloud-init 并关闭一些 init 脚本。

创建你的镜像

LXD 专注于运行完整的 Linux 系统,这意味着我们期望大多数用户只使用干净的发行版镜像,而不是只用自己的镜像。

但是有一些情况下,你有自己的镜像是有必要的。 例如生产服务器上的预配置镜像,或者构建那些我们没有构建的发行版或者架构的镜像。

将容器变成镜像

目前使用 LXD 构造镜像最简单的方法是将容器变成镜像。

可以这么做:

lxc launch ubuntu:14.04 my-container
lxc exec my-container bash
<do whatever change you want>
lxc publish my-container --alias my-new-image

你甚至可以将一个容器过去的快照变成镜像:

lxc publish my-container/some-snapshot --alias some-image

手动构建镜像

构建你自己的镜像也很简单。

  1. 生成容器文件系统。这完全取决于你使用的发行版。对于 Ubuntu 和 Debian,它将用于启动。
  2. 配置容器中该发行版正常工作所需的任何东西(如果需要任何东西)。
  3. 制作该容器文件系统的 tarball,可选择压缩它。
  4. 根据上面描述的内容写一个新的 metadata.yaml 文件。
  5. 创建另一个包含 metadata.yaml 文件的 tarball。
  6. 用下面的命令导入这两个 tarball 作为 LXD 镜像:lxc image import <metadata tarball> <rootfs tarball> --alias some-name

在一切都正常工作前你可能需要经历几次这样的工作,调整这里或那里,可能会添加一些模板和属性。

发布你的镜像

所有 LXD 守护程序都充当镜像服务器。除非另有说明,否则加载到镜像存储中的所有镜像都会被标记为私有,因此只有受信任的客户端可以检索这些镜像,但是如果要创建公共镜像服务器,你需要做的是将一些镜像标记为公开,并确保你的 LXD 守护进程监听网络。

只运行 LXD 公共服务器

最简单的共享镜像的方式是运行一个公共的 LXD 守护进程。

你只要运行:

lxc config set core.https_address "[::]:8443"

远程用户就可以添加你的服务器作为公共服务器:

lxc remote add <some name> <IP or DNS> --public

他们就可以像使用任何默认的镜像服务器一样使用它们。 由于远程服务器添加了 -public 选项,因此不需要身份验证,并且客户端仅限于使用已标记为 public 的镜像。

要将镜像设置成公共的,只需使用 lxc image edit 编辑它们,并将 public 标志设置为 true

使用一台静态 web 服务器

如上所述,lxc image import 支持从静态 https 服务器下载。 基本要求是:

  • 服务器必须支持具有有效证书的 HTTPS、TLS 1.2 和 EC 算法。
  • 当访问 lxc image import 提供的 URL 时,服务器必须返回一个包含 LXD-Image-HashLXD-Image-URL 的 HTTP 标头。

如果你想使它动态化,你可以让你的服务器查找 LXD 在请求镜像时发送的 LXD-Server-ArchitecturesLXD-Server-Version 的 HTTP 标头,这可以让你返回符合该服务器架构的正确镜像。

构建一个简单流服务器

ubuntu:ubuntu-daily: 远端服务器不使用 LXD 协议(images: 使用),而是使用称为简单流(simplestreams)的不同协议。

简单流基本上是一个镜像服务器的描述格式,使用 JSON 来描述产品以及相关产品的文件列表。

它被各种工具,如 OpenStack、Juju、MAAS 等用来查找、下载或者做镜像系统,LXD 将它作为用于镜像检索的原生协议。

虽然这的确不是提供 LXD 镜像的最简单的方法,但是如果你的镜像也被其它一些工具使用,那这也许值得考虑一下。

关于简单流的更多信息可以在这里找到。

总结

我希望这篇关于如何使用 LXD 管理镜像以及构建和发布镜像文章让你有所了解。对于以前的 LXC 而言,可以在一组全球分布式系统上得到完全相同的镜像是一个很大的进步,并且引导了更多可复制性的发展方向。

额外信息

LXD 的主站在: https://linuxcontainers.org/lxd

LXD 的 GitHub 仓库: https://github.com/lxc/lxd

LXD 的邮件列表: https://lists.linuxcontainers.org

LXD 的 IRC 频道: #lxcontainers on irc.freenode.net

如果你不想或者不能在你的机器上安装 LXD ,你可以在 web 上试试在线版的 LXD


作者简介:我是 Stéphane Graber。我是 LXC 和 LXD 项目的领导者,目前在加拿大魁北克蒙特利尔的家所在的Canonical 有限公司担任 LXD 的技术主管。


via: https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/

作者:Stéphane Graber 译者:geekpi 校对:wxy

本文由 LCTT 组织翻译,Linux中国 荣誉推出

原文:https://www.stgraber.org/2016/03/30/lxd-2-0-image-management-512/

某一天,我和我的一个机械工程师朋友聊天的时候。 他最近在做一个给半挂卡车的电子辅助刹车系统,他提到他们公司的办公室里都是 Arduinos。这主要是方便员工可以快速的对新的想法进行实验。他也提到了,Arduinos 其实比自己画电路板更加昂贵。对此,我感到非常震惊,因为我从软件行业得到的印象是 Arduinos 比定制电路板更加便宜。

我常常把 Arduinos树莓派 看做是可以制作非常有趣设备的小型、Cool、特别的组件。我主要从事于软件行业,并且总是觉得运行在 x86 和 x86-64 设备上的 Linux 才算是“常规用途”。而事实是,Arduinos 并不是特殊用途。实际上,它们是很常规的用途。它们相当的小、便宜,而且非常的灵活。这就是为什么它们像野火一样流行起来的原因。它们有全品类的输入输出设备和扩展卡。它们能让创客们快速的构建非常 Cool 的设备。它们甚至可以让公司可以快速地开发产品。

一套 Arduino 的单价比批量生产的电路板高了很多,但是,看不见的时间成本却低了很多。当电路板大规模生产的时候,价格可以控制的很低,但是,之前的研发费用却高了很多。所以,总而言之,答案就是,使用 Arduino 划得来。

Unikernel、Rump 内核和容器主机

Unikernel、Rump 内核和迷你 Linux 发行版,这些操作系统是为了特有用途而构建的。这些特有的操作系统,某种程度上就像定制电路板。它们需要前期的投入,还需要设计,但是,当大规模部署的时候,它可以提供强大的性能。

迷你操作系统,例如:红帽企业版 Atomic 或者 CoreOS 是为了运行容器而构建的。它们很小,快速,易于在启动时配置,并且很适合于运行容器。缺点就是它需要额外的工程量来添加第三方插件,比如监控客户端或者虚拟化的工具。副作用就是载入的工具也需要重新设计为超级权限的容器。 如果你正在构建一个巨大的容器环境,这些额外的工作量是划算的。但是,如果只是想尝试下容器,那可能就没必要了。

容器提供了运行标准化的工作流程(比如使用 glibc 编译)的能力。一个好处就是你可以在你的电脑上构建和测试这个工作单元(Docker 镜像)并且在完全不同的硬件上或者云端非常顺利的部署,而保持着相同的特性。在生产环境中,容器的宿主机仍然由运维团队进行配置管理,但是应用被开发团队控制。这就是对双方来说最好的合作方式。

Unikernels 和 Rump 内核依旧是为了特定目标构建的,但是却更进一步。整个的操作系统在构建的时候就被开发或者架构师配置好了。这带来了好处,同时还有挑战。

一个好处就是,开发人员可以控制这个工作流程的运转。理论上说,一个开发者可以为了不同的特性,尝试 不同的 TCP 协议栈,并且选择最好的一个。在操作系统启动的时候,开发人也可以配置 IP 地址,而不是通过 DHCP。 开发人员也可以裁剪任何对于应用而言不需要的部分。这也是性能提升的保障,因为减少了不必要的上下文切换

同时,Unikernel 也带来了挑战。目前,还缺失很多的工具。 现在,和画板子的世界类似,开发人员需要花费很多时间和精力在检查是否有完整的库文件存在,不然的话,他们必须改变他们应用的执行方式。在如何让这个“嵌入式”的操作系统在运行时配置的方面,也存在挑战。最后,每次操作系统的大改动,都需要反馈到开发人员来进行修改。这并没有一个在开发和运维之间明确的界限,所以我能想象,为了接受了这个开发流程,一些组织或者公司必须要改变。

结论

在专门的容器主机比如 Rump 内核和 Unikernel 方面也有一些有趣的传闻,因为,它们会带来一个特定工作流程的潜在变革(嵌入式、云,等等)。在这个令人激动又快速发展的领域请保持你的关注,但是也要谨慎。

目前,Unikernel 看起来和定制电路板很像。它们都需要前期的研发投资,并且都是非常独特的,可以为确定的工作流程带来好处。同时,容器甚至在常规的工作流中都非常有趣,而且它不需要那么多的投入。一个简单的例子,运维团队能方便的在容器上部署一个应用,但是在 Unikernel 上部署一个应用则需要重新设计和编码,而且业界并不能完全保证,这个工作流程就可以被部署在 Unikernel 上。

容器,Rump 内核 和 Unikernel 有一个光明的未来!


via: https://opensource.com/business/16/5/containers-unikernels-learn-arduino-raspberry-pi

作者:Scott McCarty 译者:MikeCoder 校对:wxy

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

在这篇文章中,我们将考察一个 Node.js 开发原型,该原型用于从英国三个主要折扣网店查找“Raspberry PI Zero”的库存。

我写好了代码,然后经过一晚的鼓捣把它部署在 Aure 上的 Ubuntu 虚拟机上。Docker 和 docker-compose 工具使得部署和更新过程非常快。

还记得链接指令(link)吗?

如果你已经阅读过 Hands-on Docker tutorial,那么你应该已经可以使用命令行链接 Docker 容器。通过命令行将 Node.js 的计数器链接到 Redis 服务器,其命令可能如下所示:

$ docker run -d -P --name redis1
$ docker run -d hit_counter -p 3000:3000 --link redis1:redis

现在假设你的应用程序分为三层:

  • Web 前端
  • 处理长时间运行任务的批处理层
  • Redis 或者 mongo 数据库

通过--link的显式链接只是管理几个容器是可以的,但是可能会因为我们向应用程序添加更多层或容器而失控。

加入 docker-compose

Docker Compose logo

docker-compose 工具是标准 Docker 工具箱的一部分,也可以单独下载。 它提供了一组丰富的功能,通过纯文本 YAML 文件配置所有应用程序的部件。

上面的例子看起来像这样:

version: "2.0"
services:
  redis1:
    image: redis
  hit_counter:
    build: ./hit_counter
    ports:
     - 3000:3000

从 Docker 1.10 开始,我们可以利用网络覆盖(network overlays)来帮助我们在多个主机上进行扩展。 在此之前,链接仅能工作在单个主机上。 docker-compose scale 命令可以用来在需要时带来更多的计算能力。

查看 docker.com 上的 docker-compose 参考

 真实工作示例:Raspberry PI 库存警示

新的 Raspberry PI Zero v1.3 图片,由 Pimoroni 提供

Raspberry PI Zero 嗡嗡作响 - 它是一个极小的微型计算机,具有 1GHz CPU 和 512MB RAM,可以运行完整的Linux、Docker、Node.js、Ruby 和其他许多流行的开源工具。 PI Zero 最好的优点之一就是它成本只有 5 美元。 这也意味着它销售的速度非常之快。

如果你想在 PI 上尝试 Docker 和 Swarm,请查看下面的教程:Docker Swarm on the PI Zero

原始网站:whereismypizero.com

我发现一个网页,它使用屏幕抓取以找出 4-5 个最受欢迎的折扣网店是否有库存。

  • 网站包含静态 HTML 网页
  • 向每个折扣网店发出一个 XMLHttpRequest 访问 /public/api/
  • 服务器向每个网店发出 HTTP 请求并执行抓屏

每一次对 /public/api/ 的调用,其执行花 3 秒钟,而使用 Apache Bench(ab),我每秒只能完成 0.25 个请求。

重新发明轮子

零售商似乎并不介意 whereismypizero.com 抓取他们的网站的商品库存信息,所以我开始从头写一个类似的工具。 我尝试通过缓存和解耦 web 层来处理更多的抓取请求。 Redis 是执行这项工作的完美工具。 它允许我设置一个自动过期的键/值对(即一个简单的缓存),还可以通过 pub/sub 在 Node.js 进程之间传输消息。

复刻或者追踪放在 github 上的代码: alexellis/pizerostock

如果之前使用过 Node.js,你肯定知道它是单线程的,并且任何 CPU 密集型任务,如解析 HTML 或 JSON 都可能导致速度放缓。一种缓解这种情况的方法是使用一个工作进程和 Redis 消息通道作为它和 web 层之间的连接组织。

  • Web 层

    • 使用 200 代表缓冲命中(该商店的 Redis 键存在)
    • 使用 202 代表高速缓存未命中(该商店的 Redis 键不存在,因此发出消息)
    • 因为我们只是读一个 Redis 键,响应时间非常快。
  • 库存抓取器

    • 执行 HTTP 请求
    • 用于在不同类型的网店上抓屏
    • 更新 Redis 键的缓存失效时间为 60 秒
    • 另外,锁定一个 Redis 键,以防止对网店过多的 HTTP 请求。
version: "2.0"  
services:  
  web:
    build: ./web/
    ports:
     - "3000:3000"
  stock_fetch:
    build: ./stock_fetch/
  redis:
    image: redis

来自示例的 docker-compose.yml 文件

一旦本地正常工作,再向 Azure 的 Ubuntu 16.04 镜像云部署就轻车熟路,只花了不到 5 分钟。 我登录、克隆仓库并键入docker-compose up -d, 这就是所有的工作 - 快速实现整个系统的原型不会比这几个步骤更多。 任何人(包括 whereismypizero.com 的所有者)只需两行命令就可以部署新解决方案:

$ git clone https://github.com/alexellis/pi_zero_stock
$ docker-compose up -d

更新网站很容易,只需要一个git pull命令,然后执行docker-compose up -d命令,该命令需要带上--build参数。

如果你仍然手动链接你的 Docker 容器,请自己或使用如下我的代码尝试 Docker Compose:

复刻或者追踪在 github 上的代码: alexellis/pizerostock

一睹测试网站芳容

目前测试网站使用 docker-compose 部署:stockalert.alexellis.io

预览于 2016 年 5 月 16 日


via: http://blog.alexellis.io/rapid-prototype-docker-compose/

作者:Alex Ellis 译者:firstadream 校对:wxy

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