应用这些策略来保护容器解决方案的各个层面和容器生命周期的各个阶段的安全。

容器提供了打包应用程序的一种简单方法，它实现了从开发到测试到投入生产系统的无缝传递。它也有助于确保跨不同环境的连贯性，包括物理服务器、虚拟机、以及公有云或私有云。这些好处使得一些组织为了更方便地部署和管理为他们提升业务价值的应用程序，而快速地采用了容器技术。

企业需要高度安全，在容器中运行核心服务的任何人都会问，“容器安全吗？”以及“我们能信任运行在容器中的应用程序吗？”

对容器进行安全保护就像是对运行中的进程进行安全保护一样。在你部署和运行你的容器之前，你需要去考虑整个解决方案各个层面的安全。你也需要去考虑贯穿了应用程序和容器整个生命周期的安全。

请尝试从这十个关键的因素去确保容器解决方案栈不同层面、以及容器生命周期的不同阶段的安全。

1. 容器宿主机操作系统和多租户环境

由于容器将应用程序和它的依赖作为一个单元来处理，使得开发者构建和升级应用程序变得更加容易，并且，容器可以启用多租户技术将许多应用程序和服务部署到一台共享主机上。在一台单独的主机上以容器方式部署多个应用程序、按需启动和关闭单个容器都是很容易的。为完全实现这种打包和部署技术的优势，运营团队需要运行容器的合适环境。运营者需要一个安全的操作系统，它能够在边界上保护容器安全、从容器中保护主机内核，以及保护容器彼此之间的安全。

容器是隔离而资源受限的 Linux 进程，允许你在一个共享的宿主机内核上运行沙盒化的应用程序。保护容器的方法与保护你的 Linux 中运行的任何进程的方法是一样的。降低权限是非常重要的，也是保护容器安全的最佳实践。最好使用尽可能小的权限去创建容器。容器应该以一个普通用户的权限来运行，而不是 root 权限的用户。在 Linux 中可以使用多个层面的安全加固手段，Linux 命名空间、安全强化 Linux（SELinux）、cgroups 、capabilities（LCTT 译注：Linux 内核的一个安全特性，它打破了传统的普通用户与 root 用户的概念，在进程级提供更好的安全控制）、以及安全计算模式（ seccomp ），这五种 Linux 的安全特性可以用于保护容器的安全。

2. 容器内容（使用可信来源）

在谈到安全时，首先要考虑你的容器里面有什么？例如 ，有些时候，应用程序和基础设施是由很多可用组件所构成的。它们中的一些是开源的软件包，比如，Linux 操作系统、Apache Web 服务器、Red Hat JBoss 企业应用平台、PostgreSQL，以及 Node.js。这些软件包的容器化版本已经可以使用了，因此，你没有必要自己去构建它们。但是，对于你从一些外部来源下载的任何代码，你需要知道这些软件包的原始来源，是谁构建的它，以及这些包里面是否包含恶意代码。

3. 容器注册（安全访问容器镜像）

你的团队的容器构建于下载的公共容器镜像，因此，访问和升级这些下载的容器镜像以及内部构建镜像，与管理和下载其它类型的二进制文件的方式是相同的，这一点至关重要。许多私有的注册库支持容器镜像的存储。选择一个私有的注册库，可以帮你将存储在它的注册中的容器镜像实现策略自动化。

4. 安全性与构建过程

在一个容器化环境中，软件构建过程是软件生命周期的一个阶段，它将所需的运行时库和应用程序代码集成到一起。管理这个构建过程对于保护软件栈安全来说是很关键的。遵守“一次构建，到处部署”的原则，可以确保构建过程的结果正是生产系统中需要的。保持容器的恒定不变也很重要 — 换句话说就是，不要对正在运行的容器打补丁，而是，重新构建和部署它们。

不论是因为你处于一个高强度监管的行业中，还是只希望简单地优化你的团队的成果，设计你的容器镜像管理以及构建过程，可以使用容器层的优势来实现控制分离，因此，你应该去这么做：

• 运营团队管理基础镜像
• 架构师管理中间件、运行时、数据库，以及其它解决方案
• 开发者专注于应用程序层面，并且只写代码

最后，标记好你的定制构建容器，这样可以确保在构建和部署时不会搞混乱。

5. 控制好在同一个集群内部署应用

如果是在构建过程中出现的任何问题，或者在镜像被部署之后发现的任何漏洞，那么，请在基于策略的、自动化工具上添加另外的安全层。

我们来看一下，一个应用程序的构建使用了三个容器镜像层：内核、中间件，以及应用程序。如果在内核镜像中发现了问题，那么只能重新构建镜像。一旦构建完成，镜像就会被发布到容器平台注册库中。这个平台可以自动检测到发生变化的镜像。对于基于这个镜像的其它构建将被触发一个预定义的动作，平台将自己重新构建应用镜像，合并该修复的库。

一旦构建完成，镜像将被发布到容器平台的内部注册库中。在它的内部注册库中，会立即检测到镜像发生变化，应用程序在这里将会被触发一个预定义的动作，自动部署更新镜像，确保运行在生产系统中的代码总是使用更新后的最新的镜像。所有的这些功能协同工作，将安全功能集成到你的持续集成和持续部署（CI/CD）过程和管道中。

6. 容器编配：保护容器平台安全

当然了，应用程序很少会以单一容器分发。甚至，简单的应用程序一般情况下都会有一个前端、一个后端、以及一个数据库。而在容器中以微服务模式部署的应用程序，意味着应用程序将部署在多个容器中，有时它们在同一台宿主机上，有时它们是分布在多个宿主机或者节点上，如下面的图所示：

在大规模的容器部署时，你应该考虑：

• 哪个容器应该被部署在哪个宿主机上？
• 那个宿主机应该有什么样的性能？
• 哪个容器需要访问其它容器？它们之间如何发现彼此？
• 你如何控制和管理对共享资源的访问，像网络和存储？
• 如何监视容器健康状况？
• 如何去自动扩展性能以满足应用程序的需要？
• 如何在满足安全需求的同时启用开发者的自助服务？

考虑到开发者和运营者的能力，提供基于角色的访问控制是容器平台的关键要素。例如，编配管理服务器是中心访问点，应该接受最高级别的安全检查。API 是规模化的自动容器平台管理的关键，可以用于为 pod、服务，以及复制控制器验证和配置数据；在入站请求上执行项目验证；以及调用其它主要系统组件上的触发器。

7. 网络隔离

在容器中部署现代微服务应用，经常意味着跨多个节点在多个容器上部署。考虑到网络防御，你需要一种在一个集群中的应用之间的相互隔离的方法。一个典型的公有云容器服务，像 Google 容器引擎（GKE）、Azure 容器服务，或者 Amazon Web 服务（AWS）容器服务，是单租户服务。他们让你在你初始化建立的虚拟机集群上运行你的容器。对于多租户容器的安全，你需要容器平台为你启用一个单一集群，并且分割流量以隔离不同的用户、团队、应用、以及在这个集群中的环境。

使用网络命名空间，容器内的每个集合（即大家熟知的 “pod”）都会得到它自己的 IP 和绑定的端口范围，以此来从一个节点上隔离每个 pod 网络。除使用下面所述的方式之外，默认情况下，来自不同命名空间（项目）的 pod 并不能发送或者接收其它 pod 上的包和不同项目的服务。你可以使用这些特性在同一个集群内隔离开发者环境、测试环境，以及生产环境。但是，这样会导致 IP 地址和端口数量的激增，使得网络管理更加复杂。另外，容器是被设计为反复使用的，你应该在处理这种复杂性的工具上进行投入。在容器平台上比较受欢迎的工具是使用 软件定义网络 (SDN) 提供一个定义的网络集群，它允许跨不同集群的容器进行通讯。

8. 存储

容器即可被用于无状态应用，也可被用于有状态应用。保护外加的存储是保护有状态服务的一个关键要素。容器平台对多种受欢迎的存储提供了插件，包括网络文件系统（NFS）、AWS 弹性块存储（EBS）、GCE 持久磁盘、GlusterFS、iSCSI、 RADOS（Ceph）、Cinder 等等。

一个持久卷（PV）可以通过资源提供者支持的任何方式装载到一个主机上。提供者有不同的性能，而每个 PV 的访问模式被设置为特定的卷支持的特定模式。例如，NFS 能够支持多路客户端同时读/写，但是，一个特定的 NFS 的 PV 可以在服务器上被发布为只读模式。每个 PV 有它自己的一组反应特定 PV 性能的访问模式的描述，比如，ReadWriteOnce、ReadOnlyMany、以及 ReadWriteMany。

9. API 管理、终端安全、以及单点登录（SSO）

保护你的应用安全，包括管理应用、以及 API 的认证和授权。

Web SSO 能力是现代应用程序的一个关键部分。在构建它们的应用时，容器平台带来了开发者可以使用的多种容器化服务。

API 是微服务构成的应用程序的关键所在。这些应用程序有多个独立的 API 服务，这导致了终端服务数量的激增，它就需要额外的管理工具。推荐使用 API 管理工具。所有的 API 平台应该提供多种 API 认证和安全所需要的标准选项，这些选项既可以单独使用，也可以组合使用，以用于发布证书或者控制访问。

这些选项包括标准的 API key、应用 ID 和密钥对，以及 OAuth 2.0。

10. 在一个联合集群中的角色和访问管理

在 2016 年 7 月份，Kubernetes 1.3 引入了 Kubernetes 联合集群。这是一个令人兴奋的新特性之一，它是在 Kubernetes 上游、当前的 Kubernetes 1.6 beta 中引用的。联合是用于部署和访问跨多集群运行在公有云或企业数据中心的应用程序服务的。多个集群能够用于去实现应用程序的高可用性，应用程序可以跨多个可用区域，或者去启用部署公共管理，或者跨不同的供应商进行迁移，比如，AWS、Google Cloud、以及 Azure。

当管理联合集群时，你必须确保你的编配工具能够提供你所需要的跨不同部署平台的实例的安全性。一般来说，认证和授权是很关键的 —— 不论你的应用程序运行在什么地方，将数据安全可靠地传递给它们，以及管理跨集群的多租户应用程序。Kubernetes 扩展了联合集群，包括对联合的秘密数据、联合的命名空间、以及 Ingress objects 的支持。

选择一个容器平台

当然，它并不仅关乎安全。你需要提供一个你的开发者团队和运营团队有相关经验的容器平台。他们需要一个安全的、企业级的基于容器的应用平台，它能够同时满足开发者和运营者的需要，而且还能够提高操作效率和基础设施利用率。

想从 Daniel 在 欧盟开源峰会 上的 容器安全的十个层面 的演讲中学习更多知识吗？这个峰会已于 10 月 23 - 26 日在 Prague 举行。

关于作者

Daniel Oh；Microservives；Agile；Devops；Java Ee；Container；Openshift；Jboss；Evangelism

via: https://opensource.com/article/17/10/10-layers-container-security

作者：Daniel Oh 译者：qhwdw 校对：wxy

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

CGManager 是一个核心的特权守护进程，通过一个简单的 D-Bus API 管理你所有的 cgroup。它被设计用来处理嵌套的 LXC 容器以及接受无特权的请求，包括解析用户名称空间的 UID/GID。

组件

cgmanager

这个守护进程在宿主机上运行，​​将 cgroupfs 挂载到一个独立的挂载名称空间（所以它不能从宿主机上看到），绑定 /sys/fs/cgroup/cgmanager/sock 用于传入的 D-Bus 查询，并通常处理宿主机上直接运行的所有客户端。

cgmanager 既接受使用 D-Bus + SCM 凭证的身份验证请求，用于在命名空间之间转换 uid、gid 和 pid，也可以使用简单的 “unauthenticated”（只是初始的 ucred）D-Bus 来查询来自宿主机级别的查询。

cgproxy

你可能会在两种情况下看到这个守护进程运行。在宿主机上，如果你的内核老于 3.8（没有 pidns 连接支持）或处于容器中（只有 cgproxy 运行）。

cgproxy 本身并不做任何 cgroup 配置更改，而是如其名称所示，代理请求给主 cgmanager 进程。

这是必要的，所以一个进程可以直接使用 D-Bus（例如使用 dbus-send）与 /sys/fs/cgroup/cgmanager/sock 进行通信。

之后 cgproxy 将从该查询中得到 ucred，并对真正的 cgmanager 套接字进行身份验证的 SCM 查询，并通过 ucred 结构体传递参数，使它们能够正确地转换为 cgmanager 可以理解的宿主机命名空间 。

cgm

一个简单的命令行工具，与 D-Bus 服务通信，并允许你从命令行执行所有常见的 cgroup 操作。

通信协议

如上所述，cgmanager 和 cgproxy 使用 D-Bus。建议外部客户端（所以不要是 cgproxy）使用标准的 D-Bus API，不要试图实现 SCM creds 协议，因为它是不必要的，并且容易出错。

相反，只要简单假设与 /sys/fs/cgroup/cgmanager/sock 的通信总是正确的。

cgmanager API 仅在独立的 D-Bus 套接字上可用，cgmanager 本身不连接到系统总线，所以 cgmanager/cgproxy 不要求有运行中的 dbus 守护进程。

你可以在这里阅读更多关于 D-Bus API。

许可证

CGManager 是免费软件，大部分代码是根据 GNU LGPLv2.1+ 许可条款发布的，一些二进制文件是在 GNU GPLv2 许可下发布的。

该项目的默认许可证是 GNU LGPLv2.1+

支持

CGManager 的稳定版本支持依赖于 Linux 发行版以及它们自己承诺推出稳定修复和安全更新。

你可以从 Canonical Ltd 获得对 Ubuntu LTS 版本的 CGManager 的商业支持。

via: https://linuxcontainers.org/cgmanager/introduction/

作者：Canonical Ltd. 译者：geekpi 校对：wxy

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

当你正在创建 LXD 容器的时候，你希望它们能被预先配置好。例如在容器一启动就自动执行 apt update来安装一些软件包，或者运行一些命令。

这篇文章将讲述如何用 cloud-init 来对 LXD 容器进行进行早期初始化。

接下来，我们将创建一个包含cloud-init指令的LXD profile，然后启动一个新的容器来使用这个profile。

如何创建一个新的 LXD profile

