Improve OOB experience by consistently using full container names

Hello,

we've had Quarkus users complaining about unreliable & inconsistent bootstrap of containers via Testcontainers; a general pattern was that they were either using podman or using Windows, and out of the box configurations.

I finally figured that the reason is that when the container engine is configured with multiple registries, when a container is instantiated using the "short name" like e.g. testcontainers/ryuk:0.3.3 there is ambiguity; when attempting to fetch such a container from an interactive shell, the system will ask:

podman run testcontainers/ryuk:0.3.3

? Please select an image: 
  ▸ registry.fedoraproject.org/testcontainers/ryuk:0.3.3
    registry.access.redhat.com/testcontainers/ryuk:0.3.3
    docker.io/testcontainers/ryuk:0.3.3
    quay.io/testcontainers/ryuk:0.3.3

But when executing the equivalent command from Testcontainers there is no TTY, so the request will fail:

com.github.dockerjava.api.exception.BadRequestException: Status 400: {"cause":"short-name resolution enforced but cannot prompt without a TTY","message":"failed to resolve image name: short-name resolution enforced but cannot prompt without a TTY","response":400}

    at app//org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.execute(DefaultInvocationBuilder.java:237)
    at app//org.testcontainers.shaded.com.github.dockerjava.core.DefaultInvocationBuilder.lambda$executeAndStream$1(DefaultInvocationBuilder.java:269)
    at java.base@11.0.14.1/java.lang.Thread.run(Thread.java:829)

N.B.

• This problem is tricky to identify as it won't manifest if you already have fetched the image in the past; so it might need podman system reset (or docker equivalent) to verify.
• Choices made in the past during an interactive TTY are also recorded in ~/.cache/containers/short-name-aliases.conf
• It will also affect docker users, if Docker has been reconfigured to use additional registries. I don't have Windows myself but I'm told that this is the default in Windows (!) making this issue potentially nasty and widespread.
• podman users are affected as well, because it also uses multiple registries configured as default.
• ImagePullTest is using fullnames exclusively to test the ability to download ryuk. This implies that running the testsuite on any machine will ensure the image is then cached and this will hide any subsequent problem with it on the same machine.

Solution

The solution is trivial: ensure that all container image names are being declared with full names. E.g. adapt the string constants like testcontainers/ryuk:0.3.3 to quay.io/testcontainers/ryuk:0.3.3 in org.testcontainers.utility.TestcontainersConfiguration; most likely other container names also need to be patched (and that's why I don't send a PR myself... I only stumbled on the particular issue of ryuk images - I'd be happy to patch that myself but I'm not familiar enough with the codebase to ensure I'm finding all such instances).

I've already ensured that container names hardcoded in Quarkus, Hibernate ORM, Hibernate Reactive are consistently using full names; still this issue had eluded us so far as apparently we regularly use TESTCONTAINERS_RYUK_DISABLED=true, which would also prevent the particular issue with the ryuk container.

More background about the naming issue is described here:

• https://www.redhat.com/sysadmin/container-image-short-names

Beginne mit der Untersuchung von org.testcontainers.utility.TestcontainersConfiguration und dem ImagePullTest. Durchsuche anschließend die Codebasis nach weiteren fest codierten Container-Image-Namen, die kurze Namen wie testcontainers/ryuk:0.3.3 verwenden. Aktualisiere die identifizierten Image-Referenzen auf vollständig mit der Registry qualifizierte Namen und überprüfe die relevanten Tests, ohne dich auf bereits lokal zwischengespeicherte Images zu verlassen.