EDUCBA-AWS-ElaxticSearch-CICD-笔记-全-

EDUCBA AWS ElaxticSearch CICD 笔记（全）

001：Elasticsearch航班监控项目导论 🛫

在本节课中，我们将学习一个关于在COVID-19疫情期间进行航班监控的案例研究。我们将了解这个项目的背景、目标、所需技能以及实施步骤。

我们知道，由于这场疫情，航空业遭受了巨大损失。为了获取特定日期的航班信息，航班监控对航空业来说变得非常必要。

项目难度与先决条件 🎯

上一节我们介绍了项目的背景，本节中我们来看看完成这个项目需要具备哪些基础。

本项目的难度级别为初学者。要完成此项目，你应该具备以下基础知识：

  • Elasticsearch 的基本知识。
  • Kibana 的基本知识。
  • 基本的 Linux 命令。

因为这个案例研究是在 Elastic Stack（通常称为 ELK Stack）中实现的，即 Elasticsearch、Logstash 和 Kibana。对于我们的案例研究，我们只需要：

  • Elasticsearch 作为 NoSQL 数据库。
  • Kibana 用于数据可视化。

同时，基本的 Linux 命令也是必需的，因为 Elasticsearch 和 Kibana 的安装以及它们之间的连接配置都是通过 Linux 命令完成的。

课程目标 🎯

在了解了先决条件后，接下来我们明确一下通过本课程你将能学到什么。

参与者将能够学习到各种 Elasticsearch API，例如 POST、DELETE、GET 等。这些 API 以 JSON 格式实现，用于存储数据。我们将在 NoSQL 数据库中学习所有这些 API。

具体目标包括：

  1. 在 Elasticsearch 中创建索引和文档：在我们的案例中，参与者将接触到 NoSQL 这种非关系型数据库。它比 SQL 数据库更简单，因为相关数据不需要在表之间拆分。Elasticsearch 使用基于组件的 NoSQL 数据库，它以 JSON 格式存储数据。
  2. 使用 Kibana 以表格、饼图和直方图的形式进行数据可视化：我们将使用 Kibana 来实现通过各种 API 存储的数据，并通过饼图、表格、直方图等形式进行数据可视化。虽然还有其他可视化形式如图形、地图、图表等，但我们将主要使用上述几种。

项目要求与目标学员 👥

我们已经明确了学习目标，现在来看看实施项目的具体要求和适合学习本课程的人群。

以下是项目的要求或先决条件：

  • 在 Linux 系统中安装 Elasticsearch 和 Kibana。
  • 具备 JSON、Linux 命令 和 NoSQL 概念 的基础知识。
  • 互联网上提供了完整的指南以及 Linux 命令，你可以按照步骤在 Linux 系统中操作。这部分内容可以使用 AWS Cloud Linux 实例来完成。

目标学员是任何愿意学习 NoSQL 数据库的人。在项目结束时，你将获得以下技能组合：

  • NoSQL 数据库的实践操作经验：你将能够在 NoSQL 数据库上工作，并理解如何通过索引直接输入数据，以及如何以 JSON 形式使用 API。
  • 使用 Kibana 创建仪表板：这些仪表板在一个页面上包含所有的可视化内容。Elasticsearch 的默认端口是 9200，Kibana 的默认端口是 5601。

案例研究概述 📊

最后，让我们详细了解一下我们将要实施的具体案例。

航空当局希望在 COVID 19 大流行期间监控航空公司及其运营的航线。本案例研究将涵盖以下场景，我们将按步骤逐一进行：

  1. 数据准备：我们拥有各种航空公司及其运营航线的样本数据。
  2. 数据存储：使用 API 将数据以 JSON 文档的形式存储在 Elasticsearch 中。
  3. 数据可视化：存储在 Elasticsearch 中的数据将通过 Kibana 以交互式仪表板的形式进行可视化。
  4. 项目部署：最后，该案例研究将使用 AWS 云服务部署到互联网上。

本节课中，我们一起学习了“COVID-19疫情期间航班监控”案例研究的导论部分。我们明确了项目的背景、学习目标、所需的先决条件（Elasticsearch, Kibana, Linux 基础），以及项目的实施流程（从数据准备到最终部署）。接下来，我们将开始动手搭建环境并深入 Elasticsearch 的核心操作。

002：环境配置 🛠️

在本节课中，我们将学习如何为Web开发项目配置一个AWS Elastic Beanstalk环境。我们将创建一个应用程序和环境，并了解其核心配置选项。

概述

我们将登录AWS管理控制台，创建一个名为“web-dev”的Elastic Beanstalk应用程序和环境。我们将选择PHP平台，并配置一个单实例环境来部署示例应用程序。过程中会涉及平台选择、实例配置、安全设置和监控选项的简要说明。

创建应用程序与环境

首先，我们需要登录AWS账户并导航到Elastic Beanstalk服务。

在服务搜索栏中，可以找到Elastic Beanstalk。

进入服务后，我们将开始创建应用程序。

我们将创建一个应用程序，并相应地设置环境。我们将此应用程序命名为“web”。可以在此处添加键值对以标识资源，但本次演示中不添加。

配置平台与实例

接下来，我们需要选择平台。Elastic Beanstalk支持多种平台，例如.NET、Go、Java、PHP、Python等。本次我们将部署一个PHP Web应用程序，因此选择PHP。请确保选择支持的最新版本。其他设置将使用默认值。

我们选择部署示例应用程序，以验证环境是否正常工作。本课程后续将通过CI/CD管道部署代码。

在配置面板中，可以看到多个预设选项。以下是主要配置选项：

  • 预设配置：默认选择单实例。也可以选择多可用区实例以实现高可用性，或使用按需/Spot实例，以及自定义配置。本次演示选择单实例。
  • 平台：已选择运行在64位Amazon Linux上的PHP 7.4。
  • 其他配置：可以配置日志（如CloudWatch Logs）、实例类型、存储卷（如EBS卷类型和大小）等。本次演示保留默认设置。
  • 容量：可以在此处更改容量设置，例如实例类型和最小/最大实例数量。还可以配置负载均衡器。
  • 滚动部署：当前已禁用。如果底层有多个EC2实例，可以设置分批部署策略（例如每次更新50%的实例）。由于当前只有一个实例，默认策略为“一次全部部署”。

我们使用默认的滚动更新设置。然后进入安全部分。

安全与监控设置

系统会自动创建一个Elastic Beanstalk服务角色，用于访问实例和执行操作。此外，还会创建EC2密钥对。如果想使用自己的EC2密钥对，而不是让Elastic Beanstalk创建，可以在此选择。本次演示使用默认选项。

在监控部分，当前启用了增强型健康报告系统，但未启用日志流式传输。可以在此配置托管更新，例如设置每周一11:00 UTC的更新窗口和实例替换计划。本次演示不启用这些选项。

可以在此处输入电子邮件地址以接收环境活动的通知。默认情况下，环境不属于任何VPC，但可以将其添加到VPC并选择子网。本次演示使用默认VPC。

由于我们将部署一个简单的静态网站，不需要数据库，因此不配置数据库。可以为资源添加标签以便识别，但本次演示不添加。

启动环境创建

现在，我们将应用程序名称更改为“web-dev”，以标识为开发环境。稍后我们还将创建一个生产环境。所有配置确认无误后，点击“创建应用程序”。

系统开始配置并同时创建名为“web-dev-env”的环境。应用程序名为“web-dev”。现在检查应用程序状态。

环境正在创建中。系统首先创建安全组，然后创建存储桶，并为网站分配弹性IP。一旦环境创建完成，我们还将获得一个DNS名称来访问网站。让我们等待环境状态变为“就绪”。

验证创建的资源

环境创建期间，我们可以检查已创建的资源。可以看到一个标记为“web-dev”环境的EC2实例正在运行并初始化。同时，还创建了一个S3存储桶，其中包含一些Elastic Beanstalk配置文件。此外，还创建了一个安全组，其入站规则允许通过HTTP（端口80）访问，出站规则默认为允许所有流量。

现在检查环境状态，网站应能正常工作。

这表明我们的部署和配置是成功的。我们已经成功创建了环境和应用程序（目前是示例应用程序）。

检查环境配置与日志

现在，我们可以检查环境的配置。所有配置均与我们设置的一致，包括软件设置、容量（单实例）、负载均衡器（未配置）、滚动更新和部署设置。我们没有配置通知电子邮件，监控设置也保持不变。

在日志部分，可以请求并下载日志以查看详细过程。日志记录了所有操作，例如环境创建启动、S3存储桶创建、安全组创建、弹性IP分配、等待EC2实例启动、实例命名以及应用程序URL生成。几分钟内，环境就绪且URL可访问。

监控仪表板显示健康状态良好，可以查看CPU利用率（约60%）、最大网络流入（29 KB）和流出（24 KB）等信息。我们尚未定义任何警报。在“托管更新”和“事件”部分，可以查看所有已发生的事件记录。

至此，环境配置完成，我们可以继续进行项目后续步骤。

总结

本节课中，我们一起学习了如何在AWS Elastic Beanstalk上配置一个基础的Web开发环境。我们创建了一个PHP应用程序，选择了单实例配置，并了解了安全组、存储桶、监控等核心资源的自动创建过程。成功部署示例应用后，我们还查看了环境配置详情和操作日志，为后续集成CI/CD管道奠定了基础。

003：开发环境配置 🛠️

在本节课中，我们将学习如何为我们的网站配置一个本地开发服务器。具体来说，我们将安装和配置 XAMPP 服务器，这是一个集成了Apache、MySQL、PHP等组件的流行开发环境。通过本教程，你将能够搭建一个本地环境来运行和测试你的静态网站。

概述

我们将从下载和安装XAMPP开始，然后介绍其控制面板的基本功能，并重点讲解如何配置Apache服务器以托管我们的网站文件。最后，我们会验证网站是否能够成功访问。

下载与安装XAMPP

首先，我们需要获取XAMPP的安装程序。你可以通过访问其官方网站或通过搜索引擎找到下载链接。

以下是下载步骤：

  • 访问XAMPP官方网站或通过搜索引擎找到下载页面。
  • 根据你的操作系统（Windows、Linux或Mac）选择对应的版本进行下载。
  • 下载完成后，你会得到一个安装文件（例如，Windows系统是 .exe 文件）。

安装过程非常简单。只需双击下载的安装文件，并按照屏幕上的提示进行操作即可完成安装。为了节省时间，本教程将跳过具体的安装步骤演示。

认识XAMPP控制面板

安装完成后，启动XAMPP控制面板。你会看到一个类似下图的界面，其中列出了可管理的服务，如 Apache、MySQL、FileZilla 和 Tomcat。

在安装时，你可以选择只安装需要的组件。例如，对于一个静态网站，我们主要需要 Apache 服务器。如果网站是动态的（例如使用了PHP和数据库），则还需要 MySQL 和 PHP 组件。

配置Apache服务器

上一节我们启动了XAMPP控制面板，本节中我们来看看如何配置Apache服务器以托管我们的网站。

Apache的主要配置文件是 httpd.conf。这个文件包含了服务器根目录、监听端口（默认为80）、日志路径等重要设置。你可以用文本编辑器打开这个文件进行查看和修改。

# 示例：在 httpd.conf 中修改网站根目录
# DocumentRoot "C:/xampp/htdocs"
# <Directory "C:/xampp/htdocs">

如果你想深入了解Apache的配置，可以仔细阅读这个文件中的各项参数。

部署与访问网站

现在，让我们将网站文件放到正确的位置并尝试访问它。

首先，我们需要启动Apache服务。在XAMPP控制面板中，找到Apache模块，点击旁边的 “Start” 按钮。启动成功后，你会看到Apache运行在端口80上。

接下来，我们需要放置网站文件。XAMPP默认的网站根目录是 C:\xampp\htdocs\（Windows系统）或 /opt/lampp/htdocs/（Linux系统）。你可以通过控制面板的 “Explorer” 按钮快速打开这个目录。

请将你的网站文件（例如 index.html）放入这个 htdocs 文件夹中。例如，我放置了一个简单的 index.html 文件。

现在，打开你的网页浏览器，在地址栏输入 http://localhost 或 http://127.0.0.1。如果配置正确，你将看到你的网站页面，如下图所示。

管理服务器与查看日志

XAMPP控制面板提供了便捷的管理和监控功能。

服务管理：你可以随时通过控制面板上的按钮启动或停止Apache服务。请记住，Apache服务必须处于运行状态，网站才能被访问。如果停止服务并刷新浏览器，你将看到连接错误的页面。

查看日志：调试网站时，查看日志非常有用。你可以通过控制面板的 “Logs” 按钮访问Apache的访问日志和错误日志，以排查问题。

其他工具：

  • Shell：打开一个命令行窗口，可以直接在服务器环境中执行命令。
  • Explorer：快速打开XAMPP的安装目录。
  • Services：查看或管理Windows系统后台运行的服务。
  • Netstat：查看服务器正在监听的端口和网络连接状态。

总结

本节课中我们一起学习了如何为本地开发配置XAMPP环境。我们完成了从下载安装、启动Apache服务、部署网站文件到最终通过浏览器访问网站的全过程。关键点在于：确保Apache服务已启动，并将网站文件放置在正确的 htdocs 目录下。这个本地环境是进行网站开发和测试的重要基础。

