标签 编排 下的文章

Docker 作为一款容器化应用的新兴软件,被大多数 IT 公司使用来减少基础设施平台的成本。

通常,没有 GUI 的 Docker 软件对于 Linux 管理员来说很容易,但是对于开发者来就有点困难。当把它搬到生产环境上来,那么它对 Linux 管理员来说也相当不友好。那么,轻松管理 Docker 的最佳解决方案是什么呢?

唯一的办法就是提供 GUI。Docker API 允许第三方应用接入 Docker。在市场上有许多 Docker GUI 应用。我们已经写过一篇关于 Portainer 应用的文章。今天我们来讨论另一个应用,Rancher。

容器让软件开发更容易,让开发者更快的写代码、更好的运行它们。但是,在生产环境上运行容器却很困难。

推荐阅读: Portainer:一个简单的 Docker 管理图形工具

Rancher 简介

Rancher 是一个全面的容器管理平台,它可以让容器在各种基础设施平台的生产环境上部署和运行更容易。它提供了诸如多主机网络、全局/本地负载均衡和卷快照等基础设施服务。它整合了原生 Docker 的管理能力,如 Docker Machine 和 Docker Swarm。它提供了丰富的用户体验,让 DevOps 管理员在更大规模的生产环境上运行 Docker。

访问以下文章可以了解 Linux 系统上安装 Docker。

推荐阅读:

Rancher 特性

  • 可以在两分钟内安装 Kubernetes。
  • 一键启动应用(90 个流行的 Docker 应用)。
  • 部署和管理 Docker 更容易。
  • 全面的生产级容器管理平台。
  • 可以在生产环境上快速部署容器。
  • 强大的自动部署和运营容器技术。
  • 模块化基础设施服务。
  • 丰富的编排工具。
  • Rancher 支持多种认证机制。

怎样安装 Rancher

由于 Rancher 是以轻量级的 Docker 容器方式运行,所以它的安装非常简单。Rancher 是由一组 Docker 容器部署的。只需要简单的启动两个容器就能运行 Rancher。一个容器用作管理服务器,另一个容器在各个节点上作为代理。在 Linux 系统下简单的运行下列命令就能部署 Rancher。

Rancher 服务器提供了两个不同的安装包标签如 stablelatest。下列命令将会拉取适合的 Rancher 镜像并安装到你的操作系统上。Rancher 服务器仅需要两分钟就可以启动。

  • latest:这个标签是他们的最新开发构建。这些构建将通过 Rancher CI 的自动化框架进行验证,不建议在生产环境使用。
  • stable:这是最新的稳定发行版本,推荐在生产环境使用。

Rancher 的安装方法有多种。在这篇教程中我们仅讨论两种方法。

  • 以单一容器的方式安装 Rancher(内嵌 Rancher 数据库)
  • 以单一容器的方式安装 Rancher(外部数据库)

方法 - 1

运行下列命令以单一容器的方式安装 Rancher 服务器(内嵌数据库)

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:stable
$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server:latest

方法 - 2

你可以在启动 Rancher 服务器时指向外部数据库,而不是使用自带的内部数据库。首先创建所需的数据库,数据库用户为同一个。

> CREATE DATABASE IF NOT EXISTS cattle COLLATE = 'utf8_general_ci' CHARACTER SET = 'utf8';
> GRANT ALL ON cattle.* TO 'cattle'@'%' IDENTIFIED BY 'cattle';
> GRANT ALL ON cattle.* TO 'cattle'@'localhost' IDENTIFIED BY 'cattle';

运行下列命令启动 Rancher 去连接外部数据库。

$ sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server \
 --db-host myhost.example.com --db-port 3306 --db-user username --db-pass password --db-name cattle

如果你想测试 Rancher 2.0,使用下列的命令去启动。

$ sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/server:preview

通过 GUI 访问 & 安装 Rancher

浏览器输入 http://hostname:8080http://server_ip:8080 去访问 rancher GUI.

怎样注册主机

注册你的主机 URL 允许它连接到 Rancher API。这是一次性设置。

接下来,点击主菜单下面的 “Add a Host” 链接或者点击主菜单上的 “INFRASTRUCTURE >> Add Hosts”,点击 “Save” 按钮。

默认情况下,Rancher 里的访问控制认证禁止了访问,因此我们首先需要通过一些方法打开访问控制认证,否则任何人都不能访问 GUI。

点击 “>> Admin >> Access Control”,输入下列的值最后点击 “Enable Authentication” 按钮去打开它。在我这里,是通过 “local authentication” 的方式打开的。

  • “Login UserName”: 输入你期望的登录名
  • “Full Name”: 输入你的全名
  • “Password”: 输入你期望的密码
  • “Confirm Password”: 再一次确认密码

注销然后使用新的登录凭证重新登录:

现在,我能看到本地认证已经被打开。

怎样添加主机

注册你的主机后,它将带你进入下一个页面,在那里你能选择不同云服务提供商的 Linux 主机。我们将添加一个主机运行 Rancher 服务,因此选择“custom”选项然后输入必要的信息。

在第 4 步输入你服务器的公有 IP,运行第 5 步列出的命令,最后点击 “close” 按钮。

