标签 snap 下的文章

OpenStack 非常复杂,许多社区成员都在努力使 OpenStack 的部署和操作更加容易。其中大部分时间都用来改善相关工具,如:Ansible、Puppet、Kolla、Juju、Triple-O 和 Chef (仅举几例)。但是,如果我们降低一下标准,并且还能使包的体验更加简单,将会怎样呢?

我们正在努力通过 snap 包来实现这一点。snap 包是一种新兴的软件分发方式,这段来自 snapcraft.io 的介绍很好的总结了它的主要优点: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 包专门提供了 neutron-server 过程,作为 OpenStack 部署过程的一个 snap 包。
  • Nova —— 这个 snap 包提供 OpenStack 部署过程中的 Nova 控制器组件。
  • Nova-hypervisor —— 这个 snap 包提供 OpenStack 部署过程中的 hypervisor 组件,并且配置使用通过 deb 包安装的 Libvirt/KVM + Open vSwitch 组合。这个 snap 包同时也包含 nava-lxd,这允许我们使用 nova-lxd 而不用 KVM。

这些 snpa 包已经能让我们部署一个简单可工作的 OpenStack 云。你可以在 github 上找到所有这些 OpenStack snap 包的源码。有关 OpenStack snap 包更多的细节,请参考上游存储库中各自的 README。在那里,你可以找到更多有关管理 snap 包的信息,比如覆盖默认配置、重启服务、设置别名等等。

想要创建自己的 OpenStack snap 包吗?

查看 snap cookie 工具。我很快就会写一篇博文,告诉你如何使用 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 等)。每个 轨道 track 都有 4 个不同的通道。每个轨道的边缘通道将包含 OpenStack 项目对应分支最近的内容,测试、候选和稳定通道被保留用于已发布的版本。这样我们将看到如下的用法:

sudo snap install --channel=ocata/stable keystone
sudo snap install --channel=pike/edge keystone

其它

我们可以使用多个环境变量来简化 snap 包的制作。这里 有相关的说明。实际上,你无需深入的研究他们,但是在安装完 snap 包后,你也许会想要了解这些位置:

$SNAP == /snap/<snap-name>/current

这是 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 包的多个修订版本这些数据是共用的。在这里,你可以覆盖默认配置文件和访问日志文件。

$ 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 约束的细节可以在 这里 查看。

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 译者:Snapcrafter 校对:wxy

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

snapcraft 是一个正在为其在 Linux 中的地位而奋斗的包管理系统,它为你重新设想了分发软件的方式。这套新的跨发行版的工具可以用来帮助你构建和发布 snap 软件包。接下来我们将会讲述怎么使用 CircleCI 2.0 来加速这个过程以及一些在这个过程中的可能遇到的问题。

snap 软件包是什么?snapcraft 又是什么?

snap 是用于 Linux 发行版的软件包,它们在设计的时候吸取了像 Android 这样的移动平台和物联网设备上分发软件的经验教训。snapcraft 这个名字涵盖了 snap 和用来构建它们的命令行工具、这个 snapcraft.io 网站,以及在这些技术的支撑下构建的几乎整个生态系统。

snap 软件包被设计成用来隔离并封装整个应用程序。这些概念使得 snapcraft 提高软件安全性、稳定性和可移植性的目标得以实现,其中可移植性允许单个 snap 软件包不仅可以在 Ubuntu 的多个版本中安装,而且也可以在 Debian、Fedora 和 Arch 等发行版中安装。snapcraft 网站对其的描述如下:

为每个 Linux 桌面、服务器、云端或设备打包任何应用程序,并且直接交付更新。

在 CircleCI 2.0 上构建 snap 软件包

在 CircleCI 上使用 CircleCI 2.0 语法 来构建 snap 和在本地机器上基本相同。在本文中,我们将会讲解一个示例配置文件。如果您对 CircleCI 还不熟悉,或者想了解更多有关 2.0 的入门知识,您可以从 这里 开始。

基础配置

version: 2
jobs:
  build:
    machine: true
    working_directory: ~/project
    steps:
      - checkout
      - run:
          command: |
            sudo apt update && sudo apt install -y snapd
            sudo snap install snapcraft --edge --classic
            /snap/bin/snapcraft

这个例子使用了 machine 执行器来安装用于管理运行 snap 的可执行程序 snapd 和制作 snap 的 snapcraft 工具。