感谢你的学习。

004：构建与配置文件 🛠️

在本节课中，我们将学习如何准备一个简单的网页应用代码，以及用于在AWS Elastic Beanstalk上实现持续集成/持续部署（CI/CD）的配置文件和脚本。

上一节我们介绍了CI/CD的基本概念，本节中我们来看看具体的代码和配置文件是如何构成的。

前端代码：index.html

我们的应用是一个简单的静态网页。以下是其核心HTML代码：

<!DOCTYPE html>
<html>
<head>
    <title>简单部署</title>
    <style>
        body {
            color: #333;
            background-color: #f4f4f4;
            font-family: Arial, sans-serif;
            font-size: 16px;
        }
        h1 {
            font-size: 500%;
            font-weight: normal;
            margin-bottom: 0;
        }
        h2 {
            font-size: 200%;
            font-weight: normal;
            margin-bottom: 0;
        }
    </style>
</head>
<body>
    <h1>欢迎来到EDUCBA</h1>
    <h2>感谢组织本教程</h2>
    <p>恭喜你已成功实现CI/CD。请持续关注EDUCBA以获取更多实时解决方案。</p>
</body>
</html>

这个文件定义了一个包含标题和欢迎信息的网页。你可以根据自己的需求修改其中的文本和样式。

部署脚本与依赖

当代码通过CI/CD流程部署到服务器（例如Linux）时，需要确保Web服务器（如Apache）已安装并运行。以下是相关的命令脚本。

以下是部署前需要执行的命令列表：

  • yum install -y httpd：安装Apache Web服务器（在基于RHEL的系统上）。
  • service httpd start：启动Apache服务。
  • service httpd stop：停止Apache服务（用于处理应用重启等场景）。

构建配置文件：buildspec.yml

为了指导CI/CD管道（如AWS CodeBuild）按顺序执行任务，我们需要一个构建规范文件。

以下是buildspec.yml文件的核心内容：

version: 0.2
os: linux
files:
  - source: index.html
    destination: /var/www/html/
hooks:
  before_install:
    - yum install -y httpd
    - service httpd start
  application_stop:
    - service httpd stop

这个YAML文件定义了构建过程：

  1. 版本与环境：指定构建规范的版本和操作系统。
  2. 文件复制：将源代码中的index.html文件复制到服务器的/var/www/html/目录下。
  3. 构建钩子：
    • before_install：在安装应用前，先安装并启动Apache服务器。
    • application_stop：如果应用需要停止（例如更新时），则先停止Apache服务器。

总结

本节课中我们一起学习了部署到AWS Elastic Beanstalk所需的核心文件。
我们首先分析了一个简单的HTML前端页面，然后了解了确保Web服务器运行的安装脚本，最后详细解读了指导整个自动化部署流程的buildspec.yml构建配置文件。
在接下来的课程中，我们将实际使用这些文件，通过CI/CD管道来完成部署。

005：配置Git仓库

在本节课中，我们将学习如何为持续集成/持续部署（CI/CD）流水线配置第一个组件：AWS CodeCommit。我们将创建一个Git仓库，并配置本地环境以连接到此仓库，为后续的代码推送和自动化部署做好准备。

配置AWS CodeCommit仓库

上一节我们完成了项目编码，本节中我们来看看如何将代码托管到AWS CodeCommit服务中。AWS CodeCommit是一个完全托管的源代码控制服务，用于托管安全的Git仓库。

首先，我们需要在AWS控制台中创建一个CodeCommit仓库。

  1. 在AWS控制台搜索并进入CodeCommit服务。
  2. 点击“创建仓库”按钮。
  3. 为仓库命名，例如 VbRepo。
  4. 添加描述，例如 CI/CD Demo。
  5. 可以按需添加标签。
  6. 由于这是一个PHP项目，无需启用“Amazon CodeGuru Reviewer for Java”选项。
  7. 点击“创建”按钮。

至此，我们的代码仓库已在CodeCommit中创建完成。

配置本地Git环境

现在我们需要配置本地环境以访问这个远程仓库。有多种连接方式，例如HTTPS、SSH或HTTPS（GRC）。在本教程中，我们将使用HTTPS方式。

以下是配置本地环境所需的步骤：

第一步：安装Git客户端
您必须使用支持Git版本1.7.9或更高版本的客户端。请根据您的操作系统下载并安装Git。

第二步：配置IAM用户权限
您的IAM用户需要拥有访问CodeCommit的权限。这通常通过附加一个托管策略来实现。

  1. 进入AWS IAM服务，选择您的用户。
  2. 点击“添加权限”。
  3. 选择“直接附加现有策略”。
  4. 搜索并选择策略，例如 AWSCodeCommitPowerUser 或 AWSCodeCommitFullAccess。

第三步：生成Git凭证
为了通过HTTPS连接，您需要为IAM用户生成Git凭证。

  1. 在IAM控制台进入您的用户详情页。
  2. 切换到“安全凭证”选项卡。
  3. 在“HTTPS Git凭证 for AWS CodeCommit”部分，点击“生成凭证”。
  4. 下载并保存生成的用户名和密码。

克隆远程仓库到本地

完成上述配置后，我们就可以将远程仓库克隆到本地了。

首先，在本地创建一个项目文件夹并初始化Git。

# 创建项目文件夹
mkdir demo
cd demo

# 初始化Git仓库
git init

接下来，使用之前从CodeCommit仓库页面复制的HTTPS URL和生成的Git凭证进行克隆。

# 克隆远程仓库（请替换为您的实际URL）
git clone https://git-codecommit.<region>.amazonaws.com/v1/repos/VbRepo

系统会提示您输入用户名和密码，请使用生成的Git凭证。

总结

本节课中我们一起学习了如何为CI/CD流水线配置源代码管理。我们首先在AWS CodeCommit中创建了一个Git仓库，然后配置了本地Git环境所需的权限和凭证，最后成功将远程仓库克隆到了本地。这为后续将代码推送到仓库并触发自动化构建和部署流程奠定了基础。

006：AWS CodeCommit 代码仓库操作指南 🗂️

在本节课中，我们将学习如何将本地代码推送到 AWS CodeCommit 代码仓库。这是实现持续集成与持续部署流程的第一步，我们将通过实际操作，完成从初始化本地 Git 仓库到将代码成功推送至云端仓库的全过程。

创建并初始化本地目录

首先，我们需要在本地计算机上创建一个新的文件夹，用于存放项目代码。我们将在此文件夹内初始化 Git 仓库。

以下是具体操作步骤：

  1. 创建一个名为 demo 的新文件夹。
  2. 使用终端或命令行工具进入该文件夹。
  3. 执行 git init 命令来初始化一个空的 Git 仓库。

初始化完成后，我们需要配置 Git 的用户信息，以便在提交代码时进行身份标识。

配置 Git 用户信息

上一节我们创建了本地仓库，本节中我们来配置必要的用户信息。这包括用户名和邮箱地址，它们会记录在每一次代码提交中。

配置命令如下：

git config --global user.name "EDUCBA Training"
git config --global user.email "educba@example.com"

克隆远程仓库到本地

配置好用户信息后，接下来我们需要将 AWS CodeCommit 上的远程仓库克隆到本地。这建立了本地与云端仓库的连接。

操作步骤如下：

  1. 在 AWS CodeCommit 控制台找到并复制仓库的 HTTPS 克隆 URL。
  2. 在本地终端执行 git clone <仓库URL> 命令。
  3. 根据提示输入 AWS IAM 用户的访问凭证（用户名和密码）进行身份验证。

克隆成功后，你会看到一个警告，提示克隆了一个空仓库。这是正常的，因为我们尚未向远程仓库推送任何代码。

添加代码并提交到本地仓库

现在，我们已经将远程仓库克隆到本地。本节中我们来看看如何将项目代码添加到本地仓库并进行提交。

以下是操作流程：

  1. 将你的项目代码文件复制到克隆下来的本地仓库文件夹中。
  2. 使用 git add . 命令将所有新文件添加到 Git 的暂存区。
  3. 使用 git status 命令可以查看已暂存等待提交的文件列表。
  4. 使用 git commit -m “Initial commit” 命令将暂存区的文件提交到本地仓库，并附上提交信息。

将本地提交推送到远程仓库

代码已提交到本地仓库，最后一步是将其同步到 AWS CodeCommit 远程仓库，以便团队协作和后续的 CI/CD 流程。

执行以下命令进行推送：

git push origin master

此命令会将本地 master 分支的提交推送到名为 origin 的远程仓库。

推送完成后，你可以刷新 AWS CodeCommit 控制台的代码浏览页面。之前空白的仓库现在应该显示了你刚刚推送的所有代码文件，这标志着本地代码已成功托管至云端。

本节课中我们一起学习了使用 Git 命令行工具操作 AWS CodeCommit 的核心步骤：从初始化本地仓库、配置用户、克隆远程仓库，到添加代码、提交更改，最终将代码推送至云端。掌握这些操作是构建自动化部署流水线的坚实基础。

007：P07 01_02_03_代码流水线配置 🚀

在本节课中，我们将学习如何配置一个完整的CI/CD（持续集成/持续部署）流水线。我们将使用AWS CodePipeline，将存储在AWS CodeCommit仓库中的代码，自动部署到AWS Elastic Beanstalk环境中。

上一节我们介绍了如何将代码提交到AWS CodeCommit仓库。现在，我们将创建一个流水线来自动化构建和部署过程。

创建流水线

首先，我们需要在AWS控制台中创建一条新的流水线。

  1. 在AWS控制台搜索并进入 CodePipeline 服务。
  2. 点击 创建流水线 按钮。
  3. 为流水线命名，例如 WebDeploymentPipeline。
  4. 在“服务角色”部分，选择 允许CodePipeline创建服务角色。这将由AWS自动创建一个拥有必要权限的角色。
  5. 其他高级设置（如用于存储构件的S3桶和加密方案）保持默认即可。
  6. 点击 下一步。

配置源代码阶段

现在，我们需要指定代码的来源。

  1. 在“源提供商”中，选择 AWS CodeCommit，因为我们的代码存储在那里。
  2. 选择之前创建的仓库（例如 WebRepo）和分支（例如 master）。
  3. 在“更改检测选项”中，选择 使用CloudWatch事件。这样，每当有新的代码提交到仓库时，流水线就会自动触发。
  4. 点击 下一步。

跳过构建阶段

由于我们的项目是一个基本的静态网站，不需要编译或构建过程，因此可以跳过此阶段。

  1. 在“构建提供商”步骤，直接点击 跳过构建阶段。
  2. 确认弹出的警告信息。

配置部署阶段

接下来，我们设置将代码部署到哪里。

  1. 在“部署提供商”中，选择 AWS Elastic Beanstalk。
  2. 确保区域与你的资源所在区域一致（例如 美国东部（弗吉尼亚北部））。
  3. 选择对应的Elastic Beanstalk 应用程序名称（例如 WebDeploy）和 环境名称（例如 WebDevEnv）。
  4. 点击 下一步。

审核并创建

在此步骤，你可以回顾流水线的所有配置。

  1. 仔细检查所有设置，确保源代码、部署目标等信息正确无误。
  2. 确认无误后，点击 创建流水线。

流水线创建成功后，它会立即检测CodeCommit仓库中的代码并开始执行首次部署。你可以在CodePipeline控制台看到部署进度。

验证部署结果

部署完成后，你可以通过Elastic Beanstalk环境的URL访问你的网站。如果部署成功，网站内容将从原始的AWS示例页面，更新为你提交到CodeCommit仓库中的代码。

管理流水线

创建完成后，你可以在CodePipeline控制台进行以下操作：

  • 查看详情：点击流水线名称，查看其结构和当前状态。
  • 检查历史记录：在“历史记录”选项卡中，查看所有过往的执行记录、状态（成功/失败）以及详细的执行日志。
  • 修改配置：在“配置”选项卡中，可以更新源代码、部署目标等设置。
  • 查看构件：了解流水线生成的构件存储在哪个S3桶中。
  • 管理权限：查看流水线使用的服务角色和策略。

本节课中，我们一起学习了如何配置一个连接AWS CodeCommit和Elastic Beanstalk的完整CI/CD流水线。我们设置了源代码自动检测、跳过了不必要的构建阶段，并成功实现了代码的自动部署。通过这条流水线，任何提交到主分支的代码变更都将自动、快速地被部署到线上环境，极大地提升了开发效率。

在接下来的课程中，我们将为流水线配置通知功能，以便在部署发生时通过邮件等方式及时获知状态，从而更好地监控我们的AWS环境。

008：部署通知 📧

概述

在本节课中，我们将学习如何为AWS CodePipeline配置部署通知。通过使用AWS Simple Notification Service (SNS)，我们可以设置邮件提醒，以便在代码部署的各个阶段（无论是成功还是失败）都能及时收到通知。

在上一节中，我们介绍了如何将源代码集成到AWS CodeCommit，并通过CodePipeline将其部署到AWS Elastic Beanstalk。本节中，我们来看看如何为这个流程添加通知功能。

创建通知规则

以下是创建通知规则的步骤。

首先，在已创建的CodePipeline（例如 web-deployment）中，找到并点击“创建通知规则”的选项。

  1. 命名规则：为通知规则指定一个名称，例如 web-notify。
  2. 选择详细级别：选择“完整”级别，以便获取所有操作细节的通知。
  3. 选择通知事件：选择您希望接收通知的事件类型。这包括：
    • 操作执行：成功、失败、取消、已开始。
    • 阶段执行：已开始、成功、已恢复、已取消、失败。
    • 管道执行：失败、已取消、已开始、已恢复、成功、已取代。
    • 手动批准：已开始、已批准、已拒绝、已覆盖、已需要。

注意：手动批准功能将在后续课程中介绍，目前可以全选以确保收到所有相关活动的通知。

配置SNS主题作为通知目标

接下来，我们需要创建一个目标来接收这些通知。我们将使用AWS SNS服务创建一个主题，并订阅我们的邮箱。

以下是创建SNS主题和订阅的步骤。

  1. 导航到AWS管理控制台的 Simple Notification Service (SNS) 页面。
  2. 点击“创建主题”。
  3. 选择主题类型为“标准”。
  4. 为您的主题命名，例如 web-notify-topic。显示名称是可选的，可以填写相同名称。
  5. 配置其他选项（可根据生产环境需求调整，本教程使用默认设置）：
    • 加密：对于非机密信息，可暂时保持禁用。
    • 访问策略：保持默认设置，仅允许主题所有者发布消息。
    • 重试策略：默认配置为在消息传递失败时重试3次，每次延迟20秒。
    • 交付状态日志记录：可选功能，本教程暂不启用。
    • 标签：可选，用于资源管理。
  6. 点击“创建主题”。

主题创建完成后，需要为其添加订阅者。

  1. 在新创建的主题详情页，点击“创建订阅”。
  2. 选择协议为 Email。
  3. 在“端点”字段中，输入您希望接收通知的邮箱地址。
  4. 点击“创建订阅”。

订阅创建后，您指定的邮箱会收到一封确认订阅的邮件。必须点击邮件中的确认链接，订阅才会生效。

在CodePipeline中关联SNS主题

现在，我们需要回到CodePipeline，将创建好的SNS主题设置为通知目标。

  1. 返回CodePipeline的“通知规则”创建页面。
  2. 在“目标”部分，选择您刚刚创建的SNS主题（例如 web-notify-topic）。
  3. 点击“提交”，完成通知规则的创建。

测试通知功能

为了验证通知配置是否生效，我们可以触发一次新的部署。

以下是测试步骤。

  1. 前往您的AWS CodeCommit代码仓库。
  2. 修改项目中的某个文件（例如 index.html），例如更新一些文本内容。
  3. 提交并推送这次代码更改。
  4. CodePipeline会自动检测到代码变更并开始执行部署流程。

此时，请检查您的邮箱。您应该会收到来自SNS的多封邮件，分别对应管道执行开始、源代码阶段成功、部署阶段开始、部署成功等各个事件。这证明通知系统已成功配置并正常工作。

总结

本节课中，我们一起学习了如何为AWS CodePipeline配置部署通知。我们通过创建SNS主题和订阅，将管道执行的关键事件（如成功、失败、状态变更）以邮件形式通知给相关人员。这确保了开发团队能够及时了解部署状态，是构建健壮的CI/CD流程中的重要一环。

009：部署持续通知 📨

在本节课中，我们将学习如何为AWS CodePipeline配置持续通知。通过设置通知，您可以在代码提交、构建和部署的每个阶段自动收到更新，从而无需手动登录控制台即可跟踪项目状态。

上一节我们完成了CI/CD管道的搭建，本节中我们来看看如何配置通知功能，以便及时了解部署动态。

现在，检查当前操作并前往相应页面。

检查其状态。确认是否显示索引文件已被修改。

现在需要提交此更改。然后将其推送到AWS CodeCommit仓库。再次执行操作。

执行提交命令。需要提供提交信息。

git commit index.html -m "updated index.html"

现在代码已提交，文件是index.html。接着将代码从本地主分支推送到远程主分支。

git push origin master

检查此处的问题。似乎我们刚刚执行了git push，但尚未指定文件。需要先使用git commit命令提交文件index.html。

git commit index.html -m "update the index process"

这就是提交命令。这里的-m代表提交信息，没有信息则无法提交，请确保为每次提交添加信息。

由于已提交，现在执行推送。

git push origin master

现在代码正在更新，AWS代码正在提交。可以看到，代码仓库已更新。

现在前往管道页面。上次检查是在21分钟前。它现在应该开始检查，因为我们已经将代码推送到代码仓库。

现在可以看到状态已变为“1分钟前”。这意味着我们收到了提交时输入的信息“updated index.html”。目前部署正在进行中。

等待部署完成。部署已成功。前往此处查看。

页面可能从缓存加载。刷新页面。现在可以看到我们在索引文件中更新的信息。

同时，我们应该会收到通知。稍等片刻。可能正在发送中。我们将配置通知。再等待一下。

发现问题，通知主题无法访问。正在检查。由于原通知主题无法访问，我创建了一个新主题。

进入管理通知规则页面。进入通知设置。创建了一个具有此名称的新主题。可以看到它显示为“活动”状态。之前显示为“无法访问”，现在显示为“活动视图”。

我选择了这个主题并删除了它，然后创建了一个新的。如果您遇到问题，可能是AWS后端的问题。我创建了一条新规则。

查看这里的简单通知服务。我创建了这个新主题，并提供了相同的SNS端点。现在一切正常，我们正在接收通知。

但我会通过一次新的部署来展示整个过程。这是我们的管道。在此之前，我将对代码进行一些更改。

假设将“Congratulations”改为“Congratulations you all”。保存文件。

检查Git状态。已修改的文件是index.html。

提交此index.html文件。然后将其推送到GitHub。

在此处查看。刷新页面。它应该会获取新代码并开始部署。等待一分钟。再次刷新。可以看到部署正在进行中。

检查是否收到任何通知。现在收到一条通知。查看其内容。关于此次部署执行已开始。我们收到了所有相关通知。

收到了更多新通知。查看这些，部署已开始。现在看起来不错，我们收到了所有状态转换的通知。

再次查看此处。部署现在应该已完成。是的，已成功。

现在可以打开网站并检查。“Congratulations you all”已显示。

这就是我们为CI/CD管道中的所有操作配置通知的方法。它帮助我们跟踪环境中发生的情况，而无需登录环境，并能及时获得更新。

本节课中我们一起学习了如何为AWS CodePipeline配置持续通知。通过设置SNS主题和通知规则，您可以自动接收代码提交、构建和部署等关键事件的提醒，从而实现对CI/CD流程的自动化监控。

010：配置审批阶段 🛠️

在本节课中，我们将学习如何为现有的部署流水线添加更多阶段，包括一个生产环境阶段和审批阶段。通过配置审批，可以确保代码在部署到生产环境前获得必要的批准。

上一节我们设置了基本的开发环境部署流水线。本节中，我们将扩展这个流水线，使其包含一个生产环境和一个手动审批环节。

创建生产环境

首先，我们需要为生产部署创建一个新的Elastic Beanstalk环境。

  1. 导航到Elastic Beanstalk控制台的“环境”部分。
  2. 选择现有的开发环境（例如 web-dev-env）。
  3. 点击“克隆环境”选项。
  4. 将新环境命名为 web-prod-env。
  5. 确认URL可用后，开始创建克隆环境。

创建过程需要一些时间。在等待环境启动的同时，我们可以开始配置流水线的多阶段部署。

配置流水线阶段

环境准备就绪后，我们需要编辑现有的CodePipeline流水线，为其添加新的阶段。

以下是需要添加的步骤：

  1. 添加审批阶段：在开发部署阶段之后，添加一个用于手动审批的阶段。
  2. 添加生产部署阶段：在审批通过后，添加一个用于部署到生产环境的阶段。

1. 添加审批阶段

在流水线编辑器中，执行以下操作：

  • 在开发部署阶段后，点击“添加阶段”。
  • 将阶段命名为 Approval。
  • 在该阶段内，点击“添加操作组”。
  • 配置操作：
    • 操作名称：Manual-Approval
    • 操作提供者：选择“Manual approval”
    • 配置：
      • SNS主题：选择一个已存在的SNS主题（例如 web-dev-pipeline），用于发送审批通知。
      • 说明：可填写“请批准或拒绝此次部署”。

2. 添加生产部署阶段

审批阶段配置完成后，添加生产部署阶段。

  • 在审批阶段后，点击“添加阶段”。
  • 将阶段命名为 Prod-Deployment。
  • 在该阶段内，点击“添加操作组”。
  • 配置操作：
    • 操作名称：Deploy-to-Prod
    • 操作提供者：选择“AWS Elastic Beanstalk”
    • 区域：选择您的区域（例如 us-east-1）
    • 输入工件：选择 SourceArtifact（即来自源阶段的代码）
    • 应用程序名称：选择您的Elastic Beanstalk应用程序（例如 web-prod）
    • 环境名称：选择刚创建的生产环境（例如 web-prod-env）

配置完成后，保存对流水线的所有更改。

总结

本节课中我们一起学习了如何扩展CI/CD流水线。我们创建了一个新的生产环境，并在流水线中加入了手动审批阶段和生产部署阶段。现在的完整流水线流程是：源代码 -> 构建 -> 部署到开发环境 -> 等待手动批准 -> 部署到生产环境。这种结构加强了对生产环境部署的控制，符合最佳实践。

011：配置审批并继续 🚦

在本节中，我们将学习如何配置和使用 AWS CodePipeline 中的审批阶段。我们将通过修改代码、触发流水线、观察部署流程，并最终手动批准部署到生产环境，来完整演示一个包含审批环节的 CI/CD 流程。

概述

一个典型的企业部署流程通常包含四个阶段：源代码提交、部署到预发布环境、人工审批以及最终的生产环境部署。本节将重点展示在预发布环境部署成功后，如何通过审批来控制向生产环境的推进。

上一节我们配置了完整的流水线，本节中我们来看看当代码变更触发流水线后，审批环节是如何工作的。

首先，我对项目代码进行一个简单的修改。我将 index.html 文件中的内容更新为 “Welcome to EDUCBA. Congratulations, you all have implemented CI/CD.” 并保存文件。

接下来，我需要将这次修改提交到代码仓库。以下是操作步骤：

  1. 使用 git status 命令检查文件变更状态。系统会提示 index.html 文件已被修改。
  2. 使用命令 git commit -m “updated index.html” 提交这次修改。
  3. 使用 git push 命令将提交推送到远程仓库。

完成代码推送后，流水线会自动被触发。我可以回到 AWS CodePipeline 控制台查看流水线的执行状态。

此时，流水线的 Source（源代码） 阶段已经开始执行。稍等片刻，代码检查完成后，部署流程将进入 Deploy to Development（部署到开发环境） 阶段。

部署成功后，我可以在开发环境的 Elastic Beanstalk 应用 URL 中看到我们刚才所做的文本更改已经生效。

在开发环境部署成功之后，流水线并没有立即继续。如下图所示，它停在了下一个阶段，并显示 Approval（审批） 状态。

这正是我们配置的审批环节。流水线在向生产环境部署之前，需要等待手动批准。

同时，由于我们在上一节配置了 Amazon SNS 通知，审批负责人也会收到一封请求批准的电子邮件。邮件中包含了流水线的详细信息和一个可直接批准或拒绝的链接。

现在，我作为审批人，将执行批准操作。在 CodePipeline 控制台的审批阶段，我可以添加评论（例如：“Looks good to me”），然后点击 Approve（批准）。

一旦批准操作完成，流水线的状态会立即更新。随后，流程将自动进入最终的 Deploy to Production（部署到生产环境） 阶段。

等待生产环境的部署完成。部署成功后，我访问生产环境的 Elastic Beanstalk 应用 URL，确认新的更改也已成功上线。

至此，整个 CI/CD 流水线从代码提交到生产部署的全流程已成功执行完毕。我们可以回顾一下整个流水线的结构：

总结

本节课我们一起学习了 CI/CD 流水线中审批阶段的完整工作流程。我们实践了从代码修改、提交、触发自动化部署到开发环境，再到等待人工审批，最后批准并完成生产部署的全过程。

关键点总结如下：

  • 流程控制：审批阶段是控制代码从预发布环境进入生产环境的关键闸门。
  • 通知机制：通过 SNS 服务，审批请求可以自动通过邮件等方式通知负责人。
  • 操作方式：审批既可以在 CodePipeline 控制台完成，也可以通过邮件中的链接快速处理。
  • 紧急处理：在流水线执行过程中，即使已获得批准，在必要时仍可通过控制台立即停止执行。

通过本实践，你应该已经掌握了如何在 AWS 上使用 Elastic Beanstalk 和 CodePipeline 构建一个包含审批环节的稳健的 CI/CD 流程，并可以尝试在自己的项目中实施。

012：项目弹性豆茎应用创建与启动简介 🚀

在本节课中，我们将学习一项非常有趣的AWS服务——AWS Elastic Beanstalk。我们将了解如何利用这项服务来创建和启动应用程序，从而节省大量的基础设施设置时间。

在开始动手实践之前，我们先通过PPT了解一下什么是Elastic Beanstalk。

课程目标 🎯

我们将理解本服务及本项目的目标。如前所述，我们将使用它来创建和启动一个应用程序。在这个项目中，我们将使用AWS提供的、用不同语言及其不同版本编写的示例应用程序。

