aws s3 api_在AWS中为网络核心3 x Web API设置连续交付CD管道

aws s3 api

One of my clients whose application runs on AWS had no Continuous Integration (CI). When we decide to use Continous Delivery (CD) for a new NET Core 3.x Web API, it was important that we do it using AWS tools/services as much as possible as this will make their life easier: no new accounts like Azure DevOps need to be managed, they can control access in a single place (AWS IAM), and so on.

我的应用程序在AWS上运行的一位客户没有持续集成(CI)。 当我们决定对新的NET Core 3.x Web API使用连续交付(CD)时 ，重要的是我们尽可能多地使用AWS工具/服务，因为这会使它们的生活更轻松：没有像Azure这样的新帐户需要对DevOps进行管理，它们可以在单个位置(AWS IAM)控制访问，依此类推。

Looking at AWS offering, we opted for:

查看AWS产品 ，我们选择了：

• AWS CodePipeline as Continous Delivery (CD) service;

  AWS CodePipeline作为连续交付(CD)服务 ；

• AWS CodeBuild as a “fully managed build service that compiles source code, runs tests, and produces software packages that are ready to deploy”; We will also use AWS CodeBuild not just to build the project but to run Entity Framework Core migrations as well ;)

  AWS CodeBuild作为“ 完全托管的构建服务，可以编译源代码，运行测试并生成可以部署的软件包 ”； 我们还将使用AWS CodeBuild不仅构建项目，而且还运行Entity Framework Core迁移 ;)

步骤1：自动建立程式码，也称为持续整合(CI) (Step 1: Automatically build the code aka Continous Integration (CI))

AWS CodeBuild requires your build specification to be defined in a buildspec file.

AWS CodeBuild要求您在buildspec文件中定义您的构建规范。

A buildspec is a collection of build commands and related settings, in YAML format, that CodeBuild uses to run a build.

buildspec是YAML格式的构建命令和相关设置的集合，CodeBuild用于运行构建。

So let's start by adding a buildspec.yml file in the root of your project like this:

因此，让我们首先在项目的根目录中添加一个buildspec.yml文件，如下所示：

AWS CodeBuild buildspec.yml example file for a .Net core 3.x Web API

.Net Core 3.x Web API的AWS CodeBuild buildspec.yml示例文件

As you can see, we are:

如您所见，我们是：

1. restoring and build our API project using .Net Core CLI;

   使用.Net Core CLI恢复并建立我们的API项目;

2. publishing a runtime-dependent executable for a specific platform. Yes, we will deploy this in Linux through AWS Elastic Beanstalk later on;

   发布特定平台的与运行时相关的可执行文件 。 是的，我们稍后将通过AWS Elastic Beanstalk将其部署在Linux中 。

3. you may want to publish if tests succeed by run dotnet test first;

   您可能想通过先运行dotnet test来发布测试是否成功；

Time to test :)

测试时间：)

1. Create an AWS CodePipeline:
   创建一个AWS CodePipeline：

AWS CodePipelines: Choose pipeline settings

AWS CodePipelines：选择管道设置

2. Add a source provider and select which branch should trigger a build:

2.添加源提供者，然后选择哪个分支应触发构建：

AWS CodePipelines: Add source stage

AWS CodePipelines：添加源阶段

By the time I’m writing, there isn’t a GitHub action supported by AWS to deploy to AWS Elastic Beanstalk but I bet that won’t take long to come so you may completely rely upon GitHub Actions if that is an option to you :). By the time I made this, GitHub actions were about to be announced ;)

在撰写本文时， AWS没有支持将GitHub操作部署到AWS Elastic Beanstalk，但是我敢打赌，不久之后它就会出现，因此如果您可以选择的话，您可以完全依靠GitHub Actions :)。 到我写这篇文章的时候，GitHub的动作即将宣布;)

3. And finally, add a build stage based on the AWS CodeBuild project. I strongly recommend that you create a new AWS CodeBuild project by AWS CodePipeline as this will configure some things automatically for you like the Source Provider as AWS CodePipeline

