WithDataVolume Key Collision when Referencing Volumes Defined via AddDockerComposeEnvironment

[cilerler]

Referencing a volume defined within AddDockerComposeEnvironment().ConfigureComposeFile(...) via a resource's WithDataVolume() method causes an An item with the same key has already been added. during aspire publish

When I run this

var builder = DistributedApplication.CreateBuilder(args);
var compose = builder.AddDockerComposeEnvironment("compose")
        .ConfigureComposeFile(file =>
        {
            file.Volumes.Add("redisVolumeKey", new()
            {
                Name = "redisVolumeName",
                Driver = "local",
                DriverOpts = new Dictionary<string, string>
                {
                    ["type"] = "none",
                    ["o"] = "bind",
                    ["device"] = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.UserProfile), @".docker/volumes/mySolution/myVolume")
                }
            });
        });
var cache = builder.AddRedis("redis").WithDataVolume("redisVolumeName", false);
builder.Build().Run();

it generates

services:
  compose-dashboard:
    # ...
  redis:
    # ...
    volumes:
      - type: "volume"
        target: "/data"
        source: "redisVolumeName"    # <<
        read_only: false
    networks:
      - "aspire"
networks:
  aspire:
    driver: "bridge"
volumes:
  redisVolumeName:                   # << 
    driver: "local"
  redisVolumeKey:                    # << 
    driver: "local"
    driver_opts:
      type: "none"
      o: "bind"
      device: "C:\\Users\\myUser\\.docker/volumes/mySolution/myVolume"

if I change cache to

var cache = builder.AddRedis("redis").WithDataVolume("redisVolumeKey", false);

it throws ✗ PUBLISHING FAILED: An item with the same key has already been added. Key: redisVolumeKey upon running aspire publish -p docker-compose -o ./artifacts

Any workaround you may suggest?

[davidfowl]

Theres an existing volume being added, you can reference it via:

file.Volumes["redisVolumeKey"]

[cilerler]

Your suggestion, file.Volumes["redisVolumeKey"], seems to be for accessing the volume within the ConfigureComposeFile lambda. My problem is trying to reference that volume from a completely separate resource, builder.AddRedis("redis").

My goal is to:

1. 🟢Define a single, complex volume (a bind mount) inside AddDockerComposeEnvironment(...).
2. 🔴Tell the builder.AddRedis("redis") resource to use that exact volume (which is defined in a different resource) for its data path.

The issue I'm facing is that WithDataVolume() on the Redis resource seems to always try to create its own new volume definition in the root volumes: block, which then conflicts with the one I already defined in AddDockerComposeEnvironment.

• If I use the Aspire key (redisVolumeKey), aspire publish fails with the An item with the same key has already been added exception.
• If I use the Docker name (redisVolumeName), it doesn't fail, but it generates an incorrect docker-compose.yml with two different volume definitions (as shown in my original post).

Is there a supported way to make builder.AddRedis() mount an existing volume by name without it trying to define that volume?

Thanks again for your help!

[davidfowl]

I guess I don't see the difference? ConfigureComposeFile gets called after aspire has translated the high level resource model to the low level docker compose model. When you add a voulme, it adds it to the service definition and to the compose file in the volumes section. ConfigureComposeFile gives you a chance to mutate this after the fact in a programmatic way.

You can't reference a volume defined in the aspire app model, defined in the compose file, but you can change the volume described in the aspire model before the compose file is written.

aspire model -> compose model -> file on disk.

[cilerler]

Ah, thank you, David for setting me on the right path! 🤗
That clarification is exactly what I needed.