Running the build process and deploying an application to AWS within a serverless application presented another technical challenge. The build server must have access to an underlying file system
AWS Lambdas functions are limited to 15 minutes [1] of
References:
After the user deploys their serverless infrastructure using Trellis, the user would want a way to view the state of their deployment and obtain any necessary information to communicate with their recently deployed infrastructure. Without further work from our end, users of Trellis can view the state of their deployment by heading over to the CloudFormation console in their respective AWS accounts and monitoring the state of the stacks. However, we wanted to improve the user experience by delivering the state to them without additional work from their end. To accomplish this, two main tasks need to be done:
There are three possibilities to retrieve the state of a deployment.
Updating the state through the Fargate container would be the most straightforward option, as it doesn't require learning new tools. Our initial attempt was to update the state through the Fargate container to speed up our process and prepare for our first demo. However, updating the state this way slows down the deployment time by a few seconds. Because of this drawback, we decided to pursue a different path.
Retrieving the data from CloudFormation would give the most up-to-date state among the three options. However, it’s the most complex method among the three options. To accomplish this, we need a lambda to subscribe to every user's CloudFormation and listen to any event related to the stacks the user deploys. For this to happen, we need the Fargate container to read the files it clones to determine the user's application name and then store the application name in the database to tie the appropriate stacks to the correct stage. Furthermore, every change in resource state triggers an event in CloudFormation. These events will, in turn, trigger the lambda subscribed to CloudFormation. The lambda will need to filter through these events for pertinent details as to only send relevant information to the user. The last drawback of this option is that the Fargate container performs other tasks before starting the deployment process; there is a possibility that the deployment process fails before the stacks are initiated on CloudFormation. If this happens, the user will not be updated that the deployment failed. To account for this, we need the Fargate container to send the necessary updates before deployment to the database.
We decided to use the last option, the CloudWatch log group. We connected a cloud watch log group to the Fargate container. The container sends logs to this log group, and the log group creates a log stream for each deployment. We then connected a lambda function to be triggered every time a log group event is triggered. This lambda function stores the logs in the database. This option provides sufficient details to the user without slowing down the deployment. A drawback of this option is that the state will not be live for the user as there's a latency delay from the container providing the logs to the log group triggering the lambda to the lambda storing the data in the datastore. However, we can accept this delay as it's unnecessary for the state to be updated within the second for our purposes.