How to run a docker compose file from .Net Aspire.

[Akhtaruzzaman]

I have multiple services that require a Docker Compose file to be run before starting. I have added a .NET Aspire application to manage all the services, but now I cannot run the Docker Compose file from the .NET Aspire application. Is there any way to run Docker Compose from .NET Aspire?

[davidfowl]

.NET Aspire's orchestration replaces docker compose, so you don't run docker compose from aspire.

[isaacrlevin]

I think service discovery is the primary thing in this case and I would assume to get more of the goodness I would need to adopt Aspire for the whole end to end. I understand getting things like dashboard and OTEL by default would be great but requires probably a bit of work.

[davidfowl]

Do you want this to be bidirectional? Services running in compose can talk to the app host and vice versa?

[isaacrlevin]

Bidirectional would be awesome if possible, but I think Aspire being able to discover docker compose is most beneficial

[davidfowl]

Bidirectional would require you to change your docker compose files.

[isaacrlevin]

I assumed so, that is why I said awesome, but one way is what I was thinking initially

[MadL1me]

+1 for this feature

My primary use case for Aspire is to run it locally as a single orchestration point for container management, benefiting from features like the dashboard, OTEL metrics collection, and debugging. In our setup, we use GitLab CI along with a suite of integration tests that require infrastructure components (PostgreSQL, Kafka, Redis, etc). To manage container lifetimes (e.g., for testing migrations or running performance tests), we currently rely on docker compose (so you can run for example just a postgres container and do stuff with it)

We end up maintaining two separate configurations that need to stay in sync. Managing these configurations is tedious and error-prone, and simplifying this process would be a significant productivity boost.

It feels more natural for Aspire to integrate directly with docker compose (like the way it allows to use raw dockerfiles), allowing developers to maintain a single configuration file

[danegsta]

Main headache would be that parsing a compose file can get extremely complicated very quickly. Beyond that, I’m not sure if the expectation is that we would run a single service from a compose config or if the idea was that we’d spin up every service (like compose up)? In the first case it feels a bit fragile vs. just adding a native Aspire service config (and there may be service dependencies we wouldn’t be able to fulfill in that case). If we’re supposed to be creating one Aspire container for every compose service, I think the scope of the problem would quickly become prohibitive (both from trying to implement handling for app model features and chasing down bugs that would inevitably arise from edge cases in user configurations).

This feels like something that would be an interesting problem for the community toolkit but a hard sell as a core Aspire feature.

[davidfowl]

Not sure we want to parse it tbh, I was thinking of a more hands off interop story where dcp can run compose files and maybe join it to the same network so it can exist like a single resource.

[danegsta]

I'm not sure we could wire everything up without some parsing, but it would theoretically be possible to spin up a compose config and attach it to the network. We'd have to rework some of our network logic though (we currently don't allow non-DCP managed containers to connect to a non-persistent DCP managed network as that would potentially impact our ability to clean up networks on shutdown).

If we went that approach, we'd likely need to add a new "compose" resource in DCP that would handle executing the compose commands and that would create child resources (containers, networks, volumes, etc.) to track the actual resources managed by compose.

[davidfowl]

If we went that approach, we'd likely need to add a new "compose" resource in DCP that would handle executing the compose commands and that would create child resources (containers, networks, volumes, etc.) to track the actual resources managed by compose.

That's what I am thinking.

[ahmadalsadder]

@davidfowl @danegsta I'm facing a similar challenge. I want to run the OpenSearch Docker image and configure it using settings defined in a separate configuration file (e.g., enabling plugins, specifying resource limits, setting a custom entry point). These configurations currently exist in a docker-compose.yml file.

Do you have any recommendations on how best to structure this setup or manage these configurations effectively?

raven.opensearch:
    image: opensearchproject/opensearch:latest
    user: "1000:1000"
    privileged: true
    restart: on-failure
    ports:
      - "9201:9200"
      - "9601:9600"
    environment:
      cluster.name: raven-cluster
      node.name: raven-single
      discovery.type: single-node
      opensearch_java_opts: "-Xms512m -Xmx512m"
      bootstrap.memory_lock: true
      plugins.security.disabled: true
      OPENSEARCH_INITIAL_ADMIN_PASSWORD: ${OPENSEARCH_PASSWORD}
    volumes:
      - raven_opensearch-data:/usr/share/opensearch/data
      - ./opensearch.yml:/usr/share/opensearch/config/opensearch.yml 
    ulimits:
      memlock:
        soft: -1
        hard: -1
    command: >
      sh -c "chown -R 1000:1000 /usr/share/opensearch/data && /usr/share/opensearch/opensearch-docker-entrypoint.sh"
    networks:
      - raven-network
    healthcheck:
      test: ["CMD-SHELL", "curl -s -f -o /dev/null http://localhost:9201/_cluster/health"]
      interval: 30s
      timeout: 10s
      retries: 5