The number of customers running APIs and microservices in containers and serverless computing is rising. Anypoint Flex Gateway extends the Anypoint Platform to all APIs running across any environment. Naturally, you can leverage Anypoint Flex Gateway to manage and secure them. However, a question arises about whether Anypoint Flex Gateway runs in containerized and serverless computing environments.
MuleSoft fully supports customers running Anypoint Flex Gateway in containerized and serverless computing environments. However, the successful operation of such a deployment is a shared responsibility. MuleSoft is responsible, among other things, for providing and supporting Flex Gateway and an online Docker image registry. At minimum, you are responsible for provisioning and configuring the containerized and serverless computing environment to run Flex Gateway.
At time of writing, no resources are available to jump-start such an undertaking. To make matters worse, leading cloud service providers approach containerization and serverless slightly differently and from a different perspective, e.g. Amazon ECS on AWS Fargate, Azure Container Apps, and Google Cloud Run.
Customers considering running Anypoint Flex Gateway in containerized and serverless computing environments have predominantly shown interest in using Amazon Elastic Container Service (Amazon ECS) on AWS Fargate.
Running Flex Gateway on Amazon ECS and AWS Fargate
Arguably, from the infrastructure perspective, the only resource you must create and configure to run Flex Gateway on Amazon ECS and AWS Fargate is the Amazon ECS cluster.
You could use a default VPC or create a new one to logically isolate Flex Gateway and all related services and resources from everything else in your AWS account. Naturally, you should leverage as many availability zones as needed to address your non-functional requirements.
There is no definitive rule about using one ECS cluster per Flex Gateway instance. When using Amazon ECS on AWS Fargate, you pay for the vCPU and memory resources the Flex Gateway replicas consume. Hence, you can create as many ECS clusters as you need. For example, you could create an ECS cluster per environment (e.g. development, test, production) or one for non-production environments and one for production. However, the more ECS clusters you create, the more you must operate, administer, and manage.
The following diagram, adapted from the Amazon Elastic Container Service Developer Guide, provides a conceptual overview of the different moving parts to run one Flex Gateway instance with Elastic Load Balancing (ELB) automatically routing incoming requests across Flex Gateway replicas.
First, the Amazon Elastic Container Service developer guide defines an ECS task definition as “a text file in JSON format that describes the parameters and one or more containers that form your application”. The following is an incomplete example of an ECS task definition for illustrative purposes only. Although incomplete, this example represents a Flex Gateway replica. More specifically, it specifies running the Flex Gateway Docker image that MuleSoft publishes in Docker Hub and provides additional details on how to run it (e.g. vCPU, memory).
{
"family": "Flex-Gateway-Task-Definition",
"networkMode": "awsvpc",
"containerDefinitions": [
{
"name": "flex-gateway",
"image": "docker.io/mulesoft/flex-gateway:1.6.2",
"portMappings": [
{
"containerPort": 8081,
"hostPort": 8081,
"protocol": "tcp"
}
],
"essential": true,
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/flex-gateway",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "flex-gw"
}
},
"healthCheck": {
"command": [
"CMD-SHELL",
"flexctl probe --check=liveness || exit 1"
],
"interval": 30,
"timeout": 5,
"retries": 3
}
}
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "512",
"memory": "1024",
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "LINUX"
}
}The example above also specifies a Linux task, a single port to expose, where to send the logs, and how much vCPU and memory to allocate to the containers.
As stated in the Amazon Elastic Container Service Developer Guide, “you can run a standalone task, or you can run a task as part of a service”. The ECS service description is a text file in JSON format that specifies the number of tasks or Flex Gateway replicas Amazon ECS should run and maintain simultaneously in your ECS cluster.
{
"cluster": "Flex-Gateway-ECS-Cluster",
"serviceName": "Flex-Gateway-Service",
"taskDefinition": "Flex-Gateway-Task-Definition",
"loadBalancers": [
{
"containerName": "flex-gateway",
"containerPort": 8081,
"targetGroupArn": "arn:aws:elasticloadbalancing:<...>"
}
],
"desiredCount": 2,
"launchType": "FARGATE",
"platformVersion": "LATEST",
"networkConfiguration": {
"awsvpcConfiguration": {
"assignPublicIp": "ENABLED",
"securityGroups": [
"sg-1ef524ad16cb"
],
"subnets": [
"subnet-77bd0e1bcbf5",
"subnet-f9d727e79822"
]
}
},
"schedulingStrategy": "REPLICA",
"deploymentController": {
"type": "ECS"
}
}The example above specifies running and maintaining two Flex Gateway replicas simultaneously in the Amazon ECS cluster and with a Fargate launch type. It also links the ECS service to a load balancer, which distributes requests across the Flex Gateway replicas.
Before you start provisioning and configuring AWS services and resources, you need to be aware of two challenges you must plan to address. The first is making the Flex Gateway registration and configuration files available to containers running on Amazon ECS and AWS Fargate. The second is the Elastic Load Balancing health checks.
Challenge 1: Flex Gateway registration and configuration files
The first challenge when running Flex Gateway on Amazon ECS and AWS Fargate is making the registration and configuration files available to the containers. When using Docker, for example, you typically store the registration file in a folder on the host computer, which you mount as a volume when starting Flex Gateway. There is no host computer to store data when using the AWS Fargate launch type for an ECS task, as Fargate is a serverless service as a reminder.
Flex Gateway version 1.7.0 introduces a new environment variable named FLEX_CONFIG, enabling you to inject the registration. In other words, you will be able to add the registration information directly into the task definition.
If you are running any version of Flex Gateway before 1.7.0, one solution is to extend the base Flex Gateway image to include those files. In other words, you build a custom Docker image per Flex Gateway registration file. AWS offers services to automate the build process, or you could leverage your existing DevOps toolchain and configure CD/CD pipelines. You must also store and maintain the custom Docker images in a registry, e.g. Docker Hub or Amazon Elastic Container Registry (ECR).
Another solution is to mount a data volume to the ECS tasks. There are several options for doing so; however, most are not a good fit for the Fargate launch type. Mounting an Amazon Elastic File System (Amazon EFS) volume to the ECS tasks checks all the boxes.
Using Amazon EFS is not without its challenges. For example, there is no easy way to create folders or upload files to the EFS file system. A few techniques exist to transfer data into and out of Amazon EFS file systems. Arguably, the most straightforward approach is to mount an EFS file system to a jump box (e.g. Amazon Elastic Compute Cloud (EC2) instance) to access it and manage it over SSH or SFTP. Leveraging an EFS file system and a jump box adds complexity and additional moving parts, representing possible points of failure.
The upcoming FLEX_CONFIG environment variable is the best option. However, the two workarounds for any version of Flex Gateway before 1.7.0 have benefits and tradeoffs. Regardless, it would be best to plan for your chosen solution before provisioning and configuring AWS services and resources to run Flex Gateway.
Challenge 2: ELB health checks
The second challenge when running Flex Gateway on Amazon ECS and AWS Fargate is the ELB health checks, i.e. the ELB periodically sends requests to the ECS tasks to test their status and instructs ECS to replace them if it does not get a healthy status. Flex Gateway does not expose a health check endpoint as of this writing.
MuleSoft’s recommended approach to circumvent this limitation is to register an API with Flex Gateway and leverage it for the ELB’s health checks. Once that is in place, you link the ELB to the ECS service, including configuring the health checks. Ideally, you should leverage an API you will ultimately manage with Flex Gateway for the ELB health checks. Regardless, it would help if you planned for this workaround before linking your ELB to your ECS service.
Baseline architecture
When all is said and done, running Flex Gateway on Amazon ECS and AWS Fargate requires provisioning and configuring several AWS resources and completing tasks specific to Flex Gateway. The following diagram illustrates a suggested architecture and establishes a baseline or foundation for running Flex Gateway 1.7.
First, this baseline architecture diagram illustrates deploying a single Flex Gateway instance with two replicas fronted by an ELB for minimal redundancy and failover. It does not represent any specific Flex Gateway Deployment Model (i.e., standalone, ingress, egress, and sidecar), as you can implement any of them on Amazon ECS. This diagram shows generic APIs owned by any organization and running on any service within the AWS cloud – e.g., EC2, ECS, EKS, and Lambda. However, you could as quickly implement any of the Flex Gateway Integration Use Cases.
Regardless, you can build up or down from this baseline to meet your requirements. For example, you could use one availability zone and one Flex Gateway replica in the development environment to cut costs. Conversely, you could use more than two availability zones, more than one Flex Gateway replica per availability zone, or both to achieve higher availability.
Next steps and additional resources
If you’ve never installed or worked with Anypoint Flex Gateway, consider consulting the Flex Gateway Overview and Flex Gateway Reference Architecture content in the MuleSoft product documentation, and review and satisfy the prerequisites before installing Anypoint Flex Gateway on Amazon ECS. Finally, if you are new to Amazon ECS, you might want to complete the tutorial Creating a cluster with a Fargate Linux task using the AWS CLI from the Amazon Elastic Container Service Developer Guide.
This GitHub repository proposes an approach to provisioning and configuring the AWS resources and completing the tasks specific to Flex Gateway to establish the baseline architecture. As of this writing, the proposed approach leverages the AWS Command Line Interface (CLI) for provisioning and configuring the AWS resources. If you have experience provisioning and configuring AWS resources, you could complete all the steps using the AWS management console or leverage an Infrastructure as Code approach (IaC) using AWS Elastic Beanstalk, AWS CloudFormation, Ansible, Terraform, and so on.
