[feat] Add Apple container support (opt-in)

[manojmahapatra]

Describe the feature

The archive plugin currently hard-codes the Docker CLI (docker pull/run) to build lambda zips. Apple container supports container image pull and container run, so we can add an opt-in tool switch without changing defaults.

Use Case

Apple’s container CLI already supports pulling and running OCI images, so the archive plugin should allow opt‑in use of container to build the Amazon Linux artifacts in the same way Docker does.

Proposed Solution

Add a tool selector to the packager:

• CLI flag: --container-tool docker|container
• Env var: LAMBDA_CONTAINER_TOOL=container

Default remains docker.

Map commands based on tool:

• Docker

  • docker pull <image>
  • docker run --rm -v … -w … <image> bash -cl "<cmd>"

• Apple container

  • container image pull <image>
  • container run --rm -v … -w … <image> bash -cl "<cmd>"

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

[sebsto]

This is something I was thinking about since Apple released container.
I was planning to add it to the new plugin. But given this will take weeks to lands, maybe we can move forward and add it to the current plugin.

Question:

• about naming: --container-tool or --container-cli ? or other ?
• Should we also consider tools like finch ? Is there a generic way to add future tools ?

Suggestion:

• None of the plugin options are controlled by env variable. Is this really necessary ?

I will update the new plugin spec doc.

[sebsto]

See d9aebab

[manojmahapatra]

I was planning to add it to #567. But given this will take weeks to lands, maybe we can move forward and add it to the current plugin.

That's good to know there was a previous attempt was done.

Re questions;

1. I think --container-cli sounds explicit when selecting the command-line tool, and also feels clearer. We can stick w/ it.
2. Re finch or podman, I was thinking to keep the current scope to docker, container and then make it extensible by adding more in the future. Let me know what do you think.
3. Re env var, don't think we need it now. I bounced that idea only if there is use-case in future.

[manojmahapatra]

Question: while looking at Package.swift and specifically on SwiftPM permissions, since PluginNetworkPermissionScope only includes docker (no container/OCI), we still have to require users to pass --allow-network-connections docker even when --container-cli container is used. Are we ok with that, or have I misunderstood how the permission scope works?

[sebsto]

That’s a question I have too.
Let’s wait for the code to include container and see how --allow-network-connections docker behaves in that case.

Worst case, using Apple container will require to entirely bypass the sandbox, like we did in the early days. That will be an occasion to ask the SPM team to add support for Apple container permissions.

[sebsto]

About the breakdown above. Let’s go with 1/ now. We’ll consider 2/ and 3/ in a follow unreleased if there is customer demand for it.

[manojmahapatra]

Let’s go with 1/ now

Sounds good, let me work on it and put together a draft PR.

[sebsto]

I just made a simple test and hardcoded the use of container in the plugin.
Apple's container uses XPC to communicate with its daemon.

We can't use --allow-network-connection unixSocketDaemon to bypass the sandbox.

LAMBDA_USE_LOCAL_DEPS=../.. swift package archive --allow-network-connections unixDomainSocket  -v
Plugin ‘AWSLambdaPackager’ wants permission to allow unix domain socket connections.
Stated reason: “This plugin uses Apple Container to create the AWS Lambda ZIP package.”.
Allow this plugin to allow unix domain socket connections? (yes/no) yes
-------------------------------------------------------------------------
building "hellojson" in docker
-------------------------------------------------------------------------
updating "swift:amazonlinux2" docker image
  Error: interrup
  ted: "interrupted: "XPC connection error: Connection invalid"
Ensure container system service has been started with `container system start`."
error: /usr/local/bin/container image pull swift:amazonlinux2 failed with code 1

Disabling the whole sandbox works (--disable-sandbox)

➜  HelloJSON git:(main) ✗ LAMBDA_USE_LOCAL_DEPS=../.. swift package archive --disable-sandbox  -v                           
Plugin ‘AWSLambdaPackager’ wants permission to allow docker unix domain socket connections.
Stated reason: “This plugin uses Docker to create the AWS Lambda ZIP package.”.
Allow this plugin to allow docker unix domain socket connections? (yes/no) yes
Plugin ‘AWSLambdaPackager’ wants permission to allow unix domain socket connections.
Stated reason: “This plugin uses Apple Container to create the AWS Lambda ZIP package.”.
Allow this plugin to allow unix domain socket connections? (yes/no) yes
-------------------------------------------------------------------------
building "hellojson" in docker
-------------------------------------------------------------------------
updating "swift:amazonlinux2" docker image
building "HelloJSON"
  [0/1] Planning build
  Building for production...
  [0/2] Write swift-version-24593BA9C3E375BF.txt
  [2/3] Compiling AWSLambdaRuntime Context+Foundation.swift
  Build of product 'HelloJSON' complete! (4.01s)
-------------------------------------------------------------------------
archiving "HelloJSON"
-------------------------------------------------------------------------
1 archive created
  * HelloJSON at /Users/sst/Documents/code/swift/lambda/swift-aws-lambda-runtime/Examples/HelloJSON/.build/plugins/AWSLambdaPackager/outputs/AWSLambdaPackager/HelloJSON/HelloJSON.zip

[sebsto]

FYI, it was a quick hardcoded test with minimum changes

➜  HelloJSON git:(main) ✗ git diff 
diff --git a/Package.swift b/Package.swift
index 770799c..b346430 100644
--- a/Package.swift
+++ b/Package.swift
@@ -62,12 +62,6 @@ let package = Package(
                     description:
                         "Archive the Lambda binary and prepare it for uploading to AWS. Requires docker on macOS or non Amazonlinux 2 distributions."
                 ),
-                permissions: [
-                    .allowNetworkConnections(
-                        scope: .docker,
-                        reason: "This plugin uses Docker to create the AWS Lambda ZIP package."
-                    )
-                ]
             )
         ),
         .testTarget(
diff --git a/Plugins/AWSLambdaPackager/Plugin.swift b/Plugins/AWSLambdaPackager/Plugin.swift
index 9c9258a..12b0b9e 100644
--- a/Plugins/AWSLambdaPackager/Plugin.swift
+++ b/Plugins/AWSLambdaPackager/Plugin.swift
@@ -90,7 +90,7 @@ struct AWSLambdaPackager: CommandPlugin {
         buildConfiguration: PackageManager.BuildConfiguration,
         verboseLogging: Bool
     ) throws -> [LambdaProduct: URL] {
-        let dockerToolPath = try toolsProvider("docker")
+        let dockerToolPath = try toolsProvider("container")
 
         print("-------------------------------------------------------------------------")
         print("building \"\(packageIdentity)\" in docker")
@@ -101,7 +101,7 @@ struct AWSLambdaPackager: CommandPlugin {
             print("updating \"\(baseImage)\" docker image")
             try Utils.execute(
                 executable: dockerToolPath,
-                arguments: ["pull", baseImage],
+                arguments: ["image", "pull", baseImage],
                 logLevel: verboseLogging ? .debug : .output
             )
         }

[manojmahapatra]

Yeah, I’m seeing the same. Maybe, we can proceed with --container-cli, but we should note that Apple container currently requires --disable-sandbox until SPM adds proper permissions. Let me know what you think.

[sebsto]

I think it’s the way to go. This is non blocking as long as we document it properly.

[manojmahapatra]

@sebsto I accidentally closed the issue. We could keep it open until Apple's fix lands in, and I would fix the docs.