I've created a command line interface (CLI) tool designed to handle container validation, replacing the usual shell scripts often found in Dockerfiles. This pattern might look familiar:
RUN command -v myapp || (echo "myapp missing"; exit 1)
RUN [ -n "$MODEL_PATH" ] || (echo "MODEL_PATH not set"; exit 1)
These kinds of validations kept appearing in my Dockerfiles, so I built a tool to streamline things. Instead of those lengthy commands, you can use my tool like this:
COPY --from=ghcr.io/vertti/preflight:latest /preflight /usr/local/bin/preflight
RUN preflight cmd myapp --min 2.0
RUN preflight env MODEL_PATH --match '^/models/'
RUN preflight file /usr/local/bin/inference --executable
I've also added support for runtime health checks, such as:
HEALTHCHECK CMD preflight http http://localhost:8080/health
CMD ["sh", "-c", "preflight tcp postgres:5432 --retry 10 && ./app"]
**Why did I decide to create this rather than just using shell scripts?**
* I want consistent error messages that clearly indicate what the problem is.
* It works in lightweight setups, like FROM scratch or distroless, which don't need bash or coreutils.
* It's a single binary with no dependencies.
* It replaces solutions like wait-for-it.sh, dockerize, and curl health checks.
The tool checks commands, environment variables, files, TCP/HTTP endpoints, checksums, git state, and system resources. I'd love your thoughts! What validation do you implement in your Dockerfiles that you think I missed?
5 Answers
I think it’s fair to say that while you might not win over everyone, you’ve cleaned up commands to be more readable which is a plus. It's a matter of preference, but if the image size increase is minimal, I can see how some people might find it useful to streamline their Dockerfile checks.
You should have validated this concept before going all-in on development. Most developers hesitate to add another dependency just for a tool that wraps commands we already know how to use. Shell handles missing variables well already. Plus, Docker's own HEALTHCHECK could accomplish what you're aiming for without additional layers.
I think adding validation inside the container can just add unnecessary bloat. Instead of making each Dockerfile more complex with these RUN commands, I’d recommend keeping it straightforward and wrapping it with a testing framework that manages these conditions externally.
It seems like you're reinventing the entrypoint script concept. While it's good to make checks, these validations could easily clutter the Dockerfile. Instead, it's more common to handle this logic in the entrypoint for runtime checks.
I’ve done the deep multi-stage builds too, and I get why you’d want validations. They help catch issues during the refactoring process. With a well-structured tool, you can make those checks feel more like unit tests which could be beneficial for developers.
Related Questions
XML Signature Verifier
Voltage Divider Calculator
SSL Certificate Decoder
SQL Formatter
Online Font Playground to Test Google or Custom Fonts
File Hash Generator Online – Get Instant MD5 and SHA-256 Hashes