查看已经存在的 profile：

$ lxc profile list
+---------|---------+
| NAME    | USED BY |
+---------|---------+
| default | 11      |
+---------|---------+

我们把名叫 default 的 profile 复制一份，然后在其内添加新的指令：

$ lxc profile copy default devprofile

$ lxc profile list
+------------|---------+
| NAME       | USED BY |
+------------|---------+
| default    | 11      |
+------------|---------+
| devprofile | 0       |
+------------|---------+

我们就得到了一个新的 profile： devprofile。下面是它的详情：

$ lxc profile show devprofile
config:
 environment.TZ: ""
description: Default LXD profile
devices:
 eth0:
 nictype: bridged
 parent: lxdbr0
 type: nic
 root:
 path: /
 pool: default
 type: disk
name: devprofile
used_by: []

注意这几个部分： config: 、 description: 、 devices: 、 name: 和 used_by:，当你修改这些内容的时候注意不要搞错缩进。（LCTT 译注：因为这些内容是 YAML 格式的，缩进是语法的一部分）

如何把 cloud-init 添加到 LXD profile 里

cloud-init 可以添加到 LXD profile 的 config 里。当这些指令将被传递给容器后，会在容器第一次启动的时候执行。

下面是用在示例中的指令：

 package_upgrade: true
 packages:
 - build-essential
 locale: es_ES.UTF-8
 timezone: Europe/Madrid
 runcmd:
 - [touch, /tmp/simos_was_here]

package_upgrade: true 是指当容器第一次被启动时，我们想要 cloud-init 运行 sudo apt upgrade。packages: 列出了我们想要自动安装的软件。然后我们设置了 locale 和 timezone。在 Ubuntu 容器的镜像里，root 用户默认的 locale 是 C.UTF-8，而 ubuntu 用户则是 en_US.UTF-8。此外，我们把时区设置为 Etc/UTC。最后，我们展示了如何使用 runcmd 来运行一个 Unix 命令。

我们需要关注如何将 cloud-init 指令插入 LXD profile。

我首选的方法是：

$ lxc profile edit devprofile

它会打开一个文本编辑器，以便你将指令粘贴进去。结果应该是这样的：

$ lxc profile show devprofile
config:
  environment.TZ: ""
  user.user-data: |
    #cloud-config
    package_upgrade: true
    packages:
      - build-essential
    locale: es_ES.UTF-8
    timezone: Europe/Madrid
    runcmd:
      - [touch, /tmp/simos_was_here]
description: Default LXD profile
devices:
  eth0:
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: devprofile
used_by: []

如何使用 LXD profile 启动一个容器

使用 profile devprofile 来启动一个新容器：

$ lxc launch --profile devprofile ubuntu:x mydev

然后访问该容器来查看我们的指令是否生效：

$ lxc exec mydev bash
root@mydev:~# ps ax
 PID TTY STAT TIME COMMAND
 1 ? Ss 0:00 /sbin/init
 ...
 427 ? Ss 0:00 /usr/bin/python3 /usr/bin/cloud-init modules --mode=f
 430 ? S 0:00 /bin/sh -c tee -a /var/log/cloud-init-output.log
 431 ? S 0:00 tee -a /var/log/cloud-init-output.log
 432 ? S 0:00 /usr/bin/apt-get --option=Dpkg::Options::=--force-con
 437 ? S 0:00 /usr/lib/apt/methods/http
 438 ? S 0:00 /usr/lib/apt/methods/http
 440 ? S 0:00 /usr/lib/apt/methods/gpgv
 570 ? Ss 0:00 bash
 624 ? S 0:00 /usr/lib/apt/methods/store
 625 ? R+ 0:00 ps ax
root@mydev:~#

如果我们连接得够快，通过 ps ax 将能够看到系统正在更新软件。我们可以从 /var/log/cloud-init-output.log 看到完整的日志：

Generating locales (this might take a while)...
 es_ES.UTF-8... done
Generation complete.

以上可以看出 locale 已经被更改了。root 用户还是保持默认的 C.UTF-8，只有非 root 用户 ubuntu 使用了新的locale 设置。

Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease
Get:2 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [102 kB]
Get:3 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB]

以上是安装软件包之前执行的 apt update。

The following packages will be upgraded:
 libdrm2 libseccomp2 squashfs-tools unattended-upgrades
4 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 211 kB of archives.

以上是在执行 package_upgrade: true 和安装软件包。

The following NEW packages will be installed:
 binutils build-essential cpp cpp-5 dpkg-dev fakeroot g++ g++-5 gcc gcc-5
 libalgorithm-diff-perl libalgorithm-diff-xs-perl libalgorithm-merge-perl

以上是我们安装 build-essential 软件包的指令。

runcmd 执行的结果如何？

root@mydev:~# ls -l /tmp/
total 1
-rw-r--r-- 1 root root 0 Jan 3 15:23 simos_was_here
root@mydev:~#

