-
Notifications
You must be signed in to change notification settings - Fork 120
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add a doc for container provisioning and updates
The layering model is an entirely new way to do systems management. Let's document the current state.
- Loading branch information
Showing
2 changed files
with
101 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
= Deriving from Fedora CoreOS as a bootable container image | ||
|
||
== Bootable containers overview | ||
|
||
The operating system images used for Fedora CoreOS are available as a standard container image; there is one per stream. See xref:update-streams.adoc[Update Streams]. | ||
|
||
- quay.io/fedora/fedora-coreos:stable | ||
- quay.io/fedora/fedora-coreos:next | ||
- quay.io/fedora/fedora-coreos:testing | ||
|
||
== Creating custom builds | ||
|
||
See the https://github.com/coreos/layering-examples[layering examples] git repository. While the examples there tend to use Containerfile/Dockerfile style builds, you can use any tool which can build containers and push the result to a registry. | ||
|
||
The default suggested approach is to have container tags be the source of truth for initating upgrades, and to have the client systems poll. Example systemd units for this are in [https://github.com/coreos/layering-examples/tree/main/autoupdate-host]; they boil down to a systemd `.service` which just runs `rpm-ostree upgrade --reboot` and a corresponding `.timer` unit to run it once a day. | ||
|
||
Of course, client side logic could be much more complex, including a privileged container image that runs completely arbitrary logic. | ||
|
||
== Using Ignition to switch to a bootable container image | ||
|
||
The https://coreos.github.io/rpm-ostree/container/[rpm-ostree container page] describes the commands for interacting with bootable ostree container images. | ||
|
||
This systemd unit will run only on the first boot, and switch a "stock" Fedora CoreOS node to your custom image. | ||
|
||
[source,yaml] | ||
---- | ||
variant: fcos | ||
version: 1.4.0 | ||
systemd: | ||
units: | ||
# Our custom unit for rebasing | ||
- name: rebase-custom.service | ||
enabled: true | ||
contents: | | ||
[Unit] | ||
Description=Fetch and deploy target image | ||
# Only run on the firstboot | ||
ConditionFirstBoot=true | ||
After=network-online.target | ||
[Service] | ||
# This ordering is important | ||
After=ignition-firstboot-complete.service | ||
Type=oneshot | ||
RemainAfterExit=yes | ||
ExecStart=rpm-ostree rebase --reboot ostree-unverified-registry:quay.io/example/example-derived:latest | ||
[Install] | ||
WantedBy=multi-user.target | ||
---- | ||
|
||
== Adding pull secrets for private container images | ||
|
||
If your registry requires authentication, then you can add a pull secret. See https://coreos.github.io/rpm-ostree/container/#registry-authentication[container pull secrets]. | ||
|
||
[source,yaml] | ||
---- | ||
variant: fcos | ||
version: 1.4.0 | ||
storage: | ||
files: | ||
- path: /etc/ostree/auth.json | ||
mode: 0600 | ||
contents: | ||
inline: > | ||
{ | ||
"auths": { | ||
"quay.io": { | ||
"auth": "..." | ||
} | ||
} | ||
} | ||
---- | ||
|
||
== Maintaining custom builds | ||
|
||
As the upstream container image (e.g. quay.io/fedora/fedora-coreos:stable) changes for security and functionality improvements, you are responsible for re-building your derived image. Implementing this depends on your chosen container build system. | ||
|
||
However, key to this model is the assumption that if you're deploying Fedora CoreOS, you have already invested in container infrastructure and can manage the operating system updates in the same way as application containers. | ||
|
||
== Understanding Ignition versus container content | ||
|
||
Ignition's philosophy is that it runs exactly once, and any subsequent changes should generally be done by node reprovisioning. This can | ||
be very expensive in some environments. Storing configuration directly | ||
with the OS content allows strongly coupling them and ensuring that | ||
the state of your machines is exactly what you build and replicate | ||
as a container image. | ||
|
||
Note however that content injected via Ignition will still persist as | ||
machine-local state into subsequent OS updates (including by default | ||
our unit to do the switch, which will remain inactive; though your | ||
container could run code to delete or mask the unit). | ||
|
||
This serves as a very useful "escape hatch" for machine local state. | ||
Crucially for example, networking is needed in order to fetch custom | ||
container images in this model. If your environment uses static IP | ||
addressing, then you will need to continue to inject that configuration | ||
via Ignition. | ||
|
||
As but even without the bootstrap problem of networking, there is other | ||
potential machine local state such as `/etc/hostname`, kernel | ||
arguments, etc. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters