This is the second part of a blog post series exploring AWS Quick Starts for .NET. In this post, you will learn how you can use the CI/CD for .NET Applications on AWS Fargate Quick Start. It will help you get started developing .NET applications with Amazon Elastic Container Service (Amazon ECS) on AWS Fargate, configuring a Continuous Integration and Continuous Deployment (CI/CD) pipeline with AWS CodeCommit, AWS CodeBuild and AWS CodePipeline using the Quick Start.

Part 1 of this series explored an automated way to create a .NET development environment on Amazon Web Services (AWS) using a Quick Start.

AWS Fargate is a technology that you can use with Amazon ECS and Amazon Elastic Kubernetes Service (Amazon EKS) to run containers without having to manage servers or clusters of Amazon Elastic Compute Cloud (Amazon EC2) instances. With Fargate, you no longer have to provision, configure, or scale clusters of virtual machines to run containers.

AWS has documented the steps to create an Amazon ECS cluster for Fargate. Implementing a CI/CD pipeline according to best practice to deploy applications to a Fargate cluster requires additional planning and effort. For customers that want to deploy .NET applications, AWS has developed the CI/CD for .NET Applications on AWS Fargate Quick Start.

This Quick Start helps customers implement a CI/CD pipeline that uses AWS DevOps services to automatically build and deploy their .NET applications, using Linux containers, to an Amazon ECS cluster using Fargate. The Quick Start serves both as a best practice reference architecture and a template for implementation.

To use the Quick Start, first navigate to the deployment guide, where you will find all the information you will need to deploy it into your own environment. This includes:

• Cost and licensing information
• Architecture
• Technical prerequisites, requirements and quotas
• Deployment and testing steps
• FAQs and troubleshooting information
• Link to the GitHub repository with the files

Architecture

Figure 1 is the architecture for the Quick Start. You can learn about it in more detail in the Architecture and the Resource quotas sections of the deployment guide.

Figure 1: Reference architecture diagram

The Quick Start deploys the following components:

1. An Amazon Virtual Private Cloud (Amazon VPC) configured with a private and public subnets with NAT gateway across two Availability Zones.
2. The necessary components to deploy the application on Amazon ECS. These components include:
   1. An Amazon ECS cluster configured for the Fargate launch type.
   2. An Amazon ECS task definition.
   3. An Amazon ECS service.
3. An Application Load Balancer for the Amazon ECS tasks created by the Amazon ECS service, listening for requests on port 80.
4. A CodeCommit repository with sample code.
5. A CI/CD pipeline to host, build, and deploy the application code to the Amazon ECS Cluster. This pipeline uses CodeBuild and CodePipeline.

The network configuration deployed by the Quick Start is recommended if you want to run a public-facing web application, where the backend services aren’t accessible directly from the Internet. You can read the blog post Task networking in AWS Fargate for more information and best practices for setting up networking for containers running on Fargate.

Deployment

It is important that you read the Planning the deployment section of the deployment guide to make sure you meet the prerequisites before deploying the Quick Start.

Once you have reviewed and met the requirements for this Quick Start, you are ready to deploy its CloudFormation template into your AWS account.

You have two options on how to deploy the CloudFormation template using the AWS Console:

1. Navigate to the following pre-filled CloudFormation console link.
2. Download the CloudFormation template, navigate to the CloudFormation console and manually upload the template.

After you have chosen one of the previous options, choose Next to be presented with the parameters you will use to deploy the stack.

Figure 2: AWS CloudFormation stack parameters

The parameters Quick Start S3 bucket name, Quick Start S3 key prefix and S3 bucket Region specify an Amazon Simple Storage Service (S3) bucket location where additional supporting files used during the launch of the development environment are stored. You should only change these parameters if you want to do an advanced customization as described on the Quick Start website. You can explore those files on GitHub.

After entering the parameters, choose Next. On the Configure stack options page, review the tags you want to use as well as other advanced options and choose Next. Review the stack configuration and acknowledge the creation of IAM roles by selecting I acknowledge that AWS CloudFormation might create IAM resources. Choose Create stack.

