mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-02-25 00:50:15 +08:00
MjSeven
GitHub
commit
b1d8d7660b
@ -1,153 +1,141 @@
|
||||
# 最小权限的容器协调器
|
||||
最小权限的容器编排
|
||||
================
|
||||
|
||||
|
||||
Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器，必须有一个关键的能力：一个容器协调器。
|
||||
Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器，必须有一个关键的能力：一个容器编排器。
|
||||
|
||||
|
||||
|
||||
对于关键的集群化以及计划的任务，协调器是起重大作用的，比如：
|
||||
对于关键的集群化以及计划的任务，编排器是起重大作用的，比如：
|
||||
|
||||
* 管理容器计划和资源分配。
|
||||
|
||||
* 支持服务发现和无缝（hitless）应用程序部署。
|
||||
|
||||
* 支持服务发现和无缝的应用程序部署。
|
||||
* 分配应用程序运行必需的资源。
|
||||
|
||||
不幸的是，在这种环境下，协调器的分布式特性和资源的短暂性使得确保协调器的安全是一个极具挑战性的任务。在这篇文章中，我们将讨论容器协调器安全模型中没有考虑到的、但是很重要的方面的详细情况，以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式，去克服这些问题。
|
||||
不幸的是，在这种环境下，编排器的分布式特性和资源的短暂性使得确保编排器的安全是一个极具挑战性的任务。在这篇文章中，我们将讨论容器编排器安全模型中没有考虑到的、但是很重要的这方面的详细情况，以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式，去克服这些问题。
|
||||
|
||||
诱因和威胁模型
|
||||
============================================================
|
||||
### 诱因和威胁模型
|
||||
|
||||
使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的协调器。为达到这个目标，我们部署了第一个在我们心目中认为的最小权限原则设计的容器协调器。
|
||||
使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的编排器。为达到这个目标，我们部署了第一个在我们心目中认为的以最小权限原则设计的容器编排器。
|
||||
|
||||
在计算机科学中，一个分布式系统所要求的最小权限原则是，系统中的每个参与着仅仅能访问它正当目的所需要的信息和资源。不是更多，也不是更少。
|
||||
在计算机科学中，一个分布式系统所要求的最小权限原则是，系统中的每个参与者仅仅能访问它正当目的所需要的信息和资源。不是更多，也不是更少。
|
||||
|
||||
> #### “一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”
|
||||
> “一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”
|
||||
|
||||
#### 最小权限原则
|
||||
|
||||
在一个 Docker 企业版集群中的每个节点分配的角色：既不是管理者（manager），也不是工人（worker）。这些角色为节点定义了一个很粗粒度的权限级别：管理和运行各自的任务。尽管如此，不用理会它的内置的角色，通过使用加密的方式，来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是，防止大多数的复杂的攻击者模式：攻击者控制底层通讯网络，或者甚至是攻陷的集群节点，确保集群安全变得更容易了。
|
||||
在一个 Docker 企业版集群中的每个节点分配的角色：既不是管理者（manager），也不是工人（worker）。这些角色为节点定义了一个很粗粒度的权限级别：分别进行管理和任务执行。尽管如此，不用理会它的角色，通过使用加密的方式，来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是，确保集群安全变得更容易了，甚至可以防止大多数的有经验的攻击者模式：攻击者控制了底层通讯网络，或者甚至攻陷了集群节点。
|
||||
|
||||
# 内核缺省安全
|
||||
### 内核缺省安全
|
||||
|
||||
这是一个很老的安全最大化状态：如果它不是缺省的，没有一个使用它。Docker Swarm 模式将内核缺省安全这一概念融入了内核，并且使用这一机制去解决协调器生命周期中三个很难的并且很重要的部分：
|
||||
这是一个很老的安全最大化状态：如果它不是缺省的，就没人用它。Docker Swarm 模式将缺省安全这一概念融入了核心，并且使用这一机制去解决编排器生命周期中三个很难并且很重要的部分：
|
||||
|
||||
1. 可信引导和节点引入。
|
||||
|
||||
2. 节点身份发布和管理。
|
||||
3. 认证、授权和加密的信息存储和传播。
|
||||
|
||||
3. 经过认证、授权、和加密的信息存储和传播。
|
||||
我们来分别看一下这三个部分：
|
||||
|
||||
我们来分别看一下这三个部分
|
||||
|
||||
### 可信引导和节点引入
|
||||
#### 可信引导和节点引入
|
||||
|
||||
确保集群安全的第一步，没有别的，就是严格控制成员和身份。管理员不能依赖它们节点的身份，并且在节点之间强制实行绝对的负载隔离。这意味着，未授权的节点不能允许加入到集群中，并且，已经是集群一部分的节点不能改变身份，突然去伪装成另一个节点。
|
||||
|
||||
为解决这种情况，通过 Docker 企业版 Swarm 模式管理的节点，维护了健壮的、不可改变的身份。期望的特性是，通过使用两种关键的构建块去保证加密：
|
||||
|
||||
1. 为集群成员使用安全加入令牌。
|
||||
|
||||
1. 为集群成员使用<ruby>安全加入令牌<rt>Secure join token</rt></ruby>。
|
||||
2. 从一个集中化的认证机构发行的内嵌唯一身份的证书。
|
||||
|
||||
### 加入 Swarm
|
||||
##### 加入 Swarm
|
||||
|
||||
去安全加入 Swarm，需要这个节点的令牌拷贝。在集群内的每个操作角色中，令牌是独一无二的 — 那里现在有两种类型的节点：工人（workers）和管理者（managers）。由于这种分隔，拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一的方式是通过 swarm 的管理 API，去向集群管理者请求一个特殊的令牌。
|
||||
要加入 Swarm，节点需要一份<ruby>安全加入令牌<rt>Secure join token</rt></ruby>的副本。在集群内的每个操作角色的令牌都是独一无二的 —— 现在有两种类型的节点：工人（workers）和管理者（managers）。由于这种区分，拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一得到这个特殊令牌的方式是通过 swarm 的管理 API 去向集群管理者请求一个。
|
||||
|
||||
令牌是安全的并且是随机生成的，它也有一个使得令牌漏洞更容易去检测的特殊语法：一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是，即便发现一个漏洞，令牌也可以很容易去更新，并且，推荐你经常去更新它们 — 特别是，在一段时间中你的集群不进行扩大的情况下。
|
||||
令牌是安全的并且是随机生成的，它还有一个使得令牌泄露更容易被检测到的特殊语法：一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是，即便发现一个泄露，令牌也可以很容易去更新，并且，推荐你经常去更新它们 —— 特别是，在一段时间中你的集群不进行扩大的情况下。
|
||||
|
||||
|
||||
|
||||
### 引导信任
|
||||
##### 引导信任
|
||||
|
||||
作为它的身份标识创建的一部分，一个新的节点将向任意一个网络管理者请求发布一个新的身份。但是，在我们下面的威胁模型中，所有的通讯可以被一个第三方拦截。这种请求存在的问题是：一个节点怎么知道与它进行对话的对方是合法的管理者？
|
||||
|
||||
|
||||
|
||||
幸运的是，Docker 有一个内置机制可以避免这种情况。加入令牌，它被主机用于加入 Swarm，包含一个根 CA 证书的哈希串。所以，主机可以使用单向 TLS，并且使用这个哈希串去验证它加入的 Swarm 是否正确：如果管理者持有的证书没有被正确的 CA 哈希串签名，节点就知道它不可信任。
|
||||
幸运的是，Docker 有一个内置机制可以避免这种情况。这个加入令牌被主机用于加入 Swarm，包含了一个根 CA 证书的哈希串。所以，主机可以使用单向 TLS，并且使用这个哈希串去验证它加入的 Swarm 是否正确：如果管理者持有的证书没有被正确的 CA 哈希串签名，节点就知道它不可信任。
|
||||
|
||||
### 节点身份发布和管理
|
||||
#### 节点身份发布和管理
|
||||
|
||||
在一个 Swarm 中，身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现中，证书的私钥被绝对限制到主机的原始位置。尤其是，管理者不能访问除了它自己的私钥以外的任何一个私钥。
|
||||
在一个 Swarm 中，身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现形式中，证书的私钥被绝对限制在主机的原始位置。尤其是，管理者不能访问除了它自己的私钥以外的任何一个私钥。
|
||||
|
||||
### 身份发布
|
||||
##### 身份发布
|
||||
|
||||
去接收它们的证书而无需共享它们的私钥，新的主机通过发布一个证书签名请求（CSR）来开始，管理者收到证书签名请求之后，转换成一个证书。这个证书成为这个新的主机的身份标识，使这个节点成为 Swarm 的一个完全合格成员！
|
||||
要接收它们的证书而无需共享它们的私钥，新的主机通过发布一个证书签名请求（CSR）来开始，管理者收到证书签名请求之后，转换成一个证书。这个证书成为这个新的主机的身份标识，使这个节点成为 Swarm 的一个完全合格成员！
|
||||
|
||||
####
|
||||
|
||||
|
||||
当和安全引导机制一起使用时，发行身份标识的这个机制去加入节点是缺省安全的：所有的通讯部分都是经过认证的、授权的，并且非敏感信息从来都不会以明文方式进行交换。
|
||||
当和安全引导机制一起使用时，发行身份标识的这个机制来加入节点是缺省安全的：所有的通讯部分都是经过认证的、授权的，并且非敏感信息从来都不会以明文方式进行交换。
|
||||
|
||||
### 身份标识延期
|
||||
##### 身份标识延期
|
||||
|
||||
尽管如此，给一个 Swarm 中安全地加入节点，仅仅是 “故事” 的一部分。为降低证书的漏洞或者失窃造成的影响，并且移除管理 CRL 列表的复杂性，Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期，但是，也可以配置为一个小时后即刻过期！
|
||||
尽管如此，给一个 Swarm 中安全地加入节点，仅仅是 “故事” 的一部分。为降低证书的泄露或者失窃造成的影响，并且移除管理 CRL 列表的复杂性，Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期，但是，也可以配置为一个小时后即刻过期！
|
||||
|
||||
|
||||
|
||||
这个较短的证书过期时间，意味着不能手动去处理证书更新，所以，通常会使用一个 PKI 系统。对于 Swarm，所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单：使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者，一个 Swarm 节点定期生成一个新的公钥/私钥密钥对并且用相关的 CSR 去签名发送，创建一个维持相同身份标识的完整的新证书。
|
||||
较短的证书过期时间意味着不能手动去处理证书更新，所以，通常会使用一个 PKI 系统。对于 Swarm，所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单：使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者，一个 Swarm 节点定期生成一个新的公钥/私钥密钥对，并且用相关的 CSR 去签名发送，创建一个维持相同身份标识的完整的新证书。
|
||||
|
||||
### 经过认证、授权、和加密的信息存储和传播。
|
||||
#### 经过认证、授权、和加密的信息存储和传播。
|
||||
|
||||
在一个正常的 Swarm 的操作中，发送到工人（worker）节点去运行的关于任务的信息。这里不仅仅包含将被一个节点运行的容器的信息；也包含那个容器运行所必需的资源的所有的信息，包括敏感的秘密，比如，私钥、密码、和 API 令牌。
|
||||
在一个正常的 Swarm 的操作中，关于任务的信息被发送给去运行的工人（worker）节点。这里不仅仅包含将被一个节点运行的容器的信息；也包含那个容器运行所必需的资源的所有信息，包括敏感的机密信息，比如，私钥、密码和 API 令牌。
|
||||
|
||||
### 传输安全
|
||||
##### 传输安全
|
||||
|
||||
事实上，参与 Swarm 的每个节点都拥有一个独一无二的 X509 格式的证书，因此，节点之间的通讯安全是没有问题的：节点使用它们各自的证书，与另一个连接方进行相互认证、继承机密、真实性、和 TLS 的完整性。
|
||||
|
||||
|
||||
|
||||
关于 Swarm 模式的一个有趣的细节是，本质上它是使用了一个推送模式：仅管理者被允许去发送信息到工人们（workers）— 显著降低了暴露在低权限工人节点面前的管理者节点的攻击面。
|
||||
关于 Swarm 模式的一个有趣的细节是，本质上它是使用了一个推送模式：仅管理者被允许去发送信息到工人们（workers）—— 显著降低了暴露在低权限的工人节点面前的管理者节点的攻击面。
|
||||
|
||||
### 将负载严格隔离进安全区域
|
||||
##### 将负载严格隔离进安全区域
|
||||
|
||||
管理者节点的其中一个责任是，去决定发送到每个工人（worker）节点的任务是什么。管理者节点使用多种策略去做这个决定；根据每个节点和每个负载的特性，去跨 Swarm 去安排负载。
|
||||
|
||||
在使用 Swarm 模式的 Docker 企业版中，管理者通过使用附加到每个单个节点标识上的安全标签，去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起，以限制敏感负载暴露，以及使相关秘密信息更安全。
|
||||
在使用 Swarm 模式的 Docker 企业版中，管理者节点通过使用附加到每个单个节点标识上的安全标签，去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起，以限制敏感负载暴露，以及使相关机密信息更安全。
|
||||
|
||||
|
||||
|
||||
### 安全分发秘密
|
||||
##### 安全分发机密
|
||||
|
||||
除了加快身份标识发布过程之外，管理者节点还有存储和分发工人节点所需要的任何资源的任务。像任何其它类型的资源一样处理秘密，并且基于安全的 mTLS 连接，从管理者推送到工人节点。
|
||||
除了加快身份标识发布过程之外，管理者节点还有存储和分发工人节点所需要的任何资源的任务。机密信息像任何其它类型的资源一样处理，并且基于安全的 mTLS 连接，从管理者推送到工人节点。
|
||||
|
||||
|
||||
|
||||
在主机上，Docker 企业版能确保秘密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露秘密给一个容器，确保秘密总是保存在内存中，并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全，比如，[在环境变量中存储它们][12]。一旦这个任务完成，这个秘密将永远消失。
|
||||
在主机上，Docker 企业版能确保机密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露机密给一个容器，确保机密总是保存在内存中，并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全，比如，[在环境变量中存储它们][12]。一旦这个任务完成，这个机密将永远消失。
|
||||
|
||||
### 存储秘密
|
||||
##### 存储机密
|
||||
|
||||
在管理者主机上的秘密总是加密静止的。缺省情况下，加密这些秘密的密钥（被称为数据加密密钥，DEK）是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。
|
||||
在管理者主机上的机密总是保持加密的。缺省情况下，加密这些机密的密钥（被称为数据加密密钥，DEK）是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。
|
||||
|
||||
但是，如果你运行一个生产集群，我们推荐你启用自动锁定模式。当自动锁定模式启用后，一个重新更新过的 DEK 被一个独立的加密密钥加密（KEK）。这个密钥从不被存储在集群中；管理者有责任将它存储在一个安全可靠的地方，并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。
|
||||
但是，如果你运行一个生产集群，我们推荐你启用自动锁定模式。当自动锁定模式启用后，一个重新更新过的 DEK 被一个独立的加密密钥的密钥（KEK）所加密。这个密钥从不被存储在集群中；管理者有责任将它存储在一个安全可靠的地方，并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。
|
||||
|
||||
根据 Raft 故障容错一致性算法，Swarm 模式支持多个管理者。在这个场景中，无缝扩展了秘密存储的安全性。每个管理者主机除了共享密钥之外 ，还有一个唯一的磁盘加密密钥。幸运的是，Raft 日志在磁盘上也是加密的，并且，在自动锁定模式下，没有 KEK 同样是不可访问的。
|
||||
根据 Raft 故障容错一致性算法，Swarm 模式支持多个管理者。在这个场景中，无缝扩展了机密存储的安全性。每个管理者主机除了共享密钥之外，还有一个唯一的磁盘加密密钥。幸运的是，Raft 日志在磁盘上也是加密的，并且，在自动锁定模式下，没有 KEK 同样是不可访问的。
|
||||
|
||||
### 当一个节点被攻陷后发生了什么？
|
||||
#### 当一个节点被攻陷后发生了什么？
|
||||
|
||||
|
||||
|
||||
在传统的协调器中，挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式，恢复它就像运行一个 Docker 节点的 rm 命令一样容易。这是从集群中删除一个受影响的节点，而 Docker 将去处理剩下的事情，即，重新均衡负载，并且确保其它的主机已经知道，而不会去与受影响的节点通讯。
|
||||
在传统的编排器中，挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式，恢复它就像运行一个 Docker 节点的 `rm` 命令一样容易。这是从集群中删除一个受影响的节点，而 Docker 将去处理剩下的事情，即，重新均衡负载，并且确保其它的主机已经知道，而不会去与受影响的节点通讯。
|
||||
|
||||
正如我们看到的那样，感谢最小权限协调器，甚至是，如果攻击者在主机上持续活动，它们将被从剩余的网络上切断。主机的证书 — 它的身份标识 — 被列入黑名单，因此，管理者也不能有效访问它。
|
||||
正如我们看到的那样，感谢最小权限的编排器，甚至是，如果攻击者在主机上持续活动，它们将被从剩余的网络上切断。主机的证书 —— 它的身份标识 —— 被列入黑名单，因此，管理者也不能有效访问它。
|
||||
|
||||
# 结论
|
||||
### 结论
|
||||
|
||||
使用 Swarm 模式的 Docker 企业版，在缺省情况下确保了协调器的所有关键区域的安全：
|
||||
使用 Swarm 模式的 Docker 企业版，在缺省情况下确保了编排器的所有关键区域的安全：
|
||||
|
||||
* 加入集群。阻止恶意节点加入到集群。
|
||||
|
||||
* 安排主机进入安全区域。阻止攻击者的横向移动。
|
||||
|
||||
* 把主机分组为安全区域。阻止攻击者的横向移动。
|
||||
* 安排任务。任务将仅被委派到允许的节点。
|
||||
|
||||
* 分配资源。恶意节点不能 “盗取” 其它的负载或者资源。
|
||||
|
||||
* 存储秘密。从不明文保存并且从不写入到工人节点的磁盘上。
|
||||
|
||||
* 存储机密。从不明文保存并且从不写入到工人节点的磁盘上。
|
||||
* 与工人节点的通讯。使用相互认证的 TLS 加密。
|
||||
|
||||
因为 Swarm 模式持续提升，Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是：如果一个管理者被攻陷了，怎么去保证剩下的节点的安全？路线图已经有了，其中一些功能已经可以使用，比如，白名单功能，仅允许特定的 Docker 镜像，阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。
|
||||
因为 Swarm 模式的持续改进，Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是：如果一个管理者被攻陷了，怎么去保证剩下的节点的安全？路线图已经有了，其中一些功能已经可以使用，比如，白名单功能，仅允许特定的 Docker 镜像，阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -155,7 +143,7 @@ via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/
|
||||
|
||||
作者：[Diogo Mónica][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,61 @@
|
||||
异步决策：帮助远程团队走向成功
|
||||
======
|
||||
|
||||
> 更好的沟通和少量的会议并不是白日梦。这里告诉您异步决策是如何实现这一切的。
|
||||
|
||||
|
||||
|
||||
异步决策能够让地理和文化上分散的软件团队更有效率地做出决策。本文就将讨论一下实现异步决策所需要的一些原则和工具。
|
||||
|
||||
同步决策，要求参与者实时地进行互动，而这对那些需要<ruby>[大块完整时间工作][1]<rt>Maker's Schedule</rt></ruby>的人来说代价非常大，而且对于远程团队来说这也不现实。我们会发现这种会议最后浪费的时间让人难以置信。
|
||||
|
||||
相比之下，异步决策常应用于大型开源项目中（比如我常参与的 Apache 软件基金会 ASF）。它为团队提供了一种尽可能少开会的有效方法。很多开源项目每年只开很少的几次会议（有的甚至完全没开过会），然而开发团队却始终如一地在生产高质量的软件。
|
||||
|
||||
怎样才能异步决策呢？
|
||||
|
||||
### 所需工具
|
||||
|
||||
#### 中心化的异步沟通渠道
|
||||
|
||||
异步决策的第一步就是构建一个中心化的异步沟通渠道。你所使用的技术必须能让所有的团队成员都获得同样的信息，并能进行<ruby>线索讨论<rt>threaded discussions</rt></ruby>，也就是说你要既能对一个主题进行发散也要能封禁其他主题的讨论。想一想航海专用无线电台，其中广播渠道的作用只是为了引起特定人员的注意，这些人然后再创建一个子渠道来进行详细的讨论。
|
||||
|
||||
很多开源项目依旧使用邮件列表作为中心渠道，不过很多新一代的软件开发者可能会觉得这个方法又古老又笨拙。邮件列表需要遵循大量的准则才能有效的管理热门项目，比如你需要进行有意义的引用，每个线索只讨论一个主题，保证 [标题与内容相吻合][2]。虽然这么麻烦，但使用得当的话，再加上一个经过索引的归档系统，邮件列表依然在创建中心渠道的工具中占据绝对主导的地位。
|
||||
|
||||
公司团队可以从一个更加现代化的协作工具中收益，这类工具更易使用并提供了更加强大的多媒体功能。不管你用的是哪个工具，关键在于要创建一个能让大量的人员有效沟通并异步地讨论各种主题的渠道。要创建一个一致而活跃的社区，使用一个 [繁忙的渠道要好过建立多个渠道][3]。
|
||||
|
||||
#### 构建共识的机制
|
||||
|
||||
第二个工具是一套构建共识的机制，这样你才不会陷入死循环从而确保能做出决策。做决策最理想的情况就是一致同意，而次佳的就是达成共识，也就是 “有决策权的人之间广泛形成了一致的看法”。强求完全一致的赞同或者允许一票否决都会阻碍决策的制定，因此 ASF 中只在非常有限的决策类型中允许否决权。[ASF 投票制度][4] 为类似 ASF 这样没有大老板的松散组织构建了一个久经考验的，用于达成共识的好方法。当共识无法自然产生时也可以使用该套制度。
|
||||
|
||||
#### 案例管理系统
|
||||
|
||||
如上所述，我们通常在项目的中心渠道中构建共识。但是在讨论一些复杂的话题时，使用案例管理系统这一第三方的工具很有意义。小组可以使用中心渠道专注于非正式的讨论和头脑风暴上，当讨论要转变成一个决策时将其转到一个更加结构化的案例管理系统中去。
|
||||
|
||||
案例管理系统能够更精确地组织决策。小型团队不用做太多决策可以不需要它，但很多团队会发现能有一个相对独立的地方讨论决策的细节并保存相关信息会方便很多。
|
||||
|
||||
案例管理系统不一定就是个很复杂的软件; 在 ASF 中我们所使用的只是简单的问题跟踪软件而已，这些基于网页的系统原本是创建来进行软件支持和 bug 管理的。每个案例列在一个单独的网页上，还有一些历史的注释和动作信息。该途径可以很好的追踪决策是怎么制定出来的。比如，某些非紧急的决策或者复杂的决策可能会花很长时间才会制定出来，这时有一个地方能够了解这些决策的历史就很有用了。新来的团队成员也能很快地了解到最近做出了哪些决策，哪些决策还在讨论，每个决策都有那些人参与其中，每个决策的背景是什么。
|
||||
|
||||
### 成功的案例
|
||||
|
||||
ASF 董事会中的九名董事在每个月的电话会议上只做很少的一些决策，耗时不超过 2 个小时。在准备这些会议之前，大多数的决策都预先通过异步的方式决定好了。这使得我们可以在会议上集中讨论复杂和难以确定的问题，而不是讨论那些已经达成普遍或部分共识的问题上。
|
||||
|
||||
软件世界外的一个有趣的案例是 [瑞士联邦委员会的周会][5]，它的运作方式跟 ASF 很类似。团队以异步决策构建共识的方式来准备会议。会议议程由一组不同颜色编码的列表组成，这些颜色标识了那些事项可以很快通过批准，那些事项需要进一步的讨论，哪些事项特别的复杂。这使得只要 7 个人就能每年忙完超过 2500 项决策，共 50 个周会，每个周会只需要几个小时时间。我觉得这个效率已经很高了。
|
||||
|
||||
就我的经验来看，异步决策带来的好处完全值得上为此投入的时间和工具。而且它也能让团队成员更快乐，这也是成功的关键因素之一。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/12/asynchronous-decision-making
|
||||
|
||||
作者：[Bertrand Delacretaz][a]
|
||||
译者：[lujun9972](https://github.com/lujun9972)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com
|
||||
[1]:http://www.paulgraham.com/makersschedule.html
|
||||
[2]:https://grep.codeconsult.ch/2017/11/10/large-mailing-lists-survival-guide/
|
||||
[3]:https://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/
|
||||
[4]:http://www.apache.org/foundation/voting.html
|
||||
[5]:https://www.admin.ch/gov/en/start/federal-council/tasks/decision-making/federal-council-meeting.html
|
||||
@ -1,31 +1,29 @@
|
||||
使用 Quagga 实现 Linux 动态路由
|
||||
============================================================
|
||||
|
||||
> 学习如何使用 Quagga 套件的路由协议去管理动态路由。
|
||||
|
||||
|
||||
学习如何使用 Quagga 套件的路由协议去管理动态路由。[Creative Commons Attribution][1][Wikimedia Commons: Martin Grandjean][2]
|
||||
|
||||
迄今为止，本系列文章中，我们已经在 [Linux 局域网路由新手指南：第 1 部分][4] 中学习了复杂的 IPv4 地址，在 [Linux 局域网路由新手指南：第 2 部分][5] 中学习了如何去手工创建静态路由。
|
||||
|
||||
今天，我们继续使用 [Quagga][6] 去管理动态路由，这是一个安装完后就不用理它的的软件。Quagga 是一个支持 OSPFv2、OSPFv3、RIP v1 和 v2、RIPng、以及 BGP-4 的路由协议套件，并全部由 zebra 守护程序管理。
|
||||
|
||||
OSPF 的意思是最短路径优先。OSPF 是一个内部网关协议（IGP）;它可以用在局域网和跨因特网的局域网互联中。在你的网络中的每个 OSPF 路由器都包含整个网络的拓扑，并计算通过网络的最短路径。OSPF 会通过多播的方式自动对外传播它检测到的网络变化。你可以将你的网络分割为区域，以保持路由表的可管理性；每个区域的路由器只需要知道离开它的区域的下一跳接口地址，而不用记录你的网络的整个路由表。
|
||||
OSPF 的意思是<ruby>最短路径优先<rt>Open Shortest Path First</rt></ruby>。OSPF 是一个内部网关协议（IGP）;它可以用在局域网和跨因特网的局域网互联中。在你的网络中的每个 OSPF 路由器都包含整个网络的拓扑，并计算通过该网络的最短路径。OSPF 会通过多播的方式自动对外传播它检测到的网络变化。你可以将你的网络分割为区域，以保持路由表的可管理性；每个区域的路由器只需要知道离开它的区域的下一跳接口地址，而不用记录你的网络的整个路由表。
|
||||
|
||||
RIP，路由信息协议，是一个很老的协议，RIP 路由器向网络中周期性多播它的整个路由表，而不是像 OSPF 那样只多播网络的变化。RIP 通过跳数来测量路由，任何超过 15 跳的路由它均视为不可到达。RIP 设置很简单，但是 OSPF 在速度、效率、以及弹性方面更佳。
|
||||
RIP，即路由信息协议，是一个很老的协议，RIP 路由器向网络中周期性多播它的整个路由表，而不是像 OSPF 那样只多播网络的变化。RIP 通过跳数来测量路由，任何超过 15 跳的路由它均视为不可到达。RIP 设置很简单，但是 OSPF 在速度、效率以及弹性方面更佳。
|
||||
|
||||
BGP-4 是边界网关协议版本 4。这是用于因特网流量路由的外部网关协议（EGP）。你不会用到 BGP 协议的，除非你是因特网服务提供商。
|
||||
|
||||
### 准备使用 OSPF
|
||||
|
||||
在我们的小型 KVM 测试实验室中，用两台虚拟机表示两个不同的网络，然后将另一台虚拟机配置为路由器。创建两个网络：net1 是 192.168.110.0/24 而 net2 是 192.168.120.0/24。启用 DHCP 是明智的，否则你要分别进入这三个虚拟机，去为它们设置静态地址。Host 1 在 net1 中，Host 2 在 net2 中，而路由器同时与这两个网络连接。设置 Host 1 的网关地址为 192.168.110.126，Host 2 的网关地址为 192.168.120.136。
|
||||
在我们的小型 KVM 测试实验室中，用两台虚拟机表示两个不同的网络，然后将另一台虚拟机配置为路由器。创建两个网络：net1 是 192.168.110.0/24 ，而 net2 是 192.168.120.0/24。启用 DHCP 是明智的，否则你要分别进入这三个虚拟机，去为它们设置静态地址。Host 1 在 net1 中，Host 2 在 net2 中，而路由器同时与这两个网络连接。设置 Host 1 的网关地址为 192.168.110.126，Host 2 的网关地址为 192.168.120.136。
|
||||
|
||||
* Host 1： 192.168.110.125
|
||||
|
||||
* Host 2：192.168.120.135
|
||||
|
||||
* Router：192.168.110.126 和 192.168.120.136
|
||||
|
||||
在路由器上安装 Quagga。在大多数 Linux 中它是一个 quagga 包。在 Debian 上还有一个单独的文档包 quagga-doc。取消 `/etc/sysctl.conf` 配置文件中如下这一行的注释去启用包转发功能：
|
||||
在路由器上安装 Quagga。在大多数 Linux 中它是 quagga 软件包。在 Debian 上还有一个单独的文档包 quagga-doc。取消 `/etc/sysctl.conf` 配置文件中如下这一行的注释去启用包转发功能：
|
||||
|
||||
```
|
||||
net.ipv4.ip_forward=1
|
||||
@ -44,32 +42,27 @@ net.ipv4.ip_forward=1
|
||||
hostname router1
|
||||
log file /var/log/quagga/ospfd.log
|
||||
router ospf
|
||||
ospf router-id 192.168.110.15
|
||||
network 192.168.110.0/0 area 0.0.0.0
|
||||
network 192.168.120.0/0 area 0.0.0.0
|
||||
ospf router-id 192.168.110.15
|
||||
network 192.168.110.0/0 area 0.0.0.0
|
||||
network 192.168.120.0/0 area 0.0.0.0
|
||||
access-list localhost permit 127.0.0.1/32
|
||||
access-list localhost deny any
|
||||
line vty
|
||||
access-class localhost
|
||||
```
|
||||
|
||||
你可以使用感叹号（！）或者井号（#）去注释掉这些行。我们来快速浏览一下这些选项。
|
||||
你可以使用感叹号（`!`）或者井号（`#`）去注释掉这些行。我们来快速浏览一下这些选项。
|
||||
|
||||
* **hostname** 是你希望的任何内容。这里不是一般意义上的 Linux 主机名，但是，当你使用 `vtysh` 或者 `telnet` 登入时，你将看到它们。
|
||||
|
||||
* **log file** 是你希望用于保存日志的任意文件。
|
||||
|
||||
* **router** 指定路由协议。
|
||||
|
||||
* **ospf router-id** 是任意的 32 位数字。使用路由器的一个 IP 地址就是很好的选择。
|
||||
|
||||
* **network** 定义你的路由器要通告的网络。
|
||||
|
||||
* **access-list** 限制 `vtysh` 登入，它是 Quagga 命令行 shell，它允许本地机器登入，并拒绝任何远程管理。
|
||||
* `hostname` 可以是你希望的任何内容。这里不是一般意义上的 Linux 主机名，但是，当你使用 `vtysh` 或者 `telnet` 登入时，你将看到它们。
|
||||
* `log file` 是你希望用于保存日志的任意文件。
|
||||
* `router` 指定路由协议。
|
||||
* `ospf router-id` 是任意的 32 位数字。使用路由器的一个 IP 地址就是很好的选择。
|
||||
* `network` 定义你的路由器要通告的网络。
|
||||
* `access-list` 限制 `vtysh` 登入，它是 Quagga 命令行 shell，它允许本地机器登入，并拒绝任何远程管理。
|
||||
|
||||
### Debian/Ubuntu
|
||||
|
||||
在你启动守护程序之前，Debian/Ubuntu 相对其它的 Debian 衍生版可能多需要一步到多步。编辑 `/etc/quagga/daemons` ，除了 `zebra`=yes 和 `ospfd=yes` 外，使其它所有的行的值为 `no`。
|
||||
在你启动守护程序之前，Debian/Ubuntu 相对其它的 Debian 衍生版可能多需要一步到多步。编辑 `/etc/quagga/daemons` ，除了 `zebra=yes` 和 `ospfd=yes` 外，使其它所有的行的值为 `no`。
|
||||
|
||||
然后，在 Debian 上运行 `ospfd` 去启动 Quagga：
|
||||
|
||||
@ -95,9 +88,9 @@ line vty
|
||||
|
||||
via: https://www.linux.com/learn/intro-to-linux/2018/3/dynamic-linux-routing-quagga
|
||||
|
||||
作者：[CARLA SCHRODER ][a]
|
||||
作者：[CARLA SCHRODER][a]
|
||||
译者：[qhwdw](https://github.com/qhwdw)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -105,7 +98,7 @@ via: https://www.linux.com/learn/intro-to-linux/2018/3/dynamic-linux-routing-qua
|
||||
[1]:https://www.linux.com/licenses/category/creative-commons-attribution
|
||||
[2]:https://commons.wikimedia.org/wiki/File:Network_Visualization.png
|
||||
[3]:https://www.linux.com/files/images/networkvisualizationpng
|
||||
[4]:https://www.linux.com/learn/intro-to-linux/2018/2/linux-lan-routing-beginners-part-1
|
||||
[5]:https://www.linux.com/learn/intro-to-linux/2018/3/linux-lan-routing-beginners-part-2
|
||||
[4]:https://linux.cn/article-9657-1.html
|
||||
[5]:https://linux.cn/article-9675-1.html
|
||||
[6]:https://www.quagga.net/
|
||||
[7]:https://www.quagga.net/
|
||||
@ -2,7 +2,8 @@ Audacity 快速指南：快速消除背景噪音
|
||||
======
|
||||
|
||||
|
||||
当在笔记本电脑上录制声音时 - 比如首次简单地录屏 - 许多用户通常使用内置麦克风。但是，这些小型麦克风也会捕获很多背景噪音。在这个快速指南中，我们会学习如何使用 Fedora 中的 [Audacity][1] 快速移除音频文件中的背景噪音。
|
||||
|
||||
当在笔记本电脑上录制声音时 —— 比如首次简单地录屏 —— 许多用户通常使用内置麦克风。但是，这些小型麦克风也会捕获很多背景噪音。在这个快速指南中，我们会学习如何使用 Fedora 中的 [Audacity][1] 快速移除音频文件中的背景噪音。
|
||||
|
||||
### 安装 Audacity
|
||||
|
||||
@ -11,28 +12,30 @@ Audacity 是 Fedora 中用于混合、剪切和编辑音频文件的程序。在
|
||||
![][2]
|
||||
|
||||
如果你更喜欢终端，请使用以下命令：
|
||||
|
||||
```
|
||||
sudo dnf install audacity
|
||||
|
||||
```
|
||||
|
||||
### 导入您的音频、样本背景噪音
|
||||
|
||||
安装 Audacity 后，打开程序，使用 **File > Import** 菜单项导入你的声音。这个例子使用了一个[来自 freesound.org 添加了噪音的声音][3]：
|
||||
安装 Audacity 后，打开程序，使用 “File > Import” 菜单项导入你的声音。这个例子使用了一个[来自 freesound.org 添加了噪音的声音][3]：
|
||||
|
||||
接下来，采样要滤除的背景噪音。导入音轨后，选择仅包含背景噪音的音轨区域。然后从菜单中选择 **Effect > Noise Reduction**，然后按下 **Get Noise Profile** 按钮。
|
||||
- https://ryanlerch.fedorapeople.org/noise.ogg?_=1
|
||||
|
||||
接下来，采样要滤除的背景噪音。导入音轨后，选择仅包含背景噪音的音轨区域。然后从菜单中选择 “Effect > Noise Reduction”，然后按下 “Get Noise Profile” 按钮。
|
||||
|
||||
![][4]
|
||||
|
||||
### 过滤噪音
|
||||
|
||||
接下来，选择你要过滤噪音的音轨区域。通过使用鼠标进行选择，或者按 **Ctrl + a** 来选择整个音轨。最后，再次打开 **Effect > Noise Reduction** 对话框，然后单击确定以应用滤镜。
|
||||
接下来，选择你要过滤噪音的音轨区域。通过使用鼠标进行选择，或者按 `Ctrl + a` 来选择整个音轨。最后，再次打开 “Effect > Noise Reduction” 对话框，然后单击确定以应用滤镜。
|
||||
|
||||
![][5]
|
||||
|
||||
此外，调整设置，直到你的音轨听起来更好。这里是原始文件，接下来是用于比较的降噪音轨（使用默认设置）：
|
||||
|
||||
https://ryanlerch.fedorapeople.org/sidebyside.ogg?_=2
|
||||
- https://ryanlerch.fedorapeople.org/sidebyside.ogg?_=2
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
@ -41,7 +44,7 @@ via: https://fedoramagazine.org/audacity-quick-tip-quickly-remove-background-noi
|
||||
作者：[Ryan Lerch][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,31 +1,27 @@
|
||||
如何在 Ubuntu 18.04 服务器上安装和配置 KVM
|
||||
|
||||
======
|
||||
|
||||
**KVM**（基于内核的虚拟机）是一款为类 Linux 系统提供的开源全虚拟化解决方案，KVM 使用虚拟化扩展（如 **Intel VT** 或 **AMD-V**）提供虚拟化功能。无论何时我们在任何 Linux 机器上安装 KVM，都会通过加载诸如 kvm-intel.ko（基于 Intel 的机器）和 kvm-amd.ko（基于 amd 的机器）的内核模块，使其成为<ruby>管理程序<rt>hyervisor</rt></ruby>（LCTT 译者注：一种监控和管理虚拟机运行的核心软件层）。
|
||||
**KVM**（基于内核的虚拟机）是一款为类 Linux 系统提供的开源的全虚拟化解决方案，KVM 使用虚拟化扩展（如 **Intel VT** 或 **AMD-V**）提供虚拟化功能。无论何时我们在任何 Linux 机器上安装 KVM，都会通过加载诸如 `kvm-intel.ko`（基于 Intel 的机器）和 `kvm-amd.ko`（基于 amd 的机器）的内核模块，使其成为<ruby>管理程序<rt>hyervisor</rt></ruby>（LCTT 译注：一种监控和管理虚拟机运行的核心软件层）。
|
||||
|
||||
KVM 允许我们安装和运行多个虚拟机（Windows 和 Linux）。我们可以通过 **virt-manager** 的图形用户界面或使用 **virt-install** 和 **virsh** 命令在命令行界面来创建和管理基于 KVM 的虚拟机。
|
||||
KVM 允许我们安装和运行多个虚拟机（Windows 和 Linux）。我们可以通过 `virt-manager` 的图形用户界面或使用 `virt-install` 和 `virsh` 命令在命令行界面来创建和管理基于 KVM 的虚拟机。
|
||||
|
||||
在本文中，我们将讨论如何在Ubuntu 18.04 LTS 服务器上安装和配置 **KVM 管理程序**。我假设你已经在你的服务器上安装了 Ubuntu 18.04 LTS 。接下来登录到您的服务器执行以下步骤。
|
||||
在本文中，我们将讨论如何在 Ubuntu 18.04 LTS 服务器上安装和配置 **KVM 管理程序**。我假设你已经在你的服务器上安装了 Ubuntu 18.04 LTS 。接下来登录到您的服务器执行以下步骤。
|
||||
|
||||
### 第一步：确认您的硬件是否支持虚拟化
|
||||
|
||||
执行 egrep 命令以验证您的服务器的硬件是否支持虚拟化，
|
||||
执行 `egrep` 命令以验证您的服务器的硬件是否支持虚拟化，
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ egrep -c '(vmx|svm)' /proc/cpuinfo
|
||||
1
|
||||
linuxtechi@kvm-ubuntu18-04:~$
|
||||
|
||||
```
|
||||
|
||||
如果输出结果大于 0，就意味着您的硬件支持虚拟化。重启，进入 BIOS 设置中启用 VT 技术。
|
||||
|
||||
现在使用下面的命令安装“ **kvm-ok** ”实用程序，该程序用于确定您的服务器是否能够运行硬件加速的 KVM 虚拟机
|
||||
现在使用下面的命令安装 `kvm-ok` 实用程序，该程序用于确定您的服务器是否能够运行硬件加速的 KVM 虚拟机。
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo apt install cpu-checker
|
||||
|
||||
```
|
||||
|
||||
运行 kvm-ok 命令确认输出结果，
|
||||
@ -34,60 +30,55 @@ linuxtechi@kvm-ubuntu18-04:~$ sudo apt install cpu-checker
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo kvm-ok
|
||||
INFO: /dev/kvm exists
|
||||
KVM acceleration can be used
|
||||
linuxtechi@kvm-ubuntu18-04:~$
|
||||
|
||||
```
|
||||
|
||||
### 第二步：安装 KVM 及其依赖包
|
||||
|
||||
运行下面的 apt 命令安装 KVM 及其依赖项：
|
||||
|
||||
运行下面的 apt 命令安装 KVM 及其依赖项
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo apt update
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo apt install qemu qemu-kvm libvirt-bin bridge-utils virt-manager
|
||||
```
|
||||
|
||||
只要上图相应的软件包安装成功，那么你的本地用户（对于我来说是 linuxtechi）将被自动添加到 libvirtd 群组。
|
||||
只要上图相应的软件包安装成功，那么你的本地用户（对于我来说是 `linuxtechi`）将被自动添加到 `libvirtd` 群组。
|
||||
|
||||
### 第三步：启动并启用 libvirtd 服务
|
||||
|
||||
我们在 Ubuntu 18.04 服务器上安装 qemu 和 libvirtd 软件包之后，它就会自动启动并启用 libvirtd 服务，如果 libvirtd 服务没有开启，则运行以下命令开启，
|
||||
我们在 Ubuntu 18.04 服务器上安装 qemu 和 libvirtd 软件包之后，它就会自动启动并启用 `libvirtd` 服务，如果 `libvirtd` 服务没有开启，则运行以下命令开启，
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo service libvirtd start
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo update-rc.d libvirtd enable
|
||||
|
||||
```
|
||||
|
||||
现在使用下面的命令确认 libvirtd 服务的状态，
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ service libvirtd status
|
||||
|
||||
```
|
||||
|
||||
输出结果如下所示：
|
||||
|
||||
[![libvirtd-command-ubuntu18-04][1]![libvirtd-command-ubuntu18-04][2]][3]
|
||||
![][3]
|
||||
|
||||
### 第四步：为 KVM 虚拟机配置桥接网络
|
||||
|
||||
只有通过桥接网络，KVM 虚拟机才能访问外部的 KVM 管理程序或主机。在Ubuntu 18.04中，网络由 netplan 实用程序管理，每当我们新安装一个 Ubuntu 18.04 系统时，会自动创建一个名称为 “**/etc/netplan/50-cloud-init.yaml**” 文件，其配置了静态 IP 和桥接网络，netplan 实用工具将引用这个文件。
|
||||
只有通过桥接网络，KVM 虚拟机才能访问外部的 KVM 管理程序或主机。在Ubuntu 18.04中，网络由 `netplan` 实用程序管理，每当我们新安装一个 Ubuntu 18.04 系统时，会自动创建一个名称为 `/etc/netplan/50-cloud-init.yaml` 文件，其配置了静态 IP 和桥接网络，`netplan` 实用工具将引用这个文件。
|
||||
|
||||
截至目前，我已经在此文件配置了静态 IP，文件的具体内容如下：
|
||||
|
||||
```
|
||||
network:
|
||||
ethernets:
|
||||
ens33:
|
||||
addresses: [192.168.0.51/24]
|
||||
gateway4: 192.168.0.1
|
||||
nameservers:
|
||||
addresses: [192.168.0.1]
|
||||
dhcp4: no
|
||||
optional: true
|
||||
version: 2
|
||||
|
||||
ethernets:
|
||||
ens33:
|
||||
addresses: [192.168.0.51/24]
|
||||
gateway4: 192.168.0.1
|
||||
nameservers:
|
||||
addresses: [192.168.0.1]
|
||||
dhcp4: no
|
||||
optional: true
|
||||
version: 2
|
||||
```
|
||||
|
||||
我们在这个文件中添加桥接网络的配置信息，
|
||||
@ -113,84 +104,78 @@ network:
|
||||
|
||||
```
|
||||
|
||||
正如你所看到的，我们已经从接口（ens33）中删除了 IP 地址，并将该 IP 添加到 '**br0**' 中，并且还将接口（ens33）添加到 br0。使用下面的 netplan 命令使更改生效，
|
||||
正如你所看到的，我们已经从接口（`ens33`）中删除了 IP 地址，并将该 IP 添加到 `br0` 中，并且还将接口（`ens33`）添加到 `br0`。使用下面的 `netplan` 命令使更改生效，
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo netplan apply
|
||||
linuxtechi@kvm-ubuntu18-04:~$
|
||||
|
||||
```
|
||||
|
||||
如果您想查看 debug 日志请使用以下命令，
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo netplan --debug apply
|
||||
|
||||
```
|
||||
|
||||
现在使用以下方法确认网络桥接状态：
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo networkctl status -a
|
||||
|
||||
```
|
||||
|
||||
[![networkctl-command-output-ubuntu18-04][1]![networkctl-command-output-ubuntu18-04][4]][4]
|
||||
![][4]
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ ifconfig
|
||||
|
||||
```
|
||||
|
||||
[![ifconfig-command-output-ubuntu18-04][1]![ifconfig-command-output-ubuntu18-04][5]][5]
|
||||
![][5]
|
||||
|
||||
### 第五步：创建虚拟机（使用 virt-manager 或 virt-install 命令）
|
||||
|
||||
有两种方式创建虚拟机：
|
||||
|
||||
* virt-manager（图形化工具）
|
||||
* virt-install（命令行工具）
|
||||
* `virt-manager`（图形化工具）
|
||||
* `virt-install`（命令行工具）
|
||||
|
||||
|
||||
**使用 virt-manager 创建虚拟机：**
|
||||
#### 使用 virt-manager 创建虚拟机
|
||||
|
||||
通过执行下面的命令启动 virt-manager，
|
||||
通过执行下面的命令启动 `virt-manager`：
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo virt-manager
|
||||
|
||||
```
|
||||
|
||||
[![Start-Virt-Manager-Ubuntu18-04][1]![Start-Virt-Manager-Ubuntu18-04][6]][6]
|
||||
![][6]
|
||||
|
||||
创建一个新的虚拟机
|
||||
创建一个新的虚拟机：
|
||||
|
||||
[![ISO-file-Virt-Manager][1]![ISO-file-Virt-Manager][7]][7]
|
||||
![][7]
|
||||
|
||||
点击下一步然后选择 ISO 镜像文件，我使用的是 RHEL 7.3 iso 镜像。
|
||||
点击“下一步”然后选择 ISO 镜像文件，我使用的是 RHEL 7.3 iso 镜像。
|
||||
|
||||
[![Select-ISO-file-virt-manager-Ubuntu18-04-Server][1]![Select-ISO-file-virt-manager-Ubuntu18-04-Server][8]][8]
|
||||
![][8]
|
||||
|
||||
点击下一步
|
||||
点击“下一步”。
|
||||
|
||||
在接下来的几个窗口中，系统会提示要求您为 VM 分配内存，处理器数量和磁盘空间。
|
||||
|
||||
并指定虚拟机名字和桥接网络名，
|
||||
并指定虚拟机名字和桥接网络名：
|
||||
|
||||
[![VM-Name-Network-Virt-Manager-Ubuntu18-04][1]![VM-Name-Network-Virt-Manager-Ubuntu18-04][9]][9]
|
||||
![][9]
|
||||
|
||||
点击结束
|
||||
点击“结束”。
|
||||
|
||||
[![RHEL7-3-Installation-Virt-Manager][1]![RHEL7-3-Installation-Virt-Manager][10]][10]
|
||||
![][10]
|
||||
|
||||
接下来只需要按照屏幕指示安装系统，
|
||||
接下来只需要按照屏幕指示安装系统。
|
||||
|
||||
**使用virt-install命令从命令行界面创建虚拟机，**
|
||||
#### 使用virt-install命令从命令行界面创建虚拟机
|
||||
|
||||
使用下面的 virt-install 命令从终端创建一个虚拟机，它将在命令行界面中开始安装，并根据您对虚拟机的名字，说明，ISO 文件位置和桥接配置的设置创建虚拟机。
|
||||
使用下面的 `virt-install` 命令从终端创建一个虚拟机，它将在命令行界面中开始安装，并根据您对虚拟机的名字，说明，ISO 文件位置和桥接配置的设置创建虚拟机。
|
||||
|
||||
```
|
||||
linuxtechi@kvm-ubuntu18-04:~$ sudo virt-install -n DB-Server --description "Test VM for Database" --os-type=Linux --os-variant=rhel7 --ram=1096 --vcpus=1 --disk path=/var/lib/libvirt/images/dbserver.img,bus=virtio,size=10 --network bridge:br0 --graphics none --location /home/linuxtechi/rhel-server-7.3-x86_64-dvd.iso --extra-args console=ttyS0
|
||||
|
||||
```
|
||||
|
||||
本文到此为止，我希望这篇文章能帮助你能够在 Ubuntu 18.04 服务器上成功安装 KVM。 除此之外，KVM 也是 Openstack 默认的管理程序。
|
||||
@ -206,7 +191,7 @@ via: https://www.linuxtechi.com/install-configure-kvm-ubuntu-18-04-server/
|
||||
作者：[Pradeep Kumar][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[wyxplus](https://github.com/wyxplus)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,86 +0,0 @@
|
||||
Translating by FelixYFZ Why DevSecOps matters to IT leaders
|
||||
======
|
||||
|
||||
|
||||
|
||||
If [DevOps][1] is ultimately about building better software, that means better-secured software, too.
|
||||
|
||||
Enter the term "DevSecOps." Like any IT term, DevSecOps - a descendant of the better-established DevOps - could be susceptible to hype and misappropriation. But the term has real meaning for IT leaders who've embraced a culture of DevOps and the practices and tools that help deliver on its promise.
|
||||
|
||||
Speaking of which: What does "DevSecOps" mean?
|
||||
|
||||
"DevSecOps is a portmanteau of development, security, and operations," says Robert Reeves, CTO and co-founder at [Datical][2]. "It reminds us that security is just as important to our applications as creating them and deploying them to production."
|
||||
|
||||
**[ Want DevOps advice from other CIOs? See our comprehensive resource, [DevOps: The IT Leader's Guide][3]. ]**
|
||||
|
||||
One easy way to explain DevSecOps to non-technical people: It bakes security into the development process intentionally and earlier.
|
||||
|
||||
"Security teams have historically been isolated from development teams - and each team has developed deep expertise in different areas of IT," [Red Hat][4] security strategist Kirsten Newcomer [told us][5] recently. "It doesn't need to be this way. Enterprises that care deeply about security and also care deeply about their ability to quickly deliver business value through software are finding ways to move security left in their application development lifecycles. They're adopting DevSecOps by integrating security practices, tooling, and automation throughout the CI/CD pipeline."
|
||||
|
||||
"To do this well, they're integrating their teams - security professionals are embedded with application development teams from inception (design) through to production deployment," she says. "Both sides are seeing the value - each team expands their skill sets and knowledge base, making them more valuable technologists. DevOps done right - or DevSecOps - improves IT security."
|
||||
|
||||
IT teams are tasked with delivering services faster and more frequently than ever before. DevOps can be a great enabler of this, in part because it can remove some of the traditional friction between development and operations teams that commonly surfaced when Ops was left out of the process until deployment time and Dev tossed its code over an invisible wall, never to manage it again, much less have any infrastructure responsibility. That kind of siloed approach causes problems, to put it mildly, in the digital age. According to Reeves, the same holds true if security exists in a silo.
|
||||
|
||||
"We have adopted DevOps because it's proven to improve our IT performance by removing the barriers between development and operations," Reeves says. "Much like we shouldn't wait until the end of the deployment cycle to involve operations, we shouldn't wait until the end to involve security."
|
||||
|
||||
### Why DevSecOps is here to stay
|
||||
|
||||
It may be tempting to see DevSecOps as just another buzzword, but for security-conscious IT leaders, it's a substantive term: Security must be a first-class citizen in the software development pipeline, not something that gets bolted on as a final step before a deploy, or worse, as a team that gets scrambled only after an actual incident occurs.
|
||||
|
||||
"DevSecOps is not just a buzzword - it is the current and future state of IT for multiple reasons," says George Gerchow, VP of security and compliance at [Sumo Logic][6]. "The most important benefit is the ability to bake security into development and operational processes to provide guardrails - not barriers - to achieve agility and innovation."
|
||||
|
||||
Moreover, the appearance of the DevSecOps on the scene might be another sign that DevOps itself is maturing and digging deep roots inside IT.
|
||||
|
||||
"The culture of DevOps in the enterprise is here to stay, and that means that developers are delivering features and updates to the production environment at an increasingly higher velocity, especially as the self-organizing teams become more comfortable with both collaboration and measurement of results," says Mike Kail, CTO and co-founder at [CYBRIC][7].
|
||||
|
||||
Teams and companies that have kept their old security practices in place while embracing DevOps are likely experiencing an increasing amount of pain managing security risks as they continue to deploy faster and more frequently.
|
||||
|
||||
"The current, manual testing approaches of security continue to fall further and further behind."
|
||||
|
||||
"The current, manual testing approaches of security continue to fall further and further behind, and leveraging both automation and collaboration to shift security testing left into the software development life cycle, thus driving the culture of DevSecOps, is the only way for IT leaders to increase overall resiliency and delivery security assurance," Kail says.
|
||||
|
||||
Shifting security testing left (earlier) benefits developers, too: Rather than finding out about a glaring hole in their code right before a new or updated service is set to deploy, they can identify and resolve potential issues during much earlier stages of development - often with little or no intervention from security personnel.
|
||||
|
||||
"Done right, DevSecOps can ingrain security into the development lifecycle, empowering developers to more quickly and easily secure their applications without security disruptions," says Brian Wilson, chief information security officer at [SAS][8].
|
||||
|
||||
Wilson points to static (SAST) and source composition analysis (SCA) tools, integrated into a team's continuous delivery pipelines, as useful technologies that help make this possible by giving developers feedback about potential issues in their own code as well as vulnerabilities in third-party dependencies.
|
||||
|
||||
"As a result, developers can proactively and iteratively mitigate appsec issues and rerun security scans without the need to involve security personnel," Wilson says. He notes, too, that DevSecOps can also help the Dev team streamline updates and patching.
|
||||
|
||||
DevSecOps doesn't mean you no longer need security pros, just as DevOps doesn't mean you no longer need infrastructure experts; it just helps reduce the likelihood of flaws finding their way into production, or from slowing down deployments because they're caught late in the pipeline.
|
||||
|
||||
"We're here if they have questions or need help, but having given developers the tools they need to secure their apps, we're less likely to find a showstopper issue during a penetration test," Wilson says.
|
||||
|
||||
### DevSecOps meets Meltdown
|
||||
|
||||
Sumo Logic's Gerchow shares a timely example of the DevSecOps culture in action: When the recent [Meltdown and Spectre][9] news hit, the team's DevSecOps approach enabled a rapid response to mitigate its risks without any noticeable disruption to internal or external customers, which Gerchow said was particularly important for the cloud-native, highly regulated company.
|
||||
|
||||
The first step: Gerchow's small security team, which he notes also has development skills, was able to work with one of its main cloud vendors via Slack to ensure its infrastructure was completely patched within 24 hours.
|
||||
|
||||
"My team then began OS-level fixes immediately with zero downtime to end users without having to open tickets and requests with engineering that would have meant waiting on a long change management process. All the changes were accounted for via automated Jira tickets opened via Slack and monitored through our logs and analytics solution," Gerchow explains.
|
||||
|
||||
In essence, it sounds a whole lot like the culture of DevOps, matched with the right mix of people, processes, and tools, but it explicitly includes security as part of that culture and mix.
|
||||
|
||||
"In traditional environments, it would have taken weeks or months to do this with downtime because all three development, operations, and security functions were siloed," Gerchow says. "With a DevSecOps process and mindset, end users get a seamless experience with easy communication and same-day fixes."
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders
|
||||
|
||||
作者：[Kevin Casey][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||||
[1]:https://enterprisersproject.com/tags/devops
|
||||
[2]:https://www.datical.com/
|
||||
[3]:https://enterprisersproject.com/devops?sc_cid=70160000000h0aXAAQ
|
||||
[4]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||||
[5]:https://enterprisersproject.com/article/2017/10/what-s-next-devops-5-trends-watch
|
||||
[6]:https://www.sumologic.com/
|
||||
[7]:https://www.cybric.io/
|
||||
[8]:https://www.sas.com/en_us/home.html
|
||||
[9]:https://www.redhat.com/en/blog/what-are-meltdown-and-spectre-heres-what-you-need-know?intcmp=701f2000000tjyaAAA
|
||||
@ -1,4 +1,4 @@
|
||||
How DevOps helps deliver cool apps to users
|
||||
Translating by FelixYFZ How DevOps helps deliver cool apps to users
|
||||
======
|
||||
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user