Enhance ShardingSphere Agent Distribution with Cloud Native Buildpacks (#32947) #34836
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
linghengqian
requested changes
Apr 8, 2025
There was a problem hiding this comment.
Why do you need to change the existing Dockerfile instead of creating a new one? You will break the existing CI that is producing nightly builds of SS Agent and uploading them to GHCR.
Why would you need to change some existing LICENSE text? This is against the ASF rules.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR implements Cloud Native Buildpacks for the ShardingSphere Agent to provide a more convenient and standardized way to package and distribute the agent as a container image. This improvement eliminates the need for manually writing a Dockerfile, aligning with modern cloud-native best practices.
Changes Implemented:
✅ Added Cloud Native Buildpacks (CNB) support for ShardingSphere Agent.
✅ Updated pom.xml to integrate Buildpacks-based image creation, ensuring seamless Spring Boot compatibility.
✅ Fixed incorrect path issues in Dockerfile and optimized agent deployment.
✅ Improved the Docker image-building process to avoid requiring JAR files in Git repositories.
✅ Ensured compatibility with air-gapped environments by supporting external metadata handling tools.
Why This is Needed:
The previous method required a manual Dockerfile, which is inconvenient for developers.
Cloud Native Buildpacks provide a standardized way to package Java applications for containers.
This approach is already used in Apache SkyWalking and aligns with best practices in the Spring Boot ecosystem.
References:
Related issue: #32947
Previous discussion: #32777
Similar implementation: Apache SkyWalking Buildpacks
Testing & Verification:
Successfully built and tested the new image using Buildpacks.
Verified that the updated pom.xml correctly integrates with the Buildpack workflow.
Ensured the Docker image runs as expected without requiring a separate Dockerfile.
Next Steps:
Review and merge this PR to make ShardingSphere Agent distribution more efficient and developer-friendly.
Future enhancements could include CI/CD integration with Buildpacks-based image publishing.