可见它已经生效了！

结论

当我们启动 LXD 容器的时候，我们常常需要默认启用一些配置，并且希望能够避免重复工作。通常解决这个问题的方法是创建 LXD profile，然后把需要的配置添加进去。最后，当我们启动新的容器时，只需要应用该 LXD profile 即可。

via: https://blog.simos.info/how-to-preconfigure-lxd-containers-with-cloud-init/

作者：Simos Xenitellis 译者：kaneg 校对：wxy

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

我们在过去的文章中讨论了一些 containerd 的不同特性，它是如何设计的，以及随着时间推移已经修复的一些问题。containerd 被用于 Docker、Kubernetes CRI、以及一些其它的项目，在这些平台中事实上都使用了 containerd，而许多人并不知道 containerd 存在于这些平台之中，这篇文章就是为这些人所写的。我将来会写更多的关于 containerd 的设计以及特性集方面的文章，但是现在，让我们从它的基础知识开始。

我认为容器生态系统有时候可能很复杂。尤其是我们所使用的术语。它是什么？一个运行时，还是别的？一个运行时 … containerd（它的发音是 “container-dee”）正如它的名字，它是一个容器守护进程，而不是一些人忽悠我的“ 收集 contain 迷 nerd ”。它最初是作为 OCI 运行时（就像 runc 一样）的集成点而构建的，在过去的六个月中它增加了许多特性，使其达到了像 Docker 这样的现代容器平台以及像 Kubernetes 这样的编排平台的需求。

那么，你使用 containerd 能去做些什么呢？你可以拥有推送或拉取功能以及镜像管理。可以拥有容器生命周期 API 去创建、运行、以及管理容器和它们的任务。一个完整的专门用于快照管理的 API，以及一个其所依赖的开放治理的项目。如果你需要去构建一个容器平台，基本上你不需要去处理任何底层操作系统细节方面的事情。我认为关于 containerd 中最重要的部分是，它有一个版本化的并且有 bug 修复和安全补丁的稳定 API。

由于在内核中没有一个 Linux 容器这样的东西，因此容器是多种内核特性捆绑在一起而成的，当你构建一个大型平台或者分布式系统时，你需要在你的管理代码和系统调用之间构建一个抽象层，然后将这些特性捆绑粘接在一起去运行一个容器。而这个抽象层就是 containerd 的所在之处。它为稳定类型的平台层提供了一个客户端，这样平台可以构建在顶部而无需进入到内核级。因此，可以让使用容器、任务、和快照类型的工作相比通过管理调用去 clone() 或者 mount() 要友好的多。与灵活性相平衡，直接与运行时或者宿主机交互，这些对象避免了常规的高级抽象所带来的性能牺牲。结果是简单的任务很容易完成，而困难的任务也变得更有可能完成。

containerd 被设计用于 Docker 和 Kubernetes、以及想去抽象出系统调用或者在 Linux、Windows、Solaris 以及其它的操作系统上特定的功能去运行容器的其它容器系统。考虑到这些用户的想法，我们希望确保 containerd 只拥有它们所需要的东西，而没有它们不希望的东西。事实上这是不太可能的，但是至少我们想去尝试一下。虽然网络不在 containerd 的范围之内，它并不能做成让高级系统可以完全控制的东西。原因是，当你构建一个分布式系统时，网络是非常中心的地方。现在，对于 SDN 和服务发现，相比于在 Linux 上抽象出 netlink 调用，网络是更特殊的平台。大多数新的网络都是基于路由的，并且每次一个新的容器被创建或者删除时，都会请求更新路由表。服务发现、DNS 等等都需要及时被通知到这些改变。如果在 containerd 中添加对网络的管理，为了能够支持不同的网络接口、钩子、以及集成点，将会在 containerd 中增加很大的一块代码。而我们的选择是，在 containerd 中做一个健壮的事件系统，以便于多个消费者可以去订阅它们所关心的事件。我们也公开发布了一个 任务 API，它可以让用户去创建一个运行任务，也可以在一个容器的网络命名空间中添加一个接口，以及在一个容器的生命周期中的任何时候，无需复杂的钩子来启用容器的进程。

在过去的几个月中另一个添加到 containerd 中的领域是完整的存储，以及支持 OCI 和 Docker 镜像格式的分布式系统。有了一个跨 containerd API 的完整的目录地址存储系统，它不仅适用于镜像，也适用于元数据、检查点、以及附加到容器的任何数据。

