Document how to integrate Quarkiverse Amazon DevServices with custom Dev Services

[ryandens]

I have a quarkus app that uses Amazon S3 that I like to use in quarkus dev mode. I really enjoy and appreciate this extensions ability to start a localstack container and configure my AWS SDK inside the app.

My app has an external dependency on another service that I run locally with Docker. This service also needs access to the same localstack container as my app. I attempted to write a dev service and can quite easily create another extension that creates a new DevServicesResultBuildItem responsible for starting/stopping a docker container.

However, getting access to the localstack container's generated host name on the the network is quite challenging. This line of code is responsible for configuring the network with the hostname localstack-<random-string>.

It would be nice to be able to explicitly depend on the Amazon Dev Service build item in some way shape or form, but I was unable to do that. I can't reliably find that the amazon devservice container starts before my own build item so manually inspecting the docker daemon state and attempting to discover the localstack network/hostname/host port doesn't seem to work either.

Is there some mechanism I'm missing with quarkus extensions?

[scrocquesel]

AFAIK, it is currently not possible to orchestrate order of dev services from different extensions. I guess each container should be responsible of waiting for its dependencies to be available to be ready. This should be enough if the dependency graph acyclic and it keeps things simple and isolated.

When not possible, this discussion is a good start describing your issue. you could also look at this DevServices Processor where it implements a consumer of DevServicesLauncherConfigResultBuildItem to ultimately start a container but you will not be able to return dev services properties.

As for, Quarkus Amazon extension, I think that if we add ability to configure a network alias for the container, you should be able to connect to it from your other dev services when using a shared network. The line ConfigureUtil.configureSharedNetwork should be rewrited accordingly to a more recent pattern introduced by this PR. Then when shared network is turned on, we can add a predictable network aliases based on the serviceName (something like .withNetworkAliases(serviceName);) The alias will be localstack-s3 in dev mode.

Would you like to contribute ?

[ryandens]

Hi @scrocquesel - yes i'd be happy to contribute! The network alias makes a lot of sense. One thing I noticed was that the localstack container seems to always be configured to use a shared network today, the useSharedNetwork boolean is ignored. Do you want me to update this, potentially a breaking change for consumers of this project?

A way to do this without making this a breaking change would be to update the useSharedNetwork parameter to be calculated based on the new API (DevServicesSharedNetworkBuildItem.isSharedNetworkRequired(devServicesConfig, devServicesSharedNetworkBuildItem)) as specified in the PR you linked and then to only add the network alias if useSharedNetwork is true.

Alternatively, since the container is always configured with a shared network, we could simply always add the network alias like is done in other quarkus extensions that always use shared networking (keycloak, kerberos, rabbitmq, kafka, etc).

Let me know your thoughts!

[ryandens]

By the way, I got my use case to work following the conventions from microcks that you linked above! (Creating a build step that consumes DevServicesLauncherConfigResultBuildItem and produces anEmptyBuildItem. I thought initially this was not an option for me because I was relying on the DevServicesResultBuildItem.RunningDevService's ability to do config overrides to configure my Quarkus application with the container's dynamically assigned host port. Instead, I assigned a static host port so that I don't need to override the config and then was able to access the configured S3 endpoint using devServicesConfigResult.getConfig().get("quarkus.s3.endpoint-override").

[scrocquesel]

Alternatively, since the container is always configured with a shared network, we could simply always add the network alias like is done in other quarkus extensions that always use shared networking (keycloak, kerberos, rabbitmq, kafka, etc).

Let me know your thoughts!

I think this is the easiest and conformist solution.

[ryandens]

Sounds good, thanks! This will definitely simplify my setup, I can send a PR with the network alias. If it's helpful, I can include some docs about how to integrate another dev service with this extensions dev service