在 [第 4 章]*中，我们引入了持续集成和持续部署的概念，作为一种弥合 ML 模型开发和 ML 模型部署之间差距的手段。我们还被介绍到 AWS CDK，通过将软件工程师和 ML 实践者开发的不同工件整合到一个单一的云原生应用中，来进一步缩小这个差距。因此，允许我们编纂一个 CI/CD 管道，使整个 ML 过程自动化。弥合这一差距，并帮助促进这种团队间的协同作用，是 AWS 最初创建 CDK 背后的核心设计理念之一。
注意
有关 AWS CDK 理念的更多信息，您可以阅读 AWS CDK 博客帖子中的开发云应用的最佳实践(https://AWS . Amazon . com/blogs/devo PS/best-practices-for-developing-cloud-applications-with-AWS-CDK/)。
尽管我们已经开始创建用于训练和部署 ML 模型的核心机制，但是我们还没有创建负责协调流程的整体管道。在这一章中，我们将继续整理 CI/CD 管道结构，以及 ML 模型工件，从我们停止的地方继续。以下主题将强调我们将如何完成这些任务:
- 部署 CI/CD 管道
- 构建 ML 模型工件
- 执行 CI/CD 管道
技术要求
本章将使用以下资源:
- web 浏览器(为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器)。
- 访问您在前面章节中使用的 AWS 帐户。
- 在 [第四章]*中访问你用来开始构建 CDK 应用的 Cloud9 IDE。
- 访问我们在 [第三章] B17649_03_ePub.xhtml##_idTextAnchor048
- 我们将再次在 AWS 免费层的使用限制内工作，以避免超出不必要的成本。
- 本章的配套 GitHub 存储库中提供了 CDK 构造和 ML 模型工件的源代码示例(https://GitHub . com/packt publishing/Automated-Machine-Learning-on-AWS/tree/main/chapter 05)。
部署 CI/CD 管道
您将从 [第 4 章]*中回忆起，我们通过检查内在工件，即buld.py和deploy.py脚本，并将它们提交到 CodeCommit 库中来结束这一章。尽管这些工件从根本上创建和部署了一个训练有素的 ML 模型，我们仍然需要将它们包装在一个持续的集成和持续的部署过程中。为了实现这一点，我们将继续使用 AWS CDK 来创建一个编码的 CI/CD 管道结构。
整理管道结构
应用的倒数第二个组件是管道构造本身。通过以下步骤，我们将再次利用 AWS CDK 来创建渠道:
- 如果您还没有在 web 浏览器中打开 Cloud9 环境，请登录您一直使用的 AWS 帐户，并打开您的 AWS 区域的 Cloud9 管理控制台(https://console.aws.amazon.com/cloud9)。点击打开 IDE 按钮启动 Cloud9 实例。一旦 Cloud9 实例上线，通过运行以下命令，使用终端面板激活 Python 虚拟环境:
$ cd ~/environment/abalone-cicd-pipeline/ $ source .venv/bin/activate - 现在，运行以下命令将预构建的管道构造
abalone_cicd_pipeline_stack.py添加到abalone_cicd_pipeline文件夹:abalone_cicd_pipeline_stack.py construct was created for you. We will be replacing this file with an updated version, pre-built for our example. If you have not already cloned the companion GitHub repository, you can refer to the *Codifying the SageMaker Endpoint* section in *Chapter 4*, *Continuous Integration and Continuous Delivery (CI/CD) for Machine Learning*. - 使用 Cloud9 工作区的左侧导航面板，双击更新版本的
abalone_cicd_pipeline_stack.py文件进行查看。
当我们浏览代码时，您会注意到的第一件事是，我们导入了必要的 CDK 模块，我们将使用这些模块来创建构造资源。我们将在本合同中使用的主要模块是aws_codepipeline、aws_codpipeline_actions、aws_codebuild和aws_iam模块。
接下来，从下面的代码片段中可以看到，我们将PipelineStack()类定义为cdk.Stack，并初始化它:
...
class PipelineStack(cdk.Stack):
def __init__(self, scope: Construct, id: str, *, model_name: str=None, repo_name: str=None, cdk_version: str=None, **kwargs) -> None:
super().__init__(scope, id, **kwargs)
...
正如您在前面的代码片段中看到的，我们还提供了一些关键参数，即model_name、repo_name和cdk_version来初始化该类。这些参数特定于我们的 CDK 应用，将在本章稍后实例化 CDK 应用本身时定义。
一旦我们初始化了构造，我们需要创建的第一个资源是sagemaker_role。这是一个 IAM 角色，运行时逻辑脚本，即build.py和deploy.py，将承担执行各种 SageMaker 任务。例如，sagemaker_role拥有对 SageMaker 服务的完全访问权限，以便处理训练数据、训练、评估和部署模型。
接下来，我们为包含工件源代码的存储库定义变量。例如，我们定义了一个名为container_repo的变量来声明 CodeCommit 存储库，以及一个名为s3_bucket的变量，原始的训练数据和管道执行工件将存储在这里。
接下来，我们定义四个代码构建项目中的第一个。这些 CodeBuild 项目执行运行时逻辑，以从本质上构建所需的管道资产，这些资产预处理数据、训练 ML 模型、评估 ML 模型以及构造部署模型所需的部署参数。例如，如下面的代码片段所示，container_build项目获取 ML 模型工件并执行运行时逻辑来构建工件并将其存储为 Docker 映像:
...
build=dict(
commands=[
"echo Build started on `date`",
"echo Building the Docker image...",
"docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG --build-arg REGION=$AWS_DEFAULT_REGION ."
]
),
post_build=dict(
commands=[
"echo Build completed on `date`",
"echo Pushing the Docker image...",
"docker push $IMAGE_REPO_NAME:$IMAGE_TAG"
]
)
...
由于我们将基于 AWS 深度学习容器的 Docker 容器映像，使用来自 [第 3 章] B17649_03_ePub.xhtml##_idTextAnchor048) ，的相同方法，通过自动运行自动化复杂的模型开发，我们还需要为 CodeBuild 项目提供访问容器库的必要权限。您可以从下面的代码片段中看到，我们将 IAM `PolicyStatement(
...
container_build.role.add_to_policy(
iam.PolicyStatement(
resources=[
"arn:aws:ecr:*:763104351884:repository/*",
"arn:aws:ecr:*:217643126080:repository/*",
"arn:aws:ecr:*:727897471807:repository/*",
"arn:aws:ecr:*:626614931356:repository/*",
"arn:aws:ecr:*:683313688378:repository/*",
"arn:aws:ecr:*:520713654638:repository/*",
"arn:aws:ecr:*:462105765813:repository/*"
],
actions=[
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
effect=iam.Effect.ALLOW
)
)
...
我们定义的下一个 CodeBuild 项目叫做data_build，它执行数据处理任务的运行时逻辑。从下面的代码片段中可以看到，我们运行之前创建的build.py脚本，并提供preprocess参数，告诉 Python 脚本对 SageMaker 进行 API 调用，以运行处理作业:
...
"build": {
"commands": [
"echo Build started on `date`",
"python ./artifacts/scripts/build.py preprocess"
]
},
...
接下来的两个 CodeBuild 项目，即model_build和evaluation_build，执行与data_build项目相同的运行时逻辑。除了model_build向build.py脚本提供train参数，以对 SageMaker 进行 API 调用来运行 ML 模型训练作业。例如，您可以看到下面的代码片段，其中train参数被提供给 CodeBuild 项目:
...
"build": {
"commands": [
"echo Build started on `date`",
"python ./artifacts/scripts/build.py train"
]
},
...
或者，evaluation_build项目向build.py脚本提供evaluate参数，以对 SageMaker 进行 API 调用，从而运行评估训练好的 ML 模型的处理作业。
我们创建的最后一个代码构建项目叫做deployment_build。这里，我们为deploy.py文件定义运行时逻辑。您将从 [第 4 章]*中回忆起，deploy.py脚本从管道中捕获执行参数以部署 SageMaker 端点堆栈。
从下面的代码片段中可以看到，deployment_build项目为端点堆栈合成或生成了 CloudFormation 模板，称为EndpointStack.template.json。
创建模板文件后，deployment_build项目执行deploy.py脚本来生成部署堆栈模板所需的必要云信息参数，并将这些参数存储在params.json文件中:
...
"build": {
"commands": [
"echo Synthesizing cdk template",
"npx cdk synth -o output"
]
},
"post_build": {
"commands": [
"python ./artifacts/scripts/deploy.py"
]
}
},
artifacts={
"base-directory": "output",
"files": [
"EndpointStack.template.json",
"params.json"
]
}
...
既然我们已经有了相关的运行时逻辑来构建模型工件容器映像，预处理训练数据，训练 ML 模型，然后评估 ML 模型的性能，我们 put 可以将这些组件放在一起，以构建 CI/CD 管道来自动化该过程。使用pipeline变量，我们定义了管道的整体结构，如您所见，管道是由四个连续步骤组成的或管道阶段:
- 来源
- 建设
- 同意
- 部署 源阶段指的是我们的 CodeCommit 库，它由两个分支组成。更新这些源中的任何一个都将触发管道的发布执行:
- 主分支包含编码的管道。
- 模型分支包含 ML 模型工件。 构建阶段执行四个 CodeBuild 项目，作为流水线操作，创建流程的持续集成阶段，并编译或构建 ML 模型资产。四个管道动作如下:
- ContainerBuild 动作从模型源创建容器映像，并将其上传到 ECR 存储库。
- 用于创建 SageMaker 处理作业的
build.py脚本，通过它对原始训练数据进行预处理，为模型训练做好准备。 build.py脚本，传入train参数来创建 SageMaker 训练作业，以构建优化的模型。- 最后是
build.py脚本，传入evaluate参数来创建 SageMaker 处理作业，该作业评估已训练模型的性能，以评估其生产准备情况。 批准阶段将通过创建一个手动决策门来暂停流水线，由此应用所有者将评估模型的性能结果，并手动批准或拒绝模型进行生产。如果评估被拒绝，管道执行将停止，跨职能团队将评估需要进行哪些源代码更改来改进模型。如果评估通过，管道自动转换到部署阶段。 部署阶段实质上是流程的连续部署阶段，由以下管道动作组成: DeploymentBuild动作是一个 CodeBuild 项目，它合成端点 CDK 构造并执行deploy.py脚本以从运行的管道中收集部署参数。DeployEndpoint动作部署合成的 CloudFormation 模板来创建端点堆栈，并将批准的模型部署到生产中。
既然已经创建了各种应用组件，最后的任务是配置 CDK 应用。
创建 CDK 应用
以下步骤将引导您完成添加最终代码以完成 CDK 应用的过程:
- 使用 Cloud9 工作区的导航面板，运行以下命令从配套的 GitHub 存储库中复制
app.py文件，以替换在 CDK 初始化期间创建的模板文件:$ cd ~/environment/abalone-cicd-pipeline/ $ cp ~/environment/src/Chapter05/cdk/app.py . - 现在，双击
app.py文件，我们可以查看它。
当我们查看app.py文件时，您可以看到我们导入了必要的库，以及我们之前创建的EndpointStack()和PipelineStack()类。接下来，正如您可以从下面的代码片段中看到的，我们定义了特定于我们的应用的参数，即 ML 模型的名称、CodeCommit 存储库的名称以及我们已安装的 AWS CDK 的当前版本:…
MODEL = "abalone"
CODECOMMIT_REPOSITORY = "abalone-cicd-pipeline"
CDK_VERSION = "2.3.0"
...
接下来，我们使用cdk.App()定义 CDK 应用本身，如下面的代码片段所示，我们声明了一个EndpointStack()类的实例，同时提供了必要的 CDK 应用参数，包括当前的 AWS 区域以及我们正在使用的 AWS 帐户:
...
EndpointStack(
app,
"EndpointStack",
env=cdk.Environment(account=os.getenv("CDK_DEFAULT_ACCOUNT"), region=os.getenv("CDK_DEFAULT_REGION")),
model_name=MODEL
)
...
最后，如下一个代码片段所示，我们声明了一个PipelineStack()的实例，并提供了构造所需的 CDK 应用参数:
...
PipelineStack(
app,
CODECOMMIT_REPOSITORY,
env=cdk.Environment(account=os.getenv("CDK_DEFAULT_ACCOUNT"), region=os.getenv("CDK_DEFAULT_REGION")),
model_name=MODEL,
repo_name=CODECOMMIT_REPOSITORY,
cdk_version=CDK_VERSION
)
...
我们现在已经创建了我们的 CDK 应用，并准备好进行部署。下一节将向您展示如何部署应用。
部署管道应用
在 AWS 上部署应用相对简单。以下步骤将使用 Cloud9 workspace 终端引导您完成这一过程:
- 在部署应用之前，我们需要确定应用的依赖关系。由于 ML 模型需要原始的训练数据，我们需要从 UCI 库中下载数据。运行以下命令获取训练数据:
$ cd ~/environment/abalone-cicd-pipeline/ && mkdir -p artifacts/data $ wget -c -P artifacts/data https://archive.ics.uci.edu/ml/machine-learning-databases/abalone/abalone.data - 接下来，我们需要通过指定我们正在使用的 AWS 区域以及我们的 AWS 帐户来配置 CDK 环境。运行以下命令来引导 CDK 环境:
$ cdk bootstrap aws://$/${CDK_DEFAULT_REGION} - 现在，我们可以通过运行以下命令来部署管道应用:
y, and hit *Enter*.
应用应该需要大约 2 分钟来部署，您可以在 Cloud9 终端或 CloudFormation 控制台(https://console.aws.amazon.com/cloudformation/)中查看进度。
在 CloudFormation 堆栈完成之后，我们可以通过将应用代码提交到 CodeCommit 存储库中来触发管道发布。运行以下命令创建 CDK 应用的初始提交:
$ git add –A
$ git commit -m "Initial commit of Pipeline Artifacts"
$ git push
现在，您可以在 CodePipeline 控制台(https://console.aws.amazon.com/codesuite/codepipeline/)中查看管道，并在控制台的导航窗格中单击 Pipeline 。图 5.1 显示了您可能会看到的一个例子: ![Figure 5.1 – CodePipeline console ]
图 5.1–代码管道控制台
从图 5.1 可以看出，鲍鱼-cicd-pipeline 有失效。如果你点击管道打开细节，你会看到它的源阶段已经失效，如图图 5.2 所示。 ![Figure 5.2 – Failed Source stage ]
图 5.2–失败的源阶段 图 5.2 显示了流水线的源阶段，从例子中可以看出模式源动作已经失败。这是因为 ML 从业者团队还没有创建任何模型源工件。在下一节中，我们将创建这些工件。
构建 ML 模型工件
到目前为止，我们已经关注了通常由应用开发团队执行的各种任务，为自动化过程的整体结构创建了一个 CDK 应用。在本节中，我们将继续这项工作，但是从 ML 从业者的角度来看，我们将创建 ML 模型本身，以及负责执行数据处理、ML 模型训练和 ML 模型评估过程的工件。以下步骤将向您展示 ML 从业者如何做到这一点:
- 使用你的 AWS 账户，打开 SageMaker 控制台(https://console.aws.amazon.com/sagemaker/home)。
- 使用左侧菜单面板，点击 Studio 选项，打开 SageMaker 域仪表板。
- In the SageMaker Domain dashboard, click on the Launch app drop-down menu and select Studio to launch the Studio UI in the browser. 注意
_idTextAnchor032
- 启动 Studio UI 后，点击文件菜单，然后点击新建，选择终端，启动新终端。
- 接下来，我们将克隆配套的 GitHub 存储库来访问预构建的工件。在终端中，运行以下命令:
$ cd ~ $ git clone https://github.com/PacktPublishing/Automated-Machine-Learning-on-AWS src - 现在，我们将克隆管道存储库。在终端中运行以下命令，获取 CodeCommit 存储库的地址，并克隆它:
$ CLONE_URL=$(aws codecommit get-repository --repository-name abalone-cicd-pipeline --query "repositoryMetadata.cloneUrlHttp" --output text) $ git clone $CLONE_URL - 运行以下命令来创建模型工件分支:
$ cd ~/abalone-cicd-pipeline/ $ git checkout -b model - 在我们能够创建模型工件之前，我们需要从新的分支中清除现有的代码。运行以下命令创建一个新的分支:
$ git rm -rf . - 通过运行以下命令，将预构建的 Jupyter 笔记本从克隆的配套 GitHub 存储库中复制到模型分支:
$ cp ~/src/Chapter05/Notebook/Abalone\ CICD\ Example.ipynb . - In the navigation panel of the Studio UI, double-click on Abalone CICD Example.ipynb to open the notebook for review. 注意 Jupyter 笔记本需要 Python 3(数据科学)内核，这可能需要 2 分钟才能启动。
- Jupyter 内核启动后，从内核菜单，点击重启内核并运行所有单元……选项，执行所有笔记本代码单元。
一旦所有的代码单元都被执行了，你应该会看到我们遵循了一个与我们在 [第三章] B17649_03_ePub.xhtml##_idTextAnchor048
model.pyapp.pynginx.confwsgi.pyDockerfile
让我们在容器映像的上下文中回顾一下这些组件文件的作用。
查看建模文件
model.py文件主要负责与 ML 模型本身相关的所有任务。正如您将看到的，有三个核心 Python 函数来处理准备训练数据、训练 ML 模型和评估 ML 模型的任务。例如，preprocess()函数将获取原始数据，通过对分类值进行编码来预处理数据集，然后将数据拆分为训练(80%的数据)数据集、验证(15%的数据)数据集和测试(5%的数据)数据集。
处理完数据后，我们使用train()函数编译并拟合张量流模型。然后保存训练好的模型用于评估和推断。
我们将作为模型运行时的一部分创建的最后一个函数是evaluate()函数。该函数将使用load_model()函数加载模型，评估已训练模型的质量，然后通过save_report()函数保存报告。
因此，通过在建模文件中创建这些核心函数，我们有了一个单一的运行时脚本，它处理生成一个候选产品模型以供批准的主要功能。
让我们进一步回顾一下建模文件是如何使用的，接下来也深入到app.py中。
审查申请文件
在持续集成和持续部署的背景下，模型工件将执行两个功能，模型训练和模型托管。为了包装运行时逻辑来确定模型工件执行这两个任务中的哪一个，笔记本生成的第二个文件是app.py文件。这个文件作为容器映像的主入口点，根据传递给这个入口点的参数，app.py文件中的运行时逻辑将决定是训练还是托管模型。
例如，如果您参考我们在上一节中创建的build.py文件，如下面的代码片段所示，为了将数据预处理为 SageMaker 处理作业，handle_data()函数调用create_processing_job() SageMaker API。作为 API 调用的AppSpecification参数的一部分，我们提供了容器映像 URI，以及app.py入口点的preprocess参数:
...
def handle_data(model_name=None, execution_id=None):
try:
response = sagemaker_client.create_processing_job(
ProcessingJobName=f"-ProcessingJob-{execution_id}",
ProcessingResources={
'ClusterConfig': {
'InstanceCount': 1,
'InstanceType': 'ml.m5.xlarge',
'VolumeSizeInGB': 30
}
},
StoppingCondition={
'MaxRuntimeInSeconds': 3600
},
AppSpecification={
'ImageUri': f":latest",
'ContainerEntrypoint': ["python", "app.py", "preprocess"]
},
...
因此，当 SageMaker 初始化容器映像以运行处理作业时，它将运行app.py作为入口点，并提供preprocess参数。现在，如果我们引用app.py文件中的__main__例程，如下一段代码中突出显示的，我们可以看到，当提供了preprocess参数时，主程序将依次执行model.py文件中的preprocess()函数:
...
if __name__ == "__main__":
print(f"Tensorflow Version: ")
if len(sys.argv) < 2 or ( not sys.argv[1] in [ "serve", "train", "preprocess", "evaluate"] ):
raise Exception("Invalid argument: you must specify 'train' for training mode, 'serve' for predicting mode, 'preprocess' for preprocessing mode or 'evaluate' for evaluation mode.")
preprocess = sys.argv[1] == "preprocess"
train = sys.argv[1] == "train"
evaluate = sys.argv[1] == "evaluate"
if preprocess:
model.preprocess()
elif train:
model.train()
elif evaluate:
model.evaluate()
else:
cpu_count = multiprocessing.cpu_count()
model_server_timeout = os.environ.get('MODEL_SERVER_TIMEOUT', 60)
model_server_workers = int(os.environ.get('MODEL_SERVER_WORKERS', cpu_count))
start_server(model_server_timeout, model_server_workers)
...
现在，如果您继续检查前面的代码片段，您可以进一步看到，如果将train或evaluate参数提供给入口点，相同的整体概念适用于模型训练，以及模型评估过程。
或者，如果没有提供这些参数，应用包装器将执行托管任务，从而提供经过训练的模型作为托管端点。接下来，我们将检查托管模型所必需的附加工件文件。
查看模型服务文件
由于模型将使用 Python 的 Flask 框架(https://Flask . pallets projects . com)提供服务，我们需要添加 web 服务组件，如 NGINX(https://www.nginx.com/)和 WSGI(https://www . pallets projects . com/p/werk zeug/)。这些 web 服务组件的配置存储在nginx.conf和wsgi.py文件中。
查看容器构建文件
我们在笔记本中创建的最后一个文件是Dockerfile。该文件将执行容器构建指令，从 AWS 下载 TensorFlow 2.5 深度学习容器，配置 web 服务包，并将模型工件复制到容器中。
既然我们已经查看了组成容器映像工件的文件，我们可以继续更新源代码存储库了。
提交 ML 工件
ML 从业者执行的最后一个任务是将模型工件提交到 CodeCommit 存储库中，从而触发 CI/CD 管道的发布。为此，使用 Studio UI 的终端选项卡运行以下命令:
$ cd ~/ abalone-cicd-pipeline/
$ git add –A
$ git config --global user.email "<ENTER YOUR EMAIL ADDRESS>"
$ git config --global user.name "<ENTER YOUR NAME>"
$ git commit -m "Initial commit of model artifacts"
$ git push --set-upstream origin model
注意
确保在提交新工件时替换您唯一的电子邮件地址和用户名。这样，任何触发新版本的代码变更都可以被跟踪。
如果我们假设 ML 从业者已经执行了适当的单元测试，以确保数据处理、模型训练和评估功能正常工作，并且由于我们已经将这些工件提交到 CodeCommit 存储库中，我们最终可以将 ML 模型自动部署到生产中。下一部分将回顾模型发布过程。
执行自动化 ML 模型部署
审查管道的执行是通过代码管道控制台(https://console . AWS . Amazon . com/code suite/code pipeline/home)完成的，然后通过点击鲍鱼-cicd-管道名称。一旦管道仪表板打开，您将立即看到的第一件事(如图图 5.3 所示)是源阶段已经成功。 ![Figure 5.3 – Succeeded Source stage ]
图 5.3–成功的源阶段
一旦源阶段成功，管道自动移动到构建阶段，实质上是执行 CI/CD 流程的持续集成阶段。图 5.4 显示了涵盖持续集成的四个阶段动作。 ![Figure 5.4 – Continuous integration phase of the pipeline ]
图 5.4–管道的持续整合阶段
从图 5.4 中，有几项需要注意。首先，注意流水线执行 ID 。这个 ID 用于跟踪 ML 模型的发布，因为它被嵌入到各个 SageMaker 作业的名称中。该 ID 还被用作一个 S3 文件夹，其中包含管道使用的所有相关资产。例如，通过打开 S3 控制台(https://S3 . console . AWS . Amazon . com)中的 ID 文件夹，您可以看到模型资产、训练、验证和测试数据集，以及模型评估报告。
其次，通过点击每个阶段操作的细节链接，您可以查看每个 CodeBuild 项目的输出。回想一下，创建 CodeBuild 项目是为了执行管道的容器映像构建、数据处理、模型训练和模型评估步骤。
所以，如果你点击ModelTrainingBuild项目。如果你向下滚动，你会看到来自构建日志的输出。图 5.5 显示了 ML 模型训练的代码构建日志输出示例。
![Figure 5.5 – CodeBuild log output for model training
]
图 5.5–模型训练的代码构建日志输出
从图 5.5 中可以看到，CodeBuild 项目执行build.py脚本并提供train参数。您将回忆起train参数指示build.py文件执行handle_train()函数，由此 SageMaker 被指示运行一个训练作业，并使用模型工件容器映像来训练 ML 模型。
注意
由于各种 CodeBuild 项目执行 API 调用来触发 SageMaker 作业进行数据处理、模型训练和模型评估，您可以使用 SageMaker 控制台(https://console.aws.amazon.com/sagemaker/home)查看 SageMaker 特定的日志。
最后，通过点击管道的 MainSource 和 ModelSource 分支的源代码提交 id，您可以跟踪发布版本中做了哪些代码更改，以及是谁做了这些代码更改。
因此，一旦完成了管道的持续集成阶段，并且评估了训练模型,管道就会暂停以等待人工批准。图 5.6 显示了批准阶段的示例: ![Figure 5.6 – Manual Approval stage ]
图 5.6–人工批准阶段
正如您从图 5.6 中看到的，管道处于待决状态，等待满足用例的验收标准，以便继续模型的部署。正是在这个阶段，各种应用所有者审查经过训练的候选模型的质量，并确定该模型是否被认为是生产级的。
由于评估报告是 pipeline 资产，因此可以使用 S3 控制台进行查看。通过打开管道的 S3 桶，展开管道执行 ID 的文件夹，然后打开evaluation子文件夹，应用所有者就可以打开evaluation.json文件来查看评估报告。以下是evaluation.json的一个例子:
{
"regression_metrics": {
"rmse": {
"value": 1.4838999769750487
},
"mse": {
"value": 2.20195914166655
}
}
}
在报告中，应用所有者可以看到rmse和mse评估指标结果，以决定他们是批准还是拒绝该模型。然后，通过在代码管道控制台中点击 Review 按钮，并添加任何可选的注释，将该决定应用于管道。然后，应用所有者可以点击拒绝或批准按钮。图 5.7 显示了管道审查流程的一个示例:
![Figure 5.7 – Pipeline Review
]
图 5.7–管道审查
一旦管道审核获得批准，管道执行将进入持续的部署阶段。此时，通过 DeploymentBuild 动作从当前管道执行中捕获适当的 CloudFormation 参数，并使用 DeployEndpoint 动作部署 SageMaker 端点。图 5.8 显示了管道连续部署阶段的示例: ![Figure 5.8 – Continuous deployment phase of the pipeline ]
图 5.8–管道的持续部署阶段
如图 5.8 所示，一旦部署点动作完成，我们现在就有了一个经过批准的生产模型，可以集成到年龄计算器应用中，为鲍鱼年龄预测服务。
由于 CDK 应用工件和 ML 工件存在于它们自己的代码库的专用分支中，管道或 ML 工件的任何进一步开发都由各自的应用团队或 ML 从业者拥有和管理。反馈循环中对这些分支所做的任何修正或更新都将导致 CI/CD 管道的发布变更，并将 ML 模型的新版本部署到生产中。
所以，现在我们已经用展示了如何持续集成和持续部署年龄计算器的例子，我们可以清理各种资源了。
清理
为了节省 AWS 资源成本，建议删除部署和管道资产。以下步骤将指导您完成这一过程:
- 打开 CloudFormation 控制台(https://console.aws.amazon.com/cloudformation/home)，点击 EndpointStack 打开堆栈详情。
- 现在点击 Delete 按钮来删除 SageMaker 端点、端点配置和训练好的模型工件。
- Once the stack has been deleted, repeat the same process for the abalone-cicd-pipeline stack. 注意 由于管道的 S3 桶和鲍鱼 ECR 存储库不为空，堆栈删除应该会失败。您必须手动清空这些资源，然后尝试删除堆栈。您还可以删除鲍鱼-cicd-pipeline CodeCommit 存储库。但是，不要删除 Cloud9 环境，因为我们将在下一章使用它。
总结
在这一章中，我们继续构建我们在第四章中开始的用于机器学习的 [【持续集成和持续交付 B17649_04_ePub.xhtml##_idTextAnchor061
还向您介绍了敏捷的跨职能团队的重要性，这是自动化 ML 解决方案成功的关键。我们看到了这些不同的团队如何在 ML 建模过程(从 ML 实践者的角度)和自动化模型部署(从应用开发和操作团队的角度)之间架起了桥梁。
此外，在本章中，您看到了如何使用 AWS 开发工具，即 CodeCommit、CodeBuild 和 CodePipeline 来编排 CI/CD 流程。通过实际操作的例子，您亲眼看到了在 [第 1 章] B17649_01_ePub.xhtml##_idTextAnchor015
在接下来的几章中，我们将继续扩展流程、工具和人员的概念，为年龄计算器用例构建自动化机器学习软件开发生命周期。
文章列表
- AWS自动化机器学习-一、AWS 上的自动化机器学习入门
- AWS自动化机器学习-七、使用 AWS 步骤函数构建 ML 工作流
- AWS自动化机器学习-三、使用 AutoGluon 技术自动化复杂的模型开发
- AWS自动化机器学习-九、使用 Amazon Managed Workflows 为 Apache AirFlow 构建 ML 工作流
- AWS自动化机器学习-二、使用 SageMaker 自动驾驶器自动化机器学习模型开发
- AWS自动化机器学习-五、自动化 ML 模型的持续部署
- AWS自动化机器学习-八、使用 Apache Airflow 实现机器学习过程的自动化
- AWS自动化机器学习-六、使用 AWS 步骤函数自动化机器学习过程
- AWS自动化机器学习-十、机器学习软件开发生命周期（MLSDLC）简介
- AWS自动化机器学习-十一、MLSDLC 的持续集成、部署和训练
- AWS自动化机器学习-四、机器学习的持续集成和持续交（CI/CD）
- AWS自动化机器学习-第一部分：自动机器学习过程和 AWS 上的 AutoML 的基础知识
- AWS自动化机器学习-第三部分：优化以源代码为中心的自动化机器学习方法
- AWS自动化机器学习-第二部分：通过持续集成和持续交付（CI/CD）实现机器学习过程的自动化
- AWS自动化机器学习-第五部分：自动化 AWS 上的端到端生产应用
- AWS自动化机器学习-第四部分：优化以数据为中心的自动化机器学习方法
- AWS自动化机器学习-零、前言