$ sudo docker run -e CATTLE_AGENT_IP="192.168.56.2"  --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.2.11 http://192.168.56.2:8080/v1/scripts/16A52B9BE2BAB87BB0F5:1546214400000:ODACe3sfis5V6U8E3JASL8jQ

INFO: Running Agent Registration Process, CATTLE_URL=http://192.168.56.2:8080/v1
INFO: Attempting to connect to: http://192.168.56.2:8080/v1
INFO: http://192.168.56.2:8080/v1 is accessible
INFO: Configured Host Registration URL info: CATTLE_URL=http://192.168.56.2:8080/v1 ENV_URL=http://192.168.56.2:8080/v1
INFO: Inspecting host capabilities
INFO: Boot2Docker: false
INFO: Host writable: true
INFO: Token: xxxxxxxx
INFO: Running registration
INFO: Printing Environment
INFO: ENV: CATTLE_ACCESS_KEY=9946BD1DCBCFEF3439F8
INFO: ENV: CATTLE_AGENT_IP=192.168.56.2
INFO: ENV: CATTLE_HOME=/var/lib/cattle
INFO: ENV: CATTLE_REGISTRATION_ACCESS_KEY=registrationToken
INFO: ENV: CATTLE_REGISTRATION_SECRET_KEY=xxxxxxx
INFO: ENV: CATTLE_SECRET_KEY=xxxxxxx
INFO: ENV: CATTLE_URL=http://192.168.56.2:8080/v1
INFO: ENV: DETECTED_CATTLE_AGENT_IP=172.17.0.1
INFO: ENV: RANCHER_AGENT_IMAGE=rancher/agent:v1.2.11
INFO: Launched Rancher Agent: e83b22afd0c023dabc62404f3e74abb1fa99b9a178b05b1728186c9bfca71e8d

等待几秒钟后新添加的主机将会出现。点击 “Infrastructure >> Hosts” 页面。

怎样查看容器

只需要点击下列位置就能列出所有容器。点击 “Infrastructure >> Containers” 页面。

怎样创建容器

非常简单,只需点击下列位置就能创建容器。

点击 “Infrastructure >> Containers >> Add Container” 然后输入每个你需要的信息。为了测试,我将创建一个 latest 标签的 CentOS 容器。

在同样的列表位置,点击 “ Infrastructure >> Containers”。

点击容器名展示容器的性能信息,如 CPU、内存、网络和存储。

选择特定容器,然后点击最右边的“三点”按钮或者点击“Actions”按钮对容器进行管理,如停止、启动、克隆、重启等。

如果你想控制台访问容器,只需要点击 “Actions” 按钮中的 “Execute Shell” 选项即可。

怎样从应用目录部署容器

Rancher 提供了一个应用模版目录,让部署变的很容易,只需要单击一下就可以。 它维护了多数流行应用,这些应用由 Rancher 社区贡献。

点击 “Catalog >> All >> Choose the required application”,最后点击 “Launch” 去部署。


via: https://www.2daygeek.com/rancher-a-complete-container-management-platform-for-production-environment/

作者:Magesh Maruthamuthu 译者:arrowfeng 校对:wxy

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

Docker 平台和容器已经成为打包、部署、和管理应用程序的标准。为了在一个集群内协调跨节点的容器,必须有一个关键的能力:一个容器编排器。

container orchestrator

对于关键的集群化以及计划的任务,编排器是起重大作用的,比如:

  • 管理容器计划和资源分配。
  • 支持服务发现和无缝的应用程序部署。
  • 分配应用程序运行必需的资源。

不幸的是,在这种环境下,编排器的分布式特性和资源的短暂性使得确保编排器的安全是一个极具挑战性的任务。在这篇文章中,我们将讨论容器编排器安全模型中没有考虑到的、但是很重要的这方面的详细情况,以及 Docker 企业版中如何使用内置的编排性能、Swarm 模式,去克服这些问题。

诱因和威胁模型

使用 swarm 模式的 Docker 企业版的其中一个主要目标是提供一个内置安全特性的编排器。为达到这个目标,我们部署了第一个在我们心目中认为的以最小权限原则设计的容器编排器。

在计算机科学中,一个分布式系统所要求的最小权限原则是,系统中的每个参与者仅仅能访问它正当目的所需要的信息和资源。不是更多,也不是更少。

“一个进程必须仅仅能去访问它的正当目的所需要的信息和资源”

最小权限原则

在一个 Docker 企业版集群中的每个节点分配的角色:既不是管理者(manager),也不是工人(worker)。这些角色为节点定义了一个很粗粒度的权限级别:分别进行管理和任务执行。尽管如此,不用理会它的角色,通过使用加密的方式,来保证一个节点仅仅有执行它的任务所需要的信息和资源。结果是,确保集群安全变得更容易了,甚至可以防止大多数的有经验的攻击者模式:攻击者控制了底层通讯网络,或者甚至攻陷了集群节点。

内核缺省安全

这是一个很老的安全最大化状态:如果它不是缺省的,就没人用它。Docker Swarm 模式将缺省安全这一概念融入了核心,并且使用这一机制去解决编排器生命周期中三个很难并且很重要的部分:

  1. 可信引导和节点引入。
  2. 节点身份发布和管理。
  3. 认证、授权和加密的信息存储和传播。

