Differences in available pseudo-filesystem access between Lambda and docker-lambda

[sangaline]

Docker-lambda does a great job of replicating the files that are available on Lambda, but the Docker containers expose pseudo-filesystems like /dev/, /proc/, and /sys in a more complete way than AWS Lambda. It's not uncommon for software to depend on access to these, and execution can fail in very ambiguous ways when this happens. One example of this is that, up until recently, the IPC code in Chromium relied on /dev/shm which isn't available in the Lambda environment. A Lambda function using Chromium would have worked in docker-lambda and failed on AWS Lambda due to this difference.

I've been trying to more accurately reproduce the environment by creating a chroot, and then only mounting the portions of the pseudo-filesystems that are accessible on Lambda. I'm curious to hear if you have any thoughts on this topic, or if you think that there might be a way to integrate a solution into docker-lambda.

[mhart]

I'm not exactly sure how you'd integrate a solution given that this project is specifically intended for a docker environment? The only thing I can think of is suggesting certain docker run arguments, like --ipc=none or --shm-size=1b or something?

[sangaline]

I think that adding a few notes in the README about arguments that help replicate the environment would be awesome. There are also some capabilities that are enabled by default by Docker, but which aren't available on Lambda. That would be another area where suggested command-line options would be extremely helpful.

Beyond that, what about potentially adding a command to the build environments which creates a realistic chroot, copies /var/task/ over, and then invokes a lambda function? I can totally understand not wanting to mess with the standard containers, but adding a script to the build containers probably wouldn't be too disruptive.

[mhart]

I mean, I'm all for anything that more closely replicates the environment. I don't really have time to mess around with every docker setting though, so PRs are welcome.

[damolp]

--ipc="none" mimics the AWS lambda environment

I'm trying to get Firefox working in Lambda with a Shared Memory library shim so having the environment as close as possible to lambda is critical for me.

[mhart]

You can try adding the following too. It won't exactly replicate the functionality, but it should surface errors in similar ways:

docker run ...
  -v /dev/null:/dev/fd/dummy \
  -v /dev/null:/dev/shm \
  -v /dev/null:/dev/mqueue \
  -v /dev/null:/dev/core \
  -v /dev/null:/dev/tty \
  ...
``