The process of deploying applications on the AWS Elastic Container Service (ECS) Fargate, which is a Managed serverless container orchestration service provided by AWS, has a couple of requirements that should be covered before the process is carried out. The applications/services should conform to the Microservice architecture by including the necessary bits that qualifies an application to thrive in the Microservice architecture, these include Containerization, having a Logging mechanism, a status check mechanism and should avoid over-ramped features. Having these requirements will not only enhance application development but will also help to ensure that applications and services are running as expected. These considerations should be incorporated in the design and implementation process of the applications/services.
Requirements
After the application/services is ready to be deployed in the ECS environment, there are several touch points that should also be considered before proceeding with the setup. There’s a reference to the How-To Article on this aspect, where the required services are enumerated. Prior to setting up the respective Cloud or on-premise infrastructure that would be needed by the application, a clearly defined requirement should be obtained from the development team, stating the different resources that the application would need to run, the requirements should then be analyzed by the infrastructure and architecture team to advise on the best course or the best choices after clearly considering the costs and implications of using those resources. After there’s a general consensus on the way to go regarding those requirements, the infrastructure is set up based on the agreement. Some of these requirements may include but not limited to Databases, Cache services, Messaging services like ActiveMQ, Kafka and AWS SQS, Serverless platforms for batch jobs, Machine learning services like AWS Rekognition etc. They can also be seen in the How-To Article above. These services should mostly be setup before going on to deploy the services/applications for them to integrate into.
An account on AWS that has access to the following basic services is required;
ECS
CodePipeline
CodeBuild
CloudWatch
EC2
S3
ECR
VPC
The following should be available for the required services to build on
An assigned VPC for the ECS cluster and Load Balancer with multiple Availability zones for the subnets
A Repository on GitHub that serves as the source code
A Dockerfile that will be needed to build a docker image for the deployment of the services
All the Environment variables and application properties, needed for the application to run
A predefined region for doing the creation and deployment;
After ensuring that the requirements mentioned earlier are in place, then the applications are ready to be deployed on the platform. The containers play a vital role in the deployment and functioning of microservices in general, and they also play that role in functioning on ECS. But before starting work on the deployment of the containers, there is a need to provision the services/infrastructure needed.
Setting Up the Infrastructure
AWS Elastic Container Registry
An AWS ECS cluster would first get created which is a logical separation or aggregation of ECS services and tasks, these clusters are where various elements like Container Insights are set. After setting up the Cluster, a repository should be defined where container images will be stored and pulled from when deploying. This will be done via AWS Elastic Container Registry, which provides a managed and secure way for hosting container images repositories that could be public or private. Except the company decides to provide Open Source Images, all images should be private and secure, the images should also follow the standard process when being created. The process is also described in the How-To article. The ECR service configurations should also include the option to scan the image on push to scan for any vulnerability in the container image. Images that have high vulnerability content should be escalated appropriately.
Task Definitions
After an repository on ECR is created for storing the container images for a particular service following the approved process, the ECS Task Definition should follow, this is where we define/declare the structure and configurations that should be provisioned with the containers, which include the Environment variables, the container image URI, the task name and other parameters that may be needed. Essentially, there are some parameters that needs to be ascertained based on the requirements of the development team such as the compute capacity needed to run these application workloads, this would determine the amount of compute to assign to a microservice. The container definitions is what would then contain any configuration that is required on the container level following the stipulated policies. The first image pushed to the repo should be a test image based on a test run build using the standard service for Cloud Continuous Integration as of the time of writing, using AWS CodeBuild and following the SOP and processes.
Application Load Balancer
After the task definition is created, an application load balancer on AWS Elastic Load Balancer is then configured to route traffic to the services running on the cluster. The load balancer is configured to accept traffic from the 80 and 443 ports and forwarded to the required target groups based on the matching of appended endpoints. These target groups are the tasks that are running based on the set definition.
AWS ECS Service
After the Load Balancer is configured, ECS services are now configured to run the tasks as a logical group or set that can have different interactive capabilities at a task wide scale. This allows for easier orchestration and administration. The service is also configured to receive requests for the allocated Load balancer and is allocated a security group for screening requests that comes in to the container. Based on the requirements, a health check grace period is set so as to allow the applications to start up before health checks begin. The services are also placed in the appropriate VPC and subnets. It’s also in service configuration that health checks are set. If the console is used then the routing rule for the application Load balancer is also configured. Depending on the environment and requirements, the Autoscaling group may be configured based on known behaviors and metrics. There are options of setting the autoscaling trigger to track the memory, CPU or Network activity. During the development of the application, this is also a vital part that should be taken into consideration as this will shape the way the autoscaling configuration will be designed.
After deploying the service, then a pipeline can be setup using the build project used for test running the CI for ECR. It’s also imperative that monitoring and observability is setup to track the various key performance, metrics and activities. This would require setting up a dashboard to track services based on a logical aggregation of parameters like logs, metrics such as point in time memory consumption, CPU consumption, number of running tasks, Network activity such as number of connections, and non application services monitoring too.
Top comments (0)