Docker: provide image with a baseOS other than alpine

[dmfxyz]

Component

Other (please describe)

Describe the feature you would like

An additional docker image should be published with a baseOS such as debian or ubuntu. The Alpine image is good for small consistent builds, but providing an image with a more widely used OS would be helpful for more complicated docker use cases.

The image can also install solc either via inheriting the solc docker image or through more standard install channels, rather than the more complicated install required for using Alpine's musl.

Additional context

No response

[dmfxyz]

cc @sambacha and others -- any thoughts on debian v.s. ubuntu?

[sambacha]

Technically there is no reason why you couldn't just download the existing binary build and use that in the container image. You would have to add git but that would be it. The other thing possibly is ensuring same kernel as the underlying instance used to build the binary which is the github action container.

The multi stage container image can be additionally defined in a docker-bake.hcl file.

Alternative to this approach is leveraging docker in the current build process as opposed to the github action workflow of using a provided instance. This could be leveraged for the purposes of caching build incremental stages to be used across branches potentially

[sambacha]

Have posted an issue that addresses some issues with running anvil in a container environment https://github.com/foundry-rs/foundry/issues/2806

[dboreham]

I'm also interested in this due to wanting an ARM architecture image. I found that the Apline base image, or more accurately the glibc it uses doesn't build on aarm64.

[restlessronin]

I'm using a multi-stage build to include the foundry binaries in a node image (has to be alpine). I'm using the resulting image as a VS Code devcontainer.

