Support local volumes

[lionello]

Add support for locally mapped volumes. This could be implemented by building a sidecar image from the mapped files.

version: '3'
services:
  nextjs:
    restart: always
    image: caddy:2.7.6
    command: ["caddy", "file-server", "--root", "/static", "--listen", ":80"]
    #x-defang-static-files: /static
    volumes:
      - ./:/static
    ports:
      - target: 80
        published: 8000
        mode: ingress

Currently this emits a warning.

---

Discussion on what we should do based on customer needs, when do we need volumes?

1. Dumb static website case, i.e. snake game by vibe coder. Very rarely there is code should be served without a building step, i.e. typescript, react, nextjs etc. This is already covered by current static-website case, or the user would be having a dockerfile for building, which would not require volume mount
2. Mounting large files at runtime to avoid building huge images, i.e. LLM models. This is no longer needed by the majority, as most people use hosted models
3. Mounting a volume to read-write files: most likely application needs to persist state as files locally

• Due to software limitation, not able to use a remote database, or by design, i.e. NATS use case
• Due to inexperience: It is nearly impossible to share read/write files correctly amongst multiple instances, will not scale

As a result, the most useful volume mount support we can provide for our users are, single instance mount to a disk with RO/RW support. This may also be extended to covers case 1, where a dumb website could be served from it if we implement data copy to the volume.

[lionello]

This requires volume support, before we're able to copy the local files into the created volume.

[raphaeltm]

I'm going to flag that this issue seems to be about mounting files from a local build context into a volume, as opposed to #818 which is about creating a volume that should be populated by the image at runtime/and persisted.

[raphaeltm]

Though... depending on implementation, I guess these could work similarly:

• When defang compose up is run, we create a cloud volume (EBS or something)
  • If they're using the ./localdir:/containerdir syntax, we create it based on the ./localdir name
  • If they're using the volumename:/containerdir syntax we create it based on the volumename
• If they're using the ./localdir:/containerdir syntax, we check if there is anything in the volume
  • If there is, we copy that to the cloud volume

We need to figure out, with the ./localdir:/containerdir syntax, if we just upload the local data the first time the user runs defang compose up or every time.

I suspect we'll need a bunch of warnings to make this usable and safe at the same time.

[lionello]

Also see #818 and https://github.com/DefangLabs/defang-mvp/issues/2016