Images of Container Linux alpha releases are hosted at
https://alpha.release.core-os.net/amd64-usr/. There are directories for releases by version as well as
current with a copy of the latest version. Similarly, beta releases can be found at
If you are importing images for use inside of your environment it is recommended that you import from the
current directory. For example to grab the alpha OpenStack version of Container Linux you can import
https://alpha.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2. There is a
version.txt file in this directory which you can use to label the image with a version number.
It is recommended that you also verify files using the CoreOS Image Signing Key. The GPG signature for each image is a detached
.sig file that must be passed to
gpg --verify. For example:
wget https://alpha.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2 wget https://alpha.release.core-os.net/amd64-usr/current/coreos_production_openstack_image.img.bz2.sig gpg --verify coreos_production_openstack_image.img.bz2.sig
Customizing a Container Linux image for a specific operating environment is easily done through cloud-config, a YAML-based configuration standard that is widely supported. As a provider, you must ensure that your platform makes this data available to Container Linux, where it will be parsed during the boot process.
Use cloud-config to handle platform specific configuration such as custom networking, running an agent on the machine or injecting files onto disk. Container Linux will automatically parse and execute
/usr/share/oem/cloud-config.yml if it exists. Your cloud-config should create additional units that process user-provided metadata, as described below.
End-users should be able to provide a cloud-config file to your platform while specifying their VM's parameters. This file should be made available to Container Linux at a known network address, injected directly onto disk or contained within a config-drive. Below are a few examples of how this process works on a few different providers.
Container Linux machines running on Amazon EC2 utilize a two-step cloud-config process. First, a cloud-config file baked into the image runs systemd units that execute scripts to fetch the user-provided SSH key and fetch the user-provided cloud-config from the instance user-data service on Amazon's internal network. Afterwards, the user-provided cloud-config, specified from either the web console or API, is parsed.
Rackspace passes configuration data to a VM by mounting config-drive, a special configuration drive containing machine-specific data, to the machine. Like, Amazon EC2, Container Linux images for Rackspace contain a cloud-config file baked into the image that runs units to read from the config-drive. If a user-provided cloud-config file is found, it is parsed.