Compose functionality using familiar docker-compose syntax for container

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆

[mazdak]

Motivation

This branch started from a practical goal: run a real Docker Compose development stack on top of Apple's container tooling.

The immediate workload that drove the implementation was our main repo with contains a fairly normal, but above average complexity compose.yaml file, which relies on normal Compose features such as multi-service orchestration, depends_on, health checks, env_file, profile selection, bind mounts, named volumes, extra_hosts, and image build-or-reuse behavior.

container did not have a Compose-compatible plugin for that workflow, so bringing up a realistic stack required a new plugin layer that can translate Compose concepts into the existing container runtime model.

Scope

This PR adds a first-party container compose plugin that implements the Compose-style orchestration layer in Plugins/container-compose.

It is stacked on top of #1340 because Compose extra_hosts needs the core hosts plumbing introduced there, as well as #1341.

What this changes

• add the Plugins/container-compose package, plugin config, CLI entrypoints, and debug executable
• add compose parsing, file merging, include support, env interpolation, project conversion, orchestration, and package-local test coverage
• implement Compose extra_hosts, health checks, dependency ordering, project naming/path resolution, volume copy-up behavior, and image reuse in the plugin layer

[jglogan]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

[mazdak]

Hi @mazdak, thanks for the PR!

Please read the PR discussion for #239. It describes the approach you'll need to take to build out a compose plugin.

The other approach would be to create a standalone CLI plugin in a Github project that you host and create a signed installer that puts your plugin under the user-installed plugins directory at /usr/local/libexec/container-plugins.

Sounds good. I will take a crack at that.

[jglogan]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

[mazdak]

Sounds good. I will take a crack at that.

Cool! We here to help either way. If you want to try creating a standalone plugin, open up a discussion and drop a link to it here. We (maintainers at Apple) can't work directly on other repos but we should be able to answer questions in the discussion.

If you're looking at breaking this PR down into a minimally functional plugin as discussed over in the other PR, by all means continue here.

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

[jglogan]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

[mazdak]

I will say that this PR is 99.9% self contained. Everything Compose related is in its own directory, and tested. Only one change was made to Application to amend the compose cli to the list.

The other PR is more self-contained; it doesn't hardwire the command into Application.

Self-contained is not the same as "minimally functional". The justification for starting with a "minimally functional" PR and building with PRs for discrete features is over in the other compose PR discussion.

I have refactored this PR to use the plugin architecture

[Mcrich23]

Hey! So sorry, but in an effort to make plugin development more possible #603 and #635 have lead to the CLI folder being renamed to ContainerCommands and that will impact the merging of your pull request. Just an FYI, so you understand the issue when you are resolving conflicts.

Also, idk if you are using the existing commands at all for your implementation, but if you are #603 exposes all cli commands as structures for other targets, so you can use them without touching the shell environment.

[Mcrich23]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

[mazdak]

Quick question @mazdak, does this implementation support anonymous volumes?

Just trying to figure some things out...

Yes, with one important caveat.

What it supports:

• Short-form anonymous volumes like - /data
• Long-form anonymous volumes like:

 - type: volume
target: /cache

The caveat:

• They are not truly Docker-style random anonymous volumes.
• This implementation gives them deterministic generated names based on project + service + target
• So in practice they behave more like hidden auto-generated named volumes and will be reused for the same service/target across later up runs.
• They are cleaned up on down -v via the anonymous-volume label path

[mazdak]

This implementation has been modernized and work on real docker-compose payloads in our repository.

[jglogan]

Closing for now, as we're not considering compose for upstream at this time. Please develop this as an external plugin for now. If you have any questions regarding plugin development (we're still getting docs together) feel free to open a discussion topic!

[vxnkjyffmq-code]

Okay I approve

[vxnkjyffmq-code]

I apolog

[vxnkjyffmq-code]

🕺🏼🎆