我们也花时间去 重新考虑如何使用 “图驱动” 工作。这些是叠加的或者允许镜像分层的块级文件系统，可以使你执行的构建更加高效。当我们添加对 devicemapper 的支持时， 图驱动 graphdrivers 最初是由 Solomon 和我写的。Docker 在那个时候仅支持 AUFS，因此我们在叠加文件系统之后，对图驱动进行了建模。但是，做一个像 devicemapper/lvm 这样的块级文件系统，就如同一个堆叠文件系统一样，从长远来看是非常困难的。这些接口必须基于时间的推移进行扩展，以支持我们最初认为并不需要的那些不同的特性。对于 containerd，我们使用了一个不同的方法，像快照一样做一个堆叠文件系统而不是相反。这样做起来更容易，因为堆叠文件系统比起像 BTRFS、ZFS 以及 devicemapper 这样的快照文件系统提供了更好的灵活性。因为这些文件系统没有严格的父/子关系。这有助于我们去构建出 快照的一个小型接口，同时还能满足 构建者 的要求，还能减少了需要的代码数量，从长远来看这样更易于维护。

你可以在 Stephen Day 2017/12/7 在 KubeCon SIG Node 上的演讲找到更多关于 containerd 的架构方面的详细资料。

除了在 1.0 代码库中的技术和设计上的更改之外，我们也将 containerd 管理模式从长期 BDFL 模式转换为技术委员会，为社区提供一个独立的可信任的第三方资源。

via: https://blog.docker.com/2017/12/containerd-ga-features-2/

作者：Michael Crosby 译者：qhwdw 校对：wxy

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

我最近在 docker-library/php 仓库中关闭了大量问题，最老的（并且是最长的）讨论之一是关于安装编译扩展的依赖关系，我写了一个中等篇幅的评论解释了我如何用常规的方式为我想要的软件进行 Docker 化的。

我要在这里复制大部分的评论内容，或许扩展一点点，以便有一个更好的/更干净的链接！

我第一步是编写 Dockerfile 的原始版本：下载源码，运行 ./configure && make 等，清理。然后我尝试构建我的原始版本，并希望在这过程中看到错误消息。（对，真的！）

错误信息通常以 error: could not find "xyz.h" 或 error: libxyz development headers not found 的形式出现。

如果我在 Debian 中构建，我会输入 https://packages.debian.org/file:xyz.h（用错误信息中头文件的名称替换 “xyz.h”），或者在谷歌中搜索像 “xyz.h debian” 这样的东西，找出我需要的包的名称。

如果我在 Alpine 中构建，我将使用 https://pkgs.alpinelinux.org/contents 进行类似的搜索。

“libxyz development headers” 在某种程度上也是一样的，但是根据我的经验，对于这些用 Google 对开发者来说效果更好，因为不同的发行版和项目会以不同的名字来调用这些开发包，所以有时候更难确切的知道哪一个是“正确”的。

当我得到包名后，我将这个包名称添加到我的 Dockerfile 中，清理之后，然后重复操作。最终通常会构建成功。偶尔我发现某些库不在 Debian 或 Alpine 中，或者是不够新的，由此我必须从源码构建它，但这些情况在我的经验中很少见 —— 因人而异。

我还会经常查看 Debian（通过 https://sources.debian.org）或Alpine（通过https://git.alpinelinux.org/cgit/aports/tree）我要编译的软件包源码，特别关注 Build-Depends（如 php7.0=7.0.26-1 的 debian/control 文件）以及/或者 makedepends （如 php7 的 APKBUILD 文件）用于包名线索。

就我个人而言，我觉得这种侦探工作很有趣，也很有收获，但我意识到我可能是一个独特的生物。我偶尔使用的另一个技术是看是否有人已经 Docker 化了我想要的东西，这样我可以直接从他们的 Dockerfile 中知道我需要安装的东西。

对于特定的 PHP 扩展，几乎总是有人已经想出对于这个或那个模块需要的依赖，而我所要做的就是做一些轻量的工作找出它们。

不管怎样，这就是我的方法！希望这个有帮助，玩得愉快！

via: https://tianon.github.io/post/2017/12/26/dockerize-compiled-software.html

作者：Tianon Gravi 译者：geekpi 校对：wxy

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

在我刚开始学习 Kubernetes（大约是一年半以前吧？）时，我真的不明白为什么应该去关注它。

在我使用 Kubernetes 全职工作了三个多月后，我才逐渐明白了为什么我应该使用它。（我距离成为一个 Kubernetes 专家还很远！）希望这篇文章对你理解 Kubernetes 能做什么会有帮助！

我将尝试去解释我对 Kubernetes 感兴趣的一些原因，而不去使用 “ 原生云 cloud native ”、“ 编排系统 orchestration ”、“ 容器 container ”，或者任何 Kubernetes 专用的术语 :)。我去解释的这些观点主要来自一位 Kubernetes 操作者/基础设施工程师，因为，我现在的工作就是去配置 Kubernetes 和让它工作的更好。

我不会去尝试解决一些如 “你应该在你的生产系统中使用 Kubernetes 吗？”这样的问题。那是非常复杂的问题。（不仅是因为“生产系统”根据你的用途而总是有不同的要求）

