You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/index.md
+13-76Lines changed: 13 additions & 76 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,7 +59,7 @@ The `bootc install` functionality is also more experimental.
59
59
60
60
### Installing
61
61
62
-
* Fedora: [bootc is packaged](https://bodhi.fedoraproject.org/updates/?packages=bootc) and be available in the main repositories soon.
62
+
* Fedora: [bootc is packaged](https://bodhi.fedoraproject.org/updates/?packages=bootc).
63
63
* CentOS Stream 9: There is a [COPR](https://copr.fedorainfracloud.org/coprs/rhcontainerbot/bootc/) tracking git main with binary packages.
64
64
65
65
You can also build this project like any other Rust project, e.g. `cargo build --release` from a git clone.
@@ -68,15 +68,15 @@ You can also build this project like any other Rust project, e.g. `cargo build -
68
68
69
69
Many users will be more interested in base (container) images.
70
70
71
-
To build base images "from scratch", see [bootc-images.md](bootc-images.md).
72
-
73
71
For pre-built base images:
74
72
75
73
*[Fedora CoreOS](https://quay.io/repository/fedora/fedora-coreos) can be used as a base image; you will need to [enable bootc](https://github.com/coreos/rpm-ostree/blob/main/docs/bootc.md) there.
76
74
* There is also an in-development [centos-boot](https://github.com/centos/centos-boot) project.
77
75
78
76
However, bootc itself is not tied to Fedora derivatives; [this issue](https://github.com/coreos/bootupd/issues/468) tracks the main blocker for other distributions.
79
77
78
+
To build base images "from scratch", see [bootc-images.md](bootc-images.md).
79
+
80
80
### Deriving from and switching to base images
81
81
82
82
A toplevel goal is that *every tool and technique* a Linux system
@@ -111,82 +111,19 @@ drift in this scenario however.
111
111
### Upgrading
112
112
113
113
Once a chosen container image is used as the boot source, further
114
-
invocations of `bootc upgrade` will look for newer versions - again
115
-
preserving state.
116
-
117
-
## Relationship with other projects
118
-
119
-
### Relationship with podman
120
-
121
-
It gets a bit confusing to talk about shipping bootable operating systems in container images.
122
-
Again, to be clear: we are reusing container images as:
123
-
124
-
- A build mechanism (including running *as* a standard OCI container image)
125
-
- A transport mechanism
126
-
127
-
But, actually when a bootc container is booted, podman (or docker, etc.) is not involved.
128
-
The storage used for the operating system content is distinct from `/var/lib/containers`.
129
-
`podman image prune --all` will not delete your operating system.
130
-
131
-
That said, a toplevel goal of bootc is alignment with the https://github.com/containers ecosystem,
132
-
which includes podman. But more specifically at a technical level, today bootc uses
133
-
[skopeo](https://github.com/containers/skopeo/) and hence indirectly [containers/image](https://github.com/containers/image)
134
-
as a way to fetch container images.
135
-
136
-
This means that bootc automatically also honors many of the knobs available in `/etc/containers` - specifically
137
-
things like [containers-registries.conf](https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md).
138
-
139
-
In other words, if you configure `podman` to pull images from your local mirror registry, then `bootc` will automatically honor that as well.
140
-
141
-
The simple way to say it is: A goal of `bootc` is to be the bootable-container analogue for `podman`, which runs application containers. Everywhere one might run `podman`, one could also consider using `bootc`.
142
-
143
-
### Relationship with Kubernetes
144
-
145
-
Just as `podman` does not depend on a Kubernetes API server, `bootc` will also not depend on one.
146
-
147
-
However, there are also plans for `bootc` to also understand Kubernetes API types. See [configmap/secret support](https://github.com/containers/bootc/issues/22) for example.
148
-
149
-
Perhaps in the future we may actually support some kind of `Pod` analogue for representing the host state. Or we may define a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) which can be used inside and outside of Kubernetes.
150
-
151
-
### Relationship with rpm-ostree
152
-
153
-
Today rpm-ostree directly links to `ostree-rs-ext`, and hence
154
-
gains all the same container functionality. This will likely
155
-
continue. For example, with rpm-ostree (or, perhaps re-framed as
156
-
"dnf image"), it will continue to work to e.g. `dnf install`
157
-
(i.e. `rpm-ostree install`) on the *client side* system. However, `bootc upgrade` would
158
-
(should) then error out as it will not understand how to upgrade
159
-
the system.
160
-
161
-
rpm-ostree also has significant other features such as
162
-
`rpm-ostree kargs` etc.
163
-
164
-
Overall, rpm-ostree is used in several important projects
165
-
and will continue to be maintained for many years to come.
166
-
167
-
However, for use cases which want a "pure" image based model,
168
-
using `bootc` will be more appealing. bootc also does not
169
-
e.g. drag in dependencies on `libdnf` and the RPM stack.
170
-
171
-
bootc also has the benefit of starting as a pure Rust project;
172
-
and while it [doesn't have an IPC mechanism today](https://github.com/containers/bootc/issues/4), the surface
173
-
of such an API will be significantly smaller.
174
-
175
-
Further, bootc does aim to [include some of the functionality of zincati](https://github.com/containers/bootc/issues/5).
176
-
177
-
But all this said: *It will be supported to use both bootc and rpm-ostree together*; they are not exclusive.
178
-
For example, `bootc status` at least will still function even if packages are layered.
179
-
180
-
### Relationship with Fedora CoreOS (and Silverblue, etc.)
181
-
182
-
Per above, it is a toplevel goal to support a seamless, transactional update from existing OSTree based systems, which includes these Fedora derivatives.
114
+
invocations of `bootc upgrade` from the installed operating system
115
+
will fetch updates from the container image registry.
183
116
184
-
For Fedora CoreOS specifically, see [this tracker issue](https://github.com/coreos/fedora-coreos-tracker/issues/1446).
117
+
This is backed today by ostree, implementing an A/B style upgrade system.
118
+
Changes to the base image are staged, and the running system is not
119
+
changed by default.
185
120
186
-
See also [OstreeNativeContainerStable](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable).
121
+
Use `bootc upgrade --apply` to apply updates; today this will always
It gets a bit confusing to talk about shipping bootable operating systems in container images.
10
+
Again, to be clear: we are reusing container images as:
11
+
12
+
- A build mechanism (including running *as* a standard OCI container image)
13
+
- A transport mechanism
14
+
15
+
But, actually when a bootc container is booted, podman (or docker, etc.) is not involved.
16
+
The storage used for the operating system content is distinct from `/var/lib/containers`.
17
+
`podman image prune --all` will not delete your operating system.
18
+
19
+
That said, a toplevel goal of bootc is alignment with the https://github.com/containers ecosystem,
20
+
which includes podman. But more specifically at a technical level, today bootc uses
21
+
[skopeo](https://github.com/containers/skopeo/) and hence indirectly [containers/image](https://github.com/containers/image)
22
+
as a way to fetch container images.
23
+
24
+
This means that bootc automatically also honors many of the knobs available in `/etc/containers` - specifically
25
+
things like [containers-registries.conf](https://github.com/containers/image/blob/main/docs/containers-registries.conf.5.md).
26
+
27
+
In other words, if you configure `podman` to pull images from your local mirror registry, then `bootc` will automatically honor that as well.
28
+
29
+
The simple way to say it is: A goal of `bootc` is to be the bootable-container analogue for `podman`, which runs application containers. Everywhere one might run `podman`, one could also consider using `bootc`.
30
+
31
+
## Relationship with Kubernetes
32
+
33
+
Just as `podman` does not depend on a Kubernetes API server, `bootc` will also not depend on one.
34
+
35
+
However, there are also plans for `bootc` to also understand Kubernetes API types. See [configmap/secret support](https://github.com/containers/bootc/issues/22) for example.
36
+
37
+
Perhaps in the future we may actually support some kind of `Pod` analogue for representing the host state. Or we may define a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) which can be used inside and outside of Kubernetes.
38
+
39
+
## Relationship with rpm-ostree
40
+
41
+
Today rpm-ostree directly links to `ostree-rs-ext`, and hence
42
+
gains all the same container functionality. This will likely
43
+
continue. For example, with rpm-ostree (or, perhaps re-framed as
44
+
"dnf image"), it will continue to work to e.g. `dnf install`
45
+
(i.e. `rpm-ostree install`) on the *client side* system. However, `bootc upgrade` would
46
+
(should) then error out as it will not understand how to upgrade
47
+
the system.
48
+
49
+
rpm-ostree also has significant other features such as
50
+
`rpm-ostree kargs` etc.
51
+
52
+
Overall, rpm-ostree is used in several important projects
53
+
and will continue to be maintained for many years to come.
54
+
55
+
However, for use cases which want a "pure" image based model,
56
+
using `bootc` will be more appealing. bootc also does not
57
+
e.g. drag in dependencies on `libdnf` and the RPM stack.
58
+
59
+
bootc also has the benefit of starting as a pure Rust project;
60
+
and while it [doesn't have an IPC mechanism today](https://github.com/containers/bootc/issues/4), the surface
61
+
of such an API will be significantly smaller.
62
+
63
+
Further, bootc does aim to [include some of the functionality of zincati](https://github.com/containers/bootc/issues/5).
64
+
65
+
But all this said: *It will be supported to use both bootc and rpm-ostree together*; they are not exclusive.
66
+
For example, `bootc status` at least will still function even if packages are layered.
67
+
68
+
## Relationship with Fedora CoreOS (and Silverblue, etc.)
69
+
70
+
Per above, it is a toplevel goal to support a seamless, transactional update from existing OSTree based systems, which includes these Fedora derivatives.
71
+
72
+
For Fedora CoreOS specifically, see [this tracker issue](https://github.com/coreos/fedora-coreos-tracker/issues/1446).
73
+
74
+
See also [OstreeNativeContainerStable](https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable).
0 commit comments