我们来分别看一下这三个部分:

可信引导和节点引入

确保集群安全的第一步,没有别的,就是严格控制成员和身份。管理员不能依赖它们节点的身份,并且在节点之间强制实行绝对的负载隔离。这意味着,未授权的节点不能允许加入到集群中,并且,已经是集群一部分的节点不能改变身份,突然去伪装成另一个节点。

为解决这种情况,通过 Docker 企业版 Swarm 模式管理的节点,维护了健壮的、不可改变的身份。期望的特性是,通过使用两种关键的构建块去保证加密:

  1. 为集群成员使用 安全加入令牌 Secure join token
  2. 从一个集中化的认证机构发行的内嵌唯一身份的证书。
加入 Swarm

要加入 Swarm,节点需要一份 安全加入令牌 Secure join token 的副本。在集群内的每个操作角色的令牌都是独一无二的 —— 现在有两种类型的节点:工人(workers)和管理者(managers)。由于这种区分,拥有一个工人令牌的节点将不允许以管理者角色加入到集群。唯一得到这个特殊令牌的方式是通过 swarm 的管理 API 去向集群管理者请求一个。

令牌是安全的并且是随机生成的,它还有一个使得令牌泄露更容易被检测到的特殊语法:一个可以在你的日志和仓库中很容易监视的特殊前缀。幸运的是,即便发现一个泄露,令牌也可以很容易去更新,并且,推荐你经常去更新它们 —— 特别是,在一段时间中你的集群不进行扩大的情况下。

Docker Swarm

引导信任

作为它的身份标识创建的一部分,一个新的节点将向任意一个网络管理者请求发布一个新的身份。但是,在我们下面的威胁模型中,所有的通讯可以被一个第三方拦截。这种请求存在的问题是:一个节点怎么知道与它进行对话的对方是合法的管理者?

Docker Security

幸运的是,Docker 有一个内置机制可以避免这种情况。这个加入令牌被主机用于加入 Swarm,包含了一个根 CA 证书的哈希串。所以,主机可以使用单向 TLS,并且使用这个哈希串去验证它加入的 Swarm 是否正确:如果管理者持有的证书没有被正确的 CA 哈希串签名,节点就知道它不可信任。

节点身份发布和管理

在一个 Swarm 中,身份标识是内嵌在每个节点都单独持有的一个 x509 证书中。在一个最小权限原则的表现形式中,证书的私钥被绝对限制在主机的原始位置。尤其是,管理者不能访问除了它自己的私钥以外的任何一个私钥。

身份发布

要接收它们的证书而无需共享它们的私钥,新的主机通过发布一个证书签名请求(CSR)来开始,管理者收到证书签名请求之后,转换成一个证书。这个证书成为这个新的主机的身份标识,使这个节点成为 Swarm 的一个完全合格成员!

当和安全引导机制一起使用时,发行身份标识的这个机制来加入节点是缺省安全的:所有的通讯部分都是经过认证的、授权的,并且非敏感信息从来都不会以明文方式进行交换。

身份标识延期

尽管如此,给一个 Swarm 中安全地加入节点,仅仅是 “故事” 的一部分。为降低证书的泄露或者失窃造成的影响,并且移除管理 CRL 列表的复杂性,Swarm 模式为身份标识使用了较短存活周期的证书。这些证书缺省情况下三个月后将过期,但是,也可以配置为一个小时后即刻过期!

Docker secrets

较短的证书过期时间意味着不能手动去处理证书更新,所以,通常会使用一个 PKI 系统。对于 Swarm,所有的证书是以一种不中断的方式进行自动更新的。这个过程很简单:使用一个相互认证的 TLS 连接去证明一个特定身份标识的所有者,一个 Swarm 节点定期生成一个新的公钥/私钥密钥对,并且用相关的 CSR 去签名发送,创建一个维持相同身份标识的完整的新证书。

经过认证、授权、和加密的信息存储和传播。

在一个正常的 Swarm 的操作中,关于任务的信息被发送给去运行的工人(worker)节点。这里不仅仅包含将被一个节点运行的容器的信息;也包含那个容器运行所必需的资源的所有信息,包括敏感的机密信息,比如,私钥、密码和 API 令牌。

传输安全

事实上,参与 Swarm 的每个节点都拥有一个独一无二的 X509 格式的证书,因此,节点之间的通讯安全是没有问题的:节点使用它们各自的证书,与另一个连接方进行相互认证、继承机密、真实性、和 TLS 的完整性。

Swarm Mode

关于 Swarm 模式的一个有趣的细节是,本质上它是使用了一个推送模式:仅管理者被允许去发送信息到工人们(workers)—— 显著降低了暴露在低权限的工人节点面前的管理者节点的攻击面。

将负载严格隔离进安全区域

管理者节点的其中一个责任是,去决定发送到每个工人(worker)节点的任务是什么。管理者节点使用多种策略去做这个决定;根据每个节点和每个负载的特性,去跨 Swarm 去安排负载。