Kubernetes 可以让你无需设置一台新的服务器即可在生产系统中运行代码

我首次被说教使用 Kubernetes 是与我的伙伴 Kamal 的下面的谈话：

大致是这样的：

• Kamal： 使用 Kubernetes 你可以通过一条命令就能设置一台新的服务器。
• Julia： 我觉得不太可能吧。
• Kamal： 像这样，你写一个配置文件，然后应用它，这时候，你就在生产系统中运行了一个 HTTP 服务。
• Julia： 但是，现在我需要去创建一个新的 AWS 实例，明确地写一个 Puppet 清单，设置服务发现，配置负载均衡，配置我们的部署软件，并且确保 DNS 正常工作，如果没有什么问题的话，至少在 4 小时后才能投入使用。
• Kamal: 是的，使用 Kubernetes 你不需要做那么多事情，你可以在 5 分钟内设置一台新的 HTTP 服务，并且它将自动运行。只要你的集群中有空闲的资源它就能正常工作！
• Julia: 这儿一定是一个“坑”。

这里有一种陷阱，设置一个生产用 Kubernetes 集群（在我的经险中）确实并不容易。（查看 Kubernetes 艰难之旅 中去开始使用时有哪些复杂的东西）但是，我们现在并不深入讨论它。

因此，Kubernetes 第一个很酷的事情是，它可能使那些想在生产系统中部署新开发的软件的方式变得更容易。那是很酷的事，而且它真的是这样，因此，一旦你使用一个运作中的 Kubernetes 集群，你真的可以仅使用一个配置文件就在生产系统中设置一台 HTTP 服务（在 5 分钟内运行这个应用程序，设置一个负载均衡，给它一个 DNS 名字，等等）。看起来真的很有趣。

对于运行在生产系统中的代码，Kubernetes 可以提供更好的可见性和可管理性

在我看来，在理解 etcd 之前，你可能不会理解 Kubernetes 的。因此，让我们先讨论 etcd！

想像一下，如果现在我这样问你，“告诉我你运行在生产系统中的每个应用程序，它运行在哪台主机上？它是否状态很好？是否为它分配了一个 DNS 名字？”我并不知道这些，但是，我可能需要到很多不同的地方去查询来回答这些问题，并且，我需要花很长的时间才能搞定。我现在可以很确定地说不需要查询，仅一个 API 就可以搞定它们。

在 Kubernetes 中，你的集群的所有状态 – 运行中的应用程序 (“pod”)、节点、DNS 名字、 cron 任务、 等等 —— 都保存在一个单一的数据库中（etcd）。每个 Kubernetes 组件是无状态的，并且基本是通过下列方式工作的：

• 从 etcd 中读取状态（比如，“分配给节点 1 的 pod 列表”）
• 产生变化（比如，“在节点 1 上运行 pod A”）
• 更新 etcd 中的状态（比如，“设置 pod A 的状态为 ‘running’”）

这意味着，如果你想去回答诸如 “在那个可用区中有多少台运行着 nginx 的 pod？” 这样的问题时，你可以通过查询一个统一的 API（Kubernetes API）去回答它。并且，你可以在每个其它 Kubernetes 组件上运行那个 API 去进行同样的访问。

这也意味着，你可以很容易地去管理每个运行在 Kubernetes 中的任何东西。比如说，如果你想要：

• 部署实现一个复杂的定制的部署策略（部署一个东西，等待 2 分钟，部署 5 个以上，等待 3.7 分钟，等等）
• 每当推送到 github 上一个分支，自动化 启动一个新的 web 服务器
• 监视所有你的运行的应用程序，确保它们有一个合理的内存使用限制。

这些你只需要写一个程序与 Kubernetes API（“controller”）通讯就可以了。

另一个关于 Kubernetes API 的令人激动的事情是，你不会局限于 Kubernetes 所提供的现有功能！如果对于你要部署/创建/监视的软件有你自己的方案，那么，你可以使用 Kubernetes API 去写一些代码去达到你的目的！它可以让你做到你想做的任何事情。

即便每个 Kubernetes 组件都“挂了”，你的代码将仍然保持运行

关于 Kubernetes 我（在各种博客文章中 :)）承诺的一件事情是，“如果 Kubernetes API 服务和其它组件‘挂了’也没事，你的代码将一直保持运行状态”。我认为理论上这听起来很酷，但是我不确定它是否真是这样的。

到目前为止，这似乎是真的！

我已经断开了一些正在运行的 etcd，发生了这些情况：

1. 所有的代码继续保持运行状态
2. 不能做 新的 事情（你不能部署新的代码或者生成变更，cron 作业将停止工作）
3. 当它恢复时，集群将赶上这期间它错过的内容

这样做意味着如果 etcd 宕掉，并且你的应用程序的其中之一崩溃或者发生其它事情，在 etcd 恢复之前，它不能够恢复。

