mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu.Wang
commit
dfdc78211c
@ -1,17 +1,21 @@
|
||||
怎样在桌面上安装 Docker CE？
|
||||
=====
|
||||
|
||||
[在上一篇文章中][1]，我们学习了容器世界的一些基本术语。当我们运行命令并在后续文章中使用其中一些术语时，这些背景信息将会派上用场，包括这篇文章。本文将介绍在桌面 Linux, macOS 和 Windows 上安装 Docker，它适用于想要开始使用 Docker 容器的初学者。唯一的先决条件是你对命令行界面满意。
|
||||
> 按照这些简单的步骤在你的 Linux、Mac 或 Windows 桌面上安装 Docker CE。
|
||||
|
||||
|
||||
|
||||
[在上一篇文章中][1]，我们学习了容器世界的一些基本术语。当我们运行命令并在后续文章中使用其中一些术语时，这些背景信息将会派上用场，包括这篇文章。本文将介绍在桌面 Linux、 macOS 和 Windows 上安装 Docker，它适用于想要开始使用 Docker 容器的初学者。唯一的先决条件是你对命令行界面满意。
|
||||
|
||||
### 为什么我在本地机器上需要 Docker CE？
|
||||
|
||||
作为一个新用户，你很可能想知道为什么你在本地系统上需要容器。难道它们不是作为微服务在云和服务器中运行吗？尽管容器长期以来一直是 Linux 世界的一部分，但 Docker 使它们真正可以使用它的工具和技术。（to 校正者：这句话它们意义似乎不明确）
|
||||
作为一个新用户，你很可能想知道为什么你在本地系统上需要容器。难道它们不是作为微服务在云和服务器中运行吗？尽管容器长期以来一直是 Linux 世界的一部分，但 Docker 才真正使容器的工具和技术步入使用。
|
||||
|
||||
Docker 容器最大的优点是可以使用本地机器进行开发和测试。你在本地系统上创建的容器映像可以在“任何位置”运行。就应用程序在开发系统上运行良好但生产环境中出现问题这一点，开发人员和操作人员之间不会起冲突。
|
||||
Docker 容器最大的优点是可以使用本地机器进行开发和测试。你在本地系统上创建的容器映像可以在“任何位置”运行。开发人员和操作人员之间不再会为应用程序在开发系统上运行良好但生产环境中出现问题而产生纷争。
|
||||
|
||||
关键是，为了创建容器化的应用程序，你必须能够在本地系统上运行和创建容器。
|
||||
而这个关键是，要创建容器化的应用程序，你必须能够在本地系统上运行和创建容器。
|
||||
|
||||
你可以使用以下三个平台中的任何一个 -- 桌面 Linux, Windows 或 macOS 作为容器的开发平台。一旦 Docker 在这些系统上成功运行，你将可以在不同的平台上使用相同的命令。因此，接下来你运行的操作系统无关紧要。
|
||||
你可以使用以下三个平台中的任何一个 —— 桌面 Linux、 Windows 或 macOS 作为容器的开发平台。一旦 Docker 在这些系统上成功运行，你将可以在不同的平台上使用相同的命令。因此，接下来你运行的操作系统无关紧要。
|
||||
|
||||
这就是 Docker 之美。
|
||||
|
||||
@ -21,149 +25,152 @@ Docker 容器最大的优点是可以使用本地机器进行开发和测试。
|
||||
|
||||
Docker CE 有两个版本：stable 和 edge。顾名思义，stable（稳定）版本会为你提供经过充分测试的季度更新，而 edge 版本每个月都会提供新的更新。经过进一步的测试之后，这些边缘特征将被添加到稳定版本中。我建议新用户使用 stable 版本。
|
||||
|
||||
Docker CE 支持 macOS, Windows 10, Ubuntu 14.04, 16.04, 17.04 和 17.10，以及 Debian 7.7, 8, 9 和 10, Fedora 25, 26, 27 和 centOS。虽然你可以下载 Docker CE 二进制文件并安装到桌面 Linux 上，但我建议添加仓库源以便继续获得修补程序和更新。
|
||||
Docker CE 支持 macOS、 Windows 10、 Ubuntu 14.04/16.04/17.04/17.10、 Debian 7.7/8/9/10、 Fedora 25/26/27 和 CentOS。虽然你可以下载 Docker CE 二进制文件并安装到桌面 Linux 上，但我建议添加仓库源以便继续获得修补程序和更新。
|
||||
|
||||
### 在桌面 Linux 上安装 Docker CE
|
||||
|
||||
你不需要一个完整的桌面 Linux 来运行 Docker，你也可以将它安装在最小的 Linux 服务器上，即你可以在一个虚拟机中运行。在本教程中，我将在我的主系统 Fedora 27 和 Ubuntu 17.04 上运行它（to 校正者：这句话搞不清主要是什么系统）。
|
||||
你不需要一个完整的桌面 Linux 来运行 Docker，你也可以将它安装在最小的 Linux 服务器上，即你可以在一个虚拟机中运行。在本教程中，我将在我的主系统的 Fedora 27 和 Ubuntu 17.04 上运行它。
|
||||
|
||||
### 在 Ubuntu 上安装
|
||||
|
||||
首先，运行系统更新，以便你的 Ubuntu 软件包完全更新：
|
||||
|
||||
```
|
||||
$ sudo apt-get update
|
||||
|
||||
```
|
||||
|
||||
现在运行系统升级：
|
||||
|
||||
```
|
||||
$ sudo apt-get dist-upgrade
|
||||
|
||||
```
|
||||
|
||||
然后安装 Docker PGP 密钥：
|
||||
|
||||
```
|
||||
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
|
||||
|
||||
```
|
||||
```
|
||||
Update the repository info again:
|
||||
$ sudo apt-get update
|
||||
|
||||
```
|
||||
|
||||
现在安装 Docker CE：
|
||||
|
||||
```
|
||||
$ sudo apt-get install docker-ce
|
||||
|
||||
```
|
||||
|
||||
一旦安装，Docker CE 就会在基于 Ubuntu 的系统上自动运行，让我们来检查它是否在运行：
|
||||
一旦安装完成，Docker CE 就会在基于 Ubuntu 的系统上自动运行，让我们来检查它是否在运行：
|
||||
|
||||
```
|
||||
$ sudo systemctl status docker
|
||||
|
||||
```
|
||||
|
||||
你应该得到以下输出：
|
||||
|
||||
```
|
||||
docker.service - Docker Application Container Engine
|
||||
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
|
||||
Active: active (running) since Thu 2017-12-28 15:06:35 EST; 19min ago
|
||||
Docs: https://docs.docker.com
|
||||
Main PID: 30539 (dockerd)
|
||||
|
||||
```
|
||||
|
||||
由于 Docker 安装在你的系统上，你现在可以使用 Docker CLI（命令行界面）运行 Docker 命令。像往常一样，我们运行 ‘Hello World’ 命令：
|
||||
|
||||
```
|
||||
$ sudo docker run hello-world
|
||||
|
||||
```
|
||||
|
||||
![YMChR_7xglpYBT91rtXnqQc6R1Hx9qMX_iO99vL8][2]
|
||||
|
||||
恭喜！在你的 Ubuntu 系统上正在运行着 Docker。
|
||||
|
||||
### 在 Fedora 上安装 Docker CE
|
||||
|
||||
Fedora 27 上的情况有些不同。在 Fedora 上，你首先需要安装 def-plugins-core 包，这将允许你从 CLI 管理你的 DNF 包。
|
||||
Fedora 27 上的情况有些不同。在 Fedora 上，你首先需要安装 `def-plugins-core` 包，这将允许你从 CLI 管理你的 DNF 包。
|
||||
|
||||
```
|
||||
$ sudo dnf -y install dnf-plugins-core
|
||||
|
||||
```
|
||||
|
||||
现在在你的系统上安装 Docker 仓库：
|
||||
|
||||
```
|
||||
$ sudo dnf config-manager \
|
||||
--add-repo \
|
||||
https://download.docker.com/linux/fedora/docker-ce.repo
|
||||
It’s time to install Docker CE:
|
||||
|
||||
$ sudo dnf install docker-ce
|
||||
|
||||
```
|
||||
|
||||
```
|
||||
$ sudo dnf install docker-ce
|
||||
```
|
||||
与 Ubuntu 不同，Docker 不会在 Fedora 上自动启动。那么让我们启动它：
|
||||
|
||||
```
|
||||
$ sudo systemctl start docker
|
||||
|
||||
```
|
||||
|
||||
你必须在每次重新启动后手动启动 Docker，因此让我们将其配置为在重新启动后自动启动。$ systemctl enable docker 就行。现在该运行 Hello World 命令了：
|
||||
你必须在每次重新启动后手动启动 Docker，因此让我们将其配置为在重新启动后自动启动。`$ systemctl enable docker` 就行。现在该运行 Hello World 命令了：
|
||||
|
||||
```
|
||||
$ sudo docker run hello-world
|
||||
|
||||
```
|
||||
|
||||
恭喜，在你的 Fedora 27 系统上正在运行着 Docker。
|
||||
|
||||
### 解除 root
|
||||
|
||||
你可能已经注意到你必须使用 sudo 来运行 Docker 命令。这是因为 Docker 守护进程与 UNIX 套接字绑定，而不是 TCP 端口，套接字由 root 用户拥有。所以，你需要 sudo 权限才能运行 docker 命令。你可以将系统用户添加到 docker 组，这样它就不需要 sudo 了：
|
||||
你可能已经注意到你必须使用 `sudo` 来运行 `docker` 命令。这是因为 Docker 守护进程与 UNIX 套接字绑定，而不是 TCP 端口，套接字由 root 用户拥有。所以，你需要 `sudo` 权限才能运行 `docker` 命令。你可以将系统用户添加到 docker 组，这样它就不需要 `sudo` 了：
|
||||
|
||||
```
|
||||
$ sudo groupadd docker
|
||||
|
||||
```
|
||||
|
||||
在大多数情况下，在安装 Docker CE 时会自动创建 Docker 用户组，因此你只需将用户添加到该组中即可：
|
||||
|
||||
```
|
||||
$ sudo usermod -aG docker $USER
|
||||
|
||||
```
|
||||
|
||||
为了测试组是否已经成功添加，根据用户名运行 groups 命令：
|
||||
为了测试该组是否已经成功添加，根据用户名运行 `groups` 命令：
|
||||
|
||||
```
|
||||
$ groups swapnil
|
||||
|
||||
```
|
||||
|
||||
（这里，swapnil 是用户名。）
|
||||
（这里，`swapnil` 是用户名。）
|
||||
|
||||
这是在我系统上的输出：
|
||||
```
|
||||
$ swapnil : swapnil adm cdrom sudo dip plugdev lpadmin sambashare docker
|
||||
|
||||
```
|
||||
swapnil : swapnil adm cdrom sudo dip plugdev lpadmin sambashare docker
|
||||
```
|
||||
|
||||
你可以看到该用户也属于 docker 组。注销系统，这样组就会生效。一旦你再次登录，在不使用 sudo 的情况下试试 Hello World 命令：
|
||||
你可以看到该用户也属于 docker 组。注销系统，这样组就会生效。一旦你再次登录，在不使用 `sudo` 的情况下试试 Hello World 命令：
|
||||
|
||||
```
|
||||
$ docker run hello-world
|
||||
|
||||
```
|
||||
|
||||
你可以通过运行以下命令来查看关于 Docker 的安装版本以及更多系统信息：
|
||||
|
||||
```
|
||||
$ docker info
|
||||
|
||||
```
|
||||
|
||||
### 在 macOS 和 Windows 上安装 Docker CE
|
||||
|
||||
你可以在 macOS 和 Windows 上很轻松地安装 Docker CE（和 EE）。下载官方为 macOS 提供的 Docker 安装包，在 macOS 上安装应用程序的方式是只需将它们拖到 Applications 目录即可。一旦文件被复制，从 spotlight（译者注：mac 下的搜索）下打开 Docker 开始安装。一旦安装，Docker 将自动启动，你可以在 macOS 的顶部看到它。
|
||||
你可以在 macOS 和 Windows 上很轻松地安装 Docker CE（和 EE）。下载官方为 macOS 提供的 Docker 安装包，在 macOS 上安装应用程序的方式是只需将它们拖到 Applications 目录即可。一旦文件被复制，从 spotlight（LCTT 译注：mac 下的搜索功能）下打开 Docker 开始安装。一旦安装，Docker 将自动启动，你可以在 macOS 的顶部看到它。
|
||||
|
||||
![IEX23j65zYlF8mZ1c-T_vFw_i1B1T1hibw_AuhEA][3]
|
||||
|
||||
macOS 是类 UNIX，所以你可以简单地打开终端应用程序，并开始使用 Docker 命令。测试 hello world 应用：
|
||||
macOS 是类 UNIX 系统，所以你可以简单地打开终端应用程序，并开始使用 Docker 命令。测试 hello world 应用：
|
||||
|
||||
```
|
||||
$ docker run hello-world
|
||||
|
||||
```
|
||||
|
||||
恭喜，你已经在你的 macOS 上运行了 Docker。
|
||||
@ -173,9 +180,9 @@ $ docker run hello-world
|
||||
你需要最新版本的 Windows 10 Pro 或 Server 才能在它上面安装或运行 Docker。如果你没有完全更新，Windows 将不会安装 Docker。我在 Windows 10 系统上遇到了错误，必须运行系统更新。我的版本还很落后，我出现了[这个][14] bug。所以，如果你无法在 Windows 上安装 Docker，只要知道并不是只有你一个。仔细检查该 bug 以找到解决方案。
|
||||
|
||||
一旦你在 Windows 上安装 Docker 后，你可以通过 WSL 使用 bash shell，或者使用 PowerShell 来运行 Docker 命令。让我们在 PowerShell 中测试 “Hello World” 命令：
|
||||
|
||||
```
|
||||
PS C:\Users\swapnil> docker run hello-world
|
||||
|
||||
```
|
||||
|
||||
恭喜，你已经在 Windows 上运行了 Docker。
|
||||
@ -188,9 +195,9 @@ PS C:\Users\swapnil> docker run hello-world
|
||||
via: https://www.linux.com/blog/learn/intro-to-linux/how-install-docker-ce-your-desktop
|
||||
|
||||
作者：[SWAPNIL BHARTIYA][a]
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[MjSeven](https://github.com/MjSeven)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,50 @@
|
||||
DevOps 如何帮助你将很酷的应用交付给用户
|
||||
======
|
||||
|
||||
> 想要在今天的快节奏的商业环境中获得成功？要么选择 DevOps，要么死亡。
|
||||
|
||||
|
||||
|
||||
在很久之前，遥远的银河系中，在 DevOps 成为主流实践之前，软件开发的过程是极其缓慢、单调和按部就班的。当一个应用准备要部署的时候，就已经为下一个主要版本迭代积累了一长串的变更和修复。每次为新版本迭代所花费的准备时间都需要花费数个月的时间去回顾和贯穿整个开发周期。请记住这个过程将会在交付更新给用户的过程中不断的
|
||||
重复。
|
||||
|
||||
今天一切都是瞬间和实时完成的，这个概念似乎很原始。这场移动革命已经极大的改变了我们和软件之间的交互。那些早期采用 DevOps 的公司已经彻底改变了对软件开发和部署的期望。
|
||||
|
||||
让我们看看 Facebook：这个移动应用每两周更新和刷新一次，像钟表一样。这就是新的标准，因为现在的用户期望软件持续的被修复和更新。任何一家要花费一个月或者更多的时间来部署新的功能或者修复 bug 的公司将会逐渐走向没落。如果你不能交付用户所期待的，他们将会去寻找那些能够满足他们需求的。
|
||||
|
||||
Facebook，以及一些工业巨头如亚马逊、Netfix、谷歌以及其他公司，都已经强制要求企业变得更快速、更有效的来满足今天的顾客们的需求。
|
||||
|
||||
### 为什么是 DevOps?
|
||||
|
||||
敏捷和 DevOps 对于移动应用开发领域是相当重要的，因为开发周期正变得如闪电般的快。现在是一个密集、快节奏的环境，公司必须加紧步伐赶超，思考的更深入，运用策略来去完成，从而生存下去。在应用商店中，排名前十的应用平均能够保持的时间只有一个月左右。
|
||||
|
||||
为了说明老式的瀑布方法，回想一下你第一次学习驾驶。起先，你专注于每个独立的层面，使用一套方法论的过程：你上车；系上安全带；调整座椅、镜子，控制方向盘；发动汽车，将你的手放在 10 点和 2 点钟的方向，等等。完成一个换车道一样简单的任务需要付出艰苦的努力，以一个特定的顺序执行多个步骤。
|
||||
|
||||
DevOps，正好相反，是在你有了几年的经验之后如何去驾驶的。一切都是靠直觉同时发生的，你可以不用过多的思考就很平滑的从 A 点移动到 B 点。
|
||||
|
||||
移动 app 的世界对越老式的 app 开发环境来说太快节奏了。DevOps 被设计用来快速交付有效、稳定的 app，而不需要增加资源。然而你不能像购买一件普通的商品或者服务一样去购买 DevOps。DevOps 是用来指导改变团队如何一起工作的文化和活动的。
|
||||
|
||||
不是只有像亚马逊和 Facebook 这样的大公司才拥抱 DevOps 文化；小的移动应用公司也在很好的使用。“缩短迭代周期，同时保持生产事故处于一个较低水平，以及满足顾客追求的整体故障成本。”来自移动产品代理 [Reinvently][1]的工程部的负责人，Oleg Reshetnyak 说道。
|
||||
|
||||
### DevOps: 不是如果，而是什么时候
|
||||
|
||||
在今天的快节奏的商业环境中，选在了 DevOps 就像是选择了呼吸：要么去[做要么就死亡][2]。
|
||||
|
||||
根据[美国小企业管理局][3]的报道，现在只有 16% 的公司能够持续一代人的时间。不采用 DevOps 的移动应用公司将冒着逐渐走向灭绝的风险。而且，同样的研究表明采用 DevOps 的公司组织可能能够获得两倍的盈利能力、生产目标以及市场份额。
|
||||
|
||||
更快速、更安全的革新需要做到三点：云、自动化和 DevOps。根据你对 DevOps 的定义的不同，这三个要点之间的界限是不清晰的。然而，有一点是确定的：DevOps 围绕着更快、更少风险地交付高质量的软件的共同目标将组织内的每个人都统一起来。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/2/devops-delivers-cool-apps-users
|
||||
|
||||
作者：[Stanislav Ivaschenko][a]
|
||||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ilyadudkin
|
||||
[1]:https://reinvently.com/
|
||||
[2]:https://squadex.com/insights/devops-or-die/
|
||||
[3]:https://www.sba.gov/
|
||||
@ -1,29 +1,32 @@
|
||||
不像 MySQL 的 MySQL：MySQL 文档存储介绍
|
||||
======
|
||||
|
||||
> MySQL 文档存储 可以跳过底层数据结构创建、数据规范化和其它使用传统数据库时需要做的工作，直接存储数据。
|
||||
|
||||
|
||||
|
||||
MySQL 可以提供 NoSQL JSON <ruby>文档存储<rt>Document Store</rt></ruby>了，这样开发者保存数据前无需<ruby>规范化<rt>normalize</rt></ruby>数据、创建数据库，也无需在开发之前就制定好数据样式。从 MySQL 5.7 版本和 MySQL 8.0 版本开始，开发者可以在表的一列中存储 JSON 文档。由于引入 X DevAPI，你可以从你的代码中移除令人不爽的结构化查询字符串，改为使用支持现代编程设计的 API 调用。
|
||||
|
||||
系统学习过结构化查询语言（SQL）、<ruby>关系理论<rt>relational theory</rt></ruby>和其它关系数据库底层理论的开发者并不多，但他们需要一个安全可靠的数据存储。如果数据库管理人员不足，事情很快就会变得一团糟，
|
||||
系统学习过结构化查询语言（SQL）、<ruby>关系理论<rt>relational theory</rt></ruby>、<ruby>集合<rt>set</rt></ruby>和其它关系数据库底层理论的开发者并不多，但他们需要一个安全可靠的数据存储。如果数据库管理人员不足，事情很快就会变得一团糟，
|
||||
|
||||
[MySQL 文档存储][1] 允许开发者跳过底层数据结构创建、数据规范化和其它使用传统数据库时需要做的工作，直接存储数据。只需创建一个 JSON <ruby>文档集合<rt>document collection</rt></ruby>，接着就可以使用了。
|
||||
|
||||
### JSON 数据类型
|
||||
|
||||
所有这一切都基于多年前 MySQL 5.7 引入的 JSON 数据类型。允许在表的一行中提供大约 1GB 的列。数据必须是有效的 JSON，否则服务器会报错；但开发者可以自由使用这些空间。
|
||||
所有这一切都基于多年前 MySQL 5.7 引入的 JSON 数据类型。它允许在表的一行中提供大约 1GB 大小的列。数据必须是有效的 JSON，否则服务器会报错；但开发者可以自由使用这些空间。
|
||||
|
||||
### X DevAPI
|
||||
|
||||
旧的 MySQL 协议已经历经差不多四分之一个世纪，已经显现出疲态，因此新的协议被开发出来，协议名为 [X DevAPI][2]。协议引入高级会话概念，允许代码从单台服务器扩展到多台，使用符合<ruby>通用主机编程语言样式<rt>common host-language programming patterns</rt></ruby>的非阻塞异步 I/O。需要关注的是如何遵循现代实践和编码风格，同时使用 CRUD (create, replace, update, delete) 样式。换句话说，你不再需要在你精美、淳朴的代码中嵌入丑陋的 SQL 语句字符串。
|
||||
旧的 MySQL 协议已经历经差不多四分之一个世纪，已经显现出疲态，因此新的协议被开发出来，协议名为 [X DevAPI][2]。协议引入高级会话概念，允许代码从单台服务器扩展到多台，使用符合<ruby>通用主机编程语言样式<rt>common host-language programming patterns</rt></ruby>的非阻塞异步 I/O。需要关注的是如何遵循现代实践和编码风格，同时使用 CRUD （Create、 Replace、 Update、 Delete）样式。换句话说，你不再需要在你精美、纯洁的代码中嵌入丑陋的 SQL 语句字符串。
|
||||
|
||||
一个新的 shell 支持这种新协议，即所谓的 [MySQL Shell][3]。该 shell 可用于设置<ruby>高可用集群<rt>high-availability cluster</rt></ruby>、检查服务器<ruby>升级就绪状态<rt>upgrade readiness</rt></ruby>以及与 MySQL 服务器交互。支持的交互方式有以下三种：JavaScript，Python 和 SQL。
|
||||
|
||||
### 代码示例
|
||||
|
||||
一个新的 shell 支持这种新协议，即所谓的 [MySQL Shell][3]。该 shell 可用于设置<ruby>高可用集群<rt>high-availability clusters</rt></ruby>、检查服务器<ruby>升级就绪状态<rt>upgrade readiness</rt></ruby>以及与 MySQL 服务器交互。支持的交互方式有以下三种：JavaScript，Python 和 SQL。
|
||||
|
||||
下面的代码示例基于 JavaScript 方式使用 MySQL Shell，可以从 `JS>` 提示符看出。
|
||||
|
||||
下面，我们将使用用户 `dstokes` 、密码 `password` 登录本地系统上的 `demo` 库。`db` 是一个指针，指向 demo 库。
|
||||
下面，我们将使用用户 `dstokes` 、密码 `password` 登录本地系统上的 `demo` 库。`db` 是一个指针，指向 `demo` 库。
|
||||
|
||||
```
|
||||
$ mysqlsh dstokes:password@localhost/demo
|
||||
JS> db.createCollection("example")
|
||||
@ -35,14 +38,14 @@ JS> db.example.add(
|
||||
}
|
||||
)
|
||||
JS>
|
||||
|
||||
```
|
||||
|
||||
在上面的示例中，我们登录服务器，连接到 `demo` 库，创建了一个名为 `example` 的集合，最后插入一条记录；整个过程无需创建表，也无需使用 SQL。只要你能想象的到，你可以使用甚至滥用这些数据。这不是一种代码对象与关系语句之间的映射器，因为并没有将代码映射为 SQL；新协议直接与服务器层打交道。
|
||||
|
||||
### Node.js 支持
|
||||
|
||||
新 shell 看起来挺不错，你可以用其完成很多工作；但你可能更希望使用你选用的编程语言。下面的例子使用 `world_x` 示例数据库，搜索 `_id` 字段匹配 "CAN." 的记录。我们指定数据库中的特定集合，使用特定参数调用 `find` 命令。同样地，操作也不涉及 SQL。
|
||||
新 shell 看起来挺不错，你可以用其完成很多工作；但你可能更希望使用你选用的编程语言。下面的例子使用 `world_x` 示例数据库，搜索 `_id` 字段匹配 `CAN.` 的记录。我们指定数据库中的特定集合，使用特定参数调用 `find` 命令。同样地，操作也不涉及 SQL。
|
||||
|
||||
```
|
||||
var mysqlx = require('@mysql/xdevapi');
|
||||
mysqlx.getSession({ //Auth to server
|
||||
@ -62,10 +65,10 @@ collection // Get row for 'CAN'
|
||||
|
||||
session.close();
|
||||
})
|
||||
|
||||
```
|
||||
|
||||
下面例子使用 PHP，搜索 `_id` 字段匹配 "USA" 的记录：
|
||||
下面例子使用 PHP，搜索 `_id` 字段匹配 `USA` 的记录：
|
||||
|
||||
```
|
||||
<?PHP
|
||||
// Connection parameters
|
||||
@ -88,19 +91,16 @@ collection // Get row for 'CAN'
|
||||
$data = $result->fetchAll();
|
||||
var_dump($data);
|
||||
?>
|
||||
|
||||
```
|
||||
|
||||
可以看出，在上面两个使用不同编程语言的例子中，`find` 操作符的用法基本一致。这种一致性对跨语言编程的开发者有很大帮助，对试图降低新语言学习成本的开发者也不无裨益。
|
||||
|
||||
支持的语言还包括 C，Java，Python 和 JavaScript 等，未来还会有更多支持的语言。
|
||||
支持的语言还包括 C、Java、Python 和 JavaScript 等，未来还会有更多支持的语言。
|
||||
|
||||
### 从两种方式受益
|
||||
|
||||
我会告诉你使用 NoSQL 方式录入的数据也可以用 SQL 方式使用？换句话说，我会告诉你新引入的 NoSQL 方式可以访问旧式关系型表中的数据？现在使用 MySQL 服务器有多种方式，作为 SQL 服务器，作为 NoSQL 服务器或者同时作为两者。
|
||||
|
||||
Dave Stokes 将于 6 月 8-10 日在北卡罗来纳州 Charlotte 市举行的 [Southeast LinuxFest][4] 大会上做”不用 SQL 的 MySQL，我的天哪！“主题演讲。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/mysql-document-store
|
||||
@ -108,7 +108,7 @@ via: https://opensource.com/article/18/6/mysql-document-store
|
||||
作者：[Dave Stokes][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[pinewall](https://github.com/pinewall)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,183 +0,0 @@
|
||||
4 tools for building embedded Linux systems
|
||||
======
|
||||
|
||||
|
||||
Linux is being deployed into a much wider array of devices than Linus Torvalds anticipated when he was working on it in his dorm room. The variety of supported chip architectures is astounding and has led to Linux in devices large and small; from [huge IBM mainframes][1] to [tiny devices][2] no bigger than their connection ports and everything in between. It is used in large enterprise data centers, internet infrastructure devices, and personal development systems. It also powers consumer electronics, mobile phones, and many Internet of Things devices.
|
||||
|
||||
When building Linux software for desktop and enterprise-class devices, developers typically use a desktop distribution such as [Ubuntu][3] on their build machines to have an environment as close as possible to the one where the software will be deployed. Tools such as [VirtualBox][4] and [Docker][5] allow even better alignment between development, testing, and productions environments.
|
||||
|
||||
### What is an embedded system?
|
||||
|
||||
Wikipedia defines an [embedded system][6] as: "A computer system with a dedicated function within a larger mechanical or electrical system, often with real-time computing constraints."
|
||||
|
||||
I find it simple enough to say that an embedded system is a computer that most people don't think of as a computer. Its primary role is to serve as an appliance of some sort, and it is not considered a general-purpose computing platform.
|
||||
|
||||
The development environment in embedded systems programming is usually very different from the testing and production environments. They may use different chip architectures, software stacks, and even operating systems. Development workflows are very different for embedded developers vs. desktop and web developers. Typically, the build output will consist of an entire software image for the target device, including the kernel, device drivers, libraries, and application software (and sometimes the bootloader).
|
||||
|
||||
In this article, I will present a survey of four commonly available options for building embedded Linux systems. I will give a flavor for what it's like to work with each and provide enough information to help readers decide which tool to use for their design. I won't teach you how to use any of them; there are plenty of in-depth online learning resources once you have narrowed your choices. No option is right for all use cases, and I hope to present enough details to direct your decision.
|
||||
|
||||
### Yocto
|
||||
|
||||
The [Yocto][7] project is [defined][8] as "an open source collaboration project that provides templates, tools, and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture." It is a collection of recipes, configuration values, and dependencies used to create a custom Linux runtime image tailored to your specific needs.
|
||||
|
||||
Full disclosure: most of my work in embedded Linux has focused on the Yocto project, and my knowledge and bias to this system will likely be evident.
|
||||
|
||||
Yocto uses [Openembedded][9] as its build system. Technically the two are separate projects; in practice, however, users do not need to understand the distinction, and the project names are frequently used interchangeably.
|
||||
|
||||
The output of a Yocto project build consists broadly of three components:
|
||||
|
||||
* **Target run-time binaries:** These include the bootloader, kernel, kernel modules, root filesystem image. and any other auxiliary files needed to deploy Linux to the target platform.
|
||||
* **Package feed:** This is the collection of software packages available to be installed on your target. You can select the package format (e.g., deb, rpm, ipk) based on your needs. Some of them may be preinstalled in the target runtime binaries, however, it is possible to build packages for installation into a deployed system.
|
||||
* **Target SDK:** These are the collection of libraries and header files representing the software installed on your target. They are used by application developers when building their code to ensure they are linked with the appropriate libraries
|
||||
|
||||
|
||||
|
||||
#### Advantages
|
||||
|
||||
The Yocto project is widely used in the industry and has backing from many influential companies. Additionally, it has a large and vibrant developer [community][10] and [ecosystem][11] contributing to it. The combination of open source enthusiasts and corporate sponsors helps drive the Yocto project.
|
||||
|
||||
There are many options for getting support with Yocto. There are books and other training materials if you wish to do-it-yourself. Many engineers with experience in Yocto are available if you want to hire expertise. And many commercial organizations provide turnkey Yocto-based products or services-based implementation and customization for your design.
|
||||
|
||||
The Yocto project is easily expanded through [layers][12], which can be published independently to add additional functionality, to target platforms not available in the project releases, or to store customizations unique to your system. Layers can be added to your configuration to add unique features that are not specifically included in the stock releases; for example, the "[meta-browser][13]" layer contains recipes for web browsers, which can be easily built for your system. Because they are independently maintained, layers can be on a different release schedule (tuned to the layers' development velocity) than the standard Yocto releases.
|
||||
|
||||
Yocto has arguably the widest device support of any of the options discussed in this article. Due to support from many semiconductor and board manufacturers, it's likely Yocto will support any target platform you choose. The direct Yocto [releases][14] support only a few boards (to allow for proper testing and release cycles), however, a standard working model is to use external board support layers.
|
||||
|
||||
Finally, Yocto is extremely flexible and customizable. Customizations for your specific application can be stored in a layer for encapsulation and isolation. Customizations unique to a feature layer are generally stored as part of the layer itself, which allows the same settings to be applied simultaneously to multiple system configurations. Yocto also provides a well-defined layer priority and override capability. This allows you to define the order in which layers are applied and searched for metadata. It also enables you to override settings in layers with higher priority; for instance, many customizations to existing recipes will be added in your private layers, with the order precisely controlled by the priorities.
|
||||
|
||||
#### Disadvantages
|
||||
|
||||
The biggest disadvantage with the Yocto project is the learning curve. It takes significant time and effort to learn the system and truly understand it. Depending on your needs, this may be too large of an investment in technologies and competence that are not central to your application. In such cases, working with one of the commercial vendors may be a good option.
|
||||
|
||||
Development build times and resources are fairly high for Yocto project builds. The number of packages that need to be built, including the toolchain, kernel, and all target runtime components, is significant. Development workstations for Yocto developers tend to be large systems. Using a compact notebook is not recommended. This can be mitigated by using cloud-based build servers available from many providers. Additionally, Yocto has a built-in caching mechanism that allows it to reuse previously built components when it determines that the parameters for building a particular package have not changed.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
Using the Yocto project for your next embedded Linux design is a strong choice. Of the options presented here, it is the most broadly applicable regardless of your target use case. The broad industry support, active community, and wide platform support make this a good choice for must designers.
|
||||
|
||||
### Buildroot
|
||||
|
||||
The [Buildroot][15] project is defined as "a simple, efficient, and easy-to-use tool to generate embedded Linux systems through cross-compilation." It shares many of the same objectives as the Yocto project, however it is focused on simplicity and minimalism. In general, Buildroot will disable all optional compile-time settings for all packages (with a few notable exceptions), resulting in the smallest possible system. It will be up to the system designer to enable the settings that are appropriate for a given device.
|
||||
|
||||
Buildroot builds all components from source but does not support on-target package management. As such, it is sometimes called a firmware generator since the images are largely fixed at build time. Applications can update the target filesystem, but there is no mechanism to install new packages into a running system.
|
||||
|
||||
The Buildroot output consists broadly of three components:
|
||||
|
||||
* The root filesystem image and any other auxiliary files needed to deploy Linux to the target platform
|
||||
* The kernel, boot-loader, and kernel modules appropriate for the target hardware
|
||||
* The toolchain used to build all the target binaries.
|
||||
|
||||
|
||||
|
||||
#### Advantages
|
||||
|
||||
Buildroot's focus on simplicity means that, in general, it is easier to learn than Yocto. The core build system is written in Make and is short enough to allow a developer to understand the entire system while being expandable enough to meet the needs of embedded Linux developers. The Buildroot core generally only handles common use cases, but it is expandable via scripting.
|
||||
|
||||
The Buildroot system uses normal Makefiles and the Kconfig language for its configuration. Kconfig was developed by the Linux kernel community and is widely used in open source projects, making it familiar to many developers.
|
||||
|
||||
Due to the design goal of disabling all optional build-time settings, Buildroot will generally produce the smallest possible images using the out-of-the-box configuration. The build times and build host resources will likewise be smaller, in general, than those of the Yocto project.
|
||||
|
||||
#### Disadvantages
|
||||
|
||||
The focus on simplicity and minimal enabled build options imply that you may need to do significant customization to configure a Buildroot build for your application. Additionally, all configuration options are stored in a single file, which means if you have multiple hardware platforms, you will need to make each of your customization changes for each platform.
|
||||
|
||||
Any change to the system configuration file requires a full rebuild of all packages. This is somewhat mitigated by the minimal image sizes and build times compared with Yocto, but it can result in long builds while you are tweaking your configuration.
|
||||
|
||||
Intermediate package state caching is not enabled by default and is not as thorough as the Yocto implementation. This means that, while the first build may be shorter than an equivalent Yocto build, subsequent builds may require rebuilding of many components.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
Using Buildroot for your next embedded Linux design is a good choice for most applications. If your design requires multiple hardware types or other differences, you may want to reconsider due to the complexity of synchronizing multiple configurations, however, for a system consisting of a single setup, Buildroot will likely work well for you.
|
||||
|
||||
### OpenWRT/LEDE
|
||||
|
||||
The [OpenWRT][16] project was started to develop custom firmware for consumer routers. Many of the low-cost routers available at your local retailer are capable of running a Linux system, but maybe not out of the box. The manufacturers of these routers may not provide frequent updates to address new threats, and even if they do, the mechanisms to install updated images are difficult and error-prone. The OpenWRT project produces updated firmware images for many devices that have been abandoned by their manufacturers and gives these devices a new lease on life.
|
||||
|
||||
The OpenWRT project's primary deliverables are binary images for a large number of commercial devices. There are network-accessible package repositories that allow device end users to add new software to their systems. The OpenWRT build system is a general-purpose build system, which allows developers to create custom versions to meet their own requirements and add new packages, but its primary focus is target binaries.
|
||||
|
||||
#### Advantages
|
||||
|
||||
If you are looking for replacement firmware for a commercial device, OpenWRT should be on your list of options. It is well-maintained and may protect you from issues that the manufacturer's firmware cannot. You can add extra functionality as well, making your devices more useful.
|
||||
|
||||
If your embedded design is networking-focused, OpenWRT is a good choice. Networking applications are the primary use case for OpenWRT, and you will likely find many of those software packages available in it.
|
||||
|
||||
#### Disadvantages
|
||||
|
||||
OpenWRT imposes significant policy decisions on your design (vs. Yocto and Buildroot). If these decisions don't meet your design goals, you may have to do non-trivial modifications.
|
||||
|
||||
Allowing package-based updates in a fleet of deployed devices is difficult to manage. This, by definition, results in a different software load than what your QA team tested. Additionally, it is difficult to guarantee atomic installs with most package managers, and an ill-timed power cycle can leave your device in an unpredictable state.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
OpenWRT is a good choice for hobbyist projects or for reusing commercial hardware. It is also a good choice for networking applications. If you need significant customization from the default setup, you may prefer Buildroot or Yocto.
|
||||
|
||||
### Desktop distros
|
||||
|
||||
A common approach to designing embedded Linux systems is to start with a desktop distribution, such as [Debian][17] or [Red Hat][18], and remove unneeded components until the installed image fits into the footprint of your target device. This is the approach taken for the popular [Raspbian][19] distribution for the [Raspberry Pi][20] platform.
|
||||
|
||||
#### Advantages
|
||||
|
||||
The primary advantage of this approach is familiarity. Often, embedded Linux developers are also desktop Linux users and are well-versed in their distro of choice. Using a similar environment on the target may allow developers to get started more quickly. Depending on the chosen distribution, many additional tools can be installed using standard packaging tools such as apt and yum.
|
||||
|
||||
It may be possible to attach a display and keyboard to your target device and do all your development directly there. For developers new to the embedded space, this is likely to be a more familiar environment and removes the need to configure and use a tricky cross-development setup.
|
||||
|
||||
The number of packages available for most desktop distributions is generally greater than that available for the embedded-specific builders discussed previously. Due to the larger user base and wider variety of use cases, you may be able to find all the runtime packages you need for your application already built and ready for use.
|
||||
|
||||
#### Disadvantages
|
||||
|
||||
Using the target as your primary development environment is likely to be slow. Running compiler tools is a resource-intensive operation and, depending on how much code you are building, may hinder your performance.
|
||||
|
||||
With some exceptions, desktop distributions are not designed to accommodate low-resource systems, and it may be difficult to adequately trim your target images. Similarly, the expected workflow in a desktop environment is not ideal for most embedded designs. Getting a reproducible environment in this fashion is difficult. Manually adding and deleting packages is error-prone. This can be scripted using distribution-specific tools, such as [debootstrap][21] for Debian-based systems. To further improve [reproducibility][21], you can use a configuration management tool, such as [CFEngine][22] (which, full disclosure, is made by my employer, [Mender.io][23]). However, you are still at the mercy of the distribution provider, who will update packages to meet their needs, not yours.
|
||||
|
||||
#### Recommendation
|
||||
|
||||
Be wary of this approach for a product you plan to take to market. This is a fine model for hobbyist applications; however, for products that need support, this approach is likely going to be trouble. While you may be able to get a faster start, it may cost you time and effort in the long run.
|
||||
|
||||
### Other considerations
|
||||
|
||||
This discussion has focused on build systems' functionality, but there are usually non-functional requirements that may affect your decision. If you have already selected your system-on-chip (SoC) or board, your choice will likely be dictated by the vendor. If your vendor provides a board support package (BSP) for a given system, using it will normally save quite a bit of time, but please research the BSP's quality to avoid issues later in your development cycle.
|
||||
|
||||
If your budget allows, you may want to consider using a commercial vendor for your target OS. There are companies that will provide a validated and supported configuration of many of the options discussed here, and, unless you have expertise in embedded Linux build systems, this is a good choice and will allow you to focus on your core competency.
|
||||
|
||||
As an alternative, you may consider commercial training for your development staff. This is likely to be cheaper than a commercial OS provider and will allow you to be more self-sufficient. This is a quick way to get over the learning curve for the basics of the build system you choose.
|
||||
|
||||
Finally, you may already have some developers with experience with one or more of the systems. If you have engineers who have a preference, it is certainly worth taking that into consideration as you make your decision.
|
||||
|
||||
### Summary
|
||||
|
||||
There are many choices available for building embedded Linux systems, each with advantages and disadvantages. It is crucial to prioritize this part of your design, as it is extremely costly to switch systems later in the process. In addition to these options, new systems are being developed all the time. Hopefully, this discussion will provide some context for reviewing new systems (and the ones mentioned here) and help you make a solid decision for your next project.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/embedded-linux-build-tools
|
||||
|
||||
作者：[Drew Moseley][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/drewmoseley
|
||||
[1]:https://en.wikipedia.org/wiki/Linux_on_z_Systems
|
||||
[2]:http://www.picotux.com/
|
||||
[3]:https://www.ubuntu.com/
|
||||
[4]:https://www.virtualbox.org/
|
||||
[5]:https://www.docker.com/
|
||||
[6]:https://en.wikipedia.org/wiki/Embedded_system
|
||||
[7]:https://yoctoproject.org/
|
||||
[8]:https://www.yoctoproject.org/about/
|
||||
[9]:https://www.openembedded.org/
|
||||
[10]:https://www.yoctoproject.org/community/
|
||||
[11]:https://www.yoctoproject.org/ecosystem/participants/
|
||||
[12]:https://layers.openembedded.org/layerindex/branch/master/layers/
|
||||
[13]:https://layers.openembedded.org/layerindex/branch/master/layer/meta-browser/
|
||||
[14]:https://yoctoproject.org/downloads
|
||||
[15]:https://buildroot.org/
|
||||
[16]:https://openwrt.org/
|
||||
[17]:https://www.debian.org/
|
||||
[18]:https://www.redhat.com/
|
||||
[19]:https://www.raspbian.org/
|
||||
[20]:https://www.raspberrypi.org/
|
||||
[21]:https://wiki.debian.org/Debootstrap
|
||||
[22]:https://cfengine.com/
|
||||
[23]:http://Mender.io
|
||||
@ -1,51 +0,0 @@
|
||||
|
||||
DevOps如何帮助你将很酷的应用交付给用户
|
||||
======
|
||||
|
||||
|
||||
|
||||
在很久之前，在DevOps成为主流实践之前，软件开放的过程是极其缓慢，单调和系统性的。当一个应用准备要部署的时候，一长串为下次主要的版本迭代的工具变更已经积累起来了。每次的新版本迭代的准备都将花费数月的时间去追溯以及贯穿整个开发周期的工作。请记住这个过程将会在交付更新给用户的过程中不断的
|
||||
重复。
|
||||
|
||||
今天一切都是瞬间和实时完成的，这个概念似乎很原始。这场移动革命已经极大的改变了我们和软件之间的交互。那些早期采用DevOps的公司已经彻底改变了对
|
||||
软件开发和部署的期望。
|
||||
|
||||
考虑到脸书：脸书这个移动应用每两周更新和刷新一次，像钟表一样，这就是新的标准因为现在的用户期望软件持续的被修复和更新。任何一家要花费一个月或者更多的
|
||||
时间来部署新的功能或者修复bug的公司将会逐渐走向没落。如果你不能交付用户所期待的，他们将会去寻找那些能够满足他们需求的。
|
||||
|
||||
Facebook，以及一些工业巨头如亚马逊，Netfix,谷歌以及其他的都已经强制要求企业变得更快速更有效的来满足如天的顾客们的需求。
|
||||
|
||||
### 为什么是DevOps?
|
||||
|
||||
敏捷和DevOps在移动应用开发领域是相当重要的因为开发周期正变得越来越快。现在是一个密集快节奏的环境，公司必须加紧步伐赶超，思考的更深入，运用策略来去完成从而生存下去。在应用商店中，排名前十的应用平均能够保持的时间只有一个月左右。
|
||||
|
||||
为了说明老式的瀑布方法，回想一下你第一次学习驾驶。起先，你专注于每个独立的层面，使用一套方法论的过程：你上车；系上安全带；调整座椅，镜子，控制方向盘，发动汽车，将你的手放在10点和2点钟的方向，等等。完成一个简单的任务就像是换车道一样需要付出艰苦的努力，在一个特定的顺序下执行多个步骤。
|
||||
|
||||
DevOps,正好相反，是在你有了几年的经验之后如何去驾驶的。一切都是靠直觉同时发生的，你可以不用过多的思考就很平滑的从A移动到B。
|
||||
|
||||
移动APP的世界对越老式的APP开发环境来说太快节奏了。DevOps被设计用来有效，稳定快速的在不需要增加资源的情况下交付应用。然而你不能像购买一件普通的商品或者服务一样去购买DevOps.DevOps是用来指导改变团队如何一起工作的文化和活动的。
|
||||
|
||||
不是只有像亚马逊和脸书这样的大公司拥抱DevOps文化；小的移动应用公司也在很好的使用。“在保持生产事故处于一个较低水平的同时速度啊迭代周期以及满足顾客最求的整体的失败成本。”来自移产品代理[Reinvently][1]的工程部的负责人，Oleg Reshetnyak说道。
|
||||
|
||||
### DevOps: 不是如果，而是什么时候
|
||||
|
||||
在今天的快节奏的商业环境中，选在了DevOps就像是选择了呼吸：要么去做要么就死亡。[2]
|
||||
|
||||
根据美国小企业管理的报道，现在只有16% 的公司能够持续一代人的时间。不采用DevOps的移动应用公司将冒着逐渐走向灭绝的风险。而且，同样的研究表明采用DevOps的公司组织可能能够超过盈利能力，生产目标以及市场份额。
|
||||
|
||||
更快速更安全的革新需要做到三点：云，自动化和DevOps, 根据你对DevOps的定义的不同，这三个要点之间的界限是不清晰的。然而，有一点是确定的：DevOps围绕着更快更少风险的交付高质量的软件的共同目标将组织额内的每个人都统一起来。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/2/devops-delivers-cool-apps-users
|
||||
|
||||
作者：[Stanislav Ivaschenko][a]
|
||||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/ilyadudkin
|
||||
[1]:https://reinvently.com/
|
||||
[2]:https://squadex.com/insights/devops-or-die/
|
||||
[3]:https://www.sba.gov/
|
||||
@ -0,0 +1,212 @@
|
||||
4种用于构建嵌入式Linux系统的工具
|
||||
======
|
||||
|
||||
|
||||
|
||||
Linux被部署到比Linus Torvalds在他的宿舍里工作时所预期的更广泛的设备。对各种芯片的支持是令人震惊的，使得Linux应用在大大小小的设备上：
|
||||
从[IBM的巨型机][1]到[微型设备][2]，没有比他们的连接端口和其间的任何东西都大。它被用于大型企业数据中心，互联网基础设施设备和个人开发系统。
|
||||
它还为消费电子产品、移动电话和许多物联网设备提供动力。
|
||||
|
||||
在为桌面和企业级设备构建Linux软件时，开发者典型的在他们的构建机器上使用桌面发行版，如[Ubuntu][3] 以便尽可能与被部署的机器相似。工具
|
||||
如[VirtualBox][4] and [Docker][5]使得开发测试和生成环境更好的保持一致
|
||||
|
||||
### 什么是嵌入式系统？
|
||||
|
||||
维基百科将[嵌入式系统] [6]定义为：“在更大的机械或电气系统中具有专用功能的计算机系统，往往伴随着实时计算限制。
|
||||
我觉得很简单，可以说嵌入式系统是大多数人不认为是计算机的计算机。它的主要作用是作为某种设备，它不被视为通用计算平台。
|
||||
|
||||
嵌入式系统编程中的开发环境通常与测试和生产环境大不相同。他们可能会使用不同的芯片架构，软件堆栈甚至操作系统。开发工作流程对于嵌入式开发
|
||||
人员与桌面和Web开发人员来说是非常不同通常，构建输出将包含目标设备的整个软件映像，包括内核，设备驱动程序，库和应用程序软件（有时也包括引导
|
||||
加载程序）。
|
||||
|
||||
在本文中，我将对构建嵌入式Linux系统的四种常用选项进行纵览。我将介绍一下每种产品的工作原理，并提供足够的信息来帮助读者确定使用哪种工具
|
||||
进行设计。我不会教你如何使用它们中的任何一个;一旦缩小了选择范围，就有大量深入的在线学习资源。没有任何选择适用于所有用例，我希望提供足够的
|
||||
细节来指导您的决定。
|
||||
### Yocto
|
||||
|
||||
[Yocto] [7]项目[定义] [8]是：一个开源协作项目，提供模板，工具和方法，帮助您为嵌入式产品创建定制的基于Linux的系统，而不管硬件架构如何。
|
||||
它是用于创建定制的Linux运行时映像的配方，配置值和依赖关系的集合，可根据您的特定需求进行定制。
|
||||
完全公开：我在嵌入式Linux中的大部分工作都集中在Yocto项目上，而且我对这个系统的认识和偏见可能很明显。
|
||||
Yocto使用[Openembedded] [9]作为其构建系统。从技术上讲，这两个是独立的项目;然而，在实践中，用户不需要了解区别，项目名称经常可以互换使用。
|
||||
|
||||
Yocto项目的输出大致由三部分组成：
|
||||
|
||||
* **目标运行时二进制文件：**这些包括引导加载程序，内核，内核模块，根文件系统映像。以及将Linux部署到目标平台所需的任何其他辅助文件。
|
||||
* **包流：**这是可以安装在目标上的软件包集合。您可以根据需要选择软件包格式（例如，deb，rpm，ipk）。其中一些可能预先安装在目标运行时
|
||||
二进制文件中，但可以构建用于安装到已部署系统的软件包。
|
||||
* **目标SDK：**这些是表示安装在目标上的软件的库和头文件的集合。应用程序开发人员在构建代码时使用它们，以确保它们与适当的库链接
|
||||
|
||||
#### 优点
|
||||
|
||||
Yocto项目在行业中得到广泛应用，并得到许多有影响力的公司的支持。此外，它还拥有一个庞大且充满活力的开发人员[社区] [10]和[生态系统] [11]。
|
||||
开源爱好者和企业赞助商的结合有助于推动Yocto项目。
|
||||
Yocto获得支持有很多选择。如果您想自己动手，还有书籍和其他培训材料。如果您想获得专业知识，许多有Yocto经验的工程师都可以使用。许多商业组
|
||||
织为您的设计提供基于Yocto的Turnkey产品或基于服务的实施和定制。
|
||||
Yocto项目很容易通过[layer] [12]进行扩展，它可以独立发布以添加额外的功能，将目标平台定位到项目发布中不可用的平台，或存储系统特有的自定义项。
|
||||
layer可以添加到您的配置中，以添加未特别包含在市面上版本中的独特功能;例如，[meta-browser] [13] layer包含Web浏览器的清单，可以轻松为您
|
||||
的系统进行构建。因为它们是独立维护的，所以layer可以在不同的发布时间安排上（根据layer的开发速度）而不是标准的Yocto版本。
|
||||
|
||||
Yocto可以说是本文讨论的任何选项中最广泛的设备支持。由于许多半导体和电路板制造商的支持，Yocto很可能会支持您选择的任何目标平台。
|
||||
主版本Yocto [分支] [14]仅支持少数几块主板（以便进行正确的测试和发布周期），但是，标准工作模式是使用外部主板支持layer。
|
||||
|
||||
最后，Yocto非常灵活和可定制。您的特定应用程序的自定义可以存储在一个layer进行封装和隔离。通常将要素layer特有的自定义项存储为layer本身
|
||||
的一部分，这可以将相同的设置同时应用于多个系统配置。 Yocto还提供了一个定义良好的layer优先和覆盖功能。这使您可以定义layer应用和搜索元数
|
||||
据的顺序。它还使您可以覆盖具有更高优先级的layer的设置;例如，现有清单的许多自定义功能都将保留
|
||||
|
||||
#### 缺点
|
||||
|
||||
Yocto项目最大的缺点是学习曲线。 学习系统并真正理解系统需要花费大量的时间和精力。 根据您的需求，这可能对您的应用程序不重要的技术和能力
|
||||
投入太大。 在这种情况下，与其中一家商业供应商合作可能是一个不错的选择。
|
||||
|
||||
Yocto项目的开发时间和资源相当高。 需要构建的包（包括工具链，内核和所有目标运行时组件）的数量非常重要。 Yocto开发人员的开发工作站往往是
|
||||
大型系统。 不建议使用小型笔记本电脑。 这可以通过使用许多提供商提供的基于云的构建服务器来缓解。 另外，Yocto有一个内置的缓存机制，当它确定
|
||||
用于构建特定包的参数没有改变时，它允许它重新使用先前构建的组件。
|
||||
|
||||
#### 建议
|
||||
|
||||
为您的下一个嵌入式Linux设计使用Yocto项目是一个强有力的选择。 在这里介绍的选项中，无论您的目标用例如何，它都是最广泛适用的。 广泛的行业
|
||||
支持，积极的社区和广泛的平台支持使其成为必须设计师的不错选择。
|
||||
|
||||
### Buildroot
|
||||
|
||||
[Buildroot] [15]项目被定义为:通过交叉编译生成嵌入式Linux系统的简单，高效且易于使用的工具。它与Yocto项目具有许多相同的目标，但它注重
|
||||
简单性和简约性。一般来说，Buildroot会禁用所有软件包的所有可选编译时设置（有一些值得注意的例外），从而导致尽可能小的系统。系统设计人员需要
|
||||
启用适用于给定设备的设置。
|
||||
|
||||
Buildroot从源代码构建所有组件，但不支持按目标包管理。因此，它有时称为固件生成器，因为镜像在构建时大部分是固定的。应用程序可以更新目标
|
||||
文件系统，但是没有机制将新软件包安装到正在运行的系统中。
|
||||
Buildroot输出主要由三部分组成：
|
||||
|
||||
*将Linux部署到目标平台所需的根文件系统映像和任何其他辅助文件
|
||||
*适用于目标硬件的内核，引导加载程序和内核模块
|
||||
*用于构建所有目标二进制文件的工具链。
|
||||
|
||||
### 优点
|
||||
|
||||
Buildroot对简单性的关注意味着，一般来说，它比Yocto更容易学习。核心构建系统用Make编写，并且足够短以允许开发人员了解整个系统，同时可扩展
|
||||
到足以满足嵌入式Linux开发人员的需求。 Buildroot核心通常只处理常见用例，但它可以通过脚本进行扩展。Buildroot系统使用普通的Makefile和Kconfig
|
||||
语言来进行配置。 Kconfig由Linux内核社区开发，广泛用于开源项目，使得许多开发人员都熟悉它。
|
||||
由于禁用所有可选构建时间设置的设计目标，Buildroot通常会使用开箱即用的配置生成尽可能最小的镜像。一般来说，构建时间和构建主机资源的规模
|
||||
将比Yocto项目的规模更小。
|
||||
|
||||
####缺点
|
||||
|
||||
关注简单性和最小化启用的构建选项意味着您可能需要执行重要的自定义来为应用程序配置Buildroot构建。此外，所有配置选项都存储在单个文件中，
|
||||
这意味着如果您有多个硬件平台，则需要为每个平台进行每个定制更改。对系统配置文件的任何更改都需要全部重新构建所有软件包。与Yocto相比，这可以
|
||||
通过最小的镜像大小和构建时间进行缓解，但在您调整配置时可能会导致构建时间过长。
|
||||
|
||||
中间软件包状态缓存默认情况下未启用，并且不像Yocto实施那么彻底。这意味着，虽然第一次构建可能比等效的Yocto构建短，但后续构建可能需要重建
|
||||
许多组件。
|
||||
|
||||
####建议
|
||||
|
||||
对于大多数应用程序，使用Buildroot进行下一个嵌入式Linux设计是一个不错的选择。如果您的设计需要多种硬件类型或其他差异，但由于同步多个配置
|
||||
的复杂性，您可能需要重新考虑，但对于由单一设置组成的系统，Buildroot可能适合您。
|
||||
|
||||
[OpenWRT] [16]项目开始为消费者路由器开发定制固件。您当地零售商提供的许多低成本路由器都可以运行Linux系统，但可能无法使用。这些路由器的
|
||||
制造商可能无法提供频繁的更新来解决新的威胁，即使他们这样做，安装更新镜像的机制也很困难且容易出错。 OpenWRT项目为许多已被其制造商放弃的
|
||||
设备生成更新的固件镜像，并让这些设备更加有效。
|
||||
|
||||
OpenWRT项目的主要交付物是大量商业设备的二进制镜像。有网络可访问的软件包存储库，允许设备最终用户将新软件添加到他们的系统中。 OpenWRT构建
|
||||
系统是一个通用构建系统，它允许开发人员创建自定义版本以满足他们自己的需求并添加新软件包，但其主要重点是目标二进制文件。
|
||||
|
||||
#### 优点
|
||||
|
||||
如果您正在寻找商业设备的替代固件，则OpenWRT应位于您的选项列表中。它的维护良好，可以保护您免受制造商固件无法解决的问题。您也可以添加额外的功能，使您的设备更有用。
|
||||
|
||||
如果您的嵌入式设计专注于网络，则OpenWRT是一个不错的选择。网络应用程序是OpenWRT的主要用例，您可能会发现许多可用的软件包。
|
||||
|
||||
####缺点
|
||||
|
||||
OpenWRT对您的设计施加重大决策（与Yocto和Buildroot相比）。如果这些决定不符合您的设计目标，则可能需要进行非平凡的修改。
|
||||
|
||||
在部署的设备中允许基于软件包的更新很难管理。按照定义，这会导致与您的QA团队测试的软件负载不同。此外，很难保证大多数软件包管理器的原子安装，
|
||||
以及错误的电源循环可能会使您的设备处于不可预知的状态。
|
||||
|
||||
####建议
|
||||
|
||||
OpenWRT是爱好者项目或重复使用商用硬件的不错选择。它也是网络应用程序的不错选择。如果您需要从默认设置进行大量定制，您可能更喜欢Buildroot或Yocto
|
||||
|
||||
### Desktop distros
|
||||
|
||||
设计嵌入式Linux系统的一种常见方法是从桌面发行版开始，例如[Debian] [17]或[Red Hat] [18]，并在安装的镜像符合目标设备的占用空间之前删除
|
||||
不需要的组件。这是[Raspberry Pi] [20]平台流行的[Raspbian] [19]分发方法。
|
||||
|
||||
### 优点
|
||||
|
||||
这种方法的主要优点是熟悉。通常，嵌入式Linux开发人员也是桌面Linux用户，并且精通他们的选择发行版。在目标上使用类似的环境可能会让开发人员
|
||||
更快地入门。根据所选的分布，可以使用apt和yum等标准封装工具安装许多其他工具。
|
||||
|
||||
可以将显示器和键盘连接到目标设备，并直接在那里进行所有的开发。对于不熟悉嵌入式空间的开发人员来说，这可能是一个更为熟悉的环境，无需配置和
|
||||
使用棘手的跨开发设置。
|
||||
|
||||
大多数桌面发行版可用的软件包数量通常大于前面讨论的嵌入式特定的构建器可用软件包数量。由于较大的用户群和更广泛的用例，您可能能够找到您的
|
||||
应用程序所需的所有运行时包，这些包已经构建并可供使用。
|
||||
|
||||
####缺点
|
||||
|
||||
将目标作为您的主要开发环境可能会很慢。运行编译器工具是一项资源密集型操作，根据您构建的代码的多少，可能会妨碍您的性能。
|
||||
|
||||
除了一些例外情况，桌面分布的设计并不适合低资源系统，并且可能难以充分修剪目标图像。同样，桌面环境中的预期工作流程对于大多数嵌入式设计来说
|
||||
都不理想。以这种方式获得可重复的环境很困难。手动添加和删除软件包很容易出错。这可以使用特定于发行版的工具进行脚本化，例如基于Debian系统
|
||||
的[debootstrap] [21]。为了进一步提高[可重复性] [21]，您可以使用配置管理工具，如[CFEngine] [22]（我的雇主[Mender.io] [23]完整披露了
|
||||
这一工具）。但是，您仍然受分发提供商的支配，他们将更新软件包以满足他们的需求，而不是您的需求。
|
||||
|
||||
####建议
|
||||
|
||||
对于您打算推向市场的产品，请谨慎使用此方法。这对于爱好者应用程序来说是一个很好的模型;但是，对于需要支持的产品，这种方法很可能会遇到麻烦。
|
||||
虽然您可能能够获得更快的起步，但从长远来看，您可能会花费您的时间和精力。
|
||||
|
||||
###其他考虑
|
||||
|
||||
这个讨论集中在构建系统的功能上，但通常有非功能性需求可能会影响您的决定。如果您已经选择了片上系统（SoC）或电路板，则您的选择很可能由供应商
|
||||
决定。如果您的供应商为特定系统提供板级支持包（BSP），使用它通常会节省相当多的时间，但请研究BSP的质量以避免在开发周期后期发生问题。
|
||||
|
||||
如果您的预算允许，您可能需要考虑为目标操作系统使用商业供应商。有些公司会为这里讨论的许多选项提供经过验证和支持的配置，除非您拥有嵌入式
|
||||
Linux构建系统方面的专业知识，否则这是一个不错的选择，可以让您专注于核心能力。
|
||||
|
||||
作为替代，您可以考虑为您的开发人员进行商业培训。这可能比商业OS提供商便宜，并且可以让你更加自给自足。这是快速找到您选择的构建系统基础知识
|
||||
的学习曲线。
|
||||
|
||||
最后，您可能已经有一些开发人员拥有一个或多个系统的经验。如果你有工程师有偏好，当你做出决定时，肯定值得考虑。
|
||||
|
||||
###总结
|
||||
|
||||
构建嵌入式Linux系统有多种选择，每种都有优点和缺点。将这部分设计放在优先位置至关重要，因为在以后的过程中切换系统的成本非常高。除了这些
|
||||
选择之外，新系统一直在开发中。希望这次讨论能够为审查新系统（以及这里提到的系统）提供一些背景，并帮助您为下一个项目做出坚实的决定。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/6/embedded-linux-build-tools
|
||||
|
||||
作者：[Drew Moseley][a]
|
||||
选题：[lujun9972](https://github.com/lujun9972)
|
||||
译者：[LHRChina](https://github.com/LHRChina)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/drewmoseley
|
||||
[1]:https://en.wikipedia.org/wiki/Linux_on_z_Systems
|
||||
[2]:http://www.picotux.com/
|
||||
[3]:https://www.ubuntu.com/
|
||||
[4]:https://www.virtualbox.org/
|
||||
[5]:https://www.docker.com/
|
||||
[6]:https://en.wikipedia.org/wiki/Embedded_system
|
||||
[7]:https://yoctoproject.org/
|
||||
[8]:https://www.yoctoproject.org/about/
|
||||
[9]:https://www.openembedded.org/
|
||||
[10]:https://www.yoctoproject.org/community/
|
||||
[11]:https://www.yoctoproject.org/ecosystem/participants/
|
||||
[12]:https://layers.openembedded.org/layerindex/branch/master/layers/
|
||||
[13]:https://layers.openembedded.org/layerindex/branch/master/layer/meta-browser/
|
||||
[14]:https://yoctoproject.org/downloads
|
||||
[15]:https://buildroot.org/
|
||||
[16]:https://openwrt.org/
|
||||
[17]:https://www.debian.org/
|
||||
[18]:https://www.redhat.com/
|
||||
[19]:https://www.raspbian.org/
|
||||
[20]:https://www.raspberrypi.org/
|
||||
[21]:https://wiki.debian.org/Debootstrap
|
||||
[22]:https://cfengine.com/
|
||||
[23]:http://Mender.io
|
||||
Loading…
Reference in New Issue
Block a user