Skip to content

perf: improve Dockerfile caching #1053

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Apr 30, 2024
Merged

perf: improve Dockerfile caching #1053

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 21 additions & 3 deletions Dockerfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,19 +33,37 @@ RUN apt-get update && apt-get install -y cmake protobuf-compiler
# Install protobuf for elixir
RUN mix escript.install --force hex protobuf

# Download openapi spec
COPY Makefile .oapi_version /consensus/
RUN make download-beacon-node-oapi

# Install rust
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y

ENV PATH="${PATH}:/root/.cargo/bin:/root/.mix/escripts"

# Precompile rust crates. Rustler stores targets under _build
COPY ./native /consensus/native
RUN cd /consensus/native/bls_nif && cargo build --release \
--target-dir="/consensus/_build/prod/lib/lambda_ethereum_consensus/native/bls_nif"
Copy link
Collaborator

@mpaulucci mpaulucci Apr 29, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think technically we should do mix release at the end and then this path would change. Wonder if we have another way the doesn't involver hardcoding this path.

I've been doing a small poc of doing mix release and then executing the binary directly instead of iex but the problem is that it doesn't recognize the cli for a reason.

This is what chatGPT said on the matter xD.

Direct CLI Arguments with start
The ./bin/app start command for a release typically does not support passing custom CLI arguments directly to the application's code because it starts the application in the background without an attached shell. This mode is meant for production where direct terminal interaction is not common. Instead, configurations are often managed through environment variables or external configuration files, as previously mentioned.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also tried that and apparently, only env vars reach the depths of the runtime.exs script.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird..

RUN cd /consensus/native/kzg_nif && cargo build --release \
--target-dir="/consensus/_build/prod/lib/lambda_ethereum_consensus/native/kzg_nif"
RUN cd /consensus/native/snappy_nif && cargo build --release \
--target-dir="/consensus/_build/prod/lib/lambda_ethereum_consensus/native/snappy_nif"
RUN cd /consensus/native/ssz_nif && cargo build --release \
--target-dir="/consensus/_build/prod/lib/lambda_ethereum_consensus/native/ssz_nif"

# Precompile elixir dependencies
COPY mix.exs mix.lock .fork_version ./
COPY ./config/config.exs /consensus/config/config.exs
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't know this file is read when compiling dependencies, but it makes sense

RUN mix deps.get
RUN mix deps.compile

COPY . .
COPY --from=libp2p_builder /libp2p_port/libp2p_port /consensus/priv/native/libp2p_port

RUN protoc --elixir_out=./lib proto/libp2p.proto

RUN make download-beacon-node-oapi

RUN mix deps.get
RUN mix compile

ENTRYPOINT [ "iex", "-S", "mix", "run", "--"]