在使用 Swarm 模式的 Docker 企业版中,管理者节点通过使用附加到每个单个节点标识上的安全标签,去影响这些安排决定。这些标签允许管理者将节点组与不同的安全区域连接到一起,以限制敏感负载暴露,以及使相关机密信息更安全。

Docker Swarm Security

安全分发机密

除了加快身份标识发布过程之外,管理者节点还有存储和分发工人节点所需要的任何资源的任务。机密信息像任何其它类型的资源一样处理,并且基于安全的 mTLS 连接,从管理者推送到工人节点。

Docker Secrets

在主机上,Docker 企业版能确保机密仅提供给它们指定的容器。在同一个主机上的其它容器并不能访问它们。Docker 以一个临时文件系统的方式显露机密给一个容器,确保机密总是保存在内存中,并且从不写入到磁盘。这种方式比其它竞争的替代者更加安全,比如,在环境变量中存储它们。一旦这个任务完成,这个机密将永远消失。

存储机密

在管理者主机上的机密总是保持加密的。缺省情况下,加密这些机密的密钥(被称为数据加密密钥,DEK)是以明文的方式存储在硬盘上的。这使得那些对安全性要求较低的人可以轻松地去使用 Docker Swarm 模式。

但是,如果你运行一个生产集群,我们推荐你启用自动锁定模式。当自动锁定模式启用后,一个重新更新过的 DEK 被一个独立的加密密钥的密钥(KEK)所加密。这个密钥从不被存储在集群中;管理者有责任将它存储在一个安全可靠的地方,并且当集群启动的时候可以提供它。这就是所谓的 “解锁” Swarm。

根据 Raft 故障容错一致性算法,Swarm 模式支持多个管理者。在这个场景中,无缝扩展了机密存储的安全性。每个管理者主机除了共享密钥之外,还有一个唯一的磁盘加密密钥。幸运的是,Raft 日志在磁盘上也是加密的,并且,在自动锁定模式下,没有 KEK 同样是不可访问的。

当一个节点被攻陷后发生了什么?

Docker Secrets

在传统的编排器中,挽回一台被攻陷的主机是一个缓慢而复杂的过程。使用 Swarm 模式,恢复它就像运行一个 Docker 节点的 rm 命令一样容易。这是从集群中删除一个受影响的节点,而 Docker 将去处理剩下的事情,即,重新均衡负载,并且确保其它的主机已经知道,而不会去与受影响的节点通讯。

正如我们看到的那样,感谢最小权限的编排器,甚至是,如果攻击者在主机上持续活动,它们将被从剩余的网络上切断。主机的证书 —— 它的身份标识 —— 被列入黑名单,因此,管理者也不能有效访问它。

结论

使用 Swarm 模式的 Docker 企业版,在缺省情况下确保了编排器的所有关键区域的安全:

  • 加入集群。阻止恶意节点加入到集群。
  • 把主机分组为安全区域。阻止攻击者的横向移动。
  • 安排任务。任务将仅被委派到允许的节点。
  • 分配资源。恶意节点不能 “盗取” 其它的负载或者资源。
  • 存储机密。从不明文保存并且从不写入到工人节点的磁盘上。
  • 与工人节点的通讯。使用相互认证的 TLS 加密。

因为 Swarm 模式的持续改进,Docker 团队正在努力将最小权限原则进一步推进。我们正在处理的一个任务是:如果一个管理者被攻陷了,怎么去保证剩下的节点的安全?路线图已经有了,其中一些功能已经可以使用,比如,白名单功能,仅允许特定的 Docker 镜像,阻止管理者随意运行负载。这是通过 Docker 可信内容来实现的。


via: https://blog.docker.com/2017/10/least-privilege-container-orchestration/

作者:Diogo Mónica 译者:qhwdw 校对:wxy

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

2016 年末开始的 LinchPin,现在已经拥有一个 Python API 和一个成长中的社区。

去年,我的团队公布了 LinchPin,这是一个使用 Ansible 的混合云 编配 orchestration 工具。 配给 provision 云资源从来没有这么容易便捷过。借助 Ansible 强力支持,LinchPin 专注于简化,使云资源让用户可以触手可及。在这篇文章中,我将介绍 LinchPin,并且去看看过去的 10 个月该项目是如何逐渐成熟。

(LCTT 译注:关于 orchestration 应该翻译成惯例的“编排”还是“编配”,有个 @wffger 提出的建议 ,欢迎大家参与讨论。)

LinchPin 刚出现的时候,使用 ansible-playbook 命令去运行 LinchPin ,虽然可以完成,但是还是很复杂的,LinchPin 现在有一个前端命令行用户界面(CLI),它是用 Click 写的,而且它使 LinchPin 比以前更简化。

没有止步于 CLI,LinchPin 现在还有一个 Python API,它可以用于管理资源,比如,Amazon EC2 和 OpenStack 实例、网络、存储、安全组等等。这个 API 文档 可以在你想去尝试 LinchPin 的 Python API 时帮助你。

Playbook 是一个库

因为 LinchPin 的核心是 Ansible playbook,其角色、模块、过滤器,以及任何被称为 Ansible 模块的东西都被移进 LinchPin 库中,这意味着我们虽然可以直接调用 playbook,但它不是资源管理的首选机制。linchpin 可执行文件事实上已经成为该命令行的前端。

