docs: change refs to old bootc docs URL to new variable
Move all references to the previous docs site to the new variable. Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
This commit is contained in:
Valentin Rothberg
parent
babf67e805
commit
1549613a7f
14 changed files with 24 additions and 24 deletions
|
|
@ -8,7 +8,7 @@ for the host system.
|
|||
By default, the OS performs continual auto-updates via a stock copy of the upstream
|
||||
`bootc-fetch-apply-updates.timer` and corresponding `bootc-fetch-apply-updates.service`.
|
||||
|
||||
For more, see <https://containers.github.io/bootc/man-md/bootc-fetch-apply-updates.service.html>
|
||||
For more, see <{bootc-upstream}/man-md/bootc-fetch-apply-updates.service.html>
|
||||
|
||||
== podman
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ reboot
|
|||
|
||||
===== Accessing registries
|
||||
|
||||
See the https://containers.github.io/bootc/registries-and-offline.html[bootc documentation] on
|
||||
See the {bootc-upstream}/registries-and-offline.html[bootc documentation] on
|
||||
registries, as well as the xref:container-pull-secrets.adoc[Container pull secrets] section.
|
||||
|
||||
The default Anaconda installation ISOs may also need a duplicate copy of some "bootstrap"
|
||||
|
|
@ -122,7 +122,7 @@ the "source of truth" as much as possible. A "basic" installer
|
|||
is built into the `bootc` project and is available as `bootc install to-disk`
|
||||
or `bootc install to-filesystem`.
|
||||
|
||||
TIP: More information is available https://containers.github.io/bootc/bootc-install.html[at the upstream bootc site].
|
||||
TIP: More information is available {bootc-upstream}/bootc-install.html[at the upstream bootc site].
|
||||
|
||||
In the very simplest example, assuming you have a running Linux environment
|
||||
with `podman`, you can perform a bare metal installation to a block device.
|
||||
|
|
|
|||
|
|
@ -187,7 +187,7 @@ file which will be visible in a Podman container but it won't be propagated to
|
|||
the booted system.
|
||||
|
||||
For details and recommendations, please refer to the
|
||||
https://containers.github.io/bootc/building/bootc-runtime.html[bootc-runtime documentation].
|
||||
{bootc-upstream}/building/bootc-runtime.html[bootc-runtime documentation].
|
||||
|
||||
== Lifecycle binding code and configuration
|
||||
|
||||
|
|
@ -305,7 +305,7 @@ Often packaging scripts may invoke `useradd`. This can cause "state drift"
|
|||
in the case where `/etc/passwd` is also locally modified on the system,
|
||||
and transient `/etc` is not in use.
|
||||
|
||||
More on this in https://containers.github.io/bootc/building/users-and-groups.html#adding-users-and-credentials-statically-in-the-container-build[bootc upstream].
|
||||
More on this in {bootc-upstream}/building/users-and-groups.html#adding-users-and-credentials-statically-in-the-container-build[bootc upstream].
|
||||
|
||||
If the user does not *own* any content shipped in `/usr` and it runs
|
||||
as a systemd unit, then it's often a good candidate to convert to
|
||||
|
|
@ -347,7 +347,7 @@ possible.
|
|||
|
||||
== General configuration guidance
|
||||
|
||||
See the https://containers.github.io/bootc/building/guidance.html[bootc upstream guidance].
|
||||
See the {bootc-upstream}/building/guidance.html[bootc upstream guidance].
|
||||
|
||||
Many configuration changes to a Linux system boil down effectively to
|
||||
writing configuration files into `/etc` or `/usr` - those operations
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ A common scenario is needing to configure the host system with a
|
|||
the host updates itself!
|
||||
|
||||
There is a section in the upstream bootc documentation for
|
||||
https://containers.github.io/bootc/building/secrets.html#secrets-eg-container-pull-secrets[secrets in general]
|
||||
{bootc-upstream}/building/secrets.html#secrets-eg-container-pull-secrets[secrets in general]
|
||||
that applies here.
|
||||
|
||||
The following content applies to the *built image*. When using an external
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
:page-partial:
|
||||
|
||||
NOTE: The default filesystem type for CentOS is `xfs`. There is no default filesystem for Fedora, and you must choose one when generating a disk image
|
||||
or configure one in your derived container image via https://containers.github.io/bootc/bootc-install.html#operating-system-install-configuration-required[bootc install config].
|
||||
or configure one in your derived container image via {bootc-upstream}/bootc-install.html#operating-system-install-configuration-required[bootc install config].
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
= Understanding the {projname} filesystem layout
|
||||
|
||||
This section briefly re-summarizes some of the content that is in the
|
||||
upstream https://containers.github.io/bootc/filesystem.html[bootc filesystem documentation].
|
||||
upstream {bootc-upstream}/filesystem.html[bootc filesystem documentation].
|
||||
Please consult that for more.
|
||||
|
||||
== composefs
|
||||
|
|
@ -49,7 +49,7 @@ container to configure networking, this will apply on upgrades.
|
|||
|
||||
However, according to the 3-way merge logic, any machine-local modified files will "win"
|
||||
by default. This can be a common issue with modifications to `/etc/passwd`
|
||||
in derived containers. For more on users and groups, see https://containers.github.io/bootc/building/users-and-groups.html[bootc users and groups].
|
||||
in derived containers. For more on users and groups, see {bootc-upstream}/building/users-and-groups.html[bootc users and groups].
|
||||
|
||||
== Filesystem bind mount: /var
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ While there are dozens of security benefits of image-based systems, we want to h
|
|||
Similar to the security benefits, bootable containers integrate into a vast ecosystem of tools and technologies which have emerged around containers. With bootable containers, we can build, deploy and manage our Linux systems at new scale and speed. A consistent feedback from early adopters of bootable containers is the observation of a simplified toolchain for managing all these tasks in less time.
|
||||
|
||||
== Bootc
|
||||
https://containers.github.io/bootc/[Bootc] is at the core and center of bootable containers. It is a CLI tool that ships with a number of systemd services and timers to manage a bootable container. Among other things, bootc is responsible for downloading and queuing updates, and can be used by other higher-level tools to manage the system and inspect the system status. For that reason, bootc is an integral part of each bootable container image. For more details, please refer to the https://containers.github.io/bootc/[bootc documentation].
|
||||
{bootc-upstream}/[Bootc] is at the core and center of bootable containers. It is a CLI tool that ships with a number of systemd services and timers to manage a bootable container. Among other things, bootc is responsible for downloading and queuing updates, and can be used by other higher-level tools to manage the system and inspect the system status. For that reason, bootc is an integral part of each bootable container image. For more details, please refer to the {bootc-upstream}/[bootc documentation].
|
||||
|
||||
== Filesystem Layout
|
||||
Bootc systems follow the concept of an immutable operating system. Apart from the following two exceptions, `/etc` and `/var`, all directories are mounted read-only once deployed on a physical or virtual machine. However, during a container build the entire file-system is writable.
|
||||
|
|
@ -52,7 +52,7 @@ In case the bootable container will be run in `podman-bootc`, see the xref:#_pod
|
|||
For more details on building derived bootc images, see the xref:building-containers.adoc[page in the docs]. Note that bootc is still under development. On rare occasions you might encounter problems you can find in the https://gitlab.com/fedora/bootc/tracker[upstream issue tracker] (requires a GitLab account).
|
||||
|
||||
== Conversion to Disk Images
|
||||
Updates for bootable containers happen in the form of pulling a new image and (re-)booting into it. But how do we install a fresh bootc system? While bootc supports https://containers.github.io/bootc/bootc-install.html#using-bootc-install-to-existing-root[installing a bootc container on top of an existing system], it is more common to convert a bootable container into a so-called disk image, such as ISO, raw or qcow2 to provision a new system.
|
||||
Updates for bootable containers happen in the form of pulling a new image and (re-)booting into it. But how do we install a fresh bootc system? While bootc supports {bootc-upstream}/bootc-install.html#using-bootc-install-to-existing-root[installing a bootc container on top of an existing system], it is more common to convert a bootable container into a so-called disk image, such as ISO, raw or qcow2 to provision a new system.
|
||||
|
||||
You can convert a bootable container into a disk image with the https://github.com/osbuild/bootc-image-builder[bootc-image-builder] which itself needs to be executed inside a container. `bootc-image-builder` is a feature-rich tool that further enables you to inject users, SSH keys, and define a partition layout. For more details, see the https://github.com/osbuild/bootc-image-builder?tab=readme-ov-file#-arguments[upstream documentation]. Podman Desktop also ships with a https://github.com/containers/podman-desktop-extension-bootc[bootc extension] which allows you to build and convert bootc images in just a few clicks. For more information on the extension, please see the https://developers.redhat.com/articles/2024/05/07/podman-desktop-red-hat-developer-subscription#bootc_extension_for_podman_desktop[release blog post]. Once converted, you can boot a disk image by using libvirt and qemu and other virtualization tools as described in xref:qemu-and-libvirt.adoc[in the docs].
|
||||
|
||||
|
|
@ -124,7 +124,7 @@ podman-bootc is still under development but perfectly capable of supporting your
|
|||
There are no default interactive users other than root in the base image. In the default full base images, OpenSSH is running, but there are no hardcoded credentials (passwords or SSH keys). That means that you cannot log into a booted VM without further work (e.g., injecting SSH keys for the root users). For that reason, podman-bootc automatically injects SSH keys such that you can easily get access to the VM. See the xref:authentication.adoc[section on authentication] in the docs for more information on this topic.
|
||||
|
||||
== Installing on Bare Metal
|
||||
At this point, you know how to build a bootable container image and how to convert it into a disk image that you may want to install on your machine. Before installing Fedora/CentOS bootc, it’s recommended that you have created a customized derived container image, but this is not a hard requirement, as it is possible to enable basic system access via e.g. injecting SSH keys with kickstart or with https://containers.github.io/bootc/bootc-install.html[bootc-install] and the `--root-ssh-authorized-keys` flag. You can find a list of examples and detailed instructions xref:bare-metal.adoc[here]. You can further find documentation on how to provision public cloud instances on xref:provisioning-aws.adoc[AWS] or xref:provisioning-gcp.adoc[GCP] and how to install on xref:provisioning-vsphere.adoc[vSphere].
|
||||
At this point, you know how to build a bootable container image and how to convert it into a disk image that you may want to install on your machine. Before installing Fedora/CentOS bootc, it’s recommended that you have created a customized derived container image, but this is not a hard requirement, as it is possible to enable basic system access via e.g. injecting SSH keys with kickstart or with {bootc-upstream}/bootc-install.html[bootc-install] and the `--root-ssh-authorized-keys` flag. You can find a list of examples and detailed instructions xref:bare-metal.adoc[here]. You can further find documentation on how to provision public cloud instances on xref:provisioning-aws.adoc[AWS] or xref:provisioning-gcp.adoc[GCP] and how to install on xref:provisioning-vsphere.adoc[vSphere].
|
||||
|
||||
== Updating Bootable Containers
|
||||
The figure below depicts the life cycle of a bootable container and the different steps required from building to deploying to updating bootc systems. Once a bootable container image has been built, you may convert it to a disk image. The disk image can then be used to install the content in the target environment (e.g., a public cloud instance). You might also want to push the container image to your target container registry.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ state.
|
|||
|
||||
When using `bootc install`, it is possible to add install-time kernel arguments
|
||||
both in the container image, and via `bootc install --karg`.
|
||||
https://containers.github.io/bootc/building/kernel-arguments.html["Day 2 updatable" kernel arguments] are supported as well.
|
||||
{bootc-upstream}/building/kernel-arguments.html["Day 2 updatable" kernel arguments] are supported as well.
|
||||
|
||||
Part of the longer term design is that both Anaconda and bootc-image-builder
|
||||
will start internally using `bootc install to-filesystem` code, and
|
||||
|
|
@ -55,4 +55,4 @@ will be dropped from the default base image.
|
|||
|
||||
== Future: kernel arguments managed via container updates ==
|
||||
|
||||
Kernel arguments can also be shipped when updating the bootc container, for instance, by adding a new `.toml` config to `/usr/lib/bootc/kargs.d/`. For details, please refer to the https://containers.github.io/bootc/building/kernel-arguments.html[upstream documentation].
|
||||
Kernel arguments can also be shipped when updating the bootc container, for instance, by adding a new `.toml` config to `/usr/lib/bootc/kargs.d/`. For details, please refer to the {bootc-upstream}/building/kernel-arguments.html[upstream documentation].
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ for the base images. There are two primary paths to running in AWS:
|
|||
A very useful and low-cost mechanism for provisioning a container image *without*
|
||||
generating a disk image is to use the `bootc install to-existing-root`
|
||||
flow, where the container image "installs itself" alongside an existing root
|
||||
filesystem, setting it up for the next boot. ( https://containers.github.io/bootc/bootc-install.html#using-bootc-install-to-existing-root[Upstream documentation] )
|
||||
filesystem, setting it up for the next boot. ( {bootc-upstream}/bootc-install.html#using-bootc-install-to-existing-root[Upstream documentation] )
|
||||
|
||||
=== Understanding bootc-image-builder
|
||||
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ For more, see xref:qemu-and-libvirt.adoc[qemu and libvirt].
|
|||
|
||||
== Using `bootc install to-existing-root`
|
||||
|
||||
The https://containers.github.io/bootc/bootc-install.html#using-bootc-install-to-existing-root[`bootc install to-existing-root`]
|
||||
The {bootc-upstream}/bootc-install.html#using-bootc-install-to-existing-root[`bootc install to-existing-root`]
|
||||
path supports installing "inside" an existing running Linux system, effectively
|
||||
replacing its contents with the container image. This allows provisioning
|
||||
systems using *existing* disk images already uploaded and managed
|
||||
as part of the virtualization platform.
|
||||
as part of the virtualization platform.
|
||||
|
|
|
|||
|
|
@ -45,5 +45,5 @@ In the more medium term, there are plans to extend `dnf` to also support
|
|||
client-side functionality similar to this:
|
||||
https://gitlab.com/fedora/bootc/tracker/-/issues/4[client side layering tracker].
|
||||
|
||||
This would build on more generic support for https://containers.github.io/bootc/booting-local-builds.html[booting local builds]
|
||||
This would build on more generic support for {bootc-upstream}/booting-local-builds.html[booting local builds]
|
||||
for persistent layering.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
{projname} ships with https://podman.io[podman] installed to run application containers.
|
||||
|
||||
Per the https://containers.github.io/bootc/building/guidance.html#configuration[configuration guidance]
|
||||
Per the {bootc-upstream}/building/guidance.html#configuration[configuration guidance]
|
||||
prefer using `/usr/share/containers/systemd` for including "static" container images that are launched
|
||||
dynamically.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,11 +42,11 @@ include::cloud-init-growpart.adoc[]
|
|||
|
||||
=== Storage with `bootc install`
|
||||
|
||||
See https://containers.github.io/bootc/bootc-install.html[bootc install] for more information.
|
||||
See {bootc-upstream}/bootc-install.html[bootc install] for more information.
|
||||
The `bootc install to-disk` can be used to directly write a "simple" flat storage configuration.
|
||||
|
||||
More advanced installations (especially to bare metal) can also
|
||||
be done via https://containers.github.io/bootc/man/bootc-install-to-filesystem.html[bootc install to-filesystem];
|
||||
be done via {bootc-upstream}/man/bootc-install-to-filesystem.html[bootc install to-filesystem];
|
||||
you can set up the target block storage and filesystem however
|
||||
you desire via external tools, then have your custom container
|
||||
image "self-install" to it.
|
||||
|
|
@ -55,7 +55,7 @@ image "self-install" to it.
|
|||
|
||||
{projname} uses the bootc upstream project which currently uses ostree as a backend.
|
||||
|
||||
For more on the filesystem layout, see https://containers.github.io/bootc/filesystem.html[bootc filesystem].
|
||||
For more on the filesystem layout, see {bootc-upstream}/filesystem.html[bootc filesystem].
|
||||
|
||||
=== Differences from other OSTree-based systems
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
Over the last decade, https://specs.opencontainers.org/image-spec/[OCI containers] have become a de facto way to deploy a complete functioning Linux user space as an application. A large set of practices and tooling have evolved around them. Bootable containers are a modern opinionated way of deploying, configuring and managing immutable image based Linux systems using those practices and tooling. You can find a mission statement on https://github.com/containers/bootable[github.com/containers/bootable].
|
||||
|
||||
The https://containers.github.io/bootc/[bootc documentation] summarizes bootable containers as "transactional, in-place operating system updates using OCI/Docker container images". In other words, updates to the operating system (OS) are shipped by using container images. That implies that the Linux kernel, the bootloader, drivers, etc. are all part of the container image which renders the container image "bootable".
|
||||
The {bootc-upstream}/[bootc documentation] summarizes bootable containers as "transactional, in-place operating system updates using OCI/Docker container images". In other words, updates to the operating system (OS) are shipped by using container images. That implies that the Linux kernel, the bootloader, drivers, etc. are all part of the container image which renders the container image "bootable".
|
||||
|
||||
Just like ordinary application containers, you can build bootable containers by using existing container technologies such as https://github.com/containers/common/blob/main/docs/Containerfile.5.md[Containerfiles] (i.e., https://docs.docker.com/reference/dockerfile[Dockerfiles]) and with existing tooling such as https://podman.io/[Podman], https://www.docker.com/[Docker] or https://github.com/moby/buildkit[buildkit]. You can further store the images on any container registry such as https://quay.io/[Quay.io], https://hub.docker.com/[Docker Hub], https://github.com/features/packages[the GitHub Container Registry] or any internal container registry.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue