Rename the Azure module and reimagine the Azure support

[nagyesta]

Hi,
first of all, thank you for working on the great project, it saved me a lot of work over the years!
In fact, I am considering to open some PRs to add some more Azure modules which I think would be beneficial. But first, I wanted to ask whether that is something you would be okay with... Let me to explain the idea...

As I have seen, the Azure support is somewhat limited in the Java repository but has more useful modules in other languages. I think it could be great to have feature parity with the others. To be able to do that, we would need to follow the steps below:

1. Rename: Azure -> CosmosDB

I have noticed, that the module naming is different here, maybe it would be a good idea to consider renaming the Azure module to CosmosDB which is the only supported container in it. This would help the Java support to be in line with the .Net and Python projects.

2. Additional modules

Then we could add more modules similarly to the other languages as shown below:

.Net	Go	Node	Python
Azurite	Azurite	Azurite	Azurite
Service Bus

---

The benefits

With this, Java developers could benefit from all 3 modules as well (Azurite, CosmosDB, Service Bus). Plus they can use my third party module to emulate Azure Key Vault with Lowkey Vault if anyone would like.

Note

I am not asking you to make that module part of the project, because I don't qualify as a reputable source, violating the first rule of module submission right away:

Should be a Docker Hub official image, or published by a reputable source (ideally the company or organisation that officially supports the technology)

The problem

Of course, this would be a breaking change as the Azure module will be renamed.

The questions

• What do you think?
• Would you be okay if I opened PRs implementing any part of this plan?
• Do you have an alternative solution in mind?

Thank you in advance for your kind consideration!

[eddumelendez]

Hi, thanks for bringing this topic. Azure module should contain implementations for Azure products such as Cosmosdb, Azurite, EventHubs and ServiceBus emulators.

Regardless of multiple modules or one module the user would have access to all implementations provided by Testcontainers.

Adding AzuriteContainer should be straightforward. See https://github.com/eddumelendez/testcontainers-samples/blob/589ac4d32c013cc66b7f26b83bff5ea81bb629ec/spring-cloud-azure-eventhubs/src/test/java/com/example/springcloudazureeventhubs/SpringCloudAzureEventHubsApplicationTests.java#L45-L48. PR is welcome

EventHubs depends on Azurite. See https://github.com/eddumelendez/testcontainers-samples/blob/main/spring-cloud-azure-eventhubs/src/test/java/com/example/springcloudazureeventhubs/SpringCloudAzureEventHubsApplicationTests.java#L45-L62. The expected behavior would be to allow declare EventHubsContainer and under the hood will start AzuriteContainer. Also, declare and external azurite instance if needed. Due to API limitations I would go with only first approach. PR is welcome

ServiceBus depends on Azure SQL Edge. See https://github.com/Azure/azure-service-bus-emulator-installer/blob/main/Docker-Compose-Template/docker-compose-default.yml. Similar to what is described for EventHubs. However, I haven't explore Azure SQL Edge, looking at Testcontainers for .NET, the MSSQL module should help. AFAIK, the Azure ServiceBus doesn't support the emulator url yet, so we should wait for it. See Azure/azure-service-bus-emulator-installer#25

[nagyesta]

Hi @eddumelendez ,
thank you, I will look into it and send PRs when ready!

[nagyesta]

Hi @eddumelendez ,
FYI: I finally managed to create a PR for the Azurite Container, please find it here: #9661