介绍

当 LXD 2.0 随着 Ubuntu 16.04 一起发布时，LXD 联网就简单了。要么你可以使用 lxd init 来配置，为你的容器自己提供一个 “lxdbr0” 网桥，要么使用一个已存在的物理接口。

虽然这确实有效，但是有点混乱，因为大部分的桥接配置发生在 Ubuntu 打包的 LXD 之外。那些脚本只能支持一个桥接，并且没有通过 API 暴露，这使得远程配置有点痛苦。

直到 LXD 2.3，LXD 终于发展了自己的网络管理 API ，并有相应的命令行工具。这篇文章试图来简述这些新的功能。

基础联网

在初始情况下，LXD 2.3 没有定义任何网络。lxd init 会为你设置一个，并且默认情况下将所有新的容器连接到它，但是让我们亲手尝试看下究竟发生了些什么。

要创建一个新的带有随机 IPv4 和 IP6 子网，并启用 NAT 的网络，只需要运行：

stgraber@castiana:~$ lxc network create testbr0
Network testbr0 created

你可以如下查看它的配置：

stgraber@castiana:~$ lxc network show testbr0
name: testbr0
config:
 ipv4.address: 10.150.19.1/24
 ipv4.nat: "true"
 ipv6.address: fd42:474b:622d:259d::1/64
 ipv6.nat: "true"
managed: true
type: bridge
usedby: []

如果你不想要那些自动配置的子网，你可以这么做：

stgraber@castiana:~$ lxc network create testbr0 ipv6.address=none ipv4.address=10.0.3.1/24 ipv4.nat=true
Network testbr0 created

那就会这样：

stgraber@castiana:~$ lxc network show testbr0
name: testbr0
config:
 ipv4.address: 10.0.3.1/24
 ipv4.nat: "true"
 ipv6.address: none
managed: true
type: bridge
usedby: []

如果你的容器没有使用它，那么创建的网络对你也没什么用。要将你新创建的网络连接到所有容器，你可以这么做：

stgraber@castiana:~$ lxc network attach-profile testbr0 default eth0

要将一个网络连接到一个已存在的容器中，你可以这么做：

stgraber@castiana:~$ lxc network attach my-container default eth0

现在，假设你已经在机器中安装了 openvswitch，并且要将这个网桥转换成 OVS 网桥，只需更改为正确的驱动：

stgraber@castiana:~$ lxc network set testbr0 bridge.driver openvswitch

如果你想要一次性做一系列修改。lxc network edit 可以让你在编辑器中交互编辑网络配置。

静态租约及端口安全

使用 LXD 管理 DHCP 服务器的一个好处是可以使得管理 DHCP 租约很简单。你所需要的是一个容器特定的网卡设备以及正确的属性设置。

root@yak:~# lxc init ubuntu:16.04 c1
Creating c1
root@yak:~# lxc network attach testbr0 c1 eth0
root@yak:~# lxc config device set c1 eth0 ipv4.address 10.0.3.123
root@yak:~# lxc start c1
root@yak:~# lxc list c1
+------+---------+-------------------+------+------------+-----------+
| NAME |  STATE  |        IPV4       | IPV6 |    TYPE    | SNAPSHOTS |
+------+---------+-------------------+------+------------+-----------+
|  c1  | RUNNING | 10.0.3.123 (eth0) |      | PERSISTENT | 0         |
+------+---------+-------------------+------+------------+-----------+

IPv6 也是相同的方法，但是换成 ipv6.address 属性。

相似地，如果你想要阻止你的容器更改它的 MAC 地址或者为其他 MAC 地址转发流量（比如嵌套），你可以用下面的命令启用端口安全：

root@yak:~# lxc config device set c1 eth0 security.mac_filtering true

DNS

LXD 在网桥上运行 DNS 服务器。除了设置网桥的 DNS 域（ dns.domain 网络属性）之外，还支持 3 种不同的操作模式（dns.mode）：

• managed ：每个容器都会有一条 DNS 记录，匹配它的名字以及已知的 IP 地址。容器无法通过 DHCP 改变这条记录。
• dynamic ：允许容器通过 DHCP 在 DNS 中自行注册。因此，在 DHCP 协商期间容器发送的任何主机名最终都出现在 DNS 中。
• none ： 针对那些没有任何本地 DNS 记录的递归 DNS 服务器。

默认的模式是 managed，并且典型的是最安全以及最方便的，因为它为容器提供了 DNS 记录，但是不允许它们通过 DHCP 发送虚假主机名嗅探其他的记录。

使用隧道

除了这些，LXD 还支持使用 GRE 或者 VXLAN 隧道连接到其他主机。

LXD 网络可以连接任何数量的隧道，从而轻松地创建跨多个主机的网络。这对于开发、测试和演示非常有用，生产环境通常更喜欢使用 VLAN 进行分割。

所以说，你想在主机 “edfu” 上有一个运行 IPv4 和 IPv6 的基础 “testbr0” 网络，并希望在主机 “djanet” 上使用它来生成容器。最简单的方法是使用组播 VXLAN 隧道。这种类型的隧道仅在两个主机位于同一物理段上时才起作用。

root@edfu:~# lxc network create testbr0 tunnel.lan.protocol=vxlan
Network testbr0 created
root@edfu:~# lxc network attach-profile testbr0 default eth0

它在主机 “edfu” 上定义了一个 “testbr0” 桥接，并为其他主机能加入它设置了一个组播 VXLAN。在这个设置中，“edfu” 为这个网络扮演了一个路由器角色，提供 DHCP、DNS 等等，其他主机只是通过隧道转发流量。

root@djanet:~# lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.lan.protocol=vxlan
Network testbr0 created
root@djanet:~# lxc network attach-profile testbr0 default eth0

现在你可以在任何一台主机上启动容器，并看到它们从同一个地址池中获取 IP，通过隧道直接互相通讯。

如先前所述，这个使用了组播，它通常在跨越路由器时无法很好工作。在这些情况下，你可以用单播模式使用 VXLAN 或者 GRE 隧道。

要使用 GRE 加入另一台主机，首先配置服务主机：

