document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'LCTT/master'

Browse Source
This commit is contained in:
Xingyu Wang 2019-11-05 09:37:52 +08:00
commit 4a974ab302
9 changed files with 493 additions and 504 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

289
published/20190902 How RPM packages are made- the spec file.md Normal file
View File

@ -0,0 +1,289 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: (wxy)
[#]: publisher: (wxy)
[#]: url: (https://linux.cn/article-11538-1.html)
[#]: subject: (How RPM packages are made: the spec file)
[#]: via: (https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/)
[#]: author: (Ankur Sinha "FranciscoD" https://fedoramagazine.org/author/ankursinha/)
如何编写 RPM 的 spec 文件
======
![][1]
在[关于 RPM 软件包构建的上一篇文章][2]中，你了解到了源 RPM 包括软件的源代码以及 spec 文件。这篇文章深入研究了 spec 文件，该文件中包含了有关如何构建 RPM 的指令。同样，本文以 `fpaste` 为例。
### 了解源代码
在开始编写 spec 文件之前，你需要对要打包的软件有所了解。在这里，你正在研究 `fpaste`，这是一个非常简单的软件。它是用 Python 编写的，并且是一个单文件脚本。当它发布新版本时，可在 Pagure 上找到：<https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz>。
如该档案文件所示，当前版本为 0.3.9.2。下载它，以便你查看该档案文件中的内容：
```
$ wget https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
$ tar -tvf fpaste-0.3.9.2.tar.gz
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/
-rw-rw-r-- root/root 25 2018-07-25 02:58 fpaste-0.3.9.2/.gitignore
-rw-rw-r-- root/root 3672 2018-07-25 02:58 fpaste-0.3.9.2/CHANGELOG
-rw-rw-r-- root/root 35147 2018-07-25 02:58 fpaste-0.3.9.2/COPYING
-rw-rw-r-- root/root 444 2018-07-25 02:58 fpaste-0.3.9.2/Makefile
-rw-rw-r-- root/root 1656 2018-07-25 02:58 fpaste-0.3.9.2/README.rst
-rw-rw-r-- root/root 658 2018-07-25 02:58 fpaste-0.3.9.2/TODO
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/
-rw-rw-r-- root/root 3867 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/fpaste.1
-rwxrwxr-x root/root 24884 2018-07-25 02:58 fpaste-0.3.9.2/fpaste
lrwxrwxrwx root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/fpaste.py -> fpaste
```
你要安装的文件是：
* `fpaste.py`：应该安装到 `/usr/bin/`。
* `docs/man/en/fpaste.1`：手册，应放到 `/usr/share/man/man1/`。
* `COPYING`：许可证文本，应放到 `/usr/share/license/fpaste/`。
* `README.rst`、`TODO`：放到 `/usr/share/doc/fpaste/` 下的其它文档。
这些文件的安装位置取决于文件系统层次结构标准（FHS）。要了解更多信息，可以在这里阅读：<http://www.pathname.com/fhs/> 或查看 Fedora 系统的手册页：
```
$ man hier
```
#### 第一部分：要构建什么？
现在我们知道了源文件中有哪些文件，以及它们要存放的位置，让我们看一下 spec 文件。你可以在此处查看这个完整的文件：<https://src.fedoraproject.org/rpms/fpaste/blob/master/f/fpaste.spec>。
这是 spec 文件的第一部分：
```
Name: fpaste
Version: 0.3.9.2
Release: 3%{?dist}
Summary: A simple tool for pasting info onto sticky notes instances
BuildArch: noarch
License: GPLv3+
URL: https://pagure.io/fpaste
Source0: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
Requires: python3
%description
It is often useful to be able to easily paste text to the Fedora
Pastebin at http://paste.fedoraproject.org and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin
```
`Name`、`Version` 等称为*标签*，它们定义在 RPM 中。这意味着你不能只是随意写点标签，RPM 无法理解它们！需要注意的标签是：
* `Source0`：告诉 RPM 该软件的源代码档案文件所在的位置。
* `Requires`：列出软件的运行时依赖项。RPM 可以自动检测很多依赖项，但是在某些情况下，必须手动指明它们。运行时依赖项是系统上必须具有的功能（通常是软件包），才能使该软件包起作用。这是 [dnf][3] 在安装此软件包时检测是否需要拉取其他软件包的方式。
* `BuildRequires`：列出了此软件的构建时依赖项。这些通常必须手动确定并添加到 spec 文件中。
* `BuildArch`：此软件为该计算机体系结构所构建。如果省略此标签，则将为所有受支持的体系结构构建该软件。值 `noarch` 表示该软件与体系结构无关（例如 `fpaste`，它完全是用 Python 编写的）。
本节提供有关 `fpaste` 的常规信息：它是什么，正在将什么版本制作为 RPM，其许可证等等。如果你已安装 `fpaste`，并查看其元数据时，则可以看到该 RPM 中包含的以下信息：
```
$ sudo dnf install fpaste
$ rpm -qi fpaste
Name : fpaste
Version : 0.3.9.2
Release : 2.fc30
...
```
RPM 会自动添加一些其他标签，以代表它所知道的内容。
至此，我们掌握了要为其构建 RPM 的软件的一般信息。接下来，我们开始告诉 RPM 做什么。
#### 第二部分：准备构建
spec 文件的下一部分是准备部分，用 `％prep` 代表：
```
%prep
%autosetup
```
对于 `fpaste`，这里唯一的命令是 `％autosetup`。这只是将 tar 档案文件提取到一个新文件夹中，并为下一部分的构建阶段做好了准备。你可以在此处执行更多操作，例如应用补丁程序，出于不同目的修改文件等等。如果你查看过 Python 的源 RPM 的内容，那么你会在那里看到许多补丁。这些都将在本节中应用。
通常，spec 文件中带有 `％` 前缀的所有内容都是 RPM 以特殊方式解释的宏或标签。这些通常会带有大括号，例如 `％{example}`。
#### 第三部分：构建软件
下一部分是构建软件的位置，用 `％build` 表示。现在，由于 `fpaste` 是一个简单的纯 Python 脚本，因此无需构建。因此，这里是：
```
%build
#nothing required
```
不过，通常来说，你会在此处使用构建命令，例如：
```
configure; make
```
构建部分通常是 spec 文件中最难的部分，因为这是从源代码构建软件的地方。这要求你知道该工具使用的是哪个构建系统，该系统可能是许多构建系统之一：Autotools、CMake、Meson、Setuptools（用于 Python）等等。每个都有自己的命令和语法样式。你需要充分了解这些才能正确构建软件。
#### 第四部分：安装文件
软件构建后，需要在 `％install` 部分中安装它：
```
%install
mkdir -p %{buildroot}%{_bindir}
make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}
```
在构建 RPM 时，RPM 不会修改你的系统文件。在一个可以正常运行的系统上添加、删除或修改文件的风险太大。如果发生故障怎么办？因此，RPM 会创建一个专门打造的文件系统并在其中工作。这称为 `buildroot`。 因此，在 `buildroot` 中，我们创建由宏 `％{_bindir}` 代表的 `/usr/bin` 目录，然后使用提供的 `Makefile` 将文件安装到其中。
至此，我们已经在专门打造的 `buildroot` 中安装了 `fpaste` 的构建版本。
#### 第五部分：列出所有要包括在 RPM 中的文件
spec 文件其后的一部分是文件部分：`％files`。在这里，我们告诉 RPM 从该 spec 文件创建的档案文件中包含哪些文件。`fpaste` 的文件部分非常简单：
```
%files
%{_bindir}/%{name}
%doc README.rst TODO
%{_mandir}/man1/%{name}.1.gz
%license COPYING
```
请注意，在这里，我们没有指定 `buildroot`。所有这些路径都是相对路径。`％doc` 和 `％license`命令做的稍微多一点，它们会创建所需的文件夹，并记住这些文件必须放在那里。
RPM 很聪明。例如，如果你在 `％install` 部分中安装了文件，但未列出它们，它会提醒你。
#### 第六部分：在变更日志中记录所有变更
Fedora 是一个基于社区的项目。许多贡献者维护或共同维护软件包。因此，当务之急是不要被软件包做了哪些更改所搞混。为了确保这一点，spec 文件包含的最后一部分是变更日志 `％changelog`：
```
%changelog
* Thu Jul 25 2019 Fedora Release Engineering < ...> - 0.3.9.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Thu Jan 31 2019 Fedora Release Engineering < ...> - 0.3.9.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Jul 24 2018 Ankur Sinha - 0.3.9.2-1
- Update to 0.3.9.2
* Fri Jul 13 2018 Fedora Release Engineering < ...> - 0.3.9.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Feb 07 2018 Fedora Release Engineering < ..> - 0.3.9.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Sun Sep 10 2017 Vasiliy N. Glazov < ...> - 0.3.9.1-2
- Cleanup spec
* Fri Sep 08 2017 Ankur Sinha - 0.3.9.1-1
- Update to latest release
- fixes rhbz 1489605
...
....
```
spec 文件的*每项*变更都必须有一个变更日志条目。如你在此处看到的，虽然我以维护者身份更新了该 spec 文件，但其他人也做过更改。清楚地记录变更内容有助于所有人知道该 spec 文件的当前状态。对于系统上安装的所有软件包，都可以使用 `rpm` 来查看其更改日志：
```
$ rpm -q --changelog fpaste
```
### 构建 RPM
现在我们准备构建 RPM 包。如果要继续执行以下命令，请确保遵循[上一篇文章][2]中的步骤设置系统以构建 RPM。
我们将 `fpaste` 的 spec 文件放置在 `~/rpmbuild/SPECS` 中，将源代码档案文件存储在 `~/rpmbuild/SOURCES/` 中，现在可以创建源 RPM 了：
```
$ cd ~/rpmbuild/SPECS
$ wget https://src.fedoraproject.org/rpms/fpaste/raw/master/f/fpaste.spec
$ cd ~/rpmbuild/SOURCES
$ wget https://pagure.io/fpaste/archive/0.3.9.2/fpaste-0.3.9.2.tar.gz
$ cd ~/rpmbuild/SOURCES
$ rpmbuild -bs fpaste.spec
Wrote: /home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
```
让我们看一下结果：
```
$ ls ~/rpmbuild/SRPMS/fpaste*
/home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
$ rpm -qpl ~/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
fpaste-0.3.9.2.tar.gz
fpaste.spec
```
我们看到源 RPM 已构建。让我们同时构建源 RPM 和二进制 RPM：
```
$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba fpaste.spec
..
..
..
```
RPM 将向你显示完整的构建输出，并在我们之前看到的每个部分中详细说明它的工作。此“构建日志”非常重要。当构建未按预期进行时，我们的打包人员将花费大量时间来遍历它们，以跟踪完整的构建路径来查看出了什么问题。
就是这样！准备安装的 RPM 应该位于以下位置：
```
$ ls ~/rpmbuild/RPMS/noarch/
fpaste-0.3.9.2-3.fc30.noarch.rpm
```
### 概括
我们已经介绍了如何从 spec 文件构建 RPM 的基础知识。这绝不是一份详尽的文档。实际上，它根本不是文档。它只是试图解释幕后的运作方式。简短回顾一下：
* RPM 有两种类型：源 RPM 和 二进制 RPM。
* 二进制 RPM 包含要安装以使用该软件的文件。
* 源 RPM 包含构建二进制 RPM 所需的信息：完整的源代码，以及 spec 文件中的有关如何构建 RPM 的说明。
* spec 文件包含多个部分，每个部分都有其自己的用途。
  
在这里，我们已经在安装好的 Fedora 系统中本地构建了 RPM。虽然这是个基本的过程，但我们从存储库中获得的 RPM 是建立在具有严格配置和方法的专用服务器上的，以确保正确性和安全性。这个 Fedora 打包流程将在以后的文章中讨论。
你想开始构建软件包，并帮助 Fedora 社区维护我们提供的大量软件吗？你可以[从这里开始加入软件包集合维护者][4]。
如有任何疑问，请发布到 [Fedora 开发人员邮件列表][5]，我们随时乐意为你提供帮助！
### 参考
这里有一些构建 RPM 的有用参考：
* <https://fedoraproject.org/wiki/How_to_create_an_RPM_package>
* <https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/>
* <https://docs.fedoraproject.org/en-US/packaging-guidelines/>
* <https://rpm.org/documentation.html>
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/
作者：[Ankur Sinha "FranciscoD"][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/ankursinha/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/06/rpm.png-816x345.jpg
[2]: https://linux.cn/article-11527-1.html
[3]: https://fedoramagazine.org/managing-packages-fedora-dnf/
[4]: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[5]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/

106
sources/talk/20191031 Why you don-t have to be afraid of Kubernetes.md
View File

@ -1,106 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (laingke)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Why you don't have to be afraid of Kubernetes)
[#]: via: (https://opensource.com/article/19/10/kubernetes-complex-business-problem)
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
Why you don't have to be afraid of Kubernetes
======
Kubernetes is absolutely the simplest, easiest way to meet the needs of
complex web applications.
![Digital creative of a browser on the internet][1]
It was fun to work at a large web property in the late 1990s and early 2000s. My experience takes me back to American Greetings Interactive, where on Valentine's Day, we had one of the top 10 sites on the internet (measured by web traffic). We delivered e-cards for [AmericanGreetings.com][2], [BlueMountain.com][3], and others, as well as providing e-cards for partners like MSN and AOL. Veterans of the organization fondly remember epic stories of doing great battle with other e-card sites like Hallmark. As an aside, I also ran large web properties for Holly Hobbie, Care Bears, and Strawberry Shortcake.
I remember like it was yesterday the first time we had a real problem. Normally, we had about 200Mbps of traffic coming in our front doors (routers, firewalls, and load balancers). But, suddenly, out of nowhere, the Multi Router Traffic Grapher (MRTG) graphs spiked to 2Gbps in a few minutes. I was running around, scrambling like crazy. I understood our entire technology stack, from the routers, switches, firewalls, and load balancers, to the Linux/Apache web servers, to our Python stack (a meta version of FastCGI), and the Network File System (NFS) servers. I knew where all of the config files were, I had access to all of the admin interfaces, and I was a seasoned, battle-hardened sysadmin with years of experience troubleshooting complex problems.
But, I couldn't figure out what was happening...
Five minutes feels like an eternity when you are frantically typing commands across a thousand Linux servers. I knew the site was going to go down any second because it's fairly easy to overwhelm a thousand-node cluster when it's divided up and compartmentalized into smaller clusters.
I quickly _ran_ over to my boss's desk and explained the situation. He barely looked up from his email, which frustrated me. He glanced up, smiled, and said, "Yeah, marketing probably ran an ad campaign. This happens sometimes." He told me to set a special flag in the application that would offload traffic to Akamai. I ran back to my desk, set the flag on a thousand web servers, and within minutes, the site was back to normal. Disaster averted.
I could share 50 more stories similar to this one, but the curious part of your mind is probably asking, "Where this is going?"
The point is, we had a business problem. Technical problems become business problems when they stop you from being able to do business. Stated another way, you can't handle customer transactions if your website isn't accessible.
So, what does all of this have to do with Kubernetes? Everything. The world has changed. Back in the late 1990s and early 2000s, only large web properties had large, web-scale problems. Now, with microservices and digital transformation, every business has a large, web-scale problem—likely multiple large, web-scale problems.
Your business needs to be able to manage a complex web-scale property with many different, often sophisticated services built by many different people. Your web properties need to handle traffic dynamically, and they need to be secure. These properties need to be API-driven at all layers, from the infrastructure to the application layer.
### Enter Kubernetes
Kubernetes isn't complex; your business problems are. When you want to run applications in production, there is a minimum level of complexity required to meet the performance (scaling, jitter, etc.) and security requirements. Things like high availability (HA), capacity requirements (N+1, N+2, N+100), and eventually consistent data technologies become a requirement. These are production requirements for every company that has digitally transformed, not just the large web properties like Google, Facebook, and Twitter.
In the old world, I lived at American Greetings, every time we onboarded a new service, it looked something like this. All of this was handled by the web operations team, and none of it was offloaded to other teams using ticket systems, etc. This was DevOps before there was DevOps:
1. Configure DNS (often internal service layers and external public-facing)
2. Configure load balancers (often internal services and public-facing)
3. Configure shared access to files (large NFS servers, clustered file systems, etc.)
4. Configure clustering software (databases, service layers, etc.)
5. Configure webserver cluster (could be 10 or 50 servers)
Most of this was automated with configuration management, but configuration was still complex because every one of these systems and services had different configuration files with completely different formats. We investigated tools like [Augeas][4] to simplify this but determined that it was an anti-pattern to try and normalize a bunch of different configuration files with a translator.
Today with Kubernetes, onboarding a new service essentially looks like:
1. Configure Kubernetes YAML/JSON.
2. Submit it to the Kubernetes API (**kubectl create -f service.yaml**).
Kubernetes vastly simplifies onboarding and management of services. The service owner, be it a sysadmin, developer, or architect, can create a YAML/JSON file in the Kubernetes format. With Kubernetes, every system and every user speaks the same language. All users can commit these files in the same Git repository, enabling GitOps.
Moreover, deprecating and removing a service is possible. Historically, it was terrifying to remove DNS entries, load-balancer entries, web-server configurations, etc. because you would almost certainly break something. With Kubernetes, everything is namespaced, so an entire service can be removed with a single command. You can be much more confident that removing your service won't break the infrastructure environment, although you still need to make sure other applications don't use it (a downside with microservices and function-as-a-service [FaaS]).
### Building, managing, and using Kubernetes
Too many people focus on building and managing Kubernetes instead of using it (see [_Kubernetes is a_ _dump truck_][5]).
Building a simple Kubernetes environment on a single node isn't markedly more complex than installing a LAMP stack, yet we endlessly debate the build-versus-buy question. It's not Kubernetes that's hard; it's running applications at scale with high availability. Building a complex, highly available Kubernetes cluster is hard because building any cluster at this scale is hard. It takes planning and a lot of software. Building a simple dump truck isn't that complex, but building one that can carry [10 tons of dirt and handle pretty well at 200mph][6] is complex.
Managing Kubernetes can be complex because managing large, web-scale clusters can be complex. Sometimes it makes sense to manage this infrastructure; sometimes it doesn't. Since Kubernetes is a community-driven, open source project, it gives the industry the ability to manage it in many different ways. Vendors can sell hosted versions, while users can decide to manage it themselves if they need to. (But you should question whether you actually need to.)
Using Kubernetes is the easiest way to run a large-scale web property that has ever been invented. Kubernetes is democratizing the ability to run a set of large, complex web services—like Linux did with Web 1.0.
Since time and money is a zero-sum game, I recommend focusing on using Kubernetes. Spend your very limited time and money on [mastering Kubernetes primitives][7] or the best way to handle [liveness and readiness probes][8] (another example demonstrating that large, complex services are hard). Don't focus on building and managing Kubernetes. A lot of vendors can help you with that.
### Conclusion
I remember troubleshooting countless problems like the one I described at the beginning of this article—NFS in the Linux kernel at that time, our homegrown CFEngine, redirect problems that only surfaced on certain web servers, etc. There was no way a developer could help me troubleshoot any of these problems. In fact, there was no way a developer could even get into the system and help as a second set of eyes unless they had the skills of a senior sysadmin. There was no console with graphics or "observability"—observability was in my brain and the brains of the other sysadmins. Today, with Kubernetes, Prometheus, Grafana, and others, that's all changed.
The point is:
1. The world is different. All web applications are now large, distributed systems. As complex as AmericanGreetings.com was back in the day, the scaling and HA requirements of that site are now expected for every website.
2. Running large, distributed systems is hard. Period. This is the business requirement, not Kubernetes. Using a simpler orchestrator isn't the answer.
Kubernetes is absolutely the simplest, easiest way to meet the needs of complex web applications. This is the world we live in and where Kubernetes excels. You can debate whether you should build or manage Kubernetes yourself. There are plenty of vendors that can help you with building and managing it, but it's pretty difficult to deny that it's the easiest way to run complex web applications at scale.
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/10/kubernetes-complex-business-problem
作者：[Scott McCarty][a]
选题：[lujun9972][b]
译者：[laingke](https://github.com/laingke)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/fatherlinux
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_web_internet_website.png?itok=g5B_Bw62 (Digital creative of a browser on the internet)
[2]: http://AmericanGreetings.com
[3]: http://BlueMountain.com
[4]: http://augeas.net/
[5]: https://opensource.com/article/19/6/kubernetes-dump-truck
[6]: http://crunchtools.com/kubernetes-10-ton-dump-truck-handles-pretty-well-200-mph/
[7]: https://opensource.com/article/19/6/kubernetes-basics
[8]: https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html

299
sources/tech/20190902 How RPM packages are made- the spec file.md
View File

@ -1,299 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (How RPM packages are made: the spec file)
[#]: via: (https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/)
[#]: author: (Ankur Sinha "FranciscoD" https://fedoramagazine.org/author/ankursinha/)
How RPM packages are made: the spec file
======
![][1]
In the [previous article on RPM package building][2], you saw that source RPMS include the source code of the software, along with a “spec” file. This post digs into the spec file, which contains instructions on how to build the RPM. Again, this article uses _fpaste_ as an example.
### Understanding the source code
Before you can start writing a spec file, you need to have some idea of the software that you’re looking to package. Here, you’re looking at fpaste, a very simple piece of software. It is written in Python, and is a one file script. When a new version is released, it’s provided here on Pagure: <https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz>
The current version, as the archive shows, is 0.3.9.2. Download it so you can see what’s in the archive:
```
$ wget https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
$ tar -tvf fpaste-0.3.9.2.tar.gz
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/
-rw-rw-r-- root/root 25 2018-07-25 02:58 fpaste-0.3.9.2/.gitignore
-rw-rw-r-- root/root 3672 2018-07-25 02:58 fpaste-0.3.9.2/CHANGELOG
-rw-rw-r-- root/root 35147 2018-07-25 02:58 fpaste-0.3.9.2/COPYING
-rw-rw-r-- root/root 444 2018-07-25 02:58 fpaste-0.3.9.2/Makefile
-rw-rw-r-- root/root 1656 2018-07-25 02:58 fpaste-0.3.9.2/README.rst
-rw-rw-r-- root/root 658 2018-07-25 02:58 fpaste-0.3.9.2/TODO
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/
drwxrwxr-x root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/
-rw-rw-r-- root/root 3867 2018-07-25 02:58 fpaste-0.3.9.2/docs/man/en/fpaste.1
-rwxrwxr-x root/root 24884 2018-07-25 02:58 fpaste-0.3.9.2/fpaste
lrwxrwxrwx root/root 0 2018-07-25 02:58 fpaste-0.3.9.2/fpaste.py -> fpaste
```
The files you want to install are:
* _fpaste.py_: which should go be installed to /usr/bin/.
* _docs/man/en/fpaste.1_: the manual, which should go to /usr/share/man/man1/.
* _COPYING_: the license text, which should go to /usr/share/license/fpaste/.
* _README.rst, TODO_: miscellaneous documentation that goes to /usr/share/doc/fpaste.
Where these files are installed depends on the Filesystem Hierarchy Standard. To learn more about it, you can either read here: <http://www.pathname.com/fhs/> or look at the man page on your Fedora system:
```
$ man hier
```
#### Part 1: What are we building?
Now that we know what files we have in the source, and where they are to go, let’s look at the spec file. You can see the full file here: <https://src.fedoraproject.org/rpms/fpaste/blob/master/f/fpaste.spec>
Here is the first part of the spec file:
```
Name: fpaste
Version: 0.3.9.2
Release: 3%{?dist}
Summary: A simple tool for pasting info onto sticky notes instances
BuildArch: noarch
License: GPLv3+
URL: https://pagure.io/fpaste
Source0: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
Requires: python3
%description
It is often useful to be able to easily paste text to the Fedora
Pastebin at http://paste.fedoraproject.org and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin
```
_Name_, _Version_, and so on are called _tags_, and are defined in RPM. This means you can’t just make up tags. RPM won’t understand them if you do! The tags to keep an eye out for are:
* _Source0_: tells RPM where the source archive for this software is located.
* _Requires_: lists run-time dependencies for the software. RPM can automatically detect quite a few of these, but in some cases they must be mentioned manually. A run-time dependency is a capability (often a package) that must be on the system for this package to function. This is how _[dnf][3]_ detects whether it needs to pull in other packages when you install this package.
* _BuildRequires_: lists the build-time dependencies for this software. These must generally be determined manually and added to the spec file.
* _BuildArch_: the computer architectures that this software is being built for. If this tag is left out, the software will be built for all supported architectures. The value _noarch_ means the software is architecture independent (like fpaste, which is written purely in Python).
This section provides general information about fpaste: what it is, which version is being made into an RPM, its license, and so on. If you have fpaste installed, and look at its metadata, you can see this information included in the RPM:
```
$ sudo dnf install fpaste
$ rpm -qi fpaste
Name : fpaste
Version : 0.3.9.2
Release : 2.fc30
...
```
RPM adds a few extra tags automatically that represent things that it knows.
At this point, we have the general information about the software that we’re building an RPM for. Next, we start telling RPM what to do.
#### Part 2: Preparing for the build
The next part of the spec is the preparation section, denoted by _%prep_:
```
%prep
%autosetup
```
For fpaste, the only command here is %autosetup. This simply extracts the tar archive into a new folder and keeps it ready for the next section where we build it. You can do more here, like apply patches, modify files for different purposes, and so on. If you did look at the contents of the source rpm for Python, you would have seen lots of patches there. These are all applied in this section.
Typically anything in a spec file with the **%** prefix is a macro or label that RPM interprets in a special way. Often these will appear with curly braces, such as _%{example}_.
#### Part 3: Building the software
The next section is where the software is built, denoted by “%build”. Now, since fpaste is a simple, pure Python script, it doesn’t need to be built. So, here we get:
```
%build
#nothing required
```
Generally, though, you’d have build commands here, like:
```
configure; make
```
The build section is often the hardest section of the spec, because this is where the software is being built from source. This requires you to know what build system the tool is using, which could be one of many: Autotools, CMake, Meson, Setuptools (for Python) and so on. Each has its own commands and style. You need to know these well enough to get the software to build correctly.
#### Part 4: Installing the files
Once the software is built, it needs to be installed in the _%install_ section:
```
%install
mkdir -p %{buildroot}%{_bindir}
make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}
```
RPM doesn’t tinker with your system files when building RPMs. It’s far too risky to add, remove, or modify files to a working installation. What if something breaks? So, instead RPM creates an artificial file system and works there. This is referred to as the _buildroot_. So, here in the buildroot, we create _/usr/bin_, represented by the macro _%{_bindir}_, and then install the files to it using the provided Makefile.
At this point, we have a built version of fpaste installed in our artificial buildroot.
#### Part 5: Listing all files to be included in the RPM
The last section of the spec file is the files section, _%files_. This is where we tell RPM what files to include in the archive it creates from this spec file. The fpaste file section is quite simple:
```
%files
%{_bindir}/%{name}
%doc README.rst TODO
%{_mandir}/man1/%{name}.1.gz
%license COPYING
```
Notice how, here, we do not specify the buildroot. All of these paths are relative to it. The _%doc_ and _%license_ commands simply do a little more—they create the required folders and remember that these files must go there.
RPM is quite smart. If you’ve installed files in the _%install_ section, but not listed them, it’ll tell you this, for example.
#### Part 6: Document all changes in the change log
Fedora is a community based project. Lots of contributors maintain and co-maintain packages. So it is imperative that there’s no confusion about what changes have been made to a package. To ensure this, the spec file contains the last section, the Changelog, _%changelog_:
```
%changelog
* Thu Jul 25 2019 Fedora Release Engineering < ...> - 0.3.9.2-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Thu Jan 31 2019 Fedora Release Engineering < ...> - 0.3.9.2-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Tue Jul 24 2018 Ankur Sinha - 0.3.9.2-1
- Update to 0.3.9.2
* Fri Jul 13 2018 Fedora Release Engineering < ...> - 0.3.9.1-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Wed Feb 07 2018 Fedora Release Engineering < ..> - 0.3.9.1-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Sun Sep 10 2017 Vasiliy N. Glazov < ...> - 0.3.9.1-2
- Cleanup spec
* Fri Sep 08 2017 Ankur Sinha - 0.3.9.1-1
- Update to latest release
- fixes rhbz 1489605
...
....
```
There must be a changelog entry for _every_ change to the spec file. As you see here, while I’ve updated the spec as the maintainer, others have too. Having the changes documented clearly helps everyone know what the current status of the spec is. For all packages installed on your system, you can use rpm to see their changelogs:
```
$ rpm -q --changelog fpaste
```
### Building the RPM
Now we are ready to build the RPM. If you want to follow along and run the commands below, please ensure that you followed the steps [in the previous post][2] to set your system up for building RPMs.
We place the fpaste spec file in _~/rpmbuild/SPECS_, the source code archive in _~/rpmbuild/SOURCES/_ and can now create the source RPM:
```
$ cd ~/rpmbuild/SPECS
$ wget https://src.fedoraproject.org/rpms/fpaste/raw/master/f/fpaste.spec
$ cd ~/rpmbuild/SOURCES
$ wget https://pagure.io/fpaste/archive/0.3.9.2/fpaste-0.3.9.2.tar.gz
$ cd ~/rpmbuild/SOURCES
$ rpmbuild -bs fpaste.spec
Wrote: /home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
```
Let’s have a look at the results:
```
$ ls ~/rpmbuild/SRPMS/fpaste*
/home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
$ rpm -qpl ~/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
fpaste-0.3.9.2.tar.gz
fpaste.spec
```
There we are — the source rpm has been built. Let’s build both the source and binary rpm together:
```
$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba fpaste.spec
..
..
..
```
RPM will show you the complete build output, with details on what it is doing in each section that we saw before. This “build log” is extremely important. When builds do not go as expected, we packagers spend lots of time going through them, tracing the complete build path to see what went wrong.
That’s it really! Your ready-to-install RPMs are where they should be:
```
$ ls ~/rpmbuild/RPMS/noarch/
fpaste-0.3.9.2-3.fc30.noarch.rpm
```
### Recap
We’ve covered the basics of how RPMs are built from a spec file. This is by no means an exhaustive document. In fact, it isn’t documentation at all, really. It only tries to explain how things work under the hood. Here’s a short recap:
* RPMs are of two types: _source_ and _binary_.
* Binary RPMs contain the files to be installed to use the software.
* Source RPMs contain the information needed to build the binary RPMs: the complete source code, and the instructions on how to build the RPM in the spec file.
* The spec file has various sections, each with its own purpose.
Here, we’ve built RPMs locally, on our Fedora installations. While this is the basic process, the RPMs we get from repositories are built on dedicated servers with strict configurations and methods to ensure correctness and security. This Fedora packaging pipeline will be discussed in a future post.
Would you like to get started with building packages, and help the Fedora community maintain the massive amount of software we provide? You can [start here by joining the package collection maintainers][4].
For any queries, post to the [Fedora developers mailing list][5]—we’re always happy to help!
### References
Here are some useful references to building RPMs:
* <https://fedoraproject.org/wiki/How_to_create_an_RPM_package>
* <https://docs.fedoraproject.org/en-US/quick-docs/create-hello-world-rpm/>
* <https://docs.fedoraproject.org/en-US/packaging-guidelines/>
* <https://rpm.org/documentation.html>
* * *
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/how-rpm-packages-are-made-the-spec-file/
作者：[Ankur Sinha "FranciscoD"][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/ankursinha/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/06/rpm.png-816x345.jpg
[2]: https://fedoramagazine.org/how-rpm-packages-are-made-the-source-rpm/
[3]: https://fedoramagazine.org/managing-packages-fedora-dnf/
[4]: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
[5]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/

2
sources/tech/20191021 How to program with Bash- Syntax and tools.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (jdh8383)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

96
sources/tech/20191029 Upgrading Fedora 30 to Fedora 31.md
View File

@ -1,96 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Upgrading Fedora 30 to Fedora 31)
[#]: via: (https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/)
[#]: author: (Ben Cotton https://fedoramagazine.org/author/bcotton/)
Upgrading Fedora 30 to Fedora 31
======
![][1]
Fedora 31 [is available now][2]. You’ll likely want to upgrade your system to get the latest features available in Fedora. Fedora Workstation has a graphical upgrade method. Alternatively, Fedora offers a command-line method for upgrading Fedora 30 to Fedora 31.
### Upgrading Fedora 30 Workstation to Fedora 31
Soon after release time, a notification appears to tell you an upgrade is available. You can click the notification to launch the **GNOME Software** app. Or you can choose Software from GNOME Shell.
Choose the _Updates_ tab in GNOME Software and you should see a screen informing you that Fedora 31 is Now Available.
If you don’t see anything on this screen, try using the reload button at the top left. It may take some time after release for all systems to be able to see an upgrade available.
Choose _Download_ to fetch the upgrade packages. You can continue working until you reach a stopping point, and the download is complete. Then use GNOME Software to restart your system and apply the upgrade. Upgrading takes time, so you may want to grab a coffee and come back to the system later.
### Using the command line
If you’ve upgraded from past Fedora releases, you are likely familiar with the _dnf upgrade_ plugin. This method is the recommended and supported way to upgrade from Fedora 30 to Fedora 31. Using this plugin will make your upgrade to Fedora 31 simple and easy.
#### 1\. Update software and back up your system
Before you do start the upgrade process, make sure you have the latest software for Fedora 30. This is particularly important if you have modular software installed; the latest versions of dnf and GNOME Software include improvements to the upgrade process for some modular streams. To update your software, use _GNOME Software_ or enter the following command in a terminal.
```
sudo dnf upgrade --refresh
```
Additionally, make sure you back up your system before proceeding. For help with taking a backup, see [the backup series][3] on the Fedora Magazine.
#### 2\. Install the DNF plugin
Next, open a terminal and type the following command to install the plugin:
```
sudo dnf install dnf-plugin-system-upgrade
```
#### 3\. Start the update with DNF
Now that your system is up-to-date, backed up, and you have the DNF plugin installed, you can begin the upgrade by using the following command in a terminal:
```
sudo dnf system-upgrade download --releasever=31
```
This command will begin downloading all of the upgrades for your machine locally to prepare for the upgrade. If you have issues when upgrading because of packages without updates, broken dependencies, or retired packages, add the _‐‐allowerasing_ flag when typing the above command. This will allow DNF to remove packages that may be blocking your system upgrade.
#### 4\. Reboot and upgrade
Once the previous command finishes downloading all of the upgrades, your system will be ready for rebooting. To boot your system into the upgrade process, type the following command in a terminal:
```
sudo dnf system-upgrade reboot
```
Your system will restart after this. Many releases ago, the _fedup_ tool would create a new option on the kernel selection / boot screen. With the _dnf-plugin-system-upgrade_ package, your system reboots into the current kernel installed for Fedora 30; this is normal. Shortly after the kernel selection screen, your system begins the upgrade process.
Now might be a good time for a coffee break! Once it finishes, your system will restart and you’ll be able to log in to your newly upgraded Fedora 31 system.
![][4]
### Resolving upgrade problems
On occasion, there may be unexpected issues when you upgrade your system. If you experience any issues, please visit the [DNF system upgrade quick docs][5] for more information on troubleshooting.
If you are having issues upgrading and have third-party repositories installed on your system, you may need to disable these repositories while you are upgrading. For support with repositories not provided by Fedora, please contact the providers of the repositories.
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/
作者：[Ben Cotton][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/bcotton/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/10/f30-f31-816x345.jpg
[2]: https://fedoramagazine.org/announcing-fedora-31/
[3]: https://fedoramagazine.org/taking-smart-backups-duplicity/
[4]: https://cdn.fedoramagazine.org/wp-content/uploads/2016/06/Screenshot_f23-ws-upgrade-test_2016-06-10_110906-1024x768.png
[5]: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#Resolving_post-upgrade_issues

2
sources/tech/20191101 Keyboard Shortcuts to Speed Up Your Work in Linux.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

2
sources/tech/20191104 How To Update a Fedora Linux System -Beginner-s Tutorial.md
View File

@ -1,5 +1,5 @@
[#]: collector: (lujun9972)
[#]: translator: ( )
[#]: translator: (Morisun029)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )

105
translated/talk/20191031 Why you don-t have to be afraid of Kubernetes.md Normal file
View File

@ -0,0 +1,105 @@
[#]: collector: (lujun9972)
[#]: translator: (laingke)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Why you don't have to be afraid of Kubernetes)
[#]: via: (https://opensource.com/article/19/10/kubernetes-complex-business-problem)
[#]: author: (Scott McCarty https://opensource.com/users/fatherlinux)
为什么你不必害怕 Kubernetes
======
Kubernetes 绝对是满足复杂 web 应用程序需求的最简单，最容易的方法。
![Digital creative of a browser on the internet][1]
在 90 年代末和 00 年代初，在大型网络媒体资源上工作很有趣。我的经历让我想起了 American Greetings Interactive，在情人节那天，我们拥有互联网上排名前 10 位之一的网站（以网络访问量衡量）。我们为 [AmericanGreetings.com][2]，[BlueMountain.com][3] 等公司提供了电子贺卡，并为 MSN 和 AOL 等合作伙伴提供了电子贺卡。该组织的老员工仍然深切地记得与 Hallmark 等其它电子贺卡网站进行大战的史诗般的故事。 顺便说一句，我还为 Holly Hobbie，Care Bears 和 Strawberry Shortcake 经营大型网站。
我记得就像那是昨天发生的一样，这是我们第一次遇到真正的问题。通常，我们的前门（路由器，防火墙和负载均衡器）有大约 200Mbps 的流量进入。但是，突然之间，Multi Router Traffic Grapher（MRTG）图示突然在几分钟内飙升至 2Gbps。我疯了似地东奔西跑。我了解了我们的整个技术堆栈，从路由器，交换机，防火墙和负载平衡器，到 Linux/Apache web 服务器，到我们的 Python 堆栈（FastCGI 的元版本），以及网络文件系统（NFS）服务器。我知道所有配置文件在哪里，我可以访问所有管理界面，并且我是一位经验丰富的，经验丰富的系统管理员，具有多年解决复杂问题的经验。
但是，我无法弄清楚发生了什么……
当你在一千个 Linux 服务器上疯狂地键入命令时，五分钟的感觉就像是永恒。我知道站点可能会在任何时候崩溃，因为当它被划分成更小的集群时，压垮上千个节点的集群是那么的容易。
我迅速 _跑到_ 老板的办公桌前，解释了情况。他几乎没有从电子邮件中抬头，这使我感到沮丧。他抬头看了看，笑了笑，说道：“是的，市场营销可能会开展广告活动。有时会发生这种情况。”他告诉我在应用程序中设置一个特殊标志，以减轻 Akamai 的访问量。 我跑回我的办公桌，在上千台 web 服务器上设置了标志，几分钟后，该站点恢复正常。灾难也就被避免了。
我可以再分享 50 个类似的故事，但你脑海中可能会有一点好奇：“这种运维方式将走向何方?”
关键是，我们遇到了业务问题。当技术问题使你无法开展业务时，它们就变成了业务问题。换句话说，如果你的网站无法访问，你就不能处理客户交易。
那么，所有这些与 Kubernetes 有什么关系？一切。世界已经改变。早在 90 年代末和 00 年代初，只有大型网站才出现大型网络规模级的问题。现在，有了微服务和数字化转型，每个企业都面临着一个大型的网络规模级的问题——可能是多个大型的网络规模级的问题。
你的企业需要能够通过许多不同的人构建的许多不同的，通常是复杂的服务来管理复杂的网络规模的资产。你的网站需要动态地处理流量，并且它们必须是安全的。这些属性需要在所有层（从基础结构到应用程序层）上由 API 驱动。
### 进入 Kubernetes
Kubernetes 并不复杂；你的业务问题才是。当你想在生产环境中运行应用程序时，要满足性能（伸缩性，抖动等）和安全性要求，就需要最低程度的复杂性。诸如高可用性（HA），容量要求（N+1，N+2，N+100）以及保证最终一致性的数据技术等就会成为必需。这些是每家进行数字化转型的公司的生产要求，而不仅仅是 Google，Facebook 和 Twitter 这样的大型网站。
在旧时代，我还在 American Greetings 任职时，每次我们加入一个新的服务，它看起来像这样：所有这些都是由网络运营团队来处理的，没有一个是通过标签系统转移给其他团队来处理的。这是在 DevOps 出现之前的 DevOps：
1. 配置DNS（通常是内部服务层和面向外部的公众）
2. 配置负载均衡器（通常是内部服务和面向公众的）
3. 配置对文件的共享访问（大型 NFS 服务器，群集文件系统等）
4. 配置集群软件（数据库，服务层等）
5. 配置 web 服务器群集（可以是 10 或 50 个服务器）
大多数配置是通过配置管理自动完成的，但是配置仍然很复杂，因为每个系统和服务都有不同的配置文件，而且格式完全不同。我们研究了像 [Augeas][4] 这样的工具来简化它，但是我们认为使用转换器来尝试和标准化一堆不同的配置文件是一种反模式。
如今，借助Kubernetes，启动一项新服务本质上看起来如下：
1. 配置 Kubernetes YAML/JSON。
2. 提交给 Kubernetes API（```kubectl create -f service.yaml```）。
Kubernetes 大大简化了服务的启动和管理。服务所有者（无论是系统管理员，开发人员还是架构师）都可以创建 Kubernetes 格式的 YAML/JSON 文件。使用 Kubernetes，每个系统和每个用户都说相同的语言。所有用户都可以在同一 Git 存储库中提交这些文件，从而启用 GitOps。
而且，可以弃用和删除服务。从历史上看，删除 DNS 条目，负载平衡器条目，web 服务器配置等是非常可怕的，因为你几乎肯定会破坏某些东西。使用 Kubernetes，所有内容都被命名为名称空间，因此可以通过单个命令删除整个服务。尽管你仍然需要确保其它应用程序不使用它（微服务和功能即服务（FaaS）的缺点），但你可以更加确信：删除服务不会破坏基础架构环境。
### 构建，管理和使用 Kubernetes
太多的人专注于构建和管理 Kubernetes 而不是使用它（详见 [_Kubernetes 是一辆翻斗车_][5]）.
在单个节点上构建一个简单的 Kubernetes 环境并不比安装 LAMP 堆栈复杂得多，但是我们无休止地争论着构建与购买的问题。不是Kubernetes很难；它以高可用性大规模运行应用程序。建立一个复杂的，高可用性的 Kubernetes 集群很困难，因为要建立如此规模的任何集群都是很困难的。它需要规划和大量软件。建造一辆简单的翻斗车并不复杂，但是建造一辆可以运载 [10 吨灰尘并能以 200mph 的速度稳定行驶的卡车][6]则很复杂。
管理 Kubernetes 可能很复杂，因为管理大型网络规模的集群可能很复杂。有时，管理此基础架构很有意义；而有时不是。由于 Kubernetes 是一个社区驱动的开源项目，它使行业能够以多种不同方式对其进行管理。供应商可以出售托管版本，而用户可以根据需要自行决定对其进行管理。（但是你应该质疑是否确实需要。）
使用 Kubernetes 是迄今为止运行大规模网络资源的最简单方法。Kubernetes 正在普及运行一组大型、复杂的 Web 服务的能力——就像当年 Linux 在 Web 1.0 中所做的那样。
由于时间和金钱是一个零和游戏，因此我建议将重点放在使用 Kubernetes 上。将你的时间和金钱花费在[掌握 Kubernetes 原语][7]或处理[活跃度和就绪性探针][8]的最佳方法上（另一个例子表明大型、复杂的服务很难）。不要专注于构建和管理 Kubernetes。（在构建和管理上）许多供应商可以为你提供帮助。
### 结论
我记得对无数的问题进行了故障排除，比如我在这篇文章的开头所描述的问题——当时 Linux 内核中的 NFS，我们自产的 CFEngine，仅在某些 web 服务器上出现的重定向问题等）。开发人员无法帮助我解决所有这些问题。实际上，除非开发人员具备高级系统管理员的技能，否则他们甚至不可能进入系统并作为第二组眼睛提供帮助。没有带有图形或“可观察性”的控制台——可观察性在我和其他系统管理员的大脑中。如今，有了 Kubernetes，Prometheus，Grafana 等，一切都改变了。
关键是：
1. 时代不一样了。现在，所有 web 应用程序都是大型的分布式系统。就像 AmericanGreetings.com 过去一样复杂，现在每个网站都需要该站点的扩展性和 HA 要求。
2. 运行大型的分布式系统是很困难的。（维护）周期，这是业务需求，不是 Kubernetes 的。使用更简单的协调器并不是解决方案。
Kubernetes绝对是满足复杂Web应用程序需求的最简单，最简单的方法。这是我们生活的时代，而 Kubernetes 擅长于此。你可以讨论是否应该自己构建或管理 Kubernetes。有很多供应商可以帮助你构建和管理它，但是很难否认这是大规模运行复杂 web 应用程序的最简单方法。
--------------------------------------------------------------------------------
via: https://opensource.com/article/19/10/kubernetes-complex-business-problem
作者：[Scott McCarty][a]
选题：[lujun9972][b]
译者：[laingke](https://github.com/laingke)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://opensource.com/users/fatherlinux
[b]: https://github.com/lujun9972
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/browser_web_internet_website.png?itok=g5B_Bw62 (Digital creative of a browser on the internet)
[2]: http://AmericanGreetings.com
[3]: http://BlueMountain.com
[4]: http://augeas.net/
[5]: https://linux.cn/article-11011-1.html
[6]: http://crunchtools.com/kubernetes-10-ton-dump-truck-handles-pretty-well-200-mph/
[7]: https://linux.cn/article-11036-1.html
[8]: https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html

96
translated/tech/20191029 Upgrading Fedora 30 to Fedora 31.md Normal file
View File

@ -0,0 +1,96 @@
[#]: collector: (lujun9972)
[#]: translator: (geekpi)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Upgrading Fedora 30 to Fedora 31)
[#]: via: (https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/)
[#]: author: (Ben Cotton https://fedoramagazine.org/author/bcotton/)
将 Fedora 30 升级到 Fedora 31
======
![][1]
Fedora 31 [目前发布了][2]。你也许想要升级系统来获得 Fedora 中的最新功能。Fedora 工作站有图形化的升级方式。另外，Fedora 提供了一种命令行方式来将 Fedora 30 升级到 Fedora 31。
### 将 Fedora 30 工作站升级到 Fedora 31
在发布不久之后，就会有通知告诉你有可用升级。你可以点击通知打开 **GNOME Software**。或者在 GNOME Shell 选择 Software。
在 GNOME Software 中选择_更新_，你应该会看到告诉你有 Fedora 31 更新的提示。
如果你在屏幕上看不到任何内容，请尝试使用左上方的重新加载按钮。在发布后，所有系统可能需要一段时间才能看到可用的升级。
选择_下载_以获取升级包。你可以继续工作，直到下载完成。然后使用 GNOME Software 重启系统并应用升级。升级需要时间，因此你可能需要喝杯咖啡，稍后再返回系统。
### 使用命令行
如果你是从 Fedora 以前的版本升级的，那么你可能对 _dnf upgrade_ 插件很熟悉。这是推荐且支持的从 Fedora 30 升级到 Fedora 31 的方法。使用此插件能让你轻松地升级到 Fedora 31。
#### 1\. 更新软件并备份系统
在开始升级之前，请确保你安装了 Fedora 30 的最新软件。如果你安装了模块化软件，这点尤为重要。dnf 和 GNOME Software 的最新版本对某些模块化流的升级过程进行了改进。要更新软件，请使用 _GNOME Software_ 或在终端中输入以下命令。
```
sudo dnf upgrade --refresh
```
此外，在继续操作之前，请确保备份系统。有关备份的帮助，请参阅 Fedora Magazine 上的[备份系列][3]。
#### 2\. 安装 DNF 插件
接下来，打开终端并输入以下命令安装插件：
```
sudo dnf install dnf-plugin-system-upgrade
```
#### 3\. 使用 DNF 开始更新
现在，你的系统是最新的，已经备份并且安装了 DNF 插件，你可以通过在终端中使用以下命令来开始升级：
```
sudo dnf system-upgrade download --releasever=31
```
该命令将开始在本地下载计算机的所有升级。如果由于缺乏更新包、损坏的依赖项或已淘汰的软件包而在升级时遇到问题，请在输入上面的命令时添加 _‐-allowerasing_ 标志。这将使 DNF 删除可能阻止系统升级的软件包。
#### 4\. 重启并升级
上面的命令下载更新完成后，你的系统就可以重启了。要将系统引导至升级过程，请在终端中输入以下命令：
```
sudo dnf system-upgrade reboot
```
此后，你的系统将重启。在许多版本之前，_fedup_ 工具会在内核选择/引导页面上创建一个新选项。使用 _dnf-plugin-system-upgrade_ 软件包，你的系统将重新引导到当前 Fedora 30 使用的内核。这很正常。在内核选择页面之后不久，你的系统会开始升级过程。
现在也许可以喝杯咖啡休息下！升级完成后，系统将重启，你将能够登录到新升级的 Fedora 31 系统。
![][4]
### 解决升级问题
有时，升级系统时可能会出现意外问题。如果遇到任何问题，请访问 [DNF 系统升级文档][5]，以获取有关故障排除的更多信息。
如果升级时遇到问题，并且系统上安装了第三方仓库，那么在升级时可能需要禁用这些仓库。对于 Fedora 不提供的仓库的支持，请联系仓库的提供者。
--------------------------------------------------------------------------------
via: https://fedoramagazine.org/upgrading-fedora-30-to-fedora-31/
作者：[Ben Cotton][a]
选题：[lujun9972][b]
译者：[geekpi](https://github.com/geekpi)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://fedoramagazine.org/author/bcotton/
[b]: https://github.com/lujun9972
[1]: https://fedoramagazine.org/wp-content/uploads/2019/10/f30-f31-816x345.jpg
[2]: https://fedoramagazine.org/announcing-fedora-31/
[3]: https://fedoramagazine.org/taking-smart-backups-duplicity/
[4]: https://cdn.fedoramagazine.org/wp-content/uploads/2016/06/Screenshot_f23-ws-upgrade-test_2016-06-10_110906-1024x768.png
[5]: https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/#Resolving_post-upgrade_issues