Does docker compose v3 support copy: property?

Docker Engine Compose
1

I would like to copy package.json file from a host machine to a docker container. I use the latest docker version ‘3.8’ and I get an issue like this:

services.server Additional property copy is not allowed

Also I can not find any reference to copy: property within a docker documentation (except volume:nocopy)

My docker-compose.yaml is:

version '3.8'
services:
  server:
    
    container_name: server

    image: node:18-alpine

    # command: bash -c "npm install && npm start" # alpine image doesn't have bash installed 

    # working_dir: /server
    
    volumes:
      - ./infrastructure/server:/server
      - ./server:/usr/src/swap/server
    
    copy: ./server:/usr/src/swap/server

    command: > 
      sh -c "
        npm install && npm start"

    ports:
      - "3100:3100"

    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 512M

    depends_on:
      database:
        condition: service_healthy

I referenced this code sample which gives me an idea this is still possible. However, even I run a plain code sample from that blog post, I get the same issue.

Environment:
Docker version 23.0.4, build f480fb1
Ubuntu 22.04.2 LTS

Does docker compose v3 support this property? If yes, how to make it work?

Thanks!

2
  • First of all, there is no such thing as “Docker Compose v3”. 3.8 in the compose file is the compose yaml syntax version
  • The version number in the compse file is syntactically incorrect.
  • The latest Docker Compose version is v2.17.3 and you no longer need to add a version number in the compose file. Compose v2 will not use it.
  • If you want to know what Docker Compose supports, you can check the compose specification:
    compose-spec/spec.md at master · compose-spec/compose-spec · GitHub

I don’t know that codetryout website, but Docker Compose never supported “copy”. At least I have never heard of it and I don’t even know why anyone would need it.

  • You can use volumes and mount files or folders into the container.
  • You can build your own image and use the COPY instruction of the Dockerfile which actually exists. It works with remote hosts too.
  • Since you can build images using Docker Compose, you really don’t need a copy instruction for the container.
  • Even if copy were an existing compose property, you are not using the syntax mentioned in the article.
1 Like
3

@gelassen did you find any other site or blog post that mentions what the codetryout.com blog claims to exist? I doubt there is any, as @rimelek already pointed out, it was never specified in any version of the compose file specification.

4

Thank you for your reply! It is good to confirm copy as a compose yaml file property doesn’t exist.

In terms where I need it, it is a time when I want to copy a file from my local folder to the container and that’s all. I want to avoid permanent volume mappings when, in my view, it breaks isolation between a container and a host machine. I migrate my project from VM to Docker and my initial expectations are to have similar experience - 20gb allocated to the VM and the absolute isolation from the rest of the machine.

After a week of work with Docker I understand it is not a full replacement. Better utilisation of a host machine resources has its own cost. More information about increasing container isolation and, therefore, possible holes and breaches could be found here: Key features and benefits | Docker Documentation

@meyay, thank you for your reply too!

5

I feel @rimeleks post should be marked as solution.

Everything inside the compose file configures resources using the same apis under the hood that docker {ressource} create use. Adding support for a copy element would mix resource configuration with container actions.

Almost looks like codetryout made a late April Fool’s joke :smiley:

6

Or early since the article was written in March. Or someone found a changed fork of docker compose and thought it was official and wrote an article about that.

Well, it doesn’t, assuming you are using it correctly. Of course, if you are mounting a system folder with write permission or you write files to the mounted folder and a process on the host reads that and executes that, that could do some harm, but just mounting an empty fodler or one that contains exactly that you want to see in the container is not less safe than copying a file inside the container.

The container’s filesystem is still a filesystem of the host, except the processes inside the container can’t see the rest of the host’s filesystem so copying a file into the containers writable layer is not so different from mounting a specific file or folder into the container.

As I wrote in my previous answer, you can copy files into the image. You can even have a Dockerfile with only two lines. A FROM instruction referring to the base image and a COPY instruction which would be fast and the files would be inside the container when the process starts in it.

Also note that if you don’t use volumes (or bind mounts) you can loose data if the containers crashes for some reason and you have to recreate it as everything on the container’s writable layer will be deleted… Not all applications work with local data so it is not always a problem.

Regarding the isolation, you can use diffrent runtimes. runc is just the default which creates containers. If you feel you want a very small VM, you can use for example the “kata” runtime.

It won’t solve the volume issue though.