Cache writing and permissions in a Lambda Docker container

[soundstep]

Version: Deno 1.45.2

I'm applying this guide: https://docs.deno.com/runtime/tutorials/aws_lambda/

I've got some permissions issue in the container. I can see what kind of problem this is, but what would be an elegant way of solving? A chmod? Using DENO_DIR?

The AWS Lambda log:

�[0m�[32mDownload�[0m https://registry.npmjs.org/@octokit/webhooks-methods/-/webhooks-methods-5.1.0.tgz
�[0m�[32mDownload�[0m https://registry.npmjs.org/@octokit/openapi-webhooks-types/-/openapi-webhooks-types-8.3.0.tgz
�[0m�[32mDownload�[0m https://registry.npmjs.org/@octokit/openapi-types/-/openapi-types-22.2.0.tgz
�[0m�[32mDownload�[0m https://registry.npmjs.org/@octokit/endpoint/-/endpoint-10.1.1.tgz
�[0m�[1m�[31merror�[0m: JSR package manifest for '@hono/hono' failed to load. Read-only file system (os error 30) (for '/home/sbx_user1051/.cache/deno/deps/https/jsr.io')
Check the permission of the directory.
at �[0m�[36mfile:///var/task/lib/fe-core-merge-queue-project/server/middleware.ts�[0m:�[0m�[33m2�[0m:�[0m�[33m31�[0m
EXTENSION	Name: lambda-adapter	State: Ready	Events: []
INIT_REPORT Init Duration: 2155.65 ms	Phase: invoke	Status: error	Error Type: Runtime.ExitError
START RequestId: 5768476b-cd75-437c-9563-6cbfb9ae2fc4 Version: $LATEST
RequestId: 5768476b-cd75-437c-9563-6cbfb9ae2fc4 Error: Runtime exited with error: exit status 1
Runtime.ExitError
END RequestId: 5768476b-cd75-437c-9563-6cbfb9ae2fc4
REPORT RequestId: 5768476b-cd75-437c-9563-6cbfb9ae2fc4	Duration: 2196.08 ms	Billed Duration: 2197 ms	Memory Size: 128 MB	Max Memory Used: 18 MB

Dockerfile:

# Set up the base image
FROM public.ecr.aws/awsguru/aws-lambda-adapter:0.8.4 AS aws-lambda-adapter
FROM denoland/deno:bin-1.45.2 AS deno_bin
FROM debian:bookworm-20230703-slim AS deno_runtime
COPY --from=aws-lambda-adapter /lambda-adapter /opt/extensions/lambda-adapter
COPY --from=deno_bin /deno /usr/local/bin/deno
ENV PORT=8000
EXPOSE 8000

# Copy the function code
WORKDIR "/var/task"
COPY . /var/task

# Warmup caches
RUN timeout 10s deno run -A main.ts || [ $? -eq 124 ] || exit 1

CMD ["deno", "run", "-A", "main.ts"]

[lucacasonato]

@soundstep Can you try add a RUN deno cache main.ts right after the # Warmup caches comment? It is possible that warming up this script (with downloading of dependencies), takes more than 10 seconds.

We can adjust that in the guide if that is the case.

[soundstep]

@lucacasonato

This gave me the exact same error:

# Warmup caches
RUN timeout 10s deno run -A main.ts || [ $? -eq 124 ] || exit 1
RUN deno cache main.ts

This seem to have fixed it:

# Warmup caches
ENV DENO_DIR=$HOME/.cache/deno
RUN timeout 10s deno run -A main.ts || [ $? -eq 124 ] || exit 1
RUN deno cache main.ts

I guess deno just couldn't write in /home/sbx_user1051/.cache/deno.

Does that fix make sense?

Side question: Does RUN deno cache main.ts work because it runs for the first time? It doesn't do anything locally unless I do deno cache -r main.ts.

[lucacasonato]

Ah yes, that makes sense. DENO_DIR is computed relative to the user's home directory. If the build user and the runtime user are different, the DENO DIR will be different. I am updating the docs to recommend specifying a DENO_DIR explicitly: denoland/docs#850.

deno cache ... does not look like it does anything after the first time, because the files will already be cached. It only prints out new files it is downloading. deno cache -r forcibly re-downloads all files, so that is why you are seeing output for that.

[soundstep]

Great, thanks for the additional info!

[soundstep]

@lucacasonato FYI, side note: maxday/lambda-perf#1492

[festusyuma]

Hello @lucacasonato Please why is the timout added. couldn't find an explanation anywhere cos my first call to the function took 10 seconds and I would like to eliminate that. Thank you

[soundstep]

@festusyuma Good question for the reason why there is a timeout.
If that helps, as far as I can see the timeout happens at build time, not run time.

Side question @lucacasonato: I just noticed that a docker run -it needs an --init to be able to Ctrl+C the container (based on that image). Is that normal?

[festusyuma]

@soundstep Yeah, on further deployment, it seemed to have a normal cold start time, just wondering why 10 seconds was chosen and if there are factors that could change this like number of dependencies or internet speed. would be really helpful to know why

@lucacasonato if you have any info or link to this

[festusyuma]

@soundstep @lucacasonato Just confirmed the time is dependent on both of those things, as it tries to download more packages when running the container but after increasing the time to 20 seconds, it works fine,

it initially worked fine when I had no external dependencies, this is something I feel should be documented as it looks like 10 is a standard just from reading the docs

[soundstep]

@festusyuma Not sure @lucacasonato gets the notifications by the way as the ticket is closed. It might be worth creating a discussion instead.

[festusyuma]

@lucacasonato Oh wow, Thanks