由于构建过程需要使用比较新的内核,所以我们使用了 machine 执行器而没有用 docker 执行器。在这里,Linux v4.4 已经足够满足我们的需求了。

用户空间的依赖关系

上面的例子使用了 machine 执行器,它实际上是一个内核为 Linux v4.4 的 Ubuntu 14.04 (Trusty) 虚拟机。如果 Trusty 仓库可以满足你的 project/snap 构建依赖,那就没问题。如果你的构建依赖需要其他版本,比如 Ubuntu 16.04 (Xenial),我们仍然可以在 machine 执行器中使用 Docker 来构建我们的 snap 软件包 。

version: 2
jobs:
  build:
    machine: true
    working_directory: ~/project
    steps:
      - checkout
      - run:
          command: |
            sudo apt update && sudo apt install -y snapd
            docker run -v $(pwd):$(pwd) -t ubuntu:xenial sh -c "apt update -qq && apt install snapcraft -y && cd $(pwd) && snapcraft"

这个例子中,我们再次在 machine 执行器的虚拟机中安装了 snapd,但是我们决定将 snapcraft 安装在 Ubuntu Xenial 镜像构建的 Docker 容器中,并使用它来构建我们的 snap。这样,在 snapcraft 运行的过程中就可以使用在 Ubuntu 16.04 中可用的所有 apt 包。

测试

在我们的博客文档以及互联网上已经有很多讲述如何对软件代码进行单元测试的内容。搜索你的语言或者框架和单元测试或者 CI 可以找到大量相关的信息。在 CircleCI 上构建 snap 软件包,我们最终会得到一个 .snap 的文件,这意味着除了创造它的代码外我们还可以对它进行测试。

工作流

假设我们构建的 snap 软件包是一个 webapp,我们可以通过测试套件来确保构建的 snap 可以正确的安装和运行,我们也可以试着安装它或者使用 Selenium 来测试页面加载、登录等功能正常工作。但是这里有一个问题,由于 snap 是被设计成可以在多个 Linux 发行版上运行,这就需要我们的测试套件可以在 Ubuntu 16.04、Fedora 25 和 Debian 9 等发行版中可以正常运行。这个问题我们可以通过 CircleCI 2.0 的工作流来有效地解决。

工作流是在最近的 CircleCI 2.0 测试版中加入的,它允许我们通过特定的逻辑流程来运行离散的任务。这样,使用单个任务构建完 snap 后,我们就可以开始并行的运行 snap 的发行版测试任务,每个任务对应一个不同的发行版的 Docker 镜像 (或者在将来,还会有其他可用的执行器)。

这里有一个简单的例子:

workflows:
  version: 2
  build-test-and-deploy:
    jobs:
      - build
      - acceptance_test_xenial:
          requires:
            - build
      - acceptance_test_fedora_25:
          requires:
            - build
      - acceptance_test_arch:
          requires:
            - build
      - publish:
          requires:
            - acceptance_test_xenial
            - acceptance_test_fedora_25
            - acceptance_test_arch

在这个例子中首先构建了 snap,然后在四个不同的发行版上运行验收测试。如果所有的发行版都通过测试了,那么我们就可以运行发布 job,以便在将其推送到 snap 商店之前完成剩余的 snap 任务。

留着 .snap 包

为了测试我们在工作流示例中使用的 .snap 软件包,我们需要一种在构建的时候持久保存 snap 的方法。在这里我将提供两种方法:

  1. artifact —— 在运行 build 任务的时候我们可以将 snaps 保存为一个 CircleCI 的 artifact(LCTT 译注:artifact 是 snapcraft.yaml 中的一个 Plugin-specific 关键字),然后在接下来的任务中检索它。CircleCI 工作流有自己处理共享 artifact 的方式,相关信息可以在 这里 找到。
  2. snap 商店通道 —— 当发布 snap 软件包到 snap 商店时,有多种通道可供我们选择。将 snap 的主分支发布到 edge 通道以供内部或者用户测试已经成为一种常见做法。我们可以在 build 任务中完成这些工作,然后接下来的的任务就可以从 edge 通道来安装构建好的 snap 软件包。

第一种方法速度更快,并且它还可以在 snap 软包上传到 snap 商店供用户甚至是测试用户使用之前对 snap 进行验收测试。第二种方法的好处是我们可以从 snap 商店安装 snap,这也是 CI 运行期间的测试项之一。

snap 商店的身份验证