The CloudFormation stack will start deploying and may take up to 15 minutes to complete. Once it has finished, there will be four outputs in the CloudFormation console. They are:

• CodePipelineName – The name of the created pipeline
• CodePipelineUrl – The CodePipeline console URL for the created pipeline
• LoadBalancerUrl – The URL to reach the Amazon ECS tasks
• RepoUrl – The CodeCommit console URL for the created code repository

You can read more about them in the Test the deployment section of the deployment guide.

Figure 3: CloudFormation stack outputs

You now have a containerized ASP.NET application deployed into AWS Fargate. Navigate to the value specified by the  LoadBalancerUrl output link to navigate to your application in a browser window.

Figure 4: Sample web application home page

Usage

To explore the CI/CD pipeline created by the Quick Start, you will first go to the CodePipeline console by navigating to the value of the CodePipelineUrl CloudFormation output (Figure 3).

On the CodePipeline Console, there will be three stages defined: Source, Build, and Deploy. We will explore each of these stages in more detail in the following sections.

Source Stage

On the Source stage of the pipeline, you can choose the hash number (in this example, it is 5359305b) or the AWS CodeCommit link text to navigate to the specific commit in the CodeCommit repository that triggered the pipeline execution.

Figure 5: Source stage in CodePipeline

After you deploy the Quick Start for the first time, the CodeCommit repository created by the Quick Start will contain code for a ASP.NET Core 6 Razor Pages web application with support for Docker containers. This code is used only for sample purposes. You can explore the complete codebase on GitHub.

Figure 6: Sample source code in CodeCommit

After you replace this code with your own, note that you will need to modify the buildspec.yml for the Build Stage to complete successfully. That process is described in the next section.

Build stage

On the Build stage of the pipeline, you can choose the Details link to navigate to the CodeBuild console to see the details of the build.

Figure 7: Build stage in CodePipeline

On the details page, you can explore details such as logs, environment variables, configuration of the environment, source, artifacts, resource utilization, and reports.

Figure 8: Details and logs for CodeBuild build

Along with the sample ASP.NET Core 6 application code, the Quick Start also configures a CodeBuild build specification that runs the following tasks for every build:

1. Pre-Build: Gets the credentials for the Amazon ECR repository where to push the .NET container image.
2. Build: Builds the .NET container image, tags, and pushes the image to the Amazon ECR repository.
3. Post-Build: Creates an image definition file to be used by CodePipeline to deploy the container into Amazon ECS.

To customize the build specification to work with your own code, you will need to edit the buildspec.yml stored in the CodeCommit repository created by the Quick Start.

The buildspec.yml file is where you define the actions to run as part of the build process. This includes things like installing dependencies, running unit tests, running static code analysis tools, building the code, and packaging your application. You can read more about how to define a build specification in the CodeBuild product documentation.

The CodeBuild project is configured to run builds on a LINUX_CONTAINER, BUILD_GENERAL1_SMALL environment, using the aws/codebuild/standard:5.0 image provided by CodeBuild. This provides an environment running Ubuntu 20.04 with 2 vCPUs, 3 GB of memory, and 64 GB of storage. You can read more about the available build environment compute types, the provided Docker images, and the available runtimes in the CodeBuild product documentation.

You can change this configuration by modifying the CodeBuild project definition in the CloudFormation template.

Deploy stage

On the Deploy stage of the pipeline, you can choose either the Amazon ECS or Details link (Figure 9) to navigate to the Amazon ECS console where you can access the cluster, service, and tasks created as part of the CloudFormation template (Figure 10).

Figure 9: Deploy stage in CodePipeline

Figure 10: Services in Amazon ECS cluster

In this stage, CodePipeline runs the following tasks:

1. Creates a new version of the Amazon ECS task definition with the Amazon ECR image generated in the Build stage.
2. Updates the Amazon ECS service to utilize this latest version. This starts the process of creating new tasks using the latest task definition and replaces the Elastic Load Balancer’s targets with the new healthy tasks.

An Amazon ECS task definition is required to run Docker containers in Amazon ECS. In it, you define things like the Docker image to use with each container in your task, how much CPU and memory to use with each task, or container within a task, among others. You can read about all of the parameters in the Amazon ECS product documentation.

The task definition included as part of the Quick Start defines an Amazon ECS task that uses 0.25 vCPU and 256 Mb of memory, exposes port 80, mounts a data volume on the path /var/www/my-volume, and sends logs to the Amazon CloudWatch log group created as part of the Quick Start.

You can change this configuration by modifying the Amazon ECS task definition in the CloudFormation template.

An Amazon ECS service allows you to run and maintain a specified number of instances of a task definition simultaneously in an Amazon ECS cluster. You can read about all of the parameters available for a service definition in the Amazon ECS product documentation.

The service included as part of the CloudFormation template defines that the tasks are going to be run on AWS Fargate, with a minimum of 2 tasks running at all times. Additionally, it is configured to use the Application Load Balancer created as part of the Quick Start to distribute traffic evenly across the tasks.

You can change this configuration by modifying the Amazon ECS service definition in the CloudFormation template.

Costs and licenses

You are responsible for the cost of the AWS services and any third-party licenses used while running this Quick Start reference deployment. There is no additional cost for using the Quick Start.

The AWS CloudFormation templates for this Quick Start include configuration parameters that you can customize. Some of the settings, such as the instance type, affect the cost of deployment. For cost estimates, visit the pricing pages for each AWS service you use. Prices are subject to change.

Tip: After you deploy the Quick Start, create AWS Cost and Usage Reports to deliver billing metrics to an Amazon S3 bucket in your account. These reports provide cost estimates based on usage throughout each month and aggregate the data at the end of the month. For more information, read What are AWS Cost and Usage Reports?

Cleanup

If you no longer want to keep the resources created as part of this Quick Start in your account, open the CloudFormation console, select the stack you created as part of the Quick Start and choose Delete. This will remove the resources that were created as part of the Quick Start.

Be aware that trying to delete the CloudFormation stack after additional resources were provisioned in the VPC that was provisioned will prevent the stack from being completely deleted. In that case, you need to delete those resources manually and then delete the CloudFormation stack.

Two resources that will not be deleted automatically are the Amazon ECR repository and the Amazon S3 bucket used to store artifacts for CodeBuild. You can follow the instructions in the product documentation on how to delete an Amazon ECR repository and how to delete an Amazon S3 bucket to learn how to manually remove these resources.

Conclusion

In this blog post, you learned that by using the CI/CD for .NET Applications on AWS Fargate Quick Start, developers can create a fully managed CI/CD pipeline to build, test, and deploy their .NET applications to Amazon ECS on AWS Fargate. You explored the pipeline, how it works, and explored several areas where you can customize it. You can use this reference deployment as a baseline and customize the environment to your needs.

There are resources available to help you learn AWS services when developing for the cloud. The AWS Developer Center provides tutorials and tools for developers for a variety of programming languages and services.

 .NET on AWS is the home for .NET development on AWS and is a great place to start your .NET on AWS journey. The Windows on AWS blog is a useful resource if you want to be informed on use case-specific technical solutions or customer case studies. The .NET on AWS YouTube playlist is a place to get the latest .NET on AWS sessions and videos. On social media, you can follow the official .NET on AWS Twitter handle to be updated all things .NET on AWS.

You can use these AWS resources to help you get started and dive deeper into specific topics, troubleshooting tips, and best practices for .NET on AWS. You can get additional information from the API Reference, developer guides, and other documentation that is provided.

If you have any other ideas on how the AWS Quick Start for .NET can help get started quickly and be more productive, please share them on the official .NET on AWS Twitter handle.

AWS can help you assess how your company can get the most out of cloud. Join the millions of AWS customers that trust us to migrate and modernize their most important applications in the cloud. To learn more on modernizing Windows Server or SQL Server, visit Windows on AWS. Contact us to start your modernization journey today.