标签 容器 下的文章

想知道容器编排管理和 K8S 的最新展望么？来看看专家怎么说。

title=

如果你想对容器在未来的发展方向有一个整体把握，那么你一定要跟着钱走，看看钱都投在了哪里。当然了，有很多很多的钱正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 27 亿美元 的市场份额。而在 2016 年，容器相关技术投入的总额为 7.62 亿美元，只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素，包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用，容器编排管理也会被理所当然的推广应用起来。

来自 The new stack 的调研数据表明，容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据，在已经将容器技术使用到生产环境中的使用者里，有六成使用者正在将 Kubernetes（K8S）编排管理广泛的应用在生产环境中，另外百分之十九的人员则表示他们已经处于部署 K8S 的初级阶段。在容器部署初期的使用者当中，虽然只有百分之五的人员表示已经在使用 K8S ，但是百分之五十八的人员表示他们正在计划和准备使用 K8S。总而言之，容器和 Kubernetes 的关系就好比是鸡和蛋一样，相辅相成紧密关联。众多专家一致认为编排管理工具对容器的长周期管理 以及其在市场中的发展有至关重要的作用。正如 Cockroach 实验室 的 Alex Robinson 所说，容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问，这是一个正在快速演变的领域，且未来潜力无穷。鉴于此，我们对 Robinson 和其他的一些容器的实际使用和推介者做了采访，来从他们作为容器技术的践行者的视角上展望一下容器编排以及 K8S 的下一步发展。

容器编排将被主流接受

像任何重要技术的转型一样，我们就像是处在一个高崖之上一般，在经过了初期步履蹒跚的跋涉之后将要来到一望无际的广袤平原。广大的新天地和平实真切的应用需求将会让这种新技术在主流应用中被迅速推广，尤其是在大企业环境中。正如 Alex Robinson 说的那样，容器技术的淘金阶段已经过去，早期的技术革新创新正在减速，随之而来的则是市场对容器技术的稳定性和可用性的强烈需求。这意味着未来我们将不会再见到大量的新的编排管理系统的涌现，而是会看到容器技术方面更多的安全解决方案，更丰富的管理工具，以及基于目前主流容器编排系统的更多的新特性。

更好的易用性

人们将在简化容器的部署方面下大功夫，因为容器部署的初期工作对很多公司和组织来说还是比较复杂的，尤其是容器的长期管理维护更是需要投入大量的精力。正如 Codemill AB 公司的 My Karlsson 所说，容器编排技术还是太复杂了，这导致很多使用者难以娴熟驾驭和充分利用容器编排的功能。很多容器技术的新用户都需要花费很多精力，走很多弯路，才能搭建小规模的或单个的以隔离方式运行的容器系统。这种现象在那些没有针对容器技术设计和优化的应用中更为明显。在简化容器编排管理方面有很多优化可以做，这些优化和改造将会使容器技术更加具有可用性。

在混合云以及多云技术方面会有更多侧重

随着容器和容器编排技术被越来越多的使用，更多的组织机构会选择扩展他们现有的容器技术的部署，从之前的把非重要系统部署在单一环境的使用情景逐渐过渡到更加复杂的使用情景。对很多公司来说，这意味着他们必须开始学会在 混合云 和 多云 的环境下，全局化的去管理那些容器化的应用和微服务。正如红帽 Openshift 部门产品战略总监 Brian Gracely 所说，“容器和 K8S 技术的使用使得我们成功的实现了混合云以及应用的可移植性。结合 Open Service Broker API 的使用，越来越多的结合私有云和公有云资源的新应用将会涌现出来。” 据 CloudBees 公司的高级工程师 Carlos Sanchez 分析，联合服务（Federation）将会得到极大推动，使一些诸如多地区部署和多云部署等的备受期待的新特性成为可能。

