Add platform and other properties to service.build

[chris-crone]

Build platforms

With the arrival of Arm on developer laptops and in data centers, developers are being pushed into a multi architecture world. Compose services have a platform property of type string which is used to determine what the pulled or built image's platform should be.

This works for local development or deployment as users only need a single architecture at a time. When publishing images to a container registry, users may want to build and push the images for multiple platforms.

Question:
Should the build section have a platform property of type list of strings? If so, how does this relate to the service platform?

Proposal:
Add a platform string list property to build that is respected only when pushing images, doing an implicit build if needed. This will allow developers to have a quick development cycle (only using one architecture) but allow them to publish their images with multi architecture support.

Other properties

Investigating further, there may be other build properties that we would like to add. The current set of build properties are:

"context": {"type": "string"},
"dockerfile": {"type": "string"},
"args": {"$ref": "#/definitions/list_or_dict"},
"labels": {"$ref": "#/definitions/list_or_dict"},
"cache_from": {"$ref": "#/definitions/list_of_strings"},
"network": {"type": "string"},
"target": {"type": "string"},
"shm_size": {"type": ["integer", "string"]},
"extra_hosts": {"$ref": "#/definitions/list_or_dict"},
"isolation": {"type": "string"}

Docker buildx includes the following interesting flags that are currently not exposed in the Compose format:

      --allow strings            Allow extra privileged entitlement, e.g. network.host, security.insecure
      --builder string           Override the configured builder instance
      --cache-from stringArray   External cache sources (eg. user/app:cache, type=local,src=path/to/dir)
      --cache-to stringArray     Cache export destinations (eg. user/app:cache, type=local,dest=path/to/dir)
      --load                     Shorthand for --output=type=docker
      --no-cache                 Do not use cache when building the image
  -o, --output stringArray       Output destination (format: type=local,dest=path)
      --platform stringArray     Set target platform for build
      --secret stringArray       Secret file to expose to the build: id=mysecret,src=/local/secret
      --ssh stringArray          SSH agent socket or keys to expose to the build (format: default|<id>[=<socket>|<key>[,<key>]])

Question:
Should we add any of these properties?

Proposal:
There are some options taht would make sense to add now. Specifically:

• cache-to: Logical given that we have cache-from already.
• no-cache: Logical given the ability to specify a cache.
• platform: As described above.
• secret: It's a common issue that people do not have an easy way to attach secrets in a way that they are not built into the image.

Some require more consideration as they're either very Docker specific or might be too niche:

• allow
• builder
• load
• output
• ssh

[EricHripko]

Relevant issue from the community (talking about secrets): #81. The conversation about secrets is probably best had there.

[EricHripko]

I am not convinced that there's a need for a dedicated build.platform attribute given that there's already a service.platform attribute available. Especially since the latter is defined as:

on which platform the service’s build will be performed.

The only remaining use case (I can think of) is building multi-platform images via docker-compose build. However, this doesn't seem like something that is a typical part of a developer inner loop. I imagine if you're building/testing images on multiple architectures, you'd probably want to template via variable expansion (e.g., platform: $ARCH)

[chris-crone]

Yes, you're right about service.platform for the inner loop, not sure how I missed that.

Give that the only other case is on push, maybe a --platform flag for build or push is sufficient.

[jkeiser]

network was added to build in docker/compose#4997, as well. I found it on Stack Overflow :)

[EricHripko]

Hi @jkeiser, thank you for chipping in 👍 I believe network is included under build in the spec already (see https://github.com/compose-spec/compose-spec/blob/master/schema/compose-spec.json#L91).

[thaJeztah]

Somewhat related; I've been meaning to write up something on an idea I had; I had some notes on my computer, so decided to just post them "as-is" in #188

[AkihiroSuda]

PR:

• build: add platforms #267