Track Apple container runtime support gaps

[danegsta]

Summary

Track remaining gaps for supporting Apple container as a DCP container runtime, measured against the capabilities DCP currently uses from Docker and Podman.

Blocking gaps

• Tar/archive-based copy into containers

  • [Request]: cp command tar stream support apple/container#1908
  • Apple container cp is path-based only.
  • It does not accept -/stdin tar streams.
  • It does not expand tar archives into the container filesystem.
  • Copy-in appears to require the container to be running.
  • DCP impact: blocks CreateFiles, which streams generated tar contents into a created container before start.

• Network aliases

  • [Request]: Add network-scoped aliases for container network attachments apple/container#1839
  • Apple --network supports network name plus options like mac and mtu, but not Docker/Podman-equivalent aliases.
  • DCP impact: blocks Docker/Podman-style service discovery if DCP network aliases are required.

• Container-to-container DNS parity

  • [Request]: First-class container-to-container DNS discovery on custom networks apple/container#1809
  • Apple has container DNS lookup support, but it appears oriented around container hostnames/IDs/FQDNs rather than arbitrary network aliases.
  • DCP impact: limits service discovery unless DCP can avoid alias-based names for this runtime.

Gaps requiring workarounds or degraded functionality

• Runtime events/watch support

  • [Request]: Add container events stream apple/container#484
  • No Docker/Podman-style events command or equivalent watch API was identified.
  • DCP impact: container/network watches would require polling or another Apple-specific strategy.

• Stable host callback name

  • [Request]: Support for adding host network apple/container#673
  • No obvious equivalent to Docker host.docker.internal or Podman host.containers.internal was identified.
  • DCP impact: may affect ContainerHost() and host callback/proxy paths that need a stable host name from inside containers.

• Pull policy semantics during create/run

  • Apple fetch behavior appears to use a local image if present and pull if missing.
  • No clear equivalent to Docker/Podman --pull=always, --pull=never, or --pull=missing on create/run was identified.
  • DCP impact: may affect PullPolicyAlways / PullPolicyNever semantics.

• Inspect/status fidelity

  • [Request]: Surface lastExitCode on ContainerSnapshot apple/container#1501
  • Apple status appears coarser than Docker/Podman, e.g. unknown, stopped, running, stopping.
  • DCP impact: may limit reporting or controller behavior that depends on created/exited/dead states, exit code, finished time, health, or error details.

• Log timestamps

  • [Request]: Add container log retrieval options apple/container#1591
  • container logs supports basic log retrieval/following, but no timestamp option was identified.
  • DCP impact: StreamContainerLogsOptions.Timestamps may not be implementable exactly.

Honorable mentions

• Forced volume removal

  • Apple volume delete rejects in-use volumes and no force option was identified.
  • DCP impact: mostly affects order of operations. This should be fine if DCP removes containers before volumes, but it remains a parity difference for RemoveVolumesOptions.Force.

• Build image ID file output

  • Apple build does not appear to have a Docker/Podman --iidfile equivalent.
  • DCP impact: likely none today. BuildImageOptions.IidFile still exists and Docker/Podman still support it, but current DCP build callers do not appear to set it.

• Healthcheck configuration/status

  • [Request]: Container healthcheck support — configuration, runtime observer, API, and CLI apple/container#1918
  • No Docker/Podman-style healthcheck configuration or health status equivalent was identified.

[hansmbakker]

Hopefully apple/container#1918 helps regarding the healthchecks feature gap.

[danegsta]

Hopefully apple/container#1918 helps regarding the healthchecks feature gap.

Added it to the list.