Get DevServices ports via Quarkus CLI

[kdubb]

Description

Problem

We have lots of DevServices containers running during quarkusDev (and during tests). Additionally I usually have a couple other similar containers constantly running already (e.g. PostgreSQL & Vault). All this makes interacting with the correct DevServices container from a shell cumbersome and requires creating shell scripts if you want to repeatedly do this during development sessions.

Current Solutions:

DevUI

The DevUI shows some information for some containers but not all; I assume this will be remedied in the future. I'm guessing this container information is available on the management interface for it to be available in the DevUI so maybe something like cURL http://localhost/q/dev/some/thing | jq '.some.path' will be a viable solution. Which would provide a fairly consistent easy to use solution.

Docker PS

Filtering by label in Docker CLI is fairly easy but you have to know the label and value which, as far as I know, isn't really published anywhere.

For example to lookup the currently running Vault DevServices container you execute:

docker ps --filter "label=quarkus-dev-service-vault=vault"

Which means you need to know the label is docker ps --filterquarkus-dev-service-vaultand the valuevault`; additionally the value can be set via configuration. Obviously this is different for every container started via DevServices.

Finally, if some people are using Docker and others alternative runtimes, the commands are different.

Feature

Currently I've created scripts to nose through docker ps and setup my shell for Vault and others but this would be a great addition to the Quarkus CLI!

A simple command to list container ports or grab a specific container port that can be used interactively, or via a shell script, providing connection information about the currently running DevService container for an extension.

Some example...

List port mappings:

$ quarkus ds-port rabbitmq
RabbitMQ container host address: 0.0.0.0
Port: 5672 -> 55555
Port: 1567 -> 55556

List specific port mapping:

$ quarkus ds-port rabbitmq 5672
0.0.0.0:55555

List specific port mapping (port only):

$ quarkus ds-port rabbitmq 5672 --port-only
55555

Implementation ideas

Quarkus DevServices implementations provide a container locator for each service. Providing an endpoint (on the management interface) during dev sessions that uses the locators should be easy. The only "complex" bit might be mapping a canonical name (e.g. vault) to an extension (Quarkus-vault).

As I eluded too previously, it seems the DevUI has some information on running DevService containers and something like this might be available but the information is currently incomplete when running 3.2.2.Final.

[quarkus-bot[bot]]

/cc @ebullient (cli), @geoand (devservices), @maxandersen (cli), @stuartwdouglas (devservices)

[stuartwdouglas]

Have you seen the interactive postgres one?

If you have an app running with postgres dev service type ':' to get into interactive mode, then 'postgres print-command', it will give output like this:

You are now in Quarkus Terminal. Your app is still running. Use `help` or tab completion to explore, `quit` or `q` to return to your application.
quarkus$ 
a  alias  b  config  devservices  help  log  open  postgres  quit  test  ui  unalias  
quarkus$ postgres print-command 
PGPASSWORD=quarkus psql --host=localhost --port=32768 --username=quarkus quarkus

Basically you can just copy/paste that last line to connect.

[kdubb]

I had no idea this existed! devservices list is exactly the information I need; it listed all 5 of my devservices containers. So that's great that I'm a bit closer.

It seems like the information is there what would be the issue of extending the client to make it convenient for shell scripting?

[ebullient]

The client is a separate (unthethered) processes. If you had several Quarkus apps running in dev mode, which should it use?

[kdubb]

Good point, and one that would affect us regularly since we usually have at least two Quarkus apps running when doing local development.

My thought is that it would be able to use the current directory to decide.