Post Syndicated from Joerg Woehrle original https://aws.amazon.com/blogs/devops/keeping-up-with-your-dependencies-building-a-feedback-loop-for-shared-libraries/
In a microservices world, it’s common to share as little as possible between services. This enables teams to work independently of each other, helps to reduce wait times and decreases coupling between services.
However, it’s also a common scenario that libraries for cross-cutting-concerns (such as security or logging) are developed one time and offered to other teams for consumption. Although it’s vital to offer an opt-out of those libraries (namely, use your own code to address the cross-cutting-concern, such as when there is no version for a given language), shared libraries also provide the benefit of better governance and time savings.
To avoid these pitfalls when sharing artifacts, two points are important:
- For consumers of shared libraries, it’s important to stay up to date with new releases in order to benefit from security, performance, and feature improvements.
- For producers of shared libraries, it’s important to get quick feedback in case of an involuntarily added breaking change.
Based on those two factors, we’re looking for the following solution:
- A frictionless and automated way to update consumer’s code to the latest release version of a given library
- Immediate feedback to the library producer in case of a breaking change (the new version of the library breaks the build of a downstream system)
In this blog post I develop a solution that takes care of both those problems. I use Amazon EventBridge to be notified on new releases of a library in AWS CodeArtifact. I use an AWS Lambda function along with an AWS Fargate task to automatically create a pull request (PR) with the new release version on AWS CodeCommit. Finally, I use AWS CodeBuild to kick off a build of the PR and notify the library producer via EventBridge and Amazon Simple Notification Service (Amazon SNS) in case of a failure.
Overview of solution
Let’s start with a short introduction on the services I use for this solution:
- CodeArtifact – A fully managed artifact repository service that makes it easy for organizations of any size to securely store, publish, and share software packages used in their software development process. CodeArtifact works with commonly used package managers and build tools like Maven, Gradle, npm, yarn, twine, and pip.
- CodeBuild – A fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy.
- CodeCommit – A fully-managed source control service that hosts secure Git-based repositories.
- EventBridge – A serverless event bus that makes it easy to connect applications together using data from your own applications, integrated software as a service (SaaS) applications, and AWS services. EventBridge makes it easy to build event-driven applications because it takes care of event ingestion and delivery, security, authorization, and error handling.
- Fargate – A serverless compute engine for containers that works with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Fargate removes the need to provision and manage servers, lets you specify and pay for resources per application, and improves security through application isolation by design.
- Lambda – Lets you run code without provisioning or managing servers. You pay only for the compute time you consume.
- Amazon SNS – A fully managed messaging service for both application-to-application (A2A) and application-to-person (A2P) communication.
The resulting flow through the system looks like the following diagram.
In my example, I look at two independent teams working in two different AWS accounts. Team A is the provider of the shared library, and Team B is the consumer.
Let’s do a high-level walkthrough of the involved steps and components:
- A new library version is released by Team A and pushed to CodeArtifact.
- CodeArtifact creates an event when the new version is published.
- I send this event to the default event bus in Team B’s AWS account.
- An EventBridge rule in Team B’s account triggers a Lambda function for further processing.
- The function filters SNAPSHOT releases (in Maven a SNAPSHOT represents an artifact still under development that doesn’t have a final release yet) and runs an Amazon ECS Fargate task for non-SNAPSHOT versions.
- The Fargate task checks out the source that uses the shared library, updates the library’s version in the pom.xml, and creates a pull request to integrate the change into the mainline of the code repository.
- The pull request creation results in an event being published.
- An EventBridge rule triggers the CodeBuild project of the downstream artifact.
- The result of the build is published as an event.
- If the build fails, this failure is propagated back to the event bus of Team A.
- The failure is forwarded to an SNS topic that notifies the subscribers of the failure.
Amazon EventBridge
A central component of the solution is Amazon EventBridge. I use EventBridge to receive and react on events emitted by the various AWS services in the solution (e.g., whenever a new version of an artifact gets uploaded to CodeArtifact, when a PR is created within CodeCommit or when a build fails in CodeBuild). Let’s have a high-level look on some of the central concepts of EventBridge:
- Event Bus – An event bus is a pipeline that receives events. There is a default event bus in each account which receives events from AWS services. One can send events to an event bus via the PutEvents API.
- Event – An event indicates a change in e.g., an AWS environment, a SaaS partner service or application or one of your applications.
- Rule – A rule matches incoming events on an event bus and sends them to targets for processing. To react on a particular event, one creates a rule which matches this event. To learn more about the rule concept check out Rules on the EventBridge documentation.
- Target – When an event matches the event pattern defined in a rule it is send to a target. There are currently more than 20 target types available in EventBridge. In this blog post I use the targets provided for: an event bus in a different account, a Lambda function, a CodeBuild project and an SNS topic. For a detailed list on available targets see Amazon EventBridge targets.
Solution Details:
In this section I walk through the most important parts of the solution. The complete code can be found on GitHub. For a detailed view on the resources created in each account please refer to the GitHub repository.
I use the AWS Cloud Development Kit (CDK) to create my infrastructure. For some of the resource types I create, no higher-level constructs are available yet (at the time of writing, I used AWS CDK version 1.108.1). This is why I sometimes use low-level AWS CloudFormation constructs or even use the provided escape hatches to use AWS CloudFormation constructs directly.
The code for the shared library producer and consumer is written in Java and uses Apache Maven for dependency management. However, the same concepts apply to e.g., Node.js and npm.
Notify another account of new releases
To send events from EventBridge to another account, the receiving account needs to specify an EventBusPolicy. The AWS CDK code on the consumer account looks like the following code:
new events.CfnEventBusPolicy(this, 'EventBusPolicy', {
statementId: 'AllowCrossAccount',
action: 'events:PutEvents',
principal: consumerAccount
});With that the producer account has the permission to publish events into the event bus of the consumer account.
I’m interested in CodeArtifact events that are published on the release of a new artifact. I first create a Rule which matches those events. Next, I add a target to the rule which targets the event bus of account B. As of this writing there is no CDK construct available to directly add another account as a target. That is why I use the underlying CloudFormation CfnRule to do that. This is called an escape hatch in CDK. For more information about escape hatches, see Escape hatches.
const onLibraryReleaseRule = new events.Rule(this, 'LibraryReleaseRule', {
eventPattern: {
source: [ 'aws.codeartifact' ],
detailType: [ 'CodeArtifact Package Version State Change' ],
detail: {
domainOwner: [ this.account ],
domainName: [ codeArtifactDomain.domainName ],
repositoryName: [ codeArtifactRepo.repositoryName ],
packageVersionState: [ 'Published' ],
packageFormat: [ 'maven' ]
}
}
});
/* there is currently no CDK construct provided to add an event bus in another account as a target.
That's why we use the underlying CfnRule directly */
const cfnRule = onLibraryReleaseRule.node.defaultChild as events.CfnRule;
cfnRule.targets = [ {arn: `arn:aws:events:${this.region}:${consumerAccount}:event-bus/default`, id: 'ConsumerAccount'} ];For more information about event formats, see CodeArtifact event format and example.
Act on new releases in the consumer account
I established the connection between the events produced by Account A and Account B: The events now are available in Account B’s event bus. To use them, I add a rule which matches this event in Account B:
const onLibraryReleaseRule = new events.Rule(this, 'LibraryReleaseRule', {
eventPattern: {
source: [ 'aws.codeartifact' ],
detailType: [ 'CodeArtifact Package Version State Change' ],
detail: {
domainOwner: [ producerAccount ],
packageVersionState: [ 'Published' ],
packageFormat: [ 'maven' ]
}
}
});Add a Lambda function target
Now that I created a rule to trigger anytime a new package version is published, I will now add an EventBridge target which triggers my runTaskLambda Lambda Function. The below CDK code shows how I add our Lambda function as a target to the onLibraryRelease rule. Notice how I extract information from the event’s payload and pass it into the Lambda function’s invocation event.
onLibraryReleaseRule.addTarget(
new targets.LambdaFunction( runTaskLambda,{
event: events.RuleTargetInput.fromObject({
groupId: events.EventField.fromPath('$.detail.packageNamespace'),
artifactId: events.EventField.fromPath('$.detail.packageName'),
version: events.EventField.fromPath('$.detail.packageVersion'),
repoUrl: codeCommitRepo.repositoryCloneUrlHttp,
region: this.region
})
}));Filter SNAPSHOT versions
Because I’m not interested in Maven SNAPSHOT versions (such as 1.0.1-SNAPSHOT), I have to find a way to filter those and only act upon non-SNAPSHOT versions. Even though content-based filtering on event patterns is supported by Amazon EventBridge, filtering on suffixes is not supported as of this writing. This is why the Lambda function filters SNAPSHOT versions and only acts upon real, non-SNAPSHOT, releases. For those, I start a custom Amazon ECS Fargate task by using the AWS JavaScript SDK. My function passes some environment overrides to the Fargate task in order to have the required information about the artifact available at runtime.
In the following function code, I pass all required information to create a pull request into the environment of the Fargate task:
const AWS = require('aws-sdk');
const ECS = new AWS.ECS();
exports.handler = async (event) => {
console.log(`Received event: ${JSON.stringify(event)}`)
const artifactVersion = event.version;
const artifactId = event.artifactId;
if ( artifactVersion.indexOf('SNAPSHOT') > -1 ) {
console.log(`Skipping SNAPSHOT version ${artifactVersion}`)
} else {
console.log(`Triggering task to create pull request for version ${artifactVersion} of artifact ${artifactId}`);
const params = {
launchType: 'FARGATE',
taskDefinition: process.env.TASK_DEFINITION_ARN,
cluster: process.env.CLUSTER_ARN,
networkConfiguration: {
awsvpcConfiguration: {
subnets: process.env.TASK_SUBNETS.split(',')
}
},
overrides: {
containerOverrides: [ {
name: process.env.CONTAINER_NAME,
environment: [
{name: 'REPO_URL', value: process.env.REPO_URL},
{name: 'REPO_NAME', value: process.env.REPO_NAME},
{name: 'REPO_REGION', value: process.env.REPO_REGION},
{name: 'ARTIFACT_VERSION', value: artifactVersion},
{name: 'ARTIFACT_ID', value: artifactId}
]
} ]
}
};
await ECS.runTask(params).promise();
}
};Create the pull request
With the environment set, I can use a simple bash script inside the container to create a new Git branch, update the pom.xml with the new dependency version, push the branch to CodeCommit, and use the AWS Command Line Interface (AWS CLI) to create the pull request. The Docker entrypoint looks like the following code:
#!/usr/bin/env bash
set -e
# clone the repository and create a new branch for the change
git clone --depth 1 $REPO_URL repo && cd repo
branch="library_update_$(date +"%Y-%m-%d_%H-%M-%S")"
git checkout -b "$branch"
# replace whatever version is currently used by the new version of the library
sed -i "s/<shared\.library\.version>.*<\/shared\.library\.version>/<shared\.library\.version>${ARTIFACT_VERSION}<\/shared\.library\.version>/g" pom.xml
# stage, commit and push the change
git add pom.xml
git -c "user.name=ECS Pull Request Creator" -c "[email protected]" commit -m "Update version of ${ARTIFACT_ID} to ${ARTIFACT_VERSION}"
git push --set-upstream origin "$branch"
# create pull request
aws codecommit create-pull-request --title "Update version of ${ARTIFACT_ID} to ${ARTIFACT_VERSION}" --targets repositoryName="$REPO_NAME",sourceReference="$branch",destinationReference=main --region "$REPO_REGION"
After a successful run, I can check the CodeCommit UI for the created pull request. The following screenshot shows the changes introduced by one of my pull requests during testing:
Now that I have the pull request in place, I want to verify that the dependency update does not break my consumer code. I do this by triggering a CodeBuild project with the help of EventBridge.
Build the pull request
The ingredients I use are the same as with the CodeArtifact event. I create a rule that matches the event emitted by CodeCommit (limiting it to branches that match the prefix used by our Fargate task). Afterwards I add a target to the rule to start the CodeBuild project:
const onPullRequestCreatedRule = new events.Rule(this, 'PullRequestCreatedRule', {
eventPattern: {
source: [ 'aws.codecommit' ],
detailType: [ 'CodeCommit Pull Request State Change' ],
resources: [ codeCommitRepo.repositoryArn ],
detail: {
event: [ 'pullRequestCreated' ],
sourceReference: [ {
prefix: 'refs/heads/library_update_'
} ],
destinationReference: [ 'refs/heads/main' ]
}
}
});
onPullRequestCreatedRule.addTarget( new targets.CodeBuildProject(codeBuild, {
event: events.RuleTargetInput.fromObject( {
projectName: codeBuild.projectName,
sourceVersion: events.EventField.fromPath('$.detail.sourceReference')
})
}));This triggers the build whenever a new pull request is created with a branch prefix of refs/head/library_update_.
You can easily add the build results as a comment back to CodeCommit. For more information, see Validating AWS CodeCommit Pull Requests with AWS CodeBuild and AWS Lambda.
My last step is to notify an SNS topic in in case of a failing build. The SNS topic is a resource in Account A. To target a resource in a different account I need to forward the event to this account’s event bus. From there I then target the SNS topic.
First, I forward the failed build event from Account B into the default event bus of Account A:
const onFailedBuildRule = new events.Rule(this, 'BrokenBuildRule', {
eventPattern: {
detailType: [ 'CodeBuild Build State Change' ],
source: [ 'aws.codebuild' ],
detail: {
'build-status': [ 'FAILED' ]
}
}
});
const producerAccountTarget = new targets.EventBus(events.EventBus.fromEventBusArn(this, 'cross-account-event-bus', `arn:aws:events:${this.region}:${producerAccount}:event-bus/default`))
onFailedBuildRule.addTarget(producerAccountTarget);Then I target the SNS topic in Account A to be notified of failures:
const onFailedBuildRule = new events.Rule(this, 'BrokenBuildRule', {
eventPattern: {
detailType: [ 'CodeBuild Build State Change' ],
source: [ 'aws.codebuild' ],
account: [ consumerAccount ],
detail: {
'build-status': [ 'FAILED' ]
}
}
});
onFailedBuildRule.addTarget(new targets.SnsTopic(notificationTopic));See it in action
I use the cdk-assume-role-credential-plugin to deploy to both accounts, producer and consumer, with a single CDK command issued to the producer account. To do this I create roles for cross account access from the producer account in the consumer account as described here. I also make sure that the accounts are bootstrapped for CDK as described here. After that I run the following steps:
- Deploy the Stacks:
cd cdk && cdk deploy --context region=<YOUR_REGION> --context producerAccount=<PRODUCER_ACCOUNT_NO> --context consumerAccount==<CONSUMER_ACCOUNT_NO> --all && cd - - After a successful deployment CDK prints a set of export commands. I set my environment from those Outputs:
❯ export CODEARTIFACT_ACCOUNT=<MY_PRODUCER_ACCOUNT>
❯ export CODEARTIFACT_DOMAIN=<MY_CODEARTIFACT_DOMAIN>
❯ export CODEARTIFACT_REGION=<MY_REGION>
❯ export CODECOMMIT_URL=<MY_CODECOMMIT_URL> - Setup Maven to authenticate to CodeArtifact
export CODEARTIFACT_TOKEN=$(aws codeartifact get-authorization-token --domain $CODEARTIFACT_DOMAIN --domain-owner $CODEARTIFACT_ACCOUNT --query authorizationToken --output text) - Release the first version of the shared library to CodeArtifact:
cd library_producer/library && mvn --settings ./settings.xml deploy && cd - - From a console which is authenticated/authorized for CodeCommit in the Consumer Account
- Setup git to work with CodeCommit
- Push the code of the library consumer to CodeCommit:
cd library_consumer/library && git init && git add . && git commit -m "Add consumer to codecommit" && git remote add codecommit $CODECOMMIT_URL && git push --set-upstream codecommit main && cd -
- Release a new version of the shared library:
cd library_producer/library && sed -i '' 's/<version>1.0.0/<version>1.0.1/' pom.xml && mvn --settings settings.xml deploy && cd - - After 1-3 minutes a Pull Request is created in the CodeCommit repo in the Consumer Account and a build is run to verify this PR:
- In case of a build failure, you can create a subscription to the SNS topic in Account A to act upon the broken build.
Clean up
In case you followed along with this blog post and want to prevent incurring costs you have to delete the created resources. Run cdk destroy --context region=<YOUR_REGION> --context producerAccount=<PRODUCER_ACCOUNT_NO> --context consumerAccount==<CONSUMER_ACCOUNT_NO> --all to delete the CloudFormation stacks.
Conclusion
In this post, I automated the manual task of updating a shared library dependency version. I used a workflow that not only updates the dependency version, but also notifies the library producer in case the new artifact introduces a regression (for example, an API incompatibility with an older version). By using Amazon EventBridge I’ve created a loosely coupled solution which can be used as a basis for a feedback loop between library creators and consumers.
What next?
To improve the solution, I suggest to look into possibilities of error handling for the Fargate task. What happens if the git operation fails? How do we signal such a failure? You might want to replace the AWS Fargate portion with a Lambda-only solution and use AWS Step Functions for better error handling.
As a next step, I could think of a solution that automates updates for libraries stored in Maven Central. Wouldn’t it be nice to never miss the release of a new Spring Boot version? A Fargate task run on a schedule and the following code should get you going:
curl -sS 'https://search.maven.org/solrsearch/select?q=g:org.springframework.boot%20a:spring-boot-starter&start=0&rows=1&wt=json' | jq -r '.response.docs[ 0 ].latestVersion'
Happy Building!
Author bio
 |
Joerg is a Solutions Architect at AWS and works with manufacturing customers in Germany. As a former Developer, DevOps Engineer and SRE he enjoys building and automating things. |