root@edfu:~# lxc network set testbr0 tunnel.nuturo.protocol gre
root@edfu:~# lxc network set testbr0 tunnel.nuturo.local 172.17.16.2
root@edfu:~# lxc network set testbr0 tunnel.nuturo.remote 172.17.16.9

接着是“客户端”主机：

root@nuturo:~# lxc network create testbr0 ipv4.address=none ipv6.address=none tunnel.edfu.protocol=gre tunnel.edfu.local=172.17.16.9 tunnel.edfu.remote=172.17.16.2
Network testbr0 created
root@nuturo:~# lxc network attach-profile testbr0 default eth0

如果你像使用 VXLAN，只要这么做：

root@edfu:~# lxc network set testbr0 tunnel.edfu.id 10
root@edfu:~# lxc network set testbr0 tunnel.edfu.protocol vxlan

还有：

root@nuturo:~# lxc network set testbr0 tunnel.edfu.id 10
root@nuturo:~# lxc network set testbr0 tunnel.edfu.protocol vxlan

这里需要隧道 id 以防与已经配置的多播 VXLAN 隧道冲突。

这就是如何使用最近的 LXD 简化跨主机联网了！

总结

LXD 使得从简单的单主机网络到数千个容器的非常复杂的跨主机网络的定义变得更加容易。它也使为一些容器定义一个新网络或者给容器添加第二个设备，并连接到隔离的私有网络变得很简单。

虽然这篇文章介绍了支持的大部分功能，但仍有一些可以微调 LXD 网络体验的窍门。可以在这里找到完整的列表：https://github.com/lxc/lxd/blob/master/doc/configuration.md 。

额外信息

• LXD 主站：https://linuxcontainers.org/lxd
• Github 地址： https://github.com/lxc/lxd
• 邮件列表支持：https://lists.linuxcontainers.org
• IRC 频道：#lxcontainers on irc.freenode.net
• 在线尝试 LXD：https://linuxcontainers.org/lxd/try-it

via: https://www.stgraber.org/2016/10/27/network-management-with-lxd-2-3/

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

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

在过去的几年中，我一直在做大量容器相关的工作。先前，我看到 Julien Friedman 的一个很棒的演讲，它用几行 Go 语言写了一个容器框架。这让我突然了解到容器只是一个受限的 Linux 进程中的机器。

构建这个受限视图涉及到 Golang 系统调用包中的很多调用。最初，我只是用到了表面的那些，但过了一段时间，我想剥下洋葱的下一层，看看这些系统调用是什么，以及它们的工作原理。我将在 OSCON 的演讲中分享我所学到的东西。

顾名思义，syscalls 即系统调用，它们是你从用户空间请求进入 Linux 内核的方式。内核为你做一些工作，例如创建一个进程，然后再回到用户空间。

有一个常见的机制使所有的系统调用转换到内核，这是由 libc 库处理的。 用户空间代码设置一些寄存器，包括其想要的系统调用的 ID 以及需要传递给系统调用的所有参数。它触发一个 “陷阱” 将控制转换到内核。

这就是用户空间代码如何向内核请求的，而 Linux 也有一个伪文件系统，它允许内核将信息传递给用户空间，其内容看起来像普通的目录和文件。

/proc 目录是一个很好的例子。看看里面，你会发现有关机器上运行的进程的各种有趣的信息。在某些情况，像 cgroups（控制组）那样，用户空间可以通过写入这些伪文件系统下的文件来配置参数。

当你在使用容器时，特别有趣的是，主机的 /proc 包含了所有有关容器化的进程的信息。这包括环境变量，它们也保存在 /proc 伪文件系统中，这意味着你的主机可以访问所有正在运行的容器的环境。如果你通过环境变量将诸如凭证或数据库密码这类秘密传递到容器中，则可能会产生安全性后果。

许多编写常规程序的程序员可能不觉得他们经常使用系统调用。但实际上他们会经常调用，因为每天的活动比如制作文件或者更改目录都涉及 Linux 的系统调用。

你不必是一位系统程序员才能享受系统调用的乐趣！

如果你想要了解更多，Liz 会在 Austin，Texas 举办的 OSCON 2017 上演讲 Linux 系统调用的初学者指南。

（题图： opensource.com）

作者简介：

Liz Rice - Liz Rice 是一位技术传播者，也是 Aqua Security 的容器安全专家。此前，她共同创立了 Microscaling Systems，并开发了其实时伸缩引擎，以及流行的图像元数据网站 MicroBadger.com。她拥有丰富的从网络协议和分布式系统，以及数字技术领域，如 VOD，音乐和 VoIP 软件的开发、团队和产品管理经验。

via: https://opensource.com/article/17/5/beginners-guide-syscalls

作者：Liz Rice 译者：geekpi 校对：wxy

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

一些令人振奋的消息引发了我对今年 DockerCon 的兴趣，在这次会议中，无可争议的容器巨头公司 Docker 发布了一个新的操作系统：LinuxKit。

这家容器巨头宣布的是一个灵活的、可扩展的操作系统，而为了可移植性，系统服务也是运行在容器之中。甚至，令人惊讶的是，就连 Docker 运行时环境也是运行在容器内！

在本文中，我们将简要介绍一下 LinuxKit 中所承诺的内容，以及如何自己尝试一下这个不断精简、优化的容器。

少即是多

不可否认的是，用户一直在寻找一个可以运行他们的微服务的精简版本的 Linux 。通过容器化，你会尽可能地最小化每个应用程序，使其成为一个适合于运行在其自身容器内的独立进程。但是，由于你需要对那些驻留容器的宿主机出现的问题进行修补，因此你不断地在宿主机间移动容器。实际上，如果没有像 Kubernetes 或 Docker Swarm 这样的编排系统，容器编排几乎总是会导致停机。

不用说，这只是让你保持操作系统尽可能小的原因之一。

我曾多次在不同场合重复过的最喜爱的名言，来自荷兰的天才程序员 Wietse Zweitze，他为我们提供了重要的 Email 软件 Postfix 和 TCP Wrappers 等知名软件。

在 Postfix 网站 指出，即使你编码和 Wietse 一样小心，“每 1000 行[你]就会在 Postfix 中引入一个额外的 bug”。从我的专业的 DevSecOps 角度看，这里提到的“bug” 可以将其大致看做安全问题。

从安全的角度来看，正是由于这个原因，代码世界中“少即是多”。简单地说，使用较少的代码行有很多好处，即安全性、管理时间和性能。对于初学者来说，这意味着安全漏洞较少，更新软件包的时间更短，启动时间更快。

深入观察

考虑下在容器内部运行你的程序。

一个好的起点是 Alpine Linux，它是一个苗条、精简的操作系统，通常比那些笨重的系统更受喜欢，如 Ubuntu 或 CentOS 等。Alpine 还提供了一个 miniroot 文件系统（用于容器内），最近我看到的大小是惊人的 1.8M。事实上，这个完整的 Linux 操作系统下载后有 80M。

如果你决定使用 Alpine Linux 作为 Docker 基础镜像，那么你可以在 Docker Hub 上找到一个， 它将其描述为：“一个基于 Alpine Linux 的最小 Docker 镜像，具有完整的包索引，大小只有5 MB！”

据说无处不在的 “Window 开始菜单” 文件也是大致相同的大小！我没有验证过，也不会进一步评论。

讲真，希望你去了解一下这个创新的类 Unix 操作系统（如 Alpine Linux）的强大功能。

锁定一切

再说一点，Alpine Linux 是（并不惊人）基于 BusyBox，这是一套著名的打包了 Linux 命令的集合，许多人不会意识到他们的宽带路由器、智能电视，当然还有他们家庭中的物联网设备就有它。

Alpine Linux 站点的“关于”页面的评论中指出：

“Alpine Linux 的设计考虑到安全性。内核使用 grsecurity/PaX 的非官方移植进行了修补，所有用户态二进制文件都编译为具有堆栈保护的地址无关可执行文件（PIE）。 这些主动安全特性可以防止所有类别的零日漏洞和其它漏洞利用。”

换句话说，这些捆绑在 Alpine Linux 中的精简二进制文件提供的功能通过了那些行业级安全工具筛选，以缓解缓冲区溢出攻击所带来的危害。

多只袜子

你可能会问，为什么当我们谈及 Docker 的新操作系统时，容器的内部结构很重要？

那么，你可能已经猜到，当涉及容器时，他们的目标是精简。除非绝对必要，否则不包括任何东西。所以你可以放心地清理橱柜、花园棚子、车库和袜子抽屉了。

Docker 的确因为它们的先见而获得声望。据报道，2 月初，Docker 聘请了 Alpine Linux 的主要推动者 Nathaniel Copa，他帮助将默认的官方镜像库从 Ubuntu 切换到 Alpine。Docker Hub 从新近精简镜像节省的带宽受到了赞誉。

并且最新的情况是，这项工作将与最新的基于容器的操作系统相结合：Docker 的 LinuxKit。

要说清楚的是 LinuxKit 注定不会代替 Alpine，而是位于容器下层，并作为一个完整的操作系统出现，你可以高兴地启动你的运行时守护程序（在这种情况下，是生成你的容器的Docker 守护程序 ）。

原子计划

经过精心调试的宿主机绝对不是一件新事物（以前提到过嵌入式 Linux 的家用设备）。在过去几十年中一直在优化 Linux 的天才在某个时候意识到底层的操作系统才是快速生产含有大量容器主机的关键。

例如，强大的红帽长期以来一直在出售已经贡献给 Project Atomic 的 红帽 Atomic 。后者继续解释：

“基于 Red Hat Enterprise Linux 或 CentOS 和 Fedora 项目的成熟技术，Atomic Host 是一个轻量级的、不可变的平台，其设计目的仅在于运行容器化应用程序。”

将底层的、不可变的 Atomic OS 作为红帽的 OpenShift PaaS（平台即服务）产品推荐有一个很好理由：它最小化、高性能、尖端。

特性强大

在 Docker 关于 LinuxKit 的公告中，“少即是多”的口号是显而易见的。实现 LinuxKit 愿景的项目显然是不小的事业，它由 Docker 老将和 Unikernel 的主管 Justin Cormack 指导，并与 HPE、Intel、ARM、IBM 和 Microsoft LinuxKit 合作，可以运行在从大型机到基于物联网的冰柜之中。

LinuxKit 的可配置性、可插拔性和可扩展性将吸引许多寻求建立其服务基准的项目。通过开源项目，Docker 明智地邀请每个人全身心地投入其功能开发，随着时间的推移，它会像好的奶酪那样成熟。

布丁作证

按照该发布消息中所承诺的，那些急于使用新系统的人不用再等待了。如果你准备着手 LinuxKit，你可以从 GitHub 中开始：LinuxKit。

在 GitHub 页面上有关于如何启动和运行一些功能的指导。

时间允许的话我准备更加深入研究 LinuxKit。对有争议的 Kubernetes 与 Docker Swarm 编排功能对比会是有趣的尝试。此外，我还想看到内存占用、启动时间和磁盘空间使用率的基准测试。

如果该承诺可靠，则作为容器运行的可插拔系统服务是构建操作系统的迷人方式。Docker 在博客）中提到：“因为 LinuxKit 是原生容器，它有一个非常小的尺寸 - 35MB，引导时间非常小。所有系统服务都是容器，这意味着可以删除或替换所有的内容。”

我不知道你觉得怎么样，但这非常符合我的胃口。

呼叫警察

除了我站在 DevSecOps 角度看到的功能，我会看看其对安全的承诺。

Docker 在他们的博客上引用来自 NIST（国家标准与技术研究所）的话：

“安全性是最高目标，这与 NIST 在其《应用程序容器安全指南》草案中说明的保持一致：‘使用容器专用操作系统而不是通用操作系统来减少攻击面。当使用专用容器操作系统时，攻击面通常比通用操作系统小得多，因此攻击和危及专用容器操作系统的机会较少。’”

