feat: Add ContainerBackend with Docker and Podman

[Fiona-Waters]

What this PR does / why we need it:

This PR introduces a unified ContainerBackend that automatically detects and uses either Docker or Podman for local training execution. This replaces the previous separate LocalDockerBackend and LocalPodmanBackend implementations with a single, cleaner abstraction. You can see the Docker and Podman implementations in separate commits.

This implementation tries Docker first, then falls back to Podman if Docker is unavailable. This can be overridden via ContainerBackendConfig.runtime to force a specific runtime ("docker" or "podman"). An error is raised if neither runtime is available.
Unit tests for the backend implementation have also been added. Examples for using Docker and Podman will be added to the Trainer repo later.

Manually testing on Mac I had to specify the container_host like so:
Docker via Colima container_host=f"unix://{os.path.expanduser('~')}/.colima/default/docker.sock"
Podman Desktop container_host=f"unix://{os.path.expanduser('~')}/.local/share/containers/podman/machine/podman.sock"

Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):

Fixes ##114 and #108

Checklist:
I need to look at adding docs. A README has been included.

• Docs included if any changes are user facing

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign electronic-waste for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andreyvelich]

Thank you for this @Fiona-Waters!
As we discussed here: #111 (comment), can we consolidate Podman and Docker under single container backend ?
Given that those backend should have similar APIs, I think it would be better to consolidate them, similar to KFP: https://www.kubeflow.org/docs/components/pipelines/user-guides/core-functions/execute-kfp-pipelines-locally/#runner-dockerrunner

[Fiona-Waters]

Thank you for this @Fiona-Waters! As we discussed here: #111 (comment), can we consolidate Podman and Docker under single container backend ? Given that those backend should have similar APIs, I think it would be better to consolidate them, similar to KFP: https://www.kubeflow.org/docs/components/pipelines/user-guides/core-functions/execute-kfp-pipelines-locally/#runner-dockerrunner

Thanks @andreyvelich I will look at updating the implementation.

[Fiona-Waters]

@andreyvelich @astefanutti regarding comments on this PR and #111 this is what I propose:

We have 3 backends:

• Kubernetes
• Subprocess
• Local Container

For the Local Container backend we automatically try Docker first, then Podman and then fallback to Subprocess if neither runtime is available. We use the adapter pattern with a container client adapter unified interface, and docker and podman specific calls are implemented in separate adapter classes.
There could also be an option where users can force a specific runtime for example:
LocalContainerBackendConfig(runtime="docker")
This implementation will make it easy to add support for other container runtimes in the future, if thats a possibility.
Please let me know what you think. Thanks!
cc @briangallagher

[andreyvelich]

Sure, that looks great @Fiona-Waters!

fallback to Subprocess if neither runtime is available

Why do we need to fallback to subprocess ?
I would imagine we have 3 backend support, and user decide what they want to use:

KubernetesBackend()
ContainerBackend()
LocalProcessBackend()

In the ContainerBackend users can select:

 ContainerBackend(
  ContainerBackendConfig(container_runtime="docker")
)
or
 ContainerBackend(
  ContainerBackendConfig(container_runtime="podman")
)

[astefanutti]

@Fiona-Waters that sounds to me. I agree the fallback logic may really apply to choose the default container runtime.

Other than that, I'd be inclined to drop the "Local" prefix entirely. Even Kubernetes could run local with KinD, and I doubt the SDK will ever do remote process.

[Fiona-Waters]

Sure, that looks great @Fiona-Waters!

fallback to Subprocess if neither runtime is available

Why do we need to fallback to subprocess ? I would imagine we have 3 backend support, and user decide what they want to use:

KubernetesBackend()
ContainerBackend()
LocalProcessBackend()

In the ContainerBackend users can select:

 ContainerBackend(
  ContainerBackendConfig(container_runtime="docker")
)
or
 ContainerBackend(
  ContainerBackendConfig(container_runtime="podman")
)

Understood. Let me see what I can do. Thank you for the swift reply!

[Fiona-Waters]

@Fiona-Waters that sounds to me. I agree the fallback logic may really apply to choose the default container runtime.

Other than that, I'd be inclined to drop the "Local" prefix entirely. Even Kubernetes could run local with KinD, and I doubt the SDK will ever do remote process.

Ok cool. Let me see what I can do. Thank you!

[Fiona-Waters]

@andreyvelich @astefanutti @briangallagher
I've updated the PR. Please take a look. Thanks