项目难度与前提条件 ⚙️

接下来，了解本项目的难度级别很重要。本项目属于中级水平。因为是中级项目，所以期望你了解一些基本的AWS服务，例如我们将要在应用程序中配置的S3和EC2实例。

进行本项目，你必须拥有一个AWS账户，也可以使用AWS免费套餐账户。

如果你想部署自己的代码来创建应用程序，请准备好你的代码。

项目核心目标 📋

进一步讨论项目目标，参与者将能够使用不同语言（如Java、.NET、PHP、Node.js、Python、Ruby和Go）的服务来创建应用程序。能在单一平台上使用所有这些语言及其不同版本，是不是很令人兴奋？

此外，参与者还可以：

  • 上传其应用程序的不同版本。
  • 启动你的环境。
  • 监控你的环境。

你将学到什么 📖

你将学习Elastic Beanstalk的架构和不同组件，并使用这些服务创建应用程序。你也可以在此服务中创建和启动自己的应用程序。

有任何项目要求和先决条件吗？是的。你必须拥有一个AWS账户，这样你就不必为任何服务付费，仅此而已，你就可以开始学习AWS Elastic Beanstalk了。

服务价值与技能收获 💡

我们可以讨论一下，AWS Elastic Beanstalk如何被那些寻找简单方式部署应用程序的开发人员使用。如前所述，这将为你节省大量的基础设施设置时间。

本应用程序将对开发人员有所帮助，同时也将提供实践经验。因此，对于那些想要通过AWS解决方案架构师助理认证的学生来说，这将很有帮助。

在本项目结束时，你将拥有以下技能：

  • 部署你的示例应用程序。
  • 了解许多AWS服务（我将在动手实践Elastic Beanstalk时告诉你）。
  • 监控应用程序（我们可以使用不同的服务来监控此应用程序）。
  • 使用此服务维护已部署应用程序的不同版本。

项目内容包括Elastic Beanstalk的架构，以及我们将要进行的动手实践。

案例研究 📊

现在，让我们讨论本次课程将遵循的案例研究。你的客户希望更专注于开发和创新想法。

你建议你的客户使用AWS Elastic Beanstalk进行应用程序部署和维护不同的部署版本。你将向客户演示，如何节省大量设置部署和基础设施环境的时间和精力，使用AWS示例应用程序创建应用程序，以及通过上传自己的代码来创建应用程序。

作为本案例研究的一部分，将涵盖以下场景：

  1. 使用AWS服务Elastic Beanstalk创建你的应用程序。
  2. 使用Elastic Beanstalk中预定义的示例应用程序或上传你自己的应用程序代码。
  3. 使用Elastic Beanstalk配置部署设置所需的不同参数。
  4. 解释绿色和蓝色部署方法。
  5. 使用Elastic Beanstalk进行绿色/蓝色部署方法的动手实践。

本节课中，我们一起学习了AWS Elastic Beanstalk服务的简介、项目目标、所需技能以及一个具体的客户案例。我们了解到，Elastic Beanstalk是一个能极大简化应用部署和管理的平台服务，适合希望专注于核心业务逻辑的开发团队。在接下来的章节中，我们将开始动手实践，创建我们的第一个Elastic Beanstalk应用。

013：为何我们需要 AWS Elastic Beanstalk 🚀

在本节课中，我们将学习 AWS Elastic Beanstalk 的核心概念、主要组件以及它如何简化应用程序的部署和管理。我们将探讨使用它的原因，并通过图解理解其工作原理。

概述

AWS Elastic Beanstalk 是一项服务，用于简化在 AWS 云上部署和扩展 Web 应用程序及服务的过程。它能够自动处理容量配置、负载均衡、自动扩展和应用程序健康监控等细节。

为何需要 Elastic Beanstalk

管理基础设施涉及许多复杂性，需要消耗大量时间和资源来处理。Elastic Beanstalk 是最佳选择，因为它能帮助我们忽略这些复杂性。

使用 Elastic Beanstalk 可以实现不同应用程序和环境之间的一致性。我们可以用它来同时维护每个应用程序的多个版本。

我们知道，存在许多扩展性问题，而使用 AWS Elastic Beanstalk 可以忽略这些问题。

有时可能需要部署多个应用程序，我们可以使用 Elastic Beanstalk 来实现这一点。

在部署三层应用程序架构时，需要创建和配置许多组件。单个应用程序可能包含不同的环境，例如开发、测试、预发布和生产环境。

所有环境都可以通过 AWS Elastic Beanstalk 进行管理。

Elastic Beanstalk 的主要组件

Elastic Beanstalk 主要由三个核心类别构成：应用程序、应用程序版本和环境。

  • 应用程序：是 Elastic Beanstalk 的基本单元，代表您要部署的服务或网站。
  • 应用程序版本：指向特定代码版本（例如，一个.zip文件）的引用。一个应用程序可以有多个版本。
  • 环境：是运行应用程序版本的 AWS 资源集合。每个环境只运行一个应用程序版本。

Elastic Beanstalk 的工作原理

现在，让我们看看它的实际工作流程。想象一下，您想要创建并部署一个应用程序。

您可以上传我们的应用程序版本，然后它将启动一个环境。环境就是运行应用程序版本所需的一系列 AWS 资源的集合。

您也可以管理您的环境。这意味着，每当您创建一个应用程序并部署一个环境时，您就已经部署了一个新的应用程序版本。

之后，您还可以通过更改源代码来更新应用程序版本。

本课程实践内容简介

在接下来的实践中，我们将首先使用 Elastic Beanstalk 部署一个简单的 Node.js 应用程序，而不是从复杂的开始。我们将了解如何利用 Elastic Beanstalk 来部署一个简单的应用程序。

然后，我们将启动一个高级的或生产级别的环境。这将是一个使用高可用性配置预设的高级生产环境。

我们将使用高可用性选项，例如负载均衡器和自动扩展组，这些将作为我们环境的一部分。

接着，我们将讨论部署选项和策略。我们将看到蓝绿部署方法。我们将利用之前创建的两个不同环境。您可以使用 Route 53 设置将流量对半分割。

我们将看到与 Elastic Beanstalk 相关的高级概念。我们将了解如何向现有的 Elastic Beanstalk 环境添加和更新数据库。

总结

本节课我们一起学习了 AWS Elastic Beanstalk 的基本概念和重要性。我们了解到，它通过自动化基础设施管理，解决了部署中的复杂性和扩展性问题。其核心组件——应用程序、应用程序版本和环境——共同协作，使我们能够轻松部署、管理和更新应用程序。在后续课程中，我们将动手实践，从简单部署开始，逐步深入到高可用性生产环境的配置。

014：基本功能流程 🚀

在本节课中，我们将要学习 AWS Elastic Beanstalk 的核心概念、定价策略，并通过一个手把手的实验来部署第一个应用程序。我们将了解其基本组件和工作流程。

定价策略 💰

现在，我们来讨论定价策略。你将了解使用 AWS Elastic Beanstalk 服务如何收费。

使用 Elastic Beanstalk 没有额外费用。你无需为使用该服务本身支付任何费用。然而，你只需为你实际使用或你的应用程序所消耗的底层 AWS 资源付费。

例如，你可能部署了 EC2 实例、Elastic Load Balancer 或任何其他资源。你需要为这些资源付费。但是，你无需为 Elastic Beanstalk 这项服务付费。

以上就是 Elastic Beanstalk 的概述。现在，我们开始使用 Elastic Beanstalk 部署第一个应用程序。

什么是 Elastic Beanstalk？ 🤔

Elastic Beanstalk 是一个以开发者为中心的视角，用于在 AWS 上部署应用程序。你可以在此快速部署和管理应用程序，无需了解运行这些应用程序的基础设施。它有助于在不牺牲选择或控制权的情况下降低管理复杂性。你只需上传应用程序并进行部署。

Elastic Beanstalk 负责容量预置、负载均衡、扩展和应用程序健康监控。

基本组件 🧩

让我们看看 Elastic Beanstalk 的一些基本组件。基本上，我们有三个主要类别：应用程序、应用程序版本和环境。

以下是这三个核心概念的详细说明：

  • 应用程序：应用程序是 Elastic Beanstalk 组件的逻辑集合，包括环境、版本和环境配置。
  • 应用程序版本：应用程序版本指可部署的代码源包。例如，一个 Java .war 文件。应用程序版本是应用程序的一部分，它只是一个源代码包。一个应用程序可以有许多版本，每个应用程序版本都是唯一的。
  • 环境：环境是运行一个应用程序版本的 AWS 资源集合。每个环境一次只运行一个应用程序版本。你可以同时在多个环境中运行相同的应用程序版本或不同的应用程序版本。当你创建一个环境时，Elastic Beanstalk 会预置运行你指定的应用程序版本所需的资源。

以上就是围绕 Elastic Beanstalk 的三个主要类别。

动手实验：部署第一个应用 🛠️

现在，让我们开始进行 Elastic Beanstalk 的动手实验。首先，转到 AWS 控制台首页，在“计算”部分下找到 Elastic Beanstalk，点击它。

第一步是创建一个应用程序。点击“创建新应用程序”。你将看到创建应用程序页面，填写所需详细信息。我们将应用程序命名为“my-sample-first-app”。描述字段可以留空，如果需要也可以填写。标签也是可选的。然后点击“创建”。

创建完成后，你会看到应用程序已创建，但该应用程序需要一个环境。因此，我们点击“立即创建环境”。你会看到两个选项：第一个是“Web 服务器环境”，第二个是“工作线程环境”。由于我们要部署一个 Web 应用程序，我们选择“Web 服务器环境”。如果你想运行一个处理长时间运行的工作负载或按计划处理任务的工作线程应用程序，可以选择“工作线程环境”。但根据当前部署 Web 应用程序的需求，我们选择“Web 服务器环境”。

选择后，填写所需详细信息。我们的应用程序名称已给出为“my-sample-first-app”。然后填写环境名称。接着，我们需要选择一个域名。我们尝试输入我们的域名并检查其是否可用。检查可用性后，确认可用，我们继续下一步。

现在，这里需要你选择平台。你可以从以下选项中选择：.NET、Docker、Go、Java、Node.js、PHP、Python、Ruby、Tomcat。我将选择 Python。这里你还有一个优势，可以选择平台分支和平台版本，选择你熟悉或希望部署的版本。目前，我将选择推荐的版本，即 3.7 或更高版本。

第三个选项是“应用程序代码”。正如之前阶段提到的，你可以部署自己的代码，也可以使用现有版本，或者由于这是一个全新的应用程序，我们可以选择此处的“示例应用程序”。出于演示目的，我将选择“示例应用程序”。

我们还可以查看“配置更多选项”的含义。你可以编辑那里提到的任何默认配置。由于这是一个简单的应用程序，我不打算编辑任何内容。我们将在更广泛的环境部署中检查这些配置。

目前，我认为一切看起来都很好，我们将直接创建环境。系统提示正在创建环境和应用程序，这可能需要一段时间。实际上，后台正在发生以下过程：所有 AWS 资源，如 S3、EC2、VPC 等，都在为你的应用程序创建和部署。

我将暂停视频，我们稍后再看。如你所见，AWS 资源正在生成，例如 EC2 实例。它正在与安全组一起创建。这个过程需要几分钟。

如你所见，我们的应用程序正在生成。状态是“健康”，运行版本是此版本，我们选择的平台是 Python 3.7。在这里你可以看到事件，例如成功启动环境“my-sample-first-app”。应用程序可通过此路径访问，为此环境添加了 EC2 实例。

这就是你可以查看的方式。你可以创建你的环境、你的应用程序，也可以刷新以检查是否有任何更新。目前，我们的应用程序环境处于健康状态。

现在，要查看我们的应用程序是否实际创建，只需点击我们为域名选择的这个 URL。这是我们的域名，点击它。是的，你可以看到我们的应用程序已成功部署，并且可以看到此输出。

总结 📝

本节课中，我们一起学习了 AWS Elastic Beanstalk 的基本功能。我们了解了它的定价策略（仅为底层资源付费），认识了其三个核心组件：应用程序、应用程序版本和环境。最后，我们通过一个完整的动手实验，使用示例应用程序成功在 Elastic Beanstalk 上部署了一个简单的 Web 应用，并验证了其可访问性。整个过程展示了 Elastic Beanstalk 如何简化在 AWS 上的应用部署与管理。

015：自定义配置预设 🛠️

在本节课中，我们将学习如何在AWS Elastic Beanstalk中创建自定义配置预设。我们将使用高可用性预设来构建一个生产级别的环境，该环境将包含负载均衡器和自动伸缩组等高级功能。

上一节我们介绍了基础环境配置，本节中我们来看看如何通过自定义预设来构建更高级、更健壮的部署环境。

启动高级环境

我们可以启动一个使用高可用性的高级或广泛环境。我们也可以自定义配置预设，这本质上会更加高级，因为我们将使用高可用性预设来确保包含一些高级功能，例如负载均衡器和自动伸缩组等。这样我们就可以创建一个生产级别的环境。

现在，让我们开始整个操作过程。

操作步骤

