Extend sugar compatibility with apple's container runtime in macos

[sanjay7178]

As apple released container runtime for m series silicon based chips and it is lacking with container compose (similar to docker compose ) feature . so as of now apple developer community still discussing on it . so here's the main idea bridging the gap of container compose (container runtime ) with sugar and we could integrate existing docker compose file's to work on mac.

Todo's :

• : extend container runtime with file including container.py in path src/sugar/extensions
• : cli should be sought of sugar container -f .sugar.yaml <commands>
• : make a translation layer to manage/orchestrate macos container with sugar

Relevant info :

• reddit discussion : https://www.reddit.com/r/selfhosted/comments/1l7ozmb/apple_now_supports_linux_containers_on_macos_26/
• compose support discussion: compose support? apple/container#194
• documentation : https://apple.github.io/container/documentation/

[sanjay7178]

@xmnlab lmk if the issue is still relevant and if any changes needed to edit this issue . it's quite helpful to community.

[sanjay7178]

also I had another proposal as container runtime is way different from containerd and docker runtime . kubernetes still lacking of it to run native k8s cluster's on macOS . we could make a poc first and pioneer it to happen .

some research :

• firecracker is a microVM for running containers on a light weight environment . so community around made possible to run k8s cluster's on these microVM's (kubefire)
• k8s supported runtime's : https://kubernetes.io/docs/setup/production-environment/container-runtimes/

[xmnlab]

Hi @sanjay7178 !

I think that it is a very good idea and we should move that forward.

That is a plan that I have in mind for that:

• create a dummy interface (let's call it for now apple-container-cli-dummy) that simulate all CLI input and output ... python would be the easiet way to start with
• use a compose-like app or create a new to use it with apple container
• create the extension inside sugar for that.

the idea of using apple-container-cli-dummy is to be able to test it locally in a linux machine or inside any ci .. for that we just need to receive arguments and return outputs for that .. maybe we could have a json file as a internal data store to keep the states ... maybe additionally we could have a clean command to reset this json file.

Let me know if that makes sense.

[sanjay7178]

Thanks for acknowledgement, github actions might equip with macos arm64 so no worries running on CI . But for the development apple container strictly support to M series macOS hardware .

Hi @sanjay7178 !

I think that it is a very good idea and we should move that forward.

That is a plan that I have in mind for that:

• create a dummy interface (let's call it for now apple-container-cli-dummy) that simulate all CLI input and output ... python would be the easiet way to start with
• use a compose-like app or create a new to use it with apple container
• create the extension inside sugar for that.

the idea of using apple-container-cli-dummy is to be able to test it locally in a linux machine or inside any ci .. for that we just need to receive arguments and return outputs for that .. maybe we could have a json file as a internal data store to keep the states ... maybe additionally we could have a clean command to reset this json file.

Let me know if that makes sense.

[sanjay7178]

GitHub actions supports macos runner https://docs.github.com/en/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories

[xmnlab]

hi @sanjay7178 but AFAIK it doesn't have the proper configuration for using apple container. but if you want you can check that ... it needs two things:

• macos 26+
• Virtualization.framework enabled

[sanjay7178]

macOS sequoia is enough to test container cli , apple uses test and build workflow in their GitHub actions ( https://github.com/apple/container/blob/dd6bdc20cfa16a04fc675ea7c9a6bfe620af534c/.github/workflows/common.yml#L68 ) , i believe smoke tests would work

hi @sanjay7178 but AFAIK it doesn't have the proper configuration for using apple container. but if you want you can check that ... it needs two things:

• macos 26+
• Virtualization.framework enabled

[xmnlab]

awesome! glad that we can test it on ci
but yet to test it locally in a linux machine we would still need to have a simulated app