Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

I made a Dockerfile-like system for rootfs (root filesystem) images #4740

kanpov started this conversation in Show and tell
Discussion options

One of my pain points with Firecracker was the error-prone setup that is recommended for creating rootfs images, also known as putting together a bunch of Bash scripts. In my opinion, this is far inferior to just having a Dockerfile/Containerfile that produces the image (in this case, not an OCI image, but rather a rootfs), so I wrote a CLI tool that uses a easy-to-understand and easy-to-write TOML build script to produce a rootfs in Rust: https://crates.io/crates/buildfs.

In the README available on crates.io there is a complete getting started guide with a single TOML build script that can be executed to produce a minified systemd rootfs based on debian:bookworm-slim. buildfs also supports overlays, i.e. injecting files and directories into the rootfs ("overlaying" them) in separate files that are referenced with the TOML script and packaged together into a directory/tarball (if no such references exist, we can use only the TOML script as shown in the getting started guide), and running not only inline, but also external scripts also packaged together with the TOML.

The steps that buildfs uses to produce the rootfs are:

  1. The type of package is determined (a single script, a directory, a tarball, a gzipped tarball) automatically
  2. The package is validated for declarativity (e.g. no references to files that don't exist in the package are made)
  3. A connection to the container engine (both Docker and Podman are supported, with Podman using its native libpod API) is made
  4. The container image is pulled if it doesn't exist
  5. The container is started up with the scripts that need to be run inside being bind-mounted into the container
  6. The bind-mounted scripts are executed
  7. The container's root filesystem is exported via podman and docker's export functionality (dump a container's entire contents) and extracted to a temporary location
  8. The container is stopped and removed
  9. The filesystem image is allocated with dd, mkfs is run and the filesystem is mounted into a temporary location
  10. Overlays from the build script are applied to the mounted filesystem
  11. From the exported container rootfs, directories and files configured in the build script are copied over into the mount, and configured directories and files are created in the mount (an example of the former would be /sbin and an example of the latter would be /dev or /proc as these are just empty mountpoints)
  12. The container rootfs and other temporary paths are deleted and the actual filesystem is unmounted

By streamlining as much of the rootfs creation process as possible, buildfs allows you to configure only the things that matter and automate away the rest (as shown above): scripts to run and overlays to apply, which container image to use, which type of filesystem to create and how big it should be, which directories and files to save and which mountpoints to create. The example build script from the README is only 55 lines of TOML and it is enough to create an EXT4 Debian rootfs with systemd and DNS configured that is ready for use in Firecracker.

You must be logged in to vote

Replies: 0 comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
1 participant

AltStyle によって変換されたページ (->オリジナル) /