以下是启动AWS管理控制台并开始创建自定义配置预设的步骤。

  1. 打开AWS管理控制台。
  2. 导航到Elastic Beanstalk服务。
  3. 点击“创建新环境”。
  4. 在环境配置页面，选择“自定义配置”选项。
  5. 在预设选择部分，勾选“高可用性”预设。
  6. 此预设将自动配置负载均衡器和自动伸缩组。
  7. 根据您的应用程序需求，进一步调整实例类型、最小/最大实例数等参数。
  8. 完成所有配置后，点击“创建环境”开始部署。

本节课中我们一起学习了如何在AWS Elastic Beanstalk中通过自定义配置预设来构建一个具备高可用性的生产环境。我们了解了高可用性预设如何自动集成负载均衡和自动伸缩功能，从而提升应用程序的可靠性和扩展性。

016：创建新应用程序 🚀

在本节课中，我们将学习如何在 AWS Elastic Beanstalk 中创建一个新的应用程序，并为其配置测试环境和生产环境。我们将使用 Node.js 平台作为示例，并了解环境创建过程中的关键配置选项。

概述

首先，我们需要登录 AWS 管理控制台，并导航到 Elastic Beanstalk 服务。我们的目标是创建一个 Node.js 应用程序，并为其建立两个独立的环境：一个用于测试，另一个用于生产。

创建应用程序

进入 AWS 管理控制台后，在“计算”服务类别下选择 Elastic Beanstalk。

接下来，我们将在此处创建一个新的应用程序。由于我们将使用 Node.js，因此需要相应地命名应用程序。

以下是创建应用程序的步骤：

  • 应用程序名称：为你的应用程序命名。
  • 描述：此字段为可选，可以填写应用程序的描述信息。
  • 标签：添加键值对标签也是可选的。

现在，我们的 Node.js 应用程序已经创建成功。但一个应用程序需要一个环境才能运行。

创建测试环境

应用程序创建后，我们需要为其创建环境。首先，我们将创建一个测试环境。

点击“创建新环境”按钮。环境类型分为 Web 服务器环境 和 工作环境。我们之前讨论过，工作环境适用于处理长时间运行任务或按计划执行任务的应用程序。目前，我们要部署的是 Web 应用程序，因此选择 Web 服务器环境。

以下是配置测试环境的关键步骤：

  • 域名：这是一个必填字段。我们输入一个域名并检查其可用性。
  • 描述：此字段为可选。
  • 平台：选择 Node.js。我们将使用推荐的最新平台版本。
  • 应用程序代码：在此示例中，我们选择使用 示例应用程序代码。

点击“创建环境”后，系统将开始为我们的应用程序构建环境。仪表板会显示后台正在创建的 AWS 资源，此过程需要几分钟时间。

创建生产环境

在等待测试环境创建的同时，我们可以为同一个应用程序创建生产环境。

返回应用程序列表，选择我们刚创建的应用程序。你会看到测试环境正在创建中。点击“操作”按钮，选择“创建环境”来添加另一个环境，即生产环境。一个应用程序可以拥有任意数量的环境。

再次选择 Web 服务器环境。我们将环境名称更改为“生产环境”，并设置一个对应的域名。

在平台配置部分，我们再次选择 Node.js 和推荐的最新平台版本。

接下来，我们将看到“配置更多选项”。这里提供了几种预设配置：

  • 单实例：适用于免费套餐。
  • 使用 Spot 实例的单实例。
  • 高可用性。
  • 使用 Spot 实例和按需实例的高可用性。
  • 自定义配置。

每种预设都包含一组配置，例如 EC2 实例类型、负载均衡器类型等。为了获得高可用性，我们选择 高可用性 预设。你可以查看其详细的配置参数，如实例类型（默认为 t2.micro）、存储类型、自动扩展组设置、部署策略（默认为“一次全部部署”）和负载均衡器类型（默认为推荐的应用程序负载均衡器）。你还可以检查安全组和监控设置。

目前，我们直接使用预设的配置值，不做修改，点击“创建环境”。现在，系统将开始创建我们的生产环境，这比测试环境配置更高级。

环境部署完成

等待一段时间后，可以看到生产环境已成功部署，健康状态显示为“正常”。所有部署的资源和配置信息都可以在环境概览页面查看。

至此，我们的 Node.js 应用程序拥有了两个环境：一个测试环境和一个生产环境。通过这种方式，你可以为单个应用程序部署多个环境，无论你需要何种配置。你可以使用不同的预设配置，也可以上传自己编写的代码，而不仅仅是本示例中使用的示例代码。

总结

本节课中，我们一起学习了在 AWS Elastic Beanstalk 中创建 Node.js 应用程序的完整流程。我们创建了一个应用程序，并为其成功配置了测试环境和生产环境。我们了解了环境类型的选择（Web 服务器 vs. 工作环境），以及如何使用预设的高可用性配置来部署生产环境。这为后续实现持续集成和持续部署（CI/CD）打下了基础。

017：部署策略 🚀

在本节课中，我们将学习 AWS Elastic Beanstalk 中可用的部署选项与策略。我们将探讨四种主要的部署方式，并了解它们各自的优缺点及适用场景。最后，我们将通过一个简单的演示，了解如何更新和部署应用程序代码。

概述

AWS Elastic Beanstalk 提供了多种部署策略，以适应不同的应用场景和需求。理解这些策略有助于我们在平衡部署速度、成本、可用性和风险之间做出最佳选择。

部署策略详解

我们将讨论 AWS Elastic Beanstalk 中可用的部署选项和策略。

主要有四种不同的策略选项：一次性全部部署、滚动部署、带额外批次的滚动部署以及不可变部署。下面我们简要概述这些不同选项，并看看如何在 Elastic Beanstalk 中使用它们。

一次性全部部署 ⚡

让我们从第一种策略开始，即一次性全部部署。

一次性全部部署是所有部署选项中最快的一种。

当我们使用这种部署选项时，应用程序会出现停机时间。

这是在部署环境中进行快速迭代的一个很好选择。然而，此策略没有额外成本。这是 AWS Elastic Beanstalk 中的默认部署选项。

滚动部署 🔄

第二种策略是滚动部署。

滚动部署一次升级少量实例，待第一批实例健康后，再继续下一批。

您可以设置批次大小。在此策略下，应用程序会同时运行新旧两个版本。这里没有涉及额外成本。

部署过程较长，因为一旦选择升级策略或想要升级应用程序，就必须分批进行。这导致部署过程更长。

带额外批次的滚动部署 🔄➕

接下来是带额外批次的滚动部署。

这是我们在上一节看到的滚动部署的高级版本。

此策略的特点是：应用程序在部署期间保持全容量运行。您也可以设置批次大小。应用程序同时运行两个版本。

由于我们会启动新的批次，所以会产生少量额外成本。在部署结束时，初始批次的实例会被移除，因为所有单元测试用例升级后就不再需要它们了。这同样导致部署时间较长。

不可变部署 🛡️

最后但同样重要的是不可变部署策略。

在这种策略中，我们利用自动伸缩组。让我们看看它的特点。

部署应用程序时实现零停机时间。新代码被部署到临时自动伸缩组的新实例上。由于实例数量会翻倍，因此成本较高。

部署时间较长，但从该部署策略中获得的好处是，在出现故障时可以快速回滚。如果新应用程序无法正常工作，您可以终止新的自动伸缩组，并保留现有的那个。这非常适合生产环境部署。

蓝绿部署 🌊🌿

我们下一个要讨论的主题是蓝绿部署。

蓝绿部署是一种通过将流量在两个运行着不同版本应用程序的相同环境之间切换，来发布应用程序的技术。蓝绿部署可以减轻与部署软件相关的常见风险，例如停机时间和回滚能力。

让我们看一个例子。您有用户和产生的网络流量（HTTP 或 HTTPS）。这些网络流量会到达 Route 53 DNS 服务器，其中 90% 的流量被发送到蓝色环境（包含应用程序版本 1），其余 10% 的流量被发送到最新版本，即应用程序的版本 2，也称为绿色环境。这样，您就将环境分成了两个不同的类别：蓝色环境和绿色环境。

您可以在 Route 53 中使用加权路由策略，以这种方式分割流量：90% 的流量发送到包含软件版本 1 的蓝色环境，10% 的流量发送到包含应用程序版本 2 的绿色环境。

关键在于，一旦您的绿色环境通过健康检查，您就可以使用“交换 URL”的概念，然后将全部流量发送到您的绿色环境。此后，您可以终止蓝色环境。

它的工作原理是：通过使用蓝绿部署，可以提高可用性并降低风险。蓝色环境是通常承载实时流量的生产环境。绿色环境则是用升级版本创建的。

演示：更新与部署代码 💻

在这个演示视频中，我们将看到如何利用不同的部署选项，以及如何更新我们的代码并进行部署。这是 Elastic Beanstalk 部署更新代码的主要目的。

如您所见，我有一个 Node.js 应用程序，目前有两个环境：一个是测试环境，另一个是生产环境。我将转到生产环境，检查其状态。它是健康的，并且正在运行 Node.js 12。这是我们可以访问并查看的 URL。

您可以看到输出。如果我想更新我的代码然后再次部署呢？

我将点击“上传和部署”。它会给我两个选项：一是可以部署此应用程序的先前版本，二是我可以上传新代码。我们可以选择任何一种方式，让我们选择第二种方式，即上传应用程序。

这是上传文档的简单机制。我有一个包含所有更新代码的 zip 文件。我将其命名为 nodejs-update-1.zip。当前实例数量为 1。这是模式。zip 文件已上传，我将点击部署按钮。

后台发生的情况是：我们正在用上传的新代码进行部署。

我们可以查看正在发生的事件。这些都在更新。环境正在用新代码再次更新。是的，我可以看到我的部署已完成，更新后的代码现已通过健康检查。

好的，这是我们的 URL。如果我们再次访问这个 URL：

您可以看到，我们已经用蓝色背景更新了代码，并且部署成功。我们只是点击并上传了代码，然后点击了几个按钮，部署就完成了，没有任何基础设施方面的麻烦，也不需要做任何额外的工作。我们完全避免了为部署而设置基础设施的所有头疼问题。这就是 Elastic Beanstalk 的主要目的。

这非常简单。以同样的方式，您现在可以为您的应用程序上传任何核心代码片段。根据您使用的部署策略或部署选项类型，您的应用程序可能会有一些停机时间。应用程序在此成功部署，我使用了滚动更新。

那么如何配置您的部署策略呢？您只需要点击“配置”部分。


您可以看到应用程序中的所有配置。在这里您可以看到“滚动更新和部署”。如果您想选择其他选项，是的，有部署策略，但默认是一次性全部部署。配置更新已禁用，所以我在这里没有更改任何内容，只是按照流程操作，您可以看到部署发生了，这就是输出。

同样地，我们也将看到蓝绿部署的演示。

总结

本节课中，我们一起学习了 AWS Elastic Beanstalk 的四种核心部署策略：一次性全部部署、滚动部署、带额外批次的滚动部署和不可变部署，并了解了蓝绿部署这一降低风险的高级技术。每种策略在部署速度、成本、可用性和复杂性之间有不同的权衡。通过实际操作演示，我们还看到了在 Elastic Beanstalk 中更新和部署应用程序代码是多么简单直接，它极大地简化了基础设施管理的复杂性。

018：蓝绿部署演示 🎬

在本节课中，我们将学习如何使用蓝绿部署方法。这种方法能确保在部署新版本应用时，通过交换URL的选项，将域名流量无缝切换到运行新版本应用的环境实例上。接下来，让我们看看整个过程是如何发生的。

部署环境现状

上一节我们介绍了如何将新代码部署到测试环境。现在，我的应用程序有两个环境：

  • 测试环境（Broad Environment）运行着新版本的代码，其背景色为绿色。
  • 生产环境（Production Environment）运行着旧版本的代码，其背景色为蓝色。

目前，所有的生产流量都指向生产环境。

执行URL交换

为了实现蓝绿部署，我们需要交换这两个环境的URL。以下是具体操作步骤：

  1. 在AWS Elastic Beanstalk控制台中，选择你的生产环境。
  2. 点击“操作”（Actions）按钮。
  3. 从下拉菜单中，选择“交换环境URL”（Swap Environment URLs）选项。

通过这个操作，生产环境的域名将立即开始指向之前作为测试环境的实例（即运行新版本绿色背景应用的实例），而之前的“生产环境”则变成了新的测试环境。这个过程非常迅速，能实现流量的无缝切换，最大程度减少服务中断。

核心操作与概念

以下是蓝绿部署在Elastic Beanstalk中的关键操作列表：

  • 交换环境URL：此操作会交换两个环境（例如生产与测试）的CNAME记录，从而实现流量的即时切换。
  • 克隆环境：用于创建一个与现有环境配置完全相同的新环境，这是准备“绿色”环境的基础。
  • 加载/保存配置：用于管理环境设置，确保部署的一致性。

总结

本节课我们一起学习了AWS Elastic Beanstalk中的蓝绿部署流程。我们了解到，通过先在新环境（绿色）中部署和验证应用，然后使用“交换环境URL”功能，可以安全、快速地将用户流量切换到新版本，从而实现零停机部署。这种方法极大地提高了发布的可靠性和用户体验。

019：配置 Route 53 与蓝绿部署 🚀

在本节课中，我们将学习如何配置 AWS Route 53 服务，以实现流量的加权路由，并演示如何使用 Elastic Beanstalk 的“交换环境 URL”功能执行蓝绿部署，从而实现零停机时间的应用更新。

