tug streamlines Docker pipelines.
Spend less time managing buildx images. Enjoy more time developing your core application.
$ cd example
$ tug -t mcandre/tug-demo
$ tug -ls mcandre/tug-demo
Platform: linux/386
Platform: linux/amd64
Platform: linux/amd64/v2
...
$ tug -t mcandre/tug-demo -load linux/amd64
$ docker run --rm mcandre/tug-demo cat /banner
Hello World!buildx is hard. tug is easy.
When Docker introduced the buildx subsystem, their goals included making buildx operationally successful. But not necessarily as straightforward, consistent, and intuitive as single-platform docker commands. (Assuming that you consider Docker straightforward, consistent, and intuitive, ha.) We have run extensive drills on what buildx has to offer, and wrapped this into a neat little package called tug.
We are not replacing buildx, we just provide a proven workflow for high level buildx operation. We hope tug helps you to jumpstart multi-platform projects and even learn some fundamental buildx commands along the way.
You can see more Docker gears turning, apply the tug -debug flag. tug respects your time, but also rewards curiosity.
https://godoc.org/github.com/mcandre/tug
https://github.com/mcandre/tug/releases
$ go install github.com/mcandre/tug/cmd/tug@latestBSD-2-Clause
- Docker 20.10.12+
- Docker First Aid Kit
- Apply
DOCKER_DEFAULT_PLATFORM=linux/amd64environment variable
Regardless of target application environment, we encourage an amd64 compatible build environment. This tends to improve build reliability.
In time, we may revisit this recommendation. For now, an amd64 compatible host affords better chances for successful cross-compilation than trying, for example, to build mips64 targets from s390x hosts.
For more information on developing tug itself, see DEVELOPMENT.md.
tug -get-platforms lists available platforms.
tug -ls <name> lists cached buildx entries, for the given image name (format name[:tag]). Note that this lookup targets primarily remotely pushed images.
tug -t <name> builds multi-platform images with the given image name (format name[:tag]). This is the essential tug build command.
tug -clean cleans up after junk resources, including the buildx image cache and the tug buildx builder.
Notable options:
-debugenables additional logging.-exclude-os <list>rejects image operating systems from builds. The list is comma delimited.-exclude-arch <list>rejects image architectures from builds. The list is comma delimited.-load <os/arch>copies an image of the given platform from the buildx cache to the local Docker registry as a side effect of the build. By default, multi-platform do not appear in the main local image cache. Mainly useful to prepare quickdocker run... tests oflinux/amd64platform images.-pushuploads buildx cached images to the remote Docker registry, as a side effect of the build. Normally, multi-platform images cannot be pushed from the main local cache, because most platforms do not support loading into the main local cache..or<directory>are optional trailing arguments for the Docker build directory. We default to the current working directory.
See tug -help for more options.
Practice basic, single-platform Docker. As you gain confidence with Docker, you can extend this work into the realm of multi-platform images.
See the example project, which can be built with plain docker, or with docker buildx, or with tug.
Apply the tug -debug... option to see more commands. Follow the basic, low level buildx documentation. For a more advanced illustration, see how the snek project builds its Docker images.
Depends on your particular base image. Each base image on Docker Hub, for example, is a little platform snowflake. A base image usually supports some smaller subset of the universe of platform combinations. When in doubt, grow your -exclude-arch list and retry the build.
Running tug itself within a Docker context, such as for CI/CD, would naturally require Docker-in-Docker privileges. See the relevant documentation for your particular cluster environment, such as Kubernetes.
Docker Hub provides an exceptional variety of base images, everything from Debian to Ubuntu to RHEL to glibc to musl to uClibC. If your base image lacks support for a particular platform, try searching for alternative base images. Or, build a new base image from scratch and publish it back to Docker Hub! The more we refine our base images, the easier it is to extend and use them.
- crit generates Rust ports
- factorio ports Go applications
- gox, an older Go cross-compiler wrapper
- LLVM bitcode offers an abstract assembler format for C/C++ code
- snek ports native C/C++ applications
- tonixxx ports applications of any programming language
- WASM provides a portable interface for C/C++ code
- xgo supports Go projects with native cgo dependencies