-
Notifications
You must be signed in to change notification settings - Fork 0
Adding production-like Docker environment for Slax #17
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
Draft
Kavignon
wants to merge
3
commits into
main
Choose a base branch
from
improvements/add-docker-container-prod-setup
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The docker container for production is being built in 3 stages. The Node build installs the dependencies set in app/assets , copies what's in the assets folder and runs esbuild to bundle + minify static files. The Elixir build stage installs Hex and Rebar, fetches + compiles dependencies for production, copies compiled assets from the Node build stage and runs The Distroless runtime stage copies the compiled production binaries in the Elixir stage into a minimal Distroless image (very lean Unix runtime to reduce attack opportunities), sets the working directory to /app and starts the Phoenix server.
Contributor
Author
|
I'm running into issues due to esbuild. I thought it could be my Docker setup on my machine but even trying to get a little ahead of deploying to Fly, I'm still having issues |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's being done
We continue the work established earlier for containerizing Slax for development and production.
Docker environment for Slax in development
In a previous PR (#16), we added a Docker development environment that allows Slax (a Phoenix/LiveView application) to run in Docker during development This involved:
Docker environment for Slax in production
Building on that, this PR introduces a multi-stage Docker build tailored for production Unlike the development container—which bundles all dev dependencies and results in a larger footprint—this approach produces a much smaller, more secure final image. While I'm not a security specialist, I want to minimize the attack surface and streamline the production build.
Multi-stage build
As mentioned above, the primary goals are to reduce the container's footprint and ensure minimal attack surface (within reason). A multi-stage Docker build lets you split the build process into separate phases in a single Dockerfile. Each stage focuses on a different part of your application's build lifecycle (e.g., asset compilation, release building, final runtime), and you only copy forward what's necessary for the next stage.
1. Node/Assets stage
When running Slax in production, we don’t need Node.js or other dev tools present—just the compiled (and minified) static assets. By isolating this step, we keep Node-related dependencies out of the final image, reducing size and potential vulnerabilities.
So here is what's happening during this build stage:
assets/.priv/static.2. Elixir build stage
Next, we build the actual Elixir/Phoenix release:
mix deps.get --only prod && mix deps.compile)mix phx.digestto cache-bust and fingerprint static assets3. Distroless Runtime Stage
Why a distroless runtime?
Distroless images (by Google) include the bare minimum required to run an application—essentially just the language runtime and no shell. When Slax is compiled for production, we no longer need to preserve the compiler, ore package manager, or shell. We can copy the final compiled release from the previous stage.
What happens during this stage?
Because the final container only includes the compiled release and a minimal runtime, it’s significantly smaller and more secure than a single-stage image that carries all the build tools and dependencies.