配置 Route 53 加权路由策略

上一节我们介绍了 Elastic Beanstalk 环境。本节中，我们来看看如何将用户流量引导到不同的环境。为此，我们将使用名为 Route 53 的 AWS 服务。

在 AWS 控制台的搜索栏中搜索 “Route 53”，你将进入此服务的管理窗口。这里会列出你的托管区域，你可以拥有多个托管区域。

我们需要在此创建一个记录。点击“创建记录”。

以下是关于路由策略的基本信息。如果你想了解路由策略的具体类型，可以阅读此处提供的描述。为本次演示，我将使用“加权”路由策略。点击“下一步”。

接下来，我们需要配置一些参数来定义记录。

  • 记录名称：你可以在此处输入任何名称。
  • 记录类型：我将使用默认的 A 记录，它将流量路由到 IPv4 地址。
  • TTL：保持为 300 秒。

现在我们需要定义加权记录。点击相应区域进行配置。界面会显示已选择的记录名称和类型。接下来需要选择流量要路由到的端点。

在下拉菜单中，你可以看到不同的选项。Route 53 与许多其他 AWS 服务（如 API 网关、CloudFront 分发、Elastic Beanstalk 环境、负载均衡器等）互联。由于我们正在使用 Elastic Beanstalk 环境，因此选择它。

  • 区域：选择我们正在使用的区域，例如“美国东部（弗吉尼亚北部）”。
  • 端点：选择我们的生产环境 URL。
  • 记录 ID：可以输入例如 sample-domain-production。
  • 权重：定义权重值，例如 10。

配置完成后，创建此记录。这样，我们就将 10% 的域名流量路由到了生产环境链接。

现在，我们将创建另一个记录，将 90% 的流量路由到测试环境。重复相同的过程。

  • 再次选择路由策略为“加权”。
  • 记录名称保持不变。
  • 记录类型选择 A 记录。
  • 在端点部分，再次选择 Elastic Beanstalk 环境，区域为“美国东部（弗吉尼亚北部）”。
  • 这次选择测试环境的 URL。
  • 将权重设置为 90。
  • 记录 ID 可以设为 sample-domain-test。

现在创建此记录。至此，我们已配置好域名，将全部流量分配到两个链接：10% 到生产环境，90% 到测试环境。

在 Route 53 控制台，你可以看到已创建的加权策略记录。现在，让我们返回 Elastic Beanstalk 控制台查看环境状态。

执行蓝绿部署（交换环境 URL）

现在我们已经配置好 Route 53 的加权记录集。接下来，我们将在 Elastic Beanstalk 中执行一次蓝绿部署。

在 Elastic Beanstalk 控制台，选择生产环境。点击“操作”菜单，在“部署”部分找到“交换环境 URL”功能并点击。

此功能的作用是交换生产环境和测试环境的 URL。在弹出框的下拉菜单中，选择我们的测试环境。

核心操作：

swap_environment_urls(Production_Environment, Target_Environment=Test_Environment)

系统会给出警告：交换 URL 将修改 Route 53 的 DNS 配置，可能需要几分钟时间。在更改传播期间，你的应用程序将继续运行，不会出现停机。这是该服务最重要的特性之一。

点击“交换”按钮。后台进程开始运行，部署状态显示为“健康”。让我们检查一下 URL 发生了什么变化。

理论上，生产链接现在应该被交换为测试链接，所有 DNS 策略都会相应更改。我们打开生产环境的 URL 查看。最初可能仍显示蓝色背景（原生产环境），因为 DNS 更改需要时间传播。持续刷新页面等待几分钟。

等待大约两到三分钟后，再次刷新生产环境 URL。现在，你看到的输出是绿色背景（原测试环境的内容）。

流程总结与回顾

本节课中我们一起学习了如何配置 Route 53 和执行蓝绿部署。让我们回顾一下整个流程：

  1. 第一步 - 流量分配：我们使用 Route 53 的加权路由策略，将 90% 的流量导向测试环境（绿色背景），10% 的流量导向生产环境（蓝色背景）。
  2. 第二步 - 环境交换：我们在 Elastic Beanstalk 中对生产环境执行了“交换环境 URL”操作，将其 URL 与测试环境的 URL 互换。
  3. 最终结果：交换完成后，生产环境的 URL 现在接收了 90% 的流量，并且指向了更新后的代码（即原先在测试环境验证过的代码）。通过刷新页面，我们验证了生产 URL 现在显示的是绿色背景。

这种方法帮助我们将代码从测试环境移动到生产环境，无需任何停机时间，也不会对应用程序造成损害。

这是一个简单的示例。你可以使用相同的术语和方法，通过上传新代码、利用各种部署选项、以及交换测试与生产环境的 URL，来修改更复杂的代码。Elastic Beanstalk 服务本身是免费的，你只需为应用程序实际使用的 AWS 资源付费。

这就是关于蓝绿部署和部署选项的全部内容。

020：进阶概念 🚀

在本节课中，我们将要学习AWS Elastic Beanstalk的三个进阶概念：生命周期策略、扩展文件和环境类型。这些概念能帮助你更高效地管理和优化你的应用部署。

生命周期策略 🔄

上一节我们介绍了基础部署，本节中我们来看看如何管理应用版本。生命周期策略允许你控制Elastic Beanstalk仪表板中存储的应用版本数量。

你最多可以在仪表板中维护1000个应用版本，并且可以超过这个限制。但是，只有当前正在被任何环境使用的应用版本不会被自动删除。

你可以从你的任何S3存储桶中检索应用程序的源代码包。

扩展文件 ⚙️

现在我们将了解扩展文件。这些文件位于应用程序源代码的 .ebextensions/ 目录内。

这些文件采用 YAML 或 JSON 格式，并以 .config 作为扩展名。例如，你可以找到 logging.config 文件。

以下是扩展文件的主要用途：

  • 你可以使用这些文件来更改、执行或更新你环境中组件的参数。

环境类型 🏗️

现在，让我们谈谈Elastic Beanstalk中可用的环境类型。主要有两种环境类型：Web服务器环境类型和工作环境。

1. Web服务器环境
这种环境用于运行网站、Web应用程序或任何处理HTTP请求和响应的Web API。在我们过去所有的演示回顾中，由于我们的需求是托管Web应用程序，因此一直使用这种Web服务器环境。

2. 工作环境
如果你的应用程序执行需要较长时间才能完成的任务，或者你可以将这些任务卸载到后端，或者你拥有计划任务，那么可以使用这种工作环境。

这意味着你可以将应用程序解耦到两个独立的环境中。

总结 📝

本节课中我们一起学习了AWS Elastic Beanstalk的三个进阶概念。我们了解了如何使用生命周期策略管理应用版本，认识了用于自定义环境的 .ebextensions/ 扩展文件，并区分了用于处理Web请求的Web服务器环境与用于执行后台任务的工作环境。掌握这些概念有助于你构建更健壮、可扩展的应用程序架构。

AWS Elastic Beanstalk与CI/CD：03_01_02：数据库导论 🗄️

在本节课中，我们将学习如何为现有的AWS Elastic Beanstalk环境添加数据库。我们将探讨可用的不同选项，并演示具体的操作步骤。

在上一节中，我们创建了一个包含测试（test）和生产（pro）两个环境的应用程序。本节中，我们将具体了解如何为环境附加数据库资源。我们将以为现有的生产（pro）环境添加一个RDS数据库为例进行说明。

以下是向现有环境添加数据库的主要步骤：

  1. 登录AWS管理控制台，导航到Elastic Beanstalk服务。
  2. 在左侧导航栏中，选择“环境”，然后点击您要修改的环境名称（例如“pro”）。
  3. 在环境仪表板的左侧导航栏中，找到并点击“配置”。
  4. 在配置页面中，滚动到“数据层”部分，点击“编辑”。
  5. 在数据层配置页面，您可以选择创建新的数据库实例或连接到现有实例。对于新建，您需要设置数据库引擎（如MySQL、PostgreSQL）、实例类型、存储大小、用户名和密码等参数。
  6. 完成所有必要配置后，点击页面底部的“应用”按钮。Elastic Beanstalk将开始更新您的环境以包含新的数据库资源。

这个过程的核心是修改环境的配置，其本质是更新一个描述环境的JSON或YAML文件，例如更新 .ebextensions 目录下的配置文件来声明数据库依赖。

# 示例：在 .ebextensions 配置中声明数据库选项（概念示意）
option_settings:
  aws:rds:dbinstance:
    DBEngine: mysql
    DBInstanceClass: db.t2.micro
    DBUser: mydbuser
    DBPassword: mypassword

完成上述步骤后，您的应用程序环境将与一个托管的数据库实例关联。应用程序可以通过环境变量（如 RDS_HOSTNAME, RDS_DB_NAME）自动获取数据库连接信息，无需在代码中硬写配置。

本节课中，我们一起学习了如何为AWS Elastic Beanstalk环境集成数据库。我们回顾了通过控制台配置界面添加RDS数据库的流程，并理解了其背后通过环境配置和变量注入实现连接的基本原理。这为构建需要数据持久化的完整应用程序奠定了基础。

022：演示数据库配置 🗄️

在本节课中，我们将学习如何在 AWS Elastic Beanstalk 环境中添加并配置一个 RDS 数据库实例。我们将通过控制台操作，为现有的应用程序环境附加一个数据库，并了解相关的配置选项和生命周期管理。

概述

上一节我们介绍了 Elastic Beanstalk 环境的基本状态。本节中，我们来看看如何为这个环境添加一个关系型数据库服务（RDS）。我们将从环境仪表盘开始，逐步完成数据库的创建和配置。

访问环境配置

这是我们的 Elastic Beanstalk 仪表盘，可以看到两个环境位于同一个应用程序下。目前环境处于健康状态。

现在需要执行的操作是为该环境添加一个 RDS 数据库。当前，此应用程序尚未附加任何数据库。

以下是查看或编辑配置的位置。

配置 (Configuration) 列

点击此列后，将显示当前环境的所有配置项，并可以进行编辑。最后一项是数据库配置，目前此处为空。

编辑数据库配置

我们将点击“编辑”按钮。系统首先会获取当前的配置信息，以便修改数据库设置。此操作将把一个 Amazon RDS 数据库添加到您的基础设施和环境中，用于开发和测试目的。

AWS Elastic Beanstalk 通过设置环境属性（如数据库主机名、用户名、密码、表名和端口）来向您的实例提供连接信息。当您向环境添加数据库时，其生命周期将与您的环境绑定。对于生产环境，您可以配置实例以连接到外部数据库。

配置数据库参数

现在，界面显示了一些参数选项，例如“从快照恢复”。

此选项询问我们是希望从账户中现有的快照恢复数据库，还是需要创建一个新数据库。

AWS 提供了从快照恢复数据库的功能。但在此演示中，我们将选择创建新数据库。

因此，我们选择“无”。如果账户中存在快照，它们会出现在此下拉列表中。目前没有，所以只显示“无”。

选择“无”后，我们需要创建新数据库。以下是需要配置的选项。

默认数据库引擎是 MySQL。但这里提供了多种数据库选项，包括 Oracle、PostgreSQL、SQL Server 等。

出于演示目的，我们将使用默认的 MySQL 引擎。引擎版本为 8.0.17，实例类为 db.t2.micro（这是默认的免费套餐类型）。

存储配置选项允许选择 5 GB 到 1 TB 或 24 GB。由于是演示，我们选择最小值 5 GB。

接下来需要设置用户名和密码。正确配置用户名和密码非常重要，这将帮助您访问 RDS 数据库。

我们设置用户名为 testingDb，密码也设置为 testingDb。

下一个选项是关于保留策略的：当您终止环境时，数据库实例也会被终止。选择“创建快照”会在终止前保存该数据库的快照。

因此，您可以将此快照与之前的“从快照恢复”选项关联使用。这里，我们选择“删除”。

此外，如果您的应用程序不需要多租户或高可用性，可以选择单一可用区。如果需要高可用性，则可以选择多可用区部署。目前，我们选择单一可用区。

确保所有信息输入正确，然后点击“应用”。

应用配置与部署

系统正在验证并保存所有配置。它提示保存配置，但建议不要将数据库相关配置保存在本地桌面。

现在，环境开始重新部署。因为我们更改了配置，环境将更新以包含我们刚刚配置的 RDS 数据库。此过程需要几分钟。

我们可以通过事件部分监控部署进度。所有活动都会显示在此处，对于 Elastic Beanstalk 的初学者，观察后台部署步骤非常有益。

页面会自动刷新以显示最新状态。现在可以看到事件显示 RDS 数据库已使用指定名称创建。

验证 RDS 创建

我们可以在 AWS 控制台验证 RDS 实例的创建。进入 RDS 控制台，查看数据库部分，确认实例已创建。

点击该实例，可以查看所有安全和连接参数。这些参数都是为此特定 RDS 实例自动创建的。

可以看到关联的安全组处于活动状态。还可以检查复制设置，目前我们只有一个实例。

由于未选择从快照创建，快照部分为空。可以通过点击“修改”按钮来调整配置，这与我们刚刚完成的配置过程相同。

RDS 实例已创建，但环境仍在更新其他组件。如前所述，这需要几分钟时间等待。

