Considering the scope of our test application, we will keep the EFS configurations simple and just declare fileSystemId, which is mandatory. Since EFS is accessed over the network, we also need to ensure that appropriate security group configurations are in place before this filesystem can be mounted inside the database container:

We allow incoming traffic on port2049 from any private IPv4 address, which in this case can only be the application container in the same Docker network.

Adding the Fargate service with Application Load Balancer integration

The last piece remaining in the infrastructure stack is the ECS service, which acts as the glue between the Flask container and the Application Load Balancer. It takes responsibility for registering the task IP and port in the load balancer’s target group:

In this case, we’re leveraging an existing ECS pattern in CDK constructs, which simplifies the process of creating a Fargate service that’s exposed over the internet with an Application Load Balancer. This saves us quite a lot of implementation effort.

At this point, we are done with all the infrastructure components that will be required to provision the application in our AWS accounts on an ECS cluster.

Before proceeding with the CDK deployment, let’s discuss what makes up our Flask application code and the resulting Docker image. Discussing Flask’s capabilities in detail is outside this chapter’s scope, but I will try and give you a brief walkthrough of the most important capabilities we are leveraging.

Preparing the web application code

We are using the Flask web framework to build the user-facing browser interface, as well as the backend APIs that the frontend will communicate with. Flask uses the concept of @app.route annotations, better known as decorators. They convert a Python function into a view function, which returns HTML code that can be rendered by the browser, or any other client for that matter. So, if you can prepare a function to return HTML content such as<h1> hello world! </h1>, then Flask can help you map this functionality with a URL endpoint such as /hello. As a user, you can just focus on writing these Python functions; then, Flask glues them together with specific URL endpoints that applications can leverage.

In our case, the primary functions of our application are to create and remove tasks. So, we can think of three HTTP endpoints to support these scenarios.

• GET / to retrieve all the tasks from the database

• POST / to add a new task to the database

• POST /<id>/delete to delete a task from the database

With the increasing scale of the applications, it might not be easy to directly work on HTML syntax, so Flask offers additional capabilities around rendering HTML templates with dynamic data, using Python constructs such as for loops . We will see this being used in our HTML web page when we return the database objects for user interaction. Now that we’ve put everything together, let’s have a first look at our application endpoints.

Note All application code discussed here onward is available inside your Cloud9 IDE at the chapter –7/chapter-7-flask-app path or can be referenced in this book’s GitHubrepository: https://github.com/PacktPublishing/AWS-DevOps-Simplified/ tree/main/chapter-7/chapter-7-flask-app.