cli

cli copied to clipboard

Description

Docker compose version 3.6 does not support platform attribute on a service object When running experimental and wanting to use LCOW 👍 I noticed it was added in 2.4 for docker compose https://github.com/docker/compose/pull/5767

which according to the version matrix should be supported by 3.5 and 3.6

Steps to reproduce the issue:

1. use version: '3.6' in docker-compose.yml file
2. add platform to service
3. run docker-compose config

My docker-compose.yml

version: '3.6'

services:
  jenkins:
    platform: linux
    env_file: prod.env
    container_name: jenkins
    image: jenkins-master
    build: .
    ports:
      - 8080:8080
      - 50000:50000
    volumes:
      - jenkins:/var/jenkins_home
    secrets:
      - id_rsa

volumes:
  jenkins:

secrets:
  id_rsa:
    file: .\secrets\jenkins_ssh_key

Describe the results you received:

ERROR: The Compose file '.\docker-compose.yml' is invalid because:
Unsupported config option for services.jenkins: 'platform'

Describe the results you expected: That platform is supported for a service

Additional information you deem important (e.g. issue happens only occasionally): https://github.com/docker/compose/issues/5953

Output of docker version:

Client:
 Version:      18.05.0-ce-rc1
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   33f00ce
 Built:        Thu Apr 26 00:57:53 2018
 OS/Arch:      windows/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.05.0-ce-rc1
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.10.1
  Git commit:   33f00ce
  Built:        Thu Apr 26 01:06:49 2018
  OS/Arch:      linux/amd64
  Experimental: true

Output of docker info:

Containers: 49
 Running: 0
 Paused: 0
 Stopped: 49
Images: 380
Server Version: 18.05.0-ce-rc1
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.87-linuxkit-aufs
Operating System: Docker for Windows
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.934GiB
Name: linuxkit-00155da60c09
ID: DPVM:5U4V:GKJW:DRAL:OQ3O:FIGK:7RPF:7QXW:GLQW:FPEM:SDNT:RP7W
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 20
 Goroutines: 36
 System Time: 2018-05-10T06:02:17.2846805Z
 EventsListeners: 1
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

https://github.com/docker/compose/pull/5767#issuecomment-391158566

v3 formats are frozen upon release.

Well that goes against having an experimental feature that was not included in the schema.

any reason it was only added to 2.4? and not 3.5 or 3.6? Which should be in the same version matrix.

@casz one reason for it to not being support in v3 formats is that it is not supported by Swarm Mode, and thus would have no effect on docker stack deploy — as v3 formats are mainly driven by stack deploy, that's a reason why it didn't get added to the v3 version. Also the --platform flag (on docker run) is a bit weird : it only targets (and works) with a specific version of the docker daemon, a.k.a windows dockerd with lcow support, lcow being experimental still. It doesn't have any effect or validation on Linux as of now (cc @johnstep @jhowardmsft @mavenugo I really think this is weird as hell).

That being said, I think one easy fix to that issue would be to add platform to v3 schema(s) — but it would start at schema 3.7 — and printing a warning when issuing a docker stack deploy that this field is not supported (same way we do it for build). It would allow to more easily updated from v2 to v3 for users and help us not make v2 and v3 schema diverge that much — at least not having elements in v2 that are not in v3…

cc @thaJeztah @chris-crone @shin- @dnephin

I agree with @vdemeester that current --platform switch implementation is bit weird but anyway I see that it should be included to v3.7 and to stack deploy also (other why it totally useless).

Or make Windows dockerd with LCOW enabled reporting it selves with multiple OS (linux and windows) so it would automatically choose correct platform.

A lot of moving parts, but running parallel architecture images would be great to solve. Windows 20H2 has supports for Hyper-V isolation, and Supports process isolation

I do not want the switch the Docker Desktop engine, run wsl2, and use the docker Linux context. From the Windows console, run hybrid docker-compose, Windows, and Linux context.

cc: @StefanScherer @thaJeztah @simonferquel @nebuk89

Is there any greater impetus to support this now, given that setting the platform is how you instruct Docker for Mac to emulate amd64? (See https://docs.docker.com/docker-for-mac/apple-silicon/#known-issues)

Otherwise, is there some other way we can emulate linux/amd64 on an M1 for a docker service?

@jmalloc Currently debugging the same, looking here suggests it may be in newer version?

https://github.com/docker/compose/pull/5985#issuecomment-683395676

edit: just realised thats docker-compose and not docker compose

I was able to install the most recent docker-compose by following instructions here which fixed this for my travis https://docs.docker.com/compose/install/

I tested today, and at least it works in version 3.7. (I am using Docker Compose version 1.29.2.) This page implies that it was added in 3.4, but I have not confirmed that.

It's officially documented here. At the top of the page, there's a note:

The latest and recommended version of the Compose file format is defined by the [Compose Specification (https://github.com/compose-spec/compose-spec/blob/master/spec.md). The Compose spec merges the legacy 2.x and 3.x versions, aggregating properties across these formats and is implemented by Compose 1.27.0+.

Is there any greater impetus to support this now, given that setting the platform is how you instruct Docker for Mac to emulate amd64? (See https://docs.docker.com/docker-for-mac/apple-silicon/#known-issues)

Otherwise, is there some other way we can emulate linux/amd64 on an M1 for a docker service?

Thats the same question I ask!