feat: use alpine as base image #1106
Conversation
Pull Request Test Coverage Report for Build 12852443457Details
💛 - Coveralls |
|
As can be noticed from the ci runs, alpine is equally suitable base image for parseable |
Signed-off-by: Devdutt Shenoi <[email protected]>
Signed-off-by: Devdutt Shenoi <[email protected]>
WalkthroughThis pull request updates the Dockerfile by switching both the build and final stage base images to Alpine-based images. The builder stage now uses Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant BS as Builder Stage (Alpine Rust)
participant FS as Final Stage (Scratch)
Dev->>BS: Initiate Docker build
BS->>BS: Install dependencies (apk add build-base, git, bash)
BS->>FS: Copy static binary to final image
FS->>FS: Execute application (ENTRYPOINT)
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Dockerfile (1)
37-38: Switch Final Stage to Alpine Minimal Runtime
Changing the final stage base image toalpine:latesteffectively minimizes the runtime image. However, ensure that the binary copied from the builder stage is either statically linked or fully compatible with Alpine’s musl libc, as incompatibilities may lead to runtime issues.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
Dockerfile(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: Build Default x86_64-pc-windows-msvc
- GitHub Check: Build Default aarch64-apple-darwin
- GitHub Check: Build Kafka aarch64-apple-darwin
- GitHub Check: Build Default x86_64-apple-darwin
- GitHub Check: Build Kafka x86_64-unknown-linux-gnu
- GitHub Check: Quest Smoke and Load Tests for Standalone deployments
- GitHub Check: Build Default aarch64-unknown-linux-gnu
- GitHub Check: Quest Smoke and Load Tests for Distributed deployments
- GitHub Check: Build Default x86_64-unknown-linux-gnu
- GitHub Check: coverage
🔇 Additional comments (2)
Dockerfile (2)
17-17: Adopt Alpine-based Rust Builder Image
Switching the builder stage to userust:1.84.0-alpinehelps significantly reduce image size. Please verify that all Rust crates and native dependencies compile correctly in the Alpine environment, as Alpine’s musl libc can sometimes have subtle differences compared to Debian-based images.
24-25: Install Build Dependencies with apk
The addition of the commandRUN apk add --no-cache build-base git bashensures that necessary build tools are available in the Alpine image. This is a correct approach for Alpine-based builds; just double-check that these packages cover all your build requirements.
|
Should consider using APKO |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
Dockerfile (1)
17-17: Ensure Static Linking forscratchFinal StageThe builder stage now uses the Alpine-based image (
rust:1.84.0-alpine), which is excellent for reducing image size. However, since the final stage usesscratch, please confirm that the Rust release build produces a fully statically linked binary. If not already ensured, consider using appropriate linker flags or setting the target tox86_64-unknown-linux-muslto guarantee compatibility with ascratchbase image.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
Dockerfile(2 hunks)Dockerfile.debug(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: Build Default x86_64-pc-windows-msvc
- GitHub Check: Build Default aarch64-apple-darwin
- GitHub Check: Build Default x86_64-apple-darwin
- GitHub Check: Build Default aarch64-unknown-linux-gnu
- GitHub Check: Build Kafka aarch64-apple-darwin
- GitHub Check: Quest Smoke and Load Tests for Standalone deployments
- GitHub Check: Build Default x86_64-unknown-linux-gnu
- GitHub Check: Quest Smoke and Load Tests for Distributed deployments
- GitHub Check: Build Kafka x86_64-unknown-linux-gnu
- GitHub Check: coverage
🔇 Additional comments (13)
Dockerfile (4)
24-26: Dependency Installation via apkInstalling the build dependencies (
build-base,git, andbash) withapk add --no-cacheis clear and concise. Ensure these packages cover all requirements needed during the build stage.
38-38: Adopting a Minimal Final StageSwitching the final stage base image to
scratchsignificantly minimizes the runtime image size. This is a great move for production deployments. Just be sure that the static linking concern (as mentioned above) is verified so the binary runs correctly.
43-43: Binary Copy and Path ConsistencyThe binary is copied from the builder’s release output using the command:
COPY --from=builder /parseable/target/release/parseable /parseableand the ENTRYPOINT is set to
["/parseable"]. Please verify that this location is intentional and that the file has appropriate permissions to execute in thescratchenvironment.
45-45: ENTRYPOINT ConfigurationUsing
ENTRYPOINTto run the application ensures that the container starts with your binary directly. Additionally, confirm that your binary handles signals appropriately (e.g., SIGTERM) for graceful shutdowns.Dockerfile.debug (9)
17-17: Using Alpine for the Debug BuildSwitching the builder stage to
rust:1.84.0-alpineprovides consistency with the production build. In the debug context, this change is acceptable since static linking is less of a concern for debug binaries.
24-26: Consistent Dependency InstallationThe debug Dockerfile also installs
build-base,git, andbashwith apk. This consistency helps maintain the same build environment across all builds.
31-31: Efficient Dependency CachingUsing a temporary
src/main.rswith a dummymainfunction to cache dependencies is an efficient approach. Just ensure that there’s no leftover artifact from this caching step that might interfere with the subsequent debug build.
34-35: Debug Binary Build ProcessCopying the actual
srcdirectory and runningcargo buildbuilds the debug version of the binary. This approach is standard for non-optimized (debug) builds.
38-38: Final Stage: Alpine Base for DebuggingUsing
FROM alpine:latestin the final stage for the debug build is a smart choice. It provides a lightweight environment with essential utilities, which aids in troubleshooting compared to thescratchimage used in production.
40-40: Installation of Debug UtilitiesInstalling
curlusingapk add --no-cache curlis useful for debugging and potential log ingestion tests. This helps ensure you have a minimal toolset for runtime investigations.
42-42: Working Directory ConfigurationSetting the working directory to
/parseablealigns the context for running the application and matches the subsequent file copy location.
45-45: Verify Debug Binary Placement and PermissionsThe command:
COPY --from=builder /parseable/target/debug/parseable /usr/bin/parseableplaces the debug binary in
/usr/bin/parseable. Ensure this location is intentional and that the binary has the right execution permissions within the Alpine environment.
47-47: CMD for Debug ExecutionUsing
CMD ["/usr/bin/parseable"]is appropriate for launching the debug binary in the final image. This configuration supports straightforward container execution for debugging purposes.
Fixes #XXXX.
Description
This is just a proposal, the alpine image is only ~40MB smaller on disk
This PR has:
Summary by CodeRabbit