深入了解命令行

让我们深入了解 linchpin 命令行:

$ linchpin
Usage: linchpin [OPTIONS] COMMAND [ARGS]...

  linchpin: hybrid cloud orchestration

Options:
  -c, --config PATH       Path to config file
  -w, --workspace PATH    Use the specified workspace if the familiar Jenkins
                          $WORKSPACE environment variable is not set
  -v, --verbose           Enable verbose output
  --version               Prints the version and exits
  --creds-path PATH       Use the specified credentials path if WORKSPACE
                          environment variable is not set
  -h, --help              Show this message and exit.

Commands:
  init     Initializes a linchpin project.
  up       Provisions nodes from the given target(s) in...
  destroy  Destroys nodes from the given target(s) in...

你可以立即看到一个简单的描述,以及命令的选项和参数。这个帮助的最下面的三个命令是本文的重点内容。

配置文件

之前有个名为 linchpin_config.yml 的文件。但现在这个文件没有了,替换它的是一个 ini 形式的配置文件,称为 linchpin.conf。虽然这个文件可以被修改或放到别的地方,它可以放置在配置文件容易找到的库路径中。在多数情况下,linchpin.conf 文件是不需要去修改的。

工作空间

工作空间 workspace 是一个定义好的文件系统路径,它是一个逻辑上的资源组。一个工作空间可以认为是一个特定环境、服务组、或其它逻辑组的一个单点。它也可以是一个所有可管理资源的大的存储容器。

工作空间可以在命令行上使用 --workspace-w) 选项去指定,随后是工作空间路径。它也可以使用环境变量指定(比如,bash 中的 $WORKSPACE)。默认工作空间是当前目录。

初始化 (linchpin init)

运行 linchpin init 将生成一个需要的目录结构,以及一个 PinFiletopology、和 layout 文件的示例:

$ export WORKSPACE=/tmp/workspace
$ linchpin init
PinFile and file structure created at /tmp/workspace
$ cd /tmp/workspace/
$ tree
.
├── credentials
├── hooks
├── inventories
├── layouts
│   └── example-layout.yml
├── PinFile
├── resources
└── topologies
    └── example-topology.yml

在这个时候,可以执行 linchpin up ,然后提供一个 libvirt 虚拟机,和一个名为 linchpin-centos71 的网络。会生成一个 库存 inventory ,并放在 inventories/libvirt.inventory 目录中。它可以通过读取 topologies/example-topology.ymltopology_name 的值了解它。

配给 provisioning (linchpin up)

一旦有了一个 PinFile、拓扑、和一个可选的布局,就可以 配给 provisioning 了。

我们使用 dummy (模拟)工具,因为用它来配给非常简单;它不需要任何额外的东西(认证、网络、等等)。dummy 配给程序会创建一个临时文件,它表示所配给的主机。如果临时文件没有任何数据,说明主机没有被配给,或者它已经被销毁了。

dummy 配给程序的目录树大致如下:

$ tree
.
├── hooks
├── inventories
├── layouts
│   └── dummy-layout.yml
├── PinFile
├── resources
└── topologies
    └── dummy-cluster.yml

PinFile 也很简单;它指定了它的拓扑,并且为 dummy1 目标提供一个可选的布局:

---
dummy1:
  topology: dummy-cluster.yml
  layout: dummy-layout.yml

dummy-cluster.yml 拓扑文件是一个引用,指向到配给的三个 dummy_node 类型的资源:

---
topology_name: "dummy_cluster" # topology name
resource_groups:
  -
    resource_group_name: "dummy"
    resource_group_type: "dummy"
    resource_definitions:
      -
        name: "web"
        type: "dummy_node"
        count: 3

执行命令 linchpin up 将基于上面的 topology_name(在这个案例中是 dummy_cluster)生成 resourcesinventory 文件。

$ linchpin up
target: dummy1, action: up

$ ls {resources,inventories}/dummy*
inventories/dummy_cluster.inventory  resources/dummy_cluster.output

要验证 dummy 集群的资源,可以检查 /tmp/dummy.hosts

$ cat /tmp/dummy.hosts
web-0.example.net
web-1.example.net
web-2.example.net

Dummy 模块为假定的(或模拟的)配给提供了一个基本工具。关于在 OpenStack、AWS EC2、Google Cloud 上和 LinchPin 的更多详细情况,可以去看示例

库存 inventory 生成

作为上面提到的 PinFile 的一部分,可以指定一个 layout。如果这个文件被指定,并且放在一个正确的位置上,就会为配给的资源自动生成一个用于 Ansible 的静态 库存 inventory 文件:

---
inventory_layout:
  vars:
    hostname: __IP__
  hosts:
    example-node:
      count: 3
      host_groups:
        - example

linchpin up 运行完成,资源文件将提供一个很有用的详细信息。特别是,插入到静态库存的 IP 地址或主机名:

[example]
web-2.example.net hostname=web-2.example.net
web-1.example.net hostname=web-1.example.net
web-0.example.net hostname=web-0.example.net

[all]
web-2.example.net hostname=web-2.example.net
web-1.example.net hostname=web-1.example.net
web-0.example.net hostname=web-0.example.net

