Use containerd.sock instead of docker.sock

Feature Requests
1

Hello team,

I am currently attempting to integrate LocalStack within an EKS cluster. I’ve managed to make it function by utilizing the Helm chart or manually deploying it through the creation of necessary manifest files.

The cluster runs on AWS, specifically an AWS-managed node group with version 1.27 that utilizes containerd as its container runtime instead of Docker. While LocalStack starts without any issues, attempting to create a Lambda function results in an error logged in LocalStack:

“2023-11-28T23:38:01.328 ERROR — [rvice-task_0] l.services.lambda_.hints : Failed to pull Docker image because Docker is not available in the LocalStack container but required to run Lambda functions. Please add the Docker volume mount “/var/run/docker.sock:/var/run/docker.sock” to your LocalStack startup. Link to documentation”

Is it feasible to adapt LocalStack to operate using containerd?

Thank you in advance.

2

Hi @cflmarques, thank you for raising this issue. Support for LocalStack on Kubernetes is a priority for us at the moment, as is an overhaul of our container abstraction layer. We are keen to hear more use cases like yours to help ensure that we implement the functionality that our users want.

If you are a Pro customer, LocalStack lambda functions can either run using Docker or natively with Kubernetes. If this is the case, then you can set LAMBDA_RUNTIME_EXECUTOR=kubernetes to cause Lambda to execute your code in Kubernetes pods rather than Docker containers.

We are in the process of improving the story when using LocalStack with non-docker container runtimes (including podman and containerd) and will take this suggestion on board, thank you!

3

Hi Simon,

Thank you for your response.

I’ve successfully managed to get LocalStack working in eks in DIND mode. In this setup, in this mode, localstack is running completely isolated from the host runtime. As these instances are short-lived, any issues that might arise while running in DIND mode are not critical.

When using LocalStack within Kubernetes, our main objective is to enable access from other pods. For example, while one container may create a Lambda function, another container should be able to utilize it.

In the open-source version, the Lambda endpoints generated are limited to localhost:

http://<XXXXXXXX>.lambda-url.us-east-1.localhost.localstack.cloud:4566

Is there a feature available in the pro version that enables the creation of endpoints accessible from other pods?

4

There are a few options available to you here:

  1. if you set your pod DNS server to the LocalStack pod then that name will resolve to the LS pod
  2. you can set LOCALSTACK_HOST to the name of the LocalStack service from the helm chart, then the localhost.localstack.cloud part of the domain will be replaced by whatever you set in LOCALSTACK_HOST