mag/applecontainercompose
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

new features

Browse Source
This commit is contained in:
Mark Gregory
2026-11-09 08:20:57 +00:00
parent ecfa74a35f
commit 965ae923c2
27 changed files with 1474 additions and 168 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+38 -77
View File
@@ -1,96 +1,57 @@
# AppleContainerCompose — Native Xcode project (developer preview)
# Container Compose 0.2.0
A SwiftUI macOS application and **native Swift** `accompose` CLI that operate Apple's `container` runtime. No Python, PyYAML, ServBay, Docker Desktop, or Docker daemon is needed. Both targets compile the same `ComposeCore.swift` orchestration implementation and use the Yams Swift package for YAML parsing.
One native macOS Xcode app combining the existing AppleContainerCompose orchestration engine and the supplied **ACDry Swift 1.1.0** monitor, with one **container-compose** CLI. Requires Apple silicon, macOS 26+, Xcode 26+ and Apple's `container` runtime. No Docker daemon, Go or Python is required to run it. Xcode fetches Yams for YAML parsing; Python 3 is used only by CLI tests.
## Requirements
## Build
- Apple silicon, macOS 26+, Xcode 26+
- Apple's [`container`](https://github.com/apple/container) CLI installed, with a configured kernel (`container system start`)
- Internet on first build to fetch the Yams Swift package
Open `ContainerCompose.xcodeproj`, choose **ContainerCompose**, and Run. The **Container Compose.app** product includes `container-compose` in Contents/MacOS. Choose **Save Command-Line Tool…** in the application menu to export it. Alternatively run `./Scripts/install-cli.sh` to build and install the CLI into `/opt/homebrew/bin`; override `PREFIX` if desired. The installer uses a fresh temporary build directory and preserves old accompose/acdry installations.
## Build and run GUI
The **Compose** tab opens existing compose.yaml/docker-compose.yml files and exposes Up, Down, Restart, Status, Logs, Pull, Build and runtime diagnostics. GUI Up is detached. The **Monitor & Resources** tab supplies the acdry dashboard, Containers, Images, Networks, Volumes and Projects. Opening YAML supplies its project name to monitoring. Resource lists remain runtime-wide unless the Projects filter applies. The executable selected in Settings is shared by both GUI engines. CLI discovery uses PATH and Homebrew fallback locations.
Open `AppleContainerCompose.xcodeproj`, select the `AppleContainerCompose` scheme and run. Use **Open YAML** to load `Examples/compose.yaml`, then Up / Down / Status / Logs. The GUI invokes the same native Swift engine as the CLI, not Python.
Monitor features retained: CPU/memory/network charts, six-minute in-memory history, measured receive/transmit rates, freshness indicators, searchable resource lists, inspect, polling logs with follow, stats, processes, verified lifecycle actions, explicit deletion/prune confirmations, mount references and inspect-only host mounts, keyboard shortcuts, and read-only demo mode. Disk read/write totals appear in container lists and Stats when the runtime provides them. Volume capacity is provisioned size, not occupied space. Process inspection needs `ps` inside the image. There is no fabricated live telemetry when metrics are absent.
## Install command line utility
From Terminal, in the project root:
```bash
./Scripts/install-cli.sh
accompose doctor
cd Examples
accompose up -d
accompose ps
accompose logs
accompose down
```
The installer builds the `accompose` Xcode scheme in Release and copies the binary to `/opt/homebrew/bin/accompose` (override `PREFIX=/your/prefix`). It asks for administrator permissions only if the destination directory is not writable. Add the prefix's `bin` directory to your PATH if needed.
## CLI usage
```
accompose init
accompose [-f compose.yaml] [-p project] config
accompose [-v|-vv|-vvv] up [-d|--detach] [--build]
accompose down [--volumes]
accompose ps
accompose pull
accompose build
accompose logs [service]
accompose start|stop|restart [service]
accompose exec SERVICE COMMAND [ARG ...]
accompose doctor
```
The default file discovery order is `compose.yaml`, `compose.yml`, `docker-compose.yaml`, `docker-compose.yml`. `.env` substitution, build contexts, Dockerfiles, service dependency ordering, environment variables, published ports, bind mounts, named volumes, and custom networks have initial support. Names are scoped by project.
## Limitations / important safety notes
This is an **early developer preview**, not a drop-in Docker Compose implementation. Only a subset of Compose YAML is parsed. Long-form mounts/ports, secrets, service health gating, robust reconciliation, profiles, scaling, live `logs -f`, restart supervision, and full network aliases are **not implemented**. A service with multiple networks only attaches to its first network; the CLI prints a warning. Restart policies are parsed but **not enforced**. `up` does not update an existing container when YAML changes: use `down` then `up`. `ps` currently lists all Apple containers, not just the project. Named volumes are not removed by `down` unless `--volumes` is provided. `down` may stop/remove project containers: check the project name before running it. The installer never automatically downloads or configures an unverified kernel.
Debug and Release builds of both Xcode targets and real Apple container runtime checks passed on macOS. See `Validation/VALIDATION.md` for the environment, checks and limitations.
## Updated developer preview: CLI rename and cleanup
The CLI target and installer are now named `accompose`. Re-run `./Scripts/install-cli.sh` after replacing your old project. The older `acccompose` executable is not automatically deleted. Verify using `accompose --help`.
Additional commands:
## CLI
```sh
accompose import ./docker-compose.yml # validate existing YAML without modifying it
accompose import ~/Projects/example # validate directory's default Compose file
accompose clean web --dry-run # preview deletion
accompose clean web # delete managed service container
accompose clean --all --dry-run # preview project container deletion
accompose clean --all # delete project containers
accompose prune --images # request runtime unused-image cleanup
container-compose --help
container-compose doctor
container-compose -f compose.yaml config
container-compose -vvv up -d # returns after startup
container-compose up # streams logs; Ctrl+C gracefully stops services
container-compose up --build -d
container-compose logs [SERVICE] # snapshot
container-compose start|stop|restart [SERVICE]
container-compose exec web sh # interactive terminal when invoked from a terminal
container-compose down # preserves named volumes
container-compose down --volumes
container-compose clean --all --dry-run
container-compose import ./docker-compose.yml
container-compose monitor --help
container-compose monitor watch
container-compose monitor --demo watch --json --count 2
container-compose monitor stats
container-compose monitor logs --follow CONTAINER
container-compose monitor volumes --all-mounts
container-compose monitor volume create -s 1G data
container-compose monitor projects
```
The sample `Examples/site/index.html` is included to prevent the original Nginx bind mount failure. Missing directory bind sources are created during `up`; do not use a missing *file* bind source because it will be created as a directory.
The monitor namespace retains acdry's CLI commands, including resource inspection, lifecycle, image/network/volume commands, live terminal monitoring and streaming logs. Its global options (`--container PATH`, `--project NAME`, `--demo`) precede its subcommand. Compose service commands and monitor container-ID commands are separate; use `monitor --help` for exact syntax. Resource prune in this namespace requires `--yes` and affects all unused resources of the chosen type.
### Compatibility limitations
`up -d`/`--detach` and verbosity `-v`/`-vv`/`-vvv` remain independent; options work before/after up. Foreground SIGINT/SIGTERM stops reached services in reverse dependency order and preserves containers. A log follower error is reported, and may leave containers running. Existing stopped containers are started; changed configuration requires down/up. Concurrent external runtime changes are not reconciled. Multiple foreground service logs share the terminal without prefixes.
This is **not** full Docker Compose support. Import validates only the subset of YAML handled by ComposeCore. Unrecognized service keys cause an explicit error rather than being silently ignored. Import does not yet persist projects to a GUI library, multi-file merging and YAML extension semantics are incomplete, and clean only deletes managed project containers (not host data, volumes, images or networks). Image pruning relies on the installed Apple `container` version supporting `container image prune`. The kernel and all host bind files are preserved. `--dry-run` is only supported for clean and prune. The detached/foreground lifecycle has been integration-tested on the runtime version recorded in `Validation/VALIDATION.md`.
## Compose compatibility and gaps
This is a developer preview with **partial Compose support**, not Docker Compose parity. Supported: YAML service images, Dockerfile build contexts/dockerfile/build args, short ports and volume mounts, environment list/mapping, `.env`/`${VAR}` interpolation, command, working_dir, dependency ordering and project-scoped names. Empty named-volume and custom-network declarations, plus explicit default local/bridge drivers, are supported. YAML anchors handled by Yams may work, but Compose extension/merge semantics are not implemented. Treat config as validation plus original YAML, not canonical expanded Docker Compose output.
## Foreground and detached mode fix
Unimplemented in this app: profiles, scaling, multi-file merge, include/extends, env_file, healthchecks and health/completion dependency gating, secrets/configs, deploy, watch/rebuild reconciliation, wait, one-off run, cp, events, publish/push, robust Docker shell parsing/interpolation, long port/mount syntax, network attachment options/aliases, external/custom resource names and driver/IPAM configuration. These require further implementation; they are not all Apple runtime limitations. Unknown service/root fields and several unsupported nested options are rejected before runtime changes. Restart policies only produce a warning and have no supervisor. Multiple service networks only attach the first, with a warning. `ps` lists the whole runtime. Compose `logs` is a snapshot; use `monitor logs --follow ID` for streaming outside foreground up.
- `accompose up` streams each service's logs live and stays attached until log followers finish or the command is interrupted.
- `accompose up -d` and `accompose up --detach` return after startup, leaving containers running.
- `-v`, `-vv` and `-vvv` change diagnostics only. They work before or after `up`, for example `accompose -vvv up -d` and `accompose up -d -vvv`.
- Ctrl+C (or SIGTERM) in foreground mode stops managed containers in reverse dependency order using the runtime's graceful `stop`; containers are preserved for subsequent `up`. Interrupted startup stops the containers reached so far.
- Existing stopped containers are restarted. Configuration changes still require `down` and `up`.
- The GUI's Up action retains its asynchronous, detached engine behavior.
- The runtime executable is resolved from PATH first, with Homebrew/system fallback paths.
Apple-runtime differences: this app uses Apple's CLI and per-container Linux VMs, not Docker Engine's API/socket; Docker-socket-dependent tools and Docker Swarm features are not provided. Runtime flags, networking/DNS, image architecture and storage behavior differ from Docker. Do not assume bare Compose service-name DNS works. See Apple's [command reference](https://github.com/apple/container/blob/main/docs/command-reference.md), [technical overview](https://github.com/apple/container/blob/main/docs/technical-overview.md) and [networking guide](https://github.com/apple/container/blob/main/docs/networking.md). Runtime-supported features still need explicit translation in this app.
Verbosity levels add mode/project details, Compose file location, then startup order. They do not change container execution mode. `logs` remains a snapshot command; foreground `up` uses independent live log followers. Multiple service logs share the terminal without added service prefixes.
Bind mounts can create a missing source as a directory; create file bind sources yourself first. Down/clean remove managed containers based on project/service names; verify project names before use. Down --volumes deletes project named-volume data. Host mount files are never deleted by cleanup. Build/install does not automatically start or configure the runtime/kernel.
To rerun the isolated regression suite (Python 3 is needed only for tests):
## Source provenance and validation
```sh
python3 Tests/cli_regression.py /absolute/path/to/built/accompose
```
Compose source: local AppleContainerCompose-Laravel-Fixed, matching the development checkout's ComposeCore. Monitor source: uploaded `ACDry-Swift-1.1.0.zip`, whose 14 source-package files matched the recovered local 1.1.0 release byte-for-byte before integration. The earlier acdry.zip contained an empty README and Git metadata only. Original projects and archives were preserved. The recovered monitor's MIT license is in ACDry-LICENSE. No upstream Dry Go code is included.
The suite substitutes a temporary fake runtime and never changes real containers.
See VALIDATION.md for results and reproduction. The Xcode project is the complete app/CLI build. Package.swift exposes only the monitor-core regression tests. The deliverable is source; local builds require your own signing/notarization for distribution.