diff --git a/modules/ROOT/pages/deriving-container.adoc b/modules/ROOT/pages/deriving-container.adoc new file mode 100644 index 00000000..a1033e56 --- /dev/null +++ b/modules/ROOT/pages/deriving-container.adoc @@ -0,0 +1,94 @@ += 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: + +- quay.io/fedora/fedora-coreos:stable +- quay.io/fedora/fedora-coreos:next + +etc. + +== Creating custom builds + +See the https://github.com/coreos/layering-examples[layering examples] git repository. While the examples there tend to use Container/Dockerfile style builds, you can use any tool which can build containers and push the result to a registry. + +== Using Ignition to retarget an instance + +The https://coreos.github.io/rpm-ostree/container/[rpm-ostree container page] describes the commands for interacting with bootable ostree container images. + +In this example, we will use a systemd unit to fetch and reboot into the target custom container image, and also install a systemd unit which will enable +automatic polling of the target tag, and reboot on changes. + +[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 + # Our custom unit for automatic upgrades + - name: autoupdate-host.service + enabled: false + contents: | + [Unit] + Description=Automatic host upgrades + [Service] + Type=simple + ExecStart=rpm-ostree upgrade --reboot + StandardOutput=null + # zincati does not yet understand containers + - name: zincati.service + enabled: false + # Our custom unit for automatic upgrades + - name: autoupdate-host.timer + enabled: true + contents: | + [Unit] + Description=Automatic daily host upgrades + [Timer] + OnBootSec=1h + OnUnitInactiveSec=1d + [Install] + WantedBy=timers.target +---- + +== Adding pull secrets for private container images + +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 + contents: + inline: > + { + "auths": { + "quay.io": { + "auth": "..." + } + } + } + mode: 0600 +---- + diff --git a/modules/ROOT/pages/getting-started.adoc b/modules/ROOT/pages/getting-started.adoc index a0af4c33..081263ed 100644 --- a/modules/ROOT/pages/getting-started.adoc +++ b/modules/ROOT/pages/getting-started.adoc @@ -19,7 +19,7 @@ Fedora CoreOS does not have a separate install disk. Instead, every instance sta Each platform has specific logic to retrieve and apply the first boot configuration. For cloud deployments, Ignition gathers the configuration via user-data mechanisms. In the case of bare metal, Ignition can fetch its configuration from the disk or from a remote source. -For more information on configuration, refer to the documentation for xref:producing-ign.adoc[Producing an Ignition File]. +For more information on configuration, refer to the documentation for xref:producing-ign.adoc[Producing an Ignition File]. There is also the ability to derive from the container base image, see xref:deriving-container.adoc[Booting a derived container image]. == Quickstart