大约 7 分钟后，我们收到了消息。环境健康状态恢复为“正常”，并且运行良好。

现在，我们的应用程序拥有了一项额外的配置：一个数据库。

探索环境监控与日志

此外，我想向大家展示如何查看与环境相关的日志。您可以在此处配置不同的日志。

您可以请求查看最后一百行日志，或者需要完整日志。要查看完整日志，首先需要在实例上进行配置。

目前我们没有配置，所以此处看不到。您可以点击“健康”查看整体健康状况，或查看我们刚创建的特定实例的监控信息。

我们尚未设置增强监控。此处显示的是免费套餐中提供的基础监控信息。

CPU 使用率为 0.6%。最大网络流入为 69 KB，最大网络流出为 38 KB。您可以随时调整此图表的显示范围。

由于实例是几分钟前刚启动的，数据变化不大。您可以查看 CPU 利用率图表，此处有一个峰值，因为我们在那时启动了 RDS 实例。

通过这种方式，您可以随时监控应用程序及其活动。您还可以将其与 CloudWatch 集成以设置警报。

所有这些服务都可以相互链接，以实现最佳性能和应用监控。您也可以从这里设置警报，或使用 CloudWatch 实现。

虽然本课程重点在 Elastic Beanstalk，但我提及其他 AWS 服务是因为它们都以某种方式与 Elastic Beanstalk 相互关联。Elastic Beanstalk 本质上是一个平台，我们可以在此平台上启动并集成其他 AWS 服务，以构建一个完整的环境。

总结

本节课中，我们一起学习了如何在 AWS Elastic Beanstalk 环境中添加和配置 RDS 数据库。我们完成了从访问配置、设置数据库参数、应用更改到验证创建的完整流程，并简要了解了环境监控和日志查看功能。请务必使用 AWS 账户亲自配置这些服务和应用程序，进行更多探索和实践。

023：课程导论与概述

在本节课中，我们将要学习如何利用AWS Elastic Beanstalk及相关服务，为云项目构建一个自动化的持续集成与持续部署（CI/CD）流程。我们将从核心概念入手，逐步了解整个项目的目标、所需工具以及你将学到的具体技能。

课程概述

本项目旨在加速应用程序的部署流程，即实现持续集成与持续部署。当前，DevOps正迅速成为行业标准，而CI/CD是DevOps流程中与软件开发和发布紧密相关的术语。

简单来说，持续集成是一种允许开发人员每天多次将代码集成到主共享仓库的过程，并即时提供关于功能或测试可能出错的反馈。这避免了在开发周期结束时才去构建和集成来自不同团队或个人的软件工作成果。

通过持续集成，你可以定期构建代码。这有助于开发人员满足代码质量标准，及早解决错误，并降低集成成本。

持续交付是持续集成的延伸，它专注于自动化软件的交付过程。这有助于随时将代码部署到预发布和生产环境。

持续部署则是一个自动构建并将代码部署到服务器的过程。该流程可以完全自动化，实现跨多个环境的构建、测试和部署，并能自动处理故障并回滚到之前良好的状态。

CI/CD工具与AWS方案

当我们谈论使用CI/CD部署应用程序时，市场上有多种工具可以帮助你构建强大的CI/CD流水线，以满足敏捷开发、持续构建、部署和交付的需求。

例如，我们有Jenkins、Travis CI、Gitlab、Bamboo等。这些都是提到CI/CD时，人们通常会立即想到的工具。

但在本项目中，我们将使用AWS原生工具来部署CI/CD流水线。我们将使用AWS CodePipeline、AWS CodeDeploy，并将Elastic Beanstalk作为平台即服务来部署我们的代码。Elastic Beanstalk将在后端为我们自动部署所需的基础设施。

项目难度与目标

这是一个中级难度的项目。你需要对以下AWS服务有一些基本了解：AWS Elastic Beanstalk、AWS CodeCommit、AWS CodeBuild和AWS CodePipeline。

本课程的目标是理解如何利用Elastic Beanstalk为应用程序实现持续集成和持续交付。

什么是AWS Elastic Beanstalk？

Elastic Beanstalk是一个高度托管的服务，用于部署你的代码。在通常的情况下，你需要一台服务器，需要在服务器上配置代码、构建数据库并处理所有安全问题。完成所有这些事情后，你的代码才能在此基础设施上运行。

然而，当我们使用Elastic Beanstalk时，你无需担心所有这些事情。你只需将代码上传到Elastic Beanstalk，它就会自动处理所有所需的基础设施。

你将学到什么

在本项目中，你将学习到以下内容：

  • 使用Elastic Beanstalk部署应用程序的CI/CD流程。
  • Elastic Beanstalk的深入使用。
  • 设置Elastic Beanstalk环境。
  • 设置CodePipeline和CodeDeploy的环境。
  • 如何自动化从代码检入到在Elastic Beanstalk中部署的整个周期。

本项目将涵盖所有这些内容，并提供丰富的实践操作。在学习本项目时，建议你创建一个免费的AWS账户，并熟悉我在此提到的AWS服务，如Elastic Beanstalk、CodeCommit、CodeBuild和CodePipeline。这些服务将极大地帮助你完成整个项目。

目标学员

任何技术人员都可以运行此项目，特别是：

  • 任何试图在其环境中实施CI/CD的技术工程师。
  • 任何云工程师、解决方案架构师或开发人员。
  • 任何希望实施CI/CD并希望采用DevOps模式的经理。

他们都可以将此项目作为样本，并从中尽可能多地学习。

课程收获

完成本课程后，你将：

  • 了解Elastic Beanstalk环境的一些特性。
  • 深刻理解使用Elastic Beanstalk进行部署的方法及其实施。
  • 掌握Elastic Beanstalk的配置知识。
  • 获得一个使用AWS工具实践CI/CD概念的优秀示例。
  • 能够通过跟随本课程，完全独立地构建整个CI/CD流水线。

课程内容大纲

以下是本课程将要涵盖的主题：

  1. 引言
  2. 使用Elastic Beanstalk为CI/CD创建环境
  3. 为开发设置环境（本项目将使用PHP，因此在接下来的课程中将设置PHP环境）
  4. 学习如何设置代码仓库、创建拉取请求并将代码推送到CodeCommit
  5. 项目创建与配置（配置使代码能在Elastic Beanstalk中顺利运行的其他事项）
  6. 理解构建规范（检入代码时需要考虑的事项，以及如何准备代码以减少部署问题）
  7. 设置通知（以便了解代码何时正在构建、部署等，从而跟踪环境状态）
  8. 将代码部署到开发环境，然后部署到生产环境
  9. 在部署流程中设置审批步骤（例如，手动批准代码是否需要部署到开发或生产环境，这对于生产环境是一个很好的策略）

案例研究

本课程将以一个领先的组织为例，该组织正试图使用CI/CD加速其应用程序部署流程。课程将涵盖以下所有场景：

  • 预生产环境设置
  • 开发环境配置
  • 仓库设置
  • 项目开发与配置
  • 通知变更
  • 设置审批
  • 部署到开发和生产环境的流水线

本项目将涵盖所有这些内容。

总结

本节课中，我们一起学习了本CI/CD项目的整体介绍。我们明确了课程目标是利用AWS Elastic Beanstalk及相关服务构建自动化部署流水线，了解了CI/CD的核心概念、将使用的AWS工具组合、项目的难度与目标学员，并预览了整个课程的知识大纲和最终你将获得的实践技能。希望你现在对本项目的内容有了清晰的认识。

024：理解AWS控制台 🖥️

在本节课中，我们将学习如何理解AWS控制台及其工作原理。我们将通过一个具体的项目案例——新冠疫情下的航班监控系统——来演示如何访问AWS服务，并启动Elasticsearch和Kibana服务。

概述

我们的项目是一个用于航空业的疫情航班监控系统。该项目需要使用Elasticsearch和Kibana软件。学习本教程需要具备Linux基础知识，并且你的系统中应已安装Elasticsearch和Kibana。

本课程将解决四个主要问题：

  1. 理解AWS控制台及其工作原理。
  2. 实现所有API，用于在NoSQL数据库中存储和访问数据。
  3. 使用之前创建的NoSQL数据库中的数据，在Kibana中创建饼图、表格和直方图。
  4. 创建一个包含所有数据可视化的仪表板，并应用过滤器来获取数据。

在本节视频中，我们只涵盖第一个问题：理解AWS控制台及其工作原理。我已经使用过AWS控制台，并通过实例创建了一个可共享的IP地址。

什么是AWS控制台？

AWS控制台是一个基于Web的用户界面，它通过EC2实例服务提供对云的访问。

我们可以通过一个比喻来理解：假设你住在一个小房子里，这里没有你需要的所有设施，但你具备使用这些设施的知识，并且你想使用它们。现在，有一栋大房子，里面有你想要使用的所有设施和基本的互联网连接。如果你想在那个特定的地方工作，你需要向那栋房子支付一些费用。现在，为了从小房子到达大房子，你需要一辆特定的自行车，这辆自行车在你想要进入大房子时必须随身携带。

在这个场景中：

  • 小房子代表本地主机。
  • 大房子代表AWS控制台，它允许你将IP地址分享给世界上任何有互联网连接的人。
  • 那辆特定的自行车代表PuTTY，它是进入EC2实例的中介。

访问AWS并启动服务

现在，让我们开始了解如何进入AWS以及如何访问Elasticsearch服务。

这是EC2仪表板。我已经创建了我的实例，并在上面安装了Elasticsearch和Kibana。点击“运行中的实例”。

这就是我已经安装了Elasticsearch和Kibana的实例。它只允许我通过特定的IP地址进入。如你所见，这里的实例状态是“已停止”。现在，我需要启动这个实例。所以我将点击“操作” -> “实例状态” -> “启动”。

与此同时，我们将打开PuTTY，它作为中介，将带我进入EC2实例。

在“主机名”中，我将输入实例启动后将提供的公共IP地址。每次启动服务时，它都会更改公共IP和私有IP地址，我们只能在PuTTY配置中添加那个特定的IP地址。这是公共IP地址：3.7.254.145。输入这个特定的IP地址，然后点击“打开”。

这是一个警告，点击“是”。我已经预先设置好了用户名和密码。

现在，我们已经到达了特定部分。也就是说，我们已经进入了这个特定项目的EC2实例。

启动Elasticsearch和Kibana服务

接下来，我们需要启动Elasticsearch和Kibana的服务。对于这两者，都有相应的命令。

首先，我们将启动Elasticsearch服务。命令是：

sudo service elasticsearch start

然后按回车。现在它正在启动Elasticsearch。我之前已经安装了Elasticsearch，所以我只是启动它的服务。

当我们启动这两个服务后，我们将看到它是如何工作的，以及我们如何在电脑上进入并操作它。

Elasticsearch服务已经启动。现在让我们启动Kibana的服务。命令是：

sudo service kibana start

如果你想停止服务，可以输入 sudo service kibana stop，Elasticsearch同理。

现在，两个服务都已启动。让我们看看它们是否能正常工作。

验证服务

我将打开一个新的浏览器标签页。我将输入这个公共IP地址以及Elasticsearch或Kibana的默认端口。由于我们正在使用Kibana，让我们从Kibana开始。Kibana的基本默认端口是5601。所以地址是：3.7.254.145:5601。

让我们看看它是否启动。它正在加载。我们也可以检查Elasticsearch服务，因为API只在Kibana中编写，Kibana中有一个部分允许我们输入API。所以Elasticsearch只是为了显示它是否正常工作。

让我们看看Elasticsearch或Kibana是否正常工作。是的，我们已经成功进入了Kibana主页，同样也进入了Elasticsearch。

总结

在本节视频中，我已经向你展示了如何进入Kibana。在下一个视频中，我们将在Kibana服务上工作。我们将讨论下一个问题：实现所有API以在NoSQL数据库中存储和访问数据。每个人都应该了解什么是NoSQL数据库。NoSQL数据库没有表，基于文档的概念工作。

现在，像上一个视频一样启动我们的实例。这是我们的实例：“操作” -> “实例状态” -> “启动”。与此同时，让我们启动PuTTY。现在，我们将添加实例将提供给我们的主机名。它仍处于“等待中”状态。

我们知道，在这个视频中，我们将讨论四种API：PUT、POST、GET和DELETE。现在，我们在这里获得了公共IP。将其输入到主机名中。

然后点击“打开”。我们已经创建了用户。好的，现在我们将启动服务。

首先，启动Elasticsearch服务。命令是：

sudo service elasticsearch start

现在正在启动你的Elasticsearch。

当我们启动这两个服务后，我们将进入控制台。现在，启动Kibana服务。命令是：

sudo service kibana start

是的，这个命令，名字变了。现在Kibana也已经启动，但这里的工作已经完成。

现在，我们将首先输入从该实例获得的公共IP：13.234.31.209，以及Kibana的默认端口5601。它正在加载Elasticsearch。

然后，我们必须进入那个可以编写API的特定图标，即“开发工具”。

025：API实现 🚀

在本节课中，我们将学习如何使用Elasticsearch的API进行数据操作，包括创建、读取、更新和删除（CRUD）。我们将通过具体的示例来理解PUT、POST、GET、DELETE和HEAD等HTTP方法在Elasticsearch中的不同用法和区别。

概述