卸载 (linchpin destroy

LinchPin 也可以执行资源卸载。卸载动作一般认为该资源是已经配给好的;然而,因为 Ansible 是 幂等的 idempotent linchpin destroy 将仅检查确认该资源是启用的。如果这个资源已经是启用的,它将去卸载它。

命令 linchpin destroy 也将使用资源和/或拓扑文件去决定合适的卸载过程。

Ansible dummy 角色不使用资源,卸载期间仅有拓扑:

$ linchpin destroy
target: dummy1, action: destroy

$ cat /tmp/dummy.hosts
-- EMPTY FILE --

针对暂时的资源,卸载功能有一些限制,像网络、存储、等等。网络资源可以被用于多个云实例。在这种情况下,执行一个 linchpin destroy 某些资源就不能卸载。这取决于每个供应商的实现。查看每个供应商的具体实现。

LinchPin 的 Python API

linchpin 命令行中实现的功能大多数都是用 Python API 写的。这个 API,虽然不完整,但它已经成为 LinchPin 工具的至关重要的组件。

这个 API 由下面的三个包组成:

  • linchpin
  • linchpin.cli
  • linchpin.api

该命令行工具是基于 linchpin 包来管理的。它导入了 linchpin.cli 模块和类,该类是 linchpin.api 的子类。这样做的目的是为了允许使用 linchpin.api 来做其它的 LinchPin 实现,比如像计划中的 RESTful API。

更多信息,去查看 Python API library documentation on Read the Docs

Hook

LinchPin 1.0 的其中一个大的变化是转向 hook。hook 的目标是在 linchpin 运行期间的特定状态下,允许配置使用更多外部资源。目前的状态有:

  • preup: 在配给拓扑资源之前运行
  • postup: 在配给拓扑资源之后运行,并且生成可选的 库存 inventory
  • predestroy: 卸载拓扑资源之前运行
  • postdestroy: 卸载拓扑资源之后运行

在每种状态下,这些 hooks 允许运行外部脚本。存在几种类型的 hook,包括一个定制的叫做 Action Managers。这是一个内置的 Action Manager 的列表:

  • shell: 允许任何的 内联 inline 的 shell 命令,或者一个可运行的 shell 脚本
  • python: 运行一个 Python 脚本
  • ansible: 运行一个 Ansible playbook,允许传递一个 vars_fileextra_vars 作为 Python 字典
  • nodejs: 运行一个 Node.js 脚本
  • ruby: 运行一个 Ruby 脚本

hook 被绑定到一个特定的目标,并且每个目标使用时必须重新声明。将来,hook 将可能是全局的,然后它们在每个目标的 hooks 节下命名会更简单。

使用 hook

hook 描述起来非常简单,但理解它们强大的功能却并不简单。这个特性的存在是为了给用户灵活提供那些 LinchPin 开发者所没有考虑到的功能。这个概念可能会带来 ping 一套系统的简单方式,举个实例,比如在运行另一个 hook 之前。

更仔细地去研究 工作空间 ,你可能会注意到 hooks 目录,让我们看一下这个目录的结构:

$ tree hooks/
hooks/
├── ansible
│   ├── ping
│   │   └── dummy_ping.yaml
└── shell
    └── database
        ├── init_db.sh
        └── setup_db.sh

在任何情况下,hook 都可以用在 PinFile 中,展示如下:

---
dummy1:
  topology: dummy-cluster.yml
  layout: dummy-layout.yml
  hooks:
    postup:
      - name: ping
        type: ansible
        actions:
          - dummy_ping.yaml
      - name: database
        type: shell
        actions:
          - setup_db.sh
          - init_db.sh

基本概念是有三个 postup 动作要完成。Hook 是从上到下运行的,因此,Ansible ping 任务将首先运行,紧接着是两个 shell 任务, setup_db.shinit_db.sh。假设 hook 运行成功。将发生一个系统的 ping,然后,一个数据库被安装和初始化。

认证的驱动程序

在 LinchPin 的最初设计中,开发者决定在 Ansible playbooks 中管理认证;然而,逐渐有更多的 API 和命令行驱动的工具后,意味着认证将被置于 playbooks 库之外,并且还可以根据需要去传递认证值。

配置

让用户使用驱动程序提供的认证方法去完成这个任务。举个实例,如果对于 OpenStack 调用的拓扑,标准方法是使用一个 yaml 文件,或者类似于 OS_ 前缀的环境变量。clouds.yaml 文件是一个 profile 文件的组成部分,它有一个 auth 节:

clouds:
  default:
    auth:
      auth_url: http://stack.example.com:5000/v2.0/
      project_name: factory2
      username: factory-user
      password: password-is-not-a-good-password

更多详细信息在 OpenStack documentation

这个 clouds.yaml 或者任何其它认证文件位于 default_credentials_path (比如,~/.config/linchpin)中,并在拓扑中引用:

---
topology_name: openstack-test
resource_groups:
  -
    resource_group_name: linchpin
    resource_group_type: openstack
    resource_definitions:
      - name: resource
        type: os_server
        flavor: m1.small
        image: rhel-7.2-server-x86_64-released
        count: 1
        keypair: test-key
        networks:
          - test-net2
        fip_pool: 10.0.72.0/24
    credentials:
      filename: clouds.yaml
      profile: default

default_credentials_path 可以通过修改 linchpin.conf 改变。

拓扑在底部包含一个新的 credentials 节。使用 openstackec2、和 gcloud 模块,也可以去指定类似的凭据。认证驱动程序将查看给定的名为 clouds.yaml 的文件,并搜索名为 default配置

假设认证被找到并被加载,配给将正常继续。

简化

虽然 LinchPin 可以完成复杂的拓扑、库存布局、hooks、和认证管理,但是,终极目标是简化。通过使用一个命令行界面的简化,除了提升已经完成的 1.0 版的开发者体验外,LinchPin 将持续去展示复杂的配置可以很简单地去管理。

社区的成长

在过去的一年中,LinchPin 的社区现在已经有了 邮件列表和一个 IRC 频道(#linchpin on chat.freenode.net,而且在 GitHub 中我们很努力地管理它。

在过去的一年里,社区成员已经从 2 位核心开发者增加到大约 10 位贡献者。更多的人持续参与到项目中。如果你对 LinchPin 感兴趣,可以给我们写信、在 GitHub 上提问,加入 IRC,或者给我们发邮件。

这篇文章是基于 Clint Savage 在 OpenWest 上的演讲 Introducing LinchPin: Hybrid cloud provisioning using Ansible 整理的。OpenWest 将在 2017 年 7 月 12-15 日在盐城湖市举行。


作者简介:

Clint Savage - 工作于 Red Hat 是一位负责原子项目(Project Atomic)的高级软件工程师。他的工作是为 Fedora、CentOS、和 Red Hat Enterprise Linux(RHEL)提供自动原子服务器构建。


via: https://opensource.com/article/17/6/linchpin

作者:Clint Savage 译者:qhwdw 校对:wxy

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

想知道容器编排管理和 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中国 荣誉推出

云集成高级编排器 Cloud Integrated Advanced Orchestrator (Ciao) 是一个新的负载调度程序,用来解决当前云操作系统项目的局限性。Ciao 提供了一个轻量级,完全基于 TLS 的最小配置。它是 工作量无关的、易于更新、具有优化速度的调度程序,目前已针对 OpenStack 进行了优化。

其设计决策和创新方法在对安全性、可扩展性、可用性和可部署性的要求下进行:

  • 可扩展性: 初始设计目标是伸缩超过 5,000 个节点。因此,调度器架构用新的形式实现:

    • 在 ciao 中,决策制定是去中心化的。它基于拉取模型,允许计算节点从调度代理请求作业。调度程序总能知道启动器的容量,而不要求进行数据更新,并且将调度决策时间保持在最小。启动器异步向调度程序发送容量。
    • 持久化状态跟踪与调度程序决策制定相分离,它让调度程序保持轻量级。这种分离增加了可靠性、可扩展性和性能。结果是调度程序让出了权限并且这不是瓶颈。
  • 可用性: 虚拟机、容器和裸机集成到一个调度器中。所有的负载都被视为平等公民。为了更易于使用,网络通过一个组件间最小化的异步协议进行简化,只需要最少的配置。Ciao 还包括一个新的、简单的 UI。所有的这些功能都集成到一起来简化安装、配置、维护和操作。
  • 轻松部署: 升级应该是预期操作,而不是例外情况。这种新的去中心化状态的体系结构能够无缝升级。为了确保基础设施(例如 OpenStack)始终是最新的,它实现了持续集成/持续交付(CI/CD)模型。Ciao 的设计使得它可以立即杀死任何 Ciao 组件,更换它,并重新启动它,对可用性影响最小。
  • 安全性是必需的: 与调度程序的连接总是加密的:默认情况下 SSL 是打开的,而不是关闭的。加密是从端到端:所有外部连接都需要 HTTPS,组件之间的内部通信是基于 TLS 的。网络支持的一体化保障了租户分离。

初步结果证明是显著的:在 65 秒内启动一万个 Docker 容器和五千个虚拟机。进一步优化还在进行。


via: https://clearlinux.org/ciao

作者:ciao 译者:geekpi 校对:wxy

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

一旦公司越过了“让我们看看这些容器如何工作”的阶段,他们最终会在许多不同的地方运行容器

Man conducting orchestra

需要快速、高效地交付程序的公司 —— 而今天,哪些公司不需要这样做?—— 是那些正在转向 Linux 容器的公司。他们还发现,一旦公司越过了“让我们看看这些容器如何工作”的阶段,他们最终会在许多不同的地方运行容器。

Linux 容器技术不是新技术,但它随着最初由 Docker 发明的创新性打包格式(现在的 OCI 格式)以及新应用对持续开发和部署的需求开始变得流行。在 Red Hat 的 2016 年 5 月的 Forrester 研究中,有 48% 的受访者表示已经在开发中使用容器,今年的数字预计将达到 53%。只有五分之一的受访者表示,他们在 2017 年不会在开发过程中利用容器。

像乐高积木一样,容器镜像可以轻松地重用代码和服务。每个容器镜像就像一个单独的、旨在做好一部分工作的乐高积木。它可能是数据库、数据存储、甚至预订服务或分析服务。通过单独包装每个组件,从而可以在不同的应用中使用。但是,如果没有某种程序定义(即 指令手册 instruction booklet ),则难以在不同环境中创建完整应用程序的副本。那就是容器编排的来由。

life container megabricks

容器编排提供了像乐高系统这样的基础设施 —— 开发人员可以提供如何构建应用程序的简单说明。编排引擎将知道如何运行它。这使得可以轻松创建同一应用程序的多个副本,跨越开发人员电脑、CI/CD 系统,甚至生产数据中心和云提供商环境。

Linux 容器镜像允许公司在整个运行时环境(操作系统部件)中打包和隔离应用程序的构建块。在此基础上,通过容器编排,可以很容易地定义并运行所有的块,并一起构成完整的应用程序。一旦定义了完整的应用程序,它们就可以在不同的环境(开发、测试、生产等)之间移动,而不会破坏它们,且不改变它们的行为。

仔细调查容器

很明显,容器是有意义的,越来越多的公司像“对轮胎踹两脚”一样去研究容器。一开始,可能是一个开发人员使用一个容器工作,或是一组开发人员在使用多个容器。在后一种情况下,开发人员可能会随手编写一些代码来处理在容器部署超出单个实例之后快速出现的复杂性。

这一切都很好,毕竟他们是开发人员 —— 他们已经做到了。但即使在开发人员世界也会变得混乱,而且随手代码模式也没法跟着容器进入 QA 和生产环境下。

编排工具基本上做了两件事。首先,它们帮助开发人员定义他们的应用程序的表现 —— 一组用来构建应用程序实例的服务 —— 数据库、数据存储、Web 服务等。编排器帮助标准化应用程序的所有部分,在一起运行并彼此通信,我将这称之为标准化程序定义。其次,它们管理一个计算资源集群中启动、停止、升级和运行多个容器的过程,这在运行任何给定应用程序的多个副本时特别有用,例如持续集成 (CI) 和连续交付 (CD)。

想像一个公寓楼。居住在那里的每个人都有相同的街道地址,但每个人都有一个数字或字母或两者的组合,专门用来识别他或她。这是必要的,就像将正确的邮件和包裹交付给合适的租户一样。

同样,在容器中,只要你有两个容器或两个要运行这些容器的主机,你必须跟踪开发人员测试数据库连接或用户连接到正在运行的服务的位置。容器编排工具实质上有助于管理跨多个主机的容器的后勤。它们将生命周期管理功能扩展到由多个容器组成的完整应用程序,部署在一组机器上,从而允许用户将整个集群视为单个部署目标。

这真的很简单,又很复杂。编排工具提供了许多功能,从配置容器到识别和重新调度故障容器​​,将容器暴露给集群外的系统和服务,根据需要添加和删除容器等等。

虽然容器技术已经存在了一段时间,但容器编排工具只出现了几年。编排工具是 Google 从内部的高性能计算(HPC)和应用程序管理中吸取的经验教训开发的。在本质上,其要解决的就是在一堆服务器上运行一堆东西(批处理作业、服务等)。从那时起,编排工具已经进化到可以使公司能够战略性地利用容器。

一旦你的公司确定需要容器编排,下一步就是确定哪个平台对于业务是最有意义的。在评估容器编排时,请仔细查看(尤其):

  • 应用程序定义语言
  • 现有能力集
  • 添加新功能的速度
  • 开源还是专有
  • 社区健康度(成员的积极性/高效,成员提交的质量/数量,贡献者的个人和公司的多样性)
  • 强化努力
  • 参考架构
  • 认证
  • 产品化过程

有三个主要的容器编排平台,它们似乎领先于其他,每个都有自己的历史。

  1. Docker Swarm: Swarm 是容器典范 Docker 的附件。Swarm 允许用户建立并管理 Docker 节点的集群为单个虚拟系统。Swarm 似乎正在成为一个单一供应商的项目。
  2. Mesos: Mesos 是从 Apache 和高性能计算中成长起来的,因此是一个优秀的调度员。Mesos 的技术也非常先进,虽然与其他相比似乎没有发展速度或投资优势。
  3. Kubernetes: 由 Google 开发,由其内部编排工具 Borg 经验而来,Kubernetes 被广泛使用,并拥有强大的社区。其实这是 GitHub 上排名第一的项目。Mesos 目前可能比 Kubernetes 略有技术优势,但是 Kubernetes 是一个快速发展的项目,这也是为了长期技术上的收益而进行的架构投资。在不久的将来,在技术能力上应该能赶超 Mesos。

编排的未来

展望未来,企业们可以期待看到编排工具在应用程序和服务为中心的方向上发展。因为在现实中,如今快速应用程序开发实际上是在快速地利用服务、代码和数据的组合。无论这些服务是开源的,还是由内部团队部署的抑或从云提供商处购买的,未来将会是两者的混合。由于今天的编排器也在处理应用程序定义方面的挑战,所以期望看到它们越来越多地应对外部服务的整合。

此时此刻,想要充分利用容器的公司必须利用容器编排。

(题图:Thinkstock)


via: https://www.infoworld.com/article/3205304/containers/orchestration-tools-enable-companies-to-fully-exploit-linux-container-technology.html

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

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