[Pattern] Backend service

[efekarakus]

Overview

ecs-preview currently has a single application type load balanced web app targeting the use cases of applications that should be accessed from the internet. For example, rendering a website server-side, or building a “gateway” API service that can fan-out to other services.

We'd like to introduce a new app type, a backend app, that is an ECS service that cannot be accessed from the internet but can be reached from other applications in your project with service discovery.

Why do we need a backend app type?

1. Privacy. If your application is always accessible publicly, then you need to setup authentication (AuthN) and authorization (AuthZ) mechanisms in place to filter only valid requests.
   You can remove this duplication across applications by keeping your apps private and moving these AuthN and AuthZ to a single “gateway” load balanced web app.
2. Encapsulation. Seamlessly migrate your application from v1 to v2. If your app is always behind a load-balancer, then you’ll have two different paths: “/appv1” and “/appv2”. You have to chase after your clients to ask them to hit the new “/appv2” endpoint instead of “/appv1”.
   However, if the application is in the background, you can seamlessly shift traffic from “appv1.local” to “appv2.local” without your clients being aware of the migration.

An example backend application is an “inventory service”. A RESTful web service that fronts a DynamoDB table which stores all merchandise data.

Proposal

Application initialization

Help menu

Users can initialize a backend app with the existing app init command:

$ ecs-preview app init -h
Creates a new application in a project.
This command is also run as part of "ecs-preview init"

Usage
-----
  ecs-preview app init [flags]
  
Required flags
--------------
  -n, --name        string    Name of the application.
  -d, --dockerfile  string    Path to the Dockerfile.
  -t, --app-type    string    Type of the application create. Valid values are:
                              "Load Balanced Web App", "Backend App".
Load Balanced Web App flags
---------------------------
      --port        uint16    The port on which your Dockerfile listens.

Backend App flags
-------------------
      --port        uint16    The port on which your Dockerfile listens.

Running the command

The user experience while running the command:

$ ecs-preview app init

? Your application's architecture.
A Load Balanced Web App is an internet-facing HTTP server that's behind a 
load balancer. To learn more see: https://github.com/aws/amazon-ecs-cli-v2/wiki/app-types/load-balanced-web-app

A Backend App is a service that is *not* internet-facing, but is reachable
with service discovery. To learn more see: https://github.com/aws/amazon-ecs-cli-v2/wiki/app-types/backend-app
? What type of *infrastructure pattern* best represents your application?
> Load Balanced Web App
> Backend App

? What do you want to *name* this Backend App? inventory

? Which Dockerfile would you like to use for inventory?
> ./Dockerfile

We detected that your Dockerfile exposes port 8080. We'll use that port for service discovery.

We detected "curl -f http://localhost/ || exit 1" as your healthcheck command in 
your Dockerfile with an interval of 5 seconds and 3 retries.

✔ Wrote the manifest for inventory app at ecs-project/inventory/manifest.yml.
Your manifest contains configurations like your container size and healthcheck settings.

✔ Created ECR repositories for application inventory.

If we detect a HEALTHCHECK instruction in the Dockerfile, we display the text above.
If we don’t detect a HEALTHCHECK instruction, then we just don’t set a container health check and don’t print anything.

Manifest

The generated manifest file from app init will look like:

# The manifest for your "inventory" application.
# Read the full specification for the "Backend App" type at:
#  https://github.com/aws/amazon-ecs-cli-v2/wiki/Manifests#backend-app

# Your application name will be used in naming your resources like log groups, services, etc.
name: inventory
 
# Your application is reachable at "http://inventory.${ECS_APP_DISCOVERY_ENDPOINT}:${port}"
# but is not internet-facing.
type: Backend App
 
image:
  # Path to your application's Dockerfile.
  build: ./Dockerfile
  # Port exposed through your container to route traffic to it. 
  port: 8080 


# Optional. Container healthcheck settings. 
# See https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_HealthCheck.html
#
# healthcheck:
# #  The command the container runs to determine if it's healthy.
#  cmd: ["CMD", "curl -f http://localhost/ || exit 1"]
#  interval: 10s   # Time period between healthchecks.
#  retries: 2      # Number of times to retry before container is deemed unhealthy.
#  timeout: 5s     # How long to wait before considering the healthcheck failed.
#  startPeriod: 0s # Grace period within which to provide containers time to bootstrap before failed health checks count towards the maximum number of retries.

# Number of CPU units for the task.
cpu: 256
# Amount of memory in MiB used by the task.
memory: 512
# Number of tasks that should be running in your service.
count: 1

#variables:                    # Pass environment variables as key value pairs.
#  LOG_LEVEL: info

#secrets:                      # Pass secrets from AWS Systems Manager (SSM) Parameter Store.
#  GITHUB_TOKEN: GITHUB_TOKEN  # The key is the name of the environment variable, the value is the name of the SSM      parameter.

# You can override any of the values defined above by environment.
#environments:
#  test:
#    count: 2               # Number of tasks to run for the "test" environment.

Milestones

For the team to have visibility on the necessary work that goes into adding a new application type at the moment:

• Manifest declaration
  • Define the BackendApp struct to marshal to a manifest file . (chore: add BackendApp manifest type #830)
  • Apply environment overrides to BackendApp. (chore: unmarshal backend app manifest #848)
  • Unmarshal a manifest file into a BackendApp struct. (chore: unmarshal backend app manifest #848)
• CloudFormation stack
  • Define cloudformation template (Define CloudFormation template for a backend app #833)
  • Define stack struct to transform a manifest into a cloudformation template (Transform a backend app manifest to cfn template  #845).
• Update app package (Support backend app type for "app package" #860)
• Update app deploy (feat(cli): app deploy supports backend apps #879)
  • Refactor DeployApp to be able to take any stack struct. (refactor: DeployApp accepts an interface instead of cfn primitives #851)
• Update app show
  • Add BackendApp struct to describe package. (chore(describe): extract stack related methods from WebAppDescriber #872)
  • Refactor app show to accommodate for a new application type. (feat(cli): add app show support for backend app #876)
• Update app init (feat(cli): support backend app for "app init" #873)
  • Update docker/dockerfile to parse HEALTHCHECK instructions
• Don't create a load balancer in the environment if only a backend app is present.

[efekarakus]

To illustrate: