Improvement in the integration of docker and/or docker-compose real-time volumes.

[wnunezc]

Tell us about your request A clear and concise description of what you want to happen or the change you would like to see

I would like to be able to add volumes after the container is created.

Which service(s) is this request for? Let us know which product(s) you want this for?

I assume that the products or programs running on the host OS: docker and/or docker-compose

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Assuming that containers have the objective of offering a static and ephemeral service, we always find ourselves in the need to use volumes for data preservation, but surely it has happened to someone who has forgotten to add some resource to the initial construction of the container. container.

I have not found a viable way to add volumes in real time to a running container without having to remove and rebuild/recreate it, I think that restarting it would be enough but that is not the case.

Are you currently working around the issue? A clear and concise description of any alternative solutions or features you've considered or are using today.

Yes, I have done some tests, for example creating a volume pointing to a specific directory of the host operating system:

docker volume create --driver local --opt type=none --opt device=C:\test-server --opt o=bind new-volumen-name

So that developers can place the resources they need here.

At this point I already have the container running and the volume, I just need to tell the container hey, mount that volume on your >system in this directory: /var/www/html/directory_project

Try to do it with the command:

docker run -it -v new-volumen-name:/var/www/html/directory_project --name LAMP-Container

Output:

“docker run” requires at least 1 argument. See ‘docker run --help’.

Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG…]

Create and run a new container from an image

I would be missing something like:

docker attach -v new-volumen-name:/var/www/html/directory_project --name LAMP-Container

Additional context Add any other context or screenshots about the feature request here.

Try working around some commands: commit: can cause problems since its objective is not prepared to reuse the final state of the container, but it usually requires some configurations. docker cp: It focuses on manipulating content and not on parametrically injecting something into the structure.

The main scenario where this can occur is in a local development environment when resources are limited (Hardware) and the developer prefers to use:

A single PHP7.4 service (Container) and then add projects or resources in real time (Data preservation)…

[wnunezc]

Since this "attach" does not exist or a way to update "environment" variable in real-time, it is necessary to do the following:

1. Stop and delete the container in question:

docker stop LAMP-PHP8.3
docker rm LAMP-PHP8.3

2. Before implementing this solution, it is necessary to create the volumes as such pointing to the directory in our host operating system (these are just examples).

docker volume create --driver local --opt type=none --opt device=C:\test-server --opt o=bind php83-lh-2.dock
docker volume create --driver local --opt type=none --opt device=C:\test-server --opt o=bind php83-tcg-wallet.dock

Note: this allows you to create a volume that is visible to both the host operating system and any container to which it is included, it bidirectionally preserves the data, so it is essential and indispensable if we are working with a web project.

3. Separate the yml file from the options/Volumes file and main service container (split it).
4. Manually or programmatically alter the options file yml.

Example of the yaml file for the container:

services:
  webserver83:
    container_name: LAMP-PHP8.3
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    expose:
      - 80
    networks:
      - wsdd-network
    extra_hosts:
      - "host.docker.internal:host-gateway"
    labels:
      - "wsdd.webserver.description=Web Server php8.3"
      - "wsdd.webserver.role=webserver"
    privileged: true
    tty: true

networks:
  wsdd-network:
    external: true

Example of the yaml file for options and volumes:

services:
  webserver83:
    environment:
      VIRTUAL_HOST: localhost
    volumes:
      - ./vhost:/etc/apache2/sites-enabled
      - ./php.ini:/usr/local/etc/php/php.ini

Every time you add a project we must modify the options file, manually or programmatically adding: the domain, volume and drive of the project instance; see that modified file:

services:
  webserver83:
    environment:
      VIRTUAL_HOST: localhost,lh-2.dock,tcg-wallet.dock
    volumes:
      - ./vhost:/etc/apache2/sites-enabled
      - ./php.ini:/usr/local/etc/php/php.ini
      - php83-lh-2.dock:/var/www/html/lh-2.dock
      - php83-tcg-wallet.dock:/var/www/html/tcg-wallet.dock

volumes:
  php83-lh-2.dock:
    external: true
  php83-tcg-wallet.dock:
    external: true

Note: separating the yml file will help us work efficiently on the responsibility of each file, allowing us to keep track of a single file instead of touching the web service's yml file.

5. Once we have the modified files, we can with certainty do this:

docker-compose -p projects -f docker-webserver.yml -f docker-options.yml create --build
docker-compose -p projects -f docker-webserver.yml -f docker-options.yml up -d

Note: For my personal consideration, there are many manual and/or programmatic things that could be simplified.

Note2: This also requires editing the vhost pointing to site-enabled and the windows host file with the custom URLs to use. For more details, you can write to me.

[nicks]

thanks for the request!

my hand-wavey understanding of the underlying OCI spec is that a lot of things assume the container is immutable once you've started it. cf https://github.com/opencontainers/runtime-spec/blob/main/runtime.md

Any updates to config.json after this step MUST NOT affect the container.

And there's usually strong push-back on anything that changes the container spec at runtime. This affects all OCI-compatible images, not just Docker.

[wnunezc]

thanks for the request!

Thanks for the information. Limiting the application in this way has its clear advantages regarding the compatibility and the state of the images/containers created from those images, unfortunately this restricts the capabilities of WSL or in theory the virtual machine that is created from here.

[wnunezc]

There is no interest in implementing these adjustments. Regards.