可能最重要的容器到主机和主机到容器的安全创新是将系统容器（系统服务）完全地沙箱化到自己的非特权空间中，而只给它们需要的外部访问。

通过 内核自我保护项目 Kernel Self Protection Project （KSPP）的协作来实现这一功能，我很满意 Docker 开始专注于一些非常值得的东西上。对于那些不熟悉的 KSPP 的人而言，它存在理由如下：

“启动这个项目的的假设是内核 bug 的存在时间很长，内核必须设计成可以防止这些缺陷的危害。”

KSPP 网站进一步表态：

“这些努力非常重要并还在进行，但如果我们要保护我们的十亿 Android 手机、我们的汽车、国际空间站，还有其他运行 Linux 的产品，我们必须在上游的 Linux 内核中建立积极的防御性技术。我们需要内核安全地出错，而不只是安全地运行。”

而且，如果 Docker 最初只是在 LinuxKit 前进了一小步，那么随着时间的推移，成熟度带来的好处可能会在容器领域中取得长足的进步。

终点还远

像 Docker 这样不断发展壮大的巨头无论在哪个方向上取得巨大的飞跃都将会用户和其他软件带来益处。

我鼓励所有对 Linux 感兴趣的人密切关注这个领域。

via: http://www.devsecops.cc/devsecops/containers.html

作者：Chris Binnie 译者：geekpi 校对：wxy

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

在这个最后的物联网系列文章中，Canonical 和 Resin.io 向以 Linux 容器技术作为解决方案向物联网安全性和互操作性发起挑战。

尽管受到日益增长的安全威胁，但对物联网（IoT）的炒作没有显示减弱的迹象。为了刷存在感，公司们正忙于重新规划它们的物联网方面的路线图。物联网大潮迅猛异常，比移动互联网革命渗透的更加深入和广泛。IoT 像黑洞一样，吞噬一切，包括智能手机，它通常是我们通向物联网世界的窗口，有时也作为我们的汇聚点或终端。

新的针对物联网的处理器和嵌入式主板继续重塑其技术版图。自从 9 月份推出 面向物联网的 Linux 和开源硬件 系列文章之后，我们看到了面向物联网网关的 “Apollo Lake]” SoC 芯片 Intel Atom E3900 以及三星 新的 Artik 模块，包括用于网关并由 Linux 驱动的 64 位 Artik 7 COM 及自带 RTOS 的 Cortex-M4 Artik。 ARM 为具有 ARMv8-M 和 TrustZone 安全性的 IoT 终端发布了 Cortex-M23 和 Cortex-M33 芯片。

Artik 7

讲道理，安全是这些产品的卖点。最近攻击 Dyn 服务并在一天内摧毁了美国大部分互联网的 Mirai 僵尸网络将基于 Linux 的物联网推到台前 - 当然这种方式似乎不太体面。就像 IoT 设备可以成为 DDoS 的帮凶一样，设备及其所有者同样可能直接遭受恶意攻击。

Cortex-M33 和 -M23

Dyn 攻击事件更加证明了这种观点，即物联网将更加蓬勃地在受控制和受保护的工业环境发展，而不是家用环境中。这不是因为没有消费级物联网安全技术，但除非产品设计之初就以安全为目标，否则如我们的智能家居集线器系列中的许多解决方案一样，后期再考虑安全就会增加成本和复杂性。

在物联网系列的最后这个未来展望的部分，我们将探讨两种基于 Linux 的面向 Docker 的容器技术，这些技术被提出作为物联网安全解决方案。容器还可以帮助解决我们在物联网框架中探讨的开发复杂性和互操作性障碍的问题。

我们与 Canonical 的 Ubuntu 客户平台工程副总裁 Oliver Ries 讨论了 Ubuntu Core 和适用于 Docker 的容器式 Snaps 包管理技术。我们还就新的基于 Docker 的物联网方案 ResinOS 采访了 Resin.io 首席执行官和联合创始人 Alexandros Marinos。

Ubuntu Core Snaps

Canonical 面向物联网的 Snappy Ubuntu Core 版本的 Ubuntu 是围绕一个类似容器的快照包管理机制而构建的，并提供应用商店支持。 snaps 技术最近自行发布了用于其他 Linux 发行版的版本。去年 11 月 3 日，Canonical 发布了 Ubuntu Core 16，该版本改进了白标应用商店和更新控制服务。

传统 Ubuntu（左）架构 与 Ubuntu Core 16

快照机制提供自动更新，并有助于阻止未经授权的更新。 使用事务系统管理，快照可确保更新按预期部署或根本不部署。 在 Ubuntu Core 中，使用 AppArmor 进一步加强了安全性，并且所有应用程序文件都是只读的且保存在隔离的孤岛中。

LimeSDR

Ubuntu Core 是我们最近展开的开源物联网操作系统调查的一部分，现在运行于 Gumstix 主板、Erle 机器人无人机、Dell Edge 网关、Nextcloud Box、LimeSDR、Mycroft 家庭集线器、英特尔的 Joule 和符合 Linaro 的 96Boards 规范的 SBC（单板计算机） 上。 Canonical 公司还与 Linaro 物联网和嵌入式（LITE）部门集团在其 96Boards 物联网版（IE） 上达成合作。最初，96Boards IE 专注于 Zephyr 驱动的 Cortex-M4 板卡，如 Seeed 的 BLE Carbon，不过它将扩展到可以运行 Ubuntu Core 的网关板卡上。

“Ubuntu Core 和 snaps 具有从边缘到网关到云的相关性，”Canonical 的 Ries 说。 “能够在任何主要发行版（包括 Ubuntu Server 和 Ubuntu for Cloud）上运行快照包，使我们能够提供一致的体验。 snaps 可以使用事务更新以免故障方式升级，可用于安全性更新、错误修复或新功能的持续更新，这在物联网环境中非常重要。”

Nextcloud盒子

安全性和可靠性是关注的重点，Ries 说。 “snaps 应用可以完全独立于彼此和操作系统而运行，使得两个应用程序可以安全地在单个网关上运行，”他说。 “snaps 是只读的和经过认证的，可以保证代码的完整性。

