Add a standalone, containerized agent #91
Conversation
Adds a new agent module which wraps EZE into a standalone command line executable. The new module comes with a docker profile which will produce a Docker image that will expose the 26500 port by default and can be used to run EZE standalone. Tests are minimal - testing the Docker image would require an additional integration/QA module as the build pipeline relies on Jib and not on a standard Dockerfile, which means we can't use Testcontainers to build the agent on the fly in the tests.
Adds a new step to the release pipeline to push the Docker image. This is triggered only on releases and will not push a SNAPSHOT image. Keep in mind that it will use the code in the repo as is, so technically the MANIFEST would still contain the wrong version of the executable, but the Docker image tag will be correctly overridden with the release tag. This is untested, and I'm happy to drop this commit for the initial PR.
There was a problem hiding this comment.
Love it thanks @npepinpe ❤️ 😍
I think we can iterate over it if we see something missing. I will merge it and try it out. The GHCR token is something I have to create in my account right?
Thanks again 🙇
Co-authored-by: Christopher Zell <[email protected]>
|
There were some improvements I would've liked to see, but it made the PR considerably bigger: adding the EZE version and Zeebe version when logging startup, being able to configure the bind address of the server as well as its transport (so, for example, using Unix domain socket instead of an IP address to completely avoid port collisions), producing a standalone executable JAR, adding a QA module to actually test the image, etc. Would be cool to have one day. Additionally, since this embeds Anyhow, I guess I'll let one of you merge this? Not sure what the process is now 🙃 |
Description
This PR adds a standalone agent which can be containerized and run as:
You can then use zbctl to interact with the engine as you would a normal Zeebe gateway (almost).
This is done by adding a new module,
agent, which simply wraps aZeebeEnginein a picocli wrapper. Nothing fancy was added (like configuration or dynamic versions). There's adockerprofile in the agent module which will use jib to produce a Docker image based onazul/zulu-openjdk-alpine:17-jre-headless, as this is the smallest Java 17 image available. We can always switch to something more standard if we want.By default, you can build the Docker image by running:
This will only trigger a local build of the image. To push the image, you'd run:
This will build and push the image to GHCR. The configuration assumes whoever runs this is already authenticated to GHCR. You can change the version/tag of the image by using the property
dockerImageTag.The last commit of the PR updates the pipeline to also push the image on releases, and will set the tag property to the release tag. One caveat is that the actual version in the manifest in the image will probably be the snapshot version and not the tag, I think, but I haven't tested it.
Feel free to reject, modify, ridicule, praise, whatever you want this PR 😄
Related issues
closes #44