Kubernetes 的设计对 bug 很有弹性

与任何软件一样，Kubernetes 也会有 bug。例如，到目前为止，我们的集群控制管理器有内存泄漏，并且，调度器经常崩溃。bug 当然不好，但是，我发现 Kubernetes 的设计可以帮助减轻它的许多核心组件中的错误的影响。

如果你重启动任何组件，将会发生：

• 从 etcd 中读取所有的与它相关的状态
• 基于那些状态（调度 pod、回收完成的 pod、调度 cron 作业、按需部署等等），它会去做那些它认为必须要做的事情

因为，所有的组件并不会在内存中保持状态，你在任何时候都可以重启它们，这可以帮助你减轻各种 bug 的影响。

例如，如果在你的控制管理器中有内存泄露。因为，控制管理器是无状态的，你可以每小时定期去重启它，或者，在感觉到可能导致任何不一致的问题发生时重启它。又或者，在调度器中遇到了一个 bug，它有时忘记了某个 pod，从来不去调度它们。你可以每隔 10 分钟来重启调度器来缓减这种情况。（我们并不会这么做，而是去修复这个 bug，但是，你可以这样做 :））

因此，我觉得即使在它的核心组件中有 bug，我仍然可以信任 Kubernetes 的设计可以让我确保集群状态的一致性。并且，总在来说，随着时间的推移软件质量会提高。唯一你必须去操作的有状态的东西就是 etcd。

不用过多地讨论“状态”这个东西 —— 而我认为在 Kubernetes 中很酷的一件事情是，唯一需要去做备份/恢复计划的东西是 etcd （除非为你的 pod 使用了持久化存储的卷）。我认为这样可以使 Kubernetes 运维比你想的更容易一些。

在 Kubernetes 之上实现新的分布式系统是非常容易的

假设你想去实现一个分布式 cron 作业调度系统！从零开始做工作量非常大。但是，在 Kubernetes 里面实现一个分布式 cron 作业调度系统是非常容易的！（仍然没那么简单，毕竟它是一个分布式系统）

我第一次读到 Kubernetes 的 cron 作业控制器的代码时，我对它是如此的简单感到由衷高兴。去读读看，其主要的逻辑大约是 400 行的 Go 代码。去读它吧！ => cronjob\_controller.go <=

cron 作业控制器基本上做的是：

• 每 10 秒钟：

  • 列出所有已存在的 cron 作业
  • 检查是否有需要现在去运行的任务
  • 如果有，创建一个新的作业对象去调度，并通过其它的 Kubernetes 控制器实际运行它
  • 清理已完成的作业
  • 重复以上工作

Kubernetes 模型是很受限制的（它有定义在 etcd 中的资源模式，控制器读取这个资源并更新 etcd），我认为这种相关的固有的/受限制的模型，可以使它更容易地在 Kubernetes 框架中开发你自己的分布式系统。

Kamal 给我说的是 “Kubernetes 是一个写你自己的分布式系统的很好的平台” ，而不是“ Kubernetes 是一个你可以使用的分布式系统”，并且，我觉得它真的很有意思。他做了一个 为你推送到 GitHub 的每个分支运行一个 HTTP 服务的系统 的原型。这花了他一个周末的时间，大约 800 行 Go 代码，我认为它真不可思议！

Kubernetes 可以使你做一些非常神奇的事情（但并不容易）

我一开始就说 “kubernetes 可以让你做一些很神奇的事情，你可以用一个配置文件来做这么多的基础设施，它太神奇了”。这是真的！

为什么说 “Kubernetes 并不容易”呢？是因为 Kubernetes 有很多部分，学习怎么去成功地运营一个高可用的 Kubernetes 集群要做很多的工作。就像我发现它给我了许多抽象的东西，我需要去理解这些抽象的东西才能调试问题和正确地配置它们。我喜欢学习新东西，因此，它并不会使我发狂或者生气，但是我认为了解这一点很重要 :）

对于 “我不能仅依靠抽象概念” 的一个具体的例子是，我努力学习了许多 Linux 上网络是如何工作的，才让我对设置 Kubernetes 网络稍有信心，这比我以前学过的关于网络的知识要多很多。这种方式很有意思但是非常费时间。在以后的某个时间，我或许写更多的关于设置 Kubernetes 网络的困难/有趣的事情。

或者，为了成功设置我的 Kubernetes CA，我写了一篇 2000 字的博客文章，述及了我不得不学习 Kubernetes 不同方式的 CA 的各种细节。

我觉得，像 GKE （Google 的 Kubernetes 产品) 这样的一些监管的 Kubernetes 的系统可能更简单，因为，他们为你做了许多的决定，但是，我没有尝试过它们。

via: https://jvns.ca/blog/2017/10/05/reasons-kubernetes-is-cool/

作者：Julia Evans 译者：qhwdw 校对：wxy

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