Support for running via a docker image?

[tom-sherman]

Could this be supported out of the box?

Looks like there's been some teething problems getting it to work here: #20 (comment)

[frafra]

This is what I am using:

FROM node:18

RUN apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -qy tini libc++1

WORKDIR /app
RUN npm install workerd
COPY config.capnp hello.js ./

CMD ["tini", "./node_modules/.bin/workerd", "serve", "config.capnp"]

[tom-sherman]

I have the following Dockerfile but I get an error, running on M1 MacOS:

FROM node:18

RUN apt-get update && apt-get -y install libc++-dev libunwind-dev

WORKDIR /app
RUN npm install workerd
COPY workerd.capnp worker.js health-check.js ./

CMD ["./node_modules/.bin/workerd", "serve", "workerd.capnp"]

/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory
node:child_process:910
    throw err;
    ^

Error: Command failed: /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd serve workerd.capnp
    at checkExecSyncError (node:child_process:871:11)
    at Object.execFileSync (node:child_process:907:15)
    at Object.<anonymous> (/app/node_modules/workerd/bin/workerd:134:26)
    at Module._compile (node:internal/modules/cjs/loader:1119:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1173:10)
    at Module.load (node:internal/modules/cjs/loader:997:32)
    at Module._load (node:internal/modules/cjs/loader:838:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:18:47 {
  status: 127,
  signal: null,
  output: [ null, null, null ],
  pid: 14,
  stdout: null,
  stderr: null
}

Node.js v18.9.1

Any ideas?

[frafra]

You removed libc++1 and added two unnecessary -dev libraries. This is why it fails. libc++1 install libunwind as requirement.

[tom-sherman]

@frafra I tried that, same error:

FROM node:18

RUN apt-get update && apt-get -y install libc++1 libunwind8

WORKDIR /app
RUN npm install workerd
COPY workerd.capnp worker.js health-check.js ./

CMD ["./node_modules/.bin/workerd", "serve", "workerd.capnp"]

[frafra]

This is an error with your modified version of your Dockerfile. Please stick with the suggested packages. There is no need to install libunwind explicitly, since it is a dependency of libc++1. You are specifying a version of libunwind which is not the one required by libc++1 currently. Look at the Debian packages webpage for more information.

I followed the Getting Started section of this repository and made a new one, with the suggested hello world example and a simple Dockefile, which works flawlessly. I would suggest you start there: https://github.com/frafra/workerd-docker

[tom-sherman]

I haven't written out everything I've tried, all of the changes to dockerfiles would probably blow through the character limit on a GitHub comment.

I have of course tried your dockerfile with no luck. Anything I try throws back the error while loading shared libraries: libunwind.so.1: cannot open shared object file: No such file or directory error.

[frafra]

You said to use M1. That could explain why you are having different results. Have you just tried to build the Dockerfile within the repository I linked? Do you get the very same error even when using that repository and the hello world files?

libunwind8 does not provide libunwind.so.1. libunwind is a requirement of libc++ only staring from Debian Bookworm (v12, current testing), but node:18 uses Debian Buster (v11, current stable). The package is named libunwind-14 in Debian Sid and libunwind-13 in Debian Buster: https://packages.debian.org/search?suite=bullseye&section=all&arch=any&searchon=contents&keywords=libunwind.so.1.

Could it be that libunwind.so.1 is a (indirect) dependency of workerd only on M1? Try to add libunwind-13.

[frafra]

I made a branch with the additional dependency: https://github.com/frafra/workerd-docker/tree/fix-missing-libunwind

[tom-sherman]

Ah, adding libunwind-13 gives me a different error:

/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)
/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)
/app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd: /lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /app/node_modules/@cloudflare/workerd-linux-arm64/bin/workerd)

[Cyb3r-Jak3]

I have a basic docker image for amd64 here: https://github.com/Cyb3r-Jak3/docker-workerd. Smaller than installing it via npm. Arm64 support is on the way.
Also, happy to merge it into this repo.

[kentonv]

Zooming out a bit, a broader problem here may be that our binary has too many dependencies on shared libraries that lack stable ABIs across distros. We should try to statically link more of these, at least in our npm releases.

When it comes to glibc specifically, though, we do need to dynamically link. Fortunately glibc has strong ABI compatibility. However, we need to make sure to link against an older version of glibc, since generally a binary will only work with the version it was linked against and newer versions, but not older ones.

cc @penalosa

[frafra]

Ah, adding libunwind-13 gives me a different error:

Have you installed it together with libc++1?
workerd in my container is a static binary, so I wonder what the result of ldd is on your container running on M1, giving the different requirements.

[kentonv]

workerd in my container is a static binary

Hmm are you sure? I don't think any of our binaries are static.