Gitmoxi provides GitOps based complete life-cycle management for AWS Lambda functions. When the Lambda deployment files are created, changed, or deleted in Git repository, Gitmoxi seamlessly orchestrates those changes for the Lambda functions. Gitmoxi supports both push-based (e.g. API-GW, ALB) and pull-based (e.g. SQS, Kafka) Lambda functions enabling you to build and deploy wide range of API and event-driven applications in a completely serverless archtiecture. For Lambda functions deployment, Gitmoxi orchestrates blue/green deployment where invocations can be shifted from old to new using canary, linear, or all_at_once paradigms. Gitmoxi manages the versions and invocation weight shifting automatically providing a seamless deployment workflow that can easily scale as your number of Lambda functions grow.
In the Lambda GitOps workflow, Gitmoxi uses four key files to manage deployments:
| File | Name | Purpose |
|---|---|---|
| Function definition | _lambdadef.json | Defines Lambda function parameters and configuration |
| Event source definition | _lambdaeventsourcedef.json | Specifies event triggers and sources for the Lambda function |
| Deployment configuration | _lambdadepdef.json | Controls deployment strategies and versioning |
| Input file | _lambdainput.json | Provides parameterization values for substitution |
Let’s explore each of these files, as their contents—and any changes to them—drive Gitmoxi’s Lambda deployment logic.
The Lambda function definition JSON file (_lambdadef.json) can contain all the attributes defined by the Lambda Create Function Request. This is the native Lambda function definition. So when the Lambda service team adds more features or changes you can instantly adopt those!
Lambda functions are invoked either by a push-based source such as API-GW, ALB; or pull-based sources (or pollers) such as SQS, Amazon Managed Service for Kafka (MSK). The event source mapping section describes how to define these invocation sources.
The Lambda deployment definition JSON file (_depdef.json) contains various settings such as traffic shifting, stability checks which are used by Gitmoxi during Lambda service deployment. These settings are described in more details in the next section.
The Lambda deployment input JSON file (_input.json) provides substitution values when you want to parameterize the attributes in function, event source, or deployment definition files. These files are explained in the input files section.
Let us understand how the changes to these files influence associated ECS service objects.
Whenever any of the function definition, event source definition, and/or input file are changed, Gitmoxi triggers a new deployment which create new versions of associated Lambda functions. This is because function and event source definition changes naturally indicate changes, and the changes to input file indicates some parameter value has changed. If only the Lambda deployment definition (_lambdadepdef.json) file has changed then Gitmoxi will not trigger a new deployment because this file only contains deployment settings.
Based on the function definition file, Gitmoxi checks if an active function exists in the specified region. If function doesn’t exist, Gitmoxi will create the function based on definition. And if function exists, then Gitmoxi will create a new version of the function. Gitmoxi will register the new function or new version of function to the alias provided in the deployment definition file. This alias is then used for traffic shifting (or invocation weight shifting) between the old and new versions.
Gitmoxi deletes an active Lambda function only when the associated function definition file is deleted.
Blue/green update: For a Lambda blue/green deployment, Gitmoxi will:
Blue/green traffic shifting patterns: For blue/green deployment, Gitmoxi supports following traffic shift patterns:
For every deployment, Gitmoxi checks that the desired number of tasks get to running state. Gitmoxi stability check configuration allows you to specify a timeout and polling interval to call the ECS APIs and check for task status. If all tasks don’t become stable within the specified timeout then the deployment is considered failed. You can specify either an absolute timeout or specify it based on desired number of tasks. If a service task takes longer to startup or if there are too many replica counts, then it might be better to provide the timeout in terms of desired count. For example, if your service has desired count of 10, you can either specify absolute time, say 600 seconds as the timeout, or specify 120 seconds per task for the timeout setting which will make the absolute time 1200 seconds (120 x 10). If both absolute and per task values are specified then Gitmoxi will take the max of the two values and do the stability check in that time window.
Gitmoxi also has a deployment circuit breaker which will stop and rollback the deployment if number of new task failures exceeds a configured threshold. For this as well, you can either provide an absolute threshold or specify it as a percent of the desired count. For example, if your service has desired count of 10, then you can specify 5 as absolute failure threshold. Or, you can specify 30% task failures, which will set the threshold as 3 failures (30% * 10). If both values are provided Gitmoxi takes the minimum of the two values as the threshold.
All the deployment configurations such as traffic shifting, stability checks, deployment circuit breaker are specified in the ECS deployment definition (_depdef.json) file, which is described in more details in the respective section.
Experience the power of Gitmoxi — your go-to solution for simple, flexible, and transparent deployment management
