Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

README: De-emphasize specifying user configuration #135

Closed
wants to merge 1 commit into from
Closed

README: De-emphasize specifying user configuration #135

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 13 additions & 5 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,13 +23,21 @@ $ podman machine start

## 🚀 Examples

The following example builds a [Fedora ELN](https://docs.fedoraproject.org/en-US/eln/) bootable container into a QCOW2 image for the architecture you're running
the command on.
The default expected entrypoint to a bootc system is to first create a derived container image
with your desired operating system state, authentication, firewalling etc. For more on
this, please see [the documentation](https://centos.github.io/centos-bootc/builds/).

The `fedora-bootc:eln` base image does not include a default user. This example injects a [user configuration file](#-build-config)
NOTE at the current time this project [does not yet support CentOS Stream 9](https://github.com/osbuild/bootc-image-builder/issues/20).

The base images [do not contain a user](https://centos.github.io/centos-bootc/builds/#users-and-groups).
In order allow decoupling authentication credentials from the container image, where desired,
this project also supports a [user configuration file](#-build-config). This can be provided
by adding a volume-mount for the local file as well as the `--config` flag to the bootc-image-builder container.

The following command will create a QCOW2 disk image. First, create `./config.json` as described above to configure user access.
The following command will create a QCOW2 disk image. If you prefer to maintain
credentials outside of the image, create `./config.json` as described above to configure user access.
But, other options are possible, for example you can add `cloud-init` to your image
instead and rely on that ecosystem.

```
sudo podman run \
Expand All @@ -43,7 +51,7 @@ sudo podman run \
quay.io/centos-bootc/bootc-image-builder:latest \
--type qcow2 \
--config /config.json \
quay.io/centos-bootc/fedora-bootc:eln
<your custom image>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would really like to keep a ready made copy/paste example. I think we will lose a lot of our audience if there is not a 1-5 lines copy/paste recipe for people to just try it out. Note that this might be fine depending on the audience we are targeting. But my preference would be to have some

$ cat >Containerfile <<EOF
FROM quay.io/centos-bootc/fedora-bootc:eln
<do-something-like-create-a-user-here>
EOF
$ podman build -f Containerfile -t hello-bootc
$ sudo podman run ... quay.io/centos-bootc/bootc-image-builder:latest ...

With that the user will have an image, can login, look around etc.

Happy to discuss this of course!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I understand your point. However let me back up and say that I think the entrypoint to the documentation should be shared - and currently that lives in more in https://github.com/CentOS/centos-bootc

(At some point hopefully soon we'll create a dedicated docs repo, but that's a distinct thread)

Now, we keep getting hung up on the user bits. It's a super hard problem. I just did CentOS/centos-bootc#205 which also documents using systemd credentials, IMO is often better than baking ssh keys into an image for "one off testing". This is just a super complex topic because again one might have a setup where the production image uses FreeIPA, but when you're just iterating locally you don't want that.

I understand from the perspective of bib it'd be good to have a one-liner to copy-paste to be able to execute it.

But I think bib is unlikely to be the primary "system entrypoint" in reality. There are multiple, basically in some order:

cloud

Try out https://github.com/CentOS/centos-bootc-layered/tree/main/cloud (which note also has pre-generated disk images that are made using bib right now). This will be straightforward and understandable to many experienced Linux sysadmins, immediately getting them a shell in their preferred virt framework, without building any containers or disk images.

podman CLI verb

Given we want podman (and podman desktop) to be a key entrypoint I think containers/podman#21243 will make the most sense, because we have the opportunity to streamline that all down to a basic:

podman machine bootc run quay.io/centos-bootc/centos-bootc:stream9

or whatever (that would also work with custom images); my WIP code today uses bootc install to-disk behind the scenes to materialize a disk image and systemd credentials to inject a root SSH key.

And notably doing it in podman gets us cross-architecture virt, which is an important thing (this repo does a decent job at documenting it, but we just need to streamline it to that I think).

```

### Running the resulting QCOW2 file on Linux (x86_64)
Expand Down
Loading