coreos/chunkah

coreos 프로필

최근 기록된 소스 활동: 2026년 6월 2일 01:45

SkillsMP 카탈로그 업데이트: 2026년 10월 17일 00:09

수집된 skills: 4

GitHub 스타: 148
GitHub 포크: 17

저장소 README

README 원본 파일: README.md

README 원본 보기

README 전체 펼치기

# chunkah An OCI building tool that takes a flat rootfs and outputs a layered OCI image with content-based layers. ## Table of Contents - [Motivation](#motivation) - [Highlights](#highlights) - [Installation](#installation) - [Verifying image signatures](#verifying-image-signatures) - [Usage](#usage) - [Splitting an existing image](#splitting-an-existing-image) - [Splitting an image at build time](#splitting-an-image-at-build-time-buildahpodman-only) - [Advanced Usage](#advanced-usage) - [Understanding components](#understanding-components) - [Customizing the layers](#customizing-the-layers) - [Limiting the number of layers](#limiting-the-number-of-layers) - [Output options](#output-options) - [Building from a raw rootfs](#building-from-a-raw-rootfs) - [Customizing the OCI image config and annotations](#customizing-the-oci-image-config-and-annotations) - [Pruning and filtering](#pruning-and-filtering) - [Architecture](#architecture) - [Parallelism](#parallelism) - [Compatibility with bootable (bootc) images](#compatibility-with-bootable-bootc-images) - [Debugging](#debugging) - [Relationship to `zstd:chunked`](#relationship-to-zstdchunked) - [Origins](#origins) ## Motivation Traditionally, images built using a `Dockerfile` result in a multi-layered image which model how the `Dockerfile` was written. For example, a separate layer is created for each `RUN` and `COPY` instructions. This can cause poor layer caching on clients pulling these images. A single package change may invalidate a layer much larger than the package itself, requiring re-pulling. When splitting an image into content-based layers, it doesn't matter how the final contents of the image were derived. The image is "postprocessed" so that layers are created in a way that tries to maximize layer reuse. Commonly, this means grouping together related packages. This has benefits at various levels: at the network level (common layers do not need to be re-pulled), at the storage level (common layers are stored once), and at the runtime level (e.g. libraries are only mapped once). chunkah allows you to keep building your image as you currently do, and then perform this content-based layer splitting. ## Highlights - **Content agnostic** — Compatible with RPM-based images, but not only. Other package ecosystems can be supported, as well as fully custom content. - **Container-native** — Best used as a container image, either as part of a multi-staged build, or standalone. - **Zero diff** — Apart from modification time, content is never modified. - **Reproducible** — Supports `SOURCE_DATE_EPOCH` for reproducible layers. It is a non-goal to support initial building of the root filesystem itself. Lots of tools for that exist already. It is also currently a non-goal to preprocess the rootfs to remove common sources of non-reproducibility (such as [add-determinism]). This can be done by the image build process itself. ## Installation chunkah is primarily intended to be used as a container image: ```shell podman run -ti --rm quay.io/coreos/chunkah --help ``` However, if you're currently building images using a multi-stage build, it may be more convenient to `cargo install` the binary into your builder image (whether at runtime or build time if you own the builder image). chunkah is also packaged in Fedora, making it easier to do this there. ### Verifying image signatures Container images are signed using [cosign] keyless signing. You can verify the signature of an image using cosign v3+: ```shell cosign verify \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ --certificate-identity-regexp '^https://github\.com/coreos/chunkah/' \ quay.io/coreos/chunkah:latest ``` ## Usage There are two main ways to use chunkah: - splitting an existing image - splitting an image at build time ### Splitting an existing image #### Using Podman/Buildah When using Podman/Buildah, the most natural way to split an existing image is to use the `Containerfile.splitter`, passing the target image as the `--from`: ```shell IMG=quay.io/fedora/fedora-minimal:latest buildah build --skip-unused-stages=false --from $IMG \ --build-arg CHUNKAH_CONFIG_STR="$(podman inspect $IMG)" \ https://github.com/coreos/chunkah/releases/download/v0.7.1/Containerfile.splitter ``` Additional arguments can be passed to chunkah using the CHUNKAH_ARGS build argument. > [!NOTE] > You must add the `--skip-unused-stages=false` option (see also [this buildah > RFE][buildah-rfe]). > > For Buildah versions before v1.44, this also requires `-v $(pwd):/run/src > --security-opt=label=disable`. Note that this will leave behind an `out/` > directory in the current directory. Another option is using the chunkah image directly and image mounts: ```shell IMG=quay.io/fedora/fedora-minimal:latest podman pull $IMG # image must be available locally export CHUNKAH_CONFIG_STR="$(podman inspect $IMG)" podman run --rm --mount=type=image,src=$IMG,dest=/chunkah \ -e CHUNKAH_CONFIG_STR quay.io/coreos/chunkah build \ -t localhost/fedora-minimal-chunked:latest | podman load ``` The `-t`/`--tag` option sets the image name in the OCI archive so that `podman load` automatically tags the loaded image. Without it, the image is loaded as an unnamed image identified only by its digest. For large images, this approach is less efficient than using `Containerfile.splitter`, which avoids the overhead of tarring and untarring the OCI archive (though the same efficiency can be gained by using [`--output oci:PATH`](#output-options) and importing it using `skopeo copy`.) #### Using Docker/Moby You can use the chunkah image directly using image mounts (requires v28+): ```shell IMG=quay.io/fedora/fedora-minimal:latest docker pull $IMG # image must be available locally export CHUNKAH_CONFIG_STR="$(docker inspect $IMG)" docker run --rm --mount=type=image,src=$IMG,destination=/chunkah \ -e CHUNKAH_CONFIG_STR quay.io/coreos/chunkah build \ -t localhost/fedora-minimal-chunked:latest | docker load ``` Note `docker load` support for OCI archives requires the [containerd image store] (default on new installations starting from v29+). If using the legacy graph driver, instead of piping directly into `docker load` as above, you can redirect to a file to save the OCI archive, and then use skopeo to convert to the Docker archive format: ```shell docker run --rm -ti -v $(pwd):/srv:z -w /srv quay.io/skopeo/stable \ copy oci-archive:out.ociarchive docker-archive:out.dockerarchive:chunked docker load -i out.dockerarchive ``` ### Splitting an image at build time (buildah/podman only) This uses a method called the "`FROM oci:` trick", for lack of a better term. It has the massive advantage of being compatible with a regular `buildah build` flow and also makes it more natural to apply configs to the image, but is specific to the Podman ecosystem. This *will not* work with Docker. ```Dockerfile # Optional; by default base image metadata (like labels) are lost and need to # either be repeated in the final stage or passed in via a build arg like this # one. Use with `--build-arg CHUNKAH_CONFIG_STR=$(podman inspect $IMG)`. ARG CHUNKAH_CONFIG_STR FROM quay.io/fedora/fedora-minimal:latest AS builder RUN dnf install -y git-core && dnf clean all FROM quay.io/coreos/chunkah AS chunkah ARG CHUNKAH_CONFIG_STR RUN --mount=type=bind,target=/run/src,rw \ --mount=from=builder,target=/chunkah,ro \ chunkah build --output oci:/run/src/out FROM oci:out ENTRYPOINT ["git"] ``` > [!NOTE] > When building your image, you must also add the `--skip-unused-stages=false` > option (see also [this buildah RFE][buildah-rfe]), and you cannot use the > `--jobs` option. > > For Buildah versions before v1.44, this also requires `-v $(pwd):/run/src > --security-opt=label=disable`. Note that this will leave behind an `out/` > directory in the current directory.  > [!NOTE] > There is [a known bug][buildah-annotations-bug] in this workflow preventing > informational layer annotations added by chunkah from persisting to the > final image when additional instructions follow the final `FROM`. If you're > interested in that information, you must either use `--config-str` instead > to pass your config, or run chunkah as a separate step as described in the > previous section. ## Advanced Usage ### Understanding components A component is a logical grouping of files that belong together. For example, all files from an RPM belong to the same component. Layers are created based on found components. A component repo is a source of data from which components can be created. For example, the rpmdb is a component repo (one can imagine similar component repos for other distros). There is also an xattr-based component repo (see the section "Customizing the layers" below). Multiple component repos can be active at once. ### Customizing the layers It is possible to create custom components by setting the `user.component` xattr on files/directories. This can be done using `setfattr`, e.g.: ```Dockerfile RUN setfattr -n user.component -v "custom-apps" /usr/bin/my-app ``` This is compatible with rpm-ostree's support for [the same feature](https://coreos.github.io/rpm-ostree/build-chunked-oci/#assigning-files-to-specific-layers). However, unlike rpm-ostree, this does not guarantee unique layers per xattr component. In addition, the `user.update-interval` xattr is also supported. The value is the average number of days between updates, either as an integer or a named label (`daily`, `weekly`, `biweekly`, `monthly`, `quarterly`, `yearly`), e.g.: ```Dockerfile RUN setfattr -n user.component -v "custom-apps" /usr/bin/my-app && \ setfattr -n user.update-interval -v "monthly" /usr/bin/my-app ``` This only needs to be set on one of the files in the component. If multiple files have conflicting values, chunkah reports an error. It is strongly recommended to set this xattr. A rough approximation is fine. This helps the packing algorithm make better decisions about which components to group together. When missing, defaults to `weekly`. ### Limiting the number of layers By default, the maximum number of layers emitted is 64. This can be increased or decreased using the `--max-layers` option. If the number of components exceeds the maximum, chunkah will pack multiple components together. There is thus a tradeoff in deciding this. Fewer layers means losing the efficiency gains of content-based layers. Too many layers may mean excessive processing and overhead when pushing/pulling the image. Note that containers-storage has a hard limit of 500 layers. ### Output options By default, chunkah writes an OCI archive to stdout. The `-o`/`--output` flag controls where and in what format the image is written. It supports an optional transport prefix: - `--output PATH` or `--output oci-archive:PATH` — write an OCI archive to a file instead of stdout. - `--output oci:PATH` — write the OCI directory layout directly to disk. This avoids the overhead of tarring and untarring the archive, which is particularly useful in the buildah `FROM oci:` flow (see [Splitting an image at build time](#splitting-an-image-at-build-time-buildahpodman-only)). By default, layers are uncompressed (since in the common case the OCI archive/directory is immediately imported into a container storage backend, which would immediately uncompress it). Use `--compressed` to enable gzip compression for layers (and the OCI archive itself, if applicable). The compression level can be tuned with `--compression-level` (0-9, default 6). ### Building from a raw rootfs For completeness, note it's of course also possible to split any arbitrary rootfs, regardless of where it comes from: ```shell podman run --rm -v /path/to/rootfs:/chunkah:z \ -e CHUNKAH_CONFIG_STR="$(cat config.json)" \ quay.io/coreos/chunkah build > out.ociarchive ``` > [!NOTE] > The `:z` option will relabel all files for access by the container, which may > be expensive for a large rootfs. You can use `--security-opt=label=disable` to > avoid this, but it disables SELinux separation with the chunkah container. See [Output options](#output-options) for controlling the output format and compression. ### Customizing the OCI image config and annotations The OCI image config can be provided via the `--config` option (as a file) or `--config-str`/`CHUNKAH_CONFIG_STR` (inline). The primary format is the [OCI image config] spec as JSON: ```json { "Entrypoint": ["/bin/bash"], "Cmd": ["-c", "echo hi"], "WorkDir": "/root" } ``` The output format of `podman inspect` and `docker inspect` are also supported, mostly for convenience when splitting an existing image, though it does also have the advantage of capturing annotations. Otherwise, it's also possible to set annotations directly using `--annotation`. Labels can also be added via `--label`. ### Pruning and filtering The `--prune` option excludes paths from the rootfs. It can be specified multiple times. The trailing slash matters: - `--prune /path` excludes the directory and all its descendants entirely. - `--prune /path/` excludes only the contents but keeps the directory itself. By default, chunkah errors when encountering special file types (sockets, FIFOs, block/char devices). Use `--skip-special-files` to silently skip them instead. ### Architecture The `--arch` option overrides the target architecture for the output image. This is useful when splitting an image whose architecture differs from the running host. If not provided, the architecture from the config is used (if available), or the current system architecture otherwise. Common aliases are supported (e.g. `x86_64` maps to `amd64`, `aarch64` to `arm64`). ### Parallelism Layers are written in parallel. The number of threads can be controlled with `-T`/`--threads` (or `CHUNKAH_THREADS`). By default, the number of available CPUs is used. ### Compatibility with bootable (bootc) images chunkah has no special handling for [bootable container images]. This should work fine for non-OSTree based images (i.e. "plain" images). Packing still needs to be fine-tuned for bootable images (or very large images in general). You will likely want to increase the default maximum number of layers from 64 (e.g. 128) for better splitting. As mentioned in [this section](#splitting-an-image-at-build-time-buildahpodman-only), in the build time flow, labels from the base image will be lost, including versioning information and `containers.bootc=1`, which is required by bootc. So you'll want to use a `CHUNKAH_CONFIG_STR` build arg or just re-add the label. Using chunkah to rechunk an OSTree-based bootc image is also possible by transforming it into a plain one by passing `--prune /sysroot/` to strip OSTree data from the image. If base metadata is persisted (either the existing image flow, or the build time flow with inspect output passed in as a build arg), you will need to remove the ostree-related labels using the `--label KEY-` option: ```Dockerfile ARG CHUNKAH_CONFIG_STR FROM quay.io/fedora/fedora-bootc:latest AS builder RUN dnf install -y tmux && dnf clean all RUN bootc container lint FROM quay.io/coreos/chunkah AS chunkah ARG CHUNKAH_CONFIG_STR RUN --mount=from=builder,src=/,target=/chunkah,ro \ --mount=type=bind,target=/run/src,rw \ chunkah build --prune /sysroot/ --max-layers 128 \ --label ostree.commit- --label ostree.final-diffid- \ --output oci:/run/src/out FROM oci:out ``` ### Debugging Use `-v` for verbose output or the `RUST_LOG` environment variable for fine-grained control (e.g. `RUST_LOG=chunkah=debug`). Logs are written to stderr. (There is also `-vv` for trace output mostly meant for chunkah development. You'll want to redirect stderr to a file!) ## Relationship to `zstd:chunked` [zstd:chunked] is a [container-libs] feature that enables partial layer pulls, fetching only changed files and chunks within a layer via HTTP range requests. chunkah and zstd:chunked are complementary: - chunkah operates at build time: it structures the image so that unchanged content lives in unchanged layers, maximizing layer-level deduplication. This works with any OCI registry and requires no special client support. - zstd:chunked operates at pull time: within layers, only the files (technically chunks *within* files) that changed are fetched. This requires client support and HTTP range requests from the registry, and has higher CPU and memory overhead on the client side. Used together, most layers are reused at the registry level (thanks to chunkah), and for the few that *did* change, you can efficiently pull just those (thanks to zstd:chunked), minimizing overhead. ## Origins chunkah is a generalized successor to rpm-ostree's [build-chunked-oci] command which does content-based layer splitting on RPM-based [bootable container images]. Unlike rpm-ostree, chunkah is not tied to bootable containers nor RPMs. The name is a nod to this ancestry and to buildah, with which it integrates well. [add-determinism]: https://github.com/keszybz/add-determinism [bootable container images]: https://containers.github.io/bootable/ [buildah-annotations-bug]: https://github.com/containers/buildah/issues/6652 [buildah-rfe]: https://github.com/containers/buildah/issues/6621 [build-chunked-oci]: https://coreos.github.io/rpm-ostree/build-chunked-oci/ [containerd image store]: https://docs.docker.com/engine/storage/containerd/ [container-libs]: https://github.com/containers/container-libs [cosign]: https://github.com/sigstore/cosign [OCI image config]: https://github.com/opencontainers/image-spec/blob/26647a49f642c7d22a1cd3aa0a48e4650a542269/specs-go/v1/config.go#L24 [zstd:chunked]: https://github.com/containers/container-libs/blob/main/storage/docs/containers-storage-zstd-chunked.md

저장소 README를 불러오는 중…

이 저장소의 skills

소프트웨어 개발자

직업 카테고리 1개 · 100% 분류됨

skill

직업 분류

설명

업데이트

polish-notes

소프트웨어 개발자

Polish raw GitHub release notes into user-impact-focused summaries. Use when preparing release notes for a new chunkah version.

원문 언어: 영어

2026-06-02

alloc-tracker

소프트웨어 개발자

Use when you need to measure per-phase memory allocation statistics to investigate memory usage.

원문 언어: 영어

2026-04-30

benchmark-packing

소프트웨어 개발자

Benchmark chunkah packing algorithm changes against a series of OCI images.

원문 언어: 영어

2026-04-30

extract-oci-archive

소프트웨어 개발자

Use when you need to extract an OCI archive to inspect its contents, get the rootfs layer, or read the image config.

원문 언어: 영어

2026-04-30

수집된 skill 4개 중 4개를 표시합니다.

AI 어시스턴트로 설치

이 프롬프트를 복사해 사용 중인 AI 어시스턴트에 입력하세요.

Follow https://skillsmp.com/skill-install/prompt.md to install Agent Skills from https://github.com/coreos/chunkah.