particle-os/debian-bootc-base-images
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: Improve login/tryout docs

Browse source 
- Add a preface about the base image not having cloud-init
- Migrate the Anaconda example code here and make it first
This commit is contained in:
Colin Walters 2023-11-08 15:03:07 -05:00
parent 133b52ffc2
commit a172237629
2 changed files with 171 additions and 35 deletions
Download patch file Download diff file Expand all files Collapse all files

96
docs/install.md
View file

@ -4,6 +4,67 @@
nav_order: 2
---
## Operating system state (users, ssh keys)
It's absolutely crucial to understand that the container image *is* the
operating system content. Notably the default `tier-1` image
[does not include cloud-init](cloud-agents.md) or Ignition or any default
recommended mechanism for provisioning user accountson its own.
Commonly then you will want to build your own container image derived from e.g.
`quay.io/centos-boot/fedora-tier-1:eln` that adds a login mechanism. For
example, you could
[add cloud-init](https://gitlab.com/CentOS/cloud/sagano-examples/-/blob/main/cloud-init-base/Containerfile).
However, it's also possible to embed SSH login configuration in the image, or
configure any login mechanism you desire in general! For example, you could set
up a VPN configuration in your operating system and ensure logins are only
possible over the VPN, etc.
## Installation using Anaconda
Tools like
[Anaconda](https://anaconda-installer.readthedocs.io/en/latest/intro.html)
support injecting configuration at image installation time, such as SSH keys and
passwords. This means that in contrast to what was said just before, it's
possible to directly install (and update from) an "unconfigured base image"
provided by this project.
This hinges on the
[ostreecontainer](https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#ostreecontainer)
kickstart verb, which is new in Fedora 38; for example, there is a
[netinst.iso](https://dl.fedoraproject.org/pub/fedora/linux/releases/39/Everything/x86_64/iso/)
which can be scripted with kickstart. Because a current development target for
this project is [Fedora ELN](https://docs.fedoraproject.org/en-US/eln/), it's
also supported to use the ISO generated by that project.
See [example.ks](example.ks) for an example Kickstart file. The
[virt-install --initrd-inject](https://github.com/virt-manager/virt-manager/blob/main/man/virt-install.rst#--initrd-inject)
helps inject kickstart for installation to virtual machines.
## Using `bootc install-to-filesystem --replace=alongside` with a cloud image
A toplevel goal of this project is that the "source of truth" for Linux
operating system management is a container image registry - as opposed to e.g. a
set of qcow2 OpenStack images or AMIs, etc. You should not need to maintain
infrastructure to e.g. manage garbage collection or versioning of cloud (IaaS)
VM images.
The latest releases of `bootc` have support for
`bootc install-to-filesystem --replace=alongside`. More about this core mechanic
in the
[bootc install docs](https://github.com/containers/bootc/blob/main/docs/install.md).
Here's an example set of steps to execute; this could be done via e.g.
[cloud-init](https://cloudinit.readthedocs.io/en/latest/reference/index.html)
configuration.
```shell
dnf -y install podman skopeo
podman run --rm --privileged --pid=host -v /:/target --security-opt label=type:unconfined_t <yourimage> bootc install-to-filesystem --target-no-signature-verification --karg=console=ttyS0,115200n8 --replace=alongside /target
reboot
```
<!--
## Booting directly from KVM guest image
@ -31,41 +92,6 @@ rpm-ostree rebase ostree-unverified-registry:quay.io/centos-boot/fedora-tier-1:e
systemctl reboot
```
See also [this pull request][1] for more information.
## TODO: Use osbuild
Document the ongoing work to materialize a disk image from a container.
## Using `bootc install-to-filesystem --replace=alongside` with a cloud image
A toplevel goal of this project is that the "source of truth" for Linux
operating system management is a container image registry - as opposed to e.g. a
set of qcow2 OpenStack images or AMIs, etc.
The latest development builds of `bootc` have support for
`bootc install-to-filesystem --replace=alongside`. More about this core
mechanic in the [bootc install docs](https://github.com/containers/bootc/blob/main/docs/install.md).
Here's an example set of steps to execute; this could be done via e.g.
[cloud-init](https://cloudinit.readthedocs.io/en/latest/reference/index.html)
configuration.
```shell
dnf -y install podman skopeo
podman run --rm --privileged --pid=host -v /:/target --security-opt label=type:unconfined_t quay.io/centos-boot/fedora-tier-1:eln bootc install-to-filesystem --target-no-signature-verification --karg=console=ttyS0,115200n8 --replace=alongside /target
reboot
```
## Generating a derived container image
These examples just use a "stock" container image, and in the first case rely on
user state being preserved by the `rpm-ostree rebase`.
What's much more interesting is to generate a custom derived container image,
and target that instead. For more information, see
- <https://github.com/coreos/layering-examples>
- <https://github.com/openshift/rhcos-image-layering-examples>
[1]: https://github.com/coreos/fedora-coreos-docs/pull/540