search

testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.
https://dotnet.testcontainers.org
MIT License
3.77k stars 271 forks source link

[Enhancement]: Upgrade to Azurite >= 3.28.0 and support in-memory persistence #1056

Closed Xzelsius closed 10 months ago

Xzelsius commented 10 months ago

Problem

The current usage pattern of Azurite assumes that the caller is interested in persisting stored data beyond the lifetime of the node process. This certainly is useful for extended testing scenarios or where Azurite is actually used for production-like scenarios (perhaps a best-effort approach of free, on-prem Azure Storage). However, some Azurite use cases are more ephemeral in nature. For example, if you simply want to use Azurite for a single test run in a CI pipeline, you don't need the storage to persist beyond the lifetime of the node process.

Quote from: https://github.com/Azure/Azurite/blob/105a9cd217b881922016edb7a683ebea1ab3b28a/docs/designs/2023-10-in-memory-persistence.md

Depending on the amount and size of for example a blob there is an additional overhead on the test environment when Azurite has to write it to disk. In most scenarios, test containers won't survive more than one test run. So the overhead of writing to disk could be removed.

Solution

Upgrade to Azurite 3.28.0 or later and add support for the --inMemoryPersistence argument

Benefit

Using in-memory persistence may have a positive effect on overall performance of Azurite during tests, as it does not need to store stuff on disk.

Alternatives

Leave the current implementation as is

Would you like to help contributing this enhancement?

Yes

Xzelsius commented 10 months ago

If this is being added, --extentMemoryLimit <size limit in MB> should also be supported. And it should be discussed whether in-memory persistence is the default or opt-in.

HofmeisterAn commented 10 months ago

Indeed, this sounds like a good and reasonable change to the module. Removing an existing default configuration is always a bit tricky with the current builder design (read-only configuration). This speaks for an opt-in approach (in addition, it reduces the chances of breaking existing configurations). Besides that, I do not really have an option regarding opt-in or opt-out.

Xzelsius commented 10 months ago

So I would give it a try later today. If I struggle to extend the current implementation I get back to you :)