原文：
annas-archive.org/md5/45e4c1dd094b1fc87c70427ee3df9f4d译者：飞龙
第一章：前言
在不断发展的云计算领域中， 亚马逊网络服务 (AWS) 作为领导者，提供一系列服务，赋予企业和开发者力量。 但对您来说，AWS 不仅是一个技术平台，它还可以是通往蓬勃发展的就业市场的门户。 因此，无论您是雄心勃勃的云工程师、经验丰富的开发人员还是 IT 专业人士，如果您希望在 AWS 上提升自己的技能，这本书都适合您。 这本书是为您而写的。
本书采用项目为重点的方法，每一章都将引导您通过使用 AWS 服务来实现现实场景。从设置基本的基础设施以托管网站到利用服务器无架构计算和机器学习等高级功能来驱动聊天机器人，本书中的项目旨在为您提供解决实际领域挑战所需的技能。 但这还不是全部 – 您还将了解到可以用来实现相同业务目标的替代服务和架构，因为最终关键在于权衡其利弊。
通过本书，您将在实际操作 AWS 能力方面感到自信，并能够构建自己的云项目。 您将成为备受瞩目的 AWS 专家。
本书的读者群体
本书是为希望在云计算领域开启职业生涯的学生和具有其他技术领域（如软件开发）经验但希望拥抱新职业道路或补充其云计算技术技能的专业人士编写的。 如果您是其中之一，这本书适合您。
作为一本实用书籍，建议但不强制要求具备计算机科学或工程背景以及基本的编程技能。 所有项目都附有所使用服务的理论解释，并不假设任何之前的 AWS 知识。
本书涵盖内容
第一章, 部署和与 AWS 服务交互, 解释了使用 AWS 控制台是一个良好的起点，但还有更高级的选项，可以帮助您以可扩展的方式管理资源。 在本章中，您将学习创建和管理 AWS 资源的不同方法。 您还将了解 AWS CLI 和 SDK，并熟悉基础设施 即代码。
第二章，创建个人网站，作为第一章实践内容，介绍了你将要构建的项目：一个作为个人简历使用的个人网站。 接下来是解决方案的架构图，并附有如何在你自己的 AWS 账户中一步步构建该网站的指导。 本章最后给出了一些建议，用于改善你所构建的应用程序。 。
第三章，构建食谱分享应用程序，介绍了如何构建一个食谱分享应用程序。 你将学习如何构建动态应用程序，以及如何与数据库进行交互。 本章的结构与前一章相同，首先是对新功能的描述，接着是技术架构，然后是逐步构建和 测试的指导。
第四章，构建无服务器食谱分享应用程序，重新构建食谱分享应用程序，但这一次有了不同的实现方式。 与上一章类似，这也是一个动态 Web 应用程序。 然而，这一次，你将只使用无服务器服务。 由于项目的保密性质，你还将加入一个 身份验证机制。
第五章，实现图像分析器以检测照片的友好性，讲解了如何在选择个人简历照片之前，向同事寻求反馈，以了解照片的友好程度，那么如果你能够自动完成这个过程呢？ 假设每次你上传新照片时，你的应用程序会自动对照片的友好程度进行评分，并建议这张照片是否适合用作专业简历照片。 在本章中，你将使用 AWS 原生的 AI 服务来构建这一功能。
第六章，设计内容翻译管道，讲解了可访问性。 你是否曾访问过一个自动将页面翻译成你语言的网页？ 可访问性对于触及更广泛的受众非常重要。 在本章中，你将学习如何使用 CI/CD 管道自动将内容翻译成多种语言，并根据用户的 浏览器偏好动态展示翻译内容。
第七章， 使用机器学习实现聊天机器人，探讨了聊天机器人的使用。 每个人都听说过 ChatGPT。 在这一章中，你将构建一个虚拟助手，回答与网页开发相关的查询。 这个虚拟助手由最新的机器学习进展提供动力：大型 语言模型。
第八章， 构建商业智能应用，解释了如何不仅构建网页应用，还可以构建商业智能解决方案来分析数据并识别趋势。 在这一章中，你将使用 AWS 原生服务来分析点击流数据。 点击流数据是在用户访问网站和应用时收集的。 理解这些数据可以帮助应用拥有者更好地根据目标用户调整内容。 在本章结束时，你将能够轻松查询、转换和可视化多种格式的数据。 。
第九章， 探索未来工作，解释了在 AWS 中，你可以使用超过 200 种服务来为应用提供支持。 与前几章不同，前几章提供了逐步指导来构建应用，而这一章则概述了 AWS 所提供的服务以及加速和支持你的项目创意的策略。 这一章不是实践性的，而是具有启发性的；用它来为你的下一个 大项目进行头脑风暴。
为了充分利用本书内容
你需要一个 AWS 账号才能跟着做。 如果你还没有 AWS 账号，可以按照以下 说明创建一个： https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-creating.html。
你还需要在本地机器上安装以下软件。 。
| 本书中涵盖的软件/硬件 内容 | 操作系统要求 |
|---|---|
| AWS CLI 版本 2 | Windows、macOS 或 Linux |
| Terraform 1.9.1 | |
| Node.js v18.12.0 | |
| npm 1.9.1 |
尽管示例已在这些版本中进行了测试，但它们也应能在任何更新版本中正常运行。
如果您使用的是本书的数字版，我们建议您自己输入代码或从本书的 GitHub 仓库访问代码（每个章节中都有链接）。 这样做将帮助您避免与复制和粘贴相关的潜在错误。 代码粘贴时可能会出现的错误。
下载示例代码文件
您可以从 GitHub 下载本书的示例代码文件，地址为 https://github.com/PacktPublishing/AWS-Cloud-Projects。如果代码有更新，GitHub 仓库中的代码会及时更新。
我们还有其他代码包，来自我们丰富的图书和视频目录，可通过以下链接获取： https://github.com/PacktPublishing/。快来看看吧！
使用的约定
本书中使用了一些文本约定。
<st c="6918">文本中的代码</st>：表示文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名。 以下是一个示例：“如果您在使用 React 和 i18n，您需要创建 <st c="7163">translation.json</st> 文件”
一段代码块的格式如下： 如下所示：
def lambda_handler(event, context):
…
response = bot.recognize_text(
botId = '${MeetyBot}',
botAliasId='TSTALIASID',
localeId='en_US',
sessionId='your_session_id',
text = user_input
)
…
任何命令行输入或输出的写法如下： 如下所示：
$ npm install && npm run build
粗体：表示新术语、重要单词或屏幕上显示的单词。 例如，菜单或对话框中的文字会以 粗体显示。以下是一个示例：“在 前提条件 – 准备模板 部分，选择 选择一个 现有模板。”
提示或重要备注
显示如下：
联系我们
我们欢迎来自读者的反馈 ，一直以来都非常欢迎。
一般反馈：如果您对本书的任何部分有疑问，请通过电子邮件联系我们 customercare@packtpub.com 并在邮件的主题中提及书名。
勘误：虽然我们已尽最大努力确保内容的准确性，但仍可能出现错误。 如果您在本书中发现了错误，我们将非常感激您向我们报告。 请访问 www.packtpub.com/support/errata 并填写 表格。
盗版：如果你在网上遇到任何非法复制的我们的作品，任何形式的，请提供给我们相关的位置地址或网站名称，我们将不胜感激。 请通过 copyright@packt.com 与我们联系，并提供该材料的链接。
如果你有兴趣成为作者：如果你在某个领域拥有专长，并且有兴趣写书或为书籍做贡献，请 访问 authors.packtpub.com。
分享你的想法
阅读完 AWS 云项目后，我们很想听听你的想法！ 请 点击这里直接进入亚马逊的书评页面 并分享 你的反馈。
你的评价对我们以及技术社区非常重要，它将帮助我们确保提供优质的 内容。
下载本书的免费 PDF 副本
感谢购买 本书！
你喜欢在旅途中阅读，但又不能随时携带纸质书籍吗？
你的电子书购买无法与选择的设备兼容吗？
别担心，现在购买每本 Packt 书籍，你将获得免费的 DRM 无保护 PDF 版本 ，无需额外费用。
随时随地，任何设备上阅读。 直接从你最喜欢的技术书籍中搜索、复制并粘贴代码到 你的应用程序中。
福利还不止这些，你可以获得专属的折扣、新闻通讯以及每天发送到你 邮箱的精彩免费内容。
按照这些简单步骤来获取 福利：
- 扫描二维码或访问下面的 链接
https://packt.link/free-ebook/9781835889282
-
提交你的购买证明 凭证
-
就是这样！ 我们会直接将免费的 PDF 和其他福利发送到你的 邮箱
第一部分：初学者级别的项目
在 第一部分 本书中，您将学习如何使用 AWS 控制台、AWS CLI 和 Terraform 与 AWS 服务进行交互。 接着，您将按照一步步的方式构建一个由 S3 和 CloudFront 提供支持的简单 Web 应用程序。 这些是入门级项目，但它们将帮助您开始自主构建自己的 Web 应用程序。
本部分包括以下章节： 章节：
-
第一章， 部署和与 AWS 服务进行交互
-
第二章， 创建个人网站
第二章：1
部署和与 AWS 服务交互
开始构建解决方案的旅程 在 亚马逊 Web 服务 (AWS)平台上，需要全面了解可用的工具和方法。 本章介绍了在 AWS 上架构设计的多种方法，从需求收集、服务选择开始， 到绘制架构图。
接下来，你将探索可用于部署和与 AWS 服务交互的各种方法和工具，包括 AWS 控制台、AWS 命令行界面 (CLI)，AWS 软件开发工具包 (SDK)，以及 基础设施即代码 （IaC）。
这是一个理论章节，围绕以下 主要主题结构：
-
架构设计 在 AWS 上
-
开始使用 AWS 控制台
-
导航 AWS CLI 和 SDK
-
理解 IaC
在本章结束时，你将掌握创建、操作和监控 AWS 服务的知识和技能，能够根据你的需求和偏好，选择最合适的方法进行操作，无论是通过用户友好的 AWS 控制台、CLI、通过 SDK 的编程访问，还是强大的 IaC 工具。
技术要求
虽然这是一个理论章节，但你将在本章的 GitHub 仓库中找到代码片段 ，链接如下： https://github.com/PacktPublishing/AWS-Cloud-Projects/tree/main/chapter1/code。
要跟随学习，你需要一个 AWS 账户。
在 AWS 上架构设计
在 AWS 上架构设计是指 使用 AWS 设计和规划基于云的解决方案的过程。 这包括理解各种 AWS 服务、它们的功能，以及如何将它们结合起来构建可扩展、安全且 具有成本效益的架构。
在 AWS 上架构设计时，应考虑以下四个方面，每个方面将在 本章后续部分详细介绍：
-
需求收集：这是在 AWS 上架构解决方案过程中的一个关键步骤。 它涉及了解业务需求、功能需求、非功能需求以及将在设计和实现 AWS 架构时起到决定性作用的约束条件。 AWS 架构的设计。
-
架构模式：AWS 提供了多种架构模式和参考架构，作为常见用例（如 Web 应用、数据处理管道或无服务器架构）的起点。 你可以利用这些模式并根据特定需求对其进行定制。
-
服务选择：AWS 提供了广泛的服务，包括计算、存储、数据库、网络、分析、机器学习等。 你必须仔细评估应用程序的需求，并选择最适合这些需求的 AWS 服务。
-
绘图：创建拟议架构的可视化表示是架构过程中的一个关键步骤。 AWS 没有官方工具，但 draw.io 或者仅仅使用 Microsoft PowerPoint 都可以用来创建架构图，这有助于沟通设计、促进协作 并推动实施。 。
让我们详细了解这些方面 。
需求收集
明确且定义良好的 需求对架构师设计符合组织特定需求并实现预期结果的 AWS 解决方案至关重要。 需求收集可能涉及与利益相关者的协作、开展研讨会、分析现有系统和数据、以及理解 业务背景。
然而，如果你的项目范围较小，并非所有这些步骤都适用。 尽管如此，在项目开始之前，了解可以收集到的需求类型是很重要的：
-
业务需求：第一步是理解解决方案背后的业务目标、目标和驱动因素。 这包括目标市场、预期增长、收入模型以及需要考虑的任何特定业务约束或法规。
-
功能要求：这些要求定义了解决方案必须提供的具体功能、特性和能力。 这可能包括与用户界面、数据处理、与现有系统的集成或特定 业务逻辑相关的要求。
-
非功能性要求：非功能性要求定义了解决方案必须具备的定性特征，如性能、可扩展性、可用性、安全性和合规性。 这些要求通常在确定适当的 AWS 服务和架构模式时至关重要， 以便使用。
-
技术要求：技术要求涵盖了需要使用或与 AWS 解决方案集成的具体技术、编程语言、框架和工具。 这可能包括对特定数据库、消息系统或 第三方服务的要求。
-
数据要求：在 AWS 架构设计中，理解数据要求至关重要。 这包括数据类型（结构化、非结构化或半结构化）、数据量、数据源、数据处理需求，以及任何特定的数据治理或 合规性要求。
-
集成要求：如果 AWS 解决方案需要与现有的本地系统、第三方服务或其他云环境进行集成，则必须明确定义集成要求。 这包括识别集成点、数据格式、协议和 安全性考虑事项。
-
安全性和合规性要求：根据行业和所处理数据的性质，可能会有需要在 AWS 架构中解决的特定安全性和合规性要求。 这些可能包括监管标准、数据保护法或 行业特定认证。
-
财务要求：AWS 提供按需付费定价模式。 了解预算限制和成本要求对于选择合适的 AWS 服务和实现 具有成本效益的架构至关重要。
请记住，一些人将成本或安全性要求视为功能性和非功能性要求的一个范畴。 不要拘泥于命名；只需收集所有 要求。
选择架构模式
架构模式 和参考架构作为设计和实施基于云的解决方案的起点。 这些模式封装了最佳实践、经过验证的设计和根据特定用例和需求量身定制的架构原则。 你可以在 AWS 架构中心 找到许多这样的模式： https://aws.amazon.com/architecture。
通过利用 AWS 架构模式和参考架构，你可以在经过验证的设计基础上构建，加速开发过程，并确保你的解决方案符合 AWS 最佳实践和 行业标准。
架构模式解决了常见的场景和需求。 这些包括用于 Web 应用程序、数据处理管道、无服务器架构、微服务、事件驱动架构等的模式。 你可以利用这些模式作为基础，并根据 具体需求进行定制。
除了通用模式外，AWS 还提供了针对特定领域和行业的参考架构，如电子商务、媒体和娱乐、医疗保健、金融服务等。 这些参考架构提供了关于如何使用 AWS 服务和针对 这些领域的最佳实践设计和实施解决方案的详细指导。
要选择一种模式或架构，必须仔细评估解决方案的需求、限制和用例，以选择最合适的架构。 这一选择过程涉及理解每种模式的优缺点、权衡取舍，以及它们与其他技术栈的兼容性。 这通常会在 它们的描述中详细说明。
虽然架构模式提供了一个坚实的起点，但它们很少被照搬使用。 你必须根据具体需求定制和调整这些模式，集成额外的 AWS 服务，调整配置，并考虑安全性、监控和 运营问题。
也有可能你需要的是一个混合或多模式架构。 有些解决方案需要结合多个架构模式，或者采用一种混合方法，结合不同模式的组件。 在有效地集成和协调不同模式为一个统一且可扩展的架构时，存在额外的挑战。 这是一个高级话题，你将在本书的后续章节中进一步了解。 本书。
选择服务
到目前为止，你已经有了一个 明确定义的问题和一个通用的架构模式。 下一步是选择服务。 这是在 AWS 中架构解决方案的一个关键环节。 AWS 提供了超过 200 种服务，拥有大量可以组合的构建模块，用以创建可扩展、安全且 具有成本效益的架构。
服务选择是一个迭代过程，需要在架构最佳实践和各种需求（如非功能性、功能性、成本、安全性等）之间进行平衡。 随着解决方案的发展，新的需求或 约束条件的出现，你必须不断评估和优化服务选择。
服务选择的第一步是将收集到的需求映射到可用的 AWS 服务。 这需要了解每个服务的能力和使用案例，并识别出能够满足解决方案特定功能性、非功能性和技术需求的服务。 为了进行这种映射，你需要首先了解你应该查看的服务类别。 服务被组织为不同的类别，例如计算、存储、数据库、网络、安全、分析等。 在本书的后续章节中，你将看到这些类别中的不同服务。
在确定了符合你需求的服务类别之后，你需要评估不同服务的能力。 每个 AWS 服务都提供一套独特的能力和功能。 例如，如果解决方案需要一个高度可用且可扩展的数据库，像 Amazon RDS 或 Amazon Aurora 这样的服务可能是合适的选择。 随着你在 本书的学习深入， 这一点会变得更加明确。
一些有趣的非功能性能力，你应该考虑的如下： 如下所示：
-
服务集成：AWS 服务设计上能够无缝协作。 你应该考虑不同服务之间的集成点，并确保所选服务能够有效集成，从而提供 所需的功能。
-
托管服务与自托管服务：AWS 提供托管服务（由 AWS 处理底层基础设施和维护）和自托管服务（客户有更多控制权，但也承担更多责任）。 您必须根据运营开销、成本以及合规要求等因素评估这两种服务类型之间的权衡。
-
定价与成本优化：AWS 服务有不同的定价模型，您需要考虑其服务选择的成本影响。 应评估并将成本优化策略（例如利用预留实例、竞价实例或自动扩展）纳入架构设计中。
-
发展路线图：AWS 服务在不断发展，新的功能和服务会定期发布。 您应考虑所选服务的未来路线图，并确保架构能够适应潜在的变化或新的服务提供。
重要提示
您知道并非所有 AWS 服务在所有地区都可用吗？ 没错。 AWS 服务在所有 AWS 地区并非都能统一提供。 因此，您还必须考虑您计划使用的服务的区域可用性。
有时，您可能找不到适合您需求的 AWS 服务，这也是正常的。 这时，第三方服务就显得尤为重要。 如果第三方工具符合您的需求，不要害怕使用它。 不过，请考虑之前提到的各个维度，如成本或服务集成。
架构图绘制
提议架构的可视化表示 有助于传达设计，促进团队成员之间的协作，并确保对解决方案的组件及其相互关系有共同的理解。 它还提供了实施的地图。
目前没有标准工具用于绘制 AWS 解决方案的架构图。 最常用的工具是使用 AWS 架构图标的 PowerPoint（https://aws.amazon.com/architecture/icons/）或 draw.io（https://app.diagrams.net）。 这些工具包括代表不同 AWS 服务的图标和形状。
图 1**.1 展示了一个使用 PowerPoint 绘制的高层次图，展示了两个不同区域 EC2 实例之间的通信流程。
图 1.1 – 跨区域 EC2 通信流程
图示作为一种通用语言，用于与利益相关者、开发人员、运维团队以及其他相关方沟通架构设计。 你不仅应该表示各种 AWS 服务，还要展示它们之间的关系，以及解决方案中数据和流程的整体流动。 你可以为同一个解决方案创建多个图示，每个图示可以有不同的细节层次。
重要提示
在设计阶段，图示工作并没有结束。 相反，它是架构生命周期中的一个持续过程。 定期更新和审查图示，确保它们准确反映当前的架构状态。
图示是架构文档过程中不可或缺的一部分。 它们作为设计决策、组件交互和所选架构背后理由的参考。 然而，文档并不限于图示。 创建详尽的文档对于未来的维护、故障排除以及团队或组织内的知识传承具有不可估量的价值。 本书不会深入讨论文档内容，因为这是一本专注于 实践构建的书籍。
探索 AWS Well-Architected 框架
AWS 提供了一套最佳 实践和设计原则，统称为 Well-Architected 框架 (WAR)，(https://aws.amazon.com/architecture/well-architected/)。 该框架涵盖六个支柱：运营卓越、安全性、可靠性、性能效率、成本优化， 以及可持续性。
云架构师使用该框架来确保他们的解决方案符合 AWS 最佳实践，通常是在解决方案构建完成后，但也可以在设计阶段使用。 尽管 WAR 可以单独作为一章来讲解，我们现在只是希望你了解它，并且看到我们在本书中的项目构建过程中如何引用它。
现在我们已经涵盖了设计和规划阶段，让我们深入探讨实施阶段。 在这个过程中，你将探索多个工具，并获得一些 实践经验。
开始使用 AWS 控制台
AWS 控制台是 AWS 提供的基于 Web 的用户界面，允许用户通过 图形用户 界面 (GUI)来访问和管理各种 AWS 服务和资源。
AWS 控制台旨在用户友好，并且可以通过任何 Web 浏览器访问，允许用户从任何有网络连接的地方管理其 AWS 资源。 它提供了 AWS 服务和资源的可视化展示，使得用户更容易理解和与 AWS 生态系统互动。
使用控制台
在本节中，你将 部署一个 EC2 实例，这是 AWS 的 虚拟机。
要使用控制台，你必须拥有一个 AWS 账户。 AWS 账户的创建过程不在本书的范围内，但你可以在 AWS 网站上找到所有必要的信息，网址为 https://aws.amazon.com/free。
重要提示
本书中的每个示例都假设你拥有一个独立的 AWS 账户，该账户不属于 AWS 组织。
让我们开始吧： 让我们开始：
-
访问 AWS 控制台的第一步是导航 到 https://console.aws.amazon.com/。
你将看到一个登录界面，如 图 1**.2所示。
图 1.2 – AWS 控制台登录界面
-
如果你使用的是 根用户，请输入你的用户邮箱和密码。 如果你使用的是 IAM 用户，你还需要输入 12 位数字的 账户 ID。
-
成功登录后，你将看到 AWS 控制台主页，如 图 1**.3所示。
图 1.3 – 控制台主页
本图需要重点强调的部分如下：
-
顶部的搜索栏，你可以用它来搜索特定的服务。
-
当前管理的 AWS 区域显示在右上角；在这种情况下是北弗吉尼亚。
-
当前登录的用户或角色，位于右上角，隐藏在红色框下。
-
最近访问的部分，如果你之前没有打开过 AWS 控制台，它将是空的。
重要说明
为什么角色和账户 ID 会隐藏在图 1.3中的红色框下？尽管 AWS 账户 ID、用户和角色不被认为是敏感信息，但按照 AWS 最佳实践，公开披露这些信息是不推荐的。
- 导航到 EC2 服务控制台。为此，在搜索栏中输入
ec2，然后选择EC2，如图 1.4所示。
图 1.4 – 使用 AWS 控制台搜索 EC2 服务
- 要启动最简单的虚拟机，且不进行任何自定义，请选择启动实例，如图 1.5所示。
图 1.5 – EC2 仪表板
-
在以下菜单中，选择启动一个实例，然后选择继续无密钥对（不推荐），从密钥对名称下拉菜单中选择。最后，再次选择启动实例，这次是在右侧菜单中。
-
导航到正在运行的实例。你可以通过选择 EC2 左侧菜单中的“实例”来完成，或者直接访问
console.aws.amazon.com/ec2/#Instances。你应该会看到类似于图 1.6的内容：一个正在运行的 EC2 实例，带有一个奇怪的实例 ID 和一些其他属性。
图 1.6 – EC2 实例状态
这是一个不太实用的实例，因为你无法连接到它。 原因是你没有选择密钥对。 这只是一个简单的演示，展示了 AWS 控制台的工作方式。
- 你可以通过选择 终止（删除）实例来终止该实例，如 图 1**.7所示。
图 1.7 – 使用 AWS 控制台终止 EC2 实例
虽然 AWS 控制台是一个方便的管理和排除故障的方式，但你可能已经猜到它的一些缺点。 假设你需要创建一百个，甚至一千个这样的 EC2 实例。 这将需要你花费很长时间，特别是如果你需要配置一些特定的参数，比如你在 上一篇指南中跳过的那些。
AWS 提供了 命令行工具和 SDK，用于程序化访问和自动化 AWS 服务，以解决 这些缺点。
重要提示
不建议使用根凭证在你的 AWS 账户中执行操作。 我们强烈建议你不要将根用户用于日常任务，并遵循适用于 AWS 账户的根用户最佳实践，详细信息可以在 此处找到： https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html。
建议在进入下一节之前，你先多浏览一下 AWS 控制台，熟悉一下它。
导航 AWS CLI 和 AWS SDK
AWS CLI 和 AWS SDK 是用于访问和管理 AWS 服务的编程工具。 在本节中，你将更深入地了解这些工具，并在自己的 环境中执行它们。
AWS CLI
AWS CLI 是 AWS 提供的一个 统一工具，允许你通过命令行与 AWS 服务进行交互和管理，支持 macOS 终端或 Windows 命令提示符等环境。 它提供了一种方便且可编程的方式，帮助自动化和控制各种 AWS 资源 和操作。
它是一个 CLI 工具，因此需要进行安装。 不同操作系统的安装过程有所不同，但 AWS 有详细的文档说明（https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html）。 除了独立操作外，它还可以与其他 CLI 脚本或现有的自动化工具集成。 例如，一个涉及多个组件的较大工作流，涉及本地和 远程进程。
使用 AWS CLI
在本节中，你将 像上一节一样创建一个 EC2 实例，这次使用 AWS CLI。
认证与 AWS 控制台的工作方式不同。 AWS CLI 支持多种认证方法，包括 AWS 访问密钥、IAM 角色和外部凭证提供者。 你可以在 AWS 网站上查看有关不同类型安全凭证的所有详细信息： https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds.html。
在本节中，我们将重点讲解 AWS 访问密钥。
如果你使用的是根用户或 IAM 用户，默认情况下，你的用户没有启用访问密钥。 不建议使用根用户。 不过，你可以为其创建访问密钥。 该过程在 AWS 网站上有描述： https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user_manage_add-key.html。
按照以下步骤创建新的 IAM 用户：
-
通过 控制台导航至 IAM（https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/users）。
-
选择 创建用户，并为其指定用户名。
-
在 设置权限 菜单中，选择 直接附加策略，然后找到并选择 PowerUserAccess。最后， 点击 下一步。
-
点击 创建用户。
你的用户现在应该出现在用户列表中。 要为此用户创建访问密钥，请按 以下步骤：
-
选择你新 创建的用户。
-
导航到 安全凭证 标签页，选择 创建 访问密钥。
-
在 使用场景 菜单中，选择 命令行界面（CLI），接受确认消息，然后 选择 下一步。
-
在下一个菜单中，点击 创建 访问密钥。
-
在离开此页面之前，请记下你的访问和秘密 访问密钥。
AWS 还为所有可能的排列过程提供了详细的文档， 可以在他们的官方网站上查看：
-
创建一个 IAM 用户： https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console
-
管理 IAM 用户的访问密钥： https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html
打开你偏好的本地 CLI 工具，并使用你自己的密钥设置以下变量。 这将允许你的终端与 AWS 账户进行交互：
$ export AWS_ACCESS_KEY_ID=XXXXXXXXX
$ export AWS_SECRET_ACCESS_KEY=xxxxxxxxxx
$ export AWS_DEFAULT_REGION=<st c="24521">us-east-1</st>. We recommend that you run all the following examples in this region. If you are using a different region, some parameters, such as the <st c="24667">Amazon Machine Image</st> (<st c="24689">AMI</st>), require modifications.
<st c="24718">Try the following command; it returns your running instances.</st> <st c="24781">If you don’t have any, it will</st> <st c="24812">be empty:</st>
$ aws ec2 describe-instances
<st c="24850">To create the simplest possible instance, run the following command.</st> <st c="24920">This command creates an EC2 of the smallest instance type,</st> `<st c="24979">t2.micro</st>`<st c="24987">, using that AMI ID, which effectively means Amazon Linux 2023\.</st> <st c="25051">There will be more on AMIs in</st> *<st c="25081">Chapter 3</st>*<st c="25090">:</st>
$ aws ec2 run-instances --image-id ami-0c101f26f147fa7fd
–instance-type t2.micro
<st c="25174">Your command output should be similar to the following.</st> <st c="25231">Bear in mind that part of the output was</st> <st c="25272">omitted, but check whether your</st> `<st c="25304">ImageId</st>` <st c="25311">and</st> `<st c="25316">InstanceType</st>` <st c="25328">match:</st>
{
"Groups": [],
"Instances": [
{
"AmiLaunchIndex": 0, <st c="25390">"ImageId": "ami-0c101f26f147fa7fd",</st> "InstanceId": "i-0a65cf3ecaec728a8", <st c="25463">"InstanceType": "t2.micro",</st> "LaunchTime": "2024-03-24T10:47:25+00:00",
"Monitoring": {
"State": "disabled"
},
"Placement": {
"AvailabilityZone": "us-east-1a",
"GroupName": "",
"Tenancy": "default"
},
"PrivateDnsName": "ip-172-31-38-84.ec2.internal",
###OUTPUT OMMITED###
<st c="25733">If you run the previous</st> `<st c="25758">describe</st>` <st c="25766">command again, this time, the output will show your running instance.</st> <st c="25837">Try it with the following filter, which only shows</st> `<st c="25888">t2.micro</st>`<st c="25896">-sized instances:</st>
$ aws ec2 describe-instances –filters "Name=instance-type,
值=t2.micro" --query “Reservations[].Instances[].InstanceId”
[
"i-0a65cf3ecaec728a8"
]
<st c="26065">To terminate the instance, run the following command.</st> <st c="26120">Replace the instance ID with</st> <st c="26149">your own:</st>
$ aws ec2 terminate-instances describe 命令再次执行以确保实例不再运行。
<st c="26310">探索 AWS CLI</st>
<st c="26332">进一步探索</st> <st c="26345">AWS CLI。</st> <st c="26374">每个服务的语法都是一样的：</st> <st c="26401">每个服务：</st>
$ aws <command> <subcommand> [options and parameters]
<st c="26469">以下是这些</st> <st c="26496">命令的含义：</st>
+ <st c="26510">对</st> `<st c="26532">aws</st>` <st c="26535">程序的基础调用。</st>
+ <st c="26544">顶级</st> `<st c="26559">命令</st>` <st c="26566">通常对应于由</st> <st c="26624">AWS CLI 支持的 AWS 服务。</st>
+ <st c="26632">该</st> `<st c="26637">子命令</st>` <st c="26647">指定要执行的操作。</st>
<st c="26685">重要提示</st>
<st c="26700">你创建了一个具有</st> `<st c="26730">PowerUserAccess</st>` <st c="26745">权限的 IAM 用户。</st> <st c="26759">这授予对 AWS 服务和资源的完全访问权限，但不允许管理用户或组。</st> <st c="26868">在生产环境中，你可以将用户访问权限范围缩小到更窄的一组</st> <st c="26947">权限。</st>
<st c="26962">AWS CLI 的一个方便功能是</st> `<st c="26997">帮助</st>` <st c="27001">功能。</st> <st c="27011">你可以使用它获得任何命令的帮助。</st> <st c="27057">为此，只需在命令名称的末尾键入</st> `<st c="27079">help</st>` <st c="27083">。</st> <st c="27114">执行以下命令。</st> <st c="27146">结果将是对这些命令所有可用选项的详细描述：</st>
$ aws ec2 help
$ aws ec2 describe-instances help
<st c="27285">如果逐命令浏览不是你的方式，你也可以在 AWS CLI 命令参考中找到每个</st> <st c="27384">服务的具体语法（</st>[<st c="27423">https://docs.aws.amazon.com/cli/latest/</st>](https://docs.aws.amazon.com/cli/latest/)<st c="27463">），但你将在</st> <st c="27510">接下来的章节中看到并使用更多。</st>
<st c="27529">AWS SDK</st>
<st c="27537">AWS SDK 是一个</st> <st c="27556">开源库的集合，提供来自多种编程语言的程序化访问 AWS 服务，包括 Java、Python、Node.js、.NET、Ruby、Go、PHP 等。</st> <st c="27743">这些 SDK 使开发者能够构建与 AWS 资源和服务直接交互的应用程序，而无需使用低级的 AWS</st> <st c="27884">服务 API。</st>
<st c="27897">AWS SDK 抽象了向 AWS 服务发出认证 HTTP/HTTPS 请求的复杂性，处理重试和错误处理，并解析来自 AWS 服务的响应。</st> <st c="28085">它们提供了一个更高级的、特定语言的接口，使开发者更容易将 AWS 服务集成到</st> <st c="28209">他们的应用程序中。</st>
<st c="28228">这些被认为是高级概念，你在本书中不会看到太多。</st> <st c="28312">它更常被应用开发人员使用。</st> <st c="28361">如果你有兴趣了解使用 Python SDK 创建 EC2 实例的语法，可以在</st> *<st c="28488">学习基础</st>* <st c="28504">部分找到</st> <st c="28513">，链接地址为</st> [<st c="28516">https://docs.aws.amazon.com/code-library/latest/ug/python_3_ec2_code_examples.html</st>](https://docs.aws.amazon.com/code-library/latest/ug/python_3_ec2_code_examples.html)<st c="28598">。</st>
<st c="28599">从使用控制台的手动操作到半自动化的操作，如 AWS CLI，你尚未</st> <st c="28697">见识到自动化的全部潜力。</st> <st c="28741">在接下来的章节中，你将学习如何通过 IaC</st> <st c="28807">来扩展你的部署。</st>
<st c="28816">理解 IaC</st>
<st c="28834">IaC（基础设施即代码）是一种方法</st> <st c="28854">用于配置和管理如云基础设施等资源。</st> <st c="28918">它允许你使用人类可读的定义文件</st> <st c="29006">或代码来定义和部署你的资源。</st>
<st c="29014">与之前章节中手动通过 AWS 控制台或 CLI 工具配置资源不同，IaC 允许声明性地指定所需的基础设施状态。</st> <st c="29203">在我们的上下文中，这指的是 AWS 云。</st> <st c="29241">这意味着计算实例、存储、网络、安全组以及其他</st> <st c="29319">AWS 服务。</st>
<st c="29332">通过运用 IaC，你将获得</st> <st c="29368">多个好处：</st>
+ **<st c="29386">配置一致性</st>**<st c="29412">：IaC</st> <st c="29419">推动了不可变基础设施的概念，即将基础设施组件视为一次性和可替换的，而不是手动修改。</st> <st c="29582">这种方法确保了一致性，减少了配置漂移，并简化了扩展或</st> <st c="29687">更新基础设施的过程。</st>
+ **<st c="29711">版本控制和协作</st>**<st c="29745">：IaC 模板和代码可以存储在 Git 等版本控制系统中，支持协作、代码审查和跟踪基础设施定义的变化。</st> <st c="29922">这促进了基础设施管理的最佳实践，并便于团队间的知识共享。</st> <st c="30014">。
+ **<st c="30026">自动化部署</st>**<st c="30048">：IaC 模板和代码可以与</st> **<st c="30097">持续集成和持续部署</st>** <st c="30145">(</st>**<st c="30147">CI/CD</st>**<st c="30152">) 流水线集成，从而实现</st> <st c="30175">自动化部署和更新。</st> <st c="30210">这减少了手动工作，最小化了人为错误，并确保在不同环境（例如开发、预生产、</st> <st c="30371">和生产）之间的一致性和可重复部署。</st>
+ **<st c="30387">基础设施测试和验证</st>**<st c="30425">：IaC 模板和代码可以在部署之前进行测试和验证，确保定义的基础设施符合期望的规格，并遵守组织的政策和</st> <st c="30615">最佳实践。</st>
+ **<st c="30630">成本优化和资源管理</st>**<st c="30672">：通过将基础设施视为代码，组织可以更轻松地跟踪和管理其 AWS 资源，从而实现更好的成本优化和资源利用策略。</st> <st c="30850">你将不再忘记</st> <st c="30876">某个虚拟机</st> <st c="30901">正在某个地方运行。</st>
<st c="30919">有多种 IaC 工具。</st> <st c="30950">AWS 提供了自己的原生 IaC 工具，例如 AWS CloudFormation，允许用户使用 JSON 或 YAML 模板定义基础设施资源。</st> <st c="31106">它还提供了</st> <st c="31127">AWS</st> **<st c="31131">云开发工具包</st>** <st c="31152">(</st>**<st c="31154">CDK</st>**<st c="31157">)。</st> <st c="31161">这与 AWS SDK 不同，后者提供了一个比 CloudFormation 更高层次的抽象，允许开发人员使用熟悉的编程语言（如 TypeScript、Python、Java、</st> <st c="31379">和 C#）定义 AWS 构件。</st>
<st c="31386">除了 AWS 原生工具外，还有许多第三方 IaC 解决方案，例如</st> **<st c="31471">Terraform</st>**<st c="31480">。Terraform</st> <st c="31491">是云中立的；它支持多种云服务提供商，包括 AWS，并提供一致的工作流程，以便在多个平台上管理基础设施。</st> <st c="31661">它是最著名的</st> <st c="31694">IaC 工具之一。</st>
<st c="31704">选择 IaC 工具</st> <st c="31726">归结为个人偏好、现有技能和每个工具可以提供的特定功能。</st> <st c="31821">在本书中，你将通过实践操作 CloudFormation 和 Terraform。</st> <st c="31903">然而，如果你对这个话题感兴趣，AWS 提供了关于如何选择 IaC 工具的指导</st> <st c="32011">，可以参考</st> [<st c="32014">https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/introduction.html</st>](https://docs.aws.amazon.com/prescriptive-guidance/latest/choose-iac-tool/introduction.html)<st c="32104">。</st>
<st c="32105">使用 CloudFormation</st>
在这一部分，你<st c="32147">将使用 CloudFormation 创建一个 EC2 实例。</st> <st c="32198">这是一个入门部分，不会深入探讨所有 CloudFormation 的语法</st> <st c="32281">和功能。</st>
要开始，按照以下步骤操作：</st>
1. 在你的本地环境中创建以下文件；这是一个 YAML 模板，用于创建一个指定 AMI 和 `<st c="32458">t2.micro</st>` <st c="32466">大小的 EC2 实例：</st>
```
Resources:
NewEC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: "ami-0c101f26f147fa7fd"
InstanceType: "t2.micro"
```
注意 CloudFormation 在 YAML 格式中的可读性。</st> <st c="32655">这是它的一个优点。</st>
1. 通过 AWS 控制台导航到 CloudFormation，访问 [<st c="32738">https://us-east-1.console.aws.amazon.com/cloudformation</st>](https://us-east-1.console.aws.amazon.com/cloudformation) <st c="32793">并选择</st> **<st c="32805">创建堆栈</st>**<st c="32817">。</st>
1. 选择 `<st c="32884">ec2.yml</st>`<st c="32891">，然后</st> <st c="32897">选择</st> **<st c="32904">下一步</st>**<st c="32908">。</st>
1. 给<st c="32915">堆栈</st>起个名字。
1. 跳过所有选项并部署<st c="32973">堆栈。</st>
部署过程结束时，你的堆栈状态应该显示 `<st c="33152">us-east-1</st>` <st c="33161">区域。</st>
你可以通过导航到 EC2 服务来验证刚刚创建的 EC2 实例。<st c="33244">确认它具有正确的大小</st> <st c="33281">和 AMI。</st>
<st c="33289">如果你不完全理解整个过程，不用担心。</st> <st c="33351">CloudFormation 是一个独立的世界，具有特定的语法和功能。</st> <st c="33423">浏览你的堆栈详情，你将能够找到许多特性，例如它是什么时候创建的，谁创建的，创建了哪些资源以及顺序，甚至更多高级概念，如参数</st> <st c="33665">和输出。</st>
若要了解更多关于 CloudFormation 的信息，可以查看官方的 AWS</st> <st c="33739">文档：</st> [<st c="33754">https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html</st>](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)<st c="33829">。</st>
在继续之前，为了避免额外费用，不要忘记删除你的 EC2\。<st c="33922">要删除所有</st> <st c="33936">堆栈资源，请选择</st> <st c="33962">你的堆栈并</st> <st c="33977">点击</st> **<st c="33983">删除</st>**<st c="33989">。</st>
使用 Terraform
<st c="34006">你现在将创建</st> <st c="34027">另一个 EC2 实例，这次使用 Terraform。</st> <st c="34054">本节假设你已经按照上一节的</st> *<st c="34199">AWS</st>* *<st c="34203">CLI</st>* <st c="34206">部分配置好了终端和 AWS 凭证。</st>
<st c="34215">以下是如何</st> <st c="34230">操作：</st>
1. <st c="34236">在本地工作站的任意目录中创建一个文件，并命名为</st> `<st c="34308">ec2.tf</st>`<st c="34314">。</st>
1. <st c="34315">使用以下代码填充文件，它将创建一个最小实例类型的 EC2，</st> `<st c="34403">t2.micro</st>`<st c="34411">，位于</st> `<st c="34416">us-east-1</st>`<st c="34425">区域，使用相应的 AMI ID。</st> <st c="34445">这实际上意味着使用 Amazon</st> <st c="34481">Linux 2023：</st>
```
provider "aws"{
region = "us-east-1"
}
resource "aws_instance" "ec2" {
ami = "ami-0c101f26f147fa7fd"
instance_type = "t2.micro"
}
```
<st c="34622">请注意，</st> **<st c="34639">HashiCorp 配置语言</st>** <st c="34671">(</st>**<st c="34673">HCL</st>**<st c="34676">) 代码仍然是人类可读的，尽管</st> <st c="34716">可能比</st> <st c="34747">CloudFormation YAML</st> <st c="34747">稍微难以理解一些。</st>
<st c="34767">重要说明</st>
<st c="34782">AMI ID 在每个区域都是不同的。</st> <st c="34821">如果你使用的是与</st> `<st c="34862">us-east-1</st>`<st c="34871">不同的区域，并且你想使用 Amazon Linux 2023，你需要找到相应的</st> <st c="34952">AMI ID。</st>
1. <st c="34959">要执行 Terraform 代码，你需要先安装它。</st> <st c="35018">安装过程不在本书的范围内。</st> <st c="35069">不同操作系统的安装步骤不同，但它是一个简单的过程，你可以在 HashiCorp 的</st> <st c="35196">官方网站找到详细文档（</st>[<st c="35205">https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli</st>](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)<st c="35285">）。</st>
1. <st c="35288">安装完成后，在你创建了</st> `<st c="35393">ec2.tf</st>` <st c="35399">文件的同一目录下执行以下命令。</st> <st c="35406">它们将在你的环境中启动 Terraform</st> <st c="35450">并将你之前创建的模板应用到 AWS 账户中，从而有效地</st> <st c="35526">创建</st> <st c="35535">相关资源：</st>
```
$ terraform init
$ terraform apply
```
<st c="35584">系统将提示你进行确认。</st> <st c="35618">如果执行成功，它将显示如下</st> <st c="35683">简化输出：</st>
```
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# aws_instance.ec2 will be created
+ resource "aws_instance" "ec2" {
<st c="35964">+ ami = "ami-0c101f26f147fa7fd"</st>
<st c="35995">+ instance_type = "t2.micro</st>"
###OUTPUT OMMITED###
+ root_block_device {
+ delete_on_termination = (known after apply)
+ device_name = (known after apply)
+ encrypted = (known after apply)
+ iops = (known after apply)
+ kms_key_id = (known after apply)
+ tags = (known after apply)
+ tags_all = (known after apply)
+ throughput = (known after apply)
+ volume_id = (known after apply)
+ volume_size = (known after apply)
+ volume_type = (known after apply)
}
}
Plan: 1 to add, 0 to change, 0 to destroy. Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve.
<st c="36629">Enter a value: yes</st> aws_instance.ec2: Creating... aws_instance.ec2: Still creating... [10s elapsed]
aws_instance.ec2: Still creating... [20s elapsed]
aws_instance.ec2: Still creating... [30s elapsed]
aws_instance.ec2: Creation complete after 34s [id=i-0de732fda772c16cf] <st c="36899">Apply complete!</st> <st c="36915">Resources: 1 added, 0 changed, 0 destroyed.</st>
```
1. <st c="36958">你可以使用 AWS 控制台查看已创建的 EC2 实例。</st> <st c="37034">确保在正确的区域中查看。</st> <st c="37078">要删除所有资源，执行以下</st> <st c="37129">Terraform 命令：</st>
```
$ terraform destroy
```
<st c="37167">Terraform 提供了</st> <st c="37184">更多的功能，如</st> <st c="37217">使用</st> `<st c="37235">terraform plan</st>`<st c="37249">进行干运行，或者通过</st> `<st c="37303">terraform state list</st>`<st c="37323">可视化部署的资源。你可以在 Terraform 官方文档中了解更多这些内容</st> <st c="37395">，访问地址为</st> [<st c="37398">https://developer.hashicorp.com/terraform/cli/commands</st>](https://developer.hashicorp.com/terraform/cli/commands)<st c="37452">。</st>
<st c="37453">看看为什么 IaC 有用的实际示例。</st> <st c="37511">假设你需要创建 100 台这样的机器。</st> <st c="37565">你可以将之前的代码修改为</st> <st c="37602">以下内容：</st>
provider "aws"{
region = "us-east-1"
}
resource "aws_instance" "ec2" {
ami = "ami-0c101f26f147fa7fd"
instance_type = "t2.micro" <st c="37745">count = 100</st> }
<st c="37758">不要运行这个示例，因为它可能会产生高昂的费用。</st> <st c="37815">但是，注意与使用<st c="37858">AWS 控制台</st>执行相同任务相比，</st> <st c="37888">它是多么的简单。</st>
<st c="37900">总结</st>
在这一章中，你学习了在 AWS 上架构的含义。<st c="37908">它不仅仅是部署 AWS 服务，还包括收集不同类型的需求，将这些需求与已知模式和参考架构进行对比，选择不同的服务，并将<st c="37973">这些内容记录下来</st>。</st>
<st c="38191">你还探索了在设计完成后用于部署和交互 AWS 服务的各种方法和工具。</st> <st c="38326">AWS 控制台提供了一个用户友好的图形界面，而 AWS CLI 和 SDK 则提供了程序化访问和自动化功能。</st> <st c="38458">此外，你还接触了多种基础设施即代码（IaC）技术，如 Terraform、CloudFormation 和 AWS CDK，它们允许你通过代码定义和管理你的 AWS 基础设施。</st> <st c="38624">。</st>
<st c="38635">通过理解这些不同的方法，你可以根据自己的需求和技能水平以及 AWS 部署的复杂性，选择最合适的方法。</st> <st c="38819">无论你喜欢使用视觉界面、命令行工具、程序化访问还是 IaC，AWS 提供了一系列选项来满足你的需求并简化你的</st> <st c="38976">云操作。</st>
在下一章中，你将使用<st c="38993">AWS 控制台</st>构建个人网站。
第三章：2
创建个人网站
这是你实践经验的开始。 在接下来的章节中，你将沉浸在各种场景中。 在本章的第一个实践部分，你将从一份需求列表中，学习如何为你的简历建立个人网站。 在记住这些需求的基础上，你将通过 第一章 提供的方法，构建一个使用 AWS 服务（如 S3 用于存储和 CloudFront 用于分发）的解决方案。 进行架构设计。
接下来，你将使用 AWS 控制台构建该架构。
总之，本章涵盖了以下主要主题 ，顺序如下：
-
你将要构建的内容是——一个 个人网站
-
你将如何构建它——使用 S3 和 CloudFront
-
实际构建它——使用 AWS 控制台
-
如何改进解决方案——安全性 和 DNS
到本章结束时，你将能够自信地在 AWS 中创建并托管自己的静态网站。 这是更高级 Web 应用程序的前奏，你将在 接下来的章节中看到它们。
技术要求
为了创建你自己的个人网站，你需要访问一个 AWS 账户。
本章在本书的 GitHub 代码库中有一个专门的文件夹。 在这里，你将找到跟随本章学习所需的代码片段： https://github.com/PacktPublishing/AWS-Cloud-Projects/tree/main/chapter2/code。
场景
假设你是一个刚毕业的学生，或者是一个 希望向潜在雇主或客户展示自己技能、经验和成就的专业人士。 你希望创建一个既易于访问又具有专业外观的在线形象，在这里你可以分享你的简历 或履历。
有什么比托管你自己的 个人网站更好的方式呢？
需求
回想一下，在 第一章中，收集 需求是架构 AWS 的第一步。 无论你的场景有多简单或复杂，最好将需求写下来。 这可能听起来有些傻，但花时间描述你需要什么，以及你如何构建它，会在 长期内帮助你。
在这种具体情况下，你想要构建一个简单的东西。 你需要一个提供良好用户体验的网站。 你不希望招聘者看到页面加载缓慢，从而跳过你的页面直接去下一个候选人。 同样，你也不希望招聘者在你的网站不可用时尝试访问它。 为避免这种情况，你需要了解用户的 体验。
简历经常变动。 你可能会学习到新技能，换工作，或者其他原因影响你的简历。 因此，你需要一个简单的机制来更新网站。 最后，由于这是一个个人项目，你必须尽量将成本保持在最低 水平。
所有这些因素都可以转化为功能性和 非功能性需求。
功能性需求
功能性需求 定义了解决方案必须提供的具体特性、功能和能力。 在这种情况下，具体如下： 如以下所示：
-
能够创建、编辑和更新简历的内容，包括个人信息、教育背景、工作经历、技能， 和项目
-
支持非文本内容，如 图片
-
在任何浏览器上都可以访问， 通过互联网
-
能够 基于 网站数据生成洞察
非功能性需求
非功能性需求定义了解决方案必须提供的 定性属性。 在这种情况下，具体如下： 如以下所示：
-
低延迟 – 快速的页面 加载时间
-
高可用性 – 访问时可用 可用性
-
易于维护性 – 易于更新和修补 网站
-
低成本 – 便宜的 按需付费服务
现在，你已经有了个人网站的需求。 按照 第一章 的方法论，你现在需要检查已知的 公认模式。
架构模式
在 AWS 架构中心进行简单搜索（https://aws.amazon.com/architecture/）并未找到任何 参考架构图或示例代码。 然而，它返回了一个 YouTube 系列，其中有一集名为 基础回顾：在 AWS (https://www.youtube.com/watch?v=N0nhkyhaqyw&ab_channel=AmazonWebServices)。
观看它；这是一个很好的 起点。
在 AWS 云环境之外，理解什么是静态网站非常重要。 一个 静态网站 是一种内容已预先构建并作为静态文件（通常是 HTML、CSS 和 JavaScript 文件）提供给用户的网站类型。 静态网站不需要 服务器端处理。
动态网站，另一方面，基于用户请求和其他数据在服务器端生成内容。 你将在接下来的章节中看到并构建这些。
最简单的静态网站示例是将一个单一的 HTML 文件保存在本地桌面，并在浏览器中打开它。 这可以运行；然而，除了你自己之外，没人能访问它。 这就是为什么你需要一个托管平台来托管你的 静态网站。
在构建好 静态文件后，你将文件上传到托管平台，其他人便能通过该平台访问这些文件。 这就是 AWS 和解决方案架构的作用所在。 扮演着角色。
架构
到现在，你已经了解了什么是静态网站，明确了需求，并准备创建一个架构 图 解决方案。
有两种 可能的选项：
-
不带 特定服务的图
-
带有 特定服务的图
遵循正式的流程，您创建一个没有特定服务的图表。 之后，在选择服务时，您可以根据需求将这些不特定的服务与具体服务匹配并替换掉。
例如，您知道自己需要一个 内容分发网络（CDN），因此您应该表示该内容。 之后，如果 Amazon CloudFront 满足您的需求，将无关的 CDN 图标替换为 CloudFront 图标，并放入您的 架构图中。
然而，对于这个简单的场景，并在了解架构模式后，您可以直接跳到一个图表，图表中列出了 AWS 服务。
请记住，您需要一个地方来存储静态文件，并且需要一个机制来使 它们可用。
您的图表应当类似于 图 2**.1：一个三部分组成的图表，包含 Amazon S3、Amazon CloudFront 和 Amazon CloudWatch。 客户端通过 CloudFront 连接，它从 S3 中获取您网站的静态文件。 这两个服务都将指标 发送到 CloudWatch。
图 2.1 – AWS 上的静态网站架构
尽管 客户端以计算机图标表示，但它们也可以是其他类型的设备，如手机 或平板电脑。
AWS 服务
该架构仅使用了三个服务。 在这一 节中，您将了解这些服务的功能以及它们如何满足 您的需求。
Amazon 简单存储服务（S3）
Amazon S3 是一个 高度可扩展且耐用的对象存储服务。 S3 具有许多特点。 与我们使用案例相关的特点如下：
-
S3 是一种对象 存储服务，意味着它将数据存储为对象（文件），并将其存放在 桶（目录）中。
-
设计上具有高可用性，数据会在同一地区内的多个 AWS 可用区之间自动复制，确保即使发生停机或 组件故障，您的数据仍然可以访问。
-
完全托管的服务；您无需担心管理存储基础设施的操作开销，因为这一切都由 为您处理。
-
支持版本控制，可以在同一个存储桶中保存对象的多个变体，允许你保存、检索和恢复存储在 桶中的每个对象的每个版本。
-
高度具有成本效益的存储解决方案，采用按需计费定价和分级 存储类。
将这些陈述与 你的需求关联起来：
-
你希望存储文件（例如 HTML、CSS 和图像），并希望它们随时可供招聘人员访问。 S3 是 高度可用的。
-
你希望解决方案容易维护，无需进行操作系统补丁更新和其他繁琐的工作。 S3 是一项 完全托管的服务。
-
同样，你希望能够轻松更新你的简历，如果犯错，能够回滚到之前的版本。 S3 支持 文件版本控制。
-
最后，你需要以尽可能低的成本来实现这一点。 S3 提供免费层，只对实际使用量收费，且被认为是一个 具有成本效益的服务。
它符合所有条件，成为存储你 静态文件的理想服务。
你知道 S3 有原生功能可以作为静态网站托管吗？ 你可以在 AWS 网站上了解更多 信息，地址是 https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteHosting.html。
然而，它 有两个 主要的限制：
-
S3 是一项区域性服务，因此，网站可以通过该桶所在 AWS 区域的特定网站终端访问。
-
它不 支持 HTTPS。
这引出了下一个服务：CloudFront。 如果你想了解更多关于 S3 的信息，包括免费层的内容，可以阅读 相关文档 ，地址是 https://aws.amazon.com/pm/serv-s3。
Amazon CloudFront
Amazon CloudFront 是一项 加速分发静态和动态网页内容的服务，内容包括 <st c="9126">.html</st>， <st c="9133">.css</st>， <st c="9139">.js</st>和图像文件，传送给你的用户。 它是 Amazon 的 CDN。
CDN 是一个地理上分布的服务器群组，它将内容缓存到靠近最终用户的地方。 简而言之，它的工作方式是，用户在离他们更近的 CloudFront 位置终止连接，然后通过 Amazon 的高速骨干网络完成剩余的传输。 如果你的内容已经在该位置缓存，它会直接返回，而不需要传输到 源服务器。
其一些关键特性如下：
-
全球分布式：通过在靠近用户的边缘位置缓存静态内容，CloudFront 可以更快速地提供网站文件，从而提高加载速度，带来更好的用户体验。 这一点对互联网连接较慢或位于距离源 S3 存储桶较远地区的用户尤为有益。
-
高可用且容错：CloudFront 构建在 AWS 高可用且容错的基础设施之上。 边缘位置和基础服务都考虑了冗余和容错设计，最大限度地减少单个 组件故障的影响。
-
增强的弹性：CloudFront 支持为单个分发配置多个源服务器（例如，Amazon S3 存储桶或 Web 服务器）。 如果主要源服务器不可用，CloudFront 会自动切换到次级或三级源服务器，确保内容持续 交付。
-
内容交付优化：CloudFront 通过自动压缩文件、最小化数据传输量并支持高级缓存机制（如缓存控制头和查询 字符串转发），来优化静态内容的交付。 。
再次，将这些特性与 你的需求进行对比：
-
你需要一种通过互联网在任何设备上都能使用的分发机制。 你不知道用户会在哪里，或者他们可能使用什么类型的设备和带宽限制。 CloudFront 全球分布的特性和 开箱即用的缓存功能，可以让你受益。
-
S3 是高可用的，但你还需要 CDN 高可用。 当你将多个组件串联在一起时，任何一个组件的故障都会影响整个系统。 CloudFront 还通过使用次级源 或存储桶，进一步提高了你的可用性。
-
最后，成本是一个重要因素。 CloudFront 的定价模型基于传输的数据量和请求次数，并采用按需付费模式。 如果客户端的浏览器支持，CloudFront 会自动压缩你的文件，从而减少 数据传输。
如果你想了解更多关于 CloudFront 的信息，包括免费套餐包含的内容，可以在 AWS 文档中阅读： https://aws.amazon.com/cloudfront。
Amazon CloudWatch 指标
Amazon CloudWatch 实时监控你在 AWS 上运行的资源和应用程序。 你可以使用 CloudWatch 收集和追踪指标、日志、事件 和追踪信息。
CloudWatch 拥有许多功能，但在本项目中，我们将只关注 CloudWatch 指标。 CW 指标的一些关键特性如下： 以下是 一些特点：
-
全面覆盖：它收集来自多个 AWS 服务的指标，包括 Amazon S3 和 Amazon CloudFront，以及其他许多服务。 这种全面的覆盖使你能够从一个集中位置监控和分析整个 AWS 基础设施和应用程序的性能与健康状况。 集中管理。
-
警报和通知：它支持基于指标阈值或模式创建警报。 当特定条件满足时，这些警报可以触发通知（例如，电子邮件、短信或 AWS Lambda 函数），使你能够主动应对潜在问题或采取 自动化措施。
-
成本效益：其定价基于接收的指标数量、数据保存期限以及按需付费模式，使你能够随着 AWS 基础设施和应用程序的增长，扩展你的监控工作，而无需承担高额的 前期成本。
对于任何你部署的解决方案，你都需要进行监控。 这意味着你需要知道它是否正常工作，如果没有，你需要知道为什么没有。 即便这是一个简单的包含你简历的网站，你也想知道是否有人在访问它，以及他们的体验如何。 这将满足 根据网站 数据生成洞察的能力 的要求。
CloudWatch 深度集成进 AWS 生态系统。 它会原生显示 CloudFront 和 S3 指标，例如：请求次数、错误率和延迟。 你可以访问这些指标，同时最大限度降低成本。 如果没有访问量，你将 没有费用。
如果你想了解更多关于 CloudWatch 指标的信息，包括免费层包含的内容，可以阅读 AWS 文档： https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html。
编码解决方案
恭喜你，你已经设计了一个满足所有需求的架构。 现在是时候构建它了。 在本 章中，你将使用 AWS 控制台，在 北弗吉尼亚 区域构建它。
编辑网站
首先， 在本书的 Git 仓库中下载资源，网址为 https://github.com/PacktPublishing/AWS-Cloud-Projects。你可以通过工作站终端使用 Git 工具下载，或者直接下载 ZIP 文件形式的仓库。 如何使用 Git 和 GitHub 的详细步骤指南超出了本书的范围，但如果你想深入学习这个话题，可以参考本书*《精通 Git》*，它在 https://www.packtpub.com/product/mastering-git/9781783553754中全面讲解了相关内容。
你会在 <st c="14804">chapter2/code</st> 文件夹中找到三个文件。 在你喜欢的代码编辑器中打开 <st c="14831">index.html</st> 文件。 在那里，你会发现一个标准的 HTML 文件，头部引用了一些样式，HTML 正文包含多个分区，通过标签 <st c="15027">div</st>突出显示，并填充 着 简历信息：
<!DOCTYPE html>
<html>
<head>
<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Archivo+Narrow&family=Julius+Sans+One&family=Open+Sans&family=Source+Sans+Pro&display=swap" rel="stylesheet"> <st c="15492"><link rel="stylesheet" href="index.css"></st> </head>
<body>
<page size="A4"> <st c="15565"><div class="container"></st>
<st c="15588"><div class="leftPanel"></st> <img src="img/avatar.png"/>
<div class="details">
<div class="item bottomLineSeparator">
<h2>
CONTACT
</h2>
### OUTPUT OMMITED ###
如果您不熟悉 HTML，以下是 1,000 英尺的概述：HTML 文件是浏览器读取的文件，用于渲染网页。 它们由<st c="15890">.html</st> 或 <st c="15899">.htm</st> 扩展名表示。 HTML 文档由一系列元素组成，这些元素位于标签之间。 标签通过 <st c="16028"><></st> 符号来表示。 有开标签和闭标签；内容位于它们之间。 有些标签是定义明确的，例如 <st c="16147"><p></st>，表示 段落。 要表示一个段落，您可以这样做：
<st c="16228"><p></st>This is a paragraph in HTML<st c="16260"></p></st>
您可以在 w3school 网站上找到关于许多其他标签的文档 ，网址为 https://www.w3schools.com/tags/。
然而，如果仅使用纯 HTML，您的网站将不会具有良好的美学效果。 为了直观地展示这一点，请在浏览器中打开 <st c="16485">index.html</st> 文件。 如果您尚未修改它，它将看起来像是 图 2**.2。
图 2.2 – index.html 浏览器可视化
现在，在文本编辑器中打开它，并删除头部中的这些链接标签：
<link href="https://maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Archivo+Narrow&family=Julius+Sans+One&family=Open+Sans&family=Source+Sans+Pro&display=swap" rel="stylesheet">
<link rel="stylesheet" href="index.css">
刷新您的 浏览器页面。 现在，它将看起来像是 图 2**.3：
图 2.3 – 无样式的 index.html 浏览器可视化
希望你能看出其价值。 HTML 中的样式为元素添加样式，例如颜色、字体、大小等。 HTML 中的所有内容都可以添加样式，甚至是 <st c="20226">div</st> 元素。 重新添加您已删除的五个链接标签。
现在，在文本编辑器中打开名为 <st c="20309">index.css</st> 的文件。 在此代码中，您可以找到为 HTML 文件中每种标签类型指定的字体大小和颜色。 同样，您还可以找到 定位属性：
h1 {
font-family: 'Julius Sans One', sans-serif;
}
h2 { /* Contact, Skills, Education, About me, Work Experience */
font-family: 'Archivo Narrow', sans-serif;
}
h3 { /* Accountant */
font-family: 'Open Sans', sans-serif;
} <st c="20710">.container {</st> display: flex;
flex-direction: row;
width: 100%;
height: 100%;
} <st c="20788">.leftPanel</st> {
width: 27%;
background-color: #484444;
padding: 0.7cm;
display: flex;
flex-direction: column;
align-items: center;
}
## OUTPUT OMMITED ###
对比这里找到的名称，例如 <st c="20979">leftPanel</st> 或 <st c="20992">container</st>，与您的 <st c="21012">div class</st> 属性以及 <st c="21041">index.html</st> 文件中的内容。
第三个 文件， <st c="21074">avatar.png</st>，只是一个照片文件。 要在 HTML 中插入图片，使用 <st c="21142"><</st>``<st c="21143">img></st> 标签。
现在你已经理解了这三个文件以及它们之间的关系，替换内容为你自己的简历信息和照片。 如果你有信心，也可以修改一些样式。
发布网站
到目前为止，你所做的一切都只是在使用 你的本地工作站。 在本节中，我们将使你的网站 在全球范围内可用。
使用控制台访问你的 AWS 账户，如同在 第一章中所述。 导航到 S3： https://s3.console.aws.amazon.com/s3/home?region=us-east-1#。
创建一个桶。 在其配置设置中，给它一个唯一的名称，并保持 阻止所有公共 访问 选中。
进入新创建的 S3 桶，上传之前从书籍 GitHub 仓库下载的三个文件： <st c="21882">index.html</st>， <st c="21894">index.css</st>，以及 <st c="21909">avatar.png</st>。如前所述，这些是示例文件，你可以并且应该用你自己的文件替换它们。 如果在本章结束之前你还没有完成这个操作，你将看到一个展示书籍某位 作者简历的网站。
导航到 CloudFront 控制台（https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=us-east-1#/distributions），并创建一个 新的分发：
-
选择你的桶作为 Origin 域名。
-
将 Origin 访问 从 公开 更改为 Origin 访问 控制设置。
-
创建一个新的 OAC，选择默认选项，并在 Origin 访问控制下选择它。
-
在 Web 应用防火墙(WAF) 部分，不启用 安全保护。
-
在创建您的分发之前，请仔细阅读所有选项。 注意一些有趣的选项，例如缓存策略、自动压缩对象的能力，以及不同的定价类型。
当您创建 分发时，屏幕顶部将出现一个黄色弹出窗口，如 图 2**.4所示。选择 复制策略，然后选择 前往 S3 存储桶权限以 更新策略。
图 2.4 – CloudFront OAC 弹出窗口
您将看到您的 S3 存储桶设置。 选择 编辑 在 存储桶策略 部分下，粘贴您复制的策略，并且 保存。
该策略应如下所示。 它允许 CloudFront 服务访问您存储桶内的资源。 在这种情况下，就是 <st c="23519">cloudprojectwebsitebucket</st> 存储桶：
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "<st c="23796">arn:aws:s3:::cloudprojectwebsitebucket/*",</st> "Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/E33NUQ32Z0XQZB"
}
}
}
]
}
返回到您的 CloudFront 分发并记下分发名称。 请注意，CloudFront 分发可能需要一两分钟才能 变得可用。
在末尾附加 <st c="24134">index.html</st> ，并且在您的分发状态显示为 已启用后，使用浏览器打开它。 URL 应具有以下格式；其中突出显示的部分在您的情况下应该不同：
https://<st c="24418">index.html</st> at the end of the URL, right?
<st c="24458">Navigate to your CloudFront distribution and select</st> `<st c="24573">index.html</st>` <st c="24583">and save</st> <st c="24593">your changes.</st>
<st c="24606">Your distribution state will change to</st> **<st c="24646">Deploying</st>** <st c="24655">momentarily, as shown in</st> *<st c="24681">Figure 2</st>**<st c="24689">.5</st>*<st c="24691">, under the</st> **<st c="24703">Last</st>** **<st c="24708">modified</st>** <st c="24716">column.</st>
<https://github.com/OpenDocCN/freelearn-devops-pt6-zh/raw/master/docs/aws-cld-proj/img/B22051_02_5.jpg>
<st c="24850">Figure 2.5 – CloudFront distribution status during an update</st>
<st c="24910">When the distribution finishes propagating your changes, the status column shows the</st> **<st c="24996">Enabled</st>** <st c="25003">status, and the</st> **<st c="25020">Last modified</st>** <st c="25033">column shows a date as shown in</st> *<st c="25066">Figure 2</st>**<st c="25074">.6</st>*<st c="25076">.</st>
<https://github.com/OpenDocCN/freelearn-devops-pt6-zh/raw/master/docs/aws-cld-proj/img/B22051_02_6.jpg>
<st c="25223">Figure 2.6 – CloudFront distribution status after an update</st>
<st c="25282">Refresh your</st> <st c="25296">CV page, this time without the path, as shown in the following line.</st> <st c="25365">Remember to replace the highlighted string with your</st> <st c="25418">own domain:</st>
https://d1hjtv5xjv873g.cloudfront.net/
<st c="25469">Et voilà!</st> <st c="25480">Your CV is now online and available for recruiters to</st> <st c="25534">visit it.</st>
<st c="25543">Monitoring the website</st>
<st c="25566">Your website is online, you</st> <st c="25594">can share the URL with other people and they will always have access to your latest CV.</st> <st c="25683">However, how do you know whether they actually accessed it, or whether they are having a</st> <st c="25772">good experience?</st>
<st c="25788">You already know the answer; it’s</st> <st c="25823">CloudWatch metrics:</st>
1. <st c="25842">Navigate to the CloudWatch metrics</st> <st c="25878">console (</st>[<st c="25887">https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2</st>](https://us-east-1.console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2)<st c="25971">).</st>
2. <st c="25974">In the</st> **<st c="25982">Browse</st>** <st c="25988">tab, you will find all kinds of AWS services.</st> <st c="26035">Select CloudFront, followed by</st> **<st c="26066">Per-Distribution Metrics</st>**<st c="26090">.</st>
3. <st c="26091">If you have more than one distribution, you will need to identify the relevant one by ID.</st> <st c="26182">If you just have one, select</st> **<st c="26211">BytesDownloaded</st>**<st c="26226">,</st> **<st c="26228">Requests</st>**<st c="26236">,</st> **<st c="26238">5xxErrorRate</st>**<st c="26250">,</st> <st c="26252">and</st> **<st c="26256">4xxErrorRate</st>**<st c="26268">.</st>
<st c="26269">CloudWatch will plot a graphic for you on the top of your screen, like the one shown in</st> *<st c="26358">Figure 2</st>**<st c="26366">.7</st>*<st c="26368">. At 16h25, 18K bytes were downloaded and some users were facing HTTP</st> `<st c="26438">400</st>` <st c="26441">errors.</st> <st c="26450">These metrics were calculated as</st> <st c="26483">five-minute averages.</st>
<https://github.com/OpenDocCN/freelearn-devops-pt6-zh/raw/master/docs/aws-cld-proj/img/B22051_02_7.jpg>
<st c="26641">Figure 2.7 – CW metrics graph for CloudFront</st>
<st c="26685">These metrics are free</st> <st c="26708">and were automatically populated without you having to do anything other than just configuring CloudFront.</st> <st c="26816">However, if you want more detailed metrics such as</st> **<st c="26867">4xx</st>** <st c="26870">and</st> **<st c="26875">5xx</st>** <st c="26878">error rates by the specific HTTP status code, or cache hits as a percentage of total cacheable requests, you can enable that in your CloudFront distribution at</st> <st c="27039">a cost.</st>
<st c="27046">Explore CloudWatch metrics further and see what other metrics were automatically populated.</st> <st c="27139">Here’s a hint: consider your file</st> <st c="27173">storage service.</st>
<st c="27189">Cleaning up</st>
<st c="27201">AWS resources incur costs.</st> <st c="27229">Although most services initially fall under the free tier, eventually that runs out, and you will incur costs.</st> <st c="27340">We recommend that you delete every application after you are done playing</st> <st c="27414">with it.</st>
<st c="27422">Start by deleting your</st> <st c="27445">CloudFront distribution:</st>
1. <st c="27470">Navigate to CloudFront</st> <st c="27494">console (</st>[<st c="27503">https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=us-east-1#/distributions</st>](https://us-east-1.console.aws.amazon.com/cloudfront/v4/home?region=us-east-1#/distributions)<st c="27595">).</st>
2. <st c="27598">Select and disable your</st> <st c="27623">CloudFront distribution.</st>
3. <st c="27647">After it’s</st> <st c="27658">disabled, delete</st> <st c="27676">the distribution.</st>
<st c="27693">Next, delete your</st> <st c="27712">S3 bucket:</st>
1. <st c="27722">Navigate to S3</st> <st c="27738">console (</st>[<st c="27747">https://s3.console.aws.amazon.com/s3/home?region=us-east-1</st>](https://s3.console.aws.amazon.com/s3/home?region=us-east-1)<st c="27806">).</st>
2. <st c="27809">Select your bucket.</st> <st c="27830">Inside, delete all three files.</st> <st c="27862">Buckets can only be deleted if they</st> <st c="27898">are empty.</st>
3. <st c="27908">Delete</st> <st c="27916">your bucket.</st>
<st c="27928">Future work</st>
<st c="27940">Congratulations, you now have a working static website hosted on AWS.</st> <st c="28011">There are multiple features you can complement it with.</st> <st c="28067">This section details a few ideas, but it doesn’t guide you through</st> <st c="28134">their implementation.</st>
<st c="28155">Implementing custom DNS</st>
<st c="28179">Right now, your CV is at a</st> <st c="28207">non-memorable URL.</st> <st c="28226">It would be easier for you and others to remember if your URL was something such</st> <st c="28307">as</st> `<st c="28310">bestcandidatecv.com</st>`<st c="28329">.</st>
<st c="28330">When you access a URL, in the backend, your workstation does a lookup of this URL to retrieve the IP address.</st> <st c="28441">Then it connects to</st> <st c="28461">that address.</st>
<st c="28474">To verify this behavior, open your favorite terminal and execute the following command; it returns a series of IP addresses.</st> <st c="28600">Make sure you replace the URL with</st> <st c="28635">your own:</st>
$ nslookup d1hjtv5xjv873g.cloudfront.net
<st c="28685">CloudFront supports having custom</st> <st c="28720">domain names.</st>
<st c="28733">To achieve it, first, you will need to register a new domain.</st> <st c="28796">Domains are unique.</st> <st c="28816">Within the AWS ecosystem, you can register a new domain using</st> **<st c="28878">Route 53</st>**<st c="28886">. However, you can also register your domain with other providers.</st> <st c="28953">Domains</st> <st c="28961">have a</st> <st c="28968">yearly cost.</st>
<st c="28980">Secondly, you will need to create a DNS record inside your domain.</st> <st c="29048">If you are managing your domain in Route 53, this will be done under hosted zones.</st> <st c="29131">This DNS record points your new name to your CloudFront distribution</st> <st c="29200">DNS name.</st>
<st c="29209">In simple terms, if someone looks up</st> `<st c="29247">bestcandidatecv.com</st>`<st c="29266">, the server will return</st> `<st c="29291">d1hjtv5xjv873g.cloudfront.net</st>`<st c="29320">, and then recursively,</st> <st c="29344">the IP.</st>
<st c="29351">Lastly, you will need a</st> <st c="29376">new certificate.</st> <st c="29393">Navigate to your current CV website and check the certificate details.</st> <st c="29464">They should look like</st> *<st c="29486">Figure 2</st>**<st c="29494">.8</st>*<st c="29496">. This certificate is only valid for common names that end</st> <st c="29555">with</st> `<st c="29560">cloudfront.net</st>`<st c="29574">.</st>
<https://github.com/OpenDocCN/freelearn-devops-pt6-zh/raw/master/docs/aws-cld-proj/img/B22051_02_8.jpg>
<st c="29888">Figure 2.8 – CloudFront default certificate</st>
<st c="29931">Since you will access your CV with a custom name, you will need a certificate that supports that naming.</st> <st c="30037">Within the AWS ecosystem, you can use the</st> **<st c="30079">AWS Certificate Manager</st>** <st c="30102">(</st>**<st c="30104">ACM</st>**<st c="30107">) to issue a</st> <st c="30121">new certificate.</st>
<st c="30137">If you are interested in implementing this feature, the AWS documentation details the whole</st> <st c="30230">process:</st> [<st c="30239">https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html</st>](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html)<st c="30317">.</st>
<st c="30318">Taking security to the next level</st>
<st c="30352">Your website</st> <st c="30365">is simple, and while static websites are generally considered less vulnerable to certain types of web attacks due to their lack of dynamic content and server-side</st> <st c="30528">processing, they can still be targeted by various attacks, such as</st> **<st c="30596">Distributed Denial-of-Service</st>** <st c="30625">(</st>**<st c="30627">DDoS</st>**<st c="30631">) attacks, or</st> <st c="30646">content injection.</st>
<st c="30664">For example, a malicious person can launch a DDoS attack on your website right before an interview.</st> <st c="30765">Then during the interview, when you mention it, the website is not available, making you</st> <st c="30854">look bad.</st>
<st c="30863">Security is a</st> <st c="30878">huge topic, but some quick wins that you can implement are</st> <st c="30936">AWS</st> **<st c="30941">Web Application Firewall</st>** <st c="30965">(</st>**<st c="30967">WAF</st>**<st c="30970">) and</st> <st c="30976">AWS Shield.</st>
<st c="30988">Web Application Firewall</st>
<st c="31013">AWS WAF is a</st> <st c="31026">web application firewall (not all AWS services are what the name implies) that helps to protect from common web exploits that could affect application availability, compromise security, or consume</st> <st c="31224">excessive resources.</st>
<st c="31244">WAF is a managed service, and it offers managed rules</st> <st c="31299">called</st> **<st c="31306">rulesets</st>**<st c="31314">. They are groups of security rules that protect you against common attacks and are automatically updated as new threats emerge.</st> <st c="31443">This is especially useful if you are not a security expert, or if you don’t want to spend your time managing</st> <st c="31552">security rules.</st>
<st c="31567">WAF is neatly integrated with CloudFront, and you can enable it by editing your CloudFront distribution.</st> <st c="31673">It’s a one-click action.</st> <st c="31698">Doing so creates a WAF web ACL for you with 3 Amazon-managed rulesets.</st> <st c="31769">You can view them in your</st> <st c="31795">WAF console.</st>
<st c="31807">You can add more rules to the created Web ACL, or if you want to, you can configure a custom web ACL and attach it to your</st> <st c="31931">CloudFront distribution.</st>
<st c="31955">Your static website does not interact with user inputs.</st> <st c="32012">In later chapters, as your application attack</st> <st c="32057">surface increases, you will see more benefits</st> <st c="32104">of WAF.</st>
<st c="32111">If you are</st> <st c="32122">interested in implementing this feature, the AWS documentation details the whole</st> <st c="32204">process:</st> [<st c="32213">https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html</st>](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html)<st c="32308">.</st>
<st c="32309">Shield</st>
<st c="32316">AWS Shield is</st> <st c="32330">a managed DDoS protection service.</st> <st c="32366">It is designed to safeguard applications running on AWS against DDoS attacks, which are attempts to make a website or application unavailable by overwhelming it with</st> <st c="32532">malicious traffic.</st>
<st c="32550">Shield uses techniques such as traffic flow monitoring, network anomaly detection, and traffic scrubbing to identify and filter out</st> <st c="32683">malicious traffic.</st>
<st c="32701">It has two offerings:</st> **<st c="32724">Standard</st>** <st c="32732">and</st> **<st c="32737">Advanced</st>**<st c="32745">.</st>
<st c="32746">You are</st> <st c="32754">already using Shield Standard.</st> <st c="32786">This tier is automatically enabled for all AWS customers at no additional cost.</st> <st c="32866">It shields you from the most common and frequently occurring DDoS attacks targeting</st> <st c="32950">web applications.</st>
<st c="32967">Shield</st> <st c="32975">Advanced is an optional paid subscription that you can enable on a resource basis.</st> <st c="33058">It provides additional detection and mitigation capabilities against more sophisticated and larger DDoS attacks, including those targeting higher layers (HTTP/HTTPS) and specific applications.</st> <st c="33251">Shield Advanced integrates with services such as AWS WAF for more advanced</st> <st c="33326">security controls.</st>
<st c="33344">We do</st> *<st c="33351">not</st>* <st c="33354">recommend that you enable Shield Advanced for this project.</st> <st c="33415">It has a long subscription commitment, one year, and a big price tag for a personal project</st> <st c="33507">at $3,000/month.</st>
<st c="33523">If you are interested in knowing more about</st> <st c="33568">AWS Shield, visit the AWS documentation at</st> [<st c="33611">https://aws.amazon.com/shield/</st>](https://aws.amazon.com/shield/)<st c="33641">.</st>
<st c="33642">Having better observability</st>
<st c="33670">Logging</st> <st c="33679">refers to the process of recording events, messages, and other information generated by an application during its execution.</st> <st c="33804">It is an essential practice in software development and operations as it provides insights into the behavior, performance, and potential issues of</st> <st c="33951">an application.</st>
<st c="33966">You configured and verified metrics for your static website, but not logs.</st> <st c="34042">S3, CloudFront, WAF, and other AWS services have the ability to</st> <st c="34106">generate logs.</st>
<st c="34120">Consider enabling CloudFront access logs.</st> <st c="34163">They are log files that contain detailed information about every user request that CloudFront receives.</st> <st c="34267">You can enable access logs by editing your</st> <st c="34310">CloudFront distribution.</st>
<st c="34334">CloudFront logs contain 33 fields.</st> <st c="34370">Since that’s too many to list, some important ones to have in mind are</st> <st c="34441">as follows:</st>
* `<st c="34452">date</st>`
* `<st c="34457">time</st>`
* `<st c="34462">c-ip</st>` <st c="34467">– the IP address of</st> <st c="34488">the viewer</st>
* `<st c="34498">cs(UserAgent)</st>` <st c="34512">– the</st> <st c="34519">browser identifier</st>
* `<st c="34537">x-edge-location</st>` <st c="34553">– the physical location the request</st> <st c="34590">entered from</st>
<st c="34602">Important note</st>
<st c="34617">Although this feature might not seem very useful for this specific project, having an observable solution is considered an industry best practice.</st> <st c="34765">You will regret not having logs at the time of</st> <st c="34812">troubleshooting issues.</st>
<st c="34835">Logs can be written</st> <st c="34856">to various destinations, such as files, databases, or centralized logging services such as CloudWatch, Elasticsearch, or Splunk.</st> <st c="34985">CloudFront logs are written to an S3 bucket of your choice.</st> <st c="35045">If, later, you decide that you want to centralize your logs in CloudWatch, you can move them from S3\.</st> <st c="35147">AWS designed this architecture in a blog</st> <st c="35188">post:</st> [<st c="35194">https://aws.amazon.com/blogs/mt/sending-cloudfront-standard-logs-to-cloudwatch-logs-for-analysis/</st>](https://aws.amazon.com/blogs/mt/sending-cloudfront-standard-logs-to-cloudwatch-logs-for-analysis/)<st c="35291">.</st>
<st c="35292">After you have access to your CloudFront log files, you can correlate them with your CloudWatch metrics and have a complete picture of your user experience.</st> <st c="35450">For example, you will be able to tell, for the users having 4xx errors in</st> *<st c="35524">Figure 2</st>**<st c="35532">.7</st>*<st c="35534">, which countries are they from, which browser versions are they running, and which SSL security ciphers they tried</st> <st c="35650">to negotiate.</st>
<st c="35663">As mentioned, it’s also possible to enable logs for the other components of your architecture, such as S3\.</st> <st c="35771">Investigate the benefits of that on</st> <st c="35807">your own.</st>
<st c="35816">If you are interested in implementing CloudFront access logs, the AWS documentation details the whole</st> <st c="35919">process:</st> [<st c="35928">https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html</st>](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html)<st c="36010">.</st>
<st c="36011">Final architecture</st>
<st c="36030">The final architecture, after</st> <st c="36061">enhancements, should look like the one in</st> *<st c="36103">Figure 2</st>**<st c="36111">.9</st>*<st c="36113">. Notice the addition of WAF, Route 53, and Certificate Manager.</st> <st c="36178">Your final architecture might look slightly different if you did not implement all</st> <st c="36261">the enhancements.</st>
<https://github.com/OpenDocCN/freelearn-devops-pt6-zh/raw/master/docs/aws-cld-proj/img/B22051_02_9.jpg>
<st c="36369">Figure 2.9 – Final static website architecture with improvements</st>
<st c="36433">The final simplified traffic flow is</st> <st c="36471">as follows:</st>
1. <st c="36482">The client enters your custom URL in</st> <st c="36520">its browser.</st>
2. <st c="36532">Route 53 responds to the</st> <st c="36558">DNS query.</st>
3. <st c="36568">The client’s browser sends the HTTP request to</st> <st c="36616">CloudFront IPs.</st>
4. <st c="36631">The request is inspected</st> <st c="36657">by WAF.</st>
5. <st c="36664">CloudFront replies to the request, and returns the</st> <st c="36716">static assets.</st>
6. <st c="36730">The</st> <st c="36734">client’s browser renders the</st> <st c="36764">website locally.</st>
<st c="36780">All the components send metrics and logs to CW</st> <st c="36828">as configured.</st>
<st c="36842">Summary</st>
<st c="36850">In this chapter, you learned what static websites are.</st> <st c="36906">You also learned about the common files that compose them, such as HTML, CSS, and JavaScript.</st> <st c="37000">You followed</st> *<st c="37013">Chapter 1</st>*<st c="37022">’s methodology of requirements gathering, architecture patterns, service selection, and diagraming to draw the architecture of your own static website, a</st> <st c="37177">personal page.</st>
<st c="37191">Then, using the AWS console, you</st> <st c="37225">built it.</st>
<st c="37234">Lastly, you learned about multiple possible enhancements that can take your static website to a production-level website.</st> <st c="37357">By now, you are capable of building globally distributed, highly available, highly resilient, secure</st> <st c="37458">static websites.</st>
<st c="37474">In the next chapter, you are going to go beyond static websites and create a dynamic web application to share recipes.</st> <st c="37594">You will put all your knowledge in static websites to use, but take it one</st> <st c="37669">step further.</st>
第二部分：中级项目
在 第二部分 中，您将继续在 第一部分中学到的内容和构建的项目。然而，本部分的难度有所提升。 您将以一步步的方式构建四个应用，使用的 AWS 服务包括 EC2、Lambda、API Gateway、Rekognition 和 DynamoDB。 到本章结束时，您将能够独立构建自己的分布式 Web 应用。
本部分包括以下章节：
-
第三章, 构建一个食谱分享应用
-
第四章, 构建一个无服务器食谱分享应用
-
第五章， 实现图像分析器以检测照片友好性
-
第六章， 构建内容翻译管道
第四章：3
构建一个食谱分享应用程序
一个Web 应用程序 是一个通过互联网可以从 Web 浏览器（如 Google Chrome 或 Mozilla Firefox）访问的软件程序，它可以像 第二章中的示例一样简单并具有信息性，在该示例中，你将简历提供给最终用户，或者包含复杂的业务逻辑和关键数据 管理功能。
Web 应用程序可以分解为两个部分：前端 和后端。前端是用户可见的，通常使用 HTML、CSS、JavaScript 和现代框架（如 React.js 或 Vue.js）构建。 后端将处理业务逻辑、身份验证、数据处理及与外部服务和数据库的通信，通常使用 Python、Java 或 C# 等编程语言进行开发。 前端与后端之间的通信通常通过应用程序编程接口 (API)进行，使开发人员能够抽象出复杂性，并高效地在不同应用程序之间重用功能。
在本章中，你将开发一个分享食谱的应用程序，用户可以创建、删除或查看他们的食谱。 此外，你还将实现后端和前端，开发一个功能齐全的 Web 应用程序。
总结来说，本章涵盖以下主题 按顺序：
-
你将要构建的——一个用于 分享食谱
-
你将如何构建它——使用 S3 和 CloudFront 构建前端，使用 EC2 托管 API，使用 DynamoDB 存储 你的食谱
-
构建它——通过 CloudFormation 和使用 AWS 控制台
-
如何改进解决方案——改进监控和应用日志，强制执行安全协议以访问应用程序，并且 实施身份验证
在本章结束时，你将拥有在 AWS 上构建动态 Web 应用程序的实际经验，利用不同的服务实现特定功能，并理解前端和 后端开发的基础知识。
技术要求
要构建和部署你自己的食谱分享应用程序，你需要访问 AWS 账户，并可选地配置一个域名，如果你希望通过 HTTPS 实现安全通信。 需要提醒的是，正如你在本章中所看到的，我们提供了一个第二种选择，配置为 HTTP，不需要拥有 域名。
此外，本书在其 GitHub 仓库中有一个专门的文件夹，你可以在这里找到必要的代码片段以供跟随 学习： https://github.com/PacktPublishing/AWS-Cloud-Projects/tree/main/chapter3/code。
场景
在 上一章中，你创建了一个个人网站来分享你的简历，这个网站已经在招聘人员中变得非常受欢迎，其他同行也在寻找类似的方式来分享他们的简历。 这对你的职业生涯非常有帮助，你开始思考云技术如何在你的副业和兴趣项目中提供帮助；其中一个与 你的烹饪技能 有关。
你花费大量空闲时间创造食谱和重新发明甜点，通常把它们写在笔记本里。 与此同时，你已经开始在社交媒体上建立自己的个人档案，并且已经有 80 万粉丝，他们对你菜肴的照片作出反应，并向你索要食谱。 由于你的名气越来越大，朋友和家人开始称你为“厨师”，并经常向你请教一些他们曾经尝试过的特定食谱的建议。 过去。
直到现在，你还需要去查找你的食谱笔记本，拍照并分享，但随着时间的推移以及你创作的食谱数量越来越多，这变得越来越难以管理，你需要考虑 一个替代方案。
在熟悉云技术的过程中，你开始寻找替代当前食谱分享方法的方案，用于你的第二个云项目——一个名为食谱 分享应用程序。
需求
在我们开始 解答 如何 解决这个问题之前，重要的是要澄清 我们 将要构建什么，并以清晰简洁的需求列表进行结构化，就像我们在 第一章 中介绍的那样，并在 第二章 中举例说明。
在这 个项目中，您希望开发一个食谱分享应用程序，为人们提供一个方便的平台来发现、分享和访问不同的食谱。 与前一章不同，这个应用程序需要处理与食谱管理相关的动态内容。 有不同的关键人物将访问 您的应用程序：
-
平台管理员：平台所有者，可能希望创建新配方、维护或 删除配方。
-
终端用户/消费者：使用平台访问特定配方的最终用户，不应具备创建、更改或删除 任何记录的权限。
实际的实施应是应用开发的最后一步，精确和详细的需求收集是定义清晰的 开发计划的关键。
您使用的技术、采用的服务和设计的架构应是您列出以实现 目标的技术和非技术要求的结果。
业务需求
在 您进行的市场研究后，以及在一周内获得的点赞和评论数量，您得出结论，人们倾向于在星期五和星期六花更多时间烹饪，特别是晚餐时间。 您还分析了用户的地理分布，85%位于美国，12%位于欧洲，其余 3%分布在 全球其他地区。
一家食品配送服务向您提出签署广告合同的要求，但他们只同意在您的应用程序中达到 100,000 活跃用户之后才会给出收入流。 在那之前，您的应用程序将没有收入来源。
根据这些发现和潜在的收入机会，您已经确定了以下关键 业务需求：
-
在年底之前全球达到 100,000 用户 的目标
-
增强 在欧洲的存在
-
在支持增长的同时保持成本效益 且成本不显著
功能需求
您的 应用程序应服务于两个不同的用户群体： 管理员 和 终端用户。对于最初的项目，您将开始两个不同的页面， <st c="6170">/user</st> 供终端用户使用， <st c="6198">/admin</st> 供管理员使用，以支持这两个 不同的角色。
你还希望通过简洁的用户界面创造无缝体验。 此外，你希望你的应用能够响应式，支持不同的设备，如平板、手机，和笔记本电脑。
描述功能需求的一个关键步骤是创建界面原型，如 图 3.1， 3.2， 和 3.3。
图 3.1 – 用户界面首页原型
让我们拆解不同的功能 和接口：
-
<st c="6742">/</st>``<st c="6744">用户</st>：-
访问 食谱标题列表
-
能够选择特定食谱并访问所有 详细信息
-
响应式
-
图 3.2 – 用户页面 UI 原型
-
<st c="7061">/</st>``<st c="7063">管理员</st>：-
访问 食谱标题列表
-
能够 删除食谱
-
支持 食谱创建
-
控制 最大支持的食材、步骤和 食谱数量
-
响应式
-
图 3.3 – 管理页面 UI 原型
非功能性需求
你的 应用需要处理突发访问模式，因为预计的使用量应仅在就餐时间接近时增加。 另外，你计划在未来几个月增加欧洲用户群，因此你需要为全球用户提供服务。 此外，成本效益至关重要，因为你的应用没有收入来源。 总结一下，以下是你需要的： 需求：
-
全球分发，服务全球用户 分布在全球各地的用户
-
自动扩展以处理突发 使用模式
-
成本效益
技术要求
如 在 功能需求 部分中所述，您希望支持多设备，因此您的应用需要具备响应式设计，以保持一致且良好的用户体验。 因此，前端您希望选择一个简化响应式设计并加速开发过程的框架。 对于后端，您希望采用 Python 作为编程语言，因为它简单、灵活，并且拥有庞大的库和框架生态系统， 同时支持 AWS SDK。 除了与 AWS 服务的所有交互外，您还需要开发自己的 API，因此您选择了 FastAPI，一个用 Python 构建的现代 Web 框架，旨在高效、用户友好且轻量级。 我们将使用以下技术：
-
现代前端框架 – React.js
-
后端编程语言 – Python
-
FastAPI 作为 API 开发框架
数据需求
在您的应用中，您处理食谱数据，有多种方式可以存储它们。 食谱可以作为单独的文档存储，记录或条目之间没有关系。 您不期望对数据进行任何复杂的查询，而是希望实现简单的操作来执行 以下内容：
-
列出食谱：展示已创建的食谱列表。
-
删除一个食谱：如果管理员不再希望某个特定的食谱成为组合的一部分，应当能够删除该条目。
-
创建一个食谱：创建一个新的食谱与 用户分享。
另外，您希望实现一个高度可扩展的数据存储，要求最低或无维护工作，理想情况下是一个管理服务。 作为您食谱文档的结构，您设计了 <st c="9671">recipe_example.json</st>：
{ "ID":"GUID",
"Title":"recipe title",
"Ingredients":[…],
"Steps":[…] }
考虑到每个食谱包含 10 个步骤和 10 个材料，您得出每个食谱大约为 1 KB 的结论。 在读取操作方面，假设在高峰时段有 20,000 个并发用户 ，您将有 20,000 个并发读取操作，并且您希望确保即使在 高峰时段也能保持性能的一致性。
架构模式
AWS 架构中心提供了一个由 AWS 合作伙伴的云架构专家精心编制的全面资源集合，包含经过测试和推荐的解决方案，可以作为起点。 对于这个项目，AWS 提供了一种完全适用于你的场景的架构模式： 将基于 React 的单页面应用部署到 Amazon S3 和 CloudFront (https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html). 阅读这些推荐的指南将帮助你了解你将要遵循的过程。
要深入了解每个 AWS 服务，AWS 文档可能是最好的信息来源。 每个服务都有自己的文档，强烈建议你查看并通读它，以掌握从基础到更高级的概念。 此外，理解 AWS 在你项目中的角色也很重要。 AWS 将为你提供支持、托管，并帮助你满足需求，但基本的网页开发知识是必不可少的。 在进行实现之前，了解与你的应用架构相关的一些关键概念是至关重要的。 例如，你应该能够 回答以下问题：
-
什么是 单页面应用 (SPA)，它与传统的 网页应用有何不同？
-
API 在你的应用中扮演什么角色？ 为什么你 需要一个 API？
第一个问题，a SPA 是一个加载单一 HTML 页面并在用户与应用互动时动态更新该页面的网页应用。 与传统的多页面应用不同，后者每次用户操作都需要从服务器加载一个新页面，SPA 初始时会加载所有必要的 HTML、CSS 和 JavaScript 文件，后续的交互通过 JavaScript 和对 服务器的请求无缝进行。
确保你能够回答剩下的问题，在跳入 AWS 之前建立扎实的知识基础。
架构
到目前为止， 你应该已经熟悉了将要使用的技术，并且你可能已经在本地实现了一个小的概念验证。 下一步是创建一个架构图，以支持你的项目。 图 3**.4 是一个抽象图，参考了组成完整架构的主要层次，是进行 架构设计的一个良好起点。
图 3.4 – 抽象架构
最终用户与展示层交互，以获取前端应用程序，并向计算层发出请求，但永远不会直接访问数据层。 相反，计算层负责通过 API 执行数据操作。
设计 API 非常关键，以确保你使用正确的模型来执行所有需要的数据操作，同时还应考虑数据和功能要求。 图 3**.5 展示了基于 所做分析的初步 API 结构。
图 3.5 – API 结构
以下是 详细说明：
-
<st c="13215">GET /recipes</st>：此操作获取食谱列表。 -
<st c="13261">GET /health</st>：这是一个简单的健康 检查端点。 -
<st c="13315">DELETE /recipes/{recipe_id}</st>：此操作删除具有 定义 ID 的特定食谱。 -
<st c="13395">POST /recipes</st>：此操作创建一个新的 食谱记录。
考虑到这一切， 你应该能够继续进行完整架构的设计，并使用相应的 AWS 服务。 对于前端，像上一章所用的解决方案，你将使用 Amazon S3 和 Amazon CloudFront 来提供应用程序。 计算层通过 Amazon EC2 实现，计划将 API 部署在此处。 对于数据层，在考虑所有要求之后，你最终选择了 Amazon DynamoDB 作为数据存储。 为了简化，你将把计算层和数据层合并成一个名为后台的单一层，最终，你的架构图应如下所示 图 3**.6。
图 3.6 – 用于食谱共享应用程序的 AWS 架构
在 建立高层架构后，让我们更深入地探讨你选择的具体 AWS 服务，了解它们如何与之前定义的需求对齐。 。
AWS 服务
截至本文撰写时，AWS 提供了 200 多种服务，支持不同的用途，并且管理层级各异。 选择 AWS 服务是一个重要的过程，选择应由预先定义的需求驱动，而不是相反。 在这一章节中，你将探索你解决方案中采用的服务，并了解它们如何与已定义的需求对齐。 部分服务内容已经在前几章中覆盖过。 因此，为避免内容重复，我们将简要提及当前用例的优势，并引用可以找到详细解释的章节。 。
Amazon S3
你的 前端是一个使用 React.js 构建的 SPA，它会被转化为静态文件，如 HTML、CSS 和 JavaScript，应当将这些文件视为对象。 如 第二章所述，S3 是 AWS 提供的一个可扩展、高可用且持久的对象存储服务，是托管静态网站的成本效益高的解决方案， 包括 SPA。
重要提示
S3 设计时保证了 11 个 9 的数据耐久性。 这意味着，如果你在 S3 存储 10,000 个对象，你可以预期每 1000 万年因硬件故障或其他潜在数据丢失原因，最多丢失一个对象。 。
如果你想深入了解 Amazon S3 架构，推荐观看 AWS re:Invent 2023 - 深入了解 Amazon S3 的会议： https://www.youtube.com/watch?v=sYDJYqvNeXU。
Amazon CloudFront
如果你计划让 你的应用程序全球服务用户，并希望确保使用 HTTPS 协议进行安全访问，而 S3 不支持此协议。 这只是将 CloudFront 纳入架构的众多原因之一，若要了解服务的详细解释及其优势，建议查看 AWS 服务 章节中的内容： 第二章。
Amazon 虚拟私有云（VPC）
Amazon VPC 允许 你在 AWS 云中创建一个逻辑隔离的虚拟网络。 它使你能够定义一个虚拟网络环境，在其中启动和 管理 AWS 资源，如 Amazon 弹性计算云 (EC2) 实例，以安全和受控的方式。 作为 VPC 配置的一部分，你可以定义带有多个子网的网络拓扑，这些子网可以是公共的或私有的，意味着分别具有或不具有互联网访问权限，以便隔离流量并增强 安全性。
Amazon EC2
从 技术要求来看，你决定开发自己的 API，现在你需要一个服务来部署和托管它。 Amazon EC2 允许你在 VPC 内配置虚拟机（实例）来运行你的应用程序，或者在此情况下，运行你的 API。 EC2 提供了多种实例类型，具有不同的 CPU、内存、存储和网络容量配置，允许你选择适合特定应用程序需求的实例类型，确保最佳性能 和成本效益。
EC2 提供了不同的定价模型，如果你对需求有清晰的了解，可以带来额外的成本效益，同时还提供按需选项，采用纯粹的按量付费模式，这正是你为 此项目选择的。
如果你想了解 更多关于 EC2 定价模型及其工作原理的信息，你可以在 AWS 文档中阅读： https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-ec2.html。
应用程序负载均衡器 (ALB)
ALB 是一个 完全托管的负载均衡 解决方案，旨在将流量分配到多个目标，具体来说就是 EC2 实例。 作为一个托管解决方案，它在设计上具有高度的可扩展性，并根据流量负载自动进行扩展。 此外，根据你的需求，ALB 带来了两个 主要优势：
-
健康检查：每个 负载均衡器都需要至少一个目标组，你可以为目标配置健康检查，以确保流量只发送到健康的目标，避免不良的用户体验，并提高应用程序的弹性和容错能力。 你的应用程序。
-
SSL 终止：ALB 支持 SSL 终止，卸载加密和解密的计算负担，减轻你的 EC2 实例的负担。
ALB 还 与 AWS Web 应用防火墙无缝集成，这为防范常见攻击提供了额外的安全保护，例如 SQL 注入， 跨站脚本攻击 (XSS)，以及其他网页 应用漏洞。
亚马逊 DynamoDB
选择你的数据库解决方案应根据你的数据和需求来决定。 对于这个项目，你需要将食谱存储为单独的文档。 此外，你已经定义了关于查询一致性和高性能的需求，即使在多个并发的 查询操作下。
亚马逊 DynamoDB 是一种完全 托管的 NoSQL 数据库服务，更具体地说，是一种键值和文档存储，它在任何规模下都能提供单毫秒级的性能。 通过选择 DynamoDB，你将利用其天生的高可用性，因为底层的数据复制采用按需付费模式并自动扩展，以处理突发的工作负载，就像 你的应用程序的情况。
重要提示
DynamoDB 本质上是一个分布式服务，但即使你需要高一致性，这也不应成为障碍。 DynamoDB 提供两种一致性模型：最终一致性（默认）和强一致性。 使用最后一种选项，你可以确保高一致性和数据完整性，确保返回的数据始终是最新的。 。
如果你想了解更多关于 DynamoDB 的故事、10 周年后的经验教训以及未来计划，查看这篇来自 Amazon Science: https://www.amazon.science/latest-news/amazons-dynamodb-10-years-later。
AWS CloudFormation
在*第一章*中，我们简要介绍了 AWS CloudFormation 作为配置基础设施的工具，但考虑到这是它首次被广泛使用的章节，我们将进一步深入讲解并详细说明 它。
CloudFormation 是一个 基础设施即代码 (IaC) 服务，允许你以声明性方式定义并配置 AWS 资源，这些资源通过模板文档来描述，模板可以用 YAML 或 JSON 编写。 像所有 IaC 工具一样，CloudFormation 支持基础设施生命周期自动化，从创建、更新到删除。 它支持漂移检测，用于识别可能在模板外部进行的更改，这些更改可能导致不一致。 不建议手动更改由 CloudFormation 管理的资源，因为这可能导致配置漂移，即资源的实际状态与 模板中定义的状态不符。
CloudFormation 的一个主要优势是它能够将资源管理和配置作为一个单一的单元，称为栈。 该栈可以包含来自各种 AWS 服务的资源，如 EC2 实例、VPC、S3 存储桶等。 CloudFormation 会根据 模板中定义的依赖关系，负责按正确的顺序创建和配置这些资源。
编码解决方案
到目前为止， 你应该已经牢固掌握了所使用的核心服务、选择这些服务的原因，最重要的是，如何使这些服务与你的需求相符合。 你现在终于可以进行 实际的实施了。
克隆项目
如果你正在 跟随前几章的内容，你应该已经克隆了与本书相关的代码库，但如果你是刚刚开始，可以先克隆该仓库，或者选择将代码库作为一个 ZIP 文件 下载。 该仓库的结构是以每章一个文件夹为单位的，本章的所有代码位于 <st c="22055">chapter3/code</st>。
在 <st c="22081">chapter3/code</st> 文件夹内，你将找到三个子文件夹，如 图 3**.7所示：
-
<st c="22159">frontend</st>：此处包含 你的前端代码 -
<st c="22210">backend</st>：此处包含 你的 API 代码 -
<st c="22256">platform</st>：此处包含两个不同的 CloudFormation 模板，用于部署 你的应用程序的主要基础设施。
图 3.7 – 第三章 文件夹结构
为什么有两个不同的 模板可供选择？
SPA 有两种连接方式：一种是通过 CloudFront 获取前端资源，另一种是通过浏览器中的 JavaScript API 请求与后台进行通信，如下图所示： 图 3**.6。
虽然 CloudFront 会自动提供 HTTPS 来交付前端资源，但您的 API 需要额外的配置。 为了使用 HTTPS 保护 API，您需要拥有一个域名并申请证书以 证明所有权。
我们理解您现在可能没有域名，或者不想购买域名，这不应该成为部署应用程序的障碍，因此我们已为您提供解决方案！
我们为本节设计了两种不同的选项，因此在 <st c="23227">平台</st> 文件夹中有两个不同的模板。 下表将选项与模板进行映射，帮助您选择 正确的路径：
| 描述 | CloudFormation 模板 | 推荐 | |
|---|---|---|---|
| 选项 1 | 您要么拥有一个域名，要么愿意购买一个域名来配置与 您的 API 的 HTTPS 通信 | <st c="23498">ch3-https-complete.yaml</st> | 是 |
| 选项 2 | 您希望在没有拥有或购买域名的情况下测试应用程序 一个域名 | <st c="23606">ch3-http.yaml</st> | 否 |
表 3.1 – CloudFormation 模板与您选择的选项之间的映射
关于 HTTP 和 HTTPS 之间差异的详细解释超出了本书的范围，但如果您想了解更多，您可以阅读以下 文章： https://aws.amazon.com/compare/the-difference-between-https-and-http/。
您遵循的步骤取决于您选择的选项。 为了简化过程，选项 1 的特定步骤将标记为 (仅适用于选项 1)，选项 2 的步骤将标记为 (仅适用于选项 2)。没有任何标记的步骤适用于两种选项。 请注意，即使选择了选项 2，建议阅读选项 1 的 HTTPS 配置步骤，以获取 更多知识。
重要说明
虽然此应用程序和 CloudFormation 模板旨在适用于任何 AWS 区域，但如果选择选项 1，则必须使用相同的区域来创建证书并部署解决方案。 这是因为选项 1 需要使用 AWS 证书管理器创建证书，而这是一个 区域性服务。
第一部分 – DNS 配置和证书签发（仅适用于选项 1）
要 配置 HTTPS，您需要拥有一个域名，并通过获取证书来证明所有权，本节将介绍如何配置您的 DNS 服务并为 您的域名签发证书。
域名是通过域名注册商购买的，注册商管理互联网域名的预定和注册。 在 AWS 中，Route 53 可以同时作为您的域名注册商，用于 购买域名，以及作为 DNS 服务来管理它们。 此外，您还可以选择流行的第三方注册商，如 GoDaddy 或 Namecheap 等，来购买 您的域名。
Route 53 中的 DNS 配置
在本 示例中，我们刚从第三方提供商那里购买了一个域名，并将演示如何在 Route 53 中为外部购买的域名设置 DNS 管理 。
在控制台中，通过在搜索栏输入 <st c="25559">route 53</st> ，如 图 3**.8所示，或者你也可以通过以下 链接直接访问： https://console.aws.amazon.com/route53。
图 3.8 – 控制台访问 Route 53 服务
在 Route 53 控制台的左侧面板中，执行以下操作：
-
点击 托管区域。
-
然后，点击 创建 托管区域。
-
填写
<st c="25967">awscloudprojects.site</st>。 -
选择 公共托管区域 作为 类型。
-
点击 创建 托管区域。
您的配置窗口应该如下所示 图 3**.9，除了 域名 字段 。
图 3.9 – Route 53 托管区域创建表单
如果你 返回到 托管区域 菜单，你应该能够看到你的域名列出。 要访问与你的托管区域关联的名称服务器，请按照 以下步骤操作：
-
点击你创建的域名。
-
请注意相关的名称服务器，因为你将需要它们来配置 DNS。
你应该在你的托管区域详情中看到四个名称服务器值，如 图 3**.10所示：
图 3.10 – 托管区域详情
以下步骤涉及更新你域名的名称服务器，具体步骤可能会根据你的域名注册商而有所不同。 无论你的注册商是谁，AWS 都提供了与流行 注册商配置名称服务器的逐步指南： https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/migrate-dns-domain-in-use.html。
重要提示
一个 托管区域 在 Amazon Route 53 中是一个容器，保存特定域名及其子域的所有 DNS 记录和路由配置。 它允许你根据定义的 路由策略管理和路由流量到你的 AWS 资源或外部资源。
证书颁发
你现在将继续 使用 AWS 证书管理器 (ACM) 服务进行证书颁发过程。 在控制台中，转到 ACM 服务 ，地址为 https://console.aws.amazon.com/acm。
图 3.11 – 控制台访问 ACM 服务
要为你的域名颁发证书，你需要按照 以下步骤操作：
-
点击 请求一个 证书 按钮。
-
在 证书类型 屏幕上，选择 请求公共证书 选项，点击 下一步。
-
在表单中填写必要的信息。大多数字段可以保留默认值，但对于
app.example.com、api.example.com等，您可能需要进行调整。 -
*.example.com。 -
确保验证方法设置为DNS 验证，这是 AWS 推荐的方式。
-
点击请求。
图 3.12展示了表单的最终状态，包含所有必要字段。
图 3.12 – 证书请求表单
在请求证书后，您将看到它的状态为待验证。要验证证书并证明域名所有权，您需要在您的托管区域创建一个 DNS 记录。
如果您的域名由 Route 53 管理，您可以点击创建 Route 53 记录，如图 3.13所示，这样可以更轻松地进行设置。
图 3.13 – 使用 DNS 记录验证证书
在继续操作之前，您需要等待状态变为已颁发，如图 3.14所示。如果一切配置正常，通常不需要超过 10 分钟，但根据 AWS 文档，可能需要长达几个小时，查看详细信息。
图 3.14 – ACM 证书列表
最后一步是记下certificateARN，您需要在 CloudFormation 模板中作为参数输入它：
-
导航到您创建证书所在区域的 ACM 控制台。
-
从左侧面板中选择证书列表。
-
定位到您的“已颁发”证书，如图 3.14所示。
-
点击证书，在 证书状态下，你将 找到 ARN。
图 3.15 – 证书 ARN 访问
重要说明
在 AWS 中，ARN 是 AWS 服务的唯一标识符。 它遵循以下 格式： <st c="31982">arn:partition:service:region:account-id:resource-type/resource-id</st>。
第二部分 – 解决方案部署
现在，你将使用 CloudFormation 模板来部署支持你的应用程序的基础设施，包括前端和后端，模板文件位于 <st c="32233">chapter3/code</st> 文件夹中。 根据你选择的选项，选择不同的模板，它将创建不同的组件，正如你在 下表中看到的那样。
| 选项 1(配置了 HTTPS | 选项 2(配置了 HTTP | |
|---|---|---|
| 模板 | <st c="32465">ch3-https-complete.yaml</st> | <st c="32489">ch3-http.yaml</st> |
| 前端 | CloudFront 和 S3 | CloudFront 和 S3 |
| 后端 |
-
1 VPC
-
2 公共子网
-
2 私有子网
-
1 私有 EC2 实例
-
1 ALB
-
1 NAT 网关
-
EC2 实例角色，具有与 DynamoDB 交互的最小权限 食谱表
|
-
1 VPC
-
1 公共子网
-
1 公共 EC2 实例
-
EC2 实例角色，具有与 DynamoDB 交互的最小权限 食谱表
|
| 数据存储 | DynamoDB | DynamoDB |
|---|
表 3.2 – 每个 CloudFormation 模板的资源创建
从控制台，进入 CloudFormation 服务，网址为 https://console.aws.amazon.com/cloudformation/。如果你选择了选项 1，请确保在控制台右上角的下拉区域列表中选择与你为证书选择的相同区域，如 图 3**.16所示。
图 3.16 – 控制台访问 CloudFormation
要继续堆栈创建，请按照以下步骤操作：
-
点击创建堆栈。
-
在先决条件 – 准备模板部分，选择选择一个现有模板。
-
在指定模板部分，选择上传模板文件。
-
点击选择文件。
-
根据您所遵循的选项，从
chapter3/code/platform文件夹中选择模板。 -
点击下一步。
您的创建堆栈窗口应如下所示图 3.17。
图 3.17 – CloudFormation 创建堆栈表单
下一步是配置 CloudFormation 堆栈中的参数。参数允许您创建动态且特定于环境的资源配置，从而提高基础设施作为代码的安全性和可维护性。在表 3.3中，我们解释了每个参数的目的以及哪些适用于您选择的选项。
| 参数 | 描述 | 选项 1（HTTPS 配置） | 选项 2（HTTP 配置） |
|---|---|---|---|
<st c="35278">InstanceType</st> | 从四个可用选项中选择 EC2 实例类型；默认是免费层，t3.micro。 | 是 | 是 |
<st c="35401">LatestAmiId</st> | Amazon 机器镜像（AMI）将在您的 EC2 实例中使用。默认情况下，它将使用最新的 AMI。 | 是 | 是 |
<st c="35531">GitRepoURL</st> | 代码仓库的 URL（例如， https://github.com/packtpublishing/aws-cloud-projects）。 | 是 | 是 |
<st c="35633">ALBCertificateArn</st> | 你刚刚创建的证书的 ARN。 | 是 | 否 |
表 3.3 – CloudFormation 模板参数
在 图 3**.18中，你 可以看到预期状态的示例，其中 <st c="35907">ALBCertificateArn</st> 不存在。
图 3.18 – CloudFormation 中的堆栈参数
继续操作，确认已创建 <st c="36639">IAMPolicy</st> 用于控制 API 访问 DynamoDB 表，并 点击 提交。
图 3.19 – CloudFormation 堆栈提交
你的应用程序的资源现在正在被配置。 你需要等待，直到堆栈状态更改为 CREATE_COMPLETE。你应该能够看到类似于 图 3**.20的状态。
图 3.20 – CloudFormation 堆栈创建状态
在我们的例子中， 堆栈部署大约花了 10 分钟，但请注意，这 可能会有所不同。
第三部分 – 附加配置（仅选项 1）
你 快完成了！ 你只需要进行一个附加配置，就能让你的应用运行起来，那就是在托管区中创建一个指向 ALB 的子域记录。 这还将启用一个友好的 API 名称，例如 <st c="37914">api.<your_domain></st>。按照以下步骤操作：
-
前往 Route 53 控制台。
-
选择你的域名的 托管区。
-
点击 创建记录。
-
进入
<st c="38129">api</st>). -
对于 记录类型，选择 A - IPv4 地址。
-
点击 记录名称 下的切换按钮 启用 别名。
-
在 将流量路由到 下拉菜单中，选择 应用程序和经典的别名 负载均衡器。
-
选择你的应用程序 部署的 AWS 区域。
-
在 选择负载均衡器 部分，选择与你的 CloudFormation 堆栈关联的 ALB。
-
如果 你在所选区域有多个负载均衡器，你可以通过检查 CloudFormation 堆栈的输出 部分来找到正确的负载均衡器 DNS 名称，在 CloudFormation 控制台中查看。
-
点击 创建记录 按钮保存 新记录。
你的记录创建表单应该像 图 3**.21。
图 3.21 – 你的 ALB 的 Route 53 别名记录
在进入下一部分之前，记下你创建的 DNS 记录，因为你将在 下一部分使用它。
第四部分 – 前端配置与部署
CloudFormation 堆栈已经部署了前端所需的服务，唯一剩下的步骤是将应用程序文件复制到 S3\。 但在此之前，你需要修改一些应用程序中的配置。 由于 React 开发不是本书的主要内容，我们已经创建了包含参数的配置文件，以便定制 你的应用程序。
导航到项目文件夹中的 <st c="39937">…/frontend/src/configs/configs.tsx</st> 文件，配置文件 位于此处。
配置文件由七个 配置变量组成：
-
<st c="40106">CONFIG_MAX_INGREDIENTS</st>: 一份食谱中最大 配料数 -
<st c="40159">CONFIG_MAX_STEPS</st>: 一份食谱中的最大 步骤数 -
<st c="40200">CONFIG_MAX_RECIPES</st>: 支持的最大 食谱数量 -
<st c="40243">CONFIG_USER_PAGE_TITLE</st>: 用户页面的标题 用户页面 -
<st c="40288">CONFIG_ADMIN_PAGE_TITLE</st>: 管理员页面的标题 管理员页面 -
<st c="40335">CONFIG_appConfig</st>：包含页面标题和图标的对象（图标位于<st c="40397">/frontend/public/</st>） -
<st c="40416">API_URL</st>: API 端点
图 3.22 – 配置文件示例 (config.tsx)
除了 <st c="40955">API_URL</st> 之外，所有配置项都是可选的，仅用于应用程序的微小定制，因此我们现在将重点关注 API 端点的配置。 <st c="41092">API_URL</st>，顾名思义，是用于发送请求的端点，根据您选择的选项，您需要从 不同的位置获取此值。
选项 1 的解决方案
在此选项中，您现在应该已经为您的 ALB 创建了 Route 53 记录，并且这是您应该为 <st c="41427">API_URL</st> 参数使用的值。
例如，在我们的案例中，按照 图 3**.22，我们创建了一个 <st c="41506">api.awscloudprojects.site</st> 记录，因此 <st c="41543">API_URL</st> 应设置为 <st c="41568">https://api.awscloudprojects.site</st> (不要忘记包含 协议部分)
选项 2 的解决方案
如果您选择这个选项，这意味着您没有为您的 API 创建 DNS 记录，也没有配置 ALB。 此外，由于您没有设置 HTTPS，访问 API 使用的协议是 HTTP。 因此，在这种情况下，您需要提供 EC2 公共 DNS。
您可以通过以下链接访问正在运行的 EC2 实例 https://console.aws.amazon.com/ec2/home?-Instances:instanceState=running，但您也可以选择通过 CloudFormation 输出中的 <st c="42180">APIDNSName</st> 访问新部署实例的 DNS。
在设置了 <st c="42217">API_URL</st> 配置后，您可以保存文件并继续构建过程，这个过程包括几个步骤，将代码转换为可用于网页浏览器的生产就绪的打包文件。 在我们的示例中，我们使用了 <st c="42429">npm</st> 作为包管理器，因此您需要运行以下命令：
$ npm install && npm run build
结果是一个包含需要复制到 S3 存储桶中的文件的文件夹。 文件夹名称可能会有所不同，但通常为 <st c="42652">build/</st> 或 <st c="42662">dist/</st> ，并且创建在前端根目录，如 图 3**.23所示。
图 3.23 – 构建命令后的文件夹结构
现在，最后一步是将构建文件夹复制到 S3，按照以下说明操作：
-
<st c="43093">frontend-chapter-3-</st>后面跟着一串随机字符（例如，<st c="43162">frontend-chapter-3-XXXXX</st>）。 点击其名称以 打开它。 -
从
<st c="43239">dist</st>文件夹添加文件。 -
在 S3 存储桶中，点击 上传 按钮。 这将允许您从本地机器上传文件到 S3 存储桶。
<st c="43458">dist</st>文件夹在您的本地机器上，选择该文件夹中的所有文件并确认。 接下来，在 S3 控制台中，点击<st c="43603">dist</st>文件夹，选择<st c="43649">assets</st>文件夹， 并确认。
可选择性地，您可以直接将内容拖放到 S3 窗口，但无论您使用哪种方法，您的 S3 上传窗口应该像 图 3**.24所示。
图 3.24 – 上传到 S3 的前端文件
注意
文件名是由构建过程自动生成的，因此您的文件名可能与 前面的图示不同。
请确保您有以下文件：
-
<st c="44419">i</st>``<st c="44421">ndex.html</st> -
<st c="44430">i</st>``<st c="44432">ndex-XXXXXX.css</st> -
<st c="44447">i</st>``<st c="44449">ndex-XXXXXX.js</st> -
您可能在应用程序中包含的静态文件，例如图像
之后，在底部点击 点击 上传。
您刚刚完成了所有的部署和配置，现在是时候 进行测试了。
第五部分 – 测试和探索您的应用程序
这一最后 部分专注于测试和探索你的应用程序，我们将其分为两部分：后端和前端。 让我们从 后端开始！
测试和探索后端
到现在为止，你 应该已经在 EC2 实例中运行了一个 API，再次强调，根据你选择的选项，你需要使用不同的 URL 进行测试，以及你在上一节更新的 <st c="45137">API_URL</st> 参数所使用的值，在 <st c="45162">config.tsx</st> 文件中。 要测试你的 API，你可以向其中一个端点发送请求，如果一切正常，你应该会收到响应和一个成功的 状态码。
要执行测试，你 可以将端点定义为 <st c="45427">{API_URL}/{ROUTE}</st>，其中 <st c="45452">API_URL</st> 是你在上一节的 <st c="45487">config.tsx</st> 文件中使用的 URL。 这里， <st c="45534">ROUTE</st> 是你想要访问的特定路由。
有许多不同的工具可以执行请求，你可以选择你喜欢的工具，但是如果你更喜欢视觉化工具，你可以使用，例如 Postman，或者选择通过运行一个 <st c="45812">curl</st> 命令来采用编程方法。
在以下代码中，你可以看到一个向我们 API 端点发出的 <st c="45877">curl</st> 命令示例，发往 <st c="45924">/recipes</st> 路由，用于获取已创建的 食谱列表：
$ curl -i 'https ://api.awscloudprojects.site/recipes'
HTTP/2 200
date: Wed, 03 Apr 2024 16:06:15 GMT
contente-type: application/json
contente-length: 2
server: nginx/1.18.0 (Ubuntu)
[]
无论你使用哪种方法，如果你尝试对 <st c="46214">GET</st> 请求 <st c="46233">/recipes</st> 端点，你应该会收到一个空对象，因为你还没有创建任何食谱，并且会收到一个 <st c="46333">200</st> 成功状态码，这证明了 你的 API 正常工作。
测试和探索前端
对于最终的测试，你将探索前端应用程序，并确保你在 <st c="46554">需求</st> 部分中定义的所有功能 按预期工作。
要访问你的前端，你需要进行以下操作：
-
进入 CloudFront 控制台。
-
选择您用 CloudFormation 堆栈创建的分发。 （如果您有多个分发，并且不确定哪一个是由 堆栈创建的，请打开 CloudFormation 服务，转到您之前创建的堆栈，并检查输出值
<st c="46950">CloudFrontDistributionId</st>）。 -
复制分发的 URL（它应该遵循 结构
<st c="47042">https://XXXXXX.cloudfront.net/</st>）。 -
如果您愿意，您也可以从
<st c="47188">CloudFrontDistributionUrl</st>中获取该值。 -
如果您复制并粘贴 URL 到浏览器中，您应该能够访问您新创建的应用程序并在 用户 和 管理员 页面之间导航。 如果您尝试访问 管理员 页面，您应该获得与 图 3**.25相同的体验。
图 3.25 – 食谱分享应用程序管理页面
因为您还没有创建任何食谱，所以列表应该是空的，请尝试创建一些食谱，并尝试查看 管理员 和 用户 页面之间的体验，以确保满足正确的功能需求。 。
如果您选择了选项 1，您应该能够看到预期的添加、删除和列出的食谱，但对于选项 2，还有一些额外的步骤 需要执行。
在浏览器中启用 HTTP 通信（仅限选项 2）
尽管 安全性始终是一个关注点，现代浏览器已经提供了保护措施，使在互联网上保持安全姿态更加容易。 在本例中，我们使用的是 Google Chrome，但其他浏览器如 Mozilla Firefox 也适用。
如果您仔细观察，在我们的 URL 左侧有一个警告显示为 不安全，如 图 3**.26。
图 3.26 – 食谱分享应用程序未安全警告
之所以会发生这种情况，是因为 HTTP 不是一个安全协议，而你的应用正在尝试对你的 API 发出 HTTP 请求。 此外，你的应用在 CloudFront 域中运行，正在通过 HTTP 向不同的域发出请求（一个 EC2 实例域），这通常 看起来很可疑。
如需深入故障排除，你可以在开发者工具中打开控制台，并查看我们收到的 以下错误：
图 3.27 – 控制台错误示例
仅限演示用途，你可以指示浏览器绕过其默认行为并接受 HTTP 连接，但需要强调的是，虽然这在本次练习中可以使用，但这并不是最佳实践，不应 常规执行此操作。
如果你想跳过这个阻塞，你可以进行如下操作： 以下操作：
-
点击红色的**不安全** 通知/查看网站信息 按钮，位于 URL 地址栏的左侧。
-
转到网站的**设置**。
-
滚动到**不安全内容**。
-
将**阻止（默认）** 更改为 允许。
这些指示适用于 Google Chrome，可能会根据版本或使用的浏览器有所不同。完成后，你的应用程序应该能够正常工作，请求将 被授权。
测试并探索你的 DynamoDB 表
最后一步是测试你 API 和 DynamoDB 中的数据层之间的集成，你的食谱数据存储在这里。 如果你想探索资源的创建和删除，请按照 以下步骤操作：
-
转到你的**DynamoDB** 页面，位于你的 AWS 账户中。
-
点击**探索项目** 在 左侧菜单上。
-
选择你的食谱表。
-
在你测试创建和删除食谱操作时，列出表中的项目。 这些操作应该在你的 DynamoDB 探索 项目 控制台中反映出来。
图 3**.28 展示了食谱在创建后如何存储在 DynamoDB 中。 作为练习，比较你的 DynamoDB 项目的结构与本章开始时定义的要求。
图 3.28 – 探索 DynamoDB 食谱表
第六节 – 清理
虽然 我们尝试使用 AWS 免费套餐中的服务，并且大多数采用的服务是无服务器的，并基于需求自动扩展，但如果你保持应用程序运行，未来可能会产生费用，因此本节解释了如何删除与你的 AWS 账户中与 本项目相关的所有资源。
使用 IaC 的主要优势之一，特别是在这个 CloudFormation 示例中，是简化了基础设施的提供 和删除。
要删除所有创建的资源，你只需要执行 两个步骤：
-
<st c="51993">frontend-chapter-3-</st>后面跟着一串随机字符（例如，<st c="52063">frontend-chapter-3-XXXXX</st>）。 -
点击 清空 – 这将删除你桶内的所有内容。
图 3.29 – 清空 S3 桶的过程
-
删除 CloudFormation 堆栈：
-
前往你的 AWS 账户中的 CloudFormation 控制台。
-
选择你创建的堆栈。
-
点击 “删除” 删除。
-
注意
如果你没有在列表中看到你的 CloudFormation 堆栈，请尝试更改右上角的区域，并选择你部署应用程序的区域。 之后，你应该按照所描述并展示在 图 3**.30中的删除过程进行操作。
图 3.30 – CloudFormation 堆栈删除
清理证书和 DNS 管理配置（选项 1）
如果你选择了 第一个选项并创建了 证书并配置了 DNS，那么你需要执行以下 附加步骤：
-
删除 证书：
-
进入你的 证书管理器 控制台。
-
选择你创建的证书。
-
点击 在 删除。
-
图 3.31 – 证书删除
注意
如果你没有在列表中看到你的证书，尝试更改右上角的区域，选择你部署应用程序的区域。 然后，你应该按照删除过程继续操作，具体步骤如 图 3**.31
-
清理 DNS：如果你想继续在 Route 53 中管理 DNS，你可以直接 删除 为你的 API 创建的记录：
-
进入你的 Route 53 控制台。
-
在左侧面板中选择 托管区域 。
-
选择你为 你的域名创建的托管区域。
-
选择 API 的记录。
-
点击 删除记录。
-
图 3.32 – DNS 记录清理
此外，如果你不想继续使用 Route 53 管理你的域名，删除 Route 53 中的托管区域，并更新域名注册商中的名称服务器，指向新的 DNS 服务。
未来工作
恭喜你，你 拥有一个完全功能的 Web 应用程序来存储和分享食谱！ 但是对于你开发的所有项目，必须时刻记住，你的架构总有改进的空间，并且你应该定期进行审查，以便理解哪些地方可以改进。 这正是你接下来要 做的事情。
使用安全协议
很显然，HTTP 不是一个好的选择。 因此，如果你遵循了选项 2，你可以专注的第一个改进是迁移到选项 1 并为 API 通信配置 HTTPS。
基础设施自动扩展
到目前为止，无论你选择了哪种选项，你都有一个 EC2 实例支持你的后台，但如果负载增加会发生什么？ 计算资源不足会带来不好的用户体验，并可能导致实例故障，那么你该如何应对 故障的实例呢？
以故障为前提进行架构设计是实现弹性应用程序的路径。 因此，始终是一个好习惯去问自己，假如这个组件失败会怎样？ 在我们的案例中，如果我们的 API 所在的 EC2 实例失败，比如由于负载过大，会发生什么？ 为了确保弹性和可扩展性，你应该 使用自动化 API 配置，举个例子，可以使用 AWS 自动扩展 组 (ASGs)。
ASG 会根据定义的指标自动配置和终止 EC2 实例，比如平均 CPU 使用率。 你可以创建一个 AMI，它是一个预配置的虚拟机镜像，包含运行后台所需的所有配置和代码，并将其与 ASG 关联。 为了限制需要配置的实例数量，你可以设置最小和最大实例数，比如四个实例作为上限，确保永远不会超过这个限制。 通过监控实例状态，ASG 将在指标超过阈值时从 AMI 启动新的实例，并在指标低于 另一个阈值时终止实例。
这种方法通过替换不健康的实例和根据定义的指标进行自动扩展，提供了自愈能力，使 API 具备弹性 和可扩展性。
托管服务和 CI/CD
在 本章中，你体验了一个构建过程，涉及到在本地更改应用程序，构建并将文件复制到 S3 桶，这个过程非常容易出错。 此外，尽管到目前为止，你是唯一一个在应用程序上工作的开发者，但通常会有一个开发者团队共同协作，而当前的部署方式对于团队协作 来说具有挑战性。
AWS 提供了一个 服务，已管理好托管和 持续集成与持续部署 （CI/CD）流水线 ，它简化了构建、部署和托管现代单页应用（如你的食谱共享应用）的过程。 通过 Amplify，你可以连接代码仓库（例如 GitHub、AWS CodeCommit），并配置一个 CI/CD 流水线，能够在代码提交到仓库时自动构建、测试和部署应用。 对于托管，Amplify 利用 S3 和 CloudFront，类似于你当前的设置，因此你仍将从前面提到的所有 AWS 服务 优势中受益。 本章中会有更多相关内容。
身份验证
当你 向你的 API 发出请求时，你无需使用任何身份验证机制。 这意味着世界上任何人，只要拥有端点 URL，都可以发出请求、创建食谱并删除它们，这显然不理想。 在应用程序中实现身份验证对于确保数据的安全性和隐私至关重要，尤其是当涉及到 敏感数据时。
Amazon Cognito 是一个 AWS 服务，简化了将用户身份验证和授权添加到你的 web 和移动应用程序中的过程。 它充当用户身份提供者，允许你管理用户注册、登录和访问控制等功能。 下一章将进一步介绍相关内容。 敬请期待。
日志记录与监控
你只能对 你所衡量的内容采取行动，而在当前架构下，你无法看到应用程序中发生了什么。 你获得了多少次访问？ 你的用户位于哪里？ 过去 24 小时内是否出现了错误？
虽然 有时监控与日志记录可以互换使用，但它们是两个不同的概念，尽管是互补的。 日志记录 涉及记录应用程序中的历史事件、错误和活动，而 监控 则侧重于收集和分析有关性能、健康状态和 运行状态的数据。
作为 AWS 服务组合的一部分，你可以找到 CloudWatch，这是一个综合性的监控和日志解决方案，分为两个服务：CloudWatch Logs 用于日志记录和 CloudWatch Metrics 用于监控。 通过 利用这些服务，我们可以深入了解应用的行为、性能 和健康状况。
因此，作为改进，你可以将应用日志发送到 CloudWatch Logs，并且创建一个包含所有应用组件的监控仪表板，包括 CloudFront、S3、EC2 和 DynamoDB。 这将为你提供应用程序的整体视图，并为你提供分析的工具。
缓存
食谱 是一次创建，多次访问，并且不常变更，非常适合进行数据缓存。 如果你分析当前的设置，每次用户刷新页面或选择一个食谱时，都会发送请求并在数据库中执行读取操作，这在性能和 成本角度上都可以改进。
DynamoDB 加速器 (DAX) 是一个 完全托管的、集群化的内存缓存服务，用于 DynamoDB。 它旨在通过缓存频繁的查询和响应来提高 DynamoDB 的读取性能。 DAX 兼容 DynamoDB API，这意味着你可以将其与现有应用集成，而无需进行重大代码修改。 但这并不是 唯一的选择。
对于缓存层，你可以使用任何缓存技术，比如 Redis 或 Memcached，它们作为托管解决方案可以在 Amazon ElastiCache 中使用。
这些只是你在应用中可能找到的许多未来工作示例中的六个，因此我们向你提出的挑战是，尝试寻找其他选项，并始终问自己：我能改进我当前的架构吗？
我们将以一个改进版本的应用为例，考虑之前提到的未来工作，如 图 3**.33 所示。
图 3.33 – 最终架构
与 第*3**.6*图中展示的初始架构相比，这个新版本已经包含了部分未来计划的工作。 在顶部，CloudWatch 将提供监控功能，帮助你更好地了解应用程序的运行状况，了解过去发生的错误，最重要的是，在事件发生时能够及时采取行动。 如本章所述，这个架构遵循了安全最佳实践，并且仅允许 HTTPS 作为应用程序的访问协议。 为此，你在 Route 53 中配置了你的域名，并颁发了证书来证明你对该域名的所有权。
对于数据层，考虑到食谱通常是稳定的，发布后不会有太多更改，你选择了 DAX 作为缓存层，以提高 用户体验，性能提升达到最多 10 倍——从毫秒级降低到微秒级。 以便获取一个项目。
总结
在这一章中，你实践了在 第一章 中介绍的架构设计框架。 与前一章相比，你现在拥有了一个更强大的应用程序，能够处理动态内容，最终你得到了一个功能齐全的食谱分享应用，可以作为任何项目的起点并应用于你 想到的任何项目。
你有机会体验了将单页面应用（SPA）构建并部署到 AWS 的过程，使用了 S3 和 CloudFront，这使得应用能够服务数千个 用户。
你探索了新的 AWS 服务，如 DynamoDB、EC2 和 ALB。 你还学习了使用 CloudFormation 进行基础设施即代码（IaC）的强大功能。 此外，你还看到了如何配置带有自定义域名的 HTTPS，并与 ALB 关联，以及为什么不推荐使用 HTTP。
最后，你探讨了应用程序可能的改进方向，使其更具可扩展性、成本效益和安全性。
在下一章中，你将把当前的食谱分享应用提升到一个新的水平，并了解如何仅使用 无服务器技术来架构应用程序。
扫一扫
1014
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