Ries 还说这种技术减少开发时间。 “snap 软件包允许开发人员向支持它的任何平台提供相同的二进制包，从而降低开发和测试成本，减少部署时间和提高更新速度。 “使用 snap 软件包，开发人员完可以全控制开发生命周期，并可以立即更新。 snap 包提供了所有必需的依赖项，因此开发人员可以选择定制他们使用的组件。”

ResinOS: 为 IoT 而生的 Docker

Resin.io 公司，与其商用的 IoT 框架同名，最近剥离了该框架的基于 Yocto Linux 的 ResinOS 2.0，ResinOS 2.0 将作为一个独立的开源项目运营。 Ubuntu Core 在 snap 包中运行 Docker 容器引擎，ResinOS 在主机上运行 Docker。 极致简约的 ResinOS 抽离了使用 Yocto 代码的复杂性，使开发人员能够快速部署 Docker 容器。

ResinOS 2.0 架构

与基于 Linux 的 CoreOS 一样，ResinOS 集成了 systemd 控制服务和网络协议栈，可通过异构网络安全地部署更新的应用程序。 但是，它是为在资源受限的设备（如 ARM 黑客板）上运行而设计的，与之相反，CoreOS 和其他基于 Docker 的操作系统（例如基于 Red Hat 的 Project Atomic）目前仅能运行在 x86 上，并且更喜欢资源丰富的服务器平台。 ResinOS 可以在 20 中 Linux 设备上运行，并不断增长，包括 Raspberry Pi，BeagleBone 和Odroid-C1 等。

“我们认为 Linux 容器对嵌入式系统比对于云更重要，”Resin.io 的 Marinos 说。 “在云中，容器代表了对之前的进程的优化，但在嵌入式中，它们代表了姗姗来迟的通用虚拟化“

BeagleBone Black

当应用于物联网时，完整的企业级虚拟机有直接访问硬件的限制的性能缺陷，Marinos 说。像 OSGi 和 Android 的Dalvik 这样的移动设备虚拟机可以用于 IoT，但是它们依赖 Java 并有其他限制。

对于企业开发人员来说，使用 Docker 似乎很自然，但是你如何说服嵌入式黑客转向全新的范式呢？ “Marinos 解释说，”ResinOS 不是把云技术的实践经验照单全收，而是针对嵌入式进行了优化。”此外，他说，容器比典型的物联网技术更好地包容故障。 “如果有软件缺陷，主机操作系统可以继续正常工作，甚至保持连接。要恢复，您可以重新启动容器或推送更新。更新设备而不重新启动它的能力进一步消除了故障引发问题的机率。”

据 Marinos 所说，其他好处源自与云技术的一致性，例如拥有更广泛的开发人员。容器提供了“跨数据中心和边缘的统一范式，以及一种方便地将技术、工作流、基础设施，甚至应用程序转移到边缘（终端）的方式。”

Marinos 说，容器中的固有安全性优势正在被其他技术增强。 “随着 Docker 社区推动实现镜像签名和鉴证，这些自然会转移并应用到 ResinOS，”他说。 “当 Linux 内核被强化以提高容器安全性时，或者获得更好地管理容器所消耗的资源的能力时，会产生类似的好处。

容器也适合开源 IoT 框架，Marinos 说。 “Linux 容器很容易与几乎各种协议、应用程序、语言和库结合使用，”Marinos 说。 “Resin.io 参加了 AllSeen 联盟，我们与使用 IoTivity 和 Thread的 伙伴一起合作。”

IoT的未来：智能网关与智能终端

Marinos 和 Canonical 的 Ries 对未来物联网的几个发展趋势具有一致的看法。 首先，物联网的最初概念（其中基于 MCU 的端点直接与云进行通信以进行处理）正在迅速被雾化计算架构所取代。 这需要更智能的网关，也需要比仅仅在 ZigBee 和 WiFi 之间聚合和转换数据更多的功能。

其次，网关和智能边缘设备越来越多地运行多个应用程序。 第三，许多这些设备将提供板载分析，这些在最新的智能家居集线器上都有体现。 最后，富媒体将很快成为物联网组合的一部分。

最新设备网关: Eurotech 的 ReliaGate 20-26

最新设备网关: Advantech 的 UBC-221

“智能网关正在接管最初为云服务设计的许多处理和控制功能，”Marinos 说。 “因此，我们看到对容器化的推动力在增加，可以在 IoT 设备中使用类似云工作流程来部署与功能和安全相关的优化。去中心化是由移动数据紧缩、不断发展的法律框架和各种物理限制等因素驱动的。”

Ubuntu Core 等平台正在使“可用于网关的软件爆炸式增长”，Canonical 的 Ries 说。 “在单个设备上运行多个应用程序的能力吸引了众多单一功能设备的用户，以及现在可以产生持续的软件收入的设备所有者。”

两种 IoT 网关: MyOmega MYNXG IC2 Controller

两种 IoT 网关: TechNexion 的 LS1021A-IoT Gateway

不仅是网关 - 终端也变得更聪明。 “阅读大量的物联网新闻报道，你得到的印象是所有终端都运行在微控制器上，”Marinos 说。 “但是我们对大量的 Linux 终端，如数字标牌，无人机和工业机械等直接执行任务，而不是作为操作中介（数据转发）感到惊讶。我们称之为影子 IoT。”

Canonical 的 Ries 同意，对简约技术的专注使他们忽视了新兴物联网领域。 “轻量化的概念在一个发展速度与物联网一样快的行业中初现端倪，”Ries 说。 “今天的高级消费硬件可以持续为终端供电数月。”

虽然大多数物联网设备将保持轻量和“无头”（一种配置方式，比如物联网设备缺少显示器，键盘等），它们装备有如加速度计和温度传感器这样的传感器并通过低速率的数据流通信，但是许多较新的物联网应用已经使用富媒体。 “媒体输入/输出只是另一种类型的外设，”Marinos 说。 “总是存在多个容器竞争有限资源的问题，但它与传感器或蓝牙竞争天线资源没有太大区别。”

