A pilot issue of my new mid-of-the-month newsletter.
Typically, Docker is used for building container images and/or running containerized programs. However, it can easily be (ab)used as a generic build tool. Let me show you a few examples how it can come in handy.
These days I use Rust only occasionally. In particular, it means there is often no configured development environment around. So, whenever there is a new PR in one of my Rust projects, here is what I do:
$ git clone https://github.com/iximiuz/reapme.git
$ cd reapme
$ docker run -v $(pwd):/app -w /app rust:1 cargo run --bin subreaper
The above docker run command starts a temporary build environment where I can validate the changes quickly. Alternatively, if the build artifacts need to be used outside of the builder container, the command can be adjusted as follows:
$ docker run -v $(pwd):/app -w /app rust:1 cargo build --release
$ file target/release/subreaper
target/release/subreaper: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV)...
Obviously, this trick works not only for Rust. Java and Go are two other great candidates, and the technique can be extended beyond compiling tiny programs. For instance, you can minify a bunch of CSS files without spoiling your system with any Node.js tools. As someone who's been advocating for disposable and isolated development environments, I find it very appealing.
The downside, of course, is the time needed for a new container to pull in and compile all the dependencies. So, if your use case is slightly less ephemeral, you should probably think of setting up a proper dev environment.
Since version 18.09 (released in ~2019), Docker relies on BuildKit for building container images. However, BuildKit isn't limited to building images. It defines itself as a toolkit for converting source code to build [arbitrary] artifacts in an efficient, expressive, and repeatable manner.
October 15th 2022
|
With the docker buildx build command, changing the type of the build artifact becomes as simple as providing the --output flag:
By describing your build procedure in a Dockerfile, you immediately start benefiting from efficient (and potentially remote) caching, isolated build environments, out-of-the-box cross-platform builds, and more. And the build results don't need to be container images! It'll also work for producing normal local files.
Read more about the BuildKit superpowers in this highly practical article by Batuhan Apaydın.
It's a common practice to invoke docker build commands from a Makefile. GNU make can run independent recipes in parallel, but unlike BuildKit, it's not a container-native build system. If the build targets were described in a format that BuildKit understands, it could handle multiple concurrent build requests much more efficiently than make by de-duplicating the build steps, using more advanced caching, remote build instances, etc, etc.
And that's how the new docker buildx bake command was born.
You can think of bake as an HCL-based container-aware make:
# docker-bake.hcl
group "default" {
Ā Ā targets = ["db", "webapp-dev"]
}
target "webapp-dev" {
Ā Ā dockerfile = "Dockerfile.webapp"
Ā Ā tags = ["docker.io/username/webapp:latest"]
}
target "webapp-release" {
Ā Ā inherits = ["webapp-dev"]
Ā Ā platforms = ["linux/amd64", "linux/arm64"]
}
target "db" {
Ā Ā dockerfile = "Dockerfile.db"
Ā Ā tags = ["docker.io/username/db"]
}
Combining bake with the --output trick gives you an efficient, highly concurrent, and isolated (from the host system) build tool. Go give it a try!
Look ma', no Dockerfile!
October 16th 2022
|
ā
Have a productive week ahead!
Ivan
Building labs.iximiuz.com - a place to help you learn Containers and Kubernetes the fun way š
Hello š It's this time of the month again! My traditional roundup of all things Linux, Containers, Kubernetes, and Server Side, delivered straight into your inbox š¬ What I was working on October was very productive for me - I shipped no major iximiuz Labs features (it's always hard to resist the temptation!) and instead dedicated all my available time to content work. The main focus was on Container Images. It's the subject of the first module of my "panoramic" Docker course, and it is almost...
Hey there, Iāve just finished putting together everything I know about Node.js container images and figured you might find the write-up useful. If youāre working with Node.js in Docker, chances are youāve been hit by the dilemma of which base image to use. Do you go for the default node:latest, the slimmer node:22-slim, or something super minimal like a distroless image? What about Bitnamiās alternative ā how does it stack up? Before you jump headfirst into your next build, you might want to...
Hello š Ivan's here with a slightly delayed September roundup of all things Linux, Containers, Kubernetes, and Server Side š§ What I was working on This month, I worked on an assorted set of topics. Skill Paths First off, the skill paths! I finally finished the underlying machinery, and now iximiuz Labs supports a new type of content - short roadmaps that you can use to develop or improve a specific skill: how to debug distroless containers, how to copy images from one repository to another,...