testcontainers-rs

testcontainers-rs copied to clipboard

The PR: https://github.com/testcontainers/testcontainers-rs/pull/135 added volume mapping support to testcontainer-rs.

With our current approach of removing containers (see here) these named volumes do not get removed, only anonymous volumes will be removed.

This means, your system will accumulated more and more containers and need to be removed manually.

Possible solutions

Manually remove volumes

We can manually remove the named volumes after we've removed the container (e.g. when the container gets out of scope). For this, we would need to implement volume rm [volume]. See docs here.

The issue here is that if the volume is still shared with another container, this command will fail. A possible solution here would be to only print a warning if this volume is still in use but remove the container. After the last container using this volume was removed, the volume can be removed safely.

Use anonymous volumes

As mentioned above, we can use anonymous volumes instead of named volumes. This has the advantage that the user does not have to provide a name for the volume. Anonymous volumes get automatically removed if the linked container gets removed PROVIDED the volume is not shared with another container.

In our public chat @thomaseizinger pointed out that variables get out of scope in the order they were created.

Proposed solution

Using anonymous volumes seems to be in favor for most usecases as sharing volumes between containers is an edge case. For the case where we want to share volumes between container, using anonymous volumes, would mean we need to inspect the container and find the correct volume id.

Hence, I propose the following:

• keep named volumes, i.e. use -v {named}:{internal}
• add a function inspect_volumes to retrieve a list of attached volumes

Optional (should become a new issue)

• add a function with_mount in addition to with_volume which allows to use the parameter --mount. While --volume won't get deprecated, --mount seems to be the preferred way. One difference is that --create non-existing named volumes while --mount will fail.

While --volume won't get deprecated, --mount seems to be the preferred way.

It is funny how the documentation contradicts itself here. From the first sentence of the volumes documentation:

Volumes are the preferred mechanism for persisting data generated by and used by Docker containers. While bind mounts are dependent on the directory structure and OS of the host machine, volumes are completely managed by Docker. Volumes have several advantages over bind mounts:

From reading the documentation, I get the feeling that a possible solution could be to make testcontainers manage volumes as separate entities the same way we manage containers, i.e. by creating a specific struct that implements a certain trait and has a Drop implementation to manage its lifecycle.

A container could then create a dedicated instance of this struct, expose it and allow other containers to mount it as well. That would model the lifecycle more explicitly.

We could probably do the same thing for networks.

Thank you, but I'm closing the issue for couple of reasons:

• current API doesn't provide named volumes yet
• new tracking issue is #582 (with reference to this one)