snapcraft-config-generator.py 脚本可以生成商店证书并将其保存到 .snapcraft/snapcraft.cfg 中(注意:在运行公共脚本之前一定要对其进行检查)。如果觉得在你仓库中使用明文来保存这个文件不安全,你可以用 base64 编码该文件,并将其存储为一个私有环境变量,或者你也可以对文件 进行加密,并将密钥存储在一个私有环境变量中。

下面是一个示例,将商店证书放在一个加密的文件中,并在 deploy 环节中使用它将 snap 发布到 snap 商店中。

- deploy:
    name: Push to Snap Store
    command: |
      openssl aes-256-cbc -d -in .snapcraft/snapcraft.encrypted -out .snapcraft/snapcraft.cfg -k $KEY
      /snap/bin/snapcraft push *.snap

除了 deploy 任务之外,工作流示例同之前的一样, deploy 任务只有当验收测试任务通过时才会运行。

更多的信息

  • Alan Pope 在 论坛中发的帖子:“popey” 是 Canonical 的员工,他在 snapcraft 的论坛上写了这篇文章,并启发作者写了这篇博文。
  • snapcraft 网站: snapcraft 官方网站。
  • snapcraft 的 CircleCI Bug 报告:在 Launchpad 上有一个开放的 bug 报告页面,用来改善 CircleCI 对 snapcraft 的支持。同时这将使这个过程变得更简单并且更“正式”。期待您的支持。
  • 怎么使用 CircleCI 构建 Nextcloud 的 snap:这里有一篇题为 “复杂应用的持续验收测试” 的博文,它同时也影响了这篇博文。

这篇客座文章的作者是 Ricardo Feliciano —— CircleCi 的开发者传道士。如果您也有兴趣投稿,请联系 [email protected]。原始文章可以从 这里 找到。


via: https://insights.ubuntu.com/2017/06/28/build-test-and-publish-snap-packages-using-snapcraft/

译者简介:

常年混迹于 snapcraft.io,对 Ubuntu Core、snaps 和 snapcraft 有浓厚的兴趣,并致力于将这些还在快速发展的新技术通过翻译或原创的方式介绍到中文世界。有兴趣的小伙伴也可以关注译者个人的公众号: Snapcraft

作者:Ricardo Feliciano 译者:Snapcrafter 校对:wxy

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

这篇帖子是有关 在 Ubuntu Core 开发 ROS 原型到成品 系列的补充,用来回答我收到的一个问题: “我想做一个工厂镜像,但我不想使我的 snap 公开” 当然,这个问题和回答都不只是针对于机器人技术。在这篇帖子中,我将会通过两种方法来回答这个问题。

开始之前,你需要了解一些制作 Ubuntu Core 镜像的背景知识,如果你已经看过 在 Ubuntu Core 开发 ROS 原型到成品[3 系列文章(具体是第 5 部分),你就已经有了需要的背景知识,如果没有看过的话,可以查看有关 制作你的 Ubuntu Core 镜像 的教程。

如果你已经了解了最新的情况,并且当我说 “模型定义” 或者 “模型断言” 时知道我在谈论什么,那就让我们开始通过不同的方法使用私有 sanps 来制作 Ubuntu Core 镜像吧。

方法 1: 不要上传你的 snap 到商店

这是最简单的方法了。首先看一下这个有关模型定义的例子——amd64-model.json

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-test-snap"]
}

让我们将它转换成模型断言:

$ cat amd64-model.json | snap sign -k my-key-name > amd64.model
You need a passphrase to unlock the secret key for
user: "my-key-name"
4096-bit RSA key, ID 0B79B865, created 2016-01-01
...

获得模型断言:amd64.model 后,如果你现在就把它交给 ubuntu-image 使用,你将会碰钉子:

$ sudo ubuntu-image -c stable amd64.model 
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-test-snap
error: cannot find snap "kyrofa-test-snap": snap not found
COMMAND FAILED: snap prepare-image --channel=stable amd64.model /tmp/tmp6p453gk9/unpack

实际上商店中并没有名为 kyrofa-test-snap 的 snap。这里需要重点说明的是:模型定义(以及转换后的断言)只包含了一系列的 snap 的名字。如果你在本地有个那个名字的 snap,即使它没有存在于商店中,你也可以通过 --extra-snaps 选项告诉 ubuntu-image 在断言中匹配这个名字来使用它:

$ sudo ubuntu-image -c stable \
         --extra-snaps /path/to/kyrofa-test-snap_0.1_amd64.snap \
         amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Copying "/path/to/kyrofa-test-snap_0.1_amd64.snap" (kyrofa-test-snap)
kyrofa-test-snap already prepared, skipping
WARNING: "kyrofa-test-snap" were installed from local snaps
disconnected from a store and cannot be refreshed subsequently!
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在,在 snap 并没有上传到商店的情况下,你已经获得一个预装了私有 snap 的 Ubuntu Core 镜像(名为 pc.img)。但是这样做有一个很大的问题,ubuntu-image 会提示一个警告:不通过连接商店预装 snap 意味着你没有办法在烧录了这些镜像的设备上更新它。你只能通过制作新的镜像并重新烧录到设备的方式来更新它。

方法 2: 使用品牌商店

当你注册了一个商店账号并访问 dashboard.snapcraft.io 时,你其实是在标准的 Ubuntu 商店中查看你的 snap。如果你是在系统中新安装的 snapd,默认会从这个商店下载。虽然你可以在 Ubuntu 商店中发布私有的 snap,但是你不能将它们预装到镜像中,因为只有你(以及你添加的合作者)才有权限去使用它。在这种情况下制作镜像的唯一方式就是公开发布你的 snap,然而这并不符合这篇帖子的目的。

对于这种用例,我们有所谓的 品牌商店。品牌商店仍然托管在 Ubuntu 商店里,但是它们是针对于某一特定公司或设备的一个定制的、专门的版本。品牌商店可以继承或者不继承标准的 Ubuntu 商店,品牌商店也可以选择开放给所有的开发者或者将其限制在一个特定的组内(保持私有正是我们想要的)。

请注意,这是一个付费功能。你需要 申请一个品牌商店。请求通过后,你将可以通过访问用户名下的 “stores you can access” 看到你的新商店。

在那里你可以看到多个有权使用的商店。最少的情况下也会有两个:标准的 Ubuntu 商店以及你的新的品牌商店。选择品牌商店(红框),进去后记录下你的商店 ID(蓝框):等下你将会用到它。

在品牌商店里注册名字或者上传 snap 和标准的商店使用的方法是一样的,只是它们现在是上传到你的品牌商店而不是标准的那个。如果你将品牌商店放在 unlisted 里面,那么这些 snap 对外部用户是不可见。但是这里需要注意的是第一次上传 snap 的时候需要通过 web 界面来操作。在那之后,你可以继续像往常一样使用 Snapcraft 来操作。

那么这些是如何改变的呢?我的 “kyrofal-store” 从 Ubuntu 商店继承了 snap,并且还包含一个发布在稳定通道中的 “kyrofa-bran-test-snap” 。这个 snap 在 Ubuntu 商店里是使用不了的,如果你去搜索它,你是找不到的:

$ snap find kyrofa-branded
The search "kyrofa-branded" returned 0 snaps

但是使用我们前面记录的商店 ID,我们可以创建一个从品牌商店而不是 Ubuntu 商店下载 snap 的模型断言。我们只需要将 “store” 键添加到 JSON 文件中,就像这样:

{
    "type": "model",
    "series": "16",
    "model": "custom-amd64",
    "architecture": "amd64",
    "gadget": "pc",
    "kernel": "pc-kernel",
    "authority-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "brand-id": "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8",
    "timestamp": "2017-06-23T21:03:24+00:00",
    "required-snaps": ["kyrofa-branded-test-snap"],
    "store": "ky<secret>ek"
}

使用方法 1 中的方式对它签名,然后我们就可以像这样很简单的制作一个预装有我们品牌商店私有 snap 的 Ubuntu Core 镜像:

$ sudo ubuntu-image -c stable amd64.model
Fetching core
Fetching pc-kernel
Fetching pc
Fetching kyrofa-branded-test-snap
Partition size/offset need to be a multiple of sector size (512).
The size/offset will be rounded up to the nearest sector.

现在,和方法 1 的最后一样,你获得了一个为工厂准备的 pc.img。并且使用这种方法制作的镜像中的所有 snap 都从商店下载的,这意味着它们将能像平常一样自动更新。

结论

到目前为止,做这个只有两种方法。当我开始写这篇帖子的时候,我想过可能还有第三种(将 snap 设置为私有然后使用它制作镜像),但最后证明是不行的

另外,我们也收到很多内部部署或者企业商店的请求,虽然这样的产品还没有公布,但是商店团队正在从事这项工作。一旦可用,我将会写一篇有关它的文章。

希望能帮助到您!


关于作者

Kyle 是 Snapcraft 团队的一员,也是 Canonical 公司的常驻机器人专家,他专注于 snaps 和 snap 开发实践,以及 snaps 和 Ubuntu Core 的机器人技术实现。


via: https://insights.ubuntu.com/2017/07/11/ubuntu-core-making-a-factory-image-with-private-snaps/

作者:Kyle Fazzari 译者:Snaplee 校对:wxy

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

2016 年 11 月最后一天,Canonical 和 Docker 公司宣布了一个新的商务合作意向,承诺为 Ubuntu Linux 提供商业版 Docker 引擎的企业级支持和 SLA。

这两家公司将在 Ubuntu 平台上集成商业版 Docker 引擎,这样 Canonical 就可以一体化为其客户提供商业版 Docker 引擎和 Ubuntu Linux 系统的支持。

“通过我们的合作,将商业版 Docker 引擎带到了庞大的 Ubuntu 社区, 在敏捷性、移植性和安全性方面为用户提供了更多选择。”Docker 的商业发展和技术联盟副总裁 Nick Stinemates 说。

Ubuntu 的客户现在可以受益于 Docker 的官方支持

Docker 和 Canonical 之间的新合作将使 Ubuntu 客户得到 Docker 的官方支持,而目前其他的 Linux 发行版尚无此支持。因此, Docker 公司将会以 Snap 格式发布和维护新版本的商业版 Docker 引擎。

这些 Docker 维护的 Snap 软件包将由 Docker 公司推送回上游,Ubuntu 16.04 LTS 及其它支持 Snap 的 Linux 系统将可以直接访问由官方构建的 Docker 应用容器。

“在可伸缩容器运营方面,Ubuntu 和 Docker 的组合很流行,这次的合作意向将使我们的用户可以在商业版 Docker 引擎的 DevOps 产品化方面开辟一条更快、更容易的发展道路。”Canonical 的云联盟和商业发展副总裁 John Zannos 说。

据 Canonical 和 Docker 称,Ubuntu 在以容器为中心的 DevOps 平台环境中非常流行,所以在加快和保持维护 Docker 版本发布的需求方面日益增加。最新的 Snap 技术为 Ubuntu 上的新发布 Docker 软件提供了额外的安全保护。

让我们回顾一下 Linux 社区最新的愿景——推动去中心化的应用来解决发行版的碎片化。

继上周的文章:“Snap、Flatpak 这种通吃所有发行版的打包方式真的有用吗?” 之后,一系列新观点浮出水面,其中可能包含关于这样应用是否有用的重要信息。

缺点

就这个话题在这里的评论,一个叫 Till 的 Gentoo 使用者,对于上一次我们未能完全解释的问题给出了一些新的观点。

对于上一次我们选择仅仅称之为膨胀的的东西,Till 从另一方面做了剖析膨胀将来的发展,这可以帮助我们更好的理解它的组成和其影响。

这些被称之为“捆绑应用”的应用程序能够工作在所有发行版上的机制是——将它依赖的库都包含在它们的应用软件之中,Till 说:

“捆绑应用装载了大量的并不被应用开发者所维护的软件。如果其中的某个函数库被发现了一个安全问题而需要更新的话,你得为每一个独立的应用程序安装更新来确保你的系统安全。”

本质上,Till 提出了一个重要的安全问题。但是它并不仅仅与安全有关系,它还关系到许多方面,比如说系统维护、原子更新等等。

此外,如果我们进一步假设:依赖的开发者们也许会合作,将他们的软件与使用它的应用程序一起发布(一种理想状况),但这将导致整个平台的开发整体放缓。

另一个将会导致的问题是透明的依赖关系变得模糊,就是说,如果你想知道一个应用程序捆绑了哪些依赖关系,你必须依靠开发者发布这些数据。

或者就像 Till 说的:“比如说像某某包是否已经包含了更新的某函数库这样的问题将会是你每天需要面对的。”

与之相反,对于 Linux 现行的标准的包管理方法(包括二进制包和源码包),你能够很容易的注意到哪些函数库已经在系统中更新了。

并且,你也可以很轻松的知道其它哪些应用使用了这个函数库,这就将你从繁琐的单独检查每一个应用程序的工作中解救了出来。