Ries 看到了工业和家庭网关中“提高边缘智能”的趋势。 “我们看到人工智能、机器学习、计算机视觉和上下文意识的大幅上升，”Ries 说。 “为什么要在云中运行面部检测软件，如果相同的软件可以在边缘设备运行而又没有网络延迟和带宽及计算成本呢？“

当我们在这个物联网系列的开篇故事中探索时，我们发现存在与安全相关的物联网问题，例如隐私丧失和生活在监视文化中的权衡。还有一些问题如把个人决策交给可能由他人操控的 AI 裁定。这些不会被容器，快照或任何其他技术完全解决。

如果 AWS Alexa 可以处理生活琐事，而我们专注在要事上，也许我们会更快乐。或许有一个方法来平衡隐私和效用，现在，我们仍在探索，如此甚好。

via: http://hackerboards.com/can-linux-containers-save-iot-from-a-security-meltdown/

作者：Eric Brown 译者：firstadream 校对：wxy

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

如果你正在寻找一种管理运行容器的 Linux 服务器的简单方法，那么你应该看看 Cockpit。

如果你管理着一台 Linux 服务器，那么你可能正在寻找一个可靠的管理工具。为了这个你可能已经看了 Webmin 和 cPanel 这类软件。但是，如果你正在寻找一种简单的方法来管理还包括了 Docker 的 Linux 服务器，那么有一个工具可以用于这个需求：Cockpit。

为什么使用 Cockpit？因为它可以处理这些管理任务：

• 连接并管理多台机器
• 通过 Docker 管理容器
• 与 Kubernetes 或 Openshift 集群进行交互
• 修改网络设置
• 管理用户帐号
• 通过基于 Web 的 shell 访问
• 通过图表查看系统性能信息
• 查看系统服务和日志文件

Cockpit 可以安装在 Debian、Red Hat、CentOS、Arch Linux 和 Ubuntu 之上。在这里，我将使用一台已经安装了 Docker 的 Ubuntu 16.04 服务器来安装系统。

在上面的功能列表中，其中最突出的是容器管理。为什么？因为它使安装和管理容器变得非常简单。事实上，你可能很难找到更好的容器管理解决方案。

因此，让我们来安装这个方案并看看它的使用是多么简单。

安装

正如我前面提到的，我将在一台运行着 Docker 的 Ubuntu 16.04 实例上安装 Cockpit。安装步骤很简单。你要做的第一件事是登录你的 Ubuntu 服务器。接下来，你必须使用下面的命令添加必要的仓库：

sudo add-apt-repository ppa:cockpit-project/cockpit

出现提示时，按下键盘上的回车键，等待提示返回。一旦返回到 bash 提示符，使用下面的命令来更新 apt：

sudo apt-get get update

使用下面的命令安装 Cockpit：

sudo apt-get -y install cockpit cockpit-docker

安装完成后，需要启动 Cockpit 服务并使它开机自动启动。要做到这个，使用下面的两个命令：

sudo systemctl start cockpit
sudo systemctl enable cockpit

安装就到这里了。

登录到 Cockpit

要访问 Cockpit 的 web 界面，打开浏览器（与 Cockpit 服务器在同一个网络内），输入 http://IP_OF_SERVER:9090，你就会看到登录页面（图 1）。

图 1：Cockpit 登录页面。

在 Ubuntu 中使用 Cockpit 有个警告。Cockpit 中的很多任务需要管理员权限。如果你使用普通用户登录，则无法使用 Docker 等一些工具。 要解决这个问题，你可以在 Ubuntu 上启用 root 用户。但这并不总是一个好主意。通过启用 root 帐户，你将绕过已经建立多年的安全系统。但是，在本文的用途中，我将使用以下两个命令启用 root 用户：

sudo passwd root
sudo passwd -u root 

注意，请确保给 root 帐户一个强壮的密码。

你想恢复这个修改的话，你只需输入下面的命令：

sudo passwd -l root

在其他发行版（如 CentOS 和 Red Hat）中，你可以使用用户名 root 及其密码登录 Cockpit，而无需像上面那样需要额外的步骤。

如果你对启用 root 用户感到担心，则可以在服务器的终端窗口拉取镜像（使用命令 docker pull IMAGE_NAME， 这里的 IMAGE_NAME 是你要拉取的镜像）。这会将镜像添加到你的 docker 服务器中，然后可以通过普通用户进行管理。唯一需要注意的是，普通用户必须使用以下命令将自己添加到 Docker 组：

sudo usermod -aG docker USER

其中，USER 是实际添加到组的用户名。在你完成后，重新登出并登入，接着使用下面的命令重启 Docker：

sudo service docker restart

现在常规用户可以启动并停止 Docker 镜像/容器而无需启用 root 用户了。唯一一点是用户不能通过 Cockpit 界面添加新的镜像。

使用 Cockpit

一旦你登录后，你可以看到 Cockpit 的主界面（图 2）。

图 2：Cockpit 主界面。

你可以通过每个栏目来检查服务器的状态等，但是我们想要直接进入容器。单击 “Containers” 那栏以显示当前运行的以及可用的镜像（图3）。

图 3：使用 Cockpit 管理容器难以置信地简单。

要启动一个镜像，只要找到镜像并点击关联的启动按钮。在弹出的窗口中（图 4），你可以在点击运行之前查看所有镜像的信息（并根据需要调整）。

图 4： 使用 Cockpit 运行 Docker 镜像。

镜像运行后，你可以点击它查看状态，并可以停止、重启、删除实例。你也可以点击修改资源限制并接着调整内存限制还有（或者）CPU 优先级。

添加新的镜像

假设你以 root 用户身份登录。如果是这样，那么你可以在 Cockpit GUI 的帮助下添加新的镜像。在“ Container” 栏目下，点击获取新的镜像按钮，然后在新的窗口中搜索要添加的镜像。假设你要添加 CentOS 的最新官方版本。在搜索栏中输入 centos，在得到搜索结果后，选择官方列表，然后单击下载（图5）。

图 5：使用 Cockpit 添加最新的官方构建 CentOS 镜像到 Docker 中。

