I hope apple will deliver a docker compatible api soon, so that all the existing tools will just work.
cosmotic 6 hours ago [-]
Or Docker migrate to the new API, like they did with QEMU to Virtualization Framework.
daft_pink 11 hours ago [-]
Hoping that VSCode supports Apple Containers in a similar way to it supporting Docker Containers. I’ve tried Podman to use less resources on my Mac, but found that the developer tooling in things like VSCode makes Docker a bit sticky.
esseph 4 hours ago [-]
Looking at the ecosystem between docker and podman/oci, I hope the OCI tooling gets better.
I know docker is easier to dev on for many currently, it's also been around longer, but there is a widening gap between docker deployments in production and podman deployments in production and it isn't nearly as smooth or secure as either should be.
cedws 10 hours ago [-]
Is the container CLI actually intended for end users? My impression was that it's just a demo project showing off the Containerization API. I'm guessing that BuildKit will eventually support Apple's container runtime via the Containerization API.
yodon 14 hours ago [-]
Any thoughts or insights into why Apple didn't ship docker-compose support?
figmert 11 hours ago [-]
It took Podman a good 2 or so years to develop a good docker compatible http api. I presume that's why. There's no point in coming out with all of the features when they can release with some support, and add on top of it.
WhyNotHugo 10 hours ago [-]
Even today, some docker-compose features still don’t work with podman. There’s just an absurd amount of subtleties and edge cases, but pretty much all my usages hit one of these or another.
esseph 4 hours ago [-]
Biggest reason is that docker / podman/OCI are very different architectures and security models.
I hope there is something new. The tooling and deployment fragmentation is a nightmare.
From a security and open standards pov, we maybe should be moving to podman/OCI.
The docker tooling was often focused on the dev experience and it showed, but it wasn't a system with a good security model and this transition is a large part of that pain.
Noghartt 14 hours ago [-]
To be honest, I'm not sure why they didn't already release it supporting a compose-like tool. But my hypothesis is that considering they release a v0.1.0, they tried to be lean on their CLI and maybe they're building something on top of it.
elisiariocouto 12 hours ago [-]
Excellent work! Any reason why don’t implement this as a plugin for the container CLI?
Noghartt 11 hours ago [-]
Thanks!
> Any reason why don’t implement this as a plugin for the container CLI?
I did a different CLI because, considering that Apple released their v0.1.0, I'm not sure if they're working in some kind of official support for compose YAMLs.
With that in mind, I tried to avoid coupling it into the container CLI, to avoid injecting any kind of breaking change or something else which could cause any issue in the future.
develatio 12 hours ago [-]
How does networking between several “services” (containers) work?
Noghartt 11 hours ago [-]
The container opens a gateway and each container provides its own local IP (e.g. 192.168.64.2), from what I understood, every services known host machine and can communicate with each other.
On my current implementation, I didn't work with DNS/Network Resolution because I need to understand better what I can/can't do with the API Apple provides, so the only things it does is handling the port mapping using `socat`, as the docs recommends.
I know docker is easier to dev on for many currently, it's also been around longer, but there is a widening gap between docker deployments in production and podman deployments in production and it isn't nearly as smooth or secure as either should be.
I hope there is something new. The tooling and deployment fragmentation is a nightmare.
From a security and open standards pov, we maybe should be moving to podman/OCI.
The docker tooling was often focused on the dev experience and it showed, but it wasn't a system with a good security model and this transition is a large part of that pain.
> Any reason why don’t implement this as a plugin for the container CLI?
I did a different CLI because, considering that Apple released their v0.1.0, I'm not sure if they're working in some kind of official support for compose YAMLs.
With that in mind, I tried to avoid coupling it into the container CLI, to avoid injecting any kind of breaking change or something else which could cause any issue in the future.
On my current implementation, I didn't work with DNS/Network Resolution because I need to understand better what I can/can't do with the API Apple provides, so the only things it does is handling the port mapping using `socat`, as the docs recommends.