mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
translated 20170706 OpenStack in a Snap.md (#5983)
* Delete 20170706 OpenStack in a Snap.md * Create 20170706 OpenStack in a Snap.md * Create 20170706 OpenStack in a Snap.md * Delete 20170706 OpenStack in a Snap.md * Update 20170706 OpenStack in a Snap.md
This commit is contained in:
Snapcraft
Ezio
parent
c1b4e6883c
commit
be7119005c
@ -1,199 +0,0 @@
|
||||
Snapcrafter is translating
|
||||
|
||||
OpenStack in a Snap
|
||||
============================================================
|
||||
|
||||
|
||||
### Share or save
|
||||
|
||||
|
||||
|
||||
OpenStack is complex and many of the community members are working hard to make the deployment and operation of OpenStack easier. Much of this time is focused on tools such as Ansible, Puppet, Kolla, Juju, Triple-O, Chef (to name a few). But what if we step down a level and also make the package experience easier?
|
||||
|
||||
With snaps we’re working on doing just that. Snaps are a new way of delivering software. The following description from [snapcraft.io][2] provides a good summary of the core benefits of snaps: _“Snaps are quick to install, easy to create, safe to run, and they update automatically and transactionally so your app is always fresh and never broken.”_
|
||||
|
||||
### Bundled software
|
||||
|
||||
A single snap can deliver multiple pieces of software from different sources to provide a solution that gets you up and running fast. You’ll notice that installing a snap is quick. That’s because when you install a snap, that single snap bundles all of its dependencies. That’s a bit different from installing a deb, where all of the dependencies get pulled down and installed separately.
|
||||
|
||||
### Snaps are easy to create
|
||||
|
||||
In my time working on Ubuntu, I’ve spent much of it working on Debian packaging for OpenStack. It’s a niche skill that takes quite a bit of time to understand the nuances of. When compared with snaps, the difference in complexity between deb packages and snaps is like night and day. Snaps are just plain simple to work on, and even quite fun!
|
||||
|
||||
### A few more features of snaps
|
||||
|
||||
* Each snap is installed in it’s own read-only squashfs filesystem.
|
||||
|
||||
* Each snap is run in a strict environment sandboxed by AppArmor and seccomp policy.
|
||||
|
||||
* Snaps are transactional. New versions of a snap install to a new read-only squashfs filesystem. If an upgrade fails, it will roll-back to the old version.
|
||||
|
||||
* Snaps will auto-refresh when new versions are available.
|
||||
|
||||
* OpenStack Snaps are guaranteed to be aligned with OpenStack’s upper-constraints. Packagers no longer need to maintain separate packages for the OpenStack dependency chain. Woo-hoo!
|
||||
|
||||
### Introducing the OpenStack Snaps!
|
||||
|
||||
We currently have the following projects snapped:
|
||||
|
||||
* **Keystone** – This snap provides the OpenStack identity service.
|
||||
|
||||
* **Glance** – This snap provides the OpenStack image service.
|
||||
|
||||
* **Neutron** – This snap specifically provides the ‘neutron-server’ process as part of a snap based OpenStack deployment.
|
||||
|
||||
* **Nova** – This snap provides the Nova controller component of an OpenStack deployment.
|
||||
|
||||
* **Nova-hypervisor** – This snap provides the hypervisor component of an OpenStack deployment, configured to use Libvirt/KVM + Open vSwitch which are installed using deb packages. This snap also includes nova-lxd, allowing for use of nova-lxd instead of KVM.
|
||||
|
||||
This is enough to get a minimal working OpenStack cloud. You can find the source for all of the OpenStack snaps on [github][3]. For more details on the OpenStack snaps please refer to the individual READMEs in the upstream repositories. There you can find more details for managing the snaps, such as overriding default configs, restarting services, setting up aliases, and more.
|
||||
|
||||
### Want to create your own OpenStack snap?
|
||||
|
||||
Check out the [snap cookie cutter][4]. I’ll be writing a blog post soon that walks you through using the snap cookie cutter. It’s really simple and will help get the creation of a new OpenStack snap bootstrapped in no time.
|
||||
|
||||
### Testing the OpenStack snaps
|
||||
|
||||
We’ve been using a simple script for initial testing of the OpenStack snaps. The script installs the snaps on a single node and provides additional post-install configuration for services. To try it out:
|
||||
|
||||
```
|
||||
git clone https://github.com/openstack-snaps/snap-test
|
||||
cd snap-test
|
||||
./snap-deploy
|
||||
```
|
||||
|
||||
At this point we’ve been doing all of our testing on Ubuntu Xenial (16.04). Also note that this will install and configure quite a bit of software on your system so you’ll likely want to run it on a disposable machine.
|
||||
|
||||
### Tracking OpenStack
|
||||
|
||||
Today you can install snaps from the edge channel of the snap store. For example:
|
||||
|
||||
```
|
||||
sudo snap install --edge keystone
|
||||
```
|
||||
|
||||
The OpenStack team is working toward getting CI/CD in place to enable publishing snaps across tracks for OpenStack releases (Ie. a track for ocata, another track for pike, etc). Within each track will be 4 different channels. The edge channel for each track will contain the tip of the OpenStack project’s corresponding branch, with the beta, candidate and release channels being reserved for released versions. This should result in an experience such as:
|
||||
|
||||
```
|
||||
sudo snap install --channel=ocata/stable keystone
|
||||
sudo snap install --channel=pike/edge keystone
|
||||
```
|
||||
|
||||
### Poking around
|
||||
|
||||
Snaps have various environment variables available to them that simplify the creation of the snap. They’re all documented [here][6]. You probably won’t need to know much about them to be honest, however there are a few locations that you’ll want to be familiar with once you’ve installed a snap:
|
||||
|
||||
### _$SNAP == /snap/<snap-name>/current_
|
||||
|
||||
This is where the snap and all of it’s files are mounted. Everything here is read-only. In my current install of keystone, $SNAP is /snap/keystone/91\. Fortunately you don’t need to know the current version number as there’s a symlink to that directory at /snap/keystone/current.
|
||||
|
||||
```
|
||||
$ ls /snap/keystone/current/
|
||||
bin etc pysqlite2-doc usr
|
||||
command-manage.wrapper include snap var
|
||||
command-nginx.wrapper lib snap-openstack.yaml
|
||||
command-uwsgi.wrapper meta templates
|
||||
|
||||
$ ls /snap/keystone/current/bin/
|
||||
alembic oslo-messaging-send-notification
|
||||
convert-json oslo-messaging-zmq-broker
|
||||
jsonschema oslo-messaging-zmq-proxy
|
||||
keystone-manage oslopolicy-checker
|
||||
keystone-wsgi-admin oslopolicy-list-redundant
|
||||
keystone-wsgi-public oslopolicy-policy-generator
|
||||
lockutils-wrapper oslopolicy-sample-generator
|
||||
make_metadata.py osprofiler
|
||||
mako-render parse_xsd2.py
|
||||
mdexport.py pbr
|
||||
merge_metadata.py pybabel
|
||||
migrate snap-openstack
|
||||
migrate-repository sqlformat
|
||||
netaddr uwsgi
|
||||
oslo-config-generator
|
||||
|
||||
$ ls /snap/keystone/current/usr/bin/
|
||||
2to3 idle pycompile python2.7-config
|
||||
2to3-2.7 pdb pydoc python2-config
|
||||
cautious-launcher pdb2.7 pydoc2.7 python-config
|
||||
compose pip pygettext pyversions
|
||||
dh_python2 pip2 pygettext2.7 run-mailcap
|
||||
easy_install pip2.7 python see
|
||||
easy_install-2.7 print python2 smtpd.py
|
||||
edit pyclean python2.7
|
||||
|
||||
$ ls /snap/keystone/current/lib/python2.7/site-packages/
|
||||
...
|
||||
```
|
||||
|
||||
### _$SNAP_COMMON == /var/snap/<snap-name>/common_
|
||||
|
||||
This directory is used for system data that is common across revisions of a snap. This is where you’ll override default config files and access log files.
|
||||
|
||||
```
|
||||
$ ls /var/snap/keystone/common/
|
||||
etc fernet-keys lib lock log run
|
||||
|
||||
$ sudo ls /var/snap/keystone/common/etc/
|
||||
keystone nginx uwsgi
|
||||
|
||||
$ ls /var/snap/keystone/common/log/
|
||||
keystone.log nginx-access.log nginx-error.log uwsgi.log
|
||||
```
|
||||
|
||||
### Strict confinement
|
||||
|
||||
The snaps all run under strict confinement, where each snap is run in a restricted environment that is sandboxed with seccomp and AppArmor policy. More details on snap confinement can be viewed [here][7].
|
||||
|
||||
### New features/updates coming for snaps
|
||||
|
||||
There are a few features and updates coming for snaps that I’m looking forward to:
|
||||
|
||||
* We’re working on getting libvirt AppArmor policy in place so that the nova-hypervisor snap can access qcow2 backing files.
|
||||
* For now, as a work-around, you can put virt-aa-helper in complain mode: sudo aa-complain /usr/lib/libvirt/virt-aa-helper
|
||||
|
||||
* We’re also working on getting additional snapd interface policy in place that will enable network connectivity for deployed instances.
|
||||
* For now you can install the nova-hypervisor snap in devmode, which disables security confinement: snap install –devmode –edge nova-hypervisor
|
||||
|
||||
* Auto-connecting nova-hypervisor interfaces. We’re working on getting the interfaces for the nova-hypervisor defined automatically at install time.
|
||||
* Interfaces define the AppArmor and seccomp policy that enables a snap to access resources on the system.
|
||||
|
||||
* For now you can manually connect the required interfaces as described in the nova-hypervisor snap’s README.
|
||||
|
||||
* Auto-alias support for commands. We’re working on getting auto-alias support defined for commands across the snaps, where aliases will be defined automatically at install time.
|
||||
* This enables use of the traditional command names. Instead of ‘nova.manage db sync‘ you’ll be able to issue ‘nova-manage db sync’ right after installing the snap.
|
||||
|
||||
* For now you can manually enable aliases after the snap is installed, such as ‘snap alias nova.manage nova-manage’. See the snap READMEs for more details.
|
||||
|
||||
* Auto-alias support for daemons. Currently snappy only supports aliases for commands (not daemons). Once alias support is available for daemons, we’ll set them up to be automatically configured at install time.
|
||||
* This enables use of the traditional unit file names. Instead of ‘systemctl restart snap.nova.nova-compute’ you’ll be able to issue ‘systemctl restart nova-compute’.
|
||||
|
||||
* Asset tracking for snaps. This will enables tracking of versions used to build the snap which can be re-used in future builds.
|
||||
|
||||
If you’d like to chat more about snaps you can find us on IRC in #openstack-snaps on freenode. We welcome your feedback and contributions! Thanks and have fun! Corey
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Corey Bryant is an Ubuntu core developer and software engineer at Canonical on the OpenStack Engineering team, primarily focusing on OpenStack packaging for Ubuntu and OpenStack charm development for Juju. He's passionate about open-source software and enjoys working with people from all over the world on a common cause.
|
||||
|
||||
|
||||
|
||||
------
|
||||
|
||||
via: 网址
|
||||
|
||||
作者：[ Corey Bryant ][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://insights.ubuntu.com/author/corey-bryant/
|
||||
[1]:https://insights.ubuntu.com/author/corey-bryant/
|
||||
[2]:http://snapcraft.io/
|
||||
[3]:https://github.com/openstack?utf8=%E2%9C%93&q=snap-&type=&language=
|
||||
[4]:https://github.com/openstack-snaps/snap-cookiecutter/blob/master/README.rst
|
||||
[5]:https://github.com/openstack-snaps/snap-test
|
||||
[6]:https://snapcraft.io/docs/reference/env
|
||||
[7]:https://snapcraft.io/docs/reference/confinement
|
||||
195
translated/tech/20170706 OpenStack in a Snap.md
Normal file
195
translated/tech/20170706 OpenStack in a Snap.md
Normal file
@ -0,0 +1,195 @@
|
||||
在 Snap 中玩转 OpenStack
|
||||
================================
|
||||
|
||||
|
||||
|
||||
OpenStack 非常复杂，许多社区成员都在努力使 OpenStack 的部署和操作更加容易。其中大部分时间都用来改善相关工具，如：Ansible、Puppet、Kolla、Juju、Triple-O 和 Chef (举几个例子)。但是，如果我们降低一下标准，并且还能使包的体验更加简单，将会怎样呢？
|
||||
|
||||
我们正在努力通过 snap 包来实现这一点。snap 包是一种新兴的软件分发方式，这段来自 [snapcraft.io][1] 的介绍很好的总结了它的主要优点：_snap 包可以快速安装、易于创建、安全运行而且能自动事物更新，因此你的应用程序总是能保持最新的状态并且永远不会被破坏。_
|
||||
|
||||
### 捆绑软件
|
||||
|
||||
单个 snap 包可以内嵌多个不同来源的软件，从而提供一个能够快速启动和运行的解决方案。当你安装 snap 包时，你会发现安装速度是很快的，这是因为单个 snap 包捆绑了所有它需要的依赖。这和安装 deb 包有些不同，因为它需要下载所有的依赖然后分别进行安装。
|
||||
|
||||
### Snap 包制作简单
|
||||
|
||||
在 Ubuntu 工作，我花了很多时间为 Debian 制作 OpenStack 的安装包。这是一种很特殊技能，需要花很长时间才能理解其中的细微差别。与 snap 包相比，deb 包和 snap 包在复杂性上的差异有天壤之别。snap 包简单易行，并且相当有趣。
|
||||
|
||||
### Snap 包其他的特性
|
||||
|
||||
* 每个 snap 包都安装在其独有的只读 squashfs 文件系统中。
|
||||
|
||||
* 每个 snap 包都运行在一个由 AppArmor 和 seccomp 策略构建的严格沙箱环境中。
|
||||
|
||||
* snap 包能事物更新。新版本的 snap 包会安装到一个新的只读 squashfs 文件系统中。如果升级失败，它将回滚到旧版本。
|
||||
|
||||
* 当有新版本可用时，snap 包将自动更新。
|
||||
|
||||
* OpenStack 的 snap 包能保证与 OpenStack 的上游约束保持一致。打包的人不需要再为 OpenStack 依赖链维护单独的包。这真是太爽了!
|
||||
|
||||
### OpenStack snap 包介绍
|
||||
|
||||
现在，下面这些项目已经有了相应的 snap 包：
|
||||
|
||||
* `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.）
|
||||
|
||||
* `Nova` —— 这个 snap 包提供 OpenStack 部署过程中的 Nova 控制器组件。
|
||||
* `Nova-hypervisor` —— 这个 snap 包提供 OpenStack 部署过程中的 hypervisor 组件，并且配置使用通过 deb 包安装的 Libvirt/KVM + Open vSwitch 组合。这个 snap 包同时也包含 nava-lxd，这允许我们使用 nova-lxd 而不用 KVM。
|
||||
|
||||
这些 snpa 包已经能让我们部署一个简单可工作的 OpenStack 云。你可以在 [github][2] 上找到所有这些 OpenStack snap 包的源码。有关 OpenStack snap 包更多的细节，请参考上游存储库中各自的 README。在那里，你可以找到更多有关管理 snap 包的信息，比如覆盖默认配置、重启服务、设置别名等等。
|
||||
|
||||
### 想要创建自己的 OpenStack snap 包吗?
|
||||
|
||||
查看 [snap cookie 工具][3]。我很快就会写一篇博文，告诉你如何使用 snap cookie 工具。它非常简单，并且能帮助你在任何时候创建一个新的 OpenStack snap 包。
|
||||
|
||||
### 测试 OpenStack snap 包
|
||||
|
||||
我们已经用简单的脚本初步测试了 OpenStack snap 包。这个脚本会在单个节点上安装 sanp 包，还会在安装后提供额外的配置服务。来尝试下吧：
|
||||
|
||||
```
|
||||
git clone https://github.com/openstack-snaps/snap-test
|
||||
cd snap-test
|
||||
./snap-deploy
|
||||
```
|
||||
|
||||
这样，我们就已经在 Ubuntu Xenial（16.04） 上做了所有的测试。要注意的是，这将在你的系统上安装和配置相当多的软件，因此你最好在可自由使用的机器上运行它。
|
||||
|
||||
### 追踪 OpenStack
|
||||
|
||||
现在，你可以从 snap 商店的边缘通道来安装 snap 包，比如：
|
||||
|
||||
```
|
||||
sudo snap install --edge keystone
|
||||
```
|
||||
OpenStack 团队正在努力使 CI/CD 配置到位，以便让 snap 包的发布能够交叉追踪 OpenStack 的发布（比如一个追踪 Ocata，另一个追踪 Pike 等）。每个轨道都有 4 个不同的通道。每个轨道的边缘通道将包含 OpenStack 项目对应分支最近的内容，测试、候选和稳定通道被保留用于已发布的版本。这样我们将看到如下的用法：
|
||||
|
||||
```
|
||||
sudo snap install --channel=ocata/stable keystone
|
||||
sudo snap install --channel=pike/edge keystone
|
||||
```
|
||||
|
||||
### 闲逛（原文：Poking around）
|
||||
|
||||
我们可以使用多个环境变量来简化 snap 包的制作。[这里][5] 有相关的说明。实际上，你无需深入的研究他们，但是在安装完 snap 包后，你也许会想要了解这些位置：
|
||||
|
||||
|
||||
### $SNAP == /snap/< snap-name >/current （这里 < snap-name > 显示有问题，所以多加了空格）
|
||||
|
||||
|
||||
这是 snap 包和它所有的文件挂载的位置。所有东西都是只读的。比如我当前安装的 keystone，$SNAP 就是 /snap/keystone/91。幸好，你不需要知道当前版本号，因为在 /snap/keystone/（LCTT注：/snap/keystone/current/） 中有一个软链接指向当前正在使用版本对应的文件夹。
|
||||
|
||||
```
|
||||
$ ls /snap/keystone/current/
|
||||
bin etc pysqlite2-doc usr
|
||||
command-manage.wrapper include snap var
|
||||
command-nginx.wrapper lib snap-openstack.yaml
|
||||
command-uwsgi.wrapper meta templates
|
||||
|
||||
$ ls /snap/keystone/current/bin/
|
||||
alembic oslo-messaging-send-notification
|
||||
convert-json oslo-messaging-zmq-broker
|
||||
jsonschema oslo-messaging-zmq-proxy
|
||||
keystone-manage oslopolicy-checker
|
||||
keystone-wsgi-admin oslopolicy-list-redundant
|
||||
keystone-wsgi-public oslopolicy-policy-generator
|
||||
lockutils-wrapper oslopolicy-sample-generator
|
||||
make_metadata.py osprofiler
|
||||
mako-render parse_xsd2.py
|
||||
mdexport.py pbr
|
||||
merge_metadata.py pybabel
|
||||
migrate snap-openstack
|
||||
migrate-repository sqlformat
|
||||
netaddr uwsgi
|
||||
oslo-config-generator
|
||||
|
||||
$ ls /snap/keystone/current/usr/bin/
|
||||
2to3 idle pycompile python2.7-config
|
||||
2to3-2.7 pdb pydoc python2-config
|
||||
cautious-launcher pdb2.7 pydoc2.7 python-config
|
||||
compose pip pygettext pyversions
|
||||
dh_python2 pip2 pygettext2.7 run-mailcap
|
||||
easy_install pip2.7 python see
|
||||
easy_install-2.7 print python2 smtpd.py
|
||||
edit pyclean python2.7
|
||||
|
||||
$ ls /snap/keystone/current/lib/python2.7/site-packages/
|
||||
...
|
||||
```
|
||||
|
||||
### $SNAP_COMMON == /var/snap/< snap-name >/common （这里 < snap-name > 显示有问题，所以多加了空格）
|
||||
|
||||
这个目录用于存放系统数据，对于 snap 包的多个修订版本这些数据是共用的。在这里，你可以覆盖默认配置文件和访问日志文件。
|
||||
|
||||
```
|
||||
$ ls /var/snap/keystone/common/
|
||||
etc fernet-keys lib lock log run
|
||||
|
||||
$ sudo ls /var/snap/keystone/common/etc/
|
||||
keystone nginx uwsgi
|
||||
|
||||
$ ls /var/snap/keystone/common/log/
|
||||
keystone.log nginx-access.log nginx-error.log uwsgi.log
|
||||
```
|
||||
|
||||
### 严格限制
|
||||
|
||||
每个 snap 包都是在一个由 seccomp 和 AppArmor 策略构建的严格限制的环境中运行的。更多关于 snap 约束的细节可以在 [这里][7] 查看。
|
||||
|
||||
### snap 包即将到来的新特性和更新
|
||||
|
||||
|
||||
我正在期待 snap 包一些即将到来的新特性和更新（LCTT注：此文发表于 7 月 6 日）：
|
||||
|
||||
* 我们正在致力于实现 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 接口。
|
||||
* 定义 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
|
||||
|
||||
------
|
||||
|
||||
作者简介：
|
||||
|
||||
Corey Bryant 是 Ubuntu 的核心开发者和 Canonical 公司 OpenStack 工程团队的软件工程师，他主要专注于为 Ubuntu 提供 OpenStack 的安装包以及为 Juju 进行 OpenStack 的魅力开发。他对开源软件充满热情，喜欢与来自世界各地的人一起工作。
|
||||
|
||||
译者简介：
|
||||
|
||||
> snapcraft.io 的钉子户，对 Ubuntu Core、Snaps 和 Snapcraft 有着浓厚的兴趣，并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号： `Snapcraft`，最近会在上面连载几篇有关 Core snap 发布策略、交付流程和验证流程的文章，欢迎围观 :）
|
||||
|
||||
------
|
||||
|
||||
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)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
|
||||
[a]:https://insights.ubuntu.com/author/corey-bryant/
|
||||
|
||||
[1]: http://snapcraft.io/
|
||||
[2]:https://github.com/openstack?utf8=%E2%9C%93&q=snap-&type=&language=
|
||||
[3]:https://github.com/openstack-snaps/snap-cookiecutter/blob/master/README.rst
|
||||
[4]:https://snapcraft.io/docs/reference/env
|
||||
[5]: https://snapcraft.io/docs/reference/env
|
||||
[6]:https://snapcraft.io/docs/reference/confinement
|
||||
[7]: https://snapcraft.io/docs/reference/confinement
|
||||
Loading…
Reference in New Issue
Block a user