镜像下载完后，那它就在 Docker 中可用了，并可以通过 Cockpit 运行。

如获取它那样简单

管理 Docker 并不容易。是的，在 Ubuntu 上运行 Cockpit 会有一个警告，但如果这是你唯一的选择，那么也有办法让它工作。在 Cockpit 的帮助下，你不仅可以轻松管理 Docker 镜像，也可以在任何可以访问 Linux 服务器的 web 浏览器上这样做。请享受这个新发现的让 Docker 易用的方法。

via: https://www.linux.com/learn/intro-to-linux/2017/3/make-container-management-easy-cockpit

作者：JACK WALLEN 译者：geekpi 校对：jasminepeng

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

与互联网领域的领导们关于"容器"的讨论通常被总结如下：

作为一名 CxO，我面临杠杆时间术的持续的压力。IT 预算不断减少，我只有有限的资源。然而，交付的工作量却比以往更多。我花费太多的时间致力于解决预算的约束。另外，互联网的格局正在经历一个快速的改变，而且新的技术一直在被引进。我从我最信任的顾问那听来的最新的话题是一个“容器策略”的实现。我想理解：

1. 什么是容器？
2. 过渡到容器的企业价值是什么？
3. 为什么我现在应该转移到容器？如果我不采纳会有一些坏处吗？
4. 容器是否已经足够成熟用于企业消费？
5. 我如何让我的企业因使用容器而快速地发展？

让我们从最开头开始。

容器

在过去的 10 年左右，企业已经从物理基础设施转向了虚拟机（VM）。转向 VM 的关键优势是可以减少数据中心的用量。通过在同一个物理机器上运行多个虚拟机，你可以在更少数量的物理机器上安装更多的应用程序。使用容器是另一种更轻量地打包应用程序的方式，而且其交付模式更快。它们是一种在单一的机器里运行多个应用程序进程的奇特方式，无论那个机器是一个虚拟机还是一个物理机。另外，容器在 DevOps 、微服务和云战略场景方面也扮演了重要角色。

容器 vs 虚拟机

容器和虚拟机在一些方面并不相同。一台虚拟机尽管不是物理机，但是它表现地就像是一台物理机。虚拟机是一个包含所有东西的独立的环境，是一个完整的（来宾）操作系统。在另一方面，容器是一个共享同一个物理机或虚拟机上资源的进程。容器显然更加有趣，因为：

• 相比较而言，虚拟机要重一些，而容器更轻。因为容器只包括了它们所运行的程序所需要的库。
• 虚拟机需要花费几分钟来启动，而容器在几秒钟内就可以启动。
• 通常，相比虚拟机，你的基础设施中可以容纳更多的容器。

技术已经发展到足以保持这些容器安全、彼此独立，而且正确的设计选择可以保证那些坏掉的容器不会影响运行在同一个机器里的其他容器的性能。实际上，操作系统天生就是被用来构建成优化和运行容器的。

然而，当你转向容器时，你需要做出正确的选择。你需要做足够的尽职调查，以便你选择合适的技术合作伙伴和能够制作容器的制造商。开源技术起着很关键的作用。开源的 Docker 项目使得分层格式的容器很容易构建和使用。开放容器计划（OCI）已经成为被所有主要技术供应商所支持的开源容器标准。如 Red Hat 这样的开源技术提供商提供了为容器而准备的安全的操作系统。例如， Red Hat Enterprise Linux 7.x （包括 Red Hat Enterprise Linux 原子主机）进行了优化以原生地运行容器，同时也提供监控和管理容器的工具。其他的开源项目如来自 Tectonic 的 CoreOS 也正在进入市场。的确，容器正等着被企业所采用。

容器平台

容器平台让容器成为企业消耗品。在过去这些年中，你可能在你的企业里处理过虚拟机散乱的问题，容器散乱比那要糟糕好几倍。在你的数据中心横跨不同主机运行不同规模的容器，尽管容器故障仍然保证你的应用程序的高可用性，自动化健康检查和基于流入的工作载荷的自动化容器缩放等等，这些是你能期待容器平台应该有的一些关键特性。

当在一个被定位为容器即服务模型（CaaS）的平台上运行容器时，这些平台的一些其它特性如自动化生成和部署使这个平台成为平台即服务模型（PaaS）。虽然 CaaS 能让你规模化运行容器，但是，PaaS 可以让你利用你的源代码编译、创建容器，为你运行那些容器。另外，这些平台提供了完整操作管理特性，例如，集群的管理和监控、容器的安全缺陷检测，以及安全地运行容器、跟踪日志和度量等等。

尽管一些技术供应商正在使用他们的专有技术来构建容器平台，但总的来说，企业们正在围绕建立在 Kubernetes（K8S）的基础上的开源技术而进行标准化。K8S 是一项由 Google 发起的开源项目，现在很多大平台的供应商也支持它。K8S 也是云端原生计算基金会（CNCF）的一部分，CNCF 正在发展成以云为中心技术的标准体。当你在容器平台上做出选择时，围绕开源流程编排技术的标准化是非常重要的。它基本上允许你移植到不同的容器平台，如果你不喜欢你第一次做的选择的话。K8S 还允许你的容器工作载荷可跨越不同的公有云进行迁移。这些就是为什么我们会看到越来越多的技术公司正在使用 Kubernetes 的原因。

一些企业正在试图通过拼接几个包括 K8S 在内开源项目来打造他们自己 DIY 的容器平台。这确实是比继续跟随专有技术要更好的一种解决方案，但是要完成这项工作也仍然包含很多需要探讨的地方。然而，一个企业的维护和保持这样的 DIY 平台的能力应该被认真评估。许多企业并不是想做创建 IT 平台的工作，而是他们希望运行自己的主流业务。有很多可行的基于 K8S 的解决方案，比如红帽 OpenShift 平台容器、Apprenda、Deis 和 Rancher，它们提供一个企业级平台，这些解决方案中的每种都有不同完整程度的功能。

这些解决方案是由供应商认证和支持。有些方案是完全的开源 PaaS 解决方案，而另外一些可能是 CaaS。根据你的企业的需求，这些解决方案可能是比 DIY 容器平台更好的替代品。

