Note: Please migrate to Container Linux Configs. Cloud-Config support will be removed in the future.
CoreOS Cloud-Config is a system for configuring machines with a Cloud-Config file or executable script from user-data. Cloud-Config runs in userspace on each boot and implements a subset of the cloud-init spec. See the cloud-config docs for details.
Cloud-Config template files can be added in /var/lib/matchbox/cloud
or in a cloud
subdirectory of a custom -data-path
. Template files may contain Go template elements which will be evaluated with group metadata, selectors, and query params.
/var/lib/matchbox
├── cloud
│ ├── cloud.yaml
│ └── script.sh
├── ignition
└── profiles
Reference a Cloud-Config in a Profile with cloud_id
. When PXE booting, use the kernel option cloud-config-url
to point to matchbox
cloud-config endpoint.
Here is an example Cloud-Config which starts some units and writes a file.
#cloud-config
coreos:
units:
- name: etcd2.service
command: start
- name: fleet.service
command: start
write_files:
- path: "/home/core/welcome"
owner: "core"
permissions: "0644"
content: |
{{.greeting}}
The Cloud-Config Validator is also useful for checking your Cloud-Config files for errors.
Cloud-Config starts after userspace has started, on every boot. Ignition starts before PID 1 and only runs on the first boot. Ignition favors immutable infrastructure.
Ignition is favored as the replacement for CoreOS Cloud-Config. Tasks often only need to be run once and can be performed more easily before systemd has started (e.g. configuring networking). Ignition can write service units for tasks that need to be run on each boot. Instead of depending on Cloud-Config variable substitution, Ignition favors using systemd's EnvironmentFile expansion to start units with a metadata file from a metadata source.