diff --git a/translated/tech/20170706 OpenStack in a Snap.md b/published/20170706 OpenStack in a Snap.md similarity index 82% rename from translated/tech/20170706 OpenStack in a Snap.md rename to published/20170706 OpenStack in a Snap.md index 058f5a743a..c5a1a4d487 100644 --- a/translated/tech/20170706 OpenStack in a Snap.md +++ b/published/20170706 OpenStack in a Snap.md @@ -3,9 +3,9 @@ ![](https://insights.ubuntu.com/wp-content/uploads/646b/openstaack-in-a-snap.png) -OpenStack 非常复杂，许多社区成员都在努力使 OpenStack 的部署和操作更加容易。其中大部分时间都用来改善相关工具，如：Ansible、Puppet、Kolla、Juju、Triple-O 和 Chef (举几个例子)。但是，如果我们降低一下标准，并且还能使包的体验更加简单，将会怎样呢？ +OpenStack 非常复杂，许多社区成员都在努力使 OpenStack 的部署和操作更加容易。其中大部分时间都用来改善相关工具，如：Ansible、Puppet、Kolla、Juju、Triple-O 和 Chef (仅举几例)。但是，如果我们降低一下标准，并且还能使包的体验更加简单，将会怎样呢？ -我们正在努力通过 snap 包来实现这一点。snap 包是一种新兴的软件分发方式，这段来自 [snapcraft.io][1] 的介绍很好的总结了它的主要优点：_snap 包可以快速安装、易于创建、安全运行而且能自动事物更新，因此你的应用程序总是能保持最新的状态并且永远不会被破坏。_ +我们正在努力通过 snap 包来实现这一点。snap 包是一种新兴的软件分发方式，这段来自 [snapcraft.io][1] 的介绍很好的总结了它的主要优点：_snap 包可以快速安装、易于创建、安全运行而且能自动地事务化更新，因此你的应用程序总是能保持最新的状态并且永远不会被破坏。_ ### 捆绑软件 @@ -13,28 +13,23 @@ OpenStack 非常复杂，许多社区成员都在努力使 OpenStack 的部署 ### Snap 包制作简单 -在 Ubuntu 工作，我花了很多时间为 Debian 制作 OpenStack 的安装包。这是一种很特殊技能，需要花很长时间才能理解其中的细微差别。与 snap 包相比，deb 包和 snap 包在复杂性上的差异有天壤之别。snap 包简单易行，并且相当有趣。 +在 Ubuntu 工作的时候，我花了很多时间为 Debian 制作 OpenStack 的安装包。这是一种很特殊技能，需要花很长时间才能理解其中的细微差别。与 snap 包相比，deb 包和 snap 包在复杂性上的差异有天壤之别。snap 包简单易行，并且相当有趣。 -### Snap 包其他的特性 +### Snap 包的其它特性 * 每个 snap 包都安装在其独有的只读 squashfs 文件系统中。 - * 每个 snap 包都运行在一个由 AppArmor 和 seccomp 策略构建的严格沙箱环境中。 - -* snap 包能事物更新。新版本的 snap 包会安装到一个新的只读 squashfs 文件系统中。如果升级失败，它将回滚到旧版本。 - +* snap 包能事务更新。新版本的 snap 包会安装到一个新的只读 squashfs 文件系统中。如果升级失败，它将回滚到旧版本。 * 当有新版本可用时，snap 包将自动更新。 - * OpenStack 的 snap 包能保证与 OpenStack 的上游约束保持一致。打包的人不需要再为 OpenStack 依赖链维护单独的包。这真是太爽了! ### OpenStack snap 包介绍 现在，下面这些项目已经有了相应的 snap 包： -* `Keystone` —— 这个 snap 包为 OpenStack 提供了身份服务。 +* `Keystone` —— 这个 snap 包为 OpenStack 提供了身份鉴证服务。 * `Glance` —— 这个 snap 包为 OpenStack 提供了镜像服务。 -* `Neutron` —— 这个 snap 包专门提供了 `网络-服务器` 过程，作为 OpenStack 部署过程的一个 snap 包。（原文：**Neutron** – This snap specifically provides the `neutron-server` process as part of a snap based OpenStack deployment.） - +* `Neutron` —— 这个 snap 包专门提供了 neutron-server 过程，作为 OpenStack 部署过程的一个 snap 包。 * `Nova` —— 这个 snap 包提供 OpenStack 部署过程中的 Nova 控制器组件。 * `Nova-hypervisor` —— 这个 snap 包提供 OpenStack 部署过程中的 hypervisor 组件，并且配置使用通过 deb 包安装的 Libvirt/KVM + Open vSwitch 组合。这个 snap 包同时也包含 nava-lxd，这允许我们使用 nova-lxd 而不用 KVM。 @@ -63,22 +58,21 @@ cd snap-test ``` sudo snap install --edge keystone ``` -OpenStack 团队正在努力使 CI/CD 配置到位，以便让 snap 包的发布能够交叉追踪 OpenStack 的发布（比如一个追踪 Ocata，另一个追踪 Pike 等）。每个轨道都有 4 个不同的通道。每个轨道的边缘通道将包含 OpenStack 项目对应分支最近的内容，测试、候选和稳定通道被保留用于已发布的版本。这样我们将看到如下的用法： + +OpenStack 团队正在努力使 CI/CD 配置到位，以便让 snap 包的发布能够交叉追踪 OpenStack 的发布（比如一个追踪 Ocata，另一个追踪 Pike 等）。每个轨道track都有 4 个不同的通道。每个轨道的边缘通道将包含 OpenStack 项目对应分支最近的内容，测试、候选和稳定通道被保留用于已发布的版本。这样我们将看到如下的用法： ``` sudo snap install --channel=ocata/stable keystone sudo snap install --channel=pike/edge keystone ``` -### 闲逛（原文：Poking around） +### 其它 我们可以使用多个环境变量来简化 snap 包的制作。[这里][5] 有相关的说明。实际上，你无需深入的研究他们，但是在安装完 snap 包后，你也许会想要了解这些位置： +#### `$SNAP == /snap//current` -### $SNAP == /snap/< snap-name >/current （这里 < snap-name > 显示有问题，所以多加了空格） - - -这是 snap 包和它所有的文件挂载的位置。所有东西都是只读的。比如我当前安装的 keystone，$SNAP 就是 /snap/keystone/91。幸好，你不需要知道当前版本号，因为在 /snap/keystone/（LCTT注：/snap/keystone/current/） 中有一个软链接指向当前正在使用版本对应的文件夹。 +这是 snap 包和它所有的文件挂载的位置。所有东西都是只读的。比如我当前安装的 keystone，$SNAP 就是 `/snap/keystone/91`。幸好，你不需要知道当前版本号，因为在 `/snap/keystone/` 中有一个软链接（LCTT 译注：`/snap/keystone/current/`）指向当前正在使用版本对应的文件夹。 ``` $ ls /snap/keystone/current/ @@ -118,7 +112,7 @@ $ ls /snap/keystone/current/lib/python2.7/site-packages/ ... ``` -### $SNAP_COMMON == /var/snap/< snap-name >/common （这里 < snap-name > 显示有问题，所以多加了空格） +#### `$SNAP_COMMON == /var/snap//common` 这个目录用于存放系统数据，对于 snap 包的多个修订版本这些数据是共用的。在这里，你可以覆盖默认配置文件和访问日志文件。 @@ -139,26 +133,20 @@ keystone.log nginx-access.log nginx-error.log uwsgi.log ### snap 包即将到来的新特性和更新 +我正在期待 snap 包一些即将到来的新特性和更新（LCTT 译注：此文发表于 7 月 6 日）： -我正在期待 snap 包一些即将到来的新特性和更新（LCTT注：此文发表于 7 月 6 日）： - -* 我们正在致力于实现 libvirt AppArmor 策略，这样 nova-hypervisor 的 snap 包就能够访问 qcow2 的支持文件（英文：backing files）。 +* 我们正在致力于实现 libvirt AppArmor 策略，这样 nova-hypervisor 的 snap 包就能够访问 qcow2 的支持文件backing files。 * 现在，作为一种变通方法，你可以将 virt-aa-helper 放在 complain 模式下：`sudo aa-complain /usr/lib/libvirt/virt-aa-helper`。 - * 我们还在为 snapd 开发额外的接口策略，以便为部署的实例启用网络连接。 * 现在你可以在 devmode 模式下安装 nova-hypervisor snap 包，它会禁用安全限制：`snap install -devmode -edge nova-hypervisor`。 - -* 自动连接 nova-hypervisor 的接口。我们正在努力实现在安装时自动定义 nova - hypervisor 接口。 +* 自动连接 nova-hypervisor 的接口。我们正在努力实现在安装时自动定义 nova-hypervisor 接口。 * 定义 AppArmor 和 seccomp 策略的接口可以允许 snap 包访问系统的资源。 * 现在，你可以手动连接需要接口，在 nova-hypervisor snap 包的 README 中有相关的描述。 - * 命令自动定义别名。我们正在努力实现 snap 包在安装时为命令自动定义别名。 * 这使得我们可以使用传统的命令名。安装 snap 包后，你将可以使用 `nova-manage db sync` 而无需再用 `nova.manage db sync`。 * 现在，你可以在安装 snap 包后手动设置别名，比如：`snap alias nova.manage nova-manage`。如想获取更多细节请查看 snap 包的 README 。 - * 守护进程自动定义别名。当前 snappy 仅支持为命令（非守护进程）定义别名。一旦针对守护进程的别名可用了，我们将设置它们在安装的时候自动配置。 * 这使得我们可以使用额外的单元文件名。我们可以使用 `systemctl restart nova-compute` 而无需再用 `systemctl restart snap.nova.nova-compute`。 - * snap 包资产跟踪。这使得我们可以追踪用来构建 snap 包的版本以便在将来构建时重复使用。 如果你想多聊一些关于 snap 包的内容，你可以在 freenode 的 #openstack-snaps 这样的 IRC 上找到我们。我们欢迎你的反馈和贡献！感谢并祝你玩得开心！Corey @@ -179,7 +167,7 @@ via: https://insights.ubuntu.com/2017/07/06/openstack-in-a-snap/ 作者：[Corey Bryant][a] 译者：[Snapcrafter](https://github.com/Snapcrafter) -校对：[校对者ID](https://github.com/校对者ID) +校对：[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出