企业的担忧和它们与容器的关系

今天，几乎每个企业都正在与数字时代转型打交道，这些转型影响包括 DevOps 战略、微服务和云等多个领域。容器在这些领域中的每一个中都起着相当重要的作用。

DevOps 策略

IT 组织被分成运维和应用开发，他们作为两个独立的团队运作，每一队都只有他们自己的一套目标。大多数企业为了将这两个团队联合起来正在朝 DevOps 的方向前进。

容器在 DevOps 倡议的成功中发挥着重要的作用。在 DevOps 中成功的关键标准之一是增加开发人员在运营中的份额。开发人员不仅应该把代码交给运维人员，而且他们还应该考虑他们的代码是如何在生产环境中运行的。普遍的技术是采用“架构即代码”，而不是提供几页容易出错的安装说明指示，开发团队应该提供像编程时的环境配置。

这恰恰就是容器可以解决的问题。可以作为容器的模版的容器镜像包括了从基本操作系统到应用程序代码的整个环境堆栈。利用容器，开发人员将不再只是从 Dev 到 QA 再到 Prod 这样生成应用程序；相反，他们将传递一个版本化的容器镜像，这个镜像包括生成的运行程序和它运行需要的环境。容器是包罗万象的，从操作系统库到中间件再到应用程序的所有东西都被整合进一个镜像里面。因此，容器在开发环境运行的方式和它在质量保证环境和生产环境下运行的方式完全一样。容器是 DevOps 成功的重要因素。

另外，容器平台正在进一步发展。典型的持续集成和交付（CICD）工具，如 Jenkins，可以作为容器，这个容器能在容器平台本身运行整个 CICD 过程，而不需要额外的基础设施。现在你可以使用 PaaS 平台来生成和运行你的 CICD 管道。

微服务策略

微服务是今天 IT 领域的另一个热门话题。应用程序是这样被设计的：把应用程序分解为离散化的小的服务，每个服务完成一个小任务。这些服务中的每一个都可以根据合适的技术用不同的编程语言进行编写。它们可以由小团队（双比萨团队）创建和管理，并且可以迅速地改变它们。所有这些要求再次需要用到容器。容器足够小到成为微服务的基础。容器能够支持任何你选择的技术和语言，容器易于创建和运行，并且可以快速地改变。微服务和容器现在已经不分彼此，如果有人说不使用容器来实现微服务，他们将会受到别人奇怪的表情。

实际情况是，虽然微服务有望让情况变得简单，但是它们的扩张也增加了复杂性。有几个微服务的设计和开发模式将能使它们易于实现。这意味着开发人员现在急需这样一个开发平台，在这个平台下，开发人员可以轻松地部署和组织微服务，而且还能：

• 以一种语言不可知的方式实现这些微服务设计模式。
• 不会因代码侵入而增加代码的复杂性，以便开发人员能将许多模式的代码包括进他们的业务逻辑中。
• 足够灵活以便部署在你所选择的基础设施上，并且不会把你捆绑在特定的云上。

这就是选择一个正确的容器平台所起作用的地方。在具体的基础设施上按照某一特定供应商的方法来实现这些微服务将会把你的应用程序捆绑在那些供应商的平台上。使用类似兼容 OCI 的容器的容器化微服务将可以保证你的微服务能够被运行在任何兼容 OCI 的平台上。

选择正确的容器平台来运行你的微服务是需要做的另一个重要的决定。今天，有很少的选择和许多的 FUD。如果你作出选择时不足够慎重，其中一些选择会把你带到非标准的、特定供应商的路线上。

云策略

云战略是 IT 领域的又一个热门话题。无论你是否喜欢，服务化模型都是不可避免的变化。如果你不将其作为 IT 服务进行提供，你的开发团队将可能会找到创建“shadow IT”的方法来访问云。另外，尽管使用云技术将会让你从资本支出转移到运营支出，但是，管理云支出是一个不断的挑战。

云可以提供虚拟机，在你添加额外的虚拟机之前，你要确认这个云上的 CPU、内存和网络等资源都处于最佳使用状态。容器在这个地方扮演着很重要的角色。因为容器比虚拟机要小得多。并且，如果你的应用程序正运行在容器中，你可以在虚拟机中安装更多的容器，这比在每台虚拟机中运行一个应用程序组件要多很多。

公有云供应商有很多，其中 Amazon Web Services（AWS）、Microsoft Azure 和 Google Cloud 最受欢迎。另外，你可能想在你的基于 OpenStack 的数据中心里拥有你自己的私有云。这些云环境中的每一个都有它们自己的协议、API 和工具。当你想让你的应用程序在云上运行时，你不会想要让您的应用编排被云供应商所制约，也不会想要维护任何特定云的代码。在你的技术上与特定的云供应商锁定就像在未来几年内向供应商签署空白支票。

云的可移植性对您的云战略至关重要。你可以编写应用程序，而不用担心它们在哪里运行，容器平台可以将你和特定的云供应商协议隔离开来，从而避免你与一个云供应商锁定。

传统系统

微服务架构带给开发的优势很多，但并不是每个应用程序都可以重构它们自己，有些只能重构一部分。传统的应用程序被普遍接受，它们需要维护和管理。虽然容器可以实现微服务，但容器不仅仅只是微服务。可以想象，你可以将大型应用程序和微服务作为容器来运行，因此只要你选择正确的容器技术和正确的应用程序平台，就可以将许多（如果不是所有）的传统的应用程序作为容器运行。

总结

我希望这篇对各种策略和容器的深入剖析有助于你的公司对下一步进行评估。让我在评论里面了解您公司学习到的经验，或者说没能大步向前跨越，他们还需要我再提供一些什么信息。

（题图来源：Maersk Line. CC SA-BY 4.0）

作者简介：

Veer Muchandi -- 开源爱好者，容器和PaaS倡导者，喜欢学习和分享。

via: https://opensource.com/article/17/1/container-strategy-for-executives

作者：Veer Muchandi 译者：zhousiyu325 校对：wxy

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