Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpine Linux support #1781

Closed
penberg opened this issue Sep 21, 2022 · 5 comments · Fixed by #1827
Closed

Alpine Linux support #1781

penberg opened this issue Sep 21, 2022 · 5 comments · Fixed by #1827
Labels
enhancement New feature or request

Comments

@penberg
Copy link
Contributor

penberg commented Sep 21, 2022

Apline Linux is great for really small Docker images, but chiseld currently expects glibc to be present. That doesn't work on Alpine, which uses musl. Let's either make chiseld a fully static executable or build a musl variant for Alpine.

@penberg penberg added the enhancement New feature or request label Sep 21, 2022
penberg added a commit to penberg/chiselstrike that referenced this issue Sep 22, 2022
This adds Dockerfile generation to `create-chiselstrike-app`, which
allows developers to build an image of their application and its
dependencies, including ChiselStrike, to easily deploy to applications
to Kubernetes, Fly.io, and other services.

Please note that the Dockerfile only exports port 8080, which means that
there's no access to the ChiselStrike RPC from outside. We can re-visit
the decision once we have TLS support for gRPC:

chiselstrike#1782

Also note that the generated image is pretty big because we need to run
`npm install` to fetch dependencies, which requires Node to be present.
The `chisel apply` command also has a hard-coded dependency to `npx`.

Also, we're currently unable to use Alpine Linux, for example, as a
super-slim base image because of:

chiselstrike#1781
penberg added a commit to penberg/chiselstrike that referenced this issue Sep 22, 2022
This adds Dockerfile generation to `create-chiselstrike-app`, which
allows developers to build an image of their application and its
dependencies, including ChiselStrike, to easily deploy to applications
to Kubernetes, Fly.io, and other services.

Please note that the Dockerfile only exports port 8080, which means that
there's no access to the ChiselStrike RPC from outside. We can re-visit
the decision once we have TLS support for gRPC:

chiselstrike#1782

Also note that the generated image is pretty big because we need to run
`npm install` to fetch dependencies, which requires Node to be present.
The `chisel apply` command also has a hard-coded dependency to `npx`.

Also, we're currently unable to use Alpine Linux, for example, as a
super-slim base image because of:

chiselstrike#1781
penberg added a commit to penberg/chiselstrike that referenced this issue Sep 22, 2022
This adds Dockerfile generation to `create-chiselstrike-app`, which
allows developers to build an image of their application and its
dependencies, including ChiselStrike, to easily deploy to applications
to Kubernetes, Fly.io, and other services.

Please note that the Dockerfile only exports port 8080, which means that
there's no access to the ChiselStrike RPC from outside. We can re-visit
the decision once we have TLS support for gRPC:

chiselstrike#1782

Also note that the generated image is pretty big because we need to run
`npm install` to fetch dependencies, which requires Node to be present.
The `chisel apply` command also has a hard-coded dependency to `npx`.

Also, we're currently unable to use Alpine Linux, for example, as a
super-slim base image because of:

chiselstrike#1781
penberg added a commit to penberg/chiselstrike that referenced this issue Sep 22, 2022
This adds Dockerfile generation to `create-chiselstrike-app`, which
allows developers to build an image of their application and its
dependencies, including ChiselStrike, to easily deploy to applications
to Kubernetes, Fly.io, and other services.

Please note that the Dockerfile only exports port 8080, which means that
there's no access to the ChiselStrike RPC from outside. We can re-visit
the decision once we have TLS support for gRPC:

chiselstrike#1782

Also note that the generated image is pretty big because we need to run
`npm install` to fetch dependencies, which requires Node to be present.
The `chisel apply` command also has a hard-coded dependency to `npx`.

Also, we're currently unable to use Alpine Linux, for example, as a
super-slim base image because of:

chiselstrike#1781
mergify bot pushed a commit that referenced this issue Sep 22, 2022
This adds Dockerfile generation to `create-chiselstrike-app`, which
allows developers to build an image of their application and its
dependencies, including ChiselStrike, to easily deploy to applications
to Kubernetes, Fly.io, and other services.

Please note that the Dockerfile only exports port 8080, which means that
there's no access to the ChiselStrike RPC from outside. We can re-visit
the decision once we have TLS support for gRPC:

#1782

Also note that the generated image is pretty big because we need to run
`npm install` to fetch dependencies, which requires Node to be present.
The `chisel apply` command also has a hard-coded dependency to `npx`.

Also, we're currently unable to use Alpine Linux, for example, as a
super-slim base image because of:

#1781
@psarna
Copy link
Contributor

psarna commented Oct 4, 2022

@penberg I suppose you meant "or build a glibc variant for Alpine" in the description? In any case, the first suggestion about a static executable sounds better to me :)

@psarna
Copy link
Contributor

psarna commented Oct 4, 2022

I tried cargo build --release --target x86_64-unknown-linux-musl, but unfortunately it fails with

  cargo:rustc-link-lib=static=rusty_v8
  download lockfile: "/home/sarna/repo/chiselstrike/target/x86_64-unknown-linux-musl/release/build/lib_download.fslock"
  static lib URL: https://github.com/denoland/rusty_v8/releases/download/v0.51.0/librusty_v8_release_x86_64-unknown-linux-musl.a
  cargo:rustc-link-search=/home/sarna/repo/chiselstrike/target/x86_64-unknown-linux-musl/release/gn_out/obj
  Downloading https://github.com/denoland/rusty_v8/releases/download/v0.51.0/librusty_v8_release_x86_64-unknown-linux-musl.a
  Downloading https://github.com/denoland/rusty_v8/releases/download/v0.51.0/librusty_v8_release_x86_64-unknown-linux-musl.a...
  HTTP Error 404: Not Found
  Python downloader failed, trying with curl.

, because the build system wants to download this static library, but it's not prebuilt in the denoland/rusty_v8 repo

@psarna
Copy link
Contributor

psarna commented Oct 4, 2022

denoland/rusty_v8#49

@psarna
Copy link
Contributor

psarna commented Oct 4, 2022

@psarna
Copy link
Contributor

psarna commented Oct 4, 2022

@penberg I ended up building on top of frolvlad/alpine-glibc image. It looks random, but that's what deno uses for its slimmed down alpine image (looks like they really didn't want to pursue building a musl flavor :) ) - https://github.com/denoland/deno_docker/blob/3c0d76c1cd37fc30f667a7865c1f4c136f782a81/alpine.dockerfile#L16 .

glibc only weights ~5MiB in there, and still the resulting image is 468MiB, compared to 578 from node:18-slim. The difference isn't that vast compared to the original, because node_modules itself weighs 280MiB, and there's only so much we can do to minimize the overhead of the operating system. Still, I guess 102MiB is decent enough to justify a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants