Forgive me in advance, but this post will probably be a bit rant-y.\nIf you're looking for a way to do container builds in GitLab CI without a lot of fuss,\nthis article is for you.
\nI'm writing this post because Google recently canned yet another project: Kaniko.\nThis used to be pretty much the only way to build container images in Kubernetes.\nThis probably hasn't been the case for quite some time,\nbut devops is a chore for me, and my level of involvement is usually\njust enough to get my actual work done.
\nAnyways, there are a few possible replacements, including podman buildah and BuildKit.\nWith not so much as a finger to the wind, I decided that BuildKit looked like the more polished and capable option,\nso I went with that (even though I actually use podman on servers way more often than Docker proper).\nI found the documentation for switching to be a bit lacking,\nso you all get this post!
\nI've used GitLab CI for years and find it to be an extremely capable and easy to configure system.\nRunners are extremely easy to set up.\nRead the docs for details, but I'll whizz through a Docker-based setup (I haven't gotten around to k8s, so this is plain Docker).
\nFirst, create a volume to persist the configuration:
\ndocker volume create buildkit-gitlab-runner-config\nThen, start the runner for the first time.\nI've added a few flags to set up the required volumes, and ensure it restarts automatically.
\ndocker run -d --name buildkit-gitlab-runner --restart always -v /var/run/docker.sock:/var/run/docker.sock -v buildkit-gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest\nThe runner will launch, ish, but won't do anything useful without configuration + registration.\nYou can use an ephemeral instance of the runner image to register it.\nThis prompts you for your GitLab server URL and a token.\nYou get a token by logging into the GitLab admin section and registering a new runner.\nI also set the default image to moby/buildkit:rootless, but this is optional.
docker run --rm -it -v buildkit-gitlab-runner-config:/etc/gitlab-runner gitlab/gitlab-runner:latest register\nNext, get the path to the volume with the config using docker volume inspect buildkit-gitlab-runner-config.\nInside that directory (probably only readable by root),\nyou'll see the newly generated config.toml.
To enable running container builds, you'll need this in a runners.docker section:
\nsecurity_opt = ["seccomp:unconfined", "apparmor:unconfined"]\nThis is a bit confusing, since the GitLab docs do document this but,\nat the time of this writing, there are no examples and the description of the format is confusing.\nSee the BuildKit docs\nsection on Docker for an explanation of why these options are necessary but safe enough for rootless builds.\nThere's also a third flag, systempaths=unconfined, which I've omitted (we'll revisit in a moment).
In short, the above gets you rootless image builds from within a dockerized GitLab CI runner,\nwithout resorting to privileged containers or docker-in-docker.
\n.gitlab-ci.ymlNow let's look at what you need to get this working in your CI configuration.\nI'll assume your repo has a Dockerfile in it already and you want to build + push to your GitLab Container Registry.
\nstages:\n - build\n\ncontainerize:\n stage: build\n image:\n name: moby/buildkit:rootless\n entrypoint: [ "" ] # !!\n variables:\n BUILDKITD_FLAGS: --oci-worker-no-process-sandbox\n tags:\n - docker\n - buildkit-rootless\n before_script:\n # We have some more elaborate logic to our tag naming, but that's irrelevant...\n - export IMAGE_TAG="$CI_COMMIT_TAG"\n # Container registry credentials\n - mkdir -p ~/.docker\n - echo "{\\"auths\\":{\\"$CI_REGISTRY\\":{\\"username\\":\\"$CI_REGISTRY_USER\\",\\"password\\":\\"$CI_REGISTRY_PASSWORD\\"}}}" > ~/.docker/config.json\n script:\n - buildctl-daemonless.sh build\n --frontend dockerfile.v0\n --local context=.\n --local dockerfile=.\n --output type=image,name=$CI_REGISTRY_IMAGE:$IMAGE_TAG,push=true\n --opt build-arg:CI_JOB_TOKEN=$CI_JOB_TOKEN\nThis should be pretty much copy+paste for most projects.\nA few things to note:
\nBUILDKITD_FLAGS using the flag that BuildKit discourages.\nSince we'd like the same config to work on k8s runners too, we have to use this.ARG. Why? I'm glad you asked...We have a lot of internal crates in private repos.\nRecently I hit a snag with our previous approach to authenticated pulls though.\nOur Cargo.toml files use git SSH links, which won't work in CI.\nBut you can authenticate using HTTPS and a job token!
Our previous approach was to use sed to rewrite Cargo.toml and Cargo.lock.\nIt worked until we had a transitive dependency (a direct dependency on one private crate,\nwhich in turn had a dependency on another private crate).\nI don't know why this broke exactly, since we do use Cargo.lock,\nbut regardless, it was brittle.
The solution was to amed our Dockerfile with an ARG CI_JOB_TOKEN.\nThe build script then does some git magic to rewrite the SSH requests into HTTPS ones.\nI don't know why this feature exists,\nbut I'm happy I don't need to figure out how to run a private crate registry!
# Git hacks\ngit config --global credential.helper store\necho "https://gitlab-ci-token:${CI_JOB_TOKEN}@git.mycompany.com" > ~/.git-credentials\ngit config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@git.mycompany.com".insteadOf ssh://git@git.mycompany.com\nJust add this to your build script and replace the domain with your actual GitLab domain,\nand you'll have no more issues with transitive dependencies and authenticated pulls.
\n", "summary": "", "date_published": "2025-07-31T00:00:00-00:00", "image": "", "authors": [ { "name": "Ian Wagner", "url": "https://fosstodon.org/@ianthetechie", "avatar": "media/avi.jpeg" } ], "tags": [ "devops" ], "language": "en" }, { "id": "https://ianwwagner.com//optimizing-rust-builds-with-target-flags.html", "url": "https://ianwwagner.com//optimizing-rust-builds-with-target-flags.html", "title": "Optimizing Rust Builds with Target Flags", "content_html": "Recently I've been doing some work using Apache DataFusion for some high-throughput data pipelines.\nOne of the interesting things I noticed on the user guide was the suggestion to set\nRUSTFLAGS='-C target-cpu=native'.\nThis is actually a pretty common optimization (which I periodically forget about and rediscover),\nso I thought I'd do a quick writeup on this.
A compiler translates your "idiomatic" code into low-level instructions.\nModern optimizing compilers are pretty good at figuring out ways to cleverly rewrite your code\nto make it faster, while still being functionally equivalent at execution time.\nThe instructions may be reordered from what your simple mental model expects,\nand they may even have no resemblance.\nThis includes rewriting some loop-like (or iterator) patterns into "vectorized" code using SIMD instructions\nthat perform some operation on multiple values at once.
\nSpecial instruction families like this often vary within a single architecture,\nwhich may be surprising at first.\nThe compiler can be configured to enable (or disable!) specific "features",\noptimizing for compatibility or speed.
\nIn rustc, each target triple has a default set of CPU features enabled.\nIn the case of my work laptop, that's aarch64-apple-darwin.\nSince this architecture doesn't have a lot of variation among chips,\nthe compiler can make some pretty good assumptions about what's available.\n(In fact, for my specific CPU, the M1 Max, it's perfect!)\nBut we'll soon see this is not the case for the most common target: x86_64 Linux.
To figure out what features we could theoretically enable,\nwe need some CPU info from the machine we intend to deploy on.\nThe canonical way of checking CPU features on Linux is probably to cat /proc/cpuinfo.\nThis gives a lot more output that you probably need though.\nHelpfully, rustc includes a simple command that shows you the config\nfor the native CPU capabilities: rustc --print=cfg -C target-cpu=native.\nHere's what it looks like on one Linux machine:
debug_assertions\npanic="unwind"\ntarget_abi=""\ntarget_arch="x86_64"\ntarget_endian="little"\ntarget_env="gnu"\ntarget_family="unix"\ntarget_feature="adx"\ntarget_feature="aes"\ntarget_feature="avx"\ntarget_feature="avx2"\ntarget_feature="bmi1"\ntarget_feature="bmi2"\ntarget_feature="cmpxchg16b"\ntarget_feature="f16c"\ntarget_feature="fma"\ntarget_feature="fxsr"\ntarget_feature="lzcnt"\ntarget_feature="movbe"\ntarget_feature="pclmulqdq"\ntarget_feature="popcnt"\ntarget_feature="rdrand"\ntarget_feature="rdseed"\ntarget_feature="sse"\ntarget_feature="sse2"\ntarget_feature="sse3"\ntarget_feature="sse4.1"\ntarget_feature="sse4.2"\ntarget_feature="ssse3"\ntarget_feature="xsave"\ntarget_feature="xsavec"\ntarget_feature="xsaveopt"\ntarget_feature="xsaves"\ntarget_has_atomic="16"\ntarget_has_atomic="32"\ntarget_has_atomic="64"\ntarget_has_atomic="8"\ntarget_has_atomic="ptr"\ntarget_os="linux"\ntarget_pointer_width="64"\ntarget_vendor="unknown"\nunix\nAside: I'm not quite sure why, but this isn't a 1:1 match with /proc/cpuinfo on this box!\nIt definitely does support some AVX512 instructions,\nbut those don't show up in the native CPU options.\nIf anyone knows why, let me know!
UPDATE: Shortly after publishing this post, Rust 1.89 was released.\nThis PR linked in the release notes caught my eye.\nApparently the target features for AVX512 were not actually stable at the time of writing,\nbut they are now.\nRe-running the above command with version 1.89 of rustc now includes the AVX512 instructions.
\nPerhaps the more interesting question which motivates this investigation is\nwhat the defaults are.\nYou can get this with rustc --print cfg.\nThis shows what you get when you run cargo build without any special configuration.\nHere's the output for the same machine:
debug_assertions\npanic="unwind"\ntarget_abi=""\ntarget_arch="x86_64"\ntarget_endian="little"\ntarget_env="gnu"\ntarget_family="unix"\ntarget_feature="fxsr"\ntarget_feature="sse"\ntarget_feature="sse2"\ntarget_has_atomic="16"\ntarget_has_atomic="32"\ntarget_has_atomic="64"\ntarget_has_atomic="8"\ntarget_has_atomic="ptr"\ntarget_os="linux"\ntarget_pointer_width="64"\ntarget_vendor="unknown"\nunix\nWell, that's disappointing, isn't it?\nBy default, you'd only get up to SSE2, which is over 20 years old by now!\nThis is a consequence of the diversity of the x86_64 architecture.\nIf you want your binary to run everywhere, this is the price you'd have to pay.
While -C target-cpu=native will usually make your code faster on the build machine,\na lot of modern software is built by a CI pipeline on cheap runners, but deployed elsewhere.\nTo reliably target a specific set of features, use the target-feature flag.\nThis lets you specifically enable features you know will be available on the machine running the code.\nHere's an example of RUSTFLAGS that incorporates all of the above features.\nThis should enable builds to proceed from any other x86_64 Linux machine and while producing a binary\nthat supports the exact features of the deployment machine.
RUSTFLAGS="-C target-feature=+adx,+aes,+avx,+avx2,+bmi1,+bmi2,+cmpxchg16b,+f16c,+fma,+fxsr,+lzcnt,+movbe,+pclmulqdq,+popcnt,+rdrand,+rdseed,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+xsave,+xsavec,+xsaveopt,+xsaves"\nA few days after writing this, I accidentally stumbled upon something else when working out target flags\nfor a program I knew would have wider support across several datacenters.\nIt sure would be nice if there were some "groups" of commonly supported features, right?
\nTurns out this exists, and it was staring right at me in the CPU list: microarchitecture levels!\nIf you list out all the available target CPUs via rustc --print target-cpus on a typical x86_64 Linux box,\nyou'll see that your default target CPU is x86-64.\nThis means it will run on all x86_64 CPUs, and as we discussed above, this doesn't give much of a baseline.\nBut there are 4 versions in total, going up to x86-64-v4.\nIt turns out that AMD, Intel, RedHat, and SUSE got together in 2020 to define these,\nand came up with some levels which are specifically designed for our use case of optimizing compilers!\nYou can find the full list of supported features by level on Wikipedia\n(search for "microarchitecture levels").
rustc --print target-cpus will also tell you which specific CPU you're on.\nYou can use this info to find which "level" you support.\nBut a more direct way to map to level support is to run /lib64/ld-linux-x86-64.so.2 --help.\nThanks, internet!\nYou'll get some output like this on a modern CPU:
Subdirectories of glibc-hwcaps directories, in priority order:\n x86-64-v4 (supported, searched)\n x86-64-v3 (supported, searched)\n x86-64-v2 (supported, searched)\nAnd if you run on slightly older hardware, you might get something like this:
\nSubdirectories of glibc-hwcaps directories, in priority order:\n x86-64-v4\n x86-64-v3 (supported, searched)\n x86-64-v2 (supported, searched)\nThis should help if you're trying to aim for broader distribution rather than enabling specific features for some known host.\nThe line to target an x86_64 microarch level is a lot shorter.\nFor example:
\nRUSTFLAGS="-C target-cpu=x86-64-v3"\nNOTE: As mentioned above, Rust 1.89 was released shortly after this post.\nThis incidentally brings support for AVX512 CPU features in the x86-64-v4 target CPU,\nwhich were previously marked unstable.
Enabling CPU features doesn't always make things faster.\nIn fact, in some cases, it can even do the opposite!\nThis thread\nhas some interesting anecdotes.
\nIn conclusion, here's a quick reference of the useful commands we covered:
\nrustc --print cfg - Shows the compiler configuration that your toolchain will use by default.rustc --print=cfg -C target-cpu=native - List the configuration if you were to specifically target for your CPU. Use this to see the delta between the defaults and the featurse supported for a specific CPU.rustc --print target-cpus - List all known target CPUs. This also tells you what your current CPU and what the default CPU is for your current toolchain./lib64/ld-linux-x86-64.so.2 --help - Specifically for x86_64 Linux users, will show you what microarchitecture levels your CPU supports.rustc --print target-features - List all available target features with a short description. You can scope to a specific CPU with -C target-cpu=. Useful mostly to see what you're missing, I guess.