我们将创建一个名为“aviation1”的索引（类似于数据库中的表），并向其中添加文档（类似于表中的行）。通过对比PUT和POST请求，理解它们在指定文档ID时的不同行为。同时，我们也将学习如何使用GET、DELETE和HEAD API来查询、删除和检查数据。

PUT与POST API的区别 🔄

PUT API和POST API都用于创建或更新文档，但它们在处理文档ID的方式上有所不同。

  • PUT API：必须在请求中指定一个文档ID。它将在该特定ID上存储文档。
  • POST API：不要求指定文档ID。Elasticsearch会自动生成一个ID来存储文档。

下面我们通过实际操作来看两者的实现。

创建索引与添加数据

首先，我们创建一个名为 aviation1 的索引。

PUT /aviation1

接下来，我们使用PUT API向索引中添加第一个文档。我们需要指定一个文档ID，例如 1。

PUT /aviation1/_doc/1
{
  “airline”: “Indigo”,
  “category”: “domestic”,
  “source”: “Mumbai”,
  “destination”: “Delhi”,
  “total_flights”: 7,
  “date”: “2023-10-26”,
  “average_rate”: 4500
}

执行成功后，系统会返回确认信息，表示文档已创建。

现在，让我们看看POST API的用法。如果我们尝试在POST请求中不提供ID，Elasticsearch会生成一个随机ID。

POST /aviation1/_doc
{
  “airline”: “Air India”,
  “category”: “domestic”,
  “source”: “Mumbai”,
  “destination”: “Goa”,
  “total_flights”: 4,
  “date”: “2023-10-26”,
  “average_rate”: 3500
}

但是，如果我们尝试在PUT请求中不提供ID，则会收到错误提示，要求必须指定一个ID。

PUT /aviation1/_doc
{
  “airline”: “Test Airline”,
  “category”: “test”
}

错误响应：document missing required [_id] field

因此，PUT和POST的区别已经明确。为了后续演示，我们再使用PUT API添加几条数据。

PUT /aviation1/_doc/3
{
  “airline”: “SpiceJet”,
  “category”: “domestic”,
  “source”: “Delhi”,
  “destination”: “Bangalore”,
  “total_flights”: 5,
  “date”: “2023-10-27”,
  “average_rate”: 5200
}

PUT /aviation1/_doc/4
{
  “airline”: “Vistara”,
  “category”: “international”,
  “source”: “Delhi”,
  “destination”: “London”,
  “total_flights”: 2,
  “date”: “2023-10-28”,
  “average_rate”: 85000
}

使用GET API查询数据 🔍

上一节我们介绍了如何创建数据，本节中我们来看看如何检索数据。GET API主要用于查询操作。

以下是GET API的几种常见用法：

1. 获取所有索引列表
此请求用于查看当前Elasticsearch集群中存在哪些索引。

GET /_cat/indices?v

响应会列出所有索引（如 aviation1, .kibana_1 等）及其状态信息。

2. 获取特定文档的全部信息
通过指定索引名和文档ID，可以获取该文档的完整元数据和内容。

GET /aviation1/_doc/3

响应包含文档ID、版本号、索引名以及我们存储的所有字段数据。

3. 仅获取特定文档的源数据
如果只关心文档中存储的原始数据，而不需要元信息，可以使用此请求。

GET /aviation1/_source/4

响应仅返回我们最初PUT或POST的JSON数据内容。

4. 获取索引下的所有文档
要查询一个索引（如 aviation1）中的所有文档，可以使用搜索API。

GET /aviation1/_search?q=*&pretty

或者使用请求体进行查询：

GET /aviation1/_search
{
  “query”: {
    “match_all”: {}
  }
}

响应会列出索引 aviation1 中所有文档的详细信息，包括我们通过PUT和POST创建的所有记录。

使用DELETE API删除数据 🗑️

我们已经学习了如何创建和查询数据，现在来了解如何删除数据。DELETE API用于删除文档或整个索引。

1. 删除特定文档
通过指定索引名和文档ID来删除单个文档。

DELETE /aviation1/_doc/<document_id>

例如，删除之前通过POST API创建的那个文档（需要先获取其自动生成的ID）：

DELETE /aviation1/_doc/ABCdEfGhIjKlMnOpQ1234

执行成功后，再次使用GET API查询所有文档，将看不到该条记录。

2. 删除整个索引
此操作将删除索引及其中的所有数据，请谨慎使用。

DELETE /<index_name>

例如，尝试删除一个名为 people1 的索引：

DELETE /people1

如果删除成功，响应中会包含 “acknowledged”: true。之后使用 GET /_cat/indices 命令查看，该索引将不再出现在列表中。

使用HEAD API检查存在性 ℹ️

最后，我们来了解一个简单的HEAD API。它不返回文档内容，只用于检查某个文档或索引是否存在。

检查文档是否存在

HEAD /aviation1/_doc/1

如果文档存在，将返回 200 OK 状态码。如果文档不存在（例如查询一个不存在的ID），将返回 404 Not Found 状态码。

检查索引是否存在

HEAD /aviation1

同理，用于检查索引 aviation1 是否存在。

总结

本节课中我们一起学习了Elasticsearch核心的REST API操作。

  1. 创建数据：使用PUT（必须指定ID）或POST（可自动生成ID）API。
  2. 查询数据：使用GET API，可以获取索引列表、特定文档、文档源数据或索引下的全部文档。
  3. 删除数据：使用DELETE API，可以删除特定文档或整个索引。
  4. 检查存在：使用HEAD API，快速检查文档或索引是否存在，而不获取具体内容。

通过实际操作这些API，你已经掌握了在Elasticsearch中进行基本数据管理的方法，这是构建更复杂搜索和分析功能的基础。

026：创建饼图、直方图与数据表 📊

在本节课中，我们将学习如何利用API获取数据，并基于这些数据创建饼图、直方图和数据表。我们将从创建索引模式开始，逐步完成三种不同类型的可视化图表。

首先，我们运行API并查看数据。数据中包含六份文档，每份文档具有不同的ID。接下来，我们将基于这些数据创建饼图、直方图和数据表。

创建索引模式

为了进行数据可视化，首先需要创建一个索引模式。

我们进入深度工具，管理空间，选择“索引模式”，然后点击“创建索引模式”。我们将创建一个名为 aviation_1 的索引模式。在下一步中，我们不使用时间过滤器。

我们使用的字段包括：source（出发地）、destination（目的地）、airline（航空公司）、price_category（价格类别）、date（日期）和 total_flights（总航班数）。

至此，索引模式已创建完成。

创建饼图 🥧

上一节我们创建了索引模式，本节中我们来看看如何创建饼图。

我们进入“可视化”界面，点击“创建新的可视化”，选择“饼图”类型。

以下是创建饼图的具体步骤：

  1. 选择索引模式 aviation_1。
  2. 添加存储桶，选择“切片”类型。
  3. 在聚合方式中选择“词条”。这允许我们自由选择用于创建饼图的字段。
  4. 在本例中，我们希望根据不同的航空公司创建饼图，因此选择字段 airline.keyword。
  5. 自定义标签为“Airlines”，然后点击“更新”。

现在，我们可以看到饼图中显示了不同航空公司的数据切片。我们不希望它是环形图，因此取消选中“环形图”选项。这样，最终的饼图就创建完成了。

我们可以根据需要使用不同的设置进行调整。现在，保存这个饼图，命名为 Aviation_1_Pie_Chart。

创建直方图 📈

饼图创建完成后，接下来我们学习如何创建直方图。

我们再次回到“可视化”界面，点击“创建新的可视化”，这次选择“水平条”类型（用于创建直方图）。

以下是创建直方图的具体步骤：

  1. 选择索引模式 aviation_1。
  2. 添加存储桶，选择“拆分系列”。
  3. 在聚合方式中选择“词条”。
  4. 在本例中，我们希望根据航班类别（国内或国际）来展示直方图，因此选择字段 category.keyword。
  5. 自定义标签为“Aviation Category”，然后点击“更新”。

我们可以进行一些调整，例如将图例位置设置为底部。更新后，直方图的可视化就创建好了。

现在，我们创建一个新的“直方图”可视化，重复类似的过程：

  1. 添加存储桶到X轴。
  2. 选择基于“词条”的聚合方式。
  3. 选择字段 category.keyword，并自定义标签为“Category”。
  4. 更新后，将X轴位置调整到底部。

直方图提供了丰富的设置选项，您可以尝试不同的配置以观察效果。最后，保存这个直方图，命名为 Aviation_1_Histogram。

创建数据表 📋

我们已经创建了饼图和直方图，最后我们来创建数据表。

我们回到“可视化”界面，点击“创建新的可视化”，选择“数据表”类型，并基于 aviation_1 索引模式。

以下是创建数据表的具体步骤：

  1. 添加存储桶，选择“拆分行”。
  2. 选择基于“词条”的聚合方式。
  3. 选择第一个要显示的字段，例如 airline.keyword，并自定义标签为“Airline”。
  4. 重复此过程，依次添加其他字段。字段的添加顺序决定了它们在表中从左到右的显示顺序。
  5. 继续添加 category.keyword（标签为“Category”）、source.keyword（标签为“Source”）、destination.keyword（标签为“Destination”）、total_flights（标签为“Total Flights”）和 average_price（标签为“Average Price”）等字段。
  6. 最后，添加 date 字段（标签为“Date”）。

每添加一个字段并更新后，左侧的表格预览会实时变化。完成所有字段的添加后，完整的数据表就创建好了。

最后，保存这个数据表，命名为 Aviation_1_Data_Table。

总结

本节课中，我们一起学习了数据可视化的基本流程。我们从创建索引模式开始，逐步完成了三种常见图表：饼图、直方图和数据表。通过实际操作，我们掌握了在可视化工具中选择索引、配置聚合方式、添加字段以及自定义图表属性的方法。这些技能是进行数据分析和展示的基础。

027：使用筛选器 📊

在本节课中，我们将学习如何在Kibana仪表板中配置日期格式、整合多个可视化图表，以及使用筛选器来动态过滤和查看数据。我们将通过实际操作，将之前创建的饼图、直方图和数据表整合到一个统一的仪表板中，并应用筛选器进行交互式数据分析。

上一节我们介绍了如何创建数据表。本节中，我们来看看如何调整数据表中的日期显示格式。

在数据表中，可以看到创建时间字段同时包含了日期和时间。现在，我将更改设置以移除时间部分。

为此，需要进入“堆栈管理”。在堆栈管理中，找到“高级设置”。在高级设置里，可以看到“日期格式”选项。你可以根据需求更改日期格式，系统也提供了多种预设格式。

我不希望日期显示中包含时间，因此移除了时间列。这里还有其他日期时间格式可供选择，你可以根据具体要求进行调整。

保存更改后，原本表格中的默认日期时间格式就被更新了。现在回到数据表查看变化，可以看到时间部分已被移除，只保留了所需的日期信息。

现在，让我们看一下仪表板。在最后的视频中，我们的最终目标是创建一个包含所有数据可视化的仪表板，并应用筛选器来过滤数据。在之前的视频中，我们已经创建了饼图、数据表和直方图，现在需要将这三个可视化组件整合到同一个仪表板上。

我们将返回到Elasticsearch页面。之前我们是在创建数据表的页面，现在回到选项菜单，选择“仪表板”。

我们将创建新的仪表板，并添加之前创建并保存在面板页面中的不同可视化组件。

我们会按照希望在仪表板上显示的次序，逐一添加面板。首先，添加“aviation 1”饼图，接着是“aviation 1”直方图，最后是“aviation 1”数据表。

现在可以看到，所有三个可视化组件都呈现在同一个仪表板上了。我们可以根据需要拉伸数据表的大小进行调整。

我们目前所在的这个仪表板可以添加筛选器，以便根据需求查找数据。例如，如果我想查看印度航空的国内客户数据，只需选择“国内”筛选条件。

这样，我就能看到印度航空有2个国内航班的数据。因为首先选择了“国内”筛选器，所以现在仪表板只显示所有国内航班的数据。

如果进一步只想查看印度航空的航班，可以再选择“印度航空”筛选器。现在，仪表板就清晰地展示了印度航空的国内客户数据：首先是孟买到德里的航班，然后是孟买到果阿的航班。

移除筛选器后，显示的内容会恢复原状。这个日期筛选器默认提供过去30天的数据，你也可以选择“今天”或其他自定义日期范围来查看不同时间段内创建的仪表板。

如果你想查看靛蓝航空的数据，也可以更改筛选条件。选择“靛蓝航空”后，可以看到有两条靛蓝航空的航班数据。

这提供了清晰的数据视图，所有筛选器都可以根据你的选择进行排列组合，从而获取相应的数据。

你还可以通过以下方式添加筛选器：首先选择想要添加筛选器的字段，然后设置操作符。例如，操作符可以设置为检查某个特定航空公司是否存在。

你可以相应地添加筛选器、更改日期，并执行尽可能多的调整。也可以根据喜好查看设置，并进行一些隐藏的尝试。

本节课中我们一起学习了如何在Kibana中调整日期格式、创建并整合多图表仪表板，以及使用筛选器进行交互式数据探索。掌握这些技能可以帮助你更高效地定制数据视图和进行深入分析。

posted @ 2026-03-29 09:12  绝不原创的飞龙  阅读(3)  评论(0)    收藏  举报