within the devcontainer forge is unable to install any dependencies because "github.com" is not getting resolved. I know that alpine is supposed to have DNS resolution issues (it's one reason many of the projects I work on have moved to debian slim), and I'm wondering if that's what's going on here.

I would love to have an ubuntu/debian alternative for development. alpine is probably fine for production. I'm happy to work on the PR if it's something that's of interest.

[dboreham]

The comment above jogged my memory on this issue. In the meantime I created a Dockerfile for Ubuntu which we are using successfully. It has the nice side effect that aarm64 works.

https://github.com/dboreham/foundry/blob/cerc-release/Dockerfile-debian

[restlessronin]

The comment above jogged my memory on this issue. In the meantime I created a Dockerfile for Ubuntu which we are using successfully. It has the nice side effect that aarm64 works.

https://github.com/dboreham/foundry/blob/cerc-release/Dockerfile-debian

Thanks for the quick response. I had just started work on my own Debian dockerfile and this will save me time. Are you able to build this dockerfile on macos? I'm having trouble with that. The actual cargo build process is taking a looong time (> 40 minutes) on my MacAir M1, and it's not completing by virtue of getting (multiple) SIGKILL signal(s). Is there some timeout that might be causing this? To be fair, the debian dockerfile I was working on was having the exact same issue.

EDIT. I especially like how you use the rust image for the first stage of the build. seems like that's something the official dockerfile should use as well.

[dboreham]

Thanks for the quick response. I had just started work on my own Debian dockerfile and this will save me time. Are you able to build this dockerfile on macos?

I believe it does build on macos based on colleagues not complaining, but my mac is in another location so I can't check rn. I am generally building on Linux. One thing that might be relevant is that I don't get along with the newfangled buildkit docker build mechanism, so I have it globally disabled. That might explain the difference.

We build the image with this script: https://github.com/cerc-io/stack-orchestrator/blob/main/app/data/container-build/cerc-foundry/build.sh

And some environment variables (including DOCKER_BUILDKIT=0) defined here: https://github.com/cerc-io/stack-orchestrator/blob/main/app/build_containers.py#L93

The equivalent bare docker command should look something like:

$ DOCKER_BUILDKIT=0 docker build -t myorg/foundry:test -f ~/my_project/foundry/Dockerfile-debian ./foundry 

[restlessronin]

I tried building the image on the mac without success. tried both with and without buildkit. I'm getting this error message

error: could not compile `chisel`

Caused by:
  process didn't exit successfully: `rustc --crate-name chisel --edition=2021 chisel/src/bin/chisel.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=s -C panic=abort -C lto=fat -C codegen-units=1 -C debuginfo=0 -C metadata=658c69e56c8aab7f -C extra-filename=-658c69e56c8aab7f --out-dir /opt/foundry/target/release/deps -C strip=symbols -L dependency=/opt/foundry/target/release/deps --extern bytes=/opt/foundry/target/release/deps/libbytes-869a7e814bcd8a56.rlib --extern chisel=/opt/foundry/target/release/deps/libchisel-449e9bc336a9ea56.rlib --extern clap=/opt/foundry/target/release/deps/libclap-06bc9c63832084cd.rlib --extern dirs=/opt/foundry/target/release/deps/libdirs-1ed11cfbd75b6525.rlib --extern ethers=/opt/foundry/target/release/deps/libethers-a6720983bc43e76f.rlib --extern ethers_solc=/opt/foundry/target/release/deps/libethers_solc-85b023c2b09db0e4.rlib --extern eyre=/opt/foundry/target/release/deps/libeyre-4b95cdfcca21da03.rlib --extern forge=/opt/foundry/target/release/deps/libforge-2334b267d445e747.rlib --extern forge_fmt=/opt/foundry/target/release/deps/libforge_fmt-95d8f5082c14fbe9.rlib --extern foundry_cli=/opt/foundry/target/release/deps/libfoundry_cli-8cd2ec41e5c3e508.rlib --extern foundry_common=/opt/foundry/target/release/deps/libfoundry_common-6a72742d0921fa66.rlib --extern foundry_config=/opt/foundry/target/release/deps/libfoundry_config-1c7715c4d255562a.rlib --extern foundry_evm=/opt/foundry/target/release/deps/libfoundry_evm-707da9e6497fccf1.rlib --extern regex=/opt/foundry/target/release/deps/libregex-12987167d57b7417.rlib --extern reqwest=/opt/foundry/target/release/deps/libreqwest-843e521918a31ae5.rlib --extern revm=/opt/foundry/target/release/deps/librevm-1a45a8a38264ea6e.rlib --extern rustyline=/opt/foundry/target/release/deps/librustyline-f9c27fdc2222faf3.rlib --extern semver=/opt/foundry/target/release/deps/libsemver-6cb7a215443a1609.rlib --extern serde=/opt/foundry/target/release/deps/libserde-01a40712e066ccde.rlib --extern serde_json=/opt/foundry/target/release/deps/libserde_json-7b20c297a369cf1a.rlib --extern solang_parser=/opt/foundry/target/release/deps/libsolang_parser-3e7ac28671f99851.rlib --extern strum=/opt/foundry/target/release/deps/libstrum-fcd0ca9a2ff710b2.rlib --extern time=/opt/foundry/target/release/deps/libtime-6f69082fe90bd259.rlib --extern tokio=/opt/foundry/target/release/deps/libtokio-c632dbf509de05f1.rlib --extern yansi=/opt/foundry/target/release/deps/libyansi-8566a9302a7fd272.rlib -L native=/opt/foundry/target/release/build/ring-7578e67c233d9ce7/out -L native=/opt/foundry/target/release/build/hidapi-rusb-b0137340eb0996d7/out -L native=/opt/foundry/target/release/build/libusb1-sys-420c35fad0324e67/out -L native=/opt/foundry/target/release/build/secp256k1-sys-ff70be01f7d15f46/out` (signal: 9, SIGKILL: kill)
warning: build failed, waiting for other jobs to finish...

and similar messages for compilation of foundry-cli.

I'm unsure if this is MacOs related. I'll see if I can try building on a linux box and see how far that goes.

[dboreham]

Ohhh...actually this rings a bell now. The problem isn't related to macos, rather it's due to Rust being a resource pig. You should find that if you increase the memory allocated to the Docker Linux VM (or run on a bigger machine), then the problem will go away. We had to publish a pre-built image for low-end mac users for this exact reason. It's here if anyone needs it: https://git.vdb.to/cerc-io/-/packages/container/foundry/latest

[restlessronin]

I'm trying to use the pre-built image you linked, but it's a "linux/amd64" image. I'm getting QEMU errors on my M1 when I try to run forge from the image.

[dboreham]

I can push an aarm64 image.

[restlessronin]

Thanks. I wound up building a multi-arch image on a hosted container, it's on docker hub at https://hub.docker.com/r/restlessronin/foundry.

It seems to work fine as part of a multi-stage dockerfile used as a VS Code devcontainer. Also works on M1.