3.最后，添加一个基于AWS CodeBuild项目的构建阶段。 我强烈建议您通过AWS CodePipeline创建一个新的AWS CodeBuild项目，因为这将自动为您配置一些东西，例如将源提供程序作为AWS CodePipeline

AWS CodePipelines: Add build stage

AWS CodePipelines：添加构建阶段

As you can see, we are using builspec file that we previously placed in the root of our project :)

如您所见，我们使用的是先前放置在项目根目录中的builspec文件：)

Done! You can skip deploying stage by now just to check that builds works ;) As soon as you save the pipeline, a new build will be automatically triggered. The same will happen for future commits in the source branch that you choose at step 2. — “Add source stage” ;)

完成 ！ 您现在可以跳过部署阶段，仅检查构建是否正常；)保存管道后，将自动触发新的构建。 对于您在步骤2中选择的源分支中的将来提交，也会发生同样的情况。-“添加源阶段”;)

第2步：自动部署代码，也称为连续交付(CD) (Step 2: Automatically deploy your code aka Continous Delivery (CD))

How you set the deploy stage, it depends on how you host your API. As we are using AWS, we decide to with AWS Elastic Beanstalk as it is an “easy-to-use service for deploying and scaling web applications” on several platforms. If you are using something else than AWS Elastic Beanstalk to manage your hosting environment in AWS, it is very likely that you end up using AWS CodeDeploy instead of AWS Elastic Beanstalk at “Deploy stage”.

如何设置部署阶段，取决于您托管API的方式 。 在使用AWS时，我们决定使用AWS Elastic Beanstalk，因为它是在多个平台上“ 用于部署和扩展Web应用程序的易于使用的服务 ”。 如果您要使用AWS Elastic Beanstalk之外的其他工具来管理AWS中的托管环境，那么很可能最终会在“部署阶段”使用AWS CodeDeploy代替AWS Elastic Beanstalk。

So, let's start by creating an AWS Elastic Beanstalk application (& environment) by following the AWS tutorial:

因此，让我们从遵循AWS教程创建一个AWS Elastic Beanstalk应用程序(和环境)开始：

1. although I’m pointing to .Net core on Linux as a platform, you can also choose Windows Server (with IIS as a proxy) or docker if that is your preference;

   尽管我指的是Linux平台上的.Net核心 ，但如果您愿意，也可以选择Windows Server(以IIS作为代理)或docker 。

2. if you are creating a non-production environment and you want to run Entity Framework Core migrations as part of this pipeline, I suggest that you create a database as part of your AWS Elastic Beanstalk environment; Please note that having an RDS instance being created on AWS Elastic Beanstalk “it isn’t ideal for a production environment because it ties the lifecycle of the database instance to the lifecycle of your application’s environment”;

   如果您要创建非生产环境，并且要在该管道中运行Entity Framework Core迁移，则建议您将数据库创建为AWS Elastic Beanstalk环境的一部分 ； 请注意，在AWS Elastic Beanstalk上创建RDS实例“ 这不是生产环境的理想选择，因为它将数据库实例的生命周期与应用程序环境的生命周期联系在一起 ”。

Now that you have your AWS Elastic Beanstalk application (& environment) up and running with the sample code, let’s edit our AWS CodePipeline project to deploy our code by adding a stage after build step called “Deploy”:

现在您已经启动并运行了示例代码，并运行了AWS Elastic Beanstalk应用程序(和环境)，让我们编辑AWS CodePipeline项目以通过在构建步骤之后添加一个称为“ Deploy”的阶段来部署代码：

AWS CodePipeline: Add a deploy stage

AWS CodePipeline：添加部署阶段

and voilà :) If you trigger a new build, your AWS Elastic Beanstalk will be automatically updated :)

和voilà:)如果触发新的构建，则AWS Elastic Beanstalk将自动更新:)

步骤3：自动运行Entity Framework Core Migrations连续交付(CD) (Step 3: Automatically run Entity Framework Core Migrations Continous Delivery (CD))

To run EF Core migrations, we can add another Stage in our AWS CodePipeline called Run-DBMigrations that rely on AWS CodeBuild to execute dotnet ef database update. So, let's create another buildspec file in the root of our project:

要运行EF Core迁移，我们可以在AWS CodePipeline中添加另一个名为Run-DBMigrations的阶段，该阶段依赖于AWS​​ CodeBuild执行dotnet ef database update 。 因此，让我们在项目的根目录中创建另一个buildspec文件：

db-migrations-spec.yml db-migrations-spec.yml

In order to this to work, you need to:

为了使其正常工作，您需要：

1. setup the database connection string as an environment variable in AWS CodeBuild;
   在AWS CodeBuild中将数据库连接字符串设置为环境变量;

2. allow AWS CodeBuild to reach the RDS instance

   允许AWS CodeBuild到达RDS实例

and voilà :) If you trigger another build, it just works otherwise just ask :)

和voilà:)如果您触发另一个构建，它就可以工作，否则请问:)

AWS CodePipeline succcessful run

AWS CodePipeline成功运行

关于AWS Elastic Beanstalk设置： (About AWS Elastic Beanstalk setup:)

As you may notice, I’m not setting any environment variable as I’m doing that in AWS Elastic Beanstalk directly.

您可能会注意到，我没有在AWS Elastic Beanstalk中直接设置任何环境变量。

If like me you are using Nginx as a reverse proxy server, you might want to:

如果像我一样，您将Nginx用作反向代理服务器 ，则可能需要：

1. Use app.UseForwardedHeaders in your Statup.Configure method;

   在您的Statup.Configure方法中使用 app.UseForwardedHeaders ；

2. Have your app listening in PORT 5000 by using an .ebextension:

   让您的应用使用.ebextension 在PORT 5000中进行.ebextension ：

.ebextension — env.config

.ebextension — env.config

Api.csproj

蜜蜂

寻找专业卓越的人才： (Looking for professional excellence:)

1. AWS Elastic Beanstalk supports Blue/Green deployments so you may want to update the pipeline to first deploy to a pre-production environment and have, for example, a manual action before swap CNAMES using Elastic Beanstalk command line interface (EB CLI);

   AWS Elastic Beanstalk支持蓝/绿部署，因此您可能需要更新管道以首先部署到预生产环境，并且在使用Elastic Beanstalk命令行界面(EB CLI)交换CNAMES之前具有手动操作；例如，

Because AWS Elastic Beanstalk performs an in-place update when you update your application versions, your application can become unavailable to users for a short period of time. You can avoid this downtime by performing a blue/green deployment, where you deploy the new version to a separate environment, and then swap CNAMEs of the two environments to redirect traffic to the new version instantly.

因为当您更新应用程序版本时，AWS Elastic Beanstalk会执行就地更新，所以用户可能会在短时间内无法使用应用程序。 您可以通过执行蓝/绿部署来避免这种停机，将新版本部署到单独的环境中，然后交换两个环境的CNAME以将流量立即重定向到新版本。

2. and if something goes wrong with EF Core migrations and some data got corrupted? You may still use an automatic RDS snapshot to restore but still, there is a data loss and a higher downtime time. So, why not to extend the pipeline to create a database backup named with a version number?You can create a database snapshot in AWS RDS or a native backup like this for SQL Server:

2.如果EF Core迁移出现问题，并且某些数据损坏了？ 您仍然可以使用自动RDS快照进行还原，但是仍然会丢失数据，并且停机时间会更长 。 因此，为什么不扩展管道来创建以版本号命名的数据库备份呢？您可以在AWS RDS或类似SQL Server本机备份中创建数据库快照 ：

RDS Native backup for SQL Server

SQL Server的RDS本机备份

翻译自: https://medium.com/swlh/setup-a-continous-delivery-cd-pipeline-in-aws-for-a-net-core-3-x-web-api-ca34271bd4fc

aws s3 api