想知道 CIO 们对混合云和多云的战略构想么? 请参看我们的这条相关资源， [Hybrid Cloud: The IT leader's guide。 ]

平台和工具的持续整合及加强

对任何一种科技来说，持续的整合和加强从来都是大势所趋；容器编排管理技术在这方面也不例外。来自 Sumo Logic 的首席分析师 Ben Newton 表示，随着容器化渐成主流，软件工程师们正在很少数的一些技术上做持续整合加固的工作，来满足他们的一些微应用的需求。容器和 K8S 将会毫无疑问的成为容器编排管理方面的主流平台，并轻松碾压其它的一些小众平台方案。因为 K8S 提供了一个相当清晰的可以摆脱各种特有云生态的途径，K8S 将被大量公司使用，逐渐形成一个不依赖于某个特定云服务的 “中立云” cloud-neutral 。

K8S 的下一站

来自 Alcide 的 CTO 和联合创始人 Gadi Naor 表示，K8S 将会是一个有长期和远景发展的技术，虽然我们的社区正在大力推广和发展 K8S，K8S 仍有很长的路要走。

专家们对日益流行的 K8S 平台也作出了以下一些预测：

来自 Alcide 的 Gadi Naor 表示： “运营商会持续演进并趋于成熟，直到在 K8S 上运行的应用可以完全自治。利用 OpenTracing 和诸如 istio 技术的 service mesh 架构，在 K8S 上部署和监控微应用将会带来很多新的可能性。”

来自 Red Hat 的 Brian Gracely 表示： “K8S 所支持的应用的种类越来越多。今后在 K8S 上，你不仅可以运行传统的应用程序，还可以运行原生的云应用、大数据应用以及 HPC 或者基于 GPU 运算的应用程序，这将为灵活的架构设计带来无限可能。”

来自 Sumo Logic 的 Ben Newton 表示： “随着 K8S 成为一个具有统治地位的平台，我预计更多的操作机制将会被统一化，尤其是 K8S 将和第三方管理和监控平台融合起来。”

来自 CloudBees 的 Carlos Sanchez 表示： “在不久的将来我们就能看到不依赖于 Docker 而使用其它运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ 编辑提示：[CRI-O 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。”

来自 Cockroach Labs 的 Alex Robinson 表示： “ K8S 社区正在讨论的一个重大发展议题就是加强对有状态程序的管理。目前在 K8S 平台下，实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 K8S 平台内部以及在外部服务商一端做出的一些改进。”

via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next

作者：Kevin Casey 译者：yunfengHe 校对：wxy

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

Moby Project

自从 Docker 四年前将软件容器推向大众化以来，整个生态系统都围绕着容器化而发展，在这段这么短的时期内，它经历了两个不同的增长阶段。在这每一个阶段，生产容器系统的模式已经随着项目和不断增长的容器生态系统而演变适应用户群体的规模和需求。

Moby 是一个新的开源项目，旨在推进软件容器化运动，帮助生态系统将容器作为主流。它提供了一个组件库，一个将它们组装到定制的基于容器的系统的框架，也是所有容器爱好者进行实验和交换想法的地方。

让我们来回顾一下我们如何走到今天。在 2013-2014 年，开拓者开始使用容器，并在一个单一的开源代码库，Docker 和其他一些项目中进行协作，以帮助工具成熟。

Docker Open Source

然后在 2015-2016 年，云原生应用中大量采用容器用于生产环境。在这个阶段，用户社区已经发展到支持成千上万个部署，由数百个生态系统项目和成千上万的贡献者支持。正是在这个阶段，Docker 将其产品模式演变为基于开放式组件的方法。这样，它使我们能够增加创新和合作的方面。

涌现出来的新独立的 Docker 组件项目帮助促进了合作伙伴生态系统和用户社区的发展。在此期间，我们从 Docker 代码库中提取并快速创新组件，以便系统制造商可以在构建自己的容器系统时独立重用它们：runc、HyperKit、VPNKit、SwarmKit、InfraKit、containerd 等。

Docker Open Components

站在容器浪潮的最前沿，我们看到 2017 年出现的一个趋势是容器将成为主流，传播到计算、服务器、数据中心、云、桌面、物联网和移动的各个领域。每个行业和垂直市场，金融、医疗、政府、旅游、制造。以及每一个使用案例，现代网络应用、传统服务器应用、机器学习、工业控制系统、机器人技术。容器生态系统中许多新进入者的共同点是，它们建立专门的系统，针对特定的基础设施、行业或使用案例。

作为一家公司，Docker 使用开源作为我们的创新实验室，而与整个生态系统合作。Docker 的成功取决于容器生态系统的成功：如果生态系统成功，我们就成功了。因此，我们一直在计划下一阶段的容器生态系统增长：什么样的产品模式将帮助我们扩大容器生态系统，以实现容器成为主流的承诺？

去年，我们的客户开始在 Linux 以外的许多平台上要求有 Docker：Mac 和 Windows 桌面、Windows Server、云平台（如亚马逊网络服务（AWS）、Microsoft Azure 或 Google 云平台），并且我们专门为这些平台创建了许多 Docker 版本。为了在一个相对较短的时间和更小的团队中，以可扩展的方式构建和发布这些专业版本，而不必重新发明轮子，很明显，我们需要一个新的方式。我们需要我们的团队不仅在组件上进行协作，而且还在组件组合上进行协作，这借用来自汽车行业的想法，其中组件被重用于构建完全不同的汽车。

Docker production model

我们认为将容器生态系统提升到一个新的水平以让容器成为主流的最佳方式是在生态系统层面上进行协作。

Moby Project

为了实现这种新的合作高度，今天（2017 年 4 月 18 日）我们宣布推出软件容器化运动的新开源项目 Moby。它是提供了数十个组件的“乐高组件”，一个将它们组合成定制容器系统的框架，以及所有容器爱好者进行试验和交换意见的场所。可以把 Moby 认为是容器系统的“乐高俱乐部”。

Moby 包括：

  1. 容器化后端组件库（例如，低层构建器、日志记录设备、卷管理、网络、镜像管理、containerd、SwarmKit 等）
  2. 将组件组合到独立容器平台中的框架，以及为这些组件构建、测试和部署构件的工具。
  3. 一个名为 “Moby Origin” 的引用组件，它是 Docker 容器平台的开放基础，以及使用 Moby 库或其他项目的各种组件的容器系统示例。

Moby 专为系统构建者而设计，他们想要构建自己的基于容器的系统，而不是可以使用 Docker 或其他容器平台的应用程序开发人员。Moby 的参与者可以从源自 Docker 的组件库中进行选择，或者可以选择将“自己的组件”（BYOC）打包为容器，以便在所有组件之间进行混合和匹配以创建定制的容器系统。

Docker 将 Moby 作为一个开放的研发实验室来试验、开发新的组件，并与容器技术的未来生态系统进行协作。我们所有的开源协作都将转向 Moby。Docker 现在并且将来仍然是一个开源产品，可以让你创建、发布和运行容器。从用户的角度来看，它是完全一样的。用户可以继续从 docker.com 下载 Docker。请在 Moby 网站上参阅有关 Docker 和 Moby 各自角色的更多信息。

请加入我们，帮助软件容器成为主流，并通过在组件和组合上进行协作，将我们的生态系统和用户社区发展到下一个高度。

via: https://blog.docker.com/2017/04/introducing-the-moby-project/

作者：Solomon Hykes 译者：geekpi 校对：wxy

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

让我们来探讨一下“容器主机”和“容器操作系统”之间的关系，以及它们在 Linux 和 Windows 容器之间的区别。

一些定义

  • 容器主机 Container Host ：也称为 主机操作系统 Host OS 。主机操作系统是 Docker 客户端和 Docker 守护程序在其上运行的操作系统。在 Linux 和非 Hyper-V 容器的情况下，主机操作系统与运行中的 Docker 容器共享内核。对于 Hyper-V，每个容器都有自己的 Hyper-V 内核。
  • 容器操作系统 Container OS ：也被称为 基础操作系统 Base OS 。基础操作系统是指包含操作系统如 Ubuntu、CentOS 或 windowsservercore 的镜像。通常情况下，你将在基础操作系统镜像之上构建自己的镜像，以便可以利用该操作系统的部分功能。请注意，Windows 容器需要一个基础操作系统，而 Linux 容器不需要。
  • 操作系统内核 Operating System Kernel ：内核管理诸如内存、文件系统、网络和进程调度等底层功能。

如下的一些图

Linux Containers

在上面的例子中：

  • 主机操作系统是 Ubuntu。
  • Docker 客户端和 Docker 守护进程（一起被称为 Docker 引擎）正在主机操作系统上运行。
  • 每个容器共享主机操作系统内核。
  • CentOS 和 BusyBox 是 Linux 基础操作系统镜像。
  • “No OS” 容器表明你不需要基础操作系统以在 Linux 中运行一个容器。你可以创建一个含有 scratch 基础镜像的 Docker 文件，然后运行直接使用内核的二进制文件。
  • 查看这篇文章来比较基础 OS 的大小。

Windows Containers - Non Hyper-V

在上面的例子中：

  • 主机操作系统是 Windows 10 或 Windows Server。
  • 每个容器共享主机操作系统内核。
  • 所有 Windows 容器都需要 nanoserver 或 windowsservercore 的基础操作系统。

Windows Containers - Hyper-V

在上面的例子中：

  • 主机操作系统是 Windows 10 或 Windows Server。
  • 每个容器都托管在自己的轻量级 Hyper-V 虚拟机中。
  • 每个容器使用 Hyper-V 虚拟机内的内核，它在容器之间提供额外的分离层。
  • 所有 Windows 容器都需要 nanoserver 或 windowsservercore 的基础操作系统。

几个好的链接

via: http://floydhilton.com/docker/2017/03/31/Docker-ContainerHost-vs-ContainerOS-Linux-Windows.html

作者：Floyd Hilton 译者：geekpi 校对：wxy

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

本文将介绍如何借助 minikube 在 Kubernetes 1.8 上搭建 OpenFaaS（让 Serverless Function 变得更简单）。minikube 是一个 Kubernetes 分发版，借助它，你可以在笔记本电脑上运行 Kubernetes 集群，minikube 支持 Mac 和 Linux 操作系统，但是在 MacOS 上使用得更多一些。

本文基于我们最新的部署手册 Kubernetes 官方部署指南

安装部署 Minikube

1、 安装 xhyve driver 或 VirtualBox ，然后在上面安装 Linux 虚拟机以部署 minikube 。根据我的经验，VirtualBox 更稳定一些。

2、 参照官方文档 安装 minikube 。

3、 使用 brew 或 curl -sL cli.openfaas.com | sudo sh 安装 faas-cli。

4、 通过 brew install kubernetes-helm 安装 helm 命令行。

5、 运行 minikube ：minikube start。

Docker 船长小贴士：Mac 和 Windows 版本的 Docker 已经集成了对 Kubernetes 的支持。现在我们使用 Kubernetes 的时候，已经不需要再安装额外的软件了。

在 minikube 上面部署 OpenFaaS

1、 为 Helm 的服务器组件 tiller 新建服务账号：

kubectl -n kube-system create sa tiller \
 && kubectl create clusterrolebinding tiller \
 --clusterrole cluster-admin \
 --serviceaccount=kube-system:tiller

2、 安装 Helm 的服务端组件 tiller：

helm init --skip-refresh --upgrade --service-account tiller

3、 克隆 Kubernetes 的 OpenFaaS 驱动程序 faas-netes：

git clone https://github.com/openfaas/faas-netes && cd faas-netes

4、 Minikube 没有配置 RBAC，这里我们需要把 RBAC 关闭：

helm upgrade --install --debug --reset-values --set async=false --set rbac=false openfaas openfaas/

（LCTT 译注：RBAC（Role-Based access control）基于角色的访问权限控制，在计算机权限管理中较为常用，详情请参考以下链接：https://en.wikipedia.org/wiki/Role-based_access_control ）

现在，你可以看到 OpenFaaS pod 已经在你的 minikube 集群上运行起来了。输入 kubectl get pods 以查看 OpenFaaS pod：

NAME                            READY     STATUS    RESTARTS   AGE
alertmanager-6dbdcddfc4-fjmrf   1/1       Running   0          1m
faas-netesd-7b5b7d9d4-h9ftx     1/1       Running   0          1m
gateway-965d6676d-7xcv9         1/1       Running   0          1m
prometheus-64f9844488-t2mvn     1/1       Running   0          1m

30,000ft：

该 API 网关包含了一个 用于测试功能的最小化 UI，同时开放了用于功能管理的 RESTful API 。 faas-netesd 守护进程是一种 Kubernetes 控制器，用来连接 Kubernetes API 服务器来管理服务、部署和密码。

Prometheus 和 AlertManager 进程协同工作，实现 OpenFaaS Function 的弹性缩放，以满足业务需求。通过 Prometheus 指标我们可以查看系统的整体运行状态，还可以用来开发功能强悍的仪表盘。

Prometheus 仪表盘示例：

构建/迁移/运行

和很多其他的 FaaS 项目不同，OpenFaaS 使用 Docker 镜像格式来进行 Function 的创建和版本控制，这意味着可以在生产环境中使用 OpenFaaS 实现以下目标：

  • 漏洞扫描（LCTT 译注：此处我觉得应该理解为更快地实现漏洞补丁）
  • 持续集成/持续开发
  • 滚动更新

你也可以在现有的生产环境集群中利用空闲资源部署 OpenFaaS。其核心服务组件内存占用大概在 10-30MB 。

OpenFaaS 一个关键的优势在于，它可以使用容器编排平台的 API ，这样可以和 Kubernetes 以及 Docker Swarm 进行本地集成。同时，由于使用 Docker 存储库 registry 进行 Function 的版本控制，所以可以按需扩展 Function，而没有按需构建 Function 的框架的额外的延时。

新建 Function

faas-cli new --lang python hello

以上命令创建文件 hello.yml 以及文件夹 handler，文件夹有两个文件 handler.py、requirements.txt 可用于你可能需要的 pip 模块。你可以随时编辑这些文件和文件夹，不需要担心如何维护 Dockerfile —— 我们为你通过以下方式维护：

  • 分级创建
  • 非 root 用户
  • 以官方的 Docker Alpine Linux 版本为基础进行镜像构建 (可替换)

构建你的 Function

先在本地创建 Function，然后推送到 Docker 存储库。 我们这里使用 Docker Hub，打开文件 hello.yml 然后输入你的账号名：

provider:
  name: faas
  gateway: http://localhost:8080
functions:
  hello:
    lang: python
    handler: ./hello
    image: alexellis2/hello

现在，发起构建。你的本地系统上需要安装 Docker 。

faas-cli build -f hello.yml

把封装好 Function 的 Docker 镜像版本推送到 Docker Hub。如果还没有登录 Docker hub ，继续前需要先输入命令 docker login 。

faas-cli push -f hello.yml

当系统中有多个 Function 的时候，可以使用 --parallel=N 来调用多核并行处理构建或推送任务。该命令也支持这些选项： --no-cache、--squash 。

部署及测试 Function

现在，可以部署、列出、调用 Function 了。每次调用 Function 时，可以通过 Prometheus 收集指标值。

$ export gw=http://$(minikube ip):31112
$ faas-cli deploy -f hello.yml --gateway $gw
Deploying: hello.
No existing function to remove
Deployed.
URL: http://192.168.99.100:31112/function/hello

上面给到的是部署时调用 Function 的标准方法，你也可以使用下面的命令：

$ echo test | faas-cli invoke hello --gateway $gw

现在可以通过以下命令列出部署好的 Function，你将看到调用计数器数值增加。

$ faas-cli list --gateway $gw
Function                       Invocations     Replicas
hello                          1               1

提示：这条命令也可以加上 --verbose 选项获得更详细的信息。

由于我们是在远端集群（Linux 虚拟机）上面运行 OpenFaaS，命令里面加上一条 --gateway 用来覆盖环境变量。 这个选项同样适用于云平台上的远程主机。除了加上这条选项以外，还可以通过编辑 .yml 文件里面的 gateway 值来达到同样的效果。

迁移到 minikube 以外的环境

一旦你在熟悉了在 minikube 上运行 OpenFaaS ，就可以在任意 Linux 主机上搭建 Kubernetes 集群来部署 OpenFaaS 了。

继续学习

我们的 Github 上面有很多手册和博文，可以带你轻松“上车”，把我们的页面保存成书签吧：openfaas/faas 。

2017 哥本哈根 Dockercon Moby 峰会上，我做了关于 Serverless 和 OpenFaaS 的概述演讲，这里我把视频放上来，视频不长，大概 15 分钟左右。

最后，别忘了关注 OpenFaaS on Twitter 这里有最潮的新闻、最酷的技术和 Demo 展示。

via: https://medium.com/@alexellisuk/getting-started-with-openfaas-on-minikube-634502c7acdf

作者：Alex Ellis 译者：mandeler 校对：wxy

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

Ubuntu Core 是什么？

Ubuntu Core 是完全基于 snap 包构建，并且完全事务化的 Ubuntu 版本。

该系统大部分是只读的，所有已安装的应用全部来自 snap 包，完全使用事务化更新。这意味着不管在系统更新还是安装软件的时候遇到问题，整个系统都可以回退到之前的状态并且记录这个错误。

最新版是在 2016 年 11 月发布的 Ubuntu Core 16。

注意，Ubuntu Core 限制只能够安装 snap 包（而非 “传统” 软件包），并且有相当数量的 snap 包在当前环境下不能正常运行，或者需要人工干预（创建用户和用户组等）才能正常运行。随着新版的 snapd 和 “core” snap 包发布，Ubuntu Core 每周都会得到改进。

环境需求

就 LXD 而言，Ubuntu Core 仅仅相当于另一个 Linux 发行版。也就是说，snapd 需要挂载无特权的 FUSE 和 AppArmor 命名空间以及软件栈，像下面这样：

  • 一个新版的使用 Ubuntu 官方内核的系统
  • 一个新版的 LXD

创建一个 Ubuntu Core 容器

当前 Ubuntu Core 镜像发布在社区的镜像服务器。你可以像这样启动一个新的容器：

stgraber@dakara:~$ lxc launch images:ubuntu-core/16 ubuntu-core
Creating ubuntu-core
Starting ubuntu-core

这个容器启动需要一点点时间，它会先执行第一阶段的加载程序，加载程序会确定使用哪一个镜像（镜像是只读的），并且在系统上设置一个可读层，你不要在这一阶段中断容器执行，这个时候什么都没有，所以执行 lxc exec 将会出错。

几秒钟之后，执行 lxc list 将会展示容器的 IP 地址，这表明已经启动了 Ubuntu Core：

stgraber@dakara:~$ lxc list
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+
|     NAME    |  STATE  |          IPV4        |                      IPV6                    |    TYPE    | SNAPSHOTS |
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+
| ubuntu-core | RUNNING | 10.90.151.104 (eth0) | 2001:470:b368:b2b5:216:3eff:fee1:296f (eth0) | PERSISTENT | 0         |
+-------------+---------+----------------------+----------------------------------------------+------------+-----------+

之后你就可以像使用其他的交互一样和这个容器进行交互：

stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap list
Name       Version     Rev  Developer  Notes
core       16.04.1     394  canonical  -
pc         16.04-0.8   9    canonical  -
pc-kernel  4.4.0-45-4  37   canonical  -
root@ubuntu-core:~#

更新容器

如果你一直关注着 Ubuntu Core 的开发，你应该知道上面的版本已经很老了。这是因为被用作 Ubuntu LXD 镜像的代码每隔几个月才会更新。Ubuntu Core 系统在重启时会检查更新并进行自动更新（更新失败会回退）。

如果你想现在强制更新，你可以这样做：

stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap refresh
pc-kernel (stable) 4.4.0-53-1 from 'canonical' upgraded
core (stable) 16.04.1 from 'canonical' upgraded
root@ubuntu-core:~# snap version
snap 2.17
snapd 2.17
series 16
root@ubuntu-core:~#

然后重启一下 Ubuntu Core 系统，然后看看 snapd 的版本。

root@ubuntu-core:~# reboot
root@ubuntu-core:~# 

stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap version
snap 2.21
snapd 2.21
series 16
root@ubuntu-core:~#

你也可以像下面这样查看所有 snapd 的历史记录：

stgraber@dakara:~$ lxc exec ubuntu-core snap changes
ID  Status  Spawn                 Ready                 Summary
1   Done    2017-01-31T05:14:38Z  2017-01-31T05:14:44Z  Initialize system state
2   Done    2017-01-31T05:14:40Z  2017-01-31T05:14:45Z  Initialize device
3   Done    2017-01-31T05:21:30Z  2017-01-31T05:22:45Z  Refresh all snaps in the system

安装 Snap 软件包

以一个最简单的例子开始，经典的 Hello World：

stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap install hello-world
hello-world 6.3 from 'canonical' installed
root@ubuntu-core:~# hello-world
Hello World!

接下来让我们看一些更有用的：

stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap install nextcloud
nextcloud 11.0.1snap2 from 'nextcloud' installed

之后通过 HTTP 访问你的容器就可以看到刚才部署的 Nextcloud 实例。

如果你想直接通过 git 测试最新版 LXD，你可以这样做：

stgraber@dakara:~$ lxc config set ubuntu-core security.nesting true
stgraber@dakara:~$ lxc exec ubuntu-core bash
root@ubuntu-core:~# snap install lxd --edge
lxd (edge) git-c6006fb from 'canonical' installed
root@ubuntu-core:~# lxd init
Name of the storage backend to use (dir or zfs) [default=dir]: 

We detected that you are running inside an unprivileged container.
This means that unless you manually configured your host otherwise,
you will not have enough uid and gid to allocate to your containers.

LXD can re-use your container's own allocation to avoid the problem.
Doing so makes your nested containers slightly less safe as they could
in theory attack their parent container and gain more privileges than
they otherwise would.

Would you like to have your containers share their parent's allocation (yes/no) [default=yes]? 
Would you like LXD to be available over the network (yes/no) [default=no]? 
Would you like stale cached images to be updated automatically (yes/no) [default=yes]? 
Would you like to create a new network bridge (yes/no) [default=yes]? 
What should the new bridge be called [default=lxdbr0]? 
What IPv4 address should be used (CIDR subnet notation, “auto” or “none”) [default=auto]? 
What IPv6 address should be used (CIDR subnet notation, “auto” or “none”) [default=auto]? 
LXD has been successfully configured.

已经设置过的容器不能回退版本，但是可以在 Ubuntu Core 16 中运行另一个 Ubuntu Core 16 容器：

root@ubuntu-core:~# lxc launch images:ubuntu-core/16 nested-core
Creating nested-core
Starting nested-core 
root@ubuntu-core:~# lxc list
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+
|    NAME     |  STATE  |         IPV4        |                       IPV6                    |    TYPE    | SNAPSHOTS |
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+
| nested-core | RUNNING | 10.71.135.21 (eth0) | fd42:2861:5aad:3842:216:3eff:feaf:e6bd (eth0) | PERSISTENT | 0         |
+-------------+---------+---------------------+-----------------------------------------------+------------+-----------+

写在最后

如果你只是想试用一下 Ubuntu Core，这是一个不错的方法。对于 snap 包开发者来说，这也是一个不错的工具来测试你的 snap 包能否在不同的环境下正常运行。

如果你希望你的系统总是最新的，并且整体可复制，Ubuntu Core 是一个很不错的方案，不过这也会带来一些相应的限制，所以可能不太适合你。

最后是一个警告，对于测试来说，这些镜像是足够的，但是当前并没有被正式的支持。在不久的将来，官方的 Ubuntu server 可以完整的支持 Ubuntu Core LXD 镜像。

附录

来自: https://insights.ubuntu.com/2017/02/27/ubuntu-core-in-lxd-containers/

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

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

title=

题图抽象的形容了容器和虚拟机是那么的相似，又是那么的不同！

在近期的一些会议和学术交流会上，我一直在讲述有关 DevOps 的安全问题（亦称为 DevSecOps） 注1 。通常，我首先都会问一个问题：“在座的各位有谁知道什么是容器吗？” 通常并没有很多人举手 注2 ，所以我都会先简单介绍一下什么是容器 注3 ，然后再进行深层次的讨论交流。

更准确的说，在运用 DevOps 或者 DevSecOps 的时候，容器并不是必须的。但容器能很好的融于 DevOps 和 DevSecOps 方案中，结果就是，虽然不用容器便可以运用 DevOps ，但我还是假设大部分人依然会使用容器。

什么是容器

几个月前的一个会议上，一个同事正在容器上操作演示，因为大家都不是这个方面的专家，所以该同事就很简单的开始了他的演示。他说了诸如“在 Linux 内核源码中没有一处提及到 容器 container 。“之类的话。事实上，在这样的特殊群体中，这种描述表达是很危险的。就在几秒钟内，我和我的老板（坐在我旁边）下载了最新版本的内核源代码并且查找统计了其中 “container” 单词出现的次数。很显然，这位同事的说法并不准确。更准确来说，我在旧版本内核（4.9.2）代码中发现有 15273 行代码包含 “container” 一词 注4 。我和我老板会心一笑，确认同事的说法有误，并在休息时纠正了他这个有误的描述。

后来我们搞清楚同事想表达的意思是 Linux 内核中并没有明确提及容器这个概念。换句话说，容器使用了 Linux 内核中的一些概念、组件、工具以及机制，并没有什么特殊的东西；这些东西也可以用于其他目的 注 5 。所以才有会说“从 Linux 内核角度来看，并没有容器这样的东西。”

然后，什么是容器呢？我有着虚拟化（ 管理器 hypervisor 和虚拟机）技术的背景，在我看来， 容器既像虚拟机（VM）又不像虚拟机。我知道这种解释好像没什么用，不过请听我细细道来。

容器和虚拟机相似之处有哪些？

容器和虚拟机相似的一个主要方面就是它是一个可执行单元。将文件打包生成镜像文件，然后它就可以运行在合适的主机平台上。和虚拟机一样，它运行于主机上，同样，它的运行也受制于该主机。主机平台为容器的运行提供软件环境和硬件资源（诸如 CPU 资源、网络环境、存储资源等等），除此之外，主机还需要负责以下的任务：

  1. 为每一个工作单元（这里指虚拟机和容器）提供保护机制，这样可以保证即使某一个工作单元出现恶意的、有害的以及不能写入的情况时不会影响其他的工作单元。
  2. 主机保护自己不会受一些恶意运行或出现故障的工作单元影响。

虚拟机和容器实现这种隔离的原理并不一样，虚拟机的隔离是由管理器对硬件资源划分，而容器的隔离则是通过 Linux 内核提供的软件功能实现的 注6 。这种软件控制机制通过不同的“命名空间”保证了每一个容器的文件、用户以及网络连接等互不可见，当然容器和主机之间也互不可见。这种功能也能由 SELinux 之类软件提供，它们提供了进一步隔离容器的功能。

容器和虚拟机不同之处又有哪些？

以上描述有个问题，如果你对 管理器 hypervisor 机制概念比较模糊，也许你会认为容器就是虚拟机，但它确实不是。

首先，最为重要的一点 注7 ，容器是一种包格式。也许你会惊讶的反问我“什么，你不是说过容器是某种可执行文件么？” 对，容器确实是可执行文件，但容器如此迷人的一个主要原因就是它能很容易的生成比虚拟机小很多的实体化镜像文件。由于这些原因，容器消耗很少的内存，并且能非常快的启动与关闭。你可以在几分钟或者几秒钟（甚至毫秒级别）之内就启动一个容器，而虚拟机则不具备这些特点。

正因为容器是如此轻量级且易于替换，人们使用它们来创建微服务——应用程序拆分而成的最小组件，它们可以和一个或多个其它微服务构成任何你想要的应用。假使你只在一个容器内运行某个特定功能或者任务，你也可以让容器变得很小，这样丢弃旧容器创建新容器将变得很容易。我将在后续的文章中继续跟进这个问题以及它们对安全性的可能影响，当然，也包括 DevSecOps 。

希望这是一次对容器的有用的介绍，并且能带动你有动力去学习 DevSecOps 的知识（如果你不是，假装一下也好）。

  • 注 1：我觉得 DevSecOps 读起来很奇怪，而 DevOpsSec 往往有多元化的理解，然后所讨论的主题就不一样了。
  • 注 2：我应该注意到这不仅仅会被比较保守、不太喜欢被人注意的英国听众所了解，也会被加拿大人和美国人所了解，他们的性格则和英国人不一样。
  • 注 3：当然，我只是想讨论 Linux 容器。我知道关于这个问题，是有历史根源的，所以它也值得注意，而不是我故弄玄虚。
  • 注 4：如果你感兴趣的话，我使用的是命令 grep -ir container linux-4.9.2 | wc -l
  • 注 5：公平的说，我们快速浏览一下，一些用途与我们讨论容器的方式无关，我们讨论的是 Linux 容器，它是抽象的，可以用来包含其他元素，因此在逻辑上被称为容器。
  • 注 6：也有一些巧妙的方法可以将容器和虚拟机结合起来以发挥它们各自的优势，那个不在我今天的主题范围内。
  • 注 7：很明显，除了我们刚才介绍的执行位。

原文来自 Alice, Eve, and Bob—a security blog ，转载请注明

（题图： opensource.com ）

作者简介：

原文作者 Mike Bursell 是一名居住在英国、喜欢威士忌的开源爱好者， Red Hat 首席安全架构师。其自从 1997 年接触开源世界以来，生活和工作中一直使用 Linux （尽管不是一直都很容易）。更多信息请参考作者的博客 https://aliceevebob.com ，作者会不定期的更新一些有关安全方面的文章。

via: https://opensource.com/article/17/10/what-are-containers

作者：Mike Bursell 译者：jrglinux 校对：wxy

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

  1. 1
  2. ...
  3. 12
  4. 13
  5. 14
  6. 15
  7. 16
  8. 17
  9. 18
  10. ...
  11. 24