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.

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
+----
+

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