Skip to content

Commit

Permalink
Merge pull request #541 from cgwalters/clarify-mutability
Browse files Browse the repository at this point in the history
docs: Clarify mutability at build vs runtime
  • Loading branch information
cgwalters committed May 17, 2024
2 parents 1f0c19a + 3ee7cef commit d65013c
Show file tree
Hide file tree
Showing 2 changed files with 18 additions and 0 deletions.
9 changes: 9 additions & 0 deletions docs/src/building/guidance.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,15 @@ Let's however restate a base goal of this project:
Every tool and technique for creating application base images
should apply to the host Linux OS as much as possible.

## Understanding mutability

When run as a container (particularly as part of a build), bootc-compatible
images have all parts of the filesystem (e.g. `/usr` in particular) as fully
mutable state, and writing there is encouraged (see below).

When "deployed" to a physical or virtual machine, the container image
files are read-only by default; for more, see [filesystem](../filesystem.md).

## Installing software

For package management tools like `apt`, `dnf`, `zypper` etc.
Expand Down
9 changes: 9 additions & 0 deletions docs/src/filesystem.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,15 @@ enabled = true

This will ensure that the entire `/` is a read-only filesystem.

## Understanding container build/runtime vs deployment

When run *as a container* (e.g. as part of a container build), the
filesystem is fully mutable in order to allow derivation to work.
For more on container builds, see [build guidance](building/guidance.md).

The rest of this document describes the state of the system when
"deployed" to a physical or virtual machine, and managed by `bootc`.

## Understanding physical vs logical root with `/sysroot`

When the system is fully booted, it is into the equivalent of a `chroot`.
Expand Down

0 comments on commit d65013c

Please sign in to comment.