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.
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.
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.
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.
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.
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.
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.
> 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.
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 hope apple will deliver a docker compatible api soon, so that all the existing tools will just work.
Or Docker migrate to the new API, like they did with QEMU to Virtualization Framework.
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.
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.
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.
Any thoughts or insights into why Apple didn't ship docker-compose support?
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.
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.
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.
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.
I have opened a pull request with an extraordinary important change for you.
Excellent work! Any reason why don’t implement this as a plugin for the container CLI?
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.
How does networking between several “services” (containers) work?
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.