[Bug]: Elasticsearch: Incorrectly detected OSS image

[OmarHawk]

Module

Elasticsearch

Testcontainers version

1.19.8

Using the latest Testcontainers version?

Yes

Host OS

Windows

Host Arch

amd64

Docker version

Client:
 Version:           26.1.0-rd
 API version:       1.44 (downgraded from 1.45)
 Go version:        go1.21.9
 Git commit:        cca8e72
 Built:             Tue Apr 23 16:26:59 2024
 OS/Arch:           windows/amd64
 Context:           default

Server:
 Engine:
  Version:          25.0.5
  API version:      1.44 (minimum version 1.24)
  Go version:       go1.21.10
  Git commit:       e63daec8672d77ac0b2b5c262ef525c7cf17fd20
  Built:            Sun May 12 07:25:43 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.7.10
  GitCommit:        4e1fe7492b9df85914c389d1f15a3ceedbb280ac
 runc:
  Version:          1.1.12
  GitCommit:        51d5e94601ceffbbd85688df1c928ecccbfa4685
 docker-init:
  Version:          0.19.0
  GitCommit:

What happened?

We are currently trying to use Azure Container registry (ACR) to serve as a pull through cache for Docker images. That one has quite some limitations (e.g.: https://github.com/Azure/acr/issues/599#issuecomment-1751689962), forcing us to configure the Elasticsearch Testcontainer like this (please note the library/ prefix):

            elasticsearchContainer = new ElasticsearchContainer(
                DockerImageName.parse("library/elasticsearch")
                    .asCompatibleSubstituteFor("docker.elastic.co/elasticsearch/elasticsearch")
                    .withTag("8.10.4")

            )

This one fails, as it claims it tries to use the OSS version of Elasticsearch while activating a password, even though it is not true (it is not the OSS image...) + I override this anyway with asCompatibleSubstituteFor

Relevant log output

2024-07-05T13:50:43.285Z  INFO 422 --- [dataview] [           main] ContainersSpringContextCustomizerFactory : Warming up the elastic database
2024-07-05T13:50:43.287Z  WARN 422 --- [dataview] [           main] o.t.e.ElasticsearchContainer             : library/elasticsearch is not supported anymore after 7.10.2. Please switch to docker.elastic.co/elasticsearch/elasticsearch
2024-07-05T13:50:43.332Z ERROR 422 --- [dataview] [           main] o.s.boot.SpringApplication               : Application run failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'de.mt.dataview.config.ElasticsearchTestContainer': You can not activate security on Elastic OSS Image. Please switch to the default distribution

Additional Information

Seems like the detection for isOss is could be improved - or maybe removed as it seems marked deprecated anyway...

https://github.com/testcontainers/testcontainers-java/blob/b4b1c2022d540177ada794b028c99fba5daeba1f/modules/elasticsearch/src/main/java/org/testcontainers/elasticsearch/ElasticsearchContainer.java#L108-L117

[eddumelendez]

Hi, I think the code should be

elasticsearchContainer = new ElasticsearchContainer(
     DockerImageName.parse("myregistry.azurecr.io/docker.io/library/elasticsearch")
        .asCompatibleSubstituteFor("docker.elastic.co/elasticsearch/elasticsearch")
        .withTag("8.10.4")
)

[OmarHawk]

We do have the host name written into testcontainers.properties file in our classpath via hub.image.name.prefix property as explained in https://java.testcontainers.org/features/image_name_substitution/

hub.image.name.prefix=myregistry.azurecr.io/docker.io/

That's why we don't mention it explicitly in our Java code.

[OmarHawk]

Hi, I think the code should be

elasticsearchContainer = new ElasticsearchContainer(
     DockerImageName.parse("myregistry.azurecr.io/docker.io/library/elasticsearch")
        .asCompatibleSubstituteFor("docker.elastic.co/elasticsearch/elasticsearch")
        .withTag("8.10.4")
)

Indeed, that did work - explicitly maintaining the registry name as part of the DockerImageName.parse call. I really do wonder why there is a difference between usage of

hub.image.name.prefix

and explicitly maintaining it in the Java code. In my opinion they are supposed to be treated equally.