This issue tracks work on adding automatic multi-arch support to Swarm mode. In other words, for services that run images with fat manifests, tasks will be scheduled on only those nodes which can actually run the image.

What does this give us?

The ability to automatically schedule service tasks on nodes that are capable of running them, without having to do do it manually.

How to do it?

The proposed way of achieving this works in two steps:

1. The daemon looks at the manifest of the service image. If it is a fat manifest, the platform information is pulled out and passed to the Swarm manager.
2. The manager uses a platform filter to filter out nodes that cannot support a given image.

A proposal SwarmKit PR to implement the second step is here: moby/swarmkit#1981

Here's a little more detail about the specifics:

• service create -- the daemon pulls manifest at the time it pulls image digest. If this is a fat manifest, then platform information is extracted and passed on to the Swarm manager. If there is no platform information to pass, the Swarm manager does not enable the platform filter
  • A pertinent question is whether we will allow the user to pass platform information in the future.
• service update -- this is a little more involved, because we don't want to unnecessarily poll the registry to get the manifest.
• In cases where the --image is not supplied with service update, we don't need to do anything, because we just assume that the image and all its platform-related requirements stay the same.
• If the user does update the image, and it is required to reach the registry to obtain the digest, then we also get platform information, since we're reaching the registry anyway.
• The interesting case is when the digest is provided (say by the user). Right now, we will not contact the registry in such a situation. For platform information, we do know at the manager level whether the digest of the new service spec is different from the existing one. If it isn't different, we don't need to do anything. If there is a change, then we want to contact the registry to get platform information. The only difference is that before, the user could update the service by providing a new digest, and skip the registry lookup, whereas now it would entail the registry lookup.

What will it cost?

The only cost is an addition registry round-trip during service create and sometimes during service update. While in my tests, this cost has been minimal, it is something to be aware of.