本文概述了关系和非关系数据库的区别，你还将了解如何根据它们的优缺点来决定哪一个更适合相应的项目。

我们将讨论：

• 数据库的定义
  • SQL 是什么?
• 关系型数据库
  • 特点
  • ACID 属性
• 非关系型数据库
  • 类型
  • BASE 属性
• 关系型数据库 VS 非关系型数据库
• 拓展阅读

什么是数据库？针对初学者的定义

在计算机里，数据是以不同形式出现的信息片段。它可以是文本、数字、图像、音频片段或视频。

信息集合需要被存储、处理和解释。这时就需要一种可按需轻松搜索、访问、提取和检索已保存资源的方法。该方法可以使计算机或人类分析可访问的数据、执行计算和比较、做出逻辑决策得出结论。

当然可以使用 Excel 电子表格等软件将数据存储在文件中，这样也可以完成有限的工作。

但是，如果数据量很大，使用 Excel 处理就捉襟见肘了。

在数据量增大时，Excel 无法快速检索。并且 Excel 很难固定其数据结构。

数据库是一种更易于访问、更高效且更有条理的长期存储和处理信息的方式。

数据库存储数据的规范性和系统性以及其检索数据的便捷性使其成为基于 Web 的应用程序中重要的部分。

数据库几乎可以用于所有应用程序。它们可以用来存储用户信息，例如用户名、电子邮件地址、加密密码和物理地址。

它们还存储用户行为。例如，在电商网站中，数据库会保存并跟踪“收藏”的商品。

一般使用数据库管理系统（或简称 DBMS）来管理数据库。

数据库管理系统是一个软件程序，充当最终用户和数据库中间的媒介。可以通过数据库管理系统创建和管理数据库。也可以执行查询来访问、修改和操作存储在数据库中的数据。

只需通过一些命令就可以方便轻松地存储、检索、更新和删除数据。

谈到数据库管理系统，通常有两种类型可供选择：

• 关系型数据库（也就是 SQL 数据库）
• 非关系型数据库（也就是 NoSQL 数据库）

SQL 是什么?

SQL 是 Structured Query Language 的缩写。

你可能会听过它以两种发音方式 - “S. Q. L.”（ess-kew-ell）或“se-quel”（/ˈsēkwəl/）。

无论哪种方式，SQL 都代表数据库处理的语言。

具体来说，使用 SQL，可以编写数据库查询以和数据库进行通信。查询可以是用于执行任何 CRUD（创建、读取、更新、删除）操作的命令。

SQL 是关系数据库管理系统的首选语言，将在下一节中详细介绍。

什么是关系数据库？

关系数据库（或 SQL 数据库）已经存在了一段时间。第一个关系数据库出现在 1970 年，关系数据库至今仍然很流行，一些最常见的如：

• PostgreSQL
• Microsoft SQL Server
• MySQL
• Oracle
• SQLite

关系数据库以结构化和表的方式存储数据。也就是说，它将信息存储在表中，可以将其视为数据的存储容器。例如，一家公司可以有一个 employees 表来存储其员工的数据。

关系数据库具有严格的、静态的预定义逻辑架构（schema）。可以将数据库架构视为一个组织蓝图——一组规则：哪些可以插入表、哪些不能插入表、以及如何设置数据。

在每个表中，至少有一个列（column）。这些列具有特定的数据类型，例如 INTEGER 或 VARCHAR。在 employees 表中，一些列可能是 employee_id、name、department、email 和 salary。

所有列和其数据类型构成架构。

             EMPLOYEES

+-------------+------+------------+-------+--------+
| employee_id | name | department | email | salary |
+-------------+------+------------+-------+--------+

一个表也会包含行（rows） 或 记录（records）。记录是遵守预定义架构的单个数据条目。本质上，它是一个数据项。

             EMPLOYEES
+-------------+------------------+------------+-----------------------+--------+
| employee_id |       name       | department |         email         | salary |
+-------------+------------------+------------+-----------------------+--------+
|           1 |  John Doe        | IT         | johndoe@company.com   |   3500 |
|           2 |  Kelly Kellinson | Marketing  | kelly@company.com     |   1500 |
|           3 |  Mike Manson     | Product    | mikekane@company.com  |   2300 |
+-------------+------------------+------------+-----------------------+--------+

由于关系数据库支持 SQL，所以可以直接执行查询。例如，如果想 view 月薪 greater than 2000 dollars 的 employees 的 names，那么可以编写如下 SQL 查询：

SELECT name FROM employees
WHERE salary > 2000;

执行上面的查询，会获得以下输出：

+-------------+
|    name     |
+-------------+
| John Doe    |
| Mike Manson |
+-------------+

关系数据库的特点

到目前为止，已经了解了关系数据库：

• 是表格格式
• 非常有条理，并且数据以某种结构存储
• 具有严格、预定义的架构
• 使用 SQL 执行数据库查询和操作数据

此外，一个关系数据库可以有多个表，正如数据库管理系统的名称所暗示的那样，这些表可以是相互关联的。

例如，一家电商公司可能有一个 products 表、一个 users 表、一个 emails 表和一个 orders 表。

由于表和存储在其中的信息之间存在连接和关联，可以使用命令来连接表。

关系数据库有一个主键，它作为标识符，确保表中的每一项都是唯一的，从而确保表中没有重复和冗余的数据。

外键 用于表示在表之间的关系。

不同表中的数据可以有不同的关系：

• 一对一的关系：在这种情况下，一个表中的记录仅与另一个表中的一条记录相关。电商网站中一对一关系的示例是，一个用户只能拥有一个电子邮件地址，且一个电子邮件地址只能属于一个用户。
• 一对多关系：在这种情况下，一张表中的一条记录与另一张表中的多条其他记录相关。例如，在电商网站中，一个用户可以下许多订单，但每个订单都是由一个用户下的。
• 多对多关系：在这种情况下，一个表中的一个或多个记录可以与另一个表中的一个或多个记录相关。例如，在电商网站中，一个订单可以有很多产品，而一个产品可以被购买多次。

关系数据库中的 ACID 属性

关系数据库提供 ACID 数据一致性模型。

ACID 是原子性（Atomicity）、一致性（Consistency）、事务隔离（Isolation）、持久性（Durability） 的首字母缩写词。

原子性意味着事务是原子的并且采取 “all or nothing” 的方法。

也就是，要么整个操作成功，从头到尾完成，要么不成功，整个操作“回滚”。

所有操作都保证以成功或失败结束，不存在部分成功。

一致性是确保数据库结构从事务开始到结束保持不变。一致性确保进入数据库的任何数据都遵循已设置的规则和约束。它可以保护和维护关系数据库中数据的完整性。

事务隔离意味着尽管在任何时候都发生了许多事务，但每个事务都被视为一个原子的、独立的单元，并且事务似乎是按顺序发生的。

例如，如果两个事务同时发生，此属性可确保一个事务以及那里发生的更改不会以任何方式影响另一个事务。

最后，持久性意味着事务的任何结果和更改都已提交，因此是永久性的，并且将持续存在，即使出现系统故障也是如此。

ACID 模型可确保数据库可靠且安全。

什么是非关系数据库？

非关系型数据库也称为 NoSQL 数据库。经常会看到 NoSQL 代表“Not only SQL”和“Non-SQL”。

无论哪种方式，非关系数据库都是指不使用关系数据模型的数据库。

尽管这个术语和这种类型的数据库已经存在了几十年，但 NoSQL 数据库在 1990 年代后期才开始受欢迎，当时 Internet 也变得越来越流行。

关系数据库已无法满足互联网海量且复杂的数据。

一些最流行的非关系数据库：

• MongoDB
• Redis
• Apache Cassandra
• Google Cloud Bigtable
• Amazon DynamoDB

非关系数据库不以表格式存储和组织数据。不同数据点之间没有表、行、列或关系。

相反，数据存储在集合中。数据库通常是非结构化的并使用动态架构。

非关系数据库的类型

有四种主要类型的非关系数据库：

• 列式数据库
• 键-值数据库
• 面向文档的数据库
• 图数据库

列式数据库在概念上类似于关系数据库，但它们使用组或列集（也称为列族）而不是行来逻辑组织相关数据。可以通过使用与单个列关联的唯一行键来独立访问列族。列式数据库搜索特定数据的速度很快，因为无需通过不相关的信息行来查找要搜索的内容。

键-值数据库是最简单的非关系数据库类型之一。数据以键值对集合的形式存储在字典或哈希表中。这种类型的数据库具有唯一的键。键充当指向特定值的指针并与该值相关联。分配给键的值可以是任何信息和数据类型。要检索和访问该值，请使用唯一键作为引用。

面向文档的数据库也以键值对的方式存储数据。但是其值是一个文档，它有一个唯一的键作为它的标识符。文档可以是任何格式，例如 XML、YAML 或二进制，通常采用 JSON 格式。这种类型的数据库以半结构化的方式存储数据。没有架构或预定义的结构。正因为如此，它更灵活，可以在项目需求发生变化时重新安排和重新设计数据库结构。它还提供了类似 SQL 的查询语言或者通过 API 来对数据执行查询以及 CRUD 操作。

图数据库是最复杂的非关系数据库类型，它们可以处理大量数据。图数据库专注于数据元素之间的连接和关系，并使用图论来存储、搜索和管理这些关系。图数据库使用 nodes 来存储数据，用 nodes 表示单个实体或数据。一个节点连接到另一个节点。为了表示实体之间的连接或关系，图数据库还用到了 edges。

非关系数据库中的 BASE 属性

非关系数据库提供 BASE 数据库一致性模型。该模型不像关系数据库的 ACID 模型那样严格。

BASE 是以下的首字母缩写词：

• Basic Availability 基本可用，该模型不关注数据的即时一致性。但是，该系统似乎在持续工作，并始终保证数据的可用性。
• Soft 软状态，由于缺乏即时一致性，系统的状态可能会随着时间而改变。软状态意味着系统不需要写一致性。
• Eventual 最终一致性，主要优先事项是数据的持续可用，而不是数据一致性。但是，最终在某个时候，可以期望数据是一致的。当系统停止接收输入时，可能会发生这种情况。

如何在 SQL 和 NoSQL 数据库之间进行选择

在学习了 SQL 和 NoSQL 数据库的基础知识之后，可能想知道如何为项目选择适合类型的数据库。

嗯，这个问题没有明确的答案。

两种数据库都有优点和缺点，这在很大程度上取决于正在构建的应用程序的类型、将使用的数据的类型以及的未来目标。

通常在产品中都会涉及到这两种类型的数据库。

以下是它们特征的快速摘要，可帮助决定哪一个可能更适合。

何时使用 SQL 数据库

• 需要分布在多个表中的高度结构化的数据，需要数据遵守严格的、可预测的、预定义的和已经计划好的模式。
• 数据将保持相对不变。如果不打算频繁更改数据库的结构并且不需要定期更新项目，SQL 数据库会很方便。请记住，它们提供的灵活性很小。
• 需要一致的数据。
• 数据完整性和安全性是重中之重。
• 需要复杂查询的准确结果。

SQL 数据库的一个缺点是它们是垂直扩展的。当存储变多时，需要增加当前机器上的硬件和提高计算能力。这可能代价高昂。需要增加处理能力和内存存储来处理增加的负载以提高性能。

何时使用 NoSQL 数据库

• 在一个快速的开发环境中工作，需要经常调整需求并不断更改数据库结构。
• 正在处理大量性质不同但不需要大量结构或准确性的数据。
• 正在处理需要频繁更新的数据。NoSQL 数据库提供了一个松散、灵活和动态的模式，允许对数据进行定期更改。
• 需要快速的查询结果和系统的持续可用性。
• 不想对数据库进行任何前期规划、准备或设计，而是想立即开始构建。

NoSQL 数据库的一大优势是它们可以水平扩展。

它们的设计方式可以将更多机器添加到现有机器（例如云服务器）中。与需要额外 CPU（中央处理单元）或 RAM（随机存取存储器）资源的垂直缩放相比，这种行为更可取。

但当然，NoSQL 数据库的一个缺点是它们不能确保数据的完整性和一致性。

拓展阅读

这篇文章只是触及了皮毛，最好的学习方法就是边做边学。

以下是一些学习资源，可用于了解有关数据库和 SQL 的更多信息：

• Learn SQL – Free Relational Database Courses for Beginners，为这篇文章添加书签以获取免费 SQL 课程列表。
• freeCodeCamp 关系数据库（Beta） 认证，在本课程中，你将学习到必要的开发人员工具，然后将学习如何使用代码编辑器、命令行和 Git，还将学习使用 PostgreSQL（一种关系数据库管理系统）和 SQL——它的查询语言。
• Learn About NoSQL Databases in This 3-hour Course，在本课程中，将了解四种不同的 NoSQL 数据库类型。除了理论之外，还有实战。

结语

你已经到了文章的结尾！

希望你了解了关系数据库和非关系数据库之间的主要区别。文末的额外的资源可以继续学习，将新技能付诸实践。

感谢你阅读本文，祝你编码愉快！

如果知道如何正确使用 Google，它就是世界上最强大的工具。让我们来看一下如何在谷歌搜索上做得更好。

1. 使用引号进行精确匹配搜索

可以使用引号来强制进行完全匹配搜索。如果确切知道要查找的搜索短语，这将非常有用。如果这样做，会只返回精确的结果。

"what is javascript"

2. 使用 AND 操作符

AND 操作符将仅返回与这两个术语都相关的结果。在下面的示例中，可以看到此操作符的用例。

html AND css

3. 使用 OR 操作符

可以使用 OR 操作符来获取与输入的搜索词任意一个相关的结果。

(javascript OR python) free course

4. 使用 -（减号）操作符

- 运算符将排除相关术语或短语的结果。在下面的例子中，想要获得与 JavaScript 相关的结果，但排除任何包含的 CSS 结果。

javascript -css

5. 使用 (*) 通配符作为占位符

可以使用 (*) 通配符作为占位符，它将被任何单词或短语替换。

这个是我的最爱。当我大概知道整个搜索短语并用星号替换我不知道的部分时，我会使用它。 超级好用。

"how to start * in 6 months"

6. 如何在指定网站内搜索

这也是我经常使用的方式。如果我只想在指定网站上搜索某些内容，我会这样做。

site:freecodecamp.org

7. 如何查找特定文件类型

还可以使用这个非常有用的功能来帮助找到特定的文件类型。如果正在寻找诸如 PDF 之类的材料，它会很方便。如果以前没有使用过它，那么从现在开始使用它吧。

filetype:pdf learn css

8. 如何搜索一个范围内的数字

这可以是任何东西。如果想购买特定价格区间的商品，或者正在搜索包含特定年份范围的结果，那么这很好用。

ecmascript 2016..2018

9. 使用 before 操作符

使用 before 操作符可以只返回给定日期之前的结果。

必须提供年-月-日格式的日期或仅提供年，例如：

javascript before:2020

10. 使用 after 操作符

使用 after 操作符仅返回给定日期之后的结果。必须提供年-月-日格式日期或仅提供年。如果想排除过时的结果，则非常有用。

web development after:2020

如你所见，如果知道如何正确使用它，Google 可以成为一个强大的工具。

如果有任何问题，可以在 Twitter 上与我联系。

也可以在我的 博客 上找到大量实际工作中用到的技巧和资源。

在本文中，我们将讨论 get、put 和 post HTTP 方法，介绍每种 HTTP 方法的用途以及使用场景。

为了深入了解 HTTP 方法的工作原理，本文还将介绍 HTTP 有关上下文和背景信息。

这篇文章讲要介绍的主题：

• HTTP 协议
• 客户端-服务器架构
• APIs

读完本文，将对每个请求方法的定位有一个很好的了解。还将具备发起请求和使用 Web API 的经验。

什么是 HTTP？

HTTP 是一种协议，或一组明确的规则，用于访问网络上的资源。资源可以是任何东西，从 HTML 文件到数据库中的数据、照片、文本等等。

通过 HTTP 协议向这些 API 发出请求，然后返回相应的资源。API代表应用程序编程接口。它是开发人员请求资源的机制。

客户端-服务器架构

学习 HTTP 方法前，理解客户端/服务器架构的概念很重要。该架构描述了 Web 应用程序的工作方式，并定义了通信的规则。

客户端是用户实际与之交互的应用程序，它展示所需的内容。服务器是将内容或资源发送到客户端的应用程序。服务器在某处持续运行等待客户端的请求。

这种分离的主要原因是为了保护敏感信息。如果整个应用程序都被下载到浏览器中，任何访问网页的人都可以访问所有数据。

这种架构有助于保护 API 密钥、个人数据等。现在，Next.js 和 Netlify 等流行工具允许开发人员在与其客户端程序中运行服务器代码， 无需部署到专用的服务器上。

客户端-服务器通信

客户端和服务器根据需要每次单独发送消息进行通信，而不是持续的流通信。

这些通信几乎总是由客户端以请求的形式发起。这些请求由服务器应用程序完成，返回包含请求的资源的响应。

为什么我们需要服务器-客户端架构？

假设正在构建一个网络天气应用。用户要与之交互的是客户端程序——它有按钮、搜索栏，并显示城市名称、当前温度、AQI 等数据。

天气应用不会将每个城市及其天气信息直接硬编码到程序中。这会使应用程序变得臃肿而缓慢，检索数据添加到数据库需要花费很长时间，而且每天的更新的也很让人头疼。

相反，该应用程序可以使用 Weather Web API 按城市访问天气数据。应用程序会收集用户的位置，然后向服务器发出请求，说：“嘿，把这个城市的天气信息发给我。”

根据要实现的目标，将使用不同的请求方法。服务器返回一个包含天气信息等内容的响应，具体取决于 API 的设计。它还可能会返回时间戳、该城市所在的区域等信息。

客户端与运行在某处的服务器进行通信，服务器的工作就是不断地到监听是否有到该地址的请求。当它接收到请求时，它会基于传入的参数从数据库或者另一个 API 或者本地文件查询返回符合要求的响应。

HTTP 请求剖析

HTTP 请求必须具有以下内容：

• HTTP 方法（如 GET）
• 主机 URL（如https://api.spotify.com/）
• 端点路径（如 v1/artists/{id}/related-artists）

请求还可选包含：

• Body 请求体
• Headers
• 查询字符串
• HTTP 版本号

HTTP 响应剖析

响应必须具有以下内容：

• 协议版本（如HTTP/1.1）
• 状态码（如 200）
• 状态文本（OK）
• Headers

响应还可选具有：

• Body 响应体

HTTP 方法解释

Post Malone 意味着 Get、Put、Patch 和 Delete Malone 的存在。

— Paul Ford (@ftrain) November 15, 2019

现在我们知道了什么是 HTTP 以及为什么需要它，让我们来聊聊这些不同的 HTTP 方法。

在上面的天气应用程序示例中，我们想要检索某城市的天气信息。但是如果我们想提交一个城市的天气信息该如何请求呢？

在现实生活中，可能无权更改其他人的数据，但假设我们是社区运行的天气应用程序的贡献者。除了从 API 获取天气信息外，该城市的成员还可以更新此信息以显示更准确的数据。

或者，如果我们想完全添加一个由于某种原因在我们的城市数据库中不存在的新城市怎么办？ 这些是不同的功能——检索数据、更新数据、创建新数据——所有这些都有对应的 HTTP 方法。

HTTP POST 请求

POST 用来创建一个新资源。POST 请求需要一个请求体，可以在其中定义要创建的实体数据。

POST 请求成功返回的状态码是 200。在天气应用中，可以使用 POST 方法来添加新城市。

HTTP GET 请求

GET 用来读取或检索资源。 GET 成功后会返回包含所请求信息的响应。

在天气应用中，可以使用 GET 来检索某城市当前的天气。

HTTP PUT 请求

PUT 用来修改资源。PUT 用请求体 payload 中的数据替换整个资源。如果没有与请求体唯一标识相匹配的资源，它将创建一个新资源。

在天气应用中，可以使用 PUT 来更新指定城市的所有天气数据。

HTTP PATCH 请求

PATCH 用来修改资源的部分字段。使用 PATCH，只需要传入想要更新的字段即可。

在天气应用中，可以使用 PATCH 来更新指定城市指定日期的降雨量。

HTTP 删除请求

DELETE 可以用来删除资源。在天气应用中，可以使用 DELETE 删除出于某种原因不再想跟踪的城市。

HTTP Methods 常见问题解答

PUT 和 POST 有什么区别？

PUT 请求是幂等的，这意味着执行相同的 PUT 请求将始终产生相同的结果。

另一方面，POST 会产生不同的结果。如果多次执行 POST 请求，将多次创建新资源，尽管传入的是相同的数据。

使用餐厅类比，多次 POST 会创建多个独立的订单，而多次 PUT 请求将更新现有的订单。

PUT 和 PATCH 有什么区别？

主要区别在于，如果 PUT 找不到指定的资源，它将创建一个新资源。而使用 PUT 时，需要传入改数据的全部资源，即使只想修改一个字段。

使用 PATCH，可以只传入要更新字段更新资源。

如果我只想更新我的部分资源怎么办？我还能使用 PUT 吗？

如果只想更新部分资源，则在发出 PUT 请求时仍需要发送整个资源的数据。这里更适合的选项是 PATCH。

为什么请求和响应的 body 是可选的？

body 是可选的，因为对于某些请求，例如使用 GET 方法检索资源，请求正文中无需指定任何内容。可以从指定端点检索所有数据。

类似地，当状态码足够或正文中没有要返回的内容时，某些响应的主体是可选的，如 DELETE 操作。

HTTP 请求示例

现在已经介绍了什么是 HTTP 请求，以及它们的使用场景，让我们发起一些请求！这里将使用 GitHub Gist API。

“Gist 是一种与他人共享代码段的简单方法。所有 Gist 都是 Git 仓库，因此可以使用 Git 的版本控制，fork 等功能。” （来源：GitHub）

为此，需要一个 GitHub 帐户。如果还没有，这是一个很好的时机来创建一个以在将来保存代码。

GitHub 上的每个用户都可以创建 gist、检索他们的 gist、检索所有公共 gist、删除 gist 和更新 gist，等等。为了简单起见，我们将使用 Hoppscotch，这是一个可以方便地发起 HTTP 请求的一个可视化平台。

快速上手 Hoppscotch：

• 有一个下拉菜单，可以在其中选择要用来创建请求的 method。
• 有一个文本框，可以在其中粘贴要访问的 API 端点的 URL。

• 有一个 Headers 部分，我们将按照 GitHub 文档的说明在其中传递请求头。

• 有一个 body 区域，可以按照 GitHub 文档的指示将相应的请求实体写入 body。

• 如果请求成功，右栏会显示通知。如果它是绿色的，表示成功发起了请求，如果它是红色的，代表有错误。

如何发出 GET 请求

要创建 GET 请求以检索所有特定用户的 gists，可以使用以下方法和端点：GET /users/{username}/gists。按照文档可以通过 endpoint 传入指定的参数来发起请求。

可以看到在路径中需要传入一个带有目标用户用户名的字符串。还需要传入一个名为 accept 的 headers 并将其设置为 application/vnd.github.v3+json。

API 的 URL 为：

https://api.github.com

此特定操作的端点路径为：

/users/{username}/gists

要发起此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。请务必将 “username” 替换为实际用户名。如果还没有创建过 Gists 的 GitHub 账号，可以先使用我的：camiinthisthang。
2. 选择GET请求方法
3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json

4. 点击发送！

在底部，会看到格式为 JSON 的响应。为了便于阅读，复制响应并将其粘贴到 在线 JSON 格式化程序。

在格式化程序中，可以知道响应是一个对象数组。每个对象代表一个 gist，向我们展示 URL、ID 等信息。

如何发出 POST 请求

现在来使用 POST 方法创建一个资源。在这种情况下，新资源将是一个新的 gist。

首先，需要创建一个个人 access token。为此，转到设置页面并点击生成令牌。

命名 token 并选择 scope “Create Gists”：

然后单击页面底部的绿色 Generate token 按钮。

复制 access 代码并将其粘贴到合适的位置。

现在准备好发起的请求了！根据文档应该在 body 中传递一个 headers 和一个 files 对象。可选传入一些其他参数，包括一个布尔值，它代表这个 gist 是公共的还是私有的。

API 的 URL 如下：

https://api.github.com

此操作的端点路径如下：

/gists

要发起此请求：

1. 将完整的 URL + 路径粘贴到 Hoppscotch 的输入字段中。

2. 选择POST请求方法

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json

4. 在 Body 选项卡中，将内容类型设置为 application/json。然后从一个对象{}开始。

   在这个对象内部，将 public boolean 设置为 true。然后将定义属性 files，其值是另一个对象，其键名是新 gist 名称。值应该是另一个其键为 content 的对象。这里的值应该是想要实际添加到要点中的任何值。

   可以复制/粘贴以下代码：

{
  "public": true, 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!!"
    }
  }
}

5. 在 Authorization 选项卡中，将授权类型设置为 Basic Auth。输入 GitHub 用户名并传入在密码字段中创建的个人访问令牌。

在执行这个之后，会得到一个很长的响应。检查 gist 是否已创建的一种简单方法是访问 GitHub 中的 Gist。

可以看到成功添加了一个 Gist！

如何创建 PATCH 请求

来更新刚刚创建的 Gist 的标题和描述。请记住：PATCH 允许更新资源的一部分，而不是整个资源。我们没有传入的任何内容都将保持不变。

在创建 Gist 时实际上并没有提供描述，因此我们可以使用 patch 创建一个。

API 的 URL：

https://api.github.com

此特定操作的端点路径如下：

/gists/{gist_id}

要创建此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。获取要更新的 gist 的 Gist ID。可以通过转到 GitHub 中的 Gist 并复制 URL 末尾的字母数字字符串来找到 ID。

2. 选择 PATCH 请求方法。

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json。

4. 在 Authorization 选项卡中，将授权类型设置为 Basic Auth。输入 GitHub 用户名并传递我们在密码字段中创建的个人 access token。

5. 在 Body 选项卡中，传入更新后的描述和标题。代码如下：

{
  "description": "Adding a description via the API", 
  "files": {
    "postgist.txt": {
      "content": "Adding a GIST via the API!! -- adding this line at the end to make the content slightly longer"
    }
  }
}

刷新 Gist，会看到标题和描述已经更新！

如何发起 DELETE 请求

要删除创建的 Gist。应该传入 header 和 Gist ID。

API 的 URL 如下：

https://api.github.com

此特定操作的端点路径如下：

/gists/{gist_id}

要创建此请求：

1. 在 Hoppscotch 的输入字段中粘贴完整的 URL + 路径。获取要更新的 gist 的 Gist ID 。可以通过转到 GitHub 中的 Gist 并复制 URL 末尾的字母数字字符串来找到 ID。

2. 选择 DELETE 请求方法

3. 在 Headers 选项卡中，将 accept 设置为 header 并将值设置为 application/vnd.github.v3+json。

导航到 Gists，会看到已经成功地删除了该资源。

如何在程序中发起请求

使用 Hoppscotch 是因为它可以方便的发起请求，而无需启动程序或下载任何内容。

如果想在 JavaScript/React 应用程序中发出请求，可以使用 Javascript fetch 或 Axios。

有关如何发起使用 HTTP 请求方法和 API 的简单应用程序的步骤演示，可以查看我在 youtube 上的视频，我们在其中创建了一个 Web 应用程序，该应用程序通过 API 显示有关所有国家/地区的信息 .

你做到了！

如果你正在阅读本文，请继续给自己点赞，因为你已经了解了 Web API、HTTP 协议、客户端-服务器架构——并且还发起了第一个请求。

如果你喜欢我的风格，可以在 YouTube、[Tik Tok](https:// www.tiktok.com/@camiinthisthang?)、Twitter 和 Hashnode 找到我。还可以通过 我的个人网站 找到代码片段和联系我的方式。

开始阅读之前。如果你对视频形式免费内容感兴趣。不要错过我的 Youtube 频道，我每周都会发布前端相关的视频。

https://www.youtube.com/user/Weibenfalk

----------

你也是 Web 开发和 CSS 的初学者吗？有没有好奇过网页上那些漂亮的图形是如何用 CSS 搞定的？没错，你来对地方了。

下面我将解释使用 CSS 创建图形的基础知识。这个话题很宏大！因此，我不会涵盖所有（远非全部）方法和图形，本文的目的是让你对如何使用 CSS 创建图形有一个基本的了解。

有些图形比常规图形需要更多的技巧。通常我们使用 width、height、top、right、left、border、bottom、transform 以及 :before 和 :after 等伪元素的组合来创建 CSS 图形。我们也可以使用更流行的 CSS 属性来创建图形，比如 shape-outside 和 clip-path。 下面我会一一介绍。

CSS 图形——基本方式

通过一些 CSS 技巧可以创建基本图形，例如正方形、圆形以及用常规 CSS 创建的三角形。接下来我们具体看一看。

正方形和长方形

正方形和长方形是最容易实现的图形。默认情况下，div 就是正方形或长方形。

设置宽度和高度，设置一个背景颜色，如下所示：

#square {
    background: lightblue;
    width: 100px;
    height: 100px;
}

圆形

创建一个圆形也很简单。在元素上设置 border-radius。这将在元素上创建圆角。

如果将其设置为 50%，将会变成一个圆形。如果宽度和高度不相等，将得到一个椭圆形。

#circle {
    background: lightblue;
    border-radius: 50%;
    width: 100px;
    height: 100px;
}

三角形

三角形有点棘手。元素边框的端点相交形成 45 度夹角。如果将元素的宽度和高度设置为零，元素的实际宽度也就是边框的总宽度。

别忘了，元素上的边框边缘组成了元素的对角线。可以用这个思路来创建三角形。将其中一个边框设置为纯色，将其他边框设置为透明色，就形成了一个三角形。

#triangle {
    width: 0;
    height: 0;
    border-left: 40px solid transparent;
    border-right: 40px solid transparent;
    border-bottom: 80px solid lightblue;
}

如果想让三角形指向另一个方向，可以更改与希望可见的一侧相对应的边框值。另外可以直接使用 transform 属性旋转元素。

 #triangle {
     width: 0;
     height: 0;
     border-top: 40px solid transparent;
     border-right: 80px solid lightblue;
     border-bottom: 40px solid transparent;
 }

以上就是对 CSS 基本图形的介绍。如果你想创建其它图形，你可以利用这些基础图形，发挥你的创造力和决心，通过基本的 CSS 属性实现更多图形。

在某些情况下，对于更高级的形状，使用 :after 和 :before 伪选择器也是一个不错的选择。但这超出了本文的范围，因为我的目的是介绍基础知识帮助你入门。

弊端

上述方法有一个很大的缺点。 例如，如果希望文本环绕图形展示，通过常规 HTML div 的背景和边框构成的图形无法做到这点。文本并不会自适应常规 div 元素环绕其展示。它和常规的 div 展示方式相同。

下图展示了三角形以及文本的布局方式。

幸运的是，我们可以利用一些现代 CSS 属性来轻松地做到这一点。

CSS 图形——另一种方式

在 CSS 中有一个叫做 shape-outside 的属性。此属性可以使文本环绕图形展示。

对于这个属性，有一些基本的形状：

inset()
circle()
ellipse()
polygon()

提示：还可以使用 clip-path 属性，用同样的方式创建图形，但它不会像 shape-outside 那样让文本环绕图形。

要使用 shape-outside 属性使文字环绕图形，图形元素必须是浮动的，它还必须具有指定的的宽度和高度。 这一点很重要！

可以在 此处 阅读更多。下面是从 developer.mozilla.org 链接中摘抄的文本。

**shape-outside**的 CSS 属性定义了一个可以是非矩形的形状，相邻的内联内容应围绕该形状进行包装。

inset()

inset() 类型可以创建能设置偏移量的矩形/正方形，用于文本环绕。它提供了设置环绕文本与图形重叠距离的值。

可以将所有四个方向的偏移量指定为相同值，如：inset(20px)。也可以为每个方向单独设置：inset(20px 5px 30px 10px)。

偏移量还可以使用其他单位，例如百分比。这些值对应为： inset(top right bottom left).

如下面的代码示例，将 inset 值指定为顶部 20px、右侧 5px、底部 30px 和左侧 10px。如果想让文本不和正方形重叠，可以不使用 inset()，而是在 div 上设置背景并像往常一样指定大小。

 #square {
     float: left;
     width: 100px;
     height: 100px;
     shape-outside: inset(20px 5px 30px 10px);
     background: lightblue;
 }

也可以给 inset() 第二个值，指定图形的的 border-radius，如下所示：

 #square {
     float: left;
     width: 100px;
     height: 100px;
     shape-outside: inset(20px 5px 30px 10px round 50px);
     background: lightblue;
 }

circle()

在这里，使用 shape-outside 属性创建了一个圆形，还需要给 clip-path 设置相应的值才能够显示。

clip-path 属性可以采用与 shape-outside 属性相同的值，因此可以将它设置为 shape-outside 的 circle()。另外，请注意，在此处的元素上应用了 20px 的边距，以便为文本留出一些空间。

#circle {
    float: left;
    width: 300px;
    height: 300px;
    margin: 20px;
    shape-outside: circle();
    clip-path: circle();
    background: lightblue;
}

在上面的例子中，没有指定圆的半径。这是因为我希望它与 div 一样大（300px）。如果想为圆指定不同的大小，可以这样手动设置。

circle() 有两个值，第一个值是 radius，第二个值是 position。这些值将确定圆的中心。

在下面的示例中，将 radius 设置为 50%，将圆心移动了 30%。请注意，必须在 radius 值和 position 值之间使用 “at” 一词。

我还在 clip-path 上指定了另一个 position 值。当我将 position 设置为零时，这会将圆形裁成两半。

 #circle {
      float: left;
      width: 150px;
      height: 150px;
      margin: 20px;
      shape-outside: circle(50% at 30%);
      clip-path: circle(50% at 0%);
      background: lightblue;
    }

ellipse()

椭圆形与圆形类似。可以同时定义 X 值和 Y 值，如：ellipse(25px 50px)。

和圆一样，也可以加一个 position 值作为最后一个值。

   #ellipse {
      float: left;
      width: 150px;
      height: 150px;
      margin: 20px;
      shape-outside: ellipse(20% 50%);
      clip-path: ellipse(20% 50%);
      background: lightblue;
    }

polygon()

多边形是定义了不同顶点/坐标的形状。下面创建了一个 T 形，这是我名字中的第一个字母。从坐标 0,0 开始，从左向右移动以创建 T 形。

#polygon {
      float: left;
      width: 150px;
      height: 150px;
      margin: 0 20px;
      shape-outside: polygon(
        0 0,
        100% 0,
        100% 20%,
        60% 20%,
        60% 100%,
        40% 100%,
        40% 20%,
        0 20%
      );
      clip-path: polygon(
        0 0,
        100% 0,
        100% 20%,
        60% 20%,
        60% 100%,
        40% 100%,
        40% 20%,
        0 20%
      );
      background: lightblue;
    }

Images 图片

还可以使用具有透明背景的图像来创建形状，就像下面这轮美轮美奂的月亮。

这是透明背景的 .png 图像。

<img src="src/moon.png" id="moon" />

#moon {
      float: left;
      width: 150px;
      height: 150px;
      shape-outside: url("./src/moon.png");
    }

就是这些啦，感谢你阅读本文。

关于本文作者

我叫 Thomas Weibenfalk，是来自瑞典的开发者。我经常在 Youtube 频道上创建免费教程，有一些关于 React 和 Gatsby 的高级课程。你可以通过以下链接找到我：

Twitter — @weibenfalk
Weibenfalk on Youtube
Weibenfalk Courses Website

如果问开发人员 Linux 是什么，大多数人的回答可能是 Linux 是一个开源操作系统。也有人会站在技术角度称它为内核。

不过，对我来说，Linux 不仅仅是一个操作系统或内核。Linux 代表着自由。可以根据需求自由组合各个部分组成最适合自己的操作系统，这也是 Arch Linux 吸引人的地方。

摘自 arch wiki,

Arch Linux 是通用 x86-64 GNU/Linux 发行版。Arch采用滚动升级模式，尽全力提供最新的稳定版软件。

初始安装的 Arch 只是一个基本系统，随后用户可以根据自己的喜好安装需要的软件并配置成符合自己理想的系统.

换句话说，Arch Linux 是针对有经验 Linux 用户的基于 x86-64 架构的优化发行版。它让你对系统拥有完全的选择权和控制权。

可以自主选择所需要的软件包、内核（是的，内核有很多）、boot-loader、桌面环境等等。

你有没有听过有人说，

嗯——顺便说一句，我用的是 Arch Linux！

这是因为如果想要在机器上安装 Arch Linux，需要先了解 Linux 发行版的每个部分是如何工作的。所以如果使用的是 Arch Linux，证明已经很熟悉 Linux。

安装 Arch Linux 与安装 Fedora 或 Ubuntu 之类的系统并没有太大不同。区别是 Arch Linux 必须手动完成各个步骤，而不是交给安装程序。完成了这个过程，自然了解了其他发行版的安装步骤。

在本文中，将介绍在电脑上安装和配置 Arch Linux 的整个过程。最后，还会讨论一些常见任务操作和故障排除技巧。

跟我来，带你深入浅出了解 Arch Linux。

目录

• 一些预设
• 如何创建可引导的 Arch Linux U 盘
• 准备安装 Arch Linux
• 如何安装 Arch Linux
  • 如何设置控制台键盘布局和字体
  • 如何验证引导模式
  • 如何连接到互联网
  • 如何更新系统时钟
  • 如何对磁盘进行分区
  • 如何格式化分区
  • 如何挂载文件系统
  • 如何配置镜像源
  • 如何安装 Arch Linux 基础系统
• 如何配置 Arch Linux
  • 如何生成 Fstab 文件
  • 如何使用 Arch-Chroot 登录新安装的系统
  • 如何配置时区
  • 如何配置本地化
  • 如何配置网络
  • 如何设置 root 密码
  • 如何创建非 root 用户
  • 如何安装 Microcode
  • 如何安装和配置 Boot Loader
• 如何安装 Xorg
• 如何安装图形驱动程序
• 如何安装桌面环境
  • 如何安装 GNOME 桌面
  • 如何安装 Plasma 桌面
• 如何完成安装
• 如何在桌面环境之间切换
• 使用 Pacman 管理包
  • 如何使用 Pacman 安装软件包
  • 如何使用 Pacman 删除软件包
  • 如何使用 Pacman 升级软件包
  • 如何使用 Pacman 搜索软件包
• 如何在 Arch Linux 使用 AUR
  • 如何使用 Helper 安装软件包
  • 如何手动安装软件包
• 如何解决常见问题
• 如何使用 Live Arch ISO 作为恢复媒介
• 拓展阅读
• 结论

一些预设

在进入本教程的核心之前，先澄清一些事情。为了使本文通俗易懂，我对你和你的系统做了以下假设：

• 对 Arch Linux 有基本的了解
  • Arch Linux
  • 常见问题
  • Arch 与其他发行版的比较
• 你的电脑使用的是 UEFI，而不是 BIOS
• 你有一个足够大（4GB）的 U 盘，可以用它来启动 Linux
• 有安装 Linux（Ubuntu/Fedora）的经验
• 有足够的空间在硬盘或 SSD上安装 linux

差不多就是这样。如果你具备以上所有条件，可以开始了。

如何创建可引导的 Arch Linux U 盘

要下载 Arch Linux，请访问 https://archlinux.org/download/ 并下载最新版本（本文撰写时为 2022.01.01）。ISO的大小应该在 870 兆字节左右。

下载后，需要将其写入 U 盘。可以使用 Fedora Media Writer。在系统上下载并安装应用程序。连接 U 盘打开应用程序：

单击“自定义镜像”，并使用文件浏览器选择下载的 Arch Linux ISO 文件。

程序现在可以选择一个连接的 U 盘。如果电脑连接了多个 USB 存储设备，请务必小心选择正确的 U 盘。现在点击“写入磁盘”按钮，等待进程完成。

准备安装 Arch Linux

在此步骤中，必须对系统进行一些更改，否则 Arch Linux 可能无法启动或正常运行。

第一个要改的是禁用 UEFI 配置中的安全启动。此功能有助于启动期间防止恶意软件攻击，但也会阻止 Arch Linux 安装程序的启动。

如何禁用此功能的详细说明因主板或笔记本电脑品牌而异。需要你自己在互联网中搜索来找到相应的方法。

第二个操作仅在安装和 Windows 共存的 Arch Linux 双系统时才适用。Windows有一个名为“快速启动”的功能，它通过部分休眠来缩短计算机的启动时间。

通常这是一个很好的特性，它可以防止双引导配置中的任何其他操作系统在此过程中访问硬盘。

要禁用此功能，请打开“开始”菜单并搜索“选择电源计划”，如下所示：

然后在下一个窗口中，单击左侧边栏中的“选择电源按钮的功能”：

然后在下一个窗口中，将看到“关机设置”列表，“启用快速启动（推荐）”选项应显示为只读。

单击顶部的“更改当前不可用的设置”，然后更改设置。

取消勾选“启用快速启动（推荐）”选项，然后按下底部的“保存修改”按钮。从现在开始，启动过程可能需要一些额外的时间，但这一切都是值得的。

在本文中，我将安装 Arch Linux 作为默认操作系统。所以我将把我的整个磁盘空间分配给它。

如果想让 Arch Linux 和 Windows 并存，这里有一篇专门的文章介绍这个话题。在那篇文章中，有一个章节，详细讨论了分区过程。

如何安装 Arch Linux

假设已经准备好可启动的 U 盘并且计算机配置正确，就可以开始从 U 盘启动了。开启从 U 盘启动的方法因机器而异。

在我的机器上，在启动过程中按 F12 键会将会进入到可启动设备列表。从那里可以选择可启动 U 盘。可能你已经知道适合你的电脑的方式，或者可能需要进行一些研究。

进入所有的可启动设备列表，选择要启动的 U 盘，会显示以下菜单：

从列表中选择第一个并等待 Arch 安装程序完成启动。完全启动后，会看到如下内容：

就这样。与你熟悉的其他操作系统不同，Arch 安装程序没有任何可以自动安装的图形用户界面。

它需要你投入时间和精力并逐个配置每个部分。这听起来可能有点难，但老实说，如果弄清楚每一步，安装 Arch Linux 会很有趣。

如何设置控制台键盘布局和字体

正如我已经说过的，Arch 安装程序没有图形用户界面，因此需要输入大量指令。配置键盘布局和漂亮的字体可以使安装过程不那么令人沮丧。

默认情况下，控制台是标准的美式键盘布局。这对大多数人来说应该没问题，但如果碰巧你有一个不同的键盘，可以改变它。

所有可用的键盘映射通常以 map.gz 文件的形式保存在 /usr/share/kbd/keymaps 目录中。可以使用 ls 命令查看列表：

ls /usr/share/kbd/keymaps/**/*.map.gz

这将列出所有可用的键盘映射：

假如你的是 Mac-US 键盘布局，从该列表中找到相应的 map.gz 文件，即 mac-us.map.gz 文件。

可以使用 loadkeys 命令加载所需的键盘映射。要将 mac-us.map.gz 设置为默认值，请执行以下命令：

loadkeys mac-us

如果不喜欢默认字体，也可以更改控制台字体。就像键盘映射一样，控制台字体保存在 /usr/share/kbd/consolefonts 中，可以使用 ls 命令列出：

ls /usr/share/kbd/consolefonts

这将列出所有可用的字体：

可以使用 setfont 命令设置。例如，如果要将 drdos8x16 设置为默认值，请执行以下命令：

setfont drdos8x16

loadkeys 和 setfont 命令都是包含基本 Linux 键盘工具的 kbd 包的一部分。他们都有很棒的 文档，所以如果想了解更多信息，请随时查看。

如何验证引导模式

现在已配置好控制台，下一步是确保已在 UEFI 模式下启动，而不是在 BIOS 模式下启动。

老实说，这一步对我来说似乎没有必要，因为它在实时启动菜单中字面意思是“x86_64 UEFI”。但是官方的 Arch 安装指南建议我们验证一下。

要验证引导模式，请执行以下命令：

ls /sys/firmware/efi/efivars

如果你处于 UEFI 模式，它会在你的屏幕上列出一堆文件：

在 BIOS 引导的情况下，/sys/firmware 目录中甚至不存在efi 目录。如果处于 UEFI 模式，（如果正确地遵循了一切，应该是）继续下一步。

如何连接到互联网

与许多其他实时发行版不同，Arch 实时环境并没有内置所有必要的软件包。它包含许多可用于安装系统其余部分的最低限度的软件包。所以，一个有效的互联网连接是必须的。

如果使用的是有线网络，那么从一开始应该就有了有效的互联网连接。要对其进行测试，请 ping 任何公共地址：

我正在使用 VirtualBox 制作这些屏幕截图，因此已经通过有线连接连接了互联网。但如果使用的是无线连接，事情会变得有点棘手。

实时环境带有 iwd 或 iNet wireless daemon 包。可以使用此软件包连接到附近的无线网络。

首先，执行以下命令：

iwctl

这将启动一个交互式提示，如下所示：

现在执行以下命令以查看可用无线设备的列表：

device list

这将打印出所有可用的无线设备列表。无线设备是指连接到你计算机的任何无线适配器。这里假设设备名称是 wlan0 。

要使用找到的设备扫描附近的无线网络，请执行以下命令

station wlan0 scan

你可能认为此命令将打印出所有附近网络的列表，但事实并非如此。要查看网络列表，请执行以下命令：

station wlan0 get-networks

现在假设你的 WI-FI 网络名称为“Skynet”，可以通过执行以下命令连接到它：

station wlan0 connect Skynet

iwctl 程序会提示输入 wi-fi 密码。输入密码，一旦连接到网络，输入exit 按 Enter 退出程序。再次尝试 ping 公共地址并确保 Internet 工作正常。

如何更新系统时钟

在 Linux 中，NTP 或网络时间协议用于通过网络同步计算机系统时钟。可以使用 timedatectl 命令在 Arch 实时环境中启用 NTP：

timedatectl set-ntp true

该命令将会卡住几秒。如果没有看到命令光标再次出现，请尝试按 Enter。过去我曾多次遇到过这种情况。

如何对磁盘进行分区

这可能是整个安装过程中最危险的一步——因为如果弄乱了分区，数据就会丢失。所以我建议不要立即执行本节内容。相反，请先阅读整个部分，然后再回到这里。

要开始分区，必须了解连接到计算机的磁盘。可以使用 fdisk，它是一个对话驱动的程序，用于创建和操作分区表。

fdisk -l

此命令将列出计算机上所有可用设备的分区表。

如你所见，有两个设备连接到我的计算机上（实际上是虚拟机）。根据你的设备数量，此列表可能会更长，在查看列表时忽略任何以rom、loop 或 airoot 结尾的设备。不能使用这些设备进行安装。

所以只剩下了 /dev/sda 设备。记住，在你的机器上可能完全不同。例如，如果你有 NVME 驱动器，可能会看到 /dev/nvme0n1。

一旦决定使用哪个设备，最好检查该设备内是否存在任何现有分区。可以使用 fdisk 命令：

fdisk /dev/sda -l

记得用你的设备名的替换/dev/sda。此命令将列出给定设备内的所有分区。

尽管此设备中没有分区，但在实际中，之前可能已经创建了分区。这些分区将显示为 /dev/sda1、/dev/sda2 或在有 NVME 驱动器的情况下显示为 /dev/nvme0n1p1、/dev/nvme0n1p2 等等。

fdisk 程序可以做的不仅仅是列出分区。查阅 相应的 ArchWiki 页面 以了解可以使用该程序执行的操作。

还有另一个程序 cfdisk，它是一个基于 curses- (programming library) 的 Linux 磁盘分区表操作工具。在功能上与 fdisk 相似，基于 curses 意味着它有一个界面，更易于使用。

执行以下命令在设备上启动 cfdisk：

cfdisk /dev/sda

记得用你的设备替换/dev/sda。如果设备有以前创建的分区表，那么 cfdisk 将直接显示分区列表。否则，将开始选择分区表类型：

为基于 UEFI 的系统选择 gpt。接下来，将显示设备上的分区和可用空间列表：

可以使用向上/向下箭头键沿设备列表上下移动，使用向左/向右箭头键沿不同操作左右移动。

要安装 Arch 或任何其他 Linux 发行版，需要三个独立的分区。如下：

• EFI 系统分区——用于存储 UEFI 固件所需的文件。
• ROOT – 用于安装发行版本身。
• SWAP – 用作内存交换分区。

确保正确的分区/可用空间在列表中突出显示，然后选择 [ New ] 操作。

填写所需的分区大小。可以使用 M 表示兆字节，G 表示吉字节，T 表示太字节。

对于 EFI 系统分区，应该至少分配 500MB。输入所需空间后，按 Enter 完成。更新后的分区列表可能如下所示：

EFI 系统分区是一种特殊类型的分区。它必须采用特定的类型和格式。要更改默认类型，请保持新创建的分区突出显示并从操作列表中选择 [ Type ] 。

从这个长长的类型列表中，突出显示 EFI System 并按 Enter。列表中的分区类型会相应更新：

接下来是 root 分区。突出显示剩余的可用空间并再次选择 [ New ] 。这次分配 10GB 给这个分区。root 分区的理想大小取决于个人需要。就我而言，我为所有 Linux 安装的 root 分区分配了至少 100GB 的空间。

无需更改此分区的类型。默认的 Linux filesystem 就可以了。

使用剩余空间创建最后一个分区，并从菜单中将其类型更改为 Linux swap：

交换分区的理想大小是一个有争议的问题。就我个人而言，我的机器上没有交换分区。我的内存足够大。但如果以后有需要，可以使用 swapfile 来代替。无论如何，设备的最终状态应如下所示：

如果对设置感到满意，请从操作列表中突出显示 [ Write ]，然后按 Enter。该程序将询问是否要保留这些更改。如果同意，必须输入 yes 并按 Enter。更改分区表后，选择 [ Quit ] 退出程序。

对于那些尝试将 Arch Linux 与 Windows 一起安装的人，我想提一提的是，在这种情况下，EFI 系统分区应该已经存在于设备中。所以不要碰那个。只需创建其他分区并继续。

如何格式化分区

现在已经创建了分区，需要格式化它们。可以使用 mkfs 和 mkswap 程序。在格式化之前，执行以下命令查看分区列表：

fdisk /dev/sda -l

这次将看到三个新创建的分区及其详细信息：

记住设备名称，例如 /dev/sda1、/dev/sda2、/dev/sda3 等。EFI 系统分区必须为 FAT32 格式。执行以下命令将分区格式化为 FAT32 格式：

mkfs.fat -F32 /dev/sda1

下一个是 root 分区。它可以有多种格式，但我习惯使用 EXT4 。使用以下命令格式化为 EXT4 分区：

mkfs.ext4 /dev/sda2

此操作可能需要一些时间才能完成，具体取决于分区大小。最后是交换分区。使用以下命令对其进行格式化：

mkswap /dev/sda3

这样，就完成了为安装准备分区的过程。

如何挂载文件系统

现在已经创建并格式化了分区，可以挂载它们了。可以使用 mount 命令来挂载分区：

mount /dev/sda2 /mnt

希望记得之前 /dev/sda2 分区被创建为 root 分区。Linux 中的 /mnt 挂载点用于临时挂载存储设备。由于我们只需要挂载安装 Arch Linux 的分区，所以使用 /mnt 挂载点。

而对于交换分区，不能像其他分区一样挂载它。需要明确告诉 Linux 将此分区用作交换。执行以下命令：

swapon /dev/sda3

可能已经猜到了，swapon 命令告诉系统在此设备上进行交换。我们将在后面的部分中使用 EFI 系统分区。目前，安装这两个分区就足够了。

如何配置镜像源

在安装 Arch Linux 之前还有最后一步，那就是配置镜像源。镜像源是位于世界各地不同地点的服务器，用于为附近的人提供服务。

安装程序附带 Reflector，这是一个 Python 脚本，用于检索 Arch Linux 镜像状态 页面的最新镜像列表。要打印出最新的镜像列表，执行以下命令：

reflector

如果网速较慢，可能会遇到如下错误消息：

failed to rate http(s) download (https://arch.jensgutermuth.de/community/os/x86_64/community.db): Download timed out after 5 second(s).

当下载信息的时间超过默认超时（5 秒）时，就会发生这种情况。

可以使用 --download-timeout 选项来解决此问题：

reflector --download-timeout 60

现在 reflector 将等待整整一分钟，才会失败。一长串镜像源地址会出现在屏幕上：

遍历整个列表以找到附近的 mirrors 会很麻烦。可以用 reflector 来搞定。

Reflector 可以根据的给定约束生成 mirrors 列表。例如，想要一个最近 12 小时内同步过的 mirrors 列表，这些 mirrors 位于印度或新加坡（这两个离我的位置最近），并按下载速度对镜像进行排序。

可以用 reflector 这样做：

reflector --download-timeout 60 --country India,Singapore --age 12 --protocol https --sort rate

找到的服务器将像以前一样列出：

像这样打印出 mirror 列表是不够的。必须将列表保存在 /etc/pacman.d/mirrorlist 位置。Pacman，是 Arch Linux 的默认包管理器，可以使用这个文件来查找 mirror。

在覆盖默认 mirror 列表之前，先对其进行复制：

cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak

现在使用 --save 选项执行 reflector 命令，如下所示：

reflector --download-timeout 60 --country India,Singapore --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

此命令将生成 mirror 列表并覆盖默认列表。现在已准备好安装基本的 Arch Linux 系统。

如何安装 Arch Linux 基础系统

在安装基础系统之前，最好根据新的 mirror 列表更新包缓存。请执行以下命令：

pacman -Sy

Arch Linux 的 pacman 程序就像 Ubuntu 的 apt 或 Fedora 的 dnf 程序。-S 选项表示同步，相当于 apt 或 dnf 包管理器中的 install。

更新过程完成后，可以使用 pacstrap 脚本安装 Arch Linux 系统。执行以下命令开始安装：

pacstrap /mnt base base-devel linux linux-firmware sudo nano ntfs-3g networkmanager

pacstrap 脚本可以将软件包安装到指定的新 root 目录。你可能还记得，root 分区被挂载在 /mnt 挂载点上，所以这个脚本使用了 /mnt 参数。然后，传入要安装的软件包名称：

• base - 定义基本 Arch Linux 安装的最小软件包集。
• base-devel——从源代码构建软件所需的软件包组。
• linux——内核本身。
• linux-firmware——通用硬件的驱动程序。
• sudo - 以 root 身份运行命令
• nano - 具有一些增强功能的 pico 编辑器克隆。
• ntfs-3g – 使用 NTFS 驱动器所需的 NTFS 文件系统驱动程序和实用程序。
• networkmanager - 为系统提供检测和配置以自动连接到网络。

我想澄清一下，这七个包的不是强制性的。要安装功能正常的 Arch Linux，只需要 base、linux 和 linux-firmware 包。但是考虑到其他包也是必需的，为什么不一起装完它们。

根据网速快慢，安装过程可能需要一段时间。坐下来放松一下，直到 pacstrap 完成它的工作。完成后，将看到如下内容：

恭喜，你已经成功地在你的电脑上安装了 Arch Linux。现在剩下要做的就是配置系统。

如何配置 Arch Linux

安装 Arch Linux 没那么难吧？ 事实上，在我看来，安装比配置更简单。这里有很多事情要做。所以让我们开始吧。

如何生成 Fstab 文件

根据 ArchWiki,

fstab(5) 文件可用于定义磁盘分区，各种其他块设备或远程文件系统应如何装入文件系统。

在 Ubuntu 或 Fedora 等其他发行版中，它会在安装过程中自动生成。但是，在 Arch 上，必须手动完成。执行以下命令：

genfstab -U /mnt >> /mnt/etc/fstab

genfstab 程序可以检测给定挂载点以下的所有当前挂载，并以兼容 fstab 的格式将它们打印到标准输出。所以 genfstab -U /mnt 将输出 /mnt 挂载点下的所有当前挂载。可以使用 >> 操作符将该输出保存到 /mnt/etc/fstab 文件中。

如何使用 Arch-Chroot 登录新安装的系统

现在登录的是实时环境，而不是新安装的系统。

要继续配置新安装的系统，必须先登录。执行以下命令：

arch-chroot /mnt

arch-chroot bash 脚本是 arch-install-scripts 软件包的一部分，可以无需重新启动即可更改为新安装系统的 root 用户。酷！

如何配置时区

切换 root 后，首先要配置的是时区。要查看所有可用时区的列表，请执行以下命令：

ls /usr/share/zoneinfo

所有主要时区都在目录中。

我住在位于亚洲区的孟加拉国达卡。如果列出亚洲的内容，可以看到达卡：

在 /etc/localtime 位置创建文件的符号链接，将 Asia/Dhaka 设置为我的默认时区：

ln -sf /usr/share/zoneinfo/Asia/Dhaka /etc/localtime

ln 命令用于创建符号链接。-sf 选项分别表示软链接和强制执行。

如何配置本地化

现在需要配置语言。Arch Linux 也有一个简单的设置方法。

首先，根据本地化信息编辑 etc/locale.gen 文件。在 nano 文本编辑器中打开文件：

nano /etc/locale.gen

会看到一长串语言列表：

需要取消要启用的语言的注释。我通常只需要英语和孟加拉语。因此，我将找到 en_US.UTF-8 UTF-8、bn_BD UTF-8 和 bn_IN UTF-8 语言。按 Ctrl + O 保存文件，然后按 Ctrl + X 组合键退出 nano。

现在执行以下命令：

locale-gen

locale-gen 命令将读取 /etc/locale.gen 文件并生成相应地语言环境。

现在已经启用了多种语言，需要告诉 Arch Linux 默认使用哪一种。打开 /etc/locale.conf 文件并向其中添加以下行：

LANG=en_US.UTF-8

至此，配置语言环境操作完毕。可以随时返回到 /etc/locale.gen 文件并从中添加或删除语言。只要记住在执行此操作时运行 locale-gen 即可。

如果在安装的第一步中对控制台键盘映射进行了更改，现在也需要保留它们。打开 /etc/vconsole.conf 文件并在其中添加你需要的键盘映射。

例如，如果在第一步中将默认键盘映射更改为 mac-us，那么需要将以下行添加到 vconsole.conf 文件中：

KEYMAP=mac-us

现在，每次使用虚拟控制台时，它都会有正确的键盘映射，而不必每次都对其进行配置。

如何配置网络

在任何 Linux 发行版中手动配置网络都非常棘手。这就是为什么我建议在系统安装过程中安装 networkmanager 软件包的原因。如果之前安装过了，就可以跳过安装步骤。否则，现在使用 pacman 安装软件包：

pacman -S networkmanager

Pacman 是一个包管理器。稍后将了解更多有关它的信息。现在先为计算机设置主机名。主机名是为识别网络上的机器而创建的唯一名称，写入/etc/hostname 文件中。

使用 nano 打开文件并在其中写入主机名。可以使用任何字符来标识机器。我通常使用我的设备品牌或型号作为我的主机名，并且由于我使用的是 legion 笔记本电脑，所以我将简单地写下以下内容：

legion

本地主机名解析由 nss-myhostname（systemd 提供的 NSS 模块）提供，无需编辑 /etc/hosts 文件。已默认启用。

但有些软件可能仍会直接读取/etc/hosts 文件。在 nano 中打开文件并添加以下行：

127.0.0.1        localhost
::1              localhost
127.0.1.1        legion

确保将 legion 替换为你的主机名。现在可以安装上述软件包：

pacman -S networkmanager

通过执行以下命令启用 NetworkManager 服务：

systemctl enable NetworkManager

确保将 NetworkManager 而不是 networkmanager 作为服务名称。如果命令成功，网络管理器将从现在开始在启动时自动启动并执行其操作。

如何设置 root 密码

你可能想为 root 用户设置密码，执行以下命令：

passwd

passwd 命令允许更改用户的密码。默认情况下，它会更改当前用户的密码，即 root。

它会要求输入新密码和确认密码。仔细输入，确保密码不会被忘记。

如何创建非 root 用户

长期以 root 用户身份使用 Linux 系统并不是一个好主意。所以创建一个非 root 用户很重要。要创建新用户，请执行以下命令：

useradd -m -G wheel farhan

useradd 命令允许创建一个新用户。确保将 farhan 替换为你要使用的名字。-m 选项表示还希望它创建相应的主目录。-G 选项会将新用户添加到 Arch Linux 中的管理用户组 wheel 组。

现在可以再次使用 passwd 命令为新创建的用户设置密码：

passwd farhan

该程序将提示输入新密码和密码确认。再说一次，别忘了把 farhan 换成你用过的名字。

最后，需要为这个新用户启用 sudo 权限。使用 nano 打开 /etc/sudoers 文件。打开后，找到以下行并取消注释：

# %wheel ALL=(ALL) ALL

该文件实质上意味着 wheel 组中的所有用户都可以通过提供密码来使用 sudo。按 Ctrl + O 保存文件并按 Ctrl + X 退出 nano。现在新用户将能够在必要时使用 sudo。

如何安装 Microcode

摘自 PCMag,

复杂指令集计算机 (CISC) 中的一组基本指令。Microcode 驻留在单独的高速存储器中，用作机器指令和计算机电路级之间的翻译层。Microcode 使计算机设计人员能够创建机器指令，而无需设计电子电路。

英特尔和 AMD 等处理器制造商经常会发布处理器的稳定性和安全性更新。这些更新对于系统的稳定性至关重要。

在 Arch Linux 中，Microcode 更新可以通过官方软件包获得，每个用户都应该在他们的系统上安装这些软件包。

pacman -S amd-ucode


pacman -S intel-ucode

仅仅安装这些软件包是不够的。必须确保你的引导加载程序正在加载它们。具体将在下一节中介绍。

如何安装和配置 Boot Loader

摘自维基百科，

bootloader，也拼写为 boot loader 或称为 boot manager 和 bootstrap loader，是负责引导计算机的计算机程序。

bootloader 的细节超出了本文的范围，所以只涉及安装过程。如果过去使用过任何其他 Linux 发行版，可能了解过 GRUB 菜单。

GRUB 是目前最流行的 bootloaders 之一。尽管有很多功能，这里将只演示 GRUB 的安装，因为大多数人只需安装即可。

要安装 GRUB，必须首先安装如下两个软件包。

pacman -S grub efibootmgr

如果与其他操作系统一起安装，还需要 os-prober 包：

pacman -S os-prober

该程序将搜索系统上已安装的操作系统，并将它们作为 GRUB 配置文件的一部分。

现在，需要挂载之前创建的 EFI 系统分区。为此，首先创建一个 efi 目录：

mkdir /boot/efi

摘自维基百科，

在 Linux 和其他类 Unix 操作系统中，/boot/ 目录包含用于引导操作系统的文件。

该目录存在于所有类 Unix 操作系统中。上面提到的命令在 /boot 目录中创建了一个名为 efi 的目录。创建目录后，需要在该目录中安装 EFI 系统分区。

mount /dev/sda1 /boot/efi

希望你还记得我们在分区阶段将/dev/sda1设备格式化为EFI系统分区。确保为你的设备使用正确的设备。

现在，我们将使用 grub-install 命令在新挂载的 EFI 系统分区中安装 GRUB：

grub-install --target=x86_64-efi --bootloader-id=grub

可以或多或少地逐字使用此命令。可以将 --bootloader-id 更改为你想要展示的任何更贴切的文字，例如 arch 或其他内容。如果安装完成且没有任何错误，则需要生成 GRUB 配置文件。

如果与其他操作系统一起安装，则必须在生成配置文件之前启用 os-prober。在 nano 文本编辑器中打开 /etc/default/grub 文件。找到以下行并取消注释：

#GRUB_DISABLE_OS_PROBER=false

这是上述文件中的最后一行，只需滚动到底部并取消注释即可。

现在执行以下命令生成配置文件：

grub-mkconfig -o /boot/grub/grub.cfg

grub-mkconfig 命令生成 GRUB 配置文件并将其保存到指定的目标位置。在这里，是 /boot/grub/grub.cfg 。

该命令还会检测之前安装的 microcode 以及机器上的任何其他现有操作系统。

恭喜，现在已经安装了 Arch Linux。此时，可以退出 Arch-Chroot 环境，卸载分区，然后重新启动。但我建议你多待一会儿，一起设置好图形用户界面。

如何安装 Xorg

要在系统上运行带有图形用户界面的程序，需要安装 X Window System 实现。最常见的是 Xorg。

要安装 Xorg，请执行以下命令：

pacman -S xorg-server

等到安装完成，然后继续安装必要的图形驱动程序。

如何安装图形驱动程序

在 Arch Linux 上安装图形驱动程序非常简单。只需安装图形处理单元所需的软件包，然后就可以收工了。

pacman -S nvidia nvidia-utils


pacman -S xf86-video-amdgpu


pacman -S xf86-video-intel

如果需要进一步的帮助，请随时查看 ArchWiki 页面。

如何安装桌面环境

现在已经安装了 Xorg 和必要的图形驱动程序，可以继续安装桌面环境，如 GNOME、Plasma 或 XFCE。

Arch Linux 支持很多的桌面环境，但我只尝试过 GNOME 和 Plasma。我将演示如何安装这两个。

如何安装 GNOME 桌面

要安装 GNOME，需要安装 gnome 包。执行以下命令：

pacman -S gnome

在安装过程中，会提供 pipwire-session-manager 和 emoji-font 软件包的多种选择。在两个提示中按 Enter 接受默认值。安装可能需要一些时间才能完成。

gnome 软件包带有 GDM 或 Gnome 显示管理器。可以通过执行以下命令来启用该服务：

systemctl enable gdm

到这里，在 Arch 系统上启动和运行 GNOME 的准备工作已经全部完成。

如何安装 Plasma 桌面

KDE Plasma 安装与 GNOME 没有什么不同。需要安装 Plasma 相关的包而不是 GNOME。

pacman -S plasma plasma-wayland-session

如果电脑是 NVIDIA 显卡，请不要安装 plasma-wayland-session，使用普通的旧 X11。我拥有两台配备 NVIDIA GPU 的设备，并且在使用 Wayland 时它们都表现出不稳定。

在安装过程中，将出现 ttf-font、pipwire-session-manager 和 phonon-qt5-backend 包的多种选择。确保选择 noto-fonts 作为 ttf-font 并接受其他两个的默认值。

与 GNOME 中的 gdm 一样，Plasma 带有 sddm 作为默认显示管理器。执行以下命令启用服务：

systemctl enable sddm

到这里，在 Arch Linux 系统上启动和运行 Plasma 的准备工作已经全部完成。

如何完成安装

现在已经安装了 Arch Linux 并完成了所有必要的配置步骤，可以重新启动到新安装的系统。首先要退出 Arch-Chroot 环境：

exit

接下来，卸载 root 分区以确保没有挂起的操作：

umount -R /mnt

现在重新启动机器：

reboot

等到看到 GRUB 菜单。

从列表中选择 Arch Linux 并等待系统完成启动。

使用你的用户凭据登录，如下！

全新 Arch Linux 系统已准备好。

如何在桌面环境之间切换

与其他与默认桌面环境紧密耦合的发行版不同，Arch 非常灵活。可以随时切换到另一个桌面环境。

为此，请先注销当前会话。

如你所见，我目前正在使用 Plasma。现在切换到 TTY2 按 Ctrl + Alt + F2 组合键。将看到控制台登录提示：

使用 root 凭据登录并禁用 sddm 显示管理器。

systemctl disable sddm

然后卸载之前安装的 Plasma 相关包：

sudo pacman -Rns plasma plasma-wayland-session

卸载软件包后，安装 GNOME 所需的软件包：

pacman -S gnome

然后根据你之前阅读的部分执行安装。安装 gnome 包后，启用 gdm 显示管理器：

systemctl enable gdm

重新启动计算机。

reboot

等到 Arch Linux 系统完成启动。

哇哦，漂亮的 Gnome 显示管理器。使用你的凭据登录。

可以根据需要在桌面环境之间切换，但建议在其中一个环境下安顿下来。另外，不建议同时安装多个。

使用 Pacman 管理包

已经使用 pacman 安装了许多软件包。它相当于 Ubuntu 中的 apt 和 Fedora 中的 dnf 等软件包管理器。

在本节中，将介绍一些每天都可能用到的常用 pacman 命令。

如何使用 Pacman 安装软件包

可以使用以下 pacman 命令语法安装软件包：

sudo pacman -S rust

可以按如下方式安装多个软件包：

sudo pacman -S rust golang

还可以指定软件包的位置，如下所示：

sudo pacman -S extra/rust

在此命令中，-S 选项表示同步，相当于在 apt 或 dnf 包管理器的安装。

如何使用 Pacman 删除软件包

可以使用以下 pacman 语法删除软件包：

sudo pacman -R rust

这将删除包，但会留下依赖项。如果其他包也不需要它们，则可以通过执行以下命令删除不在需要的包：

sudo pacman -Rs rust

Pacman 在删除某些应用程序时通常会保存重要的配置文件。可以使用以下语法覆盖此行为：

sudo pacman -Rn rust

当卸载某些包时，通常会使用sudo pacman -Rns。要展示的最后一件事是如何删除孤立包。

在 Ubuntu 中，sudo apt autoremove 命令会卸载任何不必要的软件包。Arch 中的等效命令是：

sudo pacman -Qdtq | pacman -Rs -

这将清除以前安装的软件包中的残余软件包。

如何使用 Pacman 升级软件包

可以使用以下语法升级系统中的所有软件包：

sudo pacman -Syu

在这个命令中，S 选项同步包，y 刷新本地包缓存，u 更新系统。这就像终极升级命令，我基本每天都会运行一次。

如何使用 Pacman 搜索软件包

要在数据库中搜索包，可以使用以下语法：

sudo pacman -Ss rust

这将打印出在数据库中找到的所有包含该搜索词的包，并且还会标识是否已经安装。

如果想检查一个包是否已经安装，可以使用以下命令：

sudo pacman -Qs rust

当想卸载软件包但不知道其确切名称时，这很有用。

如何在 Arch Linux 中使用 AUR

摘自 It's FOSS

AUR 代表 Arch 用户存储库。它是基于 Arch 的 Linux 发行版用户的社区驱动存储库。它包含名为 PKGBUILDs 的包描述，允许使用 makepkg 从源代码编译包，然后通过 pacman（Arch Linux 中的包管理器）安装它。

AUR 是 Arch Linux 最吸引人的特性之一。有了 AUR，Arch Linux 的软件包数量几乎与 Debian 相当。之前使用 pacman 安装了各种软件包。遗憾的是，不能使用它从 AUR 安装软件包。

需要安装一个 AUR helper。Arch Linux 默认不支持这些 helpers，它更倾向让开发者自己手动构建包。在这里会介绍这两种技术。如果了解 helper 的工作原理，手动完成会很顺手。

如何使用 Helper 安装软件包

在可用且当前维护的 AUR helper 中，我喜欢 yay 或另一个 yogurt 包。它是用 Go 编写的，非常可靠。

不能像其他软件包一样安装yay。需要获取源代码并编译程序。需要 git 和 base-devel 包来执行此操作。这里假设在 Arch Linux 安装期间已经安装了 base-devel：

pacman -S git

从 GitHub 克隆 yay 仓库并 cd 进入到目录里：

git clone https://aur.archlinux.org/yay.git && cd yay

执行以下命令，从源代码构建和安装 yay：

makepkg -si

makepkg 脚本自动执行包的构建过程。-si 选项代表同步依赖项和安装。第一个选项将安装所需的依赖项（在本例中为 Golang），后一个选项将安装构建的包。

构建过程完成后，makepkg 将要求输入密码。输入密码，完成安装。

检查 yay 是否已正确安装：

yay --version

现在让我们使用 yay 安装一些东西。比较常见软件包如 visual-studio-code-bin 软件包。要安装它，执行以下命令：

yay -S visual-studio-code-bin

与 pacman 不同，不应该使用 sudo 运行 yay。Yay 将查找给定的包并询问是否想查看差异：

AUR 上的所有仓库都带有一个 PKGBUILD 文件，其中包含构建此包的说明。Yay 有这个不错的功能，它可以显示自上次以来 PKGBUILD 文件中发生了什么变化。

现在，选择 N 表示无，然后按 Enter。Yay 现在将查找依赖项并输入密码来执行安装。

确认安装并提供密码。Yay 将安装依赖项并开始构建包。构建完成后，yay 将安装该软件包并在必要时提示输入密码。

安装完成后，在应用程序启动器中搜索 Visual Studio Code：

恭喜你从 AUR 安装了你的第一个包。Yay 命令与 pacman 几乎相同，所以如果可以用 pacman 做某事，也可以用 yay 做。

事实上，yay 也可以安装来自 Arch Linux 官方仓库的软件包，比如 pacman。建议仅在必要时使用 yay 从 AUR 安装软件包，使用 pacman 安装其他所有软件包。

如何手动安装软件包

就像我在上一节中所说的，ArchWiki 建议避免使用任何 AUR helper，而是手动从 AUR 安装包。现在将展示如何做。

确保安装了 git 和 base-devel 包。如果没有，使用 pacman 安装它们。

做为演示，这次来安装 Spotify。首先访问 spotify 包的 AUR 页面 - https://aur.archlinux.org/packages/spotify/ 并复制“Git Clone URL”。

该页面甚至列出了需要的所有依赖项。将仓库克隆到计算机：

每个 AUR 仓库都附带一个 PKGBUILD 文件，其中包含构建包的说明。当从 AUR 安装软件包时，可以使用类似 cat 命令检查 PKGBUILD 文件：

确保文件中没有任何有害内容。使用 makepkg 安装任何依赖项，构建包并安装它。理想情况下不应该有任何问题，但有时，可能会出现异常情况。

这时，可以返回相应的 AUR 页面并查看用户评论。在这里，找到了以下固定评论：

原来该软件包要求将 Spotify for Linux gpg 密钥添加到用户 kyechain。此命令使用 curl 下载 gpg 密钥并将其作为 gpg --import 命令的输入：

尝试再次执行makepkg -si，这次一切都正常了：

看，事实上！ 手动安装软件包经常会出现此类故障，一般在评论里就可以找到解法。现在让我们来欣赏音乐吧。

如何解决常见问题

我多年来一直使用 Arch 作为我所有主力机的操作系统，但仍然会遇到一些问题。幸运的是，当遇到困难时，有一些很棒的地方可以寻求帮助：

• ArchWiki
• Arch Linux Forum
• r/archlinux

在大多数情况下，wiki 可以找到想要找的内容。事实上，如果使用的是笔记本电脑，执行某些操作时卡住了，有一个完整的 wiki 类别专门按不同的笔记本型号分类。建议看看 wiki。

如果 wiki 未能解决你的问题，请在论坛和 subreddit 上询问其他用户。但是，无论何时，请务必先进行研究，并在帖子中包含尽可能多的描述。如果其他用户不得不不断地向你询问更多信息，这真的很烦人，这也会降低你得到答案的机会。

如何使用 Live Arch ISO 作为恢复媒介

不要理会别人怎么说，只要你知道自己在做什么，Arch Linux 就很少出问题。如果在 AUR 中安装较新的包，或者在不知道它们用途的情况下不断切换不同的内核，系统可能无法启动。

在这些情况下，可以将 Live U 盘用作应急媒介。为此，请将可启动 U 盘重新连接到计算机并启动到实时环境。在那里，如果愿意，可以配置时间、键盘映射和字体。

然后使用 fdisk 列出所有分区并找到保存 Arch Linux 安装的分区。在我的例子中，它是 /dev/sda2 分区。像以前一样挂载分区：

mount /dev/sda2 /mnt

现在使用 Arch-Chroot 以 root 用户身份登录。

arch-chroot /mnt

现在卸载安装的坏包或回到过去曾经工作的内核版本等等。完成后，退出 Arch-Chroot 环境，卸载分区，然后重新启动：

exit
umount -R /mnt
reboot

如果计算机启动正常，那么恭喜。否则，请尝试 wiki、论坛或 subreddit。如果没有任何效果，可能需要重新安装。

拓展阅读

如果已经走到了这一步，那么已经接触了很多资料——但这还不是全部。整本手册是通过结合来自 wiki、论坛和 subreddit 的信息编写的。我列出了一些拓展的 wiki 页面。

• Installation guide
• Network configuration
• General recommendation
• Desktop environment
• pacman
• Arch Build System
• makepkg
• List of applications

目前想到这些，我会更新这个列表。

总结

衷心感谢你花时间阅读本文。希望你享受学习过程，能学到一些关于 Arch 和 Linux 的知识。

除了本文，我还编写了关于其他复杂主题的手册，可在 freeCodeCamp 免费获得。

这些手册是我践行“为大家简化难以理解的技术”使命的一部分。每一本手册都花费了大量时间和精力。

如果你喜欢我的写作并想鼓励我，请考虑 star GitHub 并在 [LinkedIn](https://www. linkedin.com/in/farhanhasin/) 上关注我。

我总是乐于接受建议和讨论。欢迎在 Twitter 或 LinkedIn 上关注我，直接向我发送消息。

最后，欢迎分享给你的朋友，因为

在开源领域，我们强烈认为要真正做好某件事，就必须让更多人参与进来。— Linus Torvalds

接下来，保持严谨并持续学习。

在之前的文章《迈向计算科学的一步：JS 里的简易算法和数据结构》里，我们讨论了简易的算法 (线性和二分搜索；冒泡、选择、插入排序) 以及数据结构 (数组、键值对对象)，这里将继续讨论算法和数据结构的复杂度概念及其应用。

复杂度

复杂度是衡量程序复杂程度的一个指标。对于算法和数据结构来讲，它代表运行指定任务（如搜索、排序、访问数据）花费的时间和空间 (计算所消耗的内存)。任务的执行效率取决于执行完整程序需要的操作数。

扔垃圾需要 3 步 (打包垃圾袋，拎出去，扔进垃圾桶里)。 扔垃圾 很简单，但是如果扔装修一周后攒的垃圾，会发现不能完成这个简单的任务，因为垃圾桶 空间不足 。

房屋吸尘需要一些重复的步骤 (打开开关，使用吸尘器头重复的在地板上刮扫，关闭开关)。越大的房间就需要在地板上刮扫越多次，房屋除尘也就要耗费 越多的时间 。

执行的操作数和执行元素的数量有一定的关系，垃圾 (元素) 越多花费的时间越多，这就产生了 空间复杂度 问题。面积 (元素) 越大，吸尘器头刮扫的次数就越多，这就产生了 时间复杂度 问题。

不管是 扔垃圾 还是 房间吸尘， 操作数 (O) 和 元素的数量 (n) 成正比。如果只有一个垃圾袋，那么一次只能携带一袋垃圾。如果有两个垃圾袋，那么同时就能携带两袋垃圾，当然在体力足以同时拎两袋垃圾的前提下。这些家务活的大 O 就是 O = n，也可以写成 O = function(n) 或者 O(n) 。在这里复杂度是线性的 （操作数和元素是一一对应的关系），即 30 个操作对应 30 个元素 (上图的黄线)。

在算法和数据结构里情况是一样的。

搜索

线性搜索

元素搜索的 最好情况 是有序列表，假设要搜索的元素就在列表的第一项，这时复杂度是常数 O(1)。因此，如果搜索的元素总是第一个被索引到，和列表长度无关，元素会当即被搜索到。搜索的复杂度是和列表长度相关的常数。这种搜索平均最坏的情况是线性复杂度 O(n)。换言之，n 个元素，要遍历 n 次才能找到，因此叫线性搜索。

二分搜索

对于二分搜索， 最好的情况 也是 O(1) ，此时搜索的元素位于中点。平均最坏的情况是 n 以 2 为底的对数：

对数或者 log 是幂运算的逆运算，所以如果有 16 个元素 (n=16)，这时至少要花费 4 步（这是在最坏情况下），4 步就能找到数字 15 (基数 = 4)。

或者， O(log n)

排序

冒泡

在冒泡排序里，元素和剩下的元素集合对比来找更高的元素向上冒泡，所以，平均最坏的情况，复杂度是 O(n²) ，也就是嵌套循环。

每一个元素都要和剩下元素的集合进行对比，4 个元素一共对比 16 次 (4² = 16)。 最好的情况 是集合除了一个元素外其余都已经排好序了，那么只需进行一轮对比。也就是说四个元素需要和集合里剩下的 3 个分别元素对比，复杂度也就是 O(n) 。

选择排序

和 冒泡排序 高值冒泡不同， 选择排序 把最低值放在未排序元素的最前面，因为需要和剩下集合的每个元素对比，它的复杂度是 O(n²) 。

插值排序

和 冒泡&选择排序 不同， 插值排序 把元素直接插入到正确的位置。和上一个排序一样，需要和集合里剩下的元素对比，因此 平均最坏的复杂度 是 O(n²) 。和冒泡排序类似，如果只有一个元素需要排序，只需要一轮对比来把元素插入到正确的位置。复杂度为 O(n) 。

数据结构

数组

因为通过索引访问、添加或者删除末位数据元素只需要一步， 访问、推入、弹出 数组里的值的复杂度是 O(1) 。因此，在数组里通过索引来 线性搜索 的复杂度是 O(n) 。

另外，在数组在前面 shift 或者 unshift 值需要 重新索引 之后的每一个元素 (比如，移除索引为 0 的元素需要重新给索引为 1 的元素标记为 0，依次直到第四个)，它的复杂度是 O(n) ，需要重新标记所有元素。

健 - 值对对象

通过健 访问、插入或者删除 值是瞬间发生的，因此，复杂度是 O(1) 。通过索引健在 “存储箱” 中搜索特定的项目本质是线性搜索，因此它的复杂度是 O(n) 。

结论

复杂度不只是既定算法和数据结构里面的一个论题。运用恰当，它会是衡量代码的效率的一个利器。

组件的黄金法则

用更自然的方式创建和定义组件，组件只包含它们必需的代码

这是很短的一句话，可能你觉得已经理解了，但却很容易违反这一原则。

比如，有如下组件：

如果自然的定义这个组件你可能会这样写：

PersonCard.propTypes = {
  name: PropTypes.string.isRequired,
  jobTitle: PropTypes.string.isRequired,
  pictureUrl: PropTypes.string.isRequired,
};

代码很简单，每个属性都是它所必需的，如 name、job title 和 picture URL。

假设现在需要添加用户可更改的另一个更正式的图片。可能最容易想到的就是：

PersonCard.propTypes = {
  name: PropTypes.string.isRequired,
  jobTitle: PropTypes.string.isRequired,
  officialPictureUrl: PropTypes.string.isRequired,
  pictureUrl: PropTypes.string.isRequired,
  preferOfficial: PropTypes.boolean.isRequired,
};

看起来这些 props 是组件必需的，实际上，组件没有这些 props 也不会受到影响。而且添加了 preferOfficial 看似增加了灵活性，其实逻辑本来不该添加在这里，考虑复用的时候会发现这样做很不优雅。

如何改进

那么转换图片 URL 的逻辑不属于组件本身，那它属于哪里呢？

放在 index 里怎么样？

我们采用如下的目录结构，每个组件都有自己名字命名的文件夹，index 文件是沟通优雅组件和外部世界的桥梁。我们把这个文件叫做 “容器”（container）(参考了React Redux 的 “container” 组件概念）。

/PersonCard
  -PersonCard.js ------ the "natural" component
  -index.js ----------- the "container"

我们将容器（container）定义为连接优雅组件和外部世界的桥梁。正因为此，我们有时候又称之为 “注入（injectors）”。

优雅组件（natural component） 代表你的代码只包含必需的部分（没有诸如怎样获取数据或者位置等细节—所有代码都是必需的）。

外部世界（outside world）可以将数据转换成符合优雅组件所需的 props。

这篇文章讨论的：怎样让组件不受外部世界的污染，以及这样做的好处。

注意：虽然灵感来自 Dan’s Abramov 和 React Redux’s 的理念，但我们的容器和它们的略微不同。
Dan Abramov 的容器 和我们区别是在概念层面上。Dan 认为有两种组件：展示组件和容器组件。我们在这个基础上更进一步，认为先有组件，后有容器。
虽然我们用组件实现容器，但我们不认为容器是传统意义的组件。这就是为什么我们建议你把容器放在 index 文件里—因为它是优雅组件和外部世界的桥梁。并不独立存在。

所以这篇文章会有大量的组件、容器字眼。

为什么？

创建一个优雅组件–很容易、甚至还很有趣。

连接组件和外部世界–有点难。

依我之见，外部世界对优雅组件的污染，主要是这三种方式：

1. 古怪的数据结构
2. 组件 scope 之外的需求 (就像上面的代码那样)
3. 在 update 或者 mount 时触发 event

接下来的几节将会说明这些情况，并用例子展示不同情况下的容器实现。

处理古怪的数据结构

有时候为了呈现需要的信息，需要把数据连在一起然后将其转换成特定的格式。由于没有更好的设计模式，“古怪的” 数据结构是最容易想到的的也是最不优雅的方式。

把古怪的数据结构直接传入组件然后在组件内部转换很诱人，但是这会让组件更复杂、更难测试。

我最近就掉进了这个坑里，我创建了一个组件，从一个特殊的数据结构获取数据，然后让它支持特殊的表单。

ChipField.propTypes = {
  field: PropTypes.object.isRequired,      // <-- the "weird" data structure
  onEditField: PropTypes.func.isRequired,  // <-- and a weird event too
};

然后就诞生了这玩意，古怪的 field 数据结构做为 prop。另外，如果以后不需要在处理它了还好，但是当我们想要在另一个完全不相干的数据结构里复用它时，噩梦来了。

由于这个组件需要一个复杂的数据结构，复用几乎不可能，重构起来也很头大。之前写的测试也会很难看懂，因为它们 mock 了一个古怪的数据结构。在持续重构时测试逻辑很难懂也很难重写。

很不幸，古怪的数据结构很难避免，但是使用容器可以很好的驯服它。好处之一是你可以很好的复用组件了。之前直接把古怪的数据结构传入组件，是难复用的罪魁祸首。

注意： 我并不是说在创造组件的开始所有的组件就都应该是通用的。建议是好好考虑考虑组件的基本功能，然后在开始编码。回报是，通过少量工作写出一些高度可复用的组件。

使用函数组件实现容器

如果你 mapping props 上要求很严格，容器的一个简单的实现是使用另一个函数组件：

import React from 'react';
import PropTypes from 'prop-types';

import getValuesFromField from './helpers/getValuesFromField';
import transformValuesToField from './helpers/transformValuesToField';

import ChipField from './ChipField';

export default function ChipFieldContainer({ field, onEditField }) {
  const values = getValuesFromField(field);
  
  function handleOnChange(values) {
    onEditField(transformValuesToField(values));
  }
  
  return <ChipField values={values} onChange={handleOnChange} />;
}

// external props
ChipFieldContainer.propTypes = {
  field: PropTypes.object.isRequired,
  onEditField: PropTypes.func.isRequired,
};

组件的目录结构如下：

/ChipField
  -ChipField.js ------------------ the "natural" chip field
  -ChipField.test.js
  -index.js ---------------------- the "container"
  -index.test.js
  /helpers ----------------------- a folder for the helpers/utils
    -getValuesFromField.js
    -getValuesFromField.test.js
    -transformValuesToField.js
    -transformValuesToField.test.js

你可能会说，这也太麻烦了。看起来是多了一些文件，绕了很多弯，但是别忘了：

在组件外面转换数据和在组件内工作量是一致的。区别是，在组件外面转换数据时，你给了你自己一个更明确的点来测试转换是否正确，分离了关注点。

在组件 scope 的外部满足需要

和上面的 Person Card 一样，当你用 “黄金法则” 来思考的时候，很可能你会意识到需求是超出了组件的实际范围。该怎么实现呢？

没错，就是容器。

可以创建容器，通过少量的工作来保持组件的优雅。这样做的时候，你会解锁一个更专业的组件，这个组件也简单的多，同时容器也更易于测试。

让我们来写一个 PersonCard 容器来举栗说明。

使用高阶组件实现容器

React Redux 就是使用了 高阶组件 ，实现了从 Redux store 里 push、map props 的容器。由于我们是从 React Redux 借鉴的这个理念，毫无疑问 React Redux 的 connect 就是这个容器。

无论你是使用函数组件来映射 props，还是使用高阶组件来连接 Redux strore，组件的黄金法则还是不变的。首先，编写优雅组件，然后用高阶组件连接二者。

import { connect } from 'react-redux';

import getPictureUrl from './helpers/getPictureUrl';

import PersonCard from './PersonCard';

const mapStateToProps = (state, ownProps) => {
  const { person } = ownProps;
  const { name, jobTitle, customPictureUrl, officialPictureUrl } = person;
  const { preferOfficial } = state.settings;
  
  const pictureUrl = getPictureUrl(preferOfficial, customPictureUrl, officialPictureUrl);
  
  return { name, jobTitle, pictureUrl };
};

const mapDispatchToProps = null;

export default connect(
  mapStateToProps,
  mapDispatchToProps,
)(PersonCard);

文件结构如下：

/PersonCard
  -PersonCard.js ----------------- natural component
  -PersonCard.test.js
  -index.js ---------------------- container
  -index.test.js
  /helpers
    -getPictureUrl.js ------------ helper
    -getPictureUrl.test.js

注意：在这里，给 getPictureUrl 提供一个助手。这个逻辑很简单。你可能已经注意到了，无论 container 实现如何，文件结构几乎没变。

如果你之前用过 Redux，上面的例子你一定不陌生。再次重申，这个黄金法则不只是一个点子，它还提供了一个新思路。

另外，当使用高阶函数实现容器时，还可以把它们连在一起–把一个高阶组件做为 props 传递给下一个。我就曾经把多个高阶组件连在一起构成了一个单个的容器。

2019 注意：React 社区似乎正在让高阶组件规范成设计模式。

我也如此建议。我的经验是，对于那些不理解 functional composition 的人来说写代码很容易引发 “wrapper 地狱”，组件嵌套太多层从而引发了严重的性能问题。

这里是一些相关文章：Hooks talk (2018)， Recompose talk (2016)， Use a Render Prop! (2017)，When to NOT use Render Props (2018)

说好的钩子来了

使用钩子实现容器

为什么在这里会讨论钩子呢？因为使用钩子实现容器真的很简单呀。

如果你对 React 钩子陌生，建议你看一看 Dan Abramov 和 Ryan Florence 在 2018 React Conf 上的谈话。

要点是，钩子是 React 团队为了解决高阶组件和类似模式的问题引入的。React 想要在类似的场景用钩子替代它们。

这意味着容器既可以用函数组件实现也可以用钩子来实现。

在下面的例子里，我们使用 useRoute 和 useRedux 钩子来代表"外部世界"，使用工具类 getvalue 把外部世界映射为优雅组件的 props。我们还使用了 transformValues 来将组件转换为外部世界的 dispatch 。

import React from 'react';
import PropTypes from 'prop-types';

import { useRouter } from 'react-router';
import { useRedux } from 'react-redux';

import actionCreator from 'your-redux-stuff';

import getValues from './helpers/getVaules';
import transformValues from './helpers/transformValues';

import FooComponent from './FooComponent';

export default function FooComponentContainer(props) {
  // hooks
  const { match } = useRouter({ path: /* ... */ });
  // NOTE: `useRedux` does not exist yet and probably won't look like this
  const { state, dispatch } = useRedux();

  // mapping
  const props = getValues(state, match);
  
  function handleChange(e) {
    const transformed = transformValues(e);
    dispatch(actionCreator(transformed));
  }
  
  // natural component
  return <FooComponent {...props} onChange={handleChange} />;
}

FooComponentContainer.propTypes = { /* ... */ };

下面是对应的目录结构：

/FooComponent ----------- the whole component for others to import
  -FooComponent.js ------ the "natural" part of the component
  -FooComponent.test.js
  -index.js ------------- the "container" that bridges the gap
  -index.js.test.js         and provides dependencies
  /helpers -------------- isolated helpers that you can test easily
    -getValues.js
    -getValues.test.js
    -transformValues.js
    -transformValues.test.js

在容器里触发事件

最后一类导致组件难以复用的情况，是在 props 改变、组件 mounting 的时候触发事件。

比如，以仪表盘为例。设计团队给了你原型图，需要你把它们转换成 React 组件。现在面临的问题是如何用数据填充仪表盘。

可能你已经意识到了可以在组件 mount 时调用函数（比如：dispatch(fetchAction)） 来触发事件。

在类似的这种场景中，普遍做法是添加 componentDidMount 和 compoentDidUpdate 生命周期方法，以及 onMount 和 onDashboardIdChanged props，因为我需要触发外部事件，才能建立组件和外部世界之间的连接。

根据黄金法则，这些 onMount 和 onDashboardIdChanged props 很不优雅的，应该把它们放在容器里。

钩子厉害之处是它能让 onMount 或者 props 改变时的 dispatch 事件变得更容易实现！

在 mount 里触发事件

传入空数组调用 useEffect 来触发 mount 时的 event。

import React, { useEffect } from 'react';
import PropTypes from 'prop-types';
import { useRedux } from 'react-redux';

import fetchSomething_reduxAction from 'your-redux-stuff';
import getValues from './helpers/getVaules';
import FooComponent from './FooComponent';

export default function FooComponentContainer(props) {
  // hooks
  // NOTE: `useRedux` does not exist yet and probably won't look like this
  const { state, dispatch } = useRedux();
  
  // dispatch action onMount
  useEffect(() => {
    dispatch(fetchSomething_reduxAction);
  }, []); // the empty array tells react to only fire on mount
  // https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects

  // mapping
  const props = getValues(state, match);
  
  // natural component
  return <FooComponent {...props} />;
}

FooComponentContainer.propTypes = { /* ... */ };

组件 mount 时通过钩子在容器里触发事件

在 prop 改变时触发事件

useEffect 可以在重新渲染和函数调用时，监视 property 的改变。

在用 useEffect 前我发现我自己添加了冗余的生命周期函数方法和 onPropertyChanged 属性，因为我不知如何在组件外面扩展属性。

import React from 'react';
import PropTypes from 'prop-types';

/**
 * Before `useEffect`, I found myself adding "unnatural" props
 * to my components that only fired events when the props diffed.
 *
 * I'd find that the component's `render` didn't even use `id`
 * most of the time
 */
export default class BeforeUseEffect extends React.Component {
  static propTypes = {
    id: PropTypes.string.isRequired,
    onIdChange: PropTypes.func.isRequired,
  };

  componentDidMount() {
    this.props.onIdChange(this.props.id);
  }

  componentDidUpdate(prevProps) {
    if (prevProps.id !== this.props.id) {
      this.props.onIdChange(this.props.id);
    }
  }

  render() {
    return // ...
  }
}

老方法：当 props 改变的时候触发事件

有了 useEffect 更轻量级的方法来改变 prop ，组件也不必添加多余的 props 了。

mport React, { useEffect } from 'react';
import PropTypes from 'prop-types';
import { useRedux } from 'react-redux';

import fetchSomething_reduxAction from 'your-redux-stuff';
import getValues from './helpers/getVaules';
import FooComponent from './FooComponent';

export default function FooComponentContainer({ id }) {
  // hooks
  // NOTE: `useRedux` does not exist yet and probably won't look like this
  const { state, dispatch } = useRedux();
  
  // dispatch action onMount
  useEffect(() => {
    dispatch(fetchSomething_reduxAction);
  }, [id]); // `useEffect` will watch this `id` prop and fire the effect when it differs
  // https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects

  // mapping
  const props = getValues(state, match);
  
  // natural component
  return <FooComponent {...props} />;
}

FooComponentContainer.propTypes = {
  id: PropTypes.string.isRequired,
};

现在的方法：当 props 改变的时候使用 useEffect 来触发事件

免责声明：在 useEffect 调用前会对比容器里 prop 的异同，还可以使用其它方式，比如高阶组件（比如 recompose 的生命周期 ），或者像 react router 那样在内部 创建一个生命周期组件，但是这些方法要么就是很麻烦要么就是很难理解。

好处是什么

组件保持有趣

对于我来说，创建组件是前端开发中很有趣的部分。能把团队的想法实现感觉很棒，这种感觉值得我们分享。

在也不要让外部世界把组件 API 搞砸了。组件应该和想象中一样没有额外的 props—这也是我从黄金法则里所学到。

更多的机会测试和复用

当你采用一个像这样的模式时，引入了一个新的 data-y 层。在这个层里你可以按需的把数据转换成组件需要的形式。

不管你在不在乎，这个层已经在你的应用里存在了，但是这也可能会加重代码的逻辑。我的经验是当我关注到这一层时，我可以做大量的代码优化，可以复用大量的逻辑，现在当我知道组件之间有共性时我是不会重造轮子的。

我觉得这点在定制钩子上尤为明显。定制钩子给我们一个更简单的方式来抽出逻辑、监测外部的变化—更多时候靠 helper 函数是无法做到的。

最大化团队的输出

在团队协作里，你可以把组件和容器分开。如果事前沟通好 API，你可以同时开启如下工作：

1. Web API (如 后端)
2. 从 Web API 里获取数据（或者其它途径）然后转换数据以符合组件的 API
3. 组件

有没有例外？

就像真正的黄金法则一样，这条黄金法则也有例外。有某些的场景下，在组件里编写冗余的 API 以减少复杂性很有必要。

一个简单的例子就是 props 的命名。如果不在优雅的组件下面重新命名 data key 会让事情变得更复杂。

迷信金科玉律可能会更规范，但是同时也封杀了创造力。

分隔线

不管怎样，黄金法则只是简单的以一个新的角度重申了表现组件和容器组件。总之，在编码前增加基本的组件需求评估，会更容易写出优雅的代码。

感谢阅读。

原文：How the “Golden Rule” of React components can help you write better code，作者：Rico Kahler

一个简单的 “Get Started” 按钮

.btn {
  background: #eb94d0;
  /* 创建渐变 */
  background-image: -webkit-linear-gradient(top, #eb94d0, #2079b0);
  background-image: -moz-linear-gradient(top, #eb94d0, #2079b0);
  background-image: -ms-linear-gradient(top, #eb94d0, #2079b0);
  background-image: -o-linear-gradient(top, #eb94d0, #2079b0);
  background-image: linear-gradient(to bottom, #eb94d0, #2079b0);
  /* 给按钮添加圆角 */
  -webkit-border-radius: 28;
  -moz-border-radius: 28;
  border-radius: 28px;
  text-shadow: 3px 2px 1px #9daef5;
  -webkit-box-shadow: 6px 5px 24px #666666;
  -moz-box-shadow: 6px 5px 24px #666666;
  box-shadow: 6px 5px 24px #666666;
  font-family: Arial;
  color: #fafafa;
  font-size: 27px;
  padding: 19px;
  text-decoration: none;
}
/* 悬停样式 */
.btn:hover {
  background: #2079b0;
  background-image: -webkit-linear-gradient(top, #2079b0, #eb94d0);
  background-image: -moz-linear-gradient(top, #2079b0, #eb94d0);
  background-image: -ms-linear-gradient(top, #2079b0, #eb94d0);
  background-image: -o-linear-gradient(top, #2079b0, #eb94d0);
  background-image: linear-gradient(to bottom, #2079b0, #eb94d0);
  text-decoration: none;
}

透明背景色

.btn {
      /* 文字颜色 */
      color: #0099CC; 
      /* 清除背景色 */
      background: transparent; 
      /* 边框样式、颜色、宽度 */
      border: 2px solid #0099CC;
      /* 给边框添加圆角 */
      border-radius: 6px; 
      /* 字母转大写 */
      border: none;
      color: white;
      padding: 16px 32px;
      text-align: center;
      display: inline-block;
      font-size: 16px;
      margin: 4px 2px;
      -webkit-transition-duration: 0.4s; /* Safari */
      transition-duration: 0.4s;
      cursor: pointer;
      text-decoration: none;
      text-transform: uppercase;
}
.btn1 {
      background-color: white; 
      color: black; 
      border: 2px solid #008CBA;
}
/* 悬停样式 */
.btn1:hover {
      background-color: #008CBA;
      color: white;
}

应用 CSS Entities

这里是 CSS entities 的详细介绍。

也可以使用 HTML entities，但是只支持部分功能。

.button {
  display: inline-block;
  border-radius: 4px;
  background-color: #f4511e;
  border: none;
  color: #FFFFFF;
  text-align: center;
  font-size: 28px;
  padding: 20px;
  width: 200px;
  transition: all 0.5s;
  cursor: pointer;
  margin: 5px;
}
.button span {
  cursor: pointer;
  display: inline-block;
  position: relative;
  transition: 0.5s;
}
.button span:after {
content: '\00bb';  /* CSS Entities. 如果用的是 HTML Entities, 请改成 →*/
position: absolute;
  opacity: 0;
  top: 0;
  right: -20px;
  transition: 0.5s;
}
.button:hover span {
  padding-right: 25px;
}
.button:hover span:after {
  opacity: 1;
  right: 0;
}

添加点击动画

CSS: (SCSS)

$gray: #bbbbbb;
* {
  font-family: 'Roboto', sans-serif;
}
.container {
  position: absolute;
  top:50%;
  left:50%;
  margin-left: -65px;
  margin-top: -20px;
  width: 130px;
  height: 40px;
  text-align: center;
}
.btn {
      color: #0099CC; /* 文字颜色 */
      background: transparent; /* 清除背景色 */
      border: 2px solid #0099CC; /* 边框样式、颜色、宽度 */
      border-radius: 70px; /* 给边框添加圆角 */
      text-decoration: none;
      text-transform: uppercase; /* 字母转大写 */
      border: none;
      color: white;
      padding: 16px 32px;
      text-align: center;
      text-decoration: none;
      display: inline-block;
      font-size: 16px;
      margin: 4px 2px;
      -webkit-transition-duration: 0.4s; /* 兼容 Safari */
      transition-duration: 0.4s;
      cursor: pointer;
}
.btn1 {
      background-color: white; 
      color: black; 
      border: 2px solid #008CBA;
}
 .btn1:hover {
      background-color: #008CBA;
      color: white;
 }
b {
  outline:none;
  height: 40px;
  text-align: center;
  width: 130px;
  border-radius:100px;
  background: #fff;
  border: 2px solid #008CBA;
  color: #008CBA;
  letter-spacing:1px;
  text-shadow:0;
  font:{
    size:12px;
    weight:bold;
  }
  cursor: pointer;
  transition: all 0.25s ease;
&:active {
    letter-spacing: 2px ;
  }
  &:after {
    content:"";
  }
}
.onclic {
  width: 10px !important;
  height: 70px !important;
  border-radius: 50% !important;
  border-color:$gray;
  border-width:4px;
  font-size:0;
  border-left-color: #008CBA;
  animation: rotating 2s 0.25s linear infinite;
  &:hover {
    color: dodgerblue;
    background: white;
  }
}
.validate {
  content:"";
  font-size:16px;
  color: black;
  background: dodgerblue;
  border-radius: 50px;
  &:after {
    font-family:'FontAwesome';
    content:" done \f00c";
  }
}
@keyframes rotating {
  from {
    transform: rotate(0deg);
  }
  to {
    transform: rotate(360deg);
  }
}

Javascript: (JQuery)

$(function() {
  $("#button").click(function() {
    $("#button").addClass("onclic", 250, validate);
  });
function validate() {
    setTimeout(function() {
      $("#button").removeClass("onclic");
      $("#button").addClass("validate", 450, callback);
    }, 2250);
  }
  function callback() {
    setTimeout(function() {
      $("#button").removeClass("validate");
    }, 1250);
  }
});

图片按钮

.btn {
 background: #92c7eb;
 background-image: url(“http://res.freestockphotos.biz/pictures/15/15107-illustration-of-a-red-close-button-pv.png");
 background-size: cover;
 background-position: center;
 display: inline-block;
 border: none;
 padding: 20px;
 width: 70px;
 border-radius: 900px;
 height: 70px;
 transition: all 0.5s;
 cursor: pointer;
}
.btn:hover
{
 width: 75px;
 height: 75px;
}

Icons 按钮

index.html:

<div class="main"><button class="button" style="vertical-align:middle"><a href="#" class="icon-button twitter"><i class="icon-twitter"></i><span></span></button></a>
  <div class="text"><strong>TWEET!</strong></div>
</div>

Style.css:

button{
  border: none;
  border-radius: 50px;
}
html,
body {
  font-size: 20px;
  min-height: 100%;
  overflow: hidden;
  font-family: "Helvetica Neue", Helvetica, sans-serif;
  text-align: center;
}
.text {
  padding-top: 50px;
  font-family: "Helvetica Neue", Helvetica, 'Lucida Sans Unicode', Geneva, Verdana, sans-serif;
}
.text:hover
{
  cursor: pointer;
  color: #1565C0;
}
.main {
  padding: 0px 0px 0px 0px;
  margin: 0;
  background-image: url("https://someimg");
  text-align: center;
  background-size: 100% !important;
  background-repeat: no-repeat;
  width: 900px;
  height: 700px;  
}
.icon-button {
  background-color: white;
  border-radius: 3.6rem;
  cursor: pointer;
  display: inline-block;
  font-size: 2rem;
  height: 3.6rem;
  line-height: 3.6rem;
  margin: 0 5px;
  position: relative;
  text-align: center;
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
  width: 3.6rem;
}
.icon-button span {
  border-radius: 0;
  display: block;
  height: 0;
  left: 50%;
  margin: 0;
  position: absolute;
  top: 50%;
  -webkit-transition: all 0.3s;
  -moz-transition: all 0.3s;
  -o-transition: all 0.3s;
  transition: all 0.3s;
  width: 0;
}
.icon-button:hover span {
  width: 3.6rem;
  height: 3.6rem;
  border-radius: 3.6rem;
  margin: -1.8rem;
}
.twitter span {
  background-color: #4099ff;
}
/* Icons */
.icon-button i {
  background: none;
  color: white;
  height: 3.6rem;
  left: 0;
  line-height: 3.6rem;
  position: absolute;
  top: 0;
  -webkit-transition: all 0.3s;
  -moz-transition: all 0.3s;
  -o-transition: all 0.3s;
  transition: all 0.3s;
  width: 3.6rem;
  z-index: 10;
}
.icon-button .icon-twitter {
  color: #4099ff;
}
.icon-button:hover .icon-twitter {
  color: white;
}

总结

在这个教程里，我们学习了通过 CSS 和一点 JavaScript（如果需要点击后的效果）来美化 CSS 按钮。也可以使用 CSS3ButtonGenerator 来生成一个简单的按钮。有问题欢迎留言。

原文链接：A quick guide to styling buttons using CSS，作者：Ashwini Sheshagiri

NGINX 于 2004 年基于 2-clause BSD 许可条款首次向公众发布。根据 2021 年 3 月 Web 服务器调查，NGINX 拥有 35.3% 的市场份额，大约有 4.196 亿个站点在使用它。

由于有了 NGINXConfig 这样的的工具以及 DigitalOcean 等互联网上大量线程的配置文件，人们倾向于做大量的复制粘贴，却并不理解这些配置的含义。

相信我，搞懂它并不难......

我并不是说复制代码不好，但在千万不要在不理解的情况下复制代码。

此外，NGINX 是一种软件，应该根据要提供服务的应用程序的要求和主机上的可用资源进行精确配置。

这就是为什么你应该理解并修改你正在复制的内容，而不是盲目地复制——这就是本手册存在的意义。

通读整本书后，你应该能够：

• 理解流行工具生成的配置文件以及各种文档中的配置文件。
• 从头开始将 NGINX 配置为 Web 服务器、反向代理服务器和负载均衡器。
• 优化 NGINX 以获得最大的服务器性能。

先决条件

• 熟悉 Linux 终端和常用 Unix 程序，如 ls、cat、ps、grep、find、nproc、ulimit 和 nano。
• 一台可以运行虚拟机的计算机或 5 美元的虚拟专用服务器。
• 了解 Web 应用程序和编程语言，如 JavaScript 或 PHP。

目录

• NGINX 简介
• 如何安装 NGINX
  • 如何配置本地虚拟机
  • 如何配置虚拟专用服务器
  • 如何在配置的虚拟机或服务器上安装 NGINX
• NGINX 配置文件介绍
• 如何配置基本的 Web 服务器
  • 如何编写你的第一个配置文件
  • 如何校验并重新加载配置文件
  • 如何理解 NGINX 中的指令和上下文
  • 如何使用 NGINX 提供静态内容
  • NGINX 中的静态文件处理
  • 如何引入部分配置文件
• NGINX 的动态路由
  • 位置匹配
  • NGINX 中的变量
  • Redirects 和 Rewrites
  • 如何尝试多个文件
• NGINX 日志
• 如何使用 NGINX 作为反向代理
  • 使用 NGINX 的 Node.js
  • 使用 NGINX 的 PHP
• 如何使用 NGIXN 做为负载均衡器
• 如何优化 NGXIN 以获得最大性能
  • 如何配置工作进程和工作连接
  • 如何缓存静态内容
  • 如何压缩响应
• 如何理解主配置文件
• 高级 NGINX 概念系列
• 表达您的支持
• 尾声

项目代码

你可以在这个仓库中找到示例项目的代码。留一个 ⭐ 让我保持动力。

master 分支包含本书中使用的所有代码。

NGINX 简介

NGINX 是一种高性能网络服务器，旨在满足现代网络日益增长的需求。它专注于高性能、高并发和低资源使用。尽管它通常被称为 Web 服务器，但 NGINX 的核心是一个反向代理 服务器。

不过，NGINX 并不是市场上唯一的 Web 服务器。它最大的竞争对手之一是 Apache HTTP Server (httpd)，它于 1995 年首次发布。尽管 Apache HTTP Server 更灵活，但服务器管理员通常更喜欢 NGINX，有两个主要原因：

• 它可以处理更多的并发请求。
• 它可以在更低资源消耗的前提下更快地交付静态内容。

我不会深入讨论整个 Apache 与 NGINX 的争论。但是，如果你想详细了解它们之间的差异，请参阅 Justin Ellingwood 的这篇出色的文章。

事实上，为了解释 NGINX 的请求处理技术，我想在这里引用 Justin 的文章中的两段：

Nginx 在 Apache 之后出现，更针对的解决大规模站点将面临的并发问题。利用这些知识，Nginx 从头开始设计为使用异步、非阻塞、事件驱动的连接处理算法。

Nginx 产生工作进程，每个进程可以处理数千个连接。工作进程通过实现一个快速轮询机制来实现这一点，该机制不断地检查和处理事件，将实际工作与连接解耦，这允许每个工作进程仅在触发新事件时才关注连接。

如果这看起来有点难以理解，请不要担心。现在对内部工作原理有一个基本的了解就足够了。

NGINX 在静态内容交付方面更快，同时资源相对较少，因为它没有嵌入动态编程语言处理器。当对静态内容的请求到来时，NGINX 只响应文件而不运行任何额外的进程。

这并不意味着 NGINX 不能处理需要动态编程语言处理器的请求。接收到需要动态处理的请求时，NGINX 只是将任务委托给单独的进程，例如 PHP-FPM、[Node.js](https:/ /nodejs.org/) 或 Python。 一旦该进程完成其工作，NGINX 会将响应反向代理回客户端。

NGINX 配置文件语法参考了脚本语言语法，因此很容易配置，可以生成紧凑、易于维护的配置文件。

如何安装 NGINX

在基于 Linux 的系统上安装 NGINX 非常简单。可以使用运行 Ubuntu 的虚拟专用服务器作为你的训练场，也可以使用 Vagrant 在本地系统上配置虚拟机。

大多数情况下，配置本地虚拟机就足够了，这也是我将在本文中使用的方式。

如何配置本地虚拟机

Vagrant 是 Hashicorp 的一个开源工具，它可以使用简单的配置文件配置虚拟机。

要使用这种方式，需要 VirtualBox 和 Vagrant，所以提前先安装它们。如果你需要对该主题进行一些了解，此教程 可能会有所帮助。

在系统中的某处创建一个具有适当名称的工作目录。我的是 ~/vagrant/nginx-handbook 目录。

在工作目录中创建一个名为 Vagrantfile 的文件并输入以下内容：

Vagrant.configure("2") do |config|

    config.vm.hostname = "nginx-handbook-box"
  
    config.vm.box = "ubuntu/focal64"
  
    config.vm.define "nginx-handbook-box"
  
    config.vm.network "private_network", ip: "192.168.20.20"
  
    config.vm.provider "virtualbox" do |vb|
      vb.cpus = 1
      vb.memory = "1024"
      vb.name = "nginx-handbook"
    end
  
  end

这个 Vagrantfile 就是我之前讲的配置文件。它包含虚拟机名称、CPU 数量、RAM 大小、IP 地址等信息。

要使用此配置启动虚拟机，请在工作目录中打开终端并执行以下命令：

vagrant up

# Bringing machine 'nginx-handbook-box' up with 'virtualbox' provider...
# ==> nginx-handbook-box: Importing base box 'ubuntu/focal64'...
# ==> nginx-handbook-box: Matching MAC address for NAT networking...
# ==> nginx-handbook-box: Checking if box 'ubuntu/focal64' version '20210415.0.0' is up to date...
# ==> nginx-handbook-box: Setting the name of the VM: nginx-handbook
# ==> nginx-handbook-box: Clearing any previously set network interfaces...
# ==> nginx-handbook-box: Preparing network interfaces based on configuration...
#     nginx-handbook-box: Adapter 1: nat
#     nginx-handbook-box: Adapter 2: hostonly
# ==> nginx-handbook-box: Forwarding ports...
#     nginx-handbook-box: 22 (guest) => 2222 (host) (adapter 1)
# ==> nginx-handbook-box: Running 'pre-boot' VM customizations...
# ==> nginx-handbook-box: Booting VM...
# ==> nginx-handbook-box: Waiting for machine to boot. This may take a few minutes...
#     nginx-handbook-box: SSH address: 127.0.0.1:2222
#     nginx-handbook-box: SSH username: vagrant
#     nginx-handbook-box: SSH auth method: private key
#     nginx-handbook-box: Warning: Remote connection disconnect. Retrying...
#     nginx-handbook-box: Warning: Connection reset. Retrying...
#     nginx-handbook-box: 
#     nginx-handbook-box: Vagrant insecure key detected. Vagrant will automatically replace
#     nginx-handbook-box: this with a newly generated keypair for better security.
#     nginx-handbook-box: 
#     nginx-handbook-box: Inserting generated public key within guest...
#     nginx-handbook-box: Removing insecure key from the guest if it's present...
#     nginx-handbook-box: Key inserted! Disconnecting and reconnecting using new SSH key...
# ==> nginx-handbook-box: Machine booted and ready!
# ==> nginx-handbook-box: Checking for guest additions in VM...
# ==> nginx-handbook-box: Setting hostname...
# ==> nginx-handbook-box: Configuring and enabling network interfaces...
# ==> nginx-handbook-box: Mounting shared folders...
#     nginx-handbook-box: /vagrant => /home/fhsinchy/vagrant/nginx-handbook

vagrant status

# Current machine states:

# nginx-handbook-box           running (virtualbox)

vagrant up 命令的输出在你的系统上可能会有所不同，但只要 vagrant status 表示机器正在运行，就可以开始了。

鉴于虚拟机现在正在运行，应该能够通过 SSH 进入它。为此，请执行以下命令：

vagrant ssh nginx-handbook-box

# Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-72-generic x86_64)
# vagrant@nginx-handbook-box:~$

如果一切正常，应该登录到虚拟机上，这可以通过终端上的 vagrant@nginx-handbook-box 行看出。

此虚拟机可在本地计算机上的 http://192.168.20.20 上访问。你甚至可以通过在你的 hosts 文件中添加一个条目来为虚拟机分配一个像 http://nginx-handbook.test 这样的自定义域：

# on mac and linux terminal
sudo nano /etc/hosts

# on windows command prompt as administrator
notepad c:\windows\system32\drivers\etc\hosts

现在在文件末尾追加以下行：

nginx-handbook.test    192.168.20.20

现在你应该可以在浏览器中通过 http://nginx-handbook.test URI 访问虚拟机。

可以通过在工作目录中执行以下命令来停止或销毁虚拟机：

# to stop the virtual machine
vagrant halt

# to destroy the virtual machine
vagrant destroy

如果你想了解更多 Vagrant 命令，这个备忘单 可能会派上用场。

现在系统上有一个正常运行的 Ubuntu 虚拟机，接下来要做的就是安装 NGINX。

如何配置虚拟专用服务器

对于本演示，我将使用 Vultr 作为我的供应商，但你可以使用 DigitalOcean 或你喜欢的任何供应商。

假设你已经拥有提供商的帐户，请登录该帐户并部署新服务器：

在 DigitalOcean 上，它通常被称为 droplet。在下一个屏幕上，选择靠近你的节点。我住在孟加拉国，所以我选择新加坡：

在下一步中，必须选择操作系统和服务器配置。选择 Ubuntu 20.04 和尽可能小的服务器配置：

尽管生产服务器往往比这更大更强大，但对于本文来说，一台小型服务器就足够了。

最后，在最后一步，将类似 nginx-handbook-demo-server 之类的东西作为服务器主机和标签。如果必要，甚至可以将它们留空。

一旦对自己的选择感到满意，请继续并按下 Deploy Now 按钮。

部署过程可能需要一些时间才能完成，一旦完成，将在仪表板上看到新创建的服务器：

还要注意 Status – 它应该是 Running 而不是 Preparing 或 Stopped。 要连接到服务器，还需要用户名和密码。

进入服务器的概览页面，应该会看到服务器的 IP 地址、用户名和密码：

使用 SSH 登录服务器的命令如下：

ssh <username>@<ip address>

所以就我的服务器而言，它将是：

ssh root@45.77.251.108

# Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
# Warning: Permanently added '45.77.251.108' (ECDSA) to the list of known hosts.

# root@45.77.251.108's password: 
# Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-65-generic x86_64)

# root@localhost:~#

系统会询问是否要继续连接到此服务器。输入“yes”，然后系统会要求输入密码。从服务器概览页面复制密码并将其粘贴到终端中。

如果做的一切顺利，会成功登录到你的服务器——终端上会看到 root@localhost 行。这里的“localhost”是服务器主机名，你的显示可能会有所不同。

可以通过其 IP 地址直接访问该服务器。或者，如果拥有任何自定义域名，也可以使用它。

在整篇文章中，将看到我将测试域名添加到我的操作系统的 hosts 文件中。如果是真实服务器，则必须使用 DNS 提供商配置这些服务器。

请记住，只要此服务器正在使用，就会被收费。虽然收费应该很少，但我还是要警告你。可以通过点击服务器概览页面上的垃圾桶图标随时销毁服务器：

如果拥有自定义域名，则可以为此服务器分配一个子域名。现在已进入服务器，剩下的就是 安装 NGINX。

如何在配置的服务器或虚拟机上安装 NGINX

假设已登录到服务器或虚拟机，第一件应该做的事就是执行更新。执行以下命令来执行此操作：

sudo apt update && sudo apt upgrade -y

更新后，通过执行以下命令安装 NGINX：

sudo apt install nginx -y

安装完成后，NGINX 应自动注册为 systemd 服务并运行。要检查，请执行以下命令：

sudo systemctl status nginx

# ● nginx.service - A high performance web server and a reverse proxy server
#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
#      Active: active (running)

如果状态显示 running，那么就可以开始了。否则，可以通过执行以下命令来启动服务：

sudo systemctl start nginx

最后，为了直观地验证一切是否正常，请使用喜欢的浏览器访问服务器/虚拟机，应该会看到 NGINX 的默认欢迎页面：

NGINX 通常安装在 /etc/nginx 目录中，我们接下来的大部分工作都将在这里完成。

恭喜！已经在服务器/虚拟机上启动并运行了 NGINX。现在是时候先进入 NGINX 了。

NGINX 的配置文件介绍

作为 Web 服务器，NGINX 的工作是为客户端提供静态或动态内容。但是如何提供这些内容通常由配置文件控制。

NGINX 的配置文件以.conf 扩展名结尾，通常位于/etc/nginx/ 目录中。让我们先通过 cd 进入这个目录并获取所有文件的列表：

cd /etc/nginx

ls -lh

# drwxr-xr-x 2 root root 4.0K Apr 21  2020 conf.d
# -rw-r--r-- 1 root root 1.1K Feb  4  2019 fastcgi.conf
# -rw-r--r-- 1 root root 1007 Feb  4  2019 fastcgi_params
# -rw-r--r-- 1 root root 2.8K Feb  4  2019 koi-utf
# -rw-r--r-- 1 root root 2.2K Feb  4  2019 koi-win
# -rw-r--r-- 1 root root 3.9K Feb  4  2019 mime.types
# drwxr-xr-x 2 root root 4.0K Apr 21  2020 modules-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 modules-enabled
# -rw-r--r-- 1 root root 1.5K Feb  4  2019 nginx.conf
# -rw-r--r-- 1 root root  180 Feb  4  2019 proxy_params
# -rw-r--r-- 1 root root  636 Feb  4  2019 scgi_params
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-enabled
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 snippets
# -rw-r--r-- 1 root root  664 Feb  4  2019 uwsgi_params
# -rw-r--r-- 1 root root 3.0K Feb  4  2019 win-utf

在这些文件中，应该有一个名为 nginx.conf 的文件。这是 NGINX 的主要配置文件。可以使用 cat 程序查看此文件的内容：

cat nginx.conf# user www-data;# worker_processes auto;# pid /run/nginx.pid;# include /etc/nginx/modules-enabled/*.conf;# events {#     worker_connections 768;#     # multi_accept on;# }# http {#     ###     # Basic Settings#     ###     sendfile on;#     tcp_nopush on;#     tcp_nodelay on;#     keepalive_timeout 65;#     types_hash_max_size 2048;#     # server_tokens off;#     # server_names_hash_bucket_size 64;#     # server_name_in_redirect off;#     include /etc/nginx/mime.types;#     default_type application/octet-stream;#     ###     # SSL Settings#     ###     ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE#     ssl_prefer_server_ciphers on;#     ###     # Logging Settings#     ###     access_log /var/log/nginx/access.log;#     error_log /var/log/nginx/error.log;#     ###     # Gzip Settings#     ###     gzip on;#     # gzip_vary on;#     # gzip_proxied any;#     # gzip_comp_level 6;#     # gzip_buffers 16 8k;#     # gzip_http_version 1.1;#     # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;#     ###     # Virtual Host Configs#     ###     include /etc/nginx/conf.d/*.conf;#     include /etc/nginx/sites-enabled/*;# }# #mail {# #    # See sample authentication script at:# #    # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript# # # #    # auth_http localhost/auth.php;# #    # pop3_capabilities "TOP" "USER";# #    # imap_capabilities "IMAP4rev1" "UIDPLUS";# # # #    server {# #        listen     localhost:110;# #        protocol   pop3;# #        proxy      on;# #    }# # # #    server {# #        listen     localhost:143;# #        protocol   imap;# #        proxy      on;# #    }# #}

哇！东西很多。试图在当前状态下理解这个文件将是一场噩梦。因此，让我们备份文件并创建一个新的空文件：

# renames the filesudo mv nginx.conf nginx.conf.backup# creates a new filesudo touch nginx.conf

我强烈不鼓励你编辑原始的 nginx.conf 文件，除非你完全知道你在做什么。出于学习目的，可以重命名以备份它，但是稍后，我将向你展示在真实场景中应该如何配置服务器。

如何配置基本 Web 服务器

在本书的这一部分中，将最终通过从头开始配置一个基本的静态 Web 服务器来动手实践。本节的目的是向你介绍 NGINX 配置文件的语法和基本概念。

如何编写你的第一个配置文件

首先使用 nano 文本编辑器打开新创建的 nginx.conf 文件：

sudo nano /etc/nginx/nginx.conf

在整本书中，我将使用 nano 作为我的文本编辑器。如果你愿意，可以使用更流行的编辑器，但在现实生活场景中，你最有可能在服务器上使用 nano 或 [vim](https: //www.vim.org/) ，而不是其他任何东西。因此，请以本书为契机，提高你的 Nano 技能。此外，官方备忘单 随时供你参考。

打开文件后，将其内容更新为：

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        return 200 "Bonjour, mon ami!\n";    }}

如果你有构建 REST API 的经验，那么你可能会从 return 200 "Bonjour, mon ami!\n"; 行已经看出来服务器已配置状态代码 200 的消息“Bonjour, mon ami ！”。

如果你目前一头雾水，请不要担心，我将逐行解释这个文件，但首先让我们看看这个配置的实际效果。

如何校验并重新加载配置文件

编写新配置文件或更新旧配置文件后，首先要做的是检查文件是否存在语法错误。nginx 二进制文件包含一个选项 -t 来做到这一点。

sudo nginx -t# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok# nginx: configuration file /etc/nginx/nginx.conf test is successful

如果有任何语法错误，此命令将会展示错误信息以及出错的行号。

虽然配置文件没问题，但 NGINX 配置并不会立即生效。NGINX 的工作方式是它读取一次配置文件并在此基础上持续工作。

如果更新配置文件，则必须明确指示 NGINX 重新加载配置文件。有两种方法可以做到这一点。

• 可以通过执行 sudo systemctl restart nginx 命令来重启 NGINX 服务。
• 可以通过执行 sudo nginx -s reload 命令向 NGINX 发送 reload 信号。

-s 选项用于向 NGINX 发送各种信号。可用的信号是 stop、quit、reload 和 reopen。在我刚刚提到的两种方式中，我更喜欢第二种方式，因为它打字较少。

一旦通过执行 nginx -s reload 命令重新加载了配置文件，就可以通过向服务器发送一个简单的 get 请求来查看它的运行情况：

curl -i http://nginx-handbook.test# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 10:03:33 GMT# Content-Type: text/plain# Content-Length: 18# Connection: keep-alive# Bonjour, mon ami!

服务器响应状态代码 200 以及预期的消息。恭喜你走到这一步！现在是解释的时候了。

如何理解 NGINX 中的指令和上下文

在这里编写的几行代码虽然看似简单，但却介绍了 NGINX 配置文件的两个最重要的术语。它们是指令和上下文。

从技术上讲，NGINX 配置文件中的所有内容都是 ** 指令**。指令有两种类型：

• 简单指令
• 块指令

一个简单的指令由指令名称和空格分隔的参数组成，如 listen、return 等。简单指令以分号结束。

块指令类似于简单指令，不同之处在于它们不是以分号结尾，而是以一对花括号 {} 括起的附加指令。

能够在其中包含其他指令的块指令称为上下文，即 events、http 等。NGINX 中有四个核心上下文：

• events { } – events 上下文用于设置关于 NGINX 如何在一般级别处理请求的全局配置。一个有效的配置文件中只能有一个 events 上下文。
• http { } – 顾名思义，http 上下文用于定义有关服务器将如何处理 HTTP 和 HTTPS 请求的配置。一个有效的配置文件中只能有一个 http 上下文。
• server { } – server 上下文嵌套在 http 上下文中，用于在单个主机内配置特定的虚拟服务器。在嵌套在 http 上下文中的有效配置文件中可以有多个 server 上下文。每个“服务器”上下文都被认为是一个虚拟主机。
• main – main 上下文是配置文件本身。在前面提到的三个上下文之外编写的任何内容都在 main上下文中。

可以将 NGINX 中的上下文视为其他编程语言中的作用域。它们之间也有一种继承关系。可以在官方 NGINX 文档中找到指令的字母索引。

我已经提到在一个配置文件中可以有多个 server 上下文。但是当请求到达服务器时，NGINX 如何知道哪一个上下文中应该处理请求？

listen 指令是在配置中识别正确的 server 上下文的方法之一。考虑以下场景：

http {    server {        listen 80;        server_name nginx-handbook.test;        return 200 "hello from port 80!\n";    }    server {        listen 8080;        server_name nginx-handbook.test;        return 200 "hello from port 8080!\n";    }}

现在，如果向 http://nginx-handbook.test:80 发送请求，那么将收到“hello from port 80!” 响应。如果向 http://nginx-handbook.test:8080 发送请求，将收到“hello from port 8080!” 响应：

curl nginx-handbook.test:80# hello from port 80!curl nginx-handbook.test:8080# hello from port 8080!

这两个服务器块就像两个人拿着电话听筒，等待指定电话号码呼入时响应。它们的电话号码由 listen 指令指示。

除了listen 指令，还有 server_name 指令。考虑以下虚构图书馆管理应用程序的场景：

http {    server {        listen 80;        server_name library.test;        return 200 "your local library!\n";    }    server {        listen 80;        server_name librarian.library.test;        return 200 "welcome dear librarian!\n";    }}

这是虚拟主机思想的一个基本例子。正在同一台服务器中以不同的服务器名称运行两个单独的应用程序。

如果向 http://library.test 发送请求，那么将获得 “your local library!” 响应。如果向 http://librarian.library.test 发送请求，将收到 “welcome dear librarian!” 响应。

curl http://library.test

# your local library!

curl http://librarian.library.test

# welcome dear librarian!

为了让这个演示在你的系统上运行，你必须更新你的 hosts 文件使其包含这两个域名：

192.168.20.20   library.test
192.168.20.20   librarian.library.test

最后，return 指令负责向用户返回一个有效的响应。该指令包含两个参数：状态代码和要返回的字符串消息。

如何使用 NGINX 提供静态内容

现在已经很好地了解了如何为 NGINX 编写基本配置文件，让我们升级配置以提供静态文件而不是纯文本响应。

为了提供静态内容，首先必须将它们存储在服务器上的某个位置。如果你使用 ls 列出服务器根目录下的文件和目录，会在那里找到一个名为 /srv 的目录：

ls -lh /

# lrwxrwxrwx   1 root    root       7 Apr 16 02:10 bin -> usr/bin
# drwxr-xr-x   3 root    root    4.0K Apr 16 02:13 boot
# drwxr-xr-x  16 root    root    3.8K Apr 21 09:23 dev
# drwxr-xr-x  92 root    root    4.0K Apr 21 09:24 etc
# drwxr-xr-x   4 root    root    4.0K Apr 21 08:04 home
# lrwxrwxrwx   1 root    root       7 Apr 16 02:10 lib -> usr/lib
# lrwxrwxrwx   1 root    root       9 Apr 16 02:10 lib32 -> usr/lib32
# lrwxrwxrwx   1 root    root       9 Apr 16 02:10 lib64 -> usr/lib64
# lrwxrwxrwx   1 root    root      10 Apr 16 02:10 libx32 -> usr/libx32
# drwx------   2 root    root     16K Apr 16 02:15 lost+found
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 media
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 mnt
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 opt
# dr-xr-xr-x 152 root    root       0 Apr 21 09:23 proc
# drwx------   5 root    root    4.0K Apr 21 09:59 root
# drwxr-xr-x  26 root    root     820 Apr 21 09:47 run
# lrwxrwxrwx   1 root    root       8 Apr 16 02:10 sbin -> usr/sbin
# drwxr-xr-x   6 root    root    4.0K Apr 16 02:14 snap
# drwxr-xr-x   2 root    root    4.0K Apr 16 02:10 srv
# dr-xr-xr-x  13 root    root       0 Apr 21 09:23 sys
# drwxrwxrwt  11 root    root    4.0K Apr 21 09:24 tmp
# drwxr-xr-x  15 root    root    4.0K Apr 16 02:12 usr
# drwxr-xr-x   1 vagrant vagrant   38 Apr 21 09:23 vagrant
# drwxr-xr-x  14 root    root    4.0K Apr 21 08:34 var

这个/srv 目录旨在包含由该系统提供的特定于站点的数据。现在 cd 进入这个目录并克隆本书附带的代码库：

cd /srvsudo git clone https://github.com/fhsinchy/nginx-handbook-projects.git

在 nginx-handbook-projects 目录中应该有一个名为 static-demo 的目录，总共包含四个文件：

ls -lh /srv/nginx-handbook-projects/static-demo# -rw-r--r-- 1 root root 960 Apr 21 11:27 about.html# -rw-r--r-- 1 root root 960 Apr 21 11:27 index.html# -rw-r--r-- 1 root root 46K Apr 21 11:27 mini.min.css# -rw-r--r-- 1 root root 19K Apr 21 11:27 the-nginx-handbook.jpg

现在有了要提供的静态内容，请按如下方式更新配置：

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;    }}

代码几乎相同，除了 return 指令现在已被替换为 root 指令。该指令用于声明站点的根目录。

通过编写 root /srv/nginx-handbook-projects/static-demo 告诉 NGINX 在有任何请求时在这个服务器的 /srv/nginx-handbook-projects/static-demo 目录中查找要提供的文件。由于 NGINX 是一个 Web 服务器，它非常聪明，可以默认为 index.html 文件提供服务。

让我们看看这是否有效。测试并重新加载更新的配置文件并访问服务器，应该会看到一个不完整的 HTML 站点：

尽管 NGINX 已正确提供 index.html 文件，但从三个导航链接的外观来看，似乎 CSS 代码不起作用。

你可能认为 CSS 文件中有问题。但实际上，问题出在配置文件中。

NGINX 中的静态文件类型处理

要调试现在面临的问题，向服务器发送 CSS 文件的请求：

curl -I http://nginx-handbook/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:17:16 GMT
# Content-Type: text/plain
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

注意 Content-Type 并查看展示 text/plain 而不是 text/css。这意味着 NGINX 将此文件作为纯文本而不是样式表提供。

尽管 NGINX 足够聪明，默认情况下可以找到 index.html 文件，但在解释文件类型时它非常愚蠢。要解决此问题，再次更新配置：

events {

}

http {

    types {
        text/html html;
        text/css css;
    }

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;
    }
}

我们对代码所做的唯一更改是嵌套在 http 块中的新 types 上下文。可能已经从名称中猜到，此上下文用于配置文件类型。

通过在此上下文中编写 text/html html，你告诉 NGINX 将任何以 html 扩展名结尾的文件解析为 text/html。

可能认为配置 CSS 文件类型就足够了，因为 HTML 已经被很好地解析——但并非如此。

如果在配置中引入 types 上下文，NGINX 会变得更加笨拙，只会解析你配置的文件。因此，如果只在此上下文中定义了 text/css css，那么 NGINX 将开始将 HTML 文件解析为纯文本。

验证并重新加载新更新的配置文件并再次访问服务器。再次发送对 CSS 文件的请求，这次文件应该被解析为 text/css 文件了：

curl -I http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:29:35 GMT
# Content-Type: text/css
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

访问服务器进行视觉验收，这次站点应该看起来更好：

如果已正确更新并重新加载配置文件，但仍看到旧站点，请执行强制刷新。

如何引入部分配置文件

在 types 上下文中映射文件类型可能适用于小型项目，但对于较大的项目，它可能很麻烦且容易出错。

NGINX 为这个问题提供了解决方案。如果你再次列出 /etc/nginx 目录中的文件，会看到一个名为 mime.types 的文件。

ls -lh /etc/nginx

# drwxr-xr-x 2 root root 4.0K Apr 21  2020 conf.d
# -rw-r--r-- 1 root root 1.1K Feb  4  2019 fastcgi.conf
# -rw-r--r-- 1 root root 1007 Feb  4  2019 fastcgi_params
# -rw-r--r-- 1 root root 2.8K Feb  4  2019 koi-utf
# -rw-r--r-- 1 root root 2.2K Feb  4  2019 koi-win
# -rw-r--r-- 1 root root 3.9K Feb  4  2019 mime.types
# drwxr-xr-x 2 root root 4.0K Apr 21  2020 modules-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 modules-enabled
# -rw-r--r-- 1 root root 1.5K Feb  4  2019 nginx.conf
# -rw-r--r-- 1 root root  180 Feb  4  2019 proxy_params
# -rw-r--r-- 1 root root  636 Feb  4  2019 scgi_params
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-available
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 sites-enabled
# drwxr-xr-x 2 root root 4.0K Apr 17 14:42 snippets
# -rw-r--r-- 1 root root  664 Feb  4  2019 uwsgi_params
# -rw-r--r-- 1 root root 3.0K Feb  4  2019 win-utf

我们来看看这个文件的内容：

cat /etc/mime.types

# types {
#     text/html                             html htm shtml;
#     text/css                              css;
#     text/xml                              xml;
#     image/gif                             gif;
#     image/jpeg                            jpeg jpg;
#     application/javascript                js;
#     application/atom+xml                  atom;
#     application/rss+xml                   rss;

#     text/mathml                           mml;
#     text/plain                            txt;
#     text/vnd.sun.j2me.app-descriptor      jad;
#     text/vnd.wap.wml                      wml;
#     text/x-component                      htc;

#     image/png                             png;
#     image/tiff                            tif tiff;
#     image/vnd.wap.wbmp                    wbmp;
#     image/x-icon                          ico;
#     image/x-jng                           jng;
#     image/x-ms-bmp                        bmp;
#     image/svg+xml                         svg svgz;
#     image/webp                            webp;

#     application/font-woff                 woff;
#     application/java-archive              jar war ear;
#     application/json                      json;
#     application/mac-binhex40              hqx;
#     application/msword                    doc;
#     application/pdf                       pdf;
#     application/postscript                ps eps ai;
#     application/rtf                       rtf;
#     application/vnd.apple.mpegurl         m3u8;
#     application/vnd.ms-excel              xls;
#     application/vnd.ms-fontobject         eot;
#     application/vnd.ms-powerpoint         ppt;
#     application/vnd.wap.wmlc              wmlc;
#     application/vnd.google-earth.kml+xml  kml;
#     application/vnd.google-earth.kmz      kmz;
#     application/x-7z-compressed           7z;
#     application/x-cocoa                   cco;
#     application/x-java-archive-diff       jardiff;
#     application/x-java-jnlp-file          jnlp;
#     application/x-makeself                run;
#     application/x-perl                    pl pm;
#     application/x-pilot                   prc pdb;
#     application/x-rar-compressed          rar;
#     application/x-redhat-package-manager  rpm;
#     application/x-sea                     sea;
#     application/x-shockwave-flash         swf;
#     application/x-stuffit                 sit;
#     application/x-tcl                     tcl tk;
#     application/x-x509-ca-cert            der pem crt;
#     application/x-xpinstall               xpi;
#     application/xhtml+xml                 xhtml;
#     application/xspf+xml                  xspf;
#     application/zip                       zip;

#     application/octet-stream              bin exe dll;
#     application/octet-stream              deb;
#     application/octet-stream              dmg;
#     application/octet-stream              iso img;
#     application/octet-stream              msi msp msm;

#     application/vnd.openxmlformats-officedocument.wordprocessingml.document    docx;
#     application/vnd.openxmlformats-officedocument.spreadsheetml.sheet          xlsx;
#     application/vnd.openxmlformats-officedocument.presentationml.presentation  pptx;

#     audio/midi                            mid midi kar;
#     audio/mpeg                            mp3;
#     audio/ogg                             ogg;
#     audio/x-m4a                           m4a;
#     audio/x-realaudio                     ra;

#     video/3gpp                            3gpp 3gp;
#     video/mp2t                            ts;
#     video/mp4                             mp4;
#     video/mpeg                            mpeg mpg;
#     video/quicktime                       mov;
#     video/webm                            webm;
#     video/x-flv                           flv;
#     video/x-m4v                           m4v;
#     video/x-mng                           mng;
#     video/x-ms-asf                        asx asf;
#     video/x-ms-wmv                        wmv;
#     video/x-msvideo                       avi;
# }

该文件包含一长串文件类型及其扩展名。要在配置文件中使用此文件，请将配置更新为如下所示：

events {

}

http {

    include /etc/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-projects/static-demo;
    }

}

旧的 types 上下文现在已替换为新的 include 指令。顾名思义，该指令允许包含来自其他配置文件的内容。

验证并重新加载配置文件并再次发送对 mini.min.css 文件的请求：

curl -I http://nginx-handbook.test/mini.min.css

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 12:29:35 GMT
# Content-Type: text/css
# Content-Length: 46887
# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT
# Connection: keep-alive
# ETag: "60800c0a-b727"
# Accept-Ranges: bytes

在下面关于如何理解主配置文件的部分中，我将演示如何使用 include 来模块化虚拟服务器配置。

NGINX 中的动态路由

在上一节中编写的配置是一个非常简单的静态内容服务器配置。它所做的只是匹配来自与客户端访问的 URI 相对应的站点根目录的文件并进行响应。

因此，如果客户端请求根目录中存在文件，例如 index.html、about.html 或 mini.min.css，NGINX 将返回该文件。但是，如果访问诸如 http://nginx-handbook.test/nothing 之类的路由，它将以默认的 404 页面响应：

在本书的这一部分，将了解 location 上下文、变量、重定向、重写和 try_files 指令。本节中不会有新项目，但在此处学习的概念将在接下来的部分中必不可少。

此外，本节中的配置更改非常频繁，因此请不要忘记在每次更新后验证并重新加载配置文件。

位置匹配

我们将在本节中讨论的第一个概念是 location 上下文。更新配置如下：

events {

}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        location /agatha {
            return 200 "Miss Marple.\nHercule Poirot.\n";
        }
    }
}

我们已经用新的 location 上下文替换了 root 指令。这个上下文通常嵌套在 server 块中。server 上下文中可以有多个 location 上下文。

如果向 http://nginx-handbook.test/agatha 发送请求，将获得 200 响应代码和 Agatha Christie 创建的字符列表。

curl -i http://nginx-handbook.test/agatha

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Wed, 21 Apr 2021 15:59:07 GMT
# Content-Type: text/plain
# Content-Length: 29
# Connection: keep-alive

# Miss Marple.
# Hercule Poirot.

现在，如果向 http://nginx-handbook.test/agatha-christie 发送请求，将得到相同的响应：

curl -i http://nginx-handbook.test/agatha-christie# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 15:59:07 GMT# Content-Type: text/plain# Content-Length: 29# Connection: keep-alive# Miss Marple.# Hercule Poirot.

发生这种情况是因为，通过编写 location /agatha，告诉 NGINX 匹配任何以“agatha”开头的 URI。这种匹配称为前缀匹配。

要执行完全匹配，必须按如下方式更新代码：

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        location = /agatha {            return 200 "Miss Marple.\nHercule Poirot.\n";        }    }}

在位置 URI 之前添加一个 = 符号将指示 NGINX 只有在 URL 完全匹配时才响应。现在，如果向除 /agatha 之外的任何内容发送请求，都将收到 404 响应。

curl -I http://nginx-handbook.test/agatha-christie# HTTP/1.1 404 Not Found# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:14:29 GMT# Content-Type: text/html# Content-Length: 162# Connection: keep-alivecurl -I http://nginx-handbook.test/agatha# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:15:04 GMT# Content-Type: text/plain# Content-Length: 29# Connection: keep-alive

NGINX 中的另一种匹配是 regex 匹配。使用此匹配，可以根据复杂的正则表达式检查 URL location。

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        location ~ /agatha[0-9] {        	return 200 "Miss Marple.\nHercule Poirot.\n";        }    }}

通过将之前使用的 = 符号替换为 ~ 符号，来告诉 NGINX 执行正则表达式匹配。将 location 设置为 ~ /agatha[0-9] 意味着 NIGINX 只有在单词“agatha”后面有数字时才会响应：

curl -I http://nginx-handbook.test/agatha# HTTP/1.1 404 Not Found# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:14:29 GMT# Content-Type: text/html# Content-Length: 162# Connection: keep-alivecurl -I http://nginx-handbook.test/agatha8# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:15:04 GMT# Content-Type: text/plain# Content-Length: 29# Connection: keep-alive

默认情况下，正则表达式匹配区分大小写，这意味着如果将任何字母大写，则该 location 将不起作用：

curl -I http://nginx-handbook.test/Agatha8# HTTP/1.1 404 Not Found# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:14:29 GMT# Content-Type: text/html# Content-Length: 162# Connection: keep-alive

要将其转换为不区分大小写，必须在 ~ 符号后添加一个 *。

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        location ~* /agatha[0-9] {        	return 200 "Miss Marple.\nHercule Poirot.\n";        }    }}

这将告诉 NGINX 大小写不敏感匹配 location。

curl -I http://nginx-handbook.test/agatha8# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:15:04 GMT# Content-Type: text/plain# Content-Length: 29# Connection: keep-alivecurl -I http://nginx-handbook.test/Agatha8# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Wed, 21 Apr 2021 16:15:04 GMT# Content-Type: text/plain# Content-Length: 29# Connection: keep-alive

NGINX 为这些匹配分配优先级值，正则匹配比前缀匹配具有更高的优先级。

events {}http {    server {        listen 80;        server_name nginx-handbook.test;		location /Agatha8 {        	return 200 "prefix matched.\n";        }                location ~* /agatha[0-9] {        	return 200 "regex matched.\n";        }    }}

现在，如果向 http://nginx-handbook.test/Agatha8 发送请求，将得到以下响应：

curl -i http://nginx-handbook.test/Agatha8# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Thu, 22 Apr 2021 08:08:18 GMT# Content-Type: text/plain# Content-Length: 15# Connection: keep-alive# regex matched.

但是这个优先级可以稍微改变。NGINX 中的最后一种匹配类型是优先前缀匹配。要将前缀匹配转换为优先匹配，需要在位置 URI 之前包含 ^~ 修饰符：

events {}http {    server {        listen 80;        server_name nginx-handbook.test;		location ^~ /Agatha8 {        	return 200 "prefix matched.\n";        }                location ~* /agatha[0-9] {        	return 200 "regex matched.\n";        }    }}

现在，如果向 http://nginx-handbook.test/Agatha8 发送请求，将得到以下响应：

curl -i http://nginx-handbook.test/Agatha8# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Thu, 22 Apr 2021 08:13:24 GMT# Content-Type: text/plain# Content-Length: 16# Connection: keep-alive# prefix matched.

这一次，前缀匹配优先。所以按优先级降序排列的所有匹配列表如下：

NGINX 中的变量

NGINX 中的变量和其他编程语言中的变量类似。set 指令可用于在配置文件中的任何位置声明新变量：

set $<variable_name> <variable_value>;# set name "Farhan"# set age 25# set is_working true

变量可以是三种类型

• 字符串
• 整数
• 布尔值

除了声明的变量之外，NGINX 模块中还有内置的变量。 变量的字母索引 可在官方文档中找到。

要查看一些正在运行的变量，按如下方式更新配置：

events {}http {    server {        listen 80;        server_name nginx-handbook.test;        return 200 "Host - $host\nURI - $uri\nArgs - $args\n";    }}

现在向服务器发送请求后，会得到如下响应：

# curl http://nginx-handbook.test/user?name=Farhan# Host - nginx-handbook.test# URI - /user# Args - name=Farhan

如你所见，$host 和 $uri 变量分别保存根地址和相对于根的请求 URI。如你所见，$args 变量包含所有查询字符串。

可以使用 $arg 变量访问各个值，而不是打印查询字符串的文字字符串形式。

events {}http {    server {        listen 80;        server_name nginx-handbook.test;                set $name $arg_name; # $arg_<query string name>        return 200 "Name - $name\n";    }}

现在来自服务器的响应应该如下所示：

curl http://nginx-handbook.test?name=Farhan# Name - Farhan

我在这里演示的变量嵌入在 ngx_http_core_module 中。要在配置中访问变量，必须使用嵌入变量的模块构建 NGINX。从源代码构建 NGINX 并使用动态模块稍微超出了本文的范围，但我肯定会在我的博客中写到这一点。

Redirects 和 Rewrites

NGINX 中的重定向与任何其他平台中的重定向相同。要演示重定向的工作原理，请将配置更新为如下所示：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;        location = /index_page {                return 307 /index.html;        }        location = /about_page {                return 307 /about.html;        }    }}

现在，如果向 http://nginx-handbook.test/about_page 发送请求，将被重定向到 http://nginx-handbook.test/about.html：

curl -I http://nginx-handbook.test/about_page# HTTP/1.1 307 Temporary Redirect# Server: nginx/1.18.0 (Ubuntu)# Date: Thu, 22 Apr 2021 18:02:04 GMT# Content-Type: text/html# Content-Length: 180# Location: http://nginx-handbook.test/about.html# Connection: keep-alive

如你所见，服务器响应状态码为 307，位置指示 http://nginx-handbook.test/about.html 。 如果你从浏览器访问 http://nginx-handbook.test/about_page ， 会看到 URL 将自动更改为 http://nginx-handbook.test/about.html 。

然而，rewrite 指令的工作方式略有不同。 它在内部更改 URI，而不让用户知道。要查看它的实际效果，请按如下方式更新配置：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;        rewrite /index_page /index.html;        rewrite /about_page /about.html;    }}

现在，如果向 http://nginx-handbook/about_page URI 发送请求，将响应 200 响应码的 about.html 文件：

curl -i http://nginx-handbook.test/about_page# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Thu, 22 Apr 2021 18:09:31 GMT# Content-Type: text/html# Content-Length: 960# Last-Modified: Wed, 21 Apr 2021 11:27:06 GMT# Connection: keep-alive# ETag: "60800c0a-3c0"# Accept-Ranges: bytes# <!DOCTYPE html># <html lang="en"># <head>#     <meta charset="UTF-8">#     <meta http-equiv="X-UA-Compatible" content="IE=edge">#     <meta name="viewport" content="width=device-width, initial-scale=1.0">#     <title>NGINX Handbook Static Demo</title>#     <link rel="stylesheet" href="mini.min.css">#     <style>#         .container {#             max-width: 1024px;#             margin-left: auto;#             margin-right: auto;#         }# #         h1 {#             text-align: center;#         }#     </style># </head># <body class="container">#     <header>#         <a class="button" href="index.html">Index</a>#         <a class="button" href="about.html">About</a>#         <a class="button" href="nothing">Nothing</a>#     </header>#     <div class="card fluid">#         <img src="./the-nginx-handbook.jpg" alt="The NGINX Handbook Cover Image">#     </div>#     <div class="card fluid">#         <h1>this is the <strong>about.html</strong> file</h1>#     </div># </body># </html>

如果使用浏览器访问 URI，将看到 about.html 页面，而 URL 保持不变：

除了处理 URI 更改的方式之外，重定向和重写之间还有另一个区别。当重写发生时，NGINX 会重新评估 server 上下文。因此，重写是比重定向更昂贵的操作。

如何尝试多个文件

本节要展示的最后一个概念是 try_files 指令。try_files 指令不是响应单个文件，而是一次检查存在的多个文件。

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;        try_files /the-nginx-handbook.jpg /not_found;        location /not_found {                return 404 "sadly, you've hit a brick wall buddy!\n";        }    }}

如你所见，添加了一个新的 try_files 指令。通过编写try_files /the-nginx-handbook.jpg /not_found;，可以指示NGINX 在收到请求时在根目录中查找名为 the-nginx-handbook.jpg 的文件。如果它不存在，则转到 /not_found 位置。

所以现在如果你访问服务器，你会看到图像：

但是，如果更新配置以尝试使用不存在的文件（例如 blackhole.jpg），将收到 404 响应并显示消息“sadly, you've hit a brick wall buddy!”。

现在用这种方式写一个 try_files 指令的问题是，无论你访问什么 URL，只要服务器收到一个请求并且在磁盘上找到了 -nginx-handbook.jpg 文件，NGINX 就会返回它。

这就是为什么 try_files 经常与 $uri NGINX 变量一起使用的原因。

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;        try_files $uri /not_found;        location /not_found {                return 404 "sadly, you've hit a brick wall buddy!\n";        }    }}

通过编写 try_files $uri /not_found;，在指示 NGINX 首先尝试获取客户端请求的 URI。如果它没有找到，则尝试下一个。

所以现在如果你访问 http://nginx-handbook.test/index.html 应该得到旧的 index.html 页面。about.html 页面也是如此：

但是如果你请求一个不存在的文件，会得到 /not_found location 的响应：

curl -i http://nginx-handbook.test/nothing# HTTP/1.1 404 Not Found# Server: nginx/1.18.0 (Ubuntu)# Date: Thu, 22 Apr 2021 20:01:57 GMT# Content-Type: text/plain# Content-Length: 38# Connection: keep-alive# sadly, you've hit a brick wall buddy!

可能已经注意到的一件事是，如果访问服务器根目录 http://nginx-handbook.test，会收到 404 响应。

这是因为当访问服务器根目录时，$uri 变量不对应任何现有文件作为 NGINX 备选 location。如果要解决此问题，请按如下方式更新配置：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        root /srv/nginx-handbook-projects/static-demo;        try_files $uri $uri/ /not_found;        location /not_found {                return 404 "sadly, you've hit a brick wall buddy!\n";        }    }}

通过写 try_files $uri $uri//not_found;，指示 NGINX 首先尝试请求 URI。如果不存在，则尝试将请求的 URI 作为目录，并且每当 NGINX 最终进入目录时，它会自动开始查找 index.html 文件。

现在如果访问服务器，应该得到 index.html 文件：

try_files 是一种可用于多种变体的指令。在接下来的部分中，会遇到一些其他变体，但我建议在 Internet 上自行研究该指令的不同用法。

NGINX 日志

默认情况下，NGINX 的日志文件位于/var/log/nginx 中。 如果列出这个目录的内容，可能会看到如下内容：

ls -lh /var/log/nginx/# -rw-r----- 1 www-data adm     0 Apr 25 07:34 access.log# -rw-r----- 1 www-data adm     0 Apr 25 07:34 error.log

让我们先清空这两个文件。

# delete the old filessudo rm /var/log/nginx/access.log /var/log/nginx/error.log# create new filessudo touch /var/log/nginx/access.log /var/log/nginx/error.log# reopen the log filessudo nginx -s reopen

如果不向 NGINX 发送 reopen 信号，它将继续将日志写入先前打开的流，而新文件将保持为空。

现在要在访问日志中创建一个条目，向服务器发送一个请求。

curl -I http://nginx-handbook.test# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Sun, 25 Apr 2021 08:35:59 GMT# Content-Type: text/html# Content-Length: 960# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT# Connection: keep-alive# ETag: "608529d5-3c0"# Accept-Ranges: bytessudo cat /var/log/nginx/access.log # 192.168.20.20 - - [25/Apr/2021:08:35:59 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.68.0"

如你所见，access.log 文件中添加了一个新条目。默认情况下，对服务器的任何请求都将记录到此文件中。我们可以使用 access_log 指令来改变这种行为。

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;                location / {            return 200 "this will be logged to the default file.\n";        }                location = /admin {            access_log /var/logs/nginx/admin.log;                        return 200 "this will be logged in a separate file.\n";        }                location = /no_logging {            access_log off;                        return 200 "this will not be logged.\n";        }    }}

/admin location 块中的第一个 access_log 指令指示 NGINX 将此 URI 的任何访问日志写入 /var/logs/nginx/admin.log 文件。 第二个 /no_logging location 中的完全关闭此 location 的访问日志。

验证并重新加载配置。现在，如果向这些位置发送请求并检查日志文件，应该会看到如下内容：

curl http://nginx-handbook.test/no_logging# this will not be loggedsudo cat /var/log/nginx/access.log# emptycurl http://nginx-handbook.test/admin# this will be logged in a separate file.sudo cat /var/log/nginx/access.log# emptysudo cat /var/log/nginx/admin.log # 192.168.20.20 - - [25/Apr/2021:11:13:53 +0000] "GET /admin HTTP/1.1" 200 40 "-" "curl/7.68.0"curl  http://nginx-handbook.test/# this will be logged to the default file.sudo cat /var/log/nginx/access.log # 192.168.20.20 - - [25/Apr/2021:11:15:14 +0000] "GET / HTTP/1.1" 200 41 "-" "curl/7.68.0"

另一方面，error.log 文件保存失败日志。 要进入 error.log，必须使 NGINX crash。为此，请按如下方式更新配置：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;        return 200 "..." "...";    }}

如你所知，return 指令只接受两个参数——但我们在这里给出了三个。现在尝试重新加载配置，将看到一条错误消息：

sudo nginx -s reload# nginx: [emerg] invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

检查错误日志的内容，消息也应该出现在那里：

sudo cat /var/log/nginx/error.log # 2021/04/25 08:35:45 [notice] 4169#4169: signal process started# 2021/04/25 10:03:18 [emerg] 8434#8434: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:14

错误消息有级别。错误日志中的 notice 条目是代表日志记录的信息是无关紧要的，但必须立即处理 emerg 或 crit 条目。

有八个级别的错误消息：

• debug – 有助于确定问题所在的有用调试信息。
• info - 不需要阅读但可能很好了解的信息性消息。
• notice - 发生了一些值得注意的正常现象。
• warn - 发生了意外，但不必担心。
• error - 某些事情不成功。
• crit - 存在急需解决的问题。
• alert - 需要迅速采取行动。
• emerg - 系统处于无法使用的状态，需要立即关注。

默认情况下，NGINX 记录所有级别的消息。 可以使用 error_log 指令覆盖此行为。如果要将消息的最低级别设置为warn，请按如下方式更新配置文件：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx-handbook.test;	    	error_log /var/log/error.log warn;        return 200 "..." "...";    }}

验证并重新加载配置，从现在开始，只会记录级别为 warn 或更高级别的消息。

cat /var/log/nginx/error.log# 2021/04/25 11:27:02 [emerg] 12769#12769: invalid number of arguments in "return" directive in /etc/nginx/nginx.conf:16

与之前的输出不同，这里没有“通知”条目。emerg 是比 warn 更高级别的错误，这就是它被记录的原因。

对于大多数项目，保留错误配置应该没问题。我唯一的建议是将最小错误级别设置为 warn。这样就不必查看错误日志中不必要的条目。

但是，如果想了解有关在 NGINX 中自定义日志记录的更多信息，此官方文档的 链接 可能会有所帮助。

如何使用 NGINX 作为反向代理

当配置为反向代理时，NGINX 位于客户端和后端服务器之间。客户端向 NGINX 发送请求，然后 NGINX 将请求传递给后端。

后端服务器处理完请求后，将其发送回 NGINX。反过来，NGINX 将响应返回给客户端。

在整个过程中，客户端不知道谁在实际处理请求。写起来听起来很复杂，但一旦你自己动手，你就会发现 NGINX 让反向代理变的多么容易。

让我们看一个非常基本且不切实际的反向代理示例：

events {}http {    include /etc/nginx/mime.types;    server {        listen 80;        server_name nginx.test;        location / {                proxy_pass "https://nginx.org/";        }    }}

除了验证和重新加载配置之外，还必须将此地址添加到的 hosts 文件中，以使此演示在你的系统上运行：

192.168.20.20   nginx.test

现在，如果访问 http://nginx.test，将看到原始的 https://nginx.org 站点，而 URI 保持不变。

甚至能够在一定程度上浏览网站。如果访问 http://nginx.test/en/docs/ 应该得到 http://nginx.org/en/docs/ 页面的响应。

如你所见，在基本层面上，proxy_pass 指令只是将客户端的请求传递给第三方服务器，并将响应反向代理到客户端。

使用 NGINX 的 Node.js

现在已经知道如何配置基本的反向代理服务器，可以为 NGINX 反向代理的 Node.js 应用程序提供服务。我在本文附带的代码仓库中添加了一个演示应用程序。

我假设你有使用 Node.js 的经验并且知道如何使用 PM2 启动 Node.js 应用程序。

如果你已经在 /srv/nginx-handbook-projects 中克隆了存储库，那么 node-js-demo 项目应该在 /srv/nginx-handbook-projects/node-js-demo 目录中。

为了运行这个 demo，需要在你的服务器上安装 Node.js。 可以按照 此处 找到的说明执行此操作。

演示应用程序是一个简单的 HTTP 服务器，它响应 200 状态代码和 JSON 有效负载。可以通过简单地执行 node app.js 来启动应用程序，但更好的方法是使用 PM2。

PM2 是一个守护进程管理器，广泛用于 Node.js 应用程序的生产。如果想了解更多信息，此链接 可能会有所帮助。

通过执行 sudo npm install -g pm2 全局安装 PM2。安装完成后，在/srv/nginx-handbook-projects/node-js-demo目录下执行以下命令：

pm2 start app.js# [PM2] Process successfully started# ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐# │ id │ name               │ mode     │ ↺    │ status    │ cpu      │ memory   │# ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤# │ 0  │ app                │ fork     │ 0    │ online    │ 0%       │ 21.2mb   │# └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

或者，也可以从服务器上的任何位置执行 pm2 start /srv/nginx-handbook-projects/node-js-demo/app.js。可以通过执行 pm2 stop app 命令来停止应用程序。

应用程序现在应该正在运行，但不应从服务器外部访问。要验证应用程序是否正在运行，请从服务器内部向 http://localhost:3000 发送 get 请求：

curl -i localhost:3000# HTTP/1.1 200 OK# X-Powered-By: Express# Content-Type: application/json; charset=utf-8# Content-Length: 62# ETag: W/"3e-XRN25R5fWNH2Tc8FhtUcX+RZFFo"# Date: Sat, 24 Apr 2021 12:09:55 GMT# Connection: keep-alive# Keep-Alive: timeout=5# { "status": "success", "message": "You're reading The NGINX Handbook!" }

如果收到 200 响应，则服务器运行成功。现在要将 NGINX 配置为反向代理，请打开配置文件并按如下方式更新其内容：

events {}  http {    listen 80;    server_name nginx-handbook.test    location / {        proxy_pass http://localhost:3000;    }}

这里没啥需要解释的。只是将接收到的请求传递给在端口 3000 上运行的 Node.js 应用程序。现在，如果从外部向服务器发送请求，应该得到如下响应：

curl -i http://nginx-handbook.test# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Sat, 24 Apr 2021 14:58:01 GMT# Content-Type: application/json# Transfer-Encoding: chunked# Connection: keep-alive# { "status": "success", "message": "You're reading The NGINX Handbook!" }

尽管这适用于像这样的基本服务器，但可能需要添加更多指令才能使其在实际场景中工作，具体取决于应用程序的要求。

例如，如果应用程序处理 Web socket 连接，那么应该按如下方式更新配置：

events {}  http {    listen 80;    server_name nginx-handbook.test    location / {        proxy_pass http://localhost:3000;        proxy_http_version 1.1;        proxy_set_header Upgrade $http_upgrade;        proxy_set_header Connection 'upgrade';    }}

proxy_http_version 指令设置服务器的 HTTP 版本。 默认情况下它是 1.0，但 web socket 要求它至少是 1.1。 proxy_set_header 指令用于在后端服务器上设置标头。该指令的通用语法如下：

proxy_set_header <header name> <header value>

因此，通过编写proxy_set_header Upgrade $http_upgrade;，是在指示 NGINX 将$http_upgrade 变量的值作为名为Upgrade 的标头传递——与Connection 标头相同。

如果你想了解更多关于 web socket 代理的信息，这个指向官方 NGINX 文档的链接 可能会有所帮助。

根据的应用程序所需的标头，可能需要设置更多标头。但是上面提到的配置在配置 Node.js 应用程序时非常常见。

使用 NGINX 的 PHP

PHP 和 NGINX 就像面包和黄油一样。毕竟 LEMP 技术栈中的 E 和 P 就代表 NGINX 和 PHP。

这里假设你有使用 PHP 的经验并且知道如何运行 PHP 应用程序。

我已经在本文附带的代码仓库中包含了一个演示 PHP 应用程序。如果你已经在/srv/nginx-handbook-projects 目录中克隆了它，那么应用程序应该在/srv/nginx-handbook-projects/php-demo 中。

为了让这个演示运行，你必须安装一个名为 PHP-FPM 的包。要安装软件包，可以执行以下命令：

sudo apt install php-fpm -y

要测试应用程序，请通过在 /srv/nginx-handbook-projects/php-demo` 目录中执行以下命令来启动 PHP 服务：

php -S localhost:8000# [Sat Apr 24 16:17:36 2021] PHP 7.4.3 Development Server (http://localhost:8000) started

或者，也可以从服务器上的任何位置执行 php -S localhost:8000 /srv/nginx-handbook-projects/php-demo/index.php。

该应用程序应该在端口 8000 上运行，但无法从服务器外部访问它。要进行验证，请从服务器内部向 http://localhost:8000 发送 get 请求：

curl -I localhost:8000# HTTP/1.1 200 OK# Host: localhost:8000# Date: Sat, 24 Apr 2021 16:22:42 GMT# Connection: close# X-Powered-By: PHP/7.4.3# Content-type: application/json# {"status":"success","message":"You're reading The NGINX Handbook!"}

如果你收到 200 响应，则服务器运行成功。就像 Node.js 配置一样，现在可以简单地将请求 proxy_pass 发送到 localhost:8000 – 但是对于 PHP，有更好的方法。

PHP-FPM 中的 FPM 部分代表 FastCGI Process Module。FastCGI 是一种类似于 HTTP 的协议，用于交换二进制数据。此协议比 HTTP 稍快，并提供更好的安全性。

To use FastCGI instead of HTTP, update your configuration as follows:

要使用 FastCGI 而不是 HTTP，请按如下方式更新配置：

events {}http {      include /etc/nginx/mime.types;      server {          listen 80;          server_name nginx-handbook.test;          root /srv/nginx-handbook-projects/php-demo;          index index.php;          location / {              try_files $uri $uri/ =404;          }          location ~ \.php$ {              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;              fastcgi_param REQUEST_METHOD $request_method;              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;      }   }}

让我们从新的 index 指令开始。如你所知，NGINX 默认会查找 index.html 文件来提供服务。但在演示项目中，它是 index.php。因此，编写 index index.php，指示NGINX 以 root 用户身份使用 index.php 文件。

该指令可以接受多个参数。对于 index index.php index.html，NGINX 会首先寻找 index.php。如果它没有找到这个文件，它会寻找 index.html 文件。

第一个 location 上下文中的 try_files 指令与在上一节中看到的相同。最后的 =404 表示如果没有找到任何文件则抛出错误。

第二个 location 块是魔法发生的地方。如你所见，我们已经用新的 fastcgi_pass 替换了 proxy_pass 指令。顾名思义，它用于将请求传递给 FastCGI 服务。

PHP-FPM 服务默认运行在主机的 9000 端口上。因此，可以直接将请求传递给 http://localhost:9000，而不是像我在这里所做的那样使用 Unix 套接字。但是使用 Unix 套接字更安全。

如果安装了多个 PHP-FPM 版本，则可以通过执行以下命令简单地列出所有套接字文件位置：

sudo find / -name *fpm.sock# /run/php/php7.4-fpm.sock# /run/php/php-fpm.sock# /etc/alternatives/php-fpm.sock# /var/lib/dpkg/alternatives/php-fpm.sock

/run/php/php-fpm.sock 文件是指系统上安装的最新版本的 PHP-FPM。我更喜欢使用带有版本号的那个。这样即使 PHP-FPM 得到更新，我也可以知道我正在使用的版本。

与通过 HTTP 传递请求不同，通过 FPM 传递请求需要我们传递一些额外的信息。

将额外信息传递给 FPM 服务的一般方法是使用 fastcgi_param 指令。至少，必须将请求方法和脚本名称传递给后端服务才能使代理工作。

fastcgi_param REQUEST_METHOD $request_method; 将请求方法传递给后端，fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; 行传递要运行的 PHP 脚本的确切位置。

在这种状态下，配置应该可以工作。要测试它，请访问服务器，应该会看到如下内容：

嗯，这很奇怪。500 错误意味着 NGINX 由于某种原因崩溃了。这是错误日志可以派上用场的地方。让我们看看 error.log 文件中的最后一个条目：

tail -n 1 /var/log/nginx/error.log# 2021/04/24 17:15:17 [crit] 17691#17691: *21 connect() to unix:/var/run/php/php7.4-fpm.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.20.20, server: nginx-handbook.test, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "nginx-handbook.test"

似乎 NGINX 进程没有访问 PHP-FPM 进程的权限。

获得权限被拒绝错误的主要原因之一是用户不匹配。 查看拥有 NGINX 工作进程的用户。

ps aux | grep nginx# root         677  0.0  0.4   8892  4260 ?        Ss   14:31   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;# nobody     17691  0.0  0.3   9328  3452 ?        S    17:09   0:00 nginx: worker process# vagrant    18224  0.0  0.2   8160  2552 pts/0    S+   17:19   0:00 grep --color=auto nginx

如你所见，该进程当前归 nobody 所有。 现在检查 PHP-FPM 进程。

# ps aux | grep php# root       14354  0.0  1.8 195484 18924 ?        Ss   16:11   0:00 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)# www-data   14355  0.0  0.6 195872  6612 ?        S    16:11   0:00 php-fpm: pool www# www-data   14356  0.0  0.6 195872  6612 ?        S    16:11   0:00 php-fpm: pool www# vagrant    18296  0.0  0.0   8160   664 pts/0    S+   17:20   0:00 grep --color=auto php

另一方面，此进程由 www-data 用户拥有。这就是 NGINX 被拒绝访问此进程的原因。

要解决此问题，请按如下方式更新配置：

user www-data;events {}http {      include /etc/nginx/mime.types;      server {          listen 80;          server_name nginx-handbook.test;          root /srv/nginx-handbook-projects/php-demo;          index index.php;          location / {              try_files $uri $uri/ =404;          }          location ~ \.php$ {              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;              fastcgi_param REQUEST_METHOD $request_method;              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;      }   }}

user 指令负责设置 NGINX 工作进程的所有者。现在再次检查 NGINX 进程：

# ps aux | grep nginx# root         677  0.0  0.4   8892  4264 ?        Ss   14:31   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;# www-data   20892  0.0  0.3   9292  3504 ?        S    18:10   0:00 nginx: worker process# vagrant    21294  0.0  0.2   8160  2568 pts/0    S+   18:18   0:00 grep --color=auto nginx

毫无疑问，该进程现在归 www-data 用户所有。向服务器发送请求以检查它是否正常工作：

# curl -i http://nginx-handbook.test# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Sat, 24 Apr 2021 18:22:24 GMT# Content-Type: application/json# Transfer-Encoding: chunked# Connection: keep-alive# {"status":"success","message":"You're reading The NGINX Handbook!"}

如果收到带有 JSON 有效负载的 200 状态代码，那么就可以开始了。

这种简单的配置适用于演示应用程序，但在实际项目中，必须传递一些额外的参数。

出于这个原因，NGINX 包含一个名为 fastcgi_params 的部分配置。该文件包含最常见的 FastCGI 参数列表。

cat /etc/nginx/fastcgi_params# fastcgi_param  QUERY_STRING       $query_string;# fastcgi_param  REQUEST_METHOD     $request_method;# fastcgi_param  CONTENT_TYPE       $content_type;# fastcgi_param  CONTENT_LENGTH     $content_length;# fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;# fastcgi_param  REQUEST_URI        $request_uri;# fastcgi_param  DOCUMENT_URI       $document_uri;# fastcgi_param  DOCUMENT_ROOT      $document_root;# fastcgi_param  SERVER_PROTOCOL    $server_protocol;# fastcgi_param  REQUEST_SCHEME     $scheme;# fastcgi_param  HTTPS              $https if_not_empty;# fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;# fastcgi_param  SERVER_SOFTWARE    nginx/$nginx_version;# fastcgi_param  REMOTE_ADDR        $remote_addr;# fastcgi_param  REMOTE_PORT        $remote_port;# fastcgi_param  SERVER_ADDR        $server_addr;# fastcgi_param  SERVER_PORT        $server_port;# fastcgi_param  SERVER_NAME        $server_name;# PHP only, required if PHP was built with --enable-force-cgi-redirect# fastcgi_param  REDIRECT_STATUS    200;

如你所见，此文件还包含 REQUEST_METHOD 参数。可以在配置中包含此文件，而不是手动传递它：

user www-data;events {}http {      include /etc/nginx/mime.types;      server {          listen 80;          server_name nginx-handbook.test;          root /srv/nginx-handbook-projects/php-demo;          index index.php;          location / {              try_files $uri $uri/ =404;          }          location ~ \.php$ {              fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;              fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;              include /etc/nginx/fastcgi_params;      }   }}

服务应该表现得一样。除了 fastcgi_params 文件，可能还会遇到包含一组稍微不同的参数的 fastcgi.conf 文件。我建议你避免这种情况发生，因为它与它的行为有些不一致。

如何使用 NGINX 作为负载均衡器

由于 NGINX 的反向代理设计，可以轻松地将其配置为负载均衡器。

我已经在本文附带的代码仓库库中添加了一个演示。如果你已经在 /srv/nginx-handbook-projects/ 目录中克隆了代码仓库，那么演示应该在 /srv/nginx-handbook-projects/load-balancer-demo/ 目录中。

在现实生活中，分布在多个服务器上的大型项目可能需要负载均衡。但是对于这个简单的演示，我创建了三个非常简单的 Node.js 服务，响应服务编号和 200 状态代码。

为了让这个演示工作，你需要在服务器上安装 Node.js。可以在此链接 中找到说明以帮助你安装它。

除此之外，还需要 PM2 来守护本演示中提供的 Node.js 服务。

如果还没有安装，请通过执行 sudo npm install -g pm2 来安装 PM2。安装完成后，执行以下命令启动三个 Node.js 服务：

pm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-1.jspm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-2.jspm2 start /srv/nginx-handbook-projects/load-balancer-demo/server-3.jspm2 list# ┌────┬────────────────────┬──────────┬──────┬───────────┬──────────┬──────────┐# │ id │ name               │ mode     │ ↺    │ status    │ cpu      │ memory   │# ├────┼────────────────────┼──────────┼──────┼───────────┼──────────┼──────────┤# │ 0  │ server-1           │ fork     │ 0    │ online    │ 0%       │ 37.4mb   │# │ 1  │ server-2           │ fork     │ 0    │ online    │ 0%       │ 37.2mb   │# │ 2  │ server-3           │ fork     │ 0    │ online    │ 0%       │ 37.1mb   │# └────┴────────────────────┴──────────┴──────┴───────────┴──────────┴──────────┘

三个 Node.js 服务应该分别运行在 localhost:3001、localhost:3002、localhost:3003 上。

现在更新配置如下：

events {}http {    upstream backend_servers {        server localhost:3001;        server localhost:3002;        server localhost:3003;    }    server {        listen 80;        server_name nginx-handbook.test;        location / {            proxy_pass http://backend_servers;        }    }}

server 上下文中的配置与已经看到的相同。但是，upstream上下文是新的。NGINX 中的 upstream 是一组可以被视为单个后端的服务器。

所以你开始使用 PM2 启动的三台服务器可以放在一个 upstream，可以让 NGINX 均衡它们之间的负载。

要测试配置，必须向服务器发送大量请求。可以使用 bash 中的 while 循环自动执行该过程：

while sleep 0.5; do curl http://nginx-handbook.test; done# response from server - 2.# response from server - 3.# response from server - 1.# response from server - 2.# response from server - 3.# response from server - 1.# response from server - 2.# response from server - 3.# response from server - 1.# response from server - 2.

可以通过按键盘上的 Ctrl + C 来取消循环。从服务器的响应中可以看出，NGINX 正在自动对服务器进行负载均衡。

当然，更大的项目规模，负载均衡可能比这复杂得多。但本文的目的是让你入门，相信你现在对 NGINX 负载均衡有了基本的了解。 你可以通过执行 pm2 stop server-1 server-2 server-3 命令来停止三个正在运行的服务器（建议如此）。

如何优化 NGINX 以获得最大性能

在本文的这一部分中，将了解使服务器获得最大性能的多种方法。

其中一些方法是特定于应用程序的，这意味着它们可能需要根据你的应用程序要求进行调整。但其中一些是普适的优化手段。

就像前几节一样，在这一节中配置更改会很频繁，所以不要忘记每次验证和重新加载配置文件。

如何配置工作进程和工作连接

正如我在上一节中已经提到的，NGINX 可以产生多个工作进程，每个进程能够处理数千个请求。

sudo systemctl status nginx# ● nginx.service - A high performance web server and a reverse proxy server#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 5h 45min ago#        Docs: man:nginx(8)#    Main PID: 3904 (nginx)#       Tasks: 2 (limit: 1136)#      Memory: 3.2M#      CGroup: /system.slice/nginx.service#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;#              └─16443 nginx: worker process

如你所见，现在系统上只有一个 NGINX 工作进程。但是，可以通过对配置文件更改此数字。

worker_processes 2;events {}http {    server {        listen 80;        server_name nginx-handbook.test;        return 200 "worker processes and worker connections configuration!\n";    }}

在 main 上下文中编写的 worker_process 指令负责设置要生成的工作进程的数量。现在再次检查 NGINX 服务，你应该会看到两个工作进程：

sudo systemctl status nginx# ● nginx.service - A high performance web server and a reverse proxy server#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 5h 54min ago#        Docs: man:nginx(8)#     Process: 22610 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)#    Main PID: 3904 (nginx)#       Tasks: 3 (limit: 1136)#      Memory: 3.7M#      CGroup: /system.slice/nginx.service#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;#              ├─22611 nginx: worker process#              └─22612 nginx: worker process

设置工作进程的数量很容易，但确定工作进程的最佳数量需要更多的工作。

工作进程本质上是异步的。这意味着它们将尽可能快地处理传入的请求。

现在假设你的服务器在单核处理器上运行。如果将工作进程数设置为 1，则该单个进程将使用 100% 的 CPU 容量。 但是如果将其设置为 2，则两个进程将能够分别使用 50% 的 CPU。所以增加工作进程的数量并不意味着更好的性能。

确定最佳工作进程数的经验法则是 工作进程数 = CPU 内核数。

如果你在具有双核 CPU 的服务器上运行，则应将工作进程数设置为 2。在四核中，应将其设置为 4...明白了吧。

在 Linux 上可以用如下命令确定服务器上的 CPU 数量。

nproc# 1

我在单 CPU 虚拟机上运行，所以 nproc 检测到有一个 CPU。既然已经知道了 CPU 的数量，剩下要做的就是在配置中设置数量。

这一切都很好，但是每次升级服务器并且 CPU 数量发生变化时，都必须手动更新服务器配置。

NGINX 提供了一种更好的方法来处理这个问题。可以简单地将工作进程的数量设置为 auto，NGINX 将根据 CPU 的数量自动设置进程的数量。

worker_processes auto;events {}http {    server {        listen 80;        server_name nginx-handbook.test;        return 200 "worker processes and worker connections configuration!\n";    }}

再次检查 NGINX 进程：

sudo systemctl status nginx# ● nginx.service - A high performance web server and a reverse proxy server#      Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)#      Active: active (running) since Sun 2021-04-25 08:33:11 UTC; 6h ago#        Docs: man:nginx(8)#     Process: 22610 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=0/SUCCESS)#    Main PID: 3904 (nginx)#       Tasks: 2 (limit: 1136)#      Memory: 3.2M#      CGroup: /system.slice/nginx.service#              ├─ 3904 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;#              └─23659 nginx: worker process

工作进程的数量又恢复为 1，因为这是该服务器的最佳选择。

除了工作进程之外，还有工作连接，表示单个工作进程可以处理的最大连接数。

就像工作进程的数量一样，这个数字也与 CPU 核心数量以及操作系统每个核心允许打开的文件数量有关。

在 Linux 上用这个命令查看这个数字：

ulimit -n# 1024

现在有了这个数字，接下来在配置中设置它：

worker_processes auto;

events {
    worker_connections 1024;
}

http {

    server {

        listen 80;
        server_name nginx-handbook.test;

        return 200 "worker processes and worker connections configuration!\n";
    }
}

worker_connections 指令负责设置配置中的工作连接数。这也是第一次使用 events 上下文。

在上一节中，我提到此上下文用于设置 NGINX 在一般级别上使用的值。工作连接配置就是这样的一个例子。

如何缓存静态内容

优化服务器的第二种技术是缓存静态内容。无论使用哪种应用程序，总会提供一定数量的静态内容，例如样式表、图像等。

考虑到这些内容不太可能经常更改，最好将它们缓存一段时间。NGINX 实现起来很简单。

worker_processes auto;

events {
    worker_connections 1024;
}

http {

    include /env/nginx/mime.types;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-demo/static-demo;
        
        location ~* \.(css|js|jpg)$ {
            access_log off;
            
            add_header Cache-Control public;
            add_header Pragma public;
            add_header Vary Accept-Encoding;
            expires 1M;
        }
    }
}

通过编写location ~* .(css|js|jpg)$，指示 NGINX 匹配请求以 .css、.js 和 .jpg 结尾的文件。

在我的应用程序中，即使用户提交不同的格式，我通常也以 WebP 格式存储图像。这样，配置静态缓存对我来说变得更加容易。

可以使用 add_header 指令在对客户端的响应中包含一个标头。之前你已经看到了 proxy_set_header 指令，用于在对后端服务器的持续请求中设置标头。另一方面，add_header 指令仅将给定的标头添加到响应中。

通过将 Cache-Control 标头设置为 public，告诉客户端这个内容可以以任何方式缓存。Pragma 标头只是一个旧版本的 Cache-Control 标头并且或多或少地做了相同的事情。

下一个标头 Vary 负责让客户端知道这个缓存的内容可能会有所不同。

Accept-Encoding 的值意味着内容可能会根据客户端接受的内容编码而有所不同。这将在下一节中进一步阐明。

最后，expires 指令可以方便地设置 Expires 标头 expires 指令占用此缓存有效的持续时间。通过将其设置为“1M”，告诉 NGINX 将内容缓存一个月。 还可以将其设置为 10m 10 minutes、24h 24 hours，等等。

现在要测试配置，从服务器发送对 nginx-handbook.jpg 文件的请求：

curl -I http://nginx-handbook.test/the-nginx-handbook.jpg

# HTTP/1.1 200 OK
# Server: nginx/1.18.0 (Ubuntu)
# Date: Sun, 25 Apr 2021 15:58:22 GMT
# Content-Type: image/jpeg
# Content-Length: 19209
# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT
# Connection: keep-alive
# ETag: "608529d5-4b09"
# Expires: Tue, 25 May 2021 15:58:22 GMT
# Cache-Control: max-age=2592000
# Cache-Control: public
# Pragma: public
# Vary: Accept-Encoding
# Accept-Ranges: bytes

如你所见，标头已添加到响应中，任何主流浏览器都应该能够解释它们。

如何压缩响应

要展示的最后一种优化技术非常简单：压缩响应以减小其大小。

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include /env/nginx/mime.types;

    gzip on;
    gzip_comp_level 3;

    gzip_types text/css text/javascript;

    server {

        listen 80;
        server_name nginx-handbook.test;

        root /srv/nginx-handbook-demo/static-demo;
        
        location ~* \.(css|js|jpg)$ {
            access_log off;
            
            add_header Cache-Control public;
            add_header Pragma public;
            add_header Vary Accept-Encoding;
            expires 1M;
        }
    }
}

GZIP 是一种流行的文件格式，被应用程序用于文件压缩和解压缩。NGINX 可以使用 gzip 指令利用这种格式压缩响应。

通过在 http 上下文中编写 gzip on，可以指示 NGINX 压缩响应。 gzip_comp_level 指令设置压缩级别。可以将其设置为非常高的数字，但这并不能保证更好的压缩。设置 1 - 4 之间的数字可提供有效的结果。例如，我喜欢将其设置为 3。

默认情况下，NGINX 压缩 HTML 响应。 要压缩其他文件格式，必须将它们作为参数传递给 gzip_types 指令。 通过编写gzip_types text/css text/javascript;，告诉 NGINX 使用 text/css 和 text/javascript 的 mime 类型压缩任何文件。

在 NGINX 中配置压缩是不够的。客户端必须请求压缩响应而不是未压缩响应。我希望你记得上一节关于缓存的 add_header Vary Accept-Encoding; 行。 此标头让客户端知道响应可能会根据客户端接受的内容而有所不同。

例如，如果想从服务器请求未压缩版本的 mini.min.css 文件，可以执行以下操作：

curl -I http://nginx-handbook.test/mini.min.css# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Sun, 25 Apr 2021 16:30:32 GMT# Content-Type: text/css# Content-Length: 46887# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT# Connection: keep-alive# ETag: "608529d5-b727"# Expires: Tue, 25 May 2021 16:30:32 GMT# Cache-Control: max-age=2592000# Cache-Control: public# Pragma: public# Vary: Accept-Encoding# Accept-Ranges: bytes

如你所见，没有开启压缩的。现在，如果你想请求文件的压缩版本，则必须发送额外的标头。

curl -I -H "Accept-Encoding: gzip" http://nginx-handbook.test/mini.min.css# HTTP/1.1 200 OK# Server: nginx/1.18.0 (Ubuntu)# Date: Sun, 25 Apr 2021 16:31:38 GMT# Content-Type: text/css# Last-Modified: Sun, 25 Apr 2021 08:35:33 GMT# Connection: keep-alive# ETag: W/"608529d5-b727"# Expires: Tue, 25 May 2021 16:31:38 GMT# Cache-Control: max-age=2592000# Cache-Control: public# Pragma: public# Vary: Accept-Encoding# Content-Encoding: gzip

正如你在响应头中看到的，Content-Encoding 现在被设置为 gzip，这意味着这是文件的压缩版本。

现在，如果要比较文件大小的差异，可以执行以下操作：

cd ~mkdir compression-test && cd compression-testcurl http://nginx-handbook.test/mini.min.css > uncompressed.csscurl -H "Accept-Encoding: gzip" http://nginx-handbook.test/mini.min.css > compressed.cssls -lh# -rw-rw-r-- 1 vagrant vagrant 9.1K Apr 25 16:35 compressed.css# -rw-rw-r-- 1 vagrant vagrant  46K Apr 25 16:35 uncompressed.css

该文件的未压缩版本为“46K”，压缩版本为“9.1K”，几乎小六倍。线上的站点样式表会的更大，压缩可以使响应文件更小、响应速度更快。

如何理解主配置文件

我希望你记得你在前面部分重命名的原始 nginx.conf 文件。根据 Debian wiki，这个文件应该由 NGINX 维护者而不是服务器管理员来更改，除非他们确切地知道他们在做什么。

是在整篇文章中，我已经教你在这个文件中配置服务器。在本节中，我将介绍如何在不更改 nginx.conf 文件的情况下配置服务器。

首先，首先删除或重命名修改后的 nginx.conf 文件并恢复原来的文件：

sudo rm /etc/nginx/nginx.confsudo mv /etc/nginx/nginx.conf.backup /etc/nginx/nginx.confsudo nginx -s reload

现在 NGINX 应该回到它的原始状态。让我们通过执行 sudo cat /etc/nginx/nginx.conf 文件再次查看该文件的内容：

user www-data;worker_processes auto;pid /run/nginx.pid;include /etc/nginx/modules-enabled/*.conf;events {	worker_connections 768;	# multi_accept on;}http {	##	# Basic Settings	##	sendfile on;	tcp_nopush on;	tcp_nodelay on;	keepalive_timeout 65;	types_hash_max_size 2048;	# server_tokens off;	# server_names_hash_bucket_size 64;	# server_name_in_redirect off;	include /etc/nginx/mime.types;	default_type application/octet-stream;	##	# SSL Settings	##	ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE	ssl_prefer_server_ciphers on;	##	# Logging Settings	##	access_log /var/log/nginx/access.log;	error_log /var/log/nginx/error.log;	##	# Gzip Settings	##	gzip on;	# gzip_vary on;	# gzip_proxied any;	# gzip_comp_level 6;	# gzip_buffers 16 8k;	# gzip_http_version 1.1;	# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;	##	# Virtual Host Configs	##	include /etc/nginx/conf.d/*.conf;	include /etc/nginx/sites-enabled/*;}#mail {#	# See sample authentication script at:#	# http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript# #	# auth_http localhost/auth.php;#	# pop3_capabilities "TOP" "USER";#	# imap_capabilities "IMAP4rev1" "UIDPLUS";# #	server {#		listen     localhost:110;#		protocol   pop3;#		proxy      on;#	}# #	server {#		listen     localhost:143;#		protocol   imap;#		proxy      on;#	}#}

现在应该能够看懂此文件。在主上下文 user www-data; 中，worker_processes auto; 行已经介绍过，不在赘述。

pid /run/nginx.pid; 行设置 NGINX 进程的进程 ID，include /etc/nginx/modules-enabled/*.conf; 引入 /etc/nginx/ modules-enabled/ 目录的配置文件。

该目录用于存放 NGINX 动态模块。我在本文中没有涉及动态模块，所以我将跳过它。

现在在 http 上下文中，在基本设置下，可以看到一些常用的优化技术。以下是这些技术的作用：

• sendfile on; 禁用静态文件的缓冲。
• tcp_nopush on; 允许在一个数据包中发送响应头。
• tcp_nodelay on; 禁用 Nagle's Algorithm 导致更快的静态文件传输。

keepalive_timeout 指令指示保持连接打开的时间，types_hash_maxsize 指令设置类型哈希映射的大小。 默认情况下，它还包括 mime.types 文件。

我将跳过 SSL 设置，因为我不打算在本文介绍它们。我们已经讨论了日志记录和 gzip 设置。 可能会看到一些关于 gzip 的指令的注释内容。只要你了解自己在做什么，就可以自定义这些设置。

可以使用 mail 上下文将 NGINX 配置为邮件服务器。到目前为止，我们只讨论了 NGINX 作为 Web 服务器，所以我也将跳过这一点。

现在在虚拟主机设置下，应该看到如下两行：

### Virtual Host Configs##include /etc/nginx/conf.d/*.conf;include /etc/nginx/sites-enabled/*;

这两行指示 NGINX 引入在 /etc/nginx/conf.d/ 和 /etc/nginx/sites-enabled/ 目录中找到的所有配置文件。

看到这两行后，人们往往会把这两个目录作为放置配置文件的理想位置，但这是不对的。

还有另一个目录 /etc/nginx/sites-available/ 用于存储虚拟主机的配置文件。/etc/nginx/sites-enabled/ 目录用于存储指向 /etc/nginx/sites-available/ 目录中文件的符号链接。

实际上有一个示例配置：

ln -lh /etc/nginx/sites-enabled/# lrwxrwxrwx 1 root root 34 Apr 25 08:33 default -> /etc/nginx/sites-available/default

如你所见，该目录包含指向 /etc/nginx/sites-available/default 文件的符号链接。

思路是在 /etc/nginx/sites-available/ 目录中写入多个虚拟主机，并通过给他们创建到 /etc/nginx/sites-enabled/ 目录的符号链接来激活它。

为了演示这个概念，让我们配置一个简单的静态服务器。首先，删除默认的虚拟主机符号链接，在进程中停用这个配置：

sudo rm /etc/nginx/sites-enabled/defaultls -lh /etc/nginx/sites-enabled/# lrwxrwxrwx 1 root root 41 Apr 25 18:01 nginx-handbook -> /etc/nginx/sites-available/nginx-handbook

通过执行 sudo touch /etc/nginx/sites-available/nginx-handbook 创建一个新文件，并将输入以下内容：

server {    listen 80;    server_name nginx-handbook.test;    root /srv/nginx-handbook-projects/static-demo;}

/etc/nginx/sites-available/ 目录中的文件包含在 main http 上下文中，因此它们应该只包含 server 块。

现在通过执行以下命令在 /etc/nginx/sites-enabled/ 目录中创建一个指向此文件的符号链接：

sudo ln -s /etc/nginx/sites-available/nginx-handbook /etc/nginx/sites-enabled/nginx-handbookls -lh /etc/nginx/sites-enabled/# lrwxrwxrwx 1 root root 34 Apr 25 08:33 default -> /etc/nginx/sites-available/default# lrwxrwxrwx 1 root root 41 Apr 25 18:01 nginx-handbook -> /etc/nginx/sites-available/nginx-handbook

在验证和重新加载配置文件之前，必须重新打开日志文件。否则，可能会收到权限拒绝错误。发生这种情况的原因是因为这次交换旧的 nginx.conf 文件导致进程 ID 不同。

sudo rm /var/log/nginx/*.logsudo touch /var/log/nginx/access.log /var/log/nginx/error.logsudo nginx -s reopen

最后，验证并重新加载配置文件：

sudo nginx -t# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok# nginx: configuration file /etc/nginx/nginx.conf test is successfulsudo nginx -s reload

访问服务器，应该会看到最初的 The NGINX 手册页面：

如果已经正确配置了服务器并且仍然看到旧的 NGINX 欢迎页面，请执行硬刷新。浏览器通常会缓存旧的静态资源，需要做进行一些清理。

高级 NGINX 概念系列

服务器配置是一个很大的话题，本文的目的是让你了解 NGINX 的基础知识。还有一些重要和高级的主题没讲。

我计划在我的博客上写一些文章来解释诸如配置 HTTP2 协议、FastCGI 微缓存、速率限制、SSL 证书签名、动态模块等主题。

这样，该系列将成为易于参考且面向对基础有适当了解的人的文章集合。

所以请密切关注 https://farhan.info/ 。我希望在 2 或 3 周内发布第一篇文章。

表达你的支持

除了这本手册之外，我还编写了一些复杂主题的手册，例如 Docker 容器化 和 Kubernetes 的服务器编排 都可以在 freeCodeCamp News 上免费获得。

这些手册是我以简化晦涩技术为使命的成果。每本手册都需要花费大量的时间和精力来编写。

如果你喜欢我的写作并想让我保持动力，可以考虑在 GitHub 上 star，并在 [LinkedIn](https://www. linkedin.com/in/farhanhasin/) 认可我的相关技能。

我也愿意接受建议和讨论。在 Twitter 上关注我，并通过社交软件或 电子邮件 联系我。

最后，考虑与他人分享资源，因为

分享知识是友谊最基本的行为。因为这是一种你可以给予一些东西而不会失去一些东西的方式。 — 理查德·斯托曼

尾声

我衷心感谢你花时间阅读本文。我希望你享受你的学习时间并学习了 NGINX 的所有基本知识。

如果你喜欢我的作品，你可以在 https://www.freecodecamp.org/news/author/farhanhasin/ 上找到我的其他书籍，个人博客 https://www.farhan.info/ 同步更新。

你可以在 Twitter 上关注我 @frhnhsin 或在 LinkedIn 上与我联系 /in/farhanhasin 。

原文：The NGINX Handbook，作者：Farhan Hasin Chowdhury

无论你是否了解，cookie 随处可见，它们彻底改变了我们使用网络的方式。

在本文中，我们将介绍 cookie 的历史、它们的工作方式、如何在 JavaScript 中使用它们以及需要熟知的一些安全隐患。

cookies 简史

HTTP 超文本传输协议是一种无状态协议。根据 Wikipedia，它之所以无状态，是因为它“不需要 HTTP 服务器在不同请求期间保留用户的信息或状态”。

今天，网站服务依然是如此实现的 – 输入浏览器的URL，浏览器向某处的服务器发出请求，然后服务器返回文件以呈现页面，然后关闭连接。

现在，假设需要登录网站以查看某些内容，例如使用 LinkedIn。该过程与上述过程基本相同，会看到一个表单，用于输入电子邮件地址和密码。

输入相关信息，然后浏览器将其发送到服务器。服务器检查登录信息，如果一切顺利，它将把呈现页面所需的数据发送回浏览器。

但是，如果 LinkedIn 是无状态的，一旦跳转到另一个页面，服务器将不记得你刚刚已经登录过。它将要求你再次输入电子邮件地址和密码，进行检查后在发送数据以渲染新页面。

那会非常令人沮丧，不是吗？许多开发人员也这样认为，并找到了很多在 Web 上创建有状态会话的方法。

cookie 的发明

90 年代初期，Netscape 的开发人员 Lou Montoulli 遇到了一个问题 – 他正在为另一家公司 MCI 开发一个在线商店，该商店会在服务器中存储每个客户购物车中的商品。这意味着人们必须首先创建一个帐户，创建账户需要花费一些时间，存储每个用户购物车的内容也会占用大量存储空间。

MCI 要求将这些数据存储在客户自己的计算机上。他们还希望客户在没有登录时也能添加商品到购物车。

为了解决这个问题，Lou 提出了一个在程序员中已经广为人知的想法：魔力 cookie。

魔力 cookie 或 cookie，是可以在两个计算机程序之间传递的少量数据。它们之所以“魔幻”，是因为 cookie 中的数据通常是随机密钥或令牌，并且实际只对使用它的软件才有意义。

Lou 采用了魔力 cookie 概念，并将其应用于在线商店，后来又应用于浏览器。

现在了解了 cookie 的历史，来看一下如何使用 cookie 在网络上创建有状态会话。

cookies 如何工作

和 cookie 有点像的一个场景，就是你在游乐园中获得的腕带。

当登录网站时，过程就像进入游乐园一样。首先，要买票，然后进入公园时，工作人员会检票并给你一条腕带。

这和登录的方式一样 - 服务器检查你的用户名和密码，创建并存储会话，生成唯一的会话 ID，然后发送回带有该会话 ID 的 cookie。

（请注意，会话 ID 不是你的密码，它是完全独立的，即时生成的。密码处理和身份验证不在本文的讨论范围之内，可以在这里了解更多。）

在游乐园中，可以通过出示腕带来消费项目。

同样，当你向登录的网站发出请求时，浏览器会将带有会话 ID 的 cookie 发送回服务器。服务器使用你的会话 ID 检查会话，然后返回请求的数据。

最后，一旦离开游乐园，你的腕带将不再起作用 - 你无法使用它重新回到公园参与游乐活动。

登出网站也一样。浏览器将带有 cookie 的注销请求发送到服务端，服务端删除 session，并告知浏览器删除具有相应 session id 的 cookie。

如果想回到游乐园，则必须购买另一张门票并获得另一个腕带。同样，如果想继续使用网站，就必须重新登录。

图片来源：Session vs Token Authentication in 100 Seconds (YouTube)

这是如何使用 cookie 来记录登录网站状态的简单示例。它还可以用来记录设置的深色主题模式，以及跟踪你在网站上的其它行为等。

怎样使用 cookie

现在已经了解了 cookie 的历史以及它们的作用，接下来来看一下 cookie 的一些局限，然后用实例演示一下。

cookie 的限制

与浏览器中更常用的存储数据方案（例如，localStorage 或 sessionStorage）相比，cookie 有很多局限性。 这是 cookie 和其它技术对比的摘要：

图片来源：cookies vs localStorage vs sessionStorage - Beau teaches JavaScript (YouTube)

cookies 是一种古老的技术，并且容量非常有限。不过，可以使用它们做很多事情。 它们的体积小巧，浏览器可以轻松地在每个请求中附带 cookie 发送到服务器。

还值得一提的是，出于安全原因，浏览器仅允许 cookie 在一个域名中可见。

因此，如果你通过 ally.com 登录银行，则 cookie 将仅在该域名及其子域名内起作用。例如，你的 ally.com 的 cookie 可以在 ally.com，ally.com/about 和域名 www.ally.com 上可见，而在 axos.com 上不可见。

这意味着，即使你同时拥有两个帐户并在 ally.com 和 axos.com 上都进行了登录，这些站点也将无法读取彼此的 cookie。

重要的是要记住，你的 cookie 是随浏览器中的请求一起发送的。这非常方便，但是存在一些严重的安全隐患，后面会详述。

最后，如果本文你只能记住一个知识点，那就请记住，cookie 是公开读取和发送的，切勿在其中存储诸如密码之类的敏感信息。

怎样在 JavaScript 中设置 cookie

cookies 实际上只是带有键/值对的字符串。尽管可能更多在后端使用 cookie，但也需要客户端设置 cookie。

以下是在 vanilla JavaScript 中设置 ocokie 的方法：

document.cookie = 'dark_mode=true'

然后，当打开开发者控制台时，单击“Application（应用程序）”，然后在站点的“Cookies”下，将看到刚添加的 cookie：

如果仔细查看 cookie，会发现它的过期日期设置为 Session。这意味着，当关闭标签页/浏览器时，cookie 将被销毁。

这可能是某些场景的预期行为，例如 cookie 存有付款信息的在线商店。

但是，如果希望 cookie 的存在时间更久，需要设置一个有效期。

如何在 JavaScript 中设置 cookie 的过期时间

要设置过期时间，只需设置 cookie 的值，然后添加带有日期配置的 expires 属性，该日期一般设置为未来的某个时间：

document.cookie = 'dark_mode=true; expires=Fri, 26 Feb 2021 00:00:00 GMT' // expires 1 week from now

JavaScript Date 对象可以很方便的生成日期。 可以在此处阅读有关 Date 对象的更多信息。

或者，也可以将 max-age 属性与你希望 cookie 生效的秒数结合使用：

document.cookie = 'dark_mode=true; max-age=604800'; // expires 1 week from now

然后，当到达该日期时，浏览器将自动删除 cookie。

如何在 JavaScript 中更新 cookie

cookie 更新很方便，和是否具有有效期无关。

只需更改 cookie 的值，浏览器就会自动配置：

document.cookie = "dark_mode=false; max-age=604800"; // expires 1 week from now

如何在 JavaScript 中设置 cookie 的路径

有时，只希望 cookie 在网站的某些部分生效。如何操作取决于网站的设置方式，一种方法是使用 path 属性。

配置 cookie 的方法如下：使 cookie 仅在 /about 的 about 页面上起作用：

document.cookie = 'dark_mode=true; path=/about';

现在，cookie 仅能在 /about 和其他子目录（例如 /about/team）上生效，而不能在/blog 上生效。

然后，当访问 about 页面并查看 cookie 时，如下：

如何在 JavaScript 中删除 cookie

要在 JavaScript 中删除 cookie，只需将 expires 属性设置为已过的日期即可：

document.cookie = 'dark_mode=true; expires=Sun, 14 Feb 2021 00:00:00 GMT'; // 1 week earlier

也可以使用 max-age 并将其设置为负值：

document.cookie = 'dark_mode=true; max-age=-60'; // 1 minute earlier

然后，查看 cookie，会发现它已经被删除：

这应该是在 vanilla JS 中使用 cookie 所需了解的比较全面的知识。

我们介绍的所有内容都能够满足常见的需求，如果对 cookie 的使用比较频繁，可以考虑类库 JavaScript Cookie 或 Cookie Parser。

cookie 的安全性问题

通常，cookie 在正确配置的前提下非常安全。浏览器有很多内置的限制，我们之前已经介绍了这些限制，部分原因是该技术的年代久远，这反而提高了其安全性。

尽管如此，攻击者还是有一些办法窃取你的 cookie 并利用它来搞破坏。

我们将探讨一些常见的攻击手段，并介绍对该攻击的应对策略。

另外，请注意，所有代码段都将使用 。如果要在服务器上实现这些修补程序，则需要查找语言或框架的确切语法。

中间人攻击

中间人（MitM）攻击描述了广泛的攻击类别，其中，攻击者在客户端和服务器之间，并拦截在两者之间传递的数据。

图片来源：Man-in-the-Middle Attacks and How To Avoid Them

这可以通过多种方式完成：通过访问或收听不安全的网站，模仿公共 WiFi 路由器，DNS 欺骗或通过 SuperFish 一类的恶意软件/广告软件。

这是 MitM 攻击的比较深入的介绍概述，涉及了网站如何保护自己和用户。

警告：视频的开头谈论了斯科茨女王玛丽，并生动地描绘了她的斩首。它有一点点暴力，但是如果你想跳过它，请跳至 00:57 处播放。

作为开发人员，通过确保在服务器上启用 HTTPS，使用来自受信任的证书颁发机构的 SSL 证书以及确保代码使用 HTTPS 而不是不安全的 HTTP，可以大大减少 MitM 攻击的可能性。

就 cookie 而言，你应该在 cookie 中添加 Secure 属性，以便它们只能通过安全的 HTTPS 连接发送：

document.cookie = 'dark_mode=false; Secure';

请记住，Secure 属性实际上并不会加密 cookie 中的任何数据 – 它只是确保 cookie 无法通过 HTTP 连接发送。

但是，攻击者仍然可能会拦截和操纵 cookie。为了防止这种情况的发生，还可以使用 HttpOnly 参数：

document.cookie = 'dark_mode=false; Secure; HttpOnly';

带有 HttpOnly 的 cookie 只能由服务器访问，而不能由浏览器的 Document.cookie API 访问。这非常适合诸如登录会话之类的场景，在该会话中，只有服务器真正需要知道你是否已登录到站点，而客户端不需要该信息。

XSS 攻击

XSS（跨站点脚本）攻击描述了恶意用户将意想不到的、潜在危险的代码注入网站时的一类攻击。

这些攻击非常棘手，因为它们可能会影响访问该网站的每个人。

图片来源：Cross-site scripting

例如，如果某个站点具有评论功能，并且某人能够将恶意代码包含在评论中，则访问该站点并阅读该评论的每个人都有可能受到影响。

就 cookie 而言，如果恶意行为者在站点上成功发起 XSS 攻击，则他们可以访问会话 cookie 并以另一个已登录用户的身份访问该站点。这样，他们就可以访问其他用户的设置，以该用户的身份购买商品并将其运送到另一个地址，等各种操作。

这是一个视频，概述了 XSS 的不同类型 - Reflected、Stored，基于 DOM 的和 Mutation：

作为开发人员，要确保服务器执行“相同来源策略”，并确保正确过滤了从用户那里收到的任何输入。

就像防止 MitM 攻击一样，你应该为你使用的任何 cookie 设置 Secure 和 HttpOnly 参数：

document.cookie = 'dark_mode=false; Secure; HttpOnly';

CSRF 攻击

CSRF（跨站点请求伪造）攻击是指攻击者诱骗他人执行意想不到的，潜在的恶意行为。

例如，如果你登录到站点并单击评论中的链接，如果该链接是 CSRF 攻击的一部分，则可能会导致你无意中更改登录详细信息，甚至删除帐户。

图片来源：Cross-site request forgery

虽然 CSRF 攻击在某种程度上与 XSS 攻击有关，特别是反映了有人将恶意代码插入站点的 XSS 攻击，但每种攻击都基于不同类型的信任。

根据 Wikipedia 的说法，虽然 XSS “利用了用户对特定站点的信任，但是 CSRF 却利用了站点在用户浏览器中访问的信任。 ”

这是一段解释 CSRF 基础知识的视频，并提供了一些有用的示例：

至于 cookie，防止可能的 CSRF 攻击的一种方法是使用 SameSite 标志：

document.cookie = 'dark_mode=false; Secure; HttpOnly; SameSite=Strict';

您可以为 SameSite 设置一些值：

• Lax: cookie 不会发送嵌入内容（图像，iframe 等），而是在你单击链接或向该 cookie 所设置的来源发送请求时发送。例如，如果你在 testing.com 上，然后单击链接以转到 test.com/about，则浏览器将发送带有该请求的 test.com cookie。
• Strict：仅当你单击链接或从设置了 cookie 的来源发送请求时，才会发送 cookie。 例如，只会在你位于 test.com 及其附近时发送 test.com cookie，而不会来自 testing.com 之类的其他网站。
• None：Cookie 会随每个请求发送，无论上下文如何。 如果将 SameSite 设置为 None，则还必须添加 Secure 属性。如果可能，最好避免使用此值。

主流浏览器对 SameSite 的处理方式略有不同。例如，如果未在 cookie上设置 SameSite，则 Google Chrome 默认将其设置为 Lax 。

cookie 的替代品

你可能想知道，如果 cookie 有这么多潜在的安全漏洞，为什么我们仍在使用它们？ 当然，必须有更好的选择。

这些天来，你可以使用 sessionStorage 或 localStorage 来存储最初使用 cookie 的信息。对于有状态会话，还可以使用基于令牌的身份验证以及诸如 JWT（JSON Web令牌）之类的东西。

虽然似乎你必须在基于 cookie 的身份验证或基于令牌的身份验证之间进行选择，但也可以同时使用两者。 例如，当某人通过浏览器登录时，你可能要使用基于 cookie 的身份验证，而当某人通过电话应用程序登录时，则要使用基于令牌的身份验证。

为了进一步解决问题，Auth0 等 authentication-as-aservice 提供程序允许你同时进行两种身份验证。

如果你想了解有关 Web 令牌和基于令牌的身份验证的更多信息，请查看我们的一些文章。

当你向开发人员提供 cookie 时

就是这样！ 这就是你开始使用 cookie 所需的知识，以及在此过程中需要注意的事项。

你觉得这有用吗？ 你是如何使用 cookie？ 留言或给我发推特吧。

原文：Everything You Need to Know About Cookies for Web Development，作者：Kris Koishigawa

它是由 Google 使用 Go 语言开发的，这项了不起的技术从 2014 年开始一直是开源的。

根据 Stack Overflow 开发者调研报告 - 2020，Kubernetes 是 #3 最喜爱的平台以及 #3 最想要的平台。

除了功能强大之外，Kubernetes 是公认的难上手。入门确实不容易，但是只要你符合入门条件并且有足够的耐心完成该指南，你将可以：

• 对基础知识有深入的了解。
• 可以创建和管理 Kubernetes 集群。
• 部署任意应用程序到 Kubernetes 集群上。

入门条件

• 熟悉 JavaScript
• 熟悉 Linux 终端
• 熟悉 Docker（建议阅读：Docker 入门教程 - 2021 最新版）

项目代码

实例中的代码可以在这个仓库中找到（你的 ⭐ 是我动力的源泉）。k8s 分支包含完整的代码。

目录

• 容器编排和 Kubernetes 简介
• 安装 Kubernetes
• Kubernetes 初体验
  • Kubernetes 的架构
  • Control Plane 组件
  • Node 组件
  • Kubernetes 对象
  • Pods
  • Services
  • 全景图
  • 清除 Kubernetes 相关资源
• 声明式部署方法
  • 编写你的第一套配置
  • Kubernetes 控制面板
• 使用多容器应用程序
  • 部署计划
  • 复用 Controllers, Replica Sets 以及 Deployments
  • 创建你的第一个部署
  • 调试 Kubernetes 资源
  • 从 Pods 获取容器日志
  • 环境变量
  • 创建数据库部署
  • Persistent Volumes 和 Persistent Volume Claims
  • Persistent Volumes 的动态预配置
  • 通过 Pods 连接 Volumes
  • 组装起来
• 使用 Ingress Controllers
  • 设置 NGINX Ingress Controller
  • Kubernetes 中的 Secret 和配置
  • 在 Kubernetes 中执行更新发布
  • 组合 Configurations
• 答疑
• 结论

容器编排和 Kubernetes 简介

摘自 Red Hat —

"容器编排是指自动化容器的部署、管理、扩展和联网。

容器编排可以在使用容器的任何环境中使用。它可以帮助你在不同环境中部署相同的应用，而无需重新设计。"

让我来给你看一个例子。假设你开发了一个很棒的应用，这个 应用可以根据时间向人们推荐他们应该吃什么。

假设你已经使用 Docker 容器化了应用并将其部署在了 AWS 上 。

如果应用因为某种原因宕机，用户马上就不能访问该服务了。

要解决此问题，可以为同一应用程序制作多个副本，使其服务高可用。

即使其中一台实例发生故障，其它两台实例也可以为用用户提供服务。

假设你的应用程序在熬夜党中流行了起来，在你晚上睡觉的时候涌入大量的请求。

如果所有的实例都因为过载而无法响应该怎么办？谁来进行自动伸缩？即使你扩容 了 50 个副本，谁来做健康检查？如何设置网络使使流量打到合适的端点上？负载均衡也是一个大问题，你说呢？

Kubernetes 可以很容易的搞定这些问题。Kubernetes 是一个由多个组件组成的容器编排平台，它可以一刻不眠的使是你的服务保持在理想状态。

假设你要连续运行 50 个应用程序副本，如果请求量激增，服务器也能自动扩容。

你只需把你的需求告诉 Kubernetes，它将为你完成其余的繁重工作。

Kubernetes 会实现并维护状态。如果有旧副本挂掉了，它将创建新的副本，管理网络和存储，推出或回滚更新，甚至在必要时升级服务。

安装 Kubernetes

实际上，在本地计算机上运行 Kubernetes 与在云平台上运行 Kubernetes 有很大不同。你需要下面两个程序，来启动和运行 Kubernetes。

• minikube - 它可以在本地计算机的虚拟机（VM）上运行单节点 Kubernetes 集群。
• kubectl - Kubernetes 命令行工具，可以在 Kubernetes 集群上执行命令。

除了这两个程序之外，你还需要一个管理程序和一个容器平台。显然 Docker 就是所需的容器平台。推荐的管理程序如下：

• Hyper-V Windows 系统
• HyperKit Mac 系统
• Docker Linux 系统

Hyper-V 作为可选功能内置于 Windows 10（Pro、Enterprise 和 Education）中，可以从控制面板中打开。

HyperKit 是 Mac 平台 Docker Desktop 的核心组件。

在 Linux 上，你可以直接通过 Docker 绕过整个管理程序层。它比任何管理程序都高效，是 Linux 上运行 Kubernetes 的推荐方法。

你可以继续安装上述任何管理程序。或者你想保持简单，只需要获取 VirtualBox。

文章的剩余部分，我们假设你正在使用 VirtualBox。别担心，即使你正在使用其他管理程序，区别也不会太大。

整篇文章，我在装有 Ubuntu 的机器上使用带有 Docker 驱动程序的 minikube 完成。

安装了管理程序和容器化平台之后，就该安装 minikube 和 kubectl 程序了。

如果你使用 Mac 或 Windows，安装完 Docker Desktop 后 kubectl 就已经安装了。可在此处找到 Linux 的安装说明。

另外 minikube 也是必需要安装的，可以在 Mac 上使用 Homebrew，Windows 上使用 Chocolatey 来安装 minikube。可以在此处找到 Linux 的安装说明。

安装完成后，可以通过执行以下命令来测试是否安装成功：

minikube version

# minikube version: v1.12.1
# commit: 5664228288552de9f3a446ea4f51c6f29bbdd0e0
kubectl version

# Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"clean", BuildDate:"2020-07-16T00:04:31Z", GoVersion:"go1.14.4", Compiler:"gc", Platform:"darwin/amd64"}
# Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:43:34Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}

如果你已经为你的操作系统下载了正确的版本并且设置了正确路径，那么那你已经准备就绪啦。

正如我已经提到的，minikube 在本地计算机上的虚拟机（VM）中运行一个单节点 Kubernetes 集群。 我将在下一部分中更详细地解释集群和节点。

现在，可以理解为 minikube 使用你选择的管理程序创建常规 VM，并将其视为 Kubernetes 集群。

如果你在本节中遇到任何问题，请查看本文结尾处的答疑部分。

在启动 minikube 之前，必需正确设置管理程序才能使用。执行如下命令将 VirtualBox 设置为默认驱动程序：

minikube config set driver virtualbox

# ❗ These changes will take effect upon a minikube delete and then a minikube start

可以根据需要将 virtualbox 替换为 hyperv、 hyperkit 或者 docker。这个命令只需运行一次。

执行下面的命令启动 minikube：

minikube start

# ? minikube v1.12.1 on Ubuntu 20.04
# ✨ Using the virtualbox driver based on existing profile
# ? Starting control plane node minikube in cluster minikube
# ? Updating the running virtualbox "minikube" VM ...
# ? Preparing Kubernetes v1.18.3 on Docker 19.03.12 ...
# ? Verifying Kubernetes components...
# ? Enabled addons: default-storageclass, storage-provisioner
# ? Done! kubectl is now configured to use "minikube"

可以通过 minikube stop 命令来停止 minikube 。

Kubernetes 初体验

现在已经在本地上安装了 Kubernetes，是时候动手啦。在此示例中，会向本地集群部署一个非常简单的应用，并熟悉一下基础知识。

本节中会涉及到诸如 pod, service, 负载均衡等术语, 如果你没有搞懂他们，别急，我会在全景图小节中详细介绍它们。

如果你在上一小节已经启动了 minikube，那么就可以开始啦，否则你需要先启动它哦。启动 minikube 后，在终端执行下面的命令：

kubectl run hello-kube --image=fhsinchy/hello-kube --port=80

# pod/hello-kube created

你会立即看到 pod/hello-kube created 消息。 run 命令用来在 pod 中运行指定的容器映像。

Pods 就像是封装容器的盒子，执行以下命令确保 pod 已经成功创建并运行：

kubectl get pod

# NAME         READY   STATUS    RESTARTS   AGE
# hello-kube   1/1     Running   0          3m3s

你应该在 STATUS 列看到 Running 信息。如果看到类似 ContainerCreating 的信息，等待一两分钟，然后再次检查。

默认情况下，从集群外部无法访问 Pod。若要使其可访问，必需使用 service 使其暴露。运行 pod 后，执行下面的命令暴露 pod：

kubectl expose pod hello-kube --type=LoadBalancer --port=80

# service/hello-kube exposed

执行以下命令确保负载均衡服务已经成功创建：

kubectl get service

# NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# hello-kube   LoadBalancer   10.109.60.75   <pending>     80:30848/TCP   119s
# kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP        7h47m

请确保在列表中可以看到 hello-kube 服务。现在已经有了一个公开的 pod 正在运行，执行下面的命令访问它。

minikube service hello-kube

# |-----------|------------|-------------|-----------------------------|
# | NAMESPACE |    NAME    | TARGET PORT |             URL             |
# |-----------|------------|-------------|-----------------------------|
# | default   | hello-kube |          80 | http://192.168.99.101:30848 |
# |-----------|------------|-------------|-----------------------------|
# ? Opening service default/hello-kube in default browser...

默认的 web 浏览器应该会自动打开，显示类似如下的内容：

这是一个非常简单的 JavaScript 应用程序，使用了 vite 和一点 CSS。如果要了解刚才执行的命令，需要熟悉一下 Kubernetes 的架构。

Kubernetes 的架构

在 Kubernetes 的世界中，node 既可以是一台物理设备也可以是一台指定角色的虚拟机。这样的一组使用一个共享网络彼此通信的设备或者服务器的集合就叫做 集群（cluster）。

在本地设置中， minikube 是单节点的 Kubernetes 集群。因此 minikube 没有像上图的多个服务器，而是只有一台服务器同时充当主服务器和 node。

Kubernetes 集群中的每台服务器都会获得一个角色。有两种不同的角色：

• control-plane — 做出大部分必要的决定，并充当整个集群的大脑。它可以是单个服务器或者大型项目中的一组服务器。
• node — 负责运行工作负载，这些服务器通常由 control-plane 进行细微管理，并按照提供的说明执行各种任务。

集群中每个服务器都将具有一组特定的组件。这些组件的数量和类型根据服务器在集群中承担的角色而有所不同。这意味着节点不必包含 control plane 中的所有的组件。

在接下来的小节里，将更详细的了解组成 Kubernetes 集群的各个组件。

Control Plane 组件

Kubernetes 集群中的 control plane 由如下五个组件组成：

1. kube-api-server: 这是 Kubernetes control plane 的入口，负责验证和处理使用客户端库（如 kubectl 程序）传递的请求。
2. etcd: 这是一个分布式键值存储，是整个集群的唯一键值来源。它保存了配置数据和集群的状态信息。etcd 是一个开源项目，由来自 Red Hat 的人开发。 该项目的源代码托管在 etcd-io/etcd GitHub 仓库中。
3. kube-controller-manager: Kubernetes 中的 controller 负责控制集群的状态。当请求 Kubernetes 集群内容时，controller 会做出响应。kube-controller-manager 是通过一个进程管理所有 controller 进程的程序。
4. kube-scheduler: 调度就是根据节点的可用资源和任务需要的资源分配任务。kube-scheduler 组件执行 Kubernetes 的任务调度以确保集群中所有的服务都不过载。
5. cloud-controller-manager: 在真实的云环境中，此组件允许你通过 (GKE/EKS) API 连接集群。这样，与该云平台交互的组件就和与集群交互的组件隔离开了。在 minikube 这一类的组件中，该组件并不存在。

Node 组件

与 control plane 相比，node 的组件数量非常少，如下：

1. kubelet: 该服务充当 control plane 和集群中每个节点之间的网关。从 control plane 到节点的每条指令都通过此服务。它还与 etcd 存储区进行交互以保持状态信息的更新。
2. kube-proxy: 这个小服务运行在每个节点上，并为其维护网络规则。到达集群内部服务的任何网络请求都将通过此服务。
3. Container Runtime: Kubernetes 是一个容器编排工具，因此它最终在容器中运行应用程序。这意味着每个节点都需要一个容器环境，比如 Docker、rkt 或者 cri-o。

Kubernetes 对象

摘自 Kubernetes 文档 —

"在 Kubernetes 系统中，Kubernetes 对象 是持久化的实体。 Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息：

• 哪些容器化应用在运行（以及在哪些节点上）
• 可以被应用使用的资源
• 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略

当创建 Kubernetes 对象时，实际上是在告诉 Kubernetes 系统这个对象应该存在，任何时候 Kubernetes 系统都应该确保该对象的’

运行。

Pods

摘自 Kubernetes 文档 —

"Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元"。

pod 通常封装一个或多个紧密相关的容器，共享一个生命周期和消耗性资源。

尽管一个 pod 可以容纳多个容器，但是你不应该随意的把容器放到 pod 中。pod 中的容器必须紧密相关，以至于可以将它们视为单个应用程序。

例如，后端的 API 可能依赖数据库，但这并不意味着需要把他们都放在同一个容器中。在整篇文章中，不会有任何 pod 放置多个容器。

通常，你不应该直接管理 pod。相反，你应该使用可以提供更好的可管理的高级对象。将在后面的部分中介绍这些更高级别的对象。

Services

摘自 Kubernetes 文档 —

"Kubernetes 的 service 是将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法"。

Kubernetes pods 是非永久性资源。他们被创造出来，即使过一段时间被销毁了，也不会被回收。

相反，新的 pod 取代了旧的 pod。一些更高级别的对象甚至能动态创建和销毁 pod。

在创建每个 pod 时，会为其分配一个新的 IP 地址。但是对于可以创建、销毁和组合多个 pod 的高级对象而言，在此刻运行的 pod 集合可能与稍后运行的 pod 集合并不相同。

这就导致了一个问题：如果集群中的某些 pod 依赖于集群中的另一组 pod，怎样定位并跟踪彼此的 IP 地址呢？

根据 Kubernetes 文档 —

"Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务"。

本质上讲，service 将执行相同功能的多个 pod 组合在一起，并将它们显示为单个实体。

这样一来，如何跟踪多个 Pod 的问题就消失了，因为单个 service 现在充当了所有 pod 的沟通器。

在 hello-kube 示例中，创建了一个 LoadBalancer 类型的服务，该服务可以将来自集群外部的请求连接到集群内部运行的 pod 上。

无论何时，在需要授予另一个应用程序或者集群外部某个对象一个或多个 pod 的访问权限时，就应该创建一个 service。

比如，如果你有一组运行 web 服务的 pod，需要从 internet 进行访问，那么就必需用 service 提供必要的抽象。

全景图

现在你已经对 Kubernetes 的各个组件有了适当的了解，下图描述了他们是如何协作的：

https://kubernetes.io/docs/concepts/overview/components/

在解释各个细节之前，先看一下 Kubernetes 文档 --

"操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 Kubernetes API。 比如，当使用 kubectl 命令行接口时，CLI 会执行必要的 Kubernetes API 调用。"

运行的第一个命令是 run 命令，如下：

kubectl run hello-kube --image=fhsinchy/hello-kube --port=80

run 命令负责运行指定的镜像创建新的 pod。运行此命令后，Kubernetes 集群会执行下面的事件：

• kube-api-server 组件接收请求，对其进行校验并进行处理。
• kube-api-server 接着与节点上的 kubelet 进行通信，并提供创建 pod 所需的指令。
• kubelet 组件开始启动运行 pod，并且在 etcd 存储中保持状态的更新。

run 命令的通用语法如下：

kubectl run <pod name> --image=<image name> --port=<port to expose>

可以在 pod 内运行任何有效的容器映像。fhsinchy/hello-kube Docker 镜像包含了一个非常简单的 JavaScript 应用程序，该应用程序在容器内部的 80 端口上运行。 --port=80 选项允许容器从内部暴露 80 端口。

新创建的 Pod 运行在 minikube 集群内部，并且无法从外部访问。要公开容器并使其可用，运行的第二个命令如下：

kubectl expose pod hello-kube --type=LoadBalancer --port=80

expose 命令负责创建类型为 LoadBalancer Kubernetes service，该服务允许用户访问 Pod 中运行的应用程序。

和 run 命令一样， expose 命令的执行需要在集群内部运行相似的步骤。在这里， kube-api-server 向 kubelet 组件提供了创建 service （而不是 pod）所需的指令。

expose 命令的通用语法如下：

kubectl expose <resource kind to expose> <resource name> --type=<type of service to create> --port=<port to expose>

对象类型可以是任意合法的 Kubernetes 对象类型。名称必需和要暴露的对象名称匹配。

--type 表示所需的 service 类型。在内部或外部网络中一共有四种不同的 service 类型。

最后， --port 是要从容器中暴露的端口号。

创建完 service 后，最后一件事就是访问在 pod 的应用程序。为此，需要执行如下命令：

minikube service hello-kube

和之前的命令不同 ，最后一个命令没有用 kube-api-server。它使用 minikube 和本地集群通讯。 minikube 的 service 命令会返回给定服务的完整 URL。

当使用 --port=80 选项创建 hello-kube 容器时，Kubernetes 会在容器内暴露 80 端口，但是无法在集群外部访问它。

接着，使用 --port=80 选项创建 LoadBalancer 服务，它将 80 端口从该容器映射到本地系统中的任意端口，从而可以从集群外部访问它。

在我的系统上， service 命令返回 pod 的 URL 192.168.99.101:30848。该 URL 中的 IP 实际上是 minikube 虚拟机的真实 IP。可以通过下面的命令来验证：

minikube ip

# 192.168.99.101

可以通过如下命令验证 30848 端口是否指向 pod 内部的 80 端口：

kubectl get service hello-kube

# NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
# hello-kube   LoadBalancer   10.109.60.75   <pending>     80:30848/TCP   119s

在 PORT(S) 列上，可以看到 80 端口实际上映射到本地系统的 30484 端口。因此，无需运行 service 命令，只需找到 IP 和端口号，然后就可以在浏览器内访问 hello-kube 应用程序。

目前集群的状态如下所示：

如果你了解 Docker，那么你可能觉得使用 service 来公开 pod 有点太麻烦了。

但是当你处理涉及多个 pod 的实例时，你就会了解 Kubernetes 这么做的便利了。

清除 Kubernetes 相关资源

现在已经了解如何创建 pod 和 service 之类的 Kubernetes 资源，现在来学习如何清除它们。也就是删除它们。

执行 kubectl 的 delete 命令来删除资源，用法如下：

kubectl delete <resource type> <resource name>

使用下面的命令删除名为 hello-kube 的 pod：

kubectl delete pod hello-kube

# pod "hello-kube" deleted

使用下面的命令删除名为 hello-kube 的 service：

kubectl delete service hello-kube

# service "hello-kube" deleted

或者（现在不可用）使用 delete 命令的 --all 选项来一次性删除所有此类对象。该选项的通用语法如下：

kubectl delete <object type> --all

如果要删除所有的 pod 和 service，依次执行 kubectl delete pod --all 和kubectl delete service --all。

声明式部署方法

坦白讲，你在上一节看到的 hello-kube 例子并不是部署 Kubernetes 的最佳方式。

在之前章节采用的是交互式途径（imperative approach），这意味着你必须手动逐个执行每个命令。采用交互式方法无法很好的工程化。

使用 Kubernetes 进行部署的理想方式是声明式途径（declarative approach），作为开发人员，只需让 Kubernetes 知道服务需要达到的状态，其余的 Kubernetes 会搞定。

在本节中，将会使用声明式部署相同的 hello-kube 应用程序。

如果你尚未克隆上面链接的代码仓库，请立即进行操作。

克隆完毕后，进入 hello-kube 目录，该目录包含 hello-kube 应用程序的代码以及用户构建镜像的 Dockerfile 。

├── Dockerfile
├── index.html
├── package.json
├── public
└── src

2 directories, 3 files

JavaScript 代码位于 src 文件夹下，无需关注，你应该看一下 Dockerfile，了解一下计划部署。Dockerfile 文件内容如下：

FROM node as builder

WORKDIR /usr/app

COPY ./package.json ./
RUN npm install
COPY . .
RUN npm run build

EXPOSE 80

FROM nginx
COPY --from=builder /usr/app/dist /usr/share/nginx/html

如你所见，这是一个多阶段构建（multi-staged build）。

• 第一阶段使用 node 作为基本镜像，然后将 JavaScript 应用程序编译为生产状态。
• 第二阶段复制第一阶段生成的文件，并将其粘贴到默认的 NGINX 文档根目录中。这里假设第二阶段的基本镜像是 nginx，会把第一阶段构建的文件运行在 80 端口（nginx 默认端口）。

要在 Kubernetes 上部署应用，需要找到一种方式把镜像运行在容器里，并使其能在外部世界通过 80 端口访问。

编写你的第一套配置

在声明式方式中，无需在终端中发送单个命令，只需在 YAML 文件中写下必要的配置，然后将其提供给 Kubernetes 即可。

在 hello-kube 工程目录下，创建另一个名为 k8s 的目录，k8s 是 k(ubernete = 8 个字符)s 的缩写。

文件夹名不必一定是 k8s，可以任意命名。

甚至没有必要将其放在项目目录中，这些配置文件可以放在计算机中的任何位置，因为这些配置与项目源代码无关。

在 k8s 目录中，创建一个名为 hello-kube-pod.yaml 的新文件。先看一下所有的代码，后面会逐行解释。文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: hello-kube-pod
  labels:
    component: web
spec:
  containers:
    - name: hello-kube
      image: fhsinchy/hello-kube
      ports:
        - containerPort: 80

每个有效的 Kubernetes 配置文件都有四个必填字段。如下：

• apiVersion: 创建对象使用的 Kubernetes API 版本。该值可能会根据你创建的对象的类型而变化。对于 Pod 的创建，所需的版本是 v1。
• kind: 创建的对象的类型。Kubernetes 中有许多种对象。本文介绍了很多对象，目前只需知道要创建的对象是 Pod 即可。
• metadata: 对象的唯一标识数据。在此字段下，可以有 name、 labels、 annotation 等信息。当使用 kubectl 命令时 metadata.name 会显示在终端上。metadata.labels 字段下的键值对不必一定是 components: web ，可以指定任意 label 比如 app: hello-kube。在接下来创建 LoadBalancer service 时会使用该值作为选择器。
• spec: 包含对象希望达成的状态。 spec.containers 子字段包含将要运行在 Pod 内的容器信息。 spec.containers.name 是节点内的容器运行时分配给新创建容器的值。spec.containers.image 是用来创建容器的镜像。spec.containers.ports 字段是各种端口的配置。containerPort: 80 表示容器对外暴露的端口是 80。

现在使用 apply 命令将这个文件提供给 Kubernetes，用法如下：

kubectl apply -f <configuration file>

如下命令 apply 了名为 hello-kube-pod.yaml 的配置文件：

kubectl apply -f hello-kube-pod.yaml

# pod/hello-kube-pod created

执行以下命令以确保 Pod 已经成功启动并且正在运行：

kubectl get pod

# NAME         READY   STATUS    RESTARTS   AGE
# hello-kube   1/1     Running   0          3m3s

在 STATUS 列中能看到 Running。如果显示的是类似 ContainerCreating 的内容，请等待一两分钟后再试。

当 Pod 启动并运行后，就可以开始写 LoadBalancer service 的配置文件了。

在 k8s 路径下创建一个名为 hello-kube-load-balancer-service.yaml 的文件内容如下：

apiVersion: v1
kind: Service
metadata:
  name: hello-kube-load-balancer-service
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
  selector:
    component: web

和之前的配置文件一样，apiVersion、kind 和 metadata 字段作用相同。如你所见，metadata 内没有 labels 字段，因为 service 使用 labels 选择其它对象，而其它对象无需选择 service。

记住，service 为其他对象设置了访问策略，而其它对象无需为 service 设置访问策略。

在 spec 字段内可以看到一组新的值。和 Pod 不同，service 有四种不同的类型，他们是 ClusterIP、 NodePort、 LoadBalancer 和ExternalName。

在此例中，使用的是 LoadBalancer 类型，这是把 service 暴露给集群外的标准方法。该服务会给你提供一个 IP 地址，可以使用该 IP 地址连接到集群内运行的应用程序。

LoadBalancer 类型需要两个端口值才能正常工作，在 ports 字段下，port 值用于访问 pod 本身，其值可以是任意值。

targetPort 值是容器内部的值，必需要与容器内部的 port 一致。

正如之前所说，hello-kube 应用运行在容器内部的 80 端口上，已经在 Pod 配置文件中暴露了该端口，因此 targetPort 的值应该为 80。

selector 字段用于标识将要连接该 service 的对象。component: web 键值对必须与 Pod 配置文件中的 labels 字段相匹配。如果你之前在配置文件里使用了其它的键值对如 app: hello-kube ，那么就改成你的键值。

在次使用 apply 命令将这个文件提供给 Kubernetes。文件名为hello-kube-load-balancer-service.yaml， 命令如下：

kubectl apply -f hello-kube-load-balancer-service.yaml

# service/hello-kube-load-balancer-service created

执行以下命令以确保负载均衡器已经成功创建：

kubectl get service

# NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
# hello-kube-load-balancer-service   LoadBalancer   10.107.231.120   <pending>     80:30848/TCP   7s
# kubernetes                         ClusterIP      10.96.0.1        <none>        443/TCP        21h

确保在列表中能看到 hello-kube-load-balancer-service。现在你已经运行了一个公有的 pod，执行下面的命令直接进行访问：

minikube service hello-kube-load-balancer-service

# |-----------|----------------------------------|-------------|-----------------------------|
# | NAMESPACE |           NAME                   | TARGET PORT |             URL             |
# |-----------|----------------------------------|-------------|-----------------------------|
# | default   | hello-kube-load-balancer-service |          80 | http://192.168.99.101:30848 |
# |-----------|----------------------------------|-------------|-----------------------------|
# ?  Opening service default/hello-kube-load-balancer in default browser...

默认的浏览器应该会自动打开，如下所示：

也可以将两个文件一起提供，如下所示，将文件名替换成目录名即可：

kubectl apply -f k8s

# service/hello-kube-load-balancer-service created
# pod/hello-kube-pod created

请确保终端在 k8s 目录的父目录中。

如果位于 k8s 目录中，可以使用点 (.) 引用当前目录。应用批量配置时，最好提前清除之前创建的资源，以防发生冲突。

声明式方法是使用 Kubernetes 的理想方法，当然有一些例外情况，本文结尾会介绍。

Kubernetes 控制面板

在上一节中，使用 delete 命令清除了 Kubernetes 对象。

在本节中，会引入控制面板。Kubernetes 控制面板是一个图形用户界面，用于管理工作负载、service 等。

在终端中执行以下命令启动 Kubernetes 控制面板：

minikube dashboard

# ? Verifying dashboard health ...
# ? Launching proxy ...
# ? Verifying proxy health ...
# ? Opening http://127.0.0.1:52393/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ in your default browser...

控制面板应该会在浏览器中自动打开：

控制面板界面很直观，你可以快速上手。虽然创建、管理和删除对象都能从控制面板进行，但是本文其余部分还是会使用 cli 来操作。

在 Pods 列表中，可以使用右边的三个点菜单的 Delete 来删除 Pod。LoadBalancer service 也可以如此操作，实际上 Services 列表就位于 Pods 列表后。

可以按 Ctrl + C 组合键或者关闭终端窗口来停止控制面板服务。

使用多容器应用程序

目前为止，已经使用了单个容器运行了应用程序。

在本节中，将会使用两个容器组成应用程序。你还会学习到 Deployment、ClusterIP、 PersistentVolume、PersistentVolumeClaim 以及一些调试技巧。

将使用的服务是一个具备完整 CRUD 功能的简单的基于 express 的日记 API。该应用使用 PostgreSQL 数据库。因此不仅需要部署应用程序，还需要建立应用程序和数据库服务的内部网络连接。

该应用程序的代码位于项目仓库的 notes-api 目录中。

.
├── api
├── docker-compose.yaml
└── postgres

应用程序代码位于 api 目录中，postgres 目录包含了创建 postgres 镜像的 Dockerfile。 docker-compose.yaml 文件包含使用 docker-compose 运行应用程序的配置文件。

就像上一个项目一样，可以查看每个 service 单独的 Dockerfile，以了解应用程序是如何在容器中运行的。

也可以只检查 docker-compose.yaml 并用它来规划 Kubernetes 部署。

version: "3.8"

services: 
    db:
        build:
            context: ./postgres
            dockerfile: Dockerfile.dev
        environment:
            POSTGRES_PASSWORD: 63eaQB9wtLqmNBpg
            POSTGRES_DB: notesdb
    api:
        build: 
            context: ./api
            dockerfile: Dockerfile.dev
        ports: 
            - 3000:3000
        volumes: 
            - /usr/app/node_modules
            - ./api:/usr/app
        environment: 
            DB_CONNECTION: pg
            DB_HOST: db
            DB_PORT: 5432
            DB_USER: postgres
            DB_DATABASE: notesdb
            DB_PASSWORD: 63eaQB9wtLqmNBpg

查看 api 服务定义，应该可以看到服务运行在内部容器的 3000 端口。它还需要一堆环境变量才能正常运行。

可以忽略 volumes，它在开发环境是必需的，并且构建配置是只针对于 Docker。因此可以保留 Kubernetes 配置文件几乎不变，如下：

• Port 映射 – 必需从容器公开相同的端口。
• 环境变量 – 这些变量在所有的环境中都是相同的（尽管值将发生变化）。

db 服务更简单，它只是一堆环境变量。甚至可以用官方的 postgres 镜像代替自定义的镜像。

使用自定义镜像的好处是数据库实例可以附带预先创建的 notes 表。

该表对于应用程序是必需的，如果查看 postgres/docker-entrypoint-initdb.d 目录，会看到一个名为 notes.sql 的文件，该文件用于在初始化期间创建数据库。

部署计划

和之前的项目部署不同，该项目将变的更加复杂。

在这个项目中，将会创建三个 notes API 实例。这三个实例使用 LoadBalancer service 暴露在集群外面。

除了这个实例，还会有一个 PostgreSQL 系统实例。notes API 应用程序的三个实例都使用 ClusterIP service 和数据库实例通讯。

ClusterIP service 是另外一种 Kubernetes service，它在集群内部使应用可见。也就是说即使没有外部流量，应用程序也可以使用 ClusterIP service。

在此项目中，必需仅通过 Notes API 访问数据库，因此在集群中公开数据库服务是一个理想的选择。

上一节中已经提起到，不应该直接创建 pod。因此，在此项目中使用 Deployment 而不是 Pod。

复制 Controllers、Replica Sets 以及 Deployments

根据 Kubernetes 文档 -

"在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。控制回路（Control Loop）是一个非终止回路，用于调节系统状态。"

ReplicationController 可以很轻松的创建多个副本。当创建所需的副本后，控制器将保持当前状态。

如果过了一段时间你决定减少副本的数量，那么 ReplicationController 会立刻清除多余的 pods。

否则，如果副本的数量少于预期数量（也许一些 pod 已经崩溃），ReplicationController 会创建新的副本以达到所需的状态。

尽管 ReplicationController 很强大，但目前已不是创建副本的推荐方式。它已经被较新的 API ReplicaSet 取代。

ReplicaSet 除了提供了更多选择外，ReplicationController 和 ReplicaSet 完成的几乎是同一件事。

拥有更多的选择器是件好事，但是更棒的是，能在发布和回滚更新方面具有更大的灵活性。这就该轮到另一个 Kubernetes API Deployment 出场了。

Deployment 就像是 ReplicaSet API 的一个扩展。Deployment 不但允许你立即创建新副本，还允许使用一个或两个 kubectl 命令发布或回滚更新。

在这个项目里，会使用 Deployment 来维护应用程序实例。

创建你的第一个部署

首先，为 Notes API 部署编写配置文件，在 notes-api 目录中创建一个 k8s 目录。

在该目录中，创建一个名为 api-deployment.yaml 的文件，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000

在此文件中，apiVersion、 kind、 metadata 和 spec 字段作用与之前的项目相同。与上一个文件相比，不一样的地方如下：

• 创建 pod 时，apiVersion的值是 v1。但是创建部署时，需要的版本是 apps/v1。Kubernetes API 的版本有时会有些混乱，你可能会有些一头雾水。可以阅读一下官网文档对 Deployment YAML 文件的介绍。
• spec.replicas 定义了同时运行的副本数量。将此值设置为 3 意味着希望 Kubernetes 同时运行三个应用实例。
• 在 spec.selector 中，可以让 Deployment 知道要控制那些 pods。之前已经提到，Deployment 是 ReplicaSet 的扩展，可以控制 Kubernetes 对象。将 selector.matchLabels 设置为 component: api 意味着 Deployment 会控制 label 为 component: api 的 pods。这行代码的意思就是让 Kubernetes 知道你希望 Deployment 来控制 label 为 component: api 的 pods。
• spec.template 是用于配置 pod 的模板，它与之前的配置文件几乎相同。

现在，要查看此配置效果，和之前一样 apply 该文件：

kubectl apply -f api-deployment.yaml

# deployment.apps/api-deployment created

执行下面的命令确保 Deployment 已经成功创建：

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           2m7s

如果查看 READY 列，会看到 0/3。这意味着容器尚未创建，等待几分钟，然后在试一次。

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           28m

坦白讲，我已经等了将近半个小时，pod 还未准备就绪。API 本身只有几百 kb。这种规模的部署不应该花这么长的时间，这意味着有问题，我们来解决它。

调试 Kubernetes 资源

开始之前，首先回到起点。get 命令是一个很基础的命令。

get 命令可以打印一张包含一个或多个 Kubernetes 资源重要信息的表。用法如下：

kubectl get <resource type> <resource name>

在终端执行如下代码，在 api-deployment 上运行 get 命令：

kubectl get deployment api-deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           15m

可以省略 api-deployment 以获取所有可用的部署列表。也可以在配置文件上使用 get 命令。

可以使用如下命令获取有关 api-deployment.yaml 文件中描述的部署信息：

kubectl get -f api-deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   0/3     3            0           18m

默认情况下，get 命令显示的信息非常少，可以使用 -o 选项获取更多信息。

-o 选项设置 get 命令的输出格式，可以使用 wide 输出格式查看更详细信息。

kubectl get -f api-deployment.yaml

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES               SELECTOR
# api-deployment   0/3     3            0           19m   api          fhsinchy/notes-api   component=api

现在列表包含了更多的信息，可以在官方文档了解有关 get 命令的选项。

老实说，仅仅是运行 Deploymen 的 get 命令没啥意思。还需要获取更底层资源的信息。

看一下 pod 列表，看看里面都有啥东西：

kubectl get pod

# NAME                             READY   STATUS             RESTARTS   AGE
# api-deployment-d59f9c884-88j45   0/1     CrashLoopBackOff   10         30m
# api-deployment-d59f9c884-96hfr   0/1     CrashLoopBackOff   10         30m
# api-deployment-d59f9c884-pzdxg   0/1     CrashLoopBackOff   10         30m

现在发现了一些有用的东西。所有的 pods 都有一个值为 CrashLoopBackOff 的 STATUS。之前只接触过 ContainerCreating 和 Running 状态。你可能还会在 CrashLoopBackOff 处看到 Error。

看一下 RESTARTS 列，会发现 pod 已经重启 10 多次了，着意味着因为某些原因， pod 启动失败了。

现在，要查看一个 pod 的更详细信息，可以使用另一个名为 describe 的命令。它和 get 命令很像，用法如下：

kubectl get <resource type> <resource name>

执行下面的命令查看 api-deployment-d59f9c884-88j4 pod 的详细信息：

kubectl describe pod api-deployment-d59f9c884-88j45

# Name:         api-deployment-d59f9c884-88j45
# Namespace:    default
# Priority:     0
# Node:         minikube/172.28.80.217
# Start Time:   Sun, 09 Aug 2020 16:01:28 +0600
# Labels:       component=api
#               pod-template-hash=d59f9c884
# Annotations:  <none>
# Status:       Running
# IP:           172.17.0.4
# IPs:
#   IP:           172.17.0.4
# Controlled By:  ReplicaSet/api-deployment-d59f9c884
# Containers:
#  api:
#     Container ID:   docker://d2bc15bda9bf4e6d08f7ca8ff5d3c8593655f5f398cf8bdd18b71da8807930c1
#     Image:          fhsinchy/notes-api
#     Image ID:       docker-pullable://fhsinchy/notes-api@sha256:4c715c7ce3ad3693c002fad5e7e7b70d5c20794a15dbfa27945376af3f3bb78c
#     Port:           3000/TCP
#     Host Port:      0/TCP
#     State:          Waiting
#       Reason:       CrashLoopBackOff
#     Last State:     Terminated
#       Reason:       Error
#       Exit Code:    1
#       Started:      Sun, 09 Aug 2020 16:13:12 +0600
#       Finished:     Sun, 09 Aug 2020 16:13:12 +0600
#     Ready:          False
#     Restart Count:  10
#     Environment:    <none>
#     Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-gqfr4 (ro)
# Conditions:
#   Type              Status
#   Initialized       True
#   Ready             False
#   ContainersReady   False
#   PodScheduled      True
# Volumes:
#   default-token-gqfr4:
#     Type:        Secret (a volume populated by a Secret)
#     SecretName:  default-token-gqfr4
#     Optional:    false
# QoS Class:       BestEffort
# Node-Selectors:  <none>
# Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
#                  node.kubernetes.io/unreachable:NoExecute for 300s
# Events:
#   Type     Reason     Age                         From               Message
#   ----     ------     ----                        ----               -------
#   Normal   Scheduled  <unknown>                   default-scheduler  Successfully assigned default/api-deployment-d59f9c884-88j45 to minikube
#   Normal   Pulled     2m40s (x4 over 3m47s)       kubelet, minikube  Successfully pulled image "fhsinchy/notes-api"
#   Normal   Created    2m40s (x4 over 3m47s)       kubelet, minikube  Created container api
#   Normal   Started    2m40s (x4 over 3m47s)       kubelet, minikube  Started container api
#   Normal   Pulling    107s (x5 over 3m56s)        kubelet, minikube  Pulling image "fhsinchy/notes-api"
#   Warning  BackOff    <invalid> (x44 over 3m32s)  kubelet, minikube  Back-off restarting failed container

整个输出中最有用的部分是 Events 部分，如下：

Events:
  Type     Reason     Age                         From               Message
  ----     ------     ----                        ----               -------
  Normal   Scheduled  <unknown>                   default-scheduler  Successfully assigned default/api-deployment-d59f9c884-88j45 to minikube
  Normal   Pulled     2m40s (x4 over 3m47s)       kubelet, minikube  Successfully pulled image "fhsinchy/notes-api"
  Normal   Created    2m40s (x4 over 3m47s)       kubelet, minikube  Created container api
  Normal   Started    2m40s (x4 over 3m47s)       kubelet, minikube  Started container api
  Normal   Pulling    107s (x5 over 3m56s)        kubelet, minikube  Pulling image "fhsinchy/notes-api"
  Warning  BackOff    <invalid> (x44 over 3m32s)  kubelet, minikube  Back-off restarting failed container

从这些事件中，可以看到容器镜像已经成功 pulled，容器也已经创建，但是显然从 Back-off restarting failed container 中可以看出该容器无法启动。

describe 命令和 get 命令类似，并且具有相同的选项。

可以省略 api-deployment-d59f9c884-88j45 名字以获取所有 pods 的信息。或者也可以使用 -f 选项将配置文件传入命令。访问官方文档了解更多信息。

既然已经知道了是容器出了问题，那么就让我们到容器层面看看到底出了什么问题吧。

从 Pods 获取容器日志

还有另一个名为 logs 的 kubectl 命令，可以从容器内部获取容器的日志，用法按如下：

kubectl logs <pod>

使用如下命令 api-deployment-d59f9c884-88j45 查看 pod 内的日志：

kubectl logs api-deployment-d59f9c884-88j45
# > api@1.0.0 start /usr/app
# > cross-env NODE_ENV=production node bin/www
# /usr/app/node_modules/knex/lib/client.js:55
#     throw new Error(knex: Required configuration option 'client' is missing.);
    ^
# Error: knex: Required configuration option 'client' is missing.
#     at new Client (/usr/app/node_modules/knex/lib/client.js:55:11)
#     at Knex (/usr/app/node_modules/knex/lib/knex.js:53:28)
#     at Object.<anonymous> (/usr/app/services/knex.js:5:18)
#     at Module._compile (internal/modules/cjs/loader.js:1138:30)
#     at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
#     at Module.load (internal/modules/cjs/loader.js:986:32)
#     at Function.Module._load (internal/modules/cjs/loader.js:879:14)
#     at Module.require (internal/modules/cjs/loader.js:1026:19)
#     at require (internal/modules/cjs/helpers.js:72:18)
#     at Object.<anonymous> (/usr/app/services/index.js:1:14)
# npm ERR! code ELIFECYCLE
# npm ERR! errno 1
# npm ERR! api@1.0.0 start: cross-env NODE_ENV=production node bin/www
# npm ERR! Exit status 1
# npm ERR!
# npm ERR! Failed at the api@1.0.0 start script.
# npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

这正是出问题的地方，看起来是 knex.js 库缺少一个必要的值，导致程序启动失败。可以从官方文档了解更多关于 logs 命令的信息。

出现这个错误主要是因为在部署定义中缺少了一些必需的环境变量。

如果在看一下 docker-compose.yaml 文件中的 api service 定义，应该会看到类似如下的内容：

    api:
        build: 
            context: ./api
            dockerfile: Dockerfile.dev
        ports: 
            - 3000:3000
        volumes: 
            - /usr/app/node_modules
            - ./api:/usr/app
        environment: 
            DB_CONNECTION: pg
            DB_HOST: db
            DB_PORT: 5432
            DB_USER: postgres
            DB_DATABASE: notesdb
            DB_PASSWORD: 63eaQB9wtLqmNBpg

应用程序与数据库进行连接需要这些环境变量。所以，把这些数据添加到部署配置中就可以解决该问题。

环境变量

给 Kubernetes 配置文件添加环境变量非常简单。打开 api-deployment.yaml 文件并按如下更新内容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          
          # these are the environment variables
          env:
            - name: DB_CONNECTION
              value: pg

containers.env 字段包含所有的环境变量，如果细心你会发现我还没有给 docker-compose.yaml 文件添加所有的环境变量，我只添加了一个。

DB_CONNECTION 表示应用正在使用 PostgreSQL 数据库，添加这个变量就可以解决上述问题。

现在通过执行下面的命令在此 apply 配置文件：

kubectl apply -f api-deployment.yaml

# deployment.apps/api-deployment configured

这次显示资源已经被 configured。这就是 Kubernetes 厉害的地方，apply 配置文件可以立即生效。

现在在次使用 get 命令确保一切运行正常。

kubectl get deployment

# NAME             READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment   3/3     3            3           68m

kubectl get pod

# NAME                              READY   STATUS    RESTARTS   AGE
# api-deployment-66cdd98546-l9x8q   1/1     Running   0          7m26s
# api-deployment-66cdd98546-mbfw9   1/1     Running   0          7m31s
# api-deployment-66cdd98546-pntxv   1/1     Running   0          7m21s

三个 pod 都在运行，并且 Deployment 也运行良好。

创建数据库部署

既然 API 已经启动并且运行，是时候为数据库实例编写配置了。

在 k8s 目录中另创建一个名为 postgres-deployment.yaml 的文件，文件内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_PASSWORD
              value: 63eaQB9wtLqmNBpg
            - name: POSTGRES_DB
              value: notesdb

配置本身与上一次非常相似，我就不详细解释了，根据目前学到的知识你应该可以了解。

PostgreSQL 默认运行在 5432 端口上，运行 postgres 容器需要 POSTGRES_PASSWORD 变量。该密码也会用于 API 连接数据库。

POSTGRES_DB 变量是可选的，但是在该项目里是必需的，否则会初始化失败。

可以在 Docker Hub 页面上了解 postgres Docker 镜像的更多信息。在此项目中，化繁为简，副本数量设置为 1。

执行以下命令 apply 这个文件：

kubectl apply -f postgres-deployment.yaml

# deployment.apps/postgres-deployment created

通过 get 命令确保 pod 已经正常部署和运行：

kubectl get deployment

# NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
# postgres-deployment   1/1     1            1           13m

kubectl get pod

# NAME                                   READY   STATUS    RESTARTS   AGE
# postgres-deployment-76fcc75998-mwnb7   1/1     Running   0          13m

尽管 pod 已经成功部署和运行，但是数据库部署还是有很大的问题。

如果你以前使用过数据库系统，应该知道数据库是把数据存储在文件系统中。目前，数据库部署如下：

postgres 容器由 pod 封装，数据保留在容器内部的文件系统中。

现在，如果由于某种原因，容器崩溃或者封装容器的 pod 发生故障，则保存在文件系统的所有数据都将丢失。

崩溃后，Kubernetes 会创建一个新的 pod 来维持状态，但是两个 pod 之间没有任何数据转移机制。

为了解决这个问题，可以将数据存储在集群 pod 外部的单独空间中。

和管理计算实例相比，管理此类存储面临的是另一些问题。Kubernetes 中的 PersistentVolume 子系统为用户和管理员提供了一个 API，该 API 从存储的使用方式中抽象出如何提供存储的细节。

Persistent Volumes 和 Persistent Volume Claims

摘自 Kubernetes 文档 —

"持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。 持久卷是集群资源，就像节点也是集群资源一样。"

实际上，PersistentVolume 是一种从存储空间获得切片并将其保留给特定 pod 的方法。Volumes 始终由 pod 占用，而不是像 deployment 这样的高级对象占用。

如果要在具有多个 pod 的 deployment 中使用 volume，必须要执行一些附加步骤。

在 k8s 目录中创建一个名为 database-persistent-volume.yaml 的新文件，内容如下：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: database-persistent-volume
spec:
  storageClassName: manual
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

apiVersion、 kind 和 metadata 与其它配置文件里的用法一致，在 spec 字段里，有一些新字段：

• spec.storageClassName 指示 volume 的名称。假设云提供商有三种可用的存储。slow、 fast 和 very fast 。从云存储上获取的存储方式取决于支付的金额。如果需要 very fast 存储，则需要支付更多的费用。这些不同类型的存储就是 classes。在本例里我使用 manual，在本地集群里可以使用任何你喜欢的选项。
• spec.capacity.storage 代表 volume 的存储大小。在此项目中设置了 5GB 的存储空间。
• spec.accessModes 设置卷的访问模式。一共有三种存储模式，ReadWriteOnce 代表该 volume 可以通过单个 node 以读写方式安装。ReadWriteMany 则代表该 volume 可以被多个 node 以读写的方式安装。ReadOnlyMany 意味着该 volume 可以被多个 node 以只读的方式安装。
• spec.hostPath 是特定于开发者的。它将本地单 node 集群的目录映射为 persistent volume。/mnt/data 意味着保存在持久卷（persistent volume）中的数据位于集群的 /mnt/data 文件夹内。

执行下面的命令 apply 配置文件：

kubectl apply -f database-persistent-volume.yaml

# persistentvolume/database-persistent-volume created

现在使用 get 命令确定 volume 创建成功：

kubectl get persistentvolume

# NAME                         CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
# database-persistent-volume   5Gi        RWO            Retain           Available           manual                  58s

现在已经创建了 persistent volume，需要让 postgres pod 访问它，可以通过PersistentVolumeClaim (PVC) 。

persistent volume 声明是 pod 对存储的要求。假设在集群中有很多 volumes。该声明将定义必需满足 pod 的需求的 volume 的特征。

一个类似的的例子是从商店购买 SSD。销售员向你展示了如下模型：

现在你和销售员要求至少 200GB 的存储容量，并且驱动器的型号是 NVME。

MODEL1 是容量小于 200GB 的 SATA，与你的要求不符，MODEL 3 容量大于 200GB，但是不是 NVME 接口的。只有 MODEL2 是容量大于 200GB 并且接口是 NVME 的。正是需要的。

销售人员向你展示的 SSD models 就等同于 persistent volumes，你的要求就等同于 persistent volume 声明。

在 k8s 目录下创建一个名为 database-persistent-volume-claim.yaml 的新文件，文件内容如下：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-persistent-volume-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

apiVersion、 kind 和 metadata 和之前的作用一致。

• spec.storageClass 表示存储类型的声明配置文件。 着意味着将任何设置为 manual 的 spec.storageClass 的 PersistentVolume 都适合此类声明。如果有多个设置为 manual 的 volumes ，那么将获得其中任意一个的声明。如果没有 class 为 manual 的 volume，那就动态配置一个。
• spec.accessModes 在此设置访问模式。这表明该声明希望使用具有 ReadWriteOnce 的 accessMode。假设有两个设置为 manual 的 volumes 。其中一个将其 accessModes 设置为 ReadWriteOnce，另一个设置为 ReadWriteMany。该声明将获取其中的 ReadWriteOnce 。
• resources.requests.storage 是此声明所需要的存储量 2Gi 并不意味着给定的卷必须恰好具有 2GB 的存储容量 。而是意味着它至少要有 2GB。你应该还记得之前将存储容量设置为 5GB，大于 2GB。

执行下面的命令 apply 文件：

kubectl apply -f database-persistent-volume-claim.yaml

# persistentvolumeclaim/database-persistent-volume-claim created

使用 get 命令确定 volume 已经成功创建：

kubectl get persistentvolumeclaim

# NAME                               STATUS   VOLUME                       CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# database-persistent-volume-claim   Bound    database-persistent-volume   5Gi        RWO            manual         37s

查看 VOLUME 列，这个声明与之前创建的 database-persistent-volume 持久卷绑定 ，在看一下 CAPACITY，它是 5Gi，因为该声明要求 volume 至少有 2GB 的存储容量。

Persistent Volumes 的动态预配置

在上一小节，你已经创建了一个 persistent volume，然后创建了一个声明，但是如果以前没有设置任何 persistent volume 该怎么办呢？

在这种情况下，将自动设置与声明兼容的持久卷。

开始之前，先执行如下命令删除之前创建的 persistent volume 和 persistent volume 声明：

kubectl delete persistentvolumeclaim --all

# persistentvolumeclaim "database-persistent-volume-claim" deleted

kubectl delete persistentvolumeclaim --all

# persistentvolume "database-persistent-volume" deleted

打开 database-persistent-volume-claim.yaml 文件将内容更新为如下内容：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-persistent-volume-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

我已经从文件中删除了 spec.storageClass 字段，现在重新 apply database-persistent-volume-claim.yaml 文件（无需应用 database-persistent-volume.yaml 文件）：

kubectl apply -f database-persistent-volume-claim.yaml

# persistentvolumeclaim/database-persistent-volume-claim created

现在使用 get 命令查看声明信息：

kubectl get persistentvolumeclaim

# NAME                               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
# database-persistent-volume-claim   Bound    pvc-525ae8af-00d3-4cc7-ae47-866aa13dffd5   2Gi        RWO            standard       2s

正如你看到的，已经提供了名为 pvc-525ae8af-00d3-4cc7-ae47-866aa13dffd5 且存储容量为 2Gi 的 volume，将其动态绑定到了声明。

该项目的剩余部分使用静态或者动态预配置 persistent volume 都可以。我会使用动态配置。

通过 Pods 连接 Volumes

现在你已经创建了一个 persistent volume 和声明，是时候让数据库 pod 使用该 volume 了。

可以把之前小节创建的 persistent volume 声明连接到 pod 上。打开 postgres-deployment.yaml 文件，将内容更新如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      # volume configuration for the pod
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: database-persistent-volume-claim
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          # volume mounting configuration for the container
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
              subPath: postgres
          env:
            - name: POSTGRES_PASSWORD
              value: 63eaQB9wtLqmNBpg
            - name: POSTGRES_DB
              value: notesdb

我在此配置文件中添加了两个字段。

• spec.volumes 字段包含了供 pod 查找 persistent volume 申明的必要信息。 spec.volumes.name 可以是你想要的任何东西。spec.volumes.persistentVolumeClaim.claimName 必需与 database-persistent-volume-claim.yaml 文件中的 metadata.name 值相匹配。
• containers.volumeMounts 包含容器挂载的 volume 所必需的信息。containers.volumeMounts.name 必需与 spec.volumes.name 中的值相匹配。containers.volumeMounts.mountPath 代表 volume 挂载的目录。/var/lib/postgresql/data 是 PostgreSQL 的默认数据目录。containers.volumeMounts.subPath 表示将在 volume 创建的目录。假设你与其它的 pod 正在使用相同的 volume。保存在 /var/lib/postgresql/data 目录中的所有数据都将进入 volume 的 postgres 路径下。

现在执行下面的命令重新 apply postgres-deployment.yaml 文件：

kubectl apply -f postgres-deployment.yaml

# deployment.apps/postgres-deployment configured

现在，已经进行了正确的数据库部署，数据丢失的风险小了很多。

想要在这里提及的是，目前数据库部署中只有一个副本，如果有多个副本，那么情况会有所不同，

多个 pod 在不知道彼此存在情况下访问相同的 volume 会产生灾难性的后果 ，在 volume 内为 pod 创建子目录可以解决这个问题。

组装起来

现在已经运行了 API 和数据库，是时候建立网络并做一些后续工作了。

在前面的章节中已经了解到 Kubernetes 中的网络设置，在开始编写服务之前，先看看我为项目制定的联网计划。

• 数据库只使用 ClusterIP service 在集群内暴露，不允许任何外部流量访问。
• API 部署服务将暴露给外部世界，用户将与 API 通信，API 与数据库通信。

之前通过 LoadBalancer service 将应用暴露给了外部世界，ClusterIP 则再集群中公开应用，并且不允许外部流量访问。

鉴于数据库服务应仅在集群内可用 ，因此 ClusterIP service 服务非常适合此方案。

在 k8s 目录下创建一个名为 postgres-cluster-ip-service.yaml 的文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: postgres-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: postgres
  ports:
    - port: 5432
      targetPort: 5432

ClusterIP 的配置文件与 LoadBalancer 的配置文件差不多，唯一的不同的是 spec.type 。

现在，这个文件就清晰了。5432 是 PostgreSQL 运行的默认端口。所以也要集群内暴露 5432 。

接下来是 LoadBalancer service 的配置文件，负责将 API 暴露给外界。创建一个名为 api-load-balancer-service.yaml 的文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: api-load-balancer-service
spec:
  type: LoadBalancer
  ports:
    - port: 3000
      targetPort: 3000
  selector:
    component: api

此配置与上一节中的配置相同。API 运行在容器内的 3000 端口，所以也要在集群中暴露此端口。

最后要做的是要将环境变量添加到 API deployment 中。打开 api-deployment.yaml 文件并按照如下更新其内容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          env:
            - name: DB_CONNECTION
              value: pg
            - name: DB_HOST
              value: postgres-cluster-ip-service
            - name: DB_PORT
              value: '5432'
            - name: DB_USER
              value: postgres
            - name: DB_DATABASE
              value: notesdb
            - name: DB_PASSWORD
              value: 63eaQB9wtLqmNBpg

之前，spec.containers.env 下面只有 DB_CONNECTION 变量，新涉及到的字段如下：

• DB_HOST 表示数据库服务的地址。在非容器化环境中，该值通常为 127.0.0.1。但是在 Kubernetes 环境中，并不知道数据库容器的 IP 地址。因此只需使用公开的数据库 service 的名字即可 。
• DB_PORT 是数据库 service 公开的端口，即 5432。
• DB_USER 用于连接数据库的用户，默认的用户名是 postgres。
• DB_DATABASE API 将要连接的数据库，必须与 postgres-deployment.yaml 文件中的 spec.containers.env.DB_DATABASE 值相同。
• DB_PASSWORD 用于连接数据库的密码，必须与 postgres-deployment.yaml 文件中的 spec.containers.env.DB_PASSWORD 值相匹配。

完成此操作后就可以测试 API 了。在执行操作之前，执行一下下面的命令 apply 所有的配置文件：

kubectl apply -f k8s

# deployment.apps/api-deployment created
# service/api-load-balancer-service created
# persistentvolumeclaim/database-persistent-volume-claim created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

如果遇到任何错误，只需删除所有的资源并重新 apply 文件即可。service、persistent volumes、persistent volume 声明会立即创建。

用 get 命令确保所有的部署都已经启动且运行：

kubectl get deployment

# NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
# api-deployment        3/3     3            3           106s
# postgres-deployment   1/1     1            1           106s

从 READY 列中可以看出，所有的 pod 都已经启动并且正在运行。执行 minikube 的 service 命令访问 API。

minikube service api-load-balancer-service

# |-----------|---------------------------|-------------|-----------------------------|
# | NAMESPACE |           NAME            | TARGET PORT |             URL             |
# |-----------|---------------------------|-------------|-----------------------------|
# | default   | api-load-balancer-service |        3000 | http://172.19.186.112:31546 |
# |-----------|---------------------------|-------------|-----------------------------|
# * Opening service default/api-load-balancer-service in default browser...

API 会在默认浏览器里立即打开：

这时 API 的默认响应，还可以通过 Insomnia 或者 Postman 来测试 http://172.19.186.112:31546/ API 的完整 CRUD 功能。

可以将 API 源代码随附的测试作为文档查看。只需打开 api/tests/e2e/api/routes/notes.test.js 文件即可，如果你有 JavaScript 和express 的经验，那么理解这个文件会很容易。

使用 Ingress Controller

目前为止，已经使用 ClusterIP 在集群内公开了的应用程序，使用 LoadBalancer 把应用暴露给集群外。

尽管我已经引用了 LoadBalancer 作为引用于集群外部公开应用程序的的标准 service，但是它还有一些缺点。

当使用 LoadBalancer services 在云环境中公开应用程序时，必需单独为每个公开的服务付费。这在大型项目下回非常昂贵。

还有另一种成为 NodePort 的 service，可以代替 LoadBalancer service。

NodePort 在集群所有节点上打开一个特定的端口，并处理通过该打开端口的所有流量。

你知道，service 将多个 pod 组合在一起，并控制他们的访问方式。通过公开端口到达 service 的任何请求都将最终在正确的容器中。

用于创建 NodePort 的实例配置文件如下：

apiVersion: v1
kind: Service
metadata:
  name: hello-kube-node-port
spec:
  type: NodePort
  ports:
    - port: 8080
      targetPort: 8080
      nodePort: 31515
  selector:
    component: web

这里的 spec.ports.nodePort 字段值必须在 30000 和 32767 之间，此范围超出了各种服务通常所使用的常用端口。端口的数字位数很多。、

尝试用 NodePort service 替换前面几节创建的 LoadBalancer service，这应该不难，算是对所学知识的简单测试。

创建 Ingress 可以解决此问题，澄清一下，Ingress 不是一种 service，相反，它位于各个 service 前面，充当路由器的角色。

在集群中使用 Ingress 资源用到了 IngressController。可以在 Kubernetes 文档 中找到可用 的 ingress controllers 列表。

设置 NGINX Ingress Controller

在此例中，通过向其添加 front end 来扩展 notes API。使用 Ingress 来暴露应用，而不是使用诸如 LoadBalancer 或者 NodePort 之类的 service。

将要使用的而控制器是 NGINX Ingress Controller，在此 NGINX 将用于不同 service 请求的路由。NGINX Ingress Controller 使 Kubernetes 集群的 NGINX 配置变的更容易。

项目代码在 fullstack-notes-application 路径下：

.
├── api
├── client
├── docker-compose.yaml
├── k8s
│   ├── api-deployment.yaml
│   ├── database-persistent-volume-claim.yaml
│   ├── postgres-cluster-ip-service.yaml
│   └── postgres-deployment.yaml
├── nginx
└── postgres

5 directories, 1 file

你会看到 k8s 目录，包含在上一个小节中除了 api-load-balancer-service.yaml 文件的所有的配置文件。

原因是，在该项目中，旧的 LoadBalancer service 将被 Ingress 代替。另外，无需公开 API，而是将前端应用程序公开即可。

在开始编写新文件之前，先看看架构。

用户访问前端应用程序并提交必要的数据，然后前端应用程序将提交的数据转发到后端 API。

然后 API 将数据保留在数据库中，并将其发送回前端应用程序。然后使用 NGINX 实现请求的路由。

可以查看 nginx/production.conf 文件了解如何设置此路由。

现在实现目标所必需的网络如下：

具体如下：

• Ingress 将充当此应用程序的入口点和路由器，这是一个 NGINX 类型的 Ingress，因此端口是 nginx 的默认端口 80。
• 到 / 的每个请求都会被路由到前端应用（左侧的服务）处理。因此，如果应用程序的 URL 是 https://kube-notes.test ，那么所有的 https://kube-notes.test/foo 或者 https://kube-notes.test/bar 都会由前端应用程序处理。
• 到 /api 的每个请求都会被路由到后端的 API （右侧的服务）处理。因此，如果 URL 是 https://kube-notes.test，那么所有的 https://kube-notes.test/api/foo 或者 https://kube-notes.test/api/bar 都会由后端 API 处理。

完全可以将 Ingress service 配置与子域名一起使用，而不是向这样的路径，这里的设计使用路径的方式。

在本小节中，必需编写四个新的配置文件：

• ClusterIP 是 API deployment 的配置。
• Deployment 是 front-end 应用的配置。
• ClusterIP 是 front-end 应用的配置。
• Ingress 是路由的配置。

前三个文件我会快速的过一下。

第一个文件是 api-cluster-ip-service.yaml 配置，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: api-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: api
  ports:
    - port: 3000
      targetPort: 3000

尽管在上一小节中，将 API 直接暴露给了外界，但在本小节中，Ingress 承担起了这个任务，同时使用 ClusterIP 在内部公开 API。

配置不言自明，无需过多解释。

接下来创建一个名为 client-deployment.yaml 的文件来运行前端应用，内容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: fhsinchy/notes-client
          ports:
            - containerPort: 8080
          env:
            - name: VUE_APP_API_URL
              value: /api

它几乎与 api-deployment.yaml 文件相同，很好理解。

VUE_APP_API_URL 环境变量表示 API 请求应该转发的路径。这些转发请求将依次由Ingress 处理。

需要另一个 ClusterIP service 来公开客户端应用程序。创建一个名为 client-cluster-ip-service.yaml 的新文件，内容如下：

apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 8080
      targetPort: 8080

描述的是运行在集群上默认暴露在 8080 端口上的前端应用。

在完成了旧配置之后，下一个配置是 ingress-service.yaml 文件，内容如下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-service
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
  rules:
    - http:
        paths:
          - path: /?(.)
            backend:
              serviceName: client-cluster-ip-service
              servicePort: 8080
          - path: /api/?(.)
            backend:
              serviceName: api-cluster-ip-service
              servicePort: 3000

该文件有一些新配置，也很好理解：

• Ingress API 仍处于测试阶段，所以 apiVersion 是 extensions/v1beta1。尽管处于 beta 版本，该 API 很稳定，可以直接在生产环境中使用。
• kind 和 metadata.name 字段和之前配置相同。
• metadata.annotations 可以包含有关 Ingress 配置的信息。kubernetes.io/ingress.class: nginx 表示 Ingress 对象应该由 ingress-nginx 控制器控制。nginx.ingress.kubernetes.io/rewrite-target 表示重写目标 URL 的地方。
• spec.rules.http.paths 包含在 nginx/production.conf 文件中看到的各个路径的路由配置。 paths.path 表示路由的路径，backend.serviceName 是上述路径应该匹配的 service。backend.servicePort 是服务内部的端口。
• /?(._)_ 和 /api/?(._) 是简单的正则表达式，表示 ?(.*) 部分会被路由到指定的服务。

配置重写的方式会时不时发生变化，具体可以查看官方文档。

在 apply 新的配置之前，使用 addons 命令激活 minikube 的 ingress 插件，用法如下：

minikube addons <option> <addon name

执行如下命令激活 ingress 插件：

minikube addons enable ingress

# ? Verifying ingress addon...
# ? The 'ingress' addon is enabled

可以对 addon 命令使用 disable 选项来禁用插件，查看官网文档了解 addon 命令的更多信息。

插件激活后，可以 apply 配置文件，建议在 apply 新资源之前删除所有的资源（service、deployment 和 persistent volume claims）。

kubectl delete ingress --all

# ingress.extensions "ingress-service" deleted

kubectl delete service --all

# service "api-cluster-ip-service" deleted
# service "client-cluster-ip-service" deleted
# service "kubernetes" deleted
# service "postgres-cluster-ip-service" deleted

kubectl delete deployment --all

# deployment.apps "api-deployment" deleted
# deployment.apps "client-deployment" deleted
# deployment.apps "postgres-deployment" deleted

kubectl delete persistentvolumeclaim --all

# persistentvolumeclaim "database-persistent-volume-claim" deleted

kubectl apply -f k8s

# service/api-cluster-ip-service created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# ingress.extensions/ingress-service created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

使用 get 命令来确保所有的资源都已经创建成功。当全部运行后，可以通过 minikube 集群的 IP 地址访问该应用程序。执行如下命令获取 IP 地址：

minikube ip

# 172.17.0.2

还可以通过运行 Ingress 来获取此 IP 的地址：

kubectl get ingress

# NAME              CLASS    HOSTS   ADDRESS      PORTS   AGE
# ingress-service   <none>   *       172.17.0.2   80      2m33s

IP 和 端口分别在 ADDRESS 和 PORTS 端口列下。访问 127.17.0.2:80，可以直接进入 notes 应用程序。

可以在此应用中执行简单的 CRUD 操作，端口 80 是 NGINX 的默认端口，因此可以省略 URL 中的端口号。

如果你了解如何配置 NGINX，可以使用 ingress controller 执行很多操作。毕竟，这就是控制器的用途 - 将 NGINX 的配置存储在 Kubernetes 的 ConfigMap 上，将会在下一部分中学习。

Kubernetes 中的 Secret 和配置

目前为止，部署中使用纯文本形式存储了敏感信息，如 POSTGRES_PASSWORD，这并不是最佳实践。

可以用 Secret 将值存储在集群中，这是存储密码、token 等的更安全的方法。

在 Windows 命令行中，下一步可能无法正常工作，可以使用 git 终端或者 cmder 完成此任务。

需要将数据转换成 base64 数据才能将信息存储在 Secret 中。如果纯文本密码为 63eaQB9wtLqmNBpg ，执行以下命令获取 base64 版本。

echo -n "63eaQB9wtLqmNBpg" | base64

# NjNlYVFCOXd0THFtTkJwZw==

此步骤是必要的，参数必需是 base64 格式的，现在在 k8s 目录下创建一个 postgres-secret.yaml 文件，内容如下：

apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
data:
  password: NjNlYVFCOXd0THFtTkJwZw==

apiVersion、kind 和 metadata 的意义无需解释，data 字段就是真实的密文。

如上，创建了一个键值对，键是 password， 值是 NjNlYVFCOXd0THFtTkJwZw==。将使用 metadata.name 值在其他配置文件中作为获取密码值的 Secret 的标识。

按如下更新 postgres-deployment.yaml 文件，以在数据库配置中使用此密码：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: postgres
  template:
    metadata:
      labels:
        component: postgres
    spec:
      volumes:
        - name: postgres-storage
          persistentVolumeClaim:
            claimName: database-persistent-volume-claim
      containers:
        - name: postgres
          image: fhsinchy/notes-postgres
          ports:
            - containerPort: 5432
          volumeMounts:
            - name: postgres-storage
              mountPath: /var/lib/postgresql/data
              subPath: postgres
          env:
              # not putting the password directly anymore
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password
            - name: POSTGRES_DB
              value: notesdb

如上，除了 spec.template.spec.continers.env 字段外，所有的字段介绍过。

之前用于存储密码的 name 环境变量是纯文本。但是现在是 valueFrom.secretKeyRef 字段。

这里的 name 字段是指刚刚创建的 Secret 的名字，key 值是指 Secret 配置文件键值对中的键。Kubernetes 将在内部将编码后的值解码为纯文本。

除了数据库配置，你还需按如下所示更新 api-deployment.yaml 文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          env:
            - name: DB_CONNECTION
              value: pg
            - name: DB_HOST
              value: postgres-cluster-ip-service
            - name: DB_PORT
              value: '5432'
            - name: DB_USER
              value: postgres
            - name: DB_DATABASE
              value: notesdb
              # not putting the password directly anymore
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password

现在执行下面的命令 apply 这些新的配置文件：

kubectl apply -f k8s

# service/api-cluster-ip-service created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# secret/postgres-secret created
# ingress.extensions/ingress-service created
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created

取决于集群的状态不同，输出可能会不同。

谨慎起见，先删除所有的资源然后在 apply 配置文件来创建他们。

使用 get 命令检查并确保所有的 pod 都已经启动并且正在运行。

使用 minikube IP 访问 notes 应用程序并尝试创建新的 notes， 来测试新的配置。

minikube ip

# 172.17.0.2

访问 127.17.0.2:80，你应该会直接进入 Notes 应用程序。

还有一种无需任何配置文件即可创建 secret 的方法，执行如下命令，使用 kubectl 创建相同的 Secret。

kubectl create secret generic postgres-secret --from-literal=password=63eaQB9wtLqmNBpg

# secret/postgres-secret created

这是一种更方便的方法，因为可以跳过整个 base64 编码步骤。在这种情况下，secret 会被自动编码。

ConfigMap 和 Secret 类似，一般用于非隐私的的信息。

在 k8s 目录下创建一个名为 api-config-map.yaml 的文件，把 API deployment 里所有的其余的环境变量放在 ConfigMap 里：

apiVersion: v1 
kind: ConfigMap 
metadata:
  name: api-config-map 
data:
  DB_CONNECTION: pg
  DB_HOST: postgres-cluster-ip-service
  DB_PORT: '5432'
  DB_USER: postgres
  DB_DATABASE: notesdb

apiVersion、 kind 和 metadata 无需解释。data 字段是以键值对形式的环境变量。

和 Secret 不同，此处的 key 必需与 API 所需的 key 匹配。因此，我从 api-deployment.yaml 文件中复制了一些变量，并稍作修改后粘贴到了此处。

要在 API deployment 中使用 secret，打开 api-deployment.yaml 文件并做如下修改：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
        - name: api
          image: fhsinchy/notes-api
          ports:
            - containerPort: 3000
          # not putting environment variables directly
          envFrom:
            - configMapRef:
                name: api-config-map
          env:
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgres-secret
                  key: password

文件除了 spec.template.spec.containers.env 字段外几乎没有改变。

我已经将环境变量移到了 ConfigMap 中。spec.template.spec.containers.envFrom 用来从 ConfigMap 中获取数据。configMapRef.name 表示将从中 提取环境变量的 ConfigMap 。

然后执行下面的命令 apply 所有的配置：

kubectl apply -f k8s

# service/api-cluster-ip-service created
# configmap/api-config-map created
# deployment.apps/api-deployment created
# service/client-cluster-ip-service created
# deployment.apps/client-deployment created
# persistentvolumeclaim/database-persistent-volume-claim created
# ingress.extensions/ingress-service configured
# service/postgres-cluster-ip-service created
# deployment.apps/postgres-deployment created
# secret/postgres-secret created

取决于集群的状态，输出可能会不同。

谨慎起见，先删除所有的 Kubernetes 资源然后在 apply configs 创建他们。

使用 get 命令确保 pod 已经启动并运行，使用 minikube IP 访问 notes 应用并尝试创建新的 note。

执行下面的命令获取 IP 地址。

minikube ip

# 172.17.0.2

访问 127.17.0.2:80 ，直接进入 notes 应用程序。

Secret 和 ConfigMap 还有其它一些技巧，就不在这里展开了，如果想了解，可以查看官方文档。

在 Kubernetes 中执行更新发布

既然已经在 Kubernetes 上成功部署了一个包含多个容器的应用程序，是时候学习执行更新了。

Kubernetes 很神奇，将容器更新为较新版本的镜像比较麻烦，有很多种方式更新容器，这里不会涉及到所有的方法。

相反，我将直接进入更新容器时主要采取的方法。如果打开 client-deployment.yaml 文件并查看 spec.template.spec.containers 字段，会看到下面的配置：

containers:
    - name: client
      image: fhsinchy/notes-client

如上，在 image 字段中，没有使用任何镜像标签。现在，如果你认为在镜像尾部添加 :latest 将确保部署始终拉取最新的镜像，那你可就大错特错了。

我通常采用最简单的路径。之前提到过，在某些情况下，使用命令式而不是声明式是一个好主意，创建一个 Secret 或者更新容器就是这种情况。

可以用来执行更新的命令是 set 命令，其通用语法如下：

kubectl set image <resource type>/<resource name> <container name>=<image name with tag>

资源类型为 deployment，资源名称为 client-deployment。可以在 client-deployment.yaml 文件内的 containers 字段找到容器的名称，本例中为 client 。

我已经构建了带有标签 edge 的 fhsinchy/notes-client 镜像，将使用它来更新 fhsinchy/notes-client 的版本。

最终命令如下：

kubectl set image deployment/client-deployment client=fhsinchy/notes-client:edge

# deployment.apps/client-deployment image updated

由于 Kubernetes 将重新创建所有的 pod，执行此更新可能需要一段时间，可以运行 get 命令来了解是否所有的 pod 都已经启动并且成功运行。

重新创建后，使用 minikube IP 访问 notes 应用并尝试创建新的 notes。可以执行下面的命令获取 IP：

minikube ip

# 172.17.0.2

通过访问 127.17.0.2:80 应该可以直接进入 notes 应用程序。

鉴于我还未对应用程序代码进行任何实际更改，因此所有的内容都将保持不变。你可以使用 describe 命令来确保 pod 正在使用新的镜像。

kubectl describe pod client-deployment-849bc58bcc-gz26b | grep 'Image'

# Image:          fhsinchy/notes-client:edge
# Image ID:       docker-pullable://fhsinchy/notes-client@sha256:58bce38c16376df0f6d1320554a56df772e30a568d251b007506fd3b5eb8d7c2

grep 命令在 Mac 和 Linux 可以直接使用，如果你使用的是 Windows，使用 git bash 而不是 Windows 命令行。

尽管强制性更新过程有些繁琐，但是通过好的 CI/CD 流程可以使其变得更加容易。

组合 Configurations

尽管其中只有三个容器，但该项目中的配置文件数量已经非常庞大了。

实际上可以按照如下方式组合配置文件：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: client
  template:
    metadata:
      labels:
        component: client
    spec:
      containers:
        - name: client
          image: fhsinchy/notes-client
          ports:
            - containerPort: 8080
          env:
            - name: VUE_APP_API_URL
              value: /api
              
---

apiVersion: v1
kind: Service
metadata:
  name: client-cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: client
  ports:
    - port: 8080
      targetPort: 8080

如上，我已经使用界定符（---）组合了 client-deployment.yaml 和 client-cluster-ip-service.yaml 文件。尽管有可能在容器数量很多的项目中减少文件，但我还是建议将他们分开，更简洁、更干净。

答疑

在本节中，我将列出你使用 Kubernetes 时可能遇到的一些常见问题。

• 如果你在 Windows 或者 Mac 使用 Docker 的 minikube，Ingress 插件可能并没有生效。、
• 如果你在 Mac 上运行了Laravel Valet，并且将 HyperKit 驱动程序用于minikube，会联网失败。关闭 minikube 服务可以解决此问题。
• 如果你有一台 Ryzen (mine is R5 1600) PC，并且正在运行 Windows 10，由于缺少内嵌虚拟化支持 VirtualBox 可能会启动失败。必须在 Windows 10 （Pro、Enterprise 和 Education）上安装 Hyper-V 驱动程序，对于家庭版，很遗憾没有该选项。
• 如果你在 Windows 10 (Pro, Enterprise 和 Education) 上使用用于 minikube 的 Hyper-V 驱动，VM 可能会启动失败，并显示 内存不足的消息。不要紧张，执行 minikube start 重新启动 VM。
• 如果你在 Windows 命令行中看到本文执行的某些命令丢失，或者功能异常，请改用 git 命令行或者 cmder 。

我建议在你的系统上安装一个 Linux 发行版，并将 Docker 驱动程序用于 minikube。目前为止，这是最快也是最可靠的设置。

结论

衷心感谢你花了这么长时间阅读本文，希望你享受学习过程，并了解了 Kubernetes 的基础知识。

你可以关注我的推特 @frhnhsin 或者在 LinkedIn /in/farhanhasin 上与我联系。

原文：The Kubernetes Handbook，作者：Farhan Hasin Chowdhury

Linux 是最流行的基于 Unix 的操作系统之一。它是开源的，并在世界各地的许多行业中广泛应用。

Linux 操作系统的一项重要功能是命令行界面（CLI），它允许用户通过 Shell 与计算机进行交互。Linux Shell 是一个 REPL（Read，Evaluate，Print，Loop）环境，用户可以在其中输入命令，然后 Shell 执行该命令并返回一个结果。

ls 命令是可以从 CLI 列出文件或目录的众多 Linux 命令之一。

在本文中，我们将深入探讨 ls 命令以及常用的一些选项。

先决条件

• 具有目录和文件的计算机
• 安装一个 Linux 发行版
• 在 CLI 上导航的基本知识
• 你脸上的笑容 :)

Linux ls 命令

ls 命令用于在 Linux 和其他基于 Unix 的操作系统中列出文件或目录。

就像使用 GUI 在文件浏览器或文件夹中导航一样，默认情况下，ls 命令可以列出当前目录中的所有文件或目录，并通过命令行进一步操作它们。

启动终端并输入 ls 以查看实际效果：

如何使用选项列出目录中的文件

ls 命令还接受一些标志（也称为选项），这些标志是更改终端中文件或目录的展示方式的附加信息。

换句话说，标志改变了 ls 命令的工作方式：

 ls [flags] [directory]

PS：整篇文章中使用的内容一词是指列出的文件和目录，而不是文件/目录的实际内容。

列出当前工作目录中的文件

输入 ls 命令以列出当前工作目录的内容：

列出另一个目录中的文件

键入 ls [directory path here] 命令以列出另一个目录的内容：

列出根目录中的文件

输入 ls / 命令以列出根目录的内容：

列出父目录中的文件

键入ls .. 命令以列出上一级父目录的内容。 使用 ls ../.. 表示列出父目录的父目录的内容：

列出用户主目录（/home/user）中的文件

键入ls ~ 命令以列出用户主目录中的内容：

仅列出目录

输入 ls -d * / 命令仅列出目录：

列出带有子目录的文件

键入 ls * 命令以列出目录及其子目录的内容：

递归列出文件

输入 ls -R 命令以列出所有文件和目录并逐级展示子目录内的目录和文件：

如果有很多文件，这可能需要很长时间才能完成，因为将打印出每个目录中的每个文件。可以改为指定一个目录来运行此命令，如：ls Downloads -R

列出文件的大小

键入ls -s 命令（s 为小写字母）以列出文件或目录的大小：

以长格式列出文件

键入ls -l 命令以表格格式列出目录的内容，其列包括：

• 内容权限
• 内容链接数
• 内容的所有者
• 内容组的所有者
• 内容大小（以字节为单位）
• 内容的最后修改日期/时间
• 文件或目录名称

以可读的文件大小长格式列出文件

键入ls -lh 命令以上面相同的表格格式列出文件或目录，但用另一列表示每个文件/目录的大小：

请注意，当文件或目录的大小大于 1024 字节时，大小以字节（B）、兆字节（MB）、千兆字节（GB）或 TB（TB）列出。

列出文件，包括隐藏文件

键入 ls -a 命令以列出包括隐藏的文件或目录。在 Linux 中，任何以 . 开头的文件都被视为隐藏文件：

以长格式列出包括隐藏文件的文件

输入 ls -l -a 或 ls -a -l 或 ls -la 或 ls -al 命令以表格格式列出文件或目录，并提供包括隐藏文件或目录在内的更多信息：

列出文件并按日期和时间排序

键入ls -t 命令以列出文件或目录，并按降序（从最大到最小）按上次修改的日期和时间排序。

还可以添加 -r 标志来反转排序顺序，如下所示：ls -tr：

列出文件并按文件大小排序

键入ls -S（S 为大写）命令以列出文件或目录，并按日期或时间降序排列（从大到小）。

还可以添加 -r 标志来反转排序顺序，如下所示：ls -Sr：

列出文件并将结果输出到文件

输入ls> output.txt 命令，将前一个命令的输出打印到 output.txt 文件中。可以使用前面讨论过的任何标志，例如 -la －这里的关键是结果将输出到文件中而不记录到命令行中。

然后，可以根据需要使用该文件，也可以使用 cat output.txt 展示该文件的内容：

总结

还有很多命令可以和 ls 组合使用，以根据需要列出文件和目录。 要记住，可以一次将多个命令组合在一起。

假设要以长格式列出文件（包括隐藏文件），然后按文件大小排序。 命令是 ls -alS，这是 ls -l，ls -a 和 ls -S 的组合。

如果忘记了任何命令或不确定该怎么做，则可以运行 ls --help 或 man ls，这将显示一本手册，包含了 ls 命令的所有选项：

感谢阅读！

原文：The Linux LS Command – How to List Files in a Directory + Option Flags，作者：Bolaji Ayodeji

根据 Stack Overflow 开发者调查-2020，Docker 是开发者 #1 最想要的平台、#2 最喜欢的平台，以及#3 最流行的平台。

尽管 Docker 功能强大，但上手确并不容易。因此，本书将介绍从基础知识到更高层次容器化的的所有内容。读完整本书之后，你应该能够：

• 容器化（几乎）任何应用程序
• 将自定义 Docker 镜像上传到在线仓库
• 使用 Docker Compose 处理多个容器

前提

• 熟悉 Linux 终端操作
• 熟悉 JavaScript（稍后的的演示项目用到了 JavaScript）

目录

• 容器化和 Docker 简介
• 怎样安装 Docker
  • 怎样在 macOS 里安装 Docker
  • 怎样在 Windows 上安装 Docker
  • 怎样在 Linux 上安装 Docker
• 初识 Docker - Docker 基本知识介绍
  • 什么是容器？
  • 什么是 Docker 镜像？
  • 什么是仓库？
  • Docker 架构概述
  • 全景图
• Docker 容器操作基础知识
  • 怎样运行容器
  • 怎样公开端口
  • 如何使用分离模式
  • 怎样列表展示容器
  • 怎样命名或者重命名一个容器
  • 怎样停止或者杀死运行中的容器
  • 怎样重新启动容器
  • 怎样创建而不运行容器
  • 怎样移除挂起的容器
  • 怎样以交互式模式运行容器
  • 怎样在容器里执行命令
  • 如何处理可执行镜像
• Docker 镜像操作基础知识
  • 如何创建 Docker 镜像
  • 如何标记 Docker 镜像
  • 如何删除、列表展示镜像
  • 理解 Docker 镜像的分层
  • 怎样从源码构建 NGINX
  • 怎样优化 Docker 镜像
  • 拥抱 Alpine Linux
  • 怎样创建可执行 Docker 镜像
  • 怎样在线共享 Docker 镜像
• 怎样容器化 JavaScript 应用
  • 如何编写开发 Dockerfile
  • 如何在 Docker 中使用绑定挂载
  • 如何在 Docker 中使用匿名卷
  • 如何在 Docker 中执行多阶段构建
  • 如何忽略不必要的文件
• Docker 中的网络操作基础知识
  • Docker 网络基础
  • 如何在 Docker 中创建用户定义的桥接网络
  • 如何在 Docker 中将容器连接到网络
  • 如何在 Docker 中从网络分离容器
  • 如何删除 Docker 中的网络
• 如何容器化多容器 JavaScript 应用程序
  • 如何运行数据库服务
  • 如何在 Docker 中使用命名卷
  • 如何从 Docker 中的容器访问日志
  • 如何在 Docker 中创建网络并连接数据库服务
  • 如何编写 Dockerfile
  • 如何在正在运行的容器中执行命令
  • 如何在 Docker 中编写管理脚本
• 如何使用 Docker-Compose 组合项目
  • Docker Compose 基础
  • 如何在 Docker Compose 中启动服务
  • 如何在 Docker Compose 中列表展示服务
  • 如何在 Docker Compose 正在运行的服务中执行命令
  • 如何访问 Docker Compose 中正在运行的服务日志
  • 如何在 Docker Compose 中停止服务
  • 如何在 Docker Compose 中编写全栈应用程序
• 结论

项目代码

可以在这个仓库中找到示例项目的代码，欢迎 ⭐。

完整代码在 containerized 分支。

贡献

这本书是完全开源的，欢迎高质量的贡献。可以在这个仓库中找到完整的内容。

我通常先在本书的 GitBook 版本上进行更改和更新，然后在将其发布在 freeCodeCamp 专栏。你可以在这个链接中找到本书的最新编辑中版本。别忘了评分支持。

如果你正在寻找本书的完整稳定版本，那么 freeCodeCamp 是最好的选择。如果你有所收获，请分享给你的朋友。

不管阅读本书的哪个版本，都不要忘记留下你的意见。欢迎提出建设性的批评。

容器化和 Docker 简介

摘自 IBM,

容器化意味着封装或打包软件代码及其所有依赖项，以便它可以在任何基础架构上统一且一致地运行。

换句话说，容器化可以将软件及其所有依赖项打包在一个自包含的软件包中，这样就可以省略麻烦的配置，直接运行。

举一个现实生活的场景。假设你已经开发了一个很棒的图书管理应用程序，该应用程序可以存储所有图书的信息，还可以为别人提供图书借阅服务。

如果列出依赖项，如下所示：

• Node.js
• Express.js
• SQLite3

理论上应该是这样。但是实际上还要搞定其他一些事情。 Node.js 使用了 node-gyp 构建工具来构建原生加载项。根据官方存储库中的安装说明，此构建工具需要 Python 2 或 3 和相应的的 C/C ++ 编译器工具链。

考虑到所有这些因素，最终的依赖关系列表如下：

• Node.js
• Express.js
• SQLite3
• Python 2 or 3
• C/C++ tool-chain

无论使用什么平台，安装 Python 2 或 3 都非常简单。在 Linux 上，设置 C/C ++ 工具链也非常容易，但是在 Windows 和 Mac 上，这是一项繁重的工作。

在 Windows 上，C++ 构建工具包有数 GB 之大，安装需要花费相当长的时间。在 Mac 上，可以安装庞大的 Xcode 应用程序，也可以安装小巧的 Xcode 命令行工具包。

不管安装了哪一种，它都可能会在 OS 更新时中断。实际上，该问题非常普遍，甚至连官方仓库都专门提供了 macOS Catalina 的安装说明。

这里假设你已经解决了设置依赖项的所有麻烦，并且已经准备好开始。这是否意味着现在开始就一帆风顺了？当然不是。

如果你使用 Linux 而同事使用 Windows 该怎么办？现在，必须考虑如何处理这两个不同的操作系统不一致的路径，或诸如 nginx 之类的流行技术在 Windows 上未得到很好的优化的事实，以及诸如 Redis 之类的某些技术甚至都不是针对 Windows 预先构建的。

即使你完成了整个开发，如果负责管理服务器的人员部署流程搞错了，该怎么办？

所有这些问题都可以通过以下方式解决：

• 在与最终部署环境匹配的隔离环境（称为容器）中开发和运行应用程序。
• 将你的应用程序及其所有依赖项和必要的部署配置放入一个文件（称为镜像）中。
• 并通过具有适当授权的任何人都可以访问的中央服务器（称为仓库）共享该镜像。

然后，你的同事就可以从仓库中下载镜像，可以在没有平台冲突的隔离环境中运行应用，甚至可以直接在服务器上进行部署，因为该镜像也可以进行生产环境配置。

这就是容器化背后的想法：将应用程序放在一个独立的程序包中，使其在各种环境中都可移植且可回溯。

现在的问题是：Docker 在这里扮演什么角色？

正如我之前讲的，容器化是一种将一切统一放入盒子中来解决软件开发过程中的问题的思想。

这个想法有很多实现。Docker 就是这样的实现。这是一个开放源代码的容器化平台，可让你对应用程序进行容器化，使用公共或私有仓库共享它们，也可以编排它们。

目前，Docker 并不是市场上唯一的容器化工具，却是最受欢迎的容器化工具。我喜欢的另一个容器化引擎是 Red Hat 开发的 Podman。其他工具，例如 Google 的 Kaniko，CoreOS 的 rkt 都很棒，但和 Docker 还是有差距。

此外，如果你想了解容器的历史，可以阅读 A Brief History of Containers: From the 1970s Till Now，它描述了该技术的很多重要节点。

怎样安装 Docker

Docker 的安装因使用的操作系统而异。但这整个过程都非常简单。

Docker可在 Mac、Windows 和 Linux 这三个主要平台上完美运行。在这三者中，在 Mac 上的安装过程是最简单的，因此我们从这里开始。

怎样在 macOS 里安装 Docker

在 Mac 上，要做的就是跳转到官方的下载页面，然后单击_Download for Mac(stable)_按钮。

你会看到一个常规的 Apple Disk Image 文件，在该文件的内有 Docker 应用程序。所要做的就是将文件拖放到 Applications 目录中。

只需双击应用程序图标即可启动 Docker。应用程序启动后，将看到 Docker 图标出现在菜单栏上。

现在，打开终端并执行 docker --version 和 docker-compose --version 以验证是否安装成功。

怎样在 Windows 上安装 Docker

在 Windows 上，步骤几乎相同，当然还需要执行一些额外的操作。安装步骤如下：

1. 跳转到此站点，然后按照说明在 Windows 10 上安装 WSL2。
2. 然后跳转到官方下载页面 并单击 Download for Windows(stable) 按钮。
3. 双击下载的安装程序，然后使用默认设置进行安装。

安装完成后，从开始菜单或桌面启动 Docker Desktop。Docker 图标应显示在任务栏上。

现在，打开 Ubuntu 或从 Microsoft Store 安装的任何发行版。执行 docker --version 和 docker-compose --version 命令以确保安装成功。

也可以从常规命令提示符或 PowerShell 访问 Docker，只是我更喜欢使用 WSL2。

怎样在 Linux 上安装 Docker

在 Linux 上安装 Docker 的过程有所不同，具体操作取决于你所使用的发行版，它们之间差异可能更大。但老实说，安装与其他两个平台一样容易（如果不能算更容易的话）。

Windows 或 Mac 上的 Docker Desktop 软件包是一系列工具的集合，例如Docker Engine、Docker Compose、Docker Dashboard、Kubernetes 和其他一些好东西。

但是，在 Linux 上，没有得到这样的捆绑包。可以手动安装所需的所有必要工具。 不同发行版的安装过程如下：

• 如果你使用的是 Ubuntu，则可以遵循官方文档中的在 Ubuntu 上安装 Docker 引擎部分。
• 对于其他发行版，官方文档中提供了 不同发行版的安装指南。
  • 在 Debian上安装 Docker Engine
  • 在 Fedora 上安装 Docker Engine
  • 在 CentOS 上安装 Docker Engine
• 如果你使用的发行版未在文档中列出，则可以参考从二进制文件安装 Docker 引擎指南。
• 无论参考什么程序，都必须完成一些非常重要的 Linux 的安装后续步骤。
• 完成 docker 安装后，必须安装另一个名为 Docker Compose 的工具。 可以参考官方文档中的 Install Docker Compose 指南。

安装完成后，打开终端并执行 docker --version 和 docker-compose --version 以确保安装成功。

尽管无论使用哪个平台，Docker 的性能都很好，但与其他平台相比，我更喜欢 Linux。在整本书中，我将使用Ubuntu 20.10 或者 Fedora 33。

一开始就需要阐明的另一件事是，在整本书中，我不会使用任何 GUI 工具操作 Docker。

我在各个平台用过很多不错的 GUI 工具，但是介绍常见的 docker 命令是本书的主要目标之一。

初识 Docker - 介绍 Docker 基本知识

已经在计算机上启动并运行了 Docker，现在该运行第一个容器了。打开终端并执行以下命令：

docker run hello-world

# Unable to find image 'hello-world:latest' locally
# latest: Pulling from library/hello-world
# 0e03bdcc26d7: Pull complete 
# Digest: sha256:4cf9c47f86df71d48364001ede3a4fcd85ae80ce02ebad74156906caff5378bc
# Status: Downloaded newer image for hello-world:latest
# 
# Hello from Docker!
# This message shows that your installation appears to be working correctly.
# 
# To generate this message, Docker took the following steps:
#  1. The Docker client contacted the Docker daemon.
#  2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
#     (amd64)
#  3. The Docker daemon created a new container from that image which runs the
#     executable that produces the output you are currently reading.
#  4. The Docker daemon streamed that output to the Docker client, which sent it
#     to your terminal.
#
# To try something more ambitious, you can run an Ubuntu container with:
#  $ docker run -it ubuntu bash
# 
# Share images, automate workflows, and more with a free Docker ID:
#  https://hub.docker.com/
#
# For more examples and ideas, visit:
#  https://docs.docker.com/get-started/

hello-world 镜像是使用 Docker 进行最小化容器化的一个示例。它有一个从 hello.c 文件编译的程序，负责打印出终端看到的消息。

现在，在终端中，可以使用 docker ps -a 命令查看当前正在运行或过去运行的所有容器：

docker ps -a

# CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                     PORTS               NAMES
# 128ec8ceab71        hello-world         "/hello"            14 seconds ago      Exited (0) 13 seconds ago                      exciting_chebyshev

在输出中，使用 hello-world 镜像运行了名为 exciting_chebyshev 的容器，其容器标识为 128ec8ceab71。它已经在 Exited (0) 13 seconds ago，其中 (0) 退出代码表示在容器运行时未发生任何错误。

现在，为了了解背后发生的事情，必须熟悉 Docker 体系结构和三个非常基本的容器化概念，如下所示：

• 容器
• 镜像
• 仓库

我已经按字母顺序列出了这三个概念，并且将从列表中的第一个开始介绍。

什么是容器？

在容器化世界中，没有什么比容器的概念更基础的了。

官方 Docker resources 网站说 -

容器是应用程序层的抽象，可以将代码和依赖项打包在一起。容器不虚拟化整个物理机，仅虚拟化主机操作系统。

可以认为容器是下一代虚拟机。

就像虚拟机一样，容器是与主机系统是彼此之间完全隔离的环境。它也比传统虚拟机轻量得多，因此可以同时运行大量容器，而不会影响主机系统的性能。

容器和虚拟机实际上是虚拟化物理硬件的不同方法。两者之间的主要区别是虚拟化方式。

虚拟机通常由称为虚拟机监控器的程序创建和管理，例如 Oracle VM VirtualBox，VMware Workstation，KVM，Microsoft Hyper-V 等等。 该虚拟机监控程序通常位于主机操作系统和虚拟机之间，充当通信介质。

每个虚拟机都有自己的 guest 操作系统，该操作系统与主机操作系统一样消耗资源。

在虚拟机内部运行的应用程序与 guest 操作系统进行通信，该 guest 操作系统在与虚拟机监控器进行通信，后者随后又与主机操作系统进行通信，以将必要的资源从物理基础设施分配给正在运行的应用程序。

虚拟机内部运行的应用程序与物理基础设施之间存在很长的通信链。在虚拟机内部运行的应用程序可能只拥有少量资源，因为 guest 操作系统会占用很大的开销。

与虚拟机不同，容器以更智能的方式完成虚拟化工作。在容器内部没有完整的 guest 操作系统，它只是通过容器运行时使用主机操作系统，同时保持隔离 – 就像传统的虚拟机一样。

容器运行时（即 Docker）位于容器和主机操作系统之间，而不是虚拟机监控器中。容器与容器运行时进行通信，容器运行时再与主机操作系统进行通信，以从物理基础设施中获取必要的资源。

由于消除了整个主机操作系统层，因此与传统的虚拟机相比，容器的更轻量，资源占用更少。

为了说明这一点，请看下面的代码片段：

uname -a
# Linux alpha-centauri 5.8.0-22-generic #23-Ubuntu SMP Fri Oct 9 00:34:40 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

docker run alpine uname -a
# Linux f08dbbe9199b 5.8.0-22-generic #23-Ubuntu SMP Fri Oct 9 00:34:40 UTC 2020 x86_64 Linux

在上面的代码片段中，在主机操作系统上执行了 uname -a 命令以打印出内核详细信息。然后在下一行，我在运行 Alpine Linux 的容器内执行了相同的命令。

从输出中可以看到，该容器确实正在使用主机操作系统中的内核。这证明了容器虚拟化主机操作系统而不是拥有自己的操作系统这一点。

如果你使用的是 Windows 计算机，则会发现所有容器都使用 WSL2 内核。发生这种情况是因为 WSL2 充当了 Windows 上 Docker 的后端。在 macOS 上，默认后端是在 HyperKit 虚拟机管理程序上运行的 VM。

什么是 Docker 镜像？

镜像是分层的自包含文件，充当创建容器的模板。它们就像容器的冻结只读副本。 镜像可以通过仓库进行共享。

过去，不同的容器引擎具有不同的镜像格式。但是后来，开放式容器计划（OCI）定义了容器镜像的标准规范，该规范被主要的容器化引擎所遵循。这意味着使用 Docker 构建的映像可以与 Podman 等其他运行时一起使用，而不会有兼容性问题。

容器只是处于运行状态的镜像。当从互联网上获取镜像并使用该镜像运行容器时，实际上是在先前的只读层之上创建了另一个临时可写层。

在本书的后续部分中，这一概念将变得更加清晰。但就目前而言，请记住，镜像是分层只读文件，其中保留着应用程序所需的状态。

什么是仓库？

已经了解了这个难题的两个非常重要的部分，即 Containers 和 Images。最后一个是 Registry。

镜像仓库是一个集中式的位置，可以在其中上传镜像，也可以下载其他人创建的镜像。 Docker Hub 是 Docker 的默认公共仓库。另一个非常流行的镜像仓库是 Red Hat 的 Quay。

在本书中，我将使用 Docker Hub 作为首选仓库。

可以免费在 Docker Hub 上共享任意数量的公共镜像。供世界各地的人们下载免费使用。可在我的个人资料（fhsinchy）页面上找到我上传的镜像。

除了 Docker Hub 或 Quay，还可以创建自己的镜像仓库来托管私有镜像。计算机中还运行着一个本地仓库，该仓库缓存从远程仓库提取的镜像。

Docker 架构概述

既然已经熟悉了有关容器化和 Docker 的大多数基本概念，那么现在是时候了解 Docker 作为软件的架构了。

该引擎包括三个主要组件：

1. Docker 守护程序： 守护程序（dockerd）是一个始终在后台运行并等待来自客户端的命令的进程。守护程序能够管理各种 Docker 对象。
2. Docker 客户端： 客户端（docker）是一个命令行界面程序，主要负责传输用户发出的命令。
3. REST API： REST API 充当守护程序和客户端之间的桥梁。使用客户端发出的任何命令都将通过 API 传递，最终到达守护程序。

根据官方文档,

“ Docker 使用客户端-服务器体系结构。Docker client 与 Docker daemon 对话，daemon 繁重地构建、运行和分发 Docker 容器”。

作为用户，通常将使用客户端组件执行命令。然后，客户端使用 REST API 来访问长期运行的守护程序并完成工作。

全景图

好吧，说的够多了。 现在是时候了解刚刚学习的所有这些知识如何和谐地工作了。在深入解释运行 docker run hello-world 命令时实际发生的情况之前，看一下下面的图片：

该图像是在官方文档中找到的图像的略微修改版本。 执行命令时发生的事件如下：

1. 执行 docker run hello-world 命令，其中 hello-world 是镜像的名称。
2. Docker 客户端访问守护程序，告诉它获取 hello-world 镜像并从中运行一个容器。
3. Docker 守护程序在本地仓库中查找镜像，并发现它不存在，所以在终端上打印 Unable to find image 'hello-world:latest' locally。
4. 然后，守护程序访问默认的公共仓库 Docker Hub，拉取 hello-world 镜像的最新副本，并在命令行中展示 Unable to find image 'hello-world:latest' locally。
5. Docker 守护程序根据新拉取的镜像创建一个新容器。
6. 最后，Docker 守护程序运行使用 hello-world 镜像创建的容器，该镜像在终端上输出文本。

Docker 守护程序的默认行为是在 hub 中查找本地不存在的镜像。但是，拉取了镜像之后，它将保留在本地缓存中。因此，如果再次执行该命令，则在输出中将看不到以下几行：

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
0e03bdcc26d7: Pull complete
Digest: sha256:d58e752213a51785838f9eed2b7a498ffa1cb3aa7f946dda11af39286c3db9a9
Status: Downloaded newer image for hello-world:latest

如果公共仓库中有可用镜像的更新版本，则守护程序将再次拉取该镜像。那个 :latest 是一个标记。镜像通常包含有意义的标记以指示版本或内部版本。稍后，将更详细地介绍这一点。

Docker 容器操作基础知识

在前面的部分中，已经了解了 Docker 的构建模块，还使用 docker run 命令运行了一个容器。

在本节中，将详细介绍容器的操作。容器操作是每天要执行的最常见的任务之一，因此，正确理解各种命令至关重要。

但是请记住，这并不是可以在 Docker 上执行的所有命令的详尽列表。我只会介绍最常见的那些。当想知道某一命令的更多用法时，可以访问 Docker 命令行的官方参考。

怎样运行容器

之前，已经使用 docker run 来使用 hello-world 镜像创建和启动容器。此命令的通用语法如下：

docker run <image name>

尽管这是一个完全有效的命令，但是有一种更好的方式可以将命令分配给 docker 守护程序。

在版本 1.13 之前，Docker 仅具有前面提到的命令语法。后来，命令行经过了重构具有了以下语法：

docker <object> <command> <options>

使用以下语法：

• object 表示将要操作的 Docker 对象的类型。这可以是 container、image、network 或者 volume 对象。
• command 表示守护程序要执行的任务，即 run 命令。
• options 可以是任何可以覆盖命令默认行为的有效参数，例如端口映射的 --publish 选项。

现在，遵循此语法，可以将 run 命令编写如下：

docker container run <image name>

image name 可以是在线仓库或本地系统中的任何镜像。例如，可以尝试使用fhsinchy / hello-dock 镜像运行容器。 该镜像包含一个简单的 Vue.js应用程序，该应用程序在容器内部的端口 80 上运行。

请在终端上执行以下命令以使用此镜像运行容器：

docker container run --publish 8080:80 fhsinchy/hello-dock

# /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
# /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
# /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
# 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf
# 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
# /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
# /docker-entrypoint.sh: Configuration complete; ready for start up

该命令不言自明。唯一需要说明的部分是 --publish 8080:80 部分，将在下一个小节中进行说明。

怎样公开端口

容器是隔离的环境。主机系统对容器内部发生的事情一无所知。因此，从外部无法访问在容器内部运行的应用程序。

要允许从容器外部进行访问，必须将容器内的相应端口发布到本地网络上的端口。--publish 或 -p 选项的通用语法如下：

--publish <host port>:<container port>

在上一小节中编写了 --publish 8080:80 时，这意味着发送到主机系统端口 8080 的任何请求都将转发到容器内的端口 80。

现在要在浏览器上访问该应用程序，只需访问 http://127.0.0.1:8080。

可以在终端窗口按下 ctrl + c 组合键或关闭终端窗口来停止容器。

如何使用分离模式

run 命令的另一个非常流行的选项是 ---detach 或 -d 选项。 在上面的示例中，为了使容器继续运行，必须将终端窗口保持打开状态。关闭终端窗口会停止正在运行的容器。

这是因为，默认情况下，容器在前台运行，并像从终端调用的任何其他普通程序一样将其自身附加到终端。

为了覆盖此行为并保持容器在后台运行，可以在 run 命令中包含 --detach 选项，如下所示：

docker container run --detach --publish 8080:80 fhsinchy/hello-dock

# 9f21cb77705810797c4b847dbd330d9c732ffddba14fb435470567a7a3f46cdc

与前面的示例不同，这次不会看到很多文字，而只获得新创建的容器的 ID。

提供选项的顺序并不重要。 如果将 --publish 选项放在 --detach 选项之前，效果相同。

使用 run 命令时必须记住的一件事是镜像名称必须最后出现。如果在镜像名称后放置任何内容，则将其作为参数传递给容器入口点（在在容器内执行命令小节做了解释），可能会导致意外情况。

怎样列表展示容器

container ls 命令可用于列出当前正在运行的容器。执行以下命令：

docker container ls

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                  NAMES
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   5 seconds ago       Up 5 seconds        0.0.0.0:8080->80/tcp   gifted_sammet

一个名为 gifted_sammet 的容器正在运行。它是在 5 seconds ago 前创建的，状态为 Up 5 seconds，这表明自创建以来，该容器一直运行良好。

CONTAINER ID 为 9f21cb777058，这是完整容器 ID 的前 12 个字符。完整的容器 ID 是 9f21cb77705810797c4b847dbd330d9c732ffddba14fb435470567a7a3f46cdc，该字符长 64 个字符。在上一节中 docker container run 命令行的输的就是完整的容器 ID 。

列表的 PORTS 列下，本地网络的端口 8080 指向容器内的端口 80。name gifted_sammet 是由 Docker 生成的，可能与你的计算机的不同。

container ls 命令仅列出系统上当前正在运行的容器。为了列出过去运行的所有容器，可以使用 --all 或 -a 选项。

docker container ls --all

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                     PORTS                  NAMES
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   2 minutes ago       Up 2 minutes               0.0.0.0:8080->80/tcp   gifted_sammet
# 6cf52771dde1        fhsinchy/hello-dock   "/docker-entrypoint.…"   3 minutes ago       Exited (0) 3 minutes ago                          reverent_torvalds
# 128ec8ceab71        hello-world           "/hello"                 4 minutes ago       Exited (0) 4 minutes ago                          exciting_chebyshev

如你所见，列表 reverent_torvalds 中的第二个容器是较早创建的，并以状态代码 0 退出，这表明在容器运行期间未产生任何错误。

怎样命名或者重命名一个容器

默认情况下，每个容器都有两个标识符。 如下：

• CONTAINER ID - 64 个字符的随机字符串。
• NAME - 两个随机词的组合，下划线连接。

基于这两个随机标识符来引用容器非常不方便。如果可以使用自定义的名称来引用容器，那就太好了。

可以使用 --name 选项来命名容器。要使用名为 hello-dock-container 的 fhsinchy/hello-dock 镜像运行另一个容器，可以执行以下命令：

docker container run --detach --publish 8888:80 --name hello-dock-container fhsinchy/hello-dock

# b1db06e400c4c5e81a93a64d30acc1bf821bed63af36cab5cdb95d25e114f5fb

本地网络上的 8080 端口被 gifted_sammet 容器（在上一小节中创建的容器）占用了。这就是为什么必须使用其他端口号（例如 8888）的原因。要进行验证，执行 container ls 命令：

docker container ls

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                  NAMES
# b1db06e400c4        fhsinchy/hello-dock   "/docker-entrypoint.…"   28 seconds ago      Up 26 seconds       0.0.0.0:8888->80/tcp   hello-dock-container
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   4 minutes ago       Up 4 minutes        0.0.0.0:8080->80/tcp   gifted_sammet

一个名为 hello-dock-container 的新容器已经启动。

甚至可以使用 container rename 命令来重命名旧容器。该命令的语法如下：

docker container rename <container identifier> <new name>

要将 gifted_sammet 容器重命名为 hello-dock-container-2，可以执行以下命令：

docker container rename gifted_sammet hello-dock-container-2

该命令不会产生任何输出，但是可以使用 container ls 命令来验证是否已进行更改。 rename 命令不仅适用于处于运行状态的容器和还适用于处于停止状态的容器。

怎样停止或者杀死运行中的容器

可以通过简单地关闭终端窗口或单击 ctrl + c 来停止在前台运行的容器。但是，不能以相同方式停止在后台运行的容器。

有两个命令可以完成此任务。 第一个是 container stop 命令。该命令的通用语法如下：

docker container stop <container identifier>

其中 container identifier 可以是容器的 ID 或名称。

应该还记得上一节中启动的容器。它仍在后台运行。使用 docker container ls 获取该容器的标识符（在本演示中，我将使用 hello-dock-container 容器）。现在执行以下命令来停止容器：

docker container stop hello-dock-container

# hello-dock-container

如果使用 name 作为标识符，则 name 将作为输出返回。stop 命令通过发送信号SIGTERM 来正常关闭容器。如果容器在一定时间内没有停止运行，则会发出 SIGKILL 信号，该信号会立即关闭容器。

如果要发送 SIGKILL 信号而不是 SIGTERM 信号，则可以改用 container kill 命令。container kill 命令遵循与 stop 命令相同的语法。

docker container kill hello-dock-container-2

# hello-dock-container-2

怎样重新启动容器

当我说重启时，我指的如下是两种情况：

• 重新启动先前已停止或终止的容器。
• 重新启动正在运行的容器。

正如上一小节中学到的，停止的容器保留在系统中。如果需要，可以重新启动它们。container start 命令可用于启动任何已停止或终止的容器。该命令的语法如下：

docker container start <container identifier>

可以通过执行 container ls --all 命令来获取所有容器的列表，然后寻找状态为 Exited 的容器。

docker container ls --all

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                        PORTS               NAMES
# b1db06e400c4        fhsinchy/hello-dock   "/docker-entrypoint.…"   3 minutes ago       Exited (0) 47 seconds ago                         hello-dock-container
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   7 minutes ago       Exited (137) 17 seconds ago                       hello-dock-container-2
# 6cf52771dde1        fhsinchy/hello-dock   "/docker-entrypoint.…"   7 minutes ago       Exited (0) 7 minutes ago                          reverent_torvalds
# 128ec8ceab71        hello-world           "/hello"                 9 minutes ago       Exited (0) 9 minutes ago                          exciting_chebyshev

现在要重新启动 hello-dock-container 容器，可以执行以下命令：

docker container start hello-dock-container

# hello-dock-container

现在，可以使用 container ls 命令查看正在运行的容器列表，以确保该容器正在运行。

默认情况下，container start 命令以分离模式启动容器，并保留之前进行的端口配置。因此，如果现在访问 http：//127.0.0.1：8080，应该能够像以前一样访问 hello-dock 应用程序。

现在，在想重新启动正在运行的容器，可以使用 container restart 命令。container restart 命令遵循与 container start 命令完全相同的语法。

docker container restart hello-dock-container-2

# hello-dock-container-2

这两个命令之间的主要区别在于，container restart 命令尝试停止目标容器，然后再次启动它，而 start 命令只是启动一个已经停止的容器。

在容器停止的情况下，两个命令完全相同。但是如果容器正在运行，则必须使用container restart 命令。

怎样创建而不运行容器

到目前为止，在本节中，已经使用 container run 命令启动了容器，该命令实际上是两个单独命令的组合。这两个命令如下：

• container create 命令从给定的镜像创建一个容器。
• container start 命令将启动一个已经创建的容器。

现在，要使用这两个命令执行运行容器部分中显示的演示，可以执行以下操作：

docker container create --publish 8080:80 fhsinchy/hello-dock

# 2e7ef5098bab92f4536eb9a372d9b99ed852a9a816c341127399f51a6d053856

docker container ls --all

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS               NAMES
# 2e7ef5098bab        fhsinchy/hello-dock   "/docker-entrypoint.…"   30 seconds ago      Created                                 hello-dock

通过 container ls --all 命令的输出可以明显看出，已经使用 fhsinchy/hello-dock 镜像创建了一个名称为 hello-dock 的容器。 容器的 STATUS 目前处于 Created 状态，并且鉴于其未运行，因此不使用 --all 选项就不会列出该容器。

一旦创建了容器，就可以使用 container start 命令来启动它。

docker container start hello-dock

# hello-dock

docker container ls

# CONTAINER ID        IMAGE                 COMMAND                  CREATED              STATUS              PORTS                  NAMES
# 2e7ef5098bab        fhsinchy/hello-dock   "/docker-entrypoint.…"   About a minute ago   Up 29 seconds       0.0.0.0:8080->80/tcp   hello-dock

容器 STATUS 已从 Created 更改为 Up 29 seconds，这表明容器现在处于运行状态。端口配置也显示在以前为空的 PORTS 列中。

尽管可以在大多数情况下使用 container run 命令，但本书稍后还会有一些情况要求使用 container create 命令。

怎样移除挂起的容器

如你所见，已被停止或终止的容器仍保留在系统中。这些挂起的容器可能会占用空间或与较新的容器发生冲突。

可以使用 container rm 命令删除停止的容器。 通用语法如下：

docker container rm <container identifier>

要找出哪些容器没有运行，使用 container ls --all 命令并查找状态为 Exited 的容器。

docker container ls --all

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS                      PORTS                  NAMES
# b1db06e400c4        fhsinchy/hello-dock   "/docker-entrypoint.…"   6 minutes ago       Up About a minute           0.0.0.0:8888->80/tcp   hello-dock-container
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   10 minutes ago      Up About a minute           0.0.0.0:8080->80/tcp   hello-dock-container-2
# 6cf52771dde1        fhsinchy/hello-dock   "/docker-entrypoint.…"   10 minutes ago      Exited (0) 10 minutes ago                          reverent_torvalds
# 128ec8ceab71        hello-world           "/hello"                 12 minutes ago      Exited (0) 12 minutes ago                          exciting_chebyshev

从输出中可以看到，ID为 6cf52771dde1 和 128ec8ceab71 的容器未运行。要删除 6cf52771dde1，可以执行以下命令：

docker container rm 6cf52771dde1

# 6cf52771dde1

可以使用 container ls 命令检查容器是否被删除。也可以一次删除多个容器，方法是将其标识符一个接一个地传递，每个标识符之间用空格隔开。

也可以使用 container prune 命令来一次性删除所有挂起的容器。

可以使用 container ls --all 命令检查容器列表，以确保已删除了挂起的容器：

docker container ls --all

# CONTAINER ID        IMAGE                 COMMAND                  CREATED             STATUS              PORTS                  NAMES
# b1db06e400c4        fhsinchy/hello-dock   "/docker-entrypoint.…"   8 minutes ago       Up 3 minutes        0.0.0.0:8888->80/tcp   hello-dock-container
# 9f21cb777058        fhsinchy/hello-dock   "/docker-entrypoint.…"   12 minutes ago      Up 3 minutes        0.0.0.0:8080->80/tcp   hello-dock-container-2

如果按照本书的顺序进行操作，则应该只在列表中看到 hello-dock-container 和 hello-dock-container-2。 建议停止并删除两个容器，然后再继续进行下一部分。

container run 和 container start 命令还有 --rm 选项，它们表示希望容器在停止后立即被移除。 执行以下命令，使用 --rm 选项启动另一个 hello-dock 容器：

docker container run --rm --detach --publish 8888:80 --name hello-dock-volatile fhsinchy/hello-dock

# 0d74e14091dc6262732bee226d95702c21894678efb4043663f7911c53fb79f3

可以使用 container ls 命令来验证容器是否正在运行：

docker container ls

# CONTAINER ID   IMAGE                 COMMAND                  CREATED              STATUS              PORTS                  NAMES
# 0d74e14091dc   fhsinchy/hello-dock   "/docker-entrypoint.…"   About a minute ago   Up About a minute   0.0.0.0:8888->80/tcp   hello-dock-volatile

现在，如果停止了容器，使用 container ls --all 命令再次检查：

docker container stop hello-dock-volatile

# hello-dock-volatile

docker container ls --all

# CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

该容器已被自动删除。从现在开始，我将对大多数容器使用 --rm 选项。不需要的地方我会明确提到。

怎样以交互式模式运行容器

到目前为止，只运行了 hello-world 镜像或 fhsinchy/hello-dock 镜像。这些镜像用于执行非交互式的简单程序。

好吧，镜像并不是那么简单。镜像可以将整个 Linux 发行版封装在其中。

流行的发行版，例如 Ubuntu，Fedora 和 Debian 都在 hub 有官方的 Docker 镜像。编程语言，例如 python、php、[go](https：// hub.docker.com/_/golang) 或类似 node 和 deno 都有其官方镜像。

这些镜像不但仅运行某些预配置的程序。还将它们配置为默认情况下运行的 shell 程序。在镜像是操作系统的情况下，它可以是诸如 sh 或 bash 之类的东西，在镜像是编程语言或运行时的情况下，通常是它们的默认语言的 shell。

正如可能从以前的计算机中学到的一样，shell 是交互式程序。被配置为运行这样的程序的镜像是交互式镜像。这些镜像需要在 container run 命令中传递特殊的 -it 选项。

例如，如果通过执行 docker container run ubuntu 使用 ubuntu 镜像运行一个容器，将不会发生任何事情。但是，如果使用 -it 选项执行相同的命令，会直接进入到 Ubuntu 容器内的 bash 上。

docker container run --rm -it ubuntu

# root@dbb1f56b9563:/# cat /etc/os-release
# NAME="Ubuntu"
# VERSION="20.04.1 LTS (Focal Fossa)"
# ID=ubuntu
# ID_LIKE=debian
# PRETTY_NAME="Ubuntu 20.04.1 LTS"
# VERSION_ID="20.04"
# HOME_URL="https://www.ubuntu.com/"
# SUPPORT_URL="https://help.ubuntu.com/"
# BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
# PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
# VERSION_CODENAME=focal
# UBUNTU_CODENAME=focal

从 cat /etc/os-release 命令的输出中可以看到，我确实正在与在 Ubuntu 容器中运行的 bash 进行交互。

-it 选项提供了与容器内的程序进行交互的场景。此选项实际上是将两个单独的选项混在一起。

• 选项 -i 或 --interactive 连接到容器的输入流，以便可以将输入发送到 bash。
• -t 或 --tty 选项可通过分配伪 tty 来格式化展示并提供类似本机终端的体验。

当想以交互方式运行容器时，可以使用 -it 选项。以交互式方式运行 node 镜像，如下：

docker container run -it node

# Welcome to Node.js v15.0.0.
# Type ".help" for more information.
# > ['farhan', 'hasin', 'chowdhury'].map(name => name.toUpperCase())
# [ 'FARHAN', 'HASIN', 'CHOWDHURY' ]

任何有效的 JavaScript 代码都可以在 node shell 中执行。除了输入 -it，还可以输入 --interactive --tty，效果一样，只不过更冗长。

怎样在容器里执行命令

在本书中初识 Docker 部分中，已经了解了在 Alpine Linux 容器内执行命令。 它是这样的：

docker run alpine uname -a
# Linux f08dbbe9199b 5.8.0-22-generic #23-Ubuntu SMP Fri Oct 9 00:34:40 UTC 2020 x86_64 Linux

在此命令中，在 Alpine Linux 容器中执行了 uname -a 命令。像这样的场景（要做的就是在特定的容器内执行特定的命令）非常常见。

假设想使用 base64 程序对字符串进行编码。几乎所有基于 Linux 或 Unix 的操作系统都可以使用此功能（但 Windows 则不可用）。

在这种情况下，可以使用 busybox 之类的镜像快速启动容器，然后执行命令。

使用 base64 编码字符串的通用语法如下：

echo -n my-secret | base64

# bXktc2VjcmV0

将命令传递到未运行的容器的通用语法如下：

docker container run <image name> <command>

要使用 busybox 镜像执行 base64 编码，可以执行以下命令：

docker container run --rm busybox echo -n my-secret | base64

# bXktc2VjcmV0

这里发生的是，在 container run 命令中，镜像名称后传递的任何内容都将传递到镜像的默认入口里。

入口点就像是通往镜像的网关。除可执行镜像外的大多数镜像（在使用可执行镜像小节中说明）使用 shell 或 sh 作为默认入口点。因此，任何有效的 shell 命令都可以作为参数传递给它们。

如何处理可执行镜像

在上一节中，我简要提到了可执行镜像。这些镜像旨在表现得像可执行程序。

以的 rmbyext 项目为例。这是一个简单的 Python 脚本，能够递归删除给定扩展名的文件。 要了解有关该项目的更多信息，可以查看仓库。

如果同时安装了 Git 和 Python，则可以通过执行以下命令来安装此脚本：

pip install git+https://github.com/fhsinchy/rmbyext.git#egg=rmbyext

假设的系统上已经正确设置了 Python，则该脚本应该可以在终端的任何位置使用。使用此脚本的通用语法如下：

rmbyext <file extension>

要对其进行测试，请在一个空目录下打开终端，并在其中创建具有不同扩展名的一些文件。可以使用 touch 命令来做到这一点。现在，计算机上有一个包含以下文件的目录：

touch a.pdf b.pdf c.txt d.pdf e.txt

ls

# a.pdf  b.pdf  c.txt  d.pdf  e.txt

要从该目录删除所有 pdf 文件，可以执行以下命令：

rmbyext pdf

# Removing: PDF
# b.pdf
# a.pdf
# d.pdf

该程序的可执行镜像能够将文件扩展名用作参数，并像 rmbyext 程序一样删除它们。

fhsinchy/rmbyext 镜像的行为类似。该镜像包含 rmbyext 脚本的副本，并配置为在容器内的目录 /zone上运行该脚本。

现在的问题是容器与本地系统隔离，因此在容器内运行的 rmbyext 程序无法访问本地文件系统。因此，如果可以通过某种方式将包含 pdf 文件的本地目录映射到容器内的 /zone 目录，则容器应该可以访问这些文件。

授予容器直接访问本地文件系统的一种方法是使用绑定挂载。

绑定挂载可以在本地文件系统目录（源）与容器内另一个目录（目标）之间形成双向数据绑定。这样，在目标目录中进行的任何更改都将在源目录上生效，反之亦然。

让我们看一下绑定挂载的实际应用。要使用此镜像而不是程序本身删除文件，可以执行以下命令：

docker container run --rm -v $(pwd):/zone fhsinchy/rmbyext pdf

# Removing: PDF
# b.pdf
# a.pdf
# d.pdf

已经在命令中看到了 -v $(pwd):/zone 部分，你可能已经猜到了 -v 或 --volume 选项用于为容器创建绑定挂载。该选项可以使用三个以冒号（:）分隔的字段。该选项的通用语法如下：

--volume <local file system directory absolute path>:<container file system directory absolute path>:<read write access>

第三个字段是可选的，但必须传递本地目录的绝对路径和容器内目录的绝对路径。

在这里，源目录是 /home/fhsinchy/the-zone。假设终端当前在目录中，则 $(pwd) 将替换为包含先前提到的 .pdf 和 .txt 文件的 /home/fhsinchy/the-zone。

可以在command substitution here 上了解更多信息。

--volume 或 -v 选项对 container run 以及 container create 命令均有效。我们将在接下来的部分中更详细地探讨卷，因此，如果在这里不太了解它们，请不要担心。

常规镜像和可执行镜像之间的区别在于，可执行镜像的入口点设置为自定义程序而不是 sh，在本例中为 rmbyext 程序。正如在上一小节中所学到的那样，在 container run 命令中在镜像名称之后编写的所有内容都将传递到镜像的入口点。

所以最后，docker container run --rm -v $(pwd):/zone fhsinchy/rmbyext pdf 命令转换为容器内的 rmbyext pdf 。可执行镜像并不常见，但在某些情况下可能非常有用。

Docker 镜像操作基础知识

现在，已经对如何使用公开可用的镜像运行容器有了深入的了解，是时候学习如何创建自己的镜像了。

在本部分中，将学习创建镜像，使用镜像运行容器以及在线共享镜像的基础知识。

我建议在 Visual Studio Code 中安装官方的 Docker Extension 。 这将提升开发效率。

怎样创建 Docker 镜像

正如我在初识 Docker 部分中已经解释的那样，镜像是分层的自包含文件，它们充当用于创建 Docker 容器的模板。它们就像是容器的冻结的只读副本。

为了使用程序创建镜像，必须对要从镜像中获得什么有清晰的认识。以官方 nginx 镜像为例。只需执行以下命令即可使用该镜像启动容器：

docker container run --rm --detach --name default-nginx --publish 8080:80 nginx

# b379ecd5b6b9ae27c144e4fa12bdc5d0635543666f75c14039eea8d5f38e3f56

docker container ls

# CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
# b379ecd5b6b9        nginx               "/docker-entrypoint.…"   8 seconds ago       Up 8 seconds        0.0.0.0:8080->80/tcp   default-nginx

现在，如果在浏览器中访问 http://127.0.0.1:8080，则会看到一个默认的响应页面。

看起来不错，但是，如果想制作一个自定义的 NGINX 镜像，该镜像的功能与正式镜像完全一样，但是由你自己创建，可行吗？老实说，完全可行。实际上，只需这样做。

为了制作自定义的 NGINX 镜像，必须清楚了解镜像的最终状态。我认为镜像应如下所示：

• 该镜像应预安装 NGINX，可以使用程序包管理器完成该镜像，也可以从源代码构建该镜像。
• 该镜像在运行时应自动启动 NGINX。

很简单，如果你已经克隆了本书中链接的项目仓库，请进入项目根目录并在其中查找名为 custom-nginx 的目录。

现在，在该目录中创建一个名为 Dockerfile 的新文件。Dockerfile 是指令的集合，该指令会被守护程序生成镜像。Dockerfile 的内容如下：

FROM ubuntu:latest

EXPOSE 80

RUN apt-get update && \
    apt-get install nginx -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

CMD ["nginx", "-g", "daemon off;"]

镜像是多层文件，在此文件中，编写的每一行（称为说明）都会为镜像创建一个层。

• 每个有效的 Dockerfile 均以 FROM 指令开头。该指令为生成的镜像设置基本镜像。通过在此处将 ubuntu：latest 设置为基本镜像，可以在自定义镜像中使用 Ubuntu 的所有功能，因此可以使用 apt-get 命令之类的东西来轻松安装软件包。
• EXPOSE 指令表示需要发布的端口。使用此指令并不意味着不需要 --publish 端口。仍然需要显式使用 --publish 选项。该 EXPOSE 指令的工作原理类似于文档，适用于试图使用你的镜像运行容器的人员。它还有一些其他用途，我将不在这里讨论。
• Dockerfile 中的 RUN 指令在容器 shell 内部执行命令。apt-get update && apt-get install nginx -y 命令检查更新的软件包版本并安装 NGINX。apt-get clean && rm -rf /var/lib/apt/lists/* 命令用于清除程序包缓存，因为不希望镜像中出现任何不必要的文件。这两个命令是简单的 Ubuntu 东西，没什么特别的。此处的 RUN 指令以 shell 形式编写。这些也可以以 exec 形式编写。 可以查阅官方参考了解更多信息。
• 最后，CMD 指令为镜像设置了默认命令。该指令以 exec 形式编写，此处包含三个独立的部分。这里，nginx 是指 NGINX 可执行文件。 -g 和 daemon off 是 NGINX 的选项。 在容器内将 NGINX 作为单个进程运行是一种最佳实践，因此请使用此选项。CMD 指令也可以以 shell 形式编写。 可以查阅官方参考了解更多信息。

既然具有有效的 Dockerfile，可以从中构建镜像。就像与容器相关的命令一样，可以使用以下语法来执行与镜像相关的命令：

docker image <command> <options>

要使用刚刚编写的 Dockerfile 构建镜像，请在 custom-nginx 目录中打开终端并执行以下命令：

docker image build .

# Sending build context to Docker daemon  3.584kB
# Step 1/4 : FROM ubuntu:latest
#  ---> d70eaf7277ea
# Step 2/4 : EXPOSE 80
#  ---> Running in 9eae86582ec7
# Removing intermediate container 9eae86582ec7
#  ---> 8235bd799a56
# Step 3/4 : RUN apt-get update &&     apt-get install nginx -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> Running in a44725cbb3fa
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container a44725cbb3fa
#  ---> 3066bd20292d
# Step 4/4 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in 4792e4691660
# Removing intermediate container 4792e4691660
#  ---> 3199372aa3fc
# Successfully built 3199372aa3fc

为了执行镜像构建，守护程序需要两条非常具体的信息。Dockerfile 的名称和构建上下文。在上面执行的命令中：

• docker image build 是用于构建镜像的命令。守护程序在上下文中找到任何名为 Dockerfile 的文件。
• 最后的 . 设置了此构建的上下文。上下文是指在构建过程中守护程序可以访问的目录。

现在要使用此镜像运行容器，可以将 container run 命令与在构建过程中收到的镜像 ID 结合使用。在我这里，通过上一个代码块中的 Successfully built 3199372aa3fc 行可以看到 id 为 3199372aa3fc。

docker container run --rm --detach --name custom-nginx-packaged --publish 8080:80 3199372aa3fc

# ec09d4e1f70c903c3b954c8d7958421cdd1ae3d079b57f929e44131fbf8069a0

docker container ls

# CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                  NAMES
# ec09d4e1f70c        3199372aa3fc        "nginx -g 'daemon of…"   23 seconds ago      Up 22 seconds       0.0.0.0:8080->80/tcp   custom-nginx-packaged

要进行验证，请访问 http://127.0.0.1:8080 ，应该会看到默认的响应页面。

如何标记 Docker 镜像

就像容器一样，可以为镜像分配自定义标识符，而不必依赖于随机生成的 ID。如果是镜像，则称为标记而不是命名。在这种情况下，使用 --tag 或 -t 选项。

该选项的通用语法如下：

--tag <image repository>:<image tag>

repository 通常指镜像名称，而 tag 指特定的构建或版本。

以官方 mysql 镜像为例。如果想使用特定版本的MySQL（例如5.7）运行容器，则可以执行 docker container run mysql:5.7，其中 mysql 是镜像 repository，5.7 是 tag。

为了用 custom-nginx:packaged 标签标记自定义 NGINX 镜像，可以执行以下命令：

docker image build --tag custom-nginx:packaged .

# Sending build context to Docker daemon  1.055MB
# Step 1/4 : FROM ubuntu:latest
#  ---> f63181f19b2f
# Step 2/4 : EXPOSE 80
#  ---> Running in 53ab370b9efc
# Removing intermediate container 53ab370b9efc
#  ---> 6d6460a74447
# Step 3/4 : RUN apt-get update &&     apt-get install nginx -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> Running in b4951b6b48bb
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container b4951b6b48bb
#  ---> fdc6cdd8925a
# Step 4/4 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in 3bdbd2af4f0e
# Removing intermediate container 3bdbd2af4f0e
#  ---> f8837621b99d
# Successfully built f8837621b99d
# Successfully tagged custom-nginx:packaged

除了现在可以将镜像称为 custom-nginx:packaged（而不是一些较长的随机字符串）之外，什么都不会改变。

如果在构建期间忘记为镜像添加标记，或者你想更改标记，可以使用 image tag 命令执行此操作：

docker image tag <image id> <image repository>:<image tag>

## 或者 ##

docker image tag <image repository>:<image tag> <new image repository>:<new image tag>

如何删除、列表展示镜像

就像 container ls 命令一样，可以使用 image ls 命令列出本地系统中的所有镜像：

docker image ls

# REPOSITORY     TAG        IMAGE ID       CREATED         SIZE
# <none>         <none>     3199372aa3fc   7 seconds ago   132MB
# custom-nginx   packaged   f8837621b99d   4 minutes ago   132MB

可以使用 image rm 命令删除此处列出的镜像。通用语法如下：

docker image rm <image identifier>

标识符可以是镜像 ID 或镜像仓库。 如果使用仓库，则还必须指定标记。要删除 custom-nginx:packaged 镜像，可以执行以下命令：

docker image rm custom-nginx:packaged

# Untagged: custom-nginx:packaged
# Deleted: sha256:f8837621b99d3388a9e78d9ce49fbb773017f770eea80470fb85e0052beae242
# Deleted: sha256:fdc6cdd8925ac25b9e0ed1c8539f96ad89ba1b21793d061e2349b62dd517dadf
# Deleted: sha256:c20e4aa46615fe512a4133089a5cd66f9b7da76366c96548790d5bf865bd49c4
# Deleted: sha256:6d6460a744475a357a2b631a4098aa1862d04510f3625feb316358536fcd8641

还可以使用 image prune 命令来清除所有未标记的挂起的镜像，如下所示：

docker image prune --force

# Deleted Images:
# deleted: sha256:ba9558bdf2beda81b9acc652ce4931a85f0fc7f69dbc91b4efc4561ef7378aff
# deleted: sha256:ad9cc3ff27f0d192f8fa5fadebf813537e02e6ad472f6536847c4de183c02c81
# deleted: sha256:f1e9b82068d43c1bb04ff3e4f0085b9f8903a12b27196df7f1145aa9296c85e7
# deleted: sha256:ec16024aa036172544908ec4e5f842627d04ef99ee9b8d9aaa26b9c2a4b52baa

# Total reclaimed space: 59.19MB

--force 或 -f 选项会跳过所有确认问题。也可以使用 --all 或 -a 选项删除本地仓库中的所有缓存镜像。

理解 Docker 镜像的分层

从本书的开始，我就一直在说镜像是多层文件。在本小节中，我将演示镜像的各个层，以及它们如何在该镜像的构建过程中发挥重要作用。

在本演示中，我将使用上一小节的 custom-nginx:packaged 镜像。

要可视化镜像的多个层，可以使用 image history 命令。custom-nginx:packaged 图像的各个层可以如下所示：

docker image history custom-nginx:packaged

# IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT
# 7f16387f7307        5 minutes ago       /bin/sh -c #(nop)  CMD ["nginx" "-g" "daemon…   0B                             
# 587c805fe8df        5 minutes ago       /bin/sh -c apt-get update &&     apt-get ins…   60MB                
# 6fe4e51e35c1        6 minutes ago       /bin/sh -c #(nop)  EXPOSE 80                    0B                  
# d70eaf7277ea        17 hours ago        /bin/sh -c #(nop)  CMD ["/bin/bash"]            0B                  
# <missing>           17 hours ago        /bin/sh -c mkdir -p /run/systemd && echo 'do…   7B                  
# <missing>           17 hours ago        /bin/sh -c [ -z "$(apt-get indextargets)" ]     0B                  
# <missing>           17 hours ago        /bin/sh -c set -xe   && echo '#!/bin/sh' > /…   811B                
# <missing>           17 hours ago        /bin/sh -c #(nop) ADD file:435d9776fdd3a1834…   72.9MB

此镜像有八层。最上面的一层是最新的一层，当向下移动时，这些层会变老。最顶层是通常用于运行容器的那一层。

现在，让我们仔细看看从镜像 d70eaf7277ea 到镜像 7f16387f7307 的所有镜像。我将忽略 IMAGE 是 <missing> 的最下面的四层，因为它们与我们无关。

• d70eaf7277ea 是由 /bin/sh -c #(nop) CMD ["/bin/bash"] 创建的，它指示Ubuntu 内的默认 shell 已成功加载。
• 6fe4e51e35c1 是由 /bin/sh -c #(nop) EXPOSE 80 创建的，这是代码中的第二条指令。
• 587c805fe8df 是由 /bin/sh -c apt-get update && apt-get install nginx -y && apt-get clean && rm -rf /var/lib/apt/lists/* 创建的，这是代码中的第三条指令。如果在执行此指令期间安装了所有必需的软件包，可以看到该镜像的大小为 60MB。
• 最后，最上层的 7f16387f7307 是由 /bin/sh -c #(nop) CMD ["nginx", "-g", "daemon off;"] 创建的，它为该镜像设置了默认命令。

如你所见，该镜像由许多只读层组成，每个层都记录了由某些指令触发的一组新的状态更改。当使用镜像启动容器时，会在其他层之上获得一个新的可写层。

每次使用 Docker 时都会发生这种分层现象，这是通过一个称为 union file system 的技术概念而得以实现的。 在这里，联合意味着集合论中的联合。根据 Wikipedia

它允许透明地覆盖独立文件系统（称为分支）的文件和目录，从而形成单个一致的文件系统。合并分支内具有相同路径的目录的内容将在新的虚拟文件系统内的单个合并目录中一起看到。

通过利用这一概念，Docker 可以避免数据重复，并且可以将先前创建的层用作以后构建的缓存。这样便产生了可在任何地方使用的紧凑，有效的镜像。

怎样从源码构建 NGINX

在上一小节中，了解了 FROM、EXPOSE、RUN 和 CMD 指令。在本小节中，将学到更多有关其他指令的信息。

在本小节中，将再次创建一个自定义的 NGINX 镜像。但是，不同之处在于，将从源代码构建 NGINX，而不是像上一个示例那样使用诸如 apt-get 之类的软件包管理器进行安装。

从源代码构建 NGINX，首先需要 NGINX 的源代码。 如果克隆了我的项目仓库，则会在 custom-nginx 目录中看到一个名为 nginx-1.19.2.tar.gz 的文件。将使用此归档文件作为构建 NGINX 的源。

在开始编写代码之前，先规划一下流程。 这次的镜像创建过程可以分七个步骤完成。如下：

• 获得用于构建应用程序的基础镜像，例如 ubuntu。
• 在基础镜像上安装必要的构建依赖项。
• 复制 nginx-1.19.2.tar.gz 文件到镜像里。
• 解压缩压缩包的内容并删除压缩包。
• 使用 make 工具配置构建，编译和安装程序。
• 删除解压缩的源代码。
• 运行nginx可执行文件。

现在有了一个规划，让我们开始打开旧的 Dockerfile 并按如下所示更新其内容：

FROM ubuntu:latest

RUN apt-get update && \
    apt-get install build-essential\ 
                    libpcre3 \
                    libpcre3-dev \
                    zlib1g \
                    zlib1g-dev \
                    libssl-dev \
                    -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

COPY nginx-1.19.2.tar.gz .

RUN tar -xvf nginx-1.19.2.tar.gz && rm nginx-1.19.2.tar.gz

RUN cd nginx-1.19.2 && \
    ./configure \
        --sbin-path=/usr/bin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/nginx/access.log \
        --with-pcre \
        --pid-path=/var/run/nginx.pid \
        --with-http_ssl_module && \
    make && make install

RUN rm -rf /nginx-1.19.2

CMD ["nginx", "-g", "daemon off;"]

如你所见，Dockerfile 中的代码反映了我上面提到的七个步骤。

• FROM 指令将 Ubuntu 设置为基本映像，从而为构建任何应用程序提供了理想的环境。
• RUN 指令安装了从源代码构建 NGINX 所需的标准软件包。
• 这里的 COPY 指令是新的东西。该指令负责在映像内复制 nginx-1.19.2.tar.gz 文件。 COPY 指令的通用语法是 COPY <source> <destination>，其中 source 在本地文件系统中，而 destination 在镜像内部。作为目标的 . 表示镜像内的工作目录，除非另有设置，否则默认为 /。
• 这里的第二条 RUN 指令使用 tar 从压缩包中提取内容，然后将其删除。
• 存档文件包含一个名为 nginx-1.19.2 的目录，其中包含源代码。因此，下一步，将 cd 进入该目录并执行构建过程。 可以阅读 How to Install Software from Source Code… and Remove it Afterwards 文章，以了解有关该主题的更多信息。
• 构建和安装完成后，使用 rm 命令删除 nginx-1.19.2 目录。
• 在最后一步，像以前一样以单进程模式启动 NGINX。

现在，要使用此代码构建镜像，请执行以下命令：

docker image build --tag custom-nginx:built .

# Step 1/7 : FROM ubuntu:latest
#  ---> d70eaf7277ea
# Step 2/7 : RUN apt-get update &&     apt-get install build-essential                    libpcre3                     libpcre3-dev                     zlib1g                     zlib1g-dev                     libssl-dev                     -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> Running in 2d0aa912ea47
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container 2d0aa912ea47
#  ---> cbe1ced3da11
# Step 3/7 : COPY nginx-1.19.2.tar.gz .
#  ---> 7202902edf3f
# Step 4/7 : RUN tar -xvf nginx-1.19.2.tar.gz && rm nginx-1.19.2.tar.gz
 ---> Running in 4a4a95643020
### LONG EXTRACTION STUFF GOES HERE ###
# Removing intermediate container 4a4a95643020
#  ---> f9dec072d6d6
# Step 5/7 : RUN cd nginx-1.19.2 &&     ./configure         --sbin-path=/usr/bin/nginx         --conf-path=/etc/nginx/nginx.conf         --error-log-path=/var/log/nginx/error.log         --http-log-path=/var/log/nginx/access.log         --with-pcre         --pid-path=/var/run/nginx.pid         --with-http_ssl_module &&     make && make install
#  ---> Running in b07ba12f921e
### LONG CONFIGURATION AND BUILD STUFF GOES HERE ###
# Removing intermediate container b07ba12f921e
#  ---> 5a877edafd8b
# Step 6/7 : RUN rm -rf /nginx-1.19.2
#  ---> Running in 947e1d9ba828
# Removing intermediate container 947e1d9ba828
#  ---> a7702dc7abb7
# Step 7/7 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in 3110c7fdbd57
# Removing intermediate container 3110c7fdbd57
#  ---> eae55f7369d3
# Successfully built eae55f7369d3
# Successfully tagged custom-nginx:built

这段代码还不错，但是我们可以在某些地方进行改进。

• 可以使用 ARG 指令创建自变量，而不是像 nginx-1.19.2.tar.gz 这样的文件名进行硬编码。这样，只需更改参数即可更改版本或文件名。
• 可以让守护程序在构建过程中下载文件，而不是手动下载存档。还有另一种类似于COPY 的指令，称为 ADD 指令，该指令能够从互联网添加文件。

打开 Dockerfile 文件，并按如下所示更新其内容：

FROM ubuntu:latest

RUN apt-get update && \
    apt-get install build-essential\ 
                    libpcre3 \
                    libpcre3-dev \
                    zlib1g \
                    zlib1g-dev \
                    libssl-dev \
                    -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

ARG FILENAME="nginx-1.19.2"
ARG EXTENSION="tar.gz"

ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .

RUN tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION}

RUN cd ${FILENAME} && \
    ./configure \
        --sbin-path=/usr/bin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/nginx/access.log \
        --with-pcre \
        --pid-path=/var/run/nginx.pid \
        --with-http_ssl_module && \
    make && make install

RUN rm -rf /${FILENAME}}

CMD ["nginx", "-g", "daemon off;"]

该代码几乎与先前的代码块相同，除了在第 13、14 行有一条名为 ARG 的新指令，以及在第 16 行用法了 ADD 指令。有关更新代码的说明如下：

• ARG 指令可以像其他语言一样声明变量。以后可以使用 ${argument name} 语法访问这些变量或参数。在这里，我将文件名 nginx-1.19.2 和文件扩展名 tar.gz 放在了两个单独的参数中。这样，我只需在一个地方进行更改就可以在 NGINX 的较新版本或存档格式之间进行切换。在上面的代码中，我向变量添加了默认值。变量值也可以作为 image build 命令的选项传递。你可以查阅官方参考了解更多详细信息。
• 在 ADD 指令中，我使用上面声明的参数动态形成了下载 URL。https://nginx.org/download/${FILENAME}.${EXTENSION} 行将在构建过程生成类似于 https://nginx.org/download/nginx-1.19.2.tar.gz 的内容。可以通过一次更改文件版本或扩展名的方式来更改文件版本或扩展名，这里要使用 ARG 指令。
• 默认情况下，ADD 指令不会提取从互联网获取的文件，因此在第18行使用了 tar。

其余代码几乎不变。 现在应该可以自己理解参数的用法。最后，让我们尝试从此更新的代码构建镜像。

docker image build --tag custom-nginx:built .

# Step 1/9 : FROM ubuntu:latest
#  ---> d70eaf7277ea
# Step 2/9 : RUN apt-get update &&     apt-get install build-essential                    libpcre3                     libpcre3-dev                     zlib1g                     zlib1g-dev                     libssl-dev                     -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> cbe1ced3da11
### LONG INSTALLATION STUFF GOES HERE ###
# Step 3/9 : ARG FILENAME="nginx-1.19.2"
#  ---> Running in 33b62a0e9ffb
# Removing intermediate container 33b62a0e9ffb
#  ---> fafc0aceb9c8
# Step 4/9 : ARG EXTENSION="tar.gz"
#  ---> Running in 5c32eeb1bb11
# Removing intermediate container 5c32eeb1bb11
#  ---> 36efdf6efacc
# Step 5/9 : ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .
# Downloading [==================================================>]  1.049MB/1.049MB
#  ---> dba252f8d609
# Step 6/9 : RUN tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION}
#  ---> Running in 2f5b091b2125
### LONG EXTRACTION STUFF GOES HERE ###
# Removing intermediate container 2f5b091b2125
#  ---> 2c9a325d74f1
# Step 7/9 : RUN cd ${FILENAME} &&     ./configure         --sbin-path=/usr/bin/nginx         --conf-path=/etc/nginx/nginx.conf         --error-log-path=/var/log/nginx/error.log         --http-log-path=/var/log/nginx/access.log         --with-pcre         --pid-path=/var/run/nginx.pid         --with-http_ssl_module &&     make && make install
#  ---> Running in 11cc82dd5186
### LONG CONFIGURATION AND BUILD STUFF GOES HERE ###
# Removing intermediate container 11cc82dd5186
#  ---> 6c122e485ec8
# Step 8/9 : RUN rm -rf /${FILENAME}}
#  ---> Running in 04102366960b
# Removing intermediate container 04102366960b
#  ---> 6bfa35420a73
# Step 9/9 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in 63ee44b571bb
# Removing intermediate container 63ee44b571bb
#  ---> 4ce79556db1b
# Successfully built 4ce79556db1b
# Successfully tagged custom-nginx:built

现在可以使用 custom-nginx:built 镜像来运行容器了。

docker container run --rm --detach --name custom-nginx-built --publish 8080:80 custom-nginx:built

# 90ccdbc0b598dddc4199451b2f30a942249d85a8ed21da3c8d14612f17eed0aa

docker container ls

# CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                  NAMES
# 90ccdbc0b598        custom-nginx:built   "nginx -g 'daemon of…"   2 minutes ago       Up 2 minutes        0.0.0.0:8080->80/tcp   custom-nginx-built

使用 custom-nginx:built-v2 映像的容器已成功运行。 现在可以从 http://127.0.0.1:8080 访问该容器。

这是 NGINX 的默认响应页面。可以访问官方参考网站，以了解有关可用指令的更多信息。

怎样优化 Docker 镜像

在上一个小节中构建的镜像具有功能，但是没有经过优化。为了证明我的观点，让我们使用 image ls 命令来查看镜像的大小：

docker image ls

# REPOSITORY         TAG       IMAGE ID       CREATED          SIZE
# custom-nginx       built     1f3aaf40bb54   16 minutes ago   343MB

对于仅包含 NGINX 的镜像，这太大了。 如果拉取官方镜像并检查其大小，会看到它很小：

docker image pull nginx:stable

# stable: Pulling from library/nginx
# a076a628af6f: Pull complete 
# 45d7b5d3927d: Pull complete 
# 5e326fece82e: Pull complete 
# 30c386181b68: Pull complete 
# b15158e9ebbe: Pull complete 
# Digest: sha256:ebd0fd56eb30543a9195280eb81af2a9a8e6143496accd6a217c14b06acd1419
# Status: Downloaded newer image for nginx:stable
# docker.io/library/nginx:stable

docker image ls

# REPOSITORY         TAG       IMAGE ID       CREATED          SIZE
# custom-nginx       built     1f3aaf40bb54   25 minutes ago   343MB
# nginx              stable    b9e1dc12387a   11 days ago      133MB

为了找出根本原因，让我们首先看一下 Dockerfile：

FROM ubuntu:latest

RUN apt-get update && \
    apt-get install build-essential\ 
                    libpcre3 \
                    libpcre3-dev \
                    zlib1g \
                    zlib1g-dev \
                    libssl-dev \
                    -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

ARG FILENAME="nginx-1.19.2"
ARG EXTENSION="tar.gz"

ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .

RUN tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION}

RUN cd ${FILENAME} && \
    ./configure \
        --sbin-path=/usr/bin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/nginx/access.log \
        --with-pcre \
        --pid-path=/var/run/nginx.pid \
        --with-http_ssl_module && \
    make && make install

RUN rm -rf /${FILENAME}}

CMD ["nginx", "-g", "daemon off;"]

正如在第 3 行看到的那样，RUN 指令安装了很多东西。尽管这些软件包对于从源代码构建 NGINX 是必需的，但对于运行它而言则不是必需的。

在安装的 6 个软件包中，只有两个是运行 NGINX 所必需的，即 libpcre3 和 zlib1g。 因此，一个更好的主意是在构建过程完成后，卸载其他软件包。

为此，请按如下所示更新的 Dockerfile ：

FROM ubuntu:latest

EXPOSE 80

ARG FILENAME="nginx-1.19.2"
ARG EXTENSION="tar.gz"

ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .

RUN apt-get update && \
    apt-get install build-essential \ 
                    libpcre3 \
                    libpcre3-dev \
                    zlib1g \
                    zlib1g-dev \
                    libssl-dev \
                    -y && \
    tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION} && \
    cd ${FILENAME} && \
    ./configure \
        --sbin-path=/usr/bin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/nginx/access.log \
        --with-pcre \
        --pid-path=/var/run/nginx.pid \
        --with-http_ssl_module && \
    make && make install && \
    cd / && rm -rfv /${FILENAME} && \
    apt-get remove build-essential \ 
                    libpcre3-dev \
                    zlib1g-dev \
                    libssl-dev \
                    -y && \
    apt-get autoremove -y && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

CMD ["nginx", "-g", "daemon off;"]

如你所见，在第 10 行上，一条 RUN 指令正在执行所有必要的核心操作。确切的事件链如下：

• 从第 10 行到第 17 行，安装所有必需的软件包。
• 在第 18 行，将提取源代码，并删除下载的存档。
• 从第 19 行到第 28 行，NGINX 在系统上配置，构建和安装。
• 在第 29 行，从下载的档案中提取的文件将被删除。
• 从第 30 行到第 36 行，所有不必要的软件包都将被卸载并清除缓存。运行 NGINX 需要 libpcre3 和 zlib1g 包，因此我们保留了它们。

你可能会问，为什么我要在一条 RUN 指令中做这么多工作，而不是像我们之前那样将它们很好地拆分成多个指令。 好吧，将它们拆分会是一个错误。

如果安装了软件包，然后按照单独的 RUN 说明将其删除，则它们将位于镜像的不同层中。尽管最终镜像不会包含已删除的包，但是由于它们存在于组成该图像的一层之一中，因此它们的大小仍将添加到最终镜像中。因此，请确保在单层上进行了此类更改。

让我们使用此 Dockerfile 来构建映像，并查看它们之间的区别。

docker image build --tag custom-nginx:built .

# Sending build context to Docker daemon  1.057MB
# Step 1/7 : FROM ubuntu:latest
#  ---> f63181f19b2f
# Step 2/7 : EXPOSE 80
#  ---> Running in 006f39b75964
# Removing intermediate container 006f39b75964
#  ---> 6943f7ef9376
# Step 3/7 : ARG FILENAME="nginx-1.19.2"
#  ---> Running in ffaf89078594
# Removing intermediate container ffaf89078594
#  ---> 91b5cdb6dabe
# Step 4/7 : ARG EXTENSION="tar.gz"
#  ---> Running in d0f5188444b6
# Removing intermediate container d0f5188444b6
#  ---> 9626f941ccb2
# Step 5/7 : ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .
# Downloading [==================================================>]  1.049MB/1.049MB
#  ---> a8e8dcca1be8
# Step 6/7 : RUN apt-get update &&     apt-get install build-essential                     libpcre3                     libpcre3-dev                     zlib1g                     zlib1g-dev                     libssl-dev                     -y &&     tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION} &&     cd ${FILENAME} &&     ./configure         --sbin-path=/usr/bin/nginx         --conf-path=/etc/nginx/nginx.conf         --error-log-path=/var/log/nginx/error.log         --http-log-path=/var/log/nginx/access.log         --with-pcre         --pid-path=/var/run/nginx.pid         --with-http_ssl_module &&     make && make install &&     cd / && rm -rfv /${FILENAME} &&     apt-get remove build-essential                     libpcre3-dev                     zlib1g-dev                     libssl-dev                     -y &&     apt-get autoremove -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> Running in e5675cad1260
### LONG INSTALLATION AND BUILD STUFF GOES HERE ###
# Removing intermediate container e5675cad1260
#  ---> dc7e4161f975
# Step 7/7 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in b579e4600247
# Removing intermediate container b579e4600247
#  ---> 512aa6a95a93
# Successfully built 512aa6a95a93
# Successfully tagged custom-nginx:built

docker image ls

# REPOSITORY         TAG       IMAGE ID       CREATED              SIZE
# custom-nginx       built     512aa6a95a93   About a minute ago   81.6MB
# nginx              stable    b9e1dc12387a   11 days ago          133MB

如你所见，镜像大小从 343MB 变为 81.6MB。官方镜像是 133MB。这是一个非常优化的构建，我们可以在下一部分中进一步介绍。

拥抱 Alpine Linux

如果之前了解过 Docker，可能已经听说了 Alpine Linux。 这是功能齐全的 Linux 发行版，就像 Ubuntu、Debian 或 Fedora。

但是 Alpine 的好处是它是基于 musl，libc 和 busybox 构建的，并且是轻量级的。最新的 ubuntu 镜像大约为 28MB，而 alpine 仅为 2.8MB。

除了轻量之外，Alpine 还很安全，比其他发行版更适合创建容器。

尽管不像其他商业发行版那样用户友好，但是向 Alpine 的过渡仍然非常简单。在本小节中，将学习有关以 Alpine 镜像为基础重新创建 custom-nginx 镜像的信息。

打开的 Dockerfile 并更新其内容，如下所示：

FROM alpine:latest

EXPOSE 80

ARG FILENAME="nginx-1.19.2"
ARG EXTENSION="tar.gz"

ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .

RUN apk add --no-cache pcre zlib && \
    apk add --no-cache \
            --virtual .build-deps \
            build-base \ 
            pcre-dev \
            zlib-dev \
            openssl-dev && \
    tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION} && \
    cd ${FILENAME} && \
    ./configure \
        --sbin-path=/usr/bin/nginx \
        --conf-path=/etc/nginx/nginx.conf \
        --error-log-path=/var/log/nginx/error.log \
        --http-log-path=/var/log/nginx/access.log \
        --with-pcre \
        --pid-path=/var/run/nginx.pid \
        --with-http_ssl_module && \
    make && make install && \
    cd / && rm -rfv /${FILENAME} && \
    apk del .build-deps

CMD ["nginx", "-g", "daemon off;"]

除了几处更改外，代码几乎完全相同。我将列出更改并在进行过程中进行解释：

• 我们不使用 apt-get install 来安装软件包，而是使用 apk add。--no-cache 选项意味着下载的软件包将不会被缓存。同样，我们将使用 apk del 代替 apt-get remove 来卸载软件包。
• apk add 命令的 --virtual 选项用于将一堆软件包捆绑到单个虚拟软件包中，以便于管理。仅用于构建程序所需的软件包被标记为 .build-deps，然后通过执行 apk del .build-deps 命令在第 29 行将其删除。可以在官方文档中了解有关 virtuals 的更多信息。
• 软件包名称在这里有些不同。通常，每个 Linux 发行版都有其软件包仓库，可供在其中搜索软件包的每个人使用。如果你知道某项任务所需的软件包，则可以直接转到指定发行版的仓库的并进行搜索。可以 在此处了解 Alpine Linux软件包。

现在使用此 Dockerfile 构建一个新镜像，并查看文件大小的差异：

docker image build --tag custom-nginx:built .

# Sending build context to Docker daemon  1.055MB
# Step 1/7 : FROM alpine:latest
#  ---> 7731472c3f2a
# Step 2/7 : EXPOSE 80
#  ---> Running in 8336cfaaa48d
# Removing intermediate container 8336cfaaa48d
#  ---> d448a9049d01
# Step 3/7 : ARG FILENAME="nginx-1.19.2"
#  ---> Running in bb8b2eae9d74
# Removing intermediate container bb8b2eae9d74
#  ---> 87ca74f32fbe
# Step 4/7 : ARG EXTENSION="tar.gz"
#  ---> Running in aa09627fe48c
# Removing intermediate container aa09627fe48c
#  ---> 70cb557adb10
# Step 5/7 : ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .
# Downloading [==================================================>]  1.049MB/1.049MB
#  ---> b9790ce0c4d6
# Step 6/7 : RUN apk add --no-cache pcre zlib &&     apk add --no-cache             --virtual .build-deps             build-base             pcre-dev             zlib-dev             openssl-dev &&     tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION} &&     cd ${FILENAME} &&     ./configure         --sbin-path=/usr/bin/nginx         --conf-path=/etc/nginx/nginx.conf         --error-log-path=/var/log/nginx/error.log         --http-log-path=/var/log/nginx/access.log         --with-pcre         --pid-path=/var/run/nginx.pid         --with-http_ssl_module &&     make && make install &&     cd / && rm -rfv /${FILENAME} &&     apk del .build-deps
#  ---> Running in 0b301f64ffc1
### LONG INSTALLATION AND BUILD STUFF GOES HERE ###
# Removing intermediate container 0b301f64ffc1
#  ---> dc7e4161f975
# Step 7/7 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in b579e4600247
# Removing intermediate container b579e4600247
#  ---> 3e186a3c6830
# Successfully built 3e186a3c6830
# Successfully tagged custom-nginx:built

docker image ls

# REPOSITORY         TAG       IMAGE ID       CREATED         SIZE
# custom-nginx       built     3e186a3c6830   8 seconds ago   12.8MB

ubuntu 版本为 81.6MB，而 alpine 版本已降至 12.8MB，这是一个巨大的进步。除了 apk 软件包管理器外，Alpine 和 Ubuntu 还有一些其他的区别，但是没什么大不了的。遇到困难，可以搜索互联网。

怎样创建可执行 Docker 镜像

在上一节中，使用了 fhsinchy/rmbyext 镜像。在本节中，将学习如何制作这样的可执行镜像。

首先，打开本书随附仓库的目录。rmbyext 应用程序的代码位于同名子目录中。

在开始使用 Dockerfile 之前，请花一点时间来规划最终的输出。我认为应该是这样的：

• 该镜像应预安装 Python。
• 它应该包含 rmbyext 脚本的副本。
• 应该在将要执行脚本的地方设置一个工作目录。
• 应该将 rmbyext 脚本设置为入口点，以便镜像可以将扩展名用作参数。

要构建上面提到的镜像，请执行以下步骤：

• 获得可以运行 Python 脚本基础镜像，例如 python。
• 将工作目录设置为易于访问的目录。
• 安装 Git，以便可以从我的 GitHub 仓库中安装脚本。
• 使用 Git 和 pip 安装脚本。
• 删除不必要的构建软件包。
• 将 rmbyext 设置为该图像的入口点。

现在在 rmbyext 目录中创建一个新的 Dockerfile，并将以下代码放入其中：

FROM python:3-alpine

WORKDIR /zone

RUN apk add --no-cache git && \
    pip install git+https://github.com/fhsinchy/rmbyext.git
    apk del git

ENTRYPOINT [ "rmbyext" ]

该文件中的指令说明如下：

• FROM 指令将 python 设置为基本镜像，从而为运行 Python 脚本提供了理想的环境。3-alpine 标记表示需要 Python 3 的 Alpine 版本。
• 这里的 WORKDIR 指令将默认工作目录设置为 /zone。这里的工作目录名称完全是随机的。我发现 zone 是一个合适的名称，你也可以换成任何你想要的名称。
• 假设从 GitHub 安装了 rmbyext 脚本，则 git 是安装时的依赖项。第 5 行的 RUN 指令先安装 git，然后使用 Git 和 pip 安装 rmbyext 脚本。之后也删除了git。
• 最后，在第 9 行，ENTRYPOINT 指令将 rmbyext 脚本设置为该镜像的入口点。

在整个文件中，第 9 行是将这个看似正常的镜像转换为可执行镜像的关键。现在要构建镜像，可以执行以下命令：

docker image build --tag rmbyext .

# Sending build context to Docker daemon  2.048kB
# Step 1/4 : FROM python:3-alpine
# 3-alpine: Pulling from library/python
# 801bfaa63ef2: Already exists 
# 8723b2b92bec: Already exists 
# 4e07029ccd64: Already exists 
# 594990504179: Already exists 
# 140d7fec7322: Already exists 
# Digest: sha256:7492c1f615e3651629bd6c61777e9660caa3819cf3561a47d1d526dfeee02cf6
# Status: Downloaded newer image for python:3-alpine
#  ---> d4d4f50f871a
# Step 2/4 : WORKDIR /zone
#  ---> Running in 454374612a91
# Removing intermediate container 454374612a91
#  ---> 7f7e49bc98d2
# Step 3/4 : RUN apk add --no-cache git &&     pip install git+https://github.com/fhsinchy/rmbyext.git#egg=rmbyext &&     apk del git
#  ---> Running in 27e2e96dc95a
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container 27e2e96dc95a
#  ---> 3c7389432e36
# Step 4/4 : ENTRYPOINT [ "rmbyext" ]
#  ---> Running in f239bbea1ca6
# Removing intermediate container f239bbea1ca6
#  ---> 1746b0cedbc7
# Successfully built 1746b0cedbc7
# Successfully tagged rmbyext:latest

docker image ls

# REPOSITORY         TAG        IMAGE ID       CREATED         SIZE
# rmbyext            latest     1746b0cedbc7   4 minutes ago   50.9MB

这里在镜像名称之后没有提供任何标签，因此默认情况下该镜像已被标记为 latest。 应该能够像在上一节中看到的那样运行该镜像。请记住，参考你设置的实际镜像名称，而不是这里的 fhsinchy/rmbyext。

现在知道如何制作镜像了，是时候与全世界分享它们了。在线共享镜像很容易。所需要做的就是在任何在线仓库中注册一个帐户。在此处我将使用 Docker Hub。

导航到 Sign Up 页面并创建一个免费帐户。一个免费帐户可托管无限的公共仓库和一个私有仓库。

创建帐户后，需要使用 Docker CLI 登录。打开终端并执行以下命令：

docker login

# Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
# Username: fhsinchy
# Password: 
# WARNING! Your password will be stored unencrypted in /home/fhsinchy/.docker/config.json.
# Configure a credential helper to remove this warning. See
# https://docs.docker.com/engine/reference/commandline/login/#credentials-store
#
# Login Succeeded

系统将提示输入用户名和密码。如果输入正确，则应该成功登录到你的帐户。

为了在线共享镜像，必须对镜像进行标记。已经在上一小节中学习了有关标记的信息。只是为了加深记忆，--tag 或 -t 选项的通用语法如下：

--tag <image repository>:<image tag>

例如，让我们在线共享 custom-nginx 图像。 为此，请在 custom-nginx 项目目录中打开一个新的终端窗口。

要在线共享镜像，必须使用 <docker hub username>/<image name>:<image tag> 语法对其进行标记。我的用户名是 fhsinchy，因此命令如下所示：

docker image build --tag fhsinchy/custom-nginx:latest --file Dockerfile.built .

# Step 1/9 : FROM ubuntu:latest
#  ---> d70eaf7277ea
# Step 2/9 : RUN apt-get update &&     apt-get install build-essential                    libpcre3                     libpcre3-dev                     zlib1g                     zlib1g-dev                     libssl-dev                     -y &&     apt-get clean && rm -rf /var/lib/apt/lists/*
#  ---> cbe1ced3da11
### LONG INSTALLATION STUFF GOES HERE ###
# Step 3/9 : ARG FILENAME="nginx-1.19.2"
#  ---> Running in 33b62a0e9ffb
# Removing intermediate container 33b62a0e9ffb
#  ---> fafc0aceb9c8
# Step 4/9 : ARG EXTENSION="tar.gz"
#  ---> Running in 5c32eeb1bb11
# Removing intermediate container 5c32eeb1bb11
#  ---> 36efdf6efacc
# Step 5/9 : ADD https://nginx.org/download/${FILENAME}.${EXTENSION} .
# Downloading [==================================================>]  1.049MB/1.049MB
#  ---> dba252f8d609
# Step 6/9 : RUN tar -xvf ${FILENAME}.${EXTENSION} && rm ${FILENAME}.${EXTENSION}
#  ---> Running in 2f5b091b2125
### LONG EXTRACTION STUFF GOES HERE ###
# Removing intermediate container 2f5b091b2125
#  ---> 2c9a325d74f1
# Step 7/9 : RUN cd ${FILENAME} &&     ./configure         --sbin-path=/usr/bin/nginx         --conf-path=/etc/nginx/nginx.conf         --error-log-path=/var/log/nginx/error.log         --http-log-path=/var/log/nginx/access.log         --with-pcre         --pid-path=/var/run/nginx.pid         --with-http_ssl_module &&     make && make install
#  ---> Running in 11cc82dd5186
### LONG CONFIGURATION AND BUILD STUFF GOES HERE ###
# Removing intermediate container 11cc82dd5186
#  ---> 6c122e485ec8
# Step 8/9 : RUN rm -rf /${FILENAME}}
#  ---> Running in 04102366960b
# Removing intermediate container 04102366960b
#  ---> 6bfa35420a73
# Step 9/9 : CMD ["nginx", "-g", "daemon off;"]
#  ---> Running in 63ee44b571bb
# Removing intermediate container 63ee44b571bb
#  ---> 4ce79556db1b
# Successfully built 4ce79556db1b
# Successfully tagged fhsinchy/custom-nginx:latest

在此命令中，fhsinchy/custom-nginx 是镜像仓库，而 latest 是标签。镜像名称可以是任何名称，上传镜像后即无法更改。可以随时更改标签，该标签通常反映软件的版本或其他类型的内部版本。

以 node 镜像为例。node:lts 镜像是指 Node.js 的长期支持版本，而 node:lts-alpine 版本是指为 Alpine Linux 构建的 Node.js 版本，它比常规版本小得多。

如果你给镜像添加任何标签，则会将其自动标记为 latest。但这并不意味着 latest 标签将始终引用最新版本。如果出于某种原因，将镜像的较旧版本明确标记为 latest，则 Docker 将不会做出任何额外的工作来进行交叉检查。

生成镜像后，可以通过执行以下命令来上传镜像：

docker image push <image repository>:<image tag>

因此，在我这里，命令如下所示：

docker image push fhsinchy/custom-nginx:latest

# The push refers to repository [docker.io/fhsinchy/custom-nginx]
# 4352b1b1d9f5: Pushed 
# a4518dd720bd: Pushed 
# 1d756dc4e694: Pushed 
# d7a7e2b6321a: Pushed 
# f6253634dc78: Mounted from library/ubuntu 
# 9069f84dbbe9: Mounted from library/ubuntu 
# bacd3af13903: Mounted from library/ubuntu 
# latest: digest: sha256:ffe93440256c9edb2ed67bf3bba3c204fec3a46a36ac53358899ce1a9eee497a size: 1788

根据镜像大小，上传可能需要一些时间。完成后，应该可以在中心配置文件页面中找到该镜像。

如何容器化 JavaScript 应用程序

现在，已经了解了创建镜像的知识，是时候做一些更相关的工作了。

在本小节中，将使用在之前小节上使用的 fhsinchy/hello-dock 镜像的源代码。在容器化这个非常简单的应用的过程中，介绍了 volumes 和多阶段构建，这是 Docker 中两个很重要的概念。

如何编写开发 Dockerfile

首先，打开用来克隆本书随附仓库的目录。hello-dock 应用程序的代码位于具有相同名称的子目录中。

这是一个非常简单的 JavaScript 项目，由 vitejs/vite 项目构建。不过，请不要担心，无需了解 JavaScript 或 vite 即可学习本小节。了解 Node.js 和 npm 就足够了。

与上一部分中完成的其他项目一样，将从制定如何运行该应用程序的规划开始。如下：

• 获得可以运行 JavaScript 应用程序的基础镜像，例如 node。
• 在镜像内设置默认的工作目录。
• 将 package.json 文件复制到镜像中。
• 安装必要的依赖项。
• 复制其余的项目文件。
• 通过执行 npm run dev 命令来启动 vite 开发服务。

该规划应始终来由应用程序的开发人员制定。如果你是开发人员，那么应该已经对如何运行此应用程序有正确的了解。

现在，如果将上述计划放入 Dockerfile.dev 中，则该文件应如下所示：

FROM node:lts-alpine

EXPOSE 3000

USER node

RUN mkdir -p /home/node/app

WORKDIR /home/node/app

COPY ./package.json .
RUN npm install

COPY . .

CMD [ "npm", "run", "dev" ]

此代码的说明如下：

• 这里的 FROM 指令将官方的 Node.js 镜像设置为基础镜像，从而可以运行 JavaScript 应用。lts-alpine 标签代表镜像要使用针对 Alpine 的长期支持版本。 可以在 node 页面上找到该镜像的所有标签和其它必要的文档。
• USER 指令将镜像的默认用户设置为 node。 默认情况下，Docker 以 root 用户身份运行容器。 但是根据 Docker and Node.js Best Practices，这有安全隐患。因此，最好是尽可能以非 root 用户身份运行。node 镜像附带一个名为 node 的非 root 用户，可以使用 USER 指令将其设置为默认用户。
• RUN mkdir -p /home/node/app 指令在 node 用户的主目录内创建一个名为 app 的目录。默认情况下，Linux 中任何非 root 用户的主目录通常是 /home/<user name>。
• 然后，WORKDIR 指令将默认工作目录设置为新创建的 /home/node/app 目录。 默认情况下，任何镜像的工作目录都是根目录。如果不希望在根目录中放置不必要的文件，可以将默认工作目录更改为更合理的目录，例如 /home/node/app 或你喜欢的任何目录。该工作目录将适用于任何连续的 COPY、ADD、RUN 和 CMD 指令。
• 此处的 COPY 指令复制了 package.json文件，该文件包含有关此应用程序所有必需依赖项的信息。RUN 指令执行 npm install 命令，这是在 Node.js 项目中使用 package.json 文件安装依赖项的默认命令。 最后的 . 代表工作目录。
• 第二条 COPY 指令将其余内容从主机文件系统的当前目录（.）复制到镜像内的工作目录（.）。
• 最后，这里的 CMD 指令为该镜像设置了默认命令，即以 exec 形式编写的 npm run dev。
• 默认情况下，vite 开发服务器在端口 3000 上运行，最好添加一个 EXPOSE 命令。

现在，要由此 Dockerfile.dev 构建像镜，可以执行以下命令：

docker image build --file Dockerfile.dev --tag hello-dock:dev .

# Step 1/7 : FROM node:lts
#  ---> b90fa0d7cbd1
# Step 2/7 : EXPOSE 3000
#  ---> Running in 722d639badc7
# Removing intermediate container 722d639badc7
#  ---> e2a8aa88790e
# Step 3/7 : WORKDIR /app
#  ---> Running in 998e254b4d22
# Removing intermediate container 998e254b4d22
#  ---> 6bd4c42892a4
# Step 4/7 : COPY ./package.json .
#  ---> 24fc5164a1dc
# Step 5/7 : RUN npm install
#  ---> Running in 23b4de3f930b
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container 23b4de3f930b
#  ---> c17ecb19a210
# Step 6/7 : COPY . .
#  ---> afb6d9a1bc76
# Step 7/7 : CMD [ "npm", "run", "dev" ]
#  ---> Running in a7ff529c28fe
# Removing intermediate container a7ff529c28fe
#  ---> 1792250adb79
# Successfully built 1792250adb79
# Successfully tagged hello-dock:dev

如果文件名不是 Dockerfile，则必须使用 --file 选项显式传递文件名。 通过执行以下命令，可以使用此镜像运行容器：

docker container run \
    --rm \
    --detach \
    --publish 3000:3000 \
    --name hello-dock-dev \
    hello-dock:dev

# 21b9b1499d195d85e81f0e8bce08f43a64b63d589c5f15cbbd0b9c0cb07ae268

现在访问 http://127.0.0.1:3000，可以看到 hello-dock 应用程序。

恭喜你在容器内运行了你的第一个实际应用程序。刚刚编写的代码还可以，但是它存在一个大问题，可以在某些地方进行改进。让我们先从问题开始。

如何在 Docker 中使用 Bind Mounts

如果你以前使用过任何前端 JavaScript 框架，则应该知道这些框架中的开发服务器通常带有热重载功能。也就是说，如果对代码进行更改，服务器将重新加载，并自动反映立即进行的所有更改。

但是，如果现在对代码进行任何更改，将不会在浏览器中运行任何应用程序。这是因为正在更改本地文件系统中的代码，但是在浏览器中看到的应用程序位于容器文件系统中。

要解决此问题，可以再次使用 绑定挂载。 使用绑定挂载，可以轻松地在容器内安装本地文件系统目录。绑定挂载可以直接从容器内部引用本地文件系统，而无需复制本地文件。

这样，对本地源代码所做的任何更改都会及时反映在容器内部，从而触发 vite 开发服务器的热重载功能。对容器内部文件系统所做的更改也将反映在本地文件系统上。

已经在使用可执行镜像小节中学习到，可以对 container run 或 container start 命令使用 --volume 或 -v 选项创建绑定挂载。 回顾一下，通用语法如下：

--volume <local file system directory absolute path>:<container file system directory absolute path>:<read write access>

停止先前启动的 hello-dock-dev 容器，并通过执行以下命令来启动新的容器：

docker container run \
    --rm \
    --publish 3000:3000 \
    --name hello-dock-dev \
    --volume $(pwd):/home/node/app \
    hello-dock:dev

# sh: 1: vite: not found
# npm ERR! code ELIFECYCLE
# npm ERR! syscall spawn
# npm ERR! file sh
# npm ERR! errno ENOENT
# npm ERR! hello-dock@0.0.0 dev: `vite`
# npm ERR! spawn ENOENT
# npm ERR!
# npm ERR! Failed at the hello-dock@0.0.0 dev script.
# npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
# npm WARN Local package.json exists, but node_modules missing, did you mean to install?

请记住，我省略了 --detach 选项，这只是说明一个非常重要的观点。如你所见，该应用程序现在根本没有运行。

这是因为尽管 volume 解决了热重载的问题，但它引入了另一个问题。如果你以前有过使用 Node.js 的经验，你可能会知道 Node.js 项目的依赖项位于项目根目录的 node_modules 目录中。

现在，将项目根目录作为容器中的 volume 安装在本地文件系统上，容器中的内容将被包含所有依赖项的 node_modules 目录替换。 这意味着 vite 软件包不见了。

如何在 Docker 中使用匿名卷

可以使用匿名卷解决此问题。匿名卷除了无需在此处指定源目录之外，与绑定挂载相同。 创建匿名卷的通用语法如下：

--volume <container file system directory absolute path>:<read write access>

因此，用两个卷启动 hello-dock 容器的最终命令应如下：

docker container run \
    --rm \
    --detach \
    --publish 3000:3000 \
    --name hello-dock-dev \
    --volume $(pwd):/home/node/app \
    --volume /home/node/app/node_modules \
    hello-dock:dev

# 53d1cfdb3ef148eb6370e338749836160f75f076d0fbec3c2a9b059a8992de8b

在这里，Docker 将从容器内部获取整个 node_modules 目录，并将其存放在主机文件系统上由 Docker 守护程序管理的其他目录中，并将该目录作为 node_modules 挂载在容器中。

如何在 Docker 中执行多阶段构建

到目前为止，在本节中，已经构建了用于在开发模式下运行 JavaScript 应用程序的镜像。现在，如果要在生产模式下构建镜像，会有一些新的挑战。

在开发模式下，npm run serve 命令启动一个开发服务器，该服务器将应用程序提供给用户。该服务器不仅提供文件，还提供热重载功能。

在生产模式下，npm run build 命令将所有 JavaScript 代码编译为一些静态 HTML、CSS 和 JavaScript 文件。要运行这些文件，不需要 node 或任何其他运行时依赖项。只需要一个像 nginx 这样的服务器。

要在应用程序以生产模式运行时创建镜像，可以执行以下步骤：

• 使用 node 作为基础镜像并构建应用程序。
• 在 node 镜像中安装 nginx 并使用它来提供静态文件。

这种方法是完全有效的。但是问题在于，node 镜像很大，并且它所承载的大多数内容对于静态文件服务而言都是不必要的。解决此问题的更好方法如下：

• 使用node图像作为基础并构建应用程序。
• 将使用 node 镜像创建的文件复制到 nginx 映像。
• 根据 nginx 创建最终镜像，并丢弃所有与 node 相关的东西。

这样，镜像仅包含所需的文件，变得非常方便。

这种方法是一个多阶段构建。要执行这样的构建，在 hello-dock 项目目录中创建一个新的 Dockerfile，并将以下内容放入其中：

FROM node:lts-alpine as builder

WORKDIR /app

COPY ./package.json ./
RUN npm install

COPY . .
RUN npm run build

FROM nginx:stable-alpine

EXPOSE 80

COPY --from=builder /app/dist /usr/share/nginx/html

如你所见，Dockerfile 看起来很像以前的 Dockerfile，但有一些不同之处。该文件的解释如下：

• 第 1 行使用 node:lts-alpine 作为基础镜像开始构建的第一阶段。as builder 语法为此阶段分配一个名称，以便以后可以引用。
• 从第 3 行到第 13 行，以前已经看过很多次了。实际上，RUN npm run build 命令会编译整个应用程序，并将其存放在 /app/dist 目录中，其中 /app 是工作目录，/dist 是 vite 应用程序的默认输出目录。
• 第 15 行使用 nginx:stable-alpine 作为基础镜像开始构建的第二阶段。
• NGINX 服务器默认在端口 80 上运行，因此添加了 EXPOSE 80 行。
• 最后一行是 COPY 指令。--from=builder 部分表示要从 builder 阶段复制一些文件。之后，这是一条标准的复制指令，其中 /app/dist 是 source，而 /usr/share/nginx/html 是 destination。 这里使用的 destination 是 NGINX 的默认站点路径，因此放置在其中的任何静态文件都将自动提供。

如你所见，生成的镜像是基于 nginx 的镜像，仅包含运行应用程序所需的文件。要构建此镜像，请执行以下命令：

docker image build --tag hello-dock:prod .

# Step 1/9 : FROM node:lts-alpine as builder
#  ---> 72aaced1868f
# Step 2/9 : WORKDIR /app
#  ---> Running in e361c5c866dd
# Removing intermediate container e361c5c866dd
#  ---> 241b4b97b34c
# Step 3/9 : COPY ./package.json ./
#  ---> 6c594c5d2300
# Step 4/9 : RUN npm install
#  ---> Running in 6dfabf0ee9f8
# npm WARN deprecated fsevents@2.1.3: Please update to v 2.2.x
#
# > esbuild@0.8.29 postinstall /app/node_modules/esbuild
# > node install.js
#
# npm notice created a lockfile as package-lock.json. You should commit this file.
# npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.2 (node_modules/chokidar/node_modules/fsevents):
# npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
# npm WARN hello-dock@0.0.0 No description
# npm WARN hello-dock@0.0.0 No repository field.
# npm WARN hello-dock@0.0.0 No license field.
#
# added 327 packages from 301 contributors and audited 329 packages in 35.971s
#
# 26 packages are looking for funding
#   run `npm fund` for details
#
# found 0 vulnerabilities
#
# Removing intermediate container 6dfabf0ee9f8
#  ---> 21fd1b065314
# Step 5/9 : COPY . .
#  ---> 43243f95bff7
# Step 6/9 : RUN npm run build
#  ---> Running in 4d918cf18584
#
# > hello-dock@0.0.0 build /app
# > vite build
#
# - Building production bundle...
#
# [write] dist/index.html 0.39kb, brotli: 0.15kb
# [write] dist/_assets/docker-handbook-github.3adb4865.webp 12.32kb
# [write] dist/_assets/index.eabcae90.js 42.56kb, brotli: 15.40kb
# [write] dist/_assets/style.0637ccc5.css 0.16kb, brotli: 0.10kb
# - Building production bundle...
#
# Build completed in 1.71s.
#
# Removing intermediate container 4d918cf18584
#  ---> 187fb3e82d0d
# Step 7/9 : EXPOSE 80
#  ---> Running in b3aab5cf5975
# Removing intermediate container b3aab5cf5975
#  ---> d6fcc058cfda
# Step 8/9 : FROM nginx:stable-alpine
# stable: Pulling from library/nginx
# 6ec7b7d162b2: Already exists 
# 43876acb2da3: Pull complete 
# 7a79edd1e27b: Pull complete 
# eea03077c87e: Pull complete 
# eba7631b45c5: Pull complete 
# Digest: sha256:2eea9f5d6fff078ad6cc6c961ab11b8314efd91fb8480b5d054c7057a619e0c3
# Status: Downloaded newer image for nginx:stable
#  ---> 05f64a802c26
# Step 9/9 : COPY --from=builder /app/dist /usr/share/nginx/html
#  ---> 8c6dfc34a10d
# Successfully built 8c6dfc34a10d
# Successfully tagged hello-dock:prod

生成镜像后，可以通过执行以下命令来运行新容器：

docker container run \
    --rm \
    --detach \
    --name hello-dock-prod \
    --publish 8080:80 \
    hello-dock:prod

# 224aaba432bb09aca518fdd0365875895c2f5121eb668b2e7b2d5a99c019b953

正在运行的应用程序应位于 http://127.0.0.1:8080 上：

在这里，可以看到我所有的 hello-dock 应用程序。 如果要构建具有大量依赖关系的大型应用程序，那么多阶段构建可能会非常有用。如果配置正确，则可以很好地优化和压缩分多个阶段构建的镜像。

如何忽略不必要的文件

如果了解 git，你可能会知道项目中的 .gitignore 文件。 这些文件包含要从仓库中排除的文件和目录的列表。

嗯，Docker 也有类似的概念。.dockerignore 文件包含要从镜像构建中排除的文件和目录的列表。可以在 hello-dock 目录中有一个预先创建的 .dockerignore 文件。

.git
*Dockerfile*
*docker-compose*
node_modules

该 .dockerignore 文件必须位于构建上下文中。这里提到的文件和目录将被 COPY 指令忽略。但是，如果执行绑定挂载，则 .dockerignore 文件将对此无效。我已经在项目仓库中的必要位置添加了 .dockerignore 文件。

Docker 中的网络操作基础知识

到目前为止，在本书中，仅处理了单个容器项目。但是在实际应用中，多数项目都具有多个容器。老实说，如果不了解容器隔离的细微差别，使用一堆容器可能会有些困难。

因此，在本书的这一部分中，将介绍 Docker 的基本网络，并涉及一个小型的多容器项目。

好了，已经在上一节中了解到容器是隔离的环境。现在考虑一个场景，其中有一个基于 Express.js notes-api 应用程序和一个 PostgreSQL 数据库服务，他们在两个单独的容器中运行。

这两个容器彼此完全隔离，并且彼此无关。那么如何连接两者？ 将是一个挑战。

你可能会想到针对此问题的两种可能的解决方案。 它们如下：

• 使用暴露的端口访问数据库服务。
• 使用其 IP 地址和默认端口访问数据库服务。

第一个涉及从 postgres 容器暴露一个端口，notes-api 将通过该端口进行连接。假设来自 postgres 容器的暴露端口为 5432。现在，如果尝试从 notes-api 容器内部连接到 127.0.0.1:5432，会发现 notes-api 根本找不到数据库服务。

原因是，在 notes-api 容器内的 127.0.0.1 时，只是代表当前容器的 localhost 。postgres 服务根本不存在。结果是，notes-api 应用程序无法连接。

你可能想到的第二个解决方案找到 postgres 容器的确切 IP 地址，使用 container inspect 命令并将其与端口一起使用。 假设 postgres 容器的名称为 notes-api-db-server ，则可以通过执行以下命令轻松获得 IP 地址：

docker container inspect --format='{{range .NetworkSettings.Networks}} {{.IPAddress}} {{end}}' notes-api-db-server

#  172.17.0.2

现在假设 postgres 的默认端口是 5432，可以通过从 notes-api 容器连接到 172.17.0.2:5432 来非常容易地访问数据库服务。

这种方法也存在问题。 不建议使用 IP 地址来引用容器。另外，如果容器被破坏并重新创建，则 IP 地址可能会更改。跟踪这些不断变化的 IP 地址可能非常麻烦。

现在，我已经排除了对原始问题的可能错误答案，正确的答案是，将它们放置在用户定义的桥接网络下即可将它们连接起来。

Docker 网络基础

Docker 中的网络是另一个逻辑对象，和容器和镜像一样。就像其他两个一样，在 docker network 组下有很多用于操纵网络的命令。

要列出系统中的网络，请执行以下命令：

docker network ls

# NETWORK ID     NAME      DRIVER    SCOPE
# c2e59f2b96bd   bridge    bridge    local
# 124dccee067f   host      host      local
# 506e3822bf1f   none      null      local

你应该在系统中看到三个网络。现在在这里查看表的 DRIVER 列。这些 drivers 可以视为网络类型。

默认情况下，Docker 具有五类网络驱动。它们如下：

• bridge - Docker 中的默认网络驱动程序。当多个容器以标准模式运行并且需要相互通信时，可以使用此方法。
• host - 完全消除网络隔离。在 host 网络下运行的任何容器基本上都连接到主机系统的网络。
• none - 此驱动程序完全禁用容器的联网。 我还没有找到其应用场景。
• overlay - 这用于跨计算机连接多个 Docker 守护程序，这超出了本书的范围。
• macvlan - 允许将 MAC 地址分配给容器，使它们的功能类似于网络中的物理设备。

也有第三方插件，可让你将 Docker 与专用网络堆栈集成。在上述五种方法中，本书仅使用 bridge 网络驱动程序。

如何在 Docker 中创建用户定义的桥接网络

在开始创建自己的桥接网络之前，我想花一些时间来讨论 Docker 随附的默认桥接网络。让我们首先列出系统上的所有网络：

docker network ls

# NETWORK ID     NAME      DRIVER    SCOPE
# c2e59f2b96bd   bridge    bridge    local
# 124dccee067f   host      host      local
# 506e3822bf1f   none      null      local

如你所见，Docker 随附了一个名为 bridge 的默认桥接网络。 运行的任何容器都将自动连接到此网桥网络：

docker container run --rm --detach --name hello-dock --publish 8080:80 fhsinchy/hello-dock
# a37f723dad3ae793ce40f97eb6bb236761baa92d72a2c27c24fc7fda0756657d

docker network inspect --format='{{range .Containers}}{{.Name}}{{end}}' bridge
# hello-dock

连接到默认桥接网络的容器可以使用我在上一小节中不鼓励使用的 IP 地址相互通信。

但是，用户定义的桥接网络比默认桥接网络多一些额外的功能。根据有关此主题的官方 docs，一些值得注意的额外功能如下：

• 用户定义的网桥可在容器之间提供自动 DNS 解析： 这意味着连接到同一网络的容器可以使用容器名称相互通信。 因此，如果你有两个名为 notes-api 和 notes-db 的容器，则 API 容器将能够使用 notes-db 名称连接到数据库容器。
• 用户定义的网桥提供更好的隔离性： 默认情况下，所有容器都连接到默认桥接网络，这可能会导致它们之间的冲突。将容器连接到用户定义的桥可以确保更好的隔离。
• 容器可以即时与用户定义的网络连接和分离： 在容器的生命周期内，可以即时将其与用户定义的网络连接或断开连接。要从默认网桥网络中删除容器，需要停止容器并使用其他网络选项重新创建它。

既然已经了解了很多有关用户定义的网络的知识，那么现在该为自己创建一个了。可以使用 network create 命令创建网络。该命令的通用语法如下：

docker network create <network name>

要创建名称为 skynet 的网络，请执行以下命令：

docker network create skynet

# 7bd5f351aa892ac6ec15fed8619fc3bbb95a7dcdd58980c28304627c8f7eb070

docker network ls

# NETWORK ID     NAME     DRIVER    SCOPE
# be0cab667c4b   bridge   bridge    local
# 124dccee067f   host     host      local
# 506e3822bf1f   none     null      local
# 7bd5f351aa89   skynet   bridge    local

如你所见，已经使用给定名称创建了一个新网络。当前没有容器连接到该网络。在下一小节中，将学习有关将容器连接到网络的信息。

如何在 Docker 中将容器连接到网络

将容器连接到网络的方式主要有两种。首先，可以使用 network connect 命令将容器连接到网络。该命令的通用语法如下：

docker network connect <network identifier> <container identifier>

要将 hello-dock 容器连接到 skynet 网络，可以执行以下命令：

docker network connect skynet hello-dock

docker network inspect --format='{{range .Containers}} {{.Name}} {{end}}' skynet

#  hello-dock

docker network inspect --format='{{range .Containers}} {{.Name}} {{end}}' bridge

#  hello-dock

从两个 network inspect 命令的输出中可以看到，hello-dock 容器现在已连接到 skynet 和默认的 bridge 网络。

将容器连接到网络的第二种方法是对 container run 或 container create 命令使用 --network 选项。 该选项的通用语法如下：

--network <network identifier>

要运行连接到同一网络的另一个 hello-dock 容器，可以执行以下命令：

docker container run --network skynet --rm --name alpine-box -it alpine sh

# lands you into alpine linux shell

/ # ping hello-dock

# PING hello-dock (172.18.0.2): 56 data bytes
# 64 bytes from 172.18.0.2: seq=0 ttl=64 time=0.191 ms
# 64 bytes from 172.18.0.2: seq=1 ttl=64 time=0.103 ms
# 64 bytes from 172.18.0.2: seq=2 ttl=64 time=0.139 ms
# 64 bytes from 172.18.0.2: seq=3 ttl=64 time=0.142 ms
# 64 bytes from 172.18.0.2: seq=4 ttl=64 time=0.146 ms
# 64 bytes from 172.18.0.2: seq=5 ttl=64 time=0.095 ms
# 64 bytes from 172.18.0.2: seq=6 ttl=64 time=0.181 ms
# 64 bytes from 172.18.0.2: seq=7 ttl=64 time=0.138 ms
# 64 bytes from 172.18.0.2: seq=8 ttl=64 time=0.158 ms
# 64 bytes from 172.18.0.2: seq=9 ttl=64 time=0.137 ms
# 64 bytes from 172.18.0.2: seq=10 ttl=64 time=0.145 ms
# 64 bytes from 172.18.0.2: seq=11 ttl=64 time=0.138 ms
# 64 bytes from 172.18.0.2: seq=12 ttl=64 time=0.085 ms

--- hello-dock ping statistics ---
13 packets transmitted, 13 packets received, 0% packet loss
round-trip min/avg/max = 0.085/0.138/0.191 ms

如你所见，从 alpine-box 容器内部运行 ping hello-dock 是可行的，因为这两个容器都在同一用户定义的网桥网络下，并且自动 DNS 解析有效。

但是请记住，为了使自动 DNS 解析正常工作，必须为容器分配自定义名称。使用随机生成的名称将不起作用。

如何在 Docker 中从网络分离容器

在上一小节中，了解了有关将容器连接到网络的信息。在本小节中，将学习如何分离它们。

可以使用 network disconnect 命令来执行此任务。该命令的通用语法如下：

docker network disconnect <network identifier> <container identifier>

要从 skynet 网络分离 hello-dock 容器，可以执行以下命令：

docker network disconnect skynet hello-dock

就像 network connect 命令一样，network disconnect 命令也不给出任何输出。

如何删除 Docker 中的网络

就像 Docker 中的其他逻辑对象一样，可以使用 network rm 命令删除网络。该命令的通用语法如下：

docker network rm <network identifier>

要从系统中删除 skynet 网络，可以执行以下命令：

docker network rm skynet

也可以使用 network prune 命令从系统中删除所有未使用的网络。该命令还具有 -f 或 --force 和 -a 或 --all 选项。

如何容器化多容器 JavaScript 应用程序

既然已经对 Docker 中的网络有了足够的了解，那么在本节中，将学习如何将成熟的多容器项目容器化。涉及的项目是一个基于 Express.js 和 PostgreSQL 的简单 notes-api。

在此项目中，需要使用网络连接两个容器。除此之外，还将学习诸如环境变量和命名卷之类的概念。因此，事不宜迟，让我们直接开始。

如何运行数据库服务

该项目中的数据库服务器是一个简单的 PostgreSQL 服务，使用官方的 postgres 镜像。

根据官方文档，为了使用此镜像运行容器，必须提供 POSTGRES_PASSWORD 环境变量。除此之外，还将使用 POSTGRES_DB 环境变量为默认数据库提供一个名称。默认情况下，PostgreSQL 监听 5432 端口，因此也需要公开它。

要运行数据库服务，可以执行以下命令：

docker container run \
    --detach \
    --name=notes-db \
    --env POSTGRES_DB=notesdb \
    --env POSTGRES_PASSWORD=secret \
    --network=notes-api-network \
    postgres:12

# a7b287d34d96c8e81a63949c57b83d7c1d71b5660c87f5172f074bd1606196dc

docker container ls

# CONTAINER ID   IMAGE         COMMAND                  CREATED              STATUS              PORTS      NAMES
# a7b287d34d96   postgres:12   "docker-entrypoint.s…"   About a minute ago   Up About a minute   5432/tcp   notes-db

container run 和 container create 命令的 --env 选项可用于向容器提供环境变量。如你所见，数据库容器已成功创建并且正在运行。

尽管容器正在运行，但是存在一个小问题。 PostgreSQL、MongoDB 和 MySQL 等数据库将其数据保留在目录中。 PostgreSQL使用容器内的 /var/lib/postgresql/data 目录来持久化数据。

现在，如果容器由于某种原因被破坏怎么办？ 将丢失所有数据。为了解决此问题，可以使用命名卷。

如何在 Docker 中使用命名卷

之前，已经使用了绑定挂载和匿名卷。命名卷与匿名卷非常相似，不同之处在于可以使用其名称引用命名卷。

卷也是 Docker 中的逻辑对象，可以使用命令行进行操作。volume create 命令可用于创建命名卷。

该命令的通用语法如下：

docker volume create <volume name>

要创建一个名为 notes-db-data 的卷，可以执行以下命令：

docker volume create notes-db-data

# notes-db-data

docker volume ls

# DRIVER    VOLUME NAME
# local     notes-db-data

这个卷现在可以被安装到 notes-db 容器中的 /var/lib/postgresql/data 中。为此，请停止并删除 notes-db 容器：

docker container stop notes-db

# notes-db

docker container rm notes-db

# notes-db

现在运行一个新容器，并使用 --volume 或 -v 选项分配卷。

docker container run \
    --detach \
    --volume notes-db-data:/var/lib/postgresql/data \
    --name=notes-db \
    --env POSTGRES_DB=notesdb \
    --env POSTGRES_PASSWORD=secret \
    --network=notes-api-network \
    postgres:12

# 37755e86d62794ed3e67c19d0cd1eba431e26ab56099b92a3456908c1d346791

现在检查 notes-db 容器以确保安装成功：

docker container inspect --format='{{range .Mounts}} {{ .Name }} {{end}}' notes-db

#  notes-db-data

现在，这些数据将安全地存储在 notes-db-data 卷中，并且将来可以重复使用。在这里也可以使用绑定挂载代替命名卷，但是在这种情况下，我更喜欢使用命名卷。

如何从 Docker 中的容器访问日志

为了查看来自容器的日志，可以使用 container logs 命令。 该命令的通用语法如下：

docker container logs <container identifier>

要从 notes-db 容器访问日志，可以执行以下命令：

docker container logs notes-db

# The files belonging to this database system will be owned by user "postgres".
# This user must also own the server process.

# The database cluster will be initialized with locale "en_US.utf8".
# The default database encoding has accordingly been set to "UTF8".
# The default text search configuration will be set to "english".
#
# Data page checksums are disabled.
#
# fixing permissions on existing directory /var/lib/postgresql/data ... ok
# creating subdirectories ... ok
# selecting dynamic shared memory implementation ... posix
# selecting default max_connections ... 100
# selecting default shared_buffers ... 128MB
# selecting default time zone ... Etc/UTC
# creating configuration files ... ok
# running bootstrap script ... ok
# performing post-bootstrap initialization ... ok
# syncing data to disk ... ok
#
#
# Success. You can now start the database server using:
#
#     pg_ctl -D /var/lib/postgresql/data -l logfile start
#
# initdb: warning: enabling "trust" authentication for local connections
# You can change this by editing pg_hba.conf or using the option -A, or
# --auth-local and --auth-host, the next time you run initdb.
# waiting for server to start....2021-01-25 13:39:21.613 UTC [47] LOG:  starting PostgreSQL 12.5 (Debian 12.5-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
# 2021-01-25 13:39:21.621 UTC [47] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
# 2021-01-25 13:39:21.675 UTC [48] LOG:  database system was shut down at 2021-01-25 13:39:21 UTC
# 2021-01-25 13:39:21.685 UTC [47] LOG:  database system is ready to accept connections
#  done
# server started
# CREATE DATABASE
#
#
# /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
#
# 2021-01-25 13:39:22.008 UTC [47] LOG:  received fast shutdown request
# waiting for server to shut down....2021-01-25 13:39:22.015 UTC [47] LOG:  aborting any active transactions
# 2021-01-25 13:39:22.017 UTC [47] LOG:  background worker "logical replication launcher" (PID 54) exited with exit code 1
# 2021-01-25 13:39:22.017 UTC [49] LOG:  shutting down
# 2021-01-25 13:39:22.056 UTC [47] LOG:  database system is shut down
#  done
# server stopped
#
# PostgreSQL init process complete; ready for start up.
#
# 2021-01-25 13:39:22.135 UTC [1] LOG:  starting PostgreSQL 12.5 (Debian 12.5-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
# 2021-01-25 13:39:22.136 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
# 2021-01-25 13:39:22.136 UTC [1] LOG:  listening on IPv6 address "::", port 5432
# 2021-01-25 13:39:22.147 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
# 2021-01-25 13:39:22.177 UTC [75] LOG:  database system was shut down at 2021-01-25 13:39:22 UTC
# 2021-01-25 13:39:22.190 UTC [1] LOG:  database system is ready to accept connections

从第 57 行的文本可以看出，数据库已启动，并准备接受来自外部的连接。该命令还有 --follow 或 -f 选项，使可以将控制台连接到日志输出并获得连续的文本流。

如何在 Docker 中创建网络并连接数据库服务

如在上一节中所学，容器必须连接到用户定义的桥接网络，才能使用容器名称相互通信。为此，请在系统中创建一个名为 notes-api-network 的网络：

docker network create notes-api-network

现在，通过执行以下命令，将 notes-db 容器连接到该网络：

docker network connect notes-api-network notes-db

如何编写 Dockerfile

转到克隆项目代码的目录。在其中，进入 notes-api/api 目录，并创建一个新的 Dockerfile。 将以下代码放入文件中：

# stage one
FROM node:lts-alpine as builder

# install dependencies for node-gyp
RUN apk add --no-cache python make g++

WORKDIR /app

COPY ./package.json .
RUN npm install --only=prod

# stage two
FROM node:lts-alpine

EXPOSE 3000
ENV NODE_ENV=production

USER node
RUN mkdir -p /home/node/app
WORKDIR /home/node/app

COPY . .
COPY --from=builder /app/node_modules  /home/node/app/node_modules

CMD [ "node", "bin/www" ]

这是一个多阶段构建。第一阶段用于使用 node-gyp 构建和安装依赖项，第二阶段用于运行应用程序。我将简要介绍以下步骤：

• 阶段1使用 node：lts-alpine 作为基础，并使用 builder 作为阶段名称。
• 在第 5 行，安装了 python、make 和 g++。node-gyp 工具需要这三个软件包才能运行。
• 在第 7 行，我们将 /app 目录设置为 WORKDIR。
• 在第 9 和 10 行，将 package.json 文件复制到 WORKDIR 并安装所有依赖项。
• 第 2 阶段还使用 node-lts：alpine 作为基础镜像。
• 在第 16 行，将环境变量 NODE_ENV 设置为 production。 这对于 API 正常运行很重要。
• 从第 18 行到第 20 行，将默认用户设置为 node，创建 /home/node/app 目录，并将其设置为 WORKDIR。
• 在第 22 行，复制了所有项目文件，在第 23 行，从 builder 阶段复制了 node_modules 目录。此目录包含运行应用程序所需的所有已构建依赖关系。
• 在第 25 行，设置了默认命令。

要从此 Dockerfile 构建镜像，可以执行以下命令：

docker image build --tag notes-api .

# Sending build context to Docker daemon  37.38kB
# Step 1/14 : FROM node:lts-alpine as builder
#  ---> 471e8b4eb0b2
# Step 2/14 : RUN apk add --no-cache python make g++
#  ---> Running in 5f20a0ecc04b
# fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/main/x86_64/APKINDEX.tar.gz
# fetch http://dl-cdn.alpinelinux.org/alpine/v3.11/community/x86_64/APKINDEX.tar.gz
# (1/21) Installing binutils (2.33.1-r0)
# (2/21) Installing gmp (6.1.2-r1)
# (3/21) Installing isl (0.18-r0)
# (4/21) Installing libgomp (9.3.0-r0)
# (5/21) Installing libatomic (9.3.0-r0)
# (6/21) Installing mpfr4 (4.0.2-r1)
# (7/21) Installing mpc1 (1.1.0-r1)
# (8/21) Installing gcc (9.3.0-r0)
# (9/21) Installing musl-dev (1.1.24-r3)
# (10/21) Installing libc-dev (0.7.2-r0)
# (11/21) Installing g++ (9.3.0-r0)
# (12/21) Installing make (4.2.1-r2)
# (13/21) Installing libbz2 (1.0.8-r1)
# (14/21) Installing expat (2.2.9-r1)
# (15/21) Installing libffi (3.2.1-r6)
# (16/21) Installing gdbm (1.13-r1)
# (17/21) Installing ncurses-terminfo-base (6.1_p20200118-r4)
# (18/21) Installing ncurses-libs (6.1_p20200118-r4)
# (19/21) Installing readline (8.0.1-r0)
# (20/21) Installing sqlite-libs (3.30.1-r2)
# (21/21) Installing python2 (2.7.18-r0)
# Executing busybox-1.31.1-r9.trigger
# OK: 212 MiB in 37 packages
# Removing intermediate container 5f20a0ecc04b
#  ---> 637ca797d709
# Step 3/14 : WORKDIR /app
#  ---> Running in 846361b57599
# Removing intermediate container 846361b57599
#  ---> 3d58a482896e
# Step 4/14 : COPY ./package.json .
#  ---> 11b387794039
# Step 5/14 : RUN npm install --only=prod
#  ---> Running in 2e27e33f935d
#  added 269 packages from 220 contributors and audited 1137 packages in 140.322s
#
# 4 packages are looking for funding
#   run `npm fund` for details
#
# found 0 vulnerabilities
#
# Removing intermediate container 2e27e33f935d
#  ---> eb7cb2cb0b20
# Step 6/14 : FROM node:lts-alpine
#  ---> 471e8b4eb0b2
# Step 7/14 : EXPOSE 3000
#  ---> Running in 4ea24f871747
# Removing intermediate container 4ea24f871747
#  ---> 1f0206f2f050
# Step 8/14 : ENV NODE_ENV=production
#  ---> Running in 5d40d6ac3b7e
# Removing intermediate container 5d40d6ac3b7e
#  ---> 31f62da17929
# Step 9/14 : USER node
#  ---> Running in 0963e1fb19a0
# Removing intermediate container 0963e1fb19a0
#  ---> 0f4045152b1c
# Step 10/14 : RUN mkdir -p /home/node/app
#  ---> Running in 0ac591b3adbd
# Removing intermediate container 0ac591b3adbd
#  ---> 5908373dfc75
# Step 11/14 : WORKDIR /home/node/app
#  ---> Running in 55253b62ff57
# Removing intermediate container 55253b62ff57
#  ---> 2883cdb7c77a
# Step 12/14 : COPY . .
#  ---> 8e60893a7142
# Step 13/14 : COPY --from=builder /app/node_modules  /home/node/app/node_modules
#  ---> 27a85faa4342
# Step 14/14 : CMD [ "node", "bin/www" ]
#  ---> Running in 349c8ca6dd3e
# Removing intermediate container 349c8ca6dd3e
#  ---> 9ea100571585
# Successfully built 9ea100571585
# Successfully tagged notes-api:latest

在使用该镜像运行容器之前，请确保数据库容器正在运行，并且已附加到 notes-api-network 上。

docker container inspect notes-db

# [
#     {
#         ...
#         "State": {
#             "Status": "running",
#             "Running": true,
#             "Paused": false,
#             "Restarting": false,
#             "OOMKilled": false,
#             "Dead": false,
#             "Pid": 11521,
#             "ExitCode": 0,
#             "Error": "",
#             "StartedAt": "2021-01-26T06:55:44.928510218Z",
#             "FinishedAt": "2021-01-25T14:19:31.316854657Z"
#         },
#         ...
#         "Mounts": [
#             {
#                 "Type": "volume",
#                 "Name": "notes-db-data",
#                 "Source": "/var/lib/docker/volumes/notes-db-data/_data",
#                 "Destination": "/var/lib/postgresql/data",
#                 "Driver": "local",
#                 "Mode": "z",
#                 "RW": true,
#                 "Propagation": ""
#             }
#         ],
#         ...
#         "NetworkSettings": {
#             ...
#             "Networks": {
#                 "bridge": {
#                     "IPAMConfig": null,
#                     "Links": null,
#                     "Aliases": null,
#                     "NetworkID": "e4c7ce50a5a2a49672155ff498597db336ecc2e3bbb6ee8baeebcf9fcfa0e1ab",
#                     "EndpointID": "2a2587f8285fa020878dd38bdc630cdfca0d769f76fc143d1b554237ce907371",
#                     "Gateway": "172.17.0.1",
#                     "IPAddress": "172.17.0.2",
#                     "IPPrefixLen": 16,
#                     "IPv6Gateway": "",
#                     "GlobalIPv6Address": "",
#                     "GlobalIPv6PrefixLen": 0,
#                     "MacAddress": "02:42:ac:11:00:02",
#                     "DriverOpts": null
#                 },
#                 "notes-api-network": {
#                     "IPAMConfig": {},
#                     "Links": null,
#                     "Aliases": [
#                         "37755e86d627"
#                     ],
#                     "NetworkID": "06579ad9f93d59fc3866ac628ed258dfac2ed7bc1a9cd6fe6e67220b15d203ea",
#                     "EndpointID": "5b8f8718ec9a5ec53e7a13cce3cb540fdf3556fb34242362a8da4cc08d37223c",
#                     "Gateway": "172.18.0.1",
#                     "IPAddress": "172.18.0.2",
#                     "IPPrefixLen": 16,
#                     "IPv6Gateway": "",
#                     "GlobalIPv6Address": "",
#                     "GlobalIPv6PrefixLen": 0,
#                     "MacAddress": "02:42:ac:12:00:02",
#                     "DriverOpts": {}
#                 }
#             }
#         }
#     }
# ]

已经缩短了输出，以便于在此处查看。在我的系统上，notes-db 容器正在运行，使用 notes-db-data 卷，并连接到 notes-api-network 桥接网络。

一旦确定一切就绪，就可以通过执行以下命令来运行新容器：

docker container run \
    --detach \
    --name=notes-api \
    --env DB_HOST=notes-db \
    --env DB_DATABASE=notesdb \
    --env DB_PASSWORD=secret \
    --publish=3000:3000 \
    --network=notes-api-network \
    notes-api
    
# f9ece420872de99a060b954e3c236cbb1e23d468feffa7fed1e06985d99fb919

应该理解这个长命令，因此只简要介绍下环境变量。

notes-api 应用程序需要设置三个环境变量。 它们如下：

• DB_HOST - 这是数据库服务的主机。假定数据库服务和 API 都连接到同一用户定义的桥接网络，则可以使用其容器名称（在这种情况下为 notes-db）引用数据库服务。
• DB_DATABASE - 此API将使用的数据库。 在运行数据库服务小节，使用环境变量 POSTGRES_DB 将默认数据库名称设置为 notesdb。 将在这里使用它。
• DB_PASSWORD - 连接数据库的密码。 这也在运行数据库服务小节涉及，使用环境变量POSTGRES_PASSWORD。

要检查容器是否正常运行，可以使用 container ls 命令：

docker container ls

# CONTAINER ID   IMAGE         COMMAND                  CREATED          STATUS          PORTS                    NAMES
# f9ece420872d   notes-api     "docker-entrypoint.s…"   12 minutes ago   Up 12 minutes   0.0.0.0:3000->3000/tcp   notes-api
# 37755e86d627   postgres:12   "docker-entrypoint.s…"   17 hours ago     Up 14 minutes   5432/tcp                 notes-db

容器正在运行。 可以访问 http://127.0.0.1:3000/ 来查看正在使用的API。

该 API 总共有五个路由，可以在 /notes/api/api/api/routes/notes.js 文件中看到。 它是用我的一个开源项目引导的。

尽管容器正在运行，但是在开始使用它之前，还有最后一件事要做。必须运行设置数据库表所必需的数据库迁移，并且可以通过在容器内执行 npm run db:migrate 命令来执行此操作。

如何在正在运行的容器中执行命令

已经了解了在停止的容器中执行命令的知识。另一种情况是在正在运行的容器内执行命令。

为此，必须使用 exec 命令在正在运行的容器内执行自定义命令。

exec 命令的通用语法如下：

docker container exec <container identifier> <command>

要执行 notes-api 容器内的 npm run db:migrate，可以执行以下命令：

docker container exec notes-api npm run db:migrate

# > notes-api@ db:migrate /home/node/app
# > knex migrate:latest
#
# Using environment: production
# Batch 1 run: 1 migrations

如果要在正在运行的容器中运行交互式命令，则必须使用 -it 标志。例如，如果要访问在 notes-api 容器中运行的 shell，可以执行以下命令：

docker container exec -it notes-api sh

# / # uname -a
# Linux b5b1367d6b31 5.10.9-201.fc33.x86_64 #1 SMP Wed Jan 20 16:56:23 UTC 2021 x86_64 Linux

如何在 Docker 中编写管理脚本

管理多容器项目以及网络，卷和内容意味着编写大量命令。为了简化过程，我通常会从简单的 shell脚本和 Makefile 来提高效率。

可以在 notes-api 目录中找到四个 shell 脚本。 它们如下：

• boot.sh - 用于启动容器（如果已存在）。
• build.sh - 创建并运行容器。如果需要，它还会创建镜像，卷和网络。
• destroy.sh - 删除与此项目关联的所有容器，卷和网络。
• stop.sh - 停止所有正在运行的容器。

还有一个 Makefile，其中包含名为start、stop、build和 destroy 的四个目标，每个目标都调用前面提到的 shell 脚本。

如果容器在系统中处于运行状态，执行 make stop 将停止所有容器。 执行 make destroy 应该停止容器并删除所有东西。 确保正在 notes-api 目录中运行脚本：

make destroy

# ./shutdown.sh
# stopping api container --->
# notes-api
# api container stopped --->

# stopping db container --->
# notes-db
# db container stopped --->

# shutdown script finished

# ./destroy.sh
# removing api container --->
# notes-api
# api container removed --->

# removing db container --->
# notes-db
# db container removed --->

# removing db data volume --->
# notes-db-data
# db data volume removed --->

# removing network --->
# notes-api-network
# network removed --->

# destroy script finished

如果遇到权限拒绝错误，请在脚本上执行 chmod + x：

chmod +x boot.sh build.sh destroy.sh shutdown.sh

这里不解释这些脚本，因为它们是简单的 if-else 语句以及一些已经看过很多次的 Docker 命令。如果对 Linux Shell 有所了解，那么也应该能够理解这些脚本。

如何使用 Docker-Compose 组合项目

在上一节中，了解了有关管理多容器项目的困难。除了编写许多命令之外，还有一种更简单的方法来管理多容器项目，该工具叫作Docker Compose。

根据 Docker 的文档 -

Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过 Compose，可以使用 YAML 文件来配置应用程序的服务。然后，使用一个命令，就可以从配置中创建并启动所有服务。

尽管 Compose 可在所有环境中使用，但它更专注于开发和测试。完全不建议在生产环境上使用 Compose。

Docker Compose 基础

转至用来克隆本书随附仓库的目录。进入 notes-api/api 目录并创建 Dockerfile.dev 文件。将以下代码放入其中：

FROM node:lts-alpine as builder


RUN apk add --no-cache python make g++

WORKDIR /app

COPY ./package.json .
RUN npm install


FROM node:lts-alpine

ENV NODE_ENV=development

USER node
RUN mkdir -p /home/node/app
WORKDIR /home/node/app

COPY . .
COPY --from=builder /app/node_modules /home/node/app/node_modules

CMD [ "./node_modules/.bin/nodemon", "--config", "nodemon.json", "bin/www" ]

该代码与上一小节中使用的 Dockerfile 几乎相同。 此文件中的三个区别如下：

• 在第 10 行中，执行 npm install 而不是 npm run install --only = prod，因为还需要开发依赖项。
• 在第 15 行，将环境变量 NODE_ENV 设置为 development 而不是 production。
• 在第 24 行，使用名为 nodemon 的工具来获取 API 的热重载功能。

已经知道该项目有两个容器：

• notes-db - 一个基于 PostgreSQL 的数据库服务
• notes-api - 一个基于 Express.js 的 REST API

在 Compose 的世界中，组成应用程序的每个容器都叫作服务。组合多容器项目的第一步就是定义这些服务。

就像 Docker 守护进程使用 Dockerfile 构建映像一样，Docker Compose 使用 docker-compose.yaml 文件从中读取服务定义。

转到 notes-api 目录并创建一个新的 docker-compose.yaml 文件。 将以下代码放入新创建的文件中：

version: "3.8"

services: 
    db:
        image: postgres:12
        container_name: notes-db-dev
        volumes: 
            - notes-db-dev-data:/var/lib/postgresql/data
        environment:
            POSTGRES_DB: notesdb
            POSTGRES_PASSWORD: secret
    api:
        build:
            context: ./api
            dockerfile: Dockerfile.dev
        image: notes-api:dev
        container_name: notes-api-dev
        environment: 
            DB_HOST: db 
            DB_DATABASE: notesdb
            DB_PASSWORD: secret
        volumes: 
            - /home/node/app/node_modules
            - ./api:/home/node/app
        ports: 
            - 3000:3000

volumes:
    notes-db-dev-data:
        name: notes-db-dev-data

每个有效的 docker-compose.yaml 文件均通过定义文件版本开始。在撰写本文时，3.8 是最新版本。可以在此处查找最新版本。

YAML 文件中的块由缩进定义。将仔细介绍每个块，并解释它们的作用。

• services 块包含应用程序中每个服务或容器的定义。db 和 api 是构成该项目的两个服务。
• db 块在应用程序中定义了一个新服务，并保存了启动容器所需的信息。每个服务都需要一个预先构建的镜像或一个 Dockerfile 来运行容器。 对于 db 服务，我们使用的是官方 PostgreSQL 镜像。
• 与 db 服务不同的是，不存在 api 服务的预构建镜像。因此，将使用 Dockerfile.dev 文件。
• volumes 块定义了任何服务所需的任何名称卷。当时，它仅登记 db 服务使用的是 notes-db-dev-data 卷。

既然已经对 docker-compose.yaml 文件有了一个高层次的概述，那么让我们仔细看一下各个服务。

db 服务的定义代码如下：

db:
    image: postgres:12
    container_name: notes-db-dev
    volumes: 
        - db-data:/var/lib/postgresql/data
    environment:
        POSTGRES_DB: notesdb
        POSTGRES_PASSWORD: secret

• image 键保存用于此容器的镜像仓库和标签。使用 postgres:12 镜像来运行数据库容器。
• container_name 指示容器的名称。默认情况下，容器使用 <project directory name>_<service name> 语法命名。可以使用 container_name 覆盖它。
• volumes 数组保存该服务的卷映射，并支持命名卷，匿名卷和绑定挂载。 语法 <source>:<destination> 与之前相同。
• environment map 包含服务所需的各种环境变量的值。

api 服务的定义代码如下：

api:
    build:
        context: ./api
        dockerfile: Dockerfile.dev
    image: notes-api:dev
    container_name: notes-api-dev
    environment: 
        DB_HOST: db 
        DB_DATABASE: notesdb
        DB_PASSWORD: secret
    volumes: 
        - /home/node/app/node_modules
        - ./api:/home/node/app
    ports: 
        - 3000:3000

• api 服务没有预构建的镜像。相反，它具有构建配置。在 build 块下，定义了用于构建镜像的上下文和 Dockerfile 的名称。到目前为止，应该已经了解了上下文和 Dockerfile，因此我不会花时间解释它们。
• image 键保存要构建的镜像的名称。如果未分配，则将使用 <project directory name>_<service name> 语法来命名镜像。
• 在 environment map 内部，DB_HOST 变量演示了 Compose 的功能。即，可以使用其名称引用同一应用程序中的另一服务。因此，此处的 db 将被 api 服务容器的 IP 地址代替。DB_DATABASE 和 DB_PASSWORD 变量必须分别与 db 服务定义中的 POSTGRES_DB 和 POSTGRES_PASSWORD 匹配。
• 在 volumes map 中，可以看到一个匿名卷和一个绑定挂载。语法与上一节中看到的相同。
• ports 映射定义了端口映射。 语法 <host port>:<container port> 与以前使用的 --publish 选项相同。

最后，volumes 的代码如下：

volumes:
    db-data:
        name: notes-db-dev-data

在此处定义服务中使用的命名卷。如果未定义名称，则将使用 <project directory name>_<volume key> 命名该卷，此处的密钥为 db-data。

可以在官方文档中了解有关卷配置的更多选项。

如何在 Docker Compose 中启动服务

有几种启动 YAML 文件中定义的服务的方法。将了解的第一个命令是 up 命令。up 命令可以构建所有丢失的镜像，创建容器，然后一次性启动它们。

在执行命令之前，请确保已在 docker-compose.yaml 文件所在的目录中打开了终端。 这对于执行的每个 docker-compose 命令都非常重要。

docker-compose --file docker-compose.yaml up --detach

# Creating network "notes-api_default" with the default driver
# Creating volume "notes-db-dev-data" with default driver
# Building api
# Sending build context to Docker daemon  37.38kB
#
# Step 1/13 : FROM node:lts-alpine as builder
#  ---> 471e8b4eb0b2
# Step 2/13 : RUN apk add --no-cache python make g++
#  ---> Running in 197056ec1964
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container 197056ec1964
#  ---> 6609935fe50b
# Step 3/13 : WORKDIR /app
#  ---> Running in 17010f65c5e7
# Removing intermediate container 17010f65c5e7
#  ---> b10d12e676ad
# Step 4/13 : COPY ./package.json .
#  ---> 600d31d9362e
# Step 5/13 : RUN npm install
#  ---> Running in a14afc8c0743
### LONG INSTALLATION STUFF GOES HERE ###
#  Removing intermediate container a14afc8c0743
#  ---> 952d5d86e361
# Step 6/13 : FROM node:lts-alpine
#  ---> 471e8b4eb0b2
# Step 7/13 : ENV NODE_ENV=development
#  ---> Running in 0d5376a9e78a
# Removing intermediate container 0d5376a9e78a
#  ---> 910c081ce5f5
# Step 8/13 : USER node
#  ---> Running in cfaefceb1eff
# Removing intermediate container cfaefceb1eff
#  ---> 1480176a1058
# Step 9/13 : RUN mkdir -p /home/node/app
#  ---> Running in 3ae30e6fb8b8
# Removing intermediate container 3ae30e6fb8b8
#  ---> c391cee4b92c
# Step 10/13 : WORKDIR /home/node/app
#  ---> Running in 6aa27f6b50c1
# Removing intermediate container 6aa27f6b50c1
#  ---> 761a7435dbca
# Step 11/13 : COPY . .
#  ---> b5d5c5bdf3a6
# Step 12/13 : COPY --from=builder /app/node_modules /home/node/app/node_modules
#  ---> 9e1a19960420
# Step 13/13 : CMD [ "./node_modules/.bin/nodemon", "--config", "nodemon.json", "bin/www" ]
#  ---> Running in 5bdd62236994
# Removing intermediate container 5bdd62236994
#  ---> 548e178f1386
# Successfully built 548e178f1386
# Successfully tagged notes-api:dev
# Creating notes-api-dev ... done
# Creating notes-db-dev  ... done

这里的 --detach 或 -d 选项的功能与之前相同。仅当 YAML 文件未命名为 docker-compose.yaml 时才需要使用 --file 或 -f 选项（但我已在此处用于演示目的）。

除了 up 命令外，还有 start 命令。两者之间的主要区别在于，start 命令不会创建丢失的容器，而只会启动现有的容器。基本上与 container start 命令相同。

up 命令的 --build 选项强制重建镜像。可以在官方文档中查阅 up 命令的更多选项。

如何在 Docker Compose 中列表展示服务

尽管可以使用 container ls 命令列出由 Compose 启动的服务容器，但是还可以用 ps 命令列出仅在 YAML 中定义的容器。

docker-compose ps

#     Name                   Command               State           Ports         
# -------------------------------------------------------------------------------
# notes-api-dev   docker-entrypoint.sh ./nod ...   Up      0.0.0.0:3000->3000/tcp
# notes-db-dev    docker-entrypoint.sh postgres    Up      5432/tcp

它不如 container ls 输出的信息丰富，但是当同时运行大量容器时，它很有用。

如何在 Docker Compose 正在运行的服务中执行命令

我希望你记得上一部分，必须运行一些迁移脚本来为此 API 创建数据库表。

就像 container exec 命令一样，docker-compose 也有 exec 命令。该命令的通用语法如下：

docker-compose exec <service name> <command>

要在 api 服务中执行 npm run db:migrate 命令，可以执行以下命令：

docker-compose exec api npm run db:migrate

# > notes-api@ db:migrate /home/node/app
# > knex migrate:latest
# 
# Using environment: development
# Batch 1 run: 1 migrations

与 container exec 命令不同，不需要为交互式会话传递 -it 标志。docker-compose 是自动完成的。

如何访问 Docker Compose 中正在运行的服务日志

也可以使用 logs 命令从正在运行的服务中检索日志。该命令的通用语法如下：

docker-compose logs <service name>

要从 api 服务访问日志，请执行以下命令：

docker-compose logs api

# Attaching to notes-api-dev
# notes-api-dev | [nodemon] 2.0.7
# notes-api-dev | [nodemon] reading config ./nodemon.json
# notes-api-dev | [nodemon] to restart at any time, enter `rs`
# notes-api-dev | [nodemon] or send SIGHUP to 1 to restart
# notes-api-dev | [nodemon] ignoring: *.test.js
# notes-api-dev | [nodemon] watching path(s): *.*
# notes-api-dev | [nodemon] watching extensions: js,mjs,json
# notes-api-dev | [nodemon] starting `node bin/www`
# notes-api-dev | [nodemon] forking
# notes-api-dev | [nodemon] child pid: 19
# notes-api-dev | [nodemon] watching 18 files
# notes-api-dev | app running -> http://127.0.0.1:3000

这只是日志输出的一部分。可以使用 -f 或 --follow 选项来钩住服务的输出流并实时获取日志。只要不按 ctrl + c 或关闭窗口退出，任何以后的日志都会立即显示在终端中。即使退出日志窗口，该容器也将继续运行。

如何在 Docker Compose 中停止服务

要停止服务，可以采用两种方法。第一个是 down 命令。down 命令将停止所有正在运行的容器并将其从系统中删除。它还会删除所有网络：

docker-compose down --volumes

# Stopping notes-api-dev ... done
# Stopping notes-db-dev  ... done
# Removing notes-api-dev ... done
# Removing notes-db-dev  ... done
# Removing network notes-api_default
# Removing volume notes-db-dev-data

--volumes 选项表示要删除 volumes 块中定义的所有命名卷。可以在官方文档 中查阅有关 down 命令的更多选用法。

另一个停止服务的命令是 stop 命令，其功能与 container stop 命令相同。它停止应用程序的所有容器并保留它们。这些容器可以稍后使用 start 或 up 命令启动。

如何在 Docker Compose 中编写全栈应用程序

在本小节中，我们将在 Notes API 中添加一个前端，并将其转变为一个完整的全栈应用程序。在本小节中，我将不解释 Dockerfile.dev 文件内容（除了关于 nginx 服务的部分），因为它们与上一小节中已经看到的其他文件相同。

如果已经克隆了项目代码仓库，进入 fullstack-notes-application 目录。项目根目录下的每个目录都包含每个服务的代码和相应的 Dockerfile。

在开始使用 docker-compose.yaml 文件之前，让我们看一下该应用程序的流程图：

与其像以前那样直接接受请求，在此应用程序中，所有请求都将首先由 NGINX（我们称其为路由器）服务接收。

然后，路由器将查看所请求的路径中是否包含 /api。如果是，则路由器会将请求路由到后端，否则，路由器会将请求路由到前端。

这样做是因为在运行前端应用程序时，它不会在容器中运行。 它在浏览器上运行，并通过容器提供服务。结果，Compose 网络无法按预期工作，并且前端应用程序无法找到 api 服务。

另一方面，NGINX 在容器内运行，并且可以与整个应用程序中的不同服务进行通信。

在这里介绍不 NGINX 的配置。该主题有点超出了本书的范围。如果你想了解，请继续阅读 /notes-api/nginx/development.conf 和 /notes-api/nginx/production.conf 文件。/notes-api/nginx/Deockerfile.dev 的代码如下：

FROM nginx:stable-alpine

COPY ./development.conf /etc/nginx/conf.d/default.conf

它所做的只是将配置文件复制到容器内的 /etc/nginx/conf.d/default.conf 中。

让我们开始编写 docker-compose.yaml 文件。除了 api 和 db 服务之外，还有client 和 nginx 服务。还将很快介绍一些网络定义。

version: "3.8"

services: 
    db:
        image: postgres:12
        container_name: notes-db-dev
        volumes: 
            - db-data:/var/lib/postgresql/data
        environment:
            POSTGRES_DB: notesdb
            POSTGRES_PASSWORD: secret
        networks:
            - backend
    api:
        build: 
            context: ./api
            dockerfile: Dockerfile.dev
        image: notes-api:dev
        container_name: notes-api-dev
        volumes: 
            - /home/node/app/node_modules
            - ./api:/home/node/app
        environment: 
            DB_HOST: db 
            DB_PORT: 5432
            DB_USER: postgres
            DB_DATABASE: notesdb
            DB_PASSWORD: secret
        networks:
            - backend
    client:
        build:
            context: ./client
            dockerfile: Dockerfile.dev
        image: notes-client:dev
        container_name: notes-client-dev
        volumes: 
            - /home/node/app/node_modules
            - ./client:/home/node/app
        networks:
            - frontend
    nginx:
        build:
            context: ./nginx
            dockerfile: Dockerfile.dev
        image: notes-router:dev
        container_name: notes-router-dev
        restart: unless-stopped
        ports: 
            - 8080:80
        networks:
            - backend
            - frontend

volumes:
    db-data:
        name: notes-db-dev-data

networks: 
    frontend:
        name: fullstack-notes-application-network-frontend
        driver: bridge
    backend:
        name: fullstack-notes-application-network-backend
        driver: bridge

该文件与之前用到的文件几乎相同。唯一需要说明的是网络配置。networks 块的代码如下：

networks: 
    frontend:
        name: fullstack-notes-application-network-frontend
        driver: bridge
    backend:
        name: fullstack-notes-application-network-backend
        driver: bridge

我定义了两个桥接网络。默认情况下，Compose 创建一个桥接网络并将所有容器连接到该网络。但是，在这个项目中，我想要适当的网络隔离。 因此，我定义了两个网络，一个用于前端服务，一个用于后端服务。

我还在每个服务定义中添加了 networks 块。 这样，api 和 db 服务将被附加到同一个网络，而 client 服务将被附加到一个单独的网络。 但是 nginx 服务将同时连接到两个网络，因此它可以充当前端和后端服务之间的路由器。

通过执行以下命令来启动所有服务：

docker-compose --file docker-compose.yaml up --detach

# Creating network "fullstack-notes-application-network-backend" with driver "bridge"
# Creating network "fullstack-notes-application-network-frontend" with driver "bridge"
# Creating volume "notes-db-dev-data" with default driver
# Building api
# Sending build context to Docker daemon  37.38kB
# 
# Step 1/13 : FROM node:lts-alpine as builder
#  ---> 471e8b4eb0b2
# Step 2/13 : RUN apk add --no-cache python make g++
#  ---> Running in 8a4485388fd3
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container 8a4485388fd3
#  ---> 47fb1ab07cc0
# Step 3/13 : WORKDIR /app
#  ---> Running in bc76cc41f1da
# Removing intermediate container bc76cc41f1da
#  ---> 8c03fdb920f9
# Step 4/13 : COPY ./package.json .
#  ---> a1d5715db999
# Step 5/13 : RUN npm install
#  ---> Running in fabd33cc0986
### LONG INSTALLATION STUFF GOES HERE ###
# Removing intermediate container fabd33cc0986
#  ---> e09913debbd1
# Step 6/13 : FROM node:lts-alpine
#  ---> 471e8b4eb0b2
# Step 7/13 : ENV NODE_ENV=development
#  ---> Using cache
#  ---> b7c12361b3e5
# Step 8/13 : USER node
#  ---> Using cache
#  ---> f5ac66ca07a4
# Step 9/13 : RUN mkdir -p /home/node/app
#  ---> Using cache
#  ---> 60094b9a6183
# Step 10/13 : WORKDIR /home/node/app
#  ---> Using cache
#  ---> 316a252e6e3e
# Step 11/13 : COPY . .
#  ---> Using cache
#  ---> 3a083622b753
# Step 12/13 : COPY --from=builder /app/node_modules /home/node/app/node_modules
#  ---> Using cache
#  ---> 707979b3371c
# Step 13/13 : CMD [ "./node_modules/.bin/nodemon", "--config", "nodemon.json", "bin/www" ]
#  ---> Using cache
#  ---> f2da08a5f59b
# Successfully built f2da08a5f59b
# Successfully tagged notes-api:dev
# Building client
# Sending build context to Docker daemon  43.01kB
# 
# Step 1/7 : FROM node:lts-alpine
#  ---> 471e8b4eb0b2
# Step 2/7 : USER node
#  ---> Using cache
#  ---> 4be5fb31f862
# Step 3/7 : RUN mkdir -p /home/node/app
#  ---> Using cache
#  ---> 1fefc7412723
# Step 4/7 : WORKDIR /home/node/app
#  ---> Using cache
#  ---> d1470d878aa7
# Step 5/7 : COPY ./package.json .
#  ---> Using cache
#  ---> bbcc49475077
# Step 6/7 : RUN npm install
#  ---> Using cache
#  ---> 860a4a2af447
# Step 7/7 : CMD [ "npm", "run", "serve" ]
#  ---> Using cache
#  ---> 11db51d5bee7
# Successfully built 11db51d5bee7
# Successfully tagged notes-client:dev
# Building nginx
# Sending build context to Docker daemon   5.12kB
# 
# Step 1/2 : FROM nginx:stable-alpine
#  ---> f2343e2e2507
# Step 2/2 : COPY ./development.conf /etc/nginx/conf.d/default.conf
#  ---> Using cache
#  ---> 02a55d005a98
# Successfully built 02a55d005a98
# Successfully tagged notes-router:dev
# Creating notes-client-dev ... done
# Creating notes-api-dev    ... done
# Creating notes-router-dev ... done
# Creating notes-db-dev     ... done

现在访问 http://localhost:8080，瞧瞧！

尝试添加和删除注释，以查看应用程序是否正常运行。该项目还带有 shell 脚本和Makefile。研究一下他们，以了解如何像上一节中那样在没有 docker-compose 的帮助下运行该项目。

结语

衷心感谢你花了宝贵的时间阅读本书。我希望你喜欢它并学到 Docker 的相关知识。

如果你喜欢我的文笔，则可以在这里找到更多的的书，我偶尔也写一些博客。

可以在 Twitter @frhnhsin 上关注我，也可以在 LinkedIn /in/farhanhasin 联系我。

原文：The Docker Handbook – 2021 Edition，作者：Farhan Hasin Chowdhury

在继续阅读本指南之前，你应该对 Python 编程语言和 Flask 框架有基本的了解。如果你不熟悉这些内容，建议阅读介绍性文章 - 如何使用 Python 和 Flask 构建 Web 应用程序。

本指南的结构

本指南分为以下几部分：

• 功能
• Flask-RESTPlus 是什么？
• 安装和配置
• 项目配置和结构
• 配置设定
• Flask Script
• 数据库 Model 和迁移
• 测试
• 配置
• User 操作
• 安全与认证
• 拓展 & 结论

功能

项目将涉及以下功能和扩展。

• Flask-Bcrypt: 一个 Flask 扩展，提供了 bcrypt 散列功能。
• Flask-Migrate: 一个使用 Alembic 为 Flask 应用处理 SQLAlchemy 数据库迁移的扩展，可以通过 Flask 的命令行接口或者 Flask-Scripts 对数据库进行操作。
• Flask-SQLAlchemy: 一个 Flask 扩展，给应用添加了 SQLAlchemy 支持。
• PyJWT: 可以编码解码 JSON Web Tokens (JWT) 的 Python 库。JWT 是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519)。
• Flask-Script: 一个提供了向 Flask 插入外部脚本的功能的扩展，它可以运行除 web 应用之外的命令行任务。
• Namespaces (Blueprints)
• Flask-restplus
• UnitTest

Flask-RESTPlus 是什么？

Flask-RESTPlus 是 Flask 的扩展，可以通过它快速构建 REST API。Flask-RESTPlus 最佳实践鼓励配置尽可能少。它提供了大量的装饰器和工具来描述 API，并以文档化的形式将这些接口展现出来（通过 Swagger 来实现）。

安装和配置

在 Terminal 中输入命令 pip --version 来检查是否已安装 pip，然后回车。

pip --version

如果终端输出版本号，表示已安装 pip，可以继续执行下一步，否则请先安装 pip，如果使用 Linux 包管理器，可以在终端上运行以下命令，回车。选择 Python 2.x 或 3.x 版本。

• Python 2.x

sudo apt-get install python-pip

• Python 3.x

sudo apt-get install python3-pip

设置 virtual 环境或 virtual 环境 wrapper（只需要其中之一，取决于上面安装的版本）：

sudo pip install virtualenv

sudo pip3 install virtualenvwrapper

请按照此链接进行 virtual 环境 wrapper 的完整设置。

通过在终端上执行以下命令来创建新环境并激活它：

mkproject name_of_your_project

项目配置和结构

这里使用功能性结构通过文件的功能来组织项目文件。在功能结构里，模板、静态文件、视图在三个不同的目录中。

在项目目录中，创建一个名为 app 的新包。在 app 内部，创建两个包 main 和 test。 目录结构如下。

.
├── app
│   ├── __init__.py
│   ├── main
│   │   └── __init__.py
│   └── test
│       └── __init__.py
└── requirements.txt

接下来使用功能结构来模块化应用程序。

在 main 包中，再创建三个包，即：controller，service 和 model。 model 包将包含所有的数据库模型，而 service 包将包含应用程序的所有业务逻辑，最后 controller 包将包含所有的应用程序接口。 现在，树结构应如下所示：

.
├── app
│   ├── __init__.py
│   ├── main
│   │   ├── controller
│   │   │   └── __init__.py
│   │   ├── __init__.py
│   │   ├── model
│   │   │   └── __init__.py
│   │   └── service
│   │       └── __init__.py
│   └── test
│       └── __init__.py
└── requirements.txt

现在，来安装所需的软件包。 确保已激活创建的 virtual 环境，并在终端上运行以下命令：

pip install flask-bcrypt

pip install flask-restplus

pip install Flask-Migrate

pip install pyjwt

pip install Flask-Script

pip install flask_testing

通过运行以下命令来创建/更新 requirements.txt 文件：

pip freeze > requirements.txt

生成的 requirements.txt 文件应该如下：

alembic==0.9.8
aniso8601==3.0.0
bcrypt==3.1.4
cffi==1.11.5
click==6.7
Flask==0.12.2
Flask-Bcrypt==0.7.1
Flask-Migrate==2.1.1
flask-restplus==0.10.1
Flask-Script==2.0.6
Flask-SQLAlchemy==2.3.2
Flask-Testing==0.7.1
itsdangerous==0.24
Jinja2==2.10
jsonschema==2.6.0
Mako==1.0.7
MarkupSafe==1.0
pycparser==2.18
PyJWT==1.6.0
python-dateutil==2.7.0
python-editor==1.0.3
pytz==2018.3
six==1.11.0
SQLAlchemy==1.2.5
Werkzeug==0.14.1

配置设定

在 main 包中创建一个名为 config.py 的文件，内容如下：

import os




basedir = os.path.abspath(os.path.dirname(__file__))

class Config:
    SECRET_KEY = os.getenv('SECRET_KEY', 'my_precious_secret_key')
    DEBUG = False


class DevelopmentConfig(Config):
    
    
    DEBUG = True
    SQLALCHEMY_DATABASE_URI = 'sqlite:///' + os.path.join(basedir, 'flask_boilerplate_main.db')
    SQLALCHEMY_TRACK_MODIFICATIONS = False


class TestingConfig(Config):
    DEBUG = True
    TESTING = True
    SQLALCHEMY_DATABASE_URI = 'sqlite:///' + os.path.join(basedir, 'flask_boilerplate_test.db')
    PRESERVE_CONTEXT_ON_EXCEPTION = False
    SQLALCHEMY_TRACK_MODIFICATIONS = False


class ProductionConfig(Config):
    DEBUG = False
    
    


config_by_name = dict(
    dev=DevelopmentConfig,
    test=TestingConfig,
    prod=ProductionConfig
)

key = Config.SECRET_KEY

配置文件包含三个环境设置 class，其中包括 testing、development 和 production。

这里将使用应用程序工厂模式创建 Flask 对象。在对不同的配置创建多个实例时这个模式很方便。通过传入必填参数调用 create_app 函数，可以方便地在测试、开发和生产环境之间进行切换。

在 main 包内的 __init__.py 文件中，输入以下代码：

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
from flask_bcrypt import Bcrypt

from .config import config_by_name

db = SQLAlchemy()
flask_bcrypt = Bcrypt()


def create_app(config_name):
    app = Flask(__name__)
    app.config.from_object(config_by_name[config_name])
    db.init_app(app)
    flask_bcrypt.init_app(app)

    return app

Flask Script

现在，创建应用程序入口点。在项目的根目录中，创建一个名为 manage.py 的文件，其内容如下：

import os
import unittest

from flask_migrate import Migrate, MigrateCommand
from flask_script import Manager

from app.main import create_app, db

app = create_app(os.getenv('BOILERPLATE_ENV') or 'dev')

app.app_context().push()

manager = Manager(app)

migrate = Migrate(app, db)

manager.add_command('db', MigrateCommand)

@manager.command
def run():
    app.run()

@manager.command
def test():
    """Runs the unit tests."""
    tests = unittest.TestLoader().discover('app/test', pattern='test*.py')
    result = unittest.TextTestRunner(verbosity=2).run(tests)
    if result.wasSuccessful():
        return 0
    return 1

if __name__ == '__main__':
    manager.run()

上面的 manage.py 中的代码做了以下操作：

• line 4和 5 分别导入 migration 和 manager 模块（很快会用到 migration 命令）。
• line 9 调用开始创建的 create_app 函数，使用环境变量中的必添参数创建应用程序实例，该参数可以是 - dev、prod 或 test。如果环境变量中未设置任何值，则默认使用 dev。
• line 13 和 15 将 app 实例传递给它们各自的构造函数来实例化 manager 和 migrate class。
• 在 line 17 中，将 db 和 MigrateCommand 实例传递给 manager 的 add_command 接口，以通过 Flask-Script 暴露所有数据库迁移命令。
• line 20 和 25 将这两个函数标记为可从命令行执行函数。

Flask-Migrate 暴露了两个 class，Migrate 和 MigrateCommand。 Migrate class 包含扩展的所有功能。MigrateCommand class 仅在需要通过 Flask-Script 扩展公开数据库迁移命令时使用。

此时，可以通过在项目根目录中运行以下命令来测试应用程序。

python manage.py run

如果一切正常，应该会看到类似以下内容：

数据库 Model 和迁移

现在，开始创建模型。这里使用 sqlalchemy 的 db 实例来创建模型。

db 实例包含 **sqlalchemy ** 和 sqlalchemy.orm，它提供了一个名为 Model 的 class，该 class 是用于声明 model 的基础性声明。

在 model 包中，创建一个名为 user.py 的文件，其内容如下：

from .. import db, flask_bcrypt

class User(db.Model):
    """ User Model for storing user related details """
    __tablename__ = "user"

    id = db.Column(db.Integer, primary_key=True, autoincrement=True)
    email = db.Column(db.String(255), unique=True, nullable=False)
    registered_on = db.Column(db.DateTime, nullable=False)
    admin = db.Column(db.Boolean, nullable=False, default=False)
    public_id = db.Column(db.String(100), unique=True)
    username = db.Column(db.String(50), unique=True)
    password_hash = db.Column(db.String(100))

    @property
    def password(self):
        raise AttributeError('password: write-only field')

    @password.setter
    def password(self, password):
        self.password_hash = flask_bcrypt.generate_password_hash(password).decode('utf-8')

    def check_password(self, password):
        return flask_bcrypt.check_password_hash(self.password_hash, password)

    def __repr__(self):
        return "<User '{}'>".format(self.username)

上面的 user.py 代码执行以下操作：

• line 3: user class 继承自 db.Model class，声明为 sqlalchemy 的模型。
• line7 行到 13 会为 user 表创建所需的列。
• line 21 是 password_hash 字段的 setter，它使用 flask-bcrypt 来使用提供的密码来生成哈希。
• line 24 将给定的密码和已经保存的 password_hash 进行比较。

现在要从刚刚创建的 user model 生成数据库表，将通过 manager 接口的 migrateCommand 来生成。为了使 manager 能够检测到我们的 model，我们必须通过在 manage.py 文件中添加以下代码来导入 user 模型：

...
from app.main.model import user
...

现在，可以通过在项目根目录上运行以下命令来继续执行 migration：

1. 使用 init 命令启动一个迁移文件夹以使 Alembic 执行迁移。

python manage.py db init

2. 使用 migrate 命令检测 model 的更改并创建迁移脚本。这不会影响数据库。

python manage.py db migrate --message 'initial database migration'

2. 使用 upgrade 命令将迁移脚本应用于数据库

python manage.py db upgrade

如果一切顺利运行，则应该创建了一个新的 sqlite 数据库，并在主包内生成一个flask_boilerplate_main.db 文件。

每次数据库模型更改时，都执行一次 migrate 和 upgrade 命令

测试

配置

为确保的环境配置的设置没问题，来编写一些测试。

在测试包中创建一个名为 test_config.py 的文件，其内容如下：

import os
import unittest

from flask import current_app
from flask_testing import TestCase

from manage import app
from app.main.config import basedir


class TestDevelopmentConfig(TestCase):
    def create_app(self):
        app.config.from_object('app.main.config.DevelopmentConfig')
        return app

    def test_app_is_development(self):
        self.assertFalse(app.config['SECRET_KEY'] is 'my_precious')
        self.assertTrue(app.config['DEBUG'] is True)
        self.assertFalse(current_app is None)
        self.assertTrue(
            app.config['SQLALCHEMY_DATABASE_URI'] == 'sqlite:///' + os.path.join(basedir, 'flask_boilerplate_main.db')
        )


class TestTestingConfig(TestCase):
    def create_app(self):
        app.config.from_object('app.main.config.TestingConfig')
        return app

    def test_app_is_testing(self):
        self.assertFalse(app.config['SECRET_KEY'] is 'my_precious')
        self.assertTrue(app.config['DEBUG'])
        self.assertTrue(
            app.config['SQLALCHEMY_DATABASE_URI'] == 'sqlite:///' + os.path.join(basedir, 'flask_boilerplate_test.db')
        )


class TestProductionConfig(TestCase):
    def create_app(self):
        app.config.from_object('app.main.config.ProductionConfig')
        return app

    def test_app_is_production(self):
        self.assertTrue(app.config['DEBUG'] is False)


if __name__ == '__main__':
    unittest.main()

使用以下命令运行测试：

python manage.py test

应该会看到以下输出：

User 操作

现在，来做如下与 user 相关的操作：

• 创建一个新 user
• 通过 user 的 public_id 获取一个已注册的 user
• 获取所有的注册 user

**User Service class：**此 class 处理与 user model 有关的所有逻辑。
在 service 包中，创建一个具有以下内容的新文件 user_service.py：

import uuid
import datetime

from app.main import db
from app.main.model.user import User


def save_new_user(data):
    user = User.query.filter_by(email=data['email']).first()
    if not user:
        new_user = User(
            public_id=str(uuid.uuid4()),
            email=data['email'],
            username=data['username'],
            password=data['password'],
            registered_on=datetime.datetime.utcnow()
        )
        save_changes(new_user)
        response_object = {
            'status': 'success',
            'message': 'Successfully registered.'
        }
        return response_object, 201
    else:
        response_object = {
            'status': 'fail',
            'message': 'User already exists. Please Log in.',
        }
        return response_object, 409


def get_all_users():
    return User.query.all()


def get_a_user(public_id):
    return User.query.filter_by(public_id=public_id).first()


def save_changes(data):
    db.session.add(data)
    db.session.commit()

上面的 user_service.py 中的代码执行以下操作：

• line 8 到 29 首先检查该 user 是否已存在然后在创建新 user；如果 user 不存在，则返回成功的 response_object，否则返回错误代码 409 和失败的 response_object。
• line 33 和 37 分别通过提供 public_id 返回所有注册用户的列表和一个用户的对象。
• line 40 到 42 将更改提交到数据库。

无需在使用 jsonify 将对象格式化为 JSON，Flask-restplus 会自动将其格式化

在 main 包中，创建一个名为 util 的新包。该软件包将包含我们在应用程序中可能需要的所有必要工具。

在 util 包中，创建一个新文件 dto.py。顾名思义，就是数据传输对象（DTO）将负责在进程之间传递数据。在这里，它将用于封装 API 调用的数据。在使用中会更容易理解。

from flask_restplus import Namespace, fields


class UserDto:
    api = Namespace('user', description='user related operations')
    user = api.model('user', {
        'email': fields.String(required=True, description='user email address'),
        'username': fields.String(required=True, description='user username'),
        'password': fields.String(required=True, description='user password'),
        'public_id': fields.String(description='user Identifier')
    })

上面的 dto.py 中代码执行以下操作：

• line 5 为与 user 相关的操作创建了一个新的命名空间。Flask-RESTPlus 提供了一种使用几乎与蓝图模式相同的的方法。主要思想是将应用拆分为可重用的命名空间。命名空间模块将包含 models 和资源声明。
• line 6 通过 line 5 中的 api 命名空间提供的 model 接口创建了新用户的 dto。

User Controller： User Controller class 处理所有传入 HTTP 的与 user 有关的请求。

在 controller 包下，创建一个名为 user_controller.py 的新文件，其内容如下：

from flask import request
from flask_restplus import Resource

from ..util.dto import UserDto
from ..service.user_service import save_new_user, get_all_users, get_a_user

api = UserDto.api
_user = UserDto.user


@api.route('/')
class UserList(Resource):
    @api.doc('list_of_registered_users')
    @api.marshal_list_with(_user, envelope='data')
    def get(self):
        """List all registered users"""
        return get_all_users()

    @api.response(201, 'User successfully created.')
    @api.doc('create a new user')
    @api.expect(_user, validate=True)
    def post(self):
        """Creates a new User """
        data = request.json
        return save_new_user(data=data)


@api.route('/<public_id>')
@api.param('public_id', 'The User identifier')
@api.response(404, 'User not found.')
class User(Resource):
    @api.doc('get a user')
    @api.marshal_with(_user)
    def get(self, public_id):
        """get a user given its identifier"""
        user = get_a_user(public_id)
        if not user:
            api.abort(404)
        else:
            return user

line 1 到 8 行会导入 user controller 所需的所有资源。在 user controller 中定义了两个具体的 class，分别是 userList 和 user。这两个 class 扩展了抽象的 flask-restplus 资源。

具体资源应从此 class 扩展并暴露每个支持的 HTTP 方法。如果使用不支持的 HTTP 方法调用资源，则 API 将返回状态为 405 Method Not Allowe 的响应。否则，将调用适当的方法并在将资源添加到 API 实例时传递所有的 URL 参数。

上面 line 7中的 api 命名空间为 controller 提供了多个装饰器，包括但不限于以下几种：

• api.route: route 资源的装饰器
• api.marshal_with: 一个用来指定需要序列化字段的装饰器 (就是用到的之前创建的 __userDto__ )
• api.marshal_list_with: as_list = True__ 上面的 __marshal_with__ 的快捷装饰器
• api.doc: 用于向装饰对象添加 api 文档的装饰器
• api.response: 用于指定预期的一个响应的装饰器
• api.expect:一个装饰器，用于指定预期的输入 model（仍然使用__userDto__ 作为预期的输入）的装饰器
• api.param: 指定一个预期参数的装饰器

现在，已经使用 user controller 定义了命名空间。现在是时候将其添加到应用程序入口了。

在 app 包的 __init__.py 文件中，输入以下内容：

from flask_restplus import Api
from flask import Blueprint

from .main.controller.user_controller import api as user_ns

blueprint = Blueprint('api', __name__)

api = Api(blueprint,
          title='FLASK RESTPLUS API BOILER-PLATE WITH JWT',
          version='1.0',
          description='a boilerplate for flask restplus web service'
          )

api.add_namespace(user_ns, path='/user')

上面的 blueprint.py 代码执行以下操作：

• 在 line 8 中，通过传入 name 和 import_name 来创建一个蓝图实例。API 是应用程序资源的主要入口，因此需要在 line 10 中使用 blueprint 进行初始化。
• 在 line 16 中，将 user 命名空间 user_ns 添加到 API 实例中的命名空间列表中。

现在，已经定义了蓝图。 现在是时候在 Flask 应用中注册它了。
更新 manage.py，导入 blueprint 并将其注册到 Flask 应用程序实例中。

from app import blueprint
...

app = create_app(os.getenv('BOILERPLATE_ENV') or 'dev')
app.register_blueprint(blueprint)

app.app_context().push()

...

现在测试一下的应用程序，看看是否一切正常。

python manage.py run

现在，在浏览器中打开 URL http://127.0.0.1:5000。 应该可以看到 swagger 的文档。

让我们使用 swagger 的测试功能来测试 create new user 接口。

应该会得到如下响应

安全与认证

创建一个 blacklistToken model 来存储列入黑名单的 tokens。在 models 包中，创建具有以下内容的 blacklist.py文件：

from .. import db
import datetime


class BlacklistToken(db.Model):
    """
    Token Model for storing JWT tokens
    """
    __tablename__ = 'blacklist_tokens'

    id = db.Column(db.Integer, primary_key=True, autoincrement=True)
    token = db.Column(db.String(500), unique=True, nullable=False)
    blacklisted_on = db.Column(db.DateTime, nullable=False)

    def __init__(self, token):
        self.token = token
        self.blacklisted_on = datetime.datetime.now()

    def __repr__(self):
        return '<id: token: {}'.format(self.token)

    @staticmethod
    def check_blacklist(auth_token):
        
        res = BlacklistToken.query.filter_by(token=str(auth_token)).first()
        if res:
            return True
        else:
            return False

别忘了 migrate 所做的更改以对数据库生效。
在 manage.py 中导入 blacklist 类。

from app.main.model import blacklist

运行 migrate 和 upgrade 命令

python manage.py db migrate --message 'add blacklist table'

python manage.py db upgrade

接下来，在服务包中创建内容如下的 blacklist_service.py，以将令牌列入黑名单：

from app.main import db
from app.main.model.blacklist import BlacklistToken


def save_token(token):
    blacklist_token = BlacklistToken(token=token)
    try:
        
        db.session.add(blacklist_token)
        db.session.commit()
        response_object = {
            'status': 'success',
            'message': 'Successfully logged out.'
        }
        return response_object, 200
    except Exception as e:
        response_object = {
            'status': 'fail',
            'message': e
        }
        return response_object, 200

使用编码和解码令牌的静态方法来更新 user 模型。添加以下导入：

import datetime
import jwt
from app.main.model.blacklist import BlacklistToken
from ..config import key

• 编码

def encode_auth_token(self, user_id):
        """
        Generates the Auth Token
        :return: string
        """
        try:
            payload = {
                'exp': datetime.datetime.utcnow() + datetime.timedelta(days=1, seconds=5),
                'iat': datetime.datetime.utcnow(),
                'sub': user_id
            }
            return jwt.encode(
                payload,
                key,
                algorithm='HS256'
            )
        except Exception as e:
            return e

• 解码：在对身份验证令牌进行解码时，会考虑列入黑名单的令牌、过期的令牌和无效的令牌。

  @staticmethod  
  def decode_auth_token(auth_token):
        """
        Decodes the auth token
        :param auth_token:
        :return: integer|string
        """
        try:
            payload = jwt.decode(auth_token, key)
            is_blacklisted_token = BlacklistToken.check_blacklist(auth_token)
            if is_blacklisted_token:
                return 'Token blacklisted. Please log in again.'
            else:
                return payload['sub']
        except jwt.ExpiredSignatureError:
            return 'Signature expired. Please log in again.'
        except jwt.InvalidTokenError:
            return 'Invalid token. Please log in again.'

现在，为 user model 编写一个测试，以确保 encode 和 decode 功能运行正常。

在 test 包中，创建内容如下的 base.py 文件：

from flask_testing import TestCase
from app.main import db
from manage import app


class BaseTestCase(TestCase):
    """ Base Tests """

    def create_app(self):
        app.config.from_object('app.main.config.TestingConfig')
        return app

    def setUp(self):
        db.create_all()
        db.session.commit()

    def tearDown(self):
        db.session.remove()
        db.drop_all()

BaseTestCase 在扩展它的每个测试用例之前和之后设置了测试环境。

使用以下测试用例创建 test_user_medol.py：

import unittest
import datetime

from app.main import db
from app.main.model.user import User
from app.test.base import BaseTestCase


class TestUserModel(BaseTestCase):

    def test_encode_auth_token(self):
        user = User(
            email='test@test.com',
            password='test',
            registered_on=datetime.datetime.utcnow()
        )
        db.session.add(user)
        db.session.commit()
        auth_token = user.encode_auth_token(user.id)
        self.assertTrue(isinstance(auth_token, bytes))

    def test_decode_auth_token(self):
        user = User(
            email='test@test.com',
            password='test',
            registered_on=datetime.datetime.utcnow()
        )
        db.session.add(user)
        db.session.commit()
        auth_token = user.encode_auth_token(user.id)
        self.assertTrue(isinstance(auth_token, bytes))
        self.assertTrue(User.decode_auth_token(auth_token.decode("utf-8") ) == 1)


if __name__ == '__main__':
    unittest.main()

使用 python manage.py test 运行测试。所有测试都应该通过。

来为 login 和 logout 创建一个 authentication endpoints。

• 首先，我们需要一个 dto 作为登录 payload。将在登录端点的 @expect 注解中使用 auth dto。 将下面的代码添加到 dto.py 中

class AuthDto:
    api = Namespace('auth', description='authentication related operations')
    user_auth = api.model('auth_details', {
        'email': fields.String(required=True, description='The email address'),
        'password': fields.String(required=True, description='The user password '),
    })

• 接下来，创建一个身份验证 helper 类，以处理所有与身份验证相关的操作。该 auth_helper.py 将包含在服务包中，并将包含两个静态方法，分别是 login_user 和 logout_user。

用户退出登录后，该用户的令牌将被列入黑名单，即该用户无法使用该令牌再次登录。

from app.main.model.user import User
from ..service.blacklist_service import save_token


class Auth:

    @staticmethod
    def login_user(data):
        try:
            
            user = User.query.filter_by(email=data.get('email')).first()
            if user and user.check_password(data.get('password')):
                auth_token = user.encode_auth_token(user.id)
                if auth_token:
                    response_object = {
                        'status': 'success',
                        'message': 'Successfully logged in.',
                        'Authorization': auth_token.decode()
                    }
                    return response_object, 200
            else:
                response_object = {
                    'status': 'fail',
                    'message': 'email or password does not match.'
                }
                return response_object, 401

        except Exception as e:
            print(e)
            response_object = {
                'status': 'fail',
                'message': 'Try again'
            }
            return response_object, 500

    @staticmethod
    def logout_user(data):
        if data:
            auth_token = data.split(" ")[1]
        else:
            auth_token = ''
        if auth_token:
            resp = User.decode_auth_token(auth_token)
            if not isinstance(resp, str):
                
                return save_token(token=auth_token)
            else:
                response_object = {
                    'status': 'fail',
                    'message': resp
                }
                return response_object, 401
        else:
            response_object = {
                'status': 'fail',
                'message': 'Provide a valid auth token.'
            }
            return response_object, 403

• 现在让为 login 和 logout 操作创建 API。在 controller 包中，创建具有以下内容的 auth_controller.py：

from flask import request
from flask_restplus import Resource

from app.main.service.auth_helper import Auth
from ..util.dto import AuthDto

api = AuthDto.api
user_auth = AuthDto.user_auth


@api.route('/login')
class UserLogin(Resource):
    """
        User Login Resource
    """
    @api.doc('user login')
    @api.expect(user_auth, validate=True)
    def post(self):
        
        post_data = request.json
        return Auth.login_user(data=post_data)


@api.route('/logout')
class LogoutAPI(Resource):
    """
    Logout Resource
    """
    @api.doc('logout a user')
    def post(self):
        
        auth_header = request.headers.get('Authorization')
        return Auth.logout_user(data=auth_header)

• 此时，剩下的事情就是向应用程序 Blueprint 注册 auth api 命名空间。

如下更新 app 软件包的 __init __.py 文件

from flask_restplus import Api
from flask import Blueprint

from .main.controller.user_controller import api as user_ns
from .main.controller.auth_controller import api as auth_ns

blueprint = Blueprint('api', __name__)

api = Api(blueprint,
          title='FLASK RESTPLUS API BOILER-PLATE WITH JWT',
          version='1.0',
          description='a boilerplate for flask restplus web service'
          )

api.add_namespace(user_ns, path='/user')
api.add_namespace(auth_ns)

使用 python manage.py run 运行应用程序，然后在浏览器中打开网址 http://127.0.0.1:5000。

swagger 文档现在应该展示出新创建的带有 login 和 logout 接口的 auth 命名空间。

在编写测试以确保身份验证能够正常工作之前，先修改注册接口，以在 user 注册成功后自动登录。

将下面的方法 generate_token 添加到 user_service.py 中：

def generate_token(user):
    try:
        
        auth_token = user.encode_auth_token(user.id)
        response_object = {
            'status': 'success',
            'message': 'Successfully registered.',
            'Authorization': auth_token.decode()
        }
        return response_object, 201
    except Exception as e:
        response_object = {
            'status': 'fail',
            'message': 'Some error occurred. Please try again.'
        }
        return response_object, 401

generate_token 方法通过对用户 id 进行编码来生成身份验证令牌。此令牌作为响应返回。

接下来，在下面的 save_new_user 方法中替换 return 代码块

response_object = {
    'status': 'success',
    'message': 'Successfully registered.'
}
return response_object, 201

为

return generate_token(new_user)

现在该测试 login 和 logout 功能了。在测试包中创建一个具有以下内容的新测试文件 test_auth.py：

import unittest
import json
from app.test.base import BaseTestCase


def register_user(self):
    return self.client.post(
        '/user/',
        data=json.dumps(dict(
            email='example@gmail.com',
            username='username',
            password='123456'
        )),
        content_type='application/json'
    )


def login_user(self):
    return self.client.post(
        '/auth/login',
        data=json.dumps(dict(
            email='example@gmail.com',
            password='123456'
        )),
        content_type='application/json'
    )


class TestAuthBlueprint(BaseTestCase):

    def test_registered_user_login(self):
            """ Test for login of registered-user login """
            with self.client:
                
                user_response = register_user(self)
                response_data = json.loads(user_response.data.decode())
                self.assertTrue(response_data['Authorization'])
                self.assertEqual(user_response.status_code, 201)

                
                login_response = login_user(self)
                data = json.loads(login_response.data.decode())
                self.assertTrue(data['Authorization'])
                self.assertEqual(login_response.status_code, 200)

    def test_valid_logout(self):
        """ Test for logout before token expires """
        with self.client:
            
            user_response = register_user(self)
            response_data = json.loads(user_response.data.decode())
            self.assertTrue(response_data['Authorization'])
            self.assertEqual(user_response.status_code, 201)

            
            login_response = login_user(self)
            data = json.loads(login_response.data.decode())
            self.assertTrue(data['Authorization'])
            self.assertEqual(login_response.status_code, 200)

            
            response = self.client.post(
                '/auth/logout',
                headers=dict(
                    Authorization='Bearer ' + json.loads(
                        login_response.data.decode()
                    )['Authorization']
                )
            )
            data = json.loads(response.data.decode())
            self.assertTrue(data['status'] == 'success')
            self.assertEqual(response.status_code, 200)

if __name__ == '__main__':
    unittest.main()

请访问 GitHub repo 以获得更详尽的测试用例。

到目前为止，我们已经成功创建了接口，实现了登录和注销功能，但是接口仍然不受保护。

我们需要一种定义规则的方法，该规则确定接口是开放的的还是需要身份验证甚至是管理员特权才能访问。

可以通过为接口创建自定义装饰器来实现。

在可以保护或授权任何接口之前，需要知道当前登录的用户。为此，可以使用 flask 库的 request 从当前请求的 header 中提取 Authorization token 。然后，我们将从 Authorization token 中解码用户详细信息。

在 auth_helper.py 文件的 Auth 类中，添加以下静态方法：

@staticmethod
def get_logged_in_user(new_request):
        
        auth_token = new_request.headers.get('Authorization')
        if auth_token:
            resp = User.decode_auth_token(auth_token)
            if not isinstance(resp, str):
                user = User.query.filter_by(id=resp).first()
                response_object = {
                    'status': 'success',
                    'data': {
                        'user_id': user.id,
                        'email': user.email,
                        'admin': user.admin,
                        'registered_on': str(user.registered_on)
                    }
                }
                return response_object, 200
            response_object = {
                'status': 'fail',
                'message': resp
            }
            return response_object, 401
        else:
            response_object = {
                'status': 'fail',
                'message': 'Provide a valid auth token.'
            }
            return response_object, 401

现在可以从请求中检索已登录的用户，来继续创建 decorators。

在 util 包中创建一个文件 decorator.py，内容如下：

from functools import wraps
from flask import request

from app.main.service.auth_helper import Auth


def token_required(f):
    @wraps(f)
    def decorated(*args, **kwargs):

        data, status = Auth.get_logged_in_user(request)
        token = data.get('data')

        if not token:
            return data, status

        return f(*args, **kwargs)

    return decorated


def admin_token_required(f):
    @wraps(f)
    def decorated(*args, **kwargs):

        data, status = Auth.get_logged_in_user(request)
        token = data.get('data')

        if not token:
            return data, status

        admin = token.get('admin')
        if not admin:
            response_object = {
                'status': 'fail',
                'message': 'admin token required'
            }
            return response_object, 401

        return f(*args, **kwargs)

    return decorated

有关 decorators 及其创建方法的更多信息，请查看这个链接。

现在已经分别为有效令牌和管理员令牌创建了装饰器 token_required 和 admin_token_required，剩下的就是用 freecodecamp orgappropriate decorator 为希望保护的接口添加注解。

当前，要在应用程序中执行某些任务，需要运行不同的命令来启动应用程序、运行测试、安装依赖项等。可以使用 Makefile 将所有命令放在一个文件中来批量执行。

在应用程序的根目录上，创建一个没有文件扩展名的 Makefile。该文件应包含以下内容：

.PHONY: clean system-packages python-packages install tests run all

clean:
   find . -type f -name '*.pyc' -delete
   find . -type f -name '*.log' -delete

system-packages:
   sudo apt install python-pip -y

python-packages:
   pip install -r requirements.txt

install: system-packages python-packages

tests:
   python manage.py test

run:
   python manage.py run

all: clean install tests run

这是 make file 的选项。

1. make install : 安装 system-packages 以及 python-packages
2. make clean : 清理 app
3. make tests : 运行所有 tests
4. make run : 启动所有 application
5. make all : 执行 clean-up、installation 、 运行 tests ，并 starts app.

拓展 & 结论

复制当前应用程序架构并对其进行扩展，为该应用程序添加更多功能/接口非常容易。只需查看之前已实施的路由即可。

如有任何问题，意见或建议，请随时发表评论。另外，如果该帖子对你有所帮助，请分享出去，这样其他人也会看到并受益。

请访问 GitHub 仓库，以获取完整的项目。

感谢阅读，祝进步！

原文：How to structure a Flask-RESTPlus web service for production builds，作者：Greg Obinna

您是否也曾想过：

• 如何压缩某些东西而不丢失任何数据？
• 为什么有些算法压缩得比其他算法好？
• GZIP 是如何工作？

假设我们要压缩一个字符串（霍夫曼编码可以用于任何数据，但是字符串是很好的例子）。

不可避免地，在要压缩的文本中，某些字符会比其他字符出现得更频繁。 霍夫曼编码（Huffman Coding）基于这一事实，对文本进行了编码，以使最常用的字符比不常用的字符占用更少的空间。

编码字符串

让我们使用霍夫曼编码来压缩星球大战中 Yoda 的口头禅： “do or do not”。

“do or do not” 的长度为 12 个字符。 它有几个重复的字符，因此应该可以压缩一下。

为了便于讨论，假设存储每个字符需要 8 bits（字符编码完全是另一个主题）。这句话将占用 96 bits，但是使用霍夫曼编码可以做得更好！

先从建立树形结构开始。 数据中出现频率更高的字符更靠近树的根，而离根远的节点字符出现频率更低。

这是字符串 “do or do not” 的霍夫曼树：

字符串中最常见的字符是 “ o”（出现 4 次）和空格（出现 3 次）。请注意，这些字符的路径离根只有两步，而最不常见的字符（"t"）则有三步。

所以，可以不存储字符，而存储指向字符的路径。

从根节点开始，然后沿着树一直向着要编码的字符前进。 如果向左走，则将存储一个 0，如果向右走，则将存储一个 1。

这是使用这棵树编码第一个字符 d 的方法：

最终结果是 1 0 0 - 3 位而不是 8 位。这是一个很大的改进！

编码后的全部字符串如下所示：

占用 29 位而不是 96 位，并且没有数据丢失。 优秀！

解码字符串

要解码文本，只需根据 0（左分支）或 1（右分支）前进，直到获取到一个字符。 写下该字符，然后从顶部重新开始：

发送编码后的文本

但是等等，当我们将编码后的文本发送给其他人时，他们不是也需要这个编码树？ 是的！ 另一端需要相同的霍夫曼树才能正确解码文本。

最简单也是最低效的方法是将树与压缩文本一起发送。

当然也可以先约定同一棵树，然后使用该树对字符串进行编解码。 如果可以提前预测字符的分布，构建一个相对高效而无需每次都分析内容的树（例如，使用英文文本）也是可以的。

另一种选择是发送足够多的信息，以保证另一端与我们建立的是同一棵树（这也是 GZIP 的工作方式）。 例如，我们可以发送每个字符出现的总次数。 但是必须要小心；对于相同的文本块，可能有不止一个霍夫曼树，因此必须确保双方都以完全相同的方式构造树。

想要了解更多？

查看以下链接：