GitMoxi leverages the GitOps paradigm to manage and automate deployments. In this model, deployment artifacts—such as ECS service definitions, ECS task definitions, and Lambda function configurations—are stored in Git repositories. When these files are changed and committed to a branch, GitMoxi orchestrates the creation, update, or deletion of associated service objects based on the changes.
GitMoxi supports parallel execution and can process multiple file changes in a single commit, deploying updates across services efficiently. It handles both the creation and updating of service objects using a range of deployment strategies, including rolling updates and blue/green deployments with flexible traffic shifting patterns. When a file is deleted from the repository, GitMoxi also deletes the corresponding service object, completing the full lifecycle management.
For every commit and deployment, GitMoxi logs detailed processing metadata in AWS DynamoDB tables. It captures comprehensive deployment status, enabling you to troubleshoot with ease—whether the issue is a simple misconfiguration, missing IAM permissions, exhausted IPs, or alarm-triggered failures during traffic shifting.
GitMoxi also includes a flexible deployment circuit breaker that can automatically trigger rollbacks based on failure thresholds or prolonged stabilization times.
Below sections provide more details on the repositories and commits, followed by next chapters covering feature details for deployments.
The GitOps paradigm begins with storing deployment artifacts in Git repositories. Git provides powerful features for version control, collaboration, code review, and approvals, as well as a complete audit trail to answer the recurring question: what changed?.
With GitMoxi, you can configure multiple repositories and, for each repository, associate multiple branches. Below is an example of how to add a repository for use with GitMoxi:
gmctl repo add -r "<deployment-artifacts-git-repo>" -b main -b dev -a "<aws-secret-mgr-arn-for-Github-token>"
An access token is required for GitMoxi to evaluate commit changes and read deployment artifacts. GitMoxi currently supports AWS Secrets Manager and AWS Systems Manager Parameter Store to securely store this token. When adding a repository, simply provide the ARN of the secret where the token is stored. GitMoxi fetches the token directly and never stores or logs it. If the token is rotated or changed, GitMoxi will automatically retrieve the latest version.
You can trigger a GitMoxi deployment after pushing changes to a configured repository and branch. For example, to deploy an Amazon ECS service, you might create nginx/nginx_svcdef.json and nginx/nginx_taskdef.json, fill in the necessary configuration details, and commit them to a branch. Once committed, you can initiate deployment with:
gmctl commit deploy -r "<deployment-artifacts-git-repo>" -b main
This command works with the latest commit and all associated file changes. It can also be invoked from your CI/CD pipeline.
How does GitMoxi know which files belong to which service object?
GitMoxi relies on a specific file naming convention to identify and group deployment artifacts related to a particular service object.
For Amazon ECS services, the following suffixes are required:
_svcdef.json: ECS service definition_taskdef.json: ECS task definition_depdef.json: GitMoxi deployment configuration for ECS_input.json: Substitution valuesFor AWS Lambda functions, use these suffixes:
_lambdadef.json: Lambda function definition_lambdaeventsourcedef.json: Lambda event source mapping_lambdadepdef.json: GitMoxi deployment configuration for Lambda_lambdainput.json: Substitution valuesGitMoxi groups all files with the same path-prefix as belonging to one service object. For instance, the following files:
dev/nginx/nginx_svcdef.json
dev/nginx/nginx_taskdef.json
dev/nginx/nginx_input.json
dev/nginx/nginx_depdef.json
…share a path-prefix of dev/nginx/nginx and are thus treated as a single service object. The path-prefix is defined as the directory path plus the file name, minus the GitMoxi-specific suffix.
To ensure GitMoxi can properly associate files:
A good practice is to store related files in the same directory, start filenames with the service name, and append the appropriate suffix.
Note: ECS files (_svcdef.json, _taskdef.json) and Lambda files (_lambdadef.json, _lambdaeventsourcedef.json) should contain only native AWS attributes. GitMoxi does not introduce any proprietary fields.
To use GitMoxi in your GitOps workflow:
Next, we’ll dive deeper into how GitMoxi deploys ECS services and Lambda functions based on changes to these deployment artifact files.
Experience the power of Gitmoxi — your go-to solution for simple, flexible, and transparent deployment management