其他可能由膨胀导致的缺点包括:更大的包体积(每一个应用程序捆绑了依赖),更高的内存占用(没有共享函数库),并且,少了一个包过滤机制来防止恶意软件:发行版的包维护者也充当了一个在开发者和用户之间的过滤者,他保障了用户获得高质量的软件。

而在捆绑应用中就不再是这种情况了。

最后一点,Till 声称,尽管在某些情况下很有用,但是在大多数情况下,捆绑应用程序将弱化自由软件在发行版中的地位(专有软件供应商将被能够发布他们的软件而不用把它放到公共软件仓库中)。

除此之外,它引出了许多其他问题。很多问题都可以简单归结到开发人员身上。

优点

相比之下,另一个名叫 Sven 的人的评论试图反驳目前普遍反对使用捆绑应用程序的观点,从而证明和支持使用它。

“浪费空间?”——Sven 声称在当今世界我们有很多其他事情在浪费磁盘空间,比如电影存储在硬盘上、本地安装等等……

最终,这些事情浪费的空间要远远多于仅仅“ 100 MB 而你每天都要使用的程序。……因此浪费空间的说法实在很荒谬。”

“浪费运行内存?”——主要的观点有:

  • 共享库浪费的内存要远远少于程序的运行时数据所占用的
  • 而今运行内存已经很便宜了。

“安全梦魇”——不是每个应用程序的运行真正的要注重安全

而且,许多应用程序甚至从来没有过任何安全更新,除非在“滚动更新的发行版”。

除了 Sven 这种从实用出发的观点以外,Till 其实也指出了捆绑应用在一些情况下也有着其优点:

  • 专有软件的供应商想要保持他们的代码游离于公共仓库之外将更加容易。
  • 没有被你的发行版打包进去的小众应用程序将变得更加可行。
  • 在没有 Beta 包的二进制发行版中测试应用将变得简单。
  • 将用户从复杂的依赖关系中解放出来。

最后的思考

虽然关于此问题有着不同的想法,但是有一个被大家共同接受的观点是:捆绑应用对于填补 Linux 生态系统有着其独到的作用。

虽然如此,它的定位,不论是主流的还是边缘的,都变得愈发清晰,至少理论上是这样。

想要尽可能优化其系统的用户,在大多数情况下应该要避免使用捆绑应用。

而讲究易用性、尽可能在维护系统上少费劲的用户,可能应该会感觉这种新应用十分舒爽。


via: http://www.iwillfolo.com/linux-applications-that-works-on-all-distributions-are-they-any-good/

作者:Editorials 译者:Chao-zhi 校对:wxy

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

对新一代的打包格式开始渗透到 Linux 生态系统中的深入观察

最近我们听到越来越多的有关于 Ubuntu 的 Snap 包和由 Red Hat 员工 Alexander Larsson 创造的 Flatpak (曾经叫做 xdg-app)的消息。

这两种下一代打包方法在本质上拥有相同的目标和特点:即不依赖于第三方系统功能库的独立包装。

这种 Linux 新技术方向似乎自然会让人脑海中浮现这样的问题:独立包的优点/缺点是什么?这是否让我们拥有更好的 Linux 系统?其背后的动机是什么?

为了回答这些问题,让我们先深入了解一下 Snap 和 Flatpak。

动机

根据 FlatpakSnap 的声明,背后的主要动机是使同一版本的应用程序能够运行在多个 Linux 发行版。

“从一开始它的主要目标是允许相同的应用程序运行在各种 Linux 发行版和操作系统上。” —— Flatpak
“……‘snap’ 通用 Linux 包格式,使简单的二进制包能够完美的、安全的运行在任何 Linux 桌面、服务器、云和设备上。” —— Snap

说得更具体一点,站在 Snap 和 Flatpak (以下称之为 S&F)背后的人认为,Linux 平台存在碎片化的问题。

这个问题导致了开发者们需要做许多不必要的工作来使他的软件能够运行在各种不同的发行版上,这影响了整个平台的前进。

所以,作为 Linux 发行版(Ubuntu 和 Red Hat)的领导者,他们希望消除这个障碍,推动平台发展。

但是,是否是更多的个人收益刺激了 S&F 的开发?

个人收益?

虽然没有任何官方声明,但是试想一下,如果能够创造这种可能会被大多数发行版(即便不是全部)所采用的打包方式,那么这个项目的领导者将可能成为一个能够决定 Linux 大船航向的重要人物。

优势

这种独立包的好处多多,并且取决于不同的因素。

这些因素基本上可以归为两类:

用户角度

+ 从 Liunx 用户的观点来看:Snap 和 Flatpak 带来了将任何软件包(软件或应用)安装在用户使用的任何发行版上的可能性。

例如你在使用一个不是很流行的发行版,由于开发工作的缺乏,它的软件仓库只有很稀少的包。现在,通过 S&F 你就可以显著的增加包的数量,这是一个多么美好的事情。

+ 同样,对于使用流行的发行版的用户,即使该发行版的软件仓库上有很多的包,他也可以在不改变它现有的功能库的同时安装一个新的包。

比方说, 一个 Debian 的用户想要安装一个 “测试分支” 的包,但是他又不想将他的整个系统变成测试版(来让该包运行在更新的功能库上)。现在,他就可以简单的想安装哪个版本就安装哪个版本,而不需要考虑库的问题。

对于持后者观点的人,可能基本上都是使用源文件编译他们的包的人,然而,除非你使用类似 Gentoo 这样基于源代码的发行版,否则大多数用户将从头编译视为是一个恶心到吐的事情。

+ 高级用户,或者称之为 “拥有安全意识的用户” 可能会觉得更容易接受这种类型的包,只要它们来自可靠来源,这种包倾向于提供另一层隔离,因为它们通常是与系统包想隔离的。

* 不论是 Snap 还是 Flatpak 都在不断努力增强它们的安全性,通常他们都使用 “沙盒化” 来隔离,以防止它们可能携带病毒感染整个系统,就像微软 Windows 系统中的 .exe 程序一样。(关于微软和 S&F 后面还会谈到)

开发者角度

与普通用户相比,对于开发者来说,开发 S&F 包的优点可能更加清楚。这一点已经在上一节有所提示。

尽管如此,这些优点有:

+ S&F 通过统一开发的过程,将多发行版的开发变得简单了起来。对于需要将他的应用运行在多个发行版的开发者来说,这大大的减少了他们的工作量。

++ 因此,开发者能够更容易的使他的应用运行在更多的发行版上。

+ S&F 允许开发者私自发布他的包,不需要依靠发行版维护者在每一个/每一次发行版中发布他的包。

++ 通过上述方法,开发者可以不依赖发行版而直接获取到用户安装和卸载其软件的统计数据。

++ 同样是通过上述方法,开发者可以更好的直接与用户互动,而不需要通过中间媒介,比如发行版这种中间媒介。

缺点

膨胀。就是这么简单。Flatpak 和 Snap 并不是凭空变出来它的依赖关系。相反,它是通过将依赖关系预构建在其中来代替使用系统中的依赖关系。

就像谚语说的:“山不来就我,我就去就山”。

之前提到安全意识强的用户会喜欢 S&F 提供的额外的一层隔离,只要该应用来自一个受信任的来源。但是从另外一个角度看,对这方面了解较少的用户,可能会从一个不靠谱的地方弄来一个包含恶意软件的包从而导致危害。

上面提到的观点可以说是有很有意义的,虽说今天的流行方法,像 PPA、overlay 等也可能是来自不受信任的来源。

但是,S&F 包更加增加这个风险,因为恶意软件开发者只需要开发一个版本就可以感染各种发行版。相反,如果没有 S&F,恶意软件的开发者就需要创建不同的版本以适应不同的发行版。

原来微软一直是正确的吗?

考虑到上面提到的,很显然,在大多数情况下,使用 S&F 包的优点超过缺点。

至少对于二进制发行版的用户,或者重点不是轻量级的发行版的用户来说是这样的。

这促使我问出这个问题,可能微软一直是正确的吗?如果是的,那么当 S&F 变成 Linux 的标准后,你还会一如既往的使用 Linux 或者类 Unix 系统吗?

很显然,时间会是这个问题的最好答案。

不过,我认为,即使不完全正确,但是微软有些地方也是值得赞扬的,并且以我的观点来看,所有这些方式在 Linux 上都立马能用也确实是一个亮点。


via: http://www.iwillfolo.com/ubuntus-snap-red-hats-flatpack-and-is-one-fits-all-linux-packages-useful/

作者:Liron 译者:Chao-zhi 校对:wxy

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